Technical Background Knowledge
Unit Overview
This unit explains where all the information is coming from that is stored in the various R3LOAD and JLOAD control files. This is the key to understand why things are as they are. It also gives a better understanding of the ABAP dictionary.
• ABAP table types and storage parameters
• ABAP data types and data access through the DBSL interface • JAVA data types and data access through the JDBC interface
Unit Objectives
After completing this unit, you will be able to:
• Explain how Data Classes are used to map tables to database storage units • Understand how Data Classes are handled by R3LDCTL and R3LOAD • Create customer Data Classes
• Explain the purpose of table DBDIFF
• Understand how the R3LOAD/JLOAD data access is working
• Distinguish between the R3SZCHK behavior if the target database type is the same or different than the source database type
Unit Contents
Lesson: Data Classes (TABARTs) ... 106 Lesson: Miscellaneous Background Information ... 115 Exercise 6: Technical Background Knowledge ... 121
Lesson: Data Classes (TABARTs)
Lesson Overview
Purpose of Data Classes (TABARTs) in the ABAP DDIC and R3LOAD control files
Lesson Objectives
After completing this lesson, you will be able to:
• Explain how Data Classes are used to map tables to database storage units • Understand how Data Classes are handled by R3LDCTL and R3LOAD • Create customer Data Classes
Business Example
In the target database of a migration, some very large tables should be stored in customer defined database storage units. For that purpose, you need to know how the ABAP data dictionary and R3LOAD is dealing with Data Classes/TABARTs.
Figure 68: Definition
By this definition, examples of database storage units are: • Tablespaces (Oracle),
• Dataspaces (Informix),
• Tablespaces/containers (DB2 LUW)
TADM70 Lesson: Data Classes (TABARTs)
The table types are maintained in the ABAP Dictionary, regardless of the database used.
Figure 70: TABART – Table Types (2)
Tables in clusters or pools also contain TABART entries in their technical
configuration. These entries do not become active, unless the tables are converted to transparent tables.
Figure 72: TABART – Table Types (4)
Since NetWeaver '04, the above TABARTs can be found in any SAP System based on Web AS 6.40 and later. Even if no BW info cube was created, some tables do exist belonging to the TABARTs as shown above.
Figure 73: Tables DDART, DARTT, TS<DBS>
The TS<DBS> tables contain the list of all SAP defined storage units in a database. Table DDART contains all the TABARTs that are known in the SAP System. Table DARTT contains short TABART descriptions in various languages. Note: table TSDB2 may not exist in NetWeaver systems.
TADM70 Lesson: Data Classes (TABARTs)
Figure 74: Assignment: TABART – Database Storage Unit
R3LDCTL reads tables TA<DBS> and IA<DBS>, and writes the assignments between TABARTs and database storage units into DDL<DBS>TPL.
Tables TA<DBS> and IA<DBS> only exist for databases with the appropriate architecture.
Figure 75: Technical Configuration – Table DD09L
DD09L: ABAP Dictionary, technical configuration of tables (TABART and TABKAT) R3LDCTL extracts the corresponding TABART and size category (TABKAT) for each table, from table DD09L of the ABAP Dictionary. This information is written to the *.STR files.
Figure 76: Table and Index Storage Parameters
TG<DBS>/IG<DBS>: Assignment of size category (TABKAT = table category) to database storage parameters.
Table TG<DBS> gives R3LDCTL the information (i.e. for Oracle) about the size of “Default Initial Extent”, “Next Extent”, “Min Extent”, and “Max Extent”. This information is saved in the files DDL<DBS>.TPL. The assignment of a table to a specific table category is used to determine the “Next Extent Size” in *.STR. The “Initial Extent Size” actually used, is calculated and saved in *.EXT. Note: table TGDB2 and IGDB2 may not exist in NetWeaver systems.
TADM70 Lesson: Data Classes (TABARTs)
Figure 77: Creating New TABARTs (1)
If tables have been moved to customer-defined database storage units (that is, tablespaces) in the source database during a migration, these tables are only re-loaded into the correct storage units when tables DARTT, DDART, TS<DBS>, IA<DBS>, TA<DBS>, and DD09L have been maintained correctly.
The technical configuration of all tables (stored in DD09L) must include the correct TABART. After the tables have been unloaded, the files “DDL<Target DBS>.TPL” and “DDL<Source DBS>.TPL” should contain the customer-specific TABART and database storage unit names.
Note: change the content of DD09L by calling transaction SE11 (technical setting maintenance). This will be a modification and is shown in SPDD later on. If you use database tools (i.e. sqlplus) to update DD09L, the change is lost after an upgrade, if the corresponding large table is a SAP delivered one.
A fast check can be performed by calling R3LDCTL without parameters. R3LDCTL generates the files “SAP<TABART>.STR” and “DDL<DBS>.TPL” in the current directory. Duration: a few minutes.
See SAP Notes:
• 046272 Implement new data class in technical settings • 163449 DB2/390: Implement new data class (TABART)
Figure 78: Creating New TABARTs (2)
For information on how to create a new TABART, see SAP Note 46272.
A customer TABART name must start with “Z” or “Y”, and four additional characters. If SAPDBA or BRSPACE was used to create additional tablespaces, TABART names like U####, USR##, and USER#, can be seen as well. To prevent SAP upgrades from overwriting these definitions, the class for customer created TABARTs must be “USR”. In the example above, the new tablespace will be used for table COEP data and index storage location.
It is recommended to name new database storage units like the TABART to identify their purpose, but this is not strictly necessary.
See SAP Notes:
• 046272 Implement new data class in technical settings • 490365 Tablespace naming conventions
TADM70 Lesson: Data Classes (TABARTs)
Figure 79: Moving Tables and Indexes Between SAP Releases
During a homogeneous or heterogeneous R3LOAD system copy, tables may be moved unintentionally from one database storage unit to another. The reason for this could be that:
• Some tables were assigned to TABARTs of other database storage units, instead of being assigned to the TABART were currently being stored. R3LOAD always creates tables and indexes in locations obtained from the ABAP Dictionary. • Older SAP System Releases were installed with slightly different table locations
than subsequent releases.
• ABAP Dictionary parameters were not properly maintained after the customer had re-distributed the tables to new database storage units.
If it is essential to have single tables stored in specific database storage units, check the *.STR files before starting an import.
Table movement can significantly change the size of source and target database storage units.
If the Oracle reduced tablespace set is used for the target database, all thoughts about table and index locations are obsolete.
Lesson Summary
You should now be able to:
• Explain how Data Classes are used to map tables to database storage units • Understand how Data Classes are handled by R3LDCTL and R3LOAD • Create customer Data Classes
TADM70 Lesson: Miscellaneous Background Information
Lesson: Miscellaneous Background Information
Lesson Overview
Miscellaneous background information about table DBDIFF, R3LOAD/JLOAD data access, and R3SZCHK size computation.
Lesson Objectives
After completing this lesson, you will be able to: • Explain the purpose of table DBDIFF
• Understand how the R3LOAD/JLOAD data access is working
• Distinguish between the R3SZCHK behavior if the target database type is the same or different than the source database type
Business Example
You wonder why there are more tables in the *.STR files then visible in the ABAP dictionary transaction SE11, and some objects are defined even differently. You also want to know how the ABAP data types are translated into database specific data types.
Figure 80: Exception Table DBDIFF
R3LDCTL reserves special treatment for tables, views, and indexes contained in the exception table DBDIFF, since the ABAP Dictionary either does not contain information about these tables, or the data definitions intentionally vary from those in the database.
Generally, this involves database-specific objects and the tables of the ABAP Dictionary itself.
See related SAP Notes:
• 033814 DB02 reports inconsistencies between database & Dictionary • 193201 Views PEUxxxxx and TEUxxxxx unknown in DDIC
Figure 81: Database Modeling of the ABAP Data Types
The ABAP data types are modeled through the SAP database interface (DBSL) into the suitable data type for the database used. Refer to the ABAP Dictionary manual for further information.
The SAP<TABART>.STR files contain the ABAP data types, not the data types of the database.
Different databases provide different data types and limitations to store binary or compressed data in long raw fields. If necessary, the DBSL interface stores the same amount of data in a different number of rows, depending on the database type. R3LOAD uses the interface to read/write data to/from the database.
TADM70 Lesson: Miscellaneous Background Information
Figure 82: R3LOAD – ABAP Data Access
Figure 83: Consistency Check: ABAP DDIC – DB and Runtime
Transaction SE11 can be used to check the consistency of individual tables or views. In this process, the system checks whether the tables or view definitions in the ABAP Dictionary (DDIC) agree with the runtime object or database object. The data in the database is accessed via the runtime object of the active NAMETAB. Changes to the ABAP Dictionary are not written (and therefore are not effective) until they are activated in the NAMETAB.
The ABAP Dictionary should be OK in a standard SAP System. If you suspect that any tables are inconsistent, you can check them individually using transaction SE11.
Sometimes tables exist in the active NAMETAB but not in the database. In this case, R3LOAD will stop the export on error. Fix the NAMETAB problem with appropriate methods or mark the table entry as comment in the *.STR file.
Figure 84: ABAP Size Computation: Tables, Indexes, Database
In the case of a database change, the sizing information from the source database cannot be used to size the target database, since the data types and storage methods differ.
In the case of a homogeneous system copy, the size values can be taken from the source database. Tables that have a large number of extents can be given a sufficiently large initial extent in the target database.
To determine the correct size values, the database statistics (update statistics and so on) must be current.
Figure 85: JAVA Data Dictionary
The JAVA Web AS table and index definitions are stored as XML documents in the dictionary table.
TADM70 Lesson: Miscellaneous Background Information
Exclude lists tell JLOAD and JPKGCTL (JSPLITTER) which objects must not be exported and which objects need special treatment during the export (i.e. removal of trailing blanks)
A catalog reader (JAVA Dictionary browser) will be available with 7.10. Note: The JAVA Dictionary table will only be filled with the XML-documents, describing the table and indexes, if JLOAD is used! Do not mix a JLOAD import with other methods (i.e. database specific import tools).
Figure 86: JLOAD – Data Access
The SAP JDBC interface implements specific extensions to the JDBC standard, which are used by SAP Open SQL (i.e. the SAP JAVA DDIC, SAP transaction logic, SAP OPEN SQL compatibility).
TADM70 Lesson: Miscellaneous Background Information
Exercise 6: Technical Background
Knowledge
Exercise Objectives
After completing this exercise, you will be able to:
• Utilize the concept of TABARTs to create additional *.STR files. • Understand the function of the JAVA database interface
Business Example
You need to know how to handle customer specific Data Classes/TABARTs and you are interested in information about how the ABAP and JAVA data types are converted to database specific data types.
Task 1:
The OS migration of a large Oracle database was utilized to move the heavily used customer table ZTR1 to a separate table space. For that purpose the necessary tasks were done in the ABAP dictionary: TABART ZZTR1 was created and the tablespace name PSAPSR3ZZTR1 was defined.
1. Which changes were done to the ABAP dictionary of the source system? Which tables were involved? Note the table entries.
Task 2:
A customer database was exported using R3LOAD. A look into the export directory shows that no additional *.STR files exist for tables, which were stored in separate Oracle tablespaces. The ABAP dictionary tables, which are used to define additional TABARTs, containing the list of tablespaces, and the mapping between TABART/tablespace, were properly maintained.
1. What is the reason that no additional *.STR files were created besides the standard ones?
2. What can be done in advance to check the proper creation of an *.STR file before starting a time consuming export? Which steps are necessary?
Task 3:
The *.STR files contain database independent data type definitions as used in the ABAP dictionary.
1. How is R3LOAD able to convert database independent into database specific data types?
Task 4:
Every database vendor provides a JDBC interface for easy database access. interface? 1. Why is SAP using its own JDBC interface?
TADM70 Lesson: Miscellaneous Background Information
Solution 6: Technical Background
Knowledge
Task 1:
The OS migration of a large Oracle database was utilized to move the heavily used customer table ZTR1 to a separate table space. For that purpose the necessary tasks were done in the ABAP dictionary: TABART ZZTR1 was created and the tablespace name PSAPSR3ZZTR1 was defined.
1. Which changes were done to the ABAP dictionary of the source system? Which tables were involved? Note the table entries.
a) Define new TABARTs ZZTR1 in tables DDART and DARTT. b) Add the new tablespace name to TSORA.
c) Map TABART ZZTR1 to tablespace PSAPSR3ZZTR1 in tables TAORA and IAORA.
d) Change the TABART entry for table ZTR1 to ZZTR1 in table DD09L.
Note: Table and index data can also be stored in the same
tablespace.
Task 2:
A customer database was exported using R3LOAD. A look into the export directory shows that no additional *.STR files exist for tables, which were stored in separate Oracle tablespaces. The ABAP dictionary tables, which are used to define additional TABARTs, containing the list of tablespaces, and the mapping between TABART/tablespace, were properly maintained.
1. What is the reason that no additional *.STR files were created besides the standard ones?
a) The technical settings (table DD09L) of the involved objects were not changed. The existence of customer TABARTs does not cause the creation of additional *.STR files, if no tables have been mapped to it.
2. What can be done in advance to check the proper creation of an *.STR file before starting a time consuming export? Which steps are necessary?
a) R3LDCTL can be executed stand-alone as the <sapsid>adm user. If no command line parameters are provided, R3LDCTL will create *.STR and DDL<DBS>.TPL files in the current directory. It will take a few minutes. The created files can then be checked for proper content.
Task 3:
The *.STR files contain database independent data type definitions as used in the ABAP dictionary.
1. How is R3LOAD able to convert database independent into database specific data types?
a) R3LOAD does not need specific knowledge about the data types of the target database, because it calls the database interface (DBSL), which knows how to handle them.
Task 4:
Every database vendor provides a JDBC interface for easy database access. interface? 1. Why is SAP using its own JDBC interface?
a) Standard JDBC interfaces do not provide features required by SAP applications. Important JDBC extensions are the usage of the SAP JAVA Dictionary and the implementation of the SAP transaction mechanism.
TADM70 Lesson: Miscellaneous Background Information
Lesson Summary
You should now be able to:
• Explain the purpose of table DBDIFF
• Understand how the R3LOAD/JLOAD data access is working
• Distinguish between the R3SZCHK behavior if the target database type is the same or different than the source database type
Unit Summary
You should now be able to:
• Explain how Data Classes are used to map tables to database storage units • Understand how Data Classes are handled by R3LDCTL and R3LOAD • Create customer Data Classes
• Explain the purpose of table DBDIFF
• Understand how the R3LOAD/JLOAD data access is working
• Distinguish between the R3SZCHK behavior if the target database type is the same or different than the source database type