Problèmes connus

Cet article fournit des informations sur les problèmes connus dans le service Base Database.

Les problèmes recensés suivants sont identifiés dans Base Database Service :

Rubriques connexes

Bases de données pluggables existantes dans la nouvelle base de données

Détails

Les bases de données pluggable existantes n'apparaissent pas dans les nouvelles bases de données. Il peut s'écouler avant qu'elles n'apparaissent dans la console OCI. Cela inclut la base de données pluggable par défaut pour une nouvelle base de données et les bases de données pluggables existantes pour les bases de données clonées ou restaurées. Dans le cas d'une restauration dynamique vers une version antérieure, la liste des bases de données pluggables est mise à jour de la même manière et peut nécessiter un petit délai.

Solution de contournement

Aucun.

Base de données pluggable dans la configuration Data Guard existante

Détails

La création et la clonage d'une base de donnée pluggable dans la base de données principale ne sont pas autorisés via l'API ou la console OCI.

Solution de contournement

Vous pouvez utiliser SQL*Plus pour créer ou cloner des PDB dans la base de donnée principale. Elles seront synchronisées ultérieurement dans la Console OCI.

Problème de facturation lors de l'évolution du type de licence

Détails

Lorsque vous passez d'une licence de type BYOL à une licence incluse ou inversement, vous êtes facturé pour les deux types de licence à la première heure. Vous êtes ensuite facturé pour le type de licence mis à jour.

Solution de contournement

Nous travaillons à une résolution.

Echec de la sauvegarde vers Object Storage à l'Aide de dbcli en raison d'une modification de certificat

Détails

Les sauvegardes non gérées vers Object Storage à l'aide de l'interface de ligne de commande de base de données (dbcli) échouent 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 stratégies implémentées par deux navigateurs Web courants concernant les certificats Symantec, Oracle a récemment modifié l'autorité de certificat utilisée pour Oracle Cloud Infrastructure. La modification apportée aux certificats SSL peut entraîner l'échec des sauvegardes vers Object Storage si le module Oracle Database Cloud Backup pointe encore vers l'ancien certificat.

Solution de contournement

Dans les fichiers journaux, recherchez les erreurs répertoriées ; si elles s'Y trouvent, mettez à jour le module de sauvegarde.

  1. Consultez les fichiers journaux de sauvegarde RMAN pour rechercher les erreurs répertoriées ci-dessus :

    1. Exécutez la commande suivante pour déterminer l'ID du travail de sauvegarde ayant échoué.

      dbcli list-jobs

      Dans cet exemple de sortie, l'ID du travail de 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

    2. Utilisez l'ID du travail ayant échoué pour obtenir l'emplacement du fichier journal à consulter.

      dbcli describe-job -i <failed_job_ID>

      La commande describe-job renvoie une sortie de ce type : 

      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.

  2. Update the Oracle Database Cloud Backup Module:

    1. Déterminez l'utilisateur et l'ID de banque d'objets Swift que la base de données utilise pour les sauvegardes.

      1. Exécutez la commande dbcli list-databases pour déterminer l'ID de la base de données.

      2. Utilisez l'ID de la base de données pour déterminer l'ID de configuration de sauvegarde (backupConfigId). 

        dbcli list-databases
dbcli describe-database -i <database_ID> -j

      3. A l'aide de l'ID de configuration de sauvegarde que vous avez noté à l'étape précédente, déterminez l'ID de banque d'objets (objectStoreId). 

        dbcli list-backupconfigs
dbcli describe-backupconfig –i <backupconfig_ID> -j

      4. A l'aide de l'ID de banque d'objets que vous avez noté à l'étape précédente, déterminez l'utilisateur de banque d'objets (userName). 

        dbcli list-objectstoreswifts
dbcli describe-objectstoreswift –i <objectstore_ID> -j

    2. Mettez à jour le module de sauvegarde à l'aide des informations d'identification de banque d'objets obtenues au cours de l'étape 1.

      dbcli update-objectstoreswift –i <objectstore_ID> -p –u <user_name>

Echec de la sauvegarde vers Object Storage à l'assistance de RMAN en raison d'une modification de certificat

Détails

Echec des sauvegardes non gérées vers Object Storage à l'aide de RMAN, 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 stratégies implémentées par deux navigateurs Web courants concernant les certificats Symantec, Oracle a récemment modifié l'autorité de certificat utilisée pour Oracle Cloud Infrastructure. La modification apportée aux certificats SSL peut entraîner l'échec des sauvegardes vers Object Storage si le module Oracle Database Cloud Backup pointe encore vers l'ancien certificat.

Solution de contournement

Vérifiez les messages d'erreur répertoriés dans les fichiers journaux RMAN. S'ils s'y trouvent, connectez-vous à l'hôte en tant qu'utilisateur oracle et utilisez les informations d'identification Swift pour réinstaller le module de sauvegarde.

Remarques :

Les mots de passe Swift sont désormais appelés "jetons d'authentification". Pour plus d'informations, reportez-vous à Gestion des informations d'identification 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 contournement à tous les noeuds du cluster.

Pour plus d'informations sur le module Oracle Database Cloud Backup, reportez-vous à Utilisation d'Oracle Database Backup Cloud Service.

Modifications des ruptures du code dans les kits SDK du service Database

Détails

Les kits SDK publiés le 18 octobre 2018 introduisent des modifications de ruptures de code dans la taille et les attributs de l'édition de base de donnée dans les API de sauvegarde de base de donnée.

Solution de contournement

Pour plus d'informations sur les modifications de rupture, reportez-vous à la documentation propre aux différentes langages et mettez à jour votre code existant si nécessaire.

Impossible d'utiliser des sauvegardes gérées dans le serveur de base de données

Détails

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

Solution de contournement

Installez le module Oracle Database Cloud Backup, puis contactez Oracle Support Services pour obtenir des instructions supplémentaires.

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

  1. Connectez-vous au système de base de données via SSH et connectez-vous en tant que opc. 

    ssh -i <SSH_key> opc@<DB_system_IP address>
login as: opc

    Vous pouvez également utiliser opc@<DB_system_hostname> pour vous connecter.

  2. Téléchargez le module d'Oracle Database Cloud Backup à partir du module Oracle Database Cloud Backup.
  3. Extrayez le contenu de opc_installer.zip dans un répertoire cible, par exemple, /home/opc.
  4. Dans votre location, créez un utilisateur temporaire et accordez-lui des privilèges permettant d'accéder à Object Storage de la location.
  5. Pour cet utilisateur temporaire, créez un jeton d'authentification et notez le mot de passe. Pour plus d'informations sur la création d'un jeton d'authentification, reportez-vous à Gestion des informations d'identification utilisateur.

    Remarques :

    Les mots de passe Swift sont désormais appelés "jetons d'authentification".

  6. Vérifiez que les informations 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 région appropriée, reportez-vous à FAQ Object Storage.

    La commande doit renvoyer le code HTTP 200 ou HTTP 204 No Content de réponse d'état de réussite. Tout autre code d'état indique un problème de connexion à Object Storage.

  7. 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

    <target_dir> est le répertoire dans lequel vous avez extrait opc_installer.zip au cours du cours de l'étape 3.

    L'exécution de cette commande peut prendre quelques minutes car elle télécharge libopc.so et d'autres fichiers. Une fois la commande exécutée, vous devez voir plusieurs fichiers (y compris libopc.so) dans votre répertoire cible.

  8. Accédez au 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 la commande de copie pour les exécuter en tant qu'utilisateur root.)

  9. 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 existants dans le répertoire : 

      cp libopc.so /opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs 
