Banco de dados de uma versão anterior do SQL Server se torne inutilizável quando você anexar a uma instância de SQL Server 2012

Traduções de Artigos Traduções de Artigos
Artigo: 2710782 - Ver produtos para os quais este artigo se aplica.
Expandir tudo | Reduzir tudo

Nesta página

Sintomas

Considere o seguinte cenário:
  • Instalar uma instância do Microsoft SQL Server 2005, Microsoft SQL Server 2008 ou Microsoft SQL Server 2008 R2.
  • A instância de SQL Server é denominada INST1 e hospeda um banco de dados chamado Test_RO_FG_DB.
  • O banco de dados contém os seguintes grupos de arquivos:
    • Primário
    • RO_FG
    • RW_FG
  • O grupo de arquivos chamado RO_FG é marcado como READ_ONLY.
  • Instalar uma nova instância do Microsoft SQL Server 2012. Esta instância de SQL Server 2012 é chamado INST2.
  • Desanexe o banco de dados Test_RO_FG_DB de INST1.
  • Tente anexar o banco de dados Test_RO_FG_DB INST2.
  • Você recebe uma mensagem de erro semelhante à seguinte:
    MSG 3415, nível 16, estado 2, linha 1
    Banco de dados 'Test_RO_FG_DB' não pode ser atualizada porque ele é somente leitura possui arquivos somente leitura ou o usuário não tem permissões para modificar alguns dos arquivos. Tornar gravável do banco de dados ou arquivos e execute a recuperação novamente.
  • Você tentar reanexar o banco de dados Test_RO_FG_DB INST1.
Nesse cenário, você não pode reanexar o banco de dados INST1. E você receber a seguinte mensagem de erro no log de erro do SQL Server:

2012-05-03 22:55:45.37 spid52 iniciando backup banco de dados 'Test_RO_FG_DB'.
2012-05-03 22:55:45.78 spid52 * *******************************************************************************
2012-05-03 22:55:45.78 spid52 * iniciar despejo de pilha:
2012-05-03 22:55:45.78 spid52 * 03/05/12 22: 55: 45 spid 52
2012-05-03 22:55:45.78 spid52 * local: logscan.cpp:1490
2012-05-03 22:55:45.78 spid52 * expressão: falso
2012-05-03 22:55:45.78 spid52 * SPID: 52
2012-05-03 22:55:45.78 spid52 * ID de processo: 9156
2012-05-03 22:55:45.78 spid52 * Descrição: valor de opção inválida
2012-05-03 22:55:45.78 spid52 * 98 do Buffer de entrada bytes -
2012-05-03 22:55:45.78 spid52 * alterar banco de dados Test_RO_FG_DB definir on-line
2012-05-03 22:55:51.05 spid52 erro: 17065, gravidade: 16, estado: 1.
2012-05-03 22:55:51.05 spid52 SQL Server afirmação: arquivo: <logscan.cpp>, linha = 1490 falha na asserção = valor de opção inválida 'FALSE'. Esse erro pode ser relacionados ao tempo. Se o erro persistir depois de executar a instrução novamente, use DBCC CHECKDB para verificar a integridade estrutural do banco de dados ou reinicie o servidor para garantir que as estruturas de dados na memória não estão corrompidas.
2012-05-03 22:55:51.10 spid52 erro: 3624, gravidade: 20, estado: 1.
Falha na verificação de declaração do 2012-05-03 22:55:51.10 spid52 um sistema. Verifique o log de erro de SQL Server para obter detalhes. Normalmente, uma falha de asserção é causada por uma software bug ou corrupção de dados. Para verificar se há corrupção do banco de dados, considere executar DBCC CHECKDB. Se você concordou em Enviar despejos à Microsoft durante a instalação, um minidespejo será enviado à Microsoft. Uma atualização pode ser disponibilizada pela Microsoft no Service Pack mais recente ou em uma QFE do suporte técnico.
2012-05-03 22:56:09.16 spid52 erro: 3414, gravidade: 21, estado: 1.
2012-05-03 22:56:09.16 spid52 um erro ocorreu durante a recuperação, impedindo que o banco de dados 'Test_RO_FG_DB' (banco de dados ID 19) reiniciar. Diagnosticar erros de recuperação e corrigi-los ou restaurar de um bom backup. Se erros não são corrigidos ou esperados, contate o suporte técnico.
2012-05-03 22:56:09.18 spid52 erro: 928, gravidade: 20, estado: 1.
2012-05-03 22:56:09.18 spid52 durante a atualização, a exceção de banco de dados gerado 926, gravidade 14, estado 1, endereço 0000000000F6A971. Use o número de exceção para determinar a causa.</logscan.cpp>


