Тема номера: Системы высокой готовности

Рон Вейсс

Oracle Database 10g - переворот в готовности данных
(How Oracle Database 10g Revolutionizes Availability and Enables the Grid,
by Ron Weiss, Oracle Corporation)

Oracle Database 10g переворачивает представление о доступности данных и говорит “Да” распределенным вычислениям

Источник: доклад на конференции Сан Франциско, 2003, 20http:/otn.oracle.com/tech/grid/collateral/10gAvailability.pdf, а также http://otn.oracle.com/deploy/availability/pdf/40164_Loaiza_doc.pdf

Оглавление:

• *Введение
• *Причины остановок
• *Защита от сбоев оборудования
• *Архитектура Grid на базе Real Application Clusters
• *Временные рамки восстановления базы данных
• *Защита от повреждения данных
• *Защита от неисправностей накопителя
• *Исключение человеческого фактора
  • *Предохранение от ошибок
  • *Технология Oracle Flashback
  • *Ретроспективные запросы
  • *Flashback Versions Query
  • *Flashback Transaction Query
  • *Flashback Database
  • *Flashback Table
  • *Flashback Drop
• *Средство LogMiner для анализа журнальных файлов
• *Защита от искажений информации
  • *Hardware Assisted Resilient Data (HARD)
  • *Ретроспективное резервирование и восстановление
• *Защита от повреждений сайта
  • *Data Guard
  • *Режим Redo Apply
  • *Режим SQL Apply
  • *Передача без потерь журнальной информации
  • *RealTime Apply и Flashback Database
• *Data Guard Broker
• *Устранение плановых простоев
• *Устранение простоев, вызванных реорганизацией данных
  • *Преобразование схемы и данных “на лету”
  • *Секционирование таблиц и индексов
  • *Динамическое подключение ресурсов
• *Устранение простоев, связанных с модернизацией системы
  • *Круговая установка патчей
  • *Круговая замена программного обеспечения
• *Архитектура максимальной готовности (MAA)
• *Заключение

 Введение

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

Тенденции, существующие в современном мире, послужили импульсом к внедрению новой архитектуры IT, именуемой Grid computing. Технология распределенных вычислений (Grid computing) представляет собой новую архитектуру обработки данных, позволяющую объединить многочисленные серверы и хранилища информации в гибкую вычислительную систему, способную удовлетворить любые потребности предприятия. Последние достижения в области новейших технологий, как то недорогие сверхтонкие серверы (blade-servers), компактные мультипроцессорные конфигурации, сети хранения данных (modular storage) и операционные системы с открытым кодом наподобие Linux обеспечивают необходимую аппаратную базу для ее реализации. Дополнив мощь технических средств гибкостью архитектуры Grid пакета Oracle Database 10g, предприятия смогут предложить своим клиентам сервис высочайшего уровня и существенно снизить расходы на IT. Oracle Database 10g дает шанс оценить экономичность механизма распределенных вычислений без ущерба для производительности, масштабируемости, безопасности, управляемости, функциональности или надежности системы.

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

 Причины остановок

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

Рисунок 1. Причины остановок

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

 Защита от сбоев оборудования

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

Рисунок 2. Отказы оборудования  

Архитектура Grid на базе Real Application Clusters

Технология Real Applicaton Clusters (RAC) дает предприятию возможность собрать серверную конфигурацию, характеризующуюся высокой готовностью и масштабируемостью, на основе нескольких подсистем. В среде RAC работа ПО Oracle, осуществляющего доступ к базе данных, обеспечивается двумя или более узлами, объединенными в кластер. Благодаря этому, база данных, разделенная между несколькими аппаратно независимым подсистемам, на программном уровне сохраняет свою целостность, что открывает перед приложениям невиданные перспективы:

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

RAC создает условия для Grid. Grid включает в себя системы, состоящие из большого числа стандартных недорогих элементов, таких как процессоры, серверы, сетевое оборудование и устройства хранения информации. RAC является единственной технологией, способной превратить эти разрозненные компоненты в эффективную вычислительную систему масштаба предприятия. Совместное применение RAC и Grid ведет к значительному сокращению эксплуатационных расходов и наделяет систему дополнительной степенью свободы, благодаря чему она становиться более гибкой, “умной” и адаптивной. Динамическое подключение узлов, устройств хранения информации, процессоров и банков оперативной памяти позволяет без труда поддерживать качество сервиса на должном уровне, способствуя еще большему снижению затрат ввиду более эффективной эксплуатации ресурсов. Кроме того, RAC совершенно прозрачен для любого приложения, обращающегося к базе данных, и не требует какой бы то ни было модификации при развертывании RAC-системы.

Технология Real Application Clusters разрешает пользователю добавлять в кластер новые узлы по мере необходимости, давая ему возможность расширять систему постепенно, не тратя деньги на замену мелких узлы более крупными. Построения Grid, составленные из обычных недорогих компьютеров и дисковых массивов, с появлением Oracle Database 10g лишь повышают эффективность подобного решение. Существенно упрощается и ускоряется процесс наращивания мощности кластера, поскольку добавить в кластер один или несколько узлов гораздо проще нежели переоснастить имеющуюся систему новыми, более крупными узлами. Технология Cache Fusion, являющаяся составной частью Real Application Clusters, и поддержка InfiniBand, реализованная в Oracle Database 10g, гарантируют пользователю практически линейный рост объема кластера без изменения структуры системы.

Еще одним важнейшим достоинством кластерной архитектуры является ее традиционная отказоустойчивость, которая зиждется на мультиузловой организации. Так как узлы кластера физически независимы, сбой одного из них никак не влияет на работоспособность остальных. В Grid возможен отказ любого из узлов, но даже в самом крайнем случае, когда из строя выйдут все узлы, кроме одного, даже тогда Real Application Cluster будет в состоянии обеспечить функционирование базы данных. При такой архитектуре можно абсолютно безболезненно вводить или выводить, например, для ремонта, из состава кластера любое количество узлов; оставшаяся часть продолжит выполнять свои функции. RAC интегрирован с Oracle Application Server 10g в плане переключения пулов. В этом случае приложение получает уведомление о той или иной неполадке немедленно, а не ждет добрый десяток минут, прежде чем среагировать на таймаут TCP. Как следствие, оно тут же готово предпринять соответствующие меры восстановительного характера, и через некоторое время механизм компенсации нагрузки Grid перераспределит ее по оставшимся узлам.

Пакет Oracle Database 10g обладает целым набором средств управления кластером. В его состав включены все функции, необходимые для работы его, в том числе, управление членством узла (node membership), служба сообщений, а также механизм блокировки. Поскольку все это представляет собой полностью интегрированный программный пакет, снабженный традиционным API обработки событий, им можно управлять непосредственно из Enterprise Manager. Нет никой необходимости приобретать какое-либо дополнительное программное обеспечение для этих целей, ввиду чего вероятность возникновения ошибок при согласовании приложений сводится к нулю. Интерфейс и функциональность пакета инвариантны относительно любых платформ, на которых работает Oracle Database. Кроме того, Oracle собирается и дальше поддерживать “кластерное” ПО сторонних разработчиков.

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

Временные рамки восстановления базы данных

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

Oracle Database обеспечивает в высшей степени оперативное восстановление системы после сбоев. Однако предсказуемость важна не меньше чем скорость. Технология Fast-Start Fault Recovery, включенная в состав Oracle Database и пока не имеющая аналогов, автоматически определяет временной интервал, требуемый для возобновления работы системы. База данных самостоятельно выполняет расчет контрольных точек на протяжении всего периода восстановления, с тем чтобы уложиться в заданные временные рамки. Благодаря этому, процесс восстановления завершается быстро и в строго установленные сроки, создавая предпосылки для повышения уровня сервиса. Fast-Start Fault Recovery способна снизить время восстановления интенсивно используемой базы данных с нескольких десятков минут до менее чем десяти секунд.

 Защита от повреждения данных

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

Рисунок 3. Повреждения данных

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

Oracle Database 10g обладает усовершенствованным механизмом защиты данных. Соображения, вдохновившие разработчиков на большинство усовершенствований, связаны с экономическим аспектом хранения и резервирования информации. За последние двадцать лет емкость устройств хранения информации выросла на три порядка. В начале 80-х 200 мегабайтный диск считался пределом совершенства. Однако, как известно, предела у совершенства нет, и сегодня даже объем в 200 гигабайт не гарантирует винчестеру это почетное звание. А ведь не за горами диски емкостью 500 и даже 1000 гигабайт. Но нельзя забывать и об обратной стороне процесса. Одновременно с ростом емкости дисков падает стоимость одного мегабайта и к настоящему моменту она достигла отметки в несколько центов. Это превращает дисковые накопители в дешевое средство резервного копирования, способного составить конкуренцию магнитной ленте. Кроме того, у дисков есть дополнительное преимущество – они всегда доступны, без задержек реагируют на запросы и обеспечивают произвольный доступ к данным. Естественно, эти тенденции не могли остаться без внимания специалистов Oracle, которые не только переосмыслили, но и переработали стратегию резервирования, учтя современную динамику цен. Предоставив в распоряжение Oracle часть свободного дискового пространства, Вы сможете рассчитывать на сокращение времени копирования и восстановления данных с нескольких часов до нескольких минут. По сути, жертвуя малым и недорогим местом, Вы выигрываете в главном, избавляясь от угрозы дорогостоящей остановки.

 Защита от неисправностей накопителя

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

К счастью, этот сценарии претерпевает существенные изменения благодаря использованию функции Automatic Storage Management (ASM) пакета Oracle Database. ASM предлагает вертикально организованную файловую систему и менеджер томов, встроенные в ядро Oracle, в результате чего сокращается объем мероприятий по организации хранилища базы данных, характеризующегося более высоким уровнем доступности и не требующего приобретения, установки и обслуживания специализированных средств управления дисковыми массивами, предлагая прикладным программам уникальные возможности по работе с базой данных. Для достижения оптимального быстродействия ASM распределяет файлы по всему имеющемуся пространству, предусматривая возможность зеркалирования информации с целью защиты данных. ASM является развитием концепции SAME, придавшей исходной идее больше гибкости, поскольку она способна выполнять зеркалирование на уровне файлов базы данных, взамен привычного зеркалирования на уровне диска.

Однако более важен тот факт, что ASM сводит на нет традиционную сложность, касающуюся управления данными и пространством, максимально упрощая процесс настройки зеркалирования, добавления новых и изъятия ненужных устройств. Вместо того, чтобы возится с сотнями, а иногда и тысячами файлов, особенно в крупных хранилищах, администратор АБД, прибегнувший к помощи ASM, работает с крупно модульным объектом – группой дисков -, символизирующим собой набор накопителей, управляемых как единое логическое устройство. Функция автоматизированного именования и размещения основных файлов БД позволяет экономить время и гарантирует следование лучшим стандартам.

Собственный механизм зеркалирования ASM служит одним из возможных вариантов защиты от сбоев накопителя. Помимо обычного зеркалирование, включенного по умолчанию, доступно также тройное зеркалирование. При зеркалировании через ASM, повысить уровень защиты позволяет использование групп отказа (failure group). Группа отказа – это набор дисков, разделяющих общий ресурс, например, контроллер или дисковый массив, чей отказ не критичен для системы в целом. После задания группы, ASM начинает размещать резервные копии данных по другим группам с целью обеспечить их доступность и защиту в случае выхода из строя того или иного компонента дисковой подсистемы.

Кроме того, ASM поддерживает функцию Hardware Assisted Resilient Data, рассматриваемую нами в разделе "Предупреждение искажения данных", которая призвана улучшить защиту данных.

 Исключение человеческого фактора

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

Предохранение от ошибок

Лучший способ уберечься от ошибок – это открыть пользователю доступ только к той информации и службами, которые ему действительно нужны для выполнения работы. Пакет Oracle Database предлагает широкий выбор средств безопасности для контроля над запрашиваемыми данными путем авторизации [аутентификации] пользователей и последующего назначения им прав, строго соответствующих их служебным обязанностям. Более того, модель безопасности, реализованная в Oracle Database, предусматривает возможность ограничения доступа на уровне строк посредством функции Virtual Private Database, что еще заметнее усиливает изоляцию пользователя от “чужой” информации.

 Технология Oracle Flashback

Когда человек, обладающий соответствующими привилегиями, допускает ошибку, нужно иметь в своем арсенале инструмент, который мог бы ее исправить. В пакете Oracle Database 10g присутствует целый букет технологий, предназначенных для этих целей, под общим названием Flashback. Эти технологии совершили настоящий переворот в области восстановления данных. В прежние времена хватало нескольких минут, чтобы испортить базу данных, и требовалось несколько часов, чтобы ее воскресить. Благодаря Flashback теперь и то, и другое занимает считанные минуты. Но вместе с быстротой соседствует и поразительная простота. В наши дни, чтобы восстановить прежнее состояние базы данных, вместо долгой и запутанной процедуры достаточно отдать одну короткую команду. Flashback поддерживает SQL-интерфейс для быстрого разбора и коррекции ошибок пользователя. Технология предлагает детальный хирургически точный анализ и исправление локальных погрешностей, таких как неверно удаленный заказ клиента. Flashback в состоянии за короткий срок справиться и с более обширными повреждениями, например, такими как потеря всех заказов клиентов, сделанных ими за текущий месяц. Технология Flashback является фирменным знаком Oracle Database и позволяет выполнять откаты для объектов любого уровня, будь то строка, транзакция, таблица, табличное пространство или вся база данных целиком.

 Ретроспективные запросы

Благодаря механизму ретроспективных запросов (Flashback Query), впервые представленному в Oracle9i Database, администратор или обычный пользователь могут извлекать интересующие их данные на любой момент прошлого. Это мощное средство дает возможность прочесть и воссоздать информацию, стертую или измененную вследствие невнимательного или неосторожного обращения. Рассмотрим следующий пример:

Select * from EMPLOYEE as of ‘2:00 P.M.’ where …

Данная инструкция отображает содержимое таблицы EMPLOYEE по состоянию на 2 часа пополудни текущего дня. Разработчики, предусмотревшие в своих приложениях функцию автокоррекции ошибок, основанную на предложенном алгоритме, дадут в руки конечных пользователей инструмент для мгновенного и самостоятельного исправления ошибок, освободив, тем самым, администраторов БД, по крайней мере, от одной лишней заботы. Работать с Flashback Query чрезвычайно просто, поскольку база данных автоматически запоминает всю информацию, необходимую для реконструкции данных в определенный момент времени прошлого.

 Flashback Versions Query

Технология Flashback Versions Query служит для просмотра изменений, имевших место в базе данных на уровне строк. Являясь расширением языка SQL, она помогает находить различные версии конкретной записи таблицы в пределах указанного промежутка времени. Взглянем на следующий пример:

Select * from EMPLOYEE versions between ‘2:00 PM’ and ‘3:00 PM’ where …

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

 Flashback Transaction Query

Технология Flashback Transaction Query служит для просмотра изменений, имевших место в базе данных на уровне транзакций. Являясь расширением языка SQL, она помогает находить все изменения, произошедшие в БД с момента запуска той или иной транзакции. Взглянем на следующий пример:

Select * from DBA_TRANSACTION_QUERY where xid = ‘000200030000002D’;

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

 Flashback Database

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

Flashback Database предлагает новое решение старой проблемы. Суть его заключается в устранении последствий, вызванных нарушением целостности данных или ошибкой пользователя, путем быстрого отката базы данных к определенной временной отметке. Flashback ведет журнальные файлы, где фиксируются исходные варианты каждого измененного блока. Это чем-то напоминает непрерывную фотосъемку, с той лишь разницей, что ее объектом является не человек, а фрагменты база данных. Когда требуется восстановить работоспособность системы, Flashback “отматывает” журнальные файлы до момента, непосредственно предшествующего ошибке, и извлекает только те блоки, которые с тех пор изменились. Процедура настолько коротка, что период восстановления сокращается с нескольких часов до считанных минут. А где быстрота, там и простота. Чтобы вернуться к состоянию системы на 2:05 по полудни достаточно ввести одну-единственную команду:

FLASHBACK DATABASE to ‘2:05 PM’

Никаких тебе магнитных лент, бесконечного ожидания или запутанных манипуляций. По окончании работы Flashback можно открыть базу данных в режиме “только чтение” и проверить ее содержимое. Если по Вашему мнению, Вы оказались слишком далеко от цели, повторите попытку и так пока максимально не приблизитесь к желаемой точке. Механизм Flashback интегрирован с функцией Data Guard, поэтому путешествовать во времени Вы можете сразу с двумя базами данных: основной и резервной (подробности в разделе Data Guard).

Flashback Database - это своего рода пульт дистанционного управления базой данных, снабженный кнопками перемотки и отмены.

 Flashback Table

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

FLASHBACK TABLE orders, order_items TO TIMESTAMP (JUL-07-2003, 02:33:00);

Данная инструкция аннулирует все изменения, внесенные в таблицы orders и order_items начиная с указанного времени и до настоящего момента. Flashback Table выполняет эту операцию “на лету”, сохраняя любые ссылочные ограничения целостности между таблицами.

Flashback Table – это тоже пульт дистанционного управления с теми же кнопками, что и в предыдущем разделе, но для перемотки таблицы.

 Flashback Drop

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

Flashback Drop выполняет роль страховочной сетки при сбросе объектов в Oracle Database 10g. Когда пользователь удаляет таблицу, Flashback Drop помещает ее корзину. Объекты хранятся в корзине до тех пор, пока пользователь окончательно не сочтет их ненужными и пока в табличном пространстве, которому они принадлежат, остается свободное место. Корзина представляет собой виртуальный контейнер, где содержатся любые удаленные структуры. Открыв корзину, пользователь может достать оттуда “выброшенную” ранее таблицу вместе с сопутствующими ей объектами. Следующая команда возвращает таблицу employee и сопутствующие ей объекты в разряд активных:

FLASHBACK TABLE employee BEFORE DROP;

Flashback Drop – это своеобразная кнопка отмены сброса таблицы и связанных объектов.

 LOGMINER™ - SQL-анализатор журнальных файлов

Журнальные файлы Oracle - это россыпь разнообразных фактов из настоящей и прошлой жизни базы данных Oracle. Они служат тем источником, откуда черпается информация, используемая в процессе восстановления. В них отражаются любые изменения данных и метаданных, имевшие место в системе. LogMiner - это реляционный инстумент, который предназначен для чтения, анализа и интерпретации журнальных файлов на языке SQL. Анализ журнальных файлов посредством LogMiner позволяет отслеживать и контролировать (аудит) трансформацию данных, подготавливать информацию для планирования и настройки производительности системы, извлекать сведения, необходимые для отладки сложных приложений и восстановления удаленной (delete) информации.

 Защита от искажений информации

