Oracle Database Administration for Microsoft SQL Server DBAs part 25 ppsx

Current SessionsObviously, when there are performance issues, it is necessary to take a look at the current sessions on the database.. SQLPLUS> select username, schemaname,osuser, lockwa

Current Sessions

Obviously, when there are performance issues, it is necessary to take a look

at the current sessions on the database There is no sp_who, sp_who2, or sp_lockin Oracle, but there is the v$session view This view shows which sessions are active You can join this with another view to see which queries a session is running

SQLPLUS> select username, schemaname,osuser, lockwait,status

from v$session

where status='ACTIVE' and username not in ('SYS','SYSTEM');

USERNAME SCHEMANAME OSUSER LOCKWAIT STATUS - -DBSNMP DBSNMP oracle (null) ACTIVE MMALCHER MMALCHER mmalcher (null) ACTIVE USER1 APP1 user1 (null) ACTIVE

## Lockwait will be a non-null value when waiting on a resource

## such as a lock or a latch

## Another view to see this would be v$session_wait

## To see a SQL statement from one of the users currently active SQLPLUS> select sa.sql_text

from v$sqlarea sa, v$sqltext st, v$session s

where sa.sql_id=st.sql_id

and s.sql_hash_value=st.hash_value and s.username='SCOTT';

SQL_TEXT

-INSERT INTO log_messages (id,service,processed_date, log_date) VALUES(:"SYS_B_0",:"SYS_B_1",TO_TIMESTAMP(:"SYS_B_2",:"SYS_B_3"), :"SYS_B_4",TO_DATE(:"SYS_B_5",:"SYS_B_6"))

INSERT INTO log_messages (id,service,processed_date,log_date) VALUES(:"SYS_B_0",:"SYS_B_1",TO_TIMESTAMP(:"SYS_B_2",:"SYS_B_3"), :"SYS_B_4",TO_DATE(:"SYS_B_5",:"SYS_B_6"))

## To see what locks are current on an object

SQLPLUS> select session_id, owner, type, mode_held,

mode_requested

from dba_ddl_locks;

SESSION_ID OWNER TYPE MODE_HELD MODE_REQUESTED - - - -

-871 YELL1 Table/Procedure/Type Null None

627 SNAP Table/Procedure/Type Null None

284 SNAP Table/Procedure/Type Null None

286 ADB Table/Procedure/Type Null None

Activity Monitors

In OEM, under the Performance tab, you’ll find additional monitoring links

for looking at the top activity, instance activity, blocking sessions, and

currently running SQL, as shown in Figure 8-1 There are statistics that are

gathered as part of the Automatic Workload Repository to provide reports

for analyzing the health of the database and looking for performance issues

The historical views are based on snapshots that have been gathered (The

Automatic Workload Repository is discussed a little later in the chapter.)

Viewing these areas of activity can help you to troubleshoot performance

issues by pointing to an area that might be responding slowly or be

experiencing an overload, such as too many physical I/Os or hard parsing of SQL statements

Figure 8-2 shows the Top Activity section This has information about the resources that are being used, top SQL statements, and top sessions in the

database This can be the current information or information from another

point in time Viewing historical information is useful when a user drops by

in the afternoon to say that he was having issues in the morning, although

everything is fine now From here, you can drill down to the SQL statements and look into SQL tuning Drilling down on the session ID or SQL hash

value can get back to the SQL being run (Remember the SQL_hash_

valuefrom the v$session table from the example under the Current

Sessions section?)

The Instance Activity section shows values since the database has been

up and running or back until the last snapshot that is available By default,

these snapshots are kept seven days Figure 8-3 has a chart of instance

activity about cursors, transactions, physical and logical I/O, and other

activity It is useful to see the workload on the database server and look at

what is currently running, as well as the snapshots

FIGURE 8-1. OEM monitoring links

FIGURE 8-2. OEM Top Activity section

FIGURE 8-3. OEM Instance Activity section

Another area to check in Oracle for performance issues is wait events This

information will be available in the OEM views we just looked at, and also

available to query in the v$ views such as v$session_wait Here are a

few examples of quick queries to check for current database wait events:

SQLPLUS> select sid, event, p1text, wait_time , p1, p2

from v$session_wait;

SID EVENT P1TEXT WAIT_TIME P1 P2

- - -

-378 SQL*Net message from client 0 1952673792 1

385 SQL*Net message from client 0 1413697536 1

431 buffer busy waits component 429 3 123

## p1 and p2 will provide additional information about

## the p1text so if it is an i/o wait, would have data file

## or could be about a latch type or object

SQLPLUS> select segment_name, segment_type

from dba_extents where file_id = 3

