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

Лекция 5. Архитектура экземпляра Oracle.

Схематично экземпляр Oracle представлен на рис.2.3 Функционирование экземпляра зависит от его настроек, связанных с компонентами SGA (или ГСО) и касающихся фоновых процессов [1].

Рис.2.3. Экземпляр Oracle

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

ГСО состоит из следующих компонентов [1]:

• разделяемый пул (Shared Pool);

• кэш-буфер данных (Database Buffer Cache);

• буфер журнала транзакций (Redo Log Buffer);

• структуры сервера многопоточной среды Multi-Threaded Server (MTS).

Разделяемый пул (см. рис.2.3) содержит кэш библиотеки, кэш словаря и управляющие структуры сервера (та­кие, как набор символов БД).

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

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

Кэш библиотеки включает в себя разделяемые и локальные об­ласти SQL. Разделяемая область содержит информацию, завися­щую от текущего сеанса работы. Это могут быть присоединенные переменные, параметры окружения, стеки и буферы, необходимые для выполнения, и т.п. Локальная область формируется для каж­дой инициируемой транзакции и освобождается после того, как закрывается соответствующий курсор (запрос к базе данных, воз­вращающий данные по строкам, что позволяет применять к каж­дой из них операции модификации). Количество локальных облас­тей, которые можно одновременно открыть во время сеанса рабо­ты, ограничивается параметром OPEN_CURSORS в файле inlt.ora. Посредством этих двух структур памяти Oracle может повторно использовать информацию, общую для всех выражений SQL, а информация, специфическая для данного сеанса, может быть выбрана из локальной области.

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

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

Главным параметром разделяемого пула является параметр SHARED__POOL_SIZE в файле init.ora, который определяет его размер (в байтах). Необходимо заказывать объем пула, достаточ­ный для загрузки и сохранения блоков PL/SQL и выражений SQL. По мере загрузки и выгрузки объектов данных область фрагментируется, и может наступить такой момент, когда для загрузки очередного объекта не найдется непрерывной области подходяще­го объема. Если такая ситуация возникает, то может помочь ко­манда SQL

ALTER SYSTEM FLUSH SHARED_POOL

Если ситуация повторяется часто, нужно увеличить объем пула в файле параметров init.ora.

Кэш-буфер данных является одним из основных разделов ГСО, от функционирова­ния которого во многом зависит про­изводительность системы. Он состоит из блоков памяти того же размера, что и блоки Oracle. Все данные, с которыми работает СУБД, первым делом загружаются в кэш-буфер. В этих же блоках памяти выполняется и любое обновление данных, поэтому очень важно правильно установить размер буфера. Доступ к памяти выполняется в сотни раз быстрее, чем доступ к дискам, и при ис­пользовании системы оперативной обработки транзакций (OLTP-системы) крайне желательно, чтобы большин­ство операций с данными выполнялось в памяти кэш-буфера, куда данные уже предварительно загружены.

СУБД переносит данные на диск в соответствии с порядком их размещения в списке LRU (Least Recently Used - использованные наиболее давно). Этот список отслеживает обращение к блокам данных и учитывает частоту обращений. Когда выполняется обращение к блоку данных, хра­нящемуся в кэш-буфере, он помещается в тот конец списка, кото­рый носит название MRU (Most Recently Used - только что ис­пользован). Если серверу требуется место в кэш-буфере для за­грузки нового блока с диска, он обращается к списку LRU и реша­ет, какой из блоков перенести на диск, чтобы освободить место для нового. Блоки, наиболее отстоящие в списке от MRU, - наи­более вероятные кандидаты на перенос (удаление из кэш-буфера). Таким образом, дольше всего остаются в кэш-буфере те блоки, к которым наиболее часто выполняется обращение.

Если происходит обращение к блокам, доступ к которым тре­бует полного просмотра некоторой таблицы, то такая ситуация является исключением из описанной методики использования списка LRU. Подобные блоки сразу помещаются в самый конец списка. Чтобы отменить соглашение, принятое по умолчанию, необходимо квалифицировать соответствующую таблицу как CACHE.

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

Сервер Oracle использует отложенную многоблочную проце­дуру записи на диск с тем, чтобы уменьшить влияние времени обращения к дисковой памяти на производительность системы. Термин «отложенная» - означает, что обновление данных, выпол­ненное СУБД, не фиксируется немедленно в дисковой памяти. СУБД ждет, пока не произойдет одно из следующих событий: внесены изменения в некоторое, заранее установленное число блоков данных; потребуется освободить место в кэш-буфере для загрузки новых блоков данных; обнаружена контрольная точка; истекло время, заданное процессом DBWR. В любом из этих слу­чаев группа модифицированных блоков данных переписывается из кэш-буфера в файлы.

Размер кэш-буфера определяется двумя параметрами файла init.ora - DB_BLOCK_SIZE и DB_BLOCK_BUFFERS. Параметр DB_BLOCK_SIZE используется при создании БД для определения размера блока Oracle. В свою очередь, параметр DB_BLOCK_BUFFERS определяет количество блоков, выделяемых для кэш-буфера данных. Общий объем кэш-буфера данных (в байтах) является произведением значений этих двух параметров - DB_BLOCK_SI-ZE*DB_BLOCK_BUFFERS, и .рациональный выбор этого значения является основным в настройке кэш-буфера. Для кэш-буфера дан­ных нет необходимости выделять весь доступный объем памяти компьютера, главное - определить самое рациональное значение объема кэш-буфера, при котором память используется наиболее оптимально. Найти такое значение можно методом последова­тельных проб, увеличивая заказанный размер буфера и фиксируя, насколько заданное увеличение сказывается на производительно­сти системы. Проанализировав полученные значения, можно за­метить, что в начале этого процесса увеличение размера кэш-буфера довольно значительно повышает производительность сис­темы, но затем его влияние постепенно снижается. Здесь потребу­ется определенный опыт, чтобы вовремя остановиться и использо­вать оставшийся свободным ресурс памяти для других управляю­щих структур СУБД.

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

Размер буфера журнала транзакций задается параметром LOG_BUFFER в файле init.ora. Значение параметра указывает размер буфера в байтах. Если это значение не велико, то процесс LGWR очень часто будет переписывать информацию из буфера в файл и тем самым замедлять работу системы. Однако это будет проявляться только в случае большой интенсивности обращения к БД.

Процесс записи в журнал можно оперативно контролировать при помощи представления v$sysstat. Если запросить v$sysstat для поля value с полем name, равным «redo log space wait time», в результате получим время, в течение которого пользовательские процессы находились в состоянии ожидания при обращении к буферу журнала транзакций.

Для того чтобы гарантировать последовательный характер за­писи в буфер журнала, сервер Oracle управляет доступом к нему при помощи защелок (latch). Такая защелка представляет собой блокировку процессом Oracle некоторой структуры в памяти - аналогично блокировке файла или строки таблицы. Процесс блокирует посторонние обращения к памяти, выделенной для буфера журнала транзакций. Таким образом, если один процесс «нало­жил» защелку на буфер, другие не могут обратиться к нему до тех пор, пока защелка не будет снята.

Количество транзакций, данные о которых заносятся в журнал одновременно, сервер Oracle ограничивает параметром TRANSACTIONS. Значение, принимаемое системой по умолча­нию, может меняться в зависимости от используемой операцион­ной системы и аппаратных средств. Для многопроцессорных сер­веров допускается выделение пространства, большего, чем задано параметром TRANSACTIONS. При этом вместо защелки на выде­ление памяти процессы могут использовать защелки копий жур­нала транзакций (redo copy latch). Параметр _LOG_SIMULTANEOUS_COPIES задает количество таких защелок. По умолча­нию значение _LOG_SIMULTANEOUS_COPIES равно количеству процессоров в системе. Используя защелки копий журнала тран­закций, несколько процессов могут одновременно записывать информацию в буфер журнала транзакций.

Чтобы проанализировать работу буфера журнала транзакций, можно запросить содержимое динамического представления v$latch, в котором содержится информация о каждом типе защелки.

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

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