Não há qualquer razão lógica de ter diferentes tablespace para índices?

Question

Oi, Pode de alguma me avise por isso que nós criamos diferentes do espaço de tabela do Índice e dados.

Answer 1

É uma crença generalizada de que a manutenção de índices e tabelas em separado tablespaces melhora o desempenho.Este é considerado um mito por muitos respeitáveis especialistas (ver esta Peça de Tom thread - procure por "mito"), mas ainda é uma prática comum porque os velhos hábitos custam a morrer!

De terceiros editar

Extrato do asktom: "O Índice De Tablespace" a partir de 2001, para Oracle versão 8.1.6 a questão

• Ainda é uma boa ideia para manter os índices em suas próprias tablespace?
• Faz isso inhance desempenho ou é mais uma recuperação de problema?
• A resposta difere de uma plataforma para outra?

Primeira parte da Resposta

Yes, no, maybe.

The idea, born in the 1980s when systems were tiny and user counts were in the single 
digits, was that you separated indexes from data into separate tablespaces on different 
disks.

In that fashion, you positioned the head of the disk in the index tablespace and the head 
of the disk in the data tablespace and that would be better then seeking 2 times on the 
same disk.

Drives back then were really slow at seeking and typically measured in the 10's to 100's 
of megabytes (if you were lucky)


Today, with logical volumes, raid, NN gigabyte (nn is rapidly becoming NNN gigabytes) 
drives, hundreds/thousands of concurrent users, thousands of tables, 10's of thousands of 
indexes - this sort of "optimization" is sort of impossible.

What you strive for today is to be able to manage things, to spread IO out evenly 
avoiding hot spots.

Since I believe all things should be in locally managed tablespaces with UNIFORM extent 
sizes, I would say that yes, indexes would be in a different tablespace from the data but 
only because they are a different SIZE then the data.  My table with 50 columns and an 
average row size of 4k might belong in a tablespace that has 5meg extents whereas the 
index on a single number column might belong in a tablespace with 512k or 1m extents.

I tend to keep my indexes separate from the data but for the above sizing reason.  The 
tablespaces frequently end up on the same exact mount points.  You strive for even io 
across your disks and you may end up with indexes and data on the same devices. 

Answer 2

Faz sentido nos anos 80, quando não havia muitos usuários e o tamanho dos bancos de dados não era muito grande. Naquela época, era útil armazenar índices e tabelas nos diferentes volumes físicos.

Agora, existem os volumes lógicos, o RAID e assim por diante e não é necessário armazenar os índices e tabelas em diferentes espaços de tabela.

Mas todos os espaços de tabela devem ser gerenciados localmente com o tamanho uniforme estende. Desse ponto de vista, os índices devem ser armazenados em diferentes space de tabela, pois a tabela com as 50 colunas pode ser armazenada no espaço de tabela com tamanho de 5 MB, quando o espaço de tabela para índices será suficientet 512kb tamanho estendido.

Answer 3

• Atuação. Deve ser analisado de caso para caso. Eu acho que manter tudo o TOGHTER em um espaço de tabela se torna outro mito também! Deve ser eixos suficientes, LUNs suficientes e cuidar da fila no sistema operacional. Se alguém pensa que fazer um espaço de tabela é suficiente e é o mesmo que muitos espaços de tabela sem levar em consideração todos os outros fatores, significa novamente outro mito. Depende!
• Alta avaliabilidade. Usando espaços de tabela separados podem melhorar a alta disponibilidade do sistema, caso alguma corrupção de arquivos, corrupção do sistema, corrupção de bloqueio. Se o problema ocorrer apenas no espaço de tabela de índices, haverá a recuperação on -line e nosso aplicativo ainda está disponível para o cliente. Veja também: http://richardfoote.wordpress.com/2008/05/02/indexes-in-their-own-tablespace-recoverability-advantages-get-back/
• Usando espaços de tabela separados para índices, dados, blobs, clobs, eventualmente algumas tabelas individuais podem ser importantes para a capacidade de gerenciamento e custos. Podemos usar nosso sistema de armazenamento para armazenar nossos blobs, clobs, eventualmente arquivar para uma camada diferente de armazenamento com diferente qualidade de serviço