| Предыдущая |
Основным протоколом работы Oracle является alertSID.log. Он обычно располагается в $ORACLE_HOME/admin/SID/bdump
bash$ less /oracle/admin/SMAP/bdump/alert_SMAP.log
Shutting down instance (normal)
License high water mark = 1
Fri Nov 9 16:04:27 2001
ALTER DATABASE CLOSE NORMAL
Fri Nov 9 16:04:27 2001
SMON: disabling tx recovery
SMON: disabling cache recovery
Fri Nov 9 16:04:28 2001
Thread 1 closed at log sequence 1299
Fri Nov 9 16:04:28 2001
Completed: ALTER DATABASE CLOSE NORMAL
Fri Nov 9 16:04:28 2001
ALTER DATABASE DISMOUNT
Completed: ALTER DATABASE DISMOUNT
archiving is disabled..............
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
LICENSE_MAX_USERS = 0
Starting up ORACLE RDBMS Version: 8.1.7.0.0.
System parameters with non-default values:
processes = 150
shared_pool_size = 6428800
large_pool_size = 614400
java_pool_size = 10097152
..............................................
Т.е. содержит протокол всех жизненно важных для БД процессов. При наличии ошибок в работе БД записи о них обязательно появляются в alert.log
В двух директориях ORACLE_HOME/admin/SMAP/bdump и ORACLE_HOME/admin/SMAP/cdump могут находиться дополнительные trace логи. Если по времени они совпадают с возникновением ошибки их лучше прислать в support вместе со подозрительными строчками из aler.log
Заметим, что в alert.log может встречаться ошибка
"Restarting dead background process EMN0"
Ее можно смело игнорировать.
Несмотря на то что Oracle, как правило, не занимается большими математическими вычислениями, процессы много читающие с диска могут серьезно загружать CPU вашей системы. Чтобы быстро определить "кто виноват" можно воспользоваться программой top
bash$ /usr/local/bin/top
last pid: 661; load averages: 2.04, 0.04, 0.20
38 processes: 36 sleeping, 1 running, 1 on cpu
CPU states: 100% idle, 0.0% user, 0.0% kernel, 0.0% iowait, 0.0% swap
Memory: 128M real, 1904K free, 135M swap in use, 457M swap free
PID USERNAME THR PRI NICE SIZE RES STATE TIME CPU COMMAND
643 oracle 11 32 0 157M 40M sleep 0:05 56.00% oracle
213 root 8 53 0 2984K 1760K sleep 0:01 10.00% nscd
319 root 4 58 0 5096K 1472K sleep 0:01 0.00% dtlogin
286 root 1 58 0 1016K 576K run 0:00 0.00% utmpd
63 root 5 13 0 1984K 712K sleep 0:00 0.00% picld
197 root 1 23 0 2392K 904K sleep 0:00 0.00% in.telnetd
52 root 7 32 0 1256K 592K sleep 0:00 0.00% devfseventd
178 daemon 4 40 0 2488K 1032K sleep 0:00 0.00% statd
194 root 9 42 0 4504K 1424K sleep 0:00 0.00% syslogd
54 root 3 42 0 2296K 624K sleep 0:00 0.00% devfsadm
176 root 1 45 0 2416K 832K sleep 0:00 0.00% inetd
348 oracle 1 48 0 2480K 1064K sleep 0:00 0.00% bash
298 root 5 48 0 2608K 1032K sleep 0:00 0.00% vold
212 oracle 1 48 0 1384K 1000K sleep 0:00 0.00% bash
Как видно из картинки, действительно существуют процессы занимающие львиную долю процессорного времени и принадлежащие пользователю oracle. Это так называемые backgroud процессы (о них рассказывалось в 1 главе)
Чтобы понять чем занимается это процесс воспользуемся скриптом sinner.sql
bash$ sqlplus sys/manager @sinner 643
JServer Release 8.1.7.0.0 - Production
SID USERNAME OSUSER
---------- ------------------------------ ------------------------------
LOGON_TIME
--------------
21 SMAP2 pavel
09-nov 19:03
WHICH EXECUTIONS PARSE_CALLS SORTS BUFFER_GETS DISK_READS
--------- ---------- ----------- ---------- ----------- ----------
SQL_TEXT
--------------------------------------------------------------------------------
Current 145 302 151 1001 20
select id from admin_page_acl where id = :id
Previous 145 302 151 1001 20
select id from admin_page_acl where id = :id
WHICH SQL_TEXT
--------- ----------------------------------------------------------------
Current select id from admin_page_acl where id = :id
Previous select id from admin_page_acl where id = :id
Вывод скрипта и экран программы top вместе с описанием проблемы следует прислать в службу технической поддержки.
Мониторинг свободной памяти удобнее всего производить утилитой операционной системы vmstat.
bash$ vmstat 2 procs memory page disk faults cpu r b w swap free re mf pi po fr de sr dd -- -- -- in sy cs us sy id 0 0 0 481744 19088 2 1 27 9 10 0 1 4 0 0 0 119 69 58 1 0 98 0 0 0 480200 9184 0 3 0 0 0 0 0 1 0 0 0 121 33 65 0 0 100 0 0 0 480200 9184 0 0 0 0 0 0 0 1 0 0 0 118 35 54 0 0 100 0 0 0 480200 9184 0 0 0 0 0 0 0 0 0 0 0 112 3 49 0 0 100
Нас интересуют колонки раздела memory: swap & free. Колонка free показывает реальное кол-во свободной памяти на машине. И это число должно быть в районе нескольких мегабайт непрерывно. Колонка swap показывает кол-во используемой swap памяти. Слишком большое кол-во говорит о наличии приложений из-за которых операционная система вынуждена производить swapping.
Данные мониторинга wmstat во время возникновения проблем следует прислать в службу технической поддержки.
Мониторинг дисковой активности можно произвести двумя способами - с помощью утилит операционной системы и с помощью скрипта diskperc.sql
Воспользуемся программой iostat
bash$ iostat -npxtdc 2
tin tout us sy wt id
0 458 0 0 0 100
extended device statistics
r/s w/s kr/s kw/s
wait actv wsvc_t asvc_t %w %b device
0.0 1.5 0.0
12.0 0.0 0.0 0.0 0.4
0 0 c0t0d0
0.0 0.0
0.0 0.0 0.0 0.0
0.0 0.0 0 0 c0t0d0s0
0.0 0.0
0.0 0.0 0.0 0.0
0.0 0.0 0 0 c0t0d0s1
0.0 0.0
0.0 0.0 0.0 0.0
0.0 0.0 0 0 c0t0d0s2
0.0 0.0
0.0 0.0 0.0 0.0
0.0 0.0 0 0 c0t0d0s3
0.0 0.0
0.0 0.0 0.0 0.0
0.0 0.0 0 0 c0t0d0s4
0.0 0.0
0.0 0.0 0.0 0.0
0.0 0.0 0 0 c0t0d0s5
0.0 0.0
0.0 0.0 0.0 0.0
0.0 0.0 0 0 c0t0d0s6
0.0 1.5 0.0
12.0 0.0 0.0 0.0 0.4
0 0 c0t0d0s7
r/s reads per
second
w/s writes per
second
Kr/s kilobytes read per
second
Kw/s kilobytes written
per second
Связь между именами устройств и файлами Oracle рассматривалась в разделе 2.
Воспользуемся скриптом diskperc.sql
bear% sp sys/manager @diskperc.sql
NAME PHYRDS READ_PCT PHYWRTS WRITE_PCT
-------------------------------------------------- ------------ -------- ------------ ---------
/jet/oracle/oradata/tayga/system01.dbf 176,937 75.29 133,647 95.69
/oracle/oradata/smap/smap2.dbf 56,520 24.05 61 .04
/jet/oracle/dbs/oradata/smap/smap.dbf 595 .25 1,659 1.19
/jet/oracle/dbs/oradata/smap/smap-messages.dbf 149 .06 164 .12
/jet/oracle/oradata/tayga/rbs01.dbf 113 .05 2,262 1.62
/jet/oracle/oradata/tayga/drsys01.dbf 104 .04 80 .06
/oracle/oradata/smap/smap-messages2.dbf 101 .04 60 .04
/oracle/oradata/smap_indexes01.dbf 73 .03 66 .05
Mon Nov 12 page 2
Disk I/O s by Datafile
NAME PHYRDS READ_PCT PHYWRTS WRITE_PCT
-------------------------------------------------- ------------ -------- ------------ ---------
/jet/oracle/oradata/tayga/tools01.dbf 62 .03 1,067 .76
/jet/oracle/oradata/tayga/temp01.dbf 62 .03 60 .04
/jet/oracle/oradata/tayga/users01.dbf 62 .03 60 .04
/oracle/oradata/des.dbf 62 .03 60 .04
/jet/oracle/oradata/tayga/indx01.dbf 62 .03 60 .04
/oracle/oradata/smap/smap3.dbf 55 .02 306 .22
/oracle/oradata/smap/smap-messages3.dbf 54 .02 54 .04
Мониторинг свободного места производится утилитой операционной системы df, скриптом free_space.sql, и пакетом dba_utils.
Выполним утилиту df, форматируя вывод в килобайтах.
bash$ df -k Filesystem kbytes used avail capacity Mounted on /dev/dsk/c0t0d0s0 123231 46512 64396 42% / /dev/dsk/c0t0d0s6 1424286 445302 922013 33% /usr /proc 0 0 0 0% /proc fd 0 0 0 0% /dev/fd mnttab 0 0 0 0% /etc/mnttab /dev/dsk/c0t0d0s4 492422 9992 433188 3% /var swap 480280 8 480272 1% /var/run swap 480288 16 480272 1% /tmp /dev/dsk/c0t0d0s5 1015542 294674 659936 31% /opt /dev/dsk/c0t0d0s3 2052750 1092374 898794 55% /export /dev/dsk/c0t0d0s7 13533179 3729973 9667875 28% /oradataМы видим, что в /oradata еще достаточно свободного места. Тем не менее это место по умолчанию недоступно Oracle. Посмотрим что реально доступно Oracle
SQL> @free_space
Mon Nov 12 page 1
BYTES TABLESPACE_NAME
-------------------- ------------------------------
20,963,328 INDX
112,189,440 RBS
18,079,744 SMAP
537,559,040 SMAP2
629,137,408 SMAP3
313,090,048 SMAP_INDEXES
Mon Nov 12 page 2
BYTES TABLESPACE_NAME
-------------------- ------------------------------
802,152,448 SMAP_MESSAGES
371,654,656 SMAP_MESSAGES2
943,710,208 SMAP_MESSAGES3
1,571,291,136 SYSTEM
20,963,328 TEMP
4,743,168 TOOLS
20,963,328 USERS
Достаточно места как в system, так и в smap* таблеспайсах.
Но нужно помнить, что таблицы и индексы могут резервировать место под будущие записи, и это место показывается занятым сразу, вне зависимости от наличия реальных данных в них. Поэтому более глубокий анализ свободного или занятого места производиться следующим образом:
SQL> set serveroutput on;
SQL> exec smap_dba.dba_utils.show_space ('MESSAGE');
Free Blocks :3
Total Blocks :29440
Total Bytes :241,172,480
Unused Blocks :165
Unused Bytes :1,351,680
Last Used Ext FileId :11
Last Used Ext BlockId:192692
Last Used Block :475
Free Blocks + Unused Blocks - показывает сколько свободного места существует в таблице.
Предыдущая |
Mailto: dsvolk