Aula 1 - Revisão da arquitetura do banco de dados Oracle 11g E ferramental básico

Objetivo : nivelar o Conhecimento de todos os Participantes sobre os elementos básicos da Arquitetura física e lógica
do RDBMS Oracle, para que possa haver pleno Aproveitamento das técnicas de otimização e dos levantamentos de
ineficiências que ocorrerão no Curso.

 Instância e database : o software RDBMS Oracle é um sistema composto por diversos módulos que devem ser
carregados para a memória – não há um único executável monolítico que é responsável por todo e qualquer
processamento. Esses módulos normalmente são implementados como processos residentes em memória no
Operacional (ou no caso do Windows, como threads de um processo oracle.exe) , e são carregados por um
executável temporário, o bootstrap loader, que também cria uma área de memória compartilhada a ser utilizada
pelos processos background Oracle, a SGA (System Global Area), de acordo com os settings especificados num
arquivo de configuração (pfile ou spfile), criando o que se chama de database em mount status . Após isso, os
arquivos em disco com dados (tablespaces dos usuários) e com metadados (tablespace SYSTEM, principalmente)
serão abertos, a informação necessária lida/carregada e o database é dito ABERTO.
Os processos background mais notáveis a se destacar sob a ótica da performance e tuning são :

Archiver Processes (ARCn) : são os processos encarregados de arquivar (copiar) os arquivos com logs de
alterações do database. Se a sessão do database e/ou a task do SO forem apontados pelas ferramentas e
procedimentos de tuning que discutiremos no Curso, isso pode indicar ineficiência no hardware e/ou na
configuração do dispositivo de gravação utilizado, ou no tamanho do logfile (Arquivamento é em termos
básicos uma cópia do logfile cheio, e logfiles muito pequenos podem levar á cópias frequentes), ou então
Aplicação gerando quantidade excessiva de alterações, que precisam ser logadas (caso em que o Tuning
deve ser feito na Aplicação ou, em alguns casos, alterando-se o modelo físico da aplicação e/ou as estruturas
de armazenamento no database , em especial utilização de INSERTs em modo NOLOGGING) .

Checkpoint Process (CKPT) : para maior eficiência, a informação lida a partir dos arquivos de dados é
mantida em memória nas áreas apropriadas da SGA, mesmo após COMMIT – posteriormente,
vagarosamente e em background, a informação comitada presente em memória é gravada pelo processo
DBWR. O trabalho do Checkpoint é registrar nos controles existentes no cabeçalho dos datafiles a
atualização feita nos datafiles , juntamente com o SCN (um número sequencial que indica o horário/tempo
da atualização) . Obviamente, quanto mais tempo demorar um checkpoint isso é undicador que mais
informação está sendo mantida em memória e mais archives serão necessários numa eventual recuperação,
o que interfe em SLAs.

Database Writer Process (DBWn) : é o processo (ou processos, se o database estiver configurado para
utilizar múltiplos DBWRs) chamado(s) por quaisquer outros processos background que precisem gravar
informações na área de dados dos datafiles. Para fins de tuning, ele se relaciona com alta quantidade de
informações sendo alteradas, ou com ineficiências no acesso para gravação aos datafiles, EM ESPECIAL não
uso de Direct e/ou Asynchronous I/O .

Job Queue Processes : são os processos que executam JOBs programados pelo usuário (ou alguns Jobs
administrativos internos, no caso de databases 10g e superiores) – para fins de tuning não há alteração
possível no database, mas sim no scheduling de Jobs e no Tuning da rotina sendo executada pelo JOB.

Log Writer Process (LGWR) : as alterações feitas num database (com poucas exceções, tal como INSERTs em
modo NOLOG) precisam ser registradas, de modo a permitir a recuperação em caso de crash. No RDBMS
Oracle as alterações são logadas primeiro num buffer específico na SGA (log buffer) e posteriormente
periodicamente esse buffer é passado para disco (inserido nos log files) pelo LGWR. Ineficiências apontando
 para este processo podem indicar Aplicação gerando número excessivo de alterações ou issues na gravação
dos logfiles, e em casos mais raros tamanho ou localização dos logfiles em si.

Process Monitor Process (PMON) e System Monitor Process (SMON) : PMON é o processo responsável por
liberar recursos no SO após o término de um processo de usuário servindo a uma conexão, e SMON libera
recursos nas sessões terminadas, além de fazer rotinas administrativas não especializadas (como
shrink/diminuição de áreas de rollback/undo e temporárias não mais em uso ou desnecessárias para
recover).
Para fins de tuning, quando estes processos e/ou a sessão correspondente são apontado como relevante ,
provavelmente há algum bug levando à desconexão/perda de conexões e/ou a processos zumbis.
:

DEMONSTRAÇÃO (comandos digitados em negrito)

Objetivo : localizar os principais processos e obter Evidências da instância Oracle em execução.

[oracle@localhost ~]$ ps -ef | grep -i pmon

oracle 2703 1 0 16:20 ? 00:00:00 ora_pmon_orcl
oracle 5508 3575 0 20:52 pts/1 00:00:00 grep -i pmon

[oracle@localhost ~]$ ps -ef | grep -i dbw

oracle 2721 1 0 16:20 ? 00:00:00 ora_dbw0_orcl
oracle 5512 3575 0 20:53 pts/1 00:00:00 grep -i dbw

[oracle@localhost ~]$ ps -flp 2721

F S UID PID PPID C PRI NI ADDR SZ WCHAN STIME TTY TIME CMD
0 S oracle 2721 1 0 78 0 - 155441 - 16:20 ? 00:00:01 ora_dbw0_orcl

[oracle@localhost ~]$ ps -vp 2721

PID TTY STAT TIME MAJFL TRS DRS RSS %MEM COMMAND
2721 ? Ss 0:01 0 149389 472374 45704 2.2 ora_dbw0_orcl
[oracle@localhost ~]$

 Tablespaces, Blocos, Extents e Segmentos: Num bd Oracle as informações são armazenadas em tabelas, compostas
por linhas (também chamadas de tuplas ou registros), sendo que todas as informações duma linha residem em
colunas (também chamadas de campos ou atributos). Fisicamente em disco o espaço de armazenamento disponível
para o banco Oracle é composto por arquivos (os chamados datafiles), agrupados em tablespaces, sendo cada datafile
dividido em blocos (de tamanho normalmente fixo, mas opcionalmente ajustável, tanto a nível de database quanto
para cada tablespace de usuário). Cada bloco contém várias linhas duma dada tabela, e automaticamente o RDBMS
mantém em cada bloco uma lista das linhas que contém.
Esses fatos permitem duas otimizações básicas :

a) O fato dos datafiles serem divididos em pedaços (blocos) de tamanho fixo e conhecido permite, uma vez
identificado o bloco aone a informação reside, que a mesma seja recuperada sem uma varredura total do
arquivo : sabendo-se que a informação está no bloco X e que o block size é n bytes, o RDBMS solicita uma
operação de file seek, posicionando um ponteiro na posição x*n do datafile necessário, e lendo apenas os n bytes
após esta posição
b) Sempre é feito um aceso por bloco : assim, mesmo o menor SQL, que acesse apenas uma linha, no primeiro
acesso aos dados terá que acessar ao menos o bloco aonde a linha desejada reside. Uma vez lido o bloco do disco
(é a operação chamado PIO, Physical I/O), ele automaticamente vai para o cache de blocos em RAM do banco (DB
BLOCK BUFFER, área dentro da SGA), de onde caso necessário as demais linhas futuramente serão lidas, poupando
novo acesso físico ao disco.
Uma leitura do cache é chamada de LIO, Logical I/O. A importância de se compreender este mecanismo é que as
tools Oracle de teste e otimização que usaremos neste Treinamento dão informações de I/O em número de blocos
: esta é a razão , por exemplo, de a quantidade de I/Os em disco (PIOs) ser menor numa segunda execução do
mesmo SQL, estamos nesse caso vendo o reflexo dos blocos em cache não mais serem lidos do disco.

DEMONSTRAÇÃO
O Objetivo desta Demonstração é evidenciar a estrutura de dados do RDBMS e exemplificar as tools básicas de
report de LIOs (Logical I/Os) e PIOs (Physical I/Os)

[oracle@localhost ~]$ sqlplus system/oracle

SQL*Plus: Release 11.2.0.2.0 Production on Sun May 11 21:42:19 2014

Copyright (c) 1982, 2010, Oracle. All rights reserved.

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SYSTEM:@orcl:SQL>set timing on
SYSTEM:@orcl:SQL>set autotrace on
SYSTEM:@orcl:SQL>select * from hr.employees where rownum < 10;

EMPLOYEE_ID FIRST_NAME LAST_NAME EMAIL PHONE_NUMBER

HIRE_DATE JOB_ID
----------- -------------------- ------------------------- ------------------------- -------------------- ----
----- ----------
SALARY COMMISSION_PCT MANAGER_ID DEPARTMENT_ID
---------- -------------- ---------- -------------
100 Steven King SKING 515.123.4567 17-
JUN-87 AD_PRES
24000 90

101 Neena Kochhar NKOCHHAR 515.123.4568 21-

SEP-89 AD_VP
17000 100 90

102 Lex De Haan LDEHAAN 515.123.4569 13-

JAN-93 AD_VP
17000 100 90

103 Alexander Hunold AHUNOLD 590.423.4567 03-

JAN-90 IT_PROG
9000 102 60

104 Bruce Ernst BERNST 590.423.4568 21-

MAY-91 IT_PROG
6000 103 60

105 David Austin DAUSTIN 590.423.4569 25-

JUN-97 IT_PROG
4800 103 60

106 Valli Pataballa VPATABAL 590.423.4560 05-

FEB-98 IT_PROG
4800 103 60

107 Diana Lorentz DLORENTZ 590.423.5567 07-

FEB-99 IT_PROG
4200 103 60

108 Nancy Greenberg NGREENBE 515.124.4569 17-

AUG-94 FI_MGR
12000 101 100

9 rows selected.
Elapsed: 00:00:00.18

Execution Plan
----------------------------------------------------------
Plan hash value: 1424567464

--------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 9 | 1197 | 2 (0)| 00:00:01 |
|* 1 | COUNT STOPKEY | | | | | |
| 2 | TABLE ACCESS FULL| EMPLOYEES | 107 | 14231 | 2 (0)| 00:00:01 |
--------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

1 - filter(ROWNUM<10)

Note
-----
- dynamic sampling used for this statement (level=2)

Statistics
----------------------------------------------------------
168 recursive calls
0 db block gets
232 consistent gets
22 physical reads
0 redo size
1789 bytes sent via SQL*Net to client
437 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
6 sorts (memory)
0 sorts (disk)
9 rows processed
(neste report :
recursive calls = SQLs internos, executados nas tabelas internas do RDBMS para encontrar os metadados necessários, fazer a compilação (PARSE) do SQL, verificar as
permissões e status dos objetos envolvidos, etc
db block gets = blocos (contendo dados de usuário OU contendo dados internos do database) sem alteração/transação aberta (lidos em modo corrente, como
vieram do disco) que necessitaram ser acessados para responder ao SQL
consistent gets = blocos obtidos em modo consistente, ie, para a leitura dos quais o RDBMS verificou se existiam alterações em curso e em caso positivo buscou nos
blocos de UNDO/ROLLBACK a versão da informação tal como estava antes da alteração não-comitada em curso.
DB BLOCK GETS + CONSISTENT GETS = LIOs
physical reads = physical IO, PIOs
redo size = qtdade de redo gerado para se poder eventualmente desfazer o SQL antes do COMMIT
sorts (memory)/(disk) = qtdade de sorts
)
 Repetindo-se o mesmo SQL, vemos o efeito do CACHING reduzindo qtd de PIOs (pois dados antes vindos do
disco passaram para o cache) quanto de LIOs (pois o SQL foi compilado e o plano em memória foi usado,
Evitando diversas consultas às tabelas internas e a necessidade de se montar plano de execução e validar
completamente o SQL e os objetos dependentes) :

SYSTEM:@orcl:SQL>l
1* select * from hr.employees where rownum < 10
SYSTEM:@orcl:SQL>/

EMPLOYEE_ID FIRST_NAME LAST_NAME EMAIL PHONE_NUMBER

HIRE_DATE JOB_ID
----------- -------------------- ------------------------- ------------------------- -------------------- ----
----- ----------
SALARY COMMISSION_PCT MANAGER_ID DEPARTMENT_ID
---------- -------------- ---------- -------------
100 Steven King SKING 515.123.4567 17-
JUN-87 AD_PRES
24000 90

101 Neena Kochhar NKOCHHAR 515.123.4568 21-

SEP-89 AD_VP
17000 100 90

102 Lex De Haan LDEHAAN 515.123.4569 13-

JAN-93 AD_VP
17000 100 90

103 Alexander Hunold AHUNOLD 590.423.4567 03-

JAN-90 IT_PROG
9000 102 60
 104 Bruce Ernst BERNST 590.423.4568 21-
