Blog do DBA Valentim

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

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

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!

Algumas vezes queremos descobrir quem é o infeliz que está bloqueando uma conta no banco de dados. Para tornar as coisas mais simples você pode habilitar a auditoria no banco de dados e ativar a auditoria neste evento específico. Isso ajuda a descobrir qual é a máquina, qual o erro retornado, quando foi, dentre outras informações. No 10g é necessário realizar os seguintes procedimentos, mas no 11g a auditoria já é habilitada por padrão: 1. Defina o parâmetro audit_trail para "DB" no spfile/pfile e reinicie a instância: SQL> alter system set audit_trail=DB scope=spfile ; System altered. SQL> shutdown immediate Database closed. Database dismounted. ORACLE instance shut down. SQL> startup ; ORACLE instance started. 2. Agora habilite o audit no evento desejado de falha de login: SQL> audit session whenever not successful ; Audit succedded. 3. Para testar efetue uma conexão com o banco de dados informando senha errada e execute a consulta: SQL> s...

Galera, mais uma que eu preciso citar. Estava eu achando que ia ser simples o procedimento de alterar alguns parâmetros na instância ASM do Oracle, mas não foi bem assim. A Oracle recomenda fortemente que você utilize o AMM (Automatic Memory Management) pra tudo aceitando os valores padrão , inclusive instâncias ASM, mas isso, inclusive citado em alguns lugares, pode não ser muito legal, pois pro ASM é melhor memória estática. Esse detalhe vale pra versão 11.1, mas pra versão 11.2 ainda não sei. Bom, precisei primeiramente alterar o parâmetro "processes" das instâncias ASM, pois estão penduradas 8 bases e o limite de processos estourou rapidinho. Ao tentar alterar este valor de acordo com a documentação "ASM Best Practices" e reiniciar a instância ASM o erro era mostrado: ORA-04031: unable to allocate "string" bytes of shared memory ("string","string","string","string") Foi aí que comecei a pensar em aumen...