Искажение информации является следствием ошибок в ходе операций ввода-вывода. Предположим, что содержимое некой таблицы обновилось, и база данных инициирует операцию ввода-вывода для сохранения изменений на диске. Сначала она передает данные операционной системе, которая, в свою очередь, передает их файловой системе. Далее они попадают к менеджеру томов, тот пересылает их драйверу устройства, затем наступает очередь адаптера шины (Host-Bus-Adapter), затем по цепочке к контроллеру и, наконец, собственно диск. Ошибка или сбой любого звена в этой цепи грозит "перебросом" нескольких битов, что ведет к сохранению в базе данных испорченных байтов. Искажение может коснуться как управляющей информации, так и пользовательских данных, что, в любом случае, чревато серьезными последствиями для системы в плане функциональной готовности. Аналогичным образом, неисправность накопителя способна повредить файлы настолько, что потребуется восстанавливать всю базу данных.

 Hardware Assisted Resilient Data (HARD)

Hardware Assisted Resilient Data (HARD) - это комплексная программа, предназнвченная для предотвращения искажения данных до того, как это произойдет. Хотя искажение данных - событие довольно редкое, оно способно повлечь за собой катастрофические последствия не только для базы данных, но и для всего производства в целом. Реализуя алгоритм проверки данных на уровне устройств хранения информации, корпорация Oracle намеревается исключить возможность записи искаженных данных на физический носитель. Сквозной контроль, когда достоверность информации отслеживается на всех уровнях, начиная от приложения и заканчивая физическим устройством, является эксклюзивной технологией, предоставляемой Oracle совместно с компаниями-партнерами. После проверки, ПО Oracle дописывает к каждому блоку данных контрольную информацию, которая затем проверяется ПО накопителя. HARD препятствует появлению искажений на пути от базы данных к устройству хранения информации и, тем самым, исключает целый спектр ошибок, предотвратить которые доселе было невозможно. Технология RAID получила популярность в среде производителей аппаратного обеспечения благодаря высокой, с физической точки зрения, надежности хранения информации. HARD выводит безопасность данных на новую высоту, защищая не только их физическое представление, но и их целостность.

Впервые функция HARD увидела свет в составе пакета Oracle9i Database, откуда она в доработанном виде перебралась в Oracle Database 10g. Проверка стала более многосторонней и охватывает теперь все типы файлов и блоков, в том числе, файлы базы данных, оперативные журналы (online logs), архивные файлы и резервные копии. Кроме того, ASM позволяет использование HARD даже с неформатированными (raw - "сырыми") устройствами. В сопровождении HARD задействованы большинство основных производителей жестких дисков.

  Ретроспективное резервирование и восстановление (Flash Backup and Recovery)

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

ЗЗадача резервирования большой базы данных не относится к разряду простых. Большая база данных иногда насчитывает не одну сотню файлов, разбросанных по различным устройствам. Невнимательность при сохранение важного файла может негативно сказаться на работоспособности резервной копии. Зачастую о поврежденных файлах никто не подозревает до тех пор, пока они не понадобятся. Утилита управления восстановлением - Recovery Manager (RMAN) - это инструмент, управляющий процессами резервирования, восстановления и отката Oracle Database. Он создает и управляет политиками (policies) резервирования, а регистрируя любые операции резервирования или восстановления. По ходу резервирования все блоки данных подвергаются анализу на предмет искажений, дабы пресечь распространение ошибок при последующих операциях копирования. Особенно же важно то, что Recovery Manager гарантирует сохранность всех критичных файлов, а следовательно, и работоспособность полученной копии базы данных.

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

Recovery Manager из пакета Oracle Database 10g реализует более совершенный, нежели обычный, механизм резервирования и восстановления БД. RMAN автоматически копирует и извлекает информацию из Flash Recovery Area, представляющей собой область дискового пространства, куда заносятся все файлы и регистрируются все операции, относящиеся к процедуре восстановления данных. Учитывая новые экономические аспекты хранения информации, обсуждавшиеся нами чуть ранее, замена магнитной ленты на диск должна ускорить процесс резервирования. Но что более важно, она должна, если возникнет необходимость, существенно сократить время восстановления системы.

В обязанности Recovery Manager входит управление содержимым Flash Recovery Area. RMAN автоматически создает в ней копии нужных файлов и занимается распределением свободного места. По мере того, как архиватор заполняет Flash Recovery Area журнальными файлами, RMAN автоматически удаляет или переписывает на магнитную ленту потерявшие актуальность данные и устаревшие версии журнальных файлов. Если Вы при помощи параметра RETENTION POLICY установите семидневное окно между резервированиями, RMAN сохранит все копии файлов, необходимые для отката базы данных к любому моменту в пределах недели. Если потребуется восстановить состояние системы, датируемое более ранним числом, RMAN считает нужную информацию с магнитной ленты. Enterprise Manager поддерживает полную интеграцию с Flash Backup and Recovery.