Observação Esse problema ocorre somente quando você tentar anexar um banco de dados que contém um grupo de arquivos está marcado como READ_ONLY. Esse problema não ocorre quando você tentar mover um banco de dados READ_ONLY na qual todos os dados está marcado como READ_ONLY.

Causa

Esse problema ocorre porque SQL Server 2012 não detectar o grupo de arquivos somente leitura antes de começar a atualizar o banco de dados. Após a atualização foi iniciada, SQL Server 2012 grava entradas de log de transações. Versões anteriores não é possível ler as novas entradas de log de transação.

Ponto Da Situação

A Microsoft confirmou que este é um problema nos produtos da Microsoft listados na seção "Aplica-se a".

Resolução

Informações da atualização cumulativa

SQL Server 2012

A correção para esse problema foi lançada primeiro na atualização cumulativa 2 para SQL Server 2012. Para obter mais informações sobre esse pacote de atualizações cumulativas, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
2703275 Pacote de atualização cumulativa 2 SQL Server 2012
Observação Como as compilações são cumulativas, cada novo lançamento de correções contém todos os hotfixes e lançamento de corrigir todas as correções de segurança que foram incluídas com o anterior 2012 de SQL Server. A Microsoft recomenda que você considere a aplicação a versão mais recente de correção que contém esse hotfix. Para obter mais informações, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
2692828 2012 De SQL Server compilações lançadas após o lançamento do SQL Server 2012
Você deve aplicar um hotfix de SQL Server 2012 para uma instalação do SQL Server 2012.

Como contornar

Para contornar esse problema, use um dos seguintes métodos.

Método 1

Restaure um backup do banco de dados de INST1 em INST2.

Observação O problema descrito na seção "Sintomas" não ocorre SQL Server 2012 quando você restaurar um backup de uma versão anterior.

Método 2

Execute uma atualização in-loco de versão anterior do SQL Server para SQL Server 2012.

Método 3

Mova um banco de dados que contém um grupo de arquivos somente leitura para uma instância de SQL Server 2012. Para fazer isso, siga estas etapas.

Observação Execute as etapas 4 a 11 no servidor que está executando o SQL Server 2012. Por exemplo, execute as etapas 4 a 11 no INST2.
  1. Em INST1, desanexe o banco de dados. Por exemplo, desanexe o banco de dados Test_RO_FG_DB.
  2. Mova os arquivos de banco de dados para o servidor que hospeda a instância INST2.
  3. Tente anexar o banco de dados INST2. O exemplo de código a seguir mostra como fazer isso:
    CREATE DATABASE [Test_RO_FG_DB] ON PRIMARY ( NAME = N'Test_RO_FG', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL11.SQL2012\MSSQL\DATA\Test_RO_FG.mdf' ), 
    FILEGROUP [RO_FG] ( NAME = N'Test_RO_FG_File1', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL11.SQL2012\MSSQL\DATA\Test_RO_FG_File1.ndf' ), 
    FILEGROUP [RW_FG] ( NAME = N'Test_RW_FG_File1', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL11.SQL2012\MSSQL\DATA\Test_RW_FG_File1.ndf' )
    LOG ON ( NAME = N'Test_RO_FG_log', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL11.SQL2012\MSSQL\DATA\Test_RO_FG_log.ldf' )
    FOR ATTACH;
    GO
    Observação Você receberá a mensagem de erro 3425 mencionada na seção "Sintomas".
  4. Em um prompt de comando, renomeie os arquivos de banco de dados. O comando de exemplo a seguir mostra como fazer isso:
    rename Test_RO_FG.mdf original_Test_RO_FG.mdf
    rename Test_RO_FG_File1.ndf original_Test_RO_FG_File1.ndf
    rename Test_RW_FG_File1.ndf original_Test_RW_FG_File1.ndf
    rename Test_RO_FG_log.ldf original_Test_RO_FG_log.ldf
  5. SQL Server Management Studio, crie um banco de dados que tem o mesmo nome e a estrutura física do banco de dados que você deseja anexar. O exemplo de código a seguir mostra como fazer isso:
    CREATE DATABASE [Test_RO_FG_DB] ON PRIMARY ( NAME = N'Test_RO_FG_DB', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL11.SQL2012\MSSQL\DATA\Test_RO_FG_DB.mdf' , SIZE = 4072KB , MAXSIZE = UNLIMITED, FILEGROWTH = 1024KB ), 
    FILEGROUP [RO_FG] ( NAME = N'Test_RO_FG_File1', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL11.SQL2012\MSSQL\DATA\Test_RO_FG_File1.ndf' , SIZE = 8192KB , MAXSIZE = UNLIMITED, FILEGROWTH = 1024KB ), 
    FILEGROUP [RW_FG] ( NAME = N'Test_RW_FG_File1', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL11.SQL2012\MSSQL\DATA\Test_RW_FG_File1.ndf' , SIZE = 8192KB , MAXSIZE = UNLIMITED, FILEGROWTH = 1024KB )
    LOG ON ( NAME = N'Test_RO_FG_log', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL11.SQL2012\MSSQL\DATA\Test_RO_FG_log.ldf' , SIZE = 1024KB , MAXSIZE = 2048GB , FILEGROWTH = 10%)
    GO
  6. Defina o banco de dados offline. Para fazer isso, execute o seguinte comando:
    ALTER DATABASE [Test_RO_FG_DB] SET OFFLINE
    GO
  7. Em um prompt de comando, renomeie os arquivos no novo banco de dados. O comando de exemplo a seguir mostra como fazer isso:
    rename Test_RO_FG.mdf new_Test_RO_FG.mdf
    rename Test_RO_FG_File1.ndf new_Test_RO_FG_File1.ndf
    rename Test_RW_FG_File1.ndf new_Test_RW_FG_File1.ndf
    rename Test_RO_FG_log.ldf new_Test_RO_FG_log.ldf
  8. Em um prompt de comando, renomeie os arquivos de banco de dados que você moveu na etapa 2. Renomeie os arquivos para corresponder ao banco de dados que você criou na etapa 4. O comando de exemplo a seguir mostra como fazer isso:
    rename original_Test_RO_FG.mdf Test_RO_FG.mdf 
    rename original_Test_RO_FG_File1.ndf Test_RO_FG_File1.ndf 
    rename original_Test_RW_FG_File1.ndf Test_RW_FG_File1.ndf 
    rename original_Test_RO_FG_log.ldf Test_RO_FG_log.ldf
  9. Defina o banco de dados on-line. Para fazer isso, execute o seguinte comando:
    ALTER DATABASE [Test_RO_FG_DB] SET ONLINE
    GO
  10. Verifique se o banco de dados está online e restabelecer a funcionalidade do Service Broker.
  11. Exclua os arquivos de banco de dados que não são necessários. O comando de exemplo a seguir mostra como fazer isso:
    del /P new_Test_RO_FG.mdf
    del /P new_Test_RO_FG_File1.ndf
    del /P new_Test_RW_FG_File1.ndf
    del /P new_Test_RO_FG_log.ldf
Método 4

Reconecte um banco de dados que contém um grupo de arquivos somente leitura para a instância anterior do SQL Server. Para fazer isso, siga estas etapas.

Observações
  • O banco de dados também contém novas entradas de log de transação de atualização falha.
  • Execute as etapas 3 a 10 no servidor que está executando uma versão anterior do SQL Server. Por exemplo, execute as etapas 3 a 10 no INST1.

  1. Mova os arquivos de banco de dados para a instância de SQL Server que está hospedando o INST1.
  2. Tente anexar o banco de dados INST1. O exemplo de código a seguir mostra como fazer isso:
    CREATE DATABASE [Test_RO_FG_DB] ON PRIMARY ( NAME = N'Test_RO_FG_DB', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL10_50.SQL2008R2\MSSQL\DATA\Test_RO_FG_DB.mdf' ), 
    FILEGROUP [RO_FG] ( NAME = N'Test_RO_FG_File1', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL10_50.SQL2008R2\MSSQL\DATA\Test_RO_FG_File1.ndf' ), 
    FILEGROUP [RW_FG] ( NAME = N'Test_RW_FG_File1', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL10_50.SQL2008R2\MSSQL\DATA\Test_RW_FG_File1.ndf' )
    LOG ON ( NAME = N'Test_RO_FG_log', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL10_50.SQL2008R2\MSSQL\DATA\Test_RO_FG_log.ldf' )
    FOR ATTACH
    GO
    Observação Você receberá a mensagem de erro 3624 mencionada na seção "Sintomas". Você também receberá uma mensagem de erro 1813.
  3. Em um prompt de comando, renomeie os arquivos de banco de dados INST1. O comando de exemplo a seguir mostra como fazer isso:
    rename Test_RO_FG.mdf original_Test_RO_FG.mdf
    rename Test_RO_FG_File1.ndf original_Test_RO_FG_File1.ndf
    rename Test_RW_FG_File1.ndf original_Test_RW_FG_File1.ndf
    rename Test_RO_FG_log.ldf original_Test_RO_FG_log.ldf
  4. SQL Server Management Studio, crie um banco de dados que tem o mesmo nome e a estrutura física do banco de dados que você deseja anexar. O exemplo de código a seguir mostra como fazer isso:
    CREATE DATABASE [Test_RO_FG_DB] ON PRIMARY ( NAME = N'Test_RO_FG_DB', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL10_50.SQL2008R2\MSSQL\DATA\Test_RO_FG_DB.mdf' , SIZE = 4072KB , MAXSIZE = UNLIMITED, FILEGROWTH = 1024KB ), 
    FILEGROUP [RO_FG] ( NAME = N'Test_RO_FG_File1', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL10_50.SQL2008R2\MSSQL\DATA\Test_RO_FG_File1.ndf' , SIZE = 8192KB , MAXSIZE = UNLIMITED, FILEGROWTH = 1024KB ), 
    FILEGROUP [RW_FG] ( NAME = N'Test_RW_FG_File1', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL10_50.SQL2008R2\MSSQL\DATA\Test_RW_FG_File1.ndf' , SIZE = 8192KB , MAXSIZE = UNLIMITED, FILEGROWTH = 1024KB )
    LOG ON ( NAME = N'Test_RO_FG_log', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL10_50.SQL2008R2\MSSQL\DATA\Test_RO_FG_log.ldf' , SIZE = 1024KB , MAXSIZE = 2048GB , FILEGROWTH = 10%)
    GO
  5. Defina o banco de dados offline. Para fazer isso, execute o seguinte comando:
    ALTER DATABASE [Test_RO_FG_DB] SET OFFLINE
    GO
  6. Em um prompt de comando, renomeie os arquivos no novo banco de dados. O comando de exemplo a seguir mostra como fazer isso:
    rename Test_RO_FG.mdf new_Test_RO_FG.mdf
    rename Test_RO_FG_File1.ndf new_Test_RO_FG_File1.ndf
    rename Test_RW_FG_File1.ndf new_Test_RW_FG_File1.ndf
    rename Test_RO_FG_log.ldf new_Test_RO_FG_log.ldf
  7. Em um prompt de comando, renomeie os arquivos de banco de dados que você moveu na etapa 2. Renomeie os arquivos para corresponder ao banco de dados que você criou na etapa 4. O comando de exemplo a seguir mostra como fazer isso:
    rename original_Test_RO_FG.mdf Test_RO_FG.mdf 
    rename original_Test_RO_FG_File1.ndf Test_RO_FG_File1.ndf 
    rename original_Test_RW_FG_File1.ndf Test_RW_FG_File1.ndf 
    rename original_Test_RO_FG_log.ldf Test_RO_FG_log.ldf
  8. Definir o banco de dados para o modo de EMERGÊNCIA e executar um reparo. Para fazer isso, execute o seguinte comando.

    Observação Os logs de transação do banco de dados são reconstruídos durante esta etapa. Isso pode resultar em perda de dados. Portanto, recomendamos que você faça backup do banco de dados antes de executar essa etapa.
    ALTER DATABASE Test_RO_FG_DB SET EMERGENCY
    GO
    ALTER DATABASE Test_RO_FG_DB SET SINGLE_USER
    GO
    DBCC CHECKDB (Test_RO_FG_DB, repair_allow_data_loss) WITH ALL_ERRORMSGS
    GO
    ALTER DATABASE Test_RO_FG_DB SET MULTI_USER
    GO
  9. Verifique se o banco de dados está online e restabelecer a funcionalidade do Service Broker.
  10. Exclua os arquivos de banco de dados que não são necessários. O comando de exemplo a seguir mostra como fazer isso:
    del /P new_Test_RO_FG.mdf
    del /P new_Test_RO_FG_File1.ndf
    del /P new_Test_RW_FG_File1.ndf
    del /P new_Test_RO_FG_log.ldf

Mais Informação

Há várias etapas que ocorrem quando um banco de dados é anexado a uma instância de SQL Server. Essas etapas incluem a recuperação do banco de dados e atualizar os arquivos de versões anteriores do SQL Server.

O problema descrito na seção "Sintomas", SQL Server 2012 começa o processo de atualização antes dos arquivos somente leitura no banco de dados são detectados. As etapas de atualização incluem iniciar uma transação para limpar o bit "desligado corretamente" na página de inicialização do banco de dados. Versões anteriores do SQL Server não podem ler o registro de transação inicial. Portanto, o banco de dados não é utilizável em versões anteriores do SQL Server e SQL Server gera o erro 3624.

Upgrades no local quando um banco de dados está marcado como somente leitura

Quando você executa uma atualização in-loco de uma instância de SQL Server que contém um banco de dados somente leitura chamado Test_RO_DB para SQL Server 2012, você pode receber mensagens de erro semelhantes à seguinte no log de erro do SQL Server:

2012-05-04 21:03:59.23 spid19s iniciando o banco de dados 'Test_RO_DB'.
banco de 2012-05-04 21:03:59.56 spid19s convertendo dados 'Test_RO_DB' de 661 versão para a versão atual 706.
2012-05-04 21:03:59.56 spid19s erro: 928, gravidade: 20, estado: 1.
2012-05-04 21:03:59.56 spid19s durante a atualização, banco de dados gerado exceção 3415 gravidade 16, estado 1, endereço 000007FEE66D784A. Use o número de exceção para determinar a causa.
2012-05-04 21:03:59.61 spid19s erro: 3415, gravidade: 16, estado: 1.
2012-05-04 21:03:59.61 spid19s banco de dados 'Test_RO_DB' não pode ser atualizado porque ele é somente leitura possui arquivos somente leitura ou o usuário não tem permissões para modificar alguns dos arquivos. Tornar gravável do banco de dados ou arquivos e execute a recuperação novamente.


No final do processo de atualização, o banco de dados de Test_RO_DB será no estado RECOVERY_PENDING. Você deve usar o comando ALTER DATABASE para definir o banco de dados READ_WRITE. Use o comando ALTER DATABASE para definir o banco de dados como READ_ONLY. Isso permite que o mecanismo SQL Server atualizar o banco de dados para a versão correta.

In-loco atualizações quando um banco de dados de leitura/gravação contém grupos de arquivos são marcados como somente leitura

Quando você executa uma atualização in-loco para SQL Server 2012, você pode receber mensagens semelhantes à seguinte no log de erro do SQL Server. Esse problema ocorre quando a instância anterior do SQL Server hospeda um banco de dados de leitura/gravação e contém grupos de arquivos são marcados como READ_ONLY. No entanto, o processo de atualização termina como esperado e inicia o banco de dados on-line.

Observação A seguinte mensagem de erro, o banco de dados chamado Test_RO_FG:

2012-05-04 21:03:59.23 spid18s iniciando o banco de dados 'Test_RO_FG'.
banco de 2012-05-04 21:03:59.71 spid18s convertendo dados 'Test_RO_FG' de 661 versão para a versão atual 706.
2012-05-04 21:03:59.71 spid18s banco de dados 'Test_RO_FG' executando a etapa de atualização de versão 661 versão 668.



Propriedades

Artigo: 2710782 - Última revisão: 18 de junho de 2012 - Revisão: 2.0
A informação contida neste artigo aplica-se a:
  • Microsoft SQL Server 2012 Enterprise
Palavras-chave: 
kbsurveynew kbprb kbtshoot kbmt KB2710782 KbMtpt
Tradução automática
IMPORTANTE: Este artigo foi traduzido por um sistema de tradução automática (também designado por Machine translation ou MT), não tendo sido portanto revisto ou traduzido por humanos. A Microsoft tem artigos traduzidos por aplicações (MT) e artigos traduzidos por tradutores profissionais. O objectivo é simples: oferecer em Português a totalidade dos artigos existentes na base de dados do suporte. Sabemos no entanto que a tradução automática não é sempre perfeita. Esta pode conter erros de vocabulário, sintaxe ou gramática? erros semelhantes aos que um estrangeiro realiza ao falar em Português. A Microsoft não é responsável por incoerências, erros ou estragos realizados na sequência da utilização dos artigos MT por parte dos nossos clientes. A Microsoft realiza actualizações frequentes ao software de tradução automática (MT). Obrigado.
Clique aqui para ver a versão em Inglês deste artigo: 2710782

Submeter comentários

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com