Nuovo DBA nel cloud: Gestione di database SQL di Azure dopo la migrazione

Si applica a:Database SQL di Azure

La migrazione da un ambiente autogestito a un modello PaaS come il database SQL di Azure può essere complessa. Questo articolo illustra le funzionalità principali del database SQL di Azure per database singoli e in pool, consentendo di mantenere le applicazioni disponibili, efficienti, sicure e resilienti.

Le caratteristiche principali del database SQL di Azure includono:

• Monitoraggio del database con il portale di Azure
• Continuità aziendale e ripristino di emergenza (BCDR)
• Sicurezza e conformità
• Monitoraggio e manutenzione intelligenti del database
• Spostamento dei dati

Monitorare i database tramite il portale di Azure

Per le metriche e gli avvisi del monitoraggio di Azure, comprese le regole di avviso consigliate, si veda Monitorare database SQL di Azure con metriche e avvisi. Per altre informazioni sui livelli di servizio, vedere Panoramica del modello di acquisto basato su DTU e modello di acquisto basato su vCore.

È inoltre possibile configurare gli avvisi rispetto alle metriche delle prestazioni. Premere il pulsante Aggiungi avviso nella finestra Metrica. Seguire la procedura guidata per configurare l'avviso. È possibile avvisare se le metriche superano una determinata soglia o se la metrica scende al di sotto di una determinata soglia.

Ad esempio, se si prevede un aumento del carico di lavoro sul database, è possibile scegliere di configurare un avviso di posta elettronica ogni volta che il database raggiunge l'80% per una qualsiasi delle metriche delle prestazioni. È possibile usarlo come un preavviso per capire quando potrebbe essere necessario passare alle dimensioni di calcolo superiori.

Le metriche delle prestazioni consentono inoltre di determinare se è possibile effettuare il downgrade a dimensioni di calcolo inferiori. Tuttavia, prestare attenzione ai picchi o alle fluttuazioni dei carichi di lavoro prima di decidere di passare a dimensioni di calcolo inferiori.

Continuità aziendale e ripristino di emergenza (BCDR)

Le capacità di continuità aziendale e ripristino di emergenza consentono di continuare l'azienda in caso di emergenza. Questa situazione di emergenza potrebbe essere un evento a livello di database (ad esempio, un utente che elimina erroneamente una tabella fondamentale) o un evento a livello di data center (calamità regionale, ad esempio uno tsunami).

Come si creano e gestiscono i backup nel database SQL?

Il database SQL di Azure esegue automaticamente il backup dei database. La piattaforma effettua un backup completo ogni settimana, un backup differenziale ogni poche ore e un backup dei log ogni cinque minuti per garantire che il disaster recovery sia efficiente e la perdita di dati minima. Il primo backup completo viene eseguito non appena si crea un database. Puoi accedere a questi backup per un certo periodo chiamato periodo di retention, che varia a seconda del livello di servizio scelto. Puoi eseguire il ripristino a qualsiasi punto nel tempo compreso in questo periodo di conservazione utilizzando Point in Time Recovery (PITR).

Inoltre, la funzione di backup a lungo termine consente di conservare i file di backup fino a 10 anni e di ripristinare i dati di questi backup in qualsiasi momento di quel periodo. Azure conserva i backup del database in un'archiviazione con replica geografica per garantire resilienza in caso di una catastrofe regionale. Puoi anche ripristinare questi backup in qualsiasi regione Azure in qualsiasi momento durante il periodo di conservazione. Per altre informazioni, vedere Continuità aziendale nel database SQL di Azure.

Come si garantisce la continuità aziendale in caso di emergenza a livello di data center o di una catastrofe a livello di area?

Conserva i tuoi backup del database in uno storage geo-replicato per assicurarti che, durante un disastro regionale, tu possa ripristinare il backup in un'altra regione Azure. Questa funzionalità si chiama geo-restore. Per altre informazioni e tempi di ripristino geografico, vedere ripristino geografico per il database SQL di Azure.

Per i database cruciali, il database SQL di Azure offre la replica geografica attiva, che crea una copia secondaria con replica geografica del database originale in un'altra area. Ad esempio, se il database è inizialmente ospitato nell'area di Azure degli Stati Uniti occidentali ed è necessaria la resilienza in caso di emergenza, basta creare una replica geografica attiva del database degli Stati Uniti occidentali negli Stati Uniti orientali. Quando si verifica una calamità negli Stati Uniti occidentali, è possibile eseguire il failover nell'area degli Stati Uniti orientali.

Oltre alla geo-replicazione attiva, i gruppi di failover aiutano a gestire la replica e il failover di un gruppo di database. È possibile creare un gruppo di failover contente più database nella stessa area o in aree diverse. È quindi possibile avviare un failover di tutti i database del gruppo di failover nell'area secondaria. Per altre informazioni, vedere Panoramica dei gruppi di failover e procedure consigliate (database SQL di Azure).

Per ottenere resilienza ai guasti del datacenter o della zona di disponibilità, assicurarsi che la ridondanza della zona sia abilitata per il database o il pool elastico.

Monitora attivamente l'applicazione per rilevare un guasto grave e avvia un failover al sistema secondario. È possibile creare fino a 4 repliche geografiche attive di questo tipo in aree di Azure diverse. E non è finita qui. Puoi anche accedere a queste repliche geografiche attive secondarie in modalità di sola lettura, contribuendo a ridurre la latenza in uno scenario applicativo distribuito a livello geografico.

Che aspetto ha il ripristino di emergenza con il database SQL?

Puoi configurare la tua strategia di disaster recovery in pochi passaggi in database SQL di Azure quando usi gruppi di geo-replicazione attiva o failover. È comunque necessario monitorare l'applicazione e il suo database per rilevare eventuali emergenze a livello di area ed eseguire il failover nell'area secondaria per ripristinare la continuità aziendale.

Per altre informazioni, vedere Ripristino di emergenza del database SQL di Azure 101.

Sicurezza e conformità

database SQL di Azure fornisce sicurezza sia a livello di database che a livello di piattaforma. Puoi controllare e fornire la massima sicurezza della tua applicazione utilizzando le seguenti funzionalità:

• Identità e autenticazione (autenticazione SQL e autenticazione con Microsoft Entra ID).
• Attività di monitoraggio (controllo e rilevamento delle minacce).
• Protezione dei dati effettivi (Transparent Data Encryption [TDE] e Always Encrypted).
• Controllo dell'accesso a dati sensibili e privilegiati (sicurezza a livello di riga e mascheramento dinamico dei dati).

Microsoft Defender per il cloud offre la gestione centralizzata della sicurezza per carichi di lavoro in esecuzione in Azure, in locale e in altri cloud. È possibile visualizzare se la protezione essenziale del database SQL, ad esempio Controllo e Transparent Data Encryption [TDE] è configurata in tutte le risorse e creare criteri in base ai propri requisiti.

Quali metodi di autenticazione utente offre SQL Database?

SQL Database offre due metodi di autenticazione:

• Autenticazione Microsoft Entra
• Autenticazione SQL

Non è supportata l'autenticazione di Windows. Microsoft Entra ID è un servizio centralizzato di gestione delle identità e degli accessi. Microsoft Entra ID fornisce l'accesso Single Sign-On (SSO) al personale dell'organizzazione. Ciò significa che le credenziali vengono condivise tra i servizi Azure per un'autenticazione più semplice.

Microsoft Entra ID supporta l'autenticazione multifattore e può essere facilmente integrato con Microsoft Entra Connect Sync. Questa integrazione consente anche a database SQL di Azure di offrire autenticazione multifattore e account utente ospiti all'interno di un dominio Microsoft Entra. Se si utilizza già Active Directory in locale, è possibile attuare la federazione con Microsoft Entra ID per estendere la directory ad Azure.

L'autenticazione SQL supporta solo nome utente e password per autenticare gli utenti in qualsiasi database in un determinato server.

Come limitare o controllare l'accesso alla connettività al database?

Per organizzare la connettività per la tua applicazione, utilizza le seguenti tecniche:

• Regole del firewall
• Servizio di endpoint di rete virtuale
• IP riservati

Firewall

Per impostazione predefinita, il server SQL logico non consente tutte le connessioni ai database, tranne (opzionalmente) quelle provenienti da altri servizi Azure. Utilizzando una regola firewall, puoi aprire l'accesso al tuo server solo a entità (ad esempio, una macchina sviluppatrice) che approvi, permettendo l'indirizzo IP di quel computer a passare dal firewall. Puoi anche specificare un intervallo di IP che vuoi permettere l'accesso al server. Ad esempio, puoi aggiungere contemporaneamente indirizzi IP delle macchine sviluppatori nella tua organizzazione specificando un intervallo nella pagina delle impostazioni del firewall.

È possibile creare regole firewall a livello di server o database. Puoi creare regole firewall IP a livello server usando il portale Azure o usando SSMS. Per altre informazioni su come impostare una regola del firewall a livello di server e a livello di database, vedere Creare regole del firewall IP nel database SQL.

Punti finali del servizio

Di default, il tuo database è configurato per permettere ai servizi e alle risorse Azure di accedere a questo server, il che significa che qualsiasi macchina virtuale in Azure potrebbe tentare di connettersi al tuo database. Questi tentativi devono comunque essere autenticati. Se non si vuole che il database sia accessibile da indirizzi IP di Azure, è possibile disabilitare Consenti ai servizi e alle risorse di Azure di accedere a questo server. È anche possibile configurare gli endpoint servizio di rete virtuale.

Gli endpoint di servizio consentono di esporre le risorse di Azure critiche solo alla propria rete virtuale privata in Azure. Questa opzione elimina l'accesso pubblico alle risorse. Il traffico tra la rete virtuale e Azure rimane nella rete di backbone di Azure. Senza endpoint di servizio, si ottiene il routing dei pacchetti di tunneling forzato. La rete virtuale instrada il traffico Internet verso l'organizzazione e il traffico del servizio Azure lungo lo stesso percorso. Utilizzando gli endpoint di servizio, i pacchetti fluiscono direttamente dalla tua rete virtuale al servizio sulla rete backbone di Azure.

IP riservati

Un'altra opzione consiste nell'effettuare il provisioning degli indirizzi IP riservati per le VM e aggiungere gli indirizzi IP di quelle specifiche VM nelle impostazioni del firewall del server. Assegnando IP riservati, non è necessario aggiornare le regole del firewall cambiando indirizzi IP.

In quale porta devo connettermi al database SQL?

Il database SQL di Azure comunica sulla porta 1433. Per connetterti all'interno di una rete aziendale, devi aggiungere una regola outbound nelle impostazioni firewall della tua organizzazione. Come indicazione generale, evitare di esporre la porta 1433 all'esterno dei limiti di Azure.

Come è possibile monitorare e regolare l'attività nel server e nel database SQL?

Controllo del database SQL

Il controllo del database SQL di Azure registra gli eventi del database e li scrive in un file di log di controllo nell'account di archiviazione di Azure. La revisione è particolarmente utile se vuoi ottenere informazioni su potenziali violazioni della sicurezza e delle politiche, mantenere la conformità normativa e altro ancora. Fornisce report preconfigurati e una dashboard per darti una panoramica degli eventi che si verificano nel tuo database. Puoi definire e configurare le categorie di eventi che necessitano di revisione.

Puoi applicare queste politiche di audit a livello di database o a livello di server. Per ulteriori informazioni, vedere Abilitare il controllo del database SQL.

Rilevamento delle minacce

Utilizzando il rilevamento delle minacce, puoi agire su violazioni di sicurezza o di politiche scoperte tramite audit. Non è necessario essere esperti di sicurezza per affrontare potenziali minacce o violazioni nel sistema. Il rilevamento delle minacce ha anche alcune funzionalità integrate come il rilevamento tramite iniezione SQL, che è un modo comune di attaccare un'applicazione di database. Il rilevamento delle minacce esegue più set di algoritmi che rilevano potenziali vulnerabilità e attacchi SQL injection e modelli di accesso anomali al database , ad esempio l'accesso da una posizione insolita o da un'entità non familiare.

I responsabili della sicurezza o altri amministratori designati ricevono una notifica e-mail se viene rilevata una minaccia nel database. Ogni notifica contiene dettagli sull'attività sospetta e consigli su come eseguire altre indagini e mitigare la minaccia. Per informazioni su come attivare il rilevamento delle minacce, vedere Abilitare il rilevamento delle minacce.

Come si proteggono i dati in generale nel database SQL?

La crittografia offre un meccanismo sicuro per proteggere i dati riservati da intrusioni. I dati crittografati non sono di alcun uso per gli intrusi senza una chiave di decrittografia. In questo modo viene aggiunto un livello di protezione aggiuntivo ai livelli di sicurezza esistenti integrati nel database SQL. Due sono gli aspetti alla base della protezione dei dati nel database SQL:

• Dati inattivi nei file di dati e di log
• Dati in transito

Per impostazione predefinita, nel database SQL i dati inattivi nei file di dati e di log nel sottosistema di archiviazione sono completamente crittografati tramite Transparent Data Encryption [TDE]. Anche i backup sono crittografati. Con TDE non sono necessarie modifiche sul lato dell'applicazione che accede a questi dati. Crittografia e decrittografia si verificano in modo trasparente (da qui il nome).

Per proteggere i dati sensibili in transito e a riposo, il database SQL offre una funzionalità denominata Always Encrypted. Always Encrypted è una forma di crittografia lato client che crittografa le colonne sensibili nel database, in modo che siano in testo crittografato agli amministratori di database e agli utenti non autorizzati. Per iniziare, il server riceve i dati crittografati.

Anche la chiave per Always Encrypted è archiviata sul lato client, pertanto solo i client autorizzati possono decrittografare le colonne sensibili. Gli amministratori dei server e dei dati non possono visualizzare i dati sensibili, poiché le chiavi di crittografia vengono archiviate sul client. Always Encrypted crittografa le colonne sensibili nella tabella end-to-end, dai client non autorizzati al disco fisico.

Always Encrypted supporta confronti di uguaglianza, pertanto gli amministratori di database possono continuare a eseguire query sulle colonne crittografate come parte dei comandi SQL. Always Encrypted può essere usato con un'ampia gamma di opzioni di archiviazione di chiavi, ad esempio Azure Key Vault, l'archivio certificati di Windows e i moduli di protezione hardware locali.

Come è possibile limitare l'accesso ai dati sensibili nel database?

Ogni applicazione contiene dati sensibili nel database che devi proteggere dal fatto che siano visibili a tutti. Alcuni membri dell'organizzazione devono visualizzare questi dati, ma altri no. In questi casi, devi mascherare i tuoi dati sensibili o non esporli affatto. SQL Database offre due approcci per impedire agli utenti non autorizzati di visualizzare dati sensibili:

• Il mascheramento dinamico dei dati è una funzione di mascheramento dei dati che puoi utilizzare per limitare l'esposizione di dati sensibili mascherandola agli utenti non privilegiati. Definisci una regola di mascheramento che crea un modello di mascheramento. Ad esempio, puoi mostrare solo le ultime quattro cifre di un numero XXX-XX-0000 di identità nazionale e mascherare il resto con il X carattere. Con il mascheramento dinamico dei dati, identifichi quali utenti sono esclusi dalla regola di mascheramento e puoi vedere i dati non mascherati. Il mascheramento avviene al volo e sono disponibili varie funzioni di mascheramento per diverse categorie di dati.

• La sicurezza a livello di riga consente di controllare l'accesso a quel livello. Questa funzione nasconde alcune righe in una tabella del database in base all'utente che esegue la query (appartenenza al gruppo o contesto di esecuzione). La restrizione di accesso avviene sul livello database invece che in un livello applicativo, il che semplifica la logica dell'app. Si inizia creando un predicato che filtra le righe non esposte. Poi crei i criteri di sicurezza che definiscono chi ha accesso a queste righe. Infine, l'utente finale esegue la sua query e, a seconda dei privilegi dell'utente, o visualizza quelle righe limitate o non può vederle affatto.

