Problèmes connus

Bases de données enfichables existantes dans une nouvelle base de données

Détails

Les bases de données enfichables existantes n'apparaissent pas dans une nouvelle base de données et il peut falloir plusieurs heures avant qu'elles apparaissent dans la console OCI. Cela concerne la base de données enfichable par défaut pour une nouvelle base de données et les bases de données enfichables existantes pour les bases clonées ou restaurées. En cas de restauration sur place d'une version plus ancienne, la liste de bases de données enfichables est mise à jour de la même manière et cela peut prendre un certain temps.

Solution de rechange

Aucune.

Base de données enfichable dans une configuration de Data Guard existante

Détails

La création et le clonage d'une base de données enfichable dans la base de données principale ne sont pas autorisés au moyen de la console OCI ou de l'API.

Solution de rechange

Vous pouvez utiliser SQL*Plus pour créer ou cloner des bases de données enfichables dans la base principale et elles seront synchronisées plus tard dans la console OCI.

Problème de facturation lors de la modification du type de licence

Détails

Lorsque vous changez le type de licence de votre base de données ou de votre système de base de données de BYOL à Licence incluse, ou l'inverse, vous êtes facturé pour les deux types de licence pour la première heure. Vous êtes ensuite facturé en fonction du nouveau type de licence.

Solution de rechange

Nous travaillons à une résolution.

Échec de la sauvegarde dans le service de stockage d'objets à l'aide de dbcli en raison de la modification des certificats

Détails

Les sauvegardes non gérées dans le service de stockage d'objets à l'aide de dbcli (interface de ligne de commande de base de données) ont échoué avec les erreurs suivantes :

-> Oracle Error Codes found:
-> ORA-19554: error allocating device, device type: SBT_TAPE, device name:
-> ORA-19511: non RMAN, but media manager or vendor specific failure, error text:
-> KBHS-00712: ORA-29024 received from local HTTP service
-> ORA-27023: skgfqsbi: media manager protocol error

En réponse aux politiques mises en oeuvre par deux navigateurs Web courants concernant les certificats Symantec, Oracle a récemment modifié l'autorité de certification utilisée pour Oracle Cloud Infrastructure. La modification des certificats SSL qui en résulte peut entraîner l'échec des sauvegardes dans le service de stockage d'objets si le module Oracle Database Cloud Backup pointe toujours vers l'ancien certificat.

Solution de rechange

Recherchez dans les fichiers journaux les erreurs répertoriées et, si nécessaire, mettez à jour le module de sauvegarde.

Recherchez les erreurs répertoriées ci-dessus dans les fichiers journaux de sauvegarde RMAN :

Exécutez la commande suivante pour déterminer l'ID de la tâche de sauvegarde ayant échoué.

dbcli list-jobs

Dans cet exemple de sortie, l'ID tâche de la sauvegarde ayant échoué est "f59d8470-6c37-49e4-a372-4788c984ea59".

root@<node name> ~]# dbcli list-jobs
 
ID                                       Description                                                                     Created                             Status
---------------------------------------- ------------------------------------------------------------------------------- ----------------------------------- ----------
cbe852de-c0f3-4807-85e8-7523647ec78c     Authentication key update for DCS_ADMIN                                         March 30, 2018 4:10:21 AM UTC       Success
db83fdc4-5245-4307-88a7-178f8a0efa48     Provisioning service creation                                                   March 30, 2018 4:12:01 AM UTC       Success
c1511a7a-3c2e-4e42-9520-f156b1b4cf0e     SSH keys update                                                                 March 30, 2018 4:48:24 AM UTC       Success
22adf146-9779-4a2c-8682-7fd04d7520b2     SSH key delete                                                                  March 30, 2018 4:50:02 AM UTC       Success
6f2be750-9823-4ed5-b5ff-8e49f136dd22     create object store:bV0wqIaoLA4xLT4dGjOu                                        March 30, 2018 5:33:38 AM UTC       Success
0716f464-1a10-40df-a303-cadee0302b1b     create backup config:bV0wqIaoLA4xLT4dGjOu_BC                                    March 30, 2018 5:33:49 AM UTC       Success
e08b21c3-cd09-4e3a-944c-d1da96cb21d8     update database : hfdb1                                                         March 30, 2018 5:34:04 AM UTC       Success
1c3d7c58-79c3-4039-8f48-787057ce7c6e     Create Longterm Backup with TAG-DBTLongterm<identity number> for Db:<dbname>    March 30, 2018 5:37:11 AM UTC       Success
f59d8470-6c37-49e4-a372-4788c984ea59     Create Longterm Backup with TAG-DBTLongterm<identity number> for Db:<dbname>    March 30, 2018 5:43:45 AM UTC       Failure

Utilisez l'ID de la tâche ayant échoué pour obtenir l'emplacement du fichier journal à vérifier.

dbcli describe-job -i <failed_job_ID>

La commande describe-job devrait générer une sortie semblable à ce qui suit:

Message: DCS-10001:Internal error encountered: Failed to run Rman statement.
Refer log in Node <node_name>: /opt/oracle/dcs/log/<node_name>/rman/bkup/<db_unique_name>/rman_backup/<date>/rman_backup_<date>.log.

Mettre à jour le module Oracle Database Cloud Backup :
1. Déterminez l'ID magasin d'objets Swift et l'utilisateur que la base de données utilise pour les sauvegardes.
  1. Exécutez la commande dbcli list-databases pour déterminer l'ID base de données.
  2. Utilisez l'ID base de données pour déterminer l'ID configuration de sauvegarde (backupConfigId).
```
dbcli list-databases
dbcli describe-database -i <database_ID> -j
```
  3. À l'aide de l'ID configuration de sauvegarde que vous avez noté à l'étape précédente, déterminez l'ID magasin d'objets (objectStoreId).
```
dbcli list-backupconfigs
dbcli describe-backupconfig –i <backupconfig_ID> -j
```
  4. À l'aide de l'ID magasin d'objets que vous avez noté à l'étape précédente, déterminez l'utilisateur du magasin d'objets (userName).
```
dbcli list-objectstoreswifts
dbcli describe-objectstoreswift –i <objectstore_ID> -j
```
2. À l'aide des données d'identification de magasin d'objets obtenues à l'étape 1, mettez à jour le module de sauvegarde.
```
dbcli update-objectstoreswift –i <objectstore_ID> -p –u <user_name>
```

Échec de la sauvegarde dans le service de stockage d'objets à l'aide de RMAN en raison de la modification des certificats

Détails

Les sauvegardes non gérées dans le service de stockage d'objets à l'aide de RMAN ont échoué avec les erreurs suivantes :

-> Oracle Error Codes found:
-> ORA-19554: error allocating device, device type: SBT_TAPE, device name:
-> ORA-19511: non RMAN, but media manager or vendor specific failure, error text:
-> KBHS-00712: ORA-29024 received from local HTTP service
-> ORA-27023: skgfqsbi: media manager protocol error

En réponse aux politiques mises en oeuvre par deux navigateurs Web courants concernant les certificats Symantec, Oracle a récemment modifié l'autorité de certification utilisée pour Oracle Cloud Infrastructure. La modification des certificats SSL qui en résulte peut entraîner l'échec des sauvegardes dans le service de stockage d'objets si le module Oracle Database Cloud Backup pointe toujours vers l'ancien certificat.

Solution de rechange

Vérifiez si les fichiers journaux RMAN contiennent les messages d'erreur répertoriés. Si tel est le cas, connectez-vous à l'hôte en tant qu'utilisateur oracle et servez-vous de vos données d'identification Swift pour réinstaller le module de sauvegarde.

Note :

Les mots de passe Swift sont maintenant appelés "jetons d'authentification". Pour plus d'informations, voir Gestion des données d'identification d'utilisateur.

java -jar <opc_install.jar_path> -opcId '<swift_user_ID>' -opcPass '<auth_token>' -container <objectstore_container> -walletDir <wallet_directory> -configfile <config_file> -host https://swiftobjectstorage.<region_name>.oraclecloud.com/v1/<object_storage_namespace> -import-all-trustcerts

