Во внутреннем пуле ресурсов недостаточно системной памяти для выполнения этого запроса
Обновлено: 03.07.2024
Запуская Docker в Fedora 26 и пытаясь восстановить базу данных из резервной копии, я получаю сообщение об ошибке:
Ошибка SQL [701] [S00013]: недостаточно системной памяти в пуле ресурсов "по умолчанию" для выполнения этого запроса.
Дополнительная информация:
Команда, которую я использую для запуска Docker:
master.sys.configurations ГДЕ имя LIKE '%memory%'
ВОССТАНОВИТЬ ТОЛЬКО ФАЙЛИСТ
С ДИСКА = '/docker-mssql-fs/mydatabase.bak'
И команда, выдающая эту ошибку:
Как это решить?
Текст был успешно обновлен, но возникли следующие ошибки:
isapir прокомментировал 6 октября 2017 г. •
@twright-msft Добрый глаз! У меня действительно была опечатка, но после исправления я все равно получаю ту же ошибку. Я думаю, что процесс даже не доходит до того момента, когда он пытается проверить путь.
Есть идеи о том, как увеличить объем памяти и т. д. для экземпляра Docker MSSQL? Я пробовал некоторые команды DBCC, но продолжал получать ту же ошибку, что бы я ни делал.
прокомментировал rekahsoft 8 октября 2017 г.
У меня та же проблема, что и у @isapir.
isapir прокомментировал 8 октября 2017 г.
@rekahsoft Можете поделиться информацией о размере базы данных и/или настройках памяти?
прокомментировал rekahsoft 10 октября 2017 г.
Конечно, @isapir. Я восстанавливаю полную резервную копию 6 ГБ. Я использовал AWS и использовал пару разных экземпляров с 8 ГБ, 16 ГБ и 32 ГБ ОЗУ. Я обнаружил, что несмотря ни на что, mssql будет использовать только 8 ГБ и вылетит, как только достигнет порога 8 ГБ. Я использовал следующую команду для запуска образа докера mssql:
А затем восстановил резервную копию, используя:
Через некоторое время я получаю сообщение об ошибке: в пуле ресурсов "по умолчанию" недостаточно системной памяти для выполнения этого запроса. .
Однако я по-прежнему получаю ту же ошибку, и mssql не использует всю оперативную память. Насколько мне известно, экспресс-версия mssql для Windows имеет ограничение на 8 ГБ памяти. Возможно, это относится и к образу докера mssql?
Призрак прокомментировал 17 октября 2017 г.
Та же проблема возникает с изображениями :latest, :2017-latest и :GA-latest.
Мы попытались восстановить файл .bak размером 90 МБ. Хост - это Linux, поэтому контейнер mssql-server-linux имеет полный доступ к оперативной памяти хоста, которая составляет 24 ГБ.
Мы попытались запустить из контейнера, убедившись, что все файлы и пути имеют правильные уровни доступа пользователя, и с этой стороны ничего не изменилось.
Ghost прокомментировал 1 декабря 2017 г.
Та же проблема. Я хотел восстановить резервную копию размером 10 МБ и получил ту же ошибку. Недостаточно системной памяти в пуле ресурсов «по умолчанию» для выполнения этого запроса. (Microsoft SQL Server, ошибка: 701). Общий объем памяти Docker-Machine составляет 10 ГБ.
Версия: Microsoft SQL Server 2017 (RTM-CU1) (KB4038634) — 14.0.3006.16 (X64) 19 октября 2017 г. 02:42:29 Copyright (C) Microsoft Corporation Developer Edition, 2017 г. (64-разрядная версия) для Linux (Ubuntu 16.04.3 LTS)
isapir прокомментировал 1 декабря 2017 г.
Я хотел восстановить резервную копию размером 10 МБ и получил ту же ошибку. Недостаточно системной памяти
Тогда, думаю, все еще хуже, чем я думал. Я удивлен, что этой проблеме вообще не придается никакого значения.
Ghost прокомментировал 1 декабря 2017 г. •
Тогда, думаю, все еще хуже, чем я думал. Я удивлен, что этой проблеме вообще не придается никакого значения.
Да. У меня есть обходной путь для этого. Я установил виртуальную машину Windows Server 2016 с MSSQL Server 2016 и MSSQL Server Manager, после этого я подключил базу данных, восстановил ее с помощью резервной копии и создал новую резервную копию, после чего я смог использовать новую резервную копию на сервере Docker MSSQL.
isapir прокомментировал 1 декабря 2017 г.
Значит, резервная копия MSSQL Server 2016 восстанавливается в Docker MSSQL Server, а резервная копия более старого сервера — нет? Резервные копии, которые я тестировал, были созданы MSSQL 2008.
привидение прокомментировало 2 декабря 2017 г.
@isapir да, выглядит именно так.
rvdginste прокомментировал 3 декабря 2017 г.
У меня та же проблема с резервной копией из MSSQL 2008R2. Однако другая резервная копия из MSSQL 2008R2 восстанавливается нормально.
isapir прокомментировал 3 декабря 2017 г.
@rvdginste Можете ли вы назвать некоторые различия между двумя резервными копиями?
rvdginste прокомментировал 3 декабря 2017 г. •
@isapir Я пытался восстановить 8 баз данных (из MSSQL 2008R2), 5 удалось, а 3 не удалось. Единственное, что я могу сказать, это то, что самые большие (размер mdf) выходят из строя. Наименьший из этих 3 весит около 290 МБ, а самый большой из этих 5 — чуть меньше этого размера.
Редактировать: И я также могу подтвердить, что после восстановления и резервного копирования на MSSQL 2016 эти базы данных правильно восстанавливаются в образе Docker. Таким образом, обходной путь, предложенный @jerptrs, также работает для меня.
vrghost242 прокомментировал 8 марта 2018 г. •
У вас есть та же проблема, но вы еще не пробовали использовать виртуальную машину, но кажется, что ветка замолчала?
И обнаружил еще одну интересную проблему. База данных, созданная при восстановлении, существует, по крайней мере, частично. Но если я попытаюсь получить к нему доступ (используя DBVisualiser)
"База данных 'Surety' не может быть открыта из-за недоступных файлов или нехватки памяти или места на диске. Подробнее см. в журнале ошибок SQL Server."
А в логе написано:
(Есть второе сообщение об ошибке, ошибка: 928, серьезность: 20, состояние: 1. не уверен, связано ли это)
siddthota прокомментировал 28 марта 2018 г. •
У меня такая же проблема, когда я пытаюсь установить mssql-server-linux через docker-compose up.
база данных:
образ: microsoft/mssql-server-linux:2017-GA
среда:
- ACCEPT_EULA=Y
- SA_PASSWORD=AceSqlDB123
- USER =sa
порты:
- "1433:1433"
при попытке с помощью docker-compose up.
Он просто останавливается и ничего не делает. Я надеюсь получить решение. Я вижу, что эта тема не активна в течение последнего месяца. Будем признательны за любую помощь.
twright-msft прокомментировал 28 марта 2018 г.
@siddthota - похоже, ваш контейнер подошёл нормально. Это только конец первоначального вывода. Вы пробовали подключиться к нему? Я не думаю, что это та же проблема, которая изначально была поднята @isapir с восстановлением резервных копий базы данных. Или в вашей ситуации есть что-то, что вы не объяснили, что связывает ее с исходной проблемой?
SQL Server 2008 Enterprise SQL Server 2008 Developer SQL Server 2008 Standard SQL Server 2008 Workgroup SQL Server 2008 R2 Datacenter SQL Server 2008 R2 Developer SQL Server 2008 R2 Enterprise SQL Server 2008 R2 Standard SQL Server 2008 R2 Workgroup Еще. Меньше
Microsoft распространяет исправления для Microsoft SQL Server 2008 и Microsoft SQL Server 2008 R2 в виде одного загружаемого файла. Поскольку исправления являются накопительными, каждый новый выпуск содержит все исправления и все исправления безопасности, которые были включены в предыдущий выпуск исправлений SQL Server 2008 или SQL Server 2008.
Симптомы
При выполнении полнотекстового запроса с составными словами в Microsoft SQL Server 2008 или Microsoft SQL Server 2008 R2 в файле журнала ошибок появляется следующее сообщение об ошибке:
Date Time spidID Ошибка: 701, серьезность: 17, состояние: 123.
Date Time spidID Во «внутреннем» пуле ресурсов недостаточно системной памяти для выполнения этого запроса.
Кроме того, если вы успешно запустите полнотекстовый запрос после возникновения этой проблемы, вы получите такое же сообщение об ошибке.
Причина
Эта проблема возникает по всем следующим причинам:
В коде есть ошибка, которая используется для оценки того, сколько наборов строк требуется для выполнения операции сортировки. Поэтому код сильно завышает количество наборов строк. Требуемая оценка гранта в полнотекстовом режиме – 64 страницы для каждого набора строк, необходимого для сортировки.
Существует большой запрос, который не позволяет системе использовать память, зарезервированную для полнотекстового запроса.
Разрешение
Совокупная информация об обновлениях
SQL Server 2008 с пакетом обновления 1
Исправление для этой проблемы было впервые выпущено в накопительном обновлении 9 для SQL Server 2008 с пакетом обновления 1 (SP1). Чтобы получить дополнительные сведения об этом накопительном пакете обновления, щелкните следующий номер статьи базы знаний Майкрософт:
2083921 накопительное обновление 9 для SQL Server 2008 с пакетом обновления 1. Примечание. Поскольку сборки являются накопительными, каждый новый выпуск исправлений содержит все исправления и все исправления безопасности, которые были включены в предыдущий выпуск исправлений SQL Server 2008. Корпорация Майкрософт рекомендует рассмотреть возможность применения самого последнего выпуска исправления, содержащего это исправление. Для получения дополнительной информации щелкните следующий номер статьи, чтобы просмотреть статью в базе знаний Майкрософт:
970365 Сборки SQL Server 2008, выпущенные после выпуска пакета обновления 1 для SQL Server 2008 Исправления Microsoft SQL Server 2008 создаются для определенных пакетов обновления SQL Server. Необходимо применить исправление SQL Server 2008 с пакетом обновления 1 (SP1) к установке SQL Server 2008 с пакетом обновления 1 (SP1). По умолчанию любое исправление, входящее в пакет обновления SQL Server, включается в следующий пакет обновления SQL Server.
SQL Server 2008 с пакетом обновления 2
Исправление для этой проблемы было впервые выпущено в накопительном обновлении 1 для SQL Server 2008 с пакетом обновления 2 (SP2). Для получения дополнительных сведений об этом накопительном пакете обновления щелкните следующий номер статьи, чтобы просмотреть статью в базе знаний Майкрософт:
2289254 Накопительное обновление 1 для SQL Server 2008 с пакетом обновления 2. Примечание. Поскольку сборки являются накопительными, каждый новый выпуск исправлений содержит все исправления и все исправления безопасности, которые были включены в предыдущий выпуск исправлений SQL Server 2008.Мы рекомендуем рассмотреть возможность применения самого последнего выпуска исправления, содержащего это исправление. Для получения дополнительной информации щелкните следующий номер статьи, чтобы просмотреть статью в базе знаний Майкрософт:
2402659 Сборки SQL Server 2008, выпущенные после выпуска пакета обновления 2 (SP2) для SQL Server 2008
SQL Server 2008 R2
Исправление для этой проблемы было впервые выпущено в накопительном обновлении 4. Чтобы получить дополнительные сведения о том, как получить этот накопительный пакет обновления для SQL Server 2008 R2, щелкните следующий номер статьи, чтобы просмотреть статью в базе знаний Майкрософт:
2345451 Накопительный пакет обновления 4 для SQL Server 2008 R2. Примечание. Поскольку сборки являются накопительными, каждый новый выпуск исправлений содержит все исправления и все исправления безопасности, которые были включены в предыдущий выпуск исправлений SQL Server 2008 R2. Мы рекомендуем рассмотреть возможность применения самого последнего выпуска исправления, содержащего это исправление. Для получения дополнительной информации щелкните следующий номер статьи, чтобы просмотреть статью в базе знаний Майкрософт:
981356 Сборки SQL Server 2008 R2, выпущенные после выпуска SQL Server 2008 R2
Статус
Microsoft подтвердила, что это проблема продуктов Microsoft, перечисленных в разделе "Относится к".
Ссылки
Для получения дополнительных сведений о модели добавочного обслуживания для SQL Server щелкните следующий номер статьи базы знаний Майкрософт:
935897Команда SQL Server предлагает добавочную модель обслуживания для предоставления исправлений для выявленных проблем
Для получения дополнительных сведений о схеме именования обновлений SQL Server щелкните следующий номер статьи базы знаний Майкрософт:
822499Новая схема именования пакетов обновлений программного обеспечения Microsoft SQL ServerДополнительные сведения о полнотекстовом поиске см. на следующем веб-сайте Microsoft Developer Network (MSDN):
Полнотекстовый поиск (SQL Server)Для получения дополнительных сведений о терминологии обновлений программного обеспечения щелкните следующий номер статьи, чтобы просмотреть статью в базе знаний Майкрософт:
824684 Описание стандартной терминологии, используемой для описания обновлений программного обеспечения Microsoft
Недостаточно памяти во внутреннем пуле ресурсов для выполнения этого запроса. SQL 2012 SP4, сборка 11.0.7462.6
В SQL Server 2012 с пакетом обновления 4 (SP4) сборки 11.0.7462.6 возникает ошибка «Недостаточно памяти во внутреннем пуле ресурсов для выполнения этого запроса».
Это происходит всякий раз, когда мы запускаем задания приложений, которые загружают PDF-файлы и обрабатывают их. Иногда эти задания завершаются сбоем из-за указанной выше ошибки.
Максимальный объем памяти на сервере SQL был увеличен с 12 ГБ до 28 ГБ, однако мы все еще наблюдаем сбои заданий из-за вышеуказанной ошибки, связанной с памятью.
Любая информация будет очень полезна.
Пожалуйста, опубликуйте вывод select @@version и выберите * из sys.dm_os_process_memory, а также можете ли вы запустить sp_readerrorlog, скопировать вывод и поделиться им на общем диске, чтобы я мог видеть, какой клерк использует больше памяти.
Также, пожалуйста, дайте мне знать общий размер всех БД и размер самой большой БД
Microsoft SQL Server 2012 (SP4-GDR) (KB4057116) — 11.0.7462.6 (X64)
5 января 2018 г. 22:11:56
Авторское право (c) Microsoft Corporation
Enterprise Edition (64-разрядная версия) в Windows NT 6.3 (сборка 9600: ) (гипервизор)
Общий размер всех БД 6523 ГБ = 6,5 ТБ
Размер наибольшей БД 3719 ГБ = 3,7 ТБ
8 ответов
Эта ошибка обычно возникает из-за проблемы, когда SQL Server не может выделить оперативную память достаточно быстро.
Вы постоянно получаете эту ошибку, выполняя определенные действия? Вы смотрели на свою виртуальную память? У вас очень большой запрос?
Это очень часто происходит при выполнении заданий ETL. Иногда задания выполняются без проблем.
Также кажется, что эти запросы используют множество операторов UNION ALL. Мы увеличили объем памяти системы до 32 ГБ (память Windows server vm)
Какое значение имеет "Максимальный объем памяти сервера" в свойстве SQL Server? Если у вас есть фиксированный номер (НЕ 2147483647), вы должны изменить его после увеличения объема памяти.
максимальный объем памяти сервера, выделенный для SQL, составляет 28 ГБ
Общая системная память 32 ГБ
Что вы подразумеваете под "мы запускаем задания приложений, которые загружают PDF-файлы и обрабатывают их". это исполняемый файл, который обрабатывает pdf, а затем отправляет данные в SQL? если да, то почему он не запускается на другом компьютере, а затем отправляется на SQL Server?
Я серьезно надеюсь, что вы не используете CLR для обработки PDF-файлов. CLR вообще могут быть очень опасны
Я предлагаю выполнить этот запрос
SELECT b.virtual_address_space_reserved_kb vas_res, b.virtual_address_space_committed_kb vas_com
, b.physical_memory_in_use_kb phy_mem
FROM sys.dm_os_process_memory b
Результаты запроса
vas_res vas_com phy_mem
51527964 57949236 28891456
57 ГБ выделенной VAS, но только 28 ГБ оперативной памяти. Таким образом, память процесса SQL Server значительно выгружается. Плохо.
Управлять базой данных с объемом ОЗУ в 200 раз сложнее.
Если вы не можете добавить память, по крайней мере, уменьшите размер файла подкачки до 8 ГБ или разрешите блокировку страниц SQL Server в памяти. Либо блокирует использование SQL Server большего объема памяти (выделенные VAS), чем имеется у сервера.
Если вы не можете добавить память, по крайней мере, уменьшите размер файла подкачки до 8 ГБ или предоставьте SQL Server Lock Pages In Memory. Любой из них заблокирует использование SQL Server гораздо большего объема памяти (выделенные VAS), чем имеется у сервера.
Глупый вопрос: не значит ли это, что Равинда еще быстрее столкнется с этой ошибкой?
Опять же, это может быть лучше, чем много переполнения на диск, и все становится очень медленным.
В вашей системе что-то пошло не так.
Предположим, вы просто используете основные функции SQL Server, под которыми я подразумеваю все, что выделяет ресурсы только из общего пула буферов. В этом случае зарезервированная, выделенная и физическая память должны быть примерно одинаковыми, при условии наличия прогретого буферного кеша.
теперь предположим, что вы используете функции, требующие прямого выделения виртуального адресного пространства ОС в обход буферного кеша SQL. В идеальном случае вы объявляете объект, например: вызов xp, чтобы открыть XML-документ (старый API, а не новый API), сделать что-то, затем закрыть и освободить документ. Со временем резерв VAS будет увеличиваться, но выделенный VAS будет примерно по сравнению с используемой физической памятью.
однако, если выделенный VAS значительно превысит физическую память, это означает, что ОС должна выгружать страницы в файл подкачки, который действительно плохая вещь в современных системах.
На самом деле ситуация, когда требуется гораздо больше выделенных VAS, возникает не потому, что вам нужно так много в выделенных VAS, а потому, что кто-то забыл закрыть и освободить то, с чем он был сделан.< /p>
Здесь две проблемы
У вас мало физической памяти. У вас ТБ базы данных, а для SQL Server выделено только 28 ГБ
Вы выделили только 4 ГБ для ОС, что опять-таки может вызвать проблему, поскольку вы используете какое-то приложение для работы с файлами PDF, которому потребуется память вне буферного пула.
Но так как вы не вставили никакой конкретной информации. Трудно сказать.
Операционная система не имеет других приложений, она предназначена для SQL-сервера. Приложение PDF находится на другом сервере. Вакансии загружают только PDF-файлы и отправляют их в базу данных.
В журнале ошибок мы видим недостаточно системной памяти во внутреннем пуле ресурсов для выполнения запроса.
После этого мы получаем ошибки входа в журнал ошибок.
И пока я не увижу этот журнал ошибок, будет сложно сказать, в чем проблема.
дайте мне знать, как поделиться им. Могу я получить ваш адрес электронной почты, пожалуйста.
хорошо, а каковы последовательности кода SQL в задании для pdf, есть ли расширенные хранимые процедуры, определяет ли сетевое подключение размер пакета больше 8060 байт?
У меня нет этих подробностей, но я знаю, что эти задания выполняются без проблем в течение последних 2 лет. За последние несколько недель мы стали свидетелями сбоев в работе.
Просматривали ли вы ERRORLOG? Перезагрузил сервер? Что показывает dbcc memorystatus? В частности, объясняет ли это активное использование VAS? В противном случае может иметь место утечка памяти в неуправляемом компоненте, таком как сторонний поставщик связанных серверов.
Результаты запроса
vas_res vas_com phy_mem
51527964 57949236 28891456
да, это показывает более высокий уровень обязательного использования VAS.
в «нормальных» обстоятельствах с использованием только основных функций SQL Server, которые выделяются из пула буферов, и без прямого выделения ОС, выделенная память должна быть примерно равна физической памяти процесса.
В старых версиях SQL Server установка максимальной памяти сервера ограничивала только буферный пул, а не прямое выделение ОС.
В более поздних версиях целевая память теперь является комбинированным буфером + прямая?
Следовательно, если что-то делает прямое выделение ОС и не освобождает его после завершения, SQL Server начнет освобождать выделение буферного пула, чтобы принести общий объем памяти находится в пределах предела, установленного для цели.
Если сделано слишком много прямых выделений, то для буферного пула осталось слишком мало
Казалось бы, все, что делает прямое выделение ОС, не ограничено, поэтому зафиксированное значение увеличивается, чем целевое, и остается больше.
Однако что-то, что работает в пуле буферов, теперь сталкивается с ситуацией, когда оно генерирует сообщение об ошибке, потому что из пула буферов можно сделать очень небольшое выделение.
Возможно, необходимая функция для SQL Server, теперь, когда максимальная память сервера объединена пулом буферов + прямая, тогда также должна быть настройка для минимального пула буферов (не мин. памяти сервера), так что прямое выделение может вытолкнуть буферный пул только до установленного предела
Мы по-прежнему сталкиваемся с проблемой.Сборка SQL Server — 11.0.7462.6.
Если я обновлюсь до последней сборки, решит ли это проблему?
Последняя сборка чего? Есть более поздняя сборка SQL 2012, у меня 11.0.7493.4. Но поскольку SQL 2012 больше не поддерживается, я бы не ожидал, что в этой сборке будет решение вашей проблемы. И я действительно не думаю, что это проблема с самим SQL Server, поэтому я не уверен, что обновление до SQL 2019 поможет как таковое.
Как отмечалось ранее, мы мало что смогли понять о вашей среде, потому что вы плохо поделились информацией. Но интуиция подсказывает мне, что нужно добавить в машину гораздо больше памяти.
Мы используем локальный SQL Server 2017 для поддержки базы данных хранилища данных. База данных загружается по расписанию через SSIS, в основном за счет использования промежуточных таблиц и функции MERGE. Недавно мы начали видеть ошибку «В пуле ресурсов «внутренний» недостаточно системной памяти для выполнения этого запроса». За последние пару недель он становится все более и более безудержным.
- Отключение хранилища запросов
- Обновление SQL Server до CU27
- Отслеживание запроса (нет хороших результатов)
- Запускаем как можно больше отчетов, чтобы выявить проблему.
Последние изменения, связанные со временем возникновения ошибки:
- Включение хранилища запросов
- Добавление большого количества индексов
- У нас есть 32 ГБ памяти на сервере и выделено 26 ГБ для сервера sql
- Таблица TARGET в MERGE представляет собой CLUSTERED COLUMNSTORE INDEX
- Таблица SOURCE в MERGE представляет собой HEAP
- Со временем/множеством сбоев таблица SOURCE, в которой размещены измененные записи, разрослась до более чем 200 000 записей. В таблице TARGET примерно 10 миллионов строк.
Любая помощь будет оценена по достоинству. Я рыскал по Интернету последние пару дней в поисках каких-либо указаний. Все, что я видел до сих пор, это:
- Обновить версию SQL
- Измените свой запрос
- Добавить память на сервер
Это (вероятно) не решает проблему, но я рекомендую прочитать Итак, вы хотите использовать MERGE, а?: TL;DR: "Пожалуйста, не делайте этого, но если вы настаиваете: пожалуйста, ВСЕГДА используйте HOLDLOCK на цели."
Ничего не оптимизировано для памяти, ни регулятора ресурсов, ни SQLCLR. Я посмотрю в "Блокировать страницы в памяти" прямо в системе для сервисного аккаунта. @Чарлифейс
2 ответа 2
Благодаря помощи нескольких комментаторов я обнаружил, что моя проблема была решена путем отказа от использования операторов MERGE и вместо этого запуска независимых операторов INSERT/UPDATE/DELETE. Это было рекомендовано несколькими блогами, администратором базы данных, с которым я работаю, и комментаторами здесь, но из-за отсутствия доступной документации, которая предполагала бы, что проблемы с MERGE и памятью могут быть связаны (и мое собственное упрямство), я не пытался переключать их, пока не попробовал несколько других маршруты.
Мне все еще любопытно, что именно происходит под капотом, что вызывает проблемы с памятью, когда на поверхности вы ожидаете, что такое же количество обновлений, вставок и удалений потребует такого же (или аналогичного) количества ресурсов. Очевидно, что оператор MERGE не работает таким образом, и иногда вам нужно быть практичным с решениями.
"В пуле внутренних ресурсов недостаточно системной памяти для выполнения этого запроса." Проверьте spid, связанный с сообщением об ошибке, в журнале ошибок. Поскольку целью слияния является кластеризованный индекс columnstore, я сильно подозреваю, что ошибка не связана напрямую с MERGE, а является следствием MERGE. Сообщение от самого MERGE не должно находиться во внутреннем пуле ресурсов.
Фоновое средство перемещения кортежей работает во внутреннем пуле ресурсов. Если какие-либо оставшиеся дельта-хранилища не будут сжаты с помощью реорганизации с (COMPRESS_ALL_ROW_GROUPS = ON), в какой-то момент средство перемещения кортежей закроется и сожмет дельта-хранилища. Для этого требуется предоставление памяти. Если время ожидания средства перемещения кортежа истекло для выделения памяти или минимальное выделение для средства перемещения кортежа недоступно, результатом будет эта ошибка. Я считаю, что средство перемещения кортежей всегда использует выделение памяти объемом 1 ГБ.
Спасибо за ответ. Я просмотрел журнал ошибок и нашел соответствующий SPID. Я не знаю, что с ним делать теперь, когда он у меня есть, я все еще многому учусь. Я читал о перемещении кортежей. Я был бы удивлен, если бы механизм перемещения кортежей, который использует 1 ГБ всякий раз, когда дельта-хранилища достигают определенного порога размера, был бы виновником здесь, если только несколько дельта-хранилищ не достигли порога одновременно, а для перемещения кортежей требовалось новое выделение памяти для каждого? Но я так понимаю, что грант на 1 ГБ потребуется только один раз. Я не знаю, что делать дальше, исходя из вашего ответа.
Есть ли в конце идентификатора "s" (например, 42) или меньше 50? если да, то это системный поток. Вы правы насчет гранта в 1 ГБ, что кажется маловероятным.Даже если несколько разностных хранилищ соответствуют требованиям для перемещения кортежей одновременно, только 1 системный поток за раз будет запускать средство перемещения кортежей.
Поэтому, помимо средства перемещения кортежей, еще одним хорошим кандидатом может быть сеанс диспетчера задач SQL Server, выполняющий асинхронное автоматическое обновление статистики, если в базе данных включены как автоматическое обновление статистики, так и асинхронное автоматическое обновление статистики.
Спасибо, что уделили этому время. Комментарий к исходному вопросу решил проблему для меня. К сожалению, я до сих пор не знаю, в чем была основная причина, но при переключении с MERGE на отдельные операторы INSERT/UPDATE/DELETE проблема с памятью исчезла. Я ценю, что вы пытаетесь определить основную причину, поскольку это может быть более полезно, если кто-то столкнется с этой проблемой в будущем. SPID был 61, без s и более 50.
Рад, что вы смогли решить эту проблему!! я никогда не спрашивал - были ли ошибки возвращены клиенту, запросившему запрос, или были обнаружены в журнале ошибок, но не были возвращены клиенту?
У нас есть сервер Sql STD 2012 SP2, и за последние 3 дня мы получаем ошибку при выполнении проверки целостности DBCC как для пользовательских, так и для системных баз данных, мы используем сценарий решения Ola Maintenance.
У нас есть общая физическая память 8 ГБ, общая виртуальная память 9,25 ГБ (отображается в информации о системе Доступная физическая память 925 МБ и доступная виртуальная память 2,25 ГБ).
МАКСИМАЛЬНАЯ память настроена как 4096 МБ и МИН. память 1024 КБ)
Мы видим следующее ошибка в журнале ошибок сервера sql:
отступ предварительно отформатированного текста на 4 пробела
Уровень 17, состояние 123, строка сервера 1 Недостаточно системной памяти во «внутреннем» пуле ресурсов для выполнения этого запроса.
Сообщение 8921, уровень 16, состояние 1, сервер, строка 1. Проверка завершена. При сборе фактов обнаружен сбой.
Возможно, в базе данных tempdb недостаточно места или системная таблица несовместима. Проверьте предыдущие ошибки.
Результат: Ошибка Продолжительность: 02:55:03 DateTime: 2020-04-24 07:39:12
DateTime: 2020-04-24 07:39:12. Код завершения процесса 1. Не удалось выполнить шаг.
Когда я проверил журнал событий, я увидел следующую ошибку:
Недостаточно системной памяти во «внутреннем» пуле ресурсов для выполнения этого запроса.
У нас есть база данных TEMP, настроенная как:
Размер" 2046 МБ и доступное пространство: 1360 МБ
Временные файлы: TempDB, TempDev2 и TempLog
У нас только одна настоящая БД на 6 Гб.
Популярные темы в Microsoft SQL Server
11 ответов
Ларри Шанахан
SQL Server сообщает вам, в чем проблема — вам не хватает памяти. Реальное решение - получить больше памяти. Как минимум, я бы сказал, удвоить объем оперативной памяти (примечание: виртуальная оперативная память — это, по сути, жесткий диск, что означает более низкую производительность) и соответственно увеличить максимальный объем памяти. Независимо от того, сколько у вас оперативной памяти, SQL Server будет использовать только около 90 % максимального объема памяти.
Что касается базы данных tempdb, перезапустите экземпляр SQL Server. Это удалит весь хлам.
- отметить 36 лучших ответов
- thumb_up – 103 благодарных голоса
8 ГБ могут быть очень ограниченными. Попробуйте установить для параметра SQL Max Memory значение 1 ГБ, чтобы было больше свободной физической памяти для ОС и других приложений. Если это сработает, то вам должно быть легче увеличить общую физическую память, потому что она необходима для других ваших приложений. Установлены ли какие-либо другие приложения (например, IIS)?
На самом деле я увеличил MAX Memory, так как он был установлен, до 50% от общего объема памяти, и увеличение до 80% выглядит как работающее, так как прошлой ночью оно не дало сбоев.
Спасибо, Фессор.
На самом деле я увеличил MAX Memory, так как он был установлен, до 50% от общего объема памяти, и увеличение до 80% выглядит как работающее, поскольку прошлой ночью оно не дало сбоев.
Нет никаких других приложений, кроме нашего программного обеспечения для резервного копирования, и когда я вижу диспетчер задач, сервер sql использует более 85%, а ЦП не так уж высок.
Ларри Шанахан
Рад, что вы решили свою насущную проблему, но имейте в виду, что 8 ГБ — это не так много для работы с SQL Server, как указал Фессор. Убедитесь, что у вас осталось достаточно, чтобы ОС могла делать то, что ей нужно. В долгосрочной перспективе вам действительно следует инвестировать в больше оперативной памяти для этого сервера. Единственная универсальная константа для баз данных — они растут. По мере того, как они растут, им нужно больше ресурсов, и вы должны воспринимать этот инцидент как указание на то, что вы приближаетесь к пределу своих ресурсов. В целом оперативную память — это самый простой ресурс для добавления, поэтому посмотрите, сможете ли вы добавить ее, чтобы дать себе передышку.
Еще раз спасибо, Ларри, за хорошие предложения.
Как лучше определить, достаточно ли текущей памяти или нет?
Ларри Шанахан
Простой ответ: достаточно, чтобы производительность не ухудшилась неприемлемо, но и не настолько, чтобы вы тратили деньги впустую.
По-настоящему однозначного ответа нет, так как он зависит от вашей рабочей нагрузки (включая общий размер базы данных, количество одновременных пользователей и типы запросов, которые они или используемые ими приложения генерируют). Вам также следует учитывать будущие потребности.
Вообще говоря, вам нужно иметь 10 % или 4 ГБ ОЗУ (в зависимости от того, что больше) для ОС. Это означает, что возьмите установленную оперативную память, вычтите 4 ГБ/10% и установите это число в качестве максимального объема памяти SQL Server. Что касается того, сколько установленной оперативной памяти вам нужно, если SQL Server использует 70-75% выделенной ему памяти, у вас достаточно, чтобы вы использовали ее эффективно с бампером для учета внезапных всплесков. Этот процент может быть выше, если ваши рабочие нагрузки не так высоки и у вас нет больших всплесков использования памяти, но в целом не превышает 80%.
Теперь это очень общие цифры, предполагающие отсутствие будущих потребностей, таких как дополнительные базы данных и тому подобное. Что вам нужно сделать, так это настроить все, контролировать и вносить коррективы по мере необходимости. Если вы используете виртуальную машину, вы можете для начала добавить меньше памяти и увеличить ее по мере необходимости. Очевидно, что с физической коробкой добавить памяти сложнее, поэтому я предпочитаю добавлять больше памяти, чем меньше.
Поскольку вы сталкиваетесь с проблемами памяти, я бы посоветовал установить 12 ГБ или даже 16 ГБ установленной оперативной памяти, установив максимальный объем памяти SQL Server на 4 ГБ меньше, чтобы позволить операционной системе работать и дать вашему SQL Server достаточно оперативной памяти для игр. с участием. Учитывая то, что вы нам рассказали, не похоже, чтобы вам нужно было подниматься выше.
Это ОЧЕНЬ общая рекомендация, а не жесткие правила быстрого доступа. Как и в большинстве вещей SQL Server, он устанавливается, контролируется и корректируется. Пена. Смывать. Повторить.
Спасибо Ларри за подробную информацию.
У нас есть две БД, размер основной БД составляет всего 6 ГБ, и на этом сервере также запущено приложение.
В настоящее время общая память составляет 8 ГБ, и я установил около 6 ГБ (80 %) в качестве стандарта.
Теперь максимальный объем памяти, увеличенный с 4 ГБ до 6 ГБ, позаботился о проблеме DBCC, из-за которой задание вызывало ошибку «В пуле ресурсов «внутренний» недостаточно системной памяти для выполнения этого запроса». Итак, что вы думаете о долгосрочном решении? < /p>
Ларри Шанахан
Как в предыдущем посте. Увеличьте установленную оперативную память до 12 или 16 ГБ, установите максимальную память на 4 ГБ ниже этого значения, и некоторое время вам должно быть хорошо. Как бы то ни было, вы не оставляете ОС много работы (хотя 2 ГБ лучше, чем ничего), поэтому есть вероятность, что нехватка памяти может запустить подкачку ОС на диск, что замедлит все.. р>
Читайте также: