Error during MaxDB upgrade from 7.3.00.42 to 7.5.00.32

[Former Member]

Hello all,

I am attempting to upgrade from MaxDB 7.3.00.42 to 7.5.00.32, as part of a migration from HP-UX 11.11 to Windows Server 2003. The MaxDB database supports a Content Server 6.30 application, and from what I have found so far, I need to upgrade/patch to 7.5.00.51 on the HP-UX server, before I can migrate using the loadercli (as per note 962019).

While performing the upgrade to 7.5.00.32 (following the steps in the Upgrade Guide to MaxDB 7.5), I receive the following error.

...

chperm 660 sdb:sdba /sapdb/data/config/SDB.mmm

user sdb can access /sapdb/data/config/SDB.mmm

remove /sapdb/data/wrk/dbmsrv.prt

remove /sapdb/data/wrk/SDB.knl

remove /sapdb/data/wrk/SDB.mdf

permissions for databases as of version 7.5.00 are used on your system

database owner is sdb

administrators group is sdba

owner of SDB is sdb (sdba sdba)

user_logon failed

Obviously there is a permissions problem of some kind, but I have not been able to pinpoint where. I allowed the DDUPDATE.SH script to create the user SDB, and it appears to have been created successfully and was used during the earlier steps of the upgrade script.

While working with SAP support I confirmed that I could connect to the database using the SDB user and I also executed the sdbverify, which completed successfully. As per the upgrade guide, I am logged in to HP-UX as root when running the upgrade (and when I ran sdbverify).

If anyone has suggestions on the cause of this error, I would greatly appreciate any assistance.

Best Regards,

Rusty Robbins

[Former Member]

Isn't that how it always goes...

I have been fighting this for 4-5 days, and had replied back and forth with support, with no luck on a resolution. But of course just as soon as I post my question here, support comes back with the answer!. I guess that just goes to show how good the SDN site is! 😜

Anyway, the answer to my problem was related to the group permissions on this HP-UX server. The ddupdate script did create the SDB user and set the primary group as SDBA, which normally would give the SDB user all rights for that group. However, in this case the error continued to occur, until I explicitly added the user SDB to group SDBA (at the request of SAP support). This upgrade step did finish successfully, and I am now continuing on with the other steps to migrate to Windows. Hopefully the rest of the steps will go smoother...

Regards,

Rusty Robbins