{"id":6338,"date":"2021-09-07T23:07:57","date_gmt":"2021-09-07T23:07:57","guid":{"rendered":"https:\/\/swiv.com.br\/describing-time-model-views\/"},"modified":"2026-05-27T20:02:29","modified_gmt":"2026-05-27T19:02:29","slug":"describing-time-model-views","status":"publish","type":"post","link":"https:\/\/swiv.com.br\/index.php\/2021\/09\/07\/describing-time-model-views\/","title":{"rendered":"Describing Time Model views"},"content":{"rendered":"

Como descrito no \u00faltimo artigo (link AQUI<\/a>), a Time Model \u00e9 um conjunto de estat\u00edsticas que descrevem quais itens da DB Time est\u00e1 sendo gasto do banco de dados. Podemos ver suas informa\u00e7\u00f5es nas views V$SYS_TIME_MODEL e V$SESS_TIME_MODEL. Os dados dessas views s\u00e3o acumulados desde o startup da inst\u00e2ncia (em microsegundos), em uma estrutura hier\u00e1rquica (que tem a DB Time no topo). Como benef\u00edcios do seu uso, temos uma vis\u00e3o geral do workload do ambiente. Por exemplo: caso a porcentagem de DB Waits seja maior que 50% da DB Time, podemos ter uma indica\u00e7\u00e3o de baixa performance. Obviamente, esse valor em % n\u00e3o \u00e9 definido assim, pois isso pode variar de ambiente para ambiente. Outro benef\u00edcio \u00e9 comparar esses n\u00fameros ap\u00f3s uma manuten\u00e7\u00e3o, como aumento de mem\u00f3ria no servidor, para saber se a carga no banco ficou melhor ou pior. Por \u00faltimo, caso seja identificado um componente com alta porcentagem, pode ser um gargalo de performance no ambiente, permitindo assim a nossa investiga\u00e7\u00e3o.<\/p>\n\n\n

Segue abaixo a hierarquia citada, separada em 2 grupos: DB Time e Background Elapsed Time. Este segundo grupo n\u00e3o \u00e9 contemplado na DB Time, pois ela considera apenas os processos Foreground. Mas ele \u00e9 considerado na Time Model por uma raz\u00e3o: processos RMAN, pois os mesmos consomem bastante recurso:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Com a consulta abaixo, podemos verificar os dados da Time Model, j\u00e1 convertidos em Segundos. Em suma, a DB Time est\u00e1 em 36 segundos, dos quais 3 segundos foram investidos na DB CPU. Baseado nisso, podemos considerar que o tempo do banco aguardando recursos (DB Waits) foi de 33 segundos:<\/p>\n\n\n

\nCOL STAT_NAME FORMAT A43\nSELECT STAT_NAME, TO_CHAR(VALUE,'999,999,999,999') TIME_MICRO_S\nFROM V$SYS_TIME_MODEL\nWHERE VALUE &lt;>0 AND STAT_NAME NOT IN ('background elapsed time', 'background cpu time') \nORDER BY VALUE DESC\nFETCH FIRST 7 ROWS ONLY;\n<\/pre><\/div>\n\n
\n[oracle@oel7 ~]$ sqlplus \/ as sysdba\n \nSQL*Plus: Release 19.0.0.0.0 - Production on Tue Sep 7 19:38:44 2021\nVersion 19.3.0.0.0\n \nCopyright (c) 1982, 2019, Oracle.  All rights reserved.\n \n \nConnected to:\nOracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production\nVersion 19.3.0.0.0\n \nSQL> COL STAT_NAME FORMAT A43\nSQL> SELECT STAT_NAME, TO_CHAR(VALUE\/1000000,'999,999') TIME_S\nFROM V$SYS_TIME_MODEL\nWHERE VALUE &lt;>0 AND STAT_NAME NOT IN ('background elapsed time',\n'background cpu time')\nORDER BY VALUE DESC\nFETCH FIRST 7 ROWS ONLY;  2    3    4    5    6\n \nSTAT_NAME                                   TIME_S\n------------------------------------------- --------\nDB time                                           36\nsql execute elapsed time                          22\nparse time elapsed                                 7\nhard parse elapsed time                            7\nDB CPU                                             3\nPL\/SQL compilation elapsed time                    1\nconnection management call elapsed time            1\n \n7 rows selected.\n<\/pre><\/div>\n\n\n
J\u00e1 a consulta abaixo nos reporta os dados da V$SESS_TIME_MODEL, que nos permite identicar os processos que est\u00e3o consumindo mais DB Time:<\/p>\n\n\n
\ncol SID format 999999\ncol USERNAME format a10\ncol DBTIME format 9999999999999\ncol WAITTIME format 9999999999999\ncol WAITPCT format 99999.99\ncol ONCPUPCT format 99999.99\nSELECT M.SID, S.USERNAME\n           ,VALUE DBTIME\n           ,WAITTIME WAITTIME\n           ,ROUND((WAITTIME\/VALUE)*100,2) WAITPCT\n           ,ROUND(((VALUE-WAITTIME)\/VALUE)*100,2) ONCPU_PCT\n      FROM(SELECT SID, STAT_ID, STAT_NAME ,VALUE\n            ,VALUE - (LEAD(VALUE,1) OVER(PARTITION BY SID ORDER BY SID,STAT_NAME DESC)) WAITTIME\n           FROM V$SESS_TIME_MODEL\n           WHERE STAT_NAME IN ('DB time','DB CPU')) M,\n           V$SESSION S\nWHERE M.SID = S.SID\n      AND STAT_NAME='DB time' AND WAITTIME>0\nORDER BY WAITPCT DESC;\n<\/pre><\/div>\n\n
\nSQL> col SID format 999999\ncol USERNAME format a10\ncol DBTIME format 9999999999999\ncol WAITTIME format 9999999999999\ncol WAITPCT format 99999.99\ncol ONCPUPCT format 99999.99\nSELECT M.SID, S.USERNAME\n           ,VALUE DBTIME\n           ,WAITTIME WAITTIME\n           ,ROUND((WAITTIME\/VALUE)*100,2) WAITPCT\nSQL>            ,ROUND(((VALUE-WAITTIME)\/VALUE)*100,2) ONCPU_PCT\n      FROM(SELECT SID, STAT_ID, STAT_NAME ,VALUE\n            ,VALUE - (LEAD(VALUE,1) OVER(PARTITION BY SID ORDER BY SID,STAT_NAME DESC)) WAITTIME\n           FROM V$SESS_TIME_MODEL\n           WHERE STAT_NAME IN ('DB time','DB CPU')) M,\n                   V$SESSION S\nWHERE M.SID = S.SID\n      AND STAT_NAME='DB time' AND WAITTIME>0\nORDER BY WAITPCT DESC;\nSQL> SQL> SQL> SQL> SQL>   2    3    4    5    6    7    8    9   10   11   12   13\n    SID USERNAME           DBTIME       WAITTIME   WAITPCT  ONCPU_PCT\n------- ---------- -------------- -------------- --------- ----------\n    132 SYSRAC             673089         587010     87.21      12.79\n    148 SYS                151015         112312     74.37      25.63\n<\/pre><\/div>\n\n\n
Um dos pontos negativos da V$SYS_TIME_MODEL \u00e9 que a mesma \u00e9 cumulativa (como j\u00e1 citado), ou seja, considera os dados tantos dos hor\u00e1rios de picos, como dos hor\u00e1rios de opera\u00e7\u00e3o “normal”, desde o startup do ambiente. E caso o mesmo seja reiniciado, esses dados s\u00e3o resetados e perdidos. Felizmente, temos uma outra view, com os dados coletados a cada 1 hora (por padr\u00e3o, mas que pode ser alterado), armazenando um hist\u00f3rico dessas informa\u00e7\u00f5es. Essa view se chama DBA_HIST_SYS_TIME_MODEL. Com ela, conseguimos at\u00e9 identificar o que ocorreu em um per\u00edodo espec\u00edfico no passado. Segue exemplo:<\/p>\n\n\n
\nSQL> SET LIN 200\nSQL> SELECT * FROM DBA_HIST_SYS_TIME_MODEL FETCH FIRST 7 ROWS ONLY;\n \n   SNAP_ID       DBID INSTANCE_NUMBER    STAT_ID STAT_NAME                                        VALUE   CON_DBID     CON_ID\n---------- ---------- --------------- ---------- ------------------------------------------- ---------- ---------- ----------\n        22  548968087               1 3649082374 DB time                                       40420390  548968087          0\n        22  548968087               1 2748282437 DB CPU                                         3253483  548968087          0\n        22  548968087               1 4157170894 background elapsed time                      242290269  548968087          0\n        22  548968087               1 2451517896 background cpu time                           51754547  548968087          0\n        22  548968087               1 4127043053 sequence load elapsed time                           0  548968087          0\n        22  548968087               1 1431595225 parse time elapsed                             9042452  548968087          0\n        22  548968087               1  372226525 hard parse elapsed time                        8765551  548968087          0\n \n7 rows selected.\n<\/pre><\/div>\n\n\n
Obs: Este procedimento foi criado pelo senhor Ahmed Baraka (www.ahmedbaraka.com) e foi apenas reproduzido por mim em um laborat\u00f3rio pessoal para fins de aprendizado.<\/p>\n","protected":false},"excerpt":{"rendered":"
Como descrito no \u00faltimo artigo (link AQUI), a Time Model \u00e9 um conjunto de estat\u00edsticas que descrevem quais itens da DB Time est\u00e1 sendo gasto do banco de dados. Podemos ver suas informa\u00e7\u00f5es nas views V$SYS_TIME_MODEL e V$SESS_TIME_MODEL. Os dados dessas views s\u00e3o acumulados desde o startup da inst\u00e2ncia (em microsegundos), em uma estrutura hier\u00e1rquica […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[10],"tags":[],"class_list":["post-6338","post","type-post","status-publish","format-standard","hentry","category-performance"],"_links":{"self":[{"href":"https:\/\/swiv.com.br\/index.php\/wp-json\/wp\/v2\/posts\/6338","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/swiv.com.br\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/swiv.com.br\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/swiv.com.br\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/swiv.com.br\/index.php\/wp-json\/wp\/v2\/comments?post=6338"}],"version-history":[{"count":1,"href":"https:\/\/swiv.com.br\/index.php\/wp-json\/wp\/v2\/posts\/6338\/revisions"}],"predecessor-version":[{"id":9051,"href":"https:\/\/swiv.com.br\/index.php\/wp-json\/wp\/v2\/posts\/6338\/revisions\/9051"}],"wp:attachment":[{"href":"https:\/\/swiv.com.br\/index.php\/wp-json\/wp\/v2\/media?parent=6338"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/swiv.com.br\/index.php\/wp-json\/wp\/v2\/categories?post=6338"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/swiv.com.br\/index.php\/wp-json\/wp\/v2\/tags?post=6338"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}