63
Database Refresh Procedure 0

Database Refresh Procedure

Embed Size (px)

Citation preview

Page 1: Database Refresh Procedure

Database Refresh Procedure

0

Page 2: Database Refresh Procedure

1. Introduction 42. Pre Copy steps

2.1 Verify the passwords in the source and target systems 52.2 Check Space in Target System 62.3 OpenSSH to OpenSSH trust (host based trust) 62.4 Verify Oracle control file directories on target server 82.5 Export Target SID/Client Users & retain user master records 82.6 Save data for RFC, ITS, SAPconnect, SSO, HTTP(S), SCOT

and Logical Printer Server tables 92.7 Preserve printers 122.8 Backup BugsEye & eMerge data(If Applicable) 132.9 Export J2EE Database Schema 142.10 Capture the standard SAP jobs released in SAP 142.11 Check & Preserve details of PSAPTEMP datafiles 142.12 Preserve BI Accelerator Indexes 152.13 Logon Group Names (SMLG and RZ12) 152.14 Op-mode Snapshot 162.15 Check and Save Logical System Definition 162.16 Preserve DB13 entries 162.17 SAP License Snapshot 172.18 Determine SAP version 172.19 Preserve TXCOM table entries 17

3 Restoring/Copying the database 3.1 Procedure to Refresh Database from the online/offline Backup 193.2 Procedure to Refresh DB from the other DB in the same server 27

4 Post-Copy Steps4.1 Removing hostname entries 324.2 Fix GLOBAL_NAME parameter in Oracle 324.3 Reset Oracle SYS and SYSTEM password 334.4 Fix SAP License Key 334.5 Cleanup /sapmnt/SID/global 334.6 Start SAP for the first time 334.7 Manual run of backup log 344.8 Re-enable crontab for root on target server 344.9 Transport System Configuration 344.10 Delete all spool request 354.11 Delete Update Entries 354.12 Delete Lock Entries 36

1

Page 3: Database Refresh Procedure

4.13 Delete Source SID Profile Parameter Files 364.14 Delete Source SID Op Modes 364.15 Delete Server Specific Performance Data 364.16 Check System Logs 374.17 Fix Logon Group Names (SMLG and RZ12) 374.18 Re-initialize Import Jobs 374.19 Restore printers 384.20 Import User Master Records 384.21 Change Client Settings 394.22 Perform client import post processing 394.23 Change Client Settings 404.24 Restore data for RFC, ITS, SAPconnect, SSO, HTTP(S), SCOT and Logical Printer Server tables 404.25 Run System Consistency Check 414.26 Fix DB13 jobs 424.27 Convert CCMS tables 424.28 Changing The Source Server To Target Server Name For

SAPCOMM 424.29 Restore TXCOM table entries 424.30 Remove System Messages (or adjust) 424.31 Re-cycle SAP 434.32 Start SAP on all application servers (if applicable) 434.33 Check background processing 434.34 Clear Background Objects 434.35 Import application server Profile Parameter Files 434.36 Add required application servers to the Op Modes 434.37 Reschedule Standard SAP Jobs 444.38 Fix workload storage parameters 444.39 Configuring J2EE 6.40/7.00 444.40 Re-import BugsEye & eMerge data (if applicable) 504.41 Run sapdba_role.sql to fix Oracle privileges for OPS$SIDADM 524.42 SAP INFOCUBE INDEXES REPAIR 524.43 Convert logical systems names 53

2

Page 4: Database Refresh Procedure

1 Introduction

A Database refresh/copy consists of three sections or units of work:1. Pre Copy steps2. Restoring/Copying the database files3. 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

3

Page 5: Database Refresh Procedure

2.1 Verify the passwords in the source and target systemsBefore 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))

4

Page 6: Database Refresh Procedure

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

5

Page 7: Database Refresh Procedure

# cat ssh_host_dsa_key.pub

(Example shown below)

ssh-dss AAAAB3NzaC1kc3MAAACBAPyNO8hfzk9+WBS5nOSAhmu/eVE9+4t6Wd5sGRwWNAdyDtFF9ux/CKcgeK8o2OPFSeCcuNiw8d3NOHLCLHNjB6lH8V3L9R8+7b8hDpfpZ4fxcYKlP6W/EXHyWuv8DrEyCdyaFbYNzul7JaJx1j5lOEUa6TFJDbouqRsp/Mw0jsbBAAAAFQD4kBx7i/53NeFZ7C2GXIEDL+mAuwAAAIBzbYbmh8xDG0DQzMt6Ury0aqyDoawbnEq9uAlulvcheivO2VnZfqO9HEFd18JPIXTLWTCjtriE/6zpsgUR9oR2PCMbNW9S+PtIZ5HZ4NbTlCvF7gNxlibZ4sAB5e6zbb3Xso59K9H6m0lFNZFKrg/P0vWumYtGEw/n16tUr9LxRwAAAIEAjf+4Eis9/ippFAeNIVfKL28KlYrqlcdBHIhE/wy6/HEvAoNZ3fdxMjzvgn8gtEpzsy1+gql3o00uSJiNJKcMDzREfPqqxtu7lttOT9VYFM9mGFaLW+eBWh+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+4t6Wd5sGRwWNAdyDtFF9ux/CKcgeK8o2OPFSeCcuNiw8d3NOHLCLHNjB6lH8V3L9R8+7b8hDpfpZ4fxcYKlP6W/EXHyWuv8DrEyCdyaFbYNzul7JaJx1j5lOEUa6TFJDbouqRsp/Mw0jsbBAAAAFQD4kBx7i/53NeFZ7C2GXIEDL+mAuwAAAIBzbYbmh8xDG0DQzMt6Ury0aqyDoawbnEq9uAlulvcheivO2VnZfqO9HEFd18JPIXTLWTCjtriE/6zpsgUR9oR2PCMbNW9S+PtIZ5HZ4NbTlCvF7gNxlibZ4sAB5e6zbb3Xso59K9H6m0lFNZFKrg/P0vWumYtGEw/n16tUr9LxRwAAAIEAjf+4Eis9/ippFAeNIVfKL28KlYrqlcdBHIhE/wy6/HEvAoNZ3fdxMjzvgn8gtEpzsy1+gql3o00uSJiNJKcMDzREfPqqxtu7lttOT9VYFM9mGFaLW+eBWh+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

6

Page 8: Database Refresh Procedure

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 writtengrep 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:

7

Page 9: Database Refresh Procedure

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 ID

Object Object Name Table Key

Description/Purpose

R3TR TABU RSECTAB * Secure store table client-specificR3TR TABU RSECACTB * Secure store table cross-clientR3TR TABU RFCATTRIB * Administration table for RFC

destinationsR3TR TABU RFCDES * Destination table for Remote Function

CallR3TR TABU RFCDESSECU * SNC extensions for RFC destinationsR3TR 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 tableR3TR TABU TSPSI * Spool: Server Information (Updated

8

Page 10: Database Refresh Procedure

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 / IHUBR3TR TABU SXNODES * SAPconnect: Communication nodes

R3TR TABU SXROUTE * SAPconnect: Routing tableR3TR TABU SXSERV * SAPconnect: Node capabilitiesR3TR TABU SXADMINTAB * SAPconnect and SAPphone:

AdministrationR3TR TABU SXDOMAINS * SAPconnect: Management of Internet

Mail Addresses DomainsR3TR TABU SOPR * SAPoffice: System-wide profile

(default domain)R3TR TABU SXADDRTYPE * SAPconnect: Address typesR3TR TABU SXCONVERT * SAPconnect: Conversion functions

R3TR TABU SXCONVERT2 * SAPconnect: Conversion Functions for Forma

R3TR TABU SXCOS * SAPconnect: Send attribute classesR3TR TABU SXCOS_T * SAPconnect: Text table for send

classes R3TR TABU SXDEVTYPE * SAPconnect: Device Types for Format

ConverR3TR TABU SXFORMATG * SAPconnect: Format groups R3TR TABU SXJOBS * SAPconnect: Send Jobs R3TR TABU SXRETRY * SAPconnect: Disruptions in RFC

connectionsR3TR 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 SystemR3TR TABU TWPSSO2ACL * Workplace Single Sign-On 2 Access

Control List

R3TR TABU SSF_PSE_H * SSF: Personel Security EnvironmentR3TR TABU SSF_PSE_D * SSF: Storage for Personal Security

Environment Data

9

Page 11: Database Refresh Procedure

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}

10

Page 12: Database Refresh Procedure

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 :

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

11

Page 13: Database Refresh Procedure

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.txt8. 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 instancesu – 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 instancesu – ora<sid>exp emereq/<See WARP> file=/oracle/<SID>/sapreorg/exporteme.dmp full=y 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

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>

12

Page 14: Database Refresh Procedure

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

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) 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.

13

Page 15: Database Refresh Procedure

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.

14

Page 16: Database Refresh Procedure

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 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:

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

2.15 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:

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

15

Page 17: Database Refresh Procedure

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 id2. 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.x5. 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.

16

Page 18: Database Refresh Procedure

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 SystemBring down all the applications of SAP( for ex:: Patrol, ControlM agent, CCMSR etc)

Bring down the J2ee EngineAccess transaction SMICM

Perform the following path:

17

Page 19: Database Refresh Procedure

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-root>cd /oracle/<SID>/sapbackuproot>more <*.anf> or more <*.aff> for standby (if applicable)

To make sure that the backup by which you need to restore is successful.

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 : 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. SCP the backup file needed from source system to target System.

2. Change the permissions and ownership of Backup file.

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

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

18

Page 20: Database Refresh Procedure

root> chown ora<target sid>:dba init<source sid>.utl3. root > vi init<source sid>.utl Change CONFIG_FILE parameter as :- CONFIG_FILE /oracle/<target sid>/dbs/init<source sid>.bki

need to change Config_file parameter. This is needed to start the restore.

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

1. SCP init<source sid>.bki from source to target

2. Change permissions & ownership of init<source sid>.bki

On source system1. ora<sid> sqlplus ‘/ as sysdba’ sqlplus > alter database backup controlfile to trace; sqlplus > exit3. 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

1. To create the trace file.2. Scp the trace file to the target

system.3. Change the

permission/ownership of trace file.

Editing the tracefile on target system 1. root> vi <trace file>2. The file has been created double, remove the

first file3. Remove all the starting lines of tracefile until

STARTUP NOMOUNT3. Edit the 2nd line – CREATE CONTROLFILE REUSE DATABASE "SOURCE SID" NORESETLOGS ARCHIVELOG toCREATE CONTROLFILE SET DATABASE “TARGET SID” RESETLOGS NOARCHIVELOG4. 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

1. To go into vi mode2. 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 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

19

Page 21: Database Refresh Procedure

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 StorageStart 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”^Dfor 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 databaseOn Target System:

su – ora<sid> sqlplus “/ as sysdba” @createcontrol.sql

Check in the /oracle/<SID>/saptrace/background/alert_<SID>.log for any errors.

20

Page 22: Database Refresh Procedure

Restoring offline redologsIn 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 databaseThere 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 databaseFirst 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.

21

Page 23: Database Refresh Procedure

Recreation of the tempfilesWe 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 ADD TEMPFILE '/oracle/SSID/sapdata6/temp_4/temp.data4' SIZE 1999M REUSE AUTOEXTEND OFF;ALTER TABLESPACE PSAPTEMP ADD TEMPFILE '/oracle/SSID/sapdata6/temp_3/temp.data3' SIZE 1999M REUSE AUTOEXTEND OFF;ALTER TABLESPACE PSAPTEMP ADD TEMPFILE '/oracle/SSID/sapdata6/temp_2/temp.data2' SIZE 1999M REUSE AUTOEXTEND OFF;ALTER TABLESPACE PSAPTEMP ADD TEMPFILE '/oracle/SSID/sapdata6/temp_1/temp.data1' SIZE 1999M REUSE AUTOEXTEND OFF;

Change sourceSID to targetSID Create the needed subdorectories in the sapdata filesystem(s)

cd /oracle/<targetSID>/sapdata6mkdir temp_1  mkdir temp_2  mkdir temp_3  mkdir temp_4

Create the tempfiles: su – ora<sid> sqlplus “/ as sysdba”

ALTER TABLESPACE PSAPTEMP ADD TEMPFILE '/oracle/TSID/sapdata6/temp_1/temp.data1'

SIZE 1999M REUSE AUTOEXTEND OFF; Sqlplus> ALTER TABLESPACE PSAPTEMP ADD TEMPFILE

'/oracle/TSID/sapdata6/temp_2/temp.data2'SIZE 1999M REUSE AUTOEXTEND OFF;

Sqlplus> ALTER TABLESPACE PSAPTEMP ADD TEMPFILE '/oracle/TSID/sapdata6/temp_3/temp.data3'

SIZE 1999M REUSE AUTOEXTEND OFF; Sqlplus> ALTER TABLESPACE PSAPTEMP ADD TEMPFILE

'/oracle/TSID/sapdata6/temp_4/temp.data4'SIZE 1999M REUSE AUTOEXTEND OFF;

Making locally managed temporary datafiles non-sparseThe 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.

22

Page 24: Database Refresh Procedure

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> 40> mv temp2_1/temp2.data1 /oracle/SID/sapdata5/temp2.data1ora<sid> 41> mv /oracle/SID/sapdata5/temp2.data1 temp2_1/temp2.data1ora<sid> 40> mv temp2_2/temp2.data2 /oracle/SID/sapdata5/temp2.data2ora<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$ userWe 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 ModeCheck if the database log mode is set on archive mode with sapdba. If not, toggle database log mode.

Start Oracle ListenerThe Oracle Listener should also be started

Orasid> lsnrctl start

23

Page 25: Database Refresh Procedure

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’

24

Page 26: Database Refresh Procedure

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 OracleNote: 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 SystemCaution: 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> sqlplus ‘/ as sysdba’ shutdown immediate;

Copy the database from hotstandbyNote: 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.

25

Page 27: Database Refresh Procedure

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 restdo chfs -a options=rw,nodev,nosuid $fs umount $fs mount $fsdone

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 nowfor 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 restdo chfs -a options=rw,nodev,nosuid,cio $fs umount $fs mount $fsdone

Change ownership on restored files Logon to the target system as root cd /oracle/<targetSID>

26

Page 28: Database Refresh Procedure

chown –R ora<targetsid>:dba sapdata*

Edit the trace file on target systemUse 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 NOARCHIVELOGtoCREATE 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 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 . 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!

27

Page 29: Database Refresh Procedure

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 databaseIf 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 ListenerStart the listener if it’s 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 psapuser1dtemporary tablespace psaptemp;grant dba,connect,resource to ops$ora<SID>;

drop user ops$<SID>adm cascade;

28

Page 30: Database Refresh Procedure

create user ops$<SID>adm identified externallydefault tablespace psapuser1dtemporary 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 rootvi /.shostsremove entry: <sourceservername> rootremove entry: <targetservername> root

29

Page 31: Database Refresh Procedure

Log on to the source system as root (Noted : Not applicable for hot-standby machine)vi /.shostsremove 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 – orasidsqlplus ‘/ 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 –installAnswer 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.

30

Page 32: Database Refresh Procedure

2. Click New Licenses3. Delete the license from the source system4. 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 CdproWe 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 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.

31

Page 33: Database Refresh Procedure

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 Run transaction SE38. Enter RSPO1041(RSPO0041 for 3.1I) in the program field, and click execute. Enter the values like the following screen

32

Page 34: Database Refresh Procedure

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 re-imported. Proceed as follows:

Logon to the target SAP Run transaction RZ10.

33

Page 35: Database Refresh Procedure

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.

34

Page 36: Database Refresh Procedure

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 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) Run transaction RZ12 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. 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. <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 button4. Select Utilities, For Output Devices, Delete All

35

Page 37: Database Refresh Procedure

5. Ignore any errors/warnings6. Logon to the target system as <sid>adm7. cd /usr/sap/trans/bin8. tp addtobuffer <Transport Number> <SID>

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.txt9. 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/bintp 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

36

Page 38: Database Refresh Procedure

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.

37

Page 39: Database Refresh Procedure

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 table ZTBD00 as select * from TBD00create table ZTBD05 as select * from TBD05create table ZEDIPOA as select * from EDIPOAcreate 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

38

Page 40: Database Refresh Procedure

connect <SAP tables schema>/<password> {e.g. connect sappe8/m0tor}

Example tables :

drop table TBD00drop table TBD05drop table EDIPOAdrop 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.

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.

39

Page 41: Database Refresh Procedure

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.

40

Page 42: Database Refresh Procedure

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 re-configuring the J2EE engine on the target system. Perform the following:

su - <ora>sid

sqlplus ‘/ as sysdba’

41

Page 43: Database Refresh Procedure

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 sapdbaDuring 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

42

Page 44: Database Refresh Procedure

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 SizeType 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 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.

43

Page 45: Database Refresh Procedure

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:

44

Page 46: Database Refresh Procedure

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

/usr/sap/SID/DVEBMGSXX/j2ee/os_libs/jlaunch pf=/usr/sap/SID/SYS/profile/SID_DVEBMGSXX_<Host> -DSAPINFO=SID_<Sys no>_sdm

45

Note: When creating the SAPJSF user, add the SAP_ALL and SAP_NEW in the Profiles tab.

Page 47: Database Refresh Procedure

/usr/sap/SID/DVEBMGSXX/j2ee/os_libs/jlaunch 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.

46

Page 48: Database Refresh Procedure

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 SAPSMICM Administration J2EE Server Send Hard shutdown Without RestartOptional 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>

47

Page 49: Database Refresh Procedure

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 SAPSMICM 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 SAPSMICM 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 full=y indexes=y grants=y commit=y log=/tmp/importbug.log

STEP. Test connection

Start the J2EE processes:

48

Page 50: Database Refresh Procedure

Logon to SAPSMICM 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$SIDADMThe 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/dbcopygrep OPS sapdba_role.sql V_User := 'OPS$' || '&&1' || 'ADM';

V_User := 'OPS$SAPSERVICE' || '&&1';

The results should look like the abovesqlplus system/<password>@sapdba_role.sql <SID> UNIXsqlplus ‘/ as sysdba’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.

49

Page 51: Database Refresh Procedure

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.

50

Page 52: Database Refresh Procedure

If there persist a problem in BDLS Conversion we can proceed converting them from SQL prompt too.

51