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

Имя стандартного табличного пространства для пользователя PERFSTAT, который будет создан.

Имя временного табличного пространства для этого пользователя.

В каком табличном пространстве создавать объекты StatsPack. Этот параметр не запрашивается в версии 8.1.7 - только в 8.1.6. В данном табличном пространстве должно быть свободное место для примерно 60 экстентов (так что реальный размер будет зависеть от стандартного размера экстента).

Сценарий будет запрашивать эту информацию в ходе выполнения. Если при вводе сделана ошибка или установка была прервана по ходу, надо с помощью сценариев spdrop.sql (8.1.7 и далее) или statsdrp.sql (8.1.6 и ранее) удалить пользователя и все уже установленные представления, прежде чем снова устанавливать StatsPack. При установке StatsPack будет создано три файла с расширением .lis (их имена выдаются на экран в ходе установки). Просмотрите эти файлы и убедитесь, что при установке не было ошибок. Все должно устанавливаться без проблем, если были указаны подходящие имена табличных пространств (и нет пользователя PERFSTAT).

Теперь, после установки StatsPack, осталось собрать хотя бы два набора данных. Самый простой способ сделать это - с помощью пакета STATSPACK, принадлежащего пользователю PERFSTAT:

pertat@DEV2.THINK.COM> exec statspack.snap

PL/SQL procedure successfully completed.

Теперь надо подождать некоторое время, дав системе поработать, и сделать еще один моментальный снимок. При наличии данных за два момента времени, создать отчет тоже просто. Для этого надо выполнить сценарий statsrep.sql (8.1.6) или spreport.sql (8.1.7). Это сценарий для утилиты SQL*Plus, который надо выполнять от имени пользователя PERFSTAT (по умолчанию его пароль - PERFSTAT, но его надо изменить сразу же после установки!). Формат отчета несколько изменился при переходе с версии 8.1.6 на 8.1.7, причем формат версии 8.1.7 мне нравится больше; его мы и рассмотрим. Для создания отчета достаточно выполнить команду:

perfstat@ORA8I.WORLD> @spreport

DB Id DB Name

4080044148 ORA8I

Inst Num Instance 1 ora8i

Completed Snapshots Instance DB Name

ora8i ORA8I

Snap

Id Snap Started

1 18 Mar 2001 12:44

2 18 Mar 2001 12:47

Snap

Level Comment

10 10

Specify the Begin and End Snapshot Ids Enter value for begin snap:

Глава 10

Выдается список моментов времени, для которых собрана информация, и предлагается выбрать два из них для сравнения. Затем будет сгенерировано стандартное имя отчета и предложено принять его или задать новое. После этого генерируется отчет. Ниже представлен отчет StatsPack версии 8.1.7, по разделам, с комментариями о том, на что обращать внимание и как интерпретировать результаты.

STATSPACK report for DB Name DB Id

Instance Inst Num Release

Host

ORA8I 4080044148 ora8i

Snap Id

1 8.1.6.2.0 NO aria Snap Time Sessions

Begin Snap: End Snap: Elapsed:

Cache Sizes

db block buffers: db block size:

18-Mar-01 12:44:41 18-Mar-01 12:57:23

12.70 (mins)

16384 log buffer:

8192 shared pool size:

22 22

512000 102400000

Первая часть отчета носит справочный характер. Здесь показано, по какой базе данных был создан отчет, в частности имя и идентификатор базы данных. В вашей среде они должны быть уникальными. В поле Instance указан идентификатор SID для базы данных. Эти три параметра помогут разобраться, по какой именно базе данных был сгенерирован отчет. Одной из проблем в старых отчетах BSTAT/ESTAT было то, что они не включали никакой идентификационной информации. Неоднократно я получал отчет для анализа, а потом оказывалось, что он делался не на том сервере, где возникла проблема. Теперь такое не случится. Далее идет информация о моментах времени сбора данных и интервале между этими моментами. Для многих странно, что эти интервалы не обязательно должны быть большими - представленный выше отчет покрывает период продолжительностью 13 минут. Важно лишь, чтобы в этот период шла обычная работа с базой данных. Отчет StatsPack для периода продолжительностью 15 минут не менее показателен, чем для периода в один или несколько часов. Чем больше охватываемый период, тем сложнее прийти к определенным выводам по полученным числовым данным. Завершается этот раздел общей информацией о конфигурации сервера. Можно узнать параметры основных компонентов области SGA:

Load Profile

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

Sorts: 2.95 6.64

Logons: 0.14 0.32

Executes: 30.23 67.95

Transactions: 0.44

В этом разделе компактно представлен большой объем информации. Можно увидеть, какой объем данн1х повторного выполнения (REDO) генерировался в среднем за секунду и за транзакцию (в данном случае генерировалось от 5 до 6 Кбайт информации повторного выполнения в секунду). Средняя транзакция генерировала около 13 Кбайт данных повторного выполнения. Следующий блок информации связан с логическим и физическим вводом/выводом. Показано, что около 1 процента логических считываний потребовали чтения физического - это очень хорошо. Также показано, что в среднем транзакции выполняли почти 4000 логических считываний. Много это или мало, зависит от системы. В моем случае работало несколько больших фоновых заданий, так что такой объем чтения вполне приемлем.

Далее идет действительно важная информация - статистика по разборам. Она свидетельствует, что в среднем выполнялось по 16 разборов в секунду, причем выполнялось в среднем по 0,17 жестких разбора в секунду (разбирались никогда ранее не встречавшиеся операторы SQL). Примерно раз в шесть секунд система разбирала абсолютно новый оператор SQL. Это неплохо. Однако если бы в этом столбце за период, равный нескольким дням, сохранилось значение ноль, что свидетельствует о хорошей настройке системы, я был бы доволен. С некоторого момента все операторы SQL должны находится в разделяемом пуле.

% Blocks changed per Read: 1.07 Recursive Call %: 97.39

Rollback per transaction %: 0.29 Rows per Sort: 151.30

В следующем разделе приведен ряд интересных показателей. Параметр % Blocks Changed per Read показывает, что 99 логических чтений пришлись на блоки, которые только счит1вались, но не изменялись. Система изменяла только 1 процент прочитанных блоков. Процент рекурсивных вызовов (Recursive Call %) очень высок - более 97. Это не означает, что 97 процентов SQL-операторов в моей системе выполняются в ходе управления пространством или разбора. Если вернуться к анализу исходного трассировочного файла в разделе, посвященном SQL TRACE, там было показано, что операторы SQL, выполняющиеся в PL/SQL, также считаются рекурсивными . В моей системе почти все, кроме модуля mod plsql (это модуль Web-сервера Apache) и редких пакетных заданий, выполняется с помощью PL/SQL; все остальное написано на языке PL/SQL. Поэтому я бы удивился низкому значению Recursive Call %.

Процент отмененных транзакций (Rollback per transaction %) - очень низкий, и это хорошо. Откат - весьма дорогостоящая операция. Сначала мы что-то делаем, и на это тратятся ресурсы. Затем мы отменяем сделанное, и на это тоже требуются ресурсы. Много ресурсов потрачено без всякого результата. Если большинство транзакций откатывается, значит, основные ресурсы сервера уходят на то, чтобы что-то делать и тут же отменять сделанное. Надо разобраться, чем вызван такой объем отката и как можно переделать приложение, чтобы это изменить. В рассматриваемой системе лишь одна из примерно 345 транзакций откатывается - это приемлемо.