为什么 SQL Server 表分区停止工作？

Question

出于多种原因，但主要是数据量庞大，我们有 5 个 MS-SQL (2017) 分片服务器来分解任何单个服务器上的整体负载。其次，我们有一个按资产 ID 分区的实时表，以存储实时数据。每个资产的数据包大约每 2 秒到达一次。每个数据包可以有 300 到 12000 个数据点。

表分区和分片服务器运行良好。但是每隔一段时间，似乎其中一台服务器似乎停止使用分区，这会导致在删除旧数据和批量加载新数据时新数据到达时出现死锁和超时。

我的问题是为什么会发生这种情况，有没有办法检查何时或为什么会发生这种情况。我知道这是个问题，因为我可以将数据移动到临时表，删除原始表，使用相同的分区函数和方案重新创建原始表，最后将数据从临时表复制回新的“原始”表问题解决了。

根据要求的分区方案。资产 ID 是函数使用的内容，如上所述

CREATE PARTITION SCHEME [RMAPartitionScheme] AS PARTITION [RMAPartitionFunction] 
TO ([HULL269_484_LymanMartin], [HULL275_541_ClarenceTriche], 
    [HULL277_546_RussellAdams], [HULL278_550_CharlieComeaux], 
    [HULL281_561_CInstaller], [HULL284_587_GrandIsle], 
    [HULL290_621_ShipIsland], [HULL291_638_HornIsland], 
    [HULL296_653_StimStarIV], [HULL293_654_CatIsland], 
    [HULL292_655_SanibelIsland], [HULL297_678_DauphinIsland], 
    [HULL137_679_StimStarBrasil], [HULL809_680_Robin], 
    [HULL1304_690_FastTrack], [HULL174_691_CRuler], 
    [HULL1328_692_FastTiger], [HULL240_695_CFighter], 
    [HULL778_730_Kudu], [HULL064_738_FastCheetah], 
    [HULL063_739_FastServer], [HULLT100_746_ITS100BSM], 
    [HULLBT10_749_ITSBuckeye], [HULL315_779_Elrington], 
    [HULL302_780_MarshIsland], [HULL321_781_Courageous], 
    [HULL316_782_LaTouche], [HULL317_784_BainBridge], 
    [HULL324_787_Contender], [HULL325_788_Champion], 
    [HULL318_790_Ingot], [HULL326_792_Challenger], 
    [HULLN01_797_SeawayMoxie], [HULLAS1_799_IslandCommander], 
    [HULL301_800_DeerIsland], [HULL810_804_Lucy], 
    [DEFAULT_FILE_GROUP])

和功能

CREATE PARTITION FUNCTION [RMAPartitionFunction](int) 
AS RANGE LEFT 
FOR VALUES 
     (484, 541, 546, 550, 561, 587, 621, 638, 653, 654, 655, 678, 
      679, 680, 690, 691, 692, 695, 730, 738, 739, 746, 749, 779, 
      780, 781, 782, 784, 787, 788, 790, 792, 797, 799, 800, 804)

Answer 1

我想象缓慢（以及因此出现死锁等）以及分区“停止工作”的看法是因为您的查询突然停止进行分区消除。

您可能会错过分区消除的原因有很多：

• 数据类型不匹配和自动参数化（请参阅为什么分区消除不起作用？）
• 连接到其他表时，谓词不够具体（请参阅隐含谓词和分区消除）
• 与连接类型相关的限制（看看为什么没有分区消除）

我的问题是为什么会发生这种情况，有没有办法检查何时或为什么会发生这种情况。

您应该获得特定慢查询的实际执行计划，或者可能只是其中之一。在运行良好时获取一个，在出现问题时获取一个。您应该能够看到差异（可能是读取的分区数量不同）。随意在网站上发布有关它的问题。

也许统计数据已经过时，您会在探测端获得与分区表的散列连接。或者您突然获得较低的查询成本，并且它们正在被琐碎计划/自动参数化。

“删除并重新创建一切使其工作”的整个工作流程让我非常怀疑统计数据是否涉及问题的根本原因。

您的“为什么”问题的具体答案可能在执行计划中。在此之前，这些只是有根据的猜测，但希望它们为您指明正确的方向 =)