Tablespace I

Bom Noite pessoal!!!!

Já estava na hora de vir aqui postar(rsrs). Vocês sabem como é a correria na nossa profissão, prometo que vou tentar toda semana postar alguma coisa.
Mas vamos deixar o bláblá de lado e mãos a obra.

Hoje de manhã peguei o santo ônibus de cada dia, o ônibus lotadão aquele calor humano rsrs daí pensei caramba eu podia escrever algo no blog sobre armazenamento
de dados (dãããã - bem redundante isso já que somos profissionais de banco de dados rsrs). Pensei vou escrever sobre Tablespace esse é o tema do post.

No Oracle temos as estruturas lógicas e as estruturas fisicas, a estrutura lógica é a nossa conhecida Tablespace e as
estruturas físicas são os famosos datafiles, sendo assim uma tablespace pode ter mais de 1 datafile se necessário. Datafile fica armazenado no Sistema operacional (assunto para outro post).
A tablespace serve para organizar os objetos lógicos no banco de dados, por exemplo temos que criar umas 10 tabelas com 4Mb, 12 tabelas com 128Mb e 100 tabelas com 128kb,
A ideia seria criarmos 3 tablespaces exemplo:

Tablespace TS_TAB_4M        << Armazenamento das tabelas de 4M
Tablespace TS_TAB_128M   << Armazenamento das tabelas de 128M
Tablespace TS_TAB_128k     << Armazenamento das tabelas de 128K

Nossas tabelas já estão organizadas beleza só alegria rsrs. Mas opa e aonde eu ponho os indices? nas mesmas tablespaces? Ahh meu amigo se isso passou pela sua cabeça hahah desiste da carreira!!!
já que criamos as tablespaces para as tabelas, pultz cria também pros indices tipo assim:

Tablespace TS_IDX_4M      << Armazenamento dos indices de 4M
Tablespace TS_IDX_128M  << Armazenamento dos indices de 128M
Tablespace TS_IDX_128K   << Armazenamento dos indices de 128K

Pessoal existem 2 tablespaces no Oracle que são o bicho, NUNCA, veja bem NUNCA MESMO, crie qualquer tipo de objeto nas tablespaces SYSTEM e SYSAUX pois essas tablespaces contém o dicionário de dados do Oracle
e JAMAIS coloquem elas em OFFLINE, se por acaso essas meninas entrarem em OFFLINE não vai acontecer nada de mais, só sua instancia irá abortar, seu banco cair,
se isso acontecer você irá escutar um monte de usuários, seu chefe, seu diretor todos enchendo o saco e te fazendo um monte de perguntas (rsrs)

Tipo quando tempos tudo organizado em tablespaces temos uma maior flexibilidade dos dados, quando uma base de dados tem múltiplas tablespaces podemos fazer:

Separar os dados dos usuários dos dados do dicionário do Oracle reduzindo a contenção entre objetos do dicionário e objetos do esquema;

Separar os dados de uma aplicação da outra para evitar os acessos múltiplos a uma única tablespace, ajudando assim na manutenção da tablespace de uma certa aplicação;

Armazenar diferentes tablespaces e diferentes datafiles no disco para reduzir a contenção de I/O;

Manutenção em aplicações sem afetar outras aplicações, exemplo tenho 3 aplicações na mesma base, aplicações essas A, B e C. você pode tirar a aplicação A do ar fazer a manutenção sem ter que afetar a aplicação B e C;

Realizar o backup individual de cada tablespace.

Os sitemas operacionais tem por default um limite de arquivos que podem ser abertos simultaneamente, esses limites podem afetar o número de tablespaces online acessadas ao mesmo tempo. Para tentarmos não exceder o limite do sistema operacional devemos estudar de forma eficiente a distribuição de nossas tablespaces, tentando criar somente tablespaces necessárias com definição de tamanho máximo, caso perceba que ela irá estourar temos a opção de adicionar datafiles novos ou de colocar o datafile atual como autoextend

Bom Pessoal esse é um post mais para um entendimento para o que serve um tablespace e da importância do mesmo para o gerenciamento dos dados.
Vou ficando por aqui no proximo post vou tentar explicar as Tablespces UNDO, USERS, TEMP, ... etc

Comentários sobre RMAN

Bom, pessoal estou eu aqui novamente para mais um post, como tinha prometido vou falar um pouco sobre o utilitário RMAN, mas antes vamos relembrar um pouco sobre a postagem anterior. Foi discutido diversas maneiras de backup, backups on-line, off-line. Pois então, os backups físicos do Oracle asseguram que a transação que não foi confirmada será perdida, e podemos restaurar o banco de dados a partir de qualquer backup anterior até o ponto atual. Entretanto os backups lógicos permitem que nós DBA(s) ou até mesmo os usuários possam capturar os objetos de banco de dados individuais em um ponto particular no tempo, fornecendo assim uma opção de recuperação alternativa quando uma operação de restauração de banco de dados completa teria um impacto muito grande no restante do banco de dados.

Com o Recovery manager ou mais conhecido como RMAN, leva o backup e a recuperação do mesmo a um nível de proteção e facilidade de uso impressionantes. Podendo ser executado através de linha de comando ou para aqueles que preferirem utilizar o OEM para efetuarem seus backups. Vamos tentar ver aqui exemplos dos dois tipos mencionados.

Bom como RMAN é um assunto bem grande, irei quebrá-lo em algumas partes, para que a galera não se assuste e sai se tacando do 20º andar, afinal não queremos isso né

BACKUP e RECOVER

Boa tarde pessoal...

Este é meu primeiro post aqui no blogspot, vou falar um pouco sobre opçoes de backup e recuperação e tentar explicar ao maximo aquela famosa frase do DBA "backup bom é aquele que volta" rsrs...


Bom, backup e recover é um assunto um tanto quanto delicado, até porque muitos profissionais não dão muita atenção para ele, ou por falta de experiência ou por mero desleixo. Mas nós não, nós estamos aqui para realmente fazer a diferença, então temos que ter em mente que um servidor deverá ter uma boa rotina de backup tanto lógico como físico. O importante é que os dados estejam seguros não importa de qual maneira utilizaremos, mas se não há perda de dados então ta ótimo.

Nós temos 3 métodos de fazer backup de um banco de dados Oracle, temos exportações, backups off-line e backups on-line.

Uma boa estratégia de backup inclui tanto backups físicos(off-line e on-line) como backups lógicos(exportações).

BACKUPS LOGICOS – o famoso EXP/IMP é um tipo de backup que não se preocupa com a parte física do banco de dados, ele apenas envolve a leitura de um conjunto de registros do banco de dados e a gravação destes em um arquivo. O Data Pump Export do Oracle consulta o banco de dados e o dicionário de dados, e grava a saída em um arquivo XML chamado arquivo de dump de exportação. Podemos exportar todo o banco de dados, com um export full, ou podemos apenas exportar 1 ou 2 tabelas, ou um shema inteiro, depende do objetivo de cada um. Lembrando que a importação poderá ser feita em qualquer momento, e poderá escolher também o que será importado.

BACKUPS FISICOS – envolvem a copia dos arquivos que constituem o banco de dados. O Oracle suporta 2 tipos de backups físicos, são eles os backups online e offline, podemos usar o utilitário RMAN para nos auxiliar nesse tipo de backup. Opcionalmente, podemos optar por escrever nossos próprios scripts de backup físico, desprezando assim muitos benefícios do uso do RMAN.

Backup Off-line – com o banco off-line devemos fazer o backup de todos os arquivos de dados, controles, de todos os log de red-online, do arquivo init.ora e do arquivo de parâmetro de servidor(spfile).

Backup Online- para esse tipo de backup devemos verificar se o ARCHIVELOS está on para isso devemos ter um privilegio de DBA para executar o seguinte parâmetro ARCHIVE LOG LIST, com esse parâmetro saberemos se o archive log esta ativado ou não. Com o banco aberto devemos fazer o backup de todos os arquivos de dados, todos os arquivos de log de redo arquivados em repositórios de arquivos, de um dos arquivos de controle, por meio do comando alter database.

Devemos sempre nos lembrar que um bom backup é aquele que volta,
Uma rotina de backup deve ser bem planejada. Para melhores esclarecimentos sobre como planejar a rotina de backup pro servidor vejam em http://profissionaloracle.com.br/blogs/rodrigoalmeida/ no tópico Uma visão geral sobre backup & Recover.

Abraços e até a próxima!!!!