Questa pagina fornisce best practice per ottenere le migliori prestazioni. durabilità e disponibilità da Cloud SQL.
Se si verificano problemi con l'istanza Cloud SQL, esamina le operazioni seguenti 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 da controllare quando possono verificarsi aggiornamenti improvvisi. | Consulta Periodo di manutenzione. |
Se elimini e ricrei le istanze regolarmente, utilizza un timestamp l'ID istanza per aumentare la probabilità che i nuovi ID istanza vengano utilizzabili. | |
Non avviare un'operazione amministrativa prima dell'operazione precedente viene completata. |
Le istanze Cloud SQL non accettano nuove richieste di operazioni finché hanno completato l'operazione precedente. Se provi ad avviare prematuramente di una nuova operazione, la richiesta dell'operazione non va a buon fine. Sono inclusi il riavvio dell'istanza.
Lo stato dell'istanza nella console Google Cloud
indica se un'operazione è in esecuzione. Il segno di spunta verde indica
solo che l'istanza si trovi nello stato |
Configura lo spazio di archiviazione per supportare la manutenzione critica del database. |
Se abilitare gli aumenti automatici dello spazio di archiviazione l'impostazione dell'istanza è disabilitata o il limite di aumento automatico dello spazio di archiviazione è abilitato. Assicurati di avere almeno il 20% disponibile dello spazio di archiviazione per qualsiasi operazione critica di manutenzione del database che Cloud SQL può 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 Metrica di utilizzo disco con una soglia superiore e un valore di 0,8. Per ulteriori informazioni, consulta Creare criteri di avviso basati su metriche. |
Evita un uso eccessivo della CPU. |
Puoi visualizzare la percentuale di CPU disponibile utilizzata dalla tua istanza nella pagina dei dettagli dell'istanza nella console Google Cloud. Per ulteriori informazioni, vedi Metriche. Puoi anche monitorare l'utilizzo della CPU e ricevere avvisi al raggiungimento di una determinata soglia utilizzando Crea criteri di avviso per la soglia delle metriche. Per evitare un uso eccessivo, puoi aumentare il numero di CPU per per l'istanza. Per cambiare le CPU è necessario riavviare l'istanza. Se la tua istanza ha già raggiunto il numero massimo di CPU, devi eseguire lo sharding del database su di Compute Engine. |
Evita l'esaurimento della memoria. |
Quando cerchi segni di esaurimento della memoria, dovresti cercare usa la metrica utilizzo. Per evitare errori di esaurimento della memoria, consigliamo che questa metrica rimanga al di sotto del 90%. Puoi anche utilizzare total_usage per osservare la percentuale di memoria disponibile fornita da Cloud SQL utilizzata dall'istanza, inclusa la memoria utilizzata dal container di database di memoria allocata dalla cache del sistema operativo. Osservando la differenza tra le due metriche, puoi Identificare quanta memoria viene utilizzata dai processi rispetto a quanta viene utilizzata dalla cache del sistema operativo. Puoi riutilizzare la memoria questa cache. Per prevedere i problemi di esaurimento della memoria, controlla sia le metriche che interpretarli insieme. Se le metriche sembrano alte, potrebbe avere memoria insufficiente. Ciò può essere dovuto a una configurazione personalizzata sottodimensionato per il carico di lavoro oppure una combinazione 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ù su il 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.
|
Determina la capacità del sottosistema I/O prima di eseguire il deployment di SQL Server. | Testa vari tipi e dimensioni di I/O. Le dimensioni dell'I/O emesso lo spazio di archiviazione su disco permanente SQL Server influisce sulle IOPS e sulla velocità effettiva. Il carico di lavoro di SQL Server viene limitato quando raggiunge il limite di IOPS o il limite di velocità effettiva. La utilizzato in Cloud SQL è PD SSD, adatto per carichi di lavoro a livello aziendale ad alte prestazioni. Personalizza la VM per massimizzare le prestazioni come segue:
|
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'istanza appropriata fattore di riempimento per ridurre la frammentazione. Monitora SQL Server per verificare la presenza di 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 non ottimali. Aggiornare le statistiche soprattutto dopo aver modificato grandi quantità di dati. Utilizzare Query Store per monitorare e risolvere i problemi di SQL Server con piani di query non ottimali. |
Evita che i file di database diventino di dimensioni inutilmente grandi. |
Imposta Inoltre, assicurati che la funzionalità di Cloud SQL Abilita gli aumenti automatici dello spazio di archiviazione sia abilitata, in modo che Cloud SQL può 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 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:
Utilizza i seguenti snippet di codice per eseguire
|
Architettura dei dati
Best practice | Ulteriori informazioni |
---|---|
Se possibile, dividi le istanze di grandi dimensioni in istanze più piccole. | Quando possibile, l'utilizzo di molte istanze Cloud SQL più piccole rispetto a un'istanza di grandi dimensioni. 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. Troppi database possono influire sui tempi di upgrade del database. |
Regole di confronto database |
Sia che tu stia installando una nuova istanza di SQL Server, ripristinando un
di un database o connettere un server ai database client, è importante
per comprendere i requisiti delle impostazioni internazionali, l'ordinamento, le maiuscole e le minuscole
la sensibilità dei dati con cui lavori.
Quando selezioni una regola di confronto per il server, il database, la colonna
, stai assegnando determinate caratteristiche ai tuoi dati.
Queste caratteristiche influenzano i risultati di molte operazioni nel
per configurare un database. Ad esempio, quando crei una query utilizzando ORDER BY ,
l'ordinamento dei risultati potrebbe dipendere dalle regole di confronto
applicati al database o dettati da una clausola COLLATE nel
a livello di espressione della query. Scopri di più su
collazioni del database e supporto Unicode.
|
Progettazione di query | Per prestazioni ottimali su database o query, assicurati di non utilizzare un un numero elevato di tabelle nella stessa query (sedici o più). |
Monitoraggio delle query |
La qualità delle query potrebbe diminuire nel tempo. È importante monitorare
le prestazioni di applicazioni e query nel tempo.
Uno dei motivi di tale degrado è il bailout degli hash. I join hash ricorrenti o i salvataggi di hashing causano una riduzione delle prestazioni in un o server web. Se vedi molti eventi di avviso di hash in una traccia, aggiorna le statistiche sulle colonne che vengono unite. Ulteriori informazioni su salvataggi di hashing. |
Implementazione dell'applicazione
Best practice | Ulteriori informazioni |
---|---|
Usare buone pratiche di gestione delle connessioni, come il pooling delle connessioni e e il backoff esponenziale. | L'utilizzo di queste tecniche migliora l'uso delle risorse da parte dell'applicazione e ti aiuta a rimanere all'interno di Cloud SQL limiti di connessione. Per ulteriori informazioni ed esempi di codice, consulta Gestione delle connessioni ai database |
Testare la risposta della tua applicazione agli aggiornamenti di manutenzione, 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 non è più disponibile per un breve periodo e le connessioni esistenti vengono eliminati. Il test delle implementazioni della manutenzione offre una comprendere in che modo la tua applicazione gestisce la manutenzione pianificata la velocità di ripristino del sistema. |
Testa la risposta della tua applicazione ai failover, avvengono 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, in più transazioni più piccole piuttosto che in una singola transazione di grandi dimensioni. |
Se utilizzi il proxy di autenticazione Cloud SQL, assicurati di utilizzare alla versione aggiornata. | Consulta Conservazione Proxy di autenticazione Cloud SQL aggiornato. |
Importazione ed esportazione di dati
Best practice | Ulteriori informazioni |
---|---|
Velocizza le importazioni per istanze di piccole dimensioni. | Per le istanze di piccole dimensioni, puoi di aumentare CPU e 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 seguire la procedura corretta. | Consulta Esportazione dei 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 dei dati e protezione dei dati. Ciascuno di essi protegge da scenari diversi e integra in una solida strategia di protezione dei dati. I backup sono leggeri, offrono un modo per ripristinare lo stato dei dati sull'istanza al momento dell'acquisizione il backup. Tuttavia, i backup hanno alcune limitazioni. Se elimini il in un'istanza, vengono eliminati anche i backup. Non puoi eseguire il backup di un singolo un database o una tabella. E se la regione in cui si trova l'istanza non è disponibile, non puoi ripristinare l'istanza da quel backup, in una regione disponibile. La creazione delle esportazioni richiede più tempo perché è stato creato un file esterno in Cloud Storage da utilizzare per ricreare i dati. Esportazioni non subiranno modifiche se elimini l'istanza. Inoltre, puoi esportare un solo database o una tabella uniforme, a seconda del formato di esportazione che scegli. Quando utilizzi la funzionalità di esportazione di backup su un'istanza SQL Enterprise o Standard Nell'istanza server, evita di creare un file di archivio GZ perché tenta di comprimi 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, abilita per impostazione predefinita la prevenzione dell'eliminazione accidentale. Utilizza la funzionalità di esportazione di Cloud SQL per esportare i dati per protezione dei dati. Usa Cloud Scheduler con l'API REST per automatizzare l'esportazione gestione dei dispositivi. 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. Le seguenti argomenti descrivono alcuni consigli.
Impostazioni di configurazione globali
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 è calcolate 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
Ad esempio, se la RAM per la tua istanza è 104 GB
Per questo esempio, devi prenotare 16,4 GB di memoria. Di conseguenza, per il valore di questo flag, specifica La tabella seguente contiene valori e percentuali consigliati di RAM totale per alcuni livelli di macchine virtuali (VM) molto diffusi:
Per monitorare l'utilizzo della memoria per l'istanza, usa le seguenti metriche:
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 | Consiglio |
---|---|
cost threshold for parallelism |
Questa è la soglia alla quale lo strumento di ottimizzazione SQL esegue una query
usando il parallelismo. Il valore predefinito Il valore viene ignorato quando il criterio |
max degree of parallelism (MAXDOP) |
Per ridurre i tempi di attesa del database a causa del parallelismo, regola questo valore in base a consigli specifici sul numero di processori logici disponibili. Misurazione il rendimento 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
contenere molti batch ad hoc monouso, imposta questa opzione su |
tempdb |
Predimensiona Il tipo di attesa del database per la contesa 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, usa 8 file di dati. In caso di contesa continua, aumenta il numero di file multipli di 4 finché non ci sono ulteriori contese. |
A seconda del carico di lavoro, potrebbe essere opportuno 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 in T-SQL le API nel tuo codice. Se modifichi questa impostazione, valuta il codice dell'applicazione per qualsiasi effetti negativi. |
Page Verify |
Questa opzione consente a SQL Server di calcolare un checksum per un
pagina del database prima che venga scritta su disco e archivia il checksum
nell'intestazione della pagina. Quando una pagina viene letta di nuovo, il checksum viene
vengono ricalcolati per verificare l'integrità della pagina.
Il valore consigliato è checksum .
|
Parameterization |
Il valore predefinito è simple . Parametrizzazione semplice
consente a SQL Server di sostituire i valori letterali in una query con
parametri. Microsoft fornisce le linee guida su come modificare
valore e utilizzarlo con le guide per la pianificazione.
|
Impostazioni del database da conservare
Per prestazioni ottimali del database SQL Server, mantieni i valori predefiniti di le seguenti impostazioni di SQL Server.
Impostazione | Valore predefinito da conservare |
---|---|
Auto Close
|
False . Quando è attiva, questa impostazione apre e chiude le connessioni
e fa il flush della procedura dopo ogni connessione. Ciò può influire sulle prestazioni
dei database a cui si accede di frequente.
|
Auto Shrink
|
False . L'attivazione può causare problemi di database e indice
frammentazione e altri problemi di prestazioni, alcuni dei quali sono discussi nel
questo blog di SQL Server.
|
Date Correlation Optimization Enabled
|
False . Abilitando questo strumento puoi consentire all'ottimizzatore di trovare e ottimizzare
relazioni tra le date in due tabelle correlate. Monitoraggio in SQL
Il server comporta un certo overhead delle prestazioni.
|
Legacy Cardinality Estimation
|
False . In alcuni casi, SQL Server non è in grado di calcolare con precisione
cardinalità quando 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 sono distribuite in modo non uniforme
dati, i piani di esecuzione risultanti potrebbero portare a problemi di prestazioni.
Con questi dati, utilizza altre opzioni di Query Store anziché modificare i dati.
dell'ambientazione.
|
Query Optimizer Fixes
|
False . Se abilitata, questa opzione può influire sulle prestazioni
Strumento di stima della cardinalità di SQL Server. Se scegli di abilitarla, esegui un test per
assicurati che non ci sia una regressione delle query.
|
Auto Create Statistics
|
True . Questa opzione consente a SQL Server di creare colonne singole
statistiche
che possono migliorare le stime di cardinalità per i piani di query.
|
Auto Update Statistics
|
True . Questa opzione consente a SQL Server di aggiornare
utilizzando una soglia di ricompilazione basata su tabelle
cardinalità.
|
Auto Update Statistics Asynchronously
|
False . Questa opzione, se abilitata, indirizza la query SQL
ottimizzatore per usare le statistiche inattive per l'esecuzione attuale della query,
e aggiornare le statistiche in modo asincrono a vantaggio
dei carichi di lavoro futuri.
Tuttavia, se prevedi un tempo di risposta prevedibile per un
eseguita o se la tua applicazione riscontra spesso
timeout delle richieste mentre sono in attesa di aggiornamenti delle statistiche, ti consigliamo di attivare questa opzione
e la disattivazione di |
Target Recovery Time (Seconds)
|
60 . Questa impostazione stabilisce un limite superiore al recupero
per un database facendo svuotare le pagine "sporche" più o meno frequentemente
dal pool di buffer. Per carichi di lavoro altamente transazionali, un valore più basso
per questa impostazione, combinate 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, 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 i flag di database. La le impostazioni consigliate sono le seguenti.
flag di Trace | Consigliato |
---|---|
1204
|
Yes , ad eccezione dei server ad alta intensità di carico di lavoro che generano
ci sono molti stacchi. e Restituisci le risorse e i tipi di blocchi. che sta partecipando a un deadlock, ma anche del comando attualmente interessato. |
1222
|
Yes , ad eccezione dei server ad alta intensità di carico di lavoro che generano
ci sono molti stacchi.
|
1224
|
No . Ciò può comportare un maggiore utilizzo della memoria e causare
sul database.
|
2528
|
No . Il controllo parallelo degli oggetti è l'impostazione predefinita
consigliato. Il grado di parallelismo viene calcolato automaticamente
e il 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 dispone di un sistema
potrebbe non riuscire a visualizzare tutti i messaggi di errore.
|
4199
|
No . Questo influisce sullo strumento di stima della cardinalità e può portare a
regressione lineare delle query.
|
4616
|
No . Questa limitazione riduce la sicurezza dell'applicazione
ruoli. Deve essere convalidato in base ai requisiti dell'applicazione.
|
7806
|
Yes . Se il server di database non risponde,
una connessione di amministrazione dedicata (DAC) potrebbe essere l'unico modo per creare
per la diagnostica.
|
Passaggi successivi
Per ulteriori informazioni sulle pratiche generali per motore del database, vedi:
- Best practice generali per MySQL
- Best practice generali per PostgreSQL
- Best practice generali per SQL Server