System Copy

Plan to perform the system copy.

1
1. Consider the downtime of the source system (for preparations and
copying) when planning the system copy.
2. Perform a test run of the system copy. You can use the time taken by the
test run to calculate the system downtime:
3. If target system will replace source system, try to perform a complete test
run. This means that the entire database is exported from the source
system, transferred to the target system, and imported there. System
downtime is approximately equal to the total test time (that is, time for
export, transport, and import).
4. The source system is only down for the time of the export.
5. Calculating the system downtime is particularly important for very large
databases (VLDB) or when tapes are being used. The test run is also to
determine the amount of export data. Choose the best data transfer
method (for example, FTP or tape). We recommend that you only perform
read/write actions on local file systems.

Describes the system copy procedure to be used

a. Database In depended System Cop

b. Database-Specific System Copy

i) Backup Method

ii) Unload the source Database and load the data into Target Database

The following example describes the system copy procedure of the productive PRD
SAP system to the Sandbox system (SNB).

Preparations:

1. First export parts of the Java source system. For this, We must use the delivered SAP
installation master DVD of installed SAP release. The export of the Java part into a
file is then created using the option 'system copy'.
2. Establish whether you use a schema system or not.
In the SAP system, choose the menu option "System" -> "Status" and check the value
 of the field "Owner". In a schema system (MCOD), the owner has the value <sid>,
while the value is 'dbo' in a non-schema system.
3. Install the SQL Server and the SAP system on the target system. Prepare the source
database using the homogenous system copy guide.
4. We must ensure that all prerequisites (SQL Server collation, SQL data types, SAP
Basis Support Packages, and so on) are fulfilled.
5. Delete the automatically generated stored procedures.
Using the SQL Server Query Analyzer or the SQL Server Management Studio,
execute the following commands in the SAP database:

Schema system:

use <SAPSID>
go
setuser '<sid>'
go
exec sap_droproc

Non-schema system:

use <SAPSID>
go
exec sap_droproc

These commands delete all temporary stored procedures in the database. They are
created again automatically if necessary while the SAP system is operating.
6. If COLDER system was configured for Performance Warehouse Monitoring by
Solution Manager, we must read Note 1388700, since important post-processing steps
are required after the database copy.

Determine the file structure of the source database

1. Determine the file structure of the source database using the Server Query
Analyzer. Connect to the database to be copied and execute the command
sp_helpfile. This command provides the physical name (file name) and the
logical name (name) of all database files.

Example:

use PRD
exec sp_helpfile

Result:
name fileid filename filegroup size
-------- ------ ------------------------- --------- -----------
 PRDDATA1 1 d:\PRDDATA1\PRDDATA1.mdf PRIMARY 11214912 KB
PRDLOG1 2 e:\PRDLOG1\PRDLOG1.ldf NULL 287816 KB
PRDDATA2 3 d:\PRDDATA2\PRDDATA2.ndf PRIMARY 1951744 KB
PRDDATA3 4 d:\PRDDATA3\PRDDATA3.ndf PRIMARY 1953792 KB

Create the directory structure for the target database

In the target system, create the directory structure for the data and log files of the
SQL Server. The target database can be located on the same server or on another
machine. The target database name can differ from the source database name. It
must differ from the source database name in the case of the same SQL Server
instance. Directory and file names should correspond to the SAP naming
conventions. Create the directories <target_SID>DATA and <target_SID>LOG.
Sufficient place must be available on the target system for the data and log files.

Example:

You must copy the source database PRD to a target database QAS. On the target
system, you must create the directories QASDATA1, QASDATA2, QASDATA3, and
QASLOG1. They can be distributed on different drives (in our example, the data files
are on drive g:, the log file is on drive h:).

Detaching the source database

To reattach a database successfully to an SQL Server, you must first detach it from the SQL
Server using the stored procedure sp_detach-db or recover it successfully.

• To recover the database, you must simply start the SQL Server and stop it again. You can
then copy the database files at system level. This procedure is safer than the stored
procedure 'sp_detach_db', since you do not have to detach the source database from the
SQL Server.

• The stored procedure sp_detach_db separates a database from the SQL Server. This
corresponds to a deletion (Drop) of the database without eliminating the respective files.
The database can be reattached to the SQL Server later using sp_attach_db.

Note that detaching and attaching the database can cause problems; this is described in
Note 806925.
You must set all activities on the source database. You should restart the SQL Server.
Execute the following command in the Query Analyzer:
 use master
exec sp_detach_db '<SID>', true

After you have done this, the server no longer recognizes the database <SID>.

Example:

use master
exec sp_detach_db 'PRD', true

Copying the data and log files

Copy the data and log files into the relevant target directories of the target
computer. You may rename the files if required.

Example:

copy d:\PRDDATA1\PRDDATA1.mdf g:\QASDATA1\QASDATA1.mdf

Reattaching the source database

You can make the source database available again using 'sp_attach_db'. sp_attach_db requires
the name of the database and a list of physical file names (complete path names) as a parameter.
The list must contain the master data file (*.mdf) and all files whose physical location or name
were changed.
Therefore, for the source database, you only need to call 'sp_attach_db' with the name of the
initial database and the complete path names of the master data file since no files or names have
changed in this database.

Example:

exec sp_attach_db 'PRD', 'd:\PRDDATA1\PRDDATA1.mdf'

Step 7: Attaching the target database

Execute the following command in the Query Analyzer in the target system:

Example:

use master
exec sp_attach_db 'QAS',
'g:\QASDATA1\QASDATA1.mdf',
'g:\QASDATA2\QASDATA2.ndf',
'g:\QASDATA3\QASDATA3.ndf',
'h:\QASLOG1\QASLOG1.ldf'
Since the location and the names of the files have changed, you have to specify all database files:
The command 'sp_attach_db' only supports up to 16 data or log files. If the database contains
more than 16 files, use the command 'CREATE DATABASE FOR ATTACH'. You will find the
exact syntax description of this command in the SQL Server Books Online.
Note that detaching and attaching the database can cause problems; this is described in Note
806925.

For a cluster installation, also see Note 910012.

Homogeneous System Copy

During the system copy you use the same operating system and database
platform as the original system.

System Copy

Duplication of an SAP system. Certain SAP parameters might change in a copy.

When you perform a system copy, SAPinst installs all the instances again, but it
uses a copy of the source system database to set up the database.

This section describes how to plan your system copy.

Make sure that all required DVDs for the system copy are available:

Required DVDs

Installation Master DVD

Java DVD
Make sure that the versions of the SAP system and the installation tools are the
same on the target and source systems

The source system must be in a consistent state before you can copy it.

Creating System Copy Plan

1. Consider the downtime of the source system (for preparations and

copying) when planning the system copy.
2. Perform a test run of the system copy. You can use the time taken
by the test run to calculate the system downtime:

If your target system will replace your source system, try to perform
a complete test run. This means that the entire database is
exported from the source system, transferred to the target system,
and imported there. System downtime is approximately equal to the
total test time (that is, time for export, transport, and import).

If you do not want to replace your source system, a partial test run
(export of the entire database or parts of it) can be sufficient to
calculate the system downtime. The source system is only down for
the time of the export.

Calculating the system downtime is particularly important for very

large databases (VLDB) or when tapes are being used. The test run
is also to determine the amount of export data. Choose the best
data transfer method (for example, FTP or tape). We recommend
that you only perform read/write actions on local file systems.
3. Decide Which System Copy procedure to be used
 R3Load for ABAP Part and JLoad for JAVA Part
 Backup/Restore or Detach/Attach method.