使用 detach 重新创建 sql 日志

Question

好的，在我开始之前，我知道你不应该这样做......

我继承了一个 SQL Server 实例 (2008 R2 SP2 x64)，它有一个带有非常大事务日志的数据库（完整模式，没有 tlog 备份），并且日志位于压缩文件夹中（不要问）。我需要解决这个问题，并认为我最好的方法是分离数据库（没有理由不检查点）并重新附加 mdf 忽略 ldf，以便在适当的文件夹结构中创建一个新的。然后我可以实施一个不错的备份策略。

我真的不想备份这个 tlog，因为它很大，而且在一个压缩文件夹中，所以谁知道它到底有多大。另一种选择是简单地截断 tlog，但这已被弃用......也许将 tlog 备份到 /dev/null （无论 Windows equiv 是什么）？

显然，我会在任何事情之前进行完整备份 - 无论如何，这些每天都会发生。

我想我要问的是，这里最安全的方法是什么？

编辑：实际上，我只是想 - 如果我每天进行完整备份，那么 tlog 不会在 BU 之后立即没用吗？

Answer 1

不，请不要分离您的数据库并移动日志文件。按照从健，spaghettidba，和其他人的意见，但首先需要一个完整的备份（您需要调整db您的数据库名称，db_log以及db.ldf日志文件的逻辑和物理名称，根据sp_helpfile）：

BACKUP DATABASE db TO DISK = 'backup location' WITH INIT;

-- set it to single user
ALTER DATABASE db SET SINGLE_USER WITH ROLLBACK IMMEDIATE;

-- set the recovery mode to simple
ALTER DATABASE db SET RECOVERY SIMPLE;

-- run checkpoint twice
CHECKPOINT;
CHECKPOINT;

-- shrink the log file to something more reasonable (please not 1 MB):
DBCC SHRINKFILE(db_log, 1024); -- 1 GB

-- take the database offline
ALTER DATABASE db SET OFFLINE;

-- tell the system catalogs that you're moving the file
ALTER DATABASE db MODIFY FILE 
  (NAME = db_log, FILENAME = 'x:\other_drive\db.ldf');

停在这里。这应该告诉你：

系统目录中的文件“db_log”已被修改。下次启动数据库时将使用新路径。

因此，将 LDF 文件（现在应该大约为 1 GB）移动到x:\other_drive\然后使数据库重新联机和多用户：

ALTER DATABASE db SET ONLINE;
ALTER DATABASE db SET MULTI_USER;

（老实说，我觉得恢复备份更安全WITH MOVE；任何时候你开始移动文件，你都会面临丢失/损坏的风险。但是只要你在开始这个过程之前就进行了完整备份，那应该保护你。）

现在，如果您不关心事务日志并且不关心了解为什么它们很重要，那么将事情留在简单恢复中。但我真的，真的，真的强烈建议你完整阅读这篇文章：

• 为什么事务日志不断增长或空间不足？

尝试了解您的雇主对数据丢失的容忍度，因为我可以向您保证，大多数企业不能对此放任自流，而且 24 小时的丢失是绝对不能接受的。如果您的工作场所是这样，那么将数据库设置回完整恢复，并立即进行完整+日志备份以启动日志备份链：

ALTER DATABASE db SET RECOVERY FULL;

BACKUP DATABASE db TO DISK = N'backup_location\db_full.bak';
GO
BACKUP LOG db TO DISK = N'backup_location\db_init.trn';

然后创建某种作业，将全天进行定期日志备份。每小时可能还不够；再次，确保数据的所有者了解不经常备份日志所涉及的权衡。我怀疑他们甚至可以接受一个小时的数据丢失。不，.trn 文件很少会像 LDF 本身一样大；这只会发生在极端情况下，因为自上次日志备份以来发生的活动导致日志文件爆炸。

另外，不要让 SQL Server 靠近压缩驱动器。磁盘空间便宜；让他们投资足够的空间来充分存储与容错相关的数据和副本。