Secondary Index Select Statement Problem

Hi friends.
I have a issue with a select statement using secondary index,
SELECT SINGLE * FROM VEKP WHERE VEGR4 EQ STAGE_DOCK
                                  AND VEGR5 NE SPACE
                                  AND WERKS EQ PLANT
        %_HINTS ORACLE
        'INDEX("&TABLE&" "VEKP~Z3" "VEKP^Z3" "VEKP_____Z3")'.
given above statement is taking long time for processing.
when i check for the same secondary index in vekp table i couldn't see any DB index name with vekp~z3 or vekp^z3 or vekp____z3.
And the sy-subrc value after select statement is 4. (even though values avaliable in VEKP with given where condition values)
My question is why my select statement is taking long time and sy-subrc is 4?
what happens if a secnodary index given in select statement, which is not avaliable in that DB Table?

Hi,
> ONe more question: is it possible to give more than one index name in select statement.
yes you can:
read the documentation:
http://download.oracle.com/docs/cd/A97630_01/server.920/a96533/hintsref.htm#5156
index_hint:
This hint can optionally specify one or more indexes:
- If this hint specifies a single available index, then the optimizer performs
a scan on this index. The optimizer does not consider a full table scan or
a scan on another index on the table.
- If this hint specifies a list of available indexes, then the optimizer
considers the cost of a scan on each index in the list and then performs
the index scan with the lowest cost. The optimizer can also choose to
scan multiple indexes from this list and merge the results, if such an
access path has the lowest cost. The optimizer does not consider a full
table scan or a scan on an index not listed in the hint.
- If this hint specifies no indexes, then the optimizer considers the
cost of a scan on each available index on the table and then performs
the index scan with the lowest cost. The optimizer can also choose to
scan multiple indexes and merge the results, if such an access path
has the lowest cost. The optimizer does not consider a full table scan.
Kind regards,
Hermann

Similar Messages

Cascading Select Statements - problem with blank drop-downs

