How to improve Performance for Select statement

Hi Friends,
Can you please help me in improving the performance of the following query:
SELECT SINGLE MAX( policyterm ) startterm INTO (lv_term, lv_cal_date) FROM zu1cd_policyterm WHERE gpart = gv_part GROUP BY startterm.
Thanks and Regards,
Johny

long lists can not be produced with a SELECT SINGLE, there is also nothing to group.
But I guess the SINGLE is a bug
SELECT MAX( policyterm ) startterm
              INTO (lv_term, lv_cal_date)
              FROM zu1cd_policyterm
              WHERE gpart = gv_part
              GROUP BY startterm.
How many records are in zu1cd_policyterm ?
Is there an index starting with gpart?
If first answer is 'large' and second 'no'   =>   slow
What is the meaning of gpart? How many different values can it assume?
If many different values then an index makes sense, if you are allowed to create
an index.
Otherwise you must be patient.
Siegfried

Similar Messages

How to improve performance of insert statement

Hi all,
How to improve performance of insert statement
I am inserting 1lac records into table it takes around 20 min..
Plz help.
Thanx In Advance.

I tried :
SQL> create table test as select * from dba_objects;
Table created.
SQL> delete from test;
3635 rows deleted.
SQL> commit;
Commit complete.
SQL> select count(*) from dba_extents where segment_name='TEST';
COUNT(*)
4
SQL> insert /*+ APPEND */ into test select * from dba_objects;
3635 rows created.
SQL> commit;
Commit complete.
SQL> select count(*) from dba_extents where segment_name='TEST';
COUNT(*)
6
Cheers, Bhupinder

Need to Improve pefromance for select statement using MSEG table

Hi all,
We are using a select statement using MSEG table
which takes a very long time to run the program which is scheduled in back ground.
Please see the history below.;
1) Previously this program was using SELECT-ENDSELECT statement inside the loop i.e.
LOOP AT I_MCHB.
To get Material Doc. Details
      SELECT MBLNR
             MJAHR
             ZEILE INTO (MSEG-MBLNR,MSEG-MJAHR,MSEG-ZEILE)
             UP TO 1 ROWS
             FROM MSEG
            WHERE CHARG EQ I_MCHB-CHARG
             AND MATNR EQ I_MCHB-MATNR
             AND WERKS EQ I_MCHB-WERKS
             AND LGORT EQ I_MCHB-LGORT.
      ENDSELECT.
Endloop.
The program was taking 1 hr for 20 k data
2)The above statement was replaced by ALL ENTRIES to remove the SELECT-ENDSELECT from the loop.
***GET MATERIAL DOC NUMBER AND FINANCIAL YEAR DETAILS FROM MSEG TABLE
    SELECT MBLNR
           MJAHR
           ZEILE
           MATNR
           CHARG
           WERKS
           LGORT
               INTO TABLE I_MSEG
               FROM   MSEG
               FOR ALL ENTRIES IN I_MCHB
               WHERE CHARG EQ I_MCHB-CHARG
               AND   MATNR EQ I_MCHB-MATNR
               AND   WERKS EQ I_MCHB-WERKS
               AND   LGORT EQ I_MCHB-LGORT.
3)After getting the further technical analysis from BASIS team , And with the suggestion to optimize the program by changing the INDEX RANGE SCAN to
       MSEG~M.
SELECT MBLNR
           MJAHR
           ZEILE
           MATNR
           CHARG
           WERKS
           LGORT
               INTO TABLE I_MSEG
               FROM   MSEG
               FOR ALL ENTRIES IN I_MCHB
               WHERE MATNR EQ I_MCHB-MATNR
               AND   WERKS EQ I_MCHB-WERKS
               AND   LGORT EQ I_MCHB-LGORT.
At present the program is taking 3 to 4 hrs in back ground .
The table is complete table scan using index
MSEG~M.
Please suggest to improve the performance of this
many many thanks
deepak

The benchmark should be the join, and I can not see how any of your solutions can be faster than the join
SELECT   .....
              INTO TABLE ....
              UP TO 1 ROWS
              FROM mchb as a
              INNER JOIN mseg as b
              ON    amatnr EQ bmatnr
              AND awerks EQ bwerks
              AND algort    EQ blgort
              And   acharg EQ bcharg
              WHERE a~ ....
The WHERE condition must come from the select on MCHB, the field list from the total results
you want.
If you want to compare, must compare your solutions plus the select to fill I_MCHB.
Siegfried
Edited by: Siegfried Boes on Dec 20, 2007 2:28 PM

How to improve Performance of the Statements.

Hi,
I am using Oracle 10g. My problem is when i am Execute & fetch the records from the database it is taking so much time. I have created Statistics also but no use. Now what i have to do to improve the Performance of the SELECT, INSERT, UPDATE, DELETE Statements.
Is it make any differents because i am using WindowsXP, 1 GB RAM in Server Machine, and WindowsXP, 512 GB RAM in Client Machine.
Pls. Give me advice for me to improve Performance.
Thank u...!

What and where to change parameters and values ?Well, maybe my previous post was not clear enough, but if you want to keep your job, you shouldn't change anything else on init parameter and you shouldn't fall in the Compulsive Tuning Disorder.
Everyone who advise you to change some parameters to some value without any more info shouldn't be listen.
Nicolas.

How to improve performance of select query when primary key is not referred

Hi,
There is a select query where we are unable to refrence primary key of the tables:
Since, the the below code is refrensing to vgbel and vgpos fields instead of vbeln and posnr..... the performance is very slow.
select vbeln posnr into (wa-vbeln1, wa-posnr1)
       from lips
       where ( pstyv ne 'ZBAT'
           and pstyv ne 'ZNLN' )
           and vgbel = i_vbap-vbeln
           and vgpos = i_vbap-posnr.
endselect.
Please le t me know if you have some tips..

hi,
I hope you are using the select statement inside a loop ...endloop get that outside to improve the performance ..
if not i_vbap[] is initial.
select vbeln posnr into table it_lips
from lips
for all entries in i_vbap
where ( pstyv ne 'ZBAT'
and pstyv ne 'ZNLN' )
and vgbel = i_vbap-vbeln
and vgpos = i_vbap-posnr.
endif.

How to improve performance for Custom Extractor in BI..

HI all,
I am new to BI and started working on BI for couple of weeks.. I created a Custom Extractor(Data View) in the Source system and when i pull data takes lot of time.. Can any one respond to this, suggesting how to improve the performance of my custom Extractor.. Please do the needfull..
Thanks and Regards,
Venugopal..

Dear Venugopal,
use transaction ST05 to check if your SQL statements are optimal and that you do not have redundant database calls. You should use as much as possible "bulking", which means to fetch the required data with one request to database and not with multiple requests to database.
Use transaction SE30 to check if you are wasting time in loops and if yes, optimize the algorithm.
Best Regards,
Sylvia

