sql >> Database >  >> RDS >> Oracle

ORA-1114 Datapatch uitvoeren

Ik heb een Oracle 19.3 Multitenant-database die ik probeer toe te passen op de 19.7 Release Update. De RU is prima door opatch geïnstalleerd. Maar datapatch zal de ORA-1114-fout veroorzaken. Ik krijg fouten zoals de volgende in een van de logs:

SQL> verander pluggable database GOLD2020_06_18_123653 open lezen schrijven instances=all;
verander pluggable database GOLD2020_06_18_123653 open lezen schrijven instances=all
*
FOUT op regel 1:
ORA-65107:Er is een fout opgetreden bij het verwerken van de huidige taak op instantie:1
ORA-17500:ODM-fout:ongeldig argument
ORA-01114:IO-fout bij het schrijven van blok naar bestand 12346 (blok # 1)
ORA-17500:ODM-fout:ongeldig argument
ORA-01114:IO-fout bij het schrijven van blok naar bestand 12345 (blok # 1)
ORA-17500:ODM err:Ongeldig argument

Voordat ik kan uitleggen wat het probleem is, wil ik eerst bespreken hoe we Multitenant in mijn omgeving gebruiken. Een keer per week hebben we een cron-taak die een kopie van onze productiedatabase maakt (met behulp van schijfgebaseerde hardware-snapshots). We noemen dit productie-exemplaar ons 'gouden imago'. Deze gouden afbeelding is aangesloten op onze database als een van onze PDB's. De PDB-naam heeft de indeling GOLDjjjj_mm_dd_hhmiss zodat we weten wanneer die PDB is gemaakt.

Al onze ontwikkel- en testdatabases worden vervolgens gemaakt op basis van deze gouden afbeelding PDB. Wanneer ik DEV1 of TEST moet vernieuwen, sluiten we gewoon de PDB voor DEV1 of TEST af en laten deze vallen. Vervolgens maken we een snapshot-kloon van de nieuwste gouden afbeelding. De PDB met gouden afbeelding staat in de modus ALLEEN LEZEN om de snapshot-kloon te vergemakkelijken.

Zoals ik hier al schreef, zal Oracle, wanneer een PDB wordt gebruikt als de bron voor een snapshot-kloon, de bestandsrechten wijzigen in 220. Dit is Oracle die ons tegen onszelf beschermt. We mogen de bron van een snapshot-kloon niet wijzigen, dus Oracle maakt de gegevensbestanden alleen-lezen. Degene die bij Oracle besloot om de bestandsrechten te wijzigen, was een goed idee, praat er niet over met de ontwikkelaars van datapatches.

Datapatch ziet de PDB ALLEEN LEZEN en wil deze openen als READ WRITE, de binnenkant van de PDB patchen en dan terugzetten op ALLEEN LEZEN. Datapatch kan de PDB echter niet openen in de lees-schrijfmodus omdat de bestandsrechten dit niet toestaan. Vandaar de foutmeldingen die ik krijg.

Oracle deed dit bij mij ... ze dwongen bestandspermissies op een manier af en dan kan datapatch niet doen wat ze nu willen dat het doet.

Ik heb nog geen officieel bericht ontvangen met mijn Service Request, maar ik verwacht dat dit een bug wordt. Datapatch zou naar mijn mening alle PDB's moeten overslaan die bronnen zijn voor snapshot-klonen.

In de tussentijd kun je je hier met brute kracht een weg door banen. Ik heb geprobeerd de parameter -exclude_pdbs voor datapatch te gebruiken, maar dat werkte niet. Blijkbaar is er een bekende bug waarbij die parameter niet werkt als je lijst met PDB's een komma heeft. Dus ik moest de datapatch als volgt laten draaien:\

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

Eerst heb ik datapatch uitgevoerd om CDB$ROOT te patchen. Daarna heb ik PDB$SEED gepatcht. Daarna heb ik mijn dev-PDB's gepatcht. Ik heb mijn gouden beeld-PDB's gewoon niet gepatcht.


  1. Selecteer op een eenvoudige manier de rechterkolom als primaire sleutel voor een bepaalde tabel

  2. Barman Cloud – Deel 2:Cloudback-up

  3. MySQL versus PDO

  4. VERWIJDEREN VS DROP in SQL