Списочное секционирование

Списочное секционирование позволяет разбить таблицу по списку дискретных значений.

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

Списочные секции можно добавить, при этом должна отсутствовать секция DEFAULT, в противном случае прибегают к рассечению секции DEFAULT. Списочные секции можно удалить, слить, добавить/сократить список ключей.

Композитное секционирование

При секционировании большой таблицы сами секции могут оказаться достаточно крупными. Такие секции могут секционироваться по другому критерию секционирования. Такое двухуровневое секционирование называется композитным (допускается 2 уровня секционирования(секции и подсекции)).

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

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

Эквисекционирование

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

Идентичность секций или подсекций позволяет соединять их попарно (параллельная попарная обработка может выполняться достаточно быстро, так называемые "Partition-Wise Joins", минимизируется обмен данными между параллельными процессами и узлами в RAC), локализованность проблем при управлении и сбоях.

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

Секционирование по ссылке

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

Секционирование по виртуальному столбцу

Виртуальные столбцы – столбцы в таблице, значения в которых вычисляются динамически, "на лету", при обращении к таблице (данные в таблице физически не хранятся).

Системное секционирование

Системное секционирование -- "беcключевое" секционирование, где секционированием данных управляет приложение, а не сама СУБД, как в других видах секционирования.

41. Pipe

Пакет DBMS_PIPE

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

• Каналы являются асинхронными – они действуют независимо от транзакций. Поэтому не существует способа отменить сообщение, посланное в канал, даже если сеанс, который его послал, выполнил ROLLBACK.

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

• Сообщения посылаются в канал отправителем, который сначала упаковывает их в буфер, а затем посылает буфер.

Приемник получает буфер и распаковывает сообщение.

• Публичные (Public) – канал доступен всем пользователям, которые знают название канала.

• Частные (Private) – канал доступен только создателю канала, сессии с тем же USER_ID, что и у создателя канала, пользователям, подключенным как SYSDBA.

• CREATE_PIPE – создание канала

• NEXT_ITEM_TYPE – проверяет тип следующего сообщения

• PACK_MESSAGE – помещает элементы в локальный буфер

• PURGE – очистка содержимого канала

• RECEIVE_MESSAGE – прием сообщение и копирование его в локальный буфер

• REMOVE_PIPE – удаление канала

• SEND_MESSAGE – отправка сообщений в канал

• UNIQUE_SESSION_NAME – получает уникальное имя среди всех сессий, соедененных в данный момент с БД.

• UNPACK_MESSAGE – извлечение элемента из локального буфера

42. Oracle Stream

Oracle Streams – это средство СУБД, позволяющее переносить данные, транзакции и события в потоке данных внутри одной или между базами данных. Это более поздняя, чем "обычная" репликация (репликация на основе материализованных представлений) ), модель организации непрерывного переноса данных как внутри, так и между базами данных.

Oracle Streams предоставляет набор элементов, которые позволяют пользователю управлять:

• тем какую информацию помещать в поток

• как должен «течь» поток

• как он должен маршрутизироваться с одно сервера на другой

• что должно происходить, когда поток приходит на сервер

• где он должен прерываться. 

Oracle Streams применяется в качестве решения для различных областей :

• Репликация

• Очереди сообщений

• Загрузка хранилищ данных

Технически потоки Oracle Streams опираются на созданный независимо и ранее аппарат организации очередей передачи сообщений, известный под названием Oracle Advanced Queuing ,а также используют Dblink для передачи информации между исходной и целевой базами данных.

В отличие от "обычной" репликации Oracle Streams не требует заведения особых структур в БД (журналов таблиц, materialized views). Репликация в Oracle Streams основана на обработке информации из журнала БД.

основных компонента Oracle Streams:

1. Capture – процесс сбора данных на источнике

2. Propagation- процесс передачи данных от источника к целевой базе данных

3. Apply – процесс применения изменений в целевой базе данных

Capture(фоновый процесс)

Сбор осуществляется двумя способами:

• Неявный сбор. Серверный процесс сбора собирает DML и DDL события в исходной базе данных непосредственно из журналов (redo log), либо с помощью горячего «раскапывания» (hot mining), либо, при необходимости, из архивных журналов (archive log). После извлечения данных процесс сбора форматирует их в Logical Change Record (LCR) и помещает в область распространения для дальнейшей обработки. Процесс сбора может фильтровать LCRы по заданным правилам. Таким образом буду собираться изменения только заданных объектов.

• Явный сбор. Позволяет приложению явным образом сгенерировать сообщение и поместить его в область хранения. Эти сообщения могут быть отформатированы как LCR (дает возможность автоматически применить их процессом применения (apply process), либо как пользовательские сообщения, предназначенные для потребления другим пользовательским приложением.

Capture:

1. Работает на стороне исходной БД

2. Работают на основе правил;

3. Просматривает средствами LogMiner журналы повтора и архив;

4.Выбирает из журналов изменения в исходной БД ;

5. Формирует логическую запись об изменении, Logical Change Record (LCR);

6. Помещает LCR в качестве события в очередь Streams Advanced Queuing (SAQ).

Propagation (фоновый процесс)

1. Находится на стороне исходной БД

2. Работает на основе правил

3. Выбирает события из очереди SAQ, сформированной Capture

4. Помещает их в очереди на целевой БД через Oracle Net.

Apply (фоновый процесс)

1. Находится на стороне целевой БД

2. Работает на основе правил

3. Выбирает изменения(LCR) из очереди на целевой базе данных.

4. Применяет изменения на целевой БД.

Правила(rules)

1. Capture: определяют перечень данных, которые собираются capture и очередь для записи изменений(LCR) в исходной базе данных.

2.Propagation: определяет очередь в исходной базе данных с изменениями и очередь в целевой базе данных для применения изменений

3.Apply: определяют входную очередь и перечень объектов, подлежащих изменению с изменениями(LCR)

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

\

43. Logminer

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

Для этого существует специальный инструмент под названием LogMiner.

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

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

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

На втором этапе импортируются файлы журнала повторного выполнения, и запускается LogMiner. После запуска основного пакета LogMiner можно просматривать содержимое файлов журнала повторного выполнения с помощью SQL-операторов. Для анализа содержимого загруженных файлов журнала используется представление V$LOGMNR_CONTENTS.

Пакет DBMS_LOGMNR_D содержит всего одну процедуру - BUILD. Она применяется для создания словаря данных, используемого пакетом DBMS_LOGMNR при загрузке файла журнала повторного выполнения. Словарь позволяет сопоставить идентификаторам объектов имена таблиц, определить имена и типы данных столбцов по порядковому номеру и т.д. Использовать процедуру DBMS_LOGMNR_D.BUILD очень просто. Она имеет два параметра:

• DICTIONARY_FILENAME. Имя файла словаря, который необходимо создать.

• DICTIONARY_LOCATION. Каталог, в котором этот файл будет создан.

Пакет DBMS_LOGMNR состоит из трех процедур:

• ADD_LOGFILE. Зарегистрировать набор файлов журнала для анализа.

• START_LOGMNR. Заполнить данными представление V$LOGMNR_CONTENTS.

• END_LOGMNR. Освободить все ресурсы, выделенные при работе LogMiner. Эта процедура вызывается для корректного освобождения ресурсов перед завершением сеанса или при окончании работы с пакетами LogMiner.

44. Monitoring

DBMS_MONITOR: трассировка дейсвий в рамках сеанса (своего или чужого).

DBMS_MONITOR: модель служба-модуль-действие.

просмотр трассировочных файлов с помощью

утилит trcsess/ tkprof

45. EXTERNAL TABLE

Внешние таблицы: необходимы для доступа (SELECT) к файлам операционной системы, как таблицам базы данных.

Алтернатива: SQL Loader, не всегда удобно с ней работать, требуется запуск с командной строки.

Алтернатива: загрузить файл в CLOB

Внешние таблицы: основное отличие от нормальных таблиц – нельзя изменять данные с помощью DML, изменять можно с помощью команд (или API) файловой системы.

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

Внешние таблицы: применяются

периодический (редкий) ввод внешней информации в базу данных;

join внешних и внутренних таблиц.

Внешние таблицы: ограничения

нельзя PRIMARY KEY/FOREIGN KEY;

нельзя NOT NULL;

нельзя UNIQUE;

нельзя индексировать;

нельзя insert, delete, update;

н ельзя BFILE, LONG, LONG RAW, объекты.

Внешние таблицы: создание

должнен быть директорий;

для доступа: GRANT READ/WRITE ON DURICTORY;

выбрать драйвер доступа: ORACLE_LOADER или ORACLE_DATAPUMP.