cancel
Showing results for 
Search instead for 
Did you mean: 

System copy without application data.

Former Member
0 Kudos

Hi All,

  I have a scenario where I need to deploy a PRD2 system which should exactly same as the source system (PRD1) with following requirements:

   A) PRD2 should have all the configs (standard & customized) from PRD1

   B) PRD2 shouldn't have any application data (master & transactional) from PRD1.

  Both system is ERP 6 EHP5.

  PRD1 = AIX while PRD2 = WIN.

  System copy (migration) is out since it will copy also the application data....

  At first I thought by doing the following:

  1) Freesh install PRD2 to the same component level with PRD1.

  2) Create a Transport Reqeust from PRD1 which include all the relevant Non-SAP repository objects and transport to PRD2.

  3) Perform client copy (Cross Customization & Client specific customization ) from PRD1 to PRD2 via SCC8.

However, notice that this method might not be working since in PRD1 there might be bunch of the SAPNOTES have be implemented before this. However the PRD2 is a newly fresh installed system. Even though the Step 1,2 ,3 above is success, I'm still loosing the SAPNOTES changes in PRD2.

Do you have any idea in order to fullfill the requirement A) and B) above ?

Thanks.

Best Regards,

Ken

Accepted Solutions (0)

Answers (2)

Answers (2)

former_member443053
Discoverer
0 Kudos

Hi, I have the same question. Which profiles do we have to select when performing local client copy? SAP_CUST? Thanks!

Reagan
Product and Topic Expert
Product and Topic Expert
0 Kudos

If you want to get all the corrections implemented (SNOTES) on the PRD1 system then first create the PRD2 system following the heterogeneous system copy (migration).

Then create a new client on the PRD2 system and perform a local client copy from source client to the target client. Once the copy is complete schedule a client deletion for the source client.

Regards

RB

Former Member
0 Kudos

Hi Reagan,

Have thought of this also.

However, how to release the free space back to file system after delete the source client ?

Thanks.

Best Regards,

Ken

martin_E
Active Contributor
0 Kudos

Without knowing your DBMS, my first suggestion is that you measure the space used after you complete the system copy (but before you do the client copy)...

After you complete (and validate) the client copy,

delete the source client

unload / export the database using your DBMS tools,

redefine / recreate the filesystems underlying the database,

and import the database.

If I was in a trolling mood, I would have suggested going into the SQL Server Management Studio and shrinking the database

Former Member
0 Kudos

Hi Martin,

  Sorry for not telling the DBMS upfront ...

  It is Oracle 11.2g.

  Hmm... after dropping the source client, in order to 'resize' the datafiles... we can use BRTOOLS to do so but it might need to require drop all the objects that belongs to the datafiles / tablespace...( not sure how can archieve it ... wonder if will leads to any inconsistencies ... ? )

  By the way, if right after deleting the source client  (currently my Oracle DB has plenty of freespace) and I perform System Copy (Migration) from PRD1 to PRD2.

Will System Copy only export the used spaces or it will export also the freespace and it will require the target ssytem to have the same Total Size (Used + Free spaces) as the source system ?

Thanks.

Best Regards,

Ken

martin_E
Active Contributor
0 Kudos

Ken,

I'm so used to working with limited disk space that I didn't even think of multiple system copies

You delete the source client via transaction SCC5 - As you say, this leaves a big chunk of unused space in your database. You can safely use BRtools to free this up.

If you have the disk space available, do consider the system copy method, as I find the SWPM tools (especially on Windows) make it so much easier than mucking around with your DBMS tools etc.  Because the System Copy uses R3Load, it will only process the data, not the free space.

To summarize, the single System Copy method is:

  1. System Copy PRD1 to PRD2 on Windows,
  2. Perform a local client copy (Cross Customization & Client specific customization) on PRD2
  3. delete the source client on PRD2,
  4. Perform a database reorganisation on PRD2

... and the dual System Copy method is:

  1. System Copy PRD1 to a temporary System (Windows or AIX, wherever you feel more comfortable),
  2. Perform a local client copy (Cross Customization & Client specific customization) on the temporary system,
  3. delete the source client on the temporary system,
  4. System Copy the temporary system to PRD2

Some suggestions:

Be aware of any system specific things like live cache,

Make sure you have installed any windows specific OSS notes somewhere in the process prior to performing the migration to windows; these can have a massive impact on the R3Load time for the import.

With the dual System Copy method, the intermediate system will need licence keys, however so long as you don't record it as a production instance, there's no legal or financial ramifications.

EDIT: I just saw this in my bookmarks - may be usefull

hth

Former Member
0 Kudos

Hi Martin,

  Thanks for the info..

  Regarding the reorg database, do you meant reorg all the tables from one tablespace to another tablespace ?

  If yes, during the reorg database with Brtools. There might be some problems with the tables with RAW/LONGRAW columns which they will be converted to LOB objects before the reorg start. ( we would like to avoid that ... )

  By the way, as mentioned earlier, do you know if System Copy with SPM will require the source system and the target system to have the exactly same data file size ? OR, the System Copy method will actually calculate the required space only in the target system ?

  If is the latter, meant after deleting the source system's client, I can perform system copy and by right the target system's size is already 'slim down' ....

  What your comments ?

Best Regards,

Ken

Reagan
Product and Topic Expert
Product and Topic Expert
0 Kudos

Hello ken

To reclaim the space you will need to do a DB reorg.

It can be done by tablespace to tablespace or by doing export and import using BR*Tools. I prefer the latter.


If yes, during the reorg database with Brtools. There might be some problems with the tables with RAW/LONGRAW columns which they will be converted to LOB objects before the reorg start. ( we would like to avoid that ... )

Use the Export and Import strategy

You do not need to do a system copy aftr deleting the client.

You just need to do a DB reorg to compress the database.

Check the size of the system before doing the local client copy.

After the client deletion start the DB reorg.

Assuming the size of the DB was 320 GB before the client copy.

After taking the export of the DB drop the source tablespace.

Create the tablespace and extend it with 10 new datafiles of 1 GB each and maxsize set to 32 GB

Start the import.

Regards

RB

t_ashok_reddy_t
Explorer
0 Kudos

"Then create a new client on the PRD2 system and perform a local client copy from source client to the target client."

which profiles do we have to select when we are performing local client copy from source client to the target client???