Archives August 2021

INDEX SCAN TYPES ORACLE

Access path in oracle is basically retrieving rows from row source be it table, index or any other objects etc..

Types of access paths:

  • Full table scan
  • Table access by rowid
  • Index unique scan
  • Index range scan
  • Index full scan
  • Index fast full scan
  • Index skip scan
  • Bitmap index single value
  • Bitmap index range scan
  • Index join scan
  • Sample table scan
  • Bitmap merge
  • Cluster scan
  • Hash scan

Confusions: Often there is a confusion between index full scan and index fast full scan

Index unique scan:

An index unique scan is used from the predicate whenever an indexed column contains unique key or primary key constraint.

This type of scan return always one unique row . The scan starts from root block to leaf block with a rowid and that rowid is used to retrieve datablock from the datafile.

No. of block accesses = Height of index + 1

Exception for above formula is row chaining blocks and LOB tables

In below plan, there are two steps

  • Index unique scan – Index leaf block touch(single index block read with rowid)
  • Table access by index rowid – datablock touch from datafile with the help of previous index rowid
SQL> set autot traceonly explain
SQL> select DEPARTMENT_NAME from DEPARTMENTS where DEPARTMENT_ID=270;

Execution Plan
----------------------------------------------------------
Plan hash value: 4024094692

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

| Id  | Operation                   | Name        | Rows  | Bytes | Cost (%CPU)|
 Time     |

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

|   0 | SELECT STATEMENT            |             |     1 |    16 |     1   (0)|
 00:00:01 |

|   1 |  TABLE ACCESS BY INDEX ROWID| DEPARTMENTS |     1 |    16 |     1   (0)|
 00:00:01 |

|*  2 |   INDEX UNIQUE SCAN         | DEPT_ID_PK  |     1 |       |     0   (0)|
 00:00:01 |

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

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("DEPARTMENT_ID"=270)

Index range scan:

Index range scan is basically slicing the index based on a range based value specified on the predicate. The index can be unique or non unique and single or multiple rows are returned based on the predicate condition .If the range is large, then index full scan operation will be attracted rather than range scan.

Index is traversed from root block to leaf block matching a predicate condition. Here if you see there are two steps

  • Table access by index rowid batched
  • Index range scan

Here we can calculate the block accesses using this formula

No. of block accesses = (Returned rows which match the condition * 2 ) + blevel

Example: If there are 3 rows returned for a query, then server process retrieve the index leaf blocks from root blocks based on predicate condition,fetch the rowids consecutively back & forth and read the datablocks from the datafile. So data blocks are accessed twice both from index rowid and datablocks provided the range entries are not large.

If the range of entries are large for an index , then more than one leaf block should be scanned with the pointer. Index range scan will not occur when ‘like’ operator is used like ‘%xyz’ which scans the index in broader range from upper to lower boundary.

Conditions used – >,<,LIKE,BETWEEN , = and non unique index

SQL> select * from DEPARTMENTS where LOCATION_ID=10;

Execution Plan
----------------------------------------------------------
Plan hash value: 2156672468

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

| Id  | Operation                           | Name             | Rows  | Bytes |
 Cost (%CPU)| Time     |

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

|   0 | SELECT STATEMENT                    |                  |     1 |    21 |
     2   (0)| 00:00:01 |

|   1 |  TABLE ACCESS BY INDEX ROWID BATCHED| DEPARTMENTS      |     1 |    21 |
     2   (0)| 00:00:01 |

|*  2 |   INDEX RANGE SCAN                  | DEPT_LOCATION_IX |     1 |       |
     1   (0)| 00:00:01 |

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

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("LOCATION_ID"=10)

In index range scan, if we can also use order by clause to sort the data using index rowid in ascending (default) order without extra processing for sort. The index entrires can also be used to sort the data in the descending order. We can also see an inlist iterator step in the plan which occur due to ‘in’ clause.

kish@exdbx<>set autot traceonly explain
kish@exdbx<>select * from tabx
  2  where order_id in (33,36,39)
  3  order by order_id;
Elapsed: 00:00:00.86

Execution Plan
----------------------------------------------------------
Plan hash value: 3742152234

------------------------------------------------------------------------
| Id  | Operation                    | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |        |     3 |   228 |     6   (0)| 00:00:01 |
|   1 |  INLIST ITERATOR             |        |       |       |            |          |
|   2 |   TABLE ACCESS BY INDEX ROWID| TABX   |     3 |   228 |     6   (0)| 00:00:01 |
|*  3 |    INDEX RANGE SCAN          | IDX_ID |     3 |       |     5   (0)| 00:00:01 |
------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   3 - access("ORDER_ID"=33 OR "ORDER_ID"=36 OR "ORDER_ID"=39)

========================================================================
kish@exdbx<>select * from tabx
  2  where order_id in (33,36,39)
  3  order by order_id desc;
Elapsed: 00:00:00.01

Execution Plan
----------------------------------------------------------
Plan hash value: 1806198194

------------------------------------------------------------------------
| Id  | Operation                     | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------
|   0 | SELECT STATEMENT              |        |     3 |   228 |     6   (0)| 00:00:01 |
|   1 |  INLIST ITERATOR              |        |       |       |            |          |
|   2 |   TABLE ACCESS BY INDEX ROWID | TABX   |     3 |   228 |     6   (0)| 00:00:01 |
|*  3 |    INDEX RANGE SCAN DESCENDING| IDX_ID |     3 |       |     5   (0)| 00:00:01 |
------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   3 - access("ORDER_ID"=33 OR "ORDER_ID"=36 OR "ORDER_ID"=39)

Index full scan:

If the rows are scanned in the index leaf blocks in an order and eliminate the need for sorting,then this scan takes place. Access of all index blocks will be more efficient than accessing all table blocks.This scan uses single block read to fetch the rows. Prevents sorting operations.If there is no not null constraint, then index full scan cannot be chosen.It occur when all columns used in query are indexed and atleast one column in index has NOT NULL constraints.

  • This may also happen when there is no predicate in the query and indexed column is used after select
  • the predicate contains a condition on a non leading column in an index
  • An order by clause used on non-nullable indexed columns

Index full scan = (Predicate contain atleast one not null constraint column + Other indexed columns)

SQL> select DEPARTMENT_ID from DEPARTMENTS;

Execution Plan
----------------------------------------------------------
Plan hash value: 3963224445

