Стратегия обработки отказа SQL Server 2008 года - Передача журналов или репликация?

Мы используем Зеркальное отражение для up-to-the-second локальное восстановление.

Для по WAN удаленные резервные копии (например, высокая задержка) мы используем созданный в передаче журналов.

Обратите внимание, что для ЛЮБОЙ опции необходимо настроить это ДЛЯ КАЖДОЙ БАЗЫ ДАННЫХ, который, для 400 DBS, будет гигантская боль сзади.

Вы используете массив хранения данных (SAN или NAS)? Самый легкий метод, кажется, репликация блочного уровня с помощью Ваших снимков массива хранения данных (с соответствующим SQL Server, замораживают плагин) - это получит КАЖДУЮ базу данных автоволшебно.

Вот некоторые дополнительные мысли:

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

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

При контакте с этим многих баз данных это лучше, чтобы реализовать Геокластерное решение или использовать некоторую форму репликации SAN и работы над уровнем громкости или блочным уровнем. Если у Вас нет SAN затем, внешнее программное обеспечение, такое как InMage или Doubletake может добиться цели.

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

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

Ross Mistry, MVP SQL

Автор - управление и администрация SQL Server 2008 года и развязанный Windows Server 2008

Твиттер - @RossMistry

Это зависит в основном от навыка Вашего DBA.
Если у Вас есть квалифицированный DBA, затем зеркально отражающий, самая безопасная опция с самой быстрой обработкой отказа, если Вы настраиваете его с сервером свидетеля затем, "клиент" не должен замечать ничего кроме небольшой задержки. Если бы Ваш DBA является менее квалифицированной передачей журналов, способ пойти, но это имеет более долгую более сложную стандартную программу обработки отказа, которая включила бы воспроизведение транзакций, которые еще не фиксировались в файлу первичных данных и не были переданы. Если бы Вы надеетесь проигрывать не больше, чем, 15-30 минут данных, затем зеркально отражающих, были бы Вашим наилучшим вариантом.
При выполнении этого только с 2 серверами, необходимо установить его на режим высокой безопасности, 3-й дополнительный сервер Свидетеля может быть экземпляром экспресса SQL2008, таким образом, Вы только отсутствуете минимальные затраты на оборудование, так не исключайте это как опцию.
Я записал руководству по тому, как зеркально отразить два SQL 2 005 серверов, которые не являются членами домена в этом режиме, и это доступно http://danmacs.blogspot.com/2009/05/database-mirroring-for-non-domain-ms.html
В этом сценарии обработка отказа является ручной (но быстро), существует только возможность одной потерянной транзакции (предполагающий, что Ваше зеркало работает правильно), НО клиенты, которые соединяются с ним, должны будут быть отодвинуты вручную (или через изменение DNS, если Вы будете делать TCP/IP и не использовать именованные каналы, именованные каналы могут работать, но я не мог сказать наверняка),

Сколько денег Ваша компания имеет?

Если они - сброс и существует требование для перемещения всех баз данных затем два узла активный/пассивный кластер с теплой репликацией SAN другому от сайта, который добился бы цели активный/пассивный кластер :)

Если не затем придерживаются передачи журналов - Предприятие 2008 года предоставляет Вам преимущества сжатых резервных копий журнала (за счет CPU), и все выпуски SQL с 2005 вперед имеют способность взять резервные копии журнала одновременно с полным резервным копированием (который был проблематичен на 2 000 полей с большими объемами транзакционного действия).

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

Вы посмотрели на зеркальное отражение также?

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

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

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

Каждая зеркальная база данных использует несколько потоков, и SQL Server только настроен для выполнения с 255 потоками по умолчанию. Когда у Вас заканчиваются рабочие потоки, неудачные вещи происходят. Я выполнил серверы, которые были настроены с большим количеством потоков (512, IIRC), но это, казалось, раздражало MS очень. Выполнение чего-то, что раздражает MS, имеет тенденцию заканчиваться плохо.

Я думаю, что Вы могли пойти с поставленными базами данных 400 журналов, предположив, что нет слишком большого трафика журнала и что Вы пишете некоторые инструменты для выручения Вас с установкой их и контролем их. Инструменты могли быть записаны в tsql или чем-то как powershell.

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

http://msdn.microsoft.com/en-us/library/ms366349 (SQL.90) .aspx

Говорит 10, зеркально отразил DBS, макс. для машины на 32 бита.