Ранее этим утром store.exe так или иначе завис, что потребовало перезапуска нашего сервера Exchange. Он вернулся в онлайн без ошибок или проблем, все журналы транзакций были успешно воспроизведены, и все хранилища смонтированы в обычном режиме. Для меня это был просто один из тех случайных сбоев; однако наш консультант подозревает, что причиной этого стала коррупция в одном из магазинов. Возможно, он прав, поскольку у него гораздо больше опыта, чем у меня, но дело не в этом.
Чтобы исправить предполагаемые ошибки, он планирует запустить дефрагментацию ESEUTIL (через PerfectDisk), чтобы исправить их, что, как он утверждает, также исправит любые имеющиеся ошибки.
Насколько я понимаю, дефрагментация, проверка и восстановление - это 3 отдельных действия, и дефрагментация не подразумевает какой-либо проверки целостности. Это верно? Есть ли опасность запуска прямой дефрагментации базы данных, которая может быть повреждена?
Редактировать:
Вот первая ошибка в журнале событий, которая указала на начало проблем, которые у нас были. Кто-нибудь знает, что это может означать?
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 ....
Автономная дефрагментация с использованием 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). Мне было бы интересно узнать больше о том, что произошло потом, а также о любых событиях, непосредственно предшествующих этому, из журнала системных событий. Было ли у вас нехватка дискового пространства на каком-либо из томов серверного компьютера?