My current day job is developing SharePoint-based web applications. On Thursday, September 11 (coincidence), the SharePoint site became unresponsive. It was not storing any new data, but viewing existing data was still possible. This was important as I have end-users that rely on reports stored in Document Libraries. The daily reports would not save onto the website.

I’m sure that this article is SQL Server Administration 101 for most folks. For those diving into SharePoint with no DBA, this could be a lifesaver.

Table of Contents

Chapter 1: Transaction Log Deletion – what happens when I lost the WSS_Content transaction log
Chapter 2: The Recovery – the steps to recovering the corrupt MDF file
Chapter 3: Prevention – best practices for database and transaction log backup and truncation

Chapter 1: Transaction Log Deletion

After crawling around the servers a bit, I found out it was a disk space issue. Ends up that the Data drive for the SQL server that stores my SharePoint databases was full. I noticed a 136GB transaction log (LDF) file. I have not had formal SQL server training and the bulk of my experience is in the Linux world, so I was unsure of my next steps. Googling around I found people with similar issues and learned about sp_detach_db. I began to scramble as 8am was near and people would be coming into work. The detach was not working quickly enough. I shut down my SQL server processes and deleted the LDF file to start over on the transaction log. Little did I know that I just entered myself into a world of pain.

When the SQL server was brought back online, to my surprise, the WSS_Content database was toast. It would not allow access to it, and said that the database was corrupt. It was not shutdown cleanly… awesome news… lesson learned…

So, my first reaction is to call IT and ask for a restore of that file. More awesome news: “yea, the backups have been saying they were successful, but that file hasn’t been backed up…” Now I am worrying! I read further on Google results. I see forum replies saying things like, “well chances are if you lost your LDF file and the MDF won’t attach, the data is corrupt and you cannot get it back.”

I spend most of the day trying to find the right solution. Many of the answers on Google got me close, but did not work in the end. I find a piece of software called Stellar Phoenix SQL Database Recovery for $420. I think, well, I’ll try it and if it doesn’t work, I’ll get a refund. First problem I run into is the purchasing of the software. It takes 4 hours and 5 phone calls to get the software installed and the license working. They have a sales website that knows nothing about the software and their support team had me waiting on E-mails that never showed up. Again, lesson learned…

So, I finally have the software in hand. I rescue the MDF file, but to no avail. It transformed my 25GB MDF file into a 7MB MDF file. I apply for a refund (which is another story altogether). Soon, I learned to stop worrying and love SQL Server.

Chapter 2: The Recovery

At this point it is getting late in the evening and I am not getting anywhere. My brain is becoming mush, so I call it a night. The next morning I network around the office to learn of a colleague that is a SQL Server expert. She walks me through these steps and to my avail, the database comes back to life and SharePoint is happy. The icing on the cake is that I lost no data!

1. Make a copy of the MDF file to a remote location just in case.
2. Rename the MDF file on the SQL server.
3. Run: CREATE DATABASE WSS_Content (Double check that it puts the MDF and LDF files in the same location as they were before. Add the proper options if need be.)
4. Shutdown the SQL server.
5. Copy original database MDF file over the newly created MDF file.
6. Rename, Move or Delete the newly create LDF file to “hide” it from SQL.
7. Start SQL server.
8. Run: EXEC('ALTER DATABASE ''[WSS_Content]'' SET EMERGENCY');
9. Run: ALTER DATABASE [WSS_Content] SET SINGLE_USER;
10. Run: DBCC CHECKDB ([WSS_Content], REPAIR_ALLOW_DATA_LOSS) WITH NO_INFOMSGS;
11. Run: ALTER DATABASE [WSS_Content] SET MULTI_USER;

Chapter 3: Prevention

At this point, my transaction log would still grow to enormous proportions without the proper practices. My colleague and SQL Server expert showed me how to run backups and truncate the transaction logs daily.

• Run full database backups that overwrite themselves the next day.
  • Create a job for running full backups as so for each database that needs to be backed up:
    BACKUP DATABASE [WSS_Content] TO DISK='C:PATHTOBACKUP[WSS_Content].bak' WITH INIT
  • If the database needs to have the transaction log truncated, run this after the BACKUP DATABASE command:
    BACKUP LOG [WSS_Content] TO DISK='C:PATHTOBACKUP[WSS_Content]_LOG.bak'
  • Schedule the job to run once nightly such that it will end prior to any tape backups.
• Optional, run transaction log backups every 4 hours to ensure that data from 4 hours ago can be recovered in case of a problem throughout the day.
  • For each database that needs to have the transaction log backed up and truncated run:
    BACKUP LOG [WSS_Content] TO DISK='C:PATHTOBACKUP[WSS_Content]_LOG.bak'
  • Schedule the job to run every 4 hours and stop prior to the full database backup above.

Share/Save