Universidad Simn Bolvar

Arquitectura y Administracin de BD (CI-5313)

Septiembre Diciembre 2011
Prof: Marlene Goncalves

Fase II del Proyecto

Optimizacin de Consultas de FBV

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

order by numwait desc,

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

| Rows | Bytes |TempSpc|

------------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT

5 | 1115 |

59146 (2)| 00:11:50 |

| 1 | SORT ORDER BY

5 | 1115 |

5 | 1115 |

59146 (2)| 00:11:50 |

| 2 | HASH GROUP BY

59146 (2)| 00:11:50 |

| 3 | NESTED LOOPS ANTI

5 | 1115 |

59144 (2)| 00:11:50 |

| 4|

NESTED LOOPS

5 | 895 |

59134 (2)| 00:11:50 |

|* 5 |

HASH JOIN SEMI

| 11 | 1793 | 16M|

59123 (2)| 00:11:50 |

|* 6 |

HASH JOIN

| 113K| 14M|

| 356 | 33108 |

24389 (2)| 00:04:53 |

|* 7 |

HASH JOIN

59 (2)| 00:00:01 |

|* 8 |

TABLE ACCESS FULL

| NATION

1 | 40 |

3 (0)| 00:00:01 |

| 9|

TABLE ACCESS FULL

| SUPPLIER | 8904 | 460K|

55 (0)| 00:00:01 |

|* 10 |

TABLE ACCESS FULL

24286 (2)| 00:04:52 |

| LINEITEM | 3347K| 140M|

| 11 |

TABLE ACCESS FULL

| LINEITEM | 5383K| 133M|

24113 (1)| 00:04:50 |

|* 12 |

TABLE ACCESS BY INDEX ROWID| ORDERS

1 | 16 |

1 (0)| 00:00:01 |

|* 13 |

INDEX UNIQUE SCAN

| PK_ORDERS |

1|

0 (0)| 00:00:01 |

|* 14 |

TABLE ACCESS BY INDEX ROWID | LINEITEM | 318 | 13992 |

2 (0)| 00:00:01 |

|* 15 |

INDEX RANGE SCAN

| PK_LINEITEM | 20 |

1 (0)| 00:00:01 |

------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

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)

397 rows processed

Esta consulta necesita 207649 accesos a disco para buscar bloques, tiene 865510 lecturas
consistentes y posee 110 llamadas recursivas. Estas estadsticas hacen que esta consulta sea
sumamente lenta, y se espera que con las estructuras propuestas se logre mejorar el desempeo
de dicha consulta
Al ejecutar la consulta con las estructuras propuestas:
Execution Plan
---------------------------------------------------------Plan hash value: 4143046826

----------------------------------------------------------------------------------------------------------------------

| 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 |

| 3 | NESTED LOOPS SEMI

24245 (2)| 00:04:51 |

| 4|

| 5|

|* 6 |

| 8|

|* 9 |

1 | 137 |

1 | 93 |

| SUPPLIER |

1 | 53 |

| NATION

1 | 40 |

INDEX UNIQUE SCAN

|

1 | 153 |

TABLE ACCESS BY INDEX ROWID

0 (0)| 00:00:01 |

| 11 |

TABLE ACCESS FULL

0 (0)| 00:00:01 |

|* 10 |

1 | 197 |

NESTED LOOPS

2 (0)| 00:00:01 |

HASH JOIN

2 (0)| 00:00:01 |

|
|

24240 (2)| 00:04:51 |

| 7|

1 | 223 |

NESTED LOOPS

24241 (2)| 00:04:51 |

NESTED LOOPS ANTI

24243 (2)| 00:04:51 |

| PK_NATION |

1|

PARTITION RANGE ALL

| 3007K| 126M|

24199 (2)| 00:04:51 |

|* 12 |

1 | 12 |

TABLE ACCESS FULL

24199 (2)| 00:04:51 |

|* 13 |

| LINEITEM | 3007K| 126M|

1 | 12 |

TABLE ACCESS BY GLOBAL INDEX ROWID| ORDERS

1 | 16 |

1 (0)| 00:00:01 | ROWID | ROWID |

|* 14 |

INDEX UNIQUE SCAN

0 (0)| 00:00:01 |

|* 15 |

| PK_ORDERS |

1|

TABLE ACCESS BY GLOBAL INDEX ROWID | LINEITEM | 298 | 13112 |

2 (0)| 00:00:01 | ROWID | ROWID |

|* 16 |

INDEX RANGE SCAN

1 (0)| 00:00:01 |

|* 17 |

| PK_LINEITEM | 20 |

TABLE ACCESS BY GLOBAL INDEX ROWID | LINEITEM | 471 | 12246 |

2 (0)| 00:00:01 | ROWID | ROWID |

|* 18 |

INDEX RANGE SCAN

1 (0)| 00:00:01 |

| PK_LINEITEM |

----------------------------------------------------------------------------------------------------------------------

1|

Predicate Information (identified by operation id):

---------------------------------------------------

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

811574 consistent gets

153200 physical reads
0 redo size
13926 bytes sent via SQL*Net to client
422 bytes received via SQL*Net from client
28 SQL*Net roundtrips to/from client
12 sorts (memory)
0 sorts (disk)
397 rows processed
Esta consulta no posee llamadas recursivas, ni tampoco operaciones sobre la memoria
cach, sin embargo posee 810863 lecturas consistentes y 125535 lecturas fsicas.
Sin embargo, nos dimos cuenta que creando un nuevo ndice mejorara un poco la
eficiencia de esta consulta:
CREATE INDEX ORDERSTAT on ORDERS(O_ORDERSTATUS);
Y los resultados obtenidos son:
Execution Plan
---------------------------------------------------------Plan hash value: 344326148

------------------------------------------------------------------------------------------------------------------------

| 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 |

| 3 | NESTED LOOPS ANTI

| 2648 (1)| 00:00:32 |

| 4|

1 | 179

1 | 153

1 | 113

| 5925 | 347K

NESTED LOOPS

| 2643 (1)| 00:00:32 |

1 | 223

NESTED LOOPS

| 2644 (1)| 00:00:32 |

| 7|

NESTED LOOPS

| 2644 (1)| 00:00:32 |

| 6|

|
|

NESTED LOOPS SEMI

| 2646 (1)| 00:00:32 |

| 5|

1 | 223

| 1 | SORT ORDER BY
| 2650 (1)| 00:00:32 |

| 8|

TABLE ACCESS BY GLOBAL INDEX ROWID| ORDERS

| 2500 | 40000

| 139 (0)| 00:00:02 | ROWID | ROWID |

|* 9 |
|

9 (0)| 00:00:01 |

|* 10 |
|

| SUPPLIER |

1 | 53

| PK_SUPPKEY |

1|

| NATION

1 | 40

INDEX UNIQUE SCAN

|

4|

TABLE ACCESS BY INDEX ROWID

0 (0)| 00:00:01 |

|* 16 |
|

2 | 88

INDEX UNIQUE SCAN

0 (0)| 00:00:01 |

|* 15 |

| PK_LINEITEM |

TABLE ACCESS BY INDEX ROWID

0 (0)| 00:00:01 |

|* 14 |
|

INDEX RANGE SCAN

0 (0)| 00:00:01 |

|* 13 |
|

TABLE ACCESS BY GLOBAL INDEX ROWID| LINEITEM |

1 (0)| 00:00:01 |

| 12 |
|

| ORDERSTAT | 2500 |

2 (0)| 00:00:01 | ROWID | ROWID |

|* 11 |
|

INDEX RANGE SCAN

| PK_NATION |

1|

TABLE ACCESS BY GLOBAL INDEX ROWID | LINEITEM | 471 | 12246

2 (0)| 00:00:01 | ROWID | ROWID |

|* 17 |
|

1 (0)| 00:00:01 |

|* 18 |
|

| PK_LINEITEM |

1|

TABLE ACCESS BY GLOBAL INDEX ROWID | LINEITEM | 298 | 13112

2 (0)| 00:00:01 | ROWID | ROWID |

|* 19 |
|

INDEX RANGE SCAN

INDEX RANGE SCAN

1 (0)| 00:00:01 |

| PK_LINEITEM | 20 |
|

------------------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

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

| Rows | Bytes |TempSpc| Cos

---------------------------------------------------------------------------------------------------

| 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 |

|* 3 | HASH JOIN RIGHT ANTI |

| 827K| 112M|

| 37

36 (2)| 00:00:45 |

|* 4 |

TABLE ACCESS FULL | SUPPLIER

8 | 520 |

56 (2)| 00:00:01 |

|* 5 |

HASH JOIN

| 828K| 61M| 12M| 36

69 (2)| 00:00:45 |

|* 6 |

TABLE ACCESS FULL | PART

| 203K| 10M|

| 8

71 (2)| 00:00:11 |

| 7|

INDEX FAST FULL SCAN| PK_PARTSUPPLIER | 828K| 20M|

64 (1)| 00:00:08 |

---------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

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

| Rows | Bytes | Cost |

---------------------------------------------------------------------------| 0 | SELECT STATEMENT

| 94375 | 10M| 19726 |

| 1 | SORT ORDER BY

| 94375 | 10M| 19726 |

| 2 | SORT GROUP BY

| 94375 | 10M| 19726 |

| 3 | HASH JOIN RIGHT ANTI |

| 730K| 82M| 2705 |

| 4|

TABLE ACCESS FULL | SUPPLIER

| 5|

HASH JOIN

| 6|

TABLE ACCESS FULL | PART

| 7|

INDEX FAST FULL SCAN| PK_PARTSUPPLIER | 800K| 7031K| 477 |

| 500 | 34000 | 51 |

| 769K| 36M| 2644 |

| 192K| 7699K| 863 |

---------------------------------------------------------------------------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

| Rows | Bytes | Cost

--------------------------------------------------------------------------------

| 0 | SELECT STATEMENT

| 94375 | 10M| 58314

| 1 | SORT ORDER BY

| 94375 | 10M| 58314

| 94375 | 10M| 58314

| 2 | SORT GROUP BY
|

| 3 | HASH JOIN RIGHT ANTI

| 730K| 82M| 41294

| 4|

TABLE ACCESS FULL

| SUPPLIER

| 500 | 34000 | 51

| 5|

HASH JOIN

| 769K| 36M| 41233

| 6|

TABLE ACCESS FULL

| PART

| 192K| 7699K| 863

| 7|

TABLE ACCESS BY INDEX ROWID | PARTSUPPLIER | 800K| 7031K| 39066

| 8|

BITMAP CONVERSION TO ROWIDS|

| 9|

BITMAP MINUS

| 10 |

BITMAP MERGE

| 11 |
|

BITMAP INDEX FULL SCAN | P_BRAND_BJIX |

| 12 |

BITMAP INDEX SINGLE VALUE| P_BRAND_BJIX |

--------------------------------------------------------------------------------

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