Best practice generali

Questa pagina fornisce le best practice per ottenere le migliori prestazioni, durabilità e disponibilità da Cloud SQL.

Se si verificano problemi con l'istanza Cloud SQL, esamina quanto segue durante la risoluzione dei problemi:

Configurazione e amministrazione dell'istanza

Best practice Ulteriori informazioni
Leggi e segui le linee guida operative per assicurarti che le tue istanze siano coperte dallo SLA di Cloud SQL.
Configura un periodo di manutenzione per l'istanza principale al fine di controllare quando possono verificarsi aggiornamenti improvvisi. Consulta Periodo di manutenzione.
Se elimini e ricrei le istanze regolarmente, utilizza un timestamp nell'ID istanza per aumentare la probabilità che nuovi ID istanza siano utilizzabili.
Non avviare un'operazione amministrativa prima del completamento dell'operazione precedente.

Le istanze Cloud SQL non accettano nuove richieste di operazioni finché non hanno completato l'operazione precedente. Se tenti di avviare prematuramente una nuova operazione, la richiesta dell'operazione non va a buon fine. Sono inclusi i riavvii delle istanze.

Lo stato dell'istanza nella console Google Cloud non indica se è in esecuzione un'operazione. Il segno di spunta verde indica solo che l'istanza è nello stato RUNNABLE. Per vedere se un'operazione è in esecuzione, vai alla scheda Operazioni e controlla lo stato dell'operazione più recente.

Configura lo spazio di archiviazione per supportare la manutenzione critica del database.

Se l'impostazione Abilita aumenti automatici dello spazio di archiviazione è disabilitata o il limite di aumento automatico dello spazio di archiviazione è abilitato, assicurati di avere almeno il 20% di spazio disponibile per supportare eventuali operazioni critiche di manutenzione del database che Cloud SQL potrebbe eseguire.

Per ricevere avvisi quando lo spazio su disco disponibile scende al di sotto del 20%, crea un criterio di avviso basato su metriche per la metrica Utilizzo del disco con una posizione sopra la soglia e un valore di 0,8. Per maggiori informazioni, consulta la sezione Creare criteri di avviso basati su metriche.
Evita un uso eccessivo della CPU.

Puoi visualizzare la percentuale di CPU disponibile utilizzata dall'istanza nella pagina dei dettagli dell'istanza nella console Google Cloud. Per maggiori informazioni, consulta Metriche. Puoi anche monitorare l'utilizzo della CPU e ricevere avvisi a una soglia specificata utilizzando Crea criteri di avviso per la soglia della metrica.

Per evitare un utilizzo eccessivo, puoi aumentare il numero di CPU per l'istanza. Per cambiare le CPU è necessario riavviare l'istanza. Se l'istanza ha già raggiunto il numero massimo di CPU, devi eseguire lo sharding del database su più istanze.
Evita l'esaurimento della memoria.

Se cerchi segni di esaurimento della memoria, dovresti usare principalmente la metrica utilizzo. Per evitare errori di esaurimento della memoria, consigliamo che questa metrica rimanga al di sotto del 90%.

Puoi anche utilizzare la metrica total_usage per osservare la percentuale di memoria disponibile utilizzata dall'istanza Cloud SQL, compresa la memoria utilizzata dal container del database e quella allocata dalla cache del sistema operativo.

Osservando la differenza tra le due metriche, puoi identificare la quantità di memoria utilizzata dai processi rispetto a quella utilizzata dalla cache del sistema operativo. Puoi riutilizzare la memoria in questa cache.

Per prevedere i problemi di esaurimento della memoria, controlla entrambe le metriche e interpretale insieme. Se le metriche sembrano alte, la memoria dell'istanza potrebbe essere insufficiente. Ciò può essere dovuto a una configurazione personalizzata, alle dimensioni dell'istanza per il carico di lavoro o a una combinazione di questi fattori.

