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.
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.
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...
I wanted to thank Microsoft for awarding me with an MVP award for 2008. It is such an awesome program and an honor to be included in such a great group of professionals. I really appreciate the friendships and relationships that are a part of this prestigous program. Thanks again for the recognition and congratulations to all of the MVP award receipients.
Scott Lock