SQL Overview

DDL Statement Processing

The execution of DDL statements differs from the execution of DML statements and queries, because the success of a DDL statement requires write access to the data dictionary. For these statements, parsing (Stage 2) actually includes parsing, data dictionary lookup, and execution.

Transaction management, session management, and system management SQL statements are processed using the parse and run stages. To rerun them, simply perform another execute.

Control of Transactions

In general, only application designers using the programming interfaces to Oracle are concerned with the types of actions that should be grouped together as one transaction. Transactions must be defined so that work is accomplished in logical units and data is kept consistent. A transaction should consist of all of the necessary parts for one logical unit of work, no more and no less.

Data in all referenced tables should be in a consistent state before the transaction begins and after it ends.

Transactions should consist of only the SQL statements that make one consistent change to the data.

For example, a transfer of funds between two accounts (the transaction or logical unit of work) should include the debit to one account (one SQL statement) and the credit to another account (one SQL statement). Both actions should either fail or succeed together as a unit of work; the credit should not be committed without the debit. Other unrelated actions, such as a new deposit to one account, should not be included in the transfer of funds transaction.

In addition to determining which types of actions form a transaction, when you design an application you must also determine when it is useful to use the BEGIN_ DISCRETE_TRANSACTION procedure to improve the performance of short, non-distributed transactions.

See Also: "Discrete Transaction Management" on page 16-11

The Optimizer Overview

The optimizer determines the most efficient way to run a SQL statement. This is an important step in the processing of any data manipulation language (DML) statement: SELECT, INSERT, UPDATE, MERGE, or DELETE. There are often many different ways to run a SQL statement; for example, by varying the order in which

14-14 Oracle9i Database Concepts

SQL Overview

tables or indexes are accessed. The procedure Oracle uses to run a statement can greatly affect how quickly the statement runs. The optimizer considers many factors among alternative access paths. It can use either a cost-based or a rule-based approach. In general, always use the cost-based approach. The rule-based approach is available for the benefit of existing applications.

Note: The optimizer might not make the same decisions from one version of Oracle to the next. In recent versions, the optimizer might make different decisions based on better information available to it.

You can influence the optimizer's choices by setting the optimizer approach and goal. You can also gather statistics for the cost-based optimizer (CBO), using the PL/SQL package DBMS_STATS.

Sometimes the application designer, who has more information about a particular application's data than is available to the optimizer, can choose a more effective way to run a SQL statement. The application designer can use hints in SQL statements to specify how the statement should be run.

See Also:

Oracle9i Supplied PL/SQL Packages and Types Reference for information about using DBMS_STATS

Oracle9i Database Performance Tuning Guide and Reference for more information about the cost-based optimizer, the rule-based optimizer, and the extensible optimizer

Execution Plans

To run a DML statement, Oracle might need to perform many steps. Each of these steps either retrieves rows of data physically from the database or prepares them in some way for the user issuing the statement. The combination of the steps Oracle uses to run a statement is called an execution plan. An execution plan includes an access method for each table that the statement accesses and an ordering of the tables (the join order). The steps of the execution plan are not performed in the order in which they are numbered.

Stored Outlines Stored outlines are abstractions of an execution plan generated by the optimizer at the time the outline was created and are represented primarily as a set of hints. When the outline is subsequently used, these hints are applied at

SQL, PL/SQL, and Java 14-15