SQL Server

Timeout Error When Upgrading SPS 2003 Content Database

Scott Lock — Fri, 25 Jul 2008 04:34:10 GMT

Man, this issue has been kicking my butt all day. We've been working on a SharePoint 2003 upgrade (testing) and got to the final content database. Life was good up to this point. 110GB of content had upgraded and there were just a few hiccups, mostly related to size. Then, it came. The nasty, evil, dispicable:

Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.

Over and Over...

Basically what's happening from what we can tell is SQL Server is choking on the large document library table copy (dbo.doc) and (dbo.docversion). The temporary database (WSSUS_) log file timesout during autogrowth. It just can't keep up with the upgrade.

I'm trying again...this time I've set the autogrowth to grow by MB instead of percentage. This is a tricky to get set simply because this database isn't created until the process starts.

UPDATE

The solution turned out to be relatively simple. I grew the transaction log for the WSSUS_ database to 70GB which effectively stoped the autogrow thrashing. After doing this, the process completed as expected. The trick is that you have to run the script:

The catch is that you have to run it after the WSSUS database has been created. I simply watched in Managment Studio until I saw the database in the list and ran the script. It took 13 minutes for my hardward to execute the query.

ALTER

DATABASE [WSSUP_Temp_675cfeec-6d15-414a-aae2-a3deabbbf01b] MODIFY FILE ( NAME = N'WSSUP_Temp_675cfeec-6d15-414a-aae2-a3deabbbf01b_log', SIZE = 73400320KB , FILEGROWTH = 10240KB )

We also changed the default file location to a local disk rather than a SAN connected volume. This may have had some impact, but did not solve the problem.

Database gotchas when upgrading SPS 2003 to MOSS

Scott Lock — Tue, 22 Jul 2008 22:10:12 GMT

Again, maybe old news but I thought I would post something interesting that happened during a recent upgrade from SPS 2003 to MOSS. SharePoint is very finicky when it comes to database transactions and sizing during the gradual upgrade process. Here are a couple of things to note:

1. Make sure you have enough size - When upgrading a site that had about 150GB in content, we needed about 500GB in space to complete the migration.

2. Make sure you know where your _Pair DB's Are - SharePoint for some reason didn't put the _Pair db's on the default data and log file locations (C:\) and had to be moved to a larger volume. This caused the upgrade to fail with space issues.

3. Make sure to set the _Pair data and log files to AutoGrow - Now that you have the right amount of space, make sure that you configure the new databases to grow correctly. Large content databases will have large transactions when copying the sitecollections. This can also lead to things like timeouts and space issues. You should also consider setting the recovery model to "Simple" during the migration to keep things tight.

Just some things to think about.

SharePoint gradual upgrade disabled when using a SQL instance named SharePoint

Scott Lock — Tue, 22 Jul 2008 22:03:55 GMT

This may be old news, but we just hit this issue the other day. If you try to upgrade an instance of SharePoint Portal Server 2003 or WSS 2.0 that is running on a named instance of SQL Server called "SharePoint", the gradual upgrade option is greyed out. It turns out that this is because the installer thinks that you are trying to upgrade an instance of MSDE. Changing the instance name to something other than "SharePoint" does the trick. Talk about hardcoding something...

SQL Server Client Working on Vista, Not connected to a domain

Scott Lock — Wed, 19 Dec 2007 20:40:17 GMT

To continue in the traditiion of trackbacks, and since I can't seem to find an orginal post in my body, I thought that I would share this one with you. Jason Follas psted a solution on how to get SQL Client, running on Vista, to use different credentials when connecting to a SQL Server using Windows Authentication. Basically, there are a ton of posts out there, but this is the ONLY one that that I could find that had the solution. Here's the link to the full explantion: Making SQL Server Management Server work on Windows Vista

Here's the solution - Create a "runas.exe" shortcut with the following configuration:

C:\Windows\System32\runas.exe /netonly /user:domainx\myusername
   "C:\Program Files\Microsoft SQL Server\90\Tools\Binn\VSShell\Common7\IDE\SqlWb.exe"

Works like a charm! Thank's Jason!