[Database Probe] Alert Count=70 Zone 1 refresh=1 Zone 2 refresh=1 Zone 3 refresh=1 Zone 4 refresh=4 Zone 5 refresh=4 Redo

Alert Level=51 Datafiles Alert Level=81 Gauge color=32768 Gauge warning color=255 UseExpressionForHint=0 [Database Probe Alert_1] Name=Async IO Check Desc=Generally speaking, always set DISK_ASYNC_IO = TRUE. Even when DBWR_IO_SLAV ES > 0 or DB_WRITER_PROCESSES > 1. Only set DISK_AYNC_IO = FALSE when the platfo rm does not support asynchronous I/O or implements it inefficiently. Active=1 AlertControl=Async_IO_ LeftSideExpr=" Async_IO " RightSideExpr="0" RelationalOp== Refreshes=1 [Database Probe Alert_2] Name=DBWR Proc Slave Check Desc=Excessive DBWR activity has been requested by setting DB_WRITER_PROCESSES > 1 and DBWR_IO_SLAVES > 0. Generally speaking, you should either use multiple DB WR processes or DBWR slaves - but not both. Active=1 AlertControl=DBWR LeftSideExpr="( DBWR_Count - 1 ) * DBWR_Slaves " RightSideExpr="0" RelationalOp=> Refreshes=1 [Database Probe Alert_3] Name=DBWR Proc Count High Desc=Number of DBWR processes > 10 (the limit is 20). Verify that your hardware can actually handle that high an IO load. Active=1 AlertControl=DBWR_Count_ LeftSideExpr=" DBWR_Count " RightSideExpr="10" RelationalOp=> Refreshes=1 [Database Probe Alert_4] Name=DBWR Slave Count High Desc=Number of DBWR slave processes > 10 (there is no hard limit). Verify that y our hardware can actually handle that high an IO load. Active=1 AlertControl=DBWR_Slaves_ LeftSideExpr=" DBWR_Slaves " RightSideExpr="10" RelationalOp=> Refreshes=1 [Database Probe Alert_5] Name=Auditing Desc=Auditing has been activated via the INIT.ORA setting or an ALTER command. W hile there may be security requirements for doing this, gathering such internal database operations information does impose minimal overhead. Active=1

AlertControl=Overhead_Auditing LeftSideExpr=" Auditing_InitORA " RightSideExpr="0" RelationalOp=> Refreshes=1 [Database Probe Alert_6] Name=Timed OS Statistics Desc=Timed OS Statistics has been activated via the INIT.ORA or an ALTER command . While there may be tuning reasons for doing this, gathering such operating sys tem statistics is very expensive. Active=1 AlertControl=Overhead_Stats_OS LeftSideExpr=" Timed_Stats_OS_InitORA " RightSideExpr="0" RelationalOp=> Refreshes=1 [Database Probe Alert_7] Name=Timed Statistics Desc=Timed Statistics has been activated via the INIT.ORA or an ALTER command. W hile there may be tuning reasons for doing this, gathering such internal databas e statistics can be expensive. Active=1 AlertControl=Overhead_Stats_DB LeftSideExpr=" Timed_Stats_DB_InitORA " RightSideExpr="0" RelationalOp=> Refreshes=1 [Database Probe Alert_8] Name=Oracle Trace Desc=Oracle Trace has been enabled via the INIT.ORA or an ALTER command. While t here may be tuning reasons for doing this, permitting such internal database tra ce collections can be expensive. Active=1 AlertControl=Overhead_Trace_Oracle LeftSideExpr=" Trace_Enabled_Oracle_InitORA " RightSideExpr="0" RelationalOp=> Refreshes=1 [Database Probe Alert_9] Name=SQL Trace Desc=SQLTrace has been enabled via the INIT.ORA or an ALTER command. While there may be tuning reasons for doing this, gathering such detailed SQL trace informa tion imposes a severe performance impact. Active=1 AlertControl=Overhead_Trace_SQL LeftSideExpr=" Trace_Enabled_SQL_InitORA " RightSideExpr="0" RelationalOp=> Refreshes=1 [Database Probe Alert_10] Name=Statistics Level Desc=Statistics Level has been activated via the INIT.ORA or an ALTER command. W hile there may be tuning reasons for doing this, gathering both operating system and database statistics is expensive. Active=1 AlertControl=Overhead_Stats_Level LeftSideExpr=" Stats_Level_InitORA " RightSideExpr="0" RelationalOp=> Refreshes=1

[Database Probe Alert_11] Name=Lock SGA Desc=LOCK_SGA, which locks the entire SGA into physical memory, is not currently enabled. It is usually advisable to lock the SGA into real (physical) memory, e specially if the use of virtual memory would include storing some of the SGA usi ng disk space. This parameter is ignored on platforms that do not support it. Th is does not work for Oracle database instances on Windows. Active=1 AlertControl=SGA_Lock_ LeftSideExpr=" SGA_Lock " RightSideExpr="0" RelationalOp== Refreshes=1 [Database Probe Alert_12] Name=Session Cached Cursors Desc=SESSION_CACHED_CURSORS, which lets you specify the number of session cursor s to cache, is set to zero. Repeated parse calls of the same SQL statement cause the session cursor for that statement to be moved into the session cursor cache . Subsequent parse calls will find the cursor in the cache and need not reopen t he cursor. Oracle uses a least recently used algorithm to remove entries in the session cursor cache to make room for new entries when needed. Active=1 AlertControl=SGA_Session_Cached_Cursors LeftSideExpr=" Session_Cached_Cursors " RightSideExpr="0" RelationalOp== Refreshes=1 [Database Probe Alert_13] Name=Pre Page SGA Desc=PRE_PAGE_SGA, which determines whether all SGA pages are brought into memor y at instance startup, is currently not enabled. Operating system page table ent ries are then prebuilt for each page of the SGA. The resulting decrease in disk I/O may be offset by performance degradation in other areas. Therefore, this par ameter is most useful on systems that have sufficient memory to hold all the SGA pages without degrading performance in other areas. Active=1 AlertControl=SGA_Prepage LeftSideExpr=" Prepage " RightSideExpr="0" RelationalOp== Refreshes=1 [Database Probe Alert_14] Name=Cursor Space for Time Desc=CURSOR_SPACE_FOR_TIME, which lets you use more space for cursors in order t o save time, is currently not enabled. It affects both the shared SQL area and t he client's private SQL area. When set to TRUE, then shared SQL areas are kept p inned in the shared pool. As a result, shared SQL areas are not aged out of the pool as long as an open cursor references them. Because each active cursor's SQL area is present in memory, execution is faster. However, the shared SQL areas n ever leave memory while they are in use. Therefore, you should set this paramete r to TRUE only when the shared pool is large enough to hold all open cursors sim ultaneously. Active=1 AlertControl=SGA_Cursor_Space_For_Time LeftSideExpr=" Cursor_space_for_time " RightSideExpr="0" RelationalOp== Refreshes=1 [Database Probe Alert_15] Name=Java Pool Too Small

Desc=JAVA_POOL_SIZE, which specifies the size in bytes of the Java pool from whi ch the Java memory manager allocates most Java state during runtime execution, i s below Oracle's recommended minimum of 10-50 MB for dedicated servers and up to 100 MB for shared servers. This memory includes the shared in-memory representa tion of Java method and class definitions, as well as the Java objects that are migrated to the Java session space at end-of-call. Note - there is another alert you can use if you're not using Java. Active=1 AlertControl=Java_Pool_Megs_ LeftSideExpr=" Java_Pool_Megs " RightSideExpr="10" RelationalOp=< Refreshes=1 [Database Probe Alert_16] Name=Java Pool Not Needed Desc=JAVA_POOL_SIZE, which specifies the size in bytes of the Java pool from whi ch the Java memory manager allocates most Java state during runtime execution, i s not necessary if you're not going to use Oracle's Java Virtual Machine (JVM). In that case, you can safely set this parameter to zero. Note - there is another alert you can use if you're using Java. Active=0 AlertControl=Java_Pool_Megs_ LeftSideExpr=" Java_Pool_Megs " RightSideExpr="0" RelationalOp=> Refreshes=1 [Database Probe Alert_17] Name=Memory Sort Check Desc=The "In memory sort" percentage has fallen below the minimum threshold valu e set. For best performance in OLTP systems, most sorts should occur solely with in memory. DSS applications typically access large volumes of data and are thus expected to perform sorts to disk. Active=1 AlertControl=Efficiency_Mem_Sorts_ LeftSideExpr=" Efficiency_Mem_Sorts " RightSideExpr="80" RelationalOp=< Refreshes=1 [Database Probe Alert_18] Name=Index Usage Check Desc=The "Index Usage" percentage has fallen below the minimum threshold value s et. For best performance in OLTP systems, many if not most data accesses should be able to utilize indexes. DSS applications typically access large volumes of d ata and are thus expected to make somewhat less use of indexes on a percentage b asis. This is an arbitrary alert value to be defined by the user. The default tr iggers an alert when the index usage percentage falls below 80%. Active=1 AlertControl=Efficiency_Idx_Usage_ LeftSideExpr=" Efficiency_Idx_Usage " RightSideExpr="80" RelationalOp=< Refreshes=1 [Database Probe Alert_19] Name=ARCH Proc Not Running Desc=The ARCH process is not running and the database is in ARCHIVELOG mode. Thi s is a disaster waiting to happen. Once the Online Redo Log files fill up, the d atabase will come to a grinding halt. The database will not be able to perform a log switch from the Nth log file to the 1st log file as that file will be waiti ng to be backed up to secondary storage before it can be reused. Thus the entire database will become locked up.

