Ошибка SQL Ошибка выделения памяти
Обновлено: 04.07.2024
Одним из приложений, использующих сервер SQL, является MS Dynamics AX4SP1.
Axapta настроена в трехуровневом режиме:
Сервер объектов приложений (AOS)
Файловый сервер приложений
База данных MS SQL Server
Я получаю следующую ошибку на сервере AOS и не знаком с SQL.
Источник события: Dynamics Server 02
Object Server 02: база данных сообщила (сеанс 29 (paule)): [Microsoft] [Драйвер ODBC SQL Server] Ошибка выделения памяти. Оператор SQL был следующим: «ВЫБЕРИТЕ НАЧАЛО 1 A.NUMBERSEQUENCE, A.TXT, A.LOWEST, A.HIGHEST, A.NEXTREC, A.BLOCKED, A.FORMAT, A.CONTINUOUS, A.CYCLIC, A.CLEANATACCESS, A. .INUSE,A.NOINCREMENT,A.CLEANINTERVAL,A.LATESTCLEANDATE,A.LATESTCLEANTIME,A.ALLOWCHANGEUP,A.ALLOWCHANGEDOWN,A.MANUAL,A.FETCHHAHEADQTY,A.FETCHAHEAD,A.MODIFIEDTRANSACTIONID,A.RECVERSION,A.RECID ИЗ ТАБЛИЦЫ НОМЕРОВ A WITH(UPDLOCK) WHERE ((DATAAREAID=?) AND (NUMBERSEQUENCE=?))"
Эта ошибка говорит о том, что самому SQL-серверу не хватило памяти? или это ошибка для драйвера ODBC на сервере AOS? или что-то совсем другое?
Как мне устранить источник этой проблемы? это вызывает сбой приложения, и пользователи не могут получить доступ к системе.
Я наблюдал за сервером SQL, и он использовал только 1,8 ГБ ОЗУ из 4 ГБ физической памяти (3 ГБ, выделенных для SQL) на сервере, когда возникла эта ошибка, поэтому мне трудно поверить, что сервер SQL работал не хватает памяти..
Я не вижу ошибок на сервере SQL в журналах событий или в журнале SQL Server, соответствующих этим проблемам.
После последних перезапусков служб SQL и AOS на данный момент все стабильно, но мне бы очень хотелось узнать источник этих ошибок, чтобы его можно было устранить.
Спасибо за любые предложения/рекомендации
10 декабря 2007 г., 13:26
Появляется ли аналогичная ошибка в журнале ошибок SQL Server?
Это может произойти, когда сервер перегружен. Это стандартная версия SQL Server? Причина, по которой я спрашиваю, заключается в том, что типичная установка SQL Server использует 1,8 ГБ независимо от нагрузки. Там она стабилизируется. Если у вас есть версия Enterprise, вы можете изменить объем памяти, добавить переключатель /3GB и немного увеличить использование памяти. Однако ошибки выделения памяти обычно означают, что вам нужно больше ресурсов (память, более быстрый диск и т. д.)
Это может быть на уровне ODBC/OLEDB вашего сервера приложений, поэтому я бы проверил, есть ли у вас соответствующие ошибки на SQL Server. Если да, то посмотри там. Если нет, я бы проверил сервер приложений и, возможно, получил помощь по отладке от поставщика.
10 декабря 2007 г., 13:54
Стив Джонс, редактор (10.12.2007)
Появляется ли похожая ошибка в журнале ошибок SQL Server?Это может происходить в моменты, когда сервер становится перегружен. Это стандартная версия SQL Server? Причина, по которой я спрашиваю, заключается в том, что типичная установка SQL Server использует 1,8 ГБ независимо от нагрузки. Там она стабилизируется. Если у вас есть версия Enterprise, вы можете изменить объем памяти, добавить переключатель /3GB и немного увеличить использование памяти. Однако ошибки выделения памяти обычно означают, что вам нужно больше ресурсов (память, более быстрый диск и т. д.)
Это может быть на уровне ODBC/OLEDB вашего сервера приложений, поэтому я у вас есть соответствующие ошибки на сервере SQL. Если да, то посмотри там. Если нет, я бы проверил сервер приложений и, возможно, получил помощь по отладке от поставщика.
Нет, похожих или совпадающих ошибок на сервере SQL в средстве просмотра событий или в журналах SQL нет.
Это корпоративная версия SQL Server 2000, а не стандартная версия.
Куда пойдет запись /3GB? в параметрах запуска?
Массив хранения представляет собой Dell MD1000, состоящий из дисков Seagate SAS со скоростью вращения 15 000 об/мин, и имеет 450 ГБ свободного места из 900 ГБ, поэтому я думаю, что массив хранения должен быть достаточно быстрым.
Я тоже думал, что это проблема с приложением, но, конечно же, разработчик приложения говорит, что это проблема с SQL, и я должен удалить SQL и установить его заново, что мне кажется неправильным... думаю, он не думает заботиться обо всем остальном, что у меня работает на этом сервере в действии.
SQL Server In-Memory OLTP использует больше памяти и по-другому, чем SQL Server. Возможно, объем памяти, установленный и выделенный для In-Memory OLTP, станет недостаточным для ваших растущих потребностей. Если это так, у вас может не хватить памяти. В этом разделе рассказывается, как восстановиться после ситуации OOM. См. раздел Мониторинг и устранение неполадок с использованием памяти, чтобы узнать, как избежать многих ситуаций с нехваткой памяти.
Рассматривается в этой теме
| Тема | Обзор |
|---|---|
| Устранение сбоев восстановления базы данных из-за OOM | Что делать, если вы получили сообщение об ошибке «Операция восстановления базы данных не удалась из-за нехватки памяти в пуле ресурсов»." |
| Устранение влияния условий нехватки памяти или OOM на рабочую нагрузку | Что делать, если вы обнаружите, что проблемы с нехваткой памяти негативно влияют на производительность. |
| Устранить сбои выделения страниц из-за нехватки памяти, когда доступно достаточно памяти | Что делать, если вы получаете сообщение об ошибке «Запрещение выделения страниц для базы данных ' ' из-за недостаточно памяти в пуле ресурсов ' '. . ", когда доступной памяти достаточно для операции. |
| Рекомендации по использованию In-Memory OLTP в среде VM | О чем следует помнить при использовании In -Memory OLTP в виртуализированной среде. |
Устранение сбоев восстановления базы данных из-за OOM
При попытке восстановить базу данных может появиться сообщение об ошибке: "Операция восстановления базы данных ' ' не удалась из-за нехватки памяти в пуле ресурсов ' '". Это указывает на то, что на сервере недостаточно доступной памяти для восстановления базы данных.
На сервере, на который восстанавливается база данных, должно быть достаточно доступной памяти для оптимизированных для памяти таблиц в резервной копии базы данных, иначе база данных не перейдет в оперативный режим и будет помечена как подозрительная.
Если на сервере достаточно физической памяти, но вы по-прежнему видите эту ошибку, это может быть связано с тем, что другие процессы используют слишком много памяти, или из-за проблемы с конфигурацией недостаточно памяти для восстановления. Для этого класса проблем используйте следующие меры, чтобы сделать больше памяти доступной для операции восстановления:
Временно закройте запущенные приложения.
Закрывая одно или несколько запущенных приложений или останавливая службы, которые в данный момент не нужны, вы освобождаете память, которую они использовали, для операции восстановления. Вы можете перезапустить их после успешного восстановления.
Увеличьте значение MAX_MEMORY_PERCENT.
Если база данных привязана к пулу ресурсов, что рекомендуется, доступная для восстановления память определяется MAX_MEMORY_PERCENT. Если значение слишком низкое, восстановление завершится ошибкой. Этот фрагмент кода изменяет MAX_MEMORY_PERCENT для пула ресурсов PoolHk на 70 % установленной памяти.
Если сервер работает на виртуальной машине и не является выделенным, установите для параметра MIN_MEMORY_PERCENT то же значение, что и для MAX_MEMORY_PERCENT.
Дополнительную информацию см. в разделе Передовой опыт использования выполняющейся в памяти OLTP в среде виртуальных машин.
Информацию о максимальных значениях MAX_MEMORY_PERCENT см. в тематическом разделе Процент памяти, доступной для таблиц и индексов, оптимизированных для памяти.
Увеличить максимальный объем памяти сервера.
Информацию о настройке максимальной памяти сервера см. в разделе Параметры конфигурации сервера Память сервера.
Устранение влияния нехватки памяти или условий OOM на рабочую нагрузку
Очевидно, что лучше не допускать ситуации нехватки памяти или OOM (недостаточно памяти). Хорошее планирование и мониторинг могут помочь избежать ситуаций нехватки ресурсов. Тем не менее, лучшее планирование не всегда предвидит то, что происходит на самом деле, и вы можете столкнуться с нехваткой памяти или OOM. Восстановление после OOM состоит из двух шагов:
Откройте DAC (выделенное подключение администратора)
SQL Server предоставляет выделенное подключение администратора (DAC). DAC позволяет администратору получить доступ к работающему экземпляру SQL Server Database Engine для устранения неполадок на сервере, даже если сервер не отвечает на другие клиентские подключения. DAC доступен через утилиту sqlcmd и SQL Server Management Studio.
Инструкции по использованию DAC через SSMS или sqlcmd см. в разделе Диагностическое подключение для администраторов баз данных.
Примите меры
Чтобы решить проблему с OOM, вам нужно либо освободить существующую память, сократив ее использование, либо выделить больше памяти для ваших таблиц в памяти.
Освободить существующую память
Удалите ненужные строки таблицы, оптимизированные для памяти, и дождитесь сборки мусора
Вы можете удалить ненужные строки из таблицы, оптимизированной для памяти. Сборщик мусора возвращает память, используемую этими строками, в доступную память. Подсистема OLTP в памяти агрессивно собирает строки мусора. Однако длительная транзакция может помешать сборке мусора. Например, если у вас есть транзакция, которая выполняется в течение 5 минут, любые версии строк, созданные в результате операций обновления/удаления, когда транзакция была активной, не могут быть удалены сборщиком мусора.
Переместить одну или несколько строк в таблицу на диске
В следующих статьях TechNet приведены рекомендации по перемещению строк из таблицы, оптимизированной для памяти, в таблицу на диске.
Увеличить доступную память
Увеличить значение MAX_MEMORY_PERCENT в пуле ресурсов
Если вы не создали именованный пул ресурсов для своих таблиц в памяти, вам следует сделать это и привязать к нему свои базы данных OLTP в памяти. Инструкции по созданию и привязке баз данных In-Memory OLTP к пулу ресурсов см. в разделе Привязка базы данных с таблицами, оптимизированными для памяти, к пулу ресурсов.
Если ваша база данных In-Memory OLTP привязана к пулу ресурсов, вы можете увеличить процент памяти, доступной для пула. Инструкции по изменению значений MIN_MEMORY_PERCENT и MAX_MEMORY_PERCENT для пула ресурсов см. в подразделе Изменение MIN_MEMORY_PERCENT и MAX_MEMORY_PERCENT в существующем пуле.
Увеличьте значение MAX_MEMORY_PERCENT.
Этот фрагмент кода изменяет MAX_MEMORY_PERCENT для пула ресурсов PoolHk на 70 % установленной памяти.
Если сервер работает на виртуальной машине и не является выделенным, установите для MIN_MEMORY_PERCENT и MAX_MEMORY_PERCENT одно и то же значение.
Дополнительную информацию см. в разделе Передовой опыт использования выполняющейся в памяти OLTP в среде виртуальных машин.
Информацию о максимальных значениях MAX_MEMORY_PERCENT см. в тематическом разделе Процент памяти, доступной для таблиц и индексов, оптимизированных для памяти.
Установите дополнительную память
В конечном итоге лучшим решением, если это возможно, является установка дополнительной физической памяти. Если вы это сделаете, помните, что вы, вероятно, сможете также увеличить значение MAX_MEMORY_PERCENT (см. подраздел Изменение MIN_MEMORY_PERCENT и MAX_MEMORY_PERCENT в существующем пуле), поскольку SQL Server вряд ли потребуется больше памяти, что позволит вам если не вся вновь установленная память доступна для пула ресурсов.
Если сервер работает на виртуальной машине и не является выделенным, установите для MIN_MEMORY_PERCENT и MAX_MEMORY_PERCENT одно и то же значение.
Дополнительную информацию см. в разделе Передовой опыт использования выполняющейся в памяти OLTP в среде виртуальных машин.
Устранение сбоев выделения страниц из-за нехватки памяти при наличии достаточного объема памяти
Чтобы решить эту проблему, вам необходимо включить регулятор ресурсов.
См. раздел Включение регулятора ресурсов для получения информации об ограничениях и ограничениях, а также руководства по включению регулятора ресурсов с помощью обозревателя объектов, свойств регулятора ресурсов или Transact-SQL.
Рекомендации по использованию выполняющейся в памяти OLTP в среде виртуальных машин
Виртуализация серверов может помочь вам снизить капитальные и эксплуатационные расходы на ИТ и повысить эффективность ИТ за счет улучшенных процессов подготовки, обслуживания, доступности и резервного копирования/восстановления приложений. Благодаря последним технологическим достижениям сложные рабочие нагрузки баз данных можно легче консолидировать с помощью виртуализации. В этом разделе рассматриваются рекомендации по использованию выполняющейся в памяти OLTP SQL Server в виртуализированной среде.
Предварительное выделение памяти
Для памяти в виртуализированной среде важны более высокая производительность и расширенная поддержка. Вы должны иметь возможность как быстро выделять память виртуальным машинам в зависимости от их требований (пиковые и непиковые нагрузки), так и следить за тем, чтобы память не тратилась впустую. Функция динамической памяти Hyper-V повышает гибкость распределения памяти и управления ею между виртуальными машинами, работающими на хосте.
- Если вы используете минимальный объем памяти сервера, лучше назначать только тот объем памяти, который требуется, чтобы оставалось достаточно памяти для других процессов (тем самым избегая подкачки).
- Не устанавливайте слишком большое значение предварительного выделения памяти. В противном случае другие процессы могут не получить достаточно памяти в тот момент, когда она им требуется, что может привести к подкачке памяти.
Если вы будете следовать приведенным выше рекомендациям для базы данных с таблицами, оптимизированными для памяти, попытка восстановить и восстановить базу данных может привести к тому, что база данных окажется в состоянии "Ожидание восстановления", даже если у вас достаточно памяти для восстановления базы данных. . Причина этого в том, что при запуске In-Memory OLTP вводит данные в память более агрессивно, чем динамическое выделение памяти выделяет память для базы данных.
Разрешение
Чтобы смягчить это, предварительно выделите достаточно памяти для базы данных, чтобы восстановить или перезапустить базу данных, а не минимальное значение, полагающееся на динамическую память для предоставления дополнительной памяти при необходимости.
В этом документе обсуждаются возможные причины ошибок выделения памяти ODBC S1001 и HY001.
Решение проблемы
Недостаточно памяти
Очевидное объяснение состоит в том, что на ПК фактически закончилась память, и Client Access не смог выделить память, необходимую для дескриптора инструкции. Это может быть связано с тем, что рабочая станция имеет неправильный размер для приложения, или это может быть результатом ошибки программирования приложения, приводящей к утечке памяти. Задание сервера базы данных обычно не отображает большое количество открытых файлов или сообщение PWS0083.
Утечка дескриптора заявления о приложении
Более распространенной причиной сбоя выделения памяти является ошибка приложения, связанная с утечкой дескриптора инструкции ODBC. Приложение продолжает выделять новые дескрипторы инструкций, но никогда не освобождает ресурсы существующих дескрипторов. Обратите внимание, что только параметр SQL_DROP API SQLFreeStmt фактически освобождает всю память, связанную с дескриптором. SQL_CLOSE и SQL_UNBIND этого не делают.Поскольку каждый дескриптор оператора, выделенный приложением, также приводит к выделению памяти на сервере, программа сервера базы данных может содержать одно или несколько сообщений PWS0083.
Теоретически ODBC клиентского доступа может продолжать выделять новые дескрипторы операторов до тех пор, пока на ПК не закончится память. Однако производительность ПК (и задания сервера базы данных операционной системы) начинает снижаться задолго до этого момента, поэтому Client Access V5R1 и более поздние версии будут регистрировать предупреждающее сообщение в подробном журнале трассировки при выделении дескрипторов 5K. В более ранних версиях Client Access количество дескрипторов операторов open фактически ограничивалось примерно 1024.
С этой проблемой часто сталкиваются программисты, использующие объектную модель, созданную на основе ODBC. Некоторые распространенные приложения включают мост JDBC-ODBC, Small Talk и Visual Basic ADO. Программист может забыть уничтожить объект, когда он закончит работу с ним, или полагаться на уничтожение объекта, когда он выходит за пределы области видимости (например, с локальной переменной). В случае Java и Small Talk это зависит от сборки мусора во время выполнения. Реализации сборки мусора поставщиками сильно различаются, и в некоторых реализациях объект подключения содержит ссылку на объект инструкции. Ошибка нехватки памяти обычно появляется как прерывистая ошибка S1001, так как количество дескрипторов открытых инструкций зависит от того, насколько загружен ПК. Программист должен явно уничтожить объект, выделяющий дескриптор оператора, а не полагаться на то, что среда выполнения уничтожит его.
Отчетное количество активных операторов
Драйверы ODBC сообщают о максимальном количестве дескрипторов операторов, которые драйвер может поддерживать в API ODBC SQLGetInfo SQL_ACTIVE_STATEMENTS. Начиная с APAR SA91139 V4R5 и V4R4 клиентского доступа Access ODBC неправильно сообщает об отсутствии ограничений. Это изменение было внесено, чтобы обойти ошибку в обычном приложении для ПК, когда приложение создавало одно соединение для каждого оператора, если драйвер сообщал любое значение, отличное от 0.
Общее количество выделенных дескрипторов инструкций
Поддерживаемые версии Client Access не имеют ограничений на общее количество выдаваемых дескрипторов инструкций.
Выполнение prisma generate завершается ошибкой с этим сообщением об ошибке (спустя очень долгое время, 30 минут и более!):
Та же проблема возникает с Prisma 3.0.2
Как воспроизвести
Ожидаемое поведение
Команда должна генерировать клиент Prisma без запроса 86 ГБ ОЗУ
Информация о Призме
Среда и настройка
- ОС: Windows Server 2019 Standard
- База данных: SQL Server
- Версия Node.js: v14.15.1
Версия Prisma
Текст был успешно обновлен, но возникли следующие ошибки:
pantharshit00 прокомментировал 8 декабря 2021 г.
Спасибо за сообщение. Я могу воспроизвести это.
Ошибка воспроизведена и подтверждена.
Кандидат на следующую веху.
Проблема для Team Client.
Майкрософт SQL Server
Проблема со схемой команды.
Проблема для Team Client.
janpio изменил заголовок. Ошибка генерации prisma с ошибкой "ошибка выделения памяти [86 ГБ]" 8 декабря 2021 г.
прокомментировал pimeys 8 декабря 2021 г. •
Привет, @peteralbert. Дело не в обнаружении цикла, а в проверке каскадных путей у нас есть бесконечный цикл. В настоящее время я делаю минимальную репродукцию, но тем временем не могли бы вы db pull с последней версией prisma и посмотреть, изменяет ли она модель данных до состояния, которое больше не зацикливается? В вашей старой модели данных не было записано действий, и я очень сомневаюсь, что у вас есть циклы или несколько каскадных путей между отношениями в вашей базе данных SQL Server, поэтому сгенерированная новая модель данных с db pull не должна вызывать цикл.
Это нужно быстро исправить, поэтому я собираюсь сделать это сегодня.
прокомментировал petalbert 8 декабря 2021 г.
@pimeys db pull показывает похожее поведение — теперь он работает более 5 минут и захватывает все больше и больше памяти:
Я посмотрю, смогу ли я поделиться схемой БД, чтобы вы могли воспроизвести ее локально.
прокомментировал petalbert 8 декабря 2021 г.
Отмена извлечения базы данных сейчас, текущий статус был
pimeys прокомментировал 8 декабря 2021 г.
Схема SQL может быть нам полезна. Вы также можете отправить его по адресу schemas@prisma.io, если не хотите включать его в заявку.
прокомментировал petalbert 8 декабря 2021 г.
Только что поделился сценарием развертывания по электронной почте, указанной выше. Спасибо
pimeys прокомментировал 8 декабря 2021 г.
Спасибо. Мы поняли. Я также близок к решению этой проблемы.
прокомментировал pimeys 8 декабря 2021 г. •
У меня есть исправленный PR. Было две проблемы. Оба исправления сейчас исправлены (и будут выпущены в будущем выпуске Prisma).
прокомментировал pimeys 8 декабря 2021 г. •
Когда это объединено и вы хотите попробовать новую версию, не забудьте выполнить db pull, прежде чем что-либо делать с вашей текущей схемой, чтобы получить ссылочные действия и имена ограничений на свои места.
Один из моих клиентов связался со мной, чтобы исправить одну из ошибок, которые они получили при запуске службы SQL. В этом блоге я хотел бы поделиться своими знаниями об ошибке «Невозможно выделить достаточно памяти для запуска «Загрузка ОС SQL». Уменьшите ненужную загрузку памяти или увеличьте системную память» и как это исправить.
Мой клиент следил за статьей, так как у него был сервер-монстр с почти 2 ТБ ОЗУ. Параметры настройки SQL Server при выполнении высокопроизводительных рабочих нагрузок
Они думали, что выделение "больших страниц" поможет им повысить производительность. Следовательно, они добавили флаг трассировки 834 в параметры запуска SQL Server и попытались перезапустить службу SQL. К сожалению, служба SQL не запустилась, и они связались со мной для быстрой помощи, так как их бизнес был закрыт.
Несколько последних строк в файле ERRORLOG были такими, как показано ниже:
Использование больших страниц в диспетчере памяти.
Растровое изображение исключения страниц включено.
Ошибка выделения большой страницы во время инициализации диспетчера памяти
Не удалось инициализировать диспетчер памяти
Не удалось выделить страницы: FAIL_PAGE_ALLOCATION 2
Ошибка: 17138, серьезность: 16, состояние: 1. < br />Не удалось выделить достаточно памяти для запуска «Загрузки ОС SQL». Уменьшите ненужную нагрузку на память или увеличьте объем системной памяти.
В журнале событий это записывается, как показано ниже.
Имя журнала: Приложение,
Источник: MSSQLSERVER,
Код события: 17138,
Категория задачи: Сервер,
Уровень: Ошибка,
Ключевые слова: Классический,
Пользователь: Н/Д
Описание:
Не удалось выделить достаточно памяти для запуска «Загрузки ОС SQL». Уменьшите ненужную нагрузку на память или увеличьте объем системной памяти.
ВРЕМЕННОЕ РЕШЕНИЕ/РЕШЕНИЕ
Я провел еще одно онлайн-исследование о «больших страницах» и обнаружил, что когда SQL использует большие страницы, он пытается захватить весь максимальный размер памяти сервера во время запуска. Если он может захватить какой-то разумный объем памяти и не может выделить больше, он будет продолжать работать со значением ниже максимального объема памяти сервера. Если он не может захватить даже минимальный объем памяти, он вызовет ошибку «Невозможно выделить достаточно памяти для запуска «Загрузка ОС SQL»». Это может быть вызвано фрагментацией памяти из-за того, что сервер работает в течение длительного времени и на нем запущены другие приложения.
Чтобы решить эту проблему, сначала убедитесь, что максимальный объем памяти не превышает объем ОЗУ. Было бы неплохо перезапустить операционную систему, чтобы вся нефрагментированная память была доступна для использования SQL Server.
Читайте также: