ORACLE SQL Performance Optimization Series (1)

Original July 21, 2003 18:34:00

<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

1. Select a suitable ORACLE optimizer

There are 3 kinds of optimizers in ORACLE:

a. RULE (rule based) b. COST (cost based) c. CHOOSE (optional)

To set the default optimizer, you can pass various declarations of the OPTIMIZER_MODE parameter in the init.ora file, such as RULE, COST, CHOOSE, ALL_ROWS, FIRST_ROWS. Of course, you can also perform it at the SQL statement level or session level. cover.

In order to use the Cost-Based Optimizer (CBO), you must run the analyze command frequently to increase the accuracy of the object statistics in the database.

If the optimizer mode of the database is set to selective (CHOOSE), then the actual optimizer mode will be related to whether the analyze command has been run. If the table has been analyzed, the optimizer mode will automatically become CBO, otherwise, the database will use RULE optimizer of the form.

By default, ORACLE uses the CHOOSE optimizer, in order to avoid those unnecessary full table scans (full table scan), you must try to avoid using the CHOOSE optimizer, and directly use the rule-based or cost-based optimizer.

2. How to access Table

ORACLE uses two ways to access records in a table:

a. Full table scan

A full table scan is to access each record in a table sequentially. ORACLE optimizes full table scans by reading multiple data blocks at a time.

b. Access the table by ROWID

You can use the ROWID-based access method to improve the efficiency of accessing the table. ROWID contains the physical location information recorded in the table. ORACLE uses the index (INDEX) to realize the relationship between the data and the physical location (ROWID) where the data is stored. Contact. Usually indexes provide fast access to ROWID, so those queries based on indexed columns can get performance improvements.

3. Shared SQL Statements

In order not to parse the same SQL statement repeatedly, after the first parsing, ORACLE stores the SQL statement in memory. The memory in the shared buffer pool (shared buffer pool) located in the system global area SGA (system global area) can be Shared by all database users. So when you execute an SQL statement (sometimes called a cursor), if it

Exactly the same as the previously executed statement, ORACLE can quickly get the parsed statement and the best

Execution path. This feature of ORACLE greatly improves SQL execution performance and saves memory usage.

Unfortunately, ORACLE only provides cache buffering for simple tables, which is not suitable for multi-table join queries.

The database administrator must set appropriate parameters for this area in init.ora. When the memory area is larger, more statements can be reserved, and of course, the greater the possibility of being shared.

When you submit an SQL statement to ORACLE, ORACLE will first look for the same statement in this memory.

It should be noted here that ORACLE adopts a strict match between the two. To achieve sharing, the SQL statement must

Exactly the same (including spaces, newlines, etc.).

A shared statement must satisfy three conditions:

A. Character-level comparison:

The currently executed statement and the statement in the shared pool must be identical.

E.g:

SELECT * FROM EMP;

is different from each of the following

SELECT * from EMP;

Select * From Emp;

SELECT * FROM EMP;

B. Both statements must refer to exactly the same object:

E.g:

User Object Name How to Access

Jack sal_limit private synonym

Work_city public synonym

Plant_detail public synonym

Jill sal_limit private synonym

Work_city public synonym

Plant_detail table owner

Consider whether the following SQL statements can be shared between these two users.

SQL

can share

reason

select max(sal_cap) from sal_limit;

can not

Each user has a private synonym - sal_limit , they are different objects

select count(*0 from work_city where sdesc like 'NEW%';

can

Two users accessing the same object public synonym - work_city

select a.sdesc,b.location from work_city a , plant_detail b where a.city_id = b.city_id

can not

User jack accesses plant_detail via private synonym and jill is the owner of the table, the objects are different.

C. Bind variables with the same name must be used in both SQL statements

E.g:

The two SQL statements in the first group are the same (can be shared), while the two SQL statements in the second group are different (even if different bind variables are assigned the same value at runtime)

select pin , name from people where pin = :blk1.pin;

select pin , name from people where pin = :blk1.ot_ind;

select pin , name from people where pin = :blk1.ov_ind;

(to be continued)

ORACLE SQL performance optimization series (1) black_snai

ORACLE SQL Performance Optimization Series (1)

Guess you like