MaxDB upgrade/heterogeneus system copy problem with unicode conversion

[Former Member]

Project goal:

upgrade a Content Server Version 7.3.0.35 32bit Non Unicode to

version 7.6.06.16 64bit Unicode

I found and followed note 962019

My plan (following the note):

-create a clone of the original Content Server (vmware clone)

-as per note 962019 patched server 7.3.0.35 to 7.3.0.62 (> 7.3.0.57)

-created index

-on a fresh installed windows 2003 server 64bit i installed Content Server with build 7.6.06.16

-using loadercli from the target server (7.6.06.16) exported data

Now i was ready to start the import, as the note states:

"if the database parameter _UNICODE is set to the value NO and you want to start the target system with SAP MaxDB Version 7.6, you can use procedure described here for the import into a target system only with SAP MaxDB Version 7.6.05 build 11 or higher"

Having version 7.6.06.16 i was confident on such procedure, but my import stops immediatly with error:

D:\exportKpro>loadercli -d PRD -u SAPR3,SAP -b import.sql

Loader protocol: 'C:\Documents and Settings\administrator\My Documents

\sdb\loader\log\loader.log'

Loader packages: 'C:\Documents and Settings\administrator\My Documents

\sdb\loader\packages'

Error connecting user SAPR3 to database PRD on local host: -25005

User (SAPR3) logon to database PRD failed: SQL error -8046 = Conversion from UNI

CODE impossible: 7600 (error position: 1)

And now i'm stuck with no hints on how to proceed.

Thanks in advance.

Regards

Simone Zaffalon

[lbreddemann · Accepted solution]

Hello Simone,

as you're staying on Windows platform, there is no need for a heterogenous system copy.

All you've to do is to upgrade the 32-Bit installation to your target release (why not use MaxDB 7.7 right away?).

Once this is done, you can check whether the database catalog is still non-unicode (_UNICODE=FALSE).

If it is, there is a catalog migration procedure you can use to change this.

If the 32-Bit database is as you want it, take a full data backup.

Then uninstall the 32-Bit software, install the same version of MaxDB in the 64-Bit fashion.

Finally create the db instance by a restore of the backup.

After a load_systab your database is fully ready to go!

Just to stress this again: the _UNICODE parameter is not about your data!.

It's about the database catalog.

Having this parameter set to YES you can create e.g. tables named with Unicode characters.

The parameter does in no way affect your business data!

Since many customers ask why they should't use loadercli for a scenario like this:

a) It's only supported if you must use it, that is, you change the byte-order of the OS platform

b) it's way faster than export and import. We're talking about a few hours compared to days here!

c) It's much safer and controllable to use backup/restore and SDBUPD and move on step-by-step than exporting all data into a big file chunk and hoping that everything will be fine afterwards.

regards,

Lars

[Former Member · Accepted solution]

Thank you Lars.

Crystal clear.

The thing that is NOT clear is the note 962019.

If you read into "Symptom" you can read:

Homogeneous system copies (backup/recovery) can be executed only in systems that fulfill the following conditions:

a) The database versions in the source system and the target system do not differ.

and db version 7.3 and 7.6 obviously differ!

So i thought it was necessary to use heterogeneous system copy.

It was not clear that one could simply upgrade the instance to the target version-> backup -> restore .

Many thanks again for you clear description.

Just one thing. When you say

Then uninstall the 32-Bit software, install the same version of MaxDB in the 64-Bit fashion.

Finally create the db instance by a restore of the backup.

After a load_systab your database is fully ready to go!

Are you telling me that i can simply do a backup of a 7.3 database and import such backup into a 7.6 (and of couse do a load_systab)? I thought it was not supported.

Thanks again for your help.

Simone Zaffalon

[lbreddemann · Accepted solution]

> The thing that is NOT clear is the note 962019.

>

> If you read into "Symptom" you can read:

>

> Homogeneous system copies (backup/recovery) can be executed only in systems that fulfill the following conditions:

>

> a) The database versions in the source system and the target system do not differ.

> and db version 7.3 and 7.6 obviously differ!

I know. And I also know that there are several customers that ran into this.

Well, the note author is aware of this and will

> So i thought it was necessary to use heterogeneous system copy.

> It was not clear that one could simply upgrade the instance to the target version-> backup -> restore .

> Are you telling me that i can simply do a backup of a 7.3 database and import such backup into a 7.6 (and of couse do a load_systab)? I thought it was not supported.

Nope, not that.

What is supported is to take a backup of a 32-Bit database and restore it to a 64-Bit instance that have the same major version and the same endianess.

And that was what I tried to express in my earlier reply.

You still have to perform the upgrade via SDBUPD before.

regards,

Lars

[Former Member · Accepted solution]

Ok. No more doubts.

I started the upgrade in the vmware clone from 7.3 to 7.6 (i'm not switching to 7.7 because i'm not sure if content server 640 supports this version).

When upgrade is completed, i will take a full backup and then i'll restore this backup into target database.

Many thanks for you help and support.

Regards

Simone Zaffalon

[lbreddemann · Accepted solution]

>

> Ok. No more doubts.

> I started the upgrade in the vmware clone from 7.3 to 7.6 (i'm not switching to 7.7 because i'm not sure if content server 640 supports this version).

I am - it does

regards,

Lars

[Former Member · Accepted solution]

So... let's go for 7.7 (maybe some day i'll need to switch to Windows 2008. Who knows...)

Dowloading right now.

Thanks again

Simone Zaffalon

[Former Member]

Can you check may not help but

[lbreddemann]

Nope, this one surely won't help.

This thread is about upgrading a MaxDB instance and move it to 64-Bit.

The thread you referenced is about importing data into a existing database.

Two completely separate topics.

regards,

Lars