Difference between revisions of "Bypasssing cross platform load issues"
From SybaseWiki
(Created page with '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…') |
|||
| Line 7: | Line 7: | ||
Started cross-platform conversion for log records. | Started cross-platform conversion for log records. | ||
Msg 3151, Level 16, State 2: | Msg 3151, Level 16, State 2: | ||
| − | Server ' | + | Server 'TEST', Line 1: |
Adaptive Server cannot load this database because the database that was dumped | 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 | was not quiescent when the dump was performed. Run sp_flushstats before DUMP | ||
| Line 14: | Line 14: | ||
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. | 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== | ==Bypassing Msg 3151== | ||
| + | After loading the database and Msg 3151 is reported follow these steps: | ||
| + | |||
| + | use master | ||
| + | go | ||
sp_configure "allow updates",1 | sp_configure "allow updates",1 | ||
go | go | ||
| Line 23: | Line 27: | ||
Shutdown the server and start it up again. | Shutdown the server and start it up again. | ||
| + | |||
A message in the errorlog indicates that recovery is not done for the database: | A message in the errorlog indicates that recovery is not done for the database: | ||
| − | |||
| − | |||
| − | Log on and rebuild the transaction log 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) | dbcc traceon(3604) | ||
go | go | ||
| Line 61: | Line 67: | ||
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. | 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") | update sysusages set segmap = 7 where dbid = db_id("testdb") | ||
go | go | ||
| Line 68: | Line 76: | ||
Now reload the database with the "load database" command and reboot ASE. Then: | Now reload the database with the "load database" command and reboot ASE. Then: | ||
| + | use master | ||
| + | go | ||
update sysdatabases | update sysdatabases | ||
set status3 = status3 - 67108864, | set status3 = status3 - 67108864, | ||
| Line 119: | Line 129: | ||
Then run these commands: | Then run these commands: | ||
| + | use master | ||
| + | go | ||
update sysdatabases set status3 = 131072 | update sysdatabases set status3 = 131072 | ||
where name = "testdb" | where name = "testdb" | ||
| Line 134: | Line 146: | ||
===Transactionlog full=== | ===Transactionlog full=== | ||
When the database is accessible but the transactionlog becomes full, check the states: | When the database is accessible but the transactionlog becomes full, check the states: | ||
| − | use testdb | + | use testdb |
| − | go | + | go |
| − | sp_helpsgement logsegment | + | sp_helpsgement logsegment |
| − | go | + | go |
When a negative value of free space is reported you may need to rebuild the transaction log. | When a negative value of free space is reported you may need to rebuild the transaction log. | ||
| Line 150: | Line 162: | ||
dbcc tablealloc(syslogs,full,fix) | dbcc tablealloc(syslogs,full,fix) | ||
go | go | ||
| + | |||
| + | [[category:ASE]] | ||
Revision as of 10:27, 31 August 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.
Contents
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
