Considerazioni relative all'uso di server di prova

Si applica a:SQL Server

L'uso di un server di test per ottimizzare un database su un server di produzione è uno dei vantaggi principali di Ottimizzazione guidata motore di database. Attraverso questa funzionalità è possibile ripartire su un server di prova il carico dell'overhead generato dall'ottimizzazione senza copiare i dati effettivi dal server di produzione al server di prova.

Per utilizzare correttamente questa funzionalità, valutare le considerazioni riportate nelle sezioni seguenti.

Configurazione dell'ambiente del server di prova e del server di produzione

• L'utente che desidera utilizzare un server di prova per ottimizzare un database su un server di produzione deve essere presente su entrambi i server, altrimenti l'operazione non riuscirà.

• Per usare lo scenario server di prova/server di produzione è necessario abilitare la stored procedure estesa xp_msver. Consulente per l'ottimizzazione del motore di database usa questa stored procedure estesa per recuperare il numero di processori e la memoria disponibile del server di produzione da utilizzare durante l'ottimizzazione del server di test. Se xp_msver non è attivata, Ottimizzazione guidata Motore di database presuppone le caratteristiche hardware del computer in cui è in esecuzione Ottimizzazione guidata Motore di database. Se le caratteristiche hardware del computer in cui è in esecuzione Ottimizzazione guidata motore di database non sono note, si presume la presenza di un processore e di 1024 megabyte (MB) di memoria. Questa stored procedure estesa è abilitata per impostazione predefinita durante l'installazione di SQL Server. Per ulteriori informazioni, vedere Configurazione dell'area di superficie e xp_msver (Transact-SQL).

• Ottimizzazione guidata del Motore di database richiede che le edizioni di SQL Server siano le stesse sia nel server di test sia nel server di produzione. In caso contrario, l'edizione in uso nel server di prova ha la precedenza. Ad esempio, se il server di test esegue SQL Server Standard, il Ottimizzazione guidata motore di database non includerà nelle raccomandazioni le viste indicizzate, il partizionamento e le operazioni online, anche se il server di produzione esegue SQL Server Enterprise.

Informazioni sul comportamento del server di prova e del server di produzione

• Ottimizzazione guidata motore di database tiene conto delle differenze hardware tra il server di produzione e il server di test durante la creazione delle raccomandazioni. L'indicazione è identica a quella che verrebbe generata nel caso in cui l'ottimizzazione venisse eseguita sul solo server di produzione.

• Ottimizzazione guidata motore di database può imporre un certo carico sul server di produzione durante la raccolta dei metadati e la creazione delle statistiche necessarie per l'ottimizzazione.

• Ottimizzazione guidata motore di database non copia i dati reali dal server di produzione al server di test. Vengono copiati unicamente i metadati dei database e le necessarie statistiche.

• Tutte le informazioni sulla sessione vengono archiviate in msdb sul server di produzione. In questo modo, per eseguire l'ottimizzazione è possibile utilizzare qualsiasi server di prova disponibile, mentre le informazioni relative a tutte le sessioni si trovano in un'unica posizione, ovvero sul server di produzione.

Problemi relativi al database della shell

• Dopo l'ottimizzazione, l'Ottimizzazione guidata motore di database dovrebbe rimuovere tutti i metadati creati sul server di prova durante il processo di ottimizzazione. Questo include anche il database della shell. Se si stanno eseguendo più sessioni di ottimizzazione utilizzando gli stessi server di produzione e di prova, è possibile conservare lo scheletro di database per risparmiare tempo. Nel file di input XML specificare il sottoelemento RetainShellDB insieme agli altri sottoelementi all'interno dell'elemento padre TuningOptions . L'uso di queste opzioni fa sì che Ottimizzazione guidata Motore di database conservi il database shell. Per ulteriori informazioni, vedere Riferimento ai file di input XML (Ottimizzazione guidata del motore di database).

