SAP Database Referesh PDF

Database
Refresh
Procedure
info@keylabstraining.com
Document Information
Title Database Refresh Procedure
Author Ahmed Khan
Reviewed Balmukand Sharma
Operating System AIX 5.3
Database Oracle
www.keylabstraining.com
1. Introduction 4
2. Pre Copy steps
2.1 Verify the passwords in the source and target systems 5
2.2 Check Space in Target System 6
2.3 OpenSSH to OpenSSH trust (host based trust) 6
2.4 Verify Oracle control file directories on target server 8
2.5 Export Target SID/Client Users & retain user master records 8
2.6 Save data for RFC, ITS, SAPconnect, SSO, HTTP(S), SCOT
and Logical Printer Server tables 9
2.7 Preserve printers 12
2.8 Backup BugsEye & eMerge data(If Applicable) 13
2.9 Export J2EE Database Schema 14
2.10 Capture the standard SAP jobs released in SAP 14
2.11 Check & Preserve details of PSAPTEMP datafiles 14
2.12 Preserve BI Accelerator Indexes 15
2.13 Logon Group Names (SMLG and RZ12) 15
2.14 Op-mode Snapshot 16
2.15 Check and Save Logical System Definition 16
2.16 Preserve DB13 entries 16
2.17 SAP License Snapshot 17
2.18 Determine SAP version 17
2.19 Preserve TXCOM table entries 17
3 Restoring/Copying the database
3.1 Procedure to Refresh Database from the online/offline Backup 19
3.2 Procedure to Refresh DB from the other DB in the same server 27
4 Post-Copy Steps
4.1 Removing hostname entries 32
4.2 Fix GLOBAL_NAME parameter in Oracle 32
4.3 Reset Oracle SYS and SYSTEM password 33
4.4 Fix SAP License Key 33
4.5 Cleanup /sapmnt/SID/global 33
4.6 Start SAP for the first time 33
4.7 Manual run of backup log 34
4.8 Re-enable crontab for root on target server 34
4.9 Transport System Configuration 34
4.10 Delete all spool request 35
4.11 Delete Update Entries 35
4.12 Delete Lock Entries 36
4.13 Delete Source SID Profile Parameter Files 36
4.14 Delete Source SID Op Modes 36
4.15 Delete Server Specific Performance Data 36
4.16 Check System Logs 37
4.17 Fix Logon Group Names (SMLG and RZ12) 37
4.18 Re-initialize Import Jobs 37
4.19 Restore printers 38
4.20 Import User Master Records 38
4.21 Change Client Settings 39

4.22 Perform client import post processing 39
4.23 Change Client Settings 40
4.24 Restore data for RFC, ITS, SAPconnect, SSO, HTTP(S), SCOT
and Logical Printer Server tables 40
4.25 Run System Consistency Check 41
4.26 Fix DB13 jobs 42
4.27 Convert CCMS tables 42
4.28 Changing The Source Server To Target Server Name For
SAPCOMM 42
4.29 Restore TXCOM table entries 42
4.30 Remove System Messages (or adjust) 42
4.31 Re-cycle SAP 43
4.32 Start SAP on all application servers (if applicable) 43
4.33 Check background processing 43
4.34 Clear Background Objects 43
4.35 Import application server Profile Parameter Files 43
4.36 Add required application servers to the Op Modes 43
4.37 Reschedule Standard SAP Jobs 44
4.38 Fix workload storage parameters 44
4.39 Configuring J2EE 6.40/7.00 44
4.40 Re-import BugsEye & eMerge data (if applicable) 50
4.41 Run sapdba_role.sql to fix Oracle privileges for OPS$SIDADM 52
4.42 SAP INFOCUBE INDEXES REPAIR 52
4.43 Convert logical systems names 53
1 Introduction
A Database refresh/copy consists of three sections or units of work:
1. Pre Copy steps
2. Restoring/Copying the database files
3. Post Copy Steps.
Note : The method of copying the database files depends on if the target system has the
same number and size of file systems or greater to accommodate the source system.
Below are the steps to be followed during refresh, Commands shown in this document
are for AIX 5.3 platform.
2 Pre Copy steps

2.1 Verify the passwords in the source and target systems
Before you Proceed with the refresh you should have the login credentials in both Source
and Target system with Enough Authorisations ( Super user with sap_all and sap_new
profiles) (both OS and SAP level)
2.2 Check Space in Target System

Make sure that you have enough space in the Target System, equal to or more than in the
Source System. Check via command (on both Source and Target Systems):
As user root
df -k | grep sapdata | sort
Also make sure that the space in origlogA & B and mirrlogA & B is the same or more in the
Target system as compared to the source system. If they are not the same size, they must
be removed from the target and the file systems are enlarged to allow them to be built to
the Source sizes. Check via
As user root:
df -k | grep log| sort
Additional Checks for storage in APO – LCA system

 The size of /sapdb/<TARGET SID> should be greater than or equal to
/sapdb/<SOURCE SID> in the live cache host
Additional Checks for storage in APO – LCA system

 The size of /sapdb/<TARGET SID> should be greater than or equal to
/sapdb/<SOURCE SID> in the live cache host
Example: If source is SSID and target system is TSID (df –gt)

/dev/lvusp_ssid_002 58.88 0.97 57.90 2% /sapdb/SSID
/dev/lvusp_tsid_002 70.00 0.91 69.09 2% /sapdb/TSID
 In both systems go to T-code LC10 -> Live cache Monitoring ->

Administration -> Configuration -> Volumes
 Select Data area tab; size of the Data area in Target system should be greater
than that of the Data area in Source system, irrespective of the number of data
volumes present
Source system(Source SID(SSID))
Target System(Target
SID(TSID)
If the size of data area is less than the source system then add data volumes
2.3 OpenSSH to OpenSSH trust (host based trust)

Server which will be trusted for root login (referred to as ‗trusted server‘):
Open the connection between Source system and Target system, Just in case you want to
transfer any file during refresh. You can do so by directly using Secure copy command
In Target System
# cd /etc/ssh
# cat ssh_host_dsa_key.pub
(Example shown below)
ssh-dss
AAAAB3NzaC1kc3MAAACBAPyNO8hfzk9+WBS5nOSAhmu/eVE9+4t6Wd5sGRwWNAdyDtFF9u
x/CKcgeK8o2OPFSeCcuNiw8d3NOHLCLHNjB6lH8V3L9R8+7b8hDpfpZ4fxcYKlP6W/EXHyWuv8
DrEyCdyaFbYNzul7JaJx1j5lOEUa6TFJDbouqRsp/Mw0jsbBAAAAFQD4kBx7i/53NeFZ7C2GXIED
L+mAuwAAAIBzbYbmh8xDG0DQzMt6Ury0aqyDoawbnEq9uAlulvcheivO2VnZfqO9HEFd18JPIX
TLWTCjtriE/6zpsgUR9oR2PCMbNW9S+PtIZ5HZ4NbTlCvF7gNxlibZ4sAB5e6zbb3Xso59K9H6m
0lFNZFKrg/P0vWumYtGEw/n16tUr9LxRwAAAIEAjf+4Eis9/ippFAeNIVfKL28KlYrqlcdBHIhE/wy6
/HEvAoNZ3fdxMjzvgn8gtEpzsy1+gql3o00uSJiNJKcMDzREfPqqxtu7lttOT9VYFM9mGFaLW+eB
Wh+6I+9HHdewS4A1/F7zwxQ5QLyB5puKNs05qofObC4vpfC3R/kOFMQ=
(NOTE : The hostkey above is a single line—NOT multiple lines and must be copied over as a
single line)
On Server allowing the root trust (referred to as the ‗trusting server‘):(Source system)
# cd /etc/ssh
# vi ssh_known_hosts
(go to the last line of the file, using Shift-G in vi, and open a line at the bottom using the ‗o‘
vi command)
(using existing lines as a reference, enter the name of the trusted server, along with the fully
qualified DNS name, followed by the hostkey found in the previous step. Below is an
example of what the key would look like)
<trusted server>,<trusted server>.<domain name> ssh-dss

AAAAB3NzaC1kc3MAAACBAPyNO8hfzk9+WBS5nOSAhmu/eVE9+4t6Wd5sGRwWNAdyDtFF9u
x/CKcgeK8o2OPFSeCcuNiw8d3NOHLCLHNjB6lH8V3L9R8+7b8hDpfpZ4fxcYKlP6W/EXHyWuv8
DrEyCdyaFbYNzul7JaJx1j5lOEUa6TFJDbouqRsp/Mw0jsbBAAAAFQD4kBx7i/53NeFZ7C2GXIED
L+mAuwAAAIBzbYbmh8xDG0DQzMt6Ury0aqyDoawbnEq9uAlulvcheivO2VnZfqO9HEFd18JPIX
TLWTCjtriE/6zpsgUR9oR2PCMbNW9S+PtIZ5HZ4NbTlCvF7gNxlibZ4sAB5e6zbb3Xso59K9H6m
0lFNZFKrg/P0vWumYtGEw/n16tUr9LxRwAAAIEAjf+4Eis9/ippFAeNIVfKL28KlYrqlcdBHIhE/wy6
/HEvAoNZ3fdxMjzvgn8gtEpzsy1+gql3o00uSJiNJKcMDzREfPqqxtu7lttOT9VYFM9mGFaLW+eB
Wh+6I+9HHdewS4A1/F7zwxQ5QLyB5puKNs05qofObC4vpfC3R/kOFMQ=
NOTE : The hostkey above is a single line—NOT multiple lines, so the generic format is as
follows : <trusted server>,<trusted server>.<domain name> ssh-dss <hostkey from
trusted server>
Concatenate all the lines in the file - instead of 9 lines, it should be a single long line
On the trusting server, update the /.shosts file to allow root access
# vi /.shosts
(include a line of the format :
<trusted server>.<domain name> root
By doing so now your Source server has become the Trusting server and Target system has
become the trusted server.
2.4 Verify Oracle control file directories on target server

Logon to the target system
 as ora<target_sid>
 cd dbs
The following command will display three directories where the controlfiles will be
written
grep dbf init<TSID>.ora
According to the standards they should be in /oracle/<SID>/cntrl,

/oracle/<SID>/sapdata1/cntrl and /oracle/<SID>/sapdata2/cntrl
 ls –l /oracle/<TSID>/cntrl
 ls –l /oracle/<TSID>/sapdata1/cntrl
 ls –l /oracle/<TSID>/sapdata2/cntrl
If not ensure that these directories are created and a copy of Control file is moved to them.
2.5 Export Target SID/Client Users & retain user master records
This step only applies to those projects where the user master records are to be retained in
the target system.
Log on to the SAP target system clients that need to have users preserved.
Execute transaction SCC8

 Select profile: SAP_USER
 Target system: use ―DUM‖. YOU MUST FILL THIS VALUE IN OR IT WILL NOT
WORK
 Click execute button, click continue button and STOP AT INFO CLIENT EXPORT
SCREEN!
Perform the following before proceeding with SAP screen.

 On the Info Client Export screen, STOP! and document the transport number
displayed with the format: <sid>KTnnnnnnn
This step will fail if files exist in the transport directories with the same number.You
must delete all cofiles, data files, and log files with the same number before starting the
new export. Here‘s an example taken to find everything related to transport su –
<sid>adm
 cd /usr/sap/trans
 find ./data ./cofiles –name ‗*00017.SID‘ –exec ls –lastr {} \;
If any files are found, verify they are the correct files and can be removed, then remove
them (consult if you aren‘t sure) else rename them with extension .old:
 find ./data ./cofiles ./log –name ‗*00017.<SID>‘ –exec rm {} \;
Verify that the files were successfully removed:
 find ./data ./cofiles ./log –name ‗*00017.<SID>‘ –exec ls –lastr {} \;
 Now, return to SAP screen and click the green check mark to start the export.
Remarks:
 If DUMMY system is not there, select any SID except the SID name you are
exporting from. YOU MUST FILL A SID IN OR IT WILL NOT WORK.
Note:
1) Monitor the job using SCC3 logs. At first the log may indicate an error in the processing.
Just wait about 3-5 minutes and check again. Always look to the date/time field to verify the
correct logfile. Also, after SCC3 indicates it‘s successful you must check that the transport is
completely exported using SE03. MAKE SURE IT COMPLETES WITH RETURN CODE < 8.
2) Sometimes user master export shows COMPLETED status at SAP level but runs for a
few minutes in the operating system. Therefore always check the file size until it reaches
the saturation at operating system level.
Login as sidadm user at os level
cd /usr/sap/trans/
find ./data ./cofiles -name ‗*00017.<SID>‘ -exec ls -lastr {} \;
the file size should become constant if you again trigger the command.
2.6 Save data for RFC, ITS, SAPconnect, SSO, HTTP(S), SCOT and Logical Printer
Server tables
Here we Export the tables relevant to RFC, ITS, SAPconnect, SSO, HTTP(S), SCOT and
Logical Printers.
For Eg
Secure store tables are also exported.

These tables contain the RFC passwords. In earlier versions this was included in table
RFCDES.
The contents of the Secure store can be viewed by using tx SECSTORE or SE38
RSECADMIN.
Create a transport with the following object list:
Program Object Object Name Table Description/Purpose

ID Key
R3TR TABU RSECTAB * Secure store table client-specific
R3TR TABU RSECACTB * Secure store table cross-client
R3TR TABU RFCATTRIB * Administration table for RFC
destinations
R3TR TABU RFCDES * Destination table for Remote Function
Call
R3TR TABU RFCDESSECU * SNC extensions for RFC destinations
R3TR TABU RFCDOC * Description of Possible RFC
Connections (->RFCDES)
R3TR TABU RFCTRUST * List of existing trusting systems
R3TR TABU RFCSYSACL * List of permitted trusted systems for
the current system
R3TR TABU IACORDES * RFC Destinations for IACOR / ITS
R3TR TABU TSPSV * Spool: Server table
R3TR TABU TSPSI * Spool: Server Information (Updated
by Spool Work Processes)
R3TR TABU TSP03 * Spool: Printer declaration
R3TR TABU TSP03A * Spool: Device description (new
format)
R3TR TABU TSP03C * Spool: Device Description Extension
R3TR TABU TSP03D * Spool: Device Description (New
Format)
R3TR TABU TSP03L * Spool: Long device names
R3TR TABU TSP03T * Paper format in the device paper tray
R3TR TABU TBD11 ZKOST Transaction BD95 Configuration
R3TR TABU TWPURLSVR * Logical Web Servers for Logical
Systems / I
R3TR TABU ROIDOCPRMS * Control parameters for data transfer
from the source system
R3TR VDAT V_TBDLS * Logical System Names / IHUB
R3TR TABU SXNODES * SAPconnect: Communication nodes
R3TR TABU SXROUTE * SAPconnect: Routing table
R3TR TABU SXSERV * SAPconnect: Node capabilities
R3TR TABU SXADMINTAB * SAPconnect and SAPphone:
Administration
R3TR TABU SXDOMAINS * SAPconnect: Management of Internet
Mail Addresses Domains
R3TR TABU SOPR * SAPoffice: System-wide profile
(default domain)
R3TR TABU SXADDRTYPE * SAPconnect: Address types
R3TR TABU SXCONVERT * SAPconnect: Conversion functions
R3TR TABU SXCONVERT2 * SAPconnect: Conversion Functions for
Forma
R3TR TABU SXCOS * SAPconnect: Send attribute classes
R3TR TABU SXCOS_T * SAPconnect: Text table for send
classes
R3TR TABU SXDEVTYPE * SAPconnect: Device Types for Format
Conver
R3TR TABU SXFORMATG * SAPconnect: Format groups
R3TR TABU SXJOBS * SAPconnect: Send Jobs
R3TR TABU SXRETRY * SAPconnect: Disruptions in RFC
connections
R3TR TABU SXRFC * SAPconnect: Assignment of RFC
address to n
R3TR TABU SXTELMOIN * SAPconnect: Telephone number
modification
R3TR TABU SXTELMOOUT * SAPconnect: Telephone number
modification
R3TR TABU T160PR * Profile for External Purchasing
System
R3TR TABU TWPSSO2ACL * Workplace Single Sign-On 2 Access
Control List
R3TR TABU SSF_PSE_H * SSF: Personel Security Environment
R3TR TABU SSF_PSE_D * SSF: Storage for Personal Security
Environment Data
R3TR TABU SSFARGS * Application-Dependent Parameters
for SSF Functions (SSFG)
R3TR TABU SXMSCONFVL * XMS: Integration Engine
Configuration Parameters
R3TR TABU CREP_HTTP * KPRO CMS: Content Repositories

(HTTP)
R3TR TABU HTTPURLLOC * HTTP URL Location Exception Table
R3TR TABU RSADMINA * Control Parameters for BI
(Accelerator)
R3TR TABU RSDDTREXADMIN * Additional Settings for Indexing of an
HPA Index
R3TR TABL RSPOR_T_PORTAL * Maintaining Settings for Integration
into SAP Enterprise Portal
1. For Target system logon in SAP client, where you have enough authorizations
2. Goto SE01
3. Create button
a. Check Request type: Transport of copies
b. Uncheck any other request type
4. Enter Short description
a. Enter target (DUM) or enter a SID other than the target SID
b. Save
5. Write down the transport number
6. Click on transport request
a. Press ―Display object list‖ button
7. Press ―Display > Change‖ do be in change mode
8. Click on New entries.
9. Enter entries as listed in above table, one per line
10. After you have entered all objects, double click on each object to drill down to the
key
11. Correction : Click on <Edit>, then click on <Insert Line>‘
12. Enter '*' in each of the key field lines and save.
13. Repeat step 9-12 for all the objects.
14. Save and go back
15. Select the transport request and
16. Click on ―Release directly‖.
17. Check the transport log.
When ―application‖ or ―temporary tables‖ which you want to export giving errors then
you have to export them via Oracle :
 su – ora<sid>
{sapsid = SCHEMA (table owner) of sap tables}
 exp <sapsid>/<password> FILE=/oracle/<SID>/sapreorg/expdat.dmp
tables=<tablename>, <tablename> buffer=1024000 grants=N indexes=N
consistent=Y compress=N
2.7 Preserve printers
There are two options to preserve the printers :

 Transport
 Local file
Transport :
1. Log on to one of the SAP target system client 002 (or proper one for BW) with
personal id.
2. SPAD
3. Click on Change Icon
4. Click Output Devices
5. In menu, go to Edit Transport > Transport All
6. Press enter at screen prompt
7. A prompt for a transport number create a new one and press enter.
8. Enter a short description.
9. Press enter
10. In the message window, ―Entry is made in transport request‖ means successful
creation.
11. Execute transaction SE01, select workbench request, and click on display.
12. Click on the transport number. Select Request – Request header, enter a valid
target = DUM
13. Click SAVE and ignore any errors.
14. Click on the Development/correction task number. Press Release.
15. Press the save button in the popup menu, followed by the back button.
16. The task should now be displayed in a darker color.
17. Click on the transport number. Press Release.
18. Press the save button in the popup menu, followed by the back button.
19. Now the transport has been released.
Local file :
personal id.
2. SPAD
5. Click on the line of one of the printers
6. In menu, go to Edit --> Transfer --> Export
7. Export/Import file name : Fillin the destination of your C -drive where you can store
the file for the printers.
Example : c:/apps/reserveprintersSID.txt
8. Select Frontend computer
9. Select Export
10. Select Execute export and Generate log
11. For Output device : Fillin * (Please don't forget this otherwise it will only export
1 printer)
12. Click on execute
Please check in your txt file : c:/apps/reserveprintersSID.txt if the printers are there.
2.8 Backup BugsEye & eMerge data
if the BugsEye data & eMerge data needs to be saved.
If the customer agrees to save the data do the following:
For BugsEye:
- Export all data info from BugsEye instance

su – ora<sid>
exp bugreq/<Password for bugreq user> file=/oracle/<SID>/sapreorg/exportbug.dmp
full=y indexes=y grants=y log=/tmp/exportbug.log
Note: wait for the prompt and enter the below values.
. mode (2) U(sers)
. export grants yes
. export table data yes
. compress extents yes
For eMerge (for GSAP)

- Export all data info from eMerge instance
su – ora<sid>
exp emereq/<See WARP> file=/oracle/<SID>/sapreorg/exporteme.dmp full=y
indexes=y grants=y log=/tmp/exporteme.log
. mode (2) U(sers)
. export grants yes
2.9 Export J2EE Database Schema

The schema of the J2EE 6.40/7.00 must be saved to restart the engine after the system has
been refreshed.
Export the SAP<SID>DB or SAPMIWDB schema using schema password
su - ora<sid>
cd /oracle/<SID>/sapreorg (need at least 2GB free for SAPMIWDB)
exp sap<sid>db/<Password> file=/oracle/<SID>/sapreorg/exportj2ee.dmp full=y

indexes=y grants=y log=/tmp/exportj2ee.log
. mode (2) U(sers)
. export grants yes
In case none of the passwords work change the schema password as follows:
sqlplus ‗/ as sysdba‘
alter user sapmiwdb identified by <Password>;
2.10 Capture the standard SAP jobs released in SAP

Login to Target system
Go to SM37
Query for all the released jobs in the system and take a screen shot, we shall be Scheduling
it later.
2.11 Check & Preserve details of PSAPTEMP datafiles
Execute the following command at Oracle level for details of tempfiles, path & size of the
temp files for the existing system and preserve the details for comparison after refresh:
su - ora<SID>
sqlpls ‗/ as sysdba ‗
file_name,(bytes/1024/1024/1024) from dba_temp_files where tablespace_name
='PSAPTEMP';
2.12 Preserve BI Accelerator Indexes

If the BI system is connected to BIA the BIA indexes need to be saved so these indexes can
be rebuild later.
Start transaction /nRSDDV in the BI instance.
Select the Display All BIA Indexes button or select (F6)
Take a screen shot of these indexes and copy into a word document and save the document.
Screenshot:
2.13 Logon Group Names (SMLG and RZ12)

Logon group names are used in projects to accomplish logon load balancing. These logon
groups are used in the SAP logon pad to automatically assign users to application servers
based on currently application server usage. The spelling of the logon groups are important
because the names in the logon pad must match exactly with what is configured in the
system. Therefore, it is important to note the SAP logon group names in the target system
prior to performing the database copy, because after the copy, the logon group definitions
will reflect those of the source system. To retrieve the logon group name(s):
 For Target system logon in SAP client, where you have enough authorizations
 Execute transaction SMLG
 The logon group name(s) will be displayed on the screen. Save a copy of the
screen or write down the logon groups. Logon group names are also case-
sensitive.
RFC server groups are, amongst other things, used for parallel client copies. These RFC
server groups must be restored to their current configuration after the refresh.
 Execute transaction RZ12
 The RFC server group name(s) will be displayed on the screen. Save a copy of
the screen or write down the logon groups. RFC server group names are also
case-sensitive.
2.14 Op-mode Snapshot

Again depending on the requestor: normally the same op-mode would be maintained.
The Source <SID> and Target <SID> may have different definitions of Op-modes. After a
successful database copy the Op-modes in the Target <SID> will be replaced with the Op-
modes in the Source <SID>. Therefore, it is important to take a snapshot of the Op-modes
in the Target <SID>. Proceed as follows:
 Execute transaction RZ04
 Double-click on one of the Op-modes or click instance/op-mode in menu bar
 Execute menu items System => List => Save => Local file => unconverted.
 This will ask for a directory/filename on the local PC to store the information.
Make note of the directory/filename for use in the post-processing steps
2.15 Check and Save Logical System Definition

 Execute SCC4, and double click on all clients.
If the field Logical System is not blank, document the name with each client.
2.16 Preserve DB13 entries
As the DB13 tables will be cleared due to the refresh, the entries of the DBA Planning
Calendar must be saved.
Proceed as follows:
 Goto DB13 on the target system.

 Make a hardcopy of the screen and/or save it in notepad.
2.17 SAP License Snapshot

The Source <SID> and Target <SID> may have different list of SAP Licenses loaded in the
system. After a successful database copy the SAP Licenses in the Target <SID> will be
replaced with those in the Source <SID>. Therefore, it is important to take a snapshot of
the SAP Licenses in the Target <SID>. Proceed as follows:
 Log on to the target system at UNIX as <sid>adm

 saplicense –show > saplicense_<Target_SID>.save
 Make note of the absolute_path/filename (saplicense.save) for use in the Post
Copy Steps, should be in /local/users/<sid>adm
2.18 Determine SAP version

This step is important in order to follow these instructions as they are version dependent.
1. Log on to SAP with your personal id

2. Enter ?STAT in the transaction field at the top left corner of the screen and press
enter.
3. A pop-up screen appears, the version of SAP is listed in the field named SAP Release
(or BasisRelease).
4. Click red X to exit pop-up.x
5. SAP RELEASE: ____________________
2.19 Preserve TXCOM table entries

 Log on to SAP with your personal id in client 002
 SM54
 Double click on the entry
 Take a screen shot of the entry and copy into a word document and save the
document.
This is for saving CPIC destinations for SNC protection
Note: Apart from the steps above we should take care to see that customer specific
data is preserved as requested or applicable .
And also note that if source system is at lower level in terms support packages, addons
and other applications we might have to upgrade the target system accordingly after
refresh if required.
3 Restoring/Copying the database
3.1 Procedure to Refresh Database from the online/offline Backup
Disable crontab for root on target system

Disable root‘s cron to make sure that nothing runs that might have an impact on the refresh
<upgrade_server> # crontab -l > /local/etc/sapadm/root.crontab.`date

+‖YYYYMMMDD‖`(like root.crontab.2005JAN01)
<upgrade_server> # crontab –r
Actions on Target System

Bring down all the applications of SAP( for ex:: Patrol, ControlM agent, CCMSR etc)
Bring down the J2ee Engine

Access transaction SMICM
Perform the following path:
Administration > J2EE Server > Send Hard Shutdown > Without Restart
Bring down SAP and clean up the system
 su - <sid>adm
 stopsap
 saposcol –k
 su – ora<sid>
 lsnrctl stop
 cd /oracle/<SID>
 rm –r sapdata*
 cd /oracle/<SID>/saparch
 rm *
If this isn‘t working then use :
Check :
find /oracle/SID/saparch -name "*" -exec ls {} \;
If it can find the files then use this :

find /oracle/SID/saparch -name "*" -exec rm {} \;
 cd /oracle/<SID>/cntrl
 rm *.dbf
Copy needed files from source system to target system
On Source/Standby system- To make sure that the backup by

root>cd /oracle/<SID>/sapbackup which you need to restore is
root>more <*.anf> or more <*.aff> for standby (if successful.
applicable)
1. On Source/Standby system : 1. SCP the backup file needed from
root> cd /oracle/<SID>/sapbackup source system to target System.
root> scp xxx.anf <target
system>:/oracle/<target SID>/sapbackup/
or scp xxx.anf <target system>:/oracle/<target
SID>/sapbackup/ for standby (if applicable) 2. Change the permissions and
2. On Target system : ownership of
root> chmod g+r *.anf (or .aff file for standby (if Backup file.
applicable))
root> chown ora<target sid>:dba *.anf (or .aff
file for standby (if applicable))
1. On Source system: 1. SCP init<sid>.utl file from source
root> scp init<sid>.utl <target to target.
system>:/oracle/<sid>/dbs/ 2. Change the permissions and
2. On Target system ownership of init<source sid>.utl
root> chmod g+r init<source sid>.utl 3. Edit init<source sid>.utl . We
root> chown ora<target sid>:dba init<source need to
sid>.utl change Config_file parameter.
3. root > vi init<source sid>.utl This is
Change CONFIG_FILE parameter as :- needed to start the restore.
CONFIG_FILE /oracle/<target
sid>/dbs/init<source sid>.bki
1. On Source system ; 1. SCP init<source sid>.bki from

root> cd /oracle/<sid>/dbs source to target
root> scp init<source sid>.bki <target 2. Change permissions & ownership
system>:/oracle/<target sid>/ of init<source sid>.bki
dbs/
2. On Target system :
root> cd /oracle/<sid>/dbs
root> chmod g+r init<source sid>.bki
root> chown ora<target sid>:dba init<source
sid>.bki
On source system 1. To create the trace file.
1. ora<sid> sqlplus ‗/ as sysdba‘ 2. Scp the trace file to the target
sqlplus > alter database backup controlfile to system.
trace; 3. Change the
sqlplus > exit permission/ownership of trace
3. scp this file created in file.
/oracle/<SID>/saptrace/usertrace to the target
system /oracle /<SID>
4. scp <trace file> target system: /oracle
/<SID>/createcontrol.sql
5. On Target system
root>cd /oracle /<SID>
root> chmod g+r createcontrol.sql
root> chown ora<target sid>:dba
createcontrol.sql
Editing the tracefile on target system 1. To go into vi mode
1. root> vi <trace file> 2. To remove all the unwanted
2. The file has been created double, remove the lines. All the lines are to be
first file removed until STARTUP
3. Remove all the starting lines of tracefile until NOMOUNT, beginning from first
STARTUP NOMOUNT line.
3. Edit the 2nd line – 3. Edit the 2nd line as said.

CREATE CONTROLFILE REUSE DATABASE "SOURCE 4. Comment the 3 lines, which is
SID" NORESETLOGS ARCHIVELOG present at the bottom of the
to tracefile. We do this manually
CREATE CONTROLFILE SET DATABASE ―TARGET later.
SID‖ RESETLOGS NOARCHIVELOG 5. This is an easy command to
4. Remove also all the 2 lines, at the bottom of the change all the sid of source
tracefile – system to the sid of target
#RECOVER DATABASE system.
#ALTER DATABASE OPEN RESETLOGS;

5. Change all source sid to target sid. This can be Note :-
done by using vi command – Make sure no new datafile has being
:1,$s/<source sid>/<target sid>/g added after the backup that is being
used. Check by table V$datafile. If
yes, edit the trace file(remove the
datafile entry that are entered after
the backup that if used)
At the end of the tracefile on the BW system you

will also find some comments about the TEMP files.
For now you need to delete these entries but save
them somewhere else, because later you will need
them again. Example:
ALTER TABLESPACE PSAPTEMP ADD TEMPFILE
'/oracle/PC6/sapdata6/temp_4/temp.data4'
SIZE 1999M REUSE AUTOEXTEND OFF;
Restore database from Storage

Start restore on targetsystem in the foreground with:
 su – ora<sid>
 for normal restore: brrestore -r init<source sid>.utl -b <backupfile> -m full –c
 for standby restore: brrestore -r init<source sid>.utl -b <backupfile> -m all –c
or Start restore in the background with:

 as root
 at now
su – ora<sid> -c ―brrestore -r init<source sid>.utl -b <backupfile>-m full –c
force‖
^D
for standby: su – ora<sid> -c ―brrestore -r init<source sid>.utl -b <backupfile>-
m all –c force‖
^D
After the restore is finished (on target system):
 as root
 cd /oracle/<SID>
 chown –R ora<sid>:dba sapdata*
Rename the database

On Target System:
 su – ora<sid>
 sqlplus ―/ as sysdba‖
 @createcontrol.sql
Check in the /oracle/<SID>/saptrace/background/alert_<SID>.log for any errors.
Restoring offline redologs

In case a recovery of the database is needed (e.g. after the restore of an online backup, or a
point-in-time recovery is needed), offline redologs files needs to be restored from Storage.
To know what files you will need you can look in the sourcesystem‘s saparch directory. Look
for the file arch<SID>.log and decide which files you will need by timestamp. You can also
look in SAP (source system) with transaction DB12.
To restore redologs you will need to copy the arch<sourcesid>.log to the targetsystems
saparch directory
 scp /oracle/<sourceSID>/saparch/arch<sourceSID>.log <targetsystem>:
/oracle /<targetSID>/saparch
On target system:
 mv arch<sourceSID>.log arch<targetSID>.log
 chown ora<sid>.dba arch<targetSID>.log
chmod 660 arch<targetSID>.log
Recovering the database

There are two ways of recovering the database by CANCEL (you decide how many logfiles
you want to apply) or by TIMESTAMP.
sqlplus> recover database using backup controlfile until cancel;
or
sqlplus> recover database until time '2004-05-21:10:00:00' using backup controlfile;
to apply all required redologs automatically type AUTO
after completion we can now open the database by:
sqlplus> alter database open resetlogs;
Checking the database

First check if we can stop and start the system without problems.
Sqlplus> shutdown immediate
Sqlplus> startup
Also check the alert_SID.log for any errors.
Recreation of the tempfiles

We need some additional action for BW. Recreation of the tempfiles which you saved at
step Error! Reference source not found.
Example for 4 data files in sapdata6:

'/oracle/SSID/sapdata6/temp_4/temp.data4'
 Change sourceSID to targetSID

 Create the needed subdorectories in the sapdata filesystem(s)
cd /oracle/<targetSID>/sapdata6
mkdir temp_1
mkdir temp_2
mkdir temp_3
mkdir temp_4
Create the tempfiles:
 su – ora<sid>
 ALTER TABLESPACE PSAPTEMP ADD TEMPFILE
'/oracle/TSID/sapdata6/temp_1/temp.data1'
 Sqlplus> ALTER TABLESPACE PSAPTEMP ADD TEMPFILE
Making locally managed temporary datafiles non-sparse

The added datafiles in the previous step are locally managed temporary datafiles. These
kinds of datafiles are created as sparse files (they can grow to the configured size, but
initially this amount of space is not yet claimed on the OS level.) This can lead to issues,
when the reserved space is claimed by newly added ―normal‖ datafiles. Therefore, these files
need to be change to non-sparse files.
 su – ora<sid>
 shutdown immediate;
 exit;
Find enough space (usually 2 Gb is enough) in another filesystem than where the datafile is
currently located. The datafile needs to be moved to this other filesystem and back again.
This will make the datafile non-sparse.
Here is an example to move the files.
cd /oracle/SID/sapdata3
ora<sid> 40> mv temp2_1/temp2.data1 /oracle/SID/sapdata5/temp2.data1

ora<sid> 41> mv /oracle/SID/sapdata5/temp2.data1 temp2_1/temp2.data1
ora<sid> 40> mv temp2_2/temp2.data2 /oracle/SID/sapdata5/temp2.data2
ora<sid> 41> mv /oracle/SID/sapdata5/temp2.data2 temp2_2/temp2.data2
You can now see that the files are non-sparse and use the entire space in the filesystem.
Restart the database.
Create new OPS$ user & drop old OPS$ user

We need to generate a new OPS$ user;
 su – ora<sid>
 cd /sapmnt/<SID>/exe
 ./CHDBPASS.817
 select option a,c and d .
vi CHDBPASS.102 ; Change tablespace PSAPUSER1D into PSAPMIWUSR
; Change SAPR3 into SAPMIW
./CHDBPASS.102 ; option a c d. Set Password as relevant
; for a use schema password. For c d use system password
Later in the post step you can proceed to grant permissions to the user created
Check Archive Log Mode

Check if the database log mode is set on archive mode with sapdba. If not, toggle database
log mode.
Start Oracle Listener

The Oracle Listener should also be started
Orasid> lsnrctl start
3.2 Procedure to Refresh Database from the database residing in the same
server
(Relevant only if your standby server resides in the same system of the landscape)
For eg: if standby Server of production resides in Acceptance system you can refresh the
Acceptance system from the Hotstandy of Production(this is common practice for major
clients).
If the above condition persist you can proceed with steps specified below
Backup Source controlfile to trace

 Log on to the source (or standby database) system‘s as ora<sid>
 sqlplus ‗/ as sysdba‘
 alter database backup controlfile to trace;
 quit.
 cd /oracle/<sourceSID>/saptrace/usertrace
 ls –altr
 Write down the name of the trace file created (we will refer to it as <tracefile>)
Stop Target SAP and Oracle

Note: Downtime starts here
If the target SAP Instance has any application severs, they must be stopped first: Log
on to the application servers of the target instance as <sid>adm.
Stopsap
Logon to the target database server as <sid>adm
Stopsap
Remove the database existing on the Target System

Caution: Be careful with following commands! Look twice before pressing enter. You don‘t
want to remove datafiles belonging to another SID (like the standby database…)
 Logon to the target system as root

 cd /oracle/<targetSID>
 rm –r sapdata*/*
 cd /oracle/<targetSID>/cntrl
 rm *.dbf
 cd /oracle/<targetSID>/saparch
 rm *.dbf
Stop the hotstandby database

 Logon to the hotstandby system as ora<hotstandbysid>
 shutdown immediate;
Copy the database from hotstandby

Note: If the target system is not on the same server as the hotstandby, make sure that
/.rhosts file in the target system contains a row like:
<hotstandby system> root
If not, please add this line and don‘t forget to remove it when the procedure is completed.
Please ensure that the number of sapdata* filesystems for the target SID matches the
number of sapdata filesystems for the hotstandby SID—both in number and in size to ensure
there is sufficient capacity for the copy process. When performing the steps below, it may be
wise to copy and paste, line for line, from the document into the UNIX terminal window
because it may be difficult to identify whether you are using the proper character , number,
or letter in some cases.
On MC-II systems, the conccurent io (cio) option is turned on on the sapdata and
origlog/mirrlog filessytems. As such, to prevent a very slow refresh from the hot-standby
system, the cio option needs to be switched off because otherwise the "cp" command will be
extremely slow.
Therefore, if the hotstandby system is on MC-II platform, stop the SAP instances running on
the hotstandby and target systems if this is not done yet in the previous steps and run the
following commands as root to disable the cio option. Not that if both the hotstandby and
target systems are on MC-1 platforms, please skip this step and proceed with the next step.
lsfs | grep sapdata | while read lv a fs rest

do
chfs -a options=rw,nodev,nosuid $fs
umount $fs
mount $fs
done
If the target system is not on the same server as the hotstandby
Logon to the hotstandby system as root and run the following command:-
at now
for i in `df -Ik |grep sapdata |grep <hotstandbySID> | sed 's/^.*sapdata$[0-
9]*$$/\1/' `
do
echo $(date): ―Copying /oracle/<hotstandbySID>/sapdata${i} filesystem…‖
scp –p –r /oracle/<hotstandbySID>/sapdata${i}/*
<target_server>:/oracle/<targetSID>/sapdata${i} &
done | tee -a /tmp/hotstandby_copy.$(date +%Y%m%d%H%M%S).log
^D
If the target system is on the same server as the hotstandby
Logon to the hotstandby system as root
at now
for i in `df -Ik |grep sapdata |grep <hotstandbySID> | sed 's/^.*sapdata$[0-
9]*$$/\1/' `
do
echo $(date): ―Copying /oracle/<hotstandbySID>/sapdata${i} filesystem…‖
cp -p -r /oracle/<hotstandbySID>/sapdata${i}/*
/oracle/<targetSID>/sapdata${i} &
done | tee -a /tmp/hotstandby_copy.$(date +%Y%m%d%H%M%S).log
^D
Check if all files are copied successfully (this should be the case if there is enough space in
sapdata filesystems). It makes sense to check for file sizes and compare with the source
files.
Now, if the cio option is switched off in one of the above steps, it must be turned on again.
To do that, run the following commands on both the hotstandby and target systems:-
lsfs | grep sapdata | while read lv a fs rest
do
chfs -a options=rw,nodev,nosuid,cio $fs
umount $fs
mount $fs
done
Change ownership on restored files

 Logon to the target system as root
 cd /oracle/<targetSID>
 chown –R ora<targetsid>:dba sapdata*
Edit the trace file on target system

Use an editor (like vi) to change /tmp/<tracefile>.
Perform the following changes:
Remove all the starting lines of tracefile until the STARTUP NOMOUNT that precedes the
command: CREATE CONTROLFILE REUSE DATABASE <SID> RESETLOGS.
Note: With ORACLE 9 the trace file will appear to have duplicate data. The only difference
is that it has two stanzas, one with NORESETLOGS and one with RESETLOGS. You want
the last one.
Change all source sid to target sid. This can be done by using vi command
:1,$s/<sourse sid>/<target sid>/g
Change the 2nd line from
CREATE CONTROLFILE REUSE DATABASE <SID> RESETLOGS NOARCHIVELOG
to
CREATE CONTROLFILE SET DATABASE <SID> RESETLOGS NOARCHIVELOG

Comment all lines below and including the following 3 lines, at the bottom of the
tracefile.
#RECOVER DATABASE
#ALTER SYSTEM ARCHIVE LOG ALL;
#ALTER DATABASE OPEN;
Make sure to comment and make note of any statements at the bottom that have the
key word TEMPFILE like the following. You will need to manually execute these
statements later.
#ALTER TABLESPACE PSAPPAT1I ADD TEMPFILE
'/oracle/SID/sapdata4/pat1i_1/pat1i.data1' SIZE 52420608 REUSE
AUTOEXTEND OFF;
Save the file and exit vi.
Create controlfile and open the database
Open another session and tail the alert log:

 Logon to the target system as ora<sid>
 tail –f /oracle/<targetSID>/saptrace/background/alert_<targetSID>.log
 In your initial session:
 @/tmp/<tracefile>
 recover database using backup controlfile until cancel;
 Cancel this immediately. You don‘t really have to apply logs. (NOTE: If an on-
line backup was used, the required redo logs must be applied to the
database).
 alter database open resetlogs;
 Execute all the ―ALTER Tablespace <xxxx> ADD TEMPFILE …..‖ statements
from step 0. You can open another window and cut-paste the statements into the
sqlplus program. Make sure they execute successfully.
Caution: Keep an eye on the alert log, as eventual errors can end up in a RUNNING but
inconsistent database!
Restart the Standby database

 Logon to the hotstandby system as ora<sid>
 startup nomount;
 alter database mount standby database exclusive;
 exit

Restart the database
If the target database is supposed to run in ARCHIVELOG MODE, you have to activate it.
 shutdown immediate
 startup mount
 Following line ONLY if you have to run in ARCHIVELOG MODE:
 alter database archivelog;
 Following line ALWAYS:
 alter database open;
The following step ‗Start Oracle listener‘ is only needed if the database is restored from
standby.
Start Oracle Listener

Start the listener if it‘s not already running:
 lsnrctl start
Note: DO NOT START SAP HERE YET.
Create OPS$<SID>ADM user and grant sapdba role to

First start Oracle (if not already started):
Logon to the target system as ora<sid>

lsnrctl start
sqlplus internal
startup
exit
Go to /sapmnt/<SID>/exe and run CHDBPASS.817 or CHDBPASS.102 (Select option a,c

and d)
Note: if The CHDBPASS.817 file is not available. Therefore, the commands to create
the OPS$<SID>ADM account must be run manually. Perform the following steps:
Logon to the target system as ora<sid>

drop user ops$ora<SID> cascade;
create user ops$ora<SID> identified externally default tablespace psapuser1d
temporary tablespace psaptemp;
grant dba,connect,resource to ops$ora<SID>;
drop user ops$<SID>adm cascade;
create user ops$<SID>adm identified externally
default tablespace psapuser1d
temporary tablespace psaptemp;
grant dba,connect,resource to ops$<SID>adm;
create table ops$<SSID>adm.sapuser as select * from ops$<TSID>adm.sapuser;

exit
Also the passwords for sapr3, sys, and system must be set. Run the following
commands:
Find current passwords from warp ; Logon to the target system as ora<sid>
connect / as sysdba;
alter user system identified by passwd;
alter user sapr3 identified by passwd;
alter user sys identified by passwd;
update ops$sidadm.sapuser set passwd = 'passwd';
commit;
exit
Check for connectivity to the database with the following command as <sid>adm:
R3trans -d
4 Post-Copy Steps
4.1 Removing hostname entries
Remove the entries added during presteps . DON‘T JUST COMMENT the line, completely
remove it.
Log on to the target system as root

vi /.shosts
remove entry: <sourceservername> root
remove entry: <targetservername> root
Log on to the source system as root

(Noted : Not applicable for hot-standby machine)
vi /.shosts
remove entry: <targetservername> root
4.2 Fix GLOBAL_NAME parameter in Oracle

SAP recommends to change the GLOBAL_NAME parameter after a change of the SID
(which is of course done with a refresh). This is recommended via notes about the
homogeneous system copies (for example see note 201149 for 4.6C and 407123 for
6.x).
Change the global name via:
su – ora<sid>
sqlplus ―/ as sysdba‖
select * from global_name; (this will show an entry for the old DB name)
alter database rename global_name to <NEWSID>.world;
select * from global_name; (this will now show the right SID, for example)
GLOBAL_NAME
--------------------------------------------------------------------------------
SID.WORLD
4.3 Reset Oracle SYS and SYSTEM password

After database copy, the SYS and SYTEM passwords can become inconsistent with the
encrypted password in , which could cause database backup to fail.
(find the current SYS/SYSTEM password from warp)
su – orasid
SQL> alter user sys identified by password;
SQL> alter user system identified by password;
4.4 Fix SAP License Key

After a successful database copy, the SAP license key database will reflect only the key(s)
that were in the source system. In order for users to be able to log into the target system,
the appropriate license key has to be installed. Some projects install all of their project
license keys in all systems so that this step can be eliminated. If the license key is not
installed, proceed as follows:
 Logon to the target system as <sid>adm

 cat saplicense.save
 saplicense –install
Answer all questions with values provided by saplicense.save
Note: For NW07 systems with digitally-signed licenses e.g. Gchem CRM, this will not
work.
1. In the SAP menu choose Administration  Administration  SAP Licenses or call

transaction SLICENSE.
2. Click New Licenses
3. Delete the license from the source system
4. Install the license for the target system.
4.5 Cleanup /sapmnt/SID/global

Before starting SAP we have to remove the WF_LOG files and other directories in the
/sapmnt/SID/global/ directory on the target system. Since the files in the
/sapmnt/SID/global directory are related to the Oracle database on the system, all these
files can be removed when the DB is replaced during a refresh.
 Use this command to remove the files and directories :
rm -r /sapmnt/SID/global/*
4.6 Start SAP for the first time

When SAP is started after the refresh, all batchjobs that were not able to run during the
time of the refresh will be released immediately when SAP is started. These batchjobs
can send out purchase-orders etc to actual suppliers. As this can cause serious issues,
several customers want these jobs to be prevented from running. This is done by setting
the number of batchjobs to 0, before starting SAP for the first time. After starting SAP
there is now time to delete all released jobs in SM37, wihtout the danger of them being
kicked off at the startsap command.
Su – sidadm
Cdpro
We can edit the number of background workprocesses to 0 in instance profile
(eg:: rdisp/wp_no_btc=0 can be set in instance profile using vi editor)
Startsap
Then login to SAP and go to transaction SM37, Cancel all the released jobs to schedule.
Stopsap
Revert the btc processes to earlier value from 0 and

Startsap
4.7 Manual run of backup log

Before you Proceed please check the saparch directory to see how much free space is
available. Run the backup of logs in order to clean up the SAP directory.
4.8 Re-enable crontab for root on target server

Re-enable root‘s cron (make sure that the same file saved earlier during the step 0 pre-work
is loaded – it should have been saved and restored to /local/etc/sapadm as part of the
procedures): May need to replace the date format with the actual date the backup was
made-)
# crontab /local/etc/sapadm/root.crontab.`date +”%d%m%Y”`
4.9 Transport System Configuration

After a successful database copy, the transport system needs to be reconfigured.
Proceed as follows:
 Logon to the target SAP in client 000 as DDIC
 Run transaction SE06
 Choose ―Database copy or migration‖
 Press ―Post-installation processing‖
 Confirm ―Do you want to reinstall the CTS…‖
 Enter Source System SID
 Select OK or YES to all remaining prompts.
 Run transaction STMS
 Enter Description, Domain name(default is DOMAIN_<SID>) and domain
description. Check if the system is MC II then you have to fillin functional name
instead of hostname.
 Press Save
 Go to ―Overview‖‖Transport routes‖
 Go to ―Configuration‖‖Adjust with Controller‖
 Confirm the next popup box that says ―Adjust with controller?‖
 Go back to main screen.
 Run transaction SE06.
 Click System Change Option button.
 Validate the value is set to « objects cannot be changed>
4.10 Delete all spool request

After a successful database copy, the spool requests listed in the Target <SID> will reflect
those of the Source <SID>. Therefore, all spool requests need to be deleted from the Target
<SID>. Proceed as follows:
 Logon to the target SAP

 Enter RSPO1041(RSPO0041 for 3.1I) in the program field, and click execute.
 Enter the values like the following screen
 Select menu item Program => Execute in background

 A printer destination screen appears, enter LP01 as printer name, and uncheck
Print immediately.
 Click green check, and the job will begin in a batch process, run immediately.
4.11 Delete Update Entries

 Run transaction SM13
 Erase all entry fields and press enter/execute
 Delete all entries.
4.12 Delete Lock Entries

At the time that the backup of the Source <SID> was taken, there may have been lock
entries listed. These will have been copied to the Target <SID> after the successful
database copy and will need to be deleted. Proceed as follows:
 Erase all entry fields displayed
 Select Menu Items Lock entry => Delete all
4.13 Delete Source SID Profile Parameter Files

After the database refresh, the active profiles listed in the SAP system will be from the source
system. These profiles need to be deleted and the profiles from the OS need to be re-
imported. Proceed as follows:
 Run transaction RZ10.
 Delete source system profiles:
 Click the Profile drop-down box and choose a profile (this process must be done
for each profile, except for the DEFAULT.PFL).
 Select menu items: Profile -> Delete -> All versions of a profile.
 Click Yes to first prompt to update the database
 Click No to delete the files from the Op. Sys. Level
 Click green check on all versions deleted screen
 Repeat steps 1-3 for all source system profiles listed in the Profile drop-down list.
 Import all profiles from Unix by selecting menu items: Utilities -> Import Profiles
-> of active servers.
 Green back arrow.
4.14 Delete Source SID Op Modes

After a successful database copy, the target system will contain Operation Modes from the
source system. These Op Modes need to be deleted and the correct Op Modes need to be
imported. Proceed as follows:
 Run transaction RZ04
 Select Instance/Opmodes
 Select a server name and press SHIFT F2.
 Do this for each source system op mode listed.
 Create the target system op mode configuration(s) by selecting the menu
items Settings -> Based on Current Status -> New Instances -> Generate
 Check each of the new op modes for correctness. In the Pre Copy Steps, a
snapshot of the Target <SID> Op-modes was taken and downloaded to a
directory/filename on the local PC. Verify the Op-modes with this hardcopy
listing.
 Click the SAVE button.
4.15 Delete Server Specific Performance Data

After a successful database copy, the performance database will reflect that of the Source
<SID> and, therefore, should be deleted from the Target <SID>. Proceed as follows:
 Execute transaction ST03.
 Select Menu Items Goto => Performance database => Contents of
database
 Select Delete Data 1 Server button
 Enter the source server db server name and click Continue
 Repeat this for each source app server name.
 Select Menu Items Workload => Reorg => Delete Stats file.
 Select NO to update the database
 Select YES to delete the statistics file
4.16 Check System Logs

Check the system logs to see if there were any unusual error messages generated while the
SAP system was started back up. Proceed as follows:
 Execute transaction SM21.
 Select menu items System logs -> Choose -> All remote system logs.
 Set the From date/time fields to the date and time just prior to starting the
SAP system.
 Select the All messages radio button.
 Click the Reread system log button.
 Review the system messages. Take action on any messages that may look
suspicious.
4.17 Fix Logon Group Names (SMLG and RZ12)

 Run transaction SMLG
 Delete Source Logon Groups:
 Highlight the Source Logon Group.
 Click the Delete Group button.
 Recall the target system‘s Logon Group names which were captured in the
Pre-Copy steps.
 Click the Add assignment button
 In the Logon group field type in the target logon group name, exactly as it
looked in the snapshot taken in the Pre-Copy steps. (case-sensitive)
 Delete RFC Server Groups:
 Highlight the Logon Group.
 Click the Delete Group button.
 Recall the target system‘s Logon Group names which were captured in the
Pre-Copy steps.
 Click the Add assignment button
 In the Logon group field type in the target logon group name, exactly as it
looked in the snapshot taken in the Pre-Copy steps. (case-sensitive)
4.18 Re-initialize Import Jobs

After the database copy has successfully completed, the import jobs used by the tp
command may not work properly. It is best to delete these jobs and reschedule them new.
Proceed as follows:
 Logon to the target system in client 000 as DDIC.
 Run transaction SM37.
 Type RDDIMPDP* in the ―Job name‖ field.
 Type * in the ―User name‖ field.
 Only select the ―Sched.‖, ―Released‖, and ―Ready‖ radio buttons.
 Erase both date fields.
 Execute the transaction.
 Select all jobs and click the delete button.

 Execute program RDDNEWPP. Specify job class A or highest priority. A
message will show up in the status bar indicating the job has been scheduled.
 Log onto the target system in each of the other clients and repeat previous 2
steps. This will schedule the needed jobs in each client where transports will be
migrated.
4.19 Restore printers

Using the <Transport number> created in step 2.13. <client_number> is the default
system client or using the Local file.
Transport :
1. Login to SAP client 002

2. SPAD
3. Click the Change button
4. Select Utilities, For Output Devices, Delete All
5. Ignore any errors/warnings
6. Logon to the target system as <sid>adm
7. cd /usr/sap/trans/bin
8. tp addtobuffer <Transport Number> <SID>
9. tp import <Transport Number> <SID> client<client_number> U128
Local file :
personal id.
2. SPAD
5. Click on the line of one of the printers
6. In menu, go to Edit --> Transfer --> import
7. Export/Import file name : Fillin the destination of your C -drive where you saved the
file of the printers in step 2.15.
8. example : c:/apps/reserveprintersSID.txt
9. Select Frontend computer
10. Select Import
11. Select Execute import and Generate log
12. For Output device : Fillin *
13. Click on execute
4.20 Import User Master Records

After a database copy, the User Master Records (UMR) in the target system will be the same
as was in the source system. Normally, it is desirable to export the UMR‘s prior to the
database copy step and then re-import them after the copy completes.
cd /usr/sap/trans/bin
tp addtobuffer <SID>KTxxxxx [pf=TP_DOMAIN_<Sid of domain controller>.PFL> ]
<SID>
tp import <SID>KTxxxxx <SID> client<client_number> [pf=TP_DOMAIN_<Sid of
domain controller>.PFL ] U128
Note: The Part in the [ ] maybe required. The domain controller is usually the
development server for this landscape. For example if target system is AB3 the domain
controller is DB3.
The transport number was generated in one of the Pre-Copy steps . This process may have
to be completed for multiple clients depending on customer requirements for the target
system.
4.21 Change Client Settings

 Logon to the target SAP in client 002
 Execute transaction SCC4
 Change the category to ―Test‖ for the client that you just imported the user
masters into
 Change the Client Protection to Level 0
 Hit Save button
 Repeat this step for each client that the user import was performed
4.22 Perform client import post processing

(All R3 systems) Steps Prior to Execution of SCC7
In all R3 systems, before executing scc7, determine the storage quality of the table. If
the storage quality is less than 70%, we should re-build the index. This will speedup the
scc7 run considerably.
For determining the storage quality of the imported user master:
 Logon to Production client

 Go to ->tcode db02
 Click on Detailed Analysis
 Type USRBF2 as object name; this is the table for User buffer content for fast
RFC logon
 Click Table ->Indexes ; the table name and the index are displayed
 Place the cursor on the index(USRBF2~0) and click on Detailed Analysis
button
 Check the storage quality; select Analyis Index->Storage quality from the
menu
 If Storage quality is less than 70%, we have to rebuild index
 For rebuilding indexes, go to Alter index->rebuild
 After rebuild is completed, proceed to execute Scc7

Part 1 – Run SCC7
Please note: in large systems, this step may take an hour to complete.
 Logon to the target SAP in each of the imported clients

 Run transaction SCC7
 Verify the transport request number matches the transport number that was
created during the user master export in the Request field.
 Verify the profile name, Export time, and Export System fields.
 Click the ―Schedule in background‖ button.
Part 2 – Reset User buffers
 Logon to the target system in the productive client as firebasis
 Run transaction se38
 Enter program RSUSR405 and click execute.
 Login to SAP again to verify your id profiles are now set to the target settings,
NOT production settings.
For systems at lower versions
- Logon to the target system in the productive client

- Enter the transaction SU01
- Go to Menu, Utilities -> mass changes -> reset all user buffers.
4.23 Change Client Settings

 Execute transaction SCC4
 Select each client and verify that entries are appropriate for the following fields:
 Std Currency
 Category (Note: only one client can be marked as ―Production‖ for the SID).
Change the main client back to ―Production‖
 Change the Client Protection to Level 1
 In the subsequent sections, verify that these values are set:
 ―No changes allowed‖ - For productive clients, at least.
 ―No changes to Repository and cross-client customizing objects‖ are selected.
4.24 Restore data for RFC, ITS, SAPconnect, SSO, HTTP(S), SCOT and Logical
Printer Server tables
After a successful database copy, the RFC destinations in the target system will have values
reflecting the source system. This needs to be changed to reflect the target system. In this
case you have already a transport available containing RFC tables and/or the exported dump
file for the ―application‖ and/or ―temporary‖ tables.
Transport :
 Run STMS
 Overview -> Imports
 Double click the Target system SID name
 Use menu option Extra -> Other Requests -> Add
 Enter the transport number from RFC Export done in Pre steps
 Highlight the transport from the list and hit the transport button.
Exported dump file :
Import the exported dump file of the ―application‖ and/or ―temporary‖ tables :
<tablename>
<tablename>
To save copy of the refreshed tables:
 su – ora<sid>
 sqlplus /nolog
 connect <SAP tables schema>/password> {e.g. connect sappe8/m0tor}
Example tables :
create table ZTBD00 as select * from TBD00

create table ZTBD05 as select * from TBD05
create table ZEDIPOA as select * from EDIPOA
create table ZEDIPORT as select * from EDIPORT
To confirm the tables have already being backup:
Select table_name from dba_tables where table_name like ‗Z%‘;
To drop the refreshed tables
 su – ora<sid>
 sqlplus /nolog
 connect <SAP tables schema>/<password> {e.g. connect sappe8/m0tor}
Example tables :
drop table TBD00

drop table TBD05
drop table EDIPOA
drop table EDIPORT
- Import the original tables
su – ora<sid>
{sapsid = SCHEMA (table owner) of sap tables}
imp <sapsid>/<password> FILE=/oracle/<SID>/sapreorg/expdat.dmp tables=

<tablename>, <tablename> buffer=1024000 grants=N indexes=N
For Gchem CRM, it is not necessary to save a copy of the refreshed tables before doing the
import.
4.25 Run System Consistency Check

This will execute the system consistency check and will report any problems that were found.
There should be no errors, however, if any do appear, they need to be resolved before
opening up the system to end-users.
4.26 Fix DB13 jobs

During the refresh the DB13 (DBA Planning Calendar) tables are reset. To fix that
proceed as follows:
First delete the SM37 DBA Batch jobs:
 Logon to the Target server using your id.
 Execute the transaction SM37
 Select Job name: DBA*, User name: *, Job status: Released, Job start condition
to: <a date a month ahead>
 Select all the Jobs
 Goto Job and click on Delete
 Confirm message
 Then create the DB13 jobs preserved in Pre steps with transaction DB13
 Confirm that jobs are released by executing the transaction SM37
 Select Job name: DBA*, User name: *, Job status: Released,
Job start condition to: <a date a month ahead>
4.27 Convert CCMS tables

The tables OSMON, PAHI, MONI, DBSNP are to be converted in the database with
transaction SE14 (delete with data). The old monitor data is thus cleared from the CCMS
monitors. Proceed as follows:
 Logon to the target SAP in client 000 (as ddic user)
 Enter one of the table names (OSMON, PAHI, MONI, AND DBSNP).
 Select the Object type Table.
 Press the Edit button.
 Select radio-button delete data, Process type should be Direct.
 NOTE!!! DO NOT PRESS THE DELETE DB TABLE HERE!!!
 Press activate and adjust database.

 Repeat steps 2-6 for each of the tables listed above.
4.28 Changing The Source Server To Target Server Name For SAPCOMM
 Logon to the target SAP in client 000 (as ddic)
 Run transaction SCOM
 In Destination block choose ‗Server Assignment‘
 Press Change push button, if there is no entry, click ‗EXIT‘.
 Change the server field to the Target Server name.
4.29 Restore TXCOM table entries

 Logon to the target SAP in default client using your own id
 Click the Create button and enter the field info from the copy of the screen
taken in the pre-Refresh steps.
4.30 Remove System Messages (or adjust)

Check the system to see if there were any system messages and remove/update them.
Proceed as follows:
 Execute transaction SM02.
 Click on a message, select the Delete button.
 Repeat this until all messages have been removed.
 If a message existed prior to the refresh, Click the Create button.
 Enter the message and click Save button.
4.31 Re-cycle SAP

 Logon to UNIX on the target database server as <sid>adm account.
 Execute the Unix command stopsap to stop the SAP instance.
 Execute the Unix command startsap to restart the SAP instance on the
database server.
 Execute the Unix command ps -ef | grep ora. This will generate a listing of all
Oracle processes. There should be several of these Oracle processes listed.
 Execute the Unix command ps -ef | grep sap. This will generate a listing of
all SAP processes. There should be several of these SAP processes listed.
4.32 Start SAP on all application servers (if applicable)

 Logon to UNIX on the application server as <sid>adm account.
 Execute the Unix command startsap to start the SAP application instance.
4.33 Check background processing

 Check the boxes for ―Profile parameter‖ and ―Execute external programs‖.
 Select the radio button ―All background servers‖.
 Click the Execute button.

 Review the report for errors.
4.34 Clear Background Objects

 Start transaction SM61
 Goto Object  Modify Object.
 Click on Cleanup list button.
4.35 Import application server Profile Parameter Files

 Run transaction RZ10.
 Import all profiles from Unix by selecting menu items: Utilities -> Import Profiles
-> of active servers.
 Green back arrow.
4.36 Add required application servers to the Op Modes

 Logon to the target SAP in client 002
 Select Instance/Opmodes
 Create the target system op mode configuration(s) by selecting the menu items
Settings -> Current Status -> New Instances -> Generate
 Check each of the new op modes for correctness. In the Pre Copy Steps, a
snapshot of the Target <SID> Op-modes was taken and downloaded to a
directory/filename on the local PC. Verify the Op-modes with this hardcopy
listing.
 Click the SAVE button.
4.37 Reschedule Standard SAP Jobs

 Logon to the target system
 Schedule the Standard Jobs which were running earlier
4.38 Fix workload storage parameters

During a refresh the parameters that define how long to keep the workload storage
statistics are reset to the default. To fix:
 In the target system
 Run ST03
 Select menu option Workload -> Reorganize-> Parameters -> Performance
Database.
 Select modify parameters button
 Change the Days= 31, weeks=5 and months =12.
 Hit save Button.
4.39 Configuring J2EE 6.40/7.00

After the refresh and before starting the SAP system for the first time, the J2EE engine must
be ―reconfigured‖ in order for the engine to start properly.
Drop the Source System J2EE Schema and Tablespace
The J2EE schema and tablespace for the source system must be removed before re-
configuring the J2EE engine on the target system. Perform the following:
su - <ora>sid
drop user SAP<SSID>DB cascade;
Continue with create the J2EE schema user.
drop tablespace PSAP<SSID>DB including contents and datafiles;
Create the J2EE tablespace using sapdba

During the installation of the J2EE engine, a new tablespace is created in the ABAP stack
called PSAP<SID>DB. This tablespace must be recreated after the system has been
restored. Perform the following to create the tablespace:
su – ora<sid>
sapdba (See the warp file for the system password)
Select c – Tablespace administration -> a – Tablespace-> g - Create/drop

tablespace
Select b – New Path.

By default the tablespace is created in sapdata1. Type of path of the filesystem that
contain more than 1GB of space. In this example, /oracle/SID/sapdata8 was used.
Select c – New Size
Type 1024M to create a 1GB tablespace.
Select s – Start to Create the tablespace. Press q to return.
Create the J2EE Schema User (SAP<SID>DB or SAPMIWDB or SAPCRMDB )
As ora<sid> perform the following steps to create the J2EE user.
su – ora<sid>
create user SAP<SID>DB identified externally default tablespace PSAP<SID>DB temporary

tablespace PSAPTEMP;
alter user sap<sid>db identified by <password>;
grant select_catalog_role,connect, resource to SAP<SID>DB;
exit
Re-create the J2EE Users in the ABAP Stack

The J2EE ABAP users are removed from the ABAP stack. The following users must be re-
created in the ABAP stack The following users must be created on the main client:
 J2EE_GUEST
 J2EE_ADMIN
 SAPJSF
All three users should be created with the Communication user type to prevent the
passwords from expiring.
Perform the following:
Access transaction SU01
Enter J2EE_ADMIN in the user field.
Click the button.
In the Last Name and First Name field, enter the user name (i.e. J2EE_ADMIN).
Enter a valid email address in the E-Mail field.
Click the Logon data tab.
Enter an initial password for the user
Enter Group name in the User Group for Authorization Check field.
During creation, the User type should be set as a Dialog user. After creating the user, set
the User Type as Communications. This prevent the password of the user from expiring.
Click the Roles tab:
Note: When creating

the SAPJSF user, add
the SAP_ALL and
SAP_NEW in the
Profiles tab.
For the J2EE_ADMIN user, enter SAP_J2EE_ADMIN in the role field. The J2EE_ADMIN and
J2EE_GUEST users do not have any profile assigned.
The following chart contains the roles and profiles for the J2EE ABAP users.
User Roles Profile
J2EE_ADMIN SAP_J2EE_ADMIN None
J2EE_GUEST SAP_J2EE_GUEST None
SAPJSF SAP_BC_JSF_COMMUNICATION SAP_ALL, SAP_NEW
Perform the steps above to re-create the remaining users.
Import the J2EE schema (SAP<SID>DB)

Perform the following the import the J2EE schema:
su - ora<sid>
cd sapreorg
imp sap<sid>db/<Password> file=/oracle/<SID>/sapreorg/exportj2ee.dmp full=y

indexes=y grants=y log=/tmp/importj2ee.log
RZ11 -> param-name: rdisp/j2ee_start -> display -> Change value -> New value:
1 -> save
Start the J2EE engine using SMICM:
Administration > J2EE Server > Restart > Yes
At the OS level, verify the J2EE is running. You should see the following processes (different
on J2EE 7.00):
ps –ef | grep jlaunch
/usr/sap/SID/DVEBMGSXX/j2ee/os_libs/jlaunch
pf=/usr/sap/SID/SYS/profile/SID_DVEBMGSXX_<Host> -DSAPINFO=SID_<Sys
no>_server
pf=/usr/sap/SID/SYS/profile/SID_DVEBMGSXX_<Host> -DSAPINFO=SID_<Sys no>_sdm
pf=/usr/sap/SID/SYS/profile/SID_DVEBMGSXX_<Host> -DSAPINFO=SID_<Sys
no>_dispatcher
For J2EE 7.00 check if the state is Running.
tail /usr/sap/<SID>/DVEBMGSXX/work/dev_server0
[Thr 16708] Thu Sep 6 09:44:55 2007

[Thr 16708] JLaunchISetState: change state from [Starting applications (10)] to [Running
(3)]
Test the connection to the J2EE engine using the Appropriate URL and port number:
The following is displayed:
Verify the configuration Portal Connection for BW systems.
 Logon with J2EE_ADMIN user to the Portal (HTTPS/<Port number>)

 Navigate to "System Administration" -> "System Configuration"
 Expand Portal Content.
 Expand Systemlandscape
 Right click on SAP_BW  Open  Connection Tests
Select all tests and choose Test. The tests must complete successfully.
Note: If there exist a problem in bringing up java after refresh check if user sapjsf in
unlocked and correct password of it is maintained in secure store.
4.40 Re-import BugsEye & eMerge data (if applicable)
Re-Import BugsEye data & eMerge data (if applicable) in the following way:
Make sure the J2EE processes are stopped! (done for both BugsEye & eMerge)
Stop the j2ee processes:
Logon to SAP
SMICM  Administration  J2EE Server  Send Hard shutdown  Without
Restart
Optional  Check processes: ps –ef | grep jlaunch
STEP. Drop user bugreq

su – ora<sid>
sqlplus ‗/as sysdba‘
drop user bugreq cascade;
commit;
STEP. Create user BUGREQ in SAP EBP system

su - ora<sid>
create user BUGREQ identified by <See WARP> default tablespace PSAPBUGSEYE
temporary tablespace PSAPTEMP;
grant create session to BUGREQ;
grant create table to BUGREQ;
grant create sequence to BUGREQ;
grant unlimited tablespace to BUGREQ;
grant create view to BUGREQ;
grant create any cluster to BUGREQ;
grant create any context to BUGREQ;
grant create any index to BUGREQ;
grant create any indextype to BUGREQ;
grant create any procedure to BUGREQ;
grant create synonym to BUGREQ;
grant create trigger to BUGREQ;
grant CTXAPP to BUGREQ;
STEP. Import all bugseye data info into SAP EBP system
su - ora<sid>
imp bugreq/<See WARP> file=/oracle/<SID>/sapreorg/exportbug.dmp full=y
indexes=y grants=y commit=y log=/tmp/importbug.log
STEP. Test connection

Start the J2EE processes:
Logon to SAP
SMICM  Administration  J2EE Server  Send Hard shutdown  With Restart
{it can take up to 5 minutes before the homepage is available}
Test connection: http://<servername + dns>/requisite/login.htm
For eMerge:
Make sure the J2EE processes are stopped again.
Logon to SAP
SMICM  Administration  J2EE Server  Send Hard shutdown  Without
Restart
STEP. Drop user emereq

su – ora<sid>
drop user emereq cascade;
commit;
STEP. Create user EMEREQ in SAP EBP system

su - ora<sid>
create user EMEREQ identified by <See WARP> default tablespace PSAPEMERGE
temporary tablespace PSAPTEMP;
grant create session to EMEREQ;
grant create table to EMEREQ;
grant create sequence to EMEREQ;
grant unlimited tablespace to EMEREQ;
grant create view to EMEREQ;
grant create any cluster to EMEREQ;
grant create any context to EMEREQ;
grant create any index to EMEREQ;
grant create any indextype to EMEREQ;
grant create any procedure to EMEREQ;
grant create synonym to EMEREQ;
grant create trigger to EMEREQ;
grant CTXAPP to EMEREQ;
STEP. Import all emerge data info into SAP EBP system
su - ora<sid>
imp emereq/<See WARP> file=/oracle/<SID>/sapreorg/exporteme.dmp full=y

indexes=y grants=y commit=y log=/tmp/importbug.log
STEP. Test connection

Start the J2EE processes:
Logon to SAP
SMICM  Administration  J2EE Server  Send Hard shutdown  With Restart
{it can take up to 5 minutes before the homepage is available}
Test connection: http://<servername + dns>/emerge/login.htm
4.41 Run sapdba_role.sql to fix Oracle privileges for OPS$SIDADM

The OPS$SIDADM Oracle account must have the privilege of SAPDBA to allow the DBA
housekeeping jobs to work properly. You must run the sapdba_role.sql. First you must make
sure you have the proper script.
On the target server

su – ora<sid>
cd /local/bin/sap/dbcopy
grep OPS sapdba_role.sql
V_User := 'OPS$' || '&&1' || 'ADM';

V_User := 'OPS$SAPSERVICE' || '&&1';
The results should look like the above
sqlplus system/<password>
@sapdba_role.sql <SID> UNIX
select * from dba_role_privs where grantee like ‗OPS%‘;
The output should look like the following :

GRANTEE GRANTED_ROLE ADM DEF
------------------------------ ------------------------------ --- ---
OPS$D04ADM SAPDBA NO YES
OPS$D04ADM CONNECT YES YES
OPS$D04ADM RESOURCE YES YES
4.42 SAP INFOCUBE INDEXES REPAIR

Run report SAP_INFOCUBE_INDEXES_REPAIR (Applicable for BW systems on version 3.5
and below)
Some background: BW systems are running with NOLOGGING configured on Oracle

level. This means that the creation of indexes are not captured in redologs. While BW
drop/recreates indexes quite frequently as part of dataloading, lots of index creations
are not in the redologs. When rolling forward a database during a refresh, these indexes
will get corrupted blocks. The solution is to drop/recreate these indexes in the refreshed
system (switching on LOGGING in the production system is not feasible as performance
would go down. NOLOGGING is also the SAP recommendation for BW systems).
In BW system client:
SE38  SAP_INFOCUBE_INDEXES_REPAIR  Program  Execute in
background
This can and probably will run for hours. You can however safely continue with the next
steps. There is no need to wait for this program to finish.
4.43 Convert logical system names(BDLS RUN)

Old logical system name = <SSID>CLNT<Client number>
New logical system name = <TSID>CLNT<Client number>
Login to the Production client and navigate to transaction BDLS, and proceed to schedule
all LSN conversions from Source to target(There might be more than one BDLS runs
depending on LSN‘s which exist in the system which indeed depends on clients too)
Be sure to select radio button Conversion of client-dependant and client-independent

tables!
Deselect the check boxes Test Run and Existence check on new names in tables
Program  Execute in background.
You will get a warning LSN already exists: press ―enter‖ to ignore (don‘t click on the
warning, it won‘t work).
This will run for quite a while.
It is not feasible to wait on the outcome of the first run before starting the second run,
as too much time would be wasted. Therefore scheduled the BDLS‘s one hour behind
eachother. In this way the BDLS runs can still hit the same table simultaneously (and
therefore slow down), but overall it will be quicker than running sequentially.
The output of the SM37 job does not give all the information. However, the application
log of SAP catches the actual output of BDLS.
Go to the application log via transaction SLG1  enter appopriate dates  Execute.
Expand the row as below and doubleclick on the line Problem Class.
Click on the Choose button to see the actual output of the BDLS run.
If there persist a problem in BDLS Conversion we can proceed converting them from
SQL prompt too.
Apart from these we also need to reconfigure/repair important RFC connections in case they are not
working after database refresh.

SAP Database Referesh PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SAP Database Referesh PDF

Uploaded by

Copyright:

Available Formats

Database

Title Database Refresh Procedure

Author Ahmed Khan

Reviewed Balmukand Sharma

Operating System AIX 5.3

4.21 Change Client Settings 39

2 Pre Copy steps

2.2 Check Space in Target System

Additional Checks for storage in APO – LCA system

Additional Checks for storage in APO – LCA system

Example: If source is SSID and target system is TSID (df –gt)

 In both systems go to T-code LC10 -> Live cache Monitoring ->

Source system(Source SID(SSID))

2.3 OpenSSH to OpenSSH trust (host based trust)

(Example shown below)

<trusted server>,<trusted server>.<domain name> ssh-dss

(include a line of the format :

<trusted server>.<domain name> root

2.4 Verify Oracle control file directories on target server

According to the standards they should be in /oracle/<SID>/cntrl,

Execute transaction SCC8

Perform the following before proceeding with SAP screen.

find ./data ./cofiles -name ‗*00017.<SID>‘ -exec ls -lastr {} \;

Secure store tables are also exported.

Program Object Object Name Table Description/Purpose

R3TR TABU CREP_HTTP * KPRO CMS: Content Repositories

There are two options to preserve the printers :

12. Click on execute

if the BugsEye data & eMerge data needs to be saved.

If the customer agrees to save the data do the following:

- Export all data info from BugsEye instance

For eMerge (for GSAP)

2.9 Export J2EE Database Schema

Export the SAP<SID>DB or SAPMIWDB schema using schema password

cd /oracle/<SID>/sapreorg (need at least 2GB free for SAPMIWDB)

exp sap<sid>db/<Password> file=/oracle/<SID>/sapreorg/exportj2ee.dmp full=y

2.10 Capture the standard SAP jobs released in SAP

2.11 Check & Preserve details of PSAPTEMP datafiles

2.12 Preserve BI Accelerator Indexes

Start transaction /nRSDDV in the BI instance.

Select the Display All BIA Indexes button or select (F6)

2.13 Logon Group Names (SMLG and RZ12)

2.14 Op-mode Snapshot

2.15 Check and Save Logical System Definition

2.16 Preserve DB13 entries

 Goto DB13 on the target system.

2.17 SAP License Snapshot

 Log on to the target system at UNIX as <sid>adm

2.18 Determine SAP version

1. Log on to SAP with your personal id

2.19 Preserve TXCOM table entries

3 Restoring/Copying the database

3.1 Procedure to Refresh Database from the online/offline Backup

Disable crontab for root on target system

<upgrade_server> # crontab -l > /local/etc/sapadm/root.crontab.`date

Actions on Target System

Bring down the J2ee Engine

Perform the following path:

Bring down SAP and clean up the system

If this isn‘t working then use :

If it can find the files then use this :

Copy needed files from source system to target system

On Source/Standby system- To make sure that the backup by