什么时候应该使用完整恢复模型，什么时候应该对数据库使用简单恢复模型？
我总是使用完整恢复模式，因为它是默认模式，但今天我遇到了这个错误：
Microsoft OLE DB Provider for SQL Server (0x80040E14) 数据库“DATABASE NAME”的事务日志已满。要找出无法重用日志中的空间的原因，请参阅 sys.databases 中的 log_reuse_wait_desc 列
特定的数据库实际上是我服务器上最小和最不活动的数据库之一，所以我不知道这个数据库上的日志如何被填满，而不是其他数据库。
为了缩小日志并使数据库再次可访问，我将恢复模式从 FULL 更改为 SIMPLE 并缩小了逻辑文件日志，使用以下命令
alter database myDbName SET recovery simple
go
dbcc shrinkfile('LOG FILE LOGICAL NAME', 100)
go
它帮助，但现在我需要了解为什么它的帮助下，如何这种情况开始，如何防止这种情况在未来？
编辑：
每天晚上 1 点，我们都会对服务器上的每个数据库进行脚本备份。这是由 31 行脚本完成的，其中最重要的部分是
set @Filename = 'D:\backup\' + convert(varchar, getDate(), 112) + ' - ' + @DBName + '.bak'
set @Description = 'Full backup of database ' + @Filename
BACKUP DATABASE @DBName TO DISK …检查我的 SQL Server 日志，我看到几个这样的条目：
Date: 08-11-2011 11:40:42
Source: Logon
Message: Login failed for user 'sa'. Reason: Password did not match for the login provided. [CLIENT: 56.60.156.50]
Date: 08-11-2011 11:40:42
Source: Logon
Message: Error: 18456. Severity: 14. State: 8.
Date: 08-11-2011 11:40:41
Source: Logon
Message: Login failed for user 'sa'. Reason: Password did not match for the login provided. [CLIENT: 56.60.156.50]
Date: 08-11-2011 11:40:41
Source: Logon
Message: Error: 18456. Severity: 14. State: 8.
等等..这可能是中国人对我的 SQL Server 的攻击吗？？？！我在 ip-lookup.net 上查找了 IP 地址，它说它是中文的。 …
我目前正在 SaaS BI 产品中创建多租户数据架构。
该产品使用共享数据库和共享架构，但具有租户视图过滤器和租户数据加密（此处的灵感来源：http : //msdn.microsoft.com/en-us/library/aa479086.aspx）
创建视图过滤器时，我可以执行以下两项操作：
CREATE VIEW TenantEmployees AS
SELECT * FROM Employees WHERE TenantID = SUSER_SID()
CREATE VIEW TenantEmployees AS
SELECT * FROM Employees WHERE TenantID = SUSER_ID()
使用 SID() 我正在使用如下所示的安全标识符：
0x3425F1595A67774ABF485CDC30285443
使用 ID() 我正在使用看起来像这样的普通标识符：
265
哪一个绝对最好用，为什么？:) 我希望两者都是绝对独特的，并且永远不会在新的用户登录中重复使用