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

Similar Messages

Use secondary index in internal tables.

what are the uses of secondary index in internal table?

http://help.sap.com/saphelp_nw04/helpdata/en/cf/21eb47446011d189700000e8322d00/content.htm
Creating Secondary Indexes
Proceed as follows to create a secondary index on a table:
In the field maintenance screen for the table, choose Goto --> Indexes.
1. If you went to the field maintenance screen of the table in display mode, only correct the index (and not the table).
If indexes already exist on the table, a list of these indexes is displayed. Choose Create. A dialog box appears in which you must enter the three-place index identifier. If there are no indexes, go directly to the dialog box.
2. Enter the index identifier and choose Continue.
You will go to the maintenance screen for indexes.
3. Enter an explanatory short text in the field Short text.
Choose TabFields.
4. A list of all the fields of the table is displayed.
5. Select the fields which you want to copy to the index.
6. Choose Copy.
The selected fields are copied to the index.
7. If the values in the index fields already uniquely identify each record of the table, select Unique index.
A unique index is automatically created on the database during activation because a unique index also has a functional meaning (prevents double entries of the index fields).
8. If it is not a unique index, leave Non-unique index selected. In this case you can use the corresponding radio buttons to define whether the index should be created automatically on the database for all database systems, for selected database systems or for no database system.
9. If you chose For selected database systems, you must specify these systems.
You have two possibilities here:
List of inclusions: The index is only created automatically during activation for the database systems specified in the list. The index is not created on the database for the other database systems.
List of exclusions: The index is not created automatically on the database during activation for the specified database systems. The index is automatically created on the database for the other database systems.
Click on the arrow symbol behind the radio buttons. A dialog box appears in which you can define up to 4 database systems. Use the corresponding radio buttons to decide whether this list should be treated as a list of inclusions or exclusions.
10. Activate the index with Index ® Activate. The activation log tells you about the flow of the activation. Call it with Utilities ® Act.log. If an error occurred when activating the secondary index, you will automatically go to this log.
The secondary index is automatically created on the database during activation if the corresponding table has already been created there and index creation was not excluded for the database system.
Reward points if useful.

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

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 for the table MSEG

Hi folks,
One of my report is comparetively very slow when it is executed in the production server. when i chked, a query related to the MSEG table is taking more time to execute. I want to create a secondary index for that table. Could any body tell me the procedure of creating the seconday index for the table MSEG, as i am not aware of that.
Thanks in advance,
Shyam.

Dear shyam,
Search SDN before posting any thread their are 10k threads available for your question anyhow for your reference here is one link
http://help.sap.com/search/highlightContent.jsp
Cheers
fareed

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.

Secondary index on vbfa table

