Início / dba / Perguntas / 139555
Accepted
Katherine Villyard
Asked: 2016-05-26 12:48:20 +0800 CST

Navio de toras inexplicável desacelera

  • 772

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.

sql-server sql-server-2008-r2

2 respostas

  1. Isso é maior que um comentário, mas algo para testar primeiro e depois implementar:

    Você está enviando mais de 800 bancos de dados. Isso é uma grande quantidade de bancos de dados que você carrega a cada 15 minutos.

    Você deve descarregar alguns bancos de dados para outro servidor. Bancos de dados IMHO 800 em um único servidor é muito!

    Tivemos um problema semelhante com o logshipping quando enviamos mais de 200 bancos de dados de NY para a região de LD.

    O que fizemos é o seguinte:

    • Houve bloqueio de gravação para msdb.dbo.sysjobhistory with (TABLOCKX). A TABLOCKdica significa que o acesso ao sysjobhistory é sempre serializado. E como você tem muitos trabalhos sendo executados a cada 15 minutos, haverá contenção (bloqueio).

    • Implementamos o sinalizador de rastreamento TF – 1236. Ele apresentará o particionamento de bloqueio de banco de dados. O particionamento do bloqueio DATABASE mantém a profundidade da lista de bloqueios gerenciável em cada partição local. Isso otimiza significativamente o caminho de acesso que é usado para obter um bloqueio de DATABASE.

    • crie índices sysjobhistorye log_shipping_monitor_history_detailtabelas como abaixo:

      use msdb
    go

    create nonclustered index [nc_DBA_sysjobhistory] on dbo.sysjobhistory (
            ,[job_id] 
            ,[step_id]     
            ,[run_date]
            ) 
    include (
            [instance_id]
            ,[step_name]
            ,[sql_message_id]
            ,[sql_severity]
            ,[message]
            ,[run_status]
            ,[run_time]
            ,[run_duration]
            ,[retries_attempted]
            ,[server]
            )
    go

    use [msdb]
    go
    ----- this will help sys.sp_MSprocesslogshippingretentioncleanup proc (delete from msdb.dbo.log_shipping_monitor_history_detail).. that does the cleanup of logshipping.

    create nonclustered index [nc_DBA_LogShipping_monitor_history_detail] on [dbo].[log_shipping_monitor_history_detail] (
            [agent_id] asc
            ,[agent_type] asc
            ,[log_time_utc] asc
            )
    go
    • 4
  2. Best Answer

    Eu carreguei todos os bancos de dados que estão sendo enviados para esta consulta :

    DECLARE @path NVARCHAR(260);

SELECT 
   @path = REVERSE(SUBSTRING(REVERSE([path]), 
   CHARINDEX(CHAR(92), REVERSE([path])), 260)) + N'log.trc'
FROM    sys.traces
WHERE   is_default = 1;

SELECT *, rn = ROW_NUMBER() OVER 
  (PARTITION BY DatabaseName ORDER BY StartTime)
INTO #blat
FROM sys.fn_trace_gettable(@path, DEFAULT) 
WHERE DatabaseName IN (
  N'db1', N'db2' -- , ...
)
ORDER BY StartTime DESC; 

SELECT b.DatabaseName, b.TextData, 
  ApproximateRestoreTime = DATEDIFF(MILLISECOND, b.StartTime, b2.StartTime)
FROM #blat AS b 
LEFT OUTER JOIN #blat AS b2
ON b.DatabaseName = b2.DatabaseName
AND b2.rn = b.rn + 1
WHERE b.EventClass = 115 AND b.EventSubClass = 2
ORDER BY b.StartTime DESC;

GO
DROP TABLE #blat;

    (Mas eu editei para me dar a hora de início, apenas como uma verificação de sanidade.) Isso me deu uma série de resultados como:

    DatabaseName    ApproximateRestoreTime  StartTime

DB1             2228166                 5/26/16 12:07 PM
DB1             370                     5/26/16 12:07 PM
DB1             373                     5/26/16 12:07 PM
DB1             366                     5/26/16 12:07 PM
DB1             383                     5/26/16 12:07 PM
DB1             350                     5/26/16 12:07 PM
DB1             350                     5/26/16 12:07 PM
DB1             1730                    5/26/16 12:07 PM
DB1             1726                    5/26/16 12:07 PM
DB1             426                     5/26/16 12:07 PM
DB1             1946                    5/26/16 12:07 PM

DB2             2237880                 5/26/16 12:07 PM
DB2             2420                    5/26/16 12:07 PM
DB2             2933                    5/26/16 12:07 PM
DB2             1723                    5/26/16 12:07 PM
DB2             360                     5/26/16 12:07 PM
DB2             353                     5/26/16 12:07 PM
DB2             1370                    5/26/16 12:07 PM
DB2             5433                    5/26/16 12:07 PM
DB2             400                     5/26/16 12:07 PM
DB2             436                     5/26/16 12:07 PM
DB2             856                     5/26/16 12:07 PM

DB3             2255540                 5/26/16 12:07 PM
DB3             2513                    5/26/16 12:07 PM
DB3             390                     5/26/16 12:07 PM
DB3             360                     5/26/16 12:07 PM
DB3             470                     5/26/16 12:07 PM
DB3             4830                    5/26/16 12:07 PM
DB3             1046                    5/26/16 12:07 PM
DB3             2753                    5/26/16 12:06 PM
DB3             373                     5/26/16 12:06 PM
DB3             933                     5/26/16 12:06 PM
DB3             813                     5/26/16 12:06 PM

DB4             2272020                 5/26/16 12:06 PM
DB4             2290                    5/26/16 12:06 PM
DB4             1936                    5/26/16 12:06 PM
DB4             353                     5/26/16 12:06 PM
DB4             353                     5/26/16 12:06 PM
DB4             360                     5/26/16 12:06 PM
DB4             393                     5/26/16 12:06 PM
DB4             4000                    5/26/16 12:06 PM
DB4             853                     5/26/16 12:06 PM
DB4             2133                    5/26/16 12:06 PM
DB4             346                     5/26/16 12:06 PM

    Parece-me que os bancos de dados estão restaurando bem e a lentidão está na gravação dessas informações no msdb. Isso combinado com o fato de que sp_WhoIsActivemostrava muita aparência lenta:

    <?query --
(@param0 nvarchar(20), @param1 nvarchar(46), @param2 nvarchar(48), @param3 nvarchar(48), @param4 nvarchar(48), @param5 nvarchar(48), @param6 nvarchar(48), @param7 nvarchar(48), @param8 nvarchar(48), @param9 nvarchar(42), @param10 nvarchar(77), @param11 nvarchar(24), @param12 nvarchar(9), @param13 nvarchar(16), @param14 nvarchar(10), @param15 nvarchar(28), @param16 nvarchar(7), @param17 nvarchar(7), @param18 nvarchar(9), @param19 nvarchar(3), @param20 nvarchar(24), @param21 nvarchar(13), @param22 nvarchar(3), @param23 nvarchar(27), @param24 nvarchar(9), @param25 nvarchar(24), @param26 nvarchar(3), @param27 nvarchar(27))
declare @backup_set_id int
declare @restore_history_id int
select @backup_set_id = backup_set_id from msdb.dbo.backupset where backup_set_uuid = N'{4A3BE7C3-AF68-40D8-9261-35C781B6642C}'
if @backup_set_id is null begin
declare @media_set_id int
declare @media_count int
select @media_set_id = media_set_id from msdb.dbo.backupmediaset where media_uuid = N'{D603F5E0-6150-476A-A5B1-E7D2840AB05C}'
(etc., etc.)

    me fez pensar que sim, msdb é meu problema.

    Ele tinha apenas uma semana de histórico desde esta manhã, mas há mais de 800 bancos de dados sendo restaurados a cada 15 minutos, então o MDF ainda tinha 5 GB. Desativei os jobs e reduzi esse número para 3 dias e adicionei alguns índices . O trabalho agora está levando 4 ou 5 minutos.

    Ainda não sei por que um sistema que está em execução há mais de dois anos, felizmente, com quatro semanas de histórico agora só funciona corretamente com três dias, mas suspeito que minha equipe de armazenamento está errada e meu armazenamento está abaixo do ideal. Eu os coloquei para avaliar isso.

    Enquanto isso, se um dos servidores desta instância estiver protegendo telas azuis, não estarei duas horas e meia desatualizado!

    O provedor de hospedagem agora diz que C:está fragmentado. De qualquer forma, mudei o msdb para um armazenamento mais rápido, já que é o banco de dados que mais trabalha no sistema.

    • 2

relate perguntas