BLOG RODRIGO ALMEIDA

Olá,

Segue mais um evento sobre banco de dados Oracle 11g em São Paulo no dia 15/07/2010 no Hotel Grand Hyatt.

Descubra os benefícios de atualizar para o Oracle Database 11g Por que empresas de todos os tamanhos estão atualizando para o Oracle Database 11g? Por causa dos seguintes resultados: o Oracle Database 11g ajuda as organizações a reduzir os custos de computação com simultânea melhoria de desempenho, escalabilidade, disponibilidade e segurança. Junte-se a nós neste evento gratuito no qual os especialistas da Oracle descreverão os principais recursos inéditos que possibilitam reduzir os custos de TI, maximizar o desempenho das consultas e efetuar atualizações com os usuários on-line. Saiba como os clientes estão: Consolidando em grids de armazenamento e servidores escalonáveis Compactando dados para reduzir o footprint (volume) de armazenamento Melhorando o desempenho, a disponibilidade e a segurança do banco de dados Reduzindo os custos de TI por meio do datacenter . Não perca esta oportunidade exclusiva de encontrar os especialistas da Oracle e conhecer os maiores segredos sobre a atualização para o Oracle Database 11g. Descubra como reduzir os custos de TI e aumentar a qualidade dos níveis de serviço em toda a empresa. Para mais informações ligue: 11 3849.2133. Registre-se Agora Dia 15 de julho, 2010 Horário 8h30 às 12h00 Grand Hyatt São Paulo Piso Térreo Sala Grand III – Av. das Nações Unidas, 13.301

Agenda 8h00 Credenciamento 9h00 Abertura – Executivo Oracle 9h15 Why Standardize on Oracle Database 11g? * 10h00 Estudo de Caso implementado pelo parceiro Discover 10h30 Coffee Break 10h45 Oracle’s Maximum Availability Architectures ** 11h30 Perguntas & Respostas 11h45 Concurso Cultural – oferecimento do parceiro Discover * In this presentation, you’ll discover the benefits of upgrading to Oracle Database 11g, and how customers are reducing IT costs and increasing the quality of service for all their enterprise applications.** In this session, you’ll learn how Oracle’s Maximum Availability Architecture delivers a highly available environment with fully utilized redundancy and online operations. Apoio

Copyright © 2010, Oracle e/ou suas controladas e coligadas. Todos os direitos reservados. Entre em contato | Avisos Legais e Condições de Uso | Declaração de Privacidade

Abraços,

Olá,

Acompanhando o twitter do Eddie Awad, ele postou um link super interessante sobre básicas diferenças entre o Oracle Server e MS SQL Server, vale a pena dar uma olhada e analisar os pontos que um DBA que trabalha com ambas bases de dados descreveu como fundamentais.

O link para acompanhar a discussão está aqui: Basic Differences between Oracle and SQL Server.

Quem tiver mais sugestões, dúvidas e ideias, vamos comentando abaixo.

Abraços,

Olá,

Alguns profissionais iniciantes em Oracle, ainda tem muitas dúvidas sobre diversos conceitos de arquitetura do banco de dados Oracle, por isso, resolvi discutir sobre um ponto bem importante, O que é um Control file?

Tradução

Control file = Arquivo de Controle, tradução em português para a palavra que é muito utilizado na literatura Oracle brasileira.

Visão Geral

Contéudo

Um arquivo de controle possui diversas informações de um banco de dados que é requerida pela instância. Durante o processo de startup ou uma operação normal, somente o Oracle Server pode modificar as informações no arquivo de controle, deste modo, nenhum DBA ou usuário pode modificar seu contéudo.

As informações que o arquivo de controle possui são:

• Nome do banco de dados
• Data de criação do banco de dados
• Os nomes e localizações de cada datafile e redo log associados ao banco de dados
• Informações sobre as tablespaces
• Possíveis datafiles com status offline
• O histórico de logs
• Sobre os archives gerados
• Backupsets e backup pieces, gerados pelo RMAN
• Backups de datafiles e informações de redo log
• Cópia de datafiles
• O valor atual do número da sequência do log
• Informações de checkpoint

Para cada datafile ou redo log que é adicionado, renomeado, modificado ou excluído do banco de dados, o arquivo de controle é atualizado pelo Oracle Server para garantir a modificação da estrutura física da base. Essas modificações pode ser:

