Issues after upgrading to MaxDB 7.8

[Former Member]

We are migrating from our Content Server from 32 bit MaxDB running 7.5.00.35 to Windows 2008 R2 running MaxDB 7.8.02.27.

The target install was done on 7.6 as per DVD and then was upgraded to 7.8.

This was followed by a restore of the source system from the backup.

The restore worked fine, but after the upgrade we don't see any schema users.

Most system command does not execute.

We see errors like below in the DB Studio event viewer.

SQL error

-4004,Unknown table name or unknown schema:MONITOR_CACHES

SQL error

-4004,Unknown table name or unknown schema:LOGINFORMATION

Any help?

[Former Member]

Hi Michael,

as posted by Srinivasa. Please try to load the system tables again...

Best regards

Christian

[michael_lehmann]

Could you solve the problem?

I did the same steps to migrating the CS 32bit MaxDB running 7.6.04.07 to Windows 2008 R2 running MaxDB 7.8.02.27

- Target install on 7.6 and then upgrad to 7.8

- Restore of the source system from the backup

Know I have the same errors:

**********************************************************************

dbmcli on SDB>sql_execute select * from users

ERR

-24988,ERR_SQL: SQL error

-4004,Unknown table name or unknown schema:USERS

**********************************************************************

Please let me know, whow you proceeded.

[Former Member]

Hi,

are you both using the correct user?

superdba for database internal tables

<sid>adm for saptables

Best regards

Christian

[michael_lehmann]

Hi Christian

The target-system already had his own SDB after the installation. The database from the source-system is called SDB as well.

Both DBs know the following users: control, sapr3 and superdba. This users have different passwords in source- and target-system.

C:\>dbmcli -d SDB -u superdba,<pw from target-system>

dbmcli on SDB>

C:\>dbmcli -d SDB -u superdba,<pw from source-system>

Error! Connection failed to node (local) for database SDB:

-24950,ERR_USRFAIL: User authorization failed

Best regards

Michael

[Former Member]

One way we have found is that if we match the superdba passwords on the source and target, it seems to work.

For that after changing the password of superdba on the source side, you need to take one more fresh backup and restore that one at the target.

OSS Note.1657257 refers to kind of similar errors.

Edited by: Srinivasa Bhatta on Mar 8, 2012 10:19 PM

[michael_lehmann]

Note 1657257 solved my problem.

Thanks to Srinivasa and Christian