Дек 072012
 

Пару дней назад разработчик отлаживал некое приложение и обнаружив в файле трассировки странное явление, обратился ко мне. Приложение тормозило на вставке строк в таблицу, а в трейсе было вот что:

select file#, block# 
from
 seg$ where type# = 3 and ts# = :1


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse       48      0.00       0.00          0          0          0           0
Execute     48      0.02       0.01          0          0          0           0
Fetch       48      7.93       7.78          0     699504          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total      144      7.95       7.80          0     699504          0           0

Из 8 секунд ожидания 7.78 секунды занимал этот запрос, причём на другой схеме, находящейся в другом табличном пространстве, ничего подобного не происходило. Версия БД - 10.2.0.4.

Анализ я начал с определения структуры системной таблицы seg$. Найти её можно в файле $ORACLE_HOME/rdbms/admin/sql.bsq. Приводить её тут не вижу смысла ввиду громоздкости, скажу лишь что по своей структуре это сырые данные для представления DBA_SEGMENTS, и даже количество строк в DBA_SEGMENTS и seg$ в точности совпадает. type# = 3 - это сегмент типа TEMPORARY. Трассировка была 12 уровня (повезло), и поэтому удалось узнать значение бинда :1. Имя табличного пространства с этим номером я узнал из таблицы $ts. Это было DEFAULT TABLESPACE схемы.

Что же получается: сессия усиленно ищет временные сегменты в родном табличном пространстве перед вставкой. Сделав спекулятивное предположение, что это может быть как-то связано с поиском свободного места, я проверил, сколько места осталось в этом пространстве и в пространстве схемы, в которой всё работало нормально. Предположение оказалось верным: в нашей схеме оставались свободными считанные мегабайты. После очистки места путём удаления ненужных таблиц (разработчики не всегда убирают за собой), приложение заработало с нормальной скоростью.

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

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre lang="" line="" escaped="" cssfile="">

(обязательно)

(обязательно)