Which to use - Sy-index or sy-tabix ??

This is what i found out about SY-INDEX and SY-TABIX but which one to use when i want to delete a line of data from an internal table ? I tried both sy-index and sy-tabix and both works fine and returning the expected output for me but which one is better of to use ?
SY-TABIX :- For Internal Table, Current Line Index
SY-INDEX :- For Loops, Current Loop Pass
The below code is where i uses the Delete ..
LOOP AT dmg.
        CONCATENATE
               dmg-dmg00
               dmg-dmg01
               dmg-dmg02
               dmg-dmg03
               dmg-dmg04
               dmg-dmg07
               dmg-dmg08
               dmg-dmg09 INTO tli_down1 SEPARATED BY '*'.
        APPEND tli_down1. CLEAR tli_down1.
        DELETE dmg INDEX sy-index.
        EXIT.
      ENDLOOP.

Right. Just like what they said upstairs, sy-babix is the best choice.
One more thing is, if you want to concatenate fields of table dmg and append to tli_down1 on by one. You should not use EXIT after delete dmg.
In that case ,only one line can be appended into tli_down1 table.
> The below code is where i uses the Delete ..
>
> LOOP AT dmg.
>         CONCATENATE
>        dmg-dmg00
>         dmg-dmg01
>        dmg-dmg02
>         dmg-dmg03
>        dmg-dmg04
>         dmg-dmg07
>        dmg-dmg08
>         dmg-dmg09 INTO tli_down1 SEPARATED BY '*'.
>   APPEND tli_down1. CLEAR tli_down1.
>       DELETE dmg INDEX sy-index.
>   EXIT.
>     ENDLOOP.

Similar Messages

Which queries using particular index?

Hello,
Is it possible in Oracle 11gR2 to find out which queries are using or used particular INDEX?
Thanks a lot for your suggestion.
Best Regards

Hello,
Thanks a lot.
I have queried what you suggested, and got 5 sql_ids, but I quickly got the EXPLAIN PLAN for all the 5 sql_ids after getting sql_text, but the index I am looking for is not in the NAME column of select * from table (dbms_xplan.display());
select distinct(sql_id) from v$sql_plan where object_owner = 'HEMANT' and object_name = '&myindex';
I am little confused now, as v$sql_plan showing 5 sqls based on myindex but no one is actually using index?
Thank you.
Best Regards

What is difference between sy-index and sy-tabix and where both are using ?

what is difference between sy-index and sy-tabix and where both are using ?

hi nagaraju
sy-tabix is in Internal table, current line index. So it can only be used while looping at the internal table.
sy-index is in Loops, number of current pass. This you can use in other loop statements also (like do-enddo loop, while-endwhile)
SY-INDEX is a counter for following loops: do...enddo, while..endwhile
SY-TABIX is a counter for LOOP...ENDLOOP, READ TABLE...
Here is an example from which you can understand the difference between sy-tabix and sy-index.
Itab is an internal table with the following data in it.
id Name
198 XYZ
475 ABC
545 PQR.
loop at itab where id > 300.
write :/ itab-id, itab-name , sy-tabix, sy-index.
endloop.
My output will be :
475 ABC 2 1
545 PQR 3 2
Sy-tabix is the index of the record in internal table.
sy-index gives the no of times of loop passes.
So, for the first record in the output (475 ABC), 2 is the index of the record in internal table and as it is first time loop pass occured, sy-index value is 1.
Regards,
navjot
award points

How to find which user is using the index?

Hi All,
I have an index named 'CTXT_ITEM_CODE' . The Index _type is Domain. When i try to drop this index its telling ORA-00054: resource busy and acquire with NOWAIT specified error
now i need to find out which session is using this index, so that i can kill it and drop the index.
Thanks

SELECT c.owner,
 c.object_name,
 c.object_type,
 b.SID,
 b.serial#,
 b.status,
 b.osuser,
 b.machine
FROM v$locked_object a, v$session b, dba_objects c
WHERE b.SID = a.session_id AND a.object_id = c.object_id
AND c.object_name='CTXT_ITEM_CODE';
ALTER SYSTEM KILL SESSION '<sid, serial#>'

What is diff b/w sy-index and sy-tabix

Hi all,
Can u plz give me the diff b/w sy-index and sy-tabix exactly and how it works.
Thanks & Regards
Venkat

Hi Venkat,
1.SY-INDEX
->Current loop pass
->In a DO or WHILE loop, SY-INDEX contains the number of loop passes including the current pass.
2.SY-TABIX
->Current line index
Current line of an internal table. SY-TABIX is set by the statements below, but only for index tables.
The field is either not set or is set to 0 for hashed tables.
APPEND sets SY-TABIX to the index of the last line of the table, that is, it contains the overall number of entries in the table.

COLLECT sets SY-TABIX to the index of the existing or inserted line in the table. If the table has the type HASHED TABLE, SY-TABIX is set to 0.
LOOP AT sets SY-TABIX to the index of the current line at the beginning of each loop lass. At the end of the loop, SY-TABIX is reset to the value that it had before entering the loop. It is set to 0 if the table has the type HASHED TABLE.
READ TABLE sets SY-TABIX to the index of the table line read. If you use a binary search, and the system does not find a line, SY-TABIX contains the total number of lines, or one more than the total number of lines. SY-INDEX is undefined if a linear search fails to return an entry.

SEARCH <itab> FOR sets SY-TABIX to the index of the table line in which the search string is found.
I think that it clears ur doubt.
Thanks,
Venkat.O

Difference b/w sy-index and sy-tabix

hai all,
Could u explain the difference b/w sy-index and sy-tabix?
regards,
Selva

Hi,
sy-index - For Loops, Current Loop Pass.
sy-tabix - For Internal Table, Current Line Index in internal table.
sy-tabix is used at internal table operations (READ TABLE ... LOOP AT ...), sy-index is used at cycles (DO...n TIMES).
SY-TABIX:
Current line of an internal table. SY-TABIX is set by the statements below, but only for index tables. The field is either not set or is set to 0 for hashed tables.
it can be set by using the following:
1.append
2.collect
3.loop at
4. read
5.search
APPEND sets SY-TABIX to the index of the last line of the table, that is, it contains the overall number of entries in the table.
COLLECT sets SY-TABIX to the index of the existing or inserted line in the table. If the table has the type HASHED TABLE, SY-TABIX is set to 0.
LOOP AT sets SY-TABIX to the index of the current line at the beginning of each loop lass. At the end of the loop, SY-TABIX is reset to the value that it had before entering the loop. It is set to 0 if the table has the type HASHED TABLE.
READ TABLE sets SY-TABIX to the index of the table line read. If you use a binary search, and the system does not find a line, SY-TABIX contains the total number of lines, or one more than the total number of lines. SY-INDEX is undefined if a linear search fails to return an entry.
SEARCH <itab> FOR sets SY-TABIX to the index of the table line in which the search string is found.
SY-INDEX:
SY-INDEX is used to describe the number of iteration with in the DO..ENDDO, WHILE ...ENDWHILE....
for example,
DO.
WRITE SY-INDEX.
IF SY-INDEX = 3.
EXIT.
ENDIF.
ENDDO.
it gives output as:
1 2 3
Regards,
Raj.

Regarding sy-index and sy-tabix

Hi,
What is the major difference between sy-index and sy-tabix ,
can you give me one good example with code..
Regards,
Reddy.

Hi,
SY-TABIX - Current line of an internal table. SY-TABIX is set by the statements below, but only for index tables. The field is either not set or is set to 0 for hashed tables.
APPEND sets SY-TABIX to the index of the last line of the table, that is, it contains the overall number of entries in the table.
COLLECT sets SY-TABIX to the index of the existing or inserted line in the table. If the table has the type HASHED TABLE, SY-TABIX is set to 0.
LOOP AT sets SY-TABIX to the index of the current line at the beginning of each loop lass. At the end of the loop, SY-TABIX is reset to the value that it had before entering the loop. It is set to 0 if the table has the type HASHED TABLE.
READ TABLE sets SY-TABIX to the index of the table line read. If you use a binary search, and the system does not find a line, SY-TABIX contains the total number of lines, or one more than the total number of lines. SY-INDEX is undefined if a linear search fails to return an entry.
SEARCH FOR sets SY-TABIX to the index of the table line in which the search string is found.
SY_INDEX - In a DO or WHILE loop, SY-INDEX contains the number of loop passes including the current pass.
sy-tabix is the tab index - the index of the record in the internal table you are accessing,
sy-index is the loop counter.
If you use a condition in LOOP the sy-index will go from 1 to n, but sy-tabix will refer to the line in the internal table.
Hope this helps u.
Thanks,
Ruthra

