[Solved] how to increase oracle query when 22,000,000 records in single table?
Looking to automatically optimize YOUR SQL query? Start for free.

EverSQL Database Performance Knowledge Base

how to increase oracle query when 22,000,000 records in single table?

Database type:

I have oracle 10g installed on windows server 2003. I have 22,000,000 records in single table and this is a transactional table,
increasing of records in same table approx. 50,000 per month.

My question is that whenever I run query on it always my query too slow. Is there any method by which I can improve the performance of the query, like partitioning the table or else?

the query is

select a.prd_code
       , a.br_code||'-'||br_title
       , a.size_code||'-'||size_title
       ,size_in_gms
       , a.var_code||'-'||var_title
      , a.form_code||'-'||form_title
      , a.pack_code||'-'||pack_title
      , a.pack_type_code||'-'||pack_type_title
      , start_date
      , end_date
      , a.price
from   prices a
       , brand br
       ,  (select distinct prd_code
                 , br_code
                 ,  size_code
                 , var_code
                 , form_code
                 ,packing_code
                 ,  pack_type_code 
            from cphistory 
            where prd_code = '01' 
            and flag = 'Y'  
            and project_yy = '2009' and '01' and '10') cp
       , (select prd_code
                , br_code
                , size_code
                , size_in_gms
          from sizes 
          where prd_code = '01' 
          and end_date = '31-dec-2050' 
          and flag = 'Y') sz
        ,  (select prd_code
                   , br_code
                   , var_code
                   , var_title 
              from varient) vt
          , (select prd_code
                    , br_code
                    , form_code
                    , form_title 
             from form) fm
          ,  (select prd_code
                     , pack_title 
               from package) pc
          ,    (select prd_code
                       , pack_type_title
                 from pakck_type) pt
where a.prd_code = br.prd_code 
and   a.br_code  = br_br_code
and   a.prd_code = sz.prd_code
and   a.br_code  = sz.br_code
and   a.size_code = sz.size_code
and   a.prd_code  = vt.prd_code
and   a.br_code   = vt.br_code
and   a.var_code  = vt.var_code
and   a.prd_code  = fm.prd_code
and   a.br_code   = fm.br_code
and   a.form_code = fm.form_code
and   a.prd_code  = pc.prd_code
and   a.br_code   = pc.br_code
and   a.pack_code = pc.pack_code
and   a.prd_code  = pt.prd_code
and   a.pack_type_code = pt.pack_type_code
and   end_date = '2009'
and   prd_code = '01'
order by a.prd_code
         , a.br_code
         , a.size_code
         , a.var_code
         , a.pack_code
         , a.form_code

tables used in this query are:

prices    : has more than 2.1M rows
cphistory : has more than 2.2M rows
sizes     : has more than 5000 rows
brand     : has more than 1200 rows
varient   : has more than 1800 rows
package   : has more than 200 rows
pack_type : has more than 150 rows

How to optimize this SQL query?

The following recommendations will help you in your SQL tuning process.
You'll find 3 sections below:

  1. Description of the steps you can take to speed up the query.
  2. The optimal indexes for this query, which you can copy and create in your database.
  3. An automatically re-written query you can copy and execute in your database.
The optimization process and recommendations:
  1. Avoid Subqueries (query line: 16): We advise against using subqueries as they are not optimized well by the optimizer. Therefore, it's recommended to join a newly created temporary table that holds the data, which also includes the relevant search index.
  2. Avoid Subqueries (query line: 32): We advise against using subqueries as they are not optimized well by the optimizer. Therefore, it's recommended to join a newly created temporary table that holds the data, which also includes the relevant search index.
  3. Avoid Subqueries (query line: 43): We advise against using subqueries as they are not optimized well by the optimizer. Therefore, it's recommended to join a newly created temporary table that holds the data, which also includes the relevant search index.
  4. Avoid Subqueries (query line: 50): We advise against using subqueries as they are not optimized well by the optimizer. Therefore, it's recommended to join a newly created temporary table that holds the data, which also includes the relevant search index.
  5. Avoid Subqueries (query line: 57): We advise against using subqueries as they are not optimized well by the optimizer. Therefore, it's recommended to join a newly created temporary table that holds the data, which also includes the relevant search index.
  6. Avoid Subqueries (query line: 62): We advise against using subqueries as they are not optimized well by the optimizer. Therefore, it's recommended to join a newly created temporary table that holds the data, which also includes the relevant search index.
  7. Push Filtering Conditions Into Subqueries (modified query below): Parts of the WHERE clause can pushed from the outer query to a subquery / union clause. Applying those conditions as early as possible will allow the database to scan less data and run the query more efficiently.
  8. Use Numeric Column Types For Numeric Values (query line: 88): Referencing a numeric value (e.g. 2009) as a string in a WHERE clause might result in poor performance. Possible impacts of storing numbers as varchars: more space will be used, you won't be able to perform arithmetic operations, the data won't be self-validated, aggregation functions like SUM won't work, the output may sort incorrectly and more. If the column is numeric, remove the quotes from the constant value, to make sure a numeric comparison is done.
  9. Use Numeric Column Types For Numeric Values (query line: 27): Referencing a numeric value (e.g. 01) as a string in a WHERE clause might result in poor performance. Possible impacts of storing numbers as varchars: more space will be used, you won't be able to perform arithmetic operations, the data won't be self-validated, aggregation functions like SUM won't work, the output may sort incorrectly and more. If the column is numeric, remove the quotes from the constant value, to make sure a numeric comparison is done.
  10. Use Numeric Column Types For Numeric Values (query line: 29): Referencing a numeric value (e.g. 2009) as a string in a WHERE clause might result in poor performance. Possible impacts of storing numbers as varchars: more space will be used, you won't be able to perform arithmetic operations, the data won't be self-validated, aggregation functions like SUM won't work, the output may sort incorrectly and more. If the column is numeric, remove the quotes from the constant value, to make sure a numeric comparison is done.
  11. Use Numeric Column Types For Numeric Values (query line: 30): Referencing a numeric value (e.g. 01) as a string in a WHERE clause might result in poor performance. Possible impacts of storing numbers as varchars: more space will be used, you won't be able to perform arithmetic operations, the data won't be self-validated, aggregation functions like SUM won't work, the output may sort incorrectly and more. If the column is numeric, remove the quotes from the constant value, to make sure a numeric comparison is done.
  12. Use Numeric Column Types For Numeric Values (query line: 31): Referencing a numeric value (e.g. 10) as a string in a WHERE clause might result in poor performance. Possible impacts of storing numbers as varchars: more space will be used, you won't be able to perform arithmetic operations, the data won't be self-validated, aggregation functions like SUM won't work, the output may sort incorrectly and more. If the column is numeric, remove the quotes from the constant value, to make sure a numeric comparison is done.
  13. Use Numeric Column Types For Numeric Values (query line: 40): Referencing a numeric value (e.g. 01) as a string in a WHERE clause might result in poor performance. Possible impacts of storing numbers as varchars: more space will be used, you won't be able to perform arithmetic operations, the data won't be self-validated, aggregation functions like SUM won't work, the output may sort incorrectly and more. If the column is numeric, remove the quotes from the constant value, to make sure a numeric comparison is done.
  14. Use Numeric Column Types For Numeric Values (query line: 69): Referencing a numeric value (e.g. 01) as a string in a WHERE clause might result in poor performance. Possible impacts of storing numbers as varchars: more space will be used, you won't be able to perform arithmetic operations, the data won't be self-validated, aggregation functions like SUM won't work, the output may sort incorrectly and more. If the column is numeric, remove the quotes from the constant value, to make sure a numeric comparison is done.
The optimized query:
SELECT
        a.prd_code,
        a.br_code || '-' || br_title,
        a.size_code || '-' || size_title,
        sz.size_in_gms,
        a.var_code || '-' || vt.var_title,
        a.form_code || '-' || fm.form_title,
        a.pack_code || '-' || pc.pack_title,
        a.pack_type_code || '-' || pt.pack_type_title,
        start_date,
        end_date,
        a.price 
    FROM
        prices a,
        brand br,
        (SELECT
            DISTINCT cphistory.prd_code,
            cphistory.br_code,
            cphistory.size_code,
            cphistory.var_code,
            cphistory.form_code,
            cphistory.packing_code,
            cphistory.pack_type_code 
        FROM
            cphistory 
        WHERE
            cphistory.prd_code = '01' 
            AND cphistory.flag = 'Y' 
            AND cphistory.project_yy = '2009' 
            AND '01' 
            AND '10') cp,
        (SELECT
            sizes.prd_code,
            sizes.br_code,
            sizes.size_code,
            sizes.size_in_gms 
        FROM
            sizes 
        WHERE
            sizes.prd_code = '01' 
            AND sizes.end_date = '31-dec-2050' 
            AND sizes.flag = 'Y') sz,
        (SELECT
            varient.prd_code,
            varient.br_code,
            varient.var_code,
            varient.var_title 
        FROM
            varient) vt,
        (SELECT
            form.prd_code,
            form.br_code,
            form.form_code,
            form.form_title 
        FROM
            form) fm,
        (SELECT
            package.prd_code,
            package.pack_title 
        FROM
            package) pc,
        (SELECT
            pakck_type.prd_code,
            pakck_type.pack_type_title 
        FROM
            pakck_type 
        WHERE
            (
                pakck_type.prd_code = '01'
            )) pt 
    WHERE
        a.prd_code = br.prd_code 
        AND a.br_code = br_br_code 
        AND a.prd_code = sz.prd_code 
        AND a.br_code = sz.br_code 
        AND a.size_code = sz.size_code 
        AND a.prd_code = vt.prd_code 
        AND a.br_code = vt.br_code 
        AND a.var_code = vt.var_code 
        AND a.prd_code = fm.prd_code 
        AND a.br_code = fm.br_code 
        AND a.form_code = fm.form_code 
        AND a.prd_code = pc.prd_code 
        AND a.br_code = pc.br_code 
        AND a.pack_code = pc.pack_code 
        AND a.prd_code = pt.prd_code 
        AND a.pack_type_code = pt.pack_type_code 
        AND end_date = '2009' 
        AND 1 = 1 
    ORDER BY
        a.prd_code,
        a.br_code,
        a.size_code,
        a.var_code,
        a.pack_code,
        a.form_code

Related Articles



* original question posted on StackOverflow here.