upgrade question

[Former Member]

Hello,

I've some questions regarding our planned upgrade from 7.5.0.38 to latest 7.6.

We want to switch from rpm-based installation to the sdbinst version, and we're thinking of doing it this way:

1.) create a backup of current 7.5.0.38

2.) stop database

3.) delete all maxdb rpm's

4.) delete /var/opt/sdb and /opt/sdb

5.) install the latest 7.6 via sdbinst

6.) start database

7.) recover backup

Is this a common way for upgrading from 7.5 to 7.6, or are there some hints/missing steps ?

Furthermore I want to ask if there's a (public viewable) changelog between 7.5 and 7.6 ?

I could only find some links to SAP Marketplace or something like that, but we're no SAP customer...

many thanks in advance....GERD.....

[Former Member · Accepted solution]

Hello,

1)

backup restore from 7.5 to 7.6 will not work

2)

can you see upgrade documentation here?

http://maxdb.sap.com/doc/7_6/a2/f3f63def83c452e10000000a114084/frameset.htm

as non-SAP customer, "In-Place Migration with SDBINST " should be right for you

> Furthermore I want to ask if there's a (public viewable) changelog between 7.5 and 7.6 ?

-> as far as I know , no, pts database is best you can get

http://maxdb.sap.com/webpts

Regards

Ivan

[Former Member · Accepted solution]

Hello Ivan,

thanks for answering.

The "In-Place Migration" sounds good, but seems like we have to stick to the rpm-based installation (mentioned in the doc). This document referes to upgrade from 7.3 to 7.6 and install the target rpm's in parallel to the old ones.

I'm not sure if we should really install 7.6rpm's on top of the 7.5 ones ? I'd like to prevent a mix-up of binaries/libraries

Seems like there's no way to switch from rpm to sdbinst...?!?! create backup und restore it on 7.6 doesn't work at all ?!?

thanks in advance....GERD....

[lbreddemann · Accepted solution]

> 1)

> backup restore from 7.5 to 7.6 will not work

Hmm... well I just did it to try it out... worked

Ok, one thing is: we (SAP) don't support this. Period.

BUT (big one): since we did not change too much concerning the internal data structure, it's possible to perform such a backup/restore upgrade.

Of course there are several things to check and double check to make this work.

One example is to make sure that the database catalog is stored in UNICODE format.

Another important point is to manually reload the system tables after the restore.

So, if this would be my database, I'd just try it out first. If it works for your db - great.

regards,

Lars

p.s.

I'd be VERY careful of any custom db functions/procedures/trigger codings.

I highly doubt that they would properly survive the upgrade.

[Former Member · Accepted solution]

Hello Lars,

I followed your tip and tried recover a 7.5-backup in the newly installed 7.6-version.

Recovery worked, but I failed to run load_systab. Every time I got a "-24907,ERR_DBAWRONG: wrong SYSDBA".

I tried several user/pw combinations but with no luck......What's the default user/password after installing 7.6 (dbadmin/dbadmin, I guess) ?!?!

Here's the log of my attempts:

infra02:/ # dbmcli -d testdb -u dbm,dbm load_systab -u dbadmin,dbadmin -ud domain

ERR

-24907,ERR_DBAWRONG: wrong SYSDBA

infra02:/ # dbmcli -d testdb -u dbm,dbm load_systab -u dbadmin,dbadmin

ERR

-24907,ERR_DBAWRONG: wrong SYSDBA

infra02:/ # dbmcli -d testdb -u dbm,dbm load_systab -u dba,dba

ERR

-24907,ERR_DBAWRONG: wrong SYSDBA

infra02:/ # dbmcli -d testdb -u dbm,dbm load_systab -u dba,dba -ud domain

ERR

-24907,ERR_DBAWRONG: wrong SYSDBA

Right before creating the full backup in the 7.5 version I changed to password of the dba user to dba. Therefore I thought I have to type dba,dba as parameter for the load_systab command, seems like I'm on the wrong way...?!?!

I also wanted to try the rpm-upgrad, but I cannot find a download location for latest releases.

I only found a page at mysql with rpm's of version 7.6.00, hmmmm...

Where can I get the latest 64-bit rpm's ?

any help appreciated....GERD....

[lbreddemann · Accepted solution]

> I followed your tip and tried recover a 7.5-backup in the newly installed 7.6-version.

> Recovery worked, but I failed to run load_systab. Every time I got a "-24907,ERR_DBAWRONG: wrong SYSDBA".

> I tried several user/pw combinations but with no luck......What's the default user/password after installing 7.6 (dbadmin/dbadmin, I guess) ?!?!

The upgrade does of course not change the passwords!

And it doesn't set them back to some default.

> Here's the log of my attempts:

> -24907,ERR_DBAWRONG: wrong SYSDBA

> infra02:/ # dbmcli -d testdb -u dbm,dbm load_systab -u dba,dba -ud domain

> ERR

> -24907,ERR_DBAWRONG: wrong SYSDBA

This call should be the correct one, but the password for the dba user is wrong!

> Right before creating the full backup in the 7.5 version I changed to password of the dba user to dba. Therefore I thought I have to type dba,dba as parameter for the load_systab command, seems like I'm on the wrong way...?!?!

Ok, HOW did you change the password?

You have to be aware that the SYDBA user ('dba' in your case) is maintained in two user storages:

in the UPC (user profile container) for the DBM access (dbmcli, DBM GUI etc.)

and

in the SQL realm.

Both passwords need to be in synch.

Unfortunately it was possible to change only one of them in former versions and it looks like it's what you did here.

I hope you still remember the SQL password your 'dba' user had before.

Then you should be able to do this:

dbmcli -d testdb -u dbm,dbm
sql_connect superdba,<old pw>
sql_execute alter password superdba <new pw>
sql_release
load_systab -u superdba,<new pw> -ud domain 

> I also wanted to try the rpm-upgrad, but I cannot find a download location for latest releases.

> I only found a page at mysql with rpm's of version 7.6.00, hmmmm...

> Where can I get the latest 64-bit rpm's ?

There are no RPM based releases anymore.

And, btw., it wouldn't change a bit here.

It's the user authorization that is your problem right now, not the way the software is installed.

by the way: currently you should see the exact same problem on your source database.

Whenever you change the passwords for the SYSDBA, make sure to test whether load_systab still works!

regards,

Lars

[Former Member · Accepted solution]

Hello Lars,

thanks for your quick reply.

>

> Ok, HOW did you change the password?
> You have to be aware that the SYDBA user ('dba' in your case) is maintained in two user storages: 
> in the UPC (user profile container) for the DBM access (dbmcli, DBM GUI etc.)
> and
> in the SQL realm.
I modified the password in SQL-Studio-Session via alter password..., seem like this caused some problems...
> 
> There are no RPM based releases anymore.
O.K., good to know.
> regards,
> Lars

In the meantime I tried a different way of upgrading (upgrading the 7.5 without deinstalling the rpm's). Here's what I did:

alter password dba to dba (yes, in SQL-Studio-session)

/etc/init.d/maxdb stop

mkdir -p /var/opt/sdb/data/config/install

cd /incoming/maxdb-all-linux-64bit-x86_64-7_6_06_03

./SDBINST

existing updatable installation:

0: /opt/sdb/7500 7.5.0.38

1: none

please enter updatable installation id: 0

=> finish

dbmcli -d testdb -u dbm,dbm

dbmcli on testdb>version

OK

version,os,dbroot,logon,code,swap

"7.6.06","UNIX","/opt/sdb/7500",True,ASCII,2

dbmcli on testdb>db_online

dbmcli on testdb>load_systab -u dba,dba

OK

0,OK: everything works fine

Seems that it worked fine, but:

If I connect to the database with dbm-gui I get several errors if I want to open the tab sessions, activity, ... The error message tells me something about "...table not found. SCHEMA..."

I'm curious if I have a complete mixup-database now (parts from 7.5 and parts from 7.6), since the rundirectory is still /opt/sdb/7500 ....?!?!

Currently there are only some assumptions what to do, but no detailed plan.

Do you (or anybody else) see some mistakes in my steps from above ? Is this plan the preferred one over deleting the rpm's before installing 7.6 ?

many thanks in advance....GERD....

[lbreddemann · Accepted solution]

> In the meantime I tried a different way of upgrading (upgrading the 7.5 without deinstalling the rpm's). Here's what I did:

> alter password dba to dba (yes, in SQL-Studio-session)

> Seems that it worked fine, but:

The software upgrade did work fine.

But you should have used either SDBSETUP or SDBUPD to UPGRADE the database!

> If I connect to the database with dbm-gui I get several errors if I want to open the tab sessions, activity, ... The error message tells me something about "...table not found. SCHEMA..."

Sure it does run into such errors.

Hmm... what version of DBMGUI are you using?

After the loading of the system tables this should be OK...

> I'm curious if I have a complete mixup-database now (parts from 7.5 and parts from 7.6), since the rundirectory is still /opt/sdb/7500 ....?!?!

Hey, YOU chose the name of the dependend database path.

Nobody said: put the version number into this path.

The name of this path is really just a name - nonfunctional.

So it won't change if you upgrade.

> Currently there are only some assumptions what to do, but no detailed plan

The only problem you currently have is that somehow DBMGUI does not seem to see the correct version of the catalog views.

So I'd focus on that.

Do you get the same errors when using DB Studio?

regards,

Lars

[Former Member · Accepted solution]

Hello Lars,

>

> > In the meantime I tried a different way of upgrading (upgrading the 7.5 without deinstalling the rpm's). Here's what I did:
> > alter password dba to dba (yes, in SQL-Studio-session)
> 
> 
> > Seems that it worked fine, but:
> 
> The software upgrade did work fine.
> But you should have used either SDBSETUP or SDBUPD to UPGRADE the database!
O.K., I'll try that in the next run
> 
> > If I connect to the database with dbm-gui I get several errors if I want to open the tab sessions, activity, ... The error message tells me something about "...table not found. SCHEMA..."
> 
> Sure it does run into such errors.
> Hmm... what version of DBMGUI are you using?
> After the loading of the system tables this should be OK...
unfortunately not. I connected via DBMGUI after loading the system tables.
A first quick check with DB Studio produced no errors
> 
> > I'm curious if I have a complete mixup-database now (parts from 7.5 and parts from 7.6), since the rundirectory is still /opt/sdb/7500 ....?!?!
> 
> Hey, YOU chose the name of the dependend database path.
> Nobody said: put the version number into this  path.
> The name of this path is really just a name - nonfunctional.
> So it won't change if you upgrade.
not really, the rpm's did it for me 
> 
> Do you get the same errors when using DB Studio?
> 

I wanted to try that, but since the upgrade the server has a very poor performance and even on command line I have to wait minutes for a single statement.

Thereby i'm currently not able to try the DB Studio.

Furthermore I'm very interested what's going on on the server. It's a physical server only for testing this upgrade, no other services/app's running on it.

The only process which uses cpu/memory is kernel

After switching database to state db_offline everything went down to normal (the dbmcli call to put the database to db_offline lasted some minutes...?!?!):

OS: opensuse10.3 64bit

If I switch back to db_online it takes some time and then the system is unusable again. It looks like there is a massive writing to disk....vmstat shows 99..100 percent in state waiting

really strange....and I have no idea what to check further

any help appreciated..GERD..

[lbreddemann · Accepted solution]

> Furthermore I'm very interested what's going on on the server. It's a physical server only for testing this upgrade, no other services/app's running on it.

>

> The only process which uses cpu/memory is kernel

> After switching database to state db_offline everything went down to normal (the dbmcli call to put the database to db_offline lasted some minutes...?!?!):

>

> OS: opensuse10.3 64bit

>

> If I switch back to db_online it takes some time and then the system is unusable again. It looks like there is a massive writing to disk....vmstat shows 99..100 percent in state waiting

>

> really strange....and I have no idea what to check further

>

> any help appreciated..GERD..

Well, of course you should make sure that the db parameters are correclty set.

What does 'x_cons <SID> show ac ' tells you?

Since this is a completely different issue, you may open a new thread for it to keep the confusion small.

regards,

Lars

[markus_doehr2 · Accepted solution]

> The only process which uses cpu/memory is kernel

> After switching database to state db_offline everything went down to normal (the dbmcli call to put the database to db_offline lasted some minutes...?!?!):

"kernel" is the database engine - and yes, what you see is right and expected. You have to limit your CACHE_SIZE if the system is using all your memory and you don't want that.

Markus

[Former Member · Accepted solution]

Hello Lars, hello Markus,

thanks for your support.

I agree in opening a new thread for the performance topic.

I'll credit somepoints, but keep this thread in status open until I got a well performing 7.6 database

cu in the new thread ...

regards...GERD..