1. Virtualização de Banco de Dados
Bruno Domingues
Principal Architect
IEEE Chairman of Computer Society para o Centro-Norte do Brasil
bruno.domingues@intel.com

2. Agenda
• Motivação
• Tópicos de Virtualização
• Estratégia
• Estudos de Casos

3. Tópicos em Virtualização

4. Básico: Configuração de BIOS
• Sempre verifique as
configurações
apropriadas de BIOS
para:
• Procure por:
– Funcionalidades de CPU
– Memória
– Gerenciamento de
Energia
• Exemplo:
– Configurações padrão não
são ótimas para os
principais SGDBs do
mercado
• Se não está seguro
quanto a melhor
configuração, teste!

5. Hyper-Threading
Time(proc.cycles)
sem SMT SMT
Note: Cada
Caixa representa
uma unidade de
execução do
processador
• Múltiplos núcleos
- Núcleos completamente duplicados
- Aparecem como dois (ou mais) processadores
físicos para o sistema operacional
- Executa threads independentes com seus
próprios recursos computacionais
- Prove um meio de aumentar o desempenho e
minimiza o consumo de potência e dissipação
térmica
• SMT Multithread simultânea
- Executa duas threads ao mesmo tempo por
núcleo
• Tira vantagem da máquina de execução de 4 vias
- Mantêm o processador alimentado com múltiplas
threads
- Oculta latências de uma única thread
• Funcionalidade que provê excelente eficiência de
potência
- Ocupa uma pequena área do processador
- Pode prover ganho significativo de desempenho
*dependendo da aplicação*

6. SMT em Mapeamentos de CPU no Linux
Topologia do
processador
• Em /proc/cpuinfo
• Você poderá ver 16 CPUs: 0-
15
• Processor Topology Tool
identifica qual thread está
em qual CPU do Linux (e
muito mais)
Socket 0
OScpu# | 0 8 | 1 9| 2 10| 3 11|
Core |c0_t0 c0_t1|c1_t0 c1_t1|c2_t0 c2_t1|c3_t0 c3_t1|
Socket 1
OScpu# | 4 12| 5 13| 6 14| 7 15|
Core |c0_t0 c0_t1|c1_t0 c1_t1|c2_t0 c2_t1|c3_t0 c3_t1|
Ex. Socket 0, Core 0, Thread 1 é
Linux CPU 8

7. Comparativo de Desempenho do SMT
1 2 4 8 12 16 20 24 28 32 36 40 44 48
OracleTransactions
Threads
Typical Oracle OLTP Performance Profile
Arquitetura Nehalem com o SMT
habilitado
Arquitetura Nehalem com o SMT
desabilitado
Geração anterior como baseline

8. Escalando Frequência com CPUSPEED
[root@london1 ~]# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
stepping : 5
cpu MHz : 2933.570
cache size : 8192 KB
…
[root@london1 ~]# service cpuspeed stop
Disabling ondemand cpu frequency scaling:[ OK ]
[root@london1 ~]# cat /proc/cpuinfo | grep -i MHz
cpu MHz : 2927.000
cpu MHz : 2927.000
[root@london1 ~]# service cpuspeed start
Enabling ondemand cpu frequency scaling:[ OK ]
[root@london1 ~]# cat /proc/cpuinfo | grep -i MHz
cpu MHz : 1596.000
cpu MHz : 1596.000
[root@london1 ~]# cat /proc/cpuinfo | grep -i MHz
cpu MHz : 1596.000
cpu MHz : 2927.000
Frequências independentes em
resposta a demanda
Valores dinâmicos em
/proc/cpuinfo

9. Prioridades de scheduling

10. Exemplo de carga com Oracle
Top 5 Timed Events Avg %Total
~~~~~~~~~~~~~~~~~~ wait Call
Event Waits Time (s) (ms) Time Wait Class
------------------------------ ------------ ----------- ------ ------ ----------
latch: cache buffers chains 114,324 218,927 2154 72.1 Concurrenc
CPU time 25,442 9.1
latch free 1,998 1,342 577 0.2 Other
-------------------------------------------------------------
SQL> select * from (select name, addr, spin_gets, gets, misses, sleeps from v$latch_Children
where name = 'cache buffers chains' order by gets desc) where rownum < 5;
NAME
----------------------------------------------------------------
ADDR SPIN_GETS GETS MISSES SLEEPS
---------------- ---------- ---------- ---------- ----------
cache buffers chains
00000003E1A0A3F8 838682200 1136069722 839855996 4227
cache buffers chains
00000003E164AA10 0 29037 0 0
cache buffers chains
00000003E1A43220 0 14800 0 0
CPU do SO está em 100% porém no
Oracle apresenta apenas 9%

11. Memória e o Oracle
Connected to:
Oracle Database 10g Express Edition Release
SQL> show sga;
Total System Global Area 805306368 bytes
Fixed Size 1289996 bytes
Variable Size 197132532 bytes
Database Buffers 603979776 bytes
Redo Buffers 2904064 bytes
SQL>

12. Memória Física e Virtual
• Cada processo vê a memoria virtual continua
• MMU (Memory Management Unit) na CPU traduz o virtual para a
memória física
• A TLB (Translation Lookaside Buffer) armazena as traduções mais
recentes
[root@london1 ~]# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
…
address sizes : 40 bits physical, 48 bits virtual
• 40/44 bit fisico 1TB/16TB de memória
• MAXPHYADDR para x86-64 é de 52 bits = 4 Petabytes

13. 48-bit de Endereçamento Virtual
• Cada entrada de endereço são de 8 bytes (64 bits)
• 48 bits = PML4 + PDP + PDE + PTE + page offset
• Atualmente reservados os 16 bits mais altos de endereçamento
• bits 48 ao 63 são atualmente o mesmo que o bit 47
• Tamanho de página definido pelo offset
• Ex. no Linux #define PAGE_SHIFT 12
• 2 para a potência de 12 = 4KB Page
• Ex. endereço linear em x86_64
bit 47 bit 0
47 39 38 30 29 12 20 12 11 0
PML4 Directory Ptr Directory Table Offset
• Cada processo necessita 8 bytes por página de 4KB
• Até 256TB de espaço de endereço linear

14. Huge Pages
• Huge Pages altera o endereçamento de offset (normalmente 2 para
o 21° em x86_64 = 2MB)
• Parâmetro do kernel vm.nr hugepages
47 39 38 30 29 21 20 0
PML4 Directory Ptr Directory Offset
...
HugePages Total: 0
HugePages_Free: 0
Hugepagesize: 2048kB
HugePages_Total: 7500
HugePages_Free: 299
HugePages_Rsvd: 0
Hugepagesize: 2048 kB

15. Memória Física: Arquitetura

16. QuickPath Interconnect
Non-Uniform Memory Access (NUMA)
Nehalem
EP
Nehalem
EP
Tylersburg
EP
• Arquitetura FSB
- Toda a memória em um local
• Iniciando com o Nehalem (x86)
- Memória localizada em
múltiplos locais
• Latência para memória depende do
local
• Memória Local
- Maior banda
- Menor Latência
• Memória Remota
- Maior Latência
Verifique se o software é otimizado para NUMA

17. NUMA e Oracle
Subject: Oracle NUMA usage recommendation
Doc ID: 759565.1 Type: ALERT Modified Date : 19-JUN-2009 Status: PUBLISHED
Disabling or enabling NUMA can change application performance.
It is strongly recommended to evaluate the performance after disabling or before enabling NUMA in
a test environment.
Operating system and/or hardware configuration may need to be tuned or reconfigured when
disabling Oracle NUMA support.
Consult your hardware vendor for more information or recommendation
select a .ksppinm "Parameter", b.ksppstvl "Session Value", c.ksppstvl "Instance
Value" from x$ksppi a, x$ksppcv b, x$ksppsv c where a.indx = b.indx AND
a.indx = c.indx AND ksppinm like '%NUMA%';
…
_enable_NUMA_support
TRUE
In Alert.log
NUMA system found and support enabled (4 domains - 16,16,16,16)

