Bom, ao que eu entendi a idéia do colega lá foi no sentido que a tablespace
bigfile é composta por um único arquivo e é esse único carinha que sempre vai
ser usado em qquer acesso á ela : estatisticamente falando, se vc usa muito uma
coisa só vc em tese teria mais chance de encontrar corrupção/problemas do que
se vc tem um conjunto de coisas que vc vai variando o uso cfrme necessário....
Para mim, porém, isso é meio teórico, meias-vidas e esatísticas nem de longe
seriam elemento decisório , neste cenário que estamos falando sobre - o que vai
valer na sua decisão são fatores outros , como CONFIABILIDADE do seu hardware
(afinal, já que é um arquivo só, qquer problema de corrupção/indisponibilidade
vc perde TUDO nessa tablespace, não só os x dados que estavam no arquivo em uso
no bloco ruim), tempo para operações a nível de arquivo (exemplo, checagem com
DBV, alguns tipos de backup, etc, tudo isso é ** NECESSARIAMENTE ** feita á
nível de arquivo, numa tablespace BIGFILE vc só tem UM único arquivo então não
tem como Paralelizar, com n sessões cada uma lendo/gravando/processando um dos
arqs da tablespace), ALÉM dos eventuais limites de SO e/ou de RDBMS para um
único arquivo - se NADA disso pega pra vc, certamente vc é candidato ao uso,
sim....
[]s
Chiappa
--- Em oracle_br@yahoogrupos.com.br, Hevandro Veiga <hevandro83@...> escreveu
>
> Temos aqui uma tabela de 150gb, mais índices. Resolvi colocar essa em uma
> BIGFILE com ASM em um DG de 20 discos.
> Nesse caso, msm sendo smallfile o impacto em corromper seria o mesmo, já
> que é um objeto apenas.
> Em 07/10/2012 15:40, "Rafael Mendonca" <raffaell.ti77@...> escreveu:
>
> > **
> >
> >
> > Eu particularmente nunca vi em um ambiente de produção com BIGFILE
> > tablespace.
> >
> > Acho que única vantagem é a facilidade da administração do DBA de ter
> > apenas um datafile em um tablespace.
> >
> > Quanto a questão da desvantagem, eu percebo que:
> >
> > 1 - Quanto maior um arquivo é, maior é possibilidade de corrupção do
> > mesmo. Concluindo, um arquivo muito grande como o BIGFILE TABLESPACE terá
> > uma probabilidade maior de corrupção que um SMALLFILE de 2GB por exemplo.
> >
> > 2 - Acho que um arquivo BIGFILE deve degradar a performance se você usar
> > em um filesystem ou não utilizar paralelismo. Pra se ter um desempenho
> > razoável com um BIGFILE Tablespace você deve usar ASM ou um outro
> > fornecedor de volume lógico que realize Striping.
> >
> > Bom, o que me veio na cabeça foi isso, mas vamos esperar os especialistas
> > na área pra te passar melhores informações.
> >
> > ________________________________
> > De: Hevandro Veiga <hevandro83@...>
> > Para: oracle_br@yahoogrupos.com.br
> > Enviadas: Sexta-feira, 5 de Outubro de 2012 18:46
> > Assunto: [oracle_br] BIGFILE TABLESPACE
> >
> >
> >
> > Pessoal,
> > Alguém aqui trabalha com BIGFILE tablespace?
> > Quais vantagens e desvantagens vcs vêem?
> >
> > [As partes desta mensagem que não continham texto foram removidas]
> >
> > [As partes desta mensagem que não continham texto foram removidas]
> >
> >
> >
>
>
> [As partes desta mensagem que não continham texto foram removidas]
>
