Problems with DB copy for old release 7.4

[Former Member]

Dear all,

I wanted to perform DB copy from production to test system. Both are 7.4.0.35 version. SAP release is 45B. I know that this is no more supported, but please advice if possible.

1. I shut down the application server and DB of QAS

2. I deleted data volumes in sapdata

3. I copied data volumes from snapshot of PRD system

4. I set database to admin mode and cleared logfile

5. I started the database and it went online

I tried to load system tables with command

dbmcli -d <database_name> -u <dbm_user>,<password> load_systab -u <sysdba_user>,<password>

But I got:

ERR

-24907,ERR_DBAWRONG: wrong SYSDBA

R3trans shows following:

R3trans -d

This is R3trans version 6.05 (release 45B - 16.09.03 - 17:30:00).

2EETW169 no connect possible: "DBMS = ADABAS --- DBNAME = ''"

R3trans finished (0012).

more trans.log

4 ETW000 R3trans version 6.05 (release 45B - 16.09.03 - 17:30:00).

4 ETW000 ===============================================

4 ETW000

4 ETW000 control file: <no ctrlfile>

4 ETW000 R3trans was called as follows: R3trans -d

4 ETW000 date&time : 07.05.2009 - 13:55:11

4 ETW000 trace at level 2 opened for a given file pointer

4 ETW000 [developertrace,0] Thu May 7 13:55:11 2009 175 0.000175

4 ETW000 [developertrace,0] Loading library '/usr/sap/TSH/SYS/exe/run/dbadaslib.so' ...

4 ETW000 19 0.000194

4 ETW000 [developertrace,0] load shared library (/usr/sap/TSH/SYS/exe/run/dbadaslib.so), hdl 0

4 ETW000 1988 0.002182

4 ETW000 [developertrace,0] Library '/usr/sap/TSH/SYS/exe/run/dbadaslib.so' loaded

4 ETW000 14 0.002196

4 ETW000 [developertrace,0] function DbSlExpFuns loaded from library /usr/sap/TSH/SYS/exe/run/dbadaslib.so

4 ETW000 18 0.002214

4 ETW000 [developertrace,0] Version of '/usr/sap/TSH/SYS/exe/run/dbadaslib.so' is '45B.01'

4 ETW000 71 0.002285

4 ETW000 [developertrace,0] function dsql_db_init loaded from library /usr/sap/TSH/SYS/exe/run/dbadaslib.so

4 ETW000 10 0.002295

4 ETW000 [developertrace,0] function dbdd_exp_funs loaded from library /usr/sap/TSH/SYS/exe/run/dbadaslib.so

4 ETW000 1393 0.003688

4 ETW000 [developertrace,0] New connection 0 created 129 0.003817

4 ETW000 [developertrace,0] db_con_connect (con_name=R/3) 23 0.003840

4 ETW000 [developertrace,0] Begin DbSlConnect to database ADABAS for R/3

4 ETW000 20 0.003860

4 ETW000 [developertrace,0] DBADASLIB : version 45B.01, patch 898

4 ETW000 13 0.003873

4 ETW000 [developertrace,0] INFO : ADABAS statement length = 28672

4 ETW000 23 0.003896

4 ETW000 [developertrace,0] SQLADIAG=ada_w20303.dia 440 0.004336

4 ETW000 [developertrace,0] INFO : SQLOPT= -I 0 -t 0 19 0.004355

4 ETW000 [developertrace,0] Precompiler Runtime : C-PreComp 7.3.0 Build 050-100-073-424

4 ETW000 126651 0.131006

4 ETW000 [developertrace,0] Thu May 7 13:55:13 2009 1009642 1.140648

4 ETW000 [dbslada.,5962] *** ERROR => Couldn't get database version : sqlcode=-4008

4 ETW000 18 1.140666

4 ETW000 [ ,597] ***LOG BY2=>sql error -4008 performing CON

4 ETW000 75 1.140741

4 ETW000 [ ,597] ***LOG BY0=> 8 1.140749

2EETW169 no connect possible: "DBMS = ADABAS --- DBNAME = ''"

simple SQL statement:

sqlcli -U DEFAULT

Welcome to the MaxDB interactive terminal.

Type: \h for help with commands

\q to quit

sqlcli=> select * from usr02

• -4008: POS(1) Message not available SQLSTATE: 08004

• -4008: POS(1) Message not available SQLSTATE: 08004

user_getall

OK

CONTROL

SUPERDBA

DOMAIN

---

Please help/

[lbreddemann · Accepted solution]

> 1. I shut down the application server and DB of QAS

> 2. I deleted data volumes in sapdata

> 3. I copied data volumes from snapshot of PRD system

> 4. I set database to admin mode and cleared logfile

> 5. I started the database and it went online

That procedure is exactly where your problem comes from.

Just copying data volumes is not supported for MaxDBs.

A much better approach is to simply perform a data backup on the source system (you can do that online, no downtime required!) and then run a recovery with initialization on the target system

If you want to you can also reconfigure the volumes of the target instance by choosing "Instance -> Initialize" and "Initialize for Recovery" before actually recovering the database.

That procedure will prevent he problem you're facing right now.

It's even documented in note

#129352 Homogeneous system copy with MaxDB (SAP DB)

> I tried to load system tables with command

> dbmcli -d <database_name> -u <dbm_user>,<password> load_systab -u <sysdba_user>,<password>

>

> But I got:

>

> ERR

> -24907,ERR_DBAWRONG: wrong SYSDBA

Basically the problem here is that for the target instances still the old user profile containers are present.

Initialize the instance and recover it to get rid of that.

> R3trans shows following:

>

> R3trans -d

> This is R3trans version 6.05 (release 45B - 16.09.03 - 17:30:00).

> 2EETW169 no connect possible: "DBMS = ADABAS --- DBNAME = ''"

> R3trans finished (0012).

>

> more trans.log

> 4 ETW000 R3trans version 6.05 (release 45B - 16.09.03 - 17:30:00).

> 4 ETW000 [dbslada.,5962] *** ERROR => Couldn't get database version : sqlcode=-4008

> 4 ETW000 18 1.140666

> 4 ETW000 [ ,597] ***LOG BY2=>sql error -4008 performing CON

> 4 ETW000 75 1.140741

Yep, the logon data are wrong.

>

> simple SQL statement:

>

> sqlcli -U DEFAULT

>

> Welcome to the MaxDB interactive terminal.

>

> Type: \h for help with commands

> \q to quit

>

> sqlcli=> select * from usr02

> * -4008: POS(1) Message not available SQLSTATE: 08004

> * -4008: POS(1) Message not available SQLSTATE: 08004

And still wrong here as well.

Make sure to update the XUSER data!

>

>

> user_getall

> OK

> CONTROL

> SUPERDBA

> DOMAIN

This lists the content of the UPC files (search for UPC in the SDN MaxDB Wiki to learn more about that).

These are DBM Users - not the SQL Users R3trans and the workprocesses or sqlcli would need.

So, one step after the other.

Do the system copy as described above (or read the note) and you'll be fine afterwards.

regards,

Lars (yes, I'm the guy from the support message )

[Former Member]

Standard way worked fine. Thank you.

[Former Member]

I found something else, I dont know it this could be a problem:

source system:

dbmcli on DBPRH13 : PRH>param_getvolsall

OK

LOG_MIRRORED NO

MAXARCHIVELOGS 2

MAXDATADEVSPACES 10

ARCHIVE_LOG_001 512000 F /sapdb/PRH/saplog/DISKL001

DATADEV_0001 2560000 F /sapdb/PRH/sapdata/DISKD0001

DATADEV_0002 2560000 F /sapdb/PRH/sapdata/DISKD0002

DATADEV_0003 2560000 F /sapdb/PRH/sapdata/DISKD0003

DATADEV_0004 2560000 F /sapdb/PRH/sapdata/DISKD0004

DATADEV_0005 2560000 F /sapdb/PRH/sapdata/DISKD0005

DATADEV_0006 2560000 F /sapdb/PRH/sapdata/DISKD0006

DATADEV_0007 2560000 F /sapdb/PRH/sapdata/DISKD0007

DATADEV_0008 2560000 F /sapdb/PRH/sapdata/DISKD0008

target system:

dbmcli on DBTSH12 : TSH>param_getvolsall

OK

LOG_MIRRORED NO

MAXARCHIVELOGS 2

MAXDATADEVSPACES 10

ARCHIVE_LOG_001 512000 F /sapdb/TSH/saplog/DISKL001

DATADEV_0001 2560000 F /sapdb/TSH/sapdata/DISKD0001

DATADEV_0002 2560000 /sapdb/TSH/sapdata/DISKD0002

DATADEV_0003 2560000 F /sapdb/TSH/sapdata/DISKD0003

DATADEV_0004 2560000 F /sapdb/TSH/sapdata/DISKD0004

DATADEV_0005 2560000 F /sapdb/TSH/sapdata/DISKD0005

DATADEV_0006 2560000 F /sapdb/TSH/sapdata/DISKD0006

DATADEV_0007 2560000 F /sapdb/TSH/sapdata/DISKD0007

DATADEV_0008 2560000 F /sapdb/TSH/sapdata/DISKD0008

There is no type specified for volume DATADEV_0002

Is it possible to set it somehow via param_directput ????

[Former Member]

Hello Markus,

I use the same password as I have on source system,

Pavol

[markus_doehr2]

> 1. I shut down the application server and DB of QAS

> 2. I deleted data volumes in sapdata

> 3. I copied data volumes from snapshot of PRD system

> 4. I set database to admin mode and cleared logfile

> 5. I started the database and it went online

This is not a preferred way of doing copies but as long as the structure is the same it will work.

>

> I tried to load system tables with command

> dbmcli -d <database_name> -u <dbm_user>,<password> load_systab -u <sysdba_user>,<password>

>

> But I got:

>

> ERR

> -24907,ERR_DBAWRONG: wrong SYSDBA

So the source database/snapshot has a different password for the <sysdba> user.

Markus