Categorias
Azure SQL Database How To Troubleshooting

Azure SQL Database – Transparent Data Encryption with bring your own key

[bing_translator]

Transparent Data Encryption (TDE) vem por padrão habilitado quando você cria um novo database no Azure SQL Database.  

TDE não é mais uma novidade porem eu tenho visto que é pouco explorada (minha percepção). Se predente usar TDE on-premise vale a pena a leitura no post anterior. 

Habilitar ou desabilitar TDE no Azure SQL Database é simplesmente um click para ON ou OFF e a Microsoft faz tudo para você! Simples né, porem algumas perguntas vinham em relação a esse gerenciamento, por exemplo, como é realizado o gerenciamento de chaves ou porque apenas certificado poderiam ser usados.   

Com isso em mente a Microsoft disponibilizou uma nova opção: Bring Your Own Key. Com certeza isso faz muita diferença uma vez que posso ter o controle maior sobre as minhas chaves e posso aplicar a política definida pela minha empresa. Sendo assim agora eu posso estar cumprindo as conformidades de órgãos regulamentadores com mais transparência.  

https://azure.microsoft.com/en-us/blog/transparent-data-encryption-with-customer-managed-keys-in-azure-sql-database-generally-available/

Bring Your Own Key 

A minha primeira tentativa foi utilizar o Azure Portal para criar todos os passos necessários desde a criação de um novo servidor, key vault e key. 

Key Vault 

Na blade para criar o key vault começaram meus problemas.  

Ao tentar adicionar um acesso para o meu “logical server” eu não pude encontra-lo. Mas a pergunta era, porque não?! 

Voltei a ler a documentação e tentei entender melhor como TDE suporta BYOK. 

https://docs.microsoft.com/en-us/sql/relational-databases/security/encryption/transparent-data-encryption-byok-azure-sql?view=azuresqldb-current 

O servidor logico precisa gerar e assinar uma identidade no Azure Active Directory, mas o Azure Portal não me dá essa opção quando estou criando o servidor.  

Não tem problema, vamos para o PowerShell. 

Set-AzureRmSqlServer `
-ResourceGroupName TDE `
-ServerName tdebalabuch `
-AssignIdentity

Eu não precisei apagar e criar novamente o servidor. 

Depois de executar o comando voltei ao Azure Portal e agora o meu servidor estava disponível para adicionar acesso.

Adicionei as permissões necessárias: GET, WRAP e UNWRAP.

Key 

Agora que a key vault está criado falta apenas a key.

3 importantes atributos que a Key deve ter: 

  • No expiration date 
  • Not disabled 
  • Permissão de get, wrap key, unwrap key  

Habilitar TDE com BYOK 

Agora seria a hora de apertar o botão salvar e tudo funcionar perfeito. Seria, mas não foi! 

Recebi o erro:  

Failed to save Transparent Data Encryption settings for server: {serverName}. Error message: The provided Key Vault uri ‘https://keyvaulttde.vault.azure.net/keys/KeyForTDE/633a6b1fad6941cb96449599df0382c0’ is not valid. Please ensure the vault has the right Recovery Level other than ‘Purgeable’. 

Ok. Fiz algo de erro, vou refazer tudo e vai dar certo! #sqn 

Boa notícia, refiz algumas vezes e pude perceber o que mesmo sem atribuir uma identidade para o servidor quando clico em salvar a etapa de atribuir uma identidade e conceder as permissões o Azure Portal está fazendo 🙂 

Mas ainda falta algo que ele não faz. Então nesse momento apenas é possível utilizar PowerShell e CLI.  

Quebrando os passos 

Aqui eu comecei a quebrar os passos da criação de todos os recursos envolvidos. 

Lendo a documentação novamente me deparo com essa informação 

https://docs.microsoft.com/en-us/sql/relational-databases/security/encryption/transparent-data-encryption-byok-azure-sql?view=azuresqldb-current 

Depois de ler mais documentação percebi que essa funcionalidade era o que estava me causando problema.  

https://docs.microsoft.com/en-us/azure/key-vault/key-vault-ovw-soft-delete 

https://docs.microsoft.com/en-us/azure/key-vault/key-vault-soft-delete-powershell 

Eu tive que executar um comando em PowerShell:

($resource = Get-AzureRmResource -ResourceId (Get-AzureRmKeyVault -VaultName "KeyVaultTDE").ResourceId).Properties | Add-Member -MemberType "NoteProperty" -Name "enableSoftDelete" -Value "true" 

Set-AzureRmResource -resourceid $resource.ResourceId -Properties $resource.Properties  

Get-AzureRmKeyVault -VaultName "KeyVaultTDE"

Voltei ao Azure Portal e pude finalizar o processo. 

Investigando um pouco mais, quando entrei na Key Vault me apareceu a seguinte mensagem! 

OK! Meu entendimento é que Soft Delete ainda está em “Preview” e minha pergunta é: Porque a Microsoft liberou um recurso (TDE com BYOK) que depende de outro recurso que ainda está em “Preview”? 

Enquanto o Azure Portal não tem todas as opções disponíveis o melhor jeito é utilizar o PowerShell.  

https://docs.microsoft.com/en-us/sql/relational-databases/security/encryption/transparent-data-encryption-byok-azure-sql 

https://docs.microsoft.com/en-us/sql/relational-databases/security/encryption/transparent-data-encryption-byok-azure-sql-configure

https://azure.microsoft.com/en-us/blog/transparent-data-encryption-with-customer-managed-keys-in-azure-sql-database-generally-available/ 

https://docs.microsoft.com/en-us/sql/relational-databases/security/encryption/transparent-data-encryption-azure-sql 

https://azure.microsoft.com/en-us/blog/preview-sql-transparent-data-encryption-tde-with-bring-your-own-key-support/ 

 

Categorias
SQL Server Troubleshooting Virtual PASS BR

Transparent Data Encryption and its tricks

[bing_translator]

Transparent Data Encryption – TDE não é mais uma novidade, mas sim uma realidade que devemos usar. Um ponto importante que vale ressaltar é que esse recurso está presente apenas na edição ENTERPRISE do SQL Server.
Existem alguns passos a passos na internet de como implementar, mas eu vou deixar um script que pode ser seguido.

Master Key e Certificados

Uma forma simples de implementar o TDE é utilizar um certificado gerado pelo próprio SQL Server que é protegido pela Master Service Key.
Se você está implementando ou pretende implementar lembre-se que o mais importante de tudo é fazer backup do certificado e das keys!

PARE TUDO e faça BACKUP 

O principal aspecto para utilizar o TDE está relacionado à protecao de chaves incluindo backups separados das chaves de criptografia e a capacitade de restaurar e recuperar esse banco de dados em outro local. Assim como qualquer outro plano de DR, a restauração de bancos de dados de TDE é algo que devemos praticar antes que ocorra o desastre. Você não quer descobrir depois de um evento  que você não estava fazendo o backup da chave TDE corretamente.

Mais uma vez eu utilizei o dbatools para me ajudar a automatizar minha tarefa e quero agradecer ao Claudio Silva  (blog/twitter) por me ajudar. Algumas linhas de powershell são suficientes para isso 🙂

Agora que o background está pronto, o TDE pode ser habilitado.

A diferença quando se está utilizando AlwaysON Availability Group está na preparação dos ambientes antes de habilitar o TDE. Ou seja, você deve criar chaves e certificados em todas réplicas que pertencem ao AG.

/*
  Following steps must be executed on PRIMARY REPLICA
*/
-- Check if MASTER KEY is created
USE master; 
GO

SELECT * FROM sys.symmetric_keys; 
SELECT * FROM sys.certificates;

/*
  Step 1: On Primary Replica - Creation of the Database MASTER KEY (DMK)
  We can skype this step because we already have it
  Make sure that MASTER KEY Backup is working correctly.
        Review backup routine! This is most important step to do 
*/
-- Create a Master Key IF NOT EXISTS
USE master;
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'use_a_strong_password';
GO

-- Backup the Master Key
BACKUP MASTER KEY
TO FILE = '\\PrimaryReplica\TDE\PrimaryReplica_MasterKeyBackup.key'
ENCRYPTION BY PASSWORD = 'use_a_strong_password';
GO
/*
  Step 2: On Primary Replica - Creation of the CERTIFICATE
  Certificate is named as TDECert and it will use MASTER KEY to en
*/

-- Create Certificate Protected by Master Key
CREATE CERTIFICATE TDECert
WITH
  SUBJECT = 'Transparent Data Encryption Cerficate';
GO

/*
 Backup the Certificate
 Review backup routine. We should back up it to two/three different location
 Pick up a strong password 
*/
BACKUP CERTIFICATE Cert_For_TDE TO FILE = '\\PrimaryReplica\TDE\PrimaryReplica_Cert_For_TDE_Backup.cer'
WITH PRIVATE KEY ( FILE = '\\PrimaryReplica\TDE\PrimaryReplica_Cert_For_TDE_PrivKey.pvk'
                  ,ENCRYPTION BY PASSWORD = 'use_a_strong_password' );

/*
  Step 3: On Primary Replica - Creation of Database Encryption Key (DEK)
*/

USE YourDatabase;
GO
/*
 Create a Database Encryption Key
 Choose between AES_128 and AES_256
 Your are not going to encrytp it yet! 
*/

CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_128 -- AES_256 
ENCRYPTION BY SERVER CERTIFICATE Cert_For_TDE;
/*
  Following stes must be executed on SECONDARY REPLICA
*/

-- Check if MASTER KEY is created
USE master;
GO
SELECT * FROM sys.symmetric_keys;
SELECT * FROM sys.certificates;

-- Create a Master Key IF NOT EXISTS
USE master;
GO
/*	
  Step 4: On Secondary Replica - Creation of the DMK
  Make sure that MASTER KEY Backup is working correctly.
  Review backup routine.  
*/

CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'use_a_strong_password';
-- Backup the Master Key on secondary in order we have this when it turns into Primary and we need not worry when recovery event occurs.
-- Review backup routine! This is most important step to do

BACKUP MASTER KEY
TO FILE = '\\SecondaryReplica\TDE\SecondaryReplica_MasterKeyBackup.key' -- You can use same folder to store keys (I just change it to make things easy)
ENCRYPTION BY PASSWORD = 'use_a_strong_password';
/*
  Step 5: On Secondary Replica - Creation of the Certificate from the Primary Certificate Backup
*/

-- Create Certificate Protected by Master Key 
CREATE CERTIFICATE Cert_For_TDE
FROM FILE = '\\PrimaryReplica\TDE\PrimaryReplica_Cert_For_TDE_Backup.cer'
WITH PRIVATE KEY ( FILE = '\\PrimaryReplica\TDE\PrimaryReplica_Cert_For_TDE_PrivKey.pvk'
                  ,DECRYPTION BY PASSWORD = 'same_strong_password_for_backup' );

-- Backup the Certificate
-- Review backup routine! This is most important step to do
BACKUP CERTIFICATE Cert_For_TDE TO FILE = '\\SecondaryReplica\TDE\SecondaryReplica_Cert_For_TDE_Backup.cer' 
WITH PRIVATE KEY ( FILE = '\\SecondaryReplica\TDE\SecondaryReplica_Cert_For_TDE_PrivKey.pvk' 
                  ,ENCRYPTION BY PASSWORD = 'use_a_strong_password' );
/*
  Step 6: On Primary Replica – Enabling TDE Encryption
  Following stes must be executed on PRIMARY REPLICA
*/

-- Now you are going to encrypt it
ALTER DATABASE YourDatabase SET ENCRYPTION ON;
GO
/*
  Step 7: On the Primary Replica and Secondary Replicas – Monitoring Encryption
  This code must be run in SQLCMD mode
*/

:CONNECT PrimaryReplica
SELECT
  @@SERVERNAME
 ,db.name
 ,db.is_encrypted
 ,dm.encryption_state
 ,dm.percent_complete
 ,dm.key_algorithm
 ,dm.key_length
FROM master.sys.databases                                db
  LEFT OUTER JOIN master.sys.dm_database_encryption_keys dm
    ON db.database_id = dm.database_id;
GO

:CONNECT SecondaryReplica
SELECT
  @@SERVERNAME
 ,db.name
 ,db.is_encrypted
 ,dm.encryption_state
 ,dm.percent_complete
 ,dm.key_algorithm
 ,dm.key_length
FROM master.sys.databases                                db
  LEFT OUTER JOIN master.sys.dm_database_encryption_keys dm
    ON db.database_id = dm.database_id;
GO

Uma vez que você efetive o recurso ele será executado silenciosamente em segundo plano, criptografando o banco de dados enquanto as atividades continuam. Enquanto a criptografia inicial está em execução, podemos verificar a coluna percent_complete na sys.dm_database_encryption_keys para ver progresso (veja o step 7).

http://www.sqlservercentral.com/articles/always+on/135432/

Esse processo seria simples, se não fosse pelo grande volume de transações que eu tenho. Um sistema de telemetria que a todo instante está recebendo e enviando informações de veículos no mundo.

O CPU foi a quase 100% e gerou um performance ruim para o sistema. O que quero dizer é que processos que executavam em 500 milissegundos passaram a executar em 1200/1500 milissegundos.

Se você procurar na documentação só exista a opção de ON e OFF para ENCRYPTION. Uma vez que eu iniciei o processo para criptografar o database eu tenho que esperar terminar. E agora? Quanto tempo isso vai demorar para finalizar no meu database?

Existe uma trace flag documentada (Thanks God Microsft) que pausa o processo e simplesmente não faz rollback! Fantástico pois não perco o que foi criptografado e meu database fica com o status de “encryption in progress”. Ou seja, as páginas que foram criptografadas continuam assim e o as páginas que não foram criptografadas serão lidas normalmente.

https://blogs.msdn.microsoft.com/markweberblog/2017/04/04/transparent-data-encryption-tde-traceflag-5004-and-interrupting-encryption-scanning/

Como qualquer outra TF basta você ativar ou desativar. Para parar o processo ative a TF:

DBCC TRACEON(5004) 
GO

Para reiniciar o processo de onde parou basta desativar a TF e executar o comando novamente para criptografar o database.

DBCC TRACEOFF(5004) 
GO 

ALTER DATABASE YourDatabase SET ENCRYPTION ON;
GO

Isso salvou minha vida, pois eu pude habilitar o processo em horários de menor utilização e mesmo assim se impactasse o sistema eu seria capaz de parar.

Backup Compression

Um fator que notamos depois de habilitar o TDE foi a compressão de backups não estava funcionando corretamente, ou seja, simplesmente ignorava a opção e gerava um backup gigantesco.

Pesquisando um pouco achei uma excelente explicação para esse comportamento.

https://blogs.msdn.microsoft.com/sql_server_team/backup-compression-for-tde-enabled-databases-important-fixes-in-sql-2016-sp1-cu4-and-sql-2016-rtm-cu7/

Depois de entender melhor esse comportamento, foi a hora de verificar o que estava ocorrendo. Para isso utilizei um extended event (backup_restore_progress_trace) que facilita e muito a interpretar o que está acontencendo no momento do backup.

O Edvaldo Castro (blog/twitter) explica muito bem esse novo XE.

https://edvaldocastro.com/benchmarking-teste-do-novo-extended-event/

Você deve querer ver uma mensagem de MaxTransferSize maior de 64 KB:

https://blogs.msdn.microsoft.com/sql_server_team/new-extended-event-to-track-backup-and-restore-progress/#.VgtLzHpVhBd

Nesse momento fizemos duas ações:

1 – Atualizamos para o service pack e cumulative update mais recente visto que estávamos com a versão inferior descrita no link (https://blogs.msdn.microsoft.com/sql_server_team/backup-compression-for-tde-enabled-databases-important-fixes-in-sql-2016-sp1-cu4-and-sql-2016-rtm-cu7/)

2 – Mudamos nossa rotina de backup para se adequar as necessidades.

E o tempdb?

A partir do primeiro database utilizando TDE o tempdb passa ser criptografado automaticamente. Um curioso caso sobre o tempdb foi desvendado pelo Bob Ward, recomendo a leitura!

https://blogs.msdn.microsoft.com/bobsql/2017/01/26/sql-server-mysteries-the-case-of-tde-and-permanent-tempdb-encryption/

Eu tenho FileStream, vai criptografar?

A documentação é clara, dados em FileStream não são criptografados. Nossa solução foi utilizar BitLocker

https://docs.microsoft.com/en-us/windows/security/information-protection/bitlocker/bitlocker-how-to-deploy-on-windows-server

Como ficou a CPU?

Nossos testes mostraram um leve aumento de CPU mas nada que comprometeu  a performance. Monitoramos alguns processos críticos e vimos que o aumento foi em média de 3-5% de CPU e tempo total de duração aumentou 100-150 milissegundos.

Transaction-Log? Hummmm

Eu não vi nenhum tipo de problema com isso. Espero que continue assim 🙂

Alguns recursos que não utilizamos e ainda não testei como Buffer Pool Extention – a documentação diz que não é criptogrado e assim como FileStream uma opção seria usar BitLocker. Quero verificar o quanto isso pode afetar a área de memória ou não.

Certificado expirado

O processo de substituir com segurança o certificado é chamado rotating the encryption key. É importante fazer isso, e o SQL Server torna isso um processo simples e rápido. A substituição dos seus certificados expirados é um processo rápido e simples, e é uma parte importante da manutenção da segurança da sua criptografia

Você também pode usar ou restaurar um certificado expirado no servidor.

https://blogs.msdn.microsoft.com/sqlsecurity/2010/06/14/database-encryption-key-dek-management/

Rotação de chaves

Rotation the encryption key é o processo de passar do certificado antigo para o novo. Nesse caso, tudo o que acontece é que a chave de criptografia do banco de dados é descriptografado com o certificado antigo e criptografado novamente com o novo certificado. Esse novo valor criptografado é armazenado no banco de dados sobrescrevendo o antigo. Por ser um processo rápido, a rotação frequente não é um problema.

Novo certificado

O primeiro passo é criar um novo certificado que será usado para criptografar o banco de dados. Você pode seguir os mesmos passos acima.

Rotação do certificado

Para substituir o certificado usado para TDE, adicione o novo certificado como acima, então execute o comando

USE YourDatabase
GO

ALTER DATABASE ENCRYPTION KEY
ENCRYPTION BY SERVER CERTIFICATE TDECert_Rotate_Key;
GO

Faça backup do novo certificado e do database.

Remover TDE

Para remover o TDE é necessário executar o comando abaixo.

ALTER DATABASE yourdatabase SET ENCRYPTION OFF;
GO

Aguarde até que o processo de descriptografia esteja concluído. Use o sys.dm_database_encryption_keys DMV para determinar seu status

USE YourDatabase
GO

DROP DATABASE ENCRYPTION KEY
GO

Faça backup do novo certificado e do database.

Para finalizar, aprenda que o TDE não é apenas um recurso que liga e desliga para entrar em conformidade com órgãos regulamentadores. Você deve se preparar e entender melhor esse recurso antes de utiliza-lo em seu ambiente de producao. Este foi um dos recursos que eu mais gostei de implementar pois me aprofundei em um assunto que eu mesmo tinha deixado de lado.

Fica uma pergunta! Quando falamos de data-in-rest o TDE é suficiente para deixar meus dados seguros ou precisamos fazer um backup com criptografia? Em um próximo post falarei como utilizar backup encryption

https://blogs.msdn.microsoft.com/sqlsecurity/2010/06/14/database-encryption-key-dek-management/

https://blogs.msdn.microsoft.com/sqlsecurity/2016/10/05/feature-spotlight-transparent-data-encryption-tde/

Categorias
Monitoramento SQL Server Troubleshooting Virtual PASS BR

Monitorar Index Online com extended events

[bing_translator]

Recentemente eu precisei realizar uma movimentação de dados fisicamente, ou seja, retirar dados do arquivo1 e passar esses dados para o arquivo2.

A estratégia adotada foi a recriação do índice clustered em um novo filegroup;

CREATE CLUSTERED INDEX [IX_01] ON [dbo].[TEST]
(
   [ID] ASC
)
WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF,
      DROP_EXISTING = ON, ONLINE = ON, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)
ON [NovoFileGroup](ID)
GO

Esse procedimento é bem simples e já tinha executado muitas vezes. Porem dessa vez tinha algumas variáveis que levei em consideração no meu ambiente de teste:

Primeira: quantidade de registros envolvidos nessa tabela, aproximadamente 2 bilhões.

Segunda: Essa mesma tabela possuía 3 índices non-clustered no qual no ambiente de teste eu pude apagar antes de recriar o meu índice non-clustered.

Realizei todos os meus testes e obtive um tempo de 5 horas para execução do comando. A minha janela de manutenção era de 8 horas. A criação dos outros dois índices non-clustered levaram em torno de 3h e meia conversei com a equipe de negócio e eles não viram problema em invadir por um pouco tempo, ou seja, eu estava tudo certo para executar a minha manutenção.

Antes de iniciar a manutenção em produção, eu decidi não apagar os índices non-clustered (meu erro fatal).
Iniciei a manutenção sem nenhuma preocupação e fiquei acompanhando através de algumas DMV (sys.dm_exec_requests, sys.dm_os_tasks, sys.dm_os_waiting_tasks entre outras) a execução do comando, porém não sei se existe, eu desconheço, uma forma de saber exatamente quanto tempo falta para o comando de CREATE INDEX terminar. No meu acompanhamento eu podia ver o que estava em execução porem muito lento!

Após 10 horas a criação do índice não havia terminado e a operação do dia-a-dia já havia iniciado e nesse momento a preocupação era em não impactar o negócio com possíveis bloqueios que poderiam gerar lentidão no sistema.

Nesse momento os ânimos estavam exaltados na área de negócio e na minha gerencia uma vez que a manutenção não terminou, porem eu estava “super” tranquilo porque não haveria impacto simplesmente pelo fato de eu ter tomado o cuidado e ter utilizado a clausura ONLINE = ON.

Como estávamos usando a versão Enterprise do SQL Server 2012 essa opção é uma das principais funcionalidades que tenho utilizado quando faço manutenção em índices.

A partir desse momento a área de negócio percebeu que eles não estavam sendo afetados pela minha manutenção e que o sistema estava sendo operado normalmente (Essa criação de índice era uma das principais tabelas do sistema)

Com os ânimos mais calmos agora vinham as perguntas: Quando irá terminar? Quanto tempo falta? O que realmente está fazendo? Está travado? Posso realizar rollback? Quanto tempo para o rollback terminar? E muitas outras perguntas referentes ao processo.

Para me auxiliar em relação a algumas dessas perguntas abri um caso na Microsoft e algumas das respostas eu já tinha:

P: Quando irá terminar?

R: Não tem como estimar

P: O que realmente está fazendo?

R: Está em execução realizando a criação do índice lentamente.

P: Posso realizar rollback? Quanto tempo para o rollback terminar?

R: Pode, como está sendo realizado a criação com a clausura ONLINE = ON e DROP_EXISTING = ON o rollback é para ser rápido, mas não é possível precisar o tempo

Basead0s nessas respostas e que não havia impacto para o negócio decidimos deixar a execução rodando e monitorar o que estava fazendo. Mas agora a pergunta era como monitorar!!??

Resolvi tentar achar algum evento via XE (extended events) e existe um REPORT com informações que realmente são valiosas para monitorar o processo.

O que a opção ONLINE = ON faz exatamente? Aqui você entra nos detalhes e sabe o que está acontecendo.

https://msdn.microsoft.com/en-us/library/ms191261(v=sql.110).aspx

Através desse evento podemos monitorar todas as fases que o índice passa:

  • Fase 1: Preparation

  • Fase 2:  Build

  • Fase 3:  Final

Após saber como monitorar passamos a tentar estimar um tempo de finalização, o qual demorou 38 horas. Esse tempo todo  é completamente justificado pelo comportamento da opção ONLINE.

Usar XE é sempre uma boa opção…

Categorias
SQL Server Troubleshooting Virtual PASS BR

Unable to cycle error log file

[bing_translator]

Recentemente, comecei a receber o seguinte erro:

Unable to cycle error log file from “C:\MSSQL10_50.InstanceA\MSSQL\Log\ERRORLOG” to “C:\MSSQL10_50.InstanceA\MSSQL\Log\ERRORLOG.1” due to OS error “32(failed to retrieve text for this error. Reason: 15105)”. A process outside of SQL Server may be preventing SQL Server from reading the files. As a result, errorlog entries may be lost and it may not be possible to view some SQL Server errorlogs. Make sure no other processes have locked the file with write-only access.” [SQLSTATE 42000] (Error 17049)  DBCC execution completed. If DBCC printed error messages, contact your system administrator. [SQLSTATE 01000] (Error 2528).  The step failed.

Eu tenho JOB que é executado periodicamente que faz a chamada para a procedure sp_cycle_errorlog e o mesmo erro acontece quando executo manualmente a procedure.

O error 32 do SO tem a seguinte descrição: “Operating system error 32(The process cannot access the file because it is being used by another process.)”

Primeira tentativa foi identificar quem poderia estar usando esse arquivo de dentro do SQL Server com o seguinte comando:

SELECT
    *
FROM
    sys.dm_exec_requests a
OUTER APPLY sys.dm_exec_sql_text(a.sql_handle) b
WHERE
    session_id > 50 AND session_id <> @@SPID AND (
    text = 'xp_readerrorlog' OR text = 'sp_cycle_errorlog'
    )
ORDER BY
    start_time;

Infelizmente esse comando não retornou nenhum registro.
Para tentar descobrir qual era o processo fora do SQL Server que estava com o usando o arquivo eu utilizei o Process Explorer. Ele permitiu que eu descobrisse que alem do processo SQLSERVR.EXE e  FDLAUCHER.EXE existia outros 2 processos de SISTEMA obtendo o handle do arquivo do Errorlog do SQL Server.

UnableCycleError02

Uma vez quer consegui identificar esses outros processo a pergunta era: Porque o S.O. estaria fazendo isso? Ou melhor qual thread do S.O estaria usando esses arquivos?

A partir desse momento eu envolvi o time de suporte da Microsoft.

Utilizamos o Process Monitor para capturar o que exatamente estava ocorrendo.UnableCycleError01

Foi identificado que o handle estava vindo via SMB.

https://msdn.microsoft.com/en-us/library/ee681828(VS.85).aspx

FSCTL_REQUEST_OPLOCK control code
Requests an opportunistic lock (oplock) on a file and acknowledges that an oplock break has occurred.
To perform this operation, call the DeviceIoControl function using the following parameters.

A partir de agora eu precisa descobrir da onde vinha a requisição SMB que estava fazendo gerar o erro e para isso utilizei dois comando PowerShell:

Get-SmbOpenFile | Where-Object -Property Path -Match "ERRORLOG" 

Get-SmbOpenFile | Where-Object -Property Path -Match "MSSQL\Log"

O segundo comando nao teve nenhum resultado mas o primeiro comando me retornou algo que ajudou a resolver o meu problema. 
UnableCycleError03

Pude constatar que a existia uma maquina da ferramenta de monitoramento que estava acessando o arquivo via SMB e fazendo lock no handle. A partir desse momento eu ja tinha insumos suficientes para entrar em contato com o fornecedor e solicitar a correção do meu problema.

Esse problema ocorreu apenas em apenas um ambiente (Windows Server 2012 R2 e SQL Server 2008 R2) onde era um bug da ferramenta de monitoramento, uma vez que atualizei a ferramenta para a versão mais recente esse comportamento parou de acontecer e meu problema não voltou a ocorrer.

Gostaria de agradecer ao Danilo e Daniel pela ajuda.

 

Categorias
SQL Server Troubleshooting Virtual PASS BR

SQL SERVER MANAGEMENT STUDIO – Crashes quando inicia

[bing_translator]

Recentemente eu troquei meu notebook e comecei aquela velha rotina de instalar todos os softwares que utilizamos no dia. A expectativa era grande pois a máquina tem um hardware melhor. Assim que recebi o equipamento o primeiro software que instalei foi o SQL Server Management Studio 2014, a ferramenta que mais utilizo no dia a dia.  Após fazer a instalação (https://tiagobalabuch.com/erro-ao-instalar-sql-server-management-studio-setup-account-privileges/) com sucesso tive uma surpresa ao tentar abrir o programa, simplesmente não abria e gerava a mensagem dizendo que parou de funcionar!

ErroSSMS-01
Imagem 1

Analisando o event viewer consegui encontrar as seguintes mensagens:

ErroSSMS-02
Imagem 2

ErroSSMS-03

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Imagem 3

Pesquisando um pouco cheguei a dois

https://connect.microsoft.com/SQLServer/feedback/details/774317/sql-server-management-studio-2012-crashes-when-closing
https://connect.microsoft.com/SQLServer/feedback/details/770754/sql-server-2012-management-studio-crashes

Não ajudou muito meu problema, porém eu atualizei para o último Cumulative Update para ver se o problema seria resolvido e não tive sucesso.
Iniciamos uma investigação pensando que poderia ser algum problema com a versão do .NET Framework e nesse momento uma equipe que utiliza o Visual Studio reportou o mesmo problema ao tentar abrir o programa, mais um indicio que poderia ser algum problema com .NET Framework.
Desabilitei o .NET Framework 4.5, que vem por padrão habilitado no Windows 8.1, para verificar se poderia ser algum problema mas não tive sucesso.
Reinstalei o .NET Framework 3.5 sem sucesso novamente.

Um amigo, Rafael Machado, criou um script para apagar alguns registros e caches de informações do Windows para resolver o problema e funcionou em uma máquina que ele testou.

del /F /Q “%userprofile%\appdata\local\Microsoft\SQL Server Management Studio\*.*”

del /F /Q “%userprofile%\AppData\Local\Microsoft_Corporation\LandingPage.exe_StrongName_ryspccglaxmt4nhllj5z3thycltsvyyx\*.*”

del /F /Q “%userprofile%\appdata\local\Microsoft_Corporation\*.*”

 del /F /Q “%userprofile%\appdata\locallow\Microsoft\SQL Server Management Studio\*.*”

del /F /Q “%userprofile%\appdata\locallow\Microsoft\Visual Studio\*.*”

del /F /Q “%userprofile%\appdata\locallow\Microsoft_Corporation\*.*”

 del /F /Q “%userprofile%\appdata\roaming\Microsoft\SQL Server Management Studio\*.*”

del /F /Q “%userprofile%\appdata\roaming\Microsoft\Visual Studio\*.*”

del /F /Q “%userprofile%\appdata\roaming\Microsoft_Corporation\*.*”

 reg delete “HKEY_CURRENT_USER\Software\Microsoft\VisualStudio” /f

reg delete “HKEY_CURRENT_USER\Software\Microsoft\SQL Server Management Studio” /f

Porem para mim não funcionou e continuei investigando o problema.

Conversando com alguns amigos tive algumas dicas de como tentar identificar ou solucionar o meu problema.

O Edvaldo Castro (blog | twitter) comentou sobre um problema que ele reportou com o .NET Framework (http://edvaldocastro.com/error-netfx3/) e muito provavelmente eu poderia estar passando, porem após realizar os procedimentos indicados de remover os KB2966828 e KB2966827 e habilitar o  .NET Framework 3.5 novamente o meu problema persistia.

O Alex Rosa (blog) deu a dica de usar o log do SSMS para verificar o que estava acontecendo.
Esse procedimento é realizado incluindo a opção [-log filename] no executável do SSMS:
“C:\Program Files (x86)\Microsoft SQL Server\120\Tools\Binn\ManagementStudio\Ssms.exe” -log “C:\SSMS_log.txt”

ErroSSMS-04ErroSSMS-05
Imagem 4

Analisando encontrei algumas mensagens suspeitas:

<entry>

    <record>1077</record>

    <time>2014/11/27 12:46:58.516</time>

    <type>Error</type>

    <source>Microsoft.VisualStudio.CommonIDE.ExtensibilityHosting.VsShellComponentModelHost</source>

    <description>Could not load file or assembly &apos;Microsoft.Data.Entity.Design.DataSourceWizardExtension.dll&apos; or one of its dependencies. O sistema n&#x00E3;o pode encontrar o arquivo especificado.</description>

    <path>C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\CommonExtensions\DataDesign\Microsoft.Data.Entity.Design.DataSourceWizardExtension.dll</path>

  </entry>

 O Zavaschi (blog|twitter) me ajudou a analisar o log e encontrou mais algumas mensagens que poderia estar gerando o problema:

<entry>

    <record>366</record>

    <time>2014/11/28 10:27:58.575</time>

    <type>Warning</type>

    <source>VisualStudio</source>

    <description>PkgDef encountered data collision in section &apos;HKEY_CURRENT_USER\Software\Microsoft\SQL Server Management Studio\12.0_Config\OutputWindow\{FC076020-078A-11D1-A7DF-00A0C9110051}&apos; for value &apos;Name&apos;</description>

  </entry>

  <entry>

    <record>367</record>

    <time>2014/11/28 10:27:58.575</time>

    <type>Warning</type>

    <source>VisualStudio</source>

    <description>PkgDef encountered data collision in section &apos;HKEY_CURRENT_USER\Software\Microsoft\SQL Server Management Studio\12.0_Config\OutputWindow\{FC076020-078A-11D1-A7DF-00A0C9110051}&apos; for value &apos;Package&apos;</description>

</entry>

 <entry>

    <record>618</record>

    <time>2014/11/28 10:27:59.024</time>

    <type>Information</type>

    <source>VisualStudio</source>

    <description>PkgUnDef: Deleted key</description>

    <path>Software\Microsoft\SQL Server Management Studio\12.0_Config\Services\{5C164B27-EEC2-4b9f-B3D6-60C2EFF8C800}</path>

  </entry>

 <entry>

    <record>620</record>

    <time>2014/11/28 10:27:59.026</time>

    <type>Warning</type>

    <source>VisualStudio</source>

    <description>PkgUnDef: Did not find key to open. Skipping</description>

    <path>Software\Microsoft\SQL Server Management Studio\12.0_Config\Services\{8EEF7DE4-FC78-421A-892E-52956C035F5C}</path>

  </entry>

Agora eu precisava saber o que o processo realmente estava fazendo e comecei a utilizar o PROCMON (systernals http://technet.microsoft.com/en-us/sysinternals/bb545021.aspx) e o João Polisel me deu algumas dicas do que procurar para tentar identificar o problema.

Infelizmente, na minha opinião, eu não precisei analisar o PROCMON pois a equipe responsável pela homologação do notebook e do S.O. identificou o problema e solução.

Eles chegaram a esse link (https://social.msdn.microsoft.com/Forums/vstudio/en-US/8b3b39a8-eee6-4d43-b7e6-d9a38be2ee90/installation-of-vs-2012-rtm-invisible-dialog-box?forum=vssetup) onde uma das soluções propostas era atualizar o driver de vídeo. Nesse momento fiquei sabendo que problemas com vídeo conferencia estão ocorrendo e que deveríamos atualizar o drive de vídeo.

Pronto, após a atualização desse driver o problema se foi! Eu não sei explicar o motivo disso, mas atualizar o driver de vídeo era uma coisa que jamais imaginaria que resolveria meu problema. Obrigado a todos que ajudaram!!!

Nem sempre a solução é a que esperamos.

 

Categorias
SQL Server Troubleshooting Virtual PASS BR

SSIS – Proxy Account Permission

[bing_translator]

A utilização de Proxy Account para execução de pacotes SSIS dentro do SQL Server Agent é um procedimento para utilização de usuários que não são SYSADMIN executarem pacotes com outras credencias que não é a da conta de serviço do SQL Server Agent.

Existem varias referencias de como criar e utilizar Proxy Account porem eu passei por um problema com a utilização desse cenário.

Cenario:

Um pacote SSIS , que está armazenado em file system, com uma funcionalidade que deve ler um arquivo EXCEL em uma pasta compartilhada na rede e carregar os dados para outro lugar usando um login Windows.

A pasta compartilhada está em um domínio (Domínio A) e a servidor de Integration Services está em outro domínio (Domínio B)

Problema:

Tudo parecia perfeito, credencial criada, proxy account criada e associada corretamente , job criado correto porem na hora de executar o job o seguinte erro era apresentado:

Error:

Code: 0xC0202009

Source:  Excel Source [705]

Description: SSIS Error Code DTS_E_OLEDBERROR.  An OLE DB error has occurred. Error code: 0x80004005.

End Error

Error:

Code: 0xC02020E8

Source: Excel Source [705]

Description: Opening a rowset for “Plan1$” failed. Check that the object exists in the database.

End Error

Error:

Code: 0xC004706B

Source:  SSIS.Pipeline

Description: “component “Excel Source” (705)” failed validation and returned validation status “VS_ISBROKEN”.

End Error

A primeira tentativa de solucionar foi validar a mensagem de erro que dizia que ao abrir a “Plan1$” a operação falhou! Abri o pacote, verifiquei todas a conexões, tentei alterar algumas configurações do pacote e nada adiantou, tudo correto!

Solução:

Depois de um tempo pude perceber que o primeiro erro não estava na falha ao tentar abrir o arquivo “Plan1$” e isso era consequência.

Comecei a analisar a primeira mensagem: Description: SSIS Error Code DTS_E_OLEDBERROR.  An OLE DB error has occurred. Error code: 0x80004005.

Após pesquisar um pouco na internet achei o seguinte artigo:

http://blogs.msdn.com/b/dataaccesstechnologies/archive/2009/11/10/ssis-error-code-dts-e-oledberror-an-ole-db-error-has-occurred-reasons-and-troubleshooting.aspx

Quando cheguei ao item C apareceu um luz no fim do túnel para mim. Porem agora o problema era saber qual pasta dar permissão.

Nesse momento fui validar as variáveis de ambiente para tentar descobrir onde ficaria a pasta TEMP que o artigo dizia que deve ter permissão.

SSIS-ProxyAccountPermission - 01

 

 

 

 

 

 

Imagem 01

Agora sim!!! Tinha todas as informações e concedido acesso de leitura e escrita para o usuário do proxy account nessa pasta especifica. Hora de testar o JOB e adivinhem: mesmo erro novamente! Sinceramente não sabia o motivo do erro, pois uma vez que dei permissão na pasta e tudo o que o artigo falava estava correto, não sabia o motivo de não funcionar .

Sem saber o que fazer, surgiu a ideia de usar o Process Monitor (sysinternal) para tentar validar o que estava acontecendo no Windows. Depois de algum tempo analisando o processo e o erro consegui achar a seguinte informação:

SSIS-ProxyAccountPermission - 02

 

Acesso negado em um pasta!!! Mais uma vez uma luz apareceu porem sem saber o motivo do processo usar o usuário “Default” e a pasta “Temporary Internet Files”.

Enfim, para resolver o problema concedi permissão de escrita e leitura dentro da pasta “C:\User\Default\AppData\Local” para o usuário do Proxy Account e executei novamente o JOB que dessa vez terminou com sucesso!!!

Não sou especialista em SSIS para entender o funcionamento interno, porem somente com uso da ferramenta Process Monitor foi possível verificar o que realmente o processo fazia e onde ele precisava de permissão.

Referencias:

http://www.mssqltips.com/sqlservertip/2163/running-a-ssis-package-from-sql-server-agent-using-a-proxy-account/

http://blogs.msdn.com/b/dataaccesstechnologies/archive/2009/11/10/ssis-error-code-dts-e-oledberror-an-ole-db-error-has-occurred-reasons-and-troubleshooting.aspx

http://technet.microsoft.com/en-us/sqlserver/ff686764.aspx

Categorias
SQL Server Troubleshooting Virtual PASS BR

Erro ao instalar SQL Server Management Studio – Setup account Privileges

O SQL Server Management Studio (SSMS) é uma das principais ferramentas de um DBA SQL Server e sem ela, na minha opniao, é praticamente impossível de trabalhar, a não ser que você goste de utilizar a famosa linha de comando para tudo (SQLCMD ou SQLPS), mas esse não é meu caso. Eu estava instalando o SSMS em meu novo notebook da empresa e me deparei com o seguinte erro:

SetupAccountPrivileges-01

Figura 01

Visualizando o relatório com detalhes, tenho a mensagem:

SetupAccountPrivileges-02

Figura 02

Verificando o erro encontrei um KB relacionado ao mesmo: http://support.microsoft.com/kb/2000257

Simples e fácil de resolver. O que falta é permissão nos seguintes objetos:

Local Policy Object Display Name   User Right
Backup files and directories SeBackupPrivilege
Debug Programs SeDebugPrivilege
Manage auditing and security log SeSecurityPrivilege

Para listar as permissões, você pode utilizar o seguinte comamdo a partir de um Prompt ou PowerShell:

whoami /priv

Fácil seria se uma politica de GPO permitisse adicionar permissões nesses objetos. No meu caso o que estava faltando era permissão no “Debug Programs”.  Conversando com a equipe que definiu as GPO chegamos ao veredito que não seria mudado a GPO por varias questões de seguranças.

Corrigir essas permissões é a melhor maneira de solucionar o problema.

E agora, eu apenas queria instalar o SSMS na minha estação de trabalho! Nem tudo está perdido. Uma outra pessoal da minha equipe descobriu que é possível contornar essa verificação através da linha de comando:

Setup /Action=Install /SkipRules=HasSecurityBackupAndDebugPrivilegesCheck

Obrigado Rene pelo comando!!!

Dessa maneira foi possível instalar o SSMS no meu notebook.

Categorias
Monitoramento SQL Server Troubleshooting Virtual PASS BR

Suspect database – MSDTC in-doubt transaction

Em uma bela madrugada, onde todas as coisas obscuras aparecem, um dos servidores de um cluster falhou e executou um failover para um outro nó. Até esse momento nada de estranho e esse é o comportamento esperado.

Problema

Ao verificar os bancos de dados da instancia que sofreu o failover me deparei com o status de “suspect” em um deles. Nesse ponto começou a investigação de como isso aconteceu e como resolver!

Consegui encontrar no errorlog as seguintes mensagens:

Attempting to initialize Microsoft Distributed Transaction Coordinator (MS DTC). This is an informational message only. No user action is required.

QueryInterface failed for “DTC_GET_TRANSACTION_MANAGER_EX::ITransactionDispenser”: 0x80004005(failed to retrieve text for this error. Reason: 15105).

QueryInterface failed for “ITransactionDispenser”: 0x80004005(failed to retrieve text for this error. Reason: 15105).

Attempting to initialize Microsoft Distributed Transaction Coordinator (MS DTC). This is an informational message only. No user action is required.

SQL Server detected a DTC/KTM in-doubt transaction with UOW  {07372A47-24B9-4BC3-A651-0260624FFF8E}. Please resolve it following the guideline for Troubleshooting DTC Transactions.

An error occurred while recovering database ‘XXX’. Unable to connect to Microsoft Distributed Transaction Coordinator (MS DTC) to check the completion status of transaction (0:-222014414). Fix MS DTC, and run recovery again.

An error occurred during recovery, preventing the database ‘XXX’ (database ID 5) from restarting. Diagnose the recovery errors and fix them, or restore from a known good backup. If errors are not corrected or expected, contact Technical Support.

A aplicação que utilizava essa database também utilizava Microsoft Distributed Transaction Coordinator (MSDTC) e tudo indicava que alguma coisa se perdeu no caminho da comunicação entre o MSDTC da aplicação e do banco de dados.

No meu caso eu tinha um agravante: o cluster não possuía uma instância do MSDTC, ou seja, utilizava o MSDTC local.

Quando uma instância do SQL Server 2008 ou superior é inicializada em um cluster, ela tenta encontrar uma instância do MSDTC para comunicação na seguinte ordem:

  • Dentro do grupo do cluster onde reside o recurso do SQL Server
  • Dentro de outros grupos do cluster
  • Instância MSDTC local

Resolução

Eu não sabia o que tinha acontecido com MSDTC e resolvi tomar uma ação para deixar meu banco de dados online e depois tentar resolver qualquer problema.

Utilizei o comando abaixo:

sp_configure ‘show advanced options’, 1
go
reconfigure
go
sp_configure ‘in-doubt xact resolution’, 2
go
reconfigure
go
sp_configure ‘show advanced options’, 0
go
reconfigure
go

E depois trouxe o banco de dados ONLINE.

Podem existir outras formas de resolver esse problema, porem essa ação permitiu que meu banco dados ficasse online e pude executar um DBCC CHECKDB que para meu alivio retornou sem nenhum erro!

Antes de liberar meu banco de dados para produção novamente voltei a configuração padrao

sp_configure ‘in-doubt xact resolution’, 0
go
reconfigure
go

Outra alterativa seria vizualizar a view sys.dm_tran_active_transactions, essa view mostra algumas informações sobre  as transações com uso do MSDTC.

Os campos: transaction_uow, transaction_state, dtc_state são campos que devem ser olhados com cuidado em uma analise pois contem informaçoes importantes.

MDCTS-01

O campo transaction_uow pode ser relacionado com o Unit of Work ID dentro da lista de transações do MSDTC.

MDCTS-02

Assim você pode identificar o status da sua transação e pode tomar a ação necessária que cabe ao seu ambiente.

Conclusão

Quando a instância SQL Server executou um failover para o outro nó do cluster, a instância passou a se comunicar com o MSDTC local do novo nó, que não tinha informações das transações registradas no nó anterior.

Ao tentar iniciar o processo de recovery do banco de dados, o SQL Server encontrou informações sobre transações distribuídas que não haviam sido terminadas (confirmadas ou abortadas) antes da falha. O SQL Server entrou no processo de validar as informações do LOG e questionou o MSDTC a respeito das transações, e o novo MSDTC local não tinha informações a respeito destas transações. Por esse motivo o SQL Server não foi capaz de resolve-las e desta forma interrompeu o processo de recovery ocasionando o estado de “suspect”

A melhor solução para que isso não ocorra é ter uma instancia do MSDTC dentro do cluster.

Referências:

How to configure DTC for SQL Server in a Windows 2008 cluster

Opção de configuração de servidor in-doubt xact resolution

sys.dm_tran_active_transactions

 

Categorias
How To SQL Server Troubleshooting Virtual PASS BR

Aumentar o numero de arquivos do Errorlog e limitar o seu tamanho físico

O log de erro do SQL Server (ERRORLOG) contem muitas informações geradas pelo SQL Server como mensagens, alertas, eventos críticos, auditoria, informações geradas a partir dos usuários entre outras. O log de erro é um ótimo lugar para encontrar informações sobre o que está acontecendo com seu ambiente.

O ErrorLog é inicializado cada vez que a instancia do SQL Server é iniciada ou quando o log de erro é reciclado. Se a instancia não tem sido reiniciada por um longo tempo, o arquivo de log de erro pode crescer consideravelmente dificultando a seu leitura em uma possível analise.

Por padrão, os logs de erro de SQL Server são mantidos na subpasta de Log do SQL Server e há sete logs de erro do SQL Server. Quando o arquivo de log de erros é recriado, o log anterior é renomeado para Errorlog.1 e próximo log anterior (Errorlog.1) é renomeado para Errorlog.2 e assim por diante.

Aumentando o numero de arquivos

Para aumentar o numero de arquivos do ErrorLog do SQL Server, você deve se conectar a uma instancia e clicar com botão direito em SQL Server Log e depois em “Configure”.

Errorlog1

Figura 1

Depois habilite a única check box disponível e aumente o numero de log de erro que pode chegar até 99 arquivos.

Errorlog2

Figura 2

Para saber o caminho fisicamente onde os arquivos de log de erro estão armazenados você pode utilizar esse T-SQL para ajuda-lo.

SELECT SERVERPROPERTY(‘ErrorLogFileName’);

Abaixo o SCRIPT para a alterar a quantidade de ErrorLog :

USE [master]

GO

EXEC xp_instance_regwrite N’HKEY_LOCAL_MACHINE’, N’Software\Microsoft\MSSQLServer\MSSQLServer’, N’NumErrorLogs’, REG_DWORD, 99

GO

Novidade no SQL Server 2012

No SQL server 2012 existe uma nova opção para os arquivos de ErrorLog que é o limite por tamanho!
Podemos a partir de agora limitar o tamanho fisico do arquivo do ErrorLog 🙂
Com o comando abaixo limitamos o tamanho do arquivo em 5MB

USE [master];

GO

EXEC xp_instance_regwrite N’HKEY_LOCAL_MACHINE’,N’Software\Microsoft\MSSQLServer\MSSQLServer’, N’ErrorLogSizeInKb’, REG_DWORD, 5120;

GO

Na minha visão, essa opção é muito util quando temos grandes problema ou incidicio de problema eventos são gravados no errorlog. Com esse limitador de tamanho podemos ter a facilidade de abrir um arquivo de errorlog em um troubleshooting ou ate mesmo controlar o espaço em disco caso seja necessario!

Reciclar o ErrorLog

Para reciclar os arquivos de log de erro do SQL Server devemos executar a seguinte procedure de sistema:

sp_cycle_errorlog

Essa procedure deve ser executada diretamente na database master.

Essa procedure fecha o arquivo de log de erros atual e altera os números de extensão de log de erros, simulando um reinício da instancia.

Assim como log de erro do SQL Server o log de erro do SQL Server Agent é um ótimo lugar para buscar informações sobre o que está acontecendo com o SQL Server Agent. Porém, não é possível aumentar a quantidade de arquivos do log de erro do SQL Server Agent, sendo fixado em um total de 10 arquivos, com 1 arquivo corrente (SQLAGENT.OUT) e 9 arquivos de log (SQLAGENT.1 até SQLAGENT.9)

Da mesma maneira que acontece com o log de error do SQL Server o log de erro do SQL Server Agent é inicializado quando a instancia é iniciada ou quando o log de erro é reciclado.

Para reciclar os arquivos de log de erro do SQL Server Agent devemos executar a seguinte procedure de sistema:

sp_cycle_agent_errorlog

Essa procedure deve ser executada diretamente na database msdb.

Referencia:

Limit the size of the error log