|
|
ГЛАВА 3. НАСТРОЙКА РАСПРЕДЕЛЕНИЯ ПАМЯТИ.
------------------------------Д
Эта глава обсуждает второй шаг настроечного процесса,настройку распределения
памяти. Эта глава обсуждает выполнение настройки следующих структур памяти:
- контекстных областей
- КЭШа словаря данных
- КЭШа буферов
Выполнение СУБД ОРАКЛ может быть улучшено правильным распределением размеров
этих структур. В этой главе вы научитесь распределять память этих
структур, чтобы достичь наилучшего исполнения базы данных.
ЗНАЧЕНИЕ РАСПРЕДЕЛЕНИЯ ПАМЯТИ.
------------------------------
СУБД ОРАКЛ запоминает информацию в двух местах:
- в памяти
- на диске
Поскольку доступ к памяти намного быстрее,чем к диску,желательно для запросов
к данным обращаться к памяти,а не к диску. Для наилучшего выполнения выгодно
запоминать как можно больше данных в памяти,чем на диске. Однако,ресурсы
памяти операционной системы(ОС) ограничены. Настройка распределения памяти
включает распределение доступной памяти для структур памяти ОРАКЛа.
Вам следует настраивать распределение памяти после следующих рекомендаций,
представленных в главе 2"Настройка SQL-операторов и приложений" поскольку
потребности памяти для СУБД зависят от ваших приложений. Также вам следует
настроить распределение памяти до рассмотрения информации в главе 4"Настройка
ввода/вывода". Распределение памяти обуславливает количество вводов/выводов,
необходимое для работы СУБД. Эта глава покажет вам как распределить память,
чтобы выполнять как можно меньше вводов/выводов, а глава 4 покажет вам как
выполнять вводы/выводы наиболее эффективно.
СТРУКТУРЫ ПАМЯТИ ОРАКЛа.
------------------------
Этот раздел представляет следующие структуры памяти ОРАКЛа,важные при
настройке:
- контекстные области
- системная глобальная область (SGA)
- КЭШи
Эти структуры связаны их общей необходимостью для памяти. Увеличение размеров
дюбой из этих структур потенциально может улучшить выполнение. Каждая из этих
структур обсуждается детально в этой главе.
Контекстные области(КО).
------------------------
КО - это место в памяти,которое содержит информацию,необходимую для выполнения
SQL-операторов. Каждый SQL-оператор выполняется запросами СУБД к КО. Некоторые
прикладные средства ОРАКЛа позволяют вам контролировать как КО назначаются к
SQL-операторам в вашем приложении. Используя этот контроль,вы можете снизить
время исполнения ваших SQL-операторов.
Системная глобальная область (SGA).
-----------------------------------
SGA - это специальная структура памяти ОРАКЛа,которая содержит данные, часто
используемые ОРАКЛ-прцессами. Поскольку данные SGA области могут быть читаемы
-- 34 --
всеми ОРАКЛ-процессами,SGA располагается в общей памяти. Вы можете видеть как
много памяти выделяется под SGA и каждую из ее внутренних структур,используя
SQL*DBA-команду:
SQL*DBA> SHOW SGA
Вывод этой команды может выглядеть так:
Total System Global Area 431384 байт
Fixed Size 18236 байт
Variable Size 339420 байт
Database Buffers 65536 байт
Redo Buffers 8197 байт
КЭШи.
-----
Данные в SGA хранятся в КЭШах. КЭШ - это область памяти, которая содержит
копии данных, имеющихся на диске. Данные, запомненные в КЭШе, можно читать и
писать гораздо быстрее,чем с диска. SGA содержит следующие КЭШи, каждый КЭШ
содержит различные типы данных:
- КЭШ словаря данных
- КЭШ буферов
Когда пользователь ОРАКЛа получает данные,запомненные в КЭШе, эти данные могут
быть считаны непосредственно из памяти.Это называется "cache hit". Когда
пользователь требует данные,которых нет в КЭШе, происходит копирование данных
из файла базы данных в КЭШ перед доступом к ним. Это называется "cache miss".
Доступ к данным посредством "cache hit" очевидно быстрее,чем посредством
"cache miss".
Область КЭШа действует эффективно,если запрашиваемые данные окажутся в КЭШе.
Если КЭШ достаточно большой,то более вероятно,что он содержит данные,которые
запрашиваются. Увеличивая размеры КЭШа, вы можете увеличить процент запросов
данных типа "cache hit".
ШАГИ ПО НАСТРОЙКЕ РАСПРЕДЕЛЕНИЯ ПАМЯТИ.
--------------------------------------Д
Этот раздел описывает процесс настройки распределения памяти. Для наилучшего
эффекта вы должны следовать этим шагам в порядке изложения. Каждый шаг описан
ниже в этой главе.
Настройка вашей операционной системы(ОС).
-----------------------------------------
Убеждение, что ваша ОС используется гладко и эффективно, является твердой
основой для распределения памяти СУБД ОРАКЛ. Этот шаг дает вам также
информацию осуммарной величине памяти вашей ОС, доступной для ОРАКЛа.
Настройка синтаксического анализа (парсинга) и контекстных областей.
--------------------------------------------------------------------
Использование контекстных областей и частота парсинга в первую очередь
определяется вашими приложениями. Парсинг определяет частоту доступа к словарю
данных. Поэтому вам следует настроить контекстные области до настройки КЭШа
словаря данных.
Настройка КЭШа словаря данных.
------------------------------
Настройка КЭШа словаря данных - это простой,но важный шаг в процессе
-- 35 --
распределения памяти. КЭШ словаря данных требует малое количество памяти по
сравнению с КЭШем буферов. Однако, потеря КЭШа словаря данных обходится
дороже,чем потеря КЭШа буферов. Поэтому достаточное количество памяти должно
быть выделено, прежде всего,под КЭШ словаря данных.
Настройка КЭШа буферов.
------------------------
После настройки контактных областей и КЭШа словаря данных вы можете выделить
оставшуюся доступную память КЭШу буферов. Может оказаться необходимым
повторить шаги распределения памяти после пробного прогона процесса.
Последующие проходы позволят вам сделать отладку на ранних шагах,что является
основой изменений в последующих шагах. Например, если вы увеличиваете размер
КЭШа буферов,вам, возможно, придется выделить больше памяти ОРАКЛу,чтобы
избежать свопинга и пэйджинга (swaping & paging).
НАСТРОЙКА ВАШЕЙ ОПЕРАЦИОННОЙ СИСТЕМЫ.
------------------------------------Д
Вам следует начать настройку распределения памяти с настройки вашей
операционной системы с такими целями:
- уменьшить пэйджинг и свопинг
- привести в соответствие SGA и основную память
- выделить достаточно памяти отдельным пользователям
Эти цели являются основными в большинстве ОС. Однако,детали настройки вашей ОС
зависят от самой ОС. За подробностями настройки ОРАКЛа в вашей ОС обращайтесь
к руководству пользователя по инсталляции системы.
Уменьшение пэйджинга и свопинга.
--------------------------------
Ваша ОС может запоминать информацию в одном из следующих мест:
- реальная память
- виртуальная память
- расширенное запоминание
- диск
Ваша ОС может также перемещать информацию из одной области в другую. В
зависимости от вашей ОС эта передвижка называется пэджинг или свопинг. Многие
ОС используют пэйджинг и свопинг, чтобы разместить большее количество
информации, которой не достает в реальной памяти. Одноко, пэджинг и свопинг
требуют времени. Чрезмерный пэйджинг и свопинг могут снизить
производительность вашей ОС.
Поведение ОС может быть управляемо утилитами ОС. Излишний пэйджинг или свопинг
в этом случае сигнализирует, что новая информация часто перемещается в память.
В этом случае суммарная память вашей ОС может быть недостаточно большой, чтобы
содержать все, для чего вы выделили память. Вам следует либо увеличить память
вашей ОС, либо уменьшить ранее распределенную память.
Настройка системной глобальной области (SGA).
---------------------------------------------
Поскольку целью SGA является запоминание данных в памяти для частого доступа,
SGA всегда должна входить в основную память. Если SGA выгружается на диск,
доступ к ее данным замедляется. Вам следует убедиться, что SGA полностью
находится в памяти и не подвержена свопингу и пэйджингу.
-- 36 --
Распределение памяти пользователя.
----------------------------------
В некоторых ОС имеется возможность контролировать величину физической памяти,
выделяемой каждому пользователю. Убедитесь, что каждому пользователю выделено
достаточно памяти для размещения ресурсов, необходимых для выполнения их
приложений с СУБД. В зависимости от вашей ОС эти ресурсы могут включать:
- Вид исполнения ОРАКЛа
- SGA
- Прикладные средства ОРАКЛа
- Специальные прикладные данные
В некоторых ОС программные средства ОРАКЛа могут быть установлены так, что
один вид исполненияможет разделяться многими пользователями Разделяя вид
исполнения среди пользователей, вы можете снизить суммарную память, требуемую
для каждого пользователя.
ИСКЛЮЧЕНИЕ НЕНУЖНОГО СИНТАКСИЧЕСКОГО АНАЛИЗА(парсинга).
------------------------------------------------------Д
В этом разделе вы научитесь как исключать ненужный парсинг SQL-операторов.
Контролирование парсинга требует распределения памяти для контекстных
областей. Этот раздел обсуждает:
- что такое парсинг
- как связаны парсинг и контекстные области
- как распознать ненужный парсинг
- как распределить память для контекстных областей
Что такое парсинг?
------------------
Это шаг выполнения SQL-оператора системой СУБД ОРАКЛ. Каждый SQL-оператор,
выполняемый ОРАКЛом должен подвергнуться парсингу перед первым
выполнением,т.е. анализу. Когда SQL-оператор анализируется:
- ОРАКЛ проверяет оператор на правильность синтаксиса и семантики
- ОРАКЛ определяет имеет ли процесс, выдавший оператор, разрешение на доступ
к объектам базы данных, на которые ссылается оператор
- ОРАКЛ-оптимизатор выбирает план выполнения для оператора
Если SQL-оператор однажды был проанализирован,он может выполняться вновь без
повторного анализа. Поскольку парсинг дороже выполнения самого оператора,
желательно его делать как можно реже.
Контекстные области и курсоры.
------------------------------
Выполнение SQL-операторов требует пространства в памяти. После анализа
(парсинга) оператора, информация,необходимая для его выполнения, загружается в
контекстную область. Контекстная область - это рабочее пространство в памяти,
используемое для выполнения SQL-операторов. Курсор - это имя, определяющее
контекстную область. Распределение памяти для контекстных областей
определяется тремя INIT.ORA параметрами:
OPEN_CURSORS Этот параметр определяет суммарное количество контекстных
областей, которые может иметь один процесс одновременно.
Значение по умолчанию =50.
CONTEXT_AREA Этот параметр определяет размер контекстной области.
Значение по умолчанию = 4096 байт.
-- 37 --
CONTEXT_INCR Этот параметр определяет увеличение пространства ОРАКЛ, добав-
ляемого к контекстной области, если информация курсора
превышает значение,определяемое параметром CONTEXT_AREA. ОРАКЛ
CONTEXT_INCR до тех пор, пока она не станет достаточно
большой,чтобы вместить всю информацию курсора. Значение этого
параметра по умолчанию = 4096 байт.
После парсинга оператора он может быть выполнен снова пока его курсор-информа-
ция остается в контекстной области. Однако,если другие SQL-операторы
загружаются в контекстную область,предыдущие SQL-операторы должны быть
перетранслированы и переназначены в новую контекстную область для того,чтобы
быть выполненными снова.
Определение ненужного парсинга.
-------------------------------
Вы можете использовать SQL-трассировку,чтобы определить как много раз ваш
SQL-оператор анализируется. Запустите ваше приложение с SQLтрассировками и
проанализируйте статистику. Поле счетчика сообщит вам сколько раз каждый
оператор анализируется при выборке и исполнении. Для информации по
SQL-трассировке обратитесь к главе 7 "Выполнение тестовых программ".
Уменьшение парсинга.
--------------------
Если какой-либо оператор в вашем приложении анализируется повторно, старайтесь
уменьшить парсинг. Вы можете контролировать частоту парсинга в вашем
приложении. Реализация этого контроля специфична для каждого прикладного
средства ОРАКЛа.
Уменьшение парсинга в ОРАКЛ прекомпиляторе.
-------------------------------------------
В ОРАКЛ прекомпиляторе вы контролируете контекстные области и парсинг
следующими опциями:
- HOLD_CURSOR
- RELEASE_CURSOR
_ MAXOPENCURSORS
Эти опции могут быть заданы двумя способами:
- в командной строке прекомпилятора
- внутри прекомпилирующей программы
Этими опциями вы можете задействовать различные способы управления контекстной
областью в течение выполнения программы. Для подробной информации обратитесь к
следующим руководствам:
- Руководство программиста по ОРАКЛ прекомпилятору
- Руководство пользователя по PRO*Ada прекомпилятору
Уменьшение парсинга в интерфейсах вызова ОРАКЛа(OCIs).
------------------------------------------------------
(ORACLE Call Interfaces)
В OCIs вы можете выполнить контроль над парсингом и контекстными областями при
помощи следующих OCI вызовов:
OOPEN Этот вызов создает курсор и контекстную область
OSQL3 Этот вызов выполняет парстинг и запись в контекстную область
Для дополнительной информации обратитесь к следующим руководствам:
- Руководство программиста по OCI
- Руководство пользователя по PRO*Ada ORACLE Call Interface
-- 38 --
Уменьшение парсинга в SQL*Forms.
--------------------------------
В SQL*Forms вы также можете контролировать использует ли ваше приложение
контекстные области повторно. Этот контроль можно выполнить на трех уровнях:
- на триггерном уровне
- на form-уровне
- в процессе исполнения
Для полной информации обратитесь к инструкции разработчика SQL*Forms.
Распределение контекстных областей.
-----------------------------------
Повторное использование контекстных областей в вашем приложении определяет
какое количество парсингов и контекстных областей потребует ваше приложение.
Например, приложение,которое повторно использует контекстные области более,чем
для одного SQL-оператора, не требует так много контекстных областей, как
приложение, которое не использует их повторно. Однако, приложения,которые
повторно используют контекстные области, должны повторно анализировать
SQL-операторы, если результаты предыдущих анализов не могут быть сохранены.
Словом,чем реже вы хотите проводить анализ, тем больше контекстных областей
вам потребуется.
Будьте уверены, что вы имеете достаточное количество контекстных областей,
чтобы разместить все ваши SQL-операторы. Если вы уменьшаете парсинг, вам,
возможно, понадобится больше контекстных областей. Вам может также потребуется
увеличить предельное количество контекстных областей, разрешенных для одного
пользовательского процесса. Вы можете увеличить этот предел, увеличивая
значение INIT.ORA параметра OPEN_CURSORS. Значение этого параметра может быть
не менее 5 и не более 255, по умолчанию 50. Будьте осторожны, чтобы не стиму-
лировать пэйджинг и свопинг, выделив слишком много памяти для дополнительных
контекстных областей. Преимущества отсутствия анализа SQL-оператора могут
быть частично потеряны из-за чтения контекстных областей с диска, когда вам
необ- ходим доступ к ним. Вы, возможно, захотите поэкспериментировать, вы-
делив мало контекстных областей и выделив больше памяти под КЭШ сло- варя
данных и под КЭШ буферов. Эти КЭШи обсуждаются дальше в этой главе.
НАСТРОЙКА КЭШа СЛОВАРЯ ДАННЫХ.
------------------------------
В этом разделе вы научитесь настраивать КЭШ словаря данных. В этом разделе
рассматриваются следующие вопросы:
- что такое словарь данных
- что такое КЭШ словаря данных
- как управлять работой КЭШа словаря данных
- как улучшить работу КЭШа словаря данных
Что такое словарь данных?
-------------------------
Словарь данных ссылается на содержимое таблиц баз данных и содержит информацию
о базе данных, ее структурах, ее пользователях. Данные, запоминаемые в словаре
данных следующие:
- названия всех таблиц базы данных и образов(views)
- имена и типы полей таблиц базы данных
- права и привилегии всех пользователей ОРАКЛа
-- 39 --
Эта информация полезна как справочная для администратора базы данных,
пректировщиков приложений, а также порльзователей. К словарю данных также
часто обращается сам ОРАКЛ во время парсинга SQL-операторов. Этот доступ
необходим для работы СУБД.
Что такое КЭШ словаря данных.
-----------------------------
Поскольку словарь данных очень часто запрашивается СУБД, для содержания словаря
данных предназначена специальная область в SGA, которая называется КЭШ словаря
данных. Этой областью пользуются все ОРАКЛ процессы пользователя. КЭШ словаря
данных состоит из нескольких КЭШей. Каждый содержит информацию об определенном
объекте базы данных. Размер каждого КЭШа словаря данных определяется посредст-
вом INIT.ORA параметра. INIT.ORA параметры, которые определяют размеры КЭШей
словаря данных, имеют имена, начинающиеся с"DC_". Например, КЭШ, описывающий
поля, содержит информацию, которая описывает поля таблиц базы данных.
Количество элементов в этом КЭШе определяется INIT.ORA параметром DC_COLUMNS.
Для полной информации по КЭШам словаря данных и INIT.ORA параметрам, которые
определяют их размеры, обратитесь к приложению С "Изменение INIT.ORA
параметров".
Для наилучшего выполнения парсинга SQL-операторов КЭШи словаря данных должны
быть достаточно большими, чтобы содержать все наиболее часто запрашиваемые
данные словаря.
Проверка работы КЭШа словаря данных.
------------------------------------
Если пользовательский процесс, который выполняет SQL-оператор встречает "cache
miss",то он должен выполнить дополнительный SQL-оператор который затребует
таблицы данных в базе данных. Этот процесс называется рекурсивным вызовом,
поскольку ОРАКЛ вызывает сам себя. Рекурсивные вызовы часто производятся в
процессе выполнения и управления. Выполните следующие шаги, чтобы определить
воздействует ли "cache miss" на работу вашего СУБД:
1.Проверьте рекурсивные вызовы
2.Определите появляются ли рекурсивные вызовы в ответ на "cache miss"
Проверка рекурсивных вызовов.
-----------------------------
Количество рекурсивных вызовов определяется статистикой рекурсивных вызовов.
Наблюдайте эту статистику на дисплее при помощи утилиты SQL*DBA MONITOR
STATISTICS USER. На рис.3-1 показан экран дисплея. Для просмотра экрана
выполните SQL*DBA команду:
SQLDBA> MONITOR STATISTICS USER
Поле TOT показывает совокупную величину для каждой статистики с момента, когда
вы начали просмотр на дисплее. На рис.3-1 вы можете видеть, что суммарная
величина для статистики рекурсивных вызовов=0.
Рис.3-1. Экран, получаемый при выполнении SQL*DBA MONITOR STATISTICS
USER.
Ъ------------------------------------------------------------------ї
і ORACLE Statistics Monitor June 22 14:22:55 і
і ORACLE PID: 0 Session 0 User Name SYSTEM STATISTICSі
і Statistic Name CUR AUG MAX MIN TOT і
і--------------------- ------- ------ -------- ------- --------і
і logons 2 null null null 626 і
і current logons 1 null null null 88 і
-- 40 --
і cumulative opened cu 10 null null null 5820 і
і current open cursors 9 null null null 945 і
і user commits 0.71 0.71 0.71 0.71 5 і
і user rollbacks 0.00 0.00 0.00 0.00 0 і
і user calls 24.86 24.86 24.86 24.86 174 і
і recursive calls 0.00 0.00 0.00 0.00 0 і
і messages sent 0.71 0.71 0.71 0.71 5 і
і messages received 0.71 0.71 0.71 0.71 5 і
і background timeouts 0.29 0.29 0.29 0.29 2 і
А------------------------------------------------------------------Щ
SQL-операторы, выполняемые немедленно после запуска базы данных, часто
обуславливают рекурсивные вызовы. Эти рекурсивные вызовы происходят из-за
того, что КЭШ словаря данных начально является пустым и запросы к словарю
приводят к потери КЭШа. Для процесса настройки проверяйте рекурсивные вызовы
после полной установки базы данных.
Если СУБД прекращает делать рекурсивные вызовы после запуска,то ваш КЭШ
словаря данных вероятно велик для вашего словаря данных. В этом случае
проверьте работу КЭШа,используя таблицу,описанную в следующем разделе.
V$ROWCACHE таблица.
-------------------
Статистика, отражающая работу словаря данных сохраняется в динамически
заполняющейся таблице SYS.V$ROWCACHE. Каждая запись в этой таблице содержит
статистику для одного из КЭШей словаря данных. Эта статистика отражает всю
работу словаря данных с последнего старта базы данных. Следующие поля в этой
таблице отражают использо- вание и эффективность каждого КЭШа:
PARAMETER Этот параметр идентифицирует специальный КЭШ словаря данных.
Для каждой записи значение в этом поле является именем
INIT.ORA параметра, который определяет количество элементов в
КЭШе словаря данных. Например, в записи, которая содержит
статистику для КЭШа файловых дескрипторов, значение поля
выражено "dc_files"
GETS Это поле показывает суммарное количество запросов для информации
по соответствующему объекту данных. Например,в записи, которая
содержит статистику для КЭШа файловых дескрипторов, это поле имеет
суммарную величину запросов для описанных данных
GETMISSES Это поле показывает количество запросов к данным, отсутствующим
в КЭШе
COUNT Это поле содержит суммарное количество элементов в специальном
КЭШе. Значение вэтом поле- это величина INIT.ORA параметра,
определенного в поле PARAMETER. Например,в записи,которая
содержит статистику для КЭШа дескрипторов файлов это поле содержит
суммарное количество элементов в КЭШе файловых дескрипторов.
Величина вэтом поле - это значение INIT.ORA параметра DC_FILES.
USAGE Это поле показывает количество КЭШ-элементов,которые содержат
данные. Если КЭШ полон эта величина эквива- лентна значению
поля COUNT.
Запрос таблицы V$ROWCACHE.
--------------------------
Запрос таблицы осуществляется SQL-оператором:
-- 41 --
SELECT PARAMETER, GETS, GETMISSES, COUNT, USAGE
FROM SYS.V$ROWCACHE
Результат этого запроса может выглядеть следующим образом:
PARAMETER GETS GETMISSES COUNT USAGE
----------------------------------------------------------------Д
dc_free_extents 2497 127 50 50
dc_used_extents 2400 213 50 50
dc_segments 5370 31 50 30
dc_tablespaces 2430 3 25
dc_tablespaces 1222 3 25
dc_tablespace_quotas 2325 3 25
dc_ files 0 0 25
dc_users 27481 6 50
dc_rollback_segments 2152 10 25 10
dc_objects 138267 90 175 130
dc_costraints 18 7 150
dc_objects_ids 21922 801 50
dc_tables 162269 874 150 150
dc_synonyms 12447 8 50
dc_sequences 5049 4 20
dc_usernames 25105 20 5 20
dc_columns 912753 861 600 520
dc_table_grants 7277 14 55
dc_column_grants 0 0 100
dc_indexes 108060 45 80 50
dc_costraint_defs 0 0 200
dc_sequence_grants 0 0 20
22 rows selected
Интерпретация таблицы V$ROWCACHE.
---------------------------------
Анализ первой записи в этой таблице позволяет сделать следующие замечания:
- Значение поля PARAMETER есть"dc_extents".Эта величина показывает, что
первая запись содержит статистику для КЭШа "free extent des- criptions"
- Значение поля GETS показывает,что было 2497 запросов к данным "free extent
descriptions"
- Значение поля GETMISSES показывает,что для 127 запросов к данным "free
extent descriptions" данных в КЭШе не оказалось(cache miss)
- Значение поля COUNT показывает,что "free extent descriptions" КЭШ содержит
50 элементов
- Значение поля USAGE показывает,что все 50 элементов этого КЭШа содержат
данные
Последующие записи содержат статистику для других КЭШей словаря данных. Значе-
ние поля PARPMETER в каждой записи определяет конкретный КЭШ словаря данных.
Например, значение поля PARAMETER в третьей записи есть"dc_segments",значит
эта запись содержит статистику для "segment descriptions" КЭШа. Количество
элементов этого КЭШа определяется INIT.ORA параметром DC_SEGMENTS.
Заметьте,что значение "dc_tablespaces" появляется дважды в поле PARAMETER. Оно
-- 42 --
появляется в двух разных записях потому, что значение INIT.ORA параметра
DC_TABLESPACES определяет размер двух различных КЭШей словаря данных. Работа
каждого из них отражена в отдельной записи таблицы.
Уменьшение неудовлетворенных запросов к КЭШу словаря данных(cache misses).
Проверьте работу КЭШа,наблюдая поля GETS и GETMISSES. "Cache misses" следует
оценивать в некоторых случаях. Во время старта базы данных КЭШ словаря данных
не содержит данных. Вэтом случае любое обращение будет иметь результатом
"cache miss". Чем больше данных прочитано в КЭШ, тем меньше величина "cache
miss". В конце концов база достигнет "устойчивого состояния", при котором в
КЭШе будут находиться наиболее часто используемые данные. В этом случае
величина "cache misses" будет минимальной. Для часто запрашиваемых КЭШей
отношение GETMISSES к GETS должно быть меньше 10-15%.
Если это соотношение продолжает увеличиваться сверх этого порога во время
выполнения вашего приложения,вам следует рассмотреть возможность увеличения
количества элементов в этом КЭШе.INIT.ORA параметр, определяющий количество
элементов в КЭШе словаря, идентифицируется значением поля PARAMETER.
Уменьшение количества неиспользуемых элементов КЭШа словаря данных.
-------------------------------------------------------------------
Исследуйте поля COUNT и USAGE. Если какие-либо записи в таблице V$ROWCACHE
имеют значение поля USAGE значительно меньше значения поля COUNT,то это
свидетельствует о том,что КЭШ не полностью заполняется. В этом случае вы
имеете возможность уменьшить количество элементов в КЭШе. Уменьшив размер КЭШа
вы экономите память для других структур ОРАКЛа.
НАСТРОЙКА КЭШа БУФФЕРОВ.
------------------------
В этом разделе вы научитесь настраивать КЭШ буферов.В этом разделе
рассматриваются следующие вопросы:
- что такое КЭШ буферов
- как КЭШ буферов улучшает исполнение
- как наблюдать работу КЭШа буферов
- как улучшить работу КЭШа буферов
Что такое КЭШ буферов?
-----------------------
КЭШ буферов - это область в SGA, которая содержит копии блоков базы данных.
Эти блоки содержат данные, которые часто используются ОРАКЛ процессами. Эти
блоки содержат данные:
- таблиц
- индексов
- откатных сегментов
- кластеров
Каждый буфер в КЭШе может содержать один блок данных. Количество буферов в
КЭШе определяется INIT.ORA параметром DB_BLOCK_BUFFERS. Значение по умолчанию
для этого параметра зависит от вашей ОС и от вида компьютера. Размер КЭШа для
больших компьютеров увеличивают для увеличения производительности.
Как КЭШ буферов улучшает исполнение.
-------------------------------------
Имея копии блоков в памяти, КЭШ буферов снижает время, необходимое для доступа
-- 43 --
к данным. КЭШ буферов дает два основных преимущества:
- ОРАКЛ пользовательские процессы могут избежать ввода/вывода с диска, исполь-
зуя данные,запомненные в КЭШе буферов.
- Поскольку КЭШ буферов находится в разделяемой памяти, все ОРАКЛ процессы
имеют к нему доступ. Если один процесс прочитает блок, все другие процессы
могут иметь к нему доступ.
Проверка работы КЭШа буферов.
------------------------------
ОРАКЛ собирает эту статистику,которая отражает доступ к данным:
Logical Reads Значением этой статистики является суммарное количество
запросов к данным. Эта величина включает
запросы, удовлетворенные при доступе к буферам в памяти.
Physical Reads Значением этой статистики является суммарное количество
запросов к данным. Учитываются запросы, выполненые при
доступе к файлам базы данных на диске.
Hit Ratio Значением этой статистики является процент от общего
количества запросов, удовлетворенных исключительно
при запросах к памяти.
ОРАКЛ расчитывает статистику Hit Ratio по формуле:
Hit Ratio = (Logical Reads - Physical Reads)/Logical Reads
Вид этой статистики,полученной с помощью SQL*DBA MONITOR I/O показан
на рис.3-2. Чтобы получить это изображение выполните SQL*DBA команду
SQLDBA> MONITOR IO
Это изображение имеет две части:
Interval Левая половина экрана называется Interval. Статистика в этой
половине отражает ввод/выводы, которые произошли после
последнего обновлени экрана.
Cumulative Правая половина экрана называется Cumulative Статистика в этой
половине экрана отображает ввод/выводы,которые произошли с
начала процесса наблюдения.
Слева вы можете видеть, что величина Logical Reads = 114, величина
Physical Reads = 11 и Hit Ratio = 90%.
В половине Cumulative величина Logical Reads = 3215, величина
Physical Reads = 261 и Hit Ratio = 92%.
Рис.3-2.Экран SQL*DBA MONITOR I/O
Ъ------------------------------------------------------------------ї
Г--------Д Interval -------- ------ Cumulative --------Ді
і%Logical %Physical %Logical %Logical %Physical %Logicalі
і Reads Reads Urites Reads Reads Urites і
і0 100 0 100 0 100 PID(SNO) 0 100 0 100 0 100і
Г-------- --------Д -------- -------- -------- --------Д --------ґ
і 2(1) і
і 3(1) і
і 4(1) і
-- 44 --
і 5(1) і
і- - - 6(1) = = = і
і= = = 7(1) = = = і
і= = 8(1) = = = і
і- = - 9(1) = = = і
і= = = 10(1) = = = і
і- - - 11(1) = = = і
і- - - 12(1) = = = і
і= = = 13(1) = = = і
і 14(1) і
Г-------- --------Д -------- -------- --------Д --------ґ
і 114 11 90 Totals 3215 261 2200і
і 0.90 Hit Ratio 0.92і
і і
А------------------------------------------------------------------Щ
Уменьшение количества неудовлетворенных запросов(cache misses).
---------------------------------------------------------------
Если ваш Hit Ratio низок,порядка 60-70%, то вы, вероятно, захотите увеличить
количество буферов в КЭШе для улучшения работы. Чтобы сделать КЭШ буферов
больше, увеличьте значение INIT.ORA параметра DB_BLOCK_BUFFERS.
ОРАКЛ может собрать статистику, оценивающую выигрыш производительности, который
появится в результате увеличения размеров вашего КЭШа буферов. При помощи этой
статистики вы можете оценить какое количе- ство буферов добавит к КЭШу.
Таблица X$KCBRBH.
-----------------
Виртуальная таблица SYS.X$KCBRBH содержит статистику, которая оценивает
выполнение для увеличенного КЭШа. Каждая запись в таблице отражает
относительное улучшение выполнения от добавления буфера к КЭШу. Ниже
рассматриваются поля этой таблицы:
INDX Значение этого поля на один меньше,чем количество буферов, которые
могут быть добавлены к КЭШу.
COUNT Значение этого поля - это количество дополнительных "cache
hit",которые можно получить добавлением INDX+1 буферов к КЭШу.
Например, в первой записи таблицы величина INDX = 0 и величина COUNT равна
количеству "cache hit",которые будут получены при добавлении первого
дополнительного буфера к КЭШу.Во второй записи значение INDX = 1, а величина
COUNT - это количество "cache hit" для второго дополнительного буфера.
Разрешение заполнения таблицы X$KCBRBH.
---------------------------------------
Статистика,собраная в таблице X$KCBRBH, контролируется INIT.ORA параметром
DB_BLOCK_LRU_EXTENDED_STATISTICS. Значение этого параметра определяет
количество записей в этой таблице. По умолчанию величина этогопараметра = 0,
что означает "не собирать статистику". чтобы разрешить сбор статистики в эту
таблицу, установите некоторую величину этого параметра. Например,если эта
величина = 100, ОРАКЛ соберет 100 записей статистики, каждая означает
добавление одного буфера.
-- 45 --
Сбор этой статистики влечет за собой некоторую перегрузку. Эта перегрузка в
работе пропорциональна количеству записей в таблице. Собирайте статистику
только во время настройки КЭШа буферов. Когда вы не настраиваете, запретите
сбор статистики для улучшения производительности.
Запрос таблицы X$KCBRBH.
------------------------
Благодаря информации из этой таблицы вы можете предсказать потенциальный
выигрыш от увеличения размера КЭШа. Например,для того, чтобы определить
количество дополнительных "cache hit",которые могут появиться,если вы добавите
20 буферов к КЭШу, запросите эту таблицу посредством SQL-оператора:
SELECT SUM(COUNT) ACH
FROM SYS.X$KCBRBH
WHERE INDX < 20
Вы можете также определить каким образом эти дополнительные "cache hit"
улучшат Hit Ratio. Используйте следующую формулу для расчета Hit Ratio,
основываясь на величинах статистик Logical Reads и Physical Reads и количестве
дополнительных "cache hit"(ACH), полученных при запросе:
Hit Ratio = (Logical Reads - Physical Reads + ACH)/Logical Reads
Группирование записей в таблице X$KCBRBH.
-----------------------------------------
Другим способом исследования этой таблицы является группирование
дополнительных буферов в большие интервалы. Вы можете запросить таблицу
X$KCBRBH следующим SQL-оператором:
SELECT 250*TRUNC(INDX/250)+1іі'to'іі250*(TRUNC(INDX/250)+1) INTERVAL
SUM(COUNT) CACHE HITS
FROM SYS.X$KCBRBH
GROUP BY TRUNC(INDX/250)
Результат этого запроса может выглядеть так:
INTERVAL CACHE HITS
--------------------------
1 to 250 16080
251 to 500 10950
501 to 750 710
751 to 1000 23140
где:
INTERVAL Это интервал дополнительных буферов добавленных к КЭШу.
CACHE HITS Это количество дополнительных "cache hit",полу-
ченных при добавлении буферов в поле INTERVAL.
Исследование вывода этого запроса ведет к следующим заключениям:
- Если к КЭШу будет добавлено 250 буферов, то будет получен выигрыш в 16080
"cache hit".
- Если будет добавлено еще 250 буферов,т.е. в сумме 500 буферов, то будет еще
добавлено 10950 "cache hit" дополнительно к ранее добавленным 16080.
-- 46 --
- Если добавить еще 250 буферов,т.е. всего 750 буферов, то дополнительно
прибавится еще только 710 "cache hit", давая в сумме 27740 "cache hit".
- Если еще добавить 250 буферов до 1000, то выигрыш будет 23140 "cache hit",
давая в сумме 50880 дополнительных "cache hit".
Основываясь на этом обзоре, вам следует решить какое количество буфферов
добавить к КЭШу. Можно принять следующее решение:
- Разумно добавить 250 или 500 буферов в зависимости от имеющихся ресурсов
памяти. Оба эти добавления обеспечат значительный выигрыш
производительности.
- Неразумно добавлять 750 буферов. Выигрыш незначителен по сравнению с
предыдущим добавлением, а поэтому память,выделенная под эти буфера, могла
бы быть использована под другие структуры ОРАКЛа.
- Разумно добавить 1000 буферов,если позволяют ресурсы памяти. Выигрыш
значителен по сравнению с добавлением 250,500 и 750 буферов
Удаление ненужных буферов.
---------------------------
Если ваш Hit Ratio высок,то КЭШ, веротно достаточных размеров, чтобы содержать
наиболее часто запрашиваемые данные. В этом случае вы можете уменьшить размеры
КЭШа и все-таки обеспечить хорошую производиительность. Чтобы это сделать,
нужно уменьшить величину INIT.ORA параметр DB_BLOCK_BUFFERS. Вы можете
добавить размеры памяти для других ОРАКЛ структур. ОРАКЛ может собрать
статистику,чтобы предсказать производительность КЭШа буферов с меньшими
размерами. Исследование этой статистики может помочь вам определить какаим
наименьшим вы можете иметь КЭШ без значительного снижения производительности.
Таблица X$KCBCBH.
-----------------
Виртуальная таблица SYS.X$KCBCBH содержит статистику для оценки производитель-
ности при уменьшении КЭШа буферов. Эта таблица аналогична по структуре
предыдущей. она содержит следующие поля:
INDX Значение этого поля на один меньше,чем ожидаемое количество
буферов КЭШа.
COUNT значение этого поля - это количество "cache hit", определяемое
количеством буферов INDX+1.
Количество записей в вашей таблице эквивалентно количеству буферов в вашем
КЭШе.Каждая запись в таблице отражает количество "cache hit" свойственных
одному буферу. Например,во второй записи значение INDX = 1,а значение поля
COUNT - это количество "cache hit" для второго буфера. В третьей записи
значение INDX = 2,а значение поля COUNT равно количеству "cache hit" для 3
буфера. Первая запись таблицы содержит специальную информацию, значение
INDX = 0 и значение COUNT равно суммарному количеству блоков, помещенных в
первый буфер в КЭШе.
Разрешение заполнения таблицы X$KCBCBH.
---------------------------------------
Сбор статистики в этой таблице контролируется INIT.ORA параметром
DB_BLOCK_LRU_STATISTICS. Величина этого параметра определяет собирает ли ОРАКЛ
статистику. Значение по умолчанию этого параметра равно FALSE, что означает,
что стстистика на собирается. Для разрешения сбора статистики установите этот
-- 47 --
параметр в состояние TRUE. Сбор статистики приводит к более напряженной
работе. Собирайте статистику, когда вы настраиваите КЭШ буферов. Когда вы не
настраиваете, то запретите сбор статистики для увеличения производительности
Обращение к таблице X$KCBCBH.
-----------------------------
Исходя из информации этой таблицы вы можете предсказать количество дополнитель-
ных "cache miss", которые будут появляться,если количество буферов в КЭШе
будет уменьшено. Если ваш КЭШ буферов содержит 100 буферов,вы можете захотеть
узнать какое количество "cache miss" появится,если их будет 90. Для определения
дополнительных "cache miss" обратитесь к таблице следующим оператором:
SELECT SUM(COUNT) ACM
FROM SYS.X$KCBCBH
WHERE INDX >= 90
Вы можете также определить Hit RAtio, основываясь на этом размере КЭШа.
Используйте следующую формулу для расчета Hit Ratio,используя полля Logical
Reads и Physical Reads и на количестве дополнительных "cache miss(ACM)",
полученных при запросе:
Hit Ratio = (Logical Reads - Physical Reads - ACM)/Logical Reads
Группировка записей в таблице X$KCBCBH.
---------------------------------------
Другим способом исследовать эту таблицу является группирование буферных
интервалов. Например,если ваш КЭШ содержит 100 буферов,вы можете разделить его
на 4 буферных интервала. Запрос таблицы можно осуществить оператором вида:
SELECT 25*TRUNC(INDX/25)+1іі' to 'іі25*(TRUNC(INDX/25)+1) INTERVAL
SUM(COUNT) CACHE HITS
FROM SYS.X$KCBCBH
WHERE INDX > 0
GROUP BY TRUNC(INDX/25)
заметьте, что WHERE предложение предотвращает запрос статистики из первой
записи. Результат этого запроса может выглядеть следующим образом:
INTERVAL CACHE HITS
--------------------------Д
1 to 25 1900
26 to 50 1100
51 to 75 1360
76 to 100 230
Где:
INTERVAL Это интервал буферов в КЭШе
CACHE HITS Количество "cache hit",соответствующих буферам в поле INTERVAL
Исследование результата этого запроса позволяет сделать следующие выводы:
- Последние 25 буферов в КЭШе (с 76 по 100) выделяют 230 "cache hit". Если
КЭШ уменьшить на эти 25 буферов, то теряются 230 "cache hit".
- Третий буферный интервал с 51 по 75 приводит к потере 1360 "cache hit",если
эти буферы убрать из КЭШа. Они теряются дополнительно к 230,т.е. уменьшение
на 50 буферов приводит к суммарной потере 1590 "cache hit".
-- 48 --
- Второй буферный интервал (с 26 по 50) приведет к потере 1100 "cache
hit",если этот интервал буферов убрать из КЭШа. В сумме с предыдущими это
будет 2690 потерянных "cache hit".
- Первых 25 буферов (cо 2 по 25) приводят к потере 1900 "cache hit",если этот
интервал буферов убрать из КЭШа. Удаление всех буферов приведет к потере
всех "cache hit".
Основываясь на этом обзоре,вы должны решить уменьшать ли вам размеры КЭШа.
Могут быть следующие решения:
- Если память ограничена,то разумно убрать 25 буферов из КЭШа. Буферы с 76
по 100 добавляют сравнительно мало "cache hit". Удаление этих буферов не
ухудшит значительно работу КЭШа, а освободившаяся память может быть
использована другими средствами ОРАКЛа.
- Неразумно уменьшать КЭШ блее,чем на 25 буферов. Например, уменьшение на
50 буферов приведет к значительному ухудшению работы КЭШа, т.к.потерянные
"cache hit" составят значительную часть их общего количества.
ПЕРЕРАСПРЕДЕЛЕНИЕ ПАМЯТИ.
------------------------Д
После доведения памяти ваших ОРАКЛ структур до требуемых размеров, оцените
вновь работу контекстных областей, КЭШа словаря данных и КЭШа буферов. Если вы
уменьшили расход памяти некоторых из этих структур, вы можете захотеть выделить
больше памяти под другие структуры. Например,если вы уменьшили размер КЭШа
буферов,вы можете захотеть извлечь выгоду от дополнительного предоставления
памяти под кпнтекстные области. Настройте вашу операционную систему снова.
Доведение до нужных размеров памяти ОРАКЛ структур возможно изменили
потребности ОРАКЛа в памяти. Особенно убедитесь,что нет излишнего пэйджинга и
свопинга. Например, если размер КЭШа словаря данных или КЭШа буферов увеличил
SGA и это может быть слишком большой размер для основной памяти,то в этом
случае SGA может подвергнуться свопингу и пэйджингу.
В процессе перераспределения памяти вы можете обнаружить,что размеры ОРАКЛ
структур памяти требуют больше памяти,чем может предоставить операционная
система. В этом случае вы можете улучшить работу СУБД только добавлением
памяти вашему компьютеру.
4-1 Инструкция по настройке СУБД ОРАКЛ
ГЛАВА 4. НАСТРОЙКА ВВОДА/ВЫВОДА.
----------------------Д
Эта глава представляет третий щаг настроечного процесса:
Настройку ввода/вывода (I/O).
Эта глава научит вас как избежать узких мест I/O,которые могут помешать СУБД
ОРАКЛ работать с максимальной производительностью.
В этой главе вы научитесь как:
- снизить дисковые конфликты
- распределить пространство в блоках данных
- избежать динамического управления пространством
-- 49 --
ЗНАЧЕНИЕ НАСТРОЙКИ ВВОДА/ВЫВОДА.
--------------------------------
Выполнение многих программных приложений обычно ограничивается дисковым I/O.
Часто работа центрального процессора может быть задержана пока не закончится
работа I/O. Такое приложение называется "ограниченное вводом/выводом".
Версия 6.0 СУБД ОРАКЛ спроектирована таким образом,что выполнение не должно
быть ограничено I/O. Важно настроить I/O после распределения памяти,
рекомендованого в главе 3. Глава 3 показывает вам как распределить память,чтобы
снизить до минимума I/O. После достижения этого минимума следуйте инструкциям
этой главы,чтобы выполнять необходимые I/O эффективно насколько возможно.
ПРОЦЕСС ЗАПИСИ БАЗЫ ДАННЫХ СУБД (DBWR).
--------------------------------------Д
DBWR - это основной процесс ОРАКЛа,ответственный за управление КЭШем буферов.
DBWR процесс записывает модифицированные блоки данных из КЭШа буферов,
находящихся в SGA области в файлы базы данных на диске. DBWR выполняет главную
часть дискового I/O,необходимую для работы СУБД ОРАКЛа.
В выпусках ОРАКЛа версии 6.0,предшествовавших 6.027 управление КЭШем буферов
было основной целью настройки СУБД ОРАКЛа. Однако в версии 6.027 появился DBWR.
DBWR теперь управляет КЭШем буферов более эффективно и не требует настройки.
Для дополнительной информации относительно роли DBWR в управлении КЭШем буферов
обратитесь к приложению В данной инструкции.
СНИЖЕНИЕ ДИСКОВЫХ КОНФЛИКТОВ.
----------------------------Д
В этом разделе вы научитесь снижать дисковые конфликты. В этом разделе
обсуждаются следующие вопросы:
- что такое дисковый конфликт
- как следить за работой диска
- как уменьшить загрузку диска
Что такое дисковый конфликт?
----------------------------
Дисковые конфликты возникают когда много процессов обращаются к одному и тому
же диску одновременно.
Большинство дисков имеют ограничения на количество доступов и суммарное
количество данных, которое они могут передать за секунду. Когда достигаются
эти ограничения, процессы вынуждены ожидать доступа к диску.
Наблюдение за работой диска.
----------------------------
Работа диска отражается в:
- ORACLEFILE I/O статистике
- статистике операционной системы
СУБД ОРАКЛ имеет ORACLEFILE I/O статистику, которая отражает доступ к файлам
ОРАКЛа. Ваша ОС также может сохранять статистику для дисковых запросов ко всем
файлам.
Наблюдение работы диска с ОРАКЛом.
----------------------------------
Проверьте дисковые обращения к файлам ОРАКЛа при помощи SQL*DBA MONITOR FILE
I/O. Рис.4-2 покажет этот экран.Для получения этого экрана выполните SQL*DBA
команду: SQLDBA > MONITOR FILE SQL*DBA MONITOR FILE I/O отображает список всех
-- 50 --
файлов базы данных, к которым обращалась СУБД ОРАКЛ,вместе со статистикой,
отражающей их I/O активность. Для каждого файла базы данных выдается
статистика:
Request Rate Это среднее количество чтений из каждого файла
Read/s базы данных за секунду
Request Rate Это количество записей в каждый файл базы
Write/s данных за секунду
Batch Size Это среднее количество блоков данных,записываемых
blks/W в каждый файл базы данных за одну запись
Суммарное I/o соотношение для одного диска это сумма Request Rate Read/s и
Request Rate Write/s для всех файлов базы данных, управляемых ОРАКЛом и
находящихся на этом диске. Определите эту величину для каждого из ваших дисков.
Определите также суммарное количество блоков, записываемых на каждый за
секунду. Для одного файла количество блоков, записываемых за секунду,
определяется параметрами Request Rate Write/s и Batch Size blks/W. Суммарное
количество блоков, записываемых на каждый диск, является суммой блоков,
записываемых во все файлы.
Рис.4-1 Вид экрана для SQL*DBA MONITOR FILE I/O
Ъ------------------------------------------------------------------ї
і ORACLE FILE I/O MONITOR і
і Request Rate Batch Size Response Time Total Blocksі
іFile Name Read/s Write/s blks/R blks/W Read Write Read Writtenі
і--------Д -------------- -------------- ------------ ------------Дґ
іDISKSMKT4:[HOMAIL]V60MAIL_SYS1.ORA і
і 0.40 1.00 1.00 1.00 0.00 0.00 4705 2803і
іDISKSMKT3:[HOMAIL]V60MAIL_TBL_A01.ORA і
і 3.60 1.20 1.00 1.00 0.00 0.00 20477 3255і
іDISKSMKT1:[HOMAIL]V60MAIL_TBL_B01.ORA і
і 8.20 1.20 2.00 1.00 0.00 0.00 32127 2884і
іDISKSMKT2:[HOMAIL]V60MAIL_TBL_B02.ORA і
і 4.20 2.80 1.00 1.00 0.00 0.00 20364 3208і
А------------------------------------------------------------------Щ
Наблюдение за работой диска в операционной системе.
---------------------------------------------------
Файлы базы данных, хранящиеся на диске и файлы журнала регистрации могут
содержать вспомогательные файлы, которые не относятся к ОРАКЛу.Обращение к
таким файлам можно наблюдать с помощью ОС лучше, чем SQL*DBA-операторами.
Используйте средства ОС для проверки суммарного I/O для ваших дисков.
Старайтесь снизить сложные запросы к дискам,содержащим файлы ОРАКЛа.
Распределение ввода/вывода(I/O).
--------------------------------
Проанализируте статистику на экране SQL*DBA MONITOR FILE I/O и полученную
средствами ОС. Обратитесь к документации, описывающей аппаратные средства,для
определения предельной емкости ваших дисков. Диски, работающие возле уровня
полной загрузки потенциально можно отнести к конфликтным. Например, 40 или
больше I/O в секунду это уже излишне для большинства дисков в VMS или UNIX
операционных системах. Чтобы уменьшить работу на перегруженном диске,
переместите один или болеенаиболее часто используемых файлов в наименее
-- 51 --
активный диск. Используйте этот принцип для каждого из ваших дисков пока они
все не будут иметь одинаковое суммарное количество I/O. Это называется
распределением ввода/вывода.
Этот раздел излагает советы по распределению ввода/вывода:
- Разделите файлы базы данных и файлы журнала регистрации по различным дискам
- Разделите или "stripe" табличные данные на различные диски
- Разделите таблицы и индексы на различные диски
- Уменьшите дисковые I/O неотносящиеся к СУБД ОРАКЛ
Разделение файлов базы данных и файлов журнала регистрации.
-----------------------------------------------------------
ОРАКЛ процессы постоянно обращаются к файлам базы данных файлам журнала
регистрации. Если эти файлы находятся на общих дисках, то это приводит к
дисковым конфликтам.
Расположите каждый файл базы данных на отдельном диске. многие процессы теперь
могут обращаться к различным файлам базы данных одновременно без дисковых
конфликтов.
Расположите все файлы журнала регистрации на отдельном диске. Файлы журнала
регистрации записываются посредством Log Writer Process (LGWR) при транзакции.
Когда LGWR записывает файлы журнала регистрации согласованно, он может писать
намного быстрее,если нет в это время других обращений к этому диску.
Выделение отдельного диска для файлов журнала регистрации обычно обеспечивает
гладкое выполнение LGWR без необходимости дальнейшей настройки. Узкие места в
LGWR случаются редко. Для информации по LGWR обращайтесь к главе 5 "Настройка
конфликтов".
Выделение отдельного диска для файлов журнала регистрации является также важным
средством предосторожности. Это дает уверенность, что одновременн файлы базы
данных и файлы журнала регистрации не будут потеряны при одной аварии.
"Striping" табличных данных.
----------------------------
"Striping" - это способ разделения больших табличных данных на маленькие порции
и запоминаемые в различных файлах базы данных на различных дисках.
Это позволяет различным процессам обращаться к различным частям таблицы
одновременно без дисковых конфликтов. "Striping" особенно полезен при
оптимизацированном случайном доступе к таблицам с большим количеством записей.
Для создания "striped" таблицы:
1.Создайте пространство таблицы оператором CREATE TABLESPACE. Задайте файлы
базы данных в выражении DATAFILE. Каждый файл должен быть на отдельном диске.
CREATE TABLESPACE STRIPEDTABSPACE
DATAFILE 'FILE_ON_DISK_1' SIZE 500K,
'FILE_ON_DISK_2' SIZE 500K,
'FILE_ON_DISK_3' SIZE 500K,
'FILE_ON_DISK_4' SIZE 500K,
'FILE_ON_DISK_5' SIZE 500K
2.Затем создайте таблицу оператором CREATE TABLE. Задайте вновь создаваемое
табличное пространство во фразе TABLESPACE. Задайте также размер табличных
экстентов во фразе STORAGE. Запомните каждый экстент в отдельном файле
-- 52 --
данных.
Табличные экстенты должны быть значительно меньше, чем файлы
данных в пространстве таблиц, позволяя перегрузку. Например:
CREATE TABLE STRIPEDTAB
( COL_1 NUMBER(2),
COL_2 CHAR(10) )
TABLESPACE STRIPEDTABSPACE
STORAGE ( INITIAL 495K NEXT 495K
MINEXTENTS 5 RCTINCREASE 0 )
Результатом этих действий является создание таблицы STRIPEDTAB. Эта таблица
содержит 5 экстентов, каждый размером 495 Кбайт. Каждый экстент занимает один
из файлов, названных во фразе DATAFILE оператора CREATE TABLESPACE. Все эти
файлы находятся на отдельных дисках. Эти эстенты распределяются немедленно,
поскольку MINEXTENTS равно 5. Для дополнительной информации по MINEXTENTS и
другим запоминаемым параметрам обратитесь к разделу "Сегменты и экстенты" в
этой главе.
Разделение таблиц и индексов.
-----------------------------
Размещайте часто запрашиваемые структуры базы данных в разных файлах базы
данных и на разных дисках. Чтобы это сделать, вы должны знать какие структуры
базы данных часто используются. Например, разделяйте часто используемые таблицы
от их индексов. Это разделение распределяет вводы/выводы для таблиц и индексов
по разным дискам. Для разделения таблицы и индекса выполните следующие шаги:
1.Создайте пространство таблицы оператором CREATE TABLESPACE.
Задайте файл базы данных во фразе DATAFILE:
CREATE TABLESPACE TABSPACE_1
DATAFILE 'FILE_ON DISK_1'
2.Создайте таблицу оператором CREATE TABLE. Задайте пространство таблицы во
фразе:
CREATE TABLE TAB_1
( COL_1 NUMBER(2),
COL_2 CHAR(10) )
TABLESPACE TABSPACE_1
3.Создайте другое пространство таблицы. Задайте файл базы данных на другом
диске:
CREATE TABLESPACE TABSPACE_2
DATAFILE 'FILE_ON_DISK_2'
4.Создайте индекс. Задайте новое табличное пространство:
CREATE INDEX IND_1 ON TAB_1 (COL_1)
TABLESPACE TABSPACE_2
Эти шаги приводят к созданию таблицы TAB_1 в файле FILE_ON_DISK_1 и созданию
индекса IND_1 в файле FILE_ON_DISK_2.
Устранение других дисковых вводов/выводов (I/O).
------------------------------------------------
Если возможно, устраните I/O не относящиеся к ОРАКЛу на дисках, содержащих
-- 53 --
ОРАКЛ-файлы. Это вам позволит не только уменьшить конфликты этого диска, но и
позволит контролировать работу на таком диске при помощи SQL*DBA MONITOR FILE
I/O.
РАСПРЕДЕЛЕНИЕ ПРОСТРАНСТВА В БЛОКАХ ДАННЫХ.
------------------------------------------Д
Табличные данные в базе данных хранятся в блоках данных. В этом разделе вы
научитесь распределять пространство внутри блоков данных для наиболее
производительной работы. Ниже обсуждаются следующие вопросы:
- что хранится внутри блоков данных
- как контролировать сохранность данных
- как хранить данные наиболее эффективно для ваших приложений
Формат блока данных.
--------------------
Все блоки данных содержат пространство для:
- общей информации о блоке
- информации о кластерированных таблицах и кластерном ключе, если блок хранит
кластерированные данные
- информации о записях в блоке
- данных актуальной записи
Размер блока базы данных ОРАКЛ задается в байтах INIT.ORA параметром
DB_BLOCK_SIZE. В течение некоторого времени место в блоке, отведенное для
данных актуальной записи, может быть пустым. Это пространство считается
свободным(free space). Для дополнительной информации по формату блока данных
обращайтесь к главе 5 "Объекты пользователя базы данных" руководства
администратора СУБД ОРАКЛ.
Управление пространством блока данных.
--------------------------------------
SQL-операторы INSERT,UPDATE и DELETE могут изменить суммарное пространство в
блоке данных, содержащем данные. Пространство используется когда:
- оператор INSERT добавляет записи к таблице, которая использует этот блок
- оператор UPDATE увеличивает сумму данных, которые уже хранятся в блоке
Пространство освобождается когда:
- оператор DELETE удаляет записи,хранящиеся в блоке
- оператор UPDATE уменьшает сумму данных в записи, которая хранится в блоке
Цепочка блоков.
---------------
Если оператор UPDATE увеличивает сумму данных в записи так, что блок уже не
обеспечивает размещение этих данных, другой блок может быть использован для
хранения оставшихся данных. Это называется сцеплением записей(chaining rows).
Динамическое распределение памяти, особенно сцепление, характерное для работы
СУБД ОРАКЛ, предоставляет вам возможность контроля над пространством,
используемым внутри блоков. Вы можете регулировать использование пространства
так, чтобы было достаточно свободного пространства в каждом блоке для
размешения расширения записей, хранимых в нем.
Свободные списки.
-----------------
Свободный список - это список блоков данных, содержащих свободное пространство.
Свободные списки используются для хранения последовательности блоков, имеющих
достаточно свободного пространства для размещения новых записей. Каждая таблица
должна иметь хотя бы один свободный список. Когда ОРАКЛ процесс вставляет
запись в таблицу, процесс сначала должен найти блок данных со свободным прост-
-- 54 --
ранством для хранения данных. Найдя такой блок, процесс ищет один из свободных
списков таблицы. Количество свободных списков для таблицы определяется
величиной INIT.ORA параметра FREE_LIST_PROC во время создания таблицы.
Блоки данных в свободных списках.
---------------------------------
Следующие два параметра контролируют добавление и удаление блоков данных из
свободных списков и устанавливают пределы суммарного свободного пространства в
блоках данных:
PCTFREE Это процент от емкости блока, зарезервированный для размещения
расширяющихся записей. Если процент от емкости блока, содержащего
свободное пространство, падает ниже PCTFREE, блок удаляется из
свободного списка и новая запись не может быть добавлена в этот
блок. Однако существующие записи могут расширяться. Значение
этого параметра по умолчанию = 10%.
PCTUSED ОРАКЛ будет стараться сохранять этот процент от емкости блока,
содержащий данные. Если этот процент от емкости блока, содержащий
данные, падает ниже PCTUSED, то блок помещается в свободный список
и в этот блок может быть добавлена новая запись. Значение по
умолчанию = 40.
Вы можете определить величины двух параметров PCTFREE и PCTUSED для таблицы,
индекса или кластера во время их создания. Вы также можете определить значение
по умолчанию во время создания пространства таблицы. Сумма этих параметров не
может превышать 100%.
PCTFREE и PCTUSED могут быть определены в Data Definition Language (DDL)
операторах:
- CREATE TABLE
- ALTER TABLE
- CREATE CLUSTER
- ALTER CLUSTER
PCTFREE параметр может быть также использован в операторе CREATE INDEX для
определения величины свободного пространства, остающегося в индексных блоках во
время создания индекса. Это свободное пространство может быть использовано как
для размещения новых индексных значений, так и расширения существующих
индексных данных.
Пример управления пространством блока данных.
---------------------------------------------
Этот пример покажет вам каким образом ОРАКЛ помещает блоки данных в свободный
список и удаляет их оттуда, основываясь на значениях параметров PCTFREE и
PCTUSED. Рассмотрим SQL-оператор, который создает таблицу DEPT:
CREATE TABLE DEPT
( DEPTNO NUMBER(2),
DNAME CHAR(14),
LOG CHAR(13) )
PCTFREE 5 PCTUSED 75
Управление пространством в блоках таблицы DEPT определяется величиной PCTFREE =
5 и PCTUSED = 75. ОРАКЛ резервирует 5% от блока на расширение записей и ста-
рается сохранить блок, заполненным на 75% Один блок может принять новые записи,
если хотя бы 5% от блока свободны. Если какая-то операция заполняет блк более,
чем на 95%, ОРАКЛ удаляет блок из списка свободных блоков. Оставшееся свободное
-- 55 --
пространство может быть заполнено увеличением длины уже хранящихся записей.
Если из блока удаляется достаточное количество данных, либо удалением имеющихся
записей, либо уменьшением суммы данных в записях так, что используется менее
75% от блока, то ОРАКЛ добавляет этот блок в список свободных. В этом случае
блок может принимать новые записи пока свободное пространство не станет меньше
5%.
Выбор пределов для свободного пространства.
-------------------------------------------
Вы можете улучшить работу некоторых операций базы данных, установив команды
управления пространством для ваших блоков данных. Для того, чтобы это сделать,
вы должны быть знакомы с вашими приложениями. Особенно, вы должны знать какие
операции базы данных выполняются наиболее часто над каждой из ваших таблиц.
Выбор PCTFREE.
--------------
Величина параметра влияет на управление пространством для блоков, которые
находятся в свободном списке. Небольшая величина параметра PCTFREE улучшить
выполнение полного сканирования таблицы. Когда таблица загружается с малым
значением этого параметра, табличные данные могут удовлетвориться меньшим
количеством блоков, поскольку ОРАКЛ оставляет меньше свободного пространства в
каждом из блоков. Полное сканнирование таблицы поэтому может читать таблицу,
обращаясь к меньшему количеству блоков. Очень низкое значение PCTFREE может
использоваться для таблиц, которые только запрашиваются и не модифицируются.
Однако это увеличивает вероятность сцепления записей, которые модифицируются.
Большая величина PCTFREE снижает вероятность сцепления записей. Когда таблица
загружается с большим значением этого параметра, то ОРАКЛ оставляет больше
свободного пространства для расширения записей.
Записи могут расширяться, если они содержат поля переменной длины или с
нулевыми значениями.
Оставляя пространство для расширения записей, понижается вероятность сцепления
расширяющихся записей с другими блоками. Однако большое значение этого
параметра увеличивает количество блоков,которые должны быть прочитаны при
полном сканировании таблицы
Выбор PCTUSED.
--------------
Величина PCTUSED влияет на управление пространством для блоков, которые
удаляются из списков свободных.
Низкое значение параметра снижает вероятность сцепления расширяющихся записей
от блока к блоку. Это происходит потому, что ОРАКЛ добавляет блоки обратно в
свободные списки, когда они имеют больше свободного пространства. Это означает,
что блоки в свободном списке должны иметь больше свободного пространства, чтобы
вместить длинные записи.
Большая величина параметра уменьшает суммарное свободное пространство в блоках,
находящихся в свободном списке.Это происходит потому, что ОРАКЛ добавляет блоки
обратно в свободные списки, когда они имеют меньше свободного пространства.
Большая величина параметра позволяет хранить данные более эффективно, используя
свободное пространство, однако, это увеличивает вероятность сцепления длинных
записей. Высокое значение этого параметра также ведет к увеличению частоты,
скоторой блоки добавляются обратно в свободный список. Жесткое управление
свободными списками требует времени выполнения и может снизить эффективность
работы СУБД.
-- 56 --
КАК ИЗБЕЖАТЬ ДИНАМИЧЕСКОГО УПРАВЛЕНИЯ ПРОСТРАНСТВОМ.
----------------------------------------------------
Когда создается объект базы данных, такой как таблица, для данных выделяется
пространство. Это пространство называется сегментом. Если последующие операции
базы данных ведут к увеличению данных и пространства становится недостаточно,
то ОРАКЛ расширяет сегмент. Динамическое расширение может снизить
производительность. Этот раздел обсуждает:
- как распределяются сегменты
- как сегменты расширяются динамически
- как обнаружить динамическое расширение
- как распределить пространство для ваших данных, чтобы избежать динамического
расширения
Сегменты и экстенты.
--------------------
ОРАКЛ хранит в сегментах следующие данные:
Сегменты данных - Сегмент данных хранит все данные для одной таблицы или
кластера
Индексные сегменты - Индексный сегмент хранит все данные для одного индекса
Откатные сегменты - Откатные сегменты хранят информацию, необходимую для
восстановления изменений в базе данных
Временные сегменты - Временные сегменты обеспечивают временное пространство
для ОРАКЛа, чтобы выполнять соответствующие операции базы
данных, например такие,как сортировка
Загрузочный сегмент- Загрузочный сегмент содержит описание таблиц словаря
данных, которые загружаются при старте базы данных
Сегменты разделены на маленькие части, называемые экстентами.
Экстент состоит из непрерывных блоков данных. Количество и размер экстентов в
сегменте определяется посредством запомненных параметров в момент создания
сегмента. Эти параметры следующие:
INITIAL Этот параметр определяет размер первого или начального (initial)
экстента в сегменте. Начальный экстент всегда выделяется при
создании сегмента. Его величина выражается в байтах, значение по
умолчанию 10240 байт. Величина этого параметра округляется по
ближайшему размеру блока ОРАКЛа. Размер блоков ОРАКЛа
определяется INIT.ORA параметром DB_BLOCK_SIZE.
NEXT Этот параметр определяет размер второго и всех последующих
экстентов в сегменте. Значение тоже выражается в байтах. Значение
по умолчанию 10240 байт. Величина этого параметра округляется по
ближайшему размеру ОРАКЛ-блока.
MINEXTENTS Этот параметр определяет минимальное количество экстентов для
сегмента. Эти экстенты выделяются во время создания сегмента.
Значение по умольчанию = 1.
MAXEXTENTS Этот параметр определяет максимальное количество экстентов для
сегмента. Значение по умолчанию = 99.
-- 57 --
PCTINCREASE Этот параметр определяет процент увеличения последующих
экстентов. После второго экстента каждый экстент увеличивается на
величину этого параметра. Значение по умолчанию = 50. Если этот
параметр = 0, то все экстенты после второго имеют размер NEXT.
Вы можете задать величины запоминаемых параметров в выражении STORAGE
SQL-операторов, которые создают или изменяют объекты базы данных:
- таблицы
- кластеры
- индексы
- откатные сегменты
Например, рассмотрите CREATE TABLE-оператор:
CREATE TABLE ACCOUNTS
( ACC_NUM NUMBER,
BALANCE NUMBER(11,2) )
STORAGE ( INITIAL 100K NEXT 50K
MINEXTENT 1 MAXEXTENTS 50
PCTINCREASE 5 )
Этот оператор создает таблицу ACCOUNTS с начальным экстентом в 100 кбайт, т.е.
значение параметра INITIAL равно 100 кбайт. Размер второго экстента может быть
50, если необходимо, т.е. значение параметра NEXT. Чтобы рассчитать размер
третьего экстента, увеличьте размер второго экстента на 5%,величина
PCTINCREASE. Рассчитанный размер для 3 экстента = 52,5 кбайт. Чтобы получить
действительный размер 3 экстента, округлите этот размер до ближайшего размера
блока ОРАКЛа.
Сохраняемые значения параметров могут также быть определены во фразе DEFAULT
STORAGE следующих DDL-операторов:
- CREATE TABLESPACE
- ALTER TABLESPACE
Например, рассмотрим оператор CREATE TABLESPACE:
CREATE TABLESPACE TABSPACE_2
DATAFILE 'TABSPACE_FILE2.DAT' SIZE 20M
DEFAULT STORAGE ( INITIAL 10K NEXT 50K
MINEXTENTS 1 MAXEXTENTS 999
PCTINCREASE 10 )
ONLINE
Величина, определенная во фразе DEFAULT STORAGE является определением для
сохраняемых параметров сегментов, созданных в пространстве таблиц. Если вы
создаете таблицу в пространстве TABSPACE_2 без использования фразы STORAGE,
сохраняемые параметры табличного сегмента будут определены величинами во фразе
DEFAULT STORAGE оператора CREATE TABLESPACE.
Расширение сегмента.
--------------------
ОРАКЛ выделяет сегменты и экстенты во время создания соответствующих объектов
базы данных. Например, когда выполняется оператор CREATE TABLE, ОРАКЛ выделяет
табличный сегмент и ОРАКЛ также выделяет минимальное количество экстентов для
сегмента, определяемое параметром MINEXTENTS. Когда вы загружаете данные в эту
таблицу, данные заполняют эти экстенты.
-- 58 --
Если суммарные данные в таблице превышают размер первого MINEXTENTS, ОРАКЛ
динамически создает еще экстенты, основываясь на величинах сохраняемых
параметров. Этот процесс называется расширением. Динамическое расширение может
снизить производительность. Исходя из этого следует исключать излишнее
динамическое расширение.
Выявление динамического расширения.
-----------------------------------
Динамическое расширение заставляет ОРАКЛ выполнять SQL-операторы в дополнение к
SQL-операторам, выполняемым процессом пользователя. Эти SQL-операторы известны
как рекурсивные вызовы потому, что ОРАКЛ вызывает сам себя.
Рекурсивные вызовы генерируются при "cache miss" словаря данных.
Количество рекурсивных вызовов, выполняемых ОРАКЛом, отражается статистикой
рекурсивных вызовов. Наблюдать эту статистику на дисплее можно при помощи
оператора SQL*DBA MONITOR STATISTICS USER. Рис.4-2 показывает этот экран.
Чтобы получить экран выполните SQL*DBA команду: SQLDBA> MONITOR STATISTICS USER
На рис.4-2 вы можете видеть, что количество рекурсивных вызовов = 0
Рис.4-2
Ъ------------------------------------------------------------------ї
і і
і ORACLE PID: 0 Session 0 User Name: SYSTEM STATISTICS і
і Statistic Name CUR AUG MAX MIN TOT і
і -------------------- ----- ------ ------ ----- ----- і
і logons 2 null null null 020 і
і current logons 1 null null null 80 і
і cumulative opened cu 10 null null null 5020 і
і current open cursors 9 null null null 945 і
і user commits 0.71 0.71 0.71 0.71 5 і
і user rollbacks 0.00 0.00 0.00 0.00 5 і
і user calls 24.00 24.00 24.00 24.00 174 і
і recursive calls 0.00 0.00 0.00 0.00 0 і
і mesages sent 0.71 0.71 0.71 0.71 5 і
і mesages recieved 0.71 0.71 0.71 0.71 5 і
і background timeouts 0.29 0.29 0.29 0.29 2 і
А------------------------------------------------------------------Щ
ОРАКЛ часто делает рекурсивные вызовы вскоре после старта системы из-за
"cache miss" словаря данных. Поэтому вам следует наблюдать рекурсивные вызовы
только после полного завершения старта системы. Если ОРАКЛ продолжает делать
рекурсивные вызовы после старта, то нужно убедиться не являются ли они
следствием "cache miss" словаря данных. Для полной информации по КЭШу словаря
данных обратитесь к главе 3"Настройка распределения памяти".
Если вы определили, что излишние рекурсивные вызовы не вызваны "cache miss"
словаря данных, то эти рекурсивные вызовы могут быть следствием динамического
расширения. В этом случае следует уменьшить динамическое расширение, выделив
больше экстентов.
Выделение экстентов.
--------------------
Выполните следующие шаги, чтобы избежать динамического расширения:
1.Определите максимальный размер вашего объекта базы данных. Для определения
по формуле сколько выделить пространства для таблицы обратитесь к главе 16
"Управление пространством" Руководства администратора базы данных СУБД
ОРАКЛ.
-- 59 --
2.Выберите величины сохраняемых параметров так, чтобы ОРАКЛ выделил
достаточное количество экстентов для размещения всех ваших данных во время
создания объекта базы данных. Большое количество экстентов приведет к
выигрышу в производительности по следующим причинам:
- Поскольку блоки в одном экстенте расположены непрерывно, один большой
экстент более непрерывен, чем много маленьких экстентов. ОРАКЛ может
прочитать один большой экстент с диска за одно многоблочное чтение
- Маловероятно, что сегменты с большими экстентами будут расширяться.
Однако, поскольку большие экстенты требуют больше смежных блоков, ОРАКЛ
с трудом может найти достаточное количество смежных свободных блоков для
сохранения информации.
ГЛАВА 5. НАСТРОЙКА КОНФЛИКТОВ.
--------------------Д
Эта глава представляет четвертый шаг настроечного процесса: настройку
конфликтов. Конфликты возникают когда много процессов пытаются запросить один и
тотже ресурс одновременно. Конфликты заставляют процессы ждать доступа. ОРАКЛ
представляет вам методы избавления от конфликтов. В этой главе вы научитесь:
- как обнаружить конфликты, которые могут влиять на производительность
- как снизить конфликты
Ресурсы ОРАКЛа, обсуждаемые в этой главе, включают:
- откатные сегменты
- защелки буфера журнала регистрации изменений
СНИЖЕНИЕ КОНФЛИКТОВ ДЛЯ ОТКАТНЫХ СЕГМЕНТОВ.
------------------------------------------Д
В этом разделе обсуждаются следующие вопросы:
- Что такое откатный сегмент
- Как обнаружить конфликты для откатных сегментов
- Как создать откатные сегменты
- Как изменить размеры откатных сегментов
Что такое откатный сегмент?
---------------------------
Откатный сегмент - это выделенное пространство в базе данных, которое содержит
информацию, необходимую для восстановления или возврата изменений, выполненных
транзакцией. Откатный сегмент содержит откатные элементы. Один откатный элемент
содержит информацию, необходимую для возврата изменений, сделанных транзакцией.
Откатные сегменты используются для:
- отката транзакции
- чтения содержимого
- восстановления
Каждой транзакции, выполняемой СУБД ОРАКЛ, соответствует откатный элемент,
записываемый в откатный сегмент. Блоки базы данных, содержащие откатные
сегменты, часто запрашиваются. Поэтому откатные сегменты могут быть объектом
конфликта.
Обнаружение конфликта откатного сегмента.
-----------------------------------------
Конфликты откатных сегментов отображаются через конфликты буферов, содержащих
блоки откатных сегментов. Выполните следующие действия для того, чтобы опреде-
лить, снижают ли конфликты откатных сегментов производительность вашей СУБД:
-- 60 --
1.Проверьте наличие конфликтов для КЭШа буферов в SGA.
2.Определите является ли конфликт буфера следствием конфликта откатного
сегмента.
Анализ конфликтов буферов.
---------------------------
Для обнаружения конфликта откатного сегмента вам следует сначала анализировать
конфликты для всех буферов в КЭШе. ОРАКЛ собирает статистику, отображающую эти
конфликты:
consistent gets, Сумма этих двух статистик есть общее
db block gets количество запросов для буферов.
buffer busy waits Значение этой статистики равно количеству запросов для
буферов, результатом которых было ожидание.
Эту статистику можно получить на дисплее при помощи SQL*DBA MONITOR
STATISTICS CACHE. Чтобы наблюдать эту статистику, выполните команду:
SQLDBA> MONITOR STATISTICS CACHE
Информация выдается на два экрана рис.5-1 и 5-2. Эти рисунки показывают вид
этих экранов. На рис.5-1 вы можете видеть, что первый экран содержит статистику
consistent gets, db block gets и buffer busy waits.
Исследуйте эту статистику во время выполнения вашего приложения. Найдите
отношение величины consistent gets и db buffer gets. Это отношение представляет
процент запросов к буферу, результатом которых было ожидание.Если оно не более
10-15%,то производительность не снизится.
Если это отношение более, чем 10-1:%, то буферные конфликты могут влиять на
работу системы. В этом случае вам следует определить какой тип блока является
объектом конфликтов, запросив таблицу V$WAITSTAT, как это описано в следующем
разделе.
Рис.5-1 (Экран 1).SQL*DBA MONITOR STATISTICS CACHE
Ъ------------------------------------------------------------------ї
і ORACLE Statistics Moniyor і
і ORACLE PID: 0 Session : 0 User Name: SYSTEM TATISTICS і
і Statistic Name CUR AUG MAX MIN TOT і
і -------------------- ------ ------- ------- ------- ------- і
і db block gets 38.46 38.46 38.46 38.46 500 і
і consistent gets 95.31 95.31 95.31 95.31 1239 і
і physical reads 41.15 41.15 41.15 41.15 535 і
і physical writes 9.15 9.15 9.15 9.15 119 і
і db block changes 29.38 29.38 29.38 29.38 382 і
і change write time 0.00 0.00 0.00 0.00 0 і
і consistent changes 2.77 2.77 2.77 2.77 36 і
і write complete waits 0.23 0.23 0.23 0.23 3 і
і write wait time 0.00 0.00 0.00 0.00 0 і
і buffer busy waits 0.00 0.00 0.00 0.00 0 і
і busy wait time 0.00 0.00 0.00 0.00 0 і
і redo synch writes 0.69 0.69 0.69 0.69 9 і
і redo synch time 0.00 0.00 0.00 0.00 0 і
і DEUR exchange waits 0.00 0.00 0.00 0.00 0 і
і exchange deadlocks 0.00 0.00 0.00 0.00 0 і
і free buffer requests 45.31 45.31 45.31 45.31 589 і
-- 61 --
і free buffer scans 45.31 45.31 45.31 45.31 589 і
і free buffer inspecte 859.85 859.85 859.85 859.85 11178 і
і free buffer waits 2.38 2.38 2.38 2.38 31 і
і free wait time 0.00 0.00 0.00 0.00 0 і
А------------------------------------------------------------------Щ
Рис.5-2 (Экран 2). SQL*DBA MONITOR STATISTICS CACHE
Ъ------------------------------------------------------------------ї
і ORACLE Statistics Monitor і
і ORACLE PID: 0 Session : 0 User Name: SYSTEM STATISTICS і
і Statistic Name CUR AUG MAX MIN TOT і
і --------------------- ------ ------- ------- ------- ------- і
і ...continued (page 2) і
і dbwr timeouts 0.00 0.00 0.00 0.00 0 і
і dbwr free needed 0.00 0.00 0.00 0.00 0 і
і dbwr free lou 0.54 0.54 0.54 0.54 7 і
і dbwr buffers scanned 10.77 10.77 10.77 10.77 140 і
і dbwr checkpoints 0.00 0.00 0.00 0.00 0 і
і consistent forceouts 0.00 0.00 0.00 0.00 0 і
А------------------------------------------------------------------Щ
Динамическое выполнение V$WAITSTAT таблицы.
-------------------------------------------
Статистика блоковых конфликтов хранится в динамически выполняемой таблице
SYS.V$WAITSTAT. Эта таблица отображает блочные конфликты, возникшие после
последнего старта базы данных. Поля этой таблицы следующие:
OPERATION Это поле определяет тип операции, вызвавшей
конфликт. Значения этого поля следующие:
buffer busy waits Записи с этим значение означают конфликт буферов
consistent lock gets, Записи с этим значением могут быть только
current lock gets для многоэкземплярного ОРАКЛа
CLASS Это поле определяет класс конфликтных
блоковых объектов
Значения этого поля следующие:
undo segment header Записи с этим значением означают конфликт для буферов,
содержащих головные блоки откатного сегмента
undo block Записи с этим значением означают конфликт для буферов,
содержащих неголовные блоки откатного сегмента
data block Записи с этим значение означают конфликт для буферов,
содержащих блоки данных
segment header, Записи с этими значениями не используются
save undo header, при настройке
save undo block,
sort block
RANGE Это поле определяет диапазон времени ожидания. Значения
этого поля выражаются в миллисекундах. Они могут быть:
0 - 30
30 - 100
100 - 500
-- 62 --
500 - 1000
1000 - 2000
2000 - 4000
> 4000
COUNT Значение этого поля равно числу ожиданий для определен
ного значения поля OPERATION, для пределенного значения
поля CLASS и для определенного значения поля RANGE
TIME Значение этого поля есть сумма всех времен ожидания для
всех ожиданий в полях OPERATION CLASS и RANGE
Запрос таблицы V$WAITSTAT.
--------------------------
Чтобы лучше понять какого класса блоки, являющиеся объектом конфликта,
группируте записи таблицы V$WAITSTAT по полю CLASS. Можно определить суммарное
количество ожиданий для каждого CLASSа блоков при запросе:
SELECT CLASS, SUM(COUNT) TOTAL_WAITS
FROM SYS.V$WAITSTAT
WHERE OPERATION = 'buffer busy waits'
AND CLASS IN ('undo segment header', 'undo block', 'data block'
GROUP BY CLASS
Результат этого запроса может выглядеть так:
CLASS TOTAL WAITS
----------------------------------Д
undo segment header 1235
undo block 942
data block 5
где: CLASS класс конфликтных блоков
TOTAL WAITS суммарное время ожидания для определенного класса блоков
Анализ этого примера позволяет сделать следующие замечания:
- Было всего 1235 ожиданий для буферов, содержащих головные блоки откатных
сегментов
- Было всего 942 ожидания для буферов, содержащих неголовные блоки откатных
сегментов
- Было всего 5 ожиданий для буферов, содержащих блоки данных
Из этого примера видно, что самая большая часть конфликтов относится к буферам,
содержащим блоки откатных сегментов. Относительно малая часть конфликтов
относится к буферам, содержащим блоки данных.
Снижение конфликтов для буферов.
--------------------------------
Чтобы снизить конфликты буферов, следует снизить конфликты для CLASSа блоков с
наибольшим значением TOTAL WAITS:
- Поскольку наибольшие конфликты наблюдаются для откатных
сегментов, снизьте конфликты, создав больше откатных сегментов
- Если наибольшие конфликты будут для буферов, содержащих данные,
то обратитесь к главе 6"Дополнительные замечания по настройке".
-- 63 --
Создание откатных сегментов.
----------------------------
Далее следуют некоторые общие рекомендации для выбора количества откатных
сегментов, основываясь на количестве транзакций, выполняемых вашей СУБД
одновременно. Эти рекомендации подходят для большинства прикладных наборов:
Количество обновременных Рекомендуемое количество откатных
транзакций сегментов
----------------------------------------------------------------
менее 16 4 сегмента
от 16 до 32 8 сегментов
более 32 n/4, но не более 50
Для создания откатных сегментов используйте оператор CREATE ROLLBACK SEGMENT.
Для дополнительной информации обратитесь к справочному руководству по SQL
языку.
Выбор размеров откатных сегментов.
----------------------------------
Размер ваших откатных сегментов может влиять на производительность. Размер
откатного сегмента определяется запоминаемыми в операторе CREATE ROLLBACK
SEGMENT параметрами.
Ваш откатный сегмент должен быть достаточно большим, чтобы содержать откат для
вашей транзакции. Убедитесь, что все ваши откатные сегменты того же размера.
Создание одного большого откатного сегмента не гарантирует, что он не потребует
расширения. Поскольку транзакции назначаются на откатные сегменты случайным
образом, вы не можете быть уверены, что определенная большая транзакция будет
назначена на большой откатный сегмент, а не на маленький.
Для длинных запросов и длинныых транзакций.
-------------------------------------------
Некоторые приложения выполняют длинные запросы с данными, которые одновременно
модифицируются другими транзакциями. Такие запросы могут потребовать доступ к
откатным сегментам для восстановления старого значения модифицированных данных.
Эти откатные сегменты должны быть достаточно большими, чтобы вмещать все
откатные сегменты для данных во время исполнения запроса. Большие откатные
сегменты могут также улучшить работу одной транзакции, которая модифицирует
большое суммарное количество данных. Такие транзакции требуют большие откатные
сегменты. Если откатный элемент не входит в откатный сегмент, ОРАКЛ расширяет
сегмент. Динамическое расширение снижает производительность и его следует
избегать, когда это возможно.
Для OLTP приложений.
--------------------
Некоторые приложения выполняют "online transaction processing" или OLTP. Такие
приложения называт OLTP приложения. Они характеризуются частыми одновременно
выполняемыми транзакциями так, что каждая из них модифицирует малую сумму
данных. Если ваши приложения выполняют только OLTP без длинных запросов и
длинных транзакций, вы можете улучшить работу, создав много маленьких откатных
сегментов. Может быть полезно иметь такое же количество откатных сегментов,
сколько имеется одновременно выполняемых транзакций. При этом каждая транзакция
будет обращаться к отдельному откатному сегменту без риска конфликта.
Маленькие откатные сегменты желательно оставлять храниться в КЭШе буферов, где
доступ к ним более быстрый. Типчный OLTP откатный сегмент может иметь 2
экстента, каждый размером порядка 10 кбайт.
-- 64 --
СНИЖЕНИЕ КОНФЛИКТОВ ДЛЯ ЗАЩЕЛОК БУФЕРА ЖУРНАЛА РЕГИСТРАЦИИ ИЗМЕНЕНИЙ
--------------------------------------------------------------------Д
Конфликты доступа для буфера журнала регистрации изменений редко снижают
производительность базы данных. Однако, ОРАКЛ предоставляет вам методы для
наблюдения и снижения некоторых конфликтов, которые случаются. Этот раздел
объясняет:
- что такое буфер журнала регистрации
- каковы функции защелки буфера журнала регистрации изменений
- как обнаружить конфликты для защелок
- как снизить конфликты для защелок
Буфер журнала регистрации изменений.
------------------------------------
Буфер журнала регистрации изменений это круговой буфер в SGA, который содержит
информацию об изменениях, сделанных в базе данных. Эта информация хранится в
redo-элементах. Redo-элементы содержат информацию для реконструкции или обра-
ботки изменений, производимых над базой данных операторами языка манипулиро-
вания (DML-Data Manipulation Language) INSERT,UPDATE или DELETE или операторами
языка описания данных (DDL) CREATE,ALTER,DROP.
Redo-элементы используются для восстановления базы данных.
Redo-элементы копируются ОРАКЛ-пользовательскими процессами из пространства
памяти пользователей в буфер журнала регистрации изменений в SGA. Redo-элементы
занимают непрерывное последовательное пространство в буфере.
Процесс записи журнала (LGWR).
------------------------------
Буфер журнала регистрации изменений записывается в файл журнала регистрации
изменений (redo log file) на диск посредством LGWR процесса (Log Writer
process), т.е. основным процессом ОРАКЛа, ответственным за управление буфером
журнала регистрации измепнений. LGWR процесс записывает все redo-элементы,
которые были скопированы в буфер с момента его последнего копирования в файл.
LGWR записывает непрерывную порцию буфера на диск. LGWR записывает:
- когда процесс пользователя совершает транзакцию
- когда буфер журнала регистрации изменений полон на треть
- когда DBWR процесс пишет измененные буферы на диск
Пространство в буфере журнала регистрации изменений.
----------------------------------------------------
Когда LGWR записывает redo-элементы из буфера журнала регистрации изменений
(redo log буфер) в файл журнала регистрации изменений (redo log файл), процесс
пользователя может затем копировать любой элемент из элементов, записанных на
диск. LDWR обычно пишет достаточно быстро так, чтобы пространство в буфере было
доступно для новых элементов, даже когда доступ к журналу затруднен.
Статистика запросов к журналу регистрации изменений (redo log space requests)
отражает время, которое процесс пользователя ожидает доступа к redo log буферу.
Эту статистику можно наблюдать на экране: SQL*DBA MONITOR STATISTICS REDO.На
рис.5-3 показан вид этого экрана. Изображение можно получить, выполнив команду:
SQLDBA> MONITOR STATISTICS REDO
Величина redo log space requests должна быть всегда равна нулю.
Ненулевое значение показывает, что процессы ожидают пространство в буфере. В
этом случае увеличьте размер redo log буффера. Этот размер определяется
INIT.ORA параметром LOG_BUFFER. Это значение выражается в байтах.
-- 65 --
Рис.5-3.
Ъ------------------------------------------------------------------ї
і ORACLE Statistics Monitor і
і ORACLE PID: 0 Session : 0 User Name: SYSTEM STATISTICS і
і Statistic Name CUR AUG MAX MIN TOT і
і --------------------- ------ ------- ------- ------- ------- і
і redo entries 11.33 11.33 11.33 11.33 68 і
і redo size 2283.67 2283.67 2283.67 2283.67 13702 і
і redo entries lineari 0.00 0.00 0.00 0.00 0 і
і redo buffer allocati 0.00 0.00 0.00 0.00 0 і
і redo small copies 11.17 11.17 11.17 11.17 67 і
і redo wastage 155.17 155.17 155.17 155.17 931 і
і redo writer latching 0.00 0.00 0.00 0.00 0 і
і redo writers 0.50 0.50 0.50 0.50 3 і
і redo block written 5.17 5.17 5.17 5.17 31 і
і redo write time 0.00 0.00 0.00 0.00 0 і
і redo log switch wait 0.00 0.00 0.00 0.00 0 і
і redo chunk allocatio 0.00 0.00 0.00 0.00 0 і
і redo log space reque 0.00 0.00 0.00 0.00 0 і
і redo log space wait 0.00 0.00 0.00 0.00 0 і
і redo log switch into 0.00 0.00 0.00 0.00 0 і
і і
А------------------------------------------------------------------Щ
Защелки буфера журнала регистрации изменений.
---------------------------------------------
Доступ к redo log буферу регулируется защелками. Два типа защелок контролируют
доступ к redo log буферу:
- защелки распределения изменений
- защелки копирования изменений
Защелка распределения изменений.
--------------------------------
Защелка распределения изменений контролирует распределение пространства для
redo-элементов в redo log буфере.Чтобы распределить пространство в буфере,
пользовательский процесс ОРАКЛа должен получить защелку распределения измене-
ний. Поскольку имеется одна такая защелка, только один пользовательский процесс
может распределить пространство в буфере в данный момент времени. Одна защелка
распределения по--ерживает последовательный характер элементов в буфере. После
выделения пространства для redo-элемента, процесс пользователя может копировать
в буфер только пока он обладает защелка распределения изменений. Такое копи-
рование относят к копированию по "защелке распределения изменений". Процесс
может выполнять такое копирование, если redo -элемент меньше порогового значе-
ния. После такого копирования процесс пользователя освобождает защелку.
Максимальный размер redo-элемента который может копироваться по защелке расп-
ределения задается INIT.ORA параметром LOG_SMALL_ENTRY_MAX_SIZE. Значение
параметра выражается в байтах. Значение по умолчанию зависит от вашей
операционной системы.
Защелки копирования.
--------------------
Если redo-элемент слишком велик для копирования по защелке распределения,
процесс пользователя должен получить защелку копировыания перед копированием
элемента в буфер. Пока процесс обладает защелкой копирования, он копирует
redo-элемент в выделенное для него простанство в буфере, а затем освобождает
защелку вопирования.
-- 66 --
Если ваш компьютер имеет много CPU, ваш redo log буфер может иметь много
защелок копирования. Наличие нескольких защелок копирования позволяет
нескольким процессам копировать элементы в redo log буфер одновременно.
Количество защелок копирования определяется INIT.ORA параметром
LOG_SIMULTANEOUS_COPIES. Значение его по умолчанию равно значению INIT.ORA
параметра CPU_COUNT.
ОРАКЛ автоматически устанавливает значение CPU_COUNT по количеству CPU, дос-
тупных для ваших элементов. На однопроцессорном компьютере не должно быть
защелок копирования, поскольку активным может быть только один из процессов в
любой момент времени. В этом случае redo-элементы копируются по защелке рас-
пределения независимо от размеров. ОРАКЛ устанавливает значение CPU_COUNT = 0.
Проверка работы журнала регистрации изменений.
----------------------------------------------
Трудности доступа к буферу журнала регистрации изменений могут привести к
конфликтам для защелок буфера. Эти конфликты могут снизить производительность.
ОРАКЛ собирает статистику по работе для всех защелок. Эту статистику можно
наблюдать на SQL*DBA MONITOR LATCH экране. Изображение можно получить, выполнив
команду:
SQLDBA> MONITOR LATCH.
На рис.5-4 показан вид этого экрана.
Исследуйте статистику для защелок распределения и копирования.
Обратите внимание на статистику для Willing to Wait Requests:
Total Значение этой статистики равно суммарной величине количества
запросов к защелке
Timeouts Величина этой статистики равна числу таймаутов во время
ожидания защелки. Таймаут является результатом безуспешного
запроса к защелке. Семмарное время ожидания и количество
запросов до таймаута завист от вашей операционной системы.
Если отношение Timeouts к Total для определенной защелки превышает пороговое
значение на 10-15%, то конфликты этой защелки могут влиять на производитель-
ность. В этом случае следует снизить конфликты для этой защелки. Порог
конфликтов подходит для большинства операционных сиситем, однако некоторые
компьютеры со многими CPU, могут допустить больше конфликтов без снижения
производительности. Обратитесь к "Руководству по установке и использованию" для
дополнительной информации, специфичной для вашей операционной системы.
Рис.5-4.
Ъ------------------------------------------------------------------ї
і ORACLE Latch Monitor і
і Holder--Willing-to-Wait-Requests--No-Wait-Requests-і
іLatch Name PID Total Timeouts Immediates Total Succersesі
і--------------------- ------ -------- ---------- ----- ---------і
іprocess allocation 659 48 646 0 0 і
іsession allocation 23789 24 23767 0 0 і
іmessages 53462 369 53110 0 0 і
іenqueues 61833 178 61665 0 0 і
іcache buffers chains 1000926 787 1000259 112506 112477 і
іcache buffers Iru ch 88730 773 88019 354631 552109 і
іcache buffer handles 348 1 347 0 0 і
іmultiblock read ob je 10904 0 10984 0 0 і
іinter-instans buffe 0 0 0 0 0 і
іsystem commit number 56510 33 56470 0 0 і
-- 67 --
іarchive control 0 0 0 0 0 і
іredo allocation 55567 519 54660 0 0 і
іredo copy 0 0 0 21547 21547 і
іdml/ddl allocation 19255 13 19243 0 0 і
іtransaction allocati 6597 1 6596 0 0 і
іundo global data 6277 0 6277 0 0 і
іsequence cache 1585 4 1581 0 0 і
іrow cache objects 128948 633 128641 0 0 і
А------------------------------------------------------------------Щ
Снижение конфликтов для защелок.
--------------------------------
Большинство таких конфликтов случается, когда два или более процессов пытаются
получить одну и ту же защелку. Такие конфликты редко случаются на
однопроцессорных компьютерах, когда может быть только один активный процесс.
Снижение конфликтов для защелки распределения.
----------------------------------------------
Для снижения конфликтов для такой защелки вам следует минимизировать время, в
течение которого один процесс обладает защелкой. Для снижения этого времени
следует уменьшить копирования по защелке распределения. Уменьшив величину
INIT.ORA параметра LOG_SMALL_ENTRY_ MAX_SIZE, вы снизите количество и размер
redo-элементов, копируемых по защелке распределения.
Снижение конфликтов для защелок копирования.
--------------------------------------------
На многопроцессорных компьютерах многочисленные защелки копирования позволяют
многочисленным процессам копировать элементы в redo log буффер одновременно.
Значением INIT.ORA параметра LOG_SIMULTANEOUS _COPIES по умолчанию является
величиеа INIT.ORA параметра CPU_COUNT. ОРАКЛ автоматически устанавливает
значение CPU_COUNT равным количеству CPU, доступных вашему ОРАКЛу. На
однопроцессорных компьютерах ОРАКЛ устанавливает значение CPU_COUNT = 0.
Если вы обнаружите конфликты для защелок копирования, добавьте еще защелки. Для
этого следует увеличить LOG_SIMULTANEOUS_COPIES. Может помочь создание вдвое
большего количества защелок копирования по отношению к количеству CPU,
доступных вашему ОРАКЛу.
Другим способом снижения конфликтов для защелок копирования является снижение
времени, в течение которого каждый процесс обладает защелкой. Это мремя можно
снизить перестройкой (pre-building) элементов перед получением защелки
копирования. Redo-элемент может состоять из многих частей. Обычно каждая часть
копируется отдельно из памяти пользовательского процесса в redo log буфер пока
процесс обладает защелкой копирования. Копирование частей по-отдельности
требует многих обращений к памяти. Однако, когда элемент перестроен, процесс
собирает все части вместе до запроса защелки. Redo-элемент может быть затем
скопирован в буфер за одно обращение к памяти.
Процессы перестраивают все элементы, которые меньше порогового размера.
Этот пороговый размер определяется INIT.ORA параметром
LOG_ENTRY_PREBUILDING_THRESHOLD. Величина этого параметра выражается в байтах.
Значение по умолчанию равно 0. Это означает, что элементы не перестраиваются.
Для активизации процесса перестройки redo-элементов увеличьте
LOG_ENTRY_PREBUILDING_ THRESHOLD параметр.
НАЗНАЧЕНИЕ ВСЕМ ОРАКЛ-ПРОЦЕССАМ РАВНОГО ПРИОРИТЕТА.
--------------------------------------------------Д
-- 68 --
В работу СУБД ОРАКЛ вовлечено много процессов. Эти процессы требуют разделения
ресурсов памяти в SGA.
Убедитесь, что все ОРАКЛ-процессы имеют одинаковый приоритет. Во время
инсталляции ОРАКЛа все фоновые процессы получили приоритеты по умолчанию, как
для операционной системы. Не следует менять их приоритеты. Следует убедиться,
что все пользовательские процессы имеют тот же самый приоритет.
Назначение разных приоритетов ОРАКЛ-процессам может вызвать конфликты. Ваша
операционная система может не выделить времени процессора для процесса с низким
приоритетом, если процесс с высоким приоритетом требует времени в это время.
Если высокоприоритетный процесс требует доступа к ресурсам памяти, занятым
низкоприоритетным процессом, то он может ждать бесконечно, пока
низкоприоритетный процесс получит CPU и освободит ресурс.
ГЛАВА 6.
НННННННН
ДОПОЛНИТЕЛЬНЫЕ ЗАМЕЧАНИЯ ПО НАСТРОЙКЕ.
--------------------------------------
В этой главе обсуждаются дополнительные настроечные меры, которые
следует предпринять после завершения шагов, представленных в первых
пяти главах этого руководства.
Эти меры позволят настроить очень специфические операции СУБД ОРАКЛ.
Кроме того, эти меры могут быть важными, если эти операции снижают
производительность. Эта глава включает следующие темы:
- Сортировки
- Свободные списки
- Контрольные точки
НАСТРОЙКА СОРТИРОВОК.
--------------------Д
Некоторые приложения требуют, чтобы ОРАКЛ сортировал данные. Этот
раздел расскажет вам:
- когда ОРАКЛ сортирует данные
- какая память требуется для сортировки
- как распределить память, чтобы оптимизировать ваши сортировки
- как избежать сортировки, создавая индексы
Причины сортировок.
-------------------
Следующие SQL-операторы заставляют ОРАКЛ сортировать данные:
- SQL-операторы, которые создают индексы
- SQL-операторы, которые имеют выражения GROUP BY, ORDER BY
- SQL-операторы, которые используют оператор DISTINCT
- SQL-операторы, которые выполняют объединения
- SQL-операторы, которые используют UNION,INTERSECT или MINUS set-операторы
Области сортировки.
-------------------
Сортировки требуют пространства в памяти. Участки памяти, в которых ОРАКЛ
сортирует данные, известны как области сортировок(sort areas). Область
сортировки существует в памяти процесса пользователя ОРАКЛа, который требует
сортировку. Объем памяти для сортировки определяется INIT.ORA параметром
SORT_AREA_SIZE. Значение этого параметра выражается в байтах. Если суммарные
данные, которые сортируются, не умещаются в выделенной области сортировки,
данные разделяются на малые части, способные уместиться в эту область. Каждая
-- 69 --
часть затем сортируется отдельно. Отдельно сортируемая часть известна как
"run". После сортировки всех run ОРАКЛ объединяет их, чтобы получить
окончательный результат. После сортировки run ОРАКЛ запоминает его во временном
сегменте на диске пока сортируется следующий run. По умолчанию временные
сегменты создаются в пространстве таблицы SYSTEM. Другие пространства таблицы
могут быть определены по умолчанию с помощью фразы TEMPORARY TABLESPACE
оператора ALTER USER. Например:
ALTER USER KING
IDENTIFIED BY ARTHUR
TEMPORARY TABLESPACE CAMELOT
INIT.ORA параметр SORT_SPACEMAP_SIZE определяет как ОРАКЛ управляет картой
пространства для промежуточных run. Оракл автоматически устанавливает этот
параметр. Не следует его менять.
Распределение памяти для областей сортировок.
---------------------------------------------
Определение размера области сортировки должно соответствовать содержимому всех
данных для большинства сортировок. Однако, если ваше приложение часто выполняет
большие сортировки данных, которые не соответствуют размеру области сортировки,
возможно вы захотите увеличить размер области сортировки. Большие сортировки
могут случиться при создании больших индексов или при SQL-операторах с
выражением GROUP BY, которые обрабатывают большое количество записей.
Обнаружение больших сортировок.
-------------------------------
Вы можете определить не является ли ваша область сортировки слишком маленькой.
Используйте оператор ALTER USER для определения временного табличного
пространства для пользовательского процесса, выполняющего сортировку. Затем
наблюдайте дисковые I/O для этого табличного пространства в течение сортировки.
Дисковые I/O вы можете наблюдать при помощи SQL*DBA MONITOR FILE I/O экрана.
Для получения изображения выполните SQL*DBA команду:
SQLDBA> MONITOR FILE
Увеличение размера области сортировки.
--------------------------------------
Если вводы/выводы для временного табличного пространства чрезмерны в течение
сортировки, значит производительность вашего приложения может выиграть от
увеличения размеров области сортировки. В этом случае увеличьте значение
INIT.ORA параметра SORT_AREA_SIZE.
Улучшение выполнения от увеличения области сортировки.
------------------------------------------------------
Увеличение размера области сортировки увеличивает размер каждого run и уменьша
ет количество run. Это уменьшение может улучшить выполнение двумя путями:
- Снижение суммарного количества run уменьшает количество объединений, которые
ОРАКЛ должен выполнять, чтобы получить суммарный отсортированный результат.
- Снижение суммарного количества run снижает количество дисковых I/O ко
временным сегментам, необходимых для выполнения сортировок.
Потери производительности при больших сортировочных областях.
-------------------------------------------------------------
Увеличение размера области сортировки заставляет каждый ОРАКЛ процесс,
выполняющий сортировки, выделять больше памяти. Это увеличение уменьшает
суммарную память, доступную для контекстных областей. Это может также
-- 70 --
воздействовать на распределение памяти для операционной системы и может вызвать
пэйджинг и свопинг. Перед увеличением размера области сортировки убедитесь, что
достаточно свободной памяти доступно для вашей операционной системы.
Как избежать сортировок.
------------------------
Один из видов сортировок - это создание индексов. Создание индекса для таблицы
вызывает сортировку всех записей в таблице на основе значений индексного поля
или полей. ОРАКЛ позволяет вам создать индексы без сортировки. Если записи в
таблице загружаются в возрастающем порядке, вы можете создать индекс быстрее
без сортировки.
Опция NOSORT.
-------------
Чтобы создать индекс без сортировки, загружайте записи в таблицу в возрастающем
порядке значений индексного поля. Ваша оперпционная система может предоставить
вам утилиту сортировки для сортировки записей перед их загрузкой. Когда вы
создадите индекс, используйте опцию NOSORT в операторе CREATE INDEX. Например,
CREATE INDEX оператор создает индекс EMP_INDEX по полю ENAME таблицы EMP без
сортировки записей:
CREATE INDEX EMP_INDEX ON EMP(ENAME) NOSORT
Когда использовать опцию NOSORT.
--------------------------------
Пресортировка ваших данных и загрузка их в порядке не всегда является
быстрейшим способом их загрузки. Если вы имеете многопроцессорный компьютер, вы
имеете возможность загружать данные быстрее, используя много процессоров
параллельно, каждый процессор загружает разные порции данных. Чтобы извлечь
пользу от параллельного выполнения, загружайте данные без предварительной
сортировки. Затем создайте индекс без опции NOSORT. С другой стороны если у вас
однопроцессорный компьютер, вам, по-возможности, следует сортировать данные
перед загрузкой. Затем вам следует создать индекс с опцией NOSORT.
СНИЖЕНИЕ КОНФЛИКТОВ СВОБОДНЫХ СПИСКОВ.
--------------------------------------
Конфликты свободных списков могут снизить выполнение некоторых приложений. Этот
раздел расскажет вам:
- что такое свободные списки
- как обнаружить конфликты свободных списков
- как увеличить количество свободных списков
Свободные списки.
-----------------
Свободный список - это список блоков данных, которые содержат свободное
пространство. Свободные списки используются для хранения адресов блоков данных,
которые имеют достаточно свободного пространства для размещени новых записей.
Каждая таблица имеет один или больше свободных списков. Количество свободных
списков определяется INIT.ORA параметром FREE_LIST_PROC во время создания
таблицы. Значение этого параметра по умолчанию = 4. Когда ОРАКЛ процесс
вставляет запись в таблицу, он должен сначала найти блок данных со свободным
пространством. Чтобы найти такой блок, процесс ищет один из табличных свободных
списков.
-- 71 --
Конфликты для свободных списков могут возникнуть когда несколько ОРАКЛ
процессов одновременно вставляют запись в одну и ту же таблицу. Каждый процесс
должен получить свободный список. Если свободных списков меньше, чем процессов,
некоторые из процессов будут ожидать свободный список.
Обнаружение конфликтов свободных списков.
-----------------------------------------
Конфликты свободных списков отображаются через конфликты блоков данных в КЭШ
буфере. Выполните следующие шаги, чтобы определить снижают ли конфликты
свободных списков производительность СУБД.
1. Исследуйте конфликты буферов в КЭШ буфере SGA.
2. Определите являются ли буферные конфликты следствием конфликтов
свободных списков.
Анализ буферных конфликтов.
---------------------------
Для обнаружения конфликтов свободных списков вам следует вначале исследовать
конфликты для блоков в КЭШ-буфере. ОРАКЛ собирает такую статистику:
cosistent gets, Сумма этих двух статистик равна общему числу
db block gets запросов к блокам данных.
buffer busy waits Величина этой статистики равна количеству запросов к
буферам, которые закончились ожиданием.
Эту статистику можно получить при помощи SQL*DBA MONITOR STATISTICS CACHE
экрана. Для этого нужно выполнить SQL*DBA команду:
SQLDBA> MONITOR STATISTICS CACHE
Эта статистика выдает два экрана. На рис.6-1 и 6-2 показан вид этих
экранов. На рис.6-1 видно, что первый экран содержит статистику:
consistent gets, db block gets, buffer busy waits.
Анализируйте эту статистику во время выполнения вашего приложения. Найдите
отношение buffer busy waits к сумме consistent gets и db block gets. Это
отношение равно проценту запросов к буферу, которые закончились ожиданием. Если
это отношение не более 10-15%, то конфликты для буферов, содержащих эти
конфликтные блоки не снижают производительность. Если это отношение более 15%,
то конфликты уменьшают производительность и следует определить какой тип блоков
является объектом конфликтов.
Рис.6-1 (Экран 1).SQL*DBA MONITOR STATISTICS CACHE
Ъ------------------------------------------------------------------ї
і ORACLE Statistics Moniyor і
і ORACLE PID: 0 Session : 0 User Name: SYSTEM TATISTICS і
і Statistic Name CUR AUG MAX MIN TOT і
і -------------------- ------ ------- ------- ------- ------- і
і db block gets 38.46 38.46 38.46 38.46 500 і
і consistent gets 95.31 95.31 95.31 95.31 1239 і
і physical reads 41.15 41.15 41.15 41.15 535 і
і physical writes 9.15 9.15 9.15 9.15 119 і
і db block changes 29.38 29.38 29.38 29.38 382 і
і change write time 0.00 0.00 0.00 0.00 0 і
і consistent changes 2.77 2.77 2.77 2.77 36 і
і write complete waits 0.23 0.23 0.23 0.23 3 і
і write wait time 0.00 0.00 0.00 0.00 0 і
і buffer busy waits 0.00 0.00 0.00 0.00 0 і
-- 72 --
і busy wait time 0.00 0.00 0.00 0.00 0 і
і redo synch writes 0.69 0.69 0.69 0.69 9 і
і redo synch time 0.00 0.00 0.00 0.00 0 і
і DEUR exchange waits 0.00 0.00 0.00 0.00 0 і
і exchange deadlocks 0.00 0.00 0.00 0.00 0 і
і free buffer requests 45.31 45.31 45.31 45.31 589 і
і free buffer scans 45.31 45.31 45.31 45.31 589 і
і free buffer inspecte 859.85 859.85 859.85 859.85 11178 і
і free buffer waits 2.38 2.38 2.38 2.38 31 і
і free wait time 0.00 0.00 0.00 0.00 0 і
А------------------------------------------------------------------Щ
Рис.6-2 (Экран 2). SQL*DBA MONITOR STATISTICS CACHE
Ъ------------------------------------------------------------------ї
і ORACLE Statistics Monitor і
і ORACLE PID: 0 Session : 0 User Name: SYSTEM STATISTICS і
і Statistic Name CUR AUG MAX MIN TOT і
і --------------------- ------ ------- ------- ------- ------- і
і ...continued (page 2) і
і dbwr timeouts 0.00 0.00 0.00 0.00 0 і
і dbwr free needed 0.00 0.00 0.00 0.00 0 і
і dbwr free lou 0.54 0.54 0.54 0.54 7 і
і dbwr buffers scanned 10.77 10.77 10.77 10.77 140 і
і dbwr checkpoints 0.00 0.00 0.00 0.00 0 і
і consistent forceouts 0.00 0.00 0.00 0.00 0 і
А------------------------------------------------------------------Щ
Таблица V$WAITSTAT.
-------------------
ОРАКЛ собирает статистику для каждого типа блоков, объектов конфликтов. Эта
статистика хранится в динамически заполняемой таблице SYS.V$WAITSTAT. У этой
таблицы следующие поля:
OPERATION Это поле определяет тип операции, вызвавшей конфликт.
CLASS Это поле определяет класс блока, объекта конфликта.
COUNT Величина этого поля является количеством ожиданий для класса
блока, заданного в поле CLASS. Это количество накапливается с
момента старта системы.
Запрос таблицы V$WAITSTAT.
--------------------------
Чтобы лучше узнать какой класс блоков является объектом наибольших конфликтов,
группируйте записи в таблице по полю CLASS. Можно будет определить суммарное
количество ожиданий для каждого класса блоков при запросе:
SELECT CLASS, SUM(COUNT) TOTAL_WAITS
FROM SYS.V$WATSTAT
WHERE OPERATION = 'buffer bust waits'
AND CLASS IN ('data block, 'undo segment header' 'undo block')
GROUP BY CLASS
Результат этого запроса может выглядеть так:
CLASS TOTAL_WAITS
------------------------------------
-- 73 --
data block 755
undo block 10
undo segment header 8
Где:
CLASS - класс блоков объектов конфликтов
TOTAL - общее число ожиданий для определенного класса блоков
Из этого примера можно сделать следующие выводы:
- Было всего 755 ожиданий для буферов, содержащих блоки данных
- Было 10 ожиданий для буферов, содержащих головные блоки откатных сегментов
- Было всего 8 ожиданий для буферов, содержащих неголовные блоки откатных
сегментов
В этом примере относительно большая часть конфликтов относится к буферам,
содержащим блоки данных.
Снижение буферных конфликтов.
-----------------------------
Для снижения конфликтов, отражаемых buffer busy waits статистикой, снизьте
конфликты для класса блоков с наибольшим суммарным значением TOTAL WAITS:
- Если большинство конфликтов для буферов, содержащих блоки данных, как это
было в рассмотренном примере, снизьте конфликты, увеличив число свободных
списков.
- Если большинство конфликтов относятся к буферам, содержащим какой-либо тип
откатных сегментов, обратитесь к главе 5 "Настройка конфликтов".
Увеличение числа свободных списков.
-----------------------------------
Для уменьшения конфликтов свободных списков выполните следующие шаги:
1. Прекратите работу ОРАКЛа.
2. Увеличьте значение INIT.ORA параметра FREE_LIST_PROC до количества ОРАКЛ
процессов, которые одновременно обращаются к базе данных, но не более 32
3. Стартуйте ОРАКЛ вновь.
4. Создайте снова таблицу, свободные списки которой были объектом конфликтов.
Пересоздание может просто означать уменьшение ее. Однако вы можете захотеть
пересоздать таблицу, выбирая данные из нее в новую таблицу, уменьшая старую
таблицу и дав новое имя новой таблице. Новая таблица будет иметь столько
свободных списков, сколько задано INIT.ORA параметром FREE_LIST_PROC.
НАСТРОЙКА КОНТРОЛЬНЫХ ТОЧЕК.
----------------------------
Контрольная точка(КТ) - это операция, выполняемая СУБД ОРАКЛ автоматически. КТ
могут в определенные моменты снижать производительность. Этот раздел расскажет
вам:
- почему ОРАКЛ выполняет контрольные точки
- когда ОРАКЛ выполняет контрольные точки
- как ОРАКЛ выполняет контрольные точки
- как контрольные точки влияют на выполнение
- как изменить частоту контрольных точек
- как выбрать частоту контрольных точек
-- 74 --
Назначение контрольных точек (КТ).
----------------------------------
КТ служат следующим целям:
- устанавливают момент времени, с которого возможна "прокрутка
вперед" для восстановления данных в случае аварии ОРАКЛа
- разрешают повторно использовать или архивировать заполненный файл
журнала регистрации изменений
Для восстановления.
-------------------
Например, если в вашем компьютере авария по питанию, большинство данных может
быть найдено в файлах базы данных на диске. Однако, некоторые, подвергавшиеся
изменениям в КЭШе буферов, блоки могут не быть записаны в файл базы данных при
аварии. Совершенные изменения в этих блоках защищаются redo-элементами в redo
log файле на диске. Вы можете восстановить данные вплоть до момента аварии,
записанные в redo-элементах. Этот процесс называется "прокрутка вперед"(rolling
forward). КТ дают уверенность, что все измененные блоки будут восстановлены,
т.е. устанавливают момент, с которого ОРАКЛ может "прокрутить вперед".
Обслуживание журнала регистрации изменений.
-------------------------------------------
КТ также позволяют архивировать и использовать повторно redo log файлы. ОРАКЛ
требет по крайней мере два файла журнала регистрации изменений (redo log
файла). LGWR процесс пишет все redo-элементы последовательно в один rdo log
файл, пока он не будет полон. Затем LGWR процесс продолжает запись изменений в
другой redo log файл. Момент времени, когда один файл заполнлся и процесс
начинает писать вдругой файл , называется переключатель журнала (log switch).
КТ всегда имеет место в момент переключения. Эта КТ гарантирует, что все изме
нения, защищенные предыдущим redo log файлом, записаны в файлы базы данных и
эти redo-элементы больше не нужны. Предыдущий файл может затем быть использован
вновь, либо архивирован. Для дополнительной информации по архивированию
обратитесь к главе 15 Руководства администратора базы данных ОРАКЛ.
Когда ставятся контрольные точки.
---------------------------------
Контрольные точки выполняются при следующих обстоятельствах:
- когда redo log файл заполнен
- когда LGWR процесс записал определенное количество блоков с момента
предыдущей КТ
КТ всегда имеют место при переключениях, как описано ранее. КТ могут также
выполняться между переклбчениями. КТ выполняется когда LGWR процесс записал
определенное количество блоков с момента предыдущей КТ.
Количество блоков, записанных между КТ, называется checkpoint interval. Он
задается INIT.ORA параметром LOG_CHECKPOINT_INTERVAL. Величина этого параметра
выражается в блоках операционной системы. Например, если ваш redo log файл
имеет 5000 блоков, а значение log checkpoint interval = 2000 блоков, ОРАКЛ
выполняет три КТ для каждого redo log файла. Первая КТ выполняется когда LGWR
записывает 2000 блоков в файл. Вторая КТ выполняется когда LGWR записывает
следующие 2000 блоков. Третья КТ выполняется когда LGWR записывает 1000 блоков,
заполняя файл и выполняя переключение (log switch).
Как ОРАКЛ выполняет контрольную точку.
--------------------------------------
Когда выполняется КТ, LGWR создает список блоков, которые подвергались
-- 75 --
изменениям с момента предыдущей КТ в КЭШе буферов, но не были записаны в файлы
базы данных. Процесс записи базы данных (DBWR-процесс) затем пишет эти блоки в
файлы базы данных. Когда DBWR заканчивает запись, КТ завершена.
Как контрольные точки влияют на производительность.
---------------------------------------------------
Контрольные точки влияют на:
- время выполнения восстановления
- время выполнения задачи
Время выполнения восстановления.
--------------------------------
Частые КТ могут снизить время восстановления после аварии. Если интервал КТ
мал, тогда в интервале между КТ могут быть сделаны относительно небольшие
изменения базы данных. В этом случае относительно небольшие изменения могут
быть "прокручены вперед" для восстановления.
Время выполнения задачи.
------------------------
Поскольку КТ используют DBWR для выполнения I/O, КТ могут снизить на короткое
время производительность системы. Перегрузка, связанная с КТ, невелика и
снижает производительность только во время выполнения ОРАКЛом контрольных
точек.
Изменение частоты контрольных точек.
------------------------------------
Вы можете изменить частоту КТ в вашей СУБД, изменяя интервал КТ. Увеличение
интервала КТ снижает частоту КТ. Чтобы изменить интервал КТ, измените величину
INIT.ORA параметра LOG_CHECKPOINT_INTERVAL.
Поскольку КТ при переключении (log switch) необходима для работы журнала
регистрации изменений (redo log), вы не можете совсем убрать КТ. Однако
количество КТ может быть уменьшено до минимума установкой значения
LOG_CHECKPOINT_INTERVAL больше величины наибольшего размера вашего redo log
файла. Такая установка убирает все КТ, исключая те, что возникают по
переключателю буферов redo log файла.
Вы можете еще больше уменьшить количество КТ, снизив частоту переключателей
буферов. Чтобы уменьшить количество переключателей, увеличьте размер ваших redo
log файлов, чтобы они не заполнялись слишком быстро.
Выбор частоты контрольных точек.
--------------------------------
Вам следует выбрать частоту КТ для вашей СУБД, основываясь на особенностях
вашей работы. Если для вас наиболее важно время решения вашего приложения, чем
время восстановления, выберите низкую частоту КТ. В противном случае выберите
высокую частоту КТ.
|