crsctl start crs… FAILURE!

 

Puta que pariu! Não subiu!

 

Perdoem-me o palavrão, mas foi isso que ecoou na minha cabeça quando recebi a mensagem abaixo:

[root@machine bin]# ./crsctl start crs
Attempting to start CRS stack
Failure at scls_scr_create with code 1
Internal Error Information:
Category: 1234
Operation: scls_scr_create
Location: mkdir
Other: Unable to make user dir
Dep: 2

Eu não achei nada relevante na internet sobre esse erro! Nem no Metalink estava claro. Agora sei a solução e, por isso, compartilho com vocês!

 

 

Detalhes do ambiente

 

• Servidor Enterprise Linux 5 (EL5) 64 bits
• Oracle DB Enterprise 10.2.0.5 com PSU 10.2.0.5.6 aplicado, single instance
• Usando ASM

 

 

Mas… “Crsctl” sem ser ambiente RAC?

 

Em ambientes não RAC mas com ASM, temos um processo no SO chamado “ocssd.bin” ativo também. Esse processo fica responsável pela comunicação entre a instância do BD e a instância ASM, ou seja, é vital para o funcionamento do seu BD single instance usando ASM como controlador de arquivos.

Exemplo desse processo ativo em um dos meus servidores agora:

[ prod_db@machine /home/oracle ]: ps -ef |grep ocssd |grep -v grep
oracle 20168 19928 0 Mar23 ? 00:00:13 /oracle_home/bin/ocssd.bin

Esse processo pode estar ativo mesmo se você não estiver usando ASM ou mesmo antes de você criar uma instância (foi iniciado por padrão após instalação de algum produto).

 

Rápido adendo:

Antes de aplicar um patch ou se não vai usar ASM nesse servidor e quer parar o serviço, você pode parar/iniciar esse serviço com o comando “init.cssd stop”/”init.cssd start”, estando logado como root. Comando válido para ambientes NÃO-RAC. Com RAC esse processo também é vital, tome cuidado.

 

 

A parte que interessa: Por que aconteceu? Como corrigir?

 

No meu caso, fui contemplado com o erro após trocarmos o IP e hostname desse servidor. O banco foi instalado com o servidor tendo o hostname=A e IP=X, já estava tudo rodando bonitinho (ASM, DB, usuários trabalhando).

Só que precisávamos trocar o hostname e IP. Durante a janela de manutenção planejada, seguimos os seguintes passos:

• Parei a instância de banco
• Parei o ASM
• Parei o ocssd.bin (com “crsctl stop crs”)

O analista de Linux trocou o hostname de A para B e o IP de X para Y.
Fui todo contente fazer os passos inversos e, ao mandar o primeirão “crsctl start crs”, levo na fuça um direto de um punho com soco inglês cravando esse log na minha testa:

[root@machine bin]# ./crsctl start crs
Attempting to start CRS stack
Failure at scls_scr_create with code 1
Internal Error Information:
Category: 1234
Operation: scls_scr_create
Location: mkdir
Other: Unable to make user dir
Dep: 2

 

Para sanar o erro acima, tive que reconfigurar o CSS seguindo os passos:

1. Se houver algum processo do CSS executando, mate-o:
$ kill -9

2. Com o usuário root, vá até o $ORACLE_HOME/bin
$ cd $ORACLE_HOME/bin

3. Faça a reconfiguração do CSS
$ localconfig reset $ORACLE_HOME

4. Inicie o processo do CSS
$ /etc/init.d/init.cssd start

 

Agora sim! O CSS subiu normalmente e eu pude iniciar o ASM e, depois, o BD!

O porquê de acontecer isso e os detalhes técnicos eu não sei ainda. Não achei documento que explicasse. No máximo, em um PDF chamado “ASM Best Practices” que achei, diz que “If CSS does not start automatically on reboot or if there is a hostname configuration change. The following command (localconfig reset) can be used to reconfigure CSS on that host”.

É tudo que sei! Se for trocar hostname por aí, fique ligado nisso.

 

Obs: Essa solução funcionou para meu ambiente, mas pode não funcionar no seu. Use por sua conta e risco!

 

 

SQL Magazine!

 

Publicação

 

Galerinha, saiu uma publicação de um artigo meu na revista SQL Magazine!

É o artigo que fiz durante minha Pós-Graduação como trabalho final (tipo TCC), do qual extraí um pedaço que publiquei no post explicando sobre latches. O assunto abordado são algumas das opções de tuning para problemas de performance devido grande ocorrência de hard parses.

Infelizmente, não posso republicar meu artigo inteiro aqui no blog, pois ele está na revista, normas editoriais. Mas vocês podem adquirir a revista ou ler online. A prévia do artigo está aqui, SQL Magazine edição 95.

Essa é notícia velha, é verdade, o artigo saiu no começo do ano, eu que não consegui me organizar para vir atualizar o blog.

Estou tirando algumas teias de aranha daqui agora. =)
Obrigado a todos pelos incentivos e pelo carinho.

 

Gotta keep moving! Go go GO!

 

 

Latches – Conceito

 

Briefing

Pessoal, esse é um post simples e direto. Só irei explicar o que é um Latch.

Se você, estudante do banco de dados Oracle, começar a ler sobre a arquitetura desse SGBD, vai encontrar esse termo e, não sabendo o que é, pode interferir no entendimento. Nesse momento a minha expectativa é que você abra o Google e pesquise “o que é latch?” ou “o que são latches?” e, com sorte, caia exatamente aqui nessa página!

Esse texto é parte de um artigo que escrevi como TCC da Pós-graduação e minha intenção era publicá-lo na íntegra aqui no Blog, mas não será possível. Felizmente é por um bom motivo! Esse artigo foi publicado na SQL Magazine e, pelas normas editoriais, não pode ser publicado em outros meios. Confiram o artigo completo na revista! =)

O trecho abaixo eu já tinha publicado antes de trabalhar com a revista SQL Magazine, então vou mantê-lo aqui.

Espero que ajude tanto quanto o post sobre Blocos Anônimos (esse aqui) me parece que têm ajudado.

Não é um conceito direcionado aos iniciantes, está mais ligado a análises de tuning mas, enfim, não vai fazer mal saber o que é, ter uma noção sobre latches. Se eu li, aprendi um pouco e me foi útil, também pode ser pra você.

[Super Mario] Here we gooooo! [/Super Mario]

 

 

Latch – Extraído do meu artigo sobre Hard Parses

Latch é um mecanismo de alocação de estruturas na memória SGA serializado e desenhado para que sejam alocados por curtos períodos de tempo. Ele controla os vários processos que desejam acessar áreas compartilhadas da SGA, permitindo que somente um processo de cada vez acesse a estrutura requisitada, evitando corrupção da memória, ou seja, mantendo a integridade.

Latch não implementa fila de espera, como acontece com outros tipos de locks (travas). Se, ao tentar obter um latch, é identificado que outro processo já o obteve, sua sessão irá aguardar algum tempo e, depois, tentará novamente obter o latch.

Quando o latch for liberado pelo processo que o obtinha, se houver vários processos que precisam do mesmo latch, o primeiro processo que solicitá-lo após a liberação terá sucesso, os demais continuarão tentando aleatoriamente até conseguir ou até esgotar o tempo de tentativas.

Atente-se que não houve fila de espera e, portanto, pode ser que o primeiro processo que chegou para obter o latch bloqueado não seja o primeiro a consegui-lo após a liberação do latch.

Quando um processo fica em loop tentando obter o latch e há várias sessões tentando a mesma coisa, tal processo ficará um tempo ocupando CPU na esperança que o latch seja liberado logo (como o latch foi desenhado para durar curtos períodos, presume-se que a chance de ser liberado em breve é alta). Somente após algum tempo em CPU tentando obter o latch e falhando, o processo liberará a CPU e tentará de novo mais tarde. Isso indica, normalmente, um cenário em que há várias sessões tentando obter o mesmo latch, ao invés de uma sessão única alocando o latch por um longo tempo, como acontece com outros tipos de locks.

Tanto essa espera na CPU quanto a saída e a volta para a CPU para tentar novamente são gastos com recursos primários devem ser evitados, se possível.

Hard parse é uma operação que utiliza latches para ser completada. Portanto, temos a seguinte relação: quanto mais hard parses, mais latches. Aumentar o número de latches significa ter mais processos alocando as estruturas compartilhadas da memória (alta concorrência) e, consequentemente, aumenta a chance de que outro processo tenha que aguardar para obter seu latch ao invés de obtê-lo instantaneamente.

Quanto menos hard parses, menos latches, maior a chance de um processo obter seu latch instantaneamente (baixa concorrência), menor a chance de espera, mais rápido será o fluxo através dos mecanismos internos e mais rápido será o término da operação executada.

 

Caso o trecho tenha te deixado ainda mais confuso, peço que aguarde o post com o artigo completo. Se esse capítulo extraído não fez sentido no contexto onde você leu sobre latch, fará dentro do artigo.