My environment: RAC 11.2.0.2.6 (2 nodes running RHEL 5)
The below snap is from a one hour AWR report when running an application stability test. So the load is fairly light and the response time is good.
However, looking at the top 5 timed events I'm seeing lots of waits for "rdbms ipc reply" and "DFS lock handle". The actual time waited for these events are very low in a one hour picture, but could this be a potential time-bomb I'm seeing?
I'd expect these numbers to increase when an actual real-production workload is run.
I checked the p1 in v$session_wait for the actual lock that "DFS lock handle" is waiting on and it seems to be two variants: BB and DX that has to do with distributed transactions.
The application is running on the latest weblogic server.
Snap Id Snap Time Sessions Curs/Sess
--------- ------------------- -------- ---------
Begin Snap: 14421 23-Nov-12 15:00:24 1,482 2.5
End Snap: 14424 23-Nov-12 16:00:42 1,482 2.5
Elapsed: 60.30 (mins)
DB Time: 5.55 (mins)
Cache Sizes Begin End
~~~~~~~~~~~ ---------- ----------
Buffer Cache: 1,136M 1,136M Std Block Size: 8K
Shared Pool Size: 1,776M 1,776M Log Buffer: 16,828K
Load Profile Per Second Per Transaction Per Exec Per Call
~~~~~~~~~~~~ --------------- --------------- ---------- ----------
DB Time(s): 0.1 0.0 0.00 0.00
DB CPU(s): 0.1 0.0 0.00 0.00
Redo size: 15,202.6 2,089.8
Logical reads: 413.9 56.9
Block changes: 73.5 10.1
Physical reads: 0.3 0.0
Physical writes: 2.1 0.3
User calls: 225.9 31.1
Parses: 39.2 5.4
Hard parses: 4.5 0.6
W/A MB processed: 0.1 0.0
Logons: 0.1 0.0
Executes: 142.9 19.7
Rollbacks: 0.0 0.0
Transactions: 7.3
Event Waits Time(s) (ms) time Wait Class
------------------------------ ------------ ----------- ------ ------ ----------
DB CPU 216 64.9
rdbms ipc reply 269,792 48 0 14.5 Other
log file sync 26,331 28 1 8.3 Commit
DFS lock handle 33,825 17 1 5.1 Other
gc cr block 2-way 42,217 16 0 4.9 Cluster
Database services for the application are configured like this:
Service name: srv_prod_app
Service is enabled
Server pool: prod_srv_prod_app
Cardinality: 2
Disconnect: false
Service role: PRIMARY
Management policy: AUTOMATIC
DTP transaction: false
AQ HA notifications: false
Failover type: NONE
Failover method: NONE
TAF failover retries: 0
TAF failover delay: 0
Connection Load Balancing Goal: LONG
Runtime Load Balancing Goal: NONE
TAF policy specification: NONE
Edition:
Preferred instances: prod1,prod2
Available instances:
I'm not even sure I have a problem - as I said the system i fairly loaded right now and the application response time is good - but should these waits be cause of concern or are they to be considered normal in a RAC env? If not please advise.
Thanks!