Улучшения производительности MS SQL Datawarehouse для таблицы неуникальных ключей

Question

Недавно мы обновили наш DataWarehouse (база данных MS SQL 2000), добавив новую таблицу для контроля уровня доступа пользователей к информации во всех других таблицах.Не вдаваясь в подробности, новая таблица имеет идентификатор пользователя и список идентификаторов учетных записей, к которым они могут получить доступ.Для всех наших таблиц в DataWarehouse было создано соответствующее представление, и мы попросили наших пользователей использовать эти представления для доступа к данным (и, таким образом, ограничивают их представление на основе уровня доступа в исходной таблице контроля доступа).

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

Datawarehouse обновляется только в одночасье, и, если честно, время, которое требуется, не имеет значения - скорость вставки не требуется,только выберите.Мы также можем перестроить индексы, если это необходимо.

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

Все другие представления, которые теперь ссылаются на эту таблицу, объединяются в неиндексированный столбец (идентификатор учетной записи), а затем количество возвращаемых учетных записей отфильтровывается на основе NT-идентификатора пользователя.

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

Спасибо!

Дэвид

Answer 1

Похоже, у вас есть индекс UserId, но не AccountId, который фактически используется в соединениях.

Если я правильно понял ваши индексы, вы можете попробовать пару вещей:

• Добавить индекс по AccountId - поэкспериментируйте с кластеризованными / некластеризованными, чтобы увидеть, какое из них лучше влияет на производительность.
• Обновите индекс UserId, включив в него AccountId - это может работать лучше, если два поля всегда используются вместе.

Кроме того, при просмотре плана выполнения посмотрите на детали поиска - что он ищет? Это может помочь вам еще больше уточнить идеальные индексы для вашей системы.

Удачи!

Answer 2

К сожалению, вы не упоминаете, какой инструмент отчетности вы используете (у меня сложилось впечатление, что пользователи пишут свои собственные запросы?) Или какой объем данных у вас есть, но два более долгосрочных улучшения будут:

1. Обновление до SQL2008: SQL2000 больше не поддерживается, и производительность, инструменты и общие функции значительно улучшились в новых версиях
2. Используйте инструмент отчетности, такой как SSRS, Business Objects или Cognos, который включает поддержку видимости данных на уровне пользователя, кэширование для производительности и т. Д.

Answer 3

Если вы можете, вы должны предоставить своим пользователям процедуру хранения, которая действует следующим образом:

1. создать временную таблицу "по-старому" (без объединений)
2. отфильтровать результаты, которые пользователь мог видеть

, поэтому вы будете присоединяться только к соответствующим данным.

Это значительно улучшит время запроса (зависит от соотношения между размером базы данных и объемом соответствующих данных) и не потребует изменения схемы базы данных.