Анализ ошибок баз данных Exchange -1018, -1019 и-1022

Переводы статьи Переводы статьи
Код статьи: 314917 - Vizualiza?i produsele pentru care se aplic? acest articol.
Развернуть все | Свернуть все

В этой статье

Аннотация

Эта статья содержит сведения, помогающие оценить и проанализировать ошибки базы данных Exchange-1018, -1019 и-1022. В данной статье различия среди этих трех ошибок и типов вопросов в базе данных, вызывающие каждого из этих трех ошибок позволяет представлять фактические данные.

Дополнительная информация

Exchange включает в себя функциональные возможности для обнаружения повреждений на уровне файлов страниц в его базах данных. Ниже приведены три наиболее распространенные ошибки, связанные с повреждения базы данных Exchange на уровне файлов.
  • JET_errReadVerifyFailure -1018
  • JET_errPageNotInitialized -1019
  • -1022 JET_errDiskIO
Следующие три уровня повреждений может возникнуть в базе данных Exchange.
  • На уровне страниц (файловая система)
  • Уровень базы данных (ядро базы данных JET)
  • Уровень приложения (банк сообщений Exchange)
Служебная программа Esefile.exe можно обнаружить ошибки в базах данных на уровне страницы. Программа Eseutil.exe можно обнаружить и устранить проблемы на уровне страницы и на уровне базы данных. Служебную программу Isinteg.exe обнаруживает и исправляет проблемы на уровне приложения.

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

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

Почти всегда найти корневую причину ошибки -1018 в одной из базовых систем, от которых зависит Exchange, не Exchange кода сам. Существует очень мало исключения из этого правила. Исключения к дате были в части требований к отчетности условие -1018 Exchange не потому, что сам Exchange вызывает ошибку -1018. Для получения дополнительных сведений щелкните следующие номера статей базы знаний Майкрософт:
237953Ошибочные ошибку -1018, возвращаемый в ходе интерактивного резервного копирования
230215 Не выполнена, на однопроцессорных компьютерах резервной checksuming
Несмотря на то, что большинство ошибок-1019 и-1022 также причиной сбоя в базовой системе, нельзя исключить возможность, что-1019 и-1022 ошибки могут возникнуть из-за ошибки в Exchange код как можно быстрее.

Ошибка -1018 является наиболее часто ошибки, которая указывает, что база данных Exchange произошла повреждения на уровне файловой системы. Таким образом большая часть этой статьи посвящена Ошибка -1018.

Существует три основных способа, что на диске может привести к порче данных:
  • Неверные данные записываются на устройстве хранения данных.
  • Данные записываются в неправильное место на устройстве хранения данных.
  • Данные повреждены или изменены после сохранение.
Несмотря на то, что очень сложно предотвратить или устранить все повреждения на 100%, относительно легко обнаружить возникших проблем. Exchange обнаружит неправильное и перемещенные данные в свои файлы баз данных и выводит ошибку -1018 или ошибка -1019. Если файл серьезно повреждена, ее части полностью отсутствует или, в противном случае, недоступные при чтении файла обмена-1022 ошибка.

Как Exchange вычисляет контрольные суммы и базы данных номеров страниц

Чтобы понять, как работают механизмы, которые вызывают ошибки-1018 и -1019, необходимо понимать, как в базе данных Exchange хранятся страниц данных.

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

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

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

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

Первые два 4-Килобайтных страниц базы данных зарезервированы для базы данных «заголовок». При остановке базы данных можно использовать программу Eseutil /MH переключиться на просмотр этого заголовка. Заголовок содержит идентификационные сведения о базе данных в целом.

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

Поскольку первой страницы данных в базе данных Exchange находится после первых двух заголовке страниц, физическая страница 3 в базе данных является логической страницы 1. 2 — это логический номер физической страницы 4 и т. д.

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

Только страницы в базе данных, для которого не вычисляется контрольная сумма, «наличие неинициализированных страниц». Они представляют собой блоки страниц, которые создаются, когда размер базы данных расширяется, чтобы освободить место для дополнительных данных. Неинициализированный страницы не имеет нулевую контрольную сумму и нулевой номер страницы. Как правило каждый байт неинициализированных страниц заполняется символом 0x00.

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

Exchange Server 2003 с пакетом обновления 1 (SP1) изменен алгоритм контрольной суммы и формат страницы, которые используются. Кроме того Exchange Server 2003 с пакетом обновления 1 Появилась ошибка исправления кода (ECC) алгоритм для обнаружения и автоматически корректировать одноразрядные ошибки.Для получения дополнительных сведений об этой новой функции щелкните следующий номер статьи базы знаний Майкрософт:
867626Новый код коррекции ошибок включено в пакет обновления 1 для Exchange Server 2003

Что вызывает ошибку -1018

Exchange выводит ошибку -1018, когда инициализированные страницы в файл базы данных находится на одной из следующих условий:
  • Контрольной суммы, который хранится на странице не совпадает с результатом вычисления контрольной суммы, выполняемая при считывании страницы.
  • Номер страницы, который хранится на странице не соответствует номер страницы, который должен быть на странице, учитывая физическое расположение страницы в файл базы данных.
Exchange может быть ответственным за формирующиеся ошибку -1018, если Exchange выполняет одно из следующих:
  • Создает страницу с неправильной контрольной суммы.
  • Создает страницу правильно, но сообщает операционной системе для записи на странице в неправильном месте.
После системного администратора встречает ошибку -1018, если администратор запускает тесты диагностики оборудования для сервера и испытания не отправки отчетов, администратор может заключить, что Exchange должен нести ответственность за проблему, из-за аппаратных средств передачи первоначального анализа.

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

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

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

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

Контрольная сумма может быть создан неправильно для страницы, но затем страницы могут быть записаны на неправильное место на жестком диске. Это может быть вызвано временными памяти ошибки, например «отразить бит». Предположим, что Exchange создает новую версию стр. Сама страница не возникают ошибки, но копия номер страницы, используемый контроллером диска или операционной системой случайным образом изменена. Это может происходить, если 70 (двоичный 100110) было изменено 6 (двоичный 000110) ячейку памяти нестабильным. Контрольная сумма страницы по-прежнему верна, но теперь неправильное расположение страницы в базе данных. Exchange сообщает об ошибке -1018 для страницы, когда обнаруживает, что номер логической страницы не соответствует физическое расположение страницы. Другого рода нумерацию ошибок (из-за сервером Exchange Server) могут возникнуть Exchange записывает номер неправильный, непосредственно на странице. Однако в результате других ошибок, не Ошибка -1018. Если Exchange 71 на странице 70 и правильно ли контрольная сумма на странице, страница предназначен место 71 и проходит тесты страницы номер и контрольной суммы.

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

Несмотря на то, что одну ошибку -1018 вряд ли приведет к потере больших объемов данных, ошибок -1018 являются по-прежнему поводом для беспокойства, поскольку Ошибка -1018 является подтверждением того, что система хранения не надежно хранить или извлекать данные по крайней мере один раз. Несмотря на то, что ошибка -1018 может быть временным проблему, которая никогда не возникнет снова, более вероятно, что эта ошибка ранним предупреждением о проблеме, которая становится все хуже. Даже в том случае, если сначала Ошибка-1018 на пустой странице базы данных, невозможно знать, какие страницы затем может быть поврежден. Если поврежденный важной глобальной таблицы базы данных может стать unstartable и восстановление базы данных может быть только частично успешного или неудачного.

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

Восстановление после ошибок -1018

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

Страница, с ошибкой -1018 нельзя ремонта или восстановления. Он должен быть expunged из базы данных. Существует три способа, которые можно использовать, чтобы ликвидировать страницы из базы данных:
  • Восстановление базы данных из оперативной резервной копии.
  • С помощью программы Eseutil.exe /D коммутатор выполните автономную дефрагментацию базы данных.
  • С помощью программы Eseutil.exe /P коммутатор для восстановления базы данных.

Восстановите базу данных из оперативной резервной копии

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

С помощью программы Eseutil.exe ключом «/ D» для выполнения автономной дефрагментации базы данных

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

С помощью программы Eseutil.exe «/ P "коммутатор для восстановления базы данных

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

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

Восстановление базы данных обычно является низкокачественные стратегии, по сравнению с восстановления из резервной копии и базы данных, так как восстановление обычно занимает больше времени, чем восстановление и иная. Выберите восстановление, если только:
  • У вас нет резервной копии.
  • Вы не полного наката из резервной копии.
Ремонта или восстановления базы данных всегда сделать резервную копию текущих файлов базы данных. Если восстановление не работает, можно восстановить существующую базу данных. Если восстановление не работает, но предыдущей копии базы данных по-прежнему запуску системы, можно, в противном случае будут потеряны данные.

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

