Сообщений 0 
Оценка 0 
Оценить 
| Сообщений 0 Оценка 0 Оценить
|
Основная задача нашей книги — помочь работающим с Oracle специалистам начального или среднего уровня разобраться с системами Oracle и оптимизировать их. Здесь рассматриваются также многие темы, интересные для экспертов, но все-таки главная цель — помочь специалистам, которые уже отчаялись найти решение и ждут простых советов, помогающих улучшить производительность. Книга ставит перед собой одну простую цель: вооружить вас арсеналом советов (на разные случаи), которые позволят вам ускорить работу системы.
В предыдущем издании книги глава 1 представляла собой всеобъемлющее обсуждение оптимизации Oracle для тех, у кого нет времени прочитать всю книгу. Многие потом жаловались, что эти сведения дублировались в других главах, или, что еще хуже, прочитывали только первую главу и думали, что они уже разбираются в оптимизации. Другие, прочитав один-единственный из приведенных в ней более чем 1000 советов (и больше уже не читая книгу), заявляли, что вся она основана только на проценте удач. Нет ничего, что было бы настолько далеко от истины. Я всегда ищу способ как можно лучше помочь вам и развеять подобные мифы.
Поэтому первая глава настоящего издания посвящена тому новому, что появилось в Oracle9i. Остальные главы постепенно усложняются и изобилуют советами, которые помогут вам преодолеть трудности, связанные с оптимизацией. Вы получите такую информацию, которой больше нигде не найдете.
Если вам все-таки нужен унифицированный метод или всеобъемлющий способ оптимизации, я подготовил две таких главы для тех, у кого нет времени на чтение всей книги. В частности, глава 14 посвящена Statspack — замечательному инструментальному средству, которое включает большинство стандартных сценариев, используемых экспертами для оптимизации системы. Основное внимание уделяется тестированию перезаписи. Глава 5 посвящена Enterprise Manager — инструментальному средству будущего, которое поддерживает графический способ оптимизации системы, позволяя просматривать и оптимизировать несколько систем в одном окне.
Тем, кто хочет получить максимальный эффект от прочтения книги, следует начать с новых свойств Oracle9i. В последующих главах эти свойства рассматриваются более углубленно, и при этом основное внимание уделяется оптимизации производительности.
Темы данной главы:
Oracle9i — новейшая версия РСУБД Oracle. Она поступает в виде выпусков 1 и 2. В Oracle9i процессор базы данных содержит новые свойства и возможности, и, кроме того, улучшены функциональные возможности многих поддерживающих продуктов, например RMAN и OEM. Прочтя данную главу, вы сможете воспользоваться преимуществами этих новых функциональных возможностей.
| ПРЕДУПРЕЖДЕНИЕ В связи с новизной этих возможностей вам следует проявлять осторожность при их использовании и проводить полное тестирование, пока вы не будете уверены, что это не вызовет каких-либо проблем в базе данных. Если у вас есть доступ к Metalink, выясните наличие проблем у того свойства, которое вы готовитесь использовать. Google.com (весьма обширный) — еще один полезный адрес для поиска свежей информации о свойствах и функциональных возможностях Oracle. |
Oracle9i содержит ряд новых административных свойств, которые существенно облегчают жизнь администратора БД, в частности:
Рассмотрим каждое из этих свойств более подробно.
В большинстве случаев миграция в Oracle9i выполняется довольно просто. При миграции из Oracle версии 8 или 8i для перемещения базы данных необходимо выполнить всего несколько сценариев. Oracle9i поддерживает миграцию из окружения Oracle7 только в том случае, если вы работаете в Oracle версии 7.3.4. Миграция из Oracle 7.3.4 требует применения Database Migration Assistant или утилиты mig. Oracle9i требует больше пространства и памяти, чем предыдущие версии; перед проведением миграции убедитесь, что эти требования удовлетворяются.
| ПРИМЕЧАНИЕ Oracle9i требует больше пространства и памяти, чем предыдущие версии. |
В Oracle9i уже нет утилиты Server Manager (svmgrl). Теперь администрирование базой данных производится через SQL*Plus или ОЕМ. Кроме того, нет и Connect Internal. Для выполнения административных задач в базе данных (например, выключения или запуска), необходимо зарегистрироваться с помощью учетной записи, которой назначена привилегия SYSDBA, используя синтаксис регистрации AS SYSDBA. Ниже приводится пример регистрации по учетной записи SYS как SYSDBA с помощью SQL*Plus (но не следует входить в систему таким образом — сделайте это в интерактивном режиме, иначе ваш пароль будет показан как команда ps-f):
sqlplus "sys/password as sysdba" |
Есть и другие варианты синтаксиса регистрации, которые зависят от типа соединения сервер/база данных: локальное или удаленное. В настоящее время Oracle9i поставляется с новой привилегией GRANT ANY OBJECT PRIVILEGE, которая облегчает эту возможность. Поэтому правильное имя привилегии — GRANT ANY OBJECT PRIVILEGE. Она имеет следующий синтаксис:
GRANT grant any object privilege TO user; |
| ПРИМЕЧАНИЕ Разумеется, при предоставлении этой привилегии другим учетным записям следует проявлять осторожность, так как она дает большие права. |
После создания базы данных с помощью Database Creation Assistant (DBCA) появится приглашение ввести новые пароли SYS и SYSTEM этой БД. Кроме того, большинство пользователей/схем, созданных DBCA, кроме SYS и SYSTEM, будут заблокированы. Учтите также, что теперь SYS может предоставлять привилегии любому объекту БД. Вам больше не надо предоставлять привилегию SYS, чтобы разрешить ей управлять предоставлением привилегий вашим объектам.
Oracle9i предлагает автоматическое управление файлом инициализации базы данных в виде файла серверных параметров (SPFILE). Вместо редактирования файла инициализации БД при необходимости внести изменения, следует просто ввести команду alter system, которая изменяет значение в SPFILE. При изменении динамических параметров есть следующие варианты выбора: 1) динамически изменить значение для текущего экземпляра, но оставить SPFILE в покое; 2) изменить его в SPFILE и не трогать экземпляр; 3) изменить значение параметра и в экземпляре, и в SPFILE. Если параметр статический, как правило, изменяется только SPFILE. Ниже приводится пример изменения параметра и в SPFILE, и в экземпляре:
Alter system set open_cursors=1000 scope=both; |
Обратите внимание на слово SCOPE: это ключ. В таблице 1.1 приводятся три опции SCOPE.
| Опция | Описание |
|---|---|
| Memory | Вносит изменения только в экземпляр. Если параметр не динамический, возвращается сообщение об ошибке. |
| Spfile | Вносит изменения только в SPFILE |
| Both | Вносит изменения и в экземпляр, и в SPFILE. Если параметр статический, возвращается сообщение об ошибке. |
Команда alter system reset позволяет переустановить параметр в значение по умолчанию. Кроме того, можно открыть и прочитать SPFILE, потому что в нем показывается большинство настроек. Не следует вручную изменять SPFILE с помощью каких-либо текстовых редакторов, потому что Oracle включает информацию в верхний и нижний колонтитулы SPFILE для обеспечения его целостности.
Команда create pfile from spfile позволяет преобразовать SPFILE в текстовый файл параметров. И наоборот, create spfile from pfile позволяет преобразовать текстовый файл параметров в файл SPFILE. Если у вас работает RAC, Oracle9i позволит разным экземплярам совместно использовать один и тот же файл параметров инициализации (SPFILE или текстовый). В одном и том же файле параметров можно определять глобальные параметры для всех баз данных или конкретные параметры для определенной БД (подробнее см. в главе 4).
| ПРИМЕЧАНИЕ Если вы не можете выяснить, почему система не использует значение из файла init.ora, вероятно, его переписал SPFILE. |
Введение в Oracle9i автоматического управления отменой (Automatic Undo Management — AUM) упростило администрирование сегментами отката. Это свойство возлагает ответственность за назначение сегментов отката и управление ими на Oracle9i. Его довольно легко использовать. Выполните следующие шаги:
При автоматическом управлении отменой Oracle устанавливает размер и создает сегменты отката. Как правило, система создает 10 сегментов UNDO и добавляет дополнительные сегменты UNDO в соответствии с требованиями системной нагрузки (подробнее см. в главе 3).
| ПРИМЕЧАНИЕ Будьте осторожны с автоматическим управлением отменой в более ранних версиях Oracle 9.0. (9.0.1 и 9.0.2). Ошибка в Automatic Undo Management может помешать запуску базы данных, и придется восстанавливать ее. |
Сколько раз вы запускали групповой процесс SQL*Plus или импортировали данные в таблицу баз данных, но загрузка терпела неудачу из-за нехватки места? Подобный сбой загрузки может стать серьезной проблемой. Как правило, загрузка производится в ограниченное окно. Часто ошибки, вызванные нехваткой места, происходят в середине или ближе к концу загрузки, что создает большие проблемы, поскольку уже не хватает времени на перезапуск загрузки. На помощь приходит Oracle9i с возобновляемым назначением пространства.
При возобновляемом назначении пространства некоторые ошибки, связанные с нехваткой места, приводят к приостановке сеанса. Тогда проблему решает администратор БД. Возобновляемое назначение пространства можно использовать для приостановки сеанса при следующих обстоятельствах:
Большинство команд DML в Oracle могут использовать свойство возобновляемого назначения пространства, хотя налагаются некоторые ограничения относительно объектов в табличных пространствах, управляемых словарем. Даже параллельная обработка может использовать преимущества этого свойства. Кроме того, утилита Oracle Import и утилиты SQL*Loader имеют новые параметры, также позволяющие применять это свойство.
Для того чтобы использовать возобновляемое назначение пространства, необходимо включать его для каждого сеанса с помощью команды alter session enable resumable. По умолчанию, если условие пространства не исправляется в течение двух часов, транзакция заканчивается неудачно. При необходимости можно сконфигурировать большее или меньшее значение. После включения этого свойства Oracle автоматически обнаруживает условие пространства, приостанавливает сеанс и вносит в журнал предупреждающих сообщений запись об этом. Кроме того, представление DBA_RESUMABLE ведет запись всех текущих приостановленных сеансов. Когда администратор БД решит проблему с пространством, приостановленный сеанс автоматически возобновит работу в точке приостановки.
Oracle также поддерживает событие системного триггера AFTER SUSPEND, которое позволяет автоматизировать отклик на условие приостановки сеанса. Есть еще модуль DBMS_RESUMABLE, позволяющий управлять возобновляемым назначением пространства из SQL или PL/SQL.
| ПРИМЕЧАНИЕ Возобновляемое назначение пространства можно использовать для приостановки/возобновления сеанса, что в других случаях привело бы к ошибке, связанной с использованием пространства. |
В предыдущих версиях Oracle в качестве временного табличного пространства по умолчанию пользователям назначалось SYSTEM. Это могло вызвать проблемы, если администратор БД был невнимателен при назначении пользователю соответствующего временного табличного пространства во время создания учетной записи. Если задано табличное пространство по умолчанию, Oracle назначает его каждой новой пользовательской учетной записи при ее создании. Разумеется, если вы сами определяете табличное пространство по умолчанию для такой пользовательской учетной записи, эта настройка переопределяет настройку по умолчанию.
В Oracle табличное пространство по умолчанию определяется с помощью команды alter database default temporary tablespace. Можно также определить временное табличное пространство по умолчанию для базы данных в рамках команды create database. Команда alter database default temporary tablespace позволяет изменить текущее табличное пространство по умолчанию. Все пользователи, назначенные на старое временное табличное пространство по умолчанию, теперь будут назначены на вновь определенное временное табличное пространство по умолчанию. Пользователей, назначенных на другие временные табличные пространства, это не касается.
Файлы, управляемые Oracle (Oracle-Managed Files, OMF) — это новое свойство, позволяющее базе данных управлять практически всеми аспектами администрирования файлами базы данных Oracle. При условии правильной конфигурации OMF вам не придется определять имя, местонахождение или размер файла Oracle, и можно не беспокоиться об удалении файла данных после его создания. Необходимо просто сконфигурировать несколько параметров, а Oracle сделает все остальное. OMF автоматически управляет созданием в базе данных журналов БД, управляющих файлов и файлов данных. Если удаляется табличное пространство, состоящее из файлов данных OMF, Oracle удаляет эти файлы из файловой системы.
Для конфигурации OMF задаются следующие параметры:
| Имя параметра | Описание |
|---|---|
| db_create_file_dest | Динамический параметр, определяющий местоположение, которое OMF использует для создания всех файлов данных в базе данных. |
| db_create_online_log_dest__n | Динамический параметр, позволяющий определить до пяти различных местоположений для мультиплексированных оперативных журналов базы данных и управляющих файлов. |
| ПРИМЕЧАНИЕ Файлы, управляемые Oracle (OMF), упрощают управление базой данных. |
Иногда необходимо изменить распределение памяти SGA. Прежде, если было нужно добавить память в буферный кэш по умолчанию или добавить разделяемый пул или даже удалить память из одной из этих структур, то до Oracle9i приходилось выключать базу данных и только потом приступать к изменению распределения памяти. Oracle9i позволяет динамически изменять многие конфигурации памяти с помощью команды alter system. В таблице 1.2 приводятся области кэша памяти, которые можно изменять динамически.
Однако некоторые области памяти не являются динамическими. К ним относится JAVA_POOL. Кроме того, если используются DB_BLOCK_BUFFERS, BUFFER_POOL_KEEP и BUFFER_POOL_RECUCLE, эти области памяти также нельзя изменить динамически.
Для определения максимального объема памяти, который можно назначить для SGA, используется дополнительный параметр SGA_MAX_SIZE. По умолчанию он равен общему объему памяти, назначаемому для SGA при первом запуске базы данных. Это значение можно переопределить, установив новое значение SGA_MAX_SIZE, но для этого придется выключить и перезапустить экземпляр базы данных.
| Описание кэша | Имя параметра | Описание |
|---|---|---|
| Буферный кэшпо умолчаниюв базе данных | DB_CACHE_SIZE(новый параметр в 9i) | Определяет размер кэша по умолчанию. Может определяться в байтах, килобайтах (Кб) или мегабайтах (Мб). По умолчанию буферный кэш назначается в байтах, а не в буферах, как это происходит при настройке DB_BLOCK_BUFFERS.В Oracle9i предпочтительнее использовать именно этот параметр, а не DB_BLOCK_BUFFERS. |
| Определение подкэша буфера данных разделяемой памяти | DB_NK_CACHE_SIZE(новый параметр в 9i) | Определяет размер кэша памяти базы данных в nK. Эти размеры кэша представляют собой 2 в степени (2 Кб, 4 Кб, 8 Кб, 16 Кб). Назначаемый кэшу объем памяти определяется в байтах, килобайтах (Кб) или мегабайтах (Мб). Эта память назначается не из SGA, а из свободной памяти. |
| Область сохранения кэша | DB_KEEP_CACHE_SIZE(новый параметр в 9i) | Определяет размер пула сохранения кэша. Может определяться в байтах, килобайтах (Кб) или мегабайтах (Мб). В Oracle9i предпочтительнее использовать именно этот параметр, а не BUFFER_BLOCK_KEEP. Эта память назначается не из SGA, а из свободной памяти. |
| Очистка области кэша | DB_RECYCLE_CACHE_SIZE(новый параметр в 9i) | Определяет размер пула сохранения кэша. Может определяться в байтах, килобайтах (Кб) или мегабайтах (Мб). В Oracle9i предпочтительнее использовать именно этот параметр, а не BUFFER_POOL_RECYCLE. Эта память назначается не из SGA, а из свободной памяти. |
| Разделяемый пул | SHARED_POOL_SIZE | Определяет размер разделяемого пула. |
| Большой пул | LARGE_POOL_SIZE | Определяет размер большого пула. |
И, наконец, при задании параметра SGA_MAX_SIZE на большинстве платформ при запуске базы данных Oracle запрашивает у операционной системы память, эквивалентную SGA_MAX_SIZE. Таким образом, даже если SGA выделено всего 300 Мб, а SGA_MAX_SIZE задан как 500 Мб, Oracle запросит 5000 Мб из свободной памяти.
| ПРЕДУПРЕЖДЕНИЕ Будьте осторожны, настраивая SGA_MAX_SIZE, чтобы не забрать память у пользовательских сеансов или приложений и не спровоцировать подкачку (об управлении динамической памятью см. в главе 4). |
| ПРИМЕЧАНИЕ Управление динамической памятью можно использовать для оптимизации базы данных во время работы системы, включая изменение памяти в системной глобальной области (SGA). |
В предыдущих версиях Oracle в базе данных устанавливался единый размер блока. После фиксации такого размера блок становился словно высеченным из камня, и изменить его можно было только при восстановлении базы данных. Во многих случаях это вызывало проблемы. Например, нельзя было перемещать табличные пространства между базами данных с разными размерами блока. Кроме того, при некоторых обстоятельствах гибридные базы данных могли извлекать пользу из того, что данные находились в табличных пространствах с разными размерами блока.
Для решения этой проблемы Oracle9i позволяет назначать разные размеры блока каждому отдельному табличному пространству (за исключением табличных пространств SYSTEM, временных табличных пространств, а также табличного пространства UNDO и сегментов отката) при их создании. Кроме того, перемещаемые в базу данных табличные пространства могут иметь размер блока, отличный от установленного по умолчанию.
Мы уже обсуждали различные определения подкэша разделяемой памяти. Прежде чем перемещать или создавать табличное пространство с блоками, размер которых отличается от размера блока по умолчанию, придется создать подкэши разделяемой памяти.
Возможность создания и перемещения табличных пространств с разными размерами блока имеет множество применений. Для гибридных баз данных табличные пространства с блоками меньшего размера могут быть более эффективны при обращении к OLTP, а те, у которых размер блока больше, могут оказаться более эффективными для составления отчетов. Кроме того, в прошлом иногда было трудно перемещать табличные пространства между системами OLTP и информационными хранилищами или системами генерации отчетов из-за разного размера блоков в базах данных. Теперь это не проблема (подробнее см. в главе 4).
| ПРЕДУПРЕЖДЕНИЕ Свойства разработки Oracle не поддерживают использование нескольких размеров блоков для оптимизации производительности. Кэши с нестандартными размерами не оптимизируются. |
| ПРИМЕЧАНИЕ В Oracle9i каждое табличное пространство может иметь свой размер блока, и поэтому выбор размера блока становится менее критическим фактором перед созданием базы данных. |
В Oracle8i появилось свойство под названием “разделение курсора”, которое давало оптимизатору возможность преобразовывать литералы в командах SQL в связанные переменные. В результате одинаковые команды SQL (за исключением значений литералов) могут совместно использовать данный курсор. Это привело к сокращению времени анализа команды SQL и, что, возможно, самое главное, к уменьшению фрагментации разделяемой области SQL в разделяемом пуле. К сожалению, в результате разделения курсора и использования связанных переменных у оптимизатора появляются трудности при определении избирательности данных в столбцах, относящихся к связанной переменной. А это может привести к субоптимальным планам исполнения. Разделение курсора включается с помощью параметра CURSOR_SHARING=FORCE.
Oracle9i внесла некоторые новшества в разделение курсора. Если задать CURSOR_SHARING=SIMILAR, оптимизатор сможет анализировать распределение данных в столбцах. Воспользуйтесь проанализированной статистикой таблицы, столбцов, ассоциированных индексов и любыми сгенерированными гистограммами и определите оптимальность плана исполнения. Если план окажется оптимальным, будет использоваться проанализированная команда SQL (подробнее см. в главе 4).
| ПРИМЕЧАНИЕ Задание параметра инициализации CURSOR_SHARING помогает свести к минимуму проблемы с разделяемым пулом. |
Теперь Oracle9i может сама настраивать PGA для данного сеанса. Раньше при настройке памяти, назначаемой серверному сеансу Oracle, администратор БД мог выбирать из ряда параметров. Теперь Oracle может с помощью одного параметра PGA_AGGREGATE_TARGET определить общий объем физической памяти, который надо предоставить для использования всем выделенным серверным процессам. Эта величина позволяет Oracle выводить затем значения для таких параметров, как SORT_AREA_SIZE, HASH_AREA_SIZE, BITMAP_MERGE_AREA_SIZE и CREATE_BITMAP_AREA_SIZE. При желании можно оптимизировать отдельные параметры (подробнее см. в главе 4).
С помощью нового модуля DBMS_REDEFINITION можно переопределить таблицу в оперативном режиме, пока данные в этой таблицы еще доступны для запросов пользователей и выполнения DML. Во время переопределения можно переместить всю таблицу, определенные разделы или любое число сочетаний операций. Могут выполняться и другие операции: переименование столбцов, перемещение таблицы в новое табличное пространство, преобразование таблицы в таблицу с индексной организацией и т.д. В отношении оперативного переопределения таблиц существует ряд правил.
Несколько других административных свойств являются новыми для Oracle9i. Теперь с помощью новой конструкции INCLUDING CONTENTS AND DATAFILES в команде drop tablespace можно дать Oracle указание удалять файлы данных при удалении табличного пространства. Вот пример:
DROP TABLESPACE old_data INCLUDING CONTENTS AND DATAFILES; |
Теперь Oracle9i дает администратору возможность с помощью конструкции FORCE LOGGING в командах alter database или create database запретить какие-либо операции без регистрации в базе данных. Эта опция очень полезна, если вы управляете окружением дублирующей базы данных.
Если ваша база данных когда-либо давала сбой в середине “горячего” резервного копирования, вы знаете, что такое выводить все файлы данных БД из этого режима. Oracle9i приходит на помощь с командой alter database end backup. Теперь всего лишь одна команда выводит все файлы данных из режима “горячего” резервного копирования.
Oracle9i также упрощает конвертацию из типа данных LONG в тип данных LOB. Это делается с помощью команды alter table:
alter table my_table modify (text_column clob); |
| ПРЕДУПРЕЖДЕНИЕ Не забывайте о связанной с этим преобразованием потребности в дополнительном дисковом пространстве: понадобится вдвое больше места, чем занято под исходное LONG. |
Еще одно приятное новое свойство состоит в том, что SYS действительно стала привилегированной административной учетной записью. До Oracle9i учетная запись SYS не могла предоставлять право прямого доступа к объектам, которые ей не принадлежали, если только владелец объекта не давал SYS права на это. Но теперь SYS может при необходимости предоставлять и отменять доступ к любому объекту в базе данных. Это новое свойств тесно связано с новой привилегией GRANT ANY OBJECT PRIVILEGE, которую можно предоставлять любым пользователям, чтобы наделить их правами администрирования во всей базе данных.
И еще одно свойство: в Oracle9iR2 теперь можно локально управлять системным табличным пространством. Если использовать Database Creation Assistant, он по умолчанию создает системное табличное пространство как локально управляемое. При этом никакие другие табличные пространства базы данных не смогут быть управляемы словарем.
| ПРИМЕЧАНИЕ Если сделать системное табличное пространство локально управляемым, вы не сможете создать в базе данных табличные пространства, управляемые словарем. |
Oracle9i предлагает новые архитектурные свойства, которые могут помочь повысить производительность базы данных. Некоторые из этих совершенно новых свойств могут оказывать воздействие на производительность базы данных без вашего участия. В этом разделе мы обсудим следующие свойства:
Oracle9i поставляется с некоторыми возможностями разделения. Во-первых, вводится новый тип разделения — списочное разделение (list partitioning), при котором можно определить список значений, связанных со столбцом ключа раздела, и назначить эти значения определенному разделу.
Например, если вы бы вели розничную торговлю в 50 штатах и часто выполняли поиск своих клиентов по штату, вам пригодилось бы списочное разделение для разделения информации о клиентах по штатам.
Oracle9iR2 развивает свойство списочного разделения, позволяя создавать разделенные на диапазоны таблицы с подразделами. Версия 9iR2 также предлагает опцию создания раздела MAXVALU для разделенной по списку таблицы, что было недоступно в 9iR1. Кроме того, в 9iR2 операции разбиения на разделы выполняются более эффективно (подробнее см. в главе 3).
| ПРИМЕЧАНИЕ Oracle9i предоставляет большую гибкость и лучшие функциональные возможности для разделения, чем предыдущие версии. |
Многие администраторы БД либо разработали свои собственные сценарии извлечения DDL из словаря данных БД, либо приобрели для этого какое-либо инструментальное средство. Предлагаемый Oracle9i модуль DBMS_METADATA упрощает работу по извлечению DDL объектов БД. Он позволяет извлекать DDL для находящихся в базе данных объектов в прямом текстовом формате или в формате XML. В листинге 1.1 приводится пример использования DBMS_METADATA для распаковки таблицы SCOTT.EMP.
Листинг 1.1. Извлечение SCOTT.EMP с помощью DBMS_METADATASQL> set pages 0 SQL> set long 100000 SQL> Select dbms_metadata.get_ddl('TABLE', 'EMP ','SCOTT') from dual; CREATE TABLE "SCOTT", "EMP" ( "EMPNO" NUMBER(4,0), "ENAME" VARCHAR2 (10), "JOB" VARCHAR2(9), "MGR" NUMBER(4,0), "HIREDATE" DATE, "SAL" NUMBER(7,2), "COMM" NUMBER(7,2), "DEPTNO" NUMBER(2,0), CONSTRAINT "PK_EMP" PRIMARY KEY ("EMPNO") USING INDEX PCTFREE 10 INITRANS 2 MAXTRANS 255 STORAGE(INITIAL 16384 NEXT 16384 MINEXTENTS 1 MAXEXTENTS 505 PCTINCREASE 50 FREELIST 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT) TABLESPACE "SYSTEM" ENABLE, CONSTRAINT "FK_DEPTNO" FOREIGN KEY ("DEPTNO") REFERENCES "SСОТТ"."DEPT" ("DEPTNO") ENABLE NOVALIDATE) PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING STORAGE (INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645 PCTINCREASE 0 FREELIST 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT) TABLESPACE "USERS"; |
| ПРИМЕЧАНИЕ Модуль DBMS_METADATA позволяет извлекать DDL из словаря данных БД. |
В предыдущих версиях Oracle отслеживала доступность блоков с помощью списков свободной памяти, куда заносились все блоки, в которые можно было производить запись. Метод отслеживания свободного пространства в сегменте носил довольно спорный характер и вызывал проблемы с производительностью. Хотя управление пространством с помощью списка свободной памяти все еще применяется (и является параметром по умолчанию), в Oracle9i появилось новое свойство: автоматическое управление пространством сегмента (Automatic Segment Space Management, ASSM). Оно упрощает управление свободным пространством в сегментах и уменьшает конкуренцию, которая может сопровождать использование списков свободной памяти. ASSM можно устанавливать только в локально управляемом табличном пространстве, и все предназначенные ASSM сегменты в табличном пространстве должны его использовать. Для создания табличного пространства с ASSM используется параметр SEGMENT SPACE MANAGEMENT AUTO из команды create tablespace.
Когда с помощью ASSM создается сегмент в табличном пространстве, Oracle создает набор битовых блоков (bitmapped blocks, BMB), хранимых в этом сегменте (как правило, в начале сегмента, а другие BMB можно по мере необходимости добавлять в любое место). Oracle сохраняет BMBs как текущие, когда данные в сегменте модифицируются, и BMBs отслеживают назначение места блокам данных.
ASSM устраняет потребность в списках свободной памяти и группах списков свободной памяти, обычно связываемых с окружением Real Application Cluster (RAC). Часто ASSM приводит к повышению производительности, особенно если сегменты содержат строки, размер которых изменяется. В окружении Real Application Cluster сегменты, созданные с помощью ASSM, работают гораздо лучше, чем те, которые управляются посредством списка свободной памяти.
Следует ли использовать ASSM? Это не панацея для решения всех проблем, но, если они вызваны конфликтом из-за списка свободной памяти, возможно, ASSM вам поможет.
| ПРИМЕЧАНИЕ Автоматическое управление пространством в сегментах (ASSM) упрощает управление свободным пространством. |
В Oracle9i появилось несколько новых свойств, связанных с индексацией. Они рассматриваются в данном разделе, в частности просмотр индексов с пропусками, битовые индексы, требующие выполнения операции соединения, и создание битовых индексов для таблиц с индексной организацией. Глава 2 посвящена обсуждению индексации для начинающих.
Просмотр индексов с пропусками
В Oracle9i изменились правила индексации. Теперь можно выполнять операцию просмотра индекса с пропусками. Она позволяет оптимизатору Oracle брать для операции просмотра любой столбец, даже если он не находится на ведущем крае индекса. Однако следует учитывать некоторые последствия этого нового свойства. При миграции может выясниться, что запросы SQL получают различные планы исполнения (и, будем надеяться, благодаря этому быстрее работают), следовательно, план исполнения некоторых созданных вами вручную запросов SQL, вероятно, изменился. Поэтому тщательно проверьте и убедитесь, что это свойство не вызовет негативных последствий в вашей базе данных.
Битовые индексы, требующие выполнения операции соединения
Oracle9i предлагает некоторые новые опции индексации, которые могут повысить производительность базы данных. Битовый индекс, требующий выполнения операции соединения, создает представленный в виде битовой карты индекс, являющийся предварительным объединением столбцов из двух или более различных таблиц. Если у вас есть объединения таблиц, в которые входят столбцы с относительно небольшим числом различных значений, вам пригодится битовый индекс, требующий выполнения операции соединения.
Отображение таблиц и битовые индексы для таблиц с индексной организацией
Теперь Oracle9i позволяет создавать битовый индекс для таблиц с индексной организацией (IOT). Для этого сначала нужно создать таблицу отображения для такой таблицы. Таблица отображения переводит бит в индексе в логический ROWID в IOT. Конструкция MAPPING TABLE в команде create table позволяет создать таблицу отображения при создании IOT (см. листинг 1.2):
Листинг 1.2. Использование конструкции MAPPING TABLE в команде create tablecreate table tusc_employee ( emp_no number primary key, ename varchar2 (50) ) organization index mapping table tablespace users; |
Добавление таблицы отображения к уже существующей таблице с индексной организацией (IOT) требует восстановления IOT и создания в это время таблицы отображения.
Одна из основных задач отображения таблиц — это поддержка другого нового свойства Oracle9i: способности создавать вторичные битовые индексы для IOT. Для одной IOT можно создать несколько битовых индексов, и все они будут поддерживаться одной таблицей отображения.
Другие новые свойства индексации в 9i
В Oracle9i добавлены следующие дополнительные функциональные возможности индексации:
В Oracle9i появились следующие новые свойства организации информационных хранилищ:
Oracle9i позволяет непосредственно обращаться к внешним файлам из базы данных с помощью нового свойства “внешняя таблица”. Внешняя таблица определяется в базе данных и указывает на физический файл данных, находящийся на сервере, где работает БД. Внешняя таблица создается с помощью команды create table, в которой используется новая конструкция ORGANIZATION EXTERNAL. Как только таблица определена, к ней можно обращаться через стандартные команды SQL SELECT. Заметьте, что в настоящее время нельзя создавать индексы для внешних таблиц. Команда drop table позволяет удалить существующую внешнюю таблицу.
Правильность перезаписи запроса зависит от определения ограничений между связанными таблицами. В прошлом это было проблемой из-за невозможности создать ограничения для представлений; т.е., если представление основывалось на таблице размеров или фактов и использовалось в команде SQL, Oracle не могла воспользоваться преимуществом перезаписи запроса (а следовательно, преимуществом материализованного представления).
Для решения этой проблемы в Oracle9i введены ограничения на представления. Теперь при вводе команды create view можно определить для представлений первичный ключ, уникальный ключ и внешние ключи. В качестве альтернативы можно добавлять ограничения на представления с помощью команды alter view. Достоверность любого определяемого ограничения не будет проверяться, а ограничения NOT NULL наследуются от базисной таблицы.
Часто исходные данные предназначаются для нескольких таблиц. В таких случаях в версиях ниже Oracle9i приходилось вводить несколько команд INSERT, что приводило к дополнительному и ненужному вводу/выводу в исходную таблицу, чтобы заполнить различные таблицы. Oracle9i представляет три различных типа команды INSERT для нескольких таблиц:
Листинг 1.3 демонстрирует сводную команду INSERT для нескольких таблиц:
Листинг 1.3. Использование сводной команды INSERTInsert all Into all_sales values(store_id, 'Ql', sales_ql) Into all_sales values(store_id, 'Q2', sales_q2) Into all_sales values(store_id, 'Q3', sales_q3) Into all_sales values(store_id, 'Q4', sales_q4) Select store_id, sales_ql, sales_q2, sales_q3, sales_q4 from quarterly_sales_by_store where year='2001' |
В этом примере берется однородная денормализованная таблица QUARTERLY_SALES_BY_STORE и создается, более нормализованным способом, запись в таблице ALL_SALES. Листинг 1.4 демонстрирует пример таблицы QUARTERLY_SALES_BY_STORE и окончательной таблицы ALL_SALES после выполнения запроса:
Листинг 1.4. Обращение к таблице QUARTERLY_SALES_BY_STORE и полученные результатыSQL> select from quarterly_sales_by_store |
| STORE_ID | SALES_Q1 | SALES_Q2 | SALES_Q3 | SALES_Q4 | YEAR |
|---|---|---|---|---|---|
| 1 | 100 | 200 | 300 | 600 | 2001 |
| 2 | 200 | 400 | 600 | 1200 | 2001 |
SQL> select from all_sales; |
| STORE_NUM | QU | SALES |
|---|---|---|
| 1 | Q1 | 100 |
| 21 | Q1Q2 | 200200 |
| 21 | Q2Q3 | 400300 |
| 21 | Q3Q4 | 600600 |
| 2 | Q4 | 1200 |
| ПРИМЕЧАНИЕ Oracle9i предоставляет эффективные свойства организации информационных хранилищ, например вставку во внешние таблицы и в несколько таблиц. |
Oracle9i добавила много новых функциональных возможностей в области SQL и PL/SQL, в частности следующие:
До Oracle9i опция INDEX BY BINARY_INTEGER позволяла связывать числовой тип данных как индекс с массивом таблицы PL/SQL только при определении этой таблицы. Теперь Oracle9i позволяет создать индекс для типа данных Varchar с помощью опции INDEX BY VARCHAR2(N). Вот фрагмент кода PL/SQL:
type v_test_table is table of number index by varchar2(100); |
| ПРИМЕЧАНИЕ Это свойство имеется в Oracle9iR2. |
Oracle8i предлагала в SQL команду CASE, но в PL/SQL такая команда была недоступна. Oracle9i предлагает в PL/SQL два варианта команды case: простой и отыскиваемый. Команды CASE не возвращают значение, а выражения CASE возвращают. Оба варианта команды case имеют две разновидности: простую и отыскиваемую. Простая команда case оценивает только одно значение, а отыскиваемая может оценивать несколько значений. В листинге 1.5 приводится пример использования команды case в виде простого выражения CASE:
Листинг 1.5. Использование команды case в виде простого выражения CASECreate or replace function calculate_values (p_input varchar2) Return number Is V_return number; Begin V_return:=case p_input When 'EXPENSE' then 1 When 'INCOME' then 2 ELSE 3 End; Return v_return; End; |
В этом примере мы передаем в функцию значение p_input. Затем команда CASE оценивает значение p_input и назначает значение переменной v_return. В листинге 1.6 показан пример отыскиваемой команды CASE:
Листинг 1.6. Использование отыскиваемой команды CASECreate or replace function calculate_values (p_input varchar2 , p_number number) Return number Is V_return number; Begin case When p_input ='EXPENSE' and p_number < 1000 Then v_return: = 0; When p_input ='EXPENSE' and p_number < 5000 Then v_return:=20; When p_input ='EXPENSE' and p_number >= 5000 Then v_return:=40; Else v_return:=100; End case; Return v_return; End; |
Во время различных процессов загрузки может потребоваться вставить новую запись или модифицировать уже существующую. Раньше для этого пришлось бы писать PL/SQL. Новая команда MERGE предназначена именно для таких операций. Она позволяет вставлять запись в таблицу, если она еще не существует, и модифицировать уже существующую запись во время выполнения команды. Использование команды MERGE демонстрируется в листинге 1.7:
Листинг 1.7. Использование команды MERGEMerge into all_sales_data a Using mtd_sales_data b On (a.sale_id=b.sale_id) When matched then Update set a.sale_amt=b.sale_amt, a.store_num=b.store_num When not matched then Insert (sale_id, store_num, sale_amt) Values (b.sale_id, b.store_num, b.sale_amt); |
| ПРИМЕЧАНИЕ Oracle9i предоставляет команду merge, также известную как upsert, потому что она модифицирует запись, если она есть, или вставляет ее, когда ее нет. |
Oracle добавила следующие новые операторы SQL поддержки стандарта ANSI/ISO SQL 1999:
Хотя в Oracle9i включен синтаксис SQL 1999 для внешнего объединения, старый оператор outer join (+) все еще доступен.
Заслуживает упоминания хост новых свойств, имеющийся в 9i. В данном разделе рассматриваются кэшированные планы исполнения, DBMS_XPLAN, часовые пояса, поддержка LOB, собственный транслятор PL/SQL, семантика байта в сравнении с семантикой символа, а также детальный аудит.
Просмотр кэшированных планов исполнения
Иногда вывод плана объяснения может быть неправильным (хотя и не часто, но такое может случиться). Если необходимо увидеть реальный план исполнения, применяемый Oracle для данного запроса, можно воспользоваться новым представлением V$SQL_PLAN. Оно очень напоминает представление Oracle PLAN_TABLE и содержит планы исполнения всех команд SQL, находящихся в настоящее время в разделяемой области SQL. Оно также содержит информацию об адресе, так что к V$SQLAREA можно обратиться, если необходимо получить весь текст команды SQL или статистику исполнения данных команд SQL.
Генерация плана объяснения с помощью DBMS_XPLAN
У каждого администратора БД есть свой собственный сценарий форматирования результатов таблицы плана. Проблема в том, что необходимо поддерживать эти сценарии и переносить их на различные рабочие сайты, если вы даете консультации. Oracle9iR2 решает эту проблему с помощью DBMS_XPLAN. Его можно использовать для отображения и форматирования плана исполнения! В листинге 1.8 приводится простой пример:
Листинг 1.8. Использование DBMS.XPLANSQL> Explain plan set statement_id='TUSC' for Select * from emp; Explained. SQL> select * from table(dbms_xplan.display); PLAN_TABLE_OUTPUT |
| Id | Operation | Name | Rows | Bytes | Cost |
|---|---|---|---|---|---|
| 0 | SELECT STATEMENT | 15 | 495 | 2 | |
| 1 | TABLE ACCESS FULL | EMP | 15 | 495 | 2 |
Note: cpu costing is off 9 rows selected. |
| ПРИМЕЧАНИЕ DBMS_XPLAN можно использовать для отображения стандартного формата плана исполнения запроса. |
Новые типы данных даты и времени, функции и функциональные возможности
Oracle9i предоставляет концепцию разницы во времени по часовым поясам для базы данных. Это означает, что можно указывать, в каком часовом поясе находится ваш сервер, и записывать время на основании разницы во времени с часовым поясом сервера. Можно также указывать часовой пояс на уровне сеанса, что позволяет приложениям производить настройку часового пояса во время их работы.
Oracle9i также предоставляет несколько новых типов данных даты и времени для обеспечения дополнительного уровня точности относительно прошедшего времени, с возможной точностью до девяти цифр. Эта точность ограничена возможностями основной операционной системы.
Доступные в Oracle9i новые типы данных даты и времени перечислены в таблице 1.3.
| Тип данных | Описание |
|---|---|
| Метка даты/времени | Обеспечивает более высокий уровень измерения времени, чем SYSDATE. |
| Метка даты/времени с часовым поясом | Обеспечивает более высокий уровень измерения времени, чем SYSDATE, а также представляет разницу во времени по сравнению с заданным в настоящее время часовым поясом. |
| Метка даты/временис местным часовымпоясом | Обеспечивает более высокий уровень измерения времени, чем SYSDATE. Время вывода откорректировано так, чтобы оно отражало время для заданного в настоящее время часового пояса. |
| Интервал день-секунда | Содержит период времени в днях, часах, минутах и секундах. |
| Интервал год-месяц | Содержит период времени в месяцах и годах. |
В дополнение к новым типам данных даты/времени Oracle предоставила хост новых функций, связанных с датой и временем. К ним относятся функции управления новыми типами данных даты/времени и поддержки новых свойств часового пояса.
| ПРИМЕЧАНИЕ Oracle9i предоставляет новые типы данных даты/времени для улучшения работы с часовыми поясами. |
Усовершенствованная поддержка LOB
Теперь Oracle9i обеспечивает “родную” поддержку для LOB, не превышающих 32 Кб. Следовательно, функции на основе символа, такие как SUBSTR, теперь работают с LOB до 32 Кб. Кроме того, команда alter table позволяет легко преобразовать LONG в LOB. Знайте, что некоторые важные требования к временному пространству связаны с преобразованием столбца LONG в LOB.
Собственная компиляция PL/SQL
Oracle9i поддерживает собственную компиляцию хранимых процедур на PL/SQL. Поэтому можно компилировать процедуры PL/SQL с помощью компилятора С, и они будут работать намного быстрее. Необходимо задать параметры, указывающие Oracle, что вы хотите выполнить собственную компиляцию процедуры. Можно даже использовать собственную компиляцию для поставляемого с Oracle модуля PL/SQL.
Семантики символа в сравнении с семантикой байта
Oracle9i позволяет определять сохранение символьного типа с помощью длины символа или байтов. Это свойство применяется в многобайтовых кодовых наборах (например, Unicode), чтобы символьный столбец мог сохранять требуемое число символов.
Детальный аудит
Oracle9i позволяет осуществлять аудит всех доступов SELECT к определенной таблице. Аудит производится после разработки специальной политики, которая определяет степень аудита. Критерии аудита можно довести до выбора определенного столбца или столбцов и основанных на диапазоне значений. Когда Oracle выполняет команды SQL, происходит проверка политики аудита, чтобы было видно, заслуживает ли команда SQL аудита. Если да, в таблицу DBA_FGA_AUDIT_TRAIL вносится запись, которую администратор БД или сотрудники, занимающиеся защитой данных, могут рассмотреть позднее.
В Oracle9i появилось несколько новых свойств, которые могут изменить производительность резервного копирования или восстановления:
Fast start fault recovery (FSFR) — это новое свойство Oracle9i, которое сокращает общее время, необходимое для восстановления экземпляра после сбоя. Для конфигурации FSFR нужно задать в файле параметра базы данных или SPFILE параметр FAST_START_MTTR_TARGET в секундах (от 0 до 3600). На основании этой настройки Oracle динамически получает другие параметры настройки базы данных, чтобы требуемое среднее время восстановления (mttr) было как можно ближе к запрошенному. FAST_START_MTTR_TARGET заменяет несколько параметров из Oracle8i и более ранних версий, например DB_BLOCK_MAX_DIRTY_TARGET (теперь устарел), FAST_START_IO_TARGET и LOG_CHECKPOINT_INTERVAL. Настройка любого из этих параметров вручную позволяет отменить значения, которые Oracle устанавливает для них на основании значения, присвоенного FAST_START_MTTR_TARGET.
Oracle9i предлагает возможность оглянуться назад в прошлое, чтобы увидеть, как выглядели данные на определенный момент времени. Эта функциональная возможность известна как обращение с нарушением последовательности действий (flashback query). При этом сначала с помощью модуля DBMS_FLASHBACK определяется точка во времени (или SCN), к которой надо вернуться на уровне сеанса. После определения такой точки все последующие обращения к этому сеансу дают результаты, отражающие зафиксированное состояние объекта, как если бы это происходило в тот прошлый момент времени. По завершении обращения с нарушением последовательности действий его отключают, и все возвращаемые после этого строки будут отражать текущее состояние базы данных. Oracle9i R2 дополняет запрос с нарушением последовательности действий новыми функциональными возможностями, позволяя определить время нарушений с помощью отдельной команды SQL с конструкцией AS OF.
Возвращаемые строки были из времени, приблизительно соответствовавшего указанному времени обращения с нарушением последовательности действий. Oracle округляет это время или номера SCN с помощью 5-минутных приращений. Кроме того, вернуться назад можно только на пять дней, что вызвано налагаемыми Oracle внутренними ограничениями для ссылки на время и SCN. И, наконец, если вы хотите использовать запрос с нарушением последовательности действий, должны быть доступны все отмены, сгенерированные с того момента времени, к которому вы хотите вернуться. Oracle использует эти отмены для создания образов с согласованным чтением, которые нужны ей для возвращения данных “из прошлого”. Если такие отмены недоступны, обращение с нарушением последовательности действий возвратит сообщение об ошибке. Надо обязательно использовать автоматическое управление отменой.
| ПРИМЕЧАНИЕ Обращение с нарушением последовательности действий можно использовать для исправления ошибок пользователей. |
Со времени первого появления в Oracle утилита RMAN прошла длинный путь. В Oracle9i RMAN имеет много функций и возможностей. Например, она предлагает конфигурируемые параметры по умолчанию. Благодаря конфигурированию значений по умолчанию для каналов и уровня параллелизма блок выполнения часто оказывается ненужным при резервном копировании базы данных. Теперь создать резервную копию БД столь же просто, как использовать команду backup database. Кроме того, Oracle9i позволяет создавать резервные копии базы данных и архивных журналов за одну операцию с помощью команды backup database plus archivelog.
Некоторые сайты любят создавать резервную копию базы данных на диске, а впоследствии проводить резервное копирование этих наборов резервирования на ленту. В Oracle9i RMAN упрощает эту задачу, потому что поддерживает резервное копирование наборов резервирования. С помощью дополнительных параметров можно указать, для каких наборов резервирования нужно создать резервные копии по критерию времени, даты и др.
Восстановление управляющего файла и SPFILE базы данных теперь проходит гораздо легче благодаря автоматическому резервному копированию этих чрезвычайно важных компонентов при каждом резервном копировании. Просто введите команду configure controlfile autobackup on, и Oracle включит управляющий файл и SPFILE базы данных (если он используется) в конец каждой резервной копии. Кроме того, если задать автоматическое резервное копирование управляющего файла, Oracle будет создавать его резервную копию только на диске и каждый раз, когда в базу данных вносятся изменения, затрагивающие управляющий файл.
Oracle также упрощает восстановление управляющего файла, даже когда не используется каталог восстановления. Просто нужно задать DBID базы данных и в некоторых случаях назначить канал резервному устройству — Oracle выполнит поиск самой свежей резервной копии управляющего файла БД.
Еще одно новое свойство RMAN в Oracle9i, заслуживающее упоминания, — это восстановление среды блока. Такая функциональная возможность позволяет в оперативном режиме восстановить разрушенные блоки из резервных наборов. Таким образом, если в сообщении об ошибке будет сказано о разрушении блока, RMAN может восстановить его, пока остальная часть табличного пространства находится в оперативном режиме.
RMAN в Oracle9i имеет ряд других новых свойств, рассмотрение которых выходит за рамки нашей книги. Полностью RMAN для Oracle9i описывается в книге Роберта Фримана Oracle9i RMAN Backup and Recovery (Oracle Press, 2002).
В Oracle9i Log Miner имеет несколько новых свойств. Во-первых, можно дать Log Miner указание искать только зафиксированные транзакции. Кроме того, теперь Log Miner может транслировать команды DML, связанные с кластерами базы данных. Log Miner также поддерживает трансляцию операторов DDL базы данных, а также новую функциональную возможность определения устаревания используемого вами каталога. Это предоставляет вашему словарю несколько дополнительных возможностей для трансляции информации об объекте в процессе извлечения информации. И, наконец, теперь Log Miner может пропускать повреждение журнала базы данных, открывая путь к восстановлению большего количества транзакций в случае серьезной неисправности БД.
Oracle9i Data Guard
В Oracle9i Data Guard заменяет архитектуру дублирующей базы данных Oracle8i. В Oracle9i предлагается несколько новых свойств, включая возможность конфигурирования архитектуры дублирующей базы данных в синхронном режиме без потерь данных. При этом главный сервер не завершит фиксацию до тех пор, пока хотя бы один из удаленных резервных серверов не запишет изменения. Это всегда гарантирует отсутствие расхождения в данных между главной БД и по крайней мере одним из резервных серверов за счет производительности. Oracle9i также позволяет управлять несколькими конфигурациями Data Guard из OEM, облегчая администрирование окружением Data Guard.
Наконец, Oracle9iR2 предоставляет концепцию логической дублирующей базы данных. Журналы базы данных из главной БД архивируются на резервном сайте, где процесс использует Log Miner для считывания изменений из журналов, а затем применяет эти изменения к дублирующей БД. В течение этого процесса база данных может быть открыта в режиме чтения/записи.
Кроме того, к дублирующей БД можно добавлять дополнительные индексы, которые не существуют в главной базе данных.
| ПРИМЕЧАНИЕ В Oracle9i Data Guard позволяет конфигурировать архитектуру дублирующей БД в синхронном режиме без потери данных. |
Высокая эффективность и доступность информационных систем — ключевое требование для повседневной работы коммерческого предприятия. Рост зависимости от сохраненной информации за последнюю пару десятилетий привел к тому, что накапливаются и анализируются большие объемы данных. Требования к высокоэффективным базам данных постоянно растут, и одновременно растут осведомленность и требования к поддержанию таких баз данных в оперативном режиме. Увеличение объема глобальных операций и электронной коммерции в значительной степени зависит от доступности сохраненных данных. При неравномерной и непредсказуемой загрузке систем БД многих деловых групп решающее значение приобрел поиск высокоэффективных систем и подходящих параллельных систем для поддержки сложных и больших БД. Еще одно важное свойство — масштабируемость. По мере роста бизнеса растет накопление и взаимодействие данных, все больше пользователей и приложений начинают использовать системы БД, от которых требуется удовлетворять растущую потребность в данных без потери производительности и доступности. Для решения этих проблем Oracle9i предоставляет Real Application Clusters (RAC). Невозможно охватить в одном разделе все аспекты функционирования RAC. Мы просто выделили некоторые важные положения и внутреннюю работу RAC.
Параллельная кластеризованная база данных — это сложное приложение, обеспечивающее одновременный доступ к одной и той же базе данных (группе таблиц данных, индексам и другим объектам) с любого сервера в кластере без нарушения целостности данных. Как правило, параллельные базы данных содержат несколько экземпляров (узлов/серверов), одновременно обращающихся к той же самой физической памяти или данным. Что касается типа доступа к памяти, то параллельные системы реализованы двумя способами: модель без разделения ресурсов (Shared-Nothing Model) и модель с разделением диска (Shared-Disk Model).
В модели без разделения ресурсов, также называемой моделью дробления данных (Data-Partitioning Model), каждой системе принадлежит фрагмент базы данных, и каждый раздел может читаться или изменяться только системой-владельцем. Дробление данных позволяет каждой системе локально кэшировать свой фрагмент БД в памяти процессора, не требуя кросс-системной связи для обеспечения параллельного доступа к данным и средств управления когерентностью данных. Этот метод используется в работе базы данных IBM.
В модели с разделением диска все диски, содержащие данные, доступны для всех узлов кластера. Архитектура разделения дисков требует соответствующих методов управления для контроля параллелизма обновлений. Каждый из узлов в кластере имеет прямой доступ ко всем дискам, на которых находятся общедоступные данные. Каждый узел имеет локальный буферный кэш базы данных. Этот метод используется в работе базы данных Oracle, применяющей RAC.
Уделяя должное внимание высокой доступности и эффективности, Oracle долгое время поддерживала параллельный сервер Oracle (Oracle Parallel Server, OPS). В Oracle9i появилось следующее поколение этого свойства, и OPS возродился в виде Real Application Clusters (RAC). RAC поддерживает модель с разделением дисков, а следовательно, имеет доступ ко всем разделяемым дискам и экстенсивный механизм координирования ресурсов на разных узлах. Технология разделения дисков быстро продвинулась вперед за последние несколько лет, что обеспечило RAC дополнительные преимущества. Технология “сервер-хранилище данных” (Storage Area Network, SAN) скрывает многие сложности аппаратных модулей, контроллеров, дисководов и межсерверных соединений, оставляя на поверхности только тома памяти (storage volumes). Таким же образом группа серверов в кластере обеспечивает один образ системы и вычислительный ресурс. В сети обработки (Processing Area Network, PAN) привлекает внимание еще одна новая разработка, распространяемая некоторыми фирмами, продвигающими новые технологии, например Egenera (см. http://www.egenera.com/pdf/system_data.pdf). Вычисление с помощью BladeFrame обеспечивает масштабируемость без преград в виде добавления дополнительных узлов и управления. Все эти достижения в области аппаратных средств только подчеркивают неоспоримые успехи RAC.
На очень высоком уровне RAC представляет собой несколько экземпляров Oracle, обращающихся к одной базе данных Oracle. База данных — одна физическая БД, сохраненная в системе с разделением памяти. Каждый из экземпляров постоянно находится на отдельном хосте (также называемом “узел” или “сервер”). Все узлы собираются в кластеры через частное межсоединение и имеют доступ к разделяемой памяти. Все узлы параллельно выполняют транзакции в одной и той же БД. Как правило, предоставляемое поставщиками программное обеспечение менеджера кластера обеспечивает одно системное изображение, управляет членами узла и контролирует состояние узла. К главным компонентам относятся:
Межсоединения кластеров
Параллельная обработка основывается на передаче сообщений через несколько процессоров. Выполняющие параллельные программы процессоры обращаются за данными и командами, а затем выполняют вычисления. Каждый процессор периодически сверяется с другими узлами или главным узлом, чтобы спланировать свой следующий шаг или синхронизировать передачу результатов. Эти действия основываются на программном обеспечении, поддерживающем передачу сообщений, например на стандартном интерфейсе Message Passing Interface (MPI).
В параллельных базах данных проходит огромное число сообщений и блоков данных, или страниц, которые передаются в локальный кэш другого узла. Функциональные возможности и производительность в значительной степени зависят от эффективности транспортной среды или методологии. Она приобретает огромное значение для общей производительности кластера и использования параллельного приложения. Поскольку параллельные базы данных не налагают никаких ограничений на узел, к которому пользователи могут обратиться, эти пользователи могут выбирать, с каким узлом в кластере им установить соединение. Независимо от характера приложения, OLTP или баз данных информационных хранилищ, широко применяется движение блоков данных c одного узла на другой с помощью межсоединения. Роль кластерного межсоединения — обеспечение некоего расширенного кэша, заключающего в себе кэши всех узлов. Это одно из наиболее значительных свойств проектирования, которыми обладает кластер. Как правило, кластерное межсоединение используется для следующих функций высокого уровня:
Высокая производительность, достигаемая благодаря распределению вычислений по узлам кластера, требует кластерного межсоединения, обеспечивающего высокую скорость передачи данных и малую задержку при связи между узлами. Кроме того, межсоединение должно уметь обнаруживать и изолировать ошибки, а также использовать альтернативные пути. К межсоединениям предъявляются следующие основные требования:
Многие поставщики кластеров разработали весьма конкурентоспособную технологию. Немало продуктов, использующих межсоединение, уже приблизилось к уровням времени ожидания шины симметричной многопроцессорной обработки (Symmetrical Multi-Processing, SMP). Обзор различных возможностей межсоединений представлен в таблице 1.4.
| Измерение | Стандартная шина SMP | Каналпамяти | Myrinet | SCI | Gigabit Ethernet |
|---|---|---|---|---|---|
| Время ожидания (мс) | 0,5 | 3 | 7–9 | 9 | 100 |
| Издержки процессора (мс) | < 1 | < 1 | < 1 | ||
| Сообщения в секунду (млн.) | > 10 | > 2 | |||
| Аппаратная пропускнаяспособность (Мб/с) | > 500 | > 100 | ~250 | ~50 |
Высокопроизводительный канал памяти Межсоединение канала памяти — это быстродействующее сетевое межсоединение, предоставляющее приложениям адресное пространство в пределах всего кластера. Приложения отображают фрагменты этого адресного пространства в своем собственном виртуальном адресном пространстве как страницы размером 8 Кб, а затем считывают или записывают в него точно так же, как в обычную память.
Myrinet Эффективная, высокопроизводительная технология пакетной связи и коммутации. Она широко используется в кластерах Linux. ПО Myrinet поддерживает большинство стандартных хостов и операционных систем и поставляется с открытым исходным текстом.
Масштабируемое межсоединение (Scalable Interconnect, SCI) Наиболее производительное кластерное межсоединение компании Sun благодаря высокой скорости передачи данных и малой задержке. Использующие межсоединение приложения будут лучше масштабироваться с помощью SCI по сравнению с использованием менее производительных альтернативных средств. Sun SCI реализует удаленную разделяемую память (Remote Shared Memory, RSM) — свойство, которое обходит связь TCP/IP поверх Solaris. Это повышает производительность кластера.
Veritas Связь Database Edition/Advanced Cluster (DBE/AC) состоит из сервисов LLT (low latency transport — транспортировка с малым временем ожидания) и GAB (Group Membership and Atomic Broadcast — групповое членство и атомарная передача). LLT обеспечивает высокопроизводительную связь ядра с ядром и функции для стека IP. Именно применение LLT, а не IP, уменьшает время ожидания и накладные расходы, связанные со стеком IP.
HP HyperFabric Hyper Messaging Protocol (HMP) HP Hyper-Fabric поддерживает стандарт TCP/UDP поверх IP и НМП (собственный протокол НР). HyperFabric повышает масштабируемость и надежность TCP/UDP, обеспечивая прозрачное выравнивание нагрузки трафика соединения по нескольким картам сетевого интерфейса. HMP, вместе со свойством обхода OS и аппаратной поддержкой для разгрузки протокола, обеспечивает малое время ожидания и чрезвычайно низкое использование ресурсов процессора.
Для получения высокой производительности Oracle Real Application Cluster огромное значение играет выбор межсоединения. Необходимо проявлять осторожность при выборе технологии, подходящей для вашего окружения. Проконсультируйтесь с поставщиком, чтобы получить современные аппаратные средства.
Внутренняя работа системы Oracle RAC
В 9i RAC больше не идет речи о DIM, PCM, не-PCM, Lock Monitor и т.д. Большинство функциональных возможностей заменено или выполняется от имени сервисов глобального кэша Global Cache Services. Блокировка теперь обрабатывается как “удерживаемый ресурс”. Фоновые процессы из предыдущих версий все еще существуют, но обслуживают другие функции.
Экземпляры и процессы RAC
RAC — база данных с множественными экземплярами. Множественные экземпляры параллельно обращаются к одной и той же базе данных. Структура экземпляра RAC не так уж сильно отличается от автономного экземпляра Oracle. Помимо всех обычных процессов Oracle, например PMON, SMON, LGWR и DBWR, существует много специальных процессов, порождаемых для координирования связи между экземплярами и облегчения разделения ресурсов узлами кластера. Движение буфера между экземплярами и новый набор блоков Past Image Blocks (сохраняющих целостность данных) приводят к использованию дополнительных ресурсов из SGA.
Процессы LMSn:
Global Cache Resources (GCS) и Global Enqueue Services (GES)
Главную роль играют GCS и GES (это в основном процессы RAC). GCS обеспечивает единое системное изображение данных, даже если к данным обращаются несколько экземпляров. GCS и GES являются интегрированными компонентами Real Application Clusters, которые координируют одновременный доступ к базе данных коллективного пользования и к разделяемым ресурсам в БД и кэше БД. GES и GCS вместе поддерживают Global Resource Directory (GRD), чтобы записывать в него информацию о ресурсах и очередях. GRD остается в памяти и сохраняется во всех экземплярах. Каждый экземпляр управляет частью каталога. Распределенный характер управления имеет решающее значение для отказоустойчивости RAC.
Координация параллельных задач на сервере с разделяемым кэшем называется синхронизацией. Синхронизация использует частное межсоединение и интенсивную передачу сообщений. Она необходима таким типам ресурсов, как блоки данных и очереди. GCS поддерживает режимы для блоков в глобальной роли и отвечает за передачу блоков между экземплярами. Процессы IMS обрабатывают сообщения GCS и проделывают большую часть обработки GCS.
Очередь — это разделяемая структура памяти, которая делает последовательным доступ к ресурсам базы данных. Она может быть локальной или глобальной. Oracle использует очереди в трех режимах: 1) режим отсутствия информации (Null — N); 2) режим разделения (Share — S); и 3) исключающий режим (Exclusive — X). Блоки — это первичные структуры для чтения из буферов и записи в них. Часто это наиболее востребованный ресурс.
GES поддерживает или обрабатывает синхронизацию словарного кэша, кэша библиотеки, блокировок транзакций и блокировок DDL. Другими словами, GES управляет очередями, а не блоками данных. Для синхронизации доступа к словарному кэшу данных применяются блокировки в исключающем режиме и в базах данных кластера, состоящего из одного узла. Глобальные очереди используются в режиме базы данных кластера.
Слияние кэшей и координация ресурсов
Поскольку каждый узел в Real Application Cluster имеет свою собственную память (кэш), который не используется совместно с другими узлами, RAC должен координировать буферные кэши различных узлов при уменьшении дополнительного дискового ввода/вывода, который мог бы снизить производительность. Слияние кэшей (Cache Fusion) — технология, использующая высокоскоростные межсоединения для передачи блоков данных из кэша в кэш между экземплярами в кластере. Функциональная возможность Cache Fusion обеспечивает прямую запись измененных блоков в память, что позволяет снизить интенсивность записи на диск и повторного считывания (или ping) переданных блоков. Однако нельзя сказать, что записи на диск вообще не происходит. Она все же необходима для замены кэша и при возникновении контрольной точки. Cache Fusion решает вопросы параллельности между экземплярами: параллельное считывание на нескольких узлах, параллельное считывание и запись на разных узлах, параллельная запись на разных узлах.
Oracle читает блоки данных с диска, только если они еще не находятся в буферных кэшах какого-либо из экземпляров. Поскольку запись блоков данных происходит с задержкой, они часто содержат изменения из нескольких транзакций. Измененные блоки данных записываются на диск только при возникновении контрольной точки.
Режимы и роли ресурса
Поскольку некоторые блоки данных могут одновременно существовать в нескольких экземплярах, есть два идентификатора, которые помогают координировать их:
Последний по времени образ
Для поддержания целостности данных в версии RAC для 9i было введено новое понятие “последний (по времени) образ” (Past Image, PI). Прежде чем блок будет передан, в памяти сохраняется его последний образ и указание на то, был ли этот блок изменен или нет. В случае отказа CCS может восстановить текущую версию блока, считав PI. Этот PI отличается от блока CR, который необходим для восстановления образов последовательного чтения. Версия блока CR представляет последовательный моментальный снимок данных в точке времени.
Например, транзакция A экземпляра A обновила строку 2 блока 5, а затем транзакция B экземпляра B обновила строку 6 того же блока 5. Блок 5 был передан из экземпляра А в B. В это время создается Past Image (PI) для блока 5 в экземпляре A.
Номера изменений системы (System Change Numbers, SCN) уникальным образом идентифицируют зафиксированную транзакцию и внесенные ею изменения. Это логическая временная метка, которая определяет зафиксированную версию базы данных в одной точке времени. Каждой зафиксированной транзакции Oracle назначает уникальный SCN.
Поскольку в RAC фиксируется несколько экземпляров, в экземпляре необходимо поддерживать изменения SCN, однако требуется их синхронизация во всех экземплярах кластера. Поэтому управление SCN осуществляется Global Cache Service с помощью схемы генерации Lamport SCN или аппаратного генератора синхронизирующих импульсов, или выделенного сервера SCN. Номера SCN регистрируются в журнале БД, чтобы можно было синхронизировать операцию восстановления в Oracle9i Real Application Clusters.
Действительно ли RAC “не ломается”
Можно ли его сломать? Конечно, можно. Причиной может стать любая плохая разработка или вариант выбора. Обслуживание базы данных включает в себя много компонентов, помимо самой БД. RAC может быть включен и работать, но быть недоступен для клиентов. Между клиентскими машинами и серверами БД существуют промежуточные сетевые компоненты. В них может произойти сбой. Стихийные бедствия, уничтожающие аппаратные средства, например пожар, наводнение или землетрясение, могут вывести кластер и базу данных из строя.
Однако при условии локализации сбоев свойство RAC обеспечивает максимальную безопасность и непрерывное обслуживание базы данных. Даже при потере многих компонентов кластер с RAC может все еще функционировать. Но для этого требуется избыточная разработка всех входящих в него компонентов. Ключевое слово здесь — “разработка”. Недостаточно просто установить два или больше узлов; для надежного Real Application Cluster необходимы двойные межсоединения, двойные пути к блокам памяти, двойные блоки памяти, двойное электропитание, двойной общедоступный сетевой интерфейс и т.д. В качестве примера в таблице 1.5 показано, как действуют отдельные составляющие сбоев.
Пока в кластере доступен один из экземпляров Oracle, клиентские приложения имеют доступ к данным и могут выполняться без проблем.
| Результат | Компонент | Последствия сбоя |
|---|---|---|
| OK | Нарушения в работе/сбой процессора | На узле произошел сбой, другой узел все еще активный |
| OK | Сбой памяти | На узле произошел сбой, другой узел все еще активный |
| OK | Межсоединение | При двойном межсоединении, OK |
| Отключение | Переключение межсоединения | Узлы не могут поддерживать связь |
| OK | Сбой/замораживание ОС | На узле произошел сбой, другой узел все еще активный |
| Отключение | Программное обеспечение Cluster Manager | Кластер замораживается, все узлы выключаются |
| OK | Сбой экземпляра базы данных | Работающий на другом узле экземпляр обеспечивает обслуживание базы данных |
| OK | Управляющий файл (поврежден/потерян) | Будет использоваться мультиплексированный управляющий файл |
| OK | Файл журнала базы данных | Мультиплексированный файл журнала базы данных |
| Отключение | Потерянный файл данных | Требует восстановления носителя |
| Отключение | Ошибка человека | Зависит от типа ошибки |
| Отключение | Удаленный объект | База данных доступна, но приложение остановлено |
| Отключение | Ошибка в программном обеспечении базы данных | Возможен останов базы данных на всех экземплярах |
Разумеется, данный раздел не мог охватить все аспекты функционирования RAC. В нем просто выделены некоторые наиболее важные положения и внутренняя работа RAC. Знание специальных требований RAC и реализации глобального разделяемого кэша помогает правильно планировать и использовать RAC.
Для полного рассмотрения RAC потребовалась бы целая книга. В представлении GV$ показывается в основном статистика для всего кластера, а в представлении V$ — статистика для отдельного узла. Если планируется использовать RAC, необходимо расширить представления V$, а при наличии нескольких узлов обращаться к представлениям CV$. Этот раздел служит всего лишь введением, дающим предоставление обо всех компонентах.
Oracle9i New Features, Robert Freeman, TUSC; Oracle Press, 2002.
Спасибо Роберту Фриману за все, что написано в этой главе, за исключением раздела о RAC. Благодарю Маду Тумма из Бостонского отделения банка Credit Suisse First за помощь при написании раздела о RAC.
| Сообщений 0 Оценка 0 Оценить
|
