Funnybluejeans : другие произведения.

21

Самиздат: [Регистрация] [Найти] [Рейтинги] [Обсуждения] [Новинки] [Обзоры] [Помощь|Техвопросы]
Ссылки:
Школа кожевенного мастерства: сумки, ремни своими руками
 Ваша оценка:

  Архитектура памяти Oracle: основные структуры памяти сервера Oracle.
  Основные структуры памяти сервера Oracle.
  • SGA, System Global Area - глобальная область системы. Это большой совместно используемый сегмент памяти, к которому обращаются все процессы Oracle. •
  PGA, Process Global Area - глобальная область процесса. Это приватная область памяти процесса или потока, недоступная другим процессам/потокам. •
  UGA, User Global Area - глобальная область пользователя. Это область памяти, связанная с сеансом. Глобальная область памяти может находиться в SGA либо в PGA. Если сервер работает в режиме MTS, она располагается в области SGA, если в режиме выделенного сервера, - в области PGA.
  Области PGA и UGA
  PGA - это область памяти процесса.
  используется одним процессом или одним потоком.
  недоступна ни одному из остальных процессов/потоков в системе.
  PGA обычно выделяется с помощью
  библиотечного вызова malloc() языка С и со временем может расти (или уменьшаться).
  Область PGA никогда не входит в состав области SGA - она всегда локально выделяет-
  ся процессом или потоком.
  
  Область памяти UGA хранит состояние сеанса, поэтому всегда должна быть ему доступна.
  Местонахождение области UGA зависит исключительно от конфигурации сер-
  вера Oracle. Если сконфигурирован режим MTS, область UGA должна находиться в струк-
  туре памяти, доступной всем процессам, следовательно, в SGA.
  При подключении к выделенному серверу это требова-
  ние общего доступа к информации о состоянии сеанса снимается, и область UGA ста-
  Архитектура
  новится почти синонимом PGA, - именно там информация о состоянии сеанса и будет
  располагаться.
  Размер области PGA/UGA определяют параметры уровня сеанса в файле init.ora:
  SORT_AREA_SIZE и SORT_AREA_RETAINED_SIZE. Эти два параметра управляют
  объемом пространства, используемым сервером Oracle для сортировки данных перед
  сбросом на диск, и определяют объем сегмента памяти, который не будет освобожден
  по завершении сортировки. SORT_AREA_SIZE обычно выделяется в области PGA, a
  SORT_AREA_RETAINED_SIZE - в UGA. Управлять размером областей UGA/PGA
  можно с помощью запроса к специальному представлению V$ сервера Oracle.
  Область PGA - это "куча" памяти, в которой могут выделяться другие струк-
  туры. Область UGA также является кучей, в которой определяются связанные с сеансом
  структуры. Область UGA выделяется из PGA при подключении к выделенному серверу
  Oracle и - из области SGA при подключении в режиме MTS. Это означает, что при ра-
  боте в режиме MTS необходимо задать такой размер области SGA, чтобы в ней хватило
  места под области UGA для предполагаемого максимального количества одновременно
  подключенных к базе данных пользователей. Поэтому область SGA в экземпляре, рабо-
  тающем в режиме MTS, обычно намного больше, чем область SGA аналогично сконфи-
  гурированного экземпляра, работающего в режиме выделенного сервера.
  
  
  Область SGA
  System Global Area - глобальная область системы. Это большая разделяемая струк-
  тура, к которой обращаются все процессы Oracle. Физически область SGA реализована как сегмент
  разделяемой памяти - отдельный фрагмент памяти, к которому могут подключаться
  процессы. При отсутствии процессов Oracle вполне допустимо иметь в системе область
  SGA; память существует отдельно от них. Однако наличие области SGA при отсутствии
  процессов Oracle означает, что произошел тот или иной сбой экземпляра. Эта ситуация -
  нештатная, но она бывает.
  Вот как "выглядит" область SGA в ОС UNIX:
  $ ipcs -mb -это команда для просмотра занимаемой памяти
  В ОС Windows увидеть область SGA, как в ОС UNIX, нельзя.
  В самой СУБД Oracle можно определить размер области SGA независимо от плат-
  формы. Есть еще одно "магическое" представление V$, именуемое V$SGASTAT.
  Область SGA разбита на несколько пулов.
  • Java-пул. Java-пул представляет собой фиксированный пул памяти, выделенный
  виртуальной машине JVM, которая работает в составе сервера.
  • Большой пул. Большой пул (large pool) используется сервером в режиме MTS для
  размещения памяти сеанса, средствами распараллеливания Parallel Execution для
  буферов сообщений и при резервном копировании с помощью RMAN для буфе-
  ров дискового ввода/вывода.
  • Разделяемый пул. Разделяемый пул (shared pool) содержит разделяемые курсоры,
  хранимые процедуры, объекты состояния, кэш словаря данных и десятки других
  компонентов данных.
  • "Неопределенный" ("Null") пул. Этот пул не имеет имени. Это память, выделен-
  ная под буферы блоков (кэш блоков базы данных, буферный кэш), буфер журна-
  ла повторного выполнения и "фиксированную область SGA".
  
  На общий размер SGA наиболее существенно влияют следующие параметры init.ora.
  • JAVA_POOL_SIZE. Управляет размером Java-пула.
  • SHARED_POOL_SIZE. Управляет (до некоторой степени) размером разделяемого
  пула.
  • LARGE_POOL_SIZE. Управляет размером большого пула.
  • DB_BLOCK_BUFFERS. Управляет размером буферного кэша.
  • LOG_BUFFER. Управляет (отчасти) размером буфера журнала повторного выпол-
  нения.
  Фиксированная область SGA
  Фиксированная область SGA - это часть области SGA, размер которой зависит от
  платформы и версии. Она "компилируется" в двоичный модуль сервера Oracle при уста-
  новке (отсюда и название - "фиксированная"). Фиксированная область SGA содержит
  переменные, которые указывают на другие части SGA, а также переменные, содержа-
  щие значения различных параметров. Размером фиксированной области SGA (как пра-
  вило, очень небольшой) управлять нельзя. Можно рассматривать эту область как "заг-
  рузочную" часть SGA, используемую сервером Oracle для поиска других компонентов
  SGA.
  Буфер журнала повторного выполнения
  Буфер журнала повторного выполнения используется для временного кэширования
  данных активного журнала повторного выполнения перед записью на диск. Поскольку
  перенос данных из памяти в память намного быстрее, чем из памяти - на диск, исполь-
  зование буфера журнала повторного выполнения позволяет существенно ускорить ра-
  боту сервера. Данные не задерживаются в буфере журнала повторного выполнения на-
  долго. Содержимое этого буфера сбрасывается на диск:
  • раз в три секунды;
  • при фиксации транзакции;
  • при заполнении буфера на треть или когда в нем оказывается 1 Мбайт данных
  журнала повторного выполнения.
  Стандартный размер буфера журнала повторного выполнения, задаваемый парамет-
  ром LOG_BUFFER в файле init.ora, определяется как максимальное из значений 512 и
  (128 * количество процессоров) Кбайт. Минимальный размер этой области равен мак-
  симальному размеру блока базы данных для соответствующей платформы, умноженно-
  му на четыре. Если необходимо узнать это значение, установите LOG_BUFFER равным
  1 байт и перезапустите сервер.
  Теоретически минимальный размер буфера журнала повторного выполнения, неза-
  висимо от установок в файле init.ora, в данном случае - 65 Кбайт.
  
  
  Буферный кэш
  В буферном кэше сервер
  Oracle хранит блоки базы данных перед их записью на диск, а также после считывания
  с диска.
  Блоки в буферном кэше контролируются двумя списками. Это список "грязных" бло-
  ков, которые должны быть записаны процессом записи блоков базы данных(это DBWn;).
  Есть еще список "чистых" блоков, организован-
  ный в Oracle 8.0 и предыдущих версиях в виде очереди (LRU - Least Recently Used). Блоки упорядочивались по времени последнего использования. Этот алгоритм был не-
  много изменен в Oracle 8i и последующих версиях. Вместо физического упорядочения
  списка блоков, сервер Oracle с помощью счетчика, связанного с блоком, подсчитывает
  количество обращений ("touch count) при каждом обращении (hit) к этому блоку в буфер-
  ном кэше.
  интенсивно используемые блоки кэшируются надолго, а редко используемые - долго
  в кэше не задерживаются.
  В Oracle 8.0 добавлена возможность создания буферных пу-
  лов. С ее помощью можно зарезервировать в буферном кэше место для сегментов. Появилась возможность
  выделить место (буферный пул) достаточного размера для размещения целиком в памя-
  ти, например, таблиц-справочников". При чтении сервером Oracle блоков из этих таб-
  лиц они кэшируются в этом специальном пуле. Они будут конфликтовать за место в пуле
  только с другими помещаемыми в него сегментами. Остальные сегменты в системе бу-
  дут "сражаться" за место в стандартном буферном пуле. При этом повышается вероят-
  ность их кэширования: они не выбрасываются из кэша как устаревшие при считывании
  других, не связанных с ними блоков. Буферный пул, обеспечивающий подобное кэши-
  рование, называется пулом KEEP. Блоками в пуле KEEP сервер управляет так же, как
  в обычном буферном кэше. Если блок используется часто, он остается в кэше; если к
  блоку некоторое время не обращались и в буферном пуле не осталось места, этот блок
  выбрасывается из пула как устаревший.
  пулом RECYCLE. В нем
  блоки выбрасываются иначе, чем в пуле KEEP. Пул KEEP предназначен для продол-
  жительного кэширования "горячих" блоков. Из пула RECYCLE блок выбрасывается сразу
  после использования. Это эффективно в случае "больших" таблиц, которые читаются
  случайным образом. (Понятие "большая таблица" очень относительно; нет эталона для
  определения того, что считать "большим".) Если в течение разумного времени вероят-
  ность повторного считывания блока мала, нет смысла долго держать такой блок в кэше.
  Поэтому в пуле RECYCLE блоки регулярно перечитываются.
  
  Разделяемый пул
  Разделяемый пул - один из наиболее важных фрагментов памяти в области SGA,
  особенно для обеспечения производительности и масштабируемости. Слишком малень-
  кий разделяемый пул может снизить производительность настолько, что система будет
  казаться зависшей. Слишком большой разделяемый пул может привести к такому же
  результату. Неправильное использование разделяемого пула грозит катастрофой.
  В разделяемом пуле сервер Oracle кэширует раз-
  личные "программные" данные. Здесь кэшируются результаты разбора запроса. Перед
  повторным разбором запроса сервер Oracle просматривает разделяемый пул в поисках
  готового результата. Если 1000 сеансов выполняют тот же код, загружается и совместно
  используется всеми сеансами лишь одна копия этого кода. Сервер Oracle хранит в раз-
  деляемом пуле параметры системы. Здесь же хранится кэш словаря данных, содержа-
  щий информацию об объектах базы данных.
  Разделяемый пул состоит из множества маленьких (около 4 Кбайт) фрагментов па-
  мяти. Память в разделяемом пуле управляется по принципу давности использования
  (LRU). Самый простой способ поломать механизм разделяемого пула Oracle - не использо-
  вать связываемые переменные. Как было показано в главе 1, отказавшись от использо-
  вания связываемых переменных, можно "поставить на колени" любую систему, посколь-
  ку:
  • система будет тратить много процессорного времени на разбор запросов;
  • система будет тратить очень много ресурсов на управление объектами в разделя-
  емом пуле, т.к. не предусмотрено повторное использование планов выполнения
  запросов. Единственным решением этой проблемы является применение разделяемых опера-
  торов SQL, которые используются повторно.
  Большой пул
  Большой пул назван так не потому, что это "большая" структура (хотя его размер
  вполне может быть большим), а потому, что используется для выделения больших фраг-
  ментов памяти - больших, чем те, для управления которыми создавался разделяемый
  пул. При выделении же больших объемов памяти
  фрагмент выделяется, используется и после этого он не нужен, т.е. нет смысла его кэ-
  шировать.
  Серверу Oracle требовался аналог буферных пулов RECYCLE и KEEP в буферном
  кэше. Именно в таком качестве сейчас и выступают большой пул и разделяемый пул.
  Большой пул - это область памяти, управляемая по принципу пула RECYCLE, а раз-
  деляемый пул скорее похож на буферный пул KEEP: если фрагмент в нем используется
  часто, он кэшируется надолго.
  Память в большом пуле организована по принципу "кучи" и управляется с помощью
  алгоритмов, аналогичных используемым функциями malloc() и free() в языке С. После
  освобождения фрагмента памяти он может использоваться другими процессами.
  Большой пул, в частности, используется:
  • сервером в режиме MTS для размещения области UGA в SGA;
  • при распараллеливании выполнения операторов - для буферов сообщений, ко-
  торыми обмениваются процессы для координации работы серверов;
  • в ходе резервного копирования для буферизации дискового ввода/вывода утили-
  ты RMAN.
  
  Java-пул
  Java-пул - это самый новый пул памяти в Oracle 8i. Он был добавлен в версии 8.1.5
  для поддержки работы Java-машины в базе данных. Если поместить хранимую проце-
  дуру на языке Java или компонент EJB (Enterprise JavaBean) в базу данных, сервер Oracle
  будет использовать этот фрагмент памяти при обработке соответствующего кода.
  Java-пул используется по-разному, в зависимости от режима работы сервера Oracle.
  В режиме выделенного сервера Java-пул включает разделяемую часть каждого Java-клас-
  са, использованного хоть в одном сеансе. Эти части только читаются (векторы выпол-
  нения, методы и т.д.) и имеют для типичных классов размер от 4 до 8 Кбайт.
  При работе в режиме MTS Java-пул включает:
  • разделяемую часть каждого Java-класса и
  • часть области UGA для каждого сеанса, используемую для хранения информации
  о состоянии сеансов.
  Оставшаяся часть области UGA выделяется как обычно - из разделяемого пула или
  из большого пула, если он выделен.
  Поскольку общий размер Java-пула фиксирован, разработчикам приложений необ-
  ходимо оценить общий объем памяти для приложения и умножить на предполагаемое
  количество одновременно поддерживаемых сеансов. Полученное значение будет опре-
  делять общий размер Java-пула.
 Ваша оценка:

Связаться с программистом сайта.

Новые книги авторов СИ, вышедшие из печати:
О.Болдырева "Крадуш. Чужие души" М.Николаев "Вторжение на Землю"

Как попасть в этoт список

Кожевенное мастерство | Сайт "Художники" | Доска об'явлений "Книги"