Sy-index vs sy-tabix

hi,
i a bit confused of these 2. can let me know the difference?
normally used in internal table?
what keyword can use these 2? read, insert, delete,loop, append, modify.
thanks

hi,
SY-INDEX
The system field sy-index contains the number of loop passes, including the current loop pass.
There are four kinds of loops in ABAP:
· Unconditional loops using the DO statement.
· Conditional loops using the WHILE statement.
· Loops through internal tables and extract datasets using the LOOP statement.
· Loops through datasets from database tables using the SELECT statement.
SY-TABIX
If the internal table is an index table, SY-TABIX is set to the index of the line retrieved.
READ
chk out this link http://help.sap.com/saphelp_nw04/helpdata/en/fc/eb35f8358411d1829f0000e829fbfe/content.htm
APPEND sets SY-TABIX to the index of the last table row, that is the total number of entries in the target table.
LOOP AT sets SY-TABIX to the index of the current table row at the beginning of every loop pass. After leaving a loop, SY-TABIX is set to the value it had before entering the loop. With hashed tables, SY-TABIX is set to 0.
INSERT
chk out this link
http://help.sap.com/saphelp_nw2004s/helpdata/en/fc/eb361f358411d1829f0000e829fbfe/content.htm
DELETE
http://help.sap.com/saphelp_nw04/helpdata/en/fc/eb37d9358411d1829f0000e829fbfe/content.htm
MODIFY
http://help.sap.com/saphelp_nw2004s/helpdata/en/fc/eb35eb358411d1829f0000e829fbfe/content.htm
hope this ll help u.
Regards,
Viji

Can I refactor this query to use an index more efficiently?

I have a members table with fields such as id, last name, first name, address, join date, etc.
I have a unique index defined on (last_name, join_date, id).
This query will use the index for a range scan, no sort required since the index will be in order for that range ('Smith'):
SELECT members.*
        FROM members
        WHERE last_name = 'Smith'
        ORDER BY joindate, idIs there any way I can get something like the following to use the index (with no sort) as well:
SELECT members.*
        FROM members
        WHERE last_name like 'S%'
        ORDER BY joindate, idI understand the difficulty is probably; even if it does a range scan on every last name 'S%' (assuming it can?), they're not necessarily in order. Case in point:
Last_Name: JoinDate:
Smith          2/5/2010
Smuckers     1/10/2010An index range scan of 'S%' would return them in the above order, which is not ordered by joindate.
So is there any way I can refactor this (query or index) such that the index can be range scanned (using LIKE 'x%') and return rows in the correct order without performing a sort? Or is that simply not possible?

xaeryan wrote:
I have a members table with fields such as id, last name, first name, address, join date, etc.
I have a unique index defined on (last_name, join_date, id).
This query will use the index for a range scan, no sort required since the index will be in order for that range ('Smith'):
SELECT members.*
FROM members
WHERE last_name = 'Smith'
ORDER BY joindate, idIs there any way I can get something like the following to use the index (with no sort) as well:
SELECT members.*
FROM members
WHERE last_name like 'S%'
ORDER BY joindate, idI understand the difficulty is probably; even if it does a range scan on every last name 'S%' (assuming it can?), they're not necessarily in order. Case in point:
Last_Name: JoinDate:
Smith          2/5/2010
Smuckers     1/10/2010An index range scan of 'S%' would return them in the above order, which is not ordered by joindate.
So is there any way I can refactor this (query or index) such that the index can be range scanned (using LIKE 'x%') and return rows in the correct order without performing a sort? Or is that simply not possible?Come on. Index column order does matter. "LIKE 'x%'" actually is full table scan. The db engine accesses contiguous index entries and then uses the ROWID values in the index to retrieve the table rows.

How to use cfloop index value as part of another variable

Hello,
I have a RATE form that first asks "how many rates will you
be adding?" that answer generates a series of form elements based
on the answer. You then have a form grid to populate, 3 values for
each rate (price, code, name).
This part works fine. The issue is now I need to INSERT the
values into the table, so I need to use the INDEX value of the
cfloop to recreate the amount (and names) of the fields in the
INSERT statement. How do I escape, or re-create the evaluated form
elements ( in which their count is #i# as the loop goes) when I
need to evaluate for #i# AND evaluate for #form.sku_i_name# at the
same pass?
I am passing, for example, #form.sku_2_Name# where that might
equal "Half Page". The number 2 in that variable was assigned
during the form creation by the current index of a cfloop. Since my
action (insert) page does not know how many (out of 50 possible)
sku's are coming, how do I use the skuCount (another hidden value
passed as well) to create a proper INSERT SQL command when I need
to eval the form element and the index at the same time?
Obviously #sku_#i#_Name# does not work, and #sku_i_Name# does
not either... I know this can be done, and that I am just doing it
wrong.
Thanks for any help!

bigbrain28 wrote:
> Thank You, cfsearching! I don't quite understand 100%
how it works
As all three of us indicated you use array notation for this
type of
requirement. In ColdFusion you can use array notation or dot
notation
to access structure data. Almost all data in ColdFusion is
now some
type of structure.
I.E. #Form['myField']# is the same as #Form.myField#.
The advantage is that with array notation you can do things
you can not
do with dot notation. You can reference elements that have
keys that
are illegal variable names such as one with a space.
I.E. #url['my field'] is allowed, #url.my field# would fail
or course.
And you can concatenate the key string as we did with your
example.
I.E. #Form['aString' & aVariable]#
There are many powerful things one can do with this
knowledge. One can
access record sets with array notations. This can allow for
very
sophisticated parsing of a record set.
I.E. #myQuery['column'][row]#
You can dynamical call a variable. Thus creating dynamic code
that does
not even need to know what variables exist until run time.
I.E. #variables[anyName]#
This just scratches the surface.

Why cant we use sy-index in loop and endloop?where exactly we used sy-index

hi
can u help me for this

Hi...
Genereally Sy-index is used in iterative cases like
while....endwhile
and
Do.... Enddo
In LOOP ..... Endloop.... We should use SY-TABIX....
It would be more consistent we use sy-tabix as we loop at internal table so this SY-TABIX points to the current record its reading...
we can use sy-index but rarely depends on condition.....
SY-INDEX and SY-TABIX will not be same always in LOOP and ENDLOOP
Rewards points if satisfied..
Regards
Narin Nandivada

Use of index based on an attribute when doing an order by

Hi,
I create a table and its indexes like this:
create table poc_wip2 of xmltype
xmlschema "http://www.derwent.co.uk/wpi.xsd" element "WPI"
alter table poc_wip2
add constraint poc_wip2_pk primary key
(XMLDATA."BibPt"."PDOC_COUNTRY",
XMLDATA."BibPt".pdoc_serial, XMLDATA."BibPt".pdoc_kind)
create index pan_index on poc_wip2 t
(extractvalue(value(t),'/WPI/BibPt/@pan'))
Now when I run the query:
select extractvalue(value(t),'/WPI/BibPt/@pan')
from poc_wip2 t
order by extractvalue(value(t),'/WPI/BibPt/@pan')
I can see that a full table scan occurs. I cannot get the query to use the index built on the pan attribute.
I tried adding a INDEX_FFS hint, but this does not work when I name the pan_index, it only works with
INDEX_FFS(t), in which case the query then uses the primary key index.
Is it possible to get the query to use the pan_index index?
Thanks
Pete

Hi
Create a restricted key figure with the ZSE_BPNV1 and mention the values of the attribute and display the values
Here you can mention your charecteristic and attrribute value both with the key figure
Assign points if useful
Regards
N Ganesh

Use of substr function will avoid the use of indexes in a table

i have one table which will contain some 3,00,000 records, it contains some 11 primary keys i am using some update statements to update some fields in the records (of 3,00,000 i will compare some 1,50,000 records with 1,50,000 another records) i am using substr function in all the select statements. whether usage of substr function will avoid the use of index
can any one clarify?

contains some 11 primary keys by this I suppose you mean to say the table has a composite PK on 11 columns.
i am using substr function in all the select statementsCould you please post your SQL statement?

How to make use of Index of a table in report to fetch data?

Hi,
I need a sample code for select statement which is making use of INDEX of a table
to fetch data.
Doubt:
Can I fetch all the fields in the table by passing certain key fields of INDEX in where condition?

Hi Raja,
1) Mention the fields that you wish from database table (incase you don't need all the fields from the database table).
2) Don't use the INTO CORRESPONDING FIELDS OF TABLE ztable clause.
3)Instead use INTO TABLE ztable (But take care that during the declaration of the ztable, the fields declared are in order that in database table to fetch the Records in sequence).
Please Find the Syntax and Code Below..
SELECT * FROM <TABLE>
WHERE <WHERE>
%_HINTS ORACLE 'INDEX("<TABLE>~<INDEX ID")'.
SELECT carrid
INTO TABLE t_spfli
FROM spfli
WHERE carrud IN s_carrid AND
connid IN s_connid
%_HINTS ORACLE 'INDEX("&SPFLI&" "SPFLI~XXX")'.
Hope this Is helpFul
Thanks
kalyan

Why is the Star Transformation using two indexes for the same dimension?

Hi,
Recently, I have made an investigation about the Star Transformation feature. I have found a strange test case, which plays an important role in my strategy for our overall DWH architecture. Here it is:
The Strategy:
I would like to have the classical Star Transformation approach (single column Bitmap Indexes for each dimension foreign key column in the fact table), together with additional Bitmap Join Indexes for some of the dimension attributes, which would benefit from the materialization of the join (bitmap merge operation will be skipped/optimized).
The query:
select dp.brand, ds. region_name, dc.region_name
     , count(*), sum(f.extended_price)
from fact_line_item f
     , dim_part       dp
     , dim_supplier   ds
     , dim_customer   dc
where dp.mfgr        = 10                 -- dimension selectivity = 1/10 --> acttual/fact selectivity = 6/10
   and f.part_dk      = dp.dk
   and ds.region_name = 'REGION #1' -- dimension selectivity = 1/9
   and f.supplier_dk = ds.dk
   and dc.region_name = 'REGION #1' -- dimension selectivity = 1/11
   and f.customer_dk = dc.dk
