Best practice generali

MySQL | PostgreSQL | SQL Server

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 delle istanze

Best practice	Informazioni dettagliate
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 in modo da controllare quando possono verificarsi aggiornamenti fastidiosi.	Consulta Periodo di manutenzione.
Se elimini e ricrei regolarmente le istanze, utilizza un timestamp nell'ID istanza per aumentare la probabilità che siano utilizzabili nuovi ID istanza.
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 una nuova operazione prematuramente, la richiesta dell'operazione non andrà a buon fine. Sono inclusi i riavvii delle istanze. Lo stato dell'istanza nella console Google Cloud non indica se un'operazione è in esecuzione. Il segno di spunta verde indica solo che l'istanza è in 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 dei database.	Se l'impostazione per le istanze Abilita aumenti automatici dello spazio di archiviazione è disabilitata o è abilitato il limite di aumento automatico dello spazio di archiviazione, 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 di utilizzo del disco con una posizione sopra la soglia e un valore pari a 0,8. Per maggiori informazioni, consulta Creare criteri di avviso basati su metriche.
Evita un utilizzo 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 inoltre monitorare l'utilizzo della CPU e ricevere avvisi quando una determinata soglia viene impostata mediante Crea criteri di avviso per soglia di metriche. Per evitare un utilizzo eccessivo, puoi aumentare il numero di CPU per l'istanza. La modifica delle CPU richiede il riavvio dell'istanza. Se l'istanza ha già raggiunto il numero massimo di CPU, devi partizionare il database in più istanze.
Evita l'esaurimento della memoria.	Quando cerchi segni di esaurimento della memoria, dovresti utilizzare principalmente la metrica utilizzo. Per evitare errori di esaurimento della memoria, è consigliabile 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, inclusa la memoria utilizzata dal container del database e la memoria 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 riallocare la memoria in questa cache. Per prevedere i problemi di esaurimento della memoria, controlla entrambe le metriche e interpretale insieme. Se le metriche sembrano elevate, l'istanza potrebbe avere poca memoria. Ciò può essere dovuto a una configurazione personalizzata, alle dimensioni ridotte 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 partizionare il 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.	Consulta le 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`. Pre-dimensionati per evitare la crescita automatica. File del database utente: Crescita automatica impostata in `64-128` MB. Ridimensionate per impedire l'espansione automatica. Spazio di archiviazione: `>= 4TB` per le IOPS migliori
Determina la capacità del sottosistema di I/O prima di eseguire il deployment di SQL Server.	Testa diversi 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 di velocità effettiva. Il tipo di archiviazione utilizzato in Cloud SQL è DP SSD, ed è adatto per carichi di lavoro di livello aziendale ad alte prestazioni. Personalizza la VM per massimizzare le prestazioni come segue: Una dimensione del disco di almeno 4 TB offre una maggiore velocità effettiva e un numero maggiore di IOPS. Una vCPU maggiore fornisce più IOPS e velocità effettiva. Quando utilizzi una vCPU maggiore, monitora il parallelismo del database, che potrebbe aumentare. Per prestazioni ottimali, emetti I/O in parallelo per ottenere una maggiore profondità delle code di I/O.
Previeni la frammentazione dell'indice e gli indici mancanti.	Riorganizza l'indice o configura una pianificazione per ricreare l'indice a seconda della frequenza di modifica dei dati. Inoltre, imposta un fattore di riempimento appropriato per ridurre la frammentazione. Monitora SQL Server per individuare gli indici mancanti che potrebbero offrire prestazioni migliorate.
Aggiornare 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 la modifica di grandi quantità di dati. Utilizza il querystore per monitorare e risolvere i problemi relativi a SQL Server con piani di query non ottimali.
Impedisci che i file di database diventino di grandi dimensioni.	Imposta `autogrow` in MB anziché come percentuale, utilizzando incrementi appropriati al requisito. Inoltre, gestisci in modo proattivo la crescita prima che inizi la crescita automatica. Inoltre, assicurati che la funzionalità Cloud SQL Abilita aumenti automatici dell'archiviazione sia abilitata in modo che Cloud SQL possa aggiungere spazio di archiviazione se il database e l'istanza esauriscono lo spazio disponibile.
Rileva i problemi di integrità del database eseguendo `DBCC CHECKDB` almeno una volta alla settimana.	`DBCC CHECKDB` verifica l'integrità di tutti gli oggetti in un database. Eseguendo `DBCC CHECKDB` ogni settimana, puoi assicurarti che i 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 invece di 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, vedi 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, che però richiede un maggior numero di 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	Informazioni dettagliate
Se possibile, suddividi le istanze di grandi dimensioni in istanze più piccole.	Quando possibile, utilizzare molte istanze Cloud SQL più piccole è preferibile rispetto a un'unica 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 della tabella della tua istanza a meno di 10.000. Un numero eccessivo di tabelle di database può influire sui tempi di upgrade del database.
Regole di confronto del database	Che tu stia installando una nuova istanza di SQL Server, ripristinando il backup di un database o connettendo un server ai database client, è importante comprendere i requisiti delle impostazioni internazionali, l'ordine di ordinamento e la sensibilità alle maiuscole e all'accento dei dati con cui stai lavorando. Quando selezioni una regola di confronto per il server, il database, la colonna o l'espressione, assegni alcune 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 comcollazioni dei database e sul supporto di Unicode.
Progettazione di query	Per prestazioni ottimali di database o query, assicurati di non utilizzare un numero elevato di tabelle nella stessa query (sedici o più).
Monitoraggio delle query	Le query potrebbero ridursi nel tempo. È importante monitorare le prestazioni dell'applicazione e delle query nel tempo. Uno dei motivi di questo degrado è costituito dai bailout degli hash. Gli hash join o i bailout di hash ricorsivi causano prestazioni ridotte su un server. Se in una traccia noti molti eventi di avviso di hash, aggiorna le statistiche sulle colonne che vengono unite. Scopri di più sui bailout con l'hash.

Implementazione dell'applicazione

Best practice	Informazioni dettagliate
Utilizza buone pratiche di gestione delle connessioni, come il pooling delle connessioni e il backoff esponenziale.	L'utilizzo di queste tecniche migliora l'uso delle risorse da parte della tua applicazione e ti aiuta a rimanere entro i limiti di connessione di Cloud SQL. Per maggiori informazioni ed esempi di codice, consulta Gestione delle connessioni ai database.
Verifica la risposta della tua applicazione agli aggiornamenti di manutenzione, che possono essere eseguiti in qualsiasi momento durante il periodo di manutenzione.	Prova la manutenzione self-service per simulare un aggiornamento di manutenzione. Durante la manutenzione, l'istanza diventa non disponibile per un breve periodo e le connessioni esistenti vengono interrotte. Testare le implementazioni di manutenzione ti consente di capire meglio come 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. Vedi Avvio del failover.
Evita transazioni di grandi dimensioni.	Fai in modo che le transazioni siano brevi e di dimensioni ridotte. Se è necessario un aggiornamento del database di grandi dimensioni, eseguilo in diverse transazioni di dimensioni inferiori anziché in una singola transazione di grandi dimensioni.
Se utilizzi il proxy di autenticazione Cloud SQL, assicurati di utilizzare la versione più aggiornata.	Consulta Mantenere aggiornato il proxy di autenticazione Cloud SQL.

Importazione ed esportazione di dati

Best practice	Informazioni dettagliate
Accelera l'importazione per istanze di piccole dimensioni.	Per le istanze di piccole dimensioni, puoi temporaneamente aumentare la CPU e la RAM di un'istanza per migliorare le prestazioni durante l'importazione di set di dati di grandi dimensioni.
Se esporti i dati per importarli in Cloud SQL, assicurati di utilizzare la procedura corretta.	Vedi Esportare i dati da un server di database gestito esternamente.

Backup e ripristino

Best practice	Informazioni dettagliate
Proteggi i tuoi dati con le funzionalità Cloud SQL appropriate.	I backup e le esportazioni sono modi per fornire ridondanza e protezione dei dati. Ognuno di questi strumenti protegge da scenari diversi e si completa a vicenda in una solida strategia di protezione dei dati. I backup sono leggeri e consentono di ripristinare i dati dell'istanza allo stato 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 di 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 saranno interessate. Inoltre, puoi esportare un solo database o persino una tabella, a seconda del formato di esportazione che scegli. Quando utilizzi la funzionalità di esportazione di backup su un'istanza SQL Server Enterprise o Standard, evita di creare un file di archivio GZ, perché 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 creata nella console Google Cloud o tramite Terraform abilita 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.

Best practice

Informazioni dettagliate

Proteggi i tuoi dati con le funzionalità Cloud SQL appropriate.

I backup e le esportazioni sono modi per fornire ridondanza e protezione dei dati. Ognuno di questi strumenti protegge da scenari diversi e si completa a vicenda in una solida strategia di protezione dei dati.

I backup sono leggeri e consentono di ripristinare i dati dell'istanza allo stato 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 di 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 saranno interessate. Inoltre, puoi esportare un solo database o persino una tabella, a seconda del formato di esportazione che scegli.

Quando utilizzi la funzionalità di esportazione di backup su un'istanza SQL Server Enterprise o Standard, evita di creare un file di archivio GZ, perché 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 creata nella console Google Cloud o tramite Terraform abilita 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 SQL Server

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

Impostazione di configurazione globale

Impostazione	Consiglio
`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.

Impostazioni del database da modificare

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

Impostazione	Consiglio
`cost threshold for parallelism`	Questa è la soglia alla quale l'ottimizzatore SQL esegue una query utilizzando il parallelismo. Il valore predefinito di `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 contesa, aumenta il valore. Il valore viene ignorato se il criterio `maxdop` è impostato su `1`.
`max degree of parallelism (MAXDOP)`	Per ridurre le attese del database a causa del parallelismo, modifica questo valore in base a suggerimenti specifici sul numero di processori logici disponibili. Se imposti questa opzione su 1, misura attentamente le prestazioni.
`optimize for ad hoc workloads`	Evita di avere un numero elevato di piani monouso nella cache del piano. Per migliorare l'efficienza della cache del piano per i carichi di lavoro che contengono molti batch ad hoc a uso singolo, imposta questa opzione su `1`.
`tempdb`	Ridimensiona `tempdb` in modo che non sia necessario crescere automaticamente. Tutti i file in `tempdb` devono avere le stesse dimensioni e avere lo stesso set di dimensioni di crescita dei file. 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 otto, utilizza otto file di dati. Se la contesa continua, aumenta il numero di file di multipli di 4 fino a quando non ci saranno ulteriori contese.

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

Impostazione	Consiglio
`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 il codice dell'applicazione per verificare la presenza di eventuali effetti negativi.
`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 parametrizzazione semplice consente a SQL Server di sostituire con parametri i valori letterali in una query. Microsoft fornisce linee guida su come modificare questo valore e utilizzarlo con le guide del piano.

