sql >> Database >  >> RDS >> Oracle

Archiver opgehangen vanwege COMPATIBELE ORA-16484

Vanmorgen werd ik wakker met een paar waarschuwingen van EM over het ophangen van mijn archiver, vergelijkbaar met het volgende:

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

Ik heb de DG Broker gebruikt om het logtransport te stoppen en vervolgens opnieuw te starten.

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

Maar de archiver zou nog steeds worden opgehangen. Dus ga naar het waarschuwingslogboek om meer aanwijzingen te krijgen. Ik vond dit in het waarschuwingslogboek van de 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

De foutmelding lijkt voor de hand liggend. Ik heb COMPATIBEL te laag ingesteld. Op dit punt herinnerde ik me dat ik een maand geleden COMPATIBEL in de primary had gewijzigd. Ik ben vast vergeten dit ook in de standby te wijzigen. Een snelle verificatie bewees mijn hypothese. COMPATIBEL is ingesteld op 12.1.0.2 in de primaire versie, maar op 11.2.0 in de standby-modus. Dus daar is mijn probleem. Ik veranderde COMPATIBEL in de stand-by, stuiterde het en hervatte toen het logtransport. Het leven was prima en alles was opgelost.

Als je het je goed herinnert, zei ik dat ik een maand geleden COMPATIBEL in de primary heb veranderd. Waarom was dit vandaag een probleem en toen niet? Om dat te weten, moet u de wijzigingsgeschiedenis voor deze database kennen. Gisteravond hebben we nieuwe code vrijgegeven voor productie. Een deel van de code-release was om een ​​nieuwe tabel op te nemen die de nieuwe IDENTITY-kolomfunctie van Oracle 12c gebruikte. Dit was de eerste 12c-functie die we in onze codebasis hebben geïmplementeerd. De stand-by probeerde de tabel met de nieuwe functie te maken, maar die bewerking kon niet worden voltooid vanwege een onjuiste parameterinstelling. Ik ben nog steeds een beetje in de war hoe dit het houttransport beïnvloedde. Ik had verwacht dat alleen log van toepassing zou zijn, maar dit is hoe het zich manifesteerde.


  1. Prestatiemythen:tabelvariabelen zijn altijd in het geheugen

  2. Databasetrends 2019 – SQL versus NoSQL, topdatabases, enkelvoudig versus meervoudig databasegebruik

  3. MySQL:meerdere tabellen of één tabel met veel kolommen?

  4. mysql-updatekolom met waarde uit een andere tabel