Hints in 11G

Hi ,
Cany one provide me link for hints in 11G.
Thanks in Advance

http://docs.oracle.com/cd/E11882_01/server.112/e26088/sql_elements006.htm#SQLRF50903
And
http://docs.oracle.com/cd/E11882_01/server.112/e16638/hintsref.htm
Edited by: Girish Sharma on May 8, 2012 3:53 PM

Similar Messages

  • RULE hint and 11g

    Oracle Standard Edition 11.1.0.7.0
    We all know that the RULE hint is not longer supported, so in that case why would Oracle themselves want to use it ?
    select parsing_schema_id,sql_Text from v$sqlarea where upper(sql_text) like '%+ RULE%' or upper(sql_text) like '%+RULE%'
    I get 7 rows back from my 11gR1 database (and many more from 10gR2)
    Basically, we have a bunch of issues with parsing SQL in a 10gR2 environment, upgrading from 9iR2, setting optimizer_features_enable down at lower releases, as far as the minimum 8.0.3, does provide quicker parses with still acceptable plans, but RULE hint gives the best parse, so wondering about the support situation if we deplot it tactically. Oracle can hardly object if the RDBMS itself uses the hint, surely ?

    It was already in version 10g that the OPTIMIZER_MODE=RULE was desupported.
    "Desupported" does not mean it is no longer technically possible to use RULE nor does it mean that we do not use it anymore internally. It just means that it is no longer supported that you use this optimizer mode.
    In other words: Almost no testing was done with OPTIMIZER_MODE=RULE, and if you turn it on and you get any problems, our support will not be responsible to help you because of that setting.
    If on the other hand it turns out that for troubleshooting purpose it is necessary to go with that mode for certain statements (because our support came to that conclusion), it will be possible to use it of course without you losing further support.
    Kind regards
    Uwe
    http://uhesse.wordpress.com

  • Parallel hint in OBIEE 11g

    Dear All,
    I am new to OBIEE. Can any one tell me how to add parallel hint in 11g. Is Oracle BI Presentation Service ignores any DB Hint added to query while parsing. If yes, how to overcome this. We need to add parallel hint in few report to make things faster, i do not want to touch the table level hints as it is affecting my performance.
    I have gone through oracle doc ID 823193.1
    Thanks and Regards,
    Anand.

    Hi Jay,
    Thanks for your reply.
    can you please give a practical example by working in a sqlplus. I tried and got below error. Please help.
    SQL>  select * from t;
             N
             1
    SQL>  select n from t;
             N
             1
    SQL> select /*+PARALLEL (t,2)*/ n from t;
             N
             1
    SQL>  select EVALUATE('/*+PARALLEL (t,2)*/',t."n") from t;
    select EVALUATE('/*+PARALLEL (t,2)*/',t."n") from t
    ERROR at line 1:
    ORA-00904: "T"."n": invalid identifierRegards,
    Anand.

  • Jdeveloper 11g Migration to 11.1.1.0.1 build 5188

    Hi Jdev team,
    1) the new update 11.1.1.0.1 build 5188 is out, but on the download site the filenames are still jdevstudio11110install.exe and jdevstudio11110install.bin
    Has some one a good explanation for this dirty updating approach?
    2) After installing the new Jdev version (11.1.1.0.1 build 5188) I migrated my project (project files, jstl, weblogic-application.xml, and what ever) and build the new EAR file. Now I am trying to redeploy this EAR on our integration system (which is already out to the customer) WLS103 on OEL 5.x . Of course I get the following exception:
    ERR An error occurred during activation of changes, please see the log for details.
    ERR Error weblogic.management.DeploymentException:
    ERR Error oracle.adf.share.weblogic.listeners.ADFApplicationLifecycleListener
    INFO Success Selected Deployments were updated.
    I think because the ADF Runtime Libs are still in version adf.oracle.domain(1.0,11.1.1.0.0)
    So what is the official migration path?
    Thanks for any advices,
    Andreas.

    Hi John,
    Just start the online update tool.
    You will see a hint: „JDeveloper 11g (11.1.1.0.1) is Aviable.“
    Press the „Select All“ button, then „Next“.
    Check the „Summery“ box.
    Click Finish and see the „Confirm Exit“ text and press „Yes“ to restart JDeveloper.
    And now after running this course and rechecking the result against your (very comprehensible) assumptions tell me something about professionalism...
    I wasn't talking about any whatever update in the future, but about this very real one.
    Sorry John, but sarcasm from your site is absolutely inopportune at this point.
    Andre

  • ClassNotFoundException when running a migrated app from 11g TP to 11.1.1.0

    Hello,
    I have a application that works fine in 11g TP. After migrated to 11.1.1.0, I am getting the following error when trying to run application:
    <09/03/2009 15h02min40s BRT> <Error> <Deployer> <BEA-149265> <Failure occurred in the execution of deployment request with ID '1236621745028' for task '0'. Error is: 'weblogic.application.ModuleException: Failed to load webapp: 'Siplag2''
    weblogic.application.ModuleException: Failed to load webapp: 'Siplag2'
         at weblogic.servlet.internal.WebAppModule.prepare(WebAppModule.java:387)
         at weblogic.application.internal.flow.ScopedModuleDriver.prepare(ScopedModuleDriver.java:176)
         at weblogic.application.internal.flow.ModuleListenerInvoker.prepare(ModuleListenerInvoker.java:93)
         at weblogic.application.internal.flow.DeploymentCallbackFlow$1.next(DeploymentCallbackFlow.java:387)
         at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:37)
         Truncated. see log file for complete stacktrace
    java.lang.ClassNotFoundException: logus.security.viewcontroller.AuthenticationFilter
         at weblogic.utils.classloaders.GenericClassLoader.findLocalClass(GenericClassLoader.java:283)
         at weblogic.utils.classloaders.GenericClassLoader.findClass(GenericClassLoader.java:256)
         at weblogic.utils.classloaders.ChangeAwareClassLoader.findClass(ChangeAwareClassLoader.java:54)
         at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
         at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
    It's strange, because I'm sure the class logus.security.viewcontroller.AuthenticationFilter is in a .jar of the application's classpath, so that when I look for the library at C:\oracle\Middleware\jdeveloper\system\system11.1.1.0.31.51.88\o.j2ee\drs\Siplag2\Siplag2\WEB-INF\lib, it is there.
    Anyone have any idea?
    Luiz

    Hi John,
    Just start the online update tool.
    You will see a hint: „JDeveloper 11g (11.1.1.0.1) is Aviable.“
    Press the „Select All“ button, then „Next“.
    Check the „Summery“ box.
    Click Finish and see the „Confirm Exit“ text and press „Yes“ to restart JDeveloper.
    And now after running this course and rechecking the result against your (very comprehensible) assumptions tell me something about professionalism...
    I wasn't talking about any whatever update in the future, but about this very real one.
    Sorry John, but sarcasm from your site is absolutely inopportune at this point.
    Andre

  • Regarding RULE Hint Removal

    Hi ..
    We have an application having 40+ SQL's using RULE Hint. (11g R2).
    Now we have a plan to upgrade to 12c and we want to come out of these RULE Hints.
    Anyone faced similar kind of issue? what are do's and don't do's to remove RULE Hint. Please advise.
    Thank you!
    Regards
    Siva
    Edited by: 985936 on Feb 4, 2013 3:33 AM

    It looks like the /*+ RULE */ hint can still have an impact in 11.2.0.3:
    07:23:12 SQL> select * from v$version;
    BANNER
    Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
    PL/SQL Release 11.2.0.3.0 - Production
    CORE    11.2.0.3.0      Production
    TNS for Solaris: Version 11.2.0.3.0 - Production
    NLSRTL Version 11.2.0.3.0 - Production
    5 rows selected.
    Elapsed: 00:00:00.04
    07:23:20 SQL> create table test_rule_optimizer  as select * from dba_objects;
    Table created.
    Elapsed: 00:00:03.04
    07:23:23 SQL> create index TEST_RULE_OPTIMIZER_IDX on TEST_RULE_OPTIMIZER(object_type, owner, object_name);
    Index created.
    Elapsed: 00:00:01.32
    07:23:24 SQL>
    07:23:24 SQL> begin
    07:23:25   2    dbms_stats.gather_table_stats(ownname => user, tabname => 'TEST_RULE_OPTIMIZER');
    07:23:25   3  end;
    07:23:25   4  /
    PL/SQL procedure successfully completed.
    Elapsed: 00:00:03.91
    07:23:29 SQL>
    07:23:45 SQL> set autotrace on
    07:23:45 SQL> --
    07:23:45 SQL> -- Choosing these object types because they comprise over 50% of the objects in my table
    07:23:45 SQL> select count(*), max(last_ddl_time)
    07:23:45   2  from TEST_RULE_OPTIMIZER
    07:23:45   3  where object_type in ('INDEX','SYNONYM','INDEX PARTITION','LOB PARTITION');
      COUNT(*) MAX(LAST_DDL_TIME)
        136189 2013/02/04 04:17:04
    1 row selected.
    Elapsed: 00:00:00.12
    Execution Plan
    Plan hash value: 166585403
    | Id  | Operation          | Name                | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT   |                     |     1 |    19 |  1078   (2)| 00:00:01 |
    |   1 |  SORT AGGREGATE    |                     |     1 |    19 |            |          |
    |*  2 |   TABLE ACCESS FULL| TEST_RULE_OPTIMIZER | 19721 |   365K|  1078   (2)| 00:00:01 |
    Predicate Information (identified by operation id):
       2 - filter("OBJECT_TYPE"='INDEX' OR "OBJECT_TYPE"='INDEX PARTITION' OR
                  "OBJECT_TYPE"='LOB PARTITION' OR "OBJECT_TYPE"='SYNONYM')
    Statistics
              1  recursive calls
              0  db block gets
           3850  consistent gets
              0  physical reads
              0  redo size
            275  bytes sent via SQL*Net to client
            248  bytes received via SQL*Net from client
              2  SQL*Net roundtrips to/from client
              0  sorts (memory)
              0  sorts (disk)
              1  rows processed
    07:23:46 SQL>
    07:23:46 SQL> select /*+ rule */ count(*), max(last_ddl_time)
    07:23:46   2  from TEST_RULE_OPTIMIZER
    07:23:46   3  where object_type in ('INDEX','SYNONYM','INDEX PARTITION','LOB PARTITION');
      COUNT(*) MAX(LAST_DDL_TIME)
        136189 2013/02/04 04:17:04
    1 row selected.
    Elapsed: 00:00:00.29
    Execution Plan
    Plan hash value: 316642056
    | Id  | Operation                     | Name                    |
    |   0 | SELECT STATEMENT              |                         |
    |   1 |  SORT AGGREGATE               |                         |
    |   2 |   CONCATENATION               |                         |
    |   3 |    TABLE ACCESS BY INDEX ROWID| TEST_RULE_OPTIMIZER     |
    |*  4 |     INDEX RANGE SCAN          | TEST_RULE_OPTIMIZER_IDX |
    |   5 |    TABLE ACCESS BY INDEX ROWID| TEST_RULE_OPTIMIZER     |
    |*  6 |     INDEX RANGE SCAN          | TEST_RULE_OPTIMIZER_IDX |
    |   7 |    TABLE ACCESS BY INDEX ROWID| TEST_RULE_OPTIMIZER     |
    |*  8 |     INDEX RANGE SCAN          | TEST_RULE_OPTIMIZER_IDX |
    |   9 |    TABLE ACCESS BY INDEX ROWID| TEST_RULE_OPTIMIZER     |
    |* 10 |     INDEX RANGE SCAN          | TEST_RULE_OPTIMIZER_IDX |
    Predicate Information (identified by operation id):
       4 - access("OBJECT_TYPE"='LOB PARTITION')
       6 - access("OBJECT_TYPE"='INDEX PARTITION')
       8 - access("OBJECT_TYPE"='SYNONYM')
      10 - access("OBJECT_TYPE"='INDEX')
    Note
       - rule based optimizer used (consider using cbo)
    Statistics
              1  recursive calls
              0  db block gets
          37884  consistent gets
              3  physical reads
              0  redo size
            276  bytes sent via SQL*Net to client
            248  bytes received via SQL*Net from client
              2  SQL*Net roundtrips to/from client
              0  sorts (memory)
              0  sorts (disk)
              1  rows processed
    07:23:46 SQL>
    07:23:47 SQL>

  • Nested Loop in Oracle 11g

    Hi All,
    I recently upgraded my Oracle DB from 10.2.0.4 to 11.2.0.3 on Aix 6.1
    My below query is very slow after the upgrade
    select count(*) from v$lock where block > 0;
    I compared the explain plan and found that in 11g its using HASH JOIN while in 10g its using Nested Loop
    When I am giving NL hint in 11g its returning fast.
    I check almost all optimizer related DB parameters and its all are same as it in 10g.
    Has anyone faced this issue in your DB upgrade or help me to find the reason
    Thanks in advance

    user12207083 wrote:
    Thanks
    But how come explan plan change for dynamic views
    ThanksOrdered hint used in case of that query extracting from multiple tables, To define driving of that particular tables.
    There are changes in explain plan. Am in learning stage in PT, You can expect response from Jonathan Lewis
    Am just comparing those two explain plans.
    SQL> set timing on
    SQL> select count(*) from v$lock t1;
      COUNT(*)
           168
    Elapsed: 00:00:00.01
    SQL> select /*+ ordered */ count(*) from v$lock;
      COUNT(*)
           168
    Elapsed: 00:00:00.02
    SQL>
    SQL> set autotrace traceonly explain;
    SQL> set line 500
    SQL> select count(*) from v$lock t1;
    Elapsed: 00:00:00.00
    Execution Plan                          "Without HINT"
    Plan hash value: 2329815124
    | Id  | Operation                 | Name            | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT          |                 |     1 |    50 |     1 (100)| 00:00:01 |
    |   1 |  SORT AGGREGATE           |                 |     1 |    50 |            |          |
    |   2 |   NESTED LOOPS            |                 |     1 |    50 |     1 (100)| 00:00:01 |
    |*  3 |    HASH JOIN              |                 |     1 |    44 |     1 (100)| 00:00:01 |
    |*  4 |     FIXED TABLE FULL      | X$KSUSE         |     1 |    19 |     0   (0)| 00:00:01 |
    |   5 |     VIEW                  | GV$_LOCK        |    10 |   250 |     0   (0)| 00:00:01 |
    |   6 |      UNION-ALL            |                 |       |       |            |          |
    |*  7 |       FILTER              |                 |       |       |            |          |
    |   8 |        VIEW               | GV$_LOCK1       |     2 |   178 |     0   (0)| 00:00:01 |
    |   9 |         UNION-ALL         |                 |       |       |            |          |
    |* 10 |          FIXED TABLE FULL | X$KDNSSF        |     1 |   102 |     0   (0)| 00:00:01 |
    |* 11 |          FIXED TABLE FULL | X$KSQEQ         |     1 |   102 |     0   (0)| 00:00:01 |
    |* 12 |       FIXED TABLE FULL    | X$KTADM         |     1 |   102 |     0   (0)| 00:00:01 |
    |* 13 |       FIXED TABLE FULL    | X$KTATRFIL      |     1 |   102 |     0   (0)| 00:00:01 |
    |* 14 |       FIXED TABLE FULL    | X$KTATRFSL      |     1 |   102 |     0   (0)| 00:00:01 |
    |* 15 |       FIXED TABLE FULL    | X$KTATL         |     1 |   102 |     0   (0)| 00:00:01 |
    |* 16 |       FIXED TABLE FULL    | X$KTSTUSC       |     1 |   102 |     0   (0)| 00:00:01 |
    |* 17 |       FIXED TABLE FULL    | X$KTSTUSS       |     1 |   102 |     0   (0)| 00:00:01 |
    |* 18 |       FIXED TABLE FULL    | X$KTSTUSG       |     1 |   102 |     0   (0)| 00:00:01 |
    |* 19 |       FIXED TABLE FULL    | X$KTCXB         |     1 |   102 |     0   (0)| 00:00:01 |
    |* 20 |    FIXED TABLE FIXED INDEX| X$KSQRS (ind:1) |     1 |     6 |     0   (0)| 00:00:01 |
    Predicate Information (identified by operation id):
       3 - access("SADDR"="S"."ADDR")
       4 - filter("S"."INST_ID"=USERENV('INSTANCE'))
       7 - filter(USERENV('INSTANCE') IS NOT NULL)
      10 - filter(("KSQLKMOD"<>0 OR "KSQLKREQ"<>0) AND "INST_ID"=USERENV('INSTANCE') AND
                  BITAND("KSSOBFLG",1)<>0)
      11 - filter(("KSQLKMOD"<>0 OR "KSQLKREQ"<>0) AND "INST_ID"=USERENV('INSTANCE') AND
                  BITAND("KSSOBFLG",1)<>0)
      12 - filter(("KSQLKMOD"<>0 OR "KSQLKREQ"<>0) AND "INST_ID"=USERENV('INSTANCE') AND
                  BITAND("KSSOBFLG",1)<>0)
      13 - filter(("KSQLKMOD"<>0 OR "KSQLKREQ"<>0) AND "INST_ID"=USERENV('INSTANCE') AND
                  BITAND("KSSOBFLG",1)<>0)
      14 - filter(("KSQLKMOD"<>0 OR "KSQLKREQ"<>0) AND "INST_ID"=USERENV('INSTANCE') AND
                  BITAND("KSSOBFLG",1)<>0)
      15 - filter(("KSQLKMOD"<>0 OR "KSQLKREQ"<>0) AND "INST_ID"=USERENV('INSTANCE') AND
                  BITAND("KSSOBFLG",1)<>0)
      16 - filter(("KSQLKMOD"<>0 OR "KSQLKREQ"<>0) AND "INST_ID"=USERENV('INSTANCE') AND
                  BITAND("KSSOBFLG",1)<>0)
      17 - filter(("KSQLKMOD"<>0 OR "KSQLKREQ"<>0) AND "INST_ID"=USERENV('INSTANCE') AND
                  BITAND("KSSOBFLG",1)<>0)
      18 - filter(("KSQLKMOD"<>0 OR "KSQLKREQ"<>0) AND "INST_ID"=USERENV('INSTANCE') AND
                  BITAND("KSSOBFLG",1)<>0)
      19 - filter(("KSQLKMOD"<>0 OR "KSQLKREQ"<>0) AND "INST_ID"=USERENV('INSTANCE') AND
                  BITAND("KSSPAFLG",1)<>0)
      20 - filter("RADDR"="R"."ADDR")
    SQL>  select /*+ ordered */ count(*) from v$lock;                                "ORDERED HINT"
    Elapsed: 00:00:00.01
    Execution Plan                                                                 
    Plan hash value: 3174212559
    | Id  | Operation                 | Name            | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT          |                 |     1 |    50 |     1 (100)| 00:00:01 |
    |   1 |  SORT AGGREGATE           |                 |     1 |    50 |            |          |
    |   2 |   NESTED LOOPS            |                 |     1 |    50 |     1 (100)| 00:00:01 |
    |*  3 |    HASH JOIN              |                 |     1 |    44 |     1 (100)| 00:00:01 |
    |   4 |     VIEW                  | GV$_LOCK        |    10 |   250 |     0   (0)| 00:00:01 |
    |   5 |      UNION-ALL            |                 |       |       |            |          |
    |*  6 |       FILTER              |                 |       |       |            |          |
    |   7 |        VIEW               | GV$_LOCK1       |     2 |   178 |     0   (0)| 00:00:01 |
    |   8 |         UNION-ALL         |                 |       |       |            |          |
    |*  9 |          FIXED TABLE FULL | X$KDNSSF        |     1 |   102 |     0   (0)| 00:00:01 |
    |* 10 |          FIXED TABLE FULL | X$KSQEQ         |     1 |   102 |     0   (0)| 00:00:01 |
    |* 11 |       FIXED TABLE FULL    | X$KTADM         |     1 |   102 |     0   (0)| 00:00:01 |
    |* 12 |       FIXED TABLE FULL    | X$KTATRFIL      |     1 |   102 |     0   (0)| 00:00:01 |
    |* 13 |       FIXED TABLE FULL    | X$KTATRFSL      |     1 |   102 |     0   (0)| 00:00:01 |
    |* 14 |       FIXED TABLE FULL    | X$KTATL         |     1 |   102 |     0   (0)| 00:00:01 |
    |* 15 |       FIXED TABLE FULL    | X$KTSTUSC       |     1 |   102 |     0   (0)| 00:00:01 |
    |* 16 |       FIXED TABLE FULL    | X$KTSTUSS       |     1 |   102 |     0   (0)| 00:00:01 |
    |* 17 |       FIXED TABLE FULL    | X$KTSTUSG       |     1 |   102 |     0   (0)| 00:00:01 |
    |* 18 |       FIXED TABLE FULL    | X$KTCXB         |     1 |   102 |     0   (0)| 00:00:01 |
    |* 19 |     FIXED TABLE FULL      | X$KSUSE         |     1 |    19 |     0   (0)| 00:00:01 |
    |* 20 |    FIXED TABLE FIXED INDEX| X$KSQRS (ind:1) |     1 |     6 |     0   (0)| 00:00:01 |
    Predicate Information (identified by operation id):
       3 - access("SADDR"="S"."ADDR")
       6 - filter(USERENV('INSTANCE') IS NOT NULL)
       9 - filter(("KSQLKMOD"<>0 OR "KSQLKREQ"<>0) AND "INST_ID"=USERENV('INSTANCE') AND
                  BITAND("KSSOBFLG",1)<>0)
      10 - filter(("KSQLKMOD"<>0 OR "KSQLKREQ"<>0) AND "INST_ID"=USERENV('INSTANCE') AND
                  BITAND("KSSOBFLG",1)<>0)
      11 - filter(("KSQLKMOD"<>0 OR "KSQLKREQ"<>0) AND "INST_ID"=USERENV('INSTANCE') AND
                  BITAND("KSSOBFLG",1)<>0)
      12 - filter(("KSQLKMOD"<>0 OR "KSQLKREQ"<>0) AND "INST_ID"=USERENV('INSTANCE') AND
                  BITAND("KSSOBFLG",1)<>0)
      13 - filter(("KSQLKMOD"<>0 OR "KSQLKREQ"<>0) AND "INST_ID"=USERENV('INSTANCE') AND
                  BITAND("KSSOBFLG",1)<>0)
      14 - filter(("KSQLKMOD"<>0 OR "KSQLKREQ"<>0) AND "INST_ID"=USERENV('INSTANCE') AND
                  BITAND("KSSOBFLG",1)<>0)
      15 - filter(("KSQLKMOD"<>0 OR "KSQLKREQ"<>0) AND "INST_ID"=USERENV('INSTANCE') AND
                  BITAND("KSSOBFLG",1)<>0)
      16 - filter(("KSQLKMOD"<>0 OR "KSQLKREQ"<>0) AND "INST_ID"=USERENV('INSTANCE') AND
                  BITAND("KSSOBFLG",1)<>0)
      17 - filter(("KSQLKMOD"<>0 OR "KSQLKREQ"<>0) AND "INST_ID"=USERENV('INSTANCE') AND
                  BITAND("KSSOBFLG",1)<>0)
      18 - filter(("KSQLKMOD"<>0 OR "KSQLKREQ"<>0) AND "INST_ID"=USERENV('INSTANCE') AND
                  BITAND("KSSPAFLG",1)<>0)
      19 - filter("S"."INST_ID"=USERENV('INSTANCE'))
      20 - filter("RADDR"="R"."ADDR")
    SQL>

  • Dbms_lob , where did my time go ?

    Hi all
    After using 10046 to identify the sql that is causing the slowness in a program “ less commits cause my program to go slower” i realised that i am missing something ,
    There was a lot of time missing in the tkprof file , and no sql or wait event allocate the missing time , so i put the following test case together in an attempt to understand where the time is going .
    Version of test database : 11.1.0.6.0
    Name of test database: stdby ( :-) used my standby database)
    Database non-default values
    #     Parameter     Value1
    1:     audit_file_dest     /u01/app/oracle/admin/stdby/adump
    2:     audit_trail     DB
    3:     compatible     11.1.0.0.0
    4:     control_files     /u01/app/oracle/oradata/stdby/control01.ctl
    5:     control_files     /u01/app/oracle/oradata/stdby/control02.ctl
    6:     control_files     /u01/app/oracle/oradata/stdby/control03.ctl
    7:     db_block_size     8192
    8:     db_domain     
    9:     db_name     stdby
    10:     db_recovery_file_dest     /u01/app/oracle/flash_recovery_area
    11:     db_recovery_file_dest_size     2147483648
    12:     diagnostic_dest     /u01/app/oracle
    13:     dispatchers     (PROTOCOL=TCP) (SERVICE=stdbyXDB)
    14:     memory_target     314572800
    15:     open_cursors     300
    16:     processes     150
    17:     remote_login_passwordfile     EXCLUSIVE
    18:     undo_tablespace     UNDOTBS1More accurately I used existing example from http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:4084920819312
    I hope Tom does not mind .
    create table t ( x clob );
    create or replace procedure p( p_open_close in boolean default false,
                                     p_iters in number default 100 )
      as
          l_clob clob;
      begin
          insert into t (x) values ( empty_clob() )
          returning x into l_clob;
          if ( p_open_close )
          then
              dbms_lob.open( l_clob, dbms_lob.lob_readwrite );
          end if;
          for i in 1 .. p_iters
          loop
              dbms_lob.WriteAppend( l_clob, 5, 'abcde' );
          end loop;
          if ( p_open_close )
          then
        dbms_lob.close( l_clob );
    end if;
    commit;
    end;I did the tracing and the run of the pkg with this
    alter session set timed_statistics = true;
    alter session set max_dump_file_size = unlimited;
    alter session set tracefile_identifier = 'test_clob_commit';
    alter session set events '10046 trace name context forever, level 12';
    exec p(TRUE,20000);
    exitDid the tkprof of the 10046 trace file with
    tkprof stdby_ora_3656_test_clob_commit.trc stdby_ora_3656_test_clob_commit.trc.tkp sort=(prsela,exeela,fchela) aggregate=yes waits=yes sys=yesWith output of
    OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        1      0.02       0.02          0          0          0           0
    Execute      1     46.89     147.81      38915     235267     492471           1
    Fetch        0      0.00       0.00          0          0          0           0
    total        2     46.92     147.83      38915     235267     492471           1
    Misses in library cache during parse: 1
    Elapsed times include waiting on following events:
      Event waited on                             Times   Max. Wait  Total Waited
      ----------------------------------------   Waited  ----------  ------------
      SQL*Net message to client                       2        0.00          0.00
      SQL*Net message from client                     2        0.00          0.00
      latch: shared pool                             24        0.05          0.07
      latch: row cache objects                        2        0.00          0.00
      log file sync                                   1        0.01          0.01
    OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
    call     count       cpu    elapsed       disk      query    current        rows
    Parse      117      0.11       0.10          0          0          2           0
    Execute    426      0.37       0.40          6          4          9           2
    Fetch      645      0.17       0.51         63       1507          0        1952
    total     1188      0.65       1.03         69       1511         11        1954
    Misses in library cache during parse: 22
    Misses in library cache during execute: 22
    Elapsed times include waiting on following events:
      Event waited on                             Times   Max. Wait  Total Waited
      ----------------------------------------   Waited  ----------  ------------
      db file sequential read                     19778        1.12         30.31
      direct path write                           19209        0.00          0.44
      direct path read                            19206        0.00          0.37
      log file switch completion                      8        0.20          0.70
      latch: cache buffers lru chain                  5        0.01          0.02
        3  user  SQL statements in session.
      424  internal SQL statements in session.
      427  SQL statements in session.And it’s here where the time is being lost.The time of the main pkg p(TRUE,2000) takes 147.83 sec, which is correct , but what is making this time up.
    From sorted trace file
    SQL ID : catnjk0zv6jz1
    BEGIN p(TRUE,20000); END;
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        1      0.02       0.02          0          0          0           0
    Execute      1     46.89     147.81      38915     235267     492471           1
    Fetch        0      0.00       0.00          0          0          0           0
    total        2     46.92     147.83      38915     235267     492471           1
    Misses in library cache during parse: 1
    Optimizer mode: ALL_ROWS
    Parsing user id: 81
    Elapsed times include waiting on following events:
      Event waited on                             Times   Max. Wait  Total Waited
      ----------------------------------------   Waited  ----------  ------------
      latch: shared pool                             24        0.05          0.07
      latch: row cache objects                        2        0.00          0.00
      log file sync                                   1        0.01          0.01
      SQL*Net message to client                       1        0.00          0.00
      SQL*Net message from client                     1        0.00          0.00
    SQL ID : db78fxqxwxt7r
    select /*+ rule */ bucket, endpoint, col#, epvalue
    from
    histgrm$ where obj#=:1 and intcol#=:2 and row#=:3 order by bucket
    intresting , oracle is still using the rule hint in 11g ?
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        3      0.00       0.00          0          0          0           0
    Execute     98      0.05       0.05          0          0          0           0
    Fetch       98      0.04       0.17         28        294          0        1538
    total      199      0.10       0.22         28        294          0        1538
    Misses in library cache during parse: 0
    Optimizer mode: RULE
    Parsing user id: SYS   (recursive depth: 3)
    Rows     Row Source Operation
         20  SORT ORDER BY (cr=3 pr=1 pw=1 time=8 us cost=0 size=0 card=0)
         20   TABLE ACCESS CLUSTER HISTGRM$ (cr=3 pr=1 pw=1 time=11 us)
          1    INDEX UNIQUE SCAN I_OBJ#_INTCOL# (cr=2 pr=0 pw=0 time=0 us)(object id 408)
    Elapsed times include waiting on following events:
      Event waited on                             Times   Max. Wait  Total Waited
      ----------------------------------------   Waited  ----------  ------------
      db file sequential read                        28        0.02          0.12
    SQL ID : 5n1fs4m2n2y0r
    select pos#,intcol#,col#,spare1,bo#,spare2,spare3
    from
    icol$ where obj#=:1
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        2      0.00       0.00          0          0          0           0
    Execute     19      0.03       0.03          0          0          0           0
    Fetch       60      0.00       0.04          1        120          0          41
    total       81      0.04       0.08          1        120          0          41
    Misses in library cache during parse: 1
    Misses in library cache during execute: 1
    Optimizer mode: CHOOSE
    Parsing user id: SYS   (recursive depth: 2)
    Rows     Row Source Operation
          1  TABLE ACCESS BY INDEX ROWID ICOL$ (cr=4 pr=0 pw=0 time=0 us cost=2 size=54 card=2)
          1   INDEX RANGE SCAN I_ICOL1 (cr=3 pr=0 pw=0 time=0 us cost=1 size=0 card=2)(object id 42)
    Elapsed times include waiting on following events:
      Event waited on                             Times   Max. Wait  Total Waited
      ----------------------------------------   Waited  ----------  ------------
      db file sequential read                         1        0.04          0.04None of the parse , execute ,fetch and wait times makes up the 147.83 seconds.
    So i turned to oracles trcanlzr.sql that Carlos Sierra wrote and parsed the same trace file to find the offending sql .
    And it starts getting intrestting
    Trace Analyzer 11.2.6.2 Report: trcanlzr_75835.html
    stdby_ora_3656_test_clob_commit.trc (6970486 bytes)
    Total Trace Response Time: 148.901 secs.
    2009-MAY-03 20:03:51.771 (start of first db call in trace).
    2009-MAY-03 20:06:20.672 (end of last db call in trace).
    RESPONSE TIME SUMMARY
    ~~~~~~~~~~~~~~~~~~~~~
                                              pct of                  pct of                  pct of
                                    Time       total        Time       total        Time       total
    Response Time Component    (in secs)   resp time   (in secs)   resp time   (in secs)   resp time
                        CPU:      47.579       32.0%
              Non-idle Wait:       0.467        0.3%
         ET Unaccounted-for:     100.825       67.7%
           Total Elapsed(1):                             148.871      100.0%
                  Idle Wait:                               0.001        0.0%
         RT Unaccounted-for:                               0.029        0.0%
          Total Response(2):                                                     148.901      100.0%
    (1) Total Elapsed = "CPU" + "Non-Idle Wait" + "ET Unaccounted-for".
    (2) Total Response = "Total Elapsed Time" + "Idle Wait" + "RT Unaccounted-for".
    Total Accounted-for = "CPU" + "Non-Idle Wait" + "Idle Wait" = 148.872 secs.
    Total Unccounted-for = "ET Unaccounted-for" + "RT Unaccounted-for" = 100.854 secs.{font:Courier}
    {color:red}
    {size:19}100.825 seconds Wow , that is a lot 67.7 % of the time is not accounted for {size}
    {color}
    {font}
    I even used TVD$XTAT TriVaDis eXtended Tracefile Analysis Tool with the same conclution .
    {font:Courier}
    {color:green}
    {size:19}Looking at the raw trace file i see a lot of lines like this{size}
    {color}
    {font}
    WAIT #7: nam='direct path read' ela= 11 file number=4 first dba=355935 block cnt=1 obj#=71067 tim=1241337833498756
    WAIT #7: nam='direct path write' ela= 12 file number=4 first dba=355936 block cnt=1 obj#=71067 tim=1241337833499153
    WAIT #7: nam='db file sequential read' ela= 1095 file#=4 block#=399 blocks=1 obj#=71067 tim=1241337833501366{font:Courier}
    {color:green}
    {size:19}
    What is even more interesting is the sql for "PARSING IN CURSOR #7" is not in the trace file !
    The question is where is the time going or is the parser of the 10046 trace file just not putting the detail in ? How do i fix this, without speculating, if I do not know where the problem is ?
    I thought of doing a strace on the process . Where else can i look for my 100 sec
    Please point me in a direction where i can look for my 100,825 seconds as this is a test case with a production system that is loosing the same amount of time but with a lot more sql arround its dbms_lob.writeappend.
    {size}
    {color}
    {font}
    Edited by: user5174849 on 2009/05/16 11:17 PM

    user5174849 wrote:
    After using 10046 to identify the sql that is causing the slowness in a program “ less commits cause my program to go slower” i realised that i am missing something ,
    There was a lot of time missing in the tkprof file , and no sql or wait event allocate the missing time , so i put the following test case together in an attempt to understand where the time is going .
    Version of test database : 11.1.0.6.0
    What is even more interesting is the sql for "PARSING IN CURSOR #7" is not in the trace file !
    The question is where is the time going or is the parser of the 10046 trace file just not putting the detail in ? How do i fix this, without speculating, if I do not know where the problem is ?
    I thought of doing a strace on the process . Where else can i look for my 100 sec
    Please point me in a direction where i can look for my 100,825 seconds as this is a test case with a production system that is loosing the same amount of time but with a lot more sql arround its dbms_lob.writeappend.I guess that the separate cursor that is opened for the LOB operation is where the time is spent, and unfortunately this part is not very well exposed via the usual interfaces (V$SQL, 10046 trace file etc).
    You might want to read this post where Kerry identifies the offending SQL via V$OPEN_CURSOR: http://kerryosborne.oracle-guy.com/2009/04/hidden-sql-why-cant-i-find-my-sql-text/
    The waits of this cursor #7 are quite likely rather relevant since they probably show you what the LOB operation is waiting for.
    The LOB is created with the default NOCACHE attribute therefore it's read and written using direct path operations.
    Regards,
    Randolf
    Oracle related stuff blog:
    http://oracle-randolf.blogspot.com/
    SQLTools++ for Oracle (Open source Oracle GUI for Windows):
    http://www.sqltools-plusplus.org:7676/
    http://sourceforge.net/projects/sqlt-pp/

  • ASM Buffer Cache - which parameter is responsible for this?

    Env: Oracle 10.2.0.4.0 on Windows 2003 R2 32 bit
    In one of my testing databases, I saw this. Rest all databases (development and testing) do not have the component "ASM Buffer Cache".
    SQL> select component, current_size, user_specified_size from v$sga_dynamic_components;
    COMPONENT                          CURRENT_SIZE USER_SPECIFIED_SIZE
    shared pool                         553,648,128         209,715,200
    large pool                            4,194,304                   0
    java pool                             4,194,304                   0
    streams pool                                  0                   0
    DEFAULT buffer cache                360,710,144         314,572,800
    KEEP buffer cache                             0                   0
    RECYCLE buffer cache                          0                   0
    DEFAULT 2K buffer cache                       0                   0
    DEFAULT 4K buffer cache                       0                   0
    DEFAULT 8K buffer cache                       0                   0
    DEFAULT 16K buffer cache                      0                   0
    DEFAULT 32K buffer cache                      0                   0
    ASM Buffer Cache                              0         314,572,800I am not able to figure out from the component "ASM Buffer Cache" is coming in this list. Current_size is zero so its not of a concern actually but I was wondering which parameter enforces this value.
    Can anybody shed some light on this?
    Regards,
    Message was edited by:
    Satish Kandi
    Forgot to mention that we are not using ASM at all.

    I have some databases running on 10.2.0.3.0 (testing + dev) and others on 10.2.0.4.0 (dev databases) and I can see this component in all of them.
    I have no databases running at earlier versions of 10g so cannot confirm if it was there earlier too.
    With your hint of 11g in mind, I searched 11g documentation too and could not find any references to this component.

  • Can we use hints in oracle 11g version ?

    can we use hints in oracle 11g version ? is it working ??

    Why do you ask these questions? Have you looked at the SQL Reference Guide and Performance Tuning Guide for your Oracle version - both which covers using hints?
    Have you see a statement that is not supported? Or does not work?
    Or are you simply doing idle speculation and expecting forum members to spend their free time in answering a basic question where the answer is ridiculously simply to find?

  • Need to use Hint for Select Query  11g

    Hi,
    I have a select query which is fetching data from multiple table.
    I just need 10 or less rows, already I m using rownum <=10
    Could you tell which is the better choice for using HINT.
    /*+ FIRST_ROWS(10) */      (or)    /*+ all_rows */
    Thanks.

    On Oracle 11.2.0.3 and 11.1.0.7 on my test table with an ORDER BY in the query, I found FIRST_ROWS using the index to get sorted rows and ALL_ROWS retrieving 10 rows from a full scan and then sorting them.
    On Oracle  I didn't find any difference in plan on a different, physically smaller, table.
    For the ALL_ROWS version the optimiser already knows that there will only be 10 rows returned.
    The performance difference: As usual, only use FIRST_ROWS if you actually intend to fetch less than the full data set. If you intend to fetch all 10 rows, use ALL_ROWS, which should be the default (taken from the optimizer_mode system parameter).

  • Elapsed time went up from 1min to 22min after migrating from 10g to 11g

    I just migrated one of my database from 10.2.0.2(Red hat Linux, 2 node RAC, sga= 1Gb) to 11.2.0.1 (red Hat Linux 2 Node RAC, SGA=7GB)
    The timing for one of the specific query shoot up from 1min to 22 min.
    Following is the query:
    SELECT /*+ gather_plan_statistics */   docr.DRCONTENT
        FROM      WRPADMIN.T_DOCREPORT docr, WRPADMIN.t_document doc
               WHERE doc.docid = docr.docid
       AND 294325 = doc.rdocid
               AND ( ( ( (EXISTS
                             (SELECT   'X'
                                FROM   WRPADMIN.t_mastermap mstm1,
                                       WRPADMIN.t_docdimmap docdim1
                               WHERE       doc.docid = mstm1.docid
                                       AND mstm1.dimlvlid = 2
                                       AND mstm1.mstmapid = docdim1.mstmapid
                                       AND docdim1.dimid IN (86541))))
                      OR (EXISTS
                             (SELECT   'X'
                                FROM   WRPADMIN.t_mastermap mstm2,
                                       WRPADMIN.t_docdimmap docdim2
                               WHERE       doc.rdocid = mstm2.rdocid
                                       AND mstm2.dimlvlid = 1
                                       AND mstm2.mstmapid = docdim2.mstmapid
                                       AND docdim2.dimid IN (28388)))))
    ORDER BY   doc.DOCIDThe select field (docr.DRCONTENT) is a CLOB column.
    Following is the plan and statistics in 10g
    Statistics
              1  recursive calls
              0  db block gets
         675018  consistent gets
          52225  physical reads
              0  redo size
       59486837  bytes sent via SQL*Net to client
       27199426  bytes received via SQL*Net from client
         103648  SQL*Net roundtrips to/from client
              1  sorts (memory)
              0  sorts (disk)
          51823  rows processed
    SQL>
    Plan hash value: 129748299
    | Id  | Operation                               | Name           | Starts | E-Rows | A-Rows |   A-Time   | Buffers | Reads  |  OMem |  1Mem | Used-Mem |
    |   1 |  SORT ORDER BY                          |                |      1 |     50 |  51823 |00:00:14.72 |     627K|   5379 |    26M|  1873K|   23M (0)|
    |*  2 |   FILTER                                |                |      1 |        |  51823 |00:00:08.90 |     627K|   5379 |       |       |          |
    |   3 |    TABLE ACCESS BY GLOBAL INDEX ROWID   | T_DOCREPORT    |      1 |      1 |  51823 |00:00:05.42 |     159K|   3773 |       |       |          |
    |   4 |     NESTED LOOPS                        |                |      1 |     50 |    103K|00:00:12.65 |     156K|    628 |       |       |          |
    |   5 |      TABLE ACCESS BY GLOBAL INDEX ROWID | T_DOCUMENT     |      1 |     50 |  51823 |00:00:00.15 |     481 |    481 |       |       |          |
    |*  6 |       INDEX RANGE SCAN                  | RDOC2_INDEX    |      1 |    514 |  51823 |00:00:00.09 |     245 |    245 |       |       |          |
    |*  7 |      INDEX RANGE SCAN                   | DOCID9_INDEX   |  51823 |      1 |  51823 |00:00:00.46 |     155K|    147 |       |       |          |
    |*  8 |    TABLE ACCESS BY GLOBAL INDEX ROWID   | T_DOCDIMMAP    |  51823 |      1 |      0 |00:00:04.52 |     467K|   1140 |       |       |          |
    |   9 |     NESTED LOOPS                        |                |  51823 |      1 |    207K|00:00:03.48 |     415K|    479 |       |       |          |
    |* 10 |      TABLE ACCESS BY GLOBAL INDEX ROWID | T_MASTERMAP    |  51823 |      1 |  51823 |00:00:01.20 |     207K|    190 |       |       |          |
    |* 11 |       INDEX RANGE SCAN                  | DOCID4_INDEX   |  51823 |      1 |  51824 |00:00:00.41 |     155K|    146 |       |       |          |
    |* 12 |      INDEX RANGE SCAN                   | MSTMAPID_INDEX |  51823 |      1 |    103K|00:00:00.43 |     207K|    289 |       |       |          |
    |* 13 |     TABLE ACCESS BY GLOBAL INDEX ROWID  | T_DOCDIMMAP    |      1 |      1 |      1 |00:00:01.05 |     469 |    466 |       |       |          |
    |  14 |      NESTED LOOPS                       |                |      1 |      1 |     15 |00:00:14.62 |     468 |    465 |       |       |          |
    |* 15 |       TABLE ACCESS BY GLOBAL INDEX ROWID| T_MASTERMAP    |      1 |      1 |      1 |00:00:01.02 |     464 |    463 |       |       |          |
    |* 16 |        INDEX RANGE SCAN                 | RDOCID3_INDEX  |      1 |    629 |  44585 |00:00:00.29 |     198 |    198 |       |       |          |
    |* 17 |       INDEX RANGE SCAN                  | MSTMAPID_INDEX |      1 |      1 |     14 |00:00:00.02 |       4 |      2 |       |       |          |
    Predicate Information (identified by operation id):
       2 - filter(( IS NOT NULL OR  IS NOT NULL))
       6 - access("DOC"."RDOCID"=294325)
       7 - access("DOC"."DOCID"="DOCR"."DOCID")
       8 - filter("DOCDIM1"."DIMID"=86541)
      10 - filter("MSTM1"."DIMLVLID"=2)
      11 - access("MSTM1"."DOCID"=:B1)
      12 - access("MSTM1"."MSTMAPID"="DOCDIM1"."MSTMAPID")
      13 - filter("DOCDIM2"."DIMID"=28388)
      15 - filter("MSTM2"."DIMLVLID"=1)
      16 - access("MSTM2"."RDOCID"=:B1)
      17 - access("MSTM2"."MSTMAPID"="DOCDIM2"."MSTMAPID")following is the plan in 11g:
    Statistics
             32  recursive calls
              0  db block gets
       20959179  consistent gets
         105948  physical reads
            348  redo size
       37320945  bytes sent via SQL*Net to client
       15110877  bytes received via SQL*Net from client
         103648  SQL*Net roundtrips to/from client
              3  sorts (memory)
              0  sorts (disk)
          51823  rows processed
    SQL>
    Plan hash value: 1013746825
    | Id  | Operation                               | Name           | Starts | E-Rows | A-Rows |   A-Time   | Buffers | Reads  |  OMem |  1Mem | Used-Mem |
    |   0 | SELECT STATEMENT                        |                |      1 |        |  51823 |00:01:10.08 |      20M|   2306 |       |       |          |
    |   1 |  SORT ORDER BY                          |                |      1 |      1 |  51823 |00:01:10.08 |      20M|   2306 |  9266K|  1184K| 8236K (0)|
    |*  2 |   FILTER                                |                |      1 |        |  51823 |00:21:41.79 |      20M|   2306 |       |       |          |
    |   3 |    NESTED LOOPS                         |                |      1 |        |  51823 |00:00:01.95 |    8054 |   1156 |       |       |          |
    |   4 |     NESTED LOOPS                        |                |      1 |    335 |  51823 |00:00:00.99 |    4970 |    563 |       |       |          |
    |   5 |      TABLE ACCESS BY GLOBAL INDEX ROWID | T_DOCUMENT     |      1 |    335 |  51823 |00:00:00.38 |     402 |    401 |       |       |          |
    |*  6 |       INDEX RANGE SCAN                  | RDOC2_INDEX    |      1 |    335 |  51823 |00:00:00.17 |     148 |    147 |       |       |          |
    |*  7 |      INDEX RANGE SCAN                   | DOCID9_INDEX   |  51823 |      1 |  51823 |00:00:00.55 |    4568 |    162 |       |       |          |
    |   8 |     TABLE ACCESS BY GLOBAL INDEX ROWID  | T_DOCREPORT    |  51823 |      1 |  51823 |00:00:00.94 |    3084 |    593 |       |       |          |
    |   9 |    CONCATENATION                        |                |  51823 |        |  51823 |00:22:16.08 |      20M|   1150 |       |       |          |
    |  10 |     NESTED LOOPS                        |                |  51823 |        |      0 |00:00:02.71 |     221K|   1150 |       |       |          |
    |  11 |      NESTED LOOPS                       |                |  51823 |      1 |    103K|00:00:01.19 |     169K|    480 |       |       |          |
    |* 12 |       TABLE ACCESS BY GLOBAL INDEX ROWID| T_MASTERMAP    |  51823 |      1 |  51823 |00:00:00.72 |     108K|    163 |       |       |          |
    |* 13 |        INDEX RANGE SCAN                 | DOCID4_INDEX   |  51823 |      1 |  51824 |00:00:00.52 |   56402 |    163 |       |       |          |
    |* 14 |       INDEX RANGE SCAN                  | MSTMAPID_INDEX |  51823 |      2 |    103K|00:00:00.60 |   61061 |    317 |       |       |          |
    |* 15 |      TABLE ACCESS BY GLOBAL INDEX ROWID | T_DOCDIMMAP    |    103K|      1 |      0 |00:00:01.14 |   52584 |    670 |       |       |          |
    |  16 |     NESTED LOOPS                        |                |  51823 |        |  51823 |00:22:13.19 |      20M|      0 |       |       |          |
    |  17 |      NESTED LOOPS                       |                |  51823 |      1 |    725K|00:22:12.31 |      20M|      0 |       |       |          |
    |* 18 |       TABLE ACCESS BY GLOBAL INDEX ROWID| T_MASTERMAP    |  51823 |      1 |  51823 |00:22:11.09 |      20M|      0 |       |       |          |
    |* 19 |        INDEX RANGE SCAN                 | RDOCID3_INDEX  |  51823 |    336 |   2310M|00:12:08.04 |    6477K|      0 |       |       |          |
    |* 20 |       INDEX RANGE SCAN                  | MSTMAPID_INDEX |  51823 |      2 |    725K|00:00:00.83 |   51838 |      0 |       |       |          |
    |* 21 |      TABLE ACCESS BY GLOBAL INDEX ROWID | T_DOCDIMMAP    |    725K|      1 |  51823 |00:00:00.92 |   51823 |      0 |       |       |          |
    Predicate Information (identified by operation id):
       2 - filter( IS NOT NULL)
       6 - access("DOC"."RDOCID"=294325)
       7 - access("DOC"."DOCID"="DOCR"."DOCID")
      12 - filter("MSTM1"."DIMLVLID"=2)
      13 - access("MSTM1"."DOCID"=:B1)
      14 - access("MSTM1"."MSTMAPID"="DOCDIM1"."MSTMAPID")
      15 - filter((INTERNAL_FUNCTION("DOCDIM1"."DIMID") AND (("DOCDIM1"."DIMID"=86541 AND "MSTM1"."DIMLVLID"=2 AND "MSTM1"."DOCID"=:B1) OR
                  ("DOCDIM1"."DIMID"=28388 AND "MSTM1"."DIMLVLID"=1 AND "MSTM1"."RDOCID"=:B2))))
      18 - filter(("MSTM1"."DIMLVLID"=1 AND (LNNVL("MSTM1"."DOCID"=:B1) OR LNNVL("MSTM1"."DIMLVLID"=2))))
      19 - access("MSTM1"."RDOCID"=:B1)
      20 - access("MSTM1"."MSTMAPID"="DOCDIM1"."MSTMAPID")
      21 - filter((INTERNAL_FUNCTION("DOCDIM1"."DIMID") AND (("DOCDIM1"."DIMID"=86541 AND "MSTM1"."DIMLVLID"=2 AND "MSTM1"."DOCID"=:B1) OR
                  ("DOCDIM1"."DIMID"=28388 AND "MSTM1"."DIMLVLID"=1 AND "MSTM1"."RDOCID"=:B2))))Calling all performance experts. Any ideas ??
    Edited by: dm_ptldba on Oct 8, 2012 7:50 AM

    If you check lines 2, 3, 8, and 13 in the 10g plan you will see that Oracle has operated your two EXISTS subqueries separately (there is a bug with multiple filter subqueries in that version that indents each subquery after the first one extra place, so the shape of the plan is a little deceptive). The statistics show that the second subquery only ran once because existence was almost always satistfied by the first.
    In the 11g plan, lines 2, 3, and 9 show that the optimizer has transformed your TWO subqueries into a single subquery, then turned transformed the single subquery into a concatenation and this has, in effect, made it execute both subqueries for every row from the driving table - all the extra work appears from the redundant execution of the thing that was the second EXISTS subquery.
    If you extract the OUTLINE from the execution plans (add 'outline' to the call to dbms_xplan as one of the format options) you may see some hint that shows the optimizer combining the two subqueries - if so then put in the "NO_xxx" hint to block it. Alternatively you could simply try adding the hint stop ALL cost-based query transformations /*+ no_query_transformation */
    Regards
    Jonathan Lewis

  • JDeveloper 11g (Build 5156) fail to install on Ubuntu 8.04

    Installation of JDeveloper 11g (Build 5156) on Ubuntu 8.04 using:java -jar jdevstudio11110install.jarwith java -version:java version "1.6.0_07"
    Java(TM) SE Runtime Environment (build 1.6.0_07-b06)
    Java HotSpot(TM) Client VM (build 10.0-b23, mixed mode, sharing)fail with error:#
    # An unexpected error has been detected by Java Runtime Environment:
    #  SIGSEGV (0xb) at pc=0xb4ed0598, pid=21142, tid=3031116688
    # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode, sharing linux-x86)
    # Problematic frame:
    # C  [http://libjni.linux.so+0x4598]  JNU_GetStringNativeChars+0x34
    # If you would like to submit a bug report, please visit:
    #   [http://java.sun.com/webapps/bugreport/crash.jsp]
    ---------------  T H R E A D  ---------------
    Current thread (0x082d1400):  JavaThread "WizardController" daemon [unknown thread state, id=21159, stack(0xb4a62000,0xb4ab3000)|http://forums.oracle.com/forums/]
    siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x00000088
    ...Any hints?
    Thank you in advance,
    Massimo.

    Hi,
    I think this is more a SUN issue as an installer issue as I take it from the message you get. Anyway, best recommandation I can give is to work with customer support on tracing down the issue
    Frank
    Edited by: Frank Nimphius on Dec 3, 2008 12:58 PM

  • SQL strange behavior after 11g upgrade

    Hi all,
    After upgrading from 10.2.0.3 to 11.2.0.1 (64-bit RedHat), one of my SQLs behaves very strangely.
    These are the facts:
    - This is upgrade evaluation phase in 'lab' environment
    - First run (after db restart) returns results very quickly (acceptable 0.4 secs)
    - Every consecutive run is very slow (3-4 minutes)
    - Explain Plan did NOT change between runs;
    - Number of 'consistent gets' changed drastically (from few thousands to few millions) ...which would usually lead to inefficient data access plan (index), but again, the explain plan did not change!
    - If I flush shared_pool, next run is quick again, and the story repeats ... flushing shared_poll is possible in test system only, it's out of question for prod system of course
    - All above happens in 'lab' environment, i.e. no multi-user load yet ... practically 'one-session' system
    - I have tried both AMM and ASSM memory management(s) and same problem happens regardless (my old 10g database uses ASSM and I am trying to implement ASM in new 11g db)
    - On same server, the SQL in question performs correctly if I run it in 10g environment;
    - I have updated my 11g Oracle software/db with the latest CPU;
    In addition, I have played with 'result cache' in 11g, and putting 'result_cache' hint in my sql resolved the issue. But that will open a lot of new questions for implementation in real app environment ... so at this moment, I don't want to evaluate result cache ...if I don't have to
    I am thinking to try this on another server and eliminate eventual issue with some kind of faulty memory on existing server ... after that - to open ticket with Oracle ...
    Any similar experience out there? Any thoughts?
    Thanks a lot ...

    Welcome to the forums !
    How to post a tuning request
    HOW TO: Post a SQL statement tuning request - template posting
    When your query takes too long ...
    HTH
    Srini

  • Oracle Discoverer 11g Error to create a new public connection

    Hi,
    Since i have install a new Discoverer 11g, i got this error.
    A connection error.
    - error while creating the session, check for other errors.
    - oracle.discoiv.connections.ConnectionStoreException: While trying to lookup 'jdbc.disco_pstore' didn't find subcontext 'jdbc'. Resolved ''
    - While trying to lookup 'jdbc.disco_pstore' didn't find subcontext 'jdbc'. Resolved ''
    - While trying to lookup 'jdbc.disco_pstore' didn't find subcontext 'jdbc'. Resolved ''
    unable to retrieve connection list
    - Cannot retrieve connection list. Check the Discoverer application log for more details.
    The installation is an stand-alone without OID but i know why - jdbc looking to the metadata of the pstore.
    The database schemas are created and populated by RCU by i cannot use the STAND ALONE mode.
    Cheers
    Edited by: unsolaris on 7-Apr-2012 5:14 PM

    Thank you for your hint, but ...
    In Metalink there are no results for me.
    This is my metalink address:
    https://metalink.oracle.com/CSP/ui/flash.html#tab=KBHome(page=KBHome&id=()),(page=KBNavigator&id=(from=BOOKMARK&bmDocType=PROBLEM&bmDocDsrc=KB&bmDocTitle=Repository%20Assistant%20Fails%20With%20%22ORA-00942:%20table%20or%20view%20does%20not%20exist%22%20In%20Workspace%20Creation&viewingMode=1143&bmDocID=557067.1))
    Do you have another address?
    Thank you
    Regards
    Siegwin

Maybe you are looking for