我被困住了。
我刚刚接pipe了SQL Server上的维护工作，而这个维护工作还没有被备份…日志文件已经增长到了1.61TB …是的，1.61TB。
它吞噬了所有可用的磁盘空间。 我试图备份（不能因为日志文件的大小），我试过分离（不能因为日志文件已满），我试着收缩数据库和日志文件（不能.. .get各种错误。）由于几个原因，我处于一个非常艰难的位置。
这不再是一个“使用”的程序，但人们仍然可以访问它来获取数据。
这已经把2TB的硬盘降低到了9.94MB。
帮帮我。
编辑：此外，我不能将恢复模式更改为“完整”做适当的备份…它只是坐着旋转…我要给它几个小时，并检查它。
太痛苦了
通常在这种情况下，最好将数据库的恢复模式切换为Simple，然后对日志文件（而不是数据库本身）进行缩小。 有时你必须缩短日志几次才能把它记下来。
如果在这样做之前无法获得良好的备份，请务必立即获得好回应。
既然你说的数据库是在简单的恢复…尝试这个，在大块，在定期维护期间（将有停机时间）。
USE master Go ALTER DATABASE YourDB SET SINGLE_USER WITH ROLLBACK IMMEDIATE; ALTER DATABASE [YourDB] SET RECOVERY SIMPLE WITH NO_WAIT GO
（我知道，我知道，你说这很简单，但对于简单的恢复，这是一些奇怪的行为。）
USE [YourDB] GO DBCC SHRINKFILE (N'YourDB_log' , 0, TRUNCATEONLY) GO
和
USE [YourDB] GO DBCC SHRINKFILE (N'YourDB_log' , 0) GO
（根据需要重复）
ALTER DATABASE YourDB SET MULTI_USER; GO
然后备份 。
编辑：好的，所以没有工作。 如果你有另一个SQL 2005服务器，你可能想尝试复制mdf到其他服务器并使用
EXEC sp_attach_single_file_db @dbname='YourDb', @physname=N'D:\Path\YourDb.mdf' GO
如果可行，则可以备份旧数据库文件，删除旧数据库，然后重新连接新数据库。 放弃，否认，放弃。 （未提交的交易将会丢失。）
上周刚刚经历过这个问题，我把它切换到简单模式，但是不会让我缩小数据库。 我使用的解决scheme是将备份变为简单，然后创build一个备份，理论上清除日志文件。 在我的服务器上没有，所以我继续前进，并从我刚刚创build的备份恢复数据库，然后删除原来的一切签出。 我的数据库文件大小从200GB到25MB。 但是，这样做的缺点在于，你丢失了所有的备份时间点（这意味着你的最旧的备份现在正在服务器上运行）。 这对我们来说不是问题，但对您来说可能是一个问题。