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

Question

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

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

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

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

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

EDIT:

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

Answer 1

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

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

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

Answer 2

Ну да и нет.

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

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

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

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

Answer 3

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

Answer 4

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

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

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

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

Answer 5

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

Answer 6

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

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