В октябре 2006 года в г Сан-Франциско на ежегодной конференции Oracle Open World президент компании Oracle Ларри Эллисон объявил о начале бетта тестирования новой версии флагманского продукта компании – СУБД Oracle 11g. Выход версии планируется в 2007 году. Она будет поддерживать много новых функций, обеспечит большее быстродействие, обеспечит более высокую защиту данных и надежность работы приложения.

Все новые возможности 11g можно разделить на несколько групп:

1. Развитие СУБД Oracle как платформы для GRID вычислений. С этой целью был реализован ряд новых возможностей в области обеспечения высокой надежности и устойчивости работы (High Availability), в области облегчения управления СУБД и повышения ее самоуправляемости, реализован ряд новых возможностей для ускорения работы системы
2. Управление информацией. С этой целью была улучшена работа со всеми типами данных (включая реализацию Native XML), реализован механизм эффективной работы с файлами, хранимыми в СУБД, а не в файловой системе (SecureFiles), а также реализованы механизмы для поддержки жизненного цикла информации – ILM (Information Lifecycle Management)
3. Разработка и тестирование приложений. С этой целью были реализованы новые подходы к разработке и модификации пользовательских приложений СУБД, позволяющие выполнять работы по модификации приложений СУБД без остановки их работы. Новые режимы работы Standby (резервной) базы позволят ее использовать для тестирования работы приложений, самой СУБД, отдельных SQL операторов и т д. Все это позволит значительно снизить время плановых простоев системы.

Развитие СУБД Oracle как платформы для GRID вычислений

Начиная с версии 10g компания Oracle позиционирует свою СУБД как платформу для GRID вычислений. Концепция GRID вычислений достаточно проста, понятна, гибка и позволяет экономить средства предприятия [1]. Поэтому в последнее время наблюдается постепенное внедрение этой архитектуры в IT инфраструктуру.

Вскоре ожидается появление первых GRID с более чем тысячью процессоров. Сегодня многие крупные информационные системы используют от 100 до 300 процессоров. Реализуются как малые кластеры, состоящие из нескольких больших SMP машин (например, 2 узла по 64 процессора или 4 узла по 32 процессора), так и большие кластеры, состоящие из множества мелких элементов (например, 32 узла по 4 процессора). Для российских заказчиков тестируются конфигурации с 1,5 сотней процессоров.

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

Уже сегодня Oracle 10g позволяет объединить в кластер до 64 узлов. В Oracle 11g эта цифра удвоится. И каждый узел может иметь множество процессоров и ядер. Таким образом суммарная вычислительная мощность такой GRID может превысить вычислительную мощность серьезных mainframe машин. Кстати, уже сегодня Oracle использует для TPC тестов двухтеррабайтный буферный кэш, так что растет не только процессорная мощность GRID, но и ее суммарная память.

Одним из примеров удачного внедрения GRID технологии является хорошо известный многим Интернет магазин Amazon.com. Изначально хранилище данных Amazon.com было реализовано на основе нескольких SMP машин, но затем, с целью повышения мощности и снижения стоимости системы, ее решили перевести на платформу GRID. В качестве элементов GRID использовались четырехпроцессорные компьютеры с OC Linux, на которых был установлен Oracle 10g RAC и Oracle ASM. Архитектура системы представлена на рисунке 1.

Система состоит из нескольких блоков:

• извлечение данных из исходных систем
• интеграция, преобразование и денормализация данных
• блок обработки запросов и анализа данных
• блок доступа к данным и публикации.

Извлечением данных занимаются так называемые extract серверы. Далее они передают данные в блок интеграции и преобразований. SMP машины блока интеграции и преобразований были заменены GRID из 8 узлов. Объем данных, хранимых на этом этапе – 12 терабайт. SMP машины блока обработки запросов и анализа были заменены на GRID из 16 узлов. Объем данных хранилища – 66 терабайт. Данные extract серверов поступают в первый GRID (это Stage область), после чего загружаются в хранилище на второй DRID.

