sábado, 18 de fevereiro de 2012

O erro ORA-01194


Neste artigo vamos tratar o que significa o erro ORA-01194, quando este erro  ocorre e o que fazer para tentar corrigir este erro.

Uma das mensagens mais preocupantes que um DBA pode ler em sua tela é ORA-01194.
Mas quando essa mensagem pode ser apresentada ao DBA?

Abaixo os principais motivos:

  • Essa mensagem pode aparecer quando o DBA tenta renomear um banco de dados, utilizando a opção “create controlfile”, onde o DBA recria os “controlfiles” reapontando os “datafiles” mudando o nome do banco de dados e eventualmente o banco foi copiado (aberto) on-line, ou o backup estã inconsistente;
  • Quando numa queda inesperada do banco de dados, o DBA ao tentar levantar o banco de dados os arquivos de “redo logs” ficam desatualizados e são sobrescritos;
  • Ou por problemas no armazenamento do banco de dados (erros em discos, por exemplo).


Mensagem:ORA-01194: file 1 needs more recovery to be consistent ORA-01110: data file 1: '...../system01.dbf'”.

Causa: Uma sessão de restauração (recovery) incompleta foi iniciada, mas um número insuficiente de arquivos de “redo logs” foram aplicados tornando o arquivo inconsistente.

O arquivo não foi fechado corretamente quando ele foi aberto pela última vez pelo banco de dados. A causa mais provável desta mensagem é que o arquivo que foi copiado durante o backup apresentou problemas na restauração indicando o processo como incompleto.

Ação: O arquivo que deve ser recuperado está desatualizado. Devem-se aplicar os “archives” até que o arquivo fique consistente ou deve-se restaurar o arquivo de um backup mais antigo.


Se você como DBA já enfrentou esse tipo de erro, após fazer uma restauração do backup com sucesso pode ser necessário utilizar o parâmetro não documentado "_allow_resetlogs_corruption"

Porém antes de utilizar esse parâmetro vamos a uma explicação do que este parâmetro pode fazer.

Antes de pensar sobre o uso do parâmetro não documentado "_allow_resetlogs_corruption", todas as possibilidades de restauração devem ter sido esgotadas. Porque este parâmetro força a abertura dos arquivos de dados mesmo se suas informações não coincidirem. Ele não verificará a consistência dos arquivos de “redo logs”. Durante o próximo “checkpoint” do banco de dados os valores antigos do SCN serão sobrescritos. Isso pode deixar o banco de dados em um estado desconhecido (unknown state).

Depois de utilizar este método de recuperação, quando o banco de dados for aberto, o DBA deve exportar os dados e reconstruir o seu banco de dados. Porque neste método de recuperação algum arquivo será deixado para traz, acarretando problemas futuros com os dados, impossibilitando a abertura futura. Após a inicialização e desligamento do banco de dados o gerenciador irá solicitar a recuperação dos “redologs” antigos (archive logs) passando por todos os “redologs” disponíveis (on-line), inviabilizando a recuperação (geralmente o arquivo solicitado é o “id#1” referente a tablespace SYSTEM, sem esse arquivo o banco fica impossibilitado de abrir).

Mensagens mais comuns:

ORA-01194: file 1 needs more recovery to be consistent ORA-01110: data file 1: '..../system01.dbf'

ou

ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below ORA-01194: file 12 needs more recovery to be consistent ORA-01110: data file 12: ..../data01.dbf'

Se todos os “archive logs” disponíveis foram aplicados e todos os “redologs” disponíveis foram aplicados e o erro não for corrigido, só então que deve-se utilizar o parâmetro "_allow_resetlogs_corruption". Certifique-se de que um bom backup do banco de dados em um estado fechado (conhecido como “cold backup”) tenha sido executado antes da tentativa de recuperação usando o parâmetro "_allow_resetlogs_corruption".

Abaixo seguem os passos a serem executados para tentar a recuperação do banco de dados, utilizando o parâmetro "_allow_resetlogs_corruption".

1) Baixar o banco de dados, usar:
  SQL> SHUTDOWN IMMEDIATE;

2) Alterar o arquivo “init.ora” incluir a cláusula abaixo:
_allow_resetlogs_corruption = true

3) Levantar o banco de dados, usar:
 SQL> STARTUP MOUNT pfile='[caminho]+[nome_init.ora]' ;
 SQL> ALTER DATABASE OPEN RESETLOGS;

4) Se o banco de dados solicitar um “recover”,  deve-se utilizar o comando abaixo:
 
 SQL> RECOVER DATABASE UNTIL CANCEL;
 SQL> digitar [CANCEL]+[teclar ENTER]

Este comando indicará ao gerenciador de banco de dados que o “recover” foi efetuado, permitindo a abertura em sua sequência. Depois deve-se executar o comando abaixo:

 SQL> ALTER DATABASE OPEN RESETLOGS;

5)  Deve-se esperar alguns minuto para que o Oracle possa sincronizar os “datafiles” e abrir o arquivo.

 Comentário: Nesse momento os nervos do DBA são levados a prova intensa.

6)  Com relativa sorte, depois de aberto o banco deve-se executar os passos abaixo:
  SQL> SHUTDOWN NORMAL;

7)  Deve-se remover o parâmetro "_allow_resetlogs_corruption” do arquivo “initi.ora”

8) Levantar o banco de dados utilizando o arquivo “spfile”.
  SQL> STARTUP;

9) Deve-se verificar se existem erros no arquivo “alert.log”.

10) Por último deve-se executar uma exportação TOTAL  do banco de dados “export  full=y” e recriar o banco de dados para que o mesmo não apresente mensagens de erros futuras.




Rubens Oliveira
DBA Oracle Consultor
olivert.dba@consultant.com

quarta-feira, 8 de fevereiro de 2012

Suportando VLDB no Oracle Database


Neste artigo abordaremos as características do banco de dados Oracle para suporte a grandes bancos de dados, conhecidos também como VLDB  (Very Large Data Bases). O banco de dados Oracle atende essas características, abaixo veremos serão as principais:
  • Tablespaces com “datafiles” grandes (bigfiles)
  • Grupos de “tablespaces” temporárias
  • Desuso de índices com status de “UNUSABLE” – (Skip Unusable Indexes)
  • Indices Globais particionados em “HASH”


Tablespaces com “datafiles” grandes  (bigfiles)

Tablespaces “bigfiles” são tablespaces que possuem um “datafile” único com tamanho bem grande. Existem também as tablespaces “smallfiles” que podem ter vários arquivos de dados, mas cada um tem um tamanho limitado. Os benefícios de tablespaces “bigfiles” são:

  •  O banco de dados  tem um máximo de 64.000 “datafiles” o que limita sua capacidade total. Utilizar tablespaces “bigfiles” permite as tablespaces ter um único arquivo de dados grande o que aumenta a capacidade total do banco de dados. Uma tablespace “bigfile” com blocos de 8 K e 32 K pode conter de 32 terabytes até 128 terabytes num único “datafile”, respectivamente.
  • Usando “datafiles” maiores é possivel reduzir os parâmetros DB_FILES e MAXDATAFILES permitindo racionalizar os recursos da SGA e dos “controlfiles”.
  • A sintaxe do comando “ALTER TABLESPACE” permite operações em nível de tablespace, em vez de nível de “datafiles”, item suportado a partir da versão 10g.
Abaixo seguem alguns exemplos:

-- Comando Válido.

CREATE BIGFILE TABLESPACE mybigtbs
  DATAFILE '/u01/oracle/MYSID/mybigtbs01.dbf' SIZE 100G;

-- Comando Válido.

CREATE BIGFILE TABLESPACE mybigtbs
  DATAFILE '/u01/oracle/MYSID/mybigtbs01.dbf' SIZE 100G
  EXTENT MANAGEMENT LOCAL
  SEGMENT SPACE MANAGEMENT AUTO;
 
-- Comando Inválido.          

CREATE BIGFILE TABLESPACE mybigtbs
  DATAFILE '/u01/oracle/MYSID/mybigtbs01.dbf' SIZE 100G
  EXTENT MANAGEMENT DICTIONARY
  SEGMENT SPACE MANAGEMENT MANUAL;

O tamanho dos “datafiles” podem ser especificados em kilobytes (K), megabytes (M), gigabytes (G) ou terabytes (T).

Uma tablespace “smallfile” é um tipo de tablespace “default” durante a criação do banco de dados. Depois que o banco de dados é criado o comando ALTER DATABASE pode ser usado dinamicamente para alterar esta opção, abaixo um exemplo:

CREATE DATABASE mydb
  USER SYS IDENTIFIED BY password
  USER SYSTEM IDENTIFIED BY password
  SET DEFAULT BIGFILE TABLESPACE
  UNDO TABLESPACE undotbs
  DEFAULT TEMPORARY TABLESPACE temp;

ALTER DATABASE SET DEFAULT BIGFILE TABLESPACE;
ALTER DATABASE SET DEFAULT SMALLFILE TABLESPACE;

Quando uma tablespace “default” é definida como “bigfile” não é mais necessário na instrução CREATE TABLESPACE especificar a cláusula BIGFILE durante a criação de uma tablespace, mas para a criação de uma tablespace “smallfile” irá requerer a palavra-chave SMALLFILE. A situação ficará invertida da usual (opção “default” do banco de dados).

O comando ALTER TABLESPACE pode ser usado para modificar o tamanho e a extensão automatica de uma tablespaces “bigfile”, conforme exemplo abaixo.

ALTER TABLESPACE mybigtbs RESIZE 100G;

ALTER TABLESPACE mybigtbs AUTOEXTEND ON NEXT 10G;

Para visualizar o tipo da tablespace na coluna  BIGFILE com o valor  (YES/ NO) (sim ou não) nas visões DBA_TABLESPACES, USER_TABLESPACES e na V$TABLESPACE.
Alguns fatores adicionais a serem considerados antes de usar uma tablespace “bigfile” são:
  • Tablespace “bigfile” devem ser distribuídas para que as operações paralelas não sejam prejudicadas. O banco de dados Oracle é performático com tablespaces “bigfile” utilizando o Automatic Storage Management (ASM) ou outros gerenciadores de volumes lógicos que suportam striping ou RAID.
  • Tablespace “bigfiles” não devem ser usados em plataformas com restrições de tamanho de arquivo.

Grupos de Tablespace Temporárias

Grupos de tablespace temporárias permitem que os usuários usem mais do que uma tablespace temporária para armazenamentos temporários. O grupo de tablespaces temporárias  é criado im-plicittamente quando a primeira tablespace temporária é atribuída ao grupo.

-- Criando um grupo de tablespace para tablespaces temporárias existentes (agrupando tablespaces temporárias).

ALTER TABLESPACE temp TABLESPACE GROUP temp_ts_group;

-- Adicionando uma nova tablespace temporária a um grupo pré-definido.

CREATE TEMPORARY TABLESPACE temp2
  TEMPFILE '/u01/app/oracle/oradata/DB10G/temp201.dbf' SIZE 20M
TABLESPACE GROUP temp_ts_group;

As tablespaces temporárias atribuídas a um grupo podem ser visualizadas através da visão DBA_TABLESPACE_GROUPS.

SELECT * FROM dba_tablespace_groups;

GROUP_NAME                     TABLESPACE_NAME
------------------------------ ------------------------------
TEMP_TS_GROUP                  TEMP
TEMP_TS_GROUP                  TEMP2

2 rows selected.

Uma vez que o grupo é criado ele pode ser atribuído apenas com uma tablespace um usuário ou como uma tablespace temporária.

-- Atribuindo um grupo como o tablespace temporário para um usuário.
ALTER USER scott TEMPORARY TABLESPACE temp_ts_group;

-- Atribua grupo como o tablespace temporária (default).
ALTER DATABASE DEFAULT TEMPORARY TABLESPACE temp_ts_group;

Uma tablespace pode ser removida de um grupo, usando o comando abaixo.

ALTER TABLESPACE temp2 TABLESPACE GROUP '';

SELECT * FROM dba_tablespace_groups;

GROUP_NAME                     TABLESPACE_NAME
------------------------------ ------------------------------
TEMP_TS_GROUP                  TEMP

1 row selected.

Não há limite máximo teórico para o número de tablespace num grupo de tablespaces temporárias, mas deve conter pelo menos uma tablespace. O grupo implicitamente é descartado quando o último membro é removido. O último membro de um grupo não pode ser removido se o grupo ainda é atribuído como o tablespace temporária (default). Este exemplo deve ser feito para remover o último membro do grupo.

-- Mudar de grupo para um uma tablespace específica.
ALTER DATABASE DEFAULT TEMPORARY TABLESPACE temp;

-- Remover a tablespace de um grupo.
ALTER TABLESPACE temp TABLESPACE GROUP '';

-- Verificar se o grupo de uma tablespace temporária foi desfeito.
SELECT * FROM dba_tablespace_groups;

no rows selected.


Desuso de índices com status de “UNUSABLE”

A partir da versão 10g do Oracle pode-se definir o parâmetro SKIP_UNUSABLE_INDEXES como TRUE para que o Oracle não utilize indices desatualizados pelas estatísticas do banco de dados (DBMS_STATS), esse parâmetro também inibe mensagens de erro quando o índice está marcado como “UNUSABLE”.

Para a ativação do parâmetro SKIP_UNUSABLE_INDEXES pode-se utilizar os comandos ALTER  SYSTEM e 
ALTER SESSION como estão apresentados abaixo.

ALTER SYSTEM SET SKIP_UNUSABLE_INDEXES = TRUE;
ALTER SYSTEM SET SKIP_UNUSABLE_INDEXES = FALSE;

ALTER SESSION SET SKIP_UNUSABLE_INDEXES = TRUE;
ALTER SESSION SET SKIP_UNUSABLE_INDEXES = FALSE;

Essa configuração não pode funciona para índices de (PK) ou para indices que suportam restrições únicas e são usados para ignorá-las levando a violação da restrição (constraint violation).


Índices Globais Particionados em “Hash”

Índices globais podem ser particionados utilizando a estrutura de “hash”, a sintaxe é apresentada abaixo.

--Criação da tabela MYTABLE
CREATE TABLE mytable (
  column_1  NUMBER(10),
  column_2  VARCHAR2(10),
  column_3  NUMBER(10),
  column_4  VARCHAR2(50)
);

--Criação do índice MYINDEX
CREATE INDEX myindex ON mytable (column_1, column_2, column_3)
  GLOBAL PARTITION BY HASH (column_1, column_2)
    (PARTITION myindex_part_1 TABLESPACE users,
     PARTITION myindex_part_2 TABLESPACE users,
     PARTITION myindex_part_3 TABLESPACE users,
     PARTITION myindex_part_4 TABLESPACE users);

A manutenção de índices “hash” globais particionados  podem  ser executadas usando as instruções a seguir.

-- Adicionando uma nova partição ao índice.
ALTER INDEX myindex ADD PARTITION mytable_part_5;

-- Reduzindo o número de partições para 1.
ALTER INDEX myindex COALESCE PARTITION;

-- Reconstruindo uma partição.
ALTER INDEX myindex REBUILD PARTITION mytable_part_1 TABLESPACE users;

-- Renomeando uma partição.
ALTER INDEX myindex RENAME PARTITION mytable_part_1 TO mytable_part_a;



Rubens Oliveira
DBA Oracle Consultor
olivert.dba@consultant.com