根据我在大多数SQL server上的经验，没有事务日志的备份。 完全备份或差异备份是常见的实践，但事务日志备份确实很少。 因此事务日志文件会一直增长(直到磁盘满为止)。 在这种情况下，恢复模型应该设置为“simple”。 不要忘记修改系统数据库“model”和“tempdb”。

数据库“tempdb”的备份没有任何意义，因此这个数据库的恢复模型应该总是“简单”的。

如果不使用事务日志进行恢复(即只进行完全备份)，可以将恢复模式设置为“简单”，那么事务日志很快就会缩小，再也不会被填满。

如果您使用SQL 7或2000，您可以在数据库选项选项卡中启用“截断检查点日志”。这有同样的效果。

显然，在生产环境中不建议这样做，因为您将无法恢复到某个时间点。

不推荐John推荐的这种技术，因为没有日志文件就不能保证数据库会附加。将数据库从full更改为simple，强制设置检查点并等待几分钟。SQL Server将清除日志，然后使用DBCC SHRINKFILE收缩日志。

它发生在我身上，数据库日志文件是28 gb。

你能做些什么来减少这种情况呢? 实际上，日志文件是SQL服务器在事务发生时保存的文件数据。对于要处理的事务，SQL服务器为其分配页面。但在交易完成后，它们不会突然被释放，希望可能会有类似的交易到来。这撑起了空间。

步骤1: 首先在已探索的数据库查询中运行此命令 检查点

步骤2: 右键单击数据库 任务>备份 选择备份类型为事务日志 添加目标地址和文件名以保存备份数据(.bak)

再次重复此步骤，此时给出另一个文件名

步骤3: 现在转到数据库 右键单击数据库

>收缩>文件 “文件类型”选择“日志” 收缩动作释放未使用空间

步骤4:

检查日志文件 通常在SQL 2014中可以在

C:\Program Files\Microsoft SQL Server\MSSQL12。MSSQL2014EXPRESS \该\数据

在我的例子中，它从28 GB减少到1 MB

数据库→右键单击属性→文件→添加另一个不同名称的日志文件，并将路径设置为与旧日志文件相同，只是文件名不同。

数据库自动获取新创建的日志文件。

对MDB文件进行备份。 停止SQL服务 重命名日志文件 启动服务

(系统将创建一个新的日志文件。)

删除或移动重命名的日志文件。