Oracle
 sql >> Base de données >  >> RDS >> Oracle

Archiveur suspendu en raison de COMPATIBLE ORA-16484

Ce matin, je me suis réveillé avec quelques alertes d'EM concernant le blocage de mon archiveur, semblables à ce qui suit :

Target type=Database Instance 
Target name=orcl4 
Categories=Fault 
Message=The archiver hung at time/line number: Fri Sep 09 06:07:22 2016/376. 
Severity=Critical

J'ai utilisé le DG Broker pour arrêter puis redémarrer le transport de journaux.

edit database orcl set state=transport-off;
edit database orcl set state=transport-on;

Mais l'archiveur serait toujours bloqué. Alors c'est parti pour le journal des alertes pour obtenir plus d'indices. J'ai trouvé ceci dans le journal des alertes du primaire :

TT00: Attempting destination LOG_ARCHIVE_DEST_2 network reconnect (16484)
TT00: Destination LOG_ARCHIVE_DEST_2 network reconnect abandoned
Fri Sep 09 08:07:40 2016
Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl4/trace/orcl4_tt00_16068.trc:
ORA-16484: compatibility setting is too low

Le message d'erreur semble explicite. J'ai réglé COMPATIBLE trop bas. À ce stade, je me suis souvenu que j'avais changé COMPATIBLE au primaire il y a un mois. J'ai dû oublier de changer cela également en veille. Une vérification rapide a confirmé mon hypothèse. COMPATIBLE est défini sur 12.1.0.2 dans le primaire mais sur 11.2.0 dans le standby. Alors voilà mon problème. J'ai changé COMPATIBLE en veille, je l'ai rebondi, puis j'ai repris le transport du journal. La vie allait bien et tout était réparé.

Si vous vous souvenez bien, j'ai dit que j'ai changé COMPATIBLE dans le primaire il y a un mois. Pourquoi était-ce un problème aujourd'hui et pas à l'époque ? Pour le savoir, vous devez connaître l'historique des modifications de cette base de données. Hier soir, nous avons publié un nouveau code en production. Une partie de la publication du code consistait à inclure une nouvelle table qui utilisait la nouvelle fonctionnalité de colonne IDENTITY d'Oracle 12c. Il s'agissait de la première fonctionnalité 12c uniquement que nous avons déployée dans notre base de code. Le serveur de secours tentait de créer la table avec la nouvelle fonctionnalité, mais cette opération n'a pas pu se terminer en raison d'un paramétrage incorrect des paramètres. Je suis encore un peu confus quant à la façon dont cela a affecté le transport des grumes. Je me serais attendu à ce que seul le journal s'applique à être cassé, mais c'est ainsi que cela s'est manifesté.