Active=1 AlertControl=ARCH_ LeftSideExpr=" ARCH " RightSideExpr=" ArchiveLogMode " RelationalOp=< Refreshes=1 [Database Probe Alert_20] Name=ARCH Proc Count High Desc=Number of archive processes > 5 (the limit is 10). Verify that your hardwar e can actually handle that high an IO load. Active=1 AlertControl=ARCH_Count LeftSideExpr=" ARCH " RightSideExpr="5" RelationalOp=> Refreshes=1 [Database Probe Alert_21] Name=ARCH Proc Not Needed Desc=The ARCH process is running and the database is in NOARCHIVELOG mode. This means that you have ARCH processes running even though they will be doing no wor k. These processes are thus unnecessary and can be eliminated. Set LOG_ARCHIVE_S TART = FALSE in your INIT.ORA file. Active=1 AlertControl=Archive_Log_Mode LeftSideExpr="( ArchiveLogMode - 1 ) * ARCH " RightSideExpr="0" RelationalOp=< Refreshes=1 [Database Probe Alert_22] Name=Hourly Log Switch Rate High Desc=Your Online Redo Log file switch rate for the past hour greatly exceeds you r number of Redo Log Groups. This may present a problem as your archive processe s may not be able to copy the redo logs to secondary storage before they're need ed again, essentially resulting in a hung database. This also may indicate a muc h higher transaction load than originally anticpated and might warrant additiona l consideration regarding database configuration parameters set in the INIT.ORA file. Active=1 AlertControl=Log_Switches_Past_Hour_ LeftSideExpr=" Log_Switches_Past_Hour " RightSideExpr=" Redo_Log_Files_Groups * 2" RelationalOp=> Refreshes=1 [Database Probe Alert_23] Name=Daily Log Switch Rate High Desc=Your Online Redo Log file switch rate for the past day greatly exceeds your number of Redo Log Groups. This may present a problem as your archive processes may not be able to copy the redo logs to secondary storage before they're neede d again, essentially resulting in a hung database. This also may indicate a much higher transaction load than originally anticpated and might warrant additional consideration regarding database configuration parameters set in the INIT.ORA f ile. Active=1 AlertControl=Log_Switches_Past_Day_ LeftSideExpr=" Log_Switches_Past_Day " RightSideExpr=" Redo_Log_Files_Groups * 48" RelationalOp=> Refreshes=1 [Database Probe Alert_24] Name=Too Few Tablespaces

Desc=The database may have too few tablespaces. A typical Oracle database should have at least the following five tablespaces: SYSTEM, RBS or UNDO, TEMP, one fo r user data and one for user indexes. In fact, there should probably be separate tablespaces for user data and user indexes per application or major subject are a contained within that database. Active=1 AlertControl=Data_Files_Tablespaces_ LeftSideExpr=" Data_Files_Tablespaces " RightSideExpr="5" RelationalOp=< Refreshes=1 [Database Probe Alert_25] Name=Too Many Datafiles Desc=The database may have too many data files. A typical Oracle database should have just a few data files per tablespace. When a tablespace has lots of data f iles, it's often the case that the data file is being used as a generic containe r for too many unrelated objects. Active=1 AlertControl=Data_Files_Datafiles_ LeftSideExpr=" Data_Files_Datafiles " RightSideExpr=" Data_Files_Tablespaces * 2" RelationalOp=>= Refreshes=1 [Database Probe Alert_26] Name=Database Getting Big Desc=Total database data file size is getting relatively big. This is an arbitra ry alert value to be defined by the user. The default triggers an alert when the total database data file size passes half a terabyte. Active=1 AlertControl=Data_Files_Megs_ LeftSideExpr=" Data_Files_Megs " RightSideExpr="500000" RelationalOp=>= Refreshes=1 [Database Probe Alert_27] Name=Database Filling Up Desc=Total database data file percentage used is getting relatively tight. This is an arbitrary alert value to be defined by the user. The default triggers an a lert when the total database data file percentage used passes 80%. Active=1 AlertControl=Data_Files_Percent_Used_ LeftSideExpr=" Data_Files_Percent_Used " RightSideExpr="80" RelationalOp=>= Refreshes=1 [Database Probe Alert_28] Name=Too Few Redo Log Groups Desc=The database may have too few Online Redo Log Groups. A typical Oracle data base must have at least two groups, but you should strongly consider more than t wo groups - especially when the database is in ARCHIVELOG mode. This might prese nt a problem as your archive processes may not be able to copy the redo logs to secondary storage before they're needed again, essentially resulting in a hung d atabase. Active=1 AlertControl=Redo_Log_Files_Groups_ LeftSideExpr=" Redo_Log_Files_Groups " RightSideExpr="2" RelationalOp=<= Refreshes=1 [Database Probe Alert_29]

Name=Mismatched Redo Log Size Desc=The current Online Redo Log Group has a size that is different than the ave rage for all the other groups. While this is permitable, it is nonetheless unusu al. All the Online Redo Log Group and Member files should be the same size. It m akes redo log tuning and troubleshooting easier when all the redo log group and member file sizes are the same. Active=1 AlertControl=Redo_Log_Files_Current_ LeftSideExpr="" select bytes from v$log where group# = Redo_Log_Files_Current " " RightSideExpr="" select avg(bytes) from v$log where group# != Redo_Log_Files_Cu rrent "" RelationalOp=<> Refreshes=1 [Database Probe Alert_30] Name=Too Small Redo Log Size Desc=The Redo Log Group files appear to be of an average size that is smaller th an required to meet Oracle's recommendation of size in order to experience a log switch about every 30 minutes. This is an arbitrary alert value to be defined b y the user. The default triggers an alert when the average online redo log file size is less than 10 MB. Active=1 AlertControl=Redo_Log_Files_Megs_ LeftSideExpr=" Redo_Log_Files_Megs / Redo_Log_Files_Groups " RightSideExpr="10" RelationalOp=< Refreshes=1 [Database Probe Alert_31] Name=Disproportionate Redo Log Size Desc=The current Online Redo Log Group has a size that is disproportionately lar ger than normal. While this is permitable, it is nonetheless unusual. All the On line Redo Log Group and Member files should be the same size. It makes redo log tuning and troubleshooting easier when all the redo log group and member file si zes are the same. Active=1 AlertControl=Redo_Log_Files_Active_ LeftSideExpr=" Redo_Log_Files_Active " RightSideExpr="100 / Redo_Log_Files_Groups" RelationalOp=> Refreshes=1 [Database Probe Alert_32] Name=Session Usage Near Limit Desc=The database is nearing its maximum allowable session limit. This is an arb itrary alert value to be defined by the user. The default triggers an alert when the percetage of current sessions used exceeds 90% of the total sessions allowe d. Active=1 AlertControl=Sessions_Total_ LeftSideExpr=" Sessions_Used / Sessions_Max" RightSideExpr=".9" RelationalOp=>= Refreshes=1 [Database Probe Alert_33] Name=Too Few Active Sessions Desc=The database has relatively very few sessions that are currently active. Th is is an arbitrary alert value to be defined by the user. The default triggers a n alert when the percentage of active sessions falls below 10% of the current se ssions used. Active=1 AlertControl=Sessions_Active_

LeftSideExpr=" Sessions_Active / Sessions_Used " RightSideExpr=".1" RelationalOp=<= Refreshes=1 [Database Probe Alert_34] Name=Too Many Locked Sessions Desc=The database has relatively many sessions that are locked and waiting on re sources. This is an arbitrary alert value to be defined by the user. The default triggers an alert when the percentage of locked sessions exceeds 10% of the cur rent sessions used. Active=1 AlertControl=Sessions_Lock_Wait_ LeftSideExpr=" Sessions_Lock_Wait / Sessions_Used " RightSideExpr=".1" RelationalOp=>= Refreshes=1 [Database Probe Alert_35] Name=Process Usage Near Limit Desc=The database is nearing its maximum allowable process limit. This is an arb itrary alert value to be defined by the user. The default triggers an alert when the percentage of current processes used exceeds 90% of the total processes all owed. Active=1 AlertControl=Processes_Total_ LeftSideExpr=" Processes_Used / Processes_Max " RightSideExpr=".9" RelationalOp=>= Refreshes=1 [Database Probe Alert_36] Name=Shared Process Usage Near Limit Desc=The database is nearing its maximum allowable shared process limit. This is an arbitrary alert value to be defined by the user. The default triggers an ale rt when the percetage of current shared processes used exceeds 90% of the total shared processes allowed. Active=1 AlertControl=Processes_Shared LeftSideExpr=" Processes_Shared_Used / Processes_Shared_Max " RightSideExpr=".9" RelationalOp=>= Refreshes=1 [Database Probe Alert_37] Name=Dispatcher Process Usage Near Limit Desc=The database is nearing its maximum allowable dispatcher process limit. Thi s is an arbitrary alert value to be defined by the user. The default triggers an alert when the percentage of current dispatcher processes used exceeds 90% of t he total dispatcher processes allowed. Active=1 AlertControl=Processes_Dispatchers LeftSideExpr=" Processes_Dispatchers_Used / Processes_Dispatchers_Max " RightSideExpr=".9" RelationalOp=>= Refreshes=1 [Database Probe Alert_38] Name=Parallel Process Usage Near Limit Desc=The database is nearing its maximum allowable parallel process limit. This is an arbitrary alert value to be defined by the user. The default triggers an a lert when the percetage of current parallel processes used exceeds 90% of the to tal parallel processes allowed. Active=1 AlertControl=Processes_Parallel

LeftSideExpr=" Processes_Parallel_Used / Processes_Parallel_Max " RightSideExpr=".9" RelationalOp=>= Refreshes=1 [Database Probe Alert_39] Name=Too Few Background Procs Desc=The database appears to be missing some of the required background processe s. This is an arbitrary alert value to be defined by the user. The default trigg ers an alert when the background process count falls below 7. Note that this val ue is Oracle version dependent and that an older version of Oracle will require fewer minimum background processes. Active=1 AlertControl=Processes_Background_ LeftSideExpr=" Processes_Background " RightSideExpr="7" RelationalOp=< Refreshes=1 [Database Probe Alert_40] Name=Dedicated Servers in MTS DB Desc=Dedicated server processes have been detected in what appears to be a Multi -Threaded Server (MTS) database. While there is nothing inherently wrong with th is occuring, it may require DBA review to be sure that it's appropriate. For exa mple, certain DBA tasks require connecting to the database with a dedicated serv er and that may be what's happening. The real question is whether your applicati ons are coded to use the correct connection style for the MTS database. Active=1 AlertControl=Processes_Dedicated_ LeftSideExpr="Processes_Dispatchers_Used * Processes_Dedicated " RightSideExpr="0" RelationalOp=> Refreshes=1 [Database Probe Alert_41] Name=Excessive PGA Consumption Desc=The database has a relatively large amount of PGA memory allocated as compa red to the SGA. While there is nothing inherently wrong with this occuring, it m ay require DBA review to be sure that it's appropriate. For example, the DBA may have set certain INIT.ORA parameters like the SORT_AREA_SIZE and not realized t hey apply per process - including parallel slave processes. This is an arbitrary alert value to be defined by the user. The default triggers an alert when the p ercentage of PGA memory allocated exceeds 20% of the SGA memory allocated. Active=1 AlertControl=PGA_Size_ LeftSideExpr=" PGA_Allocated / SGA_Size " RightSideExpr=".2" RelationalOp=>= Refreshes=1 [Database Probe Alert_42] Name=Inefficient PGA Allocation Desc=The database is utilizing a relatively small portion of the PGA memory allo cated. While there is nothing inherently wrong with this occuring, it may requir e DBA review to be sure that it's appropriate. For example, the DBA may have set certain INIT.ORA parameters (e.g. SORT_AREA_SIZE) larger than necessary - resul ting in wasted memory. This is an arbitrary alert value to be defined by the use r. The default triggers an alert when the percentage of PGA memory used falls be low 60% of the PGA memory allocated. Active=1 AlertControl=PGA_Allocated_ LeftSideExpr=" PGA_Used / PGA_Max " RightSideExpr=".6" RelationalOp=<=

Refreshes=1 [Database Probe Alert_43] Name=Too Small SGA Allocation Desc=The SGA memory allocation is suspiciously small, which can result in poor d atabase performance. Oracle stores information in memory caches and on disk. Mem ory access is much faster than disk access. Disk scans (physical I/O) take a sig nificant amount of time, compared with memory access, typically in the order of 10 milliseconds. Physical I/O also increases the CPU resources required, because of the path length in device drivers and operating system event schedulers. For this reason, it is more efficient for data requests for frequently accessed obj ects to be satisfied solely by memory, rather than also requiring disk access. T his is an arbitrary alert value to be defined by the user. The default triggers an alert when the SGA allocated falls below 128 MB. Active=1 AlertControl=SGA_Size_ LeftSideExpr=" SGA_Size " RightSideExpr="128" RelationalOp=< Refreshes=1 [Database Probe Alert_44] Name=Overall DB Cache Waste Desc=The database is using a low percentage of the overall database buffer cache memory allocated. While there is nothing inherently wrong with this occuring, i t may require DBA review to be sure that it's appropriate. For example, the DBA may have set certain INIT.ORA parameters larger than is actually necessary - thu s less memory might be allocated while not negatively impacting the hit ratio. T his is an arbitrary alert value to be defined by the user. The default triggers an alert when the percentage of memory used falls below 60% of the memory alloca ted. Active=1 AlertControl=DB_Buffer_Cache_Overall LeftSideExpr=" DB_Buffer_Cache_Overall_Used / DB_Buffer_Cache_Overall_Max " RightSideExpr=".6" RelationalOp=<= Refreshes=1 [Database Probe Alert_45] Name=Default DB Cache Waste Desc=The database is using a low percentage of the default database buffer cache memory allocated. While there is nothing inherently wrong with this occuring, i t may require DBA review to be sure that it's appropriate. For example, the DBA may have set certain INIT.ORA parameters larger than is actually necessary - thu s less memory might be allocated while not negatively impacting the hit ratio. T his is an arbitrary alert value to be defined by the user. The default triggers an alert when the percentage of memory used falls below 60% of the memory alloca ted. Active=1 AlertControl=DB_Buffer_Cache_Default LeftSideExpr=" DB_Buffer_Cache_Default_Used / DB_Buffer_Cache_Default_Max " RightSideExpr=".6" RelationalOp=<= Refreshes=1 [Database Probe Alert_46] Name=Recycle DB Cache Waste Desc=The database is using a low percentage of the recycle database buffer cache memory allocated. While there is nothing inherently wrong with this occuring, i t may require DBA review to be sure that it's appropriate. For example, the DBA may have set certain INIT.ORA parameters larger than is actually necessary - thu s less memory might be allocated while not negatively impacting the hit ratio. T his is an arbitrary alert value to be defined by the user. The default triggers an alert when the percentage of memory used falls below 60% of the memory alloca

ted. Active=1 AlertControl=DB_Buffer_Cache_Recycle LeftSideExpr=" DB_Buffer_Cache_Recycle_Used / DB_Buffer_Cache_Recycle_Max " RightSideExpr=".6" RelationalOp=<= Refreshes=1 [Database Probe Alert_47] Name=Keep DB Cache Waste Desc=The database is using a low percentage of the keep database buffer cache me mory allocated. While there is nothing inherently wrong with this occuring, it m ay require DBA review to be sure that it's appropriate. For example, the DBA may have set certain INIT.ORA parameters larger than is actually necessary - thus l ess memory might be allocated while not negatively impacting the hit ratio. This is an arbitrary alert value to be defined by the user. The default triggers an alert when the percentage of memory used falls below 60% of the memory allocated . Active=1 AlertControl=DB_Buffer_Cache_Keep LeftSideExpr=" DB_Buffer_Cache_Keep_Used / DB_Buffer_Cache_Keep_Max " RightSideExpr=".6" RelationalOp=<= Refreshes=1 [Database Probe Alert_48] Name=Library Cache Waste Desc=The database is using a low percentage of the shared pool library cache cac he memory allocated. While there is nothing inherently wrong with this occuring, it may require DBA review to be sure that it's appropriate. For example, the DB A may have set certain INIT.ORA parameters larger than is actually necessary - t hus less memory might be allocated while not negatively impacting the hit ratio. This is an arbitrary alert value to be defined by the user. The default trigger s an alert when the percentage of memory used falls below 60% of the memory allo cated. Active=1 AlertControl=Shared_Pool_Lib_Cache LeftSideExpr=" Shared_Pool_Lib_Cache_Used / Shared_Pool_Lib_Cache_Used " RightSideExpr=".6" RelationalOp=<= Refreshes=1 [Database Probe Alert_49] Name=Shared Pool Too Small 1 Desc=The shared pool is probably too small. The main components of the shared po ol are the library cache and the dictionary cache. The library cache stores the executable (parsed or compiled) form of recently referenced SQL and PL/SQL code. The dictionary cache stores data referenced from the data dictionary. A cache m iss on the data dictionary cache or library cache is more expensive than a miss on the buffer cache. For this reason, the shared pool should be sized to ensure that frequently used data is cached. A number of features make large memory allo cations in the shared pool: for example, the shared server, parallel query, or R ecovery Manager. Oracle recommends segregating the SGA memory used by these feat ures by configuring a distinct memory area, called the large pool. This is an ar bitrary alert value to be defined by the user. The default triggers an alert whe n the shared pool size falls below 40 MB. Active=1 AlertControl=Shared_Pool_Overall LeftSideExpr=" Shared_Pool_Overall_Total " RightSideExpr="40" RelationalOp=<= Refreshes=1 [Database Probe Alert_50]

