OCA /OCP Oracle Database 11g A ll-in-One Exam Guide- P93 ppt

OCA/OCP Oracle Database 11g All-in-One Exam Guide 87 6 The Scheduler (described in Chapter 22) runs jobs automatically, at certain times and repeatedly at certain intervals. The jobs will usually be defined by the DBA, but following creation of a database with the DBCA, there will be three tasks configured within what is called the AutoTask system. These AutoTasks are • Gathering optimizer statistics • Running the Segment Advisor • Running the SQL Advisor The AutoTasks run within the Scheduler’s maintenance windows. The maintenance windows are defined to open at 22:00 every weeknight and to close four hours later, at 02:00, and on Saturday and Sunday to open at 06:00, closing 20 hours later, at 02:00. The Scheduler is linked to another database facility: the Resource Manager, described in Chapter 21. The Resource Manager plan that is activated during the maintenance window is one that ensures that no more than 25 percent of machine resources are dedicated to the AutoTask jobs, meaning that running these tasks should not impact adversely on other work. If the maintenance window time frames are not suitable for your database workload, they are adjustable; if the maximum of 25 percent resource usage is too high and causes performance for other work to degrade, this too can be changed. The underlying assumption is that the AutoTasks will run at a time and with a priority that is unlikely to cause problems for regular work for end users. EXAM TIP There are three automated maintenance tasks: gathering optimizer statistics; the Segment Advisor; the SQL Tuning Advisor. The advisors run automatically, but the recommendations must be accepted (or ignored) manually. The tasks run in the maintenance windows, which by default open for 4 hours every weeknight at 22:00 and for 20 hours on Saturday and Sunday, opening at 06:00. For any of the AutoTasks to run, the STATISTICS_LEVEL parameter must be set to TYPICAL (the default) or ALL. The simplest way to manage the scheduling of the AutoTask jobs is through Database Control. Select the Server tab from the database home page, then the Automated Maintenance Tasks link on the Scheduler section. The Automated Maintenance Tasks window, shown in Figure 24-6, displays the window for the next run (which opens at 06:00, because the figure was taken on a Saturday evening) with links for the results of the last two advisor runs. Clicking these links will show the recommendations (if any) with an option to implement them (implementing the recommendations is not automatic). The Segment Advisor task relies on the history of object statistics built up by the daily running of the gather Optimizer Statistics Gathering. By observing these, the Segment Advisor can see not only how much unused space there is in the tables and indexes, but also whether this space is likely to be needed again, and if not advise that Chapter 24: The AWR and the Alert System 877 PART III the segments should be reorganized. The SQL Tuning Advisor task relies on the AWR statistics gathered by the MMON process. These statistics include figures on which SQL statements are being executed many times, perhaps millions of times an hour; which statements are responsible for a large amount of disk and memory I/O; and which statements are taking a long time to run. These are the high-load statements that will be subjected to tuning analysis. To view and adjust the window schedule, click Configure. This will take you to the window shown in Figure 24-7, where there are radio buttons for enabling or disabling the jobs; buttons for configuring Optimizer Statistics Gathering and Automatic SQL Tuning jobs; links for editing the opening and closing times of the daily windows; and check boxes for selecting in which windows the various jobs will run. TIP The default settings for the maintenance windows may well not be appropriate for you. In many Middle Eastern countries, for example, Saturday and Sunday are working days. Also, many databases support global organizations: just because it is the middle of the night for you, that doesn’t mean it is for many of your end users. Figure 24-6 The Automated Maintenance Tasks window OCA/OCP Oracle Database 11g All-in-One Exam Guide 878 Exercise 24-2: Generate an ADDM Report In this exercise, you will generate an Automatic Database Diagnostic Monitor report on activity between two snapshots. 1. Connect to your database as user SYSTEM with SQL*Plus. 2. Force the creation of an AWR snapshot: execute dbms_workload_repository.create_snapshot; 3. Simulate a workload by creating a table and running an anonymous PL/SQL block to generate some activity: create table tmptab as select * from all_objects; begin for i in 1 10 loop insert into tmptab select * from all_objects; delete from tmptab; end loop; commit; end; / 4. Force the creation of an AWR snapshot, using the command in Step 2. This illustration shows Steps 2–4: Figure 24-7 The Database Control window for managing the AutoTasks system Chapter 24: The AWR and the Alert System 879 PART III 5. Connect to your database as user SYSTEM using Database Control. 6. Click the Advisor Central link in the Related Links section on the database home page. The first report listed will be the ADDM report generated as a result of the snapshot, as shown here: OCA/OCP Oracle Database 11g All-in-One Exam Guide 880 7. Select the radio button for the latest ADDM report, and click View Result. Study the report: it will show a spike of activity in the last few minutes, with a number of “Findings” beneath. Click the findings to see the nature of the activity and the statements that caused it. 8. To tidy up, drop the table from your SQL*Plus session: drop table tmptab; Using the Server-Generated Alert System The Alert system is the reason why, from release 10g onward, the Oracle database can be described as self-managing. In earlier releases, the DBA had to spend a great deal of effort on humdrum work that was essential but not always that interesting. They also had to devise methods of picking up exceptional conditions as they occurred. The Alert system can automate a large amount of work that previously fell into the DBA domain. Alert Condition Monitoring and Notifications A typical example of the humdrum work is space management: at its most basic, monitoring tablespaces to see when they are about to fill up. This could be done with scripts, such as this one: SQL> select d.tablespace_name,sum(d.bytes) total,sum(f.bytes) free 2 from dba_data_files d left outer join dba_free_space f 3 on d.tablespace_name=f.tablespace_name 4 group by d.tablespace_name; TABLESPACE_NAME TOTAL FREE SYSAUX 807337984 38928384 USERS 24641536 1507328 SMALL 401408 SYSTEM 1509949440 4390912 EXAMPLE 314572800 23396352 UNDO1 209715200 208338944 But these scripts are prone to error—or at least, misinterpretation. For example, the view DBA_FREE_SPACE has one row for every bit of free space in every tablespace. But if a tablespace were full, there would be no rows at all; hence the need for the OUTER JOIN, without which the SMALL tablespace would not be listed, even though it is in a critical state. Then consider the effect of enabling AUTOEXTEND on the datafiles. Also, an UNDO tablespace will usually be 100 percent full—but this is not a problem, because a large part of the undo data will be inactive and can be overwritten. And what about temporary tablespaces? The query would have to be in a UNION with another query against DBA_TEMP_ FILES. Many DBAs have written suites of SQL code to report on space usage and raise warnings before error conditions occurred. Fine—but the scripts had to be written, they Chapter 24: The AWR and the Alert System 881 PART III had to be run regularly, and they had to be updated to take account of changes in technology. Many companies have written and marketed tools to do the same thing. The Alert system replaces a vast amount of this humdrum work. It will monitor many conditions that can cause problems, and will send notifications by a variety of methods. With regard to space management, it is by default configured to raise a warning alert when a tablespace reaches 85 percent full and a critical alert when a tablespace is 97 percent full, with account being taken of auto-extension and the nature of the contents. Alerts comes in two forms. Stateful alerts are based on conditions that persist and can be fixed. Tablespace space usage is an example, or the number of sessions hanging, or the average time it is taking to complete a SQL statement execution. Stateless alerts are based on events; they happen and are gone. A query failing with “snapshot too old” or two transactions deadlocking are examples. To configure the Alert system, you set thresholds. The thresholds are stored in the AWR. Then the MMON background process will monitor the database and the instance, in real time, and compare the current state with the thresholds. If a threshold is crossed, it will raise the alert. The mechanism by which an alert is raised is simply to put an entry on the alert queue. A queue is a table of messages that other processes can read. What happens to the alert message next is a matter for further configuration. The default behavior is that Enterprise Manager (either Database Control or Grid Control) will dequeue the message and display it on the database home page, but Enterprise Manager can be configured to send e-mails or SMS messages when it finds that an alert has been raised. You can also view the alerts by querying the view DBA_OUTSTANDING_ ALERTS, and it is possible to write an alert handler that will dequeue the messages and take any action desired. EXAM TIP Alerts are raised by the MMON process, not by Enterprise Manager. Enterprise Manager reads alerts, as can other event handlers written by you or by third parties. Setting Thresholds There are over 200 metrics for which you can set thresholds. They are documented in the view V$METRICNAME, which gives the name of the metric and the units in which it is measured, and the ID number by which it is identified. There is an API (the DBMS_SERVER_ALERT package) for setting thresholds. For example: 1 execute dbms_server_alert.set_threshold(- 2 metrics_id=>dbms_server_alert.redo_generated_sec,- 3 warning_operator=>dbms_server_alert.operator_ge,- 4 warning_value=>'1000000',- 5 critical_operator=>dbms_server_alert.operator_ge,- 6 critical_value=>'2000000',- 7 observation_period=>1,- 8 consecutive_occurrences=>5,- 9 instance_name=>'ORCL11G',- 10 object_type=>dbms_server_alert.object_type_system,- 11 object_name=>null); OCA/OCP Oracle Database 11g All-in-One Exam Guide 882 Taking this PL/SQL execution call line by line: 1. The procedure SET_THRESHOLD will create or update an alert threshold. 2. The metric being set is the rate of redo generation, measured in bytes per second. 3. The comparison operator for the warning level, which is “greater than or equal to.” 4. The value for a warning alert, which is 1MB a second. 5. The comparison operator for the critical level, which is “greater than or equal to.” 6. The value for a critical alert, which is 2MB a second. 7. The observation period, in minutes. 8. The number of consecutive occurrences before the alert is raised. 9. The instance for which the alert is being configured. 10. The type of object to which the alert refers. 11. The name of the object to which the alert refers. Note that not all the arguments are relevant for all alerts. The preceding example configures an alert for the rate of redo generation; a warning will be raised if this exceeds 1MB a second, and a critical warning if it goes over 2MB a second. The observation period is set to a minute and consecutive occurrences to five; this means that if the redo generation happens to hit a high level just a couple of times, it will not be reported—but if it stays at a high level consistently (for five consecutive minutes), then it will be reported. As this metric is one that could vary between instances in a RAC environment, the instance name must be specified, but the object name is not relevant. If the alert were for tablespace usage, then the instance name would not be specified, the object type would be tablespace, and the object name would be set to the name of the tablespace. To reach the graphical interface for setting thresholds, select the Metric And Policy Settings link in the Related Links section on the database home page. This will show all the metrics with their settings. Clicking the Edit symbol for a metric will take you to the window where the thresholds can be set. Figure 24-8 shows this for the “Redo Generated (per second)” metric, after executing the procedure call just described. The graphical interface does not give access to all the settings for all the metrics; in this case, you cannot specify an observation period (it is always set to one minute) and have no choice of comparison operators. The Notification System The default notification mechanism for stateful alerts is nothing more than displaying them in Enterprise Manager on the database home page, and writing them to the DBA_OUTSTANDING_ALERTS view. They will remain visible until they are cleared. They may be cleared because the DBA has fixed the problem, or in some cases the Chapter 24: The AWR and the Alert System 883 PART III problem will go away in the natural course of events. For instance, a tablespace-usage alert would usually require DBA action (such as adding another datafile), whereas an activity-related alert such the rate of redo generation might clear automatically when the activity reduces. When an alert is cleared, within the database it is removed from the DBA_ OUTSTANDING_ALERTS view and written to the DBA_ALERT_HISTORY view. Stateless alerts go straight to the history view. If any notification beyond the default is needed, this must be configured within Enterprise Manager. The Enterprise Manager notification system requires configuration at three levels: • A notification method must be configured. • A rule must be created to catch the event. • An administrator must subscribe to the rule. To set up notification methods in Database Control, click the Setup link visible in most Database Control windows at the top right and bottom center, and then the Notification Methods link in the left-hand side menu bar. From here, you specify the address of the SMTP server to which Database Control should send e-mail notifications, with authentication details and a reply address. From this window, shown in Figure 24-9, you can also define additional notification methods. Figure 24-8 Setting thresholds with Database Control OCA/OCP Oracle Database 11g All-in-One Exam Guide 884 The alternative notification methods can be seen at the bottom of Figure 24-9: operating system commands or scripts, PL/SQL procedures, or an SNMP trap (which lets Database Control integrate with any SNMP management system that may be available). Having defined the notification method, create a rule. Select the Preferences link visible in most Database Control windows at the top right and bottom center, then the Rules link in the left-hand side menu bar. There are several preconfigured rules. To create a new one, click Create and give the rule a name; select the Public check box to make it available to other uses. Then click Metrics, if the rule is for a metric, and select which metrics the rule should monitor. Figure 24-10 shows adding the “Redo Generated (per second)” metric to a rule. The final step is for a user to subscribe to the notifications. From the Setup link again, choose Administrators on the left-hand side menu bar. There will by default be three administrators: SYS, SYSMAN, and SYSTEM. A site making use of Enterprise Manager would usually have created additional users. Select the radio button for the user who is to subscribe to one or more rules, click Edit to make sure the user’s e-mail address is set up, and then click Subscribe To Rules to reach a list of all the public rules, where the ones for which the user is to receive notifications by e-mail can be selected. Notifications sent with any of the other methods (PL/SQL, OS command, or SNMP) do not need this step; the code written to implement the PL/SQL Figure 24-9 Defining the server address for Database Control to send e-mail notifications Chapter 24: The AWR and the Alert System 885 PART III procedure, the operating system script, or the SNMP trap should handle the propagation of the notification. Exercise 24-3: Configure Alerts In this exercise, you will enable an alert for the commit rate and demonstrate its use. 1. Connect to your database with Database Control as user SYSTEM. 2. From the database home page, click the Metric And Policy Settings link in the Related Links section. 3. Make sure that the View box is set to All Metrics, and scroll down to the User Commit (per second) metric. 4. Set the “Warning” and “Critical” thresholds to 1 and 4, respectively. These are artificially low thresholds that it will be simple to cross. Click OK to save this change. 5. Connect to your database as user SYSTEM with SQL*Plus, and issue the COMMIT command a few times quickly: SQL> commit; Commit complete. SQL> / Commit complete. SQL> / Commit complete. SQL> / Commit complete. SQL> / Commit complete. Figure 24-10 Adding a metric to a Database Control notification rule . 24-9, you can also define additional notification methods. Figure 24-8 Setting thresholds with Database Control OCA/ OCP Oracle Database 11g All-in-One Exam Guide 884 The alternative notification methods. OCA/ OCP Oracle Database 11g All-in-One Exam Guide 87 6 The Scheduler (described in Chapter 22) runs jobs automatically, at certain times and repeatedly at certain intervals. The jobs. be the ADDM report generated as a result of the snapshot, as shown here: OCA/ OCP Oracle Database 11g All-in-One Exam Guide 880 7. Select the radio button for the latest ADDM report, and click