Processo SMON em loop infinito na instância do banco de dados Oracle… ajuda!

Question

Minha equipe e eu buscamos no Google (e ficamos bêbados!) tentando encontrar uma resposta para essa questão, portanto, esperamos que os gurus da Oracle sobre SF saibam a resposta.

Uma semana atrás tivemos uma queda de energia no prédio que hospedava nosso servidor. Todo o servidor caiu no meio de uma exportação de banco de dados. Quando colocamos o servidor novamente online, notamos um novo processo, o SMON, funcionando como um louco na instância do banco de dados. Aqui está uma captura de tela da "Atividade principal" no OEM.

Oracle Enterprise Manager http://www.myviewstate.net/images/oem.png

Nós deixamos passar por um tempo, mas depois de um dia ficamos preocupados. Depois de verificar os logs, percebemos que ele parece estar em um loop infinito. Aqui está uma parte do arquivo de log:

Fri Aug 14 14:43:58 2009
SMON: about to recover undo segment 12
SMON: mark undo segment 12 as available
SMON: about to recover undo segment 12
SMON: mark undo segment 12 as available
SMON: about to recover undo segment 12
SMON: mark undo segment 12 as available
SMON: about to recover undo segment 12
SMON: mark undo segment 12 as available
SMON: about to recover undo segment 12
SMON: mark undo segment 12 as available

Aqui estão os passos que tomei até agora (a maioria dos quais tentei devido a coisas que encontrei online), nenhuma das quais funcionou.

1. Reinicie a instância do banco de dados
2. Coloque os espaços de tabela do usuário off-line, traga-os de volta online e reinicie a instância do banco de dados
3. Criado um novo espaço de tabela REDO, pare a instância db, aponte o spfile para o novo tablesace, então reinicie o instância

Tenha em mente que eu sou um desenvolvedor e tenho muito pouca experiência em Oracle, quanto mais experiência como DBA.

Alguma sugestão?

    

Answer 1

Seu banco de dados está em loop ao tentar fazer uma recuperação e trazer segmentos de undo on-line para recuperar seu banco de dados. Já que você não é dba, eu imediatamente colocaria o suporte da oracle na linha e diria que você precisa de muita ajuda e que você não é dba. É muito provável que você inicie o banco de dados e desative o gerenciador de recuperação que está executando o loop smon ao tentar limpar os segmentos de desfazer. Tendo que fazer a limpeza do segmento de desfazer no passado, o melhor é fazer com o suporte do oracle. Muitas das etapas exigirão alguns eventos e parâmetros de sublinhado que desativam / habilitam o mojo oracle oculto. Eu não recomendaria tentar qualquer coisa que você encontrasse por conta própria ou que fosse postada sem entender a implicação e, possivelmente, como recuperar / desistir de suas tentativas. O objetivo é recuperar seu banco de dados e não torná-lo pior. Obter suporte oracle no telefone o mais cedo possível.

    

Answer 2

O Oracle 9i e superior usa tablespaces UNDO especiais e logs REDO para gerenciar suas transações.

O REDO armazena um log das declarações executadas, e o UNDO armazena antes e depois das imagens dos blocos de banco de dados afetados por essas declarações.

Fiz um pouco mais de escavação ... Se você tiver acesso ao Oracle Metalink (seu site de suporte), procure a ID de erro 3418428 Este parece ser o seu problema. Não consigo reproduzir as informações aqui, pois acredito que viola o contrato de suporte da Oracle.

A essência geral do problema é que o Gerenciamento Automático de Undo cria dinamicamente segmentos ROLLBACK no tablespace UNDO on demand. O número e tamanho dos segmentos criados varia dependendo da carga no banco de dados.

Antes do banco de dados travar, ele havia criado e colocado on-line mais do que o número padrão de segmentos ROLLBACK.

Após o travamento, o banco de dados não colocou on-line todos os segmentos ROLLBACK que tinha antes do travamento.

Eu acho que 10g podem se recuperar disso se você der tempo suficiente; 9i teve mais problemas. O banco de dados está aberto para conexões e está respondendo?

Além disso, você pode estar no mundo obscuro da recuperação do Oracle. Eu sugiro obter alguma ajuda, pois é fácil fubar totalmente o Oracle ao tentar recuperações.

    

Answer 3

Você não menciona qual versão do Oracle é essa ... existe um problema no Metalink for 10.2.0.4 com esse sintoma (821743.1). Seu sistema faz transações distribuídas? Pode haver uma transação de confirmação de duas fases não confirmada que esteja "presa". Consultar a visualização dba_2pc_pending:

selecione local_tran_id, global_tran_id, state de dba_2pc_pending;

Se houver registros que não vão embora, você precisará reverter a força neles. Tenha muito cuidado neste reino ... O conselho do @Geoff é bom, o suporte da Oracle provavelmente deve ser consultado aqui, é por isso que você está pagando. Esse sintoma após uma falha pode indicar alguma corrupção no banco de dados. É raro, mas é possível. A Oracle deve ser "prova de corrupção", mas os melhores planos e tudo isso ....

    

Answer 4

Não sou administrador ou desenvolvedor da Oracle, mas um rápido google em "smon oracle" me disse qual é o processo e o que ele está fazendo depois que seu DB teve o poder de aumentar o uso da CPU. Ele continuará assim até que seja consertado o dano causado pelo poder que está sendo puxado. Em caso de dúvida, abra um ticket com a Oracle - você paga muito pelo suporte.

    

Answer 5

O rollforward / open / rollbackward é explicado aqui

Em geral, os redo logs são aplicados empurrando as alterações de volta para o banco de dados. No final, qualquer alteração que tenha sido aplicada, mas que não terminou com um commit, deve ser revertida. Ele lê o UNDO para desfazer a mudança.

Se estiver desfazendo, significa que houve uma alteração não confirmada que precisa ser revertida. Não teria sido uma exportação (como isso deve ser puro select). Olhe para USED_UREC na transação v $. Deve haver uma linha (talvez mais) com um valor diferente de zero, o que (esperançosamente) deve diminuir, pois os registros de desfazer são aplicados para remover a alteração não confirmada.