I have very expensive statement running against VBFA table. It comes from a customer report and doing SQL:
SELECT /*+ FIRST_ROWS */ "VBELV"
FROM "VBFA"
WHERE "MANDT" = :A0 AND "VBELN" = :A1 AND ROWNUM <= :A2
It has execution plan:
SELECT STATEMENT ( Estimated Costs = 96.009 , Estimated #Rows = 41 )
|
--- COUNT STOPKEY
|
INDEX RANGE SCAN VBFA~0
As you can see it is very expensive statement because VBFA is huge table and because I have only VBFA~0 index with columns:
UNIQUE Index VBFA~0
COLUMN DISTINCT VALUES
MANDT      1
VBELV       1.589.207
POSNV      4.184
VBELN       3.202.114
POSNN       58.173
VBTYP_N    18
In order to improve performance of this report , would you recomend creating secondary index and would it be on columns: MANDT, VBELN, VBELV
I have not seen this type of secondary index in SAP community (most of the time I see sec.index on mandt, vbeln and posnn columns) so that is why I want to double check it before I deploy it.
Regards,
Andrija

Hi,
Indexes speed up access to rows in a table. They can be created for a single column or for a series of columns.
MANDT AND VBELN does not have index then create indexes on these columns.
The explain statement can be used to check the effect of creating or deleting indexes (see index) on the choice of search strategy for the specified SQL statement. You can also estimate the time needed by the database system to process the specified SQL statement. The specified QUERY or SINGLE SELECT statement is not executed while the EXPLAIN statement is being executed.
To be frank to analyze you shd generate trace file and you need to analyze.
Oracle claims that <b>first_rows_n</b> optimization results in faster response time for certain queries, we must remember that the performance is achieved via a change to the costing.
Use the FIRST_ROWS hint when you need only the first few hits of a query. When you need the entire result set, do not use this hint as it might result in poorer performance.
So collect stats,Analyze table create index your query will execute faster.
Analyze in trace file generated.Want to know indexes are used or not have a look on Explain Plan.
Regards
Vinod

Checking a functional index on a table and its metadata

Hi,
I have a functional based normal index (unique) defined on a table which uses a decode function and a combination of the columns of a table.
Eg : decode (status, 'A', column1 || column 2, column1 || column2 || column3)
Now my question is, how do we query these functional indexes from the database to see what exactly the function is...
On the database when I run a query :-
select from all_indexes where index_name = :index_name,*
it retrieves the code name of the index stored as ncs$00025 (don't remember the exact value).
How do I find out what exactly the function is? (from which table)
and is there any way that I can query the data that has been indexed by this unique index so that I can verify why the unique constraint is being violated in some cases?
Thanks and Regards,
Suyash

how do we query these functional indexes from the database to see what exactly the function is...
select * from user_ind_expressions

Are fact tables and cubes same in OWB?

Dear all
A simple question. How can I create a star schema (that is, with a fact table and dimensions) using OWB?
OWB has options to create cubes, but as per my understanding a cube is not a fact table.
Cube contains pre-computed data where as fact table contains normal data with references to dimensions.
Please correct me if I am wrong.
thanks in advance

These are just different levels of abstraction.
"Cube" is the highest level of abstraction referring to the overall package of data.
"Star schema" is how cubes are modelled showing the relationships from a fact entity to the dimension entities.
Relational and OLAP are different methods of physical implementation.
In OWB, to promote sharing of dimensions across cubes to avoid inconsistency the idea is you define and build the dimensions independently. Then you define the "cubes" as measures and references to the dimensions. When you build the "cube" you pass in business identifiers from the source data which OWB will use to link the measures to the applicable dimension data. Due to the wonders of inner joins anyone reading the "cube" will only see dimension data related to the data in that cube!
Using OWB you do not need to be concerned with the physical implementation when you use the dimension and cube operators as those operators know what to do.

Aggregate table and outdated rows

hi everybody,
let´s assume the following scenario:
- one fact table, one aggregator, one target aggregate table with a sum column.
- aggregate table loading type is set to "insert/update", update matching is done on several columns.
- first load is started, aggregated data is correct, no problems so far
- one column is updated in the fact table (all rows)
- now we´ve got a new attribute set which doesn´t match a row at the aggregate table, so a new row is inserted
- the aggregate table now contains two rows, but only one is valid
how can i avoid this without truncating the aggregate table before loading? do i have to delete outdated aggregate rows before/after loading, or is there any other solution?
thanks for your help,
peter
Edited by: peter_AT on Nov 12, 2009 7:46 AM

>
Why can't you just update that collumn in your target table if you don't need the previous version of that row?
>
thanks for your suggestion.
but this can cause "ORA-30926: unable to get a stable set of rows in the source tables" - or am i wrong about this?
a more detailed explanation:
fact table t_src:
SQL> select * from t_src;
S1 S2
A   Bproperty "match column when updating row" on columns a1 and a2 of aggregation table t_agg are set to "Yes".
aggregate table t_agg contains these rows:
SQL> select * from t_agg;
A1 A2         NUM
A   B            1now t_src is updated:
SQL> update t_src set s1='B' where s1='A';
1 row updated.
SQL> select * from t_src;
S1 S2
B   Bafter the next load table t_agg looks like this:
SQL> select * from t_agg;
A1 A2         NUM
A   B            1
B   B            1if i want to update column A1, i have to remove matching from there - which leads to ORA-30926 when loading next time.
thanks,
peter
Edited by: peter_AT on Nov 12, 2009 7:47 AM

OBIEE bypasses smaller aggregate table and queries largest aggregate table

Hello,
Currently we are experiencing something strange regarding queries that are generated.
Scenario:
We have 1 detail table and 3 aggregate tables in the RPD. For this scenario I will only refer to 2 of the Aggregates.
Aggregate 1 (1 million rows):
Contains data - Division, Sales Rep, Month, Sales
Aggregate 2 (13 milliion rows):
Contains data - Division, Product, Month, Sales
Both tables are set at the appropriate dimension levels in the Business Model. Row counts have been updated in the physical layer in the RPD.
When we create an answers query that contains Division, Month and Sales, one would think that OBIEE would query the smaller and faster of the two tables. However, obiee wants to query the table with 13 million records completely bypassing the smaller table. If we make the larger aggregate inactive, then OBIEE queries the smaller table. We can't figure out why OBIEE wants to immediately go to the larger table.
Has anyone experienced something such as this? Any help would be greatly appreciated.
Edited by: gwb on Aug 19, 2009 7:45 AM

Have you try to change the sort order of the logical table source in your logical table ?
!http://gerardnico.com/wiki/_media/temp/obiee_logical_table_sources_sort.jpg!
Set the Aggregate 1 first.
Cheers
Nico

Why do we create indexes for DSOs and Cubes.What is the use of it?

Hi All,
Can you please tell me why are indexes created for DSOs and Cubes.
What is the use with the creation of indexes.
Thanks,
Sravani

HI ,
An index is a copy of a database table that is reduced to certain fields. This copy is always in sorted form. Sorting provides faster access to the data records of the table, for example, when using a binary search. A table has a primary index and a secondary index. The primary index consists of the key fields of the table and is automatically created in the database along with the table. You can also create further indexes on a table in the Java Dictionary. These are called secondary indexes. This is necessary if the table is frequently accessed in a way that does not take advantage of the primary index. Different indexes for the same table are distinguished from one another by a separate index name. The index name must be unique. Whether or not an index is used to access a particular table, is decided by the database system optimizer. This means that an index might improve performance only with certain database systems. You specify if the index should be used on certain database systems in the index definition. Indexes for a table are created when the table is created (provided that the table is not excluded for the database system in the index definition). If the index fields represent the primary keys of the table, that is, if they already uniquely identify each record of the table, the index is referred to as an unique index.
they are created on DSO and cube for the performance purpose ..and reports created on them wil be also more efficent ..
Regards,
shikha

Difference between primary eindex and secondary index?

hi experts
pls answer me
difference between primary eindex and secondary index?
rewads apply.
thanks.
naresh.

hi,
check this link.
http://help.sap.com/saphelp_47x200/helpdata/en/cf/21eb2d446011d189700000e8322d00/frameset.htm
A difference is made between Primary & Secondary indexes to a table. the primary index consists of the key fields of the table and a pointer to the non-keys-fields of the table. The Primary index is generated automatically when a table is created and is created in the datebase as the same times as the table. It is also possible to define further indexes to a table in the ABAP/4 dictionary, which are then referred to as Secondary indexes.
Always it is not mandatory that an index should have all the key fields of a table. To see the index of a table
goto SE11->specify table name->click on the indexes... button on the application toolbar.
Based on your requirement you can you any of those index fields in the where clause of your query. Always its a better practice to use the index fields in the order specified. While selecting the records from a table it is always better to select the fields in the same order as specified in the table.

Buffering and creation of secondary indexes.

Hi All,
I have a table that has more than 6 million records, due to which performance is slow during the transaction search, kindly let me know if Buffering and creation of secondary indexes will help me.
I am given to understand that creation of seconary indexes and full buffering may not always improve performance. Kindly let me know when it is advised to go for full buffering.
Regards,
Thiru

Hi,
create secondary index for the table
check below link
http://help.sap.com/saphelp_nw70/helpdata/en/cf/21eb20446011d189700000e8322d00/content.htm
Regards,
Madhu

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

Secondary index on aggregate table and cube

Similar Messages

Maybe you are looking for