Skip to main content

Shrinking WSS (Sharepoint) SQL Server Log Files

Yesterday, while migrating a source repository from StarTeam to TFS, I received the following error:
"TF30042: The database is full. Contact your Team Foundation Server administrator."
Excuse you? Sure enough, my 100+ GB drive was full on the server. But I'd only migrated around 1000 items. Surely SQL wasn't consuming 100MB per file.

Turns out (yes, there was a lot of crud on the drive but...) the majority of the space, almost 40GB was being consumed by the Windows Sharepoint Services WSS Content data and log SQL Server files. Huh? I still need to investigate and understand why this portal, which is 100% unused, grew so large. Regardless, here's what I did to resolve:

  1. Since this is not yet a production database, I flipped the SQL recovery option from Full to Simple for WSS Content and several other databases. Detail here and here.
  2. Executed the maintenance plan for all the databases to get backups and clear out some of these files. That didn't help much. The Auto_Shrink == true didn't assist us in trimming the file sizes.
  3. Executed the following SQL as described here to understand the space available.
  4. Executed the following SQL as described here to shrink the log file down to 1GB (1000MB)
  5. Checked the data
  6. Performed a second backup for safe keeping
In the end, I recovered more than 80% of the previously consumed hard drive. Check with your DBA and / or your Sharepoint admin should you encounter this issue in a production environment. I had the luxury of being a bit cavalier because I was in a near-empty, non-production environment.

Comments

Halcyon Nancy said…
Thanks for the posting. Saved my bacon. I had this happen on a production server. The SharePoint databases were set to Simple, but the WSS databases were all set to Full. Shrinking thier log files got me half the drive back. Whew!

Popular posts from this blog

TFS Reports Out of Date

You may have noticed it takes a while for Team Foundation Server (TFS) reports to reflect changes you've made to work items or builds. Let me guess...about an hour, right? Out of the box, TFS is set to refresh the data warehouse from its transactional store every 60 minutes. How do I change the frequency of the data warehouse refresh? Browse to the TFS Controller Web Service on your TFS application tier server within IE at: http://localhost:8080/Warehouse/v1.0/warehousecontroller.asmx Select the ChangeSetting option Enter RunIntervalSeconds for the settingId and the desired number of seconds for newValue (300 for 5 minutes...5*60) Select Invoke How do I force a data warehouse refresh? Two methods here: either via the above web service or using SQL Server Management Studio. Via the web service: Browse to the TFS Controller Web Service within IE at: http://localhost:8080/Warehouse/v1.0/warehousecontroller.asmx Select the Run option Click Invo...

Rollback a Ooops in TFS with TFPT Rollback

Rhut roe, Raggie. You just checked in a merge operation affecting 100's of files in TFS against the wrong branch. Ooops. Well, you can simply roll it back, right? Select the folder in Source Control Explorer and...hey, where's the Rollback? Rollback isn't supported in TFS natively. However, it is supported within the Power Tools leveraging the command-line TFPT.exe utility. It's fairly straightforward to revert back to a previous version--with one caveot. First, download and install the Team Foundation Power Tools 2008 on your workstation. Before proceeding, let's create a workspace dedicated to the rollback. To "true up" the workspace, the rollback operation will peform a Get Latest for every file in your current workspace. This can consume hours (and many GB) with a broad workspace mapping. To work around this, I create a temporary workspace targeted at just the area of source I need to roll back. So let's drill down on our scenario... I'm worki...

VSTS 2008 Data-Driven Web Test

During a client demo this afternoon, I mind-blanked on creating a data-driven web test. Sure enough, I stepped out of the client offices and figured it out. Super. But, I think it's counterintuitive enough to outline in a blog post (...trying to make myself feel better ;-). Somewhat in my defense, I was thinking about data-driven unit tests. These, IMO, are easy to implement. Data-driven web tests are a bit more effort and challenging. Create a web test: Right-mouse on your test project selecting Add >> Web Test. Use the browser recorder to capture your web test scenario. Let's assume you're submitting an age and credit rating to an insurance rate calculator...similar to the screen capture below: Create a table or CSV file (comma-delimited...just use Excel and save as CSV) with relevant headings for your inputs and expected values: From Solution Explorer, double-click on your web test. In the main window, right-mouse on your web test selecting Add Data Sou...