Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
In Azure Analysis Services un nodo rappresenta una macchina virtuale host in cui è in esecuzione una risorsa server. Alcune operazioni, ad esempio query a esecuzione prolungata, operazioni di aggiornamento e sincronizzazione con scalabilità orizzontale delle query, possono non riuscire se una risorsa server viene spostata in un nodo diverso. I messaggi di errore comuni in questo scenario includono quanto segue:
- "Si è verificato un errore durante il tentativo di individuare una richiesta XMLA a esecuzione prolungata. La richiesta potrebbe essere stata interrotta dall'aggiornamento del servizio o dal riavvio del server."
- "Il processo con ID '<guid>' per il modello '<database>' è stato annullato a causa di un errore del servizio (inattività) con il messaggio 'Annullamento della richiesta di aggiornamento perché era bloccata senza aggiornamenti.'" Si tratta di un problema interno del servizio. Inviare nuovamente il processo o inviare un ticket per ottenere assistenza se il problema si verifica ripetutamente."
Esistono molti motivi per cui le operazioni a esecuzione prolungata possono essere interrotte. Ad esempio, gli aggiornamenti in Azure quali:
- Patch del sistema operativo
- Aggiornamenti della sicurezza
- Aggiornamenti del servizio Azure Analysis Services
- Aggiornamenti di Service Fabric. Service Fabric è un componente della piattaforma usato da molti servizi cloud Microsoft, tra cui Azure Analysis Services.
Oltre agli aggiornamenti che si verificano nel servizio, si verifica uno spostamento naturale dei servizi tra i nodi dovuto al bilanciamento del carico. Gli spostamenti dei nodi sono una parte prevista di un servizio cloud. Azure Analysis Services tenta di ridurre al minimo gli effetti derivanti dagli spostamenti dei nodi, ma è impossibile eliminarli completamente.
Oltre agli spostamenti dei nodi, possono verificarsi altri errori. Ad esempio, un sistema di database dell'origine dati potrebbe essere offline o la connettività di rete viene persa. Se durante l'aggiornamento, una partizione ha 10 milioni di righe e si verifica un errore nella riga 9 milioni, non è possibile riavviare l'aggiornamento in corrispondenza del punto di errore. Il servizio deve essere avviato di nuovo dall'inizio.
Aggiornamento dell'API REST
Le interruzioni del servizio possono risultare complesse per operazioni a esecuzione prolungata, ad esempio l'aggiornamento dei dati. Azure Analysis Services include un'API REST per ridurre gli effetti negativi derivanti dalle interruzioni del servizio. Per altre informazioni, vedere Aggiornamento asincrono con l'API REST.
Oltre all'API REST, esistono altri approcci che è possibile usare per ridurre al minimo i potenziali problemi durante le operazioni di aggiornamento a esecuzione prolungata. L'obiettivo è evitare di dover riavviare l'operazione di aggiornamento dall'inizio ed eseguire invece gli aggiornamenti in batch più piccoli di cui è possibile eseguire il commit in fasi.
L'API REST consente questo riavvio, ma non consente la flessibilità completa della creazione e dell'eliminazione della partizione. Se uno scenario richiede operazioni di gestione dei dati complesse, la soluzione deve includere una forma di invio in batch nella logica. Ad esempio, l'uso di transazioni per elaborare i dati in più batch separati consente di non richiedere il riavvio dall'inizio, ma da un checkpoint intermedio.
Aumento delle repliche di query
Indipendentemente dal fatto che si usi la logica REST o personalizzata, le query dell'applicazione client possono comunque restituire risultati incoerenti o intermedi durante l'elaborazione dei batch. Se è necessario che le query dell'applicazione client restituiscano dati coerenti durante l'elaborazione e i dati del modello sono in uno stato intermedio, utilizzare la scalabilità orizzontale con repliche di query di sola lettura.
Usando repliche di query di sola lettura, mentre gli aggiornamenti vengono eseguiti in batch, gli utenti dell'applicazione client possono continuare a eseguire query sullo snapshot precedente dei dati nelle repliche di sola lettura. Al termine degli aggiornamenti, è possibile eseguire un'operazione di sincronizzazione per aggiornare le repliche di sola lettura.
Passaggi successivi
Aggiornamento asincrono con l'API REST
Scale-out di Azure Analysis Services
Disponibilità elevata di Azure Analysis Services
Linee guida per i tentativi per i servizi di Azure