Certificação OCA – FAQ

 

Become OCA Certified!

Para entrar no mercado de trabalho como DBA, uma das opções (uma das melhores opções) é se certificar.

Todo novato tem dúvidas sobre como chegar na certificação, sobre quais são as suas opções, quer saber o quão difícil é, se há ou não um caminho mais fácil… Eu também fiquei, em diversos momentos, com essa dúvida. Perguntava para um colega, perguntava para outro, mas as informações não eram muito precisas. Pessoas, volta e meia, mandam mensagens em fóruns perguntando a mesma coisa.

Para perguntas como…

• Como iniciar meu caminho de certificação DBA Oracle?
• Qual prova é melhor fazer?
• Quanto vai custar essa brincadeira?
• Que benefícios obtenho no caminho que eu escolher?

… nosso colega de profissão debulhou, de cima a baixo, as respostas.

Há apenas algumas horas, o DBA (e Oracle Ace!) Rodrigo Almeida publicou em seu blog um belo post falando sobre todo o caminho dessa primeira certificação para os DBAs, a OCA – Oracle Certified Associate.

O post está muito rico, com comentários muito interessantes para quem está no barco dos iniciantes DBAs. Saia já daqui e vá ler o post dele! Não irei  transcrever nada do que ele comentou pois está muito bem escrito. Leiam com as palavras do expert no link abaixo:

 

Blog do Rodrigo Almeida: Torne-se um OCA com 2 Certificações
http://lnkd.in/_2yUcW

 

Enjoy!

 

Executando scripts – Dicas

DBA, roda esse script aí!

Ahhh! A requisição que todo DBA adora, executar o script que o fulano programou! Não adianta chorar, isso vai ser comum, pelo menos no seu começo de carreira.

Só que pera lá! Não saia colocando pra rodar qualquer coisa que te pedirem, não. Você é o DONO do banco de dados agora e, embora algumas diretrizes corporativas possam lhe isentar no caso de algo errado acontecer, você compartilha a responsabilidade do sucesso e do fracasso das atividades nas quais participa. Não adianta tirar o corpo fora porque o script do ciclano destruiu a base toda, você poderia ter evitado se tivesse analisado o script antes de executá-lo. A culpa é do ciclano também (na minha opinião, bem mais dele do que sua), mas você também deixou passar. É esse tipo de situação que podemos evitar tomando alguns cuidados.

Aqui vão algumas dicas para que você, rookie, fique esperto nessas ocasiões.

 

1) Leia e entenda o script

Antes de fazer qualquer coisa, abra o script e veja  o que ele faz. Nem sempre é um código muito extenso, é possível ter uma boa noção do que aquele código irá fazer no seu banco de dados. Você, como DBA, deve entender o que está acontecendo e pode (em alguns casos deve) sugerir ou propor alguma melhoria no código, antes de executá-lo.Você pode pegar casos como um DELETE sem cláusula WHERE e pode alertar o dono do script quanto a isso, confirmar se é isso mesmo que ele desejava executar ou se não foi um erro de lógica de programação.

 

2) Quem é o dono dos objetos manipulados?

Veja se, no script, estão mencionados os donos dos objetos explicitamente. Se não estiver, você terá que executar o script após ter acessado o banco com o usuário do schema correto. Ou, como DBA, alterar sua sessão para o schema correto.Caso não tenha o owner explícito e você estiver conectado como SYS ou outro usuário com privilégios suficientes, pode ser que uma infeliz coincidência aconteça e você delete, destrua (drop) ou crie objetos dentro de um schema que não era o alvo. Isso pode até ser impossível de se consertar sem ter que voltar um backup. Olha a dor de cabeça…

 

3) E se der tudo errado. Como voltar atrás?

Antes de executar, pergunte ao criador do script se já existe um plano de restauração do estado inicial (fallback). Se não existir, sugiro que você crie um. Mesmo que o requisitante diga que não precise ou que não será necessário, o DBA precisa se garantir.Por exemplo, o script vai atualizar dados de uma tabela. Antes de executar, faça uma cópia dessa tabela para uma tabela backup. Depois que executar o script, que o objetivo for validado, você até pode deletar o backup, mas seria ainda melhor se você o guardasse, por exemplo, por 1 semana ou 1 mês (dentro dos limites de espaço do seu ambiente).

Pode ser que, no momento após a execução do script, não se note problema, mas dias depois alguém perceba que algo está errado.

 

4) Ao final do script…

Observe se o caractere de término para execução do script existe. Se for um bloco anônimo tem que ter essa barra ‘/’ ao final (vide esse post aqui). Para comandos SQL, as linhas precisam conter o ‘;’ ou o ‘/’ ao final. Se o script não é finalizado corretamente, pode te causar confusão achando que está executando quando nem foi iniciado ainda.

 

Você tem outra sugestão de precaução que podemos tomar? Diz aí nos comentários ou manda um email!

 

PL/SQL – Bloco Anônimo

 

PL/SQL o que?

PL/SQL é uma linguagem de programação para o banco de dados (e algumas outras aplicações) da Oracle. Permite que você manipule os dados de forma procedural ou em blocos, o que não é possível usando puramente SQL padrão ANSI.

Para quem tem um desenvolvedor inquieto dentro de si, significa a liberdade de programar repetições (for, while, loop), programar condições (if, case), trabalhar com variáveis e essa coisa toda, no banco de dados.

Assim, pode-se ter boa parte do código de uma aplicação embutida no banco, trazendo vários benefícios, principalmente em relação a performance e segurança.

 

O Bloco Anônimo

