v4.11.10 Upgrade to v6.2.1 Hangs on Database Upgrade Screen at 90%
I have fairly big site that I have to upgrade eventually to v7.x but first I am doing the upgrade to v6.x. I found that running the installer/upgrade it kept hanging on step 3 which is the database upgrade and eventually I was seeing timeout errors in the browser console. I extended the execution timeout value to 15 minutes but still kept having the same issue.
I decided to try upgrading to an earlier version of v6 first so upgraded to v 6.0.7 and that completed quickly with no hanging. From here I attempted the upgrade to 6.2.0 again but I have the same issue as before. I've opened up a SQL Profiler tool to see if it is actually hanging or if there is any activity going on in the background and the following queries are running continually:
SELECT *
FROM [cmsDocument]
INNER JOIN [cmsContentVersion]
ON [cmsDocument].[versionId] = [cmsContentVersion].[VersionId]
INNER JOIN [cmsContent]
ON [cmsContentVersion].[ContentId] = [cmsContent].[nodeId]
INNER JOIN [umbracoNode]
ON [cmsContent].[nodeId] = [umbracoNode].[id]
WHERE ([umbracoNode].[nodeObjectType] = 'c66ba18e-eaf3-4cff-8a22-41b16d66a972')
AND ([cmsDocument].[published] = 0 AND [cmsDocument].[releaseDate] <= '2014-08-09 05:59:17')
AND ([cmsDocument].[newest]=1)
ORDER BY [cmsContentVersion].[VersionDate] DESC
, [umbracoNode].[sortOrder]
go
Followed by
SELECT *
FROM [cmsDocument]
INNER JOIN [cmsContentVersion]
ON [cmsDocument].[versionId] = [cmsContentVersion].[VersionId]
INNER JOIN [cmsContent]
ON [cmsContentVersion].[ContentId] = [cmsContent].[nodeId]
INNER JOIN [umbracoNode]
ON [cmsContent].[nodeId] = [umbracoNode].[id]
WHERE ([umbracoNode].[nodeObjectType] = 'c66ba18e-eaf3-4cff-8a22-41b16d66a972')
AND ([cmsDocument].[published] = 1 AND [cmsDocument].[expireDate] <= '2014-08-09 05:59:17')
AND ([cmsDocument].[newest]=1)
ORDER BY [cmsContentVersion].[VersionDate] DESC
, [umbracoNode].[sortOrder]
go
The only thing that changes each time is the timestamp which looks to me like this is the result of an Umbraco background process checking for nodes that need to automatically publish/unpublish?
So, my problem is what to do now. After leaving this running for over an hour it seems clear the upgrade is unlikely to progress any further.
Any advice other than not attempting to upgrade to v6/v7 from v4 (which was the general consensus at CodeGarden) would be appreciated.
Further to this and following some further digging around in the core I decided to leave it running for a longer period of time and it's now completed so the "hang" was not really a hang just an incredibly long running process without any further visual feedback. This was on my local machine and so is going to considerably lengthen the time required to take the live site offline for the final upgrade unfortunately.
Hopefully this helps someone else that might have a similar issue - patience is all that is required :)
I'm just upgrading from 4.7.1 to 6.2.6 at dev instance and have similar problem.
I have just modified executionTimeout to 4 hours but I'm waiting 3 hours and my upgrade is still at 90%. I need something to do with this because I can't upgrade our sites like this.
Last line in UmbracoTraceLog.txt looks like:
2016-05-05 15:27:07,480 [10] INFO Umbraco.Web.Strategies.Migrations.ClearMediaXmlCacheForDeletedItemsAfterUpgrade
- [Thread 15] Cleared 61 items from the media xml cache that were trashed and not meant to be there
I run SQL Profiler and I see that Umbraco is executing query like this for each node:
SELECT *
FROM [cmsContentVersion]
INNER JOIN [cmsContent] ON [cmsContentVersion].[ContentId] = [cmsContent].[nodeId]
INNER JOIN [umbracoNode] ON [cmsContent].[nodeId] = [umbracoNode].[id]
WHERE ([umbracoNode].[nodeObjectType] = @0)
AND (umbracoNode.id = @1)
ORDER BY [cmsContentVersion].[VersionDate] DESC'
,N'@0 nvarchar(40), @1 int',@0=N'b796f64c-1f99-4ffb-b886-4bf4bc011a9c',@1=171962
and then for the same node:
SELECT *
FROM [cmsPropertyData]
INNER JOIN [cmsPropertyType] ON [cmsPropertyData].[propertytypeid] = [cmsPropertyType].[id]
WHERE ([cmsPropertyData].[contentNodeId] = @0)
AND ([cmsPropertyData].[versionId] = @1)',
N'@0 int,@1 nvarchar(40)',@0=171962,@1=N'2a817b82-62b6-4a36-9bcd-82ff29ad9949'
I have just analyzed all migration steps and I don't see any code which can execute queries like above.
Maybe it is caused by Examine indexing? I leave providers in ExamineSettings.config but I commented all index sets.
Now I see that there is class RebuildMediaXmlCacheAfterUpgrade that implements IApplicationStartupHandler interface. In this class is code like this:
var target70 = new Version(7, 0, 0);
if (e.ConfiguredVersion <= target70)
{
var mediasvc = (MediaService)ApplicationContext.Current.Services.MediaService;
mediasvc.RebuildXmlStructures();
}
So all media XML is being refreshed and I don't why. I have just compared old and new generated XML and is the same.
Interestingly I have hit this again today but in v6.2.6, I've left if for hours and am now going to have to leave it overnight as I suspect what you have found is the cause of the apparent hanging and this site does have a lot of media.
I turned the logging level on to INFO and see the last entry in the log as:
v4.11.10 Upgrade to v6.2.1 Hangs on Database Upgrade Screen at 90%
I have fairly big site that I have to upgrade eventually to v7.x but first I am doing the upgrade to v6.x. I found that running the installer/upgrade it kept hanging on step 3 which is the database upgrade and eventually I was seeing timeout errors in the browser console. I extended the execution timeout value to 15 minutes but still kept having the same issue.
I decided to try upgrading to an earlier version of v6 first so upgraded to v 6.0.7 and that completed quickly with no hanging. From here I attempted the upgrade to 6.2.0 again but I have the same issue as before. I've opened up a SQL Profiler tool to see if it is actually hanging or if there is any activity going on in the background and the following queries are running continually:
Followed by
The only thing that changes each time is the timestamp which looks to me like this is the result of an Umbraco background process checking for nodes that need to automatically publish/unpublish?
So, my problem is what to do now. After leaving this running for over an hour it seems clear the upgrade is unlikely to progress any further.
Any advice other than not attempting to upgrade to v6/v7 from v4 (which was the general consensus at CodeGarden) would be appreciated.
Thanks, Simon
Further to this and following some further digging around in the core I decided to leave it running for a longer period of time and it's now completed so the "hang" was not really a hang just an incredibly long running process without any further visual feedback. This was on my local machine and so is going to considerably lengthen the time required to take the live site offline for the final upgrade unfortunately.
Hopefully this helps someone else that might have a similar issue - patience is all that is required :)
I'm just upgrading from 4.7.1 to 6.2.6 at dev instance and have similar problem.
I have just modified executionTimeout to 4 hours but I'm waiting 3 hours and my upgrade is still at 90%. I need something to do with this because I can't upgrade our sites like this.
Last line in UmbracoTraceLog.txt looks like:
I run SQL Profiler and I see that Umbraco is executing query like this for each node:
and then for the same node:
I have just analyzed all migration steps and I don't see any code which can execute queries like above.
Maybe it is caused by Examine indexing? I leave providers in ExamineSettings.config but I commented all index sets.
Please help me to solve this problem.
Now I see that there is class RebuildMediaXmlCacheAfterUpgrade that implements IApplicationStartupHandler interface. In this class is code like this:
So all media XML is being refreshed and I don't why. I have just compared old and new generated XML and is the same.
Probably condition:
is wrong.
Interestingly I have hit this again today but in v6.2.6, I've left if for hours and am now going to have to leave it overnight as I suspect what you have found is the cause of the apparent hanging and this site does have a lot of media.
I turned the logging level on to
INFOand see the last entry in the log as:There doesn't appear to be any more database activity so can only assume it is churning away on something else...
is working on a reply...