ПО SQL*Net устанавливается на обеих машинах "поверх" сетевого программного обеспечения.

Опции SQL*Net позволяют одной машине работать с одним сетевым протоколом, сообщаясь с другой машиной, работающей с другим протоколом.

При изменениях сетевых протоколов или сетевого ПО не придется изменять программное обеспечение прикладной системы. При необходимости можно выполнить изменения, установив другую версию SQL*Net для нового сетевого протокола.

На следующем рисунке показано место SQL*Net в среде клиент/сервер с двумя серверами базы данных.

10. Файлы Oracle

10.1 Файлы базы данных

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

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

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

10.2 Управляющие файлы

Любая база данных должна иметь по крайней мере один управляющий файл, хотя обычно создают, несколько, чтобы защититься от потерь. В управляющий файл записываются имя базы данных, дата и время ее создания, расположение базы данных и журнальных файлов и информация синхронизации, чтобы гарантировать согласованность всех трех групп файлов БД. При добавлении к базе данных нового файла данных или журнального файла информация будет зарегистрирована в управляющих файлах.

10.3 Журнальные файлы

Каждая база данных должна иметь по крайней мере два журнальных файла. Это -- журналы базы данных; в этих файлах записываются все изменения пользовательских и системных объектов. Если происходит какой-либо сбой, например, потеря одного (или больше) файлов базы данных, можно, используя изменения, записанные в журнальных файлах, привести базу данных к непротиворечивому состоянию без потери фиксированных транзакций. В случае сбоя, не связанного с потерей данных, такого как аварийный отказ ЭВМ, Oracle может воспользоваться информацией из журнального файла для автоматического восстановления без вмешательства администратора базы данных (DBA). Фоновый процесс SMON автоматически повторно выполняет зафиксированные в журнальных файлах изменения в файлах базы данных.

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

10.3.1 Оперативные журнальные файлы

Оперативные журнальные файлы -- два или больше журнальных файла, которые всегда используются во время работы экземпляра Oracle. Изменения в БД регистрируются в каждом из журнальных файлов поочередно. Когда один из них заполняется, вывод журнала переключается на другой; когда этот заполняется, происходит переключение на первый, и цикл продолжается.

10.3.2 Автономные/архивные журнальные файлы

Автономные или архивные журнальные файлы -- точные копии заполненных оперативных журнальных файлов; создавать их необязательно. Oracle создает их, только когда база данных обрабатывается в режиме ARCHIVELOG. Если база данных работает в режиме ARCHIVELOG, активизируется фоновый процесс ARCH и копирует заполненный оперативный журнальный файл в автономный приемник (обычно на другом дисководе). Во время этого копирования Oracle использует другой оперативный журнальный файл. Если имеется полный набор автономных журнальных файлов с момента выполнения последней резервной копии БД значит есть полная запись проведенных изменений. Если потерян один или больше файлов данных, можно воспользоваться этой записью, чтобы повторить изменения в БД, восстановленной с резервной копии.

10.4 Другие файлы поддержки

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

На некоторых платформах Oracle также создается файл SGAPAD, который содержит адрес начала области Oracle SGA.

10.5 Системные и пользовательские процессы

Рассмотрим некоторые системные процессы Oracle, которые должны выполняться для поддержания работоспособности базы данных, в том числе необязательные процессы и процессы, создающиеся для поддержки подключения к базе данных Oracle.

10.5.1 Обязательные системные процессы

К четырем системным процессам Oracle, которые должны быть всегда активными и выполняться, чтобы СУБД могла работать, относятся DBWR, LGWR, SMON и PMON.

10.5.2 DBWR - процесс записи в БД

Фоновый процесс записи в БД переписывает модифицированные блоки БД из SGA в файлы базы данных. Он записывает только модифицированные блоки (например, блок содержит новую, удаленную или измененную запись). DBWR сначала записывает наиболее давно использовавшиеся блоки. Они не обязательно записываются в базу данных при фиксации транзакции; единственная процедура, которая всегда выполняется при фиксации транзакции - регистрация и запись изменений в оперативные журнальные файлы. Блоки базы данных будут записываться позже, когда в SGA не хватит свободных буферов для размещения нового блока.

LGWR - процесс записи в журнал

Процесс записи в журнал переписывает элементы журнального буфера SGA для одной или больше транзакций в оперативные журнальные файлы. Например, при фиксации транзакции этот процесс должен записать элементы буфера в журнальные файлы на диске, и только потом пользовательский процесс получит сообщение, указывающее, что фиксация транзакции прошла успешно. После фиксации транзакции изменения записаны на диск, даже если измененные блоки базы данных все еще находятся в буфере SGA и ожидают записи процессом DBWR. SMON может всегда повторить изменения по журнальным файлам, если более актуальная копия базы данных потеряна.

10.5.3 SMON - системный монитор

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

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

Когда СУБД простаивает, SMON дефрагментирует свободное пространство в файлах базы данных, подготавливая распределение внешней памяти под новые объекты или для расширения существующих объектов базы данных.

Кроме того, SMON автоматически восстанавливает при запуске ненормально остановленный экземпляр Oracle (если нет потерянных файлов). Не выдается никаких сообщений, указывающих, что выполняется восстановление экземпляра, просто запуск займет больше времени.

10.5.4 PMON - монитор процессов

Монитор процессов контролирует пользовательские процессы. Если происходит какой-либо сбой пользовательского процесса (например, если процесс уничтожен в середине транзакции), PMON выполняет автоматический откат к! началу транзакции (отменяя все, начиная с последнего COMMIT или ROLLBACK). При этом освобождаются все блокировки и другие ресурсы системы, занятые отказавшим процессом. PMON также контролирует процесс диспетчера и процесс разделения сервера, которые являются частью СУБД многопотокового сервера, и перезапускает их, если они "зависли"

10.5.5 Необязательные системные процессы

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

10.5.6 ARCH - архиватор

Когда база данных работает в режиме ARCHFVELOG и запушен фоновый процесс-архиватор, последний выполняет копирование одного из оперативных журнальных файлов в файл-архив (точное расположение указывается в параметре INIT.ORA). Таким образом можно получить полную хронологию изменений, проведенных в файлах базы данных, записанную в архивном и оперативном журнальных файлах.

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

10.5.7 СКРТ-процесс выполнения контрольных точек

Событие "контрольная точка" происходит после заполнения одного из оперативных журнальных файлов; позже этот файл будет перезаписан, когда другие оперативные журнальные файлы заполнятся. Если журнальный файл перезаписывается, изменения, зарегистрированные в этом файле, становятся недоступными для использования в случае сбоя системы. В контрольной точке измененные блоки буферов базы данных записываются в файлы базы данных на диск фоновым процессом DBWR. Это означает, что в случае сбоя системы с утратой областей памяти для восстановления журнал изменений не понадобится. После выполнения контрольной точки журнальный файл можно перезаписывать.

В контрольной точке обновляются все заголовки файлов данных и заголовки журнальных файлов, чтобы зафиксировать сам факт выполнения контрольной точки. Фоновый процесс LGWR выполняет эту задачу обновления, которая может потребовать больших затрат времени, если имеется большое количество файлов данных и журнальных файлов. В этом случае вся СУБД будет ожидать завершения выполнения контрольной точки, прежде чем в журнальные файлы смогут записываться дальнейшие изменения базы данных.

Чтобы сократить время, которое требуется LGWR для модификации заголовков файлов, можно запустить СКРТ -- процесс выполнения контрольных точек.

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

Независимо от того, запущен или нет фоновый процесс СКРТ, контрольная точка выполняется, при заполнении одного из журнальных файлов.

10.5.8 RECO - процесс восстановления

Фоновый процесс восстановления запускается, если происходит сбой в распределенной транзакции (транзакция, в которой изменяются две или больше базы данных) и одна или больше баз данных требуют выполнить или фиксацию, или откат транзакции. RECO, если он запущен, пытается автоматически фиксировать или откатить транзакцию на локальной базе данных синхронно с процессами RECO на других базах данных. Oracle.

Не нужно запускать фоновый процесс восстановления, если не используются распределенные транзакции.

10.5.9 LCK - процесс блокировки

Фоновый процесс блокировки используется в параллельном сервере Oracle, где с одним набором файлов базы данных работает несколько экземпляров. Процессы LCK, работая на всех экземплярах, синхронизируют блокировки БД между экземплярами. Если пользователь подключился к одному экземпляру и блокирует строку, строка блокируется и для пользователя, пытающегося изменить ее другим экземпляром. Пользователи всегда могут выполнять чтение строк независимо от того, блокированы ли эти строки другими пользователями.

Может быть запущено до 10 фоновых процессов LCK, чтобы расшить узкое место синхронизации блокировок, однако одного обычно оказывается достаточно.

Не нужно запускать фоновые процессы LCK, если не используется параллельный сервер Oracle.

10.5.10 Listener - процесс прослушивания сети ("слушатель")

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

Например, взаимодействие между машиной-клиентом, выполняющей приложение на PC с Windows, и сервером базы данных на UNIX машине с сетевым протокол TCP/IP, осуществлялось бы следующим образом:

1) Машина-клиент посылает оператор запроса SQL для выполнения к UNIX машине сервера базы данных.

2) He-Oracle процесс-слушатель TCP/IP получает запрос и распознает его как запрос для Oracle.

3) Запрос посылается слушателю Oracle Listener, который направляет запрос к соответствующему экземпляру на машине. (Машина могла бы выполнять много экземпляров для многих различных баз данных.)

4) Процесс экземпляра выполняет оператор.

5) Результаты затем посылаются обратно по сетевой связи машине-клиенту.

Слушатель Listener обрабатывает запросы для всех экземпляров, выполняющихся на машине. Можно запускать несколько слушателей, но это делают редко.

10.5.11 Пользовательские процессы

Пользовательские процессы логически состоят из двух частей: кода сервера Oracle, который транслирует и выполняет операторы SQL и читает файлы и области памяти базы данных, и инструментальной части, которая является исполняемым кодом используемого программного инструмента. Код сервера иногда называют кодом ядра Oracle.

Пользовательские процессы в Oracle можно определять три различных конфигурации - однозадачная, с выделенным сервером и с многопотоковым сервером. Эти конфигурации могут совместно применяться для одного экземпляра.

10.5.12 Однозадачная конфигурация

В этом случае инструментальный код и код сервера базы данных сконфигурированы в один процесс. Каждое подключение к базе данных -- это один пользовательский процесс, выполняемый на машине. Эта конфигурация является стандартной для платформы VAX/VMS без среды клиент/сервер.

10.5.13 Конфигурация с выделенным сервером

В конфигурации с выделенным сервером (ее также называют двухзадачной) две части пользовательского процесса реализованы как два отдельных процесса, выполняемых на машине. Они поддерживают связь один с другим, используя механизмы межпроцессной связи ОС. Каждое подключение к базе данных требует работы двух процессов, выполняемых на машине. Программное обеспечение ядра Oracle в одном процессе иногда называют "теневым процессом".

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

Конфигурация с выделенным сервером может быть довольно расточительна, поскольку память расходуется на теневой процесс и количество процессов на машине возрастает, даже когда пользователь не дает каких-либо запросов к базе данных. Выделенный сервер (теневой процесс) обрабатывает запросы только одного процесса-клиента.

10.5.14 MTS (Multi-Threaded Server) - многопотоковый сервер

Конфигурация с многопотоковым сервером позволяет одному процессу сервера Oracle выполнять работу для многих пользовательских процессов. Таким образом преодолеваются недостатки конфигурации с выделенным сервером. Уменьшается количество процессов и объем занятой памяти, улучшается общая производительность системы. В конфигурации MTS появляются два новых типа системных процессов.

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

10.5.15 Процессы-диспетчеры

Один или несколько процессов-диспетчеров принимают запросы процессов-клиентов от слушателя Listener и направляют запрос к одному из процессов разделяемого сервера. Слушатель Listener требуется для конфигурации MTS, даже когда сеть не используется.

Нужно включить в конфигурацию по крайней мере один процесс-диспетчер для каждого используемого сетевого протокола, чтобы направлять запросы к экземпляру. Количество диспетчеров не увеличивается при увеличении загрузки системы, так как диспетчеры только обеспечивают маршрутизацию. Фактическая работа выполняется разделяемыми серверами.

10.5.16 Процессы разделяемого сервера

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

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

11. Оперативная память Oracle

Чем больше объем памяти, доступной Oracle, тем быстрее работает система.

11.1 Системная глобальная область (SGA)

Системная глобальная область (иногда называемая разделяемой глобальной областью) выделяется в ОЗУ для данных и управляющих структур. Она разделяется (совместно используется) всеми фоновыми и пользовательскими процессами Oracle, образующими данный экземпляр. Каждый экземпляр Oracle имеет собственную SGA; фактически SGA и фоновые процессы образуют экземпляр. Область памяти SGA выделяется при запуске и освобождается при останове экземпляра.

Содержимое SGA делится на три основные области: кэш буферов данных, область разделяемого пула и журнальный кэш. Размер каждой области управляется параметрами в файле INIT.ORA. Чем большего размера SGA можно организовать и чем большая часть ее может поместиться в реальную память машины, тем быстрее будет работать экземпляр.

11.1.1 Кэш буферов данных

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

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

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

Чем больше блоков данных помещается в реальной памяти, тем быстрее выполняется экземпляр.

11.1.2 Журнальный кэш

В оперативные журнальные файлы записываются все изменения пользовательских и системных объектов. До того как изменения записываются в журнал, Oracle хранит их в области журнального кэша. Например; элементы журнала переписываются из кэша в оперативные журнальные файлы, когда кэш заполняется или когда транзакция фиксируется. Элементы журнала для нескольких транзакций могут быть записаны в журнальный файл за одно обращение к диску.

Фоновый процесс LGWR - единственный процесс, который переписывает элементы журнала из кэша в оперативные журнальные файлы.

11.1.3 Область разделяемого пула

Область разделяемого пула SGA имеет два основных компонента: область SQL и кэш словаря. Изменять размер этих двух компонентов можно, только изменяя размер всей области разделяемого пула.

11.1.4 Область SQL

Оператор SQL, переданный для выполнения серверу базы данных, должен быть подвергнут грамматическому разбору, прежде чем он может быть выполнен. Область SQL в SGA содержит данные привязки, временные буферы, дерево разбора и план выполнения для каждого оператора SQL, переданного серверу базы данных. Так как область разделяемого пула имеет фиксированный размер, возможно, в ней не поместится весь набор операторов, которые выполнены с момента запуска экземпляра; Oracle может удалять некоторые операторы, с целью освобождения места для других.

Если пользователь выполняет оператор SQL, последний занимает память в области SQL. Если другой пользователь выполняет точно такой же оператор с теми же объектами, Oracle не производит повторно разбор второго оператора, поскольку дерево разбора и план выполнения уже есть в области SQL. Область SQL также используется для хранения в разобранной, скомпилированной форме блоков PL/SQL, которые могут разделяться пользовательскими процессами одного экземпляра.

11.1.5 Кэш словаря

Кэш словаря в области разделяемого пула содержит фрагменты системных таблиц Oracle. Системные таблицы Oracle называются "словарем данных" Oracle. Словарь данных -- набор таблиц, размешенных в файлах базы данных, и так как Oracle часто обращается к этим файлам, создастся отдельная область памяти, чтобы избежать дискового ввода/вывода.

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

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

11.1.6 Глобальная область процесса

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

Фактическое содержимое PGA зависит от того, используется ли конфигурация с многопотоковым сервером, но обычно она представляет собой область памяти, в которой хранятся переменные сеанса, массивы, некоторые строки результат и другая информация. Если используется многопотоковый сервер, часть информации, которая обычно содержится в PGA, помещается в общую SGA.

Размер PGA зависит от. операционной системы, используемой для работы экземпляра Oracle, и после выделения PGA не изменяется. Память, используемая PGA, не увеличивается пропорционально объему обработки, выполняемой в пользовательском процессе. Администратор базы данных может управлять размером PGA, изменяя некоторые параметры в файле параметров экземпляра INIT.ORA; одним из параметров, который DBA часто изменяют, является SORT_AREA_SIZE.

11.1.7 Программы Oracle

Работа сервера Oracle не зависит от того, какой инструмент используется в качестве внешнего интерфейса (например, SQL*Plus или Excel). На некоторых платформах код сервера загружается в память машины только однажды, и все процессы, использующие экземпляр, могут его разделять. Этот код ядра является реентерабельным, что экономит память, поскольку достаточно держать в ОЗУ только одну копию кода.

12. Внешняя память Oracle

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

12.1 Табличные пространства и файлы базы данных

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

Табличное пространство - логический раздел базы данных, состоящий из одного или больше физических файлов базы данных.

В каждой базе данных Oracle есть табличное пространство с именем SYSTEM, с которым связывается самый первый файл базы данных. В табличное пространство SYSTEM по умолчанию помещаются все объекты при создании базы данных. Самая простая конфигурация базы данных -- один файл базы данных в табличном пространстве SYSTEM (простая, но не самая хорошая).

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

Когда создаются объекты (такие как таблицы), которые хранятся в базе данных, можно задать табличное пространство для размещения объекта как часть оператора CREATE для объекта. В табличном пространстве SYSTEM следует хранить только системные таблицы, например, tab$, col$, ind$ и fet$.

Такие объекты, как синонимы и представления, не занимают места в базе данных, кроме места в таблице словаря данных, где хранятся их определения наряду с определениями всех других типов объектов.

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

Табличное пространств»» SYSTEM не может быть удалено; это уничтожило бы базу данных, Поскольку там располагаются системные таблицы. Также нельзя перевести табличное пространство SYSTEM в автономный режим.

12.1.1 Сегменты

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

12.1.2 Экстенты

Внешняя память для какого-либо объекта в базе данных выделяется порциями из определенного числа блоков. В файлах базы данных эти блоки должны быть смежными. Группа смежных блоков называется экстентом. Например, когда создается таблица с использованием установок по умолчанию, для самого первого экстента таблицы распределяется пять блоков Oracle (начальный экстент). По мере добавления и модификации строк в таблице пять блоков заполняются данными. Если последний блок заполнен, и должны быть вставлены новые строки, база данных автоматически выделяет для таблицы новый набор блоков (пять блоков), и новые строки вставляются в новый набор блоков. Это выделение дополнительных областей хранения (дополнительных экстентов) продолжается до тех пор, пока не будет исчерпано свободное место в табличном пространстве. Таблица начинается с одного начального экстента и затем выделяется другой (вторичный) экстент. Блоки экстента должны быть смежными в файле.

После того как экстент выделен сегменту (таблице), эти блоки не могут использоваться другим объектом базы данных, даже если все строки таблицы удалены. Таблицу нужно уничтожить (drop) или очистить (truncate), чтобы освободить внешнюю память, выделенную данной таблице. Исключение из этого правила - сегменты отката, которые могут динамически освобождать выделенною ям память.

12.1.3 Блоки Oracle

Oracle "разбивает" файлы базы данных при их первоначальном создании на блоки Oracle. В результате для программного обеспечения СУБД упрощается работа с файлами и чтение данных в области оперативной памяти.

Эти блоки обычно имеют размер 1 KB (значение по умолчанию для системы PC-DOS), 2 KB (значение по умолчанию для большинства UNIX машин и VAX/VMS), 4 KB (значение по умолчанию для мэйнфреймов типа IBM) или больше. Файл базы данных размером 50 MB содержал бы 25600 блоков Oracle, при размере блока в 2 KB (50 МВ/2 KB).

Размер блока должен быть кратен размеру блока операционной системы. Независимо от размера блока не весь блок доступен для хранения данных; Oracle занимает некоторое пространство под заголовок для управления содержимым блока. Этот заголовок блока имеет минимальный размер, но он может увеличиваться.

Блоки Oracle -- наименьшая единица внешней памяти. Увеличение размера блока Oracle может улучшать производительность; он задается только при создании базы данных.

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

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

12.1.4 ROWID - идентификатор строки

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

ROWID состоит из следующих трех компонентов, комбинация которых уникально идентифицирует физическое расположение строки:

* номер файла базы данных Oracle, который содержит блок со строкой

* номер блока Oracle, который содержит строку

* номер строки внутри блока (так как каждый блок может содержать много строк)

СУБД использует ROWID в индексах для быстрого отбора строк с указанным значением ключа. Разработчики приложений также используют его в операторах SQL как быстрый способ обращения к строке, если известен ее ROWID.

12.1.5 Свободное пространство и автоматическая организация непрерывных участков

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

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

13. Системные объекты базы данных

13.1 Словарь данных

Первыми таблицами, создаваемыми в любой базе данных, являются системные таблицы, или словарь данных Oracle. Эти таблицы относятся к первому пользовательскому учетному разделу Oracle, который создается автоматически для пользователя с именем SYS. Системные таблицы хранят информацию о структуре базы данных и объектов внутри нее, и Oracle обращается к ним, когда нуждается в информации о базе данных или когда выполняет оператор DDL (Data Definition Language -- язык определения данных) либо оператор DML (Data Manipulation. Language - язык манипулирования данными). Эти таблицы никогда непосредственно не обновляются, однако обновление в них происходит, в фоновом режиме всякий раз, когда выполняется оператор DDL.

Главные таблицы словаря данных содержат нормализованную информацию, которая является довольно трудной для восприятия человеком, так что в Oracle предусмотрен набок представлений, выдающих информацию главных системных таблиц в более понятном виде. Просмотреть имена более чем 170 представлений, в словаре данных можно с помощью команды SELECT * FROM DICT;

Oracle запрашивает информацию из таблиц словаря данных для синтаксического разбора любого оператора SQL. Информация кэшируется в области словаря данных разделяемого пула в SGA.

Так как первым создается табличное пространство SYSTEM, таблицы словаря данных записываются в файлы базы данных, связанные с табличным пространством SYSTEM.

13.2 Сегменты отката

Когда данные в Oracle изменяются, изменение должно быть или подтверждено, или отменено. Если изменение отменяется ("откатывается назад"), содержимое блоков данных восстанавливается в исходное состояние, существовавшее до изменения. Сегменты отката -- это системные объекты, которые поддерживают этот процесс. Всякий раз, когда осуществляются какие-либо изменения в таблицах приложения или в системных таблицах, в сегмент отката автоматически помещается предыдущая версия изменяемых данных, так что старая версия данных всегда доступна, если требуется откат.

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

Сегменты отката всегда принадлежат пользователю SYS, и никакой пользователь Oracle не может обратиться к ним с целью просмотра.

Сегменты отката получают внешнюю память таким же образом, как другие сегменты -- экстентами. Сегменту отката, однако, нужно первоначально распределить минимум два экстента. Первый сегмент отката создается автоматически, когда создается база данных, имеет имя SYSTEM и использует табличное пространство SYSTEM.

13.3 Временные сегменты

Временные сегменты используют пространство в файлах базы данных, чтобы создать временную рабочую область для промежуточных стадий обработки SQL и для больших/операций сортировки,

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

Ниже приводятся операции, которые могут приводить к созданию временных сегментов Oracle:

- Создание индекса

- Использование предложений ORDER BY, DISTINCT или GROUP BY в операторе SELECT

- Использование операторов работы с множествами UNION, INTERSECT, MINUS

- Создание соединений таблиц

- Использование некоторых подзапросов

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

13.4 Сегмент начальной загрузки/кэша

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

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

14. Защита данных

14.1 Транзакции, фиксация и откат

Изменения в базе данных не сохраняются, пока пользователь явно не укажет, что результаты вставки, модификации и удаления должны быть зафиксированы окончательно. Вплоть до этого момента изменения находятся в отложенном состоянии, и какие-либо сбои, подобные аварийному отказу машины, аннулируют изменения.

Транзакция - элементарная единица работы, состоящая из одного или нескольких операторов SQL; она начинается, когда пользователе подключается к базе данных, и завершается, когда вводится оператор COMMIT или ROLLBACK. После выполнения операторов COMMIT или ROLLBACK автоматически начинается следующая транзакция. Все результаты транзакции или целиком сохраняются (фиксируются), или целиком отменяются (откатываются назад).

Фиксация транзакции делает изменения окончательными, занося их в базу данных, и после того как транзакция фиксируется, изменения не могут быть отменены. Откат отменяет все вставки, модификации и удаления, сделанные в транзакции; после отката транзакции ее изменения не могут быть зафиксированы. Процесс фиксации транзакции подразумевает запись изменений, занесенных в журнальный кэш SGA, в оперативные журнальные файлы на диске. Если этот дисковый ввод/вывод успешен, приложение получает сообщение об успешной фиксации транзакции. (Текст сообщения изменяется в зависимости от инструментального средства.) Фоновый процесс DBWR может записывать блоки актуальных данных Oracle в буферный кэш SGA базы данных позже. В случае сбоя системы Oracle может автоматически повторить изменения из журнальных файлов, даже если блоки данных Oracle не были перед сбоем записаны в файлы базы данных.

Oracle также реализует идею отката на уровне оператора. Если произойдет единственный сбой при выполнении оператора, весь оператор завершится неудачей. Другими словами, оператор INSERT для 1000 строк вставит или все 1000 строк или не вставит вообще ни одной; весь оператор или выполнится или нет. Если оператор терпит неудачу в пределах транзакции, остальные операторы транзакции будут находиться в отложенном состоянии и должны либо фиксироваться, либо откатываться.

Если пользовательский процесс завершается ненормально (например, процесс уничтожен), фоновый процесс PMON автоматически откатывает изменения. Какие-либо изменения, которые процесс зафиксировал до момента сбоя, остаются фиксированными, и только изменения для текущей транзакции откатываются.

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

Точки сохранения позволяют устанавливать маркеры внутри транзакции таким образом, чтобы имелась возможность отмены только части работы, проделанной в транзакции. Целесообразно использовать точки сохранения в длинных и сложных транзакциях, чтобы обеспечить возможность отмены изменения для определенных операторов. Однако это обусловливает дополнительные затраты ресурсов системы -- оператор выполняет работу, а изменения затем отменяются; обычно усовершенствование в логике обработки могут оказаться более оптимальным решением. Oracle освобождает блокировки, захваченные отмененными операторами.

14.2 Целостность данных

Целостность данных связана с определением правил проверки достоверности данных (таких как "процентное значение должно находиться между 0 и 100") гарантирующих, что недействительные данные не попадут в таблицы. Раньше эти правила устанавливались непосредственно прикладными программами (и одни и те же правила проверялись неоднократно в различных программах). Oracle, однако, позволяет определять и хранить эти правила для объектов базы данных, которых они касаются, таким образом, чтобы кодировать их только однажды. При этом они активируются всякий раз, когда какой-либо вид изменения проводится в таблице, независимо от того, какая программа выполняет вставки, модификации или удаления. Этот контроль осуществляется в форме ограничений целостности и триггеров базы данных.

14.2.1 Ограничения целостности

Ограничения целостности устанавливают бизнес-правила на уровне базы данных, определяя набор проверок для таблиц системы. Эти проверки автоматически выполняются всякий раз, когда вызываются оператор вставки, модификации или удаления данных в таблице. Если какие-либо ограничения нарушены, операторы отменяются. Другие операторы транзакции остаются в отложенном состоянии и могут фиксироваться или отменяться согласно логике приложения.

Поскольку ограничения целостности проверяются на уровне базы данных, они выполняются независимо от того, откуда были инициированы операторы вставки, модификации или удаления. Определение проверок через эти ограничения также выполняется быстрее, чем при использовании SQL. Кроме того, информация, вводимая при объявлении ограничений, используется оптимизатором Oracle для принятия решений о том, как выполнить оператор для данной таблицы.

Для таблицы можно задавать следующие типы ограничений целостности: NOT NULL, PRIMARY KEY, UNIQUE, FOREIGN KEY, CHECK и индексы.

14.2.2 Ограничения NOT NULL (не пусто)

Ограничение NOT NULL устанавливается для столбца, чтобы указать, что столбец должен иметь значение в каждой строке; он никогда не может быть пустым. По умолчанию все столбцы в таблице могут быть пустыми. Например, при помощи NOT NULL для таблицы заказов можно указать, что должен быть всегда определен объем заказа.

14.2.3 PRIMARY KEY (первичный ключ)

Ограничение PRIMARY KEY определяет столбец или группу столбцов, которую можно использовать для уникальной идентификации строки. Никакие две строки в таблице не могут иметь одинаковых значений столбцов первичного ключа. Кроме того, столбцы первичного ключа должны всегда содержать значение. Другими словами, они -- NOT NULL. Если налагается ограничение на таблицу после ее создания, столбцы, которые формируют ограничение PRIMARY KEY, изменяются на NOT NULL. Для таблицы может быть задан только один первичный ключ PRIMARY KEY. Например, введя ограничение PRIMARY KEY для таблицы заказов, указывается, что таблица не может иметь две записи с одним номером заказа.

14.2.4 UNIQUE (уникальный)

Ограничение UNIQUE определяет вторичный ключ для таблицы. Это -- столбец или группа столбцов, которую можно использовать, как другой способ уникальной идентификации строки. Никакие две строки не могут иметь одинаковых значений для столбца или столбцов ключа UNIQUE. Хотя таблица не может иметь более одного первичного ключа, на нее можно наложить несколько ограничений UNIQUE.

Столбцы для ограничения UNIQUE не обязательно должны быть NOT NULL (хотя как правило гак и есть). Если значения для каких-либо столбцов, которые формируют уникальное ограничение, пустые, ограничение не проверяется. Например, при использовании ограничения PRIMARY KEY и UNIQUE для таблицы заказчиков можно указать, что номер заказчика - первичный ключ и имя заказчика является уникальным ключом (это подразумевало бы, что нельзя иметь в таблице двух заказчиков с одинаковыми именами.

14.2.5 FOREIGN KEY (внешний ключ)

FOREIGN KEY, или ограничение ссылочной целостности, устанавливает целостность отношений между таблицами. Оно требует, что бы столбец или набор столбцов в одной таблице совпадал с первичным или вторичным ключом другой таблицы. Например, можно установить ограничение. FOREIGN KEY для таблицы заказов, чтобы специфицировать, что всякий раз, когда вставляется или обновляется запись заказа, номер заказчика должен также существовать в таблице заказчиков. Это гарантирует, что не введутся заказы для несуществующих заказчиков.

Ограничения FOREIGN KEY используются для установления отношений родитель/потомок между таблицами. Можно даже использовать их, чтобы установить ограничения "ссылка на себя", обычно в ситуациях, где иерархическая структура создается на строках, хранимых в одной таблице. Если какие-либо столбцы внешнего ключа пусты, ограничение вообще не проверяется. Столбцы внешнего ключа обычно объявляются как NOT NULL.

Можно указать серверу БД, что когда родительская строка удаляется, удаление должно автоматически каскадироваться и должны удаляться строки потомка. Это -- опасная ситуация. Пользователь информируется только об удалении главных строк, и он может не знать о дополнительных строках, которые были удалены автоматически в фоновом режиме, так как ему ничто не указывает, что это каскадное удаление произошло.

Подобное автоматическое удаление строк потомка поддерживается, только если задано предложение ON DELETE CASCADE в конце оператора создания внешнего ключа. Однако если изменяется значение ключа главной таблицы, строки потомка не обновляются автоматически, чтобы соответствовать новому ключу; можно реализовать это требование каскадной модификации, используя триггеры базы данных.

14.2.6 CHECK

Ограничение CHECK определяет логику дополнительной проверки, которая должна дать результат "истина" для оператора вставки, модификации или удаления из таблицы. Дополнительная логика возвращает результат Boolean. Ограничение CHECK гарантирует, что значения в изменяемой строке удовлетворяют заданному набору проверок правильности. Синтаксис ограничения CHECK подобен синтаксису предложения WHERE оператора SELECT, однако здесь нельзя использовать подзапросы или столбцы, которые изменяются с течением времени (такие как SYSDATE). Вы можете использовать триггеры базы данных, чтобы запрограммировать обработку, которую нельзя поместить в ограничения. Например, при использовании ограничения CHECK для таблицы заказов, можно указать, что объем заказа должен быть больше нуля и комиссия продавца не может превышать более, чем на 10 процентов сумму заказа.

14.3 Индексы

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

Когда устанавливаются ограничения FOREIGN KEY, столбцы автоматически не индексируются. Так как столбцы внешнего ключа в операции соединения таблиц обычно участвуют вместе, на этих столбцах индексы создаются вручную.

14.4 Триггеры базы данных

Триггер базы данных -- это блок PL/SQL, который предназначен для автоматического выполнения при отработке оператора вставки, модификации и удаления из таблицы. Можно определить триггеры двух типов: запускающийся один раз для всего оператора и запускающийся для каждой вставляемой, изменяемой или удаляемой строки. С таблицей можно связать 12 событий -- для которых можно определить триггеры базы данных, а для каждого из 12 событий -- несколько триггеров базы данных.

Триггер базы данных может вызывать процедуры базы данных, которые также написаны на PL/SQL. В отличие от триггеров базы данных, процедуры в базе данных сохраняются в компилированной форме. По этой причине целесообразно поместить наиболее длинные сегменты кода в процедуру и затем вызывать эту процедура из триггера базы данных.

В дополнение к реализации сложных бизнес-правил, проверок, ввода значений по умолчанию, можно,, использовать триггеры базы данных, чтобы вставлять, модифицировать и удалять строки других таблиц. Примером такого использования является средство протоколирования, где строка протокола автоматически создается в таблице протокола всякий раз, когда строка таблицы данных изменяется. Без триггеров базы данных эта функция могла быть реализована в программах внешнего интерфейса, которые проводят изменения в базе данных; однако тот, кто умеет обойти программы внешнего интерфейса (например, используя SQL*Plus), может обойти установленные проверки и обработку.

В триггерах базы данных можно использовать операторы SQL, а в ограничениях - нет.

14.5 Привилегии системного уровня

Каждый пользователь Oracle, определяемый в базе данных, может иметь одну или несколько из болеет чем 80 привилегий системного уровня. Эти привилегии очень тонко управляют правами выполнения команд SQL. Администратор базы данных назначает системные привилегии или непосредственно пользовательским учетным разделам Oracle, или ролям. Роли затем назначаются учетным разделам Oracle. Например, прежде чем создать триггер для таблицы (даже если вы владелец таблицы как пользователь Oracle), нужно иметь системную привилегию, называемую CREATE TRIGGER, назначенную вашему учетному разделу пользователя Oracle, или роли, присвоенной учетному разделу.

Привилегия CREATE SESSION -- другая часто используемая привилегия системного уровня; Чтобы выполнить соединение с базой данных, учетный раздел Oracle должен иметь привилегию системного уровня CREATE SESSION.

14.6 Привилегии объектного уровня

Привилегии объектного уровня обеспечивают возможность выполнить определенный тип действия (выбрать, вставить, модифицировать удалить и т.д.) с указанным объектом. Владелец объекта имеет полный контроль над объектом и может выполнять любые действия с ним; он не обязан иметь привилегии объектного уровня. Фактически владелец объекта - пользователь Oracle, который может предоставлять привилегии объектного уровня другим пользователям.

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

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

14.7 Пользователи и роли

Роль -- тип объекта, который используется, для упрощения управления привилегиями системного и объектного уровня. Вместо того, чтобы назначать привилегии непосредственно учетным разделам пользователей, можно назначать привилегии ролям, которые затем назначаются пользователям.

...