Возможность инкрементального копирования неизменно реализуется RMAN с тех самых пор, как средство впервые появилось в составе Oracle8 Database. Данный механизм предполагает копирование только тех блоков, которые были созданы или изменены с момента последнего резервирования. Oracle Database 10g позволяет увеличить скорость операции путем составления списка изменившихся блоков. Oracle Database 10g фиксирует их физические адреса, а RMAN автоматически использует эту информацию для определения блоков, подлежащих добавочному копированию, и их прямой выборки. Эти блоки затем могут быть вставлены в образ системы, полученный на предыдущей итерации, что способствует сокращению процедуры восстановления. Стратегия резервирования, основанная на принципе добавочного копирования минимизирует время, необходимое для восстановления данных. Сделав механизм инкрементального копирования частью своей стратегии, Вы сможете ускорить процесс ежедневного резервирования, снизить нагрузку на сеть во время удаленного копирования, восстанавливать незарегестрированные изменения, уменьшить объем архивируемой информации и сократить время, требуемое на восстановление базы данных.

В Oracle Database 10g присутствует много любопытных усовершенствований, как то:

• Сжатие архивных и резервных файлов
• Автоматический возврат к предыдущей копии системы, в том случае, если процедура восстановления выявила отсутствие или повреждение того или иного блока
• Автоматическое восстановление от предыдущей по времени точки восстановления - восстановление через resetlogs.
• Автоматическое создание новых файлов в процессе восстановления
• Автоматический отказоустойчивый канал для резервирования и восстановления
• Автоматический откат табличных пространств к определенной временной отметке
• Единая для базы данных (full DB) команда "begin backup" для более быстрого зеркального расщепления (mirror split)
• Улучшенный механизм параллельного восстановления (в два - четыре раза)
• Переименование табличных пространств
• Proxy Backup (от третьих фирм) для архивных файлов
• Уменьшение временного окна резервирования
• Межплатформенный перенос табличных пространств

  Защита от повреждений сайта

Средства защиты данных обеспечивают сохранность информации в критических ситуациях, когда нормальное функционирование сайта невозможно в течение продолжительного промежутка времени. К таким ситуациям относятся разрушение файлов, стихийные бедствия, сбои связи и энергоснабжения и даже терроризм. Oracle Database предлагает целый спектр средств защиты данных, которые позволяют создавать и обслуживать локальную или удаленную копию основной системы. Если произойдет разрушение данных или катастрофа, пользователи смогут обратиться за нужной информацией к резервной БД.

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

 Data Guard

Data Guard отводиться роль краеугольного камня в любой стратегии восстановления Oracle Database. Data Guard дает возможность подготовить и настроить дубликат основной базы данных, который может располагаться как на другом конце света, так и в соседней комнате. В Data Guard, наряду с усовершенствованиями, призванными автоматизировать выполнение наиболее сложных задач, присутствуют функции слежения, оповещения и управления. Благодаря Data Guard Ваша база данных без труда переживет крах информационного центра. Поскольку к резервной БД (standby database), коль скоро должна быть обеспечена отказоустойчивость (failover), допускается динамическое добавление новых серверов, работа Data Guard в среде Grid остается прозрачной для приложений.

Рисунок 4. Архитектура Data Guard

 Режим Redo Apply

Data Guard в режиме Redo Apply оперирует с копией основной базы данных, называемой в данном случае физической резервной БД (physical standby database), и поддерживает ее синхронизацию с производственной базой данных. Журнальная информация передается из исходной базы данных в резервную, где накладывается на нее при помощи механизма восстановления. На физическом уровне резервная база данных полностью идентична основной, несмотря на то, что временами случается некоторое запаздывание. Запасная БД, открытая в режиме "только чтение", может снять с главной часть нагрузки при генерации отчетов. Резервирование данных также можно перепоручить запасной БД, поскольку его результат без каких-либо ограничений подойдет для восстановления основного экземпляра.

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

 Режим SQL Apply

В режиме SQL Apply Data Guard берет журнальные файлы Oracle, преобразует их в транзакции SQL, которые затем применяет к резервной базе данных. Хотя аппаратная реализация резервной базы данных, называемой в этом случае логической резервной БД (logical standby database), не всегда совпадает с оригиналом, с логической точки зрения она является ее полной копией и способна поддерживать работу пользователей не хуже основной. Параллельно с SQL-операторами резервный экземпляр может выполнять и другие операции, при этом его физическая структура не обязательно должна повторять структуру исходного экземпляра. Например, логическую резервную БД можно включить в систему принятия решений, оптимизировав процесс генерации отчетов при помощи дополнительных индексов и наглядных представлений, не существующих в оригинале.

Режим SQL Apply разработан в первую очередь для защиты данных. В этом режиме Data Guard сравнивает содержимое журнальных файлов с содержимым логической резервной БД, тем самым оберегая его логическую целостность. Таким образом, наличие логической резервной БД гарантирует защиту Ваших данных практически от любых искажений.

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

  Передача без потерь журнальной информации

Физическая и логическая резервные БД используют одни и те же службы для получения журнальной информации. Обычно журнальные файлы пересылаются из основной базы данных в резервную сразу же после создания. Data Guard позволяет обновлять эти файлы одновременно с передачей их в резервную базу данных. Это означает, что Вы полностью застрахованы от потери ценной информации. Если что-нибудь случится с главным сайтом, все журналы, необходимые для регистрации транзакции, будут доступны через запасную базу данных.

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

  RealTime Apply и Flashback Database

В Oracle Database 10g механизм Data Guard пополнился функцией Real Time apply и возможностью объединения с Flashback Database. Благодаря новой функции наложение журнальной информации на резервную базу данных происходит сразу же по получения файла, а не после архивации его предыдущей версии. Вследствие этого, копия основной базы данных оказывается максимально приближена к оригиналу, что способствует генерации отчетов в реальном масштабе времени. Кроме того, сокращается время переключения между экземплярами, что, в свою очередь, ведет к сокращению длительности плановых и внеплановых простоев. В распоряжении администратора также имеется функция Flashback Database, которой он может пользоваться для быстрого отката основной и резервной баз данных к определенному состоянию с целью исправления ошибок пользователя. Если АБД примет решение переключится на резервный экземпляр, но обнаружит, что ошибочная информация уже проникла туда при помощи Real Time Apply, ему достаточно инициировать откат и вернуть экземпляр к его исходному состоянию. Симбиоз описанных функции раз и навсегда даст ответ на вопрос, стоящий перед некоторыми читателями: как найти компромисс между оперативностью обновления запасной базы данных и задержкой записи переданных файлов, препятствующей распространению ошибок из оригинала в копию.

  Data Guard Broker

Data Guard снабжен удобным графическим интерфейсом (GUI), называемым Data Guard Manager, который интегрирован в Enterprise Manager. Также доступен интерфейс типа командной строки для контроля, автоматизации и управления компонентами Data Guard. Одно щелчка "мыши" достаточно, чтобы переключить обработку данных с основного экземпляра на один из двух возможных типов резервных БД. Data Guard Manager облегчает администраторам задачу организации и управления резервной базой данных.

Упрощение таких операций, как переключение БД и смена режимов существенно снижает вероятность ошибки.

  Устранение плановых простоев

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

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

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

  Устранение простоев, вызванных реорганизацией данных

Рисунок 5. Реорганизация данных

  Преобразование схемы и данных “на лету”

Oracle Database способна выполнять множество служебных операций, не нарушая обычного режима работы базы данных и не мешая пользователям обновлять и получать интересующую их информацию. Добавление, перестроение или дефрагментация индексов осуществляется в оперативном режиме параллельно с операциями чтения и записи конечных пользователями. Тоже самое касается перемещения и дефрагментации таблиц. Их можно переопределять (redefined), изменять тип таблиц, добавлять, удалять и переименовывать столбцы, корректировать параметры хранения, и делать все это без отрыва пользователей от производства. В Oracle Database 10g, помимо привычных уже возможностей, предусмотрены:

• поддержка простого клонирования индексов, разрешений (grants), ограничений (constraints) и прочих характеристик таблицы
• оперативное (online) преобразование данных типа long к типу LOB
• использование вместо первичных ключей уникальных индексов

Поддерживается динамическое обновление хранимых процедур Java и PL/SQL, при этом Oracle берет на себя “руководство” всеми отношениями с целью грамотной интеграции новых процедур в базу данных без ущерба для пользовательских операций. В Oracle Database 10g эта функция претерпела заметные улучшения. Теперь для большинства табличных преобразований не придется перекомпилировать хранимые процедуры, связанные с изменяемой таблицей.

  Секционирование таблиц и индексов

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

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

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

  Динамическое подключение ресурсов

Oracle Database сохраняет курс на развитие возможностей динамической реконфигурации, которая разрешает обновлять состав оборудования “на лету”. Oracle Database поддерживает динамическое изменение аппаратной конфигурации, в том числе:

• добавление и удаление процессоров в/из сервера SMP
• добавление и удаление узлов RAC-кластера
• динамическое изменение объема разделяемой памяти и управление ею “на лету”
• добавление и удаление дисков во время работы базы данных
• автоматическое перераспределение нагрузки по дискам базы данных
• перемещение файлов “на лету”

Все перечисленное выше гарантирует модернизацию системы без лишних затрат и увеличение емкости БД в случае необходимости, что является фундаментальным требованием архитектуры Grid.

  Устранение простоев, связанных с модернизацией системы

Рисунок 6. Модернизация системы

  Круговая установка патчей

Обновление программного обеспечения узлов RAC-кластера осуществляется Oracle Database по круговой схеме. Ниже приводится общее описание методики.

Рисунок 7. Круговая установка патчей

Предположим, система RAC работает в нормальном режиме, когда все узлы кластера задействованы в обработке транзакций клиентов базы данных (левый верхний угол на рис. 7). Применение патча начинается с того (шаг 1), что приостанавливается работа экземпляра, служащего объектом процедуры (в нашем случае это экземпляр 1), затем (шаг 2) при помощи специального средства Oracle (opatch) выполняется обновление "замороженного" экземпляра, после чего (шаг 3) пропатченный узел перезапускается и возвращается в состав кластера. Теперь в системе RAC имеется узел, по уровню технической готовности превосходящий остальные узлы кластера.

Система может работать в таком промежуточном [смешанном] режиме столько времени, сколько потребуется на то, чтобы выяснить, помогла ли установка патча решить первоначальные и не стала ли она источником новых проблем. Затем процедура повторяется для каждого из оставшихся узлов до тех пор, пока не будут пропатчены все узлы, входящие в состав кластера. По завершении обновления все узлы оказываются оснащены одной и той же версией программного обеспечения. При желании утилита opatch позволяет совершить "откат" кластера к предыдущему состоянию. Если работа обновленного экземпляра носит неустойчивый характер, необходимо деинсталлировать патч, ставший причиной нестабильности, либо откатиться назад для предупреждения отказа всего кластера. Процедура отката практически ничем не отличается от процедуры установки, за тем лишь исключением, что opatch не ставит патч, а удаляет его.

  Круговая замена программного обеспечения

В Oracle Database 10g модернизация программного обеспечения базы данных и установка патчей осуществляется по круговой схеме с помощью механизма Data Guard в режиме SQL Apply. Ниже приводится описание методики.

Рисунок 8. Организация резервной базы данных

После организации резервной базы данных и настройки Data Guard для отражения в ней изменений, имеющих место в основной БД, производится обновление программного обеспечения резервного экземпляра.

Рисунок 9. Модернизация резервной базы данных

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

Рисунок 10. Смена ролей

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

Введя поддержку круговой замены программного обеспечения, Oracle помогла АБД существенно сократить продолжительность периодов профилактики, а предприятиям – наладить круглосуточную бесперебойную работу своих баз данных семь дней в неделю.

  Архитектура максимальной готовности (MAA)

Использование испытанных методов – вот залог создания грамотной инфраструктуры IT. Просто технологии не достаточно. Maximum Availability Architecture (MAA - Архитектура максимальной готовности) – это выверенная комплексная программа строительства высокодоступных систем. Предприятия, взявшие за основу своих систем структуру, предложенную MAA, получают возможность быстро и эффективно разрабатывать и развертывать приложения, полностью соответствующие их производственным потребностям. MAA включает в себя конкретные схемы и рекомендации по составу оборудования, которые могут быть всесторонне разобраны и проверены на практике для достижения максимальной готовности и надежности системы. В программе детально изложены и подробно рассмотрены варианты совместного использования ключевых функций Oracle Database, обеспечивающих высокую готовность, таких как Real Application Clusters, Data Guard, Recovery Manager и Enterprise Manager. В ней также приводится примерная конфигурация и комплектация других важных составляющих высокодоступных систем: серверов, устройств хранения информации, сетевого оборудования и сервера приложений. Каждый из перечисленных компонентов уже представляет собой готовое решение, однако собранные вместе и объединенные в соответствии с архитектурой MAA, они образуют систему, характеризующуюся невероятным уровнем готовности и надежности.

В настоящее время идет доработка руководства по MAA и в ближайшем будущем оно станет неотъемлемой частью документации к Oracle Database 10g. Дополнительные сведения о MAA Вы можете узнать по адресу http://otn.oracle.com/deploy/availability/htdocs/maa.htm

  Заключение

Как основной компонент IT-инфраструктуры Oracle Database обладает всем необходимым, чтобы обеспечить доступность и готовность наиболее важных приложений. Революционные новшества пакета Oracle Database 10g гарантируют доступность Ваших данных в любое время из любой точки мира, а поддержка технологии Grid является страховкой того, что стоимость развертывания базы данных и адаптации ее к нуждам производства не превысит запланированной суммы.