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

Question

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

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

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

Как вы даже начинаете проверять проблемы с производительностью? Все статьи, которые вы найдете в VLDB (Very Large DB), касаются количества данных, а не количества таблиц.

Любые идеи? Указатели? Советы?

Answer 1

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

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

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

Answer 2

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

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

Answer 3

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

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

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

Answer 4

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

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

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

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

3) Сбор данных трассировки во время нормальной работы запроса нагрузки и определить дорогие запросы (см этого SO ответа: How Can I Log and Find the Most Expensive Queries?)