Oracle Architecture in regards to writing better performing queries. Understand Oracle Architecture Database Buffer Cache Shared Pool Write better performing queries

1. Technical Skills Enhancement – PL/SQL Best
practices
Oracle Architecture

2. Objectives
At the end of this session, you will be able to:
• Understand Oracle Architecture
• Database Buffer Cache
• Shared Pool
• Write better performing queries

3. 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

4. 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

5. Introduction – SQL and PL/SQL tuning
• Factors affecting performance of a database
90%
60%

6. 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.

7. Oracle Architecture

8. System Global Area
The 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

9. System Global Area – Database buffer cache

10. Function
PGA
System Global Area – Database buffer cache
First access
Subsequent accesses
PGA
Function
Database
2. Not in cache;
Request data
from database
3. Pass Data
to 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
Database
2. Data found in
cache. No need to
read from disk

11. System Global Area – Cache hit ratio
A 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.

12. System Global Area – Buffer cache and FTS

13. 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.

14. System Global Area – Shared Pool

15. System Global Area (SGA)
Shared Pool
show_empscalc_totals upd_salaries
Select *
from emp
Shared SQL
Pre-parsed
Update 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 1
User 2
System Global Area – Shared Pool
Dictionary
Cache

16. • 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.
System Global Area – Shared Pool

17. • 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
System Global Area – Shared Pool

18. – 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

19. 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
DELETE FROM si_users WHERE user_id = 100002
DELETE FROM si_users WHERE user_id = 100003
DELETE FROM si_users WHERE user_id = 100004
DELETE FROM si_users WHERE user_id = 100005
DELETE FROM si_users WHERE user_id = 100006
...
System Global Area – Shared Pool – Use bind
variables
Parsing is
expensive!!!

20. 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
!!!

21. System Global Area - Use bind variables
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;
/

22. System Global Area - Use bind variables
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 “

23. System Global Area - Use bind variables
Bind 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.sql
DECLARE
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;

24. System Global Area - Use bind variables
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;

25. 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

26. 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???

27. 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????

28. 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 THEN
IF num_requests > l_limit THEN
•Whenever possible, use anchored declarations rather than
explicit datatype references
VARCHAR2(20);  Hard coded declaration
Tablename.fieldname%type;  Anchored declaration
Tablename%rowtype;  Anchored declaration

29. Avoid hard coding
Avoid 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

30. 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

31. PL/SQL Tuning for performance
• 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

32. 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.

33. PL/SQL Tuning for performance
• Sample execution plan

34. PL/SQL Tuning for performance
Autotrace :
•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.

35. Thank You
Feedback, Questions, Discussion