Чтобы проверить количество исправлений, проверки результатов, созданный при выполнении следующей команды:
ESEUTIL /MH [database_file_name]
Чтобы выполнить автономную дефрагментацию исправленной базы данных, выполните следующую команду:
ESEUTIL /D [database_file_name]
Сделать полный Isinteg исправление после восстановления в Exchange 2000, должна быть запущена служба банка данных, но необходимо отключить базу данных, которую требуется восстановить. Выполните следующую команду для исправления базы данных:
-S [ISINTEGимя_сервера]-FIX - ALLTESTS ТЕСТ
Сделать полный Isinteg исправления после восстановления в Exchange Server 5.5, необходимо остановить службу банка данных. Запустите следующую команду, используя соответствующий переключатель)-PRI -или- -PUB), в зависимости от того, запущен ли восстановление частной или публичной базе данных:
ПРОГРАММА ISINTEG-PRI|PUB-FIX - ALLTESTS ТЕСТ
Примечание Можно выполнять Eseutil и следующая на необработанной базы данных файлов, независимо от их файловой системе. Файлы базы данных даже необязательно иметь на сервере Exchange. Но пока база данных находится на полностью настроенный сервер Exchange, так как команда Isinteg работает на уровне хранилища данных и использует службу банка сообщений для доступа к базе данных необходимо выполнить команду Isinteg.

Для получения дополнительных сведений щелкните следующий номер статьи базы знаний Майкрософт:
244525Как запустить Eseutil на компьютере не установлен Exchange Server

Восстановление после ошибки -1019

-1019 (JET_errPageNotInitialized) Ошибка при страницы, которая должна использоваться неинициализированному или является пустым. Если поле номера страницы на странице используется 0x00000000, -1019 ошибка вместо ошибки -1018, несмотря на то, что страница также может завершиться ошибкой проверки контрольной суммы.

Методы для исправления ошибки -1019, те же исправить ошибку -1018. Обратите внимание на то, что проблема -1019 может незамеченными больше, чем проблема -1018 поскольку -1019 проблемы не обнаруживаются оперативной резервной копии.

Несмотря на то, что причиной ошибки -1018, скорее всего, находится вне Exchange, ошибка -1019 может быть вызвано Exchange Если недопустимые логические указатели или ссылки между страницами.

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

Восстановление после ошибки-1022

Если Exchange запрашивает у операционной системы страницу базы данных, а вместо возврата страницы данных возникает ошибка, приводит к ошибке-1022 (JET_errDiskIO). Ошибка-1022 — это универсальное сообщение об ошибке, которое появляется при каждом дискового ввода вывода (I/O) проблема предотвращает получение доступа к запрошенной странице базы данных Exchange.

Наиболее распространенная причина возникновения ошибки-1022 является файлом базы данных, который был серьезно повреждены или усечены. При возникновении этой проблемы Exchange запрашивает номер страницы, размер которых превышает количество страниц в файле базы данных, и возникает ошибка-1022. Эта проблема может возникнуть из-за проблем в файловой системе или из-за воспроизведение журналов транзакций неправильной.

Exchange 2000 содержит обширные меры предосторожности во избежание воспроизведения журнала транзакций, которая может повредить базу данных, но в Exchange Server 5.5 можно было воспроизводить неполный набор файлов журнала и повредить базу данных. Например это может произойти из журнала 9 начала воспроизведения, но вместо воспроизведения принудительно начинается из журнала 10. Воспроизведение может принудительно, если администратор удаляет файл контрольных точек и журналов 9. Если транзакции в журнале 9 расширяет размер базы данных, но журнал 9 не воспроизводятся в базе данных, ссылка в журнале 10 на новые страницы, добавленные к базам данных возникает ошибка-1022. Внезапной аварийно завершает работу, останавливается (выступ), и нарушения прав доступа также являются характерными признаками воспроизведение набора журналов незавершенных транзакций в базу данных.

Понимание и устранение основной причины ошибки-1022, сложнее, чем поиск и устранение ошибок-1018 или -1019. Причиной ошибки является повреждение базы данных в файловой системе, необходимо проверить или восстановить файловую систему и восстановите из резервной копии Exchange. Хотя восстановление базы данных по-прежнему восстановления менее вероятно быть успешным, чем с другими ошибками, поскольку-1022 ошибка обычно сигнализирует обширный ущерб.

Гораздо наиболее распространенная причина возникновения ошибки-1022 с неповрежденных баз данных другим приложением, удержание открытых файлов и предотвращая банка данных службы от доступа к ним. В таких случаях можно также увидеть ошибки -1032 (JET_errFileAccessDenied). Перезапуск всех служб Exchange или сервер может разблокировать.

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

Анализ ошибок-1018 и -1019

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

После администратор находит ошибки-1018 или -1019, администратор должен знать по крайней мере три вещи:
  • Какая была на поврежденной страницы
  • Какова вероятность успешного восстановления
  • В первую очередь причину повреждения
-ошибки 1018 и -1019 может произойти в командной строке при запуске службы, в журнале событий приложений или в выходных данных средства Exchange, например Eseutil. Ошибка -1018 в журнале событий приложений может не должен выводиться при выполнении проверки целостности базы данных с Eseutil/g команда. В этом случае вполне вероятно, что неправильная страница пуста.

В большинстве случаев ошибки выводятся в форме, которая позволяет идентифицировать страницу, которая сообщает о неполадках. Можно также выполнять сканирование всей базы данных с следующая для определения поврежденных страниц. Для получения дополнительных сведений о следующая щелкните следующий номер статьи базы знаний Майкрософт:
248406Следующая программа поддержки для Exchange 2000 и Exchange Server 5.5
Следующие примеры описаны типичные ошибки -1018 из журнала событий приложения для различных версий Exchange, с помощью анализа сведений в каждой ошибки.
MSExchangeIS (248) Synchronous read page checksum error -1018
((1:3106 1:3106)(0-310013)(0-312215)) occurred.
Please restore the databases from a previous backup.
					
В предыдущем примере цифры в скобках можно интерпретировать следующим образом:
  • (1:3106 1:3106) представляет страницу базы данных, запрошенную (страницу 3106) и номер страницы, фактически найден записываются на страницу (3106). 1: Указывает, что это база данных 1, который является Priv.edb для Exchange Server 5.5. База данных 2 — Pub.edb.
  • (0-310013) представляет dbtime значение, которое в настоящее время записи на странице. В dbtime значение равно 64-разрядное значение, написанного на каждой странице, которые сопоставлены примерно сколько времени прошло с момента создания страницы было изменено.
  • (0-312215) представляет текущее dbtime значение для базы данных в целом: скорее всего, dbtime значение, которое будет записан на этой странице страница была изменена сейчас. В dbtime значение уже на странице всегда должно быть меньше, чем текущий dbtime значение.
Учитывая, что номер страницы была правильно считывать из страницы и dbtime значения находятся в разумных пределах (с первой dbtime меньше значения второго), эта страница была не заменяется совершенно другую страницу или страницы из вне базы данных.

Следующая можно использовать для вывода страницы с помощью команды следующий:
Следующая /d database.edb 3106 > 3106.txt
Так как эта страница существенно неизменными по отношению к структуре, можно также с помощью Eseutil для просмотра более логичным сведения о странице. Версии Exchange 2000 Eseutil можно использовать для просмотра сведений о структуре страницы из базы данных Exchange 2000 и Exchange Server 5.5.

Предупреждение Не используйте версию Exchange 2000 Eseutil к базе данных Microsoft Exchange Server 5.5 в любой режим, который записывает данные в базе данных. В целях безопасности используйте только /M коммутаторы и никогда не использовать /P, /G, или / R. Кроме того не копируйте Exchange 2000 версии Eseutil.exe и Ese.dll компьютера Exchange Server 5.5. Вместо этого скопируйте эти файлы на удаленном сервере и обеспечения записи имен (UNC) явного командной строки в базу данных, изучении.

Команду, подобную следующей команды выводит сведения о логическом для страницы в текстовом файле:
Eseutil /M \\exchange1\d$\exchsrvr\mdbdata\priv.edb /p3106 > 3106.txt

Initiating FILE DUMP mode...
      Database: priv.edb
          Page: 3106

                        pgnoThis <0x02360004,  4>:  3106 (0x00000c22)
                        objidFDP <0x02360018,  4>:  19 (0x00000013)
                ulChecksumParity <0x02360000,  4>:  4269350574 (0xfe791eae)
        ** computed checksum: 157180847 (0x095e63af)
                   dbtimeDirtied <0x02360008,  8>:  310013 (0x000000000004bafd)
                          cbFree <0x0236001c,  2>:  436 (0x01b4)
                       ibMicFree <0x02360020,  2>:  3608 (0x0e18)
                     itagMicFree <0x02360022,  2>:  3 (0x0003)
               cbUncommittedFree <0x0236001e,  2>:  0 (0x0000)
                        pgnoNext <0x02360014,  4>:  3108 (0x00000c24)
                        pgnoPrev <0x02360010,  4>:  3088 (0x00000c10)
                          fFlags <0x02360024,  4>:  2050 (0x00000802)
                Leaf page
                Primary page
Из этого вывода можно увидеть, что страница является конечной странице, что означает, что у него фактические данные на нем. Если восстановить эту базу данных восстановления приведет к потере по крайней мере эти данные. Для получения дополнительных сведений о том, как узнать, какие таблицы или почтовый ящик, к которому принадлежит страница щелкните следующий номер статьи базы знаний Майкрософт:
262196Как определить, какой почтовый ящик ответственного за определенной страницы в базе данных
Если вывод Eseutil конечной страницы для страницы, скорее всего, восстановление будет работы полностью высоки. Наиболее внутренним или структуры страниц можно полностью перестраивается в процессе восстановления.

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

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

Следующее сообщение об ошибке — это еще один пример:
MSExchangeIS ((247) ) Synchronous read page checksum error -1018
((1:1057816 1:3688618971) (3688618971-3688618971) (0-16815256)) occurred.
Please restore the databases from a previous backup.
В этом примере номер страницы, который фактически прочитанной странице (3688618971) не поддерживает запрошенную страницу, что означает, что область заголовка страницы, где хранится номер страницы были повреждены. То, вероятно, что номер страницы еще не существует в базе данных. Чтобы определить, так ли это, умножить номер 4 096 и затем сравните размер в байтах для файла базы данных. В этом случае номер вряд ли один написал Exchange, если база данных находится в 15 терабайт размер (3,688,618,971 x 4 096 = 15,108,583,305,216).

Также обратите внимание, что первый dbtime значение точности повторяет шаблону номера страницы. При преобразовании 3688618971 в шестнадцатеричном формате (для использования Calc.exe в режиме Инженерный) становится 0xDBDBDBDB. В Exchange 2000 и Exchange Server 5.5, размером 8 байт dbtime значение сохраняется сразу после значения номера страницы размером 4 байт. По этой причине вы знаете, по крайней мере двенадцати смежных байтов для двух разных полей были заменены определенному шаблону. В этом случае используется следующая непосредственно взглянуть на этой странице будет возможно определять вся страница была заменена шаблон 0xDB. Другой шаблон распространенных недопустимый байт имеет значение 0xFF. Если это было в случае ошибки выше, dbtime значение будет 4294967295.

Следующее сообщение об ошибке предоставляет сведения о странице как смещение байта в файле, а не как номер страницы:
Information Store (2160) The database page read from the file
"d:\exchsrvr\MDBDATA\PRIV.EDB" at offset 897024 (0x00000000000db000)
for 4096 (0x00001000) bytes failed verification due to a page checksum
mismatch. The expected checksum was 2651583211 (0x9e0bf2eb) and the
actual checksum was 2651582996 (0x9e0bf214). The read operation will
fail with error -1018 (0xfffffc06). If this condition persists then
please restore the database from a previous backup.
					
Можно преобразовать смещение первого номера страницы, удалив три последние нули дробной части, вычитанием 1 и преобразовав результат в десятичное. В этом примере, 0x00000000000db - 1 = 0xda = 218 decimal. С помощью этого десятичный номер следующая или Eseutil.

Примечание Вычитание только 1, а не 2, с учетом два заголовка страницы в базе данных, поскольку смещения начать нумерацию строк с 0x0 вместо 0x1. Если вы хотите проверить заголовок страницы следующая или Eseutil, ссылки на страницы -1 и 0.

Заголовок базы данных Exchange действительно требуется только одна страница. Вторая страница — это «Тень» заголовка. Контрольные суммы, которые выводятся при использовании Следующая /D функция dump страницы всегда после должно быть одинаковым для страницы -1 и 0 база данных закрыта аккуратно. Если заголовок переписать во время сбоя, Exchange использует копировать заголовок с новой контрольной суммы при перезапуске Exchange.

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

Ожидаемая контрольная сумма в сообщении об ошибке является контрольная сумма, фактически чтения от страницы, что теперь существует в базе данных. Фактическая контрольная сумма в сообщении об ошибке является контрольной суммы, динамически re-calculates Exchange при чтении страницы.

Если фактическая контрольная сумма на странице 0x89abcdef, страница содержит все символы 0x00. Если фактическая контрольная сумма 0x76543210, страница содержит все символы 0xFF.

В следующем примере показана ошибка -1019:
Information Store (3928) The database page read from the file
"d:\exchsrvr\MDBDATA\PRIV.EDB" at offset 1675264 (0x0000000000199000)
for 4096 (0x00001000) bytes failed verification because it contains
no page data.  The read operation will fail with error -1019 (0xfffffc05).
If this condition persists then please restore the database from a
previous backup.
					
Страницы можно сообщить -1019 ошибка или Ошибка -1018, во время обычной работы, ошибка -1019 имеет более высокий приоритет и сообщается. Помните, что ошибка -1019 возникает всякий раз, когда номер страницы, написанные на странице 0x00000000, но Exchange ожидает страницы используется. Он может быть трудно доказать ли возникает ошибка -1019, поскольку файловая система сопоставления блока нулей в файл базы данных, или потому, что Exchange ошибки и ссылка на неиспользуемые страницы как «используемые.»

Невозможно определить, из-за предыдущей ошибки ли страницы не инициализирован или в другое состояние. Для дальнейшего изучения на странице используются следующая и Eseutil. В этом примере номер страницы — 408 decimal (производный от 0x199).

С помощью Eseutil для дальнейшего изучения на странице. В pgnoThis значение должно совпадать с номером страницы, запрашивается, и ulChecksumParity значение сообщает дополнительных ** контрольная значение в случае неправильной контрольной суммы на странице. Используется следующая /D коммутатор взглянуть на необработанные страницу, чтобы определить, является ли неинициализированные (все знаки 0x00).

Ложных ошибок -1018

Произошла ошибка в «false» -1018 правильные страницы на диск, когда система ввода/вывода получает данные неправильно. Такие ошибки обычно являются временными и сложно изолировать. Но даже значение «false», Ошибка -1018 заслуживает серьезного внимания. Нарушена стабильность системы хранения данных, и система может находиться в опасности дополнительные вопросы или при сбое.

Если вы подозреваете временных ошибок чтения в вашей системе используется следующая /D Переключение или Eseutil /P/m Чтобы проверить отдельные страницы, которые в них участвуют. Если сканирование всей базы данных с помощью любой программы поместить нагрузку на системы ввода-вывода, который может привести к ложных срабатываний.

Exchange Server 5.5 с пакетом обновления 2 (SP2) добавлена функциональность для определения временных ошибок чтения. Повторно Exchange считает страницы 16 раз после сбоя проверки чтения. После успешного страницы, ознакомьтесь со временем после нескольких попыток, он указывает на наличие проблемы системы в надежно с диска. Даже если не все операции чтения 16, она не подтверждает conclusively что страница плохой. Выполнение дополнительного тестирования следующая или Eseutil.

Обнуление базы данных

Обнуление базы данных должно скрывать данные в базе данных Exchange, таким образом, чтобы восстановить или прочитаны прямой проверки файла базы данных. Для получения дополнительных сведений о обнуление базы данных щелкните следующий номер статьи базы знаний Майкрософт:
223161Информация о обнуление ESE
Если включено обнуление базы данных разделов пустым или частично пустые страницы могут быть перезаписаны с помощью шаблонов, определенных символов, но страница по-прежнему не возвращается в неинициализированном состоянии.

Свойства

Код статьи: 314917 - Последний отзыв: 7 июня 2011 г. - Revision: 4.0
Информация в данной статье относится к следующим продуктам.
  • Microsoft Exchange Server 2003 Standard Edition
  • Microsoft Exchange Server 2003 Enterprise Edition
  • Microsoft Exchange 2000 Server Standard Edition
  • Microsoft Exchange Server 5.5 Standard Edition
Ключевые слова: 
kbinfo kbmt KB314917 KbMtru
Переведено с помощью машинного перевода
ВНИМАНИЕ! Перевод данной статьи был выполнен не человеком, а с помощью программы машинного перевода, разработанной корпорацией Майкрософт. Корпорация Майкрософт предлагает вам статьи, переведенные как людьми, так и средствами машинного перевода, чтобы у вас была возможность ознакомиться со статьями базы знаний KB на родном языке. Однако машинный перевод не всегда идеален. Он может содержать смысловые, синтаксические и грамматические ошибки, подобно тому как иностранец делает ошибки, пытаясь говорить на вашем языке. Корпорация Майкрософт не несет ответственности за неточности, ошибки и возможный ущерб, причиненный в результате неправильного перевода или его использования. Корпорация Майкрософт также часто обновляет средства машинного перевода.
Эта статья на английском языке:314917

Отправить отзыв

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com