sybase增量備份和恢復(fù)的問題

zy407321952

sybase11.0.3   想用增量備份試一下，sybase增量備份要先做一下全備，備份過程沒問題，但是恢復(fù)的時(shí)候有個(gè)問題：
load tran testdbs from '/day/test.bak'
go
提示錯(cuò)誤信息：
Msg 4305, Level 16, State 1:
Line 1:
Specified file 'dump device' is out of sequence. Current time stamp is May  8
2013  9:11AM while dump was from May  8 2013  9:14AM.
我的全庫備份是在9:11的時(shí)候做的，增量備份手動(dòng)添加了幾條記錄，是在9:14做的備份，為什么恢復(fù)的時(shí)候提示我數(shù)據(jù)庫的時(shí)間戳在9:11，是因?yàn)槲一謴?fù)的時(shí)候時(shí)間戳也變成了9:11嗎？可是增量恢復(fù)的時(shí)候貌似都是要先做一個(gè)全庫恢復(fù)然后再使用增量備份恢復(fù)，求解，網(wǎng)上找不到解決辦法，官方文檔寫的太無語，看了好幾遍都沒看到solution，有人做過sybase的增量備份嗎？
Error 4305

Severity

16
Message text

Specified file '%.*s' is out of sequence. Current time stamp is %S_DATE while dump was from %S_DATE.
Explanation

During a load transaction, Adaptive Server checks the timestamp on the dumped database and each dumped transaction log to determine whether the sequence is correct. If the load sequence of the transaction logs is incorrect, error 4305 occurs and the load fails.

If you are missing a transaction log dump, you can only restore up to the transaction log dump before the missing dump.

In addition, you cannot load multiple transaction log dumps that have been created with the no_truncate option. The no_truncate option assumes that nothing further will be done with the transaction log after that point: it is only useful for up-to-the-minute recovery of a database after failure of the data device. If you have used the no_truncate option and your database is still okay, do a dump database as soon as possible.

This error is serious as the load processing stops and the load transaction fails.

Action

Load the log backups in the same sequence in which they were made. Check your transaction log dumps to determine whether one was loaded out of order. If you find the correct dump, load it and continue with the rest of the dumps, in order.

Additional information

For more information, refer to “l(fā)oad transaction” in the Reference Manual: Commands.

Versions in which this error is raised

All versions

zy407321952

找到哪做錯(cuò)了，O__O"…  現(xiàn)在可以了。

wang_xue_m

請(qǐng)把哪里出現(xiàn)的問題，怎么解決的。共享出來，謝謝

zy407321952

回復(fù) 3# wang_xue_m


    是因?yàn)槲覉?zhí)行備份的時(shí)候使用了dump transaction testdbs with truncate_only來清除日志，查資料發(fā)現(xiàn)sybase增量備份是用日志來做的，所以導(dǎo)致增量備份無法恢復(fù)。

wang_xue_m

要是不截?cái)嗳罩镜脑挘�日志空間會(huì)滿，看來你得經(jīng)常做增量備份，備完，再截?cái)?/td>

zy407321952

回復(fù) 5# wang_xue_m


    我又試了下，貌似跟dump transaction with truncate_only沒多大關(guān)系，我在執(zhí)行備份前后都執(zhí)行了該命令，沒問題，那天確實(shí)很奇怪，我也就多執(zhí)行了下這條命令就出現(xiàn)了時(shí)間戳不匹配的錯(cuò)誤，我現(xiàn)在做增量備份只會(huì)在全備的時(shí)候使用這條命令來清除日志，現(xiàn)在應(yīng)該就沒問題了。