Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
АРХИТЕКТУРА БАЗЫ ДАННЫХ ORACLE
Компоненты базы данных Oracle (рис.1) разделяются на три основные категории, в соответствии с тремя основными элементами машин, на которых эти базы данных функционируют:
Оперативная память – системная глобальная область (SGA System Global Area) Oracle
Диск – файлы данных, журналы повтора, управляющие файлы, файлы паролей и файлы параметров Oracle
Процессы – потоки в фоновом процессе oracle.exe (Windows) или отдельные процессы (Unix) и серверный процесс.
Рис.1 Элементы базы данных Oracle
1. СОЗДАНИЕ БАЗЫ ДАННЫХ ORACLE
Cоздание базы данных выполняется в два этапа: этап проектирования и этап создания.
Этап проектирования базы данных включает в себя планирование ограничений файлов и включение файлов в новую базу данных. Этап создания состоит в выполнении этого плана с помощью команды SQL CREATE DATABASE и некоторых сценариев. Планирование базы данных администратором состоит в определении ее файловой структуры.
Физически база данных Огасlе представляет собой набор файлов на диске. Расположение этих файлов несущественно для функционирования (хотя важно для производительности) базы данных. Это двоичные файлы, к которым обращаются только через программное обеспечение ядра Oracle. Запрос данных из фай лов БД обычно выполняется одним из инструментальных средств Oracle (таких как SQL*Plus), использую щих структурированный язык запросов SQL.
Логически база данных — это множество пользовательских разделов Oracle, каждый из которых иденти фицируется именем пользователя с паролем, уникальным в данной БД. Таблицы и другие объекты при надлежат некоторому пользователю Oracle. Доступ к СУБД возможен только после регистрации посредством ввода имени и пароля пользователя. Если введенные имя и пароль не проходят проверку на соответствие, доступ к БД не предоставляется. Имя и пароль пользователя СУБД Oracle отличаются от имени и пароля пользователя операционной системы.
Эта процедура регистра ции, или подключения к БД, выполняется всегда независимо от того, используются для доступа к серверу СУБД инструментальные средства Oracle или других изготовителей. Таблицы с одинаковыми именами могут существовать в двух разных учетных разделах Oracle; хотя имя у них одно, это — разные таблицы. Иногда одну БД (один набор физических файлов базы данных) исполь зуют для хранения различных версий таблиц (в отдельных учетных разделах Oracle) для разработчиков, тестирования системы или обучения пользователя; иногда одно имя таблицы используется в различных прикладных системах.
Можно, например, создать два учетных раздела Oracle, чтобы хранить данные для двух совершенно различных при кладных систем, т.е. в одной физической базе данных получились бы две логические базы данных.
2. КОМПОНЕНТЫ ПАМЯТИ ORACLE
В Oracle имеются две базовые структуры памяти. Первая и самая важная из них — системная глобальная память (SGA). Говоря о памяти, администраторы базы данных имеют в виду, как правило, именно SGA. Системная глобальная память состоит из нескольких элементов, каждый из которых отвечает определенной цели.
Буферный кэш (buffer cache). В памяти буферного кэша хранится информа ция Oracle, которую пользователи могут просматривать и изменять. Это позволяет избежать внесения пользователями изменений непосредственно в дисковые файлы. Вместо этого Oracle считывает данные, которые хочет изменить пользовательский процесс, в памяти, а позже записывает измененные данные на диск. При работе буферного кэша применяется модифицированный алгоритм "использовавшийся наиболее давно" (LRU— least-recently used), с помощью которого определяется, когда удалять данные из буферного кэша при возникновении потребности в сво бодном пространстве для информации, запрошенной пользователем.
Буфер журналов (log buffer). В буфере журналов Хранится специальная ин формация, называемая информацией повтора (redo) и помогающая Oracle воссоз давать измененные данные в случае сбоя в работе системы. Информация повтора заносится в буфер журналов пользователями, изменяющими данные, и хранится там до тех пор, пока Oracle не сможет записать ее на диск..
Разделяемый пул (shared pool). В разделяемом пуле хранится множество эле ментов, критически важных для работы базы данных Oracle. Компонентами разде ляемого пула являются библиотечный кэш (library cache), который применяется для хранения SQL-операторов, подвергнутых грамматическому разбору (что позво ляет работать с ними другим пользователям), словарный кэш (dictionary cache), или кэш строк (row cache), который применяется хранения информации словаря данных Oracle в памяти, где к нему можно достаточно быстро обращаться, а также фиксаторы (latches) и другие средства управления базой данных. Словарь данных (data dictionary) Oracle — это набор данных, хранимый в Oracle и содержащий сведения обо всех важных элементах БД.
Большой пул (large pool). Четвертый и реже других используемый компонент SGA, применяемый для выполнения параллельных операций над базой данных и для ее параллельного восстановления. Кроме того, в нем хранится информация гло бальной области сеансов пользователей в архитектуре многопоточного сервера. Впервые появившийся в Огас1е8, этот компонент необязателен для функциониро вания баз данных Oracle.
Другая структура памяти экземпляра Огасlе называется программной глобальной областью (РGА). Она помогает выполнению пользователь ских процессов, сохраняя такую информацию, как значения переменных привязки, области сортировки и другие характеристики обработки курсоров. Хотя информация о подверг шихся грамматическому разбору конструкциях SQL или PL/SQL может уже быть доступна в библиотечном кэше или разделяемом пуле, значения, над которыми пользователь хочет выполнить оператор SELECT или UPDATE, коллективно приме нять нельзя. РGА используется для хранения реальных значений для исполняемых SQL-операторов, а не переменных привязки.
3. ФАЙЛЫ ORACLE
Существуют три основные группы файлов на диске, составляющие базу данных:
Для доступа к данным БД все три набора файлов должны присутствовать, быть открытыми и доступны ми Oracle. Если эти файлы отсутствуют, обратиться к базе данных нельзя, и администратор базы данных должен будет восстанавливать часть или всю БД, используя файлы резервных копий (если их сделали!). Все эти файлы двоичные.
Наиболее важные из них — файлы базы данных, где располагаются собственно данные (от нескольких мегабайт до многих гигабайт). В зависимости от размеров, таблицы (и другие объекты) всех учетных разделов пользователей могут, очевидно, размещаться в одном файле базы данных, но это — не лучшее решение, так как оно не способствует гибкости структуры базы данных для управления доступом к различным пользовательским разделам, размещения базы данных на различных дисководах или резервного копирования и восстановления части базы данных. Нужно иметь по крайней мере один файл данных (что достаточно для маленькой или тестовой базы данных), но обычно база данных будет содержать несколько файлов. С точки зрения логического доступа и использования данных в таблицах и других объектах количество (и расположение) файлов несущественно. Размер файла базы данных задается при его создании и впоследствии не может быть увеличен.
Управляющие и журнальные файлы поддерживают функционирование архитектуры. Любая база данных должна иметь по крайней мере один управляющий файл, хотя обычно создают несколько, чтобы защититься от потерь. В управляющий файл записываются имя базы данных, дата и время ее создания, расположение базы данных и журнальных файлов и информация синхронизации, чтобы гаран тировать согласованность всех трех групп файлов БД. При добавлении к базе данных нового файла данных или журнального файла информация будет зарегистрирована в управляющих файлах.
Каждая база данных должна иметь по крайней мере два журнальных файла. Это — журналы базы данных; в этих файлах записываются все изменения пользовательских и системных объектов. Если происходит какой-либо сбой, например, потеря одного (или больше) файлов базы данных, можно, используя измене ния, записанные в журнальных файлах, привести базу данных к непротиворечивому состоянию без потери фиксированных транзакций. В случае сбоя, не связанного с потерей данных, такого как аварийный отказ ЭВМ, Oracle может воспользоваться информацией из журнального файла для автоматического восстановле ния без вмешательства администратора базы данных (DВА). Фоновый процесс SMON автоматически пов торно выполняет зафиксированные в журнальных файлах изменения в файлах базы данных. Подобно другим файлам, используемым Oracle, размер журнального файла фиксируется при создании и впоследствии не может увеличиться.
Оперативные журнальные файлы — два или больше журнальных файла, которые всегда используются во время работы экземпляра Oracle. Изменения в БД регистрируются в каждом из журнальных файлов пооче редно. Когда один из них заполняется, вывод журнала переключается на другой; когда этот заполняется, происходит переключение на первый, и цикл продолжается.
Автономные или архивные журнальные файлы — точные копии заполненных оперативных журнальных файлов; создавать их необязательно. Oracle создает их, только когда база данных обрабатывается в режиме ARCHIVELOG. Если база данных работает в режиме ARCHIVELOG, активизируется фоновый процесс ARCH и копирует заполненный оперативный журнальный файл в автономный приемник (обычно на дру гом дисководе). Во время этого копирования Oracle использует другой оперативный журнальный файл. Если имеется полный набор автономных журнальных файлов с момента выполнения последней резервной копии БД значит есть полная запись проведенных изменений. Если потерян один или больше файлов данных, можно воспользоваться этой записью, чтобы повторить изменения в БД, восстановленной с резер вной копии.
Когда запускается экземпляр Oracle (иными словами, когда инициируются фоновые процессы Oracle и выделяются структуры памяти), файл параметров экземпляра определяет размеры и режим работы СУБД. Этому файлу присваивается имя INIT.ORA. (Фактическим именем файла будет идентификатор экземпляра Oracle, конкатенированный с именем файла.) Это обычный текстовый файл, содержащий параметры, для которых можно изменять значения по умолчанию. Администратор базы данных отвечает за создание и изменение этого файла параметров.
4. СИСТЕМНЫЕ И ПОЛЬЗОВАТЕЛЬСКИЕ ПРОЦЕССЫ
Для работы с файлами базы данных на машине должны существовать системные процессы Oracle и один (или больше) пользовательский процесс. Системные процессы Oracle (их называют фоновыми) обеспечива ют функционирование пользовательских процессов, т.е. выполняют функции, которые иначе пришлось бы выполнять пользовательским процессам непосредственно. Чтобы можно было работать с БД фоновые про цессы PMON, SMON, DBWR и LGWR (они описываются ниже) должны быть активными. Другие фоновые процессы поддерживают необязательные средства, улучшающие функционирование СУБД. Дополнительно к фоновым процессам Oracle в простейшем случае на одно подключение к базе данных должен существовать один пользовательский процесс. Пользователь должен подключиться к базе данных, прежде чем он сможет обратиться к какому-либо объекту. Если один пользователь регистрируется в Oracle, используя SQL*Plus, а другой пользователь выбирает Oracle Forms, то имеется два пользовательских процесса для работы с этой базой данных - по одному для каждого подключения.
Фоновый процесс DBWR переписывает модифицированные блоки БД из SGA в файлы базы дан ных. Он записывает только модифицированные блоки (например, блок содержит новую, удаленную или измененную запись). DBWR сначала записывает наиболее давно использовавшиеся блоки. Они не обяза тельно записываются в базу данных при фиксации транзакции; единственная процедура, которая всегда выполняется при фиксации транзакции - регистрация и запись изменений в оперативные журнальные файлы. Блоки базы данных будут записываться позже, когда в SGA не хватит свободных буферов для разме щения нового блока.
LGWR — процесс записи в журнал — переписывает элементы журнального буфера SGA для одной или больше транзакций в оперативные журнальные файлы. Например, при фиксации транзакции этот процесс должен записать элементы буфера в журнальные файлы на диске, и только потом пользовательский процесс полу чит сообщение, указывающее, что фиксация транзакции прошла успешно. После фиксации транзакции изменения записаны на диск, даже если измененные блоки базы данных все еще находятся в буфере SGA и ожидают записи процессом DBWR. SMON может всегда повторить изменения по журнальным файлам, если более актуальная копия базы данных потеряна.
SMON — системный монитор — осуществляет мониторинг экземпляра. Если две транзакции ждут, пока одна из них освободит блокировки, и ни одна из них не может продолжаться (это называется "тупик" или "клинч"), SMON распознает эту ситуацию, и один из процессов получает сообщение о том, что возник тупик. SMON также освобождает временные сегменты, которые более не используются пользовательским про цессом, создавшим их. Когда СУБД простаивает, SMON дефрагментирует свободное пространство в файлах базы данных, под готавливая распределение внешней памяти под новые объекты или для расширения существующих объек тов базы данных. Кроме того, SMON автоматически восстанавливает при запуске ненормально остановленный экземпляр Oracle (если нет потерянных файлов). Не выдается никаких сообщений, указывающих, что выполняется восстановление экземпляра, просто запуск займет больше времени.
РМОN — монитор процессов — контролирует пользовательские процессы. Если происходит какой-либо сбой поль зовательского процесса (например, если процесс уничтожен в середине транзакции), РМОN выполняет автоматический откат к началу транзакции (отменяя все, начиная с последнего СОММIТ или ROLLBACK).
При этом освобождаются все блокировки и другие ресурсы системы, занятые отказавшим процессом. РМОN также контролирует процесс диспетчера и процесс разделения сервера, которые являются частью СУБД многопотокового сервера, и перезапускает их, если они "зависли".
Наряду с четырьмя обязательными системными процессами существует несколько необязательных сис темных процессов.
ARCH — фоновый процесс-архиватор — при работе базы данных в режиме ARCHIVELOG выполняет копирование одного из оперативных журнальных файлов в файл-архив (точное расположение указывается в параметре INIT.ORA). Таким образом можно получить полную хронологию изменений, про веденных в файлах базы данных, записанную в архивном и оперативном журнальных файлах.
СКРТ — процесс выполнения контрольных точек. Событие "контрольная точка" происходит после заполнения одного из оперативных журнальных фай лов; позже этот файл будет перезаписан, когда другие оперативные журнальные файлы заполнятся. Если журнальный файл перезаписывается, изменения, зарегистрированные в этом файле, становятся недоступ ными для использования в случае сбоя системы. В контрольной точке измененные блоки буферов базы данных записываются в файлы базы данных на диск фоновым процессом DBWR. Это означает, что в случае сбоя системы с утратой областей памяти для восстановления журнал изменений не понадобится. После выполнения контрольной точки журнальный файл можно перезаписывать. В контрольной точке обновляются все заголовки файлов данных и заголовки журнальных файлов, чтобы зафиксировать сам факт выполнения контрольной точки. Фоновый процесс LGWR выполняет эту задачу обновления, которая может потребовать больших затрат времени, если имеется большое количество файлов данных и журнальных файлов. В этом случае вся СУБД будет ожидать завершения выполнения контроль ной точки, прежде чем в журнальные файлы смогут записываться дальнейшие изменения базы данных. Чтобы сократить время, которое требуется LGWR для модификации заголовков файлов, можно запустить СКРТ — процесс выполнения контрольных точек. Контрольная точка может выполняться и в другие моменты, например, когда число элементов в жур нальном файле достигает предела, определенного администратором базы данных.
Независимо от того, запущен или нет фоновый процесс CKPT, контрольная точка выполняется при заполнении одного из журнальных файлов.
RECO — процесс восстановления — запускается, если происходит сбой в распределенной транзакции (тран закция, в которой изменяются две или больше базы данных) и одна или больше баз данных требуют выпол нить или фиксацию, или откат транзакции. RECO, если он запущен, пытается автоматически фиксировать или откатить транзакцию на локальной базе данных синхронно с процессами RECO на других базах данных Oracle. Не нужно запускать фоновый процесс восстановления, если не используются распределенные транзакции.
LCK — процесс блокировки — используется в параллельном сервере Oracle, где с одним набором файлов базы данных работает несколько экземпляров. Процессы LCK, работая на всех экземплярах, синхронизируют блокировки БД между экземплярами. Если пользователь подключился к одному экземпляру и блокирует строку, строка блокиру ется и для пользователя, пытающегося изменить ее другим экземпляром. Пользователи всегда могут выполнять чте ние строк независимо от того, блокированы ли эти строки другими пользователями. Может быть запущено до 10 фоновых процессов LCK, чтобы расшить узкое место синхронизации бло кировок, однако одного обычно оказывается достаточно. Не нужно запускать фоновые процессы LCK, если не используется параллельный сервер Oracle.
SQL*Net Listener — процесс прослушивания сети ("слушатель") — направляет запросы, приходящие от машин-клиентов, к соответ ствующему экземпляру Oracle. Он взаимодействует с сетевым ПО, маршрутизируя запросы между сервером базы данных и машиной-клиентом (независимо от того, что работает на клиенте — инструментальное ПО Oracle или другой сервер базы данных). Слушатель SQL*Net обрабатывает запросы для всех экземпляров, выполняющихся на машине. Можно запускать несколько слушателей SQL*Net, но это делают редко.
Пользовательские процессы логически состоят из двух частей: кода сервера Oracle, который транслирует и выполняет операторы SQL и читает файлы и области памяти базы данных, и инструментальной части, которая является исполняемым кодом используемого программного инструмента. Код сервера иногда на зывают кодом ядра Oracle.
Пользовательские процессы в Oracle можно определять для трех различных конфигураций — однозадачной; с выделенным сервером и с многопотоковым сервером. Эти конфигурации могут совместно применяться для одного экземпляра.
В случае однозадачной конфигурации инструментальный код и код сервера базы данных сконфигурированы в один процесс. Каждое подключение к базе данных — это один пользовательский процесс, выполняемый на машине.
В конфигурации с выделенным сервером (ее также называют двухзадачной) две части пользовательского процесса реализованы как два отдельных процесса, выполняемых на машине. Они поддерживают связь один с другим, используя механизмы межпроцессной связи ОС. Каждое подключение к базе данных требу ет работы двух процессов, выполняемых на машине. Программное обеспечение ядра Oracle в одном процес се иногда называют "теневым процессом". Эта конфигурация является стандартной для платформы UNIX, так как операционная система не может (в некоторых реализациях UNIX) защитить код и области памяти Oracle от кода приложения. Она также является стандартной для систем клиент/сервер, когда код сервера располагается на машине сервера, а инструментальный код выполняется на машине клиента со связью по сети. Организация взаимодействия двух составляющих частей одного логического процесса в принципе одинакова при расположении этих частей на одной или разных машинах, но когда две половины логического процесса располагаются на двух машинах и взаимодействуют через сеть, используется SQL*Net, а не механизмы межпроцессной связи опера ционной системы. Конфигурация с выделенным сервером может быть довольно расточительна, поскольку память расходу ется на теневой процесс и количество процессов на машине возрастает, даже когда пользователь не дает каких-либо запросов к базе данных. Выделенный сервер (теневой процесс) обрабатывает запросы только одного процесса-клиента.
MTS (Multi-Threaded Server) — конфигурация с многопотоковым сервером позволяет одному процессу сервера Oracle выполнять работу для многих пользовательских процессов. Таким образом преодолеваются недостатки конфигурации с выде ленным сервером. Уменьшается количество процессов и объем занятой памяти, улучшается общая произво дительность системы. В конфигурации MTS появляются два новых типа системных процессов. Использование одного из разделяемых процессов сервера, который является частью конфигурации с многопотоковым сервером, неэффективно, если пользовательский процесс выдает много запросов к базе данных (например, при экспорте базы данных); для такого процесса лучше использовать выделенный сер вер. Обе конфигурации могут сосуществовать.
Процессы-диспетчеры Один или несколько процессов-диспетчеров принимают запросы процессов-клиентов от слушателя SQL*Net и направляют запрос к одному из процессов разделяемого сервера. Слушатель SQL*Net требуется для конфигурации MTS, даже когда сеть не используется. Нужно включить в конфигурацию по крайней мере один процесс-диспетчер для каждого используемого сетевого протокола, чтобы направлять запросы к экземпляру. Количество диспетчеров не увеличивается при увеличении загрузки системы, так как диспетчеры только обеспечивают маршрутизацию. Фактическая работа выполняется разделяемыми серверами.
Процессы разделяемого сервера обеспечивают те же функциональные возможности, что и процесс выделенного сервера, и содержит код сервера Oracle, который выполняет работу для клиентов. Он может обслу живать запросы многих пользовательских процессов. Фактически используемый разделяемый сервер может меняться от одного вызова к другому, поскольку никакой пользовательский процесс не может монополизи ровать конкретный процесс разделяемого сервера. Oracle использует область в SGA для передачи сообще ний между различными активными процессами. Количество процессов разделяемого сервера автоматически увеличивается (или уменьшается до исход ного числа, определенного администратором базы данных) в соответствии с загрузкой системы.
PAGE 1