Very slow query on xml db objects

Hi, I'm a dba (new to xml db) trying to diagnose some very slow queries against xml tables. The following takes 2 + hours to return a count of ~700,000 records. We have some that take 10-15 hours.
select count(*)
from MEDTRONICCRM a, table(xmlsequence(extract(value(a),'/MedtronicCRM/Counters/
Histogram'))) b ,
table(xmlsequence(extract(value(b),'/Histogram/Row'))) c, table(xmlsequence(extract(value(c),'/Row/Column'))) d
The explain plan from a tkprof looks like this:
Rows Row Source Operation
1 SORT AGGREGATE (cr=1586294 r=27724 w=0 time=334399181 us)
761020 NESTED LOOPS (cr=1586294 r=27724 w=0 time=6285597846 us)
209395 NESTED LOOPS (cr=1586294 r=27724 w=0 time=1294406875 us)
16864 NESTED LOOPS (cr=1586294 r=27724 w=0 time=188247898 us)
544 TABLE ACCESS FULL OBJ#(26985) (cr=1993 r=548 w=0 time=171380 us)
16864 COLLECTION ITERATOR PICKLER FETCH (cr=0 r=0 w=0 time=82831582 us)
209395 COLLECTION ITERATOR PICKLER FETCH (cr=0 r=0 w=0 time=939691917 us)
761020 COLLECTION ITERATOR PICKLER FETCH (cr=0 r=0 w=0 time=3399611143 us)
I noticed the following statemnt in a previous thread:
"Indexing is not the answer here... The problem is the storage model. You are current storing all of the collections as serialized lobs. This means that all manipluation of the collection is done in memory. We need to store the collections as nested tables to get peformant queries on them. You do this by using the store VARRAY as table clause to control which collections are stored as nested tables. "
Could this be the problem? How do I tell which storage model we are using.
Thanks ,
Heath Henjum

With 10g I get the following
SQL> begin
2 dbms_xmlschema.registerSchema
3 (
4 schemaURL => '&3',
5 schemaDoc => xdbURIType('/home/&1/xsd/&4').getClob(),
6 local => TRUE,
7 genTypes => TRUE,
8 genBean => FALSE,
9 genTables => &5
10 );
11 end;
12 /
old 4: schemaURL => '&3',
new 4: schemaURL => 'MedtronicCRM.xsd',
old 5: schemaDoc => xdbURIType('/home/&1/xsd/&4').getClob(),
new 5: schemaDoc => xdbURIType('/home/OTNTEST/xsd/MedtronicCRM.xsd').getClob(),
old 9: genTables => &5
new 9: genTables => TRUE
begin
ERROR at line 1:
ORA-31154: invalid XML document
ORA-19202: Error occurred in XML processing
LSX-00175: a complex base within "simpleContent" must have simple content
ORA-06512: at "XDB.DBMS_XMLSCHEMA_INT", line 17
ORA-06512: at "XDB.DBMS_XMLSCHEMA", line 26
ORA-06512: at line 2
SQL> quit
Disconnected from Oracle Database 10g Enterprise Edition Release 10.1.0.3.0 - Production
With the Partitioning, OLAP and Data Mining options

Similar Messages

  • Very Slow Query with CTE inner join

    I have 2 tables (heavily simplified here to show relevant columns):
    CREATE TABLE tblCharge
    (ChargeID int NOT NULL,
    ParentChargeID int NULL,
    ChargeName varchar(200) NULL)
    CREATE TABLE tblChargeShare
    (ChargeShareID int NOT NULL,
    ChargeID int NOT NULL,
    TotalAmount money NOT NULL,
    TaxAmount money NULL,
    DiscountAmount money NULL,
    CustomerID int NOT NULL,
    ChargeShareStatusID int NOT NULL)
    I have a very basic View to Join them:
    CREATE VIEW vwBASEChargeShareRelation as
    Select c.ChargeID, ParentChargeID, s.CustomerID, s.TotalAmount, isnull(s.TaxAmount, 0) as TaxAmount, isnull(s.DiscountAmount, 0) as DiscountAmount
    from tblCharge c inner join tblChargeShare s
    on c.ChargeID = s.ChargeID Where s.ChargeShareStatusID < 3
    GO
    I then have a view containing a CTE to get the children of the Parent Charge:
    ALTER VIEW [vwChargeShareSubCharges] AS
    WITH RCTE AS
    SELECT ParentChargeId, ChargeID, 1 AS Lvl, ISNULL(TotalAmount, 0) as TotalAmount, ISNULL(TaxAmount, 0) as TaxAmount,
    ISNULL(DiscountAmount, 0) as DiscountAmount, CustomerID, ChargeID as MasterChargeID
    FROM vwBASEChargeShareRelation Where ParentChargeID is NULL
    UNION ALL
    SELECT rh.ParentChargeID, rh.ChargeID, Lvl+1 AS Lvl, ISNULL(rh.TotalAmount, 0), ISNULL(rh.TaxAmount, 0), ISNULL(rh.DiscountAmount, 0) , rh.CustomerID
    , rc.MasterChargeID
    FROM vwBASEChargeShareRelation rh
    INNER JOIN RCTE rc ON rh.PArentChargeID = rc.ChargeID and rh.CustomerID = rc.CustomerID
    Select MasterChargeID as ChargeID, CustomerID, Sum(TotalAmount) as TotalCharged, Sum(TaxAmount) as TotalTax, Sum(DiscountAmount) as TotalDiscount
    from RCTE
    Group by MasterChargeID, CustomerID
    GO
    So far so good, I can query this view and get the total cost for a line item including all children.
    The problem occurs when I join this table. The query:
    Select t.* from vwChargeShareSubCharges t
    inner join
    tblChargeShare s
    on t.CustomerID = s.CustomerID
    and t.MasterChargeID = s.ChargeID
    Where s.ChargeID = 1291094
    Takes around 30 ms to return a result (tblCharge and Charge Share have around 3.5 million records).
    But the query:
    Select t.* from vwChargeShareSubCharges t
    inner join
    tblChargeShare s
    on t.CustomerID = s.CustomerID
    and t.MasterChargeID = s.ChargeID
    Where InvoiceID = 1045854
    Takes around 2 minutes to return a result - even though the only charge with that InvoiceID is the same charge as the one used in the previous query.
    The same thing occurs if I do the join in the same query that the CTE is defined in.
    I ran the execution plan for each query. The first (fast) query looks like this:
    The second(slow) query looks like this:
    I am at a loss, and my skills at decoding execution plans to resolve this are lacking.
    I have separate indexes on tblCharge.ChargeID, tblCharge.ParentChargeID, tblChargeShare.ChargeID, tblChargeShare.InvoiceID, tblChargeShare.ChargeShareStatusID
    Any ideas? Tested on SQL 2008R2 and SQL 2012

    >> The database is linked [sic] to an established app and the column and table names can't be changed. <<
    Link? That is a term from pointer chains and network databases, not SQL. I will guess that means the app came back in the old pre-RDBMS days and you are screwed. 
    >> I am not too worried about the money field [sic], this is used for money and money based calculations so the precision and rounding are acceptable at this level. <<
    Field is a COBOL concept; columns are totally different. MONEY is how Sybase mimics the PICTURE clause that puts currency signs, commas, period, etc in a COBOL money field. 
    Using more than one operation (multiplication or division) on money columns will produce severe rounding errors. A simple way to visualize money arithmetic is to place a ROUND() function calls after 
    every operation. For example,
    Amount = (Portion / total_amt) * gross_amt
    can be rewritten using money arithmetic as:
    Amount = ROUND(ROUND(Portion/total_amt, 4) * 
    gross_amt, 4)
    Rounding to four decimal places might not seem an 
    issue, until the numbers you are using are greater 
    than 10,000. 
    BEGIN
    DECLARE @gross_amt MONEY,
     @total_amt MONEY,
     @my_part MONEY,
     @money_result MONEY,
     @float_result FLOAT,
     @all_floats FLOAT;
     SET @gross_amt = 55294.72;
     SET @total_amt = 7328.75;
     SET @my_part = 1793.33;
     SET @money_result = (@my_part / @total_amt) * 
    @gross_amt;
     SET @float_result = (@my_part / @total_amt) * 
    @gross_amt;
     SET @Retult3 = (CAST(@my_part AS FLOAT)
     / CAST( @total_amt AS FLOAT))
     * CAST(FLOAT, @gross_amt AS FLOAT);
     SELECT @money_result, @float_result, @all_floats;
    END;
    @money_result = 13525.09 -- incorrect
    @float_result = 13525.0885 -- incorrect
    @all_floats = 13530.5038673171 -- correct, with a -
    5.42 error 
    >> The keys are ChargeID(int, identity) and ChargeShareID(int, identity). <<
    Sorry, but IDENTITY is not relational and cannot be a key by definition. But it sure works just like a record number in your old COBOL file system. 
    >> .. these need to be int so that they are assigned by the database and unique. <<
    No, the data type of a key is not determined by physical storage, but by logical design. IDENTITY is the number of a parking space in a garage; a VIN is how you identify the automobile. 
    >> What would you recommend I use as keys? <<
    I do not know. I have no specs and without that, I cannot pull a Kabbalah number from the hardware. Your magic numbers can identify Squids, Automobile or Lady Gaga! I would ask the accounting department how they identify a charge. 
    >> Charge_Share_Status_ID links [sic] to another table which contains the name, formatting [sic] and other information [sic] or a charge share's status, so it is both an Id and a status. <<
    More pointer chains! Formatting? Unh? In RDBMS, we use a tiered architecture. That means display formatting is in a presentation layer. A properly created table has cohesion – it does one and only one data element. A status is a state of being that applies
    to an entity over a period time (think employment, marriage, etc. status if that is too abstract). 
    An identifier is based on the Law of Identity from formal logic “To be is to be something in particular” or “A is A” informally. There is no entity here! The Charge_Share_Status table should have the encoded values for a status and perhaps a description if
    they are unclear. If the list of values is clear, short and static, then use a CHECK() constraint. 
    On a scale from 1 to 10, what color is your favorite letter of the alphabet? Yes, this is literally that silly and wrong. 
    >> I understand what a CTE is; is there a better way to sum all children for a parent hierarchy? <<
    There are many ways to represent a tree or hierarchy in SQL.  This is called an adjacency list model and it looks like this:
    CREATE TABLE OrgChart 
    (emp_name CHAR(10) NOT NULL PRIMARY KEY, 
     boss_emp_name CHAR(10) REFERENCES OrgChart(emp_name), 
     salary_amt DECIMAL(6,2) DEFAULT 100.00 NOT NULL,
     << horrible cycle constraints >>);
    OrgChart 
    emp_name  boss_emp_name  salary_amt 
    ==============================
    'Albert'    NULL    1000.00
    'Bert'    'Albert'   900.00
    'Chuck'   'Albert'   900.00
    'Donna'   'Chuck'    800.00
    'Eddie'   'Chuck'    700.00
    'Fred'    'Chuck'    600.00
    This approach will wind up with really ugly code -- CTEs hiding recursive procedures, horrible cycle prevention code, etc.  The root of your problem is not knowing that rows are not records, that SQL uses sets and trying to fake pointer chains with some
    vague, magical non-relational "id".  
    This matches the way we did it in old file systems with pointer chains.  Non-RDBMS programmers are comfortable with it because it looks familiar -- it looks like records and not rows.  
    Another way of representing trees is to show them as nested sets. 
    Since SQL is a set oriented language, this is a better model than the usual adjacency list approach you see in most text books. Let us define a simple OrgChart table like this.
    CREATE TABLE OrgChart 
    (emp_name CHAR(10) NOT NULL PRIMARY KEY, 
     lft INTEGER NOT NULL UNIQUE CHECK (lft > 0), 
     rgt INTEGER NOT NULL UNIQUE CHECK (rgt > 1),
      CONSTRAINT order_okay CHECK (lft < rgt));
    OrgChart 
    emp_name         lft rgt 
    ======================
    'Albert'      1   12 
    'Bert'        2    3 
    'Chuck'       4   11 
    'Donna'       5    6 
    'Eddie'       7    8 
    'Fred'        9   10 
    The (lft, rgt) pairs are like tags in a mark-up language, or parens in algebra, BEGIN-END blocks in Algol-family programming languages, etc. -- they bracket a sub-set.  This is a set-oriented approach to trees in a set-oriented language. 
    The organizational chart would look like this as a directed graph:
                Albert (1, 12)
        Bert (2, 3)    Chuck (4, 11)
                       /    |   \
                     /      |     \
                   /        |       \
                 /          |         \
            Donna (5, 6) Eddie (7, 8) Fred (9, 10)
    The adjacency list table is denormalized in several ways. We are modeling both the Personnel and the Organizational chart in one table. But for the sake of saving space, pretend that the names are job titles and that we have another table which describes the
    Personnel that hold those positions.
    Another problem with the adjacency list model is that the boss_emp_name and employee columns are the same kind of thing (i.e. identifiers of personnel), and therefore should be shown in only one column in a normalized table.  To prove that this is not
    normalized, assume that "Chuck" changes his name to "Charles"; you have to change his name in both columns and several places. The defining characteristic of a normalized table is that you have one fact, one place, one time.
    The final problem is that the adjacency list model does not model subordination. Authority flows downhill in a hierarchy, but If I fire Chuck, I disconnect all of his subordinates from Albert. There are situations (i.e. water pipes) where this is true, but
    that is not the expected situation in this case.
    To show a tree as nested sets, replace the nodes with ovals, and then nest subordinate ovals inside each other. The root will be the largest oval and will contain every other node.  The leaf nodes will be the innermost ovals with nothing else inside them
    and the nesting will show the hierarchical relationship. The (lft, rgt) columns (I cannot use the reserved words LEFT and RIGHT in SQL) are what show the nesting. This is like XML, HTML or parentheses. 
    At this point, the boss_emp_name column is both redundant and denormalized, so it can be dropped. Also, note that the tree structure can be kept in one table and all the information about a node can be put in a second table and they can be joined on employee
    number for queries.
    To convert the graph into a nested sets model think of a little worm crawling along the tree. The worm starts at the top, the root, makes a complete trip around the tree. When he comes to a node, he puts a number in the cell on the side that he is visiting
    and increments his counter.  Each node will get two numbers, one of the right side and one for the left. Computer Science majors will recognize this as a modified preorder tree traversal algorithm. Finally, drop the unneeded OrgChart.boss_emp_name column
    which used to represent the edges of a graph.
    This has some predictable results that we can use for building queries.  The root is always (left = 1, right = 2 * (SELECT COUNT(*) FROM TreeTable)); leaf nodes always have (left + 1 = right); subtrees are defined by the BETWEEN predicate; etc. Here are
    two common queries which can be used to build others:
    1. An employee and all their Supervisors, no matter how deep the tree.
     SELECT O2.*
       FROM OrgChart AS O1, OrgChart AS O2
      WHERE O1.lft BETWEEN O2.lft AND O2.rgt
        AND O1.emp_name = :in_emp_name;
    2. The employee and all their subordinates. There is a nice symmetry here.
     SELECT O1.*
       FROM OrgChart AS O1, OrgChart AS O2
      WHERE O1.lft BETWEEN O2.lft AND O2.rgt
        AND O2.emp_name = :in_emp_name;
    3. Add a GROUP BY and aggregate functions to these basic queries and you have hierarchical reports. For example, the total salaries which each employee controls:
     SELECT O2.emp_name, SUM(S1.salary_amt)
       FROM OrgChart AS O1, OrgChart AS O2,
            Salaries AS S1
      WHERE O1.lft BETWEEN O2.lft AND O2.rgt
        AND S1.emp_name = O2.emp_name 
       GROUP BY O2.emp_name;
    4. To find the level and the size of the subtree rooted at each emp_name, so you can print the tree as an indented listing. 
    SELECT O1.emp_name, 
       SUM(CASE WHEN O2.lft BETWEEN O1.lft AND O1.rgt 
       THEN O2.sale_amt ELSE 0.00 END) AS sale_amt_tot,
       SUM(CASE WHEN O2.lft BETWEEN O1.lft AND O1.rgt 
       THEN 1 ELSE 0 END) AS subtree_size,
       SUM(CASE WHEN O1.lft BETWEEN O2.lft AND O2.rgt
       THEN 1 ELSE 0 END) AS lvl
      FROM OrgChart AS O1, OrgChart AS O2
     GROUP BY O1.emp_name;
    5. The nested set model has an implied ordering of siblings which the adjacency list model does not. To insert a new node, G1, under part G.  We can insert one node at a time like this:
    BEGIN ATOMIC
    DECLARE rightmost_spread INTEGER;
    SET rightmost_spread 
        = (SELECT rgt 
             FROM Frammis 
            WHERE part = 'G');
    UPDATE Frammis
       SET lft = CASE WHEN lft > rightmost_spread
                      THEN lft + 2
                      ELSE lft END,
           rgt = CASE WHEN rgt >= rightmost_spread
                      THEN rgt + 2
                      ELSE rgt END
     WHERE rgt >= rightmost_spread;
     INSERT INTO Frammis (part, lft, rgt)
     VALUES ('G1', rightmost_spread, (rightmost_spread + 1));
     COMMIT WORK;
    END;
    The idea is to spread the (lft, rgt) numbers after the youngest child of the parent, G in this case, over by two to make room for the new addition, G1.  This procedure will add the new node to the rightmost child position, which helps to preserve the idea
    of an age order among the siblings.
    6. To convert a nested sets model into an adjacency list model:
    SELECT B.emp_name AS boss_emp_name, E.emp_name
      FROM OrgChart AS E
           LEFT OUTER JOIN
           OrgChart AS B
           ON B.lft
              = (SELECT MAX(lft)
                   FROM OrgChart AS S
                  WHERE E.lft > S.lft
                    AND E.lft < S.rgt);
    7. To find the immediate parent of a node: 
    SELECT MAX(P2.lft), MIN(P2.rgt)
      FROM Personnel AS P1, Personnel AS P2
     WHERE P1.lft BETWEEN P2.lft AND P2.rgt 
       AND P1.emp_name = @my_emp_name;
    I have a book on TREES & HIERARCHIES IN SQL which you can get at Amazon.com right now. It has a lot of other programming idioms for nested sets, like levels, structural comparisons, re-arrangement procedures, etc. 
    --CELKO-- Books in Celko Series for Morgan-Kaufmann Publishing: Analytics and OLAP in SQL / Data and Databases: Concepts in Practice Data / Measurements and Standards in SQL SQL for Smarties / SQL Programming Style / SQL Puzzles and Answers / Thinking
    in Sets / Trees and Hierarchies in SQL

  • Very Slow Query due to Bitmap Conversion

    I have a strange problem with the performance of a spatial query. If I perform a 'SELECT non_geom_column FROM my_table WHERE complicated_join_query' the result comes back sub-second. However, when I replace the column selected with geometry and perform 'SELECT geom_column FROM my_table WHERE same_complicated_join_query' the response takes over a minute.
    The issue is that in the second case, despite the identical where clause, the explain plan is significantly different. In the 'select geom_column' query there is a BITMAP CONVERSION (TO ROWIDS) which accounts for all of the extra time, where as in the 'select other_column' query that conversion is replaced with TABLE ACCESS (BY INDEX ROWID) which is near instant.
    I have tried putting in some hints, although I do not have much experience with hints, and have also tried nesting the query in various sub-selects. Whatever I try I can not persuade the explain plan to drop the bitmap conversion when I select the geometry column. The full query and an explanation of that query are below. I have run out of things to try, so any help or suggestions at all would be much appreciated.
    Regards,
    Chris
    Explanation and query
    My application allows users to select geometries from a map image through clicking, dragging a box and various other means. The image is then refreshed - highlighting geometries based on the query with which I am having trouble. The user is then able to deselect any of those highlighted geometries, or append others with additional clicks or dragged selections.
    If there are 2 (or any even number of) clicks within the same geometry then that geometry is deselected. Alternatively the geometry could have been selected through an intersection with a dragged box, and then clicked in to deselect - again an even number of selections. Any odd number of selections (i.e. selecting, deselecting, then selecting again) would result in the geometry being selected.
    The application can not know if the multiple user clicks are in the same geometry, as it simply has an image to work with, so all it does is pass all the clicks so far to the database to deal with.
    My query therefore does each spatial point or rectangle query in turn and then appends the unique key for the rows each returned to a list. After performing all of the queries it groups the list by the key and the groups with an odd total are 'selected'. To do this logic in a single where clause I have ended up with nested select statements that are joined with union all commands.
    The query is therefore..
    SELECT
    --the below column (geometry) makes it very slow...replacing it with any non-spatial column takes less than 1/100 of the time - that is my problem!
    geometry
    FROM
    my_table
    WHERE
    primary_key IN
    SELECT primary_key FROM
    SELECT primary_key FROM my_table WHERE
    sdo_relate(geometry, mdsys.sdo_geometry(2003, 81989, NULL, sdo_elem_info_array(1, 1003, 3), sdo_ordinate_array( rectangle co-ords )), 'mask=anyinteract') = 'TRUE'
    UNION ALL SELECT primary_key FROM my_table WHERE
    sdo_relate(geometry, mdsys.sdo_geometry(2001, 81989, sdo_point_type( point co-ords , NULL), NULL, NULL), 'mask=anyinteract') = 'TRUE'
    --potentially more 'union all select...' here
    GROUP BY primary_key HAVING mod(count(*),2) = 1     
    AND
    --the below is the bounding rectangle of the whole image to be returned
    sdo_filter(geometry, mdsys.sdo_geometry(2003, 81989, NULL, sdo_elem_info_array(1, 1003, 3), sdo_ordinate_array( outer rectangle co-ords )), 'mask=anyinteract') = 'TRUE'

    Hi
    Thanks for the reply. After a lot more googling- it turns out this is a general Oracle problem and is not solely related to use of the GEOMETRY column. It seems that sometimes, the Oracle optimiser makes an arbitrary decision to do bitmap conversion. No amount of hints will get it to change its mind !
    One person reported a similarly negative change after table statistic collection had run.
    Why changing the columns being retrieved should change the execution path, I do not know.
    We have a numeric primary key which is always set to a positive value. When I added "AND primary_key_column > 0" (a pretty pointless clause) the optimiser changed the way it works and we got it working fast again.
    Chris

  • Stuck on how to improve very slow query without any admin rights

    Hello All,
    I am using the code below to query a very large data table (RH) and a few other joined tables. I am trying to improve the query but I do not have any admin rights and have no idea how to get diagnostic info on how the query is being executed. Apologies for the system specific and probably not easy to read code but I do not have a generic version that anyone could run, and no admin rights so I can not create tables.
    The main part of the code below (subquery R) takes about 10 minutes to run (3 minutes without the date parameters) and the full code (with the two analytic functions on top) below takes an eye watering 30 minutes to run and this is only a subquery of a much larger query so I really need to get this running more quickly. All I want to do is place a cap on the dates, get partitioned row numbers and a lead row value on one of the fields. I really am stuck on how to get this query more efficient. Am I counting things multiple times unnecessarily? How can I make this quicker? Am I committing some cardinal programming sin in using analytic functions on subqueries?
    Apologies for the vaugueness of this code and my questions but I am totally clueless about diagnostics and basically have very limited system access so I'm stuck as to where to go or to look.
    Very grateful for any advice,
    Jon
    SELECT R.*
    , ROW_NUMBER( ) OVER( PARTITION BY R.RTBLE_ID ORDER BY R.EFF_DT DESC, R.CHG_DT DESC ) RN
    , LEAD(R.RTNG_CD,1,0) OVER( PARTITION BY R.RTBLE_ID ORDER BY R.EFF_DT DESC, R.CHG_DT DESC ) RTNG_CD_PREV
    FROM ( SELECT RH.RTNG_ID
    , RH.RTBLE_ID
    , RA.RTNG_ACTN_DESC
    , TYP.RTNG_TYP_DESC
    , RH.RTNG_CD_ID
    , RC.RTNG_CD
    , RH.EFF_DT
    , RH.CHG_DT
    , RAL.RTNG_ALRT_TYP_ID
    , RAL.EFF_DT ALRT_EFF_DT
    , RAL.CHG_DT ALRT_CHG_DT
    , RH.PRV_FLG
    FROM FTCH_RTNG.RTNG_HIST RH
    , FTCH_RTNG.RTNG_ALRT_HIST RAL
    , FII_CORE.RTNG_ACTN RA
    , FTCH_RTNG.RTNG_TYP TYP
    , FII_CORE.RTNG_CD RC
    WHERE RH.RTNG_ACTN_ID = RA.RTNG_ACTN_ID
    AND RH.RTNG_TYP_ID = TYP.RTNG_TYP_ID
    AND RH.RTNG_TYP_ID = RC.RTNG_TYP_ID
    AND RH.RTNG_CD_ID = RC.RTNG_CD_ID
    AND RH.RTNG_ID = RAL.RTNG_ID (+)
    AND RH.DELETE_FLG = 'N'
    AND RH.EFF_DT < TRUNC(CURRENT_DATE,'MM')
    AND RAL.EFF_DT < TRUNC(CURRENT_DATE,'MM')
    )R
    -----

    Thanks so much for replying blueforg, and for pointing out the code markup.
    Our server is in the US and we run our code from London, so it is the local time I am interested in, CURRENT_DATE is merely there to get that and as you suggest is not a column. I want my cap to the first of whatever month I run the code on so I'm happy with that bit of the code (so 1 Oct if I run it today). I'm just surprised at how slow my code becomes when I try and restrict the dates and get the row numbers and next row values.
    This code is actually a subquery used in a much bigger query that I am trying to tidy up and make more efficient. The RN is important as I will eventually be filtering for RN = 1. I didn't post the full query as it is huge,badly written (by me) and and particular to our databases so I'm tackling bits one at a time to cut down on confusion. I'll repost with the RN=1 and the code markup ;)
    I also restricting the RH table directly (SELECT * FROM FTCH_RTNG.RTNG_HIST RH WHERE RH.EFF_DT < TRUNC(CURRENT_DATE,'MM')) and moving the analytic functions into the R subquery but that is very slow as well. I heard that temporary tables are efficient? I'm assuming that with my rubbish priveleges I will not be able to do that. I don't want to take any chances of messing anything up either!
    Jon
    SELECT RT.* FROM
      ( SELECT  R.*
              , ROW_NUMBER( ) OVER( PARTITION BY R.RTBLE_ID ORDER BY R.EFF_DT DESC, R.CHG_DT DESC ) RN    
              , LEAD(R.RTNG_CD,1,0) OVER( PARTITION BY R.RTBLE_ID ORDER BY R.EFF_DT DESC, R.CHG_DT DESC ) RTNG_CD_PREV
        FROM  ( SELECT  RH.RTNG_ID    
                      , RH.RTBLE_ID    
                      , RA.RTNG_ACTN_DESC    
                      , TYP.RTNG_TYP_DESC    
                      , RH.RTNG_CD_ID    
                      , RC.RTNG_CD    
                      , RH.EFF_DT  
                      , RH.CHG_DT 
                      , RAL.RTNG_ALRT_TYP_ID    
                      , RAL.EFF_DT ALRT_EFF_DT    
                      , RAL.CHG_DT ALRT_CHG_DT
                      , RH.PRV_FLG    
                FROM    FTCH_RTNG.RTNG_HIST RH
                      , FTCH_RTNG.RTNG_ALRT_HIST RAL
                      , FII_CORE.RTNG_ACTN RA    
                      , FTCH_RTNG.RTNG_TYP TYP    
                      , FII_CORE.RTNG_CD RC    
                WHERE RH.RTNG_ACTN_ID = RA.RTNG_ACTN_ID    
                AND RH.RTNG_TYP_ID = TYP.RTNG_TYP_ID    
                AND RH.RTNG_TYP_ID = RC.RTNG_TYP_ID    
                AND RH.RTNG_CD_ID = RC.RTNG_CD_ID    
                AND RH.RTNG_ID = RAL.RTNG_ID (+)    
                AND RH.DELETE_FLG = 'N'
                AND RH.EFF_DT < TRUNC(CURRENT_DATE,'MM')
                AND RAL.EFF_DT < TRUNC(CURRENT_DATE,'MM')
                                                          )R  )RT
    WHERE RT.RN = 1-----

  • Very slow query when specifying where clause

    Hi folks:
    I am using SAS with SQL Passthrough for Oracle, however that may be irrelevant to the problem.
    I have a query that I am subsetting based on a series of where clauses, and when I put the clauses into the query, it slows it down tremendously.
    I can pull the entire table and subset it later on in SAS and it is much faster.
    Can someone explain why the SQL subsetting logic runs slower than pulling 18M rows and subsetting later?
    Here is my query - hope this is enough information
    select
    a.loan_number
    , a.CFLRC_CD
    , a.cservno
    , b.cprj_typ
    , a.occ_stat
    , c.state2
    , c.city2
    , e.hstatus
    , e.hcattype
    , e.dqind
    , e.mthsdel
    from
    VEW_LL_ln_1 a
    , vew_ll_ln_2 b
    , VEW_LL_PROP_GEO_CD c
    , vew_ll_ln_actvy_1 e
    where
    a.loan_number = b.loan_number
    and a.loan_number = c.loan_number
    and a.loan_number = e.loan_number
    and e.act_dte = '01-feb-2011'
    and not (occ_stat in ('2','3'))
    and hcattype <> '800'
    and dqind not in ('E','F','G','H')
    and cprj_typ not in ('1','2','3','4','5','16','17','18','19','20','21','22')
    and cflrc_cd <> '2'
    order by
    a.loan_number
    Thanks

    You're in the wrong forum. This is the forum for the SQL Developer tool. You will get better answers in the SQL and PL/SQL forum which is here PL/SQL

  • How to speed up a very slow query creating HTML commands

    Hi, I’m generating HTML code that I will later send via dbmail (@body_format ='HTML'). There are about 11K records in the table and it takes over 9 hours to run. Any suggestions on how to increase throughput? or am I just stuck with it
    declare @html_3 varchar (max) = ' '
    select @@html_3 = @html_3 + '<tr> <td>' + cast (RegionID as varchar) + '</td><td>'
                    + RegionName + '</td><td>'
                     + cast (FileID as varchar) + '</td><td>'
                     + cast (FileNum as varchar) + '</td><td>'
                  + FileStatus + '</td><td>'
         + DeliveryStatus + '</td><td>'
         +TaskName + '</td><td>'
          + cast (EventStartDate as varchar) + '</td><td>'
      + cast (DeliveryEventLogID as varchar) + '</td><td>'
     + DeliveryServer + '</td><td>'
     + IISServer + '</td><td>'
     + UserName + '</td><td>'
     + DeliverEvent + '</td><td>'
     + NotificationEvent + '</td><td>'
     + DeliveryComments + '</td><td>'
                   + PronoComments + '</td></tr>'
    from ##PronoDetailRpt
    print @html_3

    If you have only 11K records, and if what you posted is the entire query, it should take nowhere near 9 hours to complete, even on a wimpy server. It might be that some other process is blocking your global temporary table.  
    Look at the process that is populating the
    ##PronoDetailRpttable. Is that running simultaneously as you are trying to run this query?
    Try selecting a single record from the table. Does that complete in a short time? i.e., run SELECT TOP (1) * FROM ##PronoDetailRpt;
    Run sp_who2 in a separate window while this query is running to see if there is anything blocking this
    query. There is a BlkBy column that will give you this information.
    EDIT: By the way, always specify a length for VARCHAR.  So instead of CAST (RegionID AS VARCHAR) use something like CAST (RegionID AS VARCHAR(32)) where the length is larger than the longest string you expect, or if you don't know how long it
    could be, use CAST (RegionID AS VARCHAR(MAX))

  • Very slow query

    Hi,
    we execute the following :
    select count(*) from mytable.
    We wait more than 20 minutes and then stop. I generated a AWR report for the time it was running :
    Instance Efficiency Percentages (Target 100%)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                Buffer Nowait %:  100.00 ;      Redo NoWait %:  100.00
                Buffer  Hit   %:   84.12 ;   In-memory Sort %:  100.00
                Library Hit   %:   99.47 ;       Soft Parse %:   99.69
             Execute to Parse %:   49.43 ;        Latch Hit %:  100.00
    Parse CPU to Parse Elapsd %:   50.07 ;    % Non-Parse CPU:   97.28
    Shared Pool Statistics        Begin    End
                 Memory Usage %:   78.11 ;  81.58
        % SQL with executions>1:   96.81 ;  95.22
      % Memory for SQL w/exec>1:   90.92 ;  89.73
    Top 5 Timed Events                                         Avg %Total
    ~~~~~~~~~~~~~~~~~~                                        wait   Call
    Event                                 Waits    Time (s)   (ms)   Time Wait Class
    local write wait                  1,104,035         790      1   50.9 ;  User I/O
    db file parallel write              990,897         764      1   49.3 System I/O
    control file parallel write         218,131         228      1   14.7 System I/O
    CPU time                                            134           8.6
    db file sequential read             639,781         107      0    6.9 ;  User I/O
              ------------------------------------------------------------- Can we say that the main problem is writing on disk since we have local write wait and db file parallel write ?
    If not after this AWR report what might be the problem ?
    Thank you.

    Hi;
    What is db version? Please see this
    Regard
    Helios

  • Date insertion from large XML document (clob) into relation table very slow

    Hi Everybody!
    I'm working with Oracle 9.2.0.5 on Microsoft Windows Server 2003 Enterprise Edition.
    The server (a test server) is a Pentium 4 2.8 GHz, 1GB of RAM.
    I use a procedure called PARITOP_TRAITERXMLRESULTMASSE to insert the data contained in the pXMLDOC clob parameter in the table pTABLENAME. (You can see the format of the XML document below). The first step on this procedure is to verify that the XML document is not empty. If not, the procedure needs to add a node in the document, in every <ROW> tag. This added node is named “RST_ID”. It’s the foreign key of each record. I can retrieve the value of each <RST_ID> node in an other table in which the data has been previously added (by the calling procedure). When each of the <ROW> elements has been treated, the PARITOP_INSERTXML procedure is called. This procedure uses DBMS_XMLSAVE.INSERTXML to insert the data contained in the XML document in the specified table.
    (Below, you can see the code of my procedures.)
    With this information, can you tell me why this treatment is very very very slow with a large XML document and how I can improve it?
    Thank you for your help!
    Anne-Marie
    CREATE OR REPLACE PROCEDURE "PARITOP_TRAITERXMLRESULTMASSE" (
    pPRC_ID IN PARITOP_PARC.PRC_ID%TYPE,
    pRST_MONDE IN PARITOP_RESULTAT.RST_MONDE%TYPE,
    pXMLDOC IN CLOB,
    pTABLENAME IN VARCHAR2)
    AS
    Objectif :Insérer le contenu du XML passé en paramètre (pXMLDOC) à la table passée en paramètre (pTABLENAME)
    La table passée en paramètre doit être une table ayant comme clé étrangère le champs "RST_ID" .
    (Le noeud RST_ID est donc ajouté à tous les document XML. Ce rst_id est
    déterminé à partir de la table PARITOP_RESULTAT grâce à pPRC_ID et
    pRstMonde fournis en paramètre)
    result_doc CLOB;
    XMLDOMDOC XDB.DBMS_XMLDOM.DOMDOCUMENT;
    NODE_ROWSET DBMS_XMLDOM.DOMNODE;
    NODE_ROW DBMS_XMLDOM.DOMNODE;
    vUE_ID PARITOP_RESULTAT.UE_ID%TYPE;
    vRST_ID PARITOP_RESULTAT.RST_ID%TYPE;
    nodeList DBMS_XMLDOM.DOMNODELIST;
    BEGIN
    BEGIN
    vUE_ID := 0;
    vRST_ID := 0;
    XMLDOMDOC := DBMS_XMLDOM.NEWDOMDOCUMENT(pXMLDOC);
    IF NOT GESTXML_PKG.FN_PARITOP_DOCUMENT_IS_NULL(XMLDOMDOC) THEN
    NODE_ROWSET := DBMS_XMLDOM.item(DBMS_XMLDOM.GETCHILDNODES (DBMS_XMLDOM.MAKENODE(XMLDOMDOC)),0);
    for i in 0..dbms_xmldom.getLength(DBMS_XMLDOM.getchildnodes(NODE_ROWSET))-1 loop
    NODE_ROW := DBMS_XMLDOM.ITEM(DBMS_XMLDOM.GETCHILDNODES(NODE_ROWSET), i) ;
    nodeList := DBMS_XMLDOM.GETELEMENTSBYTAGNAME(DBMS_XMLDOM.makeelement(NODE_ROW) , 'UE_ID');
    IF vUE_ID <> DBMS_XMLDOM.GETNODEVALUE(DBMS_XMLDOM.GETFIRSTCHILD(DBMS_XMLDOM.ITEM(nodeList, 0))) THEN
    vUE_ID := DBMS_XMLDOM.GETNODEVALUE(DBMS_XMLDOM.GETFIRSTCHILD(DBMS_XMLDOM.ITEM(nodeList, 0)));
    --on ramasse le rst_id
    SELECT RST_ID INTO vRST_ID
    FROM PARITOP_RESULTAT RST
    WHERE RST.PRC_ID = pPRC_ID
    AND RST.UE_ID = vUE_ID
    AND RST.RST_MONDE = pRST_MONDE
    AND RST_A_SUPPRIMER = 0;
    END IF;
    GESTXML_PKG.PARITOP_ADDNODETOROW(XMLDOMDOC, NODE_ROW, 'RST_ID', vRST_ID);
    end loop;
    RESULT_DOC := ' '; --à garder, pour ne pas que ca fasse d'erreur lors du WriteToClob.
    dbms_xmldom.writeToClob(DBMS_XMLDOM.MAKENODE(XMLDOMDOC), RESULT_DOC);
    --Insertion du document XML dans la table "tableName"
    GESTXML_PKG.PARITOP_INSERTXML(RESULT_DOC, pTABLENAME);
    DBMS_XMLDOM.FREEDOCUMENT( XMLDOMDOC);
    end if;
    EXCEPTION
    […exception treatement…]
    END;
    END;
    The format of a XML clob is :
    <ROWSET>
    <ROW>
    <PRC_ID>193</PRC_ID>
    <UE_ID>8781</UE_ID>
    <VEN_ID>6223</VEN_ID>
    <RST_MONDE>0</RST_MONDE>
    <CMP_SELMAN>0</CMP_SELMAN>
    <CMP_INDICESELECTION>92.307692307692307</CMP_INDICESELECTION>
    <CMP_PVRES>94900</CMP_PVRES>
    <CMP_PVAJUSTE>72678.017699115066</CMP_PVAJUSTE>
    <CMP_PVAJUSTEMIN>72678.017699115095</CMP_PVAJUSTEMIN>
    <CMP_PVAJUSTEMAX>72678.017699115037</CMP_PVAJUSTEMAX>
    <CMP_PV>148000</CMP_PV>
    <CMP_VALROLE>129400</CMP_VALROLE>
    <CMP_PVRESECART>4790</CMP_PVRESECART>
    <CMP_PVRHAB>101778.01769911509</CMP_PVRHAB>
    <CMP_UTILISE>1</CMP_UTILISE>
    <CMP_TVM>1</CMP_TVM>
    <CMP_PVA>148000</CMP_PVA>
    </ROW>
    <ROW>
    <PRC_ID>193</PRC_ID>
    <UE_ID>8781</UE_ID>
    <VEN_ID>6235</VEN_ID>
    <RST_MONDE>0</RST_MONDE>
    <CMP_SELMAN>0</CMP_SELMAN>
    <CMP_INDICESELECTION>76.92307692307692</CMP_INDICESELECTION>
    <CMP_PVRES>117800</CMP_PVRES>
    <CMP_PVAJUSTE>118080</CMP_PVAJUSTE>
    <CMP_PVAJUSTEMIN>118080</CMP_PVAJUSTEMIN>
    <CMP_PVAJUSTEMAX>118080</CMP_PVAJUSTEMAX>
    <CMP_PV>172000</CMP_PV>
    <CMP_VALROLE>134800</CMP_VALROLE>
    <CMP_PVRESECART>0</CMP_PVRESECART>
    <CMP_PVRHAB>147180</CMP_PVRHAB>
    <CMP_UTILISE>1</CMP_UTILISE>
    <CMP_TVM>1</CMP_TVM>
    <CMP_PVA>172000</CMP_PVA>
    </ROW>
    </ROWSET>
    PARITOP_COMPARABLE TABLE :
    RST_ID NUMBER(10) NOT NULL,
    VEN_ID NUMBER(10) NOT NULL,
    CMP_SELMAN NUMBER(1) NOT NULL,
    CMP_UTILISE NUMBER(1) NOT NULL,
    CMP_INDICESELECTION FLOAT(53) NOT NULL,
    CMP_PVRES FLOAT(53) NULL,
    CMP_PVAJUSTE FLOAT(53) NULL,
    CMP_PVRHAB FLOAT(53) NULL,
    CMP_TVM FLOAT(53) NULL
    ROCEDURE PARITOP_INSERTXML (xmlDoc IN clob, tableName IN VARCHAR2)
    AS
    insCtx DBMS_XMLSave.ctxType;
    rowss number;
    BEGIN
    --permet d'insérer les champs du XML dans la table passée en paramètre.
    --il suffit que les champs XML aient le même nom que les champs de la table
    BEGIN
    insCtx := DBMS_XMLSave.newContext(tableName); -- get context handle
    DBMS_XMLSAVE.SETDATEFORMAT( insCtx, 'yyyy-MM-dd HH:mm:ss');--attention, case sensitive
    DBMS_XMLSAVE.setIgnoreCase(insCtx, 1);
    rowss := DBMS_XMLSAVE.INSERTXML(insCtx , xmlDoc);
    DBMS_XMLSave.closeContext(insCtx);
    EXCEPTION
    […]
    END;
    END;
    PROCEDURE PARITOP_ADDNODETOROW (
    XMLDOMDOC DBMS_XMLDOM.DOMDOCUMENT,
    NODE_ROW dbms_xmldom.DOMNode,
    NOM_NOEUD VARCHAR2,
    VALEUR_NOEUD VARCHAR2)
    AS
    --PERMET D'AJOUTER UN NOEUD AVEC 1 SEULE VALEUR DANS une ROW D'UN XML.
    --UTILE SURTOUT POUR LES CLÉS ÉTRANGÈRES
    domElemAInserer DBMS_XMLDOM.DOMELEMENT;
    NODE dbms_xmldom.DOMNode;
    NODE_TMP dbms_xmldom.DOMNode;
    BEGIN
    domElemAInserer := DBMS_XMLDOM.createElement(XMLDOMDOC, NOM_NOEUD) ;
    NODE := DBMS_XMLDOM.MAKENODE(domElemAInserer); --cast
    NODE := DBMS_XMLDOM.APPENDCHILD(NODE_ROW,NODE);
    NODE_TMP := DBMS_XMLDOM.MAKENODE(DBMS_XMLDOM.CREATETEXTNODE(XMLDOMDOC, VALEUR_NOEUD ) );
    NODE := DBMS_XMLDOM.APPENDCHILD(NODE,NODE_TMP );
    END;

    Hi Everybody!
    I'm working with Oracle 9.2.0.5 on Microsoft Windows Server 2003 Enterprise Edition.
    The server (a test server) is a Pentium 4 2.8 GHz, 1GB of RAM.
    I use a procedure called PARITOP_TRAITERXMLRESULTMASSE to insert the data contained in the pXMLDOC clob parameter in the table pTABLENAME. (You can see the format of the XML document below). The first step on this procedure is to verify that the XML document is not empty. If not, the procedure needs to add a node in the document, in every <ROW> tag. This added node is named “RST_ID”. It’s the foreign key of each record. I can retrieve the value of each <RST_ID> node in an other table in which the data has been previously added (by the calling procedure). When each of the <ROW> elements has been treated, the PARITOP_INSERTXML procedure is called. This procedure uses DBMS_XMLSAVE.INSERTXML to insert the data contained in the XML document in the specified table.
    (Below, you can see the code of my procedures.)
    With this information, can you tell me why this treatment is very very very slow with a large XML document and how I can improve it?
    Thank you for your help!
    Anne-Marie
    CREATE OR REPLACE PROCEDURE "PARITOP_TRAITERXMLRESULTMASSE" (
    pPRC_ID IN PARITOP_PARC.PRC_ID%TYPE,
    pRST_MONDE IN PARITOP_RESULTAT.RST_MONDE%TYPE,
    pXMLDOC IN CLOB,
    pTABLENAME IN VARCHAR2)
    AS
    Objectif :Insérer le contenu du XML passé en paramètre (pXMLDOC) à la table passée en paramètre (pTABLENAME)
    La table passée en paramètre doit être une table ayant comme clé étrangère le champs "RST_ID" .
    (Le noeud RST_ID est donc ajouté à tous les document XML. Ce rst_id est
    déterminé à partir de la table PARITOP_RESULTAT grâce à pPRC_ID et
    pRstMonde fournis en paramètre)
    result_doc CLOB;
    XMLDOMDOC XDB.DBMS_XMLDOM.DOMDOCUMENT;
    NODE_ROWSET DBMS_XMLDOM.DOMNODE;
    NODE_ROW DBMS_XMLDOM.DOMNODE;
    vUE_ID PARITOP_RESULTAT.UE_ID%TYPE;
    vRST_ID PARITOP_RESULTAT.RST_ID%TYPE;
    nodeList DBMS_XMLDOM.DOMNODELIST;
    BEGIN
    BEGIN
    vUE_ID := 0;
    vRST_ID := 0;
    XMLDOMDOC := DBMS_XMLDOM.NEWDOMDOCUMENT(pXMLDOC);
    IF NOT GESTXML_PKG.FN_PARITOP_DOCUMENT_IS_NULL(XMLDOMDOC) THEN
    NODE_ROWSET := DBMS_XMLDOM.item(DBMS_XMLDOM.GETCHILDNODES (DBMS_XMLDOM.MAKENODE(XMLDOMDOC)),0);
    for i in 0..dbms_xmldom.getLength(DBMS_XMLDOM.getchildnodes(NODE_ROWSET))-1 loop
    NODE_ROW := DBMS_XMLDOM.ITEM(DBMS_XMLDOM.GETCHILDNODES(NODE_ROWSET), i) ;
    nodeList := DBMS_XMLDOM.GETELEMENTSBYTAGNAME(DBMS_XMLDOM.makeelement(NODE_ROW) , 'UE_ID');
    IF vUE_ID <> DBMS_XMLDOM.GETNODEVALUE(DBMS_XMLDOM.GETFIRSTCHILD(DBMS_XMLDOM.ITEM(nodeList, 0))) THEN
    vUE_ID := DBMS_XMLDOM.GETNODEVALUE(DBMS_XMLDOM.GETFIRSTCHILD(DBMS_XMLDOM.ITEM(nodeList, 0)));
    --on ramasse le rst_id
    SELECT RST_ID INTO vRST_ID
    FROM PARITOP_RESULTAT RST
    WHERE RST.PRC_ID = pPRC_ID
    AND RST.UE_ID = vUE_ID
    AND RST.RST_MONDE = pRST_MONDE
    AND RST_A_SUPPRIMER = 0;
    END IF;
    GESTXML_PKG.PARITOP_ADDNODETOROW(XMLDOMDOC, NODE_ROW, 'RST_ID', vRST_ID);
    end loop;
    RESULT_DOC := ' '; --à garder, pour ne pas que ca fasse d'erreur lors du WriteToClob.
    dbms_xmldom.writeToClob(DBMS_XMLDOM.MAKENODE(XMLDOMDOC), RESULT_DOC);
    --Insertion du document XML dans la table "tableName"
    GESTXML_PKG.PARITOP_INSERTXML(RESULT_DOC, pTABLENAME);
    DBMS_XMLDOM.FREEDOCUMENT( XMLDOMDOC);
    end if;
    EXCEPTION
    […exception treatement…]
    END;
    END;
    The format of a XML clob is :
    <ROWSET>
    <ROW>
    <PRC_ID>193</PRC_ID>
    <UE_ID>8781</UE_ID>
    <VEN_ID>6223</VEN_ID>
    <RST_MONDE>0</RST_MONDE>
    <CMP_SELMAN>0</CMP_SELMAN>
    <CMP_INDICESELECTION>92.307692307692307</CMP_INDICESELECTION>
    <CMP_PVRES>94900</CMP_PVRES>
    <CMP_PVAJUSTE>72678.017699115066</CMP_PVAJUSTE>
    <CMP_PVAJUSTEMIN>72678.017699115095</CMP_PVAJUSTEMIN>
    <CMP_PVAJUSTEMAX>72678.017699115037</CMP_PVAJUSTEMAX>
    <CMP_PV>148000</CMP_PV>
    <CMP_VALROLE>129400</CMP_VALROLE>
    <CMP_PVRESECART>4790</CMP_PVRESECART>
    <CMP_PVRHAB>101778.01769911509</CMP_PVRHAB>
    <CMP_UTILISE>1</CMP_UTILISE>
    <CMP_TVM>1</CMP_TVM>
    <CMP_PVA>148000</CMP_PVA>
    </ROW>
    <ROW>
    <PRC_ID>193</PRC_ID>
    <UE_ID>8781</UE_ID>
    <VEN_ID>6235</VEN_ID>
    <RST_MONDE>0</RST_MONDE>
    <CMP_SELMAN>0</CMP_SELMAN>
    <CMP_INDICESELECTION>76.92307692307692</CMP_INDICESELECTION>
    <CMP_PVRES>117800</CMP_PVRES>
    <CMP_PVAJUSTE>118080</CMP_PVAJUSTE>
    <CMP_PVAJUSTEMIN>118080</CMP_PVAJUSTEMIN>
    <CMP_PVAJUSTEMAX>118080</CMP_PVAJUSTEMAX>
    <CMP_PV>172000</CMP_PV>
    <CMP_VALROLE>134800</CMP_VALROLE>
    <CMP_PVRESECART>0</CMP_PVRESECART>
    <CMP_PVRHAB>147180</CMP_PVRHAB>
    <CMP_UTILISE>1</CMP_UTILISE>
    <CMP_TVM>1</CMP_TVM>
    <CMP_PVA>172000</CMP_PVA>
    </ROW>
    </ROWSET>
    PARITOP_COMPARABLE TABLE :
    RST_ID NUMBER(10) NOT NULL,
    VEN_ID NUMBER(10) NOT NULL,
    CMP_SELMAN NUMBER(1) NOT NULL,
    CMP_UTILISE NUMBER(1) NOT NULL,
    CMP_INDICESELECTION FLOAT(53) NOT NULL,
    CMP_PVRES FLOAT(53) NULL,
    CMP_PVAJUSTE FLOAT(53) NULL,
    CMP_PVRHAB FLOAT(53) NULL,
    CMP_TVM FLOAT(53) NULL
    ROCEDURE PARITOP_INSERTXML (xmlDoc IN clob, tableName IN VARCHAR2)
    AS
    insCtx DBMS_XMLSave.ctxType;
    rowss number;
    BEGIN
    --permet d'insérer les champs du XML dans la table passée en paramètre.
    --il suffit que les champs XML aient le même nom que les champs de la table
    BEGIN
    insCtx := DBMS_XMLSave.newContext(tableName); -- get context handle
    DBMS_XMLSAVE.SETDATEFORMAT( insCtx, 'yyyy-MM-dd HH:mm:ss');--attention, case sensitive
    DBMS_XMLSAVE.setIgnoreCase(insCtx, 1);
    rowss := DBMS_XMLSAVE.INSERTXML(insCtx , xmlDoc);
    DBMS_XMLSave.closeContext(insCtx);
    EXCEPTION
    […]
    END;
    END;
    PROCEDURE PARITOP_ADDNODETOROW (
    XMLDOMDOC DBMS_XMLDOM.DOMDOCUMENT,
    NODE_ROW dbms_xmldom.DOMNode,
    NOM_NOEUD VARCHAR2,
    VALEUR_NOEUD VARCHAR2)
    AS
    --PERMET D'AJOUTER UN NOEUD AVEC 1 SEULE VALEUR DANS une ROW D'UN XML.
    --UTILE SURTOUT POUR LES CLÉS ÉTRANGÈRES
    domElemAInserer DBMS_XMLDOM.DOMELEMENT;
    NODE dbms_xmldom.DOMNode;
    NODE_TMP dbms_xmldom.DOMNode;
    BEGIN
    domElemAInserer := DBMS_XMLDOM.createElement(XMLDOMDOC, NOM_NOEUD) ;
    NODE := DBMS_XMLDOM.MAKENODE(domElemAInserer); --cast
    NODE := DBMS_XMLDOM.APPENDCHILD(NODE_ROW,NODE);
    NODE_TMP := DBMS_XMLDOM.MAKENODE(DBMS_XMLDOM.CREATETEXTNODE(XMLDOMDOC, VALEUR_NOEUD ) );
    NODE := DBMS_XMLDOM.APPENDCHILD(NODE,NODE_TMP );
    END;

  • Some body please help about the Inventory FIFO (FIRST IN FISRT OUT ) query is very slow

    I have table ''tran_stock''  to store a transaction (IN-OUT) of the stock. 
    The problem is when the  transaction rows are more than 50000 the query to get the balance
    stock (Total 'IN' - Total'Out' by FIFO) is very slow . Somebody please suggest me to do this.
    This is my query
    ;WITH OrderedIn as (
        select *,ROW_NUMBER() OVER (PARTITION BY Stock_ID ORDER BY TranDate) as rn
        from Tran_Stock
        where TxnType = 'IN'  
    ), RunningTotals as (
        select  Stock_ID ,Qty,Price,Qty as Total,Cast(0 as decimal(10,2)) as PrevTotal ,  trandate , rn  from OrderedIn where rn = 1
        union all
        select  rt.Stock_ID,oi.Qty,oi.Price,Cast(rt.Total + oi.Qty as decimal(10,2)),Cast(rt.Total as decimal(10,2)) , oi.TranDate ,oi.rn 
        from
            RunningTotals rt
                inner join
            OrderedIn oi
                on
                    rt.Stock_ID = oi.Stock_ID and
                    rt.rn = oi.rn - 1
    , TotalOut as (
    select Stock_ID ,SUM(Qty) as Qty from Tran_Stock where TxnType='OUT'   group by Stock_ID
    ) ,  GrandTotal as 
    select
         rt.Stock_ID , rt.QTY AS original ,SUM(CASE WHEN PrevTotal > isNULL(out.Qty, 0) THEN rt.Qty ELSE rt.Total - isNULL(out.Qty, 0) END) AS QTY , Price , SUM(CASE WHEN PrevTotal > isNULL(out.Qty, 0) THEN rt.Qty ELSE rt.Total - isNULL(out.Qty,
    0) END * Price) AS Ending , rt.TranDate
    from
        RunningTotals rt
            LEFT join
        TotalOut out
            on
                rt.Stock_ID = out.Stock_ID
    where rt.Total > isNull(out.Qty , 0)
    group by rt.Stock_ID , Price , rt.TranDate  , rt.QTY
    ) SELECT * FROM  GrandTotal  order by TranDate  option (maxrecursion 0)
    AND  this is my Table with some example data
    USE [TestInventory]
    GO
    /****** Object:  Table [dbo].[Tran_Stock]    Script Date: 12/15/2014 3:55:56 AM ******/
    SET ANSI_NULLS ON
    GO
    SET QUOTED_IDENTIFIER ON
    GO
    CREATE TABLE [dbo].[Tran_Stock](
    [TranID] [int] IDENTITY(1,1) NOT NULL,
    [Stock_ID] [int] NULL,
    [TranDate] [date] NULL,
    [TxnType] [nvarchar](3) NULL,
    [Qty] [decimal](10, 2) NULL,
    [Price] [decimal](10, 2) NULL
    ) ON [PRIMARY]
    GO
    SET IDENTITY_INSERT [dbo].[Tran_Stock] ON 
    INSERT [dbo].[Tran_Stock] ([TranID], [Stock_ID], [TranDate], [TxnType], [Qty], [Price]) VALUES (1, 1, CAST(0x81350B00 AS Date), N'IN', CAST(200.00 AS Decimal(10, 2)), CAST(750.00 AS Decimal(10, 2)))
    INSERT [dbo].[Tran_Stock] ([TranID], [Stock_ID], [TranDate], [TxnType], [Qty], [Price]) VALUES (2, 1, CAST(0x85350B00 AS Date), N'OUT', CAST(100.00 AS Decimal(10, 2)), NULL)
    INSERT [dbo].[Tran_Stock] ([TranID], [Stock_ID], [TranDate], [TxnType], [Qty], [Price]) VALUES (3, 1, CAST(0x8A350B00 AS Date), N'IN', CAST(50.00 AS Decimal(10, 2)), CAST(700.00 AS Decimal(10, 2)))
    INSERT [dbo].[Tran_Stock] ([TranID], [Stock_ID], [TranDate], [TxnType], [Qty], [Price]) VALUES (4, 1, CAST(0x90350B00 AS Date), N'IN', CAST(75.00 AS Decimal(10, 2)), CAST(800.00 AS Decimal(10, 2)))
    INSERT [dbo].[Tran_Stock] ([TranID], [Stock_ID], [TranDate], [TxnType], [Qty], [Price]) VALUES (5, 1, CAST(0x99350B00 AS Date), N'OUT', CAST(175.00 AS Decimal(10, 2)), NULL)
    INSERT [dbo].[Tran_Stock] ([TranID], [Stock_ID], [TranDate], [TxnType], [Qty], [Price]) VALUES (6, 2, CAST(0x82350B00 AS Date), N'IN', CAST(150.00 AS Decimal(10, 2)), CAST(350.00 AS Decimal(10, 2)))
    INSERT [dbo].[Tran_Stock] ([TranID], [Stock_ID], [TranDate], [TxnType], [Qty], [Price]) VALUES (7, 2, CAST(0x88350B00 AS Date), N'OUT', CAST(40.00 AS Decimal(10, 2)), NULL)
    INSERT [dbo].[Tran_Stock] ([TranID], [Stock_ID], [TranDate], [TxnType], [Qty], [Price]) VALUES (8, 2, CAST(0x8C350B00 AS Date), N'OUT', CAST(10.00 AS Decimal(10, 2)), NULL)
    INSERT [dbo].[Tran_Stock] ([TranID], [Stock_ID], [TranDate], [TxnType], [Qty], [Price]) VALUES (9, 2, CAST(0x98350B00 AS Date), N'IN', CAST(90.00 AS Decimal(10, 2)), CAST(340.00 AS Decimal(10, 2)))
    INSERT [dbo].[Tran_Stock] ([TranID], [Stock_ID], [TranDate], [TxnType], [Qty], [Price]) VALUES (12, 2, CAST(0x98350B00 AS Date), N'IN', CAST(10.00 AS Decimal(10, 2)), CAST(341.00 AS Decimal(10, 2)))
    INSERT [dbo].[Tran_Stock] ([TranID], [Stock_ID], [TranDate], [TxnType], [Qty], [Price]) VALUES (13, 2, CAST(0x99350B00 AS Date), N'OUT', CAST(30.00 AS Decimal(10, 2)), NULL)
    INSERT [dbo].[Tran_Stock] ([TranID], [Stock_ID], [TranDate], [TxnType], [Qty], [Price]) VALUES (14, 2, CAST(0x81350B00 AS Date), N'IN', CAST(120.00 AS Decimal(10, 2)), CAST(350.00 AS Decimal(10, 2)))
    INSERT [dbo].[Tran_Stock] ([TranID], [Stock_ID], [TranDate], [TxnType], [Qty], [Price]) VALUES (15, 2, CAST(0x89350B00 AS Date), N'OUT', CAST(90.00 AS Decimal(10, 2)), NULL)
    INSERT [dbo].[Tran_Stock] ([TranID], [Stock_ID], [TranDate], [TxnType], [Qty], [Price]) VALUES (17, 3, CAST(0x89350B00 AS Date), N'IN', CAST(90.00 AS Decimal(10, 2)), CAST(350.00 AS Decimal(10, 2)))
    INSERT [dbo].[Tran_Stock] ([TranID], [Stock_ID], [TranDate], [TxnType], [Qty], [Price]) VALUES (18, 3, CAST(0x8A350B00 AS Date), N'OUT', CAST(60.00 AS Decimal(10, 2)), NULL)
    INSERT [dbo].[Tran_Stock] ([TranID], [Stock_ID], [TranDate], [TxnType], [Qty], [Price]) VALUES (19, 3, CAST(0x5D390B00 AS Date), N'OUT', CAST(20.00 AS Decimal(10, 2)), NULL)
    INSERT [dbo].[Tran_Stock] ([TranID], [Stock_ID], [TranDate], [TxnType], [Qty], [Price]) VALUES (20, 1, CAST(0x81350B00 AS Date), N'IN', CAST(200.00 AS Decimal(10, 2)), CAST(750.00 AS Decimal(10, 2)))
    INSERT [dbo].[Tran_Stock] ([TranID], [Stock_ID], [TranDate], [TxnType], [Qty], [Price]) VALUES (21, 1, CAST(0x85350B00 AS Date), N'OUT', CAST(100.00 AS Decimal(10, 2)), NULL)

    Hi,
    You dont have any Index on the table, so the filters (where part in the queries) and the sorting (order by, group by) make your query slow. it take time to sort or filter data without Index. It is like reading a book with 3k pages and trying to find a specific
    subject. You have to read the all books, but if you have "table of contents" which is the book index, then this can be done fast.
    * check the Execution plan (the image here show part of your query's execution plan). the query scan the all table 3 times...
    there is one sort that use 81% of the query resources... I will go sleep soon (it is
    23:58 In Israel now), and I don't know if I will have time to read the query itself and improved it, so lets start with indexes :-) 
    ** as a first step after or before you create the right Indexes you should remove the recursive all together. there is no reason for lopping the data when you can use it as a SET. This is where the relational database's power come to life :-)
    for example check this code. I only use your first part of the code using the first 2 CTE tables. compare result.
    ;WITH
    OrderedIn as (
    select *,ROW_NUMBER() OVER (PARTITION BY Stock_ID ORDER BY TranDate) as rn
    from Tran_Stock
    where TxnType = 'IN'
    , RunningTotals as (
    select Stock_ID ,Qty, Price, Qty as Total, Cast(0 as decimal(10,2)) as PrevTotal, trandate , rn
    from OrderedIn where rn = 1
    union all
    select
    rt.Stock_ID, oi.Qty, oi.Price, Cast(rt.Total + oi.Qty as decimal(10,2))
    ,Cast(rt.Total as decimal(10,2))
    , oi.TranDate ,oi.rn
    from RunningTotals rt
    inner join OrderedIn oi on rt.Stock_ID = oi.Stock_ID and rt.rn = oi.rn - 1
    select * from RunningTotals
    -- This will do the same as the above query
    select
    Stock_ID, Qty, Price
    , SUM(Qty) over (PARTITION BY Stock_ID order by TranDate ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) as Total
    ,TranDate--,TranID, TxnType
    from Tran_Stock
    where TxnType = 'IN'
    order by Stock_ID
      Ronen Ariely
     [Personal Site]    [Blog]    [Facebook]

  • Query with parameter as Array (UDT) very slow

    Hi.
    I have following Problem. I try to use Oracle Instant Client 11 and ODP.NET to pass Arrays in SELECT statements as Bind Parameters. I did it, but it runs very-very slow. Example:
    - Inittial Query:
    SELECT tbl1.field1, tbl1.field2, tbl2.field1, tbl2.field2 ... FROM tbl1
    LEFT JOIN tbl2 ON tbl1.field11=tbl2.field0
    LEFT JOIN tbl3 ON tbl2.field11=tbl3.field0 AND tbll1.field5=tbl3.field1
    ...and another LEFT JOINS
    WHERE
    tbl1.field0 IN ('id01', 'id02', 'id03'...)
    this query with 100 elements in "IN" on my database takes 3 seconds.
    - Query with Array bind:
    in Oracle I did UDT: create or replace type myschema.mytype as table of varchar2(1000)
    than, as described in Oracle Example I did few classes (Factory and implementing IOracleCustomType) and use it in Query,
    instead of IN ('id01', 'id02', 'id03'...) I have tbl1.field0 IN (select column_value from table(:prmTable)), and :prmTable is bound array.
    this query takes 190 seconds!!! Why? I works, but the HDD of Oracle server works very hard, and it takes too long.
    Oracle server we habe 10g.
    PS: I tried to use only 5 elements in array - the same result, it takes also 190 seconds...
    Please help!

    I did (some time ago and it was a packaged procedure) something like
    Procedure p(p_one in datatype,p_two in datatype,p_dataset out sys_refcursor) is
      the_sql varchar2(32000);
      the_cursor sys_refcursor;
    begin
      the_sql = 'WITH NOTIFICACAO AS( ' ||
                '      SELECT ' ||
                '       t1.cd_consultora, ' ||
                '                               where       t1.dt_notificacao_cn >= to_date(''01/09/2006'',''dd/mm/yyyy'') ' ||  -- note the ''
                '           where rownum <= :W_TO_REC) ' ||   -- parameter 1
                '         where r_linha >= :W_FROM_REC ';     -- parameter 2
      open the_cursor for the_sql using p_one,p_two;  -- just by the book
    end p;if I remember correctly
    Regards
    Etbin

  • MS-Access query running very slow

    Hi,
    We've MS-Access application which was pointing to UDB. Now we migrated it to point Oracle DB 9.2. After migration some of the query is running very slow.
    These queries used to take less than 30 seconds in UDB now taking more than 5 Minutes in Oracle.
    some more obeservation :
    (1) Some of the queries using "HAVING" clause without any aggregate function. When I moved this condition to "WHERE" clause, performance improved a lot.
    But problem is that I can't suggest this solution to "USERS". They are creating query using "query wizard" in MS-Access and they started creating noise on this.
    (2) I tested same MDB in two different PCs and same query is returning records in 4 seconds in one system, is taking more than 10 minutes in other system.
    Since I'm new to MS-Access, I don't know what other information I need to provide here.
    Please help me out.

    I have seen the problem like this,too
    can i have you

  • Query can run in Oracle 10g but very slow in 11g

    Hi,
    We've just migrated to Oracle 11g and we noticed that some of our view are very slow (it takes seconds in 10g and takes 30 minutes in 11g), and the tables are using the local table.
    Do any of you face the same issue?
    This is our query:
    SELECT
    A.wellbore
    ,a.depth center
    ,d.MD maxbc
    ,d.XDELT xbc
    ,d.YDELT ybc
    ,e.MD minac
    ,e.XDELT xac
    ,e.YDELT yac
    from
    table_A d,table_A e, table_B a
    where a.wellbore = d.WELLBORE (+)
    and a.wellbore = e.WELLBORE(+)
    and d.MD = (select max(MD) from table_A b where b.MD < a.depth and
    d.wellBORE = b.wellBORE)
    and e.md = (select min(md) from table_A c where c.MD > a.depth and
    e.wellBORE = c.wellBORE);

    Thanks I will move to the correct one..
    Rafi,
    Build the Indexes and it is still slow. I am querying from a view from another database, which is in 10g instances.
    Moved: Query can run in Oracle 10g but very slow in 11g
    Edited by: 924400 on Apr 1, 2012 6:03 PM
    Edited by: 924400 on Apr 1, 2012 6:26 PM

  • SPATIAL QUERY VERY SLOW

    I CAN TO EXECUTE THIS QUERY BUT IT IS VERY SLOW, I HAVE 2 TABLE , ONE A WITH 250.000 SITE AND B WITH 250.000 POINTS, I WANT TO DETERMINING HOW MANY RISK INSIDE THE SITES.
    THANKS
    JGS
    SELECT B.ID, A.ID, A.GC, A.SUMA
    FROM DBG_RIESGOS_CUMULOS_SITE A, DBG_RIESGOS_CUMULOS B
    WHERE A.GC = 'PATRIMONIAL FENOMENOS SISMICOS' AND A.GC=B.GC
    AND SDO_RELATE(B.GEOMETRY, A.GEOMETRY, 'MASK=INSIDE') = 'TRUE';
    100 RECORS IN 220 '' SLOWWWWW

    I would do two things:
    1) Ensure Oracle is patched with the latest 10.2.0.4 patches
    This is the list I've been working with:
    Patch 7003151
    Patch 6989483
    Patch 7237687
    Patch 7276032
    Patch 7307918
    2) Write the query like this
    SELECT /*+ ORDERED*/ B.ID, A.ID, A.GC, A.SUMA
    FROM DBG_RIESGOS_CUMULOS B, DBG_RIESGOS_CUMULOS_SITE A
    WHERE B.GC = 'PATRIMONIAL FENOMENOS SISMICOS'
    AND A.GC=B.GC
    AND SDO_ANYINTERACT(A.GEOMETRY, B.GEOMETRY) = 'TRUE';

  • Oracle interview questions;; query very slow

    Hai
    Most of time in interview they ask..
    WHAT IS THE STEPS U DO WHEN UR QUERY IS RUNNNING VERY SLOW..?
    i used to say
    1) first i will check for whether table is properly indexed or not
    2) next properly normalized or not
    interviewers are not fully satisfied with these answers..
    So kindly tell me more suggestion
    S

    Also when checking the execution plan, get the actual plan using DBMS_XPLAN.DISPLAY_CURSOR, rather than the predicted one (EXPLAIN PLAN FOR). If you use a configurable IDE such as SQL Developer of PL/SQL Developer it is worth taking the time to set this up in the session browser so that you can easily capture it while it's running. You might also look at the estimated vs actual cardinalities. While you're at it you could check v$session_longops, v$session_wait and (if you have the Diagnostic and Tuning packs licenced) v$active_session_history and the various dba_hist% views.
    You might try the SQL Tuning Advisor (DBMS_SQLTUNE) which generates profiles for SQL statements (requires ADVISOR system privilege to run a tuning task, and CREATE ANY SQL PROFILE to apply a profile).
    In 11g look at SQL Monitor.
    Tracing is all very well if you can get access to the tracefile in a reasonable timeframe, though in many sites (including my current one) it's just too much trouble unless you're a DBA.
    Edited by: William Robertson on Apr 18, 2011 11:40 PM
    Sorry Rob, should probably have replied to oraclehema rather than you.

  • Query runs very slow and sometime freezes

    Hi Experts,
    I have just installed SAP GUI 710 but when i open a query in analyzer it runs very slow and  if the variables are set for more than 6 months it just sits there and finally times out. It takes at least 5 minutes to open the query if it opens at all. Can you please advise me on how to resolve this issue??
    Thanks, point will be awarded.

    Worth running RSRT .
    Ravi Thothadri

Maybe you are looking for