Problemi noti

Questo articolo fornisce informazioni sui problemi noti nel servizio Base Database.

Questi problemi noti vengono identificati nel servizio Base Database:

Argomenti correlati

Pluggable database esistenti nel nuovo database

Dettagli

I pluggable database esistenti (PDB) non vengono visualizzati in un database appena creato e potrebbero essere necessarie fino a qualche ora prima che vengano visualizzati in OCI Console. Include il PDB predefinito per un nuovo database e i PDB esistenti per i database duplicati o ripristinati. In caso di ripristino in loco a una versione precedente, la lista PDB viene aggiornata in modo simile e potrebbe verificarsi un ritardo.

Soluzione alternativa

Nessuno.

PDB nella configurazione Data Guard esistente

Dettagli

La creazione e la duplicazione di un PDB nel database primario non è consentita tramite OCI Console o l'API.

Soluzione alternativa

È possibile utilizzare SQL*Plus per creare o duplicare i PDB nel database primario e verranno sincronizzati in un secondo momento in OCI Console.

Problema di fatturazione durante la modifica del tipo di licenza

Dettagli

Quando cambi il tipo di licenza del tuo database o sistema DB dal modello BYOL alla licenza inclusa, o viceversa, ti verranno addebitati entrambi i tipi di licenze per la prima ora. Successivamente, ti verrà fatturato in base al tipo di licenza aggiornato.

Soluzione alternativa

Stiamo lavorando ad una risoluzione.

Il backup nello storage degli oggetti mediante dbcli non riesce a causa della modifica del certificato

Dettagli

I backup non gestiti nello storage degli oggetti mediante l'interfaccia CLI (dbcli) del database non riescono con i seguenti errori:

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

In risposta ai criteri implementati da due browser Web comuni relativi ai certificati Symantec, Oracle ha recentemente modificato l'autorità di certificazione utilizzata per Oracle Cloud Infrastructure. La modifica risultante nei certificati SSL può causare la mancata riuscita dei backup nello storage degli oggetti se il modulo di backup di Oracle Database Cloud punta ancora al vecchio certificato.

Soluzione alternativa

Controllare i file di log per individuare gli errori elencati e, se trovati, aggiornare il modulo di backup.

  1. Esaminare i file di log di backup RMAN per individuare gli errori elencati sopra:

    1. Eseguire il comando seguente per determinare l'ID del job di backup non riuscito.

      dbcli list-jobs

      In questo output di esempio, l'ID del job di backup non riuscito è "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. Utilizzare l'ID del job non riuscito per ottenere la posizione del file di log da esaminare.

      dbcli describe-job -i <failed_job_ID>

      L'output rilevante del comando describe-job dovrebbe essere simile al seguente: 

      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. Aggiornare il modulo di backup Oracle Database Cloud:

    1. Determinare l'ID dell'area di memorizzazione degli oggetti Swift e l'utente utilizzato dal database per i backup.

      1. Eseguire il comando dbcli list-databases per determinare l'ID del database.

      2. Utilizzare l'ID database per determinare l'ID configurazione di backup (backupConfigId). 

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

      3. Utilizzando l'ID di configurazione del backup annotato nel passo precedente, determinare l'ID dell'area di memorizzazione degli oggetti (objectStoreId). 

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

      4. Utilizzando l'ID dell'area di memorizzazione degli oggetti annotato nel passo precedente, determinare l'utente dell'area di memorizzazione degli oggetti (userName). 

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

    2. Utilizzando le credenziali dell'area di memorizzazione degli oggetti ottenute dal passo 1, aggiornare il modulo di backup.

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

Backup nello storage degli oggetti mediante RMAN non riuscito a causa della modifica del certificato

Dettagli

I backup non gestiti nello storage degli oggetti mediante RMAN non riescono con i seguenti errori:

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

In risposta ai criteri implementati da due browser Web comuni relativi ai certificati Symantec, Oracle ha recentemente modificato l'autorità di certificazione utilizzata per Oracle Cloud Infrastructure. La modifica risultante nei certificati SSL può causare la mancata riuscita dei backup nello storage degli oggetti se il modulo di backup di Oracle Database Cloud punta ancora al vecchio certificato.

Soluzione alternativa

Controllare i messaggi di errore elencati nei file di log RMAN. Se trovato, eseguire il login all'host come utente oracle e utilizzare le credenziali Swift per reinstallare il modulo di backup.

Nota

Le password Swift sono ora chiamate "token di autenticazione". Per ulteriori informazioni, vedere Gestione delle credenziali utente. 
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

Per un sistema DB a più nodi, eseguire la soluzione alternativa su tutti i nodi del cluster.

Per ulteriori informazioni su Oracle Database Cloud Backup Module, vedere Uso di Oracle Database Backup Cloud Service.

Interruzione delle modifiche negli SDK del servizio di database

Dettagli

Gli SDK rilasciati il 18 ottobre 2018 introducono modifiche a livello di codice alle dimensioni del database e agli attributi dell'edizione del database nelle API di backup del database.

Soluzione alternativa

Fare riferimento alla documentazione specifica della lingua per ulteriori dettagli sulle modifiche all'interruzione e aggiornare il codice esistente, se applicabile.

Impossibile utilizzare i backup gestiti nel sistema DB

Dettagli

Le operazioni di backup e ripristino potrebbero non funzionare nel sistema DB quando si utilizza OCI Console o l'API.

Soluzione alternativa

Installare l'Oracle Database Cloud Backup Module, quindi contattare Oracle Support Services per ulteriori istruzioni.

Per installare Oracle Database Cloud Backup Module, effettuare le operazioni riportate di seguito.

  1. SSH al sistema DB ed eseguire il login come opc. 

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

    In alternativa, è possibile utilizzare opc@<DB_system_hostname> per eseguire il login.

  2. Scarica il modulo Oracle Database Cloud Backup da Oracle Database Cloud Backup Module.
  3. Estrarre il contenuto di opc_installer.zip in una directory di destinazione, ad esempio /home/opc.
  4. Nella tenancy, creare un utente temporaneo e concedere loro i privilegi per accedere allo storage degli oggetti della tenancy.
  5. Per questo utente temporaneo, creare un token di autenticazione e annotare la password. Per ulteriori informazioni sulla creazione del token di autenticazione, vedere Gestione delle credenziali utente.

    Nota

    Le password Swift sono ora chiamate "token di autenticazione".

  6. Verificare che le credenziali funzionino eseguendo il seguente comando curl:

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

    Per informazioni sull'area corretta, consulta la sezione Storage degli oggetti - Domande frequenti.

    Il comando deve restituire il codice di risposta dello stato di operazione riuscita HTTP 200 o HTTP 204 No Content. Qualsiasi altro codice di stato indica un problema di connessione allo storage degli oggetti.

  7. Eseguire il comando riportato di seguito:

    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

    Si noti che <target_dir> è la directory in cui è stato estratto opc_installer.zip nel passo 3.

    Il completamento di questo comando potrebbe richiedere alcuni minuti poiché scarica libopc.so e altri file. Una volta completato il comando, è necessario visualizzare diversi file (incluso libopc.so) nella directory di destinazione.

  8. Modificare la directory nella directory di destinazione e copiare i file lipopc.so e opc_install.jar nella directory /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

    Potrebbe essere necessario utilizzare sudo con i comandi di copia per eseguirli come root.

  9. Eseguire il comando seguente per verificare se la directory indicata esiste:

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

    Se questa directory esiste, effettuare le operazioni riportate di seguito.

    1. Eseguire il backup dei file nella directory /opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs.

    2. Eseguire i due comandi riportati di seguito per sostituire i file libopc.so e opc_install.jar esistenti in tale directory. 

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

  10. Verificare la versione di opc_install.jar. 

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

    Se /opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs esiste, eseguire anche il comando seguente: 

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

    Entrambi i comandi devono restituire l'output seguente:

    Oracle Database Cloud Backup Module Install Tool, build MAIN_2017-08-16.
  11. (Opzionale) Eliminare l'utente temporaneo e la directory di destinazione utilizzata per installare il modulo di backup.

