У нас есть две машины SQL 2005. Один используется для производственных данных, а другой - для выполнения запросов / отчетов. Каждую ночь производственная машина сбрасывает (создает резервные копии) свою базу данных на диск, а другая восстанавливает ее. Это называется процессом D-1.
Я думаю, что должен быть более эффективный способ сделать это, поскольку SQL 2005 имеет множество форм репликации. Некоторые требования:
1) Нет необходимости в мгновенной репликации, может быть (некоторая) задержка
2) Все изменения (включая схемы, данные, ограничения, индексы) необходимо реплицировать без ручного вмешательства.
3) Используется только для одной базы данных
4) При необходимости доступен третий сервер
5) Между серверами имеется высокая пропускная способность (гигабитный Ethernet).
6) Нет доступного общего хранилища (SAN)
Что было бы хорошей альтернативой ежедневному резервному копированию / восстановлению? Спасибо!
Лучшая альтернатива - это доставка журналов. Доставка журналов также основана на резервном копировании / восстановлении, но после начального заполнения полной резервной копии базы данных сайт отчетов поддерживается путем применения резервных копий журналов с основного сайта. Доставка журналов хороша, потому что:
Минусы в том, что сайт отчетов нарушается каждый раз при восстановлении журнала, все пользователи удаляются во время восстановления.
Таким образом, если у вас есть типичный 30-минутный интервал резервного копирования журнала, то сайт отчетов всегда составляет до 30 + X минут (X - время, необходимое для копирования файла и его восстановления, обычно довольно мало), и пользователи отключаются каждые 30 минут на короткое время.
Другая альтернатива - зеркальное отображение базы данных. С помощью DBM сайт отчетов постоянно обновляется, но недостатком является то, что зеркальная база данных отключена. Отчеты должны запускаться из снимок базы данных который периодически обновляется. В отличие от доставки журналов, DBM также влияет на основной сайт. Большим преимуществом решения DBM для внешних отчетов является то, что после развертывания оно также может служить решением для обеспечения высокой доступности / аварийного восстановления.
Некоторые используют репликация транзакций тоже, но я не большой поклонник этой технологии. Хотя его достаточно легко развернуть, он работает медленно при высокой нагрузке и имеет тенденцию сталкиваться с проблемами, которые довольно сложно выявить и диагностировать. Кроме того, репликация не копирует точно базу данных, а вместо этого поддерживает копии опубликованных статей в базе данных распространителя (т. Е. Выбранные таблицы и индексы), а изменения схемы требуют тщательного планирования и развертывания. С доставкой журналов и зеркальным отображением изменения схемы базы данных просто реплицируются без каких-либо проблем.