Na verdade, como eu disse, o restore ** não ** necessariamente vai ser uma
cópia Exata da origem : os blocos com dados vão ser iguaizinhos, mas há as
otimizações do RMAN que o permitem não copiar blocos vazios/desnecessários, E
também não se garante que os blocos restaurados vão ser restaurados nas mesmas
trilhas/setores de disco, mas Realmente não tem como um arquivo MENOR, com
menos blocos, causar issue de performance, e nem é provável que blocos criados
em disco na trilha/setor X ao invés de Y causem uma diferença de I/O
perceptível, então é por isso que nós podemos taxar Diretamente a alegação do
pessoal lá como nana-neném....
O que vc, como DBA (que imagino é a sua posição aí) tem é que Primeiro
marcar presença fazendo um relatório técnico apontando as impossibilidades que
citei, E depois que eles baterem bem a cabeça, vc tem que conhecer e estar
preparado para o exercício de TUNING / melhoria de performance que certamente
se seguirá ...
[]s
Chiappa
--- Em [email protected], Alex Cwb <ab80cwb@...> escreveu
>
> 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 <jlchiappa@...>
>
> > **
> >
> >
> > 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]
>
