Home > Uncategorized > Time out during gradual upgrade to MOSS 2007

Time out during gradual upgrade to MOSS 2007

Situation: Upgrading a large site collection from SPS 2003 to MOSS 2007 for a completely virtualized medium server farm environment. In brief, when you have a large site collection, the data copy for gradual upgrade may time out.


Upgrade log file:[SPSqlCommandFactory] [DEBUG] [10/20/2006 6:26:00 AM]: SqlCommand.CommandTimeout = 23635
[SPSiteCollectionCopier] [DEBUG] [10/20/2006 6:26:00 AM]: Copying table AllDocStreams.
[SPSiteCollectionCopier] [ERROR] [10/20/2006 1:00:00 PM]: Failed copying site SPSite Url=http://devhmoss.
[SPSiteCollectionCopier] [ERROR] [10/20/2006 1:00:00 PM]: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.
[SPSiteCollectionCopier] [ERROR] [10/20/2006 1:00:00 PM]: at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection)
at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj)
at System.Data.SqlClient.TdsParserStateObject.ReadSniError(TdsParserStateObject stateObj, UInt32 error)
at System.Data.SqlClient.TdsParserStateObject.ReadSni(DbAsyncResult asyncResult, TdsParserStateObject stateObj)
at System.Data.SqlClient.TdsParserStateObject.ReadPacket(Int32 bytesExpected)
at System.Data.SqlClient.TdsParserStateObject.ReadBuffer()
at System.Data.SqlClient.TdsParserStateObject.ReadByte()
at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj)
at System.Data.SqlClient.SqlCommand.RunExecuteNonQueryTds(String methodName, Boolean async)
at System.Data.SqlClient.SqlCommand.InternalExecuteNonQuery(DbAsyncResult result, String methodName, Boolean sendToPipe)
at System.Data.SqlClient.SqlCommand.ExecuteNonQuery()
at Microsoft.SharePoint.Utilities.SqlSession.ExecuteNonQuery(SqlCommand command)
at Microsoft.SharePoint.Upgrade.SPSiteCollectionMigrator.SPBaseSiteCollectionCopier.Copy()
[SPManager] [ERROR] [10/20/2006 1:30:00 PM]: Migrate [SPMigratableSiteCollection Parent=SPManager] failed.
[SPManager] [ERROR] [10/20/2006 1:30:00 PM]: This SqlTransaction has completed; it is no longer usable.
[SPManager] [ERROR] [10/20/2006 1:30:00 PM]: at System.Data.SqlClient.SqlTransaction.ZombieCheck()
at System.Data.SqlClient.SqlTransaction.Rollback(String transactionName)
at Microsoft.SharePoint.Utilities.TransactionalSqlSession.Rollback()
at Microsoft.SharePoint.Upgrade.SPSiteCollectionMigrator.SPBaseSiteCollectionCopier.Copy()
at Microsoft.SharePoint.Upgrade.SPSiteCollectionMigrator.Migrate()
at Microsoft.SharePoint.Upgrade.SPManager.Migrate(Object o, Boolean bRecurse)
[SPManager] [DEBUG] [10/20/2006 1:30:00 PM]: Elapsed time migrating [SPMigratableSiteCollection Parent=SPManager]: 21:16:28.3861356.
[SPManager] [INFO] [10/20/2006 1:30:00 PM]: Gradual Upgrade session finishes. root object = SPMigratableSiteCollection Parent=SPManager, recursive = True. 2 errors and 0 warnings encountered.
[SPManager] [DEBUG] [10/20/2006 1:30:01 PM]: Removing exclusive upgrade regkey by setting the mode to none


Events on database server :



  • Autogrow of file ‘DevMoss_SITE_Pair_log’ in database ‘DevMoss_SITE_Pair’ cancelled or timed out after 4062 ms.  Use ALTER DATABASE to set a smaller FILEGROWTH or to set a new size.

         OR



  • Autogrow of file ‘WSSUP_Temp_cda0b018-aa08-4abe-b752-418c62861754_log’ in database ‘WSSUP_Temp_cda0b018-aa08-4abe-b752-418c62861754’ took 83109 milliseconds.  Consider using ALTER DATABASE to set a smaller FILEGROWTH for this file.

Actions taken: Pregrowing transaction files in pair and temp databases as stated here did not help, neither setting a smaller growth rate to prevent a time-out during the autogrow operation on database server (because it is virtualized and expected to be slow) as described in this KB article .We also tried bumping up the resources on all servers, again no luck!!!


Cause: Due to the inaccurate nature of setting throughput on every upgrade action, and the unpredictability of hardware performance in real time, the timeout computed during upgrade process could sometime break a legit SQL query that is just running a little longer than usual.


Solution: gradual upgrade is not your choice 🙂 Use DB migration!!!!


 



Categories: Uncategorized Tags:
  1. No comments yet.
You must be logged in to post a comment.