• O Oracle pode identificar os datafiles e redo logs que foram abertos durante o processo de startup
• Identificar os arquivos que são necessários ou disponíveis em caso de recuperação do banco de dados

Portanto, para cada modificação na estrutura física do banco de dados, podendo ser feito atráves do comando ALTER DATABASE, é altamente recomendado que seja feito um backup do seu arquivo de controle para evitar possíveis problemas no próximo processo de startup do banco de dados.

Como o arquivo de controle armazena informações sobre os checkpoints, a cada três segundos, o processo de plano de fundo (CKPT) registra as posições do redo log, essas posições serão utilizadas posteriormente  durante um processo de recuperação do banco de dados, onde o Oracle irá dizer se todas as entradas dos grupos de redo log serão necessárias para realizar tal recuperação.

Referência

Oracle Concepts 10g Documentation

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.

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)

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

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á,

Algumas semanas atrás, tive um problema com um banco de dados que eu tinha acabado de criar, um caso muito estranho, tudo funcionava perfeitamente e no outro dia, o banco não iniciava por problemas de ORA-600, poderia ser um caso de pesquisar no Metalink para resolver o problema, mas por curiosidade, resolvi analisar de onde pelo menos esse erro acontecia ou tentar saber o que poderia ter acontecido com meu hardware. O erro exato do ORA-600, está abaixo:

ORA-00600: internal error code, arguments: [2252], [1903], [3499988641], [], [], [], [], []

Como eu estava tentando entender o problema, fui pesquisar sobre o primeiro argumento do ORA-600, o argumento 2252, onde ele se referia a categoria de base 2000, que é referente a funcionalidade do Cache Layer, porém, como o argumento exato é 2252, estava relacionada diretamente a funcionalidade de RCV (Recovery), e o valor 252 é para diversas funcionalidades voltadas ao SCN.

O erro sempre acontecia no momento que eu tentava abrir o banco de dados, executando o ALTER DATABASE OPEN, fora isso, meu banco de dados conseguia montar sem problemas! Então, começei a levantar algumas informações sobre o hardware, como por exemplo:

• O servidor já tinha 5 anos de uso.
• Fabricante DELL.
• O sistema operacional, tinha acabado de ser instalado, estava sobre a Plataforma Linux Red Hat EL AS 4 em 32-Bits, observando os logs do SO, também não encontrava problemas.
• O banco de dados, recém instalado e configurado.

O problema estava misterioso, quando resolvi analisar cuidadosamente o erro no alert.log, e me deparei com alvo assim:

Wed Jan  9 23:45:57 2002
Successful mount of redo thread 1, with mount id 1181935665
Wed Jan  9 23:45:57 2002
Database mounted in Exclusive Mode
Completed: ALTER DATABASE   MOUNT
Wed Jan  9 23:46:07 2002
alter database open
Wed Jan  9 23:46:07 2002
Errors in file /u01/app/oracle/admin/esdp/udump/esdp_ora_31553.trc:
ORA-00600: internal error code, arguments: [2252], [1903], [3499988641], [], [], [], [], []
Wed Jan  9 23:46:08 2002
ORA-600 signalled during: alter database open...

Lembra que disse que eu tive problemas há algumas semanas atrás, isso é no ano de 2008, todos os registros de alerta estavam com a data de 2002!! Resolvi apenas executar um DATE no Linux diretamente para ver a data, quando me deparei com o ano de 2002 também!

O argumento que o ORA-600 estava apontando estava correto, na trava certa, pois quando criei o banco de dados e realizei o import de várias dados atráves do datapump, meus primeiros archives e entradas de REDO, estava com a data de 2008, quando o servidor perdeu essa data e regrediu, é correto o Oracle Server afirmar que não consegue fazer um Automatic Recovery da instância, quando realiza a abertura do banco, pois como um banco de dados pode começar os primeiros archives na data de 2008 e depois pedir uma recuperação de 2002!!! Meio complicado.

Só para compreender melhor, olhe como estava a minha área de db_recovery:

[oracle@pelspos13 archivelog]$ ls -R
.:
2002_01_05  2008_07_31  2008_08_01  2008_08_04  2008_08_11
./2002_01_05:
o1_mf_1_1_y3dz9wbt_.arc   o1_mf_1_81_y3dx0npt_.arc  o1_mf_1_83_y3dx2ftp_.arc
o1_mf_1_80_y3dx3gmy_.arc  o1_mf_1_82_y3dx1496_.arc
./2008_07_31:
./2008_08_01:
./2008_08_04:
./2008_08_11:
o1_mf_1_82_4b1r5349_.arc
[oracle@pelspos13 archivelog]$

