Oracle query performance.

In one of my oracle procedure, I make the following query.

Select plate in amountA from Table1 where Bill_id = billId and CATEGORY = 'A ';

Select plate in amountB from Table1 where Bill_id = billId and CATEGORY = 'B ';.

Select plate in amountC from Table1 where Bill_id = billId and CATEGORY = 'C ';

I want to improve this code block.  I want to make a single request and get the result.

SELECT
(Select sum(amount) into amountA from Table1 Where Bill_id=billId and CATEGORY='A') AS x1,
(Select sum(amount) into amountB from Table1 Where Bill_id=billId and CATEGORY='B') AS x2,
(Select sum(amount) into amountC from Table1 Where Bill_id=billId and CATEGORY='C') AS x3


Can be a solution, but I not wish on it.


Is there a better approach?

Select sum (decode (category 'A', amount, 0))

sum (decode(category,'B',amount,0))

sum (decode(category,'C',amount,0))

in amountA

amountB

amountC

FROM table1

where bill_id = billid

and the category ('A', 'B', 'C');

Tags: Database

Similar Questions

  • Behavior inconsistent performance Oracle query

    Consider the following query:

    SELECT * FROM ( SELECT ARRM.*, ROWNUM FROM CRS_ARRANGEMENTS ARRM WHERE CONCAT(ARRM.NBR_ARRANGEMENT, ARRM.TYP_PRODUCT_ARRANGEMENT) > CONCAT('0000000000000000', '0000') ORDER BY ARRM.NBR_ARRANGEMENT, ARRM.TYP_PRODUCT_ARRANGEMENT, ARRM.COD_CURRENCY) WHERE ROWNUM < 1000;

    This query is performed on a table that has 10 000 000 entries. While running the query Oracle SQL Developer or my application it takes 4 minutes to run! Unfortunately, it's also the behaviour within the application I am writing. Change the value of 1000 to 10 has no impact, which suggests that he made a full table scan.

    However when the squirrel running the query returns within a few milliseconds. How is that possible? Explain plan generated in squirrel gives:

    Explain plan in SQuirreL

    But a plan different explain is generated in Oracle SQL Developer, for the same query:

    Explain plan in Oracle SQL Developer

    No idea how this difference in behavior is possible? I can't understand it. I tried with JPA and raw JDBC. In the application, I need to parse through 10 000 000 records and this query is used for pagination, so 4 minutes of waiting is not an option (which would take 27 days).

    Note: I use the same Oracle jdbc driver into a squirrel and my application so it's not the source of the problem.

    I also posted this to other web sites, for example

    http://StackOverflow.com/questions/28896564/Oracle-inconsistent-performance-behaviour-of-query

    OK - I created a test (below) case and got the same exact results you did 'test' - a FFS using SQL index * more. I then tested with SQL Developer and got the same results. You are 100 billion sure that you did not have two databases somewhere with the same name?

    SQL> create table crs_arrangements
      2  (nbr_arrangement varchar2(16) not null,
      3   product_arrangement varchar2(4) not null,
      4   cod_currency varchar2(3) not null,
      5   filler1 number,
      6  filler2 number);                                             
    
    Table created.                                                    
    
    SQL> alter table crs_arrangements add constraint crs_pk primary key
      2  (nbr_arrangement, product_arrangement, cod_currency);        
    
    Table altered.                                                    
    
    REM generate some data
    
    SQL> select count(*) from crs_arrangements;          
    
      COUNT(*)
    ----------
      10000000                                           
    
    SQL> exec dbms_stats.gather_table_stats('HR', 'CRS_ARRANGEMENTS', cascade=>true);
    
    SQL> ed
    Wrote file afiedt.buf                                                        
    
      1  explain plan for
      2  SELECT * FROM
      3    ( SELECT ARRM.*, ROWNUM FROM CRS_ARRANGEMENTS ARRM
      4      WHERE CONCAT(ARRM.NBR_ARRANGEMENT, ARRM.PRODUCT_ARRANGEMENT) > CONCAT('
    0000000000000000', '0000')
      5* ORDER BY ARRM.NBR_ARRANGEMENT, ARRM.PRODUCT_ARRANGEMENT, ARRM.COD_CURRENCY)
    WHERE ROWNUM < 1000
    SQL> /                                                                       
    
    -------------------
    | Id  | Operation                      | Name             | Rows  | Bytes | Cost
    (%CPU)| Time     |
    --------------------------------------------------------------------------------
    -------------------
    |   0 | SELECT STATEMENT               |                  |   999 | 55944 |  112
    7   (0)| 00:00:14 |
    |*  1 |  COUNT STOPKEY                 |                  |       |       |
           |          |
    |   2 |   VIEW                         |                  |  1000 | 56000 |  112
    7   (0)| 00:00:14 |
    |   3 |    COUNT                       |                  |       |       |
           |          |
    |   4 |     TABLE ACCESS BY INDEX ROWID| CRS_ARRANGEMENTS |   500K|    17M|  112
    7   (0)| 00:00:14 |
    |*  5 |      INDEX FULL SCAN           | CRS_PK           |  1000 |       |   13
    0   (0)| 00:00:02 |      
    

    However, as noted earlier in this thread:

    alter session set NLS_SORT = FRENCH;
    
    |   0 | SELECT STATEMENT        |                  |   999 | 55944 |       | 202
    85   (1)| 00:04:04 |
    |*  1 |  COUNT STOPKEY          |                  |       |       |       |
            |          |
    |   2 |   VIEW                  |                  |   500K|    26M|       | 202
    85   (1)| 00:04:04 |
    |*  3 |    SORT ORDER BY STOPKEY|                  |   500K|    17M|    24M| 202
    85   (1)| 00:04:04 |
    |   4 |     COUNT               |                  |       |       |       |
            |          |
    |*  5 |      TABLE ACCESS FULL  | CRS_ARRANGEMENTS |   500K|    17M|       | 155
    48   (1)| 00:03:07 | 
    

    Can you check your preferences of SQL Developer under database-> NLS and ensure that sorting is set to BINARY? I wonder if either he is on something else in SQL Developer or maybe your by default, the database is not BINARY and squirrel is assigning BINARY when connecting.

  • The BLASTP_ALIGN query performance decreases as increases the size table Ref?

    Newbie here.

    I'm using Oracle 11.2.0.3.

    I am currently running and a loop through the cursor according to who uses the tool BLASTP_ALIGN from Oracle:

    FOR MyALIGN_TAB IN

    (

    Select a.query_string, H.AA_SEQUENCE target_string, t_seq_id, pct_identity, alignment_length, incompatibilities, positive, gap_openings, gap_list, q_seq_start, q_frame, q_seq_end, t_seq_start, t_seq_end, t_frame, score, wait

    from (select t_seq_id, pct_identity, alignment_length, incompatibilities, positive, gap_openings, gap_list, q_seq_start, q_frame, q_seq_end, t_seq_start, t_seq_end, t_frame, score, wait

    table (BLASTP_ALIGN ((p_INPUT_SEQUENCE SELECT query_string FROM DUAL),

    CURSOR (Select GB_ACCESSION, AA_SEQUENCE from HUMAN_DB1. HUMAN_PROTEINS),

    1-1, 0, 0, 'PAM30',. 1, 10, 1, 2, 0, 0)

    )

    ),

    (SELECT p_INPUT_SEQUENCE FROM DUAL Query_string).

    HUMAN_DB1. HUMAN_PROTEINS H

    WHERE UPPER (t_seq_id) = UPPER (H.gb_accession) and gap_openings = 0

    )

    LOOP


    This initial query works relatively well (about 2 seconds) on a table target of approximately 20,000 documents (reproduced above, as the HUAMN_DB1. Table HUMAN_PROTEINS. However, if I had to choose a selected target table that contains approximately 170 000 records, the query performance are significantly reduced in about 45 seconds. The two tables have identical ratings.


    I was wondering if there are ways to improve the performance of BLASTP_ALIGN on large tables? There only seems to be a lot of documentation on BLASTP_ALIGN. I could find this (http://docs.oracle.com/cd/B19306_01/datamine.102/b14340/blast.htm), but it wasn't that useful.


    Any ideas would be greatly appreciated.



    In case one is interested... it looked like the AA_SEQUENCE column in the following slider: SLIDER (Select GB_ACCESSION, AA_SEQUENCE from HUMAN_DB1. HUMAN_PROTEINS) was a CLOB field. In my second target, my column correspodoning table was VARCHAR2. One hypothesis is that BLASTP_ALIGN made a VARCHAR2-> CLOB conversion internally. I changed the table to have a CLOB column and with success against BLASTP_ALIGN 170 000 documents about 8 seconds (not much, but better than 45).

    I will mark it as answered.

  • Query performance poor when they join CONTAINS to another table

    We just recently started evaluation Oracle Text for a search solution. We must be able to find a table which can have over 20 million lines. Each user can have visibility to a very small part of these lines. The goal is to have a single Oracle text index that represents all the columns of research in the table (multi column datastore) and provide a score for each search result so that we can sort the search results in descending score order. What we see is that the performance of the queries of TOAD are extremely fast, when we write a simple CONTAINS query against the table indexed Oracle text. However, when we first try reduce the lines from that CONTAINS query must search using a we find the query performance degrades significantly.

    For example, we can find all the records that a user has access from our base table of the following query:

    SELECT d.duns_loc
    DUNS d
    JOIN primary_contact pc
    ON d.duns_loc = pc.duns_loc
    AND pc.emp_id =: employeeID;

    This query may run in < 100 m in the example, this query returns close to 1200 lines of the duns_loc of primary key.

    Our search query looks like this:

    SELECT score (1), d.
    DUNS d
    WHERE CONTAINS (TEXT_KEY,: research, 1) > 0
    ORDER BY score (1) DESC;

    The: Find value in this example will be 'Highway '. The query can return 246 k lines in about 2 seconds.

    2 seconds is good, but we should be able to have a much quicker response if the request did not have to search the entire table, right? Since each user can only records from 'view' that they are assigned to as us if the search operation had to be analysed a tiny tiny percentage of the TEXT index, we should see results faster (and more relevant). If we now write the following query:

    WITH the subset
    AS
    (SELECT d.duns_loc
    DUNS d
    JOIN primary_contact pc
    ON d.duns_loc = pc.duns_loc
    AND pc.emp_id =: employeeID
    )
    SELECT score (1), d.
    DUNS d
    JOIN the subset s
    ON d.duns_loc = s.duns_loc
    WHERE CONTAINS (TEXT_KEY,: research, 1) > 0
    ORDER BY score (1) DESC;

    For reasons that we have not been able to identify this query actually takes longer to run than the sum times the contributing elements. This query takes more than 6 seconds to run. We, or our DBA can understand why this query runs worse than a large open research. Open research is not ideal because the query eventually folders back to the user, they do not have access to view.

    Has anyone ever encountered something like that? Any suggestions on what to watch or where to go? If someone wants more information to help diagnosis to let me know, and I'll be happy to produce it here.

    Thank you!!

    Since you're using two tables, you will get probably better performance on an index that uses a section group and a user_datastore that uses a procedure. He should be able to recover all the data with a simple query, and hit a single index. Please see the demo below. Indexing can be slower, but research should be faster. If you have your primary and foreign keys in place and current statistics before you create the index, it should speed up indexing.

    SCOTT@orcl_11gR2> -- tables:
    SCOTT@orcl_11gR2> CREATE TABLE duns
      2    (duns_loc       NUMBER,
      3       business_name  VARCHAR2 (15),
      4       business_name2 VARCHAR2 (15),
      5       address_line   VARCHAR2 (30),
      6       city            VARCHAR2 (15),
      7       state            VARCHAR2 (2),
      8       business_phone VARCHAR2 (15),
      9       contact_name   VARCHAR2 (15),
     10       contact_title  VARCHAR2 (15),
     11       text_key       VARCHAR2 (1),
     12       CONSTRAINT     duns_pk PRIMARY KEY (duns_loc))
     13  /
    
    Table created.
    
    SCOTT@orcl_11gR2> CREATE TABLE primary_contact
      2    (duns_loc       NUMBER,
      3       emp_id            NUMBER,
      4       CONSTRAINT     primary_contact_pk
      5                   PRIMARY KEY (emp_id, duns_loc),
      6       CONSTRAINT     primary_contact_fk FOREIGN KEY (duns_loc)
      7                   REFERENCES duns (duns_loc))
      8  /
    
    Table created.
    
    SCOTT@orcl_11gR2> -- data:
    SCOTT@orcl_11gR2> INSERT INTO duns (duns_loc, address_line) VALUES (1, 'highway')
      2  /
    
    1 row created.
    
    SCOTT@orcl_11gR2> INSERT INTO duns (duns_loc, address_line) VALUES (2, 'highway')
      2  /
    
    1 row created.
    
    SCOTT@orcl_11gR2> INSERT INTO primary_contact VALUES (1, 1)
      2  /
    
    1 row created.
    
    SCOTT@orcl_11gR2> INSERT INTO primary_contact VALUES (2, 2)
      2  /
    
    1 row created.
    
    SCOTT@orcl_11gR2> INSERT INTO duns (duns_loc, address_line)
      2  SELECT object_id, object_name
      3  FROM   all_objects
      4  WHERE  object_id > 2
      5  /
    
    76029 rows created.
    
    SCOTT@orcl_11gR2> INSERT INTO primary_contact
      2  SELECT object_id, namespace
      3  FROM   all_objects
      4  WHERE  object_id > 2
      5  /
    
    76029 rows created.
    
    SCOTT@orcl_11gR2> -- gather statistics:
    SCOTT@orcl_11gR2> EXEC DBMS_STATS.GATHER_TABLE_STATS (USER, 'DUNS')
    
    PL/SQL procedure successfully completed.
    
    SCOTT@orcl_11gR2> EXEC DBMS_STATS.GATHER_TABLE_STATS (USER, 'PRIMARY_CONTACT')
    
    PL/SQL procedure successfully completed.
    
    SCOTT@orcl_11gR2> -- procedure:
    SCOTT@orcl_11gR2> CREATE OR REPLACE PROCEDURE duns_proc
      2    (p_rowid IN ROWID,
      3       p_clob     IN OUT NOCOPY CLOB)
      4  AS
      5  BEGIN
      6    FOR d IN
      7        (SELECT duns_loc,
      8             '' ||
      9             business_name     || ' ' ||
     10             business_name2  || ' ' ||
     11             address_line  || ' ' ||
     12             city  || ' ' ||
     13             state     || ' ' ||
     14             business_phone  || ' ' ||
     15             contact_name  || ' ' ||
     16             contact_title ||
     17             ''
     18             AS duns_cols
     19         FROM      duns
     20         WHERE  ROWID = p_rowid)
     21    LOOP
     22        DBMS_LOB.WRITEAPPEND (p_clob, LENGTH (d.duns_cols), d.duns_cols);
     23        FOR pc IN
     24          (SELECT '' || emp_id || '' AS pc_col
     25           FROM   primary_contact
     26           WHERE  duns_loc = d.duns_loc)
     27        LOOP
     28          DBMS_LOB.WRITEAPPEND (p_clob, LENGTH (pc.pc_col), pc.pc_col);
     29        END LOOP;
     30    END LOOP;
     31  END duns_proc;
     32  /
    
    Procedure created.
    
    SCOTT@orcl_11gR2> SHOW ERRORS
    No errors.
    SCOTT@orcl_11gR2> -- user datastore, section group with field section:
    SCOTT@orcl_11gR2> begin
      2    ctx_ddl.create_preference ('duns_store', 'USER_DATASTORE');
      3    ctx_ddl.set_attribute ('duns_store', 'PROCEDURE', 'duns_proc');
      4    ctx_ddl.set_attribute ('duns_store', 'OUTPUT_TYPE', 'CLOB');
      5    ctx_ddl.create_section_group ('duns_sg', 'BASIC_SECTION_GROUP');
      6    ctx_ddl.add_field_section ('duns_sg', 'emp_id', 'emp_id', true);
      7  end;
      8  /
    
    PL/SQL procedure successfully completed.
    
    SCOTT@orcl_11gR2> -- text index with user datastore and section group:
    SCOTT@orcl_11gR2> CREATE INDEX duns_context_index
      2  ON duns (text_key)
      3  INDEXTYPE IS CTXSYS.CONTEXT
      4  FILTER BY duns_loc
      5  PARAMETERS
      6    ('DATASTORE     duns_store
      7        SECTION GROUP     duns_sg
      8        SYNC          (ON COMMIT)')
      9  /
    
    Index created.
    
    SCOTT@orcl_11gR2> -- variables:
    SCOTT@orcl_11gR2> VARIABLE employeeid NUMBER
    SCOTT@orcl_11gR2> EXEC :employeeid := 1
    
    PL/SQL procedure successfully completed.
    
    SCOTT@orcl_11gR2> VARIABLE search VARCHAR2(100)
    SCOTT@orcl_11gR2> EXEC :search := 'highway'
    
    PL/SQL procedure successfully completed.
    
    SCOTT@orcl_11gR2> -- query:
    SCOTT@orcl_11gR2> SET AUTOTRACE ON EXPLAIN
    SCOTT@orcl_11gR2> SELECT SCORE(1), d.*
      2  FROM   duns d
      3  WHERE  CONTAINS
      4             (text_key,
      5              :search || ' AND ' ||
      6              :employeeid || ' WITHIN emp_id',
      7              1) > 0
      8  /
    
      SCORE(1)   DUNS_LOC BUSINESS_NAME   BUSINESS_NAME2  ADDRESS_LINE                   CITY            ST BUSINESS_PHONE
    ---------- ---------- --------------- --------------- ------------------------------ --------------- -- ---------------
    CONTACT_NAME    CONTACT_TITLE   T
    --------------- --------------- -
             3          1                                 highway
    
    1 row selected.
    
    Execution Plan
    ----------------------------------------------------------
    Plan hash value: 2241294508
    
    --------------------------------------------------------------------------------------------------
    | Id  | Operation                   | Name               | Rows  | Bytes | Cost (%CPU)| Time     |
    --------------------------------------------------------------------------------------------------
    |   0 | SELECT STATEMENT            |                    |    38 |  1102 |    12   (0)| 00:00:01 |
    |   1 |  TABLE ACCESS BY INDEX ROWID| DUNS               |    38 |  1102 |    12   (0)| 00:00:01 |
    |*  2 |   DOMAIN INDEX              | DUNS_CONTEXT_INDEX |       |       |     4   (0)| 00:00:01 |
    --------------------------------------------------------------------------------------------------
    
    Predicate Information (identified by operation id):
    ---------------------------------------------------
    
       2 - access("CTXSYS"."CONTAINS"("TEXT_KEY",:SEARCH||' AND '||:EMPLOYEEID||' WITHIN
                  emp_id',1)>0)
    
    SCOTT@orcl_11gR2>
    
  • Query performance

    CURSOR c_exercise_list IS
           SELECT
                  DECODE(v_mfd_mask_id ,'Y',' ',o.opt_id) opt_id,
                  DECODE(v_mfd_mask_id ,'Y',' ',o.soc_sec) soc_sec,
                  P.plan_id plan_id, E.exer_id exer_id, E.exer_num,
                  DECODE(G.sar_flag, 0, DECODE(G.plan_type, 0, '1', 1, '2', 2, '3', 3, ' ', 4,'5', 5, '6', 6, '7', 7, '8', 8, '9', '0'), ' ') option_type,
                  TO_CHAR(G.grant_dt, 'YYYYMMDD') grant_dt, TO_CHAR(E.exer_dt, 'YYYYMMDD') exer_dt,
                  E.opts_exer opts_exer,
                  E.mkt_prc   mkt_prc,
                  E.swap_prc  swap_prc,
                  E.shrs_swap shrs_swap, decode(e.exer_type,2,decode(xe.cash_partial,'Y','A','2'),TO_CHAR(E.exer_type)) exer_type,
                  E.sar_shrs  sar_shrs,
                  NVL(ROUND(((xe.sar_shrs_withld_optcost - (e.opts_exer * g.opt_prc) / e.mkt_prc) * e.mkt_prc),2),0)+e.sar_cash sar_cash,
                  NVL(f.fixed_fee1,0) fixed_fee1,
                  NVL(f.fixed_fee2,0) fixed_fee2,
                  NVL(f.fixed_fee3,0) fixed_fee3,
                  NVL(f.commission,0) commission,
                  NVL(f.sec_fee,0)    sec_fee,
                  NVL(f.fees_paid,0)  fees_paid,
                  NVL(ct.amount,0)     cash_tend,
                  E.shrs_tend  shrs_tend, G.grant_id grant_id, NVL(G.grant_cd, ' ') grant_cd,
                  NVL(xg.child_symbol,' ') child_symbol,
                  NVL(xg.opt_gain_deferred_flag,'N') defer_flag,
                  o.opt_num opt_num,
                  --XO.new_ssn,
                  DECODE(v_mfd_mask_id ,'Y',' ',xo.new_ssn) new_ssn,
                          xo.use_new_ssn
                  ,xo.tax_verification_eligible tax_verification_eligible
                  ,(SELECT TO_CHAR(MIN(settle_dt),'YYYYMMDD') FROM tb_ml_exer_upload WHERE exer_num = E.exer_num AND user_id=E.user_id AND NVL(settle_dt,TO_DATE('19000101','YYYYMMDD'))>=E.exer_dt) AS settle_dt
                  ,xe.rsu_type  AS rsu_type
                  ,xe.trfbl_det_name AS trfbl_det_name
                  ,o.user_txt1,o.user_txt2,xo.user_txt3,xo.user_txt4,xo.user_txt5,xo.user_txt6,xo.user_txt7
                  ,xo.user_txt8,xo.user_txt9,xo.user_txt10,xo.user_txt11,
                  xo.user_txt12,
                  xo.user_txt13,
                  xo.user_txt14,
                  xo.user_txt15,
                  xo.user_txt16,
                  xo.user_txt17,
                  xo.user_txt18,
                  xo.user_txt19,
                  xo.user_txt20,
                  xo.user_txt21,
                  xo.user_txt22,
                  xo.user_txt23,
                  xo.user_dt2,
                  xo.adj_dt_hire_vt_svc,
                  xo.adj_dt_hire_vt_svc_or,
                  xo.adj_dt_hire_vt_svc_or_dt,
                  xo.severance_plan_code,
                  xo.severance_begin_dt,
                  xo.severance_end_dt,
                  xo.retirement_bridging_dt
                  ,NVL(xg.pu_var_price ,0) v_pu_var_price
                  ,NVL(xe.ficamed_override,'N') v_ficmd_ovrride
                  ,NVL(xe.vest_shrs,0) v_vest_shrs
                  ,NVL(xe.client_exer_id,' ') v_client_exer_id
                  ,(CASE WHEN xg.re_tax_flag = 'Y' THEN pk_xop_reg_outbound.Fn_GetRETaxesWithheld(g.grant_num, E.exer_num, g.plan_type)
                         ELSE 'N'
                     END) re_tax_indicator -- 1.5V
                  ,xe.je_bypass_flag
                  ,xe.sar_shrs_withld_taxes   --Added for SAR july 2010 release
                  ,xe.sar_shrs_withld_optcost --Added for SAR july 2010 release
            FROM
            (SELECT exer.* FROM exercise exer WHERE NOT EXISTS (SELECT s.exer_num FROM suspense s
                WHERE s.exer_num = exer.exer_num AND s.user_id = exer.user_id AND exer.mkt_prc = 0))E,
                grantz G,  xop_grantz xg, optionee o, xop_optionee xo, feeschgd f, cashtendered ct, planz P,xop_exercise xe
            WHERE
                  E.grant_num  = G.grant_num
            AND   E.user_id    = G.user_id
            AND   E.opt_num    = o.opt_num
            AND   E.user_id    = o.user_id
            AND   (G.grant_num = xg.grant_num(+) AND G.user_id=xg.user_id(+))
            AND   (o.opt_num   = xo.opt_num(+)   AND o.user_id=xo.user_id(+))
            AND   E.plan_num = P.plan_num
            AND   E.user_id = P.user_id
            AND   E.exer_num = f.exer_num(+)
            AND   E.user_id = ct.user_id(+)
            AND   E.exer_num = ct.exer_num(+)
            AND   E.user_id = ct.user_id(+)
            AND   E.exer_num=xe.exer_num(+)
            AND   E.user_id=xe.user_id(+)
            AND   G.user_id = USER
            AND NOT EXISTS (
                        SELECT tv.exer_num
                          FROM tb_xop_tax_verification tv--,exercise ex
                         WHERE tv.exer_num = e.exer_num
                           AND tv.user_id = e.user_id
                           AND tv.user_id = v_cms_user
                           AND tv.status_flag IN (0,1,3,4, 5)) -- Not Processed
            ;
    How to tune the query performance, any1 help me to impropve... Thanks in advance

    Published by: BluShadow on February 21, 2013 08:14
    corrected {noformat}
    {noformat} tags. Please read {message:id=9360002} and learn how to post code correctly.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                

    956684 wrote:
    I got the cost of CPU: 458.50 time: 1542.90 therefore anything can capture to improve performance, but there is no applied full table scan to put nothing in the mentioned table. . and most of the columns are index unique scan takes place... someone can help me to find the solution

    His request as "my car doesn't work, care color is gray. Can solve you this problem? »

    Please read the FAQ, I already posted and follow the instructions.

  • Question the use of Oracle query Variables

    Hello

    I am new to Oracle, I tried to extract the data from the Oracle database by using the following query which includes 1 variable SYSDATE_UTS, but when I try to execute the query I get an error. Please let me know what I am doing wrong and how I can fix.

    Error message
    -----
    ORA-06550: line 4, column 1:
    PLS-00428: an INTO clause in this SELECT statement
    -----

    Oracle query

    DECLARE SYSDATE_UTS NUMBER: = (sysdate-to_date('19700101','yyyymmdd')) * 86400;
    BEGIN

    SELECT
    INCIDENT_NUMBER,
    TO_DATE (to_char ((1/86400 * REPORTED_DATE) + to_date ('19700101', 'YYYYMMDD'), "jj/mm/aaaa hh24:mi:ss"), 'hh24:mi:ss dd/mm/yyyy') as REPORTED_DATE_TIME,
    GROUP_TRANSFERS
    LAST_MODIFIED_BY
    , to_date (to_char (to_date ('01011970 ', 'ddmmyyyy') + 1/24/60/60 * LAST_MODIFIED_DATE, "mm/dd/yyyy hh24:mi:ss"), 'hh24:mi:ss dd/mm/yyyy') as LAST_MODIFIED_DATE
    , (to_date (to_char (to_date ('01011970 ', 'ddmmyyyy') + 1/24/60/60 * SYSDATE_UTS, ' mm/dd/yyyy'), ' mm/dd/yyyy'))-(to_date (to_char (+ to_date('19700101','yyyymmdd') + 1/86400 * REPORTED_DATE, ' mm/dd/yyyy'), ' mm/dd/yyyy')) age
    CASE
    WHEN (to_date (to_char (to_date ('01011970 ', 'ddmmyyyy') + 1/24/60/60 * SYSDATE_UTS, ' mm/dd/yyyy'), ' mm/dd/yyyy'))-(to_date (to_char (+ to_date('19700101','yyyymmdd') + 1/86400 * REPORTED_DATE, ' mm/dd/yyyy'), ' mm/dd/yyyy')) BETWEEN 0 AND 1, THEN ' 0 - 1 days
    WHEN (to_date (to_char (to_date ('01011970 ', 'ddmmyyyy') + 1/24/60/60 * SYSDATE_UTS, ' mm/dd/yyyy'), ' mm/dd/yyyy'))-(to_date (to_char (+ to_date('19700101','yyyymmdd') + 1/86400 * REPORTED_DATE, ' mm/dd/yyyy'), ' mm/dd/yyyy')) BETWEEN 2 AND 4 and THEN 2-4 days
    WHEN (to_date (to_char (to_date ('01011970 ', 'ddmmyyyy') + 1/24/60/60 * SYSDATE_UTS, ' mm/dd/yyyy'), ' mm/dd/yyyy'))-(to_date (to_char (+ to_date('19700101','yyyymmdd') + 1/86400 * REPORTED_DATE, ' mm/dd/yyyy'), ' mm/dd/yyyy')) BETWEEN 5 AND 9, THEN 5-9 days
    WHEN (to_date (to_char (to_date ('01011970 ', 'ddmmyyyy') + 1/24/60/60 * SYSDATE_UTS, ' mm/dd/yyyy'), ' mm/dd/yyyy'))-(to_date (to_char (+ to_date('19700101','yyyymmdd') + 1/86400 * REPORTED_DATE, ' mm/dd/yyyy'), ' mm/dd/yyyy')) BETWEEN 10 AND 19, THEN 10-19 days
    WHEN (to_date (to_char (to_date ('01011970 ', 'ddmmyyyy') + 1/24/60/60 * SYSDATE_UTS, ' mm/dd/yyyy'), ' mm/dd/yyyy'))-(to_date (to_char (+ to_date('19700101','yyyymmdd') + 1/86400 * REPORTED_DATE, ' mm/dd/yyyy'), ' mm/dd/yyyy')) > 20 THEN ' Days 20 + ".
    ANOTHER "UNKNOWN".
    END AS AGE_GROUP
    OF IncidentDataBase
    and the STATE not in (4,5,6)
    and rownum < 10;
    END;

    If you run this query in sql * plus you can declare a sql * more variable, assign a numeric value according to 'now' and use in your application, i.e.

    SQL > variable NUMBER of SYSDATE_UTS;
    SQL > exec SYSDATE_UTS: = (sysdate-to_date('19700101','yyyymmdd')) * 86400;

    You would then call your request, referring to sql * more variable with a colon as SYSDATE_UTS prior to it (i.e.: SYSDATE_UTS)

    SELECT
    INCIDENT_NUMBER,
    TO_DATE (to_char ((1/86400 * REPORTED_DATE) + to_date ('19700101', 'YYYYMMDD'), "jj/mm/aaaa hh24:mi:ss"), 'hh24:mi:ss dd/mm/yyyy') as REPORTED_DATE_TIME,
    GROUP_TRANSFERS
    LAST_MODIFIED_BY
    , to_date (to_char (to_date ('01011970 ', 'ddmmyyyy') + 1/24/60/60 * LAST_MODIFIED_DATE, "mm/dd/yyyy hh24:mi:ss"), 'hh24:mi:ss dd/mm/yyyy') as LAST_MODIFIED_DATE
    , (to_date (to_char (to_date ('01011970 ', 'ddmmyyyy') + 1/24/60/60 *: SYSDATE_UTS, ' mm/dd/yyyy'), ' mm/dd/yyyy'))-(to_date (to_char (+ to_date('19700101','yyyymmdd') + 1/86400 * REPORTED_DATE, ' mm/dd/yyyy'), ' mm/dd/yyyy')) age
    CASE
    WHEN (to_date (to_char (to_date ('01011970 ', 'ddmmyyyy') + 1/24/60/60 *: SYSDATE_UTS, ' mm/dd/yyyy'), ' mm/dd/yyyy'))-(to_date (to_char (+ to_date('19700101','yyyymmdd') + 1/86400 * REPORTED_DATE, ' mm/dd/yyyy'), ' mm/dd/yyyy')) BETWEEN 0 AND 1, THEN ' 0 - 1 days
    WHEN (to_date (to_char (to_date ('01011970 ', 'ddmmyyyy') + 1/24/60/60 *: SYSDATE_UTS, ' mm/dd/yyyy'), ' mm/dd/yyyy'))-(to_date (to_char (+ to_date('19700101','yyyymmdd') + 1/86400 * REPORTED_DATE, ' mm/dd/yyyy'), ' mm/dd/yyyy')) BETWEEN 2 AND 4 and THEN 2-4 days
    WHEN (to_date (to_char (to_date ('01011970 ', 'ddmmyyyy') + 1/24/60/60 *: SYSDATE_UTS, ' mm/dd/yyyy'), ' mm/dd/yyyy'))-(to_date (to_char (+ to_date('19700101','yyyymmdd') + 1/86400 * REPORTED_DATE, ' mm/dd/yyyy'), ' mm/dd/yyyy')) BETWEEN 5 AND 9, THEN 5-9 days
    WHEN (to_date (to_char (to_date ('01011970 ', 'ddmmyyyy') + 1/24/60/60 *: SYSDATE_UTS, ' mm/dd/yyyy'), ' mm/dd/yyyy'))-(to_date (to_char (+ to_date('19700101','yyyymmdd') + 1/86400 * REPORTED_DATE, ' mm/dd/yyyy'), ' mm/dd/yyyy')) BETWEEN 10 AND 19, THEN 10-19 days
    WHEN (to_date (to_char (to_date ('01011970 ', 'ddmmyyyy') + 1/24/60/60 *: SYSDATE_UTS, ' mm/dd/yyyy'), ' mm/dd/yyyy'))-(to_date (to_char (+ to_date('19700101','yyyymmdd') + 1/86400 * REPORTED_DATE, ' mm/dd/yyyy'), ' mm/dd/yyyy')) > 20 THEN ' Days 20 + ".
    ANOTHER "UNKNOWN".
    END AS AGE_GROUP
    OF IncidentDataBase
    and the STATE not in (4,5,6)
    and rownum<>

    Table stores IncidentDataBase the "dates" in the number of seconds since the epoch unix?

  • The DIMINFO affects query performance?

    Hi all

    A USER_SDO_GEOM_METADATA can. DIMINFO well defined to improve the query performance?


    For all the tables in my system, I have the USER_SDO_GEOM_METADATA view like this:
    DIMINFO
    X; -2147483648; 2147483648; 5TH-5
    Y; -2147483648; 2147483648; 5TH-5
    Z; -2147483648; 2147483648; 5TH-5




    Thanks to you all

    The simple answer is Yes - it provides an alternative and faster I/O path.

    The real question is whether it is supposed that was the data model and its use.

    So your question is similar to asking if a varchar2 column indexing is good or not. The answer is "+ depends on +".

  • SQL query performance

    I have a table that lists the users visits to pages on our website. The information takes the type of structure within our next record table:

    VisitID | IDVisiteur | VisitPage | VisitDate
    Index | UniqueID. VisitPage | Date/time

    I need to get to IDVisiteur who visited in a user defined date range for a report that is to be written, and then get a count the days of separate visit that each user has visited our website. I have a request of work attached that will get me the result set, I want, but it's so _very_ slowly. Query Analyzer it shows that 84% included in table scans. I hope someone has a suggestion on how to optimize it. I am currently working on a MSSQL 8.0 Server, so I have no access to the function of tronque() that I would prefer to use on the dates, but that's a minor inconvenience.

    Thank you
    -Daniel

    Quote:
    Posted by: Dan Bracuk
    You have an index on visitdate?

    Visitdate contains real-time, or are all the parts of the time 0:00? If they are all from 00:00, you don't need the convert function. Otherwise, you might have better luck by selecting all data from your database and using Q of Q for the counties.

    Dan there on this one. Looking at the design table index was absent. Once I added an index my query performance dramatically, improved enough so that I don't have a lot of worries more. Thanks for the suggestion.

    -Daniel

  • MySQL to Oracle query

    Hello World ^^

    I just downloaded Oracle XE and migrated my database from MySQL to Oracle successfully.
    And I'm doing/reviewing my application now especially the query syntax.
    I am facing a problem, I have a request in the form below in MySQL and it works fine but when I tried it at the Oracle XE database, it cannot run :( So I'm asking for help here, I have already searched on the internet but had no luck.

    SELECT A.INVOICEDATE,
    *@Step1:=cast (adddate (A.INVOICEDATE, A.TERMOFPAYMENT) as date) AS STEP1, *.
    *@Step2:=if (@step1 > CURDATE (), A.TOTALAMOUNT, 0) AS STEP2, *.
    *@step3:=if (@step2 <>0,0,IF(DATEDIFF(CURDATE(),@step1) < = 30, A.TOTALAMOUNT, 0)) AS step 3,
    T_invoice FROM has
    WHERE A.STATUS = 'Open'

    I can conclude the problem is based on the variable declaration in Oracle, but I still can't understand.
    What I do in MySQL, it's that I want to fill the variable with the expression/logic so I can use 'than' variable more later in the other part of the query output syntax.
    I used variables to be filled by value due to I can't use / select ALIAS later in the other party.

    So please help to convert to Oracle query syntax. Thank you.

    Oracle and MySql are two different animals. You need to learn SQL and Oracle's PL/SQL.

    Your SQL

    SELECT A.INVOICEDATE,
    @step1:=cast(ADDDATE(A.INVOICEDATE,A.TERMOFPAYMENT) as date) AS STEP1,
    @step2:=IF(@step1>CURDATE(),A.TOTALAMOUNT,0) AS STEP2,
    @step3:=IF(@step20,0,IF(DATEDIFF(CURDATE(),@step1)<=30,A.TOTALAMOUNT,0)) AS STEP3,
    FROM t_invoice A
    WHERE A.STATUS='Open' 
    

    Can be writern as

    select invoicedate,
           step1,
           step2,
           case when step2 = 0
                then case when sysdate-step1 <=30 then A.TOTALAMOUNT else 0 end
           end AS step3
      from (
             select A.invoicedate,
                    A.invoicedate+A.termofpayment step1,
                    case when (A.invoicedate+A.termofpayment) > sysdate then A.totalamount else 0 end as step2,
               from t_invoice A
              where A.status = 'Open'
           )
    
  • Need to improve the performance of oracle query

    Hello
    Currently I wrote the request to get the maximun of XYZ company like this salary

    Select the salary of)
    Select the salary of the employee
    where the company = "XYZ".
    salary desc order)
    where rownum < 2;

    I thought to replace the same with the following query

    Select max (salary)
    the employee
    where the company = "XYZ";

    That one will be faster? can you provide some statistical data. It will be good if you share an oracle for this documentation.

    Thank you
    Khaldi

    Well, that's your requests, your data contained in your database, on your hardware... Anything that can have an impact. So who better to check if there is no difference in performance than yourself?

    Enable SQL tracing, run the statements, then analyze trace (with the help of tkprof or similar) files and look at the differences.

  • Partitioning strategy for the OBIEE query performance

    I use partitioning for the first time and I'll have trouble determining if I partition my fact table in a way that will allow the partition size to work with queries generating OBIEE.  I've set up a simple example using query I wrote to illustrate my problem.  In this example, I have a star with a fact table schema and I join in two dimensions.  My fact table is partitioned on JOB_ID and TIME_ID RANGE LIST and those are the keys that link the two dimensions that I use in this application.


    Select sum (boxbase)

    TEST_RESPONSE_COE_JOB_QTR a

    Join DIM_STUDY C on A.job_id = C.job_id

    Join DIM_TIME B on A.response_time_id = B.time_id

    where C.job_name = "FY14 CSAT"

    and B.fiscal_quarter_name = ' quarter 1';


    What can I say, because the query is in fact done filtering on columns in the dimensions instead of they, the columns in the table, the size isn't actually is happening.  I see actually slightly better performance of a non-partitioned table, even though I wrote this application specifically for partitioning strategy which is now in place.


    If I run the next statement, it runs a lot faster and a plan to explain is very simple and it seems to me that it's size down to a partition of sub as I hoped.  This isn't any query generated by OBIEE how will seem so.


    Select sum (boxbase)

    of TEST_RESPONSE_COE_JOB_QTR

    where job_id = 101123480

    and response_time_id < 20000000;


    Any suggestions?  I get some benefits from the exchange of partition by using this configuration, but if I'm going to sacrifice performance reports then that maybe isn't useful, or at the very least, I would need to get rid of my partitions void if they are not providing any benefit.


    Here are the plans to explain that I got for two queries in my original post:

    Operation

    Name of the object

    Lines

    Bytes

    Cost

    Object node

    In/Out

    PStart

    PStop

    INSTRUCTION SELECT optimizer Mode = ALL_ROWS


    1


    20960





    AGGREGATION OF TRI


    1

    13






    VIEW

    SYS. VW_ST_5BC3A99F

    101 K

    1 M

    20960





    NESTED LOOPS


    101 K

    3 M

    20950





    PARTITION LIST SUBQUERY


    101 K

    2 M

    1281



    KEY (SUBQUERY)

    KEY (SUBQUERY)

    RANGE OF PARTITION SUBQUERY


    101 K

    2 M

    1281



    KEY (SUBQUERY)

    KEY (SUBQUERY)

    CONVERSION OF BITMAP IN ROWID


    101 K

    2 M

    1281





    BITMAP AND









    MERGE TO BITMAP IMAGE









    KEY ITERATION BITMAP









    BUFFER









    INDEX SKIP SCAN

    CISCO_SYSTEMS. DIM_STUDY_UK

    1

    17

    1





    BITMAP INDEX RANGE SCAN

    CISCO_SYSTEMS. FACT_RESPONSE_JOB_ID_BMID_12






    KEY

    KEY

    MERGE TO BITMAP IMAGE









    KEY ITERATION BITMAP









    BUFFER









    VIEW

    CISCO_SYSTEMS.index$ _join$ _052

    546

    8 K

    9





    HASH JOIN









    INDEX RANGE SCAN

    CISCO_SYSTEMS. DIM_TIME_QUARTER_IDX

    546

    8 K

    2





    INDEX FULL SCAN

    CISCO_SYSTEMS. TIME_ID_PK

    546

    8 K

    8





    BITMAP INDEX RANGE SCAN

    CISCO_SYSTEMS. FACT_RESPONSE_TIME_ID_BMIDX_11






    KEY

    KEY

    TABLE ACCESS BY ROWID USER

    CISCO_SYSTEMS. TEST_RESPONSE_COE_JOB_QTR

    1

    15

    19679



    ROWID

    L LINE









    Operation

    Name of the object

    Lines

    Bytes

    Cost

    Object node

    In/Out

    PStart

    PStop

    INSTRUCTION SELECT optimizer Mode = ALL_ROWS


    1


    1641





    AGGREGATION OF TRI


    1

    13






    SIMPLE LIST OF PARTITION


    198 K

    2 M

    1641



    KEY

    KEY

    RANGE OF SINGLE PARTITION


    198 K

    2 M

    1641



    1

    1

    TABLE ACCESS FULL

    CISCO_SYSTEMS. TEST_RESPONSE_COE_JOB_QTR

    198 K

    2 M

    1641



    36

    36


    It seems unreasonable to think that relying on our index in a table partitioned (or partitioned in a way only focused on the help of ETL) can actually work better than partitioning in a way that we could get some size dynamic, but never static pruning?

    Yes - standard tables with indexes can often outperform partitioned tables. It all depends on types of queries and predicates to query which are typically used and the number of rows returned in general.

    Size of the partition eliminates the partitions TOGETHER - regardless of the number of rows in the partition or table. An index, on the other hand, is prohibited if the query predicate needs a significant number of lines since Oracle can determine that the cost is lower simply use close readings and make a full scan.

    A table with 1 million rows and a query predicate who wants 100 K of them probably will not use an index at all. But the same table with two partitions could easily have one of the partitions pruned by the "number of effective lines" only 500 k or less.

    If you are partitioning for performance, you should test your critical queries to make sure partitioning/pruning is effective for them.

    Select sum (boxbase)

    TEST_RESPONSE_COE_JOB_QTR a

    Join DIM_STUDY C on A.job_id = C.job_id

    Join DIM_TIME B on A.response_time_id = B.time_id

    where C.job_name = "FY14 CSAT"

    and B.fiscal_quarter_name = ' quarter 1';

    So, what is a typical value for 'A.response_time_id '? That represents a 'B.time_id '?

    Because a way of providing explicit partition keys may be to use a range of 'response_time_id' of the FACT table rather than a value of 'fiscal_quarter_name' of the DIMENSION table.

    If "1 quarter" could correspond to a range of dates from 01/01/YYYY ' at ' 03/31/yyyy '. "."

    Also, you said that on the partitioning: JOB_ID and TIME_ID

    But if your questions relate mainly to the DATES / TIMES, you might be better use the TIME_ID for PARTITIONS and JOB_ID, if necessary, for the subpartitioning.

    Date range partitioning is one of the most common around.and serves both performance and ease of maintenance (delete/archive old data).

  • Questions after TimesTen first trial: memory footprint and query performance

    Hello!

    I'm testing TimesTen In - Memory Database cache to see if it could help with some ad hoc reports questioned this need too long to run in our Oracle database.

    Here is the configuration:

    1.) TimesTen Server CPU Quad Core 2 with 32 GB of RAM running Windows 2003 x 64.

    2.) put in place two cachegroups read-only: a little for a quick test and the real thing that maps to a table of the database as such:


    Database table looks like:
      CREATE TABLE "TB_BD" 
       (   
       "VALUE" NUMBER NOT NULL ENABLE, 
       "TIME_UTC" TIMESTAMP (6) NOT NULL ENABLE, 
       "ASSIGNED_TO_ID" NUMBER NOT NULL ENABLE, 
       "EVENT_ID" NUMBER, 
       "ID" NUMBER NOT NULL ENABLE, 
       "ID_LABEL" NUMBER NOT NULL ENABLE, 
       "ID_ALARM" NUMBER, 
        CONSTRAINT "PK_TB_BD" PRIMARY KEY ("ID")  
       );
    Oracle database table has 1.367.336.329 lines and table segments are approximately 61 GB, so a medium line takes about 46 bytes.

    Since I have 32 GB in the TimesTen machine, I created the Group cache with a where predicate in the ID column that only the 98.191.284 most recent ranks get in the cache group. In the Oracle database, it is around 4.2 GB of data.

    After the cache loading dssize group returns:
    Command> dssize
    
      PERM_ALLOCATED_SIZE:      26624000
      PERM_IN_USE_SIZE:         19772852
      PERM_IN_USE_HIGH_WATER:   26622892
      TEMP_ALLOCATED_SIZE:      32768
      TEMP_IN_USE_SIZE:         10570
      TEMP_IN_USE_HIGH_WATER:   14192
    
      (Note: the high PERM_IN_USE_HIGH_WATER comes from a first test where I tried to cache too many rows)
    I then ran on the TimesTen machine:
    tisql> select avg(value) from tb_bd;
    She is still going after 10 hours, so I can already tell that the query execution time is not really met my expectations. :-)

    In the Windows Task Manager, I see that tisql constantly use 13% of CPU (= 100% / 8 cores), so that it uses only a carrot, but even he was using all the hearts and the execution time would be 1/8th, it wouldn't meet my expectation. :-)

    I also see in the the Windows Task Manager who becomes slowly higher and higher, currently the 'MemUsage' of my tisq 14FR processl. I believe that it is shared memory mapping that is already mapped by the TimesTen process that has approximately 24 GB mapped. The query is probably 53% through and the total time of queries can be around 20 hours.


    My questions:

    1.) for what I tested, 1 GB of data in the table Oracle needs about 4-5 gigabytes of memory in the TimesTen database. I read a post on the forum who has explained with ' data are optimized for performance, no space in TT ", but I don't quite buy it. A factor of 4-5 means that the CPU must spend 4 to 5 times the amount of data. The data is not compressed in the Oracle database, but it is in its natural binary form. I would like to understand why data takes much more space in TT - like when you have a numeric in Oracle, which TT do with it to make it 4 - 5 times bigger and why does do that?

    2.) regarding the performance of the queries: how long can take even to the base allows to browse about 20 GB of data in memory, number of lines, summarize the NUMBER of a column with a division to get the avg (< column >)? Is there something flawed with my setup?


    Thanks for the ideas!

    Kind regards
    Marcus

    Published by: user11973438 on 06.09.2012 23:27

    I agree that the use of 4 - 5 times more memory than Oracle is far from optimal. Your drawing is unfortunately a little pathological; normally we see more like 2 - 3 times (which is still too really0. There are many internal differences between Oracle and TimesTen in the way data are stored internally. Some are historical, and some are due to the optimization of performance rather than storage efficiency.

    For example:

    1 oracle lines are always variable storage length while TimesTen lines are always of fixed length in storage.

    2. in Oracle, a column defined as NUMBER only occupies the space needed based on the stored value. In TimesTen SEVERAL column always occupies the space to store the maximum possible precision and therefore takes up 22 bytes. You can reduce it by restricting explicitly using NUMBER (n) or NUMBER(n,p).

    3 TimesTen does not support any kind of parallel query within a single data store. All queries will be run using maximum core CPU; Oracle DB supports parallel queries and so it can make a big difference for certain types of application.

    4. NUMBER is implemented in software and is relatively ineffective. Calculating the average of almost 100M lines will take time... You can try to change cela a native binary type (TT_INTEGER, TT_BIGINT, BINARY_DOUBLE depending on your data); This will no doubt give a good improvement (but see point 5 below).

    5. with a database of this size, it is possible that Windows made a lot of paging, while the query is running. I myself also observed on Windows it seems to be a penalty when a process key/maps a page for the first time. You should monitor the paging activity via the task manager that the query is run. All important pagination will really affect the performance. Also, try to execute the query a second time without disconnecting ttIsql this may also show an advantage. On Unix/Linux platforms, we provide an option (MemoryLock == 4) to lock the entire database in physical memory to prevent any paging, but is not available under Windows.

    Chris

  • poor cardinality of bad query performance

    I have a query, whose performance is unsatisfactory.

    It produces (11.2.0.2) next track. The slowest part of the query is the functioning of the UNION-ALL on two fast full scans indexes on PRODUCTS_DATES indices. These clues are in the two tables that make up a notice, V_SALES_ALL.

    The estimation of cardinality for the full scans seems to be out - 100 lines against 78,000,000 and 1 703 000 respectively. The estimate of 100 strangely resembles a defect because the two tables are, as I said, an interior view. In fact, if I break up of the view to its constituent tables, queries run in a tenth of the time.


    How can I fix this misinformation, most likely created by the view?

    I'm reading the right trace?

    Regs

    Johnnie


    Rows Row Source operation
    ------- ---------------------------------------------------
    321 SORT GROUP BY (cr = 6759441 pr = 176970 pw = 176955 time = 480 US cost = 63 = 896 card = 14 size)
    5322875 NESTED LOOPS (cr = 6759441 pr = 176970 pw = 176955 time = 109327744-en)
    5322875 NESTED LOOPS (cr = 241360 pr = 176970 pw = 176955 time = 55796544 US cost = size 62 = 896 card = 14)
    5322875 HASH JOIN (cr = 241049 pr = 176970 pw = 176955 time = 7774711 US cost = size 48 = map 280 = 14)
    80445738 VIEW V_SALES_ALL (cr 241001 pr = 0 pw = time = 0 = 569162368 cost = US size 4 = 1800 map = 200)
    80445738 UNION-ALL (cr = 241001 pr = 0 pw = time 0 = 404890176 en)
    78742696 INDEX FAST FULL SCAN PRODUCTS_DATES_IDX (cr = 235954 pr = 0 pw = time 0 = 85524904 US cost = size 2 = 900 card = 100) (object id 221975)
    1703042 INDEX FAST FULL SCAN PRODUCTS_DATES_IDX_HARD (cr = 5047 pr = 0 pw = time 0 = 1850486 US cost = size 2 = 900 card = 100) (object id 241720)
    2238 VIEW index$ _join$ _003 (cr = 48 pr = 0 pw = time 0 = US cost = size 44 14474 = 24618 card = 2238)
    JOIN by HASH 2238 (cr = 48 pr = 0 pw = time 0 = 9737 US)
    2238 PRODUCTS_GF_INDEX2 INDEX RANGE SCAN (cr = 8 pr = 0 pw = time 0 = 2609 US cost = size 6 = 24618 card = 2238) (object id 255255)
    16206 INDEX FAST FULL SCAN PRODUCTS_GF_PK (cr = 40 pr = 0 pw = time 0 = 20415 US cost = size 45 = 24618 card = 2238) (object id 255253)
    5322875 INDEX UNIQUE SCAN DATES_PK (cr = 311 pr = 0 pw = time 0 = 0 US cost = 0 size = 0 = 1 card) (object id 151306)
    5322875 ACCESS BY ROWID DATES TABLE INDEX (cr 6518081 pr = 0 pw = time = 0 = 0 US cost = 1 size = 44 = 1 card)


    Implementation plan of lines
    ------- ---------------------------------------------------
    0 SELECT STATEMENT MODE: FIRST_ROWS
    321 TRI (GROUP BY)
    5322875-HASH JOIN
    TABLE 5322875 ACCESS MODE: ANALYZED (FULL) OF "DATES" (TABLE)
    5322875-HASH JOIN
    80445738 VIEW OF "index$ _join$ _003 ' (VIEW)
    80445738-HASH JOIN
    MODE 78742696 INDEX: SCANNED (SCAN INTERVAL) OF
    "PRODUCTS_GF_INDEX2" (INDEX)
    MODE 1703042 INDEX: ANALYZED (FULL SCAN) OF
    "PRODUCTS_GF_PK" ((UNIQUE) INDEX)
    2238 VIEW OF "V_SALES_ALL" (VIEW)
    2238 UNION-ALL
    INDEX 2238 MODE: ANALYZED (COMPLETE ANALYSIS) OF
    "PRODUCTS_DATES_IDX" (INDEX)
    HOW TO INDEX 16206: ANALYZED (COMPLETE ANALYSIS) OF
    "PRODUCTS_DATES_IDX_HARD" (INDEX)

    Johnnie d wrote:
    I have a query, whose performance is unsatisfactory.

    It produces (11.2.0.2) next track. The slowest part of the query is the functioning of the UNION-ALL on two fast full scans indexes on PRODUCTS_DATES indices. These clues are in the two tables that make up a notice, V_SALES_ALL.

    The estimation of cardinality for the full scans seems to be out - 100 lines against 78,000,000 and 1 703 000 respectively. The estimate of 100 strangely resembles a defect because the two tables are, as I said, an interior view. In fact, if I break up of the view to its constituent tables, queries run in a tenth of the time.

    Implementation plan of lines
    ------- ---------------------------------------------------
    0 SELECT STATEMENT MODE: FIRST_ROWS

    You run with optimizer_mode = first_rows_100?

    If yes then you may have found a bug in the code of first_rows_N. 100 seem to have been pushed inside the view in a way that has made Oracle to the full index full scans while only "intend" to find 100 rows in each table. There catches the limit of 100 as the actual limit in deciding which online source to use as the hash and which will serve to the probe.

    If you want the entire result set, or a large part of it, you could add the all_rows education indicator.

    Concerning
    Jonathan Lewis
    http://jonathanlewis.WordPress.com
    Author: core Oracle

  • Will there be any tools avialable to the on query performance tuning

    Hello

    How to tune a database query?
    Suppose that there are basic query "select * from emp where empid = '1101' ';"

    Y at - it all avilabale tools to suggest performance Tuning on a query?

    How can I resolve this application, and what is the best approach on this?

    Please share your ideas and thanks.

    Oracle provides tools such as SQL Trace and TKPROF. For the information on a SQL query.

    But basically, you should know how oracle works. You must be aware of the different access plans and know why they are being used.

    You need to know when to use an index and when not to use a.

    There are many more. Best thing for you would be to start reading the document.

  • Developer SQL vs TOAD - query performance issue

    Someone pointed out the same queries are run slower in SQL Developer and TOAD. I'm curious on this issue, since I understand Java is 'slow', but I can't find another thread on this point. I do not use TOAD, so I can't compare...

    Can it be linked to the amount of data returned by the query? What could be the other reasons for the SQL Dev works more slowly with a similar query?

    Thank you
    Attila

    It occurs to me also that TOAD always uses the equivalent of the 'thick' JDBC driver Developer SQL can use 'thin' driver or the 'thick' driver, but the connections are usually configured with the pilot "thin", since you need an Oracle client to use the 'thick' driver

    The difference is that the 'thin' drivers are written entirely in Java, but 'thick' drivers are written with only a small Java that calls the native executable (that's why you need an Oracle client) to do most of the work. In theory, a thick driver is faster because the code of the object should not be interpreted by the JAVA virtual machine. However, I heard that the performance difference is not that big. The only way to know for sure is to set up a connection with SQL Developer to use thick driver and see if it is faster (I would use a stopwatch).

    Correct me if I'm wrong, but I think that if you use 'TNS' as your type of connection, Developer SQL use thick driver, while someone is using the default value, the type of ' basic' connection the thin driver. Otherwise, you need to use the connection type 'Advanced' and type in the JDBC URL custom for the thick driver.

Maybe you are looking for

  • Problem with the USB ports, coast and Bluetooth in Satellite A100-237

    Hello, I own a laptop Satellite A100-237 and I have an annoying problem for quite a while now. The two USB ports in the side as well as the Bluetooth device will not work. What is the bluetooth device is it is simply not recognized by the system, as

  • Satellite A100 freezes

    Hello world Sorry for my English but I'm French. I'll try to do my best to describe my problem. I bought Satellite A100 2 months ago.After I completed the installation of Vista, I changed the partition of my hard disk, I put a few MB on my my d: C:I

  • new type of fraud for iTunes?  !!!!!

    In my view, that there is a new type of fraud on iTunes. I recently received an email to my iCloud saying address my "iTunes account has been suspended and I have to re - authorize within 48 hours. He asks then fill in account information, etc.. Need

  • Address book does not load in OutLook Express

    Operation of a limited account, Outlook Express cannot open the address book withthe following messages:(1) the address book failed to load. Outlook Express s wrongconfigured, please re-install.(2) unable to open the address book. The address book ca

  • BEFSR41 Ver 3 connection to the modem Motorola 2210 problem

    I have a simple (I hope) home office network configuration.  I have a router Linksys BEFSR41 Ver 3, a Vonage phone device, a couple of computers and printers all hooked into the router.  The problem appeared when my old modem is dead.  I replaced the