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

ивать работу процесса LGWR. Чтобы уменьшить время ожидания можно использовать более быстрые диски, генерировать меньше информации повторного выполнения, снизить конфликты доступа к дискам, содержащим журналы, и т.д. Найти причину ожидания - одно дело, устранить ее - совсем другое. В Oracle измеряется время ожидания более 200 событий, причем ни для одного из них нет простого способа сократить время ожидания.

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

Следующий раздел отчета:

Wait Events for DB: ORA8I Instance: ora8i Snaps: -> cs - centisecond - 100th of a second -> ms - millisecond - 1000th of a second

1 -3

-> ordered by wait tine desc, waits desc

(idle events last) Avg

Глава 10

показывает все ожидания событий клиентами, произошедшие за рассматриваемый период. Кроме информации, представленной в разделе Тор 5, показано среднее время ожидания в тысячных долях секунды, а также, сколько раз транзакция ожидала этого события. Это помогает найти существенные события. Обращаю ваше внимание, что в этом разделе множество событий надо игнорировать. Например, ожидание события SQL*Net message from client можно игнорировать в тех системах, где клиенту необходимо время на размышление. Это время, в течение которого клиент не обращался к базе данных с запросами (с другой стороны, если подобные ожидания происходят при загрузке данных, значит, клиент недостаточно быстро передает данные, и это уже проблема). В нашем случае, однако, это ожидание означает, что клиент был подключен, но не делал никаких запросов. В заголовке раздела сказано, что записи ожиданий событий, связанные с простоями, приведены в конце. Все события, начиная с SQL*Net message from client и ниже, связаны с простоями: процесс ждал, пока к нему обратятся. В большинстве случаев все эти ожидания можно игнорировать.

Представленный выше раздел отчета StatsPack показывает ожидания событий фоновыми процессами (DBWR, LGWR и т.д.). И в этом разделе записи для событий, связанных с простоями, приведены в конце, и тоже, в общем случае, могут быть проигнорированы. Раздел пригодится при настройке экземпляра в целом, чтобы понять, чего именно ждут фоновые процессы. Что именно замедляет работу сеанса, определить несложно - мы уже многократно делали это в примерах, посвященных использованию связываемых переменных, и в других разделах: достаточно выполнить запрос к представлению V$SESSION EVENT. Этот фрагмент отчета показывает, каких событий ожидают фоновые процессы, во многом аналогично тому, как ожидания представлены для отдельных сеансов.

SQL ordered by Gets for DB: ORA8I Instance: ora8i Snaps: 1 -3 -> End Buffer Gets Threshold: 10000

-> Note that resources reported for PL/SQL includes the resources used by all SQL statements called within the PL/SQL code. As individual SQL statements are also reported, it is possible and valid for the summed total % to exceed 100

Buffer Gets

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

Executions Gets per Exec % Total Hash Value

713,388 1

BEGIN sys.sync usera.do it; END;

713,388.0

56.2

1907729738

485,161 1 485,161.0 38.3 1989876028

SELECT DECODE (SA. GRANTEE# , 1, PUBLIC , U1.NAME) GRANTEE , U2.NAME GRANTED ROLE , DECODE (OPTION$ , 1, YES , NO) ADMIN OPTION FRO M SYSAUTH$@ORACLE8.WORLD SA,DEFROLE$@ORACLE8.WORLD UD,USER$@ORAC LE8. WORLD Ul ,USER$@ORACLE8.WORLD U2 WHERE SA.GRANTEE# = UD.USER # (+) AND SA.PRIVILEGE# = UD.ROLE# (+) AND U1.USER* = SA.G

239,778 2

BEGIN statspack.snap(lO); END;

119,889.0

18.9

617705294

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

В нашем случае первой указана PL/SQL-процедура sync users.do it. Она затрагивает более 700000 блоков при каждом выполнении. Хорошо это или плохо, по данному фрагменту отчета не понятно. Здесь представлены только факты - никаких оценок. Я знаю, что syncusers - большое фоновое задание, синхронизирующее словари данных двух баз и гарантирующее, что пользователь, созданный в одной базе данных, создается и в другой, а также что совпадают все роли и пароли пользователей. Вполне понятно, что она обрабатывает большой объем информации. Как оказалось, именно это задание и ждало поступления информации из удаленной базы данных (это ожидание мы обнаружили ранее).

SQL ordered by Reads for DB: ORA8I Instance: -> End Disk Reads Threshold: 1000

Physical Reads Executions Reads per Exec

8,484 1 8,484.0

BEGIN sys.sync users.do it; END;

2,810 2 1,405.0

BEGIN statspack.snap(lO); END;

oxa8i Snaps: 1 -3

% Total Hash Value

73.0 1907729738

24.2

617705294

Этот раздел очень похож на предыдущий, но вместо логического ввода/вывода он информирует о физическом вводе/выводе. В нем показаны SQL-операторы, наиболее активно физически читающие данные. Именно на эти запросы и процессы надо обратить внимание, если система не справляется с объемом ввода/вывода. Процедуру sync users, видимо, надо настроить - она является основным потребителем ресурсов дисковой подсистемы.