Considerazioni relative all'uso di server di prova

  • Articolo

Si applica a:SQL Server

L'uso 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 usare lo scenario server di prova/server di produzione è necessario abilitare la stored procedure estesa xp_msver. Ottimizzazione guidata motore di database usa questa stored procedure estesa per recuperare le informazioni sul numero di processori e sulla memoria disponibile nel server di produzione da usare per l'ottimizzazione del server di prova. Se xp_msver non è abilitata, l'Ottimizzazione guidata motore di database prende in considerazione le caratteristiche hardware del computer in cui è in esecuzione l’Ottimizzazione guidata motore di database. Se le caratteristiche hardware del computer in cui è in esecuzione Ottimizzazione guidata motore di database non sono disponibili, vengono considerati un processore e 1024 megabyte (MB) di memoria. Questa stored procedure estesa è attiva per impostazione predefinita quando si installa SQL Server. Per altre 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 nel server di prova e nel 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.

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.

  • 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 altre 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 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.

  • 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 di 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. 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.

    • Ottimizzazione guidata motore di database potrebbe consigliare di eliminare le viste indicizzate che impongono 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 consigliare di non selezionare determinati indici, ad esempio gli indici cluster in 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 .