OCA /OCP Oracle Database 11g A ll-in-One Exam Guide- P92 pps

This information is accumulated in memory and periodically written to the database: to the tables that make up the Automatic Workload Repository, the AWR.. To administer the AWR with Dat

The manageability infrastructure provided with Oracle Database 11g can be used to

automate a significant amount of the database administrator’s day-to-day work With earlier releases, monitoring the database in order to pick up developing problems before they became critical took too much time Identifying and diagnosing performance issues was not only time-consuming but also required much skill Use of the Alert

system and the diagnostic advisors, installed as standard in every 11g database, frees

the DBA from the necessity of devoting a large amount of effort to this work

The Automatic Workload Repository

Oracle collects a vast amount of statistical information regarding performance and activity This information is accumulated in memory and periodically written to the database: to the tables that make up the Automatic Workload Repository, the AWR The AWR exists as a set of tables and other objects in the SYSAUX tablespace The AWR

is related to the data dictionary, but unlike the data dictionary, the AWR is not essential for the database to function (though it may be necessary for it to function well) Data

is written to the AWR, stored for a while, and eventually overwritten with more recent information

Gathering AWR Statistics

The level of statistics gathered is controlled by the instance parameter STATISTICS_ LEVEL This can be set to BASIC, or to TYPICAL (which is the default), or to ALL The TYPICAL level will force the collection of all the statistics that are needed for normal tuning, without collecting any whose collection would impact adversely on performance The BASIC level will disable virtually all statistics, with no appreciable performance benefit The ALL level will collect extremely detailed statistics on SQL statement execution; these may occasionally be necessary if you are doing advanced SQL statement tuning, but they may cause a slight performance drop while being collected

Statistics are accumulated in memory, in data structures within the SGA This causes

no performance impact, because the statistics merely reflect what the instance is doing anyway Periodically (by default, once an hour) they are flushed to disk, to the AWR

This is known as an AWR snapshot The flushing to disk is done by a background process:

the Manageability Monitor, or MMON This use of a background process is the key

to the efficiency of the statistics collection process In earlier releases of the database, accessing performance tuning statistics was only possible by running queries against various views—the dynamic performance V$ views Populating these views was an expensive process The DBA had to launch a session against the database and then issue a query The query forced Oracle to extract data from the SGA and present it

to the session in a view This approach is still possible—all the old views, and many more, are still available—but the AWR approach is far more efficient

TIP No third-party tool can ever have the direct memory access to the

instance that MMON has If your instance is highly stressed, you should think carefully before using any tuning products other than those provided by Oracle

Chapter 24: The AWR and the Alert System

867

The MMON has direct access to the memory structures that make up the SGA, and

therefore the statistics within them It can extract data from the SGA without the need

to go via a session The only overhead is the actual writing of the snapshot of the data

to the AWR By default this occurs only once an hour and should not therefore have a

noticeable effect on runtime performance

EXAM TIP AWR statistics are saved as a snapshot to the AWR by the MMON

process, by default every 60 minutes By default, the snapshots are stored for

eight days before being overwritten

The AWR is a set of tables located in the SYSAUX tablespace—these tables cannot

be relocated They exist in the SYSMAN schema You can log on to the database with

tools such as SQL*Plus as user SYSMAN, but this should never be necessary, and indeed

Oracle Corporation does not support access to the AWR tables with SQL*Plus, or with

any tools other than the various APIs provided in the form of DBMS packages or through

various views The most straightforward way to access AWR information is through

Enterprise Manager; both Enterprise Manager Database Control and Enterprise Manager

Grid Control log on to the database as SYSMAN, using a password that is encrypted in

their configuration files This is why changing the SYSMAN password requires more

than executing an ALTER USER SYSMAN IDENTIFIED BY command; in addition

to this, you must also use the EMCTL utility:

emctl setpasswd dbconsole

which will update the encrypted password in the appropriate file

An AWR snapshot can be thought of as a copy of the contents of many V$ views at

the time the snapshot was taken, but never forget that the mechanism for copying the

information is not to query the V$ views: the information is extracted directly from the

data structures that make up the instance The process that makes the copy is MMON

In addition to information from the dynamic performance views, the AWR stores

information otherwise visible in the DBA views, populated from the data dictionary

This category of information includes a history of object statistics Without the AWR,

the database would have no long-term record of how objects were changing The statistics

gathered with DBMS_STATS provide current information, but it may also be necessary to

have a historical picture of the state of the database objects The AWR can provide this

Managing the AWR

Snapshots of statistics data are kept in the AWR, by default, for eight days This period

is configurable As a rough guide for sizing, if the snapshot collection is left on every

hour and the retention time is left on eight days, then the AWR may well require

between 200MB and 300MB of space in the SYSAUX tablespace But this figure is

highly variable and will to a large extent depend on the number of sessions

To administer the AWR with Database Control, from the database home page select

the Server tab, then the Automatic Workload Repository link in the Statistics Management

section The Automatic Workload Repository window, as in Figure 24-1, shows the

current settings for snapshot collection and retention and for the STATISTICS_LEVEL and lets you adjust them

Adjusting the AWR settings to save snapshots more frequently will make problem diagnosis more precise If the snapshots are several hours apart, you may miss peaks

of activity (and consequent dips in performance) But gathering snapshots too frequently will increase the size of the AWR and could possibly impact performance due to the increased workload of collecting and saving the information

TIP It is important to monitor the size and growth of the SYSAUX tablespace

and the AWR within it The Alert system will assist with the first task, and the view V$SYSAUX_OCCUPANTS should be used for the second

EXAM TIP By default, AWR snapshots are taken every hour and saved for

eight days The AWR is located in the SYSAUX tablespace and cannot be relocated to anywhere else

Figure 24-1 The AWR administration window

Chapter 24: The AWR and the Alert System

869

Statistics, Metrics, and Baselines

AWR snapshots contain statistics What Oracle calls a statistic is a raw figure, which is

meaningless by itself To be useful, statistics must be converted into metrics A metric

is two or more statistics correlated together For example, the number of disk reads

is a statistic; perhaps the number is two billion By itself, this is useless information

What the DBA needs to know are metrics such as disk reads per second, disk reads per

transaction, disk reads per SQL statement, and disk reads per session The DBA will

also need to do further correlations For example, disk reads per transaction is very

useful; it will identify the transactions that are stressing the I/O system and perhaps

should be tuned But the DBA will need to observe this metric over time and see how

it changes—perhaps as the SQL is rewritten or indexing structures are changed, the

I/O workload will reduce This introduces the baseline A baseline is a stored set of

statistics (and metrics) that can be used for comparisons across time

As the MMON process saves an AWR snapshot, it automatically generates a large

number of metrics from the statistics Creating baselines must be done by the DBA

Snapshots are purged after a certain period—by default, after eight days A baseline

is a pair (possibly several pairs) of snapshots that will be kept indefinitely: until the

baseline is deliberately dropped The metrics derived from the baseline can then be

compared with the metrics derived from current activity levels, assisting you with

identifying changes in activity and behavior

Baselines need to be created for specific events and for normal running For example,

if the database has regular end-of-month processing, it would make sense to store the

AWR snapshots gathered during each month end as baselines so that throughout the

year you can observe how the month-end processing activity is changing and determine

whether any problems are apparent It also makes sense to store baselines for periods of

normal, satisfactory running so that if performance degrades at a later time, information

will be available that will help identify what might have changed

To create a baseline with Database Control, select the link next to “Baselines” shown

in Figure 24-1 In the figure, this link is “1,” indicating that at the moment there is

only one baseline This link will take you to the AWR Baselines window From there,

you can define periods to store as baselines

The DBMS_WORKLOAD_REPOSITORY Package

Database Control has interfaces for managing the AWR, but it does so by invoking

procedures in a PL/SQL package: DBMS_WORKLOAD_REPOSITORY The procedures

can adjust the frequency and persistence of snapshots, generate an ad hoc snapshot

(additional to those generated by MMON), create and manipulate baselines, and

generate reports on activity between any two snapshots Figure 24-2 shows the use

of some of the procedures in the package

The first procedure call forces the MMON process to gather a snapshot immediately,

in addition to its normal scheduled snapshots This would typically be used just before and after launching a job of some kind, so that reports can be generated focusing on a particular time frame The second procedure call adjusts the snapshot management, such that snapshots will be retained for 30 days and gathered by MMON every half hour (the units are minutes) The third procedure call nominates two snapshots to be stored indefinitely as a named baseline Finally, the query lists all snapshots in the repository; note that in addition to the snapshots gathered automatically on the hour, there is also the ad hoc snapshot gathered by the first procedure call

Exercise 24-1: Monitor the Automatic Workload Repository In this exercise, you will determine the size of the AWR and monitor its growth as it stores more snapshots

1 Connect to your database with SQL*Plus as user SYSTEM

2 The view V$SYSAUX_OCCUPANTS shows all the components installed into the SYSAUX tablespace Find out how much space the AWR is taking up:

select occupant_desc,space_usage_kbytes from v$sysaux_occupants where occupant_name='SM/AWR';

Note the size returned.

3 Gather an AWR snapshot:

execute dbms_workload_repository.create_snapshot;

4 Rerun the query from Step 2, and calculate the increase in size caused by taking the manual snapshot

Figure 24-2 Use of the DBMS_WORKLOAD_REPOSITORY package

Chapter 24: The AWR and the Alert System

871

5 Find out how many snapshots there are, and what date range they cover:

select min(begin_interval_time), max(begin_interval_time),

count(snap_id) from dba_hist_snapshot;

6 Connect to your database as user SYSTEM with Database Control

7 Navigate to the Automatic Workload Repository window, shown in Figure 24-1:

from the database home page select the Server tab, and then the Automatic

Workload Repository link in the Statistics Management section You will see

figures corresponding to the results of the query in Step 5

The Database Advisory Framework

The database comes preconfigured with a set of advisors First among these is the

Automatic Database Diagnostic Monitor, or ADDM Studying ADDM reports, which

are generated automatically whenever an AWR snapshot is taken, will usually be a

regular part of the DBA’s routine The ADDM reports themselves are of great value and

will highlight problems within the database and suggest solutions, but in many cases,

its recommendations will include suggesting that you run one or more other advisors

These advisors can give much more precise diagnostic information and advice than

the ADDM

To use the advisors, in Database Control click the Advisor Central link in the

Related Links section The Advisor Central window gives you the options of viewing

the results of previous advisor tasks, or of using any of the other advisors:

• The Automatic Database Diagnostic Monitor (the ADDM)

• The Memory Advisors

• The SQL Access, Tuning, and Repair Advisors

• The Automatic Undo Advisor

• The Mean Time to Recover (MTTR) Advisor

• The Data Recovery Advisor

• The Segment Advisor

The Automatic Database Diagnostic Monitor

The ADDM is run automatically by the MMON whenever a snapshot is taken As with

all the advisors, it takes statistics and other information from the AWR The automatically

generated ADDM reports always cover the period between the current snapshot and

the previous one—so by default, you will have access to reports covering every hour

You can invoke the ADDM manually to generate a report covering the period between

any two snapshots, if you want to span a greater period The ADDM is triggered both

by automatic snapshots and also if you gather a snapshot manually The reports are

purged by default after 30 days

EXAM TIP ADDM reports are generated on demand, and whenever a

snapshot is gathered By default, they are stored for 30 days

To view the ADDM reports with Database Control, click the Advisor Central link

in the Related Links section of the database home page The Advisor Central window will show you the most recent runs of each advisor, as in Figure 24-3

Select the report’s radio button and click View Result to see the summary of recent activity, as in Figure 24-4 In the figure, this shows that overall the database has seen very little activity since the previous evening, but that there were distinct spikes at about 23:00 and 07:00, as well as in the last hour since 14:00, which will be the period covered by this report

The lower part of the ADDM window shows the results of the analysis In the figure, ADDM has detected issues with virtual memory, with the SQL being executed, and with disk I/O Clicking the links would show detail of the finding

The ADDM will often recommend running another advisor In the example shown

in Figure 24-4, selecting the Top SQL By DB Time link shows the result in Figure 24-5, which identifies the SQL statements that were stressing the system and recommends running the SQL Tuning Advisor against them

Figure 24-3 Advisor Central

Chapter 24: The AWR and the Alert System

873

Figure 24-4 The ADDM report summary

Figure 24-5 An ADDM recommendation to apply another advisor

The Advisors

The ADDM is the starting point for performance analysis and problem resolution, and it may well give all the advice needed Its recommendations include

• Hardware changes (such as adding CPUs)

• Database configuration (such as instance parameter settings)

• Schema changes (such as use of table and index partitioning)

• Application changes (such as using bid variables)

• Using other advisors (for more detailed analysis and recommendations) Other chapters describe some of the other advisors in greater detail Following are summary descriptions

The Memory Advisors

The memory advisors predict the effect of varying the size of memory structures, reporting the estimates in terms of processing time saved (the Shared Pool, Java Pool, and Streams Pool Advisors), disk activity reduced (the Database Buffer Cache Advisor),

or both (the PGA Advisor) There is no advisor for the Large Pool There is, however,

an SGA Advisor, which will report on the effect of varying the size of the entire SGA If memory management has been automated by setting the parameter MEMORY_TARGET and leaving all other memory parameters on default, there is an overall memory advisor that provides a single point from which to gauge whether allocating more memory to the instance would improve performance

The SQL Advisors

There are three SQL advisors: the SQL Access Advisor, the SQL Tuning Advisor, and the SQL Repair Advisor

The SQL Access Advisor will observe a workload of SQL statements and make recommendations regarding segments that would improve the execution speed of the workload The workload can be a hypothetical workload, or it can be derived from the SQL actually executed during a certain time frame The recommendations may include: creating or dropping indexes and materialized views, or to make use

of segment partitioning

The SQL Tuning Advisor can analyze individual statements; and as well as

recommending schema changes (as the Access Advisor does), it can recommend generating additional statistics on the statement’s execution that will assist the

optimizer in choosing the best execution plan, and rewriting the statement to

eliminate some inefficiencies that are inherent in some SQL structures

Occasionally, a SQL statement can fail because of an internal Oracle error This will be reported with the “ORA-600” error message If the error condition (which is a polite name for a “bug”) is only encountered when following a particular execution plan, it follows that using a different execution plan could avoid the failure The SQL Repair Advisor can investigate this and generate a patch to the statement that will force the optimizer to choose a safe plan, rather than a plan that hits the problem

Chapter 24: The AWR and the Alert System

875

The Automatic Undo Advisor

The Undo Advisor will observe the rate of undo data generation and the length of

queries being run, and it will recommend a minimum size for the undo tablespace,

which will ensure that queries do not fail with a “snapshot too old” error

The Mean Time to Recover (MTTR) Advisor

The mechanism for instance recovery after a failure is detailed in Chapter 14 In

summary, if the instance terminates in a disorderly fashion (such as a power cut or

server reboot while the database was open, or just a SHUTDOWN ABORT), then on

the next startup it is necessary to reinstate all work in progress that had not been

written to the datafiles at the time of the crash This will happen automatically, but

until it is done, users cannot log on The MTTR Advisor estimates how long this

period of downtime for crash recovery will be, given the current workload

The Data Recovery Advisor

If the database has been damaged in some way (such as files deleted or data blocks

corrupted), it may take some time to identify the problem There will often be several

ways of recovering from the situation For example, if a number of datafiles have been

damaged by corruptions appearing on a disk, it will be necessary to find out which

files and which blocks A decision must then be made as to whether to restore entire

files or only the damaged blocks If the database is protected by a physical standby,

switching over to that would also be a possibility

Following a failure, any DBA (no matter how experienced) will need time to

determine the nature and extent of the problem, and then more time to decide upon

the course of action that will repair the damage with the minimum disruption to

work The Data Recovery Advisor follows an expert system to advise the DBA on this

The expert system is essentially what the DBA would follow anyway, but the advisor

can do it much faster

The Segment Advisor

Segments grow automatically As rows are inserted into table segments and index keys

are inserted into index segments, the segments fill—and then Oracle will allocate more

extents as necessary But segments do not shrink automatically as data is removed or

modified with DELETE and UPDATE commands; this only happens when the segment

is deliberately reorganized The Segment Advisor observes tables and indexes, both

their current state and their historical patterns of use, and recommends appropriate

reorganization when necessary

Automatic Maintenance Jobs

If the database is to run well, it is vital that the optimizer has access to accurate object

statistics; that the tables and indexes are operating efficiently, without a large amount

of wasted space and fragmentation; and that the high-load SQL statements have been

tuned The gathering of statistics and the running of the Segment Advisor and the SQL

Tuning Advisor are, by default, automatic in an 11g database.