Проблема с нехваткой памяти в SQL Server 2005 и записью в базу данных tempdb

Question

У нас возникли некоторые проблемы с нашим рабочим SQL Server.

Сервер: Dual Quad Core Xeon 8 ГБ ОЗУ Один массив RAID 10 Windows 2003 Server 64-разрядный SQL Server 2005 Standard 64-разрядная

Сейчас на машине около 250 МБ свободной оперативной памяти. SQL Server имеет около 6 ГБ ОЗУ, и наше программное обеспечение для мониторинга сообщает, что фактически используется только половина выделенной ОЗУ SQL Server.

Наша основная база данных составляет приблизительно 20 ГБ, причем около 12 ГБ используется с любой частотой. Наша база данных находится в 700 МБ. Оба находятся на одном физическом дисковом массиве.

Кроме того, используя Filemon, я смог увидеть, что в файле tempdb было 100 или 1000 записей длиной 65536. Длина очереди на диск превышала 100 почти в 80% случаев.

Итак, вот мои вопросы ...

1. Что может вызвать все эти записи в базе данных tempdb? Я не уверен, что у нас всегда было так много активности, но это кажется чрезмерным, и эти проблемы недавние.

2. Стоит ли просто добавить больше памяти на сервер?

3. На серверах с высокой нагрузкой файлы tempdb и db должны находиться в отдельных массивах?

Answer 1

Большая длина очереди диска не означает, что у вас есть узкое место ввода / вывода, если у вас есть SAN или NAS, вы можете посмотреть другие дополнительные счетчики. Проверьте Городские легенды SQL Server, обсуждаемые для получения более подробной информации.

1: следующие операции интенсивно используют tempdb

• Повторное создание и удаление временных таблиц (локальных или глобальных)
• Табличные переменные, которые используют базу данных tempdb для хранения
• Рабочие таблицы, связанные с CURSORS
• Рабочие таблицы, связанные с предложением 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, как это сделать.

Answer 2

Не является прямым ответом на ваш вопрос, но это может быть хорошим советом: перезапуск вашего экземпляра SQL Server очистит базу данных tempdb, это может быть хорошим началом при исследовании действий, выполняемых на базе данных tempdb.

Answer 3

Да, на серверах с высокой нагрузкой рекомендуется устанавливать TempDB на отдельный набор дисков из пользовательских баз данных:

Электронная документация по SQL Server 2005: оптимизация производительности базы данных tempdb

Answer 4

Отличный вопрос, + 1

tempdb гораздо интенсивнее используется в SQL 2005+. По крайней мере: уровни изоляции моментального снимка, перестроение индекса онлайн, чтение INSERTED / DELETED в триггерах (используется для чтения файла журнала!)

Это в дополнение к обычному порядку предложений, временных таблиц и т. Д.

Возможно, вам лучше разделить журнал и файлы данных (также для возможности восстановления). Больше памяти всегда хорошо, но посмотрите этот 64-битный материал, Grumpy Old DBA ниже.

Наконец, и, возможно, наиболее важно, вероятно, вы можете столкнуться с распределением пространства в базе данных tempdb: Пояснения от Линчи Ши и Команда хранения SQL Server

Позднее редактирование:

Пол Рэндалл добавил запись " Обширная серия постов в блоге tempdb ", которая предлагает хорошие ссылки

Answer 5

1. Запись в базу данных tempdb может быть любой. Внутренние хеш-таблицы, временные таблицы, табличные переменные, вызовы хранимых процедур и т. Д.

2. Если у вас есть только 250 МБ свободной ОЗУ, тогда да, больше ОЗУ было бы хорошо.

3. Всегда рекомендуется разбивать базы данных tempdb и пользователей на разные диски.

Все записи в базу данных tempdb будут иметь размер 64 КБ, так как это размер каждого экстента базы данных.