Выполнение больших обновлений с индексированным представлением

Question

У нас есть индексированный вид, который проходит через три большие таблицы. Две из этих таблиц (A & B) постоянно обновляются с помощью пользовательских транзакций, а другая таблица (C) содержит информацию о продукте данных, которую необходимо обновлять один раз в неделю. Эта таблица продуктов содержит более 6 миллионов записей.

Нам нужен этот вид через эти три таблицы для нашего основного бизнес-процесса, и, к сожалению, мы не можем изменить этот аспект. У нас даже был MVP-сервер sql, который помогает тестировать под нагрузкой, чтобы убедиться, что у нас самая эффективная конфигурация. В таблице продуктов есть один столбец, который используется в представлении и должен обновляться каждую неделю.

Проблема, с которой мы сталкиваемся сейчас, заключается в том, что по мере увеличения объема транзакций по сравнению с таблицами A & B обновление таблицы C вызывает взаимоблокировки.

Я пробовал несколько разных методов безрезультатно: 1) Я надеялся, что мы сможем изменить представление, чтобы таблица C могла быть грязной, прочитав «WITH (NOLOCK)», но, по-видимому, эта функция недоступна с индексами Просмотры.

2) Я подумал об обновлении нового столбца в таблице C, а затем просто переименовал его, когда процесс завершен, но вы не можете этого сделать из-за зависимости в представлении.

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

4) Мы попытались сделать еженедельное обновление в небольших кусках (как минимум, 100 записей за раз), но мы все еще сталкиваемся с мертвыми замками.

вопросы:

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

b) лучший подход к изменению существующего представления, чтобы указать на новую таблицу?

спасибо!

Answer 1

Считаете ли вы, что C является секционированной таблицей и заменой раздела в качестве механизма обновления цены? Я не уверен, как это будет работать с индексированным представлением - я бы подумал, что индекс должен быть перестроен в этот момент. Я думаю, что это, вероятно, та же самая ситуация, которую вы видите с помощью ALTER TABLE.

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

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

Answer 2

Проблема, с которой вы столкнулись, заключается в том, что добавление индексированного представления между тремя таблицами вызывает конфликт блокировок.Существует очень хорошая статья о проблеме: http://sqlblog.com/blogs/alexander_kuznetsov/archive/2009/06/02/be-ready-to-drop-your-indexed-view.aspx

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

Более подробная информация о разделительных выровненном индексированных просмотрах: http://msdn.microsoft.com/en-us/library/dd171921.aspx

Answer 3

Мы можем попробовать это для избежать блокировок.

SELECT a,b,c FROM indexedview as v WITH (NOEXPAND,NOLOCK) WHERE ...