Expert Oracle Exadata - Parent Directory

CHAPTER 4 STORAGE INDEXESSYS@EXDB1> @siNAMEVALUE--------------------------------------------- ---------------cell physical IO bytes saved by storage index 7969898496As you can see, the si.sql script queries v$mystat for a statistic that contains the word “storage.”The value for this statistic will be 0 until a SQL statement that uses a Storage Index has been executed inthe current session. In our example, the query used a Storage Index that eliminated about 4 billion bytesof disk I/O. This is the amount of additional I/O that would have been necessary without StorageIndexes. Note that v$mystat is a view that exposes cumulative statistics for your current session. So if yourun the statement a second time, the value should increase to twice the value it had after the firstexecution. Of course, disconnecting from the session (by exiting SQL*Plus for example) resets moststatistics exposed by v$mystat, including this one, to 0.TracingThere is another way to monitor what is going on with Storage Indexes at the individual storage celllevel. The cellsrv program has the ability to create trace files whenever Storage Indexes are accessed.This tracing can be enabled by setting the _CELL_STORAGE_INDEX_DIAG_MODE parameter to TRUE in thecellinit.ora file on one of the storage cells. You will need to restart the cellsrv program once thisparameter is set. In general this should not cause any interruption to the clusterware or databasesrunning on the database machines, thanks to the redundancy provided by ASM. However, you should beaware that if you have issues on other storage cells, it’s possible that restarting a cellsrv process couldcause an outage. Tracing can also be enabled on all storage servers by setting the hidden databaseparameter, _KCFIS_STORAGEIDX_DIAG_MODE to a value of 2. Since this tracing mechanism is completelyundocumented, it should not be used without approval from Oracle support. Better safe than sorry.Because the cellsrv process is multithreaded, the tracing facility creates many trace files. The resultis similar to tracing a select statement that is executed in parallel on a database server, in that there aremultiple trace files that need to be combined to show the whole picture. The naming convention for thetrace files is svtrc_, followed by a process ID, followed by a thread identifier. The process ID matches theoperating system process ID of the cellsrv process. Since cellsrv enables only 100 threads by default,the file names are reused rapidly as requests come into the storage cells. Because of this rapid reuse, it’squite easy to wrap around the thread number portion of the file name. Such wrapping around doesn’twipe out the previous trace file, but rather appends new data to the existing file. Appending happenswith trace files on Oracle database servers as well, but is much less common because the process IDportion of the default file name comes from the user’s shadow process. So basically each session gets itsown number.There is another related cellsrv parameter, _CELL_SI_MAX_NUM_DIAG_MODE_DUMPS, that sets amaximum number of trace files that will be created before the tracing functionality is turned off. Theparameter defaults to a value of 20. Presumably the parameter is a safety mechanism to keep the diskfrom getting filled by trace files, since a single query can create a large number of files.Here is a snippet from a trace file generated on our test system:Trace file/opt/oracle/cell11.2.2.2.0_LINUX.X64_101206.2/log/diag/asm/cell/enkcel03/trace/svtrc_13253_100.trcORACLE_HOME = /opt/oracle/cell11.2.2.2.0_LINUX.X64_101206.2System name: LinuxNode name: enkcel03.enkitec.comRelease: 2.6.18-194.3.1.0.3.el5108