Client Copy Authorizations

To copy or transport clients, you need the appropriate authorizations. There are two types of authorizations: general authorizations for client copy, and special authorizations that depend on what you want to copy.

The nitial user SAP* has all authorizations required, except authorization to create a transport request. It can be used for all client copy tools except the client export (SCC8).

General authorization objects for Client Copy

Authorization objects	Action
S_TABU_CLI	Maintain cross-client tables
S_TABU_DIS	Maintain system tables
S_CLNT_IMP	Import data in client copy
S_DATASET	Access the file system

Copy User Profiles and User Master Records

Authorization objects	Action
S_USER_AGR	Copy roles
S_USER_PRO	Copy authorization profiles
S_USER_GRP	Copy user master records

Transport Clients

You also need the following authorizations to transport clients:

Authorization object	Action
S_CTS_ADMI with · TTYPE 'CLCP' · ACTVT '01'	Create object lists for client transport and copy into another client

Remote Copy (authorization required for RFC user in source client)

Authorization	Action
S_TABU_RFC	Remote access to tables in target system

Restarting Client Copy

If a copy terminates for technical reasons, for example, due to a database shutdown, you can restart the process from the point of termination.

• if a client copy or client import postprocessing did not finish, the system automatically proposes restart mode when you call the transaction. The same parameter settings are used automantically.

The last step is restarted. You cannot continue to copy an incompletely copied table, the table is reinitialized and recopied.

• If the restart fails, the log displays possible reasons for the error. Before you try to restart the program again, eliminate the error.

Client Copy Data Types

The client copy can copy the following components of the source client into the target client:

· User master data: User master data is only deleted in the target system if a profile with user master data is copied. Authorization profiles and roles belong to customizing and are therefore always copied with it. Copying users without authorization profiles is problematic. The copy profile SAP_USER therefore contains additional authorization profiles and roles.

· Customizing: All profiles except SAP_USER contain customizing. Customizing data is generally in tables with delivery classes C, G, E and S.

· Cross-client customizing: Choose a profile with this data type for example when you want to create a test system which is analogous to the production system, and no system copy is to be made.

Inconsistencies can arise in the target system after transporting cross-client tables. Cross-client customizing can only be used to create a new system because existing clients can be corrupted by changes in their context.

Scenario 1: You have just installed the target system. The first step in setting up a client is to import a client from another system. Since there are no other clients in the system yet, you can also copy the cross-client customizing settings to ensure that they remain consistent, including those pointing to cross-client objects.

Scenario 2: You have setup clients in the target system whose data must be retained. Cross-client data must not be imported into the system. This data would overwrite the existing data, and the customizing of the other clients in the target system would no longer be consistent. Only the data in the new client would be consistent. This is why you should not transport cross-client data. The data in the other clients of the target system is then still usable, and only the new client needs some postprocessing to reconcile the client-specific Customizing data copied with the cross-client Customizing data of the target system.

· Master/transaction (application) data: select this option, for example, if you want to set up a test system from the production client.

Application data depends on customizing data, so it can only exist consistently together with it. Application data is therefore always deleted from the target client, exception for copies with SAP_USER. Application data is generally in tables with delivery class A.

The amount of data and thus the memory required and copy time for productive clients can be considerable. In this case you should not copy application data, you should create the required test data e.g. with CATTs (Computer Aided Test Tool).

Client Copy Profile

You can use copy profiles that make it easier for you to select and combine the components you want to copy. SAP delivers the following copy profiles in the table below. The customizing and application data is deleted in the target client before copying for all profiles except SAP_USER. This is technically unavoidable.

Copy profile overview (general)

Copy profile	Description
SAP_USER	Users, user roles and authorization profiles are copied. The client is not reset.
SAP_UONL	User without authorization profile and role
SAP_PROF	Only authorization profile and roles
SAP_CUST	Client-specific customizing including authorization profile is copied. The application data is deleted, the user data is retained.
SAP_CUSV	SAP_CUST with variants
SAP_UCUS	SAP_CUST with user master data
SAP_UCSV	SAP_UCUS with variants
SAP_ALL	All client data except change documents (see note 180949) and local data is copied.
SAP_APPL	SAP_ALL without user master data
SAP_AAPX	SAP_ALL without authorization profile and roles

Additional copy profiles for client transports (SSC8 with cross-client customizing)

Copy profile	Description
SAP_EXBC	SAP_UCSV with cross-client customizing
SAP_EXPA	SAP_ALL with cross-client customizing
SAP_EXPC	SAP_CUSV with cross-client customizing

Additional copy profiles for remote copies (SCC9)

Since Basis Release 6.10, the following profiles exist. They correspond to the SAP_EX profiles. These profiles are only available in systems with no protected clients. You can see the existing clients and their settings with the transaction SCC4.

Copy profile	Description
SAP_RMBC	SAP_UCSV with cross-client customizing
SAP_RMPA	SAP_ALL with cross-client customizing
SAP_RMPC	SAP_CUSV with cross-client customizing

Special profiles (SCC8 & SCC9 only)

SAP_RECO

This profile is only for recovering an accidentally deleted client (see note 31496). It contains local tables of delivery classes L and W and the change documents, as well as SAP_ALL.

Clint Copy Profiles

You can use copy profiles that make it easier for you to select and combine the components you want to copy. SAP delivers the following copy profiles in the table below. The customizing and application data is deleted in the target client before copying for all profiles except SAP_USER. This is technically unavoidable.

Copy profile overview (general)

Copy profile	Description
SAP_USER	Users, user roles and authorization profiles are copied. The client is not reset.
SAP_UONL	User without authorization profile and role
SAP_PROF	Only authorization profile and roles
SAP_CUST	Client-specific customizing including authorization profile is copied. The application data is deleted, the user data is retained.
SAP_CUSV	SAP_CUST with variants
SAP_UCUS	SAP_CUST with user master data
SAP_UCSV	SAP_UCUS with variants
SAP_ALL	All client data except change documents (see note 180949) and local data is copied.
SAP_APPL	SAP_ALL without user master data
SAP_AAPX	SAP_ALL without authorization profile and roles

Additional copy profiles for client transports (SSC8 with cross-client customizing)

Copy profile	Description
SAP_EXBC	SAP_UCSV with cross-client customizing
SAP_EXPA	SAP_ALL with cross-client customizing
SAP_EXPC	SAP_CUSV with cross-client customizing

Additional copy profiles for remote copies (SCC9)

Since Basis Release 6.10, the following profiles exist. They correspond to the SAP_EX profiles. These profiles are only available in systems with no protected clients. You can see the existing clients and their settings with the transaction SCC4.

Copy profile	Description
SAP_RMBC	SAP_UCSV with cross-client customizing
SAP_RMPA	SAP_ALL with cross-client customizing
SAP_RMPC	SAP_CUSV with cross-client customizing

Special profiles (SCC8 & SCC9 only)

SAP_RECO

This profile is only for recovering an accidentally deleted client (see note 31496). It contains local tables of delivery classes L and W and the change documents, as well as SAP_ALL.

How to perform a client copy when CUA is active

The general procedure is to delete the CUA before performing any client copies/system copies within a CUA landscape.

This is not necessary in every case. Here is a suggestion, of how to proceed. Please don't count on any support by SAP if you proceed like suggested. You do this on your own risk.

Scenario:

Copy one client of a CUA child system to another client within the CUA landscape (CUA child) keeping the original users in the target of the copy.

In this example PRD is the source and SBX the target of the copy.

1) Clean up any (userclone) IDOC's related to SBX or PRD.

2) Delete both DEV and SBX from the central CUA system, using

RSDELCUA in PRD, SBX and in the CUA central system.

3) Backup PRD

4) Export user and authorizations from SBX clients by means of a client

export transport.

5) Restore PRD backup to SBX and do all the post steps for renaming,

etc. (especially BDLS!!!)

6) Import the users and authorizations from the client export (step 2).

7) Check any RFC's or logical systems that are required for CUA.

RFC destinations should be available, but better check.

Logical system names should have been adapted using BDLS in step 5.

8) Execute SCUA on the central CUA system to add DEV and SBX back

into the landscape.

9) Execute SCUG to transfer the users back into the central CUA system

Please see notes 197728 and 565697 on RSDELCUA, and notes

544509, 121163, 369758 and 446294 concerning BDLS and

399917.

Steps in detail:

Source: PRD-System

Target: SBX-System

You will find some points like ‚disconnect RFC'. With this the technical disconnection regarding RFC is meant.

To assure data consistency, you have to take care, that during the actions _No_ changes in the CUA central system regarding the CUA itself or users are performed. It is a good idea to lock SU01 and SU10 for that time.....

Another precondition is, that both systems are on the same basis support package level. (note 449822)

Let's start:

1) execute Reports RSADRCK1 & RSADRCK2 (first in test mode) to identify any existing address problems and clean them up (note 94104)

2) in the CUA central system: assign a special user group to all users of the SBX for later identification (SU10), for instance SBX100 for users of The system SBX client 100. The group can be defined in TX SUGR. Check SCUL - make sure, that all Users (Idocs) have a 'confirmed' status.

