Oracle 10.2.0.1 - 10.2.0.4 erros do conjunto de patch em tabelas de enfileiramento avançado

Question

Estamos executando o Oracle no RHEL 5.4 de 64 bits. Recentemente fizemos uma atualização de 10.2.0.1 para 10.2.0.4. Muitos erros foram gerados durante a atualização (amostra listada abaixo de trace.log), mas durante o teste de aplicativos depois tudo pareceu bem (limpar EXP, inserções, atualizações, exclusões, etc.). Os erros parecem estar todos relacionados a tabelas e exibições do Advanced Queuing. Nós não estamos usando a replicação, esta é uma simples instância única db.

ORA-24002: QUEUE_TABLE SYS.AQ_EVENT_TABLE does not exist
ORA-24032: object AQ$_AQ_SRVNTFN_TABLE_T exists, index could not be created
ORA-24032: object AQ$_ALERT_QT_S exists, index could not be created for queue
ORA-06512: at "SYS.DBMS_AQADM_SYSCALLS", line 117
ORA-06512: at "SYS.DBMS_AQADM_SYS", line 5116

Vale a pena se preocupar com isso e, em caso afirmativo, como faço para limpar / recriar os objetos corrompidos e / ou ausentes?

    

Answer 1

Minha sugestão é não ignorá-lo.

Recentemente tive problemas relacionados ao AQ depois de mudar de PL / SQL Interpretados para PL / SQL Compilado Nativo. Minhas tabelas de AQ onde munged e tivemos alguma corrupção de dicionário de dados. Nós não usamos explicitamente nenhum recurso do AQ para nossos produtos, mas parece que o Oracle o utiliza para algumas de suas características.

A questão principal para nós é que não fomos capazes de usar as exportações de DataPump quando eles foram bombardeados com erros relacionados a AQ. Também o acesso OEM a este banco de dados era muito esquisito. Todas as operações do usuário pareciam funcionar bem.

Se você verificar o seu log de alerta, você pode estar recebendo alguns ORA-600 estranhos, porque o subsistema AQ não está disponível.

Minha sugestão é abrir um SR com Oracle e partir daí. Eles têm um procedimento não publicado que eles podem dar a você e recria as tabelas AQ. Se você não tem nenhuma corrupção de dicionário de dados, deve ser algo simples ... mas certifique-se de que você tem capacidade de absorver algum tempo de inatividade, pois o procedimento não pode ser executado enquanto os usuários estiverem conectados. Também certifique-se de ter alguns backups bons - acabamos tendo que reverter uma semana por causa de tudo isso (por sorte, apenas um banco de dados Dev).