Ideapedia-MS SQL Server

Conceito Básico - Checkpoints ou pontos de verificação

Tecnicamente um servidor SQL deve operar para sempre de maneira confiável, rápida, mas ele tem que fazer muitas tarefas e por esse motivo divide a execução dessas tarefas por tempo ( chama-se time sharing ). Então se o sql esta atualizando um monte de dados ele vai gerar um ckeckpoint ou Ponto de verificação em um determinado momento para gravar essas informações antes que perca tudo. Ele pára temporariamente de executar a tarefa, vai executar outra tarefa e no final desta nova tarefa, volta para a tarefa anterior. Portanto o ckeckpoint é um ponto no tempo que o SQL cria para gerar uma 'quebra' no processo atual e permite que outras tarefas fundamentais do processo sejam executadas, cada uma por um tempo limitado até terminar. É como um batalhão marchando, eles marcam o passo para não perder a sincronia num desfile mas em cada 'manobra' (uma virada por exemplo) eles precisam revisar a marcação de passo e recuperar a sincronia, é isso que faz o checkpoint, cria uma ordem para que tudo que não está certo seja acertado pelos processos do servidor.

O SQL Server gera pontos de verificação e cria controles para que a restauração até esse ponto seja possível. Digamos que o Servidor SQL parte de um estado estável ( onde tudo está correto ) e faz uma modificação ( grava uma atualização no disco, por exemplo ) e depois no próximo checkpoint verifica se tudo ocorreu ok e gera um novo ponto estável nos processos do servidor e tudo se repete novamente.

Backup e o Recovery Model

Todo processo em informática é passível de falhas. O Recovery Model determina como vai ser a recuperação das informações em caso de falha.

Seja qual for o backup escolhido haverá um custo e um benefício. Quanto maior o custo maior será o benefício mas nem todas as empresas estão dispostas a arcar certos custos com os servidores SQL .

Portanto é fundamental no momento da escolha do processo de backup que o pessoal de ti e da empresa estejam acordados, cientes dos riscos, das opções que foram tomadas. Costumo fazer um documento mencionando o que está coberto e o que será perdido em caso de um acidente.

O backup esta diretamente ligado ao Recovery Model e determinará o que será recuperado e o que será perdido no caso de uma falha.

A opção Recovery Model determina a forma de recuperação do banco de dados após um desastre e as opções de backups e restore disponíveis.

Um modelo de recuperação é uma opção de configuração do banco de dados que determina o tipo de backup que se pode executar e fornece a capacidade de restaurar os dados ou recuperá-los de uma falha.

O modelo de recuperação decide como o log de transações de um banco de dados deve ser mantido e protege as alterações de dados em uma sequência específica, que pode ser usada posteriormente para uma operação de restauração de banco de dados.

Existe três opções de Recovery Model disponíveis: Full, Simple e bulk-Logged..
    • Full: Todas as operações são mantidas no log transaction, este log nunca é trucado.
    • Simple: O mínimo de operações são mantidas no log transaction, e a cada checkpoint o log transaction é trucado.
    • Bulk-Logged: O mínimo de operações é mantido, não ha suporte a restore no ponto de falha.

Cada método tem vantagens e desvantagens sobre o outro, nenhum é melhor ou pior que outro. Um se adequa melhor que outro ao seu negócio.

Recovery Model : SIMPLE

O modelo de recuperação SIMPLE é o mais simples entre os modelos disponíveis e se baseia em backups do banco de dados. Até o último backup os dados poderão ser recuperados, depois disso até o momento da falha tudo será perdido. Isto ocorre porque não há backup do log de transações e, neste modelo, o log de transações não são suportados.

Ele suporta backups completos (FULL), diferenciais e em nível de arquivo, mas não suporta os backups incrementais.

O Log é o calcanhar de aquiles deste modelo. O espaço do log é reutilizado sempre que ocorre a operação do ponto de verificação do processo em segundo plano do SQL Server. A parte inativa do arquivo de log é removida e disponibilizada para reutilização.

Não há suporte para restauração pontual e de página, apenas a restauração dos dados pelos arquivos de backup.

Razões para escolher o modelo SIMPLES de recuperação de banco de dados

1-É o de menor custo portanto ideal para bancos de dados de desenvolvimento e teste.

2-Só deve ser utilizado onde a perda de dados por um período x é aceitável.

A recuperação de ponto de falha é exclusivamente para backups completos e diferenciais

• Suporta:
    • Backup completo (Full Backup)
    • Backup diferencial (Differencial Backup)
    • Backup somente cópia (Copy-Only Backup)
    • Backup de arquivo (File Backup)
    • Backup parcial (Partial Backup)

Recovery Mode : FULL

Este é o melhor e portanto mais caro backup, tanto em termos de carga do servidor SQL como em custo porque ele é uma cópia FIEL do banco de dados. Com certeza, com um backup full podemos restaurar o servidor completamente.

Nesse modelo de recuperação, todas as transações (DDL (Data Definition Language) e DML (Data Manipulation Language)) são totalmente registradas no arquivo de log de transações.
e a sequência do log é ininterrupta o que preserva todas as informações para a restauração dos bancos de dados.

Diferentemente do modelo de recuperação Simples, o arquivo de log de transações NUNCA é truncado automaticamente durante as operações do CHECKPOINT. É no LOG que podemos restaurar a base de dados até qualquer período de tempo coberto pelo backup.

Todas as operações de restauração são suportadas, incluindo restauração point-in-time, restauração de página e restauração de arquivos.

Razões para escolher o modelo completo de recuperação de banco de dados:

1-Suporte a aplicativos de missão crítica onde não podemos perder dados.

2-Deve ser usado em projeto e soluções de alta disponibilidade

3-Facilita a recuperação de todos os dados com perda de dados zero ou mínima

4-Se o banco de dados foi projetado para ter vários grupos de arquivos e você deseja executar uma restauração fragmentada de grupos de arquivos secundários de leitura / gravação e, opcionalmente, grupos de arquivos somente leitura.

5-Permite a restauração point-in-time ( num ponto determinado do tempo coberto pelo backup) arbitráriamente escolhida pelo operador.

6-Permite restaurar páginas individuais de dados.

• Ele suporta todos os tipos de backups a seguir
    • Backup completo
    • Backup diferencial
    • Backup do log de transações
    • Backup somente cópia
    • Backup de arquivo e / ou grupo de arquivos
    • Backup parcial

Recovery Model BULK_LOGGED

Este tipo de backup é um intermediário entre o simples e o completo e por esse motivo só em situações especiais é utilizado.

É uma opção de configuração de banco de dados para fins especiais e funciona de maneira semelhante ao modelo de recuperação COMPLETO, exceto que certas operações em massa podem ser minimamente registradas, ou seja, é registrada a ação mas o conteúdo atingido pela ação é perdido porque não é gravado no LOG.

Este backup pode ser usado em sistemas onde praticamente nunca ninguém usa comandos de atualização em massa dos seus dados, que é o mais comum. Sendo assim é um backup muito mais leve para o servidor porque o LOG fica menor.

O problema é que não é possível restaurar dados pontuais específicos.

Razões para escolher o modelo de recuperação de log em massa:

1-Usa a técnica mínima de registro no log para impedir o crescimento do arquivo em operações extensas ou que nunca ocorrem.

Ele suporta todos os tipos de backups:
    • Backup completo
    • Backup diferencial
    • Backup do log de transações
    • Backup somente cópia
    • Backup de arquivo e / ou grupo de arquivos
    • Backup parcial

Transaction Log Internals-Como funciona o log de transações internamente

1-Sempre que houver uma transação (DDL e DML), os detalhes de cada operação serão registrados no arquivo de log de transações

2-O backup do log de transações garante durabilidade transacional e consistência dos dados usando um mecanismo conhecido como WAL (Write-Ahead-Logging - escreve no log antes de executar a atividade).

3-As transações que ocorrem no banco de dados primeiro são registradas no arquivo de log de transações e, em seguida, os dados são gravados no disco.

4-Isso facilita o SQL Server a reverter ou avançar cada etapa do processo de recuperação

5-Permite restauração point-in-time de bancos de dados

6-O SQL Server sempre grava no arquivo de log de transações sequencialmente. Ao chegar no fim do espaço arquivo de LOG ele pode reescrever as informações usando um ciclo de reutilização do espaço ou pode optar para crescer o log se for configurado para isso, até atingir um tamanho máximo.

O arquivo de log de transações pode ser dividido em blocos que são mapeados logicamente usando os VLFs (arquivos de log virtuais). Portanto o arquivo de log é um mas seccionado em partes e podemos tirar backup dessas partes separadamente e independentemente.

7-Os registros de log nos blocos que não são mais necessários são considerados "inativos" e essa parte dos blocos de log pode ser truncada, ou seja, os segmentos inativos dos blocos de log são substituídos por novas transações. Esses segmentos ou parte do arquivo de log são conhecidos como arquivos de log virtual (VLFs).

8-Qualquer VLF inativo pode ser truncado, embora o ponto em que esse truncamento possa ocorrer dependa do modelo de recuperação do banco de dados.

9-No modelo de recuperação SIMPLE, o truncamento do LOG pode ocorrer imediatamente após a ocorrência de uma operação CHECKPOINT. As páginas no cache de dados são descarregadas para o disco, depois de "endurecer" as alterações no arquivo de log.
O espaço em qualquer VLFs que se torna inativo como resultado e é disponibilizado para reutilização

10-Um banco de dados só tem um log que pode ser dividido em vários arquivos de log, mas é obrigatório ter pelo menos um.
Ele só grava em um arquivo de log por vez e ter mais de um arquivo não aumenta a velocidade ou a taxa de transferência de gravação.
De fato, ter mais arquivos múltiplos pode resultar em degradação do desempenho, se cada arquivo não for dimensionado corretamente ou tiver tamanho diferente.

Qualquer incompatibilidade leva a uma maior duração da recuperação do banco de dados
Para bancos de dados críticos para os negócios, é recomendável iniciar backups completos do banco de dados, seguidos por uma série de backups freqüentes de logs de transações, seguidos por outro backup completo, e assim por diante.

Como parte da operação de restauração do banco de dados, podemos restaurar o backup completo mais recente (mais diferenciais, se necessário), seguido pela cadeia de backups de arquivos de log disponíveis, até o que cobre o momento no qual desejamos restaurar o backup. base de dados

Visão geral do modelo de recuperação

Simples

Descrição
• Não há backups de log de transações.
• No Modelo de Recuperação Simples, o log de transações é limpo automaticamente e o tamanho do arquivo é mantido intacto.Por esse motivo, não é possível fazer backups de log nesse caso.
• Suporta apenas operações de backup completas e bulk_logged.
• Os recursos não suportados no modelo de recuperação simples são:
• envio de log, • AlwaysOn • espelhamento e restauração pontual
• Perda de dados : Sim. Não podemos restaurar o banco de dados para um ponto arbitrário no tempo.
Isso significa que, no caso de uma falha, só é possível restaurar o banco de dados tão atual quanto o último backup completo ou diferencial, e a perda de dados é uma possibilidade real
• Restauração point-in-time : Não

Full

Descrição
• Suporta backups de log de transações.
• Nenhum trabalho é perdido devido a um arquivo de dados perdido ou danificado.
• O modelo de recuperação de banco de dados completo registra completamente todas as transações que ocorrem no banco de dados.
• Pode-se escolher arbitrariamente um ponto no tempo para a restauração do banco de dados.
• Isso é possível restaurando primeiro um backup completo, o diferencial mais recente e depois reproduzindo as alterações registradas no log de transações. Se não houver um backup diferencial, a série de logs t será aplicada.
• Suporta recuperação de dados point-in-time.
• Se o banco de dados usar o modelo de recuperação completa, o log de transações aumentará infinitamente, e isso será um problema. Portanto, precisamos ter certeza de que fazemos backups de log de transações regularmente.
• Perda de dados: Perda de dados mínima ou nula.
• Restauração point-in-time: Essa configuração permite mais opções.
• Recuperação pontual.

Bulk-Logged (Registro em massa)

Descrição
• Esse modelo é semelhante ao Modelo de recuperação completa, pois um log de transações é mantido, mas certas transações, como operações de carregamento em massa, são minimamente registradas, embora registre outra transação.
Isso faz com que as importações de dados em massa sejam mais rápidas e mantém o tamanho do arquivo do log de transações, mas não suporta a recuperação pontual dos dados.
• Isso pode ajudar a aumentar as operações de carregamento em massa de desempenho.
• Reduz o uso do espaço de log usando o log mínimo para a maioria das operações em massa.
• Perda de dados: Se você executar transações no modelo de recuperação com registro em massa que possa exigir uma restauração do log de transações, essas transações poderão ficar expostas à perda de dados.
• Restauração point-in-time: A recuperação point-in-time só é possível se as condições abaixo forem atendidas
• Atualmente, os usuários não são permitidos no banco de dados (bd in single mode).
• Se você conseguir executar novamente os processos em massa (bulk processes).

Alternando modelos de recuperação

Full and bulk-Looged - Logs completos e em massa:
• Iniciar um backup de log
• Execute operações em massa, retorne imediatamente o banco de dados ao modelo de recuperação completa
• Iniciar backup do log de transações

