This article explores the piecemeal database restore SQL Server feature and its benefits to minimize the database restoration.

本文探讨了数据库数据库SQL Server的零碎恢复功能及其可最大程度减少数据库恢复的好处。

RPO和RTO简介 (Introduction to RPO and RTO)

The database administrator’s primary duty is to ensure the availability of the database as per defined RTO and RPO.

数据库管理员的主要职责是按照定义的RTO和RPO确保数据库的可用性。

Let’s understand these two terms.

让我们了解这两个术语。

• Recovery time objective (RTO): It defines the time in which database should be brought online in case of any disaster 恢复时间目标（RTO）：它定义了发生灾难时应使数据库联机的时间
• Recovery point objective (RPO): It refers to data loss. We define maximum data loss in case of any disaster 恢复点目标（RPO）：它是指数据丢失。 我们定义了万一发生灾难时最大的数据丢失

In the following screenshot, we can see that RPO refers to acceptable data loss and RTO refers to the time taken for recovery. It is critical to meet these requirements and make the database available to avoid any business loss:

在以下屏幕截图中，我们可以看到RPO表示可接受的数据丢失，RTO表示恢复所花费的时间。 满足这些要求并使数据库可用以避免任何业务损失至关重要：

We take regular database backups with a combination of full, differential and log backups. We might think of high availability solutions for database recoveries. In this article, we focus on database backups.

我们将常规数据库备份与完整，差异和日志备份相结合。 我们可能会想到用于数据库恢复的高可用性解决方案。 在本文中，我们重点介绍数据库备份。

零碎数据库还原SQL Server (Piecemeal database Restore SQL Server)

Let’s consider a scenario in which you have a production standalone SQL Server, and it crashes. We cannot bring this server up. You need to restore databases on a separate server and bring them online ASAP. The database is huge, and the database restoration might take few hours to finish.

让我们考虑一个场景，其中您有一个生产独立SQL Server，并且崩溃了。 我们无法启动该服务器。 您需要在单独的服务器上还原数据库，并使它们尽快联机。 数据库很大，数据库还原可能需要几个小时才能完成。

SQL Server enterprise edition offers a solution – Piecemeal database. In this technique, we can restore the database on a filegroup level and can reduce the downtime significantly. However, you need to design the database to make use of this piecemeal restoration. We will cover more in the later part of the article.

SQL Server企业版提供了一个解决方案–零碎数据库。 通过这种技术，我们可以在文件组级别还原数据库，并且可以大大减少停机时间。 但是，您需要设计数据库以利用此零碎的还原。 我们将在本文的后半部分介绍更多内容。

In the following example, we have a database, and it contains the following filegroups:

在以下示例中，我们有一个数据库，它包含以下文件组：

• Primary filegroup (default) 主文件组（默认）
• Filegroup A 文件组A
• Filegroup B 文件组B
• Filegroup C 文件组C

DBA usually follow the database backups in the following sequence:

DBA通常按照以下顺序进行数据库备份：

• Full backups weekly 每周完整备份
• Daily differential backup 每日差异备份
• Log backup every hourly 每小时记录一次备份

In the following image, you can see a backup sequence (not mapped with the schedule):

在下图中，您可以看到一个备份序列（未与日程表映射）：

Let’s say the database is down at highlighted point and you want to restore this database using backups on a different server:

假设数据库在突出显示的时间点已关闭，并且您想使用其他服务器上的备份来还原该数据库：

You will follow the database restore sequence as follows:

您将遵循以下数据库还原顺序：

• Restore the latest full backup 恢复最新的完整备份
• Last differential backup 上次差异备份
• Transaction log backup available after the last differential backup 上次差异备份后可用的事务日志备份

The database size is enormous and due to this, it takes a long time for backup restoration. Let’s say this approach took 4-5 hours for database restoration. Can you afford such downtime? No, we need some mechanism to reduce the downtime and bring the application up ASAP. Piecemeal database restores SQL Server helps to minimize database restoration.

数据库规模巨大，因此，备份恢复需要很长时间。 假设这种方法需要4-5个小时来恢复数据库。 您能负担得起这样的停机时间吗？ 不，我们需要某种机制来减少停机时间并尽快启动应用程序。 零碎的数据库还原SQL Server有助于最大程度地减少数据库还原。

As we have multiple filegroups in the database, each filegroup contains the following data:

由于数据库中有多个文件组，因此每个文件组包含以下数据：

• FG- primary – Empty filegroup FG- primary –空文件组
• FG- A – data for department A FG- A –部门A的数据
• FG- B – data for department B FG- B –部门B的数据
• FG C- Archive data FG C-存档数据

