Bekannte Probleme

Dieser Artikel enthält Informationen zu bekannten Problemen im Base Database-Service.

Die folgenden bekannten Probleme werden im Base Database Service identifiziert:

Verwandte Themen

Vorhandene integrierbare Datenbanken in neuer Datenbank

Details

Vorhandene integrierbare Datenbanken (PDB) werden in einer neu erstellten Datenbank nicht angezeigt. Sie können ein paar Stunden dauern, bis sie in der OCI-Konsole angezeigt werden. Dazu gehören die Standard-PDB für eine neue Datenbank und vorhandene PDBs für geklonte oder wiederhergestellte Datenbanken. Bei einer In-Place-Wiederherstellung einer älteren Version wird die PDB-Liste ähnlich aktualisiert, und es können Verzögerungen auftreten.

Workaround

Kein Wert.

PDB in vorhandener Data Guard-Konfiguration

Details

Das Erstellen und Klonen einer PDB in der primären Datenbank ist nicht über die OCI-Konsole oder die API zulässig.

Workaround

Mit SQL*Plus können Sie PDBs in die Primärdatenbank erstellen oder klonen. Die PDBs werden später in die OCI-Konsole synchronisiert.

Abrechnungsproblem bei Änderung des Lizenztyps

Details

Wenn Sie den Lizenztyp von Datenbank oder DB-System von "BYOL" in "Lizenz inklusive" oder umgekehrt ändern, werden beide Lizenztyptypen für die erste Stunde In Rechnung gestellt. Danach wird entsprechend Ihrem aktualisierten Lizenztyp abgerechnet.

Workaround

Eine Lösung für dieses Problem ist in Arbeit.

Backup in Object Storage mit dbcli verläuft wegen Zertifikatsänderung nicht erfolgreich

Details

Nicht verwaltete Backups in Object Storage über die Datenbank-CLI (dbcli) verlaufen mit den folgenden Fehlern nicht erfolgreiche:

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

Aufgrund der von zwei gängigen Webbrowsern in Bezug auf Symantec-Zertifikate implementierten Policys hat Oracle vor Kurzem die für Oracle Cloud Infrastructure verwendete Certificate Authority geändert. Die daraus resultierende Änderung der SSL-Zertifikate kann dazu führen, dass Backups in Object Storage nicht erfolgreich ausgeführt werden, wenn das Oracle Database Cloud Backup-Modul weiterhin auf das alte Zertifikat verweist.

Workaround

Prüfen Sie die Logdateien auf die aufgeführten Fehler, und aktualisieren Sie gegebenenfalls das Backupmodul.

  1. Prüfen Sie die RMAN-Backuplogdateien auf die oben aufgeführten Fehler:

    1. Führen Sie den folgenden Befehl aus, um die ID des nicht erfolgreichen Backupjobs zu bestimmen.

      dbcli list-jobs

      In dieser Beispielausgabe lautet die ID des nicht erfolgreichen Backupjobs "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. Ermitteln Sie anhand der ID des nicht erfolgreichen Jobs den Speicherort der zu prüfenden Logdatei.

      dbcli describe-job -i <failed_job_ID>

      Eine relevante Ausgabe des Befehls describe-job sollte wie folgt aussehen: 

      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. Aktualisieren Sie das Oracle Database Cloud Backup-Modul:

    1. Ermitteln Sie die Swift-Objektspeicher-ID und den Benutzer, den die Datenbank für Backups verwendet.

      1. Führen Sie den Befehl dbcli list-databases aus, um die ID der Datenbank zu bestimmen.

      2. Verwenden Sie die Datenbank-ID, um die Backupkonfigurations-ID (backupConfigId) zu bestimmen. 

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

      3. Ermitteln Sie anhand der Backupkonfigurations-ID, die Sie im vorherigen Schritt notiert haben, die Objektspeicher-ID (objectStoreId). 

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

      4. Ermitteln Sie anhand der Objektspeicher-ID, die Sie im vorherigen Schritt notiert haben, den Objektspeicherbenutzer (userName). 

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

    2. Aktualisieren Sie das Backupmodul mithilfe der Zugangsdaten des Objektspeichers, die Sie in Schritt 1 erhalten haben.

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

Backup in Object Storage mit RMAN verläuft wegen Zertifikatsänderung nicht erfolgreich

Details

Nicht verwaltete Backups in Object Storage mit der RMAN verlaufen mit den folgenden Fehlern nicht möglich:

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

Aufgrund der von zwei gängigen Webbrowsern in Bezug auf Symantec-Zertifikate implementierten Policys hat Oracle vor Kurzem die für Oracle Cloud Infrastructure verwendete Certificate Authority geändert. Die daraus resultierende Änderung der SSL-Zertifikate kann dazu führen, dass Backups in Object Storage nicht erfolgreich ausgeführt werden, wenn das Oracle Database Cloud Backup-Modul weiterhin auf das alte Zertifikat verweist.

Workaround

Prüfen Sie die RMAN-Logdateien auf die aufgeführten Fehlermeldungen. Wenn Sie sie gefunden haben, melden Sie sich beim Host als Oracle-Benutzer ("oracle") an, und verwenden Sie Ihre Swift-Zugangsdaten, um das Backupmodul neu zu installieren.

Hinweis:

Swift-Kennwörter werden jetzt als "Authentifizierungstoken" bezeichnet. Weitere Informationen finden Sie unter Benutzerzugangsdaten verwalten. 
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

Bei einem DB-System mit mehreren Knoten können Sie den Workaround für alle Knoten im Cluster anwenden.

Weitere Informationen zum Oracle Database Cloud Backup-Modul finden Sie unter Oracle Database Backup Cloud Service verwenden.

Wichtige Änderungen bei Datenbankservice-SDKs

Details

In den am 18. Oktober 2018 veröffentlichten SDKs werden bedeutende Änderungen an der Datenbankgröße und den Datenbankeditionsattributen in den Datenbankbackup-APIs eingeführt.

Workaround

In der sprachspezifischen Dokumentation findest du weitere Informationen zu den wichtigen Änderungen. Aktualisieren Sie gegebenenfalls Ihren vorhandenen Code.

Verwaltete Backups können in Ihrem DB-System nicht verwendet werden

Details

Backup- und Restore-Vorgänge können in Ihrem DB-System möglicherweise nicht ausgeführt werden, wenn Sie die OCI-Konsole oder die API verwenden.

Workaround

Installieren Sie das Oracle Database Cloud Backup-Modul, und wenden Sie sich dann an Oracle Support Services, um weitere Anweisungen zu erhalten.

Führen Sie die folgenden Schritte aus, um das Oracle Database Cloud Backup-Modul zu installieren:

  1. Stellen Sie mit SSH eine Verbindung zum DB-System her, und melden Sie sich als opc an. 

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

    Alternativ können Sie opc@<DB_system_hostname> zur Anmeldung verwenden.

  2. Laden Sie das Oracle Database Cloud Backup-Modul aus dem Oracle Database Cloud Backup-Modul herunter.
  3. Extrahiert den Inhalt von opc_installer.zip in ein Zielverzeichnis, z.B. /home/opc.
  4. Erstellen Sie in Ihrem Mandanten einen temporären Benutzer, und erteilen Sie diesem Berechtigungen für den Zugriff auf den Objektspeicher des Mandanten.
  5. Erstellen Sie für diesen temporären Benutzer ein Authentifizierungstoken, und notieren Sie sich das Kennwort. Weitere Informationen zum Erstellen des Authentifizierungstokens finden Sie unter Benutzerzugangsdaten verwalten.

    Hinweis:

    Swift-Kennwörter werden jetzt als "Authentifizierungstoken" bezeichnet.

  6. Verifizieren Sie die Zugangsdaten, indem Sie den folgenden curl-Befehl ausführen:

    curl -v -X HEAD -u  <user_id>:'<auth_token>' https://swiftobjectstorage.<region_name>.oraclecloud.com/v1/<object_storage_namespace>

    Informationen zum Bestimmen der richtigen Region finden Sie unter Object Storage - Häufig gestellte Fragen.

    Der Befehl sollte entweder den Antwortcode HTTP 200 oder HTTP 204 No Content für Erfolgsstatus zurückgeben. Jeder andere Statuscode gibt ein Problem beim Herstellen der Verbindung mit Object Storage an.

  7. Führen Sie den folgenden Befehl aus:

    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

    Hinweis: <target_dir> ist das Verzeichnis, zu dem Sie opc_installer.zip in Schritt 3 extrahiert haben.

    Die Ausführung dieses Befehls kann einige Minuten dauern, da er libopc.so und weitere Dateien herunterlädt. Nach Abschluss des Befehls sollten mehrere Dateien (einschließlich libopc.so) in Ihrem Zielverzeichnis angezeigt werden.

  8. Wechseln Sie zu Ihrem Zielverzeichnis, und kopieren sie die Dateien lipopc.so und opc_install.jar in das Verzeichnis /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

    (Möglicherweise müssen Sie sudo mit den Kopierbefehlen verwenden, um sie als root auszuführen.)

  9. Führen Sie den folgenden Befehl aus, um zu prüfen, ob das angegebene Verzeichnis vorhanden ist:

    ls /opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs

    Wenn dieses Verzeichnis vorhanden ist, führen Sie die folgenden Schritte aus:

    1. Sichern Sie die Dateien im Verzeichnis /opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs.

    2. Führen Sie diese beiden Befehle aus, um die vorhandenen Dateien libopc.so und opc_install.jar in diesem Verzeichnis zu ersetzen: 

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

  10. Prüfen Sie die Version von opc_install.jar. 

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

    Wenn /opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs vorhanden ist, führen Sie auch den folgenden Befehl ein: 

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

    Beide Befehle sollten die folgende Ausgabe zurückgeben:

    Oracle Database Cloud Backup Module Install Tool, build MAIN_2017-08-16.
  11. (Optional) Löschen Sie den temporären Benutzer und das Zielverzeichnis, die Sie zum Installieren des Backupmoduls verwendet haben.

Nachdem Sie die Prozedur abgeschlossen haben, wenden Sie sich an Oracle Support oder den Mandantenadministrator, um weitere Anweisungen zu erhalten. Sie müssen die OCID des DB-Systems angeben, für das Sie Backups aktivieren möchten.

Verwaltete automatische Backups sind bei der VM.Standard1.1-Ausprägung wegen eines Prozessabsturzes nicht erfolgreich

Details

Die Speicherbeschränkungen von Hostrechnern, auf welchen die VM.Standard1.1-Ausprägung ausgeführt wird, können zu Fehlern bei automatischen Datenbankbackupjobs führen, welche von Oracle Cloud Infrastructure verwaltet werden (Jobs, welche mit der OCI-Konsole oder der API verwaltet wird). Sie können den Arbeitsspeicherparameter des System ändern, um dieses Problem zu lösen.

Workaround

Ändern Sie die Speicherparameter des Systems wie folgt:

  1. Wechseln Sie zum Benutzer oracle im Betriebssystem.

    [opc@hostname ~]$ sudo su - oracle

  2. Legen Sie die Umgebungsvariable für die Anmeldung bei der Datenbankinstanz fest. Beispiel:

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

  3. Starten Sie SQL*Plus.

    [oracle@hostname ~]$ sqlplus / as sysdba

  4. Ändern Sie die anfänglichen Arbeitsspeicherparameter wie folgt:

    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. Starten Sie die Datenbankinstanz neu.

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

Oracle Data Pump-Vorgänge geben "ORA-00439: Feature nicht aktiviert" zurück

Details

Bei High Performance- und Extreme Performance-DB-Systemen ver ablaufen die Vorgänge der Data Pump-Utilitys, die Komprimierung und/oder Parallelität verwenden, möglicherweise fehlgeschlagen und geben den Fehler ORA-00439: Feature nicht aktiviert zurück. Dieses Problem betrifft die Datenbankversionen 12.1.0.2.161018 und 12.1.0.2.170117.

Workaround

Spielen Sie das Patch 25579568 oder 25891266 in die Oracle Database Homes für das Datenbankversion 12.1.0.2.161018 bzw. 12.1.0.2.170117 ein. Alternativ können Sie den Patch vom April 2017 in das DB-System und das Datenbank-Home auf die OCI-Konsole anwenden.

Hinweis:

Um die Version einer Datenbank in einem Datenbank-Home zu bestimmen, führen Sie entweder $ORACLE_HOME/OPatch/opatch lspatches als oracle-Benutzer oder dbcli list-dbhomes als root-Benutzer aus.

Verbindung vom DB-System mit dem 1 Knoten zur EM Express-Konsole kann keine hergestellt werden

Details

Sie erhalten möglicherweise eine Fehlermeldung Wie "Sichere Verbindung konnte nicht hergestellt werden" wenn Sie versuchen, eine Verbindung von Ihrem 1 Knoten-DB-System mit EM Express-Konsole heranzuziehen, da die richtigen Berechtigungen nicht automatisch angewendet wurden.

Workaround

Fügen Sie Leseberechtigungen für die asmadmin-Gruppe im Wallet-Verzeichnis des DB-Systems hinzu, und wiederholen Sie den Verbindungsvorgang. Führen Sie die folgenden Schritte durch, um Leseberechtigungen hinzuzufügen.

  1. Stellen Sie mit SSH eine Verbindung zum DB-Systemhost her, melden Sie sich als opc an, und wechseln Sie mit sudo zum Benutzer grid. 

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

  2. Rufen Sie den Speicherort des Verzeichnisses wallet ab. Dies ist der Wert der my_wallet_directory in der folgenden Befehlsausgabe. 

    [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. Kehren Sie zum Benutzer opc zurück, wechseln Sie zum Benutzer oracle, und gehen Sie zum Verzeichnis wallet. 

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

  4. Listen Sie den Verzeichnisinhalt auf, und notieren Sie die Berechtigungen.

    [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. Ändern Sie die Berechtigungen.

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

  6. Prüfen Sie, ob Leseberechtigungen hinzugefügt wurden.

    [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

Konsoleninformationen für Datenbanken, die mit aktiviertem Data Guard synchronisiert werden, werden bei Verwendung von dbaascli nicht synchronisiert

Details

Die OCI-Konsole synchronisiert und zeigt Informationen zu Datenbanken an, die mit den Utilitys dbaasapi und dbaascli erstellt und verwaltet werden. Bei Datenbanken mit konfiguriertem Data Guard werden unter folgenden Bedingungen jedoch nicht die korrekten Informationen in der OCI-Konsole angezeigt:

  • Wenn Data Guard mit der OCI-Konsole aktiviert wurde und mit der dbaascli eine Änderung an der Primär- oder Standbydatenbank vorgenommen wird (z.B. Verschieben der Datenbank an ein anderes Home), wird das Ergebnis in der OCI-Konsole nicht berücksichtigt.
  • Wenn Data Guard manuell konfiguriert wurde, wird in der OCI-Konsole keine Data Guard-Verknüpfung zwischen den beiden Datenbanken angezeigt.

Workaround

Dieses Problem ist bekannt, und wir arbeiten an einer Lösung. In der Zwischenzeit empfiehlt Oracle, Datenbanken mit aktiviertem Data Guard entweder nur über die OCI-Konsole oder nur über Befehlszeilenutilitys zu verwalten.

Grid Infrastructure wird nicht gestartet, nachdem ein Datenträger Offline und online gesetzt wurde

Details

Dies ist ein Clusterware-Problem, das nur auftritt, wenn die Oracle Grid Infrastructure-(GI-)Version 12.2.0.1 ohne Bundle-Patch ist. Das Problem wird durch die Beschädigung einer Voting Disk verursacht, nachdem Sie den Datenträger offline und wieder online gesetzt haben.

Workaround

Bestimmen Sie die GI-Version, und ermitteln sie, ob die Voting Disk beschädigt ist. Reparieren Sie den Datenträger gegebenenfalls, und spielen Sie dann das neueste GI-Bundle ein.

Führen Sie die folgenden Schritte durch:

  1. Prüfen Sie, ob die GI-Version 12.2.0.1 ist und ob ein Bundle-Patch eingespielt wurde:

    [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. Prüfen Sie die Datei /u01/app/grid/diag/crs/<hostname>/crs/trace/ocssd.trc auf den Nachweis, dass die GI aufgrund einer Voting Disk-Beschädigung nicht gestartet werden konnte: 

    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. Sie können auch mit SQL*Plus prüfen, ob die Voting Disks beschädigt sind:

    1. Melden Sie sich als grid-Benutzer an, und stellen Sie die Umgebung auf ASM ein.

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

    2. Melden Sie sich bei SQL*Plus als SYSASM an. 

      $ORACLE_HOME/bin/sqlplus / as sysasm

    3. Führen Sie folgenden beiden Abfragen aus:

      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;

      Wenn das System fehlerfrei ist, sollten die Ergebnisse wie im folgenden Beispiel aussehen.

      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

      In einem fehlerfreien System muss jede Voting Disk, die in der ersten Abfrage zurückgegeben wird, auch in der zweiten Abfrage zurückgegeben werden. Außerdem muss die Anzahl für alle Datenträger ungleich Null sein. Andernfalls ist mindestens eine Ihrer Voting Disks beschädigt.

  4. Wenn eine Voting Disk beschädigt ist, setzen Sie die Grid Disk mit der Voting Disk offline. Die Cells verschieben die fehlerhafte Voting Disk automatisch auf die andere Grid Disk und setzt diese Voting Disk online.

    1. Der folgende Befehl setzt eine Grid Disk mit dem Namen DATAC01_CD_05_SCAQAE08CELADM13 offline.

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

    2. Warten Sie 30 Sekunden, und führen Sie dann die beiden Abfragen in Schritt 3c erneut aus, um zu prüfen, ob die Voting Disk auf die neue Grid Disk migriert wurde und ob sie fehlerfrei ist.

    3. Stellen Sie sicher, dass die Grid Disk, die Sie offline gesetzt haben, jetzt online ist:

      SQL> select name, mode_status, voting_file from v$asm_disk where name='DATAC01_CD_05_SCAQAE08CELADM13';

      mode_status muss ONLINE sein, und voting_file darf NICHT Y sein.

    Wiederholen Sie die Schritte 4a bis 4c für jede verbleibende Grid Disk, die eine beschädigte Voting Disk enthält.

    Hinweis:

    Wenn das CRS wegen einer Beschädigung der Voting Disk nicht gestartet wird, starten Sie es im Exclusive-Modus, bevor Sie den Befehl in Schritt 4 ausführen.

    crsctl start crs -excl

  5. Wenn Sie die Oracle GI-Version 12.2.0.1 ohne Bundle-Patch verwenden, müssen Sie die GI-Version auf das aktuelle GI-Bundle upgraden, unabhängig davon, ob eine Voting Disk beschädigt wurde.

Skalierungsfehler bei DB-Systemspeicher

Details

Wenn Sie versuchen, in einem einzigen Vorgang von einem Wert unter 10.240 GB auf einen Wert über 10.240 GB zu skalieren, verläuft der Skalierungsvorgang möglicherweise nicht erfolgreich.

Workaround

Wenn Sie entweder regulären Datenspeicher oder den Speicher des Recovery-Bereichs (RECO) von einem Wert unter 10.240 GB (10 TB) auf einen Wert über 10.240 GB skalieren, führen Sie die Skalierung in zwei Vorgängen aus. Skalieren Sie das System zunächst auf 10.240 GB. Wenn dieser erste Skalierungsvorgang abgeschlossen ist und das System den Status "Verfügbar" hat, führen Sie einen zweiten Skalierungsvorgang durch, und geben Sie den Speicherzielwert über 10.240 GB an.

Skalierungsfehler bei DB-Systemausprägung

Details

Wenn ein DB-System für die Verwendung einer größeren Systemausprägung skaliert werden soll, verläuft der Skalierungsvorgang nicht erfolgreich. Wenn ein Parameter DB_Cache_nX nicht auf 0 (null) gesetzt ist.

Workaround

Stellen Sie bei der Skalierung eines DB-Systems sicher, dass alle DB_Cache_nX-Parameter (z.B. DB_nK_CACHE_SIZE) auf 0 (null) gesetzt sind.