Iım not suggesting that the system be quiesced. Iım just suggesting that,
for the session which issues the ALTER SYSTEM, commit or rollback any
in-flight transactions first.
I donıt feel that itıs unreasonable for an in-flight transaction to fail
when an ALTER SYSTEM is executed in its midst. Yes, an ORA-00600 is
considered a bug, but chances are good that the ³fix² will be to assign a
valid Oracle error to the condition anyway...
on 3/25/04 9:10 AM, Bobak, Mark at Mark.Bobak_at_il.proquest.com wrote:
> Not to mention, ORA-00600 is, by definition, a bug.
>>
>> -----Original Message-----
>> From: John Hallas [mailto:john.hallas_at_hcresources.co.uk]
>> Sent: Thursday, March 25, 2004 10:38 AM
>> To: oracle-l_at_freelists.org
>> Subject: RE: Resource Manager bug in 9.2.0.4?
>>
>>
>>
>>
>> Fair point Tim, but it should not be the case that you need a quiescent
>> system before changing plans.
>>
>> On many systems that situation is almost impossible to achieve
>>
>> John
>>
>>
>>
>> -----Original Message-----
>> From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org]
>> On Behalf Of Tim Gorman
>> Sent: 25 March 2004 14:27
>> To: oracle-l_at_freelists.org
>> Subject: Re: Resource Manager bug in 9.2.0.4?
>>
>>
>>
>> Jeff,
>>
>> Wouldnıt it make more sense to complete the transaction before using ALTER
>> SYSTEM? Does the error reproduce when you do that?
>>
>> -Tim
>>
>> on 3/25/04 6:47 AM, Thomas Jeff at jeff.thomas_at_thomson.net wrote:
>>
>> Wondering if anyone has experienced the following bug in Res Mgr (we
>> are running 9.2.0.4 on AIX 4.3.3). We have a TAR in for this, but
>> our experience is that tech support is completely hapless when it
>> comes to Res Mgr issues.
>>
>> The error occurs when we switch plans while users have ongoing uncommitted
>> transactions, their session will terminate with an ORA-600: internal
>> error code, arguments: [kgskdecrstat1] when they issue a COMMIT.
>> We had planned on implementing Res Mgr in our prod databases for various
>> reasons, with a need to switch plans, so this is a big show-stopper.
>>
>> I can recreate the error in every database with something like the
>> following:
>>
>>
>> SQL> create table xyz as select * from dba_objects where 1=2;
>>
>> Table created.
>>
>> SQL> insert into xyz select * from dba_objects where owner = 'SYS';
>>
>> 12561 rows created.
>>
>> SQL> alter system set resource_manager_plan = '';
>>
>> System altered.
>>
>> SQL> alter system set resource_manager_plan = 'ES_RM_PLAN';
>>
>> System altered.
>>
>> SQL> commit;
>> commit
>> *
>> ERROR at line 1:
>> ORA-00603: ORACLE server session terminated by fatal error
>>
>>
>> --------------------------------------------
>> Jeffery D Thomas
>> DBA
>> Thomson Information Services
>> Thomson, Inc.
>>
>> Email: jeff.thomas_at_thomson.net
>>
>> Indy DBA Master Documentation available at:
>> http://gkmqp.tce.com/tis_dba <http://gkmqp.tce.com/tis_dba>
>> --------------------------------------------
>>
>>
>>
>>
>>
>> ---
>> Incoming mail is certified Virus Free.
>> Checked by AVG anti-virus system (http://www.grisoft.com).
>> Version: 6.0.581 / Virus Database: 368 - Release Date: 09/02/2004
>>
>>
>>
>> ---
>> Outgoing mail is certified Virus Free.
>> Checked by AVG anti-virus system (http://www.grisoft.com).
>> Version: 6.0.581 / Virus Database: 368 - Release Date: 09/02/2004
>
Please see the official ORACLE-L FAQ:
http://www.orafaq.com
To unsubscribe send email to: oracle-l-request_at_freelists.org
put 'unsubscribe' in the subject line.
--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Received on Thu Mar 25 2004 - 11:57:39 CST