Pour un système de base de données à plusieurs noeuds, appliquez la solution de rechange sur tous les noeuds de la grappe.

Pour plus d'informations sur le module Oracle Database Cloud Backup, voir Utilisation d'Oracle Database Backup Cloud Service.

Changements cassants dans les SDK de service de base de données

Détails

Les trousses SDK lancées le 18 octobre 2018 apportent des modifications cassantes à la taille et aux attributs d'édition de base de données dans les API de sauvegarde.

Solution de rechange

Consultez la documentation spécifique à la langue pour plus d'informations sur les changements cassants et mettez à jour votre code existant selon les besoins.

Impossible d'utiliser des sauvegardes gérées dans le système de base de données

Détails

Les opérations de sauvegarde et de restauration peuvent échouer dans le système de base de données lorsque vous utilisez la console OCI ou l'API.

Solution de rechange

Installer le module Oracle Database Cloud Backup, puis contacter Oracle Support Services pour obtenir de plus amples instructions.

Pour installer le module Oracle Database Cloud Backup, procédez comme suit :

Accédez par SSH au système de base de données et connectez-vous en tant qu'opc.
```
ssh -i <SSH_key> opc@<DB_system_IP address>
login as: opc
```
Vous pouvez également utiliser opc@<DB_system_hostname> pour vous connecter.
Télécharger le module Oracle Database Cloud Backup à partir du module Oracle Database Cloud Backup.
Extrayez le contenu de opc_installer.zip dans un répertoire cible; par exemple, /home/opc.
Dans votre location, créez un utilisateur temporaire et accordez-lui les privilèges nécessaires pour accéder au stockage d'objets de la location.
Pour cet utilisateur temporaire, créez un jeton d'authentification et notez le mot de passe. Pour plus d'informations sur la création du jeton d'authentification, voir Gestion des données d'identification d'utilisateur.

Note :
Les mots de passe Swift sont maintenant appelés "jetons d'authentification".
Vérifiez que les données d'identification fonctionnent en exécutant la commande curl suivante :
```
curl -v -X HEAD -u  <user_id>:'<auth_token>' https://swiftobjectstorage.<region_name>.oraclecloud.com/v1/<object_storage_namespace>
```
Pour déterminer la bonne région, voir Service de stockage d'objets - FAQ.

La commande doit retourner le code de réponse de succès HTTP 200 ou HTTP 204 No Content. Tout autre code de statut indique un problème de connexion au service de stockage d'objets.
Exécutez la commande suivante :
```
java -jar opc_install.jar -opcid <user_id> -opcPass '<auth_token>' -libDir <target_dir> -walletDir <target_dir> -host https://swiftobjectstorage.<region_name>.oraclecloud.com/v1/<object_storage_namespace> -configFile config.txt
```
Notez que <target_dir> est le répertoire où vous avez extrait opc_installer.zip à l'étape 3.

Cette commande peut prendre quelques minutes, car elle télécharge libopc.so et d'autres fichiers. Une fois la commande terminée, vous devriez voir plusieurs fichiers (dont libopc.so) dans votre répertoire cible.
Passez dans le répertoire cible et copiez les fichiers lipopc.so et opc_install.jar dans le répertoire /opt/oracle/oak/pkgrepos/oss/odbcs.
```
cp libopc.so /opt/oracle/oak/pkgrepos/oss/odbcs
```
```
cp opc_install.jar /opt/oracle/oak/pkgrepos/oss/odbcs
```
(Vous devrez peut-être utiliser sudo avec les commandes de copie pour les exécuter en tant que root.)
Exécutez la commande suivante pour vérifier si le répertoire indiqué existe :
```
ls /opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs
```
Si ce répertoire existe, procédez comme suit :
1. Sauvegardez les fichiers dans le répertoire /opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs.
2. Exécutez ces deux commandes pour remplacer les fichiers libopc.so et opc_install.jar de ce répertoire:
```
cp libopc.so /opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs 
cp opc_install.jar /opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs
```