How to improve performance for bulk data load in Dynamics CRM 2013 Online

Hi all,
We need to bulk update (or create) contacts into Dynamics CRM 2013 online every night due to data updated from another external data source. The data size is around 100,000 and the data loading duration was around 6 hours.
We are already using ExecuteMultiple web services to handle the integration, however, the 6 hours integraton duration is still not acceptable and we are seeking for any advise for further improvement.
Any help is highly appreciated. Many thanks.
Gary

I think Andrii's referring to running multiple threads in parallel (see
http://www.mscrmuk.blogspot.co.uk/2012/02/data-migration-performance-to-crm.html - it's a bit dated, but should still be relevant).
Microsoft do have some throttling limits applied in Crm Online, and it is worth contacting them to see if you can get those raised.
100 000 records per night seems a large number. Are all these records new or updated records, or are there some that are unchanged, in which case you could filter them out before uploading ? Or are there useful ways to summarise the data before loading
Microsoft CRM MVP - http://mscrmuk.blogspot.com/ http://www.excitation.co.uk

How to improve performance for this code

Hi,
LOOP AT lt_element INTO ls_element.
READ TABLE lt_element_ident INTO ls_element_ident
WITH KEY element_id = ls_element-element_id BINARY SEARCH.
IF sy-subrc EQ 0.
MOVE ls_element_ident-value TO lv_guid.
SELECT * FROM zcm_valuation_at
APPENDING CORRESPONDING FIELDS OF TABLE lt_caseattributes
WHERE case_guid = lv_guid.
ENDIF.
ENDLOOP.
LOOP AT lt_caseattributes INTO ls_caseattributes.
IF ls_caseattributes-ext_key IS INITIAL.
SELECT SINGLE ext_key
INTO CORRESPONDING FIELDS OF ls_caseattributes
FROM scmg_t_case_attr
WHERE case_guid = ls_caseattributes-case_guid.
ENDIF.
*To get the Status description of the Case
SELECT SINGLE stat_ordno_descr
INTO ls_caseattributes-status
FROM scmgstatprofst AS a
INNER JOIN scmg_t_case_attr AS b
ON aprofile_id = bprofile_id
AND astat_orderno = bstat_orderno
WHERE case_guid = ls_caseattributes-case_guid.
MODIFY lt_caseattributes FROM ls_caseattributes INDEX sy-tabix TRANSPORTING status ext_key.
ENDLOOP.
READ TABLE lt_caseattributes INTO ls_caseattributes INDEX 1.
Regards,
Maruti

Hi,
try this kind of code:
==================================
start new
DATA:
lt_scmgstatprofst LIKE scmgstatprofst OCCURS 0 WITH HEADER LINE,
wa_scmg_t_case_attr LIKE scmg_t_case_attr.
SELECT * FROM scmgstatprofst INTO TABLE lt_scmgstatprofst.
SORT lt_scmgstatprofst BY profile_id stat_orderno.
end new
LOOP AT lt_element INTO ls_element.
READ TABLE lt_element_ident INTO ls_element_ident
WITH KEY element_id = ls_element-element_id BINARY SEARCH.
IF sy-subrc EQ 0.
    MOVE ls_element_ident-value TO lv_guid.
    SELECT * FROM zcm_valuation_at
    APPENDING CORRESPONDING FIELDS OF TABLE lt_caseattributes
    WHERE case_guid = lv_guid.
ENDIF.
ENDLOOP.
LOOP AT lt_caseattributes INTO ls_caseattributes.
IF ls_caseattributes-ext_key IS INITIAL.
    SELECT SINGLE ext_key
    INTO CORRESPONDING FIELDS OF ls_caseattributes
    FROM scmg_t_case_attr
    WHERE case_guid = ls_caseattributes-case_guid.
ENDIF.
*To get the Status description of the Case
start deletion
SELECT SINGLE stat_ordno_descr
INTO ls_caseattributes-status
FROM scmgstatprofst AS a
INNER JOIN scmg_t_case_attr AS b
ON aprofile_id = bprofile_id
AND astat_orderno = bstat_orderno
WHERE case_guid = ls_caseattributes-case_guid.
end deletion
start new
CLEAR wa_scmg_t_case_attr.
SELECT SINGLE * FROM scmg_t_case_attr INTO wa_scmg_t_case_attr
    WHERE case_guid = ls_caseattributes-case_guid.
READ TABLE lt_scmgstatprofst WITH KEY
    profile_id   = wa_scmg_t_case_attr-profile_id
    stat_orderno = wa_scmg_t_case_attr-stat_orderno
    BINARY SEARCH.
IF sy-subrc IS INITIAL.
    ls_caseattributes-status = lt_scmgstatprofst-stat_ordno_descr.
ENDIF.
end new
MODIFY lt_caseattributes FROM ls_caseattributes INDEX sy-tabix
TRANSPORTING status ext_key.
ENDLOOP.
READ TABLE lt_caseattributes INTO ls_caseattributes INDEX 1.
==================================
Regards
Walter Habich
Edited by: Walter Habich on Jun 17, 2008 8:41 AM

How to improve performance for Azure Table Storage bulk loads

Hello all,
Would appreciate your help as we are facing a challenge.
We are tried to bulk load Azure table storage. We have a file that contains nearly 2 million rows.
We would need to reach a point where we could bulk load 100000-150000 entries per minute. Currently, it takes more than 10 hours to process the file..
We have tried Parallel.Foreach but it doesn't help. Today I discovered Partitioning in PLINQ. Would that be the way to go??
Any ideas? I have spent nearly two days in trying to optimize it using PLINQ, but still I am not sure what is the best thing to do.
Kindly, note that we shouldn't be using SQL/Azure SQL for this.
I would really appreciate your help.
Thanks

I'd think you're just pooling the parallel connections to Azure, if you do it on one system. You'd also have a bottleneck of round trip time from you, through the internet to Azure and back again.
You could speed it up by moving the data file to the cloud and process it with a Cloud worker role. That way you'd be in the datacenter (which is a much faster, more optimized network.)
Or, if that's not fast enough - if you can split the data so multiple WorkerRoles could each process part of the file, you can use the VM's scale to put enough machines to it that it gets done quickly.
Darin R.

How to improve performance of the attached query