Dopo aver completato la procedura, contattare il Supporto Oracle o l'amministratore del tenant per ulteriori istruzioni. Fornire l'OCID del sistema DB per il quale si desidera abilitare i backup.

I backup automatici gestiti non riescono sulla forma VM.Standard1.1 a causa di un arresto anomalo del processo

Dettagli

Le limitazioni di memoria dei computer host che eseguono la forma VM.Standard1.1 possono causare errori per i job di backup automatico del database gestiti da Oracle Cloud Infrastructure (job gestiti utilizzando OCI Console o l'API). È possibile modificare i parametri di memoria del sistema per risolvere questo problema.

Soluzione alternativa

Modificare i parametri di memoria del sistema come indicato di seguito.

  1. Passare all'utente oracle nel sistema operativo.

    [opc@hostname ~]$ sudo su - oracle

  2. Impostare la variabile di ambiente per eseguire il login all'istanza di database. Ad esempio:

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

  3. Avviare SQL*Plus.

    [oracle@hostname ~]$ sqlplus / as sysdba

  4. Modificare i parametri di memoria iniziali come indicato di seguito.

    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. Riavviare l'istanza di database.

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

Le operazioni di Oracle Data Pump restituiscono "ORA-00439: funzione non abilitata"

Dettagli

Nei sistemi DB High Performance ed Extreme Performance, le operazioni della utility Data Pump che utilizzano compressione e/o parallelismo potrebbero non riuscire e restituire l'errore ORA-00439: funzione non abilitata. Questo problema riguarda le versioni del database 12.1.0.2.161018 e 12.1.0.2.170117.

Soluzione alternativa

Applicare la patch 25579568 o 25891266 alle home di Oracle Database per le versioni di database 12.1.0.2.161018 o 12.1.0.2.170117, rispettivamente. In alternativa, utilizzare OCI Console per applicare la patch di aprile 2017 al sistema DB e alla home del database.

Nota

Per determinare la versione di un database in una home del database, eseguire $ORACLE_HOME/OPatch/opatch lspatches come utente oracle o dbcli list-dbhomes come utente root.

Impossibile connettersi alla console EM Express dal sistema DB a 1 nodo

Dettagli

È possibile che venga visualizzato un messaggio di errore "Connessione sicura non riuscita" quando si tenta di connettersi alla console EM Express dal sistema DB a 1 nodo perché le autorizzazioni corrette non sono state applicate automaticamente.

Soluzione alternativa

Aggiungere le autorizzazioni di lettura per il gruppo asmadmin nella directory wallet del sistema DB, quindi riprovare la connessione. Per aggiungere le autorizzazioni di lettura, attenersi alla procedura seguente.

  1. SSH all'host del sistema DB, eseguire il login come opc e sudo all'utente grid. 

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

  2. Recupera la posizione della directory wallet. È il valore di my_wallet_directory nell'output del comando seguente. 

    [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. Tornare all'utente opc, passare all'utente oracle e passare alla directory wallet. 

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

  4. Elencare il contenuto della directory e prendere nota delle autorizzazioni.

    [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. Cambiare le autorizzazioni.

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

  6. Verificare che le autorizzazioni di lettura siano state aggiunte.

    [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

Informazioni su OCI Console non sincronizzate per i database abilitati per Data Guard quando si utilizza dbaascli

Dettagli

OCI Console sincronizza e visualizza le informazioni sui database creati e gestiti utilizzando le utility dbaasapi e dbaascli. Tuttavia, i database con Data Guard configurato non visualizzano informazioni corrette in OCI Console nelle seguenti condizioni:

  • Se Data Guard è stato abilitato utilizzando OCI Console e quindi viene apportata una modifica al database primario o in standby utilizzando dbaascli (ad esempio spostando il database in una home diversa), il risultato non si riflette nella console OCI.
  • Se Data Guard è stato configurato manualmente, OCI Console non mostra un'associazione Data Guard tra i due database.

Soluzione alternativa

Siamo a conoscenza del problema e stiamo lavorando a una risoluzione. Nel frattempo, Oracle consiglia di gestire i database abilitati per Data Guard utilizzando solo OCI Console o solo le utility della riga di comando.

Grid Infrastructure non viene avviato dopo la rimozione e l'online di un disco

Dettagli

Si tratta di un problema clusterware che si verifica solo quando la versione di Oracle Grid Infrastructure (GI) è 12.2.0.1 senza alcuna patch bundle. Il problema è causato dalla corruzione di un disco di voto dopo che si è offline quindi online il disco.

Soluzione alternativa

Determinare la versione del GI e se il disco di voting è danneggiato. Riparare il disco, se applicabile, quindi applicare il bundle GI più recente.

Effettuare le seguenti operazioni:

  1. Verificare che la versione GI sia 12.2.0.1 senza applicare alcuna patch bundle:

    [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. Controllare il file /u01/app/grid/diag/crs/<hostname>/crs/trace/ocssd.trc per verificare che l'avvio di GI non sia riuscito a causa del danneggiamento del disco di voting: 

    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. È inoltre possibile utilizzare SQL*Plus per confermare che i dischi di voting sono danneggiati:

    1. Eseguire il login come utente della griglia e impostare l'ambiente su 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. Eseguire il login a SQL*Plus come SYSASM. 

      $ORACLE_HOME/bin/sqlplus / as sysasm

    3. Eseguire le due query riportate di seguito.

      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;

      Se il sistema è in buono stato, i risultati dovrebbero essere simili a quelli dell'esempio seguente.

      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 un sistema in buono stato, ogni disco di voting restituito nella prima query deve essere restituito anche nella seconda query e il conteggio di tutti i dischi deve essere diverso da zero. Altrimenti, uno o più dischi di voto sono danneggiati.

  4. Se un disco di voting è danneggiato, scollegare il disco griglia contenente il disco di voting. Le celle spostano automaticamente il disco di voting errato nell'altro disco di griglia e in linea nel disco di voting.

    1. Il comando seguente delinea un disco griglia denominato DATAC01_CD_05_SCAQAE08CELADM13.

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

    2. Attendere 30 secondi, quindi eseguire di nuovo le due query nel passo 3c per verificare che il disco di voting sia migrato al nuovo disco griglia e che sia in buono stato.

    3. Verificare che il disco griglia disattivato sia ora online:

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

      mode_status deve essere ONLINE e voting_file NON deve essere Y.

    Ripetere i passi da 4a a 4c per ogni disco griglia rimanente contenente un disco di voting danneggiato.

    Nota

    Se il CRS non si avvia a causa della corruzione del disco di voting, avviarlo utilizzando la modalità Exclusive prima di eseguire il comando nel passaggio 4.

    crsctl start crs -excl

  5. Se si utilizza Oracle GI versione 12.2.0.1 senza alcuna patch bundle, è necessario eseguire l'upgrade della versione GI al bundle GI più recente, indipendentemente dal fatto che un disco di voting sia danneggiato.

Errore di ridimensionamento dello storage del sistema DB

Dettagli

Il tentativo di ridimensionare da un valore inferiore a 10.240 GB a un valore superiore a 10.240 GB in una singola operazione può portare a un errore dell'operazione di ridimensionamento.

Soluzione alternativa

Se si sta eseguendo il ridimensionamento dello storage di dati normale o dell'area di recupero (RECO) da un valore inferiore a 10.240 GB (10 TB) a un valore superiore a 10.240 GB, eseguire il ridimensionamento in due operazioni. In primo luogo, ridimensionare il sistema a 10.240 GB. Una volta completata questa prima operazione di ridimensionamento e lo stato del sistema è "disponibile", eseguire una seconda operazione di ridimensionamento, specificando il valore di storage di destinazione superiore a 10.240 GB.

Errore di ridimensionamento della forma del sistema DB

Dettagli

Quando si esegue il ridimensionamento di un sistema DB per utilizzare una forma di sistema più grande, l'operazione di ridimensionamento non riesce se un parametro DB_Cache_nX non è impostato su 0 (zero).

Soluzione alternativa

Durante la scala di un sistema DB, assicurarsi che tutti i parametri DB_Cache_nX (ad esempio, DB_nK_CACHE_SIZE) siano impostati su 0 (zero).