cancel
Showing results for 
Search instead for 
Did you mean: 

Unicode-Problem during backup from maxdb 7.6 and recover in 7.7

Former Member
0 Kudos

Hi,

I set up a new Database-Server with MaxDB 7.7 and I want to recover the Dump from my old Database-Server with MaxDB 7.6 (which is ASCII).

I get this error:

/opt/sdb/programs/bin/dbmcli on ACDB>recover_start ACDataC data

ERR

-24988,ERR_SQL: SQL error

-3068,Mismatch of parameter configuration between backup and instance

6,Data recovery failed

9,Only databackup from UNICODE databases are permitted to be recovered.

Servertask Info: because Error in backup task occured

Job 1 (Backup / Restore Medium Task) [executing] WaitingT88 Result=5224

Error in backup task occured, Error code 5224 "wrong_configuration"

but the new Database seems to be in ASCII:

/opt/sdb/programs/bin/dbmcli on ACDB>param_getvalue DEFAULT_CODE

OK

ASCII

/opt/sdb/programs/bin/dbmcli on ACDB>param_getvalue _UNICODE

OK

NO

/opt/sdb/programs/bin/dbmcli on ACDB>param_getvalue DefaultCodePage

OK

ASCII

What I did before was:

// CREATE A NEW EMPTY DATABASE

/opt/sdb/programs/bin/dbmcli -c db_create ACDB dbadmin,SECRET

// DEFINE A BACKUPTEMPLATE, SAME OPTIONS LIKE OLD 7.6 BACKUP

/opt/sdb/programs/bin/dbmcli -u dbadmin,SECRET -d ACDB medium_put ACDataC /path/to/backup/AC.dump FILE DATA 0 8 YES

// CONNECT TO NEW DATABASE VIA CONSOLE

/opt/sdb/programs/bin/dbmcli -u dbadmin,SECRET -d ACDB

// INIT PARAMETERS

param_startsession

param_init

param_commitsession

//IMPORT PARAMETERS FROM BACKUP

service_connect

recover_config ACDataC

service_release

//ACTIVATE DATABASE

db_admin

db_activate

db_activate DBM,SECRET

// RELOAD SYSTEM TABLES

load_systab

// SWITCH DB TO STATE ONLINE

db_online

so far in worked quite well.

then I copied the 7.6-backup file to /path/to/backup/AC.dump and tried to recover:

db_admin u2013f

util_connect

recover_start ACDataC data

--> Error-Message as above

So what can I do to switch to MaxDB 7.7 ?

Thanks a lot,

Oliver

Accepted Solutions (0)

Answers (1)

Answers (1)

former_member229109
Active Contributor
0 Kudos

Hello Oliver,

Are you SAP customer?

If yes => please review the SAP Note No. 744774 and SAP note:

129352 Homogeneous system copy with MaxDB (SAP DB)

Could you go with one of the following options:

1. Create the source database databackup;

Perform the source database migration iusing dbm command "db_migratecatalog";

< bring the database to offline first;

The catalog migration may take some time to complete. Make sure that the migration is not terminated.

After the migration will be finished successfuly, the database is in the "online" status and _UNICODE parameter value switched to YES >

Homogeneous databse copy using backup/restore...

2. Uninstall the target 7.7 database;

Unstall the target database instance 7.6 with _UNICODE - NO;

Perform Homogeneous database copy using backup/restore;

Perform the target database migration using "db_migratecatalog";

Upgrade the target database to 7.7;

?

What is your project in more details, if the recommended options are not working for you ?

Thank you and best regards, Natalia Khlopina

Former Member
0 Kudos

Hello Natalia,

thank you for your answer.

I made it the way you described in 1.

After restore (db_activate RECOVER ACDataC) I further had to do:


load_systab -u OLD_dba,secretpassword
db_online

But now there is another problem.

In the PHP-application, I get some unicode trash (instead of FALSE or TRUE) out of table colums actually containing BOOLEAN values:


Array
(
    [0] => Array
        (
           ....
            [KLASSIFIZIERUNGID] => 7
            [FIRMENEXPERTE] => Fû§
            [GEBURTSDATUM] => 2005-01-01

I expect FALSE but get something like Fâe¿, the F is always there, the rest is changing with every Request (F1/, Fû§, Fþ·a)

But in Database-Studio and isql the data is displayed correct.

So I tried to connect to the new Database-Server from the old Webserver and everything worked just fine.

The old Webserver is an 32 bit Suse 10.2 with php 5.2 (a VM-Ware virtual machine)

The new Webserver is running on the same Machine as the Database: 64 bit Debian 6 with php 5.3.

So I guess the problem is somewhere in ODBC or 64 Bit-PHP or is an issue with the PHP-Version.

So, have you ever encountered this strange issue?

The project in more details:

-a webbased Application for companies HR

-PHP5, Apache 2, MaxDB

-DB-connection is made via adodb and ODBC

-odbc.ini file on new server:


[ODBC]
Trace=No
TraceFile=/tmp/sql.log
ForceTrace=No
Pooling=No

[evint]
Driver=/opt/sdb/programs/lib/libsdbodbcw.so
Description=AllfieldCareerMaxDB
ServerNode=localhost
ServerDB=ACDB
FileUsage=1

janlars_goedtke
Active Participant
0 Kudos

Hi,

perhaps try the non-unicode driver?

Betriebssystem ODBC-Treiber/ASCII ODBC-Treiber/UNICODE

Microsoft Windows sqlod32.dll sqlod32w.dll

UNIX/Linux libsqlod.a|so libsqlodw.a|so

Regards Jan

Former Member
0 Kudos

same problem with the ASCII-odbc driver :o/

former_member229109
Active Contributor
0 Kudos

Hello Oliver,

1. Are you SAP customer?

2. Please post more details:

Source and target system :

sdbregview -l

< on the database server and application server >

OS of the database and application server

What application software are you using & how did you connect to the database?

3. Review Interfaces documentation at

http://maxdb.sap.com/doc/7_8/44/b7036935041388e10000000a155369/content.htm

Thank you and best regards, Natalia Khlopina

Former Member
0 Kudos

Hello Natalia,

1.) No, I'm not a SAP Customer, can you help anyway?

2.) application server and database server is the same machine


# /opt/sdb/programs/bin/sdbregview -l
WebSQL              /opt/sdb/programs    7.7.07.16               valid
Server Utilities    /opt/sdb/programs    7.7.07.16     64 bit    valid
DB Analyzer         /opt/sdb/programs    7.7.07.16     64 bit    valid
WebDAV Servlet      /opt/sdb/programs    7.7.07.16               valid
Base                /opt/sdb/programs    7.7.07.16     64 bit    valid
Redist Python       /opt/sdb/programs    7.7.07.16     64 bit    valid
JDBC                /opt/sdb/programs    7.6.06.05               valid
Messages            /opt/sdb/programs    MSG 0.8507              valid
ODBC                /opt/sdb/programs    7.7.07.16     64 bit    valid
Database Kernel     /opt/sdb/allfield    7.7.07.16     64 bit    valid
Loader              /opt/sdb/programs    7.7.07.16     64 bit    valid
SQLDBC              /opt/sdb/programs    7.7.07.16     64 bit    valid

OS: Debian 6.0.1

Linux version 2.6.32-5-amd64 (Debian 2.6.32-31)

CPU: Intel(R) Core(TM) i7 CPU 950 @ 3.07GHz (8 Cores)

RAM:8 GB

PHP Version 5.3.3-7+squeeze1

The aplication is our own PHP web application. The connection to the Database is made via the database abstraction library adodb (newest version from [http://adodb.sourceforge.net/|http://adodb.sourceforge.net/]) wich supports MaxDB connections via ODBC driver.

Here ist one more very simple example, of the problem:


select false from dual
->
Array
(
    [0] => FuFFFDOu2021 
)

3) Thank you for the URL, I'll have a look and play around a bit.

Former Member
0 Kudos

Hello,

for now I helped myself by patching the adodb library:

After the query check wich colums are of type boolean.

Then after each odbc_fetch_into() process the the boolean values of the result, e.g. check if it is a string an then check if the first character is a F or a T and set it the to 0 or 1 .

That works for me, without noticable performance loss.

But I don't really have a good feeling with this 'hack', I'd rather get clean data from ODBC.

So long, Cheers,

Oliver