nateirvin's questions

我们有一个 SQL Server 2016 (v13 SP3) 企业版服务器托管在 Windows 故障转移群集/SQL 可用性组中，具有两个节点（主节点和辅助节点）。这两个节点在运行 Windows Server 2012 R2 64 位 (NT 6.3) 的 AWS EC2 实例内运行。

本周早些时候，服务器开始响应此错误：

Could not allocate space for object 'dbo.Batches'.'pk_Batches_BatchID' in database 'XXX' because the 'PRIMARY' filegroup is full. Create disk space by deleting unneeded files, dropping objects in the filegroup, adding additional files to the filegroup, or setting autogrowth on for existing files in the filegroup.

起初，这似乎非常简单：我们认为我们粗心并允许数据和/或日志文件变得太大。这些文件肯定已满，其中没有任何未分配的空间。我们认为我们只需要扩展 Windows (NTFS) 驱动器（由 AWS EBS 在后台支持）。“XXX”数据库有一个日志文件和两个数据文件 - 数据文件设置为无限增长（尽管一次只能增长 64MB），并且数据库只有默认的“PRIMARY”文件组，不涉及其他文件组。数据文件位于“D:”驱动器上。

但“D:”驱动器有超过 400 GB 的可用空间，那么为什么数据文件没有增长呢？

我们花了很多时间查看 Windows 集群和 SQL 可用性组，因为我们还看到大量有关 AG 状态进入“正在恢复”状态以及集群角色未正确应用/同步的错误。一些更改允许主节点恢复几分钟，但随后它会再次崩溃。（因此，我们检查“XXX”数据库本身的能力受到限制。）我们查看了 EBS 是否存在某种问题或中断，但没有发现任何错误。

我们意识到服务器已经过时且陈旧。我们意识到有些人会说使用/依赖自动增长是一种不好的做法。但这个问题与最佳实践无关——而是我们如何让这个当前关闭的生产服务器恢复正常运行？

我有两台服务器，SERVER-01 和 SERVER-00（不是他们的真实姓名）。SERVER-00 是 SQL Server 2005 Standard 实例，SERVER-01 是 SQL Server 2014 Standard 实例。我有这个查询，每晚在 SERVER-00 上的 SQL 代理作业中运行：

truncate table DataWarehouse.dbo.documents
set identity_insert DataWarehouse.dbo.documents ON

INSERT INTO [DataWarehouse].[dbo].[documents]
    (
     [documentID]          
    ,[poNumber]
    ,[soldTo]
    ,[shipTo]
    )
SELECT 
     [documentID]
    ,[poNumber]
    ,[soldTo]
    ,[shipTo]      
FROM [server-01].[DataWarehouse].[dbo].[documents]

set identity_insert DataWarehouse.dbo.documents OFF

（实际查询包含更多列，为了便于阅读，我对其进行了修剪。）

在 SERVER-01 上，documents是一个视图。在 SERVER-00 上，documents是一个表。在此查询[server-01]中是 SERVER-00 上的链接服务器连接（它使用系统管理员的凭据连接到 SERVER-01）。

documentsSERVER-00 上只有大约一半的行被插入。作业没有记录错误消息或警告- 它总是成功的。这到底是怎么发生的？

我正在尝试设置复制 - 这是我第一次这样做，所以我可能在这里犯了一些菜鸟错误。现在我只是在开发环境中工作。我一直在关注此 MSDN 教程中给出的示例。

我已经将实例设置为它自己的分发者，然后我去创建一个发布（其中包括除了几个表之外的所有内容，以及除了一个视图之外的所有内容）。该发布创建得很好，但之后，所有表和列都已设置为“不用于复制”！因此，当我转到快照代理程序状态时，我当然会看到错误“当 IDENTITY_INSERT 设置为 ON 或复制用户正在插入 NOT FOR REPLICATION 标识列时，必须为表中的标识列指定显式值。”

第一次发生这种情况时，我认为我做了一些愚蠢的事情，所以我通过选择“禁用发布和分发”来回滚，并进行了一些挖掘。在我开始启用和设置复制之前，所有表都是将“不用于复制”设置为“false”的列，这是我所期望的。我重新设置了发布者和分发者设置，这并没有改变表/列设置上的任何内容。但后来我创建了出版物，它们都被修改了。我再次撤消，将它们全部恢复为“用于复制”，然后生成但没有运行发布脚本（使用 SQL Server Management Studio 的 GUI），并一次执行每个命令，检查“not for”的状态沿途复制”设置。它'sp_addarticle

每篇文章都添加了选项@identityrangemanagementoption = N'manual'and @schema_option = 0x000000000803509F，它转换为选项 0x1、0x2、0x4、0x8、0x10、0x80、0x1000、0x4000、0x10000、0x20000 和 0x8000000（请参阅这篇MSDN 文章了解它们的含义）。

环境是SQL Server 2012-dev是Developer版，最终生产环境是Standard版。我正在使用此脚本检查“不用于复制”设置的状态：

SELECT 
    tables.name AS table_name,
    columns.name AS column_name,
    COLUMNPROPERTY(columns.object_id, columns.name, 'IsIdNotForRepl') AS IsIdNotForRepl
FROM sys.tables
    JOIN sys.columns
        ON tables.object_id = columns.object_id
ORDER BY 3 DESC, 1, 2

为什么创建复制发布会主动将主题对象排除在复制之外，我该如何更改此行为？

我们的数据库中有许多表，VARCHAR(MAX)其中的列 a VARCHAR(500)（或比 max 小得多的东西）就足够了。自然地，我想清理这些，并将尺寸降低到更合理的水平。我理解的“如何”做到这一点：我的问题是改变这些列会对磁盘上​​的页面和现存文件有什么影响？（有很多关于当你增加一列时会发生什么的信息，但是很难找到关于当你缩小一个列时会发生什么的信息。）

有些表的行数非常少，所以我不担心更改的成本，但有些表很大，我担心它们可能会被重组并导致大量阻塞/停机时间。实际上，我只是想要一种估计维护窗口的方法。一般来说，我想更好地了解数据库引擎在这种情况下的行为方式。

提前致谢！

编辑：

我正在查看 20 个表，但其中只有一半的行数大于 1,000。最大的有近一百万行。VARCHAR(MAX)最严重的违规者是可以缩小到水平的具有 350,000 行和 4 列的表VARCHAR(500)。

我是 DW/BI 的新手，这似乎是一个非常基本的问题，但我似乎找不到好的答案。

我有一个事实表，它有多个与之关联的日期，所以我想我会有多个日期键返回到同一个维度表，例如SubmittedDateKey, ClosedDateKey。显然 SQL Server 可以做到这一点——我对此的保留意见是，当我以这种方式设计概念验证模式时，客户端工具（即 Tableau、Excel）似乎对如何映射关系感到困惑。（我还发现 这个论坛帖子说 Oracle 的 Analytic Workspace Manager 明确禁止这样做，这当然对我的 Microsoft 世界没有任何暗示，但表明这是一个普遍的禁忌。）

DW/BI 中是否有关于此的最佳实践？SubmittedDateDimension我应该有多个相同的维度表，例如，，而不是将一个维度表连接到这些键中的每一个ClosedDateDimension吗？

谢谢！