Início / dba / Perguntas / 329199
Accepted
Radioleao
Asked: 2023-07-12 16:34:34 +0800 CST

Backup completo do MS SQL por partição, pode ser feito sem log?

  • 772

A questão é que eu realmente não preciso do t-tlog e desejo evitá-lo. Procurei em muitos tópicos, mas não procurei a resposta de que preciso (o tópico de backup do MSSQL é muito complicado de entender bem em todos os aspectos).

Meu banco de dados é feito assim:

  • 15 tabelas de dados de configuração
  • 3 tabelas com grande quantidade de linhas por mês (no geral são 30 milhões a 50 milhões de linhas por mês)
  • Os dados do mês atual são gravados/atualizados todas as noites
  • Os dados dos meses anteriores são armazenados apenas (não são mais alterados)
  • Partições:
    • 1 partição para primária
    • 1 partição para dados de configuração
    • n partições para dados de meses (1 partição para cada mês)

Todas as noites, muitos processos recalculam todos os dados do mês; todas as manhãs há poucas mudanças em relação ao dia anterior. Isso significa também: um enorme log de transações em comparação com poucas chances de dados finais).

Eu tenho esta configuração de processo/backup:

  1. Processar dados à noite
  2. Backup completo todos os domingos de manhã
  3. Backup diferencial na manhã de segunda a sábado
  4. Backup T-Log

Quando restauro os dados, a ordem deve ser:

  1. Restauração de backup completo
  2. Restauração de todos os backups diferenciais desde o último backup completo
  3. Restauração de todos os backups T-Log desde o último backup completo
  4. Restauração do backup da cauda

Por exemplo, na quarta-feira:

  1. Backup de log final
  2. Restauração do backup completo do dia 1 (domingo)
  3. Restauração do backup diferencial do dia 2, 3, 4 (seg, ter, qua)
  4. Restauração do backup t-log do dia 2, 3, 4 (seg, ter, qua)
  5. Restauração do tail log, COM RECUPERAÇÃO

Minhas perguntas seguem.

Questão 1 : Como restaurei todos os backups diferentes, por que preciso de todos os backups de log desde o último completo? Por que não basta apenas o t-Log desde o último backup diferencial?

Pergunta 2 : Posso restaurar apenas backup completo e diferencial e colocar meu banco de dados online sem restauração de log?

Questão 3 : Após o processamento noturno dos dados, tenho certeza de que nenhum outro dado foi alterado. Isso significa que, quando fiz backup diferencial pela manhã, não preciso armazenar os enormes dados do t-Log. Posso truncar o Log de transações antes Log Backup? Ou posso evitar completamente o backup t-log?

Questão 4 : Eu realmente não preciso do T-Log completo, mas escolho FULL recovery modeporque SIMPLE modequero dividir o backup de diferentes partições em arquivos diferentes, por razões práticas. EXISTE alguma outra configuração ou você tem sugestões para isso?

Questão 5 : Como os dados dos últimos meses nunca mudam, não preciso fazer backup deles toda vez que faço um backup completo. Existe alguma maneira de misturar backups anteriores (de todos os meses anteriores) e novos backups (de dados primários, operacionais e do mês atual)?

Muito obrigado. (Eu sei que é difícil ser preciso nessas coisas. Se algum ponto não estiver bem explicado, diga-me e tentarei fazer melhor.)

sql-server

2 respostas

  1. Best Answer

    Quando restauro os dados, a ordem deve ser: Restauração do backup completo

    Sim

    Restauração de todos os backups diferenciais desde o último backup completo

    Não. Os backups de diferenças são cumulativos, portanto, apenas o último backup de diferenças deve ser restaurado

    Restauração de todos os backups T-Log desde o último backup completo

    Não. Restaurar backups de log somente desde o backup diferencial.

    Restauração do backup da cauda

    Somente se você participar do envio de logs. Em outros casos, você não cria backups de log final.

    Por exemplo, na quarta-feira: Restauração do backup completo do dia 1 (domingo) Restauração do backup diferencial de 4 (qua) Restauração do backup t-log após quarta até o ponto de recuperação desejado

    Pergunta 1: Por que não é suficiente apenas o t-Log desde o último backup diferencial?

    Deve ser suficiente. Tente restaurar (você precisa praticar a restauração de qualquer maneira) e forneça uma mensagem de erro se não funcionar

    Pergunta 2: Posso restaurar apenas backup completo e diferencial e colocar meu banco de dados online sem restauração de log?

    Sim. Ele estará no estado em que o backup do diferencial foi concluído.

    Pergunta 3: posso evitar completamente o backup t-log?

    Não tenho certeza de qual problema você está tentando resolver. Você tem um arquivo de log enorme? Basicamente, no modo de recuperação total, você deve executar backups de log para evitar que o arquivo de log cresça.

    Questão 4: Eu realmente não preciso do T-Log completo, mas escolho o modo de recuperação COMPLETO em vez do modo SIMPLE porque quero dividir o backup de diferentes partições em arquivos diferentes, por motivos práticos. EXISTE alguma outra configuração ou você tem sugestões para isso?

    Então, você quer dizer que não precisa de restauração pontual, mas usa o modo de recuperação total para backup/restauração parcial. Parece que você precisa de Piecemeal Restores https://learn.microsoft.com/en-us/sql/relational-databases/backup-restore/piecemeal-restores-sql-server?view=sql-server-ver16 Para simplesmente o modo de recuperação, você deve declarar seu grupo de arquivos antigo como somente leitura https://learn.microsoft.com/en-us/sql/t-sql/statements/alter-database-transact-sql-file-and-filegroup-options?view=sql -server-ver16

    Nesse caso, você pode pular grupos de arquivos somente leitura do backup e restauração

    Pergunta 5: Como os dados dos últimos meses nunca mudam, não preciso fazer backup deles toda vez que faço um backup completo. Existe alguma maneira de misturar backups anteriores (de todos os meses anteriores) e novos backups (de dados primários, operacionais e do mês atual)?

    Sim. você deve usar a cláusula READ_WRITE_FILEGROUPS em sua instrução de backup semanal https://learn.microsoft.com/en-us/sql/t-sql/statements/backup-transact-sql?view=sql-server-ver16#read_write_filegroups--- grupo de arquivos---logical_filegroup_name--logical_filegroup_name_var---n--

    No entanto, se você tentar gravar em qualquer objeto no espaço de tabela somente leitura, sua chamada falhará.

    • 1

  2. Não sou um grande especialista em backup, mas vou tentar:

    1. Os backups de log são necessários para restaurar o último ponto no tempo. Cada log faz backup do log tran e o trunca. Portanto, o último arquivo de log terá apenas dados desde o último backup de log. *Acredite que você precisa de todos os backups de log desde o último backup diff, não o último completo.
    2. Não tenho certeza, acredite que você pode, você deve tentar em um ambiente inferior. Você simplesmente perderá todas as alterações após o backup do diff
    3. Você pode executar o comando encolher, mas não liberará o espaço usado. No modo de recuperação total, a única maneira de reduzir o espaço usado no log de tran é o backup.
    4. Acredito que esta seja a questão principal. Você realmente precisa do modo de recuperação total se não precisar ou usar backups de log tran? Se você não se importa em perder dados entre backups full\diff (somente se tiver certeza absoluta), você deve definitivamente reconsiderar o uso de backup completo. Você também pode dividir arquivos de backup em diferentes discos no modo simples. Você simplesmente não salvará backups de log que (de acordo com o que você escreveu) não precisa de qualquer maneira.
    5. Não pense que você pode misturar restaurações entre arquivos de backup diferentes (antigos e novos).

    Tendo dito tudo isso, você deve verificar novamente o que está acontecendo em seus bancos de dados. Os arquivos de log não crescem sozinhos. Se eles fizerem isso significa que algo acontece. Mas, novamente, se eu tivesse certeza absoluta de que não preciso de backups de log, evitaria usar o modo de recuperação total.

    Eu também consideraria o processo de arquivamento - mover todos os dados antigos para outro servidor\db e trabalhar com um banco de dados relativamente pequeno para que os backups não sejam enormes.

    • 0

relate perguntas