Differenze di funzionamento delle funzionalità del Motore di database in SQL Server 2008

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.

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".

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.

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:

1. Rimuovere l'hint USE PLAN dalla query.

2. Testare la query.

3. 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:

1. 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.

2. 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.

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.

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.

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:

1. 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:

   1. Tutti gli indici XML nella colonna vengono disabilitati.

   2. Tutti i valori SQL Server 2005 continueranno a essere rappresentati nel fuso orario Z, perché sono stati normalizzati in tale fuso orario.

   3. 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.

2. 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.

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.