Alterações no comportamento de recursos do Mecanismo de Banco de Dados no SQL Server 2008

No SQL Server 2008, os aperfeiçoamentos feitos no design da tabela particionada facilitam o paralelismo durante o processamento de consulta em tabelas particionadas do que no SQL Server 2005. Como resultado, somente junções bidirecionais podem ser colocadas. Os planos de consulta para junções bidirecionais no SQL Server 2008 parecem iguais aos do SQL Server 2005 e têm desempenho equivalente ao do SQL Server 2005. Se forem incluídas tabelas adicionais com particionamento alinhado na junção, um plano diferente será selecionado, como uma junção bidirecional colocada seguida por uma junção hash com a terceira tabela. Junções colocadas entre mais de duas tabelas são incomuns e não se beneficiam com os aperfeiçoamentos feitos no paralelismo no SQL Server 2008. No entanto, se você tiver uma consulta para a qual o SQL Server 2005 executar uma junção colocada tridimensional (ou com mais dimensões), será possível que a consulta apresente execução mais lenta no SQL Server 2008 se a quantidade de memória for menor em relação ao tamanho das tabelas. Para melhorar o desempenho nesta situação, é possível aumentar a quantidade de memória disponível e reescrever a consulta de modo que as partições individuais sejam unidas separadamente antes da combinação dos resultados. Para obter mais informações sobre junções colocadas, consulte Aperfeiçoamentos de processamento de consultas em tabelas e índices particionados.

O SQL Server tem uma nova otimização para processar consultas com junções em estrela que usam junções de hash e filtros de bitmap. Quando uma consulta processa grandes quantidades de dados da união de tabelas de fato a tabelas de dimensão em um esquema em estrela, um plano de consulta que usa a nova otimização pode ser executado muito mais rapidamente. 

Assim, talvez você visualize um novo plano de consulta para as consultas existentes se elas se ajustarem ao padrão de junção em estrela. O otimizador de consulta escolhe esse plano quando suas estimativas indicam que o desempenho da consulta será melhor. No entanto, se as estatísticas usadas na estimativa de custo forem imprecisas, o otimizador de consulta poderá escolher a otimização de junção em estrela quando um plano diferente for mais rápido.

Se a opção de configuração grau máx de paralelismo ou a opção de índice MAXDOP estiver definida como 1, o otimizador de consulta não usará a otimização de junção em estrela e você não experimentará os benefícios fornecidos por esse novo recurso. Se o sistema de execução de consulta despachar uma consulta otimizada com um plano paralelo de um só thread, alguns filtros de bitmap talvez sejam removidos de um plano de junção em estrela com vários filtros de bitmap. Essa alteração poderá reduzir a velocidade da execução mais do que o esperado quando você passar de 2 threads para 1 thread, por exemplo.

A otimização de junção em estrela está disponível somente nas edições Enterprise, Developer e Evaluation do SQL Server. Para obter mais informações sobre a filtragem de bitmap, consulte Otimizando o desempenho de consulta de data warehouse por filtragem de bitmap. Para obter mais informações sobre como interpretar planos de consulta contendo filtros de bitmap, consulte Interpretando planos de execução que contêm filtros de bitmap. Para obter mais informações sobre a otimização de junção em estrela, consulte o artigo da TechNet Magazine, "Data Warehouse Query Performance".

O SQL Server 2008 facilita o paralelismo para junções de loop aninhado quando o lado externo da junção tem apenas algumas linhas. No SQL Server 2005, se houver vários threads disponíveis, uma página de linhas do lado externo da junção será alocada para cada thread. Se houver somente algumas linhas, provavelmente elas estarão na mesma página. Nesses casos, somente um thread é empregado e os benefícios potenciais do paralelismo são perdidos. O SQL Server 2008 reconhece esses casos e introduz um operador de troca que aloca uma linha por thread, de modo que todas as CPUs disponíveis sejam empregadas. O maior paralelismo significa que o consumo de CPU aumentará temporariamente em comparação com o SQL Server 2005, mas a execução de consultas será mais rápida. Esse novo comportamento somente será observado se o número de linhas externas for pequeno e se o custo da consulta for considerado grande o bastante para se beneficiar do paralelismo adicional. Se o custo da consulta for considerado pequeno ou se a estimativa de cardinalidade para o lado externo for maior do que 1000, o SQL Server alocará uma página por thread, como no SQL Server 2005. Para obter mais informações sobre operadores de troca e processamento paralelo de consultas, consulte Processamento paralelo de consultas.

O SQL Server 2008 altera o modo como as consultas em tabelas e índices particionados são processadas. As consultas em objetos particionados que usam a dica USE PLAN podem conter um plano inválido. Recomenda-se os seguintes procedimentos após a atualização do SQL Server 2008.

Quando a dica USE PLAN for especificada diretamente em uma consulta:

1. Remova a dica USE PLAN da consulta.

2. Teste a consulta.

3. Se o otimizador não selecionar um plano adequado, ajuste a consulta e especifique a dica USE PLAN com o plano de consulta desejado.

Quando a dica USE PLAN for especificada em uma guia de plano:

1. Use a função sys.fn_validate_plan_guide para verificar a validade da guia de plano. Como alternativa, é possível verificar se existem planos inválidos usando o evento Plan Guide Unsuccessful no SQL Server Profiler.

2. Se o guia de plano não for válido, descarte-o. Se o otimizador não selecionar um plano adequado, ajuste a consulta e especifique a dica USE PLAN com o plano de consulta desejado.

Para obter mais informações sobre o processamento de consultas em objetos particionados, consulte Aperfeiçoamentos de processamento de consultas em tabelas e índices particionados.

No SQL Server 2005, os arquivos de dados e de log do banco de dados Resource dependem do local do arquivo de dados do banco de dados master. Assim, se mover o banco de dados master, você também deverá mover o banco de dados Resource para o mesmo local. No SQL Server 2008, essa dependência não existe. Os arquivos do banco de dados master podem ser movidos sem a necessidade de mover o banco de dados Resource.

No SQL Server 2008, o local padrão do banco de dados Resource é <unidade>:\Arquivos de Programas\Microsoft SQL Server\MSSQL10.<nome_instância>\Binn\. O banco de dados Resource não pode ser movido.

Em versões anteriores do SQL Server, a opção de banco de dados PAGE_VERIFY é definida como NONE para o banco de dados tempdb e não pode ser modificada. No SQL Server 2008, o valor padrão do banco de dados tempdb é CHECKSUM para instalações novas do SQL Server. Ao atualizar uma instalação do SQL Server, o valor padrão permanece NONE. A opção pode ser modificada. É recomendável usar CHECKSUM para o banco de dados tempdb.

O SQL Server 2008 contém várias extensões para o suporte ao esquema XML, incluindo suporte para validação de lax, melhor manipulação dos dados de instância xs:date, xs:time e xs:dateTime e suporte adicional para os tipos list e union. Na maioria dos casos, as alterações não afetam a experiência de atualização. No entanto, se você usar uma coleção de esquemas XML no SQL Server 2005 que permita valores do tipo xs:date, xs:time ou xs:dateTime (ou qualquer subtipo), as etapas de atualização a seguir ocorrerão quando você atualizar o banco de dados do SQL Server 2005 para o SQL Server 2008.

1. Para cada coluna do xml, com tipos com uma coleção de esquemas XML que contenha elementos ou atributos de tipo como xs:anyType, xs:anySimpleType, xs:date ou qualquer um de seus subtipos, xs:time ou qualquer um de seus subtipos ou xs:dateTime e qualquer um de seus subtipos, ou tipos union ou list que contenham um desses tipos, o seguinte ocorrerá:

   1. Todos os índices XML da coluna serão desabilitados.

   2. Todos os valores do SQL Server 2005 continuarão representados na zona de hora Z, porque foram normalizados para ela.

   3. Quaisquer valores de xs:date ou xs:dateTime menores que 1º de janeiro do ano 1 resultarão em um erro em tempo de execução quando o índice for recriado ou uma instrução XQuery ou XML-DML for executada no tipo de dados xml que contém esse valor.

2. Quaisquer anos negativos nas facetas xs:date ou xs:dateTime ou valores padrão em uma coleção de esquemas XML serão atualizados automaticamente para o menor valor permitido pelo tipo xs:date ou xs:dateTime base. Por exemplo, 0001-01-01T00:00:00.0000000Z para xs:dateTime.

Observe que você ainda pode usar uma instrução select SQL simples para recuperar o tipo de dados xml inteiro, mesmo que ele contenha anos negativos. É recomendável substituir anos negativos por um ano dentro do intervalo com suporte recente ou alterar o tipo do elemento ou atributo para xs:string. Para obter mais informações, consulte XML digitado comparado com XML não digitado.

No SQL Server 2005, não há suporte para a validação lax e a validação estrita é aplicada aos elementos do tipo anyType. No SQL Server 2008, o conteúdo de elementos do tipo anyType é validado com o uso da validação lax. Para obter mais informações, consulte Componentes curinga e validação de conteúdo.