Как можно отслеживать эффективность фоновых задач обслуживания? Перемещение логов в другое место.

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

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

• Создать новую базу данных, перенести вся ящики в нее и удалить старую базу
• Выполнить офлайн дефрагментацию текущей базы

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

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

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

Определяем размер свободного места в базе Exchange 2010

Чтобы в Exchange 2010 узнать текущий размер базы данных и количество свободного места в ней (те самые неиспользуемые страницы), в Exchange Management Shell выполните следующую команду:

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

Name DatabaseSize AvailableNewMailboxSpace—- ———— ————————

WI-DB-01 17.26 GB (18,604,766,720 bytes) 8.544 GB (9,247,766,016 bytes)

В данном примере видно, что текущий размер базы WI-DB-01 17 Гб, причем свободного места в ней аж 8.5 Гб. И если вы хотите высвободить это место, размер файла почтовой базы можно уменьшить, выполнив дефрагментацию утилитой ESEUTIL.

ПРИМЕЧАНИЕ. Если ваш сервер входит в в группу DAG не используйте данную инструкицю !

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

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

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

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

В моем случае это означает, что нам необходимо иметь как минимум 9,6 Гб свободного места на диске:

17.26 – 8.54 = 8.72

8.72 x 1.1 = 9.6

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

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

Использование ESEUtil для дефрагментации базы Exchange

Откройте командную строку Exchange Management Shell и перейдите в каталог с файлом почтовой базы:

Cd D:\Data\WI-DB-01

Размонтируем базу.

Dismount-Database WI-DB-01

Запускаем дефрагментацию с помощью утилиты ESEUtil.

D:\Data\WI-DB-01>eseutil /d WI-DB-01.edb /t\\tmp_srv\exch\temp.edb

Extensible Storage Engine Utilities for Microsoft(R) Exchange Server

Copyright (C) Microsoft Corporation. All Rights Reserved.

Initiating DEFRAGMENTATION mode…

Database: WI-DB-01.edb

Defragmentation Status (% complete)

……………………………………………

Moving ‘\\ tmp_srv\exch\temp.edb’ to ‘WI-DB-01.edb’…

File Copy Status (% complete)

0 10 20 30 40 50 60 70 80 90 100

|—-|—-|—-|—-|—-|—-|—-|—-|—-|—-|

……………………………………………

It is recommended that you immediately perform a full backup

of this database. If you restore a backup made before the

defragmentation, the database will be rolled back to the state

it was in at the time of that backup.

Operation completed successfully in 2798.218 seconds.

Монтируем базу:

Mount-Database WI-DB-01

Убедимся, что ее размер уменьшился:

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

Name DatabaseSize AvailableNewMailboxSpace

—- ———— ————————

WI-DB-01 8.328 GB (8,942,190,592 bytes) 5.219 MB (5,472,256 bytes)

WI-DB-02 14.63 GB (15,785,670,144 bytes) 4.696 GB (4,968,761,856 bytes)

WI-DB -Archive-01 658.1 MB (689,542,784 bytes) 234.6 MB (241,164,544 bytes)

(Короткие заметки)

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

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

Если такой процесс не налажен, то можно опираться на некоторые эвристические утверждения (спорные, но полезные для начала).

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

2. Нет смысла перемещать почтовые ящики, которые существуют относительно долго (созданы давно) и сохраняют небольшой размер или сохраняют стабильный размер.

Для перемещения почтового ящика пользователя используется GUI или командлет New-MoveRequest

ExchangeServer 2010 позволяет перемещать почтовый ящик в другую базу без прерывания работы пользователя. http://blogs.technet.com/b/exchange/archive/2011/01/24/3411868.aspx

Число одновременных потоков копирования ограничивается. Это защищает сервер (хранилище) от перегрузки. Копирование может занять достаточно много времени.

После перемещения почтовый ящик в исходной базе помечается как SoftDeleted. (начиная с SP 1 http://technet.microsoft.com/en-us/library/dd298174.aspx )

Get-MailboxStatistics -Database «Mailbox Database 01» | where { $_ . DisconnectReason -eq «SoftDeleted» }

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

ServerName	Name	DatabaseSize	AvailableNewMailboxSpace
———-	—-	————	————————
MB2	Mailbox Database 01	101.4 GB (108,859,031,552 …	5.7 MB (5 , 976 , 883 bytes)
MB2	Mailbox Database 02	75.26 GB (80,807,526,400 b…	2.5 MB (2 , 621 , 440 bytes)
MB1	Mailbox Database 03	53.88 GB (57,856,294,912 b…	12.28 MB (12,877,824 bytes)
MB1	Mailbox Database 04	26.88 GB (28,865,265,664 b…	87.63 MB (91,881,472 bytes)

После завершения переноса нужно проверить успешность завершения процесса и удалить запросы на перемещение через GUIили

Get-MoveRequest -MoveStatus Completed | Remove-MoveRequest -Confirm: $false

Нужно удалить SoftDeletedпочтовые ящики:

$b = Get-MailboxStatistics -Database «RUMS Mailbox Database 01» | where { $_ . DisconnectReason -eq «SoftDeleted» }

$b | % { Remove-StoreMailbox -Confirm: $False -Database $_ . database -Identity $_ . mailboxguid -MailboxState «SoftDeleted» }

После этого в исходной почтовой базе появится свободное место:

Get-MailboxDatabase -Status | select ServerName , Name , DatabaseSize , AvailableNewMailboxSpace

ServerName	Name	DatabaseSize	AvailableNewMailboxSpace
———-	—-	————	————————
MB2	Mailbox Database 01	101.4 GB (108,859,031,552 …	55.97 GB (60,094,939,136 b…
MB2	Mailbox Database 02	75.26 GB (80,807,526,400 b…	28.5 GB (30,605,312,000 by…
MB1	Mailbox Database 03	53.88 GB (57,856,294,912 b…	12.28 MB (12,877,824 bytes)
MB1	Mailbox Database 04	26.88 GB (28,865,265,664 b…	87.63 MB (91,881,472 bytes)

Затем базу можно упаковать для уменьшения ее размера.

Упаковка базы может быть выполнена по двум сценариям.

Первый – традиционный для одиночной базы. База размонтируется и упаковывается утилитой eseutil /d. Процесс требует наличия свободного места +10%*<размер исходной базы>. На все время работ сервис

Второй подходит для DAG. Создается новая база на новых хранилищах. Почтовые ящики копируются в новую базу. Этот способ работает и для одиночной базы. Накладные расходы на свободное место выше, чем в первом способе: новые хранилища надо создать для всех копий в DAG. (Стратегия может быть разной: для ускорения копирования можно создать одну дополнительную копию для новой базы, а после окончания процесса переноса почтовых ящиков, добавить остальные копии на освободившиеся от исходной базы хранилища.)

Если свободных хранилищ у вас нет, то в случае DAG, вам придется удалить все дополнительные копии базы, размонтировать ее, упаковать, смонтировать и снова добавить дополнительные копии – очевидно, что это может занять намного больше времени. Поэтому рекомендуется базы делать не более 100Гб, а в случае DAGиметь свободное пространство для маневра.

При внедрении Exchange возникает неприятная ситуация – мы вроде бы все требования по месту для Exchange выполнили, но оно неумолимо уменьшается… начинаем разбираться и понимаем что всевозможные логи растут быстрее чем мы предполагали, так как же с ними бороться? Далее описаны способы по усечению\перемещению различных логов, в общем все то, что поможет нам решить проблему. Отдельно замечу, что вся информация есть в технической библиотеке technet 🙂 и здесь она всего лишь подобрана для определенной задачи: напомнить способы решения проблем с нехваткой места по причине разрастания логов.

Transaction logs

Журнал транзакций наиважнейший элемент Exchange. Приведем пример: при отправке сообщения транзакция сначала записывается в журнал. Пока транзакция не передалась в базу данных Exchange, эти данные существуют только в системной памяти и журналах транзакций. В случае аварии вы теряете содержимое памяти, и все, что у вас остается, это записи в журнале транзакций. Эти журналы важны для восстановления поврежденной базы. То же самое касается и других транзакций: полученных сообщений, удаленных элементов и сообщений, перемещенных в другие папки. Соответственно данные логи растут очень быстро, как же их уменьшить?

1. Резервное копирование

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

Отличная статья по настройке резервного копирования с использованием Windows Server Backup

2. Включение Circular Logging

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

С помощью EAC Circular Logging включается так:

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

3. Перемещение Transaction logs

Ну и в конце концов мы можем переместить логи вместе с базой в другое место\другой диск.

Для этого есть прекрасный командлет Move-DatabasePath . Приведем пример переноса базы данных MDB01 и журналов транзакций на диск M в соответствующие директории:

Move-Databasepath “MDB01” –EdbFilepath “M:\DB\MDB01\database\mdb01.edb” –LogFolderpath “M:\DB\MDB01\logs\”

Queue Database

Это конечно не логи, но если вам необходимо освободить место то перемещение данной базы может вам помочь. Queue Database — это временное хранилище сообщений, ожидающих следующую стадию обработки. Каждая очередь представляет собой логический набор сообщений, которые обрабатываются сервером транспорта в определенном порядке. Все очереди хранятся в одной базе данных ESE. Очереди размещаются только на серверах почтовых ящиков или на пограничных транспортных серверах. Местоположение базы данных очереди и ее журналов транзакций контролируется ключами в XML-файле конфигурации приложения %ExchangeInstallPath%Bin\EdgeTransport.exe.config.

Все что мы можем сделать с нею, это переместить ее в другое место. Достаточно исчерпывающая информация о перемещении находится в библиотеке technet в статье Change the Location of the Queue Database

Transport Logs

Журналы транспорта предоставляют сведения о происходящем в транспортном конвейере. Достаточно исчерпывающая информация о отключении\включении логирования и их перемещении находится в библиотеке technet в статье Transport Logs .

В Microsoft Exchange Server 2013 доступны следующие журналы транспорта:

• Agent logs
• Connectivity logs
• Message tracking and delivery reports
• Pipeline tracing
• Protocol logs
• Routing table logs

Protocol logs через EAC: servers\servers\выбрать сервер\transport logs\protocol log

Например изменить путь хранения Message Tracking через EAC: servers\servers\выбрать сервер\transport logs\message tracking log.

Отдельно замечу что переместить можно только в локальную папку. Проблему с размещением на сетевом ресурсе можно обойти использовав команду mklink и создав ссылку на сетевой ресурс. Например создайте ссылку mklink /d «D:\HubReceiveSMTPLog» \\Server\HubReceiveSMTPLog , теперь вы можете используя командлет Set-TransportService и параметр –ReceiveProtocolLogPath «D:\HubReceiveSMTPLog» хранить ReceiveSMTP логи на сетевом ресурсе. Данный способ подходит и для других логов.

IIS log files

В логе IIS у вас будет информация например о подключении вашего ipad с помощью протокола activesync. Размер IIS логов, если за ним не уследить может быть очень большим. Как же их автоматом удалить или переместить на другой диск?

1.Автоматическое удаление логов

Запускайте ежедневно через scheduler следующий скрипт ps1 (измените путь хранения логов если нужно) и все ваши логи IIS старше 30 дней будут удаляться не требуя вашего внимания.

set-location c:\inetpub\logs\LogFiles\W3SVC1\

foreach ($File in get-childitem) {

if ($File.LastWriteTime -lt (Get-Date).AddDays(-30)) {

del $File

Запускать скрипт ps1 через scheduler вы можете следующим образом:

• Создайте задачу в scheduler
• Создайте action: start a program
• В поле program/script: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
• В поле add arguments(optional): -command “pathTOscript\name.ps1”

2.Перемещение логов в другое место

• Откройте IIS Manager from Administrative Tools и выберете Default Web Site.

• Откройте Logging (щелкните два раза на иконке Logging)
• Измените место хранения логов

• Сохраните изменения. Следующий файл лога запишется в новое место хранения
• Тоже самое можно сделать при мощи powershell:

Import-Module WebAdministration

Set-ItemProperty ‘IIS:\Sites\Default Web Site’ -name logfile.directory «D:\IISLogs»

Папка Logging

И наконец папка Logging которая по умолчанию находится в ‘C:\Program Files\Microsoft\Exchange Server\V15\Logging. Здесь хранится множество логов различных служб, и может занимать достаточно большое количество места. Особенно выделяются по объему diagnostic and performance log files которые находятся в папке ‘C:\Program Files\Microsoft\Exchange Server\V15\Logging\Diagnostics

На просторах интернета было найдено простое решение этого вопроса, запускайте ежедневно через scheduler и все логи из этих папок старше 14 дней перестанут вас беспокоить 🙂

gci ‘C:\Program Files\Microsoft\Exchange Server\V15\Logging’,’C:\inetpub\logs’ -Directory | gci -Include ‘*.log’,’*.blg’ -Recurse | ? LastWriteTime -lt (Get-Date).AddDays(-14) | Remove-Item

P.S. Я лично предпочитаю резать только diagnostics:

gci ‘C:\Program Files\Microsoft\Exchange Server\V15\Logging\Diagnostics’ -Directory | gci -Include ‘*.log’,’*.blg’ -Recurse | ? LastWriteTime -lt (Get-Date).AddDays(-2) | Remove-Item

Microsoft Exchange Server, начиная с версии 2007, хранит сообщения очередей в базе данных формата ESE - Mail.que , расположенной в папке . После нескольких лет эксплуатации база данных транспортных очередей может вырасти до огромных размеров. В моем случае, примерно за 4 года эксплуатации Exchange Server 2010 она выросла до 900МБ, не много конечно, но в Интернете встречаются случаи, когда ее размер доходил до 80-100 ГБ. После создания базы заново ее размер будет 8Мб. Большой объем базы может сказаться на производительности системы и занимать лишнее пространство на диске. Я же обратил на это внимание, когда один из моих транспортных серверов начал жутко «тормозить» из-за работы антивируса. После пересоздания базы данных очередей, проблема исчезла.

Хоть Exchange и совершает автоматическую онлайн дефрагментации этой базы, но размер ее никогда не уменьшится. К примеру, если во время сбоя, ваш транспортный сервер принял и хранил в очереди 10Гб почты, то потом, когда почта уйдет, размер файла хранения останется 10Гб. Поэтому моя рекомендация, если база выросла больше 200Мб, то ее нужно создать заново . Делается это следующим образом.

1. Необходимо поставить сервис Microsoft Exchange Transport на паузу. Сервис перестанет принимать сообщения, но «разделается» со всеми сообщениями в очередях.

2. Запустите коммандлет Get-Queue и убедитесь, что в очередях не осталось сообщений.

3. Остановите сервис Microsoft Exchange Transport .

4. Откройте папку %ExchangeInstallPath%TransportRoles\data\Queue и убедитесь, что файл mail.que находится в нем.

5. После этого этого переименуйте каталог %ExchangeInstallPath%TransportRoles\data\Queue в %ExchangeInstallPath%TransportRoles\data\Queue1 .

6. Запустите сервис Microsoft Exchange Transport , папка Queue , база mail.que и лог файлы будут созданы. Размер заново созданной базы будет около 8,2 Мб.

7. Удостоверьтесь, что служба транспорта нормально работает и можно удалять папку Queue1 .

Информация о расположении файла базы данных находятся в файле %ExchangeInstallPath%Bin\EdgeTransport.exe.config , поэтому, если вы хотите переместить базу, то вместо шага 5 измените путь к новому файлу и выполните шаг 6.

Связанные записи:

Понравилась публикация? Хотите получать новые прямо в свой почтовый ящик? Нет ничего проще, подпишитесь на рассылку прямо сейчас.

При дефрагментации данные, хранящиеся на жестких дисках компьютера, перемещаются таким образом, чтобы файлы были разбиты на меньшее число частей. Дефрагментация помогает ускорить доступ к данным и их получение. Дефрагментация данных на жестких дисках повышает их производительность и эффективность работы серверов организации. В Exchange 2007/2010 дефрагментация (точнее оффлайн дефрагментация) позволяет освободить место на диске. Спросите каким образом? Все очень просто, при удалении информации из базы данных, она автоматически не сжимается (остаются пустые области), и соответственно размер файла базы не уменьшается.

Например, если из почтовой базы размером 100 Гб удалить/ переместить ящики пользователей, общим размером 5 Гб, то размер файла останется неизменным 100 ГБ. Однако, освободившиеся 5 Гб «свободного» места в дальнейшем будет использоваться новыми элементами.
Тем не менее если вам необходимо уменьшить размер файла почтовой базы в Exchange 2010, удалив незанятые страницы, вы можете воспользоваться одной из следующих методик:
Создать новую базу данных, перенести вся ящики в нее и удалить старую базу
Выполнить оффлайн дефрагментацию текущей базы
Каждый из этих методов имеет свои плюсы и минусы. Первый хорош тем, что процедура менее рискованная, но и менее удобна, т.к. если у вас в базе 500 эл. ящиков, то в ручную переносить их будет очень тяжко. Второй метод не удобен тем, что требует не мало ресурсов (об этом пойдет речь дальше) и в случае сбоев, не известно к чему это может привести, но зато с большой базой справиться относительно быстро. Выбор за вами. Первый способ описывать, я думаю, не стоит, все интуитивно понятно, остановлюсь на описании второго метода.
Для того что бы воспользоваться оффлайн дефрагментацие используется команда Eseutil. В режиме Eseutil составной частью процесса дефрагментации является создание новой базы данных, содержащей все данные, входившие в исходную базу данных, за исключением того, что пустые страницы отбрасываются и индексы перестраиваются. После завершения дефрагментации исходная база данных удаляется или сохраняется в указанном пользователем месте, а новая версия получает такое же имя, какое было у исходной базы данных.
Перед тем как начать уменьшение базы Exchange2007/ 2010 с помощью команды Eseutil, предлагаю рассмотреть команды Exchange Management Console которые могут пригодится для понимания ситуации с базами и электронными ящиками.

C помощью следующего командлета мы можем посмотреть доступные почтовые базы организации:
Get-MailboxDatabase

Теперь посмотрим какие почтовые ящики в конкретной базе (в данном примере Mailbox Database 1)
Get-MailboxDatabase "Mailbox Database 1" | Get-Mailbox

Для того что бы импортировать статистику в CSV файл в конце команды дописываем
| Export-CSV C:\mailboxes.csv
В корне диска С создается файл mailboxes.csv

Теперь перейдем к командам для оффлайн форматирования, первое что необходимо сделать перед уменьшением базы- отмонтировать ее, для этого можно запустить команду Dismount-Database ИМЯ БАЗЫ , либо запустить Exchange Management Console, зайти "Server Configuration- Mailbox " с правой стороны будут все Database выбираем необходимый нам кликаем на нем правой кнопкой мыши и выбираем Dismount Database .

ESEUTIL /d "G:\Exchange server\OTS\ots.edb"
Дефрагментированный временный файл будет создан в корне диска С, может занять до 110% первоначальной базы- это необходимо учесть.


ESEUTIL /d "G:\Exchange server\ROZN\rozn.edb" /t"G:\temp\tempdfg.edb"

Дефрагментированный временный файл будет создан на диске G в папке temp, может занять до 110% первоначальной базы, (предварительно необходимо создать файл tempdfg.edb ) затем он заменит собой существующую базу (в данном примере rozn.edb)

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