Sendo que os archives da data de 05/01/2002, seria “teoricamente” os archives mais recentes!!!

Agora, a causa disso tudo, simples! A bateria da placa mãe do servidor, como essa bateria já deveria estar com problemas, quando o servidor era reiniciado, ele voltava para a data de fabricação da placa, e com isso, todo o sistema operacional também voltava, e consequentemente, meu banco de dados.

Como trabalhava no modo ARCHIVELOG, ao abrir o banco de dados, apresentava esse erro bonito. Se for analisar, é um erro “besta”, que poderia ser resolvido rapidamente, mas, um simples erro, muitas vezes é díficil de se perceber.

Abraços,

Olá,

Para quem trabalha com banco de dados, sempre teve a curiosidade de saber qual o maior banco de dados do mundo, para termos noção do tamanho, da grandeza da administração e o tempo que deve executar uma instrução SQL, rebuild de índice e tudo mais.

Pois bem, encontrei alguns materiais na internet que falam justamente desses bancos de dados, que podem ser de diferentes fabricantes, tanto Oracle, IBM, Microsoft, PostGreSQL e etc. O mais interessante são os números ou métricas que chegaram nessas conclusões e relatam um pouco da infra-estrutura utilizada para cada ambiente de banco de dados.

O  importante também é saber que esses artigos e documentos não são de fontes oficiais das empresas ou de alguma organização responsável e séria sobre esse específico tipo de assunto. Como hoje em dia temos o TPC.ORG que corresponde aos benchmarks sobre Performance vs Custo. Esses documentos são meramente para matarmos algumas curiosidades, mas nada confirmado pelas empresas.

O documento que está abaixo, relata o TOP 10 dos maiores bancos de dados do Mundo e o mais interessante do documento, são os números que os tornam gigantescos. Veja no documento abaixo:

Top Largest Databases in the World We all collected -´

 Porém, se continuar navegando um pouco mais na internet, irá se deparar com um artigo da COMPUTERWORLD falando que o maior banco de dados do mundo é do Yahoo!, que possui um banco de dados na casa dos 2 PB (PetaBytes). Veja:

Yahoo! The database 2 PetaBytes.

Mas como é um artigo do ano de 2.008, talves esse número já esteja bem maior. E sou da opinião que deve existir bancos de dados bem maiores dos que os divulgados e analisados. Um exemplo para ampliar a curiosidade, são as bases de dados de organizações como:

• Organizações que cuidam do clima (Calculos e Imagens);
• Empresas que trabalham com tecnologia GIS (Mapeamento – GPS);
• Empresas de Media Center.

E por último o DETRAN-SP, se o estado têm a terceira maior frota de automóveis do Mundo e a cidade tem radar para tudo que é lado, imagina a quantidade de transações diárias (com imagem da placa do seu CARRO) que é gerado por hora para cada multa??? Coitado do DBA que tem que ficar aumentando a tablespace toda hora.

Abraços,

Olá,

Hoje recebi do meu amigo David Ricardo a sugestão de vídeo abaixo, que é uma simples e rápida apresentação do Oracle Database 11g Release 2. Feita pelo Vice-Presidente de banco de dados da Oracle Corporation, ele apenas comenta sobre alguns recursos, redução de custos no TI e um aumento de produtividade do DBA.

ATENÇÃO

Para quem viu o vídeo anterior sobre o Sun Oracle Database Machine, vale a pena lembrar que no Exadata II, é feito totalmente para o Oracle Database 11g Release 2 e possui “special features” de hardware feitos para o banco de dados, para oferecer EXTREME PERFORMANCE!

Abraços,

Olá,

Recentemente, estou participando de uma migração de um banco de dados, Oracle 8i para Oracle 10g, da plataforma 32-bits para 64-bits e uma aplicação Forms/Reports 6i (Oracle Developer 6i), e se deparamos com um problema de Security após a criação e importação dos owners para o novo banco de dados.

Quando mandei o desenvolvedor conectar a aplicação no novo banco de dados, para fins de testes, conectividade e possíveis problemas do 10g (Pois é uma migração do 8i, e a aplicação está toda em REGRA), o Forms nos emitia um erro estranho, como mostra abaixo:

