Ai-je vraiment besoin de garder .ldf?

Question

Chaque mois, nous faisons une fin de snapshot mois de notre base de données de production. Ces instantanés de fin de mois sont strictement à des fins d'information, il n'y a pas de mises à jour ou insertions, suppressions jamais effectuées sur eux. Chacun de ces clichés a un fichier .MDF et .LDF.

Je veux supprimer les fichiers .LDF et libérer de l'espace sur le serveur. Y a-t-il des raisons pour lesquelles j'ai besoin de garder les fichiers .LDF?

Précision:

Notre base de données de production est recréée chaque soir à partir d'extraits de fichiers hors d'un autre système. Nous ne présentons hors de la base de données de production ... aucune mise à jour ne sont jamais fait.

nuit processus: D'après ce que je peux dire ...
Chaque soir, les tables Databse sont tronqués
Les tables sont à travers une série de produits en vrac insérer des instructions
Les index sont reconstruits

Answer 1

Here is the solution I came up with to shrink the LDF files.

1. Detach Database
2. Rename LDF file to *_old.ldf
3. Attach Database
4. Remove the refernece to the missing LDF

This recreates an LDF file that is 504K in size.

5. Delete *_old.ldf
6. Empty recycle bin

This has reclaimed a significant amount of disk space on the server. It works for us because all of these databases are static reporting databases ONLY. No Inserts, Updates or Deletes will ever be performed against these databases.

UPDATE 2019-09-24: Yeah, I agree this is a really bad idea. I stopped doing this almost immediately. I have rebuilt all the indexes using a fill factor of 100. Shrunk only the .ldf files. And changed all the databases to be READ ONLY.

Answer 2

Vous ne devez pas supprimer le fichier journal. Si vous essayez de remettre en place un fichier de données sans le journal, SQL Server peut recréer techniquement, 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é. Dans ce cas, vous auriez la perte totale des données.

Consommez l'espace, et ne supprimez pas vos fichiers journaux . Vous demandez des ennuis avec cela.

Voir cet article sur journaux de transactions, en particulier la partie "Log Mauvaise gestion".

Answer 3

Comme mentionné dans autre réponse, vous ne pouvez pas supprimer le fichier journal. Ce que vous pouvez faire est de définir la base de données READ_ONLY. Avec la base de données READ_ONLY, aucune modification ne est autorisée et le fichier journal ne se développera pas. Vous pouvez réduire la taille du fichier journal à une taille minimale et atteindre votre objectif d'un encombrement minimal. Pour définir la base de données READ_ONLY exécutez la commande suivante:

USE master;
GO
ALTER DATABASE databasename SET READ_ONLY;
GO

Vous pouvez modifier l'arrière de base de données READ_WRITE, apportez les modifications nécessaires, puis réglez-le READ_ONLY chaque fois que vous avez besoin.

Le fichier journal est toujours nécessaire pour maintenir les propriétés ACID de la base de données.

Answer 4

The fact is that you can create a database just using the mdf file. It's the sp_attach_single_file_db (Transact-SQL) command. Note that it will be removed in a future version of Microsoft SQL Server. But, it's not smart to delete your LDF files. Shark is right 'You're asking for trouble with that.' Another point of view - are your ldf files huge? If they are, you can do something about them.

1. Set your database to Simple recovery model. You can do this only if you don't want to roll back the transactions
2. Instead of making MDF and LDF files, create a full database backup (.BAK) file. It will be smaller tnan MDF+LDF