Solução para recuperar tablespace PSAPUNDO no sistema SAP e migrar para PSAPUNDO2 com sucesso.

Ok,

Esta é uma espécie de suposição, pois a criação do UNDO2 está ausente no registro de alerta,

Mas aqui está:

O BD não pode ativar o PSAPUNDO2 devido a um tipo incorreto,

então presumo que foi criado como um tablespace de DADOS, ou a criação falhou.

Como não faz parte do DBA_DATA_FILES, é provável que a criação tenha sido apenas parcialmente bem-sucedida,

porque ao tentar criar o UNDO3 falha, já que especifica o arquivo de dados do UNDO2 e

o BD entende que este arquivo já pertence ao BD (-1537), o que significa que o nome do arquivo foi inserido

nos arquivos de controle (V$DATAFILE), mas a criação não foi concluída (por isso dba_data_files não tem entrada).

A pergunta básica é: Você tem o arquivo de dados do PSAPUNDO em backup?

Se sim, restaure-o e os logs e você terá terminado. Limpe o que está relacionado ao UNDO2 e UNDO3,

missão cumprida.

Quanto à outra opção (recriar UNDO), embora não tenha certeza se realmente é uma opção (pois não tenho certeza com as informações fornecidas de que os segmentos de desfazer em estado de recuperação não são necessários):

Nos velhos tempos, com segmentos de rollback reais, você precisava de um segundo segmento de rollback para criar um tablespace adicional. Como as novas BDs são criadas com um tablespace UNDO na declaração CREATE DATABASE, hoje em dia não é mais necessário, mas ao iniciar um BD sem UNDO, é provável que a criação de tablespaces adicionais ainda não tenha sucesso hoje por essa razão.

(Devo admitir que nunca verifiquei desde a versão 10)

Portanto, se realmente for possível recuperar este sistema removendo e substituindo o PSAPUNDO,

a maneira de fazer isso seria:

- definir a gestão de desfazer como manual

- criar um segmento de rollback clássico (pode ser RS_HELP em TS SYSTEM)

- colocar online o segmento de rollback RS_HELP

- criar o tablespace de desfazer UNDO4 com um nome de arquivo de dados ainda não utilizado.

- redefinir o desfazer automático para UNDO4

- colocar offline e excluir o segmento de rollback RS_HELP

- reiniciar o BD

Se isso fizer com que o BD inicie corretamente sem NENHUM problema no registro de alerta, pelo menos você terá avançado um passo.

Em seguida, tentaria limpar as evidências do UNDO2 / UNDO3.

Neste ponto, você deve ser capaz de iniciar o SAP.

Se isso funcionar bem por um tempo, você pode considerar excluir o PSAPUNDO com qualquer opção de forçamento mencionada anteriormente, mas enquanto não tiver certeza, não perca nenhum redolog desde seu último backup válido em diante.

Mais uma vez, se você tiver um backup, vá para a recuperação.

Basta restaurar e recuperar o PSAPUNDO.

Volker

Olá,

Anexo o registro de alerta como referência.

Nossa versão do Oracle é 10g.

SQL> selecione status de v$instance;

STATUS

------------

ABERTO

Em relação à sua pergunta O banco de dados colocou arquivos adicionais offline porque o PSAPUNDO não estava disponível no início. Executei o seguinte comando e descobri

que todos os outros arquivos estão online, exceto o arquivo2.

SQL> selecione * de dba_data_files;

NOME_DO_ARQUIVO

--------------------------------------------------------------------------------

ID_DO_ARQUIVO NOME_DO_TABLESPACE††††††††††††††††††† BYTES†††† BLOCOS ESTADO

---------- ------------------------------ ---------- ---------- ---------

RELATIVE_FNO AUT†† MAXBYTES† MAXBLOCKS INCREMENT_BY USER_BYTES USER_BLOCKS

------------ --- ---------- ---------- ------------ ---------- -----------

ONLINE_

-------

D:\ORACLE\SOL\SAPDATA1\UNDO_1\UNDO.DATA1

2 PSAPUNDO†††††††††††††††††††††††††††††††††††††††††††† DISPONÍVEL

2

RECUPERAR

O problema ainda não foi resolvido.

Olá,

Acredito que pode haver um problema.

Se uma instância de banco de dados for bloqueada, DEVE ter todo o UNDO ATIVO disponível para poder realizar uma recuperação de instância ao iniciar. Caso contrário, as ações de desfazer necessárias provavelmente não poderão ser executadas. Portanto, recomendaria enfaticamente NÃO excluir o undo, a menos que tenha certeza de que não é mais necessário.

Portanto, quando mencionou que iniciou a instância, fiquei intrigado em saber como o Oracle conseguiu fazer isso com arquivos de undo offline. Pode anexar o registro de alerta desde a última inicialização até "Completed alter database open" e verificar o estado da instância a partir de V$INSTANCE?

Também gostaria de saber se esta é a versão 10 ou 11.

E gostaria de saber se o banco de dados estabeleceu arquivos adicionais offline porque o PSAPUNDO não estava disponível no início.

Para constar, acredito que não poderá escapar sem restaurar e recuperar o PSAPUNDO.

Se excluir o undo que pode ser necessário para uma recuperação limpa da instância em caso de bloqueio, é possível que não consiga abrir o banco de dados novamente sem usar alguns parâmetros para permitir corrupção, e isso pode estar completamente fora de suporte.

Volker