34,587
社区成员
发帖
与我相关
我的任务
分享昨天犯二了，把备份的数据弄丢了~~~
由于业务数据完整性要求比较高，所以采用发布订阅来对数据进行备份。
昨天主服务器和备份服务器都掉电了（插头被弄掉了），然后都开不了机，后来检查到主服务器的硬盘损坏，还好订阅机器(备份服务器)的硬盘还没有坏，
然后把订阅服务器的硬盘挂接到别的电脑（以下称B电脑）上，
我做了如下操作：
首先把B电脑上的数据库服务停掉，然后删掉同名的数据库文件，再启动数据库服务，然后在企业管理器上再把这个数据库删除了（右键-》删除操作），再从订阅服务器的那个硬盘上直接附加数据库。
在这里提醒一下同仁，操作数据前记得先复制一份啊，血的教训！
再然后启动我的应用，上去查询数据都没问题。
过了十几分钟后，再查询数据，悲剧了。
之前备份的数据都没有了，甚至自动编号都归0了。
。。。。。
。。。
。
最后发现日志里面有一行，记得不大清楚了，'3697个事务回滚了'，百思不得其解，里面的数据是怎么被清除的，
可以排除人为因素，求解释！
昨天主服务器和备份服务器都掉电了（插头被弄掉了），然后都开不了机，后来检查到主服务器的硬盘损坏，还好订阅机器(备份服务器)的硬盘还没有坏，
然后把订阅服务器的硬盘挂接到别的电脑（以下称B电脑）上，
我做了如下操作：
首先把B电脑上的数据库服务停掉，然后删掉同名的数据库文件，再启动数据库服务，然后在企业管理器上再把这个数据库删除了（右键-》删除操作），再从订阅服务器的那个硬盘上直接附加数据库。
在这里提醒一下同仁，操作数据前记得先复制一份啊，血的教训！
再然后启动我的应用，上去查询数据都没问题。
过了十几分钟后，再查询数据，悲剧了。
之前备份的数据都没有了，甚至自动编号都归0了。
。。。。。
。。。
。
最后发现日志里面有一行，记得不大清楚了，'3697个事务回滚了'，百思不得其解，里面的数据是怎么被清除的，
可以排除人为因素，求解释！
...全文
请发表友善的回复…
发表回复
马少华 2012-12-24
- 打赏
- 举报
我把数据库文件附加到别的地方可以用吗？
KaBenGuBaZhu 2012-12-23
- 打赏
- 举报
开启时代 2012-12-21
- 打赏
- 举报
删除订阅 不影响历史数据。
马少华 2012-12-21
- 打赏
- 举报
还有个细节，我附加数据库后把订阅删了。这个会不会有影响。
nzperfect 2012-12-21
- 打赏
- 举报
那你把它贴出来看看吧
exec xp_readerrorlog
开启时代 2012-12-21
- 打赏
- 举报
订阅库 数据丢失只有符合 发布数据丢失后 才可发生。且当前发布已无效，所以 结果不成立啊
开启时代 2012-12-21
- 打赏
- 举报
你这情况 貌似执行了 truncate table 造成的啊 。。。
马少华 2012-12-21
- 打赏
- 举报
但我确实在日志里看到了这个'3697个事务回滚了'，这个时间和事故时间基本吻合。
我附加的这个数据库是之前的订阅数据库，而且订阅过程中断电，会不会和这有关？
开启时代 2012-12-21
- 打赏
- 举报
Profiler 怎么看过去发生了什么？
nzperfect 2012-12-21
- 打赏
- 举报
如果有问题你挂上库就应该有问题了，而不是过了十几分钟。
發糞塗牆 2012-12-21
- 打赏
- 举报
看看能不能找到具体的发生时间点，然后用Profiler看看发生了什么事马少华 2012-12-21
- 打赏
- 举报
业务逻辑都是我自己做的，肯定是没有删除的。
开启时代 2012-12-21
- 打赏
- 举报
任何时候 对数据库的备份 都无可替代。 异常断电 事务回滚是正常的，但是不应该在数据库可用后再回滚。
我认为数据丢失不是事务回滚造成的。
马少华 2012-12-21
- 打赏
- 举报
自动编号就是我习惯每个表第一列设成自增列。
如果普通删除的话ID号是不会归0 的。
nzperfect 2012-12-21
- 打赏
- 举报
如果你说的都是真的，那么应该从业务逻辑端去查原因，数据库不会有你说的这情况。
马少华 2012-12-21
- 打赏
- 举报
这个数据超过一天后就没什么价值了。倒不用找回，就是想知道这个过程是怎么产生的。
發糞塗牆 2012-12-21
- 打赏
- 举报
如果日志没截断，那还有的救，如果截断了，那......看看有没有什么第三方工具来从mdf恢复吧
nzperfect 2012-12-21
- 打赏
- 举报
再然后启动我的应用，上去查询数据都没问题。
过了十几分钟后，再查询数据，悲剧了。
之前备份的数据都没有了，甚至自动编号都归0了。
好复杂，没看懂。。
