01 oracle architecture

Technical Skills Enhancement – PL/SQL Best practices

Oracle Architecture

Objectives

At the end of this session, you will be able to:

• Understand Oracle Architecture

• Database Buffer Cache

• Shared Pool

• Write better performing queries

Agenda• Introduction to “Performance Tuning”

• What is a database?

• What is a database instance?

• System Global Area

• Program Global Area

• Database Buffer cache

• Cache Hit Ratio

• Buffer Cache and Full table scan

• Shared Pool

• Avoid Code Repetition

• Use bind variables

• Bind variable peeking

• Avoid hardcoding

• Performance tuning tools

Introduction – SQL and PL/SQL tuning

• Tuning SQL and PL/SQL code is an iterative and incremental process.

• There is no “Silver Bullet” (Straightforward solution perceived to have extreme effectiveness)

• Nothing is “Set in stone”. You have to keep up with technology and continue learning and experimenting.

• Tuning Oracle database programs involves three main areas :– SQL statements– PL/SQL code (Logic, algorithms)– Memory utilization and management of code

Introduction – SQL and PL/SQL tuning• Factors affecting performance of a database

90%

60%

Oracle Database Architecture

An Oracle database server consists of a database and at least one database instance(commonly referred to as simply an instance). Because an instance and a database are so closely connected, the term Oracle database is sometimes used to refer to both instance and database. In the strictest sense the terms have the following meanings:

■ Database

•A database is a set of files, located on disk, that store data. These files can exist independently of a database instance.

■ Database instance

•An instance is a set of memory structures that manage database files and user interactions.

•The instance consists of 2 memory areas – System Global Area (SGA), which is shared by all user, server and

background processes.

– Program Global Areas (PGA), which is private to each user, server and background process; there is one PGA for each session/process.

Oracle Architecture

System Global AreaThe SGA is read/write. If multiple users are concurrently connected to the same instance, then the data in the instance's SGA is shared among the users.

The SGA contains the following data structures:

– Database buffer cache

– Redo log buffer

– Shared pool

– Java pool

– Large pool (optional)

– Streams pool

– Other miscellaneous information

System Global Area – Database buffer cache

FunctionPGA

System Global Area – Database buffer cache

First access

Subsequent accesses

PGAFunction

Database

2. Not in cache;Request datafrom database

3. Pass Datato Cache

Application

1. Application Requests Data

4. Data retrieved from cache 5. Data returned

to application

Application

1. Application Requests Data

4. Data returned to application

3. Data retrieved from cache

Database2. Data found in

cache. No need to read from disk

System Global Area – Cache hit ratioA properly sized buffer cache can usually yield a cache hit ratio over 90%, meaning that nine requests out of ten are satisfied without going to disk.

•Designing your program in such a way that queries against a table are adjacent to each other than spread across the program will ensure better cache hit ratio.

•Scheduling similar batch jobs together (or next to each other) in the same time window will also ensure better cache hit ratio. Eg: scheduling “Audit management” infolets next to each other in the same time window and then all “Risk management” infolets in the next timeslot will ensure better performance than mixing them.

•Batch Processes that handle large data set must be scheduled in non-peak hours to reduce cache misses for regular application users.

System Global Area – Buffer cache and FTS

System Global Area – Buffer cache and FTS

Buffer Cache and Full Table Scan

•When the user process is performing a full table scan, it reads the blocks of the table into buffers and puts them on the LRU end (instead of the MRU end) of the LRU list.

•This is because (“Oracle assumes that ”)a fully scanned table usually is needed only briefly, so the blocks should be moved out quickly to leave more frequently used blocks in the cache.

•You can control this default behavior of blocks involved in table scans on a table-by-table basis. To specify that blocks of the table are to be placed at the MRU end of the list during a full table scan, use the CACHE clause when creating or altering a table. CREATE TABLE status_lookup (CODE VARCHAR2(2), DESCRIPTION VARCHAR2(30)) CACHE;

•You can specify this behavior for small lookup tables or static historical tables to avoid I/O on subsequent accesses of the table.

•This will help improve performance if the table is accessed frequently.

System Global Area – Shared Pool

System Global Area (SGA)

Shared Pool

show_empscalc_totals upd_salaries

Select * from emp

Shared SQL

Pre-parsedUpdate emp Set sal=...

Library cache

Session 1 memory (PGA/UGA)

emp_rec emp%rowtype;tot_tab tottabtype;

Session 2 memory (PGA/UGA)

emp_rec emp%rowtype;tot_tab tottabtype;

User 1User 2


Dictionary Cache

