Oracle увеличить shared pool
Когда мы строим масштабируемое решение на основе Oracle Shared Server, не следует забывать о правильном выборе large_pool_size .
Если вы не хотите получить проблем - минимальной из которых будет неожиданное снижение скорости отклика БД при резком увеличении нагрузки (даже при использовании connection pooling), а максимальной - падение экземпляра с ошибкой 7445 (даже при использовании ASMM) - необходимо устанавливать достаточно большое значение вышеупомянутого параметра.
Окей, каковы оценки и как можно определить потребное количество памяти либо как промониторить использование large pool?
Достаточно приличной начальной цифрой будет следующее соотношение: примерно 30 Мб large pool на каждые 100 коннектов к БД .
Однако, при использовании shared server позади веб-сервера этого может оказаться недостаточно. Средняя цифра shared_pool_size для относительно некрупного веб-сервера с ожидаемой нагрузкой 700 веб-сессий (при настройках shared-сервера на прием до 2000 одновременных сессий) составляет свыше 64 Мбайт.
Попробуем взглянуть.
SQL> show parameter large_pool_size
Total memory for all sessions
----------------------------------------------
16537248 Bytes
16 мегабайт при не очень высокой установившейся нагрузке.
Величина кажется не очень большой и становится непонятно, зачем мы выделили 100 мегабайт large pool?
Однако не следует забывать, что у нас включен пулинг соединений:
SQL> show parameters dispatchers
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
dispatchers string (ADDRESS=(PROTOCOL=tcp)(POOL=o
n)(TICK=1)(CONNECTIONS=100)(SE
SSIONS=1000)(SERVICE=SUN11_XPT
))(DISPATCHERS=2)
max_dispatchers integer 5
что означает, что возможно внезапное и резкое увеличение нагрузки, которое, в свою очередь, способно сильно увеличить длину очередей (напоминаю, что пулинг соединений повторно использует лишь физические ресурсы соединений - сокеты, что до увеличения объема обработки, стоящего в очереди - то он никуда не девается), и, соответственно, потребность в UGA.
Вывод из всего вышесказанного следующий.
Относительно маленький large pool бывает лишь в небольших базах. В масштабируемых конфигурациях большой пул оправдывает свое название и должен становиться действительно большим . CVYFV92SG7U4
Память 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;
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, есть два способа изменить:
Это статическая модификация, для которой требуется перезагрузка системы.
Это для изменения его размера путем повторного подключения без перезапуска.
Если Вы движетесь в сторону интерактивного бизнеса, постоянно в Вашем внимании должны быть эти наиболее общие направления настройки.
В традиционной архитектуре клиент/сервер на плохо настроенной базе данных прикладные программы могут выполняться медленно, но в среде Web эти же приложения могут не выполняться вовсе. Представьте, например, что вы разрешили заказчикам или клиентам делать запросы к базе данных через ваш Web-сайт. Приложение, которое ранее было доступно всего лишь немногим пользователям вашего учреждения, теперь внезапно стало доступно, скажем, тысячам ваших заказчиков. Тем не менее, когда вы переводите ваши деловые действия на Web, основные принципы настройки базы данных остаются теми же самыми, независимо от того, как будет расти число запросов к вашей базе данных (пусть даже по экспоненте). Естественно, много связанных с эффективностью проблем являются характерными только для каждой конкретной системы, но я обнаружил, что если при настройке постоянно иметь в виду следующие четыре направления, это поможет быстро и просто улучшить производительность системы:
- Выделение экземпляру Oracle достаточного объема оперативной памяти.
- Хранение необходимых данных и других объектов в оперативной памяти.
- Выделение запросов, вызывающих проблемы.
- Настройка проблемных запросов.
В этой статье будут обсуждаться первые три направления. Настройка проблемных запросов - это отдельная тема, и о ней пойдет речь в следующейs статье.
Правило 1. Выделение экземпляру Oracle достаточного объема оперативной памяти
Выделение экземпляру Oracle достаточного объема памяти является весьма критичным. Необходимо иметь достаточное количество памяти, чтобы из-за ее нехватки не приходилось очищать буферный кэш от используемых данных, но все-таки не настолько много, чтобы это снижало общую производительность системы. В файле init.ora имеется много параметров, некоторые из которых можно использовать для распределения памяти вашей базе данных. Ниже приведены наиболее важные для управления распределением памяти параметры:
Используйте приведенный в листинге 1 запрос, чтобы найти текущие значения этих параметров. Увидеть значения этих параметров вы можете также, используя для этого средства Oracle Enterprise Manager (OEM).
Листинг 1. Нахождение установленных значений основных параметров настройки
DB_BLOCK_BUFFERS и DB_BLOCK_SIZE
Параметр DB_BLOCK_BUFFERS управляет системной глобальной областью (SGA), которую сервер базы данных Oracle использует для хранения и обработки данных в памяти. Когда потребители запрашивают данные, сервер помещает их в память, так, чтобы при последующих запросах пользователя (или пользовательского процесса) обеспечить более быстрый доступ к ним. Если значение параметра DB_BLOCK_BUFFERS слишком мало, то сервер слишком рано сбросит на диск самые старые из имеющихся в памяти данных. А это означает, что когда эти данные потребуются в следующий раз, серверу придется считывать их с диска, а не брать в оперативной памяти. Если же значение параметра DB_BLOCK_BUFFERS слишком велико, вашей системе может не хватить памяти для эффективного функционирования.
Вы можете выяснить, насколько эффективна настройка параметра DB_BLOCK_BUFFERS, измеряя коэффициент попаданий (hit ratio), значение которого говорит вам, какая часть данных, к которым осуществляют доступ потребители, находится в памяти. Чтобы найти его, вы можете использовать запрос, приведенный в листинге 2 . (Для графического представления этих данных, вы можете использовать модуль OEM Performance Manager.)
Листинг 2. Нахождение коэффициента попадания по чтению (read hit ratio).
select 1-(sum(decode(name, 'physical reads', value,0))/
(sum(decode(name, 'db block gets', value,0)) +
(sum(decode(name, 'consistent gets', value,0))))) * 100 "Read Hit Ratio"
Я считаю, что для коэффициента попаданий вполне приемлемо значение 95 процентов или выше. Если получившееся у вас значение ниже, чем 95 процентов, вам стоит скорректировать значение DB_BLOCK_BUFFERS. Хорошее эмпирическое правило для определения этого значения - назначить для DB_BLOCK_BUFFERS 25 процентов доступной оперативной памяти, хотя конкретный выбор может зависеть от размера вашей системы, объема доступной памяти и числа потребителей.
В дополнение к корректировке числа блоков данных, которые сервер хранит в памяти, вы можете изменить размер этих блоков, регулируя настройку параметра DB_BLOCK_SIZE. Этот параметр управляет количеством данных, которые база данных может считать в память в течение одной транзакции ввода/вывода. При работе с Oracle8, вы можете установить это значение равным 32Кбайт (в предыдущих версиях Oracle только 16Кбайт), но вы должны реорганизовать базу данных, чтобы значение параметра было изменено. Прежде, чем изменить этот параметр, загляните в руководства по настройке и администрированию базы данных Oracle.
[Прим. редактора: Обратите особое внимание, что автор все же говорит о необходимости реорганизовать базу данных, если Вы захотите изменить параметр DB_BLOCK_SIZE.]
Параметр SHARED_POOL_ SIZE управляет объемом памяти, распределенным для кэширования библиотеки и словаря данных. Вы можете выяснить, насколько эффективна настройка этого параметра, таким же образом, как и для параметра DB_BLOCK_BUFFER_SIZE - измеряя коэффициент попаданий. Коэффициент попаданий можно измерять отдельно для библиотеки и для словаря данных.
Коэффициент попаданий для библиотеки указывает, какой процент памяти сервер использует для операторов и объектов PL/SQL, например, процедур, пакетов, и триггеров. В дополнение к вычислению процента удач (см. листинг 2 ), вы должны также исследовать значение столбец RELOAD в представлении v$librarycache.
Перезагрузками называются операторы, которые были размещены в памяти, но которые пришлось перезагрузить после того, как сервер удалил их оттуда. Если у вас коэффициент попаданий меньше, чем 95 процентов, или число перезагрузок больше нуля, вам следует увеличить значение SHARED_POOL_SIZE.
Коэффициент попаданий для словаря данных указывает на распределение памяти для словаря данных Oracle. Естественно, полный словарь не может постоянно находиться в памяти, но размер словарного кэша важен, потому что база данных многократно обращается к словарю во время обработки операторов SQL. Чтобы найти процент удач для словаря, вы можете использовать следующий запрос:
коэффициент попаданий ---------- 95.40 %
Напомню еще раз: хорошо, если полученное значение 95 или выше. Если полученное вами значение меньше 95 процентов, стоит подумать об увеличении значения SHARED_POOL_SIZE.
Вы можете использовать приведенный в листинге 1 запрос, чтобы выяснить, сколько свободной памяти становится доступной для используемого значения SHARED_POOL_SIZE. Количество свободной памяти - еще один индикатор того, является ли значение SHARED_POOL_SIZE оптимальным.
Параметр SORT_AREA_SIZE распределяет память для сортировки. Число байтов, которое вы распределяете для этого параметра, управляет объемом памяти, выделяемой для сортировки каждому пользователю. Если сервер не может выполнить сортировку в памяти, он распределяет на диске временные сегменты для хранения промежуточных результатов выполнения, что увеличивает число операций ввода/вывода. Вы должны установить достаточно высокое значение этого параметра, чтобы предотвратить постоянное порождение временных сегментов, и в то же самое время оставить достаточно памяти для других процессов.
В представлении V$systat содержатся сведения о проценте сортировок, которые выполняются сервером в оперативной памяти и с использованием дисковой памяти. Чтобы найти процент сортировок, выполняемых в памяти, я использую запрос из листинга 2 . Если этот процент меньше, чем 90, вы должны рассмотреть вопрос об увеличении значения SORT_AREA_SIZE.
Правило 2. Хранение в оперативной памяти нужных данных
После того, как вы распределили экземпляру сервера Oracle оптимальный объем памяти, вы должны быть уверены, что наиболее важные данные остаются в памяти. Вы можете "закрепить" в памяти (pin) основные таблицы, объекты PL/SQL и пакеты, чтобы избежать сбрасывания их сервером на диск.
Если вы последовательно выполните один и тот же запрос два или более раз, вы обратите внимание, что второй (и последующие) запросы выполняются быстрее, чем первый. Дело в том, что начальный запрос перемещает данные таблицы в буфера данных в памяти, где они остаются, пока не будут вытолкнуты другими данными из других таблиц, используемых для ответа на другие запросы. Чтобы сохранить конкретную таблицу в памяти, вы должны закрепить ее в кэше. Это стоит делать только с малыми таблицами, которые находятся в постоянном использовании.
Если вы обнаружили, что сервер выталкивает основные таблицы из памяти, вы можете закрепить их в памяти, используя параметр CACHE оператора CREATE/ALTER TABLE:
Этот параметр гарантирует, что данные из таблицы после полного ее сканирования находятся в списке самых недавно использованных (most recently used - MRU) данных, а не в списке самых давно использованных (least recently used - LRU) данных, в результате чего они будут сохранены в памяти для последующего использования. При создании таблицы значение параметра по умолчанию - NOCACHE. Поэтому для того, чтобы кэшировать таблицу при первом же к ней доступе, нужно использовать следующий синтаксис:
Можете также использовать в запросе подсказку CACHE, чтобы закрепить таблицу и сохранять ее в кэше, начиная с первого ее использования, а именно:
Перед закреплением таблиц в памяти следует выяснить, сколько памяти все еще остается свободной, чтобы можно было учесть непредвиденные запросы. Полезно проводить проверку того, достаточно ли памяти распределено для данных после того, как система проработает большую часть дня. Чтобы выяснять, сколько памяти доступно для данных в любой момент времени, выполните следующий запрос к таблице x$bh (чтобы иметь возможность обратиться к таблицам x$, вы должны войти в систему как SYS, или создать представления таблиц, а затем создать привилегии для этих представлений):
Если в первые 30 минут после запуска системы окажется, что нет свободных буферов, вам, может быть, придется возвратиться к первому правилу и увеличить значение DB_BLOCK_BUFFERS.
Закрепление в памяти объектов и пакетов
Если Вы не можете поддерживать удовлетворительную настройку для SHARED_POOL_SIZE, может оказаться важно сохранять закрепленными в памяти наиболее часто используемые объекты. Вы можете закреплять операторы объекта PL/SQL в памяти, используя процедуру DBMS_SHARED_POOL.KEEP, например, следующим образом:
Вы можете также закрепить некоторые или все пакеты, используя некоторые встроенные пакеты Oracle типа STANDARD, DBMS_STANDARD и DIUTIL.
Чтобы закрепить все пакеты вашей системы, вы можете использовать скрипт из листинга 3 .
Листинг 3. Закрепление всех пакетов в кеше.
Правило 3. Нахождение проблемных запросов
Один-единственный индекс или запрос могут затормозить или даже вовсе прекратить работу всей системы. Запрашивая v$sqlarea, вы можете выявить запросы, которые создают проблемы для системы. Проблемные запросы - это такие запросы, для которых требуется наибольшее количество физических или логических операций чтения с диска.
Обнаружение запросов, для которых требуется наибольшее количество физических операций чтения с диска
В листинге 4 приводится запрос для выявления таких запросов, для выполнения которых требуется более 10000 операций чтения с диска. Для систем большего размера вам может потребоваться увеличить этот порог.
Листинг 4. Поиск запросов, которые выыполняют более 10,000 дисковых чтений.
Обнаружение запросов, для которых требуется наибольшее количество логических операций чтения с диска
В листинге 5 приводится запрос для выявления таких запросов, для выполнения которых требуется более 200000 операций чтения в оперативной памяти. И снова, если ваша система велика, вам может потребоваться увеличить этот порог.
Листинг 5. Поиск запросов, которые выполнят более чем 200,000 логических чтений.
Выходные данные примера указывают на то, что проблему создает индекс по столбцу division, когда в компании имеется только два отдела. Чтобы улучшить производительность, нужно либо отказаться от этого индекса, либо создать его, как двоичный (bitmap) - это должно помочь.
Заметьте, что представление v$sqltext отображает только ограниченную часть SQL_TEXT. В случае примеров в листингах 4 и 5 , удается увидеть полный запрос, но в других случаях запрос может быть слишком длинным, чтобы быть отображенным полностью. В таких случаях, чтобы получить полный текст запроса, вы можете выполнить для представления v$sqltext оператор JOIN.
Использование оператора AUTOTRACE
Лучший способ измерять эффективность запросов (применяя SQL*PLUS 3.3 и более поздние версии) состоит в том, чтобы использовать команду AUTOTRACE. Для реализации свойства AUTOTRACE вы можете использовать SQL-операторы из листинга 6 . (Помните, что вы должны заранее создать таблицу PLAN_TABLE, и что вы должны иметь соответствующие привилегии доступа, разрешенные для представлений V$.) Чтобы создать роль PLUSTRACE, выполните скрипт plustrce.sql как потребитель с именем SYS. (Подробности см. в документации Oracle.)
Листинг 6. Реализация возможности AUTOTRACE
Настройка вашей базы данных для оптимальной производительности является итерационным и аналитическим процессом. Как можно заметить из этого быстрого обзора ключевых целей, наряду с некоторыми подсказками и методами, сюда относятся и сбор данных, и тонкая настройка параметров или установок, и оценка влияния, а затем повторный старт процесса для системы. Обнаруживаемые вами проблемные области обычно требуют дальнейшего анализа. В следующей статье будут обсуждены некоторые методы обработки проблемных запросов, идентифицированных вами.
Ричард Дж. Немец (Richard J. Niemiec)- исполнительный вице-президент компании TUSC. Он работает с технологиями Oracle уже более десяти лет и является автором трех вышедших в издательстве Oracle Press книг. Сейчас он выполняет обязанности исполнительного вице-президента группы пользователей IOUG-A. Ричард Дж. Немец включен в Зал Славы предпринимателей (Entrepreneur Hall of Fame).
один или два раза в несколько месяцев эта база данных Oracle XE сообщает об ошибках ORA-4031. Это не указывает на какую-либо конкретную часть sga последовательно. Недавний пример:
ORA-04031: unable to allocate 8208 bytes of shared memory ("large pool","unknown object","sort subheap","sort key")
когда эта ошибка появляется, если пользователь продолжает обновлять, нажав на разные ссылки, они будут как правило, получить больше таких ошибок в разное время, то скоро они получат "404 не найдены" ошибки страницы.
перезапуск базы данных обычно решает проблему на некоторое время, затем через месяц или около того он появляется снова, но редко в том же месте в программе (т. е. он не кажется связанным с какой-либо конкретной частью кода) (приведенный выше пример ошибки был поднят со страницы Apex, которая сортировала 5000+ строк из таблицы).
Я пробовал увеличивать sga_max_size от 140M до 256M и надеюсь, что это поможет. Конечно, я не буду знать, помогло ли это, так как мне пришлось перезапустить базу данных, чтобы изменить настройку :)
Я запускаю Oracle XE 10.2.0.1.0 на коробке Oracle Enterprise Linux 5 с 512 МБ оперативной памяти. Сервер запускает только базу данных Oracle Apex (v3.1.2) и веб-сервер Apache. Я установил его почти со всеми параметрами по умолчанию, и он работает довольно хорошо в течение года или около того. Большинство проблем, которые я смог решить сам, настроив код приложения; он не интенсивно используется и не является критически важной для бизнеса системой.
вот некоторые текущие настройки, которые, я думаю, могут быть актуальными:
если это какая-либо помощь, вот текущие размеры SGA:
даже если вы используете ASMM, вы можете установить минимальный размер для большого пула (MMAN не будет сжимать его ниже этого значения). Вы также можете попробовать закрепить некоторые объекты и увеличить SGA_TARGET.
Не забывайте о фрагментации. Если у вас много трафика, ваши пулы могут быть фрагментированы, и даже если у вас есть несколько свободных МБ, не может быть блока больше 4 КБ. Проверьте размер самого большого свободного блока с запросом типа:
все текущие ответы касаются симптома (исчерпание пула общей памяти), а не проблемы, которая, вероятно, не использует переменные привязки в ваших запросах sql \ JDBC, даже если это не кажется необходимым. Передача запросов без переменных привязки заставляет Oracle каждый раз" жестко анализировать " запрос, определяя его план выполнения и т. д.
некоторые фрагменты из приведенной выше ссылки:
"Java поддерживает переменные bind, ваши разработчики должны начать использовать подготовленные операторы и связывать входы в него. Если вы хотите, чтобы ваша система в конечном итоге масштабировалась за пределами 3 или 4 пользователей - вы сделаете это прямо сейчас (исправьте код). Это не то, о чем нужно думать, это то, что вы должны делать. Побочный эффект это-ваши общие проблемы пула в значительной степени исчезнут. Это первопричина. "
"путь Оракула общий пул (очень важная структура данных общей памяти) operates основан на разработчиках, использующих переменные bind."
" переменные привязки настолько массово важны - я никоим образом не могу переоценивать их важность. "
следующие не нужны, поскольку они не исправляют ошибку:
- 1 PS-ef|grep oracle
- найти smon и убить pid для него
- среда SQL> запуск смонтировать в SQL>
- создать pfile из spfile;
перезапуск базы данных очистит ваш пул, и это решит проблему, а не проблему.
зафиксируйте свой large_pool, чтобы он не мог опуститься ниже определенной точки или добавить память и установить более высокий Макс память.
ошибка: ORA-04031: невозможно выделить 4064 байта общей памяти ("общий пул", " выберите increment$, minvalue, m. ", "SGA heap (3,0)", "kglsim heap")
запущен экземпляр ORACLE.
общая системная глобальная область 4831838208 байт Фиксированный размер 2027320 байт Переменный Размер 4764729544 байты Буферы базы данных 50331648 байт Повторить буферы 14749696 байт База данных подключена. SQL>
Это ошибка Oracle, утечка памяти в shared_pool, скорее всего, db, управляющая множеством разделов. Решение: на мой взгляд, патч не существует, проверьте с поддержкой oracle. Вы можете попробовать с помощью subpools или en (de)able AMM .
Читайте также: