4

I am trying to upgrade SharePoint 2007 web application to SharePoint 2010, I am using attach and de-attach method.

Below is the content database information:

  • Database Size: 66 GB
  • Site Collections: 1 Site Collection

I am facing a very strange problem during migration, after running the below command

stsadm.exe -o addcontentdb -url [http://sitename] -databasename [databasename] -databaseserver [databaseserver]

After running for a long time, it got stuck on X percent (not specific number) and it shows “Upgrade In Progress” in the central administration.

I though may be it needs sometime to finish the current action. But after waiting more than 16 hours, the percentage didn't change, the central administration is still showing In Progress and no errors are there in the log. I tried many times to upgrade the database but same problem happens every time.

Improve this question
4
  • 1
    What user account are you using to do the upgrade? Make sure it's a farm account. Also what does your ULS logs say?
    – Mike
    Commented Mar 7, 2013 at 19:12
  • We had this issue with one of our 100+GBs DBs also but we let it run and it finally finished with success at around 28 hours.
    – Dave Wise
    Commented Mar 7, 2013 at 19:27
  • @Mike: I am using the farm account. the ULS logs doesn't say anything because it didn't finish (no failure).
    – Hesham Amr
    Commented Mar 7, 2013 at 20:50
  • @Dave: I will try to let it running more time. I am thinking may be it is something related to database transaction log.
    – Hesham Amr
    Commented Mar 7, 2013 at 20:50

2 Answers 2

Reset to default
0

You can run below command using SharePoint PowerShell to execute all admin jobs.

STSADM.exe -o execadmsvcjobs

At the same time, you can check the upgrade log to identify where exactly upgrade process is stuck.

Improve this answer
0

Whew, just got through a migration from SP2007 to SP2010 to SP2013.

Here's a few tips:

1) The recommended max size for a content DB during migration is no more than 200 GB. If your over, it may work, but expect it to take a long time.

a. Migrate your smaller content databases first. You can probably do up to three simultaneously from different powershell prompt windows with little issue if the databases are under 100 GigaBytes.

2) The percentage complete indicator provides no indication of how much time it will take to complete. For larger content databases, the percentage complete will tend to sit there and it will appear that your migration is stuck. However, there are ways to check whether it is really stuck.

a. The logs: c:\program files\common files\microsoft shared\web server extensions\14\logs (Substitute 14 with 15 for SP2013).

Unfortunately, when the migration script is busy running a script it stops writing to the logs for quite a while.

b. SQL Activity Monitor and SQL Profiler. These two tools that come with MS SQL 2012 and MS SQL 2014 are awesome for seeing what your migration is doing behind the scenes.

c. The migration script will run under the login name of the account that your command prompt or powershell prompt is running as, so you can filter for your user name.

d. From the SQL Activity Monitor, you'll be able to see all the processes that are connected to your SQL server. If you notice a lot of extraneous processes other than your Mount-SPContentDatabase, you probably should look at ways to reduce the connections to give more resources to the migration. Consider disabling the SP Timer service and IIS service while migrating. (Run a test on a smaller content db to see if migration works while these services are off to be sure.)

3) If possible you'll want to run your migration on an SQL server with plenty of RAM, CPUs, and HD space. When you upgrade a content database it will cause the db to grow and increase the size of you T-Log quite a bit. If you run out of HD space, your migration will fail or be corrupted.

a. Also note, that if you have a live SharePoint farm that you are trying to migrate to then your DB server is probably gonna be busy processing www requests. You can migrate your SharePoint databases to a standalone dedicated migration DB server if you have one. 

     Mount-SPContentDatabase -Name [Name] -WebApplication [Url to web app] -DatabaseServer [DBServer]

4) Beware of any Host Intrusion Protection system (HIPS) or Antivirus programs running on your SQL server or front end server. Those programs could inadvertently sabotage your migration. HIPS kept blocking some of the migration script queries on my SQL server incorrectly thinking they were an SQL injection attack.

5) Definitely do a rehearsal run of a few of your databases before doing the full migration if you've got a lot of content databases to migrate over.

Hope this helps!

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.