------------------------------------------------------------------------
| Id  | Operation        | Name       | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------
|   0 | SELECT STATEMENT |            |    27 |   108 |     1   (0)| 00:00:01 |
|   1 |  INDEX FULL SCAN | DEPT_ID_PK |    27 |   108 |     1   (0)| 00:00:01 |
------------------------------------------------------------------------
========================================================================
SQL> alter table employees modify (email null);

Table altered.

SQL> select email from employees;

Execution Plan
----------------------------------------------------------
Plan hash value: 1445457117
------------------------------------------------------------------------
| Id  | Operation         | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |           |   107 |   856 |     3   (0)| 00:00:01 |
|   1 |  TABLE ACCESS FULL| EMPLOYEES |   107 |   856 |     3   (0)| 00:00:01 |
------------------------------------------------------------------------

SQL> alter table employees modify (email not null);

Table altered.

SQL> select email from employees;

Execution Plan
----------------------------------------------------------
Plan hash value: 2196514524

------------------------------------------------------------------------
| Id  | Operation        | Name         | Rows  | Bytes | Cost (%CPU)| Time
|
------------------------------------------------------------------------
|   0 | SELECT STATEMENT |              |   107 |   856 |     1   (0)| 00:00:01
|

|   1 |  INDEX FULL SCAN | EMP_EMAIL_UK |   107 |   856 |     1   (0)| 00:00:01
|
------------------------------------------------------------------------

Index full scan(min/max):

If we want to retrieve either min or max value from an index, then the column which is indexed is used with a index full scan.

SQL> select min(department_id) from DEPARTMENTS;

Execution Plan
----------------------------------------------------------
Plan hash value: 2336069222
------------------------------------------------------------------------
| Id  | Operation                  | Name       | Rows  | Bytes | Cost (%CPU)| T
ime     |
------------------------------------------------------------------------
|   0 | SELECT STATEMENT           |            |     1 |     4 |     1   (0)| 0
0:00:01 |

|   1 |  SORT AGGREGATE            |            |     1 |     4 |            |
        |

|   2 |   INDEX FULL SCAN (MIN/MAX)| DEPT_ID_PK |     1 |     4 |     1   (0)| 0
0:00:01 |
-----------------------------------------------------------------------

Below is an example for index full scan descending in a sorted order

SQL> select * from DEPARTMENTS order by DEPARTMENT_ID desc;

Execution Plan
----------------------------------------------------------
Plan hash value: 2565564082
------------------------------------------------------------------------
| Id  | Operation                   | Name        | Rows  | Bytes | Cost (%CPU)|
 Time     |
------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |             |    27 |   567 |     2   (0)|
 00:00:01 |

|   1 |  TABLE ACCESS BY INDEX ROWID| DEPARTMENTS |    27 |   567 |     2   (0)|
 00:00:01 |

|   2 |   INDEX FULL SCAN DESCENDING| DEPT_ID_PK  |    27 |       |     1   (0)|
 00:00:01 |
------------------------------------------------------------------------

Index skip scan:

An index skip scan is used when a predicate contains a non leading column and leading column has high cardinality. This scan works by splitting multiple column index into smaller subindexes. A number of logical subindexes determined by number of distinct values in leading columns of index. If leading column has more distinct values , then more logical subindexes should be created. If the number of subindexes required is less, then index skip scan would be more efficient than full scan (scanning index block is more efficient than scanning table blocks). But if the number of subindexes required is larger, then full scan is efficient than index scan.

Index skip scan = (distinct leading column + predicate with non leading column)

SQL> create index emp_idx on employees(EMPLOYEE_ID,FIRST_NAME,SALARY);

Index created.

SQL> select * from employees where FIRST_NAME='William';

Execution Plan
----------------------------------------------------------
Plan hash value: 3789230693

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

| Id  | Operation                           | Name      | Rows  | Bytes | Cost (
%CPU)| Time     |
------------------------------------------------------------------------

|   0 | SELECT STATEMENT                    |           |     1 |    72 |     2
  (0)| 00:00:01 |

|   1 |  TABLE ACCESS BY INDEX ROWID BATCHED| EMPLOYEES |     1 |    72 |     2
  (0)| 00:00:01 |

|*  2 |   INDEX SKIP SCAN                   | EMP_IDX   |     1 |       |     1
  (0)| 00:00:01 |
------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   2 - access("FIRST_NAME"='William')
       filter("FIRST_NAME"='William')

Index fast full scan:

This is also similar to full table scan which uses multiblock reads. The data is accessed from the index itself rather than table blocks because optimizer thinks that index size is smaller than table size and all the rows are contained in index itself. Root and branch blocks are not read but leaf blocks are read directly.This scan cant be used to avoid a sort because the blocks are read using unordered multiblock reads. This operation doesnot require not-null constraint or indexed column like a index full scan. Count of records triggers index fast full scan.

Index fast full scan = (count of total records)

SQL> set autot traceonly explain
SQL> select /*+ Index_ffs(employees) */ FIRST_NAME,LAST_NAME from test.employees;

Execution Plan
----------------------------------------------------------
Plan hash value: 1847877723

------------------------------------------------------------------------------------
| Id  | Operation            | Name        | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT     |             |   107 |  1605 |     2   (0)| 00:00:01 |
|   1 |  INDEX FAST FULL SCAN| EMP_NAME_IX |   107 |  1605 |     2   (0)| 00:00:01 |
------------------------------------------------------------------------------------

Situations when optimizer skips index scan:

  • No index created on the columns
  • Index is present but cannot be utilized due to 1)Functions applied on the column 2)IS NULL operator is used when an indexed column contains null value
  • low selectivity
  • Table size is assumed as small but its really big due to missing statistics

QUERY TRANSFORMER IN SQL EXECUTION ORACLE

During execution of an SQL statement in oracle database by a client or user, query has to go into certain phases.

  • SYNTAX CHECK
  • SEMANTIC CHECK
  • SHARED POOL CHECK

Above three steps altogether considered as parsing

After these checks we directly go to optimizers execution plan to access the blocks from the database. This phase is called as optimization.

But before that, we have a phase called query transformation

The sql execution goes into query transformation phase with a set of query blocks which is defined implicitly by SELECT

Each query block is either nested within another or interrelated

Query transformer determines the optimal query transformation to generate a better execution plan by rewrite of query before optimizer generate the plan

Post all these steps , we have row source generation phase called generation of query plan.

In this article , we take a peek on query transformer

Example:

Single query block:

select * from afterdrop where cid='6697053';

Dual query block:

select * from afterdrop where cid in (select cid from afterdrop);

The dual query block can be rewritten in way by using sub plan separately for the sub query or considering a rewrite for join for the inner query. But the result set is same.

Types of query transformation:

  • View merging
  • Subquery unnesting
  • Predicate pushing
  • MV query rewrite

Let us see the query transformation techniques a bit more in detail!

View merging:

Basically, view merging is merging views with the main query block with single execution. A view can also be executed with a sub plan from the main query plan. View merging is method of query transformation which transforms a view either in line or stored views that can be analyzed into separate query blocks or as a single execution

The SQL query can be rewritten without the view. Below are the scenarios when view merging occur,

  • column used in index within another query block
  • column used for partition pruning within another query block
  • condition that limit the rows returned from tables in joined view

Below are the scenarios when view merging less likely to occur,

  • ORDER BY
  • ROWNUM
  • UNION,INTERSECT,MINUS

In the below example query, view merge take place by not considering the view STB1 as a view itself with sub plan.

If you see the second step, the view is directly used as a sub plan with a child step ‘ VIEW PUSHED PREDICATE ‘. Here the view is correlated and is evaluated for each row of outer query block

1) WITH VIEW MERGING:

kish@exdbx<>select * from sales_tab stb,
(select order_id from STB1) st
where stb.order_id = st.order_id(+)
and
stb.TOTAL_PROFIT > 3000;
  2    3    4    5  Elapsed: 00:00:00.01

Execution Plan
----------------------------------------------------------
Plan hash value: 920325918

------------------------------------------------------------------------------------------
| Id  | Operation                    | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |           |     1 |    69 |  3272   (1)| 00:00:40 |
|*  1 |  HASH JOIN OUTER             |           |     1 |    69 |  3272   (1)| 00:00:40 |
|   2 |   TABLE ACCESS BY INDEX ROWID| SALES_TAB |     1 |    63 |     0   (0)| 00:00:01 |
|*  3 |    INDEX RANGE SCAN          | TP_STB1   |     1 |       |     0   (0)| 00:00:01 |
|   4 |   TABLE ACCESS STORAGE FULL  | SALES_T   |  1048K|  6144K|  3269   (1)| 00:00:40 |
------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - access("STB"."ORDER_ID"="ORDER_ID"(+))
   3 - access("STB"."TOTAL_PROFIT">3000)

========================================================================================================
2) WITHOUT VIEW MERGING:

kish@exdbx<>select * from sales_tab stb,
(select /*+NO_MERGE*/ order_id from STB1) st
where stb.order_id = st.order_id(+)
and
stb.TOTAL_PROFIT > 3000;  2    3    4    5
Elapsed: 00:00:00.01

Execution Plan
----------------------------------------------------------
Plan hash value: 3052241770

------------------------------------------------------------------------------------------
| Id  | Operation                    | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |           |     1 |    76 |  3271   (1)| 00:00:40 |
|   1 |  NESTED LOOPS OUTER          |           |     1 |    76 |  3271   (1)| 00:00:40 |
|   2 |   TABLE ACCESS BY INDEX ROWID| SALES_TAB |     1 |    63 |     0   (0)| 00:00:01 |
|*  3 |    INDEX RANGE SCAN          | TP_STB1   |     1 |       |     0   (0)| 00:00:01 |
|   4 |   VIEW PUSHED PREDICATE      |           |     1 |    13 |  3271   (1)| 00:00:40 |
|*  5 |    TABLE ACCESS STORAGE FULL | SALES_T   |     1 |     6 |  3271   (1)| 00:00:40 |
------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   3 - access("STB"."TOTAL_PROFIT">3000)
   5 - filter("ORDER_ID"="STB"."ORDER_ID")

These are the hidden parameters which influence view merging. Complex view merging is enabled to TRUE by default

kish@exdbx<>select KSPPINM from x$ksppi where KSPPINM like '%merging%';

KSPPINM
--------------------------------------------------------------------------------
_complex_view_merging
_simple_view_merging
optimizer_secure_view_merging

Subquery unnesting:

Subquery unnesting is the method to convert a subquery into a join. The query transformer looks for ways to convert a subquery to join which is faster than the sub plan. Below is a simple example.

Here, the first step shows a single plan step for the both outer query and sub query with subquery unnesting in place.

Second step shows the query without unnesting the inner query which has a sub plan in it and uses a filter operation which is not efficient while joining tables. Why this happen because, the optimizer scans SALES_TAB table 1048k times up and down which is less better than table joins

1) USING UNNESTING:

kish@exdbx<>set autot traceonly explain
kish@exdbx<>select * from sales_t where order_id in (select order_id from SALES_TAB);
Elapsed: 00:00:00.09
Execution Plan
----------------------------------------------------------
Plan hash value: 522758219

------------------------------------------------------------------------------------------------
| Id  | Operation                  | Name      | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT           |           |  1048K|    81M|       | 12117   (1)| 00:02:26 |
|*  1 |  HASH JOIN RIGHT SEMI      |           |  1048K|    81M|    17M| 12117   (1)| 00:02:26 |
|*  2 |   TABLE ACCESS STORAGE FULL| SALES_TAB |  1048K|  5120K|       |  3629   (1)| 00:00:44 |
|   3 |   TABLE ACCESS STORAGE FULL| SALES_T   |  1048K|    76M|       |  3274   (1)| 00:00:40 |
------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - access("ORDER_ID"="ORDER_ID")
   2 - storage("ORDER_ID" IS NOT NULL)
       filter("ORDER_ID" IS NOT NULL)

======================================================================================================
2) USING NO_UNNESTING:

kish@exdbx<>set autot traceonly explain
kish@exdbx<>select order_id,order_priority from sales_t where order_id in (select /*+NO_UNNEST*/ order_id from SALES_TAB where order_id > 369);
Elapsed: 00:00:00.01
Execution Plan
----------------------------------------------------------
Plan hash value: 3081409736

----------------------------------------------------------------------------------------------------
| Id  | Operation                              | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                       |           |     1 |     8 |  3772M  (1)|999:59:59 |
|*  1 |  FILTER                                |           |       |       |            |          |
|   2 |   TABLE ACCESS STORAGE FULL            | SALES_T   |  1048K|  8192K|  3270   (1)| 00:00:40 |
|*  3 |   FILTER                               |           |       |       |            |          |
|*  4 |    TABLE ACCESS STORAGE FULL FIRST ROWS| SALES_TAB |     1 |     5 |  3630   (1)| 00:00:44 |
----------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter( EXISTS (SELECT /*+ NO_UNNEST */ 0 FROM "SALES_TAB" "SALES_TAB" WHERE 369<:B1
              AND "ORDER_ID"=:B2 AND "ORDER_ID">369))
   3 - filter(369<:B1)
   4 - filter("ORDER_ID"=:B1 AND "ORDER_ID">369)

Subquery unnesting is also a faster way to execute a subquery by removing unnecessary processing of sub plan in the query.

Things which restrict subquery unnesting

  • Disjunctive linking
  • Disjunctive correlation
  • ROWNUM(where rownum > 1)
  • CONNECT BY in subquery
  • Nested aggregate functions like MAX(COUNT(*))
  • set operator in subquery(UNION,, UNION ALL)
  • Correlated subquery block reference not in the outer query

Below is another example for subquery unnesting with correlated subquery. Here the subquery is unnested in the form of an inline view, merged with the outer query and joined atlast. The column TOTAL_PROFIT becomes the join condition and rest of the plan is spent on inline view itself.

1) SUBQUERY UNNESTING WITH CORRELATED SUBQUERY
kish@exdbx<>select x.order_id,x.order_priority,x.TOTAL_PROFIT
  2  from
  3  sales_t x
  4  where x.TOTAL_PROFIT >
  5  (select avg(y.TOTAL_PROFIT)
  6  from SALES_TAB y
  7  where y.order_id=x.order_id);
Elapsed: 00:00:00.05

Execution Plan
----------------------------------------------------------
Plan hash value: 2553163008

---------------------------------------------------------------------------------------------------
| Id  | Operation                     | Name      | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT              |           | 39322 |  1804K|       | 10292   (1)| 00:02:04 |
|   1 |  NESTED LOOPS                 |           | 39322 |  1804K|       | 10292   (1)| 00:02:04 |
|   2 |   NESTED LOOPS                |           |  1043K|  1804K|       | 10292   (1)| 00:02:04 |
|   3 |    VIEW                       | VW_SQ_1   |  1043K|    25M|       | 10286   (1)| 00:02:04 |
|   4 |     HASH GROUP BY             |           |  1043K|    17M|    37M| 10286   (1)| 00:02:04 |
|   5 |      TABLE ACCESS STORAGE FULL| SALES_TAB |  1398K|    24M|       |  3633   (1)| 00:00:44 |
|*  6 |    INDEX RANGE SCAN           | TP_STB    |     1 |       |       |     0   (0)| 00:00:01 |
|*  7 |   TABLE ACCESS BY INDEX ROWID | SALES_T   |     1 |    21 |       |     0   (0)| 00:00:01 |
---------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   6 - access("X"."TOTAL_PROFIT">"AVG(Y.TOTAL_PROFIT)")
   7 - filter("ITEM_1"="X"."ORDER_ID")

==========================================================================================================
2) REWRITTEN QUERY TO PREVIOUS QUERY
kish@exdbx<>select x.order_id,x.order_priority,x.TOTAL_PROFIT
from
sales_t x,
(select order_id,avg(TOTAL_PROFIT)
from SALES_TAB y group by order_id) y
where x.order_id=y.order_id;  2    3    4    5    6
Elapsed: 00:00:00.01

Execution Plan
----------------------------------------------------------
Plan hash value: 2094056384

--------------------------------------------------------------------------------------------------
| Id  | Operation                    | Name      | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |           |   786K|    25M|       | 16438   (1)| 00:03:18 |
|*  1 |  HASH JOIN                   |           |   786K|    25M|    24M| 16438   (1)| 00:03:18 |
|   2 |   VIEW                       |           |  1043K|    12M|       | 10286   (1)| 00:02:04 |
|   3 |    HASH GROUP BY             |           |  1043K|    17M|    37M| 10286   (1)| 00:02:04 |
|   4 |     TABLE ACCESS STORAGE FULL| SALES_TAB |  1398K|    24M|       |  3633   (1)| 00:00:44 |
|   5 |   TABLE ACCESS STORAGE FULL  | SALES_T   |  1048K|    21M|       |  3273   (1)| 00:00:40 |
--------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - access("X"."ORDER_ID"="Y"."ORDER_ID")

Hidden parameters which influence the subquery unnesting are below. ‘ _unnest_subquery ‘ is the parameter which is enabled by default which directly controls correlated subquery

kish@exdbx<>select KSPPINM from x$ksppi where KSPPINM like '%unnest%';

KSPPINM
--------------------------------------------------------------------------------
_unnest_subquery
_optimizer_unnest_all_subqueries
_distinct_view_unnesting
_optimizer_unnest_disjunctive_subq
_optimizer_unnest_corr_set_subq

Disjunctive linking:

kish@exdbx<>set autot traceonly explain
kish@exdbx<>select * from sales_t
  2  where ORDER_PRIORITY in (select order_id from SALES_TAB)
  3  or
  4  order_id=369;
Elapsed: 00:00:00.00

Execution Plan
----------------------------------------------------------
Plan hash value: 3247245147

---------------------------------------------------------------------------------------------------
| Id  | Operation                             | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                      |           | 52430 |  3891K|  3276   (1)| 00:00:40 |
|*  1 |  FILTER                               |           |       |       |            |          |
|   2 |   TABLE ACCESS STORAGE FULL           | SALES_T   |  1048K|    76M|  3276   (1)| 00:00:40 |
|*  3 |   TABLE ACCESS STORAGE FULL FIRST ROWS| SALES_TAB |     1 |     5 |  3634   (1)| 00:00:44 |
---------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter("ORDER_ID"=369 OR  EXISTS (SELECT 0 FROM "SALES_TAB" "SALES_TAB" WHERE
              "ORDER_ID"=TO_NUMBER(:B1)))
   3 - filter("ORDER_ID"=TO_NUMBER(:B1))

Predicate pushing:

I would call Filter early faster execution(FEFE) for a good performance of SQL.

This method pushes the predicates first from an outer query before retrieving all rows in inner query block so that the predicates result sets can be calculated first to determine the filter before inner query execution.

Here optimizer may or may not use an index to filter the data.

Things which prevent predicate pushing

Example: If we want to travel to paris , then we need to know the direction or shortest way to it. Without having a basic idea on where we are heading to and the cost estimate to travel , we will spend more money if we go around the place.

Similarly predicate pushing pushes the calculation of predicates before processing sub query to spend less processing with less time.

QUERY WITH PREDICATE PUSHING 
 
kish@exdbx<>select x.order_id,x.order_priority,x.TOTAL_PROFIT
from
sales_t x,
(select order_id,avg(TOTAL_PROFIT) avg_pft
from SALES_TAB y group by order_id) y
where x.order_id=y.order_id
and x.TOTAL_PROFIT > y.avg_pft
and x.order_id=369;  2    3    4    5    6    7    8
Elapsed: 00:00:00.01

Execution Plan
----------------------------------------------------------
Plan hash value: 3354926154

-------------------------------------------------------------------------------------------
| Id  | Operation                     | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT              |           |     1 |    36 |  3631   (1)| 00:00:44 |
|   1 |  MERGE JOIN                   |           |     1 |    36 |  3631   (1)| 00:00:44 |
|   2 |   SORT JOIN                   |           |     1 |    21 |     0   (0)| 00:00:01 |
|*  3 |    TABLE ACCESS BY INDEX ROWID| SALES_T   |     1 |    21 |     0   (0)| 00:00:01 |
|   4 |     INDEX FULL SCAN           | TP_STB    |     1 |       |     0   (0)| 00:00:01 |
|*  5 |   SORT JOIN                   |           |     1 |    15 |  3631   (1)| 00:00:44 |
|   6 |    VIEW                       |           |     1 |    15 |  3630   (1)| 00:00:44 |
|   7 |     HASH GROUP BY             |           |     1 |    18 |  3630   (1)| 00:00:44 |
|*  8 |      TABLE ACCESS STORAGE FULL| SALES_TAB |     1 |    18 |  3630   (1)| 00:00:44 |
-------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   3 - filter("X"."ORDER_ID"=369)
   5 - access(INTERNAL_FUNCTION("X"."TOTAL_PROFIT")>INTERNAL_FUNCTION("Y"."AVG_PFT"
              ))
       filter(INTERNAL_FUNCTION("X"."TOTAL_PROFIT")>INTERNAL_FUNCTION("Y"."AVG_PFT"
              ))
   8 - storage("ORDER_ID"=369)
       filter("ORDER_ID"=369)

===================================================================================================
QUERY WITH NO PREDICATE PUSHING

kish@exdbx<>select x.order_id,x.order_priority,x.TOTAL_PROFIT
from
sales_t x,
(select order_id,avg(TOTAL_PROFIT) avg_pft
from SALES_TAB y
where rownum > 1
group by order_id) y
where x.order_id=y.order_id
and x.TOTAL_PROFIT > y.avg_pft
and x.order_id=369;  2    3    4    5    6    7    8    9   10
Elapsed: 00:00:00.01

Execution Plan
----------------------------------------------------------
Plan hash value: 2267306622

----------------------------------------------------------------------------------------------------
| Id  | Operation                      | Name      | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT               |           | 52429 |  2406K|       | 13557   (1)| 00:02:43 |
|   1 |  NESTED LOOPS                  |           | 52429 |  2406K|       | 13557   (1)| 00:02:43 |
|*  2 |   TABLE ACCESS STORAGE FULL    | SALES_T   |     1 |    21 |       |  3271   (1)| 00:00:40 |
|*  3 |   VIEW                         |           | 52160 |  1324K|       | 10286   (1)| 00:02:04 |
|   4 |    SORT GROUP BY               |           |  1043K|    17M|    37M| 10286   (1)| 00:02:04 |
|   5 |     COUNT                      |           |       |       |       |            |          |
|*  6 |      FILTER                    |           |       |       |       |            |          |
|   7 |       TABLE ACCESS STORAGE FULL| SALES_TAB |  1398K|    24M|       |  3633   (1)| 00:00:44 |
----------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - storage("X"."ORDER_ID"=369)
       filter("X"."ORDER_ID"=369)
   3 - filter("X"."TOTAL_PROFIT">"Y"."AVG_PFT" AND "Y"."ORDER_ID"=369)
   6 - filter(ROWNUM>1)

Query rewrite with MV:

Materialized view are similar to a view which store the precomputed result set in table and transformer can rewrite the query before the excution of query. This method can be efficient for large result sets with aggregations

Query transformer rewrite the query by comparing the query with the materialized views and retrieve data from the matched materialized view result set

Below is an example of a query with inner joins with multiple plan steps

kish@exdbx<>set autot traceonly explain
kish@exdbx<>select x.order_id,x.order_priority,x.TOTAL_PROFIT
from
sales_t x
inner join sales_tab y on x.order_id = y.order_id
inner join tabx z on y.order_id = z.order_id;  2    3    4    5
Elapsed: 00:00:00.00

Execution Plan
----------------------------------------------------------
Plan hash value: 972519073

----------------------------------------------------------------------------------------------------
| Id  | Operation                      | Name      | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT               |           |  1059K|    31M|       | 11960   (1)| 00:02:24 |
|*  1 |  HASH JOIN                     |           |  1059K|    31M|    22M| 11960   (1)| 00:02:24 |
|*  2 |   HASH JOIN                    |           |  1053K|    10M|    17M|  5944   (1)| 00:01:12 |
|*  3 |    TABLE ACCESS STORAGE FULL   | SALES_TAB |  1048K|  5120K|       |  3629   (1)| 00:00:44 |
|   4 |    INDEX STORAGE FAST FULL SCAN| IDX_ID    |  1048K|  5120K|       |   620   (1)| 00:00:08 |
|   5 |   TABLE ACCESS STORAGE FULL    | SALES_T   |  1048K|    21M|       |  3273   (1)| 00:00:40 |
----------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - access("X"."ORDER_ID"="Y"."ORDER_ID")
   2 - access("Y"."ORDER_ID"="Z"."ORDER_ID")
   3 - storage("Y"."ORDER_ID" IS NOT NULL)
       filter("Y"."ORDER_ID" IS NOT NULL)

I create a materialized view(MV) for the select query

kish@exdbx<>create materialized view sales_mv
  2  enable query rewrite as
  3  select x.order_id,x.order_priority,x.TOTAL_PROFIT
  4  from
  5  sales_t x
  6  inner join sales_tab y on x.order_id = y.order_id
  7  inner join tabx z on y.order_id = z.order_id;

Materialized view created.

Optimizer chooses the MV without a hint most probably due to its speedness. But still i force the rewrite with a hint to use MV.

kish@exdbx<>select /*+rewrite(sales_mv)*/ x.order_id,x.order_priority,x.TOTAL_PROFIT
  2  from
  3  sales_t x
  4  inner join sales_tab y on x.order_id = y.order_id
  5  inner join tabx z on y.order_id = z.order_id;
Elapsed: 00:00:00.01

Execution Plan
----------------------------------------------------------
Plan hash value: 1420257564

-------------------------------------------------------------------------------------------------
| Id  | Operation                            | Name     | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                     |          |   946K|    42M|   469   (2)| 00:00:06 |
|   1 |  MAT_VIEW REWRITE ACCESS STORAGE FULL| SALES_MV |   946K|    42M|   469   (2)| 00:00:06 |
-------------------------------------------------------------------------------------------------

Note
-----
   - dynamic sampling used for this statement (level=2)

Thus using MV reduce high amount of response time and reduces cost by providing the mirror copy of the query directly without a need to process it from scratch

SQL QUERY TO FIND SESSION DETAILS FROM ACTIVE SESSION HISTORY(ASH)

Use this ash query to find the session details in near past which has details about SQL and wait events

set lines 200
set pages 1000
col event format a10
col sample_time format a20
col session_id format 99999999
col session_state format a20
col wait_time format 9999999
col time_waited format 99999999
col child# format 999
select session_id,
sample_time,
session_state,
event,
wait_time,
time_waited,
sql_id,
sql_child_number child#
from v$active_session_history
where sample_time > sysdate - 3
order by sample_time asc;
fetch next 10 rows only;
CREATE,UPDATE AND DROP VIEWS IN ORACLE

In oracle, views are stored objects which reside virtually as tables in memory(data dictionary) and has no data. View are used during the execution call and it can also created with a join of other table

Create view:

kish@exdbx<>create view STB1 as select * from sales_t;

View created.

Update view:

kish@exdbx<>create or replace view STB as
  2  select order_id from sales_t
  3  where order_id < 3000;

View created.

Drop view:

kish@exdbx<>drop view STB;

View dropped.

ORA-12801: error signaled in parallel query server P000, instance exdbadm01:exdbx1 (1)

Cause:

The error is caused due to different parallel settings for tables

  1* select * from sales_t where order_id in (select order_id from SALES_TAB)
kish@exdbx<>select * from sales_t
  2  where ORDER_ID in (select order_id from SALES_TAB)
  3  or
  4  order_id=369;
select * from sales_t
*
ERROR at line 1:
ORA-12801: error signaled in parallel query server P000, instance exdbadm01:exdbx1 (1)

Workaround:

The query has two tables where one table( SALES_TAB ) has parallel 4 and other table ( SALES_T ) has parallel 1

kish@exdbx<>select index_name,degree from dba_indexes where table_name in ('SALES_T');

INDEX_NAME                     DEGREE
------------------------------ ----------------------------------------
PK_SALES_OID                   1

Elapsed: 00:00:00.02

kish@exdbx<>select table_name,degree from dba_tables where table_name in ('SALES_T','SALES_TAB');

TABLE_NAME                     DEGREE
------------------------------ ----------------------------------------
SALES_TAB                               4
SALES_T                                 1

Equalize the parallel degree for both the tables

kish@exdbx<>alter table SALES_TAB parallel(degree 1);

Table altered.

Query gets executed

Elapsed: 00:00:00.27
kish@exdbx<>select * from sales_t
  2  where ORDER_ID in (select order_id from SALES_TAB)
  3  or
  4  order_id=3;

‘sqlplus’ is not recognized as an internal or external command,operable program or batch file.

Set the environment variables properly

SET oic=C:\Users\kisha\Documents\sqlplusclient\instantclient_19_11 # sqlplus client directory
SET PATH=%oic%:%PATH% 
SET TNS_ADMIN=C:\Users\kisha\Documents\keys
CONFIGURE ASM USING ORACLEASM(ASMLIB UTILITY)

Configure the oracleasm (asmlib) utility

[root@dgprim01 oracle]# oracleasm configure -i
Configuring the Oracle ASM library driver.

This will configure the on-boot properties of the Oracle ASM library
driver.  The following questions will determine whether the driver is
loaded on boot and what permissions it will have.  The current values
will be shown in brackets ('[]').  Hitting <ENTER> without typing an
answer will keep that current value.  Ctrl-C will abort.

Default user to own the driver interface []: oracle
Default group to own the driver interface []: oinstall
Start Oracle ASM library driver on boot (y/n) [n]: y
Scan for Oracle ASM disks on boot (y/n) [y]: y
Writing Oracle ASM library driver configuration: done

Initialize the oracleasm utility drivers

[root@dgprim01 oracle]# oracleasm init
Creating /dev/oracleasm mount point: /dev/oracleasm
Loading module "oracleasm": oracleasm
Configuring "oracleasm" to use device physical block size
Mounting ASMlib driver filesystem: /dev/oracleasm

Create the diskgroups from the logical partition of disk

[root@dgprim01 oracle]# oracleasm createdisk DATA /dev/sdb1
Writing disk header: done
Instantiating disk: done
[root@dgprim01 oracle]# oracleasm createdisk FRA /dev/sdc1
Writing disk header: done
Instantiating disk: done
[root@dgprim01 oracle]# oracleasm deletedisk FRA
Clearing disk header: done
Dropping disk: done
[root@dgprim01 oracle]# oracleasm createdisk RECO /dev/sdc1
Writing disk header: done
Instantiating disk: done
[root@dgprim01 oracle]# oracleasm createdisk REDO /dev/sde1
Writing disk header: done
Instantiating disk: done
[root@dgprim01 oracle]# oracleasm createdisk OCRVOD /dev/sdd1
Writing disk header: done
Instantiating disk: done

Scan the disks which were created to validate the diskgroups

[root@dgprim01 oracle]# oracleasm scandisks
Reloading disk partitions: done
Cleaning any stale ASM disks...
Scanning system for ASM disks...

List the disks to verify the diskgroup

[root@dgprim01 oracle]# oracleasm listdisks
DATA
OCRVOD
RECO
REDO
ORACLEASM TOOL FOR MANAGING ASM ON ORACLE LINUX

ASMLIB is an asm utility which is free to use to manage and discover asm disks logically . This tool can map the disks to the diskgroups easily.

There are three rpm packages for using oracleasm utility

  • oracleasmlib
  • oracleasm-support
  •  kmod-oracleasm

Use below commands to install the packages from ULN repository

yum install kmod-oracleasm -y 

wget https://download.oracle.com/otn_software/asmlib/oracleasmlib-2.0.17-1.el8.x86_64.rpm

wget https://public-yum.oracle.com/repo/OracleLinux/OL8/addons/x86_64/getPackage/oracleasm-support-2.1.12-1.el8.x86_64.rpm

yum localinstall ./oracleasm-support-2.1.12-1.el8.x86_64.rpm ./oracleasmlib-2.0.17-1.el8.x86_64.rpm

SAMPLE OUTPUT:

[root@dgprim01 oracle]# wget https://public-yum.oracle.com/repo/OracleLinux/OL8/              addons/x86_64/getPackage/oracleasm-support-2.1.12-1.el8.x86_64.rpm
--2021-08-23 19:39:52--  https://public-yum.oracle.com/repo/OracleLinux/OL8/addo              ns/x86_64/getPackage/oracleasm-support-2.1.12-1.el8.x86_64.rpm
Resolving public-yum.oracle.com (public-yum.oracle.com)... 106.51.144.225, 2600:              140f:c000:184::2a7d, 2600:140f:c000:188::2a7d
Connecting to public-yum.oracle.com (public-yum.oracle.com)|106.51.144.225|:443.              .. connected.
HTTP request sent, awaiting response... 200 OK
Length: 99852 (98K) [application/x-rpm]
Saving to: ‘oracleasm-support-2.1.12-1.el8.x86_64.rpm’

oracleasm-support-2 100%[===================>]  97.51K  --.-KB/s    in 0.02s

2021-08-23 19:39:52 (6.10 MB/s) - ‘oracleasm-support-2.1.12-1.el8.x86_64.rpm’ sa              ved [99852/99852]

[root@dgprim01 oracle]# yum localinstall ./oracleasm-support-2.1.12-1.el8.x86_64.rpm ./oracleasmlib-2.0.17-1.el8.x86_64.rpm
Last metadata expiration check: 23:56:50 ago on Sun 22 Aug 2021 07:43:23 PM IST.
Package oracleasmlib-2.0.17-1.el8.x86_64 is already installed.
Dependencies resolved.
================================================================================
 Package                Arch        Version             Repository         Size
================================================================================
Installing:
 oracleasm-support      x86_64      2.1.12-1.el8        @commandline       98 k

Transaction Summary
================================================================================
Install  1 Package

Total size: 98 k
Installed size: 349 k
Is this ok [y/N]: y
Downloading Packages:
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Preparing        :                                                        1/1
  Installing       : oracleasm-support-2.1.12-1.el8.x86_64                  1/1
  Running scriptlet: oracleasm-support-2.1.12-1.el8.x86_64                  1/1
Note: Forwarding request to 'systemctl enable oracleasm.service'.
Synchronizing state of oracleasm.service with SysV service script with /usr/lib/              systemd/systemd-sysv-install.
Executing: /usr/lib/systemd/systemd-sysv-install enable oracleasm
Created symlink /etc/systemd/system/multi-user.target.wants/oracleasm.service →               /usr/lib/systemd/system/oracleasm.service.

/sbin/ldconfig: /etc/ld.so.conf.d/kernel-5.4.17-2102.201.3.el8uek.x86_64.conf:6:               hwcap directive ignored

  Verifying        : oracleasm-support-2.1.12-1.el8.x86_64                  1/1

Installed:
  oracleasm-support-2.1.12-1.el8.x86_64

Complete!
[root@dgprim01 oracle]#

Use the below link to configure and create diskgroups for oracleasm

https://wordpress.com/post/alphaoragroup.com/7230

error: rpmdb: BDB0113 Thread/process 27728/140114045668224 failed: BDB1507 Thread died in Berkeley DB libraryerror: db5 error(-30973) from dbenv->failchk: BDB0087 DB_RUNRECOVERY: Fatal error, run database recoveryerror: cannot open Packages index using db5 – (-30973)error: cannot open Packages database in /var/lib/rpmError: Error: rpmdb open failed

Got the below berkley error when installing a package from yum

[root@dgprim01 oracle]# yum install oracleasmlib
error: rpmdb: BDB0113 Thread/process 27728/140114045668224 failed: BDB1507 Thread died in Berkeley DB library
error: db5 error(-30973) from dbenv->failchk: BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery
error: cannot open Packages index using db5 -  (-30973)
error: cannot open Packages database in /var/lib/rpm
Error: Error: rpmdb open failed

Followed these steps and worked perfect!

[root@dgprim01 oracle]# mkdir /var/lib/rpm/backup

[root@dgprim01 oracle]# cp -a /var/lib/rpm/__db* /var/lib/rpm/backup/
[root@dgprim01 oracle]# rm -f /var/lib/rpm/__db.[0-9][0-9]*
[root@dgprim01 oracle]# rpm --quiet -qa
[root@dgprim01 oracle]# rpm --rebuilddb
error: could not delete old database at /var/lib/rpmold.28200
[root@dgprim01 oracle]# yum clean all
24 files removed
[root@dgprim01 oracle]# yum install oracleasmlib oracleasm-support -y
Oracle Linux 8 BaseOS Lates  1% [                           ] 128 kB/s | 547 kB     05:07 ETA

DRIVER BACKUP IN WINDOWS (ACCIDENTALLY DELETED USB HUB DRIVERS – KEYBOARD NOT WORKING)

Some days back, i try to repair a corrupted pen drive by trying all trial and error methods. I tried repair of corrupted drive and scan the disk for corruptions. Then i deleted the USB drivers and then delete the root hub usb driver which deactivated the keyboard suddenly. I couldnot type anything. Then i shutdown the system and boot back to windows 10. I couldnot login to windows and got frustrated because of urgent work. But fortunately, my touch pad as working fine on my laptop. After sometime , an idea glowed on my mind to use virtual keyboard and i was able to type on the screen with the help of touchpad. It was pretty much difficult to restore to a previous point as there was no restore point created. I cannot reinstall windows or refresh the PC because of application and data on the PC was important. Even i couldnot download any drivers from the internet from any application. What i did was to perform a windows update to download the required drivers automatically.

After the windows update, drivers were automatically downloaded

Open CMD –> Run the below command to take backup of all the windows drivers for preventive measures in case you lost the essential driver

C:\Windows\system32>dism /online /export-driver /destination:"D:\Drivers Backup"

Deployment Image Servicing and Management tool
Version: 10.0.17134.1

Image Version: 10.0.17134.1304

Exporting 1 of 80 - oem0.inf: The driver package successfully exported.
Exporting 2 of 80 - oem1.inf: The driver package successfully exported.
Exporting 3 of 80 - oem10.inf: The driver package successfully exported.
Exporting 4 of 80 - oem11.inf: The driver package successfully exported.
Exporting 5 of 80 - oem12.inf: The driver package successfully exported.
Exporting 6 of 80 - oem13.inf: The driver package successfully exported.
Exporting 7 of 80 - oem15.inf: The driver package successfully exported.
Exporting 8 of 80 - oem16.inf: The driver package successfully exported.
Exporting 9 of 80 - oem17.inf: The driver package successfully exported.
Exporting 10 of 80 - oem18.inf: The driver package successfully exported.
Exporting 11 of 80 - oem2.inf: The driver package successfully exported.
Exporting 12 of 80 - oem20.inf: The driver package successfully exported.
Exporting 13 of 80 - oem21.inf: The driver package successfully exported.
Exporting 14 of 80 - oem22.inf: The driver package successfully exported.
Exporting 15 of 80 - oem23.inf: The driver package successfully exported.
Exporting 16 of 80 - oem24.inf: The driver package successfully exported.
Exporting 17 of 80 - oem25.inf: The driver package successfully exported.
Exporting 18 of 80 - oem26.inf: The driver package successfully exported.
Exporting 19 of 80 - oem27.inf: The driver package successfully exported.
Exporting 20 of 80 - oem28.inf: The driver package successfully exported.
Exporting 21 of 80 - oem29.inf: The driver package successfully exported.
Exporting 22 of 80 - oem3.inf: The driver package successfully exported.
Exporting 23 of 80 - oem30.inf: The driver package successfully exported.
Exporting 24 of 80 - oem31.inf: The driver package successfully exported.
Exporting 25 of 80 - oem32.inf: The driver package successfully exported.
Exporting 26 of 80 - oem33.inf: The driver package successfully exported.
Exporting 27 of 80 - oem34.inf: The driver package successfully exported.
Exporting 28 of 80 - oem35.inf: The driver package successfully exported.
Exporting 29 of 80 - oem36.inf: The driver package successfully exported.
Exporting 30 of 80 - oem37.inf: The driver package successfully exported.
Exporting 31 of 80 - oem38.inf: The driver package successfully exported.
Exporting 32 of 80 - oem39.inf: The driver package successfully exported.
Exporting 33 of 80 - oem4.inf: The driver package successfully exported.
Exporting 34 of 80 - oem40.inf: The driver package successfully exported.
Exporting 35 of 80 - oem41.inf: The driver package successfully exported.
Exporting 36 of 80 - oem42.inf: The driver package successfully exported.
Exporting 37 of 80 - oem43.inf: The driver package successfully exported.
Exporting 38 of 80 - oem44.inf: The driver package successfully exported.
Exporting 39 of 80 - oem45.inf: The driver package successfully exported.
Exporting 40 of 80 - oem47.inf: The driver package successfully exported.
Exporting 41 of 80 - oem48.inf: The driver package successfully exported.
Exporting 42 of 80 - oem5.inf: The driver package successfully exported.
Exporting 43 of 80 - oem51.inf: The driver package successfully exported.
Exporting 44 of 80 - oem52.inf: The driver package successfully exported.
Exporting 45 of 80 - oem53.inf: The driver package successfully exported.
Exporting 46 of 80 - oem54.inf: The driver package successfully exported.
Exporting 47 of 80 - oem55.inf: The driver package successfully exported.
Exporting 48 of 80 - oem56.inf: The driver package successfully exported.
Exporting 49 of 80 - oem57.inf: The driver package successfully exported.
Exporting 50 of 80 - oem58.inf: The driver package successfully exported.
Exporting 51 of 80 - oem59.inf: The driver package successfully exported.
Exporting 52 of 80 - oem6.inf: The driver package successfully exported.
Exporting 53 of 80 - oem60.inf: The driver package successfully exported.
Exporting 54 of 80 - oem61.inf: The driver package successfully exported.
Exporting 55 of 80 - oem62.inf: The driver package successfully exported.
Exporting 56 of 80 - oem66.inf: The driver package successfully exported.
Exporting 57 of 80 - oem67.inf: The driver package successfully exported.
Exporting 58 of 80 - oem68.inf: The driver package successfully exported.
Exporting 59 of 80 - oem69.inf: The driver package successfully exported.
Exporting 60 of 80 - oem7.inf: The driver package successfully exported.
Exporting 61 of 80 - oem71.inf: The driver package successfully exported.
Exporting 62 of 80 - oem72.inf: The driver package successfully exported.
Exporting 63 of 80 - oem75.inf: The driver package successfully exported.
Exporting 64 of 80 - oem76.inf: The driver package successfully exported.
Exporting 65 of 80 - oem77.inf: The driver package successfully exported.
Exporting 66 of 80 - oem78.inf: The driver package successfully exported.
Exporting 67 of 80 - oem79.inf: The driver package successfully exported.
Exporting 68 of 80 - oem8.inf: The driver package successfully exported.
Exporting 69 of 80 - oem80.inf: The driver package successfully exported.
Exporting 70 of 80 - oem81.inf: The driver package successfully exported.
Exporting 71 of 80 - oem82.inf: The driver package successfully exported.
Exporting 72 of 80 - oem83.inf: The driver package successfully exported.
Exporting 73 of 80 - oem84.inf: The driver package successfully exported.
Exporting 74 of 80 - oem86.inf: The driver package successfully exported.
Exporting 75 of 80 - oem87.inf: The driver package successfully exported.
Exporting 76 of 80 - oem88.inf: The driver package successfully exported.
Exporting 77 of 80 - oem89.inf: The driver package successfully exported.
Exporting 78 of 80 - oem9.inf: The driver package successfully exported.
Exporting 79 of 80 - oem90.inf: The driver package successfully exported.
Exporting 80 of 80 - oem91.inf: The driver package successfully exported.
The operation completed successfully.

C:\Windows\system32>