OCA/OCP Oracle Database 11g All-in-One Exam Guide 866 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 PART III 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 OCA/OCP Oracle Database 11g All-in-One Exam Guide 868 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 PART III 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. OCA/OCP Oracle Database 11g All-in-One Exam Guide 870 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 PART III 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. OCA/OCP Oracle Database 11g All-in-One Exam Guide 872 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 PART III Figure 24-4 The ADDM report summary Figure 24-5 An ADDM recommendation to apply another advisor OCA/OCP Oracle Database 11g All-in-One Exam Guide 87 4 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 PART III 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. . OCA/ OCP Oracle Database 11g All-in-One Exam Guide 866 The manageability infrastructure provided with Oracle Database 11g can be used to automate a significant amount of the database administrator’s. a snapshot manually. The reports are purged by default after 30 days. OCA/ OCP Oracle Database 11g All-in-One Exam Guide 872 EXAM TIP ADDM reports are generated on demand, and whenever a snapshot. ADDM report summary Figure 24-5 An ADDM recommendation to apply another advisor OCA/ OCP Oracle Database 11g All-in-One Exam Guide 87 4 The Advisors The ADDM is the starting point for performance