После реализации такой линейки из 8+16=24 узлов выяснилось, что стоимость такой инфраструктуры, благодаря использованию дешевых элементов, более чем в 2 раза ниже стоимости предыдущей системы. Поэтому было принято решение реализовать вторую такую же линейку из 8+16 узлов, которая будет дублировать работу первой линейки. Теперь данные extract серверов поступают как на первую, так и на вторую линейку серверов и в компании всегда существует 2 одинаковые версии хранилища. Одна из них является основной, а на вторую можно переключиться в случае сбоя. Такая архитектура позволила отказаться от частого копирования активных оперативных данных. Причем суммарная стоимость такой продублированной архитектуры оказалась ниже стоимости старой системы.

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

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

Список новых возможностей Oracle 11g для сохранения работоспособности приложений при внесении изменений изображен на рисунке 2.

Коротко рассмотрим эти возможности.

1. Создание среды для тестирования

В Oracle 10g реализованы 2 варианта создания резервной базы – логический и физический standby. Физический standby работает быстро, но при использовании standby базы для операций чтения ее восстановление приостанавливается. Логический standby имеет ряд ограничений на типы данных, используемые в БД (например, нельзя использовать LOBs).

Поэтому в Oracle 11g реализовано 2 новых типа standby базы: Phisical Standby with Real-Time Query и Snapshot Standby. Phisical Standby with Real-Time Query похож на старый Физический standby, однако в то время, когда standby база открыта на чтение, она продолжает догонять основную БД (восстанавливается на физическом уровне). Т е одна и та же база может использоваться как для защиты от катастрофических сбоев, так и для разгрузки основной базы и для тестирования read only приложений. Так на ней можно печатать отчеты, выполнять бэкапы, заниматься аналитикой и Data Mining.

Snapshot Standby позволяет использовать резервную базу для тестирования новых приложений и настройки старых приложений. В то время, как snapshot standby база догоняет основную базу, на ней можно тестировать приложения, которые читают и меняют данные в БД. После возврата из режима Snapshot Standby в режим Phisical Standby, все изменения, сделанные тестируемым приложением, будут аннулированы.

2. Захват и воспроизведение нагрузки

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

Функция Database Replay позволяет записать (как на видеомагнитофон) информации обо всем, что происходит с эксплуатационной СУБД, сохраняя информацию об одновременности выполнения операций. Далее эта “запись” проигрывается в реальном времени на тестовой БД или на Snapshot Standby БД, где ДБА может исследовать работу СУБД.

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

Например, воспроизведение записанных SQL операторов на тестовой БД с новой версией СУБД Oracle, позволит выявить SQL операции, производительность которых снизилась, и вызвать программу Tuning Advisor для их оптимизации с учетом возможностей новой версии СУБД. Для этого в Oracle Enterprise Manager (OEM) реализованы дополнительные экраны, где видны результаты сравнения производительности SQL.

3. Выполнение изменений в приложениях без их остановки

Большие важные приложения часто бывают недоступны в течение десятков часов из-за установки новых версий этих приложений. Oracle 11g вводит новое революционное решение, позволяющее выполнять смену версии приложения не останавливая работу этого приложения. Старая и новая версии приложения могут работать одновременно. На рисунке 3 приведен пример двух версий приложения. В старой версии было всего 2 колонки: имя и телефон. В новой версии имя, фамилия, код города и телефон хранятся и отображаются в отдельных колонках. Это потребовало как изменения структуры таблицы, так и изменения процедур, формирующих графический интерфейс. Оба приложения позволяют просматривать и модифицировать данные и могут какое-то время работать одновременно (пока старая версия не будет закрыта).

Для реализации возможности одновременной работы старого и нового приложения в Oracle 11g были введены 3 новых понятия: редакция (Edition), Editioning View (редактируемое представление) и CrossEdition Trigger (межредакционный триггер).

Понятие редакции (Edition) обеспечивает существование в БД нескольких версий программных объектов, таких как PL/SQL функции и процедуры, триггеры, views, синонимы и т д. Скрипты патчей и апгрейдов могут вносить изменения в новую редакцию (группу объектов новой редакции), в то время как старая редакция не меняется. При этом изменения не видны пользователям старой редакции. После того, как все изменения завершены и новый код протестирован, можно активизировать новую редакцию. Т е новая версия всех объектов станет актуальной.

Понятие редакции не применимо к таблицам. Чтобы могли сосуществовать 2 версии одной таблицы используются Editioning Views. Т е мы создаем новую, измененную версию таблицы и “вешаем” над ней Editioning View, который прячет все изменения в структуре таблицы и представляет новую таблицу, как старую Editioning View создается в старой редакции и там не видны изменения структуры, которые видны в процедурам новой редакции. Т е старая редакция работает не с таблицей, а с Editioning View.

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

Кстати в Oracle 11g зависимые объекты не приобретают статус INVALID и не перекомпилируются при добавлении новых процедур и функций в пакет.

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

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

В Oracle 11g эта работа будет автоматизирована. При возникновении той или иной ошибки Oracle знает, какая информация и какие файлы надо отправить в службу технической поддержки. Он создает для возникшего инцидента специальную папку и помещает туда всю необходимую для тех поддержки информацию, включая файлы трассировки и журналы, информацию о предшествующих инцидентах, информацию о проблемах с другим ПО (например, был сбой сервера приложений). Если надо, ДБА будет предложено добавить в эту папку дополнительную информацию. Администратор может контролировать состав пакета об инциденте через окно Support Workbench в OEM. Далее информация упаковывается и автоматически или вручную отправляется в службу технической поддержки.

5. Online Hot Patching

В Oracle 11g можно будет применять некоторые (в основном критичные и отладочные патчи) на ходу без остановки работы экземпляра Oracle c БД. Можно также будет включать/выключать, деинсталлировать специализированные патчи без остановки работы.

6. Новые советники (advisers)

В Oracle 11g появился ряд новых советников, упрощающих работу администратора БД. Это:

• Partitioning Adviser
• Reparing Adviser
• Streams Performance Adviser
• Space Management Adviser

Наиболее интересен Reparing Adviser. Дело в том, что при возникновении тяжелых сбоев в работе СУБД Oracle администратор оказывается в тяжелой ситуации. За короткое время он должен понять причину сбоя, выбрать и оценить способы восстановления. Для этого ему надо собрать и оценить большой объем информации. Все это в состоянии стресса. Как правило сам процесс восстановления БД после сбоя занимает 10-15% времени простоя, остальное время уходит на сбор и анализ информации.

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

Администратор должен выбрать способ лечения из предложенного списка и после чего Reparing Adviser выполнит восстановление БД. Для выбора наиболее эффективного способа лечения Reparing Advisor анализирует всю совокупность возникших ошибок и рекомендует только выполнимые варианты лечения проблемы.

7. Прочее

Среди прочих интересных возможностей Oracle 11g следует отметить:

• возможность отката завершенных транзакций
• возможность выполнения запроса в прошлое (Flashback query) для указанных таблиц на неограниченное время в прошлое – механизм Flashback Data Archive
• два новых типа секционирования таблиц – Interval partitioning и Reference partitioning и возможность смешивать различные типы partitioning для таблицы (compsite partitioning)
• кэширование результатов и промежуточных результатов запросов на сервере и на клиенте (Server Result Cache и OCI Client Result Cache)
• сжатие данных для DSS и OLTP систем, сжатие и кодирование данных всего tablespace
• поддержка семантических сетей (Semantic Web)
• оптимизация работы RAC и DataGuard
• повышение уровня самоуправляемости Oracle 11g

Литература

1.обратно

Платформа для коммерческих сред Grid //Открытые системы, 2003, N 12