{"id":9187,"date":"2018-07-17T09:17:22","date_gmt":"2018-07-17T12:17:22","guid":{"rendered":"http:\/\/www.fabriciolima.net\/?p=9187"},"modified":"2018-07-17T09:54:29","modified_gmt":"2018-07-17T12:54:29","slug":"azure-sql-database-quanto-posso-usar-de-transaction-log-e-ilimitado","status":"publish","type":"post","link":"https:\/\/fabriciolima.net\/blog\/2018\/07\/17\/azure-sql-database-quanto-posso-usar-de-transaction-log-e-ilimitado\/","title":{"rendered":"Azure SQL Database – Quanto posso usar de Transaction Log? \u00c9 ilimitado?"},"content":{"rendered":"

\"\"<\/p>\n

Fala Pessoal,<\/p>\n

Continuando os posts sobre Azure SQL Database, dessa vez vamos falar sobre um erro de Log Full<\/strong> <\/span>que consegui gerar em uma base no Azure.<\/p>\n

O Transaction Log de uma base no azure funciona da mesma forma que em uma inst\u00e2ncia On-Premise.<\/p>\n

Como no azure n\u00e3o conseguimos utilizar uma base com o recovery SIMPLE, toda base tem o recovery FULL, ou seja, nossas opera\u00e7\u00f5es de INSERT\/UPDATE\/DELETE<\/strong> ficam no transaction log at\u00e9 que o backup do log salve essas informa\u00e7\u00f5es e permita que elas sejam liberadas do log.<\/p>\n

Nada diferente do que temos hoje no On-Premise.<\/p>\n

Um dos problemas que temos hoje \u00e9 estourar o log com REBUILD<\/strong> ou quando algu\u00e9m deixa uma transa\u00e7\u00e3o aberta<\/strong>. Aquele famoso BEGIN TRAN<\/strong> que o desenvolvedor<\/strong> (exemplo meramente ilustrativo) deixou aberto e foi almo\u00e7ar.<\/p>\n

Quando contratamos uma base no Azure, n\u00e3o \u00e9 definido qual o tamanho do transaction log dessa base.<\/p>\n

Por exemplo, nos meus testes eu contratei a base na vers\u00e3o mais barata com 5 DTUs<\/strong> e 2 GB<\/strong> m\u00e1ximo de tamanho de base.<\/p>\n

E tamanho do Transaction log? \u00c9 Ilimitado?<\/strong><\/h6>\n

Para tentar pegar essas respostas fiz um teste com os scripts abaixo:<\/p>\n

--Cria uma tabela de teste\r\nCREATE TABLE [dbo].[Teste_TransactionLog](\r\n\t[Col] [VARCHAR](8000) NULL\r\n) ON [PRIMARY]\r\nGO\r\n\r\n--Popula essa tabela\r\ninsert into Teste_TransactionLog select replicate ( 'b',8000)\r\nGO 100\r\n\r\nINSERT into Teste_TransactionLog\r\nSELECT * FROM dbo.Teste_TransactionLog\r\nGO 4<\/pre>\n
A tabela ficou bem pequena com apenas 1600 linhas e ocupando 12 MB:<\/p>\n
EXEC sp_spaceused Teste_TransactionLog\r\n\r\nname                  rows                 reserved           \r\nTeste_TransactionLog   1600                 12808 KB<\/pre>\n
Mantendo essa tabela com esse tamanho, abri uma transa\u00e7\u00e3o e deixei um loop sendo executado realizando um update. Esse update gera altera\u00e7\u00f5es que s\u00e3o gravadas no transaction log, que passa a crescer:<\/p>\n
SET NOCOUNT ON\r\n\r\n--deixa a transa\u00e7\u00e3o aberta\r\nBEGIN TRAN\r\n\r\n--coloca o update para rodar em loop\r\nwhile 1=1\r\nBEGIN \r\n\t update Teste_TransactionLog set Col = REPLICATE( SUBSTRING('abcdefghijlmnopqrstuvxz',(CAST((RAND()*5465465) AS INT)%20),1),8000)\r\nend\r\nGO<\/pre>\n
Como minha base tem 5 DTU<\/strong>, ela n\u00e3o consegue processar muita coisa. Deixei o update rodando, fui resolver outras coisas e quando voltei, l\u00e1 estava a famosa mensagem de Transaction log is full<\/strong><\/span>:<\/p>\n
\"\"<\/p>\n
Opa…<\/p>\n
Ent\u00e3o quer dizer que o Transaction Log do Azure n\u00e3o \u00e9 Ilimitado?<\/h6>\n
Resposta: N\u00e3o.<\/strong><\/span><\/p>\n
O Transaction Log da minha database que tem um tamanho de 2 GB<\/strong> chegou a aproximadamente 5 GB<\/strong> de tamanho:<\/p>\n
\"\"<\/p>\n
Eu entrei em contato com o Xiaochen Wu<\/a> (Senior Program Manager do time de Azure SQL Database)<\/strong>, mostrei esses testes e perguntei se existia alguma regra ou f\u00f3rmula que determinasse o tamanho m\u00e1ximo<\/strong> de um T-Log no Azure.<\/p>\n
A resposta dele foi a seguinte:<\/p>\n
“N\u00e3o existe nenhuma f\u00f3rmula fixa para determinar o tamanho do Transaction Log. Isso n\u00e3o est\u00e1 documentado porque n\u00f3s mudamos esses valores dinamicamente de forma frequente para alcan\u00e7ar o melhor caso para a maioria dos clientes. O tamanho do log \u00e9 determinado pelo volume computacional e n\u00e3o pelo tamanho da database. Podemos ter uma base bem pequena que gere muito log.<\/em><\/p>\n
N\u00f3s raramente vemos um cliente com problema de Log Full no Azure SQL. Na maioria dos casos o usu\u00e1rio fez um rebuild em uma tabela muito grande ou deixou uma transa\u00e7\u00e3o aberta. Para o REBUILD n\u00f3s liberamos o ONLINE INDEX REBUILD que n\u00e3o vai bloquear a Limpeza do Log. Para o caso da transa\u00e7\u00e3o aberta, ela vai morrer em algum momento, dar rollback e liberar o T-Log.”<\/em><\/p>\n
Perguntei se podia compartilhar isso com voc\u00eas e disse que sim. Fica aqui meu agradecimento ao Xiaochen Wu<\/a> pelo tempo em responder minhas d\u00favidas.<\/p>\n
Resumindo, o transaction log n\u00e3o \u00e9 infinito e n\u00e3o tem uma f\u00f3rmula m\u00e1gica para sabermos at\u00e9 quanto o T-Log da nossa base pode alcan\u00e7ar.<\/strong><\/p>\n
Fica a dica de quando rodar um REBUILD dos \u00edndices no Azure, utilizar a op\u00e7\u00e3o ONLINE (post futuro) e nunca deixar transa\u00e7\u00f5es abertas na base e ir almo\u00e7ar. =)<\/p>\n
O Azure n\u00e3o tem um alerta no portal para monitorar o Transaction Log, mas podemos criar um para salvar essa informa\u00e7\u00e3o em uma tabela e depois via alguma aplica\u00e7\u00e3o ler essa tabela e enviar um e-mail. Entretanto, isso j\u00e1 \u00e9 assunto para outro post futuro.<\/p>\n
Espero que tenham aprendido algo novo.<\/p>\n
At\u00e9 a pr\u00f3xima.<\/p>\n
Posts relacionados sobre o Azure SQL Database:<\/p>\n