sql >> Database teknologi >  >> RDS >> Oracle

ORA-1114 kører Datapatch

Jeg har en Oracle 19.3 Multitenant-database, som jeg forsøger at anvende 19.7 Release Update. RU blev installeret af opatch fint. Men datapatch vil pådrage sig ORA-1114-fejlen. Jeg får fejl som følgende i en af ​​logfilerne:

SQL> alter pluggbar database GOLD2020_06_18_123653 åben læse skrive instanser=alle;
ændre pluggbar database GOLD2020_06_18_123653 åben læse skrive instanser=alle
*
FEJL på linje 1:
ORA-65107:Der opstod en fejl under behandling af den aktuelle opgave på instans:1
ORA-17500:ODM-fejl:Ugyldigt argument
ORA-01114:IO-fejl ved at skrive blok til fil 12346 (blok # 1)
ORA-17500:ODM-fejl:Ugyldigt argument
ORA-01114:IO-fejl ved at skrive blok til fil 12345 (blok # 1)
ORA-17500:ODM-fejl:Ugyldigt argument

Inden jeg kan forklare, hvad problemet er, så lad mig diskutere, hvordan vi bruger Multitenant i mit miljø. En gang om ugen har vi et cron-job, der opretter en kopi af vores produktionsdatabase (ved hjælp af disk-baserede hardware-snapshots). Vi kalder denne kopi af produktionen for vores "gyldne billede". Dette gyldne billede er sat ind i vores database som en af ​​vores PDB'er. PDB-navnet er af formatet GOLDåååå_mm_dd_hhmiss så vi ved, hvornår det FBF blev oprettet.

Alle vores dev- og testdatabaser oprettes derefter ud fra dette gyldne billede PDB. Når jeg har brug for at opdatere DEV1 eller TEST, lukker vi simpelthen PDB for DEV1 eller TEST og dropper det. Vi opretter derefter en snapshot-klon af det seneste gyldne billede. Det gyldne billede PDB er i LÆSEKUN tilstand for at lette snapshot-klonen.

Som jeg skrev om her, når en PDB bruges som kilden til en snapshot-klon, vil Oracle ændre filtilladelserne til 220. Dette er Oracle, der beskytter os mod os selv. Vi bør ikke have lov til at ændre kilden til en snapshot-klon, så Oracle gør datafilerne skrivebeskyttede. Hvem end hos Oracle, der besluttede at ændre filtilladelserne, var en god idé, talte ikke om det med datapatch-udviklerne.

Datapatch ser LÆSEKUN PDB og ønsker at åbne det som LÆS SKRIV, patch indersiden af ​​PDB og sæt derefter tilbage til LÆSEKUN. Datapatch kan dog ikke åbne PDB i læse-skrivetilstand, fordi filtilladelserne ikke tillader det. Derfor fejlene jeg modtager.

Oracle gjorde dette mod mig ... de tvang filtilladelser på én måde, og så kan datapatch ikke gøre, hvad de nu vil have det til at gøre.

Jeg har ikke modtaget officielle besked med min serviceanmodning endnu, men jeg forventer, at dette bliver en fejl. Datapatch burde springe alle PDB'er over, der er kilder til snapshot-kloner, efter min mening.

I mellemtiden kan du brute force dig vej igennem dette. Jeg forsøgte at bruge parameteren -exclude_pdbs til datapatch, men det virkede ikke. Tilsyneladende er der en kendt fejl, hvor den parameter ikke virker, hvis din liste over PDB'er har et komma. Så jeg var nødt til at køre datapatch som følger:\

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

Først kørte jeg datapatch for at patch CDB$ROOT. Så lappede jeg PDB$SEED. Så lappede jeg mine dev PDB'er. Jeg har bare ikke lappet mine gyldne billed-PDB'er.


  1. Operatorer til udpakning af JSON-underkomponenter

  2. Vend denne vej z/y/x i Oracle til x/y/z

  3. installere Oracle Instantclient på Mac OS/X uden at indstille miljøvariabler?

  4. 9 bedste fremgangsmåder til at skrive SQL-forespørgsler