Differenze di funzionamento delle funzionalità del Motore di database in SQL Server 2008
In questo argomento vengono descritte le modifiche nel comportamento introdotte nel Motore di database. Tali modifiche influiscono sulle modalità di utilizzo o di interazione delle funzionalità di SQL Server 2008 rispetto alle versioni precedenti di SQL Server.
SQL Server Agent
Modifiche al comportamento di script per un'attività di SQL Server Agent.
Se in SQL Server 2008 si crea un nuovo processo copiando lo script da un processo esistente, il nuovo processo potrebbe influire inavvertitamente sul processo esistente. Per creare un nuovo processo utilizzando lo script di un processo esistente, eliminare manualmente il parametro @schedule\_uid, che generalmente è l'ultimo parametro della sezione che crea la pianificazione nel processo esistente. In questo modo verrà creata una nuova pianificazione indipendente per il nuovo processo senza influire sui processi esistenti.
Opzioni della cache di controllo dell'accesso
In SQL Server 2005 non è possibile configurare la struttura interna access check result cache se non mediante l'utilizzo dei flag di traccia. In SQL Server 2008 è possibile utilizzare le opzioni access check cache per modificare tale struttura. Per ulteriori informazioni, vedere Opzioni access check cache.
Ricerca full-text
In SQL Server 2008 è stata introdotta una nuova architettura di ricerca full-text Anziché essere fornito come servizio separato, il motore di ricerca full-text è ora completamente integrato nel Motore di database di SQL Server. L'integrazione offre miglioramenti in termini di prestazioni, protezione, scalabilità e gestibilità della ricerca full-text rispetto alle versioni precedenti di SQL Server. Per ulteriori informazioni sulle principali differenze tra la ricerca full-text in SQL Server 2005 e in SQL Server 2008, nonché sulle procedure consigliate associate al nuovo motore di ricerca full-text integrato, vedere l'articolo tecnico "SQL Server 2008 Full-Text Search: Internals and Enhancements" in MSDN.
Server collegati
In SQL Server 2008 è cambiata la semantica delle transazioni per le istruzioni INSERT...EXECUTE in esecuzione in un server loopback collegato. In SQL Server 2005 questo scenario non è supportato e genera un errore. In SQL Server 2008 è possibile eseguire un'istruzione INSERT...EXECUTE su un server loopback collegato quando per la connessione non è abilitato MARS (Multiple Active Result Set). Quando MARS è abilitato nella connessione, il comportamento è identico a quello di SQL Server 2005.
Parallelismo
Elaborazione di query su tabelle partizionate e parallelismo
In SQL Server 2008 i miglioramenti apportati alla progettazione di tabelle partizionate favoriscono il parallelismo durante l'elaborazione di query su tabelle partizionate rispetto a quanto avviene in SQL Server 2005. Una delle conseguenze di queste modifiche alla progettazione consiste nella possibilità di collocare solo join a due vie. I piani di query relativi a join collocati a due vie in SQL Server 2008 sono simili, anche nelle prestazioni, a quelli disponibili in SQL Server 2005. Se nel join vengono incluse ulteriori tabelle con partizionamento allineato, viene selezionato un piano diverso, ad esempio un join collocato a due vie seguito da un hash join con la terza tabella. I join collocati tra più di due tabelle non sono comuni e non si avvalgono dei miglioramenti al parallelismo introdotti da SQL Server 2008. Nel caso invece di una query per la quale in SQL Server 2005 viene eseguito un join collocato a tre o più vie, è possibile che la query in questione venga eseguita più lentamente in SQL Server 2008 se la quantità di memoria è ridotta rispetto alle dimensioni delle tabelle. Uno dei sistemi validi per il miglioramento delle prestazioni in situazioni del genere consiste nell'aumento della memoria disponibile e nella successiva riscrittura della query in modo da creare join distinti per le singole partizioni prima di combinare i risultati. Per ulteriori informazioni sui join collocati, vedere Miglioramenti apportati all'elaborazione di query su tabelle e indici partizionati.
Join a stella e parallelismo
In SQL Server è disponibile una nuova soluzione di ottimizzazione per l'elaborazione delle query con join a stella che prevede l'utilizzo di hash join e filtri bitmap. Quando in una query vengono elaborate grandi quantità di dati derivanti dal join di tabelle dei fatti e di tabelle delle dimensioni in uno schema a stella, un piano di query basato sull'utilizzo del nuovo sistema di ottimizzazione può presentare tempi di esecuzione più rapidi.
Potrebbe pertanto essere disponibile un nuovo piano di query per le query esistenti, se queste rispettano lo schema di join a stella. Query Optimizer sceglie tale piano quando le stime elaborate indicano la possibilità di incremento delle prestazioni. Se, tuttavia, le statistiche utilizzate nella stima dei costi non sono precise, è possibile che venga scelta la soluzione di ottimizzazione con join a stella laddove un piano diverso potrebbe risultare più rapido.
Se l'opzione di configurazione max degree of parallelism o l'opzione di indice MAXDOP viene impostata su 1, la soluzione di ottimizzazione con join a stella non verrà utilizzata e non sarà possibile sfruttarne i vantaggi. Se il sistema di esecuzione delle query recapita una query ottimizzata con un piano parallelo contenente un solo thread, è possibile che alcuni filtri bitmap vengano rimossi da un piano di join a stella con più filtri bitmap. Questa modifica potrebbe rallentare l'esecuzione più del previsto nei casi ad esempio in cui si passa da due a un thread.
La soluzione di ottimizzazione con join a stella è disponibile solo nelle edizioni Enterprise, Developer ed Evaluation di SQL Server. Per ulteriori informazioni sull'applicazione di filtri bitmap, vedere Ottimizzazione delle prestazioni di esecuzione delle query del data warehouse tramite l'applicazione di filtri bitmap. Per ulteriori informazioni sull'interpretazione dei piani di query contenenti filtri bitmap, vedere Interpretazione dei piani di esecuzione che contengono filtri bitmap. Per ulteriori informazioni sulla soluzione di ottimizzazione con join a stella, vedere l'articolo di TechNet Magazine "Prestazioni delle query nel data warehouse".
Parallelismo per un numero ridotto di righe esterne
SQL Server 2008 facilita il parallelismo di join nested loop nei casi in cui il lato esterno del join presenta solo un numero ridotto di righe. In SQL Server 2005, se sono disponibili più thread, a ognuno viene allocata una pagina di righe del lato esterno del join. Se il numero di righe presenti è ridotto, è probabile che si trovino tutte nella stessa pagina. In questi casi viene impiegato un solo thread e vengono persi i vantaggi derivanti dal parallelismo. Tali casi sono riconosciuti da SQL Server 2008, che introduce quindi un nuovo operatore di scambio che consente di allocare una riga per thread in modo da utilizzare tutte le CPU disponibili. Il parallelismo incrementato determina un aumento temporaneo dell'utilizzo della CPU rispetto a quanto avviene in SQL Server 2005, ma consente anche una velocizzazione dell'esecuzione delle query. Questo nuovo comportamento è evidente solo se il numero di righe esterne è ridotto e se il costo stimato della query è sufficientemente grande da sfruttare i vantaggi del parallelismo aggiuntivo. Se il costo stimato della query è ridotto o la cardinalità stimata per il lato esterno è superiore a 1000, in SQL Server verrà eseguita l'allocazione di una pagina per thread come in SQL Server 2005. Per ulteriori informazioni sugli operatori di scambio e sull'elaborazione parallela di query, vedere Elaborazione parallela di query.
Query su tabelle partizionate che utilizzano l'hint USE PLAN
In SQL Server 2008 è cambiata la modalità di elaborazione delle query su tabelle e indici partizionati. È possibile che le query su oggetti partizionati che utilizzano l'hint USE PLAN contengano un piano non valido. Dopo avere eseguito l'aggiornamento a SQL Server 2008, è consigliabile eseguire le procedure indicate di seguito.
Quando l'hint USE PLAN è specificato direttamente in una query:
Rimuovere l'hint USE PLAN dalla query.
Testare la query.
Se Query Optimizer non seleziona un piano appropriato, ottimizzare la query, quindi specificare l'hint USE PLAN con il piano di query desiderato.
Quando l'hint USE PLAN è specificato in una guida di piano:
Utilizzare la funzione sys.fn_validate_plan_guide per verificare la validità della guida di piano. In alternativa, è possibile verificare la validità dei piani utilizzando l'evento Plan Guide Unsuccessful in SQL Server Profiler.
Se la guida di piano non è valida, eliminarla. Se Query Optimizer non seleziona un piano appropriato, ottimizzare la query, quindi specificare l'hint USE PLAN con il piano di query desiderato.
Per ulteriori informazioni sull'elaborazione di query su oggetti partizionati, vedere Miglioramenti apportati all'elaborazione di query su tabelle e indici partizionati.
Guide di piano
Se una guida di piano non può essere applicata, in SQL Server 2008 la query viene compilata utilizzando un piano diverso e non viene restituito alcun errore. In SQL Server 2005 viene generato un errore e non sarà possibile eseguire la query.
Le guide di piano create in SQL Server 2005 potrebbero non essere valide dopo avere eseguito l'aggiornamento a SQL Server 2008. Le guide di piano non valide non provocheranno l'esito negativo dell'applicazione, ma la guida di piano non verrà utilizzata. È consigliabile valutare nuovamente e testare le definizioni delle guide di piano quando si aggiorna l'applicazione a una nuova versione di SQL Server. I requisiti di ottimizzazione delle prestazioni e la funzionalità di individuazione delle corrispondenze delle guide di piano possono cambiare. Dopo aver aggiornato un database a SQL Server 2008, è consigliabile eseguire le seguenti attività per convalidare le guide di piano esistenti utilizzando la funzione sys.fn_validate_plan_guide. In alternativa, è possibile monitorare le guide di piano non valide utilizzando l'evento Plan Guide Unsuccessful in SQL Server Profiler.
Architettura di Query Processor
In SQL Server 2008 è cambiata la modalità di elaborazione delle query su tabelle e indici partizionati. È possibile che le query su oggetti partizionati che utilizzano l'hint USE PLAN per un piano generato da SQL Server 2005 contengano un piano non valido. Per ulteriori informazioni, vedere Considerazioni sull'aggiornamento del Motore di database. Per ulteriori informazioni sull'elaborazione di query su oggetti partizionati, vedere Miglioramenti apportati all'elaborazione di query su tabelle e indici partizionati.
Funzione REPLACE
In SQL Server 2005 gli spazi finali specificati nel primo parametro di input per la funzione REPLACE vengono eliminati quando il parametro è di tipo char. Nell'istruzione SELECT '<' + REPLACE(CONVERT(char(6), 'ABC '), ' ', 'L') + '>', ad esempio, il valore 'ABC ' viene restituito erroneamente come 'ABC'.
In SQL Server 2008 gli spazi finali vengono sempre mantenuti. Per le applicazioni basate sul comportamento precedente della funzione, utilizzare la funzione RTRIM quando si specifica il primo parametro di input per la funzione. Nella sintassi seguente viene, ad esempio, riprodotto il comportamento SELECT '<' + REPLACE(RTRIM(CONVERT(char(6), 'ABC ')), ' ', 'L') + '>' di SQL Server 2005.
Database di sistema
Database delle risorse
In SQL Server 2005 i file di dati e di log per il database Resource dipendono dal percorso del file di dati del database master. Pertanto, se il database master viene spostato, è necessario spostare anche il database Resource nello stesso percorso. In SQL Server 2008 questa dipendenza non esiste. È possibile spostare i file del database master senza spostare il database Resource.
In SQL Server 2008 il percorso predefinito del database Resource è <unità>:\Programmi\Microsoft SQL Server\MSSQL10.<nome_istanza>\Binn\. Il database Resource non può essere spostato.
Database tempdb
Nelle versioni precedenti di SQL Server l'opzione di database PAGE_VERIFY è impostata su NONE per il database tempdb e non può essere modificata. In SQL Server 2008 il valore predefinito per il database tempdb è CHECKSUM per le nuove installazioni di SQL Server. Quando si aggiorna un'installazione di SQL Server, viene mantenuto il valore predefinito NONE. L'opzione può essere modificata. È consigliabile utilizzare CHECKSUM per il database tempdb.
Utilizzo di INSERT…SELECT per eseguire il caricamento bulk dei dati con registrazione minima
Nelle versioni precedenti di SQL Server il caricamento bulk di righe in una tabella di destinazione tramite l'istruzione INSERT INTO <tabella_destinazione> SELECT <colonne> FROM <tabella_origine> rappresenta sempre un'operazione con registrazione completa. In SQL Server 2008 è possibile eseguire questa operazione con registrazione minima se la tabella di destinazione è un heap, se è impostato il modello di recupero del database con registrazione minima o registrazione minima delle operazioni bulk e se l'hint TABLOCK è specificato nella tabella di destinazione. La registrazione minima può migliorare le prestazioni dell'istruzione e ridurre la possibilità che l'operazione occupi completamente lo spazio del log delle transazioni disponibile durante la transazione. Per ulteriori informazioni, vedere INSERT (Transact-SQL).
XML
Aggiornamento di dati XML tipizzati da SQL Server 2005 a SQL Server 2008
SQL Server 2008 contiene diverse estensioni per il supporto dello schema XML, inclusi il supporto della convalida di tipo lax, una gestione migliorata dei dati delle istanze xs:date, xs:time e xs:dateTime e il supporto aggiunto per i tipi list e union. Nella maggior parte dei casi le modifiche non influiscono sull'aggiornamento. Se, tuttavia, si utilizza una raccolta di schemi XML in SQL Server 2005 che consente valori di tipo xs:date, xs:time o xs:dateTime (o qualsiasi sottotipo), l'aggiornamento del database SQL Server 2005 a SQL Server 2008 comprende i passaggi seguenti:
Per ogni colonna xml tipizzata con una raccolta di schemi XML contenente elementi o attributi di tipo xs:anyType, xs:anySimpleType, xs:date o relativo sottotipo, xs:time o relativo sottotipo, xs:dateTime e relativo sottotipo oppure di tipo union o list contenente uno di tali tipi, si verifica quanto segue:
Tutti gli indici XML nella colonna vengono disabilitati.
Tutti i valori SQL Server 2005 continueranno a essere rappresentati nel fuso orario Z, perché sono stati normalizzati in tale fuso orario.
Qualsiasi valore xs:date o xs:dateTime precedente al 1° gennaio dell'anno 1 determinerà un errore di runtime quando l'indice viene ricompilato oppure viene eseguita un'istruzione XQuery o XML-DML sul tipo di dati xml contenente quel valore.
Ogni anno negativo nei facet o nei valori predefiniti xs:date o xs:dateTime in una raccolta di schemi XML viene aggiornato automaticamente al valore più piccolo consentito dal tipo di base xs:date o xs:dateTime, ad esempio 0001-01-01T00:00:00.0000000Z per xs:dateTime.
Si noti che è comunque possibile utilizzare una semplice istruzione SQL SELECT per recuperare il tipo di dati xml intero, anche se contiene anni negativi. È consigliabile sostituire gli anni negativi con un anno che rientri nel nuovo intervallo supportato o modificare il tipo dell'elemento o dell'attributo in xs:string. Per ulteriori informazioni, vedere Dati XML tipizzati confrontati con dati XML non tipizzati.
Convalida di tipo lax ed elementi xs:anyType
Poiché in SQL Server 2005 non è supportata la convalida di tipo lax, per gli elementi anyType viene applicata la convalida di tipo strict. In SQL Server 2008 il contenuto degli elementi di tipo anyType viene convalidato utilizzando la convalida di tipo lax. Per ulteriori informazioni, vedere Componenti jolly e convalida del contenuto.
Vedere anche
Riferimento
Altre risorse
Cronologia modifiche
Aggiornamento del contenuto |
|---|
Aggiunta delle sezioni "Opzioni della cache di controllo dell'accesso", "Ricerca full-text", "Parallelismo" e "XML". |
Aggiunta della sezione "Utilizzo di INSERT...SELECT per eseguire il caricamento bulk dei dati con registrazione minima". |
Aggiunta della sezione "Modifiche al comportamento di script per un'attività di SQL Server Agent". |