A intenção deste post é compartilhar um pouco
da experiência que tive há pouco tempo com problemas relacionados a lentidão referente a I/O no desempenho de backups Oracle RMAN.
O ambiente:
AIX 6.1
Oracle RAC 11g
Backups realizados para discos com
Storage IBM SAN
Base de dados com 15Tb
O problema:
Através do relatórios de backup foi
identificado que a tempo toral para a conclusão do backup full RMAN
estava demorando um tempo muito maior do que normalmente fazia. O
“normal” era algo em torno de 20h e nos últimos relatórios
passou para 30h.
Sabendo do problema vamos entender a
análise.
Comecei usando o comando BACKUP
VALIDATE do rman. O validate
pode te ajudar a entender onde está o problema. Durante a execução
do comando, o RMAN lê os arquivos que serão usados no backup ,
assim como numa operação normal de backup. Mas fica só na leitura,
ele não faz a escrita das peças.
Então
se o tempo do BACKUP
VALIDATE
for
quase o mesmo que do backup real, podemos deduzir que a leitura nos
discos é o gargalo. Já se o tempo do BACKUP
VALIDATE
for
bem menor que o tempo do backup real, podemos dizer que o gargalo
está na fase de escrita. No
meu caso a leitura era o gargalo.
Exitem vários parâmentros e configurações a nível de RMAN e de instância de banco de dados que podem ser feitos para melhorar seu backup, mas como já verificado a nível do banco de dados, resolvi partir para o sistema operacional. Então usei o utilitário iostat para verificar as operações de I/O.
Exitem vários parâmentros e configurações a nível de RMAN e de instância de banco de dados que podem ser feitos para melhorar seu backup, mas como já verificado a nível do banco de dados, resolvi partir para o sistema operacional. Então usei o utilitário iostat para verificar as operações de I/O.
O
utilitário iostat
Ele
possui vários
parâmetros para facilitar a análise em tempo real. De cara, já
dava
pra
ver que a coluna sqfull
estava
com um valor muito alto. Então partimos pra investigação dos
parâmetros relacionados a
fila de comandos nos discos do storage.
iostat
-DRTl 2
2 =>
Mostra
2 estatisticas a cada 2 segundos de intervalo.
Caso
queira ver mais informações sobre iostat usando AIX. Veja o link no
final do artigo.
Algumas
colunas úteis para análise do problema referente a queue.
avgtime:
média de tempo gasto em esperar na fila (milisegundos)
avgwqsz:
média do tamanho da fila. Esperando para enviar os comandos para o
disco
avgsqsz:
média do tamanho da fila de serviço. O valor não deve ultrapassar
o valor do parâmetro queue_depth
sqfull:
esta
coluna mostra a quantidade de vezes que a fila de requisições de
serviço ficou cheia
Caso
queria ver um histórico, pode usar o comando sar
.
# sar -f /var/adm/sa/sa22 -s 14:20 -e 15:00 -w -q -i 4 SunOS unknown 5.10 Generic_118822-23 sun4u 01/22/2006 14:20:00 swpin/s bswin/s swpot/s bswot/s pswch/s 14:30:00 0.00 0.0 0.00 0.0 140 14:40:01 0.00 0.0 0.00 0.0 144 14:50:01 0.00 0.0 0.00 0.0 140 15:00:00 0.00 0.0 0.00 0.0 139
Você pode encotrar mais informaçoes sobre o sar no link ao final do artigo.
Solução do problema:
Em
resumo, nosso problema era que o tamanho da fila de requisições
para os discos não era suficiente para a quantidade de
solicitação.
Após várias pesquisar e testes seguem as alterações realizadas no
ambiente a
nível de disco e de adaptador.
Sistema
Operacional AIX
Disco
- Foi alterado a quantidade máxima de dados enviados em uma única operação de I/O
realizado
por disco. Como a unidade de alocação,AU, dos diskgroups no ASM
estava
configurada para 1Mb,
alteramos o max_transfer para os mesmos 1Mb.
max_transfer
= 0x100000
- Alterado o número de pedidos pendentes de I/O simultâneos que podem ser enfileirados.
queue_depth=
16
- Foi realizado o balanceamento de I/O para as duas interfaces HBA usadas para backup.
algotithm
= round_robin.
- Alterado o tamanho máximo transferido da requisições para o adptador FC.
max_xfer_size
= 0x2000000
Adaptador
- Alterado a quantidade máxima de comandos suportados pelo adaptador FC.
num_cmd_elems=1000
Banco
de dados
Quantidade
de canais (paralelismo) foi dobrada durante a execução dos backups
RMAN
para
disco.
CONFIGURE
DEVICE TYPE 'SBT_TAPE' PARALLELISM 8 BACKUP TYPE TO BACKUPSET;
Conclusão
- Redução do tempo dos backup RMAN full para disco em 40%. Economia de 16h.
- Reduzimos o principal evento de espera das bases Oracle, db_file_sequential_read, em 12%
- E um aumento na taxa de transferência nas HBA dos hosts AIX de aproximadamente 40%
Link Úteis
IOSTAT
SAR
http://www.ibm.com/developerworks/aix/library/au-unix-perfmonsar.htmlIBM Mpio
http://www.ibm.com/developerworks/aix/library/au-aix-mpio/
Comentários