A recurring requirement in the SAP IT business: homogeneous system copies. Mirroring a product system to test or release systems is very often required, but it also involves pitfalls and dangers. This blog is intended to provide an overview of what is involved.
Preparation: Tools and Documentation
Before you get down to work, you should have at least the following:
- basic knowledge of administration and SAP architecture
- at least 3 days time for this job (for the 12th run even 1 day is enough)
- root access to the target computers
- working backup or ora access to the source computers
The be-all and end-all for all activities in the SAP environment: please pay attention to the documentation (in the professional world kindly paraphrased with the euphonious acronym ‚RTFM‘).
SAP offers extensive sources of information, mainly consisting of the online SAP Help http://help.sap.com, the SAP Notes system http://service.sap.com/notes and the documentation on http://service.sap.com/instguides. For troubleshooting, sdn.sap.com is also incredibly helpful.
Starting with the official documentation, we find the appropriate documentation for our project (hom syscopy, abap only, unix/oracle) here: http://service.sap.com/instguides -> SAP Netweaver -> SAP Netweaver 7.0 (2004s) -> Installation -> „System Copy for SAP Systems Based on NW 7.0 SR2 ABAP“.
Note: To prevent too much inertia, SAP changes the documentation structure with good regularity, often due to rebuilds in the product portfolio. So don’t be discouraged if the way to the right documentation described here or in notes does not exist anymore, and in case of doubt always look for Netweaver as application platform first (e.g. 7.0 and 2004s in case of ERP6).
The guide itself also describes the corresponding notes. I strongly recommend to skim them and note the relevant passages separately, e.g.
970518 Hom./Het.System Copy SAP NetWeaver 7.0 (2004s) SR2
For system copies only rarely so crucial, it can happen e.g. with release changes or Support Package implementations that the notes are supplemented within short time by new critical information. In the worst case, such information can determine the success or failure of the entire project, and may cost you a complete reboot.
Parallel to reading the documentation and the hints, you can start downloading the required tools and installation DVDs. For our project these would be the following:
Tools (if not already available):
- putty
- a working X server
- WinSCP
SAP installation DVDs:
- Instmaster DVD
- Kernel DVD (suitable for your DB and OS version)
- JAVA Components
- Oracle RDBMS DVD
- Oracle RDBMS Patchset (+ SBP)
- Oracle RDBMS Client
- + latest kernel stack from http://service.sap.com/swdc -> Support Packages and Patches
The procedure in general
Backup source database
Of course the source system has to be backed up in one form or another. This can be done via backup solutions (e.g. Networker), or directly via filecopy from the source system.
Check target data and backup if necessary
If you want to save user masters, RFC destinations or similar from the target system for later use, you should include this in your activity plan.
Deposit CDs and prepare tools
Put the downloaded installation CDs on the target machine – maintenance activities with DVDs located elsewhere (NFS / SAMBA) are extra-pfui. Unpack them locally (very popular is sapdata with link from /instcd) and authorize them accordingly to allow the adm and the ora to access.
Start the SAPINST and prepare the installation.
Establish the X connection to an X server (keyword DISPLAY, xauth, etc.) and start SAPINST. A long litany of queries and entries follows, which you answer accordingly – the first time interesting is the so-called Solution Manager Key, which you receive after creating the target system in your SolMan SMSY.
Difficult to correct are especially the Unicode/Non-Unicode information (to find out in the kernel of the source system) and the schema name / code page of the source database (both to find in the environment of the source ora).
RDBMS and Restore
During the installation process, there is a prompt to install the RDBMS. After that is done and the patches are all implemented, SAPINST continues until the restore prompt.
Now you play with the means of your choice (brrestore, recover or scp) the data base files of the source computer on the target computer (here above all sapdata*, the control files and the DB profiles of the source data base, if necessary still the Redolog archives with on-line copies).
Since one could fill a separate blog with the Restore, only briefly the reference:
After the copy, the task is to reset the permissions / adjust the profile, and to start up the DB 1 time under the old name (with Recover with open resetlogs). Then shut down the DB again, create new controlfiles with the target name, and then start up under new name. Then check PSAPTEMP and correct the OPS$ entries, and you are ready to go. Of course, if the release was converted to 11g during the copy, more work is needed here.
Don’t worry, it sounds worse than it is.
Defuse the database
Attention : very important at this point! Schedule out all application jobs (TBTCO/TBTCS) and invalidate all RFC destinations (RFCDES) after consulting with the client. Production copies can otherwise cause nasty damage if they are booted as a second production system with active jobs or interfaces!!!
SAPINST starts the SAP system over time, so there is no time left after this step to catch up on these activities.
SAPINST continue
SAPINST actually expects to start up the DB itself. But this is a bit cumbersome with rename and recover, so we assume the DB is already online under a new name (as described in step 6). To give SAPINST something to do anyway we shutdown the DB and put a file named CONTROL.SQL with the content ’startup‘ into the log directory.
Note: this step 7. could be omitted in former times (R3Setup, SAPINST until about 2009), because the kernel was already installed and all necessary environment variables were set. In my experience, this is no longer the case. Today, SAPINST must have been completely terminated at least once if the target system is empty.
Otherwise you may be left with a restored database but no kernel / environment variables. The post-processing to get the system to fly then is somewhat involved, so please exit SAPINST and remove the sapinst-instdir only afterwards.
The postprocessing
The database is restored, the system is copied and online, SAPINST is finished. Now you can implement any necessary post-processing according to the documentation and instructions. Among others this can be the following (many of them only „if needed“):
- Disable DB logging
- Check and update SAP system profiles and DB profile (#1171650)
- Set up licenses
- Reschedule database jobs and SAP maintenance jobs
- Reset transport system
- Re-import user and RFC destinations, convert / reset RFC passwords
- SM21 Syslog / ST22 Dumps / SM28 Check SICK
- BDLS, SM54, SM55, RZ04, RZ12, SM63
- SLD connection RZ70
- SPAD preparation server
- SGEN
- Initial backup
- ..
This list is not exhaustive, but it does provide some orientation as to which topics are involved. Almost all companies also have standard lists of rework that contain industry-specific activities or take into account special features in the infrastructure. If your colleagues assure you that there is no such thing, you should think about a company cake…
In conclusion : as much „commodity“ as such a system copy may be, stay alert, and don’t stumble upon forgotten ‚obviousness‘. Do yourself and posterity a favor, document your work and store the documents centrally.
With this in mind, all the best with your new system (another one you get to look after from now on ;).
The obligatory
This documentation is a collection of empirical values, and has not been tested or released in any form by the product manufacturers (SAP, Oracle, ..). No liability can be assumed for damages resulting from (partial or complete) following of this documentation.
Of course I am happy about questions, comments or additions.
