Blog of Khlebalin Dmitriy

(Дорогу осилит идущий…)

И снова eseutil Exchange 2010.


На минувших праздниках, появилось время без спешки, суеты в тишине «потюнить чангу». К сожалению, в рабочее время административные обязанности всецело поглотили меня.

Недавно накатили на «чангу» SP3, в этот раз было решено поставить Rollup, актуальность для вашей «чанги» можно посмотреть здесь:

http://social.technet.microsoft.com/wiki/contents/articles/240.exchange-server-and-update-rollups-build-numbers.aspx

в моем случае это Rollup 5 for Exchange 2010 SP3, никаких проблем установка не вызвала.

Параллельно была необходимость доделать Offline дефрагментацию оставшихся 4-х баз.

Все прошло гладко, за исключением одной, самой большой базы, при ее дефрагментации, место на диске c: стало катастрофически заканчиваться и дефрагментация несколько раз вылетела с ошибкой. Здесь стоит отметить, что после каждой неудачной дефрагментации, на диске с: остается некий скрытый файл tmpxxx.edb, который съедает место на диске. Не забываем его удалять. По данной проблеме предприняли определенные меры, в следующий выходной снова вернемся к данному вопросу. Ибо 24 гига, которые освободятся после дефрагментации никак не лишние…

Здесь же, давно хотел вернуться к нашей старой, и до сего момента так и не решенной проблеме циклических логов:

Как видим ведение циклических логово выключено

snap1

Но логи как не складывались, так и не складываются, точней складываются за два дня (место на иске хоть отбавляй)

snap2

Эта тема некоторое время обсуждалась нами здесь:

http://social.technet.microsoft.com/Forums/ru-RU/98aaa9f4-098d-4210-9b62-76f76d81277b/-exchange-2010?forum=exchange2010ru#9403493d-cee0-4026-b1ad-55637f93fa70

но внятного ответ, так и не получили.

Коллеги по цеху близкие к «чанге» советовали пересоздать новые базы рядом и смувить все ящики туда, вероятно это могло бы исправить проблему, но у нас Standart лицензия и 5 баз уже подмонтировано, а корпоративная политика не предполагает использование ломаных или пиратских версий, поэтому этот вариант в данном случае исключен.

Попробовал пойти вот таким путем: обычно данные методы используются при восстановлении баз, но я решил попробовать это в данном случае

  • не правильное завершение работы сервера
  • что то случилось с логами (это как раз наш случай).

Для начала надо посмотреть состояние базы данных.

Eseutil / MH «Путь к базе данных»

snap3

После, выведется список разных параметров, нас интересует строка State:

Если в строке State указано что база Clean shutdown, то переместите все файлы из папки журналов транзакций (на всякий случай не удаляйте, скопируйте лучше в другую папку) и подключите базу. Если не помогло, перезагрузите сервер и попробуйте подключить базу.

В нашем случае это как раз Clean shutdown, то есть со всеми базами все ГУД, переместил старые логи в другие папки подмонтировал базы, но чуда не случилось, логи по прежнему складываются за два дня. Продолжим искать варианты решения проблемы.

Здесь не мешает рассмотреть и более тяжелые варианты:

Если в строке State: указано что база Dirty Shutdown.

Надо убедиться что с логами всё в порядке командой  Eseutil / ML «Путь лог-файлов \ префикс журнала» (если баз несколько, то префиксы будут e00, e01, e02, e03)

snap4

Если все журналы логов на месте (как показано ниже) переходим к пункту 1. Если не всё в порядке и есть ошибки, переходим к пункту 2.

1. Восстанавливаем базу с помощью мягкого восстановления — Eseutil / R

Eseutil / r <префикс журнала(e00 и.т.д)> / l «Путь лог-файлов» / D «Путь к базе данных»

snap5

После того как в консоле появится сообщение что Operation complete successfully, подключаем базу.

Если не помогло, перезагрузите сервер и подключаем базу.

2.Если в строке с логами не всё в порядке то мягкое восстановление не поможет и придётся делать жесткое восстановление Eseutil / P (при жестком восстановлении все логи транзакций будут удалены). Eseutil / P «Путь к базе данных»

snap6

После того как появится сообщение что Operation complete successfully, подключаем базу.

Если не помогло, перезагрузите сервер и подключаем базу.

Здесь еще интересно для общего кругозора:

  • ESEUTIL /D ‘ используется для автономной дефрагментации базы данных
  • ESEUTIL /R ‘ используется для восстановления базы данных
  • ESEUTIL /g ‘ выполняет проверку базы данных на целостность
  • ESEUTIL /k ‘ выполняет проверку контрольной суммы базы данных
  • ESEUTIL /p ‘ исправляет базу данных, когда она повреждена (и не подлежит восстановлению)
  • ESEUTIL /m ‘ может выгружать информацию заголовка базы данных и лог файлов
  • ESEUTIL /y ‘ может копировать большие файлы типа Mailbox Database
  • ESEUTIL /c ‘ используется для ‘жесткого восстановления (hard recover)’ базы данных во время резервного копирования в режиме онлайн

и вот эта статья:

http://technet.microsoft.com/ru-ru/library/bb331958(v=exchg.141).aspx

Всем хорошей работы !!!

P.S. Сегодня возобновили обсуждение на Технете по поводу того, куда деваются наши логи «чанги», добрые люди помогли понять что-куда?

Выполняем команду в PowerShell: Get-MailboxDatabase -Status | ft name,last* -auto

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

snap

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

Озадачились: как Veeam может знать о логах чанги и затирать их, если он целиком бэкапит виртуалку? (да, Veeam имеет встроенную функцию отдельного бэкапа баз чанги, но это не наш случай).

Оказывается, Veeam знает о логах и реально затирает их, настраивается это здесь:

snap1

Как видно стоит Truncate logs, соответственно логи затираются. Если необходимо, чтоб оставались, выбираем Do not truncate logs.

Вот собственно и ответ на наш вопрос.

Век живи, век учись. Всем спасибо за обсуждение вопроса и участие!!!

 

Реклама

13.05.2014 - Posted by | ms exchange 2010

Sorry, the comment form is closed at this time.

%d такие блоггеры, как: