都说知人知面不知心比down更可怕是人为的误删除,在没有数据库审计和灾备的情况下怎样快速恢复被损坏的数据就显得尤其重要。那么下面是昨天在客户现场发生的真实的case。
13:50 receive C site MES admin call about this issue.
13:55 login C site sqlserver database server (active/standby) and check sqlserver log to check if it was some error information.(no error information)
14:00 check TT.XXX in standby database if standby database corresponding read only table value would be changed or not. (already change)
14:00 ~ 14:15 check table TT.XXX, if it is an partition table and how many datafiles the table occupied and check those datafiles locations.
14:20 call C SITE MES admin to confirm the time period which is necessary for restore and recover database XXX.
14:30 check the database backup files posititon
14:40 copy backup files from active server to standby server in order to prevent crash current using database.
14:50 login on C site standby database server and find that backup files
15:00 modify restore and recovery script in order to restore an different named database (C_TEST) at different location (F:\TEST)
15:20 restore process failed at first time dure to restore script error
15:30~15:50 restore process successed at seocnd time
15:50 make link server at database XXX in active database server to C_TEST in standby database server
15:51 call C site MES test and confirm that is OK
那么兄弟们可以看到 sqlserver相比Oracle还是差了一些。sqlserver把undo 和 redo统一集成在transaction啦,那么从2006之后可以看到sqlserver可以直接备份和还原 filegroup 那么也就是说 sqlserver数据库可以只还原一部分数据库不需要全库恢复。
那么如果熟悉数据库的架构的情况下可以利用现有的条件加快恢复速度
我这的sqlserver使用的always on结果,这玩意类似 oracle的DG,那么为啥不用只读的standby恢复数据呢?
由于always on sync commit以及 极低的延时设置使得这一想法无法实施,不过如有不止一个slave那么可以考虑真的可以 这么设置 。
编者按:车开的再好,难免被别人撞。系统维护的在完善,也有不守规矩的人乱搞.
来自社区交流活动“起底宕机事故-深度剖析宕机真相”,由社区会员“liulei_oracle”发布。
如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!
赞0
添加新评论0 条评论