• Oracle saves memory in shared pool by using one shared SQL area for SQL statements run multiple times. Oracle recognizes when two users are executing the same SQL statement and reuses the shared SQL area for those users. The statements have to be EXACTLY the same including character spacing and character case.

• The below statements are not treated as the same statements by Oracle

Script: SharedPool.sql

SELECT DUMMY FROM DUAL ;

SELECT DUMMY FROM dual ;

SELECT DUMMY FROM DUAL ;

These statements will be parsed separately and stored separately in shared pool.


• For better performance

– Modularize and reuse program units as much as possible.

– Avoid repeating SQL statements. Write once and use many times.

– Use bind variables

– Avoid hard coding

– Follow coding guidelines, standards and naming conventions in your project.

– Ensure developers write code the same way. Achieve a consistent, readable coding style


– When a snippet of code is repeated across the application, then it is almost impossible to know/keep track of all the places it occurs. This becomes especially difficult when code changes have to be implemented.

– Encapsulate all SQL statements behind a procedural interface, usually a package.

– Hide all single row queries behind functions

– Hide entire DML statements in procedures, so you can choose (and change) the implementation for optimal performance

– Use common, standardized exception handling, error and event logging across the application

– Rely on pre-built, pre-tested, write-once, use-often PL/SQL programs.

These guidelines are aimed at optimizing the use of shared pool.

System Global Area – Shared Pool – Avoid code repetition

If you have a Java program that does for (int i=0; i<userArray.length; i++) {

String delQuery = “DELETE FROM si_users WHERE user_id = “ +

userArray[i];

stmt.executeUpdate(delQuery);

}

When executed, this code generates SQL as below. Each statement has to be parsed separately in

Shared Pool !. Bad Idea !

DELETE FROM si_users WHERE user_id = 100001






...

System Global Area – Shared Pool – Use bind variables

Parsing is expensive!!!

System Global Area - Use bind variables

It can be rewritten as below-

String delQuery = “DELETE FROM si_users WHERE user_id = ?”;

// Alternatively use

// delQuery = si_users.delete_user(?);

stmt = conn.prepareCall(delQuery);

for (int i=0; i<userArray.length; i++) {

stmt.setInt(1, userArray[i]);

stmt.execute();

}

Inside shared pool

DELETE FROM si_users WHERE user_id = :b1

A very happy database !!!


Bind variables in PL/SQL

•The good news is that PL/SQL itself takes care of most of the issues to do with bind variables, to the point where most code that you write already uses bind variables without you knowing. Take, for example, the following bit of PL/SQL:

create or replace procedure updsal(p_empno in number)as begin update emp set sal=sal*2 where empno = p_empno; commit; end;/


Bind variables in PL/SQL

•DO NOT: “where created_date > to_date(’01-sep-2006’)..”

•BETTER :

v_date := to_date(’01-sep-2006’)

where created_date > v_date “

System Global Area - Use bind variablesBind variables in Dynamic PL/SQL

Special care must be taken while writing dynamic SQL.

The code below does not use bind variable, instead it builds a new SQL statement each time concatenating the value in TO_CHAR(i).

Script : BindVariables.sqlDECLARE

l_dummy dual.dummy%TYPE;

BEGIN

FOR i IN 1 .. 10 LOOP

BEGIN

