Fabio, o Aviso sobre a necessidade de somente usar BIGFILE em ambientes que
disponham de algum tipo de distribuição de I/O / balanceamento é real e muito
oportuno - até eu, quando falei na minha msg anterior que independe a
performance, me esqueci desse caso, que não é comum em produção mas vale a pena
citar.... Edilson, imagine por exemplo que ao invés de LUNs vc usa discos
separados e independentes : com smallfile tablespace, vc pode criar um datafile
da tablespace no disco D: , um no disco E: , um no disco F: (digamos), assim
distribuindo o seu I/O ... Nesse cenário, se vc fosse usar BIGFILE como eu
disse uma tablespace bigfile só pode ter UM e apenas UM datafiole, e um
datafile só pode ficar num só disco .... Eu não tinha avisado sobre isso porque
sempre penso em produção, e em produção com certeza o mais comum é "juntar"
todas as LUNs/discos num só volume, num só I/O device que é controlado por um
software capaz de espalhar o conteúdo, ie, de automaticamente gravar cada
pedacinho deo datafile em uma parte diferente dum disco/LUN diferente : isso
pode ser feito pelo Oracle ASM, pode ser feito pelo software que controla o
storage, pelo filesystem que contém os LUNs/discos físicos, etc....
Agora, Edilson : algumas coisas que a Oracle fala a gente confia
desconfiando , vc TEm que filtrar o exagero, yes ?? Por exemplo, quando ela diz
que é "mais fácil" gerenciar um arquivo do que 10 na tablespace - bancando um
pouco o advogado do diabo, quando que vc tem que trabalhar diretamente com
datafiles ? É quando vc vai fazer operações que interferem diretamente nele
(digamos, resize, ou alteração de característica física) : ora, se ao invés de
10 comandos alter vc escreveu um só ok, vc poupou, mas poupou SEGUNDOS de
digitação, e isso numa operação não tão comum e rotineira, algo que não se faz
todos os dias .... Valeu a pena, foi lucro ?? Só vc pode dizer...
Outra coisa é a questão de limites maiores do DB ao se usar BIGFILES : isso
existe, claro, mas é algo que só vai entrar no seu escopo quando o seu DB
chegar na casa dos TERABYTES, não me parece ser o caso...
Sobre a possível redução de tempo de checkpoint por ter menos datafiles , é
algo possível mas não tão provável : afinal, menos datafiles significam menos
blocos de cabeçalho para sincronizar, ok, mas o GROSSO de um database
absolutamente não são os blocos de cabeçalho (que são POUCOS, no início de cada
arquivo) mas sim os blocos de dados, e desses a quantidade de blocos
absolutamente não se altera, estejam eles numa bigfile ou espalhados por vários
datafiles, sim ? E é auqle coisa : atualizar um muitos milhares de blocos vai
DEMORAR PRACAS, estejam esses blocos dentro de um ou dentro de x datafiles....
A quantidade de I/Os single-block vai ser RIGOROSAMENTE A MESMA, yes ?? Então
novamente : com a BIGFILE vc poupou alguns file handlers (já que só terá um
arquivo aberto) e poupou o I/O num punhadinho de blocos de cabeçalho, ok, mas o
trabalho grosso continuará Rigorosamente o mesmo, ok ?? Não pense que vai ser
uma hipermaster vantagem, que não deve ser ...
Outra coisa é que apesar de já não ser tãããão recente assim (foi introduzida
no 10g) nós ** ainda ** temos na sua versão 11.2.0.3 uns tantos quantos bugs
danados para BIGFILES, como o Bug 14055559 - System hang due to TT enqueue
contention with BIGFILE tablespace resize (Doc ID 14055559.8) e o Bug 14510149
- "enq: CT - reading" during bigfile tablespace backup (Doc ID 14510149.8), por
exemplo...
Rumine bastante essas infos , esses prós e contras e analise aí....
[]s
Chiappa
