none
Exchange 2007 SCR параметр ReplayLagTime RRS feed

  • Вопрос

  • Всем доброе время суток.

     

    Цитата из: http://technet.microsoft.com/ru-ru/magazine/cc137735.aspx

     

    "Запаздывание воспроизведения

     

    После копирования файлов журналов на целевой компьютер репликация SCR делает то, что не выполняется при репликации LCR и CCR. Вместо немедленного воспроизведения файлов журналов в копию базы данных в SCR начинается встроенная задержка воспроизведения 50 файлов на 24 часа. В SCR можно указать дополнительное время задержки, помимо этого времени по умолчанию. Это может пригодиться в разных ситуациях. Например, в случае логического повреждения активной базы данных задержка на 24 часа может исключить логическое повреждение целевой базы данных."
     
     
     
    Непонятен один момент.
     
    ReplayLagTime - задает задержку вопроизведения файлов журналов, но при этом файлы журналов все равно копируются на целевой сервер.
    Если произошел сбой, и мы хотим поднять базу с SCR копии...то после выполнения всех необходимых действий и команд (restore-storagegroupcopy), эти журналы воспроизведутся в базе...
    Каким образом можно предотвратить логическое повреждение целевой базы данных?
     
     
    • Перемещено Hengzhe Li 18 марта 2012 г. 5:25 forum merge (От:Exchange Server 2007)
    8 октября 2008 г. 13:49

Ответы

  • Log copying to the SCR target is continuous, however SCR supports log replay lag and truncation lag.
    • Replay lag is designed to minimize the chance of needing to reseed when the source is also using continuous replication and experiences a lossy failure. By default, replay lag is set to one day.
    • Truncation lag is designed so that the logs on the target can be used to recover from loss on source. By default, truncation lag is disabled.
    • Even though an option for replay lag exists, during recovery/activation, all log files are replayed (unless the log files are removed from the log path manually).
    • http://technet.microsoft.com/en-us/library/cc535020(EXCHG.80).aspx

       

       Mikhail Aleksandrov написано:

      ReplayLagTime - задает задержку вопроизведения файлов журналов, но при этом файлы журналов все равно копируются на целевой сервер.
      Если произошел сбой, и мы хотим поднять базу с SCR копии...то после выполнения всех необходимых действий и команд (restore-storagegroupcopy), эти журналы воспроизведутся в базе...
      Каким образом можно предотвратить логическое повреждение целевой базы данных?

      Удалить лог файлы вручную

      9 октября 2008 г. 10:55

    Все ответы

    • Log copying to the SCR target is continuous, however SCR supports log replay lag and truncation lag.
      • Replay lag is designed to minimize the chance of needing to reseed when the source is also using continuous replication and experiences a lossy failure. By default, replay lag is set to one day.
      • Truncation lag is designed so that the logs on the target can be used to recover from loss on source. By default, truncation lag is disabled.
      • Even though an option for replay lag exists, during recovery/activation, all log files are replayed (unless the log files are removed from the log path manually).
      • http://technet.microsoft.com/en-us/library/cc535020(EXCHG.80).aspx

         

         Mikhail Aleksandrov написано:

        ReplayLagTime - задает задержку вопроизведения файлов журналов, но при этом файлы журналов все равно копируются на целевой сервер.
        Если произошел сбой, и мы хотим поднять базу с SCR копии...то после выполнения всех необходимых действий и команд (restore-storagegroupcopy), эти журналы воспроизведутся в базе...
        Каким образом можно предотвратить логическое повреждение целевой базы данных?

        Удалить лог файлы вручную

        9 октября 2008 г. 10:55
      •  Pavel Dugaev написано:

      • Log copying to the SCR target is continuous, however SCR supports log replay lag and truncation lag.
        • Replay lag is designed to minimize the chance of needing to reseed when the source is also using continuous replication and experiences a lossy failure. By default, replay lag is set to one day.
        • Truncation lag is designed so that the logs on the target can be used to recover from loss on source. By default, truncation lag is disabled.
        • Even though an option for replay lag exists, during recovery/activation, all log files are replayed (unless the log files are removed from the log path manually).
        • http://technet.microsoft.com/en-us/library/cc535020(EXCHG.80).aspx

           

           Mikhail Aleksandrov написано:

          ReplayLagTime - задает задержку вопроизведения файлов журналов, но при этом файлы журналов все равно копируются на целевой сервер.
          Если произошел сбой, и мы хотим поднять базу с SCR копии...то после выполнения всех необходимых действий и команд (restore-storagegroupcopy), эти журналы воспроизведутся в базе...
          Каким образом можно предотвратить логическое повреждение целевой базы данных?

          Удалить лог файлы вручную

           

          Вручную?

          Например параметр ReplayLagTime равен 24 часам.

          Я знаю, что в определенный момент времени произошло логическое повреждение исходной базы...скажем в 13.00

          Тогда в таком случае мне нужно удалить лог файлы измененные после 13.00 ?

          Так?

           

           

           

           

           

           

          9 октября 2008 г. 13:55
        • Если у вас произошло повреждение в 13.00 применимо к этой ситуации это может означать, что у вас в это время проигрался в базу лог-файл. Это означает, что вы должны удалить этот лог-файл и последующие

          9 октября 2008 г. 19:24
        • Как-то не спортивно(не красиво) получается с удалением логов...

          А не легче ли пофиксить логическое повреждение базы утилитами(eseutil, isinteg) ? Ведь  SCR больше подходит если исходный сервак вообще умер со всеми ролями 

           

          Правда если время простоя критично, то может и быстрее перейти на SCR, чем гонять базу утилитами. У меня недавно упала база(физическое повреждение базы, неправильная контрольная сумма), база 60Гиг, так я её лечил почти сутки, очень долго утилиты её гоняют. Бекапы Веритаса подвели ((...потерял я к нему доверие..хотя когда тестил его на этапе внедрения всё хорошо восстанавливалось....

          10 октября 2008 г. 7:23