Tablespaces e Datafiles
- Um tablespace pode ter muitos datafiles;
- Um tablespace pode ter muitos segmentos;
- Um segmento é composto por uma ou mais extensões;
- Uma extensão é composta de muitos blocos consecutivos em um datafile;
- Um bloco do Oracle deve ser composto de um ou mais blocos do sistema operacional;
- O bloco do Oracle é a granulidade de I/O do banco de dados;
Gerenciamento de Tablespaces
- Tablespace SMALLFILE pode ter muitos datafiles, mas um tablespace BIGFILE pode ter apenas um;
- Os tablespaces têm como padrão o gerenciamento local de extensões, o gerenciamento automático de espaço de segmento, mas não um tamanho de extensão uniforme;
- Os datafiles OMF são automaticamente nomeados, iniciam com 100MB e podem estender sem limite, de forma automática;
- Um tablespace que contém segmentos não pode ser descartado, a menos que uma cláusula INCLUDING DATAFILES seja especificada;
- Tablespaces podem ser online ou offline, leitura e gravação ou somente leitura;
- Tablespaces podem armazenar três tipos de objetos: objetos permanentes, objetos temporários ou segmentos de undo.
Gerenciamento de espaço nos tablespaces
- O gerenciamento local de extensões controla a alocação de extensões em cada datafile com bitmaps;
- A cláusula UNIFORM SIZE durante a criação de um tablespace obriga todas as extensões a terem o mesmo tamanho;
- A cláusula AUTOALLOCATE permite que o Oracle determine o tamanho da próxima extensão, que é baseado na quantidade de extensões que estão sendo alocadas para um segmento;
- O gerencimanto automático de espaço de segmento controla o espaço livre em cada bloco de uma extensão usando bitmaps;
- É possível converter um tablespace do gerencimanto de extensões por dicionário para gerenciamento local de extensões, mas não de um gerenciamento de segmento por freelist para um gerenciamento automático.
ASM
- O ASM pode armazenar somente datafiles, não os binários. O Oracle Home sempre deve estar em um sistema de arquivos convencional;
- O ASM faz striping de arquivos, não de volumes. O espelhamento é opcional, o striping não.
Gerenciando estruturas de armazenamento de banco de dados
É essencial estar absolutamente claro o modelo de armazenamento do Oracle: a abstração do armazenamento lógico para o físico, o que significa que não há relacionamento direto entre uma tabela (ou qualquer outro tipo de segmento) e um datafile. O gerenciamento de espaço é muito mais simples na versão atual do que nas versões anteriores e pode ser, de fato, completamente automatizado usando o OMF. Tudo o que é sempre necessário, uma vez que os parâmetros foram configurados, é o simples comando:
CREATE TABLESPACE tablespacename;
e, em seguida, permitir que o Oracle faça o resto. O uso de bitmaps par ao gerenciamento de extensões e para gerenciamento de espaço dentro de segmentos possibilita uma grande melhoria de desempenho sobre as versões anteriores. As técnicas anteriores só são suportadas para manter a compatibilidade com versões anteriores. É possível converter as estruturas de armazenamento existentes para os métodos mais recentes.
O Database Control inclui excelentes ferramentas gráficas para gerenciar tablespaces e datafiles, mas, para fins de informações, normalmente será necessário consultar as views de dicionário de dados e de desempenho dinâmico.
Resumo da Certificação
O paradigma de banco de dados relacional requer uma separação do armazenamento lógico, com ovisto pelos programadores, para o armazenamento físico, visto pelos administradores de sistema. O Oracle implementa esse paradigma com tablespaces. Dentro de um tablespace, os segmentos são feitos de extensões que são compostos de blocos do Oracle.
As técnicas atuais de gerenciamento de espaço com bitmaps, tanto para alocar extensões para segmentos quanto para identificar blocos dentro de um segmento que são adequados à inserção de linha, são muito superiores às técnicas anteriores e sempre devem ser usadas. Combinadas com o OMF e o ASM, elas podem tornar o gerenciamento de espaço completamente automatico.
Referência Bibliográfica
Este post, assim como todos os posts sobre Certificação OCA deste blog, são trechos do livro “OCA Oracle Database 11g – Administração I (Guia do Exame 1Z0-052)”, da editora Bookman – www.bookman.com.br
Recomendo este livro a todos que pretendem estudar para o exame. Meus posts são apenas algumas dicas para quem já está estudando por outros materiais, e por isso exige uma base de conhecimento anterior em cada um dos capitulos. Para uma referência completa de estudos é recomendado a compra do livro correspondente, bem como a documentação oficial da Oracle.
![[Oracle] OCA 11g – Gerenciando Dados de Undo](https://certificacaobd.com.br/wp-content/themes/Extra/images/post-format-thumb-text.svg)
![[Oracle] OCA 11g – Executando Backups](https://certificacaobd.com.br/wp-content/uploads/2013/04/oracle_oca_dest.jpg)
Otimo resumo! Obrigado!
Poderia me ajudar numa duvida sobre esse topico ( Estruturas de armazenamento ) – Capitulo 6 do material oficial da Oracle e Capitulo 5 do livro All in One
Fiquei com uma duvida sobre a opção de LOGGING para quando vamos criar uma tablespace. Eu li no livro All in One que:
“If logging is disabled, this provides a default for the very few operations where redo generation
can be disabled, such as index creation. Whatever setting is chosen, all DML operations
will always generate redo.”
No material oficial da Oracle diz:
“…If logging is not enabled, any direct loads using SQL*Loader and direct load INSERT operations are not written to the redo log, and the objects are thus unrecoverable in the event of data loss. When an object is created without logging enabled, you must backu up those objects if you want them to be recoverable.”
Acabei ficando com duvida.
No All in one parece dizer que mesmo com a opcao NO LOGGING será gerado informacao de REDO. Diz que a opcao de NO LOGGING deixa de gerar Redo apenas para poucas opcoes como a criacao de indices…
Ja no material oficial o que entendi é que se deixar como NO LOGGING nao gera informacao de Redo e ponto final.
Pode por gentileza me ajudar a entender essa questao?
Desde ja muito obrigado!
Daniel, bom dia.
Eu estou para terminar um post que estou escrevendo da apresentação do Fco Muñoz no GUOB TECH DAY desse ano sobre isso LOGGING e NOLOGGING.
Assim que concluir eu publico, acredito que até final da semana.
Mas para te deixar mais tranquilo, existem muitos poréns dentro desse mundo. Alguns que criam na marra, outros que não criam e outros que podem ser controlados para criar ou não.
Vamos ver se o Milton contribui com algo antes de eu terminar o post.
capin
Olá Daniel!
Na verdade vc comparou coisas diferentes.
No seu segundo trecho (material oficial da Oracle), o assunto é específico sobre SQL*Loader e direct load INSERT. Ele diz que essas operações, com o logging desativado, são irrecuperáveis.
No livro All in One, o assunto e mais abrangente, falando de objetos de uma maneira em geral (tabelas, índices, operações DML). Ele diz que mesmo vc criando a tablespace com a opção NOLOGGING, ele SEMPRE irá gerar REDO – e isso é verdade. Pelo menos um pouquinho de redo será sim gerado – em operações DML. Repare que ele foi bem claro nesse ponto: “… all DML operations will always generate redo.”
Só que cargas realizadas via SQL*Loader não são operações DML!
E quando se faz um INSERT usando direct load também é considerada como CARGA de dados, e vc não deve considerar como uma operação DML “comum”.
De qualquer maneira, em qualquer um dos casos – DML ou cargas, você tem que estar ciente de que a opção NOLOGGING irá diminuir tua segurança em relação a recuperação em caso de falha ok?
Capin valeu, aguardo seu post! 🙂
Milton, valeu pelo esclarecimento.
Realmente o material da oracle faz uma referencia ao SqlLoader dentro da opcao de criação de tablespaces…ae acabei me confundindo…. pq ele nao cita o fato de outras operacoes gerarem redo, passou batido…. Coisa que o All in One acabou citando….mas sem muitos detalhes tambem.
O fato é q o professor disse que ao criar uma tablespace se vc selecionar NO LOGGING ele nao gera nada de redo.
O que me leva a entender q ele se equivocou…certo?
Eu gostaria de entender a diferenca entre os 2. Ja q se o “LOGGING” gera REDO. Estranho dizer que o “NO LOGGING” tambem gera. Onde posso ler sobre as diferenças claras sobre as 2 opções ao criar a tablespace?
Para estudar para a prova, o que realmente é importante saber?
Valeu por todo esclarecimento e parabens pelo site!
att
Daniel Esquerdo