Автоматическая дефрагментация баз Exchange 2007 - практика

Редко, но метко бывает нужно провести дефрагментацию большого количества больших баз Exchange 2007, для этих целей решил написать скрипт для Exchange Management Shell, поскольку ночью спать сильно хочется, а днем, даже в выходные дни, куча пользователей (из более чем 1200) может сидеть в базах и мешать их дефрагментировать своими недовольными звонками начальству и в тех поддержку ))).
Вообщем, использую скрипт:

####################################
#Shiryaev.DE@gmail.com
#скрипт выполняет автоматическую дефрагментацию баз для всех групп хранения CCR кластера Exchange 2007
########################
$Array_DBs = Get-MailboxDatabase | select-object name, servername, storagegroup, EdbFilePath | Sort-Object -Property name

"Count of Databases=" + ([string] $Array_DBs.Length)

for($i=0;$i -le $Array_DBs.Length-1;$i++)
{
$DB_FULL_NAME = ([string] $Array_DBs[$i].server)+"\"+([string] $Array_DBs[$i].Name)
$DB_NAME = $Array_DBs[$i].name
$DB_FILE_NAME = $Array_DBs[$i].EdbFilePath
$SG_NAME = $Array_DBs[$i].storagegroup

If ( ([string] $Array_DBs[$i].servername) -eq "MailCluster-01")
{
"["+$i+"]---Suspend-StorageGroupCopy <<" + $SG_NAME + ">>"
Suspend-StorageGroupCopy -Identity $SG_NAME -SuspendComment "Suspending CCR to reseed." -Confirm:$false
Start-sleep -s 6

"---Dismount-Database <<" + $DB_NAME + ">>"
Dismount-Database $DB_NAME -Confirm:$false
Start-sleep -s 6
"---ESEUTIL.EXE /D <<" + $DB_NAME + ">>"
ESEUTIL.EXE /d $DB_FILE_NAME /tf:\tempdb.edb
Start-sleep -s 6
"---Mount-Database <<" + $DB_NAME + ">>"
Mount-Database $DB_NAME -Confirm:$false
Start-sleep -s 6
"---Resume-StorageGroupCopy <<" + $SG_NAME + ">>"
Resume-StorageGroupCopy -Identity $SG_NAME
}
else
{
"[" + ($i+1) + "]" + "Storage Group name" + $SG_NAME + " is NOT Clustered nothing to do with DB <<" + $DB_NAME + ">>."
}
}
Немного статистики:
на сервере HP DL580G5 с 32Gb RAM и размещением всех баз на RAID5, состоящем из 4х FC15k дисков дефрагментация 11-ти баз, которая ни разу не проводилась для 80% объема от 323Gb, составляет 30000seconds, или 500minutes, или 8 hours 20 minutes, что весьма приемлемо провести за одну ночь - запустив дефрагментацию перед уходом домой вечером, например, в пятницу.
моя статистика по базам их размещению, объему, времени прохождения бэкапа и коэффициент от объема ко времени в минутах.
F:\Ex2k7_00__SG_Unlim --- 45G --- 2294s --- k = 1,17
F:\Ex2k7_01stSG_Public_Folders --- 3,6G
F:\Ex2k7_02ndSG_500Limit --- 2G --- 253s --- k = 0,71
F:\Ex2k7_03thSG_300Limit --- 45G --- 2047s --- k = 1,31
F:\Ex2k7_04thDisabled_SG --- 10G --- 461s --- k = 1,30
F:\Ex2k7_05thSG_300Limit --- 40G --- 4022s --- k = 0,59
F:\Ex2k7_11thSG_1000Limit --- 1G --- 487s --- k = 0,12
G:\Ex2k7_06thSG_300Limit --- 88G --- 11070s --- k = 0,47
G:\Ex2k7_07thSG_300Limit --- 48G --- 3334s --- k = 0,86
G:\Ex2k7_08thSG_300Limit --- 49G --- 3898s --- k = 0,75
G:\Ex2k7_09thSG_300Limit --- 16G --- 1070s --- k = 0,89
G:\Ex2k7_10thSG_300Limit --- 16G --- 1064s --- k = 0,90
Фактически k - это коэффициент скорости дефрагментации. Как видно сам скрипт не оптимален, поскольку расположение временного файла статично, а не вычисляется исходя из расположения файла базы данных, так если временный файл на том же диске F, то коэффициент выше, для баз, расположенных на диске G коэффициент падает.

То что соотношение размеров баз не оптимизировано - это всё в будущем ;-)