Risoluzione dei problemi noti
Suggerisci modifiche
PDF
È necessario essere a conoscenza di alcuni problemi noti che potrebbero verificarsi quando si utilizza SnapManager e di come risolverli.
SnapManager per Oracle non riesce a identificare i profili in modalità cluster
Se il nome del profilo Cluster-Mode non è presente nel file cmode_profiles.config nella directory di installazione di SnapManager per Oracle, potrebbe essere visualizzato il seguente messaggio di errore:
Configurare il server DFM utilizzando il set di configurazione SnapDrive -nome_utente dfm nome_appliance.
Inoltre, durante l'aggiornamento di SnapManager per Oracle, se si elimina la cartella /opt/NetApp/smo/*, viene eliminato anche il file cmode_profiles.config con i nomi dei profili in modalità cluster. Questo problema genera anche lo stesso messaggio di errore.
Soluzione
Aggiorna il profilo: <profile_name> di aggiornamento del profilo smo
|
Se SnapManager per Oracle è installato nel percorso /opt/NetApp/smo/, il percorso del file è /opt/NetApp/smo/cmode_profile/cmode_profiles.config. |
Il server non si avvia
All'avvio del server, potrebbe essere visualizzato un messaggio di errore simile al seguente:
SMO-01104: Errore durante la chiamata del comando: SMO-17107: Impossibile avviare il server SnapManager sulla porta 8074 a causa dei seguenti errori: Indirizzo java.net.BindException: già in uso
Ciò potrebbe essere dovuto al fatto che le porte di ascolto SnapManager (27214 e 27215, per impostazione predefinita) sono attualmente in uso da un'altra applicazione.
Questo errore può verificarsi anche se il comando smo_server è già in esecuzione, ma SnapManager non rileva il processo esistente.
Soluzione
È possibile riconfigurare SnapManager o l'altra applicazione per utilizzare porte diverse.
Per riconfigurare SnapManager, modificare il seguente file: C: File di programma NetApp
Vengono assegnati i seguenti valori:
-
SMO Server.port=27214
-
Server SMO.rmiRegistry.port=27215
-
remote.registry.ocijdbc.port= 27215
Remote.registry.ocijdbc.port deve essere uguale a Server.rmiRegistry.port.
Per avviare il server SnapManager, attenersi alla seguente procedura:
-
Fare clic su Start > pannello di controllo > Strumenti di amministrazione > servizi.
-
È possibile avviare il server in tre modi:
-
Nel pannello di sinistra, fare clic su Start.
-
Fare clic con il pulsante destro del mouse su NetApp SnapManager 3.3 per Oracle e selezionare Avvia dal menu a discesa.
-
Fare doppio clic su NetApp SnapManager 3.3 per Oracle e nella finestra Proprietà visualizzata, fare clic su Start.
-
Impossibile gestire i nomi di destinazione del file di log dell'archivio se i nomi di destinazione fanno parte di altri nomi di destinazione
Durante la creazione di un backup del registro di archiviazione, se l'utente esclude una destinazione che fa parte di altri nomi di destinazione, vengono esclusi anche gli altri nomi di destinazione.
Ad esempio, si supponga che siano disponibili tre destinazioni da escludere: E: Arch, G: Arch e H: Arch. Durante la creazione del backup del file di log dell'archivio, se si esclude e: Utilizzando il comando
smo backup create -profile almsamp1 -data -online -archivelogs -exclude-dest E:\\arch
, SnapManager per Oracle esclude tutte le destinazioni che iniziano con e:.
Soluzione
-
Aggiungere un separatore di percorso dopo aver configurato le destinazioni in v€archive_dest. Ad esempio, modificare e: In e:.
-
Durante la creazione di un backup, includere le destinazioni invece di escludere qualsiasi destinazione.
Le dimensioni del database del repository aumentano con il tempo e non con il numero di backup
Le dimensioni del database del repository aumentano con il tempo perché le operazioni SnapManager inseriscono o eliminano i dati all'interno dello schema nelle tabelle del database del repository, il che comporta un elevato utilizzo dello spazio dell'indice.
Soluzione
È necessario monitorare e ricostruire gli indici in base alle linee guida Oracle per controllare lo spazio occupato dallo schema del repository.
Non è possibile accedere all'interfaccia grafica di SnapManager e le operazioni SnapManager non vengono eseguite quando il database del repository non è attivo
Le operazioni SnapManager non riescono e non è possibile accedere alla GUI quando il database del repository non è attivo.
La tabella seguente elenca le diverse azioni che si desidera eseguire e le relative eccezioni:
Operazioni |
Eccezioni |
Apertura di un repository chiuso |
Il seguente messaggio di errore viene registrato in SM_gui.log: [WARN ]: SMO-01106: Si è verificato un errore durante la query del repository: CLOSED Connection java.sql.SQLException: CLOSED Connection. |
Aggiornare un repository aperto premendo F5 |
Nella GUI viene visualizzata un'eccezione di repository e viene inoltre registrato un NullPointerException nel file sm_gui.log. |
Aggiornamento del server host |
Nel file sumo_gui.log viene registrata un'eccezione NullPointerException. |
Creazione di un nuovo profilo |
Nella finestra Configurazione profilo viene visualizzata un'eccezione NullPointerException. |
Aggiornamento di un profilo |
La seguente eccezione SQL viene registrata in SM_gui.log: [WARN ]: SMO-01106: Errore durante la query del repository: Connessione chiusa. |
Accesso a un backup |
Il seguente messaggio di errore viene registrato in SM_gui.log: Impossibile inizializzare una raccolta in modo non corretto. |
Visualizzazione delle proprietà dei cloni |
Il seguente messaggio di errore viene registrato in sm_gui.log e sumo_gui.log: Impossibile inizializzare una raccolta in modo non corretto. |
Soluzione
È necessario assicurarsi che il database del repository sia in esecuzione quando si desidera accedere alla GUI o eseguire operazioni SnapManager.
Impossibile creare file temporanei per il database clonato
Quando i file tablespace temporanei del database di destinazione vengono posizionati in punti di montaggio diversi dal punto di montaggio dei file di dati, l'operazione di creazione del clone ha esito positivo, ma SnapManager non riesce a creare file temporanei per il database clonato.
Soluzione
Eseguire una delle seguenti operazioni:
-
Assicurarsi che il database di destinazione sia disposto in modo che i file temporanei siano posizionati nello stesso punto di montaggio dei file di dati.
-
Creare o aggiungere manualmente file temporanei nel database clonato.
Il backup del database Standby Data Guard non riesce
Se una posizione del registro di archiviazione è configurata con il nome del servizio del database primario, il backup del database di standby Data Guard non riesce.
Soluzione
Nella GUI, è necessario deselezionare specificare la posizione del registro archivio esterno corrispondente al nome del servizio del database primario.