Condividi tramite

Considerazioni relative all'utilizzo di server di prova

  • Articolo

L'uso di un server di test per ottimizzare un database in un server di produzione è un vantaggio importante 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.

Nota

La funzionalità di ottimizzazione del server di test non è supportata nella Ottimizzazione guidata motore di database interfaccia utente grafica (GUI).

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 il numero di processori e la memoria disponibile del server di produzione da usare durante l'ottimizzazione del server di test. Se xp_msver non è abilitato, 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 disponibili, vengono considerati un processore e 1024 megabyte (MB) di memoria. Questa stored procedure estesa viene attivata per impostazione predefinita quando si installa SQL Server. Per altre informazioni, vedere Configurazione area di superficie e xp_msver (Transact-SQL).

  • Ottimizzazione guidata motore di database prevede che le edizioni di SQL Server siano uguali sia nel server di test che 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 è in esecuzione SQL Server Standard, Ottimizzazione guidata motore di database non includerà visualizzazioni indicizzate, partizionamento e operazioni online nelle relative raccomandazioni anche se il server di produzione è in esecuzione 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 la produzione e il server di test durante la creazione di 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 carico sul server di produzione per raccogliere metadati e la creazione di statistiche necessarie per l'ottimizzazione.

  • Ottimizzazione guidata motore di database non copia i dati effettivi 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.

  • Dopo l'ottimizzazione, Ottimizzazione guidata motore di database deve rimuovere tutti i metadati creati nel server di test 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'uso di queste opzioni causa Ottimizzazione guidata motore di database conservare il database della shell. Per altre informazioni, vedere Riferimento al 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. Usare l'interfaccia utente utente 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 è in grado di ottimizzare molti eventi perché gli oggetti mancano nel database della shell che Ottimizzazione guidata motore di database crea nel server di test, 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 un database con lo stesso nome esiste già nel server di test, Ottimizzazione guidata motore di database non copia i metadati, ma continua l'ottimizzazione e raccoglie le statistiche in base alle esigenze. Questo è utile se l'utente ha già creato un database nel server di test e ha copiato i metadati appropriati prima di richiamare 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 può suggerire l'eliminazione di visualizzazioni indicizzate che applicano l'opzione DATE_CORRELATION_OPTIMIZATION nello script di raccomandazione.

    È pertanto possibile ignorare eventuali raccomandazioni che Ottimizzazione guidata motore di database fanno informazioni sulle visualizzazioni indicizzate che contengono statistiche di correlazione perché Ottimizzazione guidata motore di database conosce i costi, ma non i relativi vantaggi. Ottimizzazione guidata motore di database potrebbe non consigliare la selezione di determinati indici, ad esempio gli indici cluster nelle colonne datetime, che potrebbero risultare utili quando DATE_CORRELATION_OPTIMIZATION è abilitato.

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