Я разработчик, и мне потребуются советы администратора базы данных.
Мы начинаем получать проблемы с производительностью базы данных MSSQL2005. Видимые последствия инцидентов в основном связаны с загрузкой ЦП на сервере, но операторы сообщили, что это также истощает ресурсы из SAN (не всегда). основной источник проблем наверняка находится в каком-то приложении, но мне интересно, должны ли мы в любом случае разделить некоторые из основных таблиц, чтобы уменьшить нагрузку на ввод-вывод.
База составляет около 60Гб в одном файле.
Основная таблица (порядок) имеет 2,1 миллиона строк с 215 двоеточиями (но ни одна из них не является огромной).
У нас есть целое число как PK, так что определение функции секционирования должно быть нормальным.
Выиграем ли мы что-нибудь с разметкой? индексы раздела нам что-нибудь купят?
Вот еще несколько фактов о БД и таблице
database_name database_size unallocated space
My_base 57173.06 MB 79.74 MB
reserved data index_size unused
29 444 808 KB 26 577 320 KB 2 845 232 KB 22 256 KB
name rows reserved data index_size unused
Order 2 097 626 4 403 832 KB 2 756 064 KB 1 646 080 KB 1688 KB
Дом
А - почему? 15 лет назад 1 миллион строк считался маленьким. Сегодня 100 миллионов строк считаются маленькими.
Если у вас сильно загружен процессор, я бы начал искать, в чем проблема - это больше похоже на проблему с индексом и / или плохой дизайн поля, чем на что-либо еще.
Захват SAN - это совершенно нормально для любого SQL Server. Специалисты по SAN обычно совершенно не осведомлены о том, что серверы баз данных требуют большого количества операций ввода-вывода. Базы данных обычно требуют определенной настройки SAN, которая оптимизирована для них и может быть ими полностью использована. Он не «забивает» его, он старается использовать все ресурсы как можно лучше.
Ваша база данных МАЛЕНЬКАЯ - серьезно. Я не вижу здесь никаких проблем. Таблица заказов имеет всего 4 ГБ памяти, что, что довольно интересно, это размер, на который следует отвечать по памяти.
Секционирование полезно для массового удаления (одна таблица в год, удаление заказов за год - это усечение таблицы, а не удаление), но с вашим размером это не проблема (у меня есть таблица цен, в которой содержится около 1,5 МИЛЛИАРДА записей, и то маленький). Он не будет сильно ускорять запросы - либо запрос может быть выбран только для одного раздела (и нет, целочисленный PK не поможет, если вы не выберете диапазон PK в качестве фильтра), либо он не может. Но даже если это возможно, индекс работает почти так же быстро.
Какой тип запроса плохой? Как план исполнения? Может быть, вы:
Слишком мало памяти (8 ГБ или больше?)
У вас есть субоптимальный / несоответствующий макет индекса, чтобы запрос в основном превращался в сканирование таблицы? В этом случае я бы начал фиксировать с той стороны.
Вы загружаете больше данных, чем вам нужно?
Без вашего плана выполнения запроса на это невозможно ответить.
Кстати, 60 ГБ в одном файле - это полное пренебрежение. В ЛЮБОЙ крупной базе данных должно быть столько файлов, сколько возможно для параллельных операций (т.е. доступные серверные ядра для SQL Server);) И я уверен, что ваш ввод-вывод так же плохо организован - невыровненный раздел, плохое форматирование, замедление работы ( возможно много - плохая установка диска может стоить вам до 40% производительности).
Чтобы ослабить давление ввода-вывода:
Убедитесь, что ваш сервер базы данных установлен правильно (я редко вижу его - администраторы, похоже, любят игнорировать здесь документацию)
Прежде всего убедитесь, что у вас есть необходимые ресурсы. Насколько высок ваш бюджет операций ввода-вывода в секунду для дисковой подсистемы? Ты это измерил, или?
Убедитесь, что базы данных настроены правильно (опять же, большинство администраторов любят в этом случае быть невежественными)
Убедитесь, что у вас хорошая структура таблицы и хороший первичный ключ (практически единственное, что у вас есть право).
Затем - войдите в профилировщик, найдите приложение и убедитесь, что эти запросы оптимизированы.