Difference between revisions of "Bypasssing cross platform load issues"

Latest revision as of 11:18, 3 November 2012

When loading an ASE database dump made on another platform you may run into problems. For instance, this can happen when the dump is made on an Intel x86 platform but you want to load it into an ASE running on Solaris Sparc. As documented by Sybase, you need to prepare a dump for this situation before attempting to load it.

See: http://www.sybase.com/detail?id=1033627 or go straight to this whitepaper http://www.sybase.com/content/1033627/18XPDL_1253_WP.pdf

When you do not follow the required steps before making the database dump you may get this error:

Started cross-platform conversion for log records.
Msg 3151, Level 16, State 2:
Server 'TEST', Line 1:
Adaptive Server cannot load this database because the database that was dumped
was not quiescent when the dump was performed. Run sp_flushstats before DUMP
DATABASE and ensure that the database is not updated during the dump. 

Under some circumstances you may not want to follow the required steps and force ASE to bring the database online anyway. Below are the steps how you can do that. The name of database in the example is 'testdb'. You may run into some problems, see section below for solutions.

IMPORTANT This method may result in some loss of data or a an unusable database on the ASE where you load the database dump into. It's recommended to use it only for testing and query purposes.

Bypassing Msg 3151

After loading the database and Msg 3151 is reported follow these steps:

use master
go
sp_configure "allow updates",1
go
update sysdatabases set status = -32768,status3=131072 where name = "testdb"
go

Shutdown the server and start it up again.

A message in the errorlog indicates that recovery is not done for the database:

00:00000:00001:2011/04/05 16:07:54.38 server
*** Bypassing recovery of database id 4

Log on to ASE and rebuild the transaction log for the database

dbcc traceon(3604)
go
dbcc save_rebuild_log(testdb)
go
update sysdatabases set status = 0 where name = "testdb"
go

Shutdown the server and start it up again.

The database will now be brought online, watch the errorlog for any problems. Now the database should be recovered succesfully.

Log on to the server and:

update sysdatabases set status3=524288 where name = "testdb"
go
use testdb
go
sp_post_xpload
go
update sysdatabases set status3=0 where name = "testdb"
go

All done now, you should be able to use the database for querying data.

Problems and potential solutions

Transactionlog full during recovery

00:00000:00013:2011/04/05 16:18:00.14 server  Error: 1105, Severity: 17, State: 4
00:00000:00013:2011/04/05 16:18:00.14 server  Can't allocate space for object 'syslogs' in database 'testdb' because 'logsegment' segment is full/has no free extents. If you ran out of space in syslogs, dump the transaction log. Otherwise, use ALTER DATABASE to increase the size of the segment.
00:00000:00013:2011/04/05 16:18:00.14 server  This database requires upgrade, but its log is nearly full. Extend the log, or try 'DUMP TRAN testdb WITH NO_LOG', then retry ONLINE DATABASE.

Change the segment status for the database.

use master
go
update sysusages set segmap = 7 where dbid = db_id("testdb")
go

Now reload the database with the "load database" command and reboot ASE. Then:

use master
go
update sysdatabases
set status3 = status3 - 67108864,
status = -32768
where name = "testdb"
go

Stacktrace in modules make_log_consistent and rec_build_recovery_info

when an error in the errorlog appears like this:

00:00000:00001:2011/03/25 16:56:17.04 kernel  Current process (0x30003) infected with signal 11 (SIGSEGV)
00:00000:00001:2011/03/25 16:56:17.04 kernel  Address 0x00000000803b80fc (xls_open+0xdc), siginfo (code, address) = (1, 0x00000000000000ac)
00:00000:00001:2011/03/25 16:56:17.04 kernel  Saved signal context address 0x0000010001b08280
00:00000:00001:2011/03/25 16:56:17.04 kernel  pc=0x00000000803b80fc  npc=0x00000000803b8100
00:00000:00001:2011/03/25 16:56:17.04 kernel  g0-g2 0x0000000000000000 0x0000000000000008 0x00000000825fd000
00:00000:00001:2011/03/25 16:56:17.04 kernel  g3-g5 0x0000000000000038 0x0000000081b3f9d0 0x00000000000001c0
00:00000:00001:2011/03/25 16:56:17.04 kernel  g6-g7 0x0000000000000000 0xffffffff7eb00200
00:00000:00001:2011/03/25 16:56:17.04 kernel  o0-o2 0x0000000000000000 0x000001001c99e6c0 0x000001001c83ab50
00:00000:00001:2011/03/25 16:56:17.04 kernel  o3-o5 0x000001001d5dfc48 0x0000000000000000 0x0000000000000008
00:00000:00001:2011/03/25 16:56:17.04 kernel  o6-o7 0x0000010001b07e61 0x00000000803b80f4
00:00000:00001:2011/03/25 16:56:17.04 kernel  l0-l2 0x0000000080ddb5a0 0x00000000825c2c00 0x000001001e26a458
00:00000:00001:2011/03/25 16:56:17.04 kernel  l3-l5 0x0000000000000000 0x0000000004000000 0x00000000825fd000
00:00000:00001:2011/03/25 16:56:17.04 kernel  l6-l7 0x00000000822cc000 0x0000000004000000
00:00000:00001:2011/03/25 16:56:17.04 kernel  i0-i2 0x0000000000000001 0x0000000000000000 0x0000000000000001
00:00000:00001:2011/03/25 16:56:17.04 kernel  i3-i5 0x000001001e26a158 0x0000000000000104 0x0000000000000006
00:00000:00001:2011/03/25 16:56:17.04 kernel  i6-i7 0x0000010001b07f11 0x0000000080ddb5f0
00:00000:00001:2011/03/25 16:56:17.04 kernel  ************************************
00:00000:00001:2011/03/25 16:56:17.04 kernel  SQL causing error : use master
00:00000:00001:2011/03/25 16:56:17.04 kernel  ************************************
00:00000:00001:2011/03/25 16:56:17.04 server  SQL Text: use master
00:00000:00001:2011/03/25 16:56:17.04 kernel  curdb = 5 tempdb = 2 pstat = 0x1000
00:00000:00001:2011/03/25 16:56:17.04 kernel  lasterror = 0 preverror = 0 transtate = 1
00:00000:00001:2011/03/25 16:56:17.04 kernel  curcmd = 0 program =
00:00000:00001:2011/03/25 16:56:17.04 kernel  extended error information: hostname:  login:
00:00000:00001:2011/03/25 16:56:17.04 kernel  pc: 0x0000000080f412e4 pcstkwalk+0x24(0x0000010001b06fa0, 0x0000010001b04e18, 0x000000000000270f, 0x0000000000000002, 0x0000000000000000)
00:00000:00001:2011/03/25 16:56:17.04 kernel  pc: 0x0000000080f4112c ucstkgentrace+0x1d0(0x000001001d5dfc48, 0x0000000000000002, 0x000000000000270f, 0x0000000000000000, 0x0000000000000000)
00:00000:00001:2011/03/25 16:56:17.04 kernel  pc: 0x0000000080eccb5c ucbacktrace+0xb4(0x0000000000000000, 0x0000000000000001, 0x0000000000007c00, 0x000001001d5dfc48, 0x000001001df6d540)
00:00000:00001:2011/03/25 16:56:17.04 kernel  pc: 0x0000000080594f74 terminate_process+0x131c(0x0000000000007400, 0xffffffffffffffff, 0x000001001d5dfc48, 0x0000000000008000,  0x0000000081b2e588)
00:00000:00001:2011/03/25 16:56:17.04 kernel  pc: 0x0000000080f05c2c kisignal+0x27c(0x0000000000000058, 0x0000010001b08560, 0x0000010001b08280, 0x0000000000030003, 0x0000000000000000)
00:00000:00001:2011/03/25 16:56:17.04 kernel  pc: 0x00000000803b80fc xls_open+0xdc(0x0000000000000001, 0x0000000000000000, 0x0000000000000001, 0x000001001e26a158, 0x0000000000000104)
00:00000:00001:2011/03/25 16:56:17.04 kernel  [Handler pc: 0x0000000080de8c00 rec_handle installed by the following function:-]
00:00000:00001:2011/03/25 16:56:17.04 kernel  pc: 0x0000000080ddb5f0 make_log_consistent+0xd8(0x0000000000000005, 0x00000000825c1c00, 0x0000000000000005, 0x000001001e26a158,  0x0000000000000005)
00:00000:00001:2011/03/25 16:56:17.04 kernel  pc: 0x0000000080ddc4e4 rec_build_recovery_info+0xc7c(0x00000000000000f0, 0x0000000000000000, 0x0000000000008000, 0x0000000000008000, 0x000000000000c000)
00:00000:00001:2011/03/25 16:56:17.04 kernel  [Handler pc: 0x0000000080deccd0 rec__caller_hdlr installed by the following function:-]
00:00000:00001:2011/03/25 16:56:17.04 kernel  pc: 0x0000000080de0d98 dorecover+0x118(0x000001001d5dfc48, 0x0000000000001000, 0x0000000000008090, 0x0000000081b2e400, 0x0000000000000000)
00:00000:00001:2011/03/25 16:56:17.04 kernel  pc: 0x00000000805988d4 ds__recoverdbs+0x660(0x000001001d5dfc48, 0x00000000000094d8, 0x000001001c97efc0, 0x0000000000000001, 0x0000000081d58514)
00:00000:00001:2011/03/25 16:56:17.04 kernel  pc: 0x0000000080591438 dsinit+0xa80(0x000001000002ec98, 0x0000000081b2e400, 0x0000000000000001, 0x0000000000000032, 0x0000000081d58514)
00:00000:00001:2011/03/25 16:56:17.04 kernel  pc: 0x0000000080f57c0c _coldstart(0x0000000000000000, 0x00000000805909b8, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000)
00:00000:00001:2011/03/25 16:56:17.04 kernel  end of stack trace, spid 1, kpid 196611, suid 0

Then run these commands:

use master
go
update sysdatabases set status3 = 131072
where name = "testdb"
go

Reboot ASE, then

dbcc rebuild_log(testdb,1,1)
go
update sysdatabases set status = 0 where name = "testdb"
go

Reboot ASE once more.

Transactionlog full

When the database is accessible but the transactionlog becomes full, check the states:

use testdb
go
sp_helpsgement logsegment
go

When a negative value of free space is reported you may need to rebuild the transaction log.

dbcc save_rebuild_log(testdb)
go
use master
go
sp_dboption testdb,"single",true
go
use testdb
go
dbcc tablealloc(syslogs,full,fix)
go