Sie sind auf Seite 1von 3

DETAILED ADDM REPORT FOR TASK 'TASK_96488' WITH ID 96488 -------------------------------------------------------Analysis Period: Database ID/Instance: Database/Instance Names: Host

Name: Database Version: Snapshot Range: Database Time: Average Database Load: from 20-MAY-2011 07:00 to 27-MAY-2011 22:00 964415168/1 DBIOCS/dbiocs1 db1 10.2.0.4.0 from 20652 to 20835 420933 seconds .6 active sessions

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ FINDING 1: 9.4% impact (39639 seconds) -------------------------------------The SGA was inadequately sized, causing additional I/O or hard parses. RECOMMENDATION 1: DB Configuration, 9.4% benefit (39639 seconds) ACTION: Increase the size of the SGA by setting the parameter "sga_target" to 4032 M. ADDITIONAL INFORMATION: The value of parameter "sga_target" was "2304 M" during the analysis period. SYMPTOMS THAT LED TO THE FINDING: SYMPTOM: Wait class "User I/O" was consuming significant database time. (24% impact [100897 seconds]) FINDING 2: 5.4% impact (22897 seconds) -------------------------------------The PGA was inadequately sized, causing additional I/O to temporary tablespaces to consume significant database time. RECOMMENDATION 1: DB Configuration, 3.3% benefit (13738 seconds) ACTION: Increase the size of the PGA by setting the value of parameter "pga_aggregate_target" to 230 M. ADDITIONAL INFORMATION: The value of parameter "pga_aggregate_target" was "192 M" during the analysis period. SYMPTOMS THAT LED TO THE FINDING: SYMPTOM: Wait class "User I/O" was consuming significant database time. (24% impact [100897 seconds]) FINDING 3: 4.1% impact (17143 seconds) -------------------------------------Wait event "SQL*Net more data from client" in wait class "Network" was consuming significant database time. RECOMMENDATION 1: Application Analysis, 4.1% benefit (17143 seconds) ACTION: Investigate the cause for high "SQL*Net more data from client" waits. Refer to Oracle's "Database Reference" for the description of this wait event. SYMPTOMS THAT LED TO THE FINDING: SYMPTOM: Wait class "Network" was consuming significant database time.

(4.5% impact [18950 seconds]) FINDING 4: 2.7% impact (11257 seconds) -------------------------------------Wait class "Administrative" was consuming significant database time. NO RECOMMENDATIONS AVAILABLE FINDING 5: 1.9% impact (7883 seconds) ------------------------------------Individual database segments responsible for significant user I/O wait were found. RECOMMENDATION 1: Segment Tuning, 1.9% benefit (7883 seconds) ACTION: Investigate application logic involving I/O on TABLE "SYS.TAB$" with object id 4. RELEVANT OBJECT: database object with id 4 RATIONALE: The I/O usage statistics for the object are: 0 full object scans, 19264 physical reads, 1926 physical writes and 0 direct reads. RATIONALE: The SQL statement with SQL_ID "frrz2mmty86us" spent significant time waiting for User I/O on the hot object. RELEVANT OBJECT: SQL statement with SQL_ID frrz2mmty86us RATIONALE: The SQL statement with SQL_ID "7qdqkp18r0jxr" spent significant time waiting for User I/O on the hot object. RELEVANT OBJECT: SQL statement with SQL_ID 7qdqkp18r0jxr RATIONALE: The SQL statement with SQL_ID "8132bscusk82z" spent significant time waiting for User I/O on the hot object. RELEVANT OBJECT: SQL statement with SQL_ID 8132bscusk82z RATIONALE: The SQL statement with SQL_ID "4mj8kb55f8b2h" spent significant time waiting for User I/O on the hot object. RELEVANT OBJECT: SQL statement with SQL_ID 4mj8kb55f8b2h RATIONALE: The SQL statement with SQL_ID "1jfr1a8dy01f9" spent significant time waiting for User I/O on the hot object. RELEVANT OBJECT: SQL statement with SQL_ID 1jfr1a8dy01f9 SYMPTOMS THAT LED TO THE FINDING: SYMPTOM: Wait class "User I/O" was consuming significant database time. (24% impact [100897 seconds]) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ADDITIONAL INFORMATION ---------------------Wait class "Application" was not consuming significant database time. Wait class "Cluster" was not consuming significant database time. Wait class "Commit" was not consuming significant database time. Wait class "Concurrency" was not consuming significant database time. Wait class "Configuration" was not consuming significant database time. CPU was not a bottleneck for the instance. Session connect and disconnect calls were not consuming significant database time. Hard parsing of SQL statements was not consuming significant database time.

The database's maintenance windows were active during 44% of the analysis period. The analysis of I/O performance is based on the default assumption that the average read time for one database block is 10000 micro-seconds. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ TERMINOLOGY ----------DATABASE TIME: This is the ADDM's measurement of throughput. From the user's point of view: this is the total amount of time spent by users waiting for a response from the database after issuing a call (not including networking). From the database instance point of view: this is the total time spent by forground processes waiting for a database resource (e.g., read I/O), running on the CPU and waiting for a free CPU (run-queue). The target of ADDM analysis is to reduce this metric as much as possible, thereby reducing the instance's response time. AVERAGE DATABASE LOAD: At any given time we can count how many users (also called 'Active Sessions') are waiting for an answer from the instance. This is the ADDM's measurement for instance load. The 'Average Database Load' is the average of the the load measurement taken over the entire analysis period. We get this number by dividing the 'Database Time' by the analysis period. For example, if the analysis period is 30 minutes and the 'Database Time' is 90 minutes, we have an average of 3 users waiting for a response. IMPACT: Each finding has an 'Impact' associated with it. The impact is the portion of the 'Database Time' the finding deals with. If we assume that the problem described by the finding is completely solved, then the 'Database Time' will be reduced by the amount of the 'Impact'. BENEFIT: Each recommendation has a 'benefit' associated with it. The ADDM analysis estimates that the 'Database Time' can be reduced by the 'benefit' amount if all the actions of the recommendation are performed.

Das könnte Ihnen auch gefallen