что делает команда ora
БД Oracle для программиста
Что позволяет БД Oracle работать так быстро?
Когда вы меняете данные в БД, то ваши изменения сначала идут в кэш, а потом асинхронно в нескольких потоках (число можно сконфигурировать) пишутся на диск. Синхронно же пишется специальных лог (оперативный журнальный файл), чтобы была возможность восстановить данные после сбоя, если они еще не успели с кэша сброситься на диск. Данный подход позволяет выиграть в скорости, так как в этом случае на диск все пишется последовательно в один файл, причем можно настроить так, чтобы писалось параллельно на два или больше дисков, тем самым увеличивая надежность защиты от потери изменений. Описанных файлов должно быть несколько, и они используются по кругу: как только все данные защищенные одним из лог файлов были записаны фоновым процессом в блоки данных на диск, то данный лог файл может быть переиспользован. Таким образом в какой-то мере это позволяет еще и сэкономить, имея ультрабыстрые диски небольшого размера только для небольших журнальных файлов используемых по кругу.
Обычно я рассказываю об этом, когда мне предлагают что-то сохранять просто в файл на диске, так как это будет «быстрее» за счет того, что мы будет писать все данные последовательно и головке жесткого диска не надо будет бегать и искать рэндомные блоки. Я все же настаиваю, что мы тут ничего не выиграем, так как будем писать на медленный диск, который скоро всего активно используется множеством других процессов для записи огромного количества различных логов, а Oracle синхронно тоже пишет у себя на диск только последовательно, как я описал выше.
Механизм восстановления данных
В СУБД Oracle можно включить архивацию вышеописанных оперативных журнальных файлов, и все изменения будут архивироваться. Таким образом при потере любого диска с блоками данных мы можем восстановить их на любой момент времени, включая момент прямо перед падением, накатив на последние архивные журнальные файлы текущий оперативный журнал.
Stand by копия
Вышеупомянутые архивные файлы можно отправлять по сети и на лету применять к копии БД. Таким образом у вас всегда под рукой будет горячая копия с минимальным запаздыванием данных. В некоторых приложениях, где нет необходимости показывать данные с точностью до последнего момента, можно настроить такую БД только на чтение и разгрузить основной экземпляр БД, причем таких экземпляров на чтение может быть несколько.
Подвисание некоторых запросов на запись
При зависании некоторых ваших запросов в произвольный момент времени стоит заглянуть в alert.log на предмет наличия incomplete checkpoint. Это говорит о том, что ваши оперативные журнальные файлы слишком большие или их слишком мало, таким образом, защищаемые ими данные не успевают сбрасываться из кэша на диск, а СУБД заполнила уже все доступные оперативные журнальные файлы и хочет использовать их по кругу повторно, чего делать ни в коем случае нельзя, вот и появляется пауза. Хотя если ваше приложение работает на java, то в первую очередь я бы загляну на наличия Full GC в логах.
Неблокирующее чтение и сегмент отката
Одной из наиболее замечательных особенностей СУБД Oracle является неблокирующее чтение, которое достигается за счет сегмента отката. Запросы к Oracle на чтение никогда не блокируются, так как данные почти всегда могут быть прочитаны из сегмента отката.
Сегмент отката дает еще одну плюшку: из него можно попытаться считать немного устаревшие данные для какой-нибудь таблицы, которые были в ней на определенный момент. Называется данная фича — flashback.
Однако иногда сегмент отката может подложить свинью: если у вас есть большой job для bulk удаления данных (удаление генерирует всех больше данных в сегменте отката), то вы можете получить ORA-01555: snapshot too old. Главное что в этом случае надо помнить — это то, что не надо переписывать ваш job, чтобы он коммитил через каждые N операций, а нужно использовать отдельный специально созданный сегмент отката для таких операций.
Уровни изоляции транзакций
В Oracle вообще нет уровня изоляции READ_UNCOMMITED. Дело в том, что в других базах данных он используется для достижения максимального параллелизма путем удаления блокировок чтения. Но в Oracle чтение и так всегда выполняется без блокировок, таким образом мы уже имеем все преимущества, которые может дать этот уровень, не вводя никаких дополнительных ограничений.
Вообще, в Oracle явно доступно всего два уровня изоляции: по умолчанию используется READ_COMMITTED, но при желании вы можете установить SERIALIZABLE.
Однако на уровне операторов (SELECT, UPDATE и т.д.) у вас по умолчанию уже есть REPEATABLE_READ, т.е. в рамках одного оператора вы всегда получаете согласованное чтение, что достигается конечно же за счет сегмента отката. Мне всегда очень нравился пример приводимый Томом Кайтом для описания того, что это дает. Допустим у вас есть очень большая таблица со счетами и вы выполняете SELECT на получение суммы. В Oracle, в отличие от многих других БД, даже если в середине вашего запроса другая транзакция переведет некоторую суммы с первого счета на последний, вы в итоге все равно получите данные актуальные на начало вашего запроса, так как дойдя до последний строчки ваш SELECT увидит, что строчка была изменена, пойдет в сегмент отката и прочитает данные, которые были в этой ячейке на момент начала выполнения запроса. Во многих других базах данных, вы получите ответ в виде суммы, никогда не существующей в вашей таблице. Однако в Oracle в данном случае есть опасность получить ORA-01555: snapshot too old.
В дополнение к стандартным уровням изоляции в Oracle еще есть так называемые READ_ONLY транзакции, которые дают REPEATABLE_READ в рамках всей транзакции, а не только в рамках одного оператора. Но как следует из названия, в такой транзакции вы можете выполнять только чтение.
Позвольте Oracle кэшировать ваши данные эффективно
В Oracle все данные читаются-пишутся не прямо на диск, а через кэш. По умолчанию кэш основан на LRU алгоритме, так что если вы читаете какую-нибудь очень большую табличку по идентификатору в больших количествах, запрашивая в каждый раз новую строчку, то такие запросы могут вытеснять из кэша небольшую статическую табличку, которой бы самое милое дело постоянно находиться в кэше. Для таких целей при создании таблицы вы можете указать специальный вид кэша, куда будут ходить запросы к вашим таблицам. Так для первой таблицы в вышеописанном примере подойдет кэш RECYCLE, который по сути не хранит никакие данные, а сразу их выбрасывает из кэша. А для второй таблицы подойдет кэш KEEP, который позволить хранить в кэше небольшие статические таблице и запросы ко всем остальным таблицам не будут вытеснять данные статических таблиц из кэша.
Пустые строки
В оракл есть одна очень интересная особенность, от которой они теперь уже никогда не смогут избавиться. Дело в том, что если вы кладете в БД пустую строку, то она сохраниться как NULL. Таким образом при последующем чтении вы никогда не получите пустой строки, а только NULL. Имейте так же в виду, что по этой же причине пустые строки не попадают в индекс, так что если вы будете делать запросы, план выполнения которых, будет использовать индекс, то ваше пустые (вернее NULL) строки вы никогда не получите, но об этом чуть позже.
Индексы
Кроме всем известных индексов в виде B-деревьев в Oracle еще есть так называемые битовые индексы, которые показывают очень высокую производительность на запросах к таблицам в которых есть колонки с очень разреженными значениями. Особенно эффективно в этом случае будут работать запросы (по сравнению с обычными индексами) в которых присутствуют сложные комбинации OR и AND к разряженным столбцам. Данный индекс храниться не в B-дереве, а в битовых картах, что и дает возможность быстрого выполнения описанных запросов. Вопрос в количестве уникальных значений в таблице при которых данный индекс еще будет более предпочтителен весьма сложен: это может быть как 10 уникальных значений, так и 10 000. Здесь надо создавать индекс на конкретной таблице и смотреть что получается. Главное не пытайтесь использовать данный индекс на таблицах с большим количеством вставок и обновлений индексируемой колонки, так как такие операции будут блокировать довольно большие участки в индексируемой таблице и ваша система может встать колом или даже поймаете deadlock.
Одна из вещей, которая меня всегда очень радовала в Oracle — это возможность создания индекса по функции. Т.е. если вам в запросах приходиться использовать какую-нибудь функцию, то вы можете построить по ней индекс и значительно ускорить операции чтения.
Еще одно интересное свойство индексов, о котором необходимо знать, это то, что в индексе не хранятся значения NULL. Таким образом если вы будете делать запросы с условием или <> по индексируемой колонке, то в ответ строчек со значением NULL в индексируемой колонке вы обратно не получите. С другой стороны данное свойство можно очень эффективно использовать дня некоторых специфичных случаев. Например, у вас есть очень большая табличка в которой хранятся ордера, которая никогда не чистится. И существует фоновый процесс, который обязан все ордера отсылать в какую-нибудь backoffice систему. Первое решение, которое напрашивается — это завести еще одну колонку с флагом is_sent, где изначально стоит 0 и при отсылке мы будем проставлять 1. Т.е. фоновый процесс при каждом запуске будет делать запрос к таблице с условием is_sent=0. Битовый индекс вы здесь использовать не можете, так как табличка очень активно пополняется. Обычный индекс на основе В-дерева будет занимать очень много места, так как нужно хранить ссылки на огромное количество строчек. Но если мы слегка поменяем нашу логику и в качестве пометки отсылки, и в колонку is_sent будем класть NULL вместо 1, то индекс у нас будет крошечный, так как в любой момент в нем будут храниться только не NULL значения, а их будет очень мало.
Таблицы бывают разные
Кроме обычных таблиц в oracle как и во многих других БД есть так называемые индекс-таблицы, когда данные таблицы непосредственно лежат в индекс-дереве первичного ключа. Таким образом достигается сразу две вещи: во первых для чтения данных по первичному ключу вы имеете на одно чтение меньше, во вторых данные в таблице получаются упорядоченными по первичному ключу, так что операция ORDER BY PK будет выполняться без дополнительной сортировки. К недостаткам можно отнести тот факт, что отличить логирование в оперативные журнальные файлы данного индекса вы уже не сможете.
Еще один замечательный тип таблиц — это кластерные таблицы, которые позволяют хранить данные из двух или более таблиц кластеризованные по одному значению ключа в одном блоке данных. Это может быть весьма эффективно если вы всегда используете какие-нибудь таблицы совместно.
На основе кластерных таблиц есть еще кластерные хэш-таблицы, в которых для доступа вместо B-дерева используется таблица на основе хеша кластерного ключа. Звучит, конечно, очень интересно, но, честно говоря, на практике никогда не сталкивался.
Связывание переменных
Наверное об этом уже наслышан каждый программист, но я все же упомяну о такой обязательной техники, как связывание переменных. Дело в том, что для каждого уникального запроса строится план разбора и кладется в кэш. Если различных запросов очень много, как, например, весьма распространенный запрос по ID, то на каждый запрос буден генериться свой план, к тому же они будут вытеснять из кэша все другие планы, что может в разы увеличить время отклика вашей базы данных.
Стоит так же заметить, что не стоит этим злоупотреблять и использовать связывание для столбцов с небольшим количеством различных значений, как-то флаг is_deleted, ведь различных запросов в этом случае будет не так много, а, возможно, для более конкретного запроса СУБД удастся построить более эффективный план.
Еще пара заметок для программиста
Если у вас колонка имеет тип VARCHAR2(100), то попытка туда запихнуть строку longString.substring(0, 100) не факт, что увенчается успехом, так как ограничение 100 в определении колонки по умолчанию относится к количеству байтов, а не символов, поэтому при наличии двухбайтовых символов вы можете попасть впросак. На самом деле данное поведение можно немного сконфигурировать, подробнее можно почитать тут. Хорошо если вы еще не пытаетесь выполнить вставку в бесконечном цикле, по принципу делать пока не получиться, ведь это «получиться» в данном случае никогда не наступит.
Ну и общая рекомендация для всех типов БД: никогда не делайте update всех колонок в таблице при изменении одного поля объекта. Кажется весьма очевидным, но как показывает практика, данный антипаттерн часто имеет место быть, поэтому я настоятельно рекомендую проверить, что ваши фреймворки делают UPDATE только действительно измененных полей.
Основы администрирования баз данных Oracle
· Запуск и останов БД
· Перенос БД на другой сервер (либо временное удаление БД)
· Экспорт и импорт данных
· Резервное копирование и восстановление
· Перевод БД на другую версию сервера Oracle ( upgrade и downgrade )
· Настройка БД Oracle
· Пути повышения производительности запросов СУБД Oracle
· Некоторые полезные команды SQL
· Использование встроенных модулей
· Описание ряда особенностей при работе с Oracle
· Что делать при изменении сетевого адреса сервера
· Возможные аварийные ситуации
Запуск и останов БД
Запуск БД
Процесс запуска БД проходит 3 стадии:
Если запустить утилиту SVRMGR 30 и ввести команду
alter database mount ;
alter database open ;
Останов БД
Перенос БД на другой сервер (либо временное удаление БД)
Если не пользоваться механизмами экспорта / импорта или резервного копирования / восстановления, то общая схема такова («сюрпризы» в MS Windows NT 4 здесь не описаны):
Для временного удаления (например, перед форматированием диска):
· Запакуйте разделы % ORACLE _ HOME %\ DATABASE и % ORACLE _ HOME %\ NET 80\ ADMIN с помощью архиватора, сохраняющего длинные имена файлов (например, PKZIP или WINZIP ).
Пакуйте с учетом скрытых файлов. Скопируйте архивы в безопасное место (не на диск, который будет форматироваться).
· Если действительно предстоит форматирование диска, то на всякий случай, чтобы система не кричала:
· Деинсталлируйте Oracle Server
· Удалите каталог %ORACLE_HOME%
Для восстановления БД (после форматирования диска):
· Проинсталлируйте Oracle Server
· Верните на место файлы из архивов
При переносе БД на другой сервер:
· Проинсталлируйте на нем Oracle Server
· Создайте тот же SID
· Установите в вышеупомянутые каталоги файлы из архивов
Экспорт и импорт данных
Экспорт данных
Импорт данных
Резервное копирование и восстановление
Это самые необходимые операции, которые должен уметь использовать администратор БД. Рекомендуется использовать не «горячее» (при запущенном экземпляре), а «холодное» (после останова БД) резервное копирование средствами используемой операционной системы.
Резервное копирование БД Oracle удобно выполнять утилитой Oracle Backup Manager из пакета OEM (см. Часть 1, Глава 6: Oracle Backup Manager ( Var . exe ) ).
Перевод БД на другую версию сервера Oracle ( upgrade и downgrade )
· Шаг 1 : Остановите БД версии 8.0.3.
· Шаг 2: Создайте резервную копию БД версии 8.0.3.
· Шаг 4: Проинсталлируйте Oracle8 Enterprise Edition Release 8.0.4 ( имеется ввиду серверная часть ).
Существуют и другие способы для upgrade БД. Например, сделать полный экспорт БД, инсталлировать новую версию сервера и сделать импорт и пр.
Настройка БД Oracle
Настройка БД Oracle включает в себя, в частности, настройку конфигурационных параметров (в файле INIT SID >. ORA ) и настройку параметров заполнения таблиц и расширения табличных пространств. Настройка конфигурационных параметров уже описывалась в Главе 2 Части 1, здесь же будут приведены некоторые методы определения их оптимальности. Далее эта глава будет постоянно дополняться и уточняться.
Определение оптимальности некоторых конфигурационных параметров
· Для определения, нужно ли изменять размер буферного кэша, введите запрос:
select NAME, VALUE from V$SYSSTAT where NAME in
(‘CONSISTENT_GETS’, ‘DB_BLOCK GETS’, ‘PHYSICAL_READS’);
Затем вычислите коэффициентт попадания в SGA по следующей формуле:
HIT_RATIO = 1-(PHYSICAL READS / (DB BLOCK_GETS + CONSISTENT_GETS)
· Для определения, нужно ли изменять размер разделяемого пула, введите запросы:
select sum(PINS) PINS, sum(RELOADS) RELOADS from V$LIBRARYCACHE;
Если PINS / RELOADS больше 1 – увеличте параметр SHARED_POOL_SIZE
select sum(GETS) GETS, sum(GETMISSES) GETMISSES from V$ROWCACHE;
· Для определения, нужно ли изменять размер области сортировки, введите запрос:
select NAME, VALUE from V$SYSSTAT where NAME like ‘sort%’
Возможен такой результат запроса:
Если sorts ( disk ) больше 0, значит для параметра SORT _ AREA _ SIZE требуется больше памяти
Для параметра SORT _ AREA _ SIZE _ RETAINED можно установить минимальный размер
· Для определения, имеется ли конкуренция за журнальные файлы, введите запрос:
from V$LATCH where NAME in (‘REDO ALLOCATION’, ‘REDO COPY’)
Вычислите два значения :
Если любое значение больше 1, то имеетсяся конкуренцияция за защелку.
· чтобы снизить конкуренцию за защелку выделения журнального буфера – уменьшите параметр LOG _ SMALL _ ENTRY _ MAX _ SIZE
· чтобы снизить конкуренцию за защелку копирования журнала – увеличьте параметр LOG _ SIMULTANEOUS _ COPIES
Некоторые рекомендации по настройке объектов БД
1. Рекомендуемые параметры для таблиц :
Общая р екомендация
Для относи-тельно статичных таблиц
Для таблиц с интенсив-ными изме-нениями
5 или меньше (но не 0)
Все даннае должны помещаться в 1 экстенте с небольшим запасом
От 25% до размера INITIAL
Должно выполняться всегда следующее: PCTFREE + PCTUSED
2. Рекомендации по количеству сегментов отката:
· ж елательно на 5 пользователей 1 RBS;
· обязательно MINEXTENTS не менее 2 и PCTINCREASE не может быть указан
· Если количество одновременных транзакций :
· более 32 использовать 1 RBS на 4 транзакции, но меньше 50
3. Для определения, имеется ли конкуренция за сегменты отката, введите запрос:
select R.NAME, S.GETS, S.WAITS
from V$ROLLSTAT S, V$ROLLNAME R where S.USN=R.USN
Возможен такой результат запроса:
· Для определения, имеется ли конкуренция за ввод-вывод, введите запрос:
from V$DATAFILE D, V$FILESTAT F
Возможен такой результат запроса:
NAME PHYRDS PHYWRTS
D:\ORAWIN95\DATABASE\SYS1ORCL.ORA 648 34
D:\ORAWIN95\DATABASE\USR1ORCL.ORA 0 0
D:\ORAWIN95\DATABASE\RBS1ORCL.ORA 65 75
D:\ORAWIN95\DATABASE\TMP1ORCL.ORA 0 0
D:\ORAWIN95\DATABASE\PLIS1.ORA 6 31
· Для определения степени фрагментации, введите запрос:
TABLESPACE_NAME, sum(BYTES), max(BYTES),
from DBA_FREE_SPACE GROUP BY TABLESPACE_NAME
order by TABLESPACE_NAME
· Для определения, происходит ли чрезмерное динамическое расширение, введите запрос:
select OWNER, SEGMENT_NAME, SUM(EXTENTS)
where SEGMENT_TYPE in (‘TABLE’,’INDEX’)
group by OWNER, SEGMENT_NAME
order by OWNER, SEGMENT_NAME
Рекомендации по уменьшению количества записей на диск и др.
Если при эксплуатации БД Oracle происходят интенсивные транзакции (например, более 10 000 удалений-добавлений-изменений за 1 транзакцию, и более 10 таких транзакций друг за другом при участии нескольких таблиц с количеством записей 100 000 – 1 000 000), то для ускорения работы с жестким диском помогут приведенные ниже рекомендации.
Рекомендуется увеличить размер (например, до 8-16 М) и количество журнальных файлов (например, до 4-8, причем для повышения надежности сделать их 2-4 группами на разных дисках). При этом уменьшится количество переключений журнальных файлов, а при включенной архивации уменьшится количество записей архивных копий журнальных файлов.
alter table BIGTABLE nologging
alter trigger TABLE_LOG disable
Рекомендуется в конфигурационном файле сделать установку для активизации всех сегментов отката при запуске БД. Это приведет к уменьшению количества процессов по активизации сегментов отката при большом количестве транзаций. Установка выполняется с помощью параметра ROLLBACK _ SEGMENTS следующим образом ( R 01.. R 10 – имена сегментов отката):
alter rollback segment R01 storage (optimal 4M)
Если количество записей в БД постоянно увеличивается, рекомендуется заранее увеличить размер основного табличного пространства.
· Журнал изменений EDITIONS (большая таблица, много добавлений, удалений (очисток), нет правок): PCTUSED = 20, PCTFREE = 5;
· Некоторые «тяжелые» таблицы, указанные в приведенных выше рекомендациях 2-3 (очень большие таблицы, очень много добавлений, правок, удалений): PCTUSED = 20, PCTFREE = 10;
· Рабочие таблицы и справочники отдельных филиалов (среднее количество вводов, правок, удалений): PCTUSED = 30, PCTFREE = 30;
· Общие справочники (очень мало ввода, правок, удалений): PCTUSED = 80, PCTFREE = 10;
alter table ТАБЛИЦА pctused 20 pctfree 5
Пути повышения производительности запросов СУБД Oracle
Пути сокращения времени поиска нужных записей в таблицах
Оптимизация запросов Oracle
Даже не пользуясь индексами или кластерами, Oracle способен производить достаточно быстрый поиск в одной небольшой таблице. Однако, если во фразе where в операторе SELECT используется столбец, для которого установлен индекс или кластер, то выборка данных производится гораздо быстрее.
· where ROWID = константа ;
· where уникальный индексированный столбец = константа;
· where полный уникальный составной ключ = константа;
· where полный неуникальный составной ключ = константа;
· where полный несжатый индекс >= нижняя граница;
· where полный сжатый индекс >= нижняя граница;
· where неуникальный индекс = константа
and неуникальный индекс = константа
· where наибольший несжатый индекс >= нижняя граница;
· where наибольший сжатый индекс >= нижняя граница;
· where уникальный индексированный столбец between нижнее значение and верхнее значение или
· where индексированный столбец like ‘С%’ (диапазон с границами);
· where неуникальный индексированный столбец between нижнее значение and верхнее значение или
· where индексированный столбец like ‘С%’ (диапазон с границами);
· where уникальный индексированный столбец константа (диапазон без границ);
· where неуникальный индексированный столбец константа (диапазон без границ);
· order by полный индекс ;
· where max или min от одного индексированного столбца;
· where неиндексированный столбец = константа или
· where столбец is NULL или
· where столбец like ‘%С%’ (поиск по всей таблице).
Термин «составной ключ» означает либо ключ, состоящий из многих столбцов одной и той же таблицы, либо ключ кластера.
3. Другой способ оценки применяется для каждого соединения или внешнего соединения. Соединения оцениваются по числу таблиц, которые должны соединяться без пользования индекса и по числу декартовых произведений. Если какой-нибудь предикат во фразе WHERE имеет низкую оценку на поиск и он представляет собой лишь соединение таблиц без использования индексов, то для “ведущего” столбца будет выбран другой предикат, который выполняет соединение с использованием индексов. Оценка соединения всегда преобладает над суммарной оценкой предикатов.
Запрос с индексированным DEPTNO :
select ENAME, SAL from EMP where DEPTNO in (10,20,40);
выполняются значительно медленнее, чем запрос :
select ENAME, SAL from EMP where DEPTNO in
(select DEPTNO from TEMTABLE);
5. В данной версии все предикаты равноправны и первая таблица во фразе from будет “управляющей” таблицей. Если одна из таблиц в соединении значительно меньше, чем другая, то самую маленькую таблицу следует указать первой.
Некоторые полезные команды SQL
· После создания БД, дабы в этом убедиться, можно выполнить запрос
select NAME from V$DATABASE;
(предварительно нужно приконнектиться как SYSTEM )
· После создания БД также удобно просматривать ее на наличие таблиц, например, такими командами:
(при этом выводится описание структуры таблицы)
select OBJECT_NAME from USER_OBJECTS where OBJECT_TYPE=’TABLE’;
(или можно использовать представление OBJ вместо USER _ OBJECTS )
· Запросы к Словарю БД для просмотра описания или важных параметров пользовательских объектов:
· Просмотр параметра LAST NUMBER в последовательности:
select LAST_NUMBER from USER_SEQUENCES
· Просмотр т екста триггера:
where TABLE_OWNER=’PLIPEKN’ and TRIGGER_NAME=’ACCID_LOG’;
· Просмотр т екст а функции:
select substr(TEXT,1,500) from USER_SOURCE
where TYPE=’FUNCTION’ and NAME=’BRANCH_ID’;
· Просмотр п рав для пользователя:
select PRIVILEGE from SESSION_PRIVS;
· Просмотр ролей для пользователя:
select ROLE from SESSION_ROLES;
· Просмотр прав для роли:
select GRANTED_ROLE from ROLE_ROLE_PRIVS where ROLE=’DBA’;
· Просмотр ролей для роли:
select PRIVILEGE from ROLE_SYS_PRIVS
Использование встроенных модулей
В Oracle 8 существуют следующие встроенные модули (подчеркнутые – используемые в настоящей документации) [2, с.568]:
· DBMS _ ALERT – Синхронное взаимодействие соединений (сеансов)
· DBMS _ APPLICATION _ INFO – Регистрация приложений для трассировки
· DBMS _ AQ и DBMS _ AQADM – Управление средством Oracle 8 Advanced Queuing
· DBMS_SESCRIBE – Описание хранимых подпрограмм
· DBMS _ JOB – Планирование выполнения процедур PL / SQL
· DBMS _ LOB – Работа с объектами LOB в Oracle 8
· DBMS_LOCK – Блокировки, определяемые пользователями
· DBMS _ OUTPUT – Вывод информации на экран
· DBMS _ REFRESH и DBMS _ SNAPSHOT – Работа с моментальными снимками
· DBMS _ ROWID – Получение информации из идентификаторов строк ( ROWID ). Преобразование ROWID Oracle7 в ROWID Oracle8 и наоборот
· DBMS_SESSION – PL/SQL- эквивалент команды alter session
· DBMS _ SHARED _ POOL – Управление разделяемым пулом
· DBMS _ SQL – Динамические PL / SQL и SQL (пример в Главе 3 Части 1)
· DBMS_TRANSACTION – Команды управления транзакциями
· DBMS_UTILITY – Дополнительные служебные процедуры
· UTL_FILE – Файловый ввод-вывод
Эти модули иногда бывают очень полезны (вывод на экран, обмен сообщениями), а в ряде случаев без них не обойтись. Например, при импорте схемы в БД для замены устаревших данных в таблицах данного пользователя необходимо сначала отключить все триггеры и ограничения для этих таблиц, затем удалить все данные, и только после этого производить импорт. Затем нужно опять включить ограничения и триггеры. Чтобы в скрипте не перечислять имена всех таблиц, триггеров и ограничений, можно их выбрать из Словаря данных ( USER _ OBJECTS и др.) и затем использовать как параметры. Это достигается с помощью модуля DBMS _ SQL (в Главе 5 Части 1 это будет подробно описано).
Указанные в заголовке утилиты предназначены для ввода команд SQL ( DML и DDL ), запуска скриптов, просмотра ошибок выполнения команд и ввода других команд, необходимых для управления БД. Следует отметить, что большинство «ручных» действий (т.е. выполняемых фактически в режиме командной строки), можно проще, нагляднее и быстрее осуществить в диалоговом режиме с помощью утилит пакета Oracle Enterprise Manager и других. В то же время, наиболее «тонкое» управление БД, также как и самую исчерпывающую информацию (находящуюся в Словаре БД, состоящим из многих групп таблиц и представлений), можно получить только в режиме командной строки.
Ниже вкратце перечислены лишь некоторые достоинства и недостатки описываемых утилит, что позволит гибко подойти к их выбору в конкретной ситуации.
Описание ряда особенностей при работе с Oracle
Некоторые особенности
Прежде чем менять пароль основного пользователя в распределенной БД учтите следующее:
· Попытка обновления снимков от таблиц БД, где произошла описанная смена пароля будет, естесственно, неудачной, что может привести к зацикливанию таких попыток и приведению всей распределенной БД в нерабочее состояние.
Обнаруженные некорректности
· Неточности и подводные камни в технической документации:
· в останове БД выполняется immediate (хотя при отсутствии сервисов лучше делать normal );
· БД запускается как nomount (потом надо делать alter database open либо «переключить светофор» в Oracle Instance Manager из OEM ).
· Неприятности с версиями Oracle: