up vote 1 down vote favorite
share [g+] share [fb]

It seems I had someone trying to perform brute-force login attempts on my SQL 2005 server. As a result, the log file has grown to about 55 gigs and sits in C:\Windows\SYSMSI\SSEE\MSSQL.2005\MSSQL\Data.

The file itself is called WSS_Content_0b8dae5814114114b874e35ea7ba795b_log.LDF and appears to be currently used.

I'm unclear on how to clear or truncate this LDF file. Thanks!

EDIT: http://i.stack.imgur.com/yfdRG.jpg

link|improve this question
feedback

3 Answers

up vote 3 down vote accepted

Open SQL Server Management Studio, connect to the SQL server, find the relevant database. Right click the DB, Tasks->Shrink->Files. File type: Log, verify the file name. It will display how much is used/free.

If it's all used, you should backup the database so that it's no longer using the log file. If it's mostly empty you can proceed with releasing the unused space (or whatever portion you'd like).

If you don't want to backup the DB, you can change the recovery model (right click DB, Properties, Options tab, Recovery Model) to something simpler, or off all together if you want.

link|improve this answer
This appears to be the windows internal database, and I cannot seem to connect to it via SSMS. I'm using the defualt connection of: .\SERVER\MICROSOFT##SSEE – Ryan Peters Mar 23 '11 at 19:03
You'll have to use SharePoint's backup procedure then. IIRC it's on the SP Admin site. Running the backup should auto shrink the log. – Chris S♦ Mar 23 '11 at 19:05
I can't just clear the log? I can't do a backup because I don't have 60 gigs free on that drive. – Ryan Peters Mar 23 '11 at 19:11
According to this article, you should be able to connect via SSMS. Honestly, we don't use the "Internal DB" so I don't know much about it other than it's a version of SQL Express Edition. – Chris S♦ Mar 23 '11 at 19:28
I used your method. I found a way to log into the SSEE database from here. channel9.msdn.com/Forums/TechOff/…. Once I got in, I could run the shrink method on that database log. Thanks. – Ryan Peters Mar 23 '11 at 19:36
feedback
up vote 0 down vote

That is the log file for a Sharepoint content database. It is in use because the associated database is attached and the SQL service is running.

How do you know that the login attempts are directly responsible for the log file being large? How active is your Sharepoint site?

link|improve this answer
I don't use the sharepoint services. I use TFS, but do not use sharepoint. I'm assuming it's due to that because I'm able to view the log from SSMS, which corresponds to the same data as the LDF and there are about 100k attempts. – Ryan Peters Mar 23 '11 at 18:58
Here is an example: i.imgur.com/d0Bn3.jpg – Ryan Peters Mar 23 '11 at 19:01
TFS uses Sharepoint. – joeqwerty Mar 23 '11 at 19:19
feedback
up vote 0 down vote

I'm pretty sure that logins/login attempts don't get logged to the SQL transaction log. The cause is most likely due to the fact that the database is using the Full Recovery model and log management is not occurring.

link|improve this answer
feedback

Your Answer

 
or
required, but never shown
discard

Not the answer you're looking for? Browse other questions tagged or ask your own question.