TECHNOLOGY: Tuning

As Published In

Beginning Performance Tuning

By Arup Nanda

July/August 2012

Resolve session performance issues in Oracle Database. Its the middle of the night, and you get a frantic call from someone complaining that the database is slow. The caller demands to know whyand what youre going to do about it. Sound familiar? If it does, you are not alone. High performance is a common expectation of database system users: they get very unhappy when they dont get it, and they are usually not shy about letting you know. What should you do next? In this article, you will learn some techniques for troubleshooting Oracle Database performance issues. To use the scripts in this article, you need to create some tables in a test schema and access some dynamic performance views. The database user SYS has all privileges to access the views, so you need the password for the SYS user. The script for setting up the example tables is available in thesidebar. Session State Setup

To set up the test cases for this article, execute the SQL in this Setup section. The SQL assumes that you have access to the SYS user, you can create a user called ARUP (which means you dont have a user with the same name), and you have a tablespace called USERS with at least 64 KB of free space.

Connect as SYS, and execute the following:

connect sys/<password> as sysdba create user arup identified by arup default tablespace users / alter user arup quota unlimited on users / -- now connect as arup connect arup/arup create table t1 (

Before you start troubleshooting why a database is slow, you have to first understand that the database itself is never slow or fastit has a constant speed. The sessions connected to the database, however, slow down when they hit a bump in the road. To resolve a session performance issue, you need to identify the bump and remove it. Fortunately, its very easy to do this in most c ases. The first step to resolving a session performance issue is to ascertain what that database session is doing now. An Oracle Database session is always in one of three states: 1. 2. 3.

col1 number, col2 varchar2(1) ) / insert into t1 values (1,z) / commit /

Idle. Not doing anythingjust waiting to be given some work. Processing. Doing something usefulrunning on the CPU. Waiting. Waiting for something, such as a block to come from disk or a lock to be released. If a session is waiting to be given work (idle), its really not slow at allit just has nothing to do. If a session is waiting for some resource, such as a block or a lock, it has stopped processing. Until it gets that resource, the session will continue to wait. When it gets that resource, it does some processing and then moves on to the next resource it needs, waits for that to be available, and starts processing . . . and the cycle goes on until the session has nothing else to do. If it waits for resources often, the session will appear slow. But its not really slowits just following a pattern of go, stop, go again, stop again, and so on. Your mission is to find and eliminate the stop issues in the session. How difficult is it to get information about whats causing the session to stop? Its actually veryeasy: Oracle Database is instrumented to talk about what the database sessions are doing. All you need to do is to listen attentively or, more precisely, look for that information in the right place, and that place is a view called V$SESSION. Everything you need for your analysis is in this view. To explain how to use the V$SESSION view, I will use a very common scenario row lockingas an example. To follow along, first set up the previously mentioned tables as described in the online version of this article. Then connect as user ARUP from two different sessions. From the first session, issue the following SQL statement:

update t1 set col2 = 'x' where col1 = 1;

The output will show 1 row updated, indicating that the row was updated. Do not issue a COMMIT after the statement. By not committing, you will force the session to get and hold a lock on the first row of the T1 table. Now go to the second session and issue the following SQL statement:

update t1 set col2 = 'y' where col1 = 1;

This statement will hang. Why? The answer is simple: the first session holds a lock on the row, which causes the second session to hang and the user to complain that the session is slow. To know what the second session is doing, the first thing you need to check is the STATE column in V$SESSION:

select sid, state from v$session where username = 'ARUP'; SID STATE

3346 2832

WAITING WAITED KNOWN TIME