Problemi noti

Dettagli: in Monitoraggio sintetico, i monitoraggi Browser e Browser con script potrebbero non essere eseguiti su applicazioni che utilizzano frame.

Soluzione: siamo a conoscenza del problema e stiamo lavorando alla risoluzione. Per i monitoraggi del browser con script, è possibile risolvere il problema sostituendo index=<frame-index> con id=<id-of-frame> o name=<name-of-frame> nello script .side.

Ad esempio, se questo script è la versione originale:

{
      "id": "23956f51-8812-40e6-ac91-1d608871ee4c",
      "comment": "",
      "command": "selectFrame",
      "target": "index=0",
      "targets": [
        ["index=0"]
      ],
      "value": ""
    }

Il seguente script sarebbe la versione modificata:

{
      "id": "23956f51-8812-40e6-ac91-1d608871ee4c",
      "comment": "",
      "command": "selectFrame",
      "target": "id=frame1",
      "targets": [
        ["id=frame1"]
      ],
      "value": ""
    }

Collegamento diretto a questo problema:i monitoraggi browser e browser con script potrebbero non eseguire applicazioni che utilizzano frame

Dettagli: i criteri di autorizzazione basati sulle tag delle risorse apm-domains non funzionano per le API Trace Explorer e Synthetic Monitoring, causando errori di autorizzazione.

Soluzione: siamo a conoscenza del problema e stiamo lavorando alla risoluzione.

Collegamento diretto a questo problema: problemi con i criteri di autorizzazione basati sulle tag delle risorse apm-domains

Dettagli: quando si tenta di accedere alla console utilizzando Firefox, la pagina Console non viene mai caricata nel browser. Questo problema è probabilmente causato da un profilo utente di Firefox danneggiato.

Soluzione: creare un nuovo profilo utente Firefox, come indicato di seguito.

1. Assicurati di essere sull'ultima versione di Firefox. In caso contrario, eseguire l'aggiornamento alla versione più recente.
2. Creare un nuovo profilo utente e rimuovere il vecchio profilo utente. Per istruzioni su come creare e rimuovere un profilo utente, consultare il Supporto Mozilla: https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles.
3. Apri Firefox con il nuovo profilo.

In alternativa, è possibile utilizzare uno degli altri Browser supportati.

Collegamento diretto a questo problema: il bug nel browser Firefox può impedire il caricamento della console

Dettagli: i PDB esistenti non vengono visualizzati in un database appena creato e potrebbero essere necessarie fino a qualche ora prima che vengano visualizzati nella 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: nessuna

Collegamento diretto a questo problema: PDB esistenti in un nuovo database

Dettagli: la creazione e la duplicazione di un PDB nel database primario non sono consentite tramite la console o l'API.

Soluzione: è possibile utilizzare sqlplus per creare o duplicare PDB nel database primario e sincronizzarli in un secondo momento in OCI Console.

Collegamento diretto a questo problema: PDB nella configurazione Data Guard esistente

Dettagli: l'uso dell'API del servizio di database per eseguire la migrazione di un wallet TDE basato su file a un wallet TDE basato su chiavi gestito dal cliente in Oracle Database 12c release 1 (12.1.0.2) non riesce con il seguente errore:

[FATAL] [DBAAS-11014] - Le patch obbligatorie (30128047) non sono presenti nella Oracle home <ORACLE_HOME>
ACTION: applicare le patch necessarie (30128047) e riprovare l'operazione.

nohup /var/opt/oracle/dbaascli/dbaascli tde file_to_hsm --dbname <database_name> --kms_key_ocid <kms_key_ocid> --skip_patch_check true &

Nel comando precedente, < kms_key_ocid > si riferisce all'OCID della chiave gestita dal cliente che si sta utilizzando.

Dettagli: l'uso dell'API del servizio di database per eseguire la migrazione di un wallet TDE basato su chiavi gestito dal cliente a un wallet TDE basato su file in Oracle Database 12c release 1 (12.1.0.2) non riesce con il seguente errore:

[FATAL] [DBAAS-11014] - Le patch obbligatorie (30128047) non sono presenti nella Oracle home <ORACLE_HOME>
ACTION: applicare le patch necessarie (30128047) e riprovare l'operazione.

nohup /var/opt/oracle/dbaascli/dbaascli tde hsm_to_file --dbname <database_name> --skip_patch_check true &

Dettagli: l'uso dell'API del servizio di database per eseguire la migrazione di un wallet TDE basato su file al wallet TDE basato su chiavi gestito dal cliente in Oracle Database 12c release 2 (12.2.0.1) non riesce con il seguente errore:

[FATAL] [DBAAS-11014] - Le patch obbligatorie (30128047) non sono presenti nella Oracle home <ORACLE_HOME>
ACTION: applicare le patch necessarie (30128047) e riprovare l'operazione.

Soluzione: eseguire la migrazione di un wallet TDE basato su file in un wallet TDE basato su chiavi gestito dal cliente, come indicato di seguito.

1. Determinare se il database ha cifrato le tablespace UNDO o TEMP in uno qualsiasi dei database autonomi o in CDB$ROOT, come indicato di seguito.
   Eseguire la query seguente da CDB$ROOT per elencare tutte le tablespace cifrate contenute in tutti i database autonomi:

   SQL> select tstab.con_id, tstab.name from v$tablespace tstab, v$encrypted_tablespaces enctstab where tstab.ts# = enctstab.ts# and encryptedts = 'YES';

   Nella colonna NAME del risultato della query, cercare i nomi delle tablespace UNDO e TEMP. Se sono presenti tablespace UNDO o TEMP cifrate, procedere al passo successivo.

2. Deselezionare le tablespace UNDO o TEMP come indicato di seguito.

   Se una tablespace UNDO è cifrata

   Annullare la cifratura delle tablespace UNDO esistenti come indicato di seguito.

   SQL> alter tablespace <undo_tablespace_name> encryption online decrypt;

   Ripetere questa procedura per tutte le tablespace UNDO cifrate.

   Se una tablespace TEMP è cifrata

   1. Controllare la tablespace TEMP predefinita, come indicato di seguito.

      SQL> select property_value from database_properties where property_name = 'DEFAULT_TEMP_TABLESPACE';

      Se la tablespace TEMP predefinita non è cifrata, ma altre tablespace TEMP sono cifrate, eliminare le altre tablespace TEMP come indicato di seguito.

      SQL> drop tablespace <temp_tablespace_name>;

      Saltare il resto dei passi di questa procedura.

      Se la tablespace TEMP predefinita è cifrata, procedere con i passi rimanenti per creare e impostare una tablespace TEMP predefinita non cifrata.

   2. Impostare il parametro encrypt_new_tablespaces su DDL, come indicato di seguito.

      SQL> alter system set "encrypt_new_tablespaces" = DDL scope = memory;

   3. Creare una tablespace TEMP con le specifiche della tablespace TEMP corrente, come descritto di seguito.

      SQL> create temporary tablespace <temp_tablespace_name> TEMPFILE size 5000M;

   4. Impostare la nuova tablespace TEMP come tablespace TEMP predefinita per il database, come indicato di seguito.

      SQL> alter database default temporary tablespace <temp_tablespace_name>;

   5. Eliminare le tablespace TEMP esistenti come indicato di seguito.

      SQL> drop tablespace <temp_tablespace_name>;

   Ripetere questa procedura per tutte le tablespace TEMP cifrate.

   Il database è ora in esecuzione con le tablespace UNDO e TEMP predefinite che non sono cifrate e vengono decifrate anche le tablespace TEMP e UNDO meno recenti.

   Impostare encrypt_new_tablespaces sul valore originale, come indicato di seguito.

   SQL> alter system set "encrypt_new_tablespaces" = cloud_only;

   Procedere con la migrazione del keystore alle chiavi gestite dal cliente.

3. Una volta confermato che non sono presenti tablespace UNDO o TEMP cifrate in alcun pluggable database o in CDB$ROOT, utilizzare la utility DBAASCLI con il flag --skip_patch_check true per saltare la convalida della patch per il bug 30128047. Assicurarsi di aver applicato la patch per il bug 31527103 nella Oracle home, quindi eseguire il comando dbaascli seguente:

   nohup /var/opt/oracle/dbaascli/dbaascli tde file_to_hsm --dbname <database_name> --kms_key_ocid <kms_key_ocid> --skip_patch_check true &

   Nel comando precedente, < kms_key_ocid > si riferisce all'OCID della chiave gestita dal cliente che si sta utilizzando.

Dettagli: l'uso dell'API del servizio di database per eseguire la migrazione di un wallet TDE basato su chiavi gestito dal cliente a un wallet TDE basato su file in Oracle Database 12c release 2 (12.2.0.1) non riesce con il seguente errore:

[FATAL] [DBAAS-11014] - Le patch obbligatorie (30128047) non sono presenti nella Oracle home <ORACLE_HOME>
ACTION: applicare le patch necessarie (30128047) e riprovare l'operazione.

Soluzione: eseguire la migrazione di un wallet TDE basato su chiavi gestito dal cliente in un wallet TDE basato su file, come indicato di seguito.

1. Determinare se il database ha cifrato le tablespace UNDO o TEMP in uno qualsiasi dei database autonomi o in CDB$ROOT, come indicato di seguito.
   Eseguire la query seguente da CDB$ROOT per elencare tutte le tablespace cifrate contenute in tutti i database autonomi:

   SQL> select tstab.con_id, tstab.name from v$tablespace tstab, v$encrypted_tablespaces enctstab where tstab.ts# = enctstab.ts# and encryptedts = 'YES';

   Nella colonna NAME del risultato della query, cercare i nomi delle tablespace UNDO e TEMP. Se sono presenti tablespace UNDO o TEMP cifrate, procedere al passo successivo.

2. Deselezionare le tablespace UNDO o TEMP come indicato di seguito.

   Se una tablespace UNDO è cifrata

   Annullare la cifratura delle tablespace UNDO esistenti come indicato di seguito.

   SQL> alter tablespace <undo_tablespace_name> encryption online decrypt;

   Ripetere questa procedura per tutte le tablespace UNDO cifrate.

   Se una tablespace TEMP è cifrata

   1. Controllare la tablespace TEMP predefinita, come indicato di seguito.

      SQL> select property_value from database_properties where property_name = 'DEFAULT_TEMP_TABLESPACE';

      Se la tablespace TEMP predefinita non è cifrata, ma altre tablespace TEMP sono cifrate, eliminare le altre tablespace TEMP come indicato di seguito.

      SQL> drop tablespace <temp_tablespace_name>;

      Saltare il resto dei passi di questa procedura.

      Se la tablespace TEMP predefinita è cifrata, procedere con i passi rimanenti per creare e impostare una tablespace TEMP predefinita non cifrata.

   2. Impostare il parametro encrypt_new_tablespaces su DDL, come indicato di seguito.

      SQL> alter system set "encrypt_new_tablespaces" = DDL scope = memory;

   3. Creare una tablespace TEMP con le specifiche della tablespace TEMP corrente, come descritto di seguito.

      SQL> create temporary tablespace <temp_tablespace_name> TEMPFILE size 5000M;

   4. Impostare la nuova tablespace TEMP come tablespace TEMP predefinita per il database, come indicato di seguito.

      SQL> alter database default temporary tablespace <temp_tablespace_name>;

   5. Eliminare le tablespace TEMP esistenti come indicato di seguito.

      SQL> drop tablespace <temp_tablespace_name>;

   Ripetere questa procedura per tutte le tablespace TEMP cifrate.

   Il database è ora in esecuzione con le tablespace UNDO e TEMP predefinite che non sono cifrate e vengono decifrate anche le tablespace TEMP e UNDO meno recenti.

   Impostare encrypt_new_tablespaces sul valore originale, come indicato di seguito.

   SQL> alter system set "encrypt_new_tablespaces" = cloud_only;

   Procedere con la migrazione del keystore alle chiavi gestite dal cliente.

3. Una volta confermato che non sono presenti tablespace UNDO o TEMP cifrate in alcun pluggable database o in CDB$ROOT, utilizzare la utility DBAASCLI con il flag --skip_patch_check true per saltare la convalida della patch per il bug 30128047. Assicurarsi di aver applicato la patch per il bug 29667994 nella Oracle home, quindi eseguire il comando dbaascli seguente:

   nohup /var/opt/oracle/dbaascli/dbaascli tde file_to_hsm --dbname <database_name> --kms_key_ocid <kms_key_ocid> --skip_patch_check true &

   Nel comando precedente, < kms_key_ocid > si riferisce all'OCID della chiave gestita dal cliente che si sta utilizzando.

Dettagli: quando si modifica il tipo di licenza del database o del sistema DB dal modello BYOL alla licenza inclusa, o viceversa, viene fatturato per entrambi i tipi di licenze per la prima ora. Successivamente, ti verrà fatturato in base al tipo di licenza aggiornato.

Soluzione: stiamo lavorando a una risoluzione.

Collegamento diretto a questo problema: problema di fatturazione quando si modifica il tipo di licenza

Dettagli: se configuri la tua VCN con un gateway di servizi, la subnet privata blocca l'accesso ai repository YUM necessari per aggiornare il sistema operativo. Questo problema interessa tutti i tipi di sistemi DB.

Soluzione: questo problema è stato risolto. Ecco la soluzione consigliata prima della risoluzione del problema:

Il gateway di servizi consente l'accesso ai repository Oracle YUM se si utilizza la panoramica dei gateway di servizi denominata Tutti i servizi <region> in Oracle Services Network. Tuttavia, è ancora possibile che si verifichino problemi di accesso ai servizi YUM tramite il gateway dei servizi. C'è una soluzione al problema. Per i dettagli, vedere Problemi di accesso delle istanze ai servizi Oracle yum tramite gateway di servizi.

Collegamento diretto a questo problema: RISOLTO: il gateway di servizi attualmente non supporta gli aggiornamenti del sistema operativo

Dettagli: i backup non gestiti nello storage degli oggetti mediante l'interfaccia CLI (dbcli) del database o 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: controllare i file di log per individuare gli errori elencati e, se trovati, aggiornare il modulo di backup.

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

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

Aggiornare il modulo Oracle Database Cloud Backup:

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>
                               

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

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 informazioni dettagliate sull'uso di questo comando, consultare la documentazione di Oracle Database Cloud Backup Module.

Collegamento diretto a questo problema: Il backup dello storage degli oggetti mediante dbcli o RMAN non riesce a causa della modifica del certificato

Dettagli: gli SDK rilasciati il 18 ottobre 2018 introducono modifiche in codice alle dimensioni del database e agli attributi dell'edizione del database nelle API di backup del database.

Soluzione: consultare la seguente documentazione specifica della lingua per ulteriori dettagli sulle modifiche all'interruzione e aggiornare il codice esistente, se applicabile:

Collegamento diretto a questo problema: interruzione delle modifiche negli SDK del servizio di database

Dettagli: le operazioni di backup e ripristino potrebbero non funzionare nel sistema DB quando si utilizza la console o l'API.

Soluzione: installare il modulo Oracle Database Cloud Backup, quindi contattare Oracle Support Services per ulteriori istruzioni.

Per installare il modulo di backup Oracle Database Cloud, procedere come segue.

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. Scaricare Oracle Database Cloud Backup Module da http://www.oracle.com/technetwork/database/availability/oracle-cloud-backup-2162729.html.
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 utilizzo dei token di autenticazione e annotare la password.

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

   Nota
   
   Le password Swift sono ora denominate "token di autenticazione". Per ulteriori informazioni, vedere Utilizzo di un token di autenticazione con Swift.

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

   Per l'area corretta da utilizzare, vedere https://cloud.oracle.com/infrastructure/storage/object-storage/faq.

   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.

Collegamento diretto a questo problema: Impossibile utilizzare i backup gestiti nel sistema DB

Dettagli: le limitazioni della 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 la console o l'API). È possibile modificare i parametri di memoria del sistema per risolvere questo problema.

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

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

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: 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 la console per applicare la patch di aprile 2017 al sistema DB e alla home del database.

Collegamento diretto a questo problema: le operazioni di Oracle Data Pump restituiscono "ORA-00439: funzione non abilitata"

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: aggiungere le autorizzazioni di lettura per il gruppo asmadmin nella directory wallet del sistema DB, quindi riprovare la connessione:

1. SSH all'host del sistema DB, eseguire il login come opc, eseguire il 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 del wallet, visualizzata in rosso di seguito nell'output del comando.

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

Collegamento diretto a questo problema: Impossibile connettersi alla console EM Express dal sistema DB a 1 nodo

Dettagli: le operazioni di backup nello storage degli oggetti mediante la utility di backup Exadata (bkup_api) o RMAN non riescono con i seguenti errori:

* DBaaS Error trace:
-> API::ERROR -> KBHS-00715: HTTP error occurred 'oracle-error'
-> API::ERROR -> ORA-19511: non RMAN, but media manager or vendor specific failure, error text:
-> API::ERROR -> ORA-19554: error allocating device, device type: SBT_TAPE, device name:
-> API::ERROR -> ORA-27023: skgfqsbi: media manager protocol error
-> API::ERROR Unable to verify the backup pieces
-> 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 per bkup_api: controllare i file di log per individuare gli errori sopra elencati e, se trovati, reinstallare il modulo di backup.

Utilizzare il comando seguente per controllare lo stato del backup non riuscito:

/var/opt/oracle/bkup_api/bkup_api bkup_status --dbname=<database_name>
                    

Eseguire il comando seguente per reinstallare il modulo di backup:

/var/opt/oracle/ocde/assistants/bkup/bkup -dbname=<database_name>
                    

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

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

Eseguire questa soluzione su tutti i nodi del cluster.

Per informazioni dettagliate sull'uso di questo comando, consultare la documentazione di Oracle Database Cloud Backup Module.

Collegamento diretto a questo problema: Il backup dello storage degli oggetti mediante bkup_api o RMAN non riesce a causa della modifica del certificato

Dettagli: con la release della funzione Home database condivisa per i sistemi DB Exadata, la console ora sincronizza e visualizza anche le informazioni sui database creati e gestiti utilizzando le utility dbaasapi e dbaascli. Tuttavia, i database con Data Guard configurato non visualizzano informazioni corrette nella console nelle seguenti condizioni:

• Se Data Guard è stato abilitato utilizzando la 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.
• Se Data Guard è stato configurato manualmente, la console non mostra un'associazione Data Guard tra i due database.

Soluzione: si è a conoscenza del problema e si sta lavorando alla risoluzione. Nel frattempo, Oracle consiglia di gestire i database abilitati per Data Guard utilizzando solo la console o solo le utility della riga di comando.

Collegamento diretto a questo problema: le informazioni sulla console non sono sincronizzate per i database abilitati per Data Guard quando si utilizza dbaascli

Dettagli: si tratta di un problema clusterware che si verifica solo quando la versione di Oracle 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: determinare la versione di GI e se il disco di voting è danneggiato. Riparare il disco, se applicabile, quindi applicare il bundle GI più recente.

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

      Risultati query 1

      NAME                           VOTING_FILE
      ------------------------------ ---------------
      DBFSC3_CD_02_SLCLCX0788        Y
      DBFSC3_CD_09_SLCLCX0787        Y
      DBFSC3_CD_04_SLCLCX0786        Y

      Risultati query 2

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

      Il valore mode_status deve essere ONLINE e il valore 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.

   Vedere Applicazione delle patch ai database Oracle Grid Infrastructure e Oracle mediante dbaascli per istruzioni su come utilizzare la utility dbaascli per eseguire operazioni di applicazione delle patch per Oracle Grid Infrastructure e Oracle Database su Exadata Database Service on Dedicated Infrastructure.

Collegamento diretto a questo problema: Grid Infrastructure non viene avviata dopo la rimozione e l'onlineing di un disco

Dettagli: i sistemi DB Exadata avviati il 15 giugno 2018 o versioni successive includono automaticamente la possibilità di creare, elencare ed eliminare i database utilizzando la console, l'API o l'interfaccia CLI di Oracle Cloud Infrastructure. Tuttavia, i sistemi di cui è stato eseguito il provisioning prima di questa data richiedono ulteriori passaggi per abilitare questa funzionalità.

I tentativi di utilizzare questa funzionalità senza i passi aggiuntivi generano i seguenti messaggi di errore:

• Durante la creazione di un database - "Crea database non è supportato su questo sistema DB Exadata. Per abilitare questa funzionalità, contattare il Supporto Oracle.
• All'arresto di un database - "DeleteDbHome non è supportato su questo sistema DB Exadata. Per abilitare questa funzionalità, contattare il Supporto Oracle.

Soluzione: è necessario installare l'agente Exadata su ciascun nodo del sistema DB Exadata.

In primo luogo, creare una richiesta di assistenza per Oracle Support Services. Il Supporto Oracle risponderà fornendo un URL preautenticato per una posizione di Oracle Cloud Infrastructure Object Storage in cui è possibile ottenere l'agente.

Prima di installare l'agente Exadata:

• Eseguire l'upgrade degli strumenti (dbaastools rpm) alla versione più recente in tutti i nodi del sistema DB Exadata. Vedere Aggiornamento degli strumenti su un'istanza di Exadata Cloud Service.
• Assicurarsi che il sistema sia configurato per accedere a Oracle Cloud Infrastructure Object Storage con le liste di sicurezza necessarie per l'area in cui è stato creato il sistema DB. Per ulteriori informazioni sulla connettività a Oracle Cloud Infrastructure Object Storage, vedere Prerequisiti per i backup su Exadata Cloud Service.

Per installare l'agente Exadata:

1. Effettuare il login al nodo come utente root.

2. Eseguire i comandi seguenti per installare l'agente:

   [root@<node_n>~]# cd /tmp
   [root@<node_n>~]# wget https://objectstorage.<region_name>.oraclecloud.com/p/1q523eOkAOYBJVP9RYji3V5APlMFHIv1_6bAMmxsS4E/n/dbaaspatchstore/b/dbaasexadatacustomersea1/o/backfill_agent_package_iwwva.tar
   [root@<node_n>~]# tar -xvf /tmp/backfill_agent_package_*.tar -C /tmp
   [root@<node_n>~]# rpm -ivh /tmp/dbcs-agent-2.5-3.x86_64.rpm

   Output di esempio:

   [root@<node_n>~]# rpm -ivh dbcs-agent-2.5-3.x86_64.rpm
   Preparing...                ########################################### [100%]
   Checking for dbaastools_exa rpm on the system
   Current dbaastools_exa version = dbaastools_exa-1.0-1+18.1.4.1.0_180725.0000.x86_64
   dbaastools_exa version dbaastools_exa-1.0-1+18.1.4.1.0_180725.0000.x86_64 is good. Continuing with dbcs-agent installation
      1:dbcs-agent             ########################################### [100%]
   initctl: Unknown instance:
   initctl: Unknown instance:
   initzookeeper start/running, process 85821
   initdbcsagent stop/waiting
   initdbcsadmin stop/waiting
   initdbcsagent start/running, process 85833
   initdbcsadmin start/running, process 85836
   

3. Confermare che l'agente è installato e in esecuzione.

   [root@<node_n>~]# rpm -qa | grep dbcs-agent
   dbcs-agent-2.5-0.x86_64
   [root@<node_n>~]# initctl status initdbcsagent
   initdbcsagent start/running, process 97832

4. Ripetere i passi da 1 a 3 sui nodi rimanenti.

Dopo l'installazione dell'agente su tutti i nodi, consentire fino a 30 minuti per Oracle di completare task del workflow aggiuntivi, ad esempio l'upgrade dell'agente alla versione più recente, la rotazione delle credenziali dell'agente e così via. Al termine del processo, dovresti essere in grado di utilizzare le funzioni gestite da Exadata nella console, nell'API o nell'interfaccia CLI di Oracle Cloud Infrastructure.

Collegamento diretto a questo problema: Funzioni gestite non abilitate per i sistemi di cui è stato eseguito il provisioning prima del 15 giugno 2018

Dettagli: il file di configurazione dell'applicazione delle patch (/var/opt/oracle/exapatch/exadbcpatch.cfg) punta all'area di memorizzazione degli oggetti dell'area us-phoenix-1, anche se il sistema DB Exadata viene distribuito in un'altra area.

Questo problema si verifica se la versione di rilascio del pacchetto di strumenti del database (dbaastools_exa) è 17430 o inferiore.

Soluzione: seguire le istruzioni riportate in Aggiornamento degli strumenti su un'istanza di Exadata Cloud Service per confermare che la versione della release del package degli strumenti è uguale o inferiore a 17430, quindi aggiornarla alla versione più recente.

Collegamento diretto a questo problema: l'applicazione di patch al file di configurazione punta a un'area errata

Dettagli: se si modifica il modo in cui Oracle Linux 7 gestisce i file temporanei, è possibile rimuovere i file socket richiesti dalla directory /var/tmp/.oracle. Questo problema interessa solo i sistemi DB Exadata in cui è in esecuzione l'immagine del sistema operativo versione 19.1.2.

Soluzione: eseguire sudo /usr/local/bin/imageinfo come utente opc per determinare la versione dell'immagine del sistema operativo. Se la versione dell'immagine in uso è la 19.1.2.0.0.190306, seguire le istruzioni disponibili in ID documento 2498572.1 per risolvere il problema.