and 123 between (block_id and block_id + blocks -1);

SEGMENT_NAME SEGMENT_TYPE

-

-IDX2_SALES_PROD INDEX

SQLPLUS> select event, total_waits, time_waited

from v$system_event;

EVENT TOTAL_WAITS TIME_WAITED

- -

-db file sequential read 3591611 2309586

SQL*Net message from client 3950929 1892

log file sync 182955 1134406

Some waits give clues to performance issues; others are normal events

that are to be expected For example, a db file sequential read event is a

block read by indexes So the indexes are being used instead of full-table

scans On the other hand, db file scattered read waits could indicate the use

of full-table scans However, you should gather more information if you see

that the waits are too high because of I/O issues

The SQL*Net message from client event is the wait for the client to tell

the database server to do something It is just waiting for instructions, and

really isn’t contributing to issues—you can’t blame the database for being

slow because a session was waiting for an action while the user went to get

coffee There might be applications that open sessions and then just wait for responses before getting data from the database

We’ll look at some other ways to check waits in the “Automatic Workload Repository” section later in this chapter

SQL Plans

As a DBA, you know that tuning SQL statements is a good place to start improving performance If changes can be made to the code or available indexes, that is normally the quickest way to get results

With SQL Server, you can get the execution plan from SQL Server Management Studio or by enabling showplan_all This will provide information about the plan for which order to join the tables and the indexes to use

Oracle plans are available through the OEM tools, and they can be traced through SQL*Plus as well The plans can be saved in the plan table

or just seen in the output from the trace

Viewing Explain Plans

Let’s first look at a quick way to use SQL*Plus to see the explain plan for

a query

## To see query results and the execution plan set autotrace SQLPLUS> set autotrace on explain

SQLPLUS> select empno from emp where deptno=10;

EMPNO

-7782

7839

7934

Execution Plan

-Plan hash value: 3956160932

-| Id | Operation | Name | Rows |Cost (%CPU)| Time

-| 0 | SELECT STATEMENT | | 5 | 3 (0)| 00:00:01

|* 1 | TABLE ACCESS FULL| EMP | 5 | 3 (0)| 00:00:01 -Predicate Information (identified by operation id):

-1 - filter("DEPTNO"= -10)

## Traceonly will not execute the query but just

## show the plan

SQLPLUS> set autotrace traceonly explain

SQLPLUS> select empno from emp where deptno=10;

Execution Plan

-Plan hash value: 3956160932

-| Id | Operation | Name | Rows | Cost (%CPU)| Time

-| 0 | SELECT STATEMENT | | 5 | 3 (0)| 00:00:01

|* 1 | TABLE ACCESS FULL| EMP | 5 | 3 (0)| 00:00:01

-Predicate Information (identified by operation id):

-1 - filter("DEPTNO"= -10)

## Only difference was that the rows were not returned

## Notice the plan hash is the same

## Add index to see new plan

SQLPLUS> create index idx_emp1 on emp(deptno);

Index created.

SQLPLUS> select empno from emp where deptno=10;

Execution Plan

-Plan hash value: 306890541 ## NEW PLAN VALUE

-| Id | Operation | Name | Rows | Cost (%CPU)| Time

-| 0 | SELECT STATEMENT | | 5 | 2 (0)| 00:00:01

| 1 | TABLE ACCESS BY

INDEX ROWID| EMP | 5 | 2 (0)| 00:00:01

|* 2 | INDEX RANGE SCAN | IDX_EMP| 5 | 1 (0)| 00:00:01

-Predicate Information (identified by operation id):

-2 - access("DEPTNO"=10)

The plan table, if it does not already exist, can be created from the SQL

provided in ORACLE_HOME/rdbms/admin/utlxplan.sql

## To put the execution plan into the plan table for viewing

SQLPLUS> explain plan set statement_id='my_example' for

select * from claim where claim_id=100;

Explained.

## To see the results

SQLPLUS> select * from table(dbms_xplan.display);

-Plan hash value: 3956160932

-| Id | Operation | Name | Rows |Cost (%CPU)| Time

-| 0 | SELECT STATEMENT | | 5 | 3 (0)| 00:00:01

|* 1 | TABLE ACCESS FULL|CLAIM | 5 | 3 (0)| 00:00:01

-You can also see the explain plan through the SQL Developer GUI In Figure 8-4, the icons to get the explain plan are circled

Tuning Using Explain Plans

In the explain plan, look for how the tables and indexes are accessed Also see if the indexes being used are the ones expected and if there are other options that would be better

FIGURE 8-4. Viewing an explain plan in SQL Developer

The explain plan will show the method used to access indexes:

■ A unique scan is normally seen with an unique index

