Se um banco de dados Oracle tem mais do que um espaço de tabela para armazenamento de dados?

Question

A minha equipa mantém um banco de dados Oracle que é de aprox. 200GB em tamanho. Todos os dados (tabelas, índices, etc) vive dentro de tabela de um único 'utilizadores'. Será esta uma má idéia? Quais os benefícios de ter vários espaços de tabela, e em que circunstâncias eu iria querer adicionar mais para o meu banco de dados?

Obrigado!

Answer 1

O meu viés (e isso é em grande parte uma questão de preferência pessoal) é que se não há nenhum benefício atraente para a criação de espaços de tabelas adicionais, a vida é mais fácil com um único espaço de tabela.

• Não há nenhum benefício de desempenho para colocar objetos em diferentes espaços de tabela. Há um velho mito que separam tabelas e índices teria algumas vantagens de desempenho. Há um benefício potencial para espalhar I / O sobre todo fusos disponíveis, mas que é melhor feito com vários arquivos de dados em uma única tabela, em seguida, com vários espaços de tabela desde que a Oracle faz uma alocação de round-robin de extensões em diferentes arquivos de dados assumindo que o seu isn SAN 't já fazendo algo para até mesmo fora I / O.
• Se você tem grandes, mesas de pesquisa / história estáticos, que você poderia trazer uma nova cópia do banco de dados para o site do cliente apenas por trazer os espaços de tabelas transacionais menores, que seria uma razão para considerar vários espaços de tabela. Mas há muito poucas aplicações que têm este tipo de configuração. Se você vai ter que trazer todos os 200 GB, não importa quantos espaços de tabela que você tem.
• Na mesma linha, se você tem objetos grandes somente leitura, colocando-os em uma tabela somente leitura pode vastamente diminuir o tempo eo espaço necessário para backups. Novamente, porém, este não é particularmente comum na prática fora da data warehouses.
• Se seu aplicativo pode ser executado sem um subconjunto de objetos, pode haver um benefício para a criação de espaços de tabela separados para que você possa tomar uma off-line e fazer uma restauração de nível de tabela. Novamente, porém, algumas aplicações podem funcionar sem um conjunto de objects-- se você perder o espaço de tabela de índice, por exemplo, o pedido seja susceptível tão morto como tinha que perdeu tudo.
• Se você tem um grande número de mesas vazias ou quase vazias e uma série de tabelas muito grandes, espaços de tabela separados com diferentes políticas de alocação de extensão pode ser preferível do ponto de vista a utilização do espaço. Isso acontece ocasionalmente com pacotes de aplicativos onde qualquer instalação está usando uma porcentagem relativamente pequena das tabelas disponíveis e você não quer que cada uma das mesas vazias para ter um grau relativamente elevado atribuído a ele. Com o gerenciamento de extensão automática em um espaço de tabela gerenciado localmente, este tende a não ser uma grande preocupação, pode ser mais preocupante se você quiser usar extensões uniformes.
• Se objetos diferentes têm diferentes prioridades para o desempenho do disco, e você tem diferentes tipos de disco disponível, espaços de tabela separados podem permitir que você coloque objetos diferentes em diferentes conjuntos de discos. Em um armazém de dados, por exemplo, você pode querer colocar os dados mais antigos sobre mais lento, disco mais barato e os dados mais recentes no disco mais caro. Isso não acontece muito com as aplicações OLTP.

A menos que seu aplicativo cai em um desses casos especiais, a única vantagem de ter espaços de tabela separados é apelar para o senso de organização de um DBA. Pessoalmente, estou mais do que feliz em ser capaz de evitar especificando um nome de tabela cada vez que eu criar um objeto ou a gastar ciclos de objetos em movimento a partir da tabela "errado" quando eles inevitavelmente se criado no espaço de tabela padrão erroneamente. Pessoalmente, eu não estou excessivamente preocupado se algumas dezenas de MB de espaço são "desperdiçadas" quando utilizar espaços de tabela gerenciados localmente com gerenciamento automático medida sobre um conjunto otimizado mão de espaços de tabela com tamanhos diferentes uniforme de extensão. Por outro lado, bons do DBA tendem a ser muito preocupados com as coisas sendo organizado "tão" então eu não estou militantemente oposição se um DBA quer ter índice de dados e espaços de tabela separados apenas por causa que agrada a sensação de estética de alguém.

Answer 2

http://download.oracle.com /docs/cd/B10501_01/server.920/a96521/tspaces.htm

http://download.oracle.com /docs/cd/B28359_01/server.111/b28318/physical.htm

Você pode usar vários espaços de tabela para realizar as seguintes tarefas:

espaço em disco Controle de alocação para dados do banco de dados

Atribuir quotas espaço específico para usuários de banco de dados

disponibilidade

Controle dos dados, tomando tablespaces individuais on-line ou desligada

Faça backup de banco de dados parcial ou operações de recuperação

Alocar armazenamento de dados através de dispositivos para melhorar o desempenho

Answer 3

Uma das razões para o uso de diferentes espaços de tabela seria um desejo de usar o transporte de tabela para mover dados entre bases de dados. Se você tem um conjunto limitado de dados que você deseja mover, sem ter que exportar e importar então o transporte de tabela é uma boa opção, especialmente se é importante para testar razões que os dados têm exatamente a mesma estrutura física, como o sistema de origem ( para o trabalho de análise de desempenho, por exemplo).

Answer 4

Eu discordo fortemente com a avaliação Justin Caves. A DBA produção provavelmente teria uma opinião muito diferente.

tablespaces transportáveis ??recurso para mover subconjuntos de dados entre bases de dados, sem ter que mover todo o banco de dados.

read-only tablespaces que você não está fazendo backup de todo o banco de dados a cada semana, o que pode levar muitas horas, e você não pode suportar o impacto na performance para esse período de tempo, mesmo se a sua limitação da taxa.

apenas backup de certos espaços de tabela em datas fixas devido ao tamanho, embora muitos lugares simplesmente não têm bases de dados tão grande. mesma razão que ponto acima.

Dependendo da sua aplicação, digamos que existem módulos que podem funcionar independentemente um do outro no lado da aplicação. Se cada um tem seu próprio conjunto de espaços de tabela, você pode tomar um aplicativos de tabela off-line para fazer uma reorganização sem afetar os outros módulos ... eles podem correr como normal.

como para a separação de dados e índices: a razão tradicional era para colocar os dois em discos diferentes para que eles não competem entre si desempenho sábio. Não tanto de um problema com capacidades de armazenamento de hoje, como SANs, onde tudo está realmente a mesma área de armazenamento, mas não há ainda a consideração de que você está indo para obter contenção no nível do cabeçalho do arquivo, mesmo com gerenciado localmente espaços de tabela se você tem todos os seus objetos na mesma tabela onde você não pode locigally separam os índices das tabelas !! Mesmo se você criar 20 arquivos de dados em um espaço de tabela, você não começa a decidir onde as tabelas e índices ir, e então um dia você percebe que você tem maior contenção no nível do cabeçalho do arquivo por causa da atividade maciça contra a mesa onde é índices acontecerá a ser no mesmo arquivo de dados! Na verdade sucata isso. se você só tem uma ts, então você irá , sem dúvida, cabeçalho do arquivo experiência contenção.

existem mais razões para ter essa separação lógica, e não, não é sobre o desempenho na maioria das vezes, é mais sobre a administração em um ambiente de produção.

Answer 5

S. Lott já deu uma boa lista de razões gerais por que se pode querer dividir isso até para vários espaços de tabela.

Mais específico para sua situação ...

Eu me pergunto se há razões específicas para mudar as coisas agora. Não é nenhuma tarefa pequena para fazer uma mudança estrutural como essa. Existem problemas de desempenho? Você está correndo contra limites de espaço de armazenamento? Você precisa atribuir quotas de espaço? Será que o seu backup presente e restaurar plano de atender às suas necessidades?

Se você pudesse voltar no tempo e refazer as coisas desde o início, você certamente quer plano para sensata dividir o banco de dados em diferentes espaços de tabela. Mas vale a pena agora?