Luiz, Não vejo exatamente dessa maneira. Se analisarmos a quantidade de vezes que temos problema em um datafile em determinado período, sempre optaríamos por bigfile tablespace.
O maior problema que vejo em ter um smallfile tablespace é a administração (ou uma vantagem, pois o ambiente será bem controlado). E outra opinião minha: se tiver datafile de 32GB, não precisaríamos ficar discutindo sobre datafiles de 2 ou 4GB (é muita diferença), porque perfornace seria realmente se tivéssemos datafiles pequenos (2 ou 4GB)e problemas específicos (em apenas um datafile); e com um datafile de 32GB não há como comparar com 2 ou 4GB, pois certamente haverá diferença na performance ou no tempo de restore. Acho que é isso. []s Braga 2010/7/5 Luiz Antonio Camargo <luizla...@gmail.com> > Legal... > > Mas o fato de esperar por um problema em somente 1 DATAFILE, como uma > corrupção de bloco ou um delete acidental, seria algo determinante para > dizer: "meu datafile terá 2GB" ou "meu datafile tera 32GB"? > > att. > > luiz > > Em 5 de julho de 2010 12:59, Marcos Braga <braga.mar...@gmail.com> > escreveu: > > > > > > > Olá Luiz, > > > > Só esclarecendo a dúvida quanto a limitação do tamanho. > > > > Essa limitação está somente nos tablespaces SMALLFILES, onde o Oracle > > suporta 4000 (quatro mil) blocos em cada datafile, e 1022 (se não me > > engano) > > datafiles por tablespace; se levarmos em consideração que o tamanho > padrão > > do bloco é 8196, portanto teremos quase 32G em um datafile, o que é > > considerado, por alguns, como uma limitação do sistema operacional, mas > não > > tem nada haver, é limitação da tablespace SMALLFILE. > > > > Em BIGFILE tablespaces você não tem essa limitação, porque o Oracle cria > > somente um datafile (não me recordo qual era o limite, mas estava > rondando > > os TeraBytes). > > > > Quanto a questão da performance no restore de arquivos, já tive muito > > problema com isso, que foram causados em hosts standalone com discos > > locais, > > e quando instalamos Storage, não vi mais diferença em restaurar um > > tablespace com 5 datafiles ou uma tablespace com mesmo tamanho de 1 > > datafile. > > > > Mas se pensarmos um pouco também chega-se a conclusão de que..., se > > efetuarmos um restore da tablespace tal o tamanho é o mesmo. Penso que a > > vantagem é se um dos datafiles que fazem parte da tablespace estiver com > > problemas, aí sim um restore será mais performático do que efetuar um > > restore de um datafile grande (mas só nesses casos). > > > > Bom..., essa é minha opinião. > > > > []s > > Braga > > > > 2010/7/5 Luiz Antonio Camargo <luizla...@gmail.com <luizlaiho% > 40gmail.com> > > > > > > > > > > > > > > > > Bom Dia > > > > > > Queria abrir uma pequena discussão baseada na experiência que todos > aqui > > já > > > tiveram com tamanho de DATAFILE. > > > > > > Encontro inúmeras bases com datafile de 2GB que estouram o tamanho e > > > ganhamos dinheiro colocando mais um datafile de 2GB, rss. > > > > > > Ok, mas se o limite é 32GB, porque limitar? Já ouvi dizer que é devido > ao > > > ZIP do Linux que compacta só até 2GB (ou 4GB, não me recordo), já ouvi > > > dizer > > > que é por limitação de transferência de arquivo para FAT32, etc. Mas > tudo > > > que ouvi que limitava são coisas obsoletas, como esse zip, já que hoje > > > temos > > > o GZIP e ainda mais, já que não é recomendado compactar qualquer backup > > > devido ao tempo de recuperação. > > > > > > Ok, então vou deixar a tbs com 32GB. Mas dai muito falam que isso pode > > > interferir no desempenho da base de dados, ou que é melhor voltar 5 > > > arquivos > > > de 2GB de uma fita do que 1 de 10GB, se perder um arquivo, perde tudo, > > etc. > > > > > > O que vocês acham de tudo isso levando em conta que a base está > > "protegida" > > > por um backup diário de RMAN, possui tabelas grandes e médias, tbs de > > > índice > > > e dados, > [As partes desta mensagem que não continham texto foram removidas]
