Considerazioni relative all'utilizzo di server di prova

L'utilizzo di un server di prova per ottimizzare un database su un server di produzione è un importante vantaggio offerto da 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.

[!NOTA]

La funzionalità di ottimizzazione del server di prova non è supportata nell'interfaccia utente grafica (GUI) di Ottimizzazione guidata Motore di database.

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 utilizzare lo scenario server di prova/server di produzione è necessario abilitare la stored procedure estesa xp_msver. Ottimizzazione guidata Motore di database utilizza questa stored procedure estesa per recuperare le informazioni sul numero di processori e sulla memoria disponibile sul server di produzione da utilizzare nell'ottimizzazione del server di prova. Se xp_msver non è abilitata, Ottimizzazione guidata Motore di database utilizza le caratteristiche hardware del computer in cui è in esecuzione. Se le caratteristiche hardware del computer su cui Ottimizzazione guidata Motore di database è in esecuzione non sono disponibili, si suppone che siano disponibili un processore e 1024 MB di memoria. Questa stored procedure estesa è attiva per impostazione predefinita quando si installa SQL Server. Per ulteriori informazioni, vedere Configurazione superficie di attacco e xp_msver (Transact-SQL).

  • Ottimizzazione guidata Motore di database prevede che le edizioni di SQL Server siano identiche sul server di prova e sul server di produzione. In caso contrario, l'edizione in uso nel server di prova ha la precedenza. Ad esempio, se nel server di prova è in esecuzione SQL Server Standard Edition, Ottimizzazione guidata Motore di database non includerà tra le indicazioni le viste indicizzate, il partizionamento e le operazioni online, anche se nel server di produzione è in esecuzione SQL Server Enterprise Edition.

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

  • Nella generazione delle indicazioni, Ottimizzazione guidata Motore di database tiene in considerazione le differenze hardware esistenti tra il server di produzione e il server di prova. 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 carico aggiuntivo al server di produzione per la raccolta dei metadati e per la creazione delle statistiche necessarie per eseguire l'ottimizzazione.

  • Ottimizzazione guidata Motore di database non copia i dati effettivi dal server di produzione sul server di prova, 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 allo scheletro di database

  • Dopo aver eseguito l'ottimizzazione, Ottimizzazione guidata Motore di database rimuove tutti i metadati creati sul server di prova durante il processo di ottimizzazione. Viene rimosso anche lo scheletro di database. 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'utilizzo di queste opzioni specifica a Ottimizzazione guidata Motore di database di conservare lo scheletro di database. Per ulteriori informazioni, vedere Guida di riferimento ai file di input XML (Ottimizzazione guidata 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 utilizzato 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 ulteriori informazioni, vedere Visualizzare e utilizzare l'output di Ottimizzazione guidata motore di database

  • Se è impossibile ottimizzare numerosi eventi perché nello scheletro di database creato sul server di prova da Ottimizzazione guidata Motore di database mancano alcuni oggetti, l'utente deve controllare il log di ottimizzazione. In questo log sono elencati gli eventi che non è possibile ottimizzare. 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, Ottimizzazione guidata Motore di database non copia i metadati, continua l'ottimizzazione e procede con la raccolta delle 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:

    • Possono essere presenti utenti con piani di query differenti sui server per query che utilizzano l'opzione DATE_CORRELATION_OPTIMIZATION.

    • È possibile che Ottimizzazione guidata Motore di database consigli di eliminare le viste indicizzate che applicano l'opzione DATE_CORRELATION_OPTIMIZATION nello script di indicazioni.

    È 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 Motore di database potrebbe non indicare di selezionare determinati indici, ad esempio indici cluster su colonne datetime, che potrebbero risultare vantaggiosi 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.