介绍 (Introduction)

How often are you working with multiple environments? For example, if you are a database administrator who is responsible for a production environment as well as another environment, it most likely that you will be working with both environments simultaneously. What is the probability that you will execute a script on production, which actually needs to be executed on the other environment? I would say it is high. To prove this point let me present you an example.

您多久在多个环境中工作？ 例如，如果您是负责生产环境以及另一个环境的数据库管理员，则很可能同时使用这两个环境。 您将在生产环境上执行脚本的可能性是多少，而实际上该脚本需要在其他环境上执行？ 我会说这很高。 为了证明这一点，让我举一个例子。

A novice dba was working in multiple database servers using same SQL Server Management Studio (SSMS) in which both instances are registered. In this case, the dba has registered with their development server and the production server and for both servers. The dba has system administrative privileges. The dba had wanted to truncate customer table in the QA environment but guess what? … this script was executed in production. I don’t think I need to describe to you the consequences.

dba新手正在使用相同SQL Server Management Studio（SSMS）在多个数据库服务器中工作，并且两个实例都在其中注册。 在这种情况下，dba已向其开发服务器和生产服务器以及这两个服务器注册。 dba具有系统管理特权。 dba曾想在QA环境中截断客户表，但您猜怎么着？ …此脚本已在生产环境中执行。 我认为我不需要向您描述后果。

In another incident, a database administrator in a popular hospital needed to modify the column name of the most commonly used table. The previous length of the varchar column was 15 and the requirement was to expand the length the 50. However, instead of making it to 50, it was changed to 5. This action, of course, resulted in lost data.

在另一起事件中，一家流行医院的数据库管理员需要修改最常用表的列名。 varchar列的先前长度为15，并且要求将长度扩展为50。但是，不是将其变为50，而是更改为5。此操作当然会导致数据丢失。

In both cases, the result was an accident and emergency help was required. Typically, you need your scheduled backups to restore your data to the point which you execute the incorrect script. However, you do not take backups every hour as that will negatively impact the performance of the system. If you are taking backups on daily basis and if you have to revert your database to the last backup, then you are talking about more data loss in order to capture latest data loss.

在这两种情况下，结果都是事故，需要紧急帮助。 通常，您需要计划的备份才能将数据还原到执行错误脚本的位置。 但是，您不会每小时进行一次备份，因为这会对系统性能产生负面影响。 如果您要每天进行备份，并且必须将数据库还原到上一次备份，那么您正在谈论更多的数据丢失，以捕获最新的数据丢失。

Before moving into how to recover data, let us briefly go through the architecture of the databases in SQL Server.

在介绍如何恢复数据之前，让我们简要介绍一下SQL Server中数据库的体系结构。

Every SQL Server database has at least two files. The first one is the data file or the mdf file and the second one is transaction log file or the ldf file. Like most database systems, SQL Server uses Write Ahead Logging (WAL) which means every transaction first written to the database log and then it will be written to the data file using a CHECKPOINT operation. This is mainly done to maintain the ACID properties of a transaction. More information can be seen at https://technet.microsoft.com/en-us/library/ms186259(v=sql.105).aspx

每个SQL Server数据库至少有两个文件。 第一个是数据文件或mdf文件，第二个是事务日志文件或ldf文件。 与大多数数据库系统一样，SQL Server使用预写日志记录（WAL），这意味着每个事务首先写入数据库日志，然后使用CHECKPOINT操作将其写入数据文件。 这样做主要是为了维护事务的ACID属性。 可以在https://technet.microsoft.com/zh-cn/library/ms186259(v=sql.105).aspx中查看更多信息。

恢复模型 (Recovery Models)

In databases, there are recovery models such as SIMPLE, FULL, and BULK-LOGGED. This setting decides how log records of the database behave. This can be modified at the database option page. Please note that after modifying the recovery model you need to issue a full backup.

在数据库中，有恢复模型，例如SIMPLE，FULL和BULK-LOGGED。 此设置确定数据库的日志记录的行为。 可以在数据库选项页面上进行修改。 请注意，修改恢复模型后，您需要发出完整备份。

In the case of the FULL recovery model, log records will stay in the log file as inactive status. Log backups will clear the inactive records and those records will be backed up. In the case of the SIMPLE recovery model, as soon as the record is inactive, the record will be deleted from the log file. This means that with the SIMPLE recovery model, you do not have a record of the transaction. However, many novice database administrators choose SIMPLE recovery model as it won’t increase the log file size. BULK-Logged recovery model falls between SIMPLE and FULL recovery models. Apart from some commands, all the other transactions will be logged.

对于完整恢复模型，日志记录将以非活动状态保留在日志文件中。 日志备份将清除不活动的记录，并将备份那些记录。 对于SIMPLE恢复模型，一旦该记录处于非活动状态，该记录将从日志文件中删除。 这意味着使用SIMPLE恢复模型，您没有交易记录。 但是，许多新手数据库管理员选择SIMPLE恢复模型，因为它不会增加日志文件的大小。 大容量记录的恢复模型介于简单和完整恢复模型之间。 除某些命令外，所有其他事务都将被记录。

时间点恢复 (Point in Time Recovery)

With the all the basic information we have, let us simulate in an incident where accidental data loss has occurred.

利用我们拥有的所有基本信息，让我们模拟发生意外数据丢失的事件。

Let us assume that we have a database with full recovery model. For the demonstration purposes, let us create a table and populate a table.

让我们假设我们有一个具有完整恢复模型的数据库。 出于演示目的，让我们创建一个表并填充一个表。

Let us say that, there was a data delete on a specific time. Now your task is to recover them.

可以说，在特定时间删除了数据。 现在您的任务是恢复它们。

Immediately log backup needs to be executed either from T-SQL or from User Interface.

立即需要从T-SQL或从用户界面执行日志备份。

BACKUP LOG [DB] TO
DISK = N'C:\Program Files\Microsoft SQL
Server\MSSQL11.MSSQLSERVER\MSSQL\Backup\DB_Log.bak'
GO

Next, restore the full backup to a different database, but make sure you have to set recovery state to NORECOVERY. If you are restoring log backups or differential backups over the existing database, the state should be NORECOVERY.

接下来，将完整备份还原到其他数据库，但是请确保必须将恢复状态设置为NORECOVERY。 如果要通过现有数据库还原日志备份或差异备份，则状态应为NORECOVERY。

Similarly, you have the option of executing this using a T-SQL.

同样，您可以选择使用T-SQL执行此操作。

RESTORE DATABASE [DB2] FROM DISK = N'C:\Program Files\Microsoft SQL
Server\MSSQL11.MSSQLSERVER\MSSQL\Backup\DB.bak' WITH FILE = 1,  MOVE
N'DB' TO N'C:\Program Files\Microsoft SQL
Server\MSSQL11.MSSQLSERVER\MSSQL\DATA\DB2.mdf',  MOVE N'DB_log' TO
N'C:\Program Files\Microsoft SQL
Server\MSSQL11.MSSQLSERVER\MSSQL\DATA\DB2_log.ldf',  NORECOVERY,
NOUNLOAD,  STATS = 5

In case you have differential backups, you need to restore the latest differential backups.

如果您有差异备份，则需要还原最新的差异备份。

The next step is to restore the log backup, stating the date/time to recover the data. Before that, a log backup should be selected. In case you have multiple log backups, you need to select all the log backups as every log backup has incremental data. In case you have a differential backup, you do not need to select log backups before the differential backups, instead, you can choose the last differential backups and the transactional log backup taken after the differential backups.

下一步是还原日志备份，说明要恢复数据的日期/时间。 在此之前，应选择日志备份。 如果您有多个日志备份，则需要选择所有日志备份，因为每个日志备份都有增量数据。 如果您有差异备份，则无需在差异备份之前选择日志备份，而是可以选择最后一个差异备份和在差异备份之后进行的事务性日志备份。

The next step is to select a time to which will be your point to which you want to recover your data. As shown in the below image, you need to select the Point in time option.

下一步是选择一个要恢复数据的时间。 如下图所示，您需要选择时间点选项。

Then the time needs to be selected.

然后需要选择时间。

As usual this can be done using a T-SQL script as well which is shown below.

与往常一样，这也可以使用T-SQL脚本完成，如下所示。

RESTORE LOG [DB2]
FROM  DISK = N'C:\Program Files\Microsoft SQL
Server\MSSQL11.MSSQLSERVER\MSSQL\Backup\DB_Log.bak'WITH  FILE = 1,  NOUNLOAD,  STATS = 10,  STOPAT = N'2016-11-25T14:30:34'

With this, data is recovered to a specific time, which can be verified by running query as it will retrieve the deleted data.

这样，数据将恢复到特定时间，可以通过运行查询来验证该时间，因为它将检索已删除的数据。

改进的用户界面 (Improved User Interface)

From SQL Server 2012 onwards, you have an improved user interface so that users simply need to point to the timeline. Also, it shows backup types with different symbols and different colors as shown in the below image.

从SQL Server 2012开始，您将拥有改进的用户界面，因此用户只需要指向时间轴即可。 此外，它还显示了具有不同符号和不同颜色的备份类型，如下图所示。

Full backups and differential backups are shown with pointed arrowheads. This means that from full backups and differential backups you can recover to a time which the backup was taken. In the case of Transactional log backups, it shows a range. This means that you can recover any point with the given range.

完整备份和差异备份显示为带箭头的箭头。 这意味着您可以从完整备份和差异备份恢复到进行备份的时间。 对于事务性日志备份，它将显示一个范围。 这意味着您可以恢复给定范围内的任何点。

最佳实践 (Best Practices)

Many organizations have implemented Full backups and Transactional log backups as data backup in SQL Server. Though this mechanism is technically feasible, there are practical and implementation difficulties. Just imagine that you have implemented a weekly full backup and every 15 minutes, a log backup. This means there will be (4*24*7) 672 log backups per week. In a case of a disaster recovery, the number of files you need to implement is very large. This can be avoided by including differential backup for daily frequency. The introduction of differential backup means, that in the case of a disaster you can restore the last full backup, last differential backup, and the log backups which were taken after the last differential backup. This will reduce the restoration of number log backups. The maximum, you need are 96 log backup files. With this method, you are not only improving the restore time and operation easiness, but also you are also reducing the risk of file corruption.

许多组织已在SQL Server中实现了完全备份和事务日志备份作为数据备份。 尽管该机制在技术上是可行的，但存在实践和实施困难。 试想一下，您已经实施了每周完整备份，并且每15分钟执行一次日志备份。 这意味着每周将有（4 * 24 * 7）672个日志备份。 在灾难恢复的情况下，您需要实现的文件数量非常大。 可以通过包括每日频率的差异备份来避免这种情况。 差异备份的引入意味着，在灾难情况下，您可以还原最后的完整备份，最后的差异备份以及在最后的差异备份之后进行的日志备份。 这将减少数字日志备份的还原。 最多需要96个日志备份文件。 使用此方法，您不仅可以改善还原时间和操作简便性，而且还可以减少文件损坏的风险。

摘要 ( Summary)

Point in time recovery is very useful for database administrators in case of a need to recover of accidental data deletes or drops. By keeping the database recovery model with FULL or BULK-LOGGED, you will be able to recover data to point of a time.

在需要恢复意外数据删除或删除的情况下，时间点恢复对于数据库管理员非常有用。 通过使用FULL或BULK-LOGGED保留数据库恢复模型，您将能够恢复数据到某个时间点。

翻译自: https://www.sqlshack.com/point-in-time-recovery-with-sql-server/