Tempo de espera extremo ao colocar um banco de dados do SQL Server offline

Estou tentando realizar alguma manutenção offline (restauração do banco de dados dev a partir do backup em tempo real) no meu banco de dados dev, mas o comando 'Take Offline' via SQL Server Management Studio está executando muito lentamente - da ordem de 30 minutos ou mais. Estou quase no fim e não consigo encontrar nenhuma referência on-line sobre o que pode estar causando o problema de velocidade ou como corrigi-lo.

Alguns sites sugeriram que conexões abertas ao banco de dados causam essa desaceleração, mas o único aplicativo que usa esse banco de dados é a instância do IIS da minha máquina de desenvolvimento e o serviço é interrompido - não há mais conexões abertas.

O que poderia estar causando essa desaceleração e o que posso fazer para acelerar?

Após algumas pesquisas adicionais (novos termos de pesquisa inspirados na resposta do gbn e no comentário do u07ch na resposta do KMike), achei isso, que foi concluído com sucesso em 2 segundos:

ALTER DATABASE <dbname> SET OFFLINE WITH ROLLBACK IMMEDIATE

(Atualizar)

Quando isso ainda falhar com o seguinte erro, você pode corrigi-lo como inspirado nesta postagem do blog :

ALTER DATABASE falhou porque não foi possível colocar um bloqueio no banco de dados 'dbname'. Tente novamente mais tarde.

você pode executar o seguinte comando para descobrir quem está mantendo um bloqueio no seu banco de dados:

EXEC sp_who2

E use o SPIDque encontrar no seguinte comando:

KILL <SPID>

Em seguida, execute o ALTER DATABASEcomando novamente. Agora deve funcionar.

Provavelmente, há uma conexão com o banco de dados de algum lugar (um exemplo raro: atualização estatística assíncrona )

Para encontrar conexões, use sys.sysprocesses

USE master
SELECT * FROM sys.sysprocesses WHERE dbid = DB_ID('MyDB')

Para forçar desconexões, use ROLLBACK IMMEDIATE

USE master
ALTER DATABASE MyDB SET SINGLE_USER WITH ROLLBACK IMMEDIATE

Você tem alguma janela aberta do SQL Server Management Studio conectada a esse banco de dados?

Coloque-o no modo de usuário único e tente novamente.

No meu caso, depois de esperar tanto para terminar, não tive paciência e simplesmente fechei o estúdio de gerenciamento. Antes de sair, ele mostrava a mensagem de sucesso, db está offline. Os arquivos estavam disponíveis para renomear.

execute o procedimento armazenado sp_who2

Isso permitirá que você veja se existem bloqueios de bloqueio. Mate o seu deve corrigi-lo.

No SSMS: clique com o botão direito do mouse no ícone do SQL Server, Activity Monitor. Processos abertos. Encontre o processado conectado. Clique com o botão direito do mouse no processo, Kill.

sempre que você se deparar com esse tipo de coisa, sempre pense em seu log de transações. A declaração alter db com reversão imediata indica que esse é o caso. Verifique isto: http://msdn.microsoft.com/en-us/library/ms189085.aspx

Aprecie os pontos de verificação, etc. Você precisa decidir se vale a pena salvar as transações no seu log e, em seguida, escolher o modo para executar o banco de dados de acordo. Não há realmente nenhuma razão para você ter que esperar, mas também não há nenhuma razão para você perder dados - você pode ter as duas.

Fechar a instância do SSMS (SQL Service Manager) a partir da qual a solicitação foi feita resolveu o problema para mim .....

No meu caso, eu havia examinado algumas tabelas no banco de dados antes de executar esta ação. Minha conta de usuário estava mantendo uma conexão ativa com este banco de dados no SSMS. Depois que eu desconectei do servidor no SSMS (deixando a caixa de diálogo 'Colocar o banco de dados offline' aberta)), a operação foi bem-sucedida.

Para contornar isso, parei o site que estava conectado ao banco de dados no IIS e imediatamente o painel 'congelado' 'colocar o db offline' ficou descongelado.

Eu tentei todas as sugestões abaixo e nada funcionou.

1. EXEC sp_who

2. Matar <SPID>

3. ALTER DATABASE SET SINGLE_USER COM Reversão Imediata

   ALTER DATABASE SET OFFLINE COM ROLLBACK IMEDIATO

   Resultado: os dois comandos acima também foram bloqueados.

4) Clique com o botão direito do mouse no banco de dados -> Propriedades -> Opções Definir somente leitura do banco de dados como True Clique em 'Sim' no aviso de diálogo. O SQL Server fechará todas as conexões com o banco de dados.

Resultado: a janela ficou presa na execução.

Como último recurso, reiniciei o serviço do servidor SQL do gerenciador de configuração e executei ALTER DATABASE SET OFFLINE WITH ROLLBACK IMMEDIATE. Funcionou como um encanto

Além disso, feche todas as janelas de consulta abertas que estejam conectadas ao banco de dados em questão;)

No SSMS, defina o banco de dados como somente leitura e depois volte. As conexões serão fechadas, o que libera os bloqueios.

No meu caso, havia um site que tinha conexões abertas com o banco de dados. Este método foi bastante fácil:

1. Clique com o botão direito do mouse no banco de dados -> Propriedades -> Opções
2. Defina Database Read-Onlycomo True
3. Clique em 'Sim' no aviso de diálogo. O SQL Server fechará todas as conexões com o banco de dados.
4. Reabra Opções e desative somente leitura
5. Agora tente renomear o banco de dados ou colocá-lo offline.

Para mim, eu apenas tive que entrar no Job Activity Monitor e parar duas coisas que estavam sendo processadas. Em seguida, ficou offline imediatamente. No meu caso, embora eu soubesse quais eram esses dois processos e que não havia problema em detê-los.

No meu caso, o banco de dados estava relacionado a uma instalação antiga do Sharepoint. A interrupção e desativação dos serviços relacionados no gerenciador de servidores "desligaram" a ação offline, que estava em execução por 40 minutos, e foi concluída imediatamente.

Você pode verificar se algum serviço está utilizando o banco de dados no momento.

Da próxima vez, na caixa de diálogo Take Offline, lembre-se de marcar a caixa de seleção 'Descartar todas as conexões ativas'. Eu também estava no SQL_EXPRESS na máquina local sem conexões, mas essa desaceleração aconteceu comigo, a menos que eu marque essa caixa de seleção.

No meu caso, parei o servidor Tomcat. imediatamente o DB ficou offline.