View Performance Issues

Basically I have created a View that I can Select count(*) on and it returns the number of rows, I use the view for an Insert query to one table only pulling through several fields and after a bit of a pause it works...
I then Insert the whole view to another table and Oracle seems to hang and temp space increases until it uses all 2.5 GB it was on 700 MB when I started the second Insert. We are only talking about 50,000 rows or so.
The View is quite complex but surely Oracle has to create the whole view in order to Insert a few fields? So why does it hang on a Select * ?
CREATE OR REPLACE VIEW VW_FAMITY_TRANSFORM AS
SELECT CC_REF || '-' || RTrim(FAM_B_Prefix) AS CD_PROP, FAM_Surv_date AS CD_DATE, FAM_Unique_no AS CD_SEQ, TYP_TYPE AS CD_TYPE, FAM_SK_no AS CD_REF, FAM_E_no AS CD_OPT, FAM_SP_no AS CD_SUBOPT,
FAM_Unique_no AS CD_NO, FAM_R_no AS CD_UREF, FAM_R_Name AS CD_UNAME, FAM_R_no AS CD_ALLOCUREF,
FAM_SP_name AS CST_DESC, FAM_SK_name AS CSC_DESC, SUBSTR(FAM_Condition,1,3) AS CD_COND, FAM_PriorityVal AS CD_REP, NULL AS CD_REPDATE,
FAM_Cost AS CD_M1, NULL AS CD_EST, FAM_Types AS CD_SHED, NULL AS CD_ACTION, NULL AS CD_INF, NULL AS CD_START, NULL AS CD_COMP,
NULL AS CD_FAULT, Null AS CD_CHARGE, RTrim(FAM_SK_name) || ' ' || RTrim(FAM_E_name) || ' ' || RTrim(FAM_SP_name) AS CD_RACTION, FAM_R_Usage AS CD_CONSEQUENCE,
FAM_FailYearVal AS CD_FAILYR, NULL AS CD_SCHYEAR, NULL AS CD_SCHPERD, FAM_Surv_Name AS CD_SURVEYOR, FAM_Units AS CD_C1, FAM_Dim AS CD_C2, FAM_Mg_dim AS CD_C3,
FAM_Qty AS CD_M2, FAM_Mg_qty AS CD_M3, NULL AS CD_D1, NULL AS CD_D2, NULL AS CD_D3, FAM_Surv_Status AS CD_STATUS, NULL AS CD_ORIGIN, NULL AS CD_IND, NULL AS CD_BEDESC,
NULL AS CD_CAT, FAM_Notes AS CD_DESC, FAM_E_name AS CD_CDESC, NULL AS CD_NEWSEQ, 'Y' AS CD_CANPROCESS
FROM LD_FAMITY2, LD_CCENT, LD_TYPE, UNIT
WHERE (CC_AREA = FAM_AREA) AND (FAM_SK_no = TYP_SK_no)
AND (CC_REF || '-' || RTrim(FAM_B_Prefix) = RTrim(UN_BREF) AND TO_CHAR(FAM_R_no) = RTrim(UN_UREF));
INSERT INTO CSURV_ADD (CS_SURVEYOR, CS_PROP, CS_PNAME, CS_DATE, CS_SEQ, CS_UREF, CS_UNAME, CS_ALLOCPROP, CS_ALLOCUREF, CS_STATUS, CS_CANPROCESS) SELECT CD_SURVEYOR, CD_PROP, PR_NAME, CD_DATE, CD_SEQ, CD_UREF, CD_UNAME, CD_PROP, CD_UREF, CD_STATUS, CD_CANPROCESS FROM VW_FAMITY_TRANSFORM, PROP WHERE (CD_PROP = RTRIM(PR_SNAM));
INSERT INTO CDOTD_ADD SELECT * FROM VW_FAMITY_TRANSFORM;
Basically I need to know why the temp space is fine for the first Insert and not for the second or any way to optimise.

It is not a SQL*Plus tool issue; your question
is posted in the wrong forum. Please ask again in
the Database forum at http://www.oracle.com/forums/forum.jsp?forum=61
or the SQL forum at http://www.oracle.com/forums/forum.jsp?forum=75
-- CJ

Similar Messages

  • HTML Article performance issues in Adobe Viewer on iPad

    I have created a HTML Article using DPS but when I come to view it on Adobe Viewer in iPad the content does not scroll smoothly and the content is cut off and cropped (the whole page is not displayed), it is very judery and struggles to render the HTML below 'the fold' so to speak.
    I have tried both options for importing HTML into DPS and both have the same performance/lag isuues.
    I have a video in my HTML that seemed to be causing an issue where the video streaming was struggling to be pulled through, so I have treid YouTube and Vimeo video streaming and the performance/display issue is not resolved. I then tried embbeding an mp4 directly using HTML5 to see if it was a connection/bandwidth issue and the problem still exists. However the videos do play, its just the fact that the container is cropped in half.
    Sometimes the whole HTML article renders but then when you swipe back up the page it struggles to render the content above? Also then when you swipe back down the page the content is also cropped that was visible before?
    I have reviewed every available discussion on the Adobe Community and other resources but all the fixes mentioned do not have any effect.
    If anybody can assist or has been experiencing the same issues any advise would be welcome.
    Oh, the HTML Article contains some JS too, it does function correctly but I was wondering if JS causes problems? Just a thought.

    Well, I think I may have found the answer so I thought I would share with the Community incase anyone else experiences the same type of issues.
    After testing another peice of HTML that also included video streaming and heavy JavaScript, I narrowed the issue down to my JS. I had two Nivo Slider Carousels that were the route of the performance issues.
    The other test HTML Article scrolls smoothly and the video pulls in as intended, although once in a while there is a slight delay in the page scrolling up and down but this is hardly noticeable.
    I hope this may be of some help to other's in the future?

  • Question about a view I created to fix the performance issues

    Dear alll;
    I have this interesting problem. I created a view to help solve certain performance issue I have been having with my query
    see view below
    create or replace view view_test as
    Select trunc(c.close_date, 'YYYY-MM-DD') as close_date, t.names
    from tbl_component c, tbl_joborder t
    where c.t_id = t.p_id
    and c.type = 'C'
    group by trunc(c.close_date, 'YYYY-MM-DD'), t.names
    ;and I tried testing the view out by using the following syntax and I am getting the following errors
    select k.close_date, k.names from view_test k
    where k.names = 'Kay'
    and k.close_date between to_date('2010-01-01', 'YYYY-MM-DD') and to_date('2010-12-31', 'YYYY-MM-DD')however, I am getting the error messages below
    ora-o1898: too many precision specifiersI have googled it and tried a lot of stuff online but I cant fix the problem unfortunately and I dont know why.

    Hi,
    Instead of
    trunc(c.close_date, 'YYYY-MM-DD')say
    trunc (c.close_date, 'DD')Oracle apparantly gets confused by saying you want to truncate (or round) to two or more different units.
    If it were up to me, I would allow it, since truncatng to the year implies truncating to the month and to the day (not to mention hours, minutes and seconds), but there may be reasons why that would be a pain to implement. (Maybe because there are units, such as 'WW' and 'IW', that are not neat sub-divisions of larger units.)

  • Performance issue with a Custom view

    Hi ,
    I am pretty new to performance tuning and facing a performance issue with a custom view.
    Execution time for view query is good but as soon as I append a where caluse to view query ,the execution time increases.
    Below is the view query:
    CREATE OR REPLACE XXX_INFO_VIEW AS
    SELECT csb.system_id license_id,
    cst.name license_number ,
    csb.system_type_code license_type ,
    csb.attribute3 lac , -- license authorization code
    csb.attribute6 lat , -- license admin token
    csb.attribute12 ols_reg, -- OLS Registration allowed flag
    l.attribute4 license_biz_type ,
    NVL (( SELECT 'Y' l_supp_flag
    FROM csi_item_instances cii,
    okc_k_lines_b a,
    okc_k_items c
    WHERE c.cle_id = a.id
    AND a.lse_id = 9
    AND c.jtot_object1_code = 'OKX_CUSTPROD'
    AND c.object1_id1 = cii.instance_id||''
    AND cii.instance_status_id IN (3, 510)
    AND cii.system_id = csb.system_id
    AND a.sts_code IN ('SIGNED', 'ACTIVE')
    AND NVL (a.date_terminated, a.end_date) > SYSDATE
    AND ROWNUM < 2), 'N') active_supp_flag,
    hp.party_name "Customer_Name" , -- Customer Name
    hca.attribute12 FGE_FLAG,
    (SELECT /*+INDEX (oklt OKC_K_LINES_TL_U1) */
    nvl(max((decode(name, 'eSupport','2','Enterprise','1','Standard','1','TERM RTU','0','TERM RTS','0','Notfound'))),0) covName --TERM RTU and TERM RTS added as per Vijaya's suggestion APR302013
    FROM OKC_K_LINES_B oklb1,
    OKC_K_LINES_TL oklt,
    OKC_K_LINES_B oklb2,
    OKC_K_ITEMS oki,
    CSI_item_instances cii
    WHERE
    OKI.JTOT_OBJECT1_CODE = 'OKX_CUSTPROD'
    AND oklb1.id=oklt.id
    AND OKI.OBJECT1_ID1 =cii.instance_id||''
    AND Oklb1.lse_id=2
    AND oklb1.dnz_chr_id=oklb2.dnz_chr_id
    AND oklb2.lse_id=9
    AND oki.CLE_ID=oklb2.id
    AND cii.system_id=csb.system_id
    AND oklt.LANGUAGE=USERENV ('LANG')) COVERAGE_TYPE
    FROM csi_systems_b csb ,
    csi_systems_tl cst ,
    hz_cust_accounts hca,
    hz_parties hp,
    fnd_lookup_values l
    WHERE csb.system_type_code = l.lookup_code (+)
    AND csb.system_id = cst.system_id
    AND hca.cust_account_id =csb.customer_id
    AND hca.party_id= hp.party_id
    AND cst.language = USERENV ('LANG')
    AND l.lookup_type (+) = 'CSI_SYSTEM_TYPE'
    AND l.language (+) = USERENV ('LANG')
    AND NVL (csb.end_date_active, SYSDATE+1) > SYSDATE)
    I have forced an index to avoid Full table scan on OKC_K_LINES_TL and suppressed an index on CSI_item_instances.instance id to make the view query fast.
    So when i do select * from XXX_INFO_VIEWit executes in a decent time,But when I try to do
    select * from XXX_INFO_VIEW where active_supp_flag='Y' and coverage_type='1'
    it takes lot of time.
    Execution plan is same for both queries in terms of cost but with WHERE clause Number of bytes increases.
    Below are the execution plans:
    View query:
    SELECT STATEMENT ALL_ROWS Cost: 7,212 Bytes: 536,237 Cardinality: 3,211                                         
         10 COUNT STOPKEY                                    
              9 NESTED LOOPS                               
                   7 NESTED LOOPS Cost: 1,085 Bytes: 101 Cardinality: 1                          
                        5 NESTED LOOPS Cost: 487 Bytes: 17,043 Cardinality: 299                     
                             2 TABLE ACCESS BY INDEX ROWID TABLE CSI.CSI_ITEM_INSTANCES Cost: 22 Bytes: 2,325 Cardinality: 155                
                                  1 INDEX RANGE SCAN INDEX CSI.CSI_ITEM_INSTANCES_N07 Cost: 3 Cardinality: 315           
                             4 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_ITEMS Cost: 3 Bytes: 84 Cardinality: 2                
                                  3 INDEX RANGE SCAN INDEX OKC.OKC_K_ITEMS_N2 Cost: 2 Cardinality: 2           
                        6 INDEX UNIQUE SCAN INDEX (UNIQUE) OKC.OKC_K_LINES_B_U1 Cost: 1 Cardinality: 1                     
                   8 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_LINES_B Cost: 2 Bytes: 44 Cardinality: 1                          
         12 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_CUST_ACCOUNTS Cost: 2 Bytes: 7 Cardinality: 1                                    
              11 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_CUST_ACCOUNTS_U1 Cost: 1 Cardinality: 1                               
         28 SORT AGGREGATE Bytes: 169 Cardinality: 1                                    
              27 NESTED LOOPS                               
                   25 NESTED LOOPS Cost: 16,549 Bytes: 974,792 Cardinality: 5,768                          
                        23 NESTED LOOPS Cost: 5,070 Bytes: 811,737 Cardinality: 5,757                     
                             20 NESTED LOOPS Cost: 2,180 Bytes: 56,066 Cardinality: 578                
                                  17 NESTED LOOPS Cost: 967 Bytes: 32,118 Cardinality: 606           
                                       14 TABLE ACCESS BY INDEX ROWID TABLE CSI.CSI_ITEM_INSTANCES Cost: 22 Bytes: 3,465 Cardinality: 315      
                                            13 INDEX RANGE SCAN INDEX CSI.CSI_ITEM_INSTANCES_N07 Cost: 3 Cardinality: 315
                                       16 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_ITEMS Cost: 3 Bytes: 84 Cardinality: 2      
                                            15 INDEX RANGE SCAN INDEX OKC.OKC_K_ITEMS_N2 Cost: 2 Cardinality: 2
                                  19 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_LINES_B Cost: 2 Bytes: 44 Cardinality: 1           
                                       18 INDEX UNIQUE SCAN INDEX (UNIQUE) OKC.OKC_K_LINES_B_U1 Cost: 1 Cardinality: 1      
                             22 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_LINES_B Cost: 5 Bytes: 440 Cardinality: 10                
                                  21 INDEX RANGE SCAN INDEX OKC.OKC_K_LINES_B_N2 Cost: 2 Cardinality: 9           
                        24 INDEX UNIQUE SCAN INDEX (UNIQUE) OKC.OKC_K_LINES_TL_U1 Cost: 1 Cardinality: 1                     
                   26 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_LINES_TL Cost: 2 Bytes: 28 Cardinality: 1                          
         43 HASH JOIN Cost: 7,212 Bytes: 536,237 Cardinality: 3,211                                    
              41 NESTED LOOPS                               
                   39 NESTED LOOPS Cost: 7,070 Bytes: 485,792 Cardinality: 3,196                          
                        37 HASH JOIN Cost: 676 Bytes: 341,972 Cardinality: 3,196                     
                             32 HASH JOIN RIGHT OUTER Cost: 488 Bytes: 310,012 Cardinality: 3,196                
                                  30 TABLE ACCESS BY INDEX ROWID TABLE APPLSYS.FND_LOOKUP_VALUES Cost: 7 Bytes: 544 Cardinality: 17           
                                       29 INDEX RANGE SCAN INDEX (UNIQUE) APPLSYS.FND_LOOKUP_VALUES_U1 Cost: 3 Cardinality: 17      
                                  31 TABLE ACCESS FULL TABLE CSI.CSI_SYSTEMS_B Cost: 481 Bytes: 207,740 Cardinality: 3,196           
                             36 VIEW VIEW AR.index$_join$_013 Cost: 187 Bytes: 408,870 Cardinality: 40,887                
                                  35 HASH JOIN           
                                       33 INDEX FAST FULL SCAN INDEX (UNIQUE) AR.HZ_CUST_ACCOUNTS_U1 Cost: 112 Bytes: 408,870 Cardinality: 40,887      
                                       34 INDEX FAST FULL SCAN INDEX AR.HZ_CUST_ACCOUNTS_N2 Cost: 122 Bytes: 408,870 Cardinality: 40,887      
                        38 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_PARTIES_U1 Cost: 1 Cardinality: 1                     
                   40 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_PARTIES Cost: 2 Bytes: 45 Cardinality: 1                          
              42 TABLE ACCESS FULL TABLE CSI.CSI_SYSTEMS_TL Cost: 142 Bytes: 958,770 Cardinality: 63,918           
    Execution plan for view query with WHERE clause:
    SELECT STATEMENT ALL_ROWS Cost: 7,212 Bytes: 2,462,837 Cardinality: 3,211                                         
         10 COUNT STOPKEY                                    
              9 NESTED LOOPS                               
                   7 NESTED LOOPS Cost: 1,085 Bytes: 101 Cardinality: 1                          
                        5 NESTED LOOPS Cost: 487 Bytes: 17,043 Cardinality: 299                     
                             2 TABLE ACCESS BY INDEX ROWID TABLE CSI.CSI_ITEM_INSTANCES Cost: 22 Bytes: 2,325 Cardinality: 155                
                                  1 INDEX RANGE SCAN INDEX CSI.CSI_ITEM_INSTANCES_N07 Cost: 3 Cardinality: 315           
                             4 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_ITEMS Cost: 3 Bytes: 84 Cardinality: 2                
                                  3 INDEX RANGE SCAN INDEX OKC.OKC_K_ITEMS_N2 Cost: 2 Cardinality: 2           
                        6 INDEX UNIQUE SCAN INDEX (UNIQUE) OKC.OKC_K_LINES_B_U1 Cost: 1 Cardinality: 1                     
                   8 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_LINES_B Cost: 2 Bytes: 44 Cardinality: 1                          
         12 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_CUST_ACCOUNTS Cost: 2 Bytes: 7 Cardinality: 1                                    
              11 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_CUST_ACCOUNTS_U1 Cost: 1 Cardinality: 1                               
         28 SORT AGGREGATE Bytes: 169 Cardinality: 1                                    
              27 NESTED LOOPS                               
                   25 NESTED LOOPS Cost: 16,549 Bytes: 974,792 Cardinality: 5,768                          
                        23 NESTED LOOPS Cost: 5,070 Bytes: 811,737 Cardinality: 5,757                     
                             20 NESTED LOOPS Cost: 2,180 Bytes: 56,066 Cardinality: 578                
                                  17 NESTED LOOPS Cost: 967 Bytes: 32,118 Cardinality: 606           
                                       14 TABLE ACCESS BY INDEX ROWID TABLE CSI.CSI_ITEM_INSTANCES Cost: 22 Bytes: 3,465 Cardinality: 315      
                                            13 INDEX RANGE SCAN INDEX CSI.CSI_ITEM_INSTANCES_N07 Cost: 3 Cardinality: 315
                                       16 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_ITEMS Cost: 3 Bytes: 84 Cardinality: 2      
                                            15 INDEX RANGE SCAN INDEX OKC.OKC_K_ITEMS_N2 Cost: 2 Cardinality: 2
                                  19 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_LINES_B Cost: 2 Bytes: 44 Cardinality: 1           
                                       18 INDEX UNIQUE SCAN INDEX (UNIQUE) OKC.OKC_K_LINES_B_U1 Cost: 1 Cardinality: 1      
                             22 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_LINES_B Cost: 5 Bytes: 440 Cardinality: 10                
                                  21 INDEX RANGE SCAN INDEX OKC.OKC_K_LINES_B_N2 Cost: 2 Cardinality: 9           
                        24 INDEX UNIQUE SCAN INDEX (UNIQUE) OKC.OKC_K_LINES_TL_U1 Cost: 1 Cardinality: 1                     
                   26 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_LINES_TL Cost: 2 Bytes: 28 Cardinality: 1                          
         44 VIEW VIEW APPS.WRS_LICENSE_INFO_V Cost: 7,212 Bytes: 2,462,837 Cardinality: 3,211                                    
              43 HASH JOIN Cost: 7,212 Bytes: 536,237 Cardinality: 3,211                               
                   41 NESTED LOOPS                          
                        39 NESTED LOOPS Cost: 7,070 Bytes: 485,792 Cardinality: 3,196                     
                             37 HASH JOIN Cost: 676 Bytes: 341,972 Cardinality: 3,196                
                                  32 HASH JOIN RIGHT OUTER Cost: 488 Bytes: 310,012 Cardinality: 3,196           
                                       30 TABLE ACCESS BY INDEX ROWID TABLE APPLSYS.FND_LOOKUP_VALUES Cost: 7 Bytes: 544 Cardinality: 17      
                                            29 INDEX RANGE SCAN INDEX (UNIQUE) APPLSYS.FND_LOOKUP_VALUES_U1 Cost: 3 Cardinality: 17
                                       31 TABLE ACCESS FULL TABLE CSI.CSI_SYSTEMS_B Cost: 481 Bytes: 207,740 Cardinality: 3,196      
                                  36 VIEW VIEW AR.index$_join$_013 Cost: 187 Bytes: 408,870 Cardinality: 40,887           
                                       35 HASH JOIN      
                                            33 INDEX FAST FULL SCAN INDEX (UNIQUE) AR.HZ_CUST_ACCOUNTS_U1 Cost: 112 Bytes: 408,870 Cardinality: 40,887
                                            34 INDEX FAST FULL SCAN INDEX AR.HZ_CUST_ACCOUNTS_N2 Cost: 122 Bytes: 408,870 Cardinality: 40,887
                             38 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_PARTIES_U1 Cost: 1 Cardinality: 1                
                        40 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_PARTIES Cost: 2 Bytes: 45 Cardinality: 1                     
                   42 TABLE ACCESS FULL TABLE CSI.CSI_SYSTEMS_TL Cost: 142 Bytes: 958,770 Cardinality: 63,918

    Hi,
    You should always try using primary index fields, if not possible then secondary index fields.
    Even if you cannot do anything from either of the two then try this,
    Use Less distinct fields on the top.
    In your case , you can use bukrs ,gjahr ,werks on the top in the where condition..then followed by less distinct values..
    Even when you use secondary index if you have 4 fields in your sec index and you are using only two fields from the top then the index is useful only upto that two fields provided they are in sequence.

  • Performance Issue with Crosstab Reports Using Disco Viewer 10.1.2.48.18

    We're experiencing Performance Issue (retrieving 40000 rows) with Crosstab Reports Using Disco Viewer 10.1.2.48.18 ( > 01 Minute , executing "Building Page Axis" or executing a Refresh).
    Are there parameters to tun (in pref.txt file) , in order to reduce "Building Page Axis" execution ?
    Note : We've got the same performance problem , using Discoverer Desktop 10.1.2.48.18.
    Thank's in advance for your Help.

    Hi
    Well if the same issue occurs in both Desktop and Viewer then you have your answer. It's not the way that Discoverer is running the workbook its the way the workbook has been constructed.
    For a start, 40000 rows for a Crosstab is way over the top and WILL cause performance issues. This is because Discoverer has to create a bucket for every data point for every combination of items on the page, side and top axes. The more rows, page items and column headings that you have, the more buckets you have and therefore the longer it will take for Discoverer to work out the contents of every bucket.
    Also, whenever you use page items or crosstabs, Discoverer has to retrieve all of the rows for the entire query, not just the first x rows as with a table. This is because it cannot possibly know how many buckets to create until it has all the rows.
    You therefore to:
    a) apply sufficient filters to reduce the amount of data being returned to something manageable
    b) reduce the number of page items, if used
    c) reduce the number of items on the side or top axis of a crosstab
    d) reduce the number of complex calculations, especially calculations that would generate a new bucket
    If you have a lot of complex calculations, you should consider the use of a materialized view / summary folder to pre-calculate the values.
    Does this help?
    Best wishes
    Michael Armstrong-Smith
    URL: http://learndiscoverer.com
    Blog: http://learndiscoverer.blogspot.com

  • Performance Issue with PAY_BALANCE_VALUES_V View in Oracle R12

    Dear all ,
      We have recently upgraded from 11i(11.5.10.2) to R12(12.1.3). We are facing one Issue with slow performance of the queries where PAY_BALANCE_VALUES_V is used. We have so many reports & logic in Payroll which uses this View.
    In 11i this works fine, however in R12 it takes very long time. There are no configuration changes we have done from 11i to R12.
    Is there any way to optimize the performance or alternate way to retrieve the Balances Data in Payroll ?
    Any heads up would be highly Appreciated.
    Thanks,
    Razi

    Hi Razi,
    The balance related performance issue is written in the following note.
    Note:1494344.1 UK Payslip Generation - Self Service Program Takes Much Time To Complete (Performance Issue)
    This issue was fixed in HR_PF.B RUP6 or patch:14376786. Did you apply this patch? If not, I suggest you apply it.
    Also, HR_PF.B RUP6 has some balance related performance issues.
    If you already have applied HR_PF.B RUP6, I suggest you log a SR with SQL trace.
    Thanks,
    Hideki

  • Performance issue with view selection after migration from oracle to MaxDb

    Hello,
    After the migration from oracle to MaxDb we have serious performance issues with a lot of our tableview selections.
    Does anybody know about this problem and how to solve it ??
    Best regards !!!
    Gert-Jan

    Hello Gert-Jan,
    most probably you need additional indexes to get better performance.
    Using the command monitor you can identify the long running SQL statements and check the optimizer access strategy. Then you can decide which indexes might help.
    If this is about an SAP system, you can find additional information about performance analysis in SAP notes 725489 and 819641.
    SAP Hosting provides the so-called service 'MaxDB Migration Support' to help you in such cases. The service description can be found here:
    http://www.saphosting.de/mediacenter/pdfs/solutionbriefs/MaxDB_de.pdf
    http://www.saphosting.com/mediacenter/pdfs/solutionbriefs/maxDB-migration-support_en.pdf.
    Best regards,
    Melanie Handreck

  • RE: Case 59063: performance issues w/ C TLIB and Forte3M

    Hi James,
    Could you give me a call, I am at my desk.
    I had meetings all day and couldn't respond to your calls earlier.
    -----Original Message-----
    From: James Min [mailto:jminbrio.forte.com]
    Sent: Thursday, March 30, 2000 2:50 PM
    To: Sharma, Sandeep; Pyatetskiy, Alexander
    Cc: sophiaforte.com; kenlforte.com; Tenerelli, Mike
    Subject: Re: Case 59063: performance issues w/ C TLIB and Forte 3M
    Hello,
    I just want to reiterate that we are very committed to working on
    this issue, and that our goal is to find out the root of the problem. But
    first I'd like to narrow down the avenues by process of elimination.
    Open Cursor is something that is commonly used in today's RDBMS. I
    know that you must test your query in ISQL using some kind of execute
    immediate, but Sybase should be able to handle an open cursor. I was
    wondering if your Sybase expert commented on the fact that the server is
    not responding to commonly used command like 'open cursor'. According to
    our developer, we are merely following the API from Sybase, and open cursor
    is not something that particularly slows down a query for several minutes
    (except maybe the very first time). The logs show that Forte is waiting for
    a status from the DB server. Actually, using prepared statements and open
    cursor ends up being more efficient in the long run.
    Some questions:
    1) Have you tried to do a prepared statement with open cursor in your ISQL
    session? If so, did it have the same slowness?
    2) How big is the table you are querying? How many rows are there? How many
    are returned?
    3) When there is a hang in Forte, is there disk-spinning or CPU usage in
    the database server side? On the Forte side? Absolutely no activity at all?
    We actually have a Sybase set-up here, and if you wish, we could test out
    your database and Forte PEX here. Since your queries seems to be running
    off of only one table, this might be the best option, as we could look at
    everything here, in house. To do this:
    a) BCP out the data into a flat file. (character format to make it portable)
    b) we need a script to create the table and indexes.
    c) the Forte PEX file of the app to test this out.
    d) the SQL staement that you issue in ISQL for comparison.
    If the situation warrants, we can give a concrete example of
    possible errors/bugs to a developer. Dial-in is still an option, but to be
    able to look at the TOOL code, database setup, etc. without the limitations
    of dial-up may be faster and more efficient. Please let me know if you can
    provide this, as well as the answers to the above questions, or if you have
    any questions.
    Regards,
    At 08:05 AM 3/30/00 -0500, Sharma, Sandeep wrote:
    James, Ken:
    FYI, see attached response from our Sybase expert, Dani Sasmita. She has
    already tried what you suggested and results are enclosed.
    ++
    Sandeep
    -----Original Message-----
    From: SASMITA, DANIAR
    Sent: Wednesday, March 29, 2000 6:43 PM
    To: Pyatetskiy, Alexander
    Cc: Sharma, Sandeep; Tenerelli, Mike
    Subject: Re: FW: Case 59063: Select using LIKE has performance
    issues
    w/ CTLIB and Forte 3M
    We did that trick already.
    When it is hanging, I can see what is doing.
    It is doing OPEN CURSOR. But not clear the exact statement of the cursor
    it is trying to open.
    When we run the query directly to Sybase, not using Forte, it is clearly
    not opening any cursor.
    And running it directly to Sybase many times, the response is always
    consistently fast.
    It is just when the query runs from Forte to Sybase, it opens a cursor.
    But again, in the Forte code, Alex is not using any cursor.
    In trying to capture the query,we even tried to audit any statementcoming
    to Sybase. Same thing, just open cursor. No cursor declaration anywhere.==============================================
    James Min
    Technical Support Engineer - Forte Tools
    Sun Microsystems, Inc.
    1800 Harrison St., 17th Fl.
    Oakland, CA 94612
    james.minsun.com
    510.869.2056
    ==============================================
    Support Hotline: 510-451-5400
    CUSTOMERS open a NEW CASE with Technical Support:
    http://www.forte.com/support/case_entry.html
    CUSTOMERS view your cases and enter follow-up transactions:
    http://www.forte.com/support/view_calls.html

    Earthlink wrote:
    Contrary to my understanding, the <font face="courier">with_pipeline</font> procedure runs 6 time slower than the legacy <font face="courier">no_pipeline</font> procedure. Am I missing something? Well, we're missing a lot here.
    Like:
    - a database version
    - how did you test
    - what data do you have, how is it distributed, indexed
    and so on.
    If you want to find out what's going on then use a TRACE with wait events.
    All nessecary steps are explained in these threads:
    HOW TO: Post a SQL statement tuning request - template posting
    http://oracle-randolf.blogspot.com/2009/02/basic-sql-statement-performance.html
    Another nice one is RUNSTATS:
    http://asktom.oracle.com/pls/asktom/ASKTOM.download_file?p_file=6551378329289980701

  • Performance issues with LOV bindings in 3-tier BC4J architecture

    We are running BC4J and JClient (Jdeveloper 9.0.3.4/9iAS 9.0.2) in a 3-tier architecture, and have problems with the performance.
    One of our problems are comboboxes with LOV bindings. The view objects that provides data for the LOV bindings contains simple queries from tables with only 4-10 rows, and there are no view links or entity objects to these views.
    To create the LOV binding and to set the model for the combobox takes about 1 second for each combobox.
    We have tried most of tips in http://otn.oracle.com/products/jdev/tips/muench/jclientperf/index.html, but they do not seem to help on our problem.
    The performance is OK (if not great) when the same code is running as 2-tier.
    Does anyone have any good suggestions?

    I can recommend that you look at the following two bugs in Metalink: Bug 2640945 and Bug 3621502
    They are related to the disabling of the TCP socket-level acknowledgement which slows down remote communications for EJB components using ORMI (the protocol used by Oracle OC4J) to communicate between remote EJB client and server.
    A BC4J Application Module deployed as an EJB suffers this same network latency penalty due to the TCP acknowledgement.
    A customer sent me information (that you'll see there as a part of Bug# 3621502) like this on a related issue:
    We found our application runs very slow in 3-Tier mode (JClient, BC4J deployed
    as EJB Session Bean on 9iAS server 9.0.2 enterprise edition). We spent a lot
    of time to tune up our codes but that helped very little. Eventually, we found
    the problem seemed to happen on TCP level. There is a 200ms delay in TCP
    level. After we read some documents about Nagle Algorithm,  we disabled a
    registry key (TcpDelAckTicks) in windows2000  on both client and server. This
    makes our program a lot faster.
    Anyway, we think we should provide our clients a better solution other than
    changing windows registry for them, for example, there may be a way to disable
    that Nagle's algorithm through java.net.Socket.setTcpNoDelay(true), in BC4J,
    or anywhere in our codes. We have not figured out yet.
    Bug 2640945 was fixed in Oracle Application Server 10g (v9.0.4) and it now disables this TCP Acknowledgement on the server side in that release. In the BugDB, I see backport patches available for earlier 9.0.3 and 9.0.2 releases of IAS as well.
    Bug 3621502 is requesting that that same disabling also be performed on the client side by the ORMI code. I have received a test patch from development to try out, but haven't had the chance yet.
    The customer's workaround in the interim was to disable this TCP Acknowledgement at the OS level by modifying a Windows registry setting as noted above.
    See Also http://support.microsoft.com/default.aspx?kbid=328890
    "New registry entry for controlling the TCP Acknowledgment (ACK) behavior in Windows XP and in Windows Server 2003" which documents that the registry entry to change disable this acknowledgement has a different name in Windows XP and Windows 2003.
    Hope this info helps. It would be useful to hear back from you on whether this helps your performance issue.

  • Performance Issues with large XML (1-1.5MB) files

    Hi,
    I'm using an XML Schema based Object relational storage for my XML documents which are typically 1-1.5 MB in size and having serious performance issues with XPath Query.
    When I do XPath query against an element of SQLType varchar2, I get a good performance. But when I do a similar XPath query against an element of SQLType Collection (Varray of varchar2), I get a very ordinary performance.
    I have also created indexes on extract() and analyzed my XMLType table and indexes, but I have no performance gain. Also, I have tried all sorts of storage options available for Collections ie. Varray's, Nested Tables, IOT's, LOB's, Inline, etc... and all these gave me same bad performance.
    I even tried creating XMLType views based on XPath queries but the performance didn't improve much.
    I guess I'm running out of options and patience as well.;)
    I would appreciate any ideas/suggestions, please help.....
    Thanks;
    Ramakrishna Chinta

    Are you having similar symptoms as I am? http://discussions.apple.com/thread.jspa?threadID=2234792&tstart=0

  • Performance Issues with Folio format in Ipad.

    Hello everyone! My FIRST post here!!!
    I work with educational games and I'm facing performance issues with games that I've made in HTML5 to play in Ipad. I tried to import them to the format folio in DPS (Adobe Digital Publishing Suite). However when I import the HTML game into Indesign and try to preview it in Adobe content viewer, the game doesn't open or works without perform properly (there is a lag that doesn't let you play the game with a little of fun).
    The games that I've created have a memory use max of 35mb and weighs 30mb max.
    Does anyone know what's happen and what I can do to fix that performance issue?
    Thanks a lot!

    Moved to DPS

  • Performance issues with version enable partitioned tables?

    Hi all,
    Are there any known performance issues with version enable partitioned tables?
    I’ve been doing some performance testes with a large version enable partitioned table and it seems that OCB optimiser is choosing very expensive plans during merge operations.
    Tanks in advance,
    Vitor
    Example:
         Object Name     Rows     Bytes     Cost     Object Node     In/Out     PStart     PStop
    UPDATE STATEMENT Optimizer Mode=CHOOSE          1          249                    
    UPDATE     SIG.SIG_QUA_IMG_LT                                   
    NESTED LOOPS SEMI          1     266     249                    
    PARTITION RANGE ALL                                   1     9
    TABLE ACCESS FULL     SIG.SIG_QUA_IMG_LT     1     259     2               1     9
    VIEW     SYS.VW_NSO_1     1     7     247                    
    NESTED LOOPS          1     739     247                    
    NESTED LOOPS          1     677     247                    
    NESTED LOOPS          1     412     246                    
    NESTED LOOPS          1     114     244                    
    INDEX RANGE SCAN     WMSYS.MODIFIED_TABLES_PK     1     62     2                    
    INDEX RANGE SCAN     SIG.QIM_PK     1     52     243                    
    TABLE ACCESS BY GLOBAL INDEX ROWID     SIG.SIG_QUA_IMG_LT     1     298     2               ROWID     ROW L
    INDEX RANGE SCAN     SIG.SIG_QUA_IMG_PKI$     1          1                    
    INDEX RANGE SCAN     WMSYS.WM$NEXTVER_TABLE_NV_INDX     1     265     1                    
    INDEX UNIQUE SCAN     WMSYS.MODIFIED_TABLES_PK     1     62                         
    /* Formatted on 2004/04/19 18:57 (Formatter Plus v4.8.0) */                                        
    UPDATE /*+ USE_NL(Z1) ROWID(Z1) */sig.sig_qua_img_lt z1                                        
    SET z1.nextver =                                        
    SYS.ltutil.subsversion                                        
    (z1.nextver,                                        
    SYS.ltutil.getcontainedverinrange (z1.nextver,                                        
    'SIG.SIG_QUA_IMG',                                        
    'NpCyPCX3dkOAHSuBMjGioQ==',                                        
    4574,                                        
    4575                                        
    4574                                        
    WHERE z1.ROWID IN (
    (SELECT /*+ ORDERED USE_NL(T1) USE_NL(T2) USE_NL(J2) USE_NL(J3)
    INDEX(T1 QIM_PK) INDEX(T2 SIG_QUA_IMG_PKI$)
    INDEX(J2 WM$NEXTVER_TABLE_NV_INDX) INDEX(J3 MODIFIED_TABLES_PK) */
    t2.ROWID
    FROM (SELECT /*+ INDEX(WM$MODIFIED_TABLES MODIFIED_TABLES_PK) */
    UNIQUE VERSION
    FROM wmsys.wm$modified_tables
    WHERE table_name = 'SIG.SIG_QUA_IMG'
    AND workspace = 'NpCyPCX3dkOAHSuBMjGioQ=='
    AND VERSION > 4574
    AND VERSION <= 4575) j1,
    sig.sig_qua_img_lt t1,
    sig.sig_qua_img_lt t2,
    wmsys.wm$nextver_table j2,
    (SELECT /*+ INDEX(WM$MODIFIED_TABLES MODIFIED_TABLES_PK) */
    UNIQUE VERSION
    FROM wmsys.wm$modified_tables
    WHERE table_name = 'SIG.SIG_QUA_IMG'
    AND workspace = 'NpCyPCX3dkOAHSuBMjGioQ=='
    AND VERSION > 4574
    AND VERSION <= 4575) j3
    WHERE t1.VERSION = j1.VERSION
    AND t1.ima_id = t2.ima_id
    AND t1.qim_inf_esq_x_tile = t2.qim_inf_esq_x_tile
    AND t1.qim_inf_esq_y_tile = t2.qim_inf_esq_y_tile
    AND t2.nextver != '-1'
    AND t2.nextver = j2.next_vers
    AND j2.VERSION = j3.VERSION))

    Hello Vitor,
    There are currently no known issues with version enabled tables that are partitioned. The merge operation may need to access all of the partitions of a table depending on the data that needs to be moved/copied from the child to the parent. This is the reason for the 'Partition Range All' step in the plan that you provided. The majority of the remaining steps are due to the hints that have been added, since this plan has provided the best performance for us in the past for this particular statement. If this is not the case for you, and you feel that another plan would yield better performance, then please let me know and I will take a look at it.
    One suggestion would be to make sure that the table was been recently analyzed so that the optimizer has the most current data about the table.
    Performance issues are very hard to fix without a reproducible test case, so it may be advisable to file a TAR if you continue to have significant performance issues with the mergeWorkspace operation.
    Thank You,
    Ben

  • ITunes on Windows 7 performance issues - slow and hangs

    Is there any way to improve performance of iTunes running on Windows 7?
    It has always been slow with lots of application hangs and stalls that will resolve themselves if you wait for iTunes to catch up, but I find it incredibly frustrating.
    For example, when iTunes starts and if it is checking podcasts, the entire application is unresponsive until it finishes checking and refreshing podcasts.
    Alternately, when viewing my iPad Air and looking at the list of apps installed via iTunes it can take 30 seconds before iTunes responds.
    Considering that this is running on a system with a quad-core Haswell processor at 3.2Ghz, 16GB of RAM and Windows 7 x64 it is pretty unacceptable.
    The efficiency at which iTunes operates is just appalling.  I can run Adobe Photoshop and many more memory hungry and processor intensive applications than iTunes and get better performance than what I see in iTunes.
    This is not specific to my system either.  All of my family members have iPhones and their own computers and this performance issue exists on every computer I have ever run iTunes on.
    Is there any way to manually tune performance because this is pretty crappy.  It's been bugging me for years, but today just kind of feels like the last straw.

    I guess the answer is, "It's terribad, live with it"

  • Performance issues when creating a Report / Query in Discoverer

    Hi forum,
    Hope you are can help, it involves a performance issues when creating a Report / Query.
    I have a Discoverer Report that currently takes less than 5 seconds to run. After I add a condition to bring back Batch Status that = ‘Posted’ we cancelled the query after reaching 20 minutes as this is way too long. If I remove the condition the query time goes back to less than 5 seconds.
    Please see attached the SQL Inspector Plan:
    Before Condition
    SELECT STATEMENT
    SORT GROUP BY
    VIEW SYS
    SORT GROUP BY
    NESTED LOOPS OUTER
    NESTED LOOPS OUTER
    NESTED LOOPS
    NESTED LOOPS
    NESTED LOOPS
    NESTED LOOPS OUTER
    NESTED LOOPS OUTER
    NESTED LOOPS
    NESTED LOOPS OUTER
    NESTED LOOPS OUTER
    NESTED LOOPS
    NESTED LOOPS
    NESTED LOOPS
    NESTED LOOPS
    NESTED LOOPS
    NESTED LOOPS
    NESTED LOOPS
    NESTED LOOPS
    NESTED LOOPS
    NESTED LOOPS
    NESTED LOOPS
    TABLE ACCESS BY INDEX ROWID GL.GL_CODE_COMBINATIONS
    AND-EQUAL
    INDEX RANGE SCAN GL.GL_CODE_COMBINATIONS_N2
    INDEX RANGE SCAN GL.GL_CODE_COMBINATIONS_N1
    TABLE ACCESS BY INDEX ROWID APPLSYS.FND_FLEX_VALUES
    INDEX RANGE SCAN APPLSYS.FND_FLEX_VALUES_N1
    TABLE ACCESS BY INDEX ROWID APPLSYS.FND_FLEX_VALUE_SETS
    INDEX UNIQUE SCAN APPLSYS.FND_FLEX_VALUE_SETS_U1
    TABLE ACCESS BY INDEX ROWID APPLSYS.FND_FLEX_VALUES_TL
    INDEX UNIQUE SCAN APPLSYS.FND_FLEX_VALUES_TL_U1
    INDEX RANGE SCAN APPLSYS.FND_FLEX_VALUE_NORM_HIER_U1
    TABLE ACCESS BY INDEX ROWID GL.GL_JE_LINES
    INDEX RANGE SCAN GL.GL_JE_LINES_N1
    INDEX UNIQUE SCAN GL.GL_JE_HEADERS_U1
    INDEX UNIQUE SCAN GL.GL_SETS_OF_BOOKS_U2
    TABLE ACCESS BY INDEX ROWID GL.GL_JE_HEADERS
    INDEX UNIQUE SCAN GL.GL_JE_HEADERS_U1
    INDEX UNIQUE SCAN GL.GL_DAILY_CONVERSION_TYPES_U1
    TABLE ACCESS BY INDEX ROWID GL.GL_JE_SOURCES_TL
    INDEX UNIQUE SCAN GL.GL_JE_SOURCES_TL_U1
    INDEX UNIQUE SCAN GL.GL_JE_CATEGORIES_TL_U1
    INDEX UNIQUE SCAN GL.GL_JE_HEADERS_U1
    INDEX UNIQUE SCAN GL.GL_JE_HEADERS_U1
    INDEX UNIQUE SCAN GL.GL_JE_BATCHES_U1
    INDEX UNIQUE SCAN GL.GL_BUDGET_VERSIONS_U1
    INDEX UNIQUE SCAN GL.GL_ENCUMBRANCE_TYPES_U1
    INDEX UNIQUE SCAN GL.GL_SETS_OF_BOOKS_U2
    TABLE ACCESS BY INDEX ROWID GL.GL_JE_BATCHES
    INDEX UNIQUE SCAN GL.GL_JE_BATCHES_U1
    INDEX UNIQUE SCAN GL.GL_SETS_OF_BOOKS_U2
    INDEX UNIQUE SCAN GL.GL_JE_BATCHES_U1
    TABLE ACCESS BY INDEX ROWID GL.GL_PERIODS
    INDEX RANGE SCAN GL.GL_PERIODS_U1
    After Condition
    SELECT STATEMENT
    SORT GROUP BY
    VIEW SYS
    SORT GROUP BY
    NESTED LOOPS
    NESTED LOOPS OUTER
    NESTED LOOPS OUTER
    NESTED LOOPS
    NESTED LOOPS
    NESTED LOOPS
    NESTED LOOPS
    NESTED LOOPS OUTER
    NESTED LOOPS
    NESTED LOOPS
    NESTED LOOPS
    NESTED LOOPS
    NESTED LOOPS
    NESTED LOOPS
    NESTED LOOPS OUTER
    NESTED LOOPS
    NESTED LOOPS OUTER
    NESTED LOOPS
    NESTED LOOPS
    NESTED LOOPS OUTER
    NESTED LOOPS
    TABLE ACCESS FULL GL.GL_JE_BATCHES
    INDEX UNIQUE SCAN GL.GL_SETS_OF_BOOKS_U2
    INDEX UNIQUE SCAN GL.GL_JE_BATCHES_U1
    TABLE ACCESS BY INDEX ROWID GL.GL_JE_HEADERS
    INDEX RANGE SCAN GL.GL_JE_HEADERS_N1
    INDEX UNIQUE SCAN GL.GL_SETS_OF_BOOKS_U2
    INDEX UNIQUE SCAN GL.GL_ENCUMBRANCE_TYPES_U1
    INDEX UNIQUE SCAN GL.GL_DAILY_CONVERSION_TYPES_U1
    INDEX UNIQUE SCAN GL.GL_BUDGET_VERSIONS_U1
    TABLE ACCESS BY INDEX ROWID GL.GL_JE_SOURCES_TL
    INDEX UNIQUE SCAN GL.GL_JE_SOURCES_TL_U1
    INDEX UNIQUE SCAN GL.GL_JE_CATEGORIES_TL_U1
    INDEX UNIQUE SCAN GL.GL_JE_BATCHES_U1
    TABLE ACCESS BY INDEX ROWID GL.GL_JE_LINES
    INDEX RANGE SCAN GL.GL_JE_LINES_U1
    INDEX UNIQUE SCAN GL.GL_SETS_OF_BOOKS_U2
    TABLE ACCESS BY INDEX ROWID GL.GL_CODE_COMBINATIONS
    INDEX UNIQUE SCAN GL.GL_CODE_COMBINATIONS_U1
    TABLE ACCESS BY INDEX ROWID GL.GL_PERIODS
    INDEX RANGE SCAN GL.GL_PERIODS_U1
    TABLE ACCESS BY INDEX ROWID APPLSYS.FND_FLEX_VALUES
    INDEX RANGE SCAN APPLSYS.FND_FLEX_VALUES_N1
    INDEX RANGE SCAN APPLSYS.FND_FLEX_VALUE_NORM_HIER_U1
    TABLE ACCESS BY INDEX ROWID APPLSYS.FND_FLEX_VALUES_TL
    INDEX UNIQUE SCAN APPLSYS.FND_FLEX_VALUES_TL_U1
    TABLE ACCESS BY INDEX ROWID APPLSYS.FND_FLEX_VALUE_SETS
    INDEX UNIQUE SCAN APPLSYS.FND_FLEX_VALUE_SETS_U1
    INDEX UNIQUE SCAN GL.GL_JE_HEADERS_U1
    INDEX UNIQUE SCAN GL.GL_JE_HEADERS_U1
    INDEX UNIQUE SCAN GL.GL_JE_HEADERS_U1
    Is there anything i can do in Discoverer Desktop / Administration to avoid this problem.
    Many thanks,
    Lance

    Hi Rod,
    I've tried the condition (Batch Status||'' = 'Posted') as you suggested, but the qeury time is still over 20 mins. To test i changed it to (Batch Status||'' = 'Unposted') and the query was returned within seconds again.
    I’ve been doing some more digging and have found the database view that is linked to the Journal Batches folder. See below.
    I think the problem is with the column using DECODE. When querying the column in TOAD the value of ‘P’ is returned. But in discoverer the condition is done on the value ‘Posted’. I’m not too sure how DECODE works, but think this could be the causing some sort of issue with Full Table Scans. How do we get around this?
    Lance
    DECODE( JOURNAL_BATCH1.STATUS,
    '+', 'Unable to validate or create CTA',
    '+*', 'Was unable to validate or create CTA',
    '-','Invalid or inactive rounding differences account in journal entry',
    '-*', 'Modified invalid or inactive rounding differences account in journal entry',
    '<', 'Showing sequence assignment failure',
    '<*', 'Was showing sequence assignment failure',
    '>', 'Showing cutoff rule violation',
    '>*', 'Was showing cutoff rule violation',
    'A', 'Journal batch failed funds reservation',
    'A*', 'Journal batch previously failed funds reservation',
    'AU', 'Showing batch with unopened period',
    'B', 'Showing batch control total violation',
    'B*', 'Was showing batch control total violation',
    'BF', 'Showing batch with frozen or inactive budget',
    'BU', 'Showing batch with unopened budget year',
    'C', 'Showing unopened reporting period',
    'C*', 'Was showing unopened reporting period',
    'D', 'Selected for posting to an unopened period',
    'D*', 'Was selected for posting to an unopened period',
    'E', 'Showing no journal entries for this batch',
    'E*', 'Was showing no journal entries for this batch',
    'EU', 'Showing batch with unopened encumbrance year',
    'F', 'Showing unopened reporting encumbrance year',
    'F*', 'Was showing unopened reporting encumbrance year',
    'G', 'Showing journal entry with invalid or inactive suspense account',
    'G*', 'Was showing journal entry with invalid or inactive suspense account',
    'H', 'Showing encumbrance journal entry with invalid or inactive reserve account',
    'H*', 'Was showing encumbrance journal entry with invalid or inactive reserve account',
    'I', 'In the process of being posted',
    'J', 'Showing journal control total violation',
    'J*', 'Was showing journal control total violation',
    'K', 'Showing unbalanced intercompany journal entry',
    'K*', 'Was showing unbalanced intercompany journal entry',
    'L', 'Showing unbalanced journal entry by account category',
    'L*', 'Was showing unbalanced journal entry by account category',
    'M', 'Showing multiple problems preventing posting of batch',
    'M*', 'Was showing multiple problems preventing posting of batch',
    'N', 'Journal produced error during intercompany balance processing',
    'N*', 'Journal produced error during intercompany balance processing',
    'O', 'Unable to convert amounts into reporting currency',
    'O*', 'Was unable to convert amounts into reporting currency',
    'P', 'Posted',
    'Q', 'Showing untaxed journal entry',
    'Q*', 'Was showing untaxed journal entry',
    'R', 'Showing unbalanced encumbrance entry without reserve account',
    'R*', 'Was showing unbalanced encumbrance entry without reserve account',
    'S', 'Already selected for posting',
    'T', 'Showing invalid period and conversion information for this batch',
    'T*', 'Was showing invalid period and conversion information for this batch',
    'U', 'Unposted',
    'V', 'Journal batch is unapproved',
    'V*', 'Journal batch was unapproved',
    'W', 'Showing an encumbrance journal entry with no encumbrance type',
    'W*', 'Was showing an encumbrance journal entry with no encumbrance type',
    'X', 'Showing an unbalanced journal entry but suspense not allowed',
    'X*', 'Was showing an unbalanced journal entry but suspense not allowed',
    'Z', 'Showing invalid journal entry lines or no journal entry lines',
    'Z*', 'Was showing invalid journal entry lines or no journal entry lines', NULL ),

  • Many-to-many performance issue

    I realize that many-to-many joins have been discussed before (yes, I looked through many threads), but I'm having a slight variation on the issue. Our data warehouse has been functioning for a couple of years now, but we're now experiencing a dramatic degradation in report performance. I'll tell you everything I know and what I've tried. My hope is that someone will have an idea that hasn't occurred to me yet.
    The troubling data links deal with accounts and account_types. Each transaction will have one account, but each account can have multiple account_types and each account_type is made up of multiple accounts. It ends up looking like this:
    Transaction_cube --< account_dimension >--< account_type_table
    Given the many-to-many relationship between account and account_type, this is the only architecture I could come up with that will maintain data integrity in the transaction cube.
    I know that this is the cause of the performance issues because the reports run normally when this is removed. The volume of data obviously increases over time, but the problem appeared very suddenly -- not a gradual degradation that one would expect from a volume issue. The cube is partitioned by year and we're a little below last year's growth.
    The other fact to throw in is that the account_type table did increase in size by an additional 30% when we first noticed the problem. However, the business was able to go back and remove half of the account_types (unused types) so now the table has fewer rows than it had before we noticed the problem (~15k rows in the account_type table).
    We have tried pinning the table so that it remain in memory, but that did not help. I tried creating a materialized view combining accounts and account_types with a similar lack of improvement. I've tried adding indexes, but there is still a full-table scan. All database objects are analyzed nightly after the data load is completed.
    I'm fresh out of ideas at this point. Any suggestions and/or ideas would be greatly appreciated.

    I've thought about that. What it would mean would be aprox. 20 additional columns for each of the different account_types. Unfortunately, that would also mean that all the reports that use the account_type would have to have a condition:
    WHERE acct_type1='Income Stmt." OR acct_type2='Income Stmt." OR ....
    Since the account_types are not set up in a hierarchy and there must be only one row for account, I'm not sure that this is a feasible solution.
    Thank you for the suggestion.

Maybe you are looking for