none
Не чистятся логи Event ID от ESE 519 RRS feed

  • Вопрос

  • Помогите как решить проблемку

    Вообщем как всегда все проблемы от лени вместо того что бы пояснить начальству что диски сервера переполненны и нужно подождать пока пройдет бекап и почистятся логи напарник где то выкопал статью о том что часть логов можно обсолюдно спокойно стереть и все будет ок что он благополучно и сдела. Когда я добрался до сервера и решил таки пормально его забекапить стала валится вот такая ошибка:

    eseutil (11080) JetDBUtilities - 12636: Файлы журнала с \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy126\Program Files\Microsoft\Exchange Server\V14\Mailbox\Mailbox Database 0851184493\E0000122400.log по \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy126\Program Files\Microsoft\Exchange Server\V14\Mailbox\Mailbox Database 0851184493\E000012249F.log отсутствуют (ошибка -528) и не могут использоваться. Если эти файлы журнала необходимы для восстановления, для успешного завершения восстановления потребуется работоспособная копия этих файлов журнала.

    Для получения дополнительных сведений щелкните следующую ссылку: http://www.microsoft.com/contentredirect.asp.

    Подскажите что теперь делать?

    Из того что нашел в сети рекомендуют включить циклическое ведение журналов перезапустить службу "Банк данных Exchange" и через некоторое время отключить циклическое ведение и опять передернуть службу.

    Насколько этот метод верный или есть еще какотйо вариант?

    7 апреля 2013 г. 16:30

Ответы

  • День добрый.

    Перенесите базу данных на сервер или рабочую станции и выполните проверку базы данных.

    Eseutil

    Последствия выполнения команды eseutil /p или edbutil /d /r в Exchange


    MCITP. Знание - не уменьшает нашей глупости.

    9 апреля 2013 г. 10:49
    Модератор
  • Перенести это остановить службу и скопировать на другой компьютер. 

    На другом компьютере ее проверить.

    Exchange Database Recovery – Using eseutil commands

    1. Создайте директорию c:\exchangeese (не обязательно эту, но без пробелов, и латиницей)
    2. Скопируйте с сервера Exchange, файлы:  Eseutil.exe, Ese.dll, Jcb.dll, Exosal.dll, Exchmem.dll, ntlsapi.dll папку c:\exchangeese


    MCITP. Знание - не уменьшает нашей глупости.

    9 апреля 2013 г. 11:42
    Модератор
  • Да, после копирования запускайте службу.  Вы сможете узнать время простоя и задокументируете порядок устранения ошибок.


    MCITP. Знание - не уменьшает нашей глупости.

    9 апреля 2013 г. 14:14
    Модератор
  • Помогите как решить проблемку

    Вообщем как всегда все проблемы от лени вместо того что бы пояснить начальству что диски сервера переполненны и нужно подождать пока пройдет бекап и почистятся логи напарник где то выкопал статью о том что часть логов можно обсолюдно спокойно стереть и все будет ок что он благополучно и сдела. Когда я добрался до сервера и решил таки пормально его забекапить стала валится вот такая ошибка:

    eseutil (11080) JetDBUtilities - 12636: Файлы журнала с \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy126\Program Files\Microsoft\Exchange Server\V14\Mailbox\Mailbox Database 0851184493\E0000122400.log по \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy126\Program Files\Microsoft\Exchange Server\V14\Mailbox\Mailbox Database 0851184493\E000012249F.log отсутствуют (ошибка -528) и не могут использоваться. Если эти файлы журнала необходимы для восстановления, для успешного завершения восстановления потребуется работоспособная копия этих файлов журнала.

    Для получения дополнительных сведений щелкните следующую ссылку: http://www.microsoft.com/contentredirect.asp.

    Подскажите что теперь делать?

    Из того что нашел в сети рекомендуют включить циклическое ведение журналов перезапустить службу "Банк данных Exchange" и через некоторое время отключить циклическое ведение и опять передернуть службу.

    Насколько этот метод верный или есть еще какотйо вариант?

    У Вас вообще резервное копирование при этом проходит хоть как-то? Т.е. - Вы можете выдернуть из резервной копии файл базы данных ("Mailbox Database 0851184493.edb") и посмотреть командой eseutil /mh заголовок файла. По заголовку будет видно, нужны ли удаленные журналы для восстановления базы данных. Если нет, то на это предупреждение можно не обращать внимания.

    А чтобы предупреждения в таком случае не было, вероятно, стоит размонтировать базу, убедиться, что она находится в состоянии Clean shutdown и убрать логи с номерами меньшими, чем удаленные.

    Предупреждение! Все вышенаписанное предполагает, что у Вас не используется DAG. Потому что репликация логов для пассивной копии - это отдельная история.

    PS Если Вы делаете копию с помощью встроенного Windows Server Backup, то файл базы находится на одном из VHD, создаваемых этой программой, этот VHD можно подмонтировать (лучше - на другом сервере) с помощью Server manager. В противном случае смотрите документацию по своей программе резервного копирования.

    PPS Если файл базы не попадает в резервную копию, то можно проверить файл, не размонтируя базу, создав теневую копию вручную, командой diskshadow и скопировав этот файл куда-нибудь из этой теневой копии.


    Слава России!


    9 апреля 2013 г. 20:28
  • Все спасибо за помощь и советы.

    Откинул  проверил базу сказало что все нормально после чего на рабочем сервере перевел логи в циклическое ведение перезапустил хранилище и вернул назад опять перезапустив после чего логи очистились и вот уже несколько дней бекап проходит штатно и логи чистятся автоматом после бекапа.

    17 апреля 2013 г. 11:14

Все ответы

  • Привет,

    Может быть более "безболезненно" будет если Вы просто восстановите систему с последнего бэкапа.Либо с помощью Еseutil команд( еseutil /cc после восстановления бэкапа)

    9 апреля 2013 г. 7:54
    Модератор
  • Привет,

    Может быть более "безболезненно" будет если Вы просто восстановите систему с последнего бэкапа.Либо с помощью Еseutil команд( еseutil /cc после восстановления бэкапа)

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

    Самое обидное что файлы логов не перенесли, а стерли так бы я мог попытатся подкинуть их назад и сделать бекап но увы.

    • Изменено wer_wolf 9 апреля 2013 г. 10:38
    9 апреля 2013 г. 10:37
  • День добрый.

    Перенесите базу данных на сервер или рабочую станции и выполните проверку базы данных.

    Eseutil

    Последствия выполнения команды eseutil /p или edbutil /d /r в Exchange


    MCITP. Знание - не уменьшает нашей глупости.

    9 апреля 2013 г. 10:49
    Модератор
  • Перенести это в смысле отключить ее от Exchange в оффлайн и потом сделать eseutil /p

    9 апреля 2013 г. 11:25
  • Перенести это остановить службу и скопировать на другой компьютер. 

    На другом компьютере ее проверить.

    Exchange Database Recovery – Using eseutil commands

    1. Создайте директорию c:\exchangeese (не обязательно эту, но без пробелов, и латиницей)
    2. Скопируйте с сервера Exchange, файлы:  Eseutil.exe, Ese.dll, Jcb.dll, Exosal.dll, Exchmem.dll, ntlsapi.dll папку c:\exchangeese


    MCITP. Знание - не уменьшает нашей глупости.

    9 апреля 2013 г. 11:42
    Модератор
  • Спасибо попробую сегодня

    Сейчас не могу у нас всего 1 база и она почти 500 гиг весит

    • Изменено wer_wolf 9 апреля 2013 г. 12:04
    9 апреля 2013 г. 12:03
  • Поэтому и надо переносить на другой сервер или компьютер, чтобы не положить текущий. 

    MCITP. Знание - не уменьшает нашей глупости.

    9 апреля 2013 г. 12:54
    Модератор
  • После того как откопирую можно сервер запускать в работу пока проверятся будет или нет?

    9 апреля 2013 г. 13:04
  • Да, после копирования запускайте службу.  Вы сможете узнать время простоя и задокументируете порядок устранения ошибок.


    MCITP. Знание - не уменьшает нашей глупости.

    9 апреля 2013 г. 14:14
    Модератор
  • Помогите как решить проблемку

    Вообщем как всегда все проблемы от лени вместо того что бы пояснить начальству что диски сервера переполненны и нужно подождать пока пройдет бекап и почистятся логи напарник где то выкопал статью о том что часть логов можно обсолюдно спокойно стереть и все будет ок что он благополучно и сдела. Когда я добрался до сервера и решил таки пормально его забекапить стала валится вот такая ошибка:

    eseutil (11080) JetDBUtilities - 12636: Файлы журнала с \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy126\Program Files\Microsoft\Exchange Server\V14\Mailbox\Mailbox Database 0851184493\E0000122400.log по \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy126\Program Files\Microsoft\Exchange Server\V14\Mailbox\Mailbox Database 0851184493\E000012249F.log отсутствуют (ошибка -528) и не могут использоваться. Если эти файлы журнала необходимы для восстановления, для успешного завершения восстановления потребуется работоспособная копия этих файлов журнала.

    Для получения дополнительных сведений щелкните следующую ссылку: http://www.microsoft.com/contentredirect.asp.

    Подскажите что теперь делать?

    Из того что нашел в сети рекомендуют включить циклическое ведение журналов перезапустить службу "Банк данных Exchange" и через некоторое время отключить циклическое ведение и опять передернуть службу.

    Насколько этот метод верный или есть еще какотйо вариант?

    У Вас вообще резервное копирование при этом проходит хоть как-то? Т.е. - Вы можете выдернуть из резервной копии файл базы данных ("Mailbox Database 0851184493.edb") и посмотреть командой eseutil /mh заголовок файла. По заголовку будет видно, нужны ли удаленные журналы для восстановления базы данных. Если нет, то на это предупреждение можно не обращать внимания.

    А чтобы предупреждения в таком случае не было, вероятно, стоит размонтировать базу, убедиться, что она находится в состоянии Clean shutdown и убрать логи с номерами меньшими, чем удаленные.

    Предупреждение! Все вышенаписанное предполагает, что у Вас не используется DAG. Потому что репликация логов для пассивной копии - это отдельная история.

    PS Если Вы делаете копию с помощью встроенного Windows Server Backup, то файл базы находится на одном из VHD, создаваемых этой программой, этот VHD можно подмонтировать (лучше - на другом сервере) с помощью Server manager. В противном случае смотрите документацию по своей программе резервного копирования.

    PPS Если файл базы не попадает в резервную копию, то можно проверить файл, не размонтируя базу, создав теневую копию вручную, командой diskshadow и скопировав этот файл куда-нибудь из этой теневой копии.


    Слава России!


    9 апреля 2013 г. 20:28
  • Все спасибо за помощь и советы.

    Откинул  проверил базу сказало что все нормально после чего на рабочем сервере перевел логи в циклическое ведение перезапустил хранилище и вернул назад опять перезапустив после чего логи очистились и вот уже несколько дней бекап проходит штатно и логи чистятся автоматом после бекапа.

    17 апреля 2013 г. 11:14