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 by 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 query of V$LOGHIST actually needs 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>

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>

Can you please give some hint, what is event 10327?

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.

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