Hello,
I have posted a number of questions about Cascading Select Statements in APEX and though I've received some good information, I still get a blank drop-down when I select the first LOV.
I also found "How to test an On-Demand Process used for AJAX" on the web. Here is the link to the web page:
http://www.inside-oracle-apex.com/2006/12/how-to-test-on-demand-process.html
When I try to test the ON-DEMAND Application Process in the Address Bar of my browser by typing the following, I get an error:
http://beta.biztech.net:2020/pls/apex/f?p=4000:0:211233229176642:APPLICATION_PROCESS=CASCADING_SELECT_LIST:::P6_PROJECT_ID:CASCADING_SELECTLIST_ITEM_1
The error I get is:
Unexpected error, unable to find item name at application or page level.
ERR-1002 Unable to find item ID for item "P6_PROJECT_ID" in application "4000".
As perhaps a last ditch effort, I will post all the steps, all the code and a link to my application.
Here is a link you can visit to view my application:
http://beta.biztech.net:2020/pls/apex/f?p=112:1
You can log in with the following ID and Password
ID: tsimkiss
PW: TS92
Here are the steps that I have followed and the code that I have used.
++++++++++++++++++++++++++++++++++++++++++++++++++
1. Create an application process in Shared Components
- On Demand CASCADING_SELECT_LIST - like this:
Process Point: On Demand
Name: CASCADING_SELECT_LIST
TYPE: PL/SQL Anonymous Block
BEGIN
OWA_UTIL.mime_header ('text/xml', FALSE);
HTP.p ('Cache-Control: no-cache');
HTP.p ('Pragma: no-cache');
OWA_UTIL.http_header_close;
HTP.prn ('<select>');
HTP.prn ('<option value="' || 1 || '">' || '- select tasks -' || '</option>');
FOR c IN (SELECT newops.task_name AS task_name,
newops.task_id AS task_id
FROM NEW_OPPORTUNITIES newops
UNION
SELECT DISTINCT pt.task_name AS task_name,
pt.task_id AS task_id
FROM pa_tasks@bizdev pt,
pa.pa_projects_all@bizdev prj
WHERE prj.project_id = pt.project_id
AND prj.project_id =
CASE
WHEN TO_NUMBER(:cascading_selectlist_item_1)=1
THEN prj.project_id
ELSE TO_NUMBER(:cascading_selectlist_item_1)
END)
LOOP
HTP.prn ('<option value="' || c.task_id || '">' || c.task_name || '</option>');
END LOOP;
HTP.prn ('</select>');
END;
2. Create an application item in Shared Components:
Name: CASCADING_SELECTLIST_ITEM_1
3. Create an LOV in Shared Components
- This is the Primary LOV (name it similar to it's select list page item):
List of Values Name: PROJECT_ID
Source: Lists of Values Query
SELECT newops.CLIENT AS project_name, newops.PROJECT_ID AS project_id FROM NEW_OPPORTUNITIES newops
UNION
SELECT ppa.NAME AS project_name, ppa.PROJECT_ID AS project_id FROM pa.pa_projects_all@bizdev ppa
WHERE ppa.project_status_code='APPROVED'
AND (ppa.COMPLETION_DATE IS NULL or ppa.completion_date > sysdate)
AND (ppa.CLOSED_DATE IS NULL or ppa.closed_date > sysdate)
ORDER BY project_name asc
4. Create a javascript and put it in the header of the page where cascading drop-downs are:
<script>
function get_select_list_xml(pThis,pSelect){
var l_Return = null;
var l_Select = html_GetElement(pSelect);
var get = new htmldb_Get(null,html_GetElement('pFlowId').value,
'APPLICATION_PROCESS=CASCADING_SELECT_LIST',0);
get.add('CASCADING_SELECTLIST_ITEM_1',pThis.value);
gReturn = get.get('XML');
if(gReturn && l_Select){
var l_Count = gReturn.getElementsByTagName("option").length;
l_Select.length = 0;
for(var i=0;i<l_Count;i++){
var l_Opt_Xml = gReturn.getElementsByTagName("option");
appendToSelect(l_Select, l_Opt_Xml.getAttribute('value'),
l_Opt_Xml.firstChild.nodeValue)
get = null;
function appendToSelect(pSelect, pValue, pContent) {
var l_Opt = document.createElement("option");
l_Opt.value = pValue;
if(document.all){
pSelect.options.add(l_Opt);
l_Opt.innerText = pContent;
}else{
l_Opt.appendChild(document.createTextNode(pContent));
pSelect.appendChild(l_Opt);
</script>
5. Create two Select List page items:
P6_PROJECT_ID <-- This is the primary drop-down
P6_TASK_ID <-- This is the secondary drop-down
6. In your primary select list, put the following into HTML Form Element Attributes:
HTML Form Element Attributes: onchange="get_select_list_xml(this,'P6_TASK_ID')"
Other settings on the page:
Name: P6_PROJECT_ID
Display As: Select List
Source Used: Always, replacing any existing values in session state
Source Type: Database Column
Source value or expression: PROJECT_ID
Named LOV: PROJECT_ID <--- Choose from drop-down (this is the Application LOV created earlier)
Null display values: - select project -
Display Null: Yes
7. The second select list is based on an LOV and depends on the value of the first select list:
Name: P6_TASK_ID
Display As: Select List
Source Used: Always, replacing any existing values in session state
Source Type: Database Column
Source value or expression: TASK_ID
Null display values: - select project -
Display Null: Yes
List of values definition:
SELECT newops.task_name AS task_name,
newops.task_id AS task_id
FROM NEW_OPPORTUNITIES newops
UNION
SELECT DISTINCT pt.task_name AS task_name,
pt.task_id AS task_id
FROM pa_tasks@bizdev pt,
pa.pa_projects_all@bizdev prj
WHERE prj.project_id=pt.project_id
AND prj.project_id=:P6_PROJECT_ID
ORDER BY task_name asc
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++
If you need an actual running copy of my application, I'm not sure I can upload to the Oracle APEX website since uses datalinks to some tables. If necessary, I will give you my login into if you email me directly, however.
If someone could just straighten my code out especially on the ON-DEMAND Application Process, I think that would really help me out.
Hope someone out there can help me.
Thanks
LEH

Sorry, looking at your code that testing URL is still incorrect. You should be passing name / value pairs in the last arguments, and your passing P6_PROJECT_ID as the name part and CASCADING_SELECTLIST_1 as the value part. In your application process you are using CASCADING_SELECTLIST_1 as the parent ID for the P6_TASK_ID dropdown, so it is this name / value pair that you'll need to test. So your URL should look something like this...
http://beta.biztech.net:2020/pls/apex/f?p=112:0:211233229176642:APPLICATION_PROCESS=CASCADING_SELECT_LIST:::CASCADING_SELECTLIST_ITEM_1:[some project id]
(Note: Where [some project id] should be an ID for a project in your database, that has tasks.)
And I'm with Dan here, I still can't access that link you provided. apex.oracle.com should be your next move if you can't resolve it, as you've got at least two people willing to go and have a look at your code.
Hope it helps,
Anthony.

TableSelectMany selection state problem.

Hi All,
I have a 'TableSelectMany' component for which I am setting the selection state based on the row index. This is working fine. But when we click on any column which is sortable, the rows are getting sorted leaving the selection states in their previous positions(the same row indexes..). Can I make these selection states dynamic by making them dependent on the value of an attribute in the column(a primary/unique key)?
If some one has done this kind of thing, can you help me in this.
Regards,
Anil Kumar K.

Hi Frank,
Thank you for responding. I am using ADF BC as the business service layer.
The piece of code I have used is....(this may help you to understand the context in which I am using it.)
HashMap hashMap = null;
CoreTable waybillsTable = null;
FacesContext context = null;
StringTokenizer tokens = null;
String waybillNos = null;
String token = null;
Row waybillRecord = null;
RowKeySet rks = null;
String waybill = null;
*some lines of code to get the waybillNo into the hashmap.
waybillsTable = this.getTable1();
int rowcnt = waybillsTable.getRowCount();
rks = new RowKeySet();
/*Row index starts from 0. So,wb starts from 0 */
for (counter = 0; counter < rowcnt; counter++) {
//set the current Row in Table
waybillsTable.setRowIndex(counter);
//check if the current Row is available
if (waybillsTable.isRowAvailable()) {
//get data for the set Current Row
waybillRecord = ((JUCtrlValueBindingRef)waybillsTable.getRowData()).getRow();
if (waybillRecord != null) {
if(waybillRecord.getAttribute("waybillNo")!=null){ //This is the attribute in the table
waybill = waybillRecord.getAttribute("waybillNo").toString();
if (hashMap != null && waybill != null) {
if (hashMap.containsKey(waybill)) {
//rks.getKeySet().add(new Integer(counter)); /*This did not work for this condition. */
rks.getKeySet().add(waybillRecord.getKey());
//test code added
hashMap.remove(waybill);
this.getTable1().getSelectionState().getKeySet().addAll(rks.getKeySet());

Select statement problem?

hi,
may i know if the select statement can work if can satisfy in the where? i check the tablex entry for where clause and it is correct but i do not know why no data collected.
any reason?
thanks
internal table it_tab with fields below
fielda
fieldb
fieldc
fieldd
fielde
select fieldb fieldc fieldd into corresponding fields of wa_tab
from tablex
where ......
if sy-subrc = 0
select single aa bb into (wa_tab-fieldd , wa_tab-fielde) where ....
concatenate wa_tab-fieldb wa_tab-fieldc to wa_tab-fielda.
collect wa_tab to it_tab.
endif.
endselect.

Hi El,
In the code u have written here :
select fieldb fieldc fieldd into corresponding fields of wa_tab
from tablex
where ......
if sy-subrc = 0.
In this code, instead of using the internal table it_tab u have used workarea wa_tab.
Only when we use select single , we will be using work area.
Hope this helps you fetch the data.
Regards,
Thasneem

Select statement problem. how to get data in one row

SELECT
razm.datum_sklenitve,
razm.datum_prenehanja,
FROM
zket_zaposlenci zap,
zket_delovna_razmerja razm,
zket_delovne_razporeditve razp,
zket_sistemizacije_dm sistdm,
zket_organizacijske_enote oe,
zket_delovna_mesta delm
WHERE
zap.iid_zaposlenca = razm.iid_zaposlenca and
razm.iid_delovno_razmerje = razp.iid_delovno_razmerje and
sistdm.iid_sistemizacija_dm(+) = razp.iid_sistemizacija_dm and
nvl(sistdm.iid_organizacijske_enote, razp.iid_organizacijske_enote) = oe.iid_organizacijske_enote and
sistdm.iid_delovno_mesto = delm.iid_delovno_mesto and
razm.datum_sklenitve <= to_date('31.12.'||:v_datum, 'dd.mm.yyyy') and
nvl(razm.datum_prenehanja, to_date('31.12.'||:v_datum, 'dd.mm.yyyy')) >= to_date('01.01.'||:v_datum, 'dd.mm.yyyy') and
razp.datum_nastopa_dela <= to_date('31.12.'||:v_datum, 'dd.mm.yyyy') and
nvl(razp.datum_prenehanja_dela, to_date('31.12.'||:v_datum, 'dd.mm.yyyy')) >= to_date('01.01.'||:v_datum, 'dd.mm.yyyy') and
zkep_splosno.zkep_hierarh_oe_n(nvl(sistdm.iid_organizacijske_enote, razp.iid_organizacijske_enote), :v_oe, to_date('31.12.'||:v_datum, 'dd.mm.yyyy')) = 1 and
to_char(zkep_splosno.zkep_vrni_prvi_dr(razm.iid_delovno_razmerje, to_date('31.12.'||:v_datum, 'dd.mm.yyyy')), 'yyyy') = :v_datum
and zap.iid_zaposlenca = 1093507
order by razm.datum_sklenitve DESC
return this rows:
datum_sklenitve datum_prenehanja
1: 01.10.2010 00:00:00 | 31.12.2010 00:00:00
2: 01.10.2010 00:00:00 | 31.12.2010 00:00:00
3: 01.04.2010 00:00:00 | 31.08.2010 00:00:00
4: 01.02.2010 00:00:00 | 31.02.2010 00:00:00
how can i get in one select just this result.
1: : 01.10.2010 00:00:00 | 31.08.2010 00:00:00 (first of A and then the next one of B which is not the same as top of B)
I try everything but i do not know how. If anyone know how to do this.
regards,
MB

Simma wrote:
But the above is not documented.Not only that, but it's string aggregation which isn't meeting the OP's requirements.
Though you could be easily forgiven as the OP hasn't clearly stated the logic behind the requirements.
It could be something like wrapping the original SQL with something like the following...
SQL> ed
Wrote file afiedt.buf
1 with t as (select date '2010-10-01' as ds, date '2010-12-31' as dp from dual union all
2 select date '2010-10-01', date '2010-12-31' from dual union all
3 select date '2010-04-01', date '2010-08-31' from dual union all
4 select date '2010-02-01', date '2010-02-28' from dual)
5 --
6 -- END OF TEST DATA
7 --
8 select max(case when rn = 1 then ds else null end) as ds
9 ,max(case when rn = 2 then dp else null end) as dp
10 from (
11 select ds, dp, row_number() over (order by ds desc nulls last) rn
12 from (
13 select case when lag(ds) over (order by ds desc) = ds and lag(dp) over (order by ds desc) = dp then null else ds end as ds
14 ,case when lag(ds) over (order by ds desc) = ds and lag(dp) over (order by ds desc) = dp then null else dp end as dp
15 from t
16 order by t.ds
17 )
18* )
SQL> /
DS DP
01/10/2010 00:00:00 31/08/2010 00:00:00
SQL>but who knows?

Use two secondary indexes in a select statement

hi, i want to use two secondary indexes in a select statement.
how can i do it?

Hello,
To do it use the WHERE stm in the same order as the secondary stm is on SE11....To check if the index is used go to tcode ST05.
example
select * from ztable
WHERE BUKRS EQ 'BUK1' AND
ZFIELD EQ 'BOY'.
on se11 on the ZTABLE indexes setion must have a secondary index with
BUKRS and
ZFIELD.
BYE!!
Hope this helps!!
Gabriel

Problems with Hints in abap code to use an index in a Select statement

Hi,
I want to use an especific index in a select statement but I can´t get it. I use de next statement:
SELECT ltaklgnum ltaktanum ltakvbeln ltaptapos ltapnltyp ltappvqui
 FROM ltak AS ltak INNER JOIN ltap AS ltap
 ON ltaktanum = ltaptanum
 AND ltaklgnum = ltaplgnum
 INTO TABLE l_t_tanum_silo
 WHERE ltap~lgnum EQ ip_lgnum
 AND ltap~pquit EQ ' '
 AND ltak~lgnum EQ ip_lgnum
 AND ltak~kquit EQ ' '
 AND ltak~queue EQ ip_queue
 %_HINTS DB2 ''.
We have DB2 for Linux Unix and Windows 9.5 as DB system.
How can I fix this?
Thanks a lot.
Regards

The DB2 for Linux Unix and Windows is coded DB6 for SAP and not DB2
Look at the following OSS notes
- [Note 129385 - Database hints in Open SQL|https://service.sap.com/sap/support/notes/129385]
- [Note 150037 - Database hints in Open SQL for DB6 (DB2 for LUW)|https://service.sap.com/sap/support/notes/150037]
- [Note 1270314 - DB6: DB2 9.5 Perf. degrad. for queries with INLIST clause|https://service.sap.com/sap/support/notes/1270314]
- [Note 868888 - DB6: Optimization Guidelines|https://service.sap.com/sap/support/notes/868888]
You should use a
SELECT ltak~lgnum ltak~tanum ltak~vbeln ltap~tapos ltap~nltyp ltap~pvqui
FROM ltak AS ltak INNER JOIN ltap AS ltap
ON ltak~tanum = ltap~tanum
 AND ltak~lgnum = ltap~lgnum
INTO TABLE l_t_tanum_silo
WHERE ltap~lgnum EQ ip_lgnum
 AND ltap~pquit EQ ' '
 AND ltak~lgnum EQ ip_lgnum
 AND ltak~kquit EQ ' '
 AND ltak~queue EQ ip_queue
%_HINTS DB6 '<IXSCAN TABLE=''LTAP'' INDEX=''"LTAP~M"'' />'.
In note 868888 there is a sample for a join.
SELECT A~TABSPACE
FROM TADB6 AS A
JOIN IADB6 AS B ON A~TABART = B~TABART
%_HINTS DB6 '<NLJOIN><IXSCAN TABLE=''IADB6'' />'
 DB6 '<IXSCAN TABLE=''TADB6'' /></NLJOIN>'.
Regards

What is syntax for inner join of Select statement with Secondary Index

Hi Genies,
                Here i have created the Secondary index for table COEP and also used for select query but there is no improvement in runtime . taking same time for select query without index as well as with index. my code is
SELECT * INTO CORRESPONDING FIELDS OF TABLE ITAB_COEP FROM COEP AS A
             INNER JOIN COBK AS B ON ( A~BELNR = B~BELNR AND A~KOKRS = B~KOKRS AND A~GJAHR = B~GJAHR )
             WHERE A~OBJNR = OBJNR
             AND A~GJAHR = CURRY
             AND B~GJAHR = CURRY
             AND A~RBEST = ''
             AND A~BEKNZ = 'S'
             AND B~BELNR NE WA_COBK-BELNR
             AND B~AWREF_REV = ''
             AND B~AWORG_REV = ''
             AND B~KOKRS = WA_COIOB-KOKRS
             AND B~BLDAT BETWEEN START_DATE AND END_DATE
             AND B~BLART IN ('SA','KA','KR','AB') %_HINTS ORACLE 'INDEX("COEP" "COEP~ZBU")'.
index name is ZBU.
please any one let me know is there any syntax mistakes? but while checking and during the runtime it does'nt shows any error.
Regards,
        Thangam.P

Hi Genies,
                Here i have created the Secondary index for table COEP and also used for select query but there is no improvement in runtime . taking same time for select query without index as well as with index. my code is
SELECT * INTO CORRESPONDING FIELDS OF TABLE ITAB_COEP FROM COEP AS A
             INNER JOIN COBK AS B ON ( A~BELNR = B~BELNR AND A~KOKRS = B~KOKRS AND A~GJAHR = B~GJAHR )
             WHERE A~OBJNR = OBJNR
             AND A~GJAHR = CURRY
             AND B~GJAHR = CURRY
             AND A~RBEST = ''
             AND A~BEKNZ = 'S'
             AND B~BELNR NE WA_COBK-BELNR
             AND B~AWREF_REV = ''
             AND B~AWORG_REV = ''
             AND B~KOKRS = WA_COIOB-KOKRS
             AND B~BLDAT BETWEEN START_DATE AND END_DATE
             AND B~BLART IN ('SA','KA','KR','AB') %_HINTS ORACLE 'INDEX("COEP" "COEP~ZBU")'.
index name is ZBU.
please any one let me know is there any syntax mistakes? but while checking and during the runtime it does'nt shows any error.
Regards,
        Thangam.P

Secondary Index Picked with one field short in select query

Hi,
We have a select query as follows
select single lgort       vgbel        vgpos
    into   (lips-lgort,lips-vgbel,lips-vgpos)
    from    lips
   where         vbeln          Eq p_zlcpp-vbeln
     and         matnr          Eq p_zlcpp-matnr
     and         charg          Eq p_zlcpp-charg
The secondary index ZB has the fields as follows:
MANDT     Client
MATNR     Material Number
CHARG     Batch Number
BWART     Movement Type (Inventory Management)
When seen in the trace it seems the select query picks this secondary index. Whether it is correct? since i find no BWART in the select query. Because of this index the query take large time. I used the Hint statement as follows:
select single lgort       vgbel        vgpos
    into   (lips-lgort,lips-vgbel,lips-vgpos)
    from    lips
   where         vbeln          Eq p_zlcpp-vbeln
     and         matnr          Eq p_zlcpp-matnr
     and         charg          Eq p_zlcpp-charg   %_HINTS ORACLE 'INDEX("LIPS" "LIPS~0")' .
and it now works fast. Please advice the best way to make the select query work on itself without using the hint statement to pick the index LIPS~0 instead of the invalid secondary index ZB.
Thanks & Regards,
Selvakumar M.
Edited by: Selva on Jun 17, 2011 7:35 PM

Hello Selva,
your problem here is the decision of the optimizer that does not exactly know the selectivity of the fields.
If your deliveries are normally small (not too many items), then selecting via the document number will be relatively fast.
And selecting via the material number + batch will be slow in case if many deliveries are having same product from the same batch delivered.
I assume that the latest is the case in your system. That's why the selection with ZB index is slow.
If the data distribution is as I described above, then your hint is quite OK and I advise you to stick to the hint.
From my PoV this is the better solution rather changing the coding and throwing out MATNR field from the WHERE clause to filter later in ABAP.
Another solution would be trying to play with histograms. But you'll need %SUBSTITUTE VALUES% or %SUBSTITUTE LITERALS% hint anyway, so I find your solution better.
So, please stay with hint. Even SAP standard development does it for some select statements.
Regards,
Yuri

When is a secondary index used (in select or where)

HI All,
We are confused (and new to ABAP) on the various postings on SDN concerning this topic. Replies seem to vary.
We have the following select statement:
SELECT date1 FROM table2
WHERE material (from a stored internal table) = material-table2
AND order (from a stored internal table) = order-table2
AND delivery method (from a stored internal table) = specific value of table2.
For a second index to be created, would we create the index for only date1 (since it's the only field we are selecting from table 2) or an index with date1, material, order, delivery method or just what's in the WHERE clause of material, order and delivery method?
How can you be sure that an index will be used?
Thank you!

> We are confused (and new to ABAP)
seem you are very very new.
Your question is actually not ABAP indexes etc are SQL and can be found in many textbooks also on Wiki pages. ABAP uses SQL, but does not change much.
The use index is determined nearly only by the WHERE clause. You want to know the phone number of somebody and you know the name and the address. The Index uses the name and the address as a telephone book. The phone number comes from the table not the index! This is not the secondary index, but the primary index.
If you search in the internet for phone number, then you can use also a secondary index, i.e. you know only the complete address but not the name. A phone book would not help here.
Which index is used, if often very simple as in the example, but can become very difficult. That is done by a sophisticated program of the database, the optimizer. Check other resoucres for details.
Siegfried

Problem with Select Statements

Hi All,
I have a performance problem for my report because of the following statements.
How can i modify the select statements for improving the performance of the report.
DATA : shkzg1h LIKE bsad-shkzg,
 shkzg1s LIKE bsad-shkzg,
 shkzg2h LIKE bsad-shkzg,
 shkzg2s LIKE bsad-shkzg,
 shkzg1hu LIKE bsad-shkzg,
 shkzg1su LIKE bsad-shkzg,
 shkzg2hu LIKE bsad-shkzg,
 shkzg2su LIKE bsad-shkzg,
 kopbal1s LIKE bsad-dmbtr,
 kopbal2s LIKE bsad-dmbtr,
 kopbal1h LIKE bsad-dmbtr,
 kopbal2h LIKE bsad-dmbtr,
 kopbal1su LIKE bsad-dmbtr,
 kopbal2su LIKE bsad-dmbtr,
 kopbal1hu LIKE bsad-dmbtr,
 kopbal2hu LIKE bsad-dmbtr.
*These statements are in LOOP.
 SELECT shkzg SUM( dmbtr )
 INTO (shkzg1s , kopbal1s)
 FROM bsid
 WHERE bukrs = ibukrs
 AND kunnr = ktab-kunnr
 AND budat < idate-low
 AND shkzg = 'S'
 AND umskz EQ ''
 GROUP BY shkzg.
 ENDSELECT.
 SELECT shkzg SUM( dmbtr )
 INTO (shkzg1su , kopbal1su)
 FROM bsid
 WHERE bukrs = ibukrs
 AND kunnr = ktab-kunnr
 AND budat < idate-low
 AND shkzg = 'S'
 AND umskz IN zspgl
 GROUP BY shkzg.
 ENDSELECT.
 SELECT shkzg SUM( dmbtr )
 INTO (shkzg1h , kopbal1h)
 FROM bsid
 WHERE bukrs = ibukrs
 AND kunnr = ktab-kunnr
 AND budat < idate-low
 AND shkzg = 'H'
 AND umskz EQ ''
 GROUP BY shkzg.
 ENDSELECT.
 SELECT shkzg SUM( dmbtr )
 INTO (shkzg1hu , kopbal1hu)
 FROM bsid
 WHERE bukrs = ibukrs
 AND kunnr = ktab-kunnr
 AND budat < idate-low
 AND shkzg = 'H'
 AND umskz IN zspgl
 GROUP BY shkzg.
 ENDSELECT.
 SELECT shkzg SUM( dmbtr )
 INTO (shkzg2s , kopbal2s)
 FROM bsad
 WHERE bukrs = ibukrs
 AND kunnr = ktab-kunnr
 AND budat < idate-low
 AND shkzg = 'S'
 AND umskz EQ ''
 GROUP BY shkzg.
 ENDSELECT.
 SELECT shkzg SUM( dmbtr )
 INTO (shkzg2su , kopbal2su)
 FROM bsad
 WHERE bukrs = ibukrs
 AND kunnr = ktab-kunnr
 AND budat < idate-low
 AND shkzg = 'S'
 AND umskz IN zspgl
 GROUP BY shkzg.
 ENDSELECT.
 SELECT shkzg SUM( dmbtr )
 INTO (shkzg2h , kopbal2h)
 FROM bsad
 WHERE bukrs = ibukrs
 AND kunnr = ktab-kunnr
 AND budat < idate-low
 AND shkzg = 'H'
 AND umskz EQ ''
 GROUP BY shkzg.
 ENDSELECT.
 SELECT shkzg SUM( dmbtr )
 INTO (shkzg2hu , kopbal2hu)
 FROM bsad
 WHERE bukrs = ibukrs
 AND kunnr = ktab-kunnr
 AND budat < idate-low
 AND shkzg = 'H'
 AND umskz IN zspgl
 GROUP BY shkzg.
 ENDSELECT.

>
Siegfried Boes wrote:
> Please stop writing answers if you understrand nothing about database SELECTS!
> All above recommendations are pure nonsense!
>
> As always with such questions, you must do an analysis before you ask! The coding itself is perfectly o.k., a SELECT with an aggregate and a GROUP BY can not be changed into a SELECT SINGLE or whatever.
>
> But your SELECTS mustr be supported by indexes!
>
> Please run SQL Trace, and tell us the results:
>
> I see 8 statements, what is the duration and the number of records coming back for each statement?
> Maybe only one statement is slow.
>
> See
> SQL trace:
> /people/siegfried.boes/blog/2007/09/05/the-sql-trace-st05-150-quick-and-easy
>
>
> Siegfried
Nice point there Siegfried. Instead of giving constructive suggestion, people here give a very bad suggestion on using SELECT SINGLE combined with SUM and GROUP BY.
I hope the person already look at your reply before he try using select single and wondering why he has error.
Anyway, the most important thing is how many loop expected for those select statements?
If you have like thousands of loop, you can expect a poor performance.
So, you should also look at how many times the select statement is called and not only performance for each select statement when you're doing SQL trace.
Regards,
Abraham

Select query with secondary index

hi,
i have a report which is giving performance issues on a perticular select query on KONH table.
the select query doesnt use the primary key fields and table already has around 19 million entries.So there was a secondary index created for the fields in the table.
now, KONH is a client specific table, and hence has MANDT as the first field. when the table is not indexed it is sorted according to the order of fields, like first MANDT, then primary key fields and then remaining fields.. (correct me if i am wrong)
but the secondary index created doesnt has MANDT in it..(yea, a mistake! )...
but instead of correccting the secondary index, i am told to change the select query..
so, i used a "client specific" syntax to sort the issue.. but i dont understand whre i should put the "where mandt eq sy-mandt" clause..
should i put it right after all my secondary index fields are over? or what happens to the order of fields which are not present in the list of secondary index?
kindaly help.
thanx.

Hi chinmay kulkarni,
its better if you can ask concerned person to add MANDT field in your index as well....
Indexes and MANDT
If a table begins with the mandt field, so should its indexes. If a table begins with mandt and an index doesn't, the optimizer might not use the index.
Remember, if you will, Open SQL's automatic client handling feature. When select * from ztxlfa1 where land1 = 'US' is executed, the actual SQL sent to the database is select * from ztxlfa1 where mandt = sy-mandt and land1 = 'US'. Sy-mandt contains the current logon client. When you select rows from a table using Open SQL, the system automatically adds sy-mandt to the where clause, which causes only those rows pertaining to the current logon client to be found.
When you create an index on a table containing mandt, therefore, you should also include mandt in the index. It should come first in the index, because it will always appear first in the generated SQL.
Index: Technical key of a database table.
Primary index: The primary index contains the key fields of the table and a pointer to the non-key fields of the table. The primary index is created automatically when the table is created in the database.
Secondary index: Additional indexes could be created considering the most frequently accessed dimensions of the table.
Structure of an Index
An index can be used to speed up the selection of data records from a table.
An index can be considered to be a copy of a database table reduced to certain fields. The data is stored in sorted form in this copy. This sorting permits fast access to the records of the table (for example using a binary search). Not all of the fields of the table are contained in the index. The index also contains a pointer from the index entry to the corresponding table entry to permit all the field contents to be read.
When creating indexes, please note that:
An index can only be used up to the last specified field in the selection! The fields which are specified in the WHERE clause for a large number of selections should be in the first position.
Only those fields whose values significantly restrict the amount of data are meaningful in an index.
When you change a data record of a table, you must adjust the index sorting. Tables whose contents are frequently changed therefore should not have too many indexes.
Make sure that the indexes on a table are as disjunctive as possible.
(That is they should contain as few fields in common as possible. If two indexes on a table have a large number of common fields, this could make it more difficult for the optimizer to choose the most selective index.)
For Example...
SELECT KUNNR KUNN2 INTO TABLE T_CUST_TERR
FROM KNVP CLIENT SPECIFIED
WHERE MANDT = SY-MANDT " here MANDT shd be first
AND KUNN2 IN S_TERR
AND PARVW LIKE 'Z%'.
Accessing tables using Indexes
The database optimizer decides which index on the table should be used by the database to access data records.
You must distinguish between the primary index and secondary indexes of a table. The primary index contains the key fields of the table. The primary index is automatically created in the database when the table is activated. If a large table is frequently accessed such that it is not possible to apply primary index sorting, you should create secondary indexes for the table.
The indexes on a table have a three-character index ID. '0' is reserved for the primary index. Customers can create their own indexes on SAP tables; their IDs must begin with Y or Z.
If the index fields have key function, i.e. they already uniquely identify each record of the table, an index can be called a unique index. This ensures that there are no duplicate index fields in the database.
When you define a secondary index in the ABAP Dictionary, you can specify whether it should be created on the database when it is activated. Some indexes only result in a gain in performance for certain database systems. You can therefore specify a list of database systems when you define an index. The index is then only created on the specified database systems when activated
Also pls have a look on below link
http://www.sapfans.com/sapfans/forum/devel/messages/30240.html
Hope it will solve your problem..
Reward points if useful...
Thanks & Regards
ilesh 24x7

Facing problem in select statement dump DBIF_RSQL_INVALID_RSQL CX_SY_OPEN_S

Hi Experts,
I am facing the problem in the select statement where it giving the short dump
DBIF_RSQL_INVALID_RSQL CX_SY_OPEN_S.
i have searched many forms, but i found that the select option s_matnr have the limitaion 2000 entreis, but i am passing same s_matnr to other select statement with more than 2000 entries but it is not giving me any short dump.
but i am facing problem with only one select statement where if i pass select option s_matnr more than 1500 entris also giving short dump.
my select statement is
SELECT * FROM bsim
         INTO CORRESPONDING FIELDS OF TABLE g_t_bsim_lean
           FOR ALL ENTRIES IN t_bwkey   WHERE bwkey = t_bwkey-bwkey
                                        AND    matnr IN matnr
                                        AND    bwtar IN bwtar
                                        AND    budat >= datum-low.
in the internal table g_t_bsim_lean internal table contain all the fields of the table bsim with 2 fields from other table.
Please let me know whether i need to change the select statement or any other solution for this.
Regards,
udupi

my select query is like this:
DATA: BEGIN OF t_bwkey OCCURS 0,                          "184465
          bwkey LIKE bsim-bwkey,                            "184465
        END OF t_bwkey.                                     "184465
LOOP AT g_t_organ          WHERE keytype = c_bwkey.
    MOVE g_t_organ-bwkey     TO t_bwkey-bwkey.
    COLLECT t_bwkey.                                        "184465
ENDLOOP.                                                  "184465
READ TABLE t_bwkey INDEX 1.                               "184465
CHECK sy-subrc = 0.                                       "184465
SELECT * FROM bsim                                        "n443935
         INTO CORRESPONDING FIELDS OF TABLE g_t_bsim_lean   "n443935
           FOR ALL ENTRIES IN t_bwkey   WHERE bwkey = t_bwkey-bwkey
                                        AND    matnr IN matnr
                                        AND    bwtar IN bwtar
                                        AND    budat >= datum-low.

Issue with select query for secondary index

Hi all,
I have created a secondary index A on mara table with fields Mandt and Packaging Material Type VHART.
Now i am trying to write a report
Tables : mara.
data : begin of itab occurs 0.
include structure mara.
data : end of itab.
*select * from mara into table itab*
CLIENT SPECIFIED where
MANDT = SY-MANDT and
VHART = 'WER'.
I'm getting an error
Unable to interpret "CLIENT". Possible causes of error: Incorrect spelling or comma error.
if i change to my select query     to
*select * from mara into table itab*
where
MANDT = SY-MANDT and
VHART = 'WER'.
I'm getting an error
Without the addition "CLIENT SPECIFIED", you cannot specify the client     field "MANDT" in the WHERE condition.
Let me know if iam wrong and we are at 4.6c
Thanks

Like I already said, even if you have added the mandt field in the secondary index, there is no need the use it in the select statement.
Let me elaborate on my reply before. If you have created a UNIQUE index, which I don't think you have, then you should include CLIENT in the index. A unique index for a client-dependent table must contain the client field.
Additional info:
The accessing speed does not depend on whether or not an index is defined as a unique index. A unique index is simply a means of defining that certain field combinations of data records in a table are unique.
Even if you have defined a secondary index, this does not automatically mean, that this index is used. This also depends on the database optimizer. The optimizer will determine which index is best and use it. So before transporting this index, you should make sure that the index is used. How to check this, have a look at the link:
[check if index is used|http://help.sap.com/saphelp_nw70/helpdata/EN/cf/21eb3a446011d189700000e8322d00/content.htm]
Edited by: Micky Oestreich on May 13, 2008 10:09 PM

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

Secondary Index Select Statement Problem

Similar Messages

Maybe you are looking for