18. NUMA Desabilitada
[oracle@london1 ~]$ ipcs -m
------ Shared Memory Segments --------
key shmid owner perms bytes nattch
0x6422c258 32768 oracle 660 4096 0
0x10455eac 98305 oracle 600 15034482688 31
Processor Processor
Alocação de 64 bytes
round-robin
NUMA é habilitado por padrão se estiver habilitado na BIOS
Porém pode ser desligado no kernel pela seguinte opção:
kernel /vmlinuz-2.6.18-128.el5 ro root=/dev/VolGroup00/LogVol00 numa=off
dmesg | grep -i numa
Command line: ro root=/dev/VolGroup00/LogVol00 numa=off
NUMA turned off
NUMA OFF : Apenas um nó de memória configurado
[root@nehalem1 ~]# numactl --hardware
available: 1 nodes (0-0)
node 0 size: 18149 MB
node 0 free: 2685 MB
node distances:
node 0
0: 10
Linux enxerga memória como nó 0
apenas PORÉM intercalado pelo
Sistema com alocações de 64 bytes
Memória eventualmente alocada por
padrão.

19. Ou use Huge Pages
NUMA Habilitada
[oracle@london1 ~]$ ipcs -m
------ Shared Memory Segments ---
key shmid owner perms bytes
0xa3c20e68 32768 oracle 660 4096 0
0x00000000 884737 oracle 660 1140850688 28
0x00000000 917506 oracle 660 5905580032 28
0x00000000 950275 oracle 660 5905580032 28
0xfb0938e4 983044 oracle 660 2097152 28
When NUMA is enabled
[oracle@london1 ~]$ dmesg | grep -i numa
NUMA: Using 31 for the hash shift
NUMA ON: dois nós de memória configurados
[oracle@nehalem1 ~]$ numactl --hardware
available: 2 nodes (0-1)
node 0 size: 9059 MB
node 0 free: 778 MB
node 1 size: 9090 MB
node 1 free: 1306 MB
node distances:
node 0 1
0: 10 21
1: 21 10
Processor Processor
Linux enxerga como nó 0 e nó 1
Distâncias transmitem latência
Linux e o SGDB devem gerenciar a
memória
Processor Processor
Alocações de 2MB

20. Monitoramento e Estatísticas NUMA
/sys/devices/system/node
[root@london1 node0]$ more meminfo
Node 0 MemTotal: 9276828 kB
Node 0 MemFree: 1465256 kB
Node 0 MemUsed: 7811572 kB
Node 0 Active: 211400 kB
Node 0 Inactive: 77752 kB
Node 0 HighTotal: 0 kB
Node 0 HighFree: 0 kB
Node 0 LowTotal: 9276828 kB
Node 0 LowFree: 1465256 kB
Node 0 Dirty: 28 kB
Node 0 Writeback: 0 kB
Node 0 FilePages: 170280 kB
Node 0 Mapped: 38620 kB
Node 0 AnonPages: 199608 kB
Node 0 PageTables: 13304 kB
Node 0 NFS_Unstable: 0 kB
Node 0 Bounce: 0 kB
Node 0 Slab: 15732 kB
Node 0 HugePages_Total: 3588
Node 0 HugePages_Free: 847
[oracle@london1 ~]$ numastat
node0 node1
numa_hit 394822 873142
numa_miss 0 0
numa_foreign 0 0
interleave_hit 11826 11605
local_node 386530 854775
other_node 8292 18367
[root@london1 ~]# numactl --show
policy: default
preferred node: current
physcpubind: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
cpubind: 0 1
nodebind: 0 1
membind: 0 1

21. Considerações sobre banda de memória
• Maximum B/W:
– DDR3 1333 across 3 channels
– Up to 1 DPC (6 DIMMs total)
– Max capacity: 48 GB
• General purpose:
– DDR3 1066 across 3 channels
– Up to 2 DPC (12 DIMMs total)
– Max capacity: 96GB
• Maximum capacity:
– DDR3 800 across 3 channels
– Up to 3 DPC (18 DIMMs total)
– Max capacity: 144GB
(DPC – Dimms por canal)
CPU CPU
CPU CPU
CPU CPU
10.6 GB/s
10.6
10.6
8.5 GB/s
8.5
8.5
6.4 GB/s
6.4
6.4
Capacidade de
Banda por
processador
25.5GB/s
96GB
19.2GB/s
144GB
32GB/s
48GB
6102
9776
27208
33203
36588
HTN 3.16/
BF1333/ 667
MHz mem
HTN 3.00/
SB1600/ 800
MHz mem
NHM 2.93/ 800
MHz mem/3
DPC
NHM 2.93/
1066 MHz
mem/2 DPC
NHM 2.93/
1333 MHz
mem/1 DPC
Maior é melhor
Banda de streaming – Mbytes/Sec
+274%
Capacidade e Banda na plataforma
Memória
1333 MHz
Memória
1066 MHz
Memória
800 MHz
Source: Intel internal measurement – March 2009

22. Exemplo 1 de DMIDECODE
#dmidecode
Motherboard
Handle 0x0003, DMI type 2, 16 bytes
Base Board Information
Manufacturer: Intel
Product Name: S5000PAL0
Processor
Processor Information
Version: Intel(R) Xeon(R) CPU X5355
Memory
Handle 0x0034, DMI type 17, 27 bytes
Memory Device
Data Width: 64 bits
Size: 2048 MB
Form Factor: DIMM
Set: 1
Locator: ONBOARD DIMM_A1
Bank Locator: Not Specified
Type: DDR2
Type Detail: Synchronous
Speed: 667 MHz (1.5 ns)
• O que isso nos diz:
Motherboard
4 canais de memória (S5000PAL0) 8 Slots
(A1/A2/B1/B2/D1/D2) canais
CPU
Intel Clovertown CPUs
1333Mhz (Dual independente FSB)
Bandwidth 10666 MB/s por FSB
21 GB/s Máxima banda do FSB
Memória
Memória DDR2 667 = PC2-5300
4 canais de memória a 5.3GB/s cada
Banda de memória a 21 GB/s de todos os 4
canais
16GB memória total

23. Exemplo 2 de DMIDECODE
#dmidecode
Motherboard
Handle 0x0002, DMI type 2, 15 bytes.
Base Board Information
Manufacturer: Supermicro
Product Name: X8DTN
Processor
Processor Information
Version: Intel(R) Xeon(R) CPU X5570
Memory
Array Handle: 0x0029
Data Width: 64 bits
Size: 1024 MB
Form Factor: DIMM
Set: 1
Locator: A1_DIMM0
Bank Locator: A1_Node0_Channel0_Dimm0
Type: <OUT OF SPEC>
Type Detail: Synchronous
Speed: 800 MHz (1.2 ns)
• O que isso nos diz:
Motherboard
6 canais de memória (X8DTN), 18 slots
Node0/Node1,Channel0/1/2, DIMM0/1/2
CPU
Intel Nehalem CPUs
3.2GHz QPI (Quickpath Interconnect)
Banda de 25.6 GB/s socket to socket
Até 32GB/s de banda de memória por CPU
Memória
Memória DDR3 800 = PC4-6400
6 canais de memória a 6.4GB/s cada
Banda de memória a 38.4GB/s de todos os 6 canais
19.2GB/s por processador
18GB memória total

24. Disco e I/O
1 2 4 8 12 16 20 24
OracleTransactions
Threads
Oracle OLTP
I/O Impact on Performance
Subsistema de armazenamento “A”
Subsistema de armazenamento “B”
• Servidores idênticos com CPU e memória
• SO e SGDB idênticos
• Aplicações idênticas e cargas
• Diferentes sistemas de armazenamento
Amdahl’s Rule of Thumb
1 byte of memory and 1 byte per second of I/O are required for
each instruction per second supported by a computer

25. Dependência de OLTP Redo I/O
Event Waits Time(s) Avg wait (ms) % DB time Wait Class
log file sync 894,491 5,490 6 61.33 Commit
DB CPU 2,116 23.64
db file
sequential
read
82,013 728 9 8.14 User I/O
enq: TX - row
lock
contention
17,977 116 6 1.29 Application
latch: In
memory undo
latch
44,552 79 2 0.88 Concurrency
Per Second
Transactions: 4,023.7
Subject: WAITEVENT: "log file sync" Reference Note
Doc ID: 34592.1 Type: REFERENCE
Modified Date : 14-JUL-2009 Status: PUBLISHED
Tune LGWR to get good throughput to disk . eg: Do not put redo logs on
RAID 5