Name=Low Dict Cache Allocation Desc=The dictionary cache is probably too small. The dictionary cache stores dat a referenced from the data dictionary. A cache miss on the data dictionary cache or library cache is more expensive than a miss on the buffer cache. For this re ason, the shared pool should be sized to ensure that frequently used data is cac hed. However, many of the caches in the shared pool automatically increase or de crease in size as needed, including the library cache and the dictionary cache. This is an arbitrary alert value to be defined by the user. The default triggers an alert when the cache size size falls below 2 MB. Active=1 AlertControl=Shared_Pool_Dict_Cache LeftSideExpr=" Shared_Pool_Dict_Cache_Total " RightSideExpr="2" RelationalOp=< Refreshes=1 [Database Probe Alert_51] Name=Low SQL Area Allocation Desc=The SQL area is probably too small. When an application makes a parse call for a SQL statement, if the parsed representation of the SQL statement does not already exist in the library cache or if it has been previously parsed but aged out of the cache then Oracle parses the statement and stores the parsed form in the SQL area. This is known as a hard parse. Resources required for a hard parse include additional CPU, library cache latch gets, and shared pool latch gets. S o it's desirable to perform soft parses. This is an arbitrary alert value to be defined by the user. The default triggers an alert when the SQL area size size f alls below 8 MB. Active=1 AlertControl=Shared_Pool_SQL_Area LeftSideExpr=" Shared_Pool_SQL_Area_Total " RightSideExpr="8" RelationalOp=< Refreshes=1 [Database Probe Alert_52] Name=Excess Shared Pool Free Desc=The database has a large percentage of the shared pool free memory. While t here is nothing inherently wrong with this occuring, it may require DBA review t o be sure that it's appropriate. For example, the DBA may have set certain INIT. ORA parameters larger than is actually necessary. This is an arbitrary alert val ue to be defined by the user. The default triggers an alert when the percentage of shared pool free memory exceeds 40% of the shared pool memory allocated. Active=1 AlertControl=Shared_Pool_Free LeftSideExpr=" Shared_Pool_Free_Total / Shared_Pool_Overall_Total " RightSideExpr=".4" RelationalOp=>= Refreshes=1 [Database Probe Alert_53] Name=Low Large Pool Allocation Desc=The large pool is probably too small. A number of features make large memor y allocations in the shared pool: for example, the shared server (MTS), parallel query, or Recovery Manager. Oracle recommends segregating the SGA memory used b y these features by configuring a distinct and properly sized memory area, calle d the large pool. This is an arbitrary alert value to be defined by the user. Th e default triggers an alert when the large pool size falls below 8 MB. Active=1 AlertControl=Large_Pool_Megs_ LeftSideExpr=" Large_Pool_Megs " RightSideExpr="8" RelationalOp=< Refreshes=1

[Database Probe Alert_54] Name=Too Small Large Pool 1 Desc=The large pool is probably too small. A number of features make large memor y allocations in the shared pool: for example, the shared server (MTS), parallel query, or Recovery Manager. Oracle recommends segregating the SGA memory used b y these features by configuring a distinct and properly sized memory area, calle d the large pool. This is an arbitrary alert value to be defined by the user. Th e default triggers an alert when the low large pool used percentage exceeds 80% of the large pool size. Active=1 AlertControl=Large_Pool_Cur_Used_ LeftSideExpr=" Large_Pool_Cur_Used / Large_Pool_Megs " RightSideExpr=".8" RelationalOp=>= Refreshes=1 [Database Probe Alert_55] Name=Too Small Large Pool 2 Desc=The large pool is probably too small. A number of features make large memor y allocations in the shared pool: for example, the shared server (MTS), parallel query, or Recovery Manager. Oracle recommends segregating the SGA memory used b y these features by configuring a distinct and properly sized memory area, calle d the large pool. This is an arbitrary alert value to be defined by the user. Th e default triggers an alert when the high large pool used percentage exceeds 80% of the large pool size. Active=1 AlertControl=Large_Pool_Max_Used_ LeftSideExpr=" Large_Pool_Max_Used / Large_Pool_Megs " RightSideExpr=".8" RelationalOp=>= Refreshes=1 [Database Probe Alert_56] Name=Low Overall DB Cache Hit Ratio Desc=The database is currently experiencing a low percentage of overall database buffer cache hit ratio. This may translate to slower database performance since Oracle may be doing more physical IO than if a larger cache were allocated. As a general rule, investigate increasing the size of the cache if the cache hit ra tio is low and your application has been tuned to avoid performing full table sc ans. This is an arbitrary alert value to be defined by the user. The default tri ggers an alert when the hit ratio percentage falls below 85%. Active=1 AlertControl=DB_Buffer_Cache_Overall_Hit_ LeftSideExpr=" DB_Buffer_Cache_Overall_Hit " RightSideExpr="85" RelationalOp=< Refreshes=1 [Database Probe Alert_57] Name=Low Default DB Cache Hit Ratio Desc=The database is currently experiencing a low percentage of default database buffer cache hit ratio. This may translate to slower database performance since Oracle may be doing more physical IO than if a larger cache were allocated. As a general rule, investigate increasing the size of the cache if the cache hit ra tio is low and your application has been tuned to avoid performing full table sc ans. This is an arbitrary alert value to be defined by the user. The default tri ggers an alert when the hit ratio percentage falls below 85%. Active=1 AlertControl=DB_Buffer_Cache_Default_Hit_ LeftSideExpr=" DB_Buffer_Cache_Default_Hit " RightSideExpr="85" RelationalOp=< Refreshes=1

