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

не используются связываемые переменные, работа приложения замедляется. Там мы видели, что блок кода без связываем1х переменных выполняется 15 секунд. Тот же код, но написанный с использованием связываемой переменной выполняется за 1,5 секунды. Здесь я продемонстрирую последствия неиспользования связываемых переменных в многопользовательской среде. Уже понятно, что без связываемых переменных код работает медленнее; теперь давайте оценим, как их отсутствие повлияет на масштабируемость.

Для этого теста я буду использовать следующие таблицы. Обратите внимание: для выполнения этого примера необходим доступ к представлению V$SESSION EVENT, т.е. наличие привилегии SELECT для представления V$SESSION EVENT. Кроме того, необходимо установить параметр системы (SYSTEM) или сеанса (SESSION) TIMED STATISTICS, чтобы получать осмысленные результаты (иначе время выполнения каждого оператора будет равно нулю). Это можно сделать с помощью оператора ALTER SESSION SET TIMED STATISTICS=TRUE. Начнем с создания глобальной временной таблицы SESS EVENT, которая будет использоваться сеансом для хранения предыдущих значений событий, наступления которых ожидал сеанс. Эта таблица SESSEVENT будет использоваться для определения ожидаемых сеансами событий, количества ожиданий и времени ожидания в сотых долях секунды.

tkyte@TKYTE816> create global temporary table sess event

2 on commit preserve rows

3 as

4 select * from v$session event where 1=0; Table created.

Теперь создадим прикладную таблицу для тестирования:

tkyte@TKYTE816> create table t

2 (c1 int, c2 int, c3 int, c4 int)

3 storage (freelists 10); Table created

Я хочу проверить, что будет происходить при одновременной вставке строк в эту таблицу несколькими пользователями. В главе 6 было показано, как может повлиять наличие нескольких списков свободных мест (freelists) на одновременную вставку, поэтому соответствующая установка уже включена в оператор создания таблицы. Теперь определим, наступления каких событий будет ожидать наше приложение . Для этого сделаем копию набора текущих ожидаемых событий сеанса, выполним блок кода, который необходимо проанализировать, а затем вычислим продолжительность ожиданий, имевших место при выполнении этого блока кода:

tkyte@TKYTE816> truncate table sess event; Table truncated.

tkyte@TKYTE816> insert into sess event 2 select * from v$session event

4 where sid = (select sid from v$mystat where rownum = 1) ; 3 rows created.

530 Глава 10

tkyte@TKYTE816> declare

10 11 12 13 14 15 16

l number number;

begin

for i in 1 . loop

l number

10000

dbms random.random;

execute immediate

insert into t values

( If l number , l number , l number ,

l number )

end loop; commit;

end;

PL/SQL procedure successfully completed tkyte@TKYTE816> select a.event.

2 3 4 5 6 7 8 9 10

EVENT

(a.total waits-nvl(b.total waits,0)) total waits, (a.time waited-nvl(b.time waited,O)) time waited

from (select *

from v$session event where sid = (select sid from v$mystat where rownum = 1)) a, sess event b where a.event = b.event(+)

and (a.total waits-nvl(b.total waits,0)) > 0

TOTAL WAITS

TIME WAITED

SQL*Net message from client SQL*Net message to client log file sync

14 0 2

В этом небольшом тесте мы создаем уникальн1й оператор INSERT, который будет выглядеть примерно так:

insert into t values (12323, 12323, 12323, 12323); insert into t values (632425, 632425, 632425, 632425);

Представленные выше результаты получены в однопользовательском режиме. Если выполнить это одновременно в двух сеансах, увидим примерно такой отчет о времени ожидания:

EVENT

TOTAL WAITS

TIME WAITED

SQL*Net message SQL*Net message enqueue latch free log file sync

from client to client

4 5 2

142 2

18 0 0

235 2

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

Как видите, сеанс много раз ждал освобождения защелки (причем суммарное время ожидания - достаточно большое). Кроме того, наблюдалось ожидание следующих событий:

SQL*Net message irom client. Сервер ждал, пока клиент пошлет ему сообщение.

В данном случае клиент - SQL*Plus. В большинстве случаев ожидание этого события можно игнорировать, но если при выполнении приложения предполагаются длительные раздумья пользователя, это число неизбежно будет большим. В нашем случае сеанс SQL*Plus постоянно в]давал операторы на сервер, поэтому время ожидания должно быть небольшим. Если бы оно было большим, проблема была бы связана с клиентом (узким местом был бы клиент, неспособный достаточно часто обращаться к базе данных).

SQL*Net message to client. Сколько времени потребовалось на передачу сообщений с сервера клиенту (SQL*Plus).

Enqueue. Ожидание той или иной блокировки.

Log file sync. Время ожидания сброса буфера журнала повторного выполнения на диск процессом LGWR при фиксации.

Все события, которых может ожидать сервер, описаны в руководстве Oracle8i ReferenceManual вприложении Oracle WaitEvents .Вэтомруководствесодержатся подробные описания всех событий, которые можно увидеть в представлении V$SESSION EVENT.

На ожидание события освобождения защелки в данном случае надо обратить внимание. Эта защелка предотвращала одновременный доступ к разделяемой области SQL. Я предполагал это ожидание с учетом характеристик выполнявшейся транзакции. Другие запросы к представлениям V$ могут подтвердить это (далее мы рассмотрим представления V$ более детально). Поскольку теперь два сеанса выполняют жесткий разбор (анализируют запрос, никогда ранее не обрабатывавшийся), появляются конфликты доступа к разделяемой области SQL. Двум сеансам надо изменить общую структуру данных, и делать это они могут только поочередно. В следующей таблице показано количество ожиданий освобождения защелки для 1, 2, 3, 4 и 5 сеансов, одновременно выполняющих представленную выше транзакцию:

Учтите, что в таблице представлена информация для одного сеанса: каждому сеансу пришлось ждать столько раз и такое суммарное количество времени. В случае двух пользователей ждать пришлось три секунды, трех - около 18, четырех - около 40 и т.д. В какой-то момент при добавлении дополнительных пользователей ожидать мы будем