Hi,
How to improve performance of the below query, Please help. also attached explain plan -
SELECT Camp.Id,
rCam.AccountKey,
Camp.Id,
CamBilling.Cpm,
CamBilling.Cpc,
CamBilling.FlatRate,
Camp.CampaignKey,
Camp.AccountKey,
CamBilling.billoncontractedamount,
(SUM(rCam.Impressions) * 0.001 + SUM(rCam.Clickthrus)) AS GR,
rCam.AccountKey as AccountKey
FROM Campaign Camp, rCamSit rCam, CamBilling, Site xSite
WHERE Camp.AccountKey = rCam.AccountKey
AND Camp.AvCampaignKey = rCam.AvCampaignKey
AND Camp.AccountKey = CamBilling.AccountKey
AND Camp.CampaignKey = CamBilling.CampaignKey
AND rCam.AccountKey = xSite.AccountKey
AND rCam.AvSiteKey = xSite.AvSiteKey
AND rCam.RmWhen BETWEEN to_date('01-01-2009', 'DD-MM-YYYY') and
to_date('01-01-2011', 'DD-MM-YYYY')
GROUP By rCam.AccountKey,
Camp.Id,
CamBilling.Cpm,
CamBilling.Cpc,
CamBilling.FlatRate,
Camp.CampaignKey,
Camp.AccountKey,
CamBilling.billoncontractedamount
Explain Plan :-
Description Object_owner Object_name Cost Cardinality Bytes
SELECT STATEMENT, GOAL = ALL_ROWS 14 1 13
SORT AGGREGATE 1 13
VIEW GEMINI_REPORTING 14 1 13
HASH GROUP BY 14 1 103
NESTED LOOPS 13 1 103
HASH JOIN 12 1 85
TABLE ACCESS BY INDEX ROWID GEMINI_REPORTING RCAMSIT 2 4 100
NESTED LOOPS 9 5 325
HASH JOIN 7 1 40
SORT UNIQUE 2 1 18
TABLE ACCESS BY INDEX ROWID GEMINI_PRIMARY SITE 2 1 18
INDEX RANGE SCAN GEMINI_PRIMARY SITE_I0 1 1
TABLE ACCESS FULL GEMINI_PRIMARY SITE 3 27 594
INDEX RANGE SCAN GEMINI_REPORTING RCAMSIT_I 1 1 5
TABLE ACCESS FULL GEMINI_PRIMARY CAMPAIGN 3 127 2540
TABLE ACCESS BY INDEX ROWID GEMINI_PRIMARY CAMBILLING 1 1 18
INDEX UNIQUE SCAN GEMINI_PRIMARY CAMBILLING_U1 0 1

duplicate thread..
How to improve performance of attached query

How to improve performance of attached query

Hi,
How to improve performance of the below query, Please help. also attached explain plan -
SELECT Camp.Id,
rCam.AccountKey,
Camp.Id,
CamBilling.Cpm,
CamBilling.Cpc,
CamBilling.FlatRate,
Camp.CampaignKey,
Camp.AccountKey,
CamBilling.billoncontractedamount,
(SUM(rCam.Impressions) * 0.001 + SUM(rCam.Clickthrus)) AS GR,
rCam.AccountKey as AccountKey
FROM Campaign Camp, rCamSit rCam, CamBilling, Site xSite
WHERE Camp.AccountKey = rCam.AccountKey
AND Camp.AvCampaignKey = rCam.AvCampaignKey
AND Camp.AccountKey = CamBilling.AccountKey
AND Camp.CampaignKey = CamBilling.CampaignKey
AND rCam.AccountKey = xSite.AccountKey
AND rCam.AvSiteKey = xSite.AvSiteKey
AND rCam.RmWhen BETWEEN to_date('01-01-2009', 'DD-MM-YYYY') and
to_date('01-01-2011', 'DD-MM-YYYY')
GROUP By rCam.AccountKey,
Camp.Id,
CamBilling.Cpm,
CamBilling.Cpc,
CamBilling.FlatRate,
Camp.CampaignKey,
Camp.AccountKey,
CamBilling.billoncontractedamount
Explain Plan :-
Description Object_owner Object_name Cost Cardinality Bytes
SELECT STATEMENT, GOAL = ALL_ROWS 14 1 13
SORT AGGREGATE 1 13
VIEW GEMINI_REPORTING 14 1 13
HASH GROUP BY 14 1 103
NESTED LOOPS 13 1 103
HASH JOIN 12 1 85
TABLE ACCESS BY INDEX ROWID GEMINI_REPORTING RCAMSIT 2 4 100
NESTED LOOPS 9 5 325
HASH JOIN 7 1 40
SORT UNIQUE 2 1 18
TABLE ACCESS BY INDEX ROWID GEMINI_PRIMARY SITE 2 1 18
INDEX RANGE SCAN GEMINI_PRIMARY SITE_I0 1 1
TABLE ACCESS FULL GEMINI_PRIMARY SITE 3 27 594
INDEX RANGE SCAN GEMINI_REPORTING RCAMSIT_I 1 1 5
TABLE ACCESS FULL GEMINI_PRIMARY CAMPAIGN 3 127 2540
TABLE ACCESS BY INDEX ROWID GEMINI_PRIMARY CAMBILLING 1 1 18
INDEX UNIQUE SCAN GEMINI_PRIMARY CAMBILLING_U1 0 1

duplicate thread..
How to improve performance of attached query

How to utilize index in selection statement

hi
how to utilize index in selection statement and how is it reduces performance whether another alternative is there to reduce performance .
thanks

Hi Suresh,
For each SQL statement, the database optimizer determines the strategy for accessing data records. Access can be with database indexes (index access), or without database indexes (full table scan).The cost-based database optimizer determines the access strategy on the basis of:
*Conditions in the WHERE clause of the SQL statement
*Database indexes of the table(s) affected
*Selectivity of the table fields contained in the database indexes
*Size of the table(s) affected
*The table and index statistics supply information about the selectivity of table fields, the selectivity of combinations of table fields, and table size. Before a database access is performed, the database optimizer cannot calculate the exact cost of a database access. It uses the information described above to estimate the cost of the database access.The optimization calculation is the amount by which the data blocks to be read (logical read accesses) can be reduced. Data blocks show the level of detail in which data is written to the hard disk or read from the hard disk.
Inroduction to Database Indexes
When you create a database table in the ABAP Dictionary, you must specify the combination of fields that enable an entry within the table to be clearly identified. Position these fields at the top of the table field list, and define them as key fields.
After activating the table, an index is created (for Oracle, Informix, DB2) that consists of all key fields. This index is called a primary index. The primary index is unique by definition. As well as the primary index, you can define one or more secondary indexes for a table in the ABAP Dictionary, and create them on the database. Secondary indexes can be unique or non-unique. Index records and table records are organized in data blocks.
If you dispatch an SQL statement from an ABAP program to the database, the program searches for the data records requested either in the database table itself (full table scan) or by using an index (index unique scan or index range scan). If all fields requested are found in the index using an index scan, the table records do not need to be accessed.
A data block shows the level of detail in which data is written to the hard disk or read from the hard disk. Data blocks may contain multiple data records, but a single data record may be spread across several data blocks.
Data blocks can be index blocks or table blocks. The database organizes the index blocks in the form of a multi-level B* tree. There is a single index block at root level, which contains pointers to the index blocks at branch level. The branch blocks contain either some of the index fields and pointers to index blocks at leaf level, or all index fields and a pointer to the table records organized in table blocks. The index blocks at leaf level contain all index fields and pointers to the table records from the table blocks.
The pointer that identifies one or more table records has a specific name. It is called, for example, ROWID for Oracle databases. The ROWID consists of the number of the database file, the number of the table block, and the row number within the table block.
The index records are stored in the index tree and sorted according to index field. This enables accelerated access using the index. The table records in the table blocks are not sorted.
An index should not consist of too many fields. Having a few very selective fields increases the chance of reusability, and reduces the chance of the database optimizer selecting an unsuitable access path.
Index Unique Scan
If, for all fields in a unique index (primary index or unique secondary index), WHERE conditions are specified with '=' in the WHERE clause, the database optimizer selects the access strategy index unique scan.
For the index unique scan access strategy, the database usually needs to read a maximum of four data blocks (three index blocks and one table block) to access the table record.
select * from VVBAK here vbeln = '00123' ......end select.
In the SELECT statement shown above, the table VVBAK is accessed. The fields MANDT and VBELN form the primary key, and are specified with '=' in the WHERE clause. The database optimizer therefore selects the index unique scan access strategy, and only needs to read four data blocks to find the table record requested.
Index Range Scan
select * from VVBAP here vbeln = '00123' ......end select.
In the example above, not all fields in the primary index of the table VVBAP (key fields MANDT, VBELN, POSNR) are specified with '=' in the WHERE clause. The database optimizer checks a range of index records and deduces the table records from these index records. This access strategy is called an index range scan.
To execute the SQL statement, the DBMS first reads a root block (1) and a branch block (2). The branch block contains pointers to two leaf blocks (3 and 4). In order to find the index records that fulfill the criteria in the WHERE clause of the SQL statement, the DBMS searches through these leaf blocks sequentially. The index records found point to the table records within the table blocks (5 and 6).
If index records from different index blocks point to the same table block, this table block must be read more than once. In the example above, an index record from index block 3 and an index record from index block 4 point to table records in table block 5. This table block must therefore be read twice. In total, seven data blocks (four index blocks and three table blocks) are read.
The index search string is determined by the concatenation of the WHERE conditions for the fields contained in the index. To ensure that as few index blocks as possible are checked, the index search string should be specified starting from the left, without placeholders ('_' or %). Because the index is stored and sorted according to the index fields, a connected range of index records can be checked, and fewer index blocks need to be read.
All index blocks and table blocks read during an index range scan are stored in the data buffer at the top of a LRU (least recently used) list. This can lead to many other data blocks being forced out of the data buffer. Consequently, more physical read accesses become necessary when other SQL statements are executed
DB Indexex :Concatenation
In the concatenation access strategy, one index is reused. Therefore, various index search strings also exist. An index unique scan or an index range scan can be performed for the various index search strings. Duplicate entries in the results set are filtered out when the search results are concatenated.
Select * from vvbap where vbeln in ('00123', '00133', '00134').
endselect.
In the SQL statement above, a WHERE condition with an IN operation is specified over field VBELN. The fields MANDT and VBELN are shown on the left of the primary index. Various index search strings are created, and an index range scan is performed over the primary index for each index search string. Finally, the result is concatenated.
Full Table Scan
select * from vvbap where matnr = '00015'.
endselect
If the database optimizer selects the full table scan access strategy, the table is read sequentially. Index blocks do not need to be read.
For a full table scan, the read table blocks are added to the end of an LRU list. Therefore, no data blocks are forced out of the data buffer. As a result, in order to process a full table scan, comparatively little memory space is required within the data buffer.
The full table scan access strategy is very effective if a large part of a table (for example, 5% of all table records) needs to be read. In the example above, a full table scan is more efficient than access using the primary index.
In Brief
Index unique scan: The index selected is unique (primary index or unique secondary index) and fully specified. One or no table record is returned. This type of access is very effective, because a maximum of four data blocks needs to be read.
Index range scan: The index selected is unique or non-unique. For a non-unique index, this means that not all index fields are specified in the WHERE clause. A range of the index is read and checked. An index range scan may not be as effective as a full table scan. The table records returned can range from none to all.
Full table scan: The whole table is read sequentially. Each table block is read once. Since no index is used, no index blocks are read. The table records returned can range from none to all.
Concatenation: An index is used more than once. Various areas of the index are read and checked. To ensure that the application receives each table record only once, the search results are concatenated to eliminate duplicate entries. The table records returned can range from none to all.
Regards,
Balaji Reddy G
***Rewards if answers are helpful

Timesten create a lock for select statement through sqldev

When use ttisql connect to TimesTen Release 7.0.6.15.0 at autocommit=1, there is no lock for select statement.
but when I use sql developer (driver is ttjdbc5.jar, regardless of version) to connect, even with autocommit=1, there will be locks for select statement.
Is it a bug? How can I achieve the same no locks for select statement through sql developer?Thanks.

-your update tells me that you are connected to a remote timesten data store using the client driver
-the ttXactAdmin output indicates that SqlNavigator has a shared lock on the database itself: this will not interfere with anybody else' read operations, and I believe that until such time as you actually attempt some kind of DML against the data store that th IX lock on the database lock will not interfere with any other DML either.
-a shared database lock will always be acquired for any transaction in TimesTen. You can test this for yourself from ttisql: set autocommit off, perform a simple update and do not commit the transaction. Then open a separate session and execute ttxactadmin - you will the IX database lock as well as the various locks on tables and indexes.
-I believe this pretty much proves my original thinking: that sqlDeveloper attaches to TimesTen in transaction mode. However, the IX lock on the database will not interfere with anybody else's work and should not be a problem.

Performance issue - Select statement

Hi I am having the 10 lack records in the KONP table . If i am trying to see all the records in SE11 , it is giving the short dump TSV_TNEW_PAGE_ALLOC_FAILED . I know this is because of less memory in the Server . Is there any other way to get the data ? How to optimise the below SELECT statement if i have large data in the table .
i_condn_data - is having 8 lack records .
SELECT knumh kznep valtg valdt zterm
        FROM konp
        INTO TABLE i_condn_data_b
        FOR ALL ENTRIES IN i_condn_data
        WHERE knumh = i_condn_data-knumh
        AND kschl = p_kschl.
Please suggest .