EXECUTE IMMEDIATE 'SELECT dummy FROM dual WHERE dummy = ''' || TO_CHAR(i) || ''''

INTO l_dummy;

EXCEPTION

WHEN NO_DATA_FOUND THEN

NULL;

END;

END LOOP;

END;


Using bind variable…..DECLARE

l_dummy dual.dummy%TYPE;

BEGIN

FOR i IN 1 .. 10 LOOP

BEGIN

EXECUTE IMMEDIATE 'SELECT dummy FROM dual WHERE dummy = TO_CHAR(:dummy)'

INTO l_dummy USING i;

EXCEPTION

WHEN NO_DATA_FOUND THEN

NULL;

END;

END LOOP;

END;

Bind Variable Peeking

• When Oracle sees a brand new query (not yet parsed) with bind variable, in an effort to choose the best plan Oracle “peeks” at the value of the bind variable and then chooses the plan accordingly.

• This plan is then utilized for all subsequent runs of the same query.

• This could be beneficial in a good percentage of cases.

• In certain situations this may produce unpredictable results

• A table with 10 million rows. A column has 2 distinct values Y and N. 99% of the rows contain the value Y and 1% contain the value N. (Skewed data)

• When Y is used (non selective) in the WHERE clause a full table scan would be the best approach

• When N is used in the WHERE clause an INDEX scan would be best

• If query with Y was run first, it would always perform FTS which will considerably slow down the application

• If query with N was run first, it would always perform INDEX scan which would make N queries very fast, but slightly slow down Y queries

Bind Variable Peeking – Cause and effect – On a lighter note

The butterfly effect

In chaos theory , a butterfly flapping its wings gently in a far away tropical forest could cause major hurricanes a few weeks later in the east coast of United States!!

The Rain effect

There was an application where, whenever it rains on a Monday morning - the database had to be restarted in the afternoon to make it perform correctly.

*Every Monday morning*, *every single time* if it rains the DB slows down. Since the users have experienced it several 100 times they would call up the DBA and say- "It is Monday, it is raining, you know what to do", after the reboot, everything is running fast again.

What did Monday morning rain have to do with DB performance???

Bind Variable Peeking – Cause and effect – On a lighter note

The Rain effect

•The DBAs took backups on Sunday nights emptying the shared pool

•The application had a frequently executed query on a table with skewed data. The query would run with selective value only for “A user”. This user lives far away from office. He normally arrived office at 6am.

•On regular Monday mornings the query would be executed for the first time (hence hard parsed) for him with selective value. Due to BVP it would register INDEX scan. INDEX scan it is for all subsequent runs. Not bad at all.

•On rainy days he comes in late after the rain subsides. If rain happens to fall on Monday morning while the shared pool is empty, then the larger user group with non-selective value hits the application first, registering FTS. FTS it is for all subsequent runs. Bringing the DB to its knees.

So…… who is the culprit now, the rain or BVP????

Avoid hard coding

Avoid hard coding not only for better performance, but also for the below reason-

Hard Coding – Someone assumed that something will never change and that is ne ve r true !!. Avoid hardcoding to reduce source code impact when requirements change.

•Avoid hard coding literal values IF num_requests > 100 THENIF num_requests > l_limit THEN

•Whenever possible, use anchored declarations rather than explicit datatype references

VARCHAR2(20); Hard coded declarationTablename.fieldname%type; Anchored declarationTablename%rowtype; Anchored declaration

Avoid hard codingAvoid hard coding in cursors. Instead use parameterized cursors. In some cases this will also facilitate usage of bind variables.

Instead of ….

DECLARE

CURSOR dept_cur IS

SELECT last_name FROM employee

WHERE department_id = 10;

BEGIN

OPEN dept_cur;

Rewrite as below …

DECLARE

CURSOR dept_cur (dept IN INTEGER) IS

SELECT last_name FROM employee

WHERE department_id = dept;

BEGIN

OPEN dept_cur (20); ……

PL/SQL Tuning for performance

Some methods used to measure and analyze performance of PL/SQL code

• Utilize Oracle’s Tools – EXPLAIN_PLAN– Autotrace– V$SQLAREA– AWR/ADDM report …….

• Third party tools– Quest SQLab, – Quest Spotlight, – Computer Associates SQL Station Plan Analyzer .......

• Homegrown utilities– Timer Utility for procedures– SMC

• Code reviews

• Load Testing


• Explain Plan

• Whenever an SQL statement is run, Oracle parses and analyzes the query to find the most effective way to execute the query and then designs an execution plan for it.

• This execution plan is basically a step by step instruction for how the statement must be executed. That is, the order in which the tables are read, if indexes are used, which join methods are used to join tables and so on.

It shows the following information:

• Ordering of the tables referenced by the statement

• Access method for each table mentioned in the statement

• Join method for tables affected by join operations in the statement

• Data operations like filter, sort, or aggregation

• Cost and Cardinality of each operation

Performance Tuning Best practices – Explain plan

Understanding the execution plan –•Cost - The estimated resource usage for that plan. The lower the cost the more efficient the plan is expected to be. The optimizer’s cost model accounts for the I/O, CPU and network resources that will be used by the query.

•Cardinality– Estimate of the number of rows coming out of each of the operations.

•Access method – The way in which the data is being accessed, via either a table scan or index access. Eg: Full table scan, table access by ROWID, Index unique scan, Index range scan etc

•Join method – The method (e.g., hash, nested loops, sort-merge, etc.) used to join tables with each other.


• Sample execution plan

PL/SQL Tuning for performanceAutotrace :

•In SQL*Plus you can automatically get a report on the execution path used by the SQL optimizer and the statement execution statistics. The report is generated after a successful SQL DML statement, such as SELECT, DELETE, UPDATE or INSERT. It is useful for monitoring and tuning the performance of these DML statements.

Thank YouFeedback, Questions, Discussion

01 oracle architecture

Technology

database files

databasea database

database instancean

term oracle database

better cache

sized buffer cache

ratiobuffer cache

cache misse