Best practice generali

Questa pagina fornisce le best practice per ottenere il massimo livello di prestazioni, durabilità e affidabilità 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 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 per controllare quando possono verificarsi aggiornamenti che causano interruzioni. Consulta Periodo di manutenzione.
Se elimini e ricrei regolarmente le istanze, utilizza un timestamp nell'ID istanza per aumentare la probabilità che i nuovi ID istanza siano utilizzabili.
Non avviare un'operazione amministrativa prima che l'operazione precedente sia stata completata.

Le istanze Cloud SQL non accetteranno nuove richieste di operazioni finché non avranno completato l'operazione precedente. Se tenti di avviare una nuova operazione prematuramente, 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 verificare se un'operazione è in esecuzione, vai alla scheda Operazioni e controlla lo stato dell'operazione più recente.

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

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

Per ricevere un avviso quando lo spazio su disco disponibile scende al di sotto del 20%, crea una criterio di avviso basata sulle metriche per la metrica Utilizzo del disco con una posizione Sopra la soglia e un valore di 0,8. Per saperne di più, consulta Crea policy di avviso basate 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 saperne di più, consulta Metriche. Puoi anche monitorare l'utilizzo della CPU e ricevere avvisi in corrispondenza di una soglia specificata utilizzando Crea policy di avviso basate su soglie metriche.

Per evitare un utilizzo eccessivo, puoi aumentare il numero di CPU per la tua istanza. La modifica delle CPU richiede il riavvio dell'istanza. Se la tua istanza ha già raggiunto il numero massimo di CPU, devi eseguire lo sharding del database in più istanze.
Evita l'esaurimento della memoria.

Quando cerchi segni di esaurimento della memoria, devi utilizzare principalmente la metrica usage. Per evitare errori di memoria esaurita, ti consigliamo di mantenere questa metrica 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 l'allocazione della memoria da parte della 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 memoria esaurita, controlla entrambe le metriche e interpretale insieme. Se le metriche appaiono elevate, l'istanza potrebbe avere poca memoria. Ciò può essere dovuto a una configurazione personalizzata, a un'istanza sottodimensionata per il workload o a una combinazione di questi fattori.

Scala l'istanza Cloud SQL per aumentare le dimensioni della memoria. La modifica della dimensione 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. Consulta Impostazioni di SQL Server.
Ottimizza l'istanza 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-dimensionato per impedire la crescita automatica.
  • File di database utente: crescita automatica impostata su 64-128 MB. Pre-dimensionato per impedire la crescita automatica.
  • Spazio di archiviazione: >= 4TB per le migliori IOPS
Determina la capacità del sottosistema di 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 sulle IOPS e sul throughput. Il workload di SQL Server viene limitato quando raggiunge il limite di IOPS o di throughput. Il tipo di archiviazione utilizzato in Cloud SQL è un disco permanente SSD, adatto per workload di livello aziendale ad alte prestazioni.

Personalizza la VM per massimizzare le prestazioni nel seguente modo:

  • Un disco di dimensioni pari o superiori a 4 TB offre un throughput e un numero di IOPS maggiori.
  • Un numero maggiore di vCPU fornisce più IOPS e throughput. Quando utilizzi una vCPU più elevata, monitora le attese del database per il parallelismo, che potrebbero anche aumentare.
  • Per prestazioni ottimali, esegui l'I/O in parallelo per ottenere una profondità della coda di I/O più elevata.
Previeni la frammentazione dell'indice e gli indici mancanti. Riorganizza l'indice o configura una pianificazione per ricreare l'indice in base alla frequenza con cui cambiano i dati. Inoltre, imposta 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 non sono aggiornate, l'ottimizzatore delle query SQL potrebbe generare piani di query non ottimali. Aggiorna le statistiche, soprattutto dopo la modifica di grandi quantità di dati. Utilizza l'archivio query per monitorare e risolvere i problemi di SQL Server con piani di query non ottimali.
Impedire che i file di database diventino inutilmente grandi.

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

Inoltre, assicurati che la funzionalità Abilita gli incrementi 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 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 un utilizzo intensivo delle 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 clonato.
  • 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 Ripristina 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

Ottimizza le prestazioni

Per garantire la sicurezza dei dati e il corretto funzionamento delle applicazioni con le tabelle OLTP in-memory, valuta la possibilità di applicare le seguenti best practice:

Best practice Ulteriori informazioni
Rispetta le best practice di Microsoft per le tabelle ottimizzate per la memoria
  • Backup regolari: assicurati di aver pianificato backup regolari per i tuoi database. In caso di danneggiamento dei dati, questo ti consente di ripristinarli all'ultimo stato sicuro noto.
  • Verifica del backup: poiché le opzioni di riparazione DBCC non sono disponibili per le tabelle ottimizzate per la memoria, ti consigliamo di testare il backup eseguendo ripristini periodici. Se si verificano problemi di integrità dei dati in una tabella ottimizzato per la memoria, devi eseguire il ripristino dall'ultimo backup sicuro noto.

Per saperne di più sulle limitazioni, consulta Funzionalità di SQL Server non supportate per OLTP in memoria.

Sicurezza

Best practice Ulteriori informazioni
Preferisci IP privato A meno che non sia richiesto l'accesso con IP pubblico, preferisci l'utilizzo di un IP privato. In questo modo, contribuirai a ridurre al minimo le connessioni di rete non autorizzate al tuo database.
Evita 0.0.0.0/0 nelle reti autorizzate Evita di includere 0.0.0.0/0 nelle reti autorizzate, poiché ciò consente l'accesso da internet globale senza limitazioni.
Evita reti autorizzate troppo grandi Evita di utilizzare prefissi CIDR di piccole dimensioni in Reti autorizzate, poiché ciò consente l'accesso da un numero potenzialmente eccessivo di host. Ti consigliamo un prefisso CIDR non inferiore a /16 e preferibilmente superiore a /19.

Architettura dei dati

Best practice Ulteriori informazioni
Se possibile, suddividi le istanze di grandi dimensioni in istanze più piccole. Quando possibile, è meglio utilizzare molte istanze Cloud SQL più piccole anziché un'unica istanza di grandi dimensioni. La gestione di un'istanza monolitica di grandi dimensioni presenta sfide che non si presentano con un gruppo di istanze più piccole.
Non utilizzare troppe tabelle di database.

Mantieni il numero di tabelle dell'istanza inferiore a 10.000. Un numero eccessivo di tabelle del database può influire sul tempo di upgrade del database.

Regole di confronto del database Che tu stia installando una nuova istanza di SQL Server, ripristinando un backup del database o connettendo un server ai database client, è importante comprendere i requisiti relativi alle impostazioni internazionali, l'ordinamento e la sensibilità alle maiuscole e agli accenti dei dati con cui stai lavorando. Quando selezioni una regole 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 dalla regole di confronto applicate al database o dettate in una clausola COLLATE a livello di espressione della query. Scopri di più sulle regole di confronto dei database e sul supporto di Unicode.
Progettazione di query Per prestazioni ottimali del database o delle query, assicurati di non utilizzare un numero elevato di tabelle all'interno della stessa query (16 o più).
Monitoraggio delle query Le query potrebbero peggiorare nel tempo. È importante monitorare le prestazioni dell'applicazione e delle query nel tempo. Uno dei motivi di questo peggioramento sono i bailout degli hash.
I join hash ricorsivi o i bailout hash causano una riduzione delle prestazioni in un server. Se in una traccia vengono visualizzati molti eventi di avviso di hash, aggiorna le statistiche sulle colonne che vengono unite. Scopri di più sui bailout degli hash.

Implementazione delle applicazioni

Best practice Ulteriori informazioni
Utilizza buone pratiche di gestione delle connessioni, come il pooling delle connessioni e il backoff esponenziale. L'utilizzo di queste tecniche migliora l'utilizzo delle risorse da parte dell'applicazione e ti aiuta a rispettare i limiti di connessione di Cloud SQL. Per saperne di più ed esempi di codice, consulta Gestisci le connessioni ai 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 diventa non disponibile per un breve periodo e le connessioni esistenti vengono interrotte. Il test delle implementazioni di manutenzione ti consente di comprendere meglio il modo in cui l'applicazione gestisce la manutenzione pianificata e la velocità con cui il sistema può eseguire il recupero.
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. Mantieni le transazioni piccole e brevi. Se è necessario un aggiornamento di un database di grandi dimensioni, eseguilo in diverse transazioni più piccole anziché in un'unica transazione di grandi dimensioni.
Se utilizzi il proxy di autenticazione Cloud SQL, assicurati di utilizzare la versione più aggiornata. Consulta Mantieni aggiornato il Cloud SQL Auth Proxy.

Importazione ed esportazione di dati

Best practice Ulteriori informazioni
Velocizza le importazioni per istanze di piccole dimensioni. Per le 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 l'importazione in Cloud SQL, assicurati di utilizzare 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 la funzionalità Cloud SQL appropriata.

I backup e le esportazioni sono modi per fornire ridondanza e protezione dei dati. Ognuna di queste funzionalità protegge da scenari diversi e si integra con le altre in una solida strategia di protezione dei dati.

I backup sono leggeri e consentono di ripristinare i dati dell'istanza allo stato in cui erano al momento del backup. Tuttavia, i backup presentano 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. Se la regione in cui si trova l'istanza non è disponibile, non puoi ripristinare l'istanza da quel backup, nemmeno 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. Le esportazioni non vengono interessate se elimini l'istanza. Inoltre, puoi esportare un singolo database o anche una singola tabella, a seconda del formato di esportazione scelto.

Quando utilizzi la funzionalità di esportazione del 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 attiva la prevenzione dell'eliminazione accidentale per impostazione predefinita.

Utilizza la funzionalità di esportazione in Cloud SQL per esportare i dati per una protezione aggiuntiva. Utilizza Cloud Scheduler con l'API REST per automatizzare la gestione delle esportazioni. Per scenari più avanzati, Cloud Scheduler con Cloud Run 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)

Questo flag limita la quantità di memoria che Cloud SQL può allocare per i suoi pool interni.

Ti consigliamo di lasciare che sia Cloud SQL a gestire il valore di questo flag. Se devi gestire manualmente questo valore, utilizza la formula descritta più avanti in questa sezione.

Se non imposti un valore per questo flag, Cloud SQL gestisce il valore automaticamente, in base alle dimensioni della RAM per l'istanza. Se non imposti un valore per il flag e ridimensioni l'istanza, Cloud SQL regola automaticamente il valore del flag in modo da soddisfare i nostri suggerimenti per la nuova dimensione dell'istanza. Questa operazione di ridimensionamento rimuove anche qualsiasi valore impostato manualmente per questo flag. In questo modo, il database utilizza le risorse in modo più efficace, evitando l'allocazione eccessiva, riducendo la probabilità di un arresto anomalo dovuto a problemi di memoria insufficiente e contribuendo a evitare il peggioramento delle prestazioni dell'istanza.

Se preferisci gestire il valore di questo flag, impostalo manualmente. Di conseguenza, Cloud SQL disattiva la gestione automatica. Se ridimensioni l'istanza, il valore inserito manualmente viene ignorato. Il ridimensionamento dell'istanza riattiva la gestione automatica dei flag. Se, dopo il ridimensionamento, vuoi controllare manualmente il valore del flag, devi inserire un nuovo valore per riattivare il controllo manuale. Valuta la possibilità di rivedere il valore in modo che corrisponda ai valori consigliati per una nuova dimensione.

Se devi gestire manualmente il valore del flag, ti consigliamo di utilizzare la seguente formula per impostare il flag di database max server memory (mb):

  • Prenota 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 della tua istanza è di 104 GB
(106.496 MB), prenota:

  • 1,4 GB di memoria per il sistema operativo e gli agenti
  • 4 GB di memoria, perché 104 GB è maggiore di 16 GB
  • 11 GB di memoria, perché ci sono 88 GB di RAM, ovvero più di 16 GB (104-16=88) e 88 diviso 8 è 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 i valori e le percentuali consigliati della RAM totale per alcuni livelli di macchine virtuali (VM) più diffusi:

Livello istanza (MB) max server memory (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 la memoria utilizzata per l'istanza, utilizza le seguenti metriche:

  • 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 Monitora 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 nella tabella seguente.

Impostazione Suggerimento
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 conflitto, aumenta il valore.

Il valore viene ignorato quando maxdop è impostato su 1.

max degree of parallelism (MAXDOP)

Per ridurre le attese del database dovute al parallelismo, modifica questo valore in base ai suggerimenti specifici sul numero di processori logici disponibili. Misura attentamente le prestazioni se imposti questa opzione su 1.

Per ulteriori informazioni, vedi max degree of parallelism (MAXDOP).

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 workload che contengono molti batch ad hoc monouso, imposta questa opzione su 1.

tempdb

Pre-dimensiona tempdb in modo che non sia necessario l'autocrescita. Tutti i file in tempdb devono avere le stesse dimensioni e lo stesso set 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 8, utilizza 8 file di dati. Se il conflitto persiste, aumenta il numero di file di multipli di 4 finché non viene risolto.

A seconda del workload, 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 il codice dell'applicazione per verificare se ci sono effetti negativi.
Page Verify Questa opzione consente a SQL Server di calcolare un checksum per una pagina del 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 i valori letterali di una query con i parametri. Microsoft fornisce linee guida su come modificare questo valore e utilizzarlo con le guide di piano.

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. Se questa impostazione è attiva, apre e chiude le connessioni e svuota 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 di questa opzione 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 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 i dati nelle tabelle non sono distribuiti in modo uniforme, i piani di esecuzione risultanti potrebbero causare problemi di prestazioni. Con questi dati, utilizza altre opzioni di 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 attivarla, esegui un test per assicurarti che non si verifichi una regressione delle query.
Auto Create Statistics True. Questa opzione consente a SQL Server di creare statistiche su una singola colonna 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 non aggiornate utilizzando una soglia di ricompilazione basata sulla cardinalità della tabella.
Auto Update Statistics Asynchronously False. Se abilitata, questa opzione indica all'ottimizzatore delle query SQL di utilizzare le statistiche non aggiornate per l'esecuzione della query corrente, aggiornando al contempo le statistiche in modo asincrono per i workload 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 delle statistiche, valuta la possibilità di attivare questa opzione e disattivare Auto Update Statistics.

Target Recovery Time (Seconds) 60. Questa impostazione stabilisce un limite superiore per il tempo di recupero di un database svuotando le pagine dirty più o meno frequentemente sul disco dal pool di buffer. Per i workload con un numero elevato di transazioni, un valore inferiore per questa impostazione, combinato con le IOPS di archiviazione vicine al valore massimo, può contribuire a un collo di bottiglia delle prestazioni.

Impostazioni dei 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 i flag di database. Le impostazioni consigliate sono le seguenti.

Flag di Trace Consigliato
1204 Yes, ad eccezione dei server con workload intensivi che generano molti deadlock.

Restituisce le risorse e i tipi di blocchi che partecipano a un deadlock, nonché il comando attualmente interessato.
1222 Yes, ad eccezione dei server con workload intensivi che generano molti deadlock.
1224 No. Ciò può comportare una maggiore memoria utilizzata e causare 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à nastro per i backup sono una funzionalità di Cloud SQL per SQL Server.
3226 No, a meno che non siano necessari backup frequenti, come i backup TLOG.
3625 No. Poiché l'account root non dispone dell'accesso come amministratore di sistema, potrebbe non essere in grado di visualizzare tutti i messaggi di errore.
4199 No. Ciò influisce sullo strumento di stima della cardinalità e può portare alla regressione delle query.
4616 No. Questa limitazione riduce la sicurezza dei ruoli dell'applicazione. Deve essere convalidato in base ai requisiti dell'applicazione.