26. Dependência de OLTP Redo CPU
Event Waits Time(s) Avg wait (ms) % DB time Wait Class
log file sync 1,795,089 5,909 3 50.38 Commit
DB CPU 2,789 23.78
db file
sequential
read
162,468 2,703 17 23.05 User I/O
enq: TX - row
lock
contention
23,311 205 9 1.74 Application
log file switch
completion
1,429 52 37 0.44 Configuration
Per Second
Transactions: 8,264.3
• Subsistemas de discos idênticos
• Memórias idênticas
• OS e SGDB idênticos
• Upgrade CPU (LGWR também precisa de CPU)
Atualização de memória de uma geração para outra pode trazer até 2x mais desempenho
para o redo

27. Desempenho de Disco rígido e CPU
175x CPU vs. 1.3x ganhos com discos rígidos
NormalizedPerformance
Desempenho de CPU normalizado pelo tempo
médio de acesso para leituras de 20k
200
180
160
140
120
100
80
0
Jan
'96
Jan
'97
Jan
'98
Jan
'99
Jan
'00
Jan
'01
Jan
'02
Jan
'03
Jan
'04
Jan
'05
Jan
'06
Jan
'08
Source: Intel measurementsDate
Desempenho aferido de
ganho de CPU= 175x
Desempenho aferido do
disco rígido = 1.3X
desde 1996
60
40
20
Jan
'07
Jan
'09
Potencial do
SSD
Multicore CPU
CPU
disco

28. Comparativo de Disco Rígido e SSD
1 rack de 120 HDDs
36,000 IOPS
12 GB/sec com banda
sustentável
1452 Watts
8.8 TB
1 rack de 120 SSDs
4,200,000 IOPS
36 GB/sec com banda
sustentável
288 Watts
3.8 TB
Por HDD:
– R/W 150 MB/sec
– 320 IOPS (Read)
– 120 IOPS (Write)
– 12.1 W (active)
Por SSD:
– Read 250 MB/sec
– Write 170 MB/sec
– 35,000 IOPS (Read)
– 4000 IOPS (Write)
– 2.4 W (active)

29. SAN vs. SSD para desempenho de OLTP
8 discos SSD
15 discos SAN

30. Desempenho Virtual vs. Nativo
Native Performance Drives Virtualized Performance
Desempenho do virtualizado é proporcional ao desempenho nativo
Nativo
Desempenho nativo leva a desempenho do virtualizado
Virtual
Overhead Nativo
Virtual
Overhead
Overhead da
virtualização
Overhead aprox. 16%

31. Estratégia

32. Visão Geral do Processo
Defina grupos de
banco de dados
com requisites
similares
• OLAP
• OLTP
Tome um
representante
significativo de
cada grupo
• SGA Grandes
• Huge Pages
• Etc.
Migre para o
ambiente virtual
e avalie o
desempenho
• Desempenho
• Aplicação
• O resultado confere
com o estimado?

