Oracle - MS Server / OracleМП / лекции оракл / lect3_m2_ipovs_ipovs_SUBDOracle_231000.62

Лекция 3. Основные элементы архитектуры Oracle.

Физическая архитектура Oracle различна в разных операционных системах. Например, в ОС UNIX СУБД Oracle реализована в виде нескольких отдельных процессов операционной системы — практически каждая существенная функция реализована отдельным процессом [3]. Для UNIX такая реализация подходит, поскольку основой многозадачности в ней является процесс. Для Windows, однако, подобная реализация не подходит и работала бы не слишком хорошо (система получилась бы медленной и плохо масштабируемой). На этой платформе СУБД Oracle реализована как один многопоточный процесс, т.е. с использованием подходящих для этой платформы механизмов реализации. На мэйнфреймах IBM, работающих под управлением OS/390 и zOS, СУБД Oracle использует несколько адресных пространств OS/390, совместно образующих экземпляр Oracle. Для одного экземпляра базы данных можно сконфигурировать до 255 адресных пространств. Более того, СУБД Oracle взаимодействует с диспетчером загрузки OS/390 WorkLoad Manager (WLM) для установки приоритетности выполнения определенных компонентов Oracle по отношению друг к другу и к другим задачам, работающим в системе OS/390. В ОС Netware тоже используется многопоточная модель. Хотя физические средства реализации СУБД Oracle на разных платформах могут отличаться, архитектура системы — достаточно общая, чтобы можно было понять, как СУБД Oracle работает на всех платформах [3].

Три основных компонента архитектуры Oracle [3]:

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

• Структуры памяти, в частности системная глобальная область (System Global Area — SGA).

• Физические процессы или потоки. Три типа процессов, образующих экземпляр: серверные процессы, фоновые процессы и подчиненные процессы.

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

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

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

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

Табличное пространство представляет собой логический раздел базы данных. В каждой базе данных имеется хотя бы одно табличное пространство, называе­мое системным (SYSTEM). Можно создавать другие табличные пространства, чтобы объединить вместе пользователей или приложения, что позволит упрос­тить управление базой данных и повысить ее производительность. В качестве примеров можно привести табличные пространства USERS для общего исполь­зования и UNDO для сегментов отмены. Табличное пространство может принадлежать только одной базе данных.

Каждое табличное пространство состоит из одного или нескольких дисковых файлов, называемых файлами данных [1]. Файл данных может принадлежать одному и только одному табличному пространству. После создания файлов их размеры можно изменять. При создании новых табличных пространств необходимо созда­вать и новые файлы данных. После добавления файла данных к табличному про­странству его уже нельзя удалить или связать с другим табличным пространством. Если объекты базы данных сохраняются в нескольких табличных простран­ствах, можно разделить их на физическом уровне, разместив соответствующие файлы данных на различных дисках. Разделение данных представляет собой важный инструмент планирования и настройки того способа, с помощью кото­рого база данных работает с запросами ввода/вывода. Соотношение между базой данных, табличными пространствами и файлами данных показаны на рис. 2.1.

Рис. 2.1 Соотношение между базой данных, табличными пространствами и файлами данных

Файлы данных обеспечивают физическую сохранность ин­формации базы данных, являясь как внутренними структу­рами (связаны непосредственно с табличными пространствами), так и внешни­ми, поскольку это физические файлы. Помимо файлов данных к базе данных имеют отношение также журналы повтора, управляющие файлы, трассировочные файлы и журнал предупреждающих сообщений [1].

Oracle поддерживает журналы всех транзакций в базе данных. Транзакции запи­сываются в файлы, называемые файлами оперативных журналов повтора. Эти фай­лы используются для восстановления транзакций базы данных в надлежащем порядке в случае сбоя БД. Сохранение информации журналов повтора является внешним по отношению к файлам данных базы данных.

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

Все базы данных Oracle будут иметь не менее трех файлов журнала повторов. В Oracle запись в файлы журнала повторов производится циклически: после за­полнения первого файла идет запись во второй файл, пока он не будет заполнен. По заполнении всех файлов оперативного журнала повтора происходит возврат к первому файлу журнала и начинается замена его содержимого новыми данны­ми транзакции. Если база данных работает в режиме ARCHIVELOG, перед пере­записью она сделает копию файлов оперативного журнала повтора. Затем эти архивированные файлы журнала повтора можно использовать для восстановле­ния любой части базы данных в любой момент времени.

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

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

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

У каждого из фоновых процессов, происходящих в экземпляре, есть свой трасси­ровочным файл. Такой файл содержит информацию о существенных событиях, с которыми сталкивается фоновый процесс. Помимо трассировочных файлов, Oracle поддерживает файл, называемый журналом предупреждающих сообщений. В этот журнал записываются команды и их результаты для основных событий в ра­боте базы данных. Например, в него записываются: создание табличных про­странств; ключи журналов повтора; операции восстановления и запуска базы данных. Журнал предупреждающих сообщений является чрезвычайно важным источником информации для повседневного управления базой данных; трасси­ровочные файлы наиболее полезны при выяснении причин серьезного сбоя.

Журнал предупреждающих сообщений следует просматривать ежедневно. За­писи в журнале предоставят информацию о любых проблемах, возникших во время операций базы данных, включая все происходящие внутренние ошибки ORA-0600. Чтобы облегчить пользование этим журналом, нужно каждый день ав томатически переименовывать его. Например, если он называется alert_orcl.log, можно переименовать его так, чтобы имя файла содержало текущую дату. Когда в следующий раз Oracle попытается внести запись в журнал предупреждающих сообщений, он не сможет найти файл с именем alert_orc.log и поэтому создаст новый. При этом в наличии будет текущий (alert_orcl.log), а также предыдущий жур­нал предупреждающих сообщений. Такой способ разделения записей в журнале может повысить эффективность их анализа.

Для работы сервера должны быть активными системные и пользовательские процессы Oracle [1]. К обязательным системным процессам относятся: PMON — монитор процессов, SMON — системный монитор, DBWR — процесс записи в базу данных, LGWR — процесс записи в журнал транзакций. Дополнительно к системным процессам для подключений к базе данных должны существовать пользовательские процессы. Пользователь должен подключиться к базе данных, прежде чем он сможет обратиться к какому-либо ее объекту. Пользовательские процессы логически состоят из двух частей: кода сервера, который транслирует и выполняет операторы SQL, читает файлы и области памяти базы данных, и инструментальной части, которая является исполняемым кодом используемого программного средства.

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

Память, используемая сервером Oracle, имеет следующую структуру. Системная память для всей базы данных называется SGA (system global area — глобальная системная область (ГСО)). Данные и управляющие структуры в SGA являются разделяемыми, и все системные и пользовательские процессы могут к ним обращаться. Например, в SGA в течение некоторого времени хранятся дерево синтаксического разбора и план выполнения для каждого оператора SQL, и если происходит повторное выполнение такого же оператора, то повторный анализ не производится и используется находящийся в SGA план выполнения. Таким образом, повышается быстродействие системы за счет устранения дублирования операций.

Список литературы

1. Илюшечкин В.М. - Учебно-методические разработки для самостоятельной работы студентов, изучающих дисциплину «СУБД Oracle»

2. All-Oracle [Электронный ресурс]. – URL:http://all-oracle.ru/content/view/?part=1&id=68

3. Oracle для профессионалов [Электронный ресурс]. – URL: http://citforum.ru/database/oracle/kyte

7