Performance Issues with Debugging even in Display Mode

Hi not certain if this would sit in Security, ABAP or Basis, but lets start here as it is security related.
S_DEVELOP with any activity on DEBUG on a production system is a concern, but what are the performance related issues when a super user has to go into debug in display only on a production system because of a really complex issue?
I've heard in the past of a scenario where system performance was impacted, and we have notes around the allocation of S_DEVELOP display DEBUG access to this point. (I've summarised these below)
The risk with debug is associated with the length of time that the actual debugging process is being performed.
u2022     Work processes are dedicated solely to the users for the duration of the debug. If these are being performed for a long time, these can cause issues with not enough work processes being available.
u2022     It can cause DB2 locks. If the debug session last awhile, DB2 locks are not released. This impacts the availability of tablespaces, thus, affecting various transactions running across the system.
Even with these concerns, security will often get asked for debug display access.
As security is about risk identification, assessment and then controlled access what do other organisations do?
Options (not exhaustive) are "No Debug ever" or "Debug display only via a fire fight or super user on a time limited basis".
We are currently in the "debug display only via fire fight" camp, but would like to canvas opinion on this.
As one of the concepts of security is Availability of data (and to an extent ensuring the systems are up and running) do the performance risks push the security function to the "No Debug Ever" stance.

If you need to debug in production, then 9 times out of 10 you need to do root-cause analysis: The developer is the problem.
Writing sloppy code and not testing properly should not be an excuse for debugging in production.
But of course, there are exceptions even when you do try to keep them to a minimum.
To add to Jurjen's comments, also note that the debugger only has a limited capability of doing a rollback. So you can quite easily and unintentionally create inconsistencies in the system - also in display mode - which is an integrity problem, and typically more critical than availability problems or even potential confidentiality concerns.
Cheers,
Julius
Edited by: Julius Bussche on May 15, 2009 10:50 AM

