Descripción general de las fases de procesamiento de una sentencia SQL

En este post podemos  ver un esquema simplificado de las fases de procesamiento de una sentencia SQL.

Una vez que una sentencia es envíada al motor de base de datos Oracle, pasa por las siguientes fases que determinan la mejor manera de resolverla.

En la siguiente tabla podemos ver resumen muy simplificado y abstracto de las fases involucradas durante el procesamiento de una consulta SELECT.

PARSE	Statement matching, syntactic and semantic checks			Statement is checked against the library cache to determine if it already exists and the syntax and structure are checked.
	Query Transformation			Certain query contructs (e.g. Views, subqueries) may be transformed at this stage to open up new join and access possibilities
	RBO - plan determined using rules (Obsolete as of Oracle 10g)	CBO	Determine object costs and cardinalities	Individual objects are costed and the number of rows (cardinality) is determined.
			Cost different join orders	Join orders and methods are evaluated and the plan with the overall lowest cost is chosen
			Build structures for runtime	Run time structures are built and stored in the library cache. At execution time these structures are used to drive the query.
EXECUTE				Memory areas are allocated for bind variables, values are filled and the plan generated by the PARSE phase are executed.
FETCH				Data blocks are retrieved, unwanted rows are removed and data is sorted as necessary. Resultant rows are presented to the application.

Oracle registra estadísticas individuales para las fases PARSE, EXECUTE y FETCH que se pueden ver realizando un “tracing” (utilizando SQL_TRACE). Para fines de registro netamente estadístico, la operación de “Query Optimization” forma parte de la fase PARSE.

Este es un ejemplo bastante general de procesamiento. Algunas de las fases pueden ser reposicionadas o reordenadas dependiendo del tipo de consulta que haya sido enviada.

De igual manera, Oracle puede también combinar diferentes pasos o diferirlos a una etapa posterior. Por ejemplo, si  ‘bind variable peeking' está en activo, el optimizador debe utilizar el primer valor 'bound' para determinar el plan de ejecución de la consulta. Esto significa que la optimización ocurrirá realmente en la fase EXECUTE, ya que ésta será la primera vez que algún valor de la variable “bind” este disponible. 

Fuente: MOS (Doc ID 199273.1)