Não é (ainda) um grupo de carnavalescos foliões que seguem um trio elétrico (mas bora criar um pros DBAs nerds pularem carnaval?).

Um código PL/SQL pode ser armazenado como um objeto dentro do banco de dados. Seriam as famosas Procedures, Functions e Triggers. Esses objetos podem ainda ser agrupados em Packages (pacotes), para facilitar a lógica e o gerenciamento de um grupo de blocos que possuem relacionamento entre si ou compartilham fatores em comum.

Eventualmente, podemos sentir a necessidade de executar um código PL/SQL singular, apenas uma vez, para algum teste ou para uma correção de um dado, por exemplo. Nesses casos (e em outros que julgar necessário) você pode usar um bloco anônimo. É um bloco PL/SQL que não será armazenado definitivamente no banco. O bloco será interpretado, executado e depois será descartado.

Não use bloco anônimo se você sentir que irá executar ou já estiver executando o mesmo bloco mais de uma vez, mesmo que a frequência esteja mais para semanal ou mensal do que diária. Nesse caso é melhor criar uma Procedure, pois o Oracle poderá (dependendo do cenário) utilizar recursos internos para obter melhor performance ao executar o mesmo código várias vezes quando ele está armazenado no banco.

 

Estrutura do Bloco Anônimo

[DECLARE]
BEGIN
   -- Statements
   [EXCEPTION]
END;
/

 

Exemplos

-- Bloco Anonimo #1 --
-- Exibe o dia da semana da data corrente --
BEGIN
   DBMS_OUTPUT.PUT_LINE('Output:' || CHR(10) || TO_CHAR(SYSDATE,'DAY'));
END;
/

-- Bloco Anonimo #2 --
-- Exibe a data e hora correntes --
BEGIN
   DBMS_OUTPUT.PUT_LINE ('Output:' || CHR(10) || TO_CHAR(SYSDATE, 'DD/MON/YYYY hh24:mm'));
END;
/

-- Bloco Anonimo #3 --
-- Exibe dados de um funcionario da tabela 'employees', schema 'hr' --
DECLARE
   v_emp hr.employees%ROWTYPE;
BEGIN
   SELECT * INTO v_emp
   FROM hr.employees
   WHERE employee_id=&emp_id;

   DBMS_OUTPUT.PUT_LINE('-----------------------------------');
   DBMS_OUTPUT.PUT_LINE('ID: ' || TO_CHAR(v_emp.employee_id));
   DBMS_OUTPUT.PUT_LINE('Nome: ' || TO_CHAR(v_emp.first_name));
   DBMS_OUTPUT.PUT_LINE('Sobrenome: ' || TO_CHAR(v_emp.last_name));
   DBMS_OUTPUT.PUT_LINE('-----------------------------------');
END;

 

Executando Blocos Anônimos – Dicas

Muito comum na vida de um DBA é pegar um script oriundo de outro time (que muitas vezes é até de outra empresa), normalmente desenvolvedores que cuidam das aplicações, e ter que executar esse script em alguma das suas instâncias de banco de dados.

Esse tópico vale um post só pra ele, dicas sobre execução de scripts: “Executando scripts – Dicas“.

Além de atentar para as dicas gerais de execução de script no link acima, quando vamos executar um bloco PL/SQL que outra pessoa programou, é sempre bom observar se o caractere de término do bloco anônimo (essa barra: ‘/’) consta no final do script. Isso costuma causar confusões.

Já me pediram ajuda mais de uma vez para saber porque a execução de um bloco estava demorando para terminar. O problema é que a execução nem tinha iniciado! =P

Muitas vezes o autor do código esquece de colocar o caractere terminador: ‘/’. Então, o seu cursor no prompt fica parado esperando nova instrução, ele não sabe que já pode executar o que foi digitado. Mesmo que você dê vários [ENTER], ele continua aguardando novas instruções e parece que fica naquele estado onde não libera seu cursor. Por parecer um comportamento típico de quando há algo executando em segundo plano, muitas vezes acham que o script já está executando e, na verdade, não está.

Fui perguntado, certa vez:
- Mas já tem um “END;” no final do bloco. Por que, POR QUE, MEU DEUS, tenho que colocar a barra???

Resposta:
Sem o caractere ‘/’ pode significar que aquele bloco ainda não está terminado. É possível, após um “END;”, termos outras instruções PL/SQL para serem executadas, um bloco PL/SQL dentro de outro. Por isso o Oracle não irá executar nada do bloco até receber o terminador barra.

 

-- Exemplo de bloco dentro de outro bloco --
BEGIN
   DBMS_OUTPUT.PUT_LINE('Bloco Anonimo Principal - Checkpoint 1');

   BEGIN
      DBMS_OUTPUT.PUT_LINE('Bloco Anonimo Interno 1 - Checkpoint 2');
   END;

   DBMS_OUTPUT.PUT_LINE('Bloco Anonimo Principal - Checkpoint 3');

   BEGIN
      DBMS_OUTPUT.PUT_LINE('Bloco Anonimo Interno 2 - Checkpoint 4');
   END;

   DBMS_OUTPUT.PUT_LINE('Bloco Anonimo Principal - Checkpoint 5');
END;
/

 

Se o código, após o [ENTER] depois do primeiro “END;”, no exemplo acima, fosse executado, estaria errado e retornaria erro. O código não estava completo, não era para executar. Se ainda não ficou claro, segue uma analogia para o significado do ‘/’:

Dear Oracle, Master of all Databases, I’m done writing down my prayers to you. Please read it, execute it and report me any problems, my Lord. Sincerely, Your cleric, DBA.

Se você escrever isso e der [ENTER] também funciona, juro!