小编RGO*_*RGO的帖子

请查看下面的快照，其中显示了我管理的其中一个 SQL Server 实例的所有数据文件和事务日志文件的时间戳。这是一个生产实例。

今天是 2019 年 12 月 27 日。但是，如您所见，所有时间戳都显示更旧的时间。

事实是，我在几天前的 12 月 24 日拍了这张快照。但是，当我今天检查时，情况仍然没有变化。

上面的快照取自用户数据库。我还检查了驻留在单独驱动器上的系统数据库，并拍摄了文件时间戳的快照，如下所示：

这些数据库当然不是超级活跃的。但是，我确信交易一直在运行。此外，我查看了其中一些的“架构更改历史记录”报告，并可以确认我们的维护工作最近在 12 月 26 日就一直在工作并重建索引。

数据库都在完全恢复模型中（尽管这可能无关紧要 - 只是一个事实）。操作系统为 Windows NT 6.0（= Windows Server 2007），SQL Server 版本为 2008 SP3。操作系统和 SQL Server 都将于明年第一季度进行升级。同样从上面的快照中可以明显看出，数据文件和日志文件都驻留在同一个磁盘驱动器和文件夹中，我“继承”的这台服务器的配置当然不是最好的。因此，希望所有这些都将在几个月后进行的计划升级/迁移活动中得到修复。

现在我的问题是为什么这些文件的时间戳没有得到更新，尽管数据库仍然处于活动状态？（即使手动运行 Checkpoint 也没有改变任何东西）。然后，如果事务日志文件没有得到更新，备份是否良好可靠？它们真的包含它们应该包含的记录吗？

我在数据库中通过清理看到以下数量的登录、注销和注销：

SQL> select action_name, count(*) qty
from Dba_audit_session
group by action_name
order by 1;  2    3    4

ACTION_NAME                        QTY
--------------------------- ----------
LOGOFF                         1946180
LOGOFF BY CLEANUP               754683
LOGON                             1026

登录少于注销的 0.1% 是没有意义的。

任何想法为什么？

某些 SQL Server 更新发生在维护时段之外，这导致服务器重新启动。我怎样才能阻止这种情况在未来再次发生？

以下是我在查看 Windows 更新设置时可以看到的内容：

昨天报了以下错误：

无法为数据库 'Z' 中的对象 'dbo.X'.'Y' 分配空间，因为 'PRIMARY' 文件组已满

工程师从表中删除了一些记录后，错误被清除。我昨天无法检查详细信息，因为我实际上没有管理员访问权限。我的访问后来被排序。当我今天检查数据库大小时，我观察到以下情况：

有 312.63 MB 可用空间，这意味着有 312.63 MB 空间分配给数据库但尚未分配给任何页面或对象（如果我错了，请纠正我）。我不希望昨天的删除操作释放任何页面/空间。那么为什么数据库不能使用这个随时可用并分配给数据库的空间呢？

我忽略了文件自昨天以来进一步增长的可能性，因为在事件发生时已经有足够的磁盘空间可用。这是一个 SQL Server 2016 SP1 Express Edition，它已启用自动增长设置，文件增长大小为 64 MB，最大大小设置为Unlimited。考虑：

  10184 MB + 64 MB = 10248 MB > 10240 MB (= 10 GB = maximum allowed DB size in Express Edition)

很明显，该文件不能（也不能）进一步增长。

虽然数据库无法调整文件大小，但它仍然可以使用任何可用空间。那为什么没有发生呢？

会不会是昨天delete后有对象被drop掉了？

我是从 Oracle DBA 背景开始学习 SQL Server 数据库管理的。所以也许很自然，我总是试图了解两个 DBMS 之间的差异以及相似之处。最近让我印象深刻的一个问题是，日志记录是否应该多次备份，如何备份？在 Oracle 数据库中，假设数据库处于“Archive-Log”数据库模式，“redo”日志文件被归档为单独的“archived redo log”文件，其作用在时间点恢复的情况下至关重要方案，因此，定期备份这些文件非常重要。很多时候，DBA 对每个“归档重做日志”文件进行多次备份，例如，如果某个特定磁带丢失或损坏，在其他备份设备上的其他地方仍然可以使用相同备份的另一个副本。这显然将提供高级别的数据丢失保护。

众所周知，在SQL Server中，有包含日志记录的事务日志，它对执行数据库恢复起着至关重要的作用。现在我的问题是：对于处于“完整”恢复模式的数据库，是否可以多次备份日志记录？如果可能的话，这是个好主意吗？如何做到这一点？