group by dp.brand, ds. region_name, dc.region_name
The actual plan:
| Id | Operation                              | Name                        | Starts | E-Rows | Cost (%CPU)| A-Rows |   A-Time   | Buffers | Reads |
|   0 | SELECT STATEMENT                       |                             |      1 |        | 3247 (100)|      1 |00:01:42.05 |     264K|    220K|
|   1 | HASH GROUP BY                         |                             |      1 |      2 | 3247   (1)|      1 |00:01:42.05 |     264K|    220K|
|* 2 |   HASH JOIN                            |                             |      1 | 33242 | 3037   (1)|    217K|00:01:29.67 |     264K|    220K|
|* 3 |    TABLE ACCESS FULL                   | DIM_SUPPLIER                |      1 |   1112 |   102   (0)|   1112 |00:00:00.01 |     316 |      4 |
|* 4 |    HASH JOIN                           |                             |      1 | 33245 | 2934   (1)|    217K|00:01:29.10 |     264K|    220K|
|* 5 |     TABLE ACCESS FULL                  | DIM_CUSTOMER                |      1 |    910 |   102   (0)|    910 |00:00:00.08 |     316 |      8 |
|* 6 |     HASH JOIN                          |                             |      1 | 33248 | 2831   (1)|    217K|00:01:28.57 |     264K|    220K|
|* 7 |      TABLE ACCESS FULL                 | DIM_PART                    |      1 |     10 |     3   (0)|     10 |00:00:00.01 |       6 |      0 |
|   8 |      PARTITION RANGE ALL               |                             |      1 | 36211 | 2827   (1)|    217K|00:01:28.01 |     264K|    220K|
|   9 |       TABLE ACCESS BY LOCAL INDEX ROWID| FACT_LINE_ITEM              |      6 | 36211 | 2827   (1)|    217K|00:01:33.85 |     264K|    220K|
| 10 |        BITMAP CONVERSION TO ROWIDS     |                             |      6 |        |            |    217K|00:00:07.09 |   46980 |   3292 |
| 11 |         BITMAP AND                     |                             |      6 |        |            |     69 |00:00:08.33 |   46980 |   3292 |
| 12 |          BITMAP MERGE                  |                             |      6 |        |            |    193 |00:00:02.09 |    2408 |   1795 |
| 13 |           BITMAP KEY ITERATION         |                             |      6 |        |            |   4330 |00:00:04.66 |    2408 |   1795 |
| 14 |            BUFFER SORT                 |                             |      6 |        |            |     60 |00:00:00.01 |       6 |      0 |
|* 15 |             TABLE ACCESS FULL          | DIM_PART                    |      1 |     10 |     3   (0)|     10 |00:00:00.01 |       6 |      0 |
|* 16 |            BITMAP INDEX RANGE SCAN     | FACT_LI__P_PART_DIM_KEY_BIX |     60 |        |            |   4330 |00:00:02.11 |    2402 |   1795 |
|* 17 |          BITMAP INDEX SINGLE VALUE     | FACT_LI__P_PART_MFGR_BJX    |      6 |        |            |   1747 |00:00:06.65 |     890 |    888 |
| 18 |          BITMAP MERGE                  |                             |      6 |        |            |    169 |00:00:02.78 |   16695 |    237 |
| 19 |           BITMAP KEY ITERATION         |                             |      6 |        |            |   5460 |00:00:01.56 |   16695 |    237 |
| 20 |            BUFFER SORT                 |                             |      6 |        |            |   5460 |00:00:00.02 |     316 |      0 |
|* 21 |             TABLE ACCESS FULL          | DIM_CUSTOMER                |      1 |    910 |   102   (0)|    910 |00:00:00.01 |     316 |      0 |
|* 22 |            BITMAP INDEX RANGE SCAN     | FACT_LI__P_CUST_DIM_KEY_BIX |   5460 |        |            |   5460 |00:00:02.07 |   16379 |    237 |
| 23 |          BITMAP MERGE                  |                             |      6 |        |            |    170 |00:00:03.65 |   26987 |    372 |
| 24 |           BITMAP KEY ITERATION         |                             |      6 |        |            |   6672 |00:00:02.23 |   26987 |    372 |
| 25 |            BUFFER SORT                 |                             |      6 |        |            |   6672 |00:00:00.01 |     316 |      0 |
|* 26 |             TABLE ACCESS FULL          | DIM_SUPPLIER                |      1 |   1112 |   102   (0)|   1112 |00:00:00.01 |     316 |      0 |
|* 27 |            BITMAP INDEX RANGE SCAN     | FACT_LI__S_SUPP_DIM_KEY_BIX |   6672 |        |            |   6672 |00:00:02.74 |   26671 |    372 |
The Question:
Why is the Star Transformation using both indexes FACT_LI__P_PART_DIM_KEY_BIX and FACT_LI__P_PART_MFGR_BJX for the same dimension criteria (dp.mfgr = 10)?? The introduction of the additional Bitmap Join Index actually make Oracle to do the work twice !!!
Anybody, any idea ?!?

