As most of people in SQL Server might know already, we released SQL Server 2008 at August 6th 2008. It is a finished product now with great features for SAP. The certification with SAP will happen as I described in an earlier article in this blog. But this shouldn’t be the theme of this article. This article should be about SAP Platform Migration to SQL Server and SAP Platform Migrations on SQL Server. As one still might remember, we engaged with SAP in a common migration lab last year to optimize SAP Platform Migrations and SAP Unicode Migrations. We still continue this engagement and keep on working on documentation as well as product improvements on both sides. In order to get experiences and knowledge to the public earlier, three OSS notes got released on SAP Migrations which should help to give ideas on how to minimize the downtime by speeding up the export and import phase of the SAP migration process. Let me briefly describe these OSS notes.
Let’s start with OSS note #1156361. This note describes a change on the SAP R3load side using bulk insert for tables which have a CLOB/BLOB column. In the past rows into tables with columns of that type got inserted on a row by row basis instead of SQL Server’s bulk load interface. The reason for not to use the bulk insert interface was that there were problems on the SQL Server side many years back. Also data volumes of tables with CLOB/BLOB columns remained small in the SAP space. Times changed, there are no problems with SQL Server’s ability to bulk insert rows with CLOB/BLOB content and the tables in SAP containing CLOB/BLOBs also grew in volume quite a bit. With some changes in their code, SAP was able to increase the throughput loading data into SQL Server with the most recent bits and bytes for Netweaver 7.0 and Netweaver 2004.
Next OSS note would be #1241751. This note was just released today. The note describes one problem we saw again and again when customers were performing SAP Unicode and SAP Platform Migrations. The issue always was that the SQL Server transaction log volume grew dramatically during the import phase. The scenario this growth happens in looks like the following: Several dozen R3load processes load data and eventually create non-clustered indexes. Due to the fact that SQL Server did not use its minimal logging capabilities for the particular way SAP loads the data, the volume in the transaction log could grow to several 100GB performing larger migrations with Terabytes of data volume. SQL Server 2008 does improve this situation. We also adapted the improved coding in SQL Server 2005 CU8 (Cumulative Upgrade 8 – based on top of Service Pack 2) to significantly reduce the volume growth in the SQL Server’s transaction log for the particular way SAP loads the data. How to enable these improvements for SQL Server 2005 and SQL Server 2008 is described in the SAP OSS note.
Last but not least OSS note #1054852. A longer but comprehensive note describing several aspects of reducing export and import times. Areas covered in this OSS note are:
- Is sorting of data required?
- Primary key handling in relation to clustering and time of creation
- Can you deactivate logging on MS SQL Server?
- Information regarding sorting and Unicode conversion
- Information regarding BW migration and sorting
- Information regarding BW migration and partitioning
- Information about compression
- Information about splitting when importing
The content of this note is extremely comprehensive and based on reports of experiences customers made as well as experiences made in the migration lab. It is a must to read before approaching any type of SAP Unicode migration on SQL Server or SAP Platform Migration to SQL Server. So far so good. We expect to see more out of the joined SAP and Microsoft lab within the next 6 months.