sql >> Databasteknik >  >> RDS >> Oracle

ORA-16205 Uppgradering till 11.2.0.3

Jag försöker uppgradera alla våra databaser från 11.2.0.2 till 11.2.0.3 i år. Mina första uppgraderingar var på en 2-nods RAC primär med 2-nods RAC standby-databas i en testbädd. Det finns inte mycket till denna databas eftersom det bara är en startdatabas. Men detta låter mig testa uppgraderingen på RAC-databaser med både en primär och standby. Jag dokumenterade processen längs vägen.

Efter det var jag redo att uppgradera våra utvecklings- och testdatabaser. Jag använde DBUA för att utföra uppgraderingen och den gick utan problem. Våra dev- och testdatabaser är kloner av produktion och vi kunde testa vår anpassade applikation med den nya versionen.

Äntligen var jag redo att uppgradera produktionen. Återigen använde jag DBUA för att utföra uppgraderingen av den primära databasen. Men den här gången fick jag ett fel:

ORA-16205 log_archive_dest2 innehåller upprepade eller motstridiga värden

Hoppsan. Detta var oväntat eftersom jag inte hade sett det här felet i någon av mina tidigare uppgraderingar. Dev- och testdatabaserna har inte standby, så LOG_ARCHIVE_DEST2 är inte inställt. Min testbädd är lite annorlunda inställd, så jag fattade inte problemet där. Eftersom detta var en oförutsedd händelse avbröt jag min uppgradering samma kväll och bestämde mig för att gå till botten med problemet och boka om uppgraderingen till ett senare datum.

Jag upptäckte att bugg 13387526 (fixad i 11.2.0.4) kan orsaka detta problem för den här parametern när du gör STARTUPGRADERING på databasen. I min testbädd skapade jag en RAC 11.2.0.2-databas med en RAC-standby. I den primära satte jag LOG_ARCHIVE_DEST_2 till något som liknar det som var i produktion. Jag försökte uppgradera på denna testbädd och stötte på samma bugg. För att komma runt problemet ställer jag in LOG_ARCHIVE_DEST_2 på 'service=my_standby db_unique_name=my_standby'. Med denna minimala parameterinställning fortsatte uppgraderingen sedan korrekt. Efter att uppgraderingen gjorts ställer jag tillbaka denna parameter till sin ursprungliga inställning.


  1. PostgreSQL 13:BEGRÄNSNING … MED BÅND

  2. Använda SQL Server lagrade procedurer från Python (pyodbc)

  3. Finns det sätt att ge ett användarvänligt felmeddelande vid överträdelse av begränsningar

  4. Att skriva en fil med flera trådar