33. Lições Aprendidas
Start
Analyze Oracle AWR
Requires <
16vCPU
SGA <32GB and
<1000 users?
Yes
Evaluate if is worth
on migrating to this
amount of vCPUs
No
Yes
I/O
requirements
match virtual
capacity?
Yes
Virtualize
Yes
Evaluate memory
configuration and if
is feasible
Yes
Hold
No
HoldNo
No
1st – Analise os relatórios do Oracle (i.e. AWR)
para entender carga, recursos computacionais
utilizados, dependências e.g. baixa disponibilidade
de CPU e memória não alocada apropriadamente
na NUMA pode impactar diretamente no acesso de
I/O e consequentemente o desempenho;
2nd – Baseado em testes de desempenho com
ambiente VMWare, bancos de dados que
necessitem mais do que 16 vCPUs não tomam
proveito de mais núcleos e não são os melhores
candidatos para virtualização – HT não podem ser
contados como núcleo e permita um acréscimo de
33% de vCPUs se estiver usando HT;
3rd – SGAs com ≤32GB e ≤1000 usuários
conectando são ótimos para uma migração direta ,
além deste ponto pode necessitar melhor
planejamento em alocação de memória e
configuração, incluindo Huge Pages;
4th – Avalie a capacidade de armazenamento
baseado nas características de carga (e.g. OLAP
possui requisites muito diferentes do OLTP
requerendo alta capacidade de escrita sequencial
e redo.. O objetivo deste fluxo é definir quando um banco
poder ser migrado diretamente ou quando é
necessário uma avaliação mais próxima

34. Estudo de Caso

35. DB_1
Host CPU (CPUs: 160 Cores: 80 Sockets: 8)
Load Average Begin Load Average End %User %System %WIO %Idle
1.53 1.50 0.1 0.1 0.0 99.9
Load Profile
Per Second Per Transaction Per Exec Per Call
DB Time(s): 0.1 0.0 0.00 0.00
DB CPU(s): 0.0 0.0 0.00 0.00
Redo size: 28,634.0 1,221.4
Logical reads: 271.5 11.6
Block changes: 160.6 6.9
Physical reads: 0.0 0.0
Physical w rites: 2.1 0.1
User calls: 142.2 6.1
Parses: 1.4 0.1
Hard parses: 0.0 0.0
W/A MB processed: 0.0 0.0
Logons: 0.1 0.0
Executes: 51.2 2.2
Rollbacks: 0.0 0.0
Transactions: 23.4
Existem de 57 a 65 sessões e 64GB de buffer,
portanto certamente este não será um problema
Event Waits Time(s) Avg wait (ms) % DB time Wait Class
log file sync 1,945,325 4,499 2 66.53 Commit
DB CPU 2,372 35.08
Embora não esteja muito alto, mas o log sync wait é o
processo que leva mais tempo (como a maioria dele com
escrita em paralelo) portanto 2ms para commit significa escrita
sequencial em I/O para o redo logs que é o principal evento.
2ms é completamente razoável e se espera o mesmo tempo
rodando virtualizado
The top statementismostlyinsertrelatedsoOLTP
INSERT INTO TMP_TB_CADUP (TIPO_REGISTRO, CN, PREFIXO, MCDU_INICIAL, MCDU_FINAL,
EMPRESA_PROPRIETARIA, EMPRESA_RECEPTORA, REGIAO, SETOR, AREA_OPERACAO_MOVEL, UF, AREA_LOCAL,
AREA_TARIFARIA, CNL, TIPO_PREFIXO, PORTADO, DATA_SOLIC_ABERTURA, DATA_VIGENCIA_INICIAL,
DATA_VIGENCIA_FINAL) VALUES (:1, :2, :3, :4, :5, :6, :7, :8, :9, :10, :11, :12, :13, :14, :15, :16, :17, :18, :19)
A quantidade de memória parece ser mais do que suficiente para SGA/PGA e o uso é
CPU-bound, portanto bastante capacidade disponível. Pode ser usada na VM a mesma
quantidade de memória com 16vCPU

36. DB_2
Checkpoint incompleto significa que não conseguiu escrever o
dado antes da solicitação de tratamento do próximo log. Isto
significa que a base de dados irá ficar suspensa neste caso
por um Segundo – até que o checkpoint seja concluído.
O banco de dados pode ser virtualizado porém o redo precise ser : Parece que o log redo é
muito pequeno ou/e existe um problema de I/O já que escrita de log em paralelo demorar
34ms é muito alto.
Este não está particularmente ocupado, tem um buffer pequeno porém com poucas sessões. O principal ponto que
encontramos é um erro
Top 5 Timed Events
Event Waits Time(s)
Avg
Wait(ms)
% Total Call
Time
Wait Class
log file switch (checkpoint
incomplete)
16,588 15,465 932 43.4 Configuration
db file sequential read 2,011,238 8,030 4 22.5 User I/O
CPU time 3,396 9.5
log file parallel w rite 43,908 1,506 34 4.2 System I/O
controlfile parallel w rite 35,357 1,485 42 4.2 System I/O
Statistic Total per Hour
log sw itches(derived) 380 16.52

37. DB_3
O número de sessões não é muito alto e o buffer é pequeno. Para data warehouses tendemos a preferir um
PGA maior ao invés de buffer – Seria bom aumentar ambos com enfase no PGA para melhorar o desempenho
(cuidado deve ser tomado com SGA com o parâmetro pre_page_sga quando executado em paralelo já que
cada consulta paralela irá paginar todo o SGA antes de iniciar – OK com SGA pequeno mas pode causar
problemas se aumentado)
Esta base de dados realiza consultas em paralelo e uma consulta consome 21 minutos. Com consultas
paralelas você realiza leituras diretas (i.e. direct path reads) – o dado não está em cache portanto a
enfase deve ser em desempenho de leitura – quando a leitura de I/O for corretamente configurada a
virtualização desta base de dados não seria um problema.
Este é um banco de dados de cultas, portanto não é muito interessante do ponto de vista de transações. A maior parte da atividade é
usada é usada em backup durante a geração do relatório AWR.
Event Waits Time(s)
Avg
Wait(ms)
% Total Call
Time
Wait Class
Backup: sbtbackup 40 15,993 399,837 47.5 Administrative
db file sequential read 1,829,511 10,038 5 29.8 User I/O
RMAN backup & recovery
I/O
596,507 8,264 14 24.5 System I/O
db file scattered read 178,495 3,941 22 11.7 User I/O
PX Deq Credit: send blkd 993,159 3,669 4 10.9 Other

38. DB_4
Esta base de dados pode ser virtualizada porém deverá focar em melhorar o desempenho
baseado nestas recomendações, e.g. aumentar o buffer para obter o melhor resultado em
máquina virtual.
A maior parte do tempo é gasta no em leitura sequencial no db (leitura de indice), também olhando no buffer apresenta que aumento no
buffer pode melhorar o desempenho. Esta é uma boa indicação que CPU é evento principal porém ainda vale a pena notar que o tempo
de leitura de I/O é de 6-7ms, que é muito alto para ir ao disco ao invés de buscar na memória.
Top 5 Timed Foreground Events
Event Waits Time(s) Avg wait (ms) % DB time Wait Class
DB CPU 272,787 87.74
db file sequential read 4,079,187 26,590 7 8.55 User I/O
direct path read 558,151 3,607 6 1.16 User I/O
db file scattered read 601,699 3,363 6 1.08 User I/O
log file sync 58,254 1,858 32 0.60 Commit
1qg1ukxc0m53j /* insert br.com.cpqd.oss.commons.etics.resource.physical.EquipmentUnitImpl */ insert into CR_EQ_UNIT
(ALIAS, FTYPE, NAME, OBJ_REF_ID, OWNER, STATUS, CR_LOGICAL_COUNT_ID, OCCUPIABLE,
CR_EQUIPMENT_ID, ID) values (:1 , :2 , :3 , :4 , :5 , :6 , :7 , :8 , :9 , :10 )
2m648gnna1pjk /* insert br.com.cpqd.oss.commons.etics.coppernetwork.entities.CopperConnectionData */ insert into
CR_COPPER_CONNECTION (CONNECT_ESPEC_ID, CR_EQUIPMENT_UNIT_ID, NOTES,
CR_SRC_TRANS_UNIT_ID, CR_TRG_TRANS_UNIT_ID, ID) values (:1 , :2 , :3 , :4 , :5 , :6 )
User I/O
Time (s)
Executions
UIO per
Exec
(s)
%Total
Elapsed
Time (s)
%CPU %IO SQL Id
SQL
Module
SQL Text
2,491.76 0 7.27 6,199.40 59.39 40.19 3r1tvz18j3vtg SQL*Plus declare TYPE
cr_eq_unit_ids_t ...
2,193.68 0 6.40 6,199.47 63.95 35.38 ga3y2fdjz0wj5 SQL*Plus declare TYPE
cr_transmission_u...
A maior parte da CPU vai aqui:
A maior parte do I/O vai aqui – observe que estes rodam por 100 minutos
e não completaram no tempo em que o relatório foi tirado.

39. Obrigado!