Simples a COMPLETO ou Diferencial

• Iniciar um backup completo (ou diferencial, se já estiver disponível)
• Agendar backups de log t

FULL ou BULK_Logged para Simple

• Desativar a tarefa de backup do log de transações
• Verifique se há um trabalho para fazer backup completo
• Visualize ou altere o modelo de recuperação de banco de dados usando as seguintes opções:

Notas :

1- É possível verificar o qual o recovery model utilizado no banco de dados pelo SSMS ou através da query abaixo:
select name, recovery_model_desc from sys.databases

2- É possível alterar o recovery model através da query abaixo as opções disponíveis são(FULL|SIMPLE|BULK_LOGGED) :
-- alterando o recovery da base de dados data para SIMPLE
alter database data set recovery SIMPLE

3- Em bases de produção é recomendado o uso do recovery model FULL com backups diferenciais de hora em hora ou num período que a perda de dados seja tolerável.

2-Retirando backup de todas as bases da instância
    Alter procedure GERA_BACKUP as begin
    --CREATE procedure GERA_BACKUP as begin

        declare GERA_BACKUP cursor fast_forward for

            select name from master.dbo.SysDatabases

            declare @database varchar(200)
            declare @cmd varchar(200)
            declare @data varchar(20)
            declare @resultado varchar(7500)

    -- msg de inicio do processo
            set @data=getdate()
            print 'inicio:' + @data

    -- eliminando o backup do dia anterior
            exec xp_cmdshell 'del C:\BKP_LOCAL_GTD01\BKP_GTD01.bak'


            open GERA_BACKUP

            fetch next from GERA_BACKUP into @database

            while (@@fetch_status <> -1) begin
                if (@@fetch_status <> -2) and (@database <> 'tempdb') and (@database <> 'master') and (@database <> 'model') and (@database <> 'msdb') begin
                    set @cmd = 'backup database ' + @database + ' to BKP'
    --                print ''
    --                print '---------------------------------------'
    --                print '-- TIRANDO BACKUP DA BASE DE DADOS : --'
    --                print @cmd
    --                print '---------------------------------------'
                    exec (@cmd)
                end

                fetch next from GERA_BACKUP into @database

            END

    --msg de fim de backup
            set @data = CONVERT(VARCHAR(20),getdate())
            print 'fim:' + @data
        end

        close GERA_BACKUP
        DEALLOCATE GERA_BACKUP

    /*
    -- formato : backup database base_dados to device
    exec GERA_BACKUP
    */

3-Backup Diário das bases de dados
    alter procedure proc_backup_diario as begin
    --create procedure proc_backup_diario as begin

        set nocount on

        declare @base_dados varchar(50)
        declare @data datetime
        declare @periodicidade varchar(20)
        declare @servidor varchar(50)
        declare @utilizacao varchar(2000)
        declare @site varchar(500)
        declare @responsavel varchar(50)
        declare @table_name varchar(150)

        declare @comando varchar(2000)
        declare @usuario varchar(200)
        declare @senha varchar(200)

        declare cursor_backup_diario Cursor for
            select * from tab_controle_backup

            Open cursor_backup_diario

            fetch next from cursor_backup_diario
                into @base_dados, @data, @periodicidade, @servidor,
                    @utilizacao, @site, @responsavel

            while (@@fetch_status = 0 ) begin

                if @periodicidade = 'DIARIA' begin

                    if datediff(d,@data,getdate()) >= 1 begin
                        print 'precisa tirar backup DIARIO : ' + @base_dados + ', data ult bkp : ' + convert(varchar(15),@data)
    -- bases de dados
    -- select name from master..sysdatabases where dbid > 4

    --tabelas dentro de uma base de dados
    --use INFO_ATIV_COM
    --sp_tables @table_name = '%'
    --where table_owner <> 'INFORMATION_SCHEMA'
    --and table_owner <> 'sys'

    -- buscando as tabelas da base de dados

                        set @comando = 'bcp ' + Char(34) + @base_dados + '.dbo.' + @table_name
                        set @comando = @comando + Char(34) + ' out ' + Char(34) + @base_dados + '.dbo.' + @table_name + '.txt'
                        set @comando = @comando + Char(34) + ' -e' + Char(34) + @base_dados + '_dbo_' + @table_name + '.err' + Char(34)
                        set @comando = @comando + ' -S' + @servidor + ' -U' + @usuario + ' -P' + @senha + ' -n'
                        print @comando
                    end
                end

                if @periodicidade = 'MENSAL' begin
                    if datediff(m,@data,getdate()) >= 1 begin
                        print 'precisa tirar backup MENSAL : ' + @base_dados + ', data ult bkp : ' + convert(varchar(15),@data)
                    end
                end

                fetch next from cursor_backup_diario
                    into @base_dados, @data, @periodicidade, @servidor,
                        @utilizacao, @site, @responsavel
            end

            close cursor_backup_diario
            deallocate cursor_backup_diario
    end

    /*
    exec proc_backup_diario
    */

4-Backup manual
    -- eliminando o dispositivo de backup anterior
    --sp_dropdevice 'BKP'

    -- eliminando o backup anterior
    exec xp_cmdshell 'DEL C:\BKP_LOCAL_GTD01\BKP_GTD01.bak'

    -- criando o dispositivo de backup
    /*
        exec sp_addumpdevice
        @devtype = 'disk',
        @logicalname = 'BKP_GTD01',
        @physicalname = 'C:\BKP_LOCAL'
    */

Backup e o Recovery Model

O backup esta diretamente ligado ao Recovery Model.
    A opção Recovery Model determina a forma de recuperação do banco de dados após um desastre e as opções de backups e restore disponíveis.

Um modelo de recuperação é uma opção de configuração do banco de dados que determina o tipo de backup que se pode executar e fornece a capacidade de restaurar os dados ou recuperá-los de uma falha.

O modelo de recuperação decide como o log de transações de um banco de dados deve ser mantido e protege as alterações de dados em uma sequência específica, que pode ser usada posteriormente para uma operação de restauração de banco de dados.

Existe três opções de Recovery Model disponíveis: Full, Simple e bulk-Logged.
    •Full: Todas as operações são mantidas no log transaction, este log nunca é trucado.
    •Simple: O mínimo de operações são mantidas no log transaction, e a cada checkpoint o log transaction é trucado.
    •Bulk-Logged: O mínimo de operações é mantido, não a suporte a restore no ponto de falha.

Recovery Model : SIMPLE

• O modelo de recuperação SIMPLE é o mais simples entre os modelos disponíveis.
• Ele suporta backups completos, diferenciais e em nível de arquivo.
• Os backups do log de transações não são suportados.
• O espaço do log é reutilizado sempre que ocorre a operação do ponto de verificação do processo em segundo plano do SQL Server.
• A parte inativa do arquivo de log é removida e disponibilizada para reutilização.
• Não há suporte para restauração pontual e de página, apenas a restauração do arquivo secundário somente leitura.

Razões para escolher o modelo simples de recuperação de banco de dados

• Mais adequado para bancos de dados de desenvolvimento e teste
• Relatórios simples ou banco de dados de aplicativos, onde a perda de dados é aceitável
• A recuperação de ponto de falha é exclusivamente para backups completos e diferenciais
• Nenhuma sobrecarga administrativa
• Suporta:
    • Backup completo (Full Backup)
    • Backup diferencial (Differencial Backup)
    • Backup somente cópia (Copy-Only Backup)
    • Backup de arquivo (File Backup)
    • Backup parcial (Partial Backup)

Recovery Mode : FULL

• Nesse modelo de recuperação, todas as transações (DDL (Data Definition Language) + DML (Data Manipulation Language)) são totalmente registradas no arquivo de log de transações.
• A sequência do log é ininterrupta e é preservada para as operações de restauração dos bancos de dados.
• Diferentemente do modelo de recuperação Simples, o arquivo de log de transações não é truncado automaticamente durante as operações do CHECKPOINT.
• Todas as operações de restauração são suportadas, incluindo restauração point-in-time, restauração de página e restauração de arquivos.

Razões para escolher o modelo completo de recuperação de banco de dados:

• Suporte a aplicativos de missão crítica
• Projeto de soluções de alta disponibilidade
• Para facilitar a recuperação de todos os dados com perda de dados zero ou mínima
• Se o banco de dados foi projetado para ter vários grupos de arquivos e você deseja executar uma restauração fragmentada de grupos de arquivos secundários de leitura / gravação e, opcionalmente, grupos de arquivos somente leitura.
• Permitir restauração point-in-time arbitrária
• Restaurar páginas individuais
• Incorrer em alta sobrecarga administrativa

• Ele suporta todos os tipos de backups a seguir
    • Backup completo
    • Backup diferencial
    • Backup do log de transações
    • Backup somente cópia
    • Backup de arquivo e / ou grupo de arquivos
    • Backup parcial

Recovery Model BULK_LOGGED

• É uma opção de configuração de banco de dados para fins especiais e funciona de maneira semelhante ao modelo de recuperação COMPLETO, exceto que certas operações em massa podem ser minimamente registradas.
• O arquivo de log de transações usa uma técnica conhecida como log mínimo para operações em massa.
• O problema é que não é possível restaurar dados pontuais específicos.

Razões para escolher o modelo de recuperação de log em massa:

• Us1 a técnica mínima de log para impedir o crescimento do arquivo de log
• Se o banco de dados estiver sujeito a operações em massa periódicas

Ele suporta todos os tipos de backups:
    • Backup completo
    • Backup diferencial
    • Backup do log de transações
    • Backup somente cópia
    • Backup de arquivo e / ou grupo de arquivos
    • Backup parcial

Transaction Log Internals-Como funciona o log de transações internamente

O Log de transações armazena cada operação que o SQL Server faz e não é possível desligar ou não usar o Log de transações. No banco de dados Oracle isto é possível porque ele funciona de outra maneira.
• 1-Sempre que houver uma transação (DDL e DML), os detalhes de cada operação serão registrados no arquivo de log de transações
• 2-O backup do log de transações garante durabilidade transacional e consistência dos dados usando um mecanismo conhecido como WAL (Write-Ahead-Logging - escreve no log antes de executar a atividade).
• 3-As transações que ocorrem no banco de dados primeiro são registradas no arquivo de log de transações e, em seguida, os dados são gravados no disco.
• 4-Isso facilita o SQL Server a reverter ou avançar cada etapa do processo de recuperação
• 5-Permite restauração point-in-time de bancos de dados
• 6-O SQL Server sempre grava no arquivo de log de transações sequencialmente.
É de natureza cíclica.
O arquivo de log de transações é dividido em blocos de log que são mapeados logicamente usando os VLFs (arquivos de log virtuais)
• 7-Os registros de log nos blocos que não são mais necessários são considerados "inativos" e essa parte dos blocos de log pode ser truncada, ou seja, os segmentos inativos dos blocos de log são substituídos por novas transações.
Esses segmentos ou parte do arquivo de log são conhecidos como arquivos de log virtual (VLFs)
• 8-Qualquer VLF inativo pode ser truncado, embora o ponto em que esse truncamento possa ocorrer dependa do modelo de recuperação do banco de dados
• 9-No modelo de recuperação SIMPLE, o truncamento pode ocorrer imediatamente após a ocorrência de uma operação CHECKPOINT.
As páginas no cache de dados são descarregadas para o disco, depois de "endurecer" as alterações no arquivo de log.
O espaço em qualquer VLFs que se torna inativo como resultado e é disponibilizado para reutilização
• 10-Um banco de dados pode ter vários arquivos de log, mas é obrigatório ter pelo menos um.
Ele só grava em um arquivo de log por vez e ter mais de um arquivo não aumenta a velocidade ou a taxa de transferência de gravação.
De fato, ter mais arquivos múltiplos pode resultar em degradação do desempenho, se cada arquivo não for dimensionado corretamente ou tiver tamanho diferente.
• Qualquer incompatibilidade leva a uma maior duração da recuperação do banco de dados
Para bancos de dados críticos para os negócios, é recomendável iniciar backups completos do banco de dados, seguidos por uma série de backups freqüentes de logs de transações, seguidos por outro backup completo, e assim por diante.
• Como parte da operação de restauração do banco de dados, podemos restaurar o backup completo mais recente (mais diferenciais, se necessário), seguido pela cadeia de backups de arquivos de log disponíveis, até o que cobre o momento no qual desejamos restaurar o backup. base de dados

Visão geral do modelo de recuperação

Simples

Full

Bulk-Logged (Registro em massa)

Alternando modelos de recuperação

Simples a COMPLETO ou Diferencial

• Iniciar um backup completo (ou diferencial, se já estiver disponível)
• Agendar backups de log t

FULL ou BULK_Logged para Simple

Notas :
1- É possível verificar o qual o recovery model utilizado no banco de dados pelo SSMS ou através da query abaixo:
select name, recovery_model_desc from sys.databases

2- É possível alterar o recovery model através da query abaixo as opções disponíveis são(FULL|SIMPLE|BULK_LOGGED) :
-- alterando o recovery da base de dados data para SIMPLE
alter database data set recovery SIMPLE

3- Em bases de produção é recomendado o uso do recovery model FULL.