Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
-------------------------------Analysis Period
--------------AWR snapshot range from 340 to 352.
Time period starts at 10-NOV-14 03.00.12 PM
Time period ends at 11-NOV-14 03.00.08 AM
Analysis Target
--------------Database 'ORCLOPR' with DB ID 642801350.
Database version 11.2.0.4.0.
ADDM performed an analysis of instance orclopr1, numbered 1 and hosted at
odabase1.
Activity During the Analysis Period
----------------------------------Total database time was 158799 seconds.
The average number of active sessions was 3.68.
Summary of Findings
------------------Description
Active Sessions
Percent of Activity
-------------------------------- ------------------1 Top SQL Statements
1.96 | 53.25
2 Sequence Usage
1.4 | 38.01
3 Unusual "Concurrency" Wait Event 1.08 | 29.42
4 Hard Parse Due to Literal Usage .52 | 14.15
5 Global Cache Messaging
.23 | 6.18
6 PL/SQL Execution
.15 | 4.01
7 CPU Usage
.14 | 3.75
8 Soft Parse
.11 | 3.03
9 Buffer Busy - Hot Objects
.11 | 2.86
Recommendations
--------------5
1
4
1
1
3
2
2
2
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Findings and Recommendations
---------------------------Finding 1: Top SQL Statements
Impact is 1.96 active sessions, 53.25% of total activity.
--------------------------------------------------------SQL statements consuming significant database time were found. These
statements offer a good opportunity for performance improvement.
Recommendation 1: SQL Tuning
Estimated benefit is 1.45 active sessions, 39.31% of total activity.
-------------------------------------------------------------------Action
Investigate the SELECT statement with SQL_ID "16g9b6myx4afy" for
possible performance improvements. You can supplement the information
given here with an ASH report for this SQL_ID.
Related Object
SQL statement with SQL_ID 16g9b6myx4afy.
SELECT NOKONS.NEXTVAL FROM DUAL
Rationale
The SQL spent only 23% of its database time on CPU, I/O and Cluster
waits. Therefore, the SQL Tuning Advisor is not applicable in this case.
Look at performance data for the SQL to find potential improvements.
Rationale
Database time for this SQL was divided as follows: 100% for SQL
execution, 0% for parsing, 0% for PL/SQL execution and 0% for Java
execution.
Rationale
SQL statement with SQL_ID "16g9b6myx4afy" was executed 14602691 times
and had an average elapsed time of 0.0041 seconds.
Rationale
Waiting for event "row cache lock" in wait class "Concurrency" accounted
for 76% of the database time spent in processing the SQL statement with
SQL_ID "16g9b6myx4afy".
Rationale
Top level calls to execute the PL/SQL statement with SQL_ID
"0wsp66t36mw5f" are responsible for 50% of the database time spent on
the SELECT statement with SQL_ID "16g9b6myx4afy".
Related Object
SQL statement with SQL_ID 0wsp66t36mw5f.
DECLARE
v_KDCAB VARCHAR2(5);
p_URUT NUMBER(2) DEFAULT 0;
CURSOR XX IS
SELECT A.KDCAB
FROM TAB_REGIONAL A
INNER JOIN TAB_CABANG B ON A.KDPRS = B.KDPRS AND A.KDCAB = B.KDCAB
WHERE SUBSTR(A.KDCAB,1,1) IN ('5')
ORDER BY B.NOURUT;
BEGIN
OPEN XX;
LOOP
FETCH XX INTO v_KDCAB;
EXIT WHEN XX%NOTFOUND;
UPDATE TAB_CABANG SET MULAI = SYSDATE WHERE KDPRS = 'MFIN' AND KDCAB
= v_KDCAB;
PROC_BUDGET('MFIN','2012',DATE'2012-01-01',v_KDCAB,
DATE'2011-12-01','1');
UPDATE TAB_CABANG SET SELESAI = SYSDATE WHERE KDPRS = 'MFIN' AND
KDCAB = v_KDCAB;
END LOOP;
CLOSE XX;
COMMIT;
END;
Recommendation 2: SQL Tuning
Estimated benefit is .17 active sessions, 4.72% of total activity.
-----------------------------------------------------------------Action
Run SQL Tuning Advisor on the SELECT statement with SQL_ID
"bj0gwdk9mdta7".
Related Object
SQL statement with SQL_ID bj0gwdk9mdta7.
SELECT NVL(CASE :B5 WHEN 1 THEN NILAI01 WHEN 2 THEN NILAI02 WHEN 3
THEN NILAI03 WHEN 4 THEN NILAI04 WHEN 5 THEN NILAI05 WHEN 6 THEN
NILAI06 WHEN 7 THEN NILAI07 WHEN 8 THEN NILAI08 WHEN 9 THEN NILAI09
WHEN 10 THEN NILAI10 WHEN 11 THEN NILAI11 WHEN 12 THEN NILAI12 WHEN
13 THEN NILAI13 WHEN 14 THEN NILAI14 WHEN 15 THEN NILAI15 WHEN 16
THEN NILAI16 WHEN 17 THEN NILAI17 WHEN 18 THEN NILAI18 WHEN 19 THEN
Action
Run SQL Tuning Advisor on the SELECT statement with SQL_ID
"0rgaga613sdbg".
Related Object
SQL statement with SQL_ID 0rgaga613sdbg.
SELECT CASE WHEN KDJAB NOT
IN('ABMM','BMMK','BMOP','COLH','HOPR','SLSH') THEN
SUM(GAPOK_BARU+500000+(GAPOK_BARU*4.24/100)+(GAPOK_BARU*10/100)) ELSE
0 END FROM TAB_JABATAN_GAJI_AWAL WHERE KDJAB = :B3 AND KDCAB = :B2
AND TAHUN = TO_CHAR(:B1 ,'YYYY') GROUP BY KDJAB
Rationale
The SQL spent 100% of its database time on CPU, I/O and Cluster waits.
This part of database time may be improved by the SQL Tuning Advisor.
Rationale
Database time for this SQL was divided as follows: 100% for SQL
execution, 0% for parsing, 0% for PL/SQL execution and 0% for Java
execution.
Rationale
SQL statement with SQL_ID "0rgaga613sdbg" was executed 9752417 times and
had an average elapsed time of 0.00059 seconds.
Rationale
Top level calls to execute the PL/SQL statement with SQL_ID
"0wsp66t36mw5f" are responsible for 52% of the database time spent on
the SELECT statement with SQL_ID "0rgaga613sdbg".
Related Object
SQL statement with SQL_ID 0wsp66t36mw5f.
DECLARE
v_KDCAB VARCHAR2(5);
p_URUT NUMBER(2) DEFAULT 0;
CURSOR XX IS
SELECT A.KDCAB
FROM TAB_REGIONAL A
INNER JOIN TAB_CABANG B ON A.KDPRS = B.KDPRS AND A.KDCAB = B.KDCAB
WHERE SUBSTR(A.KDCAB,1,1) IN ('5')
ORDER BY B.NOURUT;
BEGIN
OPEN XX;
LOOP
FETCH XX INTO v_KDCAB;
EXIT WHEN XX%NOTFOUND;
UPDATE TAB_CABANG SET MULAI = SYSDATE WHERE KDPRS = 'MFIN' AND KDCAB
= v_KDCAB;
PROC_BUDGET('MFIN','2012',DATE'2012-01-01',v_KDCAB,
DATE'2011-12-01','1');
UPDATE TAB_CABANG SET SELESAI = SYSDATE WHERE KDPRS = 'MFIN' AND
KDCAB = v_KDCAB;
END LOOP;
CLOSE XX;
COMMIT;
END;
Recommendation 4: SQL Tuning
Estimated benefit is .1 active sessions, 2.84% of total activity.
----------------------------------------------------------------Action
Investigate the PL/SQL statement with SQL_ID "0wsp66t36mw5f" for
possible performance improvements. You can supplement the information
given here with an ASH report for this SQL_ID.
Related Object
SQL statement with SQL_ID 0wsp66t36mw5f.
DECLARE
v_KDCAB VARCHAR2(5);
p_URUT NUMBER(2) DEFAULT 0;
CURSOR XX IS
SELECT A.KDCAB
FROM TAB_REGIONAL A
INNER JOIN TAB_CABANG B ON A.KDPRS = B.KDPRS AND A.KDCAB = B.KDCAB
WHERE SUBSTR(A.KDCAB,1,1) IN ('5')
ORDER BY B.NOURUT;
BEGIN
OPEN XX;
LOOP
FETCH XX INTO v_KDCAB;
EXIT WHEN XX%NOTFOUND;
UPDATE TAB_CABANG SET MULAI = SYSDATE WHERE KDPRS = 'MFIN' AND KDCAB
= v_KDCAB;
PROC_BUDGET('MFIN','2012',DATE'2012-01-01',v_KDCAB,
DATE'2011-12-01','1');
UPDATE TAB_CABANG SET SELESAI = SYSDATE WHERE KDPRS = 'MFIN' AND
KDCAB = v_KDCAB;
END LOOP;
CLOSE XX;
COMMIT;
END;
Rationale
The SQL Tuning Advisor cannot operate on PL/SQL statements.
Rationale
Database time for this SQL was divided as follows: 24% for SQL
execution, 13% for parsing, 63% for PL/SQL execution and 0% for Java
execution.
Rationale
SQL statement with SQL_ID "0wsp66t36mw5f" was executed 2 times and had
an average elapsed time of 40959 seconds.
Recommendation 5: SQL Tuning
Estimated benefit is .09 active sessions, 2.49% of total activity.
-----------------------------------------------------------------Action
Run SQL Tuning Advisor on the INSERT statement with SQL_ID
"5vb310x4vcucb".
Related Object
SQL statement with SQL_ID 5vb310x4vcucb.
INSERT INTO MAS_JADWALH_KONS(KDBUDGET, KDPRS, KDCAB, JENIS,
PERIODBOOK, TENOR) VALUES (:B1 , :B2 , :B3 , :B4 , :B5 , :B6 )
Rationale
The SQL spent 100% of its database time on CPU, I/O and Cluster waits.
This part of database time may be improved by the SQL Tuning Advisor.
Rationale
Database time for this SQL was divided as follows: 97% for SQL
execution, 0% for parsing, 3% for PL/SQL execution and 0% for Java
execution.
Rationale
SQL statement with SQL_ID "5vb310x4vcucb" was executed 13833513 times
and had an average elapsed time of 0.0047 seconds.
Rationale
Top level calls to execute the PL/SQL statement with SQL_ID
"0wsp66t36mw5f" are responsible for 56% of the database time spent on
the INSERT statement with SQL_ID "5vb310x4vcucb".
Related Object
SQL statement with SQL_ID 0wsp66t36mw5f.
DECLARE
v_KDCAB VARCHAR2(5);
p_URUT NUMBER(2) DEFAULT 0;
CURSOR XX IS
SELECT A.KDCAB
FROM TAB_REGIONAL A
INNER JOIN TAB_CABANG B ON A.KDPRS = B.KDPRS AND A.KDCAB = B.KDCAB
WHERE SUBSTR(A.KDCAB,1,1) IN ('5')
ORDER BY B.NOURUT;
BEGIN
OPEN XX;
LOOP
FETCH XX INTO v_KDCAB;
EXIT WHEN XX%NOTFOUND;
UPDATE TAB_CABANG SET MULAI = SYSDATE WHERE KDPRS = 'MFIN' AND KDCAB
= v_KDCAB;
PROC_BUDGET('MFIN','2012',DATE'2012-01-01',v_KDCAB,
DATE'2011-12-01','1');
UPDATE TAB_CABANG SET SELESAI = SYSDATE WHERE KDPRS = 'MFIN' AND
KDCAB = v_KDCAB;
END LOOP;
CLOSE XX;
COMMIT;
END;
Finding 2: Sequence Usage
Impact is 1.4 active sessions, 38.01% of total activity.
-------------------------------------------------------Sequence cache misses were consuming significant database time.
Recommendation 1: Application Analysis
Estimated benefit is 1.4 active sessions, 38.01% of total activity.
------------------------------------------------------------------Action
Investigate application or look at top SQL to find hot sequences. Use a
larger cache size for those sequences. Try avoiding the use of the ORDER
setting if running RAC.
Finding 3: Unusual "Concurrency" Wait Event
Impact is 1.08 active sessions, 29.42% of total activity.
--------------------------------------------------------Wait event "row cache lock" in wait class "Concurrency" was consuming
significant database time.
Recommendation 1: Application Analysis
Estimated benefit is 1.08 active sessions, 29.42% of total activity.
-------------------------------------------------------------------Action
Investigate the cause for high "row cache lock" waits. Refer to Oracle's
"Database Reference" for the description of this wait event.
Action
Look at the "Top SQL Statements" finding for SQL statements consuming
significant time on the "row cache lock" wait event. For example, the
SELECT statement with SQL_ID "16g9b6myx4afy" is responsible for 100% of
these waits.
Recommendation 2: Application Analysis
Estimated benefit is 1.08 active sessions, 29.41% of total activity.
-------------------------------------------------------------------Action
Investigate the cause for high "row cache lock" waits in Service
"SYS$USERS".
Recommendation 3: Application Analysis
Estimated benefit is 1.08 active sessions, 29.4% of total activity.
------------------------------------------------------------------Action
Investigate the cause for high "row cache lock" waits in Module
"SQL*Plus".
Recommendation 4: Application Analysis
Estimated benefit is 1.08 active sessions, 29.36% of total activity.
-------------------------------------------------------------------Action
Investigate the cause for high "row cache lock" waits with P1,P2,P3
("cache id, mode, request") values "13", "0" and "5" respectively.
Symptoms That Led to the Finding:
--------------------------------Wait class "Concurrency" was consuming significant database time.
Impact is 1.1 active sessions, 30.04% of total activity.
Finding 4: Hard Parse Due to Literal Usage
Impact is .52 active sessions, 14.15% of total activity.
-------------------------------------------------------SQL statements were not shared due to the usage of literals. This resulted in
additional hard parses which were consuming significant database time.
Recommendation 1: Application Analysis
Estimated benefit is .52 active sessions, 14.15% of total activity.
------------------------------------------------------------------Action
Investigate application logic for possible use of bind variables instead
of literals.
Action
Alternatively, you may set the parameter "cursor_sharing" to "force".
Rationale
At least 11 SQL statements with FORCE_MATCHING_SIGNATURE
8429266482480969003 and PLAN_HASH_VALUE 3901956591 were found to be
using literals. Look in V$SQL for examples of such SQL statements.
Rationale
At least 11 SQL statements with FORCE_MATCHING_SIGNATURE
13389248132014974997 and PLAN_HASH_VALUE 3901956591 were found to be
using literals. Look in V$SQL for examples of such SQL statements.
Rationale
At least 10 SQL statements with FORCE_MATCHING_SIGNATURE
11719339990383857829 and PLAN_HASH_VALUE 3901956591 were found to be
using literals. Look in V$SQL for examples of such SQL statements.
Rationale
At least 9 SQL statements with FORCE_MATCHING_SIGNATURE
2390145687982650860 and PLAN_HASH_VALUE 1970954553 were found to be
using literals. An example is SQL statement with SQL_ID "guzqbk0h0wk5g".
Related Object
SQL statement with SQL_ID guzqbk0h0wk5g.
Rationale
At least 9 SQL statements with FORCE_MATCHING_SIGNATURE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Additional Information
---------------------Miscellaneous Information
-------------------------