Tenho várias instâncias do SQL 2008, todas executando o Microsoft SQL Server 2008 (SP4) (confirmado select @@VERSIONnos servidores em questão). Eles são executados no Windows Server 2008 ou no Windows Server 2008 R2.
Dois deles existem apenas para enviar com o Red Gate SQL Backup 7.4.0.23, e estou tendo problemas com um deles. (É um dos servidores 2008 R2, se isso faz diferença.) Estou usando um trabalho t-sql que percorre uma lista muito longa de bancos de dados (puxados dinamicamente de outros servidores) e os restaura.
Anteriormente, esse trabalho levava menos de 10 minutos. Agora está levando de uma hora e meia a duas horas e meia. Não houve alterações de código e nenhum aumento radical no número de bancos de dados a serem restaurados. Seu servidor irmão, com código quase idêntico, está executando este trabalho em menos de 4 minutos. (O servidor irmão é um dos servidores não R2, se isso fizer diferença.)
O log de eventos e o log de erros SQL mostram um erro de:
Erro do sistema operacional 0x80770006 (falha ao recuperar o texto para este erro. Motivo: 317)."
Não sei se esta é a causa do problema ou não; O Google sugere que isso ocorre quando diferentes versões do SQL Server coexistem ou quando o Red Gate SQL Backup 6.x precisa de um patch especial. Não acho que nenhum desses seja o problema porque o erro é intermitente, as versões do SQL Server são idênticas e estou executando o Red Gate SQL Backup 7.x, mas certamente posso estar errado. Os fóruns do Red Gate sugeriram executar uma consulta para ver se a memória do VAS estava baixa, pois isso poderia causar problemas semelhantes.
VAS Total avail mem, KB Max free size, KB
8320072080 8314974784
Outras coisas que tentei resolver o problema incluem:
- Limpando arquivos de log antigos de "C:\ProgramData\Red Gate\SQL Backup\Log[instancename]", porque a última vez que o trabalho ficou lento foi porque havia muitos arquivos de log nesse diretório.
- Verificando e resolvendo quaisquer problemas de memória no servidor.
- Certifique-se de que o antivírus tenha exclusões para arquivos .sqb (SQL Backup).
- Executando
CHKDSKnos volumes envolvidos. - Observando a execução do trabalho com
sp_WhoIsActive. - Verificando msdb para certificar-se de que o trabalho de limpeza estava sendo executado corretamente. A entrada mais antiga tem quatro semanas, mas ainda parece muito grande.
- Executando
DBCC CheckDBem msdb. - Pedir àqueles com visibilidade nos utilitários de armazenamento para verificar se há alguma falha lá. Eles dizem que meu armazenamento é "ideal".
Coisas que pretendo fazer:
- Limpe o histórico do msdb para apenas uma semana. É uma consulta de bloqueio, então quero esperar até depois do expediente, mesmo que os clientes não consultem ativamente esta instância.
Observar a execução do trabalho com sp_whoisactiveparece mostrar muitos PAGEIOLATCH(ambos SHe EX) no msdb, mas as esperas geralmente duram menos de um segundo. (A consulta é o procedimento de atualização do conjunto de backup.)
O único erro que posso encontrar são variantes intermitentes de (do log de erros do SQL):
2016-05-25 14:12:39.18 Backup Error: 3201, Severity: 16, State: 7.
2016-05-25 14:12:39.18 Backup Cannot open backup device 'SQLBACKUP_D99ABDE1-42E6-4617-B1EB-BDA30BF8113B'. Operating system error 0x80770006(failed to retrieve text for this error. Reason: 317).
(seguido imediatamente por "Log foi restaurado.") e (do log do aplicativo Visualizador de Eventos):
SQLVDI: Loc=SVDS::Open. Desc=Bad State. ErrorCode=(-1). Process=8056. Thread=10512. Server. Instance=DR. VD=Global\SQLBACKUP_D99ABDE1-42E6-4617-B1EB-BDA30BF8113B_SQLVDIMemoryName_0.
Cannot open backup device 'SQLBACKUP_D99ABDE1-42E6-4617-B1EB-BDA30BF8113B'. Operating system error 0x80770006(failed to retrieve text for this error. Reason: 317).
o que estou perdendo? Onde mais posso procurar?
Coisas que fiz depois do expediente:
- Purgar msdb para uma semana.
- Adicione uma chave de registro para o tempo limite de VDI para Red Gate SQL Backup. (Eu alterei esse valor anteriormente e excluí a chave. O padrão é 30 segundos e pensei que um banco de dados parecia travar muito mais do que 30 segundos, então coloquei uma chave com o valor padrão para ter certeza.)
Nenhuma diferença, mas encontrei essa consulta e parece ter me dado uma pista. Um banco de dados em particular que eu pensei ter notado sp_WhoIsActivedemorando muito, bem. Não foi minha imaginação. Os tempos de restauração aproximados incluem 5068100, 4252443, 4408026, 2184080, 2786363 (além de coisas como 330, 373, etc.). (Esses são milissegundos.) Eu verifiquei o número de VLFs neste banco de dados e há apenas 46, então algo mais está acontecendo.
Vou carregar uma lista completa de bancos de dados de envio de log e executá-la novamente.
Os bancos de dados secundários estão em restauração, não em espera. Estamos usando o Red Gate para o envio de log para a compactação, porque já temos cópias dos backups criptografados gravados em um compartilhamento naquele servidor e porque havia uma preocupação com a possível sobrecarga no mestre. Há muitos bancos de dados sendo enviados. Mais de 800 naquele servidor. Eu tento fazer isso como um processo para reduzir a contenção do msdb.
As máquinas são bare metal, não VMs. Está apenas ficando para trás, pelo que posso dizer, e a contenção é a restauração ou a gravação de informações sobre a restauração no MSDB (ou ambos). A restauração mais recente ocorreu no último minuto.