Unicode Conversions are more and more requested by customers driven by SAP's strategy to support only unicode systems as of NetWeaver 7. For the project team unicode conversions may be real challenging as the next story might clarify. The total runtime of an upgrade and unicode conversion was approx. 1 year and a half in one of our situations.
The next part is about our experiences with unicode conversions and the possible scenarios. I hope that it clarifies the unicode conversion project and the possibilities for customers and partners to optimize the runtimes.
ExampleOne of SAP's customers was running 2 separated R/3 4.6c production systems (both with Oracle db size of approx. 1.2 TB at the start time; different client numbers for the production client) and customer had a certain need to upgrade the systems and convert them to unicode.
As technical consultant involved in this project we copied the first production system to a test system and performed a combined upgrade and unicode conversion.
That was a disappointing adventure, the total process (upgrade+unicode conversion) took more than 4 days total downtime.
The customer's requirements had only a 24-hour downtime window in a weekend so this was not acceptable for customer and we had to find another solution for the customer.
The architect of the customer decided to split up the upgrade and the Unicode conversion (unwanted by SAP, customer has to sign a disclaimer for this situation) and both the upgrade and the unicode conversion processes were optimized with respect to runtime.
Unicode conversion steps
In this story I will focus on the unicode conversion, the upgrade from 4.6c to ERP6.0 will not be specified in detail. The following steps are the basic steps for unicode conversions (from presentation SPC200.pdf):
1. Prepare non-Unicode system. (mainly SPUMG)
2. Export non-Unicode database and convert non-Unicode data. (the export)
3. Create new Unicode database and import the non-Unicode database. (the import)
4. Do post-conversion activities in the Unicode system (mainly SUMG)
Source system: MDMP or Single Code page ?One of the first questions for Unicode Conversions is the source system, is it MDMP or single code page? In our situation customer had a MDMP system, with European languages installed (D+E) but also Asian languages (J+1+M).
From presentation SPC200.pdf: ca 90% of all SAP customers are single code page.
MDMP unicode conversion: much effortFor the unicode conversion of the MDMP system we noticed that execution of SPUMG was much effort with long runtimes (more than one week runtime to complete all SPUMG steps!).
Tip: The spumg results can be saved to use in other systems. This is described in the Twin Upgrade and Unicode conversion guides.
The "project planning - mdmp system" published on SDN was used for our customer.
The project planning generally means that we created a copy of the production system to a test system (and renamed it and isolated it from the other SAP systems) and a Unicode conversion was executed on this test system.
After a few weeks the first conversion of the test system was completed and we created a new test system by copying the production system over the test system again (and isolating it!).
This new test system was Unicode converted for a second time, third time and so on. (it was executed 5 times before production was converted)
The role of a test system is important
The test system that we had available was no complete copy of the production system, the production system consisted of db+ci server and 6 application servers. Our test system was only as big as the db+ci server (no application servers available). We will see lateron that we would liked to have had the exact hardware as production.
Runtime improvement: focus on export+large/cluster tables
After the first unicode conversion we noticed that the export runtime had to be improved because this was our major factor for the downtime.
For other systems we also noticed that the export requires most tuning, cluster tables are important for tuning, some large tables were in the system that took almost 24 hours to export.
Speed-up the conversion runtime
Possibilities to speed-up the conversion runtime:
1. parallellization (nr of R3load processes; set to 12 in our case, we tested also other values)
2. table splitting for large tables
3. archiving/cleaning up of large tables that can be cleaned easily
4. use application servers for export (not used in our case due to no application servers available on the test system)
5. parallel export+import (not used in our case, not possible, some prereqs: different server when sid remains same)
6. fastload-options for Oracle database (tested but not enough performance gain)
7. unsorted export (tested but also not enough performance gain)
8. additional support from SAP SLO team like told in oss note 693168
Experiences
We have tested almost all options, and mainly table splitting was of major influence to bring the downtime of the longest export-part back from 24 hours to approx. 6 hours, this was sufficient for us, the total export ran finally for approx. 12 hours.
The largest table in these production systems was approx. 60GB and also tables of 20GB were split. We have split the 10 largest tables to keep the overview.
Since we did not use unsorted export we needed a very large PSAPTEMP tablespace (250GB in our situation, the used-level peaked at approx. 200GB).
Also some of the tables were cleaned up dramatically (archived, like some old idocs).
Table splitting: use and test with care!
We used NW7SR2 (named NW2004sSR2 at that time) that has builtin support for table splitting, but unfortunately the table splitting does not work out-of-the-box (be warned!). Several manual actions were necessary (undocumented or badly documented) to use table splitting. Quite some effort was necessary to make table splitting working completely in NW7SR2. When you want to use table splitting make sure to test this very good on the test system. A few days before we executed the production conversion the software NW7SR3 was released, but this was too late for us, I expect that some of the table splitting bugs will have been fixed in SR3.
I expect also that additional application servers could have brought down the total runtime of the export, but we had no possibility (on short notice) to test and workout this scenario completely before the production system was planned to be converted (and our runtime was acceptable now).
Some experience numbers
ERP6 system with MDMP database with languages D+E+N+1+J+M (European languages and Japanese+Chinese languages)
db+ci on 16-cpu Itanium2 HP server and 6 application servers for approx. 1000 concurrent endusers
Oracle database with total size of approx 1.4TB, runtime of export+import was approx. 24 hours (executed only on dbci server; import is a bit faster than the export)
psaptemp must be very large when nr of parallel R3load processes is high and when tables are large (250GB in our case)
Additional support of the SLO-team
When the first R/3 production system was upgraded and converted to unicode, we still had one 4.6c production system of approx. 1.3TB left that needed to be upgraded and unicode-converted. The fastest way for this second system was by using the services of the SAP SLO-team (System Landscape Optimization). We created a copy of the 4.6c production system and the ERP6 unicode production system (and isolated these test systems) and installed a third NW7 system with TDMS functionality. The TDMS system simply read all data from the 4.6c system and copied this data to the ERP6 system. This cycle was repeated 3 times before the final execution was done for the 2 production systems. Also the customer and the functional teams had much work to test all functionality from both production systems.
Note that this way of copying the old release system into the new release system via an additional TDMS system was only possible because the 2 production systems used different client numbers.
The 4.6c production system of approx. 1.3TB was copied to the ERP6 production system in approx. 24 hours, another 20 hours test and small corrections were executed after that by the customer and functional teams and the second system was also upgraded+unicode-converted within 1 weekend.
One of SAP's other customers had a database of approx. 3 TB that needed to be converted to unicode. There was an additional requirement that the production system was only allowed down for approx. 6 hours in 1 particular weekend. Unfortunately I have no exact details about this conversion (I'm very curious about technical details and numbers), but I understood it was executed successfully by the SAP SLO team.
I hope that these 2 conversion stories can help some of the customers and partners to have some background information and possibilities about Unicode conversions.
Summary
Summary: The unicode conversion project can be quite challenging with long runtimes depending on the source system and the available resources for test scenarios and final conversion. Customers and partners have quite some possibilities to decrease the runtime of the conversion theirselves, but also the SLO team of SAP can assist in decreasing the runtime.
Roger Hoogeveen started as unix system engineer in 1994, is certified SAP Technical Consultant since 1996 and is specialist in migrations, upgrades and unicode conversions.
Roger is one of the Technical Consultants at Uphantis (http://www.uphantis.com) in the Netherlands that can service SAP customers.
