Hi Sinardy,
Further to that, if you've looked at 'recover.bsq' you'll have seen that it attempts
up to 5 retries in the event of
ORA-235 errors. If you want to write similarly robust code and use event 10327 to test
it, then you might want to use
the seldom used LIFETIME qualifier of the event syntax instead of the FOREVER
qualifier that I suggested before. For
example, you could simulate getting the error twice and then succeeding on the third
attempt using the qualifier
LIFETIME 2.
There is also an AFTER n TIMES qualifier available that can be used to delay the
raising of the error. The thing to
watch here is that queries against the controlfile based V$ views may need to read
more than one block from the
controlfile. So although a query against V$THREAD can get away with just one
controlfile read, my full scan of V$LOGHIST
actually did 19 controlfile reads, so I would need to specify AFTER 19 TIMES to get
the query to succeed once before
failing. The AFTER n TIMES qualifier can be combined with the LIFETIME qualifier using
a comma to get both effects as
follows.
SQL> alter session set events '10327 trace name context after 19 times,
lifetime 2';
Session altered.
SQL> select count(*) from v$loghist;
COUNT(*)
----------
823
SQL> /
select count(*) from v$loghist
*
ERROR at line 1:
ORA-00235: controlfile fixed table inconsistent due to concurrent update
SQL> /
select count(*) from v$loghist
*
ERROR at line 1:
ORA-00235: controlfile fixed table inconsistent due to concurrent update
SQL> /
COUNT(*)
----------
823
SQL>
@ Regards,
@ Steve Adams
@ http://www.ixora.com.au/ - For DBAs
@ http://www.secularislam.org/call.htm - For Muslims
@ http://www.christianity.net.au/ - For all
-----Original Message-----
Sent: Friday, 19 October 2001 19:05
To: Sinard Xing; Multiple recipients of list ORACLE-L
Hi Sinardy,
Sure, the following should illustrate how you might use it for testing ...
SQL> alter session set events '10327 trace name context forever';
Session altered.
SQL> select count(*) from v$loghist;
select count(*) from v$loghist
*
ERROR at line 1:
ORA-00235: controlfile fixed table inconsistent due to concurrent update
SQL>
@ Regards,
@ Steve Adams
@ http://www.ixora.com.au/ - For DBAs
@ http://www.secularislam.org/call.htm - For Muslims
@ http://www.christianity.net.au/ - For all
-----Original Message-----
Sent: Friday, 19 October 2001 19:20
To: Multiple recipients of list ORACLE-L
Hi Steve,
Can you please give some hint, what is event 10327 ?
Regards,
Sinardy
-----Original Message-----
Sent: Friday, 19 October 2001 3:38 PM
To: Sinard Xing; Multiple recipients of list ORACLE-L
Hi Sinardy,
It probably means that a log switch was in progress at the same time as the
query. However, the error can be simulated
by setting event 10327. So if someone's been setting events and has messed
up, that could also explain it. You can use
that event for testing if you want to write robust code that handles the
error. A good example of such code can be seen
in '$ORACLE_HOME/rdbms/admin/recover.bsq'.
@ Regards,
@ Steve Adams
@ http://www.ixora.com.au/ - For DBAs
@ http://www.secularislam.org/call.htm - For Muslims
@ http://www.christianity.net.au/ - For all
-----Original Message-----
Can someone tell me what is the cause of this error
FROM sys.v_$loghist lh1, sys.v_$loghist lh2
*
ERROR at line 6:
ORA-00235: controlfile fixed table inconsistent due to concurrent update
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Steve Adams
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
