Проблема с нехваткой памяти в SQL Server 2005 и записью в базу данных tempdb
У нас возникли некоторые проблемы с нашим производственным SQL Server.
Сервер: Dual Quad Core Xeon 8 ГБ ОЗУ Один RAID 10 Массив Windows 2003 Server 64-разрядный SQL Server 2005 Стандартный 64-разрядный
Сейчас на машине около 250 МБ свободной оперативной памяти. SQL Server имеет около 6 ГБ ОЗУ, и наше программное обеспечение для мониторинга сообщает, что фактически используется только половина выделенного ОЗУ SQL Server.
Наша основная база данных составляет приблизительно 20 ГБ, причем около 12 ГБ используется с любой частотой. Наша база данных находится в 700 МБ. Оба расположены на одном физическом дисковом массиве.
Кроме того, используя Filemon, я смог увидеть, что файл tempdb имел 100 или 1000 записей длиной 65536. Длина очереди диска превышала 100 почти в 80% случаев.
Итак, вот мои вопросы
Что вызвало бы все эти записи в базе данных tempdb? Я не уверен, что у нас всегда была такая большая активность, но это кажется чрезмерным, и эти проблемы недавние.
Должен ли я просто добавить больше памяти на сервер?
На серверах с высокой нагрузкой файлы tempdb и db должны находиться в отдельных массивах?
5 ответов
Большая длина очереди диска не означает, что у вас есть узкое место ввода-вывода, если у вас есть SAN или NAS, вы можете посмотреть другие дополнительные счетчики. Проверьте обсуждаемые городские легенды SQL Server для получения более подробной информации.
1: следующие операции интенсивно используют базу данных tempdb
- Повторное создание и удаление временных таблиц (локальных или глобальных)
- Табличные переменные, которые используют tempdb для хранения
- Рабочие столы, связанные с КУРСОРАМИ
- Рабочие таблицы, связанные с предложением ORDER BY
- Рабочие таблицы, связанные с предложением GROUP BY
- Рабочие файлы, связанные с HASH PLANS
Эти функции SQL Server 2005 также интенсивно используют базу данных tempdb:
- управление версиями на уровне строк (моментальный снимок)
- восстановление индекса онлайн
Как уже упоминалось в других ответах SO, прочитайте эту статью о передовом опыте повышения производительности базы данных tempdb.
2: Анализ количества свободной оперативной памяти на сервере, т. Е. Просмотр счетчика WMI Память-> Доступные мегабайты, не помогает, поскольку SQL Server будет кэшировать страницы данных в оперативной памяти, поэтому любой сервер БД, который работает достаточно долго, будет иметь мало свободной оперативной памяти.,
Счетчики, на которые вы должны обратить внимание, которые более осмысленно сообщают вам, поможет ли добавление ОЗУ на сервер:
Экземпляр SQL Server:Buffer Manager-> Ожидаемая продолжительность жизни страницы (в секундах). Значение ниже 300-400 секунд будет означать, что страницы не находятся в памяти слишком долго и данные непрерывно считываются с дисков. Серверы с низкой продолжительностью жизни страниц выиграют от дополнительной оперативной памяти.
а также
Экземпляр SQL Server:Buffer Manager-> Коэффициент попадания в буферный кэш. Это говорит о процентном соотношении страниц, которые были прочитаны из ОЗУ, которым не требовалось чтение с диска; коэффициент попаданий в кэш ниже 85 будет означать, что сервер выиграет из дополнительной оперативной памяти
3: Да, не может пойти не так, как надо здесь. Рекомендуется иметь tempdb на отдельном наборе дисков. Посмотрите на эту статью базы знаний под заголовком: Перемещение базы данных tempdb, как это сделать.
Не является прямым ответом на ваш вопрос, но это может быть хорошим советом: перезапуск вашего экземпляра SQL Server очистит базу данных tempdb, это может быть хорошим началом при изучении действий, которые выполняются на базе данных tempdb.
Отличный вопрос, +1
tempdb используется гораздо интенсивнее в SQL 2005+. По крайней мере: уровни изоляции моментального снимка, перестроение индекса онлайн, чтение INSERTED/DELETED в триггерах (используется для чтения файла журнала!)
Это в дополнение к обычному порядку предложений, временных таблиц и т. Д.
Возможно, вам лучше разделить ваш журнал и файлы данных (также для восстановления). Больше памяти всегда хорошо, но посмотрите этот 64-битный специфический материал, Grumpy Old DBA ниже.
Наконец, и, возможно, наиболее важно, вероятно, вы можете столкнуться с проблемой распределения пространства в базе данных tempdb: Пояснения от команды Linchi Shea и хранилища SQL Server.
Позднее редактирование:
Пол Рэндалл (Paul Randall) добавил запись " Обширная серия постов в блоге tempdb ", которая предлагает хорошие ссылки
Да, на серверах с высокой нагрузкой рекомендуется устанавливать TempDB на отдельный набор дисков из пользовательских баз данных:
Электронная документация по SQL Server 2005: оптимизация производительности базы данных tempdb
Писать в tempdb можно что угодно. Внутренние хеш-таблицы, временные таблицы, табличные переменные, вызовы хранимых процедур и т. Д.
Если у вас есть только 250 мегабайт свободной оперативной памяти, тогда да, больше оперативной памяти было бы хорошо.
Всегда рекомендуется разбивать базу данных tempdb и пользователя на разные диски.
Все записи в базу данных tempdb будут иметь размер 64 КБ, так как это размер каждого экстента базы данных.