Unicode Single Host In-Parallel Database Conversion or Migration: Part 2

[Former Member]

This is Part 2 of the series of a technique to simultaneous perform R3load database migration on the same host. Part 1 can be found here.

Steps to Perform Simultaneous Export and Import Using Standard SAP Tools (SAP Inst)

Prerequisites

1. Disk space: as a rule of thumb you will need to plan for approximately double the disk space than your source database.
   Some think you would need Triple the disk space due to need a) the original database b) intermediate flatfiles and c) the target system.
   However in practice the target database is smaller than original and the can be 1/2 the size
   particularly if you import with advanced compression. The intermediate  flatfiles are created in a compressed format as a result they always a small fraction of the source size. in my experience 10~30% of the size. ie For a 3TB database, the flatfiles will require at most 1TB of Tier 2 storage (any spare or aging disk ) should be more than enough. In my recent engagement 3.5TB of database after export consumed 650GB of disk space.
   
   You will need the following filesystems for a Oracle to Oracle migration
   /oracle/<NewSID/ and all sapdataXX mirrlogx origlogx fileystems as per standard install guide. If you are migrating from a non-compressed to a compressed database plan for about 50% of the current database size.
   /backup/fullexp : This will need to be around 30% of the current database size, it will contain the intermediate flatfiles exported from the source system.
   /backup/migmon: This is the communicate directory for the migration monitor it can be small 1GB.
   
   
2. Memory : Normally the memory you have for the running the SAP instance is used during the migration for the 2nd database.

Basic Overview of Steps

1. Source System Size Calculation: Using sapinst Perform database size calculation to extract database size.
   
   
2. Target Database Build Start SAPInst on the Import target to create a target system system using sapinst. "Waiting for package"
   
   
3. Source System Optional Table Split calcuations for large tables ( if you use Oracle rowid's this needs to be done in downtime)
   
   
4. Source System Export: During downtime The source database is exported , simultanously the data is imported by the importer processes waiting in step 2.
   
   

Tips.

1. Make sure you download from SAP's service market place the latest R3load and Oracle libraries. Additionally upgrading your landscape to the current kernel would bode your project well (eg 7.20 EXT2)
2. Practice as best you can, strongly recommend 2 technical only practice runs first to document and second to optimize before migrating your first system.
3. Simultaneous processes: 1 core : 4 R3load. This is a very tough of course if you only have 1 productive system sized correctly. As a rule of thumb 1 CPU core = 4 R3load processes. eg if you have 22 cores available then 88 simultaneous process are good split 50:50 between exporters and importer
4. During the R3load processing the SAP instance is not running. Thus all of the avaiable memory to database processeing , split once again 50:50.
5. Don't forget to use the direct path method of import. "-loadprocedure fast" (current versions)
6. Note for larger tables with LOB's (large binary objects) the  direct path doesn't work well unless you have oracle 11.2  and 7.20 export tool

Next is Part 3 in which we prepare the target system.