You are on page 1of 11

ADDM Report for Task 'TASK_1366'

-------------------------------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

NILAI19 WHEN 20 THEN NILAI20 WHEN 21 THEN NILAI21 WHEN 22 THEN


NILAI22 WHEN 23 THEN NILAI23 WHEN 24 THEN NILAI24 WHEN 25 THEN
NILAI25 WHEN 26 THEN NILAI26 WHEN 27 THEN NILAI27 WHEN 28 THEN
NILAI28 WHEN 29 THEN NILAI29 WHEN 30 THEN NILAI30 WHEN 31 THEN
NILAI31 WHEN 32 THEN NILAI32 WHEN 33 THEN NILAI33 WHEN 34 THEN
NILAI34 WHEN 35 THEN NILAI35 WHEN 36 THEN NILAI36 WHEN 37 THEN
NILAI37 WHEN 38 THEN NILAI38 WHEN 39 THEN NILAI39 WHEN 40 THEN
NILAI40 WHEN 41 THEN NILAI41 WHEN 42 THEN NILAI42 WHEN 43 THEN
NILAI43 WHEN 44 THEN NILAI44 WHEN 45 THEN NILAI45 WHEN 46 THEN
NILAI46 WHEN 47 THEN NILAI47 WHEN 48 THEN NILAI48 WHEN 49 THEN
NILAI49 WHEN 50 THEN NILAI50 WHEN 51 THEN NILAI51 WHEN 52 THEN
NILAI52 WHEN 53 THEN NILAI53 WHEN 54 THEN NILAI54 WHEN 55 THEN
NILAI55 WHEN 56 THEN NILAI56 WHEN 57 THEN NILAI57 WHEN 58 THEN
NILAI58 WHEN 59 THEN NILAI59 WHEN 60 THEN NILAI60 END, 0) FROM
MAS_SDM WHERE KDPRS = :B4 AND KDBUDGET = :B3 AND KDCAB = :B2 AND
KDJAB = :B1 AND KATEGORI = 0
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 "bj0gwdk9mdta7" was executed 31617724 times
and had an average elapsed time of 0.00021 seconds.
Rationale
Top level calls to execute the PL/SQL statement with SQL_ID
"0wsp66t36mw5f" are responsible for 55% of the database time spent on
the SELECT statement with SQL_ID "bj0gwdk9mdta7".
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 3: SQL Tuning
Estimated benefit is .14 active sessions, 3.9% of total activity.
-----------------------------------------------------------------

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

2390145687982650860 and PLAN_HASH_VALUE 1970954553 were found to be


using literals. An example is SQL statement with SQL_ID "64ncs1sdf22wd".
Related Object
SQL statement with SQL_ID 64ncs1sdf22wd.
Rationale
At least 9 SQL statements with FORCE_MATCHING_SIGNATURE
5258686056706365155 and PLAN_HASH_VALUE 649060659 were found to be using
literals. Look in V$SQL for examples of such SQL statements.
Symptoms That Led to the Finding:
--------------------------------Hard parsing of SQL statements was consuming significant database time.
Impact is .53 active sessions, 14.3% of total activity.
Finding 5: Global Cache Messaging
Impact is .23 active sessions, 6.18% of total activity.
------------------------------------------------------Inter-instance messaging was consuming significant database time on this
instance.
Recommendation 1: Application Analysis
Estimated benefit is .23 active sessions, 6.18% of total activity.
-----------------------------------------------------------------Action
Look at the "Top SQL Statements" finding for SQL statements consuming
significant time on Cluster waits. For example, the SELECT statement
with SQL_ID "16g9b6myx4afy" is responsible for 67% of Cluster wait
during the analysis period.
Symptoms That Led to the Finding:
--------------------------------Wait class "Cluster" was consuming significant database time.
Impact is .23 active sessions, 6.2% of total activity.
Finding 6: PL/SQL Execution
Impact is .15 active sessions, 4.01% of total activity.
------------------------------------------------------PL/SQL execution consumed significant database time.
Recommendation 1: SQL Tuning
Estimated benefit is .14 active sessions, 3.79% of total activity.
-----------------------------------------------------------------Action
Tune the entry point PL/SQL "MFIN_BUDGET.PROC_BUDGET" of type
"PROCEDURE" and ID 60155. Refer to the PL/SQL documentation for addition
information.
Rationale
2812 seconds spent in executing PL/SQL "MFIN_BUDGET.PROC_INS_BUANG" of
type "PROCEDURE" and ID 60145.
Rationale
372 seconds spent in executing PL/SQL "MFIN_BUDGET.PROC_MAS_SDM" of type
"PROCEDURE" and ID 60129.
Rationale
332 seconds spent in executing PL/SQL "MFIN_BUDGET.GET_GAJI_KARY" of
type "FUNCTION" and ID 60075.
Rationale
272 seconds spent in executing PL/SQL "MFIN_BUDGET.GET_JML_KARY" of type

"FUNCTION" and ID 60063.


Rationale
201 seconds spent in executing PL/SQL "MFIN_BUDGET.PPMT" of type
"FUNCTION" and ID 59989.
Recommendation 2: SQL Tuning
Estimated benefit is .01 active sessions, .18% of total activity.
----------------------------------------------------------------Action
Tune the entry point PL/SQL "SYS.DBMS_SPACE.AUTO_SPACE_ADVISOR_JOB_PROC"
of type "PACKAGE" and ID 8364. Refer to the PL/SQL documentation for
addition information.
Rationale
292 seconds spent in executing PL/SQL
"SYS.DBMS_SPACE.OBJECT_SPACE_USAGE" of type "PACKAGE" and ID 8364.
Recommendation 3: SQL Tuning
Estimated benefit is 0 active sessions, .04% of total activity.
--------------------------------------------------------------Action
Tune the entry point PL/SQL
"SYS.DBMS_STATS.GATHER_DATABASE_STATS_JOB_PROC" of type "PACKAGE" and ID
8390. Refer to the PL/SQL documentation for addition information.
Finding 7: CPU Usage
Impact is .14 active sessions, 3.75% of total activity.
------------------------------------------------------Time spent on the CPU by the instance was responsible for a substantial part
of database time.
Recommendation 1: Application Analysis
Estimated benefit is 2.31 active sessions, 62.74% of total activity.
-------------------------------------------------------------------Action
Look at the "Top SQL Statements" finding for SQL statements consuming
significant time on CPU. For example, the SELECT statement with SQL_ID
"16g9b6myx4afy" is responsible for 8% of CPU usage during the analysis
period.
Recommendation 2: Application Analysis
Estimated benefit is .14 active sessions, 3.75% of total activity.
-----------------------------------------------------------------Action
Parsing SQL statements were consuming significant CPU. Please refer to
other findings in this task about parsing for further details.
Finding 8: Soft Parse
Impact is .11 active sessions, 3.03% of total activity.
------------------------------------------------------Soft parsing of SQL statements was consuming significant database time.
Recommendation 1: Application Analysis
Estimated benefit is .11 active sessions, 3.03% of total activity.
-----------------------------------------------------------------Action
Investigate application logic to keep open the frequently used cursors.
Note that cursors are closed by both cursor close calls and session
disconnects.

Recommendation 2: Database Configuration


Estimated benefit is .11 active sessions, 3.03% of total activity.
-----------------------------------------------------------------Action
Consider increasing the session cursor cache size by increasing the
value of parameter "session_cached_cursors".
Rationale
The value of parameter "session_cached_cursors" was "100" during the
analysis period.
Finding 9: Buffer Busy - Hot Objects
Impact is .11 active sessions, 2.86% of total activity.
------------------------------------------------------Read and write contention on database blocks was consuming significant
database time.
Recommendation 1: Schema Changes
Estimated benefit is .01 active sessions, .14% of total activity.
----------------------------------------------------------------Action
Consider rebuilding the TABLE "MFIN_BUDGET.MAS_JADWAL" with object ID
59736 using a higher value for PCTFREE.
Related Object
Database object with ID 59736.
Recommendation 2: Schema Changes
Estimated benefit is .01 active sessions, .14% of total activity.
----------------------------------------------------------------Action
Consider partitioning the TABLE "MFIN_BUDGET.MAS_JADWAL" with object ID
59736 in a manner that will evenly distribute concurrent DML across
multiple partitions.
Related Object
Database object with ID 59736.
Symptoms That Led to the Finding:
--------------------------------Read and write contention on database blocks was consuming significant
database time.
Impact is .11 active sessions, 2.86% of total activity.
Wait class "Concurrency" was consuming significant database time.
Impact is 1.1 active sessions, 30.04% of total activity.
Inter-instance messaging was consuming significant database time on
this instance.
Impact is .23 active sessions, 6.18% of total activity.
Wait class "Cluster" was consuming significant database time.
Impact is .23 active sessions, 6.2% of total activity.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Additional Information
---------------------Miscellaneous Information
-------------------------

Wait class "Application" was not consuming significant database time.


Wait class "Commit" was not consuming significant database time.
Wait class "Configuration" was not consuming significant database time.
Wait class "Network" was not consuming significant database time.
Wait class "User I/O" was not consuming significant database time.
The network latency of the cluster interconnect was within acceptable limits
of 1 milliseconds.
Session connect and disconnect calls were not consuming significant database
time.
The database's maintenance windows were active during 33% of the analysis
period.

You might also like