• Dopo una sessione di ottimizzazione riuscita che prevede l'utilizzo combinato di un server di prova e un server di produzione, è possibile che gli scheletri di database rimangano nel server di prova, anche se non è stato usato il sottoelemento RetainShellDB . Tali scheletri di database indesiderati possono interferire con le sessioni di ottimizzazione successive e devono essere eliminati prima di eseguire una nuova sessione di ottimizzazione che prevede l'utilizzo combinato di un server di prova e un server di produzione. Inoltre, se una sessione di ottimizzazione si interrompe in modo imprevisto, è possibile che gli scheletri di database nei server di prova e gli oggetti presenti in tali database rimangano nei server di prova. Prima di avviare una nuova sessione di ottimizzazione che prevede l'utilizzo combinato di un server di prova e un server di produzione è necessario eliminare anche tali database e oggetti.

Problemi relativi al processo di ottimizzazione

• L'utente deve controllare il contenuto del log di ottimizzazione per individuare eventuali errori di ottimizzazione causati dalle differenze esistenti tra il server di produzione e quello di prova ed errori risultanti dalla copia dei metadati dal server di produzione a quello di prova. Potrebbe ad esempio accadere che l'account di accesso di un utente non esista sul server di prova. Se l'account di accesso di un utente non è presente sul server di prova, gli eventi nel carico di lavoro generati da quell'utente potrebbero non essere ottimizzabili. Utilizzare la GUI di Ottimizzazione guidata motore di database per visualizzare il log di ottimizzazione. Per altre informazioni, vedere Visualizzare e utilizzare l'output generato da Ottimizzazione guidata motore di database

• Se Ottimizzazione guidata motore di database non riesce a ottimizzare molti eventi perché alcuni oggetti risultano mancanti nello scheletro di database creato da Ottimizzazione guidata motore di database nel server di prova, l'utente deve controllare il log di ottimizzazione. Gli eventi che non possono essere regolati sono elencati nel registro. Per ottimizzare correttamente il database sul server di prova, è necessario che l'utente crei gli oggetti mancanti nello scheletro di database e che quindi avvii una nuova sessione di ottimizzazione

• Se sul server di prova esiste già un database con lo stesso nome, l'Ottimizzazione guidata Motore di database non copia i metadati, ma continua l'ottimizzazione e raccoglie le statistiche necessarie. Questa funzionalità è utile nel caso in cui l'utente abbia già creato un database sul server di prova e abbia copiato i metadati appropriati prima di eseguire Ottimizzazione guidata motore di database.

• Se sul server di produzione è stata attivata l'opzione DATE_CORRELATION_OPTIMIZATION per un database, i metadati e i dati associati a questa opzione non vengono inseriti completamente in uno script durante l'ottimizzazione del server di prova. Quando l'ottimizzazione viene eseguita in uno scenario con server di prova/server di produzione, possono verificarsi i problemi seguenti:

  • Gli utenti possono avere piani di query diversi sui server per le query che utilizzano l'opzione DATE_CORRELATION_OPTIMIZATION.

  • Ottimizzazione guidata motore di database potrebbe suggerire di eliminare le viste con indice che applicano l'opzione DATE_CORRELATION_OPTIMIZATION nello script di raccomandazione.

  È pertanto possibile ignorare le indicazioni generate da Ottimizzazione guidata motore di database per le viste indicizzate relative alle statistiche di correlazione, dato che Ottimizzazione guidata motore di database ne conosce i costi ma non i vantaggi. Ottimizzazione guidata del motore di database potrebbe non consigliare la selezione di determinati indici, ad esempio gli indici clusterizzati su colonne datetime, che potrebbero risultare utili quando l'opzione DATE_CORRELATION_OPTIMIZATION è abilitata.

  Per determinare se una vista è basata su statistiche di correlazione, selezionare la colonna is_date_correlation_view della vista del catalogo sys.views .