Collegamento diretto a questo problema: vari errori del flusso di lavoro del database dovuti alla rimozione dei file temporanei richiesti da Oracle Linux 7

Dettagli: se utilizzi i backup dei gruppi di volumi durante l'esecuzione delle operazioni DR per la computazione e lo storage in diversi AD all'interno della stessa area, le transizioni DR avanti e indietro causeranno la fine dello storage a blocchi di computazione e associato (che utilizza i backup dei gruppi di volumi) in un AD diverso ogni volta.

Soluzione: questo problema non ha effetto sullo storage a blocchi replicato utilizzando la replica del gruppo di volumi.

Dettagli: le impostazioni delle prestazioni del tuning automatico per i volumi di storage a blocchi non vengono trasferite durante le operazioni di DR.

Soluzione: per i volumi di storage a blocchi con prestazioni con tuning automatico abilitato, è necessario riabilitare queste impostazioni dopo che Full Stack DR esegue il passaggio di questi volumi di storage a blocchi a un'altra area.

Dettagli: se si esegue un'operazione di failover immediatamente dopo la modifica di una risorsa protetta da Full Stack DR, il recupero delle risorse potrebbe non riuscire o la risorsa potrebbe non essere recuperata correttamente. Ad esempio, se si modifica la destinazione di replica o altre proprietà per un gruppo di volumi aggiunto a un gruppo di protezione DR e l'area primaria subisce un'indisponibilità immediata in seguito, Full Stack DR potrebbe non rilevare le modifiche apportate alle impostazioni di replica del gruppo di volumi e ciò influirà sul recupero di tale gruppo di volumi.

Soluzione: eseguire un controllo preliminare dello switchover immediatamente dopo aver apportato modifiche a qualsiasi risorsa in protezione DR.

Dettagli: Full Stack DR utilizza la utility Esegui comando di Oracle Cloud Agent (OCA) per eseguire script locali sulle istanze. Quando si configura un passo definito dall'utente per eseguire uno script locale in un'istanza di Microsoft Windows, non è possibile utilizzare la funzione Esegui come utente di Full Stack DR che consente di specificare un ID utente diverso per eseguire script locali che risiedono nelle istanze.

Soluzione: nelle istanze di Microsoft Windows, lo script può essere eseguito solo come ID utente ocarun predefinito utilizzato dalla utility Esegui comando dell'agente Oracle Cloud. Questa limitazione non ha effetto sulle istanze di Oracle Linux.

Dettagli: Full Stack DR utilizza la utility Esegui comando di Oracle Cloud Agent (OCA) per eseguire script locali sulle istanze. Per impostazione predefinita, questi script vengono eseguiti come utente ocarun.

Soluzione: in un'istanza di Microsoft Windows, qualsiasi script locale configurato per l'esecuzione come passo definito dall'utente in un piano DR deve essere accessibile ed eseguibile da questo ID utente ocarun.

Dettagli: quando si esegue uno script locale utilizzando un passo definito dall'utente in un piano DR, se non si forniscono percorsi completi per gli interpreti o gli script, Full Stack DR restituirà errori.

Soluzione: quando si configura un passo definito dall'utente in un piano DR per eseguire uno script locale che risiede in un'istanza, assicurarsi di fornire il percorso completo a qualsiasi interprete che può precedere il nome dello script, nonché il percorso completo dello script.

Dettagli: durante le operazioni DR, Full Stack DR tenta di riassegnare l'IP privato originale assegnato a un'istanza se il blocco CIDR della subnet di destinazione corrisponde al blocco CIDR della subnet di origine e se l'IP privato originale dell'istanza non è già assegnato.

Se si utilizza Full Stack DR per riposizionare tutti i nodi in un cluster OCFS2 e l'IP privato per uno qualsiasi dei nodi del cluster non può essere riassegnato, tali nodi del cluster verranno scollegati dal cluster OCFS2 dopo l'avvio dei nodi nella standby region.

Soluzione: assicurarsi che il blocco CIDR della subnet di destinazione corrisponda al blocco CIDR della subnet di origine e che tutti gli indirizzi IP privati necessari per i nodi del cluster siano disponibili nella subnet di destinazione.

Dettagli: dopo che Full Stack DR riposiziona un'istanza in un'area diversa, la pagina delle risorse dell'istanza potrebbe visualizzare il seguente messaggio per Accesso all'istanza:

Non siamo sicuri di come connettersi a un'istanza che utilizza questa immagine

Soluzione: ignorare questo messaggio. Le connessioni SSH all'istanza funzioneranno normalmente se si utilizza il file chiave SSH originale per connettersi e autenticare l'istanza.

Dettagli: dopo che Full Stack DR ha riposizionato un'istanza in un'area diversa, la pagina delle risorse dell'istanza potrebbe visualizzare informazioni errate per la parte Immagine del volume di avvio.

Ad esempio, nella colonna Informazioni immagine può essere visualizzato il seguente messaggio: Errore durante il caricamento dei dati

Soluzione: questo messaggio di errore riguarda la visualizzazione del nome dell'immagine, ma non influisce sul funzionamento dell'istanza o del relativo volume di avvio.

Dettagli: quando non c'è tempo di inattività per il comando nohup, l'esecuzione del comando run non riesce e il report sullo stato non riesce.

nohup sh enabler.sh  &> enabler.log &
sleep 10
exit 0

Dettagli: durante una transizione DR, quando i volumi a blocchi vengono spostati in un'area diversa, le impostazioni delle prestazioni (IOPS e throughput) non vengono replicate e ripristinate automaticamente. Potrebbe essere necessario riconfigurare queste impostazioni delle prestazioni.

Soluzione: dopo aver eseguito un piano DR, configurare manualmente l'impostazione delle prestazioni.

Dettagli: il caricamento su richiesta di un file zip creato in un computer Windows potrebbe non riuscire a caricare il contenuto del log. Il motivo dell'errore è che il file zip creato in Windows ha la stessa ora dell'ultima modifica dell'ora di creazione del file. Pertanto, quando il file viene decompresso, l'ora dell'ultima modifica del file viene impostata come ora di creazione del file che potrebbe essere precedente all'indicatore orario delle voci di log nel file di log. In tal caso, le voci di log con l'indicatore orario più recente dell'ora dell'ultima modifica del file non vengono caricate.

Un esempio del problema:

Indicatore orario sulla voce del log: 2020-10-12 21:12:06

Ora dell'ultima modifica del file di log: 2020-10-10 08:00:00

Soluzione: copiare i file di log in una nuova cartella e creare un file zip. Questa azione rende l'ora dell'ultima modifica del file più recente dell'indicatore orario delle voci di log. Utilizzare questo nuovo file zip per il caricamento su richiesta.

Utilizzando l'esempio precedente, dopo l'implementazione della soluzione alternativa:

Indicatore orario sulla voce del log: 2020-10-12 21:12:06

Ora dell'ultima modifica del file di log: 2021-03-31 08:00:00

Collegamento diretto a questo problema: Caricamento su richiesta da un computer Windows mediante un file zip

Dettagli: le cartelle contenenti più di 10.000 file possono causare l'uso elevato di risorse (memoria/archiviazione/CPU) da parte del Management Agent, con conseguente rallentamento della raccolta dei log, impatto su altre funzionalità del Management Agent e rallentamento del computer host.

Quando il plugin Log Analytics di Management Agent rileva cartelle di grandi dimensioni, al file mgmt_agent_logan.log di Management Agent viene aggiunto un messaggio simile al seguente esempio:

2020-07-30 14:46:51,653 [LOG.Executor.2388 (LA_TASK_os_file)-61850] INFO - ignore large dir /u01/service/database/logs. set property loganalytics.enable_large_dir to enable. 

Risoluzione: si consiglia di evitare cartelle di grandi dimensioni. Utilizzare un meccanismo di cleanup per rimuovere i file subito dopo la raccolta in modo che il Management Agent disponga di tempo sufficiente per raccoglierli di nuovo.

Tuttavia, se si desidera continuare a monitorare i log in cartelle di grandi dimensioni, è possibile abilitare il supporto eseguendo l'azione seguente:

sudo -u mgmt_agent echo "loganalytics.enable_large_dir=true" >> INSTALL_DIRECTORY/agent_inst/config/emd.properties

Sostituire INSTALL_DIRECTORY con il percorso della cartella agent_inst e riavviare l'agente.

Collegamento diretto a questo problema: Gestione speciale durante il monitoraggio dei log nelle cartelle di grandi dimensioni