首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >问答首页 >Server 2017;内存故障排除;资源池“内部”中的系统内存不足,无法运行此查询

Server 2017;内存故障排除;资源池“内部”中的系统内存不足,无法运行此查询
EN

Database Administration用户
提问于 2021-12-15 18:03:59
回答 2查看 5.5K关注 0票数 4

我们正在运行一个本地Server 2017以支持datawarehouse数据库。数据库通过SSIS按计划加载,主要通过使用暂存表和合并函数。最近,我们开始看到错误“资源池‘内部’没有足够的系统内存来运行这个查询。”在过去的几周里,它变得越来越猖獗。

我们已经尝试过:

  1. 关闭查询存储
  2. 通过CU27更新Server
  3. 跟踪查询(没有好的结果)
  4. 运行尽可能多的报告来找出问题所在

最近与错误时间相关的更改:

  1. 打开查询商店
  2. 添加大量索引

其他资料:

  1. 我们在服务器上有32 to内存,并将26 to分配给sql server。
  2. 合并的目标表是一个聚集的COLUMNSTORE索引
  3. 合并的源表是一个堆。
  4. 随着时间的推移/多个故障,发起更改记录的源表已增加到200,000多条记录。目标表为1,000万行。

任何帮助都将不胜感激。在过去的几天里,我一直在互联网上搜索,寻找任何的指导。到目前为止我看到的是:

  1. 更新SQL版本
  2. 修改查询
  3. 向服务器添加内存

合并语句:

代码语言:javascript
运行
复制
 DROP TABLE IF EXISTS #Changes;
DROP TABLE IF EXISTS #TransformedChanges;

CREATE TABLE #Changes
(
    [Change Type] VARCHAR(100)
);
MERGE [dbo].[FactOrderLine] AS TARGET
USING ( SELECT
[FactOrderLine].[OrderLine_Key],
[FactOrderLine].[BookedDate_Date_Key],
[FactOrderLine].[BookedDate_Time_Key],
[FactOrderLine].[Account_Key],
[FactOrderLine].[CCN_Key],
[FactOrderLine].[BillTo_SalesOffice_Key],
[FactOrderLine].[BillTo_Territory_Key],
[FactOrderLine].[ShipTo_SalesOffice_Key],
[FactOrderLine].[ShipTo_Territory_Key],
[FactOrderLine].[AssemblyLocation_Key],
[FactOrderLine].[ProductDivision_Key],
[FactOrderLine].[Product_Key],
[FactOrderLine].[Booked Date],
[FactOrderLine].[Ordered Quantity],
[FactOrderLine].[Unit Price - CCN],
[FactOrderLine].[Unit Price - Transaction],
[FactOrderLine].[Discount Factor],
[FactOrderLine].[Split Factor],
[FactOrderLine].[Is Split?],
[DW_Checksum] = CHECKSUM([FactOrderLine].[BookedDate_Date_Key],
[FactOrderLine].[BookedDate_Time_Key],
[FactOrderLine].[Account_Key],
[FactOrderLine].[CCN_Key],
[FactOrderLine].[BillTo_SalesOffice_Key],
[FactOrderLine].[BillTo_Territory_Key],
[FactOrderLine].[ShipTo_SalesOffice_Key],
[FactOrderLine].[ShipTo_Territory_Key],
[FactOrderLine].[AssemblyLocation_Key],
[FactOrderLine].[ProductDivision_Key],
[FactOrderLine].[Product_Key],
[FactOrderLine].[Booked Date],
[FactOrderLine].[Ordered Quantity],
[FactOrderLine].[Unit Price - CCN],
[FactOrderLine].[Unit Price - Transaction],
[FactOrderLine].[Discount Factor],
[FactOrderLine].[Split Factor],
[FactOrderLine].[Is Split?],
0)
FROM [changeLog].[FactOrderLine] ) AS SOURCE
ON [Source].[OrderLine_Key] = [Target].[OrderLine_Key]
WHEN MATCHED AND ISNULL([Source].[DW_Checksum], 0) <> ISNULL([Target].[DW_Checksum], 0) THEN UPDATE SET
[Target].[BookedDate_Date_Key] = [Source].[BookedDate_Date_Key],
[Target].[BookedDate_Time_Key] = [Source].[BookedDate_Time_Key],
[Target].[Account_Key] = [Source].[Account_Key],
[Target].[CCN_Key] = [Source].[CCN_Key],
[Target].[BillTo_SalesOffice_Key] = [Source].[BillTo_SalesOffice_Key],
[Target].[BillTo_Territory_Key] = [Source].[BillTo_Territory_Key],
[Target].[ShipTo_SalesOffice_Key] = [Source].[ShipTo_SalesOffice_Key],
[Target].[ShipTo_Territory_Key] = [Source].[ShipTo_Territory_Key],
[Target].[AssemblyLocation_Key] = [Source].[AssemblyLocation_Key],
[Target].[ProductDivision_Key] = [Source].[ProductDivision_Key],
[Target].[Product_Key] = [Source].[Product_Key],
[Target].[Booked Date] = [Source].[Booked Date],
[Target].[Ordered Quantity] = [Source].[Ordered Quantity],
[Target].[Unit Price - CCN] = [Source].[Unit Price - CCN],
[Target].[Unit Price - Transaction] = [Source].[Unit Price - Transaction],
[Target].[Discount Factor] = [Source].[Discount Factor],
[Target].[Split Factor] = [Source].[Split Factor],
[Target].[Is Split?] = [Source].[Is Split?],
[Target].[DW_Checksum] = [Source].[DW_Checksum],
[Target].[DW_ModifiedOn] = GETUTCDATE(),
[Target].[DW_IsDeleted?] = 0
WHEN NOT MATCHED BY TARGET THEN INSERT
(
[OrderLine_Key],
[BookedDate_Date_Key],
[BookedDate_Time_Key],
[Account_Key],
[CCN_Key],
[BillTo_SalesOffice_Key],
[BillTo_Territory_Key],
[ShipTo_SalesOffice_Key],
[ShipTo_Territory_Key],
[AssemblyLocation_Key],
[ProductDivision_Key],
[Product_Key],
[Booked Date],
[Ordered Quantity],
[Unit Price - CCN],
[Unit Price - Transaction],
[Discount Factor],
[Split Factor],
[Is Split?],
[DW_IsDeleted?], [DW_Checksum], [Source_ModifiedOn], [DW_ModifiedOn], [DW_CreatedOn] ) VALUES (
[Source].[OrderLine_Key],
[Source].[BookedDate_Date_Key],
[Source].[BookedDate_Time_Key],
[Source].[Account_Key],
[Source].[CCN_Key],
[Source].[BillTo_SalesOffice_Key],
[Source].[BillTo_Territory_Key],
[Source].[ShipTo_SalesOffice_Key],
[Source].[ShipTo_Territory_Key],
[Source].[AssemblyLocation_Key],
[Source].[ProductDivision_Key],
[Source].[Product_Key],
[Source].[Booked Date],
[Source].[Ordered Quantity],
[Source].[Unit Price - CCN],
[Source].[Unit Price - Transaction],
[Source].[Discount Factor],
[Source].[Split Factor],
[Source].[Is Split?],
0,
[Source].[DW_Checksum],NULL,GETUTCDATE(),GETUTCDATE()
)
OUTPUT $action INTO #Changes;
CREATE TABLE #TransformedChanges
    (
        [Update Record Count] INT,
        [Insert Record Count] INT
    );
