Sga что это

Структуры памяти Oracle DataBase

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

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

Понятие о главной памяти

Все компьютеры используют память, которая в действительности состоит из иерархии различных уровней памяти. В сердце иерархии находится главная память (main memory), которая содержит все исполняемые инструкции и манипуляции данными. Вся главная память представляет собой память произвольного доступа (RAM), что означает возможность чтения байта из любого ее участка за одно и то же время. Обычно вы имеете доступ к данным в главной памяти за 10-100 наносекунд.

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

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

Oracle использует два типа структур памяти – общую и относящуюся к процессу. Системная глобальная область (system global area – SGA) – это часть общей памяти, которую разделяют между собой все серверные процесс (включая фоновые). Специфичная для процессов часть памяти известна как программная глобальная область (program global area — PGA), или принадлежащая процессу память (process-private memory). В последующих разделах мы рассмотрим эти два компонента памяти Oracle более подробно.

Системная глобальная область

SGA – наиболее важный компонент памяти в экземпляре Oracle. Особенно в крупных OLTP-базах данных SGA намного больше и важнее, чем PGA. В средах хранилищ данных, с другой стороны, PGA может быть более важно область памяти Oracle – ввиду ее решающего влияния на эффективность сортировок и хеширования больших объемов данных, что присуще аналитическим вычислениям в хранилищах данных.

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

SGA не является однородной областью. На самом деле это комбинация нескольких структур памяти.

Как минимум SGA включает следующие структуры данных:

• buffer cache
• log buffer
• shared pool:
• — library cache
• — data dictionary cache
• — PL/sQL area
• — SQL query and PL/SQL function result caches

Она также может включать:

• large pool
• java pool
• streams pool

Ниже перечислены основные компоненты SGA.

• Буферный кэш базы данных. Хранит копии блоков данных, прочитанных из файлов данных.
• Разделенный пул. Содержит библиотечный кэш для хранения разобранного SQL и PL/SQL кода, готового к использованию всеми пользователями. Он также содержит кэш словаря данных, который хранит всю информацию словаря.
• Буфер журнала повторного выполнения. Содержит информацию, необходимую для восстановления изменений, проведенных в базе данных операциями DML (языка манипулирования данными). Эта информация затем записывается в журналы повторного выполнения писателем журналов.
• Пул Java. Представляет пространство «кучи» для создания объектов Java.
• Большой пул. Хранит крупные выделения памяти, такие как резервные буферы RMAN.
• Пул потоков. Поддерживает средство Oracle Streams (средство для репликации данных между базами данных).

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

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

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

Буферный кэш базы данных

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

Буферы памяти в буферном кэше базы данных можно разделить на три группы:

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

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

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

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

Использование нескольких пулов буферных кэшей базы данных

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

Oracle обеспечивает гибкость в использовании буферного кэша, позволяя конфигурировать буферный кэш базы данных в множество буферных пулов. Буферные пулы в этот контексте — это просто части общего буферного кэша, отвечающие данным критериям удержания объектов базы данных данных вроде таблиц. Например, вы можете взять общий буферный кэш размером в 500 Мбайт и разделить его на три пула – два по 200 Мбайт и один в 100 Мбайт. Как только вы создадите данные буферные пулы, то сможете назначать им таблицы при создании для исключительного использования. Вы можете также применят команду ALTER TABLE или ALTER INDEX для модификации типа буферного пула, который должна использовать таблица или индекс.

Обратите внимание, что любым объектам базы данных, которым вы не назначаете определенный постоянный (keep) или повторно используемый (recycle) буферный пул, будут назначены в буферный пул по умолчанию, размер которого определен в соответствие со значением, указанным в параметре инициализации DB_CACHE_SIZE. Постоянный или повторно используемый буферные пулы необязательны, в то время как буферный пул по умолчанию – обязателен.

Помните, что главной целью назначения объектов в разные буферные пулы является минимизация «промахов» при обращении к кэшу данных и как следствие – минимизация операций дискового ввода-вывода. Фактически все стратегии буферного кэширования нацелены на это. Если вы не знаете, какие объекты в вашей базе данных к каким типам буферных кэшей отнести, запросите эту информацию из представления V$DB_CACHE_ADVICE, чтобы получить совет у Oracle.

Основные типы буферных пулов.

Буферный пул	Инициализационный параметр	Описание
Постоянный буферный пул (keep buffer pool)	DB_KEEP_CACHE_SIZE	Постоянно хранит блоки данных в памяти. У вас могут быть маленькие таблицы, к которым выполняются частые обращения и для предотвращения их удаления из буферного кэша им можно назначить постоянный буферный пул при создании таблицы.
Повторно используемый буферный пул (recycle buffer pool)	DB_RECYCLE_CACHE_SIZE	Удаляет данные из кэша немедленно после использования. Этот буферный пул следует применять осторожно, если вы вообще решите использовать его. Повторно используемый буферный пул удаляет объект из кэша сразу по завершении транзакции. Очевидно, что его следует применять только для крупных таблиц, обращение к которым осуществляется нечасто, и которые не нужно хранить к кэше неопределенно долго.
Буферный пул по умолчанию (default buffer pool)	DB_CACHE_SIZE	Содержит все данные и объекты, которые не назначены в постоянный и повторно используемый буферные пулы.

Множественные размеры блоков базы данных и буферный кэш

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

Параметр DB_BLOCK_SIZE в файле параметров инициализации определяет ваш стандартный и часто единственный размер блока для свей базы данных. Параметр DB_CAHCE_SIZE в вашем файле инициализационных параметров специфицирует размер (в байтах) кэша буферов со стандартным размером блоков. Обратите внимание, что вы не устанавливаете количество буферов базы данных, вместо этого вы специфицируете размер самого буферного кэша в параметре DB_CACHE_SIZE.

Вы можете иметь до пяти различных размеров блока в своих базах данных, т.е. можно создавать табличные пространства с одним из пяти доступных размеров блоков. Хотя большинство баз данных используют единственный стандартный размер блока. Хотя большинство баз данных используют единственный стандартный размер блока (такой как 4 Кбайт, 8 Кбайт или 16 К байт), можно также указать некоторые или все размеры четырех нестандартных блоков. Например, можно иметь некоторые таблицы типа хранилища данных, которые выиграют от крупного размера блока, например 32 Кбайт. Однако при этом большитсвто прочих таблиц в базе могут обслуживать нужды онлайновой обработки, и потому должны использовать стандартный размер блока в 4 Кбайт. Если вам случиться использовать все четыре из нестандартных размеров блока помимо стандартного, можете создать табличные пространства со всеми пятью размерами блоков. Однако прежде чем вы создадите эти табличные пространства с нестандартным размером блоков, вы должны сконфигурировать нестандартные подкэши в буферных кэшах для каждого размера блока, который хотите использовать. Специфицировать нестандартные буферные подкэши можно с помощью параметра инициализации DB_nK-CACHE_SIZE, где n- размер блока в Кбайт, который может принимать значения 2,4,8,16 или 32.

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

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

DBKEEP_CACHE_SIZE = 48MB
DB_RECYCLE_CACHE_SIZE = 24MB
DB_CACHE_SIZE = 128MB / Стандартный размер блока 4 Кбайт /
DB_2k_CACHE_SIZE = 48MB / нестандартный размер блока 2 Кбайт /
DB_8k_CACHE_SIZE = 192MB / нестандартный размер блока 8 Кбайт /
DB_16k_CACHE_SIZE = 384MB / нестандартный размер блока 16 Кбайт _/

Общий размер буферного кэша в этом примере составит сумму все приведенных поэкэшей, равную 824 Мбайт.

Коэффициент попаданий в буферный кэш

Чтение из буфера происходит намного быстрее, чем чтение с диска. Важнейший принцип правильного определения размера буферного кэша можно сформулировать одной фразой: «затрагивать как можно меньшее количество блоков», поскольку дисковый ввод-вывод, необходимый для чтения данных из блоков Oracle на диске, обходится много дороже чтения данных из SGA. Вот почему коэффициент попаданий (hit ratio), измеряющий процент времени, когда пользователь получает нужные ему данные из буферного кэша (вместо чтения диска), является настолько важным индикатором производительности экземпляра Oracle.

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

Коэффициент попаданий = (1- (физических чтений) / (логических чтений) * 100)

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

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

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

Разделяемы пул

Разделяемы пул (share pool) очень важная часть Oracle SGA, и правильное определение его размера для вашего экземпляра поможет устранить несколько типов узких мест в экземпляре Oracle. В отличие от буферного кэша базы данных, который хранит действительные блоки данных, разделяемый пул хранит исполняемый код PL/SQL и операторы SQL вместе с информацией, относящейся к таблицам словаря данных. Словарь данных – это набор ключевых таблиц, поддерживаемых Oracle и содержащих важнейшие данные о таблицах базы, пользователях, привилегиях и тому подобном.

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

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

Библиотечный кэш

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

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

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

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

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

Кэш результатов

В Oracle Database 11G появился замечательный новый компонент SGA, именуемый кэшем результатов (result cache). Кэш результатов – ото область SGA, именуемый кэшем результатов (result cache). Кэш результатов – это область SGA, где база данных хранит результаты как запросов SQL, так и функций PL/SQL, если вы включаете эти кэши. Когда база данных выполняет некоторый запрос SQL вновь, она может просто извлечь результат из кэша результата в вместо повторного выполнения того же запроса, тем самым существенно повышая производительность. Кэширование результата функций PL/SQL работает очень похоже на кэш результатов запросов SQL. Когда кэшированная функция выполняется повторно, база данных не выполняет ее тело вновь, а вместо этого просто сразу возвращает кэшированные результат.

Вы используете инициализационный параметр RESULT_CACHE_MODE, чтобы контролировать поведение кэширования базой данных результатов запросов SQL и функций PL/SQL. Можно также использовать подсказку нового кэша результатов, чтобы переопределить установку параметра RESULT_CACHE_MODE. Управлять кэшированием можно через PL/SQL пакет DBMS_RESULT_CACHE или с помощью Enterprise Manager.

Буфер журнала повторного выполнения

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

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

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

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

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

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

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

Большой пул и Java-пул

Большой пул (large pool) – это просто необязательный пул памяти, которым Oracle управляет иначе, чем разделяемый пулом. Большой пул понадобится конфигурировать только в том случае, если вы используете в базе данных параллельные запросы. Oracle также рекомендует конфигурировать этот пул, если вы применяете RMAN или конфигурацию разделяемого сервера вместо стандартной конфигурации выделенного сервера. Вы устанавливаете размер этого пула в инициализационном файле, используя параметр LARGE_POOL_SIZE. Большой пул памяти важен, если применяется архитектура разделяемого сервера.

