Strengths of relational query language is the wide variety of ways in which a user can express the query and system can evaluate it
How flexible the queries are written , it expresses the performance (good/bad) greatly on the quality of query optimizer
Queries are parsed and then presented to query optimizer, which is responsible for identifying an efficient execution plan
Optimizer generates the alternative plans and least estimated cost plan is chosen ;Query is essentially treated as σ – П – join algebra exprn with remaining operations carried out on the result of above exprn
Query optimization is the process of identifying the access plan with the minimum cost
Cost = Time taken to get all the answers
Starting with System-R, most DBMSs use the same algorithm
generate most of the access plans and select the cheapest one
First, how do we determine the cost of a plan?
Then, how long is this process going to take and how do we make it faster?
The formula for the cost (using the CPU Costing Model) of a query is: Cost = ( #SRds * sreadtime + #MRds * mreadtime + #CPUCycles / cpuspeed ) / sreadtime where: #SRds = number of single block reads #MRds = number of multi block reads #CPUCycles = number of CPU Cycles sreadtim = single block read time mreadtime = multi block read time cpuspeed = Standard 'Oracle' CPU cycles per second The translation of this formula is: The cost is the time spent on single block reads, plus the time spent on multiblock reads, plus the CPU time required, all divided by the time is takes to do a single block read. This means that the cost of a query is the PREDICTED EXECUTION TIME, counted in number of single block read times and is effectively the unit of measure of the cost.
The following operations are made during the parsing .
Validate the syntax of the statement: is the query a valid SQL statement? SQL> select nothing where 1=2; select nothing where 1=2 * ERROR at line 1: ORA-00923: FROM keyword not found where expected
Validate the semantic of the statement: are the objects valid? is there any ambiguity? does the constant fit into the column?... SQL> select col from not_existent_table; select col from not_existent_table * ERROR at line 1: ORA-00942: table or view does not exist Search in the shared pool :
Is the query text already known (search among all the query texts)? if not, error
Does the query referenced the same objects (search among all versions of the query)? if not, error
Is the execution environment identical (same search)? If yes, execute the query.
Allocate memory in the shared pool to store the data about the query
Get the values of the bind variables and check if all values fit in the columns
SQL> var v varchar2(20); SQL> exec :v := '12345678901' PL/SQL procedure successfully completed. SQL> insert into michel.t values (:v); insert into michel.t values (:v) * ERROR at line 1: ORA-12899: value too large for column "MICHEL"."T"."COL" (actual: 11, maximum: 10)
Optimize the query execution
Build the parse tree and the execution plan in a format that the SQL engine can use, this is named row source generation
Store the parse tree and the execution plan in the shared pool .
Once the SQL stmt is transformed , the DBMS created what is commonly known as an access/execution plan
Access/execution plan contains series of steps a DBMs will use to execute the query and return the result set in most efficient way
SQL execution :- all i/o operations are indicated in the access plan are executed. When the execution plan is run, the proper locks are acquired for the data to be accessed and then retrieved from data files and placed in DBMs data cache
SQL fetching :- after the parsing and execution phases are completed, all rows that match the specified conditions are retrieved ,sorted and grouped and/or aggregated
In the fetching phase, the rows of resulting query result set are returned to the client. During this phase, the DBMS may use temporary table space to store temporary data
Query Graph is a single graph corresponding to each query. It does not specify any order on which operation to perform first.
Query Plan ( prev.diag) presents a specific order of operations for executing a query.
It is a set of steps used to help accessing and modifying a SQL RDMS. Since SQL is declarative, there are typically a large number of alternative ways to execute a given query, with widely varying performance.
When a query is submitted to the database, the query optimizer evaluates some of the different, correct possible plans for executing the query and returns what it considers the best alternative
SQL query will be analysed first and parsed into a query graph