Академический Документы
Профессиональный Документы
Культура Документы
practices
Oracle Architecture
Objectives
At the end of this session, you will be able to:
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 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
System Global Area – Database buffer cache
System Global Area – Database buffer cache
4. Data retrieved
First access 3. Pass Data from cache 5. Data returned
to Cache to application
Database Application
Function
2. Not in cache; PGA
Request data 1. Application
from database Requests Data
2. Data found in
cache. No need to Application
Database read from disk
Function
PGA
1. Application
Requests Data
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.
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 – Shared Pool
Instead of ….
DECLARE
CURSOR dept_cur IS
• Homegrown utilities
– Timer Utility for procedures
– SMC
• Code reviews
• Load Testing
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
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.
PL/SQL Tuning for performance