База данных SQL Server с МАССИВНЫМ количеством таблиц

Question

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

Проблема не в большом количестве данных, а в огромном количестве таблиц. В одной базе данных более 30 000 таблиц. Общий объем данных составляет около 650 ГБ.

У меня нет никакого контроля над приложением, которое создает все эти таблицы. Приложение использует примерно 2500 таблиц на «подразделение» в более крупной компании с 10–15 подразделениями.

Как вы вообще начинаете проверять проблемы с производительностью? Все статьи, которые вы найдете в VLDB (Очень большие БД), касаются объема данных, а не количества таблиц.

Есть идеи? Указатели? Советы?

Answer 1

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

Вместо этого спросите пользователей "что там медленно"? Даже если вы измерили производительность (возможно, с помощью Profiler), ваши цифры могут не соответствовать воспринимаемой проблеме производительности.

Answer 2

Как уже отмечали другие, количество таблиц, вероятно, свидетельствует о плохом дизайне, но это далеко не хлам, который является источником проблем с производительностью.

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

Я бы начал с , запустив несколько трасс в базе данных, и выявил бы неэффективные запросы. Это также скажет вам, какие таблицы используются приложением чаще всего. По всей вероятности, большое количество этих таблиц, вероятно, либо: A) оставшиеся временные таблицы; Б) больше не используется; или C) рабочие столы, которые кто-то не убирал.

Answer 3

Если оставить в стороне плохой дизайн БД, если ни один пользователь не сообщает о медленном времени отклика, то у вас в настоящее время нет проблем с производительностью.

Если у вас есть проблемы с производительностью:

1) Проверка на фрагментацию (dbcc showcontig)

2) Проверьте технические характеристики оборудования, размещение RAID / дисков / файлов. Проверьте журналы ошибок сервера SQL. Если аппаратное обеспечение кажется недостаточно конкретным или плохо разработанным, запустите счетчики производительности (см. PAL инструмент)

3) Сбор данных трассировки во время обычной рабочей нагрузки запросов и определение дорогостоящих запросов (см. Этот ответ SO: Как я могу регистрировать и находить самые дорогие запросы? )

Answer 4

Программное обеспечение создает все эти таблицы? Если это так, возможно, одни и те же ошибки повторяются снова и снова. Все ли таблицы имеют первичный ключ? Все ли они имеют кластерный индекс? Имеются ли все необходимые некластеризованные индексы (те столбцы, которые используются для фильтрации и объединения) и т. Д. И т. Д. И т. Д.

Является ли обновление SQL Server 2008 одним из вариантов? Если это так, вы можете воспользоваться новой функцией Управление на основе политик , чтобы применять передовые методы для такого большого количества таблиц.

Чтобы начать настройку сейчас, я бы использовал профилировщик, чтобы найти эти операторы с наибольшей продолжительностью, а затем посмотрел бы, что вы можете сделать, чтобы улучшить их (добавить индексы, как правило, самый простой способ).