11g New Features For Administrators Student Guide-6

Default Maintenance Resource Manager Plan
SQL> show parameter resource_manager_plan
NAME TYPE VALUE

---------------------- ------- ------------------------------------------
resource_manager_plan string SCHEDULER[0x2843]: DEFAULT_MAINTENANCE_PLAN
7 - 27 Copyright © 2007, Oracle. All rights reserved.
When a maintenance window opens, DEFAULT_MAINTENANCE_PLAN resource manager

plan is automatically set to control the amount of CPU used by automated maintenance tasks. To
be able to give different priorities to each possible task during a maintenance window, various
consumer groups are assigned to DEFAULT_MAINTENANCE_PLAN. The hierarchy between
groups and plans is shown on the above slide.
For high priority tasks:
• Optimizer Statistics Gathering automatic task is assigned to the
ORA$AUTOTASK_STATS_GROUP consumer group.
• Segment Advisor automatic task is assigned to the ORA$AUTOTASK_SPACE_GROUP
consumer group.
• Automatic SQL Tuning automatic task is assigned to the ORA$AUTOTASK_SQL_GROUP
consumer group.
Note: If need be, you can manually change the percentage of CPU resources allocated to the
various automated maintenance task consumer groups inside
ORA$AUTOTASK_HIGH_SUB_PLAN.
Oracle Database 11g: New Features for Administrators 7 - 27

Automated Maintenance Task Priorities
Run Job1 Run Job2 Run Job3 Run Job3 Run Job4
… with with with with with …
urgent urgent high medium medium
priority priority priority priority priority
urgent MMON
Stats high
Maintenance medium
Window ABP
Space
Job1 … Jobn
SQL
DBA_AUTOTASK_TASK
Automated Maintenance Tasks feature is implemented by a background process: Autotask

Background Process (ABP). ABP functions as an intermediary between automated tasks and the
Scheduler. Its main purpose is to translate tasks into jobs for execution by the Scheduler. Just as
important, ABP maintains history of execution of all tasks. ABP stores its private repository in
SYSAUX tablespace. You can view this repository through DBA_AUTOTASK_TASK. ABP is
spawned by MMON, typically at the start of a Maintenance Window. There is only one ABP
required for all instances. Every 10 minutes, MMON check to see if ABP needs to be restarted in
case it crashes.
ABP determines the list of jobs that need to be created for each maintenance task. This list
receives priority: urgent, high, or medium. Within each priority group, jobs are arranged in the
preferred order of execution. ABP creates jobs in a round-robin manner; so all Urgent priority
jobs are created first, then all High priority jobs, and finally all Medium priority jobs.
Depending on the the task’s priority attribute (urgent, high, or medium), various Scheduler job
classes are created to be able to map task’s priority consumer groups to corresponding job classes.
Note: With Oracle Database 11g, there is no job that is permanently associated with a specific
automated task. Therefore, it is not possible to use DBMS_SCHEDULER API to control the
behavior of automated tasks. Instead, DBMS_AUTO_TASK_ADMIN package should be used.

Controlling Automatic Maintenance Tasks
The Automatic Maintenance Task feature decides when and in what order tasks are performed. As
a DBA, you can control the following:
• If the maintenance window turns out to be inadequate for the maintenance workload, you can
reconfigure the maintenance window.
• You also have the ability to control the percentage of resources allocated to the automated
maintenance tasks during each window.
• You can enable/disable individual task in some or all Maintenance Windows.
• In RAC environment, you have the ability to shift maintenance work to one or more instances
by mapping maintenance work to a service. Enabling the service on a subset of instances will
shift maintenance work to these instances.
As shown on the slide, Enterprise Manager is the preferred way for Automatic Maintenance Tasks
control. However, you can also use the DBMS_AUTO_TASK_ADMIN package.

Important I/O Metrics for Oracle Databases
Disk bandwidth Channel bandwidth
Metric = IOPS Metric = MBPS

and Latency
Need large
Need high RPM and
I/O channel
fast seek time
OLTP OLAP
(Small random I/Os) (Large sequential I/Os)
Important I/O Metrics for Oracle Databases

To have a clear understanding of the type of I/O resource metrics that you need to know for tuning
purposes in an Oracle Database environment, we need to briefly go through the type of I/Os
issued by Oracle Database processes. The database I/O workload typically consists of small
random I/Os and large sequential I/Os. The small random I/Os are more prevalent in an OLTP
application environment where each foreground reads a data block into the buffer cache for
updates and the changed blocks are written in batches by the dbwr process. Large sequential I/Os
are common in an OLAP application environment. The OLTP application performance depends
on how fast the small I/Os are serviced, which depends on how fast the disk can spin and seek to
the data. The large I/O performance depends on the capacity of the I/O channel that connects the
server to the storage array. The larger the capacity of the channel, the better the large I/O
throughput.
IOPS (I/Os per second): This metric represents the number of small random I/Os that can be
serviced in a second. The IOPS rate mainly depends on how fast the disk media can spin. The
IOPS rate from a storage array can be increased either by adding more disk drives or by using disk
drives with a higher RPM (Rotations Per Minute) rate.
MBPS (Mbytes per second): The rate at which data can be transferred between the computing
server node and the storage array depends on the capacity of the I/O channel that is used to
transfer data. The wider the pipe, the more data can be transferred.

Important I/O Metrics for Oracle Databases (Continued)
The throughput of a streaming data application depends on how fast this data can be accessed and
is measured using the MBPS metric.
Even though the disks themselves have an upper limit on the amount of sequential data they can
transfer, it is often the channel capacity that limits the overall throughput of the system. For
example, a host connected to a NAS server through a GigE switch is limited by a transfer capacity
of 128 MBPS. Hence it becomes important to throttle based on this channel resource.
I/O Latency: Latency is another important metric that is used in measuring the performance of an
I/O subsystem. Latency represents the time it takes for a submitted I/O request to be serviced by
the storage. Put it another way, it represents the fixed overhead before the first byte of a transfer
arrives after an I/O request has been submitted. A higher latency usually indicates an overloaded
system. Latency values are more commonly used for small random I/Os when tuning a system. If
there are too many I/Os queued up against a disk, the latency increases. To improve the latency of
I/O requests, data is usually striped across multiple spindles so that all I/O requests to a file do not
go to the same disk.
Apart from the main resources mentioned above, there are also other storage array components
that can affect I/O performance. Array vendors provide caching mechanisms to improve read
throughput, but their real benefit is questionable in a database environment because Oracle
Database uses caches and read-ahead mechanisms so that data is available directly from RAM
rather than disks.