Пул Java (устанавливаемый параметром JAVA_POOL_SIZE) предназначен для баз данных, которые содержат много кода Java, так что обычной области SGA недостаточно для размещения компонентов, использующих объекты Java. Пул памяти java резервируется для виртуальной машины Java (JVM) и для ваших приложений Java. В случае развертывани яEnterprise JavaBeans или применения CORBA потенциально понадобится размер пула java свыше 1 Гбайт.

Пул Streams

Oracle Streams – это технология, которая позволяет разделять общие данные между разными базами данных и между разными средами приложений. Пул Stream – это память, выделенная для поддержки деятельности Streams в вашем экземпляре. Если вы вручную устанавливаете копоенет пула Streams, используя инициализационный параметр STREAMS_POOL_SIZE, память для этого пула передается из буферного кэша после первого обращения к Streams. Если вы используете автоматическое управление памятью, то память для пула Streams заимствуется из глобального пула SGA. Переданный объем составляет до 10% от размера разделяемого пула.

Программная глобальная область

Oracle создает программную глобальную область (PGA) для каждого пользователя при открытии пользовательского сеанса. Эта область содержит данные и управляющую информацию для выделенного серверного процесса, который Oracle создает для каждого индивидуального пользователя. В отличие от SGA, PGA предназначена для исключительного использования каждый серверным процессом и не может разделяться между несколькими процессами. Регистрационная информация сеанса и постоянная информация, такая как информация о привязке переменных и соглашениях о типах данных, по–прежнему является частью SGA, если только вы не применяете конфигурацию разделяемого сервера но область времени выполнения, используемая операторами SQL располагается в PGA.

Например, пользовательский процесс может иметь некоторые курсоры (дескрипторы областей памяти, где вы храните значения переменных), ассоциированные с ним. Поскольку это пользовательские курсоры, они не разделяются автоматически с другими пользователями и потому PGA – подходящее место для хранения этих частных значений. Другое основное использование PGA ориентировано на выполнение требовательных к памяти операций SQL, которые включают сортировку, таких как запросов с конструкцией ORDER BY или GROUP BY. Таким операциям нужна некоторая рабочая область, и PGA обеспечивает эту область памяти.

Память PGA относится к следующим двум типам:

• Частная область SQL. Эта область памяти содержит информацию о привязке переменный SQL и структуры памяти времени выполнения. Каждый сеанс, выполняющий оператор SQL, получает свою собственную частную область SQL.
• Область времени выполнения. Область времени выполнения создается для пользовательского сеанса, когда тот выдает оператор SELECT, INSERT, UPDATE или DELETE. После запуска оператора SELECT, INSERT, UPDATE или DELETE либо после извлечения результатов оператора SELECT область времени выполнения освобождается Oracle.

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

Чтобы сократить время реакции, все сортировки, выполняемые в PGA, должны полностью проходить в кэше рабочей области. Это называется операцией оптимального режима (optimal mode operation), поскольку вся работа выполняется в памяти, без дискового ввода-вывода. Если сортировка требует обращения к диску, поскольку области памяти для нее недостаточно, это сильно замедляет операцию сортировки. Операция SQL, которая вынуждена обращаться к дисковой памяти даже в ограниченной степени – однопроходная операция – происходит медленнее, чем операция, полностью выполняемая в области памяти. Однако если ваша область памяти времени выполнения слишком мала по сравнению с потребностями операции сортировки. Oracle приходится осуществлять несколько проходов по сортируемым данным, что очень нагружает диск и значительно увеличивает время реакции для пользователя. Таким образом, существует прямая зависимость между размером PGA и производительность запросов.

Вы можете настраивать размеры этих частных рабочих областей, но это подход «наудачу», который требует учета множества сложных конфигурационных параметров Oracle, касающихся рабочих областей памяти. К параметрам, которые нужно устанавливать вручную, относятся SORT_AREA_SIZE, HASH_AREA_SIZE и BITMAP_AREA_SIZE.

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

Вы автоматизируете выделение памяти PGA, устанавливая параметр инициализации WORKAREA_SIZE_POLICY в его значение по умолчанию – auto. Если вы установите значение этого параметра в manual, то должны будете специфицировать все параметры рабочей области PGA, упомянутые выше. Параметр WORKAREA_SIZE_POLICY гарантирует автоматизацию памяти PGA. Однако вы должны также установить размер общей выделенной памяти PGA, указав значение инициализационного параметра PGA_AGGREGATE_TARGET. Например, если вы установите в файле параметров инициализации PGA_AGGREGATE_TARGET=5000000000, то Oracle использует 5 Гбайт выделенной памяти PGA в качестве глобальной установки для экземпляра. Oracle будет удерживать общий объем памяти PGA, используемой всеми серверными процессами экземпляра, в пределах этой величины.

Если вы не установите параметр PGA_AGGREGATE_TARGET, то должны будете использовать ручной режим управления рабочими областями. В качестве альтернативы можно активизировать ручной режим, установив параметр WORKAREA_SIZE_POLICY в manual. Oracle настоятельно рекомендует применять автоматическое управление PGA, поэтому что оно позволяет более эффективно использовать память. Для пользователей это означает более высокую производительность и сокращение времени выполнения запросов в целом.

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

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

Автоматическое управление памятью