■ A range scan is used when multiple values could be returned for the

nonunique index

■ A full or fast full scan of the index may be performed when more

data is being accessed or it is just more efficient to scan all the data

instead of sorting for the range scan

For tables, the quickest access method is by row ID Seeing full-table

scans might mean that you can use indexes to improve performance How

the tables are being joined also affects the query The methods for joining

tables include sort merge join, nested loops, and hash join

The cost-based optimizer (CBO) pulls in the details about the system and

objects to create execution plans The CBO evaluates the details, and then it

does transformation of the statements for complex queries In performing

these steps, it also calculates the cost to choose the access paths, join orders,

and join methods The cost of the query is included in the explain plan, which can help you with tuning and knowing which plan might be better

The object statistics are needed for the CBO to be able to create the best

execution plan Incomplete or stale information could cause the optimizer

to use a full-table scan or an inefficient method to access indexes To make

the CBO’s job easier, you should ensure that the queries are coded the best

they can be, the statistics are updated, and the required indexes are present

NOTE

Earlier versions of Oracle used a rule-based

optimizer (RBO) Then in the next couple of

Oracle versions, you could choose between the

RBO and CBO, and even let Oracle choose the

best method There were even times when

deleting statistics from a table or using the RULE

hint (no longer available with Oracle Database

11g) would improve performance Now, with

the automated statistics gathering and the use of

the information that is available, as well as being

able to do some transformations of the queries,

the CBO has gotten smarter and can create

efficient query plans

You can use hints to suggest another path or direction for the CBO Here are a couple examples:

## Hint to just append the rows to the end on an insert

SQLPLUS> insert /*+ APPEND */ into table1 select …

## Hint to use an index

SQLPLUS> select /*+ INDEX(a) */ col1, col2 from a where …

However, you should be careful about using hints They might get you a performance boost for the current plan, but upgrades and other information might come along, and the CBO could have better information about a faster plan to use

The CBO definitely needs valid statistics and information, and there are database parameters that can help to decide the best execution plans

Statistics for Tables and Indexes

Because of the CBO, statistics is one of the first areas that I validate when looking at performance Do the index and table have statistics? Are they current statistics? Do the row counts in the statistics match the current row count? The row counts could point to a load happening after or during the time statistics are being generated The CBO uses the information available, and if the information is not current or valid, that will not lead to good execution plans

SQLPLUS> select num_rows, last_analyzed

from dba_tab_statistics

where table_name='SALES';

NUM_ROWS LAST_ANALYZED

-1490 15-MAR-10

SQLPLUS> select count(1) from sales;

COUNT(1)

-3919232

## Actual row count and number of rows in statistics different

## gathering statistics could be useful here.

You may consider making adjustments to the sample size and the

frequency of the statistics collection The statistics can also be adjusted to improve plans and methods of scans and access Specific values can be set

for an index such that it appears that there are more or less distinct values or

a different number of rows

SQLPLUS> exec dbms_stats.set_column_stats('SCHEMA1','TAB1',

'COL1', DISTCNT => 8, NO_INVALIDATE => FALSE);

PL/SQL procedure successfully completed.

## Once set the statistics can be locked

## Now lock statistics

SQLPLUS> exec dbms_stats.lock_table_stats('SCHEMA1','TAB1');

PL/SQL procedure successfully completed.

## Or if didn’t help just unlock and gather the stats again

SQLPLUS> exec dbms_stats.unlock_table_stats('SCHEMA1','TAB1');

PL/SQL procedure successfully completed.

SQLPLUS> exec dbms_stats.gather_table_stats('SCHEMA1','TAB1',

CASCADE => TRUE);

PL/SQL procedure successfully completed.

## Or restore the statistics (schema, table and timestamp)

SQLPLUS> exec dbms_stats.restore_table_stats('SCHEMA1',

'TAB1','12-MAR-10 06.40.33.900462 PM -05:00');

PL/SQL procedure successfully completed.

## Number of rows might be useful if a table is loaded as a

## batch process and starts off with zero each time.

SQLPLUS> exec dbms_stats.set_table_stats('SCHEMA1','TAB2',

NUMROWS => 4000000, NO_INVALIDATE => FALSE);

Taking a look in the area of table and index statistics is well worth the

time when it comes to tuning current statements You do need to be careful

to avoid overdoing adjustments or trying to outsmart the CBO However,

when other options are exhausted, a gentle nudge in one direction can help

improve the execution of the queries

Database Parameters

Not to say that these are the only parameters to look at when tuning queries, but Figure 8-5 has the list of database parameters that are classified in the

optimizer area For most parameters, the Help column includes a link to

specific information about the parameter’s default value and use