Melhoramentos de 2016 do SQL Server no processamento de alguns tipos de dados e operações invulgares
Microsoft SQL Server 2016 e base de dados de SQL do Microsoft Azure incluem melhoramentos em conversões de tipo de dados e em várias outras operações. A maior parte destas melhorias oferece maior precisão quando lidam com tipos de vírgula flutuante, bem como com tipos de datetime clássico. Estes melhoramentos estão disponíveis quando utiliza um nível de compatibilidade da base de dados de 130 ou posterior. Isto significa que para algumas expressões (principalmente invulgares) verá resultados diferentes para alguns valores de entrada depois de actualizar a base de dados para o nível de compatibilidade 130. Estes resultados podem estar reflectidos nas colunas de estruturas persistente da base de dados tabela incluídos dados sujeitos a restrições de verificação , persistentes calculadas, índices de referenciar colunas processadas, filtradas índices e as vistas indexadas.
Se tiver uma base de dados que foi criado numa versão anterior do SQL Server, recomendamos que efectue a validação adicional depois de actualizar para SQL Server 2016 e antes de alterar o nível de compatibilidade da base de dados para 130. Se achar que nenhuma das estruturas persistentes na base de dados são afectadas por estas alterações, recomendamos que reconstrua estruturas afectadas depois de actualizar a base de dados para o nível de compatibilidade 130. Ao fazê-lo, vai beneficiar destas melhorias no SQL Server 2016.
Este artigo descreve como persistentes estruturas da base de dados pode ser validado como parte da actualização para o nível de compatibilidade 130, e como qualquer afectado estruturas possa ser reconstruído depois de alterar o nível de compatibilidade 130.
Passos de validação durante uma actualização para o nível de compatibilidade 130
SQL Server 2016 inclui melhoramentos para a precisão das seguintes operações em nível de compatibilidade 130:
Conversões de tipo de dados invulgares. Estas incluem as seguintes:
Flutuar para real
Alguns casos de  PARTDATA/DIFDATA e Graus
Converter com um estilo de Nulo
Para utilizar estes melhoramentos para a avaliação da expressão na sua aplicação, altere o nível de compatibilidade das bases de dados para 130. Para mais informações sobre todas as alterações e exemplos, mostrando as alterações, consulte o Apêndice A.
As estruturas seguintes na base de dados poderão persistir os resultados de uma expressão:
Dados da tabela sujeitos a restrições de verificação
Colunas processadas persistentes
Índices que usam calculado colunas na chave ou incluir colunas
Índices filtradas
Tem uma base de dados que foi criada por uma versão anterior do SQL Server, ou que já criado no SQL Server 2016 mas que um nível de compatibilidade 120 ou um nível anterior.
Utilizar as expressões cuja precisão foi melhorada como parte da definição de estruturas persistentes na base de dados.
Neste cenário, poderá ter persistentes estruturas que são afectadas pelos melhoramentos de precisão implementado utilizando o nível de compatibilidade 130. Se for este o caso, recomendamos que valida as estruturas persistentes e reconstruir qualquer estrutura que é afectada.
Se tiver afectado estruturas e que não reconstruir depois de alterar o nível de compatibilidade 130, poderá detectar os resultados de consulta ligeiramente diferente, dependendo se é utilizada um índice específico, a coluna calculada ou a vista e, se poderiam ser considerados uma violação de uma restrição de dados numa tabela.
Nota Sinalizador 139 no SQL Server de rastreio
O sinalizador de rastreio global 139 é introduzido no CU3 de 2016 do SQL Server e Service Pack (SP) 1 para forçar a semântica de conversão no âmbito do DBCC verificar comandos como DBCC CHECKDB, DBCC CHECKTABLE e DBCC CHECKCONSTRAINTS ao analisar a precisão melhorada e a lógica de conversão introduzida com o nível de compatibilidade 130 numa base de dados com um nível de compatibilidade anterior correcto.
Sinalizador de rastreio 139 não se destina a ser continuamente activada num ambiente de produção e deve ser utilizado com o propósito exclusivo de efectuar as verificações de validação de base de dados descritas neste artigo. Assim, deve ser desactivada através da utilização de dbcc traceoff (139, -1) na mesma sessão, depois das regras de validação são concluídas.
Sinalizador de rastreio 139 é suportado apenas no CU3 de 2016 do SQL Server e posterior e no SQL Server de 2016 SP1 e versões posteriores.
Para actualizar para o nível de compatibilidade 130, siga estes passos:
Efectua uma validação para identificar todas as estruturas persistentes afectadas:
Activar o sinalizador de rastreio 139 executando DBCC TRACEON(139,-1).
Execute comandos DBCC CHECKDB/da mesa e CHECKCONSTRAINTS .
Desactivar o sinalizador de rastreio 139 executando DBCC TRACEOFF(139,-1).
Altere o nível de compatibilidade da base de dados para 130.
Recriar todas as estruturas que identificou no passo 1.
Nota Sinalizadores de rastreio na base de dados de SQL de Azure
Definir sinalizadores de rastreio não é suportada na base de dados de SQL de Azure. Por conseguinte, é necessário alterar o nível de compatibilidade antes de efectuar a validação:
Actualize o nível de compatibilidade da base de dados para 130.
Efectua uma validação para identificar todas as estruturas persistentes afectadas.
Reconstrua as estruturas que identificou no passo 2.
Apêndice A contém uma lista detalhada de todos os melhoramentos de precisão e fornece um exemplo para cada um.
Apêndice B contém um processo passo a passo detalhado para efectuar a validação e recompilar todas as estruturas afectadas.
Apêndices C e D contêm scripts para ajudar a identificar potencialmente afectados objectos na base de dados. Por conseguinte, pode as validações de âmbito e gerar scripts correspondentes para executar as verificações. Para determinar mais facilmente se todas as estruturas persistentes nas bases de dados são afectadas pelos melhoramentos de precisão no nível de compatibilidade 130, execute o script no Apêndice D para gerar as verificações de validação correcto e, em seguida, executar este script para efectuar a validação.
Apêndice a: alterações no nível de compatibilidade 130
No presente anexo, encontrará as listas dos melhoramentos para a avaliação da expressão no nível de compatibilidade 130. Cada alteração inclui uma consulta de exemplo associados. As consultas podem ser utilizadas para mostrar as diferenças entre a execução de uma base de dados que utiliza um nível de compatibilidade de pré-130 em relação uma base de dados que utiliza o nível de compatibilidade 130.
As tabelas seguintes listam conversões de tipos de dados e operações adicionais.
Consulta de exemplo
Resultado para o nível de compatibilidade < 130
Resultado para o nível de compatibilidade 130
flutuar, real, numérico, decimal, moeda ou smallmoney data/hora ou smalldatetime Aumente a precisão de arredondamento. Anteriormente, o dia e hora foram convertidos separadamente e resultados foram truncados antes que combinada-los.
DECLARE @f FLOAT = 1,2
data/hora bigint, int ou smallint Um datetime negativo cuja parte do tempo é exactamente um meio dia ou de uma escala de um meio-dia é arredondado correctamente (o resultado está desactivada por 1).
Seleccione @h, fundido (@h como INT)
data/hora ou smalldatetime flutuar, real, numérico, money ou smallmoney Melhorar a precisão para os últimos 8 bits de precisão em alguns casos.
DECLARE @f FLOAT = converter (FLOAT, @p0)
Seleccione @f, fundido (@f como VARBINARY(8))
vírgula flutuante real Verificações de limite são menos rigorosas. SELECCIONE FUNDIDO (3.40282347000E + 038 COMO REAL) Excesso aritmético 3.402823E + 38
smallmoney, de moeda e numéricos vírgula flutuante Quando a escala de entrada for zero, existe um arredondamento imprecisão quando combina quatro partes do numérico.
DECLARE @f FLOAT = fundido (@n FLUTUAR)
smallmoney, de moeda e numéricos vírgula flutuante Quando a escala de entrada é diferente de zero, não existe um arredondamento imprecisão quando dividir por 10 ^ escala.
DECLARE @n numérico (18. o, 10) = 12345678.0123456781
real ou de vírgula flutuante numérico Melhorar a precisão em alguns casos de arredondamento.
Seleccione fundido (@f como numérico (1, 1))
real ou de vírgula flutuante numérico Melhorar a precisão quando arredondar para mais do que 16 dígitos em alguns casos.
DECLARE @v decimais (38, 18) = 1E-18
real ou de vírgula flutuante Money ou smallmoney Melhor exactidão quando converte números grandes, em alguns casos.
DECLARE @f float = 2SET @f = potência (@f, 49) + energia (@f, -2)
(n) char (var) numérico Uma entrada de mais de 39 caracteres acciona já não é necessariamente um excesso aritmético.
DECLARE @value nchar(100) = '1.11111111111111111111111111111111111111'
Excesso aritmético 1.1
(n) char (var) bit Suporta conduzindo espaços e sinais.
DECLARE @value nvarchar(100) = '1'
A conversão falhou ao converter o valor de nvarchar '1' para tipo de dados de bits. 1
data/hora hora ou datetime2 Precisão melhorada quando converter para data/hora tipos com maior precisão. Tenha em atenção que os valores de data/hora são armazenados como marcas de escala representam 1/300th de um segundo. A hora mais recente e tipos de datetime2 armazenam um número de dígitos, onde o número de dígitos coincide com a precisão discreto.
DECLARE @value datetime = ' 00:00:00.003 de 1900-01-01'
hora ou datetime2 data/hora Melhorada arredondamento de preços em alguns casos.
DECLARE @value time(4) = '00:00:00.0045'
Utilizar a função incorporada radianos ou graus que utiliza o tipo de dados numéricos. Divide graus por pi/180, onde-anteriormente multiplicado por 180/pi. Semelhante para radianos.
Numérica adição ou subtracção quando a escala do operando é maior do que a escala do resultado. Arredondamento sempre ocorre após a adição/subtracção, enquanto que anteriormente, por vezes, poderia ocorrer antes.
Seleccionar @p1 + @p2
Converter com estilo de Nulo . Converter com estilo Nulo devolve sempre Nulo quando o tipo de destino é numérico. SELECCIONE CONVERTER (SMALLINT, '0', NULL); 0 NULL
PARTDATA que utiliza a opção microssegundos ou nanossegundos, com o tipo de dados de data/hora. Valor já não é truncado no nível milisegundos antes de converter para microrganismos ou nanossegundos.
DECLARE @dt DATETIME = ' 01-01-1900 00:00:00.003»;
DATEDIFF que utiliza a opção microssegundos ou nanossegundos, com o tipo de dados de data/hora. Valor já não é truncado no nível milisegundos antes de converter para microrganismos ou nanossegundos.
DECLARE @d1 DATETIME = ' 00:00:00.003 de 1900-01-01'
DECLARE @d2 DATETIME = ' 00:00:00.007 de 1900-01-01'
Comparação entre os valores de data/hora e datetime2 com valores diferentes de zero para milissegundos. Valor de data/hora já não será truncado a nível da milissegundo quando executa uma comparação com um valor de datetime2. Isto significa que determinados valores que anteriormente com igual, já não comparar igual.
Seleccione CAST(@d1 AS datetime2(7)), @d2SELECT CASE WHEN (@d1=@d2), em seguida, fim de 'desigual' ELSE 'é diferente de'
Apêndice b: passos para verificar e actualizar persistentes estruturas
A recomendação é para validar se a base de dados tem todas as estruturas persistentes que são afectadas pelas alterações no nível de compatibilidade 130 e recriar todas as estruturas afectadas.
Tenha em atenção que isto aplica-se apenas às estruturas persistentes que foram criadas na base de dados de uma versão mais antiga do SQL Server ou utilizando um nível de compatibilidade anterior ao 130. As estruturas persistentes potencialmente afectados incluem o seguinte:
Nesta situação, execute o seguinte procedimento.
Passo 1: Verificar o nível de compatibilidade da base de dados
Verifique o nível de compatibilidade da base de dados utilizando o procedimento que é documentado na Ver ou alterar o nível de compatibilidade de uma base de dados.
Se o nível de compatibilidade da base de dados for inferior a 130, recomendamos que efectue a validação descrito no passo 2 antes de aumentar o nível de compatibilidade para 130.
Passo 2: Identificar afected persistentes estruturas
Valide se a base de dados contém todas as estruturas persistentes que são afectadas pela precisão melhorada e a lógica de conversão na compatibilidade nível 130, de duas formas:
DBCC CHECKDB com EXTENDED_LOGICAL_CHECKS , que confirma todas as estruturas da base de dados.
DBCC CHECKTABLE com EXTENDED_LOGICAL_CHECKS , que valida as estruturas relacionadas com uma única tabela.
A opção Com o EXTENDED_LOGICAL_CHECKS é necessária para se certificar de que os valores persistentes são comparados com valores calculados e aos casos de sinalizador no qual existe uma diferença. Uma vez que estas verificações forem muitas, o tempo de execução de instruções de DBCC que utilizam esta opção é consideravelmente mais demorado do que a execução de instruções de DBCC sem a opção. Por conseguinte, a recomendação de grandes bases de dados é utilizar DBCC CHECKTABLE para identificar tabelas individuais.
DBCC CHECKCONSTRAINTS pode ser utilizado para validar as restrições de verificação . Esta declaração pode ser utilizada na base de dados ou o nível de tabela.
Tenha em atenção que DBCC verificação * demonstrações devem sempre ser executadas numa janela de manutenção, devido ao potencial impacto dos controlos de carga de trabalho online.
Validação de nível de base de dados
Validação ao nível da base de dados é adequada para pequenas e médias moderadamente bases de dados. Utilize a validação de nível de tabela para grandes bases de dados.
DBCC CHECKDB com EXTENDED_LOGICAL_CHECKS é utilizado para validar todas as estruturas persistentes na base de dados.
DBCC CHECKCONSTRAINTS é utilizado para validar todas as restrições de verificação na base de dados.
DBCC CHECKCONSTRAINTS é utilizado para validar a integridade de restrições.
Utilize o seguinte script para validar a base de dados:
A utilização o sinalizador de rastreamento torna-se de que os controlos são efectuados utilizando a lógica de precisão e a conversão melhorada que se encontra na compatibilidade nível 130, forçar a semântica de conversão correcto, mesmo quando a base de dados tem um nível inferior de compatibilidade.
Se a instrução de CHECKCONSTRAINTS está concluída e não devolve um conjunto de resultados, não é necessária nenhuma acção adicional.
Se a declaração de devolver um conjunto de resultados, cada linha nos resultados da indica uma violação de uma restrição e também inclui os valores que violam a restrição.
Guardar os nomes de tabelas e restrições, os valores que causou o violated (a 'Where' coluna no conjunto de resultados).
O exemplo seguinte mostra uma tabela com uma restrição de verificação e uma única linha que viola a restrição de nível de compatibilidade 130, mas que cumpra a restrição em níveis inferiores de compatibilidade.
O comando CHECKCONSTRAINT devolve os seguintes resultados:
[dbo].[table1] [chk1] [c2] = ' 00:00:00.997 de 1900-01-01' AND [c3] = ' 00:00:01.000 de 1900-01-01' AND [c4] = '3'
Este resultado indica que a restrição [chk1] foi suspenso para a combinação de valores da coluna no 'Where'.
DBCC CHECKDB COM EXTENDED_LOGICAL_CHECKS
DBCC CHECKDB com EXTENDED_LOGICAL_CHECKS valida todas as estruturas persistentes na base de dados. Esta é a opção mais conveniente porque uma única instrução valida todas as estruturas da base de dados. Contudo, esta opção não é adequada para grandes bases de dados devido ao tempo de execução esperado da instrução.
Utilize o seguinte script para validar a base de dados completa:
Se a instrução de CHECKDB é concluída com êxito, não é necessária nenhuma acção adicional.
Se a instrução estiver concluída com erros, siga estes passos:
Guarde os resultados da execução da instrução DBCC , localizada no painel de mensagens no SQL Server Management Studio (SSMS), para um ficheiro.
Certifique-se de que qualquer um dos erros comunicados estão relacionados com estruturas persistentes:
Quadro 1: Persistentes estruturas e mensagens de erro correspondentes inconsistências
Tipo de estrutura afectado
Mensagens de erro observadas
Tome nota do
Colunas processadas persistentes Msg 2537, erro de nível 16Table: < object_id > do ID de objecto, índice de ID de < index_id >... A verificação de registo (coluna calculada válida) falhou. Os valores são... ID < object_id > do objecto e indexar ID < index_id >
Índices referenciar colunas na chave calculadas ou incluir colunas
Erro 8951
Erro da tabela: tabela '< table_name >' (ID < object_id >). Linha de dados não tem uma linha de índice correspondente no índice '< index_name >' (ID < index_id >)...
Erro 8952
Erro da tabela: tabela '< table_name >' (ID < table_name >). Linha do índice no índice ' (ID < index_id >) não corresponde a qualquer linha de dados...
Além disso, podem existir erros secundários 8955 e/ou 8956 de segurança. Isto contêm detalhes sobre as linhas exactas afectadas. Estes podem não ser respeitados para este exercício.
ID < object_id > do objecto e indexar ID < index_id >
Erro 8908
A... < view_name > a vista indexada (ID < object_id > do objecto) não conter todas as linhas que produz a definição da vista...
Erro 8907The... vista indexada '< view_name >' (ID < object_id > do objecto) contém linhas que não são produzidas pela definição da vista...
ID de objecto < object_id >
Depois de concluir a validação de nível de base de dados, mova para o passo 3.
Validação de nível de objecto
Bases de dados maiores, é útil validar estruturas e restrições de uma tabela ou uma vista de cada vez para reduzir o tamanho das janelas de manutenção ou para limitar os controlos lógicos expandidos apenas a objectos potencialmente afectados.
Utilize as consultas no Apêndice C para identificar tabelas potencialmente afectadas. O script no Apêndice D pode ser utilizado para gerar CHECKTABLE e CHECKCONSTRAINTS as restrições baseadas em consultas enumeradas no Apêndice C.
Para validar as restrições relacionadas com uma única tabela ou vista, utilize o seguinte script:
A utilização o sinalizador de rastreamento torna-se de que os controlos são efectuados utilizando a lógica de precisão e a conversão melhorada que se encontra na compatibilidade nível 130, forçar a semântica melhorada, mesmo quando a base de dados tem um nível inferior de compatibilidade.
Se a declaração de devolver um conjunto de resultados, cada linha nos resultados da indica uma violação de uma restrição e também fornece os valores que violam a restrição.
DBCC CHECKTABLE COM EXTENDED_LOGICAL_CHECKS
Para validar as estruturas persistentes relacionadas com uma única tabela ou vista, utilize o seguinte script:
Se a instrução CHECKTABLE for concluída com êxito, não é necessária nenhuma acção adicional.
Guarde os resultados da execução da instrução DBCC , localizada no painel de mensagens na SSMS, para um ficheiro.
Certifique-se de que qualquer um dos erros comunicados estão relacionados com estruturas persistentes enumerados no quadro 1.
Depois de concluir a validação de nível de tabela, avance para o passo 3.
Passo 3: Actualizar para o nível de compatibilidade 130
Se o nível de compatibilidade da base de dados já estiver 130, pode ignorar este passo.
O nível de compatibilidade da base de dados pode ser alterado para 130 utilizando o seguinte script:
Uma vez que existem alterações de optimização de consulta com o nível de compatibilidade 130, recomendamos que Active o arquivo de consulta antes de alterar o nível de compatibilidade. Para mais informações, consulte a manter a estabilidade do desempenho durante a actualização para o SQL Server 2016.
Passo 4: Actualização persistentes estruturas
Se não existem inconsistências foram encontradas durante a validação efectuada no passo 2, são efectuadas com a actualização e pode ignorar este passo.
Se foram encontradas inconsistências no passo 2, são necessárias acções adicionais para remover as inconsistências da base de dados. As acções necessárias dependem do tipo de estrutura que é afectado.
Execute as acções de reparação este passo apenas depois do nível de compatibilidade da base de dados foi alterado para 130.
A base de dados (ou bases de dados) de cópia de segurança
Recomendamos que efectue uma cópia de segurança da base de dados antes de efectuar qualquer uma das acções que a secção seguinte descreve. Se utilizar Azure base de dados de SQL, não tem de ter uma cópia de segurança Pode sempre utilizar a funcionalidade de restauro em qualquer altura para voltar atrás no tempo, no caso de algum problema com qualquer uma das actualizações.
Restrições de verificação
Corrigir violações da restrição de verificação requer a modificação de dados na tabela ou a restrição de verificação própria.
Do nome da restrição (obtido no passo 2), pode obter a definição de restrição do seguinte modo:
Para inspeccionar as linhas da tabela que são afectadas, pode utilizar as informações do 'Where' que foi anteriormente devolvidas pela instrução DBCC CHECKCONSTRAINTS :
Tem de actualizar as linhas afectadas ou alterar a definição de restrição para se certificar de que a restrição não é violada.
Actualização de dados de tabela
Não existe nenhuma regra rígida indicando a forma como os dados devem ser actualizados. Em geral, para cada 'Where' extracto diferente devolvido por CHECKCONSTRAINTS de DBCC, irá executar a seguinte instrução de actualização:
Considere a seguinte tabela de exemplo com um constrangimento e uma linha que viola a restrição no nível de compatibilidade 130:
Neste exemplo, a restrição é simples: c4 coluna tem de ser igual a uma expressão que envolvam c2 e c3. Para actualizar a tabela, atribua este valor a c4:
Repare que a cláusula WHERE utilizada na instrução update corresponde às informações 'Onde' devolvidas pelo DBCC CHECKCONSTRAINTS.
Restrição de verificação de actualização
Para alterar uma restrição de verificação , tem de largar e recriá-la. Recomenda-ambos na mesma transacção, caso não existem quaisquer problemas relacionados com a definição de restrição actualizado. Pode utilizar o Transact-SQL seguinte:
O exemplo seguinte actualiza o chk1 de restrição em dbo.table1:
É a forma mais fácil actualizar colunas processadas persistentes actualizar uma das colunas que é referenciado pela coluna calculada. O novo valor para a coluna pode ser o mesmo que o valor antigo, tal que a operação não altera quaisquer dados de utilizador.
Siga estes passos para cada object_id relacionadas com a inconsistências nos dados calculados que anotou no passo 2.
Identificar colunas processadas:
Execute a seguinte consulta para obter o nome da tabela e os nomes das colunas processadas persistentes para o object_id anotados:
Identificar colunas referenciadas:
Execute a seguinte consulta para identificar colunas referenciadas pela coluna calculada. Tome nota de um da referenced_column_names:
Execute uma instrução de actualização que envolva uma das colunas referenciadas para accionar uma actualização da coluna calculada:
A seguinte instrução irá desencadear uma actualização da coluna que é referenciada pela coluna calculada e também accionam uma actualização da coluna calculada.
A expressão ÉNULO na instrução é concebida para o efeito de tal forma que não é alterado o valor da coluna original, enquanto ainda certificando-se de que a coluna calculada é actualizada através da utilização de lógica de avaliação de expressão de nível 130 compatibilidade DB.
Tenha em atenção que para tabelas muito grandes, não poderá actualizar todas as linhas numa única transacção. Nesse caso, que pode executar a actualização em lotes, adicionar uma cláusula WHERE da instrução de actualização que identifica um intervalo de linhas; com base na chave primária, por exemplo.
Identifica índices referenciando a coluna calculada.
Esta consulta identifica os índices que fazem referência à coluna calculada persistente. Qualquer índice tem de ser reconstruída. Para tal, siga os passos na secção seguinte.
Índices, índices filtradas e as vistas indexadas
Inconsistências nos índices correspondem a erros 8951 e 8952 (para tabelas) ou 8907 e 8908 (para vistas) no resultado da verificação de DBCC * desde o passo 2.
Para reparar essas inconsistências e execute DBCC CHECKTABLE com REPAIR_REBUILD. Isto irá reparar as estruturas de índices sem qualquer perda de dados. No entanto, a base de dados tem de estar no modo de utilizador único e, por conseguinte, não está disponível para outros utilizadores enquanto reparação está a ocorrer.
Pode também manualmente reconstruir índices afectados. Esta opção deve ser utilizada se a carga de trabalho não pode ser colocado offline, uma vez que reconstruir o índice pode ser executada como uma operação ONLINE (em edições suportadas do SQL Server).
Se definir a base de dados no modo de utilizador único, uma opção não estiver, pode reconstruir índices individualmente, utilizando o índice de alterar... RECONSTRUA, para cada índice identificado no passo 2.
Utilize a seguinte consulta para obter os nomes de tabela e o índice para um determinado object_id e index_id.
Utilize a seguinte instrução para reconstruir o índice:
Nota Se estiver a utilizar o padrão, Web, ou criar Express edições, índice online não é suportada. Por conseguinte, a opção WITH (ONLINE = ON) devem ser retirados a instrução ALTER INDEX.
O exemplo seguinte mostra a reconstrução de um índice filtrado:
Se tiver de planos de manutenção regular, recomendamos que inclua este reconstrução do índice como parte da sua manutenção agendada.
Reparar utilizando DBCC
Para cada (object_id) relacionados com um índice com inconsistências que anotou no passo 2, execute o seguinte script para efectuar uma reparação. Este script define a base de dados em modo de utilizador único para a operação de reparação. No pior dos casos, a reparação efectua uma reconstrução do índice completo.
Apêndice c: consultas para identificar tabelas do candidato
Os scripts seguintes identificam tabelas do candidato que pretende validar utilizando DBCC CHECKTABLE com EXTENDED_LOGICAL_CHECKS, com base na existência de estruturas persistentes e restrições que utilizam tipos de dados afectados pelos melhoramentos no nível de compatibilidade 130.
O seguinte conjunto de detalhes da lista de consultas sobre as tabelas e as estruturas potencialmente afectadas que requerem a validação adicional.
A consulta seguinte devolve todas as vistas indexadas, fazer referência a colunas utilizando tipos de dados afectados ou utilizando qualquer uma das funções incorporadas afectadas:
A seguinte consulta devolve todas as tabelas com dados calculados referenciar outras colunas utilizando tipos de dados afectados ou utilizando qualquer uma das funções incorporadas afectadas, onde quer a coluna é persistente ou referenciada de um índice.
A consulta seguinte devolve todas as tabelas com índices filtradas que fazem referência a colunas na condição de filtro que afectaram os tipos de dados:
A seguinte consulta lista todas as tabelas com restrições de verificação que se referem a tipos de dados afectados ou funções incorporadas:
Apêndice d: Script para criar instruções de verificação *
O script seguinte combina as consultas do anexo anterior e simplifica os resultados a apresentar uma lista de tabelas e vistas sob a forma de instruções CHECKCONSTRAINTS e CHECKTABLE .