Safely deleting a SQL Server log file (.LDF)

Question

• I can make sure my app is in a consistent state.
• I can rollback all the uncompleted transactions if any (just in case) it's ok
• I can DETACH the database

What do I need the log file for after that?

I'm particularly talking about a "highly controlled" environment. So, the real question is: How can I explicitly force everything to be alright in order to avoid possible data loss? Does anyone here have experience doing this kind of operation?

UPDATE

The reason for this is that I'm not a fan of immense log files. The highly controlled environment is my PC running a single app in a single-user mode. I'm the developer of this app and I have complete control over the code changes. I'd prefer to delete rather than SHRINK so please do not suggest that I simply SHRINK the file.

UDATE 2 -- PRACTICE

I've had this process in production for more than half a year without any issue.

Answer 1

Just to add to the existing answers.

The SQL Server 2008 Internals Book (pp 175-177) implies that detaching the database, deleting the log file and reattaching the mdf file ought to be quite safe as it says.

Detaching a database ensures that no incomplete transactions are in the database and that there are no dirty pages for this database in memory. If these conditions cannot be met, the detach operation fails ... one benefit of using the sp_detach_db procedure is that SQL Server records the fact that the database was shut down cleanly ... This can be a quick way to shrink a log file that has become much larger than you would like

However this does not seem to be the case. This blog post has a demo of this method leaving your database broken too.

Answer 2

You can force a ROLLBACK though by switching the DB to RESTRICTED using WITH ROLLBACK IMMEDIATE. See ALTER DATABASE. You can't force COMMIT (as per your SO question)

Then...

• If you delete the LDF (SQL Server shut down), your database comes back "suspect".
• If you detach+delete, attach the MDF by itself, the LDF is re-created.

Note: for the millionth time, you need an LDF. In case you ask

Answer 3

After you dig yourself out of this hole, please, read this and learn from it. Logs are an essential part of how SQL Server works. You can't just get rid of them. But you can manage them appropriately. You're probably working off the default settings, which create all databases in Full Recovery mode, meaning, the logs are going to grow. Change this after you create the database. Other than that, @gbn up there has the answer.

Answer 4

To maintain ACID transactions in SQL server, the SQL server architecture relies on the use of data files and log files.

That is why you need the log file.

For the needs of your application maybe all you need is a flat file storage mechanism.

Answer 5

Surely you can delete your LDF file. You even may to choose to delete the sql server!

The only question - why do you need to do this?

If you drop the ldf's for just not to transfer them to the other server - copy data files, try to attach them and only if you succeed - delete old files, even with data files together.

You should not delete LDF files until you successfully raised up the DB on the side without LDF (and sql server surely recreates them). Or at least - tested this behavior.

Answer 6

TL:DR the ldf file is required, because SQL documents everything (including allowing you to query) before it actually does anything.

SQL needs the ldf (log file) to support fault tolerance answer by StanleyJohns.

No matter how controlled your environment, there will be changes inside of your SQL database; failed logins, restarts from patching, plan updates with queries, many things create changes that you may not be aware of.

SQL is designed so if the power goes out during a change (no matter how small) it will be able to recover. To meet this it creates entries in the ldf file. If the system is in FULL recover, all off those entries are saved, if the system is in SIMPLE recovery, those entries are deleted when the change is completed or COMMITTED. To accomplish this, before any changes are made they are entered in the .ldf.

In the event of a power outage, everything in the .ldf that has not committed will be rolled back.

If ldf space is an issue read Why Does the Transaction Log Keep Growing or Run Out of Space?