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

Question

Я изучаю возможность использования доставки журналов в среде SQL Server 2005.Идея заключалась в том, чтобы настроить частую доставку журналов на дополнительный сервер.Намерение:Используйте вторичный сервер для обслуживания запросов отчетов, тем самым разгружая основной сервер БД.

Я наткнулся на это на ветка форума sqlservercentral:

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

Итак, мои вопросы:

• Верно ли вышесказанное?Неужели вы действительно не можете использовать доставку журналов так, как я собираюсь?
• Если это правда, может ли кто-нибудь объяснить, почему вы не можете выполнить инструкции SELECT для базы данных во время восстановления журнала транзакций?

РЕДАКТИРОВАТЬ:

Первый вопрос является дубликатом этот вопрос о сбое сервера.Но мне все же хотелось бы получить ответ на второй вопрос:Почему невозможно выполнить операторы SELECT во время восстановления журнала транзакций?

Answer 1

Может ли кто -нибудь объяснить, почему вы не можете выполнить выбранные операторы в базу данных, пока журнал транзакций восстанавливается?

Короткий ответ: инструкция RESTORE устанавливает исключительную блокировку восстанавливаемой базы данных.

По поводу пишет, надеюсь, мне не нужно объяснять, почему они несовместимы с восстановлением.Почему он тоже не разрешает чтение?Прежде всего, невозможно узнать, будет ли сеанс с блокировкой базы данных выполнять чтение или запись.Но даже если бы это было возможно, восстановление (журнал или резервное копирование) — это операция, которая обновляет непосредственно страницы данных в базе данных.Поскольку эти обновления идут прямо в физическое местоположение (страницу) и не следуют логической иерархии (раздел метаданных-страница-строка), они не учитывают возможные блокировки намерений со стороны других читателей данных и, таким образом, имеют возможность изменять структуры. как они читаются.Сканирование таблицы SELECT после указателей следующей-предыдущей страницы приведет к беспорядку, что приведет к повреждению чтения.

Answer 2

Ну да и нет.

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

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

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

РЕДАКТИРОВАТЬ:Вы также можете оценить альтернативные архитектурные решения, соответствующие потребностям вашего бизнеса.Например, репликация транзакций или зеркальное отображение базы данных с помощью моментального снимка базы данных.

Answer 3

Если у вас корпоративная версия, вы можете использовать зеркальное отображение базы данных + моментальный снимок, чтобы создать копию базы данных, доступную только для чтения, доступную для отчетов и т. д.Зеркальное отображение использует «непрерывную» доставку журналов «под капотом».Он часто используется в описанном вами сценарии.

Answer 4

Да, это правда.

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

Я вижу два варианта:

1. Используйте зеркалирование базы данных.
2. Запланируйте доставку журналов только тогда, когда система отчетов не используется.

Answer 5

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

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

Answer 6

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