3) Export Users with Tx SCC8 and Profile "SAP_USER" from SBX (roles are exported too)

4) disconnect RFC of CUA central system (from now on no actions in the CUA central system! If possible, disconnect RFC by means of hardware disconnect)

5) Perform system copy from PRD to SBX

6) disconnect RFC for SBX

7) delete CUA completely in SBX (all clients!) with report "RSDELCUA" (!Not in the CUA central system!) (note 565697 - SE38)

8) Reimport Users and roles of the User export in SBX with TMS and perform post Steps in SCC7

9) adapt rfc-connections in Tx SM59 in SBX and CUA central system

10) Execute Tx BDLS (possibly in all clients of SBX) (Remark: for the CUA only the entry in table T000 is important.) (note #369758)

11) delete the ALE model for CUA in all clients of SBX (Tx BD64) (this step may not be necessary if the model itself is not changed (=same CUA landscape))

12) reconnect RFC in SBX and CUA central system

14) redistribute the CUA model from the central system ( Tx SCUA ->edit -> save)

15) in CUA central system: SCUM -> change any setting (it does not matter which one) and save. Undo your change and save again . Only upon a change the data is synchronized to child systems.

16) select all users with SU10 based on the usergroup assigned before (SBX100); Assign or delete a non existing role to that users for SBX. A popup will appear, that the role does not exist. Now press 'cancel'. The users will get distributed now.

Now your CUA should work again.

Good luck.

Copy a Client into a Stand Alone System

How to copy a client into a stand alone system?

The scenario is I have a 2 system landscape. I want to copy an existing client from DEV to a standalone system for some demo purposes.

There is an option for Client TRANSPORT which will help you perhaps:

A client transport differs from a remote client copy in that it does not use RFC. Like a remote client copy, however, a client transport is used to copy data between different R/3 Systems.

A client transport consists of two steps. First, a client export extracts client data from the source client to files at the operating system level. Second, the data is imported from the operating systemfiles into the target client.

To perform a client export, proceed as follows:

Log on to the source client. From the R/3 initial screen, choose:

*Tools *(r) *Administration *(r) *Administration *(r) *Client Admin. *(r) *Client Transport*(r) *Client Export*. Select the data to be copied using a profile.

Indicate the target system to which the client will be copied. (The target system must be defined in TMS as part of the transport domain.)

Begin the client export. As copying is a lengthy process, use scheduled background processing. The client export performed in the source system , exports the client data asynchronously bycalling the transport program tp at the operating system level. This export process will generate up to

3 data files at operating system level:

. RT<>; this file contains client-specific data

. RO<>; this file contains Cross-client data

. RX<>; this file contains SAPscript texts

Depending on the type of data selected through the client transport profile, the client copy command

files added to the buffer of the target system are

KO; this file is for cross-client data

KT; this file is for client-specific data

KX; this file is also for client-specific data

The client export change requests are not imported when an Import all takes place. Therefore, you must import these requests into the target client using TMS. You must import the data in the following order: first cross-client data, then client- specific data.

After the import process has completed, post-import activities are required possible for object generation steps. After completing the import, log on to the target client. From the R/3 initial screen, choose:
*Tools *(r) *Administration *(r) *Administration *(r) *Client Admin. *(r) *Client Transport *(r) *ImportEditing*

To display client transport logs, use the Transport Organizer.During client transport, a Repository consistency check can be performed by clicking the RFC system check button in Transaction SCC8. If inconsistencies are detected, a list of the ABAP Dictionary tables definitions missing in the target system is generated. This will help your recognize in advance formal problems that may occur during the import of the source data.

Steps For SAP Client Copy / System Refresh

Before doing a client copy, you need to prepare the following :-

1. Find the source client space with the client size custom program which can be implemented using the rel. note:
Find the space of the client - '0118823'. This will give you the size of the source client.

2. If your are on Unix OS, adjust all the file systems according to PRD file system to fit the PRD client in DEV
client based on space requirements also.

3. You can do the client copy by remote or export/import client.
Remote method is not preferred if you are doing a large client copy.
Do a client export/import.

4. To speed up the export/import, use R3trans export/import for the clustered tables.
Please find the rel. notes related to performance improvements for cluster tables in OSS.

5. Do import and post processing.
Note: Export may take 10 to 20 hr. for 50gb of data
import may take 4 days and post import will take 8 to 15 hr. for 50gb of data. And it all depends on
your system performance.

Please refer OSS rel. notes for the few RZ10 parameters which needs to be set for cluster tables to speed up the process.

Note :-

If it is a fresh installation, do this --

1. SCC4 --> Create client no. and fill other details.
2. Logon to the newly created client with SAP* and PASS as password.
3. SCCL --> choose any profile (preferably SAP_ALL), source client 000 and target client .
4. Preferably do a test run initially to check if it can go well.
5. As a care check space in databases.

What are step and procedure to create a client & to take a client copy from source to target.

By: Kavitha.G

If you are copying from same system then flow the below steps:

1. Create the client in Tcode scc4.
2. Before that create a logical System in BD54.
3. Login in the newly created client with
user Name : sap* and password : pass
4. Use the Tcode sccl to copy the client.if you are not familiar with the client copy. Try a test run and then schedule it in background.
5. You can select the needed profile.
6. To view the log files use the tcode scc3.

If you are using different system then create a rfc connection in sm59.test the connection and then continue from the 1st step
You can also import and export a client. Use scc7 for importing from the client and scc8 fro exporting from the source client

What is system refresh when and why it is done?

The system refersh is nothing but the deletion of the client and replacing the data from other client. For example : you have clients 100, 200 and 300. Suppose when you want to refresh the client 100 you remove the client 100 and replace it with 200 0r 300 as per your reqiurement. Mostly the refresh of clients will be happen at the time of development stage.

System Refresh is a simplified term to Client Copy. Client Copy means copying the production client on to the quality to test the real data. As recommend by SAP this need to carried out every 3 months.

The process to carry out the same is as follows:
1. Create a client on quality system using txn scc4
2. Create a RFC between Production system and Quality System (need to create on quality system)
3. Login to the newly created client using sap* and pass as a password
4. Txn sccl to start the client copy. You can test the client copy by selecting the test run option. (test run will estimate the time taken for the activity).

Client Copy from Production to Quality Server

It depend on system size and available time.
For small system you can do remote client copy.
Another option is to make client export on PRD system, then client import in Quality system.

For the large system is not any other way - just do system copy.
In few words:
make backup, remove Quality system from transport system and from CUA, resore on Quality system, re-create control files - to change the SID( Oracle), startup DB, several post-copy steps.

Here is plan that i follow :

Generally – follow note 147243. The difference in this procedure is that DB Load is not interrupted as is proposed in the note, but I wait for the initial installation to fully complete and then do the next steps.

1. Adjust memory parameters (Oracle, SAP) and page file of source system. If necessary adjust also number of work processes. This step is optional. Most often it is not done, instead of it the adjustments of the profiles are done later in the target system.
2. Trace the control file Control.sql of source system – note 147243
3. Adjust created control file as for the target system – note 147243
4. Create new user with admin rights (put this user in ORA_DBA group)
5. Logon as this user (local/domain) and perform a new installation as per inst. guide
6. Do this only if this is a second SAP instance installed on the same host:
See note 576919 (Ora-12505). Oracle listener is changed during the installation. Adjust listener.ora
- if system fails on DBCONNECTTEST step (can occur if you install more than one instance on the same host), check if environment variable Local is defined. If it is, it should have the correct value for the SID and it must be defined as User variable, not as System variable. Also restart the computer. Then start the database of the new SID.
- Terminal services also can impact this error – note 441518. Note 556232 explains the environment settings.
- If error occurs on DIPGNTAB_NT see note 162266 and especially note 400241 (ora-1403 or ora 1017)
7. Patch Oracle of the target system, if necessary (to have the same patch level as in the source system)
8. Update Kernel of Target system (use the newest kernel available)
9. Stop Oracle Service
10. Delete on Target system :\ORACLE\ (Online redo log directories must stay, just the files in them have to be deleted). Redo log directories must be on the same drives as they are on the Source system (because Online Redo logs are recreated by the Control.SQL). Otherwise adjust appropriate the traced control file from the sourse system
11. Copy or restore :\ORACLE\ (SAPDATA 1-6) from Source to the target system.
12. Delete all copied in previous step Control files on the Target system !
13. Copy Oracle init.ora , .sap , .dba from source system and adjust them to the situation in Target system (, paths, etc)
14. Adjust SAP profiles to the status of Target system (memory parameters, number of workprocesses, language parametrs, etc.)
15. Start Oracle Services
16. Modify Control.sql as per Guide (Note 147243)
17. Database must be down. Execute Control.sql . This must recreate the control file and open that database
18. Start DB, Start SAP
19. If the system does not start, delete old OPS$ user and create it again (Note 50088) – only for R/3 4.6C

Only for BW (or system based on WAS 6.20):
- Use note 659509 in combination with 400241. Use the newest oradbusr.sql script to create new OPS$ user– it is attached to current version of note 50088. Change password/owner of SAPUSER table as described in 659509 – use old SID for the “ops$adm.sapuser” and new SID for “SCHEMAOWNER”:
ora% sqlplus /nolog
> connect / as sysdba
> insert into ops$adm.sapuser values
('', '');
- Grant SAPDBA role to new OPS$ user:
GRANT CONNECT, RESOURCE TO “OPS$\ADM”;

In the examples below IPW is the source system, GRB is the target system.

- Give to the user default and temporary tablespace, for example:
ALTER USER "OPS$GRATHDB1\GRBADM" DEFAULT TABLESPACE PSAPIPWUSR
TEMPORARY TABLESPACE PSAPTEMP IDENTIFIED EXTERNALLY;
- Grant the necessary roles to new SAP user, for example:
GRANT CONNECT, RESOURCE, SELECT_CATALOG_ROLE TO SAPGRB;
- Apply note 534765 to change dbs_ora_schema environment to the old SID (SID which owns SAP tables in the schema)
- Create OPS$SAPService user (example):
create user "OPS$GRATHDB1\SAPSERVICEGRB" DEFAULT TABLESPACE SYSTEM
TEMPORARY TABLESPACE SYSTEM IDENTIFIED EXTERNALLY;
- Grant necessary rights to OPS$SAPService user:
GRANT CONNECT, RESOURCE, SAPDBA TO "OPS$GRATHDB1\SAPSERVICEGRB";
- Create the synonym:
CREATE SYNONYM "OPS$GRATHDB1\SAPSERVICEGRB".SAPUSER FOR
"OPS$SAPBW\IPWADM".SAPUSER;
- Grant select update onto the SAPUSER table for SAPService user:
GRANT SELECT, UPDATE ON "OPS$SAPBW\IPWADM".SAPUSER TO "OPS$GRATHDB1\SAPSERVICEGRB”;
- Drop the old synonym:
DROP SYNONYM "OPS$SAPBW\SAPSERVICEIPW".SAPUSER;
- Start SAP system.

20. If the system does not start yet, apply note 8179

21. Post Implementation steps
These steps are derived from Homogeneous copy guide, section “post copy activities”
- Delete all irrelevant in SM59
- Delete old CUA settings, if exists (SCUA, BD64)
- SPAD – adjust printers
- Delete entries in tables:
sqlplus
connect sapr3/sap;
delete from DBSTATHORA;
delete from DBSTAIHORA;
delete from DBSTATIORA;
delete from DBSTATTORA;
delete from MONI;
delete from PAHI;
delete from OSMON;
delete from DBSNP;
delete from SDBAH;
delete from SDBAD;
delete from SDBAP;
delete from SDBAR;
delete from DDLOG;
delete from TPFET;
delete from TPFHT;
delete from TLOCK;
commit;
exit;
For systems based on WAS 6.20 check in Homogeneous Copy Guide for the tables, which entries must be deleted.

- Delete all unnecessary in SM37
- Execute SICK, SM28 (Installation check)
- SE06 (Choose DB Copy)
Start transaction SE06 and choose ‘Database copy or migration’. Click now the button Processing after installation [Execute].
Accept the given source system.
SAP will now ask if the originals have to changed from source system name to target system name. Only answer this question with yes if this installation doesn’t stay within the same landscape.

- SE38 -> execute report RSBTCDEL (mark field delete with force mode). This deletes old batch jobs by your criteria
- SP12 – Tempse Consistency
- Execute DB02
- Configure STMS
- RZ10 – import new profiles
- SE61 – adapt the logon text
- Adapt the picture after logon
- Delete unnecessary clients
- Import necessary requests
- Add the system CUA ?
- Install Documentation

Additional steps for BW only – follow closely note 184754
a) In the target BW, change the contents of field "target host" in all RFC connections (destinations) for R/3 and DataMart source systems (Transaction SM59) to a nonsensical, nonexistent address (such as 'nowhere'). Then delete ALL R/3 and DataMart source systems in the Administrator Workbench source system tree. Caution: This step deletes all PSA tables of these source systems - the data are lost! A message is generated stating that the source system cannot be accessed (since you deleted the host of the RFC connection). Select "Ignore".
Confirm on the request, until all transfer structures are not deleted – track this on “Transfer structure”. This operation deletes the transfer structures and transfer rules for the affected sourse systems. It asks also if you want to delete RFC destinations and Logical systems of the source systems (SALE).
“MySelf” Logical system (based on old ) can not be deleted.
Release the request created during this procedure.
b) DO NOT create new Logical system (e.g. GRGRB400). In BDLS step this will be done automatically by the report RBDLSMAP
c) Follow note 121163
d) Before running BDLS, adapt ROLLBACK segments (if necessary)