O SQL na verdade não redimensiona o log após um backup de log - em vez disso, ele apenas altera os metadados internos para marcar partes do log (chamadas Virtual Log Files ou VLFs) que podem ser reutilizadas. Esse processo é chamado de truncamento de log. Portanto, seu arquivo de log crescerá se não houver VLFs livres, mas nunca diminuirá, a menos que você diga manualmente ao SQL Server para fazer isso.
Como o tamanho do log do banco de dados é 10Gb, a restauração do backup também criará um arquivo de log de 10Gb, independentemente da quantidade realmente em uso. O mesmo se aplica a qualquer arquivo de dados.
Você pode reduzir o arquivo de registro usando o comando ' DBCC SHRINKFILE ' - embora, a menos que você É certo que o log não vai crescer para 10Gb novamente, então eu recomendo contra fazê-lo (há um impacto no desempenho do crescimento do arquivo). Transações de longa duração ou atividades de manutenção de banco de dados podem consumir muito log de transações, portanto vale a pena descobrir por que o log está em 10Gb antes de encolher.
Para responder às suas três perguntas:
Existe algum tipo de backup que um usuário / administrador no site possa realizar interferindo ou interrompendo o envio de logs?
Sim - se você interromper a cadeia de backup fazendo o backup do log em um destino fora da configuração de envio de log, resultando na não aplicação do backup no servidor secundário. Você deve usar backups COPY_ONLY nessa situação, pois eles não afetarão a cadeia de log. Isso se aplica apenas aos backups de log, pois os backups completos não truncam o log.
Se você usar o envio de logs, isso é suficiente para garantir que os logs não cresçam continuamente ou ainda seja necessário fazer o backup dos logs (usando, por exemplo, um plano de manutenção)?
Isso deve estar bem, a menos que exista algo mais que impeça que o log seja truncado, como espelhamento de banco de dados, transações de longa execução, replicação ou mesmo criação de instantâneo de banco de dados. A maneira de descobrir por que seu log não está sendo truncado é examinar a coluna log_reuse_wait_desc em sys.databases .
Também é possível (mas improvável) que a tarefa de backup para o envio de logs esteja fazendo backups usando COPY_ONLY / NO_TRUNCATE, o que significa que o arquivo de log aumentará continuamente quando estiver cheio.
Esse não é muito importante, mas se eu tiver um backup que precise de mais espaço para um arquivo de log do que o disponível, existe alguma maneira de restaurá-lo sem o arquivo de log ou sem corrigir o problema? na origem e obtendo um novo backup.
Se você reduzir o arquivo de log e fizer um backup completo, quando for restaurá-lo, o SQL Server criará o banco de dados usando o arquivo de log menor.
Se você não puder reduzir, mas estiver restaurando para um servidor de desenvolvimento / teste, poderá montar um armazenamento temporário e usar 'WITH MOVE' na instrução RESTORE para mover o arquivo de log para essa unidade, depois reduzir o log e mover o arquivo de log fora do armazenamento temporário (avisos sobre se você deve reduzir o log ou ainda não se aplicam!).