Vérifiez la version de opc_install.jar.

java -jar /opt/oracle/oak/pkgrepos/oss/odbcs/opc_install.jar |grep -i build

Si /opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs existe, exécutez également la commande suivante :

java -jar /opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs/opc_install.jar |grep -i build

Les deux commandes doivent retourner la sortie suivante :

Oracle Database Cloud Backup Module Install Tool, build MAIN_2017-08-16.

(Facultatif) Supprimez l'utilisateur temporaire et le répertoire cible que vous avez utilisés pour installer le module de sauvegarde.

Après avoir terminé la procédure, communiquez avec le soutien technique Oracle ou avec l'administrateur du locataire pour obtenir des instructions supplémentaires. Vous devez fournir l'OCID du système de base de données pour lequel vous souhaitez activer les sauvegardes.

Échec des sauvegardes automatiques gérées sur la forme VM.Standard1.1 en raison d'une panne de processus

Détails

Les limites de mémoire des machines hôte exécutant la forme VM.Standard1.1 peuvent causer des échecs pour les tâches de sauvegarde automatique de base de données gérées par Oracle Cloud Infrastructure (tâches gérées à l'aide de la console OCI ou de l'API). Vous pouvez modifier les paramètres de mémoire du système pour résoudre ce problème.

Solution de rechange

Modifiez les paramètres de mémoire des systèmes de la manière suivante :

Passez à l'utilisateur oracle dans le système d'exploitation.
```
[opc@hostname ~]$ sudo su - oracle
```
Réglez la variable d'environnement pour vous connecter à l'instance de base de données. Par exemple :
```
oracle@hostname ~]$ . oraenv 
ORACLE_SID = [oracle] ? orcl
```

Démarrez SQL*Plus.

[oracle@hostname ~]$ sqlplus / as sysdba

Modifiez les paramètres initiaux de mémoire de la manière suivante :

SQL> ALTER SYSTEM SET SGA_TARGET = 1228M scope=spfile; 
SQL> ALTER SYSTEM SET PGA_AGGREGATE_TARGET = 1228M; 
SQL> ALTER SYSTEM SET PGA_AGGREGATE_LIMIT = 2457M; 
SQL> exit

Redémarrez l'instance de base de données.

[oracle@hostname ~]$ srvctl stop database -d db_unique_name -o immediate 
[oracle@hostname ~]$ srvctl start database -d db_unique_name -o open

Les opérations Oracle Data Pump retournent " ORA-00439 : Fonctionnalité non activée "

Détails

Dans les systèmes de base de données High Performance et Extreme Performance, les opérations de l'utilitaire Data Pump qui utilisent la compression et/ou le parallélisme peuvent échouer et retourner l'erreur ORA-00439 : Fonctionnalité non activée. Ce problème affecte les versions de base de données 12.1.0.2.161018 et 12.1.0.2.170117.

Solution de rechange

Appliquez le correctif 25579568 ou 25891266 aux répertoires de base Oracle Database pour les versions 12.1.0.2.161018 ou 12.1.0.2.170117, respectivement. Sinon, utilisez la console OCI pour appliquer le correctif d'avril 2017 au système de base de données et au répertoire de base.

Note :

Pour déterminer la version d'une base de données dans un répertoire de base, exécutez $ORACLE_HOME/OPatch/opatch lspatches en tant qu'utilisateur oracle ou dbcli list-dbhomes en tant qu'utilisateur racine.

Impossible de se connecter à la console EM Express à partir de votre système de base de données à 1 noeud

Détails

Vous pourriez obtenir un message d'erreur "Secure Connection Failed" (Échec de la connexion sécurisée) lorsque vous tentez de vous connecter à la console EM Express à partir de votre système de base de données à 1 noeud, car les autorisations appropriées n'ont pas été appliquées automatiquement.

Solution de rechange

Ajoutez des autorisations en lecture pour le groupe asmadmin dans le répertoire du portefeuille du système de base de données, puis réessayez la connexion. Effectuez les étapes suivantes pour ajouter des autorisations de lecture.

Accédez par SSH à l'hôte du système de base de données, connectez-vous en tant qu'opc et sudo à l'utilisateur grid.

[opc@dbsysHost ~]$ sudo su - grid
[grid@dbsysHost ~]$ . oraenv
ORACLE_SID = [+ASM1] ?
The Oracle base has been set to /u01/app/grid

Obtenez l'emplacement du répertoire wallet. Il s'agit de la valeur de my_wallet_directory dans la sortie de commande suivante.

[grid@dbsysHost ~]$ lsnrctl status | grep xdb_wallet

(DESCRIPTION=(ADDRESS=(PROTOCOL=tcps)(HOST=dbsysHost.sub04061528182.dbsysapril6.oraclevcn.com)(PORT=5500))(Security=(my_wallet_directory=/u01/app/oracle/admin/dbsys12_phx3wm/xdb_wallet))(Presentation=HTTP)(Session=RAW))

Retournez à l'utilisateur opc, passez à l'utilisateur oracle, puis accédez au répertoire wallet.

[opc@dbsysHost ~]$ sudo su - oracle
[oracle@dbsysHost ~]$ cd /u01/app/oracle/admin/dbsys12_phx3wm/xdb_wallet

Affichez le contenu du répertoire et prenez note des autorisations.

[oracle@dbsysHost xdb_wallet]$ ls -ltr
total 8
-rw------- 1 oracle asmadmin 3881 Apr  6 16:32 ewallet.p12
-rw------- 1 oracle asmadmin 3926 Apr  6 16:32 cwallet.sso

Modifiez les autorisations .

[oracle@dbsysHost xdb_wallet]$ chmod 640 /u01/app/oracle/admin/dbsys12_phx3wm/xdb_wallet/*

Vérifiez que les autorisations de lecture ont été ajoutées.

[oracle@dbsysHost xdb_wallet]$ ls -ltr
total 8
-rw-r----- 1 oracle asmadmin 3881 Apr  6 16:32 ewallet.p12
-rw-r----- 1 oracle asmadmin 3926 Apr  6 16:32 cwallet.sso

Les informations de la console OCI ne sont pas synchronisées pour les bases de données où Data Guard est activé lors de l'utilisation de dbaascli

Détails

La console OCI synchronise et affiche des informations sur les bases de données créées et gérées à l'aide des utilitaires dbaasapi et dbaascli. Toutefois, les bases de données où Data Guard est configuré n'affichent pas des informations correctes dans la console OCI dans les cas suivants :

Si Data Guard a été activé à l'aide de la console OCI, puis qu'une modification a été apportée à la base de données principale ou de secours à l'aide de dbaascli (par exemple, le déplacement de la base de données dans un autre répertoire de base), le résultat n'est pas reflété dans la console OCI.
Si Data Guard a été configuré manuellement, la console OCI n'affiche pas l'association Data Guard entre les deux bases de données.

Solution de rechange

Nous sommes conscients du problème et travaillons à le résoudre. Dans l'intervalle, Oracle recommande de gérer les bases de données où Data Guard est activé en utilisant uniquement la console OCI ou les utilitaires de ligne de commande.

Grid Infrastructure ne démarre pas après la mise hors ligne et en ligne d'un disque

Détails

Il s'agit d'un problème de clusterware qui se produit uniquement avec la version 12.2.0.1 d'Oracle Grid Infrastructure (GI) sans aucun correctif d'ensemble. Le problème est dû à un disque votant corrompu après sa mise hors ligne puis en ligne.

Solution de rechange

Déterminez la version de GI et vérifiez si le disque votant est corrompu. Au besoin, réparez le disque, puis appliquez le dernier ensemble GI.

Effectuez les étapes suivantes :

Vérifiez que la version de GI est 12.2.0.1 sans aucun correctif d'ensemble :

[root@rmstest-udaau1 ~]# su - grid
[grid@rmstest-udaau1 ~]$ . oraenv
ORACLE_SID = [+ASM1] ? +ASM1
The Oracle base has been set to /u01/app/grid
[grid@rmstest-udaau1 ~]$ $ORACLE_HOME/OPatch/opatch lsinventory
Oracle Interim Patch Installer version 12.2.0.1.6
Copyright (c) 2018, Oracle Corporation.  All rights reserved.

Oracle Home       : /u01/app/12.2.0.1/grid
Central Inventory : /u01/app/oraInventory
   from           : /u01/app/12.2.0.1/grid/oraInst.loc
OPatch version    : 12.2.0.1.6
OUI version       : 12.2.0.1.4
Log file location : /u01/app/12.2.0.1/grid/cfgtoollogs/opatch/opatch2018-01-15_22-11-10PM_1.log

Lsinventory Output file location : /u01/app/12.2.0.1/grid/cfgtoollogs/opatch/lsinv/lsinventory2018-01-15_22-11-10PM.txt

--------------------------------------------------------------------------------
Local Machine Information::
Hostname: rmstest-udaau1.exaagclient.sretest.oraclevcn.com
ARU platform id: 226
ARU platform description:: Linux x86-64

Installed Top-level Products (1):

Oracle Grid Infrastructure 12c                                       12.2.0.1.0
There are 1 products installed in this Oracle Home.

There are no Interim patches installed in this Oracle Home.

--------------------------------------------------------------------------------

OPatch succeeded.

Recherchez dans le fichier /u01/app/grid/diag/crs/<hostname>/crs/trace/ocssd.trc des éléments prouvant que le démarrage de GI a échoué en raison d'un disque votant corrompu :

ocssd.trc
 
2017-01-17 23:45:11.955 :    CSSD:3807860480: clssnmvDiskCheck:: configured 
Sites = 1, Incative sites = 1, Mininum Sites required = 1 
2017-01-17 23:45:11.955 :    CSSD:3807860480: (:CSSNM00018:)clssnmvDiskCheck: 
Aborting, 2 of 5 configured voting disks available, need 3 
...... 
. 
2017-01-17 23:45:11.956 :    CSSD:3807860480: clssnmCheckForNetworkFailure: 
skipping 31 defined 0 
2017-01-17 23:45:11.956 :    CSSD:3807860480: clssnmRemoveNodeInTerm: node 4, 
slcc05db08 terminated. Removing from its own member and connected bitmaps 
2017-01-17 23:45:11.956 :    CSSD:3807860480: 
################################### 
2017-01-17 23:45:11.956 :    CSSD:3807860480: clssscExit: CSSD aborting from 
thread clssnmvDiskPingMonitorThread 
2017-01-17 23:45:11.956 :    CSSD:3807860480: 
################################### 
2017-01-17 23:45:11.956 :    CSSD:3807860480: (:CSSSC00012:)clssscExit: A 
fatal error occurred and the CSS daemon is terminating abnormally 
 
------------
 
2017-01-19 19:00:32.689 :    CSSD:3469420288: clssnmFindVF: Duplicate voting disk found in the queue of previously configured disks 
queued(o/192.168.10.18/PCW_CD_02_slcc05cel10|[66223efc-29254fbb-bf901601-21009 
cbd]), 
found(o/192.168.10.18/PCW_CD_02_slcc05cel10|[66223efc-29254fbb-bf901601-21009c 
bd]), is not corrupted 
2017-01-19 19:01:06.467 :    CSSD:3452057344: clssnmvVoteDiskValidation: 
Voting disk(o/192.168.10.19/PCW_CD_02_slcc05cel11) is corrupted

Vous pouvez également utiliser SQL*Plus pour vérifier si les disques votants sont corrompus :

Connectez-vous en tant qu'utilisateur de grille et définissez l'environnement sur ASM.

[root@rmstest-udaau1 ~]# su - grid
[grid@rmstest-udaau1 ~]$ . oraenv
ORACLE_SID = [+ASM1] ? +ASM1
The Oracle base has been set to /u01/app/grid

Connectez-vous à SQL*Plus en tant que SYSASM.
```
$ORACLE_HOME/bin/sqlplus / as sysasm
```

Exécutez les deux interrogations suivantes :

SQL> select name, voting_file from v$asm_disk where VOTING_FILE='Y' and group_number !=0;
SQL> select  CC.name, count(*) from x$kfdat AA JOIN (select disk_number, name from v$asm_disk where VOTING_FILE='Y' and group_number !=0) CC ON CC.disk_number = AA.NUMBER_KFDAT where AA.FNUM_KFDAT= 1048572 group by CC.name;

Si le système est sain, les résultats devraient ressembler à l'exemple suivant.

Query 1 Results
NAME                           VOTING_FILE
------------------------------ ---------------
DBFSC3_CD_02_SLCLCX0788        Y
DBFSC3_CD_09_SLCLCX0787        Y
DBFSC3_CD_04_SLCLCX0786        Y

Query 2 Results
NAME                           COUNT(*)
------------------------------ ---------------
DBFSC3_CD_02_SLCLCX0788        8
DBFSC3_CD_09_SLCLCX0787        8
DBFSC3_CD_04_SLCLCX0786        8

Dans un système sain, chaque disque votant retourné dans la première interrogation doit également figurer dans la deuxième et le total des disques doit être différent de zéro. Sinon, au moins un des disques votant" est corrompu.

Si un disque votant est corrompu, mettez hors ligne le disque de grille qui le contient. Les cellules vont automatiquement déplacer le disque votant incorrect vers l'autre disque de grille et mettre en ligne ce disque votant.
1. La commande suivante met hors ligne d'un disque de grille nommé DATAC01_CD_05_SCAQAE08CELADM13.
```
SQL> alter diskgroup DATAC01 offline disk DATAC01_CD_05_SCAQAE08CELADM13;
     Diskgroup altered.
```
2. Attendez 30 secondes, puis réexécutez les deux interrogations de l'étape 3c pour vérifier que le disque votant a été migré vers le nouveau disque de grille et qu'il est sain.
3. Vérifiez que le disque de grille précédemment mis hors ligne est maintenant en ligne :
```
SQL> select name, mode_status, voting_file from v$asm_disk where name='DATAC01_CD_05_SCAQAE08CELADM13';
```
  mode_status doit avoir la valeur ONLINE et voting_file NE doit PAS avoir la valeur Y (Oui).
Répétez les étapes 4a à 4c pour chaque disque de grille restant qui contient un disque votant corrompu.
Note :

Si CRS ne démarre pas en raison du disque votant corrompu, utilisez le mode exclusif avant d'exécuter la commande de l'étape 4.
```
crsctl start crs -excl
```
Si vous utilisez Oracle GI version 12.2.0.1 sans correctif d'ensemble, vous devez mettre à niveau à la dernière version de l'ensemble GI, qu'un disque votant soit corrompu ou non.

Échec de l'ajustement du stockage du système de base de données

Détails

La tentative d'ajustement d'une valeur inférieure à 10 240 Go à une valeur supérieure à 10 240 Go en une seule fois peut échouer.

Solution de rechange

Si vous ajustez le stockage de données standard ou le stockage de la zone de récupération (RECO) d'une valeur inférieure à 10 240 Go (10 To) à une valeur supérieure à 10 240 Go, effectuez l'ajustement en deux opérations. Tout d'abord, ajustez le système à 10 240 Go. Une fois cette première opération d'ajustement terminée, lorsque le système est à l'état "Disponible", effectuez une seconde opération d'ajustement en spécifiant la valeur de stockage cible supérieure à 10 240 Go.

Échec de l'ajustement de la forme du système de base de données

Détails

Lors de l'ajustement d'un système de base de données pour l'utilisation d'une forme de système plus grande, l'opération d'ajustement échoue si un paramètre DB_Cache_nX n'est pas réglé à 0 (zero).

Solution de rechange

Lors de l'ajustement d'un système de base de données, assurez-vous que tous les paramètres DB_Cache_nX (par exemple, DB_nK_CACHE_SIZE) sont réglés à 0 (zéro).