数据库的简单或完整恢复模型？

alter database myDbName SET recovery simple
go
dbcc shrinkfile('LOG FILE LOGICAL NAME', 100)
go

set @Filename = 'D:\backup\' + convert(varchar, getDate(), 112) + ' - ' + @DBName + '.bak'
set @Description = 'Full backup of database ' + @Filename
BACKUP DATABASE @DBName TO DISK = @Filename WITH INIT , NOUNLOAD , NAME = @Description, NOSKIP , STATS = 10, NOFORMAT

#1 楼

我什么时候应该使用完整恢复模型，什么时候应该对数据库使用简单恢复模型？数据库。当您不需要数据库的时间点恢复，并且上一次完全备份或差异备份足以作为恢复点时，应使用简单恢复模型。 （注意：还有另一种恢复模式，批量记录。有关批量记录恢复模型的更多信息，请参见此参考）。

用于SQL Server的Microsoft OLE DB提供程序（0x80040E14）数据库'的事务日志数据库名称'已满。要找出为什么无法重用日志中的空间的原因，请参见sys.databases中的log_reuse_wait_desc列。 。如果不进行备份，则它将继续物理增长事务日志文件（如果启用了自动增长并且maxsize允许），因为它无法重用事务日志的任何“部分”（虚拟日志文件）。它只能将那些VLF标记为可重复使用，并且在执行事务日志备份时（以及其他一些要求，例如没有活动的事务，某些复制方面等），允许事务日志具有“包装”性质。 br />
要缩小日志并使数据库可再次访问，我使用以下命令将恢复模型从FULL更改为SIMPLE并缩小了逻辑文件日志
......
虽然有帮助，但是现在我需要了解为什么会有所帮助，这种情况如何开始以及将来如何防止这种情况发生？

这对您有帮助，因为通过将数据库设置为简单的恢复模型，您可以告诉SQL Server您不再关心时间点恢复，并且不再需要确保不再保留虚拟日志文件并将其标记为活动的要求，现在检查点进程将这些VLF标记为非活动。
从以下MSDN参考中摘录/引用：在简单的恢复模型下，除非某些因素延迟了日志截断，否则自动检查点将截断事务日志的未使用部分。相比之下，在完整和批量记录的恢复模型下，一旦建立了日志备份链，自动检查点就不会导致日志截断。现在，您可以在事务日志中释放可用空间，从而可以物理上缩小NTFS文件。
值得花一些时间阅读以下内容：

恢复模型
管理事务日志（Gail Shaw） br />可以延迟日志截断的因素

编辑后进行编辑：
该BACKUP DATABASE命令将适用于任一恢复模型。至于常规数据库的缩减……请不要做！！！！认真地，相应地调整数据库的大小，如果您使用完整的恢复模型，那么请确保您正在执行例行且频繁的事务日志文件，不仅要保持事务日志大小不变，而且还要满足恢复点对象。

我们不应该对数据库进行任何其他类型的备份，因此不应该对事务日志进行备份吗？

如果您的数据库正在使用完整恢复模型，那么应该做事务日志备份。如果您的数据库处于简单恢复状态，那么您实际上就无法进行事务日志备份。
关于要使用哪种恢复模式（简单还是完整），我们无法为您做出决定。只有您，您的业务团队和您的SLA可以。