Então...

           Durante a aplicação de um patch, encontrei um documentação falando nessa nova nomenclatura dos produtos e resolvi compartilhar.           A Oracle está consolidando diferentes nomes e formantos anteriormente usados, dentro de uma maneira mais simples e fácil de entender os produtos. Essa nova nomenclatura deverá ser usada na documentação Oracle e em várias ferramentas disponibilizadas pelo suporte durante  aplicação de patch e atividades de manutenção. A nova nomenclatura já está em vigor para novas documentações.   

- Sabemos que existe vários casos onde o uso de bind variables pode nos ajudar bastante do ponto de vista da peformance das consultas, mas uma outra área que devemos ter cuidado ao usar binds, é a da segurança de nosso banco. Vou mostrar na prática como o uso de bind pode nos ajudar a dar mais segurança ao código. - Faço a criação da nossa tabela de testes e depois faço insert de algumas linhas. create table clientes (pri_nome varchar2(50), ult_nome varchar2(50)); insert into clientes values ('Thiago','Castro'); insert into clientes values ('Lucas','Costa'); insert into clientes values ('João','Souza'); insert into clientes values ('Antônio','Pereira'); commit; 1 row created. SQL> 1 row created. SQL> 1 row created. SQL> 1 row created. SQL> Commit complete. - Vamos criar uma procedure bem simples, a teste_inject. Como podemos ver no código, ela pega o parâmetro passado, o ultimo nome

Timeout obtaining lock - AIX 6.1 + Oracle 11g Hoje duratnte a instalação do Oracle 11.2.0.3 passei por um pequeno problema. Depois de ter verificado todos os pré-requisitos de hardware e software, fui executar o runInstaller e me deparei com o seguinte erro: $ ./runInstaller oslevel: Timeout obtaining lock. oslevel é um comando do sistema operacional AIX que nos retorna a versão do software. Ele é semelhante ao uname no Linux. Bom, depois de ver a mensagem de erro, tentei executar o comando oslevel com o usuário oracle e o retorno foi o mesmo: $oslevel -s oslevel: Timeout obtaining lock. Percebi que o comando só funcionava com o usuário root: bash-3.2# oslevel -s 6100-06-02-1044 Como a mensagem de erro falava em lock, então pensei que poderia haver algum arquivo temporário que fosse usado durate a execução do comando oslevel e que estava em lock por algum usuário. Então acessei o diretório /tmp e lá existia um arquivo oculto ".oslevel.datafiles". Fiz a exclu

Vou compartilhar aqui uma funcionalidade muito interessante que descobri na ferramenta TOAD. Pelo menos pra mim ela foi bastante útil. Se você precisa executar um único script, ou até mesmo vários scripts em várias bases de dados diferentes, essa funcionalidade é muito show.  Abaixo um breve resumo de como fazer. Primeiro você precisa acessa o "Script Manager" clicando no atalho que circulei em vermelho na figura. Logo depois, devemos criar um grupo de scripts. Depois de criado o grupo, devemos adicionar os scripts que pretendemos executar. No meu caso, criei um script chamado teste.sql que irei executar em duas bases diferentes. Criado o grupo e adicionado os scripts, agora é só executar e verificar o resultado dos comandos.

Para simular um erro no alertlog do seu banco de dados basta você se conectar com o usuário sys e executar: SQL > EXEC SYS.DBMS_SYSTEM.KSDWRT(2, 'ORA-00600: internal error code, arguments: [2252], [1903], [666], [], [], [], [], []'); PL/SQL procedure successfully completed.           Pronto depois disso é só abrir seu arquivo de alerta e vai ver que o erro que você criou vai estar lá. Uma das utilidades dessa rotina é dar sustos em seu colega de trabalho. HEheHEhehEHE