Ранее этим утром store.exe так или иначе запутался, что потребовало перезапуска нашего сервера Exchange. Он вернулся в сеть без ошибок или проблем, все журналы транзакций были успешно воспроизведены, и все хранилища смонтированы как обычно. Для меня это был просто один из тех случайных сбоев; однако наш консультант подозревает, что это было вызвано повреждением в одном из хранилищ. Возможно, он прав, поскольку у него гораздо больше опыта, чем у меня, но это не суть.
Чтобы исправить предполагаемые ошибки, он планирует запустить дефрагментацию ESEUTIL (через PerfectDisk), которая, по его словам, также исправит любые имеющиеся ошибки.
Насколько я понимаю, дефрагментация, проверка и восстановление — это три отдельных действия, и дефрагментация не подразумевает никакой проверки целостности.Это правильно? Есть ли какие-либо опасности в запуске прямой дефрагментации базы данных, которая может быть повреждена?
Редактировать:
Вот первая ошибка в журнале событий, которая указала на начало проблем, которые у нас были. Кто-нибудь знает, что это может означать?
Event Type: Error
Event Source: Microsoft Exchange Server
Event Category: None
Event ID: 1000
Date: 11/23/2011
Time: 8:15:47 AM
User: N/A
Computer: SERVER
Description:
Faulting application exsp.dll, version 6.5.7638.1, stamp 430e735b, faulting module kernel32.dll, version 5.2.3790.4480, stamp 49c51f0a, debug? 0, fault address 0x0000bef7.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Data:
0000: 41 00 70 00 70 00 6c 00 A.p.p.l.
0008: 69 00 63 00 61 00 74 00 i.c.a.t.
0010: 69 00 6f 00 6e 00 20 00 i.o.n. .
0018: 46 00 61 00 69 00 6c 00 F.a.i.l.
0020: 75 00 72 00 65 00 20 00 u.r.e. .
0028: 20 00 65 00 78 00 73 00 .e.x.s.
0030: 70 00 2e 00 64 00 6c 00 p...d.l.
0038: 6c 00 20 00 36 00 2e 00 l. .6...
0040: 35 00 2e 00 37 00 36 00 5...7.6.
0048: 33 00 38 00 2e 00 31 00 3.8...1.
0050: 20 00 34 00 33 00 30 00 .4.3.0.
0058: 65 00 37 00 33 00 35 00 e.7.3.5.
0060: 62 00 20 00 69 00 6e 00 b. .i.n.
0068: 20 00 6b 00 65 00 72 00 .k.e.r.
0070: 6e 00 65 00 6c 00 33 00 n.e.l.3.
0078: 32 00 2e 00 64 00 6c 00 2...d.l.
0080: 6c 00 20 00 35 00 2e 00 l. .5...
0088: 32 00 2e 00 33 00 37 00 2...3.7.
0090: 39 00 30 00 2e 00 34 00 9.0...4.
0098: 34 00 38 00 30 00 20 00 4.8.0. .
00a0: 34 00 39 00 63 00 35 00 4.9.c.5.
00a8: 31 00 66 00 30 00 61 00 1.f.0.a.
00b0: 20 00 66 00 44 00 65 00 .f.D.e.
00b8: 62 00 75 00 67 00 20 00 b.u.g. .
00c0: 30 00 20 00 61 00 74 00 0. .a.t.
00c8: 20 00 6f 00 66 00 66 00 .o.f.f.
00d0: 73 00 65 00 74 00 20 00 s.e.t. .
00d8: 30 00 30 00 30 00 30 00 0.0.0.0.
00e0: 62 00 65 00 66 00 37 00 b.e.f.7.
00e8: 0d 00 0a 00 ....
решение1
Офлайн-дефрагментация с использованием eseutilзавершится неудачей, если она обнаружит повреждение на уровне страниц в базе данных, потому что. Вам придется использовать опцию /p(rePair), чтобы отбросить поврежденные страницы.
Повреждение данных на логическом уровне (подумайте о повреждении «данных» в базе данных, а не «структуры» базы данных) не может быть исправлено с помощью eseutil. isintegИнструмент может находить логические несоответствия в базе данных в версиях Exchange до 2007. В Exchange 2010 isintegбыл заменен на new-MailboxRepairRequestкомандлет (Более подробную информацию можно найти в блоге команды Exchange.).
Сказав все это, я обеспокоен советом вашего консультанта. Видите ли вы события в журнале событий приложений от ESE или служб, связанных с Exchange, которые указывают на какое-либо повреждение базы данных? В целом, Exchange не «случайно падает», и проблема с драйвером оборудования или самим оборудованием кажется более вероятной причиной, чем проблема с Exchange. Кроме того, поскольку журналы воспроизводились без проблем, я нахожу маловероятным, что вы берете повреждение на уровне страницы.
Наконец, если вы берете повреждение на уровне страницы, простое удаление этого повреждения не является решением. Вам нужно найти основную причину (неисправное оборудование и т. д.), которая вызывает повреждение, и устранить ее. Делать что-либо еще — значит просто подвергать себя постоянному риску.
Оффлайн-дефрагментация сама по себе не является серьезным риском. Вам следует немедленно сделать полную резервную копию после завершения оффлайн-дефрагментации, поскольку все предыдущие инкрементные и дифференциальные резервные копии не могут быть восстановлены (потому что новая база данных — это просто новая база данных). Очевидно, что ваш сервер также будет недоступен для пользователей в течение периода дефрагментации.
Я бы подробно изучил то, что произошло сегодня утром, и пришел бы к выводу о первопричине (или, по крайней мере, к весьма вероятной гипотезе), прежде чем начал бы тратить деньги на «исправление» этого.
Недавно у меня был случай, когда машина Exchange Server 2003 не делала снимки VSS и сообщала о различных ошибках JET во время попыток резервного копирования. Я решил развернуть новую установку Exchange на другой машине, переместить все почтовые ящики пользователей на новую машину, затем удалить проблемную базу данных на исходном сервере и разрешить создание новой. После того, как мы провели стресс-тестирование и убедились, что исходный сервер работает нормально, мы переместили все почтовые ящики обратно. Я бы предпочел эту стратегию в ситуации, которую вы описываете (если бы у меня было достаточно сообщений журнала событий, которые указывали на реальное «повреждение» в базе данных почтовых ящиков исходного компьютера Exchange Server).
Редактировать:
Запись, которую вы разместили выше, является ошибкой в поставщике Exchange для Microsoft Search (который создает полнотекстовые индексы баз данных Exchange). Мне было бы интересно узнать больше о том, что произошло потом, а также о любых событиях, непосредственно предшествовавших этому, из журнала системных событий. У вас было состояние нехватки дискового пространства на каком-либо из томов сервера?
решение2
Дефрагментация ESEUTIL не предназначена специально для обширного восстановления базы данных Exchange. Функция дефрагментации заключается в освобождении свободного места в базе данных и оптимизации производительности базы данных путем создания нового сжатого файла базы данных.
Пока вы запускаете дефрагментацию, она также может выполнять определенные исправления в базе данных, если она находит какие-либо несоответствия или проблемы. Это часть общего процесса дефрагментации и может исправить незначительные проблемы.
Если ваша база данных Exchange Server повреждена, рекомендуется сначала выполнить команду ESEUTIL /mh, чтобы проверить полное состояние вашей базы данных. Если вы обнаружили, база данных находится в грязном состоянии. Позже вы можете использовать команды ESEUTIL /P или ESEUTIL /R в зависимости от повреждения базы данных. Убедитесь, что вы сделали резервную копию своей базы данных, прежде чем пытаться выполнять какие-либо операции по восстановлению.
Я посоветовал обратиться в службу поддержки Microsoft, чтобы обеспечить правильные шаги восстановления.
Вы можете обратиться к этим статьям Microsoft: