我无法弄清楚如何缩小数据库ldf文件的大小. DBA说我应该使用 使用truncate_only备份日志dbname 虽然看起来它在SQL查询分析器中正确执行,但ldf文件仍然超过2 Gb. **澄清基于以下一些评论和一些答案.***有问题的特定数据库是我的笔记本电脑上的数据库,我只将其用于开发过程.日志文件正在增长到导致完整磁盘的程度.不涉及生产风险.我理解我提出的问题中的方法和我接受的答案在生
假设我有一个SQL Server数据库,其数据文件的初始大小为100 GB,但它只包含10 GB的数据.然后,数据库备份的大小仅为10 GB. 我想将此备份还原到不同的服务器(或同一服务器上的不同数据库),但我不希望它占用与原始磁盘空间相同的磁盘空间(100 GB),这是默认情况下发生的情况. 在进行备份之前我无法缩小原始数据库(它是一个生产数据库,它需要那么多预先分配的空间);恢复完成后,我可以
我有一个目前150GB的数据库文件,但只使用了75GB – 这是因为我将所有索引(另一个75GB)移动到一个新的数据文件.我想从这个数据文件中回收至少部分空间,但是当我试图缩小文件时,它会无限期地“执行”,最终因为网络中断或其他不受我控制而被取消(之后)运行的一天).即使使用“缩小到特定大小”功能并指定它只是修剪10MB也似乎永远不会返回 – 它只是在进程被中断之前一直存在. 还有另一种方法可以让
在SQL Server(本例中为2008)中,如何快速收缩实例上所有数据库的所有文件(包括日志和数据)？我可以通过SSMS并右键单击每个并选择任务 – >收缩,但我正在寻找更快的东西. 我编写了一些“创建数据库”脚本并忘记了它们的默认大小已经膨胀,并且在这个项目中不需要为这些文件保留那么多空间. 当您从GUI执行“任务 – >收缩”时,它实际上会在幕后发出DBCC SHRINKDATABASE命令
在SQL Server 2008中缩小临时数据库时使用的最佳做法是什么？ 使用以下内容有风险吗？ use tempdb
GO
DBCC FREEPROCCACHE -- clean cache
DBCC DROPCLEANBUFFERS -- clean buffers
DBCC FREESYSTEMCACHE ('ALL') -- clean system cache
DBCC FREESES
对于一个项目,我使用的是SQL Server 2008 R2.一个表有一个文件流列. 我做了一些负载测试,现在数据库已经使用了~20GB. 我有空表,除了几个(配置表).但我的数据库仍然占用了大量空间.所以我使用了任务 – >收缩 – >数据库/文件但我的数据库仍然使用16GB的东西. 我发现文件流文件仍然占用了大量空间. 问题是我需要备份这个数据库以将其导出到最终的生产服务器上,如果我指示要压缩
有没有办法估计缩减对SQL Server数据库的缩短时间？是否有可用的工具可以提供一些猜测？ 我们有非常大的数据库,因此最好知道数据库将无法使用多长时间(即使只是以小时为单位的近似估计). 提前致谢！ 很少建议缩小数据库,因为它会导致索引和磁盘碎片.如果确实需要缩小文件,则操作是在线操作,并且根本不会使数据库脱机.
我们正在使用SQL Server 2012的AlwaysOn可用性组功能.常规完整数据库备份和事务日志备份每天在辅助数据库上完成. 我已阅读here在主副本上执行事务日志备份,或者副本副本将两个副本的事务日志标记为可重用.无论如何,事务日志备份大小很大,可以使用shrink文件减少： 我已在本地恢复数据库并执行收缩操作.日志文件大小减少到160 MB. 我的问题是我应该在哪个数据库上对事务日志文件
好的,我们都知道一个大的日志文件会破坏数据库性能. 今天我们正在分析客户端的服务器,看到一些日志文件比数据文件大3900％. 这让我很好奇,如果这两者之间有最好的比例吗？ 我认为对于sql server的数据文件与日志文件的比例没有任何硬性规定. 简单来说,日志文件作为数据库中的变化记录存在.可用于恢复目的.数据更改速度越快,日志文件可能需要的越大. 您在客户端看到的内容更可能是数据库处于完全恢复
我的SQL Server 2008数据库文件(.mdf)文件接近24 MB,但日志文件增长到15 GB.如果我想缩小数据库,需要考虑的重点是什么？ 缩小会导致任何索引碎片,是否会影响我的数据库性能？ 您的问题是您没有在事务日志上进行备份,因此它不能删除日志中的任何值.这与备份数据库不同,应该每天最少完成(我们每15分钟完成一次).在你解决这个问题之前,萎缩对你没有任何好处！ 阅读有关事务日志备份的
我知道缩小是魔鬼：它颠倒了页面顺序,并导致皮肤癌,数据碎片和全球变暖.列表继续……话虽如此,说我有一个100 GB的数据库,我删除50 GB的数据 – 不是在一张桌子上,而是在数据库范围内对旧数据进行一般修剪,覆盖90％的数据表 – 这是否构成缩小数据库的适当用例？ 如果没有,从数据库中删除如此高比例的数据后,采取什么样的措施来清理房屋？我可以想到两个：重建索引和更新统计.还有什么？ 永远不会推荐
这个问题在这里以各种形式提出,但问题归结为： 我知道缩小数据库是有风险的.在这种情况下,我删除了这么多数据,我再也不会使用它了. >我如何缩小数据库？我缩小了哪些文件？ >这样做时我应该考虑什么？ >之后我该怎么办？ >如果它是一个大型数据库怎么办？我可以以较小的增量缩小它吗？ 一些初步警告： >通常称为缩小生产数据库或数据文件的最差做法(日志文件是另一个问题,如this question所述).
DBCC ShrinkDatabase()
DBCC ShrinkFile() >我是否需要运行两个DBCC命令才能缩小数据库？ >上面这两个有什么区别？ 只是… > DBCC ShrinkDatabase()：收缩所有文件 > DBCC ShrinkFile()：只有一个文件 例如,您可能遇到日志备份问题,并且它已失控,因此您运行DBCC ShrinkFile(). 您几乎从不使用ShrinkD
我有一个数据库,它有一个350 MB的数据文件(.mdf)和一个4.9 GB的日志文件(.ldf).恢复模型设置为FULL. 当我尝试缩小日志文件时,它并没有缩小. 我知道缩小数据库并不好,不应该这样做.但我仍然试图缩小日志文件. 当我跑 DBCC SQLPerf(logspace) 我发现日志大小为4932 MB,使用的日志空间为98.76％！ 然后我尝试了这个命令 USE <databasen
SQL 2008日志文件占了23G硬盘空间，而事务日志已经截断（Truncate），实际日志内容很小，1G都不到，想要释放日志文件霸占的多余空间
