on 03-25-2014 6:26 PM
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
Hi, I have the same question. Which profiles do we have to select when performing local client copy? SAP_CUST? Thanks!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
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
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:
... and the dual System Copy method is:
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
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
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
User | Count |
---|---|
108 | |
12 | |
11 | |
6 | |
5 | |
4 | |
3 | |
3 | |
3 | |
3 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.