Database Procedure

This page was exported from - SAP ADMIN
Export date: Thu Feb 23 6:06:21 2012 / +0000 GMT
Database Refresh Procedure
Introduction
A Database refresh/copy consists of three sections or units of work: - Pre Copy steps - Restoring/Copying the database files - 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.
Output as PDF file has been powered by [ Universal Post Manager ] plugin from www.ProfProjects.com
| Page 1/65 |

Pre Copy steps
2.1
Verify the passwords in the source and target systems
Before you Proceed with the refresh you should have the login credentials in both Source and Target system with Enough Authorisations ( Super user with sap_all and sap_new profiles) (both OS and SAP level)
2.2
Check Space in Target System
Make sure that you have enough space in the Target System, equal to or more than in the Source System. Check via command (on both Source and Target Systems): As user root
| Page 2/65 |

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 inAPO? LCA system

v 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 inAPO? LCA system

v 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 /dev/lvusp_tsid_002 58.88 70.00 0.97 0.91 57.90 69.09 2% /sapdb/SSID 2% /sapdb/TSID
v In both systems go to T-code LC10 -> Live cache Monitoring -> Administration -> Configuration -> Volumes v 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
| Page 3/65 |

Source system(Source SID(SSID))
Target System(Target SID(TSID))
If the size of data area is less than the source system then add data volumes
2.3
OpenSSH to OpenSSH trust (host based trust)
Server which will be trusted for root login (referred to as ?trusted server?): Open the connection between Source system and Target system, Just in case you want to transfer any file during refresh. You can do so by directly using Secure copy command In Target System # cd /etc/ssh # cat ssh_host_dsa_key.pub (Example shown below) ssh-dss AAAAB3NzaC1kc3MAAACBAPyNO8hfzk9+WBS5nOSAhmu/eVE9+4t6Wd5sGRwWNAdyDtFF9ux/CKcgeK8o2OPFSeCcuNi w8d3NOHLCLHNjB6lH8V3L9R8+7b8hDpfpZ4fxcYKlP6W/EXHyWuv8DrEyCdyaFbYNzul7JaJx1j5lOEUa6TFJDbouqRsp/Mw0 jsbBAAAAFQD4kBx7i/53NeFZ7C2GXIEDL+mAuwAAAIBzbYbmh8xDG0DQzMt6Ury0aqyDoawbnEq9uAlulvcheivO2VnZfqO 9HEFd18JPIXTLWTCjtriE/6zpsgUR9oR2PCMbNW9S+PtIZ5HZ4NbTlCvF7gNxlibZ4sAB5e6zbb3Xso59K9H6m0lFNZFKrg/P0v WumYtGEw/n16tUr9LxRwAAAIEAjf+4Eis9/ippFAeNIVfKL28KlYrqlcdBHIhE/wy6/HEvAoNZ3fdxMjzvgn8gtEpzsy1+gql3o00u SJiNJKcMDzREfPqqxtu7lttOT9VYFM9mGFaLW+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/CKcgeK8o2OPFSeCcuNi w8d3NOHLCLHNjB6lH8V3L9R8+7b8hDpfpZ4fxcYKlP6W/EXHyWuv8DrEyCdyaFbYNzul7JaJx1j5lOEUa6TFJDbouqRsp/Mw0 jsbBAAAAFQD4kBx7i/53NeFZ7C2GXIEDL+mAuwAAAIBzbYbmh8xDG0DQzMt6Ury0aqyDoawbnEq9uAlulvcheivO2VnZfqO
| Page 4/65 |

9HEFd18JPIXTLWTCjtriE/6zpsgUR9oR2PCMbNW9S+PtIZ5HZ4NbTlCvF7gNxlibZ4sAB5e6zbb3Xso59K9H6m0lFNZFKrg/P0v WumYtGEw/n16tUr9LxRwAAAIEAjf+4Eis9/ippFAeNIVfKL28KlYrqlcdBHIhE/wy6/HEvAoNZ3fdxMjzvgn8gtEpzsy1+gql3o00u SJiNJKcMDzREfPqqxtu7lttOT9VYFM9mGFaLW+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 By doing so now your Source server has become the Trusting server and Target system has become the trusted server.
2.4
Verify Oracle control file directories on target server
Logon to the target system

- as ora<target_sid> - cd dbs The following command will display three directories where the controlfiles will be written grep dbf init<TSID>.ora According to the standards they should be in /oracle/<SID>/cntrl, /oracle/<SID>/sapdata1/cntrl and /oracle/<SID>/sapdata2/cntrl - ls ?l /oracle/<TSID>/cntrl - ls ?l /oracle/<TSID>/sapdata1/cntrl - ls ?l /oracle/<TSID>/sapdata2/cntrl
If not ensure that these directories are created and a copy of Control file is moved to them. 2.5 Export Target SID/Client Users & retain user master records
This step only applies to those projects where the user master records are to be retained in the target system. Log on to the SAP target system clients that need to have users preserved. Execute transaction SCC8 Select profile: SAP_USER Target system: use ? DUM?. YOU MUST FILL THIS VALUE IN OR IT WILL NOT WORK
| Page 5/65 |

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

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-specific
R3TR TABU RSECACTB * Secure store table cross-client
R3TR TABU RFCATTRIB * Administration table for RFC destinations
R3TR TABU RFCDES * Destination table for Remote Function Call
| Page 7/65 |

R3TR TABU RFCDESSECU * SNC extensions for RFC destinations
R3TR TABU RFCDOC * Description of Possible RFC Connections (->RFCDES)
R3TR TABU RFCTRUST * List of existing trusting systems
R3TR TABU RFCSYSACL * List of permitted trusted systems for the current system
R3TR TABU IACORDES * RFC Destinations for IACOR / ITS
R3TR TABU TSPSV * Spool: Server table
R3TR TABU TSPSI * Spool: Server Information (Updated by Spool Work Processes)
| Page 8/65 |

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
| Page 9/65 |

TABU TWPURLSVR * Logical Web Servers for Logical Systems / I
R3TR TABU ROIDOCPRMS * Control parameters for data transfer from the source system
R3TR VDAT V_TBDLS * Logical System Names / IHUB
R3TR TABU SXNODES * SAPconnect: Communication nodes
R3TR TABU SXROUTE * SAPconnect: Routing table
R3TR TABU SXSERV * SAPconnect: Node capabilities
R3TR TABU SXADMINTAB * SAPconnect and SAPphone: Administration
R3TR TABU
| Page 10/65 |

SXDOMAINS * SAPconnect: Management of Internet Mail Addresses Domains
R3TR TABU SOPR * SAPoffice: System-wide profile (default domain)
R3TR TABU SXADDRTYPE * SAPconnect: Address types
R3TR TABU SXCONVERT * SAPconnect: Conversion functions
R3TR TABU SXCONVERT2 * SAPconnect: Conversion Functions for Forma
R3TR TABU SXCOS * SAPconnect: Send attribute classes
R3TR TABU SXCOS_T * SAPconnect: Text table for send classes
R3TR TABU SXDEVTYPE
| Page 11/65 |

* SAPconnect: Device Types for Format Conver
R3TR TABU SXFORMATG * SAPconnect: Format groups
R3TR TABU SXJOBS * SAPconnect: Send Jobs
R3TR TABU SXRETRY * SAPconnect: Disruptions in RFC connections
R3TR TABU SXRFC * SAPconnect: Assignment of RFC address to n
R3TR TABU SXTELMOIN * SAPconnect: Telephone number modification
R3TR TABU SXTELMOOUT * SAPconnect: Telephone number modification
R3TR TABU T160PR *
| Page 12/65 |

Profile for External Purchasing System
R3TR TABU TWPSSO2ACL * Workplace Single Sign-On 2 Access Control List
R3TR TABU SSF_PSE_H * SSF: Personel Security Environment
R3TR TABU SSF_PSE_D * SSF: Storage for Personal Security Environment Data
R3TR TABU SSFARGS * Application-Dependent Parameters for SSF Functions (SSFG)
R3TR TABU SXMSCONFVL * XMS: Integration Engine Configuration Parameters
R3TR TABU CREP_HTTP * KPRO CMS: Content Repositories (HTTP)
R3TR TABU HTTPURLLOC * HTTP URL Location Exception Table
| Page 13/65 |

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 EnterprisePortal
- For Target system logon in SAP client, where you have enough authorizations - Goto SE01 Create button - Check Request type: Transport of copies - Uncheck any other request type Enter Short description - Enter target (DUM) or enter a SID other than the target SID - Save - Write down the transport number Click on transport request - Press ?Display object list? button - Press ?Display > Change? do be in change mode - Click on New entries. - Enter entries as listed in above table, one per line
| Page 14/65 |

10. After you have entered all objects, double click on each object to drill down to the key 11. Correction : Click on <Edit>, then click on <Insert Line>? 12. Enter '*' in each of the key field lines and save. 13. Repeat step 9-12 for all the objects. 14. Save and go back 15. Select the transport request and 16. Click on ?Release directly?. 17. Check the transport log. When ?application? or ?temporary tables? which you want to export giving errors then you have to export them via Oracle : - su ? ora<sid> {sapsid = SCHEMA (table owner) of sap tables} exp <sapsid>/<password> FILE=/oracle/<SID>/sapreorg/expdat.dmp tables=<tablename>, <tablename> buffer=1024000 grants=N indexes=N consistent=Y compress=N 2.7 Preserve printers
There are two options to preserve the printers : - Transport - Local file Transport : - Log on to one of the SAP target system client 002 (or proper one for BW) with personal id. - SPAD - Click on Change Icon - Click Output Devices - In menu, go to Edit Transport > Transport All - Press enter at screen prompt - A prompt for a transport number create a new one and press enter. - Enter a short description. - 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
| Page 15/65 |

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 :
- Log on to one of the SAP target system client 002 (or proper one for BW) with personal id. - SPAD - Click on Change Icon - Click Output Devices - Click on the line of one of the printers - In menu, go to Edit --> Transfer --> Export - Export/Import file name : Fillin the destination of your C -drive where you can store the file for the printers. Example : c:/apps/reserveprintersSID.txt - Select Frontend computer - Select Export 10. Select Execute export and Generate log 11. For Output device : Fillin * 12. Click on execute Please check in your txt file : c:/apps/reserveprintersSID.txt if the printers are there. 2.8 Backup BugsEye & eMerge data (Please don't forget this otherwise it will only export 1 printer)
if the BugsEye data & eMerge data needs to be saved. If the customer agrees to save the data do the following: For BugsEye: - Export all data info from BugsEye instance
| Page 16/65 |

su ? ora<sid> exp bugreq/<Password for bugreq user> file=/oracle/<SID>/sapreorg/exportbug.dmp full=y indexes=y grants=y log=/tmp/exportbug.log
Note: wait for the prompt and enter the below values. . mode (2) U(sers) . export grants yes . export table data yes . compress extents yes
For eMerge (for GSAP) - Export all data info from eMerge instance su ? ora<sid> exp emereq/<See WARP> file=/oracle/<SID>/sapreorg/exporteme.dmp full=y indexes=y grants=y log=/tmp/exporteme.log
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> 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
| Page 17/65 |

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.
Select the Display All BIA Indexes button or select (F6)
| Page 18/65 |

Take a screen shot of these indexes and copy into a word document and save the document. Screenshot:
2.13
Logon Group Names (SMLG and RZ12)
Logon group names are used in projects to accomplish logon load balancing. These logon groups are used in the SAP logon pad to automatically assign users to application servers based on currently application server usage. The spelling of the logon groups are important because the names in the logon pad must match exactly with what is configured in the system. Therefore, it is important to note the SAP logon group names in the target system prior to performing the database copy, because after the copy, the logon group definitions will reflect those of the source system. To retrieve the logon group name(s): - For Target system logon in SAP client, where you have enough authorizations Execute transaction SMLG
- The logon group name(s) will be displayed on the screen. Save a copy of the screen or write down the logon groups. Logon group names are also case-sensitive. RFC server groups are, amongst other things, used for parallel client copies. These RFC server groups must be restored to their current configuration after the refresh. - 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 - 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
| Page 19/65 |

2.15
Check and Save Logical System Definition
Execute SCC4, and double click on all clients. If the field Logical System is not blank, document the name with each client.
2.16
Preserve DB13 entries
As the DB13 tables will be cleared due to the refresh, the entries of the DBA Planning Calendar must be saved. Proceed as follows: - Goto DB13 on the target system. - Make a hardcopy of the screen and/or save it in notepad.
2.17
SAP License Snapshot
The Source <SID> and Target <SID> may have different list of SAP Licenses loaded in the system. After a successful database copy the SAP Licenses in the Target <SID> will be replaced with those in the Source <SID>. Therefore, it is important to take a snapshot of the SAP Licenses in the Target <SID>. Proceed as follows: - Log on to the target system at UNIX as <sid>adm - saplicense ?show > saplicense_<Target_SID>.save
- Make note of the absolute_path/filename (saplicense.save) for use in the Post Copy Steps, should be in /local/users/<sid>adm
2.18
Determine SAP version
This step is important in order to follow these instructions as they are version dependent. - Log on to SAP with your personal id - Enter ?STAT in the transaction field at the top left corner of the screen and press enter. - A pop-up screen appears, the version of SAP is listed in the field named SAP Release (or BasisRelease). - Click red X to exit pop-up.x
| Page 20/65 |

- SAP RELEASE: ____________________
2.19
Preserve TXCOM table entries

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

Procedure to Refresh Database from the online/offline Backup
Disable crontab for root on target system

Disable 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)
| Page 21/65 |

<upgrade_server> # crontab ?r
Actions on Target System

Bring down all the applications of SAP( for ex:: Patrol, ControlM agent, CCMSR etc)
Bring down the J2ee Engine Access transaction SMICM
Perform the following path: Administration > J2EE Server > Send Hard Shutdown > Without Restart Bring down SAP and clean up the system
- su - <sid>adm
- stopsap - saposcol ?k
- su ? ora<sid> - lsnrctl stop - cd /oracle/<SID> - rm ?r sapdata* - cd /oracle/<SID>/saparch - rm *
| Page 22/65 |

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 systemroot>cd /oracle/<SID>/sapbackup root>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))
| Page 23/65 |

root> chown ora<target sid>:dba *.anf (or .aff file for standby (if applicable))
- 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 root> chown ora<target sid>:dba init<source sid>.utl 3. root > vi init<source sid>.utl Change CONFIG_FILE parameter as :CONFIG_FILE /oracle/<target sid>/dbs/init<source sid>.bki
- SCP init<sid>.utl file from source to target. - Change the permissions and ownership of init<source sid>.utl - Edit init<source sid>.utl . We need to change Config_file parameter. This is needed to start the restore.
1. On Source system ; root> cd /oracle/<sid>/dbs
| Page 24/65 |

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
- SCP init<source sid>.bki from source to target - Change permissions & ownership of init<source sid>.bki
On source system 1. ora<sid> sqlplus ?/ as sysdba? sqlplus > alter database backup controlfile to trace; sqlplus > exit - scp this file created in /oracle/<SID>/saptrace/usertrace to the target system /oracle /<SID> - scp <trace file> target system: /oracle /<SID>/createcontrol.sql - On Target system root>cd /oracle /<SID> root> chmod g+r createcontrol.sql root> chown ora<target sid>:dba createcontrol.sql
- To create the trace file. - Scp the trace file to the target system. - Change the permission/ownership of trace file.
Editing the tracefile on target system - root> vi <trace file>
| Page 25/65 |

- The file has been created double, remove the first file - Remove all the starting lines of tracefile until STARTUP NOMOUNT 3. Edit the 2nd line ? CREATE CONTROLFILE REUSE DATABASE "SOURCE SID" NORESETLOGS ARCHIVELOG to CREATE CONTROLFILE SET DATABASE ?TARGET SID? RESETLOGS NOARCHIVELOG - Remove also all the 2 lines, at the bottom of the tracefile ? #RECOVER DATABASE
#ALTER DATABASE OPEN RESETLOGS; - Change all source sid to target sid. This can be done by using vi command ? :1,$s/<source sid>/<target sid>/g
- To go into vi mode - To remove all the unwanted lines. All the lines are to be removed until STARTUP NOMOUNT, beginning from first line. Edit the 2nd line as said. - Comment the 3 lines, which is present at the bottom of the tracefile. We do this manually later. - This is an easy command to change all the sid of source system to the sid of target system.
Note :Make sure no new datafile has being added after the backup that is being used. Check by table V$datafile. If yes, edit the trace file(remove the datafile entry that are entered after the backup that if used)
At the end of the tracefile on the BW system you will also find some comments about the TEMP files. For now you need to delete these entries but save them somewhere else, because later you will need them again. Example: ALTER TABLESPACE PSAPTEMP ADD TEMPFILE '/oracle/PC6/sapdata6/temp_4/temp.data4' SIZE 1999M REUSE AUTOEXTEND OFF; ALTER TABLESPACE PSAPTEMP ADD TEMPFILE '/oracle/PC6/sapdata6/temp_3/temp.data3'
| Page 26/65 |

SIZE 1999M REUSE AUTOEXTEND OFF; ALTER TABLESPACE PSAPTEMP ADD TEMPFILE '/oracle/PC6/sapdata6/temp_2/temp.data2' SIZE 1999M REUSE AUTOEXTEND OFF; ALTER TABLESPACE PSAPTEMP ADD TEMPFILE '/oracle/PC6/sapdata6/temp_1/temp.data1' SIZE 1999M REUSE AUTOEXTEND OFF;
Restore database from Storage

Start restore on targetsystem in the foreground with: - su ? ora<sid> - for normal restore: brrestore -r init<source sid>.utl -b <backupfile> -m full ?c - for standby restore: brrestore -r init<source sid>.utl -b <backupfile> -m all ?c
or Start restore in the background with: - as root - at now su ? ora<sid> -c ?brrestore -r init<source sid>.utl -b <backupfile>-m full ?c force? D for standby: su ? ora<sid> -c ?brrestore -r init<source sid>.utl -b <backupfile>-m all ?c force? D After the restore is finished (on target system): - as root - cd /oracle/<SID> - chown ?R ora<sid>:dba sapdata*
Rename the database
| Page 27/65 |

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

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

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

Checking the database

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

We need some additional action for BW. Recreation of the tempfiles which you saved at step Error! Reference source not found.
Example for 4 data files in sapdata6:
ALTER TABLESPACE PSAPTEMP 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>/sapdata6 mkdir temp_1 mkdir temp_2 mkdir temp_3 mkdir temp_4
| Page 29/65 |

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

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

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

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

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

The Oracle Listener should also be started Orasid> lsnrctl start
| Page 31/65 |

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

- Log on to the source (or standby database) system?s as ora<sid> - sqlplus ?/ as sysdba? - alter database backup controlfile to trace; - quit.
| Page 32/65 |

- cd /oracle/<sourceSID>/saptrace/usertrace - ls ?altr - Write down the name of the trace file created (we will refer to it as <tracefile>)
Stop Target SAP and Oracle

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

Caution: Be careful with following commands! Look twice before pressing enter. You don?t want to remove datafiles belonging to another SID (like the standby database?)
- Logon to the target system as root - cd /oracle/<targetSID> - rm ?r sapdata*/* - cd /oracle/<targetSID>/cntrl - rm *.dbf - cd /oracle/<targetSID>/saparch - rm *.dbf
Stop the hotstandby database

- Logon to the hotstandby system as ora<hotstandbysid> - sqlplus ?/ as sysdba? - shutdown immediate;
Copy the database from hotstandby

Note: If the target system is not on the same server as the hotstandby, make sure that /.rhosts file in the target system contains a row like: <hotstandby system> root
| Page 33/65 |

If not, please add this line and don?t forget to remove it when the procedure is completed. Please ensure that the number of sapdata* filesystems for the target SID matches the number of sapdata filesystems for the hotstandby SID?both in number and in size to ensure there is sufficient capacity for the copy process. When performing the steps below, it may be wise to copy and paste, line for line, from the document into the UNIX terminal window because it may be difficult to identify whether you are using the proper character , number, or letter in some cases.
On MC-II systems, the conccurent io (cio) option is turned on on the sapdata and origlog/mirrlog filessytems. As such, to prevent a very slow refresh from the hot-standby system, the cio option needs to be switched off because otherwise the "cp" command will be extremely slow.
Therefore, if the hotstandby system is on MC-II platform, stop the SAP instances running on the hotstandby and target systems if this is not done yet in the previous steps and run the following commands as root to disable the cio option. Not that if both the hotstandby and target systems are on MC-1 platforms, please skip this step and proceed with the next step.
lsfs | grep sapdata | while read lv a fs rest do chfs -a options=rw,nodev,nosuid $fs umount $fs mount $fs done If the target system is not on the same server as the hotstandby Logon to the hotstandby system as root and run the following command:at now for i in `df -Ik |grep sapdata |grep <hotstandbySID> | sed 's/.*sapdata([0-9]*)$/1/' ` do echo $(date): ?Copying /oracle/<hotstandbySID>/sapdata${i} filesystem?? scp ?p ?r /oracle/<hotstandbySID>/sapdata${i}/* <target_server>:/oracle/<targetSID>/sapdata${i} & done | tee -a /tmp/hotstandby_copy.$(date +%Y%m%d%H%M%S).log D
| Page 34/65 |

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

Logon to the target system as root - cd /oracle/<targetSID> - chown ?R ora<targetsid>:dba sapdata*
Edit the trace file on target system
| Page 35/65 |

Use an editor (like vi) to change /tmp/<tracefile>. Perform the following changes: Remove all the starting lines of tracefile until the STARTUP NOMOUNT that precedes the command: CREATE CONTROLFILE REUSE DATABASE <SID> RESETLOGS. Note: With ORACLE 9 the trace file will appear to have duplicate data. The only difference is that it has two stanzas, one with NORESETLOGS and one with RESETLOGS. You want the last one. Change all source sid to target sid. This can be done by using vi command :1,$s/<sourse sid>/<target sid>/g Change the 2nd line from CREATE CONTROLFILE REUSE DATABASE <SID> RESETLOGS NOARCHIVELOG to CREATE CONTROLFILE SET DATABASE <SID> RESETLOGS NOARCHIVELOG Comment all lines below and including the following 3 lines, at the bottom of the tracefile. #RECOVER DATABASE #ALTER SYSTEM ARCHIVE LOG ALL; #ALTER DATABASE OPEN; Make sure to comment and make note of any statements at the bottom that have the key word TEMPFILE like the following. You will need to manually execute these statements later. #ALTER TABLESPACE PSAPPAT1I ADD TEMPFILE '/oracle/SID/sapdata4/pat1i_1/pat1i.data1' SIZE 52420608 REUSE AUTOEXTEND OFF; Save the file and exit vi.
Create controlfile and open the database
Open another session and tail the alert log: - Logon to the target system as ora<sid> - tail ?f /oracle/<targetSID>/saptrace/background/alert_<targetSID>.log - In your initial session: - Logon to the target system as ora<sid> - sqlplus ?/ as sysdba? - @/tmp/<tracefile>
| Page 36/65 |

- recover database using backup controlfile until cancel;
Cancel this immediately. You don?t really have to apply logs. (NOTE: If an on-line backup was used, the required redo logs must be applied to the database). - alter database open resetlogs; Execute all the ? ALTER Tablespace <xxxx> ADD TEMPFILE ?..? statements from step 0. You can open another window and cut-paste the statements into the sqlplus program. Make sure they execute successfully.
Caution: Keep an eye on the alert log, as eventual errors can end up in a RUNNING but inconsistent database!
Restart the Standby database

- Logon to the hotstandby system as ora<sid> - sqlplus ?/ as sysdba? - startup nomount; - alter database mount standby database exclusive; - exit -
Restart the database

If the target database is supposed to run in ARCHIVELOG MODE, you have to activate it. - Logon to the target system as ora<sid> - sqlplus ?/ as sysdba? - shutdown immediate - startup mount - Following line ONLY if you have to run in ARCHIVELOG MODE: - alter database archivelog; - Following line ALWAYS: - alter database open; The following step ?Start Oracle listener? is only needed if the database is restored from standby.
Start Oracle Listener

Start the listener if it?s not already running: - Logon to the target system as ora<sid> - lsnrctl start
Note: DO NOT START SAP HERE YET.
| Page 37/65 |

Create OPS$<SID>ADM user and grant sapdba role to

First start Oracle (if not already started):
Logon to the target system as ora<sid>
lsnrctl start sqlplus internal startup exit
Go to /sapmnt/<SID>/exe and run CHDBPASS.817 or CHDBPASS.102 (Select option a,c and d)
Note: if The CHDBPASS.817 file is not available. Therefore, the commands to create the OPS$<SID>ADM account must be run manually. Perform the following steps:
Logon to the target system as ora<sid>
sqlplus ?/ as sysdba? drop user ops$ora<SID> cascade; create user ops$ora<SID> identified externally default tablespace psapuser1d temporary tablespace psaptemp;
| Page 38/65 |

grant dba,connect,resource to ops$ora<SID>; drop user ops$<SID>adm cascade; create user ops$<SID>adm identified externally default tablespace psapuser1d temporary tablespace psaptemp; grant dba,connect,resource to ops$<SID>adm; create table ops$<SSID>adm.sapuser as select * from ops$<TSID>adm.sapuser; exit
Also the passwords for sapr3, sys, and system must be set. Run the following commands:
| Page 39/65 |

Find current passwords from warp ; Logon to the target system as ora<sid>
connect / as sysdba; alter user system identified by passwd; alter user sapr3 identified by passwd; alter user sys identified by passwd; update ops$sidadm.sapuser set passwd = 'passwd'; commit; exit
Check for connectivity to the database with the following command as <sid>adm: R3trans -d
Post-Copy Steps
4.1 Removing hostname entries

Remove the entries added during presteps . DON?T JUST COMMENT the line, completely remove it.
| Page 40/65 |

Log on to the target system as root vi /.shosts remove entry: <sourceservername> root remove entry: <targetservername> root
Log on to the source system as root (Noted : Not applicable for hot-standby machine) vi /.shosts remove entry: <targetservername> root
4.2 Fix GLOBAL_NAME parameter in Oracle

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

After database copy, the SYS and SYTEM passwords can become inconsistent with the encrypted password in , which could cause
| Page 41/65 |

database backup to fail. (find the current SYS/SYSTEM password from warp) su ? orasid sqlplus ?/ as sysdba? SQL> alter user sys identified by password; SQL> alter user system identified by password;
4.4 Fix SAP License Key

After a successful database copy, the SAP license key database will reflect only the key(s) that were in the source system. In order for users to be able to log into the target system, the appropriate license key has to be installed. Some projects install all of their project license keys in all systems so that this step can be eliminated. If the license key is not installed, proceed as follows:
Logon to the target system as <sid>adm
- cat saplicense.save
- saplicense ?install Answer all questions with values provided by saplicense.save
Note: For NW07 systems with digitally-signed licenses e.g. Gchem CRM, this will not work.
In the SAP menu choose Administration Administration SAP Licenses or call transaction SLICENSE. - Click New Licenses - Delete the license from the source system - 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
| Page 42/65 |

removed when the DB is replaced during a refresh. - Use this command to remove the files and directories : rm -r /sapmnt/SID/global/*
4.6 Start SAP for the first time

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

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

Re-enable root?s cron (make sure that the same file saved earlier during the step 0 pre-work is loaded ? it should have been saved and restored to /local/etc/sapadm as part of the procedures): May need to replace the date format with the actual date the backup was made-)
| Page 43/65 |

# crontab /local/etc/sapadm/root.crontab.`date +?%d%m%Y?`
4.9 Transport System Configuration

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

After a successful database copy, the spool requests listed in the Target <SID> will reflect those of the Source <SID>. Therefore, all spool requests need to be deleted from the Target <SID>. Proceed as follows:
Logon to the target SAP - Run transaction SE38. - Enter RSPO1041(RSPO0041 for 3.1I) in the program field, and click execute. - Enter the values like the following screen
- Select menu item Program => Execute in background - A printer destination screen appears, enter LP01 as printer name, and uncheck Print immediately. - Click green check, and the job will begin in a batch process, run immediately.
| Page 44/65 |

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. - 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
| Page 45/65 |

- Check each of the new op modes for correctness. In the Pre Copy Steps, a snapshot of the Target <SID> Op-modes was taken and downloaded to a directory/filename on the local PC. Verify the Op-modes with this hardcopy listing. - Click the SAVE button.
4.15 Delete Server Specific Performance Data

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

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

Output as PDF file has been powered by [ Universal Post Manager ] plugin from www.ProfProjects.com | Page 46/65 |

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 : - Login to SAP client 002 - SPAD - Click the Change button - Select Utilities, For Output Devices, Delete All - Ignore any errors/warnings Logon to the target system as <sid>adm - cd /usr/sap/trans/bin - tp addtobuffer <Transport Number> <SID> - tp import <Transport Number> <SID> client<client_number> U128
Local file : - Log on to one of the SAP target system client 002 (or proper one for BW) with personal id. - SPAD - Click on Change Icon - Click Output Devices - Click on the line of one of the printers - In menu, go to Edit --> Transfer --> import - Export/Import file name : Fillin the destination of your C -drive where you saved the file of the printers in step 2.15.
| Page 47/65 |

- example : c:/apps/reserveprintersSID.txt - Select Frontend computer 10. Select Import 11. Select Execute import and Generate log 12. For Output device : Fillin * 13. Click on execute
4.20 Import User Master Records

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

- Logon to the target SAP in client 002 - Execute transaction SCC4 - Change the category to ?Test? for the client that you just imported the user masters into - Change the Client Protection to Level 0 - Hit Save button - Repeat this step for each client that the user import was performed
4.22
Perform client import post processing
(All R3 systems) Steps Prior to Execution of SCC7

In all R3 systems, before executing scc7, determine the storage quality of the table. If the storage quality is less than 70%, we should re-build the index. This will speedup the scc7 run considerably. For determining the storage quality of the imported user master: v Logon to Production client v Go to ->tcode db02
| Page 48/65 |

v Click on Detailed Analysis v Type USRBF2 as object name; this is the table for User buffer content for fast RFC logon v Click Table ->Indexes ; the table name and the index are displayed v Place the cursor on the index(USRBF2~0) and click on Detailed Analysis button v Check the storage quality; select Analyis Index->Storage quality from the menu v If Storage quality is less than 70%, we have to rebuild index v For rebuilding indexes, go to Alter index->rebuild v 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. - 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.
Part 2 ? Reset User buffers

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.
| Page 49/65 |

?No changes to Repository and cross-client customizing objects? are selected.
4.24 Restore data for RFC, ITS, SAPconnect, SSO, HTTP(S), SCOT and Logical Printer Server tables
After a successful database copy, the RFC destinations in the target system will have values reflecting the source system. This needs to be changed to reflect the target system. In this case you have already a transport available containing RFC tables and/or the exported dump file for the ?application? and/or ?temporary? tables.
Transport : Logon to the target SAP - Run STMS - Overview -> Imports - Double click the Target system SID name - Use menu option Extra -> Other Requests -> Add - Enter the transport number from RFC Export done in Pre steps - Highlight the transport from the list and hit the transport button.
Exported dump file : Import the exported dump file of the ?application? and/or ?temporary? tables : <tablename> <tablename> To save copy of the refreshed tables: - su ? ora<sid> - sqlplus /nolog - connect <SAP tables schema>/password> {e.g. connect sappe8/m0tor} Example tables :
create table ZTBD00 as select * from TBD00
create table ZTBD05 as select * from
| Page 50/65 |

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

- 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).
| Page 52/65 |

- Select the Object type Table. - Press the Edit button. - Select radio-button delete data, Process type should be Direct. - NOTE!!! DO NOT PRESS THE DELETE DB TABLE HERE!!! - Press activate and adjust database. Repeat steps 2-6 for each of the tables listed above. 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. 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.28 Changing The Source Server To Target Server Name For SAPCOMM 4.29 Restore TXCOM table entries 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. 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. Logon to UNIX on the application server as < sid>adm account. Execute the Unix command startsap to start the SAP application instance. 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. - Start transaction SM61 - Goto Object Modify Object.
| Page 53/65 |

Click on Cleanup list button. 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. 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 SAVEbutton. - Logon to the target system - Schedule the Standard Jobs which were running earlier
4.31 Re-cycle SAP 4.32 Start SAP on all application servers (if applicable) 4.33 Check background processing 4.34 Clear Background Objects 4.35 Import application server Profile Parameter Files 4.36 Add required application servers to the Op Modes 4.37 Reschedule Standard SAP Jobs 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.
| Page 54/65 |

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? drop user SAP<SSID>DB cascade; Continue with create the J2EE schema user. drop tablespace PSAP<SSID>DB including contents and datafiles;
Create the J2EE tablespace using sapdba

During the installation of the J2EE engine, a new tablespace is created in the ABAP stack called PSAP<SID>DB. This tablespace must be recreated after the system has been restored. Perform the following to create the tablespace: su ? ora<sid> sapdba (See the warp file for the system password)
Select c ? Tablespace administration -> a ? Tablespace-> g - Create/drop tablespace
Select b ? New Path. By default the tablespace is created in sapdata1. Type of path of the filesystem that contain more than 1GB of space. In this example, /oracle/SID/sapdata8 was used. Select c ? New Size Type 1024M to create a 1GB tablespace. Select s ? Start to Create the tablespace. Press q to return.
Create the J2EE Schema User (SAP<SID>DB or SAPMIWDB or SAPCRMDB )

As ora<sid> perform the following steps to create the J2EE user. su ? ora<sid>
| Page 55/65 |

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.
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:
| Page 56/65 |

Note: When creating the SAPJSF user, add the SAP_ALL and SAP_NEW in the Profiles tab.
For the J2EE_ADMIN user, enter SAP_J2EE_ADMIN in the role field. The J2EE_ADMIN and J2EE_GUEST users do not have any profile assigned. The following chart contains the roles and profiles for the J2EE ABAP users.
User Roles Profile
J2EE_ADMIN SAP_J2EE_ADMIN None
J2EE_GUEST SAP_J2EE_GUEST None
SAPJSF SAP_BC_JSF_COMMUNICATION SAP_ALL, SAP_NEW
| Page 57/65 |

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 /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
| Page 58/65 |

- Right click on SAP_BW Open Connection Tests
Select all tests and choose Test. The tests must complete successfully.
Note: If there exist a problem in bringing up java after refresh check if user sapjsf in unlocked and correct password of it is maintained in secure store.
4.40 Re-import BugsEye & eMerge data (if applicable)
Re-Import BugsEye data & eMerge data (if applicable) in the following way: Make sure the J2EE processes are stopped! (done for both BugsEye & eMerge) Stop the j2ee processes: Logon to SAP SMICM Administration J2EE Server Send Hard shutdown Without Restart Optional Check processes: ps ?ef | grep jlaunch STEP. Drop user bugreq su ? ora<sid> sqlplus ?/as sysdba? drop user bugreq cascade; commit;
STEP. Create user BUGREQ in SAP EBP system su - ora<sid> sqlplus ?/as sysdba? create user BUGREQ identified by <See WARP> default tablespace PSAPBUGSEYE temporary tablespace PSAPTEMP; grant create session to BUGREQ; grant create table to BUGREQ;
| Page 59/65 |

grant create sequence to BUGREQ; grant unlimited tablespace to BUGREQ; grant create view to BUGREQ; grant create any cluster to BUGREQ; grant create any context to BUGREQ; grant create any index to BUGREQ; grant create any indextype to BUGREQ; grant create any procedure to BUGREQ; grant create synonym to BUGREQ; grant create trigger to BUGREQ; grant CTXAPP to BUGREQ;
STEP. Import all bugseye data info into SAP EBP system su - ora<sid> imp bugreq/<See WARP> file=/oracle/<SID>/sapreorg/exportbug.dmp full=y indexes=y grants=y commit=y log=/tmp/importbug.log
STEP. Test connection Start the J2EE processes: Logon to SAP SMICM Administration J2EE Server Send Hard shutdown With Restart {it can take up to 5 minutes before the homepage is available} Test connection: http://<servername + dns>/requisite/login.htm
For eMerge: Make sure the J2EE processes are stopped again.
| Page 60/65 |

Logon to SAP SMICM Administration J2EE Server Send Hard shutdown Without Restart
STEP. Drop user emereq su ? ora<sid> sqlplus ?/as sysdba? drop user emereq cascade; commit;
STEP. Create user EMEREQ in SAP EBP system su - ora<sid> sqlplus ?/as sysdba? create user EMEREQ identified by <See WARP> default tablespace PSAPEMERGE temporary tablespace PSAPTEMP; grant create session to EMEREQ; grant create table to EMEREQ; grant create sequence to EMEREQ; grant unlimited tablespace to EMEREQ; grant create view to EMEREQ; grant create any cluster to EMEREQ; grant create any context to EMEREQ; grant create any index to EMEREQ; grant create any indextype to EMEREQ; grant create any procedure to EMEREQ; grant create synonym to EMEREQ; grant create trigger to EMEREQ;
| Page 61/65 |

grant CTXAPP to EMEREQ;
STEP. Import all emerge data info into SAP EBP system su - ora<sid> imp emereq/<See WARP> file=/oracle/<SID>/sapreorg/exporteme.dmp full=y indexes=y grants=y commit=y log=/tmp/importbug.log
STEP. Test connection Start the J2EE processes: Logon to SAP SMICM Administration J2EE Server Send Hard shutdown With Restart {it can take up to 5 minutes before the homepage is available} Test connection: http://<servername + dns>/emerge/login.htm
4.41 Run sapdba_role.sql to fix Oracle privileges for OPS$SIDADM The OPS$SIDADM Oracle account must have the privilege of SAPDBA to allow the DBA housekeeping jobs to work properly. You must run the sapdba_role.sql. First you must make sure you have the proper script. On the target server su ? ora<sid> cd /local/bin/sap/dbcopy grep OPS sapdba_role.sql
V_User := 'OPS$' || '&&1' || 'ADM'; V_User := 'OPS$SAPSERVICE' || '&&1';
The results should look like the above
| Page 62/65 |

sqlplus system/<password> @sapdba_role.sql <SID> UNIX sqlplus ?/ as sysdba? select * from dba_role_privs where grantee like ?OPS%?;
The output should look like the following :
GRANTEE
GRANTED_ROLE
ADM DEF
------------------------------ ------------------------------ --- --OPS$D04ADM OPS$D04ADM OPS$D04ADM SAPDBA CONNECT RESOURCE NO YES YES YES YES YES
4.42 SAP INFOCUBE INDEXES REPAIR

Run report SAP_INFOCUBE_INDEXES_REPAIR (Applicable for BW systems on version 3.5 and below)
Some background: BW systems are running with NOLOGGING configured on Oracle level. This means that the creation of indexes are not captured in redologs. While BW drop/recreates indexes quite frequently as part of dataloading, lots of index creations are not in the redologs. When rolling forward a database during a refresh, these indexes will get corrupted blocks. The solution is to drop/recreate these indexes in the refreshed system (switching on LOGGING in the production system is not feasible as performance would go down. NOLOGGING is also the SAP recommendation for BW systems).
In BW system client: SE38 SAP_INFOCUBE_INDEXES_REPAIR Program Execute in background
This can and probably will run for hours. You can however safely continue with the next steps. There is no need to wait for this program to finish. 4.43 Convert logical system names(BDLS RUN)] Old logical system name = <SSID>CLNT<Client number>
| Page 63/65 |

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.
| Page 64/65 |

Click on the Choose button to see the actual output of the BDLS run.
If there persist a problem in BDLS Conversion we can proceed converting them from SQL prompt too.
| Page 65/65 |

Database Procedure

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Database Procedure

Загружено:

Авторское право:

Доступные форматы

This page was exported from - SAP ADMIN

Export date: Thu Feb 23 6:06:21 2012 / +0000 GMT

Database Refresh Procedure

This page was exported from - SAP ADMIN

Pre Copy steps

Verify the passwords in the source and target systems

Check Space in Target System

This page was exported from - SAP ADMIN

df -k | grep sapdata | sort

Additional Checks for storage inAPO? LCA system

Additional Checks for storage inAPO? LCA system

This page was exported from - SAP ADMIN

Source system(Source SID(SSID))

Target System(Target SID(TSID))

OpenSSH to OpenSSH trust (host based trust)

This page was exported from - SAP ADMIN

Verify Oracle control file directories on target server

Logon to the target system

This page was exported from - SAP ADMIN

This page was exported from - SAP ADMIN

Program ID Object Object Name Table Key Description/Purpose

R3TR TABU RSECTAB * Secure store table client-specific

R3TR TABU RSECACTB * Secure store table cross-client

R3TR TABU RFCATTRIB * Administration table for RFC destinations

R3TR TABU RFCDES * Destination table for Remote Function Call

This page was exported from - SAP ADMIN

R3TR TABU RFCDESSECU * SNC extensions for RFC destinations

R3TR TABU RFCDOC * Description of Possible RFC Connections (->RFCDES)

R3TR TABU RFCTRUST * List of existing trusting systems

R3TR TABU IACORDES * RFC Destinations for IACOR / ITS

R3TR TABU TSPSV * Spool: Server table

This page was exported from - SAP ADMIN

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

This page was exported from - SAP ADMIN

TABU TWPURLSVR * Logical Web Servers for Logical Systems / I

R3TR VDAT V_TBDLS * Logical System Names / IHUB

R3TR TABU SXNODES * SAPconnect: Communication nodes

R3TR TABU SXROUTE * SAPconnect: Routing table

R3TR TABU SXSERV * SAPconnect: Node capabilities

R3TR TABU SXADMINTAB * SAPconnect and SAPphone: Administration

This page was exported from - SAP ADMIN

SXDOMAINS * SAPconnect: Management of Internet Mail Addresses Domains

R3TR TABU SOPR * SAPoffice: System-wide profile (default domain)

R3TR TABU SXADDRTYPE * SAPconnect: Address types

R3TR TABU SXCONVERT * SAPconnect: Conversion functions

R3TR TABU SXCONVERT2 * SAPconnect: Conversion Functions for Forma

R3TR TABU SXCOS * SAPconnect: Send attribute classes

R3TR TABU SXCOS_T * SAPconnect: Text table for send classes

R3TR TABU SXDEVTYPE

This page was exported from - SAP ADMIN

* SAPconnect: Device Types for Format Conver

R3TR TABU SXFORMATG * SAPconnect: Format groups

R3TR TABU SXJOBS * SAPconnect: Send Jobs

R3TR TABU SXRETRY * SAPconnect: Disruptions in RFC connections

R3TR TABU SXRFC * SAPconnect: Assignment of RFC address to n

R3TR TABU SXTELMOIN * SAPconnect: Telephone number modification

R3TR TABU SXTELMOOUT * SAPconnect: Telephone number modification