Постоянная доступность данных

Основные моменты, обеспечивающие постоянную готовность современных СУБД, можно определить как:

• оперативное администрирование;
• функциональная насыщенность СУБД.

Оперативное администрирование

Средства администрирования в идеале призваны поддерживать бесперебойное функционирование СУБД, что подразумевает сведение к минимуму планируемых или сбойных простоев системы. На практике систему иногда требуется остановить ради выполнения какой-либо утилиты. Утилиты для пакетной загрузки/выгрузки данных, архивирования и восстановления, проверки целостности, реорганизации индекса и пр. - все должны эффективно выполняться в оперативном (on-line) режиме, без остановки СУБД, причем для ускорения предпочтительно использование параллельных алгоритмов. При возникновении сбоя во время этих, как правило, продолжительных операций, с помощью контрольных точек (checkpoints) или даже специальных журналов должен обеспечиваться повторный запуск административных утилит непосредственно с точки останова. Для сокращения времени автономного (off-line) обслуживания необходима поддержка таких возможностей, как автоматическое, без участия оператора, оперативное архивирование заполненных журналов и базы данных одновременно на несколько архивных устройств, автоматический перезапуск системы с контролируемым временем восстановления и т.д. Задачи администрирования, включая мониторинг и реконфигурацию ресурсов системы, часто вступают в противоречие с доступностью данных. В идеале, выполнение операций по реорганизации и перемещению крупных таблиц и индексов в пределах системы не должно ограничивать доступ к таблице, части таблицы или к базе данных. Даже в случае необходимости выключения части базы данных, например в силу физического повреждения таблиц или их частей, работоспособные части таблиц и базы данных должны оставаться доступными для приложений в течение времени восстановления (рис. 9). При этом приложения должны, конечно, знать, что вместо целой таблицы для запросов доступна лишь ее часть. Вообще говоря, любые административные действия, включая физическое планирование, размещение, перемещение и реорганизацию баз данных, управление дисковым пространством, архивирование и восстановление журналов и частей баз данных, перезапуск СУБД должны быть максимально прозрачными для приложений. Средства мониторинга серверов СУБД должны позволять пользователям строить свои собственные управляющие процедуры, отражающие специфику применения СУБД. При этом важны такие параметры, как возможность централизации управления, подобно средствам прежних централизованных систем (mainframes), выполнение операций в назначенное время без участия оператора (unattended or scheduled), одновременное использование всех доступных архивных устройств вычислительной платформы. Все это обеспечивает максимальную готовность и доступность информационной системы.

Рис. 9. Оперативное параллельное восстановление базы данных.

Функциональная насыщенность СУБД

Общим термином "функциональная насыщенность" можно определить множество механизмов, используемых серверами баз данных (а) для уменьшения последствий системных сбоев и (б) для повышения прозрачности доступа к дублированным данным при нормальном функционировании. Теоретически СУБД обязана обеспечивать доступ к данным по чтению и записи, независимо от обстоятельств, будь то сбой аппаратной платформы или какого-то ее компонента. Для обозначения такого уровня доступности используется термин "нечувствительность к сбоям". Кроме того, существует класс систем, в которых требования к доступности данных не так высоки, т.е. допустим временный, хотя и очень короткий (несколько минут в год), период неработоспособности.

Системы, обеспечивающие непрерывный доступ к данным (fault tolerant) или почти непрерывный (high availability) обычно опираются на различные формы избыточности. Как правило, это системы дублирования аппаратного обеспечения и контролируемой избыточности данных. Аппаратная избыточность может включать платформы с полным резервированием, поддерживающие (standby) процессоры, диски с двойным интерфейсом (dual-port), дисковые массивы и пр. Один из вариантов - зеркалирование дисков, когда один диск используется в качестве копии другого и может быть использован при сбое вместо него. Хотя аппаратная избыточность и важна для повышения общей надежности системы, ее реализация, как правило, не ориентирована на обработку транзакций СУБД и на связанные с этим специфические ограничения, например, обеспечение атомарности транзакции. В результате СУБД не может воспользоваться преимуществами чисто аппаратных решений резервирования системы для повышения своей производительности. Управляемая избыточность данных обычно представлена в двух формах - программное зеркалирование (software mirroring) и тиражирование (replication) данных. Программное зеркалирование дисков, называемое также дуплексированием (duрlexing) или мультиплексированием (multiplexing), может не только защитить от аппаратных сбоев, но и улучшить производительность. Поскольку зеркалирование базы данных (или ее частей - таблиц(ы), индексов, их фрагментов и пр.) производится на другом физическом устройстве, то операции чтения данных можно распределить между двумя устройствами и производить параллельно (рис. 10). Конечно, зеркалирование бесполезно с любой точки зрения, если оно организовано на одном диске.

Рис. 10. Организация параллельного чтения

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

Рис. 11. Организация тиражирования с поддержкой удаленной копии базы

Тиражирование в системах, требующих в первую очередь повышенной надежности, в целом подобно зеркалированию, но здесь копия данных может поддерживаться удаленно. Если происходит копирование всей базы данных, то обычно это делается с целью обеспечить горячий резерв (warm standby). Однако в некоторых реализациях есть возможность использовать копию для просмотра (без модификации) данных. Это способно обеспечить значительные преимущества для систем со смешанной загрузкой, поскольку приложения для принятия решений, генерации отчетов и т.п. могут обращаться к копии базы данных, в то время как приложения оперативной обработки транзакций используют первичную базу данных (рис. 11).