Zumba, O particionamento por si só já melhora a performance da consulta pelo fato de que - partindo-se do princípio que feito feito pelo range certo (data, por exemplo) a massa de dados a ser buscada é melhor assim como o plano de execução muda e tudo mais.
Ao meu ver, a não ser que você possa criar tablespaces diferentes em discos lógicos diferentes, a separação por tablespace só melhoraria uma possível fragmentação, caso a tabela seja muito alterada. Da mesma forma, a manutenção de partições é mais fácil quando todas estão num mesmo local (dropar tablespaces com frequencia pode ser complicado dependendo de sua estratégia de backup). Na prática: Num cliente, tínhamos uma tabela com 750 milhões de linhas (aprox. 2 milhões de inserções/dia). O particionamento era feito por data (em pedaços de 10 dias - algo importante de se levantar pois a granularidade da partição deve estar em consonância com a característica das consultas) e a tablespace utilizada era a mesma. Sds, Marcelo Medrado Polo-IT 2009/8/28 Zumba <zumba_ora...@yahoo.com.br> > > > Pois é, documentação de uma decisão no passado sempre foi um problema. Mas > temos um bom método de trabalho, então não seria tão grave. > > Eu estou mais preocupado em apresentar uma boa solução, pois como não tenho > experiencia no quesito, mesmo lendo documentação, sempre é bom ouvir os > experientes no assunto. > > Outra pergunta, é possível ganhar performance particionando uma tabela, mas > todas as partições apontarem pra mesma tablespace? Existe algum ganho nisso, > ou necessariamente devem estar em tbs diferentes?? > > É comum haver um script que cria tablespace + partição e deleta as antigas, > ou a ideia é um pouco arriscada demais, algo não recomendado?? > > Obrigado. > Zumba > > __________________________________________________________ > Veja quais são os assuntos do momento no Yahoo! +Buscados > http://br.maisbuscados.yahoo.com > > [As partes desta mensagem que não continham texto foram removidas]
