System Copy In Sap Basis


If you copied a BW system, you must adjust the SAP HANA calculation to the new system names views after the migration. This is done when calling the report RSBWPOSTMIGRATION with all options. This completes the system copy. Reference SAP note:- 1844468 – Homogeneous system copy on SAP HANA. Copy all archive files created since online backup on source system to archive directory of target system. Archive file names are different from asked during recovery session. You can change archive file names for target system via the following script.

1. What takes place during a homogeneous system copy?

The main purpose of a homogeneous system copy is to build a test, demo or training system or to move a system to a new hardware. The difference to a heterogeneous system copy is that both the database and operating system remain the same. Because of this, there is the possibility on some platforms to perform the copy using database-dependent methods (such as backup/restore). Note that no matter if you change the version or bit version of either the operating system or the database, the system copy is still considered to be a homogeous system copy (for example, the system copy from Microsoft Windows 2000 32-bit to Microsoft Windows 2003 x64).

2. What takes place during a heterogeneous system copy (migration)?

System Copy In Sap Basis
The main purpose of a heterogeneous system copy is to create a copy of an already existing SAP system on the platform where either operating system, or database, or both differ from the operating system/database of the source system. The whole migration process consits of five main steps (described in detail in the system copy documentation):
  1. Preparation steps on the source system
  2. Export of the source system data into database-independent format
  3. Transfer of the exported files to the target host
  4. New system installation together with data import
  5. Post-processing steps within the target system

3. Which tools are used during a migration on source and target systems?

The main programs used for the migration - depending on the kernel release - are R3SETUP, SAPinst or software provisioning manager. During execution, they call other programs for particular purposes (such as R3LOAD, R3LDCTL, R3SZCHK) that use different command files. For a technical overview, see this document.


4. What is the purpose of the files that are used during a migration?

  • DDL<db_type>.TPL is used for creation of table/index definition in database-specific syntax and contains negative list of tables, views and indexes, assignment of TABARTs to storeage unit and next extent size of table/index. TABART stands for a data class. For more information, see SAP Note 46272 (SMP login required).
  • SAP<TABART<.STR contain table/index definitions from the ABAP Dictionary.
  • SAP<TABART.CMD contain definitions of path and names for corresponding STR, TOC, EXT files,DDL<db_type>.TPL, export directory, block and file sizes.
  • SAP<TABART>.<nnn> (<nnn> = 001, 002, ..), so called dump files, contain the data of all tables of a tabart in a non-platform-specific file format. These are binary files and they should never been changed/edited!
  • SAP<TABART>.EXT contain initial sizes for tables and indexes. Not applicable to some databases (such as for Microsoft SQL Server).
  • SAP<TABART>.TOC contain position of table data within the corresponded dump file, name of the dump file, time stamp of unload, and table rows number. TOC files must never be changed without approval of SAP support.
  • SAP<TABART>.log contain log file information in case of errors and for restarting.
  • SAP<TABART>.TSK are files used by R3load - for more information, see SAP Note 455195 (SMP login required).

5. What interdependencies to kernel versions have to be considered?

For the ABAP kernel tools used during a migration, some rules should be followed:
  1. Tools used at the export on the source system must have the same version as on the target system.
  2. Tools used must all have the same kernel version (do not mix up kernel tools of different releases, as otherwise, different versions of the called programs - such as R3load - might be used for export and import).
  3. Tools must have the same kernel release as the system that is migrated.
These rules should be applied, unless specified otherwise in an installation/migration SAP Note or documentation. Keep this in mind when downloading a patched version of any mentioned tool from SAP Service Marketplace!
The Java system copy tools do not depend on the kernel version and you can always use the latest version of these tools.
For more information about dependencies to kernel versions for ABAP and Java systems, see SAP Note 784118(SMP login required).

6. What requirements should be met before a migration starts?

See SAP Note 82478 (SMP login required).

7. Is a migration of a specific product/OS+DB combination supported?

First, check whether both the source and the target product/OS+DB combination is supported - for this, refer to thePlatform Availability Matrix available in SAP Service Marketplace at: http://service.sap.com/pam (SMP login required).
In addition, check both the system copy documentation and the relevant SAP Notes for any possible restrictions.

8. Where can I find information on how to optimize the overall runtime of a system copy?

See the corresponding documents on the System Copy and Migration document.

9. Is it possible to perform a final migration of a productive system without a 'test' run?

No, you should always perform a test migration on a comparable hardware with a system that is using a copy of the production database. This is necessary both to get an idea about the overall runtime of the production migration and to recognize possible major issues of the procedure before the final migration

What is Homogeneous system copy?

If a system copy takes place between systems with same platform (operating system and database system), then it’s called HOMOGENEOUS SYSTEM COPY.

Reasons for Copying a SAP System

  1. To create a new training system for end-user or project team education
  2. To create a DEMO system
  3. To create a Test system for upgrade or other purposes.
  4. To recover a system on another machine with the same platform after a crash.
  5. To copy large clients. If a client very large to export/import, it is better to do a system copy rather than client transport.

Methods for homogeneous system copy

· Backup and restore method(DOES NOT REQUIRE PRD DOWNTIME)

· By using SAPinst import/export method(REQUIRES SIGNIFICANT AMOUNT OF DOWNTIME)

Note:- In our case I am going to follow backup and restore method since no downtime required, henceforth this guide is prepared for a Homogeneous System Copy using Online/Offline Database Backup

Homogeneous System Copy using Online/Offline Database Backup

. Steps for a Homogeneous system copy are briefly as below:

  1. Preparations on Target System.
  2. Restore Online/Offline Backup of Source System onto Target System.
  3. Create CONTROLFILE creation script on Source System.
  4. Modification of CONTROLFILE script and creation of CONTROLFILEs of Target System.
  5. Recovery of Oracle Database on Target System.
  6. Completion of System Copy.

Prerequisites

Following conditions must be provided to copy a system:

  1. Both Source and Target Systems must have Same Operating System and Database System. Also Patch levels must be same.
  2. You have sufficient free space for sapdata directories on target system.
  3. For Windows systems, you have to create all drives where datafiles resides on source system.
  4. Use most current database backup in order to shorten database creation time.

Procedure

Data and Log directories on target system must be cleaned before restoring source database. Here below are the commands to clean directories. Before this, you have to stop all SAP and Oracle processes in service.msc.

  1. You have to resize the following file systems before restore process. Take into account sizes of source system.
  2. /oracle//sapdata1 /oracle//sapdata2 /oracle//sapdata3 /oracle//sapdata4 /oracle//sapdata5 /oracle//sapdata6 /oracle//saparch

After cleaning necessary file systems/directories, you have to restore most current database backup to target system. For this, find the detail backup log (e.g. bdkxxsrh.anf) for that backup on source system. You can determine this from back.log summary backup log file or using DB12. Copy this detailed backup log file into /oracle//sapbackup directory on target system. Use BRRESTORE command below to restore the source database on target system

Use the following command to begin restore:

cd sapbackup

brrestore -m full -b (det_log_file= for example bdkxxsrh.anf)

At the first step of restore, system will recognize that the Oracle SID is different on target machine (where the restore command executed) and in backup. Also, Oracle_Home parameters in backup and in current system will be different and recognized by brrestore. But the restore command will restore the datafiles to match current systems file system.

All the datafiles and online redolog files (only for Offline DB Backup) must be successfully restored.

At this step, there are 3 probabilities that must be taken into account for the following steps.

i. You are using an online database backup of source system to create target system.

You have to find and put all archive files created during online backup into target systems archive directory to be able to recover database. You can also apply all the archives created from the online backup start time to latest available.

ii. You are using an offline database backup of source system which is running in ARCHIVELOG mode to create target system.

You may find the archive files created after offline backup on source system to make database current on target system via applying during recovery.

iii. You are using an offline database backup of source system which is running in NOARCHIVELOG mode to create target system.

You don’t have any archive files created on source system so you don’t need anything.

After restoring datafiles and redolog files, a script must be prepared on source system to create CONTROLFILE of target system.

Use SQLPLUS to create a script to create controlfile using current CONTROLFILE content. Login to source system as QSGadm user and execute the following SQLPLUS commands. To be able to execute following commands, database must be at least in MOUNT mode.

SQL>alter database backup controlfile to trace;

As a result of this command, a trace file (e.g. qsg_ora_6944) will be created under /oracle//saptace/usertrace directory.

You have to edit this file to be able to use for CONTROLFILE creation on target system.

a. Rename file name as CONTROL.SQL

b. Open file to edit using NOTEPAD.

Sap Basis Administrator Jobs

c. Remove all lines before “STARTUP MOUNT” line. Delete all commented “#” lines. Also remove all lines after CHARACTER SET UTF8;” line.

d. Change all Source PSG SID to QSG SID (use ctrl+H)

Change the line

CREATE CONTROLFILE REUSE DATABASE ‘PSG’ NORESETLOGS ARCHIVELOG;

As follow

CREATE CONTROLFILE REUSE SET DATABASE ‘QSG’ RESETLOGS ARCHIVELOG;

If you want to change datafile or redolog file destinations, first move the files on target destination at OS level, then edit CONTROL.SQL file for new destinations.

After CONTROL.SQL script preparation, following commands must be run to create CONTROLFILE of target system:

Database will be in inconsistent status after creation of CONTROLFILE. This can be viewed by trying to open the database.

SQL> alter database open;

alter database open * ORA-01589: must use RESETLOGS or NORESETLOGS option for database open

At this step, a recovery must be made in order to be able to use the database.

If your source system is running in NOARCHIVELOG mode, then you have to use the following command to recover database. Seriale spanjolle shqip.

SQL> recover database using backup controlfile until cancel;

If you restored an online backup on target system and put all the archive files created since online backup start time, use the following commands.

SQL> recover database using backup controlfile;

After execution of this command, Oracle will ask for archive files to be consistent. As archive files contains only database changes commands, you will use source system archive file on new systems database recovery. Copy all archive files created since online backup on source system to archive directory of target system. Archive file names are different from asked during recovery session. You can change archive file names for targetsystem manually.

But recovery session must be started with the following command and cancelled again to be able to start database.

Otherwise following error will arise during database opening.

SQL> alter database open resetlogs;

alter database open resetlogs * ORA-01113: file 1 needs media recovery ORA-01110: data file 1: ‘/oracle/QSG/sapdata1/system_1/system.data1’

To open database, use the following command:

System

SQL> alter database open resetlogs;

After opening database, LISTENER process must be started.

Before opening SAP perform the following activities:-

· Change dbs_ors_schema to SAPPSG both in CI and DI that is both in 10.99.32.45 and 10.99.32.46

Open, edit, copy, move, or delete files stored on Windows NTFS-formatted USB drives on your Mac. When you get a new Mac, it’s only able to read Windows NTFS-formatted USB drives. To add, save, or write files to your Mac, you need an add-on NTFS-driver. Microsoft NTFS for Mac by Tuxera is easy-to-use software that makes this possible. Tuxera NTFS for Mac 2015 and onward can be updated through System Preferences - Tuxera NTFS - Updates tab. The application will check if a newer version is available, and will install it with a single click. For older versions: Download the latest installer by visiting Microsoft NTFS for Mac by Tuxera. Tuxera ntfs 2015 download windows 7.

· Check the users and lock status by entering following command

Make sure all the users are in open state.

Sap Basis Classes

· Run oradbusr.sql as per the Note 50088 – Creating OPS$ users on Windows NT/Oracle to create ops$ users

SQL>@F:oradbusr.sql SAPTSID NT DOMAIN SID

If you still find any errors refer NOTE 400241 (https://websmp230.sap-ag.de/sap%28bD1lbiZjPTAwMQ%29/bc/bsp/spn/sapnotes/index2.htm?numm=400241)

What Is System Copy And System Refresh In Sap Basis

· Now change the password of SAPPSG by using brconnect so that it will get updated in SAPUSER table, enter the following command in cmd

brconnect -u system/basis$1234 -f chpass -o SAPPSG -p basis$1234

Note: – If you use below command in SQL for changing password the result will not be updated in the SAPUSER table, but if you change thru brconnect an encrypted password will be created, so please always use brconnect to change the password.

SQL> insert into “OPS$ CHESVLQSAP1 QSGADM”.sapuser values(‘SAPPSG’,’basis@1234′);

System Copy In Sap Basis

· So now when you parse the below commands and expect the same output, also check r3trans –d in command prompt and ensure return code is 0000

SQL>conn /@SID

SQL>connected .

· Now start the SAP services

Logon to the SAP R/3 System and go to TCODE SE06. Select “Database Copy or Migration” and execute “Post Installation Processing”.

Change all of the Source System Objects to Target System Objects as asked.

System Copy In Sap Basis Guru99

Delete old TMS configuration and make new configuration for TMS via STMS TCODE.

Now Login to 000 client with SAP*, as your Hardware Key is not changed, you don’t have to get additional License Key from SAPNET. You can use previous systems (on target system, if SID is not changed) License in new system created on target system.