Изменить размер log buffer oracle
This chapter describes how to tune the database buffer cache. If you are using automatic memory management to manage the database memory on your system, there is no need to manually tune the memory caches described in this chapter.
This chapter contains the following topics:
About the Database Buffer Cache
For many types of operations, Oracle Database uses the buffer cache to store data blocks read from disk. Oracle Database bypasses the buffer cache for particular operations, such as sorting and parallel reads.
To use the database buffer cache effectively, tune SQL statements for the application to avoid unnecessary resource consumption. To meet this goal, verify that frequently executed SQL statements and SQL statements that perform many buffer gets are well-tuned.
When using parallel query, consider configuring the database to use the database buffer cache instead of performing direct reads into the Program Global Area (PGA). This configuration may be appropriate when the system has a large amount of memory.
Oracle Database SQL Tuning Guide for information about tuning SQL statements
About the Database Buffer Cache
For many types of operations, Oracle Database uses the buffer cache to store data blocks read from disk. Oracle Database bypasses the buffer cache for particular operations, such as sorting and parallel reads.
To use the database buffer cache effectively, tune SQL statements for the application to avoid unnecessary resource consumption. To meet this goal, verify that frequently executed SQL statements and SQL statements that perform many buffer gets are well-tuned.
When using parallel query, consider configuring the database to use the database buffer cache instead of performing direct reads into the Program Global Area (PGA). This configuration may be appropriate when the system has a large amount of memory.
Oracle Database SQL Tuning Guide for information about tuning SQL statements
Throughput
Раздел Throughput отображает пропускную способность. Пропускная способность базы данных измеряет объем работы, которую база данных выполняет за единицу времени.
Пики на графике Throughput должны соответствовать пикам на графике Average Active Sessions. Если заметен рост времени ожидания, необходимо убедиться, что увеличивается пропускная способность. Если пропускная способность низкая, а время ожидания растет — необходимо изменить настройки БД.
Latency показывает задержку чтения блоков. Это разница между временем выполнения чтения и временем обработки чтения БД. Показатель должен стремиться к нулю.
Оптимальным считается значение до 10 мс. Этот график — основной показатель производительности в этом блоке. Если зафиксирован рост времени задержки, нужно посмотреть, не растет ли количество I/O операций и их вес, также на рост Latency может влиять утилизация CPU.
Статистику по I/O можно смотреть в разрезе функций, в разрезе типов и в разрезе групп потребителей ресурсов (группы пользователей). Для этого на графике необходимо выбрать соответствующий Breakdown. Графики показывают количество I/O-операций в секунду и их вес в разрезе выбранного значения Breakdown. Для большей детализации можно провалиться глубже в статистику, выбрав соответствующее значение на графике или в легенде, и посмотреть статистику именно по выбранному значению.
I/O Function
График дает представление об уровне утилизации диска приложениями или джобами. То есть на графике можно увидеть, какие процессы больше всего читали и писали за определенный период.
Можно выделить следующие категории:
№ | Категория | Описание |
---|---|---|
1 | Фоновые процессы | Включают в себя ARCH, LGWR, DBWR (полный список фоновых процессов есть в документации) |
2 | Активность | XML DB, Streams AQ, Data Pump, Recovery, RMAN |
3 | Тип I/O | Включает прямую запись и чтение (в том числе чтение из кэша) |
4 | Другое | Включает операции ввода/вывода управляющих файлов |
I/O Type
Выводит статистику по тяжести операций ввода-вывода. Маленькими считаются операции, которые обрабатывают до 128 КБ. К большим операциям ввода-вывода относятся: сканирование таблиц и индексов, прямая загрузка данных, резервное копирование, восстановление и архивирование.
Consumer group
Дает представление об утилизации диска в разрезе групп пользователей: показывает, какая группа пользователей выполняет операции чтения и записи в определенный период. Включает в себя фоновые процессы.
Average Runnable Process
Этот график дает общее понимание использования CPU.
№ | Показатель | Описание |
---|---|---|
1 | Instance Foreground CPU | Отображает утилизацию CPU процессами текущего инстанса, напрямую запущенными клиентом, например выполнение запросов. Список событий ожидания текущего инстанса можно посмотреть в AWR-отчете |
2 | Instance Background CPU | Отображает утилизацию CPU фоновыми процессами текущего инстанса, например LGWR. Список событий фонового процесса текущего инстанса можно посмотреть в AWR-отчете или в официальной документации Oracle |
3 | Non-database Host CPU | Отображает утилизацию CPU процессами, не относящимися к текущему инстансу |
4 | Load Average | Отображает среднюю длину очереди процессов, ожидающих выполнения |
5 | CPU Treads/CPU Cores | Отображает лимит максимально возможного использования CPU |
Configuring Multiple Buffer Pools
For most systems, a single default buffer pool is generally adequate. However, database administrators with detailed knowledge of an application's buffer pool may benefit from configuring multiple buffer pools.
For segments that have atypical access patterns, consider storing blocks from these segments in two separate buffer pools: the KEEP pool and the RECYCLE pool. A segment's access pattern may be atypical if it is constantly accessed (sometimes referred to as hot) or infrequently accessed (such as a large segment that is accessed by a batch job only once a day).
Using multiple buffer pools enables you to address these irregularities. You can use the KEEP pool to maintain frequently accessed segments in the buffer cache, and the RECYCLE pool to prevent objects from consuming unnecessary space in the buffer cache. When an object is associated with a buffer cache, all blocks from that object are placed in that cache. Oracle Database maintains a DEFAULT buffer pool for objects that are not assigned to a specific buffer pool. The default buffer pool size is determined by the DB_CACHE_SIZE initialization parameter. Each buffer pool uses the same LRU replacement policy. For example, if the KEEP pool is not large enough to store all of the segments allocated to it, then the oldest blocks age out of the cache.
By allocating objects to appropriate buffer pools, you can:
Reduce or eliminate I/Os
Isolate or limit an object to a separate cache
This section describes how to configure multiple buffer pools and contains the following topics:
Память Oracle можно разделить на глобальную область системы и глобальную область обработки в соответствии с общими и частными аспектами, то есть SGA и PGA (глобальная область обработки или частная глобальная область). Для памяти в области SGA она является общей глобальной. В UNIX сегмент общей памяти должен быть установлен для oracle (которое может быть одним или несколькими), потому что oracle является многопроцессорным в UNIX, oracle в WINDOWS - это Один процесс (несколько потоков), поэтому нет необходимости устанавливать сегмент общей памяти. PGA - это приватная область процесса (потока). В Oracle, использующем режим общего сервера (MTS), часть PGA, то есть UGA, будет помещена в общую память large_pool_size.
Архитектура памяти оракула состоит из картинки, и ключевые параметры и имена параметров можно увидеть с первого взгляда в соответствии с дисплеем над картинкой:
Для части SGA, мы можем видеть через запрос в sqlplus:
Fixed Size:
Разные платформы Oracle и разные версии могут отличаться, но это фиксированное значение для определения среды, в которой хранится информация о различных компонентах SGA, которую можно рассматривать как область, определяющую создание SGA.
Variable Size :
Содержит настройки памяти, такие как shared_pool_size, java_pool_size, large_pool_size и т. Д.
Database Buffers :
Индекс по буферной зоне:
В 8i он содержит три части памяти: db_block_buffer * db_block_size, buffer_pool_keep, buffer_pool_recycle.
В 9i он включает db_cache_size, db_keep_cache_size, db_recycle_cache_size, db_nk_cache_size.
Redo Buffers :
Относится к буферу журналов, log_buffer. Дополнительным моментом здесь является то, что значения запроса для параметров v $, v $ sgastat и v $ sga могут отличаться. Значение в параметре v $ относится к начальному пользователю
Значение, установленное в файле параметров инициализации, v $ sgastat - это фактический размер буфера журнала, выделенный Oracle (поскольку значение выделения буфера фактически дискретно, и оно не выделяется блоком в качестве минимальной единицы),
Значение, запрашиваемое в v $ sga, указывается после того, как oracle выделил буфер журнала. Чтобы защитить буфер журнала, установите несколько страниц защиты, обычно мы обнаруживаем, что размер страницы защиты составляет около 11 КБ (может отличаться в разных средах).
2. Параметры и настройки в SGA:
2.1 Log_buffer
Что касается настройки размера буфера журналов, я обычно не думаю, что есть слишком много предложений, потому что после обращения к условиям триггера, написанным LGWR, мы обнаружим, что обычно оно незначительно и превышает 3M. Как формальная система,
Может потребоваться установить для этой части значение log_buffer = 3-5M, а затем настроить его в соответствии с конкретной ситуацией.
log_buffer - это буфер журнала повторов.
2.2 Large_pool_size
Для настройки большого буферного пула, если MTS не используется, рекомендуется, чтобы 20-30M было достаточно. Эта часть в основном используется для сохранения некоторой информации во время параллельного запроса, а RMAN может использоваться во время резервного копирования.
Если MTS установлен, так как часть UGA будет перемещена сюда, вам необходимо рассмотреть настройку этой части в соответствии с числом процессов сервера и настройками связанных параметров памяти сеанса.
2.3 Java_pool_size
2.4 Shared_pool_size
Накладные расходы на Shared_pool_size обычно должны поддерживаться в пределах 300M. Если система не использует много хранимых процедур, функций, пакетов,
Например, приложения, такие как oracle erp, могут достигать 500M или даже выше. Итак, мы предполагаем систему памяти 1G, мы можем рассмотреть
Установите этот параметр равным 100M, система 2G считает установленной на 150M, система 8G считает установленной на 200-300M
2.5SGA_MAX_SIZE
Область SGA включает в себя различные буферы и пулы памяти, и большинство из них могут указывать свои размеры через определенные параметры. Однако, как дорогой ресурс, объем физической памяти системы ограничен.
Хотя для адресации памяти ЦП нет необходимости учитывать фактический объем физической памяти (об этом будет подробно рассказано позже), но чрезмерное использование виртуальной памяти приводит к вводу / выводу страницы
Это сильно повлияет на производительность системы и может даже привести к сбою системы. Следовательно, есть параметр для управления максимальным размером виртуальной памяти, используемой SGA. Этот параметр - SGA_MAX_SIZE. Когда экземпляр запускается,
Каждой области памяти выделяется только минимальный размер, требуемый экземпляром, и в последующем рабочем процессе их размер увеличивается по мере необходимости, а их общий размер ограничивается SGA_MAX_SIZE.
Для систем OLTP, обратитесь к:
Системная память
Значение SGA_MAX_SIZE
Когда запускается экземпляр oracle, он загружает только наименьший размер каждой области памяти. Другая память SGA выделяется только как виртуальная память, и только когда процесс касается соответствующей страницы, она заменяется физической памятью. Но мы можем захотеть, чтобы все SGA выделялись физической памяти после запуска экземпляра. В настоящее время вы можете достичь цели, установив параметр PRE_PAGE_SGA. Значением этого параметра по умолчанию является FALSE, что означает, что не все SGA помещаются в физическую память. Если установлено значение TRUE, запуск экземпляра поместит все SGA в физическую память. Это может заставить экземпляр начать достигать своего максимального состояния производительности, но время запуска также будет больше (потому что для того, чтобы поместить весь SGA в физическую память, процесс оракула должен коснуться всех страниц SGA).
Чтобы гарантировать, что SGA заблокирован в физической памяти без необходимости постраничного ввода / вывода страницы, им можно управлять с помощью параметра LOCK_SGA. Значением по умолчанию для этого параметра является FALSE. Когда указано TRUE, все SGA могут быть заблокированы в физической памяти. Конечно, некоторые системы не поддерживают блокировку памяти, этот параметр недопустим.
Вот очень важный параметр, представленный в Oracle10g. До 10g размер каждой области памяти SGA должен быть указан их соответствующими параметрами, и они не могут превышать значение указанного размера параметра, хотя их сумма может не достигать максимального предела SGA. Кроме того, после выделения память каждой области может использоваться только для этой области и не может использоваться совместно. Возьмем две наиболее важные области памяти в SGA, Buffer Cache и Shared Pool, которые оказывают наибольшее влияние на производительность экземпляра, но есть такое противоречие: в случае ограниченных ресурсов памяти иногда данные кэшируются Требование очень велико, чтобы улучшить попадание в буфер, вам необходимо увеличить буферный кэш, но из-за ограниченного SGA вы можете «захватывать» только другие области, такие как сокращение общего пула, увеличение буферного кэша, а иногда и большие блоки кода PLSQL. Он разрешается и хранится в памяти, что приводит к недостаточному общему пулу или даже к ошибке 4031, а также к необходимости расширения общего пула, что может потребовать вмешательства человека для восстановления памяти из буферного кеша.
С помощью этой новой функции этот конфликт памяти в SGA разрешается. Эта функция называется автоматическим управлением общей памятью (ASMM). И только этот параметр SGA_TARGE управляет этой функцией. После установки этого параметра вам не нужно указывать размер для каждой области памяти. SGA_TARGET задает максимальный объем памяти, который может использовать SGA, а размер каждой памяти в SGA контролируется самой Oracle и не требует указания вручную. Oracle может в любой момент настроить размер каждой области, чтобы достичь наиболее приемлемого размера системы с наилучшей производительностью, и контролировать их сумму в пределах значения, указанного в SGA_TARGET. Если для SGA_TARGET указано значение (по умолчанию 0, т. Е. ASMM не запущен), функция ASMM запускается автоматически.
Три, метод настройки памяти оракула
Когда возникают проблемы с производительностью в производственной среде проекта, как мы можем определить, какие параметры необходимо настроить?
3.1 Проверьте частоту попаданий в библиотечный кеш экземпляра ORACLE:
3.2 Проверьте частоту попаданий в буфер данных экземпляра ORACLE:
3.3 Проверьте частоту попаданий в кэш словаря экземпляра ORACLE:
3.4 Проверьте частоту попаданий в буфер журнала экземпляра ORACLE:
3.5 Проверьте undo_retention:
32-битные и 64-битные проблемы
Для оракула есть проблемы 32-битные и 64-битные. Эта проблема в основном влияет на размер SGA. В 32-битной базе данных Oracle обычно может использовать не более 1,7 ГБ памяти. Даже если у нас 12 ГБ памяти, мы можем использовать только 1,7 ГБ, что является большим сожалением. Если мы установим 64-битную базу данных, мы сможем использовать много памяти, и для нас почти невозможно достичь верхнего предела. Однако 64-битная база данных должна быть установлена в 64-битной операционной системе, но, к сожалению, в Windows может быть установлена только 32-битная база данных. Мы можем проверить, является ли база данных 32-битной или 64-битной, следующим образом.
Однако в некоторых операционных системах это может обеспечить некоторые средства, позволяющие нам использовать более 1,7 ГБ памяти, достигая более 2 ГБ или даже больше.
Вопрос 1. Значение sga_target / pga_aggregate_target изменено, поэтому их сумма больше, чем memory_target;
Вопрос 2. Измените значение memory_target так, чтобы оно было меньше суммы sga_target / pga_aggregate_target, и будет сообщено об ошибке;
SQL> запуск для запуска базы данных Ошибка:
ORA-02097: parameter cannot be modified because specified value is invalid
ORA-00838: Specified value of MEMORY_TARGET is too small, needs to be at least 4016M
Краткое описание проблемы: Memory_Target меньше суммы SGA_Target и pga_aggregate_target
Информация о конфигурации указанных выше параметров хранится в файле $ ORACLE_HOME / dbs / spfile.ora, но этот файл является двоичным файлом и не может быть изменен напрямую: только его файл pfile для копирования можно создать с помощью операторов SQL для изменения vi / vim Просто замени это. (В это время БД была закрыта и не может быть запущена, но pfile все еще может быть создан spfile)
Первое решение: восстановить предыдущее состояние без изменений.
1)SQL>create pfile from spfile;
2)[[email protected] dbs]$ vim $ORACLE_HOME/dbs/initorcl.ora
3) Удалить строку * .sga_target = *****
4)SYS> create spfile from pfile;
Второй метод - изменить sga_target на правильное значение:
1) Создайте документ инициализации pfile;
2) Изменить * .sga_target = X (X равно значению MEMORY_TARGET минус значение PGA (больше 10M, минимум PGA));
3) Создать SPFILE из модифицированного PFILE;
4) Просто запустите БД;
Третий метод заключается в изменении и увеличении значения * .memory_target,
1) Подобно второму способу, создайте документ инициализации pfile;
2) Изменить и увеличить * .memory_target = Y (значение Y не может быть больше, чем размер общей файловой системы / dev / shm tmpfs, в противном случае будет сообщено об ошибке в случае 2)
Случай 2: проблема: значение Memory_Target слишком велико
SQL> запуск для запуска базы данных Ошибка:
ORA-00845: MEMORY_TARGET not supported on this system
Причина проблемы: размер физической памяти> = настройка размера целевого элемента памяти> = / dev / shm tmpfs размер общей файловой системы
Способ 1: обратитесь к способу 3 в случае 1, чтобы изменить размер Memory_Target;
Метод 2: измените размер / dev / shm, есть два способа изменить:
Это статическая модификация, для которой требуется перезагрузка системы.
Это для изменения его размера путем повторного подключения без перезапуска.
This chapter describes how to tune the database buffer cache. If you are using automatic memory management to manage the database memory on your system, there is no need to manually tune the memory caches described in this chapter.
This chapter contains the following topics:
Services
Службы на этом графике представляют собой группы приложений. Отображаются только сессии активных служб, находящиеся в ожидании в определенный момент времени. Например, служба SYS$USERS — это установка пользовательского сеанса.
Top 10 Foreground Events by Total Wait Time
В разделе находится топ-10 событий, которые ожидали ресурсов дольше остальных.
При анализе необходимо обратить внимание на класс события ожидания. Если wait class System I/O, User I/O или Other, это нормально для БД. Если класс события ожидания Concurrency, это может свидетельствовать о проблемах.
Классы события ожидания можно посмотреть в разделе Wait Classes by Total Wait Time. В разделе находится статистика по классам события ожидания с сортировкой по времени ожидания.
Описание некоторых событий ожидания:
№ | Событие ожидания | Описание |
---|---|---|
1 | DB CPU | Отображает процессорное время, затраченное на пользовательские операции над БД. Это событие должно находиться на первом месте списка |
2 | db file sequential read | Метрика сигнализирует, что пользовательский процесс не находит нужный блок в buffer cache, загружает его с диска в SGA и ждет физического ввода/вывода |
3 | db file scattered read | Указывает на проблему с фулл-сканами, возможно, нужны индексы |
4 | read by other session | Может говорить о том, что размер блока слишком большой или задержка (latency) слишком большая |
5 | enq TX – row lock contention | Событие возникает при ожидании блокировки строки для дальнейшей ее модификации DML-запросом. Если показатель больше 10%, необходимо разбираться в причинах. Более детальную информацию можно посмотреть в разделе Segments by Row Lock Waits, в котором есть сведения о том, какие таблицы были заблокированы и какими запросами |
6 | DB FILE SEQUENTIAL READ | Если среднее значение параметра больше 100 мс, это может свидетельствовать о том, что диск работает медленно |
7 | LOG FILE SYNC | Значение AVG WAIT более 20 мс может свидетельствовать о проблемах |
8 | DB FILE SCATTERED READ | Если это событие выполняется — возможно, имеет смысл создать дополнительные индексы. Для более подробной информации нужно перейти к разделу Segments By Physical Read, в котором находится информация по таблицам и индексам, в которых происходит физическое чтение |
9 | direct path read temp ИЛИ direct path write temp | Эти события дают информацию по использованию временных файлов |
10 | Buffer Busy Wait | Событие указывает на то, что несколько процессов пытаются обратиться к одному блоку памяти, то есть пока первый процесс работает с конкретным блоком памяти, остальные процессы находятся в статусе ожидания |
About the Database Buffer Cache
For many types of operations, Oracle Database uses the buffer cache to store data blocks read from disk. Oracle Database bypasses the buffer cache for particular operations, such as sorting and parallel reads.
To use the database buffer cache effectively, tune SQL statements for the application to avoid unnecessary resource consumption. To meet this goal, verify that frequently executed SQL statements and SQL statements that perform many buffer gets are well-tuned.
When using parallel query, consider configuring the database to use the database buffer cache instead of performing direct reads into the Program Global Area (PGA). This configuration may be appropriate when the system has a large amount of memory.
Oracle Database SQL Tuning Guide for information about tuning SQL statements
Average Active Sessions
- Если зафиксирован рост активных сессий, то должна расти пропускная способность (график Throughput).
- Если Active Sessions превышает CPU Cores/CPU Threads, это свидетельствует о проблемах производительности.
- Если зафиксирован рост времени отклика операций, но при этом активные сессии не превышают CPU, это значит, что узкое место не в CPU и нужно более детально смотреть, по каким классам события ожидания фиксируется рост, после чего можно на графике нажать на соответствующий класс и провалиться глубже в детализацию (откроется отчет ASH — Active Session History).
Performance Home
На вкладке Performance Home можно увидеть основные графики утилизации БД.
Load Profile
Здесь отображается общая информация по тому, как была загружена БД за выбранный период.
№ | Параметр | Описание |
---|---|---|
1 | DB Time(s) | Сумма времени утилизации процессора и время ожидания (без простоя) |
2 | DB CPU(s) | Нагрузка на процессор |
3 | Background CPU(s) | Загрузка процессора фоновыми задачами |
4 | Redo size | Объем чтения |
5 | Logical reads | Среднее количество логических чтений блоков |
6 | Block changes | Среднее значение измененных блоков |
7 | Physical reads | Физическое чтение в блоках |
8 | Physical writes | Количество записей в блоках |
9 | Read I/O requests | Количество чтений |
10 | Write I/O requests | Количество записей |
11 | Read I/O (MB) | Объем чтения |
12 | Write I/O (MB) | Объем записей |
13 | IM scan rows | Количество строк в In-Memory Compression Units (IMCU), которые были доступны |
14 | Session Logical Read IM | Чтения в In-Memory |
15 | User calls | Пользовательские вызовы |
16 | Parses | Разборы |
17 | Logons | Количество входов |
18 | Excecutes | Количество вызовов |
19 | Rollback | Количество откатов данных |
20 | Transacions | Количество транзакций |
Configuring the Database Buffer Cache
When configuring a new database instance, it is impossible to know the correct size for the buffer cache. Typically, a database administrator makes a first estimate for the cache size, then runs a representative workload on the instance and examines the relevant statistics to see whether the cache is under-configured or over-configured.
This section describes how to configure the database buffer cache. If you are using automatic shared memory management to configure the Shared Global Area (SGA), there is no need to manually tune the database buffer cache as described in this section.
This section contains the following topics:
Using the V$DB_CACHE_ADVICE View
The V$DB_CACHE_ADVICE view shows the simulated miss rates for a range of potential buffer cache sizes. This view assists in cache sizing by providing information that predicts the number of physical reads for each potential cache size. The data also includes a physical read factor, which is a factor by which the current number of physical reads is estimated to change if the buffer cache is resized to a given value.
However, physical reads do not necessarily indicate disk reads in Oracle Database, because physical reads may be accomplished by reading from the file system cache. Hence, the relationship between successfully finding a block in the cache and the size of the cache is not always a smooth distribution. When sizing the buffer pool, avoid using additional buffers that do not contribute (or contribute very little) to the cache hit ratio.
The following figure illustrates the relationship between physical I/O ratio and buffer cache size.
Figure 13-1 Physical I/O Ratio and Buffer Cache Size
Description of "Figure 13-1 Physical I/O Ratio and Buffer Cache Size"
Examining the example illustrated in the above figure leads to the following observations:
As the number of buffers increases, the physical I/O ratio decreases.
The decrease in the physical I/O between points A and B and points B and C is not smooth, as indicated by the dotted line in the graph.
The benefit from increasing buffers from point A to point B is considerably higher than from point B to point C.
The benefit from increasing buffers decreases as the number of buffers increases.
There is some overhead associated with using this advisory view. When the advisory is enabled, there is a small increase in CPU usage, because additional bookkeeping is required. To reduce both the CPU and memory overhead associated with bookkeeping, Oracle Database uses sampling to gather cache advisory statistics. Sampling is not used if the number of buffers in a buffer pool is small to begin with.
To use the V$DB_CACHE_ADVICE view:
Set the value of the DB_CACHE_ADVICE initialization parameter to ON .
This enables the advisory view. The DB_CACHE_ADVICE parameter is dynamic, so the advisory can be enabled and disabled dynamically to enable you to collect advisory data for a specific workload.
Run a representative workload on the database instance.
Allow the workload to stabilize before querying the V$DB_CACHE_ADVICE view.
Query the V$DB_CACHE_ADVICE view.
The following example shows a query of this view that returns the predicted I/O requirement for the default buffer pool for various cache sizes.
The output of this query might look like the following:
In this example, the output shows that if the cache was 212 MB instead of the current size of 304 MB, the estimated number of physical reads would increase by a factor of 1.74, or 74%. Hence, it is not advisable to decrease the cache size to 212MB.
However, increasing the cache size to 334MB may potentially decrease reads by a factor of .93, or 7%. If an additional 30MB memory is available on the system and the value of the SGA_MAX_SIZE parameter allows for the increment, it is advisable to increase the default buffer cache pool size to 334MB.
Calculating the Buffer Cache Hit Ratio
The buffer cache hit ratio calculates how often a requested block has been found in the buffer cache without requiring disk access. This ratio is computed using data selected from the V$SYSSTAT performance view. Use the buffer cache hit ratio to verify the physical I/O as predicted by the V$DB_CACHE_ADVICE view.
Table 13-1 lists the statistics from the V$SYSSTAT view used to calculate the buffer cache hit ratio.
Table 13-1 Statistics for Calculating the Buffer Cache Hit Ratio
consistent gets from cache
Number of times a consistent read was requested for a block from the buffer cache.
db block gets from cache
Number of times a CURRENT block was requested from the buffer cache.
physical reads cache
Total number of data blocks read from disk into buffer cache.
Example 13-1 shows a query of this view.
Example 13-1 Querying the V$SYSSTAT View
In this example, the query is simplified by using values selected directly from the V$SYSSTAT view, rather than over an interval. It is recommended to calculate the delta of these statistics over an interval while the application is running, then use these delta values to determine the buffer cache hit ratio. For information about collecting statistics over an interval, see Automatic Performance Diagnostics .
Using the values from the output of this query, calculate the hit ratio for the buffer cache using the following formula:
Oracle Database Reference for information about the V$SYSSTAT view
Interpreting the Buffer Cache Hit Ratio
Before deciding whether to increase or decrease the buffer cache size, you should first examine the buffer cache hit ratio.
A low cache hit ratio does not necessarily imply that increasing the size of the buffer cache will benefit performance. Moreover, a high cache hit ratio may wrongly indicate that the buffer cache is adequately sized for the workload.
To interpret the buffer cache hit ratio, consider the following factors:
Avoid repeated scanning of frequently accessed data by performing the processing in a single pass or by optimizing the SQL statement.
Repeated scanning of the same large table or index can artificially inflate a low cache hit ratio. Examine frequently executed SQL statements with a large number of buffer gets, to ensure that the execution plans for these SQL statements are optimal.
Avoid requerying the same data by caching frequently accessed data in the client program or middle tier.
In large databases running OLTP applications, many rows are accessed only once (or never). Hence, there is no purpose in keeping the block in memory following its use.
Do not continuously increase the buffer cache size.
Continuous increases of the buffer cache size have no effect if the database is performing full table scans or operations that do not use the buffer cache.
Consider poor hit ratios when large full table scans are occurring.
Database blocks accessed during a long full table scan are placed on the tail end of the Least Recently Used (LRU) list and not on the head of the list. Therefore, the blocks age out faster than blocks read when performing indexed lookups or small table scans.
Short table scans are scans performed on tables under a certain size threshold. The definition of a small table is the maximum of 2% of the buffer cache or 20, whichever is bigger.
Increasing Memory Allocated to the Database Buffer Cache
If the cache hit ratio is low and your application is tuned to avoid performing full table scans, consider increasing the size of the buffer cache. If possible, resize the buffer pools dynamically, rather than shutting down the instance to perform this change.
To increase the size of the database buffer cache:
Set the value of the DB_CACHE_ADVICE initialization parameter to ON .
Allow the buffer cache statistics to stabilize.
Examine the advisory data in the V$DB_CACHE_ADVICE view to determine the next increment required to significantly decrease the amount of physical I/O performed, as described in "Using the V$DB_CACHE_ADVICE View" .
If it is possible to allocate the extra memory required to the buffer cache without causing the system to page, then allocate this memory.
To increase the amount of memory allocated to the buffer cache, increase the value of the DB_CACHE_SIZE initialization parameter.
The DB_CACHE_SIZE parameter specifies the size of the default cache for the database's standard block size. To create and use tablespaces with block sizes other than the database's standard block sizes (such as for transportable tablespaces), configure a separate cache for each block size used. Use the DB_ n K_CACHE_SIZE parameter to configure the nonstandard block size needed (where n is 2, 4, 8, 16 or 32 and not the standard block size).
The process of choosing a cache size is the same, regardless of whether the cache is the default standard block size cache, the KEEP or RECYCLE cache, or a nonstandard block size cache.
When the cache is resized significantly (greater than 20%), the old cache advisory value is discarded and the cache advisory is set to the new size. Otherwise, the old cache advisory value is adjusted to the new size by the interpolation of existing values.
For more information about the DB_ n K_CACHE_SIZE parameter, see:
Reducing Memory Allocated to the Database Buffer Cache
If the cache hit ratio is high, then the buffer cache is likely large enough to store the most frequently accessed data. If this is the case and memory is required for another memory structure, consider reducing the size of the buffer cache.
To reduce the size of the database buffer cache:
Examine the advisory data in the V$DB_CACHE_ADVICE view to determine if decreasing the size of the buffer cache will significantly increase the number of physical I/Os, as described in "Using the V$DB_CACHE_ADVICE View" .
To reduce the amount of memory allocated to the buffer cache, decrease the value of the DB_CACHE_SIZE initialization parameter.
Active Session History (ASH) Report
В данной таблице находятся самые тяжелые SQL запросы, на которые приходится наибольший процент активности и наибольшее время ожидания.
В таблице содержится статистика по запросам, на которые приходится наибольший процент выборочной активности и подробная информация о их плане выполнения. Вы можете использовать эту информацию, чтобы определить, какая часть выполнения SQL операторов значительно повлияла на затраченное время SQL оператора.
ASH Report
ASH Report (Active Session History) дает более подробную информацию по потреблению ресурсов. Чтобы перейти к графику, в меню Performance нужно выбрать пункт Performance Hub/ASH Report. Также перейти к ASH Report можно при выборе класса события ожидания на графике Average Active Session.
- События ожидания и группы событий ожидания.
- Группы пользователей, пользователи, сервисы, инстансы.
- SQL-запросы.
AWR (Automatic Workload Repository) дает подробную информацию о процессах, происходящих с БД в определенный период. Для построения AWR-отчета нужно выбрать пункт меню Performance/AWR/AWR Report. Также есть возможность сравнивать два временных промежутка. Для этого нужно выбрать пункт меню Performance/AWR/Compare Period Report.
Ниже будут описаны наиболее показательные разделы AWR-отчета, описание остальных разделов можно поискать в официальной документации.
SQL statistics
Раздел содержит несколько таблиц со статистикой по SQL-запросам, отсортированным по определенному критерию.
Подробнее про оптимизацию запросов и примеры типичных проблем в запросах можно почитать в статье Проактивная оптимизация производительности БД Oracle.
№ | Параметр | Описание |
---|---|---|
1 | SQL ordered by Elapsed Time | Топ SQL-запросов по затраченному времени на их выполнение |
2 | SQL ordered by CPU Time | Топ SQL-запросов по процессорному времени |
3 | SQL ordered by User I/O Wait Time | Топ SQL-запросов по времени ожидания ввода/вывода для пользователя |
4 | SQL ordered by Gets | Запросы к БД, упорядоченные по убыванию логических операций ввода/вывода. При анализе стоит учитывать, что для PL/SQL-процедур их количество прочитанных Buffer Gets будет состоять из суммы всех запросов в рамках этой процедуры |
5 | SQL ordered by Reads | Этот раздел схож с предыдущим: в нем указываются все операции ввода/вывода, наиболее активно физически считывающие данные с жесткого диска. Именно на эти запросы и процессы надо обратить внимание, если система не справляется с объемом ввода/вывода |
6 | SQL ordered by Physical Reads (UnOptimized) | В этом разделе выводятся неоптимизированные запросы. В Oracle неоптимизированными считаются все запросы, которые не обслуживаются DSFC или Exadata Cell Smart Flash Cache (ECSFC) |
7 | SQL ordered by Executions | Наиболее часто выполняемые запросы |
8 | SQL ordered by Parse Calls | Отображает количество попыток разбора SQL-запросов до его выполнения |
9 | SQL ordered by Sharable Memory | Запросы, занимающие больший объем памяти общего пула SGA |
10 | SQL ordered by Version Count | Здесь показано количество SQL-операторов экземпляров одного и того же оператора в разделяемом пуле |
11 | Complete List of SQL Text | Показывает полный SQL-запрос, не только его хэш. В этой таблице можно найти неоптимальные запросы (например, запросы по всем столбцам таблицы «select * from. », запросы с большим количеством «like» и т. п.) |
Instance Efficiency Percentages
№ | Показатель | Критерии |
---|---|---|
1 | Buffer nowait | Если показатель меньше 95%, значит, буферы data block buffer используются неправильно. Возможно, нужно увеличить data block buffer size |
2 | Buffer Hit | Если показатель меньше 95%, значит, буферы data block buffer используются неправильно. Возможно, нужно увеличить data block buffer size |
3 | Library cache hit | Если показатель меньше 95% — нужно расширять shared pool (либо причина в bind-переменных) |
4 | Redo NOWAIT | Если показатель меньше 95%, это говорит о проблеме в redo log buffer или redo log |
5 | Parse CPU to Parse Elapsd | Показатель должен быть больше или равен 90%, тогда большинство процессов не ожидает ресурсов, что говорит о правильной работе базы данных |
6 | Non-Parse CPU | Показатель должен приближаться к 100%, это значит, что большинство ресурсов CP используется в различных операциях, кроме parsing, что говорит о правильной работе базы данных. Если Non-Parse CPU низкий, значит, база много времени тратит на разбор запроса вместо реальной работы |
7 | In-memory sort | Значение меньше 100 говорит о том, что сортировка идет через диск, а также есть потенциальные проблемы с PGA_AGGREGATE_TARGET,SORT_AREA_SIZE,HASH_AREA_SIZE и bitmap setting |
8 | Soft Parse | Чем он выше, тем меньше у нас Hard Parse |
9 | Latch Hit | Чем он выше, тем меньше мы ждем Latches (если он низкий — у нас проблемы с CPU-Bound и Latches) |
Configuring the Database Buffer Cache
When configuring a new database instance, it is impossible to know the correct size for the buffer cache. Typically, a database administrator makes a first estimate for the cache size, then runs a representative workload on the instance and examines the relevant statistics to see whether the cache is under-configured or over-configured.
This section describes how to configure the database buffer cache. If you are using automatic shared memory management to configure the Shared Global Area (SGA), there is no need to manually tune the database buffer cache as described in this section.
This section contains the following topics:
Using the V$DB_CACHE_ADVICE View
The V$DB_CACHE_ADVICE view shows the simulated miss rates for a range of potential buffer cache sizes. This view assists in cache sizing by providing information that predicts the number of physical reads for each potential cache size. The data also includes a physical read factor, which is a factor by which the current number of physical reads is estimated to change if the buffer cache is resized to a given value.
However, physical reads do not necessarily indicate disk reads in Oracle Database, because physical reads may be accomplished by reading from the file system cache. Hence, the relationship between successfully finding a block in the cache and the size of the cache is not always a smooth distribution. When sizing the buffer pool, avoid using additional buffers that do not contribute (or contribute very little) to the cache hit ratio.
The following figure illustrates the relationship between physical I/O ratio and buffer cache size.
Figure 13-1 Physical I/O Ratio and Buffer Cache Size
Description of "Figure 13-1 Physical I/O Ratio and Buffer Cache Size"
Examining the example illustrated in the above figure leads to the following observations:
As the number of buffers increases, the physical I/O ratio decreases.
The decrease in the physical I/O between points A and B and points B and C is not smooth, as indicated by the dotted line in the graph.
The benefit from increasing buffers from point A to point B is considerably higher than from point B to point C.
The benefit from increasing buffers decreases as the number of buffers increases.
There is some overhead associated with using this advisory view. When the advisory is enabled, there is a small increase in CPU usage, because additional bookkeeping is required. To reduce both the CPU and memory overhead associated with bookkeeping, Oracle Database uses sampling to gather cache advisory statistics. Sampling is not used if the number of buffers in a buffer pool is small to begin with.
To use the V$DB_CACHE_ADVICE view:
Set the value of the DB_CACHE_ADVICE initialization parameter to ON .
This enables the advisory view. The DB_CACHE_ADVICE parameter is dynamic, so the advisory can be enabled and disabled dynamically to enable you to collect advisory data for a specific workload.
Run a representative workload on the database instance.
Allow the workload to stabilize before querying the V$DB_CACHE_ADVICE view.
Query the V$DB_CACHE_ADVICE view.
The following example shows a query of this view that returns the predicted I/O requirement for the default buffer pool for various cache sizes.
The output of this query might look like the following:
In this example, the output shows that if the cache was 212 MB instead of the current size of 304 MB, the estimated number of physical reads would increase by a factor of 1.74, or 74%. Hence, it is not advisable to decrease the cache size to 212MB.
However, increasing the cache size to 334MB may potentially decrease reads by a factor of .93, or 7%. If an additional 30MB memory is available on the system and the value of the SGA_MAX_SIZE parameter allows for the increment, it is advisable to increase the default buffer cache pool size to 334MB.
Calculating the Buffer Cache Hit Ratio
The buffer cache hit ratio calculates how often a requested block has been found in the buffer cache without requiring disk access. This ratio is computed using data selected from the V$SYSSTAT performance view. Use the buffer cache hit ratio to verify the physical I/O as predicted by the V$DB_CACHE_ADVICE view.
Table 13-1 lists the statistics from the V$SYSSTAT view used to calculate the buffer cache hit ratio.
Table 13-1 Statistics for Calculating the Buffer Cache Hit Ratio
consistent gets from cache
Number of times a consistent read was requested for a block from the buffer cache.
db block gets from cache
Number of times a CURRENT block was requested from the buffer cache.
physical reads cache
Total number of data blocks read from disk into buffer cache.
Example 13-1 shows a query of this view.
Example 13-1 Querying the V$SYSSTAT View
In this example, the query is simplified by using values selected directly from the V$SYSSTAT view, rather than over an interval. It is recommended to calculate the delta of these statistics over an interval while the application is running, then use these delta values to determine the buffer cache hit ratio. For information about collecting statistics over an interval, see Automatic Performance Diagnostics .
Using the values from the output of this query, calculate the hit ratio for the buffer cache using the following formula:
Oracle Database Reference for information about the V$SYSSTAT view
Interpreting the Buffer Cache Hit Ratio
Before deciding whether to increase or decrease the buffer cache size, you should first examine the buffer cache hit ratio.
A low cache hit ratio does not necessarily imply that increasing the size of the buffer cache will benefit performance. Moreover, a high cache hit ratio may wrongly indicate that the buffer cache is adequately sized for the workload.
To interpret the buffer cache hit ratio, consider the following factors:
Avoid repeated scanning of frequently accessed data by performing the processing in a single pass or by optimizing the SQL statement.
Repeated scanning of the same large table or index can artificially inflate a low cache hit ratio. Examine frequently executed SQL statements with a large number of buffer gets, to ensure that the execution plans for these SQL statements are optimal.
Avoid requerying the same data by caching frequently accessed data in the client program or middle tier.
In large databases running OLTP applications, many rows are accessed only once (or never). Hence, there is no purpose in keeping the block in memory following its use.
Do not continuously increase the buffer cache size.
Continuous increases of the buffer cache size have no effect if the database is performing full table scans or operations that do not use the buffer cache.
Consider poor hit ratios when large full table scans are occurring.
Database blocks accessed during a long full table scan are placed on the tail end of the Least Recently Used (LRU) list and not on the head of the list. Therefore, the blocks age out faster than blocks read when performing indexed lookups or small table scans.
Short table scans are scans performed on tables under a certain size threshold. The definition of a small table is the maximum of 2% of the buffer cache or 20, whichever is bigger.
Increasing Memory Allocated to the Database Buffer Cache
If the cache hit ratio is low and your application is tuned to avoid performing full table scans, consider increasing the size of the buffer cache. If possible, resize the buffer pools dynamically, rather than shutting down the instance to perform this change.
To increase the size of the database buffer cache:
Set the value of the DB_CACHE_ADVICE initialization parameter to ON .
Allow the buffer cache statistics to stabilize.
Examine the advisory data in the V$DB_CACHE_ADVICE view to determine the next increment required to significantly decrease the amount of physical I/O performed, as described in "Using the V$DB_CACHE_ADVICE View" .
If it is possible to allocate the extra memory required to the buffer cache without causing the system to page, then allocate this memory.
To increase the amount of memory allocated to the buffer cache, increase the value of the DB_CACHE_SIZE initialization parameter.
The DB_CACHE_SIZE parameter specifies the size of the default cache for the database's standard block size. To create and use tablespaces with block sizes other than the database's standard block sizes (such as for transportable tablespaces), configure a separate cache for each block size used. Use the DB_ n K_CACHE_SIZE parameter to configure the nonstandard block size needed (where n is 2, 4, 8, 16 or 32 and not the standard block size).
The process of choosing a cache size is the same, regardless of whether the cache is the default standard block size cache, the KEEP or RECYCLE cache, or a nonstandard block size cache.
When the cache is resized significantly (greater than 20%), the old cache advisory value is discarded and the cache advisory is set to the new size. Otherwise, the old cache advisory value is adjusted to the new size by the interpolation of existing values.
For more information about the DB_ n K_CACHE_SIZE parameter, see:
Reducing Memory Allocated to the Database Buffer Cache
If the cache hit ratio is high, then the buffer cache is likely large enough to store the most frequently accessed data. If this is the case and memory is required for another memory structure, consider reducing the size of the buffer cache.
To reduce the size of the database buffer cache:
Examine the advisory data in the V$DB_CACHE_ADVICE view to determine if decreasing the size of the buffer cache will significantly increase the number of physical I/Os, as described in "Using the V$DB_CACHE_ADVICE View" .
To reduce the amount of memory allocated to the buffer cache, decrease the value of the DB_CACHE_SIZE initialization parameter.
Parallel Executions
Раздел дает представление о показателях, связанных с параллельным выполнением запросов. Параллельный запрос делится на несколько процессов для ускорения выполнения запроса. Параллельное выполнение полезно при выполнении тяжелых запросов. Подробнее можно прочесть в официальной документации Oracle.
Foreground Wait Class, Foreground Wait events и Background Wait Events
Показывают классы и события, которые провели в ожидании большего всего. Foreground Wait events дополняет информацию раздела Top 10 Foreground Events By Total Wait Time. Background Wait Events показывает детализацию по событиям ожидания фоновых процессов.
Host CPU и Instance CPU
Здесь стоит обратить внимание на %Idle и %Total CPU. Если показатель %Idle низкий, а %Total CPU высокий, это может свидетельствовать о том, что процессор является узким местом.
Configuring Multiple Buffer Pools
For most systems, a single default buffer pool is generally adequate. However, database administrators with detailed knowledge of an application's buffer pool may benefit from configuring multiple buffer pools.
For segments that have atypical access patterns, consider storing blocks from these segments in two separate buffer pools: the KEEP pool and the RECYCLE pool. A segment's access pattern may be atypical if it is constantly accessed (sometimes referred to as hot) or infrequently accessed (such as a large segment that is accessed by a batch job only once a day).
Using multiple buffer pools enables you to address these irregularities. You can use the KEEP pool to maintain frequently accessed segments in the buffer cache, and the RECYCLE pool to prevent objects from consuming unnecessary space in the buffer cache. When an object is associated with a buffer cache, all blocks from that object are placed in that cache. Oracle Database maintains a DEFAULT buffer pool for objects that are not assigned to a specific buffer pool. The default buffer pool size is determined by the DB_CACHE_SIZE initialization parameter. Each buffer pool uses the same LRU replacement policy. For example, if the KEEP pool is not large enough to store all of the segments allocated to it, then the oldest blocks age out of the cache.
By allocating objects to appropriate buffer pools, you can:
Reduce or eliminate I/Os
Isolate or limit an object to a separate cache
This section describes how to configure multiple buffer pools and contains the following topics:
Этот класс ожидания инцидент происходит в контролируемом IO Операция. IO доступ к файлу управления обычно вызывается файлом журнальные, контрольно-пропускной пункт, и т.д. (например, обновление SCN). Таким образом, обработка оптимизации таких событий, в основном должны быть настроена для этих операций.
Это событие ожидания обычно происходит, когда процесс обслуживания обновляется все управляющие файлы, как правило:
- Сеанс запускает транзакцию файла управления (обновление всех файлы управления до настоящего времени до совершения сделки);
- Сеанс представляет транзакцию в файл управления;
- Запись файла управления модифицируется, который обновляется для всех управляющих файлов
Если этот случай существенно влияет на IO системы При выполнении, вы можете использовать следующие средства для оптимизации:
- В случае обеспечения того, чтобы количество резервных копий файла управления является безопасным (не все потеряно файлом управления), количество управляющих файлов сведено к минимуму;
- Если операционная система поддерживает AIO Настройка базы данных для поддержки AIO;
- Файл управления передачей для ввода-вывода Нагрузки является относительно низким.
Это событие ожидания, как правило, происходит в отдельном контроле И.О. Когда операция чтения. Это, как правило, можно:
- Резервное копирование файла управления;
- RAC При совместном использовании информации о файле управления между примерами;
- Прочитайте блок данных заголовка или другой блок данных файла управления.
Используйте следующее заявление, чтобы найти событие ожидания, вызванного путем доступа, которые контролируют:
- Если операционная система поддерживает AIO Настройка базы данных для поддержки AIO;
- Файл управления передачей для ввода-вывода Нагрузки является относительно низким.
Это событие ожидания, как правило, происходит в отдельном контроле И.О. Написать операцию записи. Используйте следующее заявление, чтобы найти событие ожидания, вызванного путем доступа, которые контролируют:
- Если операционная система поддерживает AIO Настройка базы данных для поддержки AIO;
- Файл управления передачей для ввода-вывода Нагрузки является относительно низким.
Написать журнал Redo Там будет много ожидающих событий, большинство из которых связаны с IO. Наиболее важным из "Log File Parallel Write" и "Log File Sync". Процесс LGWR фон Oracle будет ждать Log File Parallel Write события и недавний процесс будет ждать «файл журнала синхронизации» события.
Это событие происходит ожидание в LGWR Процесс ожидает завершения написания REDO в лог-файл Redo. Это событие происходит, когда процесс LGWR записывает данные в буфер журнала в лог-файл.
Асинхронный IO используется Такого рода операции записи параллельно, в противном случае он будет записан только в файл REDO. Процесс LGWR должен ждать все журнальные файлы должны быть записаны. Таким образом, эффективность ввода-вывода диска, когда файл журнальных находится непосредственно влияет на общее время ожидания события ожидания.
- Не делайте табличного пространства в горячем состоянии ожидания. Когда табличное пространство находится в горячем состоянии ожидания, табличное пространство больше не обновляются, журнальным Будет резко возрастать;
- журнал Redo Файл находится на устройстве хранения высокой скорости, не ставьте его на RAID5, вы можете рассмотреть возможность размещения на гол устройства;
- Redo log Диск, на котором находится файл должен попытаться избежать других операций ввода-вывода;
- Для некоторых операций, например, данные о большом объеме, вы можете настроить NOLOGGIN , Неустранимые варианты, или использовать подсказки / * + Append * / уменьшить поколение журнальных в операторах SQL.
- В обеспечении журнала повторного выполнения Когда данные будут защищено достаточно (без потери файла журнала), попробуйте уменьшить количество членов группы журнальной;
- Используйте журнал повторения в конфигурации Когда функция, такие как репликация потоков, LogMiner, логический режим Д.Г., попытаться установить самый низкий уровень дополнительного каротажа;
- Добавлен log_buffer правильно размер
Мы можем отрегулировать log_buffer в соответствии со следующими методами. Размер, сравнить журнальные буфера распределения повторных попыток (при запросе буфера журнала, не хватает буфера, вы должны повторно подать заявку), если доля превышает 0,1%, мы должны рассмотреть вопрос об увеличении размера log_buffer.
Кроме того, если система статистики, журнальные Космические запросы Более 0, указывая, что процесс ждет выделить файловое пространство журнальные, не дожидаясь буферного пространства. В это время, мы должны также рассмотреть вопрос об увеличении размера log_buffer.
Тем не менее, log_buffer Размер не должен превышать 128k * CPU или 512K (взять самый большой один в двух чисел).
оракул Процесс регистрации переднего стола отправляется или прокасает транзакцию, чтобы дождаться дожидания отправки или отката, чтобы сгенерировать событие ожидания. Часть причина ожидания может быть дождаться, когда процесс LGWR для копирования повторенной записи сеансной транзакции из буфера журнала на диск. В это время передний процесс будет отображаться в ожидании синхронизации файла журнала, а процессом фона LGWR ждет файла журнала Parallel Partly.
Если вы настроили с помощью данных Третий шаг в приведенных выше шагах также необходимо записать запись Redo в файл журнала REDO в базе данных ожидания в сети.
- Во-вторых, данные, связанные с тремя шагами, могут быть из Statspack Или статистика статистики AWR's «Redo Write» получено;
- Время ожидания и файл журнала параллельно писать Время ожидания одинаково;
- Когда система нагрузки очень высока, пятая и шесть шагов будет очень длинным, потому что в это время, хотя LGWR Процесс уведомил, что в режиме ожидания Front / пользовательский процесс был завершен, но нагрузка на систему слишком высока, процесс Front / User должен дождаться операционной системы, чтобы запланировать свой план прогона.
Чтобы понять, что заблокировано, файл журнала Sync Ключ состоит в том, чтобы сравнить среднее время ожидания файла журнала Syntc и файла журнала Parallel Parallel Написать:
- Если их время ожидания почти, тогда журнал журнал Файл журнала синхронизации файла ожидания в задаче IO (т. Е. Третий шаг), нам нужно оптимизировать IO файла журнала (как описано выше);
- Если файл журнала синхронизации Время ожидания намного выше, чем файл журнала Parallel, то синхронизация файла журнала вызвана другими механизмами журнала REDO (причинах неизота) во время отправки или отката, таких как защелка, LGWR ждать копирования и т. Д. Буфер Связанный конфликт защелки.
Вы можете использовать следующее утверждение для получения синхронизации файла журнала Соотношение среднего времени ожидания файла журнала Parallel Написать:
Мы также можем принять следующие средства настройки для уменьшения синхронизации файла журнала. ждать:
- Уменьшите журнал REDO в соответствии с методом в предыдущем разделе Генерация, обеспечивая эффективность redo log, уменьшая конфликт между журналом Redo и другим IO;
- Объедините небольшие транзакции в объемные транзакции, чтобы уменьшить количество представлений и отката.
Log file single write Написать связанную информацию в заголовок файла после открытия или закрытия файла журнала REDO. Поскольку номер файла содержит номер файла, информация заголовка файла не пишет несколько файлов параллельно, но написано отдельно, и его время ожидания не будет учитываться в файле журнала Параллельно.
Когда процесс из REDO Log Последовательное событие «Последовательное чтение журнала» генерируется при прочтении записи REDO в файле, например, Arch Process считывает данные журнала REDO.
Redo log Когда файл имеет проблему IO, приведенные выше события ожидания обычно отображаются одновременно, что и файл журнала Parallel Parallel пишет событие ожидания. Таким образом, два метода ожидания могут быть уменьшены за счет увеличения эффективности файла журнала REDO, упомянутой в 3.4.1.
При генерировании REDO log Когда вам нужно ждать, пока LGWR выключате файл журнала, сгенерирован переключатель файла журнала; во время команды Switch Logfile - это команда, чтобы дождаться, чтобы DBA ручной работы переключать журналы:
- Получите номер файла следующего файла журнала из файла управления;
- Получить Redo Copy И защелка редо.
- Пустое повторение Напишите запись Redo в буфер в файл журнала;
- Закройте текущий журнал Redo документ;
- Обновлять файлы управления, в том числе:
При ожидании третьего шага приведенного выше, переключатель файла журнала (файл журнала клиринга) генерируется. Жду события.
Мы можем взять вышеупомянутый способ улучшения журнального Файл эффективность IO уменьшает эти три ожидания события. Кроме того, можно увеличить размер файла журнала, уменьшить частоту переключения журнала (в общем случае, при переключении от 20 до 30 минут, в течение системы работает). Вы можете запросить переключение записи журнала и его интервал переключения на следующее заявление:
Когда вы делаете переключение журнала, вы будете делать контрольно-пропускной пункт Если есть другая контрольная точка, когда есть другой пункт пропуск, вы должны ждать контрольной точки для завершения и Log File Switch (CheckPoint Неполного) генерируются. Когда происходит это ожидание события, переключение журнала больше, чем обычно.
Для того, чтобы уменьшить событие ожидания, вам нужно уменьшить блокпост, вызванное переключением журнала. Поощряйте шансы других контрольно-пропускной пункт в системе. Мы можем сделать настройки с помощью следующих методов:
- Увеличение журнальные Размер файла уменьшается на частоте переключения журнала;
- Увеличение параметра LOG_CHECKPOINT_INTERVAL Размер, этот параметр устанавливает число блоков данных журнальных между контрольно-пропускными пунктами (размером размера блока данных) между системой дважды. Но Oracle ограничивает общий размер этих блоков данных менее чем на 90% файла минимум журнала. Если минимальный размер файла журнала 100 м, размер блока данных операционной системы 512K, то LOG_CHECKPOINT_INTERVAL меньше (100 * 90% / 0,5) = 180
log switch/archive Ожидание ожидания события для всех потоков Архива ожидания для всех потоков Архива для завершения текущего файла журнала архивирование. Когда процесс LGWR переключает журнал, если журнал будет вырезать еще не архив, вам нужно дождаться завершенным архив, который будет генерировать ключ файла журнала (архивация Необходимый) ждет события. В это время, мы можем также найти следующую информацию в журнале предупреждений:
Эти два события имеют только базы данных в архиве Режим будет отображаться в режиме. Обратите внимание, что архив слишком медленно. Настройка этих двух событий, в основном для настройки для настройки Архив.
В большинстве случаев, журнальные Чем больше количество файлов, тем больше размер, архив процесс может сделать Архивировать больше времени. Если REDO запись резко возросла, считаю плюс количество лога-файлы, так что архив процесс имеет несколько процессов архивирования выравнивающего времени. Однако, если процесс ARCH не может идти в ногу с обработкой скорости процесса LGWR, число увеличения лог-файлов не допускается.
Увеличение пропускной пункт Интервал может также сделать процесс архивирования больше времени для архива процесса. Повышение параметров LOG_CHECKPOINT_INTERVAL может увеличить интервал контрольной точки. Кроме того, увеличение числа DBWR процессов, настройка Aios для повышения эффективности обработки CheckPoint.
log_archive_max_processes параметров Вы можете настроить максимальное количество процессов ARCH. Мы можем сделать скрипт для выполнения «ALTER System Archive Log All;» команду, а затем установить задание для выполнения сценария на фиксированный интервал. Эта команда может заставить архив все unmarkable лог-файлы. Это способствует выравниванию архивной обработки трудоемкости процесса ARCH.
Увеличение Архив Размер буфера процесса может повысить эффективность архива, который контролируется параметром log_archive_buffer_size. Начальная настройка этого параметра 4K, а максимум может быть увеличен до 128К. Тем не менее, обратите внимание, чтобы увеличить этот параметр, хотя эффективность Архива может быть обеспечена, это может снизить общую производительность системы;
Кроме того, мы можем также увеличить архив Буфера процесса повышает эффективность архива. Количество буферов контролируется параметром log_archive_buffer, до 8.
Система в целом IO Проблемы производительности и конфликт будет также влиять на эффективность Архиве. Можно использовать способы, описанные ранее для уменьшения конфликтов ввода-вывода в системе, повысить общую эффективность ввода-вывода для повышения эффективности архивирования.
Привет! Меня зовут Александра, я работаю в команде тестирования производительности. В этой статье расскажу базовые сведения об OEM от Oracle. Статья будет полезна для тех, кто только знакомится с платформой, но и не только для них. Основная цель статьи — помочь провести быстрый анализ производительности БД и поиск отправных точек для более глубокого анализа.
OEM (Oracle Enterprise Manager) — платформа для управления БД. OEM предоставляет графический интерфейс для выполнения большого количества операций с базами данных: резервное копирование, просмотр аварийных журналов, графиков производительности.
Читайте также: