0

So I have this SharePoint 2007 site that is basically trash. I'm supposed to just toss it, but I'm in need of copying all of the data in form of traditional files and folders from certain projects. And since the transaction log is full, it's so damn slow.

Even opening SharePoint takes up to 15 minutes, or it won't open at all. Copying of files is extremely slow. So I'm in need of a quick fix here. Just to be able to copy out some files and folders. I don't need to fix the problem per se.

What can I do to fix it temporarily to be able to copy out the data?

HopelessN00b
  • 53,385
  • 32
  • 133
  • 208
Kenny Bones
  • 119
  • 2
  • 3
  • 14

2 Answers2

0

SharePoint is actually a database (hence the transaction logs), so the quickest way I can think of to access the site temporarily for data transfer is to open MSSQL Management Studio, open the SharePoint database as a database, and dump the data you need out that way. (Either by moving the database file, or actually extracting the data).

You could also fix the problem "for good" by taking the database offline so you can commit the transaction logs to the database and then delete them from disk, and (from the sounds of things) run a database defragmentation. Those two things should make Sharepoint run a lot faster, so it's not painfully slow accessing the site. The time it takes to do so would probably be a few hours at a minimum (varying greatly based on the size of the database), but worst case scenario, you could leave the database operations running all day/overnight and extract the data tomorrow.

HopelessN00b
  • 53,385
  • 32
  • 133
  • 208
0

Unless your server is out of disk space having a large transaction log file won't necessarily make the server slow. Also just because the log file is large it doesn't mean it is full.

If you haven't already you can run DBCC SQLPERF (LOGSPACE) in management studio which will show you if the log is actually full or just big. If the log is full then you should be able to force it to truncate by performing a log backup. I'd probably recommend you first do a full database backup, then do a transaction log backup. After that then the log shouldn't be full anymore (i.e. truncated) and you can resize it if you need to with DBCC SHRINKFILE.

Factors That Can Delay Log Truncation

Ultimately I'm not sure if this will actually fix your SharePoint performance issue - but it should free up some space for you on the server.

shiitake
  • 379
  • 1
  • 7