Info object activation failed when selected With Master data.

[former_member241605]

Hi all,

Currently we are facing very typical issue on activation of Info Object.

As we have enabled With master data check for a Info object and when tried to activate it is throwing error messages.

We tried in many ways like RSRV and aslo tried activating it in the back ground with the help of RSDG_IOBJ_ACTIVATE and even tried with SE14 for adjusting but nothing worked

But when we check the Info object Log Object we found the main error mentioned below

It is saying Tablespace "PSAPDBW" not exists in the system, but currently in DB02 the Tablespace name is "PSAPSR3"

So we checked with BASIS and they said, a year Before we had an Server Migration from HP to Linux during that time the Tablesapce changed from"PSAPDBW" to "PSAPSR3".

But even Basis People are not getting why only this object reffering to the old Tablesapce name which doesn't exist any more in the system

Basis came up with a solution saying to create the Ptable directly using  SQL for this info object, which we are not sure how far this is good and also we are not sure about the Impacts on this

So kindly suggest what can we do and also please let me know if any one of you faced this kind of issue before?

If so what will be the steps to be taken care to get resolve this issue.

Kindly have a look into this

waithing for your replies!!!

With Regards,

PJ.

[snitwipro · Accepted solution]

Hi,

   Please open your P table (of the info object) in SE14 and try checking the consistency of the database object and runtime object. If those are inconsistent, then use 'Reog' from the SE14 menu (only DDIC user would be able to perform this operation). Once the Reorg is done, then use option 'Save data' - activate and adjust database (execute in background).

  Once this job is completed, then try activating your info object again.

Sourav

[former_member241605 · Accepted solution]

Hello Sourav,

Thanks for your reply!

First of all P Table doesn't exist for the Info Object which i try to activate as this is the first time i am selecting With Master Data Check for the info Object so it has to create Ptable and M table,

FYI: Even we have tried SE14 and it has been ruled out

But it is not happing due to Tablesapce issue as i mentioned in the thread.

With Regards,

PJ.

[Former Member · Accepted solution]

Hi P J,

Try executing this program rsdmd_checkprg_all and give your  info object name by default some options already checked in that screen and you check the box repair also and execute..

After program execution try activate the info object RSDG_IOBJ_ACTIVATE..

Hope it will resolve the issue...revert if still issue persists.

[former_member241605 · Accepted solution]

Hello Shiva,

Thanks for your reply!

Frankly speaking in my case the program which you mentioned doesn't make any changes and more or less it seems to be like RSRV and if you look into my question throughly i mentioned clearly that problem rises while the creation of Ptable & Mtable which refering to the Invalid Tablesapce.

With Regards,

PJ.

[former_member213275 · Accepted solution]

Hi Kiran,

Are the settings of table "TAORA" are defined correctly.
When a new SAP table is created, the logical storage parameters data class and size category are set in the technical settings of the table (transaction SE13).
When you set masterdata at info object level(checkbox set) and save it and now check whether attribute tabel created for that info object or not. if yes then check the technical settings saved for that table from transction Se13 and see whether the data class defined is APPL0 or something and check table "TAORA" against the entry maintained in dataclass. check whether the parameter table space defined correctly or not.
The data class logically defines the tablespace where the newly created table will be stored. The data class is assigned to the data tablespace using the TAORA table and index tablespace using the table IAORA. With the new tablespace layout there is no separation of data and index tablespaces. dataclass APPL0 -for Masterdata , APPL1-Transaction data .
If the settings maintained for APPL0 refers to wrong table space then ask basis people to maintain correctly.

If the error still persists then ask your abaper to debug at what point and how the error is occuring while activating info object.
He can debug by keeping breakpoint on select statement on particular table TAORA, IAORA,  TATAF, TABKAT etc.. and ask to check where/how the invalid tablespace is been fetched while activating info object.

Srikanth.

[former_member241605 · Accepted solution]

Hello Srikanth,

Thanks for your Reply!!

It seems your reply seems almost matching with our issue and we found this Invalid Tablesapce "PSAPDBW" under the table  TATAF and when we checked it is showing 933 records.

But for the same table we checked in Q & P and found 0 Entries.

So if we clear the entries in the table  TATAF will it work fine OR please let us know what steps to be taken care inorder to get rid of this issue?

Please guide us for one more time as we are near to achieve this with your help

Thanks in Advance,

PJ.

[former_member213275 · Accepted solution]

Hi,

Although it's a  good practise not to clear tables and  i am not sure whether this will solve your problem. The SQL statement to create the indexes are stored in the TATAF table, this table is built during prepare of upgrade but there is no upgrade for your case right?.

