Friday Dec 02, 2011

Capturing 10053 trace files continued

In our previous blog post I described how you can use the new diagnostic event infrastructure in Oracle Database 11g to capture an Optimizer trace (10053) for any SQL statement once you have its SQL_ID. The approach I showed using the traditional ‘Alter session set event’ approach. What I forgot to mention (and have been scolded for) was that you can also use the new infrastructure to generate an Optimizer trace for any SQL statement in the cursor cache, without having to re-execute it.[Read More]

Wednesday Nov 16, 2011

How do I capture a 10053 trace for a SQL statement called in a PL/SQL package?

Traditionally if you wanted to capture an Optimizer trace (10053) for a SQL statement you would issue an alter session command to switch on a 10053 trace for that entire session, and then issue the SQL statement you wanted to capture the trace for. Once the statement completed you would exit the session to disable the trace. You would then look in the USER_DUMP_DEST directory for the trace file. But what if the SQL statement you were interested  in was actually called as part of a PL/SQL package. How do generate an Optimizer trace for just that statement?[Read More]

Tuesday Sep 01, 2009

What's Changed between my New Query Plan and the Old One?

In most cases the first step in debugging a performance problem caused by a plan change is to visually inspect both of the execution plans generated by the query optimizer. Usually the customer has a known plan that performed well and the new plan that performs worse. Visual inspection of plans is easy when the query is not too complex but becomes a tedious exercise when the query is complex (involving tens of joins, sub-queries, views, etc). This article introduces a new plan comparison tool implemented in Oracle Database 11gR2.[Read More]

Friday Mar 14, 2008

Oracle keeps closing my TAR because I cannot provide a testcase, can you help?

The answer to this question is yes, as Oracle Database 11g provides a new diagnostic tool called SQL Test Case Builder. In this article, we explain what SQL Test Case Builder is, and how to use it with examples.

Why SQL Test Case Builder?

For most SQL problems, the single most important factor for a speedy bug resolution is to obtain a reproducible test case. However, this is normally the longest and most painful step for customers. The goal of the SQL Test Case Builder (TCB) is to automatically gather as much information as possible related to a SQL incident (problem) and package it in a way that allows a developer or a support engineer to reproduce the problem on his or her own machine quickly. At a very high-level, SQL Test Case Builder can be seen as a way to export a SQL. Currently, Oracle export (expdp) takes a schema or a set of tables and exports all the dependents objects. SQL Test Case Builder provides the same service but takes a SQL statement as input.

What's Inside Test Case Builder?

The main input of SQL Test Case Builder is a SQL object. A SQL object is defined as the SQL text plus all the information required to compile it on a particular database instance (this contains the parsing user name, for example). Logically, a SQL test case appears as a script containing all the necessary commands to recreate the objects, the user, the statistics, and the environment. Within the Oracle Diagnosability infrastructure, TCB compiles the problem SQL in a special capture mode to obtain the set of objects to export. A test case captures two types of information:

  1. Permanent information
    • SQL text
    • PL/SQL functions, procedures, packages
    • Statistics
    • Bind variables
    • Compilation environment
    • User information (like privileges)
    • SQL profiles, stored outlines, or other SQL Management Objects
    • Meta data on all the objects involved
    • Optimizer statistics
    • The execution plan information
    • The table content (sample or full). This is optional.
  2. Transient information
  3. For most of the SQL test cases, the permanent information above is enough to reproduce a problem. There are however cases where this is not enough and additional information about the context in which this SQL was compiled is required. Therefore, in addition to the permanent information, SQL Test Case Builder captures transient information, e.g. information that is only available as part of the compilation of the SQL statement. This includes dynamic sampling results, cached information, some run time information, like the actual degree of parallelism used, etc. As part of creating a SQL test case, the SQL object is reloaded and all the diagnostic information available generated and gathered automatically. This information will be made available to Oracle support and developers.

How do I use the SQL Test Case Builder?

The task of creating a SQL test case can be performed in two ways:
  • From EM (Enterprise Manager), where TCB is invoked on user-demand via IPS (Incident Packaging Service) after a SQL incident occurred. The user can also manually create an incident for a problem query for building test case purpose.
  • From SQLPLUS, where you can directly invoke one of the PL/SQL API functions in the SQL Diagnostic package. We will give examples of using the APIs below.
All the new PL/SQL procedures supporting SQL Test Case Builder are part of a new PL/SQL package called dbms_sqldiag (see dbmsdiag.sql for details). The two main features related to TCB in this package are export and import test cases.
  • Procedure dbms_sqldiag.export_sql_testcase exports a SQL test case for a given SQL statement to a given directory.
  • Procedure dbms_sqldiag.import_sql_testcase imports a test case from a given directory.
To build (or export) a test case, the simplest form would be something like:
     dbms_sqldiag.export_sql_testcase(
       directory  => 'TCB_DIR_EXP',
       sql_text   => 'select count(*) from sales',
       testcase   => tco)
Here directory and sql_text are inputs which specify where the test case will be stored, and the problem query statement, respectively. Testcase specifies the test case metadata as output. For security reason, the user data are not exported by default. You have the option to set exportData to TRUE to include the data. You can also set samplingPercent if you are exporting with data. To protect users proprietary codes, TCB will not export PL/SQL package body by default. Once the test case has been built, you can copy all the files under the export directory to your test environment. Note there is a file called xxxxxxxxmain.xml, for example, oratcb1_03C600800001main.xml, which contains the metadata of the test case. Now importing the test case can be as simple as:
     dbms_sqldiag.import_sql_testcase(
       directory => 'TEST_DIR',
       filename => 'oratcb1_03C600800001main.xml')
To verify that the test case is successfully rebuilt, you can just issue an explain command for the problem query. However, if you want to actully run the query, then you need to have the data available. You can refer to dbmsdiag.sql for more information about other options available for these procedures.

Example - We now show the typical steps of using TCB by a sample query with materialized view. In this exmaple, we set the exportData option to TRUE, so we can re-run the same query after the TCB task is completed.

  1. Setup
  2. SQL> connect / as sysdba
    Connected.
    SQL>
    SQL> create or replace directory TCB_DIR_EXP as
      2  '/net/tiger/apps/tcb_exp';
    Directory created.
    SQL>
    SQL> grant dba to apps;
    Grant succeeded.
    SQL>
    SQL> connect apps/apps
    Connected.
    SQL>
    SQL> create materialized view scp_mvu
      2  parallel 2
      3  as
      4  select          p.prod_name, c.cust_gender,
      5                  max(s.amount_sold) max_amount_sold
      6  from            sales s, products p, customers c
      7  where           s.prod_id = p.prod_id
      8  and             s.cust_id = c.cust_id
      9  group by        p.prod_name, c.cust_gender;
    
    Materialized view created.
    
    SQL>
    SQL> desc scp_mvu;
     Name                                      Null?    Type
     ----------------------------------------- -------- ------------
     PROD_NAME                                 NOT NULL VARCHAR2(50)
     CUST_GENDER                                        CHAR(1)
     MAX_AMOUNT_SOLD                                    NUMBER
    
    SQL>
    SQL> select * from scp_mvu where max_amount_sold > 7000 order by 3;
    
    PROD_NAME                                          C MAX_AMOUNT_SOLD
    -------------------------------------------------- - ---------------
    Joseph Sportcoat                                   F          7400.8
    Kenny Cool Leather Skirt                           M            7708
    Leather Boot-Cut Trousers                          M            8184
    
    3 rows selected.
  3. Export as user APPS
  4. SQL> connect apps/apps
    Connected.
    
    SQL>
    SQL> Rem define the problem SQL statement
    SQL> create or replace package define_vars is
      2    sql_stmt1     varchar2(2000) := q'# select * from scp_mvu
      3                                        where max_amount_sold > 7000
      4                                        order by 3
      5                                      #';
      6  end;
      7  /
    
    Package created.
    SQL> 
    SQL> set serveroutput on
    SQL>
    SQL> declare
      2    tco           clob;
      3  begin
      4    -- Export test case
      5    dbms_sqldiag.export_sql_testcase
      6    (
      7      directory           => 'TCB_DIR_EXP',
      8      sql_text            => define_vars.sql_stmt1,
      9      user_name           => 'APPS',
     10      exportData          => TRUE,
     11      testcase            => tco
     12    );
     13 
     14  end;
     15  /
    
    PL/SQL procedure successfully completed.
    SQL>
    SQL> Rem Drop MV before importing
    SQL> drop materialized view scp_mvu;
    
    Materialized view dropped.
    At this stage, the export procedure has successfully completed. The next commands prepare a directory for import purpose. The directory could be on a different machine.
    SQL> conn / as sysdba
    Connected.
    SQL> create or replace directory TCB_DIR_IMP
      2  as '/net/lion/test/tcb_imp';
    Directory created.
    SQL>
    SQL> grant dba to test;
    Grant succeeded.
    As the export has finished successfully, you can now transfer all the files under TCB_DIR_EXP to a directory in test environment, for example, TCB_DIR_IMP as created above. Again, look up and make note of the TCB metadata file xxxxxxxxmain.xml, which will be used below.

  5. Import as user TEST
  6. SQL> connect test/test
    Connected.
    SQL>
    SQL> set serveroutput on
    SQL>
    SQL> begin
      2    -- Import test case
      3    dbms_sqldiag.import_sql_testcase
      4    (
      5      directory           => 'TCB_DIR_IMP',
      6      filename            => 'oratcb3_05e803500001main.xml',
      7      importData          => TRUE
      8    );
      9 
     10  end;
     11  /
    
    PL/SQL procedure successfully completed.
    
    
  7. Verification. This is to check that now all relevant objects were imported successfully.
SQL> desc scp_mvu;
 Name                                      Null?    Type
 ----------------------------------------- -------- ------------
 PROD_NAME                                 NOT NULL VARCHAR2(50)
 CUST_GENDER                                        CHAR(1)
 MAX_AMOUNT_SOLD                                    NUMBER
SQL>
SQL> select * from scp_mvu where max_amount_sold > 7000 order by 3;

PROD_NAME                                          C MAX_AMOUNT_SOLD
-------------------------------------------------- - ---------------
Joseph Sportcoat                                   F          7400.8
Kenny Cool Leather Skirt                           M            7708
Leather Boot-Cut Trousers                          M            8184

3 rows selected.

 Finally, we also have good news for 10g users: SQL Test Case Builder has been backported to 10.2.0.4!
About

The Oracle Optimizer blog is written by members of the Optimizer development team. The goal of this blog is to provide an insight into the workings of the Optimizer and the statistics it relies on. The views expressed on this blog are our own and do not necessarily reflect the views of Oracle and its affiliates. The views and opinions expressed by visitors on this blog are theirs solely and may not reflect ours.

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today