Steven George Sr. Delivery Manager

Steven George Sr. Delivery Manager
Mark Fuller Sr. Pr. Instructor Rick Pandya Pr. Instructor JF Verrier Pr. Curriculum Developer Oracle Corporation

Oracle Database 10 g: Managing the Self-Managing Database

Objectives Understanding the self-management capabilities of Oracle Database 10 g Customizing the self-management capabilities of Oracle Database 10 g

½ Cost Manageability Goal Reduce Administration Cost
Automatic versus Manual Intelligence versus Data Reduce Capital Expenditure Adaptive versus Oversized Integrated versus Third Party ½ Cost Reduce Failure Cost Preventive versus Corrective Act and Succeed versus Trial and Error

How DBAs Spend Their Time
Install 6% Create and Configure 12% Load Data 6% Manage Database System 55% The bulk of a DBA’s time is spent performing ongoing management. Ongoing management tasks include: SQL and application tuning System resource tuning Space and object management Backup and recovery Storage management Although this presentation concentrates on the new Oracle Database 10g manageability features that are used to simplify the ongoing management tasks, a lot more has also been done for the other areas of a DBA’s job. For example, Oracle Database 10g includes: Fast and lightweight installation with automatic pre- and post-install validations Automatic configuration of all administration tools and components Preset values for advanced initialization parameters so that only a small number of basic initialization parameters need to be set Support for cross-platform transportable tablespaces and Data Pump for fast data loading Simplification of upgrades using pre- and post-upgrade checks Use of a single upgrade script Restartable processes (such as upgrades) Note: DBA time allocation statistics are based on the IOUG 2001 DBA Survey. Maintain Software 6%

Database Management Challenges
? ? Application and SQL Management ? Storage Management System Resource Management ? Backup and Recovery Management Space Management ? With previous releases of the Oracle server, a good portion of the DBA’s time was spent on monitoring database system health, identifying bottlenecks, and improving system performance. Some of the tasks included: Application and SQL management: Creation of indexes, collection of Oracle optimizer statistics System resource management: Monitoring CPU utilization, sizing the various database buffers Space management: Sizing the various database files, monitoring space utilization within segments Backup and recovery management: Monitoring the mean time to recover the database, planning for disaster recovery, backing up the database Storage management: Configuring disks, monitoring the I/O bandwidth, determining the stripe size

Solution: Self-Managing Database
Application and SQL Management Enterprise Manager Database Console Storage Management System Resource Management Monitor Alert Automatic Management Fix Advise Backup and Recovery Management Space Management Common Manageability Infrastructure The Oracle Database 10g can now automatically inform you of performance and resource allocation problems. In addition to providing you suggestions for fixing these problems, the Oracle server can also automatically fix the problems for you.

Common Manageability Infrastructure: Automatic Workload Repository
Automated Tasks Proactive Server Alerts Advisory Framework Automatic Workload Repository Efficient The principal elements of the common manageability infrastructure are: Automatic Workload Repository (AWR): This component is the central element of the new manageability infrastructure. It provides services to internal Oracle server components to collect, process, maintain, and access performance statistics for problem detection and self-tuning purposes. Server-based advisors: As part of this new architecture, multiple server-based advisors are created. These advisors are designed around a common infrastructure that makes them easy to manage. For example, the Automatic Database Diagnostic Monitor (ADDM) is the ultimate solution for Oracle database tuning. The ADDM automatically identifies bottlenecks within the Oracle server, and additionally makes recommendations on the options available to fix them. Automatic Routine Administration Tasks: By using the Scheduler, you can delegate to the Oracle server some of the repetitive tasks that need to be performed to keep your database functioning well. For example, the Scheduler now schedules routine administration tasks, such as analyzing optimizer statistics. Server-generated Alerts: The Oracle server can automatically detect alarming situations. In reaction to a detected problem, the Oracle server sends you an alert message with possible remedial actions. Data Warehouse of the Database Direct memory access Automatic collection of important statistics

Automatic Workload Repository
ADDM finds top problems MMON SYSAUX WR Schema BG In-memory statistics … 7:00 a.m. Snapshot 1 BG 7:30 a.m. Seven days AWR Statistics Snapshot 2 ASH 8:00 a.m. FG 8:30 a.m. Snapshot 3 … Snapshot 4 FG SGA The Automatic Workload Repository (AWR) is the infrastructure that provides services to the Oracle server components to collect, maintain, and utilize statistics for problem detection and self-tuning purposes. AWR is part of the management monitoring infrastructure. The diagram shows you how AWR fits in with the rest of the infrastructure. AWR consists of two major parts: An in-memory statistics collection facility that is used by Oracle server components to collect statistics. These statistics are stored in memory for performance reasons. Statistics stored in memory are accessible through fixed views. The most important new statistics used by AWR are time model, wait classes, new SQL statistics, OS stats, metrics, and the Active Session History (ASH), which represents the history of recent sessions activity. The Workload Repository is the persistent portion of the facility. Statistics stored inside the Workload Repository are accessible through dictionary views and are mainly used for historical analyses. The data in the Workload Repository is used by internal components for self-tuning and is accessible to external users. The data is stored in the system-defined WR schema, which resides in the new SYSAUX tablespace. The in-memory version of the statistics is transferred to disk (in the form of snapshots) every 30 minutes by a new background process called MMON. 8:30am DBA

Statistics Level STATISTICS_LEVEL BASIC TYPICAL ALL
Turn off all self-tuning capabilities Recommended default value Additional statistics for manual SQL diagnostics You can control the set of statistics to capture by using the STATISTICS_LEVEL initialization parameter. If STATISTICS_LEVEL is set to: BASIC: The computation of AWR statistics and all self-tuning capabilities are turned off. TYPICAL: Only part of the statistics are collected. They represent what is typically needed to monitor the Oracle server behavior. ALL: All possible statistics are captured.

Configuring The Workload Repository
Although the preset values for the AWR should be adequate in most environments, you can modify the settings to suit your needs. Enterprise Manager (EM) allows you to configure the RETENTION, INTERVAL, and STATISTICS_LEVEL parameters for capturing snapshots. You can access the corresponding EM page by clicking the Administration link and then the Workload Repository link. You are also able to get more details about each captured snapshot as well as create new ones. You can also create baselines if needed.

Manually Creating Snapshots
From this page, you can create your own snapshots as well as baselines. This page also gives you details about captured snapshots.

Database Feature Usage Metric Collection
Oracle Database 10g Once a week DB Feature Usage Statistics DB High-Water Mark Statistics MMON Advanced Replication, Oracle Streams, AQ, Virtual Private Database, Audit options, … size of largest segment, maximum number of sessions, maximum number of tables, maximum size of the database, maximum number of data files, … AWR DBA_FEATURE_USAGE_STATISTICS DBA_HIGH_WATER_MARK_STATISTICS The Workload Repository is also used to track Oracle database usage metrics. The Oracle database usage metrics represent the information that keeps track of how you use the Oracle database. The Oracle database usage metrics are divided into two categories: Database feature usage statistics High-water mark (HWM) values of certain database attributes Examples of each category are shown in the slide. Usage and HWM statistics are useful in the following scenarios: You want to determine how often a particular feature has been used. You want to have an idea of certain resource usage of your database. Once a week, MMON tracks and records the database feature usage and HWM statistics. The tracking mechanism uses a sampling method of the data dictionary. Statistics are recorded inside the Workload Repository. The recorded statistics can be viewed through EM. HOST CONFIGURATION INFO EM Console EM Repository: ECM

Common Manageability Infrastructure: Server Alerts
Automatic Automated Tasks Proactive Server Alerts Advisory Framework Automatic Workload Repository Efficient The principal elements of the common manageability infrastructure are: Automatic Workload Repository (AWR): This component is the central element of the new manageability infrastructure. It provides services to internal Oracle server components to collect, process, maintain, and access performance statistics for problem detection and self-tuning purposes. Server-based advisors: As part of this new architecture, multiple server-based advisors are created. These advisors are designed around a common infrastructure that makes them easy to manage. For example, the Automatic Database Diagnostic Monitor (ADDM) is the ultimate solution for Oracle database tuning. The ADDM automatically identifies bottlenecks within the Oracle server, and additionally makes recommendations on the options available to fix them. Automatic Routine Administration Tasks: By using the Scheduler, you can delegate to the Oracle server some of the repetitive tasks that need to be performed to keep your database functioning well. For example, the Scheduler now schedules routine administration tasks, such as analyzing optimizer statistics. Server-generated Alerts: The Oracle server can automatically detect alarming situations. In reaction to a detected problem, the Oracle server sends you an alert message with possible remedial actions. Push model Enabled by default Timely generation

Automatic Notification Server monitors itself
Server Alerts Enterprise Manager Guided Resolution Automatic Notification Server Alerts Queue Server monitors itself Oracle Server (SGA) AWR Currently, a good portion of the DBA’s time is spent on monitoring the database system’s health in order to identify bottlenecks and improve system performance. Oracle Database 10g takes over some of these tasks, automatically informs you if there are any performance or resource allocation problems, and provides suggestions for remedial actions. With the introduction of the new background process MMON, Oracle server components can schedule monitoring actions to be performed periodically. The Oracle server components that detect a problem may generate an alert message for you to act upon. Similarly, foreground processes may discover some unusual conditions and invoke an urgent action to be run by MMON. The action in turn can produce an alert message to be sent to you. In both cases, these alert messages are pushed in a reliable and timely manner. The alert message contains a description of the problem and advice on how to fix it. In addition, the Oracle server keeps a history of the statistics in the Workload Repository. This information can be used later by the self-tuning components of the Oracle server. MMON

Server Alerts Delivery Process
Subscribing Clients Console Update Third Party Queue BG Advanced Queue Push FG EM (EMD) Page or DBAs An alerts condition discovery is based on some internally determined or customer-defined threshold. Whenever such a situation occurs, the Oracle server does the following: Creates an alert containing the following information: Identity of an object on which the recommendation is produced. Objects can be any database entity (for example, tablespaces). Description of the problem Brief advice on a corrective action Advisory name for more detailed advice (optional) Status or level of severity Queues the alert into the predefined persistent queue ALERT_QUE owned by SYS The severity level of an outstanding alert can be updated to reflect the current status of the problem. When that happens, a new alert message is sent out. When the problem condition is cleared, the outstanding alert is moved to the alert history. Alert history is purged according to Workload Repository snapshot purging policy. By default, any alerts with resolution time longer than seven days are purged. EM is used to notify you about outstanding alerts. EM is the main consumer of the ALERT_QUE. Depending on the EM setup for alerts, administrators are notified via or pager. Server-generated alerts are always displayed on the EM console.

Server-Generated Alert Types
Metric-Based Alert 97% Critical Cleared Threshold Alerts Alert 85% Warning Cleared MMON Resumable Session Suspended Recovery Area Low On Free Space Snapshot Too Old Non- Threshold Alerts There are two kinds of server-generated alerts: threshold and non-threshold. Most Oracle server-generated alerts are configured by setting two threshold values on database metrics: Warning threshold Critical threshold There are 161 metrics for which you can define thresholds. Examples of metric threshold alerts: Physical Reads Per Sec User Commits Per Sec SQL Service Response Time Examples listed here are per instance rather than per database (such as the Tablespace Space Usage metric). Other server-generated alerts correspond to specific database events, such as the following: Snapshot Too Old Recovery Area Low On Free Space Resumable Session Suspended Alert Alert Alert Event-Based

Out-of-the-box Alerts
97% Critical 85% Warning Locally Managed Tablespace Tablespace Space Usage By default, the following server-generated alerts are enabled: Tablespace Space Usage (warning 85%, critical 97%) Snapshot Too Old Recovery Area Low On Free Space Resumable Session Suspended Note: Other alerts may be enabled out of the box through the Enterprise Manager alert framework. Resumable Session Suspended Recovery Area Low On Free Space Snapshot Too Old

EM Interface to Alerts If you are using EM, the server-generated alerts are displayed on the Database home page as shown in the illustration. The server-generated alerts behave the same way as the EM alerts. In addition to what was previously supported, EM enables you to set thresholds based on a given baseline or an arbitrary pair of snapshots. Most alerts contain the name of an associated advisor that can be invoked to give you more detailed advice. For each corresponding alert message, EM provides a link to invoke the corresponding advisor.

Setting Alert Thresholds
From the Database home page, you can go to the Edit Metric Thresholds page, where you can change default settings for the defined metric thresholds. Note: The majority of alerts in EM and in the database are threshold based.

Common Manageability Infrastructure: Automated Tasks
Automatic Automated Tasks Proactive Server Alerts Advisory Framework Automatic Workload Repository Efficient The principal elements of the common manageability infrastructure are: Automatic Workload Repository (AWR): This component is the central element of the new manageability infrastructure. It provides services to internal Oracle server components to collect, process, maintain, and access performance statistics for problem detection and self-tuning purposes. Server-based advisors: As part of this new architecture, multiple server-based advisors are created. These advisors are designed around a common infrastructure that makes them easy to manage. For example, the Automatic Database Diagnostic Monitor (ADDM) is the ultimate solution for Oracle database tuning. The ADDM automatically identifies bottlenecks within the Oracle server, and additionally makes recommendations on the options available to fix them. Automatic Routine Administration Tasks: By using the Scheduler, you can delegate to the Oracle server some of the repetitive tasks that need to be performed to keep your database functioning well. For example, the Scheduler now schedules routine administration tasks, such as analyzing optimizer statistics. Server-generated Alerts: The Oracle server can automatically detect alarming situations. In reaction to a detected problem, the Oracle server sends you an alert message with possible remedial actions. Statistics collection task scheduled out-of-the-box Pre-packaged routine maintenance tasks Resource usage controlled

Automatic Optimizer Statistics Collection
DBA tracks and gathers statistics Targets right objects Resolves two issues Automatic Optimizer Statistics Collection is one of the task types supported by Automated Tasks. For the cost-based optimizer (CBO) to generate optimal execution plans, it must have valid statistics on the objects. In the past, collecting statistics (or setting up jobs to do so) was typically a task for the DBA. In addition, it was necessary to keep track of changes to objects to determine if statistics collection was necessary. If an object had stale statistics or no statistics, inefficient SQL execution plans would be generated. Automatic Optimizer Statistics Collection automates this task and relieves you of the necessity of manually gathering these statistics for database objects. This feature reduces the likelihood of poorly performing SQL statements due to stale or invalid statistics and enhances SQL execution performance by providing optimal input to the CBO. Determines right samples Automatic statistics collection

Gather Statistics Job MAINTENANCE_WINDOW_GROUP WEEKNIGHT_WINDOW
WEEKEND_WINDOW 10pm–6am Mon to Fri 12am Sat to 12am Mon gather_stats_job AUTO_TASKS_JOB_CLASS The GATHER_STATS_JOB is automatically created at database creation time. This task executes the DBMS_STATS.GATHER_DATABASE_STATS_JOB_PROC procedure and uses the Scheduler as shown in the diagram. Two windows are also defined automatically: WEEKNIGHT_WINDOW is predefined between 10 p.m. and 6 a.m. from Monday to Friday. WEEKEND_WINDOW is predefined between 12 a.m. on Saturday and 12 a.m. on Monday. You can customize these management windows. For example, you can change the time interval, repeat frequency, and resource plan. These two windows belong to a predefined group called MAINTENANCE_WINDOW_GROUP. GATHER_STATS_JOB uses a specific Scheduler class, called AUTO_TASKS_JOB_CLASS. This class is automatically created by the Oracle server and is associated with a specific resource consumer group, called AUTO_TASKS_CONSUMER_GROUP. If you want to control resources used by GATHER_STATS_JOB, all you need to do is define a resource plan and specify the resource to allocate to the AUTO_TASKS_CONSUMER_GROUP. You must then associate the resource plan with the windows in the MAINTENANCE_WINDOW_GROUP. AUTO_TASKS_CONSUMER_GROUP

Adding New Tasks Using EM
You can add your own customized tasks by adding a new job using the Scheduler. To do so, click the Administration tab on the Database home page. Next, click the Jobs link, and then click the Create Job button.

Creating Automated Tasks
D E M O N S T R A T I O N Creating Automated Tasks

Common Manageability Infrastructure: Advisory Framework
Automatic Automated Tasks Proactive Server Alerts Advisory Framework Automatic Workload Repository Efficient The principal elements of the common manageability infrastructure are: Automatic Workload Repository (AWR): This component is the central element of the new manageability infrastructure. It provides services to internal Oracle server components to collect, process, maintain, and access performance statistics for problem detection and self-tuning purposes. Server-based advisors: As part of this new architecture, multiple server-based advisors are created. These advisors are designed around a common infrastructure that makes them easy to manage. For example, the Automatic Database Diagnostic Monitor (ADDM) is the ultimate solution for Oracle database tuning. The ADDM automatically identifies bottlenecks within the Oracle server, and additionally makes recommendations on the options available to fix them. Automatic Routine Administration Tasks: By using the Scheduler, you can delegate to the Oracle server some of the repetitive tasks that need to be performed to keep your database functioning well. For example, the Scheduler now schedules routine administration tasks, such as analyzing optimizer statistics. server-generated Alerts: The Oracle server can automatically detect alarming situations. In reaction to a detected problem, the Oracle server sends you an alert message with possible remedial actions. Uniform interface Fully integrated

Advisory Framework SQL Tuning PGA Buffer Cache Memory SGA ADDM Access
Shared Pool Space Segment Advisor Undo AWR Advisors are server components that provide you with useful feedback about resource utilization and performance for its respective component. Here is the list of pre-created advisors: Automatic Database Diagnostic Monitor (ADDM): An advisor for the database instance. It provides a top-down analysis of the system, identifies problems and their potential causes, and provides recommendations for fixing the problems. SQL Tuning Advisor: Responsible for providing tuning advice for a SQL statement. SQL Access Advisor: Deals with schema issues and determines optimal ways to access data. PGA Advisor: Gives detailed statistics for the work areas and recommends optimal usage of PGA memory based on your workload. SGA Advisor: Responsible for tuning and recommending SGA size depending on pattern of access for the various components within the SGA: Buffer Cache Advisor: Predicts cache hit rates for buffer access for different sizes of the buffer cache. Library Cache Advisor: Predicts the cursor cache hit rate for the library cache for different sizes. Segment Advisor: Responsible for space issues regarding a database object. It analyzes the growth trends. Undo Advisor: Suggests parameter values and the amount of additional space that is needed to support flashback for a specified time. Common data source Seamless integration

Guided Tuning Session Create an advisor task Adjust task parameters
Enterprise Manager Database Console Perform analysis No Accept results? Yes A typical tuning session consists of the following steps: 1. Create an advisor task. An advisor task is an executable data area in the advisor repository that manages your tuning efforts. 2. Adjust appropriate task parameters. Parameters are set in the main advisor task. They control the advisor’s behavior. Typical parameters include TARGET_OBJECTS, TIME_WINDOW, and TIME_LIMIT, in addition to advisor-specific parameters. The TIME_WINDOW parameter denotes the time period that the advisor must consider for its analysis. 3. Perform an analysis. This step initiates the execution of the task, which is a synchronous operation. Control is not returned to the caller until the operation has completed or a user interruption is detected. 4. Review the results. The results of the analysis can be reviewed using the built-in views or procedures. You have the option of accepting, rejecting, or ignoring the recommendations. If a recommendation is rejected, you may wish to rerun an analysis using the rejected recommendation as advice to the next analysis operation. Implement recommendations

Advisory Central This is the central page for all advisors. You are able to launch advisors by selecting an advisor in the Launch Advisor choice box and then clicking the Go button corresponding to the choice box. Note: The Advisory Central page can be accessed from the Database home page.

Application and SQL Management Enterprise Manager Database Console Storage Management System Resource Management Monitor Alert Automatic Management Fix Advise Backup and Recovery Management Space Management The Oracle Database 10g can now automatically inform you of performance and resource allocation problems. In addition to providing you suggestions for fixing these problems, the Oracle server can also automatically fix the problems for you. Common Infrastructure

Performance Monitoring Solutions
SGA In-memory statistics MMON Snapshots Alerts ADDM ADDM Results Proactive Monitoring within Oracle Server AWR DBA With previous releases of the Oracle server, you were only able to retrieve statistical information for some of the important areas. So the tuning process was tedious and error prone; it could lead to a waste of your time and efforts. Oracle Database 10g introduces new and more effective methods to monitor your database. Proactive monitoring, with two main components: Automatic Database Diagnostic Monitor (ADDM). This component is the ultimate solution for Oracle database tuning. The ADDM automatically identifies bottlenecks within the Oracle server. Additionally, working with other manageability components, the ADDM makes recommendations on the options available for fixing these bottlenecks. Server-generated alerts: This is the capability of the Oracle server to automatically detect alarming situations. In reaction to a detected problem, the Oracle server sends you an alert message with possible remedial actions. Reactive monitoring: The Oracle server has powerful new data sources and performance- reporting capabilities. Enterprise Manager provides an integrated performance management console that uses all relevant data sources. Using a drill-down method, you are able to manually identify bottlenecks in a few mouse clicks. New data sources are introduced to capture important information about your database’s health: for example, new in-memory statistics for real-time diagnostics as well as statistics history stored in the Automatic Workload Repository. Reactive Monitoring

ADDM Performance Monitoring
SGA 30 minutes In-memory statistics MMON Snapshots ADDM ADDM Results EM AWR Every 30 minutes, the database automatically captures statistical information from the SGA and stores it inside the Automatic Workload Repository in the form of snapshots. These snapshots are stored on disk and are similar to statspack snapshots. However, they contain more precise information than statspack snapshots. Additionally, the ADDM is scheduled to run automatically by the new MMON process on every database instance to detect problems proactively. Each time a snapshot is taken, the ADDM is triggered to do an analysis of the period corresponding to the last two snapshots. The ADDM proactively monitors the instance and detects bottlenecks before they become a significant problem. The results of each ADDM analysis are stored inside the Automatic Workload Repository and are accessible through the Enterprise Manager console. Note: You can also manually invoke ADDM from the Advisory Central EM page. By manually invoking ADDM, you can perform analysis across any two snapshots. ADDM Results

ADDM Problem Classification System
… … RAC Waits Buffer Busy System Wait Concurrency Parse Latches … Buf Cache latches IO Waits … With previous releases of the Oracle server, statspack was unable to identify some problems because of lack of granularity in the statistics. With the introduction of the new wait and time model statistics in Oracle Database 10g, ADDM is able to identify the top performance issues. Another benefit of ADDM is that it concentrates its analysis on top problems (the ones that impact the system most). Internally, ADDM uses a tree structure to represent all possible tuning issues. The tree is based on the new wait and time model statistics used by the Oracle Database. The root of this tree represents the symptoms, and going down to the leaves, ADDM identifies root causes. ADDM walks down the tree using time-based thresholds for each node. If the time-based threshold is not exceeded for a particular node, ADDM prunes the corresponding sub-tree. This allows ADDM to identify non-problem areas. This tree structure allows ADDM to efficiently prune the search space to quickly identify the problems. Non-problem areas Symptoms Root Causes

Accessing ADDM Advice By looking at your Database home page through the EM console, you can see the Advice section, which gives you the number of ADDM findings from the previous automatic run. By clicking the ADDM Findings link, you are directed to the ADDM Findings page, where you can access the details of the latest ADDM run.

ADDM Recommendations On the ADDM Finding Details page, you are given recommendations to solve the corresponding issue. Recommendations are identified by SCHEMA, SQL Tuning, DB configuration, and many other categories. The Benefit column gives you the maximum reduction in service request elapse time if the recommendation is implemented.

Performance Monitoring Solutions
SGA In-memory statistics MMON Snapshots Alerts ADDM ADDM Results Proactive Monitoring within Oracle Server AWR DBA With previous releases of the Oracle server, you were only able to retrieve statistical information for some of the important areas. So the tuning process was tedious and error prone; it could lead to a waste of your time and efforts. Oracle Database 10g introduces new and more effective methods to monitor your database. Proactive monitoring, with two main components: Automatic Database Diagnostic Monitor (ADDM). This component is the ultimate solution for Oracle database tuning. The ADDM automatically identifies bottlenecks within the Oracle server. Additionally, working with other manageability components, the ADDM makes recommendations on the options available for fixing these bottlenecks. Server-generated alerts: This is the capability of the Oracle server to automatically detect alarming situations. In reaction to a detected problem, the Oracle server sends you an alert message with possible remedial actions. Reactive monitoring: The Oracle server has powerful new data sources and performance- reporting capabilities. Enterprise Manager provides an integrated performance management console that uses all relevant data sources. Using a drill-down method, you are able to manually identify bottlenecks in a few mouse clicks. New data sources are introduced to capture important information about your database’s health: for example, new in-memory statistics for real-time diagnostics as well as statistics history stored in the Automatic Workload Repository. Reactive Monitoring

Performance Management Approach
CPU/Waits SQL Sessions Host Oracle CPU Bottlenecks Memory Bottlenecks Uses ASH and AWR Enterprise Manager allows you to correlate both host and instance bottlenecks by giving you detailed statistics from both sides. There is indeed no need to tune an Oracle instance on a host system when there is a general lack of system resources. You can differentiate the work executed by Oracle from work that is executed outside of Oracle. EM provides you with information about three major Oracle tuning areas: CPU and wait classes Top SQL statements impacting the Oracle instance Top sessions impacting the Oracle instance For each of the preceding dimensions, EM gives you real-time data by extracting statistics from the Active Session History (ASH), or historical data by extracting statistics from the Automatic Workload Repository (AWR). On most of the performance-related EM pages, you can drill down to these three dimensions.

Enterprise-wide Console Page Database Performance Page
EM Product Layout Enterprise-wide Console Page Target Databases Page Database Home Page Database Performance Page Drilldowns SQL Session The diagram shows you the basic navigational flow inside EM. With just a few mouse clicks, you can narrow down the possible problems: The Console page is the one that you see the first time you log in to EM. This page gives you a summary of all monitored targets. The Target Databases page gives you a high-level overview of all monitored databases. You can use this page to determine which instance needs immediate attention. The Database home page gives you a specific overview of a particular instance. This page includes outstanding alerts and recent ADDM findings. The Database Performance page gives you specific details about current and past wait-class statistics. From this page, you can see snapshot intervals. From here you can drill down to: Specific wait events Related top SQL statement statistics Top session statistics

Database Performance Page
The next series of screen shots identifies a Buffer Busy Waits scenario. On the Database Performance page, you can see the main graphic that illustrates the most important classes of wait time spent by the instance. Basically, wait events are now categorized in different classes. In this example, the Concurrency wait class has been predominant on this instance since 7:50 p.m. You can also see the frequency at which snapshots are taken. The graphic displays the maximum number of available CPU on your system. In the example, the system has only one CPU, and you can see that the Concurrency wait class is significantly above the maximum CPU. You should therefore click the Concurrency wait class to drill down into the problem. Note: From the Performance page, click the corresponding snapshot icon to see the Snapshot Details page.

Concurrency Wait Class: Drill Down
This page gives you more details about the concurrency problem. Here you can find the three performance dimensions discussed previously. The upper portion of the page gives you details about the wait events for the Concurrency class. Here the buffer busy wait in the Concurrency class is the most important one. You can move the time window along the time line to go back in history. Once the time window is set, the Overview charts are automatically updated to reflect the corresponding period. The Overview tab contains two charts: Corresponding top SQL statements Corresponding top sessions Only the top problems are shown. In this example, you can see that the problem is evenly distributed across each top session (around 12%). Each of these sessions is experiencing important buffer busy waits. The top sessions are all apparently executing the same SQL statement, which takes up almost all resources (around 93%). The basic idea behind these graphics is to show the same information aggregated along different dimensions. You can click the Top SQL link to get more details about the problematic SQL statements.

Automate the SQL Tuning Process
I can do it for you! SQL Workload ADDM DBA The process of identifying high-load SQL statements and tuning them is very challenging even for an expert. SQL tuning is not only one of the most critical aspects in managing the performance of a database server; it is also one of the most difficult tasks to accomplish. With Oracle Database 10g, the task of identifying high-load SQL statements has been automated by ADDM. Even though the number of high-load SQL statements identified by ADDM may represent a very small percentage of total SQL workload, the task of tuning them is still complex and requires a high level of expertise. The SQL Tuning Advisor is a new feature of Oracle Database 10g designed to replace the manual tuning of SQL statements, a task that constituted a significant part of a DBA’s and application developer’s time and effort. SQL statements that have a slow response time or are consuming high resources (such as CPU, I/O, temporary space) are good candidates for the SQL Tuning Advisor. The advisor receives one or more SQL statements as input and provides advice on how to optimize their execution plan, rationale for the advice, the estimated performance benefit, and the actual command to implement the advice. The user can simply choose to accept the advice, thus tuning the SQL statements. With the introduction of the SQL Tuning Advisor, you can now let the Oracle optimizer tune the SQL code for you. High-load SQL SQL Tuning Advisor

SQL Tuning Advisor Overview
Automatic Tuning Optimizer Comprehensive SQL Tuning Detect Stale or Missing Statistics Statistics Check Optimization Mode SQL Tuning Advisor Plan Tuning Optimization Mode Plan Tuning (SQL Profile) Add Missing Index Run Access Advisor Access Analysis Optimization Mode SQL Analysis Optimization Mode Restructure SQL The SQL Tuning Advisor is primarily the driver of the tuning process. It calls the CBO in a special internal mode in which the CBO performs the following four specific types of analysis: Stale or missing statistics analysis: Objects with stale or missing statistics are automatically recommended for statistics collection to be performed on them. Plan tuning analysis (SQL Profile): The SQL Profile includes historical information of prior runs of a SQL statement, comparison of actual and estimated cardinality, and predicate selectivity. The CBO actually runs portions of a SQL statement in the background to generate a comprehensive profile. This allows the CBO to adapt itself to a particular SQL statement given the additional information, and makes possible the generation of a well-tuned plan. The SQL Profile is stored persistently in the data dictionary and hence does not require any application code changes. Access path analysis: The CBO recommends new indexes that produce a significantly faster execution path. It may recommend the running of SQL Access Advisor. Restructure SQL: The CBO identifies SQL statements that lend themselves to bad plans, and makes relevant suggestions to restructure them. The suggested restructured query is very similar but not identical to the original statement. Thus, only a DBA or application developer can decide whether the suggestion is valid for a specific environment.

No application code change
Plan Tuning Flow SQL Tuning Advisor Optimizer (Tuning Mode) submit create SQL Profile use No application code change Database Users Optimizer (Normal Mode) output Under normal mode, the CBO produces the best possible execution plan with whatever information is currently available for the query. It cannot afford to gather additional information that might improve the plan, since the CBO has to generate an execution plan in a fraction of a second under normal mode. However, in the Plan Tuning Analysis mode, the CBO has time to gather additional information for the query (in the form of a SQL Profile), and this profile allows the generation of a superior execution plan that is well tuned. In the Plan Tuning Analysis mode, the CBO collects the SQL Profile for the query automatically, and you can then decide whether to activate the profile or not. Once it is activated, the CBO uses the SQL Profile under normal mode to generate a well-tuned plan that is superior to the original. The SQL Profile is stored persistently in the data dictionary. This form of tuning, therefore, does not require any application code changes. Well-Tuned Plan

SQL Tuning Advisor Usage Model
Automatic Selection AWR ADDM High-load SQL SQL Tuning Advisor Sources AWR Manual Selection STS Cursor Cache Filter/Rank The SQL Tuning Advisor takes one or more SQL statements as input. The input can come from many different sources: High-load SQL statements identified by ADDM SQL statements that are currently in cursor cache SQL statements from the AWR: A user can select any set of SQL statements captured by the AWR. By default, AWR maintains data for up to seven days. A user can go back to any time during the last seven days and tune statements selectively. Custom workload: A user can create a custom workload consisting of statements of interest to the user. These may be statements that are neither in cursor cache nor are high-load to be captured by ADDM or AWR. For such statements, a user can create a custom workload and tune it using the advisor. SQL statements from cursor cache, AWR, and custom workload can be filtered and/or ranked before they are input to the SQL Tuning Advisor. For multi-statement input, a new object called SQL Tuning Set (STS) is provided. An STS stores multiple SQL statements along with their execution information: Execution context: parsing schema name and bind values Execution statistics: average elapsed time and execution count Note: A possible source for STS creation can be another STS. DBA Custom

Resolving Performance Problems
D E M O N S T R A T I O N Resolving Performance Problems

Overview of Automatic Shared Memory Management
Shared Pool Database Buffer Cache Redo Log Buffer Java Pool Fixed SGA Large Pool SGA MMAN The system global area (SGA) is internally divided into memory components. A component represents a pool of memory used to satisfy a particular class of memory allocation requests. The most commonly configured memory components include the database buffer cache, shared pool, large pool, and Java pool. You can use the Automatic Shared Memory Management feature of Oracle Database 10g to enable the Oracle server to automatically determine the size of each of these memory components within the limits of the total SGA size. Note: The Automatic Shared Memory Management feature uses a new background process named Memory Manager (MMAN), which serves as the SGA Memory Broker and coordinates the sizing of the memory components. The SGA Memory Broker keeps track of the sizes of the components and pending resize operations. Automatically set the optimal size

Benefits of Automatic Shared Memory Management
DB_CACHE_SIZE SHARED_POOL_SIZE LARGE_POOL_SIZE JAVA_POOL_SIZE Total SGA size Automatic Shared Memory Management simplifies the configuration of the SGA. In the past, you needed to manually specify the amount of memory to be allocated for the database buffer cache, shared pool, Java pool, and large pool. It was often a challenge to optimally size these components. Undersizing can lead to poor performance and out-of-memory errors (ORA-4031), while oversizing can waste memory. This new feature enables you to specify a total memory amount to be used for all SGA components. The Oracle server periodically redistributes memory between the above components according to workload requirements. In earlier releases of the Oracle server, the user did not have exact control over the total size of the SGA since memory was allocated by Oracle for the fixed SGA and for other internal metadata allocations over and above the total size of the user-specified SGA parameters. This additional memory was usually small (measured in tenths of megabyte)s. The new SGA size parameter SGA_TARGET now includes all the memory in the SGA, including all the automatically sized components, manually sized components, and any internal allocations during startup. SGA_TARGET

Using EM to Configure Automatic Shared Memory Management
You can use Enterprise Manager to configure Automatic Shared Memory Management as follows: 1. Select your database. 2. Select the Administration tab. 3. Select Memory Parameters under the Instance heading. 4. Select the SGA tab. 5. Click the Enable button for Automatic Shared Memory Management, and then enter the total SGA size in megabytes.

Automating Memory Management
D E M O N S T R A T I O N Automating Memory Management

Segment Shrink Overview
Data Unused Space Unused Space Data HWM Online and in-place Shrink Operation Reclaimed Space The upper part of the diagram shows you a sparsely populated segment, with some unused space both above and below the segment’s high-water mark (HWM). When such a situation occurs, the segment may suffer bad performance during scans and DML operations due to the following: Data is spread across multiple data blocks (thus, more I/Os). Row chaining exists. Unused space remains unavailable for use by other objects in need. When space used by an object at a steady state is much less than the amount of space allocated to it, the unused space must be reclaimed. With previous releases of the Oracle server, space once allocated below the segment’s HWM could be freed only by moving or redefining the segment. In Oracle Database 10g, you can shrink segments. When a segment is shrunk, its data is compacted, its HWM is pushed down, and unused space is released back to the tablespace containing the segment. A shrink operation is an online and in-place operation, and it does not use extra database space to be executed. “In-place” means the shrink operation does not create a separate object; rather, the shrink is done on the same object. Note: You cannot execute a shrink operation on segments managed by free lists. Data HWM

How Can I Shrink Segments?
ALTER … SHRINK SPACE [CASCADE] TABLE INDEX MATERIALIZED VIEW MATERIALIZED VIEW LOG MODIFY PARTITION MODIFY SUBPARTITION MODIFY LOB ALTER TABLE employees ENABLE ROW MOVEMENT; 1 Because a shrink operation may cause row IDs to change in heap-organized segments, you must enable row movement on the corresponding segment before executing a shrink operation on that segment. Row movement by default is disabled at segment level. To enable row movement, the ENABLE ROW MOVEMENT clause of CREATE TABLE or ALTER TABLE commands is used. This is illustrated in the first example. The ALTER command is used to invoke segment shrink on an object. The object’s type can be one of the following: table (heap-organized or index-organized), partition, subpartition, LOB (data and index segment), index, materialized view, or materialized view log. The SHRINK SPACE clause is used to shrink space in a segment. If CASCADE is specified, the shrink behavior is cascaded to all the dependent segments that support a shrink operation (except materialized views, LOB indexes, IOT mapping tables, and overflow segments). The SHRINK SPACE clause is illustrated in the second example. In an index segment, the shrink operation coalesces the index before compacting the data. Note: Index dependency is taken care of during the segment shrink operation. The indexes are in a usable state after shrinking the corresponding table. No further maintenance is needed. ALTER TABLE employees SHRINK SPACE CASCADE; 2

Segment Advisor The Segment Advisor determines whether an object is a good candidate for a shrink operation. It makes its recommendations based on the amount of unused space that can be released, and takes into consideration estimated future space requirements using criteria from growth-trending information gathered. After the recommendations are made, you can choose to implement the recommendations. The Segment Advisor allows two types of objects for getting shrink advice: tablespace or schema object. You must choose between comprehensive and limited mode, as this has an effect on the flow of subsequent pages. In comprehensive mode, the Advisor samples selected objects as needed and generates more complete recommendations. In limited mode, the Advisor makes a quick recommendation using available statistics.

Growth Trend Report Segment Growth Trending focuses on collecting growth-trend data and making it available for advisories and reporting tools such as EM. This is a function of the Segment Advisor. The growth trend report data: Is based on Automatic Workload Repository data Indicates past growth trends and predicts future growth patterns Is supported only for locally managed tablespaces The Workload Repository collects the persistent space usage information.

Proactively Managing Space
D E M O N S T R A T I O N Proactively Managing Space

Segment Resource Estimation
The new segment resource estimation feature enables you to estimate the amount of resources that creation of a new segment would require. Based on the structure of a table or index and the number of estimated rows in the table, Oracle Database 10g estimates the amount of disk space likely to be consumed by the object.

Automatic Undo Retention Tuning
Proactive tuning Undo retention is tuned for longest-running query. Query duration information is collected every 30 seconds. Reactive tuning Undo retention is gradually lowered under space pressure. Oldest unexpired extents are used first. Enabled by default Oracle Database 10g automatically determines the optimal undo retention time depending on the size of the undo tablespace. Without your intervention, Oracle Database 10g dynamically adjusts to the change in undo requirements depending on the system activity. This maximizes the usage of the available space in the undo tablespace: There is no need to set the undo retention period manually. Long-running queries succeed without encountering “Snapshot too old” errors.

Using Automatic Undo Retention Tuning
D E M O N S T R A T I O N Using Automatic Undo Retention Tuning

Undo Advisor Oracle Database 10g can automatically analyze undo tablespace usage and provide recommendations. By choosing the time period that best represents the system activity, the undo space usage analysis gives you recommendations for the undo retention length and the undo tablespace size.

Redo Logfile Size Advisor
The Redo Logfile Size Advisor determines the optimal smallest online redo log file size based on the current FAST_START_MTTR_TARGET setting and MTTR statistics. Thus, the Redo Logfile Size Advisor is enabled only if FAST_START_MTTR_TARGET is set. The Advisor provides a recommended optimal smallest online redo log file size. You can then adjust the online redo log file size to the recommended optimal size. The Redo Logfile Size Advisor is invoked via Enterprise Manager. Using EM to obtain redo log file sizing advice: 1. Navigate to Database > Administration > Storage > Redo Log Groups. 2. Click the radio button for the group that you want to retrieve sizing advice. 3. Select Sizing advice from the Actions drop-down menu. 4. Click Go, and then click Continue. Note: An online redo log file size is considered optimal if it does not drive incremental checkpointing more aggressively than needed by FAST_START_MTTR_TARGET.

Automatic Backup (DBCA Setup)
In Oracle Database 10g, DBCA supports automation of backup jobs.

Optimized Incremental Backup
Optimizes incremental backups Tracks which blocks have changed since last backup Oracle Database 10g has integrated change tracking. New Change Tracking File is introduced. Changed blocks are tracked as redo is generated. Database backup automatically uses changed block list. List of Changed Blocks Change Tracking File The goal of an incremental backup is to back up only those data blocks that have changed since a previous backup. You can use Recovery Manager (RMAN) to create incremental backups of datafiles, tablespaces, or the whole database. During media recovery, RMAN examines the restored files to determine whether it can recover them with an incremental backup. If it has a choice, then RMAN always chooses incremental backups over archived logs, as applying changes at a block level is faster than reapplying individual changes. If you enable the block change tracking feature, then Oracle Database 10g tracks the physical location of all database changes in a new type of file called the “block change tracking file.” RMAN can use the change tracking data to determine which blocks need to be read during an incremental backup. When block change tracking is not enabled, then the entire datafile is read during each incremental backup, even if just a very small part of that file has changed since the last incremental backup. The maintenance of this file is fully automatic and does not require user intervention. The performance overhead is small. There is no need to set the block change tracking file if the parameter DB_CREATE_FILE_DEST is set. By default, the Oracle database does not record block change information. You enable this feature using the ALTER DATABASE ENABLE BLOCK CHANGE TRACKING command. Once enabled, the Oracle database maintains the block change tracking file and makes the required changes to it. There is no extra maintenance required. Note: You can enable block change tracking by using EM. Redo Generation SGA Redo Log

Defining Flash Recovery Area
With Automatic Disk-Based Backup and Recovery, you can create a flash recovery area, which automates management of backup-related files. Choose a location on disk and an upper bound for storage space, and then set a retention policy that governs how long backup files are needed for recovery. Oracle manages the storage used for backups, archived redo logs, and other recovery-related files for your database within that space. Files no longer needed are eligible for deletion when RMAN needs to reclaim space for new files. If you do not use a flash recovery area, you must manually manage disk space for your backup-related files and balance the use of space among the different types of files.

Flash Recovery Area Space Management
Disk limit is reached and a new file needs to be written into the Recovery Area. Oracle deletes files that are no longer required on disk. Recovery Area Database file backup 1 2 3 Space pressure occurs. 4 Warning is issued to user. RMAN updates list of files that may be deleted. 1 Each time RMAN creates a file in the Recovery Area, the list of files that are no longer required on disk is updated. When the Recovery Area experiences space pressure or is low on free space because there are no files that can be deleted from the Recovery Area, the user is warned of the danger of running out of disk space. The Oracle server and RMAN continue to create files in the recovery area until 100% of the disk limit is reached. Thus, when setting the DB_RECOVERY_FILE_DEST_SIZE, you must consider whether you have allocated enough disk space before running out of space or backup to tape. Files that are obsolete or have been backed up to tape are likely candidates for deletion to provide free space. When a file is written into the Recovery Area and space is needed for that file, Oracle deletes a file that is on the obsolete files list. When a file is written and deleted from the Recovery Area, notification is written into the alert log. Note: When Recovery Area used space is at 85%, a warning is issued; when used space is at 97%, a critical warning is issued. These are internal settings and cannot be changed. 2 Backup files to be deleted

Suggested Strategy In Oracle Database 10g, you can use RMAN to apply incremental backups to data file image copies. With this recovery method, you can use RMAN to recover a copy of a data file. That is, you can roll forward (recover) the image copy to the specified point in time by applying the incremental backups. The benefits of applying incremental backups to data file image copies are: Reduction in the time required for media recovery No need for you to perform a full image copy after incremental backups By default, when you configure automatic backup jobs by using EM, Oracle uses the following strategy: A full database copy is taken during the first backup. An incremental backup to disk is taken daily. The current database copy is then merged with the incremental backup. In this way, you can always perform a full database recovery or a point-in-time recovery to any time within the past day. Note: To access the Backup Strategy page, navigate to the Maintenance tab under the Recovery column, and then choose Backup.

Flashback Error Correction
Database Flashback Database Restore database to time Uses flashback logs Flashback Drop Restore dropped table Uses recycle bin Flashback Table Restore all rows in table to time Uses UNDO in database Flashback Transaction Query Query a committed Txn Flashback Versions Query Query changes to rows over time Customer Order Order Line Flashback Database reduces the time required to recover the database to a point in time. As a database grows in size, the length of time required to restore all data files to perform a traditional point-in-time recovery becomes prohibitive. Flashback Drop can un-drop a table. When you drop a table it is placed in the recycle bin automatically. You can restore the dropped table from the recycle bin. Flashback Table allows you to recover a table or tables to a specific point in time without restoring a backup. When you use this feature, the data in the tables and all associated objects (indexes, constraints, triggers, etc.) is restored. Flashback Transaction Query is a diagnostic tool that provides a way for you to view changes made to the database at the transaction level. This allows you to diagnose problems in your database and perform analysis and audits of transactions. The use of this feature in conjunction with Flashback Versions Query allows you to easily recover from user or application errors. The undo SQL generated via this feature can be used to roll back the changes made by a transaction. Flashback Versions Query returns as set of rows that is a history of changes of the rows across transactions. The Flashback Versions Query retrieves all committed occurrences of the rows. Changes made by the current active transaction are not returned. In other words, uncommitted row versions within a transaction will not be shown.

What Is Automatic Storage Management
Database Tablespace Segment ASM solves management problems of Oracle databases. Extent Automatic Storage Management (ASM) is a database service that allows the efficient management of disk drives with 24 × 7 availability. ASM can provide management for single SMP machines or across multiple nodes of a cluster for Oracle Real Application Clusters (RAC) support. ASM automatically does load balancing in parallel across all available disk drives to prevent hot spots and maximize performance, even with rapidly changing data usage patterns. It prevents fragmentation so that there is never a need to relocate data to reclaim space. It does automatic online disk space reorganization for the incremental addition or removal of storage capacity. It can maintain redundant copies of data to provide fault tolerance, or it can be built on top of vendor-supplied reliable storage mechanisms. Data management is done by selecting the desired reliability and performance characteristics for classes of data rather than with human interaction on a per-file basis. ASM solves many of the difficult management problems of Oracle databases. As the size of a database server increases in terms of disk drives and nodes in a cluster, the traditional techniques for management stop working. They do not scale efficiently, they become too prone to human error, and they require independent effort on every node of a cluster. Other tasks, such as manual load balancing, become so complex that it is no longer a viable solution. ASM solves these problems if you have expanding storage needs and you are faced with storage management problems that are wasting to many cycles of your time. ASM manages Oracle files. ASM does not replace existing concepts.

Hierarchy Or Database ASM disk group Tablespace Data file ASM file
Segment Or ASM disk Extent File system file or raw device Allocation unit Files in a tablespace may be in operating system file systems, raw devices, and ASM files as a result of the tablespace history. New RMAN commands enable non-ASM-managed files to be relocated to an ASM disk group. The diagram depicts the relationships that exist between the various storage concepts inside an Oracle database. In the left and middle columns of the diagram, you see the relationships that existed in previous releases of the Oracle server. The right column of the diagram shows you the new concepts introduced by ASM in Oracle Database 10g. However, these new concepts are only used to describe file storage and do not replace any existing concepts (such as segments, tablespaces, and so on). The link between the two hierarchies is made at the data file level. That is, a data file can be stored as an ASM file or a file system file, or it can be stored on a raw device. At the top of the new hierarchy (on the right), you see what is called the ASM disk group. Each disk group is self-describing. Any single ASM file is contained in only one disk group. However, a disk group may contain files belonging to several databases, and a single database may use storage from multiple disk groups. As you can see, one disk group is made up of ASM disks, and each ASM disk belongs to only one disk group. Also, ASM files are always spread across all the disks in the disk group. Oracle block Physical block

Reduces the cost of managing storage Reduces administration complexity
ASM Benefits Reduces the cost of managing storage Reduces administration complexity Supports RAC Improves performance, scalability, and reliability Reduces administration complexity: Simplifies or eliminates daily administration: automatic I/O tuning for all loads Reduces the number of objects to manage: One disk group replaces multiple FS. Simplifies configuration changes: automatic data copy on disk add and drop Reduced downtime: ASM prevents accidental file deletion. Eliminates costly storage products: Reduces the cost of managing storage Provides clustered volume manager and file system integrated with the database Works with any type of disk from cheap JBOD to SAN disk arrays Improves performance, scalability, and reliability: Raw disk I/O performance for all files Stripe files across multiple storage arrays Higher storage utilization Overcomes file system size limitations Implements mirroring to protect against storage array failure: two-way mirroring Supports Real Application Clusters: eliminates Real Application Clusters’ need for a Cluster Logical Volume Manager or a Cluster File System

ASM file automatically spread inside disk group dgroupA
ASM Files CREATE TABLESPACE sample DATAFILE '+dgroupA'; Database file 1 Automatic ASM file creation 2 3 4 ASM files are Oracle database files stored in ASM disk groups. When a file is created, certain file attributes are permanently set. Among these are its protection policy (mirroring, or none) and its striping policy. ASM files are not visible from the operating system or its utilities, but are visible to RMAN and other Oracle-supplied tools. All circumstances in which a database must create a new file allow for the specification of a disk group for automatically generating a unique file name. ASM files are similar to Oracle Managed Files. Like Oracle Managed Files, any file that is created in this way is automatically deleted when it is no longer needed. A partially created file is deleted if the creation fails. With ASM, file operations are specified in terms of database objects. Administration of databases never requires knowing the name of a file, though the name of the file is exposed through some data dictionary views or the ALTER DATABASE BACKUP CONTROLFILE TO TRACE command. ASM load- balances file activity by uniformly distributing file extents across all disks in a disk group. ASM mirroring, like RAID-1, protects critical data by maintaining multiple copies of data. However, unlike RAID-1, ASM mirroring is on a file basis. Mirror protection is most suitable for data files, online logs, and control files. ASM supports two-way mirroring for the most critical data. Because each file in a disk group is physically spread across all disks in the disk group, a backup of a single disk is not useful. Database backups of ASM files must be made with RMAN. ASM does not manage binaries, alert logs, trace files, or password files. 1 2 3 4 ASM file automatically spread inside disk group dgroupA

SQL Statements Issued to ASM Instances
ALTER SYSTEM RESTRICTED SESSION CREATE DISKGROUP ASM Instance There are several new disk group administrative commands. They all require the SYSDBA privilege and must be issued from an ASM instance. You can add new disk groups. You can also modify existing disk groups to add new disks, remove existing ones, and many other operations. You can remove existing disk groups. Finally, you can prevent database instances from connecting to an ASM instance. When the command ALTER SYSTEM ENABLE RESTRICTED SESSION is issued to an ASM instance, database instances cannot connect to that ASM instance. Conversely, ALTER SYSTEM DISABLE RESTRICTED SESSION enables connections from database instances. This command permits an ASM instance to start up and mount disk groups for purposes of maintenance without allowing database instances to access the disk groups. ALTER DISKGROUP DROP DISKGROUP

Enterprise Manager and ASM
This Enterprise Manager page shows the status of the ASM instance along with the metrics and alerts generated by the collection mechanisms. This page also provides the startup and shutdown functionality. Clicking the Alert link takes the user to an alert details page. The DiskGroup usage chart shows space used by each client database along with free space. The Administration tab of the ASM home page shows the enumeration of disk groups from V$OSM_DISKGROUP. On this screen, you can Create/Edit/Drop a disk group. You can also perform disk-group operations like Mount, Dismount, Rebalance, Check, and Repair on a selected disk group.

Using Automatic Storage Management
D E M O N S T R A T I O N Using Automatic Storage Management

How Oracle Database 10 g DBAs Spend Their Time
Proactive and Strategic Planning 50+% Create and Configure 6% Install 3% Think and act more proactively and strategically Are application-aware and business-sensitive Support larger databases with more users, for more mission-critical applications Can consolidate, centralize, and globalize Require and provide more education Get more sleep! Are even more important and valuable! Maintain Software 3% Manage Database System 25% Load Data 3%

Summary Oracle Database 10 g’s self-management capabilities work out-of-the-box. Customization of Oracle Database 10 g’s self-management capabilities can be done through Enterprise Manager. Oracle Database 10 g is a self-managing database which reduces administration overhead and enables DBAs to become proactive strategists.

Q & Q U E S T I O N S A N S W E R S A

Reminder – please complete the OracleWorld online session survey Thank you.

Steven George Sr. Delivery Manager

Similar presentations

Presentation on theme: "Steven George Sr. Delivery Manager"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Steven George Sr. Delivery Manager

Similar presentations

Presentation on theme: "Steven George Sr. Delivery Manager"— Presentation transcript:

Similar presentations

About project

Feedback