В прежних версиях Oracle администраторы тратили довольно много времени на подбор правильного размера SGA. Ничего необычного не было в том, чтобы довольно часто выполнять перекалибровку размера SGA, добиваясь оптимальной настройки экземпляра. В Oracle Database 11g вы можете конфигурировать автоматическое управление памятью, используя новый параметр инициализации MEMORY_TAGRET. Все, что необходимо сделать для этого – это присвоить определенное значение параметру MEMORY_TARGET, и Oracle возьмет на себя автоматическое распределение памяти между компонентами SGA и PGA. Выделение памяти SGA Oracle различным компонентам происходит не статически, а меняется по мере изменения загрузки базы данных. Oracle может автоматически управлять следующими пятью компонентами SGA (соответствующие инициализационные параметры Oracle указаны в скобках):

• Буферный кэш базы данных (DB_CACHE_SIZE);
• Разделяемы пул (SHARED_POOL_SIZE);
• Большой пул (LARGE_POOL_SIZE);
• Пул Java (JAVA_POOL_SIZE);
• Пул потоков (STREAMS_POOL_SIZE);

Как видите, Oracle автоматически настраивать пять компонентов SGA, которые мы называем параметрами SGA с автоматически устанавливаемым размером. Вы должны по-прежнему самостоятельно управлять остальными компонентами SGA, даже при автоматическом управлении памятью.

Ниже приведены настраиваемые вручную компоненты SGA:

• Постоянный буферный кэш (DB_KEEP_CACHE_SIZE);
• Повторно используемый буферный кэш (DB_RECYCLE_CACHE_SIZE);
• Все буферные кэши нестандартного размера блока (DB_nK_CACHE_SIZE);
• Буфер журнала повторного выполнения (LOG_BUFFER).

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

Опции управления памятью и умолчания в инсталляции базы данных

Когда вы создаете базу данных с помощью DataBase Configuration Assistant (DBCA) и если выбираете базовую опцию инсталляции, то автоматическое управление памятью включено по умолчанию. Если же вместо этого вы предпочтете расширенную опцию инсталляции, нужно будет выбрать одну из следующих трех конфигураций памяти:

• Автоматическое управление памятью;
• Автоматическое управление разделяемой памятью плюс автоматическое управление памятью PGA;
• Ручное управление разделяемой памятью плюс автоматическо еупрвление памятью PGA.

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

Tags: Oracle Database, Память

Очищающая, смазывающая присадка в бензин СГА (SGA) для снижения расхода топлива, восстановления работы форсунок, 100мл

Присадка в топливо СУПРОТЕК АПРОХИМ SGA мягко очищает топливную аппаратуру, смазывает ее, защищает от коррозии, предотвращает образование отложений. Это восстанавливает рабочие характеристики топливных насосов, инжекторов или форсунок, защищает их от износа, продлевает срок службы.

Комплексное восстановление топливной аппаратуры улучшает впрыск, приводит к снижению расхода топлива, повышению динамики.

Для постоянных потребителей присадка доступна по сниженной цене в упаковке box — 9 флаконов по 50 мл.

Количество:

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

Очистка насосов, снижение износа плунжеров нормализует давление топлива в системе. Очистка клапанов, каналов и сопла форсунок — продлевает их срок службы. Все вместе это обеспечивает качественный распыл топлива и более полное его сгорание, что приводит к следующим эффектам:

• снижение расхода топлива на 5%-15% в зависимости от состояния автомобиля.
• продление срока службы топливной аппаратуры.
• снижение вибраций за счет равномерного сгорания топлива в цилиндрах.
• снижение нагрузки на турбину, катализаторы, дожигатели топлива, что продлевает их ресурс.
• снижение загрязнений в моторном масле, что сохраняет его рабочие свойства и в конечном итоге сокращает износ двигателя.

Присадка SGA рассчитана на постоянное применение, поэтому имеет сбалансированную «мягкую» рецептуру. Она постепенно удаляет загрязнения и отложения и предотвращает образование новых. Присадка не содержит «промоторов горения» или других веществ, изменяющих режимы работы двигателя.

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

В чем отличия присадки от очистителя?

«Очиститель» является более активным средством. Он безопасен для двигателя в случае разового применения, однако его не рекомендуется применять слишком часто. Состав «SGA» является средством постоянного применения и имеет сбалансированную безопасную рецептуру, которая не нарушает работы двигателя.

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

Как пользоваться присадкой и очистителем для комплексного ухода за топливной системой?

Присадку «SGA» и «Очиститель топливной системы» лучше использовать по очереди, как показано на схеме ниже. Если у автомобиля система непосредственного впрыска или он имеет сильные загрязнения топливной системы. то сначала рекомендуется использовать присадку. В остальных случаях в начале рекомендутся использовать очиститель, а зтем поддерживать систему с помощью присадки.

Можно ли заливать в бак одновременно «Очиститель топливной системы» и присадку «SGA»?

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

Характеристики
Область применения
Тип двигателя бензин / газ
Обрабатываемые агрегаты Насосы / форсунки
Тип транспорта легковой / коммерческий / внедорожник / грузовой; спец.техника
Основные характеристики
Назначение очистка / смазка / защита
Вес, гр 150
Упаковка коробка
Комплектация коробка, инструкция
Форма выпуска флакон
Объём, мл 2*50
Дополнительная информация
Срок годности 2 года
Меры предосторожности огнеопасно
Производитель
Страна производства Россия
Производитель Супротек-Апрохим

Инструкция по применению

1 флакон 50 мл рассчитан на 40 – 60 литров топлива (примерно 1 мл на 1 литр топлива). Перед заправкой автомобиля залейте присадку в топливный бак.

Для этого:

• тщательно взболтайте содержимое флакона;
• откройте флакон и залейте присадку в топливный бак (при необходимости воспользуйтесь топливной воронкой);
• заправьте машину топливом.

При пробеге автомобиля более 50 000 километров при первых двух заправках рекомендуется заливать 2 флакона по
50 мл на 40 — 60 литров топлива (или из расчета 2 мл на 1 л. топлива).

Как пользоваться присадкой и очистителем для комплексного ухода за топливной системой?

Присадку «SGA» и «Очиститель топливной системы» лучше использовать по очереди. Рекомендуется начать очистку с применения присадки, а примерно через 10 000 км пробега использовать «Очиститель». Затем продолжать использовать присадку и повторять общую очистку каждые 10 000 км.

Можно ли заливать в бак одновременно «Очиститель топливной системы» и присадку «SGA»?

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

Примечания

Рецептура присадки «SGA (СГА)» является собственной разработкой компании «Супротек». Все компоненты присадки производятся в Германии и поставляются в РФ по прямому соглашению с производителем.

Присадка прошла годовой цикл стендовых испытаний и тестирования на автомобилях разных классов в нескольких регионах России с использованием топлива различных заправочных сетей.

Состав «SGA (СГА)» тщательно сбалансирован для обеспечения безопасности его применения. Очистка топливной аппаратуры осуществляется постепенно и «мягко» за счет использования ПАВ, а не активных растворителей. Механизм действия поверхностно-активных веществ гарантирует безопасность присадки для топливных фильтров, элементов топливной аппаратуры из пластика и композиционных материалов, железосодержащих материалов.

Присадка в бензин СУПРОТЕК «SGA (СГА)» не содержит октан-корректоров, не изменяет температуру или скорость сгорания топлива.

Состав СУПРОТЕК «SGA (СГА)» может использоваться с любыми типами систем впрыска. Особенное внимание при разработке рецептуры было уделено эффективности и безопасности применения присадки в системах непосредственного впрыска топлива (TFSI, TSI, GDI и системах других марок), которые работают в условиях высокого давления в топливной рампе, а, значит, имеют повышенный уровень требований к точности работы форсунок. Даже незначительные загрязнения сопла форсунки приводят к существенному дисбалансу в работе электрогидравлических форсунок и форсунок с использованием пьезоэлектрических клапанов, что нарушает режим впрыска топлива и в конечном счете приводит к быстрому выходу форсунок из строя (обмотки электромагнита или пьезокристалла). В системах внешнего смесеобразования (инжекторных и карбюраторных) присадка сохраняет эффективность, поскольку действие очищающих компонентов не зависит от давления в топливной системе и устройства агрегатов.

ОСТОРОЖНО! ГОРЮЧАЯ ЖИДКОСТЬ! ПРЕДОХРАНЯТЬ ОТ ВОЗДЕЙСТВИЯ ПРЯМЫХ СОЛНЕЧНЫХ ЛУЧЕЙ И НАГРЕВАНИЯ ВЫШЕ 40С! ХРАНИТЬ В ПРОХЛАДНОМ, ХОРОШО ВЕНТИЛИРУЕМОМ МЕСТЕ В ПЛОТНО ЗАКРЫТОЙ/ГЕРМЕТИЧНОЙ УПАКОВКЕ.

ТОПЛИВНАЯ ПРИСАДКА «SGA» И «ОЧИСТИТЕЛЬ ТОПЛИВНОЙ СИСТЕМЫ» – КАК ПОЛЬЗОВАТЬСЯ?

«Супротек» предлагает два разных продукта, связанных с очисткой топливной системы: присадку к бензину «SGA» и «Очиститель топливной системы».

В чем отличие присадки и очистителя?

• «Очиститель» является более активным средством. Он безопасен для двигателя в случае разового применения, однако его не рекомендуется применять слишком часто. Состав «SGA» является средством постоянного применения и имеет сбалансированную безопасную рецептуру, которая не нарушает работы двигателя.
• Добавка предназначена для постоянной очистки тонких топливных каналов и деталей внутри форсунок, инжекторов и насосов. Вследствие «мягкой» рецептуры она не оказывает воздействия на значительные загрязнения в топливном баке, топливопроводах, в камере сгорания. «Очиститель» же как раз нацелен в первую очередь на удаление сажи из камеры сгорания, связывание воды в топливном баке, растворение лаков и отложений на протяжении всей топливной системы.
• Основная и единственная задача «Очистителя» – удаление загрязнений из топливной системы. Присадка в бензин «SGA» является многофункциональной. Она содержит смазывающие добавки, ингибиторы коррозии и модификатор трения, которые продлевают срок службы прецизионной топливной аппаратуры.

Как пользоваться присадкой и очистителем для комплексного ухода за топливной системой?

