Database Probe

[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
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
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
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
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
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
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
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
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
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

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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Name=Process Usage Near Limit
Desc=The database is nearing its maximum allowable process limit. This is an arb
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
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
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
Name=Parallel Process Usage Near Limit
Desc=The database is nearing its maximum allowable parallel process limit. This
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
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
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
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
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
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
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
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
Name=Default DB Cache Waste
Desc=The database is using a low percentage of the default database buffer cache
ted.
Active=1
AlertControl=DB_Buffer_Cache_Default
LeftSideExpr=" DB_Buffer_Cache_Default_Used / DB_Buffer_Cache_Default_Max "
RightSideExpr=".6"
RelationalOp=<=
Refreshes=1
Name=Recycle DB Cache Waste
Desc=The database is using a low percentage of the recycle database buffer cache
ted.
Active=1
AlertControl=DB_Buffer_Cache_Recycle
LeftSideExpr=" DB_Buffer_Cache_Recycle_Used / DB_Buffer_Cache_Recycle_Max "
RightSideExpr=".6"
RelationalOp=<=
Refreshes=1
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
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
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
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
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
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
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

Name=Too Small Large Pool 1
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
Name=Too Small Large Pool 2
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
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
Name=Low Default DB Cache Hit Ratio
Desc=The database is currently experiencing a low percentage of default database
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

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
Name=Low Recycle DB Cache Hit Ratio
Desc=The database is currently experiencing a low percentage of recycle database
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
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
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
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
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
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
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
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
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
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
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 "
RelationalOp=>
Refreshes=2
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

lert when the physical reads per second exceeds 5000.
Active=1
AlertControl=Physical_Reads_Sec
LeftSideExpr=" Phys_rd_sec "
RelationalOp=>
Refreshes=2
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 "
RelationalOp=>
Refreshes=2

Database Probe

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Database Probe

Uploaded by

Copyright:

Available Formats

[Database Probe]

[Database Probe Alert_11]

Name=Mismatched Redo Log Size

LeftSideExpr=" Sessions_Active / Sessions_Used "

LeftSideExpr=" Processes_Parallel_Used / Processes_Parallel_Max "

Name=Low Dict Cache Allocation

[Database Probe Alert_54]

[Database Probe Alert_58]

s is an arbitrary alert value to be defined by the user. The default triggers an

is an arbitrary alert value to be defined by the user. The default triggers an a

You might also like