I decided it was time I started looking at Oracle Enterprise Manager. Here is the performance tab for an Oracle 11.2.0.1.0 test database. It does not look very busy as most people havegone home. As always, click on the images as necessary to enlarge them and bring them into focus:
In the red session below, I created a user in the database, connected as that user, created a table and left the session with an uncommitted transaction:
SQL> conn / as sysdba
SQL> conn / as sysdba
Connected.
SQL> create user andrew
2 identified by reid
3 default tablespace users
4 quota unlimited on users
5 /
User created.
SQL> grant create session, create table to andrew
2 /
Grant succeeded.
SQL> conn andrew/reid
Connected.
SQL> create table andrews_table
2 (col1 varchar2(10))
3 /
Table created.
SQL> insert into andrews_table values ('ANDREW')
2 /
1 row created.
SQL> commit
2 /
Commit complete.
SQL> update andrews_table set col1 = 'BRIAN'
2 /
1 row updated.
SQL>
Then in a different session in blue, I created another user, checked the time to compare it against the time line in the OEM window and tried to update the same row:
SQL> conn / as sysdba
Connected.
SQL> create user john
2 identified by smith;
User created.
SQL> grant create session to john
2 /
Grant succeeded.
SQL> grant update on andrew.andrews_table to john
2 /
Grant succeeded.
SQL> select to_char(sysdate,'hh24:mi:ss')
2 time_now from dual
3 /
TIME_NOW
--------
18:05:15
SQL> conn john/smith
Connected.
SQL> update andrew.andrews_table
2 set col1 = 'COLIN'
3 /
The blue session had to wait because the red session had not committed its transaction. I left both sessions for a while. Then I looked at OEM again:
This showed that some kind of application wait had started around the time noted above (i.e. just after 1805 hours). I hovered over the word Application on the right of the screen:
Then I clicked on it and OEM took me to another screen. This showed me that user JOHN was waiting for a row lock (enq: TX - row lock contention). When I hovered over SQL ID, OEM even showed me the SQL he was trying to run:
I went back to the red session, committed the transaction and noted the time:
SQL> update andrews_table set col1 = 'BRIAN'
2 /
1 row updated.
SQL> commit
2 /
Commit complete.
SQL> select to_char(sysdate,'hh24:mi:ss')
2 time_now from dual
3 /
TIME_NOW
--------
18:41:16
SQL>
The update in the blue session completed:
SQL> update andrew.andrews_table
2 set col1 = 'COLIN'
3 /
1 row updated.
SQL>
I waited a bit longer then went back to the test database’s performance tab in OEM. The application wait had finished at the time noted above (i.e. around 1841 hours):
