Выпуск 5 - СУБД Oracle "с нуля"
Выпуск 5
Уважаемые подписчики, сегодня мы продолжаем изучение теоретической части СУРБД
Oracle. Очень скоро настанет время некоторых практических вопросов, упражнений
и экспериментов. Как всегда, предлагаю Вам несложные вопросы, ответив на которые,
Вы будете уверены, что предыдущие выпуски прочитаны достаточно внимательно.
1) Назовите основное узкое место СУРБД Oracle.
2) Какие основные элементы составляют экземпляр Oracle?
3) В каком случае выгодно запускать несколько процессов DBWR?
4) Для чего нужны диспетчерские процессы?
5) Какие преимущества дает индексирование таблиц?
Как работает транзакция
Из предыдущих выпусков мы уже знаем, что транзакция - это одна или более SQL-команд,
завершенных фиксацией или откатом. Под фиксацией (commiting) понимается принятие
и сохранение всех изменений. Откат (rollbacking) - это процедура отмены последних
изменений, т.е. возврат к предыдущему состоянию БД. Чтобы понять, как работает
система Oracle, мы по шагам рассмотрим
пример работы простой транзакции. Замечу, что для работы данного примера необходим
SQL*Net (сетевой протокол Oracle), так как мы будем иметь дело с клиент-серверным
приложением. Итак, транзакция выполняется следующим образом:
1. Приложение обрабатывает пользовательский ввод и создает соединение с сервером
посредством SQL*Net.
2. Сервер принимает запрос на соединение и создает серверный процесс.
3. Пользователь выполняет SQL-команду (или совокупность команд). В нашем примере
будем считать, что пользователь изменяет данные в строке таблицы.
4. Серверный процесс просматривает разделяемый пул - есть ли там SQL-область
с идентичными SQL-командами. Если он находит аналогичную разделяемую SQL-область,
то серверный процесс проверяет права пользователя на доступ к данным. Предположим,
что права есть, тогда серверный процесс выполняет команды, используя разделяемую
SQL-область. Однако, если разделяемая SQL-область не найдена, то выделяется
память под новую, а затем происходит разбор и выполнение SQL-команд.
5. Серверный процесс ищет данные в SGA (если они есть в buffer cache) или считывает их
из файла данных в кэш буферов.
6. Серверный процесс изменяет данные в SGA. Запомните, что серверный процесс
может только читать данные из файла данных. Позже процесс DBWR запишет измененные
блоки данных в постоянное хранилище.
7. Пользователь выполняет команду COMMIT (фиксация) или ROLLBACK (откат).
COMMIT завершает транзакцию, а ROLLBACK отменяет изменения. Если транзакция
зафиксирована, то процесс LGWR немедленно записывает ее в файл журнала изменений.
8. Если транзакция успешно завершена, то клиентскому процессу передается код
завершения. Если произошел какой-либо сбой, то возвращается сообщение об ошибке.
Замечание 1: Транзакция не считается зафиксированной
до тех пор, пока не завершена запись в файл журнала изменений (redo log file).
Этот механизм способствует тому, что в случае сбоя зафиксированная транзакция
может быть восстановлена. Если транзакция зафиксирована - это все равно, что
выплавить надпись в металле. Только серьезное стихийное бедствие может стереть
ее в
порошок.
Замечание 2: Для простоты понимания транзакции в предыдущем алгоритме некоторые шаги были опущены.
Чтобы лучше понять весь механизм транзакции, советую Вам проделать следующую
процедуру. Возьмите лист бумаги, нарисуйте клиента и сервер, а на сервере разделяемый
пул, SQL-области и SGA. А затем, по предыдущим восьми шагам, нарисуйте стрелочками
все операции, выполняемые процессами.
Функции СУРБД ORACLE
При работе с СУРБД Oracle Вы должны организовать выполнение таких функций
как целостность данных, восстановление после сбоев, перехват ошибок и т.д. Это
можно устроить посредством контрольных точек, журналирования и архивирования.
Рассмотрим далее некоторые из этих функций.
Создание контрольных точек (checkpointing)
Как мы уже знаем, сигнал к созданию контрольной точки поступает либо от процесса
DBWR, либо от LGWR. Но что же такое контрольная точка? И для чего она необходима?
Так как все изменения блоков данных происходят в блоковых буферах, то изменения
данных в памяти не обязательно отражаются в этих блоках на диске. Процесс кэширования
происходит по алгоритму последнего использованного блока, поэтому буфер, подверженный
постоянным изменениям, помечается как последний использованный, и процесс DBWR
не записывает его на диск. Контрольная точка применяется для того, чтобы эти
буферы были записаны на диск. Все грязные буферы вынуждены быть сохранены на
диске в обязательном порядке. Но это вовсе не означает, что вся работа прекращается
в момент выполнения контрольной точки.
Контрольная точка может выполняться в двух режимах: быстрая контрольная точка
и нормальная контрольная точка. В режиме нормальной контрольной точки процесс
DBWR просто записывает
немного больше грязных буферов в каждый момент своей активности. В этом режиме
контрольная точка выполняется гораздо дольше, но затрагивает меньше системных
ресурсов, чем быстрая. В режиме быстрой контрольной точки DBWR записывает сразу
большое число буферов в каждый момент своей работы. Такая контрольная точка
выполняется очень быстро и более эффективна в смысле работы ввода/вывода. Но,
в тоже время, значительно снижает производительность системы.
Частое выполнение контрольных точек способствует снижению затрат времени, необходимого
на восстановление системы в случае сбоя. Контрольная точка автоматически выполняется
при смене журнала операций.
Журналирование и архивирование
Журнал операций (redo log) записывает все изменения БД Oracle. Целью использования
журнала операций является экстренное восстановление БД в некоторых случаях
сбоев системы и потери файлов данных. Восстановив файлы данных из ранее сделанных
резервных копий, файлы журнала операций (включая архивные файлы журнала) могут
повторить все последние транзакции. Таким
образом, файлы данных будут полностью восстановлены.
Когда файл журнала операций (или группа файлов) оказывается полностью заполненным, происходит смена
журнала и процесс LGWR перключается на следующую группу файлов журналирования операций. В этот момент осуществляется контрольная точка, а после смены журнала процесс ARCH
копирует заполненный файл в архив файлов журналирования. Как только
архивирование закончилось, файл журнала операций помечается как доступный.
Очень важно, чтобы архивные файлы журнала операций надежно хранились, так как
они могут понадобиться для восстановления системы.
Примечание: Как говорилось ранее, транзакция
не считается зафиксированной до тех пор, пока она не будет записана в файл журнала
операций. Если файлы журнала операций будут храниться на дисках с медленным
вводом/выводом, то затормозится работа всей системы.
Производительность ORACLE
В первую очередь на производительность Oracle влияет архитектура аппаратных
средств. Но существует также ряд других факторов. Например, дизайн пользовательского
приложения может затронуть эффективность и скорость работы больше, чем все остальные
факторы.
В большинстве случаев причиной небольшой производительности системы является
именно приложение, в котором либо неоптимизированные SQL-запросы, либо не используются
индексы. Хороший же дизайн приложения способен творить чудеса производительности.
Приложение - это первое место, куда нужно обратить внимание, если у Вас возникают
проблемы с производительностью.
Если Вы создадите таблицу, в которой некоторые столбцы проиндексированы, но
эти столбцы не используются в предложении WHERE, то индексы никогда не будут
использованы. Создавать правильные и красивые индексы недостаточно, Вы должны
быть уверены в том, что они будут использованы.
Совет: Желательно создать спецификацию
идентификации таблиц и индексов в Вашей БД. В этом случае разработчики ПО и
команда, разрабатывающая таблицы, будут иметь исчерпывающее руководство. Это
поможет избежать многих проблем, а также даст возможность полноценного использования
индексов.
Задачи, связанные с обработкой большого количества транзакций в реальном времени
или с доступом к большим хранилищам данных, неизменно приводят к высокой конкуренции
пользователей за обладание ресурсами. Поэтому решение проблемы управления доступом
пользователей к ресурсам может существенно повысить эффективность работы системы.
Oracle 8i предоставляет возможности управления выделением пользователю системных
ресурсов и назначением приоритета
пользователям - им может быть присвоен класс ресурсов, а затем каждому классу
назначен соответствующий процент ресурсов системы.
В Oracle 8i была введена технология секционирования (partitioning), которая
позволяет загружать большие таблицы и индексы по частям, а не как единое целое,
и дает существенный выигрыш в производительности СУБД. Причина выигрыша заключается
в том, что при выполнении запроса к базе данных оптимизатор исключает из области
поиска разделы, которые не содержат данных, относящихся к запросу. Наряду с
ранговым секционированием, использовавшимся ранее, в Oracle 8i представлены
два других механизма секционирования - композитное и хэш-секционирование, что
дает возможность администратору выбрать метод секционирования с целью повышения
эффективности работы конкретной системы.
Хэш-секционирование предоставляет простой способ разделения данных на контейнеры
одинакового размера, которые распределяются по разным устройствам ввода/вывода
и даже по разным машинам. Производительность запроса в этом случае повышается
за счет распределения операций ввода/вывода по разным устройствам. При этом
улучшается производительность как обычных, так и параллельных запросов. Композитное
секционирование объединяет преимущества
рангового и хэш-секционирования - первоначально данные секционируются по рангу
значения, а затем администратор определяет количество хэш-подразделов. При этом
гарантируется полная поддержка локальных индексов и синтаксиса SQL, как при
работе с обычными (несекционированными) таблицами.
В Oracle 8i включены и другие усовершенствования, улучшающие производительность
приложений, работающих с хранилищами данных, и упрощающие управление ими. В
частности, перестройку индексов можно теперь выполнять в режиме реального времени,
не прерывая операций, связанных со вставкой, изменением и удалением записей,
производимых в базовой таблице.Теперь можно
создавать индексы, упорядоченные по убыванию значений индексируемой величины,
что помогает обеспечить быстрый доступ в тех случаях, когда возвращаемые столбцы
должны быть отсортированы по убыванию. Улучшены возможности мониторинга за выполнением
длительных процессов, таких как формирование индексов или резервное копирование.
Параллельный сервер ORACLE
Параллельный сервер Oracle позволяет разделить доступ к базе данных между
разными серверными процессами (Oracle instance), причем каждый из процессов
может обрабатывать конкурирующие транзакции. Различные серверные процессы, работающие
с одной и той же базой данных, могут быть запущены на разных машинах, формируя
тем самым отдельный кластер. Это резко повышает надежность работы системы, поскольку
параллельный сервер Oracle в состоянии
отловить аварийную ситуацию, произошедшую с одной из машин кластера, практически
мгновенно, после чего база данных продолжает оставаться доступной через серверный
процесс, запущенный на другой машине.
В версии Oracle 8i внесен ряд усовершенствований, улучшающий работу параллельного
сервера в плане повышения производительности и управляемости. Появился специальный
мастер настройки параллельного сервера, улучшена диагностика ошибок, ведется
статистика распределения кэш-памяти между серверными процессами, введен новый
механизм связи между серверными процессами, повысивший производительность операций
чтения. При этом данный механизм,
получивший наименование Сервер согласованного чтения, обеспечивает работу существующих
приложений, реализованных в среде параллельного сервера Oracle, без какой-либо
модификации.
Репликация данных
Репликация - это процесс копирования и поддержания объектов БД на множестве
серверов, составляющих распределенную информационную систему. Изменения, производимые
на одном сервере системы, затем передаются на удаленные серверы. Репликации
позволяют пользователю получить быстрый доступ к разделяемой информации и организовать
синхронизацию данных.
Репликации в среде Oracle могут происходить по двум схемам: мастер-мастер и
мастер-snapshot.
В первом случае два или несколько серверов БД функционируют как равные части
единой системы. При такой конфигурации клиентские приложения могут изменять
данные на любом из серверов - серверы БД Oracle автоматически синхронизируют
данные во всех объектах репликаций, гарантируя при этом глобальную целостность
данных и поддержку конкурирующих транзакций.
Схема мастер-snapshot предусматривает частичное или полное копирование объектов
репликации с одного сервера БД на другой. При этом полученная копия представляет
собой "мгновенный снимок" (snapshot) данных, содержащихся в объектах
БД, подлежащих реплицированию. Такие "мгновенные снимки" могут иметь
статус "только для чтения" или быть обновляемыми. Обновляемые snapshots
позволяют клиенту возвращать изменения в реплицируемые объекты на мастер-сервере.
В целях повышения производительности системы при осуществлении процессов репликации
данных, разработчики Oracle стремятся перенести код, ответственный за репликации,
в ядро СУБД. В версии 8.0.3 внутрь ядра были перенесены триггеры, использовавшиеся
при репликациях, в Oracle 8i
версии 8.1.5 сюда же переносятся сгенерированные пакеты (packages), используемые
для применения этих реплицированных транзакций на удаленных узлах. За счет этого,
а также за счет оптимизации процессов пересылки информации, увеличена производительность
обновления snapshots.
Многие характеристики Oracle 8i разрабатываются для того, чтобы помочь пользователям,
реализующим приложения "переднего плана", офисной автоматизации и
автоматизации деятельности мобильных средств связи. Шаблоны группы обновления
snapshots, а также дополнительные возможности проверки Менеджера Репликации
Oracle (Oracle Replication Manager) позволяют администраторам централизованно
определять сотни удаленных узлов, в которых создаются
snapshots, и управлять ими. Шаблоны группы обновления snapshots позволяют создавать
определения удаленных snapshots на центральном узле системы. Так как все эти
новые возможности Oracle 8i Advanced Replication поддерживаются также и Oracle
Lite, организации могут развертывать свои приложения на легких, мобильных базах
данных, не жертвуя никакими функциональными возможностями.
На этом я завершаю пятый выпуск рассылки.
Всегда Ваш - Lemon
При создании выпуска использовалась часть материалов статьи
"Oracle
8i - база данных для Интернета" Георгия Шахова.
|