cp opc_install.jar /opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs

  10. Vérifiez la version du fichier 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 renvoyer la sortie suivante :

    Oracle Database Cloud Backup Module Install Tool, build MAIN_2017-08-16.
  11. (Facultatif) Supprimez l'utilisateur temporaire et le répertoire cible que vous avez utilisés pour installer le module de sauvegarde.

Une fois que vous avez terminé la procédure, contactez le support technique Oracle ou l'administrateur de locataires pour obtenir davantage d'instructions. Vous devez fournir l'OCID du système de base de données pour lequel activer les sauvegardes.

Echec 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 entraîner l'échec des travaux de sauvegarde de base de données automatique gérés par Oracle Cloud Infrastructure (travaux gérés à l'utilisation de la console ou de l'API OCI). Vous pouvez modifier les paramètres mémoire du système pour résoudre ce problème.

Solution de contournement

Modifiez les paramètres de mémoire d'un système comme suit :

  1. Passez à l'utilisateur oracle dans le système d'exploitation.

    [opc@hostname ~]$ sudo su - oracle

  2. Définissez la variable d'environnement pour la connexion à l'instance de base de données. Exemple :

    oracle@hostname ~]$ . oraenv 
ORACLE_SID = [oracle] ? orcl

  3. Lancez SQL*Plus.

    [oracle@hostname ~]$ sqlplus / as sysdba

  4. Modifiez les paramètres initiaux de mémoire comme suit :

    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

  5. 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 renvoient "ORA-00439 : feature not enabled" (fonction non activée)

Détails

Sur les systèmes de base de donnée High Performance et Extreme Performance, les opérations de l'interface Data Pump utilisant une compression et/ou un parallélisme peuvent échouer et renvoyer l'erreur ORA-00439 : fonctionnalité non activée. Ce problème concerne les versions de base de données 12.1.0.2.161018 et 12.1.0.2.170117.

Solution de contournement

Appliquez le patch 25579568 ou 25891266 aux répertoires de base d'Oracle Database pour la version 12.1.0.2.161018 ou 12.1.0.2.170117, respectivement. Vous pouvez également utiliser la console OCI pour appliquer le patch d'avril 2017 au répertoire de base et au système de base de données.

Remarques :

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

Connexion à la console EM Express impossible à partir du système de base de données à 1 noeud

Détails

Il se peut que le message d'erreur "Secure Connection Failed" s'affiche lorsque vous tentez d'établir une connexion à la console EM Express à partir du système d'exploitation à 1 noeud, car ces droits d'accès corrects n'ont pas été appliqués automatiquement.

Solution de contournement