MAY-91 IT_PROG
6000 103 60

105 David Austin DAUSTIN 590.423.4569 25-

JUN-97 IT_PROG
4800 103 60

106 Valli Pataballa VPATABAL 590.423.4560 05-

FEB-98 IT_PROG
4800 103 60

107 Diana Lorentz DLORENTZ 590.423.5567 07-

FEB-99 IT_PROG
4200 103 60

108 Nancy Greenberg NGREENBE 515.124.4569 17-

AUG-94 FI_MGR
12000 101 100

9 rows selected.

Elapsed: 00:00:00.00

Execution Plan
----------------------------------------------------------
Plan hash value: 1424567464

--------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 9 | 1197 | 2 (0)| 00:00:01 |
|* 1 | COUNT STOPKEY | | | | | |
| 2 | TABLE ACCESS FULL| EMPLOYEES | 107 | 14231 | 2 (0)| 00:00:01 |
--------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

1 - filter(ROWNUM<10)

Note
-----
- dynamic sampling used for this statement (level=2)

Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
6 consistent gets
0 physical reads
0 redo size
1789 bytes sent via SQL*Net to client
437 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
9 rows processed

SYSTEM:@orcl:SQL>

 Continuando, além disto para maior eficiência quando uma tabela é criada ou quando novos dados são acrescentados
e mais espaço se faz necessário, a alocação em disco não é feita um bloco por vez, mas sim é alocada uma quantidade
fixa de blocos pré-definida para a tabela, o chamado EXTENT : a importância do extent é que no caso de acessos a
mais de uma linha e dados duma só vez, e/ou varredura de toda a tabela em busca de dados, tipicamente serão lidos
extents duma só vez, e não bloco a bloco, e os blocos desses extents vão para o cache (respeitando limites internos do
banco, normalmente 10% do cache, para evitar saturação), o que se refletirá em consultas futuras. Naturalmente,
informações não são apenas lidas num bd, mas também alteradas e deletadas, E por paradigma no bd Oracle leituras
nunca sofrem interferência/bloqueio por alterações, E uma alteração não comitada NUNCA se reflete numa leitura :
assim, nesses casos o bloco desejado é lido para o cache igualmente, mas é feita uma cópia dele no estado atual
antes da alteração (o chamado undo ou rollback), o bloco original em cache será alterado, mas é a cópia que será lida
pelas outras sessões que não podem ver as alterações não comitadas. Para que seja possível se re-aplicar uma
operação a qualquer tempo, também é gerado o redo, ie, os bytes da alteração no bloco são armazenados em RAM e
depois no disco, nos redo log files. Da mesma forma, num ambiente multi-usuário, pode acontecer que o banco
receba dois pedidos de acesso ao mesmo bloco, assim há um mecanismo de controle de acesso aos blocos, uma
“trava” simples e rápida em memória, um indicador de que naquele instante há alguém acessando o bloco, outras
sessões devem aguardar, esse controle é o LATCH, que não pode ser confundido com locks/bloqueios: já os LOCKs
impedem o acesso a linhas ou tabelas inteiras, são de longa duração, e impedem totalmente, fazem falhar o acesso
por parte de outrem, enquanto os latches são de curtíssima duração (frações de segundo, tipicamente), e em caso de
falha de obtenção de um dado latch a sessão interessada não falha, simplesmente fica em waiting por alguns
momentos e retoma a tentativa de acesso.

Os conceitos de latch, lock, undo e redo serão importantes em pontos futuros deste Workshop.

DEMONSTRAÇÃO
O Objetivo desta demonstração é evidenciar (através da Instrumentação básica presente num RDBMS Oracle, que
será usada intensamente neste Treinamento) o registro das operações internas :

Metodologia : abriremos 3 terminals (um para consultar e outros dois acessando os mesmos objetos ao mesmo
tempo, para Evidenciar)

