数据库备份恢复策略_如何根据备份策略选择和检查正确的数据库恢复模型

数据库备份恢复策略

介绍 (Introduction)

Following best practices, we should apply principles like segregation of duties. This implies the segregation of application environments. In particular, we might see for a given application that it incorporates at least two environments: a production environment and a non-production environment that exists for testing, Q/A, training, etc

遵循最佳实践，我们应该应用诸如职责分工之类的原则。这意味着应用程序环境的隔离。特别是，对于给定的应用程序，我们可能会看到它至少包含两个环境：生产环境和用于测试，Q / A，培训等的非生产环境

The value we give to each of these environments could be different, depending on multiple factors. For that reason, amongst other aspects, we won’t apply the same backups for each of these environments. For instance, the default strategy for production databases could be to take a FULL backup every night and a log backup every 3 hours. In contrast, we could decide that we won’t take backups at all for non-production environments except those related to development tasks. For these development databases, we could take a FULL backup once a week (but it should be more frequently).

我们为这些环境提供的价值可能会有所不同，具体取决于多个因素。因此，除其他方面外，我们不会为每个环境都应用相同的备份。例如，生产数据库的默认策略可能是每晚进行一次完整备份，每3小时进行一次日志备份。相反，我们可以决定，除了与开发任务相关的环境以外，对于非生产环境完全不备份。对于这些开发数据库，我们可以每周进行一次完整备份（但应该更频繁）。

Depending on the need for backup operations, we should adjust the Recovery Model option of each database so that we are able to only do the expected operations and there is no side effect with this setting. Let me explain.

根据备份操作的需要，我们应该调整每个数据库的“ 恢复模型”选项，以便我们只能执行预期的操作，并且此设置没有副作用。让我解释。

In order to take a LOG backup for a given database, we need to define its recovery model either to FULL or BULK_LOGGED.

为了对给定的数据库进行LOG备份，我们需要将其恢复模型定义为FULL或BULK_LOGGED 。

Let’s prove this assumption simply by taking a database called [testJEL] which is in SIMPLE recovery model:

让我们简单地通过采用SIMPLE恢复模型中的[testJEL]数据库来证明这一假设：

Using SQL Server Management Studio (SSMS), let’s try to take a LOG backup for that database.

使用SQL Server Management Studio（SSMS），让我们尝试对该数据库进行LOG备份。

We can see that the LOG backup type is not on the list…

我们可以看到LOG备份类型不在列表中……

So, for environments where LOG backups are mandatory, we should ensure that databases are not in SIMPLE recovery model.

因此，对于必须进行LOG备份的环境，我们应确保数据库不在SIMPLE恢复模型中。

But that’s not all! What happens if there are databases set with FULL recovery model in an environment which is not backed up? It’s pretty easy to understand that, sooner or later, either the transaction log or file system hosting this transaction log will be full.

但这还不是全部！如果在没有备份的环境中设置了FULL恢复模型的数据库会怎样？很容易理解，迟早，托管该事务日志的事务日志或文件系统将已满。

To prevent it from happening, we should ensure that every database in such an environment uses the SIMPLE recovery model.

为了防止发生这种情况，我们应该确保在这种环境中的每个数据库都使用SIMPLE恢复模型。

This article will present a solution that monitors if the recovery model for each database on a given SQL Server instance is adequate with the backup policy defined for that server.

本文将提供一种解决方案，该解决方案监视给定SQL Server实例上每个数据库的恢复模型是否适合为该服务器定义的备份策略。

To do so, we will first define some pretty common software environments and the backup policy that should be applied. Once it’s done, we will define a (simple) way to keep track of current server’s environment. Then, we will discuss a stored procedure that we will use in order not only to detect abnormal database settings (regarding its recovery model) but also to correct them.

为此，我们将首先定义一些非常常见的软件环境以及应应用的备份策略。完成后，我们将定义一种（简单的）方法来跟踪当前服务器的环境。然后，我们将讨论一个存储过程，该过程将不仅用于检测异常的数据库设置（关于其恢复模型），还用于纠正它们。

定义环境和示例备份策略 (Defining environments and a sample backup policy)

Here is a table with some common environments and an example backup policy.

这是带有一些常见环境的表以及一个备份策略示例。

In summary, with this kind of backup policy, only production environments should be using a recovery model different from SIMPLE.

总之，使用这种备份策略，仅生产环境应使用不同于SIMPLE的恢复模型。

如何跟踪服务器环境变量 (How to keep track of server environment variables)

In the most standardized environments, we might use different drive letters. For instance, we could use the D:\ drive for system databases, the P:\ drive for actual production ones and the E:\ drive for non-production data. But it’s not an absolute rule that everybody can use…

