sql >> Databasteknik >  >> RDS >> Oracle

ORA-1114 Kör Datapatch

Jag har en Oracle 19.3 Multitenant-databas som jag försöker använda 19.7 Release Update. RU installerades bra av opatch. Men datapatch kommer att orsaka ORA-1114-felet. Jag får fel som följande i en av loggarna:

SQL> ändra pluggbar databas GOLD2020_06_18_123653 öppna läs skriv instanser=alla;
ändra pluggbar databas GOLD2020_06_18_123653 öppna läs skriv instanser=alla
*
FEL på rad 1:
ORA-65107:Fel uppstod vid bearbetning av den aktuella uppgiften på instans:1
ORA-17500:ODM-fel:Ogiltigt argument
ORA-01114:IO-fel vid skrivning av block till fil 12346 (block # 1)
ORA-17500:ODM-fel:Ogiltigt argument
ORA-01114:IO-fel vid skrivning av block till fil 12345 (block # 1)
ORA-17500:ODM-fel:Ogiltigt argument

Innan jag kan förklara vad problemet är, låt mig diskutera hur vi använder Multitenant i min miljö. En gång i veckan har vi ett cron-jobb som skapar en kopia av vår produktionsdatabas (med hjälp av diskbaserade hårdvarubilder). Vi kallar denna kopia av produktionen vår "gyllene bild". Denna gyllene bild är inkopplad i vår databas som en av våra PDB. PDB-namnet är av formatet GOLDåååå_mm_dd_hhmiss så att vi vet när det preliminära budgetförslaget skapades.

Alla våra dev- och testdatabaser skapas sedan från denna gyllene bild PDB. När jag behöver uppdatera DEV1 eller TEST stänger vi helt enkelt av PDB för DEV1 eller TEST och släpper det. Vi skapar sedan en snapshot-klon av den senaste gyllene bilden. Den gyllene bilden i PDB är i ENDAST läsläge för att underlätta klonen av ögonblicksbild.

Som jag skrev om här, när en PDB används som källa för en ögonblicksbildsklon, kommer Oracle att ändra filbehörigheterna till 220. Detta är Oracle som skyddar oss från oss själva. Vi bör inte tillåtas att ändra källan till en ögonblicksbildsklon så Oracle gör datafilerna skrivskyddade. Den på Oracle som bestämde sig för att ändra filbehörigheterna var en bra idé pratade inte om det med datapatch-utvecklarna.

Datapatch ser READ ONLY PDB och vill öppna den som READ WRITE, lappa insidan av PDB och ställ sedan tillbaka till READ ONLY. Datapatch kan dock inte öppna PDB i lässkrivläge eftersom filbehörigheterna inte tillåter det. Därav felen jag får.

Oracle gjorde detta mot mig ... de tvingade filbehörigheter på ett sätt och sedan kan datapatch inte göra vad de nu vill att den ska göra.

Jag har inte fått officiellt besked med min serviceförfrågan än, men jag förväntar mig att detta kommer att bli ett fel. Datapatch borde hoppa över alla PDB:er som är källor för snapshot-kloner, enligt min mening.

Under tiden kan du brute force dig igenom detta. Jag försökte använda parametern -exclude_pdbs för datapatch men det fungerade inte. Tydligen finns det ett känt fel där den parametern inte fungerar om din lista med PDB har ett kommatecken. Så jag var tvungen att köra datapatch enligt följande:\

./datapatch -verbose -pdbs cdb\$root
./datapatch -verbose -pdbs pdb\$seed
./datapatch -verbose -pdbs dev1,dev2

Först körde jag datapatch för att patcha CDB$ROOT. Sedan lappade jag PDB$SEED. Sedan lappade jag mina dev PDB:er. Jag har bara inte lappat mina gyllene bild-PDB.


  1. Hur du hanterar dina PostgreSQL-databaser från ClusterControl CLI

  2. SQL Server 2005 Använder DateAdd för att lägga till en dag till ett datum

  3. Hur gör man samma aggregering på varje kolumn, utan att lista kolumnerna?

  4. Den enkla guiden om hur du använder underfrågor i SQL Server