SAP Basis Tech Supports

Symptom
You use a MaxDB Content Server database, and you want to copy it to another host.
1. To do this, you use a homogeneous system copy with the backup/recovery procedure.
Homogeneous system copies (backup/recovery) may only be executed in the following systems:
a) systems where the database version is the same in both source and target system
b) systems where the processor uses the same byte sorting sequence (Little Endian -> Little Endian; Big Endian -> Big Endian). Note 552464 describes the permitted combinations. The current MaxDB documentation provides a complete matrix under
German: Grundwissen -> Konzepte des Datenbanksystems -> Verwaltung -> Replikation und High-Availability -> Datenbankkopie -> Kompatible Prozessorarchitekturen f黵 Datenbankkopien
English: Basic Concepts -> Administration -> Replication and High Availability -> Database Copy -> Compatible Processor Architecture for Database Copies
For information about the homogeneous system copy process, refer to Note 129352.2. Heterogeneous system copies
If the homogeneous system copy procedure cannot be used for a Content Server for one of the reasons specified under 1., the system copy of a Content Server Storage (SDB) with MaxDB uses the database loader (loadercli) instead of the R3load.
This procedure is described here.
C A U T I O N:
In your source system, check the setting of the following parameter: _UNICODE
If the parameter _UNICODE is set to the value NO, and you want to start the target system with MaxDB Version 7.6, you can use the procedure described here for the import into target system only with MaxDB Version 7.6.05 build 11 or higher (PTS: 1157386).
The required MaxDB version is available on SWDC.
Note that the target system must be installed at least with 7.6.05 build 11. An upgrade to this version does not help. Stop the target system (shutdown) and delete the database instance (drop database). SAPinst provides the option ‘uninstall’. Here, you are led through the uninstalling process. The repeat the software installation with 7.6.05 build 11 or higher.
Other terms
Heterogeneous system copy, content server, loader, loadercli, encoding type of source and target database do not match: source = ASCII target = UNICODE;
Reason and Prerequisites
1. You use the Content Server on a MaxDB2. For loading and unloading you require at least a loader Version 7.6.05 build 11 or higher (regardless of which database kernel version you use).
You can determine the loader version on your system by using, for example, ’sdbregview -l’. If you require an update, refer to Note 649814.3. Important: You must use the same binary-compatible loader for the entire export an import; for example, you cannot start the export with a Windows ‘little endian’ loader and then carry out the import with a loader under AIX ‘big endian’. For the entire process (export and import) you must only use the loader of the source system or only the loader of the target system. Using a combination of both will later cause a termination due to missing binary compatibility.
We recommend to use the loader of the target system (since the ‘loadercli’ version is more recent or the same as the one on the source system).4. In your source system, you use SAPDB Kernel Version 7.3.00 Build 57 (PTS 1143300) or higher, or MaxDB Kernel Version 7.5.00 Build 40 (PTS 1143301) or 7.6.00 Build 31 or higher.5. In your target system, you use SAPDB kernel Version 7.3.00 build 57 (PTS 1143300) or higher, or MaxDB kernel Version 7.5.00 build 40 (PTS 1143301) or 7.6.05 build 11 (PTS 1157386) or higher.6. If the minimum required version 7.3.00 Build 57 is not yet available on the SAP Service Marketplace, you must first upgrade the Content Server Version 7.3. to Version 7.5.00 Build 40 before you can execute a heterogeneous system copy.7. The procedure described in this note supports the following migrations:The source system has the same database kernel version as the target system.The source system has a lower database kernel version than the target system.The source system runs on a 32-bit platform, and the target system runs on a 64-bit platform.The source system has an ASCII database catalog (parameter _UNICODE = NO), and the target system has a UNICODE database catalog (parameter _UNICODE = YES). Each default installation as of MaxDB Version 7.6 has a UNICODE database catalog (_UNICODE=YES).
Solution

