AWR: насколько «экзадатится» работа базы данных?

[shane54]

Просто интересно, а откуда вообще такая задача «просчитать что будет, если вынести базу обратно на классическую архитектуру»? Ведь обычно же как раз наоборот бывает — «посчитайте нам, на сколько все станет хорошо если перенесём БД на Exa?».

По поводу статьи — все так, и определить вклад я вообще слабо представляю как (чтоб точно) — и роль Exadata Software и плюс ещё и роль Exadata Hardware, с учётом всех этих Flash Cache, Infiniband (и RoCE в X8M) и просто мега-быстрых SSD.

[JetHabr]

Мы тоже думаем, что такая задача возникать не должна, но однако на иногда бывает:)

[xtender]

Не очень понял причем тут AWR… Просто нужные статистики другие и смотреть их можно прямо в том же AWR, например:

col END_INTERVAL_TIME for a20
col stat_name for a64
break on END_INTERVAL_TIME
select 
   to_char(ss.END_INTERVAL_TIME,'yyyy-mm-dd hh24:mi') END_INTERVAL_TIME
   ,st.stat_name
   ,st.value
from dba_hist_snapshot ss
    ,dba_hist_stat_name sn
    ,dba_hist_sysstat st
where
     ss.END_INTERVAL_TIME between systimestamp-interval '24' hour 
                              and systimestamp-interval '23' hour
and ss.dbid = (select dbid from v$database)
and sn.dbid = (select dbid from v$database)
and st.dbid = (select dbid from v$database)
and (st.snap_id,st.dbid,st.instance_number) in (
    (ss.snap_id,ss.dbid,ss.instance_number)
)
and st.stat_id=sn.stat_id
and sn.stat_name like 'cell%'
and (sn.stat_name in (
            'cell session smart scan efficiency' 
           ,'cell physical IO bytes saved by storage index' 
           ,'cell physical IO bytes eligible for predicate offload' 
           ,'cell physical IO interconnect bytes returned by smart scan'
           ,'cell IO uncompressed bytes'
          )
         or
     sn.stat_name like 'cell blocks processed%'
     )
/

[xtender]

Вполне нормальный документ для этого: Smart scan: Find the statistics related to cell offload (Doc ID 1438173.1)

[vlanko]

Я смотрю, что SuperCluster из продажи почти пропал, а Exadata еще жива?

[JetHabr]

Мы наблюдаем вполне эффективную «жизнь» SuperCluster в отдельных местах. Вообще вопрос о SuperCluster — это в первую очередь вопрос про Sparc и заслуживает отдельной статьи. А инновационная система хранения (благодаря которой «экзадатится» работа базы) — у SuperCluster и Exadata одинаковая!

[xtender]

1. Вклад магии Exadata в производительность базы данных не высок — не превышает 5 %, а база данных «экзадатится» плохо.

Ну в общем-то так и есть, если не учитывать криво посчитанный процент:

1. 1 млн ожиданий у смартскана и в сумме всего ~1200сек — пусть даже соффлоудилось идеальные 90%, то это всего будет лишь в ~10 раз больше (плюс-минус из-за погрешности в переходе к cell multiblock/singleblock block read + увеличение объема пересылки + в худшем случае — построчные фильтры) — итого ну пусть даже в 20 раз больше — 24к сек — совсем пустяки.

   
   

2. IO действительно мало, а прочие два ожидания (cell single block/multiblock physical read) собственно и не оффлоудятся. В крайних случаях, это, конечно, может привести к тяжелым проблемам, например, если кол-во сессий в этой системе маленькое и они просто кучу данных молотят 100% времени, затыкаясь в притык по SLA — в таком случае — да, небольшое замедление может привести к проблемам, но в прочих реально многопользовательских системах с таким перекосом в CPU (непонятно еще как оно распределено было и что в бэкграунде творилось), будет лишь незначительное замедление IO, но никак не упрется в его лимиты. Если из этих 70% DBTime лишь микрозапросы по кэшам, PL/SQL да прочие числомолотилки — то smartscan/не смартскан — что слону дробина

   
   

[JetHabr]

Спасибо за мнение! Получается, что пост написан не зря. Если сравнивать между собой статистики секции «Instance Activity Stats» («physical read total bytes», «cell physical IO bytes eligible for predicate offload», «cell physical IO interconnect bytes returned by smart scan» и так далее), то выходит, что по крайней мере за эти сутки вклад магии Exadata в общий Performance был внушительный, не меньше половины. Точно больше 5%!