google analytics

meta

adsense

Showing posts with label pl/sql. Show all posts
Showing posts with label pl/sql. Show all posts

Sunday, March 29, 2015

Incrementing or Manipulating non date concurrent program parameters without a wrapper for scheduling

Recently I came across a scenario where I had to schedule a concurrent program which contained couple of parameters.

One of the parameter was a date parameters and one was a character parameter which was defaulted to a string value based on SYSDATE when submitted from SRS. This was done using program definition defaults.

The program was scheduled with increment date parameters on and we observed that the non date parameter was the same for all schedules. This is because Oracle only increments date parameters and doesn't honor the defaulting logic setup at the concurrent program definitions.

This is a classic problem and everybody knows the classic solution :

Write a wrapper that implements the defaulting logic and submit the program in question. This wrapper program can be then scheduled.


Oracle provides a much less intrusive and a straight forward approach to achieve this common requirement : Concurrent Request Incrementor

An example incrementor procedure is below. Note that we completely take over the incrementing logic and it becomes our responsibility to increment the data parameters too.

PROCEDURE parameter_incrementor
IS
   l_para1         VARCHAR2 (1000);
   l_defaulted_param    VARCHAR2 (1000);
   l_date_param   VARCHAR2 (1000);
   l_param4        VARCHAR2 (1000);
BEGIN
   -- get parameter1 value
   l_para1 := FND_RESUB_PRIVATE.GET_PARAMETER (1);

   -- get paramter4 value
   l_param4 := FND_RESUB_PRIVATE.GET_PARAMETER (4);

-- contruct the string parameter that needs to be used when resubmitting
-- adn aslo increment the date parameter

      SELECT    'XXXXX_'
             || l_para1
             || 'XXXXXXXXX_'
             || TO_CHAR (SYSDATE, 'MMDDYYYY_HH24MISS'),
             TO_CHAR (TO_DATE (l_param4, 'YYYY/MM/DD HH24:MI:SS') + 1,
                      'YYYY/MM/DD HH24:MI:SS')
        INTO l_defaulted_param, l_date_param
        FROM DUAL;


   -- setting parameter values

   FND_RESUB_PRIVATE.SET_PARAMETER (2, l_defaulted_param);
   FND_RESUB_PRIVATE.SET_PARAMETER (3, l_defaulted_param);
   FND_RESUB_PRIVATE.SET_PARAMETER (4, l_date_param);
EXCEPTION
   WHEN OTHERS
   THEN
      RAISE;

END parameter_incrementor;

Now this procedure can be given as the Incrementor function in the program definition window as shown below.




Tuesday, March 6, 2012

SQL to get the Next or previous Weekend Date - NEXT_DAY

The below SQL gives the next Saturday and the next Sunday dates.


SELECT NEXT_DAY('06-MAR-2012', 'SATURDAY') "next saturday" 
,NEXT_DAY('06-MAR-2012', 'SUNDAY') "next sunday"
FROM dual;






If the requirement is to find the previous weekend dates, just subtract the dates by 7.


SELECT NEXT_DAY('06-MAR-2012', 'SATURDAY')-7 "next saturday" 
,NEXT_DAY('06-MAR-2012', 'SUNDAY')-7 "next sunday" 
FROM dual;

Monday, August 15, 2011

Oracle - Performance Tuning SQL code using DBMS_SQLTUNE


The below write up gives a step by step approach to performance tune a query using the Oracle built in Package : DBMS_SQLTUNE 

Though this wont replace a manual performance tuning effort, it can get you started in the right direction or help you spot the obvious that you had always missed.

Please note this package required special licensing requirements to be used



STEP 1: Create a Tuning Task
DECLARE
DECLARE
  my_sqltext CLOB;
  task_name VARCHAR2(30);
BEGIN
  my_sqltext := 'SELECT DISTINCT PARENT_CUST_DOC_ID FROM APPS.XX_AR_EBL_CONS_HDR_HIST WHERE EXTRACT_BATCH_ID = 234';
  task_name := DBMS_SQLTUNE.CREATE_TUNING_TASK( sql_text => my_sqltext,
                                   user_name => 'APPS',
                                   scope => 'COMPREHENSIVE',
                                   time_limit => 60,
                                   task_name => 'sql_tuning_cons_ebill4');
END;
STEP 2: Execute the Task
begin
dbms_sqltune.execute_tuning_task ( 'sql_tuning_cons_ebill4');
end;
STEP 3: Check if the task has completed
SELECT task_name, status FROM dba_advisor_log WHERE task_name= 'sql_tuning_cons_ebill4';
STEP 4: Generate Report 
select dbms_sqltune.report_tuning_task('sql_tuning_cons_ebill4') from dual;
The suggestion below is to analyze the table and then create a index on extact_batch_id which gives a 98% benefit.
GENERAL INFORMATION SECTION
-------------------------------------------------------------------------------
Tuning Task Name                  : sql_tuning_cons_ebill4
Tuning Task Owner                 : APPS
Scope                             : COMPREHENSIVE
Time Limit(seconds)               : 60
Completion Status                 : COMPLETED
Started at                        : 07/16/2010 18:37:22
Completed at                      : 07/16/2010 18:37:22
Number of Statistic Findings      : 1
Number of Index Findings          : 1
-------------------------------------------------------------------------------
Schema Name: APPS
SQL ID     : dt7baa656pgxr
SQL Text   : SELECT DISTINCT PARENT_CUST_DOC_ID FROM
             APPS.XX_AR_EBL_CONS_HDR_HIST WHERE EXTRACT_BATCH_ID = 234
-------------------------------------------------------------------------------
FINDINGS SECTION (2 findings)
-------------------------------------------------------------------------------
1- Statistics Finding
---------------------
  Table "XXFIN"."XX_AR_EBL_CONS_HDR_HIST" and its indices were not analyzed.
  Recommendation
  --------------
  - Consider collecting optimizer statistics for this table and its indices.
    execute dbms_stats.gather_table_stats(ownname => 'XXFIN', tabname =>
            'XX_AR_EBL_CONS_HDR_HIST', estimate_percent =>
            DBMS_STATS.AUTO_SAMPLE_SIZE, method_opt => 'FOR ALL COLUMNS SIZE
            AUTO', cascade => TRUE);
  Rationale
  ---------
    The optimizer requires up-to-date statistics for the table and its indices
    in order to select a good execution plan.
2- 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: 98.06%)
  ------------------------------------------
  - Consider running the Access Advisor to improve the physical schema design
    or creating the recommended index.
    create index XXFIN.IDX$$_5D6710001 on
    XXFIN.XX_AR_EBL_CONS_HDR_HIST("EXTRACT_BATCH_ID");
  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.
-------------------------------------------------------------------------------
EXPLAIN PLANS SECTION
-------------------------------------------------------------------------------
1- Original
-----------
Plan hash value: 3839049120
----------------------------------------------------------------------------------------------
| Id  | Operation          | Name                    | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |                         |     2 |    52 |   103   (1)| 00:00:02 |
|   1 |  HASH UNIQUE       |                         |     2 |    52 |   103   (1)| 00:00:02 |
|*  2 |   TABLE ACCESS FULL| XX_AR_EBL_CONS_HDR_HIST |     2 |    52 |   102   (0)| 00:00:02 |
----------------------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
 
   2 - filter("EXTRACT_BATCH_ID"=234)
2- Using New Indices
--------------------
Plan hash value: 3594741815
--------------------------------------------------------------------------------------------------------
| Id  | Operation                    | Name                    | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |                         |     1 |    26 |     2  (50)| 00:00:01 |
|   1 |  HASH UNIQUE                 |                         |     1 |    26 |     2  (50)| 00:00:01 |
|   2 |   TABLE ACCESS BY INDEX ROWID| XX_AR_EBL_CONS_HDR_HIST |     1 |    26 |     1   (0)| 00:00:01 |
|*  3 |    INDEX RANGE SCAN          | IDX$$_5D6710001         |     1 |       |     1   (0)| 00:00:01 |
--------------------------------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
 
   3 - access("EXTRACT_BATCH_ID"=234)
-------------------------------------------------------------------------------

LinkWithin

Related Posts Plugin for WordPress, Blogger...