КОНФИГУРИРОВАНИЕ СЕРВЕРА ORACLE
----------------------------------------------------------------
ЧАСТЬ II
КОНФИГУРИРОВАНИЕ СЕРВЕРА ORACLE
ГЛАВА 4
----------------------------------------------------------------
УПРАВЛЕНИЕ ПРОЦЕССАМИ ORACLE
Эта глава объясняет, как управлять процессами инстанции ORACLE.
Темы этой главы включают обсуждение следующих вопросов:
* запуск однопроцессных и многопроцессных инстанций ORACLE
* конфигурирование и запуск ORACLE с многоканальными
серверами
* подключение к инстанции
* мониторинг процессов ORACLE
* снятие пользовательских процессов
Управление процессами ORACLE 4-1
----------------
Запуск однопроцессных и многопроцессных инстанций
В большинстве операционных систем вы можете запускать инстанцию
ORACLE либо в однопроцессном, либо в многопроцессном режиме,
независимо от того, как ORACLE был инсталлирован или запускался
последний раз. Если компьютер, на котором выполняется сервер
ORACLE, поддерживает многопроцессность, то инстанции баз данных
обычно запускаются в многопроцессном режиме, так что много
пользователей могут одновременно обращаться к разделяемой базе
данных; однопроцессные же инстанции поддерживают лишь одного
пользователя в каждый момент. Однако, в некоторых
экспериментальных ситуациях, вы можете найти полезным запустить
инстанцию в однопроцессном режиме.
Некоторые операционные системы (такие как MS-DOS) не
поддерживают многопроцессности или разделяемой памяти; в таких
системах однопроцессная инстанция является единственной
возможностью.
Задание режима процессов
------------------------
Режим процессов инстанции задается параметром инициализации
SINGLE_PROCESS. Чтобы запустить однопроцессную инстанцию,
установите этот параметр в TRUE; чтобы запустить многопроцессную
инстанцию, установите этот параметр в FALSE. Если параметр
SINGLE_PROCESS опущен, его умалчиваемым значением считается
FALSE.
Если ваша система может выполнять только однозадачный ORACLE, то
ORACLE автоматически инсталлируется для такой конфигурации; у
вас не будет выбора, помимо запуска ORACLE в однозадачной
конфигурации.
----------------
Запуск ORACLE с только выделенными серверами
Если ваша система должна работать с выделенными серверными
процессами, то ORACLE автоматически инсталлируется для такой
конфигурации. Однако, если ваша система может поддерживать
ORACLE в такой конфигурации, может оказаться, что она
поддерживает также многоканальный сервер (описываемый в
следующей секции).
Чтобы запустить ORACLE в конфигурации выделенного сервера,
установите параметры инициализации MTS_SERVICE, MTS_DISPATCHERS,
MTS_SERVERS и MTS_LISTENER_ADDRESS в файле параметров базы
данных в пустые значения, или совсем выбросьте их из файла
параметров. (Обратитесь к приложению A для дополнительной
информации об этих параметрах и файлах параметров.)
4-2 Руководство администратора
----------------
Запуск ORACLE с многоканальными серверами
Чтобы установить вашу систему в конфигурацию многоканального
сервера, запустите процесс слушателя сети и установите некоторые
параметры инициализации:
* SHARED_POOL_SIZE
* MTS_LISTENER_ADDRESS
* MTS_SERVICE
* MTS_DISPATCHERS
* MTS_MAX_DISPATCHERS
* MTS_SERVERS
* MTS_MAX_SERVERS
Теперь вы можете запустить инстанцию, которая будет использовать
конфигурацию многоканального сервера.
Указания по управлению процессом сетевого слушателя приводятся в
вашей документации по SQL*Net; ниже даются указания по установке
каждого из перечисленных выше параметров.
Замечание: Пользовательские процессы, которые хотят использовать
многоканальный сервер, должны подключаться через SQL*Net, даже
если они работают на той же машине, что и инстанция ORACLE.
Распределение дополнительной памяти в разделяемом пуле
для разделяемого сервера
------------------------------------------------------
Когда пользователи подключаются через многоканальный сервер,
ORACLE должен распределить дополнительную память в разделяемом
пуле для хранения информации о соединениях между
пользовательскими процессами, диспетчерами и серверами. Для
каждого пользователя, который будет подключаться через
многоканальный сервер, добавьте 1K к значению параметра
SHARED_POOL_SIZE. (Для дополнительной информации об этом
параметре см. приложение A; см. также главу 23 для
дополнительной информации о настройке.)
Установка адреса процесса сетевого слушателя (MTS_LISTENER_ADDRESS)
-------------------------------------------------------------------
В файле параметров базы данных, установите параметр
инициализации MTS_LISTENER_ADDRESS для каждого порта, с которым
будет соединяться база данных. Этот параметр имеет следующий
синтаксис:
MTS_LISTENER_ADDRESS = "(адрес)"
Здесь "адрес" - это адрес, который слушатель будет прослушивать
на запросы соединения для конкретного протокола. Файл может
содержать несколько таких адресов (т.е. несколько параметров
MTS_LISTENER_ADDRESS):
Управление процессами ORACLE 4-3
MTS_LISTENER_ADDRESS = "(ADDRESS=(PROTOCOL=tcp)(PORT=5000)\
(HOST=ZEUS))"
MTS_LISTENER_ADDRESS = "(ADDRESS=(PROTOCOL=decnet)(OBJECT=outa)\
(NODE=ZEUS))"
Замечание: Этот синтаксис несколько отличается от аналогичного
параметра слушателя SQL*Net: параметр MTS_LISTENER_ADDRESS может
специфицировать лишь один адрес на логическую строку
(ADDRESS_LIST не поддерживается), тогда как параметр SQL*Net
может содержать список адресов. В остальном синтаксис сетевого
адреса совпадает.
Каждый адрес, заданный в файле параметров базы данных, должен
быть также специфицирован в соответствующем файле конфигурации
слушателя. Адреса кодируются по-разному для разных сетевых
протоколов. Для дополнительной информации о том, как задавать
адреса для процесса сетевого слушателя, обратитесь к вашему
руководству по инсталляции [IUG] и к документации по SQL*Net.
Задание имен служб для диспетчеров (MTS_SERVICE)
------------------------------------------------
С помощью параметра MTS_SERVICE специфицируйте имя службы,
ассоциируемой с диспетчерами. Пользователь запрашивает
многоканальный сервер, задавая это имя службы в строке
соединения. Имя службы должно быть уникальным; если возможно,
используйте в качестве него SID инстанции. Если вы не
устанавливаете этот параметр, его умалчиваемым значением будет
значение параметра DB_NAME. (Если параметр DB_NAME также не
установлен, ORACLE возвращает ошибку ORA-00114, "опущено
значение системного параметра mts_service", при запуске базы
данных.) Чтобы узнать значение вашего SID, введите команду SHOW
LOGICAL ORA_SID в SQL*DBA.
Например, если имя диспетчерской службы суть TEST_DB, этот
параметр можно установить следующим образом:
MTS_SERVICE = "test_db"
В дальнейшем, для соединения с этим диспетчером можно
использовать строку соединения, подобную следующей:
SQLPLUS scott/tiger@\
(DESCRIPTION=(ADDRESS=(PROTOCOL=decnet)(NODE=hq)\
OBJECT=mts7)\
(CONNECT_DATA=(SID=test_db)))
Для дополнительной информации о том, как задавать строку
соединения для конфигурации многоканального сервера, обратитесь
к вашему руководству по инсталляции [IUG] и к документации по
SQL*Net.
Установка начального числа диспетчеров
--------------------------------------
Число диспетчерских процессов, запускаемых при запуске
инстанции, определяется параметром MTS_DISPATCHERS. Оцените
заранее, сколько диспетчеров следует запускать для каждого
сетевого протокола.
4-4 Руководство администратора
Должное число диспетчерских процессов для каждой инстанции
зависит от того, какой производительности базы данных вы хотите
добиться, от лимита на число соединений на процесс, зависящего
от операционной системы, и от числа соединений, требуемых на
каждый сетевой протокол. (Обратитесь к вашему руководству по
инсталляции, чтобы узнать об ограничениях операционной системы.)
Инстанция должна обеспечивать столько соединений, сколько
одновременных пользователей может оказаться в базе данных; чем
больше диспетчеров вы имеете, тем лучшую потенциальную
производительность увидят пользователи, так как им не придется
долго ждать диспетчерского обслуживания.
Узнав число возможных соединений на процесс для вашей
операционной системы, вычислите начальное число диспетчерских
процессов, которые должны запускаться при старте инстанции для
каждого сетевого протокола, с помощью следующей формулы:
число максимальное число одновременных сессий
диспетчеров = CEIL (---------------------------------------)
число соединений на одного диспетчера
Знаменатель этой формулы зависит от операционной системы.
Например, предположим, что ваша система имеет обычно 80
пользователей, одновременно подключенных через TCP/IP, и 40
пользователей, подключенных через DECnet. В этом случае
параметр MTS_DISPATCHERS следует задать следующим образом:
MTS_DISPATCHERS = "TCPIP, 3"
MTS_DISPATCHERS = "DECNET, 3"
При задании параметра MTS_DISPATCHERS вы можете включать лишь те
протоколы, которые специфицированы в параметре
MTS_LISTENER_ADDRESS.
После запуска инстанции вы можете, если надо, запускать
дополнительные диспетчерские процессы; однако можно запускать
лишь диспетчеры, использующие те протоколы, которые
специфицированы в файле параметров базы данных. Например, если
файл параметров запускает диспетчеры для протоколов A и B, вы не
можете во время работы запустить диспетчер для протокола C, не
изменив файл параметров и не перезапустив инстанцию. (Для
дополнительной информации см. "Добавление и удаление
диспетчерских процессов" на странице 4-7.)
Установка максимального числа диспетчеров
-----------------------------------------
Параметр MTS_MAX_DISPATCHERS задает максимальное число
диспетчерских процессов (для всех сетевых протоколов вместе),
которое можно запустить для инстанции. Чтобы оценить
максимальное число диспетчерских процессов, которые могут
потребоваться инстанции, используйте следующую формулу:
максимальное число одновременных сессий
MTS_MAX_DISPATCHERS = ---------------------------------------
число соединений на одного диспетчера
Управление процессами ORACLE 4-5
Вы можете создавать столько диспечтерских процессов, сколько вам
надо, но общее число процессов, включая диспетчерские, не может
превышать лимита, устанавливаемого операционной системой на
число выполняющихся процессов.
Установка начального числа разделяемых серверных процессов
----------------------------------------------------------
Число разделяемых серверных процессов, запускаемых при старте
инстанции, задается параметром MTS_SERVERS. Требуемое число
начальных разделяемых серверных процессов для базы данных
зависит от того, сколько обычно подключается пользователей, и
какая обработка требуется для каждого пользователя. Если каждый
пользователь делает в единицу времени относительно мало
запросов, то каждый соответствующий пользовательский процесс
большую часть времени простаивает. В этом случае один серверный
процесс может обслуживать от 10 до 20 пользователей. Если
интенсивность запросов пользователей высока, то для обработки
этих запросов требуется большая доля серверных процессов по
отношению к процессам пользователей.
Если вы хотите использовать разделяемые процессы в ORACLE, вы
должны установить для параметра MTS_SERVERS значение, не меньшее
1. Если вы установите нулевое значение или совсем опустите этот
параметр, то ORACLE вообще не запустит ни одного разделяемого
сервера. Однако вы можете увеличить нулевое значение
MTS_SERVERS во время работы инстанции; см. секцию "Изменение
минимального числа разделяемых серверных процессов" на странице
4-6.
Лучше всего принять заниженную оценку числа разделяемых
серверов. Дополнительные разделяемые серверы запускаются
автоматически, когда это необходимо, и автоматически
закрываются, когда они начинают слишком долго простаивать.
Однако начальное число серверов всегда остаются активными, даже
если они простаивают. Если вы установите слишком высокое
значение для начального числа серверов, ваша система будет нести
ненужные накладные расходы. Поэкспериментируйте с различным
начальным числом разделяемых серверных процессов, отслеживая их
поведение, пока не найдете идеальное значение для вашего
типичного режима работы базы данных
Установка максимального числа разделяемых серверных процессов
-------------------------------------------------------------
Параметр MTS_MAX_SERVERS задает максимальное число разделяемых
серверных процессов, которое можно запустить для инстанции. В
общем случае, этот параметр должен соответствовать числу
разделяемых серверов, необходимому для периодов пиковых нагрузок
в базе данных. Поэкспериментируйте с различным максимальным
числом разделяемых серверных процессов, отслеживая их поведение,
пока не найдете идеальное значение для этого параметра.
Изменение минимального числа разделяемых серверных процессов
------------------------------------------------------------
После запуска инстанции вы можете изменить минимальное число
разделяемых серверных процессов либо через диалоговое окно
Configure Servers в SQL*DBA, либо через команду ALTER SYSTEM.
Рис.4-1 показывает диалог Configure Multi-Threaded Server.
4-6 Руководство администратора
Рис.4-1
Диалог Configure Multi-Threaded Server
---------------------------------------------------------------¬
¦ File Edit Session Instance Storage Log Backup Security¦
¦--------------------------------------------------------------+
¦¦ ¦
¦¦ ¦
¦¦ ¦
¦¦ г==== Configure Multi-Threaded Server ======¬ ¦
¦¦ ¦ ¦ ¦
¦¦ ¦ Number of Shared Server Processes: 2----- ¦ ¦
¦¦ ¦ ¦ ¦
¦¦ ¦-------------------------------------------¦ ¦
¦¦ ¦ Mandatory (OK) (Cancel) ¦ ¦
¦¦ L===========================================- ¦
¦¦ ¦
¦L-------------------------------------------------------------+
¦--------------------------------------------------------------+
¦¦ ¦
¦¦ ¦
¦L-------------------------------------------------------------+
L---------------------------------------------------------------
Этот пример устанавливает два разделяемых серверных процесса.
(ORACLE в конечном счете снимает слишком долго простаивающие
диспетчеры и серверы до установленного вами минимума.)
Следующее предложение показывает командный эквивалент диалога
Configure Multi-Threaded Server, показанного на рис.4-1:
ALTER SYSTEM SET MTS_SERVERS = 2
Если вы установите MTS_SERVERS в 0, то ORACLE постепенно снимет
все текущие серверы, когда они будут простаивать, но не будет
запускать новых серверов, пока вы не увеличите значение
MTS_SERVERS. Таким образом, обнуление MTS_SERVERS фактически
временно прекращает режим многоканального сервера.
Привилегии, требуемые для изменения минимального числа
разделяемых серверных процессов
Чтобы управлять минимальным числом разделяемых серверных
процессов, вы должны иметь привилегию ALTER SYSTEM.
Добавление и удаление диспетчерских процессов
---------------------------------------------
Вы можете управлять числом диспетчерских процессов в инстанции.
Если обзоры V$QUEUE и V$DISPATCHER показывают устойчиво высокую
загрузку диспетчерских процессов, запустите дополнительные
диспетчерские процессы, чтобы направлять запросы пользоваталей
без ожидания; вы можете запускать новые диспетчеры до тех пор,
пока их число не сравняется с значением MTS_MAX_DISPATCHERS. И
наоборот, если загрузка диспетчерских процессов устойчиво низка,
уменьшите число диспетчеров. (Обратитесь к главе 23 для
дополнительной информации о настройке многоканального сервера.)
Для изменения числа диспетчерских процессов используйте либо
диалоговое окно Configure Multi-Threaded Dispatcher в SQL*DBA,
Управление процессами ORACLE 4-7
либо команду ALTER SYSTEM. Рис.4-2 показывает диалог Configure
Multi-Threaded Dispatcher.
Рис.4-2
Диалог Configure Multi-Threaded Dispatcher
---------------------------------------------------------------¬
¦ File Edit Session Instance Storage Log Backup Security¦
¦--------------------------------------------------------------+
¦¦ ¦
¦¦ ¦
¦¦ г==== Configure Multi-Threaded Dispatcher ==¬ ¦
¦¦ ¦ ¦ ¦
¦¦ ¦ Dispatcher Protocol: tcpip----------- ¦ ¦
¦¦ ¦ Number of dispatchers: 4--------------- ¦ ¦
¦¦ ¦-------------------------------------------¦ ¦
¦¦ ¦ ------------------------------¬ ¦ ¦
¦¦ ¦ ¦ D0001 ¦ (Add) ¦ ¦
¦¦ ¦ ¦ D0002 ¦ ¦ ¦
¦¦ ¦ ¦ D0003 ¦ (Remove) ¦ ¦
¦¦ ¦ L------------------------------ ¦ ¦
¦¦ ¦-------------------------------------------¦ ¦
¦L--------¦ Mandatory (OK) (Cancel) ¦--------+
¦---------¦===========================================---------+
¦¦ ¦
¦¦ ¦
¦L-------------------------------------------------------------+
L---------------------------------------------------------------
Если перед этим было три диспетчера, то этот пример добавляет
один диспетчерский процесс. Следующее предложение показывает
командный эквивалент диалога Configure Multi-Threaded
Dispatcher, показанного на рис.4-2:
ALTER SYSTEM
SET MTS_DISPATCHER = 'TCPIP,4';
Вы можете запускать новые диспетчерские процессы лишь для тех
протоколов, которые специфицированы в параметрах
MTS_LISTENER_ADDRESS и MTS_DISPATCHERS. Чтобы запустить
диспетчеры для тех протоколов, для которых в данный момент нет
диспетчеров, остановите базу данных, отредактируйте файл
параметров, а затем перезапустите базу данных.
Если вы уменьшаете число диспетчеров для конкретного протокола,
лишние диспетчерские процессы не удаляются сразу. Вместо этого
ORACLE постепенно снимает диспетчеры, когда они слишком долго
простаивают, вплоть до лимита, который вы установили параметром
MTS_DISPATCHERS.
Изменение числа диспетчеров для одного протокола не затрагивает
диспетчеров других протоколов. (Для полного описания команды
ALTER SYSTEM обратитесь к документу ORACLE7 Server SQL Language
Reference Manual.)
4-8 Руководство администратора
Привилегии, требуемые для изменения числа диспетчерских процессов
Чтобы управлять числом диспетчерских процессов, вы должны иметь
привилегию ALTER SYSTEM.
Выбор выделенного сервера для соединения
----------------------------------------
Если возможно, пользователи должны присоединяться к инстанции
через диспетчер, чтобы поддерживать число процессов, требуемых
для работы инстанции, на низком уровне. В следующих ситуациях,
однако, пользователи и администраторы должны явно подключаться к
инстанции через выделенный серверный процесс:
* чтобы запустить пакетное задание (т.е. задание, которое
не позволит серверу простаивать)
* чтобы использовать SQL*DBA для запуска или останова базы
данных либо для восстановления носителя
Чтобы затребовать соединение через выделенный сервер,
пользователь должен включить специальную фразу (SRVR=DEDICATED)
в свою строку соединения TNS для SQL*Net. Для полного описания
синтаксиса строки соединения SQL*Net обратитесь к вашему
руководству по инсталляции и документации по SQL*Net.
----------------
Управление процессами ORACLE
Инстанция ORACLE может иметь много фоновых процессов, которые
вам необходимо отслеживать. Эта секция объясняет, как
идентифицировать эти процессы и управлять ими.
Замечание: Обратитесь к главе 23 для дополнительной информации о
настройке процессов ORACLE.
Мониторинг процессов инстанции ORACLE
-------------------------------------
Используйте средство мониторинга SQL*DBA, чтобы выдавать текущую
информацию о процессах базы данных ORACLE. Интерес представляют
следующие мониторы SQL*DBA:
PROCESS Монитор процессов суммирует информацию обо всех
процессах ORACLE, включая клиент-сервер,
пользовательские, серверные и фоновые процессы,
обращающиеся к базе данных через текущую инстанцию
базы данных.
SESSION Монитор сессий выдает идентификатор и состояние каждой
сессии, присоединенной к ORACLE.
Просмотр и мониторинг блокировок
--------------------------------
ORACLE также предоставляет два способа выдавать информацию о
блокировках для текущих транзакций в инстанции:
Управление процессами ORACLE 4-9
Мониторы Средство мониторинга SQL*DBA предоставляет два
SQL*DBA монитора для отслеживания блокировок инстанции.
(LOCK и Обратитесь к документу ORACLE7 Server Utilities
LATCH) User's Guide за полной информацией о мониторах
SQL*DBA.
UTLLOCKT.SQL Скрипт UTLLOCKT.SQL выдает простой символьный
граф ожиданий в форме дерева. Вызываемый через
любой инструмент разовых запросов (SQL*DBA или
SQL*Plus), этот скрипт распечатывает те сессии в
системе, которые ожидают блокировок, а также
соответствующие блокировки. Местоположение
этого скрипта зависит от операционной системы;
обратитесь к вашему руководству по инсталляции.
(Еще один скрипт, CATBLOCK.SQL, создает обзоры,
необходимые для UTLLOCKT.SQL, и должен быть
выполнен до того, как будет использоваться
UTLLOCKT.SQL).
Использование динамических таблиц производительности
----------------------------------------------------
Для отслеживания процессов инстанции ORACLE можно использовать
несколько таблиц производительности:
* V$CIRCUIT
* V$QUEUE
* V$DISPATCHER
* V$SHARED_SERVER
* V$SQLAREA
* V$SESS_IO
* V$LATCH
* V$SYSSTAT
Например, следующий запрос выдает рабочую нагрузку для каждого
диспетчерского процесса в системе:
SELECT (busy/(busy + idle))* 100 "% OF TIME BUSY"
FROM v$dispatcher;
Обратитесь к приложению B для дополнительной информации о
таблицах производительности.
Идентификация фоновых процессов ORACLE в операционной системе
-------------------------------------------------------------
Так как на вашем компьютере могут одновременно работать
несколько баз данных, ORACLE предоставляет механизм для
именования процессов инстанции. А именно, имена фоновых
процессов префиксуются идентификатором инстанции, чтобы отличать
друг от друга совокупности процессов для каждой инстанции.
4-10 Руководство администратора
Например, инстанция с именем TEST может иметь фоновые процессы
со следующими именами:
* ORA_TEST_DBWR
* ORA_TEST_LGWR
* ORA_TEST_SMON
* ORA_TEST_PMON
* ORA_TEST_RECO
* ORA_TEST_LCK0
* ORA_TEST_ARCH
* ORA_TEST_D000
* ORA_TEST_S000
* ORA_TEST_S001
Идентификатор инстанции и формат имен процессов ORACLE зависят
от операционной системы; обратитесь к вашему руководству по
инсталляции [IUG].
Файлы трассировки, файл ALERT и фоновые процессы
------------------------------------------------
Каждый серверный или фоновый процесс может вести запись в
ассоциированный с ним ФАЙЛ ТРАССИРОВКИ. Когда процесс встречает
внутреннюю ошибку, он записывает сообщение об этой ошибке в свой
файл трассировки. Часть информации, попадающей в файл
трассировки, предназначена для вас, как АБД; другая часть
предназначена для службы сопровождения Oracle. Информацию
файлов трассировки часто можно использовать для настройки
приложений и инстанций. (Для дополнительной информации об
ошибках и сообщениях обратитесь к документу ORACLE7 Server
Messages and Codes Manual.)
Существует один специальный файл трассировки, называемый файлом
ALERT. Файл ALERT базы данных представляет собой
хронологический журнал сообщений и ошибок, включая:
* все внутренние ошибки (ORA-600), ошибки о запорченных
блоках (ORA-1578) и сообщения о захватах (ORA-60)
* административные операции, такие как предложения SQL
CREATE/ALTER/DROP DATABASE/TABLESPACE/ROLLBACK SEGMENT и
команды SQL*DBA STARTUP, SHUTDOWN, ARCHIVELOG и RECOVER
* некоторые сообщения и ошибки, относящиеся к функциям
разделяемых серверов и диспетчерских процессов
* ошибки во время автоматического освежения снимков
* значения параметров инициализации в момент запуска базы
данных и инстанции
Управление процессами ORACLE 4-11
ORACLE использует файл ALERT для ведения журнала этих
специальных операций, как альтернативу выдаче такой информации
на консоль оператора (хотя многие системы выдают такую
информацию на консоль). Если операция выполняется успешно, она
записывается в файл ALERT как "завершенная" вместе с отметкой
времени.
Использование файлов трассировки
Вы можете периодически проверять файл ALERT и другие файлы
трассировки инстанции, чтобы выяснить, не встретились ли ошибки
в фоновых процессах. Например, когда процесс LGWR не может
осуществить запись в член группы журнала, сообщение об ошибке
записывается в файл трассировки процесса LGWR и в файл ALERT.
Если вы увидите такие сообщения об ошибках, это значит, что
встречена проблема носителя или ввода-вывода, которую вы должны
немедленно исправить.
Кроме того, ORACLE записывает в файл ALERT значения параметров
инициализации и другую важную статистику. Например, когда вы
нормально или немедленно закрываете инстанцию (но не снимаете
ее), ORACLE записывает в файл ALERT наибольшее число сессий,
которые были присоединены за время жизни инстанции; на основе
этого вы можете определять, не пора ли вам повышать лицензионное
соглашение с ORACLE. (См. "Лицензирование по числу сессий и
пользователей" на странице 11-2.)
Спецификация местоположения для файлов трассировки
Все файлы трассировки для фоновых процессов и файл ALERT пишутся
в назначение, устанавливаемое параметром инициализации
BACKGROUND_DUMP_DEST. Все файлы трассировки для серверных
процессов пишутся в назначение, устанавливаемое параметром
инициализации USER_DUMP_DEST. Имена файлов трассировки зависят
от операционной системы; обычно они включают имя процесса,
ассоциированного с файлом (такое как LGWR или RECO). Для
дополнительной информации обратитесь к вашему руководству по
инсталляции [IUG].
Управление размерами файлов трассировки
Максимальный размер каждого файла трассировки (за исключением
файла ALERT) можно контролировать через параметр инициализации
MAX_DUMP_FILE_SIZE. Этот лимит задается как число блоков
операционной системы. Чтобы контролировать размер файла ALERT,
вы должны просто периодически вручную удалять этот файл, когда
он не нужен; в противном случае ORACLE продолжает вести запись в
конец этого файла. (Вы можете без всякой опасности удалять этот
файл во время работы инстанции, хотя вы можете пожелать сначала
сделать его запасную копию.)
Управление режимом записи в файлы трассировки
Фоновые процессы всегда пишут в файл трассировки, когда это
необходимо. Однако серверные процессы ведут запись в свои файлы
трассировки (помимо сообщений о внутренних ошибках) лишь в том
случае, когда параметр инициализации SQL_TRACE установлен в
TRUE.
Однако, независимо от текущего значения этого параметра, каждая
сессия может включать или отключать трассировку от имени
4-12 Руководство администратора
ассоциированного серверного процесса с помощью команды SQL ALTER
SESSION с параметром SET SQL_TRACE. Например, следующее
предложение включает запись в файл трассировки для сессии:
ALTER SESSION SET SQL_TRACE TRUE;
Для многоканального сервера, ввиду того, что каждая сессия,
использующая диспетчер, направляется к разделяемому серверному
процессу, информация трассировки записывается в файл трассировки
этого сервера лишь в том случае, если сессия включила режим
трассировки (или если встречена ошибка). Поэтому для того,
чтобы отследить трассировку для конкретной сессии, соединенной
через диспетчер, вам может понадобиться просмотреть несколько
файлов трассировки для нескольких разделяемых серверов.
Поскольку средство трассировки SQL для серверных процессов может
вызвать значительные накладные расходы системы, включайте это
средство лишь на время сбора статистики.
Для полной информации о команде ALTER SESSION обратитесь к
документу ORACLE7 Server SQL Language Reference Manual.
Запуск процесса контрольной точки
---------------------------------
Если процесс контрольной точки (CKPT) не присутствует, то
процесс LGWR отвечает за обновление заголовков всех управляющих
файлов и файлов данных, чтобы отразить последнюю контрольную
точку. Чтобы сократить время, необходимое для выполнения
контрольной точки, особенно когда база данных состоит из
большого количества файлов, запустите процесс CKPT.
Чтобы сделать это, установите параметр CHECKPOINT_PROCESS в
файле параметров базы данных в TRUE. (Его умалчиваемое значение
есть FALSE.)
----------------
Снятие сессий
В некоторых ситуациях вы можете захотеть снять (убить) текущие
пользовательские сессии. Например, вам может потребоваться
выполнить административную операцию, и необходимо срочно снять
все неадминистративные сессии.
Снимайте текущую сессию либо через диалоговое окно Kill User
Session в SQL*DBA, либо командой SQL ALTER SYSTEM с параметром
KILL SESSION. Рис.4-3 показывает диалог Kill User Session.
Управление процессами ORACLE 4-13
Рис.4-3
Диалог Kill User Session
---------------------------------------------------------------¬
¦ File Edit Session Instance Storage Log Backup Security¦
¦--------------------------------------------------------------+
¦¦ ¦
¦¦ г=========== Kill User Session =============¬ ¦
¦¦ ¦ ¦ ¦
¦¦ ¦ Session# Serial# Username ¦ ¦
¦¦ ¦ ----------------------------------------¬ ¦ ¦
¦¦ ¦ ¦ 000009 00237 SYS ¦ ¦ ¦
¦¦ ¦ ¦ 000014 00285 SCOTT ¦ ¦ ¦
¦¦ ¦ ¦ ¦ ¦ ¦
¦¦ ¦ ¦ ¦ ¦ ¦
¦¦ ¦ ¦ ¦ ¦ ¦
¦¦ ¦ L---------------------------------------- ¦ ¦
¦¦ ¦-------------------------------------------¦ ¦
¦¦ ¦ Mandatory (OK) (Cancel) ¦ ¦
¦¦ L===========================================- ¦
¦¦ ¦
¦L-------------------------------------------------------------+
¦--------------------------------------------------------------+
¦¦ ¦
¦¦ ¦
¦L-------------------------------------------------------------+
L---------------------------------------------------------------
Следущее предложение является командным эквивалентом диалога
Kill User Session, показанного на рис.4-3:
ALTER SYSTEM KILL SESSION '7,15';
Для идентификации убиваемой сессии укажите ее индексный номер и
ее серийный номер. Чтобы определить индексный номер (SID) и
серийный номер сессии, опросите динамическую таблицу
производительности V$SESSION. Например, следующий запрос
идентифицирует все сессии для пользователя JWARD:
SELECT sid, serial#
FROM v$session
WHERE username ='JWARD';
SID SERIAL#
--------- ---------
7 15
Когда сессия снимается, ресурсы, удерживаемые ею (такие как
блокировки и области памяти), немедленно освобождаются и
становятся доступными другим сессиям.
Если пользовательская сессия активна в момент ее снятия (т.е.
осуществляет вызов ORACLE), то текущая транзакция откатывается,
а пользователь немедленно получает следующее сообщение:
ORA-00028: your session has been killed
(ваша сессия снята)
Если пользовательская сессия не активна в момент ее снятия (т.е.
не осуществляет вызов ORACLE), то это сообщение не возвращается
немедленно, а передается, когда пользователь впоследствии
попытается использовать снятую сессию.
4-14 Руководство администратора
Если после получения сообщения ORA-00028 пользователь пытается
выдавать какие-либо предложения, ORACLE возвращает следующее
сообщение:
ORA-01012: not logged on
(не подключен)
Обзор V$SESSION также показывает состояние (STATUS) текущих
сессий. Строка для снятой сессии удаляется из этого обзора,
когда пользователь получает сообщение ORA-00028.
Следующий пример показывает, как АБД убивает неактивную сессию:
SELECT sid, serial#, status, server
FROM v$session
WHERE username = 'JWARD';
SID SERIAL# STATUS SERVER
---------- ------- -------- ---------
7 15 INACTIVE DEDICATED
ALTER SYSTEM KILL SESSION '7,15';
SELECT sid, serial#, status, server
FROM v$session
WHERE username = 'JWARD';
SID SERIAL# STATUS SERVER
---------- ------- -------- ---------
7 15 KILLED PSEUDO
Если активная сессия не может быть прервана (например, она
выполняет сетевой ввод-вывод или откатывает транзакцию), то
сессия не может быть снята до окончания этой операции. В этом
случае сессия удерживает все свои ресурсы вплоть до снятия.
Кроме того, сессия, выдавшая предложение ALTER SYSTEM для снятия
другой сессии, ожидает снятия сессии до 60 секунд; если
операция, которая не может быть прервана, продолжается дольше
одной минуты, то инициатор предложения ALTER SYSTEM получает
сообщение, указывающее, что сессия была "помечена" для снятия.
Сессия, помеченная для снятия, выдается в обзоре V$SESSION с
состоянием KILLED и с сервером, отличным от PSEUDO.