SQL Server /oracle 如何恢复以前的历史记录,对某个table

fly050505

经常干以下的愚蠢事：
update/delete records时，忘记了写where条件。
结果整表都被改了。

请教一下，如何恢复到以前的记录,针对这个被改变的table。（不计划使用，restore database）
没有用transaction, 因为不想把这个经常使用的table lock。

还请赐教。

coin_king

只有用transaction log否则好像没有办法

fly050505

原帖由 liedong 于 2011-10-9 10:21 发表
只有用transaction log否则好像没有办法

只是觉得这是很常见的事情，ms,oracle应该有非常好的解决方案。
SQL Server是先记log的机制。Server Cache Memory中日志页总是先写于数据页。理论上来讲，在到达check point前，应该可以很方便的rollback.

Fernando

restore数据库也没关系啊，不用覆盖现在数据库，restore到其他地方export出来嘛

黑山老妖

如果是在sqlplus下打完了指令以后马上打rollback。

huangjoice

经常这样干也太粗心了吧， 放到transaction里把。删掉不该删掉的数据可不是小问题。相比你所顾虑的问题，数据的integrity 更加重要。而且不觉得你把这个放到transaction 里面会有很大的performance影响，你不会在live数据库上直接工作吧？

wendy

oracle ,can use flashback table

[ 本帖最后由 wendy 于 2011-10-9 20:39 编辑 ]

fly050505

原帖由 huangjoice 于 2011-10-9 20:04 发表
经常这样干也太粗心了吧， 放到transaction里把。删掉不该删掉的数据可不是小问题。相比你所顾虑的问题，数据的integrity 更加重要。而且不觉得你把这个放到transaction 里面会有很大的performance影响，你不会在live数据库上直接工作吧？

我们干的都是一脚踢的活，
经常是直接在Live上干。
一边干，往往一边还有电话过来催。
唉，苦呀。
因为是实时系统，用transaction会lock table，马上就会有人报bug。

YugaYuga

benny2002

Oracle可以用flashback table;

SqlServer没有特别好的解决方法，只能把session设置成不自动commit，确定后再commit.

Fernando

原帖由 fly050505 于 2011-10-9 19:39 发表


我们干的都是一脚踢的活，
经常是直接在Live上干。
一边干，往往一边还有电话过来催。
唉，苦呀。
因为是实时系统，用transaction会lock table，马上就会有人报bug。

type the command in text editor, double check it, then copy to SQL*Plus, after the command competed, double check how many records are updated/deleted, then commit

多情圣手

唯一的办法就是调用公司的母带啦·～

北风

还是那句话要用transaction
但是要是真的经常发生，用了也没用，最后你可能会把立即commit变成习惯
根据你的描述，你们需要一个UI专门处理这里一类的修改，而不是直接去数据库update

原帖由 fly050505 于 9/10/2011 09:09 发表
经常干以下的愚蠢事：
update/delete records时，忘记了写where条件。
结果整表都被改了。

请教一下，如何恢复到以前的记录,针对这个被改变的table。（不计划使用，restore database）
没有用transaction, 因为不想把这个经常使用的table lock。

还请赐教。

zxzzd

为什么会直接去数据库修改数据? 应该尽量避免吧. 实在不行也要经常备份.
良好的习惯是避免错误的最好办法

huaxianz

If you have log shipping in place, and if the restore interval is longer enough during which you can notice and respond to a catastrophic action on the primary, then you can roll back your accidental deletion. HOWEVER, log shipping is not supposed to be used for this purpose. It's just a possible workaround.

All in all, nothing is better than having a good habit. E.g. always write where clause before anything else, or embed DML statement within a transaction and do not commit it before double checking the result, or even write out those affected rows into an auxiliary table before applying the changes to production. If too many rows are qualified by the serach condition and leads to lock escalation, then let it block. Blocking is not always a bad thing, it's acceptable if under a threshold. After all it's what a pessimistic concurrency model is supposed to be. Blocking is at least 100 times better than losing production data.

huaxianz

原帖由 fly050505 于 2011-10-9 10:33 发表


只是觉得这是很常见的事情，ms,oracle应该有非常好的解决方案。
SQL Server是先记log的机制。Server Cache Memory中日志页总是先写于数据页。理论上来讲，在到达check point前，应该可以很方便的rollback.

The transaction log is only intended to enable SQL Server to guarantee recoverability in case of failures, or to allow dba to take backups of the changes to database. If you need to keep track of changes to database, you have to implement your own auditing mechanism. It's impossible for human-being to read the transaction log directly even if knowledgeable enough as it just contains a hell of a lot of information. There are some third party products in the martket to reverse engineer the transaction log, which may be a good choice if desired.