2

我们目前正在将我们的 LIMS（实验室信息管理系统）从 Oracle 迁移到 MS-SQL，我在某个领域遇到了困难。我们运行三个独立的实例：生产、开发和测试。Prod 实例是实况实例，由实验室使用，dev 实例是我在开发新功能的地方，而测试实例是在部署到生产之前测试这些新功能的地方。在这种情况下，我会定期将生产数据库复制（使用备份/恢复）到其他两个实例，以便我使用与操作员相同的配置。但是，生产数据库包含大量我在开发/测试实例中不需要的存档数据，因此我没有将这些表包含在备份中——这为我节省了数十分钟的时间。Oracle 对此很有用，因为您可以指定要包含在备份中的表。但是，AFAIK 这在 MS-SQL 中是不可能的，但可以做的是将活动表和存档表放入不同的文件组中。然后可以单独备份这些文件。

我已经成功地创建了我的 PRIMARY 文件组的备份，但是我很难恢复它。有时命令完成但数据库仍然无法访问，我被告知恢复尚未完成 - 其他时候它只是拒绝执行命令。这似乎与事务日志有关，但这扩展了我的知识。

我正在使用的备份命令是： BACKUP DATABASE production FILEGROUP='PRIMARY' TO DISK='C:\Temp\db.bak' WITH FORMAT,COPY_ONLY

我正在尝试的还原命令是： RESTORE DATABASE development FROM DISK='C:\Temp\db.bak' WITH REPLACE,NORECOVERY它告诉我“备份集包含一个数据库的备份，而不是现有的‘开发’数据库”。

目前源和目标在 SQL Server 的同一个实例中，但将来它们将在完全不同的机器上，可能没有直接连接（所以我必须通过某种类型的文件传输）。两者都配置了完全恢复。

我发现了一些类似的问题，但它们并没有真正帮助我。这是创建我的生产数据库的部分克隆的合理方法吗？如何让我的恢复命令按我的需要工作？

4

2 回答 2

2

您在正确的轨道上，但是由于您处于完全恢复模式，因此您还需要备份尾日志，并恢复自上次备份文件组以来的日志文件。如果日志备份不经常发生（例如每隔一小时），那么您只需在恢复文件组后进行尾部日志备份并恢复此单个日志文件。您还需要向restore 命令添加WITH PARTIAL和。FILEGROUP = 'PRIMARY'

它看起来像这样：

BACKUP DATABASE production FILEGROUP='PRIMARY' TO DISK='C:\Temp\db.bak' WITH FORMAT
GO

BACKUP LOG productionLog TO DISK 'C:\Temp\tail.trn'
GO

RESTORE DATABASE development FILEGROUP = 'Primary' FROM DISK='C:\Temp\db.bak' WITH PARTIAL,NORECOVERY
RESTORE LOG FROM DISK 'C:\Temp\tail.trn' WITH RECOVERY
于 2018-07-25T05:02:54.543 回答
0

非常感谢您的建议 - 它让我感动，但我仍然遇到问题。我现在使用以下命令：

BACKUP DATABASE Prod FILEGROUP='PRIMARY' TO DISK='C:\Temp\Temp\prod.bak' WITH FORMAT; BACKUP LOG Prod TO DISK='C:\Temp\Temp\prod.trn'; RESTORE DATABASE Test FILEGROUP='PRIMARY' FROM DISK='C:\Temp\Temp\prod.bak' WITH PARTIAL,RECOVERY; RESTORE LOG Test FROM DISK='C:\Temp\Temp\prod.trn' WITH RECOVERY;

我得到以下回复：

Processed 376 pages for database 'Prod', file 'Prod' on file 1. Processed 2 pages for database 'Prod', file 'Prod_log' on file 1. BACKUP DATABASE...FILE=<name> successfully processed 378 pages in 0.082 seconds (36.013 MB/sec). Processed 7 pages for database 'Prod', file 'Prod_log' on file 6. BACKUP LOG successfully processed 7 pages in 0.007 seconds (7.254 MB/sec). Msg 3154, Level 16, State 4, Line 3 The backup set holds a backup of a database other than the existing 'Test' database. Msg 3013, Level 16, State 1, Line 3 RESTORE DATABASE is terminating abnormally. Msg 3154, Level 16, State 4, Line 4 The backup set holds a backup of a database other than the existing 'Test' database. Msg 3013, Level 16, State 1, Line 4 RESTORE LOG is terminating abnormally.

如果我使用WITH REPLACE而不是WITH PARTIAL我收到不同的错误消息：

The database cannot be recovered because the log was not restored. The roll forward start point is now at log sequence number (LSN) 35000000203200001. Additional roll forward past LSN 35000000203200001 is required to complete the restore sequence. This RESTORE statement successfully performed some actions, but the database could not be brought online because one or more RESTORE steps are needed. Previous messages indicate reasons why recovery cannot occur at this point. RESTORE DATABASE ... FILE=<name> successfully processed 378 pages in 0.024 seconds (123.046 MB/sec). Msg 4326, Level 16, State 1, Line 4 The log in this backup set terminates at LSN 35000000092800001, which is too early to apply to the database. A more recent log backup that includes LSN 35000000203200001 can be restored. Msg 3013, Level 16, State 1, Line 4 RESTORE LOG is terminating abnormally.

如果我WITH NORECOVERY在数据库还原上使用，该命令会成功，但RESTORE LOG然后会给我：

RESTORE DATABASE ... FILE=<name> successfully processed 378 pages in 0.032 seconds (92.285 MB/sec). Msg 4326, Level 16, State 1, Line 4 The log in this backup set terminates at LSN 35000000092800001, which is too early to apply to the database. A more recent log backup that includes LSN 35000000203200001 can be restored. Msg 3013, Level 16, State 1, Line 4 RESTORE LOG is terminating abnormally.

在任何情况下，目标数据库都停留在“正在恢复”状态。

于 2018-07-27T02:43:15.400 回答