Nuovo amministratore di database (DBA) nel cloud: gestione del 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

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 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 esegue un backup completo ogni settimana, un backup differenziale ogni poche ore e un backup del log ogni 5 minuti per garantire che il ripristino di emergenza sia efficiente e la perdita di dati sia minima. Il primo backup completo viene eseguito non appena si crea un database. Questi backup sono disponibili per un determinato periodo denominato periodo di conservazione, che varia in base al livello di servizio scelto. È possibile eseguire il ripristino a qualsiasi punto nel tempo all'interno di questo periodo di conservazione usando ripristino temporizzato (PITR).

Inoltre, la funzionalità backup di conservazione a lungo termine consente di mantenere i file di backup per un massimo di 10 anni e di ripristinare i dati da questi backup in qualsiasi momento entro tale periodo. I backup del database vengono mantenuti in un'archiviazione con replica geografica per garantire resilienza dalla catastrofe a livello regionale. È anche possibile ripristinare questi backup in un'area di Azure in qualsiasi punto nel tempo entro 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?

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. 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 replica geografica attiva, i gruppi di failover consentono di 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 altre informazioni, vedere Panoramica dei gruppi di failover e procedure consigliate (database SQL di Azure).

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. Ciò consente di ridurre la latenza per uno scenario di applicazione con distribuzione geografica.

Che aspetto ha 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 altre informazioni, vedere Ripristino di emergenza del database SQL di Azure 101.

Sicurezza e conformità

La sicurezza all'interno del database SQL è disponibile a livello di database e a livello di piattaforma. È possibile controllare e garantire una sicurezza ottimale per l'applicazione come indicato di seguito:

• 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 ai dati sensibili e con privilegi (sicurezza a livello di riga e maschera dati dinamica).

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 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. Microsoft Entra ID fornisce l'accesso Single Sign-On (SSO) al 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 una politica tramite l'accesso condizionale e usare l'autenticazione a più fattori di Microsoft Entra.
L'accesso a Windows viene eseguito usando le credenziali di Microsoft Entra da un dominio federato	Usare l'autenticazione di Microsoft Entra.
L'accesso a Windows viene eseguito usando le credenziali di un dominio non federato con Azure	Usare l'autenticazione integrata di Microsoft Entra.
Disporre 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 alla connettività al database?

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

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

Firewall

Per impostazione predefinita, tutte le connessioni ai database all'interno del server non sono consentite, ad eccezione delle connessioni (facoltativamente) provenienti da altri servizi di Azure. Con una regola del firewall, è possibile aprire l'accesso al server solo alle entità (ad esempio, a un computer per sviluppatori) di cui si approva, consentendo l'indirizzo IP del computer tramite 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 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.

Endpoint di servizio

Per impostazione predefinita, il database è configurato in Consenti ai servizi e alle risorse di Azure di accedere a questo 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 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 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 ottimizzarlo perché i pacchetti passano direttamente dalla rete virtuale al servizio nella 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. L'assegnazione degli indirizzi IP riservati evita di dover aggiornare le regole firewall quando si modificano gli indirizzi IP.

In quale porta devo connettermi al database SQL?

Il database SQL comunica sulla porta 1433. 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

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. Il controllo è particolarmente utile se si intende ottenere informazioni dettagliate sulle potenziali violazioni di sicurezza e criteri, mantenere la conformità alle normative e così via. Consente di definire e configurare determinate categorie di eventi che si ritiene necessario controllare e in base a cui è possibile ottenere report preconfigurati e un dashboard per ottenere una panoramica degli eventi che si verificano nel database.

È possibile applicare questi criteri di controllo a livello di database o server. Per altre informazioni, abilitare il controllo del database SQL.

Rilevamento delle minacce

Con il rilevamento delle minacce, è possibile agire sulle violazioni di sicurezza o dei criteri individuate dal controllo. Non è necessario essere esperti di sicurezza per affrontare potenziali minacce o violazioni nel sistema. Il rilevamento delle minacce include anche alcune funzionalità predefinite, ad esempio il rilevamento sql injection, un modo piuttosto comune per 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.

Caratteristiche	Sempre Crittografato	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	Minima
Granularità di crittografia	A livello di colonna	A livello di database

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

Ogni applicazione dispone di dati sensibili nel database che devono essere protetti dall'essere visibili a tutti. Alcuni membri del personale all'interno dell'organizzazione devono essere in grado di visualizzare questi dati, a differenza di altri. In questi casi, i dati sensibili devono essere mascherati o non essere esposti affatto. Per impedire a utenti non autorizzati di visualizzare dati sensibili, il database SQL offre due approcci di questo tipo:

• La maschera dati dinamica è una funzionalità di maschera dati che consente di limitare l'esposizione dei dati sensibili mascherandola agli utenti senza privilegi nel livello applicazione. Si definisce una regola di maschera che può creare un modello di maschera (ad esempio, per visualizzare solo le ultime quattro cifre di un ID nazionale SSN: XXX-XX-0000 e mascherarne la maggior parte con il X carattere) e identificare quali utenti devono essere esclusi dalla regola di maschera. 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 quel livello. 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 si gestiscono 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 dal database SQL di Azure
• In alternativa, puoi utilizzare Azure Key Vault come archivio chiavi

Per impostazione predefinita, la chiave master per TDE è gestita dal database SQL di Azure. Se l'organizzazione vuole controllare la chiave master, è possibile usare Azure Key Vault come archivio 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.

Sempre Crittografato

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 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 l'organizzazione e il database SQL viene in genere instradato sulla rete pubblica. Tuttavia, è possibile ottimizzare questo percorso e renderlo più sicuro con Azure ExpressRoute. ExpressRoute estende la rete aziendale nella piattaforma Azure tramite una connessione privata. In questo modo si evita 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 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:

• Colocazione di Cloud Exchange
• Any-to-any
• Point-to-Point

ExpressRoute consente anche di eseguire un burst fino a 2 volte il limite di larghezza di banda acquistato senza costi aggiuntivi. È anche possibile configurare la connettività tra più aree con ExpressRoute. Per un elenco dei provider di connettività ExpressRoute, vedere Partner ExpressRoute e località di peering. 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 è utile per la conformità dell'organizzazione?

Il database SQL rispetta una serie di conformità normative. Per visualizzare il set più recente di conformità rispettate dal database SQL, visitare il Centro protezione Microsoft ed esaminare le conformità importanti per la vostra organizzazione per verificare se il database SQL è incluso nei servizi di 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 eseguito la migrazione del database al database SQL, è necessario monitorare il database( ad esempio, controllare come l'utilizzo delle risorse è simile o i controlli DBCC) ed eseguire una manutenzione regolare (ad esempio, ricompilare o riorganizzare indici, statistiche e così via). 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

Con le informazioni dettagliate sulle prestazioni delle query, è possibile ottenere raccomandazioni personalizzate per il carico di lavoro del database, in modo che le applicazioni possano continuare a funzionare ottimale. È anche possibile configurarlo in modo che questi consigli vengano applicati automaticamente, evitando di dover eseguire manualmente le attività di manutenzione. Con Advisor per il database SQL è possibile implementare automaticamente le raccomandazioni sugli indici in base al carico di lavoro. Questa operazione è denominata 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. Dopo ogni analisi, viene fornito un elenco personalizzato di passaggi interattivi e script di correzione e un report di valutazione che può essere usato per soddisfare 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. Per altre informazioni, vedere Pool elastici che consentono di gestire e ridimensionare più database nel database SQL di Azure e pianificare e gestire i costi per il database SQL di Azure.

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

È 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. È 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 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 per il database SQL di Azure e Azure Synapse Analytics usando il portale di Azure.

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 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?

Una parte importante delle tecniche di risoluzione dei problemi che è possibile usare per diagnosticare i problemi di prestazioni di query e database rimane invariata: lo stesso motore di database alimenta il cloud. Il database SQL di Azure consente di risolvere e diagnosticare più facilmente i problemi di prestazioni. Può anche eseguire alcune di queste azioni correttive per conto dell'utente e, in alcuni casi, correggerle automaticamente.

L'approccio alla risoluzione dei problemi di prestazioni può trarre vantaggio in modo significativo dall'uso di funzionalità intelligenti come Query Performance Insight (QPI) e Database Advisor in combinazione. La differenza nella metodologia, quindi, è che non è più necessario eseguire il lavoro manuale di elaborare i dettagli essenziali che potrebbero aiutare a 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. Database Advisor offre consigli su elementi che possono aiutare a migliorare le prestazioni complessive in generale, ad esempio indici mancanti, eliminazione di 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 supponga, ad esempio, di avere un'applicazione di tipo chatty sensibile alla latenza di rete. In questo caso, le prestazioni della tua applicazione peggiorano perché ci sarebbero molte richieste brevi che vanno avanti e indietro ("chiacchierone") tra l'applicazione e il server, e su una rete congestionata questi spostamenti 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.

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 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 set completo di raccomandazioni per l'ottimizzazione dei problemi di prestazioni, vedere Ottimizzare il database.

Come è possibile assicurarsi di usare il livello di servizio e le dimensioni di calcolo appropriate?

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 ci si accorge che le query e/o i database sono sempre attivi, è opportuno valutare la scalabilità verticale a dimensioni di calcolo superiori. Analogamente, se non si sembrano usare le risorse altrettanto durante le ore di punta, valutare la possibilità di ridurre le 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 altre informazioni sulla gestione di più database tramite pool elastico, vedere Gestire 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. Queste tecniche predefinite vengono usate dal servizio quando si verifica la necessità. I backup dei database nel servizio vengono testati regolarmente ripristinandoli ed eseguendo DBCC CHECKDB su di essi. Se si verificano problemi, il database SQL li gestisce in modo proattivo.

Il ripristino automatico delle pagine viene usato per la correzione di pagine danneggiate o con problemi di integrità dei dati. Le pagine del database vengono sempre verificate con l'impostazione predefinita CHECKSUM che verifica l'integrità della pagina. Il database SQL monitora e esamina in modo proattivo l'integrità dei dati del database e risolve i problemi che si verificano. Facoltativamente, è possibile eseguire controlli di integrità personalizzati in base alle esigenze. Per altre informazioni, vedere Integrità dei dati nel database SQL.

Spostamento dei dati dopo la migrazione

Come si esportano e si importano 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 nel database SQL di Azure usando il portale di Azure:

  

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

A tale scopo, è possibile procedere in diversi modi:

• Sincronizzazione dati: questa funzionalità consente di sincronizzare i dati in modo bidirezionale tra più database DI SQL Server e 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 delle transazioni: con la replica delle transazioni è possibile sincronizzare i dati da un database DI SQL Server al database SQL di Azure con l'istanza di SQL Server come server di pubblicazione e il database SQL di Azure come sottoscrittore. Per il momento è supportata solo questa configurazione. Per altre 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 delle transazioni

Contenuto correlato

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