Handling and troubleshooting of tablespaces during SAP Upgrades, Enhancement Packages and Support Packages updates

Handling and troubleshooting of tablespaces during SAP Upgrades, Enhancement Packages and Support Packages updates

During SAP systems upgrades, enhancement packages installations and Support Packages updates via SUM (when shadow instance is present), the system tablespaces are changed according to the their new release.

The UPG tools have their own mechanism to update the tablespaces. However, problems can take place during the tablespaces handling; and/or customers might have questions related to the deletion or modificcation of tablespaces. For example, if PSAPSR370xX or PSAP<SID>70xX can be deleted or not, or if tablespaces named as the old SAP Basis release (e.g. PSAPSR3701 or PSAPSR3701X)  are not empty.

Before proceeding, please familiarize yourself with the naming convention and data files in SAP environments, on the following help.sap link:

SAP Naming Conventions for Tablespaces and Data Files

Please note that Microsoft’s MSSQL, SAP’s MaxDB and Sybase’s own DB don’t use the concept of tablespaces to store data logically, so this document is not applicable to these DBs.

Also notice that the majority or such problems take place on Oracle databases, so this will be the database focused on this article.

This Knowledge Base Article intends to help troubleshooting problems with tablespaces during UPG processes.

Environment

  • Release upgrade, Enhancement Package installation, Support Package Stack application of  SAP products (ERP, CRM, Solman etc.) based on NetWeaver 7.x using the Software update manager (SUM)
  • SAP NetWeaver 7.0
  • SAP NetWeaver 7.3
  • SAP enhancement package 1 for SAP NetWeaver 7.0
  • SAP enhancement package 1 for SAP NetWeaver 7.3
  • SAP enhancement package 2 for SAP NetWeaver 7.0
  • SAP enhancement package 3 for SAP NetWeaver 7.0
  • SAP Solution Manager SAP Solution Manager 7.1
  • SAP enhancement package for SAP ERP SAP enhancement package 4 for SAP ERP 6.0
  • SAP enhancement package 5 for SAP ERP 6.0
  • SAP enhancement package 6 for SAP ERP 6.0
  • SAP enhancement package 7 for SAP ERP 6.0
  • SAP enhancement package 8 for SAP ERP 6.0

Cause

Background

each table is assigned to a data class (also called TABART). You can check this by going to transaction SE11 –> table name –> Technical Settings –> Data class:

Bseg Table

 Definition of TABART: is a table attribute used to link each table to its own tablespace. This attribute is just an information, not an ABAP or database object!

Each TABART is linked to a tablespace (also called container). Please refer to note #541542 for more details about this layout. (in Oracle databases the relationship between each tablespace and data classes (tabarts) is done via tables IAORA and TAORA, which link the respective indexs and tables.

The tables are organized according to a certain pattern, called tablespace layout. The below example shows the ‘new’ Oracle layout (introduced in release 46C SR2, with kernel 46D). Please refer to note #355771 for information regarding the the old and new Oracle layouts.

Layouts

Here is an example of the old (also called classic concept) Oracle layout:

Oracle Layout

Here is an example of the TADB2 and TADB6 tables, which store the tables <–> tablespace information for IBM’s DB2 database (also know as DB4 or DB6, depending on the operating system used):

TADB2 and TADB6 tables

The 3 main table spaces based on the new layout are:

PSAP<SID> stores SAP application tables
PSAP<SID><version> stores SAP system tables
PSAP<SID>USR stores customers Z tables
PSAP<SID>USR1…X stores customers Z tables

During Upgrades, the UPG tool will generate a new tablespace (called exchange tablespace) on the shadow instance based on the ones from the source system, named PSAP<SID><new_version>. The size of the new tablespace is approximately the size of the old tablespace. If there is also an Unicode Conversion taking place (as in the CUUC – Combined Upgrade and Unicode Conversion) the tool allocates 25% more space for the new tablespace. You can check the calc peformed by the UPG tool on log files DBFPLUSD.SPC (which is the size of the information found on DBFALL.SPC plus 25% when doing unicode together). Also you can see in INICNTDEST.LOG how the SAP tablespaces are matched with the customer tablespaces – you can see all of this in main log file DBFPLUSD.LOG.

 Short example:

Taking as an example the release NetWeaver 7 EHP 2:

The first time the SUM installs NW 7.0 EHP2 over NW 7.0, it will create the tablespace PSAPSR3702 (or PSAP<SID>702), because of SAP_BASIS will be on 702 level.

   – if SUM will be used a second time to install Support Package stacks, it means SAP_BASIS level remain on 702, so  the tablespace that will be created will be SAPSR3702X, because SAPSR3702 already exists.

   – if SUM will be used a third time to install Support Package stacks again, SAP_BASIS level will still remain on 702, so the tablespace that will be created will be SAPSR3702, because SAPSR3702X already exists.

 Please be informed that SPs being updated via SPAM or SAINT do not follow this logic, as no new tablespaces are created with this tools.

 Upgrading a system with tablespaces ending in ‘X’

If your system went by a SP implementation via SUM, as exampled above, resulting in tablespaces like PSAPSR3702X, and now it will be upgraded to a new release, the new tablespaces created will not hold the ‘X’ character. By the end of the upgrade, the tablespaces will be named as PSAPSR3731.

Resolution

These are the most common errors related to tablespaces during Upgrades:

1) error during extraction phase PREP_INIT/INIT_CNTRANS:

Release ‘XXX’ missing in table container ‘<tablespace>’ for tabart ‘<tabart>’
Release ‘XXX’ missing in index container ‘<tablespace>’ for tabart ‘<tabart>’
Container pair ‘PSAPSR3XXXX’/’PSAPSR3’ for tabart ‘<tabart>’ not identical

For example:

Release ‘731’ missing in table container ‘PSAPP1R700’ for tabart ‘SLDEF’
Release ‘731’ missing in index container ‘PSAPP1R700’ for tabart ‘SLDEF’
Release ‘731’ missing in table container ‘PSAPP1R700’ for tabart ‘SLEXC’
Release ‘731’ missing in index container ‘PSAPP1R700’ for tabart ‘SLEXC’
Release ‘731’ missing in table container ‘PSAPP1R700’ for tabart ‘SSDEF’
Release ‘731’ missing in index container ‘PSAPP1R700’ for tabart ‘SSDEF’
Release ‘731’ missing in table container ‘PSAPP1R700’ for tabart ‘SSEXC’
Release ‘731’ missing in index container ‘PSAPP1R700’ for tabart ‘SSEXC’
Container pair ‘PSAPSR3731’/’PSAPSR3’ for tabart ‘SLDEF’ not identical.

Container pair ‘PSAPSR3731’/’PSAPSR3’ for tabart ‘SLEXC’ not identical.

Reason: tablespaces are assigned to incorrect TABARTs in IAORA and TAORA, or table TSORA (which maps the tablespaces x index spaces) has an incorrect information regard the container par.

Solution: maintain the correct entries in TAORA/IAORA according to the note #541542 before you start the upgrade. Please doble check if the mapping is correct according to the following documentation:
Oracle tables TAORA, IAORA and TSORA contents

Reset and restart upgrade again after this is fixed.

2) tablespace is not emtpy after upgrade, or tables/indexes are placed on the wrong tablespace.

You can verify this with program checkDB (from BRCONNECT), a situation similar to the following:
(from checkDB.log)

BR0969I Checking database administration…
BR0970W Database administration alert – level: WARNING, type: IN_WRONG_TABLESPACE, object: (table) SAPRP1.BCACT, value: PSAPSAP620
BR0970W Database administration alert – level: WARNING, type: IN_WRONG_TABLESPACE, object: (index) SAPRP1.BCACT~0, value: PSAPSAP620
BR0970W Database administration alert – level: WARNING, type: IN_WRONG_TABLESPACE, object: (table) SAPRP1.BCCOM, value: PSAPSAP620
BR0970W Database administration alert – level: WARNING, type: IN_WRONG_TABLESPACE, object: (index) SAPRP1.BCCOM~0, value: PSAPSAP620
BR0970W Database administration alert – level: WARNING, type: IN_WRONG_TABLESPACE, object: (table) SAPRP1.BCEXC, value: PSAPSAP620
BR0970W Database administration alert – level: WARNING, type: IN_WRONG_TABLESPACE, object: (index) SAPRP1.BCEXC~0, value: PSAPSAP620
BR0970W Database administration alert – level: WARNING, type: IN_WRONG_TABLESPACE, object: (table) SAPRP1.BCRES, value: PSAPSAP620

There are still tables and/or indexes present on the old tablespace.

Reason: they were not moved to the correct one, probably due to inconsistency on the TABART information prior to the upgrade. Notes #777615 and #778784 explain this situation.

Solutionmove the tables/indexes to the new tablespace using the specific database tool for this action. In Oracle it is BRSPACE (included in BRTOOLS), see note #646681. Note #1715052 covers this situation as well.

3) not enough free space in phase PREP_INIT/SPACECHK_INI:

4 ETQ064 Free space of ”       2″ MBytes found in tablespace “PSAPTEMP”
4 ETQ064 Free space of ”       2″ MBytes found in tablespace “PSAPTEMP”
4 ETQ064 Free space of ”       2″ MBytes found in tablespace “PSAPTEMP”
4 ETQ064 Free space of ”       2″ MBytes found in tablespace “PSAPTEMP”
4 ETQ064 Free space of ”       2″ MBytes found in tablespace “PSAPTEMP”
1EETQ399 Last error code set is ”
1EETQ204 Upgrade phase “SPACECHK_INI” aborted with severe errors

Reason: there are two setting that influences in this phase. The first one is the NLS_CHARACTERSET/NLS_NCHAR_CHARACTERSET that are not set as it is mentioned in note #669902. The second one is the automatic undo management, which might be either not set or set to manual

Solution: follow note #669902 to rectify the NLS_NCHAR_CHARACTERSET and set the automatic undo management to automatic, as per note #600141 (also valid for versions 10 and 11). You can reset it to manual (or disable it) after the upgrade is finished.

 4) DB6 indexes created at wrong tablespace:

>> 2011/10/01 00:28:55  START OF PHASE PREP_INTEGRATION/INIT_CNTRANS_2

>>>> Table class to container mapping <<<<
INFO: An inconsistency has been detected in your system:
Container pair ‘RD1#EL701DX’/’RD1#EL701DX’ for tabart ‘SLDEF’ not different.
Container pair ‘RD1#EL701DX’/’RD1#EL701DX’ for tabart ‘SLEXC’ not different.
Container pair ‘RD1#ES701DX’/’RD1#ES701DX’ for tabart ‘SSDEF’ not different.
Container pair ‘RD1#ES701DX’/’RD1#ES701DX’ for tabart ‘SSEXC’ not different.

01)  –  Repeat the check
02)  *  Ignore the inconsistency
Ignore the inconsistency <– here

Reason: error was ignored during phase INIT_CNTRANS_2.

For example:
TSDB6

TABSPACE                         INDSPACE
S0E#EL701DX                    S0E#EL701DX  <–  should be S0E#EL701IX
S0E#ES701DX                    S0E#ES701DX  <–  should be S0E#ES701IX

IADB6

TABART TABSPACE
SLDEF    S0E#EL701DX <–  should be S0E#EL701IX
SLEXC    S0E#EL701DX <–  should be S0E#EL701IX
SSDEF    S0E#ES701DX <–  should be S0E#ES701IX
SSEXC    S0E#ES701DX <–  should be S0E#ES701IX

Solution: since the index locations are only specified at time of creating a table, it cannot be changed afterwards. The only way to solve the problem is to use DB6CONV (see note #1513862) to move and thereby explicitly creating all erroneous tables to/in new and correct data- and index- tablespaces.

 5) Excessive increase of new tablespace size due to incorrect Oracle Allocation type:

You noticed the new tablespace has twice, thrice or even more the size when compared to the old one.

Reason: the Allocation type has been set to UNIFORM for the new tablespace. As a consequence you’re obliged to enter a value for the default Init ext. (MB) and Next ext. (KB). For example:

Tablespace Management Allocation Init ext.(MB) Next ext.(KB)
PSAPSR3 LOCAL SYSTEM 0.06 0.00
PSAPSR3700 LOCAL SYSTEM 0.06 0.00
PSAPSR3702 LOCAL UNIFORM 1,024.00 1,024.00
PSAPSR3USR LOCAL SYSTEM 0.06 0.00
PSAPTEMP LOCAL UNIFORM 1.00 1.00
PSAPUNDO LOCAL SYSTEM 0.06 0.00
SYSAUX LOCAL SYSTEM 0.06 0.00
SYSTEM LOCAL SYSTEM 0.06 0.00

Solution: please create a temporary tablespace with AUTOALLOCATE type of allocation, then reorganize the content of the tablespace with allocation type UNIFORM to the temporary tablespace (note #646681). Drop the UNFORM tablespace and finally rename the temporary tablespace to the old name. Please refer to note #214995 for assistance. Usually the sizes are the same as on the old tablespace. You can view this in transaction DBACOCKPIT -> Space -> Tablespaces -> Overview.
SYSTEM ==> the value of the ‘next extend’ option increases automatically, following the table size increase.
UNIFORM ==> value is increased in fixed values, as seen above.

6) Error during MOVE_NAMETAB phase, ORA-00959, tablespace does not exist. For example:

2EETP345 18:02:26: Retcode 1: SQL-error “959-ORA-00959: tablespace
‘PSAPRKQ’ does not exist” in DDL
2EETP345  statement for “WDYADT_VE_DEFS                “
2 ETP399                  DB-ROLLBACK()
2EETP334 18:02:26: error in DDL, nametab for “WDYADT_VE_DEFS” not
activated

Reason: the tablespace does not exist on the database level. Note that this error is usually associated to a system copy, via BACKUP + RESTORE method, where the DB tool does not perform the tablespace renaming automatically (unlike using SAP’s sapinst tool)

Solution: create the tablespace on the database and check if the TAORA x IAORA assignments are pointing to this tablespace. Restart the update procedure from scratch.

7) Error during PREACT_UPG phase:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
DDIC ACTIVATION ERRORS and RETURN CODE in SAPA702EPP.BWQ

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

3 EDT012XActivate table “DD03L”
2WENP205 “POSITION” already active and reserved (If possible, select
another name)
1EEDT609 Value in field “Data class” (value “USER6” not permitted)
2WEDT135 Flag: ‘Incorrect enhancement category‘ could not be updated
3 EDT013 Table “DD03L” was not activated
1EEDO519X”Table” “DD03L” could not be activated

3 EDT012XActivate table “DD04L”
3EEDT609 Value in field “Data class” (value “USER6” not permitted)
4WEDT135 Flag: ‘Incorrect enhancement category‘ could not be updated
3 EDT013 Table “DD04L” was not activated
1EEDO519 “Table” “DD04L” could not be activated

Reason: Incorrect data class (TABART) assignment for these system tables. on this example, they’re assigned to a custom tablespace (USER6). This error usually happens to the DD* tables.

Solution: reassing them to the right data class (SSEXC). Check TAORA to verify the correct TABART for the system tables.

8) TTREE* tables were left in old tablespace. After you finished the upgrade or enhancemente package procedure, you still see the following objects on the old version tablespace:

TTREE
TTREED
TTREEI
TTREEN
TTREEP
TTREET
TTREE_APPL
TTREE_FLNK

special mention to

DBMAPS
SCI_DD28S
MSSSTORAGE
DDMTF_SAV
DDMTT_SAV
DDMTF_ISU
DDMTT_ISU
DDXTT_MIG
UPGCOLLPATTERN

Reason:  this is documented in SAP note #1819182: “This is caused due to a required reclassification of the tables mentioned above. However, the SUM tool does not move the tables”. For the tables mentioned on the ‘special mention’, please refer to note #2211218

Solution: Please follow the steps on the ‘Solution’ part of both notes:

In transaction SE13 or SE11, change the data type SSEXC to APPL0 for the
tables and activate your data. After you do this, you can use
a) SE14
b) ICNV
c) DB tools
to move the table to a different tablespace (for TABART APPL0).

AND

The following listed tables should be remained with data class SSEXC as exchange tables.

DDMTF_SAV
DDMTT_SAV
DDMTF_ISU
DDMTT_ISU
DDXTT_MIG
UPGCOLLPATTERN

So if the data class is not SSEXC after system update/upgrade, please change the data class to SSEXC, and move them to the corresponding tablespace. You can find the corresponding tablespace in table TAORA or IAORA.

Note: please contact SAP Product Support if you encounter a table which is not listed in  this KBA or in SAP Note 1819182.

9) Upgrade is finished but I still see the old tablespace on my system. Can I delete it?

Reason: similarly to point #2, data can still exists on the tablespace, however no matter the reason.

Solution: if the old tablespace is completely empty, then you can safely delete it. However, if you attempt to do it and Oracle issues a warning informing the tablespace is not empty, DO NOT ignore this warning! You might be falling into the bug described in note #1677201 “Oracle 11g: Dictionary corruption / ORA-959 due to DROP TBS”. Also be sure to use the very last version of SUM in order to not fall into old bugs described in notes #1680769, #1715052 and #1819182 (described above in point #8) .

See Also

The SAP Support Wiki page for tablespace:

Old exchange tablespace is not empty after update

The following SAP notes:

Note #646681 –   Reorganizing tables with BRSPACE
Note #355771 –   Oracle: Explanation of the new tablespace layout
Note #541542 –   Upgrade phase INIT_CNTRANS: Container inconsistency
Note #600141 –   Oracle9i: Automatic UNDO Management
Note #646681 –   Reorganizing tables with BRSPACE
Note #655162 –   BRCONNECT messages in relation to technical settings
Note #669902 –   Setting the national character set to UTF8
Note #777615 –   Incorrect data class/database container assignment
Note #778784 –   Inconsistencies between data class and database container
Note #1513862 – DB6: Table conversion using DB6CONV Version 5.01 or higher
Note #1715052 – tablespace cannot be deleted after upgrade
Note #1819182 – Tables (TTREE*) remain in old exchange tablespace
Note #2211218 – DDMTF_SAV, DDMTT_SAV, DDMTF_ISU, DDMTT_ISU, DDXTT_MIG or UPGCOLLPATTERN tables remain in the old tablespace

You may also like...