Вопросы Теги

Простая Репликация SQL Server 2005 года - “D-1” сервер используется для тяжелых запросов/отчетов

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

2. В веб-браузере Вы представлены с, вводите “C:\Windows\System32 ″ в строке поиска и совершаете нападки, входят.

3. Найдите cmd.exe в папке System32, щелкните правой кнопкой по ней и выберите “Run as Administrator”.

4. Когда контроль учётных записей предлагает Вам поднимать полномочия, щелчок позволяют.

5. Введите “slmgr - перевооружаются” в командной строке и совершают нападки, входят.

6. Перезагрузка.

2
задан 27 March 2010 в 01:44
1 ответ

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

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

Недостатки - то, что сайт создания отчетов разрушен, каждый хронологический журнал восстанавливается, все пользователи выгнаны во время восстановления.

Таким образом, если у Вас есть типичный 30-минутный резервный интервал журнала затем, сайт создания отчетов всегда - до 30 + X минут (X являющийся временем, должен был скопировать файл и восстановить его, обычно довольно маленький), и пользователи разъединяются каждые 30 минут в течение короткого времени.

Другая альтернатива является зеркальным отражением базы данных. С DBM сайт создания отчетов постоянно совершенствуется, но оборотная сторона - то, что зеркальная база данных в режиме офлайн. Отчеты должны быть выполнены от снимка базы данных, который периодически обновляется. В отличие от передачи журналов, DBM также влияет на основной сайт. Большое преимущество решения DBM для удаленных отчетов состоит в том, который когда-то развернулся, оно может служить высоким решением для доступности/аварийного восстановления также.

Некоторая репликация транзакций использования также, но я не большой поклонник той технологии. В то время как легкий достаточно для развертывания это медленно на высокой загрузке, и это имеет тенденцию столкнуться с проблемами, которые довольно трудно диагностировать и диагностировать. Кроме того, репликация не копирует точно базу данных, но вместо этого поддерживает копии опубликованных статей в базе данных распространения (т.е. выбранные таблицы и индексы), и модификации схемы требуют тщательного планирования и развертывания. С передачей журналов и зеркально отражающий изменения схемы базы данных просто копируются w/o любая проблема.

1
ответ дан 3 December 2019 в 13:31
  • 1
    Спасибо за ответ. I' ll изучают передачу журналов, даже при том, что у нас есть некоторые тяжелые отчеты, которые работают дольше, чем в течение часа, и наши резервные копирования журнала транзакций основного DB составляют каждые 30 минут. Пользователи уже вышиблены из сервера в процессе руководства d-1, который мы выполняем каждую ночь. –  Ricardo Pardini 27 March 2010 в 20:26
  • 2
    Можно использовать снимки базы данных для длительных отчетов. Создайте снимок, запустите отчет о снимке, он может работать, пока он хочет. Когда сделан, кэшируйтесь, отчет затем отбрасывают снимок. Передача журналов может быть применена тем временем w/o прерывание отчета. –  Remus Rusanu 27 March 2010 в 22:43
  • 3
    Спасибо Remus, но я думаю я can' t используют снимки начиная с I' m по Стандарту SQL 2005 года. Я думаю I' ll на самом деле пытаются реализовать roll-my-own " журнал shipping": точно так же, как мастер делает, но с дополнительной аналитикой, например: прежде, чем восстановить резервное копирование журнала, вторичное устройство оценивает число соединенных пользователей и что they' ре, делающее; если бы вторичное устройство (в большой степени) используется, оно задержало бы восстановление журнала до ' timeout' или пока пользователи не уходят. Возможно, it' s немного безумный, но у нас есть сборка более сложные решения прежде. Спасибо за всю справку! –  Ricardo Pardini 28 March 2010 в 19:18

Теги

Похожие вопросы