Действительно ли возможно иметь в наличии вторичный сервер, только для чтения в сценарии передачи журналов?
Печать моноширинного шрифта в размерах по умолчанию - (на листе А4) 80 столбцов 66 строками.
6 ответов
Кто-нибудь может объяснить, почему вы не можете выполнить операторы SELECT для база данных, в то время как журнал транзакций восстанавливается?
Краткий ответ: инструкция RESTORE принимает исключительную блокировку восстанавливаемой базы данных.
Что касается записи, я надеюсь, мне не нужно объяснять, почему они несовместимы с восстановлением. Почему тоже не позволяет читать? Прежде всего, невозможно узнать, будет ли сеанс, в котором заблокирована база данных, выполнять чтение или запись. Но даже если это возможно, восстановление (журнал или резервное копирование) - это операция, которая напрямую обновляет страницы данных в базе данных. Поскольку эти обновления идут прямо в физическое расположение (страницу) и не следуют логической иерархии (метаданные-раздел-страница-строка), они не будут учитывать возможные блокировки намерений от других считывателей данных и, таким образом, имеют возможность изменять структуры , как они читаются . Сканирование таблицы SELECT после указателей на следующую-предыдущую страницу приведет к беспорядку, что приведет к повреждению чтения.
Ну и да, и нет.
Вы можете делать именно то, что хотите, в том, что вы можете перенести рабочую нагрузку по отчетности на вторичный сервер, настроив доставку журналов на копию базы данных только для чтения. Я уже устанавливал этот тип архитектуры несколько раз ранее, и он действительно работает очень хорошо.
Предостережение заключается в том, что для выполнения восстановления файла резервной копии журнала транзакций не должно быть других подключений к базе данных в вопрос. Следовательно, есть два варианта: когда процесс восстановления запустится, он либо завершится с ошибкой, тем самым отдавая приоритет пользовательским соединениям, или он завершится успешно, отключив все пользовательские соединения для выполнения восстановления.
В зависимости от вашей частоты восстановления это не обязательно является проблемой. Вы просто информируете своих пользователей о том, что, скажем, каждый час в 10 часов последнего часа существует вероятность того, что ваш отчет может потерпеть неудачу. Если это произойдет, просто запустите отчет повторно.
РЕДАКТИРОВАТЬ: вы также можете оценить альтернативные архитектурные решения для вашего бизнеса. Например, репликация транзакций или зеркальное отображение базы данных с помощью моментального снимка базы данных
Вы также можете оценить альтернативные архитектурные решения для вашего бизнеса. Например, репликация транзакций или зеркальное отображение базы данных с помощью моментального снимка базы данных Вы также можете оценить альтернативные архитектурные решения для вашего бизнеса. Например, репликация транзакций или зеркальное отображение базы данных с помощью моментального снимка базы данныхЕсли у вас корпоративная версия, вы можете использовать зеркальное отображение базы данных + моментальный снимок для создания доступной только для чтения копии базы данных, доступной для отчетов и т. Д. Использование зеркального отображения «сплошная» транспортировка бревен «под капотом». Он часто используется в описанном вами сценарии.
Да, это правда.
Я думаю, что происходит следующее:
Пока журнал транзакций восстанавливается, база данных заблокирована, так как большая ее часть обновляется.
Это связано с соображениями производительности больше, чем с чем-либо еще.
Я вижу два варианта:
- Использовать зеркальное отображение базы данных.
- Запланировать доставку журналов только тогда, когда система отчетов не используется.
Небольшая путаница в том, что флаг norecovery при восстановлении означает, что ваша база данных не будет выведена из состояния восстановления в онлайн-состояние - вот почему операторы select не будут работать - база данных отключена. Флаг отсутствия восстановления позволяет вам восстанавливать несколько файлов журнала подряд (в сценарии типа DR), не возвращая базу данных в оперативный режим.
Если вы не хотите регистрировать доставку / иметь недостатки, вы можете поменять местами к односторонней репликации транзакций, но накладные расходы / настройка в целом будут более сложными.
Будет ли работать одноранговая репликация. Затем вы можете запускать запросы на одном экземпляре и таким образом сохранять нагрузку на исходный экземпляр.