SEO

Hi,

I'm actually working on the migration of a DB2 unicode db (V8.2 FP 15) from
a Sunfire machine with SunOS (64 bit, Big-endian) to an AIX 5.3 (64-bit,
Big-endian) server located in US. The target server has DB2 V8.2 FP 15
installed and instance name and filesystem user groups rights an so on are
all identical.
From the manuals I see that a crossplatform backup-restore should be
supported between the two systems.
I did a full offline backup of the db with compress option. Resulting backup
file is about 10GB. Then I ftp'ed this image in binary mode to the target
machine. I did a restore like this

db2 restore database <db> from /tmp/<image_name> taken at <time_stamp>
comprlib <aix_compression_lib>

this said restore was successful. I did a rollforward complete (successful)
and could connect to the database so it seemed all went well. I began
running some SQL and scripts and noticed soon that our character data is
somewhat corrupted. We have a lot of text data from over 40 countries in
many different languages and the character data from some languages (like
chinese and arabic for example) has been completely replaced by 0x00 0x1A
bytes in char and varchar columns.

Does someone has an idea before I go with IBM support?

Regards,
aka.

aka wrote:
> I'm actually working on the migration of a DB2 unicode db (V8.2 FP 15) from
> a Sunfire machine with SunOS (64 bit, Big-endian) to an AIX 5.3 (64-bit,
> Big-endian) server located in US. The target server has DB2 V8.2 FP 15
> installed and instance name and filesystem user groups rights an so on are
> all identical.
> From the manuals I see that a crossplatform backup-restore should be
> supported between the two systems.
> I did a full offline backup of the db with compress option. Resulting backup
> file is about 10GB. Then I ftp'ed this image in binary mode to the target
> machine. I did a restore like this
>
> db2 restore database <db> from /tmp/<image_name> taken at <time_stamp>
> comprlib <aix_compression_lib>
>
> this said restore was successful. I did a rollforward complete (successful)
> and could connect to the database so it seemed all went well. I began
> running some SQL and scripts and noticed soon that our character data is
> somewhat corrupted. We have a lot of text data from over 40 countries in
> many different languages and the character data from some languages (like
> chinese and arabic for example) has been completely replaced by 0x00 0x1A
> bytes in char and varchar columns.
>
> Does someone has an idea before I go with IBM support?
I'm going out on a limb here, but I don't think you have a restore problem.
neither backup nor restore give a hoot about your VARCHAR and CHAR columns.
It does not look at the data.

Now, to confirm that please compare the HEX content of the data.
Running the HEX() function ON THE SERVER via SQL.

I would start looking at codepage conversion, locale, territory.
Not my cup of tea, so I can't be more specific. But I'd be very
surprised if backup/restore is guilty.

Cheers
Serge
--
Serge Rielau
DB2 Solutions Development
IBM Toronto Lab

Hi Serge,

thanks for confirming that BACKUP / RESTORE should not mangle with our
character data, that was also my thinking.

What I did was SELECT HEX(REP_MESSAGE) FROM ... and it returned a string
like this 001A001A001A001A...

Now because control center can not show many of the UTF-8 encoded data
especially when there are different languages mixed in the same field we
tend to use Toad for browsing the db and looking at our tables.
My experience so far is that Toad has less problems in reading out these
fields even if there is sometimes an invalid unicode character in the data
(which comes mostly from byte oriented substring operations), but by
browsing some tables on the target machine I saw whole screens full of
..?.?.?.?.?.?.?.?.?.?.?.?.?.?.?.?.?.?.?.? where I see chinese (at least I
believe) characters over here in our data warehouse.

I set the LANG=en_US.UTF-8 on both machines in my PUTTY window...

I'll be on this topic next week and researching further.

Thanks & regards,
aka.


"Serge Rielau" <srielau@ca.ibm.com> wrote in message
news:61ovscF20aog1U1@mid.individual.net...
> aka wrote:
>> I'm actually working on the migration of a DB2 unicode db (V8.2 FP 15)
>> from a Sunfire machine with SunOS (64 bit, Big-endian) to an AIX 5.3
>> (64-bit, Big-endian) server located in US. The target server has DB2 V8.2
>> FP 15 installed and instance name and filesystem user groups rights an so
>> on are all identical.
>> From the manuals I see that a crossplatform backup-restore should be
>> supported between the two systems.
>> I did a full offline backup of the db with compress option. Resulting
>> backup file is about 10GB. Then I ftp'ed this image in binary mode to the
>> target machine. I did a restore like this
>>
>> db2 restore database <db> from /tmp/<image_name> taken at <time_stamp>
>> comprlib <aix_compression_lib>
>>
>> this said restore was successful. I did a rollforward complete
>> (successful) and could connect to the database so it seemed all went
>> well. I began running some SQL and scripts and noticed soon that our
>> character data is somewhat corrupted. We have a lot of text data from
>> over 40 countries in many different languages and the character data from
>> some languages (like chinese and arabic for example) has been completely
>> replaced by 0x00 0x1A bytes in char and varchar columns.
>>
>> Does someone has an idea before I go with IBM support?
> I'm going out on a limb here, but I don't think you have a restore
> problem.
> neither backup nor restore give a hoot about your VARCHAR and CHAR
> columns.
> It does not look at the data.
>
> Now, to confirm that please compare the HEX content of the data.
> Running the HEX() function ON THE SERVER via SQL.
>
> I would start looking at codepage conversion, locale, territory.
> Not my cup of tea, so I can't be more specific. But I'd be very surprised
> if backup/restore is guilty.
>
> Cheers
> Serge
> --
> Serge Rielau
> DB2 Solutions Development
> IBM Toronto Lab