Scala l'istanza Cloud SQL per aumentare le dimensioni della sua memoria. La modifica delle dimensioni della memoria dell'istanza richiede il riavvio dell'istanza. Se l'istanza ha già raggiunto la dimensione massima della memoria, devi eseguire lo sharding del database su più istanze. Per scoprire di più sul monitoraggio di entrambe le metriche nella console Google Cloud, consulta Metriche.
Configura le impostazioni di SQL Server in modo che funzionino in modo ottimale per Cloud SQL. Vedi Impostazioni di SQL Server.
Ottimizza l'istanza in modo ottimale per le esecuzioni di test. La tabella seguente elenca i valori di configurazione adatti per le esecuzioni di test.
  • vCPU: 40
  • Memoria: 262144 MB
  • MAXDOP: 8
  • Soglia di costo per il parallelismo: 120
  • file tempdb: 8. Predimensionato per evitare la crescita automatica.
  • File di database utente: aumento automatico impostato in 64-128 MB. Predimensionato per evitare la crescita automatica.
  • Spazio di archiviazione: >= 4TB per ottimizzare le IOPS
Determina la capacità del sottosistema I/O prima di eseguire il deployment di SQL Server.

Testa vari tipi e dimensioni di I/O. La dimensione dell'I/O inviato allo spazio di archiviazione su disco permanente proveniente da SQL Server influisce su IOPS e velocità effettiva. Il carico di lavoro SQL Server viene limitato quando raggiunge il limite di IOPS o il limite di velocità effettiva. Il tipo di archiviazione utilizzato in Cloud SQL è DP SSD, ideale per carichi di lavoro aziendali ad alte prestazioni.

Personalizza la VM per massimizzare le prestazioni come segue:

  • Una dimensione del disco di almeno 4 TB garantisce una maggiore velocità effettiva e IOPS.
  • Una vCPU maggiore fornisce più IOPS e velocità effettiva. Quando utilizzi una vCPU più alta, monitora il database attende il parallelismo, che potrebbe anche aumentare.
  • Per prestazioni ottimali, esegui l'I/O in parallelo per ottenere una profondità di coda I/O maggiore.
Evita la frammentazione degli indici e gli indici mancanti. Riorganizza l'indice o configura una pianificazione per ricrearlo a seconda della frequenza di modifica dei dati. Imposta anche un fattore di riempimento appropriato per ridurre la frammentazione. Monitora SQL Server per individuare indici mancanti che potrebbero offrire prestazioni migliori.
Aggiorna regolarmente le statistiche. Se le statistiche sono obsolete, lo strumento di ottimizzazione delle query SQL potrebbe generare piani di query non ottimali. Aggiorna le statistiche soprattutto dopo aver modificato grandi quantità di dati. Utilizza il archivio query per monitorare e risolvere i problemi di SQL Server che ha piani di query non ottimali.
Evita che i file di database diventino di dimensioni inutilmente grandi.

Imposta autogrow in MB anziché come percentuale, utilizzando gli incrementi appropriati al requisito. Inoltre, gestisci in modo proattivo la crescita prima che inizi la crescita automatica.

Inoltre, assicurati che la funzionalità Abilita aumenti automatici dello spazio di archiviazione di Cloud SQL sia abilitata, in modo che Cloud SQL possa aggiungere spazio di archiviazione se il database e l'istanza esauriscono lo spazio.

Rileva i problemi di integrità del database eseguendo DBCC CHECKDB almeno una volta a settimana. DBCC CHECKDB controlla l'integrità di tutti gli oggetti in un database. Eseguendo DBCC CHECKDB ogni settimana, puoi assicurarti che i tuoi database non siano danneggiati. DBCC CHECKDB è un'operazione che richiede molte risorse e può influire sulle prestazioni dell'istanza.
Non eseguire DBCC CHECKDB su un server di produzione.
Ti consigliamo di utilizzare una delle seguenti opzioni anziché eseguire DBCC CHECKDB su un server di produzione:
  • Clona un database ed esegui DBCC CHECKDB sul database di clonazione.
  • Ripristina un backup in un'altra istanza, quindi esegui DBCC CHECKDB sui database dell'istanza ripristinata. Per saperne di più sul ripristino di un'istanza, consulta Ripristinare un'istanza.

Utilizza i seguenti snippet di codice per eseguire DBCC CHECKDB su un database:

  • (Consigliato) Esegui DBCC CHECKDB con EXTENDED_LOGICAL_CHECKS. Si tratta di un controllo completo, ma che richiede più risorse. 
          USE DATABASE_NAME
      DBCC CHECKDB WITH EXTENDED_LOGICAL_CHECKS,
      DATA_PURITY,NO_INFOMSGS, ALL_ERRORMSGS
  • Esegui DBCC CHECKDB con PHYSICAL_ONLY: 
          USE DATABASE_NAME
      DBCC CHECKDB WITH PHYSICAL_ONLY,
      NO_INFOMSGS, ALL_ERRORMSGS

Architettura dei dati

Best practice Ulteriori informazioni
Se possibile, dividi le istanze di grandi dimensioni in istanze più piccole. Quando possibile, utilizzare molte istanze Cloud SQL più piccole è meglio di un'istanza di grandi dimensioni. La gestione di un'istanza monolitica di grandi dimensioni presenta sfide non poste da un gruppo di istanze più piccole.
Non utilizzare troppe tabelle di database.

Mantieni il conteggio delle tabelle dell'istanza inferiore a 10.000. Un numero eccessivo di tabelle di database può influire sui tempi di upgrade del database.

Regole di confronto database Che tu stia installando una nuova istanza di SQL Server, ripristinando un backup di database o connettendo un server a database client, è importante comprendere i requisiti delle impostazioni internazionali, l'ordinamento e la distinzione tra maiuscole e minuscole e accento dei dati con cui lavori. Quando selezioni una regola di confronto per il server, il database, la colonna o l'espressione, assegni determinate caratteristiche ai dati. Queste caratteristiche influiscono sui risultati di molte operazioni nel database. Ad esempio, quando crei una query utilizzando ORDER BY, l'ordinamento del set di risultati potrebbe dipendere dalle regole di confronto applicate al database o dettate in una clausola COLLATE a livello di espressione della query. Scopri di più sulle collazioni del database e sul supporto Unicode.
Progettazione di query Per prestazioni ottimali per database o query, assicurati di non utilizzare un numero elevato di tabelle all'interno della stessa query (sedici o più).
Monitoraggio delle query La qualità delle query potrebbe diminuire nel tempo. È importante monitorare le prestazioni dell'applicazione e delle query nel tempo. Uno dei motivi di tale degrado è il bailout degli hash.
I join hash ricorsivi o i blocchi di hashing riducono le prestazioni in un server. Se in una traccia sono presenti molti eventi di avviso relativo all'hash, aggiorna le statistiche sulle colonne che vengono unite. Ulteriori informazioni sui bailout degli hash.

Implementazione dell'applicazione

Best practice Ulteriori informazioni
Utilizza buone pratiche di gestione delle connessioni, come il pooling di connessioni e il backoff esponenziale. Queste tecniche migliorano l'utilizzo delle risorse da parte dell'applicazione e ti consentono di rimanere entro i limiti di connessioni di Cloud SQL. Per ulteriori informazioni ed esempi di codice, consulta Gestione delle connessioni di database.
Testa la risposta della tua applicazione agli aggiornamenti di manutenzione, che possono verificarsi in qualsiasi momento durante il periodo di manutenzione. Prova la manutenzione self-service per simulare un aggiornamento di manutenzione. Durante la manutenzione, l'istanza non è disponibile per un breve periodo e le connessioni esistenti vengono eliminate. Il test delle implementazioni della manutenzione consente di comprendere meglio il modo in cui la tua applicazione gestisce la manutenzione pianificata e la velocità di ripristino del sistema.
Testa la risposta della tua applicazione ai failover, che possono verificarsi in qualsiasi momento. Puoi avviare manualmente un failover utilizzando la console Google Cloud, gcloud CLI o l'API. Consulta Avvio del failover.
Evita transazioni di grandi dimensioni. Fai in modo che le transazioni siano brevi e brevi. Se è necessario un aggiornamento di grandi dimensioni del database, eseguilo con diverse transazioni di piccole dimensioni anziché in una singola transazione di grandi dimensioni.
Se utilizzi il proxy di autenticazione Cloud SQL, assicurati di avere la versione più aggiornata. Consulta Mantenere aggiornato il proxy di autenticazione Cloud SQL.

Importazione ed esportazione di dati

Best practice Ulteriori informazioni
Velocizza le importazioni per istanze di piccole dimensioni. Per istanze di piccole dimensioni, puoi aumentare temporaneamente la CPU e la RAM di un'istanza per migliorare le prestazioni durante l'importazione di set di dati di grandi dimensioni.
Se esporti dati per importarli in Cloud SQL, assicurati di utilizzare la procedura corretta. Consulta Esportazione di dati da un server di database gestito esternamente.

Backup e ripristino

Best practice Ulteriori informazioni
Proteggi i tuoi dati con le funzionalità Cloud SQL appropriate.

I backup e le esportazioni sono modi per fornire ridondanza e protezione dei dati. Ciascuno di essi offre protezione da scenari diversi e si integra a vicenda in una solida strategia di protezione dei dati.

I backup sono leggeri; consentono di ripristinare lo stato dei dati sull'istanza al momento in cui è stato eseguito il backup. Tuttavia, i backup hanno alcune limitazioni. Se elimini l'istanza, vengono eliminati anche i backup. Non puoi eseguire il backup di un singolo database o una singola tabella. E se la regione in cui si trova l'istanza non è disponibile, non puoi ripristinare l'istanza da quel backup, anche in una regione disponibile.

La creazione delle esportazioni richiede più tempo, perché in Cloud Storage viene creato un file esterno che può essere utilizzato per ricreare i dati. Se elimini l'istanza, le esportazioni non sono interessate. Inoltre, puoi esportare un solo database o anche una singola tabella, a seconda del formato di esportazione che scegli.

Quando utilizzi la funzionalità di esportazione di backup su un'istanza SQL Server o Enterprise o Standard, evita di creare un file di archivio GZ, perché questo tenta di comprimere un backup già compresso in modo nativo da SQL Server.

Proteggi l'istanza e i backup dall'eliminazione accidentale.

Un'istanza Cloud SQL che crei nella console Google Cloud o tramite Terraform consente la prevenzione dell'eliminazione accidentale per impostazione predefinita.

Utilizza la funzionalità di esportazione in Cloud SQL per esportare i dati per una maggiore protezione. Utilizza Cloud Scheduler con l'API REST per automatizzare la gestione delle esportazioni. Per scenari più avanzati, Cloud Scheduler con Cloud Functions per l'automazione.

Impostazioni di SQL Server

Alcune impostazioni di SQL Server sono consigliate per Cloud SQL. I seguenti argomenti descrivono alcuni suggerimenti.

Impostazioni di configurazione globali

Impostazione Suggerimento
max worker threads Mantieni il valore predefinito 0. Questa impostazione definisce il numero di thread disponibili per SQL Server in base al numero di CPU. Il valore viene calcolato automaticamente dal motore SQL Server all'avvio.
max server memory (MB)

Se non specifichi un valore per questa impostazione, nel tempo SQL Server consuma la maggiore quantità di memoria possibile fino a raggiungere il 100%. Se l'utilizzo della memoria per un'istanza Cloud SQL per SQL Server diventa troppo elevato, potrebbero verificarsi problemi di prestazioni. Per maggiori informazioni sull'utilizzo della memoria per SQL Server, vedi Monitorare la memoria utilizzata.

Ti consigliamo di utilizzare la seguente formula per impostare il flag di database
max server memory:

  • Riserva 1,4 GB di memoria per il sistema operativo e gli agenti.
  • Se la RAM sul server è inferiore o uguale a 16 GB, riserva 1 GB di memoria per ogni 4 GB di RAM.
  • Se la RAM sul server è superiore a 16 GB, lascia 4 GB di memoria e riserva 1 GB di memoria per ogni 8 GB di RAM superiore a 16 GB.

Ad esempio, se la RAM per la tua istanza è 104 GB
(106496 MB), scegli:

  • 1,4 GB di memoria per il sistema operativo e gli agenti
  • 4 GB di memoria, perché 104 GB sono maggiori di 16 GB
  • 11 GB di memoria, perché ci sono 88 GB di RAM, maggiori di 16 GB (104-16=88) e 88 divisi per 8 corrispondono a 11

Per questo esempio, devi prenotare 16,4 GB di memoria. Di conseguenza, per il valore di questo flag, specifica 89702 MB
[(104-16,4) * 1024 = 89702].

La tabella seguente contiene valori e percentuali consigliati di RAM totale per alcuni livelli di macchine virtuali (VM) molto diffusi:

Livello istanza (MB) Memoria massima server (MB) % (totale)
3840 1440 37
4096 1632 39
5792 2912 50
8192 4704 57
11584 7248 62
16384 10848 66
23168 16800 72
32768 25200 76
46336 37072 80
65568 53888 82
92704 77648 83
131136 111248 84
185440 158784 85
262272 226000 86
370880 321056 86
524544 455488 86
741792 645600 87

Per monitorare l'utilizzo della memoria per l'istanza, usa le seguenti metrics:

  • database/memory/usage
  • database/sqlserver/memory/buffer_cache_hit_ratio
  • database/sqlserver/memory/memory_grants_pending
  • database/sqlserver/memory/page_life_expectancy

Per saperne di più, consulta Monitorare le istanze Cloud SQL.

Impostazioni del database da modificare

Per prestazioni ottimali del database SQL Server, configura le seguenti impostazioni di SQL Server come suggerito di seguito.

Impostazione Suggerimento
cost threshold for parallelism

Questa è la soglia alla quale lo strumento di ottimizzazione SQL esegue una query utilizzando il parallelismo. Il valore predefinito 5 può causare l'esecuzione di troppe query in parallelo, aumentando così il tempo di attesa del database sui thread paralleli. Per ridurre questo tipo di conflitto, aumenta il valore.

Il valore viene ignorato quando il criterio maxdop è impostato su 1.

max degree of parallelism (MAXDOP)

Per ridurre i tempi di attesa del database dovuti al parallelismo, regola questo valore in base a suggerimenti specifici sul numero di processori logici disponibili. Misura attentamente le prestazioni se imposti questa opzione su 1.

optimize for ad hoc workloads

Evita di avere un numero elevato di piani monouso nella cache dei piani. Per migliorare l'efficienza della cache del piano per i carichi di lavoro che contengono molti batch ad hoc monouso, imposta questa opzione su 1.

tempdb

Predimensiona tempdb in modo che non sia necessario crescere automaticamente. Tutti i file in tempdb devono avere le stesse dimensioni e avere lo stesso insieme di dimensioni di crescita.

Il tipo di attesa del database per la contesa tempdb viene visualizzato come PAGELATCH_UP. Per ridurre la contesa, aggiungi altri file.

Se il numero di processori è inferiore o uguale a 8, utilizza lo stesso numero di file dei processori logici. Se il numero di processori è maggiore di 8, utilizza 8 file di dati. Se la contesa persiste, aumenta il numero di file di multipli di 4 fino a quando non ci sono ulteriori contese.

A seconda del carico di lavoro, potresti voler modificare anche le seguenti impostazioni.

Impostazione Suggerimento
Close Cursor on Commit Enabled Il valore predefinito è off, il che significa che i cursori non vengono chiusi automaticamente quando esegui il commit di una transazione.
Default Cursor Questa opzione controlla l'ambito di un cursore utilizzato nel codice T-SQL. Se modifichi questa impostazione, valuta la presenza di eventuali effetti negativi nel codice dell'applicazione.
Page Verify Questa opzione consente a SQL Server di calcolare un checksum per una pagina di database prima che venga scritta su disco e di archiviare il checksum nell'intestazione della pagina. Quando una pagina viene letta di nuovo, il checksum viene ricalcolato per verificare l'integrità della pagina. Il valore consigliato è checksum.
Parameterization Il valore predefinito è simple. La semplice parametrizzazione consente a SQL Server di sostituire i valori letterali in una query con parametri. Microsoft fornisce linee guida su come modificare questo valore e utilizzarlo con le guide ai piani.

Impostazioni del database da conservare

Per prestazioni ottimali del database SQL Server, mantieni i valori predefiniti delle seguenti impostazioni di SQL Server.

Impostazione Valore predefinito da conservare
Auto Close False. Quando è attiva, questa impostazione apre e chiude le connessioni e scarica la procedura dopo ogni connessione. Ciò può causare un peggioramento delle prestazioni nei database a cui si accede di frequente.
Auto Shrink False. L'attivazione può causare la frammentazione del database e dell'indice e altri problemi di prestazioni, alcuni dei quali sono discussi in questo blog di SQL Server.
Date Correlation Optimization Enabled False. L'attivazione può consentire all'ottimizzatore di trovare e ottimizzare le relazioni tra le date in due tabelle correlate. Il monitoraggio di questo aspetto in SQL Server comporta un certo overhead delle prestazioni.
Legacy Cardinality Estimation False. In alcuni casi, SQL Server non può calcolare con precisione le cardinalità quando questa impostazione è abilitata.
Parameter Sniffing ON. Lo sniffing dei parametri dalle tabelle del database può aiutare a creare piani di esecuzione da riutilizzare. Se le tabelle hanno dati distribuiti non uniformemente, i piani di esecuzione risultanti potrebbero causare problemi di prestazioni. Con questi dati, utilizza altre opzioni del Query Store anziché modificare questa impostazione.
Query Optimizer Fixes False. Se abilitato, può influire sulle prestazioni dello strumento di stima della cardinalità di SQL Server. Se scegli di abilitarla, esegui dei test per assicurarti che non ci sia una regressione delle query.
Auto Create Statistics True. Questa opzione consente a SQL Server di creare statistiche a colonna singola che possono migliorare le stime di cardinalità per i piani di query.
Auto Update Statistics True. Questa opzione consente a SQL Server di aggiornare statistiche obsolete utilizzando una soglia di ricompilazione basata sulla cardinalità delle tabelle.
Auto Update Statistics Asynchronously False. Questa opzione, se abilitata, indica allo strumento di ottimizzazione delle query SQL di utilizzare le statistiche inattive per l'esecuzione attuale delle query, aggiornandole in modo asincrono per agevolare i carichi di lavoro futuri.

Tuttavia, se prevedi un tempo di risposta prevedibile per una query eseguita di frequente o se la tua applicazione riscontra spesso timeout delle richieste client in attesa di aggiornamenti statistici, valuta la possibilità di abilitare questa opzione e disabilitare Auto Update Statistics.

Target Recovery Time (Seconds) 60. Questa impostazione stabilisce un limite superiore al tempo di recupero per un database mediante il flush delle pagine dirty in modo più o meno frequente sul disco dal pool di buffer. Per carichi di lavoro altamente transazionali, un valore più basso per questa impostazione, combinato con le IOPS di archiviazione che si avvicinano al valore massimo, può contribuire a un collo di bottiglia delle prestazioni.

Impostazioni flag di Trace

I flag di traccia in SQL Server vengono utilizzati per impostare determinate caratteristiche, modificare il comportamento dei database SQL Server o eseguire il debug dei problemi in SQL Server.

Alcuni flag di traccia di SQL Server sono supportati in Cloud SQL e possono essere impostati utilizzando flag di database. Le impostazioni consigliate sono le seguenti.

flag di Trace Opzione consigliata
1204 Yes, ad eccezione dei server ad alto carico di lavoro che generano molti deadlock.

Restituisci le risorse e i tipi di blocchi che partecipano a un deadlock, nonché il comando attualmente interessato.
1222 Yes, ad eccezione dei server ad alto carico di lavoro che generano molti deadlock.
1224 No. Ciò può comportare un maggiore utilizzo di memoria e una pressione della memoria sul database.
2528 No. Il controllo parallelo degli oggetti è l'impostazione predefinita ed è consigliato. Il grado di parallelismo viene calcolato automaticamente dal motore del database.
3205 No. Le unità a nastro per i backup sono una funzionalità di Cloud SQL per SQL Server.
3226 No, a meno che tu non abbia bisogno di backup frequenti, ad esempio quelli dei TLOG.
3625 No. Poiché l'account root non ha accesso come amministratore di sistema, potrebbe non essere in grado di visualizzare tutti i messaggi di errore.
4199 No. Questo influisce sullo strumento per la stima di cardinalità e può portare a una regressione delle query.
4616 No. Questa limitazione riduce la sicurezza relativa ai ruoli delle applicazioni. Deve essere convalidato in base ai requisiti dell'applicazione.
7806 Yes. Se il server di database non risponde, l'unico modo per stabilire una connessione per la diagnostica potrebbe essere la connessione di amministrazione dedicata (DAC).

Passaggi successivi

Per ulteriori informazioni sulle pratiche generali per motore del database, vedi: