Piores Práticas – Utilizar o comando BACKUP LOG com a opção WITH TRUNCATE_ONLY – Parte I

Boa Noite Pessoal,

Nos últimos dias estive um pouco ausente dos fóruns e de diversas comunidades que participo, pois estou ministrando um curso oficial de SQL Server 2008. Ontem durante a aula apresentei a parte de backups e após as explicações, participei para os alunos uma situação muito comum que indiretamente está relacionada com backups. Hoje nos fóruns MSDN e Technet também presenciei a mesma situação acontecendo novamente intitulando-se "Log Gigantesco".

Acredito que depois da dificuldade de conectar-se remotamente ao SQL Server (se alguém estiver com essa dificuldade leia esse excelente artigo "Como configurar Conexão Remota no SQL Server 2005") , problemas com o log de transação que cresce assustadoramente representam provavelmente a dúvida mais comum de SQL Server que exista. De fato já vi inúmeras dúvidas relacionadas ao log do SQL Server que cresce, cresce, cresce e deixa alguns desenvolvedores, dbas iniciantes e profissionais preocupados e aparentemente sem ter o que fazer. Na maioria das vezes a solução é uma só conforme descrito abaixo (o texto foi adaptado para preservar a identidade de seus participantes):

"Oi Gente,

Estou com um banco de dados com um arquivo de LOG com mais de 40Gb e preciso de espaço.
O HD só tem mais 2GB e LOG continua crescendo. O que devo fazer ?"

"Oi Fulano,

Cara é muito simples. Basta só rodar esses dois comandos:

Backup Log NomeDoSeuBanco WITH TRUNCATE_ONLY
GO
DBCC SHRINKFILE(NomeLogicoArquivoLog, 10)
GO

Se você não souber o nome do arquivo lógico roda a sp_helpdb ‘SeuBanco’. É importante rodar os dois comandos conectado no seu banco."

De fato essa é a solução padrão e realmente funciona. Na maioria das situações, aqueles que aplicaram essa solução certamente viram seus arquivos de Log diminuir tão assustadoramente quanto cresceram. Com uma solução tão "eficiente" a receita de bolo é escrita. Toda vez que o LOG atingir tamanhos absurdos, basta então rodar o BACKUP LOG com o TRUNCATE_ONLY e logo em seguida rodar o SHRINK FILE. A eficiência desse comando parece ser tanta que não me estranha que ele seja contemplado em jobs, planos de manutenção e nem que seja encapsulado em uma stored procedure.

Inquestionavalmente arquivos de Log gigantescos são um incômodo. Não só pelo fato de ameaçaram acabar com todo o espaço livre disponível na unidade, mas também porque se um backup possui um arquivo de LOG gigantesco, será necessário reservar um espaço gigantesco em outro ambiente no momento da restauração. E como normalmente os ambientes de homologação e desenvolvimento tem menos recursos, arquivos muito grandes podem ser verdadeiros inconvenientes. Após ver tantas dezenas de threads com problemas de arquivos de log que crescem além da conta fico com duas preocupações: Será que aqueles que simplesmente executam esses comandos tem a menor noção do problema que eles podem provocar ? E será que aqueles que repassam esses comandos sabem exatamente o tamanho do risco que podem estar introduzindo em outros ambientes ?

"Afinal o que há de mal em executar esses dois comandos ? Eles sempre irão reduzir o log de transações e "resolver o problema" e essa é a solução que está escrita na maioria dos tutoriais, fóruns, etc. Se o arquivo de log não for limpo aí sim é que os problemas aparecem." Não posso deixar de concordar com a afirmação, mas vejamos algo um pouco mais apurado antes de tirar as conclusões sobre algo praticamente inquestionável.

Um pouco sobre o Log de transações

Todo banco de dados possui uma estrutura de log que registra tudo o que aconteceu que represente escrita nesse banco de dados. Essa estrutura é imprescindível para que o banco de dados saiba o que aconteceu na eventualidade de uma queda de energia entre outros problemas e mantenha-se consistente. De tempos em tempos (mais precisamente a cada Checkpoint), as transações registradas no Log de transações são efetivamente aplicadas no banco de dados mantendo sua consistência. As entradas no Log possuem um sequencial chamado LSN que é o acrônimo de Log Sequence Number. À medida que o Log recebe novas instruções, novos LSNs são adicionados. A tabela abaixo mostra um hipotético exemplo de um Log de transações.

LSN Instrução
001 INSERT INTO Clientes VALUES (1,‘Alberto’,2560.92,‘M’)
002 DELETE FROM AjusteEstoque WHERE IDAjuste = 3097
003 CREATE TABLE Defeitos (IDDef INT, IDProd INT, Data SMALLDATETIME)
004 CHECKPOINT
005 ALTER TABLE Produtos ADD DataUltimaAtualizacao SMALLDATETIME
006 UPDATE Produtos SET DataUltimaAtualizacao = DataCadastro
007 GRANT SELECT ON Produtos TO UsrMarketing
008 EXEC sp_addrolemember ‘db_datareader’, ‘UsrRelatorios’
009 CHECKPOINT
010 DROP TABLE ProdutosHistorico

A propriedade RECOVERY MODEL

O Recovery Model de um banco de dados tem papel fundamental no funcionamento dessas estruturas de log e nas estratégias possíveis de Disaster Recover a partir de um backup. Há três opções para o Recovery Model: Simple, Bulk Logged e Full. Não explicarei os detalhes do funcionamento do Bulk Logged dada sua proximidade com o Recovery Model Full. Para o entendimento desse artigo, o Recovery Model Bulk Logged e Full podem ser interpretados como iguais embora não o sejam em alguns casos.

No Recovery Model Simple todas as transações são gravadas no arquivo de Log, mas a cada Checkpoint elas são excluídas do arquivo de Log liberando espaço para novas entradas. Se considerarmos que o arquivo de log exemplificado tem capacidade para gravar 10 LSNs e que o Recovery Model está marcado como Simple, após o Checkpoint do LSN004, os LSNs 001, 002, 003 e 004 seriam eliminados do arquivo de log, o mesmo valeria para os LSNs 005, 006, 007, 008 e 009 após o Checkpoint em LSN009. Se nesse momento aparecessem mais algumas entradas, elas seriam gravadas no início do arquivo que foi liberado. Ex

LSN Instrução
011 TRUNCATE TABLE TMP
012 EXEC UspRelatorioVendas @DataInicio = ‘20090720’
013 DBCC CHECKTABLE(‘RelatoriosConsolidados’)
014 CHECKPOINT
015 DROP USER UsrApp
   
   
   
   
010 DROP TABLE ProdutosHistorico

Os LSNs 011, 012, 013 e 014 são posteriores ao LSN010, mas como o arquivo tem capacidade para 10 entradas, é necessário acomodar esses LSNs. Como há espaço no início do arquivo, as entradas podem ser cadastradas perfeitamente sem prejudicar a consistência desse Log. No Recovery Model Simple, o Log recicla-se automaticamente e apaga as entradas que ficaram para trás e que foram contempladas no banco pelo processo de Checkpoint. Após o processo de Checkpoint, as transações ficam refletidas no banco e portanto são apagadas do Log de transações. O checkpoint contemplado no LSN014 apagaria todos os LSNs deixando somente o LSN015 e liberaria espaço para mais nove entradas de Log (quatro na área antes do LSN015 e cinco após a presença do LSN015). O Recovery Model Simple irá sempre reciclar as entradas do log formando um circulo na qual hora determinadas posições estaram preenchidas, serão apagadas pelo processo de Checkpoint, serão utilizadas novamente e excluídas novamente. É por esse comportamento em forma de círculo que essa arquitetura é chamada em alguns produtos de Log Circular.

No Recovery Model Full, as coisas funcionam um pouco diferentes. Ao contrário do Recovery Model Simple, o Recovery Model Full não irá apagar de forma automática os LSNs do log de transações independente do que aconteça. Mesmo que o processo de Checkpoint ocorra e as transações já estejam contempladas no banco de dados, o Log continuará a mantê-las no arquivo de Log. Essa característica de arquivamento faz com que alguns chamem essa arquitetura de Archieve Log. Se admitirmos que esse arquivo possui capacidade apenas para 10 LSNs, após completar os 10 LSNs, o arquivo ficará completamente cheio. O cadastro do LSN 011 ao LSN015 irá demandar que o arquivo de Log cresça conforme a tabela abaixo:

LSN Instrução
001 INSERT INTO Clientes VALUES (1,‘Alberto’,2560.92,‘M’)
002 DELETE FROM AjusteEstoque WHERE IDAjuste = 3097
003 CREATE TABLE Defeitos (IDDef INT, IDProd INT, Data SMALLDATETIME)
004 CHECKPOINT
005 ALTER TABLE Produtos ADD DataUltimaAtualizacao SMALLDATETIME
006 UPDATE Produtos SET DataUltimaAtualizacao = DataCadastro
007 GRANT SELECT ON Produtos TO UsrMarketing
008 EXEC sp_addrolemember ‘db_datareader’, ‘UsrRelatorios’
009 CHECKPOINT
010 DROP TABLE ProdutosHistorico
011 TRUNCATE TABLE TMP
012 EXEC UspRelatorioVendas @DataInicio = ‘20090720’
013 DBCC CHECKTABLE(‘RelatoriosConsolidados’)
014 CHECKPOINT
015 DROP USER UsrApp

Uma vez que o Recovery Model Full faz com que o banco de dados não exclua as entradas antigas do log de transações, ou seja, as transações que já estão contempladas no banco de dados, não é de se esperar que o log cresça de forma indefinida. Afinal novas transações irão gerar novos LSNs e como esses não são limpos de forma automática o resultado final é um arquivo de log de tamanhos acima do normal. O crescimento do Log se dará na velocidade em que novas transações ocorrem, mas é fato que mais cedo ou mais tarde ele irá incomodar.

Uma conclusão inicial é que se o arquivo de Log cresce de forma descomunal, o banco de dados não pode estar em Recovery Model Simple. Se o Recovery Model Simple faz a devida exclusão das entradas inativas (aquelas já contempladas pelo Checkpoint), não há como o Recovery Model Simple fazer com que um arquivo de Log cresça de forma desproporcional (muitas vezes ele não cresce). Se o banco de dados estiver com o Recovery Model Simple, a única preocupação é ter um arquivo de log que consiga acomodar a quantidade média de transações entre um checkpoint e outro.

A primeira recomendação é que se o arquivo de Log cresce demais, ao invés de simplesmente efetuar o Truncate com o Shrink funcionem, é mais factível mudar o Recovery Model para Simple. Assim, o arquivo de Log não irá crescer de forma descomunal e tenderá a ficar constante. Embora o Truncate com o Shrink funcione, o problema voltará a acontecer, pois, se o Recovery Model é Full o Log irá crescer novamente. Ao invés de executar sucessivos Truncates e Shrinks é mais sensato alterar o Recovery Model para Simple eliminando a causa raiz do problema.

A título de curiosidade, o truncate iria eliminar as entradas inativas do log, ou seja, todas aquelas anteriores ao último checkpoint e o shrink iria reduzir o arquivo, possivelmente devolvendo-o ao tamanho de 10 LSNs ao invés de 15 conforme a tabela abaixo:

LSN Instrução
   
   
   
   
   
   
   
   
   
015 DROP USER UsrApp

O início do arquivo ficaria pronto para receber novas entradas de LSN. Com o tempo, o Log cresceria e provocaria sucessivas expansões até que um novo truncate e um novo shrink fossem executados.

Se a diferença entre o Recovery Model Simple e o Recovery Model fosse apenas a administração do tamanho do arquivo de log seria interessante perguntar qual a utilidade do Recovery Model Full. Enquanto o Recovery Model Simple dispensa maiores preocupações com o tamanho do arquivo de log, o Recovery Model Full traz responsabilidades e preocupações adicionais e isso é um forte indício para pensar porque os bancos de dados não são criados com o Recovery Model Simple ? Dá muito menos trabalho.

É sem dúvida um raciocínio que faz sentido, mas vejamos a seguir porque o Recovery Model Full é importante mesmo com as implicações e overheads administrativos.

A escolha do Recovery Model e o processo de restauração

O Recovery Model tem papel fundamental no processo de backup e restauração do banco de dados. Alguns Recovery Models permitem a realização de backups de log e posterior recuperação enquanto outro simplesmente não permitem. O uso de backup de logs também é imprecindível para algumas estratégias de backup e restore mais complexas como o Restore Online e o Piecemal Restore ambos utilizados em conjunto com backups e filegroups. Por hora basta saber que o Recovery Model Simple não possibilita a realização de backups de logs enquanto que os demais Recovery Models possibilitam.

A razão para o Recovery Model Simple não permitir backups de logs é um pouco óbvia. Como ele exclui as entradas mais antigas do Log de transações a cada Checkpoint e como cada Checkpoint ocorre em média de minuto em minuto, não faria muito sentido fazer o backup do log de transações de uma base com o Recovery Model Simple. Não haveria o que gravar no backup, pois, provavelmente no momento de fazê-lo restariam apenas as entradas mais recentes (as que o Checkpoint) ainda não contemplou enquanto que muitos outros LSNs teriam sido deixados de lado. Como o Recovery Model Full não exclui as entradas do Log (mesmo as já contempladas pelo Checkpoint), faz sentido em falar de backups de log para bases com o Recovery Model Full. Vejamos como isso funciona através do hipotético arquivo de log.

LSN Hora Instrução
001 00:00 BACKUP DATABASE BD TO DISK = ‘C:\Temp\BDFull.BAK’
002 08:00 CREATE TABLE Tbl (Codigo INT)
003 09:00 INSERT INTO Tbl VALUES (1)
004 09:30 INSERT INTO Tbl VALUES (2)
005 10:00 BACKUP LOG BD TO DISK = ‘C:\Temp\BDLog01.TRN’
006 14:45 INSERT INTO Tbl VALUES (4)
007 15:20 INSERT INTO Tbl VALUES (5)
008 15:30 CHECKPOINT
009 16:00 INSERT INTO Tbl VALUES (6)
010 18:00 BACKUP LOG BD TO DISK = ‘C:\Temp\BDLog02.TRN’

Os backups contemplam a relação de LSNs conforme a tabela abaixo:

Backup Lsn Inicial Lsn Final
BDFull 001 001
BDLog01 002 005
BDLog02 006 010

Com essa relação de backups é visível que o banco de dados pode ser reconstruído para parar em qualquer posição possível entre o LSN 001 e o LSN 010. A tabela abaixo mostra as sequências necessárias para voltar o banco em qualquer LSN, ou melhor dizendo qualquer milissegundo entre às 00:00 e às 18:00.

LSN Sequência Necessária
001 Apenas o BDFull
002 Restaurar o BDFull e o BDLog01 com parada às 08:00
003 Restaurar o BDFull e o BDLog01 com parada às 09:00
004 Restaurar o BDFull e o BDLog01 com parada às 09:30
005 Restaurar o BDFull e o BDLog01 com aplicação total de BDLog01
006 Restaurar o BDFull, o BDLog1 com aplicação total e o BDLog02 com parada às 14:45
007 Restaurar o BDFull, o BDLog1 com aplicação total e o BDLog02 com parada às 15:20
008 Restaurar o BDFull, o BDLog1 com aplicação total e o BDLog02 com parada às 15:30
009 Restaurar o BDFull, o BDLog1 com aplicação total e o BDLog02 com parada às 16:00
010 Restaurar o BDFull, o BDLog1 e o BDLog02 com aplicação total para ambos

Segundo a tabela, é possível restaurar em qualquer LSN aplicando-se o backup full e restaurando-se os Logs necessários. Embora o exemplo pare em LSNs específicos, uma vez que os backups contemplem toda a duração de 00:00 até às 18:00 é possível parar em qualquer posição nesse intervalo. É totalmente factível voltar o banco às 12:00 mesmo que não haja nenhum LSN identificado.

Após a realização do backup de Log (BDLog01) os LSNs 001, 002, 003, 004 e 005 foram retirados do arquivo de Log e copiados para o backup de Log BDLog01. O backup de Log BDLog02 irá contemplar todos os LSNs gravados desde o último backup de Log (no caso o BDLog01) e portanto irá retirar do arquivo de Log os LSNs 006, 007, 008, 009 e 010. A realização desses backups retirou as entradas de Log inativas, liberou espaço e fez com que o arquivo de Log possuísse espaço disponível para acomodar futuras transações sem provocar um crescimento exagerado ou ainda o estouro do espaço disponível em disco.

Da mesma forma que um banco com o Recovery Model Simple não permite realizar backup de Log, ele também não permite efetuar o truncate do Log. Então situações que exijam o uso do truncate do Log só podem contemplar outros Recovery Models como no caso o Full. Vejamos como o uso do truncate (independente do Shrink ou não) afetaria o exemplo.

LSN Hora Instrução
001 00:00 BACKUP DATABASE BD TO DISK = ‘C:\Temp\BDFull.BAK’
002 08:00 CREATE TABLE Tbl (Codigo INT)
003 09:00 INSERT INTO Tbl VALUES (1)
004 09:30 INSERT INTO Tbl VALUES (2)
005 10:00 BACKUP LOG BD TO DISK = ‘C:\Temp\BDLog01.TRN’
006 14:45 CREATE TABLE EmpregadoMes (Nome VARCHAR(50))
007 15:20 INSERT INTO Tbl VALUES (5)
008 15:30 BACKUP LOG BD WITH TRUNCATE_ONLY
009 16:00 INSERT INTO EmpregadoMes VALUES (‘Fernando’)
010 18:00 BACKUP LOG BD TO DISK = ‘C:\Temp\BDLog02.TRN’

A relação de LSNs conforme os backups ficaria da seguinte forma:

Backup Lsn Inicial Lsn Final
BDFull 001 001
BDLog01 002 005
BDLog02 009 010

É possível observar que o LSN 008 fez um truncate no Log e por isso o backup de Log BDLog02 só contemplou o LSN subsequente ao LSN que efetuou o truncate. Vejamos agora as possibilidades de restauração:

LSN Sequência Necessária
001 Apenas o BDFull
002 Restaurar o BDFull e o BDLog01 com parada às 08:00
003 Restaurar o BDFull e o BDLog01 com parada às 09:00
004 Restaurar o BDFull e o BDLog01 com parada às 09:30
005 Restaurar o BDFull e o BDLog01 com aplicação total de BDLog01
006 Não é possível restaurar, pois, não há como chegar até o LSN 006
007 Não é possível restaurar, pois, não há como chegar até o LSN 007
008 Não é possível restaurar, pois, não há como chegar até o LSN 008
009 Não é possível restaurar, pois, não há como pular para o LSN 009
010 Não é possível restaurar, pois, não há como pular para o LSN 010

Como o log foi truncado no LSN 008, o backup de Log BDLog02 não irá contemplar os LSNs 006, 007 e 008 que são os LSNs subsequentes ao backup de Log BDLog01. Assim é impossível restaurar o banco em uma posição que contemple esses LSNs, ou seja, não será possível restaurar o banco em nenhum horário entre às 10:00 (LSN 005) e às 16:00 (LSN 009). Embora os LSNs 009 e 010 estejam contemplados no backup de Log BDLog02, também não será possível restaurá-los, pois, a restauração de backups de log não permite que sequências de log sejam quebradas. Se o Backup Full (BDFull) e o primeiro backup de Log (BDLog) forem restaurados, o banco ficará parado no LSN 005 às 10:00. Não será possível simplesmente "pular" das 10:00 (LSN 005) para às 16:00 (LSN 009), pois, nesse tempo houve atividades no banco de dados que não podem ser desconsideradas. Podemos ver que o LSN 006 cria a tabela EmpregadoMes e que o LSN 009 faz um INSERT nessa tabela. Se os LSNs 006, 007 e 008 pudessem ser ignorados, o LSN 009 iria gerar um erro, pois, se o LSN 006 foi ignorado, a tabela EmpregadoMes não exisitiria. A verdade é que mesmo que essa tabela fosse criada em um LSN contemplado no backup (digamos o LSN 004), não é possível fazer a restauração, pois, a única forma de garantir a consistência é passando por todos os LSNs contemplados sem "pular" (ou melhor desconsiderar) etapas da história do banco de dados. A verdade é que no momento em que se trunca o Log todo o processo de restauração é invalidado a partir do último backup de log antes do truncate (no caso após o LSN 005 o banco não pode ser recuperado).

Observa-se que um simples comando de backup com a opção truncate_only inviabilizou parte do processo de restauração. Inegavelmente o truncate do log de transações liberou espaço e talvez tenha "resolvido o problema do log de transações grande demais". Sim, essa é justamente a parte que todos conhecem e esperam como resultado do comando. Se o Shrink for executado em seguida, a área livre do arquivo de Log será devolvida ao Windows fazendo com que o arquivo seja efetivamente reduzido. O que maioria das pessoas efetivamente não avalia ou simplesmente desconhece é o efeito colateral desse comando. De fato ele liberou espaço, mas acabou de invalidar parte do processo de restauração. Possivelmente o executor do comando não irá descobrir isso após truncar o log, mas sim em uma situação futura quando seu banco de dados estiver com problemas e ele precisar restaurar um backup. Nesse hora ele encherá o peito e falará a si próprio (ou ao chefe se ele estiver próximo): "Tenho uma rotina de backups full e de Log e posso portanto restaurar o backup em qualquer posição desejada". Mal sabe ele que após rodar o inocente comando de truncate do log sua rotina de backups de Log foi jogada no lixo. O problema é que essa descoberta se dará no momento em que o backup será o mais imprescindível possível e infelizmente não será possível contar com ele.

Dada as limitações atuais do Spaces, não pude publicar nesse artigo um exemplo prático. Eu o apresento logo a seguir na parte II do artigo.

[ ]s,

Gustavo

13 Respostas para “Piores Práticas – Utilizar o comando BACKUP LOG com a opção WITH TRUNCATE_ONLY – Parte I

  1. Saudações Gustavo,Muito bom o seu artigo, meus parabéns!! Estou migrando minhas atribuições para SQL Server e seu artigo me ajudou bastante a entender uma situação que estou enfrentando em meu ambiente de trabalho.[]´sJunior

  2. Olá Ismael,Fico contente do artigo lhe ser útil e de você aprender do jeito "certo" ao invés de optar por soluções mais imediatas que possam trazer problemas no futuro. Eu agradeço o seu feedbackAbs,

  3. Gustavo, parabéns pela riqueza em detalhes nessa explicação. Já lí muitos artigos a respeito mas nenhum comparado ao seu. Me ajudou a entender melhor sobre os tipos de logs do SQL. Valeu!Edner

  4. Olá Edner,Obrigado pelo feedback. Eu tentei realmente ser o mais claro possível na explicação do funcionamento do log de transação e os impactos na hora de efetuar o backup / truncate. Que bom que lhe ajudou :)[ ]s,

  5. Flavio Jacinto

    Parabéns pelo artigo.
    Esclareceu muitas coisas. Continue escrevendo sobre o SQL Server.

    Um abraço.

    Flávio

  6. Excelente artigo, esclareceu minhas duvidas a respeito do meu log de trasação, estou mais aliviado! rsrsrs

  7. Minha duvida é seguinte,

    fiz um job para backup log to arquivolog.str para 10 em 10 minutos.

    Este job sobrescreve o de 10 em 10 minutos o mesmo arquivo “arquivolog.str”.
    Se eu for restaurar a mesma base de dados percebi que ele pega a sequencia correta dos logs no arquivolog.str, mas, se eu deletar o .mdf e tentar fazer um full do .mdf e subir o arquivolog.str, o numero LSN não bate.

    Como posso resolver este problema? Teria que criar um t-sql para sempre adicionar arquivolog.str em sequencia. Exemplo:
    arquivolog1.str
    arquivolog2.str
    etc..
    até ele fazer um diferencial e recomeçar
    arquivolog.1.str
    arquivolog2.str
    etc?

    • Boa Noite Hudson,

      Confesso que fiquei um pouco perdido com sua dúvida (como assim restaurar um full do .mdf ?). Independente disso, tenho duas considerações. A primeira é que 10 minutos é uma frequência muito alta. Se você faz um backup a cada dez minutos, ao final do dia você terá 144 logs. Se fizer um full semanal, a carga de logs vai para pouco mais de mil logs. Não recomendo log a cada dez minutos. Acredito que frequências mais altas como meia hora ou até de duas em duas horas sejam mais adequadas (a menos que algo como o Log Shipping esteja envolvido). Minha outra consideração é que você não sobrescreva o arquivo. Se você sobrescrever, as transações serão apagadas e o restore ficará comprometido.

      [ ]s,

      Gustavo

  8. Olá Gustavo,

    Estou começando agora a estudar o SQL Server 2008, e um dos maiores problemas que enfrentamos aqui na empresa, com certeza é o tal do log que cresce a tal ponto que não se consegue executar procedimento algum, e sempre executamos o script mencionado por você, quando li, confesso que até ri da situação.
    Gostaria de aproveitar para tirar uma dúvida inclusive, um superior meu me orientou a deixar a base com transaction full, porém, no momento de se fazer o backup, esvaziar o transaction log.
    Isto pode-se considerar uma “pior prática” também ?

    • Olá Anderson,

      Se o seu log está crescendo demais, faça mais backups para que as transações sejam arquivadas e retiradas do log de transações que aí ele não enche e tudo certo.

      A prática do seu superior não faz nenhum sentido (embora muita gente a utilize). Se você esvazia o log de transações, você está invalidando-o, pois, ele não poderá ser utilizado para restaurar backups posteriormente. E se você o invalida, qual é o sentido de ter o recovery model full ? Seria melhor deixar a base no recovery model simple e não ter problemas, pois, o resultado final seria o mesmo da sugestão do seu chefe, porém sem a preocupação do log encher. Claro que em ambas as situações, você perde o “Point In Time”.

      [ ]s,

      Gustavo

  9. Pingback: Backup e Shrink no Banco de Dados | Lealpjm

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s