文件还原的意外结果

SQL Server 的最高优先级是遵守ACID属性。这意味着，无论您做什么，您的数据库始终在事务上保持一致。

但是，您尝试执行的操作可能会使您陷入不一致的状态。想一想解释 ACID 属性的标准示例：银行帐户。假设您有两个帐户驻留在不同的文件组中（例如，两个帐户表或一个具有分区）。现在您在事务中将资金从文件组一转移到文件组二。然后你去恢复文件组一到传输之前。这导致钱现在同时存在于两个账户中，这显然不是理想的状态。

那么，您的示例中发生了什么？

6) 文件组成功恢复到灾难发生前的某个时间点。但是它处于“正在恢复”状态并且不可访问。

8) 日志恢复使文件组与数据库的其余部分同步（在事务级别）。为此，日志备份中捕获的所有已提交事务都将重新应用于该文件组。但是，删除是一个已提交的事务，因此它也会重新执行。这使数据库保持一致，但表为空。

您指向的 Technet 示例假设文件由于某些外部原因（例如驱动器故障）而脱机。在这种情况下，所描述的恢复是有意义的，因为您希望重新应用所有事务。

在您的情况下，您需要在其他地方恢复数据库，然后将数据复制回原始表。为此，您可以只恢复包含相关数据的文件组和主文件组。您不能只恢复辅助文件组，主文件组也必须始终恢复。这是建议不要在主文件组中包含任何数据的原因之一。这样一来，必须恢复那个的影响也很小。

在恢复序列之后，您的表中没有数据，因为您恢复了上次日志备份的所有事务，其中包括从表中删除的数据。

您基本上要寻找的是时间点还原。这是一个工作示例（注意：正如 Sebastian 已经暗示的那样，在对文件执行时间点还原时需要还原 PRIMARY 文件组）：

use AdventureWorks2012RestoreTest;
go

-- create a new filegroup
--
alter database AdventureWorks2012RestoreTest
add filegroup USERTABLES_01;
go

-- create a new data file in the new filegroup
--
alter database AdventureWorks2012RestoreTest
add file
(
    name = Aw2012Rt_data2,
    filename = '<backup dir>\Aw2012Rt_data2.ndf',
    size = 2 MB
) to filegroup USERTABLES_01;

-- create the duplicate table on the new filegroup
--
create table [HumanResources].[Employee_01]
(
    [BusinessEntityID] [int] NOT NULL,
    [NationalIDNumber] [nvarchar](15) NOT NULL,
    [LoginID] [nvarchar](256) NOT NULL,
    [OrganizationNode] [hierarchyid] NULL,
    [OrganizationLevel] [smallint] NULL,
    [JobTitle] [nvarchar](50) NOT NULL,
    [BirthDate] [date] NOT NULL,
    [MaritalStatus] [nchar](1) NOT NULL,
    [Gender] [nchar](1) NOT NULL,
    [HireDate] [date] NOT NULL,
    [SalariedFlag] [bit] NOT NULL,
    [VacationHours] [smallint] NOT NULL,
    [SickLeaveHours] [smallint] NOT NULL,
    [CurrentFlag] [bit] NOT NULL,
    [rowguid] [uniqueidentifier] NOT NULL,
    [ModifiedDate] [datetime] NOT NULL
) on USERTABLES_01;
go

-- populate the new table
--
insert into HumanResources.Employee_01
select *
from HumanResources.Employee;

-- get initial count of table
--
select count(*)
from HumanResources.Employee_01;
-- 290

-- initiate a full backup of the database
--
backup database AdventureWorks2012RestoreTest
to disk = '<backup dir>\Aw2012RT_full.bak'
with init;
go

-- because we need to do a point-in-time recovery we might as
-- well get the datetime stamp right before the delete
--
select getdate();
-- 2014-01-08 05:34:56.767

-- "accidentally" delete all data
--
delete from HumanResources.Employee_01;

-- verify all of the data is gone
--
select count(*)
from HumanResources.Employee_01;
-- 0

-- start the restore sequence
--
use master;
go

-- you need to restore the PRIMARY filegroup in order for point-in-time recovery
-- othewise you'll get the following error message:
-- "Point-in-time recovery is not possible unless the primary filegroup is part 
-- of the restore sequence. Omit the point-in-time clause or restore the primary filegroup."
--
backup log AdventureWorks2012RestoreTest
to disk = '<backup dir>\Aw2012RT_log.trn'
with init, norecovery;
go

restore database AdventureWorks2012RestoreTest
file = 'Aw2012Rt_data2',
filegroup = 'PRIMARY'
from disk = '\\stringermain\VmShare\temp\Aw2012RT_full.bak'
with norecovery;
go

-- now you can do point-in-time recovery with the STOPAT clause
-- specifying a datetime stamp before the delete operation
--
restore log AdventureWorks2012RestoreTest
from disk = '<backup dir>\Aw2012RT_log.trn'
with 
    stopat = '2014-01-08 05:34:56.767',
    recovery;
go

use AdventureWorks2012RestoreTest;
go

-- verify that we now have data in the table
--
select count(*)
from HumanResources.Employee_01;
-- 290

正如 Sebastian 还提到的那样，如果您希望取回已删除的数据，那么在其他地方恢复并复制数据可能本质上更容易。但我想展示你更正的测试用例只是为了说明你将如何进行时间点恢复。