Can we create secondary indexes in pooled and cluster table?

hello all
can we create secondary indexes in pooled and cluster table?

Hi,
Yes, you can.
Refer the below links
[http://www.sap-img.com/abap/the-different-types-of-sap-tables.htm|http://www.sap-img.com/abap/the-different-types-of-sap-tables.htm]
[http://help.sap.com/saphelp_40b/helpdata/en/cf/21f083446011d189700000e8322d00/content.htm|http://help.sap.com/saphelp_40b/helpdata/en/cf/21f083446011d189700000e8322d00/content.htm]
Regards,
SB

Similar Messages

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 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).
Hope this clarifies things,
Mark

Which type of information can be hold by pool and cluster tables

hi experts tell me exactly which type of information hold by pooled and cluster tables
thanks in advance

Hi
I hope, you know that Rewarding with Points for the Useful answers is the SDN policy
Pooled table
Pooled tables can be used to store control data (e.g. screen sequences,
program parameters or temporary data). Several pooled tables can be
combined to form a table pool. The table pool corresponds to a physical
table on the database in which all the records of the allocated pooled
tables are stored.
Cluster table
Cluster tables contain continuous text, for example documentation.
Several cluster tables can be combined to form a table cluster. Several
logical lines of different tables are combined to form a physical record
in this table category. This permits object-by-object storage or
object-by-object access. In order to combine tables in clusters, at
least part of the keys must agree. Several cluster tables are stored in
one corresponding table on the database.
Pool Tables (match codes, look up tables)
Should be accessed via primary key or
Should be buffered (SE11->Display Table->technical settings)
No secondary indexes
Select * is Ok because all columns retrieved anyway
Cluster Tables (BSEG,BSEC)
Should be accessed via primary key - very fast retrieval otherwise very slow
No secondary indexes
Select * is Ok because all columns retrieved anyway. Performing an operation on multiple rows is more efficient than single row operations. Therefore you still want to select into an internal table. If many rows are being selected into the internal table, you might still like to retrieve specific columns to cut down on the memory required.
Statistical SQL functions (SUM, AVG, MIN, MAX, etc) not supported
Can not be buffered
Reward points for useful Answers
Regards
Anji

What is the differences between Transparent,Pooled and Cluster tables?

Hello all,
What is Pool table?What is the differences between Transparent,Pooled and Cluster tables?
Regards!
Purna

Transparent table:
Tables can be defined independently of the database in the ABAP Dictionary. The fields of the table are defined together with their (database-independent) data types and lengths.
A table definition in the ABAP Dictionary has the following components:
Table fields: The field names and the data types of the fields contained in the table are defined here.
Foreign keys: The foreign keys define the relationships between this table and other tables.
Technical settings: The technical settings define how the table is created on the database.
Indexes: Indexes can be defined for the table to speed up data selection from the table.
There are three categories of database tables in the ABAP Dictionary.
A physical table definition is created in the database for the table definition stored in the ABAP Dictionary for transparent tables when the table is activated. The table definition is translated from the ABAP Dictionary to a definition of the particular database.
On the other hand, pooled tables and cluster tables are not created in the database. The data of these tables is stored in the corresponding table pool or table cluster. It is not necessary to create indexes and technical settings for pooled and cluster tables.
Pooled table
Pooled tables can be used to store control data (e.g. screen sequences, program parameters or temporary data). Several pooled tables can be combined to form a table pool. The table pool corresponds to a physical table on the database in which all the records of the allocated pooled tables are stored.
Cluster table
Cluster tables contain continuous text, for example, documentation. Several cluster tables can be combined to form a table cluster. Several logical lines of different tables are combined to form a physical record in this table type. This permits object-by-object storage or object-by-object access. In order to combine tables in clusters, at least parts of the keys must agree. Several cluster tables are stored in one corresponding table on the database.
Regds,
Manohar

Replicating Pool and Cluster tables in HANA

Hi,
Has anyone been able to successfully replicate the Pool and Cluster tables to HANA? I browsed around but am not able to find any solid material/documents related to the same. Please point me to the same.
yogesh

Hi Yogesh,
Maybe you skiped this one. The sample uses BSEG from cluster RFBLG and it's very well explained by Tobias Koebler
How to enable parallel replication
Regards, Fernando Da Rós

Where we can use pooled and cluster tables.

Hi Experts,
I have read all the threads and tutorials. all are telling like the difference between pooled and clulster tables are
Pooled table
It can hold small amount of data ( 10 to 100 records) and large number of tables( 100 to 1000 tables). It has fixed structure like Tabname, Varkey, Datain, Vardata.
Cluter tables
It can hold large amount of data but small number of tables. It is also have fixed strucuter like CLKEY1,CLKEY2 , CLKEY3...., Pageno, Timestamp, Pagelg, Vardata.
But i want which situation we can choose pooled table and which situation we can choose cluster table. In general way or Business way.
Thank you,
Srinivas M
Edited by: Srinivas Marapureddy on May 11, 2010 4:39 PM

>
El Tony wrote:
> Those table to manage big data volume, for example BSEG is a cluster table, this help to database for store the data in little amount. Instead the Pooled Table to store the table in other table, so that this help to database for store the data too but in more little amount.
>
> In Background ABAP to control this, because there are source code that help to show the data complete, but in the databse the data is store with alphanumerics. This is a advantage for the database.
Let me correct you, the data is not stored in alphanumeric but in RAW format in pool & cluster tables.
SAP says pool & cluster tables are created so that data from different tables belonging containing similar kind of data are clubbed together. I am not sure if storing data in RAW format compresses its size but SAP recommends storing business data in transperant tables.
Quote from SAP documentation:
"Data of commercial relevance is usually stored in transparent tables."
If data compression were a significant point SAP would have stored data in table clusters & not in transperant tables.
Comments are welcome.
BR,
Suhas

How to create secondary indexes in DB2e from MI

Hello,
we need to create secondary indexes in the DB2e SyncBO tables for a SynBO containing several thousands entries.
We create it manually and works fine, but we have to distribute
this to every user (about 300).
Is there a way to distribuite this index creation for an
application from a central location (WebConsole)?
Or,
is there any attribute in the SyncBO definitions for creating indexes on selected fields in teh database?
Thanks in advance and best regards,
Angel

Hi,
I found the way to create the indexes. In the metadata
function of the SyncBO builder, you can mark any field
as index (either in the header or in the detail tables).
This creates a secondary index in the database per marked
field.
Regards,
Angel

Inforation on Pool tables and cluster tables required.

I want to know about the pool tables and cluster tables like how to create them and how to look the tables associated with the given tables. Like for the table BSEG we have other tables linked BSID etc. I'm new to this concept please guide me.

Pooled Table:
A pooled table in R/3 has a many-to-one relationship with a table in the database (see Figures 3.1 and 3.2). For one table in the database, there are many tables in the R/3 Data Dictionary. The table in the database has a different name than the tables in the DDIC, it has a different number of fields, and the fields have different names as well. Pooled tables are an SAP proprietary construct.
When you look at a pooled table in R/3, you see a description of a table. However, in the database, it is stored along with other pooled tables in a single table called a table pool. A table pool is a database table with a special structure that enables the data of many R/3 tables to be stored within it. It can only hold pooled tables.
R/3 uses table pools to hold a large number (tens to thousands) of very small tables (about 10 to 100 rows each). Table pools reduce the amount of database resources needed when many small tables have to be open at the same time. SAP uses them for system data. You might create a table pool if you need to create hundreds of small tables that each hold only a few rows of data. To implement these small tables as pooled tables, you first create the definition of a table pool in R/3 to hold them all. When activated, an associated single table (the table pool) will be created in the database. You can then define pooled tables within R/3 and assign them all to your table pool.
Pooled tables are primarily used by SAP to hold customizing data.
Cluster Table:
A cluster table is similar to a pooled table. It has a many-to-one relationship with a table in the database. Many cluster tables are stored in a single table in the database called a table cluster.
A table cluster is similar to a table pool. It holds many tables within it. The tables it holds are all cluster tables.
Like pooled tables, cluster tables are another proprietary SAP construct. They are used to hold data from a few (approximately 2 to 10) very large tables. They would be used when these tables have a part of their primary keys in common, and if the data in these tables are all accessed simultaneously.
Table clusters contain fewer tables than table pools and, unlike table pools, the primary key of each table within the table cluster begins with the same field or fields. Rows from the cluster tables are combined into a single row in the table cluster. The rows are combined based on the part of the primary key they have in common. Thus, when a row is read from any one of the tables in the cluster, all related rows in all cluster tables are also retrieved, but only a single I/O is needed.
A cluster is advantageous in the case where data is accessed from multiple tables simultaneously and those tables have at least one of their primary key fields in common. Cluster tables reduce the number of database reads and thereby improve performance.
Restrictions on Pooled and Cluster Tables
1. Pooled and cluster tables are usually used only by SAP and not used by customers, probably because of the proprietary format of these tables within the database and because of technical restrictions placed upon their use within ABAP/4 programs. On a pooled or cluster table:
2. Secondary indexes cannot be created.
3. You cannot use the ABAP/4 constructs select distinct or group by.
4.You cannot use native SQL.
5.You cannot specify field names after the order by clause. order by primary key is the only permitted variation.
For creation of pooled /cluster table, have a look at below link.
http://help.sap.com/saphelp_erp2004/helpdata/en/81/415d363640933fe10000009b38f839/frameset.htm
For creation of table pool /cluster, have a look at below link.
http://help.sap.com/saphelp_erp2004/helpdata/en/81/415d363640933fe10000009b38f839/frameset.htm
Have a look at below link.
http://www.sap-img.com/abap/the-different-types-of-sap-tables.htm
Best Regards,
Vibha
*Please mark all the helpful answers

Cannot use comparisons with column column references in pool and cluste

Hi Experts,
I am facing an issue in a select statement written in 4.6 version and in that the table is a transparent table but when porting it to ECC6.0, it gives the follwing error:
You cannot use comparisons with column column references in pool and cluster tables:'A~MATNR'. refe
The select statement is as below:
SELECT akschl alifnr amatnr aekorg awerks aesokz
         aknumh adatbi a~datab
         bmtart bmatkl
        b~yybcezndr " Commented as not required(IDE)
         cwerks cmmsta c~herkl
            INTO CORRESPONDING FIELDS OF TABLE gt_a017
            FROM a017 AS a
           INNER JOIN mara AS b
            ON bmatnr = amatnr
             INNER JOIN marc AS c
               ON cmatnr = bmatnr
              AND cwerks = awerks
             INNER JOIN lfa1 AS d
             ON dlifnr = alifnr
            WHERE a~kappl = 'M'           AND
                  a~lifnr IN s_lifnr              AND
                  a~matnr IN s_matnr        AND
                  a~ekorg IN s_ekorg        AND
                 a~kschl = v_kschl        AND
                  a~kschl = gv_kschl       .
Kindly help me out in this as A017 is a pooled table in ECC 6.0 . Thanks in advance!!!
Thanks and Best Regards,
Sahil

Hi Sahil,
Refer below code
SELECT KSCHL LIFNR MATNR EKORG WERKS ESOKZ
       KNUMH DATBI DATAB
FROM A017
INTO IT_A017 " internal Table
WHERE KAPPL = 'M' AND
        LIFNR IN S_LIFNR AND
        MATNR IN S_MATNR AND
        EKORG IN S_EKORG AND
*         kschl = v_kschl AND
        KSCHL = GV_KSCHL .
IF IT_A017[] IS NOT INITIAL.
    SELECT MATNR MTART MATKL
          FROM MARA
      INTO TABLE IT_MARA" internal Table
      FOR ALL ENTRIES IN IT_A017
      WHERE MATNR = IT_A017-MATNR.
    SELECT MATNR WERKS MMSTA HERKL
      FROM MARC
      INTO TABLE IT_MARC" internal Table
      FOR ALL ENTRIES IN IT_A017
      WHERE MATNR = IT_A017-MATNR AND
            WERKS = IT_A017-WERKS.
    SELECT LIFNR
      FROM LFA1
      INTO IT_LFA1" internal Table
      FOR ALL ENTRIES IN IT_A017
      WHERE LIFNR = IT_A017-LIFNR.
    ENDIF.
After this use READ statement and fill the data in final internal table..
Please search on SCN for more information about how to use FOR ALL ENTRIES..
Hope it will solve your problem..
Thanks & Regards
ilesh 24x7
ilesh Nandaniya

Why Inner join or Outer join is not used for Pool or Cluster tables ?

Hi SAP-ABAP Experts .
With Due Regards .
May u explain me why Inner join or Outer join is not useful for Pool or Cluster tables ?
because peoples advised not use Joins for Pool and Cluster tables , What harm will take place , If we do this ?
Best Regards to all : Rajneesh

Both Pooled and Cluster Tables are stored as tables within the database. Only the structures of the two table types which represent a single logical view of the data are defined within the ABAP/4 Data Dictionary. The data is actually stored in bulk storage in a different structure. These tables are commonly loaded into memory (i.e., 'buffered') due to the fact they are typically used for storing internal control information and other types of data with little or no external (business) relevance.
Pooled and cluster tables are usually used only by SAP and not used by customers, probably because of the proprietary format of these tables within the database and because of technical restrictions placed upon their use within ABAP/4 programs. On a pooled or cluster table:
Secondary indexes cannot be created.
You cannot use the ABAP/4 constructs select distinct or group by.
You cannot use native SQL.
You cannot specify field names after the order by clause. order by primary key is the only permitted variation.
I hope it helps.
Best Regards,
Vibha
Please mark all the helpful answers

Warnings Pool or cluster table selected to check/collect statistics

Dear all,
I am getting error in in db13 backup.
We are using Sap Ecc5 and
oracle 9i on Window 2003.
Production Server I am facing problem suddenly in db13 the UpdateStatsEnded with Return code:    0001 Success with warnings
BR0819I Number of pool and cluster tables found in DDNTT for owner SAPPRD: 169
BR0871W Pool or cluster table selected to check/collect statistics: SAPPRD.EPIDXB
BR0871W Pool or cluster table selected to check/collect statistics: SAPPRD.EPIDXC
BR0871W Pool or cluster table selected to check/collect statistics: SAPPRD.GLSP
BR0871W Pool or cluster table selected to check/collect statistics: SAPPRD.GLTP
BR0871W Pool or cluster table selected to check/collect statistics: SAPPRD.KAPOL
BR0871W Pool or cluster table selected to check/collect statistics: SAPPRD.KOCLU
BR0871W Pool or cluster table selected to check/collect statistics: SAPPRD.M_IFLM
BR0871W Pool or cluster table selected to check/collect statistics: SAPPRD.VBCLU
BR0871W Pool or cluster table selected to check/collect statistics: SAPPRD.VBFCL
And in db02
Missing in R/3 DDIC 11   index
MARA_MEINS
MARA_ZEINR
MCHA_VFDAT
VBRP_ARKTX
VBRP_CHARG
VBRP_FKIMG
VBRP_KZWI1
VBRP_MATKL
VBRP_MATNR
VBRP_SPART
VBRP_WERKS
Please guide steps   how to build index and Pool or cluster table problem.
Thanks,
Kumar

> BR0819I Number of pool and cluster tables found in DDNTT for owner SAPPRD: 169
> BR0871W Pool or cluster table selected to check/collect statistics: SAPPRD.EPIDXB
> BR0871W Pool or cluster table selected to check/collect statistics: SAPPRD.EPIDXC
> BR0871W Pool or cluster table selected to check/collect statistics: SAPPRD.GLSP
> BR0871W Pool or cluster table selected to check/collect statistics: SAPPRD.GLTP
> BR0871W Pool or cluster table selected to check/collect statistics: SAPPRD.KAPOL
> BR0871W Pool or cluster table selected to check/collect statistics: SAPPRD.KOCLU
> BR0871W Pool or cluster table selected to check/collect statistics: SAPPRD.M_IFLM
> BR0871W Pool or cluster table selected to check/collect statistics: SAPPRD.VBCLU
> BR0871W Pool or cluster table selected to check/collect statistics: SAPPRD.VBFCL
Upto Oracle 9i the rulebased optimizer was still used for Pool/Clustertables for reasons of plan stability (e.g. always take the index).
To ensure that this is the case, these tables/indexes mustn't have CBO statistics.
Therefore these tables are usually excluded from getting CBO statistics via an DBSTATC entry. You can modify this setting in transaction DB21.
> And in db02
>
>
Missing in R/3 DDIC 11   index
> MARA_MEINS
> MARA_ZEINR
> MCHA_VFDAT
> VBRP_ARKTX
> VBRP_CHARG
> VBRP_FKIMG
> VBRP_KZWI1
> VBRP_MATKL
> VBRP_MATNR
> VBRP_SPART
> VBRP_WERKS
Well, these indexes have been setup just in the database and not (how it is supposed to be) via the SE11. As the indexes have a naming-scheme, that is not supported by the ABAP Dictionary, the easiest way to get away from the warnings is to check which columns are covered by the indexes, drop the indexes on DB level and recreate them via SE11.
Best regards,
Lars

What is the "No database index" means when you Creating Secondary Indexes?

HI,
   I'm Creating Secondary Indexes in the maintenance screen of the table(se11)
   There are three options under "Non-unique Index":
   1.Index on all database systems
   2.For selected database systems
   3.No database index
My questions is :
What do u mean by "No Database Index" and when is it used.
Can anybody plz tell me what's the difference of this three options ?
Here is what i found in the help:
   No database index: The index is not created in the database. If you
   choose this option for an index that already exists in the database,
   it is deleted when you activate this option.

Hi,
It is clear from the help documentation,
Here see what the help document says:
Create the index in the database (selection)
Whether an index improves or worsens performance often depends on the database system. You can therefore set whether an index defined in the ABAP Dictionary should be created in the database.
This makes it easier to install a platform-specific customer system.
You can set this option as follows:
1. Index in all database systems: The index is always created in the database.
2. In selected database systems: The index is created depending on the database system used. In this option, you must specify the databases in which the indexes are to be created. You can do this either on an inclusive (list of systems on which it should be created) or an exclusinve (list of systems on which it should not be created) basis. In either case, you can list up to four different database systems.
3. No database index:: The index is not created in the database. If you set this option for an index that already exists in the database, it is deleted when you activate the table in the ABAP Dictionary.
Note: Unique indexes have an extra function, and must therefore always be created in the database. The database system prevents entries or index fields being duplicated. Since programs may rely on this database function, you cannot delete unique indexes from the database.
Hope it helps you,
Regards,
Abhijit G. Borkar

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.

Guidelines to create secondary index

Hi Guys,
I'm trying to get a guidelines to create an optimize secondary index. For eg, how to analyze the list of fields should be included into the secondary index. What can be done and not.
Pls place your comment.
Thanks in advance.

Hi,
Basically index are provided to improver performance. i.e with index select on database tables retrieves data much faster.
If you are writting select statement on the table where in where clause you have non-primary keys then it takes longer to retriev data from Database table.
If you have select in dbtable on non-primary key you can create Secondary index with keys as per your where clause which result in faster Database table access.
But remember not to create too many secondary indexes on same table which could result in slow / degrage performance..
and also check this link :
http://help.sap.com/saphelp_470/helpdata/en/cf/21eb20446011d189700000e8322d00/frameset.htm
Regards
Appana

Is it possible to created secondary indexes on ODS in Production

Hi,
Is it possible to created secondary indexes on ODS in Production System. I need to create secondary indexes on ODS but it is already in production. Hence Can I directly create secondary indexes without transportation from dev to production?

Hi,
Secondary Indexes for DSO can be transported. For the transport the DSO objects needs to be transported (R3TR ODSO <technical name>.
Additionally, secondary Indexes are necessary quite often for DSO tables, which can be transported. In few cases you need indexes on other BW tables, but they cannot be transported. Never create additional Indexes on InfoCube tables (like E- and F-Fact tables and Dimension tables)
Thanks & B.R.
Vince

Can we create secondary indexes in pooled and cluster table?

Similar Messages

Maybe you are looking for