Медленный MS SQL 2000, много таймаутов. Как я могу улучшить производительность?

Question

Я нашел этот скрипт в SQL Authority:

ИСПОЛЬЗОВАТЬ MyDatabase
GO
EXEC sp_MSforeachtable @ command1 = «печать»? DBCC DBREINDEX (’? ',’ ’, 80)»
GO
EXEC sp_updatestats
GO

Это уменьшило мою частоту отказов вставки со 100% до 50%. Это намного эффективнее, чем план технического обслуживания переиндексации.

Должен ли я также переиндексировать master и tempdb? Как часто? (Я пишу в эту базу данных 24 часа в сутки) Любые предостережения, о которых я должен знать?

Answer 1

RAID 5 на вашем NAS? Это твой убийца.

INSERT записывается в журнал: он записывает в файл .LDF (log). Этот файл на 100% записан (ну, достаточно близко).

Это огромное соотношение записи к чтению генерирует много дополнительных записей на диск в RAID 5.

У меня есть статья в работе (добавлю позже): RAID 5 записывает в 4 раза больше на диск, чем RAID 10 в ситуациях 100% записи.

* Решения 1010 *

Вам нужно как минимум разделить данные и файлы журналов для вашей базы данных.

Редактировать: Уточнил эту строку: Файлы журнала должны идти на диски RAID 1 или RAID 10. Это не так важно для файлов данных (.MDF). Файлы журналов записываются на 100%, поэтому преимущества RAID 1 или RAID 10.

Есть и другие потенциальные проблемы, такие как фрагментированная файловая система или множество сегментов Vlog (в зависимости от того, как выросла ваша база данных), но я бы сказал, что вашей основной проблемой является RAID 5.

Для БД объемом 3 ТБ я бы также добавил как можно больше оперативной памяти (32 ГБ, если Windows Advanced / Enterprise) и настроил PAE / AWE и т. Д. Это уменьшит некоторые проблемы с диском, но только для кэширования данных.

Коэффициент заполнения 85 или 90 - это обычное эмпирическое правило. Если ваши вставки широкие и не являются строго монотонными (например, столбец int IDENTITY), то у вас будет много разделений страниц с чем-либо более высоким.

Я не единственный, кто не любит RAID 5: BAARF

Редактировать еще раз:

Ищите « Протокол ведения журнала записи (WAL) » в этой статье SQL Server 2000. Это по-прежнему актуально: оно объясняет, почему файл журнала важен.

Я не могу найти свою статью о том, как страдает RAID 5 по сравнению с RAID 10 при 100% загрузке записи.

Наконец, SQL Server выполняет ввод-вывод частями по 64 КБ, поэтому отформатируйте NTFS с кластерами по 64 КБ.

Answer 2

Проверьте свои планы запросов также. Некоторые индексы могут не использоваться или SQL может быть неэффективным.

Какое обслуживание таблицы у вас есть?

все ли данные в таблицах относятся к текущей обработке?

Можете ли вы складировать некоторые данные?

Как выглядит ваша блокировка? Вы блокируете весь стол?

EDIT: Профилировщик SQL показывает все взаимодействия с SQL Server. Это должна быть жизненная сила администратора баз данных.

Answer 3

Спасибо за всю помощь. Я еще не там, но поправляюсь.

Я мало что могу сделать с аппаратными ограничениями. Вся доступная оперативная память разрешена для SQL Коэффициент заполнения установлен на 95 Используя профилировщик, часовая трассировка предложила настройку индекса с предполагаемым увеличением эффективности на 27%.

В результате я удвоил количество успешных ВСТАВК. Сейчас только 1 из 4 терпят неудачу. Отслеживание сейчас и настроиться позже, чтобы увидеть, станет ли лучше.

Пока не понимаю блокировки.

Для тех, кто поддерживает SQL Server как профессию, я на правильном пути?

Answer 4

Это может быть что угодно. Связан ли системный процессор? IO связаны? Диск слишком утомлен? Система слишком много пейджингов? Сеть перегружена?

Вы настроили индексы? Я не помню, был ли в 2000 году мастер настройки индекса, но по крайней мере вы могли запустить профилировщик, чтобы создать рабочую нагрузку, которая могла бы использоваться мастером настройки индекса SQL Server 2005.