开发同事说由于误操作, 造成了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者都是将对应的数据文件通过一定的方法嵌入到其他数据库中.