Come si gestiscono le chiavi di crittografia nel cloud?

Sia Always Encrypted (crittografia lato client) sia la crittografia trasparente dei dati (crittografia a riposo) offrono opzioni di chiave gestite dal cliente . Ruota regolarmente le chiavi di crittografia. Scegli una frequenza di rotazione che sia in linea con le normative interne e i requisiti di conformità della tua organizzazione.

Transparent Data Encryption (TDE)

TDE utilizza una gerarchia a due chiavi. I dati di ogni database utente sono criptati da una chiave di crittografia asimmetrica AES-256 unica per database (DEK), che viene criptata con una chiave master RSA 2048 asimmetrica unica per il server. La chiave master può essere gestita:

• Automaticamente dal database SQL di Azure
• In alternativa, puoi utilizzare Azure Key Vault come archivio chiavi

Di default, database SQL di Azure gestisce la chiave master TDE. Se la tua organizzazione vuole il controllo sulla chiave mestra, usa Azure Key Vault come archivio delle chiavi. Con Azure Key Vault l'organizzazione assume il controllo sul provisioning delle chiavi, sulla rotazione e sulle autorizzazioni. La rotazione o la modifica del tipo di una chiave master TDE è rapida, poiché ricrittografa solo la DEK. Per le organizzazioni con separazione tra ruoli tra sicurezza e gestione dei dati, un amministratore della sicurezza può fornire il materiale delle chiavi per la chiave master TDE in Azure Key Vault e fornire un identificatore di chiave Azure Key Vault all'amministratore del database da utilizzare per la crittografia a riposo su un server. Key Vault è progettato in modo che Microsoft non possa vedere o estrarre le chiavi di crittografia. Si consegue anche una gestione centralizzata delle chiavi per l'organizzazione.

Sempre Crittografato

Always Encrypted utilizza anche una gerarchia a due chiavi. Una colonna di dati sensibili viene criptata da una chiave di crittografia AES a 256 colonne (CEK), che viene criptata da una chiave principale a colonna (CMK). I driver client forniti per Always Encrypted non hanno limitazioni sulla lunghezza delle chiavi master di colonna (CMK). Il valore crittografato della CEK viene archiviato nel database e la CMK viene archiviata in un archivio di chiavi attendibile, ad esempio l'archivio certificati di Windows, Azure Key Vault o un modulo di sicurezza hardware.

• Ruota sia il CEK che il CMK.

• La rotazione della CEK è un'operazione che dipende dalla quantità di dati e può richiedere molto tempo, a seconda delle dimensioni delle tabelle che contengono le colonne crittografate. Pianifica di conseguenza le rotazioni CEK.

• La rotazione CMK non interferisce con le prestazioni del database e può essere fatta con ruoli separati.

Il diagramma seguente mostra le opzioni degli archivi di chiavi per le chiavi master di colonna in Always Encrypted:

Come è possibile ottimizzare e proteggere il traffico tra l'organizzazione e il database SQL?

Il traffico di rete tra la tua organizzazione e il database SQL generalmente viene instradato attraverso la rete pubblica. Tuttavia, puoi ottimizzare questo percorso e renderlo più sicuro usando Azure ExpressRoute. ExpressRoute estende la tua rete aziendale sulla piattaforma Azure tramite una connessione privata, bypassando l'Internet pubblico. Si ottengono anche una maggiore sicurezza, affidabilità e ottimizzazione del routing che si traduce in latenze di rete inferiori e velocità più veloci rispetto a quelle che normalmente si riscontrano su Internet pubblico. Se hai intenzione di trasferire una porzione significativa di dati tra la tua organizzazione e Azure, usare ExpressRoute può portare benefici in termini di costo. Sono disponibili tre modelli di connettività diversi per la connessione dall'organizzazione ad Azure:

• Colocazione di Cloud Exchange
• Da qualsiasi origine a qualsiasi destinazione
• Point-to-Point

ExpressRoute consente anche di eseguire un burst fino a 2 volte il limite di larghezza di banda acquistato senza costi aggiuntivi. Puoi anche configurare la connettività tra le regioni usando ExpressRoute. Per un elenco dei provider di connettività ExpressRoute, vedere Partner ExpressRoute e località di peering. I seguenti articoli descrivono ExpressRoute in modo più dettagliato:

• Prerequisiti
• Flussi di lavoro

Il database SQL è conforme ai requisiti normativi e in che modo è utile per la conformità dell'organizzazione?

database SQL di Azure è conforme a una serie di esigenze normative. Per visualizzare le ultime normative che SQL Database soddisfa, visita il Microsoft Trust Center e consulta le conformità importanti per la tua organizzazione per verificare se SQL Database è incluso nei servizi Azure conformi. Anche se il database SQL è certificato come servizio conforme, contribuisce alla conformità del servizio dell'organizzazione, ma non lo garantisce automaticamente.

Monitoraggio e manutenzione intelligenti del database dopo la migrazione

Dopo aver migrato il tuo database in SQL Database, monitora il tuo database (ad esempio, controlla come è l'utilizzo delle risorse o controlli DBCC) e effettua una manutenzione regolare (ad esempio, ricostruire o riorganizzare indici, statistiche e altro ancora). Il database SQL usa le tendenze cronologiche e le metriche registrate e le statistiche per monitorare e gestire in modo proattivo il database, in modo che l'applicazione venga eseguita sempre in modo ottimale. In alcuni casi, il database SQL di Azure può eseguire automaticamente le attività di manutenzione a seconda delle impostazioni di configurazione. Sono tre gli aspetti alla base del monitoraggio nel database SQL:

• Monitoraggio e ottimizzazione delle prestazioni
• Ottimizzazione della sicurezza
• Ottimizzazione dei costi

Monitoraggio e ottimizzazione delle prestazioni

Utilizzando Query Performance Insights, puoi ottenere raccomandazioni personalizzate per il carico di lavoro del tuo database, così che le tue applicazioni possano continuare a funzionare a un livello ottimale. È anche possibile configurarlo in modo che questi consigli vengano applicati automaticamente, evitando di dover eseguire manualmente le attività di manutenzione. Utilizzando SQL Database Advisor, puoi implementare automaticamente le raccomandazioni degli indici in base al tuo carico di lavoro. Questa funzione si chiama Auto-Tuning. Le raccomandazioni si evolvono di pari passo con il carico di lavoro dell'applicazione per fornire quelle più pertinenti. È anche possibile esaminare manualmente queste raccomandazioni e applicarle a propria discrezione.

Ottimizzazione della sicurezza

SQL Database fornisce raccomandazioni di sicurezza pratiche per aiutarti a proteggere i tuoi dati. Offre inoltre il rilevamento delle minacce per identificare e indagare attività sospette nel database che possono rappresentare una minaccia potenziale per il database. La valutazione delle vulnerabilità è un servizio di scansione e reportistica di database che puoi utilizzare per monitorare lo stato di sicurezza dei tuoi database su larga scala e identificare rischi e deviazioni da una base di sicurezza che definisci. Dopo ogni scansione, fornisce una lista personalizzata di passaggi concreti e script di bonifica, insieme a un rapporto di valutazione che può aiutarti a soddisfare i requisiti di conformità.

Utilizzando Microsoft Defender per il cloud, puoi individuare raccomandazioni di sicurezza su tutte le parti e applicarle rapidamente.

Ottimizzazione dei costi

La piattaforma Azure SQL analizza la storia di utilizzo tra i database di un server per valutare e raccomandare opzioni di ottimizzazione dei costi. Questa analisi richiede in genere qualche settimana per analizzare e formulare raccomandazioni pratiche.

È possibile ricevere notifiche banner nel server SQL di Azure per le raccomandazioni sui costi. Per maggiori informazioni, consulta I pool elastici consentono di gestire e ridimensionare più database in database SQL di Azure e Pianificare e gestire i costi per database SQL di Azure.

Come si monitorano le prestazioni e l'utilizzo delle risorse nel database SQL?

Puoi monitorare le prestazioni e l'utilizzo delle risorse in SQL Database utilizzando i seguenti metodi:

Database watcher

Il database watcher raccoglie dati di monitoraggio approfonditi del carico di lavoro per offrire una visualizzazione dettagliata delle prestazioni, della configurazione e del funzionamento del database. Le dashboard nel portale di Azure offrono una visualizzazione in un unico riquadro dell'ambiente Azure SQL e una visualizzazione dettagliata di ogni risorsa monitorata. I dati vengono raccolti in un archivio dati centrale nell’ambito della sottoscrizione di Azure. È possibile eseguire query, analizzare, esportare, visualizzare i dati raccolti e integrarli con sistemi downstream.

Per altre informazioni su database watcher, consultare i seguenti articoli:

• Monitorare i carichi di lavoro di Azure SQL con il database watcher (anteprima)
• Guida introduttiva: Creare un watcher per monitorare Azure SQL (anteprima)
• Creare e configurare un watcher (anteprima)
• Raccolta di dati e set di dati del database watcher (anteprima)
• Analizzare i dati di monitoraggio del database watcher (anteprima)
• Domande frequenti sul database watcher

Portale di Azure

Il portale Azure mostra l'utilizzo di un database quando selezioni il database e selezioni il grafico nel pannello Panoramica. È possibile modificare il grafico per visualizzare varie metriche, tra cui percentuale di CPU, percentuale di DTU, percentuale I/O dei dati, percentuale di sessioni e percentuale delle dimensioni del database.

Da questo grafico è anche possibile configurare avvisi per risorsa. Questi avvisi ti permettono di rispondere alle condizioni delle risorse tramite un'email, scrivere su un endpoint HTTPS/HTTP o eseguire un'azione. Per ulteriori informazioni, consulta Creare avvisi per database SQL di Azure tramite il portale di Azure.

Viste a gestione dinamica

È possibile eseguire una query sulla vista a gestione dinamica sys.dm_db_resource_stats per ottenere la cronologia delle statistiche di utilizzo delle risorse dell'ultima ora e sulla vista del catalogo di sistema sys.resource_stats per ottenere la cronologia degli ultimi 14 giorni.

Informazioni dettagliate sulle prestazioni delle query

Informazioni dettagliate sulle prestazioni delle query consente di visualizzare una cronologia delle query che consumano più risorse e delle query di lunga durata per un database specifico. È possibile identificare TOP rapidamente le query in base all'utilizzo delle risorse, alla durata e alla frequenza di esecuzione. È possibile tenere traccia delle query e rilevare la regressione. Questa funzionalità richiede che Query Store sia abilitato e attivo per il database.

Si notino problemi di prestazioni: in che modo la metodologia di risoluzione dei problemi del database SQL è diversa da SQL Server?

La maggior parte delle tecniche di risoluzione dei problemi che usi per diagnosticare query e problemi di performance del database sono le stesse di SQL Server on-premise. database SQL di Azure utilizza lo stesso SQL motore di database. Tuttavia, le funzionalità di Azure ti aiutano a risolvere problemi e diagnosticare i problemi di prestazioni ancora più facilmente. Può anche eseguire alcune di queste azioni correttive per tuo conto e, in alcuni casi, correggerle automaticamente in modo proattivo.

Il tuo approccio alla risoluzione dei problemi di prestazioni può trarre notevole beneficio dall'utilizzo di funzionalità intelligenti come Query Performance Insight (QPI) e Database Advisor. La differenza nella metodologia è che non è più necessario fare il lavoro manuale di ricavare i dettagli essenziali che potrebbero aiutarti a risolvere il problema in questione. La piattaforma esegue il lavoro per conto dell'utente. Un esempio di questo lavoro è QPI. Usando QPI, puoi approfondire fino al livello della query e guardare le tendenze storiche per capire esattamente quando la query è regredita. Il Database Advisor ti dà raccomandazioni su cose che potrebbero aiutarti a migliorare le prestazioni complessive in generale, come indici mancanti, eliminazione di indici, parametrizzazione delle tue query e altro ancora.

Con la risoluzione dei problemi delle prestazioni, è importante identificare se il problema è solo l'applicazione o il database a influenzare le prestazioni della tua applicazione. Spesso il problema delle prestazioni risiede a livello dell'applicazione. Potrebbe trattarsi dell'architettura o dei criteri di accesso ai dati. Si supponga, ad esempio, di avere un'applicazione di tipo chatty sensibile alla latenza di rete. In questo caso, la tua applicazione ne rienta perché ci sono molte brevi richieste che vanno avanti e indietro ("chiacchierone") tra l'applicazione e il server. In una rete congestionata, questi viaggi di andata e ritorno si accumulano rapidamente. Per migliorare le prestazioni in questo caso, è possibile usare query batch, che consentono di ridurre la latenza di round trip e migliorare le prestazioni dell'applicazione.

Inoltre, se noti un degrado nelle prestazioni complessive del tuo database, puoi monitorare le viste di gestione dinamica sys.dm_db_resource_stats e sys.resource_stats per comprendere il consumo di CPU, IO e memoria. Le prestazioni potrebbero essere influenzate se il database è in stato di esaurimento delle risorse. Potrebbe essere necessario modificare le dimensioni di calcolo e/o il livello di servizio in base alle esigenze crescenti e ridotte del carico di lavoro.

Per un insieme completo di raccomandazioni per la regolazione di problemi di prestazioni, vedi Ottimizza il tuo database.

Come posso assicurarmi di utilizzare il livello di servizio e la dimensione di calcolo appropriati?

Database SQL offre due diversi modelli di acquisto: il precedente modello DTU e il più adattabile modello di acquisto vCore. Per altre informazioni, vedere Confrontare modelli di acquisto basati su vCore e DTU del database SQL di Azure.

È possibile monitorare il consumo di risorse di query e database in entrambi i modelli di acquisto. Per altre informazioni, si veda Monitorare e ottimizzare le prestazioni. Se noti che i tuoi database sono costantemente in esecuzione ad alto utilizzo, considera di scalare a una dimensione di calcolo più alta. Allo stesso modo, se non usi le risorse così tanto durante le ore di punta, considera di ridurre la dimensione di calcolo attuale. Puoi considerare di usare Automazione di Azure per scalare i tuoi database SQL secondo un programma.

Se hai un pattern di app SaaS o uno scenario di consolidamento di database, considera l'uso di un elastic pool per l'ottimizzazione dei costi. Un elastic pool è un ottimo modo per consolidare i database e ottimizzare i costi. Per maggiori informazioni sulla gestione di più database utilizzando un pool elastico, vedi Gestisci pool e database.

Con quale frequenza è necessario eseguire i controlli di integrità per il mio database?

Il database SQL può gestire automaticamente determinate classi di danneggiamento dei dati e senza perdita di dati. Il servizio utilizza queste tecniche integrate quando si presenta la necessità. Se ci sono problemi, SQL Database li affronta in modo proattivo. Come ulteriore livello di protezione, potresti scegliere di testare il ripristino del backup ed eseguire controlli di integrità. Per maggiori informazioni, consulta Data Integrity in database SQL di Azure.

La riparazione automatica delle pagine viene utilizzata per correggere pagine corrotte o con problemi di integrità dei dati. L'impostazione CHECKSUM verifica sempre l'integrità delle pagine del database. Per altre informazioni, vedere Integrità dei dati nel database SQL.

Spostamento dei dati dopo la migrazione

Come posso esportare e importare dati come file BACPAC da SQL Database utilizzando il portale Azure?

• Esportazione: è possibile esportare il database nel database SQL di Azure come file BACPAC dal portale di Azure:

  

• Importa: Puoi anche importare dati come file BACPAC nel tuo database in database SQL di Azure utilizzando il portale Azure:

  

Come si sincronizzano i dati tra il database SQL e SQL Server?

Per maggiori informazioni sulle alternative alla sincronizzazione dati, vedi Migra verso soluzioni alternative.

Contenuto correlato

• Monitorare e ottimizzare le prestazioni in database SQL di Azure e Istanza gestita di SQL di Azure