JNK's questions

我有一个存储过程，用于查询用于在我们的系统中分配工作的繁忙队列表。有问题的表在 WorkID 上有一个主键并且没有重复项。

查询的简化版本是：

INSERT INTO #TempWorkIDs (WorkID)
SELECT
        W.WorkID

    FROM
        dbo.WorkTable W

    WHERE
        (@bool_param = 0 AND
        ((W.InProgress = 0
         AND ISNULL(W.UserID, -1) != @userid_param
         AND (@bool_filtered = 0
              OR W.TypeID IN (SELECT TypeID FROM #Types AS t)))
         OR 
         (@bool_param = 1
          AND W.InProgress = 1
          AND W.UserID != @userid_param)
        OR
        (@Auto_Param = 0
         AND W.UserID = @userid_param)))
         OR
         (@bool_param = 1 AND W.UserID = @userid_param)
    OPTION
        (RECOMPILE)

该#Types表已在该过程的前面填充。

正如我所说，WorkTable它很忙，有时在运行此查询时我怀疑其中一条记录正在从中的一组过滤器移动到另一组过滤器WHERE。具体来说，当有人开始处理某个项目，并且W.InProgress从 0 更改为 1 时，就会发生这种情况。发生这种情况时，当我尝试将主键添加到此查询插入的临时表中时，我遇到了重复键冲突。

我已经在错误发生时生成的查询计划中确认没有并行度，隔离级别为READ COMMITTED，并且源表中没有重复记录。您还可以看到这里没有JOINs 或其他方法来获取笛卡尔积。

这是匿名查询计划：

问题是，是什么导致了重复，我怎样才能让它停止？

我认为READ COMMITTED应该在这里工作，我需要锁定。我几乎可以肯定，当InProgress我查询时记录上的位发生变化时，就会发生欺骗。我知道这一点是因为该表存储了该更改的时间，并且它在我查询并收到错误的几毫秒内。

我遇到了一个反复出现的 SSRS 问题，即向客户发送“不良”报告。问题是我们有包含多个子报表的报表，一个或多个子报表将无法处理。当子报表处理失败时，报表会发送一条错误消息来代替子报表，并且没有实际数据。

我的问题是，如果子报告失败，是否有办法阻止报告发送？

理想情况下，我希望外部报告只返回一个错误。有没有办法让 SSRS 报告中的错误状态升级到外部范围？是否有我们可以强制执行的编码标准来防止此问题？

我们目前同时使用 SSRS 2008r2 和 SSRS 2016。

我有一个服务代理应用程序，目前在两台服务器上有 5 或 6 个队列。

一般的工作流程是：

服务器 A

• 用户填充一些表
• 用户触发存储过程，将消息放入标头队列中，指示有工作要做
• Broker 从这个头队列中读取数据并创建大量消息发送到服务器 B

服务器 B

• 消息全部进入 1 个队列
• 在这个队列中，消息被检查和解绑，有效负载被运行，并且从我们与之交互的另一组过程/表中收集响应
• 创建响应消息并将其发送回服务器 A

服务器 A

• 响应消息进入一个特殊队列并用于更新用户在顶部填充的表
• 结束对话消息从发起者队列中读取，并用于更新另一个跟踪标头记录进度的表（即处理的 100 条消息中的 50 条）
• 当我们检测到标头记录已被完全处理时，一条新消息被发送到另一个发送通知电子邮件的队列

我建议在服务器 A 上整合其中一些队列，但我不确定最佳实践是什么。其中两个队列将具有相对较高的消息处理量，而电子邮件队列将非常慢。

我们（我认为）在管理消息类型方面做得很好，所以理论上我们可以将它们全部放入一个队列中，并且应用程序仍然可以运行。

在这种情况下何时维护单独的队列以及何时合并是否有最佳实践？

我有一个与此类似的 XML 文档：

<Root>
  <Sub>
    <Record>
      <Guid>aslkjflaksjflkasjfkljsd</Guid>
    </Record>
    <Record>
       <Guid>opqiwuerl;kasdlfkjawop</Guid>
    </Record>
  </Sub>
</Root>

我正在<Record>根据某些标准替换整个节点。<Record>节点包含一个<Guid>我可以用来识别它们的（请假装这些是有效的 GUID！）。

知道 GUID，我将该节点的 XML 返回到一个变量中以供进一步处理。在下游，我需要能够删除该特定节点，以便我可以insert将节点的修改版本恢复到原始文档中。

有没有一种方法来确定序数，或者另一种方法来使用delete/replace方法根据元素的值删除节点？

我有一系列可更新的视图，我们向最终用户公开，作为后端流程的接口。

其中一个视图引用了两个表，并且需要INSTEAD OF触发器UPDATE和INSERTs。

表格的结构是（大大简化）：

Claim
(DataRowID bigint IDENTITY PRIMARY KEY
,<bunch of claim data>)

ClaimExtended
(ClaimDataRowID bigint FOREIGN KEY references dbo.Claim(DataRowID) NOT NULL
,<bunch of other claim data>)

我最初的计划是在触发器中这样做：

CREATE TRIGGER [dbo].[MyTrigger] ON [dbo].[MyView]
INSTEAD OF INSERT
AS

DECLARE @IDLink TABLE
    (RowID int
    ,ClaimDataRowID bigint)

DECLARE @Inserted TABLE
    (RowID int identity (1,1) NOT NULL
    ,<all the columns from the view>)

INSERT INTO
    @Inserted
    (<View columns>)
SELECT
    (<View columns>)
FROM
    Inserted

INSERT INTO
    Claim
    (<Columns>)
OUTPUT
    I.RowID
    ,inserted.ClaimDataRowID
    INTO
        @IDLink (RowID, ClaimDataRowID)
SELECT
    (<Columns>)
FROM
    @Inserted I

INSERT INTO
    ClaimExtended
    (ClaimDataRowID,
    <Columns>)
SELECT
    C.ClaimDataRowID,
    <Columns>
FROM
    @Inserted I
INNER JOIN
    @IDLink C
        ON C.RowID = I.RowID

这里的OUTPUT子句不起作用，但是（Multi-part identifier I.RowID could not be bound）我假设是因为我无法在INSERT OUTPUT子句中引用源表。

除了使视图成为表格之外，我还可以在这里使用什么其他方法？由于其他原因，这需要是 aVIEW并且基础表几乎是一成不变的。

我的公司在不久的将来会转向限制性更强的安全模型。

作为其中的一部分，我们正在将特定服务器更改为新模型并测试我们所有现有的流程。我经常使用的过程之一是利用 SMO 框架按依赖顺序编写数据库对象的脚本，因此我们可以在另一台服务器上运行这些脚本。

依赖顺序非常重要，因为我们有很多嵌套对象（想想引用其他视图的视图）。

使用新的安全模型后，此脚本停止正常工作。

我也在 SSMS 中进行了测试（针对 2008r2 实例的 SSMS 2012），并且View Dependencies在引用同一数据库中另一个视图的视图上使用不会在Objects on which [this view] depends.

更麻烦的是，如果我sp_depends在有问题的视图上运行，我确实会得到一个准确的依赖关系列表。

我做了一些研究，找不到明确的答案，所以我希望有人能帮助我：

用户需要哪些特定权限才能准确查看 SQL Server 2008r2 和/或 SQL Server 2012（我们即将升级）中的依赖项。

关于同一项目的相关问题在这里。

我正在寻找两种方法来为存储 IT 基础设施数据的数据仓库中的事实表和维度表之间的层次关系建模。

举个例子：

• FACT_Folder
  • 包含有关文件系统文件夹的事实
• Dim_Drive
  • 文件夹链接到单个 DRIVE 条目
• Dim_Array
  • 驱动器链接到单个阵列
• Dim_Server
  • 阵列链接到单个服务器
• Dim_Farm
  • 服务器链接到单个农场

出于我们的目的，我们不需要担心文件夹移动到不同的驱动器。

我们希望能够获得此层次结构所有级别的指标。

假设我最终将拥有数百万个文件夹实体（包含每日数据），以及成百上千个驱动器、阵列等；您会推荐哪种设计模式，为什么？

1. 归一化

   • AFolder链接到 a Drive，层次结构的其余部分在维度之间

2. 非规格化 I

   • AFolder链接到 a Drive，但维度包含每一行的每个条目Drive的整个层次结构Drive

3. 非规格化 II

   • AFolder直接链接到层次结构的所有级别

4. ??????

我在 DW 设计方面相当陌生，并且正在使用 DW 对某些 IT 基础架构进行建模。

此时的主要问题/问题是如何对驱动器信息建模。

我们将收集有关文件和文件夹的聚合数据，以及物理驱动器上的单独数据。驱动器信息将至少包括总空间和可用空间，并且每周更新几次。

需要回答的业务问题之一是驱动器使用的趋势如何随时间变化。驱动器信息也将用于下至文件/文件夹级别的层次结构。

我现在可以看到的选项是：

1. DRIVE作为维度 实施

   • 简化层级设计
   • 这会导致报告出现问题吗？仅报告维度上的时间限制数据对我来说似乎违反直觉
   • 有一个你知道每次刷新数据时都会改变的维度似乎也有问题

2. DRIVE作为事实表实施

   • 简化报告
   • 使层次结构复杂化（？）——我也将使用它Drive来将数据映射回特定的服务器或计算机。可以将事实表用作层次结构中的中间层吗？我不认为是。

3. DRIVE作为事实和维度实施

   • 事实将仅包含键、日期和空间上的事实
   • 维度将包括其他非附加数据，例如它所在的计算机等。
   • 似乎解决了这两个问题，但这是反模式吗？

我在任何地方都无法找到关于此的权威资源，所以希望大师可以在这里给我一个答案。

我有一个非常大的表，我们必须在其中添加一列。聚集索引非常分散，我想做一个ALTER INDEX REBUILD清理它。

当我更改列时，我通常也会这样做，ALTER TABLE REBUILD因为这会清除该操作中的任何指针或拆分。

既然我们谈论的是聚集索引，它本质上就是表，我是否需要两者都做？

我的怀疑是ALTER INDEX REBUILD集群不会更新所有的东西ALTER TABLE，但我也担心ALTER TABLE不会清理索引碎片。

因此，让我先说我无法完全控制我的数据库设计，因此当前系统的许多方面都无法针对这种情况进行更改。

关于我们应该如何重新考虑设计方面的评论可能是正确的，但没有帮助:)

我有一个非常大的表，大约 150 个字段宽和大约 600m 行，它驱动大量进程。这是在数据仓库的情况下，所以我们在计划的加载过程之外没有任何更新/插入，所以它被大量索引。

已决定尝试对该表进行分区，并且我对索引分区表有些担心。我没有任何分区经验，因此感谢任何输入或链接。我无法在 BOL 或 msdn 上找到我所追求的具体内容。

目前，我们聚集在一个我们称之为IncidentKeyavarchar(50)且不是唯一的字段上 - 我们可以有 1-100 条相同的记录IK（请不要发表评论）。我们确实经常在旧IncidentKey记录上获得新数据，因此它也不是连续的。

我知道我需要IncidentDate在我的聚集索引键中包含我的分区字段 , 才能使分区正常工作。我想它会是IncidentKey, IncidentDate。

问题是，如果“新”分区中的记录应该在聚集索引中“旧”分区中的记录之前，那么聚集索引的机制将如何在分区表中的 2 部分键上工作？

例如，我有 5 条记录：

IncidentKey    Date

ABC123        1/1/2010
ABC123        7/1/2010
ABC123        1/1/2011
XYZ999        1/1/2010
XYZ999        7/1/2010

如果我得到一条新记录，ABC123, 2/1/2011它将需要在聚集索引BEFORE XYZ999, 1/1/2010中。这是如何运作的？

我假设有碎片和指针，但我找不到任何关于具有双部分键的分区表上的非分区聚集索引的物理存储和配置的信息。

我以前没见过SLEEP_TASK等待类型，今天我似乎得到了很多。

我不是正式的 DBA，只是了解一些 DBA 知识的 SQL Server 开发人员。上周末我们将服务器升级到10.52.2500.0- 我认为是 R2SP1。

我可以在网上找到的所有信息都表明这SLEEP_TASK意味着服务器正在等待某种内部进程完成。我没有任何阻塞或任何后台进程，如检查点或幽灵清理运行，所以我有点难过。

有没有人见过这种等待类型，如果有，你能告诉我是什么原因造成的吗？

SQL Server 2012 中代号Denali为列存储索引的新功能之一。

我对常规的旧行存储索引了解很多，例如 b-tree 结构、叶级和 b-tree 页面之间的存储差异、包含字段的影响、优化使用它们、键的顺序等。

我很难获得有关列存储索引 内部的任何好的信息。

• 它的结构如何？
• 有b树吗？其他结构到位了吗？
• 数据是如何组织的？
• 什么样的特定运算符最适合使用它？
• 使用它们时要避免的任何其他反模式？

我能找到的很多关于它们的内容基本上与“正常”索引完全相反，即没有键的排序，没有包含的字段，只有非聚集的。

任何见解都值得赞赏。

我的 DBA 和我在索引结构上存在分歧。

考虑医疗索赔的数据......

我们有包含以下Header字段的表：

ClaimId (varchar(50)), PaidAmount, MemberID...

对于每个标题，我们都有一个或多个记录，Detail例如：

ClaimId (varchar(50)), LineNumber (smallint), MemberId...

结构的效率或数据的重复不在这个问题的参数范围内。

还有其他表格可以通过 联系到各个Detail行ClaimId, LineNumber，我们也经常JOIN Detail这样Header做ClaimId。

对于Detail表，聚簇索引键更可取：

ClaimId

或者

ClaimId, LineNumber

ClaimId单独不是唯一的，但组合ClaimId, LineNumber对于记录来说是唯一的Detail。

我们中的一个人认为ClaimIdalone 是一个更好的聚簇键，因为它更窄，并且查找将同样有效，因为我们需要ClaimId在查找LineNumber.

另一个认为两者的结合更好，因为它不需要额外的RowID, 并且可以用于JOINing 到需要LineNumber作为JOIN条件的支持表。

我有一个每月的 ETL 过程，这里太复杂了，无法解释，但基本上我们会获得大量客户数据，将其批量加载到各种表中，然后运行一系列构建过程。

总数据量很大，我们每月添加25-30m条记录到最大的表中，总共有大约700m条记录。每个也有 2m-300m 记录的支持表。该集合的总数据约为 3.5TB。

本月，某些流程所花的时间比平时长得多。一个例子是一个通常在 30 分钟内完成的过程在我杀死它之前花了大约 40 个小时（它仍然没有完成）。

并非所有流程都受到影响，有些流程甚至比平时运行得更快。

显然，根本原因超出了我在这里可以问的范围，但有些事情困扰着我：

我们有以数百万百分比显示的各个运营商的实际查询计划。

就像针对 的聚集索引扫描、针对791,358,704%的合并连接75,566,494%等。这发生在多个查询计划中，这些计划取自sys.dm_exec_query_plan。

这些查询计划是否指示其他一些更大的问题？

我可以肯定地知道问题不是过时的统计数据——我们对所有主要表运行了全扫描，并且我手动重建了最大的表和数据库，并预先调整大小以消除碎片。