(sessão#1, vai monitorar) :

[oracle@localhost ~]$ sqlplus / as sysdba

SYS:AS SYSDBA@orcl:SQL>show user

USER is "SYS"

(notar que as estatísticas/eventos do database são incrementais , então o que nos interessa é a diferença entre
duas coletas)

(sessão#2 vai ser monitorada) , vai atualizar um registro

[oracle@localhost ~]$ sqlplus system/oracle
SYSTEM:@orcl:SQL>select sid, serial# from v$session where audsid=userenv('sessionid');

SID SERIAL#
------ --------
39 37

(vamos fazer uma coleta inicial)

SYS:AS SYSDBA@orcl:SQL>create table TEMP_STATS_TBL as
select sid, name, value, 1 exec#
from v$sesstat ss, v$statname sn
where sn.statistic#=ss.statistic#
and sid=39;

Table created.

(na sessão monitorada vou executar um SQL que tenho certeza não existir antes) :

SYSTEM:@orcl:SQL>select region_id, region_name, rownum, 'Exemplo#1' from hr.regions;

REGION_ID REGION_NAME ROWNUM 'EXEMPL

---------- ------------------------- ---------- -------
1 Europe 1 Exemplo#1
 2 Americas 2 Exemplo#1
3 Asia 3 Exemplo#1
4 Middle East and Africa 4 Exemplo#1

SYSTEM:@orcl:SQL>

(faço uma segunda coleta e consulto a diferença) :

SYS:AS SYSDBA@orcl:SQL>insert into TEMP_STATS_TBL (

select sid, name, value, 2 exec#
from v$sesstat ss, v$statname sn
where sn.statistic#=ss.statistic#
and sid=39);

628 rows created.

SYS:AS SYSDBA@orcl:SQL>select t1.sid, t1.name, t1.value Valor1, t2.value Valor2, t2.value - t1.value Diferenca
from TEMP_STATS_TBL t1, TEMP_STATS_TBL t2
where t1.sid = t2.sid
and t1.name = t2.name
and t1.exec# = 1
and t2.exec# = 2
and t1.value <> t2.value
order by 1,2;

SID NAME VALOR1 VALOR2 DIFERENCA

------ ---------------------------------------------------------------- ---------- ---------- ----------
39 DB time 39 40 1
39 HSC Heap Segment Block Changes 15 25 10
39 SQL*Net roundtrips to/from client 14 16 2
39 buffer is not pinned count 530 585 55
39 bytes received via SQL*Net from client 2571 2943 372
39 bytes sent via SQL*Net to client 4812 5634 822
39 calls to get snapshot scn: kcmgss 251 284 33
39 calls to kcmgas 6 8 2
39 calls to kcmgcs 9 18 9
39 cell physical IO interconnect bytes 262144 409600 147456
39 cluster key scan block gets 49 58 9
39 cluster key scans 29 36 7
39 commit cleanouts 9 10 1
39 commit cleanouts successfully completed 9 10 1
39 consistent gets 723 822 99
39 consistent gets - examination 308 341 33
39 consistent gets from cache 723 822 99
39 consistent gets from cache (fastpath) 390 444 54
39 db block changes 48 70 22
39 db block gets 37 49 12
39 db block gets from cache 37 49 12
39 deferred (CURRENT) block cleanout applications 7 8 1
39 enqueue releases 38 43 5
39 enqueue requests 39 44 5
39 execute count 233 255 22
39 file io service time 0 725 725
39 file io wait time 38724 47526 8802
39 free buffer requested 34 52 18
39 hot buffers moved to head of LRU 0 6 6
39 index fetch by key 60 80 20
39 index scans kdiixs1 211 222 11
39 messages sent 7 8 1
39 no work - consistent read gets 405 462 57
39 non-idle wait count 98 117 19
39 non-idle wait time 29 30 1
39 opened cursors cumulative 214 236 22
39 parse count (hard) 25 27 2
39 parse count (total) 144 162 18
39 parse time elapsed 3 4 1
39 physical read IO requests 32 46 14
39 physical read bytes 262144 409600 147456
 39 physical read total IO requests 32 46 14
39 physical read total bytes 262144 409600 147456
39 physical reads 32 50 18
39 physical reads cache 32 50 18
39 physical reads cache prefetch 0 4 4
39 recursive calls 1654 1749 95
39 redo entries 24 35 11
39 redo size 8048 11212 3164
39 redo synch time (usec) 3721 4103 382
39 redo synch writes 3 4 1
39 rows fetched via callback 15 16 1
39 session cursor cache hits 145 149 4
39 session logical reads 760 871 111
39 session pga memory 1466412 1138732 -327680
39 shared hash latch upgrades - no wait 5 7 2
39 sorts (memory) 148 154 6
39 sorts (rows) 529 534 5
39 table fetch by rowid 258 266 8
39 table scan blocks gotten 6 22 16
39 table scan rows gotten 188 204 16
39 table scans (short tables) 5 8 3
39 undo change vector size 2376 3508 1132
39 user I/O wait time 3 4 1
39 user calls 20 24 4
39 workarea executions - optimal 41 45 4

66 rows selected.

SYS:AS SYSDBA@orcl:SQL>drop table TEMP_STATS_TBL;

Table dropped.

(abro nova sessão , refaço a monitoração e executo exatamente o mesmo SQL, notar que os parses e consumo de
hardware diminuíram) :

SYSTEM:@orcl:SQL>exit

[oracle@localhost ~]$ sqlplus system/oracle

SYSTEM:@orcl:SQL>select sid, serial# from v$session where audsid=userenv('sessionid');

SID SERIAL#
------ --------
39 11

SYSTEM:@orcl:SQL>

SYS:AS SYSDBA@orcl:SQL>create table TEMP_STATS_TBL as

select sid, name, value, 1 exec#
from v$sesstat ss, v$statname sn
where sn.statistic#=ss.statistic#
and sid=39;

Table created.

SYSTEM:@orcl:SQL>select region_id, region_name, rownum, 'Exemplo#1' from hr.regions;

REGION_ID REGION_NAME ROWNUM 'EXEMPLO#

---------- ------------------------- ---------- ---------
1 Europe 1 Exemplo#1
2 Americas 2 Exemplo#1
3 Asia 3 Exemplo#1
4 Middle East and Africa 4 Exemplo#1

SYSTEM:@orcl:SQL>
SYS:AS SYSDBA@orcl:SQL>insert into TEMP_STATS_TBL (
select sid, name, value, 2 exec#
from v$sesstat ss, v$statname sn
where sn.statistic#=ss.statistic#
and sid=39);

628 rows created.

SYS:AS SYSDBA@orcl:SQL>select t1.sid, t1.name, t1.value Valor1, t2.value Valor2, t2.value - t1.value Diferenca
from TEMP_STATS_TBL t1, TEMP_STATS_TBL t2
where t1.sid = t2.sid
and t1.name = t2.name
and t1.exec# = 1
and t2.exec# = 2
and t1.value <> t2.value
order by 1,2;

SID NAME VALOR1 VALOR2 DIFERENCA

------ ---------------------------------------------------------------- ---------- ---------- ----------
39 CPU used by this session 2 3 1
39 HSC Heap Segment Block Changes 4 14 10
39 SQL*Net roundtrips to/from client 14 16 2
39 buffer is not pinned count 23 28 5
39 bytes received via SQL*Net from client 2480 2852 372
39 bytes sent via SQL*Net to client 4813 5635 822
39 calls to get snapshot scn: kcmgss 26 39 13
39 calls to kcmgas 4 5 1
39 calls to kcmgcs 8 10 2
39 commit cleanouts 7 8 1
39 commit cleanouts successfully completed 7 8 1
39 consistent gets 69 87 18
39 consistent gets - examination 15 17 2
39 consistent gets from cache 69 87 18
39 consistent gets from cache (fastpath) 53 68 15
39 db block changes 25 47 22
39 db block gets 22 34 12
39 db block gets from cache 22 34 12
39 deferred (CURRENT) block cleanout applications 0 1 1
39 enqueue releases 13 16 3
39 enqueue requests 14 17 3
39 execute count 23 25 2
39 index fetch by key 3 13 10
39 messages sent 4 5 1
39 no work - consistent read gets 45 59 14
39 non-idle wait count 22 27 5
39 opened cursors cumulative 26 28 2
39 parse count (total) 24 26 2
39 recursive calls 182 185 3
39 redo entries 14 25 11
39 redo size 4136 7332 3196
39 redo synch time (usec) 12018 12389 371
39 redo synch writes 2 3 1
39 session logical reads 91 121 30
39 table scan blocks gotten 5 11 6
39 table scan rows gotten 161 169 8
39 table scans (short tables) 4 5 1
39 undo change vector size 992 2152 1160
39 user calls 19 23 4

39 rows selected.

Notar que diminuiu sensivelmente a quantidade de PARSEs de SQLs, isso foi devido ao cache – dificilmente essa
estatística de performance chega a zero, pois em qualquer momento há SQLs os mais diversos sendo executados
num banco de dados (inclusive os SQL recursivos, internos, gerados pelo próprio RDBMS, que se controla via
tabelas, acessadas via SQL) - , mas houve Aproveitamento.