For performance reasons, it always makes sense to start the loader on the host that takes less time.
To execute the system copy, proceed as follows:
1. Actions in the source system:
a) Check DATA
Execute a Check DATA (Verify) in the source system. This checks whether the data in the source database SDB (Content Server) is consistent.
b) CREATE INDEX (Kernel Version 7.3 and 7.5 only)
To speed up the subsequent execution of the loader actions, create an index in the source system as an <sysdba> user (for example, SUPERDBA) with SQLStudio:
CREATE INDEX PACKAGE_INDEX ON
TRANSFORMATIONMODEL (PACKAGEGUID,OWNER,TABLENAME)
c) Control file for unloading the catalog and data
On the Content Server, all data belongs to the user SAPR3, which means that you can unload all repositories with the EXPORT USER command.
You need a command file for the MaxDB loader to export the data in the source system. The data must be unloaded page-by-page.
Example of an ‘SDB_EXPORT.sql’ control file created for the export into the file system in the ‘c:\export’ directory:
EXPORT USER
catalog outstream file ‘c:\export\SAPR3.cat’
data outstream file ‘c:\export\SAPR3.data’ PAGES
package outstream file ‘c:\export\SAPR3.pack’ csv
The SAPR3.cat file contains the catalog information of the Content Server (CREATE commands and so on).
The files SAPR3.data<nnnn> contain the content server data, SAPR3.data0000 is an administrative file required for a later import.
The SAPR3.pack file is a log file for support in case of an error.
Adjust the directory details in accordance with your system environment. Note that the directories must be set up on a sufficiently large disk or file system to ensure that all data can be saved to that location.
You can also unload the data using remote pipes or external tape drives. If you do so, adjust the sample script provided above accordingly.
The directory into which the data is loaded can also be shared or mounted for the import into the target system.
d) Unloading the data
Start ‘loadercli’ as follows:
loadercli -d <source DBNAME> -u <USER>,<PASSWORD> -n <source hostname> -b <EXPORT USER Script>
Example:
loadercli -d SDB -u SAPR3,SAP -n comp1234 -b c:\export\SDB_EXPORT.sql
If the error “-1013 Too many order columns” occurs during the export, and if the file SAPR3.data0000 was not generated, see Note 1171018.2. Actions in the target system:
a) Installing the software
You have already installed the Content Server database software in the target system with the relevant MaxDB version and created an SDB database.
b) CREATE INDEX (7.3 and 7.5 target systems only)
If the target system has database Version 7.3 or 7.5, you must create the following index as an SYSDBA user (for example, SUPERDBA) with SQLStudio to speed up the loading process (not necessary as of 7.6):
CREATE INDEX PACKAGE_INDEX ON
TRANSFORMATIONMODEL (PACKAGEGUID,OWNER,TABLENAME)
c) COLUMNCOMPRESSION (target systems with Version 7.6 or higher)
If the target system has MaxDB Version 7.6 or higher, you must check the parameter configuration of the COLUMNCOMPRESSION support parameter in the target system. The correct setting (for the duration of the import) depends on the database version of the source system.
Source version Parameter setting in target system
7.3 COLUMNCOMPRESSION= NO
7.4 COLUMNCOMPRESSION= NO
7.5 COLUMNCOMPRESSION= NO
If the source system has MaxDB Version 7.6 or higher, the COLUMNCOMPRESSION parameter in the target system for the duration of the import must be set to the same value as in the source system. The COLUMNCOMPRESSION parameter can be changed ONLINE.
d) Control file for loading the catalog and data
You need a command file for the loading process. The data is loaded page-by-page.
Example of an ‘SDB_IMPORT.sql’ control file created for the import into the file system in the c:\import directory:
IMPORT USER
catalog instream file ‘c:\export\SAPR3.cat’
data instream file ‘c:\export\SAPR3.data’ PAGES
package outstream file’c:\import\SAPR3.pack’ csv
e) User schema
The data is loaded in the schema of the database user. If this database user has not yet been created in the target system, the loading process terminates and the system issues an error message.
Use the SQLStudio to check whether the the user SAPR3 has already been created in the target system:
Log on to the SQLStudio as the database user SUPERDBA. If the command SELECT * FROM USERS shows:that the user SAPR3 already exists, you can perform the import as described below in section f).that the user SAPR3 does not yet exist, you must create it as follows before you can start the import:
create user SAPR3 password sap DBA not exclusive
f) Loading process
As mentioned above, you should make sure that you only use the loader of the source system or the loader of the target system for the entire export and import process. Subsequently changing the loader causes an error during the import, as the versions are not binary-compatible.
If the data is on the target host, the loader is started there, and the option -n is not required.
loadercli -d <targetDB> [-n < target-server>] -u <USER>,<Password> -b c:\import\SDB_IMPORT.sql
Example of loading from the source system:
loadercli -d SDB -n <host_target> -u SAPR3,SAP -b c:\import\SDB_IMPORT.sql
Example of loading from the target system:
loadercli -d SDB -u SAPR3,SAP -b c:\import\SDB_IMPORT.sql
g) Backup
The data is write-protected after page-by-page loading into the target database. A database backup (SAVE DATA) is therefore essential once the loading process is completed and before production operation is resumed.