ALTER SYSTEM SET EVENTS is the instance level counterpart to ALTER SESSION SET EVENTS. It sets events for all future database sessions. Events set in this way do not persist across instance restarts. If an event must be set each time an instance starts, use the parameter EVENT (see page 32).
Here’s a scenario for using an event at instance level, which you will hopefully never have to face. Let’s assume there are several block corruptions in a table segment. Unfortunately, the database is in no archive log mode, so neither data file nor block level recovery are an option.
Importing the last export dump would result in data loss. The following undocumented event enables skipping of corrupt blocks during a full table scan:3
$ oerr ora 10231
10231, 00000, "skip corrupted blocks on _table_scans_"
// *Cause:
// *Action: such blocks are skipped in table scans, and listed in trace files You may be able to salvage most of the changes since the last export was done by a table- level export with this event. Yet, there is no way to instruct the export utility exp to set an event after it has connected. This is where ALTER SYSTEM SET EVENTS comes in handy. By using DBMS_
SYSTEM.READ_EV, we may confirm that events thus set really are picked up by new database sessions.
SQL> CONNECT / AS SYSDBA Connected.
SQL> VARIABLE lev NUMBER SQL> SET AUTOPRINT ON
SQL> ALTER SYSTEM SET EVENTS '10231 trace name context forever, level 10';
System altered.
SQL> EXECUTE sys.dbms_system.read_ev(10231, :lev)
2. ILO is available for download at http://sourceforge.net/projects/hotsos-ilo.
3. The documented procedure DBMS_REPAIR.SKIP_CORRUPT_BLOCKS provides the same functionality in Oracle9i and subsequent releases.
Debes_1952-1C13.fm Page 131 Tuesday, April 28, 2009 9:33 AM
LEV --- 0
SQL> CONNECT / AS SYSDBA Connected.
SQL> EXECUTE sys.dbms_system.read_ev(10231, :lev) LEV
--- 10
Event 10231 was not enabled in the database session that ran ALTER SYSTEM SET EVENTS.
After starting a new database session, the event is set. At this point the export utility might be started to salvage the data. As soon as it finishes, the event may be switched off.
SQL> ALTER SYSTEM SET EVENTS '10231 trace name context off';
System altered.
SQL> CONNECT / AS SYSDBA Connected.
SQL> EXECUTE sys.dbms_system.read_ev(10231, :lev) LEV
--- 0
ALTER SESSION/SYSTEM SET EVENTS and Diagnostic Dumps
ALTER SESSION SET EVENTS and ALTER SYSTEM SET EVENTS may also be used to request certain diag- nostic dumps in the event of an ORA-nnnnn error. The resulting trace files could be sent to Oracle Support for analysis. Usually, such trace files document the state of an instance at the time when an error occurred. Thus, they may prove useful in pinpointing the cause of a defect.
The syntax for requesting a dump when an ORA-nnnnn error occurs is as follows:
ALTER {SESSION|SYSTEM} SET EVENTS 'error_code TRACE NAME dump_name LEVEL lvl'
To print a list of available dumps, use the command ORADEBUG DUMPLIST in SQL*Plus. Following is the syntax for disabling a dump in the event of an ORACLE error:
ALTER {SESSION|SYSTEM} SET EVENTS 'error_code TRACE NAME dump_name OFF'
Let’s assume that several sessions have encountered the error ORA-04031, for example
“ORA-04031: unable to allocate 4096 bytes of shared memory ("java pool","unknown object","joxs heap","Intern")”. To create a heap dump each time any database session receives the ORACLE error 4031, you would run the following ALTER SYSTEM statement:4
SQL> ALTER SYSTEM SET EVENTS '4031 trace name heapdump level 536870914';
System altered.
4. Oracle10g automatically writes a trace file when an ORA-4031 error is raised.
C H A P T E R 1 3 ■ A L T E R S E S S I O N / S Y S T E M S E T E V E N T S 133
Valid levels for this event are 1, 2, 3, 32, and 536870912 plus one of the levels between 1 and 32. Among others, the resulting trace file contains a call stack trace and the SQL statement, which was active at the time when the error occurred.
ioc_allocate (size: 4096, heap name: *** SGA ***, flags: 110009) caught 4031
*** 2007-11-12 16:20:54.359 ksedmp: internal or fatal error
ORA-04031: unable to allocate 4096 bytes of shared memory ("java pool",
"unknown object","joxs heap","Intern") Current SQL statement for this session:
SELECT SYNNAM, DBMS_JAVA.LONGNAME(SYNNAM), DBMS_JAVA.LONGNAME(SYNTAB), TABOWN, TABNODE, PUBLIC$, SYNOWN, SYNOWNID, TABOWNID, SYNOBJNO FROM SYS.EXU9SYN WHERE SYNOWNID = :1 ORDER BY SYNTIME --- Call Stack Trace ---
calling call entry argument values in hex location type point (? means dubious value)
…
After collecting sufficient diagnostic data, the dump event may be disabled with the following statement:
SQL> ALTER SYSTEM SET EVENTS '4031 trace name heapdump off';
System altered.
Immediate Dumps
Using the following syntax, it is also possible to request that a dump be taken immediately:
ALTER SESSION SET EVENTS 'IMMEDIATE TRACE NAME dump_name LEVEL lvl'
If you suspect that an instance is hanging, you might take a system state dump like this:
SQL> ALTER SESSION SET EVENTS 'immediate trace name systemstate level 10';
Session altered.
The header of a system state dump looks as follows:
SYSTEM STATE ---
System global information:
processes: base 6ED426BC, size 50, cleanup 6ED47FF4 allocation: free sessions 6ED60D60, free calls 00000000 control alloc errors: 0 (process), 0 (session), 0 (call) PMON latch cleanup depth: 0
seconds since PMON's last scan for dead processes: 21 system statistics:
166 logons cumulative 18 logons current
1082648 opened cursors cumulative 25 opened cursors current
Debes_1952-1C13.fm Page 133 Tuesday, April 28, 2009 9:33 AM
135
■ ■ ■
C H A P T E R 1 4