Re: [oracle_br] Re: Backup RMAN muito lento

2016-01-27 Por tôpico Paulo Jr paulobarbosa....@gmail.com [oracle_br]
Aparentemente a taxa está normal, precisa verificar no SO se tem algum erro
de disco, mas creio que está normal.

se quiser pode fazer um teste tbm via SO.

http://elias.praciano.com/2014/09/como-verificar-o-desempenho-do-hd-no-linux/




*Att,*

*Paulo Barbosa*

*Adm de Banco de Dados*

*skype: paulobarbosa.sp*
*Cel.: (11) 98869-0988*

2016-01-27 12:00 GMT-02:00 palomacbarb...@yahoo.com.br [oracle_br] <
oracle_br@yahoogrupos.com.br>:

>
>
> Segue resultado:
>
>
> STATUS KEY DIA_SEMANA START_TIME END_TIME TEMPO_TOTAL INPUT_TYPE DEVICE
> ENTRADA SAIDA TAXA_SEGUNDOS
>
> COMPLETED 1088037 DOMINGO 17-01-2016   20:00:43 18-01-2016   10:47:26
> 14:46:43 DB FULL DISK1.60T  370.24G7.13M
> COMPLETED 1091382 SEXTA 22-01-2016   22:01:35 23-01-2016   15:03:23
> 17:01:48 DB FULL DISK1.69T  390.96G6.53M
> COMPLETED 1093775 TERCA 26-01-2016   18:00:58 27-01-2016   10:28:04
> 16:27:06 DB FULL DISK1.65T  381.98G6.60M
>
>
> 
>


[oracle_br] Re: Backup RMAN muito lento

2016-01-27 Por tôpico jlchia...@yahoo.com.br [oracle_br]
Blz ? Então, graças a todos os deuses eu há muito tempo não tenho que fazer 
backup RMAN de database standard edition (e principalmente acima da casa de 
terabyte), pois Sei como um fato que o RMAN é ** mega-capado **, entre outras 
coisas Incapaz de fazer backup com paralelismo, Incapaz de usar Block Change 
tracking para backups incrementais rápidos,  Incapaz de usar novos recursos de 
block-level (como Block-Level media recovery), que não me espantaria se 
influenciasse negativamente no I/O multibloco  Nessa vc PERDEU simplesmente 
algumas das maiores avenidas para melhorar a performance de seu backup
 Anyway, algumas sugestões pra vc investigar :
 
 a) é absolutamente CRÍTICO que ** todo o I/O ** seja ASÍNCRONO, não apenas a 
leitura dos datafiles (controlada pelo parâmetro DISK_ASYNC_IO) mas TAMBÉM a 
gravação - tenha certeza, portanto, de NÃO USAR filesystem nesse disco local, 
ok ?? Já chega ele ser um SAS, e ainda por cima inferior a 10k, não 
sobrecarregue, vai de RAW DEVICE 
 
 b) pense com carinho na possibilidade de ter MAIS de um disco para backup, 
agrupado num disk volume - certamente pelo custo não parece haver a 
possibilidade de nenhum tipo de RAID, mas quem sabe ao menos um JBOD : o 
negócio aqui é DISTRIBUIR o I/O em múltiplos devices, há boas chances aí de que 
esse único device isolado esteja te causando gargalo, verifique... Talvez até 
mesmo, se vc conseguir montar um disk volume aí (seja no storage,seja local), 
pensar em ASM nele...

 c) vc ao que vejo está SEMPRE fazendo backup full , avalie a possibilidade de 
implementar backup incremental - provavelmente não vai ser lá muito eficiente 
dado que vc no SE não pode usar BCT, mas veja lá
 
 d) confirme se vc pode ou não usar no SE backup multi-seção de um datafile 
grande (Não É paralelismo, vc está sub-dividindo o mesmo datafile), e/ou 
otimização do UNDO : as notas metalink "MultiSection Backups" (Doc ID 406295.1) 
e "RMAN 11G : RMAN UNDO backup optimization" (Doc ID 406468.1)que os apresentam 
foram criadas para EE, mas plz Confirme a disponibilidade dos recursos no SE
 
 e) só por desencargo, dá uma geral na nota "Known RMAN Performance Problems" 
(Doc ID 247611.1) : não tem grande coisa aberta no 11.2.0.4 mas checa...
 
 f) siga os procedimentos de debug indicados em "Troubleshooting RMAN 
Performance or Hang Issues" (Doc ID 815857.1) e "RMAN Performance 
Troubleshooting" (Doc ID 1326686.1) : vc vai ver que a maioria deles OU eu já 
falei acima OU são EE-only, mas veja lá o que vc descobre com isso...
  EM ESPECIAL, vai ser bem interessante a técnica do BACKUP VALIDATE citada, 
pois com isso o RMAN vai fazer TODO o processamento que faz normalmente mas só 
não vai gravar no disco de saída, isso é Ótimo para provar ou desprovar as 
minhas Suposições acima registradas de que talvez seja o teu único disco de 
saída o teu gargalo
 
 g) sob ESTRITO suporte/supervisão do Oracle Support, avalie as mudanças de 
buffer sizes no RMAN : a nota "RMAN Restore Performance on non-ASM filesystems" 
(Doc ID 1561238.1) fala sobre RESTORE, mas (até um ponto) o BACKUP em si pode 
ser influenciado por esses params, na hora de ler os datafiles...
 
 []s
 
   Chiappa

[oracle_br] Re: Backup RMAN muito lento

2016-01-27 Por tôpico palomacbarb...@yahoo.com.br [oracle_br]
Paulo, bom dia. 

 As taxas que tenho são essas:
 

 

 input_bytes : 1.816.117.903.360
 output_bytes:   410.150.502.400

 



Re: [oracle_br] Re: Backup RMAN muito lento

2016-01-27 Por tôpico Paulo Jr paulobarbosa....@gmail.com [oracle_br]
Executa essa query.


SELECT status, session_key KEY,
decode(to_char(start_time, 'd'), 1, 'DOMINGO', 2, 'SEGUNDA',
3, 'TERCA', 4, 'QUARTA',
5, 'QUINTA', 6, 'SEXTA',
7, 'SABADO') DIA_SEMANA,
to_char(start_time, 'dd-mm-   hh24:mi:ss') start_time,
to_char(end_time, 'dd-mm-   hh24:mi:ss') end_time,
time_taken_display TEMPO_TOTAL, input_type,
output_device_type device,
input_bytes_display ENTRADA, output_bytes_display SAIDA,
output_bytes_per_sec_display TAXA_SEGUNDOS
FROM v$rman_backup_job_details where start_time > sysdate-2
order by START_TIME;




*Att,*

*Paulo Barbosa*

*Adm de Banco de Dados*

*skype: paulobarbosa.sp*
*Cel.: (11) 98869-0988*

2016-01-27 11:51 GMT-02:00 palomacbarb...@yahoo.com.br [oracle_br] <
oracle_br@yahoogrupos.com.br>:

>
>
> Paulo, bom dia.
>
> As taxas que tenho são essas:
>
>
> input_bytes : 1.816.117.903.360
>
> output_bytes:   410.150.502.400
>
> 
>


[oracle_br] Re: Backup RMAN muito lento

2016-01-27 Por tôpico palomacbarb...@yahoo.com.br [oracle_br]
Segue resultado: 

 

 STATUS KEY DIA_SEMANA START_TIME END_TIME TEMPO_TOTAL INPUT_TYPE DEVICE 
ENTRADA SAIDA TAXA_SEGUNDOS
 

 COMPLETED 1088037 DOMINGO 17-01-2016   20:00:43 18-01-2016   10:47:26 14:46:43 
DB FULL DISK1.60T  370.24G7.13M
 COMPLETED 1091382 SEXTA 22-01-2016   22:01:35 23-01-2016   15:03:23 17:01:48 
DB FULL DISK1.69T  390.96G6.53M
 COMPLETED 1093775 TERCA 26-01-2016   18:00:58 27-01-2016   10:28:04 16:27:06 
DB FULL DISK1.65T  381.98G6.60M