The application uses data from FG A and FG B filegroup for all operations. Data in these filegroups should always be available.

该应用程序将FG A和FG B文件组中的数据用于所有操作。 这些文件组中的数据应始终可用。

FG C filegroup contains archive data. The size of this filegroup is approximately 45% of the overall database size. The application uses this data rarely. We can afford comparatively large downtime for this filegroup.

FG C文件组包含存档数据。 该文件组的大小约为整个数据库大小的45％。 应用程序很少使用此数据。 我们可以为该文件组提供较大的停机时间。

We can utilize a piecemeal database to restore SQL Server in this case. Look at the following image, and you can get the following points:

在这种情况下，我们可以利用零散的数据库来还原SQL Server。 看下面的图片，您可以获得以下几点：

• We restored database backups and initially restored FG- Primary, FG- A and FG- B filegroups 我们还原了数据库备份，并最初还原了FG- Primary，FG- A和FG- B文件组
• The database is available, and application can fetch data from online filegroups 该数据库可用，并且应用程序可以从联机文件组中获取数据
• FC-C is still unavailable. It takes time for this filegroup restoration. Therefore, we start the restoration of this particular filegroup once all other filegroups are available FC-C仍然不可用。 恢复该文件组需要花费时间。 因此，一旦所有其他文件组都可用，我们便开始恢复该特定文件组
• FC-C filegroup also becomes online, and now the application can fetch data from this filegroup as well FC-C文件组也变为联机状态，现在应用程序也可以从该文件组中获取数据

Using this piecemeal database restoration, we minimized database downtime and application can be online without waiting for archival filegroup:

使用此零散的数据库还原，我们最大程度地减少了数据库停机时间，并且应用程序可以在线使用，而无需等待档案文件组：

零碎数据库还原SQL Server演示 (Demonstration for Piecemeal database Restore SQL Server)

It sounds good, right. Let’s explore it practically.

听起来不错，对。 让我们进行实际探索。

For this demo, create a SQL database with multiple filegroups, as shown in the above image using the following query:

对于此演示，使用以下查询创建具有多个文件组SQL数据库，如上图所示：

Create database [MultipleFG]
on primary
(name = N'MultipleFG', filename = N'T:\DB\MultipleFG.mdf'),
filegroup [FG-A]
(name = N'MultipleFG_A', filename = N'T:\DB\MultipleFG_A.ndf'),
filegroup [FG-B]
(name = N'MultipleFG_B', filename = N'T:\DB\MultipleFG_B.ndf'),
filegroup [FG-C]
(name = N'MultipleFG_C', filename = N'T:\DB\MultipleFG_C.ndf')
log on
(name = N'MultipleFG_log', filename = N'T:\DB\MultipleFG_log.ldf')

Execute sp_helpfile command to list down all data files, filegroups:

执行sp_helpfile命令以列出所有数据文件，文件组：

The following query creates a table on each filegroup and insert test data in it:

以下查询在每个文件组上创建一个表，并在其中插入测试数据：

• A table in filegroup FG-A

  文件组FG-A中的一个表

  CREATE TABLE dbo.Customers
  (ID           INT NOT NULL, CustomerName NVARCHAR(50) NOT NULL,
  )
  ON [FG-A];
  INSERT INTO Customers
  VALUES
  (1, 'Raj'
  );
  GO
  

• A table in filegroup FG-B

  文件组FG-B中的一个表

  CREATE TABLE dbo.Product
  (ID          INT NOT NULL, productname NVARCHAR(50) NOT NULL,
  )
  ON [FG-B];
  INSERT INTO product
  VALUES
  (1, 'DB'
  );
  GO
  

• A table in filegroup FG-C

  文件组FG-C中的一个表

  CREATE TABLE dbo.archive
  (ID          INT NOT NULL, archivedata NVARCHAR(50) NOT NULL,
  )
  ON [FG-C];
  INSERT INTO archive
  VALUES
  (1, 'archivedata'
  );
  

We perform full, differential, Log backups for creating the backup LSN chain.

我们执行完整的差异日志备份，以创建备份LSN链。

完整的数据库备份 (Full database backup)

BACKUP DATABASE [MultipleFG] TO DISK = N'C:\sqlshack\Demo\MultipleFG.bak' WITH NOFORMAT, INIT, COMPRESSION, STATS = 10;
GO

In the output, we can see it takes a backup of all filegroups and transaction logs in full database backup:

在输出中，我们可以看到它在完整数据库备份中对所有文件组和事务日志进行了备份：

差异数据库备份 (Differential database backup)

BACKUP DATABASE [MultipleFG] TO DISK = N'C:\sqlshack\Demo\MultipleFG_diff.bak' WITH DIFFERENTIAL, NOFORMAT, INIT, COMPRESSION, STATS = 10;
GO

In the differential backup also, it takes the backup of all filegroups and transaction logs.

同样在差异备份中，它将备份所有文件组和事务日志。

交易日志备份 (Transaction log backup)

Insert another record in the archive table stored in FG-C filegroup before taking transaction log backup:

在进行事务日志备份之前，将另一条记录插入FG-C文件组中存储的存档表中：

INSERT INTO archive
VALUES
(2, 'archivedata'
);BACKUP log [MultipleFG] TO DISK = N'C:\sqlshack\Demo\MultipleFG_log.trn' WITH NOFORMAT, INIT, COMPRESSION, STATS = 10;
GO

Below is the output of the transaction log backup:

以下是事务日志备份的输出：

Now, replicate the scenario that the database server is crashed, and you cannot access the server. In this case, you decided to restore this database on a separate server. We will use the same sequence for database restoration – full, differential and log backup.

现在，复制数据库服务器崩溃的情况，并且您无法访问该服务器。 在这种情况下，您决定在单独的服务器上还原该数据库。 我们将使用相同的顺序进行数据库还原-完整，差异和日志备份。

We can verify the database files and their filegroups in the database backup before restoration. Execute RESTORE FILELISTONLY to view the files information inside the full backup.

还原之前，我们可以在数据库备份中验证数据库文件及其文件组。 执行RESTORE FILELISTONLY以查看完整备份中的文件信息。

RESTORE FILELISTONLY from disk='T:\DB\MultipleFG.bak'

We can see backup file information for all data files and their respective filegroups:

我们可以看到所有数据文件及其各自文件组的备份文件信息：

For this demonstration, I will restore the database on the source database instance with a different database name. In this restore database command, you can note that we are restoring primary, FG-A, and FG-B filegroups.

对于此演示，我将使用其他数据库名称在源数据库实例上还原数据库。 在此还原数据库命令中，您可以注意到我们正在还原主文件组，FG-A和FG-B。

We use NORECOVERY clause so that subsequent backups can be restored on this database. We cannot restore further backups without NORECOVRY clause because SQL Server already performed database recovery and the database is online.

我们使用NORECOVERY子句，以便可以在此数据库上还原后续备份。 如果没有NORECOVRY子句，我们将无法还原更多的备份，因为SQL Server已经执行了数据库恢复并且数据库处于联机状态。

还原数据库的完整数据库备份，以实现零散的数据库还原SQL Server（主，FG-A和FG-B文件组） (Restore full database backup for piecemeal database restore SQL Server (Primary, FG-A and FG-B filegroups) )

RESTORE DATABASE [MultipleFG_clone] FILEGROUP = 'Primary', FILEGROUP = 'FG-A', FILEGROUP = 'FG-B' FROM DISK = N'T:\DB\MultipleFG.bak' WITH FILE = 1, MOVE N'MultipleFG' TO N'T:\database\MultipleFG.mdf', MOVE N'MultipleFG_A' TO N'T:\database\MultipleFG_A.ndf', MOVE N'MultipleFG_B' TO N'T:\database\MultipleFG_B.ndf', MOVE N'MultipleFG_log' TO N'T:\database\MultipleFG_log.ldf', NORECOVERY, PARTIAL, STATS = 10;

In the output messages, it shows the data files that belong to filegroups primary, FG-A and FG-B. We do not have an entry for filegroup FG-C because we have not specified filegroup FG-C in the restore database command:

在输出消息中，它显示了属于主文件组FG-A和FG-B的数据文件。 我们没有文件组FG-C的条目，因为没有在restore数据库命令中指定文件组FG-C：

还原差异数据库备份以实现零散数据库还原SQL Server（主，FG-A和FG-B文件组） (Restore differential database backup for piecemeal database restore SQL Server (Primary, FG-A and FG-B filegroups))

Let’s restore a subsequent differential backup. We do not need to specify the filegroups in the differential backup restoration command. It automatically restores content for primary, FG-A and FG-B filegroups:

让我们还原后续的差异备份。 我们不需要在差异备份还原命令中指定文件组。 它会自动还原主要，FG-A和FG-B文件组的内容：

RESTORE DATABASE [MultipleFG_clone] FROM DISK = N'T:\DB\MultipleFG_diff.bak' WITH FILE = 1, NORECOVERY, STATS = 10;

还原事务日志备份以进行零散的数据库还原SQL Server（主，FG-A和FG-B文件组） (Restore transaction log backup for piecemeal database restore SQL Server( Primary, FG-A and FG-B filegroups))

Restore transaction log backup after differential backup restoration with the following query:

差异备份还原后，使用以下查询还原事务日志备份：

RESTORE DATABASE [MultipleFG_clone] FROM DISK = N'T:\DB\MultipleFG_log.trn' WITH FILE = 1, NORECOVERY, STATS = 10;

Once we have done database restoration using full, differential and transaction log backup, we can perform database recovery using WITH RECOVERY clause. We can access the database after the recovery:

使用完整，差异和事务日志备份完成数据库还原后，就可以使用WITH RECOVERY子句执行数据库还原。 恢复后我们可以访问数据库：

RESTORE DATABASE [MultipleFG_clone] WITH RECOVERY;

The database is online now, and we can access the data from FG-A and FG-B filegroups:

该数据库现已在线，我们可以从FG-A和FG-B文件组访问数据：

• FG-A filegroup table

  FG-A文件组表

  SELECT *
  FROM Customers;
  

• FG-B filegroup table

  FG-B文件组表

  SELECT *
  FROM Product;
  

  

We have not restored the FG-C filegroup, and if we try to access table archive from FG-C, we get the following error message. We cannot retrieve this record because the table resides in a filegroup that is not online:

我们尚未还原FG-C文件组，并且如果尝试从FG-C访问表存档，则会收到以下错误消息。 我们无法检索该记录，因为该表位于不在线的文件组中：

Select * from archive

We have partially recovered the database. In the example above, we saw that FG-C contains archive data and we have longer restore time for it, but the application will be functional with other filegroups. At this point, we can run the application with minimal impact on database availability. It is the benefit of piecemeal database restoration.

我们已经部分恢复了数据库。 在上面的示例中，我们看到FG-C包含存档数据，并且恢复时间更长，但是该应用程序可以与其他文件组一起使用。 至此，我们可以在不影响数据库可用性的情况下运行该应用程序。 这是零碎数据库还原的好处。

We can check the status of filegroups using the following query:

我们可以使用以下查询来检查文件组的状态：

select file_id, name, state_desc, physical_namefrom [MultipleFG_clone].sys.database_files

In the screenshot, we can see status RECOVERY_PENDING for the filegroup FG-C:

在屏幕截图中，我们可以看到文件组FG-C的状态RECOVERY_PENDING：

Let’s restore the remaining filegroup FG-C as well. We require restoration of all backups again but for this filegroup only.

让我们也还原剩余的文件组FG-C。 我们要求再次还原所有备份，但仅限此文件组。

还原完整数据库备份，以实现零散数据库还原SQL Server（FG-C文件组） (Restore full database backup for piecemeal database restore SQL Server (FG-C filegroup))

RESTORE DATABASE [MultipleFG_clone] FILEGROUP = 'FG-C' FROM DISK = N'T:\DB\MultipleFG.bak' WITH FILE = 1, MOVE N'MultipleFG_C' TO N'T:\database\MultipleFG_C.ndf', STATS = 10;

In the output, we get an entry for FG-C filegroup only because we have specified FG-C on the restore database command:

在输出中，仅由于在restore database命令上指定了FG-C，我们才获得FG-C文件组的条目：

还原差异数据库备份以实现零散数据库还原SQL Server（FG-C文件组） (Restore differential database backup for piecemeal database restore SQL Server (FG-C filegroup))

RESTORE DATABASE [MultipleFG_clone] FILEGROUP = 'FG-C' FROM DISK = N'T:\DB\MultipleFG_diff.bak' STATS = 10;

还原事务日志备份以实现数据库的零碎还原SQL Server（FG-C文件组） (Restore transaction log backup for piecemeal database restore SQL Server(FG-C filegroup))

It automatically performs recovery for the FG-C filegroup:

它会自动对FG-C文件组执行恢复：

RESTORE DATABASE [MultipleFG_clone] FROM DISK = N'T:\DB\MultipleFG_log.trn';

Let’s check the status of all data files using sys.database_files:

让我们使用sys.database_files检查所有数据文件的状态：

select file_id, name, state_desc, physical_name
from [MultipleFG_clone].sys.database_files

In the output, we can verify that the complete database is online and accessible:

在输出中，我们可以验证整个数据库是否联机且可访问：

结论 (Conclusion)

In this article, we explored the Piecemeal database Restore SQL Server. It is useful for the database restoration of a large database. We should plan the database structure in a way to enable piecemeal restoration effectively. It can help a DBA to minimize the application downtime.

在本文中，我们探讨了Piecemeal数据库Restore SQL Server。 这对于大型数据库的数据库还原很有用。 我们应该以一种有效地进行零散恢复的方式来计划数据库结构。 它可以帮助DBA最大限度地减少应用程序停机时间。

翻译自: https://www.sqlshack.com/piecemeal-restore-in-sql-server-database/