user1068636 Asked: 2022-12-16 19:30:02 +0800 CST2022-12-16 19:30:02 +0800 CST 2022-12-16 19:30:02 +0800 CST 是否有任何数据库跟踪所有插入、更新和删除,以便您可以简单地撤消任何更改,直到恢复到良好状态? 772 有时人们会进行他们不希望的插入、更新或删除,并希望恢复他们的更改(或撤消它们)。是否有数据库可以让这件事变得容易(即是否有数据库跟踪对它所做的每一次插入、更新、删除,以便您可以在特定时间之前重新创建整个数据库)? rollback 2 个回答 Voted Best Answer J.D. 2022-12-16T20:14:39+08:002022-12-16T20:14:39+08:00 是否有数据库可以跟踪对它所做的每一次插入、更新、删除,以便您可以在特定时间之前重新创建整个数据库 我知道没有任何数据库系统可以开箱即用 - 用于一组特定的更改。这样做会非常困难,因为在不同的时间点,跨多个表,多个更改可能会叠加到先前的更改或由于先前的更改而导致的数据状态。所以它不像撤消对单个表的线性更改列表那么简单,否则会破坏数据库系统的ACID 原则。但是,时间点恢复是可能的,可以将整个数据库始终如一地恢复到特定时间的先前状态(在本答案末尾进一步讨论)。 一些数据库系统提供用于数据审计目的的变更跟踪形式。例如,Microsoft SQL Server 具有Change Tracking、Change Data Capture和Temporal Tables功能,这些功能可以跟踪补充表中的数据更改,并提供旧值和更改发生时间的时间戳等信息。这是用于手动核对和审计,而不是用于完全撤销数据库状态到某个先前时间点的工具。 最接近的方法是使用粒度备份,例如 SQL Server 提供的事务日志备份,它将数据库恢复到某个时间点,但不会仅撤消对某些表的一组特定更改。它是将数据库整体恢复到特定时间点的完全一致的恢复。 Phill W. 2022-12-17T03:51:20+08:002022-12-17T03:51:20+08:00 ... 插入、更新或删除他们不打算并希望恢复他们的更改(或撤消)。 这就是交易的目的。 您开始一个事务,进行一些更改,决定不再需要它们并回滚到该事务的开始,丢弃这些更改。 根据您的 DBMS,没有人会知道它曾经发生过。 我们最常见的用途是保护自己免受“糟糕时刻”的影响: begin transaction ; -- this bit is DBMS-specific update the_banks_10million_accounts set account_balance = 0 ; -- OOPS! rollback ; -- No harm done 是否有数据库……跟踪对它所做的每一次插入、更新、删除,以便您可以在特定时间之前重新创建整个数据库)? 是的。几乎所有这些。 您所描述的通常称为“时间点恢复”,它是 DBA 绝对必不可少的工具。 在某时某时,数据库中发生了“Something Bad(TM)”。 您需要将整个数据库恢复到那个时间点 [恰好之前],使它好像“Something Bad(TM)”从未发生过一样。 要执行时间点恢复,您可以还原以前的 [完整] 备份,然后“前滚”[临时备份和] 事务日志以返回到所需的时间点。 听起来不错,不是吗? 现在,64,000 美元的问题: 为什么 DBMS 不让这变得简单? 因为,矛盾的是,这个“时间点恢复”过程是破坏性的。 假设“Something Bad(TM)”发生在中午 12 点。 数据库的某些部分已损坏,有些东西停止工作。可能需要一个小时左右的时间才能收到消息,您必须“修复”数据库。 在那一小时内,数据库中发生了许多其他“Something Bad(TM)”没有中断的事情。所有这些其他更改都将被此恢复过程破坏。 为什么? 因为恢复数据库不像进入您的 Delorean 并飞回 1955 年(尽管 Oracle 数据库的“闪回查询”确实提供了非常类似的功能)。 恢复后,您的数据库将恢复到“回到 1955 年”的状态,对从那时起发生的任何事情一无所知。人们从中午 12 点到您开始恢复之前所做的所有可爱的工作都将消失。 解决这个问题的唯一方法是恢复数据库的副本,提取“损坏的”数据,就像“Something Bad(TM)”发生之前一样,然后找出如何“用鞋拔”将该数据恢复到原始数据库中,替换损坏的数据。这可能会非常、非常痛苦和耗时,并且在解决时实际上会导致更多问题。
我知道没有任何数据库系统可以开箱即用 - 用于一组特定的更改。这样做会非常困难,因为在不同的时间点,跨多个表,多个更改可能会叠加到先前的更改或由于先前的更改而导致的数据状态。所以它不像撤消对单个表的线性更改列表那么简单,否则会破坏数据库系统的ACID 原则。但是,时间点恢复是可能的,可以将整个数据库始终如一地恢复到特定时间的先前状态(在本答案末尾进一步讨论)。
一些数据库系统提供用于数据审计目的的变更跟踪形式。例如,Microsoft SQL Server 具有Change Tracking、Change Data Capture和Temporal Tables功能,这些功能可以跟踪补充表中的数据更改,并提供旧值和更改发生时间的时间戳等信息。这是用于手动核对和审计,而不是用于完全撤销数据库状态到某个先前时间点的工具。
最接近的方法是使用粒度备份,例如 SQL Server 提供的事务日志备份,它将数据库恢复到某个时间点,但不会仅撤消对某些表的一组特定更改。它是将数据库整体恢复到特定时间点的完全一致的恢复。
这就是交易的目的。
您开始一个事务,进行一些更改,决定不再需要它们并回滚到该事务的开始,丢弃这些更改。
根据您的 DBMS,没有人会知道它曾经发生过。
我们最常见的用途是保护自己免受“糟糕时刻”的影响:
是的。几乎所有这些。
您所描述的通常称为“时间点恢复”,它是 DBA 绝对必不可少的工具。
要执行时间点恢复,您可以还原以前的 [完整] 备份,然后“前滚”[临时备份和] 事务日志以返回到所需的时间点。
听起来不错,不是吗?
现在,64,000 美元的问题:
因为,矛盾的是,这个“时间点恢复”过程是破坏性的。
假设“Something Bad(TM)”发生在中午 12 点。
数据库的某些部分已损坏,有些东西停止工作。可能需要一个小时左右的时间才能收到消息,您必须“修复”数据库。
在那一小时内,数据库中发生了许多其他“Something Bad(TM)”没有中断的事情。所有这些其他更改都将被此恢复过程破坏。
为什么?
因为恢复数据库不像进入您的 Delorean 并飞回 1955 年(尽管 Oracle 数据库的“闪回查询”确实提供了非常类似的功能)。
恢复后,您的数据库将恢复到“回到 1955 年”的状态,对从那时起发生的任何事情一无所知。人们从中午 12 点到您开始恢复之前所做的所有可爱的工作都将消失。
解决这个问题的唯一方法是恢复数据库的副本,提取“损坏的”数据,就像“Something Bad(TM)”发生之前一样,然后找出如何“用鞋拔”将该数据恢复到原始数据库中,替换损坏的数据。这可能会非常、非常痛苦和耗时,并且在解决时实际上会导致更多问题。