[Database Probe Alert_58] Name=Low Keep DB Cache Hit Ratio Desc=The database is currently experiencing a low percentage of keep database bu ffer cache hit ratio. This may translate to slower database performance since Or acle may be doing more physical IO than if a larger cache were allocated. As a g eneral rule, investigate increasing the size of the cache if the cache hit ratio is low and your application has been tuned to avoid performing full table scans . This is an arbitrary alert value to be defined by the user. The default trigge rs an alert when the hit ratio percentage falls below 85%. Note - the DBA may si mply have allocated a keep pool and not placed any objects into it or the applic ations may not be accessing keep pool objects. Active=1 AlertControl=DB_Buffer_Cache_Keep_Hit_ LeftSideExpr=" DB_Buffer_Cache_Keep_Hit " RightSideExpr="85" RelationalOp=< Refreshes=1 [Database Probe Alert_59] Name=Low Recycle DB Cache Hit Ratio Desc=The database is currently experiencing a low percentage of recycle database buffer cache hit ratio. This may translate to slower database performance since Oracle may be doing more physical IO than if a larger cache were allocated. As a general rule, investigate increasing the size of the cache if the cache hit ra tio is low and your application has been tuned to avoid performing full table sc ans. This is an arbitrary alert value to be defined by the user. The default tri ggers an alert when the hit ratio percentage falls below 85%. Note - the DBA may simply have allocated a recycle pool and not placed any objects into it or the applications may not be accessing recycle pool objects. Active=1 AlertControl=DB_Buffer_Cache_Recycle_Hit_ LeftSideExpr=" DB_Buffer_Cache_Recycle_Hit " RightSideExpr="85" RelationalOp=< Refreshes=1 [Database Probe Alert_60] Name=Excessive Redo Log Buffer Size Desc=The redo log buffer appears to be too large. Applications that insert, modi fy, or delete large volumes of data usually need to change the default log buffe r size. The log buffer is small compared with the total SGA size, and a modestly sized log buffer can significantly enhance throughput on systems that perform m any updates. A reasonable first estimate for such systems is to make the log buf fer 1 MB. On most systems, sizing the log buffer larger than 1 MB does not provi de any performance benefit. Increasing the log buffer size does not have any neg ative implications on performance or recoverability. It merely uses extra memory . Active=1 AlertControl=Redo_Log_Buffer_Megs_ LeftSideExpr=" Redo_Log_Buffer_Megs " RightSideExpr="1" RelationalOp=> Refreshes=1 [Database Probe Alert_61] Name=Excessive Redo Allocation Retries Desc=The value of redo buffer allocation retries should be near zero over an int erval. If this value increments consistently, then processes have had to wait fo r space in the redo log buffer. The wait can be caused by the log buffer being t oo small or by checkpointing. Increase the size of the redo log buffer, if neces sary, by changing the value of the initialization parameter LOG_BUFFER. Alterna tively, improve the checkpointing or archiving process. Active=1

AlertControl=Redo_Log_Buffer_Retries_ LeftSideExpr=" Redo_Log_Buffer_Retries " RightSideExpr="0" RelationalOp=> Refreshes=2 [Database Probe Alert_62] Name=Excessive Redo Allocation Waits Desc=The value of redo buffer allocation waits should be near zero over an inter val. If this value increments consistently, then processes have had to wait for space in the redo log buffer. The wait can be caused by the log buffer being too small or by checkpointing. Increase the size of the redo log buffer, if necessa ry, by changing the value of the initialization parameter LOG_BUFFER. Alternati vely, improve the checkpointing or archiving process. Active=1 AlertControl=Redo_Log_Buffer_Waits_ LeftSideExpr=" Redo_Log_Buffer_Waits " RightSideExpr="0" RelationalOp=> Refreshes=2 [Database Probe Alert_63] Name=Shared Pool Too Small 2 Desc=The shared pool is probably too small. The main components of the shared po ol are the library cache and the dictionary cache. The library cache stores the executable (parsed or compiled) form of recently referenced SQL and PL/SQL code. The dictionary cache stores data referenced from the data dictionary. A cache m iss on the data dictionary cache or library cache is more expensive than a miss on the buffer cache. For this reason, the shared pool should be sized to ensure that frequently used data is cached. A number of features make large memory allo cations in the shared pool: for example, the shared server, parallel query, or R ecovery Manager. Oracle recommends segregating the SGA memory used by these feat ures by configuring a distinct memory area, called the large pool. This is an ar bitrary alert value to be defined by the user. The default triggers an alert whe n the miscellaneous shared pool components size exceed 40% of the shared pool. Active=1 AlertControl=Shared_Pool_Misc LeftSideExpr=" Shared_Pool_Misc_Total / Shared_Pool_Overall_Total " RightSideExpr=".4" RelationalOp=>= Refreshes=1 [Database Probe Alert_64] Name=Low Dict Cache Hit Ratio Desc=The database is currently experiencing a low percentage of dictionary cache hit ratio. This may translate to slower database performance since Oracle may b e doing more physical IO than if a larger cache were allocated. This is an arbit rary alert value to be defined by the user. The default triggers an alert when t he hit ratio percentage falls below 95%. Note - the hit ratio may be less than 9 5% after initial database startup as the cache is empty, but should stabilize ar ound the desired percentage after a short while. Active=1 AlertControl=Shared_Pool_Dict_Cache_Hit_ LeftSideExpr=" Shared_Pool_Dict_Cache_Hit " RightSideExpr="95" RelationalOp=< Refreshes=1 [Database Probe Alert_65] Name=Low Library Cache Hit Ratio Desc=The database is currently experiencing a low percentage of library cache hi t ratio. This may translate to slower database performance since Oracle may be d oing more physical IO than if a larger cache were allocated. Specifically, this means that SQL statements that are needed are being "aged out" of the cache. Thi

s is an arbitrary alert value to be defined by the user. The default triggers an alert when the hit ratio percentage falls below 85%. Active=1 AlertControl=Shared_Pool_Lib_Cache_Hit_ LeftSideExpr=" Shared_Pool_Lib_Cache_Hit " RightSideExpr="85" RelationalOp=< Refreshes=1 [Database Probe Alert_66] Name=High Block Mods Ratio Desc=The database is experiencing a period of relatively high block modification versus get activity. This is usually the case during a high volume data load or other period of unusual insert/update activity. While there is nothing inherent ly wrong with this, the DBA may still want to examine the overall database load and see if there are jobs that can be scheduled so as not to overlap. This is an arbitrary alert value to be defined by the user. The default triggers an alert when the block mods to get ratio exceeds 25%. Active=1 AlertControl=Block_Mods_Sec_ LeftSideExpr=" Block_Mods_Sec " RightSideExpr=" .25 * Block_Gets_Sec " RelationalOp=> Refreshes=2 [Database Probe Alert_67] Name=High Physical Writes Ratio Desc=The database is experiencing a period of relatively high physical write ver sus read activity. This is usually the case during a high volume data load or ot her period of unusual insert/update activity. While there is nothing inherently wrong with this, the DBA may still want to examine the overall database load and see if they are jobs that can be scheduled so as not to overlap. This is an arb itrary alert value to be defined by the user. The default triggers an alert when the physical writes to reads ratio exceeds 25%. Active=1 AlertControl=Physical_Writes_Sec LeftSideExpr=" Phys_wr_sec " RightSideExpr=".25 * Phys_rd_sec " RelationalOp=> Refreshes=2 [Database Probe Alert_68] Name=Excessive Log Writer Writes Desc=The database is experiencing a period of relatively high log writer activit y. This is usually the case during a high volume data load or other period of un usual insert/update activity. While there is nothing inherently wrong with this, the DBA may still want to examine the overall database load and see if there ar e jobs that can be scheduled so as not to overlap. This is an arbitrary alert va lue to be defined by the user. The default triggers an alert when the log writer writes per second exceeds 1000. Active=1 AlertControl=LGWR_Count LeftSideExpr=" LGWR_wr_sec " RightSideExpr="1000" RelationalOp=> Refreshes=2 [Database Probe Alert_69] Name=Excessive Physical Reads Desc=The database is experiencing a period of relatively high physical read acti vity. This is usually the case during any period of unusually high select activi ty or if there is excessive full table scan activity. While there is nothing inh erently wrong with this, the DBA may still want to examine the overall database load and see if there are jobs that can be scheduled so as not to overlap. This

is an arbitrary alert value to be defined by the user. The default triggers an a lert when the physical reads per second exceeds 5000. Active=1 AlertControl=Physical_Reads_Sec LeftSideExpr=" Phys_rd_sec " RightSideExpr="5000" RelationalOp=> Refreshes=2 [Database Probe Alert_70] Name=Excessive Block Gets Desc=The database is experiencing a period of relatively high block get activity . This is usually the case during any period of unusually high select activity o r if there is excessive full table scan activity. While there is nothing inheren tly wrong with this, the DBA may still want to examine the overall database load and see if there are jobs that can be scheduled so as not to overlap. This is a n arbitrary alert value to be defined by the user. The default triggers an alert when the block gets per second exceeds 5000. Active=1 AlertControl=Block_Gets_Sec_ LeftSideExpr=" Block_Gets_Sec " RightSideExpr="5000" RelationalOp=> Refreshes=2