Chiappa, Acredito que todas as possibilidades foram esgotadas depois que voce detalhou cada uma delas.
Assim que foi dada esta "desculpa", tive duvidas se o RMAN realmente faria algo tão ruim assim utilizando multiplos canais. Além do mais, como vc citou, nada será feito no db restaurado que não seja uma copia exata como estava no db origem. Enfim, não estou encabeçando esta tarefa e eles já dispararam o processo, mas ao final eles verão que de nada adiantou esta "teoria furada" e perderão mais tempo com single channel no restore. Mas agradeço muito pelo esclarecimento, tenho mais segurança em defender a idéia. Obrigado. Alex 2012/9/3 J. Laurindo Chiappa <[email protected]> > ** > > > Colega, me parece é que estão querendo, como dizia um amigo meu, te passar > um nana-neném, le aplicar um 171, é tapeação mesmo.... > > Bom, para vc entender, primeiro vamos DEFINIR exatamente o que é > "fragmentação" : o pessoal usa "fragmentação" como uma palavra genérica, > para definir QUALQUER tipo de problema/issue/diminuição de performance > causada (ao menos parcialmente) por distribuição de dados em disco, e como > dá pra imaginar, isso é tipo um 'cobertor' que serve para encobrir qquer > coisa - neguim não pode/não quer definir exatamente o que é e onde está o > problema, tasca FRAGMENTAÇÃO no relatório e tudo bem.... > > Assim sendo, como primeira possibilidade vamos pensar em Fragmentação como > espaço sem dados, em blocos totalmente vazios seja acima do high-water > mark, seja abaixo (entre os extents), que em tese seriam lido à toa no caso > de full table scan ou similares : ORA, cfrme discutido em > http://tonguc.wordpress.com/2008/03/08/ (e Fartamente Documentado nos > manuais RMAN) o RMAN tanto *** não *** backupeia (e portanto NÃO restaura, > claro) blocos acima da hwm nunca usados (NULL COMPRESSION) quanto abaixo da > hwm e totalmente em branco (UNUSED BLOCK COMPRESSION)... Isso funciona > TANTO se alocando 1 ou alocando-se múltiplos canais.... Então esta primeira > possibilidade é blablabla... > > Vamos tentar uma segunda possibilidade, entendendo-se Fragmentação como > espaço em branco dentro dos blocos : ORA, é Documentado (no Concepts) que > no RMAN vc tem leitura de blocos para o backup, mais especificamente : > > "...During a backup, an RMAN channel reads the blocks from the input files > into I/O disk buffers.... " > > ==> OU SEJA, o backup (e portanto o RESTORE!!) te dão imagens EXATAS de > como estava o bloco, NÂO tem como o restore por conta própria querer > inserir espaços em branco no bloco, o RMAN só faz cópias Exatas do bloco, > yep ??? Então possibilidade número 2, bullshit.... > > Vamos tentar uma terceira possibilidade, de que para eles FRAGMENTAÇÃO > sejam blocos ou extents criados em trilhas/setores do disco diferentes da > origem : isso até pode acontecer, mas isso NÂO pode ser aceito como causa > de performance diferente,pois : > > => para localizar os blocos que precisa o Oracle *** NUNCA *** varre um > disco setor por setor, e sim faz um FSEEK a partir do início do datafile > (usando os metadados que possui) e aí, localizado o ponto, ou faz um único > I/O de um único bloco ou faz um único I/O multiblock, lendo o extent > inteiro se possível > > e > > => ainda que o RMAN (por causa das otimizações de bloco acima comentadas) > coloque blocos em extents diferentes da origem, é Conceitual que dentro de > um extent os blocos TODOS são contíguos : Não tem como se ter um extents > com blocos "espalhados" pelo disco.... > > Então para a Terceira possibilidade temos que até pode acontecer de blocos > ficarem em posições diferentes do disco, mas dado que o I/O NÂO é feito > varrendo-se o disco a partir da trilha 0, é largamente Indiferente para a > performance se o bloco que estava na trilha x foi restaurado na trilha y > ..... Até pode haver uma mínima diferença para os poucos blocos que estavam > mais próximos da 'borda' do disco se forem recriados mais em trilhas mais > distantes, mas isso é Mínimo, não dá pra justificar.... Então possibilidade > 3 refutada.... > > ===> O que repito então é isso, pra mim estão tentando te enganar jogando > a culpa em quem não é culpado .... O que eu faria se estivesse no seu lugar > é TRACEs + TKPROFs da execução de alguns SQLs na produção versus TRACEs + > TKPROFs dos mesmos SQLs no ambiente teste, aí vc Certamente OU vai ver > planos de Execução diferentes entre prod x teste (mostrando que as > Estatísticas em teste não estão OK em teste, e/ou o hardware em teste não > está bem configurado ou mesmo é inferior em teste, coisa do tipo), OU vc > vai ver o mesmo plano de execução rodar com performance inferior em test , > mostrando que ou test tem problemas físicos causando os mesmos I/Os nos > mesmos planos demorarem mais, ou test tem problemas de configuração, seja > no banco seja no SO ... > > []s > > Chiappa > > > --- Em [email protected], Alex Cwb <ab80cwb@...> escreveu > > > > > Ola pessoal, > > > > Estou passando por uma situação com um fornecedor que está > > argumentando que o restore feito em uma base de testes com RMAN > > fragmenta quando utilizado com multiplos canais. > > Como a aplicação dele rodando na base da empresa está lenta, um dos > > motivos apresentados por ele é que a base está fragmentada (e causada > > pelo restore). > > > > O restore feito foi usado com 6 canais, e eu acredito que isto não > > seja realmente o problema dele, afinal jamais existirá base que não > > tenha algo fragmentado (comportamento natural de DB). > > > > Procurei por mais informações sobre isso, mas nada que realmente > > alerta sobre isso. Mas minha duvida é se realmente fazer restore com > > multiplos canais provoca fragmentação. > > Alguem tem alguma experiencia neste sentido?? > > > > Utilizamos versão 10g em plataforma HP-UX e ASM como file-system e > > tamanho de 10T. > > Base não está sofrendo grandes updates, pois está sendo utilizada para > > testes apenas. > > > > Desde já agradeço qualquer informação. > > > > Alex > > > > > [As partes desta mensagem que não continham texto foram removidas] ------------------------------------ -------------------------------------------------------------------------------------------------------------------------- >Atenção! As mensagens do grupo ORACLE_BR são de acesso público e de inteira >responsabilidade de seus remetentes. Acesse: http://www.mail-archive.com/[email protected]/ -------------------------------------------------------------------------------------------------------------------------- >Apostilas » Dicas e Exemplos » Função » Mundo Oracle » Package » Procedure » >Scripts » Tutoriais - O GRUPO ORACLE_BR TEM SEU PROPRIO ESPAÇO! VISITE: >http://www.oraclebr.com.br/ ------------------------------------------------------------------------------------------------------------------------ Links do Yahoo! Grupos <*> Para visitar o site do seu grupo na web, acesse: http://br.groups.yahoo.com/group/oracle_br/ <*> Para sair deste grupo, envie um e-mail para: [email protected] <*> O uso que você faz do Yahoo! Grupos está sujeito aos: http://br.yahoo.com/info/utos.html