Hi,
try to use "UP TO n ROWS" to control the quantity of selected data in each Loop step.
Something like this:
sort itab by itab-knumh.
flag = 'X'.
while flag = 'X'.
SELECT knumh kznep valtg valdt zterm
FROM konp
INTO TABLE i_condn_data_b UP TO one_million ROWS
WHERE knumh > new_value_for_selection
AND kschl = p_kschl.
describe table i_condn_data_b lines i.
read table i_condn_data_b index i.
new_value_for_selection = i_condn_data_b-knumh.
*....your logic for table i_condn_data_b
if one_million > i.
clear flag.
endif.
endwhile.
Regards

How to improve performace for this program

Hi,
I want to improve performance for this program.Pls help me.Here is the code.
Thanks
kumar
--# SCCS: @(#)nscdprpt_rpt_fam_fweq_detail_aggr_dml.sql 2.1 08/17/05 12:16:11
--# Location: /appl/dpdm/src/sql/SCCS/s.nscdprpt_rpt_fam_fweq_detail_aggr_dml.sql
-- =============================================================================
-- Purpose:
-- DML Script to calculate aggregate rows from table NSCDPRPT.RPT_FAM_FWEQ_DETAIL
-- inserts one (1) monthly total row for each comparison type (6 of them)
-- Modification History
-- Date Version Who What
-- 28-Jun-05 V1.00 J. Myers Initial Version
-- 17-Aug-05 gzuerc Replaced UNION ALL code with INSERT's to avoid
-- Oracle error out of undo tablespace.
-- ============================================================================
-- NOTES:
-- This process pulls data from RPT_FAM_FWEQ_DETAIL table.
-- The target table RPT_FAM_FWEQ_DETAIL_AGGR is truncated by plan_ctry and loaded daily;
-- it is the data used in the Forecast Accuracy Measurements Report.
-- The input data is 'wide' (6 quantities), and this script outputs a single
-- row for each quantity as a 'thin' table (single column F1_QTY and F2_QTY shared by all quantities), and
-- with a ROW_TYPE = 'TOTAL'
-- Two (2) other scripts add additional rows to this table as follows:
-- 1) nscdprpt_rpt_fam_FWEQ_detail_aggr_sesn_avg_dml.sql => calculates the
-- total quantities F1_QTY, F2_QTY and AE for each LEVEL_VALUE
-- 2) nscdprpt_rpt_fam_FWEQ_detail_aggr_pct_swg_dml.sql => calculates the
-- percent swing in quantities between DISP_EVENTS for each grouping
-- of PLAN_CTRY, DIVISION, SEASON and TRG_EVENT_NUM for only LEVEL_TYPE = 'SUB_CAT'
-- =============================================================================
-- The result set from joining RPT_FAM_FWEQ_DETAIL rows with comparison types
-- is inserted into the table RPT_FAM_FWEQ_DETAIL_AGGR
INSERT INTO rpt_fam_FWEQ_detail_aggr
SELECT plan_ctry,
division,
season,
monthly_seq,
 bucket_month_date,
tier_num,
level_num,
tier_volume,
trg_event_num,
disp_event_num,
max_event_num,
compare_name,
first_display_event_num,
level_type,
level_value,
'TOTAL' AS row_type,
material,
key_material,
sap_cat_cd,
sap_cat_desc,
sap_sub_cat_cd,
sap_sub_cat_desc,
sty_colr_sdesc,
sty_grp_nbr,
sty_grp_desc,
matl_typ,
sap_prod_typ_grp, -- 'Type Group' in Brio
typ_grp_desc, -- 'Type Group' in Brio
curr_prod_i2_life_cyc_cd,
NULL AS promo_ind, -- for future use
-- Each RPT_FAM_FWEQ_DETAIL row's eight (8) quantity columns are broken down
-- into F1_QTY from DISP_aaaa_QTY, F2_QTY from TRG_aaaa_QTY and
 -- AE from aaaa_AE where 'aaaa' is equal to one of the COMPARE_TYPEs below:
-- F1_QTY
CASE WHEN compare_type = 'DELIVERY_PLAN' THEN
disp_dlvry_plan_qty
WHEN compare_type = 'NET' THEN
disp_net_qty
WHEN compare_type = 'NET_AO' THEN
disp_ao_qty
WHEN compare_type = 'NET_FTRS' THEN
disp_futr_qty
WHEN compare_type = 'NET_REPLENS' THEN
disp_replen_qty
WHEN compare_type = 'AUTH_FTRS' THEN
disp_auth_futr_qty
END as f1_qty,
-- F2_QTY
CASE WHEN compare_type = 'DELIVERY_PLAN' THEN
trg_dlvry_plan_qty
WHEN compare_type = 'NET' THEN
trg_net_qty
WHEN compare_type = 'NET_AO' THEN
trg_ao_qty
WHEN compare_type = 'NET_FTRS' THEN
trg_futr_qty
WHEN compare_type = 'NET_REPLENS' THEN
trg_replen_qty
WHEN compare_type = 'AUTH_FTRS' THEN
trg_auth_futures_qty
END as f2_qty,
-- AE
CASE WHEN compare_type = 'DELIVERY_PLAN' THEN
abs(disp_dlvry_plan_qty - trg_dlvry_plan_qty)
WHEN compare_type = 'NET' THEN
abs(disp_net_qty - trg_net_qty)
WHEN compare_type = 'NET_AO' THEN
abs(disp_ao_qty - trg_ao_qty)
WHEN compare_type = 'NET_FTRS' THEN
abs(disp_futr_qty - trg_futr_qty)
WHEN compare_type = 'NET_REPLENS' THEN
abs(disp_replen_qty - trg_replen_qty)
WHEN compare_type = 'AUTH_FTRS' THEN
abs(disp_auth_futr_qty - trg_auth_futures_qty)
END as ae,
SYSDATE AS zz_insert_tmst
FROM
-- The following in-line view provides three (3) result sets from the RPT_FAM_FWEQ_DETAIL table
 -- This in-line view returns only LEVEL_NUM = 1 or LEVEL_TYPE = 'SUB_CAT' data
 SELECT plan_ctry,
 division,
 season,
 monthly_seq,
 bucket_month_date,
 tier_num,
 level_num,
 tier_volume,
 trg_event_num,
 trg_event_type,
 disp_event_num,
 max_event_num,
 first_display_event_num,
 level_type,
 level_value,
 -- The following NULL'd columns' values cannot be saved due to aggregation
 NULL AS material,
 NULL AS key_material,
 sap_cat_cd,
 sap_cat_desc,
 sap_sub_cat_cd,
 sap_sub_cat_desc,
 NULL AS sty_colr_sdesc,
 NULL AS sty_grp_nbr,
 NULL AS sty_grp_desc,
 NULL AS matl_typ,
 sap_prod_typ_grp, -- 'Type Group' in Brio
 typ_grp_desc, -- 'Type Group' in Brio
 NULL AS curr_prod_i2_life_cyc_cd,
 sum(disp_net_qty) AS disp_net_qty,
 sum(trg_net_qty) AS trg_net_qty,
 -- ABS(sum(trg_net_qty) - sum(disp_net_qty)) AS net_AE,
 sum(disp_dlvry_plan_qty) AS disp_dlvry_plan_qty,
 sum(trg_dlvry_plan_qty) AS trg_dlvry_plan_qty,
 -- ABS(sum(trg_dlvry_plan_qty) - sum(disp_dlvry_plan_qty)) AS dlvry_plan_AE,
 sum(disp_futr_qty) AS disp_futr_qty,
 sum(trg_futr_qty) AS trg_futr_qty,
 -- ABS(sum(trg_futr_qty) - sum(disp_futr_qty)) AS futr_AE,
 sum(disp_ao_qty) AS disp_ao_qty,
 sum(trg_ao_qty) AS trg_ao_qty,
 -- ABS(sum(trg_ao_qty) - sum(disp_ao_qty)) AS ao_AE,
 sum(disp_replen_qty) AS disp_replen_qty,
 sum(trg_replen_qty) AS trg_replen_qty,
 -- ABS(sum(trg_replen_qty) - sum(disp_replen_qty)) AS replen_AE,
 sum(disp_futr_qty) AS disp_auth_futr_qty,
 sum(trg_auth_futures_qty) AS trg_auth_futures_qty --,
 -- ABS(sum(trg_auth_futures_qty) - sum(disp_futr_qty)) AS auth_futures_AE
 FROM rpt_fam_FWEQ_detail
 WHERE plan_ctry &where_plan_ctry
 and level_num = 1 -- 'SUB-CAT'
 -- AND (promo_ind <> 'Y' OR promo_ind IS null)
 GROUP BY plan_ctry,
 division,
 season,
 monthly_seq,
 bucket_month_date,
 tier_num,
 level_num,
 tier_volume,
 trg_event_num,
 trg_event_type,
 disp_event_num,
 max_event_num,
 first_display_event_num,
 level_type,
 level_value,
 sap_cat_cd,
 sap_cat_desc,
 sap_sub_cat_cd,
 sap_sub_cat_desc,
 sap_prod_typ_grp, -- 'Type Group' in Brio
 typ_grp_desc -- 'Type Group' in Brio
 ) dtl,
 -- The following in-line view returns all of the different combinations
 -- of comparison types in the RPT_FAM_FWEQ_DETAIL table
 -- This select returns the pairing of all forecast types
 SELECT event_type, compare_type, compare_name
 from
 (SELECT event_type, compare_type, compare_type_description || ' to ' || compare_type_description AS compare_name
 FROM rpt_fam_compare_types
 WHERE event_type = 'FCST'
 UNION
 -- This select returns the pairing of all bookings types with forecast types
 SELECT bkng.event_type, fcst.compare_type, bkng.compare_type_description || ' to ' || fcst.compare_type_description AS compare_name
 FROM rpt_fam_compare_types fcst,
 rpt_fam_compare_types bkng
 WHERE fcst.event_type = 'FCST'
 AND bkng.event_type = 'BKNG'
 AND fcst.compare_type = bkng.compare_type
 WHERE event_type || ' ' || compare_type <> 'FCST AUTH_FTRS'
 AND compare_type NOT IN ('NET_SHIP', 'SHIP_NET_FTRS', 'NET_ETS', 'GROSS_FTRS')
 ) cmpr
-- The two (2) in-line views are joined by EVENT_TYPE (i.e. 'FCST' and 'BKNG')
-- to form a product of all RPT_FAM_FWEQ_DETAIL rows with comparison types
WHERE dtl.trg_event_type = cmpr.event_type
ORDER BY plan_ctry,
division,
season,
monthly_seq,
tier_num,
level_num,
tier_volume,
trg_event_num,
disp_event_num,
max_event_num,
first_display_event_num,
level_type,
level_value
COMMIT
INSERT INTO rpt_fam_FWEQ_detail_aggr
SELECT plan_ctry,
division,
season,
monthly_seq,
 bucket_month_date,
tier_num,
level_num,
tier_volume,
trg_event_num,
disp_event_num,
max_event_num,
compare_name,
first_display_event_num,
level_type,
level_value,
'TOTAL' AS row_type,
material,
key_material,
sap_cat_cd,
sap_cat_desc,
sap_sub_cat_cd,
sap_sub_cat_desc,
sty_colr_sdesc,
sty_grp_nbr,
sty_grp_desc,
matl_typ,
sap_prod_typ_grp, -- 'Type Group' in Brio
typ_grp_desc, -- 'Type Group' in Brio
curr_prod_i2_life_cyc_cd,
NULL AS promo_ind, -- for future use
-- Each RPT_FAM_FWEQ_DETAIL row's eight (8) quantity columns are broken down
-- into F1_QTY from DISP_aaaa_QTY, F2_QTY from TRG_aaaa_QTY and
 -- AE from aaaa_AE where 'aaaa' is equal to one of the COMPARE_TYPEs below:
-- F1_QTY
CASE WHEN compare_type = 'DELIVERY_PLAN' THEN
disp_dlvry_plan_qty
WHEN compare_type = 'NET' THEN
disp_net_qty
WHEN compare_type = 'NET_AO' THEN
disp_ao_qty
WHEN compare_type = 'NET_FTRS' THEN
disp_futr_qty
WHEN compare_type = 'NET_REPLENS' THEN
disp_replen_qty
WHEN compare_type = 'AUTH_FTRS' THEN
disp_auth_futr_qty
END as f1_qty,
-- F2_QTY
CASE WHEN compare_type = 'DELIVERY_PLAN' THEN
trg_dlvry_plan_qty
WHEN compare_type = 'NET' THEN
trg_net_qty
WHEN compare_type = 'NET_AO' THEN
trg_ao_qty
WHEN compare_type = 'NET_FTRS' THEN
trg_futr_qty
WHEN compare_type = 'NET_REPLENS' THEN
trg_replen_qty
WHEN compare_type = 'AUTH_FTRS' THEN
trg_auth_futures_qty
END as f2_qty,
-- AE
CASE WHEN compare_type = 'DELIVERY_PLAN' THEN
abs(disp_dlvry_plan_qty - trg_dlvry_plan_qty)
WHEN compare_type = 'NET' THEN
abs(disp_net_qty - trg_net_qty)
WHEN compare_type = 'NET_AO' THEN
abs(disp_ao_qty - trg_ao_qty)
WHEN compare_type = 'NET_FTRS' THEN
abs(disp_futr_qty - trg_futr_qty)
WHEN compare_type = 'NET_REPLENS' THEN
abs(disp_replen_qty - trg_replen_qty)
WHEN compare_type = 'AUTH_FTRS' THEN
abs(disp_auth_futr_qty - trg_auth_futures_qty)
END as ae,
SYSDATE AS zz_insert_tmst
FROM
 -- This in-line view returns only LEVEL_NUM = 2 or LEVEL_TYPE = 'STYLE_GROUP' data
 (SELECT plan_ctry,
 division,
 season,
 monthly_seq,
 bucket_month_date,
 tier_num,
 level_num,
 tier_volume,
 trg_event_num,
 trg_event_type,
 disp_event_num,
 max_event_num,
 first_display_event_num,
 level_type,
 level_value,
 -- The following NULL'd columns' values cannot be saved due to aggregation
 NULL AS material,
 NULL AS key_material,
 sap_cat_cd,
 sap_cat_desc,
 sap_sub_cat_cd,
 sap_sub_cat_desc,
 NULL AS sty_colr_sdesc,
 sty_grp_nbr,
 sty_grp_desc,
 NULL AS matl_typ,
 sap_prod_typ_grp, -- 'Type Group' in Brio
 typ_grp_desc, -- 'Type Group' in Brio
 NULL AS curr_prod_i2_life_cyc_cd,
 sum(disp_net_qty) AS disp_net_qty,
 sum(trg_net_qty) AS trg_net_qty,
 -- ABS(sum(trg_net_qty) - sum(disp_net_qty)) AS net_AE,
 sum(disp_dlvry_plan_qty) AS disp_dlvry_plan_qty,
 sum(trg_dlvry_plan_qty) AS trg_dlvry_plan_qty,
 -- ABS(sum(trg_dlvry_plan_qty) - sum(disp_dlvry_plan_qty)) AS dlvry_plan_AE,
 sum(disp_futr_qty) AS disp_futr_qty,
 sum(trg_futr_qty) AS trg_futr_qty,
 -- ABS(sum(trg_futr_qty) - sum(disp_futr_qty)) AS futr_AE,
 sum(disp_ao_qty) AS disp_ao_qty,
 sum(trg_ao_qty) AS trg_ao_qty,
 -- ABS(sum(trg_ao_qty) - sum(disp_ao_qty)) AS ao_AE,
 sum(disp_replen_qty) AS disp_replen_qty,
 sum(trg_replen_qty) AS trg_replen_qty,
 -- ABS(sum(trg_replen_qty) - sum(disp_replen_qty)) AS replen_AE,
 sum(disp_futr_qty) AS disp_auth_futr_qty,
 sum(trg_auth_futures_qty) AS trg_auth_futures_qty --,
 -- ABS(sum(trg_auth_futures_qty) - sum(disp_futr_qty)) AS auth_futures_AE
 FROM rpt_fam_FWEQ_detail
 WHERE plan_ctry &where_plan_ctry
 and level_num = 2 -- 'STYLE-GRP' or 'STYLE'
 -- AND (promo_ind <> 'Y' OR promo_ind IS null)
 GROUP BY plan_ctry,
 division,
 season,
 monthly_seq,
 bucket_month_date,
 tier_num,
 level_num,
 tier_volume,
 trg_event_num,
 trg_event_type,
 disp_event_num,
 max_event_num,
 first_display_event_num,
 level_type,
 level_value,
 sap_cat_cd,
 sap_cat_desc,
 sap_sub_cat_cd,
 sap_sub_cat_desc,
 sty_grp_nbr,
 sty_grp_desc,
 sap_prod_typ_grp, -- 'Type Group' in Brio
 typ_grp_desc -- 'Type Group' in Brio
 ) dtl,
 -- The following in-line view returns all of the different combinations
 -- of comparison types in the RPT_FAM_FWEQ_DETAIL table
 -- This select returns the pairing of all forecast types
 SELECT event_type, compare_type, compare_name
 from
 (SELECT event_type, compare_type, compare_type_description || ' to ' || compare_type_description AS compare_name
 FROM rpt_fam_compare_types
 WHERE event_type = 'FCST'
 UNION
 -- This select returns the pairing of all bookings types with forecast types
 SELECT bkng.event_type, fcst.compare_type, bkng.compare_type_description || ' to ' || fcst.compare_type_description AS compare_name
 FROM rpt_fam_compare_types fcst,
 rpt_fam_compare_types bkng
 WHERE fcst.event_type = 'FCST'
 AND bkng.event_type = 'BKNG'
 AND fcst.compare_type = bkng.compare_type
 WHERE event_type || ' ' || compare_type <> 'FCST AUTH_FTRS'
 AND compare_type NOT IN ('NET_SHIP', 'SHIP_NET_FTRS', 'NET_ETS', 'GROSS_FTRS')
 ) cmpr
-- The two (2) in-line views are joined by EVENT_TYPE (i.e. 'FCST' and 'BKNG')
-- to form a product of all RPT_FAM_FWEQ_DETAIL rows with comparison types
WHERE dtl.trg_event_type = cmpr.event_type
ORDER BY plan_ctry,
division,
season,
monthly_seq,
tier_num,
level_num,
tier_volume,
trg_event_num,
disp_event_num,
max_event_num,
first_display_event_num,
level_type,
level_value
COMMIT
INSERT INTO rpt_fam_FWEQ_detail_aggr
SELECT plan_ctry,
division,
season,
monthly_seq,
 bucket_month_date,
tier_num,
level_num,
tier_volume,
trg_event_num,
disp_event_num,
max_event_num,
compare_name,
first_display_event_num,
level_type,
level_value,
'TOTAL' AS row_type,
material,
key_material,
sap_cat_cd,
sap_cat_desc,
sap_sub_cat_cd,
sap_sub_cat_desc,
sty_colr_sdesc,
sty_grp_nbr,
sty_grp_desc,
matl_typ,
sap_prod_typ_grp, -- 'Type Group' in Brio
typ_grp_desc, -- 'Type Group' in Brio
curr_prod_i2_life_cyc_cd,
NULL AS promo_ind, -- for future use
-- Each RPT_FAM_FWEQ_DETAIL row's eight (8) quantity columns are broken down
-- into F1_QTY from DISP_aaaa_QTY, F2_QTY from TRG_aaaa_QTY and
 -- AE from aaaa_AE where 'aaaa' is equal to one of the COMPARE_TYPEs below:
-- F1_QTY
CASE WHEN compare_type = 'DELIVERY_PLAN' THEN
disp_dlvry_plan_qty
WHEN compare_type = 'NET' THEN
disp_net_qty
WHEN compare_type = 'NET_AO' THEN
disp_ao_qty
WHEN compare_type = 'NET_FTRS' THEN
disp_futr_qty
WHEN compare_type = 'NET_REPLENS' THEN
disp_replen_qty
WHEN compare_type = 'AUTH_FTRS' THEN
disp_auth_futr_qty
END as f1_qty,
-- F2_QTY
CASE WHEN compare_type = 'DELIVERY_PLAN' THEN
trg_dlvry_plan_qty
WHEN compare_type = 'NET' THEN
trg_net_qty
WHEN compare_type = 'NET_AO' THEN
trg_ao_qty
WHEN compare_type = 'NET_FTRS' THEN
trg_futr_qty
WHEN compare_type = 'NET_REPLENS' THEN
trg_replen_qty
WHEN compare_type = 'AUTH_FTRS' THEN
trg_auth_futures_qty
END as f2_qty,
-- AE
CASE WHEN compare_type = 'DELIVERY_PLAN' THEN
abs(disp_dlvry_plan_qty - trg_dlvry_plan_qty)
WHEN compare_type = 'NET' THEN
abs(disp_net_qty - trg_net_qty)
WHEN compare_type = 'NET_AO' THEN
abs(disp_ao_qty - trg_ao_qty)
WHEN compare_type = 'NET_FTRS' THEN
abs(disp_futr_qty - trg_futr_qty)
WHEN compare_type = 'NET_REPLENS' THEN
abs(disp_replen_qty - trg_replen_qty)
WHEN compare_type = 'AUTH_FTRS' THEN
abs(disp_auth_futr_qty - trg_auth_futures_qty)
END as ae,
SYSDATE AS zz_insert_tmst
FROM
 -- This in-line view returns only LEVEL_NUM = 3 or LEVEL_TYPE = 'MATL' data
 (SELECT plan_ctry,
 division,
 season,
 monthly_seq,
 bucket_month_date,
 tier_num,
 level_num,
 tier_volume,
 trg_event_num,
 trg_event_type,
 disp_event_num,
 max_event_num,
 first_display_event_num,
 level_type,
 level_value,
 material,
 key_material,
 sap_cat_cd,
 sap_cat_desc,
 sap_sub_cat_cd,
 sap_sub_cat_desc,
 sty_colr_sdesc,
 sty_grp_nbr,
 sty_grp_desc,
 matl_typ,
 sap_prod_typ_grp, -- 'Type Group' in Brio
 typ_grp_desc, -- 'Type Group' in Brio
 curr_prod_i2_life_cyc_cd,
 sum(disp_net_qty) AS disp_net_qty,
 sum(trg_net_qty) AS trg_net_qty,
 -- ABS(sum(trg_net_qty) - sum(disp_net_qty)) AS net_AE,
 sum(disp_dlvry_plan_qty) AS disp_dlvry_plan_qty,
 sum(trg_dlvry_plan_qty) AS trg_dlvry_plan_qty,
 -- ABS(sum(trg_dlvry_plan_qty) - sum(disp_dlvry_plan_qty)) AS dlvry_plan_AE,
 sum(disp_futr_qty) AS disp_futr_qty,
 sum(trg_futr_qty) AS trg_futr_qty,
 -- ABS(sum(trg_futr_qty) - sum(disp_futr_qty)) AS futr_AE,
 sum(disp_ao_qty) AS disp_ao_qty,
 sum(trg_ao_qty) AS trg_ao_qty,
 -- ABS(sum(trg_ao_qty) - sum(disp_ao_qty)) AS ao_AE,
 sum(disp_replen_qty) AS disp_replen_qty,
 sum(trg_replen_qty) AS trg_replen_qty,
 -- ABS(sum(trg_replen_qty) - sum(disp_replen_qty)) AS replen_AE,
 sum(disp_futr_qty) AS disp_auth_futr_qty,
 sum(trg_auth_futures_qty) AS trg_auth_futures_qty --,
 -- ABS(sum(trg_auth_futures_qty) - sum(disp_futr_qty)) AS auth_futures_AE
 FROM rpt_fam_FWEQ_detail
 WHERE plan_ctry &where_plan_ctry
 and level_num = 3 -- 'MATERIAL'
 -- AND promo_ind <> 'Y'
 GROUP BY plan_ctry,
 division,
 season,
 monthly_seq,
 bucket_month_date,
 tier_num,
 level_num,
 tier_volume,
 trg_event_num,
 trg_event_type,
 disp_event_num,
 max_event_num,
 first_display_event_num,
 level_type,
 level_value,
 material,
 key_material,
 sap_cat_cd,
 sap_cat_desc,
 sap_sub_cat_cd,
 sap_sub_cat_desc,
 sty_colr_sdesc,
 sty_grp_nbr,
 sty_grp_desc,
 matl_typ,
 sap_prod_typ_grp, -- 'Type Group' in Brio
 typ_grp_desc, -- 'Type Group' in Brio
 curr_prod_i2_life_cyc_cd
 ) dtl,
 -- The following in-line view returns all of the different combinations
 -- of comparison types in the RPT_FAM_FWEQ_DETAIL table
 -- This select returns the pairing of all forecast types
 SELECT event_type, compare_type, compare_name
 from
 (SELECT event_type, compare_type, compare_type_description || ' to ' || compare_type_description AS compare_name
 FROM rpt_fam_compare_types
 WHERE event_type = 'FCST'
 UNION
 -- This select returns the pairing of all bookings types with forecast types
 SELECT bkng.event_type, fcst.compare_type, bkng.compare_type_description || ' to ' || fcst.compare_type_description AS compare_name
 FROM rpt_fam_compare_types fcst,
 rpt_fam_compare_types bkng
 WHERE fcst.event_type = 'FCST'
 AND bkng.event_type = 'BKNG'
 AND fcst.compare_type = bkng.compare_type
 WHERE event_type || ' ' || compare_type <> 'FCST AUTH_FTRS'
 AND compare_type NOT IN ('NET_SHIP', 'SHIP_NET_FTRS', 'NET_ETS', 'GROSS_FTRS')
 ) cmpr
-- The two (2) in-line views are joined by EVENT_TYPE (i.e. 'FCST' and 'BKNG')
-- to form a product of all RPT_FAM_FWEQ_DETAIL rows with comparison types
WHERE dtl.trg_event_type = cmpr.event_type
ORDER BY plan_ctry,
division,
season,
monthly_seq,
tier_num,
level_num,
tier_volume,
trg_event_num,
disp_event_num,
max_event_num,
first_display_event_num,
level_type,
level_value
COMMIT
/

I agree.
SELECT ticket_no,name_of_the_passenger..
FROM ticket_master
WHERE ticket_no NOT IN
(SELECT Ticket_no
FROM ticket_cancellations
WHERE trip_id = my_trip_id);
This involves creating a little temp table for each record in ticket_no. Then full scanning it.
Change it to
SELECT ticket_no,name_of_the_passenger..
FROM ticket_master B
WHERE ticket_no NOT EXISTS
(SELECT null
FROM ticket_cancellations A
WHERE A.ticket_no = B.ticket_no
AND trip_id = my_trip_id);
Then you get an index hit in both cases.

How to improve Performance for Select statement

Similar Messages

Maybe you are looking for