INSERT INTO #TransformedChanges
SELECT *
FROM
    (
        SELECT 
            TRIM(#Changes.[Change Type])+' Record Count' AS [Change Type],
            COUNT(*) AS [Record Count]
        FROM #Changes
        GROUP BY TRIM(#Changes.[Change Type])+' Record Count'
    ) A
PIVOT
    (
        SUM([Record Count])
        FOR A.[Change Type] IN ([Update Record Count], [Insert Record Count])
    ) [B];
DECLARE @TransformationChecker INT;
SET @TransformationChecker = (SELECT COUNT(*) FROM #TransformedChanges);
IF @TransformationChecker = 0 INSERT INTO #TransformedChanges VALUES(0,0);
SELECT ISNULL([Update Record Count], 0) [Update Record Count], ISNULL([Insert Record Count], 0) [Insert Record Count] FROM #TransformedChanges;

DROP TABLE IF EXISTS #Changes;
DROP TABLE IF EXISTS #TransformedChanges;
EN

回答 2

Database Administration用户

回答已采纳

发布于 2021-12-20 15:24:36

感谢多个评论者的帮助,我发现通过删除合并语句的使用并运行独立的INSERT/UPDATE/DELETE语句来解决我的问题。这是由多个博客、与我一起工作的DBA和这里的评论者推荐的,但是由于没有可用的文档来暗示合并和内存问题可能会被链接(以及我自己的固执),我没有尝试切换它们,直到尝试多个其他路径。

我仍然很好奇,当表面上您期望相同数量的更新、插入和删除需要相同(或类似)数量的资源时,遮罩下到底发生了什么导致内存问题。显然,MERGE语句并不是这样操作的,有时您必须对解决方案很实际。

票数 6
EN

Database Administration用户

发布于 2021-12-16 12:12:30

“资源池‘内部’中的系统内存不足,无法运行此查询。”检查与错误日志中的错误消息关联的spid。因为合并的目标是聚集的列存储索引,所以我强烈怀疑错误不是与合并直接关联的,而是合并的结果。来自合并本身的消息不应该在内部资源池中。

后台元组移动程序确实在内部资源库中运行。除非使用reorg (COMPRESS_ALL_ROW_GROUPS = ON)压缩剩余的增量存储,否则元组移动程序将在某个时候关闭和压缩增量存储。它需要内存授权才能做到这一点。如果元组移动程序的内存授权超时,或者元组移动程序的最小权限不可用,则该错误就是结果。我相信元组移动程序总是使用1GB内存授权。

票数 2
EN
页面原文内容由Database Administration提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://dba.stackexchange.com/questions/304008

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档