Dom, here it is the plan with the predicates:
| Id | Operation                              | Name                        | Starts | E-Rows | Cost (%CPU)| A-Rows |   A-Time   | Buffers | Reads |
|   0 | SELECT STATEMENT                       |                             |      1 |        | 3638 (100)|      1 |00:06:41.17 |     445K|    236K|
|   1 | HASH GROUP BY                         |                             |      1 |      2 | 3638   (1)|      1 |00:06:41.17 |     445K|    236K|
|* 2 |   HASH JOIN                            |                             |      1 | 33242 | 3429   (1)|    217K|00:08:18.02 |     445K|    236K|
|* 3 |    TABLE ACCESS FULL                   | DIM_SUPPLIER                |      1 |   1112 |   102   (0)|   1112 |00:00:00.03 |     319 |    313 |
|* 4 |    HASH JOIN                           |                             |      1 | 33245 | 3326   (1)|    217K|00:08:17.47 |     445K|    236K|
|* 5 |     TABLE ACCESS FULL                  | DIM_CUSTOMER                |      1 |    910 |   102   (0)|    910 |00:00:00.01 |     319 |    313 |
|* 6 |     HASH JOIN                          |                             |      1 | 33248 | 3223   (1)|    217K|00:08:16.63 |     445K|    236K|
|* 7 |      TABLE ACCESS FULL                 | DIM_PART                    |      1 |     10 |     3   (0)|     10 |00:00:00.01 |       6 |      0 |
|   8 |      PARTITION RANGE ALL               |                             |      1 | 36211 | 3219   (1)|    217K|00:08:16.30 |     445K|    236K|
|   9 |       TABLE ACCESS BY LOCAL INDEX ROWID| FACT_LINE_ITEM              |      6 | 36211 | 3219   (1)|    217K|00:08:40.89 |     445K|    236K|
| 10 |        BITMAP CONVERSION TO ROWIDS     |                             |      6 |        |            |    217K|00:00:32.00 |   46919 | 19331 |
| 11 |         BITMAP AND                     |                             |      6 |        |            |     69 |00:00:34.50 |   46919 | 19331 |
| 12 |          BITMAP MERGE                  |                             |      6 |        |            |    193 |00:00:00.58 |    2353 |      1 |
| 13 |           BITMAP KEY ITERATION         |                             |      6 |        |            |   4330 |00:00:00.10 |    2353 |      1 |
| 14 |            BUFFER SORT                 |                             |      6 |        |            |     60 |00:00:00.01 |       6 |      0 |
|* 15 |             TABLE ACCESS FULL          | DIM_PART                    |      1 |     10 |     3   (0)|     10 |00:00:00.01 |       6 |      0 |
|* 16 |            BITMAP INDEX RANGE SCAN     | FACT_LI__P_PART_DIM_KEY_BIX |     60 |        |            |   4330 |00:00:00.07 |    2347 |      1 |
|* 17 |          BITMAP INDEX SINGLE VALUE     | FACT_LI__P_PART_MFGR_BJX    |      6 |        |            |   1747 |00:01:23.64 |     882 |    565 |
| 18 |          BITMAP MERGE                  |                             |      6 |        |            |    169 |00:00:09.14 |   16697 |   7628 |
| 19 |           BITMAP KEY ITERATION         |                             |      6 |        |            |   5460 |00:00:02.19 |   16697 |   7628 |
| 20 |            BUFFER SORT                 |                             |      6 |        |            |   5460 |00:00:00.01 |     316 |      0 |
|* 21 |             TABLE ACCESS FULL          | DIM_CUSTOMER                |      1 |    910 |   102   (0)|    910 |00:00:00.01 |     316 |      0 |
|* 22 |            BITMAP INDEX RANGE SCAN     | FACT_LI__P_CUST_DIM_KEY_BIX |   5460 |        |            |   5460 |00:00:08.78 |   16381 |   7628 |
| 23 |          BITMAP MERGE                  |                             |      6 |        |            |    170 |00:00:21.46 |   26987 | 11137 |
| 24 |           BITMAP KEY ITERATION         |                             |      6 |        |            |   6672 |00:00:10.29 |   26987 | 11137 |
| 25 |            BUFFER SORT                 |                             |      6 |        |            |   6672 |00:00:00.01 |     316 |      0 |
|* 26 |             TABLE ACCESS FULL          | DIM_SUPPLIER                |      1 |   1112 |   102   (0)|   1112 |00:00:00.01 |     316 |      0 |
|* 27 |            BITMAP INDEX RANGE SCAN     | FACT_LI__S_SUPP_DIM_KEY_BIX |   6672 |        |            |   6672 |00:00:20.94 |   26671 | 11137 |
Predicate Information (identified by operation id):
   2 - access("F"."SUPPLIER_DK"="DS"."DK")
   3 - filter("DS"."REGION_NAME"='REGION #1')
   4 - access("F"."CUSTOMER_DK"="DC"."DK")
   5 - filter("DC"."REGION_NAME"='REGION #1')
   6 - access("F"."PART_DK"="DP"."DK")
   7 - filter("DP"."MFGR"=10)
15 - filter("DP"."MFGR"=10)
16 - access("F"."PART_DK"="DP"."DK")
17 - access("F"."SYS_NC00017$"=10)
21 - filter("DC"."REGION_NAME"='REGION #1')
22 - access("F"."CUSTOMER_DK"="DC"."DK")
26 - filter("DS"."REGION_NAME"='REGION #1')
27 - access("F"."SUPPLIER_DK"="DS"."DK")
Note
   - star transformation used for this statement

Which to use - Sy-index or sy-tabix ??

Similar Messages

Maybe you are looking for