Tables Archives » Page 2 of 2 » Musings of an IT Implementor

SAP Unicode Conversion Nametab Inconsistency

During a unicode conversion of a SAP NW731 system, I saw a problem where a number of BI FACT tables (/BIC/E*) were present in the SAP nametab, existed in the Oracle database, but they didn’t exist in the DDIC (SAP data dictionary visible in SE14).

SPUMG nametab

I asked the BI administrator to confirm that these tables were not referenced in the BI cubes, and they weren’t. He suggested that these tables used to belong to a cube that was long since deleted. This means that at some point there must have been a program bug that has left the nametab inconsistent with the DDIC.

There are no SAP notes about what to do in a situation like this, but there are two options:
1, Exclude the tables from the unicode conversion in transaction SPUMG by adjusting the exceptions list.
or
2, Manually adjust the SAP nametab.
I chose option 2, since this was the cleanest option and would hopefully leave the system in a better state for future updates.

I found SAP note 29159 contained some useful information on a similar subject. The note suggested writing some simple ABAP code to delete these tables from the SAP nametab tables DDNTT and DDNTF.

Whilst this was simple enough, I decided that I didn’t need to go as far as writing ABAP. I manually removed the entries at the database level using SQL:

SQL> delete from sapsr3.ddntt where tabname ='<TABLE>'; SQL> delete from sapsr3.ddntf where tabname ='<TABLE>';

Then restarted the system (or you could sync the nametab buffer with “/n$NAM”).
This fixed the issue and allowed the unicode conversion to continue.

UPDATE: I’ve since found that it’s possible to list the contents of the Nametab buffer and delete specific tables from the buffer using the function modules DD_SHOW_NAMETAB and DD_NAMETAB_DELETE.

SAP R3load table splitter – Table Analysis Performance

Be careful when using the R3load table splitter from the Software Provisioning Manager screens.
You are asked to supply your table split file, in the install guide, in the format “<TABLE>%<# SPLITS>”.
However, this does not supply the table column to split by.

When splitting large tables, during the Table Splitting preparation phase (before you even start exports), R3ta can run for quite a while whilst is performs scans of the available INDEXES and then COUNTs the number of rows in the table(s) to be split.

It’s trying to define the most apt column(s) to use for generating the WHR files which contain the query predicates.

I tried adding a specific column during the initial table splitter screens, where you can specify the column to use. However, this seems to be completely ignored.

The best advice, is to prepare your table split during your proof phase in the sandbox environment, then potentially manually adjust the final WHR file to account for any additional rows in the table(s) to be split.

This will save a lot of time and effort in the true production conversion run.

Also, ensure that the indexes on those tables, especially the ones that the WHR predicates refer to, are rebuilt if possible.

HowTo: Hide SAP tables including USR02

Within an SAP system, the user account passwords are hashed and stored in the SAP schema table USR02.
If the SAP system users have access to transaction SE16, then it’s possible for them to view the USR02 table by default.

This would present the user with the opportunity of seeing the password hash values.

It would be possible to spot a commonly used password hash and provided the user knows the actual password text that generated the hash, could use it to log in as a different SAP user, maybe with higher privileges.

More importantly, if the user manages to modify the table through transaction SM30, they could set their own hashes.

It is better to create a new authorisation group for the USR02 table, then exclude this specific auth group from the user roles via auth object S_TABU_DIS and setting the “Authorization Group” field.

An example would be to create a new authorisation group “ZZND” (zz no display) in transaction SE54.
Then, still in SE54, assign all the tables you do not wish anyone to see, to the new auth group.

Use transaction PFCG to edit your roles and change authorisation S_TABU_DIS, so that the field “Authorization Group” is set to a range “$*” to “ZY*” (it excludes ZZ*):

The next time the users try to access the table, they will receive a no authorization prompt in SE16.

UPDATE 30/05/2014: The post above was based on R/3 4.7. Later releases may have an SC auth group already defined with the USR* tables, plus others, already defined. You may still wish to create your own ZZND auth group to ensure continuity across upgrades and for your own standardisation practices if you must customise the list of tables in the auth group. Thanks Matt.

Useful SAP Tables

During my time as a SAP BASIS administrator, I have accumulated a number of useful database tables.

ADR6 – User Address Data (cross with USR21)
AGR_1250 – Authorization data for the activity group
AGR_USERS – Assignment of roles to users
AGR_SELECT – Assignment of roles to Tcode
AGR_PROF – Profile name for role
AGR_DEFINE – Role definition
BDCPS – Change Pointers
DDLOG – Table buffer changes for sync between dialog instances.
DD02T – SAP Tables and descriptions.
DD09L – SAP Tables (with logging PROTOKOLL=X)
PA0105 – HR Communications InfoType (includes USERID to PERNO).
SH_PRIN – Printer list
TADIR – Repository object table.
TBRG – All Authorisation Groups.
TDDAT – Tables to Authorisation Groups.
TBTCP – Background Job Steps (see field AUTHCKNAM for job user)
TOLE – OLE Link table
USR02 – User passwords.
USR01 – Users.
USR04 – User Master Authorisations.
USR10 – Authorisation Profiles.
UST04 – Users to profiles.
TDEVC – Package table.
TSP03D – Printer Output Devices
TST03 – Spool requests
TSTC – Transactions
TVARV – Variant Variables
VARI – Variants