SAP ORACLE SYSTEM REFRESH

(Restore and Recovery)

> PREREQUISITES:

ACTIVITY: HOW / WHAT

Before starting the refresh process, ensure that you have a backup of both the
1. Preparation source and target systems.
This is crucial to prevent data loss in case of any issues during the refresh.

Ensure that the target system is shut down or set to a restricted mode where no
2. Shutdown the Target System users can access it during the refresh.

1) Login to target system (ex: QAS) and execute tcode SCC8.

2) Select the profile SAP_USER and provide the target system where later this user
master needs to be imported after refresh.
3) After this schedule in background. --- Select the source client from where export
3. Export of user master and authorizations needs to be taken and click on immediately and execute. and click on continue to
confirm.
4) Follow these steps to all the clients in the target system to export.
>> After this it will give you three transport numbers.

Client settings (SCC4)

Logon groups (SMLG)
Processing groups (RZ12)
AL11, SE03 and SM61
Printer details (SPAD)
Operation modes (RZ03, RZ04 and SM63)
4. Take snapshots of: RFCs (SM59)
Partner profiles (WE20) and ports (WE21)
Logical systems (BD54)
Services that are active (SICF)
These screenshots are to be captured because after system refresh, we need to
check and maintain the same settings in target system.

As part of pre-refresh steps, we need to take backup of target system’s.

*Go to SE01 --- create Transport of copies --- after which you will get a REQUEST
NUMBER.
*Double click on Request Number --- enter the program ID, Object type and Object
name.
Ex: For AL11 --- R3TR (program ID), TABU(object type), USER_DIR (object name).
*Double click on the object name and give * for keys.
5. Create transport request *SAVE and go back.
*Fill in this for all the below T codes:
Printer settings (SPAD)
Processing groups (RZ12)
Logon groups(SMLG)
Logical systems (BD54)
Operation mode settings(RZ03/RZ04)
RFCs related information(SM59)
AL11(sap directories)
 SE03 (transport organizer tool settings)
Batch processing relation information (SM61)
Customer entries information (SM69)
Archive related settings (OAC0)
Include all the above tables details in the transport request and save.
**Make sure to release this transport before the refresh starts. Otherwise the
cofile and datafile will not generated and you will not be able to import this
transport later. If we can’t import request, then we may have to create/maintain
all these configurations manually which will be tedious and complex task.**

>> Check source system backup size.

>> Check kernel and oracle version of source and target.
6. Also check >> Check all the process running in target system and start after refresh --- ps -ef
>> Check and resize the file systems before restore.

> REFRESH ACTIVITY: DB REFRESH >> DB RESTORE & RECOVERY

STEPS IN SOURCE SYSTEM (Ex: PRD) STEPS IN TARGET SYSTEM (Ex: QAS)

1. Create CONTROL FILE and edit control file in target. 1. RESTORE the Backup file.

2. Find the BACKUP to be used. 2. Cleanup the ORAARCH DIRECTORY.

3. Find the REDO LOGS to be applied. 3. Change the ownership and permission of REDO LOG files.

4. Copy the backup to target system. 4. Validate the backup size with source.

5. Exit from source system. 5. Recover DB and apply logs.

> REFRESH ACTIVITY - (Source system steps in detail)

ACTIVITY: HOW / WHAT / WHY

>> What is control file?

- These are used to update the information dynamically about the database
structure changes.
- It consists of the paths, log sequence no, system changes number and it is
essential to restore and recover the database.

>> How to create control file?

1. Create CONTROL FILE and edit control file in target. 1) Switch to oracle --- su - oracle
sqlplus / as sysdba
2) Command to create contol file?
Alter Database backup controlfile to trace as '/oracle/<SID>/control_<SID>.SQL'
Resetlogs;

>> How to edit control file?

In Target system go to control file location and use Vi command to edit.
 1) Replace source SID with target SID.
:1, $S/<source SID>/<target SID>/G
2) Go to top of the control file and change REUSE to SET
3) Go to bottom of the control file and make note of the temp file of tablespace in
notepad, after DB recovery create temp file of table space.
4) Save file.

>> Rename or delete old control files in target system. After recovery these files
will be automatically created.

>> Go to cd/oracle/SID/sapbackup
>> Tail -10 xbrbackupSID.log
2. Find the SOURCE BACKUP to be used. >> This provides complete status of the backup taken (Ex: Last 10 (Primary)
backups with time, date).

>> What is REDO LOG?

In SAP, the database system writes to a redo log file all redo log entries of
transactions that were not completed at the last savepoint and which need to be
repeated by the database system. Redo log entries are write-ahead log entries,
meaning that the entries are written before the actual data is written. The redo log
is managed by the logger component.

3. Find the REDO LOGS to be applied. >> How to find REDO LOGS?
1) Go to /oracle/<source SID>/sapbackup
2) tail -10 xbrbackSID.log
3) grep log <backupfile name>
- This provides redo log files which needa to be copied to target system.
4) Copy this required logs to /oracle/target SID/oraarch

>> Find backup in source system.

- cd/oracle/source SID/sapbackup
4. Copy the backup to target system. - ls -lrt (you will get list of backup files ex: filename.afd)
- Copy this file to target system /oracle/target SID/sapbackup directory.

5. Exit from source system. >> After completing all the above activities, Exit from the source system.

> REFRESH ACTIVITY - (Target system steps in detail)

ACTIVITY: HOW / WHAT / WHY

>> HOW to Restore?

1) Go to target system.
2) Switch to oracle and go to backup location.
Su - oracle
1. RESTORE the Backup file. cd /oracle/target SID/sapbackup/
ls -lrt
4) Command to Restore:
brrestore -m full -b <backup filename> -c

>> Cleaning up the ORAARCH directory after a restore operation in the target
2. Cleanup the ORAARCH DIRECTORY. system is essential for efficient disk
space management, improved system performance, data integrity, compliance,
and security.
>> It is recommended to establish a regular cleanup process as part of the system
 maintenance activities to keep the
ORAARCH directory clean and optimized.
>> Before cleaning up the ORAARCH directory, identify which archived redo log
files are obsolete or unnecessary archived redo log files and can be safely
removed. You can use SQL*Plus queries to identify obsolete files based on
retention policies or specific criteria.

>> Stop the database if necessary.

>> Locate the redo log files.
3. Change the ownership and permission of REDO LOG files. >> Change ownership and permission by chown and chmod.
>> Verify changes.
>> Start the database.

1) Check Source Data Size: Determine the total size of the data on the source
system that was backed up. This can often be done using database management
tools or file system utilities.
2) Check Backup File Size: Verify the size of the backup file created from the
source system.
4. Validate the backup size with source. 3) Check Restored Data Size: After restoring, check the size of the data on the
target system.
4) Compare Sizes: Compare the size of the source data with the size of the
restored data on the target system. The sizes should be comparable, allowing for
some differences due to compression or file system overhead.

>> After doing th restore check your database status.

>> su - oracle
>> sqlplus / as sysdba
>> select status from v$instance; ------- to check database status (started or
unmounted , mounted , open).
>> If your database in mounted :--> it is ready for recovery.

Command to recovery,
>> recover database using backup controlfile until cancel;
- There are 5 types --- 1.cancel 2.data and time 3.Point in time 4 .lsn(least or log
sequenc no.) 5.scn(system change number).
>> Next it will ask for Log files,
Give AUTO --- Automatically logs will be applied from oraarch directory and
recover will processed and completed.
5. Recover DB and apply logs.
Check the database status. If it is mounted change it to open.
>> select status from v$instance; ---- mounted.
mounted ----- open
>> alter database open resetlogs;
>> select status from v$instance; ---- open(db is running).
exit from sql and exit from oracle.

>> su - sidadm
>> R3trans -d ----- to check weather by db is coonecting with application or not.
--- If it results 0012 ----- check trans.log to debug the error.
--- If it results 0000 or 0004 (warning) --- sucess

>> startsap r3 ----- To start the application.

> POST REFRESH ACTIVITIES:

ACTIVITY: HOW / WHAT / WHY

By setting batch work processes as 0 at OS level.

1. Disable batch processing

2. Start sap system and login with sap* user

In SAP environment, there will be a requirement to install a license to a new

installed SAP system or to a system refreshed from another system. This is the
primary step in the post refresh activities of an SAP system.

SAP license key can be requested from Service Marketplace from the following
link:

"http://service.sap.com/licensekey

How:
3. Install SAP license * Download license key for a SAP system and store in your local desktop.
* Once the license files are downloaded from market place, login into 000 client
using SAP* user of an SAP system on which you would like to apply license.
* Execute transaction SLICENSE to apply the license.
* Click on “Old Licenses” tab to list old licenses existing in the system.
* Select each license and delete license by navigating. Repeat this step until all old
licenses are deleted.
* To install new license click on install button. This provides the file manager,
navigate to the location where license file that was downloaded from marketplace
was kept in your desktop and select the file and click open to input the license file.
* It then displays message after successful installation of license key.

>> After system refresh, you may have to hold jobs from execution in target
system because the target system consists of source system jobs and they
shouldn’t run. So, it is suggested to hold all the jobs from execution and release
only required jobs and basis standard jobs(housekeeping jobs).
>> Sometimes, there might be duplicate schedule of same job and you want to
hold the duplicate job to prevent multiple executions.
>> In these cases, to hold the jobs to prevent from execution, we need to set the
status of those jobs from “Released” to “Scheduled”.
4. Prevent batch job from running by setting all jobs from released to How:
scheduled * Execute SM37.
(using SM37) * Keep * in the user field and job field.
* Select only RELEASED jobs ---- Execute.
* All the jobs which are released will be displayed.
* Select the job --- go to the JOB tab in menu ---- click on Released ----> Scheduled.
Then all the selected jobs status will be set as “Scheduled” and those jobs won’t
get executed till you release them again.

>> Deleting and recreating the TMS configuration for the target system using SE06
after a system refresh is a critical
5. Delete/recreate TMS for target system using SE06 step to ensure the integrity, consistency, and accuracy of the transport landscape
in SAP.
It helps prevent transport-related issues and ensures smooth operation of the
TMS in the refreshed system landscape.
>> By recreating the TMS configuration, you have the opportunity to redefine and
recreate transport routes between systems in the landscape. This ensures that
 transport routes are correctly configured to facilitate the movement of transport
requests between systems in the refreshed landscape.
>> Do not delete the STMS configuration or transport routes if the domain
controller for the source and target is same.

How:
* Login to target system (ex: QAS).
* Execute STMS.
* Go to Import queue of QAS.
6. Import user master for all clients (which was done as part of pre- * Add that transport request which was generated before refresh activity and
refresh steps) import it.
* Then perform post processing using SCC7.

>> The import queue in the target system retains all the released transport
7. Import transports related to AL11, SE03, SMLG, RZ12, SM59, SALE requests that were present before the system refresh. These requests remain in
and SM69 backup the queue with their statuses and contents preserved.
>> Import the Released Transport Request in QAS system.
(which was done in pre-refresh steps)

>> BDLS is used for LOGICAL System Name conversion after System Refresh
activity.
>> In BDLS Conversion ,Production Logical System Name is changed to Quality
Logical System Name.
Example:
8. Execute BDLS transaction If we are doing refresh from PRD Client 970 to QAS Client 970 then we need to run
BDLS for
PRDCLNT970 –> QASCLNT970

>> After system refresh, the target system will have SAP profiles of source system.
So, we need to delete the old
profiles and import new SAP profiles of the target system.
>> How to delete existing SAP profiles after system refresh?
* Go to transaction RZ10 and select the profile to be deleted.
* After selecting, navigate to Profile tab -> Delete -> All Versions -> Of a profile.
This will delete the profile.
9. Delete old SAP profiles and import new profiles using RZ10 * Perform this for all the old profiles.
transaction >> How to import the SAP profiles?
* Go to RZ10 transaction and navigate to Utilities tab -> Import Profiles -> Of
active servers. This will import all the profiles of active servers in the SAP system.
>> How to check consistency of all profiles in SAP system?
* Go to transaction RZ10 and navigate to Utilities tab -> Check all profiles -> Of
active servers. This will display profile check log with details of any inconsistencies.

>> Performing a spool consistency check helps detect any inconsistencies, errors,
or discrepancies in the spool system configuration, such as missing devices,
incorrect printer definitions, or unresolved print requests.
>> Ensure that print requests are processed accurately and output documents are
delivered to the intended destinations without errors.
10. Perform spool consistency check using SP12 transaction How:
* Execute SP12.
* Go to the TemSe data storage tab ---- consistency check.
* After the check is completed, the system will display the results, indicating any
inconsistencies, errors, or warnings detected during the process.

Deleting old update records helps optimize system performance by reducing the
11. Delete old update records using SM13 transaction volume of data stored in the database tables.

12.Delete/Reorganize transaction RFC’s using SM58 transaction >> During a system refresh, RFC entries from the source system may be copied to
the target system's transaction RFC queue. These entries could be no longer
relevant in the target system environment. Deleting or reorganizing these RFC
 entries ensures that only valid and necessary entries remain in the queue.
>> The presence of unnecessary RFC entries in the transaction RFC queue can
increase system overhead and resource consumption, including database space,
memory usage, and processing time. Deleting or reorganizing RFC entries helps
minimize system overhead and ensures that system resources are used effectively.

>> Deleting old batch job logs removes unnecessary data, freeing up storage space
13. Delete batch job logs by executing RSBTCDEL report using SE38 and optimizing system performance.
transaction >> This helps to optimize system performance, ensure data privacy and
compliance, and facilitate effective log management in SAP environments.

>> The accumulation of old spool requests can consume significant database
14. Delete Old spool requests by executing RSPO0041 report using resources and impact system performance. Deleting old spool requests frees up
SE38 transaction database space and improves system performance by reducing the load on the
database server.

>> SAP Transaction WE20 (Partner Profile) is used in SAP for managing partner
profiles and communication settings. It allows users to create, change, and display
partner profiles, which define the communication parameters and settings for
exchanging data with external partners (such as customers, vendors, and banks) in
various SAP modules.
15. Create/modify necessary partner profiles using WE20 transaction >> Partner profiles play a crucial role in ensuring the integrity and reliability of
data exchange processes between SAP systems and external partners. By creating
or modifying partner profiles after a system refresh, organizations can maintain
data exchange integrity and minimize the risk of communication errors or data
inconsistencies.

>> SAP Transaction WE21 (Port Maintenance) is used to configure communication

channels in SAP systems. It allows users to define various ports and their
associated parameters to establish connections with external systems. WE21 is
essential for integrating different systems and enabling seamless data exchange,
16. Modify necessary ports using WE21 transaction ensuring smooth business processes and efficient information flow.
>> You can also create transport request with we20 and we21 tables and import
them after the system refresh.

>> Configuring mail settings in SCOT is essential to ensure the reliable delivery of
emails from the SAP system to external recipients and vice versa. It allows
17. Perform mail configuration using SCOT transaction administrators to specify the SMTP (Simple Mail Transfer Protocol) server and
other mail parameters required for sending and receiving emails.

>> Old mail-related entries in the SOST transaction can clutter the user interface
and make it difficult to find relevant information. By deleting outdated entries,
18. Delete old mail related entries using SOST transaction users can navigate the SOST transaction more efficiently and focus on managing
current mail requests and messages.

>> Executing SGEN or RSGENINVLAS helps regenerate ABAP load objects, such as
19. Execute SGEN transaction or run RSGENINVLAS report (no variant executable programs, function modules, and classes, to ensure optimal system
is required) using SE38 performance.

>> This is essential for enabling web-based functionalities, supporting integration

scenarios, enabling external access, facilitating Fiori applications, enhancing user
20. Make necessary services active through SICF transaction experience, and ensuring compliance with security policies in SAP environments.
It ensures that the SAP system is accessible and functional for users, partners, and
external systems in the updated system landscape.