Академический Документы
Профессиональный Документы
Культура Документы
Integrante:
Gabriel Lpez 06-39810
Caracas, 21 de Noviembre del 2011
Para evaluar el desempeo de las mejoras propuestas por el equipo en la fase I del diseo de la
Base de Datos de FVB se seleccionaron las consultas Q1 y Q2. A continuacin se har un breve
anlisis sobre el desempeo de estas consultas en su forma original y con las modificaciones
propuestas a fin de observar si se logr optimizar el desempeo de estas consultas.
Q1)
select s_name, count(*) as numwait
from supplier, lineitem l1, orders, nation
where s_suppkey = l1.l_suppkey
and o_orderkey = l1.l_orderkey
and o_orderstatus = 'F'
and l1.l_receiptdate > l1.l_commitdate
and exists (
select *
from lineitem l2
where l2.l_orderkey = l1.l_orderkey
and l2.l_suppkey <> l1.l_suppkey)
and not exists (
select *
from lineitem l3
where l3.l_orderkey = l1.l_orderkey
and l3.l_suppkey <> l1.l_suppkey
and l3.l_receiptdate > l3.l_commitdate)
and s_nationkey = n_nationkey
and n_name = '&nation'
group by s_name
Q2)
select p_brand, p_type, p_size, count(distinct ps_suppkey) as supplier_cnt
from partsupp, part
where p_partkey = ps_partkey
and p_brand <> '&brand'
and ps_suppkey not in (
select s_suppkey
from supplier
where s_comment like '%Customer%Complaints%')
group by p_brand,
p_type,
p_size
order by supplier_cnt desc,
p_brand,
p_type,
p_size;
Se elijieron estas dos consultas. Q1 fue elegida dado que entre los cambios a la base de
datos se propuso que la tabla LINEITEM estuviera particionada por el atributo orderkey,
permitiendo de esta forma traer menos bloques a memoria cuando se consulte sobre esta tabla
por este atributo. Adems de que esta consulta realiza 2 subconsultas ms por este atributo en
dicha tabla. Por la misma razn se realiz una particin sobre ORDERS con respecto al atributo
orderkey. Se espera que estos cambios disminuyan considerablemente el nmero de accesos a
disco que hace la consulta puesto que ambas tablas son muy grandes.
Se tom la decisin de trabajar con Q2 dado que se cre un ndice bitmap sobre el atributo
Brand en la tabla PARTS, por lo que hacer el condicional del where donde se pide que sea distinto
de la marca suministrada por el usuario. Esto significara un scan completo, sin embargo con este
ndice se evitara realizar el scan completo mejorando as el tiempo de ejecucin de dicha
consulta.
Anlisis de Q1:
Al ejecutar la consulta sobre la base de datos original:
Execution Plan
---------------------------------------------------------Plan hash value: 2487387641
------------------------------------------------------------------------------------------------------
| Id | Operation
Cost (%CPU)| Time
| Name
------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT
5 | 1115 |
| 1 | SORT ORDER BY
5 | 1115 |
5 | 1115 |
| 2 | HASH GROUP BY
5 | 1115 |
| 4|
NESTED LOOPS
5 | 895 |
|* 5 |
| 11 | 1793 | 16M|
|* 6 |
HASH JOIN
| 113K| 14M|
| 356 | 33108 |
|* 7 |
HASH JOIN
59 (2)| 00:00:01 |
|* 8 |
| NATION
1 | 40 |
3 (0)| 00:00:01 |
| 9|
55 (0)| 00:00:01 |
|* 10 |
| 11 |
|* 12 |
1 | 16 |
1 (0)| 00:00:01 |
|* 13 |
| PK_ORDERS |
1|
0 (0)| 00:00:01 |
|* 14 |
2 (0)| 00:00:01 |
|* 15 |
| PK_LINEITEM | 20 |
1 (0)| 00:00:01 |
------------------------------------------------------------------------------------------------------
5 - access("L2"."L_ORDERKEY"="L1"."L_ORDERKEY")
filter("L2"."L_SUPPKEY"<>"L1"."L_SUPPKEY")
6 - access("S_SUPPKEY"="L1"."L_SUPPKEY")
7 - access("S_NATIONKEY"="N_NATIONKEY")
8 - filter("N_NAME"='BRAZIL')
10 - filter("L1"."L_RECEIPTDATE">"L1"."L_COMMITDATE")
12 - filter("O_ORDERSTATUS"='F')
13 - access("O_ORDERKEY"="L1"."L_ORDERKEY")
14 - filter("L3"."L_RECEIPTDATE">"L3"."L_COMMITDATE" AND "L3"."L_SUPPKEY"<>"L1
"."L_SUPPKEY")
15 - access("L3"."L_ORDERKEY"="L1"."L_ORDERKEY")
Note
----- dynamic sampling used for this statement
Statistics
---------------------------------------------------------110 recursive calls
3 db block gets
865510 consistent gets
207649 physical reads
788 redo size
13730 bytes sent via SQL*Net to client
422 bytes received via SQL*Net from client
28 SQL*Net roundtrips to/from client
7 sorts (memory)
0 sorts (disk)
----------------------------------------------------------------------------------------------------------------------
| Id | Operation
Cost (%CPU)| Time
| Name
| Rows | Bytes |
| Pstart| Pstop |
----------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT
24247 (2)| 00:04:51 |
|
|
1 | 223 |
1 | 223 |
| 2 | HASH GROUP BY
24247 (2)| 00:04:51 |
1 | 223 |
| 1 | SORT ORDER BY
24247 (2)| 00:04:51 |
| 4|
| 5|
|* 6 |
| 8|
|* 9 |
1 | 137 |
1 | 93 |
| SUPPLIER |
1 | 53 |
| NATION
1 | 40 |
1 | 153 |
0 (0)| 00:00:01 |
| 11 |
0 (0)| 00:00:01 |
|* 10 |
1 | 197 |
NESTED LOOPS
2 (0)| 00:00:01 |
HASH JOIN
2 (0)| 00:00:01 |
|
|
| 7|
1 | 223 |
NESTED LOOPS
| PK_NATION |
1|
| 3007K| 126M|
|* 12 |
1 | 12 |
|* 13 |
1 | 12 |
1 | 16 |
|* 14 |
0 (0)| 00:00:01 |
|* 15 |
| PK_ORDERS |
1|
|* 16 |
1 (0)| 00:00:01 |
|* 17 |
| PK_LINEITEM | 20 |
|* 18 |
1 (0)| 00:00:01 |
| PK_LINEITEM |
----------------------------------------------------------------------------------------------------------------------
1|
6 - access("S_SUPPKEY"="L1"."L_SUPPKEY")
9 - filter("N_NAME"='BRAZIL')
10 - access("S_NATIONKEY"="N_NATIONKEY")
12 - filter("L1"."L_RECEIPTDATE">"L1"."L_COMMITDATE")
13 - filter("O_ORDERSTATUS"='F')
14 - access("O_ORDERKEY"="L1"."L_ORDERKEY")
15 - filter("L3"."L_RECEIPTDATE">"L3"."L_COMMITDATE" AND "L3"."L_SUPPKEY"<>"L1
"."L_SUPPKEY")
16 - access("L3"."L_ORDERKEY"="L1"."L_ORDERKEY")
17 - filter("L2"."L_SUPPKEY"<>"L1"."L_SUPPKEY")
18 - access("L2"."L_ORDERKEY"="L1"."L_ORDERKEY")
Note
----- dynamic sampling used for this statement
Statistics
---------------------------------------------------------280 recursive calls
0 db block gets
------------------------------------------------------------------------------------------------------------------------
| Id | Operation
| Cost (%CPU)| Time
| Name
| Rows | Bytes
| Pstart| Pstop |
--------------------------------------------------------------------------------
-----------------------------------------
| 0 | SELECT STATEMENT
| 2650 (1)| 00:00:32 |
|
|
1 | 223
1 | 223
| 2 | HASH GROUP BY
| 2650 (1)| 00:00:32 |
| 4|
1 | 179
1 | 153
1 | 113
| 5925 | 347K
NESTED LOOPS
1 | 223
NESTED LOOPS
| 7|
NESTED LOOPS
| 6|
|
|
| 5|
1 | 223
| 1 | SORT ORDER BY
| 2650 (1)| 00:00:32 |
| 8|
| 2500 | 40000
|* 9 |
|
9 (0)| 00:00:01 |
|* 10 |
|
| SUPPLIER |
1 | 53
| PK_SUPPKEY |
1|
| NATION
1 | 40
4|
0 (0)| 00:00:01 |
|* 16 |
|
2 | 88
0 (0)| 00:00:01 |
|* 15 |
| PK_LINEITEM |
0 (0)| 00:00:01 |
|* 14 |
|
0 (0)| 00:00:01 |
|* 13 |
|
1 (0)| 00:00:01 |
| 12 |
|
| ORDERSTAT | 2500 |
|* 11 |
|
| PK_NATION |
1|
|* 17 |
|
1 (0)| 00:00:01 |
|* 18 |
|
| PK_LINEITEM |
1|
|* 19 |
|
1 (0)| 00:00:01 |
| PK_LINEITEM | 20 |
|
------------------------------------------------------------------------------------------------------------------------
9 - access("O_ORDERSTATUS"='F')
10 - filter("L1"."L_RECEIPTDATE">"L1"."L_COMMITDATE")
11 - access("O_ORDERKEY"="L1"."L_ORDERKEY")
13 - access("S_SUPPKEY"="L1"."L_SUPPKEY")
14 - filter("N_NAME"='BRAZIL')
15 - access("S_NATIONKEY"="N_NATIONKEY")
16 - filter("L2"."L_SUPPKEY"<>"L1"."L_SUPPKEY")
17 - access("L2"."L_ORDERKEY"="L1"."L_ORDERKEY")
18 - filter("L3"."L_RECEIPTDATE">"L3"."L_COMMITDATE" AND "L3"."L_SUPPKEY"<>"L1
"."L_SUPPKEY")
19 - access("L3"."L_ORDERKEY"="L1"."L_ORDERKEY")
Note
----- dynamic sampling used for this statement
Statistics
---------------------------------------------------------18 recursive calls
0 db block gets
8185038 consistent gets
151529 physical reads
0 redo size
13730 bytes sent via SQL*Net to client
422 bytes received via SQL*Net from client
28 SQL*Net roundtrips to/from client
5 sorts (memory)
0 sorts (disk)
397 rows processed
De aqu se puede ver como disminuye en casi 2000 accesos a disco, lo cual representa una
gran mejora para dicha consulta. Adems de que posee llamadas recursivas. Al comparar esta
ltima opcin contra el desempeo de la consulta de la base de datos sin modificar se puede
observar una disminucin de unos 56120 accesos a disco, por lo que el tiempo de respuesta es
mucho menor.
Anlisis de Q2:
Al ejecutar la consulta sobre la base de datos original nos da:
Execution Plan
---------------------------------------------------------Plan hash value: 548422033
---------------------------------------------------------------------------------------------------
| Id | Operation
t (%CPU)| Time
| Name
---------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT
| 827K| 112M|
| 39
27 (7)| 00:00:48 |
| 1 | SORT ORDER BY
| 827K| 112M|
| 39
| 827K| 112M|
| 39
27 (7)| 00:00:48 |
| 2 | SORT GROUP BY
27 (7)| 00:00:48 |
| 827K| 112M|
| 37
36 (2)| 00:00:45 |
|* 4 |
8 | 520 |
56 (2)| 00:00:01 |
|* 5 |
HASH JOIN
69 (2)| 00:00:45 |
|* 6 |
| 203K| 10M|
| 8
71 (2)| 00:00:11 |
| 7|
64 (1)| 00:00:08 |
---------------------------------------------------------------------------------------------------
3 - access("PS_SUPPKEY"="S_SUPPKEY")
4 - filter("S_COMMENT" LIKE '%Customer%Complaints%')
5 - access("P_PARTKEY"="PS_PARTKEY")
6 - filter("P_BRAND"<>'Brand#21')
| 6
Note
----- dynamic sampling used for this statement
Statistics
---------------------------------------------------------46 recursive calls
5 db block gets
7121 consistent gets
5855 physical reads
0 redo size
1666050 bytes sent via SQL*Net to client
55351 bytes received via SQL*Net from client
7875 SQL*Net roundtrips to/from client
1 sorts (memory)
1 sorts (disk)
118106 rows processed
Al ejecutar la consulta sobre la base de datos modificada nos da:
Execution Plan
------------------------------------------------------------------------------------------------------------------------------------| Id | Operation
| Name
| 1 | SORT ORDER BY
| 2 | SORT GROUP BY
| 4|
| 5|
HASH JOIN
| 6|
| 7|
| 500 | 34000 | 51 |
---------------------------------------------------------------------------Note
----- 'PLAN_TABLE' is old version
Statistics
---------------------------------------------------------47 recursive calls
5 db block gets
6140 consistent gets
5981 physical reads
0 redo size
1610924 bytes sent via SQL*Net to client
55351 bytes received via SQL*Net from client
7875 SQL*Net roundtrips to/from client
1 sorts (memory)
1 sorts (disk)
118106 rows processed
Por lo que podemos observar en el plan de ejecucin que no se utiliz el ndice que se cre sobre
la tabla PARTSUPPLIER. Durante esta ejecucin se realizan 47 llamadas recursivas, 5 bloques
obtenidos, 5981 lecturas fsicas y 6140 lecturas consistentes.
Sin embargo al utilizar el hint e indicarle a Oracle que utilice el ndice creado sobre la tabla
PARTSUPPLIER, se obtiene:
Execution Plan
----------------------------------------------------------
--------------------------------------------------------------------------------
| Id | Operation
| Name
--------------------------------------------------------------------------------
| 0 | SELECT STATEMENT
| 1 | SORT ORDER BY
| 2 | SORT GROUP BY
|
| 4|
| SUPPLIER
| 500 | 34000 | 51
| 5|
HASH JOIN
| 6|
| PART
| 7|
| 8|
| 9|
BITMAP MINUS
| 10 |
BITMAP MERGE
| 11 |
|
| 12 |
--------------------------------------------------------------------------------
Note
----- 'PLAN_TABLE' is old version
Statistics
---------------------------------------------------------46 recursive calls
5 db block gets
20609 consistent gets
5855 physical reads
0 redo size
1673924 bytes sent via SQL*Net to client
55351 bytes received via SQL*Net from client
7875 SQL*Net roundtrips to/from client
1 sorts (memory)
1 sorts (disk)
118106 rows processed
Por lo que se puede observar que con esta consulta utilizando el ndice creado el
desempeo de dicha consulta empeora notablemente, si nos fijamos en los costos se puede ver
como los costos en la consulta sin ndice daban al principio 3 operaciones con un costo de 19726
mientras que con el ndice da 3 operaciones con un costo de 58314, por lo que el costo de la
segunda forma es mucho mayor. Analizando ms a fondo las estadsticas se puede observar que
durante la consulta con el ndice se realizan las mismas llamadas recursivas y los mismos 5 accesos
a bloques, sin embargo 20610 lecturas consistentes pero 126 lecturas fsicas menos. Estos
nmeros son mucho mayores.
De esto podemos concluir que el ndice efectivamente disminuye la cantidad de accesos a
disco, eliminando 126 accesos. Sin embargo cuando se compara la consulta con el ndice y sin el
ndice resulta que el ndice seleccionado resulto ser un costo adicional que no beneficiaba el
desempeo de la consulta