Использование дубликата базы данных SQL Server для запросов

Question

У меня очень большая (более 100 гигабайт) база данных SQL Server 2005, которая получает большое количество вставок и обновлений с меньшими частыми выборами. Для выбора требуется много индексов, чтобы поддерживать их нормальное функционирование, но, похоже, что число индексов влияет на эффективность вставок и обновлений.

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

Answer 1

Вы хотите настроить топологию базы данных master / child с использованием репликации. С SQL-сервером вам нужно настроить репликацию между двумя базами данных (желательно на отдельном оборудовании). Master DB вы должны использовать для вставок и обновлений. Ребенок будет обслуживать все ваши избранные запросы. Вы также захотите оптимизировать обе настройки конфигурации базы данных для типа работы, которую они будут выполнять. Если у вас есть тяжелые запросы на выборку в дочерней базе данных, вы также можете настроить представления, которые позволят выполнять запросы лучше, чем сложные объединения таблиц.

Некоторые справочные материалы по тиражированию:

http://technet.microsoft.com/en-us/library/ms151198.aspx

Просто Google, и вы найдете много информации о том, как установить и настроить:

http://search.aim.com/search/search?&query=sql+server+2005+replication&invocationType=tb50fftrab

Answer 2

Транзакционная репликация может сделать это, поскольку у подписчика может быть несколько дополнительных индексов по сравнению с издателем. Но вы должны иметь в виду простой факт: все вставки / обновления / удаления будут реплицироваться в отчетной копии (подписчике), а дополнительные индексы ... замедляют репликацию. На самом деле возможно замедлить репликацию до скорости, которую невозможно поддерживать, что приводит к увеличению объема распределительной БД. Но это только тогда, когда у вас постоянно высокий уровень обновлений. Если проблемы возникают только в периоды пиковых нагрузок, тогда DB распределения будет действовать как очередь, которая поглощает пики и выравнивает их в непиковые часы.

Я бы не стал использовать этот метод без абсолютного, 100% -ного доказательства того, что дополнительные индексы замедляют вставку / обновление / удаление, а также без тестирования того, что вставка / обновление / удаление действительно работают значительно лучше. без лишних индексов. В частности, убедитесь, что виновником не является другой обычный подозреваемый: блокировка конкуренции.

Answer 3

Не забудьте настроить коэффициент заполнения при создании двух ваших баз данных. Он должен быть низким (er) для базы данных с частыми обновлениями и 100 для вашей «базы данных» / базы данных только для чтения.

Answer 4

Как правило, все операции на основе множеств (включая обновление индексов) выполняются быстрее, чем операции на основе множеств

1,000 вставки, скорее всего, будут медленнее, чем одна вставка 1,000 записей.

Вы можете пакетно обновлять вторую базу данных. Это, во-первых, ускорит обновление индекса, а во-вторых, сгладит пики.

Answer 5

Вы можете запланировать сценарий bcp для копирования данных в другую БД.

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