unicode conversion by using oracle exp / imp ?

[Former Member]

Hi, unicode experts.

I have done unicode conversion by using sapinst (R3load). It works flawlessly.

But when you do all necessary preps and try to convert through oracle tool

exp/imp, I would get core dump when using R3trans at Target, even if I switched on

unicode version of DDNTF and DDNTT, if you know what I mean.

SO is it possible to convert to unicode by exp/imp ? Have anyone done one ?

Could someone list all the steps that is done by sapinst ?

Which step could not be achieved by manual prep and exp/imp ?

Let us put support issue aside, and only focus on the tech. side, say, on sandbox.

The reason I want exp/imp to work is clear. R3load is simply too slow ! Plus,

the R3load import cannot start until export is done.

Thanks for your insights.

Hans

[Former Member · Accepted solution]

next: exp/imp would only be able to convert text strings from one codepage to the next one on database VARCHAR type fields.

not all text information within an SAP System is stored in VARCHAR fields. Some are stored in other LONG RAW, LOB or BLOB fields. This content would not be converted.

peter

[markus_doehr2]

(...)

SO is it possible to convert to unicode by exp/imp ?

Have anyone done one ?

definitely - NO

- for various reasons.

(...)

R3load does a LOT more than just exporting the database - R3load does the actual CONVERSION.

Example:

You have a table with three lines of different codepages

TEST_TABLE
==========
1 English (ISO 8859-1)
2 German (ISO 8859-15)
3 Russian (ISO 8859-5)

If you just use exp, it will export the data "as is", and reimport it "as is". No codepage change will take place. The only difference is, that the data is stored in a Unicode table, the data itself is not Unicode because exp does just a dump of the data to the harddisk.

Now - let's assume the first entry is a letter "a". In combination with the codepage ISO 8859-1 R3load "knows", that the ASCII code is '97' and need to be translated to U0061, which is the representation of 'a' in codepage UCS-2 (resp. 4102/4103). This is done for all characters in the system. Those "tables" are burried in the libicu* libraries, which is basically an IBM development (http://www-306.ibm.com/software/globalization/icu/index.jsp).

Exp/imp is not aware of that logic, it will dump the ASCII '97' into the Unicode database. You will get all sorts of mixture but never your actual texts back.

It's becoming even more complicated with cluster tables, they need to be uncompressed, data read, converted and compressed back again.

The reason I want exp/imp to work is clear. R3load is

simply too slow ! Plus,

the R3load import cannot start until export is done.

This is not true, you can use the migration monitor and do export and import in parallel over network. We did that and it was working great Additionally you can "split" big tables into pieces and process them in parallel too.

--

Markus

[Former Member]

Markus, thanks for your prompt reply.

I saw your point regarding multiple codepages. R3load will have an edge.

Assume that I have only one codepage and English is the only language.

We only want to convert it to unicode for future language expansion.

DO you still see a reason why exp/imp does not work ?

Even in such a simple case, my experiment of exp/imp seems to fail due

to core dump from R3trans. Can you pinpoint which step is missing ?

We did use the step for swapping nametab as in SAP note 932779.

I used the Solution Manager 4.0 as a test and did not mind the text

and only wanted to be able to start SAP to check up.

As far as parallel R3load export and import, I heard it before and will try it.

I appreciate your point of view. But Oracle specific exp/imp should be faster

compared to R3load.

Hans

[markus_doehr2]

Assume that I have only one codepage and English is

the only language.

We only want to convert it to unicode for future

language expansion.

An R/3 system consists at minimum of two languages, English and German So that is already ambigious: Either 7-bit ASCII or 8-bit ISO 8859-1

DO you still see a reason why exp/imp does not work

?

yes. You have lots of binary data in the database (e. g. your compiled programs) that must be converted too. Additionally as I said already, there are other table types, that exp is not aware (cluster, indx, pool). The structure of that table is stored in a special manner in binary tables, they need to become converted to Unicode too. If that is not done, nothing will work.

Even in such a simple case, my experiment of exp/imp

seems to fail due

to core dump from R3trans. Can you pinpoint which

step is missing ?

We did use the step for swapping nametab as in SAP

note 932779.

I used the Solution Manager 4.0 as a test and did not

mind the text

and only wanted to be able to start SAP to check up.

see above.

If you read the official conversion guides, you will understand, why it´s not working - technically. If it would have been that easy, SAP wouldn´t have invested so much time write special preparation transactions and programs.

Additionally, not everyone uses Oracle - and there must be a general approach for a conversion, not only for Oracle customers - beside the fact, that it´s technically impossible to do it with database tools.

As far as parallel R3load export and import, I heard

it before and will try it.

I appreciate your point of view. But Oracle specific

exp/imp should be faster

compared to R3load.

It´s not about speed - it´s about consistency and only the application (in this case it´s an application server) knows how to handle special tables.

We converted an almost 1 TB database in under 24 hours using parallel export and import - and 7 hours there were running just two tables. There are many things you can do to speed up things, check Note 857081 - Unicode conversion: downtime estimate

--

Markus