Olá!
A GPO já colocou a disposição em seu website a apresentação sobre a ferramenta RMAN que foi utilizada para a palestra na V ENPO para consulta dos profissionais. Acho legal realizarem o download do power point, pois a apresentação traz mais detalhes sobre a ferramenta e técnicas de backup e recover.
Para fazer o download, basta clicar aqui. E caso tenha dúvidas ou sugestões, fique a vontade para entrar em contato.
Abraços,
Olá,
Demorei um pouco para postar como foi o Encontro Nacional de Profissionais Oracle que ocorreu no sábado passado (29/11/2008) na FIAP, pois estava numa correria danada e precisando um pouco de descanso.
Bom, como todas as edições da ENPO, tivemos ótimas palestras, oportunidade de conhecer diversos profissionais oracle, aumentando a rede social e agregar conhecimentos.
Nessa edição, tive o prazer para poder palestrar sobre um tema bem discutido, que é backup e recover com RMAN. Bem, a apresentação tinha bastante slides e o assunto é extenso, tive 1 hora para contar os conceitos básicos da arquitetura da ferramenta rman e suas principais funcionalidades, foi um pouco corrido, mas acho que deu para o público conhecer e entender um pouco sobre essa maravilhosa ferramenta. Em breve a apresentação estará disponível no site da ENPO e GPO.
Tivemos outras palestras bem interessantes também, como do nosso parceiro de blog e comunidade Oracle Ricardo Portilho que discutiu sobre o Load Balance em RAC, que teve uma apresentação bastante divertida (principalmente a imagem do balanceamento de cerveja entre a mulher e o homem), tive o prazer de conhecer pessoalmente, e é um cara super gente fina! Vale a recomendação de conhecer o blog dele também aqui na GPO com contéudo bem legal.
Outras palestras como o Chiappa, que discutiu um pouco sobre a utilização e o modo de utilizar a ferramenta SQL*Plus, o nosso velho e bom amigo de todos os dias, tivemos também Roberto Serson, ou show man Oracle, falando um pouco sobre Expressões Regulares, que se existe um desenvolvedor que gosta da trabalhar com a metodologia POG, ao conhecer as expressões regulares, ninguem mais irá dar manutenção em seus códigos! =D
Para o público, tivemos ainda uma boa visão geral de como trabalha o Oracle Spatial, que teve como palestrante o profissional Marcos Couto, de como o BI trabalha no geral como o Francisco Piedade, que detalhou e mostrou experiência no assunto.
E como todo palestrante, abaixo segue a imagem do meu novo trófeu recebido pelos organizadores da ENPO, que será guardado com muito carinho.
Gostei da participação da galera no geral, e desculpas por não ter dado muita atenção ao pessoal que veio tirar dúvidas durante os coffee breaks ou me esperado para almoçar, pois estava muito corrido o dia e muita gente comigo também, então estava díficil administrar tudo, quem quizer ainda discutir alguma coisa, fique a vontade de mandar e-mails para mim.
E agradeço aos organizadores (Fernanda, Morgado e Willians) pela oportunidade e aos amigos, tanto da iMasters, Affinia, Pellegrino, GPTI, IBTA e aos leitores em geral que compareceram ao evento.
Abraços,
Olá,
Uma dos maiores problemas de realizar uma recuperação completa ou uma restauração de um banco de dados para um novo servidor, é o problema de mencionar o DBID (Database Identifier - Identificação do banco de dados) para o catálogo do RMAN.
Pois, para conseguir uma restauração da base, é necessário mencionar o DBID ao catálogo de recuperação para conseguir associar o banco de dados no catálogo e posteriormente restaurar e recuperar seus backups sets.
Agora, vamos mencionar quais os meios que podemos encontrar o DBID de um banco de dados.
1. Dicionário de dados
Podemos realizar um simples select na view v$database para conseguir a informação, veja.
SQL> select dbid from v$database;
DBID ---------- 4263396950
1 linha selecionada.
2. RMAN - Inicío de sessão
O DBID também é informado quando você conecta ao RMAN, lembrando, que o DBID será informado se o banco de dados estiver em MOUNT ou OPEN, se apenas com NOMOUNT, não será informado, pois não irá ler o arquivo de controle, ou control file. Exemplo.
[oracle@PELSPOWMS2 ~]$ rman
Recovery Manager: Release 10.2.0.1.0 - Production on Thu Oct 23 17:15:23 2008
Copyright (c) 1982, 2005, Oracle. All rights reserved.
RMAN> connect target ‘rman/##########@wmssp.world’;
connected to target database: WMSSP (DBID=4263396950)
RMAN>
3. RMAN - Usando o comando List incarnation
Outro modo de se conseguir o DBID do banco de dados, é após logar-se no banco de dados target e estar conectado ao catálogo de recuperação, utilizar o comando LIST INCARNATION, exemplo:
RMAN> list incarnation; List of Database Incarnations DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time ------- ------- -------- ---------------- --- ---------- ---------- 8451 8458 WMSSP 4263396950 PARENT 1 30/06/2005 19:09:40 8451 8452 WMSSP 4263396950 CURRENT 446075 27/02/2008 09:03:20
RMAN>
Uma dica muito importante é sempre manter uma planilha com todos os bancos de dados, senhas e seus respectivos DBID armazenados após as criação do banco de dados para não correr risco de não saber o DBID do banco de dados criado.
Abraços,
Olá,
Semana passada o nosso velho e bom amigo Metalink ficou de cara nova, e também com um apelido novo, chamado agora de My Oracle Support (Site: http://metalink.oracle.com), criado boa parte em Flash (Actions Scripts FORTES!) e com novas funcionalidades integradas ao SCM (Software Configuration Manager), apresentou uma cara bem bonita e uma razoável navegação.
Abaixo mostro um pequeno screenshot da nova tela inicial do Metalink, ou My Orale Support.
Ao acessar o metalink, algumas novidades apareceram como: Dashboard, Community, Reports e Collector. O mais bacana das opções é o Dashboard, que sumariza todas as informações da sua conta em uma única tela, tais informações como seus SR (Service Request - ou TAR), informações sobre suas bases que estão coletando informação pelo OCM (Oracle Configuration Manager), inventário e Projects . O screenshot mostra a tela de dashboards.
O metalink sempre foi o canal para entrar em contato com o suporte da Oracle, para aqueles problemas difíceis de se resolver, a qualidade do suporte não mudou muita coisa, continua o mesmo (Quem usa sabe!), porém ao abrir um SR (ou TAR), você pode ter mais integração com o suporte e informação disponível da sua conta em um pequeno boxtext, como apresentado abaixo.
O My Oracle Support está com bons recursos, entre eles, podemos destacar:
MapView
Ao abrir um SR, você já pode mencionar em qual banco de dados está o problema, atribuindo as informações que estão armazenadas no repositório da Oracle ao SR. Essas informações são retiradas dos relatórios de RDA ou pelos coletores do SCM.
PowerView
Um recurso do My Oracle Support que permite filtrar informações por região do aplicativo, customizando as informações que acordo com o seu interesse. As regiões podem ser Knowledge base, Projects, System, System Health e Service Request.
System Health
Um monitor que analisa a saúde de seus bancos de dados e aplicativos, como Application Server e EBS (E-Bussiness Suite), monitora informações de segurança, patch e recomendações. Ótimo para equipes que querem atuar com pró-atividade.
Web Seminars
Dentro da região Knowledge, existe a opção Tools and Training > Training (Web Seminars). Uma ótima sacada da Oracle para seus profissionais. A intenção é fornecer seminários e treinamentos gratuitos para seus produtos de suporte, como RDA, SCM, E-Bussiness Diagnostics entre outros. Dessa forma, trabalhar de acordo com os padrões Oracle e entender todas as ferramentas e seus respectivos fluxos de chamado.
Esses são apenas alguns itens que gostei de comentar sobre a nova ferramente da Oracle de suporte, para quem já é assinante Metalink, vale a pena dar uma navegada no site e descobrir muito mais coisas. O site em sí ainda é meio lento, mesmo para quem usa conexão DSL ou dedicada está bom, mas, para quem não gostou mesmo do site e ainda prefere a versão antiga, em todas as páginas existe o Link para Classic Metalink.
Abraços,
Olá,
Vou mostrar uma tática bem legal de diminuir um banco de dados Oracle físicamente, sem mexer em extents (por shrink table), rebuild de índices ou realizar desfragmentação de segmentos (por Export\Import Utility) no banco de dados.
O principal ponto que iremos atacar será os espaços livres desnecessários alocados na tablespace, que consomem espaços em disco preciosos no sistema operacional, toda essa tarefa será guiada atráves da marca d’água (HWM - High Water Mark) dos datafiles onde podemos realizar um RESIZE no datafile para um valor menor sem a perda de dados.
Lembrete
Essa tarefa envolve alguns conceitos de Oracle, como os de Marca D’água, ou HWM - High Water Mark, esse tema eu vou abordar em outro post para melhor entendimento. OK!
Para iniciarmos os trabalhos, vamos analisar o tamanho do nosso banco de dados e quanto ele está ocupando em disco, abaixo, vou fazer dois SELECTS que passa essas informações para nós e depois um print da quantidade em disco utilizado e livre no sistema operacional.
SQL> select sum(bytes)/1024/1024 as "TamanhoFisico(MB)" from dba_data_files;
TamanhoFisico(MB) ----------------- 76000
SQL> col "FileSystem" format a12
SQL> l 1 select substr(file_name,1,4) as "FileSystem", sum(bytes)/1024/1024 as "Tamanho(MB)" 2 from dba_data_files 3 group by rollup(substr(file_name,1,4)) 4* order by substr(file_name,1,4) SQL> /
FileSystem Tamanho(MB) ------------ ----------- /u01 25800 /u02 50200 76000
Percebemos, que no meu banco de dados, tenho quase 26GB de datafiles no FileSystem /u01 e mais 50GB no FileSystem /u02, totalizando os 76GB que é o tamanho total do meu banco de dados. O importante é saber o que esse valor representa na minha máquina, em questão de consumo e escabilidade, veja o que a máquina ainda pode oferecer.
[oracle@pelspos18 ~]$ df -h Filesystem Size Used Avail Use% Mounted on /dev/sda2 9.9G 3.2G 6.3G 34% / /dev/sda1 190M 13M 168M 8% /boot none 2.0G 0 2.0G 0% /dev/shm /dev/sda5 2.0G 36M 1.9G 2% /tmp /dev/sda6 114G 51G 58G 48% /u01 /dev/sdb1 134G 50G 78G 40% /u02
Para o FileSystem /u01, representa 48% de utilização, já para o FileSystem /u02, representa 40% de utilização. Claro, que tudo isso, irá depender de como o aplicativo e banco de dados se comporta, se é um banco de dados com crescimento acentuado diário, mensal ou semestral, tudo isso influência. Mas, no exemplo que estou utilizando, o banco de dados tem um crescimento em média de 3GB por mês, então, está adequado.
Mas, eu preciso liberar mais espaço em disco para fazer alguns backups em disco, exports e etc. Então, vou diminuir meu banco de dados físicamente de forma segura, como eu disse no início do post.
Para fazer isso, preciso da mais algumas informações como, Tamanho Físico e Livre das tablespace, que pode ser pego facilmente pelos SELECTS abaixo.
SQL> select tablespace_name, sum(bytes)/1024/1024 as "TAMANHO(MB)" 2 from dba_data_files 3 group by tablespace_name 4 order by sum(bytes);
TABLESPACE_NAME TAMANHO(MB) -------------------- ----------- FIN_CPAG 400 FIN_CEXT_IDX 800 USERS 800 TOOLS 1500 SYSAUX 2000 SYSTEM 2000 FIN_CORP 3500 FIN_CORP_IDX 5000 FIN_CPAG_IDX 8000 UNDOTBS 10000 FIN_CREC_IDX 12000 FIN_CREC 30000
12 linhas selecionadas.
Bom, as tablespaces SYSTEM e SYSAUX não é novidade para ninguem, então, elas vou deixar-las de fora da atividade, para não ocorrer nenhum tipo de problema. Vou apenas pensar nas demais, inclusive na de UNDO. Perceba que esse é apenas um SELECT para ver o tamanho total das tablespaces, agora, quero saber quanto cada uma tem livre, para poder direcionar os RESIZES. Abaixo segue o tamanho livre por tablespace.
SQL> select tablespace_name, sum(bytes)/1024/1024 as "TAMANHO(MB)" 2 from dba_free_space 3 group by tablespace_name 4 order by sum(bytes);
TABLESPACE_NAME TAMANHO(MB) -------------------- ----------- FIN_CREC_IDX 2,1875 FIN_CPAG 398,5625 USERS 642,5625 FIN_CEXT_IDX 799,5625 TOOLS 1495,3125 SYSTEM 1738,8125 SYSAUX 1869,125 FIN_CORP_IDX 2456,4375 FIN_CORP 3259,6875 FIN_CPAG_IDX 5289,375 FIN_CREC 8625,125 UNDOTBS 9865,375
12 linhas selecionadas.
Apenas mudei a view do primeiro SELECT, de dba_data_files para dba_free_space. Com isso, podemos ver quem tem mais espaço livre e saber quem precisa, existe tablespace com 8GB livres, e outros com 2,3 e 5G livres, só nisso, deixando apenas 10% livre, podemos economizar 12GB em disco. E ainda sem pensar no UNDO.
Agora, vamos executar um SELECT que irá analisar a marca d’água dos datafiles e verificar se existe a possibilidade de realizar um RESIZE para um valor menor, com isso, liberar espaço em disco no sistema operacional. Esse SELECT precisa de uma atenção especial, pois, é necessário informar o tamanho do db_block_size do seu banco de dados para efetuar corretamente os cálculos.
Para saber o tamanho do seu db_block_size, basta fazer o seguinte procedimento.
NO SQLPLUS, faça:
SQL> show parameters db_block_size
NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ db_block_size integer 8192
Se preferir, poderá ver na v$parameter, como no exemplo.
SQL> col name format a15 SQL> col value format a15 SQL> select name, value from v$parameter where name = 'db_block_size';
NAME VALUE --------------- --------------- db_block_size 8192
Agora, o momento esperado, o SELECT para realizar a operação de resize, veja.
SQL> l 1 select 'alter database datafile ''' || file_name || ''' resize ' || 2 ceil( (nvl(hwm,1)*8192*1.2)/1024/1024 ) || 'm;' cmd 3 from dba_data_files a, 4 ( select file_id, max(block_id+blocks-1) hwm 5 from dba_extents 6 group by file_id ) b 7 where a.file_id = b.file_id(+) 8 and ceil( (nvl(hwm,1)*8192*1.2)/1024/1024 ) < ceil( blocks*8192/1024/1024) 9* and ceil( (nvl(hwm,1)*8192*1.2)/1024/1024 ) > 100
Lembrete
Veja que onde está 8192 no script acima, é referente ao tamanho do db_block_size do seu banco de dados, esse valor então poder ser 2048, 4096, 8192, 16384 e 32768.
O script acima irá gerar um resultado sobre espaço livre, tamanho atual, espaço que pode ser salvo, total de espaço que pode ser liberado por datafile do seu banco de dados, tudo isso gerado pelos cálculos sobre a marca d’água de cada datafile. Se atentem pois ele está pegando todas as tablespaces do banco de dados e isso para nós não é necessário, podemos excluir a tablespace SYSTEM e SYSAUX.
FILE_NAME SMALLEST CURRSIZE SAVINGS SMALLEST_SAFE SAVINGS_SAFE ------------------------------------------------------------ ---------- ---------- ---------- ------------- ------------ /u02/app/oracle/oradata/finp/fin_corp01.dbf 125 2000 1875 149 1851 /u02/app/oracle/oradata/finp/sysaux01.dbf 191 2000 1809 229 1771 /u02/app/oracle/oradata/finp/system01.dbf 264 2000 1736 316 1684 /u02/app/oracle/oradata/finp/fin_corp02.dbf 117 1500 1383 140 1360 /u01/app/oracle/oradata/finp/fin_cpag_idx04.DBF 643 2000 1357 771 1229 /u01/app/oracle/oradata/finp/fin_cpag_idx03.dbf 651 2000 1349 781 1219 /u01/app/oracle/oradata/finp/fin_cpag_idx02.dbf 692 2000 1308 830 1170 /u01/app/oracle/oradata/finp/fin_cpag_idx01.dbf 728 2000 1272 873 1127 /u01/app/oracle/oradata/finp/fin_corp_idx02.dbf 847 2000 1153 1016 984 /u01/app/oracle/oradata/finp/fin_corp_idx01.dbf 897 2000 1103 1076 924 /u02/app/oracle/oradata/finp/fin_crec09.dbf 1284 2000 716 1540 460 /u02/app/oracle/oradata/finp/fin_crec08.dbf 1288 2000 712 1545 455 /u02/app/oracle/oradata/finp/fin_crec07.dbf 1304 2000 696 1564 436 /u02/app/oracle/oradata/finp/fin_crec06.dbf 1314 2000 686 1576 424 /u02/app/oracle/oradata/finp/fin_crec05.dbf 1331 2000 669 1597 403 /u02/app/oracle/oradata/finp/fin_crec04.dbf 1334 2000 666 1600 400 /u02/app/oracle/oradata/finp/fin_crec01.dbf 1351 2000 649 1622 378 /u02/app/oracle/oradata/finp/fin_crec02.dbf 1351 2000 649 1621 379 /u02/app/oracle/oradata/finp/fin_crec03.dbf 1351 2000 649 1621 379 /u02/app/oracle/oradata/finp/users01.dbf 158 800 642 189 611 /u02/app/oracle/oradata/finp/fin_crec15.dbf 1427 2000 573 1712 288 /u02/app/oracle/oradata/finp/fin_crec14.dbf 1547 2000 453 1856 144 /u02/app/oracle/oradata/finp/fin_crec13.dbf 1549 2000 451 1858 142 /u02/app/oracle/oradata/finp/fin_crec12.dbf 1551 2000 449 1861 139 /u02/app/oracle/oradata/finp/fin_crec11.dbf 1603 2000 397 1923 77 /u01/app/oracle/oradata/finp/fin_corp_idx03.dbf 802 1000 198 962 38
26 linhas selecionadas. CMD -------------------------------------------------------------------------------------------------------------------------- alter database datafile '/u02/app/oracle/oradata/finp/system01.dbf' resize 316m; alter database datafile '/u02/app/oracle/oradata/finp/fin_crec11.dbf' resize 1923m; alter database datafile '/u02/app/oracle/oradata/finp/fin_crec02.dbf' resize 1621m; alter database datafile '/u02/app/oracle/oradata/finp/fin_crec07.dbf' resize 1564m; alter database datafile '/u02/app/oracle/oradata/finp/fin_corp02.dbf' resize 140m; alter database datafile '/u02/app/oracle/oradata/finp/fin_crec05.dbf' resize 1597m; alter database datafile '/u02/app/oracle/oradata/finp/fin_crec06.dbf' resize 1576m; alter database datafile '/u02/app/oracle/oradata/finp/fin_crec03.dbf' resize 1621m; alter database datafile '/u02/app/oracle/oradata/finp/fin_crec08.dbf' resize 1545m; alter database datafile '/u01/app/oracle/oradata/finp/fin_corp_idx01.dbf' resize 1076m; alter database datafile '/u02/app/oracle/oradata/finp/fin_crec01.dbf' resize 1622m; alter database datafile '/u02/app/oracle/oradata/finp/fin_crec09.dbf' resize 1540m; alter database datafile '/u02/app/oracle/oradata/finp/fin_crec12.dbf' resize 1861m; alter database datafile '/u02/app/oracle/oradata/finp/fin_crec14.dbf' resize 1856m; alter database datafile '/u02/app/oracle/oradata/finp/fin_crec15.dbf' resize 1712m; alter database datafile '/u01/app/oracle/oradata/finp/fin_cpag_idx01.dbf' resize 873m; alter database datafile '/u01/app/oracle/oradata/finp/fin_cpag_idx04.DBF' resize 771m; alter database datafile '/u02/app/oracle/oradata/finp/sysaux01.dbf' resize 229m; alter database datafile '/u02/app/oracle/oradata/finp/fin_crec13.dbf' resize 1858m; alter database datafile '/u02/app/oracle/oradata/finp/fin_crec04.dbf' resize 1600m; alter database datafile '/u01/app/oracle/oradata/finp/fin_cpag_idx02.dbf' resize 830m; alter database datafile '/u02/app/oracle/oradata/finp/fin_corp01.dbf' resize 149m; alter database datafile '/u02/app/oracle/oradata/finp/users01.dbf' resize 189m; alter database datafile '/u01/app/oracle/oradata/finp/fin_corp_idx02.dbf' resize 1016m; alter database datafile '/u01/app/oracle/oradata/finp/fin_corp_idx03.dbf' resize 962m; alter database datafile '/u01/app/oracle/oradata/finp/fin_cpag_idx03.dbf' resize 781m;
26 linhas selecionadas.
Uma coisa boa que essse script já fornece o comando de DDL para redimensionar o datafile da tablespace sem a perda de dados. Basta executar.
Após a execução dos scripts, vamos analisar os resultados gerados. Primeiramente, vamos ver agora o tamanho total e o espaço livre das tablespaces, depois verificar como ficou o espaço em disco no sistema operacional e saber o quanto ganhamos com isso.
Espaço total das tablespace
SQL> l 1 select tablespace_name, sum(bytes)/1024/1024 as "TAMANHO(MB)" 2 from dba_data_files 3 group by tablespace_name 4* order by sum(bytes) SQL> /
TABLESPACE_NAME TAMANHO(MB) -------------------- ----------- USERS 189 FIN_CORP 289 FIN_CPAG 400 FIN_CEXT_IDX 800 TOOLS 1500 SYSAUX 2000 SYSTEM 2000 FIN_CORP_IDX 3054 FIN_CPAG_IDX 3255 UNDOTBS 10000 FIN_CREC_IDX 12000 FIN_CREC 25496
12 linhas selecionadas.
Espaço livre nas tablespace
SQL> l 1 select tablespace_name, sum(bytes)/1024/1024 as "TAMANHO(MB)" 2 from dba_free_space 3 group by tablespace_name 4* order by sum(bytes) SQL> /
TABLESPACE_NAME TAMANHO(MB) -------------------- ----------- FIN_CREC_IDX 2,1875 USERS 31,5625 FIN_CORP 48,6875 FIN_CPAG 398,5625 FIN_CORP_IDX 510,4375 FIN_CPAG_IDX 544,375 FIN_CEXT_IDX 799,5625 TOOLS 1495,3125 SYSTEM 1737,3125 SYSAUX 1811,5 FIN_CREC 4121,125 UNDOTBS 9797,4375
12 linhas selecionadas.
Espaço no sistema operacional
[oracle@pelspos18 u01]$ df -h Filesystem Size Used Avail Use% Mounted on /dev/sda2 9.9G 3.2G 6.3G 34% / /dev/sda1 190M 13M 168M 8% /boot none 2.0G 0 2.0G 0% /dev/shm /dev/sda5 2.0G 36M 1.9G 2% /tmp /dev/sda6 114G 45G 64G 42% /u01 /dev/sdb1 134G 42G 86G 33% /u02
Conclusões
Perceba que algumas tablespace permaneceram do mesmo tamanho e algumas tiveram mais que 10% do seu tamanho reduzido, o melhor que podemos notar no sistema operacional que o FileSystem /u02 que antes tinha 78GB disponível, agora tem 86GB, uma diferença de 8GB, para o FileSystem /u01 que atens tinha 58GB disponível, agora tem 64GB, uma diferença de 6GB, que somando com o valor anterior, podemos reutilizar 14GB de espaço no sistema operacional.
O tamanho do nosso banco de dados fisicamente, também diminuiu, foi para 62GB. Antes era de 76GB, 14GB a menos, justamente o que nós não utilizamos mais.
O que pode nos ajudar a redução física do banco de dados?
Pode nos ajudar em N tarefas, como:
Acho que isso já são boas razões para se pensar em fazer uma diminuição física do seu banco de dados.
Abraços,
Olá,
O título desse post já diz muita coisa, “Achei um ORA-600, o que faço?”. Muitos gostariam de ter o botão EJECT na cadeira, outros de ser ninjas e jogar o pó para desaparecer e alguns gostariam de ser o novo David Blaine. Na verdade, esse número “cabalístico” de erro pode ser o início de uma longa jornada.
O RDBMS (Relational Database Management System) Oracle possui dois códigos de erros que assustam qualquer DBA, o bendito ORA-600 e ORA-7445, mas nesse momento, vamos refletir sobre o ORA-600, o que ele realmente significa para nós.
Quando nós encontramos ele no alert.log ou diretamente pelo Oracle Server (via SQL*PLUS ou qualquer outra aplicação), significa que temos um problema na aceitação do comando no kernel do RDBMS ou temos uma inconsistência em um determinado processo, que geralmente, pode estar associado a um BUG, **MAS**, nem sempre é um BUG, por isso que temos que ter muita calma nessa hora. O Metalink disponibiliza uma ferramenta de pesquisa para esse específico erro, o chamado ORA-600 Lookup tool. Atráves dele, pode ser encontrado a solução para seu específico erro, se existe um patchoff para correção ou se existe um simples workarround “gambiarra” para realizar.
O ORA-600 pode ser um problema causado por diversos fatores, como:
A falta de recursos de memória ou problemas de disco podem auxiliar seu aparecimento.
Uma má instalação e falta de patchs no sistema operacional pode causar o ORA-600, e quando digo má instalação, gosto de me referir aquela instalação, NEXT-NEXT-FINISH.
Podem perceber que a Oracle, quando lança um produto, possui diversos PatchSets, que é um conjunto de correções (Patchoffs) que é detectado pelo suporte da Oracle em acompanhamento de seus clientes. A falta de atualização só aumenta a sua chance de ter um amigo ORA-600.
Sempre que é lançada uma versão nova de banco de dados, com por exemplo, versão, 8.1.0, 9.1.0, 10.1.0 ou 11.1.0, (lógico, em suas respectivas epócas) e na sua aplicação começa a utilizar as features da versão (novos recursos de desenvolvimento ou banco de dados), **COM CERTEZA**, encontrará um ORA-600 em algum momento de sua humilde vida. Isso é porque o Kernel do RDBMS ainda não está “amadurecido” para executar “tal” tarefa, sobre “tal” sistema operacional com “tal” linguagem de programação.
Como sempre digo, ter um ORA-600na base de dados nem sempre é uma questão de desespero ou assinar a setença de morte, tudo bem que talvez possa virar algumas noites na empresa, mas isso passa. O ORA-600pode vim a qualquer momento, porque ele é resultante de diversos fatores como dito acima e **SIM**, para alguns tipos de ORA-600, podem ser resolvidos rapidamente.
Toda vez que se tem um ORA-600, é gerado um arquivo de trace no servidor, no diretório USER_DUMP_DEST ou BACKGROUND_DUMP_DEST(depende qual será o processo afetado). Nesse arquivo de trace, para quem é mais experiente, poderá encontrar as raízes dos problemas. Pode ser um “LAZARENTO” de uma instrução de SELECT que faz join com uma INLINE VIEW, que também faz um hash join com uma Materialized view e tem uma view com dblink que força o aparecimento do ORA-600, ou como pode ser um simples INSERT em tabelas IOT e assim vai, só com bastante analise iremos saber as causas. Mas onde quero chegar com isso?
Quando se tem o erro ORA-600 em mãos, devemos tentar entende-lo, como mostra um exemplo de mensagem abaixo:
ORA-00600: internal error code, arguments: [kcbz_check_objd_typ_3], [0], [0], [1], [], [], [], []
ou
ORA-00600: internal error code, arguments: [12209], [498], [], [], [], [], [], []
Podemos ter uma idéia de onde vêm o possível problema, a menssagem de erro é sempre composta por ORA-600 [argumento1] [argumento2] até o [argumento8]. Se estudarem a arquitetura interna do Oracle, o kernel é composto por diversas travas que fazem o controle, acesso e utilização dos dados.
Nínguem sabe dizer com 100% de certeza, se o kernel do Oracle é puramente escrito na linguagem C, mas dizem que possui algumas coisas em Java para os releases superiores ao 9i. Pois bem, isso não interessa até o momento, eu quero apenas exemplificar.
Analisando o trace gerado, podemos ter a idéia de onde ele vêm, como eu disse acima (por SELECT, INSERT, CREATE e etc), e sempre devemos prestar a atenção no primeiro argumento, pois ele que irá dizer em qual momento ou trava ocorreu o problema.
No primeiro erro mencionado, nosso primeiro argumento foi o kcbz_check_objd_typ_3, que internamente para o Oracle a trava KCBZ quer dizer Kernel Cache Buffer, então já podemos ir mais profundamente e pensar que ocorreu um erro no tratamento da informação durante sua passagem pelo SGA.
No segundo erro, como não existe nenhuma trava mencionada no primeiro argumento, e não envolve travas do kernel, pode ser algum problema apenas como manipulação dos dados ou quebra de integridade interna, e por isso, dá uma esperança que pode ser um ORA-600 com resolução rápida.
Ambos os erros, podem estar associados a um BUG da versão ou apenas uma má interpretação do banco de dados, isso, apenas olhando o erro e o trace não iremos conseguir garantir nada. É apenas um exemplo e modo de como podemos se comportar com um ORA-600 no banco de dados.
LEMBRETE
Sempre, **MAS**, sempre que tiver um ORA-600 em sua base de dados, acione de imediato o suporte da Oracle para analisar profundamente os motivos do aparecimento do problema e realizar uma investigação sobre seu ambiente, como mencionado, os fatores podem ser diversos e também pode ser ou não um real BUG da sua versão.
Estou apenas dizendo uma experiência que tenho no dia-a-dia e não me responsabilizo pelos seus atos. Espero que tenham gostado desse assunto e que possa entender melhor o motivo do nosso velho amigo ORA-600.
Abraços,
