http___blog.yavor.info__m_20140205_1.xml
http___blog.yavor.info__p_2118_lang_en.xml
1.1 1.2 1.3 2.1 2.2 3.1 4.1 4.2 4.3 5.1 6.1 6.2 6.3 6.4 7.1 8.1 9.1 9.2 10.1 11.1 12.1 13.1 13.2 13.3 13.4 13.5 13.6 14.1 14.2 14.3 15.1
Рано или късно годината приключва. Трябва да се правят отчети, бюджети, трябва да кажем „нашите бази се държаха така и така през годината“. От къде да вземем тези данни? Както съм казвал и преди, при нас пазим 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) ще оцени такъв довод. Версия на тази заявка, подходяща за RAC бази има тук
1.1 2.1 2.2 3.1 3.2 4.1 5.1 5.2 6.1
This post is also available in: Bulgarian A few days ago I posted a query that returns the average load for given database per day, week or month. Works great on single instance databases, but not in RAC environments RAC databases have one line per instance in DBA_HIST views, so my strategy of subtracting the value from the previous line returns very strange results. So here is the RAC-aware version of the query: 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.instance_number, tm.snap_id) snap_db_time from dba_hist_sys_time_model tm, dba_hist_snapshot s where tm.stat_name = 'DB CPU' and s.snap_id = tm.snap_id and s.instance_number = tm.instance_number 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 The only difference is, I'm careful which is the instance on the previous line. This statement works also on single-instance databases. Sorry, the comment form is closed at this time.