今天用SQL SERVER修改了批量21W条数据，突然发现自己改错了，怎样返回上一步

前提条件

-- 将 数据库的恢复模式（Recovery mode）设置为  “完整（Full）”

-- 此 *** 作可以在  SQL Server Management Studio 中， 选择数据库， 鼠标右键， 属性后，在 选项 标签中进行设置。

USE [master]

GO

ALTER DATABASE [test] SET RECOVERY FULL WITH NO_WAIT

GO

-- 完整备份数据库

backup database test to disk='e:\test_20130704dat'

GO

已为数据库 'test'，文件 'Test' (位于文件 1 上)处理了 376 页。

已为数据库 'test'，文件 'Test_log' (位于文件 1 上)处理了 3 页。

BACKUP DATABASE 成功处理了 379 页，花费 1151 秒(2571 MB/秒)。

 测试数据

USE [test]

GO

-- 创建测试表

CREATE TABLE test_br_table (

  ID   int,

  VAL  VARCHAR(10),

  PRIMARY KEY(ID)

);

GO

INSERT INTO test_br_table  VALUES (1, 'TEST1');

INSERT INTO test_br_table  VALUES (2, 'TEST2');

INSERT INTO test_br_table  VALUES (3, 'TEST3');

GO

SELECT GETDATE()

GO

-----------------------

2013-07-04 16:44:12393

(1 行受影响)

-- 假设误 *** 作， 删除所有的数据了

DELETE FROM test_br_table

GO

(3 行受影响)

 恢复 

USE [master]

GO

-- 步骤1 备份当前数据库的事务日志：

BACKUP LOG [Test] TO disk= N'e:\test_log' WITH NORECOVERY

GO

已为数据库 'Test'，文件 'Test_log' (位于文件 1 上)处理了 9 页。

BACKUP LOG 成功处理了 9 页，花费 0046 秒(1486 MB/秒)。

-- 步骤2 恢复一个误删除之前的完全备份：

RESTORE DATABASE [Test] FROM DISK = N'e:\test_20130704dat' WITH NORECOVERY,  REPLACE

GO

已为数据库 'Test'，文件 'Test' (位于文件 1 上)处理了 376 页。

已为数据库 'Test'，文件 'Test_log' (位于文件 1 上)处理了 3 页。

RESTORE DATABASE 成功处理了 379 页，花费 0828 秒(3574 MB/秒)。

-- 步骤3 将数据库恢复至误删除之前的时间点：

RESTORE LOG [Test] FROM  DISK = N'e:\test_log' WITH  STOPAT = N'2013-07-04 16:44:12393' , RECOVERY

GO

已为数据库 'Test'，文件 'Test' (位于文件 1 上)处理了 0 页。

已为数据库 'Test'，文件 'Test_log' (位于文件 1 上)处理了 9 页。

RESTORE LOG 成功处理了 9 页，花费 0013 秒(5258 MB/秒)。

 核对数据

use [Test]

GO

SELECT  FROM test_br_table

GO

ID          VAL

----------- ----------

          1 TEST1

          2 TEST2

          3 TEST3

(3 行受影响)

MySQL 的 Binlog 记录着 MySQL 数据库的所有变更信息，了解 Binlog 的结构可以帮助我们解析Binlog，甚至对 Binlog 进行一些修改，或者说是“篡改”，例如实现类似于 Oracle 的 flashback 的功能，恢复误删除的记录，把 update 的记录再还原回去等。本文将带您探讨一下这些神奇功能的实现，您会发现比您想象地要简单得多。本文指的 Binlog 是 ROW 模式的 Binlog，这也是 MySQL 8 里的默认模式，STATEMENT 模式因为使用中有很多限制，现在用得越来越少了。

Binlog 由事件（event）组成，请注意是事件（event）不是事务（transaction），一个事务可以包含多个事件。事件描述对数据库的修改内容。

现在我们已经了解了 Binlog 的结构，我们可以试着修改 Binlog 里的数据。例如前面举例的 Binlog 删除了一条记录，我们可以试着把这条记录恢复，Binlog 里面有个删除行（DELETE_ROWS_EVENT）的事件，就是这个事件删除了记录，这个事件和写行（WRITE_ROWS_EVENT）的事件的数据结构是完全一样的，只是删除行事件的类型是 32，写行事件的类型是 30，我们把对应的 Binlog 位置的 32 改成 30 即可把已经删除的记录再插入回去。从前面的 “show binlog events” 里面可看到这个 DELETE_ROWS_EVENT 是从位置 378 开始的，这里的位置就是 Binlog 文件的实际位置（以字节为单位）。从事件（event）的结构里面可以看到 type_code 是在 event 的第 5 个字节，我们写个 Python 小程序把把第383（378+5=383）字节改成 30 即可。当然您也可以用二进制编辑工具来改。

找出 Binlog 中的大事务

由于 ROW 模式的 Binlog 是每一个变更都记录一条日志，因此一个简单的 SQL，在 Binlog 里可能会产生一个巨无霸的事务，例如一个不带 where 的 update 或 delete 语句，修改了全表里面的所有记录，每条记录都在 Binlog 里面记录一次，结果是一个巨大的事务记录。这样的大事务经常是产生麻烦的根源。我的一个客户有一次向我抱怨，一个 Binlog 前滚，滚了两天也没有动静，我把那个 Binlog 解析了一下，发现里面有个事务产生了 14G 的记录，修改了 66 万条记录！下面是一个简单的找出 Binlog 中大事务的 Python 小程序，我们知道用 mysqlbinlog 解析的 Binlog，每个事务都是以 BEGIN 开头，以 COMMIT 结束。我们找出 BENGIN 前面的 “# at” 的位置，检查 COMMIT 后面的 “# at” 位置，这两个位置相减即可计算出这个事务的大小，下面是这个 Python 程序的例子。

切割 Binlog 中的大事务

对于大的事务，MySQL 会把它分解成多个事件（注意一个是事务 TRANSACTION，另一个是事件 EVENT），事件的大小由参数 binlog-row-event-max-size 决定，这个参数默认是 8K。因此我们可以把若干个事件切割成一个单独的略小的事务

ROW 模式下，即使我们只更新了一条记录的其中某个字段，也会记录每个字段变更前后的值，这个行为是 binlog_row_image 参数控制的，这个参数有 3 个值，默认为 FULL，也就是记录列的所有修改，即使字段没有发生变更也会记录。这样我们就可以实现类似 Oracle 的 flashback 的功能，我个人估计 MySQL 未来的版本从可能会基于 Binlog 推出这样的功能。

了解了 Binlog 的结构，再加上 Python 这把瑞士军刀，我们还可以实现很多功能，例如我们可以统计哪个表被修改地最多？我们还可以把 Binlog 切割成一段一段的，然后再重组，可以灵活地进行 MySQL 数据库的修改和迁移等工作。

企业管理器

--右键"数据库"

--所有任务

--还原数据库

--"还原为数据库库"中输入还原后的数据库名

--还原选择"从设备"--选择设备--添加--添加你的备份文件--确定,回到数据库还原的界面

--备份号--选择内容--选择你要恢复那次备份的内容

--选项--将"移至物理文件名"中的物理文件名修改为你的数据文件要存放的文件名

--如果要还原的数据库已经存在,选择"在现有数据库上qz还原"-

-确定

--或用SQL语句:

restore database 数据库 from disk='c:\你的备份文件名'

还原数据库

企业管理器中的 *** 作:

1进行完整恢复

企业管理器--右键"数据库"--所有任务--还原数据库

--"还原为数据库库"中输入还原后的数据库名,设为:test

--还原选择"从设备"--选择设备--添加--添加你的备份文件

--确定,回到数据库还原的界面

--"还原备份集",选择"数据库--完全"

--选项--将"移至物理文件名"中的物理文件名修改为你的数据文件要存放的文件名

--如果要还原的数据库已经存在,选择"在现有数据库上qz还原"

--"恢复完成状态",选择"使数据库不再运行，但能还原其它事务日志"

--确定

--或用SQL语句:

restore database 数据库 from disk='c:\你的完全备份文件名' with norecovery

2进行差异恢复

企业管理器--右键"数据库"--所有任务--还原数据库

--"还原为数据库库"中选择数据库名:test

--还原选择"从设备"--选择设备--添加--添加你的备份文件

--确定,回到数据库还原的界面

--"还原备份集",选择"数据库--差异"

--"恢复完成状态",选择"使数据库不再运行，但能还原其它事务日志"

--确定

--或用SQL语句:

restore database 数据库 from disk='c:\你的差异备份文件名' with norecovery

3进行日志恢复

企业管理器--右键"数据库"--所有任务--还原数据库

--"还原为数据库库"中选择数据库名:test

--还原选择"从设备"--选择设备--添加--添加你的备份文件

--确定,回到数据库还原的界面

--"还原备份集",选择"事务日志"

--"恢复完成状态",选择"使数据库可以继续运行，但无法还原其它事务日志"

--确定

--或用SQL语句:

restore log 数据库 from disk='c:\你的日志备份文件名' with recovery

--解决还原数据库目录不对的详细步骤:

1企业管理器中的方法:

--右键"数据库"

--所有任务

--还原数据库

--"还原为数据库库"中输入还原后的数据库名

--还原选择"从设备"--选择设备--添加--添加你的备份文件--确定,回到数据库还原的界面

--备份号--选择内容--选择你要恢复那次备份的内容

--选项--将"移至物理文件名"中的物理文件名修改为你的数据文件要存放的文件名

--如果要还原的数据库已经存在,选择"在现有数据库上qz还原"-

-确定

2用SQL语句的方法(假设你的备份文件名为: c:\xxbak

--列出备份文件中的逻辑文件名

restore filelistonly from disk='c:\xxbak'

--用语句恢复,根据上面列出的逻辑文件名使用move选项

restore database 恢复后的数据库名

from disk='c:\xxbak'

with move '逻辑数据文件名1' to 'c:\物理数据文件名1'

,move '逻辑数据文件名2' to 'c:\物理数据文件名2'

,move '逻辑数据文件名n' to 'c:\物理数据文件名n'

没有什么要特别注意的,和企业版之间的备份/还原要注意的东西一样:

1要注意备份时的设置问题,不要指定多个备份文件,否则还原时也要指定多个备份文件

2要注意备份的媒体处理方式问题,用重写,而不是追加,否则还原的时候要指定备份号

3要注意备份的方式,用完全备份,而不是其他备份方式,否则还原时还要其他备份文件支持

以上就是关于今天用SQL SERVER修改了批量21W条数据，突然发现自己改错了，怎样返回上一步全部的内容，包括:今天用SQL SERVER修改了批量21W条数据，突然发现自己改错了，怎样返回上一步、python *** 作数据库mysql数据库出现错误奇怪望高人指点、SQL数据被删除如何恢复等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！