• Автомобили с небольшим пробегом (менее 40-50 тысяч километров). При малом пробеге топливная система автомобиля скорее всего находится в достаточно чистом состоянии. Рекомендуется начать постоянное использование добавки «SGA» для поддержания рабочих характеристик топливной аппаратуры. Приблизительно через 10 000 километров пробега рекомендуется использовать «Очиститель топливной системы» для очистки камеры сгорания, и повторять его применение через каждые 10 000 километров пробега.
• Автомобили с большим пробегом и системой внутреннего смесеобразования (системы впрыска TFSI, TSI, GDI, MPI и другие). Системы непосредственного впрыска работают в условиях большого давления топлива и особо чувствительны к качеству топлива. Рекомендуется начать уход за топливной системой с постоянного применения «SGA». Она обеспечит нормальное функционирование форсунок и насоса высокого давления, уберет из них уже существующие загрязнения. После этого, примерно через 8-10 тысяч километров пробега, рекомендуется применение «Очистителя топливной системы». Его применение с нормально работающими форсунками будет безопасным. Рекомендуется повторять обработку «очистителем» через каждые 10 000 километров пробега.
• Автомобили с большим пробегом и системой внешнего смесеобразования (инжекторные и карбюраторные двигатели). Топливные системы этих автомобилей достаточно надежны и нетребовательны. Рекомендуется сначала произвести комплексную очистку с помощью «Очистителя топливной системы» (1 флакон на 1 бак топлива). Это даст начальный позитивный эффект в нормализации работы двигателя. Начиная со следующей заправки рекомендуется начать постоянное применение состава «SGA» для поддержания достигнутых эффектов. Повторное применение «Очистителя» рекомендуется через каждый 10 000 километров пробега.

Можно ли заливать в бак одновременно «Очиститель топливной системы» и присадку «SGA»?

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

Присадку «SGA» рекомендуется использовать в первую очередь для восстановления рабочих характеристик топливных инжекторов и форсунок. Симптомами нарушения их работы из-за загрязнений могут быть следующие признаки:

• Увеличение расхода топлива на 1 литр и более;
• Падение динамики разгона автомобиля;
• «Жёсткая» работа двигателя;
• Повышение расхода топлива;
• Характерный запах не сгоревшего топлива из глушителя;
• Неровная работа двигателя на холостых оборотах;
• Чёрный дым при резком наборе скорости;
• Затруднённый запуск холодного двигателя;

Все это свидетельствует о нарушении правильной и своевременной подачи топлива в камеры сгорания одного или нескольких цилиндров. Постоянное применение «SGA» при нескольких заправках подряд с высокой степенью вероятности позволит избавиться от этих проблем.

Структуры памяти экземпляра БД

Экземпляр БД Oracle состоит из блоков разделяемой памяти, называемых system global area (SGA) и background процессов. SGA содержит три обязательные структуры данных:

• Thedatabasebuffercache / содержит копии блоков данных считанные из файлов данных
• Thelogbuffer / содержит данные о транзакциях которые ещё не записаны в redolog
• Thesharedpool / содержит проверенные SQL выражения и кэш словаря данных, содержащий таблицы, представления и триггеры.

Также дополнительно могут быть:

• Largepool
• Javapool
• Streemspool

Эти структруры показаны на рисунке 1-5 и мы обсудим обязательные структуры.

Пользовательские сессии тоже требуют памитя на сервере. Как мы помним это неразделяемая область памяти, которая называется PGA. У каждой сессии своя PGA.

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

Database buffer cache

Database buffer cache – это область где выполняются SQL команды. Когда мы обновляем данные, они не изменяются непосредственно в файлах данных на жёстком диске. Блоки данных, которые содержат данные с которыми мы работает вначале копируются в buffer cache (если они ещё не находятся там). Изменения (вставка, измнение или удаление данных) применяются к этим копиям данных в буфферном кэше. Затем эти блоки данных остаются в памяти некоторое время, пока место которое они занимают не понадобится для работы над какими-либо другими данными.

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

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

В идеале – блоки данных содержащие наиболее часто используемые данные будут в buffer cache, таким образом снижая количество операций чтения/записи. Как типичный пример работы буфер кэша рассмотрим пример типичной операции продавца в магазине, который получает данные о клиенте и обновляет их. Будут использованы примерно такие запросы:

SELECT CUSTOMER_ID,CUSTOMER_NAME FROM CUSTOMERS;

UPDATE CUSTOMERS SET CUSTOMER_NAME=’Вася’ WHERE CUSTOMER_ID=100;

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

Потом пользователь запускает команды UPDATE и COMMIT, которые будут обработаны серверным процессом. Допуская, что данные всё ещё доступны в buffer cache на момент выполнения этого запроса, строка будет обновлена в буфер кэше. В данном примере мы получим эффективность использования буфера – 50%. 2 раза доступ к данным в кэше буфера, один раз чтение данных с диска. Формула расчёта: 1-«кол-во чтений с диска»/кол-во чтений с буфера»). В хорошо оптимизированных базах данных этот показатель может достигать 90%.

Буффер в котором данные в блоках отличаеются от данных этих блоков на дисковом пространстве – называбтся грязными (dirty buffers). Буфер будет чистым (clean) когда блок только скопирован с диска в память: в этот момент времени данные одинаковые и в памяти и на диске. В итоге, грязные блоки данных должны быть записан назад на диск и тогда буфер опять станет чистым. Но даже после записи на диск, блоки остаются в памяти, пока их не перепишут другими блоками.

Важно, что нету прямой зависмости количества обновлений данных в буфере (комманд COMMIT) и количества операция записи данных назад в файлы данных. Запись в файлы данных производится background process-ом – database writer.

Размер buffer cache очень важен для производительности. Значение должно быть адекватно рассчитано, не минимальное — чтобы все часто используемые блоки (неважно чистые или грязные) находились в буфере, но не настолько большое чтобы даже редко используемые данные тоже находились в буфере. Недостаточный объём приведёт к избыточному использованию чтения/записи с диска, так как блоки будут читаться с диска, тут же переписываться и снова читаться. Слишком большой объём не настолько плохо как слишкомй маленький (пока он меньше чем размер реальной доступной оперативной памяти) но тоже может вызывать определённые проблемы: например запуск базы данных будет дольше, так как требуется форматирование большого объёма памяти.

Память для buffer cache выделяется на этапе запуска экземпляра БД. До версии 9i нельзя изменить размер буфер кэша без перезапуска инстанса. Начиная с версии 10 g – размер буфера кэша можно изменять как автоматически (включить механизм автоматическго управления), так и вручную.

Буфер логов (log buffer)

Буфер логов – это небольшая, краткосрочная выделенная область памяти для хранения записей изменений (change vector) до записи их в журнал (redo log) на диске. Запись изменений – это изменение произошедшее с чем либо; выполнений DML команда создаёт записи изменений. Сохранение всех таких записей – это гарантия того, что данные никогда не будут утеряны. Когда бы не изменились данные в блоке – запись изменений в блоке должна быть записана в журнал. Впоследствии эти записи могут быть считаны и применены к резервной копии файлов данных, если возникла необходимость.

Изменения не пишутся в журнал серверными процессами сессий. Если бы это было реализовано таким образом, сессиям пришлось бы ждать выполнения операций чтения/записи чтобы закончить выполнения любой DML команды. Вместо этого сессии пишут в буфер логов в памяти. Это гораздо быстрее чем писать на диск. Уже из буфера логов записи изменений (сформированные из разных сессий) пишутся в журнал.Одна операция записи в журнал может влючать множество изменений. Эти изменения пишутся примерно в реальном времени – но как только какая-нибудь сессия исполняет команду COMMIT – тут же происходит запись в журнал. Запись осуществляется background процессом – log writer-ом (LGWR).

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

Невозможно задать значение, меньше чем значение по умолчанию. Если попробовать сделать это, Oracle просто установит значение по умолчанию. Можно установить большее значение, но обычно этого делать не стоит. Основаная проблема в том, что когда выполняется команда COMMIT, запускается запись изменений из буфера на диск, и пока операции записи осуществляется, сессия которая запустила команду COMMIT будет ждать. Запись изменений важная часть архитектуры Oracle. Идея того что подтверждённые изменения никогда не будут утеряны в том, что выполнение команды commit считается успешным только тогда, когда данные изменены в buffer cache и записи зименений (vector change) записаны в журнал на диске (это значит что изменения могуть быть повторены при необходимости). Большой буфер логов может привести к тому что операция записи из него на диск будет занимать длительное время, а в это время сессия не может продолжать работу.

Память для буфера логов выделяется в момент запуска экземпляра БД и размер не может быть изменен без перезапуска. Это круговой буффер. Серверные процессы пишут записи изменений, и текущий указатель перемещается. Log writer записывает эти изменения на диск группами, и когда он это делает, место занятое этими записями становится снова доступным и может быть переписано новыми записями. В момент самой высокой нагрузки на сервер, может случиться так, что новые векторы должны быть записаны быстрее чем log writer может записать их на диск. Если такое случается все команды манипулированяи данными будут «подвисать» на некоторое время, пока log writer не очистит буфер.

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

The shared pool

Shared pool самая сложная область в SGA. Она состоит из под-областей, которые управляются Oracle сервером. Мы обсудим только 4 кмпонента:

Data dictionary cache

SQL PL/SQL function result cache

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

Library cache

Library cache это область памяти где хранятся последние выполненные запросы в разобранном виде. Разбор (parsing) – это процесс преобразования инструкция написанный программистом в исполняемые команды понятные Oracle. Этот процесс Oracle запускает по требованию. Хранение разобранных команд очень сильно увеличивает производительность, потому что процесс разбора занимает время. Рассмотрим пример простого запроса:

SELECT * FROM PRODUCTS WHERE PRODUCT_ID=100;

Перед тем как выполнять запрос, надо узнать что написано в запросе и как его выполнять. Начиная с того, что такое PRODUCTS? Мжет быть это таблица? Или синоним, представление? Вообще существует ли такой объект? Дальше символ «звездочка» — какие столбцы в таблице PRODUCTS (если это действительно таблица)? Есть ли у пользователя необходимые права чтобы просматривать эту таблицу? Вопросы на эти ответы и многие другие надо найти в словаре данных. Важное замечание – алгоритм поиска разобранного запроса в кэше базируется на ASCII символах которые использованы в запросе. Небольшое различие (к примеру использование строчных символов вместо прописных) может привести к тому что запрос будет разбираться опять.

После разбора запроса, сервер должен решить как наиболее оптимально выполнять его. Есть ли индекс для поля PRODUCT_ID? Если он есть, будет ли быстрее использовать индекс чтобы найти нужную строку, или проще просмотреть всю таблицу? И ещё больше и больше запросов в словарь данных. Бывает что для простого запроса надо создать много запросов в словарь данных и разбор занимает больше времени чем выполнение самого запроса. Смысл library cache – хранить запросы в разобранном виде, готовые к выполнению. Первый вызов необходимо обработать – второй вызов такого же запроса, тут же готов к выполнению. В хороших приложениях запросы подготавливаются один раз – а выполняются миллионы раз. Это позволяет сэкономить огромное количество времени.

Кэш словаря данных (Data dictionary cache)

Data dictionary cache иногда называют row cache. В нём хранятся определения использованных объектов: описания таблиц, индексов, пользователей и другие мета-данные. Хранения этих данные в кэше в памяти SGA, где они доступны для всех сессий, в отличии от чтения их со словаря данных с диска, сильно увеличивает производительность разбора команд.

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

SELECT SUM(ORDER_AMOUNT) FROM ORDERS;

SELECT * FROM ORDERS WHERE ORDER_NO=100;

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

Область PL/SQL (PL/SQL Area)

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

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

SQL Query and PL/SQL Function Result Cache

Данный кэш появился в версии 11 g. Во многих приложениях, одинаковые запросы выполняются много раз, или одной сессией или разными. Создание этого кэша позволило Oracle серверу хранит результаты подобных запросов в памяти. Когда запрос будет выполняться повторно вместо его реального выполнения, результат возьмётся из кэша.

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

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

По умолчанию, SQL Query PL/SQL function result cache отключен. Но если его включить – можно получить очень существенное ускорение производительности. Для данного вида кэша администратор может установить максимальный размер памяти.

Управление размером shared pool

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

Память в shared pool выделятся согласно алгоритму LRU (least recently used). Когда нужно выделить место в shared pool, сервер будет искать объекты которые не использовались дольше всех. Если этот объект потом понадобится опять – его придется перезагрузить (возможно снова удалив другой объект).

Shared pool выделяет память в момент запуска экземпляра БД. Начиная с версии 9i размер может изменяться динамически без перезапуска, либо механизмом атовматического управления, либо администратором.

1. Single-instance архитектура
2. Необходимые определения
3. Семейство продуктов Oracle

Перевод «SGA» на русский

For this purpose, SGA have associates who have previously worked as bailiffs, and have extensive enforcement experience.

В этих целях SGA имеет юристов, ранее работавших судебными исполнителями и имеющих существенный опыт.

In its litigation and arbitration practice SGA represent clients in different categories of disputes.

В своей судебной и арбитражной практике SGA представляет клиентов по разным категориям споров.

Ask your SGA representative and/or the Student Affairs Office to establish what protocols are required of faculty who will be absent from teaching duties.

Попросите вашего СГА представителя и/или отделом по студенческим вопросам, чтобы определить, какие протоколы необходимы факультета, который будет отсутствовать на учебных обязанностей.

The SGA contains all information necessary for the instance operation.
SGA содержит всю необходимую информацию для операций экземпляра.

A similar architecture was previously used by performance optimization products that also used the SGA and other shared data structures.

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

SGA lawyers represent clients in tax, business, customs, land and administrative disputes.

Юристы SGA представляют интересы клиентов по налоговым, хозяйственным, таможенным, земельным и административным спорам.

SGA represents clients during all stages of court enforcement.
SGA представляет интересы клиентов на всех стадиях исполнительного производства.
Substantial gainful activity (SGA) is a specified dollar amount.
Значительный доход деятельности (SGA) является доллар, указанной суммы.
Completed study in «SGA» school, qualification: cosmetologist-mesotherapy specialist.
Прошла обучение в школе «SGA», квалификация: специалист косметологии-мезотерапии.

The agency pairs SGA with a list of medical conditions that qualify individuals for disability benefits.

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

The proposed SGA token will be available for purchase in Q4 2018, although only for accredited investors.

Предполагаемый токен SGA будет доступен в четвёртом квартале 2018 года, однако лишь аккредитованным инвесторам.

The current state of information does not support or refute and association between major depressive disorders and LBW or SGA delivery.

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

Like libra, SGA features the characteristics of a so-called stablecoin, which seeks to avoid the volatility of cryptocurrencies like bitcoin.

Как и Libra, SGA обладает характеристиками так называемого стейблкоина, который стремится избежать волатильности криптовалют, таких как биткоины.

Extensive practical experience, professionalism and mobility of SGA team predetermined its successful practice, and highly appreciated by our Clients.

Большой практический опыт, профессионализм и мобильность команды SGA в этом направлении предопределили ее успешную практику, и не раз были высоко отмечены клиентами.

In the legal practice of SGA this type of service is highlighted as a separate self-direction and is one of the most sought-for the Clients.

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

The SSA employs higher threshold levels of SGA for persons with specific disabilities, such as blindness.

ССС работает выше порогового уровня SGA для людей с определенными недостатками, как, например, слепоте.

Full-term and premature newborns (including SGA): GK 4300
Доношенные и недоношенные новорожденные (в том числе и SGA): ГК 4300 г.

SGA was founded in 2008 by a group of leading lawyers with experience in various areas of Kazakhstani and international law.

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

The dispatcher will first place this request onto the request queue in the SGA (1).
Диспетчер поместит этот запрос в очередь запросов в области SGA (1).
This condition is called small for gestational age (SGA).
Это состояние называется небольшой для гестационного возраста (SGA)
Возможно неприемлемое содержание

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

Зарегистрируйтесь, чтобы увидеть больше примеров. Это просто и бесплатно
Ничего не найдено для этого значения.
Предложить пример
Больше примеров Предложить пример

Новое: Reverso для Windows

Переводите текст из любого приложения одним щелчком мыши .

Скачать бесплатно
Перевод голосом, функции оффлайн, синонимы, спряжение, обучающие игры

Результатов: 163 . Точных совпадений: 163 . Затраченное время: 76 мс

Помогаем миллионам людей и компаний общаться более эффективно на всех языках.