Similar Messages

  • Performance Issue With Displaying Candidate Details for iRecruitment

    We are in EBS R12.1.3 when we trying to display the Candidate Details page in iRecruitment iRecruitment >vacancies>applicants> click on applicant>   the page spins for  a quite whille to show the results and some times we see the 500 errors..
    We are in R12.1.3 and also applied the  Patch.10427777:R12.IRC.B patch.. is there any  tunnign steps for the iRecruitment  page=/oracle/apps/irc/candidateSearch/webui/CmAplSrchPG

    You have already applied the patch mention in note: Performance Issue With Displaying Candidate Details Page in 12.1.3 (Doc ID 1293164.1)
    check this note also Performance Issue when Clicking on Candidate Name (Doc ID 1575164.1)
    thanks

  • Performance issues with pipelined table functions

    I am testing pipelined table functions to be able to re-use the <font face="courier">base_query</font> function. 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? The <font face="courier">processor</font> function is from [url http://www.oracle-developer.net/display.php?id=429]improving performance with pipelined table functions .
    Edit: The underlying query returns 500,000 rows in about 3 minutes. So there are are no performance issues with the query itself.
    Many thanks in advance.
    CREATE OR REPLACE PACKAGE pipeline_example
    IS
       TYPE resultset_typ IS REF CURSOR;
       TYPE row_typ IS RECORD (colC VARCHAR2(200), colD VARCHAR2(200), colE VARCHAR2(200));
       TYPE table_typ IS TABLE OF row_typ;
       FUNCTION base_query (argA IN VARCHAR2, argB IN VARCHAR2)
          RETURN resultset_typ;
       c_default_limit   CONSTANT PLS_INTEGER := 100;  
       FUNCTION processor (
          p_source_data   IN resultset_typ,
          p_limit_size    IN PLS_INTEGER DEFAULT c_default_limit)
          RETURN table_typ
          PIPELINED
          PARALLEL_ENABLE(PARTITION p_source_data BY ANY);
       PROCEDURE with_pipeline (argA          IN     VARCHAR2,
                                argB          IN     VARCHAR2,
                                o_resultset      OUT resultset_typ);
       PROCEDURE no_pipeline (argA          IN     VARCHAR2,
                              argB          IN     VARCHAR2,
                              o_resultset      OUT resultset_typ);
    END pipeline_example;
    CREATE OR REPLACE PACKAGE BODY pipeline_example
    IS
       FUNCTION base_query (argA IN VARCHAR2, argB IN VARCHAR2)
          RETURN resultset_typ
       IS
          o_resultset   resultset_typ;
       BEGIN
          OPEN o_resultset FOR
             SELECT colC, colD, colE
               FROM some_table
              WHERE colA = ArgA AND colB = argB;
          RETURN o_resultset;
       END base_query;
       FUNCTION processor (
          p_source_data   IN resultset_typ,
          p_limit_size    IN PLS_INTEGER DEFAULT c_default_limit)
          RETURN table_typ
          PIPELINED
          PARALLEL_ENABLE(PARTITION p_source_data BY ANY)
       IS
          aa_source_data   table_typ;-- := table_typ ();
       BEGIN
          LOOP
             FETCH p_source_data
             BULK COLLECT INTO aa_source_data
             LIMIT p_limit_size;
             EXIT WHEN aa_source_data.COUNT = 0;
             /* Process the batch of (p_limit_size) records... */
             FOR i IN 1 .. aa_source_data.COUNT
             LOOP
                PIPE ROW (aa_source_data (i));
             END LOOP;
          END LOOP;
          CLOSE p_source_data;
          RETURN;
       END processor;
       PROCEDURE with_pipeline (argA          IN     VARCHAR2,
                                argB          IN     VARCHAR2,
                                o_resultset      OUT resultset_typ)
       IS
       BEGIN
          OPEN o_resultset FOR
               SELECT /*+ PARALLEL(t, 5) */ colC,
                      SUM (CASE WHEN colD > colE AND colE != '0' THEN colD / ColE END)de,
                      SUM (CASE WHEN colE > colD AND colD != '0' THEN colE / ColD END)ed,
                      SUM (CASE WHEN colD = colE AND colD != '0' THEN '1' END) de_one,
                      SUM (CASE WHEN colD = '0' OR colE = '0' THEN '0' END) de_zero
                 FROM TABLE (processor (base_query (argA, argB),100)) t
             GROUP BY colC
             ORDER BY colC
       END with_pipeline;
       PROCEDURE no_pipeline (argA          IN     VARCHAR2,
                              argB          IN     VARCHAR2,
                              o_resultset      OUT resultset_typ)
       IS
       BEGIN
          OPEN o_resultset FOR
               SELECT colC,
                      SUM (CASE WHEN colD > colE AND colE  != '0' THEN colD / ColE END)de,
                      SUM (CASE WHEN colE > colD AND colD  != '0' THEN colE / ColD END)ed,
                      SUM (CASE WHEN colD = colE AND colD  != '0' THEN 1 END) de_one,
                      SUM (CASE WHEN colD = '0' OR colE = '0' THEN '0' END) de_zero
                 FROM (SELECT colC, colD, colE
                         FROM some_table
                        WHERE colA = ArgA AND colB = argB)
             GROUP BY colC
             ORDER BY colC;
       END no_pipeline;
    END pipeline_example;
    ALTER PACKAGE pipeline_example COMPILE;Edited by: Earthlink on Nov 14, 2010 9:47 AM
    Edited by: Earthlink on Nov 14, 2010 11:31 AM
    Edited by: Earthlink on Nov 14, 2010 11:32 AM
    Edited by: Earthlink on Nov 20, 2010 12:04 PM
    Edited by: Earthlink on Nov 20, 2010 12:54 PM

    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 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 crystal reports 11 - Critical

    Post Author: DJ Gaba
    CA Forum: Exporting
    I have migrated from crystal reports version 8 to version 11.
    I am experiencing some performance issues with reports when displayed in version 11
    Reports that was taking 2 seconds in version 8 is now taking 4-5 seconds in versino 11
    I am using vb6 to export my report file into pdf
    Thanks 

    Post Author: synapsevampire
    CA Forum: Exporting
    Pleae don't multiple forums on the site with the same question.
    I responded to your other post.
    -k

  • Performance issues with 0CO_OM_WBS_1

    We use BW3.5 & R/3 4.7 and encounter huge performance issues with 0CO_OM_WBS_1? Always having to do a full load involving approx 15M records even though there are on the average 100k new records since previous load. This takes a longtime.
    Is there a way to delta-enable this datasource?

    Hi,
    This DS is not delta enabled and you can only do a full load.  For a delta enabled one, you need to use 0CO_OM_WBS_6.  This works as other Financials extractors, as it has a safety delta (configurable, default 2 hours, in table BWOM_SETTINGS).
    What you should do is maybe, use the WBS_6 as a delta and only extract full loads for WBS_1 for shorter durations.
    As you must have an ODS for WBS_1 at the first stage, I would suggest do a full load only for posting periods that are open.  This will reduce the data load.
    You may also look at creating your own generic data source with delta; if you are clear on the tables and logic used.
    cheers...

  • Performance issues with FDK in large XML documents

    In my current project with FrameMaker 8 I'm experiencing severe performance issues with some FDK API calls.
    The documents are about 3-8 MBytes in size. Fortmatted they cover 150-250 pages.
    When importing such an XML document I do some extensive "post-processing" using FDK. This processing happens in Sr_EventHandler() during the SR_EVT_END_READER event. I noticed that some FDK functions calls which modify the document's structure, like F_ApiSetAttribute() or F_ApiNewElementInHierarchy(), take several seconds, for the larger documents even minutes, to complete one single function call. I tried to move some of these calls to earlier events, mostly to SR_EVT_END_ELEM. There the calls work without a delay. Unfortunately I can't rewrite the FDK client to move all the calls that are lagging to earlier events.
    Does anybody have a clue why such delays happen, and possibly can make a suggestion, how to solve this issue? Thank you in advance.
    PS: I already thought of splitting such a document in smaller pieces by using the FrameMaker book function. But I don't think, the structure of the documents will permit such an automatic split, and it definitely isn't an option to change the document structure (the project is about migrating documents from Interleaf to XML with the constraint of keeping the document layout identical).

    FP_ApplyFormatRules sounds really good--I'll give it a try on Monday. Wonder how I could miss it, as I already tried FP_Reformatting and FP_Displaying at no avail?! By the way, what is actually meant with FP_Reformatting (when I used it I assumed it would do exactly what FP_ApplyFormatRules sounds to do), or is that one another of Lynne's well-kept secrets?
    Thank's for all the helpful suggestions, guys. On Friday I already had my first improvements in a test version of my client: I did some (not all necessary) structural changes using XSLT pre-processing, and processing went down from 8 hours(!) to 1 hour--Yeappie! I was also playing with the idea of writing a wrapper to F_ApiNewElementInHierarchy() which actually pastes an appropriate element created in a small flow on the reference pages at the intended insertion location. But now, with FP_ApplyFormatRules on the horizon, I'm quite confident to get even the complicated stuff under control, which cannot be handled by the XSLT pre-processing, as it is based on the actual formatting of the document at run-time and cannot be anticipated in pre-processing.
    --Franz

  • Performance issues with Oracle EE 9.2.0.4 and RedHat 2.1

    Hello,
    I am having some serious performance issues with Oracle Enterprise Edition 9.2.0.4 and RedHat Linux 2.1. The processor goes berserk at 100% for long (some 5 min.) periods of time, and all the ram memory gets used.
    Some environment characteristics:
    Machine: Intel Pentium IV 2.0GHz with 1GB of RAM.
    OS: RedHat Linux 2.1 Enterprise.
    Oracle: Oracle Enterprise Edition 9.2.0.4
    Application: We have a small web-application with 10 users (for now) and very basic queries (all in stored procedures). Also we use the latest version of ODP.NET with default connection settings (some low pooling, etc).
    Does anyone know what could be going on?
    Is anybody else having this similar behavior?
    We change from SQL-Server so we are not the world expert on the matter. But we want a reliable system nonetheless.
    Please help us out, gives some tips, tricks, or guides…
    Thanks to all,
    Frank

    Thank you very much and sorry I couldn’t write sooner. It seems that the administrator doesn’t see the kswap going on so much, so I don’t really know what is going on.
    We are looking at some queries and some indexing but this is nuts, if I had some poor queries, which we don’t really, the server would show pick right?
    But he goes crazy and has two oracle processes taking all the resources. There seems to be little swapping going on.
    Son now what? They are all ready talking about MS-SQL please help me out here, this is crazy!!!
    We have, may be the most powerful combinations here. What is oracle doing?
    We even kill the Working Process of the IIS and have no one do anything with the database and still dose two processes going on.
    Can some one help me?
    Thanks,
    Frank

  • 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

  • Performance issues with SAP BPC 7.0/7.5 (SP06, 07, 08) NW

    Hi Experts
    There are some performance issues with SAP BPC 7.5/7.0 NW, users are saying they are not getting data or there are some issues while getting data from R/3 system or ECC 6.0. Then what things do I need to consider to check, such as what DataSources or Cubes I need to check? So, how to solve this issue?
    What things I need to consider for SAP NW BI 7.0 u2013 SAP BPC 7.5 NW (SP06, 07, 08) Implementation?
    Your help is greatly appreciated.
    Regards,
    Qadeer

    Hi,
    New  SP was released in February, and now most of the new bugs should been caught ,This has a Central Note. For SP06 it's Note 1527325 - Planning and Consolidation 7.5 SP06 NetWeaver Central Note to fix any issues. Most of the improvements in SP06 were related to performance, especially when logging on from the BPC clients.There you should be able to find a big list of fixes/improvements and Notes that describe those. Some of the Notes even have test description how to reproduce that issue in the old version.
    hope this will help you
    Regards
    Rv

  • Performance issues with the Tuxedo MQ Adapter

    We are experimenting some performance issues with the MQ Adapter. For example, we are seeing that the MQ Adapter takes from 10 to 100 ms in reading a single message from the queue and sending to the Tuxedo service. The Tuxedo service takes 80 ms in its execution so there is a considerable waste of time in the MQ adapter that we cannot explain.
    Also, we have looked a lot of rollback transactions on the MQ adapter, for example we got 980 rollback transactions for 15736 transactions sent and only the MQ adapter is involved in the rollback. However, the operations are executed properly. The error we got is
    135027.122.hqtux101!MQI_QMTESX01.7636.1.0: gtrid x0 x4ec1491f x25b59: LIBTUX_CAT:376: ERROR: tpabort: xa_rollback returned XA_RBROLLBACK.
    I am looking for information at Oracle site, but I have not found nothing. Could you or someone from your team help me?

    Hi Todd,
    We have 6 MQI adapters reading from 5 different queues, but in this case we are writing in only one queue.
    Someone from Oracle told us that the XA_RBROLLBACK occurs because we have 6 MQ adapters that are reading from the same queues and when one adapter finds a message and try to get that message, it can occurs that other MQ Adapter gets it before. In this case, the MQ adapter rollbacks the transaction. Even when we got some XA_RBROLLBACK errors, we don´t lose message. Also, I read something about that when XA sends a xa_end call to MQ adapter, it actually does the rollback, so when the MQ adapter receives the xa_rollback call, it answers with XA_RBROLLBACK. Is that true?
    However, I am more worried about the performance. We are putting a request message in a MQ queue and waiting for the reply. In some cases, it takes 150ms and in other cases it takes much more longer (more than 400ms). The average is 300ms. MQ adapter calls a service (txgralms0) which lasts 110ms in average.
    This is our configuration:
    "MQI_QMTESX01" SRVGRP="g03000" SRVID=3000
    CLOPT="-- -C /tuxedo/qt/txqgral00/control/src/MQI_QMTESX01.cfg"
    RQPERM=0600 REPLYQ=N RPPERM=0600 MIN=6 MAX=6 CONV=N
    SYSTEM_ACCESS=FASTPATH
    MAXGEN=1 GRACE=86400 RESTART=N
    MINDISPATCHTHREADS=0 MAXDISPATCHTHREADS=1 THREADSTACKSIZE=0
    SICACHEENTRIESMAX="500"
    /tuxedo/qt/txqgral00/control/src/MQI_QMTESX01.cfg:
    *SERVER
    MINMSGLEVEL=0
    MAXMSGLEVEL=0
    DEFMAXMSGLEN=4096
    TPESVCFAILDATA=Y
    *QUEUE_MANAGER
    LQMID=QMTESX01
    NAME=QMTESX01
    *SERVICE
    NAME=txgralms0
    FORMAT=MQSTR
    TRAN=N
    *QUEUE
    LQMID=QMTESX01
    MQNAME=QAT.Q.NACAR.TO.TUX.KGCRQ01
    *QUEUE
    LQMID=QMTESX01
    MQNAME=QAT.Q.NACAR.TO.TUX.KGCPQ01
    *QUEUE
    LQMID=QMTESX01
    MQNAME=QAT.Q.NACAR.TO.TUX.KPSAQ01
    *QUEUE
    LQMID=QMTESX01
    MQNAME=QAT.Q.NACAR.TO.TUX.KPINQ01
    *QUEUE
    LQMID=QMTESX01
    MQNAME=QAT.Q.NACAR.TO.TUX.KDECQ01
    Thanks in advance,
    Marling

  • Performance issue with Jdeveloper

    Hi Guys,
    I am experiencing strange performance issue with Jdeveloper 10.1.3.3.0.4157. There are many other threads regarding the performance issue in this forum, but the problem I have is a little bit different.
    I have two computers: one is Athlon 3200+ with Vista and another one is P4 dual core 6400 with XP (service pack 2). Both of them have 2GB memory.
    I am running the same simple project on both computer, but only the one with Vista has the problem. The problem is very similar to the problem mentioned in the thread:
    Re: IDE has become extremely slow?
    But it's much worse. It only happens only on JSF pages. Basically, any operations on the JSF pages are very slow. Loading the page, changing the attributes of a button in source editor, or even clicking the items in the design view take forever to run.
    The first weird thing is that it may use 100% CPU, but it never recover, which means the 100% CPU usage never stops or when it stops, the Jdeveloper stops responding.
    The second weird thing is that the project is not big. Actually, it's very small. The problem started to happen since last week. There are not big changes during the period. The only thing I can say is that we created two more JSF pages.
    The third weird thing is that the same project never happened on the P4+XP box. When I open the project on the P4+XP box, it’s always fast and no CPU spike.
    Any advises are welcome!
    Thanks,
    Steven

    Hi Guys,
    I re-made a simple test project for this problem and now I now always reproduce the problem in JDeveloper on both system (XP & Vista). Everytime I open this jspx file in the source editor and try to scroll up/down the source file, or manually delete an attribute, JDeveloepr will hang and the CPU usage is 0%.
    Here is the content of the test file:
    <?xml version='1.0' encoding='windows-1252'?>
    <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.0"
    xmlns:h="http://java.sun.com/jsf/html"
    xmlns:f="http://java.sun.com/jsf/core"
    xmlns:af="http://xmlns.oracle.com/adf/faces"
    xmlns:afh="http://xmlns.oracle.com/adf/faces/html">
    <jsp:output omit-xml-declaration="true" doctype-root-element="HTML"
    doctype-system="http://www.w3.org/TR/html4/loose.dtd"
    doctype-public="-//W3C//DTD HTML 4.01 Transitional//EN"/>
    <jsp:directive.page contentType="text/html;charset=windows-1252"/>
    <f:view>
    <afh:html binding="#{backing_streettypedetail.html1}" id="html1">
    <afh:head title="streettypedetail"
    binding="#{backing_streettypedetail.head1}" id="head1">
    <meta http-equiv="Content-Type"
    content="text/html; charset=windows-1252"/>
    </afh:head>
    <afh:body binding="#{backing_streettypedetail.body1}" id="body1">
    <af:messages binding="#{backing_streettypedetail.messages1}"
    id="messages1"/>
    <h:form binding="#{backing_streettypedetail.form1}" id="form1">
    <af:panelForm binding="#{backing_streettypedetail.panelForm1}"
    id="panelForm1">
    <af:inputText value="#{bindings.streetTypeID.inputValue}"
    label="#{bindings.streetTypeID.label}"
    required="#{bindings.streetTypeID.mandatory}"
    columns="#{bindings.streetTypeID.displayWidth}"
    binding="#{backing_streettypedetail.inputText1}"
    id="inputText1">
    <af:validator binding="#{bindings.streetTypeID.validator}"/>
    </af:inputText>
    <af:inputText value="#{bindings.description.inputValue}"
    label="#{bindings.description.label}"
    required="#{bindings.description.mandatory}"
    columns="#{bindings.description.displayWidth}"
    binding="#{backing_streettypedetail.inputText2}"
    id="inputText2">
    <af:validator binding="#{bindings.description.validator}"/>
    </af:inputText>
    <af:inputText value="#{bindings.abbr.inputValue}"
    label="#{bindings.abbr.label}"
    required="#{bindings.abbr.mandatory}"
    columns="#{bindings.abbr.displayWidth}"
    binding="#{backing_streettypedetail.inputText3}"
    id="inputText3">
    <af:validator binding="#{bindings.abbr.validator}"/>
    </af:inputText>
    <f:facet name="footer">
    <h:panelGroup binding="#{backing_streettypedetail.panelGroup1}"
    id="panelGroup1">
    <af:commandButton text="Save"
    binding="#{backing_streettypedetail.saveButton}"
    id="saveButton"
    actionListener="#{bindings.mergeEntity.execute}"
    action="#{userState.retrieveReturnNavigationRule}"
    disabled="#{!bindings.mergeEntity.enabled}"
    partialSubmit="false">
    <af:setActionListener from="#{true}"
    to="#{userState.refresh}"/>
    </af:commandButton>
    <af:commandButton text="Cancel"
    binding="#{backing_streettypedetail.cancelButton}"
    action="#{userState.retrieveReturnNavigationRule}"
    id="cancelButton">
    <af:setActionListener from="#{false}"
    to="#{userState.refresh}"/>
    </af:commandButton>
    </h:panelGroup>
    </f:facet>
    </af:panelForm>
    </h:form>
    </afh:body>
    </afh:html>
    </f:view>
    <!--oracle-jdev-comment:auto-binding-backing-bean-name:backing_streettypedetail-->
    </jsp:root>
    Can anybody take a look at the file and let me know what's wrong with it?
    Thanks in advance.
    Steven

  • Performance issue with using MAX function in pl/sql

    Hello All,
    We are having a performance issue with the below logic wherein MAX is being used in order to get the latest instance/record for a given input variable ( p_in_header_id).. the item_key is having the format as :
    p_in_header_id - <number generated from a sequence>
    This query to fetch even 1 record takes around 1 minutes 30 sec..could someone please help if there is a better way to form this logic & to improve performance in this case.
    We want to get the latest record for the item_key ( this we are getting using MAX (begin_date)) for a given p_in_header_id value.
    Query 1 :
    SELECT item_key FROM wf_items WHERE item_type = 'xxxxzzzz'
    AND SUBSTR (item_key, 1, INSTR (item_key, '-') - 1) =p_in_header_id
    AND root_activity ='START_REQUESTS'
    AND begin_date =
    (SELECT MAX (begin_date) FROM wf_items WHERE item_type = 'xxxxzzzz'
    AND root_activity ='START_REQUESTS'
    AND SUBSTR (item_key, 1, INSTR (item_key, '-') - 1) =p_in_header_id);
    Could someone please help us with this performance issue..we are really stuck because of this
    regards

    First of all Thanks to all gentlemen who replied ..many thanks ...
    Tried the ROW_NUMBER() option but still it is taking time...have given output for the query and tkprof results as well. Even when it doesn't fetch any record ( this is a valid cased because the input header id doesn't have any workflow request submitted & hence no entry in the wf_items table)..then also see the time it has taken.
    Looked at the RANK & DENSE_RANK options which were suggested..but it is still taking time..
    Any further suggestions or ideas as to how this could be resolved..
    SELECT 'Y', 'Y', ITEM_KEY
    FROM
    ( SELECT ITEM_KEY, ROW_NUMBER() OVER(ORDER BY BEGIN_DATE DESC) RN FROM
    WF_ITEMS WHERE ITEM_TYPE = 'xxxxzzzz' AND ROOT_ACTIVITY = 'START_REQUESTS'
    AND SUBSTR(ITEM_KEY,1,INSTR(ITEM_KEY,'-') - 1) = :B1
    ) T WHERE RN <= 1
    call count cpu elapsed disk query current rows
    Parse 0 0.00 0.00 0 0 0 0
    Execute 1 0.00 1.57 0 0 0 0
    Fetch 1 8700.00 544968.73 8180 8185 0 0
    total 2 8700.00 544970.30 8180 8185 0 0
    many thanks

  • SAP DS 1.3: Performance issues with crosstab planning (IE only)

    Hi everyone,
    because im currently developing a custom component for DS 1.3, I got in touch with the planning feature of design studio. Planning currently only works in a crosstab.
    Here I recognized a significant performance issue with the internet explorer:
    If you simply type in a new value into a cell in a crosstab, it takes ~10s to confirm it (not constant! Sometimes it takes 2s, sometimes 15s). During this 10s, it seems like the IE crashed - no response at all. Sometimes there is also a warning message on bottom ('... script is slowing down the application ...').
    Tested the same scenario with Chrome and FF - takes less than 1s to confirm.
    Whats going on here ...? Anyone experienced the same issues?
    My testing environment:
    Windows 8.1
    IE 11 (also tested emulated Ie 10 and IE 9 - same problem)
    DS 1.3.0.3.201405141058
    Local mode
    Application only contained a simple crosstab, data source based on BW 7.3 query
    Of course I deactivated all custom components while testing...
    Kind regards
    Wladimir

    Hi Tammy,
    Thanks for your reply. Of course, my IE is updated to latest version (11.0.9600.17207).
    Hopefully SP1 will fix this bug...
    Kind regards
    Wladimir

  • 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.

Maybe you are looking for