Thiago Castro | Databases

- 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

- 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 ...

       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 p...

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

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 dat...