transaction log full

[JohnNerge]

I received an error 999999 when I tried to run a Delete Features within ArcMap on an enterprise feature class of about 30,000 records saying that the database transaction log was full. I shrank the log file but continued to get the error. When I ran Delete Features on a different feature class of about 3,600 records I had no problem.

I've only had issues like this with the database in the last seven days. The transaction log became full when I was doing some large field calculations, but shrinking the .ldf file worked just fine then.

Is there something else I need to do besides shrinking the associated .ldf log file to clear this up?

Thanks in advance,
John Nerge

[ATTACH=CONFIG]21040[/ATTACH]

[ThomasColson]

What Database are you using? I'm assuming SQL, you should specify that when posting to the SDE forum. Usually taking a FULL (not differential) backup will clear that, as well as rebuilding/reorganizing any indexes on FC's that have seen heavy edits. Finally, you might want to consider moving the log file to another disk array.

[JohnNerge]

Sorry, yes it's a SQL database. Thanks for the tips.

[ShannonShields · Accepted solution]

Are you backing up your transaction logs or just the database? Transaction log backups are going to enable log truncations, keeping the size manageable; full database backups do not. Way more than you probably want to know about transaction logs and how to manage and maintain them can be found here: http://msdn.microsoft.com/en-us/library/ms345419(v=sql.105).aspx. The key piece to take away though, is to backup them up fairly frequently.

-Shannon

[JohnNerge]

They are, but I don't know if they're being truncated too. I'm going to do a deep dive into the maintenance being done on the server. Thanks again.

[ThomasColson]

SQL transaction logs are automatically truncated with a full backup. Doing a tlog-only back up means you're doing a differential backup. Pros and cons to that: with differential, your backup media storage is cheaper, as well as backup time, but recovery in case of a failure is horrific in terms of complexity. A daily full backup suits most SDE installations, as well a pulling a full before significant data changes. Ask you're whomever is maintaining your SQL to pull a full back up in either case, and see if that error goes away.

[JohnNerge]

Still working out the kinks, but the issue was that the transaction log file was set to a small initial size with no autogrowth allowed. I've increased the log file size and will probably set some restricted growth allowances too. The recovery model was and is going to remain set to full. Thanks again, everyone.