Ajoutez des droits d'accès de lecture pour le groupe asmadmin sur le répertoire de portefeuille du système de base de données, puis réessayez de vous connecter. Pour ajouter des autorisations de lecture, procédez comme suit.

  1. Connectez-Vous via SSH à l'hôte de système de base de données, connectez-vous en tant qu'utilisateur 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

  2. 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))

  3. Revenez à l'utilisateur opc, passez à l'utilisateur oracle et passez dans le répertoire wallet. 

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

  4. Répertoriez le contenu du répertoire et notez les droits d'accès.

    [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

  5. Modifiez les droits d'accès .

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

  6. Vérifiez que des droits d'accès en lecture ont été ajoutés.

    [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ée sur lesquelles Data Guard est activé lorsque dbaascli est utilisé

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 pour lesquelles Data Guard a été configuré n'affichent pas l'information correcte dans la console OCI dans les conditions suivantes :

  • Si Data Guard a été activé à l'aide de la console OCI, et qu'une modification est apportée à la base de données principale ou de secours via dbaascli (par exemple, déplacement de la base de données vers un autre répertoire de bases), 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 d'association Data Guard entre les deux bases.

Solution de contournement

Nous avons connaissance du problème et travaillons à sa résolution. En attendant, Oracle vous recommande de gérer vos bases de données sur quelles Data Guard est activé en utilisant uniquement la console OCI ou uniquement des utilitaires de ligne de commande.

Grid Infrastructure ne démarre pas après avoir mis un disque hors ligne et mis en ligne

Détails

Il s'agit d'un problème de clusterware qui se produit uniquement lorsque la version Oracle Grid Infrastructure (GI) correspond à 12.2.0.1 sans package de patches. Ce problème est dû à l'endommagement d'un disque "votant" après l'avoir mis hors ligne, puis en ligne.

Solution de contournement

Déterminez la version de GI et si le disque "votant" est endommagé. Réparez le disque, si nécessaire, puis appliquez le dernier groupe GI.

Procédez comme suit :

  1. Vérifiez que la version de GI correspond à la version 12.2.0.1 sans package de patches appliqué :

    [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.

  2. Consultez le fichier /u01/app/grid/diag/crs/<hostname>/crs/trace/ocssd.trc pour savoir si l'échec de démarrage de GI est dû à l'endommagement d'un disque "votant" : 

    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

  3. Vous pouvez également utiliser SQL*Plus pour confirmer que les disques "votants" sont endommagés :

    1. Connectez-vous en tant qu'utilisateur grid 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

    2. Connectez-vous à SQL*Plus en tant qu'utilisateur SYSASM. 

      $ORACLE_HOME/bin/sqlplus / as sysasm

    3. Exécutez les deux requêtes 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 en bon état, les résultats doivent 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" renvoyé dans la première requête doit également être renvoyé dans la seconde, et le décompte pour tous les disques doit être différent de zéro. Sinon, des disques "votants" sont endommagés.

  4. Si un disque "votant" est endommagé, mettez hors ligne le disque grille le contenant. Les cellules déplacent automatiquement le disque "votant" endommagé vers l'autre disque grille et celui-ci en ligne.

    1. La commande suivante met hors ligne un disque grille nommé DATAC01_CD_05_SCAQAE08CELADM13.

      SQL> alter diskgroup DATAC01 offline disk DATAC01_CD_05_SCAQAE08CELADM13;
     Diskgroup altered.

    2. Patientez 30 secondes, puis réexécutez les deux requêtes de l'étape 3c pour vérifier que le disque "votant" a migré vers le nouveau disque grille et qu'il est en bon état.

    3. Vérifiez que le disque grille que vous avez 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 être ONLINE et voting_file NE doit PAS être Y (Oui).

    Répétez les étapes 4a à 4c pour chaque disque grille restant contenant un disque "votant" endommagé.

    Remarques :

    Si le CRS ne démarre pas en raison de l'endommagement du disque "votant", démarrez-le en mode exclusif avant d'exécuter la commande de l'étape 4.

    crsctl start crs -excl

  5. Si vous utilisez Oracle GI version 12.2.0.1 sans package de patches, vous devez mettre à niveau la version de GI vers le dernier groupe GI, qu'un disque "votant" soit endommagé ou non.

Echec du redimensionnement du stockage du système de base de données

Détails

Toute tentative de redimensionnement d'une valeur inférieure à 10 240 Go à une valeur supérieure à 10 240 Go en une seule opération peut entraîner l'échec de l'opération.

Solution de contournement

Si vous redimensionnez du stockage de données standard ou du stockage de zone de récupération (RECO) d'une valeur inférieure à 10 240 Go (10 To) à une valeur supérieure à 10 240 Go, effectuez le redimensionnement en deux opérations. Tout d'abord, redimensionnez le système à 10 240 Go. Une fois que cette première opération de redimensionnement est terminée et que le système présente l'état Disponible, effectuez une seconde opération de redimensionnement, en indiquant une valeur de stockage cible supérieure à 10 240 Go.

Echec du redimensionnement de forme de système de base de données

Détails

Lorsque vous redimensionnez un système de base de données pour qu'il utilise une forme plus grande, l'opération de redimensionnement échoue si un paramètre DB_Cache_nX n'est pas défini sur 0 (zéro).

Solution de contournement

Lors du redimensionnement 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 définis sur 0 (zéro).