Обзор архитектуры базы данных Exchange Server и СУБД

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

В этой статье

Аннотация

Эта статья содержит общие сведения о базе данных Архитектура и ядро СУБД для Microsoft Exchange Server. Обсуждение содержит сведения о компоненты базы данных обслуживания базы данных согласованность возможных типов сбоев базы данных и служебные программы.

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

Сервер Exchange использует от сбоев, на основе транзакций базы данных для хранения сообщений и сведения о каталоге до его применения к База данных. Для Exchange Server 5.5 Standard Edition может увеличиваться каждой базы данных максимум 16 гигабайт (ГБ). Для Exchange Server 5.5 корпоративный выпуск размер ограничивается только оборудование.

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

Компоненты баз данных

Разработки Exchange Server основана на стандартной базы данных Технология. Система использует встроенный механизм базы данных, располагает Структура диска для сервера Exchange Server и управления памятью. База данных Технология ядра также используется другими приложениями Windows, за кулисами например Windows Internet Name Service (WINS) и динамического узла Конфигурация протокола (DHCP).

Банк данных

Банк, который является ключевым компонентом для базы данных Управление в Exchange Server — это фактически две базы данных. Закрытый базы данных банка, Priv.edb, управляющей данными в почтовые ящики пользователей. В общих папок, Pub.edb, управляющей данными в общих папках.

Банк работает с сообщениями приложение программирования Ядро базы данных, чтобы гарантировать, что все действия пользователя и интерфейс (MAPI) записанные на жесткий диск сервера. Например, когда пользователь сохраняет сообщения в Microsoft Outlook MAPI сначала вызывает банка, который затем вызывает компонент Database engine, который затем записывает изменения на диск.

Ядро базы данных JET

Баз данных Exchange Server основаны на формате JET, который использует файлы журналов для отслеживания и сохранения данных. Microsoft JET является Дополнительно 32-разрядные многопоточных СУБД, сочетает в себе скорость и производительность другие дополнительные возможности для улучшения обработки на основе транзакций возможности.

Компонент database engine кэширует диска в память Замена страницы по 4 килобайта (КБ) данных из памяти. Обновляет страницы в памяти и записывает новые или обновленные страницы обратно на диск. Это делает более эффективным, поскольку при поступлении запросов, ядро базы данных системы буферов данных в памяти вместо постоянно обращения к диску.

В версии более ранней, чем Exchange Server 5.5 буферного кэша имеет фиксированный размер. Если требуется дополнительная память, администратор должен вручную изменять размер буфера.

В Exchange Server 5.5, выделения динамического буфера позволяет буфера кэш-памяти увеличивается или уменьшается, в зависимости от того, сколько памяти доступно и о том, что ресурсы используются другими службами, которые выполняются на платформе Microsoft Компьютер с системой Windows NT Server. Если память, не используются другими службами Ядро базы данных Exchange Server занимает столько памяти, сколько необходимо. Если другие службы должны памяти, компонент database engine предоставляет некоторый объем памяти, передача страницы на жесткий диск и уменьшение размера буфера.

При пользователь делает запрос, компонент database engine запрос загружает в память и Пометка страниц как «грязный» («грязный» страница является страницей, записанные с помощью данные и по-прежнему задерживается в памяти). Позже эти «грязные» страницы записываются на баз данных банков сообщений на диске.

Поддержание согласованности базы данных

Несмотря на то, что кэширования в памяти — это наиболее эффективный способ обработки данные, один эффект является то, что данные на диске никогда не полностью последние версии. База данных помечена как привести к «грязных» страниц в памяти Несовместимость, несмотря на то, что сервер Exchange работает нормально. Базы данных действительно в согласованном состоянии, только когда все «грязные» страницы успешно перенесены на диск во время завершения работы, в котором нет ошибок.

Что При потере содержимого памяти? Например если сервер зависает Перед записью данных на диске и остается несогласованным База данных? Exchange использует файлы журнала транзакций для восстановления из этой ситуации.

Файлы журнала транзакций

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

Обмен «на основе транзакций» системы обмена сообщениями и банка данных транзакций базы данных. Транзакция — это набор изменений для базы данных, таких как вставки, удаления и обновления, в которых система за четыре «КИСЛОТА» инварианты:
  • Атомная: Либо все операции выполняются или ни один из них происходят.
  • Согласованность: База данных преобразуется из одного правильного между состояниями.
  • Изолированное: Изменения не видны до момента фиксации.
  • Надежность: Зафиксированные транзакции сохраняются в База данных даже в случае отказа системы.
Следуя этим инвариантов означает, что компонент database engine фиксирует транзакцию только в том случае, если он может гарантировать, что данные длительного пользования или Постоянная, защищенный от сбоев и другие сбои. Компонент database engine фиксирует данные только после передачи данных из памяти файл журнала транзакций на жестком диске.

Например, чтобы переместить выполняет важные папки сервера Exchange сообщения из папки «Входящие» три операции:
  1. Удаляет сообщение из папки «Входящие»
  2. Вставляет сообщение в папку «важные»
  3. Обновляет сведения о каждой папки в соответствии с число непрочтенных элементов и элементов
Эти операции выполняются в одной транзакции. Порядок операции, не имеет значения. Сервер Exchange Server, можно удалить сообщение из Папка "Входящие" поскольку удаление фиксируется только в том случае, когда сообщение безопасно вставлена важные папки. Даже в случае отказа системы Exchange Сервер никогда не теряет сообщения во время его перемещения и никогда не заканчивается двух копий сообщения.

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

Файл контрольных точек

Компонент database engine сохраняет файл контрольной точки с именем EDB.chk для каждой последовательности файла журнала следить за данные с еще не были записаны в файл базы данных на диске. Файл контрольной точки указатель в последовательности журналов, указывающее место в файле журнала требования для запуска восстановления в случае сбоя хранилища информации. В файл контрольных точек для эффективного восстановления. Без него Банк данных начнется с начала старого файла журнала на на диске и проверьте каждую страницу в каждый файл журнала, чтобы определить, будет ли он уже был были записаны в базу данных--процесс занимает много времени, особенно если все вы Чтобы сделать — это создание согласованной базы данных.

Файл контрольной точки расположены на системном диске. Если необходимо восстановить системный диск, этот файл скорее всего отсутствует или только некорректную версию. Но в большинстве случаев файл контрольных точек берет на себя.

Нормальному уровню ведения журнала

Ниже приведен процесс "normal ведение журнала"где данные записываются в файлы журнала транзакций:
  1. Пользователь отправляет сообщение.
  2. MAPI вызывает хранилище сведений о том, что пользователь отправляет сообщение.
  3. Банк начинает транзакцию базы данных ядро и вносит соответствующие изменения данных.
  4. Компонент database engine записывает транзакцию в памяти dirtying новую страницу в памяти.
  5. Одновременно компонент database engine обеспечивает безопасность транзакций в файл журнала транзакций и создает запись журнала. Когда компонент database engine достигает конца файла журнала транзакций по и создаст новый журнал файл в последовательности.
  6. Компонент database engine записывает «грязные» страницы в базе данных файл на жестком диске.
  7. Обновить файл контрольной точки.
Циклическое ведение журнала

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

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

По умолчанию циклическое ведение журнала включено в Exchange 5.5 Для поддержания фиксированного размера для файлов журнала и предотвращения электростатического сервера. При файл журнала достигает предельного размера 5 МБ, компонент database engine удаляет его и создает новый файл журнала в последовательности. В результате сервер Exchange Server сохраняет достаточно только данные на жестком диске, чтобы сделать if согласованность базы данных происходит сбой происходит.

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

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

Защита данных

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

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

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

Каждый файл журнала в последовательность может содержать до 5 МБ данных. Когда файл журнала заполнен, он является переименован как предыдущий файл журнала и создан новый файл Edb.log имя. Exchange Server связывает каждый файл журнала с шестнадцатеричным поколения номер. Поскольку файлы журнала могут иметь одинаковое имя, штампы ядро базы данных в заголовке каждого файла в последовательности с уникальной подписи, так что его можно различать различных поколений файлов журнала.

Повреждение базы данных

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

Существует два типа повреждения:
  • Физическое повреждение
    На самом низком уровне данные могут физически поврежден на диске. Это обычно оборудования проблема, которая всегда требуется для восстановления из резервной копии.
  • Логических повреждений
    Типичное логическое повреждение происходит на уровне базы данных. Например сбоев ядра базы данных может привести к индексу операции, чтобы указать отсутствующие значения. Логическое повреждение может также возникать в уровень приложений в почтовые ящики, сообщения, папки и вложений. Для пример, повреждения на уровне приложения может привести к подсчеты неправильной ссылки уровни управления неверный доступ, заголовок сообщения без текста сообщения и т. д.

