События в базе данных
реклама
Билет №1
1. Основные характеристики СУБД Oracle.
управление большими базами данных и контроль управления пространством ORACLE поддерживает самые большие базы данных, потенциального размера до сотен гигабайт.
Чтобы обеспечить действенный контроль за использованием дорогостоящих дисковых устройств,
он предоставляет полный контроль распределения пространства.
много одновременных пользователей базы данных ORACLE поддерживает большое число пользователей, одновременно
выполняющих
разнообразные приложения, которые оперируют одними и
теми же данными. Он минимизирует
соперничество за данные и гарантирует согласованность данных.
высокая производительность обработки транзакций ORACLE поддерживает все описанные выше средства, сохраняя высокую степень суммарной
производительности системы. Пользователи базы данных не страдают от низкой
производительности обработки.
высокая степень готовности На некоторых установках ORACLE работает 24 часа в сутки, не имея
периодов разгрузки,
ограничивающих пропускную способность базы данных. Нормальные системные операции, такие
как откат базы данных, а также частичные сбои компьютерной системы, не прерывают работу с
базой данных.
управляемая доступность ORACLE может выборочно управлять доступностью данных, как на уровне базы данных, так и на
более низких уровнях. Например, администратор может отключить доступ к конкретному
приложению (с тем, чтобы можно было осуществить перезагрузку данных этого приложения), не
затрагивая других приложений.
Пром. стандарты
ORACLE удовлетворяет промышленно принятым стандартам по языку
доступа к данным,
операционным системам, интерфейсам с пользователем и сетевым протоколам. Это "открытая"
система, которая защищает инвестиции заказчика.
Сервер ORACLE7 был сертифицирован Национальным институтом
стандартов и технологий
США как 100%-совместимый со стандартом
ANSI/ISO SQL89. ORACLE7 полностью
удовлетворяет требованиям
правительственного стандарта США FIPS127-1 и имеет
"маркировщик" для подчеркивания нестандартных применений SQL.
Кроме того, ORACLE7 был оценен Правительственным национальным центром компьютерной
безопасности (NCSC) как совместимый с критериями защиты Оранжевой книги; сервер ORACLE7 и
Trusted ORACLE7 отвечают соответственно как уровням C2 и B1 Оранжевой книги, так и
сравнимым с ними европейским критериям защиты ITSEC.
управляемая защита
Для защиты от несанкционированного доступа к базе данных ORACLE предоставляет
защищенные от сбоев средства безопасности, лимитирующие и отслеживающие доступ к данным.
Эти средства позволяют легко управлять даже наиболее сложными схемами доступа.
автоматизированное обеспечение целостности ORACLE автоматически поддерживает целостность данных, соблюдая "организационные
правила", которые диктуют стандарты приемлемости данных. Как следствие, устраняются затраты
на кодирование и сопровождение проверок в многочисленных приложениях базы данных.
окружение клиент/сервер (распределенная обработка) -
Чтобы извлечь максимум преимуществ из данной компьютерной системы или сети, ORACLE
позволяет разделять работу между сервером базы данных и прикладными программами клиентов.
Вся тяжесть управления совместно используемыми данными может быть сосредоточена в
компьютере, выполняющем СУБД, в то время как рабочие станции, на которых работают
приложения, могут сконцентрироваться на интерпретации и отображении данных.
системы распределенных баз данных В компьютерных окружениях, соединенных сетями, ORACLE комбинирует данные, физически
находящиеся на разных компьютерах, в одну логическую базу данных, к которой имеют доступ все
пользователи сети. Распределенные системы обладают такой же степенью прозрачности для
пользователей и согласованности данных, что и нераспределенные системы, предоставляя в то же
время преимущества управления локальной базой данных.
переносимость Программное обеспечение ORACLE переносимо между различными операционными системами
и одинаково во всех системах. Приложения, разрабатываемые для ORACLE, могут быть
перенесены в любую операционную систему с минимумом модификаций или вообще без таковых.
совместимость программное обеспечение ORACLE совместимо с промышленными стандартами, включая
большинство стандартных операционных систем. Приложения, разрабатываемые для ORACLE,
могут использоваться в любой операционной системе с минимумом
модификаций или вообще
без таковых.
Связываемость программное обеспечение ORACLE позволяет различным типам
компьютеров и
операционных систем совместно использовать информацию посредством сетей.
2. Файловые системы и базы данных.
С появлением магнитных дисков началась история систем управления данными во внешней памяти.
До этого каждая прикладная программа, которой требовалось хранить данные во внешней памяти,
сама определяла расположение каждой порции данных на магнитной ленте или барабане и
выполняла обмены между оперативной памятью и устройствами внешней памяти с помощью
программно-аппаратных средств низкого уровня (машинных команд или вызовов соответствующих
программ операционной системы). Такой режим работы не позволяет или очень затрудняет
поддержание на одном внешнем носителе нескольких архивов долговременно хранимой
информации. Кроме того, каждой прикладной программе приходилось решать проблемы
именования частей данных и структуризации данных во внешней памяти. Историческим шагом
явился переход к использованию централизованных систем управления файлами. С точки зрения
прикладной программы, файл - это именованная область внешней памяти, в которую можно
записывать и из которой можно считывать данные. Правила именования файлов, способ доступа к
данным, хранящимся в файле, и структура этих данных зависят от конкретной системы управления
файлами и, возможно, от типа файла. Система управления файлами берет на себя распределение
внешней памяти, отображение имен файлов в соответствующие адреса во внешней памяти и
обеспечение доступа к данным.
В современных файловых системах явно или неявно выделяется некоторый базовый уровень. На
этом уровне обеспечивается работа с файлами, состоящими из блоков, прямо адресуемых в
адресном пространстве файла. Размер этих логических блоков файла совпадает или кратен размеру
физического блока диска и обычно выбирается равным размеру страницы виртуальной памяти,
поддерживаемой аппаратурой компьютера совместно с операционной системой.
В некоторых файловых системах базовый уровень доступен пользователю, но более часто
прикрывается некоторым более высоким уровнем, стандартным для пользователей. Распространены
два основных подхода.
При первом подходе, применяемом, например, в файловых системах операционных систем фирмы
DEC RSX и VMS, пользователи представляют файл как последовательность записей. Каждая запись
- это байтовая последовательность постоянного или переменного размера. Записи можно читать или
записывать последовательно или позиционировать файл на запись с указанным номером.
Некоторые файловые системы позволяют разбивать записи на поля и объявлять некоторые поля
ключами записи. В таких файловых системах можно потребовать выборку записи из файла по ее
заданному ключу. Естественно, что в этом случае файловая система поддерживает в том же (или
другом, служебном) базовом файле дополнительные невидимые пользователю служебные
структуры данных. Распространенные способы организации ключевых файлов основываются на
технике хэширования и B-деревьев. Существуют и многоключевые способы организации файлов.
Второй подход, ставший распространенным вместе с операционной системой UNIX, состоит в том,
что любой файл представляется как последовательность байтов. Из файла можно прочитать
указанное число байтов, либо начиная с его начала, либо предварительно произведя его
позиционирование на байт с указанным номером. Аналогично, можно записать указанное число
байтов в конец файла, либо предварительно выполнив позиционирование файла. Заметим, что, тем
не менее, во всех разновидностях файловых систем ОС UNIX поддерживается базовое блочное
представление файла, которое скрыто от пользователей.
Конечно, для обоих подходов можно обеспечить набор преобразующих функций, приводящих
представление файла к некоторому другому виду. Один из примеров - наличие стандартной
файловой среды системы программирования на языке Си в операционных системах фирмы DEC.
Все современные файловые системы поддерживают многоуровневое именование файлов за счет
поддержания во внешней памяти дополнительных файлов со специальной структурой - каталогов.
Каждый каталог содержит имена каталогов и/или файлов, содержащихся в данном каталоге. Таким
образом, полное имя файла состоит из списка имен каталогов плюс имя файла в каталоге,
непосредственно указывающем на данный файл. Разница между способами именования файлов в
разных файловых системах состоит в том, с чего начинается эта цепочка имен.
Имеются два крайних варианта. Во многих системах управления файлами требуется, чтобы каждый
архив файлов (полное дерево справочников) целиком располагался на одном дисковом пакете (или
логическом диске, разделе физического дискового пакета, представляемом с помощью средств
операционной системы как отдельный диск). В этом случае полное имя файла начинается с имени
дискового устройства, на котором установлен соответствующий диск. Такой способ именования
используется в файловых системах фирмы DEC, очень близко к этому находятся и файловые
системы персональных компьютеров. Можно назвать эту организацию поддержанием
изолированных файловых систем.
В файловой системе Miltics пользователи представляли всю совокупность каталогов и файлов как
единое дерево. Полное имя файла начиналось с имени корневого каталога, и пользователь не обязан
был заботиться об установке на дисковое устройство каких-либо конкретных дисков. Сама система,
выполняя поиск файла по его имени, запрашивала оператора об установке необходимых дисков.
Такую файловую систему можно назвать полностью централизованной.
Конечно, во многом централизованные файловые системы удобнее изолированных: система
управления файлами принимает на себя больше рутинной работы. Но в таких системах возникают
существенные проблемы, если кому-то требуется перенести поддерево файловой системы на другую
вычислительную установку.
Компромиссное решение применено в файловых системах ОС UNIX. На базовом уровне в этих
файловых системах поддерживаются изолированные архивы файлов. Один из этих архивов
объявляется корневой файловой системой. После запуска системы можно "смонтировать" корневую
файловую систему и ряд изолированных файловых систем в одну общую файловую систему.
Технически это производится с помощью создания в корневой файловой системе специальных
пустых каталогов. Специальный системный вызов mount ОС UNIX позволяет подключить к одному
из этих пустых каталогов корневой каталог указанного архива файлов. После монтирования общей
файловой системы именование файлов производится так же, как если бы она с самого начала была
централизованной. Если учесть, что обычно монтирование файловой системы производится при
раскрутке системы, то пользователи ОС UNIX обычно и не задумываются об исходном
происхождении общей файловой системы.
2.3. Защита файлов
Поскольку файловые системы являются общим хранилищем файлов, принадлежащих, вообще
говоря, разным пользователям, системы управления файлами должны обеспечивать авторизацию
доступа к файлам. В общем виде подход состоит в том, что по отношению к каждому
зарегистрированному пользователю данной вычислительной системы для каждого существующего
файла указываются действия, которые разрешены или запрещены данному пользователю.
Существовали попытки реализовать этот подход в полном объеме. Но это вызывало слишком
большие накладные расходы как по хранению избыточной информации, так и по использованию
этой информации для контроля правомочности доступа.
Поэтому в большинстве современных систем управления файлами применяется подход к защите
файлов, впервые реализованный в ОС UNIX. В этой ОС каждому зарегистрированному
пользователю соответствует пара целочисленных идентификаторов: идентификатор группы, к
которой относится этот пользователь, и его собственный идентификатор в группе. При каждом
файле хранится полный идентификатор пользователя, который создал этот файл, и фиксируется,
какие действия с файлом может производить его создатель, какие действия с файлом доступны для
других пользователей той же группы и что могут делать с файлом пользователи других групп. Эта
информация очень компактна, требующиеся при проверке действия невелики, а такой способ
контроля доступа удовлетворителен в большинстве случаев.
2.4. Режим многопользовательского доступа
Последнее, на чем мы остановимся в связи с файлами, это способы их использования в
многопользовательской среде. Если операционная система поддерживает многопользовательский
режим, вполне реальна ситуация, когда два или более пользователя одновременно пытаются
работать с одним и тем же файлом. Если все пользователи собираются только читать файл, ничего
страшного не произойдет. Но если хотя бы один из них будет изменять файл, для корректной работы
этих пользователей требуется взаимная синхронизация.
В системах управления файлами обычно применялся следующий подход. В операции открытия
файла (первой и обязательной операции, с которой должен начинаться сеанс работы с файлом)
среди прочих параметров указывался режим работы (чтение или изменение). Если к моменту
выполнения этой операции от имени некоторого пользовательского процесса A файл уже находился
в открытом состоянии от имени некоторого другого процесса B, причем файл был открыт в режиме,
который несовместим с желаемым режимом открытия (совместимы только режимы чтения), то в
зависимости от особенностей системы процессу A либо сообщалось о невозможности открытия
файла в желаемом режиме, либо он блокировался до тех пор, пока в процессе B не выполнялась
операция закрытия файла.
Заметим, что в ранних версиях файловой системы ОС UNIX вообще не были предусмотрены какие
бы то ни было средства синхронизации параллельного доступа к файлам. Операция открытия файла
выполнялась всегда для любого существующего файла, если пользователь, от имени которого
выполнялся процесс, имел соответствующие права доступа. При совместной работе синхронизацию
приходилось производить вне файловой системы (и специальных средств для этого ОС UNIX не
предоставляла). В современных реализациях файловых систем ОС UNIX по выбору поддерживается
синхронизация при открытии файлов. Кроме того, существует возможность синхронизации
нескольких процессов, параллельно модифицирующих один и тот же файл. Для этого введен
специальный механизм синхронизационных блокировок диапазонов адресов открытого файла.
3. Области применения файлов
Прежде всего файлы применяются для хранения текстовых данных: документов, текстов программ и
т. д. Такие файлы обычно образуются и модифицируются с помощью различных текстовых
редакторов. Структура текстовых файлов обычно очень проста: это либо последовательность
записей, содержащих строки текста, либо последовательность байтов, среди которых встречаются
специальные символы (например, символы конца строки).
Файлы с текстами программ являются входными параметрами компиляторов, которые, в свою
очередь, формируют файлы, содержащие объектные модули. С точки зрения файловой системы,
объектные файлы также обладают абсолютно стандартной структурой - последовательности записей
или байтов. Система программирования накладывает на эту структуру более сложную и
специфичную для этой системы структуру объектного модуля. Подчеркнем, что логическая
структура объектного модуля неизвестна файловой системе, эта структура поддерживается
программами системы программирования.
Аналогично обстоит дело с файлами, формируемыми редакторами связей (компоновщиками
выполняемых программ) и содержащими образы выполняемых программ. Логическая структура
таких файлов остается известной только редактору связей и программе-загрузчику, являющейся
компонентом операционной системы.
Заметим, что в отмеченных выше случаях вполне достаточно тех средств защиты файлов и
синхронизации параллельного доступа, которые обеспечивают системы управления файлами. Очень
редко возникает потребность параллельной модификации файлов, и как правило, каждый
пользователь может обойтись своей частной копией.
Другими словами, файловые системы обычно обеспечивают хранение слабо структурированной
информации, оставляя дальнейшую структуризацию прикладным программам. В перечисленных
выше случаях использования файлов это даже хорошо, потому что при разработке любой новой
прикладной системы, опираясь на простые, стандартные и сравнительно дешевые средства
файловой системы, можно реализовать те структуры хранения, которые наиболее естественно
соответствуют специфике данной прикладной области.
Однако для информационных систем ситуация коренным образом отличается. Эти системы главным
образом ориентированы на хранение, выбор и модификацию постоянно хранимой информации.
Структура информации обычно очень сложна, и хотя структуры данных различны в разных
информационных системах, между ними часто бывает много общего. На начальном этапе
использования вычислительной техники проблемы структуризации данных решались
индивидуально в каждой информационной системе. Производились необходимые надстройки
(библиотеки программ) над файловыми системами, подобно тому, как это делается в компиляторах,
редакторах и т. д.
Но поскольку в информационных системах требуется поддержка сложных структур данных, эти
индивидуальные средства управления данными составляли существенную часть информационных
систем, практически повторяясь (как программные компоненты) от одной системы к другой.
Стремление выделить общую часть информационных систем, ответственную за управление сложно
структурированными данными явилось, на наш взгляд, первой побудительной причиной создания
СУБД, которая, возможно, могла бы представлять некоторую общую библиотеку программ,
доступную каждой информационной системе.
Однако очень скоро стало понятно, что невозможно обойтись такой общей библиотекой программ,
реализующей над стандартной базовой файловой системой более сложные методы хранения
данными.
Вообще, согласованность данных является ключевым понятием баз данных. На самом деле, если
информационная система (даже такая простая, как в нашем примере) поддерживает согласованное
хранение информации в нескольких файлах, можно говорить о том, что она поддерживает базу
данных. Если же некоторая вспомогательная система управления данными позволяет работать с
несколькими файлами, обеспечивая их согласованность, можно назвать ее системой управления
базами данных. Уже только требование поддержания согласованности данных в нескольких файлах
не позволяет обойтись библиотекой функций: такая система должна обладать некоторыми
собственными данными (мета-данными) и даже знаниями, определяющими целостность данных.
ТРЕБУЕТСЯ ПОДДЕРЖКА ЗАПРОСОВ
Таким образом, СУБД решают множество проблем, которые затруднительно или вообще
невозможно решить при использовании файловых систем. При этом существуют приложения, для
которых вполне достаточно файлов, приложения, для которых необходимо решать, какой уровень
работы с данными во внешней памяти для них требуется, и приложения, для которых безусловно
нужны базы данных.
Современные системы управления файлами и управления базами данных представляют собой
весьма совершенные инструменты, каждый из которых может быть очень успешно применен в
соответствующей области деятельности. Но всегда необходимо помнить, что каждый инструмент
приносит максимальную пользу именно в той области, для которой он создан.
Билет №2
1 Проблемы и задачи курса
2 Физическая и логическая структуры базы данных Oracle.
База данных ORACLE имеет как физическую, так и логическую
структуру. За счет разделения
физической и логической структуры базы данных
достигается возможность
управления
физической структурой данных, не затрагивая доступа к логическим структурам данных.
Физическая структура базы данных
Физическая структура базы данных ORACLE определяется файлами операционной системы, из
которых состоит база данных. Каждая база данных ORACLE составляется из файлов трех типов:
одного или нескольких файлов данных, двух или более файлов журнала повторения работы и
одного или нескольких управляющих файлов. Файлы базы данных предоставляют действительную
физическую память для информации базы данных.
Логическая структура базы данных
Логическая структура базы данных ORACLE определяется:
* одним или несколькими табличными пространствами
* объектами схем базы данных (таблицами, обзорами,
индексами, кластерами, последовательностями, хранимыми
процедурами)
Логические структуры хранения, включая табличные пространства,
сегменты и экстенты,
определяют, как используется физическое пространство базы данных. Объекты схем и отношения
между ними формируют реляционную структуру базы данных.
Логические структуры
Системы управления базами данных эволюционировали от иерархических к сетевым, а затем
к реляционным моделям. Сегодня наиболее широко принятой моделью базы данных является
реляционная модель. Эта модель имеет три главных аспекта:
Структуры - это хорошо определенные объекты, хранящие данные базы данных. Структурами и
данными, хранящимися в них, можно манипулировать посредством операций.
Операции - это четко определенные действия, позволяющие пользователю манипулировать
данными и структурами базы данных. Операции на базе данных должны подчиняться
предопределенному набору правил целостности.
Правила целостности - это законы, которые определяют, какие операции допускаются
над данными и структурами базы данных. Правила целостности защищают структуры и данные
базы данных.
Табличные пространства
База данных разделяется на логические единицы хранения, называемые ТАБЛИЧНЫМИ
ПРОСТРАНСТВАМИ. Табличное пространство служит для того, чтобы группировать вместе
взаимосвязанные логические структуры. Например, в табличном пространстве обычно
группируются все объекты приложения, чтобы упростить некоторые административные операции.
Базы данных, табличные пространства и файлы данных
* Каждая база данных логически разделяется на одно или
более табличных пространств.
* Для каждого табличного пространства явно создаются один
или более файлов данных, чтобы физически хранить данные
всех логических структур табличного пространства.
* Общая емкость памяти табличного пространства определяется
суммой размеров файлов данных, составляющих это табличное
пространство
* Суммарная емкость всех табличных пространств базы данных
составляет общую емкость базы данных.
Онлайновые и офлайновые табличные пространства
Табличное пространство может находиться в состояниях ОНЛАЙН (доступно) или ОФЛАЙН
(недоступно). Обычно табличное пространство находится в онлайне, так что пользователи имеют
доступ к информации в нем. Однако иногда табличное пространство может переводиться в офлайн,
чтобы сделать часть базы данных недоступной, сохраняя в то же время нормальный доступ к
остальной части базы данных. Это облегчает выполнение многих административных задач.
Схемы и объекты схем
СХЕМА - это коллекция объектов. ОБЪЕКТЫ СХЕМЫ - это логические
структуры,
непосредственно относящиеся к данным базы данных.
Объекты схемы включают такие
структуры, как таблицы, обзоры,
последовательности, хранимые процедуры, синонимы,
индексы, кластеры и связи баз данных. (Не существует взаимосвязи между табличным
пространством и схемой; объекты одной и той же схемы могут находиться в разных табличных
пространствах, и одно и то же табличное пространство может содержать объекты из разных схем.)
ТАБЛИЦА - это основная единица хранения данных в базе данных ORACLE. Таблицы базы
данных хранят все данные, доступные пользователям.
Данные таблицы хранятся в виде СТРОК и СТОЛБЦОВ. Каждая таблица определяется с
ИМЕНЕМ ТАБЛИЦЫ и набором столбцов. Каждому столбцу дается ИМЯ СТОЛБЦА, ТИП
ДАННЫХ (такой как CHAR, DATE или NUMBER), а также ШИРИНА (которая может быть
предопределена типом данных, как в случае DATE) или МАСШТАБ и ТОЧНОСТЬ (только для типа
данных NUMBER). После того, как таблица создана, в нее
могут быть вставлены строки
действительных данных. После этого строки таблицы можно опрашивать, удалять или обновлять.
Чтобы учредить организационные правила для данных таблицы, для
таблицы можно также
определить ограничения целостности и триггеры. (Для дополнительной информации см. Раздел
"Целостность данных" на странице 1-26.)
ОБЗОР - это настроенное по заказу представление данных из одной или нескольких таблиц. Обзор
можно рассматривать как "хранимый запрос".
Обзоры в действительности не содержат данных; вместо этого они
доставляют данные из тех
таблиц, на которых они основаны (так
называемых БАЗОВЫХ ТАБЛИЦ обзоров). Базовые
таблицы, в свою очередь, могут быть как таблицами, так и обзорами.
Как и таблицы, обзоры можно опрашивать, обновлять и осуществлять в них вставки и удаления, с
некоторыми ограничениями. Все операции, осуществляемые над обзором, в действительности
затрагивают базовые таблицы этого обзора.
Широкое применение обзоров обусловлено следующими их свойствами:
* Обзоры предоставляют дополнительный уровень защиты
таблиц, ограничивая доступ
предопределенным множеством строк и столбцов базовой таблицы. Например, обзор можно
составить так, что столбцы со специфической информацией (скажем, сведениями о зарплате) не
включаются в определение обзора.
* Обзоры позволяют скрыть сложность данных. Например, единственный обзор может
служить для построения СОЕДИНЕНИЯ, которое является отображением взаимосвязанных
столбцов или строк из нескольких таблиц. Однако такой обзор скрывает тот факт, что эти данные на
самом деле принадлежат разным таблицам.
* Обзоры помогают упростить команды для пользователя. Например, с помощью обзора
пользователь может выбирать информацию из нескольких таблиц, не зная, как осуществлять
сложный коррелированный запрос.
* Обзоры представляют данные с иной точки зрения, чем они представлены в таблице.
Например, с помощью обзора можно переименовать столбцы, не затрагивая самих таблиц, на
которых базируется обзор.
* Обзоры позволяют составлять и сохранять сложные запросы.
Например, запрос может
выполнять обширные вычисления по
информации таблицы. Благодаря тому, что этот запрос
сохраняется как обзор, вы выполняете эти вычисления только при обращении к обзору.
ПОСЛЕДОВАТЕЛЬНОСТЬ генерирует уникальные порядковые номера,
которые могут
использоваться как значения числовых столбцов таблиц базы данных. Последовательности
упрощают прикладное программирование, автоматически генерируя уникальные числовые значения
для строк одной или нескольких таблиц.
Последовательность
автоматически
генерирует правильное значение для каждого из
пользователей.
Номера, генерируемые последовательностью, независимы от таблиц, так что одну и ту же
последовательность можно использовать для нескольких таблиц.
После ее создания, к
последовательности могут обращаться различные пользователи, чтобы получать действительные
порядковые номера.
Программные единицы
Термином "программная единица" обозначаются хранимые процедуры, функции и пакеты.
ПРОЦЕДУРА или ФУНКЦИЯ - это совокупность предложений SQL и PL/SQL, сгруппированных
вместе как выполнимая единица, исполняющая специфическую задачу. (См. "Доступ к данным"
на странице 1-22 для дополнительной информации о SQL и PL/SQL.) Процедуры и функции
сочетают
легкость и гибкость SQL с процедурными возможностями языка структурного
программирования. С помощью PL/SQL такие процедуры и функции можно определять и сохранять
в базе данных для продолжительного использования.
Процедуры и функции похожи друг на друга, с той разницей, что
функция всегда возвращает
вызывающей программе единственное значение, тогда как процедура не возвращает значения.
ПАКЕТЫ дают метод инкапсулирования и хранения взаимосвязанных
процедур, функций и
других конструктов пакета как единицы в базе данных. Предоставляя администратору базы
данных или разработчику приложений организационные преимущества, пакеты в то же время
расширяют функциональные возможности и увеличивают производительность базы данных.
СИНОНИМ - это алиас (дополнительное имя) для таблицы, обзора,
последовательности или
программной единицы. Синоним не есть объект, но он является прямой ссылкой на объект.
Синонимы используются для:
* маскировки действительного имени и владельца объекта
* обеспечения общего доступа к объекту
* достижения прозрачности местоположения для таблиц, обзоров или
программных
единиц удаленной базы данных
* упрощения кодирования предложений SQL для пользователей базы
данных
Синоним может быть общим или личным. Индивидуальный
пользователь может создать
ЛИЧНЫЙ СИНОНИМ, который доступен
только этому пользователю. Администраторы баз
данных чаще всего
создают ОБЩИЕ СИНОНИМЫ, благодаря которым объекты базовых схем
становятся доступными для общего пользования всем пользователям базы данных.
Индексы, кластеры и хэшированные кластеры
Индексы, кластеры и хэшированные кластеры - это необязательные
структуры,
ассоциированные с таблицами, которые можно создавать для повышения производительности
операций извлечения данных. Так же, как индекс в книге позволяет вам быстрее отыскивать нужную
информацию, индекс ORACLE предоставляет быстрый путь доступа к данным таблицы. При
обработке запроса ORACLE может использовать некоторые или все имеющиеся индексы для
эффективного отыскания запрашиваемых строк. Индексы полезны, когда приложения часто
опрашивают интервалы строк таблицы (например, всех сотрудников с жалованьем выше 1000
долларов), либо отдельные строки.
Индексы создаются по одному или нескольким столбцам таблицы.
Однажды созданный,
индекс автоматически поддерживается и используется ORACLE. Изменения в данных таблицы
(такие как
добавление новых строк, обновление или удаление строк)
автоматически
отражаются во всех соответствующих индексах при полной прозрачности для пользователей.
Индексы логически и физически независимы от данных. Их можно удалять и создавать в любой
момент, не оказывая влияния на другие таблицы или другие индексы. После удаления индекса все
приложения будут функционировать по-прежнему; однако доступ к ранее индексированным данным
может быть замедлен.
Билет №3
1. Технология и модели клиент-сервер.
"Клиент-сервер" - это модель взаимодействия компьютеров в сети. Как правило, компьютеры не
являются равноправными. Каждый из них имеет свое, отличное от других, назначение, играет свою
роль. Некоторые компьютеры в сети владеют и распоряжается информационно-вычислительными
ресурсами, такими как процессоры, файловая система, почтовая служба, служба печати, база
данных. Другие же компьютеры имеют возможность обращаться к этим службам, пользуясь
услугами первых. Компьютер, управляющий тем или иным ресурсом, принято называть сервером
этого ресурса, а компьютер, желающий им воспользоваться - клиентом. Конкретный сервер
определяется видом ресурса, которым он владеет. Так, если ресурсом являются базы данных, то речь
идет о сервере баз данных, назначение которого - обслуживать запросы клиентов, связанные с
обработкой данных; если ресурс - это файловая система, то говорят о файловом сервере, или файлсервере, и т. д.
В сети один и тот же компьютер может выполнять роль как клиента, так и сервера. Например, в
информационной системе, включающей персональные компьютеры, большую ЭВМ и миникомпьютер под управлением UNIX, последний может выступать как в качестве сервера базы
данных, обслуживая запросы от клиентов - персональных компьютеров, так и в качестве клиента,
направляя запросы большой ЭВМ.
Этот же принцип распространяется и на взаимодействие программ. Если одна из них выполняет
некоторые функции, предоставляя другим соответствующий набор услуг, то такая программа
выступает в качестве сервера. Программы, которые пользуются этими услугами, принято называть
клиентами. Так, ядро реляционной SQL-ориентированной СУБД часто называют сервером базы
данных, или SQL-сервером, а программу, обращающуюся к нему за услугами по обработке данных SQL-клиентом.
Рисунок 1.
Системы с централизованной архитектурой.
Первоначально СУБД имели централизованную архитектуру (рис.1). В ней сама СУБД и
прикладные программы, которые работали с базами данных, функционировали на центральном
компьютере (большая ЭВМ или мини-компьютер). Там же располагались базы данных. К
центральному компьютеру были подключены терминалы, выступавшие в качестве рабочих мест
пользователей. Все процессы, связанные с обработкой данных, как то: поддержка ввода,
осуществляемого пользователем, формирование, оптимизация и выполнение запросов, обмен с
устройствами внешней памяти и т.д., выполнялись на центральном компьютере, что предъявляло
жесткие требования к его производительности. Особенности СУБД первого поколения напрямую
связаны с архитектурой систем больших ЭВМ и мини-компьютеров и и адекватно отражают все их
преимущества и недостатки. Однако нас больше интересует современное состояние
многопользовательских СУБД, для которых архитектура "клиент-сервер" стала фактическим
стандартом.
Если предполагается, что проектируемая информационная система (ИС) будет иметь технологию
"клиент-сервер", то это означает, что прикладные программы, реализованные в ее рамках, будут
иметь распределенный характер. Иными словами, часть функций прикладной программы (или,
проще, приложения) будет реализована в программе-клиенте, другая - в программе-сервере, причем
для их взаимодействия будет определен некоторый протокол.
Основной принцип технологии "клиент-сервер" заключается в разделении функций стандартного
интерактивного приложения на четыре группы, имеющие различную природу. Первая группа - это
функции ввода и отображения данных. Вторая группа объединяет чисто прикладные функции,
характерные для данной предметной области (например, для банковской системы - открытие счета,
перевод денег с одного счета на другой и т.д.). К третьей группе относятся фундаментальные
функции хранения и управления информационными ресурсами (базами данных, файловыми
системами и т.д.). Наконец, функции четвертой группы - это служебные функции (играющие роль
связок между функциями первых трех групп.
В соответствии с этим в любом приложении выделяются следующие логические компоненты:
╥ компонент представления, реализующий функции первой группы;
╥ прикладной компонент, поддерживающий функции второй группы;
╥ компонент доступа к информационным ресурсам, поддерживающий функции третьей групп, а
также вводятся и уточняются соглашения о способах их взаимодействия (протокол взаимодействия).
Различия в реализациях технологии "клиент-сервер" определяются четырьмя факторами. Во-первых,
тем, в какие виды программного обеспечения интегрированы каждый из этих компонентов. Вовторых, тем, какие механизмы программного обеспечения используются для реализации функций
всех трех групп. Во-третьих, как логические компоненты распределяются между компьютерами в
сети. В-четвертых, какие механизмы используются для связи компонентов между собой.
Выделяются четыре подхода, реализованные в моделях:
╥ модель файлового сервера (File Server - FS);
╥ модель доступа к удаленным данным (Remote Data Access - RDA);
╥ модель севера базы данных (DataBase Server - DBS);
╥ модель сервера приложений (Application Server - AS).
Рисунок 2.
Модель файлового сервера.
FS-модель является базовой для локальных сетей персональных компьютеров. Не так давно она
была исключительно популярной среди отечественных разработчиков, использовавших такие
системы, как FoxPRO, Clipper, Clarion, Paradox и т.д. Суть модели проста и всем известна. Один из
компьютеров в сети считается файловым сервером и предоставляет услуги по обработке файлов
другим компьютерам. Файловый сервер работает под управлением сетевой операционной системы
(например, Novell NetWare) и играет роль компонента доступа к информационным ресурсам (то есть
к файлам). На других компьютерах в сети функционирует приложение, в кодах которого совмещены
компонент представления и прикладной компонент (рис.2). Протокол обмена представляет собой
набор низкоуровневых вызовов, обеспечивающих приложению доступ к файловой системе на файлсервере.
FS-модель послужила фундаментом для расширения возможностей персональных СУБД в
направлении поддержки многопользовательского режима. В таких системах на нескольких
персональных компьютерах выполняется как прикладная программа, так и копия СУБД, а базы
данных содержатся в разделяемых файлах, которые находятся на файловом сервере. Когда
прикладная программа обращается к базе данных, СУБД направляет запрос на файловый сервер. В
этом запросе указаны файлы, где находятся запрашиваемые данные. В ответ на запрос файловый
сервер направляет по сети требуемый блок данных. СУБД, получив его, выполняет над данными
действия, которые были декларированы в прикладной программе.
К технологическим недостаткам модели относят высокий сетевой трафик (передача множества
файлов, необходимых приложению), узкий спектр операций манипуляции с данными ("данные - это
файлы"), отсутствие адекватных средств безопасности доступа к данным (защита только на уровне
файловой системы) и т.д. Собственно, перечисленное не есть недостатки, но - следствие внутренне
присущих FS-модели ограничений, определяемых ее характером. Недоразумения возникают, когда
FS-модель используют не по назначению, например, пытаются интерпретировать как модель
сервера базы данных. Место FS-модели в иерархии моделей "клиент-сервер" - это место модели
файлового сервера, и ничего более. Именно поэтому обречены на провал попытки создания на
основе FS-модели крупных корпоративных систем - попытки, которые предпринимались в недавнем
прошлом и нередко предпринимаются сейчас.
Рисунок 3.
Модель доступа к удаленным данным.
Более технологичная RDA-модель существенно отличается от FS-модели характером компонента
доступа к информационным ресурсам. Это, как правило, SQL-сервер. В RDA-модели коды
компонента представления и прикладного компонента совмещены и выполняются на компьютереклиенте. Последний поддерживает как функции ввода и отображения данных, так и чисто
прикладные функции. Доступ к информационным ресурсам обеспечивается либо операторами
специального языка (языка SQL, например, если речь идет о базах данных), либо вызовами функций
специальной
библиотеки
(если
имеется
соответствующий
интерфейс
прикладного
программирования - API).
Клиент направляет запросы к информационным ресурсам (например, к базам данных) по сети
удаленному компьютеру. На нем функционирует ядро СУБД, которое обрабатывает запросы,
выполняя предписанные в них действия, и возвращает клиенту результат, оформленный как блок
данных (рис.3). При этом инициатором манипуляций с данными выступают программы,
выполняющиеся на компьютерах-клиентах, в то время как ядру СУБД отводится пассивная роль обслуживание запросов и обработка данных. В Разделе 2 будет показано, что такое распределение
обязанностей между клиентами и сервером базы данных не догма - сервер БД может играть более
активную роль, чем та, которая предписана ему традиционной парадигмой.
RDA-модель избавляет от недостатков, присущих как системам с централизованной архитектурой,
так и системам с файловым сервером.
Прежде всего перенос компонента представления и прикладного компонента на компьютерыклиенты существенно разгружает сервер БД, сводя к минимуму общее число процессов
операционной системы. Сервер БД освобождается от несвойственных ему функций; процессор или
процессоры сервера целиком загружаются операциями обработки данных, запросов и транзакций.
Это становится возможным благодаря отказу от терминалов и оснащению рабочих мест
компьютерами, которые обладают собственными локальными вычислительными ресурсами,
полностью используемыми программами переднего плана. С другой стороны, резко уменьшается
загрузка сети, так как по ней передаются от клиента к серверу не запросы на ввод-вывод (как в
системах с файловым сервером), а запросы на языке SQL, их объем существенно меньше.
Основное достоинство RDA-модели - унификация интерфейса "клиент-сервер" в виде языка SQL.
Действительно, взаимодействие прикладного компонента с ядром СУБД невозможно без
стандартизованного средства общения. Запросы, направляемые программой ядру, должны быть
понятны обоим. Для этого их следует сформулировать на специальном языке. Но в СУБД уже
существует язык SQL, о котором уже шла речь . Поэтому целесообразно использовать его не только
в качестве средства доступа к данным, но и стандарта общения клиента и сервера.
Такое общение можно сравнить с беседой нескольких человек, когда один отвечает на вопросы
остальных (вопросы задаются одновременно). Причем делает это он так быстро, что время ожидания
ответа приближается к нулю. Высокая скорость общения достигается прежде всего благодаря четкой
формулировке вопроса, когда спрашивающему и отвечающему не нужно дополнительных
консультаций по сути вопроса. Беседующие обмениваются несколькими короткими однозначными
фразами, им ничего не нужно уточнять.
К сожалению, RDA-модель не лишена ряда недостатков. Во-первых, взаимодействие клиента и
сервера посредством SQL-запросов существенно загружает сеть. Во-вторых, удовлетворительное
администрирование приложений в RDA-модели практически невозможно из-за совмещения в одной
программе различных по своей природе функций (функции представления и прикладные). Более
подробно о недостатках RDA-модели сказано в п. 2.3.1.
Рисунок 4.
Модель сервера базы данных.
Наряду с RDA-моделью все большую популярность приобретает перспективная DBS-модель (рис.
4). Последняя реализована в некоторых реляционных СУБД (Informix, Ingres, Sybase, Oracle). Ее
основу составляет механизм хранимых процедур - средство программирования SQL-сервера.
Процедуры хранятся в словаре базы данных, разделяются между несколькими клиентами и
выполняются на том же компьютере, где функционирует SQL-сервер. Язык, на котором
разрабатываются хранимые процедуры, представляет собой процедурное расширение языка
запросов SQL и уникален для каждой конкретной СУБД. Более подробно о хранимых процедурах
рассказано в п. 2.3.3.
В DBS-модели компонент представления выполняется на компьютере-клиенте, в то время как
прикладной компонент оформлен как набор хранимых процедур и функционирует на компьютересервере БД. Там же выполняется компонент доступа к данным, то есть ядро СУБД. Достоинства
DBS-модели очевидны: это и возможность централизованного администрирования прикладных
функций, и снижение трафика (вместо SQL-запросов по сети направляются вызовы хранимых
процедур), и возможность разделения процедуры между несколькими приложениями, и экономия
ресурсов компьютера за счет использования единожды созданного плана выполнения процедуры. К
недостаткам модели можно отнести ограниченность средств, используемых для написания
хранимых процедур, которые представляют собой разнообразные процедурные расширения SQL, не
выдерживающие сравнения по изобразительным средствам и функциональным возможностям с
языками третьего поколения, такими как C или Pascal. Сфера их использования ограничена
конкретной СУБД, в большинстве СУБД отсутствуют возможности отладки и тестирования
разработанных хранимых процедур.
На практике часто используется смешанные модели, когда поддержка целостности базы данных и
некоторые простейшие прикладные функции поддерживаются хранимыми процедурами (DBSмодель), а более сложные функции реализуются непосредственно в прикладной программе, которая
выполняется на компьютере-клиенте (RDA-модель). Так или иначе современные
многопользовательские СУБД опираются на RDA- и DBS-модели и при создании ИС,
предполагающем использование только СУБД, выбирают одну из этих двух моделей либо их
разумное сочетание.
Рисунок 5.
Модель сервера приложений.
В AS-модели (рис.5) процесс, выполняющийся на компьютере-клиенте, отвечает, как обычно, за
интерфейс с пользователем (то есть осуществляет функции первой группы). Обращаясь за
выполнением услуг к прикладному компоненту, этот процесс играет роль клиента приложения
(Application Client - AC). Прикладной компонент реализован как группа процессов, выполняющих
прикладные функции, и называется сервером приложения (Application Server - AS). Все операции над
информационными ресурсами выполняются соответствующим компонентом, по отношению к
которому AS играет роль клиента. Из прикладных компонентов доступны ресурсы различных типов
- базы данных, очереди, почтовые службы и др.
RDA- и DBS-модели опираются на двухзвенную схему разделения функций. В RDA-модели
прикладные функции приданы программе-клиенту, в DBS-модели ответственность за их
выполнение берет на себя ядро СУБД. В первом случае прикладной компонент сливается с
компонентом представления, во-втором - интегрируется в компонент доступа к информационным
ресурсам. В AS-модели реализована трехзвенная схема разделения функций, где прикладной
компонент выделен как важнейший изолированный элемент приложения, для его определения
используются универсальные механизмы многозадачной операционной системы, и стандартизованы
интерфейсы с двумя другими компонентами. AS-модель является фундаментом для мониторов
обработки транзакций (Transaction Processing Monitors - TPM), или, проще, мониторов транзакций,
которые выделяются как особый вид программного обеспечения. Мониторы транзакций - предмет
Раздела 4.
В заключение отметим, что, часто, говоря о сервере базы данных, подразумевают как компьютер,
так и программное обеспечение - ядро СУБД. При описании архитектуры "Клиент-сервер" под
сервером базы данных мы имели в виду компьютер. Далее сервер базы данных будет пониматься
как программное обеспечение - ядро СУБД.
2. Логические структуры базы данных Oracle (табличные пространства и их
состояния, схемы и объекты схемы:таблицы, обзоры).
Логические структуры
Системы управления базами данных эволюционировали от иерархических к сетевым, а затем
к реляционным моделям. Сегодня наиболее широко принятой моделью базы данных является
реляционная модель. Эта модель имеет три главных аспекта:
Структуры - это хорошо определенные объекты, хранящие данные базы данных. Структурами и
данными, хранящимися в них, можно манипулировать посредством операций.
Операции - это четко определенные действия, позволяющие пользователю манипулировать
данными и структурами базы данных. Операции на базе данных должны подчиняться
предопределенному набору правил целостности.
Правила целостности - это законы, которые определяют, какие операции допускаются
над данными и структурами базы данных. Правила целостности защищают структуры и данные
базы данных.
Табличные пространства
База данных разделяется на логические единицы хранения, называемые ТАБЛИЧНЫМИ
ПРОСТРАНСТВАМИ. Табличное пространство служит для того, чтобы группировать вместе
взаимосвязанные логические структуры. Например, в табличном пространстве обычно
группируются все объекты приложения, чтобы упростить некоторые административные операции.
Базы данных, табличные пространства и файлы данных
* Каждая база данных логически разделяется на одно или
более табличных пространств.
* Для каждого табличного пространства явно создаются один
или более файлов данных, чтобы физически хранить данные
всех логических структур табличного пространства.
* Общая емкость памяти табличного пространства определяется
суммой размеров файлов данных, составляющих это табличное
пространство
* Суммарная емкость всех табличных пространств базы данных
составляет общую емкость базы данных.
Онлайновые и офлайновые табличные пространства
Табличное пространство может находиться в состояниях ОНЛАЙН (доступно) или ОФЛАЙН
(недоступно). Обычно табличное пространство находится в онлайне, так что пользователи имеют
доступ к информации в нем. Однако иногда табличное пространство может переводиться в офлайн,
чтобы сделать часть базы данных недоступной, сохраняя в то же время нормальный доступ к
остальной части базы данных. Это облегчает выполнение многих административных задач.
Схемы и объекты схем
СХЕМА - это коллекция объектов. ОБЪЕКТЫ СХЕМЫ - это логические
структуры,
непосредственно относящиеся к данным базы данных.
Объекты схемы включают такие
структуры, как таблицы, обзоры,
последовательности, хранимые процедуры, синонимы,
индексы, кластеры и связи баз данных. (Не существует взаимосвязи между табличным
пространством и схемой; объекты одной и той же схемы могут находиться в разных табличных
пространствах, и одно и то же табличное пространство может содержать объекты из разных схем.)
ТАБЛИЦА - это основная единица хранения данных в базе данных ORACLE. Таблицы базы
данных хранят все данные, доступные пользователям.
Данные таблицы хранятся в виде СТРОК и СТОЛБЦОВ. Каждая таблица определяется с
ИМЕНЕМ ТАБЛИЦЫ и набором столбцов. Каждому столбцу дается ИМЯ СТОЛБЦА, ТИП
ДАННЫХ (такой как CHAR, DATE или NUMBER), а также ШИРИНА (которая может быть
предопределена типом данных, как в случае DATE) или МАСШТАБ и ТОЧНОСТЬ (только для типа
данных NUMBER). После того, как таблица создана, в нее
могут быть вставлены строки
действительных данных. После этого строки таблицы можно опрашивать, удалять или обновлять.
Чтобы учредить организационные правила для данных таблицы, для
таблицы можно также
определить ограничения целостности и триггеры. (Для дополнительной информации см. Раздел
"Целостность данных" на странице 1-26.)
ОБЗОР - это настроенное по заказу представление данных из одной или нескольких таблиц. Обзор
можно рассматривать как "хранимый запрос".
Обзоры в действительности не содержат данных; вместо этого они
доставляют данные из тех
таблиц, на которых они основаны (так
называемых БАЗОВЫХ ТАБЛИЦ обзоров). Базовые
таблицы, в свою очередь, могут быть как таблицами, так и обзорами.
Как и таблицы, обзоры можно опрашивать, обновлять и осуществлять в них вставки и удаления, с
некоторыми ограничениями. Все операции, осуществляемые над обзором, в действительности
затрагивают базовые таблицы этого обзора.
Широкое применение обзоров обусловлено следующими их свойствами:
* Обзоры предоставляют дополнительный уровень защиты
таблиц, ограничивая доступ
предопределенным множеством строк и столбцов базовой таблицы. Например, обзор можно
составить так, что столбцы со специфической информацией (скажем, сведениями о зарплате) не
включаются в определение обзора.
* Обзоры позволяют скрыть сложность данных. Например, единственный обзор может
служить для построения СОЕДИНЕНИЯ, которое является отображением взаимосвязанных
столбцов или строк из нескольких таблиц. Однако такой обзор скрывает тот факт, что эти данные на
самом деле принадлежат разным таблицам.
* Обзоры помогают упростить команды для пользователя. Например, с помощью обзора
пользователь может выбирать информацию из нескольких таблиц, не зная, как осуществлять
сложный коррелированный запрос.
* Обзоры представляют данные с иной точки зрения, чем они представлены в таблице.
Например, с помощью обзора можно переименовать столбцы, не затрагивая самих таблиц, на
которых базируется обзор.
* Обзоры позволяют составлять и сохранять сложные запросы.
Например, запрос может
выполнять обширные вычисления по
информации таблицы. Благодаря тому, что этот запрос
сохраняется как обзор, вы выполняете эти вычисления только при обращении к обзору.
ПОСЛЕДОВАТЕЛЬНОСТЬ генерирует уникальные порядковые номера,
которые могут
использоваться как значения числовых столбцов таблиц базы данных. Последовательности
упрощают прикладное программирование, автоматически генерируя уникальные числовые значения
для строк одной или нескольких таблиц.
Последовательность
автоматически
генерирует правильное значение для каждого из
пользователей.
Номера, генерируемые последовательностью, независимы от таблиц, так что одну и ту же
последовательность можно использовать для нескольких таблиц.
После ее создания, к
последовательности могут обращаться различные пользователи, чтобы получать действительные
порядковые номера.
Программные единицы
Термином "программная единица" обозначаются хранимые процедуры, функции и пакеты.
ПРОЦЕДУРА или ФУНКЦИЯ - это совокупность предложений SQL и PL/SQL, сгруппированных
вместе как выполнимая единица, исполняющая специфическую задачу. (См. "Доступ к данным"
на странице 1-22 для дополнительной информации о SQL и PL/SQL.) Процедуры и функции
сочетают
легкость и гибкость SQL с процедурными возможностями языка структурного
программирования. С помощью PL/SQL такие процедуры и функции можно определять и сохранять
в базе данных для продолжительного использования.
Процедуры и функции похожи друг на друга, с той разницей, что
функция всегда возвращает
вызывающей программе единственное значение, тогда как процедура не возвращает значения.
ПАКЕТЫ дают метод инкапсулирования и хранения взаимосвязанных
процедур, функций и
других конструктов пакета как единицы в базе данных. Предоставляя администратору базы
данных или разработчику приложений организационные преимущества, пакеты в то же время
расширяют функциональные возможности и увеличивают производительность базы данных.
СИНОНИМ - это алиас (дополнительное имя) для таблицы, обзора,
последовательности или
программной единицы. Синоним не есть объект, но он является прямой ссылкой на объект.
Синонимы используются для:
* маскировки действительного имени и владельца объекта
* обеспечения общего доступа к объекту
* достижения прозрачности местоположения для таблиц, обзоров или
программных
единиц удаленной базы данных
* упрощения кодирования предложений SQL для пользователей базы
данных
Синоним может быть общим или личным. Индивидуальный
пользователь может создать
ЛИЧНЫЙ СИНОНИМ, который доступен
только этому пользователю. Администраторы баз
данных чаще всего
создают ОБЩИЕ СИНОНИМЫ, благодаря которым объекты базовых схем
становятся доступными для общего пользования всем пользователям базы данных.
Индексы, кластеры и хэшированные кластеры
Индексы, кластеры и хэшированные кластеры - это необязательные
структуры,
ассоциированные с таблицами, которые можно создавать для повышения производительности
операций извлечения данных. Так же, как индекс в книге позволяет вам быстрее отыскивать нужную
информацию, индекс ORACLE предоставляет быстрый путь доступа к данным таблицы. При
обработке запроса ORACLE может использовать некоторые или все имеющиеся индексы для
эффективного отыскания запрашиваемых строк. Индексы полезны, когда приложения часто
опрашивают интервалы строк таблицы (например, всех сотрудников с жалованьем выше 1000
долларов), либо отдельные строки.
Индексы создаются по одному или нескольким столбцам таблицы.
Однажды созданный,
индекс автоматически поддерживается и используется ORACLE. Изменения в данных таблицы
(такие как
добавление новых строк, обновление или удаление строк)
автоматически
отражаются во всех соответствующих индексах при полной прозрачности для пользователей.
Индексы логически и физически независимы от данных. Их можно удалять и создавать в любой
момент, не оказывая влияния на другие таблицы или другие индексы. После удаления индекса все
приложения будут функционировать по-прежнему; однако доступ к ранее индексированным данным
может быть замедлен.Билет №4
1. Типовая организация современной СУБД.
Оганизация типичной СУБД и состав ее компонентов соответствует следующему набору функций:
управление данными во внешней памяти;
управление буферами оперативной памяти;
управление транзакциями;
журнализация и восстановление БД после сбоев;
поддержание языков БД.
Логически в современной реляционной СУБД можно выделить наиболее внутреннюю часть - ядро
СУБД (часто его называют Data Base Engine), компилятор языка БД (обычно SQL), подсистему
поддержки времени выполнения, набор утилит. В некоторых системах эти части выделяются явно, в
других - нет, но логически такое разделение можно провести во всех СУБД.
Ядро СУБД отвечает за управление данными во внешней памяти, управление буферами
оперативной памяти, управление транзакциями и журнализацию. Соответственно можно выделить
такие компоненты ядра (по крайней мере, логически, хотя в некоторых системах эти компоненты
выделяются явно), как менеджер данных, менеджер буферов, менеджер транзакций и менеджер
журнала. Как можно было понять из первой части этой лекции, функции этих комонентов
взаимосвязаны, и для обеспечения корректной работы СУБД все эти компоненты должны
взаимодействовать по тщательно продуманным и проверенным протоколам. Ядро СУБД обладает
собственным интерфейсом, не доступным пользователям напрямую и используемым в программах,
производимых компилятором SQL (или в подсистеме поддержки выполнения таких программ), и
утилитах БД. Ядро СУБД является основной резидентной частью СУБД. При использовании
архитектуры "клиент-сервер" ядро является основным составляющим серверной части системы.
Основная функция компилятора языка БД - компиляция операторов языка БД в некоторую
выполняемую программу.
Основной проблемой реляционных СУБД является то, что языки этих систем (а это, как правило,
SQL) являются непроцедурными, т.е. в операторе такого языка специфицируется некоторое
действие над БД, но эта спецификация не процедура, она лишь описывает в некоторой форме
условия совершения желаемого действия (вспомните примеры из первой лекции). Поэтому
компилятор должен решить, каким образом выполнять оператор языка, прежде чем произвести
программу. Применяются достаточно сложные методы оптимизации операторов, которые мы
подробно рассмотрим в следующих лекциях. Результатом компиляции является выполняемая
программа, представляемая в некоторых системах в машинных кодах, но более часто в
выполняемом внутреннем машинно-независимом коде. В последнем случае реальное выполнение
оператора производится с привлечением подсистемы поддержки времени выполнения,
представляющей собой, по сути дела, интерпретатор этого внутреннего языка.
Наконец, в отдельные утилиты БД обычно выделяют такие процедуры, которые слишком накладно
выполнять с использованием языка БД, например, загрузка и разгрузка БД, сбор статистики,
глобальная проверка целостности БД и т.д. Утилиты программируются с использованием
интерфейса ядра СУБД, а иногда даже с проникновением внутрь ядра.
2. Логические структуры базы данных Oracle (табличные пространства и их
состояния, схемы и объекты схемы:последовательности, хранимые процедуры,
синонимы)
--- тоже что и в билете #3 --
Билет №5
1. Базовые понятия реляционных баз данных. 3/95 (Кузнецов)
Основными понятиями реляционных баз данных являются:
тип данных,
домен,
атрибут,
кортеж,
первичный ключ и
отношение.
Тип данных
Понятие тип данных в реляционной модели данных полностью адекватно понятию типа
данных в языках программирования. Обычно в современных реляционных БД допускается
хранение символьных, числовых данных, битовых строк, специализированных числовых данных
(таких как "деньги"), а также специальных "темпоральных" данных (дата, время, временной
интервал). Достаточно активно развивается подход к расширению возможностей реляционных
систем абстрактными типами данных (соответствующими возможностями обладают, например,
системы семейства Ingres/Postgres). В нашем примере мы имеем дело с данными трех типов:
строки символов, целые числа и "деньги".
Домен
Понятие домена более специфично для баз данных, хотя и имеет некоторые аналогии с
подтипами в некоторых языках программирования. В самом общем виде домен определяется
заданием некоторого базового типа данных, к которому относятся элементы домена, и
произвольного логического выражения, применяемого к элементу типа данных. Если
вычисление этого логического выражения дает результат "истина", то элемент данных является
элементом домена. Наиболее правильной интутивной трактовкой понятия домена является
понимание домена как допустимого потенциального множества значений данного типа.
Например, домен "Имена" в нашем примере определен на базовом типе строк символов, но в
число его значений могут входить только те строки, которые могут изображать имя (в частности,
такие строки не могут начинаться с мягкого знака). Следует отметить также семантическую
нагрузку понятия домена: данные считаются сравнимыми только в том случае, когда они
относятся к одному домену. В нашем примере значения доменов "Номера пропусков" и "Номера
групп" относятся к типу целых чисел, но не являются сравнимыми. Заметим, что в большинстве
реляционных СУБД понятие домена не используется, хотя в Oracle V.7 оно уже поддерживается.
Схема отношения, схема базы данных
Схема отношения - это именованное множество пар имя атрибута, имя домена (или типа, если
понятие домена не поддерживается). Степень, или "арность" схемы отношения,- мощность этого
множества. Степень отношения СОТРУДНИКИ равна четырем, то есть оно является 4-арным.
Если все атрибуты одного отношения определены на разных доменах, осмысленно использовать
для именования атрибутов имена соответствующих доменов (не забывая, конечно, о том, что это
является всего лишь удобным способом именования и не устраняет различия между понятиями
домена и атрибута). Схема БД (в структурном смысле) - это набор именованных схем
отношений.
Кортеж, отношение
Кортеж, соответствующий данной схеме отношения, - это множество пар имя атрибута,
значение, которое содержит одно вхождение каждого имени атрибута, принадлежащего схеме
отношения. "Значение" является допустимым значением домена данного атрибута (или типа
данных, если понятие домена не поддерживается). Тем самым, степень, или "арность" кортежа,
т.е. число элементов в нем, совпадает с "арностью" соответствующей схемы отношения.
Попросту говоря, кортеж - это набор именованных значений заданного типа. Отношение - это
множество кортежей, соответствующих одной схеме отношения. Иногда, чтобы не путаться,
говорят "отношение-схема" и "отношение-экземпляр", иногда схему отношения называют
заголовком отношения, а отношение как набор кортежей - телом отношения. На самом деле,
понятие схемы отношения ближе всего к понятию структурного типа данных в языках
программирования. Было бы вполне логично разрешать отдельно определять схему отношения,
а затем - одно или несколько отношений с данной схемой. Однако в реляционных базах данных
это не принято. Имя схемы отношения в таких базах данных всегда совпадает с именем
соответствующего отношения-экземпляра. В классических реляционных базах данных после
определения схемы базы данных изменяются только отношения-экземпляры. В них могут
появляться новые и удаляться или модифицироваться существующие кортежи. Однако во
многих реализациях допускается и изменение схемы базы данных: определение новых и
изменение существующих схем отношения. Это принято называть эволюцией схемы базы
данных. Обычным житейским представлением отношения является таблица, заголовком которой
является схема отношения, а строками - кортежи отношения-экземпляра; в этом случае имена
атрибутов именуют столбцы этой таблицы. Поэтому иногда говорят "столбец таблицы", имея в
виду "атрибут отношения". Когда мы перейдем к рассмотрению практических вопросов
организации реляционных баз данных и средств управления, мы будем использовать эту
житейскую терминологию. Этой терминологии придерживаются в большинстве коммерческих
реляционных СУБД. Реляционная база данных - это набор отношений, имена которых
совпадают с именами схем отношений в схеме БД. Как видно, основные структурные понятия
реляционной модели данных (если не считать понятия домена) имеют очень простую
интуитивную интерпретацию, хотя в теории реляционных БД все они определяются абсолютно
формально и точно.
Фундаментальные свойства отношений
Остановимся теперь на некоторых важных свойствах отношений, которые следуют из
приведенных ранее определений.
Отсутствие кортежей-дубликатов
То свойство, что отношения не содержат кортежей-дубликатов, следует из определения отношения
как множества кортежей. В классической теории множеств, по определению, каждое множество
состоит из различных элементов. Из этого свойства вытекает наличие у каждого отношения так
называемого первичного ключа - набора атрибутов, значения которых однозначно определяют
кортеж отношения. Для каждого отношения, по крайней мере, полный набор его атрибутов обладает
этим свойством. Однако при формальном определении первичного ключа требуется обеспечение его
"минимальности", т.е. в набор атрибутов первичного ключа не должны входить такие атрибуты,
которые можно отбросить без ущерба для основного свойства,- однозначно определять кортеж.
Понятие первичного ключа является исключительно важным в связи с понятием целостности баз
данных. Забегая вперед, заметим, что во многих практических реализациях РСУБД допускается
нарушение свойства уникальности кортежей для промежуточных отношений, порождаемых неявно
при выполнении запросов. Такие отношения являются не множествами, а мультимножествами, что в
ряде случаев позволяет добиться определенных преимуществ, но иногда приводит к серьезным
проблемам.
Отсутствие упорядоченности кортежей
Свойство отсутствия упорядоченности кортежей отношения также является следствием определения
отношения-экземпляра как множества кортежей. Отсутствие требования к поддержанию порядка на
множестве кортежей отношения дает дополнительную гибкость СУБД при хранении баз данных во
внешней памяти и при выполнении запросов к базе данных. Это не противоречит тому, что при
формулировании запроса к БД, например, на языке SQL можно потребовать сортировки
результирующей таблицы в соответствии со значениями некоторых столбцов. Такой результат, это
вообще говоря, не отношение, а некоторый упорядоченный список кортежей.
Отсутствие упорядоченности атрибутов
Атрибуты отношений не упорядочены, поскольку по определению схема отношения есть множество
пар имя атрибута, имя домена. Для ссылки на значение атрибута в кортеже отношения всегда
используется имя атрибута. Это свойство теоретически позволяет, например, модифицировать
схемы существующих отношений не только путем добавления новых атрибутов, но и путем
удаления существующих атрибутов. Однако в большинстве существующих систем такая
возможность не допускается, и хотя упорядоченность набора атрибутов отношения явно не
требуется, часто в качестве неявного порядка атрибутов используется их порядок в линейной форме
определения схемы отношения.
Атомарность значений атрибутов
Значения всех атрибутов являются атомарными. Это следует из определения домена как
потенциального множества значений простого типа данных, т.е. среди значений домена не могут
содержаться множества значений (отношения). Принято говорить, что в реляционных базах данных
допускаются только нормализованные отношения или отношения, представленные в первой
нормальной форме.
2. Логические структуры базы данных Oracle (табличныепространства и их
состояния, схемы и объекты схемы:индексы, кластеры и связи баз данных)
--- тоже что и в билете #3 --
Билет №6
1. Моделирование данных. Метод Баркера.
Моделирование - это воспроизведение характеристик некоторого объекта на другом, специально
созданном, для его изучения. Математическая модель представляет собой формализованное
описание системы с помощью некоторого абстрактного (формализованного) языка и включает в
себя систему аксиом, совокупность абстрактных объектов, свойства которых и отношения между
которыми, удовлетворяют аксиомам. Между моделируемым объектом и моделью должно
существовать отношение подобия.
Цель моделирования данных состоит в обеспечении разработчика ИС концептуальной схемой базы
данных в форме одной модели или нескольких локальных моделей, которые относительно легко
могут быть отображены в любую систему баз данных.
Наиболее распространенным средством моделирования данных являются диаграммы "сущностьсвязь" (ERD). С их помощью определяются важные для предметной области объекты (сущности), их
свойства (атрибуты) и отношения друг с другом (связи). ERD непосредственно используются для
проектирования реляционных баз данных.
Нотация ERD была впервые введена П. Ченом (Chen) и получила дальнейшее развитие в работах
Баркера .
Первый шаг моделирования - извлечение информации из интервью и выделение сущностей.
Сущность (Entity) - реальный либо воображаемый объект, имеющий существенное значение для
рассматриваемой предметной области, информация о котором подлежит хранению.
Каждая сущность должна обладать уникальным идентификатором. Каждый экземпляр сущности
должен однозначно идентифицироваться и отличаться от всех других экземпляров данного типа
сущности. Каждая сущность должна обладать некоторыми свойствами:
каждая сущность должна иметь уникальное имя, и к одному и тому же имени должна всегда
применяться одна и та же интерпретация. Одна и та же интерпретация не может применяться
к различным именам, если только они не являются псевдонимами;
сущность обладает одним или несколькими атрибутами, которые либо принадлежат
сущности, либо наследуются через связь;
сущность обладает одним или несколькими атрибутами, которые однозначно
идентифицируют каждый экземпляр сущности;
каждая сущность может обладать любым количеством связей с другими сущностями модели.
Следующим шагом моделирования является идентификация связей.
Связь (Relationship) - поименованная ассоциация между двумя сущностями, значимая для
рассматриваемой предметной области. Связь - это ассоциация между сущностями, при которой, как
правило, каждый экземпляр одной сущности, называемой родительской сущностью, ассоциирован с
произвольным (в том числе нулевым) количеством экземпляров второй сущности, называемой
сущностью-потомком, а каждый экземпляр сущности-потомка ассоциирован в точности с одним
экземпляром сущности-родителя. Таким образом, экземпляр сущности-потомка может существовать
только при существовании сущности родителя.
Связи может даваться имя, выражаемое грамматическим оборотом глагола и помещаемое возле
линии связи. Имя каждой связи между двумя данными сущностями должно быть уникальным, но
имена связей в модели не обязаны быть уникальными. Имя связи всегда формируется с точки зрения
родителя, так что предложение может быть образовано соединением имени сущности-родителя,
имени связи, выражения степени и имени сущности-потомка.
Например, связь продавца с контрактом может быть выражена следующим образом:
продавец может получить вознаграждение за 1 или более контрактов;
контракт должен быть инициирован ровно одним продавцом.
Степень связи и обязательность графически изображаются следующим образом .
Последним шагом моделирования является идентификация атрибутов.
Атрибут - любая характеристика сущности, значимая для рассматриваемой предметной области и
предназначенная
для
квалификации,
идентификации,
классификации,
количественной
характеристики или выражения состояния сущности. Атрибут представляет тип характеристик или
свойств, ассоциированных со множеством реальных или абстрактных объектов (людей, мест,
событий, состояний, идей, пар предметов и т.д.). Экземпляр атрибута - это определенная
характеристика отдельного элемента множества. Экземпляр атрибута определяется типом
характеристики и ее значением, называемым значением атрибута. В ER-модели атрибуты
ассоциируются с конкретными сущностями. Таким образом, экземпляр сущности должен обладать
единственным определенным значением для ассоциированного атрибута.
Атрибут может быть либо обязательным, либо необязательным (рисунок 2.23). Обязательность
означает, что атрибут не может принимать неопределенных значений (null values). Атрибут может
быть либо описательным (т.е. обычным дескриптором сущности), либо входить в состав
уникального идентификатора (первичного ключа).
Уникальный идентификатор - это атрибут или совокупность атрибутов и/или связей,
предназначенная для уникальной идентификации каждого экземпляра данного типа сущности. В
случае полной идентификации каждый экземпляр данного типа сущности полностью
идентифицируется своими собственными ключевыми атрибутами, в противном случае в его
идентификации участвуют также атрибуты другой сущности-родителя (рисунок 2.24).
Рис. 2.23.
Рис. 2.24.
Каждый атрибут идентифицируется уникальным именем, выражаемым грамматическим оборотом
существительного, описывающим представляемую атрибутом характеристику. Атрибуты
изображаются в виде списка имен внутри блока ассоциированной сущности, причем каждый
атрибут занимает отдельную строку. Атрибуты, определяющие первичный ключ, размещаются
наверху списка и выделяются знаком "#".
Каждая сущность должна обладать хотя бы одним возможным ключом. Возможный ключ сущности
- это один или несколько атрибутов, чьи значения однозначно определяют каждый экземпляр
сущности. При существовании нескольких возможных ключей один из них обозначается в качестве
первичного ключа, а остальные - как альтернативные ключи.
Помимо перечисленных основных конструкций модель данных может содержать
ряд дополнительных.
Подтипы и супертипы: одна сущность является обобщающим понятием для группы подобных
сущностей (рисунок 2.26).
Взаимно исключающие связи: каждый экземпляр сущности участвует только в одной связи из
группы взаимно исключающих связей (рисунок 2.27).
Рис. 2.25.
Подтипы и супертипы
Взаимно исключающие связи
Рекурсивная связь: сущность может быть связана сама с собой (рисунок 2.28).
Неперемещаемые (non-transferrable) связи: экземпляр сущности не может быть перенесен из
одного экземпляра связи в другой (рисунок 2.29).
Рекурсивная связь
Неперемещаемая связ
2. Блоки данных, экстенты и сегменты в tablespase Oracle.
ORACLE распределяет пространство базы данных для всех ее данных.
Единицами логического распределения являются блоки данных,
экстенты и сегменты. Следующий рисунок иллюстрирует отношения
между этими структурами данных.
Отношения между сегментами, экстентами и блоками данных
╔═══════════════════════╗
║
║
║
Сегмент
║
║
112K
║
║
║
╚═══════════════════════╝─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┐
│
└ ─ ┬─────────┐
┌──────────────────────────┤
│ Экстент │
│
Экстент
│
│
28K
├┐
│
84K
├─┐
└─┬───────┘│
└─┬────────┬────────┬──────┘ │
├────────┤
├────────┼────────┼────────┤
│
2K
│ Блоки
│
2K
│
2K
│
2K
│
├────────┤ данных
├────────┼────────┼────────┤
│
2K
│
│
2K
│
2K
│
2K
│
├────────┤
├────────┼────────┼────────┤
│
2K
│
│
2K
...
│
├───
├───
│
...
│
Блоки
данных
Блоки данных
На самом низком уровне рассмотрения, данные базы данных ORACLE хранятся в БЛОКАХ
ДАННЫХ (называемых также логическими блоками, блоками ORACLE или страницами). Один
блок данных соответствует фиксированному числу байт физического пространства базы данных на
диске. Размер блока данных специфически устанавливается для каждой базы данных ORACLE при
ее создании. Этот размер кратен
размеру блока операционной системы, но не превышает
определенный
максимум. Важно помнить, что база данных, на ее самом низком
уровне,
использует и распределяет свободное пространство в базе данных блоками данных ORACLE.
(По контрасту с этим, все данные на физическом уровне, т.е. На уровне операционной системы,
распределяются в байтах. Каждая операционная система имеет то, что называется РАЗМЕРОМ
БЛОКА, который определяется как специфическое число байт на диске.)
Экстенты
Следующий уровень логического пространства базы данных
называется ЭКСТЕНТОМ. Экстент - это специфическое число смежных блоков данных,
распределяемых для хранения специфического типа информации.
Сегменты
Уровень логического пространства базы данных, следующий за экстентом, называется
СЕГМЕНТОМ. Сегмент - это совокупность экстентов, распределенных для специфического типа
структуры данных, и находящихся в одном и том же табличном пространстве.
Например, данные каждой таблицы хранятся в ее собственном СЕГМЕНТЕ ДАННЫХ, а данные
каждого индекса хранятся в его собственном СЕГМЕНТЕ ИНДЕКСА.
ORACLE распределяет пространство для сегментов экстентами.
Поэтому, когда существующие экстенты сегмента заполнены, ORACLE распределяет очередной
экстент для этого сегмента. Поскольку экстенты распределяются при необходимости, экстенты
сегмента не обязательно смежны на диске, и могут быть распределены между различными файлами.
Каждый экстент, однако, не может находиться в нескольких файлах.
Блоки данных
ORACLE управляет пространством в файлах данных базы данных в единицах, называемых
БЛОКАМИ ДАННЫХ. Блок данных - это наименьшая единица ввода-вывода, используемая базой
данных.
Блок данных соответствует физическому блоку на диске с размером, совпадающим с размером
блока данных ORACLE. Этот размер блока может отличаться от стандартного размера блока вводавывода
операционной системы, в которой выполняется ORACLE.
Формат блока данных
Формат блока данных ORACLE один и тот же, независимо от того, содержит ли блок данные
таблицы, индекса или кластера. Рис. иллюстрирует формат блока данных.
Блок базы данных
┌────────────────────────┐
│ Общий и переменный
│
│ заголовок
│
├────────────────────────┤
│ Оглавление таблиц
│
├────────────────────────┤
│ Оглавление строк
│
│
│
├────────────────────────┤
│ Свободное пространство │ │
│
│
│
│
│
│
│
│
│
│ │
├────────────────────────┤
│ Данные строк
│
│
│
│
│
│
│
│
│
│
│
└────────────────────────┘
Заголовок (общий и переменный)
Заголовок содержит общую информацию блока, такую как адрес блока и тип сегмента (сегмент
данных, сегмент индекса или сегмент отката). Заголовок составляет накладные расходы блока,
которые имеют переменный размер. В среднем, суммарные накладные расходы фиксированной и
переменной частей блока составляют от 84 до 107 байт.
Оглавление таблиц
Часть блока, составляющая оглавление таблиц, содержит информацию о том, какие таблицы
имеют строки в этом блоке.
Оглавление строк
Эта часть блока содержит информацию о действительных строках в блоке (включая адреса
каждой порции строки в области данных строк). После того, как в оглавлении строк распределено
пространство, это пространство не освобождается при удалении строки. Поэтому блок, который
сейчас пуст, но когда-то содержал до 50 строк, по-прежнему имеет 100 байт, распределенных в
заголовке для оглавления строк. Это пространство используется повторно лишь тогда, когда в блок
вставляются новые строки.
Данные строк
Эта порция блока содержит данные таблицы или индекса. Строки могут переходить из блока в
блок;
Свободное пространство
Свободное пространство в блоке используется для вставки новых строк и для обновлений строк,
требующих дополнительного
пространства (например, при замене пустых хвостовых значений на непустые значения). Будут ли
конкретные вставки действительно осуществляться в данном блоке - зависит от значения параметра
управления пространством PCTFREE и от текущей величины свободного пространства в блоке.
Пространство для входов транзакций
Блоки данных, распределенные для сегмента данных таблицы или кластера либо для сегмента
индекса, могут также использовать
свободное пространство для входов транзакций. ВХОД ТРАНЗАКЦИИ требуется в блоке для
каждой транзакции INSERT, UPDATE, DELETE и SELECT...FOR UPDATE, обращающейся хотя бы
к одной строке в данном блоке. Пространство, занимаемое входами транзакций, зависит от
операционной системы; для большинства операционных
систем вход транзакции занимает приблизительно 23 байта.
Введение в PCTFREE, PCTUSED и цепочки строк
Два параметра управления пространством, PCTFREE и PCTUSED,
позволяют разработчику управлять использованием свободного
пространства для вставок и обновлений строк в блоках данных.
Оба этих параметра могут быть специфицированы лишь при создании
(CREATE) или изменении (ALTER) таблиц и кластеров (сегментов
данных). Кроме того, параметр PCTFREE можно также
специфицировать при создании или изменении индексов (сегментов
индекса).
Параметр PCTFREE
Параметр PCTFREE устанавливает процент памяти блока,
резервируемой (оставляемой свободной) для возможных обновлений
строк, уже содержащихся в блоке. Например, предположим, что вы
специфицировали следующий параметр в предложении CREATE TABLE:
PCTFREE 20
Это требует, чтобы 20% места в каждом блоке данных в сегменте
данных этой таблицы оставлялись свободными и доступными для
возможных обновлений строк, уже существующих в каждом блоке.
Рис.3-3 иллюстрирует параметр PCTFREE.
Блок базы данных
PCTFREE = 20
┌────────────────────────┐
│ Общий и переменный
│
│ заголовок
│
├────────────────────────┤
│ Оглавление таблиц
│
├────────────────────────┤
│ Оглавление строк
│
│
│
├────────────────────────┤
│ Свободное пространство │ │
│
20%
│
│
│
├────────────────────────┤
│ Данные строк
│
│
│
│
│
│
│
│
│
│
│
│
│ Блок позволяет вставки строк,
│
│ пока не будет занято 80%,
│
│ оставляя 20% свободного места
│
│ для обновления существующих
│
│ строк в блоке
│
│
└────────────────────────┘
Заметьте, что до того, как будет достигнут процент PCTFREE,
свободное пространство в блоке данных заполняется как вставками
новых строк, так и ростом заголовка блока данных.
Параметр PCTUSED
После того, как блок данных будет заполнен до процента PCTFREE,
этот блок не рассматривается для вставки новых строк до тех пор,
пока процент используемой памяти в блоке не упадет ниже
параметра PCTUSED. До этого момента свободная память в блоке
может использоваться лишь для обновления строк, уже содержащихся
в блоке данных. Например, предположим, что вы специфицировали
следующий параметр в предложении CREATE TABLE:
PCTUSED 40
В этом случае, блок данных в сегменте данных, после заполнения
его до отметки PCTFREE, не будет рассматриваться для вставки
новых строк до тех пор, пока процент используемой памяти в блоке
не упадет до 39% или ниже. Рис. 3-4 иллюстрирует это.
Блок базы данных
PCTUSED = 40
┌────────────────────────┐
│ Общий и переменный
│
│ заголовок
│
├────────────────────────┤
│ Оглавление таблиц
│
├────────────────────────┤
│ Оглавление строк
│
│
│
├────────────────────────┤
│ Свободное пространство │ │
│
20%
│
│
│
│
│
│
│
│
│
│
│
│
│ │
├────────────────────────┤
│ Данные строк
│
│
│ В блок не вставляются новыестроки,
│
│ пока объем занятого пространства
│
│ не упадет ниже 40%
│
│
│
│
└────────────────────────┘
Как PCTFREE и PCTUSED работают вместе
PCTFREE и PCTUSED работают вместе, чтобы оптимизировать
использование пространства в блоках данных экстентов внутри
сегмента данных. Рис.3-5 иллюстрирует, как PCTFREE и PCTUSED
работают вместе для управления свободным пространством в блоке.
Поддержка свободной памяти в блоках данных через PCTFREE и PCTUSED
Блок базы данных
PCTFREE = 20, PCTUSED = 40
┌────────────────────────┐
┌────────────────────────┐
│ Заголовок
│
│ Заголовок
│
├────────────────────────┤
├────────────────────────┤
│ Оглавление таблиц
│
│ Оглавление таблиц
│
├────────────────────────┤
├────────────────────────┤
│ Оглавление строк
│
│ Оглавление строк
│
├────────────────────────┤
├────────────────────────┤
│ Свободное пространство │ │
│ Свободное пространство │
│
│
│
│ │
│
│
├────────────────────────┤
│
│
│
│
│
│ │
│
│
├────────────────────────┤
│
│
│ Данные строк
│
│ Данные строк
│
│
│
│
│
│
│
│
│
└────────────────────────┘
└────────────────────────┘
1. Строки вставляются до 80%, так как PCTFREE диктует,чтобы 20% блока оставалось
свободным для обновления существующих строк.
2. Обновления существующих строк могут использовать свободную память в блоке. Новые
строки не могут вставляться в блок, пока занятая память не станет 39% или меньше.
│
┌────────────────────────┐
│ Заголовок
│
├────────────────────────┤
│ Оглавление таблиц
│
├────────────────────────┤
│ Оглавление строк
│
├────────────────────────┤
│ Свободное пространство │ │
│
│
│
│
│
│
│
│
│
│ │
├────────────────────────┤
│ Данные строк
│
│
│
└────────────────────────┘
┌────────────────────────┐
│ Заголовок
│
├────────────────────────┤
│ Оглавление таблиц
│
├────────────────────────┤
│ Оглавление строк
│
├────────────────────────┤
│ Свободное пространство │
│
├────────────────────────┤
│ Данные строк
│
│
│
│
│
│
│
│
│
│
│
└────────────────────────┘
3. Когда объем занятого пространства упадет ниже 40%, в блок снова можно вставлять
новые строки.
4. Строки вставляются до 80%, так как PCTFREE диктует,чтобы 20% блока оставалось
свободным для существующих строк.
Цикл
продолжается ...
Как ORACLE использует PCTFREE и PCTUSED
Во вновь распределенном блоке данных, место, доступное для
вставок, равно размеру блока минус сумма накладных расходов
(заголовок блока) и PCTFREE. Обновление существующих данных
может использовать все свободное пространство в блоке; поэтому
обновления могут сделать свободное место в блоке меньшим чем
PCTFREE, - пространство, резервируемое для обновлений, но
недоступное для вставок.
Для каждого сегмента данных и сегмента индекса ORACLE
поддерживает один или несколько СВОБОДНЫХ СПИСКОВ; свободный
список - это список блоков данных, которые были распределены для
экстентов этого сегмента и имеют процент свободной памяти,
превышающий PCTFREE; эти блоки доступны для вставок. Когда
выдается предложение INSERT, ORACLE ищет в свободном списке
таблицы первый доступный блок и использует его, если можно; если
свободного пространства в этом блоке слишком мало, чтобы
удовлетворить требованиям этого INSERT, и по меньшей мере равно
PCTUSED, то этот блок выбрасывается из свободного списка.
Несколько свободных списков на сегмент могут уменьшить
соперничество за свободные списки, когда имеют место
одновременные вставки.
Когда выдаются предложения DELETE и UPDATE, ORACLE проверяет, не
стало ли место, используемое в блоке, меньше чем PCTUSED; если
это так, то блок передвигается в начало свободного списка, и
будет первым используемым из доступных блоков.
Доступность и сжатие свободного пространства в блоке данных
Два типа предложений освобождают пространство в одном или
нескольких блоках данных: предложения DELETE и те предложения
UPDATE, которые заменяют существующие значения на меньшие.
Память, освобожденная в результате этих типов предложений,
доступна для последующих предложений INSERT при следующих
условиях:
* Если предложение INSERT находится в той же транзакции и
следует за предложением, освобождающим пространство, то
такое предложение INSERT может использовать
освободившееся пространство.
* Если предложение INSERT находится в одной транзакции, а
предложение, освобождающее пространство - в другой (может
быть, исполняемой другим пользователем), то предложение
INSERT может использовать освободившееся пространство
после того, как вторая транзакция будет подтверждена, и
лишь в случае потребности в этом пространстве.
Освобождаемое пространство не обязательно будет смежным с
основной областью свободного пространства в блоке. Свободное
пространство в блоке объединяется ("сжимается") ТОЛЬКО тогда,
когда предложение UPDATE или INSERT пытается использовать блок,
содержащий достаточно свободного места, для размещения нового
куска строки, но фрагментация свободной памяти не позволяет
вставить этот кусок строки в непрерывный участок блока. Таким
образом, производительность базы данных не страдает от
непрерывных и излишних сжатий свободной памяти блоков по каждой
операции DELETE или UPDATE.
Цепочки строк между блоками данных
В некоторых обстоятельствах все данные строки таблицы могут не
умещаться в один блок данных. В таком случае данные этой строки
сохраняются в ЦЕПОЧКЕ блоков данных, резервируемых в этом
сегменте. Цепочки строк возникают чаще всего при больших
строках (т.е. строках, содержащих столбец с типом данных LONG
или LONG RAW).
Если таблица содержит столбец с типом данных LONG, который
позволяет содержать до двух гигабайт информации, то данные этой
строки могут потребовать цепочки из двух или более блоков
данных. Такого типа цепочек блоков избежать невозможно.
Если строка в блоке данных обновляется так, что общая длина
строки увеличивается, а свободное пространство в блоке
заполнено, то данные всей строки МИГРИРУЮТ, т.е. переносятся в
новый блок данных, при условии, что в новом блоке поместится вся
строка. На месте первоначального куска мигрировавшей строки
записывается указатель на новый блок, содержащий мигрировавшую
строку; ROWID мигрировавшей строки не изменяется.
Когда строка занимает цепочку блоков или мигрирует,
производительность операций ввода-вывода, связанных с этой
строкой, падает, потому что ORACLE вынужден просматривать больше
одного блока данных, чтобы извлечь информацию строки. О том,
как уменьшить миграцию строк и улучшить производительность,
смотрите в документе ORACLE7 Server Apllication Developer's
Guide.
Экстенты
Экстент - это логическая единица распределения пространства базы
данных, состоящая из определенного числа непрерывных блоков
данных. Каждый тип сегмента состоит из одного или нескольких
экстентов. Когда существующее пространство в сегменте полностью
использовано, ORACLE распределяет для сегмента новый экстент.
В этом разделе описано, как распределяются экстенты для
сегментов.
Когда распределяются экстенты для сегментов
Независимо от типа, каждый сегмент в базе данных создается по
меньшей мере с одним экстентом для хранения его данных. Этот
экстент называется НАЧАЛЬНЫМ экстентом данного сегмента.
Замечание: Сегменты отката представляют исключение из этого
правила; они всегда имеют как минимум два экстента.
Например, при создании таблицы ее сегмент данных содержит
начальный экстент из заданного числа блоков данных. Хотя ни
одной строки еще не вставлено, блоки данных ORACLE, занимаемые
начальным экстентом, уже зарезервированы для строк этой таблицы.
Когда блоки данных в начальном экстенте сегмента заполнятся и
потребуется дополнительное пространство для новых данных, ORACLE
автоматически распределяет ИНКРЕМЕНТАЛЬНЫЙ экстент для этого
сегмента. Инкрементальный экстент - это очередной экстент,
размер которого совпадает с размером предыдущего экстента для
данного сегмента или превышает его на определенную величину
(инкремент).
Для целей сопровождения, каждый сегмент в базе данных содержит
заголовок сегмента, который описывает характеристики этого
сегмента и оглавление (список) экстентов в этом сегменте.
Как распределяются экстенты для сегментов
ORACLE управляет действительным распределением экстентов для
данного сегмента. При распределении нового экстента для
сегмента выполняются следующие шаги:
1. ORACLE отыскивает (в табличном пространстве, содержащем
сегмент) первый свободный, непрерывный участок блоков данных,
составляющих размер инкрементального сегмента (или больше).
Свободное пространство для нового экстента отыскивается с
помощью следующего алгоритма:
a. ORACLE ищет непрерывный набор блоков данных, совпадающий
с размером нового экстента, предварительно округленным вверх
для уменьшения внутренней фрагментации. Например, если новый
экстент требует 19 блоков данных, ORACLE ищет ровно 20
непрерывных блоков данных.
b. Если точное совпадение не найдено, ORACLE ищет множество
непрерывных блоков данных, размером не меньшее требуемого
размера. Если ORACLE находит группу непрерывных блоков,
минимум на пять блоков большую, чем требуемый размер
экстента, то он расщепляет эту группу блоков на отдельные
экстенты, один из которых имеет требуемый размер; если размер
такой группы превышает требуемый размер меньше, чем на пять
блоков, то новому экстенту распределяется вся эта группа
блоков.
Продолжая наш пример, если ORACLE не находит группу ровно из
20 непрерывных блоков данных, он начинает искать множество
непрерывных блоков данных числом больше 20. Если первая
найденная группа содержит 25 или более блоков, ORACLE
разбивает эти блоки, выделяя из них новый экстент; если
первая найденная группа содержит от 21 до 24 блоков, новому
экстенту распределяются все эти блоки.
c. Если больший набор непрерывных блоков не найден, ORACLE
соединяет все свободные смежные блоки данных в
соответствующем табличном пространстве, так что формируются
группы непрерывных блоков большего размера. (Фоновый процесс
SMON также периодически объединяет смежное свободное
пространство.) После соединения блоков данных в табличном
пространстве этапы поиска (a) и (b) повторяются второй раз.
Если экстент не может быть распределен и после вторичного
поиска, возвращается ошибка.
2. После того, как ORACLE находит необходимое свободное место в
табличном пространстве, часть этого свободного места,
соответствующая размеру инкрементального экстента,
распределяется этому экстенту. Если ORACLE нашел участок
свободного пространства большего размера, чем требуется для
экстента, то остаток оставляется как свободное пространство
(но не меньше, чем пять непрерывных блоков).
3. Заголовок сегмента и словарь данных обновляются, чтобы
показать, что новый сегмент распределен, и что распределенное
пространство больше не свободно.
Обычно ORACLE обнуляет блоки вновь распределенного экстента при
первом использовании этого экстента; в некоторых случаях
(например, когда АБД выдает предложение ALTER TABLE или ALTER
CLUSTER с опцией ALLOCATE EXTENT при использовании групп
свободных списков), ORACLE обнуляет блоки экстента в момент
распределения этого экстента.
Когда освобождаются экстенты
В общем случае, экстенты сегмента не возвращаются в табличное
пространство, пока сегмент не освобождается как единица, как,
например, при удалении таблицы или кластера предложениями DROP
TABLE или DROP CLUSTER. Эти правила имеют следующие исключения:
* Владелец таблицы или кластера, или пользователь с
привилегией DELETE ANY, может осуществить усекание
таблицы с помощью предложения TRUNCATE.
* Периодически ORACLE может освобождать один или несколько
экстентов сегмента отката.
При освобождении экстентов словарь данных обновляется, чтобы
отразить вновь приобретенные экстенты как свободное
пространство. Все данные в блоках освободившихся экстентов
становятся недоступными, и обнуляются, когда эти блоки будут
впоследствии использованы для других экстентов.
Некластеризованные таблицы, снимки и журналы снимков
Пока существует некластеризованная таблица (в том числе таблица,
с которой делаются снимки или журнал снимков; о журналах снимков
см. на странице 21-33), или до тех пор, пока эта таблица не
усечена, все блоки данных в ее сегменте данных остаются
распределены этой таблице; новые строки для таблицы могут быть
вставлены в любой блок, если в нем достаточно свободного места.
Даже при удалении всех строк таблицы ее блоки данных не
освобождаются для использования другими объектами в табличном
пространстве.
При удалении некластеризованной таблицы все экстенты ее данных и
сегментов индексов освобождаются ORACLE для соответствующих
табличных пространств, и становятся доступными для других
объектов в этих табличных пространствах. Впоследствии, когда
другим сегментам потребуются большие экстенты, непрерывные
освобожденные экстенты идентифицируются ORACLE и объединяются в
экстенты большего размера, запрошенные другими сегментами.
Сегменты
Сегмент - это набор экстентов, содержащих все данные для
конкретного типа структуры логического пространства внутри
табличного пространства. Например, для каждой таблицы ORACLE
распределяет один или несколько экстентов, чтобы сформировать
сегмент данных этой таблицы; для каждого индекса ORACLE
распределяет один или несколько экстентов, чтобы сформировать
сегмент индекса для этого индекса.
База данных ORACLE может содержать четыре различных типа
сегментов:
* сегмент данных
* сегмент индекса
* сегмент отката
* временный сегмент
Сегменты данных
Каждая некластеризованная таблица (в том числе снимок и журнал
снимков) в базе данных ORACLE имеет единственный сегмент данных,
содержащий все данные этой таблицы. Этот сегмент данных
косвенно создается командой CREATE TABLE/SNAPSHOT/SNAPSHOT LOG.
Каждый кластер в базе данных ORACLE также имеет единственный
сегмент данных, содержащий все данные кластера, т.е. данные всех
таблиц в этом кластере. Этот сегмент данных косвенно создается
командой CREATE CLUSTER.
Параметры пространства для таблицы, снимка, журнала снимков или
кластера определяют способ распределения экстентов для сегмента
данных. Непосредственное указание этих параметров через команды
CREATE TABLE/SNAPSHOT/SNAPSHOT LOG/CLUSTER или ALTER
TABLE/SNAPSHOT/SNAPSHOT LOG/CLUSTER влияет на эффективность
хранения и извлечения данных в этом сегменте данных.
Сегменты индекса
Каждый индекс в базе данных ORACLE имеет единственный сегмент
индекса, содержащий все данные этого индекса. Этот сегмент
косвенно создается командой CREATE INDEX. Эта команда позволяет
вам специфицировать параметры пространства для экстентов
сегмента индекса, а также табличное пространство, в котором
должен быть создан этот сегмент индекса. (Сегмент данных для
таблицы и сегмент индекса для ассоциированного индекса не
обязаны размещаться в одном и том же табличном пространстве.)
Создатель индекса может управлять способом распределения
экстентов для сегмента индекса; непосредственное указание
параметров пространства влияет на эффективность хранения и
извлечения данных в этом сегменте индекса.
Сегменты отката
Каждая база данных содержит один или несколько сегментов отката.
Сегмент отката - это часть базы данных, в которой записываются
действия транзакций, которые, возможно, придется отменить в
некоторых обстоятельствах. Сегменты отката используются для
обеспечения согласованности по чтению, для отката транзакций и
для восстановления базы данных.
Последующие секции, касающиеся сегментов отката, предоставляют
информацию о том, как сегменты отката работают при откате
транзакций, согласованности по чтению и восстановлении базы
данных.
Временные сегменты
При обработке запросов ORACLE часто требует временного рабочего
пространства для промежуточных этапов обработки предложения SQL.
Это дисковое пространство, называемое ВРЕМЕННЫМ СЕГМЕНТОМ,
распределяется автоматически. Обычно временный сегмент нужен
как рабочая область для сортировки. Сегмент не создается, если
операция сортировки может быть выполнена в памяти, или если
ORACLE находит какой-нибудь иной способ выполнения операции с
использованием индексов.
Операции, требующие временных сегментов
Следующие предложения SQL могут потребовать использования
временного сегмента:
* CREATE INDEX
* SELECT ... ORDER BY
* SELECT DISTINCT ...
* SELECT ... GROUP BY
* SELECT ... UNION
* SELECT ... INTERSECT
* SELECT ... MINUS
* неиндексированные соединения
* некоторые коррелированные подзапросы
Например, если запрос содержит фразу DISTINCT, фразу GROUP BY и
фразу ORDER BY, то может потребоваться целых два временных
сегмента. Если приложения часто выдают предложения, приведенные
в показанном списке, то администратору базы данных следует
настроить параметр инициализации SORT_AREA_SIZE.
Билет №7
1. Вторая и третья нормальная формы.
Определение 1: Функциональная зависимость (functional dependence - FD). В отношении R атрибут
Y функционально зависит от атрибута X (X и Y могут быть составными атрибутами, т.е. реально
состоять из нескольких атомарных атрибутов) в том и только в том случае, если каждому значению
X соответствует в точности одно значение Y:
R.X -> R.Y.
Замечание: Термин "функциональная зависимость" не случаен, поскольку в точности соответствует
математическому понятию функции.
Определение 2: Полная функциональная зависимость. Функциональная зависимость R.X -> R.Y
называется полной, если атрибут Y не зависит функционально от любого точного подмножества X
(точным подмножеством множества X называется любое его подмножество, не совпадающее с X).
Определение 3: Транзитивная функциональная зависимость. Функциональная зависимость R.X ->
R.Y называется транзитивной, если существует такой атрибут Z, что имеются функциональные
зависимости R.X -> R.Z и R.Z -> R.Y.
Определение 4: Возможный ключ (alternative key). Возможным ключом отношения называется его
атомарный или составной атрибут, значения которого полностью функционально определяют
значения всех остальных атрибутов отношения.
Определение 5: Неключевой атрибут. Неключевым атрибутом называется любой атрибут
отношения, не входящий в состав первичного ключа.
Определение 6: Взаимно независимые атрибуты. Два или более атрибута называются взаимно
независимыми, если ни один из этих атрибутов не является функционально зависимым от других
атрибутов.
Определение 7: Отношение R находится в первой нормальной форме (1NF) если все значиения
атрибутов атомарны и все неключевые элементы функционально зависят от ключа.
Определение 8. Отношение R находится во второй нормальной форме (2NF) в том и только в том
случае, когда находится в 1NF и каждый неключевой атрибут полностью зависит от первичного
ключа.
Определение 9. Отношение R находится в третьей нормальной форме (3NF) в том и только в том
случае, если находится в 2NF и каждый неключевой атрибут нетранзитивно зависит от первичного
ключа.
Эквивалентным определением является следующее:
Определение 10. Третья нормальная форма (альтернативное определение). Отношение R
находится в третьей нормальной форме (3NF) в том и только в том случае, если все неключевые
атрибуты R взаимно независимы и полностью зависят от первичного ключа.
Примеры:
Рассмотрим следующий пример схемы отношения:
СОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ
(СОТР_НОМЕР, СОТР_ЗАРП, ОТД_НОМЕР, ПРО_НОМЕР, СОТР_ЗАДАН)
Первичный ключ:
СОТР_НОМЕР, ПРО_НОМЕР
Функциональные зависимости:
СОТР_НОМЕР -> СОТР_ЗАРП
СОТР_НОМЕР -> ОТД_НОМЕР
ОТД_НОМЕР -> СОТР_ЗАРП
СОТР_НОМЕР, ПРО_НОМЕР -> СОТР_ЗАДАН
Как видно, хотя первичным ключом является составной атрибут СОТР_НОМЕР, ПРО_НОМЕР, атрибуты
СОТР_ЗАРП и ОТД_НОМЕР функционально зависят от части первичного ключа, т.е. атрибута
СОТР_НОМЕР. В результате, мы не сможем вставить в отношение СОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ
кортеж, описывающий сотрудника, который еще не выполняет никакого проекта (первичный ключ не
может содержать неопределенное значение). При удалении кортежа мы не только разрушаем связь
данного сотрудника с данным проектом, но утрачиваем информацию о том, что он работает в некотором
отделе. При переводе сотрудника в другой отдел мы будем вынуждены модифицировать все кортежи,
описывающие этого сотрудника, или получим несогласованный результат. Такие неприятные явления
называются аномалиями схемы отношения. Они устраняются путем нормализации.
СОТРУДНИКИ-ОТДЕЛЫ
(СОТР_НОМЕР, СОТР_ЗАРП, ОТД_НОМЕР)
Первичный ключ:
СОТР_НОМЕР
Функциональные зависимости:
СОТР_НОМЕР -> СОТР_ЗАРП
СОТР_НОМЕР -> ОТД_НОМЕР
ОТД_НОМЕР -> СОТР_ЗАРП
СОТРУДНИКИ-ПРОЕКТЫ
(СОТР_НОМЕР, ПРО_НОМЕР, СОТР_ЗАДАН)
Первичный ключ:
СОТР_НОМЕР, ПРО_НОМЕР
Функциональная зависимость:
СОТР_НОМЕР, ПРО_НОМЕР -> СОТР_ЗАДАН
Каждое из этих двух отношений находится в 2NF, и в них устранены отмеченные выше аномалии (легко
проверить, что все упомянутые выше операции выполняются без проблем).
3NF ---->:
Можно произвести декомпозицию отношения СОТРУДНИКИ-ОТДЕЛЫ в два отношения
СОТРУДНИКИ и ОТДЕЛЫ:
СОТРУДНИКИ (СОТР_НОМЕР, ОТД_НОМЕР)
Первичный ключ:
СОТР_НОМЕР
Функциональная зависимость:
СОТР_НОМЕР -> ТД_НОМЕР
ОТДЕЛЫ (ОТД_НОМЕР, СОТР_ЗАРП)
Первичный ключ:
ОТД_НОМЕР
Функциональная зависимость:
ОТД_НОМЕР -> СОТР_ЗАРП
Каждое из этих двух отношений находится в 3NF и свободно от отмеченных аномалий.
На практике третья нормальная форма схем отношений является достаточной в большинстве случаев и
приведением к третьей нормальной форме процесс проектирования реляционной базы данных обычно
заканчивается. Однако иногда полезно продолжить процесс нормализации.
2.Физические структуры базы данных Oracle (файлы данных, файлы журнала
повторения работы и управляющие файлы).
Используемые данные базы данных ORACLE логически хранятся в ТАБЛИЧНЫХ
ПРОСТРАНСТВАХ, а физически располагаются в ФАЙЛАХ ДАННЫХ, ассоциированных
соответствующим табличным пространством. Рис. иллюстрирует эту взаимосвязь.
с
Файлы данных: физические структуры, каждая из которых связанас одним табличным
пространством.
Объекты:
Хранятся в табличных пространствах, и могут
располагаться в нескольких
файлах данных
Хотя базы данных, табличные пространства, файлы данных и сегменты тесно связаны, они
имеют важные отличия:
Файлы данных и табличные пространства
Табличное пространство (один или несколько файлов данных)
┌──────────────────────────────────────────────────────────────┐
│ Файл данных
Файл данных
│
│ ╔═══════════════════════╗
╔════════════════════════════╗
│ ║
║
║
║ │
│ ║ ┌───────┐ ┌──────────╨───╨──────────────┐ ┌───────┐
║ │
│ ║ │Таблица│ │ Таблица
│ │Индекс │
║ │
│ ║ │
│ │
│ └───────┘
║ │
│ ║ │
│ │
│ ┌───────┐
║ │
│ ║ │
│ │
│ │Индекс │
║ │
│ ║ └───────┘ └──────────╥───╥──────────────┘ └───────┘
║ │
│ ║ ┌───────┐ Файлы данных┌───────┐ ║
║ ┌───────┐
┌──────────┐
│ ║ │Индекс │ │Индекс │ ║
║ │Индекс │
│ Таблица │
║ │
│ ║ └───────┘ └───────┘ ║
║ └───────┘
│
│
║ │
│ ║ ┌───────┐ ┌───────┐ ║
║ ┌───────┐
│
│
║ │
│ ║ │Индекс │ │Индекс │ ║
║ │Индекс │
│
│
║ │
│ ║ └───────┘ └───────┘ ║
║ └───────┘
└──────────┘
║ │
│ ╚═══════════════════════╝
╚════════════════════════════╝ │
│
│
└──────────────────────────────────────────────────────────────┘
║
│
Базы данных и табличные пространства:
База данных ORACLE составлена из одного или нескольких единиц логической памяти,
называемых ТАБЛИЧНЫМИ ПРОСТРАНСТВАМИ. Все данные базы данных хранятся в
табличных пространствах этой базы данных.
Табличные пространства и файлы данных:
Каждое табличное пространство базы данных ORACLE пространства составлено из одного или
нескольких файлов и файлы данных операционной системы, называемых ФАЙЛАМИ ДАННЫХ.
Файлы данных табличного пространства физически хранят соответствующие данные базы
данных на диске.
Базы данных и файлы данных:
Данные базы данных в совокупности хранятся в файлах данных, из которых состоит каждое
табличное пространство этой базы данных. Например, простейшая база данных ORACLE могла
бы иметь одно табличное пространство с одним файлом данных. Более сложная база данных
могла бы иметь три табличных пространства, каждое из
которых состоит из двух файлов данных (что в совокупности дает шесть файлов данных).
Объект схем, сегменты и табличные пространства:
При создании объекта схемы, такого как таблица или индекс, создается сегмент этого объекта в
предназначенном табличном пространстве базы пространства данных. Например,
предположим, что таблица создается в указанном табличном пространстве с помощью команды
CREATE TABLE с опцией TABLESPACE. Пространство для сегмента данных этой таблицы
распределяется в одном или нескольких файлах данных, составляющих это табличное
пространство. Сегмент объекта может размещаться лишь в одном табличном пространстве базы
данных.
Файлы данных
Табличное пространство в базе данных ORACLE состоит из одного или нескольких
физических ФАЙЛОВ ДАННЫХ. Файлы данных, ассоциированные с табличным
пространством, хранят все данные этого табличного пространства. Любой файл данных может
ассоциироваться только с одним табличным пространством и только
с одной базой данных.
При создании файла данных для табличного пространства ORACLE
распределяет ему
указанное количество дисковой памяти. Когда файл данных создается, операционная система
несет ответственность за очистку старой информации и за установку должных режимов доступа к
файлу, прежде чем он будет распределен ORACLE. Если файл велик, этот процесс (очистка)
может потребовать значительного времени.
Поскольку первым табличным пространством в любой базе данных
всегда является
SYSTEM, первые файлы данных любой базы данных
автоматически распределяются
табличному пространству SYSTEM во
время создания базы данных.
Содержимое файла данных
После первоначального создания файла данных соответствующее дисковое пространство еще
не содержит никаких данных; однако это пространство ЗАРЕЗЕРВИРОВАНО за будущими
сегментами ассоциированного табличного пространства - оно не может содержать каких-либо
иных (чужих) данных. Когда сегмент (например, сегмент данных таблицы) будет создан и
начнет увеличиваться в размерах, ORACLE использует свободное место в соответствующих
файлах данных, чтобы распределять экстенты для этого сегмента.
Данные в сегментах объектов (сегментах данных, сегментах индексов, сегментах отката и
т.д.) в табличном пространстве физически хранятся в одном или нескольких файлах данных,
составляющих это табличное пространство. Заметьте, что объект схемы не соответствует
определенному файлу данных; скорее, файл данных является хранилищем данных любого объекта
в конкретном
табличном пространстве. Экстенты одного сегмента могут быть
распределены в нескольких файлах данных табличного пространства;
таким образом, объект может "занимать" один или несколько файлов данных. Обычно АБД и
пользователи не могут контролировать, в каких файлах данных размещается объект.
Офлайновые файлы данных
Табличные пространства в любой момент можно переводить в ОФЛАЙН (т.е. делать
недоступными) или в ОНЛАЙН (делать доступными).Поэтому все файлы данных, составляющие
табличное пространство,
переводятся в офлайн или онлайн одновременно, всей группой.
Индивидуальные файлы данных также могут быть переведены в офлайн; однако это
обычно делается лишь при некоторых процедурах
восстановления базы данных.
Журнал Повторений
Каждая база данных ORACLE имеет набор из двух или более ФАЙЛОВ ЖУРНАЛА ПОВТОРЕНИЯ РАБОТЫ.
Комплект файлов журнала повторения работы для одной базы данных совместно называется ЖУРНАЛОМ
ПОВТОРЕНИЯ (redo log).
В базе данных Oracle имеется файлы двух типов:
Файлы данных, сгруппированные в табличные пространства.
Файлы данных, относящиеся к классу журнала повтора.
В базе данных как минимум должно быть не менее двух оперативных журналов повтора.
Журнал повтора часто называют журналом транзакций. Основная функция журнала повторения - регистрация всех
изменений, осуществляемых в данных. Все изменения, выполняемые в базе данных, записываются в журнал повторения.
Если в результате сбоя модифицированные данные не удастся постоянно записать в файлы данных, эти изменения
можно получить из журнала повторения, так что результаты работ никогда не теряется, т.е. можно произвести не только
восстановление старой копии БД, но и повторить все транзакции, выполненные к моменту сбоя.
Файлы журнала повторения критичны в вопросе защиты базы данных от сбоев. Чтобы защититься от таких сбоев,
которые затрагивают сам журнал повторения, ORACLE допускает ЗЕРКАЛЬНЫЙ ЖУРНАЛ ПОВТОРЕНИЯ, так что
две или более копий журнала повторения можно поддерживать одновременно на разных дисках.
Информация в файле журнала повторения используется только для восстановления базы данных после сбоя системы или
носителя, в результате которого данные базы данных не могут быть записаны в файлы данных.
Процесс применения журнала повторения в процессе операции восстановления базы данных называется ПРОКРУТКОЙ
ВПЕРЕД. База данных может работать в двух режимах. В режиме ARCHIVELOG и в режиме NOARCHIVELOG,
соответственно либо, создается архивная копия всех журналов транзакций, либо содержимое транзакций не сохраняется.
Для определения текущего режима работы экземпляра выдают команду archive log list, из под Server* Manager. Многие
аспекты процесса архивирования указаны параметрами файла INIT.ORA Восстановление после сбоя экземпляра, с
использование только журнала обновления, называется - оперативным восстановлением.
Чтобы добавить новые члены в существующую группу журнала, используйте либо диалог Add Online Redo Log Member
в SQL*DBA, либо команду SQL ALTER DATABASE с параметром ADD LOGFILE MEMBER. Для удаления группы
онлайнового журнала повторения вы должны иметь системную привилегию ALTER DATABASE.
Число онлайновых файлов журнала базы данных ограничивается тремя параметрами:
Параметр MAXLOGFILES, который использовался в предложении CREATE DATABASE при создании базы
данных, определяет максимальное число групп онлайнового журнала на базу данных; номера групп могут
изменяться от 1 до MAXLOGFILES. Единственный способ перекрыть эту верхнюю границу - заново создать
базу данных или ее управляющий файл; поэтому важно рассмотреть это значение перед созданием базы данных.
Если в предложении CREATE DATABASE не указан параметр MAXLOGFILES, то ORACLE использует
умалчиваемое значение, зависящее от операционной системы.
Параметр LOG_FILES в файле параметров может временно уменьшить максимальное число групп файлов
журнала на время исполнения текущего экземпляра. Значение этого параметра не может превышать значение
MAXLOGFILES. Если в файле параметров не указан параметр LOG_FILES, то ORACLE использует
умалчиваемое значение, зависящее от операционной системы.
Параметр MAXLOGMEMBERS, который использовался в предложении CREATE DATABASE при создании
базы данных, определяет максимальное число членов в группе. Как и для MAXLOGFILES, единственный
способ перекрыть эту верхнюю границу - заново создать базу данных или ее управляющий файл; поэтому важно
рассмотреть это значение перед созданием базы данных. Если в предложении CREATE DATABASE не указан
параметр MAXLOGMEMBERS, то ORACLE использует умалчиваемое значение, зависящее от операционной
системы.
Журнал повтора можно разделить на две категории: оперативные и архивные. Оперативные
журналы повтора – это два и более журналов, записываемые во время работы базы данных;При
работе в режиме ARCHIVELOG перед началом перезаписи Oracle копирует содержимое очередного
оперативного журнала повтора в соответствующее место на диске, где хранятся архивные журналы
повтора. В момент переключения оперативных журналов повтора, каждому создаваемому журналу
присваивается определенный порядковый номер, в соответствие с коим происходит процесс
переключения журналов повтора.
К примеру: Уже после второго переключения журнала повтора копируется журнал повтора из
первой группы, после чего созданная копия будет называется архивным журналом повтора.
Номер цикла
Порядковый номер
архивного журнала
Группа журнала
повтора
Состояние
Подключение №1
18
1
2
3
Активна
Не активна
Архивируется
Подключение №2
19
1
2
3
Архивируется
Активна
Не активна
Подключение №3
20
1
2
3
Не активна
Архивируется
Активна
Подключение №4
21
1
2
3
Активна
Не активна
Архивируется
Создание групп онлайнового журнала
Можно создать группы онлайнового журнала и как часть создания базы данных, и позднее. Если
возможно, спланируйте журнал и создайте все необходимые группы файлов журнала во время
создания базы данных. Для создания новой группы онлайнового журнала используйте команду SQL:
ALTER DATABASE с параметром ADD LOGFILE.
Управляющие файлы
Каждая база данных ORACLE имеет УПРАВЛЯЮЩИЙ ФАЙЛ, в котором записывается
физическая структура базы данных. В частности, этот файл содержит следующую информацию:
* имя базы данных
* имена и местоположения файлов данных и файлов журнала
повторения этой базы
данных
* отметку времени создания базы данных
Как и для журнала повторения, ORACLE позволяет поддерживать зеркальные управляющие
файлы с целью защиты управляющей информации.
Использование управляющих файлов
При каждом запуске инстанции базы данных ORACLE ее управляющий файл используется
для того, чтобы идентифицировать базу данных и файлы журнала повторения, которые должны
быть открыты для продолжения работы базы данных. Когда физический состав базы
данных изменяется (например, создается новый файл данных или
файл журнала), ORACLE
автоматически модифицирует управляющий
файл, чтобы отразить это изменение.
Управляющий файл базы данных используется также в тех случаях, когда требуется
восстановление базы данных.
///////////////////////
Сценарий catproc. sql создает стандартные модули Oracle, часто используемые при разработке программ на PL/SQL.
Этот сценарий нужно выполнять после создания базы данных, подключившись к Oracle с помощью SQL*Plus как
администратор
В Огас1е8i добавлены следующие активизирующие события:
alter Триггер активизируется при изменении объекта базы данных
create Триггер активизируется при создании объекта базы данных
drop Триггер активизируется при удалении объекта базы данных
logoff Триггер активизируется при отключении пользователя от Огас1е8i
logon Триггер активизируется при регистрации пользователя в Oracle8i
servererror Триггер активизируется при получении пользователем сообщения об ошибке от Oracle8i
shutdown Триггер активизируется непосредственно перед остановкой экземпляра Oracle8i
startup Триггер активизируется при запуске экземпляра Огас1е8i
Физическими дисковыми ресурсами Oracle являются управляющие файлы, журналы повтора и файлы данных
Физическим дисковым ресурсам соответствуют логические: табличные области, сегменты, экстенты и блоки
Управляющие файлы используются для указания экземпляру Oracle местонахождения других файлов,
необходимых для его нормальной работы
Содержимое управляющего файла находится в сценарии его создания, который генерируется командой alter
database backup controlfile to trace. Затем этот файл можно найти в каталоге, указанном параметром
инициализации USER_DUMP_DEST
Сведения об управляющих файлах, например об их местонахождении, можно получить в V$CONTROLFILE,
V$DATABASE и V$CONTROLFILE_RECORD_SECTION
Важно мультиплексировать управляющие файлы, чтобы снизить зависимость от одного дискового ресурса
хост-машины. Для этого используется параметр CONTROL_FILES файла initsid.ora
Архитектура журналов повтора Oracle состоит из следующих компонентов: буфера журналов повтора, где
хранятся элементы повтора пользовательских процессов; процесса LGWR, переносящего элементы повтора из
памяти на диск; и из оперативных журналов повтора на диске, в которых сохраняются элементы повтора,
извлекаемые из памяти
Оперативные журналы повтора называются группами. Группа состоит из одного или нескольких файлов
(компонентов), в которые LGWR переписывает элементы повтора из памяти. Чтобы экземпляр Oracle мог
запускаться, должны существовать, как минимум, две группы оперативных журналов повтора
Контрольные точки - это события, во время которых LGWR сообщает DBWR о необходимости записать все
измененные блоки на диск. Это происходит во время переключения журналов (переключения регистр
Используемые данные базы данных ORACLE логически хранятся в ТАБЛИЧНЫХ ПРОСТРАНСТВАХ, а
физически располагаются в ФАЙЛАХ
ДАННЫХ, ассоциированных с соответствующим
табличным
пространством.
ации), когда LGWR прекращает запись информации в заполненный журнал и начинает запись в новый журнал.
В этот момент LGWR еще и фиксирует изменение порядка файлов журналов повтора в заголовках файлов
данных и в управляющем файле
Важно понимать, как LGWR записывает данные повтора в журналы, переходя от одного к другому и
возвращаясь обратно, что происходит при использовании архивирования, какова роль процесса ARCH и как
LGWR может конкурировать с ARCH
Журналы повтора мультиплексируются с помощью операторов create database и alter database; это следует
делать обязательно
LogMiner позволяет исследовать содержимое оперативных и архивных журналов повтора
Для работы с LogMiner используются два модуля: DBMS_LOGMNR_D - для управления файлом словаря
LogMiner - и DBMS_LOGMNR - для управления собственно LogMiner
Процедура build () из DBMS_LOGMNR_D формирует файл словаря LogMiner в виде текстового файла,
внешнего для Oracle. Перед выполнением этой процедуры нужно установить каталог для записи файла
словаря, используя параметр UTL_FILE_DIR
Для анализа конкретных файлов журналов нужно идентифицировать их в LogMiner в виде списка. Для этого
используется процедура add_logfile() из DBMS_LOGMNR, принимающая ряд параметров
Для запуска и остановки LogMiner используются процедуры start_logmnr() и stop_logmnr(). Для процедуры
start_logmnr() нужно указывать ряд параметров
Сведения о содержимом журналов повтора можно найти в V$LOGMNR_CONTENTS
В LogMiner можно найти сведения только о тех операторах DML, которые выполнялись над несцепленными
строками, когда тип данных, над которыми производились манипуляции, был скалярным (к примеру,
VARCHAR2, но не LOB или VARRAY). Содержимое V$LOGMNR_CONTENTS можно видеть только из сеанса, в
котором выполняется LogMiner
Табличные области и файлы данных взаимосвязаны. Табличная область может состоять из нескольких файлов
данных, но каждый файл данных должен быть связан только с одной табличной областью
Во время создания базы данных существует только одна табличная область - SYSTEM. Администратору БД не
следует размещать все объекты базы в этой табличной области, так как нередко к их хранению
предъявляются противоречивые требования. Вместо этого ему нужно создать несколько табличных областей
для различных сегментов, доступных в базе данных, и поместить объекты в эти табличные области
Сегменты (и табличные области) бывают разных видов: табличные, индексные, отката и временные.
Сегменты двух других видов (кластерные и IOT) используются довольно редко, и поэтому их можно
размещать в табличной области данных, не мешая при этом другим объектам
Чтобы отделить прикладные данные от объектов, создаваемых в поддержку таких административных
инструментов, как Oracle Enterprise Manager, нужно создать табличную область TOOLS
Когда сегмент, содержащий объект базы данных, больше не может вместить его информацию, Oracle
выделяет для хранения данных новый экстент. Это отрицательно влияет на производительность системы.
Нужно соблюдать разумный баланс между предварительным выделением пространства сегментам и
выделением новых экстентов
Существуют временные сегменты двух видов: для постоянных табличных областей и для временных
табличных областей
Использование временных сегментов в Oracle усовершенствовано, чтобы повысить эффективность операций
дисковой сортировки. Сегменты сортировки во временных табличных областях выделяются для первой
дисковой сортировки, а затем продолжают быть доступными в течение всего времени работы экземпляра.
Результатом является более низкий уровень фрагментации, чем при хранении временных сегментов в
постоянных табличных областях
Новая область памяти, называемая пулом экстентов сортировки, позволяет пользовательским процессам
получать экстенты для дисковой сортировки во временных табличных областях
Когда временные сегменты больше не нужны транзакции, процесс SMON отменяет их выделение в
постоянных табличных областях
Во временных табличных областях нельзя создавать постоянные объекты базы данных, например таблицы.
Кроме того, нельзя превращать постоянные табличные области во временные, если в постоянной табличной
области находятся постоянные объекты
Сведения о временных сегментах и сегментах сортировки можно получить в представлениях словаря
DBA_SEGMENTS, V$SORT_SEGMENT, V$SESSION и V$SORT_USAGE
Сегмент сортировки существует во временной табличной области, пока доступен экземпляр. С сегментом
сортировки могут совместно работать все пользователи
Размер экстентов временной табличной области должен быть установлен кратным SORT_AREA_SIZE плюс
один дополнительный блок для заголовка сегмента, что повышает производительность операций дисковой
сортировки
Oracle позволяет администратору БД управлять использованием дискового пространства на уровне блоков с
помощью параметров pctfree и pctused
Для получения сведений о структурах хранения информации используются представления словаря данных
DBA_SEGMENTS, DBA_TABLESPACES, DBA_TS_QUOTAS, V$TABLESPACE, DBA_EXTENTS,
DBA_FREE_SPACE и DBA_FREE_SPACE_COALESCED
Между временем существования экстентов и уровнем фрагментации табличной области существует
обратно пропорциональная зависимость: чем меньше время существования, тем выше вероятность
фрагментации
Билет №8
1. Связь технологий моделирования данных с использованием ERD с
технологиями нормализации данных.
2. Словарь данных и структуры памяти Oracle.
Каждая база данных ORACLE имеет СЛОВАРЬ ДАННЫХ. Он представляет собой
набор таблиц и обзоров, используемых как ТОЛЬКО ЧИТАЕМОЕ представление базы данных.
Например, в словаре данных хранится информация о логической и физической структуре базы
данных.
Помимо этой важной информации, словарь данных хранит также следующую информацию:
* о действительных пользователях базы данных ORACLE
* об ограничениях целостности, определенных для таблиц базы данных
* о том, сколько пространства распределено для каждого бъекта схемы, и сколько из него
используется
Словарь данных создается при создании самой базы данных. Чтобы точно отражать состояние
базы данных в любой момент, словарь данных автоматически обновляется ORACLE в ответ на
специальные
действия (такие как изменение структуры базы данных). Словарь
данных
критичен для работоспособности базы данных, ибо на нем
основывается регистрация,
верификация и управление текущей
работой. Например, во время операций с базой
данных ORACLE
обращается к словарю данных для проверки того, что объекты схем
существуют и что пользователи имеют к ним соответствующие права доступа.
Словарь данных является одной из важнейших частей базы данных
Например, словарь данных может предоставлять следующую информацию:
* имена пользователей ORACLE
* привилегии и роли, которые были предоставлены каждому
пользователю
* имена объектов схем (таблиц, обзоров, снимков, индексов,
кластеров, синонимов, последовательностей, процедур,
функций, пакетов, триггеров и т.д.)
* информацию об ограничениях целостности
* умалчиваемые значения для столбцов
* сколько пространства было распределено и в настоящее
время используется объектами в базе данных
* информацию аудитинга, например, кто обращался к
различным объектам и обновлял их
* в Trusted ORACLE - метки всех объектов и пользователей
* другую общую информацию о базе данных
Словарь данных структурирован через таблицы и обзоры, как и любые другие данные в
базе данных. Для обращения к словарю данных вы используете SQL. Так как словарь данных
можно только читать, пользователи могут выдавать лишь запросы (предложения SELECT) по
таблицам и обзорам словаря данных.
Структура словаря данных
В состав словаря данных базы данных входят:
базовые
Основу словаря данных составляет совокупность
таблицы
базовых таблиц, хранящих информацию о базе
данных. Эти таблицы читаются и пишутся ТОЛЬКО
самим ORACLE; они редко используются
непосредственно пользователем ORACLE любого
типа, потому что они нормализованы, и большая
часть данных в них закодирована.
доступные
Словарь данных содержит доступные пользователю
пользователю обзоры, которые суммируют и отображают в удобном
обзоры
формате информацию из базовых таблиц словаря.
Эти обзоры декодируют информацию базовых таблиц,
представляя ее в полезном виде, таком как имена
пользователей или таблиц, и используют
соединения и фразы WHERE, чтобы упростить
информацию. Большинство пользователей имеют
доступ к этим обзорам вместо базовых таблиц
словаря.
SYS, владелец словаря данных
Все базовые таблицы и обзоры словаря данных принадлежат пользователю ORACLE с
учетным именем SYS. Поэтому ни один пользователь ORACLE не должен НИКОГДА изменять
никаких объектов, содержащихся в схеме SYS, а администратор безопасности должен строго
контролировать использование этого центрального учетного имени.
[!] Замечание: Изменение данных или манипулирование ими в базовых
таблицах словаря данных может нанести необратимый ущерб
работоспособности базы данных.
Как используется словарь данных
Словарь данных базы данных ORACLE имеет два основных применения:
* ORACLE обращается к словарю данных каждый раз, когда
выдается предложение DDL.
* Каждый пользователь ORACLE может использовать словарь
данных как только-читаемый справочник по базе данных.
Как ORACLE и другие продукты Oracle используют словарь данных
Данные в базовых таблицах словаря данных необходимы для функционирования
ORACLE. Поэтому только ORACLE должен записывать или изменять информацию словаря
данных. Во время операций по базе данных ORACLE читает словарь данных, чтобы
удостовериться, что нужные объекты существуют, и что пользователи имеют к ним должный
доступ. ORACLE также непрерывно обновляет словарь данных, чтобы отражать происходящие
изменения в структурах базы данных, аудитинге, грантах и данных. Например, если пользователь
KATHY создает таблицу с именем PARTS, в словарь данных добавляются новые строки, чтобы
описать новую таблицу, ее столбцы, сегмент, экстенты, а также привилегии, которые
KATHY имеет по этой таблице. Эта новая информация становится видимой при очередном
опросе обзоров словаря.
Кэширование словаря данных для быстрого доступа
Поскольку ORACLE постоянно обращается к словарю данных для проверки прав доступа
пользователей и состояния объектов, большая часть информации словаря данных кэшируется в
SGA. Вся информация поддерживается в памяти с помощью алгоритма LRU (т.е. вытесняется
наиболее давно использовавшаяся информация). Обычно в кэше поддерживается информация,
требуемая для разбора предложений. Столбцы COMMENTS, описывающие таблицы и столбцы,
не кэшируются, если они не используются часто.
Словарь данных и другие программы
Другие продукты Oracle могут дополнительно создавать в словаре данных свои собственные
таблицы и обзоры, а также обращаться к существующим обзорам. Разработчики приложений,
которые пишут программы, обращающиеся к словарю данных, должны использовать общие
синонимы, а не сами базовые таблицы: эти синонимы менее подвержены изменениям между
версиями ORACLE.
Добавление новых элементов данных словаря
Вы можете добавлять в словарь данных новые таблицы или обзоры. Если вы добавляете новые
объекты в словарь данных, их владельцем должен быть SYSTEM или какой-либо третий
пользователь ORACLE. Никогда не создавайте новых объектов под учетным именем SYS, если
только вы не выполняете скрипт, специально предоставляемый фирмой Oracle для создания новых
объектов словаря данных.
Удаление элементов словаря данных
Так как все изменения в словаре данных осуществляются ORACLE в ответ на предложения
DDL, НИКАКИЕ ДАННЫЕ В ТАБЛИЦАХ СЛОВАРЯ ДАННЫХ НЕ ДОЛЖНЫ УДАЛЯТЬСЯ
ИЛИ ИЗМЕНЯТЬСЯ непосредственно пользователем. Единственное исключение из этого
правила представляет таблица SYS.AUD$. Когда включен режим аудитинга, эта таблица может
неограниченно расти. Хотя вы не должны удалять эту таблицу, администратор безопасности
может удалять из нее данные, потому что строки этой таблицы служат лишь для информации и не
являются необходимыми для работы ORACLE.
Общие синонимы для обзоров словаря данных
Общие синонимы создаются для многих обзоров словаря данных, так что они легко доступны
всем пользователям. Администратор безопасности может создавать дополнительнные общие
синонимы для общесистемных объектов. Однако другие пользователи должны избегать давать
своим собственным объектам имена, совпадающие с общими синонимами.
Структуры памяти
Механизмы ORACLE работают через использование структур памяти и
процессов. Все
структуры памяти располагаются в основной памяти
(иногда называемой виртуальной памятью
или памятью произвольного
доступа) компьютеров, составляющих систему базы данных.
ПРОЦЕССЫ - это задания или задачи, работающие в памяти этих
компьютеров.
Рис. показывает типичный вариант структур памяти и процессов
ORACLE. Все структуры
памяти и процессы, изображенные на этой
схеме, обсуждаются ниже.
Структуры памяти и процессы ORACLE
┌──────┐
┌──────┐
┌──────┐
┌──────┐
┌┴─────┐│
│ RECO │
│ PMON │
│ SMON │
┌┴─────┐├┘
└──┬───┘
└──┬───┘
└──┬───┘
│ LCK0 ├┘
│
│
│
└──┬───┘
┌───────────────┴──────────┴──────────┴─────────────┐
└─────────┤
Глобальная область системы (SGA)
│
│
┌────────────────────────────┐ ┌────────────┐
│
│
│
│ │ Буфер
│
│
│
│ Буферный кэш базы данных │ │ журнала
│
│
Пользова│
│
│ │ повторения │
│
тельские
│
└───┬──────────────┬─────────┤ └─────────┬──┘
│
процессы
└───────┼──────────────┼─────────┼───────────┼──────┘
┌─────────┐
│
│
│ ┌──────┐ │ ┌──────┐
┌┴────────┐│ ┌──────┴─────┐ ┌─────┴──────┐ │ │ CKPT │ │ │ ARCH ├───┐
┌┴────────┐││ │ Разделяемый│ │ Выделенный │ │ └─┬──┬─┘ │ └───┬─┬┘
│
│пользова-│││ │ серверный │ │ серверный │ │
│
- │
│
│тельский │├┘ │ процесс
│ │ процесс
│ ┌┴────┴┐ │ ┌─┴────┐│ │
│
│процесс ├┘ └─────┬────┬─┘ └─┬────────┬─┘ │ DBWR │ │┌┤ LGWR ││ │
│
└────┬────┘
│
│
└───┬──┘ ││└─┬────┘│ │
│
│
┌───┴──┐ │ ┌────┴────┐
│
││
│ │
│
└──────────┤ D000 │ │ │пользова-│
│ ┌─────┴──┐ ││┌─┴─────┴┐│
│
└──────┘ │ │тельский │
└─┤ Файлы ├┘││ Файлы ││
│
│ │процесс │ ┌──┤ данных │ ││ журнала││
│
│ └─────────┘ │ └────────┘ │└────────┘
│
│
│
┌────────┐│ ┌───────┴──┐ │
└──────────────┘
│ Управл.││ │Офлайновые│ │
│ файлы ├┘ │устройства│ │
└───┬────┘
└──────────┘ │
└─────────────────────┘
Структуры памяти
ORACLE создает и использует свои структуры памяти для выполнения некоторых задач.
Например, память используется для размещения исполняемого программного кода и данных,
разделяемых между пользователями. С ORACLE ассоциируются несколько базовых структур
памяти: глобальная область системы (которая включает буфера базы данных и журнала
повторения, а также разделяемый пул) и глобальные области программ. Следующие секции
подробно объясняют каждую из этих видов областей.
Глобальная область системы (SGA)
ГЛОБАЛЬНАЯ ОБЛАСТЬ СИСТЕМЫ (SGA) - это область разделяемой памяти,
распределяемая ORACLE, которая содержит данные и управляющую информацию для одной
инстанции ORACLE. Область SGA и фоновые процессы ORACLE составляют инстанцию
ORACLE.
SGA распределяется при запуске инстанции и освобождается при закрытии инстанции.
Каждая запускающаяся инстанция имеет свою
собственную область SGA.
Данные в SGA разделяются (т.е. совместно используются) всеми пользователями,
присоединенными к базе данных. Для оптимальной производительности SGA должна быть
максимально большой (пока позволяет реальная память), чтобы держать как можно больше
данных в памяти и минимизировать дисковые операции. Информация, хранящаяся в SGA,
подразделяется на несколько типов структур памяти, включая буфера базы данных, буфера журнала
повторения и разделяемый пул. Эти области имеют фиксированные размеры и создаются при
запуске инстанции.
Буферный кэш базы данных
БУФЕРА БАЗЫ ДАННЫХ в SGA хранят наиболее недавно использовавшиеся блоки
данных из базы данных; все множество буферов базы данных в инстанции составляет
БУФЕРНЫЙ КЭШ БАЗЫ ДАННЫХ. Эти буфера могут содержать модифицированные данные,
которые еще не записаны на диск для постоянного хранения.
Поскольку последние использовавшиеся (в том числе и наиболее часто использующиеся)
данные поддерживаются в памяти, требуется меньше дисковых операций, и производительность
увеличивается.
Буфер журнала повторения
БУФЕР ЖУРНАЛА ПОВТОРЕНИЯ в SGA хранит ЗАПИСИ ПОВТОРЕНИЯ – журнал
изменений, осуществленных в базе данных. Записи повторения, хранящиеся в буферах
журнала повторения, записываются в онлайновый файл журнала, который используется при
необходимости восстановления базы данных. Его размер статичен.
Разделяемый пул
Разделяемый пул - это часть SGA, содержащая конструкты разделяемой памяти, такие
как разделяемые области SQL. Разделяемая область SQL требуется для обработки каждого
уникального предложения SQL, выданного базе данных. (См. "Предложения SQL" на странице
1-22.) Разделяемая область SGA содержит такую информацию, как дерево разбора и план
исполнения для соответствующего предложения. Единственная разделяемая область SGA
используется всеми приложениями, которые выдают то же самое предложение. Это позволяет
оставлять больше разделяемой памяти для других целей.
Курсоры
КУРСОР - это описатель (имя или указатель) области памяти,
ассоциированной с
конкретным предложением. Хотя большинство пользователей ORACLE полагаются на
автоматическую обработку курсоров, обеспечиваемую утилитами ORACLE, программные
интерфейсы предлагают разработчикам приложений большую степень контроля над курсорами.
Например, при разработке приложений прекомпиляторов курсор является именованным ресурсом,
доступным программе, и может специально использоваться для разбора предложений SQL,
встроенных в приложение. Разработчик может написать приложение так, чтобы оно
контролировало фазы
исполнения предложения SQL и за счет этого повышало свою
производительность.
Глобальная область программы (PGA)
ГЛОБАЛЬНАЯ ОБЛАСТЬ ПРОГРАММЫ (PGA) - это буфер памяти, содержащий данные
и управляющую информацию для процесса сервера.
PGA создается ORACLE при запуске процесса сервера. Информация в области PGA зависит от
конфигурации ORACLE.
Билет №9
1. Распределенные базы данных.
Суть распределенной базы данных выражена формулой: "Доступ к распределенной базе данных
выглядит для клиента точно так же, как доступ к централизованной БД".
Рассмотрим пример. Пусть БД Склад расположена на узле Узел_1, а БД Предприятия - на узле
Узел_2. В первой содержится таблица Деталь, во второй - Поставщик. Пусть БД Номенклатура
должна включать таблицы Деталь и Поставщик, физически принадлежащие различным БД.
Логически она будет рассматриваться как нераспределенная БД. Ниже приведены операторы SQL,
которые устанавливают ссылки на таблицы локальных баз данных. Они включены в описание
распределенной базы данных и передаются серверу распределенной БД, о котором речь пойдет
ниже.
REGISTER TABLE Деталь AS LINK
WITH NODE = Узел_1,
DATABASE = Склад;
{ РЕГИСТРИРОВАТЬ ТАБЛИЦУ Деталь
КАК СВЯЗЬ
С УЗЛОМ = Узел_1
БАЗА ДАННЫХ = Склад;}
REGISTER TABLE Поставщик AS LINK
WITH NODE = Узел_2,
DATABASE = Предприятия;
{ РЕГИСТРИРОВАТЬ ТАБЛИЦУ
Поставщик КАК СВЯЗЬ
С УЗЛОМ = Узел_2
БАЗА ДАННЫХ = Предприятия;}
Таким образом, при описании распределенной БД Номенклатура явно задаются ссылки на
конкретные таблицы реально существующих баз данных; однако при работе с такой базой данных
это физическое распределение данных прозрачно для пользователя.
До сих пор мы говорили о проблемах сетевого взаимодействия клиента и сервера. Их решение с
помощью коммуникационного сервера является необходимым (но не достаточным) условием
поддержки распределенных баз данных. Неразрешенными пока остаются следующие задачи:
Управление именами в распределенной среде;
Оптимизация распределенных запросов;
Управление распределенными транзакциями.
Первая решается путем использования глобального словаря данных. Он хранит информацию о
распределенной базе данных: расположение данных, возможности других СУБД (если используется
шлюз), сведения о скорости передачи по сети с различной топологией и т.д.
Глобальный словарь данных - это механизм отслеживания расположения объектов в распределенной
БД. Данные могут храниться на локальном узле, на удаленном узле, или на обеих узлах - их
расположение должно оставаться прозрачным как для конечного пользователя, так и для
программы. В ней не нужно явным образом указывать место расположения данных - программа
должна быть полностью независима от того, на каких узлах размещаются данные, с которыми она
оперирует.
Что касается второй задачи, то она требует интеллектуального решения. Распределенный запрос
затрагивает несколько баз данных на различных узлах, причем объемы выборки могут быть весьма
различными. Обратимся к БД Номенклатура, которая распределена по двум узлам сети. Таблица
Деталь хранится на одном узле, таблица Поставщики - на другом. Размер первой таблицы - 10000
строк, размер второй - 100 строк (множество деталей поставляется небольшим числом
поставщиков). Допустим, что выполняется запрос:
SELECT Название_детали,
Название_поставщика,
Адрес_поставщика
FROM Деталь, Поставщик
WHERE Материал = "Пластмасса";
{ ВЫБРАТЬ Название_детали,
Название_поставщика,
Адрес_поставщика
ИЗ Деталь, Поставщик
ГДЕ Материал = "Пластмасса" }
Результат запроса - таблица, содержащая столбец Название_детали из таблицы Деталь, и столбцы
Название_поставщика и Адрес_поставщика из таблицы Поставщик. То есть результирующая
таблица представляет собой объединение (join) двух таблиц. Оно выполнено по столбцу
Номер_поставщика в таблице Деталь (внешний ключ) и столбцу Номер таблицы Поставщик
(первичный ключ).
Данный запрос - распределенный, так как затрагивает таблицы, принадлежащие различным
локальным БД. Для его нормального выполнения необходимо иметь обе исходные таблицы на
одном узле. Следовательно, одна из таблиц должна быть передана по сети. Очевидно, что это
должна быть таблица меньшего размера, то есть таблица Поставщик. Поэтому оптимизатор
распределенных запросов обязательно должен учитывать размер таблиц. В противном случае запрос
будет выполняться непредсказуемо долго.
Помимо размера таблиц, оптимизатор распределенных запросов должен учитывать также
множество дополнительных параметров, в том числе статистику распределения данных по узлам,
объем данных, передаваемых между узлами, скорость коммуникационных линий, структуры
хранения данных, соотношение производительности процессоров на разных узлах и т.д. Все эти
данные как раз и содержатся в глобальном словаре данных.
Что касается обработки распределенных транзакций, то эта тема будет обсуждаться в следующем
разделе.
Решение всех трех задач, о которых речь шла выше, возложено на специальный компонент СУБД сервер распределенных баз данных (Distributed Database Server).
Если база данных расположена на одном узле, и сервер БД и прикладная программа выполняются
там же, то не требуется ни коммуникационный сервер, ни сервер распределенной БД. Когда же
прикладная программа выполняется на локальном узле, БД находится на удаленном узле, и там же
выполняется сервер БД, то на удаленном узле необходим коммуникационный сервер, а на
локальном - сервисная коммуникационная программа.
Если распределенная БД состоит из таблиц локальных БД, которые находятся на одном узле, и там
же функционирует сервер распределенной БД, и выполняется прикладная программа, то
коммуникационный сервер не нужен (нет взаимодействия по сети). Если же локальные БД
расположены на нескольких узлах, то для доступа к распределенной БД необходим и сервер
распределенной БД, и коммуникационный сервер.
Важнейшее требование к современным СУБД - межоперабельность (или интероперабельность).
Это качество можно трактовать как открытость системы, позволяющая встраивать ее как компонент
в сложную разнородную распределенную среду. Оно достигается как за счет использования
интерфейсов, соответствующих международным, национальным и промышленным стандартам, так
и за счет специальных решений.
Для СУБД это качество означает следующее:
возможность приложений, созданных средствами разработки данной СУБД, оперировать над
базами данных в "чужом" формате так, как будто это собственные базы данных;
свойство СУБД, позволяющее ей служить в качестве поставщика данных для любых
приложений, созданных средствами разработки третьих фирм, поддерживающих некоторый
стандарт обращения к базам данных.
Первое достигается использованием шлюзов, второе - использованием интерфейса ODBC, который
будет рассмотрен в п.3.4.
До сих пор мы рассматривали однородные базы данных, то есть БД в формате конкретной СУБД. В
то же время СУБД может осуществлять доступ к БД в другом формате. Это делается с помощью
шлюза. Например, СУБД INGRES получает доступ к базе данных в формате СУБД Rdb через
специальный шлюз. Если СУБД Альфа осуществляет доступ к базе данных в формате Бета (или
просто к базе данных Бета), то говорят, что Альфа имеет шлюз в Бета.
Современные информационные системы требуют доступа к разнородным базам данных. Это
означает, что в прикладной программе для реализации запросов к базам данных должны быть
использованы такие средства, чтобы запросы были понятны различным СУБД, как реляционным,
так и опирающимся на другие модели данных. Одним из возможных путей является обобщенный
набор различных диалектов языка SQL (как это сделано, например, в СУБД OpenIngres).
Система, в которой несколько компьютеров различных моделей и производителей связаны в сеть, и
на каждом из них функционирует собственная СУБД, называется гетерогенной системой.
Рассмотрим пример такой системы (рис.1).
Рисунок 1.
Глобальная база данных распределена по трем узлам. Узел A - это компьютер VAX 6000/560 с ОС
VMS и СУБД Rdb, где расположена локальная БД Предприятия в формате Rdb. Второй (узел B)
представляет собой компьютер SUN Sparc Server 1000 под управлением операционной системы
Solaris. На нем функционирует СУБД Ingres и находится локальная БД Склад в формате INGRES. В
качестве узла C выступает mainframe IBM c операционной системой MVS и СУБД DB2. На нем
расположена локальная БД Инструмент в формате DB2.
Сервер распределенной БД - компонент СУБД Ingres - выполняется на узле B. Коммуникационные
серверы Ingres работают на всех трех узлах. Узлы A и B используют для взаимодействия протокол
TCP/IP, в то время как узлы B и C общаются в соответствии со стандартом SNA.
Локальные БД на всех трех узлах управляются абсолютно автономно. Распределенная БД
Производство содержит таблицы из всех трех локальных БД. Для доступа сервера распределенной
БД к БД Предприятия необходим шлюз из Ingres в Rdb, а для доступа к БД Инструмент - шлюз из
Ingres в DB2.
Шлюз из Ingres в DB2 позволяет манипулировать данными в формате DB2 так, как будто они данные в формате Ingres. Шлюз из Ingres в Rdb позволяет оперировать с данными в формате Rdb
так, как будто они - данные в формате Ingres.
2. Процессы Oracle.
ПРОЦЕСС - это "канал управления", механизм в операционной системе, который исполняет
последовательность шагов. Некоторые операционные системы используют термины ЗАДАНИЕ
или ЗАДАЧА.
Процесс обычно имеет собственную область личной памяти, в которой он
работает.
СУБД ORACLE имеет два общих типа процессов: пользовательские процессы и процессы
ORACLE.
Пользовательские процессы (клиенты)
ПОЛЬЗОВАТЕЛЬСКИЙ ПРОЦЕСС создается и поддерживается для исполнения
программного кода прикладной программы (такой как
программа Pro*C) или инструмента
ORACLE (такого как SQL*DBA).
Пользовательский процесс также управляет взаимодействием с процессами сервера. Это
взаимодействие осуществляется через
программный интерфейс.
Процессы ORACLE
ПРОЦЕССЫ ORACLE вызываются другими процессами для того, чтобы выполнять
функции от имени вызывающего процесса. Ниже обсуждаются различные типы процессов
ORACLE и их специфические функции.
Процессы сервера
ORACLE создает ПРОЦЕССЫ СЕРВЕРА, чтобы обрабатывать запросы от присоединенных
пользовательских процессов. Процесс сервера
отвечает за связь с пользовательским
процессом и за
взаимодействие с ORACLE для выполнения запросов ассоциированного
пользовательского процесса. Например, если пользователь
запрашивает данные, которых
еще нет в буферах базы данных в SGA,
то ассоциированный процесс сервера считывает
соответствующие
блоки данных из файлов данных в SGA.
ORACLE можно конфигурировать на различное число пользовательских процессов на один
процесс сервера. В КОНФИГУРАЦИИ ВЫДЕЛЕННОГО СЕРВЕРА каждый процесс сервера
обрабатывет запросы для одного пользовательского процесса. КОНФИГУРАЦИЯ
МНОГОКАНАЛЬНОГО СЕРВЕРА позволяет многим пользовательским процессам совместно
использовать небольшое число процессов сервера, минимизируя количество процессов сервера и
максимизируя утилизацию доступных системных ресурсов.
В некоторых системах пользовательский и серверный процессы разделены, тогда как в
других системах они объединены в единый процесс. Если система конфигурирована на
многоканальный сервер, или если пользовательские и серверные процессы работают на разных
машинах, то пользовательский процесс и процесс сервера
должны быть раздельными.
Фоновые процессы
ORACLE создает множество ФОНОВЫХ ПРОЦЕССОВ для каждой инстанции. В фоновых
процессах сосредоточены те функции, которые иначе пришлось бы выполнять множеством
программ ORACLE, запускаемых
для каждого пользовательского процесса. Фоновые процессы
асинхронно выполняют операции ввода-вывода и отслеживают другие
процессы ORACLE,
обеспечивая лучший параллелизм и улучшая
производительность и надежность.
Область SGA и фоновые процессы ORACLE в совокупности составляют инстанцию ORACLE.
Каждая инстанция ORACLE может использовать несколько фоновых процессов. Эти
процессы имеют следующие имена: DBWR, LGWR, CKPT, SMON, PMON, ARCH, RECO, Dnnn
и LCKn. Каждый из этих
фоновых процессов описан ниже.
Писатель базы данных (DBWR)
ПИСАТЕЛЬ БАЗЫ ДАННЫХ записывает модифицированные блоки из буферного кэша
базы данных в файлы данных. Благодаря способу, которым ORACLE осуществляет
журнализацию, процессу DBWR не требуется записывать эти блоки при завершении транзакции.
Вместо этого DBWR оптимизирован так, чтобы минимизировать обращения к диску. В общем
случае, DBWR выполняет запись лишь тогда, когда в SGA требуется прочитать очередную
порцию данных, а в буферном кэше недостает свободных буферов. Первыми записываются те
данные, к которым было самое давнее обращение.
Писатель журнала (LGWR)
ПИСАТЕЛЬ ЖУРНАЛА записывает на диск записи журнала повторения. Эти записи
генерируются в буфере журнала повторения в SGA. Когда транзакция завершается и буфер
журнала заполняется, LGWR переписывает записи журнала повторения в файл журнала
повторения.
Контрольная точка (CKPT)
В специфические моменты времени все модифицированные буфера в SGA записываются
процессом DBWR в файлы данных; это событие
называется контрольной точкой. Процесс
КОНТРОЛЬНОЙ ТОЧКИ отвечает за своевременную сигнализацию процессу DBWR о
контрольных точках и обновление всех файлов данных и управляющих
файлов базы данных, чтобы отразить последнюю контрольную точку.
Процесс CKPT не обязателен; если он отсутствует, его функции берет на себя процесс LGWR.
Монитор системы (SMON)
МОНИТОР СИСТЕМЫ осуществляет восстановление инстанции во время запуска инстанции.
В системе с несколькими инстанциями (при использовании Параллельного сервера), процесс
SMON одной инстанции может также осуществлять восстановление других
сбившихся инстанций. SMON также очищает временные сегменты, которые больше не
используются, и восстанавливает мертвые транзакции, пропущенные после сбоя и восстановления
инстанции в результате сбоев файлов или офлайновых ошибок. Процесс SMON в
конечном счете восстанавливает такие транзакции, когда табличное
пространство или файл переводится в онлайн. SMON также сжимает
свободные экстенты в базе данных, чтобы сделать свободное
пространство непрерывным и более доступным для распределения.
Монитор процессов (PMON)
МОНИТОР ПРОЦЕССОВ осуществляет восстановление процесса после сбоя
пользовательского процесса. PMON отвечает за очистку кэша и освобождение ресурсов,
использовавшихся процессом. PMON также контролирует диспетчерские (см. ниже) и серверные
процессы, и рестартует их, если они сбиваются.
Архиватор (ARCH)
АРХИВАТОР копирует онлайновые файлы журнала повторения в архивную память, когда
они переполняются. ARCH активен лишь тогда, когда журнал повторения используется в режиме
ARCHIVELOG.
Восстановитель (RECO)
ВОССТАНОВИТЕЛЬ используется для разрешения распределенных транзакций, зависших
в результате сетевого или системного сбоя в распределенной базе данных. В моменты,
определяемые таймером, локальный RECO пытается соединиться с удаленными базами данных и
автоматически подтвердить или отменить локальную порцию каждой висящей распределенной
транзакции.
Диспетчер (Dnnn)
ДИСПЕТЧЕРЫ - это необязательные фоновые процессы, существующие лишь в
конфигурации многоканального сервера. По меньшей мере один диспетчерский процесс создается
для каждого используемого коммуникационного протокола (D000, ..., Dnnn). Каждый
диспетчерский процесс отвечает за маршрутизацию запросов от присоединенных
пользовательских процессов к доступным разделяемым серверным процессам, и за
возвращение ответов обратно в ассоциированные пользовательские процессы.
Блокировка (LCKn)
До десяти процессов БЛОКИРОВКИ (LCK0, ..., LCK9) используются для межинстанционных
блокировок в среде Параллельного сервера ORACLE.
Все эти детали не видны конечному пользователю. Он работает с БД Производство так, как будто
это централизованная БД Ingres. Это и есть полностью прозрачный доступ к данным.
Отметим, что технология распределенных БД защищает инвестиции в программное обеспечение.
Она может рассматриваться как "мост", перекинутый от mainframe-систем и нереляционных СУБД к
современным профессиональным СУБД на платформе RISC-компьютеров. Она позволяет
разрабатывать для них прикладные программы, обеспечивая им доступ к огромным массивам
информации на больших ЭВМ и тем самым гарантирует мягкий и безболезненный переход к новой
платформе.
Билет №10
1. Технология тиражирования данных.
Принципиальное отличие технологии тиражирования данных от технологии распределенных баз
данных (которую часто для краткости называют технологией STAR) заключается в отказе от
распределенных данных. Ее суть состоит в том, что любая БД (как для СУБД, так и для работающих
с ней пользователей) всегда является локальной; данные всегда размещаются локально на том узле
сети, где они обрабатываются; все транзакции в системе завершаются локально.
Тиражирование данных - это асинхронный перенос изменений объектов исходной базы данных
(source database) в БД, принадлежащим различным узлам распределенной системы. Функции
тиражирования данных выполняет специальный модуль СУБД - сервер тиражирования данных,
называемый репликатором (replicator). Его задача - поддержка идентичности данных в
принимающих базах данных (target database) данным в исходной БД. Сигналом для запуска
репликатора служит срабатывание правила (см. Раздел 2), перехватывающего любые изменения
тиражируемого объекта БД. Возможно и программное управление репликатором посредством
сигнализаторов о событиях в базе данных.
В качестве базиса для тиражирования выступает транзакция к БД. В то же время возможен перенос
изменений группами транзакций, периодически или в некоторый момент времени, что дает
возможность исследовать состояние принимающей БД на определенный момент времени. Детали
тиражирования данных полностью скрыты от прикладной программы; ее функционирование никак
не зависит от работы репликатора, который целиком находится в ведении администратора БД.
Следовательно, для переноса программы в распределенную среду с тиражируемыми данными не
требуется ее модификации.
Технология распределенных БД и технология тиражирования данных - в определенном смысле
антиподы. Краеугольный камень первой - синхронное завершение транзакций одновременно на
нескольких узлах распределенной системы, то есть синхронная фиксация изменений в
распределенной БД. "Ахиллесова пята" технологии STAR - жесткие требования к
производительности и надежности каналов связи. Если БД распределена по нескольким
территориально удаленным узлам, объединенным медленными и ненадежными каналами связи, а
число одновременно работающих пользователей составляет десятки и выше, то вероятность того,
что распределенная транзакция будет зафиксирована в обозримом временном интервале, становится
чрезвычайно малой. В таких условиях (характерных, кстати, для большинства отечественных
организаций) обработка распределенных данных практически невозможна.
Реальной альтернативой технологии STAR становится технология тиражирования данных, не
требующая синхронной фиксации изменений (и в этом ее сильная сторона). В действительности
далеко не во всех задачах требуется обеспечение идентичности БД на различных узлах в любое
время. Достаточно поддерживать тождественность данных лишь в определенные критичные
моменты времени. Следовательно, можно накапливать изменения в данных в виде транзакций в
одном узле и периодически копировать эти изменения на другие узлы.
Просуммируем очевидные преимущества технологии тиражирования данных. Во-первых, данные
всегда расположены там, где они обрабатываются - следовательно, скорость доступа к ним
существенно увеличивается. Во-вторых, передача только операций, изменяющих данные (а не всех
операций доступа к удаленным данным, как в технологии STAR), и к тому же в асинхронном
режиме, позволяет значительно уменьшить трафик. В-третьих, со стороны исходной БД для
принимающих БД репликатор выступает как процесс, инициированный одним пользователем, в то
время как в физически распределенной среде с каждым локальным сервером работают все
пользователи распределенной системы, конкурирующие за ресурсы друг с другом. Наконец, вчетвертых, никакой продолжительный сбой связи не в состоянии нарушить передачу изменений.
Дело в том, что тиражирование предполагает буферизацию потока изменений (транзакций); после
восстановления связи передача возобновляется с той транзакции, на которой тиражирование было
прервано.
Технология тиражирования данных не лишена некоторых недостатков, вытекающих из ее
специфики. Например, невозможно полностью исключить конфликты между двумя версиями одной
и той же записи. Он может возникнуть, когда вследствие все той же асинхронности два пользователя
на разных узлах исправят одну и ту же запись в тот момент, пока изменения в данных из первой
базы данных еще не были перенесены во вторую. Следовательно, при проектировании
распределенной среды с использованием технологии тиражирования данных необходимо
предусмотреть конфликтные ситуации и запрограммировать репликатор на какой-либо вариант их
разрешения.
Завершая обсуждение, отметим, что тиражирование данных - это не очередной технологический
изыск и не прихоть разработчиков СУБД. Жизненность концепции тиражирования подтверждается
опытом ее использования в области, предъявляющей повышенные требования к надежности - в
сфере банковских информационных систем.
2. Программный интерфейс и инстанция Oracle.
ПРОГРАММНЫЙ ИНТЕРФЕЙС - это механизм, посредством которого пользовательский
процесс общается с процессом сервера. Он выступает как метод стандартной коммуникации
между любым инструментом или приложением клиента (таким как SQL*Forms) и программным
обеспечением ORACLE. Программный интерфейс должен:
* действовать как механизм коммуникации, форматируя запросы
на данные,
передавая данные, перехватывая и возвращая
ошибки
* выполнять преобразование и трансляцию данных, в
частности, между
разными типами компьютеров, или во
внешние типы данных программы
пользователя
Коммуникационное программное обеспечение и SQL*Net
Если пользовательский и серверный процессы находятся на разных компьютерах в сети,
или если пользовательские процессы присоединяются к разделяемым серверным процессам
через диспетчерские процессы, то программный интерфейс включает физическое сетевое
соединение, программное обеспечение коммуникации и SQL*Net. SQL*Net - это интерфейс
ORACLE к
стандартным коммуникационным протоколам, обеспечивающий должную
передачу данных между компьютерами. (См. "SQL*Net" на странице
Инстанция ORACLE
Каждый раз, когда запускается база данных, распределяется область SGA и запускаются
фоновые процессы ORACLE. Комбинация этих процессов и буферов памяти называется
ИНСТАНЦИЕЙ ORACLE.
Рис.иллюстрирует многопроцессную инстанцию ORACLE.
Инстанция ORACLE
Пользовательские
процессы
Процессы
ORACLE
(фоновые)
┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐
│ User │ │ User │ │ User │ │ User │ ...
└──┬───┘ └──┬───┘ └──┬───┘ └──┬───┘
│
│
│
│
┌───────────┴─────────┴─────────┴─────────┴──────────────┐
│
│
│
Глобальная область системы (SGA)
│
│
│
└──┬─────────┬─────────┬─────────┬─────────┬─────────┬───┘
│
│
│
│
│
│
┌──┴───┐ ┌──┴───┐ ┌──┴───┐ ┌──┴───┐ ┌──┴───┐ ┌──┴───┐
│ RECO │ │ PMON │ │ SMON │ │ DBWR │ │ LGWR │ │ ARCH │
└──────┘ └──────┘ └──────┘ └──────┘ └──────┘ └──────┘
Параллельный сервер ORACLE: системы с несколькими инстанциями
Некоторые архитектуры оборудования (например, слабосвязанные процессоры) позволяют
нескольким компьютерам разделять доступ к данным, программному обеспечению или
периферийным устройствам.
ORACLE с опцией Параллельного сервера использует преимущества такой архитектуры,
выполняя несколько инстанций, которые "разделяют" единую физическую базу данных. В
соответствующих приложениях, Параллельный сервер ORACLE предоставляет доступ к одной
базе данных пользователей на разных машинах, обеспечивая увеличенную производительность.
Пример работы ORACLE
Следующее описание иллюстрирует работу конфигурации ORACLE, при которой
пользователь и ассоциированный с ним процесс сервера находятся на разных машинах,
соединенных через сеть.
1. Инстанция работает на том компьютере, на котором выполняется ORACLE (часто
называемом ХОСТОМ или СЕРВЕРОМ БАЗЫ ДАННЫХ).
2. Компьютер, используемый для приложений (ЛОКАЛЬНАЯ МАШИНА или РАБОЧАЯ
СТАНЦИЯ КЛИЕНТА) выполняет приложение в рамках пользовательского процесса.
Приложение-клиент пытается установить соединение с сервером, используя подходящий
драйвер SQL*Net.
3. Сервер также выполняет соответствующий драйвер SQL*Net. Сервер обнаруживает
запрос на соединение от приложения и
создает (выделенный) процесс сервера от имени пользовательского процесса.
4. Пользователь выполняет предложение SQL и подтверждает свою транзакцию. Например,
пользователь изменяет данные в строке таблицы.
5. Процесс сервера принимает это предложение и проверяет разделяемый пул, чтобы
отыскать в нем разделяемую область SQL, содержащую идентичное предложение SQL. Если
такая разделяемая область SQL найдена, процесс сервера проверяет пользовательские привилегии
доступа к запрашиваемым данным и использует существующую разделяемую область SQL для
обработки предложения; если нет, то для предложения распределяется новая разделяемая
область SQL, в которой осуществляется разбор и исполнение предложения.
6. Процесс сервера извлекает все необходимые значения данных из файла данных (таблицы)
или получает их из SGA.
7. Процесс сервера модифицирует данные в SGA. Процесс DBWR
записывает модифицированные данные на диск для постоянного хранения, если сочтет это
необходимым. Поскольку транзакция подтверждена, процесс LGWR немедленно регистрирует
транзакцию в онлайновом файле журнала повторения.
8. Если транзакция успешна, процесс сервера посылает сообщение через сеть приложению.
В противном случае передается соответствующее сообщение об ошибке.
9. Во время всей описанной процедуры работают другие фоновые процессы, наблюдая за
условиями, которые могут потребовать вмешательства. Кроме того, сервер базы данных
управляет транзакциями других пользователей и предотвращает соперничество между
транзакциями, запрашивающими одни и те же данные.
Эти шаги описывают лишь самый основной уровень операций, которые осуществляет
ORACLE.
Билет №11
1. Эволюция серверов баз данных.
В период создания первых СУБД технология "клиент-сервер" только зарождалась. Поэтому
изначально в архитектуре систем не было адекватного механизма организации взаимодействия
такого типа, в современных же системах он жизненно необходим.
Чтобы понять суть проблемы, рассмотрим эволюцию серверов баз данных. Первое время
доминировала модель, когда управление данными (функция Сервера) и взаимодействие с
пользователем были совмещены в одной программе (рис.6a). Затем функции управления данными
были выделены в самостоятельную группу - сервер, однако модель взаимодействия пользователя с
сервером соответствовала парадигме "один-к-одному" (рис.6б), то есть сервер обслуживал запросы
ровно одного пользователя (клиента), и для обслуживания нескольких клиентов нужно было
запустить эквивалентное число серверов. Выделение сервера в отдельную программу революционный шаг, позволяющий, в частности, поместить сервер на одну машину, а программный
интерфейс с пользователем - на другую, осуществляя взаимодействие между ними по сети (рис.7).
Однако необходимость запуска большого числа серверов для обслуживания множества
пользователей сильно ограничивала возможности такой системы.
Рисунок 6.
Централизованная архитектура (а) и архитектура "один к одному" (б).
Рисунок 7.
Размещение клиента и сервера на различных машинах.
Рисунок 8.
Многопотоковая архитектура.
Проблемы, возникающие в модели "один-к-одному", решаются в архитектуре систем с выделенным
сервером, способным обрабатывать запросы от многих клиентов. Сервер единственный обладает
монополией на управление данными и взаимодействует одновременно со многими клиентами
(рис.8). Логически каждый клиент связан с сервером отдельной нитью (thread) или потоком, по
которому пересылаются запросы. Такая архитектура получила название многопотоковой (multithreaded).
Она позволяет значительно уменьшить нагрузку на операционную систему, возникающую при
работе большого числа пользователей (trashing). С другой стороны, возможность взаимодействия с
одним сервером многих клиентов позволяет в полной степени использовать разделяемые объекты
(начиная с открытых файлов и кончая данными из системных каталогов), что значительно
уменьшает потребности в памяти и общее число процессов операционной системы. Например,
системой с архитектурой "один-к-одному" будет создано 50 копий процессов СУБД для 50
пользователей, тогда как системе с многопотоковой архитектурой для этого понадобится только
один сервер.
Однако такое решение привносит новую проблему. Так как сервер может выполняться только на
одном процессоре, возникает естественное ограничение на применение СУБД для
мультипроцессорных платформ. Если компьютер имеет, например, четыре процессора, то СУБД с
одним сервером используют только один из них, не загружая оставшиеся три.
В некоторых системах эта проблема решается заменой выделенного сервера на диспетчер или
виртуальный сервер (virtual server) (рис.9), который теряет право монопольно распоряжаться
данными, выполняя только функции диспетчеризации запросов к актуальным серверам. Таким
образом, в архитектуру системы добавляется новый слой, который размещается между клиентом и
сервером, что увеличивает трату ресурсов на поддержку баланса загрузки (load balancing) и
ограничивает возможности управления взаимодействием "клиент-сервер". Во-первых, становиться
невозможным направить запрос от конкретного клиента конкретному серверу, во-вторых, серверы
становятся равноправными - нет возможности устанавливать приоритеты для обслуживания
запросов.
Рисунок 9.
Архитектура с виртуальным сервером.
Подобная организация взаимодействия "клиент-сервер" является аналогом банка, где имеется
несколько окон кассиров, и банковский служащий (диспетчер), направляет каждого вновь
пришедшего посетителя (клиента) к свободному кассиру (актуальному серверу). Система работает
нормально, пока все посетители равноправны (имеют равные приоритеты), однако, стоит лишь
появиться посетителям с высшим приоритетом (которые должны обслуживаться в специальном
окне), как возникают проблемы. Учет приоритета клиентов особенно важен в системах оперативной
обработки транзакций, однако именно эту возможность не может предоставить архитектура систем с
диспетчеризацией.
Рисунок 10.
Многопотоковая мультисерверная архитектура.
Современное решение проблемы СУБД для мультипроцессорных платформ заключается в
возможности запуска нескольких серверов базы данных, в том числе и на различных процессорах.
При этом каждый из серверов должен быть многопотоковым. Если эти два условия выполнены, то
есть основание говорить о многопотоковой архитектуре с несколькими серверами (multithreaded, multi-server architecture), представленной на рис.10.
2. Пример работы конфигурации Oracle.
билет 10 вопрос 2 - в конце?Билет №12
Активный сервер
Действительно профессиональные СУБД обладают мощным активным сервером базы данных. Это
не просто технические новшество. Идея активного сервера коренным образом изменяет
представление о роли, масштабах и принципах использования СУБД, а в чисто практическом плане
позволяет выбрать современные, эффективные методы построения глобальных информационных
систем.
Идея активного интеллектуального сервера БД возникла не сама по себе - она стала ответом на
задачи реальной жизни. В Разделе 1 было сформулировано общее представление о базе данных.
Однако вдумчивый читатель может его расширить. Действительно, объекты реального мира,
помимо непосредственных, прямых связей, имеют друг с другом более сложные причинноследственные связи; они динамичны, находятся в постоянном изменении. Эти связи и процессы
должны каким-то образом отражаться и в базе данных, если мы имеем в виду не статичное
хранилище данных, а информационную модель маленькой части реального мира. Иными словами, в
базе данных, помимо собственно данных и непосредственных связей между ними, должны хранится
знания о данных, а сама база должна адекватно отражать процессы, происходящие в реальном мире.
Значит, необходимо иметь средства хранения и управления такой информацией.
Актуальные задачи
Указанные требования выливаются в решение следующих задач.
Во-первых, необходимо, чтобы база данных в любой момент правильно отражала состояние
предметной области - данные должны быть взаимно непротиворечивыми. Пусть, например, база
данных Кадры хранит сведения о рядовых сотрудниках, отделах, в которых они работают, и их
руководителях. Нужно учесть следующие правила: каждый сотрудник должен быть подчинен
реальному руководителю; если руководитель уволился, то все его сотрудники переходят в
подчинение другому, а отдел реорганизуется; во главе каждого отдела должен стоять реальный
руководитель; если отдел сокращен, то его руководитель переводится в резерв на выдвижение и т.д.
Во-вторых, база данных должна отражать некоторые правила предметной области, законы, по
которым она функционирует (business rule). Завод может нормально работать, только в том случае,
если на складе имеется достаточный запас деталей определенной номенклатуры. Следовательно, как
только количество деталей некоторого типа станет меньше минимально допустимого, завод должен
докупить эти детали в нужном количестве.
В-третьих, необходим постоянный контроль за состоянием базы данных, отслеживание всех
изменений, и адекватная реакция на них. Например, в автоматизированной системе управления
производством датчики контролируют температуру инструмента; она периодически передается в
базу данных и там сохраняется; как только температура инструмента превышает максимально
возможное значение, он отключается.
В-четвертых, необходимо, чтобы возникновение некоторой ситуации в базе данных четко и
оперативно влияло на ход выполнения прикладной программы. Многие программы требуют
оперативного оповещения о всех происходящих в базе данных изменениях. Так, в системах
автоматизированного управления производством необходимо моментально уведомлять программы о
любых изменениях параметров технологических процессов, когда последние хранятся в базе
данных. Почтовая служба требует оперативного уведомления получателя, как только получено
новое сообщение. Брокер на бирже СУБД должен немедленно получать сообщение об изменении
цены акций, поскольку промедление в несколько секунд грозит большими потерями.
Оповещение о возникновении определенного состояния базы данных и изменениях в ней может
потребоваться в любом учреждении для контроля прохождения документов. Если документ,
который должен быть просмотрен и последовательно завизирован несколькими руководителями,
хранится в базе данных, то каждый из них в свою очередь будет оперативно уведомлен о
поступлении документа ему на подпись.
Важная проблема СУБД - контроль типов данных. В Разделе 1 уже говорилось о том, что в базе
данных каждый столбец в любой таблице содержит данные некоторых типов. Тип данных
определяется при создании таблицы. Каждому столбцу присваивается один из стандартных типов
данных, разрешенных в СУБД. Стало быть, в базе данных можно хранить только данные
стандартных типов - числа, целые и вещественные, строки символов, данные типа "дата", "время" и
"денежная единица" - репертуар реальной СУБД ограничен именно этими типами данных. Как же
быть с нестандартными данными? Ведь в реальной жизни требуется хранить и обрабатывать данные
в значительно более широком диапазоне - плоскостные и пространственные координаты, единицы
различных метрик, пятидневные недели (рабочая неделя, в которой сразу после пятницы следует
понедельник), дроби, не говоря уже о графических изображениях.
Традиционные подходы
До недавнего времени функции управления знаниями оставались за границами возможностей
реляционных СУБД или были очень ограниченны.
Знания о предметной области традиционно включались непосредственно в прикладные программы,
для чего использовались возможности процедурных языков программирования. Этот подход в
подавляющем большинстве случаев преобладает и сейчас.
Рассмотрим, например, базу данных Склад, хранящую информацию о наличии деталей на
заводском складе. Прикладная программа Складской Учет обеспечивает учет имеющихся и вновь
поступающих деталей. В ее функции входит просмотр содержимого базы данных, добавление
информации о новых деталях, замена снятых с производства деталей на новые и т.д. В программе
реализованы некоторые правила, например "В любой момент времени количество деталей типа
"втулка" не должно быть меньше 1000" (ситуация со втулками на производстве всегда
напряженная). Нетрудно понять, что оно должно применяться только в том случае, когда количество
втулок уменьшается. Значит, нужно проверить: а не уменьшилось ли оно настолько, что стало
меньше 1000. Если это произошло, то нужно срочно направить на завод-изготовитель письмо с
просьбой отгрузить нужное количество втулок, если, конечно, такое письмо не было направлено до
этого.
А чтобы это правило применялось, программа должна периодически, через определенные интервалы
времени опрашивать значение в столбце Количество таблицы Деталь для всех строк, которые
удовлетворяют условию Деталь. Название ="Втулка". Если это значение становится меньше 1000,
программа должна послать письмо на завод-изготовитель.
Фрагмент программы указан в Примере 1.
...
SELECT Количество, Номер_поставщика
FROM Деталь
WHERE Название = "Втулка";
IF (Количество < 1000)
THEN
BEGIN
SELECT Адрес_поставщика
FROM Поставщик
WHERE Номер = Номер_поставщика;
Послать письмо(Адрес_поставщика, 1000-Количество);
END
ELSE Ничего не делать
...
{ ...
ВЫБРАТЬ Количество, Номер_поставщика
ИЗ Деталь
ГДЕ Название = "Втулка";
ЕСЛИ (Количество < 1000) ТО
НАЧАТЬ
ВЫБРАТЬ Адрес_поставщика
ИЗ Поставщик
ГДЕ Номер = Номер_поставщика;
Послать письмо(Адрес_поставщика, 1000-Количество);
ЗАКОНЧИТЬ
ИНАЧЕ Ничего не делать
... }
Пример 1.
В чем недостатки такого подхода?
Во-первых, реализация правил перегружает прикладную программу и усложняет ее написание и
понимание. Во-вторых, и это более существенный недостаток, когда изменяется само правило,
изменения должны быть отражены в тексте программы. Когда же правила изменяются
кардинальным образом, разработчику приходится пересматривать логику выполнения программы и
практически переписывать ее заново.
Удобнее оставить за прикладными программами только базовые алгоритмы управления данными, а
часто меняющиеся правила, которые действуют во внешнем мире, вынести за рамки программ и
оформить как-то иначе. В противном случае разработчиков ждут неприятные сюрпризы.
Рассмотрим для примера прикладную банковскую систему. При ее создании разработчики в
алгоритмах управления данными учли те правила финансовой деятельности, которые диктовались
действующим законодательством. Предположим теперь, что законы претерпели некоторые
изменения (что в наше время происходит слишком часто!). Естественно, эти изменения должны
быть немедленно отражены и в алгоритмах управления данными, что повлечет за собой
необходимость модификации всех прикладных программ, составляющих информационную систему.
Это огромная работа - нужно исправить и отладить программы, откомпилировать и собрать их,
внести изменения в документацию и переобучить персонал.
С другой стороны, правила, о которых идет речь, не должны противоречить друг другу. Когда их
реализует группа разработчиков, нет никаких гарантий взаимной непротиворечивости правил.
Фактически правила должен формулировать и контролировать один человек - администратор базы
данных. При традиционном подходе практически невозможно обеспечить централизованный
контроль за взаимным соответствием правил, если они разбросаны по многим программам, и, что
более важно для коммерческих организаций, практически невозможно проконтролировать
преднамеренное искажение правил программистами.
Таким образом, включение правил в прикладные программы, когда серверу отводится пассивная
роль поставщика и хранителя данных, а вся интеллектуальная часть реализуется в программе,
представляет собой устаревшую технологию. Она чревата большими накладными расходами при
изменении правил и не обеспечивает централизованного контроля за их непротиворечивостью.
Ясно, что эта технология имеет в своей основе столь популярную ныне RDA-модель (о ней речь
шла выше).
Традиционное решение задач контроля за состоянием базы данных и уведомления прикладных
программ о всех происходящих в ней событиях опирается на механизмы опроса (polling)
прикладными программами базы данных, которому присущи следующие недостатки.
Прикладная программа не может непрерывно опрашивать базу данных, так как это приведет к
перегрузке сервера бесполезными запросами. Опрос производится через интервалы времени,
которые определяет программист. Следовательно, если в базе данных происходят какие-либо
изменения, то они выявляются не сразу, а через какое-то время. Именно поэтому традиционное
решение не обеспечивает оперативного оповещения, в прикладных же программах, работающих в
реальном времени (см. примеры выше), это требование является ключевым. Постоянный опрос
базы данных сильно сказывается на производительности системы - программы, опрашивающие базу
данных, перегружают своими запросами сервер и сеть. Громоздкие конструкции в тексте программ,
реализующие опрос, серьезно затрудняют ее написание и понимание.
Другое важное требование реальной жизни - синхронизация работы нескольких программ,
обращающихся к базе данных. Рассмотрим пример. Финансовая система завода должна отслеживать
поступление платежей за продукцию на некоторый счет. Как только деньги поступили (все знают,
насколько это важное событие - "пришли деньги!"), все прикладные программы, включенные в
финансовую систему, должны быть оповещены об этом. После этого каждая из них может
предпринять некоторые действия. Так, программа Отгрузка Продукции должна найти в базе
данных соответствующий заказ, определить номенклатуру заказанной продукции, ее количество,
сроки поставки, сформировать и послать на склад готовой продукции заказ на отгрузку, распечатать
сопроводительные документы - иными словами подготовить продукцию к отправке. Программа
Бухгалтерия, в частности, должна по дате поступления денег определить, просрочен ли платеж, и,
если это так, начислить штраф. Все эти действия активизируются событием в базе данных поступлением денег на счет (в терминах реляционной СУБД это означает добавление новой строки в
таблицу Платежи). Работа всех программ синхронизируется этим событием.
Традиционное решение проблемы синхронизации программ обеспечивается стандартными
средствами многозадачной операционной системы. Однако такая синхронизация может быть
связана с изменениями, происходящими в базе данных, только посредством постоянного опроса
таблицы Платежи. Недостатки такого подхода очевидны - в нем взаимосвязь программ
обеспечивается на уровне операционной системы, тогда как эту функцию, безусловно, должна
выполнять СУБД. Кроме того, приходится привлекать программы опроса, недостатки которого мы
уже обсуждали.
Общепринятый способ преодоления ограничения на типы данных в СУБД - приведение данных
новых типов к стандартным. Как правило, данные новых типов рассматриваются как целые или
вещественные числа, или как строки символов.
Рассмотрим пример. В ряде стран, в том числе и в США, для измерения длины наряду с
привычными мерами метрической системоы используются также футы и дюймы. Правила
выполнения арифметических операций в этой системе отличны от десятичной. Так, три фута
одиннадцать дюймов плюс один дюйм равно четырем футам ( 3"11" + 1" = 4"). Стандартный набор
типов данных не позволяет определить данные в этой системе и оперировать с ними. Они должны
быть преобразованы в вещественные числа с плавающей точкой, то есть представлены
соответственно, как 3.91666 (три фута одиннадцать дюймов) и 0.08333 (один дюйм). Выполнив
операцию сложения (3.91666+0.08333=3.99999), мы убедимся, что такое представление приводит к
потере точности (ведь результат должен быть равен четырем!).
Следовательно, прямое приведение новых типов данных к стандартным чревато ошибками необходимо их преобразование в данные стандартных типов. Функции преобразования данных
должны взять на себя прикладные программы (больше некому). В результате получается довольно
громоздкая схема. Программа извлекает из базы данных данные новых типов, представленные как
стандартные, преобразует и обрабатывает их, затем вновь преобразует и передает серверу для
хранения. Сервер в обработке данных новых типов при такой схеме участия не принимает - ведь он
рассматривает их как стандартные и будет обрабатывать как стандартные (и тогда возникнут
ошибки!).
Сегодня, например, для отечественных банков актуальна проблема больших чисел. Масштаб
расчетов настолько возрос, что в некоторых итоговых операциях фигурируют суммы, которые
превосходят разрядную сетку для целых чисел. Поэтому в программах приходится преобразовывать
целые числа в строки и наоборот, что не упрощает их логику. Хранение и обработка больших целых
как вещественных приводит к потере точности, что в финансовой системе недопустимо.
Далее мы увидим, что решение проблемы заключается в определении нового типа данных "большие
целые". Как только это сделано, сервер базы данных начинает "понимать" новый тип данных и
выполнять над ним все операции, ха2.3. Активный сервер
Действительно профессиональные СУБД обладают мощным активным сервером базы данных. Это
не просто технические новшество. Идея активного сервера коренным образом изменяет
представление о роли, масштабах и принципах использования СУБД, а в чисто практическом плане
позволяет выбрать современные, эффективные методы построения глобальных информационных
систем.
Идея активного интеллектуального сервера БД возникла не сама по себе - она стала ответом на
задачи реальной жизни. В Разделе 1 было сформулировано общее представление о базе данных.
Однако вдумчивый читатель может его расширить. Действительно, объекты реального мира,
помимо непосредственных, прямых связей, имеют друг с другом более сложные причинноследственные связи; они динамичны, находятся в постоянном изменении. Эти связи и процессы
должны каким-то образом отражаться и в базе данных, если мы имеем в виду не статичное
хранилище данных, а информационную модель маленькой части реального мира. Иными словами, в
базе данных, помимо собственно данных и непосредственных связей между ними, должны хранится
знания о данных, а сама база должна адекватно отражать процессы, происходящие в реальном мире.
Значит, необходимо иметь средства хранения и управления такой информацией.
Современные решения
Идеи, реализованные в СУБД третьего поколения (пока, к сожалению, не во всех), заключаются в
том, что знания выносятся за рамки прикладных программ и оформляются как объекты базы
данных. Функции применения знаний начинает выполнять непосредственно сервер базы данных.
Такая архитектура суть воплощение концепции активного сервера. Она опирается на четыре
"столпа":
процедуры базы данных
правила (триггеры)
события в базе данных
типы данных, определяемые пользователем
Процедуры базы данных
В различных СУБД они носят название хранимых (stored), присоединенных, разделяемых и т.д.
Ниже будем пользоваться терминологией, принятой в СУБД Ingres.
Использование процедур базы данных преследует четыре цели.
Во-первых, обеспечивается новый независимый уровень централизованного контроля доступа к
данным, осуществляемый администратором базы данных.
Во-вторых, одна процедура может использоваться несколькими прикладными программами - это
позволяет существенно сократить время написания программ за счет оформления их общих частей в
виде процедур базы данных. Процедура компилируется и помещается в базу данных, становясь
доступной для многократных вызовов. Так как план ее выполнения определяется единожды при
компиляции, то при последующих вызовах процедуры фаза оптимизации пропускается, что
существенно экономит вычислительные ресурсы системы.
В-третьих, использование процедур баз данных позволяет значительно снизить трафик сети в
системах с архитектурой "клиент-сервер". Прикладная программа, вызывающая процедуру, передает
серверу лишь ее имя и параметры. В процедуре, как правило, концентрируются повторяющиеся
фрагменты из нескольких прикладных программ (рис.11a). Если бы эти фрагменты остались частью
программы, они загружали бы сеть посылкой полных SQL-запросов (рис.11б).
Рисунок 11.
Увеличение производительности системы за счет использования процедур базы данных.
а. процедуры не используются;
б. выделение фрагмента прикладных программ в виде процедуры БД.
Наконец, в-четвертых, процедуры базы данных в сочетании с правилами, о которых речь пойдет
ниже, предоставляют администратору мощные средства поддержки целостности базы данных.
В современных СУБД процедура хранится непосредственно в базе данных и контролируется ее
администратором. Она имеет параметры и возвращает значение. Процедура базы данных создается
оператором CREATE PROCEDURE (СОЗДАТЬ ПРОЦЕДУРУ) и содержит определения
переменных, операторы SQL ( например, SELECT, INSERT), операторы проверки условий
(IF/THEN/ELSE) операторы цикла (FOR, WHILE), а также некоторые другие.
Например, необходимо разработать процедуру, которая переводила бы рядового сотрудника в
резерв на выдвижение на руководящую должность. Процедура Назначение перемещает строки из
таблицы Сотрудник, содержащей сведения о сотрудниках, в таблицу Резерв для всех сотрудников с
указанным номером. Номер сотрудника представляет собой целое число (тип integer), который не
может иметь пустое значение, является параметром процедуры и передается ей при вызове из
прикладной программы оператором EXECUTE PROCRDURE (ВЫПОЛНИТЬ ПРОЦЕДУРУ).
(Пример 2.)
CREATE PROCEDURE Назначение (Номер_сотрудника integer not nul) AS
BEGIN
INSERT INTO Резерв
SELECT *
FROM Сотрудник
WHERE Номер = Номер_сотрудника;
DELETE
FROM Сотрудник
WHERE Номер = Номер_сотрудника;
END
{ СОЗДАТЬ ПРОЦЕДУРУ Назначение (Номер_сотрудника целый не пустой) КАК
НАЧАТЬ
ВКЛЮЧИТЬ В Резерв
ВЫБРАТЬ ВСЕ
ИЗ Сотрудник
ГДЕ Номер = Номер_сотрудника;
УДАЛИТЬ ИЗ Сотрудник
ГДЕ Номер = Номер_сотрудника;
ЗАКОНЧИТЬ }
Пример 2.
Правила
Механизм правил (триггеров) позволяет программировать обработку ситуаций, возникающих при
любых изменениях в базе данных.
Правило придается таблице базы данных и применяется при выполнении над ней операций
включения, удаления или обновления строк, а также при изменении значений в столбцах таблицы.
Применение правила заключается в проверке сформулированных в нем условий, при выполнении
которых происходит вызов специфицированной внутри правила процедуры базы данных. Важно,
что правило может быть применено как до, так и после выполнения операции обновления,
следовательно, возможна отмена операции.
Таким образом, правило позволяет определить реакцию сервера на любое изменение состояния базы
данных. Правила (так же, как и процедуры) хранятся непосредственно в базе данных независимо от
прикладных программ.
Одна из целей механизма правил - отражение некоторых внешних правил деятельности
организации. Пусть, например, в базе данных Склад содержится таблица Деталь, хранящая
сведения о наличии деталей на складе завода. Одно из правил деятельности завода заключается в
том, что недопустима ситуация, когда на складе количество деталей любого типа становится
меньше, допустим, 1000.
Это требование описывается правилом Проверить_деталь. Оно применяется в случае обновления
столбца Количество таблицы Деталь: если новое значение в столбце меньше 1000, то выполняется
процедура Заказать_деталь. В качестве параметров ей передаются номер детали данного типа и
остаток (количкство деталей на складе). (Пример 3.)
CREATE RULE Проверить_деталь
AFTER UPDATE (Количество) OF Деталь
WHERE Деталь.Количество < 1000
EXECUTE PROCEDURE
Заказать_деталь (Номер детали = Деталь.Номер,
Остаток = Деталь.Количество);
{ СОЗДАТЬ ПРАВИЛО Проверить_деталь
ПОСЛЕ ОБНОВЛЕНИЯ (Количество) В Деталь
ГДЕ Деталь.Количество < 1000
ВЫПОЛНИТЬ ПРОЦЕДУРУ
Заказать_деталь (Номер детали=Деталь.Номер,
Остаток=Деталь.Количество);
}
Пример 3.
Таким образом, если возникает ситуация, когда на складе количество деталей какого-либо типа
становиться меньше требуемого, запускается процедура базы данных, которая заказывает
недостающее количество деталей этого типа. Заказ сводится к посылке письма (например, по
электронной почте) на завод или в цех, который изготавливает нужные детали. Процедура
проверяет, был ли ранее сделан заказ, если - нет, то посылает письмо. Все это происходит
автоматически, без вмешательства пользователя. Пример этот, разумеется, упрощенный - в нем не
учтено, что заказ мог быть сделан и раньше.
Важнейшая цель механизма правил - обеспечить целостность базы данных. Один из аспектов
целостности - целостность по ссылкам (referential integrity) - относится к связи двух таблиц между
собой. Напомним, что эта связь поддерживается внешними ключами.
Пусть, например, таблица Руководитель содержит сведения о начальниках, а таблица Сотрудник о сотрудниках некоторой организации (см. пример в 1.1.). Столбец Номер руководителя является
внешним ключом таблицы Сотрудник и является ссылкой этой таблицы к таблице Руководитель.
Для обеспечения целостности ссылок должны быть учтены два требования. Во-первых, если в
таблицу Сотрудник добавляется новая строка, значение столбца Номер_руководителя должно
быть взято из множества значений столбца Номер таблицы Руководитель (сотрудник может быть
подчинен только реальному руководителю). Во-вторых, при удалении любой строки из таблицы
Руководитель в таблице Сотрудник не должно остаться ни одной строки, в которой в столбце
Номер руководителя было бы значение, тождественное значению столбца Номер в удаляемой
строке (все сотрудники, если их руководитель уволился, должны перейти в подчинение другому).
Как учесть эти требования на практике? Очевидно, должны быть созданы правила, их реализующие.
Первое правило Добавить_сотрудника срабатывает при включении строки в таблицу Сотрудник;
его применение заключается в вызове процедуры Проверить_руководителей, проверяющей,
существует ли среди множества значений столбца Номер_руководителя значение, тождественное
значению поля Номер добавляемой строки. Если это не так, процедура должна ее отвергнуть.
Второе правило применяется при попытке удалить строку из таблицы Руководитель; оно состоит в
вызове процедуры, которая сравнивает значения в столбце Номер_руководителя таблицы
Сотрудник со значением поля Номер в удаляемой строке. В случае совпадения значения в столбце
Номер_руководителя обновляются (Пример 4.)
CREATE RULE Добавить_сотрудника
AFTER INSERT INTO Сотрудник
EXECUTE PROCEDURE Проверить_руководителя (Номер = Сотрудник.Номер);
{ СОЗДАТЬ ПРАВИЛО Добавить_сотрудника
ПОСЛЕ ВКЛЮЧЕНИЯ В Сотрудник
ВЫПОЛНИТЬ ПРОЦЕДУРУ Проверить_руководителя (Номер=Сотрудник.Номер)
}
Пример 4.
Механизм правил позволяет реализовать и более общие ограничения целостности. К примеру,
таблица Сотрудник содержит информацию о сотрудниках, в том числе имя и название отдела, в
котором они работают. Таблица Отдел хранит для каждого отдела число работающих в нем
сотрудников в столбце Количество сотрудников. Одно из ограничений целостности заключается в
том, что это число должно совпадать с количеством строк для данного отдела в таблице Сотрудник.
Как учесть это ограничение? Одно из возможных решений состоит в использовании правила
Добавить_сотрудника, которое применяется при включении строки в таблицу Сотрудник и
запускает процедуру Новый_сотрудник. Она, в свою очередь, обновляет значение столбца
Номер_сотрудника, увеличивая его на единицу. Параметр процедуры - название отдела. (Пример
5.)
CREATE RULE
AFTER INSERT INTO Сотрудник
EXECUTE PROCEDURE Новый_сотрудник (Отдел = Сотрудник.Отдел);
{ СОЗДАТЬ ПРАВИЛО Включить_сотрудника
ПОСЛЕ ВКЛЮЧЕНИЯ В Сотрудник
ВЫПОЛНИТЬ ПРОЦЕДУРУ Новый_сотрудник (Отдел = Сотрудник.Отдел)
}
Пример 5.
Разумеется, на практике при помощи механизма правил реализуются более сложные и изощренные
ограничения целостности.
Механизм правил - сердце активного сервера базы данных. Аналогом правил послужили триггеры
(triggers), которые впервые появились в СУБД Sybase (насколько известно автору) и впоследствии
были реализованы в том или ином виде и под тем или иным названием в большинстве
многопользовательских СУБД.
События в базе данных
Механизм событий в базе данных (database events) позволяет прикладным программам и серверу
базы данных уведомлять другие программы о наступлении в базе данных определенного события и
тем самым синхронизировать их работу. Операторы языка SQL, обеспечивающие уведомление,
часто называют сигнализаторами событий в базе данных (database event alerters). Функции
управления событиями целиком ложатся на сервер базы данных.
Рисунок 12.
События в базе данных.
Рис.12 иллюстрирует один из примеров использования механизма событий: различные прикладные
программы и процедуры вызывают события в базе данных, а сервер оповещает монитор прикладных
программ об их наступлении. Реакция монитора на события заключается в выполнении действий,
которые предусмотрел его разработчик.
Механизм событий используется следующим образом. Вначале в базе данных для каждого события
создается флажок, состояние которого будет оповещать прикладные программы о том, что
некоторое событие имело место (оператор CREATE DBEVENT - СОЗДАТЬ СОБЫТИЕ). Далее во
все прикладные программы, на ход выполнения которых может повлиять это событие, включается
оператор REGISTER DBEVENT (ЗАРЕГИСТРИРОВАТЬ СОБЫТИЕ), который оповещает сервер
базы данных, что данная программа заинтересована в получении сообщения о наступлении события.
Теперь любая прикладная программа или процедура базы данных может вызвать событие
оператором RAISE DBEVENT (ВЫЗВАТЬ СОБЫТИЕ). Как только событие произошло, каждая
зарегистрированная программа может получить его, для чего должна запросить очередное
сообщение из очереди событий (оператор GET DBEVENT - ПОЛУЧИТЬ СОБЫТИЕ) и запросить
информацию о событии, в частности, его имя (оператор SQL INQUIRE_SQL).
Пример 6 иллюстрирует обработку всех событий из очереди.
loop
EXEC SQL GET DBEVENT;
EXEC SQL INQUIRE_SQL (:event_name = DBEVENTNAME);
if (event_name = "event_1"
обработать событие event_1
else if (event_name = "event_2")
обработать событие event_2
else
...
endif
until event_name = " "
{ цикл
ПОЛУЧИТЬ СОБЫТИЕ
ПОЛУЧИТЬ ИМЯ СОБЫТИЯ
если (имя события = "первое событие")
обработать первое событие
иначе если (имя события = "второе событие")
обработать второе событие
иначе
...
конец если
пока имя события не равно пустой строке
}
Пример 6.
Рассмотрим пример из производственной системы, иллюстрирующий использование механизма
событий в базе данных совместно с правилами и процедурами. События используются для
определения ситуации, когда рабочий инструмент нагревается до температуры выше допустимой и
должен быть отключен.
1. Создается правило, которое применяется всякий раз, когда новое значение температуры
инструмента заносится в таблицу Инструмент. Как только она превосходит 500 градусов, правило
вызывает процедуру Отключить_инструмент.
CREATE RULE Перегрев_инструмента
AFTER UPDATE OF
Инструмент (Температура)
WHERE Новое.Температура >= 500
EXECUTE PROCEDURE
Отключить_инструмент
(Номер_инструмента =
Инструмент.Номер);
{ СОЗДАТЬ ПРАВИЛО
Перегрев_инструмента
ПОСЛЕ ОБНОВЛЕНИЯ
Инструмент (Температура)
ГДЕ Новое.Температура >= 500
ВЫПОЛНИТЬ ПРОЦЕДУРУ
Отключить_инструмент
(Номер_инструмента =
Инструмент.Номер);
}
2. Создается процедура базы данных Отключить_инструмент, которая вызывает событие
Перегрев; она будет выполнена в результате применения правила, определенного на шаге 1. Эта
процедура регистрирует время, в течение которого инструмент был отключен, и вызывает событие
Перегрев:
CREATE PROCEDURE
Отключить_инструмент
(Номер_инструмента) AS
BEGIN
UPDATE Инструмент
SET Статус = "ВЫКЛ"
WHERE Номер = Номер_инструмента;
RAISE DBEVENT Перегрев;
END;
{ СОЗДАТЬ ПРОЦЕДУРУ
Отключить_инструмент
(Номер_инструмента) КАК
НАЧАТЬ
ОБНОВИТЬ Инструмент
УСТАНОВИТЬ Статус = "ВЫКЛ"
ГДЕ Номер = Номер_инструмента;
ВЫЗВАТЬ СОБЫТИЕ Перегрев;
END;
}
3. Создается событие Перегрев, которое будет вызвано, когда инструмент перегреется:
CREATE DBEVENT Перегрев;
{ СОЗДАТЬ СОБЫТИЕ Перегрев }
4. Наконец, создается прикладная программа Монитор Инструментов, которая следит за
состоянием инструментов. Она регистрируется сервером в качестве получателя события Перегрев с
помощью оператора REGISTER DBEVENT. Если событие произошло, программа посылает
сообщение пользователю и сигнал, необходимый для отключения инструмента.
...
EXEC SQL REGISTER
DBEVENT Перегрев;
...
EXEC SQL GET DBEVENT;
EXEC SQL INQUIRE_SQL
(Имя события = DBEVENTNAME, ...);
if (Имя события = "Перегрев")
then
послать сообщение;
отключить инструмент;
endif;
{...
ВЫПОЛНИТЬ SQL
ЗАРЕГИСТРИРОВАТЬ СОБЫТИЕ Перегрев;
...
ВЫПОЛНИТЬ SQL ПОЛУЧИТЬ СОБЫТИЕ;
ВЫПОЛНИТЬ SQL ПОЛУЧИТЬ ИМЯ СОБЫТИЯ;
если Имя события = "Перегрев"
то
послать сообщение;
отключить инструмент;
конец если;
}
Описанные конструкции в совокупности определяют следующую логику работы (рис.13):
1. Прикладная программа Монитор Инструментов периодически регистрирует с помощью
датчиков текущие значения параметров множества различных инструментов.
2. Та же программа заносит в таблицу Инструмент новое значение температуры для данного
инструмента.
3. Всякий раз, когда это происходит, то есть обновляется значение в столбце Температура таблицы
Инструмент, применяется правило Перегрев_инструмента.
4. Применение правила состоит в проверке нового значения температуры. Если оно превышает
максимально допустимое значение, то запускается процедура Отключить_инструмент.
5. Она изменяет значение в столбце Статус таблицы Инструмент на "ВЫКЛ".
6. Она же вызывает событие Перегрев.
7. Программа Монитор Событий получает (перехватывает) событие Перегрев.
8. Она же посылает сообщение на экран диспетчеру.
9. Она же отключает инструмент.
Рисунок 13.
Пример использования механизма событий в базе данных.
Когда используются традиционные методы опроса БД, логика работы совершенно иная. Пришлось
бы разработать дополнительную программу, которая периодически выполняла бы операцию
выборки из таблицы Инструмент по критерию "Температура > 5000". Это очень заметно сказалось
бы на эффективности, поскольку операция SELECT влечет серьезные накладные расходы.
Разумеется, пример приведен лишь для иллюстрации схемы срабатывания механизма "правило процедура - событие" и ни в коей мере не отражает реальные схемы управления технологическими
процессами на производстве.
Типы данных, определяемые пользователем
Проблемы с типами данных, о которых шла речь выше, решаются за счет интеграции в сервер новых
типов данных. К сожалению, далеко не все современные СУБД поддерживают типы данных,
определенные пользователем. Пока только СУБД Ingres включает такой механизм. Эта система
предоставляет программисту возможность определять собственные типы данных и операции над
ними и использовать их в операторах SQL. Для определения нового типа данных необходимо
написать и откомпилировать функции на языке СИ, после чего собрать редактором связей
некоторые модули Ingres. Отметим, что введение новых типов данных является по сути изменением
ядра СУБД. Важно и то, что в Ingres типы данных, определяемые пользователем, могут быть
параметризованными.
Определение нового типа данных сводится к указанию в его имени, размера и идентификатора в
глобальной структуре, описывающей типы данных. Чтобы с новым типом данных можно было
использовать функции, которые реализуют стандартные операции (сравнение, преобразование в
различные форматы, и т.д.), программист должен разработать их самостоятельно (интерфейс
функций предопределен). Указатели на эти функции являются элементами глобальной структуры.
Как только новый тип данных определен, то все операции выполняются над ним, как над данными
стандартного типа. Разрешение пользователю создавать собственные типы данных - один из шагов
развития реляционных СУБД в направлении объектно-реляционных систем.
2. Доступ к данным в Oracle. SQL – язык структурированных запросов.
Доступ к данным
ORACLE отвечает общим требованиям к СУБД, к которым относятся:
* соответствие промышленно принятым стандартам для языка доступа к данным
* обеспечение согласованности информации в базе данных во время
манипулирования ее данными
* определение и обеспечение правил поддержки целостности
информации в базе данных
* обеспечение высокой производительности
SQL - структурный язык запросов
SQL - это простой, мощный язык доступа к базе данных, который является стандартным для
реляционных СУБД. SQL, реализованный корпорацией Oracle для ORACLE, на 100% согласуется
со стандартом ANSI/ISO языка SQL.
Предложения SQL
Все операции над информацией в базе данных ORACLE осуществляются посредством
ПРЕДЛОЖЕНИЙ SQL. Предложение SQL - это строка текста SQL, предоставляемая ORACLE для
исполнения. Предложение должно быть законченным предложением SQL, например:
SELECT ename, deptno FROM emp
Может быть исполнено лишь полное предложение SQL, тогда как ФРАГМЕНТ
ПРЕДЛОЖЕНИЯ, наподобие следующего, генерирует ошибку, указывающую, что требуется
дополнительный текст, чтобы предложение SQL могло быть выполнено:
SELECT ename
Предложение SQL можно рассматривать как очень простую, но мощную компьютерную
программу или инструкцию.
Предложения SQL подразделяются на пять категорий: предложения DDL, предложения
DML, предложения управления транзакциями, предложения управления сессией и предложения
встроенного SQL.
В запросах на языке SQL используются имена, которые однозначно идентифицируют объекты базы
данных. В частности, это - имя таблицы (Деталь), имя столбца (Название), а также имена других
объектов в базе, которые относятся к дополнительным типам (например, имена процедур и правил),
о которых речь пойдет в Разделе 2. Наряду с простыми, используются также сложные имена например, квалификационное имя столбца (qualified column name) определяет имя столбца и имя
таблицы, которой он принадлежит (Деталь.Вес). Для простоты в примерах имена будут записаны на
русском языке, хотя на практике этого делать не рекомендуется. Имена выделены в тексте жирным
шрифтом.
Каждый столбец в любой таблице хранит данные определенных типов. Различают базовые типы
данных - строки символов фиксированной длины, целые и вещественные числа, и дополнительные
типы данных - строки символов переменной длины, денежные единицы, дата и время, логические
данные (два значения - "ИСТИНА" и "ЛОЖЬ"). В языке SQL можно использовать числовые,
строковые, символьные константы и константы типа "дата" и "время".
Предложения определения данных (DDL)
ПРЕДЛОЖЕНИЯ DDL определяют и поддерживают объекты, а также удаляют ненужные
объекты. К предложениям DDL также относятся те, которые позволяют пользователю
предоставлять другим пользователям ПРИВИЛЕГИИ, то есть права доступа к базе данных и
конкретным объектам в базе данных.
Предложения манипулирования данными (DML)
ПРЕДЛОЖЕНИЯ DML манипулируют данными базы данных. Например,запросы, вставка,
обновление и удаление строк - это операции DML; блокировка таблицы или обзора и
исследование плана исполнения предложения SQL также относятся к операциям DML.
Предложения управления транзакциями
Предложения УПРАВЛЕНИЯ ТРАНЗАКЦИЯМИ управляют изменениями,
осуществляемыми предложениями DML. Они позволяют пользователю или разработчику
приложения группировать эти изменения в логические транзакции.
Примеры таких предложений: COMMIT, ROLLBACK и SAVEPOINT.
Предложения управления сессией
Предложения УПРАВЛЕНИЯ СЕССИЕЙ позволяют пользователю контролировать
свойства его текущей сессии, в том числе управлять включением и отключением ролей и
изменением языковых характеристик. Имеются два предложения управления сессией:
ALTER SESSION и SET ROLE.
Предложения управления системой
Команды управления системой изменяют свойства инстанции сервера ORACLE. Единственной
такой командой является ALTER SYSTEM; она позволяет изменять такие характеристики, как
минимальное число разделяемых серверных процессов, а помимо этого, убивать сессию и
выполнять некоторые другие задачи.
Предложения встроенного SQL
Предложения встроенного SQL инкорпорируют предложения DDL, DML и предложения
управления транзакциями в программу на процедурном языке (например, одном из языков,
используемых прекомпиляторами ORACLE). Примерами таких предложений являются OPEN,
CLOSE, FETCH и EXECUTE.
Билет №13
1. Процедуры базы данных. Правила, события в базе данных.
В различных СУБД они носят название хранимых (stored), присоединенных, разделяемых и т.д.
Ниже будем пользоваться терминологией, принятой в СУБД Ingres.
Использование процедур базы данных преследует четыре цели.
Во-первых, обеспечивается новый независимый уровень централизованного контроля доступа к
данным, осуществляемый администратором базы данных.
Во-вторых, одна процедура может использоваться несколькими прикладными программами - это
позволяет существенно сократить время написания программ за счет оформления их общих частей в
виде процедур базы данных. Процедура компилируется и помещается в базу данных, становясь
доступной для многократных вызовов. Так как план ее выполнения определяется единожды при
компиляции, то при последующих вызовах процедуры фаза оптимизации пропускается, что
существенно экономит вычислительные ресурсы системы.
В-третьих, использование процедур баз данных позволяет значительно снизить трафик сети в
системах с архитектурой "клиент-сервер". Прикладная программа, вызывающая процедуру, передает
серверу лишь ее имя и параметры. В процедуре, как правило, концентрируются повторяющиеся
фрагменты из нескольких прикладных программ (рис.11a). Если бы эти фрагменты остались частью
программы, они загружали бы сеть посылкой полных SQL-запросов (рис.11б).
Рисунок 11.
Увеличение производительности системы за счет использования процедур базы данных.
а. процедуры не используются;
б. выделение фрагмента прикладных программ в виде процедуры БД.
Наконец, в-четвертых, процедуры базы данных в сочетании с правилами, о которых речь пойдет
ниже, предоставляют администратору мощные средства поддержки целостности базы данных.
В современных СУБД процедура хранится непосредственно в базе данных и контролируется ее
администратором. Она имеет параметры и возвращает значение. Процедура базы данных создается
оператором CREATE PROCEDURE (СОЗДАТЬ ПРОЦЕДУРУ) и содержит определения
переменных, операторы SQL ( например, SELECT, INSERT), операторы проверки условий
(IF/THEN/ELSE) операторы цикла (FOR, WHILE), а также некоторые другие.
Правила
Механизм правил (триггеров) позволяет программировать обработку ситуаций, возникающих при
любых изменениях в базе данных.
Правило придается таблице базы данных и применяется при выполнении над ней операций
включения, удаления или обновления строк, а также при изменении значений в столбцах таблицы.
Применение правила заключается в проверке сформулированных в нем условий, при выполнении
которых происходит вызов специфицированной внутри правила процедуры базы данных. Важно,
что правило может быть применено как до, так и после выполнения операции обновления,
следовательно, возможна отмена операции.
Таким образом, правило позволяет определить реакцию сервера на любое изменение состояния базы
данных. Правила (так же, как и процедуры) хранятся непосредственно в базе данных независимо от
прикладных программ.
Одна из целей механизма правил - отражение некоторых внешних правил деятельности
организации.
Важнейшая цель механизма правил - обеспечить целостность базы данных. Один из аспектов
целостности - целостность по ссылкам (referential integrity) - относится к связи двух таблиц между
собой. Напомним, что эта связь поддерживается внешними ключами.
Механизм правил позволяет реализовать и более общие ограничения целостности.
Механизм правил - сердце активного сервера базы данных. Аналогом правил послужили триггеры
(triggers), которые впервые появились в СУБД Sybase (насколько известно автору) и впоследствии
были реализованы в том или ином виде и под тем или иным названием в большинстве
многопользовательских СУБД
События в базе данных
Механизм событий в базе данных (database events) позволяет прикладным программам и серверу
базы данных уведомлять другие программы о наступлении в базе данных определенного события и
тем самым синхронизировать их работу. Операторы языка SQL, обеспечивающие уведомление,
часто называют сигнализаторами событий в базе данных (database event alerters). Функции
управления событиями целиком ложатся на сервер базы данных.
Рисунок 12.
События в базе данных.
Рис.12 иллюстрирует один из примеров использования механизма событий: различные прикладные
программы и процедуры вызывают события в базе данных, а сервер оповещает монитор прикладных
программ об их наступлении. Реакция монитора на события заключается в выполнении действий,
которые предусмотрел его разработчик.
Механизм событий используется следующим образом. Вначале в базе данных для каждого события
создается флажок, состояние которого будет оповещать прикладные программы о том, что
некоторое событие имело место (оператор CREATE DBEVENT - СОЗДАТЬ СОБЫТИЕ). Далее во
все прикладные программы, на ход выполнения которых может повлиять это событие, включается
оператор REGISTER DBEVENT (ЗАРЕГИСТРИРОВАТЬ СОБЫТИЕ), который оповещает сервер
базы данных, что данная программа заинтересована в получении сообщения о наступлении события.
Теперь любая прикладная программа или процедура базы данных может вызвать событие
оператором RAISE DBEVENT (ВЫЗВАТЬ СОБЫТИЕ). Как только событие произошло, каждая
зарегистрированная программа может получить его, для чего должна запросить очередное
сообщение из очереди событий (оператор GET DBEVENT - ПОЛУЧИТЬ СОБЫТИЕ) и запросить
информацию о событии, в частности, его имя (оператор SQL INQUIRE_SQL).
*/*/*/*/* Alternate*/*/*/*/*/*/
Процедуры и функции
ПРОЦЕДУРЫ и ФУНКЦИИ представляют собой совокупности предложенийSQL
и PL/SQL,
сгруппированных
в
единицу
для решенияспецифической проблемы или выполнения
множества взаимосвязанных задач.
Процедура создается и сохраняется в базе
данных в откомпилированной форме, и может выполняться (вызываться) любым
пользователем или приложением. Процедуры и функции похожи друг на друга, с той
разницей, что функция всегда
возвращает вызывающей программе единственное
значение, тогда как процедура не возвращает значения.
Пакеты
ПАКЕТЫ дают метод инкапсулирования и хранения взаимосвязанных процедур, функций,
переменных и других конструктов пакета как единицы в базе данных. Предоставляя
администратору базы данных или разработчику приложений организационные преимущества,
пакеты в то же время расширяют функциональные возможности (например, глобальные
переменные пакета могут объявляться и использоваться любой процедурой в пакете) и
увеличивают производительность базы данных (так, все объекты пакета синтаксически
разбираются, компилируются и загружаются в память один раз).
Триггеры базы данных
ORACLE позволяет вам писать процедуры, которые выполняются автоматически в
результате обновления, вставки или удаления из таблицы. Такие процедуры называются
триггерами базы данных. Триггеры базы данных могут использоваться самыми
разнообразными способами для информационного управления вашей базой данных.
Например, их можно использовать для автоматизации генерации данных,
аудита
модификаций
данных,
введения
в действие комплексных ограничений целостности
или организации сложных процедур обеспечения защиты.
Целостность данных
Весьма важно
гарантировать подчиненность
данных некоторым организационным
правилам, которые определяются администратором базы
данных
или
разработчиком
приложений.
Например, предположим, что организационное правило диктует, что ни
одна строка в таблице INVENTORY не должна содержать в числовом столбце
SALE_DISCOUNT
значения,
превышающего
.9.
Если предложение INSERT или
UPDATE пытается нарушить это правило целостности, ORACLE должен откатить
некорректное предложение и возвратить приложению ошибку. Для решения проблем,
связанных с соблюдением правил целостности данных, ORACLE предлагает такие
средства, как ограничения целостности и триггеры базы данных.
Ограничения целостности
ОГРАНИЧЕНИЕ ЦЕЛОСТНОСТИ - это декларативный способ заданияорганизационного
правила для столбца таблицы.
Ограничение целостности представляет собой
утверждение о данных таблицы, которое должно быть всегда истинным:
* Если для таблицы создается ограничение целостности, и в таблице уже
существуют данные, не удовлетворяющие этому ограничению, то такое
ограничение
нельзя ввести
в действие.
* После того как
ограничение определено, если
любые результаты
предложения DML нарушают это ограничение, предложение откатывается, и возвращается
ошибка.
Ограничения целостности определяются с таблицей и сохраняются как часть
определения таблицы, централизованно в словаре данных базы данных, так что
все
приложения базы данных
должны подчиняться одному и тому же набору правил.
Если правило изменяется, его требуется изменить лишь один раз, на уровне базы данных,
а не много раз для каждого приложения.
ORACLE поддерживает следующие ограничения целостности:
NOT NULL
запрещает пустые значения (NULL) в
столбце
таблицы
UNIQUE
запрещает повторяющиеся значения в столбце или
группе столбцов
PRIMARY KEY
(первичный ключ)
запрещает повторяющиеся
и
пустые значения в столбце или группе столбцов
FOREIGN KEY
(внешний ключ) требует, чтобы каждое значение в
столбце
или
группе
столбцов
совпадало со
значением столбца UNIQUE или PRIMARY KEY другой
таблицы. (Ограничения целостности FOREIGN KEY
также
определяют
действия
"ссылочной
целостности", которые диктуют, что ORACLE должен
делать с
зависимыми данными
при изменении
данных, на которые они ссылаются.)
CHECK
запрещает значения, которые не удовлетворяют
логическому выражению ограничения
Ключи
Термин "ключ" используется в определениях различных
типов ограничений
целостности.
КЛЮЧ
- это столбец
или группа столбцов, участвующих в
определении некоторых типов ограничений целостности.
Ключи
описывают
отношения
между различными таблицами и столбцами в реляционной базе данных. Существуют
следующие типы ключей:
первичный
Столбец или
группа столбцов,
включенных в
ключ
определение ограничения таблицы PRIMARY KEY.
Значения
первичного
ключа
уникально
идентифицируют строки в таблице.
Лишь один
первичный ключ может быть определен для таблицы.
уникальный
Столбец или
группа столбцов,
включенных в
ключ
определение ограничения UNIQUE.
внешний ключ
Столбец или
группа столбцов,
включенных в
определение ограничения ссылочной целостности.
адресуемый
Уникальный или первичный ключ той же самой или
ключ
другой таблицы, на который ссылается внешний
ключ.
Индивидуальные
значения
называются ЗНАЧЕНИЯМИ КЛЮЧА.
столбца,
определенного
как ключ,
Триггеры базы данных
Замечание: Информация этой секции применима лишь к ORACLE с
процедурной опцией.
Централизованные действия могут быть определены с использованием
недекларативного подхода (т.е. написанием кода PL/SQL) с помощью триггеров базы
данных.
ТРИГГЕР БАЗЫ ДАННЫХ - это хранимая процедура, которая возбуждается (т.е.
неявно выполняется), когда для ассоциированной таблицы выдается предложение INSERT,
UPDATE или DELETE. С помощью триггеров базы данных можно снабдить СУБД такими
возможностями, как аудитинг, основанный на значениях данных, комплексный
контроль безопасности и сложные правила целостности.
Например, можно создать
триггер базы данных, который будет позволять модифицировать таблицу лишь в
нормальные рабочие часы.
Замечание: Хотя триггеры базы данных позволяют определять и
вводить в действие правила целостности, триггер базы даных это не то же самое, что ограничение целостности. Помимо прочих
различий, триггер базы данных, определенный для введения в
действие
правила
целостности,
не
проверяет
данных, уже
загруженных в таблицу.
Поэтому настоятельно
рекомендуется
использовать триггеры баз данных вместо ограничений целостности
только там, где правило целостности
действие ограничением целостности.
не может быть введено в
2. Транзакции в Oracle
Транзакция представляет собой последовательность операторов языка SQL, которая
рассматривается как некоторое неделимое действие над базой данных, осмысленное с точки
зрения пользователя. В то же время, это логическая единица работы системы. Транзакция
реализует некоторую прикладную функцию, например, перевод денег с одного счета на другой в
банковской системе.
Существуют различные модели транзакций, которые могут быть классифицированы на основании
различных свойств, включающих структуру транзакции, параллельность внутри транзакции,
продолжительность и т.д. Чаще всего имеют в виду традиционные транзакции, характеризуемые
четырьмя классическими свойствами: атомарности, согласованности, изолированности,
долговечности (прочности) - ACID (Atomicity, Consistency, Isolation, Durability). Иногда
традиционные транзакции называют ACID-транзакциями. Упомянутые выше свойства означают
следующее.
1. Свойство атомарности выражается в том, что транзакция должна быть выполнена в целом
или не выполнена вовсе.
2. Свойство согласованности гарантирует, что по мере выполнения транзакций данные
переходят из одного согласованного состояния в другое - транзакция не разрушает взаимной
согласованности данных.
3. Свойство изолированности означает, что конкурирующие за доступ к базе данных транзакции
физически обрабатываются последовательно, изолированно друг от друга, но для
пользователей это выглядит так, как будто они выполняются параллельно.
4. Свойство долговечности трактуется следующим образом: если транзакция завершена
успешно, то те изменения в данных, которые были ею произведены, не могут быть потеряны
ни при каких обстоятельствах (даже в случае последующих ошибок).
Расширенные транзакции допускают формирование из ACID-транзакций иерархических структур.
Если конкретная модель ослабляет некоторые из требований ACID, то речь идет об ослабленной
транзакции. Более подробно о расширенных и ослабленных транзакциях можно прочесть в работе
[1].
Фиксация транзакции - это действие, обеспечивающее запись на диск изменений в базе данных,
которые были сделаны в процессе выполнения транзакции. До тех пор, пока транзакция не
зафиксирована, возможно аннулирование этих изменений, восстановление базы данных в то
состояние, в котором она была на момент начала транзакции. Фиксация транзакции означает, что
все результаты выполнения транзакции становятся постоянными. Они станут видимыми другим
транзакциям только после того, как текущая транзакция будет зафиксирована. До этого момента
все данные, затрагиваемые транзакцией, будут "видны" пользователю в состоянии на начало
текущей транзакции.
Если в процессе выполнения транзакции случилось нечто такое, что делает невозможным ее
нормальное завершение, база данных должна быть возвращена в исходное состояние. Откат
транзакции - это действие, обеспечивающее аннулирование всех изменений данных, которые были
сделаны операторами SQL в теле текущей незавершенной транзакции.
Каждый оператор в транзакции выполняет свою часть работы, но для успешного завершения всей
работы в целом требуется безусловное завершение всех их операторов. Группирование операторов в
транзакции сообщает СУБД, что вся эта группа должна быть выполнена как единое целое, причем
такое выполнение должно поддерживаться автоматически.
В стандарте ANSI/ISO SQL определены модель транзакций и функции операторов COMMIT и
ROLLBACK. Стандарт определяет, что транзакция начинается с первого SQL-оператора,
инициируемого пользователем или содержащегося в программе. Все последующие SQL-операторы
составляют тело транзакции. Транзакция завершается одним из четырех возможных путей (рис.1):
оператор COMMIT означает успешное завершение транзакции; его использование делает
постоянными изменения, внесенные в базу данных в рамках текущей транзакции;
оператор ROLLBACK прерывает транзакцию, отменяя изменения, сделанные в базе данных в
рамках этой транзакции; новая транзакция начинается непосредственно после использования
ROLLBACK;
успешное завершение программы, в которой была инициирована текущая транзакция,
означает успешное завершение транзакции (как будто был использован оператор COMMIT);
ошибочное завершение программы прерывает транзакцию (как будто был использован
оператор ROLLBACK).
Рисунок 1.
Существуют и другие модели транзакций (например, принятая в Sybase). Диалект SQL Sybase
включает четыре оператора обработки транзакций:
оператор BEGIN TRANSACTION сигнализирует о начале транзакции;
оператор COMMIT TRANSACTION означает успешное выполнение транзакции; его смысл
соответствует оператору COMMIT в модели ANSI/ISO, однако после его использования
никакая новая транзакция не стартует;
оператор SAVE TRANSACTION устанавливает точку сохранения в теле транзакции - то есть
сохраняет состояние базы данных, достигнутое на момент использования оператора. Точки
сохранения именованы, что позволяет устанавливать несколько точек сохранения в
транзакции; имя точки сохранения указывается в операторе SAVE TRANSACTION.
оператор ROLLBACK TRANSACTION выполняет две функции. Если в операторе указано
имя точки сохранения, то производится откат к состоянию базы данных, достигнутому к
моменту выполнения оператора SAVE TRANSACTION. Если же в операторе не указано имя
точки сохранения, то производится откат изменений к моменту начала транзакции (см. рис.2).
Рисунок 2.
Точки сохранения применяются, как правило, в протяженных транзакциях и позволяют разделить
транзакцию на несколько небольших осмысленных фрагментов. Пользователь может зафиксировать
работу в любой точке транзакции с тем, чтобы выполнить ее откат к состоянию, соответствующему
этой точке.
Откат и фиксация транзакций становятся возможными благодаря журналу транзакций. Он
используется следующим образом. Известно, что все операции над реляционной базой данных суть
операции над строками таблиц. Следовательно, для обеспечения отката таблиц к предыдущим
состояниям достаточно хранить не состояния таблицы, а лишь те ее строки, которые подверглись
изменениям.
При выполнении любого оператора SQL, который вносит изменения в базу данных, СУБД
автоматически заносит очередную запись в журнал транзакций. Запись состоит из двух
компонентов: первый - это состояние строки до внесения изменений, второй - ее же состояние после
внесения изменений. Только после записи в журнал транзакций СУБД действительно вносит
изменения в базу данных. Если после данного оператора SQL был выполнен оператор COMMIT, то
в журнале транзакций делается отметка о завершении текущей транзакции. Если же после оператора
SQL следовал оператор ROLLBACK, то СУБД просматривает журнал транзакций и отыскивает
записи, отражающие состояние измененных строк до внесения изменений. Используя их, СУБД
восстанавливает те строки в таблицах базы данных, которые были изменены текущей транзакцией, таким образом аннулируются все изменения в базе данных.
Одной из основных проблем многопользовательских СУБД является организация одновременного
доступа к одним и тем же данным множества пользователей с помощью механизма транзакций. Они
кратко могут быть определены как: потеря изменений, незафиксированные изменения и ряд других,
более сложных проблем.
Потеря изменений происходит в ситуации, когда две или несколько программ читают одни и те же
данные из базы данных, вносят в них какие-либо изменения и затем пытаются одновременно
записать результат по прежнему месту. Разумеется, в базе данных могут быть сохранены изменения,
выполненные только одной программой, - любые другие изменения будут потеряны.
Проблема незафиксированных изменений возникает в случае, когда в процессе выполнения
транзакции одной программой в данные были внесены изменения и тут же прочитаны другой
программой, однако затем в первой программе транзакция была прервана оператором ROLLBACK.
Получается, что вторая программа прочитала неверные, незафиксированные данные.
Очевидно, что необходима определенная дисциплина обработки транзакций, позволяющая
устранить проблемы, описанные выше и им подобные. Такая дисциплина существует и опирается на
следующие правила:
(1) В процессе выполнения транзакции пользователь (или программа) "видит" только согласованные
состояния базы данных. Пользователь (или программа) никогда не может получить доступ к
незафиксированным изменениям в данных, достигнутым в результате действий другого
пользователя (программы);
(2) Если две транзакции, A и B, выполняются параллельно, то СУБД полагает, что результат будет
такой же, как если бы: - транзакция A выполнялась бы первой, за ней была бы выполнена
транзакция B; - транзакция B выполнялась бы первой, за ней была бы выполнена транзакция A.
Эта дисциплина известна как сериализация транзакций. Фактически она гарантирует, что каждый
пользователь (программа), обращающаяся к базе данных, работает с ней так, как будто не
существует других пользователей (программ), одновременно с ним обращающихся к тем же
данным. Для практической реализации этой дисциплины большинство коммерческих СУБД
используют механизм блокировок.
Для пояснения действия механизма блокировок воспользуемся Рис.3 На нем представлены три
таблицы базы данных (Заказ, Отделение, Товар), к которым возможен доступ в процессе
выполнения двух транзакций - A и B. Когда при выполнении транзакции A происходит обращение к
таблицам Заказ и Отделение, СУБД блокирует фрагмент таблицы (что имеется в виду под
фрагментом - будет расказано ниже) до тех пор, пока транзакция не будет зафиксирована или
отменена. Транзакция B выполняется параллельно и блокирует на момент своего выполнения
таблицу Товар. Если в процессе выполнения транзакции B делается попытка получить доступ к
блокированным таблицам, обработка транзакции приостанавливается и возобновляется только после
того, как транзакция А завершается и освобождает блокированные ею таблицы.
Рисунок 3.
Как мы видим, механизм блокировок разрешает проблемы, связанные с доступом нескольких
пользователей (программ) к одним и тем же данным. Однако его применение связано с
существенным замедлением обработки транзакций, вызванным необходимостью ожидания, когда
освободятся данные, захваченные конкурирующей транзакцией. Можно попытаться
минимизировать вызванный этим ущерб, локализуя фрагменты данных, захватываемые
транзакцией. Так, СУБД может блокировать всю базу данных целиком (очевидно, что это
неприемлемый вариант), таблицу базы данных, часть таблицы, отдельную строку. Описанное выше
называется уровнями блокировки. Современные СУБД используют в большинстве блокировки на
уровне частей таблиц (страниц) и/или на уровне записей.
При блокировке на уровне страниц СУБД захватывает для выполнения транзакции некоторый
фрагмент таблицы, запрещая доступ к нему (на время выполнения транзакции) конкурирующим
транзакциям. Последние, впрочем, могут захватить другие страницы той же таблицы. Так как размер
страниц обычно невелик (2-4 Кб), то время ожидания транзакций, конкурирующих за доступ к
страницам таблицы, оказывается приемлемым даже для режима оперативного доступа к базе
данных. Блокировка на уровне страниц реализована, например, в Ingres.
Если СУБД реализована таким образом, что может захватывать для выполнения транзакции
отдельные строки таблицы, то скорость обработки транзакции существенно повышается.
Блокировка на уровне записей (строк) позволяет добиться максимальной производительности за
счет того, что захватываемый объект (запись) является минимальной структурной единицей базы
данных.
Теоретически, блокировка на уровне элементов данных (захват конкретного поля строки) позволит
добиться еще большей производительности. Однако, насколько известно автору, пока ни в одной
коммерческой СУБД не удалось реализовать этот уровень блокировки.
Помимо уровней блокировки, выделяют также тип блокировки или схему блокировки.
Конкурирующие транзакции могут захватывать данные, в то же время разрешая доступ к этим
данным другим транзакциям, но только для чтения. Кроме того, транзакции могут блокировать
данные, не допуская захвата тех же данных другими транзакциями, в том числе и только для чтения.
Проиллюстрируем это примером, представленным на рис. 4.
Рисунок 4.
Две транзакции (A, B) конкурируют за доступ к таблицам Заказ, Отделение, Товар. Сравним этот
пример с предшествующим. За счет использования более гибкой схемы блокировки для таблицы
Отделение (разделяемая блокировка) мы получаем более высокий уровень параллелизма доступа
транзакций A, B к одним и тем же данным.
Оператор SQL LOCK TABLE позволяет транзакции установить на таблицу определенный тип
блокировки. Рассмотрим этот оператор на примере СУБД Informix.
Синтаксис оператора таков:
LOC-K TABLE &LTимя таблицы&GT IN SHARE MODE
LOC-K TABLE &LTимя таблицы&GT IN EXCLUSIVE MODE
Если используется тип блокировки SHARE, то это означает, что в рамках данной транзакции (то
есть транзакции, внутри которой был использован оператор LOCK TABLE) разрешено чтение из
данной таблицы в других транзакциях (однако запись в таблицу запрещена). Использование
EXCLUSIVE запрещает другим транзакциям (пока не завершена данная) читать и/или записывать
данные в таблицу. Блокировка таблицы осуществляется внутри транзакции единожды. Это означает,
что невозможно изменить тип блокировки внутри транзакции, например, с SHARE на EXLUSIVE;
это можно сделать только по завершении транзакции:
BEGIN WORK
LOC-K TABLE Заказ IN EXCLUSIVE MODE
...
COM--MIT WORK
BE-GIN WORK
LOCK TABLE Заказ
IN SHARE MODE ...
COMMIT WORK
Внимательный читатель может заметить, что транзакции могут попасть в тупиковую ситуацию,
состояние неразрешимой взаимоблокировки. Оно иллюстрируется простейшей ситуацией.
Транзакция A обновляет таблицу Заказ, блокируя некоторую ее страницу (для определенности страницу C). В то же время транзакция B обновляет таблицу Товар, блокируя страницу D таблицы.
Далее, транзакция A пытается обновить данные на странице D таблицы Товар (но, поскольку
транзакция B еще не завершена, транзакция A переводится в состояние ожидания того момента,
когда транзакция B освободит захваченную ею страницу). В этот же момент транзакция B пытается
обновить данные на странице C таблицы Заказ. Сделать этого она не может, потому что страница
захвачена транзакцией A и не освобождена, так как последняя находится в состоянии ожидания.
Транзакция B также переводится в состояния ожидания. Налицо ситуация взаимоблокировки
транзакций, которая может продолжаться бесконечно, если СУБД не предпримет специальные
меры. На практике происходят более сложные взаимоблокировки нескольких транзакций.
Для их предотвращения СУБД периодически проверяет блокировки, установленные активными
транзакциями. Если СУБД обнаруживает взаимоблокировки, она выбирает одну из транзакций,
вызвавшую ситуацию взаимоблокировки, и прерывает ее. Это освобождает данные для внесения
изменений конкурирующей транзакцией, разрешая тупиковую ситуацию. Программа, которая
инициировала прерванную транзакцию, получает сообщение об ошибке, информирующее ее о
причине прерывания (имела место тупиковая ситуация). Избежать их может правильная стратегия
внесения изменений в базу данных. Одним из наиболее простых и эффективных правил может быть
следующее: все программы, которые обновляют одни и те же таблицы, должны, по мере
возможности, делать это в одинаковой последовательности (UPDATE Заказ, UPDATE Отделение,
UPDATE Товар...).
В современной литературе часто встречается термин OLTP (On-Line Transaction Processing),
который обычно переводят как "оперативная обработка транзакций", то есть выполнение транзакций
в режиме реального времени. Система OLTP должна, безусловно учитывать жесткие временные
требования, следующие из специфики прикладной области. Например, процедура покупки и
оформления авиабилета должна происходить очень быстро и не задерживать очередь покупателей.
Система, регистрирующая продажи билетов, должна обрабатывать одновременно несколько сотен
запросов (транзакций), поступающих от множества продавцов авиабилетов. Требования по скорости
обработки запроса могут быть очень жесткими - менее секунды, однако вызваны они требованиями
реальной жизни. Область OLTP обычно - это массированный поток коротких и простых транзакций,
исходящих от сотен и тысяч пользователей, а также (возможно) базы данных большого объема. Если
говорить о прикладных областях OLTP - то это, прежде всего, центры кредитных карточек, системы
резервирования авиабилетов и мест в отелях, телекоммуникационные системы и т.д.
Если данные хранятся в одной базе данных, то транзакция к ней рассматривается как локальная.
Распределенные системы обычно включают несколько компьютеров - серверов баз данных,
называемых узлами. Данные физически распределены между ними. На каждом узле содержится
некоторая локальная база данных, содержащая фрагмент данных из общей распределенной базы (см.
предыдущий раздел). В распределенных базах транзакция, выполнение которой заключается в
обновлении данных на нескольких узлах сети, называется глобальной или распределенной
транзакцией.
Для пользователя распределенной базы данных глобальная транзакция выглядит как обычная. Это
означает, что, хотя в процессе выполнения распределенной транзакции происходит изменение
данных в нескольких базах на автономных узлах, сам этот процесс организован таким образом, что
программисту, инициирующему обработку транзакции внутри своей программы, нет необходимости
заботиться о синхронности завершения транзакции на каждом из узлов, ею затрагиваемых.
Внешне выполнение распределенной транзакции выглядит как обработка транзакции к локальной
базе данных. Тем не менее распределенная транзакция включает в себя несколько локальных
транзакций, каждая из которых завершается двумя путями - фиксируется или прерывается.
Распределенная транзакция фиксируется только в том случае, когда зафиксированы все локальные
транзакции, ее составляющие. Если хотя бы одна из локальных транзакций была прервана, то
должна быть прервана и распределенная транзакция. Как на практике учесть это требование?
Для этого в современных СУБД предусмотрен так называемый протокол двухфазовой (или
двухфазной) фиксации транзакций (two-phase commit). Название отражает тот факт, что
фиксация распределенной транзакции выполняется в две фазы.
Фаза 1 начинается, когда при обработке транзакции встретился оператор COMMIT. Сервер
распределенной БД (или компонент СУБД, отвечающий за обработку распределенных транзакций)
направляет уведомление "подготовиться к фиксации" всем серверам локальных БД, выполняющим
распределенную транзакцию. Если все серверы приготовились к фиксации (то есть откликнулись на
уведомление и отклик был получен), сервер распределенной БД принимает решение о фиксации.
Серверы локальных БД остаются в состоянии готовности и ожидают от него команды
"зафиксировать". Если хотя бы один из серверов не откликнулся на уведомление в силу каких-либо
причин, будь то аппаратная или программная ошибка, то сервер распределенной БД откатывает
локальные транзакции на всех узлах, включая даже те, которые подготовились к фиксации и
оповестили его об этом.
Фаза 2 - сервер распределенной БД направляет команду "зафиксировать" всем узлам, затронутым
транзакцией, и гарантирует, что транзакции на них будут зафиксированы. Если связь с локальной
базой данных потеряна в интервал времени между моментом, когда сервер распределенной БД
принимает решение о фиксации транзакции, и моментом, когда сервер локальной БД подчиняется
его команде, то сервер распределенной БД продолжает попытки завершить транзакцию, пока связь
не будет восстановлена.
Билет №14
1. Открытые системы.
Реальное распространение архитектуры клиент-сервер стало возможным благодаря развитию и
широкому внедрению в практику концепции открытых систем. Поэтому мы начнем с краткого
введения в открытые системы.
Основным смыслом подхода открытых систем является упрощение комплексирования
вычислительных систем за счет международной и национальной стандартизации аппаратных и
программных интерфейсов. Главной побудительной причиной развития концепции открытых
систем явились повсеместный переход к использованию локальных компьютерных сетей и те
проблемы комплексирования аппаратно-программных средств, которые вызвал этот переход. В
связи с бурным развитием технологий глобальных коммуникаций открытые системы приобретают
еще большее значение и масштабность.
Ключевая фраза открытых систем, направленная в сторону пользователей, - независимость от
конкретного поставщика. Ориентируясь на продукцию компаний, придерживающихся стандартов
открытых систем, потребитель, который приобретает любой продукт такой компании, не попадает к
ней в рабство. Он может продолжить наращивание мощности своей системы путем приобретения
продуктов любой другой компании, соблюдающей стандарты. Причем это касается как аппаратных,
так и программных средств и не является необоснованной декларацией. Реальная возможность
независимости от поставщика проверена в отечественных условиях.
Практическая опора системных и прикладных программных средств открытых систем - это
стандартизованная операционная система. В настоящее время такой системой является Unix.
Фирмам-поставщикам различных вариантов ОС Unix в результате длительной работы удалось
придти к соглашению об основных стандартах этой операционной системы. Сейчас все
распространенные версии Unix в основном совместимы по части интерфейсов, предоставляемых
прикладным (а в большинстве случаев и системным) программистам. Как кажется, несмотря на
появление претендующей на стандарт системы Windows NT, именно Unix останется основой
открытых систем в ближайшие годы.
Технологии и стандарты открытых систем обеспечивают реальную и проверенную практикой
возможность производства системных и прикладных программных средств со свойствами
мобильности (portability) и интероперабельности (interoperability). Свойство мобильности означает
сравнительную простоту переноса программной системы в широком спектре аппаратнопрограммных средств, соответствующих стандартам. Интероперабельность означает упрощение
комплексирования новых программных систем на основе использования готовых компонентов со
стандартными интерфейсами.
Применение подхода открытых систем выгодно и производителям, и пользователям. Прежде всего,
открытые системы обеспечивают естественное решение проблемы поколений аппаратных и
программных средств. Производителям таких средств не приходится решать все проблемы заново;
они могут, по крайней мере, временно продолжать комплексировать системы, используя
существующие компоненты.
Заметим, что при этом возникает новый уровень конкуренции. Все производители обязаны
обеспечить некоторую стандартную среду, но вынуждены добиваться ее как можно лучшей
реализации. Конечно, через какое-то время существующие стандарты начнут играть роль тормоза
прогресса, и тогда их придется пересматривать.
Преимуществом для пользователей является то, что они могут постепенно заменять компоненты
системы на более совершенные, не утрачивая работоспособности системы. В частности, в этом
кроется решение проблемы постепенного наращивания вычислительных, информационных и других
мощностей компьютерной системы.
2. .Процедурное языковое расширние языка SQL - PL/SQL в Oracle.
PL/SQL - это процедурное языковое расширение SQL, принадлежащее
Oracle. PL/SQL позволяет вам перемешивать предложения SQL с процедурными
конструктами. PL/SQL предоставляет возможность определять и исполнять программные
единицы PL/SQL, такие как процедуры, функции и пакеты. Программные единицы PL/SQL в целом
подразделяются на анонимные блоки и хранимые процедуры.
АНОНИМНЫЙ БЛОК - это блок PL/SQL, который появляется в вашем приложении. Во
многих приложениях блоки PL/SQL можно применять всюду, где разрешено использовать
предложения PL/SQL. Такие блоки называются анонимными, потому что они не имеют имен.
ХРАНИМАЯ ПРОЦЕДУРА - это блок PL/SQL, хранящийся в базе данных и вызываемый из
приложения по имени. Когда вы создаете хранимую процедуру командой CREATE, ORACLE
осуществляет ее разбор и сохраняет разобранное представление в базе данных. ORACLE также
позволяет вам создавать и сохранять функции, которые подобны процедурам, и пакеты, которые
являются коллекциями процедур и функций. Для информации о хранимых процедурах,
функциях, пакетах и триггерах базы данных обратитесь к главам 14 и 15.
Как исполняется PL/SQL
ПРОЦЕССОР PL/SQL (engine) - это специальная компонента многих продуктов ORACLE, в
том числе сервера ORACLE, которая занимается обработкой PL/SQL. Рис.11-1 иллюстрирует
процессор PL/SQL, содержащийся в сервере ORACLE.
Рис.11-1
Процессор PL/SQL и сервер ORACLE
Сервер ORACLE
┌─────────────────────────────────────────────┐
│
│
│
SGA
Процессор PL/SQL
│
Приложение
│ ┌──────────────────┐
┌─────────────────┐ │
базы данных
│ │
│
│ ┌─────────────┐ │ │
┌──────────────────┐
│ │ Процедура
│
│ │ Исполнитель │ │ │
│
│
│ │ ┌──────────────┐ │ ┌─ │ процедурных │ │ │
│ Программный код │
│ │ │BEGIN
│ │ │ │ │ предложений │ │ │
│ Программный код │
│ │ │ процедурное │ │ │ │ └──────┬──────┘ │ │
│ Программный код │
│ │ │ процедурное │ │ │ └────────┼────────┘ │
│ Вызов процедуры ─┼───┼──┼│ SQL
├─┼─┘
│
│
│ Программный код │
│ │ │ процедурное │ │
│SQL
│
│ Программный код │
│ │ │ SQL
│ │
│
│
│
│
│ │ │END;
│ │
┌────────────┐
│
└──────────────────┘
│ │ ├──────────────┤ │
│ Исполнитель │
│
│ └─┼──────────────┼─┘
│ предложений │
│
│
│
│
│
SQL
│
│
│
└─────────────┘
│
└────┼──────────────┼─────────────────────────┘
└─ ─ ─ ┬─ ─ ─ ─┘
╔═══════════╧════════════╗
║
База данных
║
║
║
╚════════════════════════╝
Процедура (или пакет) хранится в базе данных. Когда процедура, хранящаяся в базе
данных, вызывается из приложения, откомпилированная процедура (или пакет, в котором
она содержится) загружается в разделяемый пул в области SGA, и исполнители PL/SQL и SQL
совместно обрабатывают предложения в этой процедуре.
Процессор PL/SQL встроен в следующие продукты Oracle:
* Сервер ORACLE с процедурной опцией
* SQL*Forms (версия 3 и позже)
* SQL*Menu (версия 5 и позже)
* SQL*ReportWriter (версия 2 и позже)
* Oracle Graphics (версия 2 и позже)
Если вы имеете ORACLE с процедурной опцией, то вы можете вызывать хранимую
процедуру из другого блока PL/SQL, который может быть как анонимным блоком, так и
другой хранимой процедурой. Например, вы можете вызывать хранимые процедуры из
SQL*Forms (версии 3 или более поздней).
Кроме того, вы можете передавать ORACLE анонимные блоки из приложений,
разработанных с помощью следующих инструментов:
* Прекомпиляторов ORACLE (включая пользовательские выходы)
* Интерфейсов вызова ORACLE (OCI)
* SQL*Plus
* SQL*DBA
Языковые конструкты PL/SQL
Блоки PL/SQL могут включать следующие языковые конструкты PL/SQL:
* переменные и константы
* курсоры
* исключения
Следующие секции дают общее описание каждого конструкта; для дополнительной
информации обратитесь к документу PL/SQL User's Guide and Reference.
Переменные и константы
Переменные и константы могут объявляться в процедуре, функции и пакете. Переменная или
константа может использоваться в предложениях SQL и PL/SQL, в которых она либо
поставляет значение, либо принимает значение.
Замечание: Некоторые интерактивные инструменты, такие как SQL*DBA,
позволяют вам определять переменные в текущей сессии. Переменные, объявленные
таким
способом, можно использовать так же, как и переменные, объявляемые в
процедурах или пакетах.
Курсоры
КУРСОРЫ могут явно объявляться в процедуре, функции или пакете для облегчения
ориентированной на записи обработки данных ORACLE. Курсоры могут также неявно
объявляться процессором PL/SQL для поддержания других действий манипуляции данными.
Исключения
PL/SQL позволяет вам явно обрабатывать как внутренние, так и определенные пользователем
условия ошибок, называемых
ИСКЛЮЧЕНИЯМИ, которые могут возникать в ходе обработки кода PL/SQL. Внутренние
исключения вызываются незаконными операциями, такими как деление на 0, или ошибками
ORACLE, возвращаемыми коду PL/SQL. Пользовательские исключения определяются явно,
и возбуждаются внутри блока PL/SQL для управления обработкой ошибок, специфичной для
приложения (например, отрицательный баланс при дебитовании счета).
Когда исключение ВОЗБУЖДАЕТСЯ, нормальное выполнение кода PL/SQL останавливается, и
вызывается программа, называемая обработчиком исключений. Для любого внутреннего или
пользовательского исключения может быть написан специфичный обработчик исключений.
ORACLE с процедурным расширением также позволяет вам создавать и вызывать хранимые
процедуры. Когда ваше приложение вызывает хранимую процедуру, разобранное представление
этой процедуры извлекается из базы данных и обрабатывается процессором PL/SQL внутри
ORACLE. Вы можете вызывать хранимые процедуры из приложений, разработанных с
помощью следующих инструментов:
* Прекомпиляторов ORACLE (включая пользовательские выходы)
* Интерфейсов вызова ORACLE (OCI)
* SQL*Module
* SQL*Plus
* SQL*DBA
Вы можете также вызывать хранимую процедуру из другого блока PL/SQL, который может
быть как анонимным блоком, так и другой
хранимой процедурой. Для информации о том,
как вызывать хранимые процедуры из каждого типа приложения, обратитесь к руководству по
соответствующему инструменту; например, для прекомпиляторов - к документу Programmer's
Guide to the ORACLE Precompilers.
УРМАН
Билет №16
1. Обработка транзакций.
Раздел 4. Обработка транзакций
4.1. Понятие транзакции
В Разделе 1 уже обсуждалось понятие транзакции. Транзакция представляет собой
последовательность операторов языка SQL, которая рассматривается как некоторое неделимое
действие над базой данных, осмысленное с точки зрения пользователя. В то же время, это
логическая единица работы системы. Транзакция реализует некоторую прикладную функцию,
например, перевод денег с одного счета на другой в банковской системе.
Существуют различные модели транзакций, которые могут быть классифицированы на основании
различных свойств, включающих структуру транзакции, параллельность внутри транзакции,
продолжительность и т.д. Чаще всего имеют в виду традиционные транзакции, характеризуемые
четырьмя классическими свойствами: атомарности, согласованности, изолированности,
долговечности (прочности) - ACID (Atomicity, Consistency, Isolation, Durability). Иногда
традиционные транзакции называют ACID-транзакциями. Упомянутые выше свойства означают
следующее.
1. Свойство атомарности выражается в том, что транзакция должна быть выполнена в целом
или не выполнена вовсе.
2. Свойство согласованности гарантирует, что по мере выполнения транзакций данные
переходят из одного согласованного состояния в другое - транзакция не разрушает взаимной
согласованности данных.
3. Свойство изолированности означает, что конкурирующие за доступ к базе данных транзакции
физически обрабатываются последовательно, изолированно друг от друга, но для
пользователей это выглядит так, как будто они выполняются параллельно.
4. Свойство долговечности трактуется следующим образом: если транзакция завершена
успешно, то те изменения в данных, которые были ею произведены, не могут быть потеряны
ни при каких обстоятельствах (даже в случае последующих ошибок).
Расширенные транзакции допускают формирование из ACID-транзакций иерархических структур.
Если конкретная модель ослабляет некоторые из требований ACID, то речь идет об ослабленной
транзакции. Более подробно о расширенных и ослабленных транзакциях можно прочесть в работе
[1].
В качестве примера, иллюстрирующего понятие транзакции, рассмотрим традиционную базу
данных, состоящую из пяти таблиц: Заказчик, Менеджер, Отделение, Товар, Заказ, и
содержащую информацию о поставках некоторого Товара (контролируемых Менеджером) по
определенному Заказу из Отделения компании Заказчику. Структура таблиц выглядит следующим
образом:
Заказчик (Номер, Компания, Лимит_кредита)
Менеджер (Номер, Имя, Возраст, Должность, Место_работы, Время_работы, Руководитель, Квота,
Объем_продаж)
Отделение (Номер, Город, Число_служащих, Объем_продаж, Продаж_в_год)
Товар (Серия, Индекс, Описание, Цена, Количество)
Заказ (Номер, Дата, Номер_заказчика, Индекс_продукта, Количество, Стоимость)
Рассмотрим транзакцию "Изменить количество в заказе номер 113051 с 4 до 10, причем стоимость
заказа изменится с 140580 до 355000. Заказ на товар серии "МП456" индекс "674А" номер 113051,
размещенный менеджером под номером 108, работающим в г.Тверь (отделение 21)".
Предполагается, что пользователь вводит операторы SQL последовательно один за другим,
пользуясь некоторым интерактивным средством ввода SQL-запросов.
UPDATE Заказ
-SET Количество = 10,
Стоимость = 355000
WHERE Номер = 113051
UPDATE Менеджер
-SET Объем_продаж = Объем_продаж - 140580 + 355000
WHERE Номер = 108
UPDATE Отделение
-SET Объем_продаж = Объем_продаж - 140580 + 355000
WHERE Номер = 21
UPDATE Товар
-SET Количество_на_складе = Количество_на_складе + 4 - 10
WHE-RE Серия = "МП456"
AND Индекс = "674А"
...К этому моменту никаких ошибок не обнаружено...
COMMIT WORK
Последний оператор фиксирует изменения в базе данных, достигнутые в результате выполнения
операторов SQL, составляющих транзакцию.
Вновь рассмотрим ту же самую транзакцию, но предположим, что в процессе ввода операторов
SQL, ее составляющих, пользователь допустил ошибку и указал в последнем операторе ошибочную
серию. После этого необходимо немедленно использовать оператор ROLLBACK WORK - и тогда
все изменения в базе данных, декларированные операторами внутри транзакции, будут отменены и
база данных вернется к состоянию на момент начала транзакции.
UPDATE Заказ
-SET Количество = 10,
Стоимость = 355000
WHERE Номер = 113051
UPDATE Менеджер
-SET Объем_продаж = Объем_продаж - 140580 + 355000
WHERE Номер = 108
UPDATE Отделение
-SET Объем_продаж = Объем_продаж - 140580 + 355000
WHERE Номер = 21
UPDATE Товар
-SET Количество_на_складе = Количество_на_складе + 4 - 10
WHE-RE Серия = "МП465"
AND Индекс = "674А"
...-Ошибка! Вместо "МП456" использовано "МП465", требуется откатить изменения...
ROLLBACK WORK
Таким образом, возможны два варианта завершения транзакции. Если все операторы выполнены
успешно и в процессе выполнения транзакции не произошло никаких сбоев программного или
аппаратного обеспечения, транзакция фиксируется.
Фиксация транзакции - это действие, обеспечивающее запись на диск изменений в базе данных,
которые были сделаны в процессе выполнения транзакции. До тех пор, пока транзакция не
зафиксирована, возможно аннулирование этих изменений, восстановление базы данных в то
состояние, в котором она была на момент начала транзакции. Фиксация транзакции означает, что
все результаты выполнения транзакции становятся постоянными. Они станут видимыми другим
транзакциям только после того, как текущая транзакция будет зафиксирована. До этого момента все
данные, затрагиваемые транзакцией, будут "видны" пользователю в состоянии на начало текущей
транзакции.
Если в процессе выполнения транзакции случилось нечто такое, что делает невозможным ее
нормальное завершение, база данных должна быть возвращена в исходное состояние. Откат
транзакции - это действие, обеспечивающее аннулирование всех изменений данных, которые были
сделаны операторами SQL в теле текущей незавершенной транзакции.
Каждый оператор в транзакции выполняет свою часть работы, но для успешного завершения всей
работы в целом требуется безусловное завершение всех их операторов. Группирование операторов в
транзакции сообщает СУБД, что вся эта группа должна быть выполнена как единое целое, причем
такое выполнение должно поддерживаться автоматически.
В стандарте ANSI/ISO SQL определены модель транзакций и функции операторов COMMIT и
ROLLBACK. Стандарт определяет, что транзакция начинается с первого SQL-оператора,
инициируемого пользователем или содержащегося в программе. Все последующие SQL-операторы
составляют тело транзакции. Транзакция завершается одним из четырех возможных путей (рис.1):
оператор COMMIT означает успешное завершение транзакции; его использование делает
постоянными изменения, внесенные в базу данных в рамках текущей транзакции;
оператор ROLLBACK прерывает транзакцию, отменяя изменения, сделанные в базе данных в
рамках этой транзакции; новая транзакция начинается непосредственно после использования
ROLLBACK;
успешное завершение программы, в которой была инициирована текущая транзакция,
означает успешное завершение транзакции (как будто был использован оператор COMMIT);
ошибочное завершение программы прерывает транзакцию (как будто был использован
оператор ROLLBACK).
Рисунок 1.
Существуют и другие модели транзакций (например, принятая в Sybase). Диалект SQL Sybase
включает четыре оператора обработки транзакций:
оператор BEGIN TRANSACTION сигнализирует о начале транзакции;
оператор COMMIT TRANSACTION означает успешное выполнение транзакции; его смысл
соответствует оператору COMMIT в модели ANSI/ISO, однако после его использования
никакая новая транзакция не стартует;
оператор SAVE TRANSACTION устанавливает точку сохранения в теле транзакции - то есть
сохраняет состояние базы данных, достигнутое на момент использования оператора. Точки
сохранения именованы, что позволяет устанавливать несколько точек сохранения в
транзакции; имя точки сохранения указывается в операторе SAVE TRANSACTION.
оператор ROLLBACK TRANSACTION выполняет две функции. Если в операторе указано
имя точки сохранения, то производится откат к состоянию базы данных, достигнутому к
моменту выполнения оператора SAVE TRANSACTION. Если же в операторе не указано имя
точки сохранения, то производится откат изменений к моменту начала транзакции (см. рис.2).
Рисунок 2.
Точки сохранения применяются, как правило, в протяженных транзакциях и позволяют разделить
транзакцию на несколько небольших осмысленных фрагментов. Пользователь может зафиксировать
работу в любой точке транзакции с тем, чтобы выполнить ее откат к состоянию, соответствующему
этой точке.
Откат и фиксация транзакций становятся возможными благодаря журналу транзакций. Он
используется следующим образом. Известно, что все операции над реляционной базой данных суть
операции над строками таблиц. Следовательно, для обеспечения отката таблиц к предыдущим
состояниям достаточно хранить не состояния таблицы, а лишь те ее строки, которые подверглись
изменениям.
При выполнении любого оператора SQL, который вносит изменения в базу данных, СУБД
автоматически заносит очередную запись в журнал транзакций. Запись состоит из двух
компонентов: первый - это состояние строки до внесения изменений, второй - ее же состояние после
внесения изменений. Только после записи в журнал транзакций СУБД действительно вносит
изменения в базу данных. Если после данного оператора SQL был выполнен оператор COMMIT, то
в журнале транзакций делается отметка о завершении текущей транзакции. Если же после оператора
SQL следовал оператор ROLLBACK, то СУБД просматривает журнал транзакций и отыскивает
записи, отражающие состояние измененных строк до внесения изменений. Используя их, СУБД
восстанавливает те строки в таблицах базы данных, которые были изменены текущей транзакцией, таким образом аннулируются все изменения в базе данных.
Одной из основных проблем многопользовательских СУБД является организация одновременного
доступа к одним и тем же данным множества пользователей с помощью механизма транзакций. Они
кратко могут быть определены как: потеря изменений, незафиксированные изменения и ряд других,
более сложных проблем.
Потеря изменений происходит в ситуации, когда две или несколько программ читают одни и те же
данные из базы данных, вносят в них какие-либо изменения и затем пытаются одновременно
записать результат по прежнему месту. Разумеется, в базе данных могут быть сохранены изменения,
выполненные только одной программой, - любые другие изменения будут потеряны.
Проблема незафиксированных изменений возникает в случае, когда в процессе выполнения
транзакции одной программой в данные были внесены изменения и тут же прочитаны другой
программой, однако затем в первой программе транзакция была прервана оператором ROLLBACK.
Получается, что вторая программа прочитала неверные, незафиксированные данные.
Очевидно, что необходима определенная дисциплина обработки транзакций, позволяющая
устранить проблемы, описанные выше и им подобные. Такая дисциплина существует и опирается на
следующие правила:
(1) В процессе выполнения транзакции пользователь (или программа) "видит" только согласованные
состояния базы данных. Пользователь (или программа) никогда не может получить доступ к
незафиксированным изменениям в данных, достигнутым в результате действий другого
пользователя (программы);
(2) Если две транзакции, A и B, выполняются параллельно, то СУБД полагает, что результат будет
такой же, как если бы: - транзакция A выполнялась бы первой, за ней была бы выполнена
транзакция B; - транзакция B выполнялась бы первой, за ней была бы выполнена транзакция A.
Эта дисциплина известна как сериализация транзакций. Фактически она гарантирует, что каждый
пользователь (программа), обращающаяся к базе данных, работает с ней так, как будто не
существует других пользователей (программ), одновременно с ним обращающихся к тем же
данным. Для практической реализации этой дисциплины большинство коммерческих СУБД
используют механизм блокировок.
Для пояснения действия механизма блокировок воспользуемся Рис.3 На нем представлены три
таблицы базы данных (Заказ, Отделение, Товар), к которым возможен доступ в процессе
выполнения двух транзакций - A и B. Когда при выполнении транзакции A происходит обращение к
таблицам Заказ и Отделение, СУБД блокирует фрагмент таблицы (что имеется в виду под
фрагментом - будет расказано ниже) до тех пор, пока транзакция не будет зафиксирована или
отменена. Транзакция B выполняется параллельно и блокирует на момент своего выполнения
таблицу Товар. Если в процессе выполнения транзакции B делается попытка получить доступ к
блокированным таблицам, обработка транзакции приостанавливается и возобновляется только после
того, как транзакция А завершается и освобождает блокированные ею таблицы.
Рисунок 3.
Как мы видим, механизм блокировок разрешает проблемы, связанные с доступом нескольких
пользователей (программ) к одним и тем же данным. Однако его применение связано с
существенным замедлением обработки транзакций, вызванным необходимостью ожидания, когда
освободятся данные, захваченные конкурирующей транзакцией. Можно попытаться
минимизировать вызванный этим ущерб, локализуя фрагменты данных, захватываемые
транзакцией. Так, СУБД может блокировать всю базу данных целиком (очевидно, что это
неприемлемый вариант), таблицу базы данных, часть таблицы, отдельную строку. Описанное выше
называется уровнями блокировки. Современные СУБД используют в большинстве блокировки на
уровне частей таблиц (страниц) и/или на уровне записей.
При блокировке на уровне страниц СУБД захватывает для выполнения транзакции некоторый
фрагмент таблицы, запрещая доступ к нему (на время выполнения транзакции) конкурирующим
транзакциям. Последние, впрочем, могут захватить другие страницы той же таблицы. Так как размер
страниц обычно невелик (2-4 Кб), то время ожидания транзакций, конкурирующих за доступ к
страницам таблицы, оказывается приемлемым даже для режима оперативного доступа к базе
данных. Блокировка на уровне страниц реализована, например, в Ingres.
Если СУБД реализована таким образом, что может захватывать для выполнения транзакции
отдельные строки таблицы, то скорость обработки транзакции существенно повышается.
Блокировка на уровне записей (строк) позволяет добиться максимальной производительности за
счет того, что захватываемый объект (запись) является минимальной структурной единицей базы
данных.
Теоретически, блокировка на уровне элементов данных (захват конкретного поля строки) позволит
добиться еще большей производительности. Однако, насколько известно автору, пока ни в одной
коммерческой СУБД не удалось реализовать этот уровень блокировки.
Помимо уровней блокировки, выделяют также тип блокировки или схему блокировки.
Конкурирующие транзакции могут захватывать данные, в то же время разрешая доступ к этим
данным другим транзакциям, но только для чтения. Кроме того, транзакции могут блокировать
данные, не допуская захвата тех же данных другими транзакциями, в том числе и только для чтения.
Проиллюстрируем это примером, представленным на рис. 4.
Рисунок 4.
Две транзакции (A, B) конкурируют за доступ к таблицам Заказ, Отделение, Товар. Сравним этот
пример с предшествующим. За счет использования более гибкой схемы блокировки для таблицы
Отделение (разделяемая блокировка) мы получаем более высокий уровень параллелизма доступа
транзакций A, B к одним и тем же данным.
Оператор SQL LOCK TABLE позволяет транзакции установить на таблицу определенный тип
блокировки. Рассмотрим этот оператор на примере СУБД Informix.
Синтаксис оператора таков:
LOC-K TABLE &LTимя таблицы&GT IN SHARE MODE
LOC-K TABLE &LTимя таблицы&GT IN EXCLUSIVE MODE
Если используется тип блокировки SHARE, то это означает, что в рамках данной транзакции (то
есть транзакции, внутри которой был использован оператор LOCK TABLE) разрешено чтение из
данной таблицы в других транзакциях (однако запись в таблицу запрещена). Использование
EXCLUSIVE запрещает другим транзакциям (пока не завершена данная) читать и/или записывать
данные в таблицу. Блокировка таблицы осуществляется внутри транзакции единожды. Это означает,
что невозможно изменить тип блокировки внутри транзакции, например, с SHARE на EXLUSIVE;
это можно сделать только по завершении транзакции:
BEGIN WORK
LOC-K TABLE Заказ IN EXCLUSIVE MODE
...
COM--MIT WORK
BE-GIN WORK
LOCK TABLE Заказ
IN SHARE MODE ...
COMMIT WORK
Внимательный читатель может заметить, что транзакции могут попасть в тупиковую ситуацию,
состояние неразрешимой взаимоблокировки. Оно иллюстрируется простейшей ситуацией.
Транзакция A обновляет таблицу Заказ, блокируя некоторую ее страницу (для определенности страницу C). В то же время транзакция B обновляет таблицу Товар, блокируя страницу D таблицы.
Далее, транзакция A пытается обновить данные на странице D таблицы Товар (но, поскольку
транзакция B еще не завершена, транзакция A переводится в состояние ожидания того момента,
когда транзакция B освободит захваченную ею страницу). В этот же момент транзакция B пытается
обновить данные на странице C таблицы Заказ. Сделать этого она не может, потому что страница
захвачена транзакцией A и не освобождена, так как последняя находится в состоянии ожидания.
Транзакция B также переводится в состояния ожидания. Налицо ситуация взаимоблокировки
транзакций, которая может продолжаться бесконечно, если СУБД не предпримет специальные
меры. На практике происходят более сложные взаимоблокировки нескольких транзакций.
Для их предотвращения СУБД периодически проверяет блокировки, установленные активными
транзакциями. Если СУБД обнаруживает взаимоблокировки, она выбирает одну из транзакций,
вызвавшую ситуацию взаимоблокировки, и прерывает ее. Это освобождает данные для внесения
изменений конкурирующей транзакцией, разрешая тупиковую ситуацию. Программа, которая
инициировала прерванную транзакцию, получает сообщение об ошибке, информирующее ее о
причине прерывания (имела место тупиковая ситуация). Избежать их может правильная стратегия
внесения изменений в базу данных. Одним из наиболее простых и эффективных правил может быть
следующее: все программы, которые обновляют одни и те же таблицы, должны, по мере
возможности, делать это в одинаковой последовательности (UPDATE Заказ, UPDATE Отделение,
UPDATE Товар...).
В современной литературе часто встречается термин OLTP (On-Line Transaction Processing),
который обычно переводят как "оперативная обработка транзакций", то есть выполнение транзакций
в режиме реального времени. Система OLTP должна, безусловно учитывать жесткие временные
требования, следующие из специфики прикладной области. Например, процедура покупки и
оформления авиабилета должна происходить очень быстро и не задерживать очередь покупателей.
Система, регистрирующая продажи билетов, должна обрабатывать одновременно несколько сотен
запросов (транзакций), поступающих от множества продавцов авиабилетов. Требования по скорости
обработки запроса могут быть очень жесткими - менее секунды, однако вызваны они требованиями
реальной жизни. Область OLTP обычно - это массированный поток коротких и простых транзакций,
исходящих от сотен и тысяч пользователей, а также (возможно) базы данных большого объема. Если
говорить о прикладных областях OLTP - то это, прежде всего, центры кредитных карточек, системы
резервирования авиабилетов и мест в отелях, телекоммуникационные системы и т.д.
Если данные хранятся в одной базе данных, то транзакция к ней рассматривается как локальная.
Распределенные системы обычно включают несколько компьютеров - серверов баз данных,
называемых узлами. Данные физически распределены между ними. На каждом узле содержится
некоторая локальная база данных, содержащая фрагмент данных из общей распределенной базы (см.
предыдущий раздел). В распределенных базах транзакция, выполнение которой заключается в
обновлении данных на нескольких узлах сети, называется глобальной или распределенной
транзакцией.
Для пользователя распределенной базы данных глобальная транзакция выглядит как обычная. Это
означает, что, хотя в процессе выполнения распределенной транзакции происходит изменение
данных в нескольких базах на автономных узлах, сам этот процесс организован таким образом, что
программисту, инициирующему обработку транзакции внутри своей программы, нет необходимости
заботиться о синхронности завершения транзакции на каждом из узлов, ею затрагиваемых.
Внешне выполнение распределенной транзакции выглядит как обработка транзакции к локальной
базе данных. Тем не менее распределенная транзакция включает в себя несколько локальных
транзакций, каждая из которых завершается двумя путями - фиксируется или прерывается.
Распределенная транзакция фиксируется только в том случае, когда зафиксированы все локальные
транзакции, ее составляющие. Если хотя бы одна из локальных транзакций была прервана, то
должна быть прервана и распределенная транзакция. Как на практике учесть это требование?
Для этого в современных СУБД предусмотрен так называемый протокол двухфазовой (или
двухфазной) фиксации транзакций (two-phase commit). Название отражает тот факт, что
фиксация распределенной транзакции выполняется в две фазы.
Фаза 1 начинается, когда при обработке транзакции встретился оператор COMMIT. Сервер
распределенной БД (или компонент СУБД, отвечающий за обработку распределенных транзакций)
направляет уведомление "подготовиться к фиксации" всем серверам локальных БД, выполняющим
распределенную транзакцию. Если все серверы приготовились к фиксации (то есть откликнулись на
уведомление и отклик был получен), сервер распределенной БД принимает решение о фиксации.
Серверы локальных БД остаются в состоянии готовности и ожидают от него команды
"зафиксировать". Если хотя бы один из серверов не откликнулся на уведомление в силу каких-либо
причин, будь то аппаратная или программная ошибка, то сервер распределенной БД откатывает
локальные транзакции на всех узлах, включая даже те, которые подготовились к фиксации и
оповестили его об этом.
Фаза 2 - сервер распределенной БД направляет команду "зафиксировать" всем узлам, затронутым
транзакцией, и гарантирует, что транзакции на них будут зафиксированы. Если связь с локальной
базой данных потеряна в интервал времени между моментом, когда сервер распределенной БД
принимает решение о фиксации транзакции, и моментом, когда сервер локальной БД подчиняется
его команде, то сервер распределенной БД продолжает попытки завершить транзакцию, пока связь
не будет восстановлена.
4.2. Мониторы транзакций
Мониторы обработки транзакций (Transaction Processing Monitor - TPM), или, проще, мониторы
транзакций - программные системы (которые относят к категории middleware, то есть к
посредническому или промежуточному программному обеспечению), обеспечивающие
эффективное управление информационно-вычислительными ресурсами в распределенной системе.
Они представляют собой гибкую, открытую среду для разработки и управления мобильными
приложениями, ориентированными на оперативную обработку распределенных транзакций. В числе
важнейших характеристик TPM - масштабируемость, поддержка функциональной полноты и
целостности приложений, достижение максимальной производительности обработки данных при
невысоких стоимостных показателях, поддержка целостности данных в гетерогенной среде. TPM
опираются на трехзвенную модель "клиент-сервер" (модель сервера приложений или AS-модель),
описанную в Разделе 2. Естественно, что все преимущества модели отражаются и на программных
системах, построенных на ее основе.
На современном рынке мониторов транзакций основными "действующими лицами" являются такие
системы, как ACMS (DEC), CICS (IBM), TOP END (NCR), PATHWAY (Tandem), ENCINA (Transarc),
TUXEDO System (USL). Наиболее известной из этой группы является система CICS - наверняка
среди читателей найдутся специалисты, работавшие с ней на мэйнфреймах IBM. Несмотря на
принципиальное сходство, конкретные TPM отличаются рядом характеристик, причем различия
часто вытекают как из специфики операционной системы, в которой реализован и функционирует
TPM. Ниже будет описаны основные возможности TPM на базе операционной системы UNIX.
4.2.1. Корпоративная среда обработки транзакций
TPM на базе UNIX опирается на фундаментальное понятие - корпоративную среду обработки
транзакций (Enterprise Transaction Processing - ETP). Архитектура ETP (рис.5) - это три ряда
компьютеров:
Ряд 1: Персональные станции (Personal Workstations);
Ряд 2: Компьютеры под управлением ОС UNIX (UNIX Transaction Processing Servers - UPTS);
Ряд 3: Mainframe-системы (Proprietary Transaction Processing Servers - PTPS) или компьютеры
под управлением UNIX c RISC-архитектурой процессоров;
Рисунок 5.
Компьютеры ряда 1, функционирующие под управлением DOS, MS Windows, OS/2, UNIX,
используются в качестве рабочих мест конечных пользователей. Характерная черта ETP отсутствие ограничений на модели компьютеров, составляющих этот ряд. Однако, как правило, ряд
1 состоит из компьютеров на базе процессоров Intel 486/Pentium под управлением MS Windows (MS
Windows фактически стала стандартом оконного графического интерфейса для большинства
категорий пользователей и стандартом операционной среды для подавляющего числа прикладных
программ и систем).
Ряд 2 составляют компьютеры среднего класса под управлением ОС UNIX, на которых
функционирует ядро TPM и, как правило, реляционные СУБД (Oracle, Informix, Ingres),
выступающие в качестве менеджера ресурсов. Кроме того, на них же может быть установлен шлюз к
TPM в операционной среде мэйнфрейма (как правило, разработчики TPM на базе UNIX
предусматривают в конфигурации своих систем шлюз к наиболее популярной такой системе - IBM
CICS).
Ряд 3 представлен мэйнфреймами или RISC-компьютерами под управлением UNIX. О мэйнфреймах
мы говорим в тех ситуациях, когда исторически сложилось так, что в организации они существуют
уже долгое время, берут на себя большую часть всего объема обработки транзакций, концетрируют
огромные вычислительные ресурсы и содержат большие массивы данных (то есть речь идет об
унаследованных системах). Если этого "тяжелого наследия" нет, то можно смело использовать в
качестве компьютеров ряда 3 RISC-серверы, сегодня приближающиеся по производительности к
мэйнфреймам.
Таким образом, среда обработки транзакций формируется из набора разнородных компьютеров (и
соответствующих ОС), ранжируемых от персональных компьютеров до мэйнфрейм-систем. TPM на
базе UNIX представляет собой своего рода "клей", который связывает вместе компьютеры трех
рядов в открытую унифицированную среду обработки транзакций.
Ключом к интеграции систем, функционирующих на компьютерах различных рядов, является
специализированный интерфейс прикладного программирования ATMI (Application Transaction
Manager Interface), обеспечивающий:
для ряда 1 - формирование и передачу запросов от клиентов к серверам, выполняющимся на
компьютерах ряда 2;
для ряда 2 - обработку запросов, поступающих от компьютера ряда 1 (в том числе и с
обращением к менеджеру ресурсов), и, по необходимости, формирование и направление
запросов к серверам, выполняющимся на компьютерах ряда 3.
для ряда 3 - обработку запросов, поступающих от серверов ряда 2.
Отметим, что подобное представление о корпоративной среде обработки транзакций не является
абстракцией. Сегодня многие организации приходят именно к такой, "трехуровневой" архитектуре
информационных систем (с той оговоркой, что наличие ряда 3 вызвано историческими причинами мэйнфреймы использовались первоначально и сразу от них отказаться невозможно).
4.2.2. Модель обработки транзакций
Понятия транзакции в TPM и в традиционных СУБД значительно отличаются. Суть остается одной,
но в понимании СУБД транзакция - это атомарное действие над базой данных, в то время как в TPM
транзакция трактуется гораздо шире. Она включает не только операции с данными, но и любые
другие действия - передачу сообщений, выдачу отчетов, запись в индексированные файлы, опрос
датчиков и т.д. Это позволяет реализовать в TPM прикладные транзакции, бизнес-транзакции, что в
СУБД, вообще говоря, сделать невозможно.
TPM опирается на модель обработки распределенных транзакций X/Open DTP, которая описывает
взаимодействие трех субъектов обработки транзакций - прикладной программы (в качестве
прикладной программы фигурирует как сервер приложения, так и клиент приложения), менеджера
транзакций (Transaction Manager - TM) и менеджера ресурсов (Resource Manager - RM). Модель
представлена на рис. 6
Рисунок 6.
На RM возложено управление информационными ресурсами - будь то файлы, базы данных или чтото другое. Приложение взаимодействует с RM либо с помощью набора специальных функций, либо,
если в качестве RM выступает реляционная SQL-ориентированная СУБД - посредством операторов
языка SQL, инициируя необходимые операции с данными. Последние оформляются как транзакции,
обработку которых берет на себя TM. Если с помощью монитора транзакций необходимо решать
задачи обработки распределенных транзакций, то роль менеджера ресурсов должна играть СУБД,
поддерживающая двухфазовый протокол фиксации транзакций и удовлетворяющая стандарту
X/Open XA (например Oracle 7.x, OpenINGRES, Informix-Online 7.x).
Роль TM в модели X/Open DTP - это роль диспетчера, главного координатора транзакций. Он
обладает полным набором функций управления как локальными, так и глобальными,
распределенными транзакциями. В последнем случае транзакция может обновлять данные на
нескольких узлах, причем управление данными на них осуществляется различными RM. Обработка
распределенных транзакций обеспечивается за счет использования протокола двухфазовой
фиксации транзакций, который гарантирует целостность данных в информационной системе,
распределенной по нескольким узлам, независимо от того, какой RM управляет обработкой данных
на каждом таком узле. Эта уникальная возможность как раз и позволяет рассматривать TPM как
средство интеграции в гетерогенной информационной среде.
Функции TM в модели X/Open DTP не ограничиваются только управлением транзакциями. Он берет
на себя также координацию взаимодействия клиента и сервера (поэтому иногда его называют
менеджером транзакций и коммуникаций). При этом используется высокоуровневый интерфейс
ATMI (о котором речь шла выше), представляющий собой набор вызовов функций на языке
третьего поколения (например на языке C). С его помощью разработчик реализует один из
нескольких режимов взаимодействия клиента и сервера в рамках расширенной модели "клиентсервер". Ни сервер приложения, ни клиент приложения не содержат явных вызовов менеджера
транзакций - они включены в библиотечные функции ATMI и невидимы извне. Таким образом,
детали взаимодействия прикладной программы и монитора транзакций скрыты от разработчика, что
и дает основание говорить об ATMI как о высокоуровневом интерфейсе.
Модель X/Open DTP не описывает в деталях структуру TPM. Она лишь определяет, из каких
компонентов должна состоять любая система DTP и как эти компоненты взаимодействуют друг с
другом. Будучи воплощенной в конкретной системе, модель дополняется возможностями,
существенно расширяющими традиционные представления о технологии "клиент-сервер".
4.2.3. Интерфейс прикладного программирования ATMI
Как уже говорилось выше, TPM - это инструмент эффективной реализации технологии "клиентсервер". Что конкретно за этим стоит? Реальная информационная система - это совокупность
взаимодействующих программ. Некоторые из них предоставляют набор услуг, называемых обычно
сервисами (перевод английского термина "services" - некоторое искажение правил русского языка,
где слово "сервис" обычно употребляется в единственном числе). Такие программы
рассматриваются, как программы-серверы. Программы, желающие воспользоваться данными
услугами и обращающиеся с этой целью к серверам, обычно называют клиентами. Интерфейс
прикладного программирования описывает набор вызовов, с помощью которых можно организовать
взаимодействие программы-клиента и программы-сервера несколькими различными способами.
При этом надо иметь в виду, что программы эти выполняются в рамках различных процессов,
которые, возможно, функционируют на различных, быть может, разнородных компьютерах.
Следовательно, речь идет об описании межпроцессного взаимодействия в терминах "клиент-сервер".
В качестве иллюстрации приведем пример использования TUXEDO ATMI. Отметим, что они
представляют интерес только для читателей, знакомых с языком C. Остальным мы рекомендуем
пропустить этот раздел и перейти к чтению следующего.
В примере программа-клиент передает программе-серверу строку для конвертации. Для этого в
программе-клиенте используется вызов tpcall(). С его помощью организуется синхронный режим
взаимодействия клиента и сервера, когда клиент запрашивает сервер и моментально получает ответ.
Задача сервера - выполнить некоторое преобразование передаваемой строки и вернуть результат
клиенту.
/* Программа - клиент */
#include &LTstdio.h&GT
#include "atmi.h"
#define BUFLEN 80
ma-in(){
char *inpbuf, *outbuf;
long len;
/* -Инициализация связи клиента с сервером */
if (--tpinit((TPINIT *) NULL) == -1){ return(1);
}
/* Выделение памяти под буфер */
if -((buf = tpalloc("STRING", NUL-L, BUFLEN)) == NULL) {
tpterm();
return(2);
}
strcpy (buf, "TUXEDO example");
/* Вызов сервиса CONVERT */
if -(tpcall("CONVERT", inpbuf, 0, &AMPoutbuf, &AMPlen, 0) == -1) { fprintf (stderr, "Service request failed");
tpfree (buf);
tpterm();
return(3);
}
/* Печать результата */
pr-intf ("Converted string %s", outbuf);
/* -Освобождение памяти, занятой под буфер */
tpfree (buf);
/* -Отключение программы-клиента от сервера */
tpterm ();
return (0);
}
/* Программа - сервер */
#include &LTstdio.h&GT
#include "atmi.h"
CO-NVERT (TPSVCINFO *rqst){
int i;
/* -Выполнить преобразование строки */
for- (i = 0; i &LT rqst-&GTlen; i++)
rqst-&GTdata[i] = convert(rqst-&GTdata[i]);
/* Вернуть преобразованный буфер */
tpr-eturn (TPSUCCESS, 0, rqst-&GTdata, 0L, 0);
}
Как мы видим в примере, обращение клиента к серверу происходит синхронно: клиент заполняет
буфер данных, вызывает сервис CONVERT; данные в результирующем буфере возвращаются в
программу-клиент немедленно по завершении работы сервиса CONVERT программы-сервера.
Однако это - самый простейший и самый очевидный способ организации взаимодействия клиента и
сервера. Возможны и другие, более изощренные способы взаимодействия, например
полудуплексный режим обмена запросами между клиентом и сервером (в один момент времени
только один процесс может посылать и только один сервис - получать сообщение).
4.2.4. Функциональный подход
Фундаментальная характеристика TPM - функциональный (function-centric) подход к
проектированию бизнес-приложений. Еще раз отметим, что сосредоточение всех прикладных
функций в серверах приложений по сути означает "поставку (или предоставление) функций"
(functions shipping) для программы-клиента, в отличие от традиционной архитектуры с сервером
базы данных, следующей парадигме "поставка (или предоставление) данных" (data shipping).
Возможность декомпозиции приложений по нескольким уровням с четко очерченными функциями
и стандартными интерфейсами позволяет создавать легко модифицируемые системы со стройной и
целостной архитектурой. Концентрация чисто прикладных функций в серверах приложений и
использование унифицированных интерфейсов с другими логическими компонентами делает
прикладную систему практически полностью независимой как от конкретной реализации
интерфейса с пользователем, так и от необходимого ей менеджера ресурсов. Первое означает, что
для реализации интерфейса с пользователем может быть выбран любой удобный и привычный для
разработчика инструментарий, будь то Microsoft Visual С++ или Visual Basic; следствием второго
является то, что менеджер ресурсов (например СУБД) может быть заменен на другой,
поддерживающий тот же стандарт интерфейса с прикладной программой - для реляционных СУБД в
качестве унифицированного интерфейса используется встроенный (embedded) SQL. Разумеется, в
реализации ESQL для каждой конкретной СУБД имеются различия, порой весьма существенные.
Поэтому приложение должно быть либо разработано специально с целью работы с конкретной
СУБД, либо оно должно быть спроектировано так, чтобы максимально безболезненно быть
перенастроено на работу с другой СУБД.
Концентрация прикладных функций в сервере приложения на практике означает совершенно иной по сравнению с другими видами программного обеспечения - подход к администрированию
приложения, существенно упрощающий обновление бизнес-функций и контроль за их
непротиворечивостью. Начнем с того, что разделение компонента представления и прикладного
компонента позволяет поручить их реализацию двум независимым специализированным группам
разработчиков. Первая сосредотачивает свое внимание на разработке и реализации интерфейса с
пользователем, уделяя основное внимание связанным с этим вопросам (стиль интерфейса,
эргономические требования и т.д.). Вторая группа полностью концентрируется на "чистой"
реализации приложения и не обращает никакого внимания на интерфейс с пользователем.
Интерфейс между компонентами, разрабатывемыми разными группами, представляет собой
специализированный API (например TUXEDO ATMI). Преимущество подобного подхода - в
специализации, разделении труда и более быстрой реализации проекта за счет параллельной работы
групп программистов.
Функциональный подход имеет своим следствием и преимущества администрирования
приложения. Отныне оно рассматривается как единое целое; сервер приложения имеет набор
параметров, устанавливаемых его администратором; как и сервер БД, сервер приложения
запускается и останавливается специальными командами; существуют команды, позволяющие
опросить параметры сервера приложения и вывести их на консоль.
Любые изменения в прикладных функциях осуществляются локально, в сервере приложения, и
никак не затрагивают коды клиентов приложения, которых (клиентов) может быть множество. Более
того, эти изменения вносятся специалистом - администратором сервера приложения, единственным
лицом, отвечающим за функциональность и семантическую целостность приложения. Разработчики
программ-клиентов никак не участвуют в процедуре обновления приложения - это выходит за рамки
их компетенции.
4.2.5. Другие возможности TPM
Уникальная возможность TPM - динамическая настройка параметров системы для достижения
требуемой производительности (баланс загрузки). TPM поддерживает как статический, так и
динамический балансы. Суть заключается в том, что TPM запускает или останавливает серверы
приложений в зависимости от предопределенных условий и текущего состояния системы. Для
оптимизации пропускной способности системы TPM тиражирует копии процессов-серверов на этом
же или других узлах, предоставляя тем самым в распоряжение клиентов приложения необходимые
вычислительные ресурсы (в виде дополнительных процессов) для выполнения запросов клиентов.
Помимо вертикального и горизонтального масштабирования TPM обеспечивает так называемую
матричную масштабируемость. Это - интеграция дополнительных ресурсов в гетерогенную среду
в любой ее точке без изменения архитектуры приложения, которое в этой среде функционирует.
Достигается это за счет динамической реконфигурации, а на практике означает, что в конфигурацию
системы динамически, без остановки серверов приложений, может быть добавлен, например, новый
сервер приложения, дополнительный менеджер ресурсов или новый компьютер. Очевидно, что
матричная масштабируемость практически неограниченно расширяет возможности управления
параметрами системы для достижения требуемой производительности.
TPM обладает возможностями, которые существенно снижают стоимость обработки данных в
online-приложениях. Небольшие затраты на ее приобретение с лихвой компенсируются экономией
на СУБД. Дело в том, что, как правило, стоимость современных СУБД рассчитывается исходя из
числа одновременных подключений (connection). Клиент считается подключенным к СУБД, начиная
с момента открытия сеанса (session) с базой данных и заканчивая ее закрытием. В течение сеанса
СУБД считает клиента активным и вынуждена хранить контекст его подключения, даже в том
случае, если клиент вообще не направляет запросов СУБД, а выполняет свои внутренние функции
либо просто ждет ввода от пользователя.
Одна из основных функций TPM - обеспечение быстрой обработки запросов, поступающих к
серверу приложений от множества клиентов (от сотен до тысяч). TPM выполняет ее,
мультиплексируя запросы на обслуживание, направляя их к серверу приложения, число которых
контролируется им самим. Запросы на обработку данных формируются сервером приложения на
языке SQL и адресуются СУБД. Между клиентом приложения и СУБД появляется дополнительный
слой, который играет роль мультиплексора. Действительно, клиент подключается к серверу,
передает ему данные для обработки; после того, как сервер выполнил требуемые действия, он
получает результаты обработки и отключается. Контекст подключения не сохраняется, так как в
этом нет никакой необходимости. В то же время клиент обращается с запросами на обслуживание не
к СУБД, а к серверу, следовательно, СУБД регистрирует и отслеживает подключения сервера, но не
клиента приложения. Однако таких подключений будет заведомо меньше, чем возможных
подключений клиентов - хотя бы потому, что сервер приложений предоставляет сервис,
разделяемый одновременно несколькими клиентами. Но это позволяет ограничить максимально
возможное число одновременных подключений к СУБД, уменьшив тем самым ее стоимость.
Важнейшая характеристика TPM - поддержка многомашинных конфигураций с возможностью
миграции серверов приложений и их групп на резервный компьютер в случае сбоев в работе
основного является фундаментом, на котором может быть построена система, по надежности
близкая к абсолютной. Действительно, применение так называемых безотказных (fault tolerant)
компьютеров гарантирует работоспособность лишь при случайных сбоях, но бессильно перед
злоумышленником или в случае механического повреждения.
2. Согласованное чтение данных в Oracle.
Билет №17
1. Синтаксическая и семантическая оптимизация запросов. 4/96 (Кузнецов)
2. Синтаксическая оптимизация запросов
При классическом подходе к организации оптимизаторов запросов на этапе логической
оптимизации производятся эквивалентные преобразования внутреннего представления запроса,
которые "улучшают" начальное внутреннее представление в соответствии с фиксированными
стратегиями оптимизатора. Характер "улучшений" связан со спецификой общей организации
оптимизатора, в частности с особенностями процедуры поиска возможных процедурных планов
запросов, выполняемой на третьей фазе обработки запроса.
Поэтому трудно привести полную характеристику и классификацию методов логической
оптимизации. Мы ограничимся несколькими примерами, а также рассмотрим один частный, но
важный класс логических преобразований, касающихся сложных запросов, выраженных на языке
SQL.
2.1. Простые логические преобразования запросов
Очевидный класс логических преобразований запроса составляют преобразования предикатов,
входящих в условие выборки, к каноническому представлению. Имеются в виду предикаты,
содержащие операции сравнения простых значений. Такой предикат имеет вид арифметическое
выражение op арифметическое выражение, где op - операция сравнения, а арифметические
выражения левой и правой частей в общем случае содержат имена полей отношений и константы (в
языке SQL среди констант могут встречаться и имена переменных объемлющей программы,
значения которых становятся известными только при реальном выполнении запроса).
Канонические представления могут быть различными для предикатов разных типов. Если предикат
включает только одно имя поля, то его каноническое представление может, например, иметь вид
имя поля op константное арифметическое выражение (эта форма предиката - простой предикат
селекции - очень полезна при выполнении следующего этапа оптимизации). Если начальное
представление предиката имеет вид (a+5)*A op 36 (малыми буквами обозначены имена объемлющих
переменных, а большими - имена полей отношений), то каноническим представлением такого
предиката может быть A op 36/(a+5). Если предикат включает в точности два имени поля разных
отношений (или двух разных вхождений одного отношения), то его каноническое представление
может иметь вид имя поля op арифметическое выражение, где арифметическое выражение в правой
части включает только константы и второе имя поля (это тоже форма, полезная для выполнения
следующего шага оптимизации, - предикат соединения; особенно важен случай эквисоединения,
когда op - это равенство). Если в начальном представлении предикат имеет вид 5*A a*B op b, то его
каноническое представление - A op (b+a*B)/5.
Наконец, для рассматриваемых предикатов более общего вида имеет смысл приведение предиката к
каноническому представлению вида арифметическое выражение op константное арифметическое
выражение, где выражения правой и левой частей также приведены к каноническому
представлению; например, в выражениях полностью раскрыты скобки и произведено
лексикографическое упорядочение. В дальнейшем можно произвести поиск общих арифметических
выражений в разных предикатах запроса. Это оправдано, поскольку при выполнении запроса
вычисление арифметических выражений будет производиться при выборке каждого очередного
кортежа, т. е. потенциально большое число раз.
При приведении предикатов к каноническому представлению можно вычислять константные
выражения и избавляться от логических отрицаний.
Следующий класс логических преобразований связан с приведением к каноническому виду
логического выражения, задающего условие выборки запроса. Как правило, используются либо
дизъюнктивная, либо конъюнктивная нормальные формы. Выбор канонической формы зависит от
общей организации оптимизатора.
При приведении логического условия к каноническому представлению можно производить поиск
общих предикатов (они могут существовать изначально, могут появиться после приведения
предикатов к каноническому виду или в процессе нормализации логического условия) и упрощать
логическое выражение за счет, например, выявления конъюнкции взаимно противоречащих
предикатов. Фрагмент логического выражения ...(A>5)AND(A<5)... можно заменить на ...FALSE...
Возможны и более "умные" упрощения. Например, фрагмент логического выражения
...(A>B)AND(B=5)... можно заменить на ...(A>5)AND(B=5)... Такие упрощения могут оказаться
существенными для дальнейшей обработки запроса: в запросе с логическим условием первого вида
предполагалось соединение отношений; после преобразования запрос уже не требует соединения.
2.2. Преобразования запросов с изменением порядка реляционных операций
В традиционных оптимизаторах распространены логические преобразования, связанные с
изменением порядка выполнения реляционных операций. Примером соответствующего правила
преобразования в терминах реляционной алгебры может быть следующее (A и B - имена
отношений):
(A JOIN B) WHERE restriction-on-A
AND restriction-on-B
эквивалентно выражению
(A WHERE restriction-on-A) JOIN
(B WHERE restriction-on-B).
Здесь JOIN обозначает реляционный оператор естественного соединения отношений; A WHERE
restriction - оператор ограничения отношения A в соответствии с предикатом restriction.
Хотя немногие реляционные системы имеют языки запросов, основанные в чистом виде на
реляционной алгебре, правила преобразований алгебраических выражений могут быть полезны и в
других случаях. Довольно часто реляционная алгебра используется в качестве основы внутреннего
представления запроса. Естественно, что после этого можно выполнять и алгебраические
преобразования.
В частности, существуют подходы, связанные с преобразованием к алгебраической форме запросов
на языке SQL. Можно выявить две основные побудительные причины преобразований запросов на
SQL к алгебраической форме. Первой, на наш взгляд, менее важной может быть стремление к
использованию реляционной алгебры в качестве унифицированного внутреннего интерфейса
реляционной СУБД. Такой подход распространен при применении специализированных машин баз
данных, на основе которых реализуются различные интерфейсы доступа к базам данных. Интерфейс
машины баз данных должен быть унифицирован (например быть алгебраическим), а все остальные
интерфейсы, включая интерфейс на основе SQL, приводятся к алгебраическому.
Второй причиной, особенно важной в контексте проблем оптимизации, является то, что
реляционная алгебра более проста, чем язык SQL. Преобразование запроса к алгебраической форме
упрощает дальнейшие действия оптимизатора по выборке оптимальных планов. Вообще говоря,
развитый оптимизатор запросов системы, ориентированной на SQL, должен выявить все возможные
планы выполнения любого запроса, но "пространство поиска" этих планов в общем случае очень
велико; в каждом конкретном оптимизаторе используются свои эвристики для сокращения
пространства поиска. Некоторые, возможно, наиболее оптимальные планы никогда не будут
рассматриваться. Разумное преобразование запроса на SQL к алгебраическому представлению
сокращает пространство поиска планов выполнения запроса с гарантией того, что оптимальные
планы потеряны не будут.
2.3. Приведение запросов с вложенными подзапросами к запросам с соединениями
Основным отличием языка SQL от языка реляционной алгебры является возможность использовать
в логическом условии выборки предикаты, содержащие вложенные подзапросы. Глубина
вложенности не ограничивается языком, т. е., вообще говоря, может быть произвольной. Предикаты
с вложенными подзапросами при наличии общего синтаксиса могут обладать весьма различной
семантикой. Единственным общим для всех возможных семантик вложенных подзапросов
алгоритмом выполнения запроса является вычисление вложенного подзапроса всякий раз при
вычислении значения предиката. Поэтому естественно стремиться к такому преобразованию
запроса, содержащего предикаты с вложенными подзапросами, которое сделает семантику
подзапроса более явной, предоставив тем самым в дальнейшем оптимизатору возможность выбрать
способ выполнения запроса, наиболее точно соответствующий семантике подзапроса.
Ниже Ri обозначает i-е отношение базы данных; Ck - k-е поле (столбец) отношения.
Предикаты, допустимые в запросах языка SQL, можно разбить на следующие четыре группы.
1. Простые предикаты. Это предикаты вида Ri.Ck op X, где X - константа или список констант, и op
- оператор скалярного сравнения (=, <>, >, >=, <, <=) или оператор проверки вхождения в множество
(IS IN, IS NOT IN).
2. Предикаты с вложенными подзапросами. Это предикаты вида Ri.Ck op Q, где Q - блок запроса,
а op может быть таким же, как для простых предикатов. Предикат может также иметь вид Q op Ri.Ck.
В этом случае оператор принадлежности к множеству заменяется на CONTAINS или DOES NOT
CONTAIN. Эти две формы симметричны. Достаточно рассматривать только одну.
3. Предикаты соединения. Это предикаты вида Ri.Ck op Rj.Cn, где Ri ╢ Rj и op - оператор
скалярного сравнения.
4. Предикаты деления. Это предикаты вида Qi op Qj, где Qi и Qj - блоки запросов, а op может быть
оператором скалярного сравнения или оператором проверки вхождения в множество.
Приведенная классификация является упрощением реальной ситуации в SQL. Не рассматриваются
предикаты соединения общего вида, включающие арифметические выражения с полями более чем
двух отношений.
Каноническим представлением запроса на n отношениях называется запрос, содержащий n-1
предикат соединения и не содержащий предикатов с вложенными подзапросами. Фактически,
каноническая форма - это алгебраическое представление запроса.
Ниже приводятся два примера канонических форм запросов с предикатами разного типа.
Соответствующая техника существует и для других видов предикатов.
SELECT Ri.Ck FROM Ri WHERE Ri.Ch IS IN
SELECT Rj.Cm FROM Rj WHERE Ri.Cn = Rj.Cp
эквивалентно
SELECT Ri.Ck FROM Ri, Rj WHERE
Ri.Ch = Rj.Cm AND Ri.Cn = Rj.Cp
SELECT Ri.Ck FROM Ri WHERE
Ri.Ch =SELECT AVG (Rj.Cm) FROM Rj WHERE
Rj.Cn = Ri.Cp
эквивалентно
SELECT Ri.Ck FROM Ri, Rt WHERE
Ri.Ch = Rt.Cm AND Ri.Cp = Rt.Cn, где
Rt (Cp, Cn) = SELECT Rj.Cp, AVG (Rj.Cn) FROM Rj
GROUP BY Rj.Cp
Разумность таких преобразований обосновывается тем, что оптимизатор получает возможность
выбора большего числа способов выполнения запросов. Часто открывающиеся после
преобразований способы выполнения более эффективны, чем планы, используемые в традиционном
оптимизаторе System R.
При использовании в оптимизаторе запросов подобного подхода не обязательно производить
формальные преобразования запросов. Оптимизатор должен в большей степени использовать
семантику обрабатываемого запроса, а каким образом она будет распознаваться - это вопрос
техники.
Заметим, что в кратко описанном нами подходе имеются некоторые тонкие семантические
некорректности. Известны исправленные методы, но они слишком сложны технически, чтобы
рассматривать их в наших лекциях.
3. Семантическая оптимизация запросов
Рассмотренные преобразования запросов основывались на семантике языка запросов, но в них не
использовалась семантика базы данных, к которой адресуется запрос. Любое преобразование может
быть произведено независимо от того, какая конкретная база данных имеется в виду. На самом же
деле, при каждой истинно реляционной базе данных хранится и некоторая семантическая
информация, определяющая, например, целостность базы данных.
Если говорить о базах данных, поддерживаемых System R, то эта информация хранится в системных
каталогах базы данных в виде заданных ограничений целостности. Поскольку СУБД гарантирует
целостность базы данных, то ограничения целостности можно рассматривать как аксиомы, в
окружении которых формулируются запросы к базе данных.
3.1. Преобразования запросов на основе семантической информации
В качестве начальных примеров преобразований запросов на основе семантической информации
рассмотрим подходы известных СУБД System R и INGRES к обеспечению работы с базами данных
через представления. Эти преобразования не были ориентированы на оптимизацию запросов, но
имеют к ней непосредственное отношение.
Представление базы данных (view) в терминах языков SQL и QUEL - это именованный
каталогизированный запрос, представляющий собой, с точки зрения пользователей, такой же объект
базы данных, как и отношение. Представления могут использоваться в запросах так же, как и
хранимые отношения (с ограничениями на применение их в операторах модификации базы данных).
Семантика представлений требует, чтобы они были точными: в момент выполнения запроса над
представлением получаемая информация должна точно соответствовать текущему состоянию
хранимой части базы данных. Выполнение запроса над представлением требует его материализации,
т. е. вычисления отношения, определяемого запросом, который связан с представлением.
Подход System R и Ingres основан на том, что представления хранятся в каталогах базы данных во
внутренней форме, получаемой после выполнения грамматического разбора (а также, возможно,
логической оптимизации) соответствующего запроса. При обработке запроса над представлением до
выполнения фазы логической оптимизации производится слияние внутренних форм запроса и
представления. Образуется некоторая новая преобразованная внутренняя форма, и над ней
производится вся последующая обработка запроса, включая логическую оптимизацию и выбор
оптимального плана выполнения запроса. При этом оптимизатор получает больше информации о
данном запросе и может принимать более правильные решения. Приведем простой пример.
Пусть представление определено как
DEFINE VIEW V (C2) AS
SELECT C1 FROM R WHERE C1 > 6.
Запрос формулируется следующим образом:
SELECT C2 FROM V WHERE C2 < 6.
Если бы запрос компилировался в расчете на явную материализацию представления, был бы выбран
способ его выполнения, основанный на последовательном сканировании V с выбором кортежей,
удовлетворяющих условию. Запрос так бы и выполнялся, чтобы в конце концов выдать пустой
результат. При слиянии же внутренних форм запроса и представления мы получили бы внутреннюю
форму, эквивалентную запросу
SELECT C1 FROM R WHERE C1 < 6 AND C1 >6.
Уже на фазе логической оптимизации можно было бы установить, что он эквивалентен запросу
SELECT C1 FROM R WHERE FALSE,
из чего следовало бы, что результат запроса пуст.
Очевидно, что в ряде случаев этот способ обработки запросов над представлениями базы данных
позволяет добиться более эффективного выполнения запроса за счет предоставления оптимизатору
большей информации. Та же идея лежит и в основе семантической оптимизации запросов:
использование при оптимизации запроса семантической информации, хранящейся в базе данных
независимо от данного запроса.
Другим примером преобразований запросов, имеющих непосредственное отношение к оптимизации,
являются преобразования запросов на модификацию базы данных для удовлетворения
существующих в базе данных ограничений целостности. Этот подход впервые был применен в
СУБД INGRES, но используется и в других системах, например А в System R.
Ограничением целостности называется сохраняемое в каталогах базы данных логическое
выражение, составленное из предикатов над объектами базы данных. База данных находится в
целостном состоянии, если удовлетворяются все заданные ограничения целостности.
Если задан запрос на модификацию базы данных, включающей ограничения целостности,
удовлетворение которых требуется при выполнении любой модификации, то можно добавить
соответствующие ограничениям предикаты к логическому условию запроса.
Пусть база данных, характеризующая структуру организации, состоит из отношений EMP и DEPT. В
отношении EMP регистрируются служащие организации. Схема этого отношения EMP (EMP#,
EMPNAME, DEPT#); поле EMP# содержит уникальный номер служащего, поле EMPNAME - имя
служащего, а DEPT# - номер отдела организации, в котором работает данный сотрудник.
Отношение DEPT хранит информацию об отделах и имеет схему DEPT (DEPT#, EMPCOUNT), где в
поле EMPCOUNT хранится общее число сотрудников данного отдела. Пусть задано ограничение
целостности
ASSERT B IMMEDIATE ON EMP: EMP.DEPT# = 6.
Это ограничение означает запрещение занесения, удаления и модификации кортежей в отношении
EMP со значением поля DEPT#, отличным от 6. Пусть обрабатывается запрос на удаление кортежа
DELETE EMP WHERE EMPNAME = "Brown".
Если при компиляции запроса не учитывать наличие ограничения целостности, то корректным
способом выполнения такого запроса будет следующий: последовательно выбирать кортежи, у
которых значением поля EMPNAME является "Brown"; проверять удовлетворение очередного
кортежа ограничению целостности, и, если проверка удовлетворительна, удалить кортеж.
Если же ограничения целостности учитываются при компиляции, то можно слить внутренние
формы запроса и соответствующих ограничений целостности, а потом произвести совместную
оптимизацию. В нашем случае после слияния образуется внутренняя форма, эквивалентная запросу
DELETE EMP WHERE EMPNAME = "Brown" AND DEPT# = 6.
При выполнении такого запроса не понадобятся дополнительные вызовы проверок ограничений
целостности второго типа, поскольку они все уже включены в логическое условие выполнения
операции удаления. Кроме того, оптимизатор получает большую свободу в выборе способа
выполнения запроса. Например, если отделы малочисленны и для отношения EMP поддерживается
индекс на поле DEPT#, то, возможно, наиболее оптимальным способом выполнения запроса будет
сканирование отношения через индекс по DEPT# с условием DEPT# = 6 с удалением всякого
выбираемого таким образом кортежа со значением поля EMPNAME, равным "Brown". Тем самым
преобразующие запрос действия, не направленные специально на оптимизацию, могут
способствовать более эффективному выполнению запроса. Эффективность выполнения запроса
удается повысить за счет использования знаний, независимо хранящихся в базе данных.
Рассмотренные примеры показывают, что идея семантической оптимизации в принципе не нова.
Имеется и принципиальная разница между рассмотренными выше преобразованиями запросов и
теми, которые производятся при семантической оптимизации. Основное отличие состоит в том, что
когда производятся слияния внутренней формы запроса с внутренней формой представления или
внутренними формами ограничений целостности, мы обязаны полностью и однозначно
использовать внешнюю информацию, независимо от того, будет ли это способствовать оптимизации
запроса: условие выборки представления должно быть целиком добавлено через AND к условию
выборки запроса; то же относится и к набору логических условий ограничений целостности. Иначе
семантика запроса над представлением или оператора модификации базы данных будет нарушена.
3.2. Использование семантической информации при оптимизации запросов
Семантическая оптимизация основана на наличии в базе данных семантической информации,
которую необязательно использовать при обработке запроса, но применение которой может
привести к его более оптимальному выполнению. Если семантическая оптимизация имеет дело
только со знаниями, представленными в виде ограничений целостности базы данных, то при
семантической оптимизации производится множество преобразованных внутренних представлений
запроса; при каждом преобразовании используется некоторый поднабор ограничений целостности.
Если, например, в базе данных определены два ограничения целостности A и B с логическими
условиями F1 и F2 и обрабатывается запрос с условием выборки F, то в ходе семантической
оптимизации будут получены внутренние представления, эквивалентные запросам с условиями F, F
AND F1, F AND F2 и F AND F1 AND F2.
Каждое из полученных внутренних представлений подвергается полной дальнейшей обработке,
включая логическую оптимизацию и выбор оптимального плана выполнения; из полученных планов
(все они семантически эквивалентны, т. е. вырабатывают один и тот же результат) выбирается
наиболее дешевый, который и становится реальным планом выполнения исходного запроса.
Для разумного применения семантической оптимизации удобно представлять ограничения
целостности базы данных в импликативной форме. Тогда можно добиться более осмысленного
порядка преобразований. Пусть, например, в нашей базе данных о структуре организации
отношение EPM расширено полями STATUS и SALARY. Значения поля STATUS характеризуют
должность служащего, а поле SALARY - его оклад. Может быть наложено ограничение
целостности, выражающееся в том, что оклад, превышающий 40000, допустим только для
начальников отделов:
ASSERT A ON EMP:
IF SALARY > 40.000 THEN STATUS = "Manager".
Предположим, что обрабатывается запрос
SELECT EMPNAME, STATUS FROM EMP
WHERE SALARY = 20.000.
Если не учитывать импликативного характера ограничения целостности, то по общим правилам
будет произведено слияние внутренних представлений запроса и ограничения целостности, которое
заведомо ничего не даст. Если же рассматривать ограничение целостности как правило
преобразования, а левую часть импликации - как условие применения правила, то слияние
производиться и не будет, что в общем случае сэкономит время обработки запроса. Но для запроса
SELECT EMPNAME, STATUS FROM EMP
WHERE SALARY > 40.000
правило преобразования применимо и приводит к семантически эквивалентному запросу
SELECT EMPNAME, STATUS FROM EMP
WHERE STATUS = "Manager",
выполнение которого может быть более эффективным.
После преобразования запроса в соответствии с некоторым правилом к полученному представлению
может оказаться применимым другое правило и т. д. Возможно появление циклов преобразований.
Проблема построения полного набора семантически эквивалентных представлений запроса на
основе заданного набора правил в общем случае является весьма сложной. Точное решение этой
проблемы может потребовать затрат, соизмеримых с затратами на выполнение запроса по наиболее
оптимальному плану. Поэтому, вообще говоря, необходимо применение эвристических алгоритмов,
сокращающих пространство поиска, т. е. задающих условие прекращения генерации новых
представлений. Эвристики основываются на минимизации взвешенной суммы стоимостей
семантической оптимизации и выполнения запроса. Примером грубой эвристики может быть
следующий: оптимизация производится до тех пор, пока затраты на нее не превзойдут оценочную
стоимость наиболее эффективного из всех найденных планов выполнения запроса.
2. Резервное копирование и восстановление базы данных (структуры,
используемые для восстановления)в Oracle.( Физическое копирование и
восстановление.doc)
Билет №18
1. Основные этапы восстановления базы данных в Oracle.
( Физическое копирование и восстановление.doc)
2.
Основные программные конструкции PL/SQL.