Here's an update of our journey to production Unicode conversions for R/3 and SCM.
In prior installments, I talked about planning and about our development conversions. This weekend we converted our quality systems, with the largest being an R/3 instance close to 6TB when we began. It is smaller now!
First, my primary role is performance tuning, so here are charts of CPU use for the application servers we used in R/3 and SCM.
R/3 Unicode Conversion (quality) CPU Use
SCM Unicode Conversion (quality) CPU Use
At SAP Tech Ed '07, I showed a simplified version of charts below, and explained how we optimized our network connectivity to minimize contention between incoming and outgoing data on all servers. For R/3, we used 5 app servers, for SCM we used 4.
Network pipe diagrams
Our Oracle and Unicode consultants worked on balancing the export and import streams that R3Load used. We employed table splitting, the "load fast" procedure, and this time used ROWID (see below). The CPU charts show we were at peaks for about 12 hours, and the work dwindled after that. Additional load balancing, plus better I/O systems in production should put us back to around 12 hours for the copy.
As a result, the R/3 database move was executed in under 17 hours.
There was also downtime in the schedule to move storage back to the original I/O system. This ran for about 12 hours.