在具有 512 GB RAM 和 64 个逻辑内核的服务器上运行 SQL 时，除了某些Windows 修补程序之外，是否有任何特殊注意事项（即“需要担心的事情”）？
当在这些阈值中的一个或两个以上运行但不正确时，我知道一些指导。
操作系统：Windows Server 2008 R2
SQL Server 2008 R2 SP3（集群）
关于 1 GB = 1000 MB 还是 1024 MB 是否有关于 1 ) 磁盘空间和/或 2) RAM 的权威文档？根据我的研究，1 GB 的“官方”细分过去是 1024，但最近（相对而言）有所更改为 1000。
在数据库管理领域更准确吗？还是仅仅取决于上下文？
SQL Server 包含用于查看/更新字符串数据为大写和小写但不是正确大小写的系统函数。有多种原因希望此操作发生在 SQL Server 中而不是在应用程序层中。就我而言，我们在整合来自多个来源的全球人力资源数据期间执行了一些数据清理。
如果您在互联网上搜索，您会发现此任务的多种解决方案，但许多似乎有限制性警告或不允许在函数中定义例外。
注意：正如下面评论中提到的，SQL Server 不是执行此转换的理想场所。还建议了其他方法 - 例如 CLR。在我看来，这篇文章已经达到了它的目的——将所有这些想法集中在一个地方真是太好了，而不是随处可见的随机花絮。谢谢你们。
新的高级 DBA 请求禁用以前的高级 DBA 的 Active Directory 帐户。但是，他忘记检查以前的 DBA 是所有者的数据库。我们现在有大约 60 个数据库，拥有一个孤立的所有者。有没有办法在不临时重新启用已禁用的 AD 帐户的情况下解决此问题？
注意：我知道关于不将所有者设置为用户的最佳实践。我以前的老板可能也是如此，但忽略了到处进行更改（千分之六的情况并没有想象中那么糟糕）。
我有这个查询来查找我想要针对整个企业的 CMS 中的注册服务器运行的备份的持续时间。
但问题是如何只找到每个数据库的备份时间MIN和MAX持续时间，而不是所有备份的运行时间。
我已经搞砸了很多，MIN但MAX还没有找到正确的组合。
我会以错误的方式解决这个问题吗？
DECLARE @dbname sysname
SET @dbname = NULL
SELECT database_name AS [Database]
, backup_start_date AS [Backup Started]
, backup_finish_date AS [Backup Finished]
, backup_size AS [Backup Size]
, compressed_backup_size AS [Compressed Backup Size]
, CAST((CAST(DATEDIFF(s, backup_start_date, backup_finish_date) AS int))/3600 AS varchar) + ' hours, '
+ CAST((CAST(DATEDIFF(s, backup_start_date, backup_finish_date) AS int))/60 AS varchar)+ ' minutes, '
+ CAST((CAST(DATEDIFF(s, backup_start_date, backup_finish_date) AS int))%60 AS varchar)+ ' seconds' AS [Total Time]
FROM msdb.dbo.backupset
WHERE [type]!='L'
AND database_name IN (SELECT name FROM master.dbo.sysdatabases)
GROUP BY database_name
,backup_start_date
,backup_finish_date
,backup_size
,compressed_backup_size;
代码来自这里。
是否可以在不严重影响合并复制的情况下更改不仅用于发布服务器而且用于 6 个订阅服务器的 SQL Server 服务帐户的密码？我想避免（或至少预先警告）任何潜在问题，因为复制不是我的强项，而且我讨厌对其进行故障排除。
我们的一个部门无缘无故地运行 SQL Server 2012 SP1 企业版（我知道，我知道......这个决定是在我之前做出的，他们拒绝改变）。由于我缺乏 Enterprise ed. 的经验，我很好奇的是，为什么在部门中没有人知道原因的情况下会创建数据库快照。我不知道，多年来他们一直在手动删除这些内容。
据我了解，数据库快照只能通过 T-SQL 创建（尽管我相信DBCC CHECKDB可能会在幕后创建它们）那么这里究竟发生了什么？有没有一种好方法可以追踪创建快照的过程？有没有我忽略的设置？
所讨论的实例是一个专用的 SharePoint 实例。
服务器本身有空间限制，这使得快照成为一个更大的问题。
我一直不清楚这一点——是否应该使用 Smart Defrag 或 Windows 的磁盘碎片整理程序等工具对运行 SQL Server 的 Windows 服务器进行碎片整理？
之前的高级 DBA 离开了公司，我意识到一台服务器存在多个问题，主要是速度缓慢（从 SSMS 需要很长时间打开，长时间运行的查询，以及失败的 SSIS 作业（数据仓库），到连接到链接服务器（其中 150 多个）的困难）。
在这个包含 5 个堆叠实例的服务器上，很可能发生了太多事情。一位新的高级 DBA 将很快加入该团队，但最好在他们加入时为他或她弄清楚这一切。
所以，本质上：
当我意识到这个问题时，我发现服务器内存的 94% 分配给了 SQL Server。我继续通过从两个过度配置的实例中释放内存，将其降低到 85%。
然后我注意到我们默认实例上的 MAXDOP 设置为 4（可能是 6，我不记得了）以及 CPU Affinity 设置。这些 CPU 被锁定，而其他 CPU 的活动很少。我继续并删除了 Affinity 设置（因为这些设置在添加额外的 CPU 之前就已存在）。我在所有 5 个实例中将 MAXDOP 设置为 20。
目前，我仍然看到 4 个 CPU 挂钩但总体平均值。使用率（跨所有 CPU）大约只有 25%。
我已经使用 SysInternal 的 ProcExp、资源监视器和 Windows Performance Toolkit 来观察这个问题，但我真的不知道如何隔离哪些进程，具体来说，是根本原因。关于如何真正隔离这里发生的事情的任何建议/指导？（即特定计数器/跟踪/其他程序。）
更新，根据请求：
系统信息：
Windows Server 2012 R2 Standard
64 GB 内存共
20 个 CPU
配置：
分配给此实例的 24 GB 内存
分配给其他实例的 26.5 GB 内存（总计 50.5 GB - 78.9%）
并行度的成本阈值 = 50（跨所有实例）
我禁用了一个未使用的 SSAS 进程。