Вот, наконец, и настал новый 2004 год! Всем желаю, всех благ и чтобы у всех Орклоидов и не только, сбылись все мечты и все желания! Я наконец вернулся из небольшой, но весьма насыщенной событиями поездки и думаю продолжить наши с вами занятия БД Oracle. :) Кто-нибудь там с галерки может быть, напомнит нам, на чем мы остановились!? Тишина ... ну, что ж тогда напомню, что мы с вами остановились, на разборе процесса транзакции. Надеюсь, что всем стало немного понятнее как она работает. И мы с вами в плотную подошли к теме простых приемов мониторинга, нашего с вами экземпляра БД Oracle.
Итак, давайте попробуем разобраться. Мониторинг БД, как правило, бывает необходим в силу ряда причин, одной из которых, может быть возникновение разнообразных сбоев и неполадок. Так, например, при работе БД создает файлы трассировки процессов, по которым легко определить основные неполадки при функционировании экземпляра БД. Располагаются эти файлы согласно параметров USER_DUMP_DEST и BACKGROUND_DUMP_DEST в файле init.ora. Когда определенный фоновый процесс прерывается или какая-либо операция завершается неудачно, происходит формирования файла трассировки процесса. При этом в него сразу записывается информация о возникшей ошибке. Далее администратор БД, может провести "следствие", выяснив, что же послужило причиной той или иной сбойной ситуации. Либо когда что-то не совсем ясно, может передать файл трассировки в службу Oracle World Wide Web Customer Support, где ему помогут разобраться с данной проблемой. Так же существует файл alert.log, в который записывается информация при аварийном прерывании какого-либо фонового процесса, что так же не маловажно для администратора БД. Вообще по большому счету, чем лучше ваш Администратор БД понимает и представляет функционирование сервера Oracle, тем меньше вероятности, что вы лишитесь вашей ценной информации! :) Но, это так к слову. Одним из немаловажных выводов, который можно сделать из прошлых шагов это то, что, собственно, устойчивое функционирование БД в основном определяется правильной и безотказной работой фоновых процессов БД. Ранее мы с ними уже успели познакомится, по этому повторяться не буду.
А получить информацию о работе фоновых процессов можно при помощи команд операционной системы. Так, например, в OS UNIX каждый фоновый процесс Oracle представляет собой отдельную задачу - task. Полезно рассматривать информацию, которую предоставляет ваша ОС относительно использования задачей памяти и процессора. Например, в OS UNIX это команды, sar, ps, vmstat, top. Но OS UNIX - это отдельная тема, а мы с вами более детально рассматриваем Windows NT. А, вот здесь картина более утонченная. :) Все дело в том, что весь экземпляр БД Oracle в данной ОС выполнен как единый фоновый процесс (интересная формулировка, не правда ли, экземпляр - фоновый процесс) самой ОС и называется - сервисом. А, вот те самые фоновые процессы БД, в данном случае выполнены в NT как потоки. Они находятся внутри самого сервиса собственно экземпляра БД и ведут постоянное взаимодействие с ним. В самой NT имеется множество средств для трассировки и мониторинга сервисов. А средства администрирования потоков здесь несколько сложнее. Одним из средств мониторинга потоков может служить Performance Monitor. С его помощью можно анализировать использование памяти и переключателей контекста для всех потоков, которые принадлежат данному сервису. Эта утилита обычно штатная для NT. Для примера давайте дадим вот такой запрос:
SELECT a.spid, b.name FROM v$process a, v$bgprocess b WHERE a.addr = b.paddr /
Получаем:
SQL> SELECT a.spid, b.name FROM v$process a, v$bgprocess b 2 WHERE a.addr = b.paddr 3 / SPID NAME ------------ ----- 1284 PMON 1400 DBW0 964 LGWR 1424 CKPT 1428 SMON 1416 RECO 1436 CJQ0 1464 QMN0 8 строк выбрано.
Теперь, если перевести десятичный столбец SPID в шестнадцатеричный, то можно получить соответствие идентификатора потока NT с фоновым процессом Oracle. Что-то вроде вот этого:
SPID(HEX) NAME ------------ ----- 504 PMON 578 DBW0 3C4 LGWR 590 CKPT 594 SMON 588 RECO 59C CJQ0 5B8 QMN0
У вас эти значения могут быть другими, но это не важно. Я понимаю, что данная информация немного суховатая, но необходимая для понимания и освоения нашей с вами цели, по этому пока отдохните и продолжим в следующий раз. :)