Nuovo amministratore di database (DBA) nel cloud: gestione del database SQL di Azure dopo la migrazione

Si applica a: Database SQL di Azure

Il passaggio da un ambiente tradizionale, gestito e controllato in autonomia, a un ambiente PaaS può risultare inizialmente piuttosto complesso. Gli sviluppatori di app o i DBA hanno bisogno di conoscere le funzionalità principali della piattaforma che contribuiscono a mantenere l'applicazione sempre disponibile, efficiente e flessibile. Questo articolo mira esattamente a questo. L'articolo organizza in modo sintetico le risorse e propone alcune indicazioni su come usare al meglio le principali funzionalità del database SQL di Azure con database singoli e in pool per gestire e mantenere efficiente l'applicazione, nonché per ottenere risultati ottimali nel cloud. Destinatari tipici di questo articolo:

• Utenti che valutano la migrazione delle applicazioni al database SQL di Azure - Modernizzazione delle applicazioni.
• Utenti in fase di migrazione delle applicazioni - Scenari di migrazione in corso.
• Utenti che hanno recentemente completato la migrazione al database SQL di Azure – nuovo DBA nel cloud.

Questo articolo illustra alcune delle caratteristiche principali del database SQL di Azure come piattaforma immediatamente utilizzabile quando si lavora con i database singoli e i database in pool elastici. Sono le seguenti:

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

Nota

Microsoft Entra ID era precedentemente conosciuto come Azure Active Directory (Azure AD).

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 gli articoli modello di acquisto basato su DTU o 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 scegliere di ricevere un avviso se la metrica supera una determinata soglia o 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 funzionalità della continuità aziendale e del ripristino di emergenza consentono di proseguire normalmente l'attività aziendale 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 creare e gestire i backup nel database SQL

Non vengono creati backup nel database SQL di Azure perché non è necessario. Il database SQL esegue automaticamente il backup dei database, pertanto non è più necessario preoccuparsi di pianificare, eseguire e gestire i backup. La piattaforma esegue un backup completo ogni settimana, backup differenziali a intervalli di poche ore e un backup del log ogni 5 minuti per garantire un ripristino di emergenza efficiente e una perdita di dati minima. Il primo backup completo viene eseguito non appena si crea un database. Questi backup sono disponibili per un determinato periodo, chiamato "periodo di conservazione", che varia a seconda del livello di servizio scelto. Il database SQL offre la possibilità di eseguire un ripristino in qualsiasi punto nel tempo all'interno di questo periodo di conservazione con il recupero temporizzato.

La funzionalità di conservazione a lungo termine consente anche di mantenere i file di backup per un periodo più lungo, nello specifico fino a 10 anni, ed eseguire il ripristino da questi backup in qualsiasi punto nel periodo. I backup dei database vengono quindi mantenuti in una risorsa di archiviazione con replica geografica per garantire resilienza da calamità regionali. È anche possibile ripristinare questi backup in un'area di Azure in qualsiasi punto nel tempo entro il periodo di conservazione. Per ulteriori informazioni, vedere Panoramica sulla continuità aziendale.

Come garantire la continuità aziendale in caso di emergenza a livello di data center o di catastrofe

I backup dei database sono archiviati in un'archiviazione con replica geografica per garantire, in caso di emergenza a livello di area, la possibilità di ripristinare il backup in un'altra area di Azure. Questo processo è noto come ripristino geografico. L'obiettivo del punto di ripristino (RPO) per il ripristino geografico è in genere < 1 ora e il tempo di recupero stimato (ERT) varia da pochi minuti ad alcune ore.

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 replica geografica attiva, i gruppi di failover offrono un modo pratico per 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 nel gruppo di failover dell'area secondaria. Per ulteriori informazioni, vedere Gruppi di failover.

Per ottenere resilienza per errori di data center e zone di disponibilità, assicurarsi che la ridondanza di zona sia abilitata per il database o il pool elastico.

Monitorare attivamente l'applicazione per rilevare emergenze e avviare un failover nel database secondario. È possibile creare fino a 4 repliche geografiche attive di questo tipo in aree di Azure diverse. E non è finita qui. È anche possibile accedere in sola lettura a queste repliche geografiche attive secondarie. Questa situazione risulta molto utile per ridurre la latenza per uno scenario di applicazione con distribuzione geografica.

Come si presenta il ripristino di emergenza con il database SQL

È possibile eseguire la configurazione e la gestione del ripristino di emergenza con pochi passaggi nel database SQL di Azure quando si usa la replica geografica attiva o i gruppi di 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 ulteriori informazioni, vedere ripristino di emergenza 101 per il database SQL di Azure.

Sicurezza e conformità

Il database SQL tiene in gran conto sicurezza e privacy. La sicurezza nel database SQL è disponibile a livello di database e di piattaforma e risulta più comprensibile se suddivisa in vari livelli. A ogni livello è possibile controllare e garantire la sicurezza ottimale dell'applicazione. I livelli sono:

• Identità e autenticazione (autenticazione di SQL) e autenticazione con Microsoft Entra ID (in precedenza Azure Active Directory).
• Attività di monitoraggio (controllo e rilevamento delle minacce).
• Protezione dei dati effettivi (Transparent Data Encryption [TDE] e Always Encrypted [AE]).
• Controllo dell'accesso ai dati sensibili e con privilegi (sicurezza a livello di riga e Dynamic Data Masking).

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 in tutte le risorse è configurata la protezione essenziale del database SQL, ad esempio controllo e Transparent Data Encryption [TDE], e creare criteri in base a requisiti personalizzati.

Quali metodi di autenticazione degli utenti vengono offerti nel database SQL

Nel database SQL sono disponibili 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. È molto efficace per fornire l'accesso Single Sign-On (SSO) a tutto il personale dell'organizzazione. Ciò significa che le credenziali vengono condivise tra i servizi di Azure per semplificare l'autenticazione.

Microsoft Entra ID supporta l'autenticazione a più fattori e può essere facilmente integrato con Windows Server Active Directory. Questo consente al database SQL e ad Azure Synapse Analytics di offrire l'autenticazione a più fattori e gli account utente guest all'interno di un dominio di 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.

Se…	Database SQL / Azure Synapse Analytics
È stato usato Active Directory in SQL Server in locale	Eseguire la federazione di AD con Microsoft Entra ID e usare l'autenticazione di Microsoft Entra. La federazione consente di usare l'accesso Single Sign-On.
È necessario applicare l'autenticazione a più fattori	Richiedere l'autenticazione a più fattori come criterio tramite l'accesso condizionale di Microsoft e usare l'autenticazione a più fattori di Microsoft Entra.
È stato effettuato l'accesso a Windows con le credenziali di Microsoft Entra da un dominio federato	Usare l'autenticazione integrata di Microsoft Entra.
Si è connessi a Windows con le credenziali di un dominio non federato con Azure	Usare l'autenticazione integrata di Microsoft Entra.
Si dispone di servizi di livello intermedio che devono connettersi al database SQL o ad Azure Synapse Analytics	Usare l'autenticazione integrata di Microsoft Entra.
Disporre di un requisito tecnico per l'uso dell'autenticazione SQL	Usare l'autenticazione in SQL

Come limitare o controllare l'accesso di connettività al database

Esistono diverse tecniche a disposizione che è possibile usare per conseguire un'organizzazione di connettività ottimale per l'applicazione.

• Regole del firewall
• Endpoint di servizio di rete virtuale
• IP riservati

Firewall

Un firewall impedisce l'accesso al server da un'entità esterna, consentendo solo a entità specifiche l'accesso al server. Per impostazione predefinita, vengono rifiutate tutte le connessioni ai database all'interno del server, ad eccezione delle connessioni (optionally7) in entrata da altri servizi di Azure. Con una regola del firewall è possibile aprire l'accesso al server solo alle entità (ad esempio, un computer per sviluppatori) approvate, consentendo all'indirizzo IP del computer di attraversare il firewall. Consente anche di specificare un intervallo di indirizzi IP a cui si intende consentire l'accesso al server. È ad esempio possibile aggiungere in una sola volta gli indirizzi IP del computer per sviluppatori specificando un intervallo nella pagina Impostazioni del firewall.

È possibile creare regole firewall a livello di server o database. Le regole del firewall IP a livello di server possono essere create usando il portale di Azure oppure con SSMS. Per ulteriori informazioni su come impostare una regola del firewall a livello di server e database, vedere: Creare regole del firewall IP nel database SQL.

Endpoint di servizio

Per impostazione predefinita, il database è configurato per "consentire ai servizi e alle risorse di Azure di accedere al server", il che significa che qualsiasi macchina virtuale in Azure potrebbe tentare di connettersi al database. Questi tentativi devono comunque essere autenticati. Se non si intende rendere il database accessibile da parte di eventuali indirizzi IP di Azure, è possibile disabilitare l'opzione di "consentire ai servizi e alle risorse di Azure di accedere al server". È anche possibile configurare gli endpoint di servizio di rete virtuale.

Gli endpoint di servizio consentono di esporre le risorse cruciali di Azure solo alla rete privata virtuale in Azure. In questo modo si elimina essenzialmente l'accesso pubblico alle risorse. Il traffico tra la rete virtuale e Azure rimane nella rete di backbone di Azure. Senza gli endpoint di servizio si ottiene il routing dei pacchetti con tunneling forzato. La rete virtuale forza il traffico Internet nell'organizzazione e il traffico del servizio Azure in modo che segua lo stesso route. Con gli endpoint di servizio è possibile ottimizzare questo processo, perché i pacchetti seguono il flusso direttamente dalla rete virtuale al servizio nella rete di 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. L'assegnazione degli indirizzi IP riservati evita di dover aggiornare le regole firewall quando si modificano gli indirizzi IP.

Con quale porta è possibile connettersi al database SQL

La porta 1433. Il database SQL comunica attraverso questa porta. Per connettersi da una rete aziendale, è necessario aggiungere una regola in uscita nelle impostazioni del firewall dell'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

Con il database SQL è possibile attivare il controllo per rilevare gli eventi di database. Il servizio di controllo del database SQL registra gli eventi che si verificano nel database e li registra in un file di log di controllo nell'account di Archiviazione di Azure dell'utente. Il controllo è particolarmente utile se si desidera ottenere informazioni dettagliate su potenziali violazioni di sicurezza e policy, mantenere la conformità normativa ecc. Consente di definire e configurare determinate categorie di eventi che si ritiene necessitino di controllo e, sulla base di ciò, è possibile ottenere report preconfigurati e una dashboard per avere una panoramica degli eventi che si verificano nel database. È possibile applicare questi criteri di controllo a livello di database o server. Per una guida su come attivare il controllo per il server/database, vedere: Abilitare il controllo del database SQL.

Rilevamento delle minacce

Con il rilevamento delle minacce è possibile intervenire in modo molto semplice sulle violazioni in termini di sicurezza o criteri individuate con il controllo. Non è necessario essere esperti di sicurezza per affrontare potenziali minacce o violazioni nel sistema. Il rilevamento delle minacce include anche alcune funzionalità incorporate come il rilevamento di attacchi SQL injection. Un attacco SQL injection è un tentativo di modificare o compromettere i dati e un modo molto comune per attaccare in genere un'applicazione di database. Il rilevamento delle minacce esegue vari set di algoritmi che rilevano potenziali vulnerabilità e attacchi SQL injection, nonché modelli anomali di accesso al database (ad esempio, accesso da una posizione insolita o da un'entità di sicurezza sconosciuta). 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 scoprire come attivare il rilevamento delle minacce, vedere: Abilitare il rilevamento delle minacce.

Come proteggere 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:

• I dati inattivi nei file di log e di dati
• I dati in elaborazione

Nel database SQL, per impostazione predefinita, i dati inattivi nei file di log e di dati nel sottosistema di archiviazione sono sempre interamente crittografati con Transparent Data Encryption [TDE]. Anche i backup sono crittografati. Con TDE non sono necessarie modifiche sul lato applicazione che accede a questi dati. Crittografia e decrittografia si verificano in modo trasparente (da qui il nome). Per proteggere i dati sensibili in elaborazione e inattivi, il database SQL include una funzionalità denominata Always Encrypted (AE). Always Encrypted è un tipo di crittografia lato client che crittografa le colonne sensibili nel database (in modo che siano in testo crittografato per gli amministratori di database e gli 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 oggi i confronti delle uguaglianze, pertanto i DBA possono continuare a eseguire query sulle colonne crittografate nell'ambito 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.

Caratteristiche	Always Encrypted	Transparent Data Encryption
Intervallo di crittografia	End-to-end	Dati inattivi
Il server può accedere a dati sensibili	No	Sì, poiché la crittografia è per i dati inattivi
Operazioni T-SQL consentite	Confronto di uguaglianza	L'intera superficie di attacco T-SQL è disponibile
Modifiche all'app richieste per usare la funzionalità	Minima	Estremamente minime
Granularità di crittografia	A livello di colonna	A livello di database

Come limitare l'accesso ai dati sensibili nel database

Ogni applicazione include quantità specifiche di dati sensibili nel database che non devono essere visibili a chiunque. Alcuni membri del personale all'interno dell'organizzazione devono essere in grado di visualizzare questi dati, a differenza di altri. Un esempio è rappresentato dai salari dei dipendenti. Un manager deve poter accedere alle informazioni salariali dei suoi dipendenti diretti, mentre i singoli membri del team non dovrebbero avere accesso alle informazioni salariali dei loro colleghi. Un altro scenario è rappresentato da sviluppatori di dati che potrebbero interagire con dati sensibili durante le fasi di sviluppo o test, ad esempio i codici fiscali dei clienti. Anche queste informazioni non devono essere esposte allo sviluppatore. In questi casi, i dati sensibili devono essere mascherati o addirittura non esposti. Per impedire a utenti non autorizzati di visualizzare dati sensibili, il database SQL offre due approcci di questo tipo:

Dynamic Data Masking è una funzionalità di mascheramento dei dati che limita l'esposizione a dati sensibili mascherandoli agli utenti sprovvisti di privilegi sul lato applicazione. Definire una regola di mascheramento che possa creare criteri (ad esempio, per visualizzare solo le ultime quattro cifre di un codice fiscale: XXX-XX-0000 e mascherare le altre cifre con X) e identificare gli utenti che devono essere esclusi dalla regola di mascheramento. Il mascheramento avviene in tempo reale e sono disponibili varie funzioni di mascheramento per categorie di dati diverse. Dynamic Data Masking consente di rilevare automaticamente i dati sensibili nel database e applicarvi il mascheramento.

La sicurezza a livello di riga consente di controllare l'accesso a livello di riga. In altre parole, alcune righe in una tabella di database in base all'utente che esegue la query (appartenenza a un gruppo o contesto di esecuzione) sono nascoste. La limitazione dell'accesso viene eseguita a livello di database anziché a livello di applicazione, per semplificare la logica dell'app. Per iniziare, creare un predicato di filtro per escludere le righe che non devono essere esposte e i criteri di sicurezza che definiscono gli utenti con accesso a queste righe. Infine, l'utente finale esegue la query e, a seconda dei privilegi dell'utente, visualizza o meno le righe con restrizioni.

Come gestire le chiavi di crittografia nel cloud

Sono disponibili opzioni di gestione delle chiavi per Always Encrypted (crittografia lato client) e Transparent Data Encryption (crittografia dei dati inattivi). È consigliabile ruotare regolarmente le chiavi di crittografia. La frequenza di rotazione deve essere allineata alle normative interne e ai requisiti di conformità dell'organizzazione.

Transparent Data Encryption (TDE)

In TDE è presente una gerarchia a due chiavi. I dati in ogni database utente vengono crittografati con una chiave di crittografia simmetrica AES-256 (chiave DEK) univoca per il database, che a sua volta viene crittografata da una chiave master asimmetrica RSA 2048 univoca per il server. La chiave master può essere gestita:

• Automaticamente dalla piattaforma - Database SQL.
• Usando Azure Key Vault come archivio delle chiavi.

Per impostazione predefinita, la chiave master per Transparent Data Encryption viene gestita dal servizio di database SQL per praticità. Se l'organizzazione intende gestire la chiave master, è disponibile un'opzione per utilizzare 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 il cambio del tipo di una chiave master TDE è un processo rapido, poiché ripete solo la crittografia della chiave di crittografia del database. Per le organizzazioni con distinzione dei ruoli tra sicurezza e gestione dei dati, un amministratore della sicurezza può effettuare il provisioning del materiale per la chiave master di TDE in Azure Key Vault e fornire un identificatore di chiave di Azure Key Vault all'amministratore del database da usare per la crittografia dei dati inattivi in 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.

Always Encrypted

In Always Encrypted è presente anche una gerarchia a due chiavi. Una colonna di dati sensibili viene crittografata con una chiave di crittografia di colonna (CEK) AES 256, che a sua volta viene crittografata da una chiave master di colonna (CMK). I driver del client forniti per Always Encrypted non presentano limitazioni di lunghezza per le chiavi master di colonna. Il valore crittografato della chiave di crittografia di colonna viene archiviato nel database e quello della chiave master di colonna in un archivio di chiavi attendibile, ad esempio l'archivio certificati di Windows, Azure Key Vault e i moduli di protezione hardware locali.

• È possibile alternare sia la chiave di crittografia di colonna sia la chiave master di colonna.
• La rotazione delle chiavi di crittografia di colonna è un'operazione relativa alla dimensione dei dati e il tempo può essere un fattore importante, in base alle dimensioni delle tabelle contenenti le colonne crittografate. È dunque prudente pianificare di conseguenza la rotazione delle chiavi di crittografia di colonna.
• La rotazione delle chiavi master di colonna, invece, non interferisce con le prestazioni del database e può essere eseguita con ruoli separati.

Il diagramma seguente illustra le opzioni di archivio 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 l'organizzazione e il database SQL viene in genere instradato sulla rete pubblica. Tuttavia, se si sceglie di ottimizzare questo percorso per renderlo più sicuro, è possibile valutare Azure ExpressRoute. In sostanza, ExpressRoute consente di estendere la rete aziendale alla piattaforma Azure tramite una connessione privata. In questo modo si evita l'Internet pubblico. Si conseguono anche livelli superiori di sicurezza, affidabilità e ottimizzazione del routing, che si traducono in minori latenze di rete e velocità più elevata rispetto a quanto si verifica nell'Internet pubblico. Se si intende trasferire un blocco consistente di dati tra l'organizzazione e Azure, l'uso di ExpressRoute può risultare vantaggioso in termini economici. Sono disponibili tre modelli di connettività diversi per la connessione dall'organizzazione ad Azure:

• Condivisione percorso per Cloud Exchange
• Any-to-any
• Point-to-Point

ExpressRoute consente anche di raddoppiare il limite di larghezza di banda acquistato senza alcun costo aggiuntivo. È anche possibile configurare la connettività tra più aree con ExpressRoute. Per visualizzare un elenco dei provider di connettività ExpressRoute, vedere: Partner e località di peering per ExpressRoute. Gli articoli seguenti descrivono ExpressRoute in modo più dettagliato:

• Introduzione a ExpressRoute
• Prerequisiti
• Flussi di lavoro

Il database SQL è conforme ai requisiti normativi e in che modo questo facilita la conformità dell'organizzazione

Il database SQL rispetta una serie di conformità normative. Per visualizzare il set più recente di conformità soddisfatte, visitare il Centro protezione di Microsoft ed eseguire il drill-down nelle conformità importanti per l'organizzazione per capire se il database SQL sia incluso nei servizi conformi di Azure. È importante notare che, sebbene il database SQL sia certificato come servizio conforme, esso agevola la conformità del servizio dell'organizzazione, ma non la garantisce automaticamente.

Monitoraggio e manutenzione intelligenti del database dopo la migrazione

Dopo aver eseguito la migrazione del database al database SQL, procedere al monitoraggio del database (ad esempio, verificare l'utilizzo delle risorse o i controlli DBCC) ed eseguire una manutenzione regolare (ad esempio, ricreare o riorganizzare gli indici, le statistiche e così via). Fortunatamente, il database SQL è intelligente nel senso che usa le tendenze cronologiche e le metriche e le statistiche registrate per contribuire in modo proattivo al monitoraggio e alla gestione del database, in modo che l'applicazione venga sempre eseguita 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

Con Informazioni dettagliate prestazioni query è possibile ottenere raccomandazioni personalizzate per il carico di lavoro del database in modo che le applicazioni vengano sempre eseguite a un livello ottimale. È anche possibile configurarlo in modo che questi consigli vengano applicati automaticamente, evitando di dover eseguire manualmente le attività di manutenzione. Con Advisor per database SQL, è possibile implementare automaticamente consigli relativi agli indici in base al carico di lavoro. Questo processo è definito "ottimizzazione automatica". 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

Il database SQL offre raccomandazioni di sicurezza utilizzabili per consentire di proteggere i dati e il rilevamento delle minacce per identificare ed esaminare attività sospette del database che potrebbero rappresentare una potenziale minaccia. La valutazione della vulnerabilità SQL è un servizio di analisi e reporting di database che consente di monitorare lo stato di sicurezza dei database su larga scala e identificare i rischi di sicurezza e la deviazione da una baseline della sicurezza definita dall'utente. Al termine di ogni analisi vengono forniti un elenco personalizzato di passaggi eseguibili e gli script di correzione, nonché un report di valutazione che può essere usato per consentire di rispettare i requisiti di conformità.

Con Microsoft Defender per il cloud, è possibile identificare i consigli sulla sicurezza tra le bacheche e applicarli rapidamente.

Ottimizzazione dei costi

La piattaforma SQL di Azure analizza la cronologia di utilizzo tra i database in un server per valutare e consigliare 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.
• I pool elastici sono un'opzione di questo tipo. Per maggiori informazioni, si veda I pool elastici consentono di gestire e dimensionare più database nel database SQL di Azure.
• Per altre informazioni, si veda Pianificazione e gestione dei costi per database SQL di Azure.

Come monitorare le prestazioni e l'uso delle risorse nel database SQL di Azure

È possibile monitorare le prestazioni e l'uso delle risorse nel database SQL con i metodi seguenti:

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. I clienti possono eseguire query, analizzarle, esportarle, visualizzarle e integrarle 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)
• Avvio rapido: Creare un database watcher per monitorare Azure SQL (anteprima)
• Creare e configurare un database 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

Azure portal

Il portale di Azure mostra l'uso di un database selezionandolo e selezionando il grafico nel riquadro 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 consentono di rispondere alle condizioni delle risorse con un messaggio e-mail, scrivere in un endpoint HTTPS/HTTP o eseguire un'azione. Per altre informazioni, vedere Creare avvisi.

DMV

È possibile eseguire una query nella DMV sys.dm_db_resource_stats per restituire la cronologia delle statistiche sull'uso delle risorse dell'ultima ora e la vista del catalogo di sistema sys.resource_stats per restituire la cronologia degli ultimi 14 giorni.

Informazioni dettagliate prestazioni query

Informazioni dettagliate prestazioni query consente di visualizzare una cronologia delle query principali a livello di uso delle risorse e delle query con esecuzione prolungata per un database specifico. È possibile identificare rapidamente le query principali in base all'uso 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.

Sto riscontrando problemi di prestazioni: in che modo la metodologia di risoluzione dei problemi del database SQL differisce da SQL Server?

Una parte significativa delle tecniche di risoluzione dei problemi che verrebbero usate per diagnosticare problemi di query e prestazioni del database rimane invariata. Dopotutto, lo stesso motore di database alimenta il cloud. Tuttavia, la piattaforma, vale a dire il database SQL di Azure, include "intelligenza" integrata. Consente di risolvere e diagnosticare i problemi di prestazioni anche più facilmente. Può inoltre eseguire alcune di queste azioni correttive per conto dell'utente e, in alcuni casi, correggerli automaticamente in modo proattivo.

L'approccio alla risoluzione dei problemi delle prestazioni può offrire vantaggi significativi grazie all'utilizzo di funzionalità intelligenti, ad esempio Informazioni dettagliate prestazioni query (QPI) e Advisor per database insieme, pertanto la differenza di metodologia differisce a tal proposito: non è più necessario eseguire l'attività manuale di recupero dei dettagli essenziali che consentirebbero di risolvere il problema in questione. La piattaforma esegue il lavoro per conto dell'utente. Un esempio a riguardo è QPI, che consente di eseguire il drill-down a livello di query, esaminare le tendenze cronologiche e individuare il momento esatto in cui la query è stata sottoposta a regressione. Advisor per database offre raccomandazioni su elementi che potrebbero migliorare in generale le prestazioni complessive, ad esempio indici mancanti, eliminazione degli indici, parametrizzazione delle query e così via.

Per la risoluzione dei problemi di prestazioni, è importante stabilire se a impattare sulle prestazioni sia solo l'applicazione o il database che la supporta. Spesso il problema delle prestazioni risiede a livello dell'applicazione. Potrebbe trattarsi dell'architettura o dei criteri di accesso ai dati. Si consideri ad esempio di avere un'applicazione "frammentata" sensibile alla latenza di rete. In questo caso, l'applicazione risente del traffico eccessivo di brevi richieste in entrata e in uscita ("frammentazione") tra l'applicazione e il server e, in una rete congestionata, questo traffico si accumula rapidamente. Per migliorare le prestazioni, è possibile usare gli invii di query in batch. L'uso dei batch risulta particolarmente utile, in quanto ora le richieste vengono elaborate in un batch, consentendo di ridurre la latenza di andata e ritorno e migliorare le prestazioni dell'applicazione.

Se poi si riscontra una riduzione generale delle prestazioni del database, è possibile monitorare le viste a gestione dinamica sys.dm_db_resource_stats e sys.resource_stats per individuare il consumo di memoria, CPU e I/O. Le prestazioni potrebbero esserne impattate perché il database ha esaurito le risorse. Potrebbe essere necessario modificare le dimensioni di calcolo e/o il livello di servizio in base all'aumento o alla riduzione delle esigenze di carico di lavoro.

Per un set completo di raccomandazioni per la risoluzione dei problemi relativi alle prestazioni, vedere Ottimizzare il database.

Come verificare di usare il livello di servizio e le dimensioni di calcolo appropriati

Database SQL offre due diversi modelli di acquisto: il precedente modello DTU e il più adattabile modello di acquisto vCore. Per le differenze, si veda Confrontare i modelli di acquisto basati su vCore e DTU del database SQL di Azure.

Per assicurarsi che le dimensioni di calcolo siano corrette, è 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 ci si accorge che le query e/o i database sono sempre attivi, è opportuno valutare la scalabilità verticale a dimensioni di calcolo superiori. In modo analogo, qualora si notasse che, anche nelle ore di punta, le risorse non vengono usate in modo eccessivo, prendere in considerazione la riduzione dalle dimensioni di calcolo correnti. È possibile prendere in considerazione l'uso di Automazione di Azure per ridimensionare i database SQL in base a una pianificazione.

In presenza di criteri di app SaaS o uno scenario di consolidamento del database, considerare l'uso di un pool elastico per l'ottimizzazione dei costi. Il pool elastico è un ottimo modo per conseguire il consolidamento dei database e l'ottimizzazione dei costi. Per ulteriori informazioni sulla gestione di più database usando un pool elastico, si veda Gestire pool e database.

Con quale frequenza è necessario eseguire controlli di integrità del database

Il database SQL usa alcune tecniche intelligenti che consentono di gestire automaticamente specifiche classi di danneggiamento dei dati, senza alcuna perdita. Queste tecniche sono incorporate nel servizio e vengono usate in base alle esigenze. A intervalli regolari, i backup dei database nel servizio vengono testati ripristinandoli ed eseguendo CHECKDB di DBCC. Se si verificano problemi, il database SQL li gestisce in modo proattivo. La correzione di pagina automatica viene usata per correggere le pagine danneggiate o con problemi di integrità dei dati. Le pagine di database vengono sempre verificate con l'impostazione CHECKSUM predefinita che verifica l'integrità della pagina. Il database SQL monitora ed esamina in modo proattivo l'integrità dei dati del database e, se si verificano problemi, li gestisce con la massima priorità. Inoltre, è anche possibile eseguire altri controlli di integrità personalizzati. Per altre informazioni, vedere Data Integrity in SQL Database (Integrità dei dati nel database SQL)

Spostamento dei dati dopo la migrazione

Come esportare e importare i dati come file BACPAC dal database SQL usando il portale di Azure?

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

• Importazione: è anche possibile importare dati come file BACPAC nel database all'interno del database SQL di Azure usando il portale di Azure.

Come sincronizzare dati tra il database SQL e SQL Server

A tale scopo, è possibile procedere in diversi modi:

• Sincronizzazione dei dati: questa funzionalità consente di sincronizzare i dati in modo bidirezionale tra più database di SQL Server e il database SQL. Per eseguire la sincronizzazione con database di SQL Server, è necessario installare e configurare l'operatore di sincronizzazione in un computer locale o in una macchina virtuale e aprire la porta TCP in uscita 1433.
• Replica transazionale: con la replica transazionale è possibile sincronizzare i dati da un database di SQL Server al database SQL di Azure, dove l'istanza di SQL Server è l'autore e il database SQL di Azure è l'abbonato. Per il momento è supportata solo questa configurazione. Per ulteriori informazioni su come eseguire la migrazione dei dati da un database di SQL Server ad Azure SQL con tempi di inattività minimi, vedere: Usare la replica transazionale

Contenuto correlato

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