Blog do DBA Valentim

E aí galera!? Bom, hoje tive que criar um procedimento de desligamento para todas as bases de dados do lugar onde eu trabalho. Foi solicitado para documentação. Pensei no trabalho que iria ser fazer um script para cada base de dados em cada servidor (e não são poucos) que fizesse o seguinte: export ORACLE_SID=(instância1) sqlplus / as sysdba <<EOF shutdown immediate; exit EOF export ORACLE_SID=(instância2) sqlplus / as sysdba <<EOF .... Criei um script onde isso poderia tornar as coisas mais fáceis e que se aplica a qualquer servidor do ambiente: (UPDATE 17/01/2012 - Script atualizado para ignorar linhas que começam com "*" geralmente criadas quando um agente do grid control é instalado) (UPDATE 06/03/2012 - Script reformulado, agora ele solicita o comando. É similar ao script do post "RAC EDITION") #!/bin/bash echo "Provide utility:" echo "SQLPLUS => 1" echo "RMAN => 2" read utility if [ -z $util

OBS.: Reformulei este antigo post que falava sobre BIGFILE. Anteriormente eu passei um script que quebrava o arquivo em partes iguais de acordo com o valor do paralelismo, mas se o arquivo for muito grande vai demorar da mesma forma. Não é obrigatório ser igual ao número de canais. É possível quebrar o arquivo em tamanhos menores e quando o canal terminar uma parte iniciará a outra. Desta forma é mais recomendável. O Bigfile pode ajudar em vários fatores, mas é temos que saber utilizá-lo. O tempo necessário para backup/restore aumenta consideravelmente quando trabalhamos com ele sem MULTISECTION. Prefira SMALLFILE quando possível. Melhor ainda: faça um balanço entre usar BIGFILE e SMALLFILE, analisando a questão da quantidade de arquivos, tempos de backup/restore, limitações, etc. Foi incluído um recurso interessante no RMAN (Recovery Manager) do Oracle 11g que são os "backups  multissessão"  . Resumindo, para as tablespaces BIGFILE (tablespaces que possuem somente um a

Depois de um tempo ausente, volto com este probleminha que já aconteceu comigo duas vezes. Pediram-me para que eu restaurasse um banco de dados para criação de uma base de testes (ainda bem) e no momento da restauração algo assim aconteceu: creating datafile No=1 name=/....../o1_mf_system_5n2w3nky_.dbf released channel: t1 RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of restore command at 09/05/2010 09:34:12 ORA-01180: can not create datafile 1 ORA-01110: data file 1: '/....../o1_mf_system_5n2w3nky_.dbf' Segundo o METALINK, isso acontece porque "O Rman acha que não tem backups pra restaurar, então ele recria os arquivos para aplicar os archives. No entanto isso não funciona para a tablespace SYSTEM". De fato é verdade. Quando tentamos restaurar os demais arquivos dá c

A versão Oracle Database 11gR2 realmente é uma versão repleta de recursos e melhorias que nos ajudam muito, mas muito mesmo. Algumas coisas mudaram, como o novo SPM (SQL Plan Management) que passa a gerenciar melhor a questão de planos trabalhando junto com a sua base SMB (SQL Management Base). Quando um comando SQL é "hard parsed", o CBO (Cost Based Optimizer) produz vários planos de execução e seleciona um com o custo mais baixo. Se uma baseline de plano de SQL estiver presente, o otimizador compara apenas o plano recém-produzido com os planos já existentes na baseline. Se um plano adequado é encontrado ele é marcado como ACEITO (ACCEPTED) e o plano é utilizado. Se a baseline não tiver um plano aceito,  o otimizador avalia os planos aceitos na baseline e usa o que tiver menor custo. Se o plano de execução originalmente produzido pelo otimizador teve um custo menor que o presente na baseline, ele é adicionado a baseline como um plano NÃO-ACEITO (NON-ACCEPTED), então não é u

Vi este erro hoje quando foi tentado iniciar uma base de dados (fase OPEN): ORA-00600: internal error code, arguments: [kskopen1], [], [], [], [], [], [], [] Segundo o trace gerado poderia ser algo relacionado ao Resource Manager: ... Dump of memory from 0x0000000104AAF424 to 0x0000000104AAF564 104AAF420          25642C20 43505573 203D2025      [%d, CPUs = %] 104AAF430 640A0049 4F70656E 696E6720 77697468  [d..I Opening with ] 104AAF440 20696E74 65726E61 6C205265 736F7572  [ internal Resour ] 104AAF450 6365204D 616E6167 65722070 6C616E0A  [ ce Manager plan. ] 104AAF460 0049424D 6B736B6F 70656E31 0049424D  [.IBM kskopen1 .IBM] 104AAF470 6B736B74 68657869 7428293A 20206465  [ kskthexit ():  de] 104AAF480 6C657469 6E672074 68726561 64203078  [leting thread 0x] 104AAF490 25782C20 76632030 7825782C 20736573  [%x, vc 0x%x, ses] 104AAF4A0 73203078 25700A00 6B736B74 6872736F  [s 0x%p..kskthrso] ... Algum recurso foi habilitado e não era suportado gerando o erro. Há uma form

Feliz ano novo (para os que consideram o início do ano após o carnaval), Desculpem minha ausência, mas é que o tempo é curto e muitas coisas estão acontecendo ao mesmo tempo. Preciso informar a vocês um evento em particular que ocorreu comigo em um dos ambientes em que trabalho. O ambiente é em RAC 11g e um sistema foi migrado. Quando este foi migrado, foi percebido um alto índice de ocorrência do evento "ENQ: TX - ROW LOCK CONTENTION" que não acontecia antes. Isso parece claro, porém não foi tão fácil assim resolver. Este evento acontecia em INSERTS, UPDATES e DELETES causando um "pequeno" estresse ao utilizar a aplicação. Anteriormente o sistema funcionava normalmente em SINGLE INSTANCE, mas os problemas vieram após "virar" pro RAC. Sabemos que falta de índices em chaves estrangeiras causam problemas de ROW LOCK, mas não era o caso, pois não acontecia anteriormente. Quando ocorre este evento em INSERTS, geralmente, é pelo fato de uma sessão estar ins

O parâmetro de inicialização AUDIT_SYSLOG_LEVEL é parcialmente documentado. Várias imprecisões na documentação sugerem que o parâmetro é menos útil do que realmente é. Ações de banco de dados pelo SYS e/ou administradores de banco de dados ou os operadores podem ser auditados para registrar nos arquivos de log (pelo deamon do syslog) do sistema operacional UNIX pertencentes ao root. Isso impede que usuários de banco de dados privilegiados removam os registros de auditoria que contêm um registo das suas atividades. A configuração padrão é a auditoria CONNECT, STARTUP e SHUTDOWN com privilégios SYSDBA ou SYSOPER com escrita nos arquivos pertencentes ao proprietário do software Oracle, embora não havendo auditoria do SQL, PL/SQL e outras ações com esses privilégios ou outros privilégios, tais como a role DBA. Em outras palavras, com exceção das operações descritas acima, a auditoria padrão (veja o parâmetro AUDIT_TRAIL), assim como auditoria fina (veja o pacote DBMS_FGA), estão desligadas

O comando CREATE/ALTER USER <usuario> IDENTIFIED BY VALUES '<password hash>' não é documentado. É utilizado internamente para armazenar as senhas que foram anteriormente salvas com o utilitário export na tabela do dicionário de dados SYS.USER$. Em algumas situações onde o DBA precisa se conectar com um certo usuário, mas não sabe a senha dele ou a possibilidade de salvar estas senhas ganha-se tempo ao invés de sair perguntando por elas. Às vezes você como DBA precisa realizar alguma manutenção que é preciso ser com aquele schema específico, mas a empresa não quer fornecer a senha do usuário/schema então este recurso pode ser utilizado da seguinte maneira: Você se conecta com um usuário administrativo (DBA ou SYSDBA) e executa a consulta e anota o resultado: SQL> spool senha.log SQL> SELECT password FROM dba_users     WHERE username='SCOTT'; PASSWORD                      ------------------------------ F894844C34402B67         

Feliz 2011 pessoal! Que este ano seja ótimo para nós, com certificações, saúde, reconhecimentos e outras conquistas. Em breve estarei postando mais alguns artigos interessantes por aí. Fiquem ligados!