J'ai une base de données Oracle 19.3 Multitenant que j'essaie d'appliquer la mise à jour de la version 19.7. Le RU a été installé par opatch très bien. Mais datapatch entraînera l'erreur ORA-1114. J'obtiens des erreurs telles que les suivantes dans l'un des journaux :
SQL> alter pluggable database GOLD2020_06_18_123653 open read write instances=all ;
alter pluggable database GOLD2020_06_18_123653 open read write instances=all
*
ERREUR à la ligne 1 :
ORA-65107 :Erreur rencontrée lors du traitement de la tâche en cours sur l'instance : 1
ORA-17500 :Erreur ODM :argument non valide
ORA-01114 :Erreur d'écriture du bloc d'E/S dans le fichier 12346 (bloc n° 1)
ORA-17500 :Erreur ODM :argument non valide
ORA-01114 :Erreur d'E/S lors de l'écriture du bloc dans le fichier 12345 (bloc n° 1)
ORA-17500 :Erreur ODM :Argument non valide
Avant de pouvoir expliquer quel est le problème, laissez-moi vous expliquer comment nous utilisons Multitenant dans mon environnement. Une fois par semaine, nous avons une tâche cron qui crée une copie de notre base de données de production (à l'aide d'instantanés matériels sur disque). Nous appelons cette copie de production notre « image dorée ». Cette image dorée est insérée dans notre base de données comme l'un de nos PDB. Le nom de l'APB est au format GOLDaaaa_mm_jj_hhmiss afin que nous sachions quand ce PDB a été créé.
Toutes nos bases de données de développement et de test sont ensuite créées à partir de cette image dorée PDB. Lorsque j'ai besoin d'actualiser DEV1 ou TEST, nous fermons simplement la PDB pour DEV1 ou TEST et la laissons tomber. Nous créons ensuite un clone instantané de la dernière image dorée. L'image dorée PDB est en mode LECTURE SEULE pour faciliter le clonage de l'instantané.
Comme je l'ai écrit ici, lorsqu'un PDB est utilisé comme source pour un clone d'instantané, Oracle changera les autorisations de fichier à 220. C'est Oracle qui nous protège de nous-mêmes. Nous ne devrions pas être autorisés à modifier la source d'un clone d'instantané afin qu'Oracle rende les fichiers de données en lecture seule. Quiconque chez Oracle qui a décidé de changer les autorisations de fichiers était une bonne idée n'en a pas parlé avec les développeurs de datapatch.
Datapatch voit le PDB READ ONLY et veut l'ouvrir en READ WRITE, patcher l'intérieur du PDB, puis le remettre en READ ONLY. Cependant, datapatch ne peut pas ouvrir la PDB en mode lecture-écriture car les autorisations de fichier ne le permettent pas. D'où les erreurs que je reçois.
Oracle m'a fait ça… ils ont forcé les autorisations de fichiers dans un sens, puis datapatch ne peut pas faire ce qu'ils veulent maintenant.
Je n'ai pas encore reçu de message officiel avec ma demande de service, mais je m'attends à ce que cela devienne un bogue. Datapatch devrait ignorer tous les PDB qui sont des sources de clones d'instantanés, à mon avis.
En attendant, vous pouvez forcer brutalement votre chemin à travers cela. J'ai essayé d'utiliser le paramètre -exclude_pdbs pour datapatch mais cela n'a pas fonctionné. Apparemment, il existe un bogue connu dans lequel ce paramètre ne fonctionne pas si votre liste de PDB contient une virgule. J'ai donc dû exécuter le patch de données comme suit :\
./datapatch -verbose -pdbs cdb\$root
./datapatch -verbose -pdbs pdb\$graine
./datapatch -verbose -pdbs dev1,dev2
Tout d'abord, j'ai exécuté datapatch pour patcher CDB$ROOT. Ensuite, j'ai patché PDB$SEED. Ensuite, j'ai corrigé mes PDB de développement. Je n'ai tout simplement pas corrigé mes PDB d'image dorée.