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

Select the Server tab from the database home page, then the Automated Maintenance Tasks link on the Scheduler section.. Connect to your database as user SYSTEM using Database Control.. W

Trang 1

OCA/OCP Oracle Database 11g All-in-One Exam Guide

876

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

Trang 2

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

Trang 3

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

Trang 4

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:

Trang 5

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

Trang 6

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

Trang 7

object_type=>dbms_server_alert.object_type_system,-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

Trang 8

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

Trang 9

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

Trang 10

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

Định dạng
Số trang	10
Dung lượng	561,1 KB