6/19/22, 6:33 PM Experiences from Unicode Conversions | SAP Blogs

Community Topics Groups Answers Blogs Events Programs Res

Ask a Question Write a Blog Post

Former Member
February 17, 2009
| 6 minute read

Experiences from Unicode

Conversions
 3  2  7,819
Follow

Unicode Conversions are more and more requested by customers driven by SAP’s
 Like 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
 RSS Feed 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.

Example

One 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.

https://blogs.sap.com/2009/02/17/experiences-from-unicode-conversions/ 1/9
6/19/22, 6:33 PM Experiences from Unicode Conversions | SAP Blogs

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 effort

For 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!).

https://blogs.sap.com/2009/02/17/experiences-from-unicode-conversions/ 2/9
6/19/22, 6:33 PM Experiences from Unicode Conversions | SAP Blogs

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)

https://blogs.sap.com/2009/02/17/experiences-from-unicode-conversions/ 3/9
6/19/22, 6:33 PM Experiences from Unicode Conversions | SAP Blogs

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.

https://blogs.sap.com/2009/02/17/experiences-from-unicode-conversions/ 4/9
6/19/22, 6:33 PM Experiences from Unicode Conversions | SAP Blogs

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.

https://blogs.sap.com/2009/02/17/experiences-from-unicode-conversions/ 5/9
6/19/22, 6:33 PM Experiences from Unicode Conversions | SAP Blogs

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.

Alert Moderator

Assigned Tags

Retagging required

roger hoogeveen

https://blogs.sap.com/2009/02/17/experiences-from-unicode-conversions/ 6/9
6/19/22, 6:33 PM Experiences from Unicode Conversions | SAP Blogs

Similar Blog Posts 

Unicode Conversion Overview Guide
By
Former Member Apr 08, 2009

System Conversion to SAP S/4HANA: SUM is the tool

By
Boris Rubarth Nov 24, 2015

SAP Upgrades: When Should my Organization Convert to Unicode?

By
Former Member Jul 05, 2008

Related Questions 
Archiving
By
matt s Sep 24, 2008

upgrade ERP 6.0 non-unicode

By
Nicola Blasi Sep 10, 2009

ABAP to Unicode COnversion

By
Former Member Jun 09, 2007

3 Comments

Former Member
February 17, 2009 at 11:43 am

Hey Roger,

Sounds like philips?!

Nice weblog. Maybe I will contact you in a while since I might be involved in some upgrades.

Best regards,

https://blogs.sap.com/2009/02/17/experiences-from-unicode-conversions/ 7/9
6/19/22, 6:33 PM Experiences from Unicode Conversions | SAP Blogs

Joris

Like 0 | Reply | Alert Moderator | Share

Former Member
May 8, 2009 at 6:00 am

Hi,

Thanks for this nice blog. We are planning to start the unicode conversion and this helped me to think
about lot of options.

Nice work!

Thanks!

Like 0 | Reply | Alert Moderator | Share

Former Member
July 2, 2010 at 12:58 am

Can you explain in details the steps take for table splitting as this was the measure factor in your case and also
i am going to do this kind of project in coming days

Like 0 | Reply | Alert Moderator | Share

Add Comment

Find us on

Privacy Terms of Use

Legal Disclosure Copyright

https://blogs.sap.com/2009/02/17/experiences-from-unicode-conversions/ 8/9
6/19/22, 6:33 PM Experiences from Unicode Conversions | SAP Blogs

Trademark Cookie Preferences

Newsletter Support

https://blogs.sap.com/2009/02/17/experiences-from-unicode-conversions/ 9/9