我从 Oracle DBA 背景来到 SQL Server 数据库管理。所以也许很自然，我总是试图理解这两个 DBMS 之间的差异以及相似之处。最近让我印象深刻的一个问题是，日志记录是否应该备份多次，如何备份？在 Oracle 数据库中，假设数据库处于“归档日志”数据库模式，“重做”日志文件被归档为单独的“归档重做日志”文件，其作用在时间点恢复的情况下至关重要因此，定期备份这些文件非常重要。很多时候，DBA 会对每个“归档重做日志”文件进行多次备份，例如，如果某个特定磁带丢失或损坏，在其他备份设备上的其他地方仍然会有相同备份的另一个副本。这显然会提供高级别的保护以防止数据丢失。
众所周知，在 SQL Server 中，存在包含日志记录的事务日志，它们对于执行数据库恢复起着至关重要的作用。现在我的问题是：对于处于“FULL”恢复模式的数据库，是否可以多次备份日志记录？如果可能的话，这是个好主意吗？以及如何做到这一点？
我试图找出 SQL Server 2016 每小时或每天生成的事务日志数据量。“生成的数据”是指每小时（或每天）有多少数据（以字节/KB/等为单位）写入磁盘。
有没有办法找到这个？
我们的数据库处于完全恢复模式，并且我们确实有定期的事务日志备份。因此，我认为在 msdb 中查询备份元数据可能有助于实现这一目标。行得通吗？它会给我正确和可靠的结果吗？
第二个选项可能是查看事务日志文件发生的读/写 IO 量。这个能用吗？如果是，我该怎么做？是否有任何 SQL Server DMV 提供此类信息？Windows 工具呢？（如 Windows 性能监视器）？
如果可能的话，我更喜欢上面的第二个选项，因为它不需要事务日志备份。因此，它甚至可以与 SIMPLE 恢复模型数据库一起使用。所以，我的问题是，这可能吗？
还有其他选择吗？比如现成的 SQL Server 工具或视图？
请注意，我需要这些数据，因为我们正在尝试估计如果我们在云中创建（近）实时复制数据库所需的网络 IO 量。所以，我认为我们应该以某种方式测量归因于事务日志文件的 IO 量。我的假设是否正确，即所需的 IO 将等于事务日志文件的 Io 量？这就是 SQL Server 事务复制的工作方式吗？（即通过将 VLF 发送到复制站点）？
一些 SQL Server 更新发生在维护窗口之外，导致服务器重新启动。我怎样才能阻止这种情况在未来再次发生？
以下是我在查看 Windows 更新设置时可以看到的内容：
昨天报了如下错误：
无法为数据库“Z”中的对象“dbo.X”.“Y”分配空间，因为“PRIMARY”文件组已满
工程师从表中删除了一些记录后，错误被清除。我昨天无法检查详细信息，因为我实际上没有管理员访问权限。我的访问权限稍后进行了排序。当我今天检查数据库大小时，我观察到以下内容：
有 312.63 MB 可用空间，这意味着有 312.63 MB 空间分配给数据库但尚未分配给任何页面或对象（如果我错了，请纠正我）。我预计昨天的删除操作不会释放任何页面/空间。那么为什么数据库不能使用这个随时可用并分配给数据库的空间呢？
我忽略了文件自昨天以来进一步增长的可能性，因为事件发生时已经有足够的磁盘空间可用。这是一个 SQL Server 2016 SP1 Express Edition，它启用了Autogrowth设置，文件增长大小为 64 MB，最大大小设置为Unlimited。考虑：
10184 MB + 64 MB = 10248 MB > 10240 MB (= 10 GB = maximum allowed DB size in Express Edition)
很明显，该文件不能（也不能）进一步增长。
虽然数据库无法调整文件大小，但它仍然可以使用任何可用的空间。那为什么没有发生呢？
莫非，昨天删除后，有些对象被删除了？
请参阅下面的快照，其中显示了我管理下的一个 SQL Server 实例的所有数据文件以及事务日志文件的时间戳。这是一个生产实例。
今天是 2019 年 12 月 27 日。但是，如您所见，所有时间戳都显示了更早的时间。
事实是，我在几天前的 12 月 24 日拍摄了这张快照。但是，正如我今天检查的那样，情况仍然没有改变。
上面的快照取自用户数据库。我还检查了驻留在单独驱动器上的系统数据库，并拍摄了文件时间戳的快照，如下所示：
这些数据库当然不是超级活跃的。但是，我确信有交易一直在运行。此外，我查看了其中一些的“架构更改历史记录”报告，并且可以确认我们的维护工作直到昨天 12 月 26 日一直在工作和重建索引。
数据库都处于完全恢复模式（尽管这可能不相关 - 只是需要提及的事实）。操作系统是 Windows NT 6.0 (= Windows Server 2007)，SQL Server 版本是 2008 SP3。操作系统和 SQL 服务都将在明年第一季度升级。从上面的快照中也可以看出，数据文件和日志文件都驻留在同一个磁盘驱动器和文件夹中，我“继承”的这个服务器的配置肯定不是最好的。因此，希望在几个月后进行的计划升级/迁移活动期间，所有这些都将得到解决。
现在我的问题是为什么这些文件的时间戳没有得到更新，尽管数据库仍然处于活动状态？（即使手动运行 Checkpoint 也没有改变任何东西）。然后，如果事务日志文件没有得到更新，备份是否良好且可靠？它们真的包含它们应该包含的记录吗？
我们的应用程序支持人员表示，其中一个应用程序出现故障可能是由于在一天中的特定时间（特别是每晚 08:30 pm 到 09:30 pm 之间）数据库中的一些异常活动/负载。没有提供切实的证据，但是他们有兴趣查看问题时间期间数据库中发生的任何事情的统计数据/图表，看看他们是否可以从中获得任何线索。或者至少，要确保数据库方面没有问题。
之前我曾告诉他们，跟踪会话可以帮助我们了解问题期间数据库中发生的情况。（也许我不应该这么说？）现在他们缠着我向他们提供跟踪数据，但他们不知道应该跟踪哪些事件。他们给了我一个模糊的要求，“请您提供好坏时期的统计数据，以便我们进行比较？”
问题是我也注意到应该包括哪些事件。
为了帮助他们解决这个问题，我也一直在考虑使用 MDW（管理数据仓库）。目前未启用。
这里有m个问题：
这是一个SQL Server 2008 R2数据库，等待明年上半年升级。这是一个生产数据库。
SolarWinds 用于监控我们的数据库。据我了解，它已经收集了大量数据（例如用户连接、活动会话、活动事务、延迟写入/秒等）。这些数据每 5 分钟收集一次。
我们团队中有 Oracle DBA，但没有其他 SQL Server DBA。这意味着不幸的是，周围没有其他人能够帮助我。
我也是这个环境的新手，对 SQL Server 不是很精通，至少在性能调优方面是这样，因为我一生中大部分时间都在做 Oracle。
有人问我，我们的 SQL Server 实例之一是否有足够的内存。这是在具有 40 个 CPU 和 64 GB RAM 的 x64 计算机上运行的 SQL Server 2008 R2 标准版。
此实例下运行的所有数据库的总大小略大于 300 GB。
该实例已配置为最小服务器内存为 4096 MB，最大服务器内存为 24000 MB。
到目前为止，我已经设法收集了以下信息：
正在使用的物理内存：
SELECT physical_memory_in_use_kb,
process_physical_memory_low,
process_virtual_memory_low
FROM sys.dm_os_process_memory
physical_memory_in_use_kb process_physical_memory_low process_virtual_memory_low
------------------------- --------------------------- --------------------------
25657180 0 0
性能计数器：
SELECT counter_name , cntr_value
FROM sys.dm_os_performance_counters
WHERE counter_name IN ('Total Server Memory (KB)',
'Target Server Memory (KB)', 'Granted Workspace Memory (KB)',
'Maximum Workspace Memory (KB)',
'Memory Grants Outstanding', 'Memory Grants Pending')
counter_name cntr_value
----------------------------------- --------------------
Granted Workspace Memory (KB) 1024
Maximum Workspace Memory (KB) 17714520
Memory Grants Outstanding 1
Memory Grants Pending 0
Target Server Memory (KB) 24576000
Total Server Memory (KB) 24576000
缓冲池：
select count(*) AS Buffered_Page_Count
,count_big(*) * 8192 / (1024 * 1024) as Buffer_Pool_MB
from sys.dm_os_buffer_descriptors
Buffered_Page_Count Buffer_Pool_MB
------------------- --------------------
2499693 19528
缓冲池大小图：
BPHR：
请：
计划缓存大小：
每秒页面读取次数
每秒页面写入次数
总 IO 等待时间：
我的问题是：
我应该看的其他东西是什么？
如果以上就足够了，我是否必须建议添加更多内存（可能是 50 GB），因为 PLE 会随着时间的推移而下降（而总 IO 等待时间显示会增加）？
目标服务器内存等于最大内存集。如果配置了实例，这是否表明实例可以利用更多内存？
那么，我如何知道我的 SQL Server 是否需要更多内存？或者它没有
为了备份一张大表（使用SELECT .. INTO ..），我在一台有 4 个 CPU 和 16 GB RAM 的机器上花了将近 4 个小时。操作期间没有外部应用程序/进程访问该表。
表大小为 220 GB，SELECT .. INTO是一个简单的（即SELECT * INTO BACKUP_TABLE FROM ORIGINAL_TABLE）
这是一个测试环境，基于此，我需要估算生产环境中相同操作的执行时间。生产环境有 40 个 CPU 和 64 个 RAM。
CPU 相同，两个系统的 I/O 系统相同。（即磁盘类型和磁盘布局相同）。
考虑到生产服务器的处理能力提高 10 倍，估计生产的 SELECT .. INTO .. 将在不到一个小时内完成是否现实？
如果无法根据上述情况回答这个问题，我是否应该重新运行测试并收集一些指标？如果是，这些指标应该是什么？
在此先感谢您提供您对此的想法！
已从我们的 SQL Server 数据库之一收到以下错误消息：
SQL Server 检测到基于逻辑一致性的 I/O 错误：校验和不正确（预期：0x6847f47b；实际：0x15160a19）。它发生在读取文件“C:\XYZ.MDF”中偏移量 0x000001c832e000 的数据库 ID 5 中的页面 (1:934295) 期间。SQL Server 错误日志或系统事件日志中的其他消息可能会提供更多详细信息。这是威胁数据库完整性的严重错误情况，必须立即纠正。完成完整的数据库一致性检查 (DBCC CHECKDB)。这个错误可能是由许多因素引起的；有关详细信息，请参阅 SQL Server 联机丛书。
显然我必须DBCC CHECKDB在损坏的数据库上运行。在此之前，我试图找出数据库名称是什么（使用数据库 ID）以及错误与什么对象相关，使用错误消息中给出的页码。
所以我知道数据库名是distribution，表名是MSrepl_errors。
我对 SQL Server 复制功能不太熟悉，因此如果有人可以帮助我解决以下问题，我将不胜感激：
为了调查和/或可能解决问题，我必须先执行DBCC CHECKDB；但是，CHECKDB如果不先将数据库置于单用户模式，就无法运行，这是正确的吗？
distribution关于数据库不被最终用户使用的事实，我是否仍然必须将其置于单用户模式？如果是，对复制作业有什么影响？
我在数据库中看到以下数量的登录与注销与注销：
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% 是没有意义的。
任何想法为什么？
我们的一位数据库用户抱怨说，他们无法从这个特定实例中的一个数据库中进行选择，而他们在同一个实例中访问其他数据库时没有问题。他们有访问问题的那一项显示为“待机/只读”。其他只是正常的。
因此，我检查了给定主体的 Security -> Logins 并查看了主体的属性，以查看是否有任何用户映射到此登录的只读数据库。该特定数据库没有这样的映射，而其他数据库有映射并且都具有“db_datareader”角色成员资格。最初，我也想为这个数据库添加一个用户映射；但是，它失败并显示以下消息：
“更新数据库 X 失败，因为数据库是只读的”
然后，我检查了只读数据库，发现其中存在一个与出现此问题的帐户同名的用户。它还具有“db_datareader”角色成员资格。所以，我想我只需要将两者联系起来；但是，我不知道如何。请帮我！谢谢。