Dois-je vraiment conserver les fichiers .LDF?

Chaque mois, nous faisons un aperçu de fin de mois de notre base de données de production. Ces instantanés de fin de mois sont strictement à des fins de rapport, il n'y a jamais d'insertions, de mises à jour ou de suppressions sur eux. Chacun de ces instantanés possède un fichier .MDFet .LDF.

Je veux supprimer les .LDFfichiers et libérer de l'espace sur le serveur. Y a-t-il des raisons pour lesquelles je dois conserver les .LDFfichiers?

Clarification:

Notre base de données de production est recréée chaque nuit à partir d'extraits de fichiers d'un autre système. Nous faisons uniquement rapport hors de la base de données de production ... aucune mise à jour n'est jamais effectuée.

Processus nocturne:
D'après ce que je peux dire ...
Chaque nuit, les tables de la base de données sont tronquées
Les tables sont remplies via une série d'instructions d'insertion en bloc Les
index sont reconstruits

Vous ne devez pas supprimer le fichier journal. Si vous essayez de rattacher un fichier de données sans le journal, SQL Server peut techniquement le recréer, mais il y a quelques problèmes potentiels, comme s'il y avait des transactions ouvertes lorsque la base de données a été détachée. Dans ce cas, vous auriez une perte totale de données.

Consommez de l'espace et ne supprimez pas vos fichiers journaux . Vous demandez des ennuis avec ça.

Consultez cet article sur les journaux de transactions , en particulier la partie «Mauvaise gestion des journaux ».

Comme mentionné dans une autre réponse , vous ne pouvez pas supprimer le fichier journal. Vous pouvez définir la base de données sur READ_ONLY. Avec la base de données dans READ_ONLY, aucune modification n'est autorisée et le fichier journal ne s'agrandira pas. Vous pouvez réduire la taille du fichier journal à une taille minimale et atteindre votre objectif d'une empreinte minimale. Pour définir la base de données dans, READ_ONLYexécutez la commande suivante:

USE master;
GO
ALTER DATABASE databasename SET READ_ONLY;
GO

Vous pouvez modifier la base de données READ_WRITE, apporter les modifications nécessaires, puis la définir à READ_ONLYtout moment.

Le fichier journal est toujours requis pour conserver les propriétés ACID de la base de données.

Le fait est que vous pouvez créer une base de données en utilisant simplement le fichier mdf. Il s'agit de la commande sp_attach_single_file_db (Transact-SQL). Notez qu'il sera supprimé dans une future version de Microsoft SQL Server. Mais, il n'est pas intelligent de supprimer vos fichiers LDF. Shark a raison "Vous demandez des ennuis avec ça." Un autre point de vue - vos fichiers ldf sont-ils énormes? S'ils le sont, vous pouvez faire quelque chose pour eux.

1. Définissez votre base de données sur un modèle de récupération simple . Vous ne pouvez le faire que si vous ne souhaitez pas annuler les transactions
2. Au lieu de créer des fichiers MDF et LDF, créez un fichier de sauvegarde de base de données complète (.BAK). Ce sera plus petit tnan MDF + LDF

Voici la solution que j'ai trouvée pour réduire les fichiers LDF.

1. Détacher la base de données
2. Renommez le fichier LDF en * _old.ldf
3. Attacher une base de données
4. Retirez la référence du LDF manquant

Cela recrée un fichier LDF d'une taille de 504 Ko.

5. Supprimer * _old.ldf
6. Poubelle de recyclage vide

Cela a récupéré une quantité importante d'espace disque sur le serveur. Cela fonctionne pour nous car toutes ces bases de données sont UNIQUEMENT des bases de données de rapports statiques. Aucune insertion, mise à jour ou suppression ne sera jamais effectuée sur ces bases de données.

MISE À JOUR 2019-09-24: Oui, je suis d'accord, c'est une très mauvaise idée. J'ai arrêté de le faire presque immédiatement. J'ai reconstruit tous les index en utilisant un facteur de remplissage de 100. Rétrécissez uniquement les fichiers .ldf. Et changé toutes les bases de données pour qu'elles soient LISEES UNIQUEMENT.