Fui convidado para escrever um artivo para a SQL Magazine. Achei interessante o convite e aceitei. O artigo faz parte da revista SQL Magazine 138. Seguem os links:SQL Magazine 138Estrategias de backup e restore no PostgreSQLEspero que gostem!Abracos! Se estiver pensando em migrar pra versao 12.2, entao deveria dar uma olhada neste post que saiu no blog do Mike DietrichO laboratorio e dividido em 4 situacoes de migracao para a versao 12.2. E possivel baixar os templates para Oracle VM Virtual Box com as configuracoes para reproducao dos cenarios.Abaixo um resumo das situacoes encontradas no Hands-On. A intencao deste post e compartilhar um poucoda experiencia que tive ha pouco tempo com problemas relacionados a lentidao referente a I/O no desempenho de backups Oracle RMAN. O ambiente:AIX 6.1Oracle RAC 11g Backups realizados para discos comStorage IBM SANBase de dados com 15TbO problema:Atraves do relatorios de backup foiidentificado que a tempo toral para a conclusao do backup full RMANestava demorando um tempo muito maior do que normalmente fazia. Onormal era algo em torno de 20h e nos ultimos relatoriospassou para 30h.Sabendo do problema vamos entender aanalise.Comecei usando o comando BACKUPVALIDATE do rman. O validatepode te ajudar a entender onde esta o problema. Durante a execucaodo comando, o RMAN le os arquivos que serao usados no backup ,assim como numa operacao normal de backup. Mas fica so na leitura,ele nao faz a escrita das pecas. Entaose o tempo do BACKUPVALIDATEforquase o mesmo que do backup real, podemos deduzir que a leitura nosdiscos e o gargalo. Ja se o tempo do BACKUPVALIDATEforbem menor que o tempo do backup real, podemos dizer que o gargaloesta na fase de escrita. Nomeu caso a leitura era o gargalo. Exitem varios paramentros e configuracoes a nivel de RMAN e de instancia de banco de dados que podem ser feitos para melhorar seu backup, mas como ja verificado a nivel do banco de dados, resolvi partir para o sistema operacional. Entao usei o utilitario iostatpara verificar as operacoes de I/O.Outilitario iostat Elepossui variosparametros para facilitar a analise em tempo real. De cara, jadavapraver que a coluna sqfull estavacom um valor muito alto. Entao partimos pra investigacao dosparametros relacionados afila de comandos nos discos do storage. iostat-DRTl 22 =>Mostra2 estatisticas a cada 2 segundos de intervalo.Casoqueira ver mais informacoes sobre iostat usando AIX. Veja o link nofinal do artigo.Algumascolunas uteis para analise do problema referente a queue.avgtime:media de tempo gasto em esperar na fila (milisegundos)avgwqsz:media do tamanho da fila. Esperando para enviar os comandos para odiscoavgsqsz:media do tamanho da fila de servico. O valor nao deve ultrapassaro valor do parametro queue_depthsqfull:estacoluna mostra a quantidade de vezes que a fila de requisicoes deservico ficou cheiaCasoqueria ver um historico, pode usar o comando sar. # sar -f /var/adm/sa/sa22 -s 14:20 -e 15:00 -w -q -i 4SunOS unknown 5.10 Generic_118822-23 sun4u 01/22/200614:20:00 swpin/s bswin/s swpot/s bswot/s pswch/s14:30:00 0.00 0.0 0.00 0.0 14014:40:01 0.00 0.0 0.00 0.0 14414:50:01 0.00 0.0 0.00 0.0 14015:00:00 0.00 0.0 0.00 0.0 139Voce pode encotrar mais informacoes sobre o sar no link aofinal do artigo.Solucao do problema: Emresumo, nosso problema era