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
>
