Pular para o conteúdo principal

Postagens

Mostrando postagens de 2011

Usando o RMAN para verificar corrupção no banco e em backups

- Primeiro é interessante entendermos a diferença de uma corrupção lógica para uma física.        Física: Uma corrupção física ocorre quando o conteúdo do bloco não corresponde ao formato físico que o Oracle espera. Por padrão o RMAN realiza uma         verificação física sempre que ocorre um backup, um restore ou um validate.     Lógica: O bloco está no formato correto, mas o conteudo não corresponde ao esperado pelo Oracle. Exemplos de corrupção lógica seriam: corrupção         em um pedaço de uma linha ou uma entrada de índice. - O RMAN pode ser usado para identificar corrupção em datafile, controlfiles, archivelogs. Podemos também saber se uma peça de backup é restaurável. O RMAN VALIDATE pode ser usado para verificar esses tipos de integridade. Existem três tipo para o comando:  - VALIDATE  - BACKUP ... VALIDADTE  - RESTORE ... VALIDATE Obs: O comando VALIDATE usado sozinho só é válido a partir da versão 11g. # VALIDATE  O VALIDATE pode ser usado para checar a localização

ORA-00600: internal error code, arguments: [kccpb_sanity_check_2]

       Depois de um pico de energia e do desligamento inesperado do storage, quando fui tentar abrir uma das bases (10.2.0.4) recebi uma mensagem não muito agradável : 08:41:53 SYS@EADTR > startup ORACLE instance started. Total System Global Area 1610612736 bytes Fixed Size                  2084400 bytes Variable Size             385876432 bytes Database Buffers         1207959552 bytes Redo Buffers               14692352 bytes ORA-00600: internal error code, arguments: [kccpb_sanity_check_2], [8706], [5700], [0x000000000], [], [], [], []        Pelo startup acima, podemos ver que o problema ocorre no momento que o banco procura o controlfile, então a solução foi pegar meu último backup e restaurar o controlfile. RESTORE CONTROLFILE FROM AUTOBACKUP;       Depois de restaurado o controlfile, consegui abrir a base para novas conexões sem maiores problemas.

Novo bug criado junto a Oracle: BUG-11887892

Recentemente passamos por alguns problemas de performance com alguns recursos do Oracle 11g SPM( SQL Plan Management Base) e SMB (SQL Management Base) em nosso ambiente Oracle RAC 11g R2 muito bem detalhado pelo meu parceiro Eduardo. Segue o link : http://dbavalentim.blogspot.com/2011/03/merge-na-sqlobjauxdata-com-full-table.html

Restore e recover Oracle usando backups incremental

No ambiente de testes verifiquei algo que não sabia. Um backup incremental Level 1 , diferencial ou cumulativo não é usado no restore e sim no recover. Um backup level 1 é como se fosse um pacote de archives. No momento do recover se o Oracle encontrar uma peça de backup incremental level 1 que contenha todas as alterações necessária para recuperação da base, ele da prioridade ao backup incremental deixando os archives em segundo plano. Baseado nisso, podemos dizer que é como se os level 1 fossem uma segurança a mais no momento do recover. Para comprovar veja os passos que fiz abaixo. Primeiro executo um backup incremental level 0 RMAN> backup incremental level 0 database; Starting backup at 21-JAN-11 using channel ORA_DISK_1 channel ORA_DISK_1: starting incremental level 0 datafile backup set channel ORA_DISK_1: specifying datafile(s) in backup set input datafile file number=00001 name=/u01/app/oracle/oradata/CANSADA/datafile/o1_mf_system_6mm2dr9k_.dbf input datafil

Identificando a versão do seu banco de dados Oracle

 - O primeiro dígito é o identificador geral. Ele representa a ultima versão do software, a que possui significantes novas funcionalidades.  - O segundo número representa a versão de level de manutenção. Algumas novas funcionalidades podem ser incluídas.  - O terceiro, mostra o a versão do level do Oracle Fusion Middleware  - O quarto, identifica a versão do level de um componente específico. Componentes diferentes podem possuir diferentes números, dependendo por exemplo conjunto de patches ou versões provisória.  - O quinto dígito identifica uma versão para uma plataforma específica. Normalmente é um patch set. Quando diferentes plataformas requerem um nivel equivalente de patch set, o dígito será o mesmo para todas as plataformas afetadas. Nota: Iniciado na versão 9.2, as versões de manutenção do banco de dados Oracle são indicados por uma mudança no segundo dígito. Em versões anteriores, o terceiro número indicava uma versão particular de manutenção.   Verificando su