Uninitialized logical page after database load

[Former Member]

Hi Guys

I am struggling to restore a database to a new server. I have a brand new installation of ASE 16 on Windows server 2008. I have run the following commands:

disk init name ="TWSDEV1DB", physname="c:\sapdata\TWSDEV1DB.dbf", size="5000M"

go

disk init name ="TWSDEV1DBLOG", physname="c:\sapdata\TWSDEV1DBLOG.dbf", size="5000M"

go

sp_helpdevice

go

CREATE login cssdmw with password cssdmw;

Then I ran this....

CREATE DATABASE TWSDEV1DB on TWSDEV1DB  = "4250M"  for load;

go

ALTER DATABASE TWSDEV1DB for load;

go

load database TWSDEV1DB from 'compress::1::/temp/TWSDEV1DB.dmp_1409151614.sc'

stripe on 'compress::1::/temp/TWSDEV1DB.dmp_1409151614.sc1'

stripe on 'compress::1::/temp/TWSDEV1DB.dmp_1409151614.sc2'

stripe on 'compress::1::/temp/TWSDEV1DB.dmp_1409151614.sc3'

go

online database TWSDEV1DB

go

The online database is erroring with an Uninitialized logical page.

Any help would be welcome.

[former_member188958 · Accepted solution]

Hi David,

I don't think the fact that your database creation script probably doesn't match the original layout of the source database is causing this error.  You should be able to load any dump into a database that is the same size as the source regardless of layout (assuming same page size, character set, sort order, etc).  Matching the layout does make things "prettier" (log fragments end up on devices named "log...", etc, but the load should succeed and the database be functional regardless.

I agree with Jeff that the "with compression" option should be used in preference to the older "compress::" syntax.  The "with compression" feature is more flexible as the dump header and trailer can be read, the dump can be made to a remote backupserver, etc.

There is a known bug on 16.0 that results in this 692 error, which is CR 764402.  The error is specific to the use the "for load" option.  I recommend that you drop the database and create it without using "for load"; the process will take longer as it initializes every page, but it will avoid the bug.  A fix for the bug is expected in the 16.0 SP00 PL04 release (I don't have an expected date for it, but should be fairly near future).

Cheers,

-bret

[Former Member · Accepted solution]

Thanks Bret, very useful! I'm pretty certain about the other parameters so will give it a try. I'm out of the office for a few days now so will try later in the week.

Have a good weekend.

[Former Member · Accepted solution]

Hi

I tried this:

CREATE DATABASE TWSDEV1DB on TWSDEV1DB  = "4250M";

go

load database TWSDEV1DB from 'compress::1::/temp/TWSDEV1DB.dmp_1409151614.sc'

stripe on 'compress::1::/temp/TWSDEV1DB.dmp_1409151614.sc1'

stripe on 'compress::1::/temp/TWSDEV1DB.dmp_1409151614.sc2'

stripe on 'compress::1::/temp/TWSDEV1DB.dmp_1409151614.sc3'

go

online database TWSDEV1DB

go

The load was successful but said it would not bring the database online automatically, use online database.

The online database failed with

Uninitialised logical page..... object syslogs etc

[former_member188958 · Accepted solution]

Ok, well, that eliminates the theory that this is due to CR 764402.

[former_member188958 · Accepted solution]

There is a restriction documented under the LOAD DATABASE command in the ASE Reference Manual that you cannot load dumps earlier than 12.5.4 into 15.x.

load database

I don't recall any particular technical reason for it offhand, though.

[Former Member · Accepted solution]

Thanks Bret,

That's not quite what I wanted to hear but may explain my problem. I guess I'll have to raise a case to SAP support which leads to another problem.....

How do I get support for ASE Developer edition, I have a SID but ASE is not one of my supported products?

[former_member188958 · Accepted solution]

Is there any chance Replication is involved?

You might see if running the following command before doing the online database helps:

dbcc dbrepair(dbname, ltmignore)

[former_member188958 · Accepted solution]

Hi David,

Since the Developer edition is free, I doubt it comes with any formal support.  I'm not an expert on the licensing though.

However, given the current information, I'm sure the formal advice from support would be that you should first upgrade the dump by loading it into a 12.5.4 (preferably latest rollup) server, then dump that and load it into 15.x.  This might have to be done by the source of the dump; they probably have a support contract that would let them get the latest 12.5.4 rollup, I don't know whether you could.

-bret

[Former Member · Accepted solution]

Sadly not, db still wont come online. I think I'm going to use the 2 step process. 12.5.4 then to 16. I'll focus on getting a copy of 12.5.4.

Many thanks for all your help

[Former Member · Accepted solution]

Hi Bret

Just looking at the restrictions again it also says:

• You cannot load a dump that was made on a different platform.

Am I approaching this in the wrong way? I'm trying to migrate from AIX ASE12.5.3 to Windows ASE16. It was my understanding that the Load database would deal with the platform changes and indeed the messages imply that it is successful at that. But this restriction has set me wondering....

Is there another way I could approach this, baring in mind that these two databases are not electronically connected. The source has very restricted access so I am limited to what I can do at that end. I do not have AIX on my network, we are a windows house.

Edited:

Just realised that the document you linked was ASE15, Looking at ASE16 the cross platform restriction is not there:

SyBooks Online

The ASE12.5.4 restriction is still there, so I'm still wondering "is there another way?"

Message was edited by: David Peace

[former_member188958 · Accepted solution]

Hi David,

The "cannot load from another platform" was a doc bug in 15.x; the wording pre-existed the cross-platform dump and load (XPDL) functionality but didn't get removed in error when XPDL was added.

It might still be worth trying the load with a regular uncompressed 12.5.3, but if that doesn't work than I'd try upgrading the dump to 12.5.4.

-bret

[Former Member · Accepted solution]

Thanks Bret,

The company holding the source data has gone all procedural on me. We were working too well so they felt that we should slow down 😉

I will try the various other solutions when I get through the paperwork.

Cheers

[Former Member]

Ok, I have not got some more information about the source Database. This is version 12.5.3, the dump was created from that database and we are trying to load it into ASE16.

I asked for a create statement and tried using that which had the same error. Is there an issue moving from ASE 12.5 to 16 directly?

[former_member182259]

You created the database on the data device - but not log....and other things may not be lining up.  Best thing to do would be to:

load database TWSDEV1DB from 'compress::1::/temp/TWSDEV1DB.dmp_1409151614.sc'

stripe on 'compress::1::/temp/TWSDEV1DB.dmp_1409151614.sc1'

stripe on 'compress::1::/temp/TWSDEV1DB.dmp_1409151614.sc2'

stripe on 'compress::1::/temp/TWSDEV1DB.dmp_1409151614.sc3'

with listonly=create_sql

It will tell you the create database command to use to be able to load the database.    In addition, you are using the old/deprecated compression syntax.   You should use the 'with compression=###' option instead when dumping the database. 

[Former Member]

I got this....

Could not execute statement.

The dump image specified does not contain information for any of the

database devices. You can not generate creation scripts from this dump

image.

SQLCODE=3182

Server=ASE16DB, Severity Level=16, State=1, Transaction State=1, Line=1

Line 7

load database TWSDEV1DB from 'compress::1::/temp/TWSDEV1DB.dmp_1409151614.sc'

stripe on 'compress::1::/temp/TWSDEV1DB.dmp_1409151614.sc1'

stripe on 'compress::1::/temp/TWSDEV1DB.dmp_1409151614.sc2'

stripe on 'compress::1::/temp/TWSDEV1DB.dmp_1409151614.sc3' with listonly=create_sql

[former_member182259]

Ack!   May be due to the use of the deprecated/old style compression.

If you still have access to the original source where the dump was taken, issue:

sp_helpdb <dbname>

Where <dbname> is the name of the database the dump was from.  The second result set will show the list of devices and how much space was allocated on each - in order.    Use that output as the basis for your create database.

The create database DDL for the database you are loading the dump into has to match the create database DDL for the database of the dump - which is the source of your problem.   One other option vs. the above is if you are using SCC, if you right click on the database in the object browser, there should be a generate DDL option....

[Former Member]

Many thanks, I do not have access to the original database, but have gone back to the DBA and asked for the create database SQL. It's a very steep learning curve, just setting up our development environment.

Cheers