Стратегии и средства настройки

что в точности соответствует значению параметра Soft Parse %, представленного в начале отчета. Эти точные данные использовались для вычисления многих представленных ранее показателей.

Tablespace IO Stats for DB: ORA8I Instance: ora8i Snaps: 1 -3

->ordered by IOs (Reads + Writes) desc

Tablespace

Av Av Av Av Buffer Av Buf

Reads Reads/s Rd(ms) Blks/Rd Writes Writes/s Waits Wt(ms)

TEMP

1,221

File 10 Stats for DB: ORA8I Instance: ora8i Snaps: 1 -3 ->ordered by Tablespace, File

Tablespace

Filename

Av Av Av Av

Reads Reads/s Rd(ms) Blks/Rd Writes Writes/s

Buffer Av Buf Waits Wt(ms)

DRSYS

0 7.9

/d02/oradata/ora8i/drsys01.dbf

2.4 0 0

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

Buffer Pool Statistics for DB: ORA8I Instance: -> Pools D: default pool, K: keep pool, R:

ora8i Snaps:

recycle pool

Buffer Gets

Consistent Gets

Free Write

Physical Physical

Reads Writes

Buffer

Buffer Complete

Waits Waits

1 -3

Busy

Waits

D 9,183 721,865 7,586 118 0 0 0

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

Rollback Segment Stats for DB: ORA8I Instance: ora8i Snaps: 1 -3

->A high value for Pet Waits suggests more rollback segments may be required

RBS No

Trans Table Gets

Pet Waits

Undo Bytes Written

Wraps

Shrinks Extends

5.0 866.0

0.00 0.00

447,312

Глава 10

Rollback Segment Storage for DB: ORA8I Instance: ->Optimal Size should be larger than Avg Active

ora8i Snaps: 1 -3

RBS No

Segment Size Avg Active Optimal Size Maximum Size

663,552 26,206,208 26,206,208

7,372 526,774 649,805

663,552 26,206,208 26,206,208

В этом разделе представлена информация об использовании сегментов отката. В этом случае также имеет смысл добиваться равномерного распределения нагрузки по сегментам отката (за исключением, конечно, сегмента отката в табличном пространстве SYSTEM). Кроме того, в заголовке раздела представлены наиболее существенные соображения, которые необходимо учитывать при анализе этой информации. Обратите внимание на совет, что значение Optimal должно быть больше, чем Avg Active, если установка оптимального размера сегментов отката вообще используется (представленный отчет показывает, что в этой базе данных оптимальный размер сегментов отката не задан). Поскольку определение размера сегментов отката и распределение ввода/вывода по ним - это задача администратора базы данных, мы переходим к следующему разделу:

Latch Activity for DB: ORA8I Instance: ora8i Snaps: 1 -3

-> Get Requests , Pet Get Miss and Avg Sips/Miss are statistics for

willing-to-wait latch get requests

-> NoWait Requests , Pet NoWait Miss are for no-wait latch get requests -> Pct Misses for both should be very close to 0.0

Pct Avg Pct

Get Get Slps NoWait NoWait

Latch Name Requests Miss /Miss Requests Miss

Active checkpoint queue latch

virtual circuit queues

Latch Sleep breakdown for DB: 0RA8I Instance: ora8i Snaps: 1 -3 -> ordered by misses desc

Latch Name

Get Spin &

Requests Misses Sleeps Sleeps l->4

library cache 202,907 82

cache buffers chains 2,082,767 26

12 72/8/2/0/0 1 25/1/0/0/0

Latch Miss Sources for DB: ORA8I Instance: ora8i Snaps: 1 -3 -> only latches with sleeps are shown -> ordered by name, sleeps desc

Latch Name Where

cache buffers chains kclbgtcr: kslbegin

NoWait Waiter

Misses Sleeps Sleeps

Стратегии и средства настройки

library cache library cache library cache

kglic 0 7

kglhdgn: child: 0 3

kglget: child: KGLDSBYD 0 2

Child Latch Statistics DB: 0RA8I Instance: -> only latches with sleeps are shown -> ordered by name, gets desc

ora8i Snaps: 1 -3

Latch Name

Child Num

Requests

Hisses Sleeps

Spin & Sleeps l->4

12/1/0/0/0

Как было описано в главе 3, защелки - это простые средства обеспечения последовательного доступа в СУБД Oracle. Защелка всегда либо устанавливается, либо нет, в отличие от очередей, где не имеющий возможности установить блокировку процесс засыпает , пока блокировка не будет снята другим процессом. При использовании защелки запрашивающий процесс сразу определяет, установлена она или нет. Если защелка не установлена, запрашивающий процесс некоторое время крутится (используя ресурсы процессора), пытаясь установить защелку еще раз. Если не получается, он засыпает на некоторое время и пытается установить ее еще раз. В представленных выше отчетах отражена информация об этих действиях. Например, видно, что защелку библиотечного кэша не удалось установить 82 раза из 202907 попыток. Далее, 72 из этих 82 защелок б1ли успешно установлены при следующей попытке, 8 - при второй и 2 - при третей. Показатель установки с первой попытки в системе был близок к 100 процентам (почти 100 процентов устанавливавшихся защелок были успешно установлены сразу же), так что тут проблем нет. В системе, не использующей связываемые переменные или слишком часто разбирающей запросы, вы увидите многочисленные конфликты при установке защелок в библиотечном кэше. Еще по этому фрагменту отчета можно понять, что около 4,5 процентов (93800/2082767) запросов защелки на цепочки кэш-буферов приходилось на одну дочернюю защелку из 930. Это, вероятно, означает, что в системе имеется горячий блок, к которому одновременно пытается обратиться несколько процессов. Им всем нужна защелка, чтобы обратиться к этому блоку, и это приводит к конфликтам. С этой проблемой надо разобраться. Отчет о защелках помогает найти подобные конфликты. Для их снятия придется вернуться к настройке на уровне приложений. Конфликты при установке защелок - это симптом, а не причина проблемы.