MaxDB import error from 7.5.0.55 to 7.6.06.27

[Former Member]

Hi All,

Good Day!

We are using MaxDB Export/Import to migrate the Content server data from MaxDB 7.5.0.55 to MaxDB 7.6.06 build 027.

Export has been completed successfully, now when we are trying to import in to the target database with latest loadercli tool on the target system,

there is an error throwing..

Error details are:

"Error restoring table COMPONENTS0001; table exists but source table

and

target table schema are different"

FYI:

We have installed the MaxDB database freshly & updated to latest

7.6.06 BUILD 027. We are executing the loadercli statement from the

target system only. The reason we are not upgrading to latest 7.7 or 7.8 is our Cache server are on 7.6 & so the content server update is also planned on 7.6.

Can you please let me know how to map the schemas & restart the import.

My thought is if we map schemas, it should start the import without issues.

Thanks,

Best Regards,

Prabhu Reddy.

[yashwanthkumar_kethineed]

Hello Prabhu,

It looks like the Definitions of source and target table COMPONENTS0001 do not match.

NOTE - If the source database version is < 7.6 and the target database version is >= 7.6, the parameter COLUMNCOMPRESSION must be set to NO in the target database.

Next Steps:

Check if the database parameter COLUMNCOMPRESSION is same on both source and target databases.

Check "Actions in the target system" in SAP Note - 962019 - System Copy of SAP MaxDB Content Server Database

If this is the case, after you adjust the parameter - drop the table on the target "COMPONENTS0001" if exists before you restart the import again.

[Former Member]

Hi Prabhu,

why do you use loadercli? You should be able to just import using backup and recovery.

Also for the different cache/content servers it is not important which DB version they run. This is transparent for the applications accessing the CS/CSC.

Regards,

Matthias

[former_member188883]

Hi Prabhu,

Can you maintain the same schema like source when you install target MAxDB instance.

This should resolve the issue.

Secondly check the dbsize.tpl file located in the export dump. You can perform relevant mapping in this file.

Regards,

Deepak Kori