sqlserver收缩数据库后日志变大

数据库压缩后日志会变大……相当复杂。

我记得2 02 2 年为一家公司开发数据库。
压缩后，日志继续增长。
当时我就茫然了，寻找了很久。

首先，压缩操作本身会增加日志。
想想看，在压缩时，数据库必须移动数据页并重写日志来记录这些操作。
就像当你搬家时，你最终可能会比搬家之前得到更多的垃圾。
例如，压缩 5 00 GB 的库可能会产生额外的 1 00 GB 日志。

其次，旧日志没有被清除。
收缩操作并不意味着删除所有旧日志。
可能有些东西早就该清理了，但还没有清理干净。
就像计算机的回收站一样，您已经清空了它，但系统文件可能仍然被引用，但实际上并未被清空。
我看到一个案例，该库在 2 02 2 年 1 0 月被压缩。
日志中仍然有 2 02 1 年未删除的条目，占用了 2 00 GB。

第三，恢复方式过于简单。
如果数据库配置了简单的恢复模型，压缩操作对日志的影响将会受到限制。
在简单模式下，日志仅保留到检查点，并且压缩可能无法完全清除旧日志。
我看到一个项目，数据库采用简单模式压缩，但是日志仍然正常增长，就像没有发生任何操作一样。

四是存在未解决问题。
如果压缩期间数据库中有未提交的事务，则日志应继续增长。
就像你欠了别人钱，你把房子卖了（递减），别人不会因为你卖了房子而原谅你欠的钱。
我正在研究一个案例，其中一个未提交的事务有一个 5 0MB 的日志，收缩操作一直挂在那里，日志像肿瘤一样增长。

解决方案...
首先，更改恢复模式。
进入完全恢复模式，备份日志，然后收缩它。
压缩前清除不必要的日志。
2 02 2 年在银行系统尝试过。
转变后mode 制作日志的备份副本，然后对其进行压缩。
效果立竿见影。

其次，检查您的未完成交易。
使用 DBCC CHECKPOINT 或事务日志备份来完成挂起的事务。
我有一位客户审查了一笔待处理的交易，一旦处理完毕，减少就很顺利。

第三，压缩时指定更多参数。
例如，使用 DBCC SHRINKDATABASE 时，您可以指定压缩百分比。
不要做这种蠢事：切到一半然后停下来。
我发现收缩操作在 3 0% 时挂起，而日志大小增加到 1 TB。

仅此而已...我可能有偏见，但这都是事实。

数据库或者数据库日志文件过大怎么解决

我已经多次看到此类问题。
服务器数据库文件或日志太大会导致一些问题。
实际上有几种解决方案。
先说第一种方案，不限制数据库文件的大小。
当然，这取决于你的服务器上是否有足够的空间。
当时我就遇到了这种情况，就是服务器空间比较大，所以就这么做了。

第二种解决方案是直接清理数据库日志文件。
我们打开数据库，然后选择分离数据库，找到日志文件并将其删除。
添加后，此时会自动生成一个很小的初始日志文件。
这个方法我也用过，效果很好。

第三个选项是收缩数据库日志文件。
您可以对其进行配置，以便将数据库文件或日志文件减小到一定的大小。
这个操作挺专业的，当时我也不懂。
我查了资料后明白了。

不过，无论选择什么方案，都应该根据实际情况而定。
操作之前，说实话当时不太懂，后来发现需要备份数据库。
如果出现问题，至少你可以恢复。

总之，这些方法都是可行的。
使用哪一种取决于您的需要。
操作前记得退后一步，这样万一出了问题，你就无处可哭了。

emby数据库突然变大了

上周 Emby 数据库突然变大。

可能有几个原因。

1 .添加了一个新文件。
2 02 3 年 例如，增加了1 00部高清电影。
每卷还配有大封面图片。
这会占用空间。

2 日志未清除。
系统日志总是很长。
当用户很多时尤其如此。
短短几周内，它就变得巨大了。

3 索引问题。
如果搜索量太大，您将被索引。
指数也会上涨。

4 临时文件不会被删除。
查询时使用临时表。
如果不及时删除，就会拖慢你的速度。

5 它碎成碎片。
删除一些东西后，空间就空了。
没有足够的新数据来填充它。

6 发生安装错误。
它可能在更新过程中被破坏。

清理日志是个好主意。
查看索引如何工作。
您还应该清除临时文件。

算了。