Homogeneous system copy with MaxDB (SAP DB)

This note is used as an addition for the notes "INST: X.XX R/3 Inst. - Homogeneous System Copy"

You want to import a backup from a SAP DB or MaxDB database instance into another SAP DB or MaxDB database instance of the same version.

See Notes 457425 and 632357 if you want to carry out a system copy for an SAP liveCache instance.

To generate a database copy, import the backup of a source system into the target system.
To import a backup from another system, a 'normal' recovery is not sufficient. An 'Instance install' or an 'Recovery with Initialization' must be carried out.

Prerequisites:

Both databases have the same version (7.x.x) in the first three places. The build level of the target instance version is equal to or higher than the build level of the source instance.
As of Version 7.6, the Support Package level (that is, the third place) of the target instance may be larger than the relevant level of the source instance.

You use the Database Manager GUI for database administration. In the first three places, the version of the Database Manager GUI should be higher than or equal to the version of the database kernel. If the first 3 digits are the same as this version, the last two numbers (build level) of the DBMGUI version can be lower than the numbers of the database kernel.
As of Version 7.6, the third place of the DBMGUI version may be lower than the version of the database core.

Version 7.2 and 7.3
Either you generated a consistent data backup (migration) on the source system or subsequent log backups or consistent incremental backups are available on the source system.

You are using Version 7.4 or higher.

As of Version 7.4, data backups always contain a transaction-consistent status of the data. You do not need the migration option to create a backup.
A backup medium or backup media with which you can import the backup(s) was/were created in the target system.
Target system size:
The target system can be smaller or larger than the source system.

Version 7.2 and 7.3:
The minimum target system size is as large as the highest assigned page number in the source system (LAST DATA PNO). You can determine this value in the source system using the following call (Command Prompt or UNIX shell):
Version 7.2. or 7.3. (one line!):
dbmcli -d <database_name> -u <dbm_user>, <password> -n <database_server> -uSQL sapr3,sap sql_execute "select maxdatapageno from sysdba.serverdbstatistics"

This value may be reduced by a restart (release of temporary pages).



You are using Version 7.4 or higher.
The minimum target system size is as large as the number of assigned permanent pages in the source system. Configure the target system in such a way that it does not become full after the first restart. You can determine the number of assigned permanent data pages in the source system using the following call:

dbmcli -d <database_name> -u <dbm_user>, <password> -n <database_server> -uSQL sapr3 ,sap sql_execute 'select "Perm Data (Pages)" from info_state'

As of Version 7.5:
dbmcli -d <database_name> -u <dbm_user>, <password> -n <database_server> info state

You are using Version 7.6 or higher.
As of Version 7.6, you can reduce the database online by deleting data volumes.



If you do not wish to create the migration backup physically, you can use remote pipes for transporting the backup. For more information, see Note 489615.


You can only import backups of the database instance into systems where the processor works with the same byte-assortment (Little Endian -> Little Endian; Big Endian -> Big Endian). Note 552464 describes the permitted combinations. The current MaxDB documentation displays a complete matrix under
German: Grundwissen -> Konzepte des Datenbanksystems -> Verwaltung -> Replikation und High-Availability -> Datenbankkopie -> Kompatible Prozessorarchitekturen für Datenbankkopien
English: Basic Concepts -> Administration -> Replication and High Availability -> Database Copy -> Compatible Processor Architecture for Database Copies.
Note 767598 contains the links you need to follow to access the documentation.

Backups of a 32-bit system can be imported into a 64-bit system and vice versa.

Solution
Carry out the following steps for the system copy:

The First and Second Edition of the Database Manager GUI are both available. We recommend that you use the newer Second Edition, which is available from the SAP Service Marketplace. This note describes both tools.


1. Source system:

Create a full backup of the system:
Database Manager GUI First Edition:
DBMGUI -> Backup -> Complete or
Database Manager GUI Second Edition:
DBMGUI -> Backup -> Backup Wizard -> Complete


Provided no consistent backup ('for Migration') is generated with Version 7.2, or 7.3, you must then create a log backup or a consistent incremental backup.

2. Target system:
a) Software:
If you are rebuilding the system from scratch (in other words, there is no software installed), use R3INST, R3Setup, or SAPINST to import the SAP instance software and the database software. After you have done this, you can terminate the installation program (if supported).
b) Restore:
Before the restore, you must initialize the target instance. This initialization formats the log area. Data volumes are only formatted if they are not configured as raw devices and are not available in the configured size.

Database Manager GUI Second Edition:
If you use Database Manager GUI Second Edition or Database Manager GUI Version 7.5 or newer, then start the Recovery Wizard under "Recovery with Initialization..."
The documentation describes how to use this wizard. Note 767598 contains the links you need to follow to access the documentation. The part that is relevant for the Restore is in:
-> MaxDB

-> Tools

-> Database Manager GUI

-> Restoring Data

-> Restoring After Initializing a Database Instance





If you use DBMGUI Version 7. 5 and instances of versions lower than 7.5, read Note 864650.



Database Manager GUI First Edition:
If you use the First Edition Database Manager GUI, proceed as described below:

Select the menu item 'Instance -> Install'.
Specify the name of the target database as the database name -> Next.
If the database instance already exists, choose 'reinstall' in the popup that follows. If the database instance does not yet exist, you must select the software version (according to the version of the source system).
Enter DBM user (control) and SYSDBA user (superdba) -> Next.
If the database instance is not in the OFFLINE operating state, you must now confirm the stop.
If you want to transfer the current database parameters, select 'Use current parameters' in the window that follows. Otherwise, you can transfer the parameters of the source system from the backup or assign the default values to the parameters -> Next. Next
Check the parameters and correct them if necessary -> Next.
Check the devspace information and correct it if necessary.
Select the 'Restore Instance' option -> Next.
Check the information you entered -> Install.
The installation then executes the 'Start instance' and 'Initialize configuration' steps. Now you have to register the newly installed database instance in the Database Manager GUI.

You must then proceed as follows in the Database Manager GUI to import the data backup (make sure that the desired database instance is selected).

Select the menu option 'Recovery -> Database'
Under no circumstances should you restart before the recovery - if you do, the following error occurs after the restore - '-8003: log and data must be compatible' .
Select 'Restore Medium' -> Next Step.
Select the relevant backup medium -> Next Step.
Start Restore with 'Start'.
After you have imported the data backup, import additional backups or press the 'Restart' button in the template.
If you use external backup tools and a Database Manager GUI version that does not yet support external backup tools during the restore, proceed as described in Note 387583.

c) After the restore, delete all entries from the following tables so that the CCMS in the newly structured system does not display any actions (such as: backups and update statistics runs) from the original system:
CNHIST, CNREPRT, CNMEDIA, DBSTATHADA, DBSTATIHADA, DBSTATIADA, DBSTATTADA, SDBAADAUPD
d) Load the system tables in the target system using the following command:
dbmcli -d <database_name> -u <dbm_user>, <password> load_systab -u <sysdba_user>, <password> -ud <domain_user_password>

(enter in one line, for example: dbmcli -d N01 -u control,control load_systab -u superdba,admin -ud domain)

e) If the name of the database user who owns the application data is SAP<sid>, you can rename the user SAP<newsid>. To do this, use the following command:
dbmcli -d <newsid> -u control,control -uSQL superdba,admin
sql_execute rename user SAP<sid> to SAP<newsid>
Then, as described in Note 39439, adjust the XUSER entries for the central instance and for all application servers.
In the case of MCOD systems, you can carry out this step for each SAP instance.

If you cannot or do not want to rename the user, you can set Profile Parameter dbs/ada/schema as of SAP Version 6.20. Example:
dbs/ada/schema=SAP <oldsid>
This is especially applicable if you copy a system that was migratedfrom an earlier SAP release and the user is still SAPR3:
dbs/ada/schema=SAPR3