FRM-10256: User is not authorized to run Form Builder Menu

Logo de início, pensei que poderia ser problemas no owner da aplicação (no banco de dados), ou o menu da aplicação, que utiliza outro owner para validar e construir o menu. Fiz todos os checks necessários, como:

• Analisar o “STATUS ACCOUNT” de todos os owners no banco de dados, que pode ser feito pela view dba_users;
• Olhar qual perfil de banco de dados os owners estão usando, todos estavam com DEFAULT para início;
• Analisar com a base de produção, objetos inválidos, views e qualquer outro objeto que tenha relação com a construção dos menus, e também nada.

Então, resolvi junto com o desenvolvedor, pesquisar sobre o assunto e esse erro específico, e encontramos a seguinte solução pelo Metalink.

Visão Geral

A segurança do Oracle Forms é baseada em roles (papéis) no banco de dados Oracle. Essas roles são um método de permitir o acesso as informações do banco de dados para os usuários, portanto, se nenhum usuário não tem acesso a qualquer coisa, essas roles podem ajudar a facilitar o acesso.

Desde que os usuários tenham essas roles definidas pelo DBA ou Administrador de aplicação, os módulos de MENU e ITENS DO MENU terão um controle de acesso feito internamento pelo menu da aplicação.

Solução

Para resolver esse problema, o DBA, conectado no banco de dados com o usuário SYS, deve executar um script de segurança que vêm junto com o Developer 6i, que é o script abaixo:

Para ambiente Windows

%ORACLE_HOME%\tools\dbtab\forms60\frm60sec.sql

Para ambiente Linux\Unix

$ORACLE_HOME/forms60/admin/sql/frm60sec.sql

Esse script é pertecente ao ORACLE_HOME do Developer 6i, não confunda com o ORACLE_HOME do banco de dados. Execute ele com o usuário SYS e seus problemas vão terminar.

Abaixo, segue o contéudo do script, caso, estejam com esse problema e não conseguem acessar o servidor de aplicação por motivo de segurança da empresa ou qualquer outro motivo.

FRM60sec.sql

create or replace view FRM50_ENABLED_ROLES as
select urp.granted_role role,
sum(distinct decode(rrp.granted_role,
'ORAFORMS$OSC',2,
'ORAFORMS$BGM',4,
'ORAFORMS$DBG',1,0)) flag
from sys.user_role_privs urp, role_role_privs rrp
where urp.granted_role = rrp.role (+)
and urp.granted_role not like 'ORAFORMS$%'
group by urp.granted_role;

create public synonym FRM50_ENABLED_ROLES for sys.FRM50_ENABLED_ROLES;

create role ORAFORMS$OSC;

create role ORAFORMS$DBG;

create role ORAFORMS$BGM;

PRONTO! Acho que agora vai resolver a vida, caso tenha problemas, dê os grants de SELECT do SYNONYM para os usuários que precisa acessar a aplicação.

Abraços,

Olá,

Vamos tocar num assunto interessante, as transações pendentes quando se trabalhar com banco de dados em ambientes distribuídos. Essas transações é uma forma de comunicação entre bases de dados Oracle, atráves de DBLINKS, e trabalham com uma tecnologia de controle chamada TWO-PHASE Commit, traduzida, Comprometimento em duas fases, que server como garantia de integridade entre as bases oracle, tanto na base de origem e destino, permitindo que a transação seja segura e íntegra.

A tecnologia de TWO-PHASE Commit, basicamente surgiu para controlar e monitorar as atividades de commit e rollback das transações em ambientes de bases de dados distribuídos, que como dito acima, serve para garantir a consistência dos dados. Existe desde a versão 8i um processo de plano de fundo (background process) chamado RECO, que sua principal função no banco de dados é monitorar todas essas transações, a partir de um LOCAL_TRAN_ID (na base de origem) e um GLOBAL_TRAN_ID (na base de destino) e dizer ao banco de dados, qual é o estado das transações, e se tiver algum problema, tentar recuperar-las.

Junto a com tecnologia, o dicionário de dados ganhou duas visões, a primeira é a dba_2pc_pending, que tem como objetivo listar todas as transações que estão pendentes no banco de dados, que por algum motivo o RECO não fez a sua recuperação ou se a transação ainda está sendo efetivada ou não no banco de dados, e temos também a visão dba_2pc_neighbors, que lista todas as entradas e saídas das transações que estão pendentes, qual o banco de dados, usuário e etc.

O objetivo desse post não é aprensetar a tecnologia TWO-PHASE Commit que é velha, desde 1980 está implementado nos banco de dados Oracle, e sim, de como eliminar essas transações que ficam “pressas” em nossos banco de dados.

Abaixo, segue um exemplo de um ambiente real de como as duas visões acima podem nos auxiliar na eliminação das transações, veja:

select local_tran_id, global_tran_id, state, fail_time, force_time
from dba_2pc_pending;

LOCAL_TRAN_ID GLOBAL_TRAN_ID STATE FAIL_TIM FORCE_TI
———————- —————————————- —————- ——– ——–
14.28.232339 PARA.WORLD.0964cc71.14.28.232339 collecting 30/07/08
4.26.229018 PARA.WORLD.0964cc71.4.26.229018 collecting 31/07/08
12.42.248854 PARA.WORLD.0964cc71.12.42.248854 collecting 11/08/08

select local_tran_id, in_out, database, dbuser_owner
from dba_2pc_neighbors;

LOCAL_TRAN_ID IN_ DATABASE DBUSER_OWNER
———————- — ——————– ——————————
14.28.232339 in ARA_VE_WANDERSON
14.28.232339 in PARA.WORLD DPD
4.26.229018 in ARA_VE_SANSAO
12.42.248854 in ARA_VE_MELQUESEDETE
14.28.232339 out PEL_DIST_ARA.WORLD DPD
14.28.232339 out PEL_DIST_GOI.WORLD DPD
4.26.229018 out PEL_DIST_GOI.WORLD DPD
12.42.248854 out PEL_DIST_GOI.WORLD DPD

Perceba que as duas visões podem nos fornecer ótimas informações sobre as pendências que estão no banco de dados, o que nós iremos precisar é apenas o LOCAL_TRAN_ID, que é a identificação da transação distribuída e a partir dessa transação, saber qual é o seu status, pela coluna STATE.

Observe que no primeiro SELECT na visão dba_2pc_pending, a transação de id 14.28.232339 está com seu status de COLLECTING (Coletando) e até agora está um zumbi dentro do banco de dados, pois basta observar pela data de FAIL_TIME (Data de Falha) que o processo RECO não conseguiu fazer sua recuperação até o momento. Então, devemos eliminar-la manualmente, habilitando no banco de dados, a opção de recuperação distribuída, deste modo:

sqlplus /nolog

SQL*Plus: Release 10.2.0.1.0 – Production on Seg Ago 11 14:21:50 2008
Copyright (c) 1982, 2005, Oracle. All rights reserved.

conn sys@pel_dist_ara as sysdba

Informe a senha:
Conectado.

alter system enable distributed recovery;

Sistema alterado.

select local_tran_id, global_tran_id, state, fail_time, force_time
from dba_2pc_pending;

LOCAL_TRAN_ID GLOBAL_TRAN_ID STATE FAIL_TIM FORCE_TI
———————- —————————————- —————- ——– ——–
14.28.232339 PARA.WORLD.0964cc71.14.28.232339 collecting 30/07/08
4.26.229018 PARA.WORLD.0964cc71.4.26.229018 collecting 31/07/08
12.42.248854 PARA.WORLD.0964cc71.12.42.248854 collecting 11/08/08

exec dbms_transaction.purge_lost_db_entry ('14.28.232339');

Procedimento PL/SQL concluído com sucesso.

commit;

Commit concluído.

select local_tran_id, global_tran_id, state, fail_time, force_time
from dba_2pc_pending;

LOCAL_TRAN_ID GLOBAL_TRAN_ID STATE FAIL_TIM FORCE_TI
———————- —————————————- —————- ——– ——–
4.26.229018 PARA.WORLD.0964cc71.4.26.229018 collecting 31/07/08
12.42.248854 PARA.WORLD.0964cc71.12.42.248854 collecting 11/08/08

Eu também utilizei o pacote DBMS_TRANSACTION, o seu procedimento PURGE_LOST_DB_ENTRY, que é utilizado nesses casos para a eliminação de transações pendentes sem nenhum comprometimento do ambiente oracle.

E sempre que for utilizar essa técnica para eliminar transação pendente, sempre se lembre de duas coisas:

1. Sempre deverá executar as ações acima com um usuário com permissão de SYSDBA, ou com o usuário SYS, com a role SYSDBA.

Para habilitar a recuperação de transação, podemos utilizar o seguinte comando:

alter system enable distributed recovery;

2. Para as versões 9i, que foi o começo dos segmentos de UNDO (nosso velho amigo rollback), devemos alterar o seguinte parâmetro da instância:

alter system set "_smu_debug_mode"=4;

É um parâmetro não documentado do banco de dados, que é limpar as transações que estão utilizando os segmentos de UNDO, isso foi corrigido na versão 10g posteriormente.

Após a realização de todas as tarefas acima, poderá ver que o processo RECO não está gerando mais traces no diretório do BACKGROUND_DUMP_DEST das transações que não conseguiu recuperar.

Isso é uma técnica muito utilizada quando queremos eliminar essas transações para evitar lock-held ou incosistência nos dados, mas lembre-se, sempre veja a coluna FAIL_TIME para ver desde quando não está conseguindo efetuar a recuperação, pois a dba_2pc_pending também informa as transações que estão pendentes no dia. Tome cuidado.

Abraços,

Olá!

Para quem trabalha em empresas que possui diversas bases de dados e tem contrato de suporte com a Oracle, como o Metalink, Oracle Consulting ou parceiras da empresa, já conhece ou deve ter ouvido falar sobre as ferramentas de suporte as equipes de DBA, o RDA (Remote Diagnostic Agent) e SCM (Software Configuration Management).

Pois bem, muitos confudem e acham que essas ferramentas são a mesma coisa, ou que o SCM é uma versão do RDA melhorado, que realmente parece ter a mesma funcionalidade, mas, existe um diferença entre eles.

O RDA, é uma ferramenta de suporte da Oracle desenvolvido em Perl, que tem como principal finalidade captar diversas informações do ambiente do cliente para ajudar na solução de problemas quando se tem um TAR aberto no Metalink. Essas informações variam desde o sistema operacional, configurações de rede, java até informações do banco de dados e seus respectivos produtos, como ASM, Enterprise Manager, EBS, iAS e etc.

Sua função é auxiliar no momento da abertura do TAR ou durante o processo de investigação de seu problema junto á Oracle. Ao instalar e configurar o RDA, e posteriormente a sua execução, são coletados informações essênciais para os analistas, pois o RDA no final da execução gera um arquivo compactado contendo diversos relatórios em extensão HTML com todas as informações citadas acima.

O SCM, já trabalha de forma diferente, sua finalidade também é captar todas as informações sobre seu ambiente para ajudar na resolução de seus problemas, quase as mesmas que do RDA, porém, seu grande diferencial, é que ele trabalha com os chamados coletores, ou OCM (Oracle Configuration Manager), que podem ser executados em periodos de tempo de acordo com a sua necessidade e ociosidade do sistema, ou seja, após sua instalação e configuração correta, ele envia todas as informações coletadas para um repositório on-line na Oracle, que pode ser acessado pelo novo site do Metalink, o My Oracle Support, com essas informações retidas na Oracle, ele automáticamente analisa e fornece dicas e alertas sobre seu banco de dados, quais patchs estão faltando no banco, dicas para melhorar segurança, informações de ajuste para alguns parâmetros e etc. Deste modo, fornece uma habilidade de pró-atividade aos DBAs, mantendo sempre atualizado.

Ambas as ferramentas são multi-plataformas, ou seja, podem ser utilizados tanto em ambientes Windows, Linux e Unix, para cada caso, existem scripts específicos para cada sistema operacional.

O RDA sempre foi uma ferramenta muito boa não apenas para lhe auxiliar nas tarefas junto ao suporte da Oracle, mas também, para consultores de banco de dados que trabalham em diversas empresas, e que precisam conhecer o ambiente que irá enfrentar, já que seus relatórios podem ser vistos de forma offline e completo, ajuda em muito para conhecer o sistema.

Eu apenas estou dando uma pequena prévia sobre essas ferramentas, que considero como um recurso básico em qualquer equipe de administradores de banco de dados. Quem tem acesso ao Metalink, recomendo que veja como funciona essas ferramentas atráves de demostrações da própria Oracle e conheça mais técnicamente o que cada um pode lhe oferecer, exite também Web Seminars em português gratuitos no site para lhe auxiliar na aprendizagem.

Abraços,