Este é um post disponível para assinantes MVP
dê seu feedback
post favorito
Administrando Tablespaces e Datafiles no Oracle - Revista SQL Magazine 89
Este artigo trata da definição de conceitos e administração de tablespaces e datafiles no banco de dados Oracle.
[Artigo já está disponível no Leitor Digital DevMedia®. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da SQL Magazine 89
Dados! Esta é a palavra chave quando se fala em banco de dados. Toda a tarefa do DBA está pautada em garantir a integridade e disponibilidade dos dados.
Mas não se pode esquecer que, além de garantir que os dados estejam disponíveis e íntegros no momento em que forem solicitados, é de extrema importância garantir que novos dados possam ser armazenados e permaneçam disponíveis/íntegros. É um ciclo interminável na vida de todo DBA.
Esta tarefa de gerenciamento do espaço alocado/disponível para o crescimento das tabelas e índices está pautada diretamente no gerenciamento físico e lógico das áreas de armazenamento do banco de dados, que é feita através das tablespaces (armazenamento lógico) e dos datafiles (armazenamento físico).
Neste artigo apresentaremos alguns scripts bastante úteis para que o DBA execute esta tarefa do dia-a-dia de uma maneira bastante tranquila e segura. Boa Leitura.
Conceito de Tablespace
Tablespace é uma estrutura lógica do banco de dados Oracle para o armazenamento dos segmentos. São considerados segmentos os objetos Oracle que “ocupam” espaço, como por exemplo as tabelas e índices.
Pode-se (e recomenda-se) criar várias tablespaces para “separar” de maneira lógica diferentes segmentos, até mesmo em função de ganho de desempenho do banco de dados. Uma divisão clássica é a criação de uma tablespace para armazenar os segmentos de tabelas e outra tablespace para armazenar os segmentos de índices.
Fisicamente, no nível do sistema operacional, o armazenamento é feito através de datafiles, que são arquivos de sistema operacional com tamanhos definidos e que podem ser “vistos” no sistema operacional através de comandos simples como “ls -l” (UNIX) ou “dir” (MS-Windows).
Desta forma, para fazer a devida relação entre as estruturas lógica (tablespaces) e física (datafiles), cada tablespace é formada por um ou mais datafiles porém, cada datafile pode “servir” a uma e somente uma tablespace. A Figura 1 mostra o esquema geral destas estruturas física e lógica.
Perceba, na Figura 1, que é perfeitamente possível armazenar diferentes segmentos (tabelas e índices) na mesma tablespace, porém por questões de boas práticas, não é recomendado. Veja também que a tablespace é composta por dois datafiles e que cada datafile é parte de apenas uma tablespace.
Administrando as Tablespaces
A primeira tarefa é verificar qual o espaço utilizado e o espaço disponível em cada uma das tablespaces presentes no banco de dados. A Listagem 1 apresenta um script bastante útil para esta verificação.
Listagem 1. Verificando o espaço utilizado e espaço disponível nas tablespaces.
1. SQL> SET LINE 180 PAGES 9999 TIMING ON
2. SQL> COL TABLESPACE FOR A10
3. SQL> COL TOTAL_MB FOR 9,999.99
4. SQL> COL USED_MB FOR 9,999.99
5. SQL> COL MB_FREE FOR 9,999.99
6. SQL> COL LARGEST FOR 999.99
7. SQL> COL "%_USED" FOR 999.99
8. SQL> BREAK ON REPORT
9. SQL> COMPUTE SUM OF TOTAL_MB ON REPORT
10. SQL> COMPUTE SUM OF MB_FREE ON REPORT
11. SQL> COMPUTE SUM OF USED_MB ON REPORT
12. SQL> SELECT A.TABLESPACE_NAME TABLESPACE,
13. 2 A.BYTES/1048576 TOTAL_MB,
14."
ATENÇÃO! A exibição deste artigo foi interrompida.
Este é um post disponível para assinantes MVP
2 COMENTÁRIOS
Sugiro uma continuação do artigo para abordar as tablespaces UNDO e TEMP pois estas tem um comportamento diferenciado.
Aqui temos dificuldade de avaliar o espaço necessário para ser alocado aos tablespaces (dados, índices, lob) quando um novo sistema/módulo é desenvolvido. Alguém tem algum dica neste sentido? Como a partir do modelo físico da aplicação podemos estimar estes recursos?
Obrigado por seu comentário. É sempre importante e gratificante a participação do leitor.
Com relação ao Database Control, sim, é possível realmente deixar tudo configurado e receber alertas quando as métricas são atingidas porém, em muitos casos, o ambiente gráfico não está disponível ou a política da empresa não permite que o agente esteja em execução no servidor (tenho vários clientes nestas situações) e, desta forma, nada de Database Control.
É necessário "se virar" com scripts agendados na "crontab" ou coisa assim. Para estas situações, os scripts que disponibilizei são bastante úteis.
Com relação a TEMP e UNDO, apenas o dia-a-dia da aplicação fará com que o DBA possa definir um tamanho aceitável para ambas. Muitos problemas com ordenações indicam necessidade de aumentar a TEMP e muito "snapshot too old" indica a necessidade de aumentar a UNDO. Só o tempo fará com que o DBA consiga definir um valor aceitável e, após atingido este valor, os problemas de ordenação e "snapshot too old" levam o DBA a consulta (neste ponto, somente uma ou outra consulta apresentará problema, então é hora do tuning). ;-)
Espero ter ajudado.
Abraços
Ricardo Rezende
Space do autor
0
0
