Loading SQL Tuning Sets

On a 10.2.0.4 database, is it possible to load SQL Tuning sets with SQL from a text file? I can't find anything in the documentation mentioning this but I could have simply missed it and this facility would be very useful to us.
Our reporting tool is MicroStrategy which operates by building lots of temporary tables: extracting the SQL via Top Activity EM page will put the CTAS statement into the tuning set which (I believe) is ignored by SQL Access Advisor - extracting the sql to a text file, editting to remove the "create table as" and executing in order to load the tuning set is very long winded for a set of queries - at least being able to load the tuning set directly with a set of SQL select statements directly from a text file would help significantly.
Many thanks for any advice
Pete

I did not see a direct way to create the STS from a text file. From the docs:
"The standard sources for populating an STS are the workload repository, another STS, or the cursor cache"
http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/sql_tune.htm#i34915
But you could try a couple of things:
1) create one tuning task per statement, using DBMS_SQLTUNE.CREATE_TUNING_TASK, which can use plain text as input: http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/sql_tune.htm#CHDJDHGE
2) create the STS with queries from cursor cache: http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14258/d_sqltun.htm#i1010615
Both approaches needs some PL/SQL programming, but it can be useful if you can identify your SQL statements some way.
Regards.

Similar Messages

  • Permissions needed for Applying SQL Tuning Sets/SQL Plans 11g?

    What permission are needed for a user to apply/activate sql tuning sets (sql plans) in 11g? The user can capture and move the the sql tuning sets from a 10g database to an 11g database but is getting "ORA-01031: insufficient privileges" when trying to activate/apply the sqlplans in 11g.
    The user has:
    ADMINISTER SQL MANAGEMENT OBJECT and ADMINISTER SQL TUNING SET and EXECUTE on SYS.DBMS_SPM
    The user is an administrator for our Data Warehouse team but they do not have sysdba priviliges.
    Do you also know of a good white paper that covers the step by step instructions and permissions needed for aquiring and applying/activating sqlplans?
    If more information is needed in order to respond please advise.
    Thank you

    What permission are needed for a user to apply/activate sql tuning sets (sql plans) in 11g? The user can capture and move the the sql tuning sets from a 10g database to an 11g database but is getting "ORA-01031: insufficient privileges" when trying to activate/apply the sqlplans in 11g.
    The user has:
    ADMINISTER SQL MANAGEMENT OBJECT and ADMINISTER SQL TUNING SET and EXECUTE on SYS.DBMS_SPM
    The user is an administrator for our Data Warehouse team but they do not have sysdba priviliges.
    Do you also know of a good white paper that covers the step by step instructions and permissions needed for aquiring and applying/activating sqlplans?
    If more information is needed in order to respond please advise.
    Thank you

  • List Sql Tuning Sets

    I am hoping for a quick easy answer on this. grin
    We have been generating a number of Sql Tuning Sets via Grid Control and now we want to export them. Of course, they all have these awful, non-descriptive names. How do we list them? I was unable to find any help in the "automatic SQL tuning" guide (Chapter 12) of the Performance Guide, and browsing the DBA_* and other fixed views has not revealed anything, yet.

    Does this help?
    BANPROD_SQL > select id,name,owner,description,created from WRI$_SQLSET_DEFINITIONS order by 1 desc;
    ID NAME OWNER DESCRIPTION CREATED
    10 TUNING_SET_1141930799317 ORACLE Automatically generated by ADDM 09-MAR-06
    9 TUNING_SET_1141921159123 ORACLE Automatically generated by ADDM 09-MAR-06
    8 TUNING_SET_1141831053351 ORACLE Automatically generated by ADDM 08-MAR-06
    7 TUNING_SET_1141826801391 ORACLE Automatically generated by ADDM 08-MAR-06
    6 TOP_SQL_1141752418284 ORACLE Automatically generated by Top SQL 07-MAR-06
    5 TOP_SQL_1141749589578 ORACLE Automatically generated by Top SQL 07-MAR-06
    4 TOP_SQL_1141747575814 ORACLE Automatically generated by Top SQL 07-MAR-06
    2 TOP_SQL_1141746930242 ORACLE Automatically generated by Top SQL 07-MAR-06
    1 TUNING_SET_1141660362671 ORACLE Automatically generated by ADDM 06-MAR-06
    9 rows selected.

  • ORA-13754: "SQL Tuning Set" "" does not exist for user "SYS"

    While calling dbms_stats.seed_col_usage I got the following error. Can someone help me on how to resolve it
    sqlplus
    SQL*Plus: Release 11.2.0.1.0 Production on Thu Apr 14 14:37:38 2011
    Copyright (c) 1982, 2009, Oracle. All rights reserved.
    Enter user-name: / as sysdba
    Connected to:
    Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
    With the Partitioning, OLAP, Data Mining and Real Application Testing options
    SQL> select * from v$version;
    BANNER
    Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
    PL/SQL Release 11.2.0.1.0 - Production
    CORE 11.2.0.1.0 Production
    TNS for IBM/AIX RISC System/6000: Version 11.2.0.1.0 - Production
    NLSRTL Version 11.2.0.1.0 - Production
    SQL> show user
    USER is "SYS"
    SQL> begin
    2 dbms_stats.seed_col_usage(null,null,400);
    3 end;
    4 /
    begin
    ERROR at line 1:
    ORA-13754: "SQL Tuning Set" "" does not exist for user "SYS".
    ORA-06512: at "SYS.DBMS_SQLTUNE_INTERNAL", line 17379
    ORA-06512: at "SYS.DBMS_STATS", line 28451
    ORA-06512: at line 2
    Thank You
    Sarayu

    According to the documentation:
    SEED_COL_USAGE ProcedureThis procedure iterates over the SQL statements in the specified SQL tuning set, compiles them and seeds column usage information for the columns that appear in these statements.
    Syntax
    DBMS_STATS.SEED_COL_USAGE (
    sqlset_name IN VARCHAR2,
    owner_name IN VARCHAR2,
    time_limit IN POSITIVE DEFAULT NULL);>
    It looks like you need to provide a SQLSET_NAME and OWNER_NAME to use this procedure correctly, to which you've provided NULLs. I don't see any exceptions in the documentation that indicate special processing when NULLs are provided.

  • Modify sql tuning set

    Hi Experts
    I have created a sql tuning set with all sqls from cursor cache referring table1. Now I have transported this sqlset to nonprod environment, now what I want to do is  make table1 partitioned and test the impact. Instead of altering table1 I want create copy of table1 as partitioned table2. Is there a way I cancl change the sqls in my sqlset to refer to table2 in place of table1. So I basically want to update the sqls with table2 instead of table1. Is this possible and if yes how? If no any other way of doing it, sqlset has ~200 sqls

    Why ever not!
    1. You create a new user with the appropriate privileges
    2. Logon as the new user and create private synonmys (if public ones do not exist) for the objects you need to use
    3. Either import a sql set or create a sqlset.
    4. Create and execute an analysis task - this will be your baseline
    5. Build test1 table as a partitioned table in the new schema - this will override the public synonym
    6. Execute an analysis task - this will be your post change run
    7. Compare results.

  • SQL tuning set for specific SQLID

    Hi,
    Is it possible to create SQL tuning set for specific SQLID's?
    Advance thanks!

    do you have any code or some package to do this?As long as those statements are in AWR or the cursor cache then you can use
    DBMS_SQLTUNE.SELECT_CURSOR_CACHE or
    DBMS_SQLTUNE.SELECT_WORKLOAD_REPOSITORY For example something like this:
    begin
      DBMS_SQLTUNE.CREATE_SQLSET(
        sqlset_name => 'my_tuning_set',
        description  => 'my tuning set');
    end;
    DECLARE
    baseline_cursor DBMS_SQLTUNE.SQLSET_CURSOR;
    BEGIN
    OPEN baseline_cursor FOR
          SELECT VALUE(p)
          FROM   TABLE(DBMS_SQLTUNE.SELECT_CURSOR_CACHE
                 (basic_filter      => 'sql_id in (''1'',''2'',''3'')',
                  attribute_list    => 'ALL'
                  )) p;
        DBMS_SQLTUNE.LOAD_SQLSET(
                 sqlset_name     => 'my_tuning_set',
                 populate_cursor => baseline_cursor);
    END;
    /

  • RAT - SQL Tuning Set from 9i trace in wrong order

    Hi together
    I want to test the impact of some staments on 9.2.0.8 in 11g with Real Application Testing, but the order in the tuning set seems to b wrong (not in the traced order). So i made a small Test Script who is creating a Table, insert Data with a loop and select all.
    Steps :
    * 9i enable trace level 4
    * 9i run the script
    * 9i stop the trace
    * transfer to 11g
    * make an sql tunnig set
    * running in the Performance Analyzer Workflow
    The first run Oracle makes performance datas from the trace files. In the second run I want to execute the statements from the tuning set in the 11g database. The traced Schema from 9i exists.
    In the report after the second run I see the failure that the insert and select statement is not allowed. When i take a look in the SQL Tuning Set i see that the select and insert will be played before the create table ! Also on the view DBA_SQLSET_STATEMENTS.
    Is there a way to get the correct order in the SQL Tuning Set like the statement order (create before insert,select) ? Or can Oracle not handle DDL-Statements in the trace ?
    Regards Martin

    Hi together
    I want to test the impact of some staments on 9.2.0.8 in 11g with Real Application Testing, but the order in the tuning set seems to b wrong (not in the traced order). So i made a small Test Script who is creating a Table, insert Data with a loop and select all.
    Steps :
    * 9i enable trace level 4
    * 9i run the script
    * 9i stop the trace
    * transfer to 11g
    * make an sql tunnig set
    * running in the Performance Analyzer Workflow
    The first run Oracle makes performance datas from the trace files. In the second run I want to execute the statements from the tuning set in the 11g database. The traced Schema from 9i exists.
    In the report after the second run I see the failure that the insert and select statement is not allowed. When i take a look in the SQL Tuning Set i see that the select and insert will be played before the create table ! Also on the view DBA_SQLSET_STATEMENTS.
    Is there a way to get the correct order in the SQL Tuning Set like the statement order (create before insert,select) ? Or can Oracle not handle DDL-Statements in the trace ?
    Regards Martin

  • Sql tuning set explain plan

    A hypothetical question came up between dbas in the office.   We regularly take tuning sets before making significant changes on the DB.  Populate from cache.  Great little way of checking to see if anything changed.  Someone asked if a table T1 was accessed during a given day where we had a tuning set being populated from the cache (no reason for auditing to be on at the time).  Well first thing to do is search the sql_statements
    select * from DBA_SQLSET_STATEMENTS
    where sqlset_name = 'my_sts'
    and sql_text like '%select * from t1%'
    but no rows returned, so next idea is to query the plan in case a synonym was used
    select * from DBA_SQLSET_PLANS
    where sqlset_name = 'my_sts'
    and object_name = 'T1'
    And yes, its there we had a select against the table, the main sql_text in the dba_sqlset_statments view was using a synonym.  great, so now we might be able to use this as a alternative audit method (mmv depending on whether you have the diag pack). 
    Heres the question, can we always be guaranteed an object will be in a plan?

    Dom Brooks wrote:
    Also, the presence of a SQL statement in the shared pool does not indicate it was run today - you'd need to check the relevant column, something like last_active_time.
    More importantly, the absence of a SQL statement from the shared pool does not indicate that it was not run today.
    Just that it's no longer in the shared pool.
    I'm concious of that when running the populate,  even in a busy period our pools last over an hour,  with that in mind when Im populating my tuning set, I set the frequency to 10 minutes to poll the cache where distinct IDs and HASHes are overloaded in the tuning set if theyre already there. 
    http://docs.oracle.com/cd/B28359_01/appdev.111/b28419/d_sqltun.htm#CACJHDDC
    Note that in production systems the time limit and repeat interval would be set much higher. You should tune the time_limit and repeat_interval parameters based on the workload time and cursor cache turnover properties of your system.

  • OWB Cube load SQL tuning

    I have a OWB mapping which takes input from a staging table and add those row to the Cube. The underlying table behind cube is a relational fact table joined with the dimensions using foreign keys. Explain plan behind the query has a rather high cost and the mapping runs for 30 minutes. If you see below, in step 17, the cost goes up to 1,396,573 which is also where nested loops start to appear. Can somebody provide general pointers to tune this query?
    Plan
    SELECT STATEMENT ALL_ROWSCost: 1,746,526,275 Bytes: 386,835,904 Cardinality: 464,947                                                                            
         46 NESTED LOOPS OUTER Cost: 1,746,526,275 Bytes: 386,835,904 Cardinality: 464,947                                                                       
              41 NESTED LOOPS OUTER Cost: 1,744,200,663 Bytes: 380,791,593 Cardinality: 464,947                                                                  
                   37 NESTED LOOPS OUTER Cost: 1,743,270,415 Bytes: 374,747,282 Cardinality: 464,947                                                             
                        34 NESTED LOOPS OUTER Cost: 1,740,476,128 Bytes: 368,702,971 Cardinality: 464,947                                                        
                             29 NESTED LOOPS OUTER Cost: 1,739,545,862 Bytes: 362,658,660 Cardinality: 464,947                                                   
                                  25 NESTED LOOPS OUTER Cost: 1,710,193,475 Bytes: 356,614,349 Cardinality: 464,947                                              
                                       20 NESTED LOOPS OUTER Cost: 49,230,267 Bytes: 350,570,038 Cardinality: 464,947                                         
                                            17 NESTED LOOPS OUTER Cost: 1,402,837 Bytes: 344,525,727 Cardinality: 464,947                                    
                                                 13 HASH JOIN RIGHT OUTER Cost: 7,481 Bytes: 338,481,416 Cardinality: 464,947                               
                                                      1 TABLE ACCESS STORAGE FULL TABLE ORION.DIM_HR_SALARY Cost: 6 Bytes: 31 Cardinality: 1                          
                                                      12 HASH JOIN RIGHT OUTER Cost: 7,472 Bytes: 324,068,059 Cardinality: 464,947                          
                                                           2 TABLE ACCESS STORAGE FULL TABLE ORION.DIM_ADDRESS Cost: 2,050 Bytes: 65 Cardinality: 1                     
                                                           11 HASH JOIN RIGHT OUTER Cost: 5,420 Bytes: 293,846,504 Cardinality: 464,947                     
                                                                3 TABLE ACCESS STORAGE FULL TABLE ORION.DIM_SESSION Cost: 12 Bytes: 70 Cardinality: 1                
                                                                10 HASH JOIN RIGHT OUTER Cost: 5,405 Bytes: 261,300,214 Cardinality: 464,947                
                                                                     4 TABLE ACCESS STORAGE FULL TABLE ORION.DIM_LOCATION Cost: 9 Bytes: 21 Cardinality: 1           
                                                                     9 HASH JOIN RIGHT OUTER Cost: 5,393 Bytes: 251,536,327 Cardinality: 464,947           
                                                                          5 TABLE ACCESS STORAGE FULL TABLE ORION.DIM_HR_EMPLOYEE Cost: 135 Bytes: 75 Cardinality: 1      
                                                                          8 HASH JOIN RIGHT OUTER Cost: 5,256 Bytes: 216,665,302 Cardinality: 464,947      
                                                                               6 TABLE ACCESS STORAGE FULL TABLE ORION.DIM_CLASS_INSTRUCTOR Cost: 12 Bytes: 48 Cardinality: 1
                                                                               7 TABLE ACCESS STORAGE FULL TABLE O_STG.FACT_CLASS_INSTRUCTOR_STG2 Cost: 5,241 Bytes: 194,347,846 Cardinality: 464,947
                                                 16 VIEW SYS. Cost: 3 Bytes: 13 Cardinality: 1                               
                                                      15 TABLE ACCESS BY INDEX ROWID TABLE ORION.DIM_CLASS_ATTRIBUTES Cost: 3 Bytes: 153 Cardinality: 1                          
                                                           14 INDEX RANGE SCAN INDEX ORION.ALL_ATTRIBUTES_IDX_12 Cost: 2 Cardinality: 1                     
                                            19 VIEW SYS. Cost: 103 Bytes: 13 Cardinality: 1                                    
                                                 18 TABLE ACCESS STORAGE FULL TABLE ORION.DIM_COURSE Cost: 103 Bytes: 30 Cardinality: 1                               
                                       24 PARTITION HASH ALL Cost: 3,572 Bytes: 13 Cardinality: 1 Partition #: 27 Partitions accessed #1 - #8                                        
                                            23 VIEW SYS. Cost: 3,572 Bytes: 13 Cardinality: 1                                    
                                                 22 TABLE ACCESS BY LOCAL INDEX ROWID TABLE ORION.DIM_PERSON Cost: 3,572 Bytes: 31 Cardinality: 1 Partition #: 27 Partitions accessed #1 - #8                              
                                                      21 INDEX RANGE SCAN INDEX ORION.ALL_ATTRIBUTES_IDX_2_P Cost: 8 Cardinality: 3,661 Partition #: 27 Partitions accessed #1 - #8                         
                                  28 PARTITION RANGE ALL Cost: 63 Bytes: 13 Cardinality: 1 Partition #: 31 Partitions accessed #1 - #7                                             
                                       27 VIEW SYS. Cost: 63 Bytes: 13 Cardinality: 1                                         
                                            26 TABLE ACCESS STORAGE FULL TABLE ORION.DIM_TIME_TERM Cost: 63 Bytes: 27 Cardinality: 1 Partition #: 31 Partitions accessed #1 - #7                                   
                             33 VIEW SYS. Cost: 2 Bytes: 13 Cardinality: 1                                                   
                                  32 FILTER                                              
                                       31 TABLE ACCESS BY INDEX ROWID TABLE ORION.DIM_HR_JOB Cost: 2 Bytes: 38 Cardinality: 1                                         
                                            30 INDEX RANGE SCAN INDEX ORION.ALL_ATTRIBUTES_IDX_19 Cost: 1 Cardinality: 1                                    
                        36 VIEW SYS. Cost: 6 Bytes: 13 Cardinality: 1                                                        
                             35 TABLE ACCESS STORAGE FULL TABLE ORION.DIM_ORG_STRUCTURE Cost: 6 Bytes: 37 Cardinality: 1                                                   
                   40 VIEW SYS. Cost: 2 Bytes: 13 Cardinality: 1                                                             
                        39 TABLE ACCESS BY INDEX ROWID TABLE ORION.DIM_DEMOGRAPHICS Cost: 2 Bytes: 43 Cardinality: 1                                                        
                             38 INDEX RANGE SCAN INDEX ORION.ALL_ATTRIBUTES_IDX Cost: 1 Cardinality: 1                                                   
              45 VIEW SYS. Cost: 5 Bytes: 13 Cardinality: 1                                                                  
                   44 FILTER                                                             
                        43 TABLE ACCESS BY INDEX ROWID TABLE ORION.DIM_DEPARTMENT Cost: 5 Bytes: 31 Cardinality: 1                                                        
                             42 INDEX RANGE SCAN INDEX ORION.ALL_DEPT_ATTRIBUTES_IDX Cost: 1 Cardinality: 3

    Hi Emile,
    regading extracting data from MSSQL with OWB on Unix platform (using Generic Connectivity):
    Re: SQLServer access from AIX Warehouse builder
    Re: OWB on Solaris Connectivity with SQL SERVER on Windows
    We want to load aprox. 100 million records a day.
    I've read some articles about this and the advise was to dump the data from SQL Server to files and load the files with OWB.100 million records per day is not a problem for daily extracting from MSSQL Server if you have 1-2 hour.
    In my opinion dumping to text file is a bad practice and is unnecessary if customer don't have special requirements (for example for security reason).
    SQL Server source table and a Oracle target table without any difficult transformationsIn my opninion the best way process data from MSSQL is to extract data to staging area (schema) on Oracle DB with mappings as simple as possible (ONLY filters, without any join), and most of data processing prefom in Staging area or during moving from staging to DWH.
    Also look at OWB user guide (how to use Generic Connectivity in OWB)
    http://download.oracle.com/docs/cd/E11882_01/owb.112/e10582/loading_ms_data.htm#i1064950
    Regards,
    Oleg
    Edited by: added link to OWB doc with description of using Generic Connectivity

  • SQL Tuning Advisor on a specific SQL statement

    Hi all,
    How can I used SQL Tuning Advisor in Oracle EM Database Control to tune a specific SQL statement; i.e. the statement is not any of: Top SQL, SQL Tuning Sets, Snapshots Preserved Snapshot Sets.
    Thanks in advance,
    Ahmed B.

    Hi,
    You can use either the automatic SQL tuning features that are accessible from Enterprise Manager Database Console on the "Advisor Central" page or trough SQL*PLUS using the DBMS_SQLTUNE pakage:
    -- creating the tuning task
    set serveroutput on
    declare
      l_sql_tune_task_id  varchar2(100);
    begin
      l_sql_tune_task_id := dbms_sqltune.create_tuning_task (
                              sql_id      => '<your_sql_id>',
                              scope       => dbms_sqltune.scope_comprehensive,
                              time_limit  => 60,
                              task_name   => '<your_tuning_task_name>',
                              description => 'tuning task for statement your_sql_id.');
      dbms_output.put_line('l_sql_tune_task_id: ' || l_sql_tune_task_id);
    end;
    -- executing the tuning task
    exec dbms_sqltune.execute_tuning_task(task_name => '<your_tuning_task_name>');
    -- displaying the recommendations
    set long 100000;
    set longchunksize 1000
    set pagesize 10000
    set linesize 100
    select dbms_sqltune.report_tuning_task('<your_tuning_task_name>') as recommendations from dual;For more information, take a look at link provided by Jaffy.
    Cheers
    Legatti

  • Additional licenses reuired for using Sql Tuning Advisor In SQL Developer 4.0.3

    Hi,
    We have Oracle Database 11g Enterprise Edition Release 11.2.0.3.0. Do we need to purchase an additional oracle license for using SQL Tuning Advisor Option in SQL Developer 4.0.3 

    We have Oracle Database 11g Enterprise Edition Release 11.2.0.3.0. Do we need to purchase an additional oracle license for using SQL Tuning Advisor Option in SQL Developer 4.0.3 
    The Oracle Tuning Pack is DATABASE functionality - it is part of the database. Sql Developer just uses it.
    Yes - to use ANY of the features of the tuning pack requires an extra cost license.
    http://docs.oracle.com/cd/B28359_01/license.111/b28287/options.htm#CIHFIHFG
    Oracle Tuning Pack
    The Oracle Tuning Pack provides database administrators with expert performance management for the Oracle environment, including SQL tuning and storage optimizations. The Oracle Diagnostic Pack is a prerequisite product to the Oracle Tuning Pack. Therefore, to use the Tuning Pack, you must also have a Diagnostic Pack.
    The Tuning Pack includes the following features:
      SQL Access Advisor
      SQL Tuning Advisor
      Automatic SQL Tuning
      SQL Tuning Sets
      SQL Monitoring
      Reorganize objects
    In order to use the features listed above, you must purchase licenses for the Tuning Pack, with one exception: SQL Tuning Sets can be used if you have licensed either the Tuning Pack or Oracle Real Application Testing. A new initialization parameter, CONTROL_MANAGEMENT_PACK_ACCESS, is introduced to control access to the Diagnostic Pack and Tuning Pack in the database server. This parameter can be set to one of three values:
      DIAGNOSTIC+TUNING: Diagnostic Pack and Tuning Pack functionally is enabled in the database server.
      DIAGNOSTIC: Only Diagnostic Pack functionality is enabled in the server.
      NONE: Diagnostic Pack and Tuning pack functionally is disabled in the database server.
    The Tuning Pack functionality can be accessed by the Enterprise Manager links as well as through the database server command-line APIs. The use of either interface requires licensing of the Tuning Pack

  • OBIEE 11g BI Publisher; New Data Set Creation Error "Failed to load SQL"

    Hi,
    I'm trying to create a new SQL data set (from a client machine). I use "query builder" to build the data set. But when I click "OK", it fires the error "Failed to load SQL".
    But strangely, if connect to the OBIEE server's desktop and create the data set it works without any issues. I wonder this would be a firewall issue. If so what are the ports I should open.
    It's a enterprise installation. And we have already open 9703, 9704, and 9706.
    Has anyone came across such a situation?

    Talles,
    First of all you might have more chance of getting a response over in the BIP forum. Other than that all I can think of is: is your MS SQL Server running with mixed mode auth?

  • I could not set Automatic SQL Tuning enabled

    Hi experts,
    I execute below command by sys user.
    BEGIN
    dbms_auto_task_admin.enable(client_name => 'sql tuning advisor', operation => NULL, window_name => NULL);
    END;
    It occur error:
    ORA-15604: Initialization parameters prevent client from being enabled.
    ORA-06512: at "SYS.DBMS_AUTO_TASK_ADMIN", line 23
    ORA-06512: at "SYS.DBMS_AUTO_TASK_ADMIN", line 122
    Thanks!
    Joseph.

    Hi P. Forstmann ,
    Yes , I have the license.
    SQL> show parameter control_m
    NAME TYPE VALUE
    control_management_pack_access string DIAGNOSTIC+TUNING
    SQL> select * from v$version;
    BANNER
    Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - Production
    PL/SQL Release 11.2.0.2.0 - Production
    CORE 11.2.0.2.0 Production
    TNS for Linux: Version 11.2.0.2.0 - Production
    NLSRTL Version 11.2.0.2.0 - Production
    Rds,Joseph.

  • Need help to debug SQL Tuning Advisor Error Message

    Hi,
    I am getting an error message while try to get recommendations from the SQL Tuning Advisor.
    Environment:
    Oracle Version:  11.2.0.3.0
    O/S: AIX
    Following is my code:
    declare
    my_task_name  varchar2 (30);
    my_sqltext    clob;
    begin
    my_sqltext := 'SELECT DISTINCT MRKT_AREA AS DIVISION, PROMO_ID,
                    PROMO_CODE,
                    RBR_DTL_TYPE.PERF_DETL_TYP, 
                    RBR_DTL_TYPE.PERF_DETL_DESC,
                    RBR_DTL_TYPE.PERF_DETL_SUB_TYP,
                    RBR_DTL_TYPE.PERF_DETL_SUB_DESC,
                    BU_SYS_ITM_NUM,
                    RBR_CPN_LOC_ITEM_ARCHIVE.CLI_SYS_ITM_DESC,
                    PROMO_START_DATE,
                    PROMO_END_DATE,
                    PROMO_VALUE2,
                    PROMO_VALUE1,
                    EXEC_COMMENTS,
                    PAGE_NUM,
                    BLOCK_NUM,
                    AD_PLACEMENT,
                    BUYER_CODE,
                    RBR_CPN_LOC_ITEM_ARCHIVE.CLI_STAT_TYP,
                    RBR_MASTER_CAL_ARCHIVE.STATUS_FLAG
    FROM  (PROMO_REPT_OWNER.RBR_CPN_LOC_ITEM_ARCHIVE
    INNER JOIN PROMO_REPT_OWNER.RBR_MASTER_CAL_ARCHIVE
    ON (RBR_CPN_LOC_ITEM_ARCHIVE.CLI_PROMO_ID = PROMO_ID)
    AND (RBR_CPN_LOC_ITEM_ARCHIVE.CLI_PERF_DTL_ID = PERF_DETAIL_ID)
    AND (RBR_CPN_LOC_ITEM_ARCHIVE.CLI_STR_NBR = STORE_ZONE)
    AND (RBR_CPN_LOC_ITEM_ARCHIVE.CLI_ITM_ID = ITM_ID))
    INNER JOIN PROMO_REPT_OWNER.RBR_DTL_TYPE
    ON (RBR_MASTER_CAL_ARCHIVE.PERF_DETL_TYP = RBR_DTL_TYPE.PERF_DETL_TYP)
    AND (RBR_MASTER_CAL_ARCHIVE.PERF_DETL_SUB_TYP = RBR_DTL_TYPE.PERF_DETL_SUB_TYP)
    WHERE ( ((MRKT_AREA)=40)
    AND ((RBR_DTL_TYPE.PERF_DETL_TYP)=1)
    AND ((RBR_DTL_TYPE.PERF_DETL_SUB_TYP)=1) )
    AND ((CLI_STAT_TYP)=1 Or (CLI_STAT_TYP)=6)
    AND ((RBR_MASTER_CAL_ARCHIVE.STATUS_FLAG)=''A'')
    AND ( ((PROMO_START_DATE) >= to_date(''2011-10-20'', ''YYYY-MM-DD'')
    And (PROMO_END_DATE) <= to_date(''2011-10-26'', ''YYYY-MM-DD'')) )
    ORDER BY MRKT_AREA';
    my_task_name := dbms_sqltune.create_tuning_task
                                 (sql_text => my_sqltext,
                                  user_name => 'PROMO_REPT_OWNER',
                                  scope     => 'COMPREHENSIVE',
                                  time_limit => 3600,
                                  task_name  => 'Test_Query',
                                  description  => 'Test Query');
    end;
    begin
      dbms_sqltune.execute_tuning_task(task_name => 'Test_Query');
    end;
    set serveroutput on size unlimited;
    set pagesize 5000
    set linesize 130
    set long 50000
    set longchunksize 500000
    SELECT DBMS_SQLTUNE.REPORT_TUNING_TASK('Test_Query') FROM DUAL;
    Output:
    snippet .....
    FINDINGS SECTION (1 finding)
    1- Index Finding (see explain plans section below)
    The execution plan of this statement can be improved by creating one or more
    indices.
    Recommendation (estimated benefit: 71.48%)
    - Consider running the Access Advisor to improve the physical schema design
    or creating the recommended index.
    Error: Cannot fetch actions for recommendation: INDEX
    Error: ORA-06502: PL/SQL: numeric or value error: character string buffer too small
    Rationale
    Creating the recommended indices significantly improves the execution plan
    of this statement. However, it might be preferable to run "Access Advisor"
    using a representative SQL workload as opposed to a single statement. This
    will allow to get comprehensive index recommendations which takes into
    account index maintenance overhead and additional space consumption.
    snippet
    Any ideas why I am getting ORA-06502 error?
    Thanks in advance
    Rogers

    Bug 14407401 - ORA-6502 from index recommendation section of DBMS_SQLTUNE output (Doc ID 14407401.8)
    Fixed:
    The fix for 14407401 is first included in
    12.1.0.1 (Base Release)

  • Need Help in sql tuning in EXADATA environment

    I am uploadin the sql with its current explain plan, this sql in Prd database is executing in 6-10 mins and we need to improve this sql perf to 1-2 mins as the requirement from business team.
    I am giving some backgroud about this sql tuning requirement, this sql is newly developed in and currently is in UAT phase, we don't have much option for tuning code here since the sql is tool generated through COGNOS DataMart tool, options are there to look into from DBA end with plan level or creating indexes on suitible columns to reduce i/o in minimizing the rows traversing by the sql.
    Is anybody can help me out here?
    WITH "WCRS_CLAIM_DETAIL_VW5"
    AS (SELECT "WCRS_CLAIM_DETAIL_VW"."CLAIM_DETAIL_PK_ID"
    "CLAIM_DETAIL_PK_ID",
    "WCRS_CLAIM_DETAIL_VW"."CLAIM_ID" "CLAIM_ID",
    "WCRS_CLAIM_DETAIL_VW"."CURRENT_SNAPSHOT_IND"
    "CURRENT_SNAPSHOT_IND",
    "WCRS_CLAIM_DETAIL_VW"."LOSS_DT" "LOSS_DT",
    "WCRS_CLAIM_DETAIL_VW"."REGULATORY_STATE_CD"
    "REGULATORY_STATE_CD"
    FROM "CDW_DLV_IDS"."WCRS_CLAIM_DETAIL_VW" "WCRS_CLAIM_DETAIL_VW"
    WHERE "WCRS_CLAIM_DETAIL_VW"."CURRENT_SNAPSHOT_IND" = 'Y'),
    "WCRS_POLICY_DETAIL_VW7"
    AS (SELECT "WCRS_POLICY_DETAIL_VW"."CLAIM_NBR" "CLAIM_NBR",
    "WCRS_POLICY_DETAIL_VW"."CLAIM_SYMBOL_CD" "CLAIM_SYMBOL_CD",
    "WCRS_POLICY_DETAIL_VW"."CURRENT_SNAPSHOT_IND"
    "CURRENT_SNAPSHOT_IND",
    "WCRS_POLICY_DETAIL_VW"."KEY_OFFICE_CD" "KEY_OFFICE_CD",
    "WCRS_POLICY_DETAIL_VW"."POLICY_NBR" "POLICY_NBR"
    FROM "CDW_DLV_IDS"."WCRS_POLICY_DETAIL_VW" "WCRS_POLICY_DETAIL_VW"
    WHERE "WCRS_POLICY_DETAIL_VW"."CURRENT_SNAPSHOT_IND" = 'Y')
    SELECT /*+ gather_plan_statistics monitor bind_aware */
    /* ^^unique_id */
    "T0"."C0" "Account_Name",
    "T0"."C1" "Accident_State_Cd",
    "T0"."C2" "c3",
    "T0"."C3" "PPO_Name",
    "T0"."C4" "Invc_Classification_Type_Desc",
    FIRST_VALUE (
    "T0"."C5")
    OVER (
    PARTITION BY "T0"."C0",
    "T0"."C1",
    "T0"."C2",
    "T0"."C3",
    "T0"."C4",
    "T0"."C6")
    "Claim_Cnt___Distinct",
    "T0"."C7" "Invc_Control_Number",
    "T0"."C8" "Invc_Allowance_Amt",
    "T0"."C9" "Invc_Charge_Amt",
    "T0"."C10" "c10",
    "T0"."C11" "PPO_Reduction_Amt",
    "T0"."C12" "Dup_Ln_Save_Amt",
    "T0"."C13" "c13",
    "T0"."C14" "Sub_Total",
    "T0"."C15" "c15",
    "T0"."C6" "c16"
    FROM (SELECT "T1"."C0" "C0",
    "T1"."C1" "C1",
    "T1"."C2" "C2",
    "T1"."C3" "C3",
    "T1"."C4" "C4",
    "T1"."C6" "C5",
    "T1"."C5" "C6",
    "T0"."C0" "C7",
    "T1"."C7" "C8",
    "T1"."C8" "C9",
    "T1"."C9" "C10",
    "T1"."C10" "C11",
    "T1"."C11" "C12",
    "T1"."C12" "C13",
    "T1"."C13" "C14",
    "T1"."C14" "C15"
    FROM (SELECT COUNT (DISTINCT "INVC_DIM_VW"."INVC_ID") "C0"
    FROM "CDW_DLV_IDS"."WCRS_POLICY_GROUPING_VW" "WCRS_POLICY_GROUPING_VW",
    "WCRS_CLAIM_DETAIL_VW5",
    "EDW_DM"."INVC_DIM_VW" "INVC_DIM_VW",
    "EDW_DM"."PROVIDER_NETWORK_DIM_VW" "PROVIDER_NETWORK_DIM_VW",
    "EDW_DM"."INVC_ACTY_SNPSHT_FACT_VW" "INVC_ACTY_SNPSHT_FACT_VW6",
    "EDW_DM"."CURRENT_MED_INVC_RPT_DT_VW" "CURRENT_MED_INVC_RPT_DT_VW",
    "EDW_DM"."ALL_INVC_SNPSHT_FACT_VW" "ALL_INVC_SNPSHT_FACT_VW",
    "CDW_DLV_IDS"."WCRS_CURRENT_CLAIM_RPT_DT_VW" "WCRS_CURRENT_CLAIM_RPT_DT_VW",
    "CDW_DLV_IDS"."WCRS_CLAIM_FACT_VW" "WCRS_CLAIM_FACT_VW",
    "WCRS_POLICY_DETAIL_VW7",
    "EDW_DM"."INVC_CLAIM_DTL_BRDG_FACT_VW" "INVC_CLAIM_DTL_BRDG_FACT_VW"
    WHERE "INVC_DIM_VW"."INVC_DELETION_IND" <> 'Y'
    AND "INVC_DIM_VW"."INVC_CONSIDRTN_TYPE_DESC" =
    'Original'
    AND "CURRENT_MED_INVC_RPT_DT_VW"."CURRENT_MONTH_RPT_DT" =
    "ALL_INVC_SNPSHT_FACT_VW"."AS_OF_MONTH_END_DT_PK_ID"
    AND "WCRS_CURRENT_CLAIM_RPT_DT_VW"."CURRENT_CLAIM_RPT_DT" =
    "WCRS_CLAIM_FACT_VW"."CLAIM_REPORTING_DT"
    AND "WCRS_POLICY_GROUPING_VW"."ACCOUNT_NM" =
    CAST ('1ST TEAM STAFFING SERVICES, INC.' AS VARCHAR (50 CHAR))
    AND "WCRS_POLICY_DETAIL_VW7"."POLICY_NBR" =
    "WCRS_POLICY_GROUPING_VW"."POLICY_IDENTIFIER"
    AND "WCRS_POLICY_DETAIL_VW7"."CLAIM_NBR" =
    "WCRS_CLAIM_FACT_VW"."CLAIM_NBR"
    AND "WCRS_POLICY_DETAIL_VW7"."CLAIM_SYMBOL_CD" =
    "WCRS_CLAIM_FACT_VW"."CLAIM_SYMBOL_CD"
    AND "WCRS_POLICY_DETAIL_VW7"."KEY_OFFICE_CD" =
    "WCRS_CLAIM_FACT_VW"."KEY_OFFICE_CD"
    AND "WCRS_POLICY_DETAIL_VW7"."CURRENT_SNAPSHOT_IND" =
    'Y'
    AND "WCRS_CLAIM_FACT_VW"."CLAIM_DETAIL_PK_ID" =
    "WCRS_CLAIM_DETAIL_VW5"."CLAIM_DETAIL_PK_ID"
    AND "WCRS_CLAIM_DETAIL_VW5"."CURRENT_SNAPSHOT_IND" =
    'Y'
    AND "WCRS_CLAIM_FACT_VW"."CLAIM_GID" =
    "INVC_CLAIM_DTL_BRDG_FACT_VW"."CLM_GID"
    AND "INVC_CLAIM_DTL_BRDG_FACT_VW"."INVC_GID" =
    "INVC_DIM_VW"."INVC_GID"
    AND "INVC_DIM_VW"."INVC_PK_ID" =
    "INVC_ACTY_SNPSHT_FACT_VW6"."INVC_PK_ID"
    AND "ALL_INVC_SNPSHT_FACT_VW"."MONTH_END_DT_PK_ID" =
    "INVC_ACTY_SNPSHT_FACT_VW6"."MONTH_END_DT_PK_ID"
    AND "ALL_INVC_SNPSHT_FACT_VW"."INVC_GID" =
    "INVC_ACTY_SNPSHT_FACT_VW6"."INVC_GID"
    AND "PROVIDER_NETWORK_DIM_VW"."PROVIDER_NETWORK_PK_ID" =
    "INVC_ACTY_SNPSHT_FACT_VW6"."PPO_PROVIDER_NETWORK_PK_ID"
    AND "WCRS_CURRENT_CLAIM_RPT_DT_VW"."CURRENT_CLAIM_RPT_DT" =
    "WCRS_CLAIM_FACT_VW"."CLAIM_REPORTING_DT") "T0",
    ( SELECT "WCRS_POLICY_GROUPING_VW"."ACCOUNT_NM" "C0",
    "WCRS_CLAIM_DETAIL_VW5"."REGULATORY_STATE_CD" "C1",
    CASE
    WHEN "INVC_DIM_VW"."INVC_IN_OUT_OF_NETWORK_IND" =
    'Y'
    THEN
    'In - Network'
    WHEN "INVC_DIM_VW"."INVC_IN_OUT_OF_NETWORK_IND" =
    'N'
    THEN
    'Out - Network'
    ELSE
    'Others'
    END
    "C2",
    "PROVIDER_NETWORK_DIM_VW"."PROVIDER_NETWORK_NM" "C3",
    "INVC_DIM_VW"."INVC_CLASS_TYPE_DESC" "C4",
    CASE
    WHEN (EXTRACT (
    YEAR FROM ("WCRS_CLAIM_DETAIL_VW5"."LOSS_DT"))
    IS NULL)
    OR (EXTRACT (
    MONTH FROM ("WCRS_CLAIM_DETAIL_VW5"."LOSS_DT"))
    IS NULL)
    THEN
    NULL
    ELSE
    ( EXTRACT (
    YEAR FROM ("WCRS_CLAIM_DETAIL_VW5"."LOSS_DT"))
    || EXTRACT (
    MONTH FROM ("WCRS_CLAIM_DETAIL_VW5"."LOSS_DT")))
    END
    "C5",
    COUNT (DISTINCT "WCRS_CLAIM_DETAIL_VW5"."CLAIM_ID")
    "C6",
    SUM ("INVC_ACTY_SNPSHT_FACT_VW6"."INVC_ALWC_AMT") "C7",
    SUM ("INVC_ACTY_SNPSHT_FACT_VW6"."INVC_CHRGS_AMT")
    "C8",
    SUM (
    "INVC_ACTY_SNPSHT_FACT_VW6"."TOT_INVC_REVIEW_RULE_ALWC_AMT")
    "C9",
    SUM ("INVC_ACTY_SNPSHT_FACT_VW6"."INVC_PPO_REDUC_AMT")
    "C10",
    SUM ("INVC_ACTY_SNPSHT_FACT_VW6"."INVC_DUP_REDUC_AMT")
    "C11",
    SUM ("INVC_ACTY_SNPSHT_FACT_VW6"."INVC_OSR_REDUC_AMT")
    "C12",
    ( SUM (
    "INVC_ACTY_SNPSHT_FACT_VW6"."INVC_CHRGS_AMT")
    - SUM ("INVC_ACTY_SNPSHT_FACT_VW6"."INVC_ALWC_AMT"))
    - SUM (
    "INVC_ACTY_SNPSHT_FACT_VW6"."INVC_DUP_REDUC_AMT")
    "C13",
    SUM (
    "INVC_ACTY_SNPSHT_FACT_VW6"."INVC_CLNT_SPEC_REDUC_AMT")
    "C14"
    FROM "CDW_DLV_IDS"."WCRS_POLICY_GROUPING_VW" "WCRS_POLICY_GROUPING_VW",
    "WCRS_CLAIM_DETAIL_VW5",
    "EDW_DM"."INVC_DIM_VW" "INVC_DIM_VW",
    "EDW_DM"."PROVIDER_NETWORK_DIM_VW" "PROVIDER_NETWORK_DIM_VW",
    "EDW_DM"."INVC_ACTY_SNPSHT_FACT_VW" "INVC_ACTY_SNPSHT_FACT_VW6",
    "EDW_DM"."CURRENT_MED_INVC_RPT_DT_VW" "CURRENT_MED_INVC_RPT_DT_VW",
    "EDW_DM"."ALL_INVC_SNPSHT_FACT_VW" "ALL_INVC_SNPSHT_FACT_VW",
    "CDW_DLV_IDS"."WCRS_CURRENT_CLAIM_RPT_DT_VW" "WCRS_CURRENT_CLAIM_RPT_DT_VW",
    "CDW_DLV_IDS"."WCRS_CLAIM_FACT_VW" "WCRS_CLAIM_FACT_VW",
    "WCRS_POLICY_DETAIL_VW7",
    "EDW_DM"."INVC_CLAIM_DTL_BRDG_FACT_VW" "INVC_CLAIM_DTL_BRDG_FACT_VW"
    WHERE "INVC_DIM_VW"."INVC_DELETION_IND" <> 'Y'
    AND "INVC_DIM_VW"."INVC_CONSIDRTN_TYPE_DESC" =
    'Original'
    AND "CURRENT_MED_INVC_RPT_DT_VW"."CURRENT_MONTH_RPT_DT" =
    "ALL_INVC_SNPSHT_FACT_VW"."AS_OF_MONTH_END_DT_PK_ID"
    AND "WCRS_CURRENT_CLAIM_RPT_DT_VW"."CURRENT_CLAIM_RPT_DT" =
    "WCRS_CLAIM_FACT_VW"."CLAIM_REPORTING_DT"
    AND "WCRS_POLICY_GROUPING_VW"."ACCOUNT_NM" =
    CAST ('1ST TEAM STAFFING SERVICES, INC.' AS VARCHAR (50 CHAR))
    AND "WCRS_POLICY_DETAIL_VW7"."POLICY_NBR" =
    "WCRS_POLICY_GROUPING_VW"."POLICY_IDENTIFIER"
    AND "WCRS_POLICY_DETAIL_VW7"."CLAIM_NBR" =
    "WCRS_CLAIM_FACT_VW"."CLAIM_NBR"
    AND "WCRS_POLICY_DETAIL_VW7"."CLAIM_SYMBOL_CD" =
    "WCRS_CLAIM_FACT_VW"."CLAIM_SYMBOL_CD"
    AND "WCRS_POLICY_DETAIL_VW7"."KEY_OFFICE_CD" =
    "WCRS_CLAIM_FACT_VW"."KEY_OFFICE_CD"
    AND "WCRS_POLICY_DETAIL_VW7"."CURRENT_SNAPSHOT_IND" =
    'Y'
    AND "WCRS_CLAIM_FACT_VW"."CLAIM_DETAIL_PK_ID" =
    "WCRS_CLAIM_DETAIL_VW5"."CLAIM_DETAIL_PK_ID"
    AND "WCRS_CLAIM_DETAIL_VW5"."CURRENT_SNAPSHOT_IND" =
    'Y'
    AND "WCRS_CLAIM_FACT_VW"."CLAIM_GID" =
    "INVC_CLAIM_DTL_BRDG_FACT_VW"."CLM_GID"
    AND "INVC_CLAIM_DTL_BRDG_FACT_VW"."INVC_GID" =
    "INVC_DIM_VW"."INVC_GID"
    AND "INVC_DIM_VW"."INVC_PK_ID" =
    "INVC_ACTY_SNPSHT_FACT_VW6"."INVC_PK_ID"
    AND "ALL_INVC_SNPSHT_FACT_VW"."MONTH_END_DT_PK_ID" =
    "INVC_ACTY_SNPSHT_FACT_VW6"."MONTH_END_DT_PK_ID"
    AND "ALL_INVC_SNPSHT_FACT_VW"."INVC_GID" =
    "INVC_ACTY_SNPSHT_FACT_VW6"."INVC_GID"
    AND "PROVIDER_NETWORK_DIM_VW"."PROVIDER_NETWORK_PK_ID" =
    "INVC_ACTY_SNPSHT_FACT_VW6"."PPO_PROVIDER_NETWORK_PK_ID"
    AND "WCRS_CURRENT_CLAIM_RPT_DT_VW"."CURRENT_CLAIM_RPT_DT" =
    "WCRS_CLAIM_FACT_VW"."CLAIM_REPORTING_DT"
    GROUP BY "WCRS_POLICY_GROUPING_VW"."ACCOUNT_NM",
    "WCRS_CLAIM_DETAIL_VW5"."REGULATORY_STATE_CD",
    CASE
    WHEN "INVC_DIM_VW"."INVC_IN_OUT_OF_NETWORK_IND" =
    'Y'
    THEN
    'In - Network'
    WHEN "INVC_DIM_VW"."INVC_IN_OUT_OF_NETWORK_IND" =
    'N'
    THEN
    'Out - Network'
    ELSE
    'Others'
    END,
    "PROVIDER_NETWORK_DIM_VW"."PROVIDER_NETWORK_NM",
    "INVC_DIM_VW"."INVC_CLASS_TYPE_DESC",
    CASE
    WHEN (EXTRACT (
    YEAR FROM ("WCRS_CLAIM_DETAIL_VW5"."LOSS_DT"))
    IS NULL)
    OR (EXTRACT (
    MONTH FROM ("WCRS_CLAIM_DETAIL_VW5"."LOSS_DT"))
    IS NULL)
    THEN
    NULL
    ELSE
    ( EXTRACT (
    YEAR FROM ("WCRS_CLAIM_DETAIL_VW5"."LOSS_DT"))
    || EXTRACT (
    MONTH FROM ("WCRS_CLAIM_DETAIL_VW5"."LOSS_DT")))
    END) "T1") "T0"
    ORDER BY "Account_Name" ASC NULLS LAST,
    "Accident_State_Cd" ASC NULLS LAST,
    "c3" ASC NULLS LAST,
    "PPO_Name" ASC NULLS LAST,
    "Invc_Classification_Type_Desc" ASC NULLS LAST

    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
    | 0 | SELECT STATEMENT | | 1 | 838 | 1079K (1)| 00:00:34 | | |
    | 1 | TEMP TABLE TRANSFORMATION | | | | | | | |
    | 2 | PX COORDINATOR | | | | | | | |
    | 3 | PX SEND QC (RANDOM) | :TQ10000 | 10M| 317M| 848K (1)| 00:00:27 | | |
    | 4 | LOAD AS SELECT | SYS_TEMP_0FD9D677A_286AAA2E | | | | | | |
    | 5 | PX BLOCK ITERATOR | | 10M| 317M| 848K (1)| 00:00:27 | | |
    |* 6 | TABLE ACCESS STORAGE FULL | WCRS_CLAIM_DETAIL | 10M| 317M| 848K (1)| 00:00:27 | | |
    | 7 | PX COORDINATOR | | | | | | | |
    | 8 | PX SEND QC (RANDOM) | :TQ20000 | 10M| 268M| 44875 (1)| 00:00:02 | | |
    | 9 | LOAD AS SELECT | SYS_TEMP_0FD9D677B_286AAA2E | | | | | | |
    | 10 | PX BLOCK ITERATOR | | 10M| 268M| 44875 (1)| 00:00:02 | | |
    |* 11 | TABLE ACCESS STORAGE FULL | WCRS_POLICY_DETAIL | 10M| 268M| 44875 (1)| 00:00:02 | | |
    | 12 | PX COORDINATOR | | | | | | | |
    | 13 | PX SEND QC (ORDER) | :TQ40017 | 1 | 838 | 186K (2)| 00:00:06 | | |
    | 14 | WINDOW SORT | | 1 | 838 | 186K (2)| 00:00:06 | | |
    | 15 | PX RECEIVE | | 1 | 838 | 186K (2)| 00:00:06 | | |
    | 16 | PX SEND RANGE | :TQ40016 | 1 | 838 | 186K (2)| 00:00:06 | | |
    | 17 | NESTED LOOPS | | 1 | 838 | 186K (2)| 00:00:06 | | |
    | 18 | BUFFER SORT | | | | | | | |
    | 19 | PX RECEIVE | | | | | | | |
    | 20 | PX SEND BROADCAST | :TQ40001 | | | | | | |
    | 21 | VIEW | | 1 | 13 | 93216 (2)| 00:00:03 | | |
    | 22 | SORT GROUP BY | | 1 | 393 | | | | |
    | 23 | PX COORDINATOR | | | | | | | |
    | 24 | PX SEND QC (RANDOM) | :TQ30015 | 1 | 393 | | | | |
    | 25 | SORT GROUP BY | | 1 | 393 | | | | |
    | 26 | PX RECEIVE | | 1 | 393 | | | | |
    | 27 | PX SEND HASH | :TQ30014 | 1 | 393 | | | | |
    | 28 | SORT GROUP BY | | 1 | 393 | | | | |
    |* 29 | HASH JOIN ANTI | | 1 | 393 | 93216 (2)| 00:00:03 | | |
    | 30 | PX RECEIVE | | 1 | 376 | 85197 (2)| 00:00:03 | | |
    | 31 | PX SEND HASH | :TQ30012 | 1 | 376 | 85197 (2)| 00:00:03 | | |
    | 32 | BUFFER SORT | | 1 | 838 | | | | |
    | 33 | NESTED LOOPS | | 1 | 376 | 85197 (2)| 00:00:03 | | |
    | 34 | NESTED LOOPS | | 1 | 358 | 85197 (2)| 00:00:03 | | |
    | 35 | NESTED LOOPS | | 1 | 348 | 85197 (2)| 00:00:03 | | |
    |* 36 | HASH JOIN ANTI | | 1 | 316 | 85179 (2)| 00:00:03 | | |
    | 37 | PX RECEIVE | | 4 | 1156 | 77161 (2)| 00:00:03 | | |
    | 38 | PX SEND HASH | :TQ30010 | 4 | 1156 | 77161 (2)| 00:00:03 | | |
    |* 39 | HASH JOIN ANTI BUFFERED | | 4 | 1156 | 77161 (2)| 00:00:03 | | |
    | 40 | PX RECEIVE | | 371 | 94605 | 69142 (2)| 00:00:03 | | |
    | 41 | PX SEND HASH | :TQ30008 | 371 | 94605 | 69142 (2)| 00:00:03 | | |
    |* 42 | HASH JOIN | | 371 | 94605 | 69142 (2)| 00:00:03 | | |
    | 43 | PX RECEIVE | | 350 | 77000 | 36642 (1)| 00:00:02 | | |
    | 44 | PX SEND BROADCAST | :TQ30007 | 350 | 77000 | 36642 (1)| 00:00:02 | | |
    |* 45 | HASH JOIN | | 350 | 77000 | 36642 (1)| 00:00:02 | | |
    | 46 | PX RECEIVE | | 140 | 25200 | 28624 (1)| 00:00:01 | | |
    | 47 | PX SEND BROADCAST | :TQ30006 | 140 | 25200 | 28624 (1)| 00:00:01 | | |
    |* 48 | HASH JOIN | | 140 | 25200 | 28624 (1)| 00:00:01 | | |
    | 49 | PX RECEIVE | | 140 | 22820 | 25169 (1)| 00:00:01 | | |
    | 50 | PX SEND BROADCAST | :TQ30005 | 140 | 22820 | 25169 (1)| 00:00:01 | | |
    |* 51 | HASH JOIN BUFFERED | | 140 | 22820 | 25169 (1)| 00:00:01 | | |
    | 52 | BUFFER SORT | | | | | | | |
    | 53 | PX RECEIVE | | 9 | 306 | 5 (0)| 00:00:01 | | |
    | 54 | T PX SEND BROADCAS | :TQ30000 | 9 | 306 | 5 (0)| 00:00:01 | | |
    | 55 | INDEX ROWID TABLE ACCESS BY | WCRS_POLICY_GROUPING | 9 | 306 | 5 (0)| 00:00:01 | | |
    |* 56 | AN INDEX RANGE SC | SUK3 | 9 | | 1 (0)| 00:00:01 | | |
    |* 57 | HASH JOIN | | 9699K| 1193M| 25149 (1)| 00:00:01 | | |
    | 58 | PX RECEIVE | | 9699K| 434M| 22205 (1)| 00:00:01 | | |
    | 59 | PX SEND HASH | :TQ30003 | 9699K| 434M| 22205 (1)| 00:00:01 | | |
    | 60 | NESTED LOOPS | | 9699K| 434M| 22205 (1)| 00:00:01 | | |
    | 61 | BUFFER SORT | | | | | | | |
    | 62 | PX RECEIVE | | | | | | | |
    | 63 | DCAST PX SEND BROA | :TQ30002 | | | | | | |
    | 64 | CARTESIAN MERGE JOIN | | 1 | 14 | 13 (0)| 00:00:01 | | |
    | 65 | TERATOR PX BLOCK I | | 1 | 8 | 10 (0)| 00:00:01 | | |
    | 66 | ESS STORAGE FULL TABLE ACC | CURRENT_MED_INVC_RPT_DT | 1 | 8 | 10 (0)| 00:00:01 | | |
    | 67 | T BUFFER SOR | | 1 | 6 | 3 (0)| 00:00:01 | | |
    | 68 | E PX RECEIV | | 1 | 6 | 2 (0)| 00:00:01 | | |
    | 69 | BROADCAST PX SEND | :TQ30001 | 1 | 6 | 2 (0)| 00:00:01 | | |
    | 70 | K ITERATOR PX BLOC | | 1 | 6 | 2 (0)| 00:00:01 | | |
    | 71 | ACCESS STORAGE FULL TABLE | WCRS_CURRENT_CLAIM_RPT_DT | 1 | 6 | 2 (0)| 00:00:01 | | |
    | 72 | TOR PX BLOCK ITERA | | 9699K| 305M| 22192 (1)| 00:00:01 | KEY | KEY |
    |* 73 | STORAGE FULL TABLE ACCESS | WCRS_CURRENT_CLAIM_FACT | 9699K| 305M| 22192 (1)| 00:00:01 | KEY | KEY |
    | 74 | PX RECEIVE | | 10M| 785M| 2907 (2)| 00:00:01 | | |
    | 75 | PX SEND HASH | :TQ30004 | 10M| 785M| 2907 (2)| 00:00:01 | | |
    |* 76 | VIEW | | 10M| 785M| 2907 (2)| 00:00:01 | | |
    | 77 | TOR PX BLOCK ITERA | | 10M| 268M| 2907 (2)| 00:00:01 | | |
    | 78 | STORAGE FULL TABLE ACCESS | SYS_TEMP_0FD9D677B_286AAA2E | 10M| 268M| 2907 (2)| 00:00:01 | | |
    |* 79 | VIEW | | 10M| 168M| 3439 (2)| 00:00:01 | | |
    | 80 | PX BLOCK ITERATOR | | 10M| 317M| 3439 (2)| 00:00:01 | | |
    | 81 | E FULL TABLE ACCESS STORAG | SYS_TEMP_0FD9D677A_286AAA2E | 10M| 317M| 3439 (2)| 00:00:01 | | |
    | 82 | PX BLOCK ITERATOR | | 15M| 599M| 7994 (1)| 00:00:01 | | |
    | 83 | LL TABLE ACCESS STORAGE FU | INVC_CLAIM_DTL_BRDG_FACT | 15M| 599M| 7994 (1)| 00:00:01 | | |
    | 84 | PX BLOCK ITERATOR | | 15M| 521M| 32477 (2)| 00:00:02 | | |
    |* 85 | TABLE ACCESS STORAGE FULL | INVC_DIM | 15M| 521M| 32477 (2)| 00:00:02 | | |
    | 86 | PX RECEIVE | | 15M| 509M| 7994 (1)| 00:00:01 | | |
    | 87 | PX SEND HASH | :TQ30009 | 15M| 509M| 7994 (1)| 00:00:01 | | |
    | 88 | PX BLOCK ITERATOR | | 15M| 509M| 7994 (1)| 00:00:01 | | |
    | 89 | TABLE ACCESS STORAGE FULL | INVC_CLAIM_DTL_BRDG_FACT | 15M| 509M| 7994 (1)| 00:00:01 | | |
    | 90 | PX RECEIVE | | 15M| 404M| 7994 (1)| 00:00:01 | | |
    | 91 | PX SEND HASH | :TQ30011 | 15M| 404M| 7994 (1)| 00:00:01 | | |
    | 92 | PX BLOCK ITERATOR | | 15M| 404M| 7994 (1)| 00:00:01 | | |
    | 93 | TABLE ACCESS STORAGE FULL | INVC_CLAIM_DTL_BRDG_FACT | 15M| 404M| 7994 (1)| 00:00:01 | | |
    | 94 | TABLE ACCESS BY INDEX ROWID | INVC_ACTY_SNPSHT_FACT | 1 | 32 | 18 (0)| 00:00:01 | | |
    |* 95 | INDEX RANGE SCAN | IFK_XPKINVOICE_ACTIVITY_SNAPSH | 1 | | 1 (0)| 00:00:01 | | |
    |* 96 | INDEX UNIQUE SCAN | IFK_XPKPROVIDER_NETWORK_DIM | 1 | 10 | 0 (0)| 00:00:01 | | |
    |* 97 | INDEX RANGE SCAN | IFK_XPKALL_INVC_SNPSHT_FACT | 1 | 18 | 1 (0)| 00:00:01 | | |
    | 98 | PX RECEIVE | | 15M| 254M| 7994 (1)| 00:00:01 | | |
    | 99 | PX SEND HASH | :TQ30013 | 15M| 254M| 7994 (1)| 00:00:01 | | |
    | 100 | PX BLOCK ITERATOR | | 15M| 254M| 7994 (1)| 00:00:01 | | |
    | 101 | TABLE ACCESS STORAGE FULL | INVC_CLAIM_DTL_BRDG_FACT | 15M| 254M| 7994 (1)| 00:00:01 | | |
    | 102 | VIEW | | 1 | 825 | | | | |
    | 103 | SORT GROUP BY | | 1 | 430 | 93216 (2)| 00:00:03 | | |
    | 104 | BUFFER SORT | | | | | | | |
    | 105 | PX RECEIVE | | 1 | 430 | 93216 (2)| 00:00:03 | | |
    | 106 | PX SEND HASH | :TQ40015 | 1 | 430 | 93216 (2)| 00:00:03 | | |
    |*107 | HASH JOIN ANTI BUFFERED | | 1 | 430 | 93216 (2)| 00:00:03 | | |
    | 108 | PX RECEIVE | | 1 | 413 | 85198 (2)| 00:00:03 | | |
    | 109 | PX SEND HASH | :TQ40013 | 1 | 413 | 85198 (2)| 00:00:03 | | |
    | 110 | BUFFER SORT | | 1 | 838 | | | | |
    | 111 | NESTED LOOPS | | 1 | 413 | 85198 (2)| 00:00:03 | | |
    | 112 | NESTED LOOPS | | 1 | 395 | 85197 (2)| 00:00:03 | | |
    | 113 | NESTED LOOPS | | 1 | 369 | 85197 (2)| 00:00:03 | | |
    |*114 | HASH JOIN ANTI | | 1 | 311 | 85179 (2)| 00:00:03 | | |
    | 115 | PX RECEIVE | | 4 | 1136 | 77161 (2)| 00:00:03 | | |
    | 116 | PX SEND HASH | :TQ40011 | 4 | 1136 | 77161 (2)| 00:00:03 | | |
    |*117 | HASH JOIN ANTI BUFFERED | | 4 | 1136 | 77161 (2)| 00:00:03 | | |
    | 118 | PX RECEIVE | | 371 | 92750 | 69143 (2)| 00:00:03 | | |
    | 119 | PX SEND HASH | :TQ40009 | 371 | 92750 | 69143 (2)| 00:00:03 | | |
    |*120 | HASH JOIN | | 371 | 92750 | 69143 (2)| 00:00:03 | | |
    | 121 | PX RECEIVE | | 350 | 72450 | 36642 (1)| 00:00:02 | | |
    | 122 | PX SEND BROADCAST | :TQ40008 | 350 | 72450 | 36642 (1)| 00:00:02 | | |
    |*123 | HASH JOIN | | 350 | 72450 | 36642 (1)| 00:00:02 | | |
    | 124 | PX RECEIVE | | 140 | 23380 | 28624 (1)| 00:00:01 | | |
    | 125 | PX SEND BROADCAST | :TQ40007 | 140 | 23380 | 28624 (1)| 00:00:01 | | |
    |*126 | HASH JOIN | | 140 | 23380 | 28624 (1)| 00:00:01 | | |
    | 127 | PX RECEIVE | | 140 | 15540 | 25169 (1)| 00:00:01 | | |
    | 128 | PX SEND BROADCAST | :TQ40006 | 140 | 15540 | 25169 (1)| 00:00:01 | | |
    |*129 | HASH JOIN BUFFERED | | 140 | 15540 | 25169 (1)| 00:00:01 | | |
    | 130 | BUFFER SORT | | | | | | | |
    | 131 | PX RECEIVE | | 9 | 306 | 5 (0)| 00:00:01 | | |
    | 132 | PX SEND BROADCAST | :TQ40000 | 9 | 306 | 5 (0)| 00:00:01 | | |
    | 133 | ROWID TABLE ACCESS BY INDEX | WCRS_POLICY_GROUPING | 9 | 306 | 5 (0)| 00:00:01 | | |
    |*134 | INDEX RANGE SCAN | SUK3 | 9 | | 1 (0)| 00:00:01 | | |
    |*135 | HASH JOIN | | 9699K| 712M| 25149 (1)| 00:00:01 | | |
    | 136 | PX RECEIVE | | 10M| 287M| 2907 (2)| 00:00:01 | | |
    | 137 | PX SEND HASH | :TQ40004 | 10M| 287M| 2907 (2)| 00:00:01 | | |
    |*138 | VIEW | | 10M| 287M| 2907 (2)| 00:00:01 | | |
    | 139 | PX BLOCK ITERATOR | | 10M| 268M| 2907 (2)| 00:00:01 | | |
    | 140 | E FULL TABLE ACCESS STORAG | SYS_TEMP_0FD9D677B_286AAA2E | 10M| 268M| 2907 (2)| 00:00:01 | | |
    | 141 | PX RECEIVE | | 9699K| 434M| 22205 (1)| 00:00:01 | | |
    | 142 | PX SEND HASH | :TQ40005 | 9699K| 434M| 22205 (1)| 00:00:01 | | |
    | 143 | NESTED LOOPS | | 9699K| 434M| 22205 (1)| 00:00:01 | | |
    | 144 | BUFFER SORT | | | | | | | |
    | 145 | PX RECEIVE | | | | | | | |
    | 146 | PX SEND BROADCAST | :TQ40003 | | | | | | |
    | 147 | IAN MERGE JOIN CARTES | | 1 | 14 | 13 (0)| 00:00:01 | | |
    | 148 | R PX BLOCK ITERATO | | 1 | 8 | 10 (0)| 00:00:01 | | |
    | 149 | ORAGE FULL TABLE ACCESS ST | CURRENT_MED_INVC_RPT_DT | 1 | 8 | 10 (0)| 00:00:01 | | |
    | 150 | BUFFER SORT | | 1 | 6 | 3 (0)| 00:00:01 | | |
    | 151 | PX RECEIVE | | 1 | 6 | 2 (0)| 00:00:01 | | |
    | 152 | AST PX SEND BROADC | :TQ40002 | 1 | 6 | 2 (0)| 00:00:01 | | |
    | 153 | ATOR PX BLOCK ITER | | 1 | 6 | 2 (0)| 00:00:01 | | |
    | 154 | STORAGE FULL TABLE ACCESS | WCRS_CURRENT_CLAIM_RPT_DT | 1 | 6 | 2 (0)| 00:00:01 | | |
    | 155 | PX BLOCK ITERATOR | | 9699K| 305M| 22192 (1)| 00:00:01 | KEY | KEY |
    |*156 | E FULL TABLE ACCESS STORAG | WCRS_CURRENT_CLAIM_FACT | 9699K| 305M| 22192 (1)| 00:00:01 | KEY | KEY |
    |*157 | VIEW | | 10M| 555M| 3439 (2)| 00:00:01 | | |
    | 158 | PX BLOCK ITERATOR | | 10M| 317M| 3439 (2)| 00:00:01 | | |
    | 159 | TABLE ACCESS STORAGE FULL | SYS_TEMP_0FD9D677A_286AAA2E | 10M| 317M| 3439 (2)| 00:00:01 | | |
    | 160 | PX BLOCK ITERATOR | | 15M| 599M| 7994 (1)| 00:00:01 | | |
    | 161 | TABLE ACCESS STORAGE FULL | INVC_CLAIM_DTL_BRDG_FACT | 15M| 599M| 7994 (1)| 00:00:01 | | |
    | 162 | PX BLOCK ITERATOR | | 15M| 641M| 32477 (2)| 00:00:02 | | |
    |*163 | TABLE ACCESS STORAGE FULL | INVC_DIM | 15M| 641M| 32477 (2)| 00:00:02 | | |
    | 164 | PX RECEIVE | | 15M| 509M| 7994 (1)| 00:00:01 | | |
    | 165 | PX SEND HASH | :TQ40010 | 15M| 509M| 7994 (1)| 00:00:01 | | |
    | 166 | PX BLOCK ITERATOR | | 15M| 509M| 7994 (1)| 00:00:01 | | |
    | 167 | TABLE ACCESS STORAGE FULL | INVC_CLAIM_DTL_BRDG_FACT | 15M| 509M| 7994 (1)| 00:00:01 | | |
    | 168 | PX RECEIVE | | 15M| 404M| 7994 (1)| 00:00:01 | | |
    | 169 | PX SEND HASH | :TQ40012 | 15M| 404M| 7994 (1)| 00:00:01 | | |
    | 170 | PX BLOCK ITERATOR | | 15M| 404M| 7994 (1)| 00:00:01 | | |
    | 171 | TABLE ACCESS STORAGE FULL | INVC_CLAIM_DTL_BRDG_FACT | 15M| 404M| 7994 (1)| 00:00:01 | | |
    | 172 | TABLE ACCESS BY INDEX ROWID | INVC_ACTY_SNPSHT_FACT | 1 | 58 | 18 (0)| 00:00:01 | | |
    |*173 | INDEX RANGE SCAN | IFK_XPKINVOICE_ACTIVITY_SNAPSH | 1 | | 1 (0)| 00:00:01 | | |
    | 174 | TABLE ACCESS BY INDEX ROWID | PROVIDER_NETWORK_DIM | 1 | 26 | 0 (0)| 00:00:01 | | |
    |*175 | INDEX UNIQUE SCAN | IFK_XPKPROVIDER_NETWORK_DIM | 1 | | 0 (0)| 00:00:01 | | |
    |*176 | INDEX RANGE SCAN | IFK_XPKALL_INVC_SNPSHT_FACT | 1 | 18 | 1 (0)| 00:00:01 | | |
    | 177 | PX RECEIVE | | 15M| 254M| 7994 (1)| 00:00:01 | | |
    | 178 | PX SEND HASH | :TQ40014 | 15M| 254M| 7994 (1)| 00:00:01 | | |
    | 179 | PX BLOCK ITERATOR | | 15M| 254M| 7994 (1)| 00:00:01 | | |
    | 180 | TABLE ACCESS STORAGE FULL | INVC_CLAIM_DTL_BRDG_FACT | 15M| 254M| 7994 (1)| 00:00:01 | | |
    ---------------------------------------------------------------------------------------------------------------------------------------------------------------

Maybe you are looking for