Professional Documents
Culture Documents
Recommendations For Migrations Using Microsoft SQL Server
Recommendations For Migrations Using Microsoft SQL Server
Recommendations For Migrations Using Microsoft SQL Server
Symptom
Other Terms
We strongly recommend that you only make the changes to the standard migration
process that are mentioned in this note in collaboration with experienced
certified OS/DB migration consultants.
Experience shows that incorrect or incomplete changes can have serious
consequences. (Missing primary keys, for example, mostly result in data
inconsistencies.)
Solution
1. Unsorted exports
As of SQL Server 2008 R2, the import of unsorted exports to SQL Server is
released without restriction.
2. Clustering and creation point of the primary key
The standard OS/DB migration tools create a clustered index for the primary
key, before the data are loaded into the table. This ensures that the data
are stored in a "sorted" format in the SQL Server tables. All tables in SAP
systems like ECC 6.0 are created in this way. Tables in BW systems may have
migration tools are configured by default so that tools use PAGE compression
for all tables and indexes. All customers should use PAGE compression, if
the database release is SQL 2008 or higher. Ensure that you have imported
SAP Note 1581700 with SNOTE or that it is contained in the Support Packages.
9. Information about splitting when exporting or importing
If the export runs on SQL Server with split tables, the R3load and R3ta
versions listed in SAP Note 1650246 must be used. This change was provided
for kernel release 7.0 and higher.
NOTE: The general method of splitting used in the 6.40 version of r3ta or
before does not work for SQL Server and will result in export times that are
much worse than an export which does not split any tables.
General guidelines can be given about how many table splits should be
generated in source systems (Oracle, DB2, MaxDB, and so on). Performance on
export and import varies considerably, depending on hardware resources, SAN
memory I/O functions and factors in relation to the table (data
distribution, data types, size, and so on).
Customers have successfully exported systems with table splits ranging from
2 to over 80.
WARNING: E-Fact and F-Fact tables in BW must not be split when the export
runs on SQL Server because they have no primary key constraint. For those
tables R3ta will revert to the older split method used prior to the change
of note 1650246. The splitting process itself will take a very long time,
and the export will take too long as well. Much longer than if these tables
were not split at all. DSO and PSA tables do have primary keys and can be
split efficiently just like normal tables.
The parallel import of split tables is fully supported under SQL Server 2008
R2 and higher. Older SAP documentation may specify restrictions, but these
restrictions are obsolete.
If you observe deadlocks when importing using SQL 2005 or 2008 (not R2),
reduce BCP_BATCH_SIZE.
10. General recommendations
The following is strongly recommended:
a) Use the latest R3Load.exe, dbmsslib.dll and r3ldctl.exe.
b) Use the latest SAP Software Provisioning Manager (SWPM).
c) Use the kernel DVD with the latest patch level.
d) Use the latest available SQL Server release.
e) Use the latest SQL Server Service Pack.
f) Import all SAP Notes required for SQL Server into the source system (even
if it executes UNIX/Oracle or DB2. By doing this, you ensure that no
problems will occur in the target system. SQL Server specific code in OSS
Notes will not be executed in the source system
g) Read SAP Note 888210 or 1738258 and check SAP systems with very old
Support Packages carefully, since SAP Notes that support compression or
other SQL Server function, may have to be imported with SNOTE.
11. Further information
Read the FAQ about OS/DB migration in the Microsoft blog located here.
Other Components
Component Description