Bom, primeiro vamos responder à sua pergunta : sim, vc EM TESE poderia setar
para 16 (veja na documentação mas o limite máximo, iirc, é de 32), MAS na
prática se vc o fizer é ENORME a chance de piorar VIOLENTAMENTE a performance
se o seu hardware não suportar..... Entenda, quando vc seta uma tarefa para ser
feita em PARALELO, vc passa a ter MÚLTIPLAS tasks fazendo I/O ao mesmo tempo
(em locais/"pedaços" diferentes dos seus datafiles), e OBVIAMENTE isso gasta
CPU (para os processos no SO), gasta RAM (para os buffers), pode gastar banda
de rede/comunicação... SE o seu hardware já está no gargalo, vc já tem tasks de
usuário consumindo recursos mil, o I/O/CPU/rede/RAM Podem Não dar conta dessas
tasks extras, sim ???
Assim sendo : PARALELISMO vc só lança mão se tem CERTEZA que há recursos de
hardware desocupados, que possam atender às tasks extras, E o garu de
paralelismo depende Fundamentalmente da CAPACIDADE do seu hardware - idealmente
vc executaria sem paralelismo (grau 1), depois tentaria com 2 ou 3, depois com
6, e veja que resposta obtém... é Começar ** SIMPLES **, aos Poucos, okdoc ??
Já que vc está preocupado com performance do backup, algumas dicas cabíveis :
a. é FUNDAMENTAL que vc obtenha a maior performance possível do teu hardware
de I/O (um backup para disco consome principalmente é I/O, mesmo), então vc TEM
que :
1. junto com o sysadmin desse ambiente , ver quais discos/controladoras são
mais rápidas e/ou estão sendo menos usadas, e dedicar esses caras pro backup
2. TEM que garantir a menor concorrência de I/O possível , então junto com o
pessoal da Aplicação, tem que negociar uma janela com o menor processamento
possível, re-schedular o que der, etc
3. notar que o seu objetivo é gravar a info em disco Apenas esta vez (um
backup dificilmente é lido logo em seguida à gravação), o mais rápido
possível, E sem grandes preocupações com manutenção/segurança (já que asap isso
vai ir pralguma fita/dispositivo afora o disco), yep ??? Assim, junto com o seu
sysadmin E com o pessoal de discos/storage, vc VAI SE ASSEGURAR que o
disco/device Não tem Journaling/software-mirroring, que ESTÁ sendo acessado via
I/O Asynchronous E em Direct-mode I/O (assim bypassando caches do SO E
permitindo múltiplos I/Os simultâneos)... Esse objetivo é DIAMETRALMENTE OPOSTO
aos defaults do SO, que é jogar para cache tudo que foi acessado para tentar
acelerar os PRÓXIMOS I/Os que forem repetidos, fique atento....
Isso é ainda mais importante quando eu vejo que vc está com um destino
/d01/backup/nãoseioque : TIPICAMENTE isso indica um FILESYSTEM em uso, e na
maioria dos filesystems nem asunc I/O nem Direct I/O são default....
4. LOGICAMENTE, já que o RMAN roda em parte dentro do database (sempre há
uma fase de LEITURA dentro do disco antes da fase de gravação externa), o
DATABASE preferencialmente deve estar bem configurado, ie : com Asynch I/O e
Direct I/O ativos, tablespaces (preferencialmente LMT!!!) com extent sizes
apropriados/alinhados com o tamanho máximo de I/o no seu ambiente, SGA e PGA
adequados, nenhum WAIT interno do próprio RDBMS despontando entre os TOPs
(PRINCIPALMENTE waits referentes à commit ou ação do DBWR!!), a menor taxa de
buffer busy e correlatos, etc...
b. além de paralelismo, experimente também no RMAN ativar a BACKUP
OPTIMIZATION, desative encriptação, não tenha múltiplas cópias nem dos archives
nem dos datafiles backupeados.... Mais uma vez, isso diminui a segurança MAS
como esse backup vai ASAP para fita, não vejo grandes riscos aí...
c. também faz parte do teu trabalho diminuir AO MÁXIMO o volume a ser
backupeado : isso implica em testar backups Incrementais, não backupear
datafiles históricos/read-only todas as vezes....
Opções mais arriscadas, como não backupear tablespaces que só contém índices
(extraindo ao invés só os DDLs) podem ser consideradas, também, SE vc tem
tablespaces com separações, SE vc está á vontade em aceitar o trabalho e o
risco maiores que isso implica E SE o SLA para o restore for beeeem liberal...
d. nessa fase que vc está, de testes, setup e verificações iniciais, as
views/tabelas internas de wait em geral (e as de RMAN em particular) podem ter
ser Extremamente úteis : google e localiza o paper "Recovery Manager (RMAN)
Performance Tuning Best Practices" e de ums estudada nos manuais de Adm
inistração e Tuning que vc acha várias refs para elas todas
[]s
Chiappa
