oracle autotrace что это такое

Инструменты для настройки производительности SQL

Инструменты для настройки производительности SQL чрезвычайно важны. Разработчики могут использовать их для изучения хороших стратегий выполнения, а в производственной базе данных они оказывают неоценимую помощь при реактивной настройке. Эти инструменты могут давать хорошее представление об используемых запросами ресурсах. В их число входят такие утилиты, как EXPLAIN PLAN, Autotrace, SQL Trace и TKPROF.

Использование инструмента EXPLAIN PLAN

Утилита EXPLAIN PLAN помогает настраивать SQL за счет того, что позволяет просматривать план выполнения, выбираемый для SQL-оператора оптимизатором Oracle. Во время настройки SQL может возникать необходимость переписывать запросы и экспериментировать с подсказами для оптимизатора. Инструмент EXPLAIN PLAN просто замечательно подходит для таких экспериментов, потому что позволяет немедленно узнавать, как будет работать запрос при каждом изменении в коде. Поскольку эта утилита дает возможность видеть план выполнения без выполнения кода, она избавляет от необходимости запускать ненастроенный код для выяснения того, принесли ли изменения какую-то выгоду. Понимание работы EXPLAIN PLAN является важным в оценке производительности запросов. Она, по сути, приоткрывает окно в логику, которой пользуется оптимизатор Oracle при выборе планов выполнения.

Анализ вывода EXPLAIN PLAN позволяет видеть шаги, которые будет предпринимать CBO для выполнения данного SQL-оператора. Утилита EXPLAIN PLAN четко показывает, будет ли оптимизатор, например, использовать индекс. Вдобавок она сообщает о порядке, в котором будут соединяться таблицы, и помогает оценить производительность запросов. Если более конкретно, то в выводе этой утилиты отображается следующая информация:

Создание вывода EXPLAIN PLAN

Сгенерировать вывод EXPLAIN PLAN для любого оператора языка манипулирования данными SQL можно примерно так, как показано в листинге 2.

Получение вывода EXPLAIN PLAN

Просто так выбирать столбцы из таблицы PLAN_TABLE нельзя из-за иерархической природы взаимоотношений между ними. В листинге 3 приведен код, который можно использовать для того, чтобы вывод EXPLAIN PLAN распечатывался в читабельном виде и ясно показывал, как выглядит план выполнения оператора.

Другие способы отображения результатов EXPLAIN PLAN

Сначала потребуется создать сам оператор EXPLAIN PLAN для SQL-оператора:

Затем необходимо задать в SQL*Plus надлежащий размер строк и страниц:

Теперь можно отобразить вывод EXPLAIN PLAN :

Интерпретирование вывода EXPLAIN PLAN

Поначалу интерпретировать вывод EXPLAIN PLAN немного сложно, поэтому не помешает запомнить перечисленные ниже простые принципы.

В примере, показанном ранее в листинге 3 (где отражающий план вывод идет сразу же после кода), Oracle использует таблицу INVENTORIES в качестве управляющей таблицы и применяет следующий путь выполнения:

Этот вывод говорит о следующем.

Используя вывод EXPLAIN PLAN, можно быстро определять, почему некоторые из запросов занимают больше времени, чем ожидалось. Обладая такими знаниями, можно легко настраивать запрос до тех пор, пока не будет достигнут приемлемый порог по производительности. Замечательным в утилите EXPLAIN PLAN является то, что в случае ее применения никогда не требуется выполнять ни одного оператора в самой базе данных для отслеживания плана его выполнения. В следующем разделе предлагаются еще некоторые примеры использования этой утилиты.

Другие примеры планов

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

В третьем примере для извлечения результатов запроса осуществляется соединение двух таблиц ( customers и orders ):

В листинге 4 показано, как будет выглядеть вывод EXPLAIN PLAN в таком случае.

На шаге 4 строки, полученные из таблицы orders на шаге 3, будут соединяться со строками, полученными из таблицы customers на шаге 2, на основании соблюдения условия WHERE o.customer_id=c.customer_id.

Как видно по предыдущим примерам, утилита EXPLAIN PLAN позволяет получать четкое представление об используемых оптимизатором методах доступа, и делать это без выполнения самого запроса. Зачастую она помогает оперативно узнать, почему SQL-код работает медленно. Вывод EXPLAIN PLAN может позволить определить, насколько избирательными являются индексы, и экспериментировать с быстрым внесением соответствующих изменений в код.

Использование утилиты Autotrace

Утилита Autotrace (Автотрассировка) позволяет получать вывод EXPLAIN PLAN автоматически при выполнении SQL-оператора в SQL*Plus. В случае входа в систему от имени пользователя SYS или SYSTEM привилегии, необходимые для использования этой утилиты, предоставляются автоматически.

Перед использованием утилиты Autotrace необходимо создать в своей схеме таблицу плана ( PLAN_TABLE ). Она будет применяться для всех последующих выполнений утилиты Autotrace. В случае отсутствия такой таблицы в схеме, при попытке запустить утилиту Autotrace будет появляться сообщение об ошибке:

Если роли PLUSTRACE еще не существует в базе данных, как в показанном выше примере, тогда пользователь SYS должен запустить сценарий plustrace.sql (см. листинг 6) для ее создания.

Затем роль PLUSTRACE должна предоставляться тому пользователю, который желает использовать утилиту Autotrace:

После этого данный пользователь может активизировать утилиту Autotrace и просматривать вывод EXPLAIN PLAN для любого запроса, который использует в сеансе. Утилита Autotrace может активизироваться с различными опциями.

Для всех SQL-операторов, выполняемых после активизации утилиты Autotrace, будут генерироваться планы выполнения (до тех пор, пока утилита Autotrace не будет отключена с помощью команды SET AUTOTRACE OFF ), как показано в листинге 7.

Как видно в этом листинге, после отображения плана выполнения для SQL-оператора утилита Autotrace отображает детали о количестве рекурсивных вызовов SQL, произошедших во время выполнения исходного оператора, количестве операций физического и логического чтения, количестве операций сортировки в памяти и на диске и количестве обработанных строк.

Далее предлагаются примеры оптимизации SQL-запросов с применением утилиты Autotrace. В этих примерах один и тот же запрос выполняется в отношении таблицы courses дважды: один раз без индекса, а другой — с индексом. После индексирования таблицы этот запрос выполняется перед ее анализом. Результаты говорят сами за себя.

Как здесь видно, в запросе была использована операция полного сканирования таблицы по причине отсутствия у этой таблицы каких-либо индексов. Из-за этого всего было выполнено 338 операций физического чтения. Обратите внимание, что общее количество строк в таблице courses составляет 98 384. Из этого количества предметов по теме “медицина” оказалось 98 304. Это значит, что значения в таблице совершенно не распределяются равномерно среди предметов. Теперь давайте посмотрим, что произойдет в случае использования индекса.

В следующем примере выполняется аналогичный запрос, но с индексом. Однако никакие статистические данные ни по таблице, ни по индексу не собираются. Результаты создания индекса по таблице courses и выполнения в его отношении такого же запроса, получаются довольно интересными. Увидеть это можно в листинге 9.

В третьем примере запрос с индексом выполняется после сбора статистических данных по таблице. Теперь у Oracle есть все необходимые статистические данные и потому на этот раз применяется оптимизатор CBO. Оптимизатор CBO принимает решение использовать индекс только в том случае, если стоимость применения индекса будет ниже стоимости полного сканирования таблицы. В данном случае принято решение не использовать индекс, потому что запросу придется считывать 98 304 из общих 98 384 строк. Oracle правильно решает выполнять вместо этого полное сканирование таблицы. Результаты показаны в листинге 10.

В этом листинге первый элемент — recursive calls (рекурсивные вызовы) — отражает количество дополнительных операторов, которые Oracle приходится выполнять при обработке SQL-оператора пользователя. Например, такие рекурсивные вызовы (или рекурсивные SQL-операторы) приходится выполнять для выделения пространства или для выполнения запросов в таблицы словаря данных на диске. В данном примере Oracle пришлось сделать 290 подобных внутренних вызов.

Использование утилит SQL Trace и TKPROF

SQL Trace (Трассировка SQL) представляет собой утилиту Oracle, которая помогает отслеживать выполнение SQL-операторов, а TKPROF — еще одну утилиту Oracle, которая помогает преобразовывать генерируемые SQL Trace файлы трассировки в удобный для чтения формат. Если утилита EXPLAIN PLAN предоставляет ожидаемый план выполнения, то утилита SQL Trace выдает уже фактические результаты выполнения SQL-запроса. Иногда бывает невозможно идентифицировать точный код, скажем, генерируемых динамическим образом SQL-операторов. Файлы SQL Trace могут легко перехватывать такой код. Помимо всего прочего, SQL Trace позволяет отслеживать следующие переменные.