Impostazioni del database da conservare

Per prestazioni ottimali del database SQL Server, conserva 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 cancella 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, nonché altri problemi di prestazioni, alcuni dei quali sono illustrati in questo blog di SQL Server.
`Date Correlation Optimization Enabled`	`False`. Se abiliti questa opzione, l'ottimizzatore può trovare e ottimizzare le relazioni tra le date in due tabelle correlate. Il monitoraggio in SQL Server comporta un certo overhead per le prestazioni.
`Legacy Cardinality Estimation`	`False`. In alcuni casi, SQL Server non può calcolare con precisione le cardinalità se questa impostazione è abilitata.
`Parameter Sniffing`	`ON`. Lo sniffing dei parametri dalle tabelle del database può aiutare a creare piani di esecuzione per il riutilizzo. Se le tabelle contengono dati distribuiti in modo non uniforme, i piani di esecuzione risultanti potrebbero causare problemi di prestazioni. Con questi dati, utilizza altre opzioni dell'archivio query anziché modificare questa impostazione.
`Query Optimizer Fixes`	`False`. Se abilitata, può influire sulle prestazioni dello strumento per la stima della cardinalità di SQL Server. Se scegli di abilitarla, esegui un test per assicurarti che non esista 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 le statistiche obsolete utilizzando una soglia di ricompilazione basata sulla cardinalità della tabella.
`Auto Update Statistics Asynchronously`	`False`. Se abilitata, questa opzione indica all'ottimizzatore di query SQL di utilizzare le statistiche inattive per l'esecuzione della query attuale, aggiornando le statistiche in modo asincrono per agevolare i carichi di lavoro futuri. Tuttavia, se prevedi tempi di risposta prevedibili per una query eseguita di frequente o se la tua applicazione riscontra spesso timeout delle richieste client in attesa degli aggiornamenti delle statistiche, ti consigliamo di abilitare questa opzione e disabilitare `Auto Update Statistics`.
`Target Recovery Time (Seconds)`	`60`. Questa impostazione stabilisce un limite superiore per il tempo di recupero per un database scaricando le pagine dirty più o meno frequentemente sul disco dal pool di buffer. Per carichi di lavoro altamente transazionali, un valore inferiore per questa impostazione, combinato con un numero di IOPS di archiviazione vicino al valore massimo, può contribuire a un collo di bottiglia delle prestazioni.

Impostazioni flag 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 SQL Server sono supportati in Cloud SQL e possono essere impostati utilizzando flag di database. Di seguito sono riportate le impostazioni consigliate.

Flag di Trace	Consigliato
`1204`	`Yes`, ad eccezione dei server a uso intensivo dei carichi di lavoro che generano molti deadlock. Restituisci le risorse e i tipi di blocchi che fanno parte di un deadlock, nonché il comando attualmente interessato.
`1222`	`Yes`, ad eccezione dei server a uso intensivo dei carichi di lavoro che generano molti deadlock.
`1224`	`No`. Ciò può comportare un maggiore utilizzo della memoria e pressione di memoria sul database.
`2528`	`No`. Il controllo parallelo degli oggetti è l'impostazione predefinita ed è consigliata. 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, come i backup di TLOG.
`3625`	`No`. Poiché l'account principale non dispone dell'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 della cardinalità e può portare alla regressione delle query.
`4616`	`No`. Questa limitazione riduce la sicurezza dei ruoli delle applicazioni. Deve essere convalidato in base ai requisiti dell'applicazione.
`7806`	`Yes`. Se il server del database non risponde, l'unico modo per stabilire una connessione ai fini della diagnostica potrebbe essere la connessione di amministrazione dedicata (DAC).

Passaggi successivi

Per ulteriori informazioni sulle procedure generali per motore del database, consulta: