Alterações no comportamento de recursos do Mecanismo de Banco de Dados no SQL Server 2008
Este tópico descreve alterações de comportamento no Mecanismo de Banco de Dados. As alterações de comportamento afetam o modo como os recursos funcionam ou interagem no SQL Server 2008 em comparação com versões anteriores do SQL Server.
SQL Server Agent
Alterações no comportamento do script de uma tarefa do SQL Server Agent.
No SQL Server 2008, se você criar um novo trabalho copiando o script de um trabalho existente, o novo trabalho poderá afetar o trabalho existente inadvertidamente. Para criar um novo trabalho usando o script de um trabalho existente, exclua manualmente o parâmetro @schedule\_uid, que, normalmente, é o último parâmetro da seção que cria a agenda de trabalho no trabalho existente. Isso criará uma nova agenda independente para o novo trabalho sem afetar os trabalhos existentes.
Opções de cache de verificação de acesso
No SQL Server 2005, a estrutura interna de access check result cache não pode ser configurada, a não ser que você use os sinalizadores de rastreamento. No SQL Server 2008, você pode usar as opções de access check cache para modificar essa estrutura. Para obter mais informações, consulte Opções de cache de verificação de acesso.
Pesquisa de texto completo
O SQL Server 2008 apresenta uma nova arquitetura de pesquisa de texto completo. Agora, o Mecanismo de Pesquisa de Texto Completo é completamente integrado ao Mecanismo de Banco de Dados do SQL Server, em vez de um serviço separado. A integração fornece recursos melhores de gerenciabilidade, escalabilidade, segurança e desempenho de pesquisa de texto completo do que os encontrados nas versões anteriores do SQL Server. Para obter mais informações sobre as diferenças principais entre a pesquisa de texto completo no SQL Server 2005 e no SQL Server 2008, bem como as práticas recomendadas associadas a esse novo Mecanismo de Pesquisa de Texto Completo, consulte o artigo técnico "SQL Server 2008 Full-Text Search: Internals and Enhancements" no MSDN.
Servidores vinculados
O SQL Server 2008 altera a semântica de transação de instruções INSERT... EXECUTE executadas em um servidor vinculado de auto-retorno. No SQL Server 2005, este cenário não tem suporte e causa um erro. No SQL Server 2008, uma instrução INSERT...EXECUTE pode ser executada em um servidor vinculado de auto-retorno quando a conexão não tem vários conjuntos de resultados ativos (MARS) habilitados. Quando o MARS está habilitado na conexão, o comportamento é igual ao apresentado no SQL Server 2005.
Paralelismo
Processamento e paralelismo de consulta de tabela particionada
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.
Junção em estrela e paralelismo
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".
Paralelismo de poucas linhas externas
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.
Consultas de tabela particionada que usam a dica USE PLAN
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:
Remova a dica USE PLAN da consulta.
Teste a consulta.
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:
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.
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.
Guias de plano
No SQL Server 2008, se não for possível cumprir um guia de plano, a consulta será compilada usando outro plano, e nenhum erro será retornado. No SQL Server 2005, ocorre um erro e a consulta falha.
As guias de plano criadas no SQL Server 2005 podem não ser válidas após a atualização para o SQL Server 2008. Os guias de plano inválidos não farão com que o aplicativo falhe, mas o guia de plano não será usado. Recomendamos que as definições do guia de plano sejam reavaliadas e testadas quando o aplicativo for atualizado para uma nova versão do SQL Server. Os requisitos de ajuste de desempenho e o comportamento de correspondência de guia de plano podem mudar. Depois de atualizar um banco de dados para o SQL Server 2008, execute as tarefas a seguir para validar guias de plano existentes usando a função sys.fn_validate_plan_guide. Como alternativa, é possível monitorar guias de plano inválidos usando o evento Plan Guide Unsuccessful no SQL Server Profiler.
Arquitetura do processador 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 para um plano gerado pelo SQL Server 2005 podem conter um plano inválido. Para obter mais informações, consulte Considerações sobre a atualização do Mecanismo de Banco de Dados. Para obter mais informações sobre processamento de consultas em objetos particionados, consulte Aperfeiçoamentos de processamento de consultas em tabelas e índices particionados.
Função REPLACE
No SQL Server 2005, os espaços à direita especificados no primeiro parâmetro de entrada para a função REPLACE são cortados quando o parâmetro é do tipo char. Por exemplo, na instrução SELECT '<' + REPLACE(CONVERT(char(6), 'ABC '), ' ', 'L') + '>', o valor 'ABC ' é avaliado incorretamente como 'ABC'.
No SQL Server 2008, os espaços à direita são sempre preservados. Para aplicativos que dependem do comportamento anterior da função, use a função RTRIM ao especificar o primeiro parâmetro de entrada para a função. Por exemplo, a sintaxe a seguir reproduzirá o comportamento de SELECT '<' + REPLACE(RTRIM(CONVERT(char(6), 'ABC ')), ' ', 'L') + '>' do SQL Server 2005.
Bancos de dados do sistema
Banco de dados Recurso
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.
Banco de dados tempdb
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.
Usando INSERT…SELECT em dados de carregamento em massa com log mínimo
Em versões anteriores do SQL Server, o carregamento em massa de linhas em uma tabela de destino usando a instrução INSERT INTO <tabela_de_destino> SELECT <colunas> FROM <tabela_de_origem> é sempre uma operação totalmente registrada em log. No SQL Server 2008, essa operação pode ser executada com log mínimo quando a tabela de destino é um heap, quando o modelo de recuperação do banco de dados é definido como simples ou bulk-logged e quando a dica TABLOCK é especificada na tabela de destino. O log mínimo pode melhorar o desempenho da instrução e reduzir a possibilidade de a operação preencher o espaço de log disponível durante a transação. Para obter mais informações, consulte INSERT (Transact-SQL).
XML
Atualizando XML com tipo do SQL Server 2005 para o SQL Server 2008
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.
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á:
Todos os índices XML da coluna serão desabilitados.
Todos os valores do SQL Server 2005 continuarão representados na zona de hora Z, porque foram normalizados para ela.
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.
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.
Validação lax e elementos xs:anyType
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.
Consulte também
Referência
Outros recursos
Histórico de alterações
Conteúdo atualizado |
|---|
Adição das seções "Opções de cache de verificação de acesso", "Pesquisa de texto completo", "Paralelismo" e "XML". |
Adição da seção "Usando INSERT… SELECT em dados de carregamento em massa com log mínimo." |
Adição da seção "Alterações no comportamento do script de uma tarefa do SQL Server Agent". |