I/O Calibration and Enterprise Manager
I/O Calibration and Enterprise Manager

To determine the previously discussed important I/O metrics, you can use the I/O Calibration tool
exposed through Enterprise Manager or PL/SQL in Oracle Database 11g. I/O Calibration is a
modified version of the ORION tool. Because calibration requires issuing enough I/Os to saturate
the storage system, any performance-critical sessions will be negatively impacted. Thus, you
should run I/O calibration only when there is little activity on your system.
I/O Calibration takes approximately ten minutes to run. You can launch an I/O Calibration task
directly from Enterprise Manager as shown on the slide. You do this by accessing the
Performance tab. On the Performance page, you can click the I/O tab and then the I/O Calibration
button.
Once on the I/O Calibration page, you need to specify the approximate number of physical disks
attached to your database storage system as well as the maximum tolerable latency for a single-
block I/O request. Then, in the Schedule section of the I/O Calibration page, you can specify
when to execute the calibration operation. You click the Submit button to create a corresponding
Scheduler job.
From the Scheduler Jobs page, you can see the amount of time it takes for the calibration task to
run. Once finished, you can go back to the I/O Calibration page to see the results of the calibration
operation which gives you the maximum I/O per second, maximum megabytes per second, and
the maximum tolerable latency metrics.

I/O Calibration and PL/SQL interface
SQL> exec dbms_resource_manager.calibrate_io( -

num_disks=>1, -
max_latency=>10, -
max_iops=>:max_iops, -
max_mbps=>:max_mbps, -
actual_latency=>:actual_latency);
PL/SQL procedure successfully completed.
SQL> select * from v$io_calibration_results;
STATUS LATENCY MAX_IOPS MAX_MBPS NUM_DISKS CALIBRATION_TIME

------ ------- -------- -------- --------- -------------------------
READY 21 87 5 1 12-APR-07 02.47.46.698 AM
I/O Calibration and PL/SQL interface

Alternatively, you can run the I/O Calibration task using PL/SQL interface. This is done when you
execute the CALIBRATE_IO procedure from the DBMS_RESOURCE_MANAGER package.
This procedure calibrates the I/O capabilities of storage. The calibration status and results are
available from the V$IO_CALIBRATION_RESULTS table.
Here is a brief description of the parameters you can specify for the CALIBRATE_IO procedure:
• num_disks: Approximate number of physical disks in the database storage
• max_latency: Maximum tolerable latency in milliseconds for database-block-sized IO
requests
• max_iops: Maximum number of I/O requests per second that can be sustained. The I/O
requests are randomly-distributed, database-block-sized reads.
• max_bps: Maximum throughput of I/O that can be sustained, expressed in megabytes per
second. The I/O requests are randomly-distributed, one megabyte reads.
• actual_latency: Average latency of database-block-sized I/O requests at max_iops rate,
expressed in milliseconds
Usage notes:
• Only users with the SYSDBA privilege can run this procedure.
• Only one calibration can be run at a time. If another calibration is initiated at the same time,
it will fail.
• For a RAC database, the workload is simultaneously generated from all instances.
• The latency time is computed only when the initialization parameter TIMED_STATISTICS
is set to TRUE (which is turned on when STATISTICS_LEVEL is set to TYPICAL or ALL).
I/O Statistics Overview
V$IOSTAT_FUNCTION
AWR & EM
.
V$IOSTAT_FILE
V$IOSTAT_CONSUMER_GROUP
I/O Statistics Overview

To give a consistent set of statistics for all I/O’s issued from an Oracle instance, a set of virtual
views are introduced with Oracle Database 11g which collect I/O statistics in three dimensions:
• RDBMS components : Components are grouped by their functionality into 12 categories
shown on the slide.
• When Resource Management is enabled, I/O statistics are collected for all consumer groups
that are part of the currently enabled resource plan.
• I/O statistics are also collected for individual files (if it has been opened).
Each dimension has statistics for read and write operations. Since read/write can occur in single
block or multi block operations, they are separated into four different operations as shown on the
slide. For each operation type, the number of corresponding requests and the amount of
megabytes are cumulated. In addition to these, total I/O wait time in millisenconds and number of
total waits are also cumulated for both components and consumer group statistics.
For file statistics, total service time in microseconds is cumulated in addition to statistics for
single block reads.
Virtual views show cumulative values for statistics. Component and consumer group statistics are
transformed into AWR metrics that are sampled regularly and stored in the AWR repository. You
can retrieve those metrics across a timeline directly on the performance page of Enterprise
Manager.
Note: V$IOSTAT_NETWORK provides information about network I/O statistics that were
caused by accessing files on a remote database instance.
I/O Statistics and Enterprise Manager

You can retrieve I/O statistics directly on the Performance page in Enterprise Manager. On the
Performance page, simply click on the I/O sub-tab located underneath the Average Active Session
graph.
On the I/O sub-page, you can see a breakdown of I/O statistics on three possible dimension: I/O
Function, I/O Type, and Consumer Group. Click one of the radio buttons to look at the
corresponding dimension graphs. The slide shows you the two graphs corresponding to the I/O
function dimension: I/O Megabytes per Second per RDBMS component and I/O Requests per
Second per RDBMS component.
Note: The Other RDBMS component category corresponds to everything that is not directly
issued from SQL (PL/SQL, Java).


From one of the I/O statistic graphs, you can drill down to a specific component by clicking on
that component. In the example shown on the slide, you drill down to the Buffer Cache Reads
component. This takes you to the I/O Rates by I/O Function page where you can see the three
important graphs for that particular component: MBPS, IOPS, and wait time.

Resource Manager New EM Interface
Resource Manager New EM Interface

Using Enterprise Manager, you can access the Resource Manager section from the Server page.
The Resource Manager section is organized in the way you should proceed to use Resource
Manager.
The first link in that section is called Getting Started. From the Getting Started With Database
Resource Manager page, you can see a brief description of each step as well as links to the
corresponding pages.

Resource Manager Plans Created by Default
Resource Manager Plans Created by Default

When you create an Oracle 11g Database, by default, the above shown resource manager plans
are created. However, none of them are active by default.

SQL> show parameter resource_manager_plan
NAME TYPE VALUE

---------------------- ------- ------------------------------------------
resource_manager_plan string SCHEDULER[0x2843]: DEFAULT_MAINTENANCE_PLAN

When a maintenance window opens, DEFAULT_MAINTENANCE_PLAN resource manager
plan is automatically set to control the amount of CPU used by automated maintenance tasks. To
be able to give different priorities to each possible task during a maintenance window, various
consumer groups are assigned to DEFAULT_MAINTENANCE_PLAN. The hierarchy between
groups and plans is shown on the above slide.
For high priority tasks:
• Optimizer Statistics Gathering automatic task is assigned to the
ORA$AUTOTASK_STATS_GROUP consumer group.
• Segment Advisor automatic task is assigned to the ORA$AUTOTASK_SPACE_GROUP
consumer group.
• Automatic SQL Tuning automatic task is assigned to the ORA$AUTOTASK_SQL_GROUP
consumer group.
Note: If need be, you can manually change the percentage of CPU resources allocated to the
various automated maintenance task consumer groups inside
ORA$AUTOTASK_HIGH_SUB_PLAN.

Default Plan
Default Plan
The above slide shows you how DEFAULT_PLAN is created.
Note that there are no limits for its thresholds.
As you can see, Oracle Database 11g introduced two new I/O limits that you can define as
thresholds in a resource manager plan.

I/O Resource Limit Thresholds
I/O Resource Limit Thresholds

When you create a resource manager plan directive, you can specify I/O resource limits.
The above example shows you how to do this in both Enterprise Manager and PL/SQL.
You can specify the following two arguments:
• switch_io_megabytes: Specifies the amount of I/O (in MB) that a session can issue before an
action is taken. Default is NULL, which means unlimited.
• switch_io_reqs: Specifies the number of I/O requests that a session can issue before an action
is taken. Default is NULL, which means unlimited.

e re!
lt sh
re su
t
ge
n to
e rsio
v
kable
or
aw
or
a it f
tow
e d
Ne
You can also look at the Resource Manager Statistics page

Scheduler New Features
• Scheduling Streams Propagation Jobs using Oracle

Scheduler
• Support for
– Remote Jobs
– Distributed Jobs
– Lightweight jobs for performance (large number of jobs)
The main Enhancements to Scheduler in Oracle database 11g are listed. The feature on the
scheduling propagation jobs is discussed in the Oracle Streams e-study

Remote and Distributed Jobs
Schedule
Remote jobs Jobs
• Operating system level jobs
• Scripts, binaries, etc
• No Oracle database
required
• Agent starts and manages
jobs
Distributed jobs
• Database jobs on other Agent
servers
Execute Execute
OS job DB Job
Oracle Scheduler has added support for remote and multi-node jobs. It provides the ability of
running a job on a host without a database
Additionally users are allowed to provide a list of databases on which to execute a job. Creation
and maintenance are done on a single database, but at run time exact replicas are executed on all
the databases specified.

Installing the Agent
The agent is a separately installable component but it is included in every database. During
installation of the agent as part of the database there is no configuration necessary. If the agent
installed as part of the database is required to run jobs from another database an additional step is
necessary to register with that database and to start the agent in the background.
During standalone installation the agent should be registered with at least one database. It is
possible to automate this registration if the user is willing to include the database registration
password in the installer file. This allows for silent automated installs.
Optional information includes
• Path to install the agent into
• Whether to automatically start the agent
• Whether to setup the agent to automatically start on every computer startup
If after installation of the agent, another database is required to run jobs on the agent, the agent
must be registered with that database.

Running a remote JOB
1. Set the source for remote jobs for this database

2. Set an agent registration password
3. Install agents on 2 machines
4. For every job to be run on the host, add it as a
destination
The following steps are necessary to run a remote external job.

1. Set the source for remote jobs for this database (XML DB HTTP listener) with
dbms_scheduler.set_scheduler_attribute('source','server.examp
le.com:1234') where 'server.example.com:1234' is the server name and port
for the XML DB HTTP listener
2. Set an agent registration password with
dbms_scheduler.set_agent_registration_pass('password',
max_uses=>2)
3. Install agents on 2 machines with agent-install database-password set to "password "
4. For every job to be run on the host, add it as a destination with
1. dbms_scheduler.add_job_destination('job1','host1','user1','p
assword')
2. dbms_scheduler.add_job_destination('job1','host2','user2','p
assword')
5. Once the job has been enabled there are two rows in the
*_SCHEDULER_REMOTE_JOB_STATE views, one for each destination
6. The job runs on both destinations every time it is scheduled to run. For every run there are 2
entries in *_SCHEDULER_JOB_LOG and *_SCHEDULER_JOB_RUN_DETAILS views.
7. Once the job has been completed or has been disabled there are no rows in the
*_SCHEDULER_REMOTE_JOB_STATE views.

Remote Database Jobs
Job 1
Job 2
Job 3
A remote database job refers to a collection of jobs with the following properties:
• The jobs are created on one database.
• The jobs share their metadata with the exception of run-related attributes, thus making the
jobs copies of each other.
• Each copy of the job executes on a different database, independently of the others. For
example, a job may execute successfully several times on one database while failing to
execute at all on another database. (The success or failure of a job on one database does not
affect any of the other copies).
• All copies of the job can be altered or manipulated from the database where the job was
originally created.
The copies of the job that are running on the various databases are, in effect, independent jobs.
However, they are still linked in the sense that they can be manipulated as a group. The original
job created by the user is called the parent job. To distinguish the copies of the job from other
copied/cloned jobs, the copies are called job instances.
The database on which a remote database job is created is called the source database of the job.
The databases on which the job is executed are called destination databases. If the job is
configured to execute on the database on which it was created, then that database is both the
source database for the job as well as one of its destinations.

Setting Parameters for Remote Jobs
• MAX_CONCURRENT_JOBS
• MAX_CONCURRENT_JOBS_PER_USER
• max_concurrent_jobs
MAX_CONCURRENT_JOBS: This is the absolute maximum number of jobs allowed to run on the
host simultaneously. This only includes jobs run through and controlled by the agent. Default
value is 100. If jobs run through the agent are taking up too much CPU, memory or IO, the
administrator can reduce this number.
MAX_CONCURRENT_JOBS_PER_USER: Allowable Values are1-1000. If multiple users run
jobs on a remote host this parameter allows limiting the maximum number of jobs a single user
can run simultaneously. Default value is 100. Since this is the same as the default value for
MAX_CONCURRENT_JOBS it does not have any effect by default. If several users use a remote
host and one is using more CPU/memory/IO than he should, this number can be reduced.
LIMITING_CPU_THRESHOLD:Allowable Values are10-100. This is the CPU threshold, above
which new jobs cannot run. Default value is 100 This value effectively turns limiting based on
CPU usage off. If a remote host should never be completely loaded or should have CPU always
reserved for another use then this value should be set to ensure this.

Enhancements to Scheduler APIs
• NEW DBMS_SCHEDULER Procedures

– CREATE_CREDENTIAL
– DROP_CREDENTIAL
– SET_AGENT_REGISTRATION_PASS
– ADD_JOB_DESTINATION
– REMOVE_JOB_DESTINATION
– SET_PREFERRED_CREDENTIAL
– UNSET_PREFERRED_CREDENTIAL
– GET_FILE
– PUT_FILE
• Modified DBMS_SCHEDULER Procedures
– STOP_JOB
– RUN_JOB
CREATE_CREDENTIAL
CREATE_CREDENTIAL(
credential_name IN VARCHAR2,
user IN VARCHAR2,
password IN VARCHAR2,
domain IN VARCHAR2 DEFAULT NULL,
db_role IN VARCHAR2 DEFAULT NULL,
comments IN VARCHAR2 DEFAULT NULL);
This is used to create a stored username/password pair called a credential. Credentials reside in a
particular schema and can be created by any user with the CREATE JOB system privilege.
DROP_CREDENTIAL
DROP_CREDENTIAL(
credential_name IN VARCHAR2,
force IN BOOLEAN DEFAULT FALSE);
This is used to drop a stored username/password pair called a credential. To drop a public
credential, the SYS schema must be explicitly given. Only a user with the MANAGE SCHEDULER
system privilege is able to drop a public credential. For a regular credential only the owner of the
credential or a user with the CREATE ANY JOB system privilege is able to drop the credential.
SET_AGENT_REGISTRATION_PASS
SET_AGENT_REGISTRATION_PASS(
registration_password IN VARCHAR2,
expiration_date IN TIMESTAMP DEFAULT NULL,
max_uses IN NUMBER DEFAULT 1);
This is used to set the agent registration password for a database. Remote agents must register
with the database before the database can submit jobs to the agent. To prevent abuse, this
Dictionary Views
• New Views:
– *_SCHEDULER_CREDENTIALS
– *_SCHEDULER_JOB_DESTINATIONS
– *_SCHEDULER_PREFERRED_CREDS
• These views are modified to contain the following
additional columns.
– *_SCHEDULER_JOBS:
– *_SCHEDULER_JOB_LOG
– *_SCHEDULER_JOB_RUN_DETAILS
– *_SCHEDULER_REMOTE_JOB_STATE
• The following dictionary views have been added:

- *_SCHEDULER_CREDENTIALS:This lists all regular credentials in the current user's
schema.
- *_SCHEDULER_JOB_DESTINATIONS:This is a list of all destinations for all jobs in
the current schema. If a job does not have any destinations specified, it runs only on the
local database or host.
- *_SCHEDULER_PREFERRED_CREDS: This is a list of all preferred credentials for the
current schema. If target is NULL then this credential is valid for all targets for jobs in
the current schema.
• *_SCHEDULER_JOBS: These views are modified to contain the following additional
columns:
- number_of_destinations NUMBER NOT NULL Number of destinations
specified
- single-destination VARCHAR2(5) NOT NULL Whether this
should run on one of the destinations or all of them.
- credential_name VARCHAR2(30) Name of the credential to be
used for an external job
- credential_owner VARCHAR2(30) Owner of the credential to be
used for an external job
- working_directory VARCHAR2(1000) Initial directory for an external
job
- input VARCHAR2(4000) String to be provided as standard input to an
external jobDatabase 11g: New Features for Administrators 7 - 50
Oracle
- environment_variables VARCHAR2(4000) Semicolon-separated list
of name-value pairs to be set as environment variables for an external job
Light Weight Jobs
• Persistent lightweight jobs

– Little metadata
– Recoverable
• Volatile lightweight jobs
– No metadata
– Non recoverable
A lightweight job as one that has the following characteristics.

• Not based on database objects like current scheduler jobs
• A significantly lower creation overhead than current scheduler jobs
• A significantly lower average session creation time than current scheduler jobs.
• Less redo generated during runs than current scheduler jobs or no redo at all.
The Oracle Database 11g allows the creation of two types of lightweight jobs.
• The first type of lightweight has a small footprint on disk for lightweight job metadata and
also for storing run-time data. The footprint on disk also makes recovery possible and makes
load-balancing possible in RAC environments. These are called persistent lightweight jobs.
• The second type of lightweight jobs is called volatile lightweight jobs. These jobs may or
may not have their metadata written to disk and certainly don't have state written to disk at
run time. Recovery from crashes is not possible and neither is load-balancing across RAC
instances.
In addition to the two types of lightweight jobs, the database continues to support the database
object-based jobs that have existed since the Oracle Scheduler was first introduced in Oracle 10g.
Lightweight jobs are not intended to replace these jobs as each of the types of jobs described
above have their own advantages and provide you the flexibility to choose one or another based
on your needs.

Choosing the Right Job
• Regular job
– Highest Overhead
– Best recovery
• Persistent lightweight job

– Less Overhead
– Some recovery
• Volatile lightweight jobs

– Minimum overhead
– No recovery
The advantages and disadvantages of the three types of jobs are as follows
• A regular job offers the maximum flexibility but does entail a significant overhead in
create/drop performance. They can be created with a single command, the user can have fine-
grained control of the privileges on the job. He can also use a program or a stored procedure
owned by another user. The downside is, as mentioned before is slow create and drop time
because of the overhead necessitated by database objects. If the user is creating a relatively
small number of jobs that run relatively infrequently then he should choose regular jobs.
• A persistent lightweight job has a significant improvement in create and drop time since it
does not have the overhead of creating a database object. Since persistent lightweight jobs
write state to disk at run-time, their run-time overhead isn’t likely to be much better than for
regular jobs but these is a small improvement here. There are several drawbacks to persistent
lightweight jobs. First, the user cannot set privileges on these jobs - they inherit their
privileges from the parent job template; since the use of a template is mandatory, it is not
possible to create a fully self-contained persistent lightweight job. If the user needs to create a
large number of jobs in a very short time (from 10-100 jobs a second) and he has a library of
programs available that he can use then he should use persistent lightweight jobs.
• Volatile lightweight jobs write as little to disk as possible. Creates and drops may not be
written to disk at all and no state is written at run time. Thus the creation overhead is even
lesser than that for persistent lightweight jobs and there is minimal run-time overhead. On the
downside, volatile lightweight jobs share all the drawbacks of persistent lightweight jobs. In
addition, they have additional drawbacks in that they cannot be recovered if the database
crashes and cannot be load-balanced across RAC instances. Volatile jobs should be used in
those situations
Oracle where the user
Database 11g:is creating very large
New Features fornumbers of frequently
Administrators 7 -executing
52 jobs
and wants to bring overhead (both CPU as well as redo) to an absolute minimum.
New PL/SQL APIs
• New DBMS_SCHEDULER method

– The CREATE_LIGHTWEIGHT_JOB method
• Methods that work on lightweight jobs:
– SET_ATTRIBUTE
– GET_ATTRIBUTE
– SET_JOB_ARGUMENT_VALUE
– RESET_JOB_ARGUMENT_VALUE
– STOP_JOB, DROP_JOB
– RUN_JOB ·
• Methods that do not apply to lightweight jobs are:
– CREATE_JOB
– SET_JOB_ANYDATA_VALUE
Lightweight jobs are created modified and dropped using DBMS_SCHEDULER APIs. There are
minimal changes to the APIs – other than for creating lightweight jobs, no new APIs have been
added. The CREATE_LIGHTWEIGHT_JOB call has been added to create lightweight jobs.
Most calls to manipulate regular jobs work on lightweight jobs. The methods
SET_ATTRIBUTE, GET_ATTRIBUTE, SET_JOB_ARGUMENT_VALUE,
RESET_JOB_ARGUMENT_VALUE, STOP_JOB, DROP_JOB and RUN_JOB work with light
weight jobs. The job-related dbms_scheduler calls that do not apply to lightweight jobs are
CREATE_JOB (which is used only to create regular jobs) and SET_JOB_ANYDATA_VALUE
since lightweight jobs cannot take ANYDATA arguments.

Viewing Light Weight Jobs in Dictionary
• No new views are added

• Lightweight jobs are visible *_SCHEDULER_JOBS views
• Arguments to lightweight jobs are visible through
*_SCHEDULER_JOB_ARGS views
• Light Weight jobs are not visible through *_OBJECTS
views
The changes to dictionary views are as follows:

• No new views are added.
• Lightweight jobs are visible through the same views as regular jobs are –
DBA_SCHEDULER_JOBS, ALL_SCHEDULER_JOBS and USER_SCHEDULER_JOBS.
• Arguments to lightweight jobs are visible through the same views as those of regular jobs –
DBA_SCHEDULER_JOB_ARGS, ALL_SCHEDULER_JOB_ARGS and
USER_SCHEDULER_JOB_ARGS.
• Since lightweight jobs are not database objects, they are not visible through the
DBA_OBJECTS, ALL_OBJECTS and USER_OBJECTS views.

Summary
In this lesson, you should have learned how to:

• Bla
• Bla

Performance
Enhancements
Copyright © 2007, Oracle. All rights reserved.

Objectives
After completing this lesson, you should be able to:

• Use ADDM to perform cluster-wide performance
analysis
• Setup SGA sizing initialization parameters
• Setup Automatic Memory Management
• Use memory advisors
• Setup statistics preferences
• Setup incremental statistics
• Setup multi-columns statistics
• Setup expression statistics
• Defer statistics publishing
8-2 Copyright © 2007, Oracle. All rights reserved.

ADDM Enhancements

Advisor Named Findings
• Advisor results are now classified and named

– Exist in DBA{USER}_ADVISOR_FINDINGS view
• You can query all finding names from
DBA_ADVISOR_FINDING_NAMES view:
SQL> select finding_name from dba_advisor_finding_names;

FINDING_NAME
----------------------------------------
Top Segments by I/O
Top SQL by "Cluster" Wait
. . .
Undersized Redo Log Buffer
Undersized SGA
Undersized Shared Pool
Undersized Streams Pool
Oracle Database 10g introduced the advisor framework and various advisors to help DBAs
manage databases efficiently. These advisors provide feed back in the form of findings. Oracle
database 11g now classifies these findings, so that you can query the Advisor views to understand
how often a given type of finding is recurring in the database. A FINDING_NAME column has
been added to the following Advisor views:
• DBA_ADVISOR_FINDINGS
• USER_ADVISOR_FINDINGS
A new DBA_ADVISOR_FINDING_NAMES view displays all the finding names.

ADDM Enhancements in Oracle Database 11g
• ADDM for RAC

• Directives (finding suppression)
• dbms_addm package

Automatic Database Diagnostic Monitor (ADDM)
in Oracle Database 10g
• Self-Diagnostic Engine In the
Database
• Integrate all components
Application & SQL together
Management
• Automatically provides
Storage
database-wide performance
System Resource
Management Management diagnostic, including RAC
• Real-time results using the Time
Model
Backup & Recovery Space
Management Database Management • Provides impact and benefit
Management analysis, non problem areas
Intelligent Infrastructure • Provides Information vs. raw
data
• Runs proactively out of the box,
reactively when required

How Does ADDM Work?
Snapshots in • Top Down Analysis Using AWR

Automatic Workload Snapshots
Repository
• Throughput centric - Focus on
reducing time ‘DB time’
Automatic Diagnostic
Self-Diagnostic Engine
Engine • Classification Tree - based on
decades of Oracle performance
tuning expertise
• Real-time results – don’t need to
wait hours to see the results)
• Pinpoints root cause:
High-load IO / CPU
RAC issues Distinguishes symptoms from
SQL issues
the root cause
• Reports non-problem areas, e.g.
SQL System Network + I/O is not a problem
Resource DB config
Advisor Advice Advice

Oracle Database 11g: Automatic Database
Diagnostic Monitor for RAC
Database ADDM
Self-diagnostic Engine
Instance ADDM
AWR
…
Inst1 Instn
Oracle Database 11g: Automatic Database Diagnostic Monitor for RAC

Oracle Database 11g offers an extension to the set of functionality that increases the database’s
manageability by offering cluster-wide analysis of performance. A special mode of the Automatic
Database Diagnostic Monitor (ADDM) analyzes an Oracle Real Application Clusters(RAC)
database cluster and reports on issues that are affecting the entire cluster as well as those that are
affecting individual instances. This mode is called Database ADDM as opposed to Instance
ADDM that already exist with Oracle Database 10g.
Database ADDM for RAC is not just a report of reports but it has independent analysis
appropriate for RAC.

Automatic Database Diagnostic Monitor
for RAC
• Identifies the most critical performance problems for

the entire RAC cluster database
• Runs automatically when taking AWR snapshots (the
default)
• Performs database-wide analysis of:
– Global resources, for example IO, global locks
– High-load SQL, hot blocks
– Global cache interconnect traffic
– Network latency issues
– Skew in instance response times
• Used by DBAs to analyze cluster performance
Automatic Database Diagnostic Monitor for RAC

In Oracle Database 11g you can create a period analysis mode for ADDM that analyzes the
throughput performance for an entire cluster. When the advisor runs in this mode it is called
Database ADDM. You can run the advisor for a single instance which is equivalent to the Oracle
Database 10g ADDM and is now called instance ADDM.
The instance ADDM has access to AWR data generated by all instances making the analysis of
global resources more accurate. Both database and instance ADDM run on continuous time
periods that can contain instance startup and shutdown. In the case of database ADDM there may
be several instances that are shutdown or started during the analysis period. You must maintain
the same database version throughout the entire time period however.
Database ADDM runs automatically after each snapshot is taken. The automatic instance ADDM
runs are the same as in Oracle Database 10g. You can also perform analysis on a subset of
instances in the cluster. This is called partial analysis ADDM.
I/O capacity finding (the I/O system is overused) is a global finding since it concerns a global
resource affecting multiple instances. A local finding concerns a local resource or issue that
affects a single instance. For example, a CPU bound instance results in a local finding about CPU.
While ADDM can be used during application development to test changes to either the
application, the database system or the hosting machines, database ADDM is targeted at DBAs.

Automatic Database Diagnostic Monitor
for RAC
• Specified in
DBMS_ADVISOR.SET_DEFAULT_TASK_PARAMETER
procedure:
Value of INSTANCE Value of INSTANCES ADDM Analysis Mode
‘0’ or ‘UNUSED’(default) Database ADDM (all instances)
‘UNUSED’(default)
‘0’ or Comma separated list Partial analysis ADDM. Only
‘UNUSED’(default) of instance numbers instances specified in the
(1,2,5..) INSTANCES parameter are
analyzed.
A positive integer Any value Instance ADDM. The instance
(eg. ‘1’) specified in the INSTANCE
parameter is analyzed.
Automatic Database Diagnostic Monitor for RAC

The distinction between database and instance ADDM is based on the value of the advisor
parameter ‘INSTANCE’. When the value is ‘ALL’ the task is a database ADDM. When the value
is numeric, it is the instance ID for a instance ADDM task.
The results of an ADDM analysis are stored in the advisor framework and accessed like any
ADDM task in Oracle Database 10g. You select to run database ADDM, instance ADDM or
partial analysis by setting the parameters INSTANCE and INSTANCES in the
DBMS_ADVISOR.SET_DEFAULT_TASK_PARAMETER procedure.
Note: Partial ADDM is not currently exposed through EM but command line PL/SQL APIs
exists to do partial analysis.
Use DBMS_ADDM instead!

EM Support For ADDM for RAC
• Cluster Database Home Page:

Oracle Database 11g EM displays the ADDM analysis on the Cluster Database Home Page. The
Findings Table is displayed in the Performance Analysis section.
For each finding, the Affected Instances column displays the number (n of n) of instances
affected. The display also indicates the percentage impact for each instance. Further drill down on
the findings takes you to the ADDM Findings Detail page.

• Finding History Page:

The ADDM Finding Details Page allows you to see the Finding History. When you click on this
button you see a page with a chart on the top plotting the impact in active sessions for the finding
over time. The default display period is 24 hrs. The drop down also supports viewing for seven
days.
At the bottom of the display, a table similar to the results section is shown, displaying all findings
for this named finding.
From this page, you can set filters on the findings results. Different types of findings (e.g. CPU,
Logins, SQL) have different kinds of criteria for filtering.
Note: Only automatic runs of ADDM are considered for the Finding History. These results reflect
the unfiltered results only.

Using the DBMS_ADDM Package
• A database ADDM task is created and executed:
SQL> var tname varchar2(60);

SQL> BEGIN
SQL> :tname := ‘my database ADDM task’;
SQL> dbms_addm.analyze_db(:tname, 1, 2);
SQL> END;
• Use GET_REPORT procedure to see the result:
SQL> SELECT dbms_addm.get_report(:tname) FROM DUAL;

The DBMS_ADDM package eases ADDM management. It consists of the following procedures and
functions:
• ANALYZE_DB: Creates an ADDM task for analyzing the database globally.
• ANALYZE_INST: Creates an ADDM task for analyzing a local instance.
• ANALYZE_PARTIAL: Creates an ADDM task for analyzing a subset of instances.
• DELETE: Deletes a created ADDM task (of any kind).
• GET_REPORT: Get the default text report of an executed ADDM task.
• Parameters 1,2 are start and end snapshot

Advisor Named Findings and Directives
• Advisor results are now classified and named

– Exist in DBA{USER}_ADVISOR_FINDINGS view
• You can query all finding names from
DBA_ADVISOR_FINDING_NAMES view:
SQL> select finding_name from dba_advisor_finding_names;

FINDING_NAME
----------------------------------------
Top Segments by I/O
Top SQL by "Cluster" Wait
. . .
Undersized Redo Log Buffer
Undersized SGA
Undersized Shared Pool
Undersized Streams Pool
Advisor Named Findings and Directives

Oracle Database 10g introduced the advisor framework and various advisors to help DBAs
manage databases efficiently. These advisors provide feed back in the form of findings. Oracle
database 11g now classifies these findings, so that you can query the Advisor views to understand
how often a given type of finding is recurring in the database. A FINDING_NAME column has
been added to the following Advisor views:
• DBA_ADVISOR_FINDINGS
• USER_ADVISOR_FINDINGS
A new DBA_ADVISOR_FINDING_NAMES view displays all the finding names.

• Create an ADDM directive which filters Undersized SGA

findings:
SQL> var tname varchar2(60);
SQL> BEGIN
2 dbms_addm.insert_finding_directive (NULL,
3 'My undersized SGA directive',
4 'Undersized SGA',
5 2,
6 10);
7 :tname := 'my instance ADDM task';
8 dbms_addm.analyze_inst(:tname, 1, 2);
9 END;
10 /
SQL> SELECT dbms_addm.get_report(:tname) from dual;
• Possible findings found in DBA_ADVISOR_FINDING_NAMES

You can use possible finding names to query the findings repository to get all occurrences of that
specific finding.
Above you see the creation of a instance ADDM task with a finding directive. When the task
name is NULL it applies to all subsequent ADDM tasks. The finding name (“Undersized SGA”)
must exist in the DBA_ADVISOR_FINDING_NAMES view (which lists all the findings) and is
case sensitive. The result of DBMS_ADDM.GET_REPORT only shows an ‘Undersized SGA’
finding if the finding is responsible for at least 2 (min_active_sessions) average active
sessions during the analysis period, and this constitutes at least 10% (min_perc_impact) of
the total database time during that period.
Further PL/SQL directive procedures are:
• INSERT_FINDING_DIRECTIVE:Create a directive to limit reporting of a specific finding
type.
• INSERT_SQL_DIRECTIVE: Create a directive to limit reporting of actions on specific
SQL.
• INSERT_SEGMENT_DIRECTIVE:Create a directive to prevent ADDM from creating
actions to “run Segment Advisor” for specific segments.
• INSERT_PARAMETER_DIRECTIVE:Create a directive prevent ADDM from creating
actions to alter the value of a specific system parameter.
• Long syntax for parameters would help here again

• Directives are reported if you specify all
• The following lists the procedures to add directives:

– INSERT_FINDING_DIRECTIVE
– INSERT_SQL_DIRECTIVE
– INSERT_SEGMENT_DIRECTIVE
– INSERT_PARAMETER_DIRECTIVE
• The following lists the procedures to delete directives:
– DELETE_FINDING_DIRECTIVE
– DELETE_SQL_DIRECTIVE
– DELETE_SEGMENT_DIRECTIVE
– DELETE_PARAMETER_DIRECTIVE

Note: For a complete description of available procedures please see the Oracle Database 11g
PL/SQL References and Types documentation.

Modified Advisor Views
New column Description

FILTERED ‘Y’ means that the row in the view
was filtered out by a directive (or
combination of directives).
‘N’ means that the row was not
filtered.
• Found in:
– DBA_ADVISOR_FINDINGS
– USER_ADVISOR_FINDINGS
– DBA_ADVISOR_RECOMMENDATIONS
– USER_ADVISOR_RECOMMENDATIONS
– DBA_ADVISOR_ACTIONS
– USER_ADVISOR_ACTIONS
Modified Advisor Views

The views containing advisor findings, recommendations and actions have been enhanced by
adding the above column.

New ADDM Views
• DBA{USER}_ADDM_TASKS: Displays every executed

ADDM task. Are extensions of the corresponding
Advisor views.
• DBA{USER}_ADDM_INSTANCES: Displays instance level
information for ADDM tasks that completed.
• DBA{USER}_ADDM_FINDINGS: Are extensions of the
corresponding Advisor views.
DBA{USER}_ADDM_FDG_BREAKDOWN: Displays the
contribution for each finding from the different
instances for database and partial ADDM.
New ADDM Views

Note: For a complete description of available procedures please see the Oracle Database 11g
documentation set.

Oracle Database 10g SGA Parameters
Automatic Shared Memory Management (ASMM)
• With ASMM five important SGA components can be
automatically tuned.
• Special buffer pools are not auto-tuned
• Log buffer is a static component but has a good default
Auto-tuned Manual Manual
parameters dynamic parameters static parameters
DB_KEEP_CACHE_SIZE LOG_BUFFER_SIZE
SHARED_POOL_SIZE
DB_CACHE_SIZE
LARGE_POOL_SIZE DB_RECYCLE_CACHE_SIZE
SGA_MAX_SIZE
JAVA_POOL_SIZE
STREAMS_POOL_SIZE DB_nK_CACHE_SIZE
SGA_TARGET
Oracle Database 10g SGA Parameters

As shown on the slide, the five most important pools are automatically tuned when Automatic
Shared Memory Management (ASMM) is activated. These parameters are called auto tuned
parameters.
The second category called manual dynamic parameters are parameters that can be manually
resized without having to shutdown the instance, but that are not automatically tune by the
system.
The last category represents the parameters that are fixed in size, and cannot be resized without
shutting down the instance first.

Oracle Database 10g PGA Parameters
Automatic SQL Execution Memory Management
• PGA_AGGREGATE_TARGET:
– Specifies the target aggregate amount of PGA memory
available to the instance
– Can be dynamically modified at the instance level
– Examples: 100000K, 2500M, 50G
– Default value is greater of 10 MB and 20% of SGA size
• WORKAREA_SIZE_POLICY:
– Optional
– Can be dynamically modified at the instance or session
level
– Allows you to fallback to static SQL memory
management for a particular session
Oracle Database 10g PGA Sizing Parameters Status

PGA_AGGREGATE_TARGET specifies the target aggregate PGA memory available to all server
processes attached to the instance.
Setting PGA_AGGREGATE_TARGET to a nonzero value automatically sets the
WORKAREA_SIZE_POLICY parameter to AUTO. This means that SQL working areas used by
memory-intensive SQL operators are automatically sized. A nonzero value for this parameter is
the default since, unless you specify otherwise, Oracle sets it to 20% of the SGA or 10 MB,
whichever is greater. Setting PGA_AGGREGATE_TARGET to 0 automatically sets the
WORKAREA_SIZE_POLICY parameter to MANUAL. This means that SQL work areas are sized
using the *_AREA_SIZE parameters. Keep in mind that PGA_AGGREGATE_TARGET is not set
in stone. It is used to help the system better manage PGA memory, but the system will exceed this
setting if necessary. WORK_AREA_SIZE_POLICY can be altered per database session, allowing
manual memory management on a per session basis if needed. For example, a session is loading a
large import file and a rather large sort_area_size is needed. A logon trigger could be used to set
the WORK_AREA_SIZE_POLICY for the account doing the import. If
WORK_AREA_SIZE_POLICY is AUTO and PGA_AGGREGATE_TARGET is set to 0, we throw
an external error ORA-04032 at startup.
Note: Until Oracle 9i Release 2, PGA_AGGREGATE_TARGET controls the sizing of work areas
for all dedicated server connections, but it has no effect on shared servers connections and the
*_AREA_SIZE parameters take precedence in this case. In Oracle Database 10g,
PGA_AGGREGATE_TARGET controls work areas allocated by dedicated and shared connections.

Oracle Database 10g Memory Advisors
• Buffer Cache Advice (introduced in 9iR1):
– V$DB_CACHE_ADVICE
– Predicts physical read times for different cache sizes
• Shared Pool Advice (in 9iR2):
– V$SHARED_POOL_ADVICE
– Predicts parse times for different sizes of shared pool
• Java Pool Advice (in 9iR2):
– V$JAVA_POOL_ADVICE
– Predicts java class load time for java pool sizes
• Streams Pool Advice (10gR2)
– V$STREAMS_POOL_ADVICE
– Predicts spill and unspill activity time for various sizes
Oracle Database 10g Memory Advisors

In order to help you size the most important SGA components, a number of advisories have been
introduced in the Oracle database. They are listed on the slide:
• V$DB_CACHE_ADVICE contains rows that predict the number of physical reads and time
for the cache size corresponding to each row.
• V$SHARED_POOL_ADVICE displays information about estimated parse time in the shared
pool for different pool sizes.
• V$JAVA_POOL_ADVICE displays information about estimated class load time into the Java
pool for different pool sizes.
• V$STREAMS_POOL_ADVICE displays information about the estimated count of spilled or
unspilled messages and the associated time spent in the spill or unspill activity for different
Streams pool sizes.
Note: For more information about these views, refer to the Oracle Database Reference guide.

11g New Features For Administrators Student Guide-6

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

11g New Features For Administrators Student Guide-6

Hochgeladen von

Copyright:

Verfügbare Formate

Default Maintenance Resource Manager Plan

SQL> show parameter resource_manager_plan

NAME TYPE VALUE

7 - 27 Copyright © 2007, Oracle. All rights reserved.

When a maintenance window opens, DEFAULT_MAINTENANCE_PLAN resource manager

Oracle Database 11g: New Features for Administrators 7 - 27

7 - 28 Copyright © 2007, Oracle. All rights reserved.

Automated Maintenance Tasks feature is implemented by a background process: Autotask

Oracle Database 11g: New Features for Administrators 7 - 28

7 - 29 Copyright © 2007, Oracle. All rights reserved.

Oracle Database 11g: New Features for Administrators 7 - 29

Disk bandwidth Channel bandwidth

Metric = IOPS Metric = MBPS

7 - 30 Copyright © 2007, Oracle. All rights reserved.

Important I/O Metrics for Oracle Databases

Oracle Database 11g: New Features for Administrators 7 - 30

Oracle Database 11g: New Features for Administrators 7 - 31

7 - 32 Copyright © 2007, Oracle. All rights reserved.

I/O Calibration and Enterprise Manager

Oracle Database 11g: New Features for Administrators 7 - 32

SQL> exec dbms_resource_manager.calibrate_io( -

PL/SQL procedure successfully completed.

SQL> select * from v$io_calibration_results;

STATUS LATENCY MAX_IOPS MAX_MBPS NUM_DISKS CALIBRATION_TIME

7 - 33 Copyright © 2007, Oracle. All rights reserved.

I/O Calibration and PL/SQL interface

7 - 34 Copyright © 2007, Oracle. All rights reserved.

I/O Statistics Overview

7 - 35 Copyright © 2007, Oracle. All rights reserved.

I/O Statistics and Enterprise Manager

Oracle Database 11g: New Features for Administrators 7 - 35

7 - 36 Copyright © 2007, Oracle. All rights reserved.

I/O Statistics and Enterprise Manager

Oracle Database 11g: New Features for Administrators 7 - 36

7 - 37 Copyright © 2007, Oracle. All rights reserved.

Resource Manager New EM Interface

Oracle Database 11g: New Features for Administrators 7 - 37

7 - 38 Copyright © 2007, Oracle. All rights reserved.

Resource Manager Plans Created by Default

Oracle Database 11g: New Features for Administrators 7 - 38

SQL> show parameter resource_manager_plan

NAME TYPE VALUE

7 - 39 Copyright © 2007, Oracle. All rights reserved.

Default Maintenance Resource Manager Plan

Oracle Database 11g: New Features for Administrators 7 - 39

7 - 40 Copyright © 2007, Oracle. All rights reserved.

Oracle Database 11g: New Features for Administrators 7 - 40

7 - 41 Copyright © 2007, Oracle. All rights reserved.

I/O Resource Limit Thresholds

Oracle Database 11g: New Features for Administrators 7 - 41

7 - 42 Copyright © 2007, Oracle. All rights reserved.

You can also look at the Resource Manager Statistics page

Oracle Database 11g: New Features for Administrators 7 - 42

• Scheduling Streams Propagation Jobs using Oracle

7 - 43 Copyright © 2007, Oracle. All rights reserved.

Oracle Database 11g: New Features for Administrators 7 - 43

7 - 44 Copyright © 2007, Oracle. All rights reserved.

Oracle Database 11g: New Features for Administrators 7 - 44

7 - 45 Copyright © 2007, Oracle. All rights reserved.

Oracle Database 11g: New Features for Administrators 7 - 45

1. Set the source for remote jobs for this database

7 - 46 Copyright © 2007, Oracle. All rights reserved.

The following steps are necessary to run a remote external job.