Error trying Unicode migration

[Former Member]

I'm trying to migrate a 7.6.06.03 instance to Unicode (in order to later migrate it to 7.7).

I run db_offline, and then db_migratecatalog. And then it hangs forever (db_migratecatalog never returns).

Last lines on knldiag say:

2009-07-21 19:08:11 7393 54000 OBJECT /opt/sdb/7606/lib/liboms

2009-07-21 19:08:11 7393 51382 MIGRAT MIGRATING ASCII CATALOG TO UNICODE

2009-07-21 19:08:12 7393 ERR 51105 AK CACHE AK00001.dmp written: 0

What is wrong?

Knldiag is on:

http://www.tecnova.com.br/maxdb/knldiag.gz

And complete data backup on:

http://www.tecnova.com.br/maxdb/backup_unicode.gz

Thanks!!!

[lbreddemann · Accepted solution]

Hi there,

I restored your backup, ran a load_systab and after bouncing the instance the db_migratecatalog.

Now the database catalog in stored in UNICODE and I didn't get the hanging or the AK.. dump.

Sorry - I can not reproduce this.

regards,

Lars

[Former Member · Accepted solution]

Thank you very much, Lars!

Seems that Natalia suceeded in reproducing the situation. Could it be differences on OS / Environment?

I'm runing on Linux CentOS 5.3 64 bits:

[root@SRVBackup ~]# uname -a

Linux SRVBackup 2.6.18-128.el5 #1 SMP Wed Jan 21 10:41:14 EST 2009 x86_64 x86_64 x86_64 GNU/Linux

In what environment did you suceed with db_migratecatalog?

[former_member229109 · Accepted solution]

Hello Victor,

Thank you for the additional tests & information given in the thread.

I discussed with Lars his tests internaly.Lars was running tests on Linux 32bit.

I was also able yesterday to run 'db_migratecatalog' on Linux 32 bit server after I restored your backup.

Do you have the Linux 32 bit server?

The case is reproduced on the local server, Linux 64bit :

>uname -a

Linux XXXXX 2.6.5-7.282-smp #1 XXXX x86_64 x86_64 x86_64 GNU/Linux

The 'db_migratecatalog' was hanging & AK dump was created.

I tried to drop triggers, but it didn't help. We will continue analysis internally &

the thread will be updated after that.

Best regards, Natalia Khlopina

[Former Member · Accepted solution]

Hi, Natalia.

I tried to do db_migratecatalog on a 32bit server, and it does not hang anymore, but fails with this error:

2009-07-29 14:46:18 2788 51382 MIGRAT MIGRATING ASCII CATALOG TO UNICODE

2009-07-29 14:46:19 2788 ERR 51105 AK CACHE AK00001.dmp written: 0

2009-07-29 14:46:19 2788 ERR 51382 MIGRAT MIGRATION FAILED WITH ERROR -9400

2009-07-29 14:46:19 2788 ERR 51080 SYSERROR -9400 AK Cachedirectory full

2009-07-29 14:46:19 2788 3 Admin Database state: OFFLINE

2009-07-29 14:46:19 2788 11560 COMMUNIC Releasing T207

2009-07-29 14:46:19 2788 12696 DBSTATE Change DbState to 'SHUTDOWN'(25)

2009-07-29 14:46:20 0 12845 DBSTATE Kernel exited normal

2009-07-29 14:46:20 0 12808 DBSTATE Flushing knltrace pages

2009-07-29 14:46:20 0 11560 COMMUNIC Releasing T68

2009-07-29 14:46:20 0 12696 DBSTATE Change DbState to 'OFFLINE '(29)

"uname -a" on this server is:

Linux SAPDB2 2.6.18-8.el5 #1 SMP Thu Mar 15 19:57:35 EDT 2007 i686 i686 i386 GNU/Linux

DATA_CACHE was set to 150000, and CAT_CACHE_SUPPLY to 100000.

In what environment did you succeed with the migration? (Distribution / Kernel Version...). If I could only suceed with this migration on a separate system prepared exclusively for this task, it would help me. I have other databases to migrate.

[former_member229109 · Accepted solution]

Hello Victor,

I run test on Linux 32 VM :

uname -a

Linux XXXX 2.6.18-128.1.10.el5 #1 XXXX EDT 2009 i686 i686 i386 GNU/Linux

Database version: 'X32/LINUX 7.6.06 Build 003-121-202-135'

I created the database instance & initialize the database parameters from your backup

< DBM Command 'recover_config "<medium-name>"'.

Database parameter CAT_CACHE_SUPPLY was set 200000.

But I changed the following database parameters:

CACHE_SIZE 50000

DATA_VOLUME_NAME_0001 DAT_UNICODE_0001

LOG_VOLUME_NAME_001 LOG_UNICODE_001

DIAG_HISTORY_PATH /sapdb/data/wrk/NLK/DIAGHISTORY

RUNDIRECTORY /sapdb/data/wrk/NLK

MAXUSERTASKS 20

Run param_checkall, the database parameter DATACACHE_RGNS was changed

< See param_getexplain DATACACHE_RGNS > & also KERNELVERSION => KERNEL 7.6.06 BUILD 003-121-202-135

And in dbm.utl has the information about restore of your backup & migration to Unicode with RC 0.:

2009-07-27 07:06:03 4A6DB44B0001 0000 IC1 CREATE INSTANCE WITH RESTORE DATA FR

OM '/sapdb/data/wrk/backup_unicode' FILE BLOCKSIZE 8 MEDIANAME 'INITIALBACKUP'

2009-07-27 07:06:33 4A6DB44B0001 0001 IC1 RETURNCODE 0;CREATE INSTANCE WIT

H RESTORE DATA FROM '/sapdb/data/wrk/backup_unicode' FILE BLOCKSIZE 8

2009-07-27 07:06:33 4A6DB44B0001 0002 TAP DATE.............. 2009-07-27

2009-07-27 07:06:33 4A6DB44B0001 0003 TAP TIME.............. 07:06:28

2009-07-27 07:06:33 4A6DB44B0001 0004 TAP SERVERDB.......... UNICODE

2009-07-27 07:06:33 4A6DB44B0001 0005 TAP SERVERNODE........ SRVBackup

2009-07-27 07:06:33 4A6DB44B0001 0006 TAP KERNEL VERSION.... Kernel 7.6.06

Build 003-123-202-135

2009-07-27 07:06:33 4A6DB44B0001 0007 TAP PAGES TRANSFERRED. 28920

2009-07-27 07:06:33 4A6DB44B0001 0008 TAP PAGES LEFT........ 0

2009-07-27 07:06:33 4A6DB44B0001 0009 TAP NO OF VOLUMES..... 1

2009-07-27 07:06:33 4A6DB44B0001 000A TAP MEDIA NAME........ INITIALBACKUP

2009-07-27 07:06:33 4A6DB44B0001 000B TAP TAPE NAME......... /sapdb/data/wrk/b

ackup_unicode

2009-07-27 07:06:33 4A6DB44B0001 000C TAP TAPE ERRORTEXT.... UNDEF

2009-07-27 07:06:33 4A6DB44B0001 000D TAP TAPE LABEL........ DAT_000000006

2009-07-27 07:06:33 4A6DB44B0001 000E TAP IS CONSISTENT..... TRUE

2009-07-27 07:06:33 4A6DB44B0001 000F TAP FIRST IO SEQUENCE. 667

2009-07-27 07:06:33 4A6DB44B0001 0010 TAP LAST IO SEQUENCE.. UNDEF

2009-07-27 07:06:33 4A6DB44B0001 0011 TAP DBSTAMP1 DATE..... 2009-07-21

2009-07-27 07:06:33 4A6DB44B0001 0012 TAP DBSTAMP1 TIME..... 19:17:38

2009-07-27 07:06:33 4A6DB44B0001 0013 TAP DBSTAMP2 DATE..... UNDEF

2009-07-27 07:06:33 4A6DB44B0001 0014 TAP DBSTAMP2 TIME..... UNDEF

2009-07-27 07:06:33 4A6DB44B0001 0015 TAP BD PAGE COUNT..... 28900

2009-07-27 07:06:33 4A6DB44B0001 0016 TAP TAPEDEVICES USED.. 1

2009-07-27 07:06:33 4A6DB44B0001 0017 TAP DB_IDENT.......... SRVBackup:UNICODE

20090721191738

2009-07-27 07:06:33 4A6DB44B0001 0018 TAP MAX USED DATA PNO. 0

2009-07-27 07:06:33 4A6DB44B0001 0019 TAP CONV PAGE COUNT... 16

2009-07-27 07:15:55 4A6DB69B0004 0000 RST RESTART

2009-07-27 07:15:56 4A6DB69B0004 0001 RST RETURNCODE 0;RESTART

2009-07-27 07:16:42 4A6DB6CA0005 0000 SHT SHUTDOWN

2009-07-27 07:18:17 4A6DB7290001 0000 REQ SET LOG WRITER OFF

2009-07-27 07:18:17 4A6DB7290001 0001 RET RETURNCODE 0;SET LOG WRITER OFF

2009-07-27 07:18:17 4A6DB7290002 0000 REQ MIGRATE TO UNICODE

2009-07-27 07:18:24 4A6DB7290002 0001 RET RETURNCODE 0;MIGRATE TO UNICODE

2009-07-27 07:18:30 4A6DB7360003 0000 SHT SHUTDOWN

2009-07-27 07:18:52 4A6DB74C0001 0000 REQ SET LOG WRITER ON

2009-07-27 07:18:52 4A6DB74C0001 0001 RET RETURNCODE 0;SET LOG WRITER ON

2009-07-27 07:18:52 4A6DB74C0002 0000 RST RESTART

2009-07-27 07:18:53 4A6DB74C0002 0001 RST RETURNCODE 0;RESTART

2009-07-27 07:26:18 4A6DB90A0003 0000 SHT SHUTDOWN

Thank you and best regards, Natalia Khlopina

[former_member229109 · Accepted solution]

Hello Victor,

The database developer did the analysis of the reported issue locally.

Please see more details in PTS 1189997 at http://www.sapdb.org/webpts.

You could also check in which version of the database the problem will be fixed later.

In current version of the database you could use given in PTS workaround to run the catalog migration to Unicode.

As workaround, you could use one of the following options:

A) set CATCACHE_MINSIZE to 507904

or

B) perform the migration using slowknl.

Both options tested locally as a workaround.

Please let us know, if you will have further database questions/problems to finish with catalog migration to Unicode.

Thank you and best regards, Natalia Khlopina

[Former Member · Accepted solution]

Didn't work with 507904, but worked with 5079040!

On 64 bits!

Thanks, Natalia!!!

[Former Member]

The AK00001.dmp file is here:

http://www.tecnova.com.br/maxdb/AK00001.dmp

We are not SAP costumers... we're using the Community Edition with our custom ERP software. Excellent product BTW, congratulations!

Thanks!

[simon_matter]

Hi,

I can not really help you but I had a similar problem and maybe you can check out this thread:

[|]

Unfortunately I couldn't make the migration work so we started with a new instance on 7.7 and did a DB copy on the application level.

Also with 7.7 we had (and still have) a number of issues, you may look at my other posts concerning this. We are also not SAP customers but use our own ERP software with the community version of MaxDB.

Regards,

Simon

Edited by: Simon Matter on Jul 22, 2009 8:53 AM

[Former Member]

Thank you very much, Simon!

Indeed, I've seen your previous post on this topic. I'm analyzing the possibilities... maybe it's not the time for this migration yet.

Any further comment from the gurus?

[former_member229109]

Hello Victor,

You posted data backup on:

http://www.tecnova.com.br/maxdb/backup_unicode.gz

I tried also to reproduce the problem on the local server.

When did you create the databackup of the nonunicode database?

< additional database logs will be helpful. See 2. >

I installed the database instance version 7.6.06.03, create the database instance with the

parameter's configuration from your backup < small adjustment for the rundirectory,

History & volumes location >, run recovery with initialization using your backup,

restarted the database, load system tables, stopped the database & run db_migratecatalog

=> case reproduced.

I will check it further localy.

1.

Could you also run the following steps in parallel & see if it's working::

The database version 7.6.06.03.

A) Stop the database. Change database parameter _UNICODE to NO

For example, using dbm command: param_directput _UNICODE NO

Restart the database in the admin mode & check the values of the database parameters

DEFAULT_CODE & _UNICODE in the knldiag file.

B) Initialize the database for the restore, for example, using DBMGUI and continue with restore of the databackup created before you run "db_migratecatalog" first time.

C) Restart the database & load system tables.

D) Run the database "check data"< Verify >.

Check the BAD INDIZES if the new has to be recreated.

E) How many tables & views do you have in the database?

< Run as SYSDBA user SQL statements:

select * from users

select count(*) from tables where owner='<user>'

select count(*) from views

select TRIGGERNAME from triggers >

F) Bring the database in offline:

dbmcli -d UNICODE -u dbm,<pwd> db_offline

Increase the database parameter CAT_CACHE_SUPPLY.

Migrate the database catalog to UNICODE:

dbmcli -d UNICODE -u dbm,<pwd> db_migratecatalog

2.

Please give the links to the database log files: knldiag.err, dbm.prt, dbm.knl, dbm.utl

Please post the output of the command: uname -a

3.

You could migrate from an ASCII to a Unicode database is by using the loader.

Thank you and best regards, Natalia Khlopina

Edited by: Natalia Khlopina on Jul 23, 2009 4:49 PM

[former_member229109]

Hello Victor,

as I wrote you, the case was reproduced localy & the we will update the thread after the analysis will be done by developer.

Thank you and best regards, Natalia Khlopina

[Former Member]

Natalia,

Thank you very much for your attention!

I followed the steps you suggested:

Created a new database (with UNICODE=NO), restored my backup and loaded system tables. Then:

[root@SRVBackup data]# cat /var/opt/sdb/data/wrk/TEST/knldiag | egrep "DEFAULT_CODE=|UNICODE="

2009-07-28 14:11:40 3327 20235 RTE DEFAULT_CODE=ASCII

2009-07-28 14:11:40 3327 20235 RTE _UNICODE=NO

/opt/sdb/programs/bin/dbmcli on TEST>db_execute CHECK DATA

OK

---

[root@SRVBackup data]# cat /var/opt/sdb/data/wrk/TEST/knldiag.err | grep 2009

2009-07-28 14:07:50 --- Starting GMT 2009-07-28 17:07:50 7.6.06 Build 003-123-202-135

2009-07-28 14:11:37 ___ Stopping GMT 2009-07-28 17:11:37 7.6.06 Build 003-123-202-135

2009-07-28 14:11:40 --- Starting GMT 2009-07-28 17:11:40 7.6.06 Build 003-123-202-135

(no errors)

select username from users:

DBM

DBSERVICE

DBA

select count(*) from tables where owner='DBA':

1218

select count(*) from views:

210

select TRIGGERNAME from triggers:

TQUERYREWRITERULES

SYSUPDATECOUNTERWANTED_INSERT

SYSUPDSTATWANTED_DELETE

SYSUPDSTATWANTED_INSERT

(set DATA_CACHE to 300.000, CAT_CACHE_SUPPLY to 200.000)

/opt/sdb/programs/bin/dbmcli on TEST>db_offline

OK

---

/opt/sdb/programs/bin/dbmcli on TEST>db_migratecatalog

And, now, the command hangs forever, process "kernel" is using 100% CPU, and knldiag.err shows:

2009-07-28 14:30:00 5753 ERR 51105 AK CACHE AK00001.dmp written: 0

[Former Member]

The diagnostic files asked are on:

http://www.tecnova.com.br/maxdb/diagnostic_files.tar.gz

And the output of uname -a is:

Linux SRVBackup 2.6.18-128.el5 #1 SMP Wed Jan 21 10:41:14 EST 2009 x86_64 x86_64 x86_64 GNU/Linux