Назад | Перейти на главную страницу

Должен ли я разделить мою основную таблицу на 2 миллиона строк?

Я разработчик, и мне потребуются советы администратора базы данных.
Мы начинаем получать проблемы с производительностью базы данных 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% производительности).

Чтобы ослабить давление ввода-вывода:

  • Убедитесь, что ваш сервер базы данных установлен правильно (я редко вижу его - администраторы, похоже, любят игнорировать здесь документацию)

  • Прежде всего убедитесь, что у вас есть необходимые ресурсы. Насколько высок ваш бюджет операций ввода-вывода в секунду для дисковой подсистемы? Ты это измерил, или?

  • Убедитесь, что базы данных настроены правильно (опять же, большинство администраторов любят в этом случае быть невежественными)

  • Убедитесь, что у вас хорошая структура таблицы и хороший первичный ключ (практически единственное, что у вас есть право).

Затем - войдите в профилировщик, найдите приложение и убедитесь, что эти запросы оптимизированы.