Tài liệu OCA: Oracle Database 11g Administrator Certified Associate- P20 ppt

On the EM Database Control home screen, click the Performance tab, and click the Run ASH Report button, as shown in Figure 14.13... Using EM Database Control to View ADDM Analysis EM Dat

SQL>

SQL> exec dbms_stats.gather_table_stats(null, ‘customers’, method_opt=>’for all columns size skewonly’);

PL/SQL procedure successfully completed

SQL> select column_name, num_distinct, histogram

2 from user_tab_col_statistics 3* where table_name = ‘CUSTOMERS’

SQL> /COLUMN_NAME NUM_DISTINCT HISTOGRAM - - -CUST_NAME 47692 HEIGHT BALANCEDCUST_STATE 6 FREQUENCYCUST_COUNTRY 3 FREQUENCYSYS_STUZVS6GX30A0GN_5YRYSD2LPM 8 FREQUENCY

SQL> select * from customers where cust_country = ‘India’ and cust_state =

1 - filter(“CUST_STATE”=’TN’ AND “CUST_COUNTRY”=’India’)

As you can see in the example, before extended statistics were collected, the estimated number of rows was 1447, whereas after the extended statistics collection, the number of rows optimizer estimated to return is 86.

To drop the extend statistics, use the DROP_EXTENDED_STATISTICS procedure:

SQL> exec dbms_stats.drop_extended_stats(null,’CUSTOMERS’, ‘(CUST_COUNTRY, CUST_STATE)’);

PL/SQL procedure successfully completed

SQL>

To define the extension and collect statistics in one step, you can do the following:

SQL> exec dbms_stats.gather_table_stats(null, ‘customers’, method_opt=>’for all columns size skewonly for columns (cust_country, cust_state)’);

PL/SQL procedure successfully completed

SQL> select extension_name, extension from user_stat_extensions

2 where table_name = ‘CUSTOMERS’;

EXTENSION_NAME EXTENSION - -SYS_STUZVS6GX30A0GN_5YRYSD2LPM (“CUST_COUNTRY”,”CUST_STATE”)

In the next section, you’ll learn to enable and disable the automatic statistics collection

as well as perform other AutoTask jobs

Configuring Automated Maintenance Tasks Using EM

The following are three default automated maintenance tasks:

Gathering optimizer statistics

Û N

Running the Segment Advisor

Û N

Running the SQL Tuning Advisor

Û N

You can also enable and disable the AutoTask jobs using EM Grid Control On the Server tab, choose Automated Maintenance Tasks under Oracle Scheduler Figure 14.8 shows the Automated Maintenance Tasks screen

By clicking the Configure button, you can enable or disable the default AutoTask jobs, as well as adjust the days on which these tasks are run, as shown in Figure 14.9

To learn more about Automated Maintenance Tasks and Oracle Scheduler,

read the “Oracle Database Administrator’s Guide 11g Release 1 (11.1) Part

Number B28310-04” Oracle documentation

F i g u r e 14 8 Automated Maintenance Tasks screen

F i g u r e 14 9 Configure Automated Maintenance Tasks screen

Gathering Performance Statistics

Oracle Database generates several performance statistics that are used for self-tuning purposes and are available for administrators to better tune the database Most of the performance statistics information is available through V$ dictionary views (also known as dynamic

performance views) The information in the V$ views are not persistent; that is, tion is lost when the database is shut down Automatic Workload Repository (AWR) saves the performance information in system tables and is made available for analysis through

informa-EM Database Control and other third-party tools AWR information is persistent across database shutdowns

The AWR data is captured at a system or database level, and session-level information is captured using another mechanism called the Active Session History (ASH) You will learn about AWR and ASH in the following sections

Using Automatic Workload Repository

Two background processes are responsible for collecting the performance statistics:

Memory Monitor (MMON) and Memory Monitor Light (MMNL) These processes work together to collect performance statistics directly from the system global area (SGA) The MMON process does most of the work by waking up every 60 minutes and gathering statistical information from the data dictionary views, dynamic performance views, and optimizer and then storing this information in the database The tables that store these sta-tistics are the Automatic Workload Repository These tables are owned by the user SYSMAN

and are stored in the SYSAUX tablespace

To activate the AWR feature, you must set the pfile/spfile’s parameter STATISTICS_LEVEL

to the appropriate value The values assigned to this parameter determine the depth of the statistics that the MMON process gathers Table 14.3 shows the values that can be assigned

to the STATISTICS_LEVEL parameter

ta b l e 14 3 Specifying Statistics Collection Levels

Collection Level Description

BASIC Disables the AWR and most other diagnostic monitoring and advisory

activities Few database statistics are gathered at each collection val when operating the instance in this mode.

inter-TYPICAL Activates the standard level of collection activity This is the default

value for AWR and is appropriate for most environments.

ALL Captures all the statistics gathered by the TYPICAL collection level, plus

the execution plans and timing information from the operating system.

Once gathered, the statistics are stored in the AWR for a default duration of eight days

However, you can modify both the frequency of the snapshots and the duration for which they are saved in the AWR One way to modify these intervals is by using the Oracle-supplied package DBMS_WORKLOAD_REPOSITORY The following SQL command shows the DBMS_WORKLOAD_

REPOSITORY package being used to change the AWR collection interval to 1 hour and the retention period to 30 days:

SQL> execute dbms_workload_repository.modify_snapshot_settings (interval=>60,retention=>43200);

PL/SQL procedure successfully completed

The 30-day retention value shown here is expressed in minutes: 60 minutes per hour × 24 hours per day × 30 days = 43,200 minutes.

You can also change the AWR collection interval, retention period, and collection depth using EM Database Control Choose the Server tab, and click Automatic Workload Reposi-tory under Statistics Management (see Figure 14.10)

F i g u r e 14 10 AWR statistics collection and retention using EM

Click the Edit button to change the settings, as shown in Figure 14.11

F i g u r e 14 11 Changing AWR statistics collection and retention using EM

In Figure 14.11, the retention period for statistics gathered by the MMON process is set

to 15 days, and statistics are collected every 30 minutes You can also modify the depth at which statistics are collected by the AWR by clicking the Collection Level link Clicking this link opens the Initialization Parameters screen where you can specify any of the three predefined collection levels shown in Table 14.3 Figure 14.12 shows the AWR collection level being changed from TYPICAL to ALL

F i g u r e 14 12 Changing the AWR statistics collection level

Take care when specifying the AWR statistics collection interval ering snapshots too frequently requires additional space in the SYSAUXtablespace and adds database overhead each time the statistics are col- lected AWR does not use any space in the SGA.

Gath-Using EM Database Control, you can view the AWR report Click the Run AWR Report ton on the Automatic Workload Repository screen shown earlier in Figure 14.10 You can get the same report using SQL*Plus by running the script $ORACLE_HOME/rdbms/admin/awrrpt.sql You can manage the AWR snapshots with SQL*Plus by utilizing the DBMS_WORKLOAD_

but-REPOSITORY package, as described in the next section

Managing AWR Snapshots Manually

You can create AWR snapshots by using the CREATE_SNAPSHOT procedure, as shown here:

SQL> SELECT snap_id, begin_interval_time, end_interval_time

Once AWR snapshots are taken and stored in the database, the Automatic Database Diagnostic feature uses the AWR data, as described in the “Automatic Database Diagnostic Monitoring” section.

Active Session History

ASH is sampled data at specified intervals from the current state of all active sessions The data is collected in memory and can be accessed by V$ views The ASH information is also written to a persistent store by the AWR snapshots

The V$ACTIVE_SESSION_HISTORY provides the information collected by the ASH sampler

The sessions are sampled every second and are stored in a circular buffer in SGA Each session is stored as a row The current and historical information is available in the data dictionary view DBA_HIST_ACTIVE_SESS_HISTORY ASH information also includes the execu-tion plan for each SQL captured

Oracle provides a script to generate an ASH report, $ORACLE_HOME/rdbms/admin/

ashrpt.sql You will be prompted for the report type (HTML or text), the begin time in minutes prior to SYSDATE, the duration in minutes for the report, and a name for the report

You can also use EM Database Control to generate the ASH report

On the EM Database Control home screen, click the Performance tab, and click the Run ASH Report button, as shown in Figure 14.13

F i g u r e 14 13 Performance screen in EM Database Control

The screen shown in Figure 14.14 captures parameters for the ASH report Specify the start time and end time for the report, and click the Generate Report button

F i g u r e 14 14 ASH report parameters

Any session that is connected to the database and does not wait for a wait event that belongs to the idle wait class is considered as an active session.

AWR Baselines

It is a good practice to baseline your database when everything is working as expected

When things go south, you can use this baseline to compare system statistics and

perfor-mance metrics AWR baselines contain perforperfor-mance data from a specific time period that

is preserved for comparison when problems occur This baseline data is excluded from the AWR purging process

You can create two types of baselines: a single baseline and a repeating baseline A single

baseline is captured at a single fixed-time interval, such as October 5 between 10 a.m and

1 p.m A repeating baseline repeats during a time interval for a specific period, such as every Friday between 10 a.m and 1 p.m You can create and delete AWR baselines using

EM Database Control or SQL*Plus

Managing AWR Baselines Using SQL*Plus

To create a single baseline, use the CREATE_BASELINE procedure as shown in the following code You can include the optional expiration parameter to automatically delete the snap-shot after the specified number of days

To drop a baseline, use the DROP_BASELINE procedure as shown in the following code

The cascade parameter specifies that only the baseline should be dropped, not the shots associated with the baseline

SQL>

You can create a baseline for the future date and time These are called baseline templates

The following code creates a baseline template:

SQL> BEGIN

2 DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE_TEMPLATE(

3 start_time => TO_DATE(‘01-JAN-09 05.00.00’,’DD-MON-YY HH.MI.SS’),

4 end_time => TO_DATE(‘01-JAN-09 08.00.00’,’DD-MON-YY HH.MI.SS’),

SQL>

AWR baselines and baseline templates are never dropped automatically (or purged) from the database unless explicitly dropped by the DBA or the expiration period ends.

Managing AWR Baselines Using EM Database Control

Using EM Database Control to create, rename, and drop AWR baselines is easier than using SQL*Plus and error-free From the database home page, click the Server tab (shown

earlier in Figure 14.1) Click the AWR Baselines link under Statistics Management The current baselines are displayed, as shown in Figure 14.15.

F i g u r e 14 15 AWR Baselines screen

Click the Create button to create a new baseline You will be presented with the option

to create a single baseline or a repeating baseline If you choose a single baseline, you will

be presented with the screen shown in Figure 14.16 Enter the name of the baseline You can specify the snapshots to include in the baseline by using the snapshot IDs or using a time range

F i g u r e 14 16 AWR Create Single Baseline screen

If you choose to create a repeating baseline, you’ll see the screen shown in Figure 14.17

Enter a baseline name, and specify the frequency

F i g u r e 14 17 AWR Create Repeating Baseline screen

You can drop a baseline by choosing the baseline and clicking the Delete button on the AWR Baselines screen (Figure 14.15)

Automatic Database Diagnostic Monitoring

Following each AWR statistics-collection process, the Automated Database Diagnostic

Monitoring (ADDM) feature automatically analyzes the gathered statistics and compares

them to the statistics gathered by the previous two AWR snapshots By comparing the rent statistics to these two previous snapshots, the ADDM can easily identify potential database problems such as these:

cur-CPU and I/O bottlenecks

Û N

Resource-intensive SQL or PL/SQL or Java execution

Û N

Lock contention

Û N

Utilization of Oracle’s memory structures within the SGA

Û N

RAC-specific issues

Û N

Issues with Oracle Net configuration

Û N

Data-concurrency issues

Û N

Based on these findings, the ADDM may recommend possible remedies The goal of these recommendations is to minimize DB Time DB Time is composed of two types of time measures for nonidle database users: CPU time and wait time This information is stored as the cumulative time that all database users have spent either using CPU resources

or waiting for access to resources such as CPU, I/O, or Oracle’s memory structures High

or increasing values for DB Time indicate that users are requesting increasingly more server resources and may also be experiencing waits for those resources, which can lead to less than optimal performance In this way, minimizing DB Time is a much better way to mea-sure overall database performance than Oracle’s old ratio-based tuning methodologies

DB Time is calculated by combining all the times from all nonidle user sions into one number Therefore, it is possible for the DB Time value to be larger than the total time that the instance has been running.

ses-Once ADDM completes its comparison of the newly collected statistics to the previously collected statistics, the results are stored in the AWR You can use these statistics to establish baselines against which future performance will be compared, and you can use deviations from these baseline measures to identify areas that need attention In this manner, ADDM allows you to not only better detect and alert yourself to potential management and per-formance problems in the database but also allows you to automatically take corrective actions to rectify those problems quickly and with little or no manual intervention

The following sections introduce the interfaces, features, and functionality of ADDM and explain how you can use this utility to monitor and manage database storage, security, and performance We’ll begin by examining the EM Database Control tools you can use to view the results of ADDM analysis

Using EM Database Control to View ADDM Analysis

EM Database Control graphically displays the results of the ADDM analysis on several screens, including the following:

The Performance Findings link under the Diagnostic Summary section of the EM

Û N

Database Control main screenThe Performance tab of the EM Database Control main screen

Û N

The ADDM screen located by clicking the Advisor Central link at the bottom of the

Û N

EM Database Control main screenYou’ll see sample output from each of the EM Database Control screens in the following sections

The EM Database Control Performance Findings Link

The EM Database Control home screen contains a section called Diagnostic Summary One

of the links under this section is ADDM Findings Figure 14.18 shows this section

F i g u r e 14 18 The Diagnostic Summary section of the EM Database Control home

screen

The output in Figure 14.18 shows that ADDM discovered four performance-related findings Clicking the link for these four performance findings displays the ADDM sum-mary screen, at the bottom of which is the Performance Analysis section, as shown in Figure 14.19

The Findings section on this screen shows the ADDM analysis and the recommendation

to resolve the issue

F i g u r e 14 19 ADDM summary screen

The EM Database Control Performance Tab

You can also click the Performance tab on the EM Database Control main screen to view performance data collected by AWR and analyzed by ADDM You can click the Run ADDM Now button to take an AWR snapshot and perform ADDM analysis Figure 14.20 shows the Performance tab of EM Database Control

F i g u r e 14 2 0 EM Database Control Performance tab

Using Active Sessions of the Performance tab, you can drill down into detailed tion that has been identified as having an impact on performance Click the Scheduler link, which will take you to the screen shown in Figure 14.21

informa-F i g u r e 14 21 Detailed performance information

The Advisor Central Screen

The Advisor Central screen also contains ADDM findings The link for the Advisor Central screen is at the bottom of the EM Database Control home screen Click this link to display the Advisor Central screen, shown in Figure 14.22

Click the ADDM link in the Advisors section of this screen to display a graph that shows all the recent AWR snapshots taken by the MMON process

As stated earlier, the ADDM automatically compares the most recent AWR snapshot with the last two AWR snapshots when formulating its recommendations However, you can use this Create ADDM Task screen to manually select any two AWR snapshot times and formulate ADDM recommendations for activity that occurred between those two points in time To start this process, click the Period Start Time radio button, and then select a start date and time by clicking the point in the graph’s timeline that corresponds to the beginning period that you want to use Repeat this process to specify the end-process timestamp

You can also manually perform an ADDM analysis without EM Database Control by using the addmrpt.sql script located in the $ORACLE_HOME/

rdbms/admin directory.

F i g u r e 14 2 2 The Advisor Central screen

You can use the DBMS_ADDM package to manually analyze AWR snapshots Table 14.4 shows some of the subprograms in DBMS_ADDM that can be used to manually manage ADDM analysis

ta b l e 14 4 Partial List of DBMS_ADDM Subprograms

Procedure Name Description

ANALYZE_DB Creates an ADDM analysis by specifying the begin and

end AWR snapshot IDs

INSERT_FINDING_DIRECTIVE Excludes certain findings from ADDM reportingINSERT_SEGMENT_DIRECTIVE Excludes a certain schema, object, or segment from ADDM

reporting (do not run Segment Advisor on these segments)INSERT_SQL_DIRECTIVE Excludes certain SQL from ADDM reporting

The DBA_ADVISOR_FINDINGS, DBA_ADVISOR_RECOMMENDATIONS, and DBA_

ADVISOR_ACTIONS dictionary views have a column named FILTERED If the value for this column is Y, the row in the view is filtered by a directive and

is not reported.

Although using EM Database Control to create and view ADDM results is by far the simplest way to review ADDM recommendations, you can also query the ADDM data dictionary views directly I’ll discuss some of these data dictionary views in the following section

Using Data Dictionary Views to View ADDM Analysis

You can use more than 20 data dictionary views to examine the results of ADDM’s ties Table 14.5 describes five commonly used ADDM views that store the recommendation information you saw in the EM Database Control pages

activi-ta b l e 14 5 ADDM Daactivi-ta Dictionary Views

DBA_ADDM_TASKS Displays executed advisor tasksDBA_ADDM_FINDINGS Describes the findings identified by the ADDM analysisDBA_ADVISOR_OBJECTS Describes the objects that are referenced in the ADDM

findings and recommendationsDBA_ADVISOR_RECOMMENDATIONS Describes the recommendations made based on ADDM

findingsDBA_ADVISOR_RATIONALE Describes the rationale behind each ADDM finding

DBA_ADDM_TASKS, DBA_ADDM_INSTANCES, and DBA_ADDM_FINDINGS are sions of the corresponding DBA_ADVISOR_ views but are specific for ADDM tasks and findings.

exten-The following SQL statement shows a sample query on the DBA_ADVISOR_FINDINGS data dictionary view that identifies the type of performance problem that is causing the most impact on the database:

SQL> SELECT task_id, type, message

2 FROm dba_advisor_findings

3 WHERE impact= (select MAX(impcat) FROM dba_advisor_findings);

TASK_ID TYPE MESSAGE - - -

164 PROBLEM SQL statements consuming significant database time were found

The output from this query shows that SQL statements being executed in the database are contributing to the poor database performance By itself, the DBA_ADVISOR_FINDINGS

table does not identify which SQL statements are consuming the database time Instead, these are shown in the DBA_ADVISOR_OBJECTS data dictionary view and are identified by the

TASK_ID value shown in the query on DBA_ADVISOR_FINDINGS A query on that view, using the TASK_ID of 164 returned by the ADDM session that had the potential for the greatest database impact, returns the SQL statements shown here:

SQL> SELECT attr4

2 FROM dba_advisor_objects

3 WHERE task_id = 164;

ATTR4 -UPDATE customers SET credit_limit=credit_limit*1.15 WHERE cust_id = :B1DELETE FROM sales WHERE time_id BETWEEN ’01-JAN-00’ and ’01-JAN-01’;

UPDATE sales_history SET quantity_sold = quantity_sold+10 WHERE CHANNEL_ID := B1

SELECT COUNT(*) FROM Sales_history;

SELECT DISTINCT channel_id FROM sales_history;

This query shows all the SQL statements that were captured by the AWR during the snapshot period and that were used in the ADDM analysis for that same period

The DBA_ADVISOR_ACTIONS data dictionary view shows the ADDM recommendations for each finding The following query shows the recommendations for correcting the performance issues associated with TASK_ID 164, which was identified earlier as being the costliest database activity:

SQL> SELECT TRIM(attr1) ATTR1, TRIM(attr2) ATTR2, TRIM(attr3) ATTR3

2 FROM dba_advisor_actions

3 WHERE task_id = 164;

ATTR1 ATTR2 ATTR3 - - -log_buffer 262144 15728640

This output indicates that ADDM recommends that the values for LOG_BUFFER, DB_

CACHE_SIZE, and UNDO_RETENTION all be changed from their current values to 15,728,640 bytes; 50,331,648 bytes; and 363 seconds, respectively

If you want to see the rationale behind each of the actions shown in DBA_ADVISOR_ACTIONS, query the DBA_ADVISOR_RATIONALE data dictionary view The DBA_ADVISOR_RATIONALE view stores the ADDM recommendations that ADDM has formulated based on the AWR data like those stored in DBA_ADVISOR_FINDINGS and DBA_ADVISOR_OBJECTS The following example shows a sample query on the DBA_ADVISOR_RATIONALE view using the TASK_ID of 164 identi-fied earlier:

SQL> SELECT message

2 FROM dba_advisor_rationale

3 WHERE task_id = 164;

MESSAGE -Buffer cache writes due to small log files were consuming significant database time

The buffer cache was undersized causing significant read I/O

The value of “undo retention” was 900 seconds and the longest running query lasted only 330 seconds This extra retention caused

unnecessary I/O

As you can see from the complexity of these examples, examining the ADDM results via EM Database Control is much easier than accessing the data dictionary views via SQL From a practical standpoint, you would run SQL queries against these ADDM views only if EM Database Control were unavailable.

To gain further insight into the recommendations and information gathered by the

ADDM, Oracle 11g also provides several advisor utilities in EM Database Control I will

discuss these advisors in the next section

The Advisory Framework

Oracle 11g comes with several advisors to help proactively manage the database The top portion of Figure 14.22 shows the advisors available in Oracle 11g and how to invoke them

Advisors provide recommendations that are key for a DBA to manage the database tively The advisors can be classified into various categories The following are the advisors:

effec-Memory

Û N

SGA Advisor

Û N

PGA Advisor

Û N

Shared Pool Advisor

Û N

Buffer Cache Advisor

Û N

SQL

Û N

SQL Tuning Advisor

Û N

SQL Access Advisor

Û N

Automatic Undo Management

Û N

Undo Advisor

Û N

Recovery

Û N

MTTR Advisor

Û N

Data Recovery Advisor

Û N

Space

Û N

Segment Advisor

Û N

The purpose of each advisor is explained next Since the OCA certification exam expects you to only be familiar with the general purpose of the advisors, I won’t go into detail of each advisor in this book You can click each advisor’s link on the Advisor Central screen and familiarize yourself with the contents

Memory advisors Memory advisors provide the optimal size for various memory

param-eters If AMM is enabled, the advisor provides the target amount of memory to allocate to the instance If AMM is disabled but ASMM is enabled, the advisor provides recommenda-tions on the optimal sizes for SGA and PGA If no automatic memory features are enabled, you can get the sizes for individual SGA components such as shared pool and buffer cache

AMM and ASMM are discussed later in the chapter

SQL Tuning Advisor This provides SQL tuning advice You may use the top activity or

current session’s graphs to drill down to the SQL statement to tune You can tune one ment or multiple statements The advice includes restructuring SQL statements, creating additional indexes, using materialized views, partitioning tables, refreshing the optimizer statistics, and so on

state-SQL Access Advisor The state-SQL Access Advisor provides recommendations on schema

mod-ifications It recommends indexes and materialized views to optimize SQL queries

Undo Advisor The Undo Advisor recommends the optimal size for the undo tablespace

based on the undo retention and flashback requirements

MTTR_TARGET initialization parameter This parameter determines the amount of time required by the instance to start in the event of an instance crash Instance failure can occur when the host server crashes, when any critical SGA background process fails, or if the instance is shut down using the ABORT option Instance recovery occurs automatically

on the first startup following the instance failure During instance recovery, Oracle uses the online redo logs to roll back any uncommitted transactions that were “in flight” when the instance crashed to ensure that all committed transactions are written to disk As a DBA, you often try to minimize the time it takes to perform this instance recovery so that you can bring up the database quickly

Data Recovery Advisor The Data Recovery Advisor helps diagnose and repair data

fail-ures and corruptions It analyzes the failure based on the symptoms and determines the repair strategies

Segment Advisor The Segment Advisor identifies whether a segment is a good candidate

for a shrink operation based on the level of fragmentation within the segment The advisor also keeps historical growth of the segment, which can be used for capacity planning Seg-ments that can be shrunk are those that the Segment Advisor has found to need less space than they are currently allocated By shrinking or compressing these segments, space is returned to the database for use by other objects, and the total number of I/Os needed to access these objects is reduced, potentially improving the performance of SQL statements that access these objects

In the next section, you’ll learn about another tool in the Oracle 11g database that helps

you proactively monitor the database with timely alerts

Monitoring Server-Generated Alerts

In addition to monitoring and making recommendations on SQL, memory, mean time to

recover, segments, and undo activity, an Oracle 11g database can also proactively monitor

itself for other types of problems related to configuration, security, and space management

To do so, you use the server-generated alerts feature

A server-generated alert is an alert from the Oracle 11g database that says it suspects a

problem with the database These alerts are also an integral part of the ADDM ture They notify you when a management or performance issue occurs and begin taking corrective actions—if you configured such actions By default, the alert notifications are sent to a predefined persistent queue named ALERT_QUE owned by SYS EM Grid Control reads this queue

architec-There are two types of server-generated alerts: threshold based and event based Threshold

alerts are triggered when a specified threshold is met, such as when a tablespace has reached certain capacity Threshold alerts can be fired at a warning level (for example, 85 percent

tablespace capacity) or at a critical level (for example, 97 percent tablespace capacity) Event

alerts are triggered when a specified event occurs, such as a database error

Viewing and Configuring Alerts Using EM Database Control

The EM Database Control home page displays the alerts when they are triggered

Figure 14.23 shows the Alerts section of the Database Control home page

F i g u r e 14 2 3 Alerts section of the Database Control home page

You can see the alert history by clicking the Alert link You can configure the alerts by clicking the Metric and Policy Settings link under Related Links Figure 14.24 shows the top portion of the Metric and Policy Settings screen

F i g u r e 14 2 4 Metric and Policy Settings screen

As you can see in Figure 14.24, each alert can have two levels of severity: Warning and Critical These two alert levels allow you to achieve greater granularity For example, you might want two thresholds set up with regard to the archive destination One might be a warning threshold that triggers an alert when the archive destination is 80 percent full—

causing a message to be displayed on the EM Database Control main screen In addition, you might want to set up a critical threshold so that you receive an email whenever the archive destination device is 90 percent full In this manner, you can escalate a potential problem from an EM Database Control console message to an email alert as the problem gets worse

You can also use warning and critical alerts to distinguish between severity problems, such as statistics indicating temporary poor perfor- mance, and higher-severity problems, such as ORA-0600 error messages

lower-in the database alert log You can achieve this by deflower-inlower-ing warnlower-ing olds only for lower-severity alerts and defining warning and critical alerts for higher-severity problems.

thresh-Viewing and Configuring Alerts Using SQL

You can use SQL*Plus to configure the alert thresholds and to view the alerts The DBMS_

SERVER_ALERT package has the subprograms to define and query the thresholds The SET_

THRESHOLD procedure is used to define the threshold, and the GET_THRESHOLD procedure is used to retrieve threshold information

You can also query the thresholds from the DBA_THRESHOLDS dictionary view The lowing is an example:

fol-SQL> SELECT metrics_name, warning_value, critical_value

2 FROM dba_thresholds

3 WHERE metrics_name like ‘Tablespace%’

SQL> /METRICS_NAME WARNING_VA CRITICAL_V - - -Tablespace Bytes Space Usage 0 0

Tablespace Space Usage 85 97SQL>

Threshold alerts are written to DBA_OUTSTANDING_ALERTS Nonthreshold alerts are ten only to DBA_ALERT_HISTORY Entries from DBA_OUTSTANDING_ALERTS are cleared when the alert condition is cleared The following is a query from the DBA_OUTSTANDING_ALERTS view:

writ-SQL> SELECT reason FROM dba_outstanding_alerts;

REASON -db_recovery_file_dest_size of 4395630592 bytes is 97.27%

used and has 119794176 remaining bytes available

Metrics “Database Time Spent Waiting (%)” is at 36.84571 for event class “Concurrency”

The V$METRIC view shows system-level metric values Metric history is saved in the

V$METRIC_HISTORY view

So far, you have seen several tools that help DBAs proactively monitor the database I cannot possible identify all the potential issues and how to proactively avoid them Errors

and database corruptions do happen The Oracle 11g database has a reporting mechanism

to analyze the problem reactively and take measures to avoid it in the future You’ll learn about the Automatic Diagnostic Repository in the next section

Understanding Automatic Diagnostic Repository

The Automatic Diagnostic Repository (ADR) is a file-based repository for database tic data such as alert log files, trace files, core dump files, health monitor reports, and so on

diagnos-In prior releases of Oracle, the trace and dump files were traditionally saved in directories specified by the _DUMP_DIRECTORY parameters Starting with Oracle 11g, these files and much

more are saved under the ADR framework

ADR replaces the BACKGROUND_DUMP_DEST, CORE_DUMP_DEST, and USER_DUMP_DEST tions A new parameter, DIAGNOSTIC_DEST, specifies the base directory for the ADR The default for DIAGNOSTIC_DEST is $ORACLE_BASE if available; otherwise, it’s $ORACLE_HOME/log ADR is a vast topic and is not covered here in its entirety

loca-Within ADR base, there can be multiple ADR homes Each ADR home is the base tory for all the files belonging to an instance The ADR home directory for an instance is

direc-$DIAGNOSTIC_DEST/diag/rdbms/<dbname>/<instance name>.The subdirectories under the DIAGNOSTIC_DEST are as follows:

DIAGNOSTIC_DEST/diag DIAGNOSTIC_DEST/diag rdbms tnslsnr

<db_name> <machine_name>

<instance_name> <listener_name>

alert alert cdump cdump

hm incident incident incpkg incpkg lck

ir metadata lck stage metadata sweep stage trace sweep

trace