Can you also check whether any entries exists in table TBATG.

Take a backup of everything before you proceed even a try may cause damage.

Srikanth.

[former_member213275 · Accepted solution]

Hi,

Also check below tables  whether you have any wrong table space "PSAPDBW" defined? 

TADB6, TSDB6 and IADB6

Srikanth.

[former_member213275 · Accepted solution]

Hi,

I found some blog and might be useful for you FAQ related to table space.

1. How does the SAP system determine the tablespace and storage parameters for objects to be created?

In various situations, database objects are created from R/3, for example:

• Table conversions
• Transports of new objects into the system
• Manual creation of new objects (transactions SE14, SE11)

If errors occur when you create objects (such as the MAXEXTENTS limit is reached, for example) or if the objects are created in an incorrect tablespace, you must determine the basis on which the storage parameters and the target tablespace are defined. For this, the R/3 system proceeds with the following steps:

a) User-specific settings

• If user-specific settings exist (for example, because you specified data in SE14 using the "For new creation" button), these are used to create the new object.
• The user-specific settings are stored in the DDSTORAGE table.    b) Current database settings
• If the affected object already existed at database level (for example, for a table conversion) and user-specific settings do not exist, the previous settings are transferred. This means that the new object is in the same tablespace and has the same storage parameters as the object that previously existed.    c) Technical settings
• If the two conditions above are not fulfilled, the technical settings take effect. They are in transaction SE13 and consist of the "Data Class" (TABART) and the "Size Category" (TABKAT). The TABART is used to define the tablespace used while the TABKAT determines the size of the storage parameters.
• The TAORA (tables) or IAORA (indexes) tables contain the 'TABART -> tablespace' assignment.
• The TGORA (tables) or IGORA (indexes) tables contain the 'TABKAT -> storage parameter' assignment.
• The TSORA table contains the 'table tablespace -> index tablespace' assignment.
• The DD09L table contains TABKAT and TABART for all objects with technical settings.
• The DDART and DARTT tables contain information about the available TABARTs.

The system temporarily stores DDL statements in the TATAF table within the SAP transport system. These statements also contain components, such as tablespace names, that were determined based on the settings mentioned above.

2. What do I have to bear in mind in connection with the technical settings in the BW environment?Some temporary BW objects (naming convention /BI0/0*) use the tablespace and the storage parameters of the dummy table QUERY_TABL_MODEL (for example, /BI0/06*, /BI0/0P*; in some cases /BI0/01*, /BI0/02*). For more information, also see Note 568632.Sometimes, temporary BW objects are created without an explicit specification of a tablespace. This is the reason why these can then be found in the default tablespace. The tablespace may also be defined dynamically with individual methods.By default, fact tables use the technical settings stored in the model table RSDMFACTAB. By default, dimension tables use the technical settings stored in the model table RSDMDIMTAB (Note 443767). For more BW-specific model tables, see the type group RSDG in transaction SE11 (for example, RSDMODSTAB for ODS).

3. How can I adjust these SAP settings?SAPDBA and BRSPACE make the necessary settings automatically (for example, if the target tablespace is missing during a table reorganization). For more information, see Note 154193.Note 771191 describes how you can move BW objects into another tablespace.Note 568632 describes how you can change the settings for temporary BW objects if problems occur.Note 46272 describes how you can include a new data class in the technical settings.You can correct entries for individual objects in DD09L by adjusting the technical settings in transaction SE14. Under "For new creation" in transaction SE14, you can adjust the DDSTORAGE entries for individual objects.You can use transaction SE16 to change entries from TAORA, IAORA, TGORA, IGORA and TSORA. Note that this is only possible if it is permitted by the settings for the system change option (transaction SE06) and client change option (transaction SCC4).If you cannot use transaction SE16 or if you want to change a large number of entries in DDSTORAGE or DD09L, you can update the tables directly at Oracle level, while taking the necessary precautions.You can only change entires in TATAF manually (or by activating the object in transaction SE11).Note that the above tables are generally buffered in the R/3 system. Therefore, changes made with SQLPLUS or other R/3 external tools are only recognized by R/3 if the instance is restarted or if buffering is invalidated for the tables. For this invalidation, use the report "RSDBBUFF -> Edit -> Reset buffer".

4. What errors may occur if an incorrect tablespace or incorrect storage parameters are defined in SAP?

• If SAP finds a tablespace that no longer actually exists in the user-specified or technical settings, the following error occurs when you use SAP tools to create the object (for example, as part of a conversion):
  
      ORA-00959: Tablespace <tsp> does not exist

           This problem can occur even if the entries in TAORA, IAORA and TSORA are correct after an online reorganization with BRSPACE, because the SAP buffer for these tables is not automatically invalidated at the same time. In this case, you can perform a manual invalidation using the report RSDBBUFF.           If the problem persists even though you have corrected TAORA/IAORA, TATAF may contain obsolete entries that you must correct.

• If BRCONNECT detects a difference between TAORA / IAORA and the actual existing SAP tablespaces, the errors described in Note 655162 occur.
• Incorrect TAORA/IAORA entries may cause dumps when you create partitions in BW (see Note 539757).
• If, for an object, you select a TABKAT that is too low and therefore NEXT and MAXEXTENTS parameters that are too small, this may cause "maxextents reached" errors as described in Note 533455.
• In addition, extent sizes that are too small may lead to performance problems due to space transactions.
• If the partitions of partitioned objects are in different tablespaces (because the tablespace to be used for new partitions changed in the meantime), the process of 'dropping' the affected tablespaces fails with an ORA-14404. In general, you should ensure that the partitions of an object are in one tablespace only.

5. How does Oracle determine the tablespace and the storage parameters for objects to be created?

Generally, SAP explicitly specifies tablespaces and storage parameters. These values then undergo a 1:1 conversion by Oracle. If tablespaces and storage parameters are not explicitly specified, Oracle proceeds according to the following rules:

If a tablespace is not specified for tables or indexes, the object is created in the default tablespace of the database user who is logged on to the system. You can determine the default tablespaces for the database users as follows:

SELECT USERNAME, DEFAULT_TABLESPACE FROM DBA_USERS;

If the tablespace specification is missing for partitions, the default setting is used for the partition. You can determine this for tables or indexes as follows:

SELECT DEF_TABLESPACE_NAME FROM DBA_PART_TABLES
WHERE TABLE_NAME = '<table_name>';

SELECT DEF_TABLESPACE_NAME FROM DBA_PART_INDEXES
WHERE INDEX_NAME = '<index_name>';

Oracle determines non-specified storage parameters for tables or indexes from the default values of the relevant tablespaces. You can determine these as follows:

SELECT INITIAL_EXTENT, NEXT_EXTENT, MAX_EXTENTS, PCT_INCREASE
FROM DBA_TABLESPACES
WHERE TABLESPACE_NAME = '<tablespace_name>';

Oracle determines non-specified storage parameters for partitions from the default storage parameters for the partitions of the relevant object. You can determine these for tables or indexes as follows:

SELECT DEF_INITIAL_EXTENT, DEF_NEXT_EXTENT, DEF_MAX_EXTENTS,
   DEF_PCT_INCREASE
FROM DBA_PART_TABLES
WHERE TABLE_NAME = '<table_name>';

SELECT DEF_INITIAL_EXTENT, DEF_NEXT_EXTENT, DEF_MAX_EXTENTS,
   DEF_PCT_INCREASE
FROM DBA_PART_INDEXES
WHERE INDEX_NAME = '<index_name>';

6. How can I change default Oracle values for tablespaces and storage parameters?

Generally, you do not have to adjust the Oracle default values. However, if you believe this may be useful in individual cases, you can use the following commands:

Changing the default tablespaces for a user:

ALTER USER <user_name> DEFAULT TABLESPACE <new_default_tablespace>;

Changing the tablespace defaults of the storage parameters:

ALTER TABLESPACE <tsp> DEFAULT STORAGE (INITIAL <new_initial>);
ALTER TABLESPACE <tsp> DEFAULT STORAGE (NEXT <new_next>);
ALTER TABLESPACE <tsp> DEFAULT STORAGE (MAXEXTENTS <new_maxextents>);
ALTER TABLESPACE <tsp> DEFAULT STORAGE (PCTINCREASE <new_pctincrease>);

Changing the partition defaults for tables:

ALTER TABLE "<table_name>" MODIFY DEFAULT ATTRIBUTES
   TABLESPACE <tablespace_name>;
ALTER TABLE "<table_name>" MODIFY DEFAULT ATTRIBUTES
   STORAGE (INITIAL <new_initial>);
ALTER TABLE "<table_name>" MODIFY DEFAULT ATTRIBUTES
   STORAGE (NEXT <new_next>);
ALTER TABLE "<table_name>" MODIFY DEFAULT ATTRIBUTES
   STORAGE (MAXEXTENTS <new_maxextents>);
ALTER TABLE "<table_name>" MODIFY DEFAULT ATTRIBUTES
   STORAGE (PCTINCREASE <new_pctincrease>);

Changing the partition defaults for indexes:

The same as tables, except with:

ALTER INDEX "< index_name>" ...

7. What happens if the defined default tablespace of a partitioned segment no longer exists?

If, during a reorganization, you delete a tablespace, for example, which is defined as DEF_TABLESPACE_NAME in DBA_PART_TABLES or DBA_PART_INDEXES, the tablespace name is replaced by a placeholder such as _$deleted$7$0. If you now perform an ADD PARTITION, it leads to the following errors:

ORA-00959: tablespace '_$deleted$8$0' does not exist

You can correct this by adjusting the tablespace name using MODIFY DEFAULT ATTRIBUTES as described above.

BRSPACE performs this adjustment automatically during the reorganization.

8. What pitfalls and exceptions are associated with the mechanisms for specifying the tablespace and storage parameters?

Even though it seems as though you have set up user-specific values and technical settings correctly, a number of SAP and Oracle patterns of behavior may result in the wrong tablespace or storage parameters being used:

Depending on the release and patch status, PSA tables in BW (naming convention: /BI*/B*) follow their own rules with regard to tablespace and storage parameters. For more information, see Notes 639930 and 639941.

New partitions for locally partitioned indexes in BW are automatically created if the relevant table gets new partitions. The tablespace in which the new index partitions are created cannot be explicitly specified. Instead, the default tablespace specified when the index is created is always used. Alternatively, if a default tablespace was not specified, the table tablespace is used. This may cause problems after moving indexes to another tablespace, for example, if the default tablespace was not also adjusted (see the BRSPACE bug from Note 822936, for example).

You can use the following command to check whether a default tablespace was defined for the index:

SELECT DEF_TABLESPACE_NAME FROM DBA_PART_INDEXES
WHERE INDEX_NAME = '<index_name>';

If the field is empty or if an incorrect tablespace is specified, you can adjust the default value as follows:

ALTER INDEX "<index_name>"
MODIFY DEFAULT ATTRIBUTES TABLESPACE <tablespace_name>;

If a TRUNCATE is executed on a table or partition, Oracle resets the value for NEXT to the NEXT value of the last deleted extent. Therefore, if you had created a table or partition with an unfavorable NEXT value (for example, very small 8K), but you corrected this later (after some extents were already allocated), Oracle resets NEXT to the original NEXT value (in the case of a TRUNCATE). In particular, this may cause problems in BW because automatic TRUNCATEs are executed there in some situations.

To solve the problem, you must manually correct NEXT directly after a TRUNCATE.

If you have used a tool such as BRSPACE to move tables to another tablespace, the changes to tables such as TAORA or IAORA may be lost when you upgrade or import Support Packages because the SAP dictionary is "officially" unaware of the changes. If you carry out a system copy later on, segments may be placed in the original tablespace again. Note 778784 describes how you can avoid this problem. See also Note 777615.

Srikanth.

[former_member241605 · Accepted solution]

Hello Srikanth,

Thanks for your Quick Reply!!

I have checked in the Table : TBATG and no entries available based on the Object

As i mentioned in my thread we had an Server Upgradation from HP to Linux which happened a year ago and after long time we tried to change this object and got in big tricky issue

Ans yes you are wrote as this table might be important so we spoke with our FO and they said that they are going to raise this issue to SAP.

So we will wait and see for the reply from SAP !

Once i get an Update on this i will sure update you people and till then i will keep this Thread in open so that to get more specific replies.

Thanks for alll your support!! and please continue this .

With Regards,

PJ.

[former_member241605 · Accepted solution]

hello Srikanth,

I am sorry i didn't checked your latest reply and i don't my screen refreshed  or not so i will check your reply now and let you know!!

Thanks Buddy

With Regards,

PJ

[former_member241605 · Accepted solution]

Hello Srikanth,

I have checked the tables

TADB6, TSDB6 and IADB6 which you given and the Tablespace PSAPDBW doesn't exist in any of this tables.

With Regards,

PJ.

[former_member241605 · Accepted solution]

Hello Srikanth,

The issue has been solved and thanks to you for your good response on this issue really appreciated!!

The Basis people modified an entry having old Tablesapce "PSAPDBW" and they have replaced with the current one in the table "DDSTORAGE".

Finally the info object got activated by selecting With Master data check in the Info object

I like to Thank all Those who shared their thoughts about this issue!!

Regards,

PJ.