在最标准化的环境中，我们可能使用不同的驱动器号。例如，我们可以将D：\驱动器用于系统数据库，将P：\驱动器用于实际生产数据库，将E：\驱动器用于非生产数据。但这不是每个人都可以使用的绝对规则。

For that reason, we will keep it simple and store this information in a table, in a database dedicated to DBA tasks and tools. This table should help to answer two questions:

因此，我们将使其保持简单，并将此信息存储在专用于DBA任务和工具的数据库的表中。该表应有助于回答两个问题：

which environment are we in? 我们在哪个环境中？
which databases should I ignore? (i.e. which databases are considered as system databases) 我应该忽略哪些数据库？（即哪些数据库被视为系统数据库）

Storage description

储存说明

We will use a table called [Common].[ApplicationParams] that I already introduced in an article entitled How to report on SQL Server deadlock occurrences. As indicated by its name, it’s a table that holds parameters for applications. Here is its structure:

我们将使用名为[Common]。[ApplicationParams]的表，该表已经在标题为“ 如何报告SQL Server死锁事件”的文章中介绍过。顾名思义，它是一个表，其中包含应用程序的参数。这是它的结构：


[ApplicationName]   [varchar](128)  NOT NULL,
[ParamName]         [varchar](64)   NOT NULL,
[ParamValue]        [varchar](max),
[DefaultValue]      [varchar](max),
[ValueCanBeNULL]    [bit]           DEFAULT 0 NOT NULL,
[isDepreciated]     [bit]           NOT NULL,
[ParamDescription]  [varchar](max)  NULL,
[creationdate]      [datetime]      NOT NULL,
[lastmodified]      [datetime]      NOT NULL

Its primary key is defined using [ApplicationName] and [ParamName] columns. You will find the code for this stored procedure in the Downloads section at the end of this article.

它的主键是使用[ApplicationName]和[ParamName]列定义的。您可以在本文结尾的“ 下载”部分中找到此存储过程的代码。

This table comes with a stored procedure called Common.getApplicationParam that will return the value for a given application parameter. The code to create this stored procedure will also be attached to this article.

该表带有一个称为Common.getApplicationParam的存储过程，该存储过程将返回给定应用程序参数的值。创建此存储过程的代码也将附在本文中。

Now we have a place to store the information, it’s time to define how this information will be stored. This, once again, will be pretty simple. We will actually define an application whose name is built based on two server properties which are:

现在我们有了一个存储信息的地方，该定义该信息的存储方式了。再次，这将非常简单。我们实际上将定义一个应用程序，该应用程序的名称基于两个服务器属性构建：

ServerName 服务器名称
InstanceName 实例名称

So, the value for ApplicationName column will be defined using following query:

因此，将使用以下查询定义ApplicationName列的值：


select @ApplicationName = CAST(SERVERPROPERTY('ServerName') AS VARCHAR(256)) + CASE WHEN SERVERPROPERTY('InstanceName') IS NULL THEN '' ELSE  CHAR(92) /* backslash*/ + CAST(SERVERPROPERTY('InstanceName') AS VARCHAR(256)) END
;

Storage of the information regarding software environment

存储有关软件环境的信息

The parameter corresponding to the software environment will be called “Environment”.

与软件环境相对应的参数将称为“环境”。

Now, we just need to insert a record in that table using following query template:

现在，我们只需要使用以下查询模板在该表中插入一条记录：


INSERT INTO Common.ApplicationParams (ApplicationName, ParamName, ParamValue, DefaultValue, ValueCanBeNULL, isDepreciated,ParamDescription
)
VALUES (@ApplicationName, 'Environment','CHANGEME','CHANGEME',0,0,'Defines the software environment in which this server is'
)

Storage of the information regarding database exclusion list

存储有关数据库排除列表的信息

We will simply use the same pattern as above but the value for ParamName column will be called “SystemDatabases” and the value of ParamValue column will be a comma separated list containing at least following databases:

我们将简单地使用与上述相同的模式，但是ParamName列的值将被称为“ SystemDatabases”，而ParamValue列的值将是一个逗号分隔的列表，其中至少包含以下数据库：

master 主
msdb 数据库
model 模型
tempdb 临时数据库
<Your DBA Toolkit database> <您的DBA Toolkit数据库>

Security concerns

安全问题

There is an important thing to notice about this solution: it highly depends on the contents of Common.ApplicationParams table. One could modify this value without notifying you about this… For that reason, consider adding triggers that disallow the changes to these parameters or that keep track of any modification in that table, or both of them!

关于此解决方案，有一件重要的事情要注意：它高度依赖于Common.ApplicationParams表的内容。可以在不通知您的情况下修改此值...出于这个原因，请考虑添加不允许更改这些参数或跟踪该表中的任何修改或两者的触发器！

核对存储过程的设计 (Design of the checkup stored procedure)

In this section, we will use the Common.ApplicationParams and its records discussed above. We will call this stored procedure [Administration].[CheckRecoveryModelToEnvAdequation]. It will be able to run in 3 modes:

在本节中，我们将使用上面讨论的Common.ApplicationParams及其记录。我们将这个存储过程称为[Administration]。[CheckRecoveryModelToEnvAdequation] 。它将能够在3种模式下运行：

Report – an interactive mode that sums up databases that do not comply to the rules we defined. 报告 –一种交互式模式，用于汇总不符合我们定义的规则的数据库。
Monitoring – designed to fail if any non-compliant database is found. Ideal for a SQL Server Agent Job with enabled notification when the job fails. 监视 –旨在在发现任何不兼容的数据库时失败。当作业失败时启用通知SQL Server代理作业的理想选择。
Correct – finds the databases that do not comply with the rules we defined, tries to set enforce compliance and reports about its execution. This mode will need a parameter that allow user to set a default recovery model to use in case of non-conformity. 正确 –查找不符合我们定义的规则的数据库，尝试设置强制性合规性并报告其执行情况。此模式将需要一个参数，该参数允许用户设置默认恢复模型以在不合格的情况下使用。

Note: We could also add other checks, like checking all databases uses CHECKSUM page verification, which we did using a parameter called @WithPageVerifyCheck.

注意：我们还可以添加其他检查，例如检查所有数据库都使用CHECKSUM页面验证，我们使用名为@WithPageVerifyCheck的参数进行了验证。

In summary, here is the interface for our stored procedure:

总而言之，这是存储过程的接口：


ALTER PROCEDURE [Administration].[CheckRecoveryModelToEnvAdequation] (@ExecutionMode                  VARCHAR(64)  = 'REPORT', -- Possible values: REPORT, MONITORING, CORRECT@WithPageVerifyCheck            BIT          = 1,@DefaultRecoveryMode4Production VARCHAR(256) = 'FULL',@Debug                          SMALLINT     = 0
)

Its algorithm is pretty straight forwards:

它的算法非常简单：

Check parameters are valid 检查参数是否有效
Get back environment related information from Common.ApplicationParams table
从Common.ApplicationParams表中获取与环境相关的信息
Transform the comma-separated value for SystemDatabases parameter to a string that can be used in a dynamic T-SQL query
This means:
1. Adding leading simple quote
2. Replacing any occurrence of comma character to escaped ‘,’
3. Adding trailing simple quote
将SystemDatabases参数的逗号分隔值转换为可在动态T-SQL查询中使用的字符串
这表示：
1. 添加前导简单报价
2. 将任何出现的逗号替换为'，'
3. 添加尾随简单报价
Create a temporary table #dbs
创建一个临时表#dbs
Build a dynamic T-SQL query that stores into #dbs temporary table
构建一个动态T-SQL查询，该查询存储到#dbs临时表中
Run this dynamic query 运行此动态查询
Take appropriate action depending on the value for @ExecutionMode parameter
1. If ‘MONITORING’ -> Fail if #dbs table has records
2. If ‘REPORT’ -> Return records in #dbs table
3. Else -> Loop on each record in #dbs table and try to solve the problem. Then show execution report
根据@ExecutionMode参数的值采取适当的措施
1. 如果'MONITORING' ->如果#dbs表包含记录，则失败
2. 如果为'REPORT' ->返回#dbs表中的记录
3. 否则->在#dbs表中的每个记录上循环并尝试解决该问题。然后显示执行报告

You will find below part of the code for the operation 7.c:

您将在下面的代码7.c中找到部分操作：


WHILE (1 = 1) /* in order to simulate a DO … WHILE*/
BEGINSET @CurrentDbName  = NULL;SET @tsql           = NULL;SET @CurOutcome     = NULL;SELECT TOP 1 @CurrentDbName = DatabaseName,@tsql          = CorrectiveStatementFROM #dbs WHERE CorrectionOutcome IS NULL;IF(@CurrentDbName IS NULL) /* = Loop Condition */BEGINBREAK;END;BEGIN TRY EXEC @ExecRet = sp_executesql @tsql ;IF(@ExecRet <> 0) /* Check success*/BEGINRAISERROR('An error occurred …',12,1);END;SET @CurOutcome = 'SUCCESS';END TRYBEGIN CATCH SELECT @ErrorNumber    = ERROR_NUMBER(),@ErrorLine      = ERROR_LINE(),@ErrorMessage   = ERROR_MESSAGE(),@ErrorSeverity  = ERROR_SEVERITY(),@ErrorState     = ERROR_STATE();/* Keep track of error message in @LogMsg */SET @CurOutcome = 'ERROR';END CATCH ;/* To be able to get out of this infinite loop! */UPDATE #dbs SET CorrectionOutcome = @CurOutcome,CorrectionLog     = @LogMsg WHERE DatabaseName = @CurrentDbName;
END;

