This post is also available in: English
Рано или късно годината приключва. Трябва да се правят отчети, бюджети, трябва да кажем „нашите бази се държаха така и така през годината“. От къде да вземем тези данни?
Както съм казвал и преди, при нас пазим AWR репорти за доста време назад. Едно време смятах от тях как расте базата, за да си планираме storage; сега смятам и как расте натоварването.
select trunc(this_day, 'MONTH'), avg(day_db_time), sum(cnt) scnt
from (select this_day, count(1) cnt,
sum(case
when snap_db_time > 0 then
snap_db_time/1000/1000/60/60/24
else
null
end) day_db_time
from (select trunc(begin_interval_time) this_day, tm.snap_id,
value - lag(value, 1) over(order by tm.snap_id) snap_db_time
from dba_hist_sys_time_model tm, dba_hist_snapshot s
where tm.stat_name = 'DB time'
and s.snap_id = tm.snap_id
and s.begin_interval_time > add_months(trunc(sysdate, 'YEAR'), -24)
and s.begin_interval_time < trunc(sysdate, 'MONTH')
)
group by this_day)
group by trunc(this_day, 'MONTH')
order by 1
Това query е доста коварно. В крайна сметка дава средното натоварване (DB time) по месеци за последните 2 години, ако имате толкова awr данни. Който пази само месец, може да си го направи по дни.
Един от тънките моменти е, че DB time (както всяка системна статистика) е постоянно нарастваща величина, която се отчита от стартирането на instance. Заявката взема стойността от всеки snapshot и от нея вади стойността предишния. Ако случайно имате restart на instance, се получава отрицателно число - защото брояча започва от нула. За нуждата на грубата статистика такива данни просто ги пропускам, понеже ни се случват адски рядко и не могат да повлияят значително.
SQL> select sysdate, startup_time, trunc(sysdate-startup_time) Days_since_restart from v$instance; SYSDATE STARTUP_T DAYS_SINCE_RESTART --------- --------- ------------------ 05-FEB-14 19-FEB-13 350
Сумирам данните по дни, после взимам средната стойност за месеца.
Честно казано трябваше ми известно време за да осмисля и подкарам правилно заявката. Ако някой забележи грешка в нея, моля пишете в коментарите.
Събраните дании чертая в excel - една колонка за DB time, една за DB CPU (where tm.stat_name = 'DB CPU') и за сравнение - броя бизнес транзакции през месеца (за да покажа каква работа сме свършили реално). Много приятно е като изпратя на Големите Шефове как броя транзакции расте, а натоварването в БД почти не се променя. Има и месеци когато натоварването видимо намалява - чудесен пример за оптимизации. Примерно когато пуснахме result cache на някои заявки, веднага се видя в графиката; оптимизацията на процедурата за събиране на статистики също се усети. Добрите администратори винаги имат проблема, че тяхната работа не се вижда от мениджмънта, защото липсата на проблеми е трудно измерима. Една такава графика говори на език, познат за хората, които определят заплати и позиции.
Интересна графика се получава и от "първата производна" - нарастването за една година. "През януари 2014 сме направили Х% повече плащания спрямо януари 2013, а натоварването на на сървърите е нарастнало само с Y%". Всеки мениджър, който знае цената на Oracle licenses (per CPU) ще оцени такъв довод.
P.S. Версия на тази заявка, подходяща за RAC бази има тук
Sorry, the comment form is closed at this time.