數(shù)據(jù)庫日志文件丟失，怎么能讀取數(shù)據(jù)

andkylee

建議使用dbcc rebuild_log命令，在執(zhí)行dbcc rebuild_log之前，先找一個(gè)log設(shè)備文件。
這個(gè)log設(shè)備文件可以通過新建一個(gè)數(shù)據(jù)庫獲得，前提是你知道數(shù)據(jù)庫原來的分配情況。
如果dbcc　save_rebuild_log， dbcc　rebuild_log都不行的話。 我看你需要嘗試非常規(guī)恢復(fù)工具了。 我自己編寫了一個(gè)從設(shè)備文件提取數(shù)據(jù)的工具。

Eisen

另外create了一個(gè)庫，然后load以前dump出的備份，就用這個(gè)log唄

sl0325

謝謝andkylee，Eisen的幫助，兩種方式都嘗試了，但還是報(bào)錯(cuò)：

00:00000:00001:2011/12/22 16:06:48.57 server  Started estimating recovery log boundaries for database 'bsrun201112'.
00:00000:00001:2011/12/22 16:06:48.60 server  Starting diagnostics for read failure:
00:00000:00001:2011/12/22 16:06:48.60 server  Device Information:
                                 Device number = 8
                                 Phyname = /opt/hisdata/bsrun4.dat
00:00000:00001:2011/12/22 16:06:48.60 server  Buffer Information:
                                 Buf addr = 0x0x40b629200, Mass addr = 0x0x40b629200
                                 Buf pageno = 25465968, Mass pageno = 25465968, dbid = 4
00:00000:00001:2011/12/22 16:06:48.60 server  
                                 Buf virtpg = 25465968, Mass virtpg = 2425968
                                 Buf stat = 0x1, Mass stat = 0x1008
                                 Mass keep = 1, Mass awaited = 0
00:00000:00001:2011/12/22 16:06:48.60 server  Page Information from first read attempt: Page read from disk ppageno = 28025968, pptnid = 1409437064, pindid = 0 pnextpg = 28025958, pprevpg = 27980487 plevel = 0, pstat = 0x11 pts_hi = 2, pts_lo = 621732403
00:00000:00001:2011/12/22 16:06:48.60 server  Page Information from second read attempt: Page read from disk ppageno = 28025968, pptnid = 1409437064, pindid = 0 pnextpg = 28025958, pprevpg = 27980487 plevel = 0, pstat = 0x11 pts_hi = 2, pts_lo = 621732403
00:00000:00001:2011/12/22 16:06:48.60 server  SDES Information:
                                 dbid = 4, objid = 8, sptnid = 8 scur.pageid = 25465968
                                 sstat = 0x4001, sstat2 = 0x4000000
                                 suid = 1, cacheid = 0
00:00000:00001:2011/12/22 16:06:48.60 server  PSS Information:
                                 pstat = 0x1000, pcurdb = 4, pspid = 1
                                 p2stat = 0x1110, p3stat = 0x10000804
                                 plasterror = 0, preverror = 0, pattention = 0
00:00000:00001:2011/12/22 16:06:48.60 server  End diagnostics for read failure:
00:00000:00001:2011/12/22 16:06:48.60 kernel  pc: 0x00000000012fcd13 pcstkwalk+0x323()
00:00000:00001:2011/12/22 16:06:48.60 kernel  pc: 0x00000000012fc7c0 ucstkgentrace+0x170()
00:00000:00001:2011/12/22 16:06:48.60 kernel  pc: 0x0000000001295fa9 ucbacktrace+0x69()
00:00000:00001:2011/12/22 16:06:48.60 kernel  pc: 0x0000000000971b1d wrongpage__print_diagnostic+0x2ed()
00:00000:00001:2011/12/22 16:06:48.60 kernel  pc: 0x0000000000971086 wrongpage+0x2c6()
00:00000:00001:2011/12/22 16:06:48.60 kernel  pc: 0x000000000096ddad getpage_with_validation+0xbed()
00:00000:00001:2011/12/22 16:06:48.60 kernel  pc: 0x0000000000972083 getrow+0x43()
00:00000:00001:2011/12/22 16:06:48.60 kernel  pc: 0x00000000009a2f1f apl__startscan+0x14ef()
00:00000:00001:2011/12/22 16:06:48.60 kernel  pc: 0x00000000009a12f1 startptnscan+0x381()
00:00000:00001:2011/12/22 16:06:48.60 kernel  pc: 0x00000000009b8b32 xsc__syslogs_setscan+0x1b2()
00:00000:00001:2011/12/22 16:06:48.60 kernel  pc: 0x00000000009b82f8 xls_startscan+0x178()
00:00000:00001:2011/12/22 16:06:48.60 kernel  pc: 0x000000000093c0e3 ckpt_get_record+0x53()
00:00000:00001:2011/12/22 16:06:48.60 kernel  [Handler pc: 0x0x0000000000a857f0 rec_handle installed by the following function:-]
00:00000:00001:2011/12/22 16:06:48.60 kernel  pc: 0x0000000000a81aaa rec_logbounds+0x2ba()
00:00000:00001:2011/12/22 16:06:48.60 kernel  [Handler pc: 0x0x0000000000a857f0 rec_handle installed by the following function:-]
00:00000:00001:2011/12/22 16:06:48.60 kernel  pc: 0x0000000000a7f995 recovery+0x4a5()
00:00000:00001:2011/12/22 16:06:48.60 kernel  pc: 0x0000000000a7c7ce boot__recover_and_online+0xae()
00:00000:00001:2011/12/22 16:06:48.60 kernel  [Handler pc: 0x0x0000000000a89940 rec__caller_hdlr installed by the following function:-]
00:00000:00001:2011/12/22 16:06:48.60 kernel  pc: 0x0000000000a7e909 rec__boot_recover_dbs+0xe9()
00:00000:00001:2011/12/22 16:06:48.60 kernel  pc: 0x0000000000a7abd3 rec_run_parallel_recovery+0x2d3()
00:00000:00001:2011/12/22 16:06:48.60 kernel  [Handler pc: 0x0x0000000000a89940 rec__caller_hdlr installed by the following function:-]
00:00000:00001:2011/12/22 16:06:48.60 kernel  pc: 0x0000000000a7e424 dorecover+0x174()
00:00000:00001:2011/12/22 16:06:48.60 kernel  pc: 0x0000000000727b2d ds__recoverdbs+0x52d()
00:00000:00001:2011/12/22 16:06:48.60 kernel  pc: 0x00000000007214d7 dsinit+0xad7()
00:00000:00001:2011/12/22 16:06:48.60 kernel  end of stack trace, spid 1, kpid 196611, suid 0
00:00000:00001:2011/12/22 16:06:48.61 server  Error: 695, Severity: 21, State: 1
00:00000:00001:2011/12/22 16:06:48.61 server  An attempt was made to read logical page '25465968' for database 'bsrun201112' (4), object 'syslogs' (, index 'syslogs' (0), partition 'syslogs_8' ( from disk. Wrong logical page '28025968' was brought into cache 'default data cache'.
00:00000:00001:2011/12/22 16:06:48.62 server  Error: 3414, Severity: 21, State: 1
00:00000:00001:2011/12/22 16:06:48.62 server  Database 'bsrun201112' (dbid 4): Recovery failed. Check the ASE errorlog for further information as to the cause.
00:00000:00001:2011/12/22 16:06:48.62 server  Recovery has restored the value of 'local async prefetch limit' for '16K' pool in 'default data cache' from '80' to 'DEFAULT'.
00:00000:00001:2011/12/22 16:06:48.62 server  Recovery has restored the value of 'local async prefetch limit' for '2K' pool in 'default data cache' from '80' to 'DEFAULT'.
00:00000:00001:2011/12/22 16:06:49.17 server  Bufunhash: Buffer 0x40b629200 from database id 4 has page number 28025968
in the page header and page number 25465968 in the buffer header. Buffer will be unhashed,
no action is necessary. Printing headers for diagnostics:
00:00000:00001:2011/12/22 16:06:49.17 server  Mass: 0x0x40b629200 Buffer: 0x0x40b629200
-Mass pgno: 25465968 vdev: 8 virtpg: 2425968 dbid: 4 stat: 0x4001000 keep: 0 awaited: 0
tripsleft: 0, flushseq: 0 dirty seq: 0 filthyseq: 0
-Buf pgno: 25465968 vdev: 8 virtpg: 2425968 stat: 0x1 bpage: 0xbabbd000 linked: ( lru)
00:00000:00001:2011/12/22 16:06:49.17 server  Page: 0x3babbd000 pageno: 28025968 objid: 1409437064 indid: 0
- nextpg: 28025958 prevpg: 27980487 pstat: 0x11 ts: (2, 621732403) nextrno: 10
- freeoff: 1503 minlen: 96 level: 0

想請教高手和版主們可以使用powersybedit來恢復(fù)嗎？還要哪里可以下載到powersybedit軟件？

hobbylu

用powersybedit恢復(fù)太復(fù)雜，你的數(shù)據(jù)設(shè)備是好的，應(yīng)該通過某些手段可以恢復(fù)。

Eisen

懷疑你的dbcc rebuild_log做法有問題，請貼出你詳細(xì)的dbcc rebuild_log的步驟

sl0325

我使用了兩種方法準(zhǔn)備恢復(fù)用的庫，1.重新建立一個(gè)設(shè)備名稱，數(shù)量，大小一樣的空庫，然后拷貝數(shù)據(jù)設(shè)備文件去覆蓋，用來恢復(fù)。2.建立一個(gè)設(shè)備名稱，數(shù)量，大小一樣的空庫，還原上個(gè)月的備份，然后拷貝數(shù)據(jù)文件去覆蓋，用來恢復(fù)。
具體的恢復(fù)語句如下：
啟動數(shù)據(jù)庫服務(wù)
1>sp_role "grant","sybase_ts_role",sa
2>go
1>sp_configure "allow updates",1
2>go
1>update master..sysdatabases set status=-32768 where name="bsrun201112"
2>go
1>shutdown with nowait
2>go
啟動數(shù)據(jù)庫服務(wù)
1>dbcc rebuild_log(bsrun201112,1,1)
2>go
報(bào)kernel setting console to nonblocking mode.failed attempt to remove old log extents.
1>shutdown with nowait
2>go
啟動數(shù)據(jù)庫服務(wù)
1>update master..sysdatabases set status=0 where name="bsrun201112"
2>go
1>sp_configure "allow updates",0
2>go
重啟數(shù)據(jù)庫服務(wù)
查看系統(tǒng)啟動日志，就報(bào)13樓貼得日志錯(cuò)誤。
請版主和高手們看看，做的步驟有什么問題嗎？

Eisen

1. 報(bào)kernel setting console to nonblocking mode.failed attempt to remove old log extents.

復(fù)制代碼

果然是rebuild_log有錯(cuò)。檢查一下你的db instance用戶對那個(gè)log device的權(quán)限是否正確。

hobbylu

最關(guān)鍵的問題，它的數(shù)據(jù)庫不能進(jìn)入bypass模式，無法使用dbcc rebuild_log

Eisen

那么反其道而行之……將其data segment設(shè)備用dd覆蓋到另外的備份庫上，再rebuild log那個(gè)備份庫，估計(jì)也好試試。
前陣子剛這樣救了一個(gè)備份服務(wù)壞掉的系統(tǒng)。

andkylee

Eisen 發(fā)表于 2011-12-26 13:41
那么反其道而行之……將其data segment設(shè)備用dd覆蓋到另外的備份庫上，再rebuild log那個(gè)備份庫，估計(jì)也好試 ...

我認(rèn)為Eisen的方法很值得嘗試。
數(shù)據(jù)庫的dbtable信息放在第一個(gè)allocation單元上，
你可以嘗試將恢復(fù)庫的第一allocation單元抽取出來，然后覆蓋到現(xiàn)有的數(shù)據(jù)設(shè)備文件的第一個(gè)allocation單元。
然后再使用現(xiàn)有的數(shù)據(jù)設(shè)備文件覆蓋恢復(fù)庫的設(shè)備文件，

要做好相應(yīng)的設(shè)備的備份！