http___blog.yavor.info__p_2088_1.xml
http___blog.yavor.info__p_2091_lang_en.xml
1.1 2.1 2.2 2.3 3.1 3.2 4.1 5.1 5.2 5.3 6.1 7.1 7.2 7.3 7.4 8.1 9.1 10.1 10.2 11.1 12.1 13.1 14.1 14.2 14.3 14.4 14.5 14.6 15.1 15.2 15.3
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) ще оцени такъв довод.
1.1 2.1 2.2 2.3 3.1 3.2 4.1 5.1 5.2 5.3 6.1 7.1 7.2 7.3 7.4 7.5 8.1 9.1 10.1 10.2 11.1 12.1 13.1 14.1 14.2 14.3 14.4 14.5 14.6 14.7 15.1 15.2 15.3
This post is also available in: Bulgarian Sooner or later, the year ends. Again, it’s time to do some reports, to plan a budget, to say “The overall performance of our database is this and this”. But how to find this data? As I have told already, we keep AWR reports for very long period. One I calculated the database space usage growth, in order to plan the storage needs; now I need tha database server load. 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 This query is a tricky one. It gives the average load (DB time) for every month in the last 2 years, if you keep such amount of snapshots. If you keep only one month, you can report by day - it it is not that impressive. One of the detail worth mentioning is, DB time (just like every system stat) is an ever growing number, counted since the instance restart. The query takes the value for every snapshot and subtracts the value of the former snapshot. If the instance is restarted, the number is negative - because the counter starts form zero. To build proper stats, I simply skip such numbers. Instance restart happens so rarely, so I think it cannot influence the stats so much. 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 The next thing I do in the query is sum the numers by day, and get he average for each month. To be honest, the query took me quite a while to create. If you see some error, please share your thoughts in the comments below Once I have the data, I draw a graph in Excel - one line for DB time, one for DB CPU ( where tm.stat_name = 'DB CPU') and, to put some business context - number of business transactions for the month (which represents the actual, real-world "work done"). The I show to the Bug Boss how we do more and more actual work, but manage to keep the database load almost constant. In some months there's even decrease in the load - great example for the optimizations done. For example, we we have enabled result cache for some queries, this was easy to see on the graph; optimizations to the stats gathering procedure was also easily seen. The good admins alway suffer from lack of visibility of their efforts. It's hard to show the lack of problems. So a graph like this speaks the same language as the people which decide on salaries and head count. Another interesting graph is the growth over some period - e.g. a year. "During Jan 2014 we made X% more payments through our system compared to Jan 2013, but the database server load growth is only Y%". Every manager aware of Oracle's CPU license cost will understand that this means.