Совет. Если в приложении много SQL-кода генерируется динамически, утилита SQL Trace является идеальным средством для настройки SQL-операторов.

Хотя утилита EXPLAIN PLAN и важна для определения пути доступа, который будет использовать оптимизатор, SQL Trace предлагает массу чрезвычайно полезной информации о потреблении ресурсов и эффективности операторов. Она позволяет получать четкое представление о том, не подвергается ли оператор излишнему синтаксическому анализу. Показатели по количеству выполнений и выборки иллюстрируют степень его эффективности. Хорошо видно, сколько времени ЦП расходуется на обработку запросов и сколько операций ввода-вывода происходит на этапе их выполнения. Это помогает выявлять в приложении те SQL-операторы, которые отнимают больше всего ресурсов, и настраивать их. Вывод EXPLAIN PLAN, который является необязательной частью вывода SQL Trace, отражает количество строк, извлекаемых на отдельных шагах плана выполнения, и тем самым помогает выявлять шаги, на которых выполняется больше всего работы. Путем сравнения объема потребляемых ресурсов с количеством выбираемых строк можно легко определять, насколько продуктивным является конкретный оператор.

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

Установка параметров инициализации, касающихся трассировки

Сбор трассировочных статистических данных сказывается на производительности и поэтому Oracle не производит трассировку автоматически для всех сеансов. Трассировка представляет собой совершенно необязательный процесс, который активизируется на ограниченное количество времени для сбора метрических показателей по производительности критичных SQL-операторов. Чтобы процесс трассировки SQL происходил в Oracle правильно, сначала необходимо соответствующим образом установить четыре параметра инициализации и перезапустить базу данных после получения уверенности в том, что они сконфигурированы так, как надо. Три из этих параметров представляют собой динамические параметры, которые можно изменять на уровне сеанса.

Параметр STATISTICS_LEVEL

Параметр TIMED_STATISTICS

Параметр USER_DUMP_DEST

Параметр MAX_DUMP_FILE_SIZE

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

Активизация механизма трассировки SQL

А вот пример установки SQL_TRACE в TRUE с помощью пакета DBMS_SESSION :

Часто пользователи просят администратора баз данных помочь со сбором трассировочных данных по их SQL-операторам.

Интерпретирование трассировочных файлов с помощью TKPROF

Отличать трассировочный файл, созданный в результате выполнения SQL Trace, от остальных файлов в каталоге дампа можно по его размеру: такие трассировочные файлы обычно имеют гораздо больший размер по сравнению с остальными файлами в каталоге. Эти трассировочные файлы являются подробными и сложными. К счастью, есть легко запускаемая утилита TKPROF, которая умеет преобразовывать вывод таких файлов в удобный для чтения формат. Она принимает эти файлы в качестве входных данных вместе с несколькими другими параметрами.

В табл. 1 показаны основные параметры, которые можно передавать утилите TKPROF для получения желаемого формата. Введя в командной строке команду tkprof, можно получить список всех допустимых параметров утилиты TKPROF.

Совет. Введя tkprof в приглашении операционной системы, можно быстро получить справку по использованию утилиты TKPROF.

Изучение файла с отформатированным выводом

В листинге 11 показана верхняя часть файла test.txt, в которой объясняются ключевые термины, используемые утилитой.

В каждом отчете TKPROF для каждого SQL-оператора, выполнявшегося во время отслеживавшегося сеанса пользователя, отображается следующая информация:

Следовательно, по листингу 12 можно сделать такие выводы.

Ниже показана следующая часть вывода TKPROF, отражающая план выполнения, который был запрошен явным образом при вызове утилиты TKPROF. Обратите внимание на то, что вместо показателей по стоимости, которые возвращаются при использовании утилиты EXPLAIN PLAN, в данном случае возвращается информация о количестве строк вывода на каждом этапе выполнения.

И, наконец, в последней части вывода TKPROF отображается сводный отчет, сообщающий, сколько всего SQL-операторов было отслежено. Ниже показано, как выглядит эта часть:

Вывод TKPROF позволяет легко выявлять неэффективные SQL-операторы. TKPROF может упорядочивать SQL-операторы по затраченному на их выполнение времени и тем самым помогать определить, какие из SQL-операторов нуждаются в оптимизации.

