Não sou especialista em DBA/SQL, então, desculpe-me se este for o fórum errado para postar.
Há um problema com nosso banco de dados de produção em que os arquivos de log não estão sendo armazenados no formato LDF. O DBA deseja excluir nosso banco de dados de produção e restaurar um backup completo para corrigir o problema. Esta é uma prática recomendada? Há várias conexões ativas de aplicativos com esse banco de dados. Essas conexões são reconectadas automaticamente quando o banco de dados é restaurado?
Há alguns mal-entendidos na redação de suas perguntas, mas darei uma explicação rápida para cada uma delas.
Depende de como os aplicativos foram construídos/programados. Se uma conexão existente for interrompida no lado do servidor e se um tratamento de erros tiver sido implementado no aplicativo que procura conexões interrompidas, seu aplicativo poderá se reconectar com êxito ao seu banco de dados (servidor).
O Log de Transações do banco de dados será sempre armazenado no formato "LDF". O arquivo em si pode não ter uma extensão que o indique como um
*.ldfarquivo. Ou dito de outra forma: o Mecanismo de Banco de Dados do SQL Server sempre gravará as informações referentes às transações no arquivo de log de transações, independentemente do nome do arquivo.A melhor prática seria criar o banco de dados com os nomes de arquivo desejados em primeiro lugar.
Fazer backup do banco de dados e restaurá-lo enquanto altera os nomes dos arquivos é possivelmente a maneira mais fácil de "renomear" os arquivos relevantes.
A segunda melhor opção seria desanexar o banco de dados e, em seguida, renomear os arquivos e trazer o banco de dados de volta usando a
CREATE DATABASE .... FOR ATTACHsintaxe mencionada nesta resposta Renomear o log SQL e o arquivo mestre do banco de dadosOutro método para renomear ou mover arquivos de banco de dados do usuário é detalhado no Procedimento de realocação planejada na documentação do SQL Server. Resumindo, ...
ALTER DATABASE,ALTER DATABASE...SET OFFLINE,ALTER DATABASE...SET ONLINE_No entanto, não importa qual solução você usa, pois o banco de dados estará indisponível em qualquer caso.
Veja minha primeira resposta à sua pergunta inicial.
De jeito nenhum!
Restaurar um banco de dados é, talvez surpreendentemente, um processo destrutivo .
Enquanto isso acontece, suas tabelas podem ou não existir e podem ou não conter dados [completos].
Por esse motivo, todas as conexões do [Aplicativo] devem ser cortadas no início do processo e nenhuma nova conexão será permitida até que o processo de restauração seja concluído e as verificações tenham sido realizadas nos dados restaurados.
Esta não é uma atividade a ser tomada de ânimo leve (e seu DBA deve saber disso).
Eles podem não ser armazenados em arquivos nomeados com extensões .LDF , mas serão armazenados no formato interno correto. Seu banco de dados simplesmente não funcionaria se esse não fosse o caso (a menos que esteja sendo executado sem nenhum registro, o que, para um sistema de produção , é uma "ofensa suspensa", no meu livro).
Tenho certeza de que os arquivos de log do SqlServer não podem ser renomeados enquanto o banco de dados está em execução, portanto, restaurar o backup não corrigirá o "problema de nomenclatura de arquivos" que, como eu disse antes, não é realmente um problema.
Se realmente houver um problema com o subsistema de registro, então esse é um problema muito maior que precisa ser resolvido com urgência, mas, novamente, destruir todos os dados transacionais armazenados desde o último backup não é a resposta.
Na verdade, se os logs de transações realmente não estiverem sendo registrados corretamente, então o único backup para o qual eles poderão restaurar será o último backup "completo", não importa há quanto tempo ele foi feito!
Interromper o banco de dados, fazer backup imediatamente, alterar o modo de registro e reiniciar o banco de dados é tudo o que você precisa fazer.