开发同事说由于误操作, 造成了1个数据库损坏,需要恢复. 随即检查需要的备份,发现此备份已经被覆盖了.
静下心仔细想了一下, 猜测可以使用NAS 的快照文件文件来恢复. 我们的设备文件都在NAS上,而NAS上设置了
snap, 并且保留2周内的snap.
但使用snap来备份数据库,需要和数据库之间存在协调.以oracle数据库为例, 我们21:00将每台机器上的数
据库进入用户备份模式(alter database begin backup),在23:00时,NAS上开始执行snap, 第2天1:00, 每台机器
上的数据库退出用户备份模式(alter database end backup),而对于sybase数据库我并不熟悉,以前也没有考虑
过使用NAS 的快照来恢复. 因此所有的sybase server也就没有类似的设置,它的备份使用普通的dump来操作.
考虑到数据库晚上基本没有io操作,认为实际上此时的snap应该可以用于恢复. 最简单的方法就是先停止
sybase server,将所有文件都复制到原始位置,然后再启动. 但这样copy的文件很多,影响的时间长,而且自己并
不肯定能恢复.于是想将需要的文件复制到其他目录做一下测试.
查阅sybase手册后,认为可以使用quiesce先得到对应数据库的必要信息,然后使用mount按照前面获取的信息
来加载设备文件,建立对应的数据库.
具体操作步骤如下:
1. 检查对应数据库的dbid
select * from sysdatabases where name='FIXServer_mb3'
dbid 52. 检查此数据库在哪些设备文件上
select vdevno from sysusages where dbid=5 group by vdevno
6
73. 检查对应的设备文件上是否仅包含这一个数据库
select dbid from sysusages where vdevno in (6,7) group by dbid
54. 检查设备文件的物理名称
select name,phyname from sysdevices where vdevno in (6,7)
FIXServer_mb_date /hubs/syb_1503/data/CopsTWDev/FIXServer_mb_data.dat
FIXServer_mb_log /hubs/syb_1503/data/CopsTWDev/FIXServer_mb_log.dat5. 检查对应卷的snap情况,
# find sv_hourly*/FAS3140A_vol7_backup_qtr/hubs/syb_1503/data/CopsTWDev/FIXServer_mb_data.dat -ls
13457311 281132 -rw-r--r-- 1 131012 other 287309824 Oct 7 21:59 sv_hourly.0/FAS3140A_vol7_backup_qtr/hubs/syb_1503/data/CopsTWDev/FIXServer_mb_data.dat
13457311 281132 -rw-r--r-- 1 131012 other 287309824 Oct 6 19:57 sv_hourly.1/FAS3140A_vol7_backup_qtr/hubs/syb_1503/data/CopsTWDev/FIXServer_mb_data.dat
13457311 281132 -rw-r--r-- 1 131012 other 287309824 Sep 27 19:42 sv_hourly.10/FAS3140A_vol7_backup_qtr/hubs/syb_1503/data/CopsTWDev/FIXServer_mb_data.dat6. 将所需要的snap 复制到测试目录
cp FIXServer_mb_data.dat /dbfiles_wif/CopsTWDev/hubs/
cp FIXServer_mb_log.dat /dbfiles_wif/CopsTWDev/hubs/
7. 在现有sybase server中获取对应数据库的信息. 随后release.
quiesce database FIXServer_mb3_tag hold FIXServer_mb3 for external dump to "/vol2/sybase.backup/FIXServer_mb3.manifest"
quiesce database FIXServer_mb3_tag release8. 建立一个测试sybase server,不包含任何用户定义的数据库,在测试sybase server中
1> mount database all from "/vol2/sybase.backup/FIXServer_mb3.manifest"
using "/dbfiles_wif/CopsTWDev/hubs/FIXServer_mb_data.dat" = "FIXServer_mb_date",
"/dbfiles_wif/CopsTWDev/hubs/FIXServer_mb_log.dat" = "FIXServer_mb_log"
2> 3> 4> go
Started estimating recovery log boundaries for database 'FIXServer_mb3'.
Database 'FIXServer_mb3', checkpoint=(71970, 20), first=(71970, 20),
last=(71975, 19).
Completed estimating recovery log boundaries for database 'FIXServer_mb3'.
Started ANALYSIS pass for database 'FIXServer_mb3'.
Completed ANALYSIS pass for database 'FIXServer_mb3'.
Started REDO pass for database 'FIXServer_mb3'. The total number of log records
to process is 64.
Redo pass of recovery has processed 5 committed and 6 aborted transactions.
Completed REDO pass for database 'FIXServer_mb3'.
Recovery of database 'FIXServer_mb3' will undo incomplete nested top actions.
Started filling free space info for database 'FIXServer_mb3'.
Completed filling free space info for database 'FIXServer_mb3'.
Started cleaning up the default data cache for database 'FIXServer_mb3'.
Completed cleaning up the default data cache for database 'FIXServer_mb3'.
MOUNT DATABASE: Completed recovery of mounted database 'FIXServer_mb3'.
9. 随后online数据库.
online database FIXServer_mb3
从体会来说,sybase的mount database类似于oracle的传输表空间, 2者都是将对应的数据文件通过一定的方法嵌入到其他数据库中.