Best practice generali

Questa pagina fornisce le best practice per ottenere il massimo rendimento. 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 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. Vedi Periodo di manutenzione.
Se elimini e crei di nuovo le istanze regolarmente, utilizza un timestamp nell'ID istanza per aumentare la probabilità che i 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 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 è 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 la manutenzione critica del database.

Se l'impostazione dell'istanza Attiva gli incrementi automatici dello spazio di archiviazione è disattivata o se è attivato il limite di aumento automatico dello spazio di archiviazione, assicurati di avere almeno il 20% di spazio disponibile per gestire 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 un criterio di avviso basato sulle metriche per la metrica Utilizzo disco con una posizione sopra la soglia 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 dall'istanza nella pagina dei dettagli dell'istanza in Google Cloud Console. Per ulteriori informazioni, vedi Metriche. Puoi anche monitorare l'utilizzo della CPU e ricevere avvisi a una soglia specificata utilizzando Creare criteri di avviso basati su soglie di 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 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, ti consigliamo di mantenere questa metrica 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 a seconda del carico di lavoro oppure una combinazione questi fattori.

Esegui il ridimensionamento dell'istanza Cloud SQL per aumentare le dimensioni della 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.
  • vCPU: 40
  • Memoria: 262144 MB
  • MAXDOP: 8
  • Soglia di costo per il parallelismo: 120
  • file tempdb: 8. Predimensionato per evitare la crescita automatica.
  • File del database utente: impostazione di crescita automatica in 64-128 MB. Pretagliato per impedire la crescita automatica.
  • Spazio di archiviazione: >= 4TB per le migliori IOPS
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 per l'archiviazione su disco permanente proveniente da SQL Server influiscono 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:

  • Un disco di dimensioni pari o superiori a 4 TB offre una maggiore velocità in termini di throughput e IOPS.
  • Un numero maggiore di vCPU offre più IOPS e una maggiore velocità effettiva. Quando utilizzi un numero maggiore di vCPU, monitora le attese del DB per il parallelismo, che potrebbero aumentare.
  • Per un rendimento ottimale, esegui l'I/O in parallelo per ottenere una maggiore profondità della coda I/O.
Evita la frammentazione degli indici e gli indici mancanti. Riorganizza l'indice o imposta una pianificazione per ricostruirlo in base alla frequenza con cui cambiano i dati. Imposta anche un'istanza appropriata fattore di riempimento per ridurre la frammentazione. Monitora SQL Server per rilevare gli 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 la modifica di 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 del database diventino inutilmente grandi.

Imposta autogrow in MB anziché in percentuale, utilizzando gli incrementi adeguate al requisito. Inoltre, gestisci in modo proattivo la crescita prima dell'attivazione della crescita automatica.

Inoltre, assicurati che la funzionalità Abilita gli aumenti automatici dello spazio di archiviazione di Cloud SQL sia attivata 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 settimanalmente, puoi assicurarti che i tuoi database non siano corrotti. 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 clonato.
  • Ripristina un backup in un'altra istanza, quindi esegui DBCC CHECKDB sull'istanza i database dell'istanza. 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
  • Corri 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, suddividi le istanze di grandi dimensioni in istanze più piccole. Se possibile, è meglio utilizzare molte istanze Cloud SQL di piccole dimensioni anziché 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. Un numero eccessivo di tabelle del database può influire sul tempo di upgrade del database.

Collazione del 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 collating per il server, il database, la colonna o l'espressione, assegni determinate caratteristiche ai 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 di 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 Le query potrebbero peggiorare 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 ricorsivi o le uscite di emergenza hash causano una riduzione delle prestazioni di 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 salvataggi di hash.

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 e esempi di codice, consulta Gestire le connessioni al 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 interrotte. Testare l'implementazione della manutenzione ti consente di comprendere meglio come la tua applicazione gestisce la manutenzione programmata e la rapidità con cui il sistema può recuperare.
Testa la risposta dell'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. Mantieni le transazioni brevi e piccole. 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 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 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 importarli in Cloud SQL, assicurati di seguire la procedura corretta. Consulta Esportare 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. Ognuna protegge da scenari diversi e si completano a vicenda in una strategia di protezione dei dati solida.

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 database o 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 solo un singolo database o anche una tabella, a seconda del formato di esportazione scelto.

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 Run offre funzioni per l'automazione.

Impostazioni di SQL Server

Alcune impostazioni di SQL Server sono consigliate per Cloud SQL. Gli argomenti riportati di seguito 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)

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

Se non imposti un valore per questo flag, Cloud SQL gestisce il valore automaticamente in base alle dimensioni della RAM della tua istanza. Inoltre, se ridimensioni l'istanza, Cloud SQL regola automaticamente il valore del flag per soddisfare i nostri suggerimenti per la nuova dimensione dell'istanza.

Ti consigliamo vivamente di non specificare un valore per questo flag per le tue istanze. Se imposti il valore su un valore superiore all'80%, potresti riscontrare instabilità, peggioramento delle prestazioni e arresti anomali del database a causa di problemi di memoria insufficiente.

Se preferisci gestire il valore di questo flag, impostalo manualmente. Di conseguenza, Cloud SQL disattiva la gestione automatica. Se stai modificando le dimensioni dell'istanza, ti consigliamo di rivedere il valore in modo che corrisponda a quelli consigliati per una nuova dimensione.

Ti consigliamo di utilizzare la seguente formula per impostare il flag del 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 superiori a 16 GB
  • 11 GB di memoria, perché 88 GB di RAM sono superiori a 16 GB (104-16=88) e 88 diviso per 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 seguente tabella contiene i valori e le percentuali consigliati di RAM totale per alcuni livelli di macchine virtuali (VM) di uso comune:

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, 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 ulteriori informazioni, 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 di seguito.

Impostazione Consiglio
cost threshold for parallelism

Questa è la soglia oltre la 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 nei thread paralleli. Per ridurre questo tipo di contesa, aumenta il valore.

Il valore viene ignorato quando maxdop è impostato su 1.

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. Misura attentamente 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 1.

tempdb

Imposta le dimensioni predefinite per tempdb in modo che non debba essere ridimensionato automaticamente. Tutti i file in tempdb devono avere le stesse dimensioni e avere lo stesso set di dati.

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, usa 8 file di dati. Se la contesa persiste, aumenta il numero di file per multipli di 4 finché non si verificano ulteriori conflitti.

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 effettui l'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 eventuali 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 nuovamente calcolato 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 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. La sua attivazione può causare frammentazione del database e dell'indice e altri problemi di prestazioni, alcuni dei quali sono descritti in 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. Il monitoraggio in SQL 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 hanno dati distribuiti in modo non uniforme, i piani di esecuzione risultanti potrebbero causare problemi di prestazioni. Con questi dati, utilizza altre opzioni di Query Store anziché modificare i dati. dell'ambientazione.
Query Optimizer Fixes False. Se abilitato, può influire sulle prestazioni dell'estimatore della cardinalità di SQL Server. Se scegli di attivarla, esegui il test per verificare che non si verifichi una regressione delle query.
Auto Create Statistics True. Questa opzione consente a SQL Server di creare statistiche a una colonna che possono migliorare le stime della cardinalità per i piani di query.
Auto Update Statistics True. Questa opzione consente a SQL Server di aggiornare le statistiche устаревших utilizzando una soglia di ricompilatura basata sulla cardinalità della tabella.
Auto Update Statistics Asynchronously False. Se questa opzione è attivata, lo strumento di ottimizzazione delle query SQL ordina di utilizzare le statistiche non aggiornate per l'esecuzione della query corrente, aggiornando 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 Auto Update Statistics.

Target Recovery Time (Seconds) 60. Questa impostazione stabilisce un limite superiore al tempo di recupero di un database svuotando le pagine sporche sul disco più o meno frequentemente dal pool di buffer. Per i carichi di lavoro altamente transazionali, un valore inferiore per questa impostazione, combinato con le IOPS di archiviazione vicine al valore massimo, può contribuire a creare 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. Le impostazioni consigliate sono le seguenti.

Flag di traccia Consigliato
1204 Yes, ad eccezione dei server con carichi di lavoro elevati che generano molti deadlock.
e
Restituisci le risorse e i tipi di blocchi. che partecipa a un deadlock e anche il comando attualmente interessato.
1222 Yes, ad eccezione dei server con carichi di lavoro elevati che generano molti deadlock.
1224 No. Ciò può comportare un maggiore utilizzo della memoria e causare sul database.
2528 No. Il controllo parallelo degli oggetti è predefinito e 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 amministratore non ha accesso amministrativo al sistema, potrebbe non essere in grado di 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 dei ruoli dell'applicazione. 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: