主页 / dba / 问题 / 114585
Accepted
dwjv
Asked: 2015-09-10 06:41:26 +0800 CST

使用 detach 重新创建 sql 日志

  • 772

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

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

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

显然我会在做任何事情之前做一个完整的备份——无论如何这些每天都会发生。

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

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

sql-server

1 个回答

  1. Best Answer

    不，请不要分离您的数据库并移动日志文件。遵循 Kin、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 靠近压缩驱动器。磁盘空间便宜；让他们投资足够的空间来充分存储与容错相关的数据和副本。

    • 5

相关问题