Database Refresh Procedure

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. 2. 2.1 2.2 2.3 2.4 2.5 2.6
3 4
Introduction Pre Copy steps Verify the passwords in the source and target systems Check Space in Target System OpenSSH to OpenSSH trust (host based trust) Verify Oracle control file directories on target server Export Target SID/Client Users & retain user master records Save data for RFC, ITS, SAPconnect, SSO, HTTP(S), SCOT and Logical Printer Server tables 2.7 Preserve printers 2.8 Backup BugsEye & eMerge data(If Applicable) 2.9 Export J2EE Database Schema 2.10 Capture the standard SAP jobs released in SAP 2.11 Check & Preserve details of PSAPTEMP datafiles 2.12 Preserve BI Accelerator Indexes 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 2.17 SAP License Snapshot 2.18 Determine SAP version 2.19 Preserve TXCOM table entries Restoring/Copying the database 3.1 Procedure to Refresh Database from the online/offline Backup 3.2 Procedure to Refresh DB from the other DB in the same server Post-Copy Steps 4.1 Removing hostname entries 4.2 Fix GLOBAL_NAME parameter in Oracle 4.3 Reset Oracle SYS and SYSTEM password 4.4 Fix SAP License Key 4.5 Cleanup /sapmnt/SID/global 4.6 Start SAP for the first time 4.7 Manual run of backup log 4.8 Re-enable crontab for root on target server 4.9 Transport System Configuration 4.10 Delete all spool request 4.11 Delete Update Entries 4.12 Delete Lock Entries 4.13 Delete Source SID Profile Parameter Files 4.14 Delete Source SID Op Modes 4.15 Delete Server Specific Performance Data 4.16 Check System Logs 4.17 Fix Logon Group Names (SMLG and RZ12) 4.18 Re-initialize Import Jobs 4.19 Restore printers 4.20 Import User Master Records
4 5 6 6 8 8 9 12 13 14 14 14 15 15 16 16 16 17 17 17 19 27 32 32 33 33 33 33 34 34 34 35 35 36 36 36 36 37 37 37 38 38
4.21 4.22 4.23 4.24 4.25 4.26 4.27 4.28 4.29 4.30 4.31 4.32 4.33 4.34 4.35 4.36 4.37 4.38 4.39 4.40 4.41 4.42 4.43 Change Client Settings Perform client import post processing Change Client Settings Restore data for RFC, ITS, SAPconnect, SSO, HTTP(S), SCOT and Logical Printer Server tables Run System Consistency Check Fix DB13 jobs Convert CCMS tables Changing The Source Server To Target Server Name For SAPCOMM Restore TXCOM table entries Remove System Messages (or adjust) Re-cycle SAP Start SAP on all application servers (if applicable) Check background processing Clear Background Objects Import application server Profile Parameter Files Add required application servers to the Op Modes Reschedule Standard SAP Jobs Fix workload storage parameters Configuring J2EE 6.40/7.00 Re-import BugsEye & eMerge data (if applicable) Run sapdba_role.sql to fix Oracle privileges for OPS$SIDADM SAP INFOCUBE INDEXES REPAIR Convert logical systems names 39 39 40 40 41 42 42 42 42 42 43 43 43 43 43 43 44 44 44 50 52 52 53
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.
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 SID(TSID)
System(Target
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 lineNOT 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 lineNOT 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>/sapdata1/cntrl and /oracle/<SID>/sapdata2/cntrl ls l /oracle/<TSID>/cntrl ls l /oracle/<TSID>/sapdata1/cntrl ls l /oracle/<TSID>/sapdata2/cntrl /oracle/<SID>/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. Heres 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 arent 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 its 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 ID R3TR R3TR R3TR R3TR R3TR R3TR R3TR R3TR R3TR R3TR R3TR R3TR R3TR R3TR R3TR R3TR R3TR R3TR R3TR Object TABU TABU TABU TABU TABU TABU TABU TABU TABU TABU TABU TABU TABU TABU TABU TABU TABU TABU TABU Object Name RSECTAB RSECACTB RFCATTRIB RFCDES RFCDESSECU RFCDOC RFCTRUST RFCSYSACL IACORDES TSPSV TSPSI TSP03 TSP03A TSP03C TSP03D TSP03L TSP03T TBD11 TWPURLSVR Table Key * * * * * * * * * * * * * * * * * ZKOST * Description/Purpose Secure store table client-specific Secure store table cross-client Administration table for RFC destinations Destination table for Remote Function Call SNC extensions for RFC destinations Description of Possible RFC Connections (->RFCDES) List of existing trusting systems List of permitted trusted systems for the current system RFC Destinations for IACOR / ITS Spool: Server table Spool: Server Information (Updated by Spool Work Processes) Spool: Printer declaration Spool: Device description (new format) Spool: Device Description Extension Spool: Device Description Format) Spool: Long device names (New
Paper format in the device paper tray Transaction BD95 Configuration Logical Web Servers for Logical
Systems / I R3TR R3TR R3TR R3TR R3TR R3TR R3TR R3TR R3TR R3TR R3TR R3TR R3TR R3TR R3TR R3TR R3TR R3TR R3TR R3TR R3TR R3TR R3TR R3TR R3TR R3TR TABU VDAT TABU TABU TABU TABU TABU TABU TABU TABU TABU TABU TABU TABU TABU TABU TABU TABU TABU TABU TABU TABU TABU TABU TABU TABU ROIDOCPRMS V_TBDLS SXNODES SXROUTE SXSERV SXADMINTAB SXDOMAINS SOPR SXADDRTYPE SXCONVERT SXCONVERT2 SXCOS SXCOS_T SXDEVTYPE SXFORMATG SXJOBS SXRETRY SXRFC SXTELMOIN SXTELMOOUT T160PR TWPSSO2ACL SSF_PSE_H SSF_PSE_D SSFARGS SXMSCONFVL * * * * * * * * * * * * * * * * * * * * * * * * * * Control parameters for data transfer from the source system Logical System Names / IHUB SAPconnect: Communication nodes SAPconnect: Routing table SAPconnect: Node capabilities SAPconnect and SAPphone: Administration SAPconnect: Management of Internet Mail Addresses Domains SAPoffice: System-wide profile (default domain) SAPconnect: Address types SAPconnect: Conversion functions SAPconnect: Forma SAPconnect: SAPconnect: classes SAPconnect: Conver SAPconnect: SAPconnect: SAPconnect: connections SAPconnect: address to n Conversion Functions for Send attribute classes Text table for send Device Types for Format Format groups Send Jobs Disruptions in Assignment of
RFC RFC
SAPconnect: Telephone number modification SAPconnect: Telephone number modification Profile for External Purchasing System Workplace Single Sign-On 2 Access Control List SSF: Personel Security Environment SSF: Storage for Personal Security Environment Data Application-Dependent Parameters for SSF Functions (SSFG) XMS: Integration Configuration Parameters Engine
R3TR R3TR R3TR R3TR R3TR TABU TABU TABU TABU TABL CREP_HTTP HTTPURLLOC RSADMINA RSDDTREXADMIN RSPOR_T_PORTAL * * * * * KPRO CMS: Content Repositories (HTTP) HTTP URL Location Exception Table Control Parameters for BI (Accelerator) Additional Settings for Indexing of an HPA Index 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 Preserve printers There are two options to preserve the printers : Transport Local file
2.7
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. 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. Select Request Request header, enter a valid
Local file : 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. 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 * 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 (Please don't forget this otherwise it will only export
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 indexes=y grants=y log=/tmp/exporteme.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 2.9 Export J2EE Database Schema
full=y
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) full=y
exp sap<sid>db/<Password> file=/oracle/<SID>/sapreorg/exportj2ee.dmp indexes=y grants=y log=/tmp/exportj2ee.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
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) ='PSAPTEMP';
from
dba_temp_files
where
tablespace_name
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 casesensitive.
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. For Target system logon in SAP client, where you have enough authorizations 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 Opmodes in the Source <SID>. Therefore, it is important to take a snapshot of the Op-modes in the Target <SID>. Proceed as follows: 2.15 For Target system logon in SAP client, where you have enough authorizations 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 Check and Save Logical System Definition For Target system logon in SAP client, where you have enough authorizations
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: 2.18 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 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
3.1
Restoring/Copying the database

Procedure to Refresh Database from the online/offline Backup
Disable crontab for root on target system Disable roots cron to make sure that nothing runs that might have an impact on the refresh <upgrade_server> # crontab -l > +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 /local/etc/sapadm/root.crontab.`date
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 isnt 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 systemroot>cd /oracle/<SID>/sapbackup root>more <*.anf> or more <*.aff> for standby (if applicable) 1. On Source/Standby system : root> cd /oracle/<SID>/sapbackup 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. On Target system : To make sure that the backup by which you need to restore is successful. 1. SCP the backup file needed from source system to target System.
2. Change the permissions and ownership of
root> chmod g+r *.anf (or .aff file for standby (if applicable)) root> chown ora<target sid>:dba *.anf (or .aff file for standby (if applicable)) 1. On Source system: root> scp init<sid>.utl <target system>:/oracle/<sid>/dbs/ 2. On Target system root> chmod g+r init<source sid>.utl root> chown ora<target sid>:dba init<source sid>.utl 3. root > vi init<source sid>.utl Change CONFIG_FILE parameter as :CONFIG_FILE /oracle/<target sid>/dbs/init<source sid>.bki 1. On Source system ; root> cd /oracle/<sid>/dbs root> scp init<source sid>.bki <target system>:/oracle/<target sid>/ 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. ora<sid> sqlplus / as sysdba sqlplus > alter database backup controlfile to trace; sqlplus > exit 3. scp this file created in /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. root> vi <trace file> 2. The file has been created double, remove the first file 3. Remove all the starting lines of tracefile until STARTUP NOMOUNT Backup file.
1. SCP init<sid>.utl file from source to target. 2. Change the permissions and ownership of init<source sid>.utl 3. Edit init<source sid>.utl . We need to change Config_file parameter. This is needed to start the restore.
1. SCP init<source sid>.bki from source to target 2. Change permissions & ownership of init<source sid>.bki
1. To create the trace file. 2. Scp the trace file to the target system. 3. Change the permission/ownership of trace file.
1. To go into vi mode 2. To remove all the unwanted lines. All the lines are to be removed until STARTUP NOMOUNT, beginning from first line.
3. Edit the 2nd line CREATE CONTROLFILE REUSE DATABASE "SOURCE SID" NORESETLOGS ARCHIVELOG to CREATE CONTROLFILE SET DATABASE TARGET SID RESETLOGS NOARCHIVELOG 4. Remove also all the 2 lines, at the bottom of the tracefile #RECOVER DATABASE #ALTER DATABASE OPEN RESETLOGS; 5. Change all source sid to target sid. This can be done by using vi command :1,$s/<source sid>/<target sid>/g 3. Edit the 2nd line as said. 4. Comment the 3 lines, which is present at the bottom of the tracefile. We do this manually later. 5. This is an easy command to change all the sid of source system to the sid of target system. Note :Make sure no new datafile has being 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; ALTER TABLESPACE PSAPTEMP ADD TEMPFILE '/oracle/PC6/sapdata6/temp_3/temp.data3' SIZE 1999M REUSE AUTOEXTEND OFF; ALTER TABLESPACE PSAPTEMP ADD TEMPFILE '/oracle/PC6/sapdata6/temp_2/temp.data2' SIZE 1999M REUSE AUTOEXTEND OFF; ALTER TABLESPACE PSAPTEMP ADD TEMPFILE '/oracle/PC6/sapdata6/temp_1/temp.data1' 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 sourcesystems 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: ALTER TABLESPACE PSAPTEMP '/oracle/SSID/sapdata6/temp_4/temp.data4' SIZE 1999M REUSE AUTOEXTEND OFF; ALTER TABLESPACE PSAPTEMP '/oracle/SSID/sapdata6/temp_3/temp.data3' SIZE 1999M REUSE AUTOEXTEND OFF; ALTER TABLESPACE PSAPTEMP '/oracle/SSID/sapdata6/temp_2/temp.data2' SIZE 1999M REUSE AUTOEXTEND OFF; ALTER TABLESPACE PSAPTEMP '/oracle/SSID/sapdata6/temp_1/temp.data1' ADD ADD ADD ADD TEMPFILE TEMPFILE TEMPFILE TEMPFILE
SIZE 1999M REUSE AUTOEXTEND OFF; 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> sqlplus / as sysdba SIZE SIZE SIZE SIZE ALTER TABLESPACE PSAPTEMP '/oracle/TSID/sapdata6/temp_1/temp.data1' 1999M REUSE AUTOEXTEND OFF; Sqlplus> ALTER TABLESPACE PSAPTEMP '/oracle/TSID/sapdata6/temp_2/temp.data2' 1999M REUSE AUTOEXTEND OFF; Sqlplus> ALTER TABLESPACE PSAPTEMP '/oracle/TSID/sapdata6/temp_3/temp.data3' 1999M REUSE AUTOEXTEND OFF; Sqlplus> ALTER TABLESPACE PSAPTEMP '/oracle/TSID/sapdata6/temp_4/temp.data4' 1999M REUSE AUTOEXTEND OFF; ADD ADD ADD ADD TEMPFILE TEMPFILE TEMPFILE 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>
sqlplus / as sysdba 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> ora<sid> ora<sid> ora<sid> 40> 41> 40> 41> mv mv mv mv temp2_1/temp2.data1 /oracle/SID/sapdata5/temp2.data1 /oracle/SID/sapdata5/temp2.data1 temp2_1/temp2.data1 temp2_2/temp2.data2 /oracle/SID/sapdata5/temp2.data2 /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 . ; 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
vi CHDBPASS.102
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) systems 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 dont 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> sqlplus / as sysdba
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 dont 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 SIDboth 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$[09]*$$/\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$[09]*$$/\1/' ` do echo $(date): Copying /oracle/<hotstandbySID>/sapdata${i} filesystem cp -p -r /oracle/<targetSID>/sapdata${i} & ^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 /oracle/<hotstandbySID>/sapdata${i}/*
done | tee -a /tmp/hotstandby_copy.$(date +%Y%m%d%H%M%S).log
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: Logon to the target system as ora<sid> sqlplus / as sysdba @/tmp/<tracefile> recover database using backup controlfile until cancel; Cancel this immediately. You dont really have to apply logs. (NOTE: If an online 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> sqlplus / as sysdba 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. Logon to the target system as ora<sid> sqlplus / as sysdba
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 its not already running: Logon to the target system as ora<sid> 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> sqlplus / as sysdba 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. commands:
Run the following
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
Post-Copy Steps
4.1 Removing hostname entries Remove the entries added during presteps . DONT 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 (Noted : Not applicable for hot-standby machine) vi /.shosts remove entry: <targetservername> root system as 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 sqlplus / as sysdba 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 roots 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 OverviewTransport routes Go to ConfigurationAdjust 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 Run transaction SE38. 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 Logon to the target SAP 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: Logon to the target SAP Run transaction SM12 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 reimported. Proceed as follows: Logon to the target SAP 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: Logon to the target SAP 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: Logon to the target SAP 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: Logon to the target SAP 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) Logon to the target SAP Run transaction SMLG Delete Source Logon Groups: Highlight the Source Logon Group. Click the Delete Group button. Recall the target systems 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) Run transaction RZ12 Delete RFC Server Groups: Highlight the Logon Group. Click the Delete Group button. Recall the target systems 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. Run transaction SE38. 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. system client or using the Local file. Transport : 1. Login to SAP client 002 2. SPAD 3. 4. 5. 6. 7. 8. Click the Change button Select Utilities, For Output Devices, Delete All Ignore any errors/warnings Logon to the target system as <sid>adm cd /usr/sap/trans/bin tp addtobuffer <Transport Number> <SID>
<client_number> is the default
9. tp import <Transport Number> <SID> client<client_number> U128 Local file : 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. 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 UMRs 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 Logon to the target SAP 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 : Logon to the target SAP 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 create create create table table table table ZTBD00 ZTBD05 ZEDIPOA ZEDIPORT as as as as select select select select * * * * from from from from TBD00 TBD05 EDIPOA 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 drop drop drop table table table table TBD00 TBD05 EDIPOA EDIPORT
- Import the original tables su ora<sid> {sapsid = SCHEMA (table owner) of sap tables} imp <sapsid>/<password> FILE=/oracle/<SID>/sapreorg/expdat.dmp <tablename>, <tablename> buffer=1024000 grants=N indexes=N tables=
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. Logon to the target SAP Run transaction SM28. 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) Run transaction SE14. 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 Run transaction SM54 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: Logon to the target SAP 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 Logon to the target SAP Run transaction SM65. 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 Logon to the target SAP 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 Run transaction RZ04 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 reconfiguring the J2EE engine on the target system. Perform the following: su - <ora>sid sqlplus / as sysdba 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> sqlplus / as sysdba 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 recreated 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 J2EE_ADMIN Roles SAP_J2EE_ADMIN Profile None
J2EE_GUEST SAPJSF SAP_J2EE_GUEST SAP_BC_JSF_COMMUNICATION None 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 indexes=y grants=y log=/tmp/importj2ee.log full=y
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> no>_server -DSAPINFO=SID_<Sys
/usr/sap/SID/DVEBMGSXX/j2ee/os_libs/jlaunch pf=/usr/sap/SID/SYS/profile/SID_DVEBMGSXX_<Host> -DSAPINFO=SID_<Sys no>_sdm /usr/sap/SID/DVEBMGSXX/j2ee/os_libs/jlaunch pf=/usr/sap/SID/SYS/profile/SID_DVEBMGSXX_<Host> 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)] -DSAPINFO=SID_<Sys
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> sqlplus /as sysdba 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 indexes=y grants=y commit=y log=/tmp/importbug.log full=y
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> sqlplus /as sysdba drop user emereq cascade; commit; STEP. Create user EMEREQ in SAP EBP system su - ora<sid> sqlplus /as sysdba 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 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 sqlplus / as sysdba select * from dba_role_privs where grantee like OPS%; The output should look like the following : GRANTEE GRANTED_ROLE OPS$D04ADM OPS$D04ADM OPS$D04ADM SAPDBA CONNECT RESOURCE full=y
ADM DEF NO YES YES YES 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 background Program Execute in
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 LSNs 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 (dont click on the warning, it wont 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 BDLSs 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.

Database Refresh Procedure

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Database Refresh Procedure

Încărcat de

Drepturi de autor:

Formate disponibile

Database Refresh Procedure

Database Refresh Procedure

1. 2. 2.1 2.2 2.3 2.4 2.5 2.6

Pre Copy steps

Source system(Source SID(SSID))

Capture the standard SAP jobs released in SAP

Select the Display All BIA Indexes button

Restoring/Copying the database

su - <sid>adm stopsap saposcol k su ora<sid> lsnrctl stop cd /oracle/<SID> rm r sapdata* cd /oracle/<SID>/saparch rm *

2. Change the permissions and ownership of

done | tee -a /tmp/hotstandby_copy.$(date +%Y%m%d%H%M%S).log

Run the following

<client_number> is the default

Enter J2EE_ADMIN in the user field. Click the button.

ADM DEF NO YES YES YES YES YES

------------------------------ ------------------------------ --- ---

S-ar putea să vă placă și