Утилита SQL Trace является очень мощным инструментом для настройки SQL, поскольку выходит далеко за рамки той информации, которую предоставляет утилита EXPLAIN PLAN. Она предоставляет точные сведения о количестве различных вызовов, которые выполнялись к Oracle во время выполнения оператора, а также о том, как потреблялись ресурсы на различных этапах его выполнения.

На заметку! Сеансы отдельных пользователей еще очень удобно отслеживать с помощью интерфейса OEM Database Control.

Источник

Настройка средства AUTOTRACE в SQL*Pius

Начальная установка AUTOTRACE

Средство AUTOTRACE полагается на доступность таблицы по имени PLAN_ТАВLЕ. Начиная с версии Oracle 10g, схема SYS содержит глобальную временную таблицу под названием PLAN_TABLE$. Все необходимые привилегии для работы с этой таблицей выданы пользователю PUBLIC и определен открытый синоним (с именем PLAN_TABLE, который указывает на SYS.PLAN_TABLE$). Это значит, что получать доступ к этой таблице может любой пользователь.

Вы должны также создать и назначить роль PLUSTRACE:

При желании можете заменить PUBLIC в команде GRANT другим именем пользователя.

Управление отчетом AUTOTRACE

Отчет о пути выполнения, который используется оптимизатором SQL, и статистику по выполнению операторов можно получать автоматически. Отчет генерируется после успешного выполнения операторов SQL DML (т.е, SELECT, DELETE, UPDATE, MERGE и INSERT). Он полезен ля отслеживания и настройки производительности перечисленных операторов. Отчетом можно управлять посредством настройки системной переменной AUTOTRACE.

• SET AUTOTRACE OFF. Отчет AUTOTRACE не генерируется. Это принято по умолчанию.

• SET AUTOTRACE ON EXPLAIN. Отчет AUTOTRACE будет отображать только путь выполнения, применяемый оптимизатором.

• SET AUTOTRACE ON STATISTICCS. Отчет AUTOTRACE будет отображать толь-ко статистику по выполнению SQL-операторов.

• SET AUTOTRACE ON. Отчет AUTOTRACE будет содержать путь выполнения, используемый оптимизатором, и статистику по выполнению SQL-операторов.

• SET AUTOTRACE TRACEONLY. Похоже на SET AUTOTRACE ON, но подавляет вывод запроса пользователя, если он есть.

• SET AUTOTRACE TRACEONLY EXPLAIN: Похоже на SET AUTOTRACE ON, но подавляет вывод запроса пользователя (если он есть) и также статистику по выполнению.

Источник

11
Using Autotrace in SQL*Plus

This chapter contains the following sections:

Controlling the Autotrace Report

You can control the report by setting the AUTOTRACE system variable.

No AUTOTRACE report is generated. This is the default.

SET AUTOTRACE ON EXPLAIN

The AUTOTRACE report shows only the optimizer execution path.

SET AUTOTRACE ON STATISTICS

The AUTOTRACE report shows only the SQL statement execution statistics.

The AUTOTRACE report includes both the optimizer execution path and the SQL statement execution statistics.

SET AUTOTRACE TRACEONLY

Example 11-1 Creating a PLAN_TABLE

Run the following commands from your SQL*Plus session to create the PLAN_TABLE in the HR schema:

Example 11-2 Creating the PLUSTRACE Role

Run the following commands from your SQL*Plus session to create the PLUSTRACE role and grant it to the DBA:

Example 11-3 Granting the PLUSTRACE Role

Run the following commands from your SQL*Plus session to grant the PLUSTRACE role to the HR user:

Execution Plan

The execution plan shows the SQL optimizer’s query execution path. Each line of the execution plan has a sequential line number. SQL*Plus also displays the line number of the parent operation.

The execution plan consists of four columns displayed in the following order:

Shows the line number of each execution step.

Shows the relationship between each step and its parent. This column is useful for large reports.

Shows each step of the report.

Shows the database links or parallel query servers used.

The format of the columns may be altered with the COLUMN command. For example, to stop the PARENT_ID_PLUS_EXP column being displayed, enter the following:

The execution plan output is generated using the EXPLAIN PLAN command.

Chapter 9, «Using EXPLAIN PLAN» for more information about interpreting the output of EXPLAIN PLAN

Statistics

The statistics are recorded by the server when your statement executes and indicate the system resources required to execute your statement. The results include the following statistics:

Number of recursive calls generated at both the user and system level. Oracle maintains tables used for internal processing. When Oracle needs to make a change to these tables, it internally generates an internal SQL statement, which in turn generates a recursive call.

Number of times a CURRENT block was requested.

Number of times a consistent read was requested for a block

Total number of data blocks read from disk. This number equals the value of «physical reads direct» plus all reads into buffer cache.

Total amount of redo generated in bytes

bytes sent via SQL*Net to client

Total number of bytes sent to the client from the foreground processes.

bytes received via SQL*Net from client

Total number of bytes received from the client over Oracle Net.

SQL*Net roundtrips to/from client

Total number of Oracle Net messages sent to and received from the client

Number of sort operations that were performed completely in memory and did not require any disk writes

Number of sort operations that required at least one disk write

Number of rows processed during the operation

The client referred to in the statistics is SQL*Plus. Oracle Net refers to the generic process communication between SQL*Plus and the server, regardless of whether Oracle Net is installed.

You cannot change the default format of the statistics report.

Example 11-4 Tracing Statements for Performance Statistics and Query Execution Path

If the SQL buffer contains the following statement:

The statement can be automatically traced when it is run:

Your output may vary depending on the version of the server to which you are connected and the configuration of the server.

Example 11-5 Tracing Statements Without Displaying Query Data

To trace the same statement without displaying the query data, enter:

This option is useful when you are tuning a large query, but do not want to see the query report.

Example 11-6 Tracing Statements Using a Database Link

To trace a statement using a database link, enter:

Tracing Parallel and Distributed Queries

When you trace a statement in a parallel or distributed query, the execution plan shows the cost based optimizer estimates of the number of rows (the cardinality). In general, the cost, cardinality and bytes at each node represent cumulative results. For example, the cost of a join node accounts for not only the cost of completing the join operations, but also the entire costs of accessing the relations in that join.

Lines marked with an asterisk (*) denote a parallel or remote operation. Each operation is explained in the second part of the report.

The second section of this report consists of three columns displayed in the following order:

Shows the line number of each execution step.

Describes the function of the SQL statement in the OTHER_PLUS_EXP column.

Shows the text of the query for the Oracle Real Application Clusters database or remote database.

Example 11-7 Tracing Statements With Parallel Query Option

To trace a parallel query running the parallel query option:

Line 0 of the Execution Plan shows the cost based optimizer estimates the number of rows at 1, taking 26 bytes. The total cost of the statement is 1.

Lines 2, 3, 4 and 5 are marked with asterisks, denoting parallel operations. For example, the NESTED LOOPS step on line 3 is a PARALLEL_TO_SERIAL operation. PARALLEL_TO_SERIAL operations execute a SQL statement to produce output serially. Line 2 also shows that the parallel query server had the identifier Q2000.

Numbers identifying parallel report lines cross reference the line of the parent report. For example, in the last line of the example:

The 4 refers to the 4 3 TABLE ACCESS *. line in the parent report.

Example 11-8 Monitoring Disk Reads and Buffer Gets

To monitor disk reads and buffer gets:

The following shows typical results:

If consistent gets or physical reads is high relative to the amount of data returned, it indicates that the query is expensive and needs to be reviewed for optimization. For example, if you are expecting less than 1,000 rows back and consistent gets is 1,000,000 and physical reads is 10,000, further optimization is needed.

SET Variables Influencing SQL*Plus Performance

The following SET variables can influence SQL*Plus performance.

SET APPINFO OFF

Sets automatic registering of scripts through the DBMS_APPLICATION_INFO package. Setting APPINFO OFF disables the registering and monitoring of performance and resource usage of scripts. This reduction in overheads may improve performance.

SET ARRAYSIZE

Sets the number of rows—called a batch—that SQL*Plus will fetch from the database at one time. Valid values are 1 to 5000. A large value increases the efficiency of queries and subqueries that fetch many rows, but requires more memory. Values over approximately 100 provide little added performance. ARRAYSIZE has no effect on the results of SQL*Plus operations other than increasing efficiency.

SET DEFINE OFF

SET FLUSH OFF

SET FLUSH is not supported in iSQL*Plus

Controls when output is sent to the user’s display device. OFF allows the host operating system to buffer output which may improve performance by reducing the amount of program I/O.

Use OFF only when you run a script that does not require user interaction and whose output you do not need to see until the script finishes running.

SET SERVEROUTPUT

SET TRIMOUT ON

SET TRIMOUT is not supported in iSQL*Plus

Determines whether SQL*Plus allows trailing blanks at the end of each displayed line. ON removes blanks at the end of each line, which may improve performance especially when you access SQL*Plus from a slow communications device. TRIMOUT ON does not affect spooled output.

SET TRIMSPOOL ON

SET TRIMSPOOL is not supported in iSQL*Plus

Determines whether SQL*Plus allows trailing blanks at the end of each spooled line. ON removes blanks at the end of each line, which may improve performance especially when you access SQL*Plus from a slow communications device. TRIMSPOOL ON does not affect terminal output.

iSQL*Plus Server Statistics

iSQL*Plus Server statistics provide static environment information as well as dynamic information about iSQL*Plus sessions. You can request a report containing iSQL*Plus Server statistics with:

where machine_name.domain is the URL of the Oracle HTTP Server for which you want to generate iSQL*Plus Server statistics.

where port is the port number used by the iSQL*Plus Server. The default is 7777.

where full gives all possible statistics and is the default.

and where active gives dynamically changing session statistics for the iSQL*Plus Server. These statistics are also included at the end of the full report.

where [&refresh= number ] optionally specifies the time in seconds before the statistics report is automatically refreshed. The minimum value is 10 seconds.

You must have Oracle HTTP Server authentication to access the iSQL*Plus DBA URL, but as there is no connection to a database, no Oracle9 i login is required.

The iSQL*Plus Server statistics report has the following sections.

All possible statistics for the full report are shown in the following list:

Server Details

This section displays the following information about the iSQL*Plus Server:

Server Environment

This section shows settings for iSQL*Plus Server environment variables:

Configuration Parameters

This section shows settings for iSQL*Plus Server parameters:

Client Details

This section shows the type of web browser used by the iSQL*Plus Client:

Active Statistics

This section shows the current values for the following iSQL*Plus Server statistics:

The number of concurrent active sessions, or the number of people currently logged in to iSQL*Plus.

Sessions since startup

The cumulative count of sessions established since the iSQL*Plus Server started.

Maximum concurrent sessions

The maximum or peak number of concurrent sessions since the iSQL*Plus Server started.

Sessions expired since startup

The cumulative count of the number of sessions timed-out due to inactivity since the iSQL*Plus Server started.

Requests since startup

The cumulative count of active HTTP requests since the iSQL*Plus server was started.

Next expiry operation (minutes)

The number of minutes (rounded down) until the next expiry process.

Expiry operations since startup

The number of times the expiry process has run since the iSQL*Plus Server started.

Hash table collisions

The number of active sessions that currently have a hash table collision. Compare this with Sessions active to see if there is a current problem with collisions.

Hash table collisions since startup

The cumulative count of the sessions that have had a hash table collision since the iSQL*Plus Server started. Compare this with Sessions since startup to see if there is an ongoing problem with collisions.

Interpreting Active Statistics

To maximize resource availability it is recommended that each user of iSQL*Plus have a database schema profile with appropriately defined limits.

Increasing Number of Threads

If there are many people logged in doing long running queries, then response may be improved by increasing iSQLPlusNumberOfThreads to increase the number of threads available.

Increasing Hash Table Size

If there are a large number of collisions relative to the number of sessions, then consider increasing the hash table size by increasing iSQLPlusNumberOfThreads to improve response.

Reducing Timeout Interval

If large numbers of people are being timed out, it is an indication that users are not logging out cleanly, and sessions may be remaining idle. In this case, and if the iSQL*Plus Server load is high, you may want to consider reducing the iSQLPlusTimeOutInterval to more aggressively time out sessions.

Idle Timeout

The idle timeout is the time the Oracle HTTP Server waits for results from iSQL*Plus. It is set to 3600 seconds, which is likely to prevent iSQL*Plus timing out before the web browser. It is sufficient for many long queries to return results before iSQL*Plus times out.

The idle timeout should not be confused with the iSQLPlusTimeOutInterval which manages the lifetime of a user’s session.

Monitoring Disk Reads and Buffer Gets

Monitor disk reads and buffer gets by executing the following statement in SQL*Plus:

Typical results returned are shown as follows:

If ‘consistent gets’ or ‘physical reads’ is high relative to the amount of data returned, then this is a sign that the query is expensive and needs to be reviewed for optimization.

For example, if you are expecting less than 1,000 rows back and ‘consistent gets’ is 1,000,000 and ‘physical reads’ is 10,000, then this query needs to be further optimized.

Источник

• ← приспособления растений к жизни в водоемах
• snapshot maven что это →