on 10-21-2013 2:27 PM
Hi Support Gurus,
I am performing a homogeneous system copy based on Microsoft SQL Server 2008.I have run System Copy using Sapinst twice and i am not getting the desired result.
The DB size is 3 TB and in both runs i have tried something different.
First Run --> I ran Sapinst without using table splitting preparation and package splitting.The run took more than 72 hrs.
Second Run --> I used Table Splitting preparation.I split 31 large tables by taking threshold of 5 GB for each chunk.The splitting ran fine and .WHR files were also generated. I then ran Database Instance Export , using package limit size as 10 GB and specified an order in which tables and packages should be unloaded.This time it took time more than the first run and the size of the Export was also larger.
My area of concern is that when i started the export, at that point it was using all the 30 R3 Load processes and the CPU utilization was also good but it left the SAPAPPL1 package for export in the end and only one R3 Load process was working on it.The export of SAPAPPL1 package almost took 3 days.
I don't understand when I had specified a package limit of 10 GB, then why the export was still so large for SAPAPPL1 package and it took 3 days.
Please suggest me on what am I missing.Is it the order or the package limit size.
Thanks & Regards
Sumit Prasad
Hi Sumit ,
Can you check if your DB it still running ?
Best Regards,
AhMeD
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello,
try to analyze the export/import time with the Migtime Tool (note 784118).
With this tool you are able to find the long running package(s) and you could try to split the affected package(s) more useful.
best regards
Jörg
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello Jorg,
I have analysed the export using MIGTIME both the times.From the analysis of the first run only we had decided to use "Table Splitting Feature" and had set the Package Size Limit also.
The table splitting went fine in the second run but the size limit of package was not picked up and therefore we still had huge packages such SAPAPPL1,SAPAPPL0,SAPSSEXC and etc left in the end and because of which the export took more than 3 days.
Please suggest further.
Thanks & Regards
Sumit Prasad
Hello Sumit,
did you use the latest SWPM for the export/import procedure ? ...or an old Installation Master-DVD ?
Did you check note 1650246 ?
Did you use parallel export/import method for saving some migration time ?
Did you test the export/import only with package splitting (and without table splitting) ?
What is your SAP Release ?
Did you check the concerned system copy guide ?
Please check the area "processing split tables" in the system copy guide and you will find the general information, that MS SQL do not support parallel data import (of the same table ?).
best regards
Jörg
Heelo Jorg,
Yes i am using the latest version of SWPM for export\import procedure.I also checked the Note # 1650246 before starting the export.
I am not using parallel export\import as we are using the same host for both export and import.
I have tested table splitting and package splitting both.Table splitting was a success but packgae splitting was not. Export got stuck again on SAPAPPL1,SAPAPPL0 and SAPSSEXC packages.
I succeeded in table splitting but was not able to pull out the large tables from the above mentioned packages.Package splitting also didn't work in spite of specifying package size limit.
SAP Release --> SAP ECC 6.0 EHP 6
I have also checked the concerned system copy guide but couldn't find anything relevant regarding package splitting.
Please suggest further
Thanks & Regards
Sumit Prasad
Hi Sumit,
Can you check in .TSK file what all tables are listed under these packages.
You may need to perform some homework on the tables under these packages and later evaluate whether table splitting for these packages can help or not.
Also you may think of package splitting with 100 M size to create more R3load jobs and speed it up.
Hope this helps.
Regards,
Deepak Kori
Hi Deepak\SAP Gurus
Table splitting and package splitting has worked fine for me.I was able to export source DB in 13hrs.
Now when i am performing the import, it is taking 3 days to finish.
Couldn't understand why as i have specified more number of R3Load proceses than i took for Export.
Waiting for your suggestions
Thanks & Regards
Sumit Prasad
Hi,
for me it looks like as if the table splitting doesn't work correctly. You should open an OSS message for this, as there were several changes in this area within the last half year.
Regards
Clas
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello Sumit,
for MS SQL 2008 'the database specific system copy way' is much faster as the export/import way.
Please have a look in the adequate system copy guide / area 'Database Specific System copy'.
SAP-Note 555223 (Question 😎 and note 151603 could be additional helpful.
The backup/restore way (recommended from Eduardo) is really very useful, because you didn´t have a downtime of the source system.
If you could have a downtime (perhaps in the case of a hardware migration) you could switch the SAN-Devices very fast from the old server to the new server without copy the data files manually.
In my opinion, it only make sense to use export/import way if your source ms sql database is under 2008 and the target database is ms sql 2008 (or a higher version) because the export/import way is an easy way to actitvate the 'new' compression during the import.
best regards
Jörg
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello Sumit,
Have you tried backup/restore? This could help you.
Remember to use a version with page compression (2008 SP2, 2008 R2 SP1 or 2012).
Regards,
Eduardo Rezende
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
93 | |
10 | |
10 | |
9 | |
9 | |
7 | |
6 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.