юни 102010
 

This post is also available in: English

Много полезно, за всички, които си пазят AWR snapshots за по-дълъг период от време. От тази таблица може да се изкара trend за нарастването на базата. Примерно по месеци изглеждат така:

select tsu.snap_id, to_char(sn.mon, 'Mon.YYYY'), round(sum(tsu.tablespace_size * nvl(ts.blocksize, p.value))/1024/1024/1024, 2) GB_size
  from dba_hist_tbspc_space_usage tsu,
       sys.ts$ ts,
       v$parameter p,
       (select trunc(begin_interval_time, 'MONTH') Mon, min(snap_id) snap_id
          from dba_hist_snapshot
         group by trunc(begin_interval_time, 'MONTH')) sn
 where p.name = 'db_block_size'
   and tsu.tablespace_id = ts.ts#(+)
   and sn.snap_id = tsu.snap_id
 group by tsu.snap_id, sn.mon
 order by 1

Този SQL идва с няколко забележки:
– малко ми е тъпо размера на tablespace да се пази в блокове, а не байтове. Отне ми известно време да схвана какви са числата. Документацията не помага много 🙂
– ако в миналото е имало tablespace, който в последствие е drop-нат, се приема, че е бил с default-ния block size. Аз, лично не намерих друг начин
– още нещо леко тъпо: v$tablespace няма изведена колонка blocksize, докато dba_tablespaces няма ts#. Заради тази… хм… неконсистентност в поведението, предпочетох да използвам директно sys.ts$. На който не му харесва това, може да си ги join-не по tablespace_name

 Posted by at 11:15

  2 Responses to “dba_hist_tbspc_space_usage”

  1. Не работи когато си на raw devices. Показва винаги едно и също число.

  2. Здрасти Явор,

    Скрипта е много полезен. Ползвам го понякога :).
    Бях попитан от клиенти кои бази са кандидати за дедикейтнати файбър карти за бекъп на ленти (със сегашните 1 гбит ланки 1ТБ отнема 10 часа) . Общото в случая беше че всички се връзват към рекавъри каталог бази. Поиграх да разгледам взевъзможните RC_RMAN* and RC_BACKUP* вюта и случайно забелязах че колонката „инпут байтс“ дава точна статистика как е нараснала базата съответно ELAPSED_SECONDS колко секунди се е „влачил“ бекъп джоба.

    използвам RC_RMAN_BACKUP_JOB_DETAILS

    set pages 2000 lines 200
    COL STATUS FORMAT a9
    COL hrs FORMAT 999.99
    select INPUT_BYTES/1024/1024/1024,SESSION_KEY,DB_NAME,INPUT_TYPE,TO_CHAR(START_TIME,’DDMonYY HH24′) start_time,ELAPSED_SECONDS/3600 hrs from RC_RMAN_BACKUP_JOB_DETAILS
    where trunc(start_time) >= to_date(’06/21/2011′ ,’mm/dd/yyyy’) and INPUT_TYPE like ‘DB%’ and INPUT_BYTES/1024/1024/1024 > 200
    order by DB_NAME,SESSION_KEY;

    Поздрави
    Огнян Истатков

Sorry, the comment form is closed at this time.