The T-SQL code to create the [Administration].[CheckRecoveryModelToEnvAdequation] stored procedure can be found in the ZIP file attached at the end of this article.

可在本文末尾的ZIP文件中找到用于创建[Administration]。[CheckRecoveryModelToEnvAdequation]存储过程的T-SQL代码。

Let’s run this stored procedure against a SQL Server instance which has one non-compliant database:

让我们针对具有一个不兼容数据库SQL Server实例运行此存储过程：

In REPORT mode:

在报告模式下：
In MONITORING mode:

在监视模式下：
In CORRECT mode:

在正确模式下：

自动执行程序 (Automating procedure execution)

The [Administration].[CheckRecoveryModelToEnvAdequation] stored procedure won’t run without being called. We need a process that will call it regularly. To do so, we could create a PowerShell script that uses Invoke-SQLCmd commandlet and schedule it using Windows Tasks Scheduler… Or, we could create a SQL Server Job as SQL Server Agent is very handy!

如果不调用[Administration]。[CheckRecoveryModelToEnvAdequation]存储过程，则该过程将不会运行。我们需要一个可以定期调用的过程。为此，我们可以创建一个使用Invoke-SQLCmd Commandlet的PowerShell脚本，并使用Windows Tasks Scheduler对其进行调度……或者，因为SQL Server代理非常方便，所以我们可以创建一个SQL Server Job！

Here is the procedure for the creation of a SQL Server Agent Job called “[Administration] Check Database Recovery Model”.

这是创建名为“ [Administration] Check Database Recovery Model”SQL Server代理作业的过程。

Note: The following procedure assumes that a Database Mail Operator “The DBA Team” has already In SQL Server Management Studio (SSMS), connect to a SQL Server instance.

注意：以下过程假定数据库邮件操作员“ DBA团队”已经在SQL Server Management Studio（SSMS）中连接到SQL Server实例。

Go down to SQL Server Agent Node and expend it. 转到“ SQL Server代理节点”并扩展它。
Right-click on Jobs node and select New Job.

右键单击Jobs节点，然后选择New Job 。
This opens a New Job dialog. Fill in the General step then go to the Page step.

这将打开“ 新作业”对话框。填写常规步骤，然后转到页面步骤。
Click on the New button at the bottom. It will open a dialog called New Job Step.

单击底部的“ 新建”按钮。它将打开一个名为New Job Step的对话框。
Fill in the General step as follows and go to the “Advanced” page.

按照以下步骤填写“ 常规”步骤，然后转到“高级”页面。
Select the “Include step output in history” checkbox then click on the “OK” button.

选中“将步骤输出包括在历史记录中”复选框，然后单击“确定”按钮。
Create a dedicated schedule. Choose to preferably run it once a day. For instance:a.

创建一个专用的时间表。选择最好每天运行一次。例如：
The most important part now, set the job to notify a Database Mail operator when it fails:

现在，最重要的部分是，将作业设置为在失败时通知数据库邮件操作员：
OK button and the job is created. 确定按钮，然后创建作业。
Test Job Execution 测试作业执行

资料下载 (Downloads)

You’ll find all resources to implement this check on your SQL Server boxes using following link:

您将使用以下链接在SQL Server框中找到实现此检查的所有资源：

All scripts bundle所有脚本包

In order to install it, open scripts one by one following ascending numbering (from 01 to 06). Be aware that the sixth file requires manual intervention for you to define both server environment and databases that should be ignored.

为了安装它，请按照升序编号（从01到06）一一打开脚本。请注意，第六个文件需要手动干预才能定义服务器环境和应忽略的数据库。

参考资料 (References)

Recovery Models (SQL Server) 恢复模型（SQL Server）
How to: Create a Job (SQL Server Management Studio) 如何：创建作业（SQL Server Management Studio）
SERVERPROPERTY (Transact-SQL) 服务器属性（Transact-SQL）

翻译自: https://www.sqlshack.com/how-to-choose-and-check-the-right-database-recovery-model-in-accordance-to-your-backup-strategy/

数据库备份恢复策略