Transport of secondary index on /BIC/P table

Hi All,
I have created a secondary index on '/BIC/P table and it is not allowing me to assign a transport object as the table itself is temporary and it gets created automatically in the target system when we activate the info-object.
Is there any way to transport the secondary index directly on the /BIC/P table ?
Its urgent.
Thanks
Soumya

Soumya,
Sorry for not being clear enough: you can change the package of this index and transport it but since the P table could be regenerated automatically by the BW application when you change your IObj you may now get into troubles when importing a change.
Indeed having now a local $TMP table with a non-local object underneath may not please your target system and even not your DEV system...
One can always bypass SAP BW application; for instance creating indexes directly in the database; but this is at its own risk!
hoping this will explain a bit further your issue
Olivier.

Similar Messages

Secondary Index on ODS Change Table

Hi All,
We have a process that does a lookup to the change table /bic/XXXX40 in the update rules while loading the ODS. We are having performance problems that can be resolved by putting a secondary index on the change table. We are able to create the index in the Dev env using SE11, but we can't put it in a package other than $TMP. Putting a secondary index on the ODS in the normal way didn't put the index on the change table so that doesn't help us.
Any ideas on how we can get our new index into a package that we can transport?
Thanks in advance!

Just echoing Jorge's post - you'll need to open Prod and create it there, same is if you were creating secondary indices on master data tables or dimension tables, since the wkbench doesn't support creating indices on them either.
PS.
Put yourself on the SDN world map (http://sdn.idizaai.be/sdn_world/sdn_world.html) and earn 25 points.
Spread the wor(l)d!

Can we create secondary index for a cluster table

hi
can we create secondary index for a cluster table

Jyothsna,
There seems to be some kind of misunderstanding here. You <i>cannot</i> create a secondary index on a cluster table. A cluster table does not exist as a separate physical table in the database; it is part of a "physical cluster". In the case of BSEG for instance, the physical cluster is RFBLG. The only fields of the cluster table that also exist as fields of the physical cluster are the leading fields of the primary key. Taking again BSEG as the example, the primary key includes the fields MANDT, BUKRS, BELNR, GJAHR, BUZEI. If you look at the structure of the RFBLG table, you will see that it has primary key fields MANDT, BUKRS, BELNR, GJAHR, PAGENO. The first four fields are those that all cluster tables inside BSEG have in common. The fifth field, PAGENO, is a "technical" field giving the sequence number of the current record in the series of cluster records sharing the same primary key.
All the "functional" fields of the cluster table (for BSEG this is field BUZEI and everything beyond that) exist only inside a raw binary object. The database does not know about these fields, it only sees the raw object (the field VARDATA of the physical cluster). Since the field does not exist in the database, it is impossible to create a secondary index on it. If you try to create a secondary index on a cluster table in transaction SE11, you will therefore rightly get the error "Index maintenance only possible for transparent tables".
Theoretically you could get around this by converting the cluster table to a transparent table. You can do this in the SAP dictionary. However, in practice this is almost never a good solution. The table becomes much larger (clusters are compressed) and you lose the advantage that related records are stored close to each other (the main reason for having cluster tables in the first place). Apart from the performance and disk space hit, converting a big cluster table like BSEG to transparent would take extremely long.
In cases where "indexing" of fields of a cluster table is worthwhile, SAP has constructed "indexing tables" around the cluster. For example, around BSEG there are transparent tables like BSIS, BSAS, etc. Other clusters normally do not have this, but that simply means there is no reason for having it. I have worked with the SAP dictionary for over 12 years and I have never met a single case where it was necessary to convert a cluster to transparent.
If you try to select on specific values of a non-transparent field in a cluster without also specifying selections for the primary key, then the database will have to do a serial read of the whole physical cluster (and the ABAP DB interface will have to decompress every single record to extract the fields). The performance of that is monstrous -- maybe that was the reason of your question. However, the solution then is (in the case of BSEG) to query via one of the index tables (where you are free to create secondary indexes since those tables are transparent).
Hope this clarifies things,
Mark

Need help in using a Secondary Index of a GL Table

Hello ABAPers,
Good morning/afternoon!
I was wondering if anyone could give me a hand on this issue.
To give you a brief background, I need to retrieve Open and Cleared items in the last 24 hours, that is, from 11 am yesterday till 10:59:59 today. The criteria is to pull the information using Entry Date (CPUDT) and Entry Time (CPUTM) from BKPF and using BELNR, retrieve the postings in BSIS and BSAS. as you can see in the piece of code. However, this process takes soooooo long to run.
Below is the code snippet.
We use 46C and MS SQL database.
The index fields of BKPF~ZB2 are: MANDT, CPUDT and BLART.
The index fields of BSIS~Z01are: BUKRS, GJAHr, HKONT, PRCTR, GSBER
TYPES: BEGIN OF i_bseg,
       bukrs LIKE bkpf-bukrs,
       hkont LIKE bsis-hkont,
       gjahr LIKE bkpf-gjahr,
       belnr LIKE bkpf-belnr,
       buzei LIKE bsis-buzei,
       bldat LIKE bsis-bldat,
       budat LIKE bsis-budat,
       waers LIKE bsis-waers,
       monat LIKE bsis-monat,
       shkzg LIKE bsis-shkzg,
       gsber LIKE bsis-gsber,
       dmbtr LIKE bsis-dmbtr,
       wrbtr LIKE bsis-wrbtr,
       cpudt LIKE bkpf-cpudt,
       cputm LIKE bkpf-cputm,
       END OF i_bseg.
*Internal Tables
DATA:
      i_bkpf TYPE TABLE OF bkpf,
      i_bseg TYPE STANDARD TABLE OF i_bseg.
Select records from yesterday's entry date.
    SELECT bukrs belnr gjahr monat budat cpudt cputm waers
            FROM bkpf INTO CORRESPONDING FIELDS OF TABLE i_bkpf
            WHERE ( cpudt = so_date2-low AND
                    cputm >= so_cputm-low AND
                    cputm <= so_cputm-high )
            OR    ( cpudt = so_date2-high AND
                    cputm >= so_time2-low AND
                    cputm <= so_time2-high )
            %_HINTS MSSQLNT 'INDEX("BKPF" "BKPF~ZB2")'.
    IF sy-subrc NE 0.
      MESSAGE e006 WITH 'BKPF'.
    ENDIF.
Select Open Items***
    SELECT bukrs hkont gjahr belnr buzei budat bldat
           waers monat shkzg gsber dmbtr wrbtr
           FROM bsis
           APPENDING CORRESPONDING FIELDS OF TABLE i_bseg
           FOR ALL ENTRIES IN i_bkpf
           WHERE bukrs = i_bkpf-bukrs
           AND gjahr = i_bkpf-gjahr
           AND hkont IN so_saknr
           AND belnr = i_bkpf-belnr
           %_HINTS MSSQLNT 'INDEX("BSIS" "BSIS~Z01")'.
Also get any cleared items ***
    SELECT bukrs hkont gjahr belnr buzei budat bldat
           waers monat shkzg gsber dmbtr wrbtr
           FROM bsas
           APPENDING CORRESPONDING FIELDS OF TABLE i_bseg
           FOR ALL ENTRIES IN i_bkpf
           WHERE bukrs IN so_bukrs
           AND   hkont IN so_saknr
           AND   gjahr = sp_gjahr
           AND   belnr = i_bkpf-belnr.
Many thanks,
Rosemarie

Thanks for your response.
The date and time fields are defined in my selection screen and the default values pre-set in the INITIALIZATION, so the dates and times are already stored as a range.
The problem is why is the process taking so long. Is the syntax for the INDEX correct?
PARAMETERS:p_not RADIOBUTTON GROUP pass.
SELECT-OPTIONS:
so_date2 FOR bkpf-cpudt,         " Entry Date
so_cputm FOR sy-uzeit,         " Entry Time
so_time2 for sy-uzeit.        " Entry Time 2
INITIALIZATION.
RANGES: so_time2 FOR sy-uzeit.
g_date = sy-datum - 1.
g_year = sy-datum+0(4).
sp_gjahr = g_year.
CONCATENATE sp_gjahr '0101' INTO g_from_date.
g_from_time = '110000'.
g_24_hour   = '235959'.
g_time_diff = g_24_hour - g_from_time.
g_to_time = g_from_time + g_time_diff.
g_to_time2 = g_from_time - 1.
MOVE: 'I'      TO so_cpudt-sign,
        'BT'     TO so_cpudt-option,
        g_from_date   TO so_cpudt-low,
        sy-datum TO so_cpudt-high.
APPEND so_cpudt.
MOVE: 'I'      TO so_date2-sign,
        'BT'     TO so_date2-option,
        g_date   TO so_date2-low,
        sy-datum TO so_date2-high.
APPEND so_date2.
MOVE: 'I'         TO so_cputm-sign,
        'BT'        TO so_cputm-option,
        g_from_time TO so_cputm-low,
        g_to_time   TO so_cputm-high.
APPEND so_cputm.
MOVE: 'I'         TO so_time2-sign,
        'BT'        TO so_time2-option,
        '000000'    TO so_time2-low,
         g_to_time2 TO so_time2-high.
APPEND so_time2.

Regarding Secondary Index in a Table

hi
if i create a secondary index in a table is it obligatory or optional to have first field as MANDT (Client field) if the table is client dependent & how many secondary indexes(MAXIMUM) can be created for a table.
Regards

Hi,
Check the below Link
How to transport a secondary index on P master data table?
Hope this helps you.
Regards,
Anki Reddy

Is it worth creating secondary index on BKPF table ?

Hello,
One of my clients is using ECC version 5.0. I have a requirement wherein I need to fetch the data from BKPF table based on AWKEY, BUKRS and GJAHR. There is no standard secondary index available.
I have decided to create a secondary index on these fields in the following order:
1) MANDT
2) AWKEY
3) BUKRS
4) GJAHR
I know that creating secondary indexes does improve performance during data retrieval. But when I checked the total number of entries in BKPF table in production system, there are more than 20 lac 2 million records.
I am worried that creation of secondary index will create another table of such a large size in production that has data sorted on the above fields. Also, the RAM of production system is 6 GB.
Please suggest if creation of secondary index is a good measure OR should I recommend the client to increase the system RAM?
Regards,
Danish.
Edited by: Thomas Zloch on Oct 3, 2011 3:01 PM

Hi,
Secondary Index on BKPF-AWKEY has been successfully created in production. The report which used to timeout in foreground as well as in background is now executing in less than 10 seconds !!
Client is very much satisfied with this. But, there is one problem that we are facing now is that when the user is changing an existing billing document via VF02, on SAVE, system takes a very long time to save the changes done.
We monitored the processes via SM50 and found that there was a sequential read on BKPF table.
Before transporting the index in production, system approximately took not more than 5 seconds to save the Billing Document. But now system takes more than 20 minutes just to save the billing document via VF02.
I really don't know what has gone wrong. I can't figure out if I have missed any step while creating the index.
I did the following,
1) Created a Secondary index on BKPF, saved it in the transport request and activated it. Since the index was not existing in database ORACLE, I activated and adjusted the table via SE14. Now, index exists on database as well. Working perfectly in development.
2) Imported the transport request to Production. Checked in SE11. Index was existing and active. Also, index existed in database ORACLE.
Have I missed anything ? Is it required to activate and adjust the database via SE14 in production too ?
Regards,
Danish.

Creation of secondary index on RSPCPROCESSLOG table

Hello guys,
We have detected severe performance issues while executing the transaction ST03n in our BW 3.5 System.
Looking in the OSS notes we found the note "SAP Note 841324 - ST03N: poor performance for process chain profile" where it recommends the creation of a secondary index in the table RSPCPROCESSLOG with the following features:
Create another secondary index on the RSPCPROCESSLOG table with the
following fields:
- INSTANCE
- TYPE
Can you please let us know what is the step by step to proceed with the creation of this secondary index?
Thanks for your help.
Kind regards

Please ask questions about Oracle Text (formerly interMedia text) in the Oracle Text forum. You will get a quicker, more expert answer there.

Secondary index on aggregate table and cube

Hi to all,
I have small doubt.
1. Primary index created in F and E table of CUBE by system.
then how secondary index in created in F and E table of cube,
or
is that B* tree index created as secondary index on F/E table of cube, when we use process type create / deleted index in PC for CUBE
or if we do manually under performance tab for cube.
2. Primary index also created on F and E table of aggregate by system.
then how secondary index in created in F and E table of aggregate,
or
is that B* tree index created as secondary index on F/E table of aggregate, when we use process type create / deleted index in PC for CUBE
or if we do manually under performance tab for aggregate
Regards
Pavneet Rana

Hi,
Thru process chains you can't handle them.
You can do it by manual with help basis or ABAP team.
BW server--> T code SE11, Select table - Enter table name and display it.
On next screen on tool bar you can see indexes --> click on it.
Thanks

How to transport Secondary Index, If I created it via DB02-directly on DB?

Hi Experts,
For curiosity, wuld like to know that,
How to transport the Secondary Index, If I created it via DB02 i.e. directly on DB?
thanq.

Hi srikhar,
1. How to transport the Secondary Index, If I created it via DB02 i.e. directly on DB?
Now, There is no question of transport,
bcos what u will transport.
We can only transport objects which
are created from r/3 data dictionary etc.
regards,
amit m.

How many SECONDARY INDEXES are created for CLUSTER TABLES?

how many SECONDARY INDEXES are created for CLUSTER TABLES?
please explain.

There seems to be some kind of misunderstanding here. You cannot create a secondary index on a cluster table. A cluster table does not exist as a separate physical table in the database; it is part of a "physical cluster". In the case of BSEG for instance, the physical cluster is RFBLG. The only fields of the cluster table that also exist as fields of the physical cluster are the leading fields of the primary key. Taking again BSEG as the example, the primary key includes the fields MANDT, BUKRS, BELNR, GJAHR, BUZEI. If you look at the structure of the RFBLG table, you will see that it has primary key fields MANDT, BUKRS, BELNR, GJAHR, PAGENO. The first four fields are those that all cluster tables inside BSEG have in common. The fifth field, PAGENO, is a "technical" field giving the sequence number of the current record in the series of cluster records sharing the same primary key.
All the "functional" fields of the cluster table (for BSEG this is field BUZEI and everything beyond that) exist only inside a raw binary object. The database does not know about these fields, it only sees the raw object (the field VARDATA of the physical cluster). Since the field does not exist in the database, it is impossible to create a secondary index on it. If you try to create a secondary index on a cluster table in transaction SE11, you will therefore rightly get the error "Index maintenance only possible for transparent tables".
Theoretically you could get around this by converting the cluster table to a transparent table. You can do this in the SAP dictionary. However, in practice this is almost never a good solution. The table becomes much larger (clusters are compressed) and you lose the advantage that related records are stored close to each other (the main reason for having cluster tables in the first place). Apart from the performance and disk space hit, converting a big cluster table like BSEG to transparent would take extremely long.
In cases where "indexing" of fields of a cluster table is worthwhile, SAP has constructed "indexing tables" around the cluster. For example, around BSEG there are transparent tables like BSIS, BSAS, etc. Other clusters normally do not have this, but that simply means there is no reason for having it. I have worked with the SAP dictionary for over 12 years and I have never met a single case where it was necessary to convert a cluster to transparent.
If you try to select on specific values of a non-transparent field in a cluster without also specifying selections for the primary key, then the database will have to do a serial read of the whole physical cluster (and the ABAP DB interface will have to decompress every single record to extract the fields). The performance of that is monstrous -- maybe that was the reason of your question. However, the solution then is (in the case of BSEG) to query via one of the index tables (where you are free to create secondary indexes since those tables are transparent).

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

Maximum Number fields in a secondary index key

Hello All,
We created a secondary index on BSIS which we had to drop as system was hung up. My question is how many fileds SAP recommends in a secondary index key? Ours had 6 keys including mandt.
Thanks

Hi Sameer,
There is no real specification in number of fields for an index as fas as i know. Definitely 6 fields is allowed for a secondary
index.But it really matters with the number of secondary indices. So dont create too many secondary index for a single table.
Try to use other optimization techniques in the programming instead of creating secondary index.
//Kothand

Help me with Points to be noted While creating a Secondary Index.

Hi,
There is a Secondary index created on a Z table which already have 9 secondary indexes. This is the 10th index that is created.
The Index is created as follows
MANDT             Client
DOCNUM_REF     Document number
The Table data is huge and it is more than 4Lakh records.
I have done the following analyses.
1) The fields to be used are not in any other indexes.
2) The Data is mostly different, i.e. The document reference field is having distinct data
select a~docnum a~werks_o a~docnum_ref a~natop
         a~m_icms a~m_ipi
         b~lgort_out b~mov_est
         b~item b~matnr
    appending table ti_requisicoes
    from zsytmm_reqnfcb as a
   inner join zsytmm_reqnfit as b
      on a~branch_o eq b~branch_o
     and a~requi    eq b~requi
     and a~mask     eq b~mask
     for all entries in ti_doc_saida_del
   where a~docnum_ref   eq ti_doc_saida_del-docnum.
What else I need to check , so that the index improves the performance. The table is using in 300 reports.

Ravishankar Lanjewar wrote:
@SAP LEARNER,
>
> There is a Secondary index created on a Z table which already have 9 secondary
> indexes. This is the 10th index that is created.
>
>
> I will not recommand to create index any more on this table. If you want to create secondary index for on above table which you have mention. You don't create index only for hamper of performance of single program/report.
>
> Don't create more than 4 to 5 index on sinlge table.
>
> Refere the tread Link:[Why to create Secondary index ?|Re: When is a secondary index used (in select or where)]
Sounds like another myth that is widely spread across SAP community.
Remember, complex systems like modern DBMS do not like generalizations. I personally know standard SAP tables with 9 standard secondary indexes. In the meantime the hardware became fast enough to update several secondary indexes without really significant problems. Of course indexes require space, of course one should create indexes that are not similar and differ from each other with more than one field for example. In other words, think before creating!
But it's again incorrect to say "do not create because you already have 9 others". You did not even ask what fields are in the affected table, what are the existing indexes.
Ravishankar Lanjewar wrote:
> I will recommand to delete all the index and create 4 to 5 fresh index while doing analysis for all SQL statement using where use list depends on where condition of SQL.
I am now trying to imagine the effort to analyze 300 reports using this table and all corresponding selects. And probably you will drop supporting indexes for several reports. Some of them may be CEO/CFO-relevant reports that will run minutes/hours instead of seconds. And I would like to see the reaction of CEO when he finds out that it was the result of your "optimization" activities.

How to use secondary index

Hi abapers,
Iam creating secondary index for the database table MSEG. ....How to write select query for the secondary index that i have created..
Regards,
Ramya

how to create secondary index in tables
https://forums.sdn.sap.com/click.jspa?searchID=933015&messageID=2971112
Guidelines to create secondary index
https://forums.sdn.sap.com/click.jspa?searchID=933015&messageID=2009801
Secondary index;
http://help.sap.com/saphelp_47x200/helpdata/en/cf/21eb2d446011d189700000e8322d00/content.htm
this will definitely help you, dont forget to award points if found helpful

Transaction DB02 = Missing Tables and Indexes shows under Secondary indexes from package $tmp

Hi SAP Gurus,
I noticed on our SAP business warehouse (BW) system (NetWeaver 7.0 based on AIX/Oracle 11g) in transaction DB02 => Diagnostics => Missing Tables and Indexes under Secondary indexes, 26 indexes, in package $tmp:
The indexes are defined, but they don't have been created on the database.
When I try to create them via the database tool, I am getting the warning:
Does the warning raise up, because they where defined in the $tmp package?
I was looking in SAP notes for a solution for this "warning" concerning the /BIC/F-Indexes but I didn't found yet anything helpful ...
Thanks for your help and ideas ...
Best regards
Carlos

Hi Carlos,
These are secondary indexes created during process chains in BI to improvise performance.
You may refer below SCN blogs on creation of these indices in BI.
Secondary Index - Improving DSO insert/read performance
How to Create Secondary Index on DSO in SAP BW
Hope this helps.
Regards,
Deepak Kori

Transport of secondary index on /BIC/P table

Similar Messages

Maybe you are looking for