Active - активная стратегия аварийного восстановления для SQL Sever 2005

Мы пытаемся разработать стратегию активного - активного аварийного восстановления для нашего хранилища данных на 6 ТБ. В нашем хранилище данных 40 баз данных, и все должно быть реплицировано в режиме реального времени.

Сайт 1: должен обрабатывать все ETL. Сайт 2: будет обрабатывать все запросы отчетов.

  • Зеркальное отображение базы данных (мы не можем позволить себе отбрасывать и создавать моментальные снимки, так как мы не можем уничтожить какие-либо соединения)
  • Репликация
  • Доставка журналов

Возможен переход на SQL Server 2008.

Каков наилучший способ повышения производительности и доступности?

С уважением, Надя


sql-server-2008 sql-server-2005
person Nagendra Somasetty    schedule 11.03.2009    source источник

Ответы (4)


arrow_upward
2
arrow_downward

Поскольку вы не можете позволить себе отказаться от активных подключений, доставка журналов тоже не вариант. Для восстановления журнала вам необходимо получить монопольный доступ к базе данных. Поддержка оборудования (SAN) будет здесь большим подспорьем. Я почти хотел бы видеть вас ETL на одном сервере, а затем сделать его активным для отчетности и использовать другой сервер для ETL. Таким образом, у вас есть сервер отчетов без процесса ETL и сервер ETL без отчетов, но вы меняете местами, который какой из них, каждую ночь? основание.

person Walden Leverich    schedule 11.03.2009
comment
Мне нравится идея. Но наш склад - это хранилище данных почти в реальном времени. Приемлемое отставание данных для бизнеса - полчаса. Разве нам не нужно отбрасывать пользователей, когда мы переключаемся с одного сервера на другой? - person Nagendra Somasetty; 12.03.2009
comment
Хранилище данных почти в реальном времени ... мне всегда нравилось это выражение. :-) В любом случае да. Это исключает идею обмена. Я чувствую, что репликация - ваш единственный вариант здесь. Но как выглядят данные, когда вы наполовину прошли загрузочную часть ETL? Разве у пользователя не может получиться недоделанный результат? - person Walden Leverich; 12.03.2009
comment
Лол я знаю. Я лысею, сохраняя это чудовище почти в реальном времени. Большая часть данных транзакционная. Я думаю, пользователям это понравится. Думаю, репликация - мой единственный вариант. - person Nagendra Somasetty; 12.03.2009
comment
Какое-то поражение цели, если ты почти в реальном времени, да? Лучше бы вам вместо этого оптимизировать дизайн OLTP? - person RobS; 31.03.2009

arrow_upward
0
arrow_downward

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

Вот как я сейчас обрабатываю 3 базы данных (11, 17 и 23 ТБ).

  1. Мы размещаем базу данных в EMC SAN.
  2. Каждые 12 часов базы данных клонируются на разных логических объектах, расположенных в одной и той же сети SAN, а затем монтируются на разных серверах. Это резервная копия на случай, если основные серверы будут закрыты. Эти базы данных обычно на 12 часов отстают от первичных баз данных. Мы используем их для отчетов, где мы можем жить с данными 12-часовой давности.
  3. Каждые 24 часа клоны из 2 копируются в другой SAN в другом здании и монтируются. Это вторичная резервная копия. В этих базах данных мы запускаем диагностику, проверки DBCC и т. Д.
  4. Всего у нас запущено 9 экземпляров SQL Server Enterprise Edition (3 продукта, 3 аварийного восстановления первой строки и 3 аварийного восстановления второй линии).
  5. Мы решили пойти по этому пути, поскольку могли жить с задержкой до 24 часов в данных.

Это, безусловно, выполнимо, но это потребует изрядного планирования, а также вложений с вашей стороны. Для нас стоимость лицензии на 9 EE была невысокой по сравнению с ценой двух SAN и межсоединения между ними.

person no_one    schedule 11.03.2009

arrow_upward
0
arrow_downward

Одноранговая репликация транзакций, вероятно, лучший вариант для вас, если вы не хотите пойти по дорогому пути аппаратной репликации SAN.

Это предложение почти в реальном времени, так что этого должно быть достаточно для отчетности.

person Nick Kavadias    schedule 13.03.2009
comment
Разве с аппаратной репликацией SAN не нужно перезапускать службу sql при каждой синхронизации? - person Nagendra Somasetty; 17.03.2009
comment
Если да. Можете ли вы сказать мне, кто является поставщиком и технологией SAN? - person Nagendra Somasetty; 17.03.2009
comment
Все крупные поставщики делают это. Я знаю, что это делает HP EVA. У меня не было возможности протестировать его работу на SQL Server, я не хочу, чтобы он работал, потому что файлы журнала и данных не будут синхронизироваться - person Nick Kavadias; 17.03.2009

arrow_upward
0
arrow_downward

В значительной степени репликация SQL Server или какое-то решение для клиентов с использованием SQL Service Broker будет вашим лучшим выбором. Если ваши таблицы статичны и все изменения данных выполняются на одном сайте, то репликация транзакций может быть вашим лучшим выбором. Вам понадобится большой канал WAN для обработки репликации, поскольку согласованность транзакций сохраняется даже при использовании нескольких потоков.

В SQL Server 2008 есть некоторые улучшения в производительности репликации, поскольку он позволяет использовать несколько потоков для распределителя, что может вам помочь.

person mrdenny    schedule 31.03.2009