Физическое повреждение

Физическое повреждение серьезной, потому что он может уничтожить данные, и Единственное, что можно сделать это восстановление из резервной копии Exchange. Очень важно, Определение физического повреждения раннее и быстрого устранения проблем.

Определение физического повреждения

Создает физического повреждения в банке следующие ошибки в журнале приложений средства просмотра событий:
  • Представляет данные, считанные с диска -1018 (JET_errReadVerifyFailure) не так же, как данные, записанные на диск.
  • -1022 (JET_errDiskIO) оборудования, драйвер устройства или Возвращает ошибки операционной системы.
  • -510 JET_errLogWriteFail файлов журнала нет диска пробел или сбоя оборудования с диска файл журнала.
Несмотря на то, что Exchange обычно отображается ошибка-1018 или-1022 сообщения при отсутствии физического повреждения, можно также определить физический Рекомендуется повреждения путем выполнения оперативного архива, которые являются корпорации Майкрософт метод резервного копирования данных. Оперативное резервное копирование также является лучшим способом для обнаружения повреждение базы данных файла, поскольку он является единственным, обработки систематически проверяет каждый одной страницы в базе данных.

Когда вы Запуск интерактивного резервного копирования, программа архивации Windows NT читает каждой страницы размером 4 КБ файл базы данных передает в ядро базы данных, а затем записывает его на Лента. Компонент database engine проверяет правильность контрольной суммы на каждой странице. Если контрольная сумма на странице не соответствует контрольной суммы, базы данных вычисляет модуль повреждения физической базы данных на жестком диске и NT Backup заносит в журнал ошибку -1018.

Предотвращение физического повреждения

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

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

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

Восстановление после физического повреждения

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

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

ПРИМЕЧАНИЕ: Если это вообще возможно, избегайте использования Eseutil в режиме восстановления (Eseutil / p). Eseutil, поставляемый с сервером Exchange Server, — это последнее средство для Восстановление повреждения базы данных, когда другие способы не помогают. В режиме восстановления он получает неработающих базу данных работать вновь, путем удаления поврежденных страниц. Никогда не должно Eseutil используется для восстановления данных. Если при запуске Eseutil /p команды, необходимо запустить (дефрагментации в автономном режимеEseutil /d), а затем запустите Isinteg-test alltests-исправление Команда восстановить базу данных в согласованное состояние.

Логических повреждений

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

Предотвращение логических повреждений

Поскольку логических повреждений непредсказуемым таким образом, существует не гарантирует полную надежность способа предотвратить его. Однако существуют способы уменьшить риск:
  • Установите последний пакет обновления для Microsoft Exchange Server версии 5.5 как можно скорее. Пакеты обновления устранить ряд известных проблемы в Exchange Server 5.5.

    Для Дополнительные сведения о пакеты обновления и как получить их, нажмите кнопку следующие номера статей базы знаний Майкрософт:
    241740 Список ошибок Исправлено в Exchange Server 5.5 с пакетом обновления 3
    254682 XADM: Исправления ядра базы данных Post-3 (SP3) Exchange Server 5.5
    191014 Как получить последний пакет обновления для Exchange Server 5.5
  • Убедитесь, что компьютер Exchange Server является безопасным и что конфигурации не изменяется.
Если вы обнаружили проблему и сохранится после выполнения через на эти меры предосторожности, вы может нашли новую ошибку. Если это случае, как можно скорее уведомить корпорацию Майкрософт.
Восстановление логических повреждений

В банке данных может привести к повреждению логические или в ядре СУБД. Поскольку логическое повреждение может вызвать серьезные повреждения к данным не игнорировать отчеты ошибок.

Можно использовать команды Isinteg Утилита для проверки возникают проблемы в банке или служебной программы Eseutil Чтобы проверить, возникают проблемы в ядре СУБД. Обратите внимание, что следует использовать эти Служебные программы только как последнее средство после восстановления системы из резервная копия.

Программа Isinteg

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

Программа Isinteg не предназначен для использования в рамках обслуживания хранилища обычной информации; он предназначен для помощи в ситуациях аварийного восстановления. Например можно запустить Их достижения Isinteg информации хранения счетчики памяти Синхронизируйте после сбоя системы.

Поскольку программа Isinteg работает на Уровень логической схемы, можно восстановить данные, которые не удается восстановить программы Eseutil. Это обусловлено тем, что данные, являются допустимыми для программы Eseutil с физического на уровне логической схемы могут быть семантически недопустимого уровня схемы. Программа Isinteg Записывает данные в журнал приложений в средстве просмотра событий, чтобы Ход восстановления.

Программа Isinteg выполняет две основные задачи:
  • Исправления банка данных после восстановления из автономная архивация.
  • Он проверяет и при необходимости исправления ошибки в информации хранилище.
Для дополнительной сведения об устранении неполадок с хранилищем данных и программа Isinteg щелкните следующий номер статьи базы знаний Майкрософт Основание:
182081 XADM: Описание программы ISINTEG

или можно найти в Isinteg.rtf на Exchange Server 5.5 компакт-диске, в каталоге Support\Utils.

Программа Eseutil

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

Для получения дополнительных сведений о С помощью средства Eseutil щелкните следующий номер статьи для просмотра статьи в База знаний корпорации Майкрософт:
192185 XADM: Инструкции по дефрагментации с помощью средства ESEUTIL (Eseutil.exe)
или можно найти в Eseutil.rtf Exchange 5.5 компакт-диск в каталог Support\Utils.

Резервное копирование данных

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

Оперативное резервное копирование

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

Exchange использует файл .pat (исправление), который следит за обновленные страницы резервного копирования программа запущена, убедитесь, что, страницы, измененные во время резервного копирования также резервного копирования. Существуют два файла .pat, Priv.pat для частного Банк данных и Pub.pat для общих папок.

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

Процесс интерактивного резервного копирования

Программа резервного копирования, например в Windows NT Backup (Ntbackup.exe) выполняет следующие во время полной резервной копии или резервной копии:
  1. Создание копии базы данных и сохраняет его на ленту.
  2. Добавляет набор страниц в файле .pat страниц, изменения после копирования на ленту.
  3. Переименовывает текущий файл Edbx.log, где x Это номер файла журнала в шестнадцатеричном формате и Создание нового поколения журнала.
  4. В полной резервной копии архивацию .pat файл и все файлы журнала После контрольной точки (за исключением нового Edb.log) на ленту. В резервной копии резервное копирование всех файлов журнала до и после контрольной точки.
  5. В полной резервной копии удаление файлов журналов транзакций, которые являются старше контрольной точки. В резервной копии не приводит к удалению всех транзакций файлы журнала.
Программа архивации выполняет следующие во время добавочного резервной копии или разностной резервной копии:
  1. В добавочной резервной копии, создается копия файлов журналов и Архивирование ленты. В разностной резервной копии копирует базу данных Лента.
  2. Добавляет набор страниц в файле .pat страниц, изменения после копирования на ленту.
  3. Переименовывает текущий файл Edbx.log и создает новое поколение журнала.
  4. Резервное копирование файла .pat и все файлы журнала до и после контрольной точки, включая новые Edb.log, на магнитную ленту.
  5. В добавочное резервное копирование удаление файлов журналов транзакций старше контрольной точки. В разностной резервной копии не приводит к удалению всех журналов файлы.

Автономная архивация

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

Для получения дополнительных сведений об архивации щелкните ее следующие номера статей базы знаний Майкрософт:
191357 XADM: Восстановление отдельной базы данных из полное оперативное резервное копирование
179308 XADM: Инструкции по проверке Exchange оперативного архива

Свойства

Код статьи: 271987 - Последний отзыв: 5 июня 2011 г. - Revision: 4.0
Информация в данной статье относится к следующим продуктам.
Ключевые слова: 
kbinfo kbmt KB271987 KbMtru
Переведено с помощью машинного перевода
ВНИМАНИЕ! Перевод данной статьи был выполнен не человеком, а с помощью программы машинного перевода, разработанной корпорацией Майкрософт. Корпорация Майкрософт предлагает вам статьи, переведенные как людьми, так и средствами машинного перевода, чтобы у вас была возможность ознакомиться со статьями базы знаний KB на родном языке. Однако машинный перевод не всегда идеален. Он может содержать смысловые, синтаксические и грамматические ошибки, подобно тому как иностранец делает ошибки, пытаясь говорить на вашем языке. Корпорация Майкрософт не несет ответственности за неточности, ошибки и возможный ущерб, причиненный в результате неправильного перевода или его использования. Корпорация Майкрософт также часто обновляет средства машинного перевода.
Эта статья на английском языке:271987

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

 

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