Blog of Khlebalin Dmitriy

(Записки из мира IT…)

Оффлайн дефрагментация баз данных Exchange 2010.


На выходных «накатили» (я не в плане накатили по стакану), SP3 на нашу «чангу 2010», обновление накатилось не с первого раза, ругнувшись на невозможность что-то удалить из файлов “чанги”. Перезагрузка решила этот вопрос, все обновилось в штатном режиме, но после перезагрузки нас ждал новый сюрпрайс: по какой-то причине служба “Informationstore” отказалась стартовать злобно выдавая ошибку, оказались расхождения времени на сервере Exchangeи в домене (как то странно, до обновления стартовала, после обновления время разошлось-чудеса), в интернете по данной ошибке не много публикаций, эта проблема решается следующим образом:

snap1

Далее рестартануть службу Active Directory Topology service

После этого служба успешно стартанула и наша «чанга» благополучно вернулась к своим обязанностям по пересылке почты.

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

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

Необходимость дефрагментации почтовых баз в Exchange Server 2010 возникает из-за того, что при удалении информации из базы данных, она автоматически не сжимается (остаются пустые страницы), и соответственно размер файла базы не уменьшается. Например, если из почтовой базы размером 20 Гб перенести ящики пользователей, общим размером 5 Гб, то размер файла останется неизменным 20 ГБ. Однако, освободившиеся 5 Гб «свободного» места в дальнейшем будет использоваться новыми элементами. Говоря простым языком: удалил почтовый ящик пользователя, размер стораджа не уменьшился.

Следует четко различать процессы офлайн и онлайн (интерактивной) дефрагментации базы Exchange 2010. Интерактивная дефрагментация в Exchange выполняется постоянно при включенной опции Enable background database maintenance (24 x 7 ESE scanning). Эта процедура выполняется в фоновом режиме включает в себя удаление устаревших элементов в хранилище и оптимизацию расположения страниц, у нас она включена. Основная задача – освободить неиспользуемое пространство за счет сжатия записей до минимально возможного количества страниц с целью сокращения количества операций ввода/вывода. Отмечу, что неиспользуемое пространство не возвращается системе. Офлайн дефрагментация позволяет высвободить это пространство.

Для начала интересно, какую базу лучше всего дефрагментировать, для этого в PowerShell набираем следующую команду:

C:\>Get-MailboxDatabase -Status | ft name,databasesize, availablenewmailboxspace –auto

показывает статистику по всем базам в организации.

C:\>Get-MailboxDatabase -Server mail -Status | ft name,databasesize, availablenewmailboxspace -auto
показывает статистику по всем базам на сервере mail (в данном случае mailэто мой рабочий почтовик)

В моем случае, это выглядит примерно так:

snap2

Актуально дефрагментировать базу “gold1”, но время уже не позволяло, поэтому решил остановиться на “Head”

Подготовка к дефрагментации Exchange 2010

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

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

Поэтому, если вы собираетесь выполнить дефрагментацию почтовой Exchange, необходимо иметь свободное место, равному не менее 110% от текущего размера базы (без учета пустых страниц).

В моем  текущем случае, размер диска позволяет  не копировать tmp базу никуда, если размер диска не позволяет, то необходима команда следующего вида:

D:\Database\head>eseutil /d head.edb /t\\tmp_srv\exch\temphead.edb

Ну или что-то в этом роде, на какой-нибудь свободный сетевой ресурс.

Мой вариант оказался таким:

snap3

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

mount-Database head

Снова открываем  PowerShell набираем:

Get-MailboxDatabase -Status | ft name,databasesize,availablenewmailboxspace -auto

snap4

Видим что наша база похудела, при том не плохо похудела.

Аналогично проделываем операцию с оставшимися базами и получаем свободное место на дисках.

На текущий момент базы «чанги» заняли 2/3 размера виртуального диска, так что тут постепенно пора подумать о грядущем:

-Или расширить сторадж средствами «вари» в существующем VMDKразделе

-Или подмонтировать новый VMDK и перенести часть баз «чанги» туда, но это если есть место на дисках в корзине.

Но это уже совершенно другая история…

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

 

Реклама

29.04.2014 - Posted by | ms exchange 2010

Sorry, the comment form is closed at this time.

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