Sharepoint Service Error: A deployment or retraction is already under way for the solution "xxx.wsp" , and only one deployment or retraction at a time is supported

Sometime this error has been occured from Windows SharePoint Services Administration command when the user do retractsolution or deploysolution like the follwing

C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN>stsadm -o retractsolution -name "%PackageName%" -local -url %TargetWebUrl%

or

C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN>stsadm -o deploysolution -name "%PackageName%" -local -allowGacDeployment -url %TargetWebUrl%
A deployment or retraction is already under way for the solution "xxx.wsp", and only one deployment or retraction at a time is supported
it occurs if anomalies deployment is running for the same package in the backend due to some previous deployment has been crashed before for some reason.

To avoid this problem do the followings:

Look for the deploy jobId to break the running by the following command:
C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN>stsadm-o enumdeployments

• Cancel the deploy typing the following command:
C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN>stsadm-o canceldeployment-id "GUID jobId"

• Check that deploy has been canceled by typing the following command:
C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN>stsadm-o enumdeployments
Hope it should work. 

Import, Export, Copy, and Delete List Items Using STSADM.exe

1. gl-exportlistitem

This command works almost identically to the gl-exportlist command that I created earlier. The main difference is that it takes in an optional "id" parameter which can be a single list item ID or a comma separated list of list item IDs. The syntax of the command can be seen below:

C:\>stsadm -help gl-exportlistitem

stsadm -o gl-exportlistitem

Exports a list item or items.

Parameters:
        -url <list view url>
        -filename <export file name>
        [-id <list item ID (separate multiple items with a comma)>]
        [-overwrite]
        [-includeusersecurity]
        [-haltonwarning]
        [-haltonfatalerror]
        [-nologfile]
        [-versions <1-4>
                1 - Last major version for files and list items
                2 - The current version, either the last major or the last minor
                3 - Last major and last minor version for files and list items
                4 - All versions for files and list items (default)]
        [-cabsize <integer from 1-1024 megabytes> (default: 25)]
        [-nofilecompression]
        [-quiet]

Here's an example of how to export 3 items from the site directory list:

stsadm –o gl-exportlistitem -url "http://intranet/sitedirectory/siteslist/AllItems.aspx" -id "1,2,3" -filename "c:\SiteDirItems" -includeusersecurity -versions 4 -nofilecompression

Running the above will create a folder called "SiteDirItems" in the root c: drive. You'll also find a log file there containing the same information that was dumped to the console. This same output can then be used by the gl-importlistitem command to copy the list items to another list in any site collection (note that the target could be on any web app in any farm). To export all items in a list simply omit the "id" parameter.

2. gl-importlistitem

This command has almost exactly the same parameters as the built in "import" command. One additional parameter of note is the "-retargetlinks" parameter. If this parameter is specified then you must also specify the "-sourceurl" parameter which corresponds to a view of the source list. The "retargetlinks" parameter tells the code to find any links that point to items in the source list and make them point to the target list.


This becomes helpful in a move operation. Note that only items identified by the list items BackwardLinks collection will get modified (unfortunately I'm not 100% clear about when and how this collection is set so I don't claim that using this will fix every link to your items, though I do have another command that will loop through every field of every item of every list of every site and adjust the field value by replacing one value with another). The syntax of the command can be seen below:

C:\>stsadm -help gl-importlistitem

stsadm -o gl-importlistitem

Imports a list item or items.

Parameters:
        -url <list view url to import into>
        -filename <import file name>
        [-includeusersecurity]
        [-haltonwarning]
        [-haltonfatalerror]
        [-nologfile]
        [-updateversions <1-3>
                1 - Add new versions to the current file (default)
                2 - Overwrite the file and all its versions (delete then insert)
                3 - Ignore the file if it exists on the destination]
        [-nofilecompression]
        [-quiet]
        [-retargetlinks (resets links pointing to the source to now point to the target)]
        [-sourceurl <url to a view of the original list> (use if retargetlinks)]
        [-retainobjectidentity]

Here's an example of how to import the items into the SiteDirectory list that we exported above and re-target any links pointing to the original documents so that they now point to the new documents (note that just like the built in import operation if you specify nofilecompression for the export you must also specify it for the import):

stsadm –o gl-importlistitem -url "http://teamsites/sitedirectory/siteslist/allitems.aspx" -filename "c:\SiteDirItems" -includeusersecurity -updateversions 2 -nofilecompression -retargetlinks -sourceurl "http://intranet/sitedirectory/siteslist/AllItems.aspx"

As with the exportlistitem operation a log file will be generated which will include all the details that were dumped to the console.

Update 11/15/2007: Apparently there's some sort of funky bug with the deployment API which is preventing the importing of list items from functioning 100% (see the comments below from David who discovered the issue). The problem is that if you import a list item that has dependencies in different folders either the dependencies or the dependent items will be placed in the wrong folder. There's a way with code that you can set the TargetParentUrl for orphaned items which is supposed to correct this - unfortunately it appears that whatever URL is first set gets used for all remaining items. The interesting thing is that you shouldn't need to set this property at all because all the list items are going to the same targe web and the WebUrl property of the SPImportSettings object is being set but if I don't set anything then the items still end up in the wrong location. The unfortunate side affect of this is that in order to prevent things from appearing in what would seem random locations and thus making it difficult to find imported items I've had to force everything to go to the root folder. Fortunately it's fairly easy to move things around after the import but it's still what should be an unnecessary pain in the butt. If anyone has any information which can help me solve this problem please pass it along (I spent two days picking through disassembled code trying to identify where the failure was but was not able to find anything conclusive - I also spent quite a bit of time trying to provide a work around to fix it but ran into to many issues where I'd fix one thing and break another (it's just too hard to predict every possible combination of possibilities that could occur)).

3. gl-copylistitem

If you've got the ability to import and export list items then why not make it a one step operation to copy a list item or move a list item. Once I had the code for the import and export the copy was nothing more than a wrapper which would call into the appropriate methods. By adding an extra parameter to support deleting the source list item I now also had a move command. The syntax of the command is just the combination of the import and export minus that which I don't need the user to set. The syntax of the command can be seen below:

C:\>stsadm -help gl-copylistitem

Copies a list item or items to another list.

Parameters:
        -sourceurl <list view url to copy>
        -targeturl <url of a web site to copy to>
        [-id <list item ID (separate multiple items with a comma)>]
        [-includeusersecurity]
        [-haltonwarning]
        [-haltonfatalerror]
        [-nologfile]
        [-versions <1-4>
                1 - Last major version for files and list items
                2 - The current version, either the last major or the last minor
                3 - Last major and last minor version for files and list items
                4 - All versions for files and list items (default)]
        [-updateversions <1-3>
                1 - Add new versions to the current file (default)
                2 - Overwrite the file and all its versions (delete then insert)

                3 - Ignore the file if it exists on the destination]
        [-quiet]
        [-retargetlinks (resets links pointing to the source to now point to the target)]
        [-deletesource]

Here's an example of how to perform the same operation that the above import and export commands were doing but with just one step while at the same time deleting the source list items:

stsadm –o gl-copylistitem -sourceurl "http://intranet/sitedirectory/siteslist/AllItems.aspx" -targeturl "http://teamsites/sitedirectory/siteslist/allitems.aspx" -id "1,2,3" -includeusersecurity -updateversions 2 -versions 4 -nofilecompression -retargetlinks -deletesource

If the source list items were deleted then the result of the export operation is saved to a temp folder, the path to which is displayed to the user upon completion. To delete all items in a list simply ommit the "id" parameter.

4. gl-deletelistitem

I created this command because I needed a quick way to clean up all my test items that I was creating while testing the gl-importlistitem command. So even though I didn't need it for my upgrade project specifically it came in handy for me so I figure someone else may benefit from it as well. The command allows you to either delete all items or specific items by passing in an "id" parameter. The syntax of the command can be seen below:

C:\>stsadm -help gl-deletelistitem

Deletes an item or items from a list.

Parameters:
        -url <list view URL>
        [-id <list item ID (separate multiple items with a comma)>]
        [-deletefolders]

Here's an example of how to delete items from a list:

stsadm –o gl-deletelistitem -url "http://intranet/sitedirectory/siteslist/AllItems.aspx" -id "1,2,3"

To delete all items from a list simply omit the "id" parameter.

Move List Items with Attachments between SharePoint 2007 and 2013: Using with MS Access 2013.

open Access 2013 , I clicked to create a new Blank Desktop Database and started my journey:



I gave the database a name and pressed Create:



Time to start poking around. I went to the External Data tab, and clicked More to reveal SharePoint List in the “Import & Link” section of the ribbon:



I entered the URL to my SharePoint 2007 site and chose to Import the source data into a new table in the current database.



I selected the list I wanted to export and clicked OK.



Access then proceeded to lock up my computer for several minutes as it imported the data, but it was worth the wait. Keep in mind that although logically we are exporting the data from SharePoint 2007, from Access’ perspective we are importing this data into Access. From here, we will export this data to a list in our SharePoint Online site.

When the import completed, I clicked Close and noticed in the “All Access Objects” view in the left pane, my database now contained a table named after the SharePoint list I just brought over. I double-clicked it and sure enough, all the data was there including the list item attachments!



Stunned by my good fortune, I double-clicked some of these cells to confirm the attachments were actually there. They were!




Time to get this data into SharePoint 2013. I went back to the External Data tab, and clicked More to reveal SharePoint List in the “Export” section of the ribbon:



Much like the import wizard earlier, the export wizard allows me to connect to a SharePoint site (I chose my SharePoint Online site this time) and specify a name for the new list.



I pressed OK and allowed Access to do its thing (it took about 15 minutes). When it was done, my browser opened to the newly imported list in SharePoint Online. Not only was the list schema perfect (if you’ve ever imported a spreadsheet to create a new list, you know how frustrating it can be to have all of your Choice columns converted to Single line of text), but all the attachments to the list items were there as well!
You will notice a few extra columns are created as part of the process:

• Encoded Absolute URL
• Item Type
• Path
• URL Path
• Workflow Instance ID
• Comments
• File Type
• _OldID

You can safely remove these from your new list if you do not want or need them.



Is completed! Thanks, Access 2013!

Introduction to SharePoint 2010 for SQL Servers DBAs

Problem

My company is getting ready to rollout SharePoint 2010.  As the only DBA on staff, I need a quick introduction to the product that is geared to a DBA.  Can you help me out?  Check out this tip to learn more.

Solution

From the standpoint of a DBA, you can think of SharePoint 2010 as just an application that stores its data in SQL Server databases.  However, it is really useful to have a high level understanding of SharePoint concepts such as the SharePoint farm, server roles, service applications, web applications, and sites.    
In this tip I will provide an overview of the SharePoint 2010 concepts and discuss what matters to the DBA.  In addition, I will highlight what the DBA needs to know about the installation and configuration of SharePoint.  In future tips I will focus on what the DBA needs to know about administering the SharePoint databases. 
In the this tip, I'm referencing the SharePoint 2010 platform.  

SharePoint 101

When you mention the word SharePoint, most people think of a browser-based application that you use for collaboration.  Your company, department, group, etc. has a site that contains lists used for announcements, events, contacts, calendars, documents, and so on.  From the standpoint of the DBA, these lists (and other data) are stored in SQL Server databases.
From a technical standpoint, there are several distinct products that we refer to as "SharePoint 2010".  SharePoint Foundation 2010 provides the basic collaboration functions.  SharePoint Server 2010 provides additional capabilities above and beyond SharePoint Foundation and includes the following versions:

• SharePoint Server 2010 Enterprise Client Access License features
• SharePoint Server 2010 for Internet Sites, Enterprise
• SharePoint Server 2010 Standard Client Access License features
• SharePoint Server 2010 for Internet Sites, Standard

From the standpoint of the DBA, the version of SharePoint that your company chooses is largely a business decision and maybe somewhat influenced by the difference in the licensing costs.  For the DBA it's all about databases and a lot of them!
There are three specific types of database used by SharePoint:

• Farm configuration
• Content
• Service application

I will provide more details on these databases in the following sections and in future tips.  

SharePoint Farm

The SharePoint farm is comprised of one or more servers.  In your organization you have one or more farms; e.g. intranet, development, and testing.  From the standpoint for the DBA, a farm is represented by a single SQL Server database which by default is named SharePoint_Config (i.e. the farm configuration database).  Each server in a farm is "connected" to a single configuration database.  If you have multiple farms, each one has its own configuration database.
The following diagram is taken from Topologies for SharePoint Server 2010 on the Microsoft TechNet site and shows some examples of small SharePoint farms:

Note that you can have a SharePoint farm that is made up of only a single server; you can have much larger farms than the above diagram shows as well.

Server Roles

There are three server roles in a SharePoint farm:

• A web front end serves up web pages for end users; i.e. it runs web applications
• An application server provides services to the web applications; e.g. Excel Services, User Profile, Performance Point, etc.
• A database server runs instance(s) of SQL Server that store data for web applications and services

Keep in mind that a single server could provide one or more of these roles.  From the standpoint of the DBA, the database server is obviously the focal point.

Service Applications

SharePoint provides many service applications that are consumed by the web applications.  The following is a screenshot from the SharePoint Central Administration web site showing the complete list of services provided out of the box with SharePoint Server Enterprise Edition:

From the standpoint of the DBA, the important thing about application services is that some of them have one or more databases associated with them and they have their own unique considerations.  As a general rule the service application databases tend to not be that big.  I will cover the details of creating and managing service application databases in a future tip.

Web Applications

Web applications serve up the web pages that provide the SharePoint user experience.  Each web application is provided by an Internet Information Services (IIS) web site.  The web application's code is executed in an IIS application pool process.  From the standpoint of the DBA, there are two key points about the web application:

• A web application is associated with one or more content databases; the content database is where the data in the SharePoint is stored.
• The IIS application pool identity (i.e. the Windows account that is running the process) automatically gets specific permissions in the content database

The default behavior in SharePoint is that when you create a web application, you also create a content database. 

Sites

The word sites is somewhat ambiguous in SharePoint.  The connotation of a site is a "web" site.  From the technical standpoint of the SharePoint object model, a site is really a site collection; each item in the collection is a web.  From the standpoint of the DBA, the important thing here is that an entire site collection is contained in a single content database; a content database can hold one or more site collections.  From a planning perspective, you want to give careful consideration to what site collections are stored in a particular content database.  Content databases can become quite large so deciding the content database for each site collection is one of the most important things for the DBA.  Multiple, smaller content databases can be much easier to manage than a single large content database. 
The default behavior in SharePoint is that when you create a site collection, SharePoint puts the site collection in one of the content databases associated with the web application.  You will want to designate which content database will hold a particular site collection.  I will cover creating and managing content databases in a future tip.

SharePoint Installation and Configuration

A SharePoint installation can be broken down into the following steps:

• Install SharePoint prerequisites (there are a number of items that SharePoint requires)
• Install SharePoint software on every web front end and application server
• Perform SharePoint configuration on each web front end and application server

From the standpoint of the DBA, here are the things that you need to know:

• SharePoint 2010 only works with the following 64 bit editions of SQL Server: SQL Server 2008 R2, SQL Server 2008 SP1 CU2, and SQL Server 2005 SP3 CU3
• To install SharePoint requires a Windows account (i.e. the SharePoint "setup" or "admin" account) with the following attributes:
  • Should be a Windows domain account
  • Member of the Local Administrators group on each SharePoint server
  • SQL Server login and a member of the dbcreator and securityadmin SQL Server server roles
• SharePoint configuration is where you create a farm (i.e. create the SharePoint configuration database) and connect the SharePoint server to the newly created farm or an existing farm
• SharePoint configuration requires a "farm" account (i.e. a farm administrator account); this account should be a Windows domain account and must already exist; the configuration process will:
  • Create a SQL Server login for this account
  • Add it to the dbcreator and securityadmin SQL Server server roles
  • Add it to the db_owner database role for all SharePoint databases

For additional details about the SQL Server database requirements take a look at:

• Hardware and Software Requirements (SharePoint Server 2010).
• SQL Server 2008 R2 and SharePoint 2010 Products: Better Together (white paper)

Next Steps

• This tip provides the foundation knowledge that I think a DBA needs to begin administering SharePoint databases. 
• Stay tuned for future tips that will cover database administration topics related to SharePoint databases.
• Remember that SharePoint creates some SQL Server logins and databases; if you see databases and logins that you're not familiar with, find out if they were created by SharePoint before deleting them!

Huge Data - how To Migrate SharePoint 2007 My Sites Databases to SharePoint 2010 -

Problem

I'm the DBA tasked with migrating the SharePoint 2007 content databases to our new SharePoint 2010 farm.  I'm having a real problem upgrading the My Sites content database; it takes 36 hours using the database attach method!  Our My Sites isn't mission critical but what I need is to be able to do this in a piecemeal fashion; e.g. I have a nightly maintenance window of a couple of hours and I can run a portion of the upgrade each night until it's done.  Do you have any ideas?

Solution

The SharePoint content databases hold all of your lists, documents, pictures, etc.  In many cases they can grow very quickly as users add content. In order to proactively manage the growth of your content databases, you may want to create additional content databases and move selected site collections from one content database to another.  This allows you to keep the size of the content database somewhat in check.  The larger the content database the longer it takes to backup, restore, run DBCC, etc.

In the case of migration from SharePoint 2007 (SP2007) to SharePoint 2010 (SP2010), you can backup your SP2007 content databases and "attach" them to your SP2010 farm.  This is called the database attach method and it also performs whatever upgrades are required; e.g. schema changes.  If you are new to SharePoint, you may want to take a look at my earlier tip Introduction to SharePoint for SQL Server DBAs where I quickly summarize what you was an DBA need to know about SharePoint.

I have experienced the exact situation that you cite; my SP2007 My Sites content database took 39+ hours to attach to SP2010.  I have no idea why it takes so long but since a migration is a one-time thing I don't want to spend any time worrying about it; I just needed to get it done.

The following are the steps that I used to perform a piecemeal upgrade of my SP2007 My Sites content database to SP2010:

1. I decided to split the My Sites content database into 5 separate databases so I needed to create additional content databases.  This allowed me to upgrade a group of My Sites each night.
2. Get the list of My Sites (each is a site collection) then decide on which site collections to move to each content database.
3. Move the site collections to their new content database.
4. Backup the newly created and populated content databases in the SP2007 farm.
5. Restore the content databases to the SP2010 database server.
6. Attach each content database to the SP2010 web application for My Sites.

The above steps make the following assumptions:

• You have a database server for your SP2007 and a different database server for you SP2010 farm
• You are using Windows authentication for SQL Server (if you use SQL Server authentication you'll need to supply additional parameters to the commands that we will go though below)

I'll use the STSADM command-line administration tool for the steps that are performed in the SP2007 farm; by default you will find STSADM.EXE in the folder C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\BIN. You will probably want to add the folder to your path. You run STSADM from a command prompt. I'll use PowerShell cmdlets for the steps that are performed in the SP2010 farm; to run the cmdlets you can launch the SharePoint 2010 Management Shell via the Microsoft SharePoint 2010 Products program group in the Start menu.

Create Content Databases

Use the following command to create a new content database in your SP2007 My Sites web application:

STSADM -o addcontentdb -url http://mysites.yourdomain.com -databasename MySites_Content_01 -databaseserver yourdbserver

The following are the main points about the parameters:

• The o parameter is the operation name
• The url parameter is your My Sites web application url
• The databasename parameter is the name of the content database to be created
• The databaseserver parameter is the server name of your SP2007 database server

You can find the details on all of the command line parameters for adding a content database here.  Make sure to check the sizes of the database file and log file and grow them as necessary; the default is 20MB for data and 5MB for the log.

Get the List of My Sites

Use the following command to get the list of my sites (each My Site is a site collection) in your SP2007 My Sites web application:

STSADM -o enumsites -url http://mysites.yourdomain.com > sitelist.xml

The following are the main points about the parameters:

• The o parameter is the operation name
• The url parameter is your My Sites web application url
• You need to redirect the standard output from the command to a file; e.g. sitelist.xml

Here is an example of the sitelist.xml file:

Note that the file has the size of each My Site (StoreageUsedMB); you can use this to properly size the content databases where you will move the sites.

Move a Site Collection to Another Content Database

To move site collections to another content database, you have to create one XML file for each target content database.  The format of the XML file must be just like the sites.xml file created in the previous step and it must include the just list of sites to be moved.  So if you wanted to split your My Sites into 5 content databases, you would need 5 files.  After creating the XML files with the list of sites for each content database, run the following command (all on one line for each content database move):

STSADM -o mergecontentdbs -url http://mysites.yourdomain.com -sourcedatabasename Content_MySite -destinationdatabasename dbname -operation 3 -filename C:\temp\mysites-01.xml

You can find the complete details on the mergecontentdbs operation here.  Note that when the above command completes you will see a message that an IISRESET is required; run the following command from the command prompt (you will likely have to launch the command prompt with the Run As Administrator):

IISRESET /noforce

I find conflicting information concerning whether or not you need to run the STSADM command preparetomove before moving sites to another content database.  You can find the details for the preparetomove command here; I've never been able to specify the command and have it run successfully; I always get some error message that doesn't help me figure out what I'm doing wrong.  In the case of migrating SP2007 My Sites to SP2010, I have not run the command and the migration was successful.

Backup and Restore the New Content Database(s)

Assuming you have separate database servers for your SP2007 and SP2010 farms, you will need to backup the new content databases on the SP2007 database server, copy the backups to the SP2010 database server, and restore them to the SP2010 database server.  You can use the SQL Server Management Studio gui (right click on the database, select Tasks, Backup) or simply enter the T-SQL command in a query window:

BACKUP DATABASE contentdbname TO DISK = 'fullpathofbackupfile'

To perform the restore you can use the SQL Server Management Studio gui (right click on the database, select Tasks, Restore) or simply enter the T-SQL command in a query window:

RESTORE DATABASE contentdbname FROM DISK = 'fullpathofbackupfile'

Prior to taking the backup, you may want to set the content database to read only so users cannot make any changes once the migration is in process. 

Attach the Content Databases to the SP2010 Farm

After you restore the new content databases to your SP2010 database server, you are ready for the final step - attach the databases to your SP2010 My Sites web application.  STSADM is still available with SP2010 but the preferred approach is to use PowerShell cmdlets for administration tasks.  Launch the SharePoint 2010 Management Shell from the Microsoft SharePoint 2010 Products program group in the Start menu; you will see what looks just like a command prompt but it is in fact a PowerShell command prompt.

Run the following command to attach and upgrade your SP2007 content database for each content database to be attached:

Mount-SPContentDatabase dbname -DatabaseServer dbservername -WebApplication http://mysites.yourdomain.com -UpdateUserExperience

Specify the UpdateUserExperience parameter to have the My Sites use the SharePoint 2010 user interface.  You can omit the parameter and have the My Sites retain the SharePoint 2007 look and feel.  I tried this and I didn't like the results so I would suggest that you try the SharePoint 2010 user interface; it just works better.

You can find the full details for the Mount-SPContentDatabase cmdlet here. 

Next Steps

• Although the focus of this tip was migrating My Sites, the steps apply to migrating any SP2007 content database to SP2010 and also moving site collections between content databases.
• Take a look at the tips on MSSQLTips.com in the SharePoint category; most of these are written specifically for DBAs.
• You can find the details on all of the STSADM database operations here.
• You can find the details on all of the PowerShell cmdlets for database operations here.

Attach databases and upgrade to SharePoint Foundation 2010

Other Versions

• Office 2007

3 out of 3 rated this helpful - Rate this topic

  Applies to: SharePoint Foundation 2010
Topic Last Modified: 2011-08-05
When you upgrade from Windows SharePoint Services 3.0 to Microsoft SharePoint Foundation 2010 by using the database attach upgrade approach, you upgrade only the content for your environment and not the configuration settings. Using a database attach upgrade approach is useful when you are changing hardware or want to reconfigure your server farm topology as part of the upgrade process. For more information about how to choose an upgrade approach, see Determine upgrade approach (SharePoint Foundation 2010).
The first step in the process is to set up a new environment to host the upgraded content. If you have not yet set up and configured the new environment, follow the steps in Prepare the new SharePoint Foundation 2010 environment for a database attach upgrade to do so. You must create a Web application in the new environment for every Web application in the old environment, copy any server-side customizations, configure services, and apply any farm settings to the new environment.
After you set up the new environment, you can use the procedures in this article to detach and then reconnect the databases to perform the actual upgrade. This article contains the steps required to perform a standard database attach upgrade and a database attach upgrade with read-only databases.
In this article:

• Process overview
• Before you begin
• Set the previous version databases to be read-only (database attach with read-only databases)
• Back up the previous version databases by using SQL Server tools
• Detach the previous version databases (standard database attach)
• Restore a backup copy of the database (database attach with read-only databases)
• Set the databases to read-write (database attach with read-only databases)
• Verify custom components
• Attach a content database to the Web application
• Verification: Verify upgrade for the first database
• Attach remaining databases
• Verification: Verify upgrade for additional databases

Note

One frequent cause of failures during upgrade is that the environment is missing customized features, solutions, or other elements. Be sure that any custom elements you have to have are installed on your front-end Web servers before you begin the upgrade process. Use the pre-upgrade checker — and, for a database attach upgrade, also use the test-spcontentdatabase Windows PowerShell cmdlet — to identify any custom elements that your sites might be using. For more information, see Identify and install customizations in the article "Use a trial upgrade to find potential issues."

For more information about the general process of upgrading by using the database attach upgrade approach, see Upgrade process overview (SharePoint Foundation 2010).

Process overview

---

When you upgrade by using database attach upgrade, you detach the databases in the old farm and then attach them to the new farm. When you attach a database to the new farm, the upgrade process runs and upgrades the whole database. The database attach upgrade process is similar to the in-place upgrade process. The difference is that the database attach upgrade process is performed manually, and is performed in a separate environment.
If you want to preserve your original farm and allow users to continue to access their data, you must set the databases to read-only and then attach a backup copy of the databases.

Note
The part of the process in this article that is specific to moving a database from one computer that is running Microsoft SQL Server to a different computer that is running SQL Server is known as planned relocation. For more information about planned relocation, see Moving User Databases (http://go.microsoft.com/fwlink/p/?LinkId=148425).

For a general overview of the upgrade process, see Upgrade process overview (SharePoint Foundation 2010).

Before you begin

---

Before you begin the database attach upgrade, review the following information about permissions, hardware requirements, and software requirements. Follow the specified steps to install or configure prerequisite software or to modify settings.

• Ensure that you have met all hardware and software requirements. You must have a 64-bit version of Windows Server 2008 or Windows Server 2008 R2. For server farms, you must also have a 64-bit version of SQL Server 2005 or SQL Server 2008. For more information about these requirements (such as specific updates that you must install), see Determine hardware and software requirements (SharePoint Foundation 2010).
• Ensure that you are prepared to set up the required accounts by using appropriate permissions. For detailed information, see Administrative and service accounts required for initial deployment (SharePoint Foundation 2010).
• Ensure that the account you use to attach the databases is a member of the db_owner fixed database role for the content databases that you want to upgrade.
• Run the pre-upgrade checker tool on the sites that are stored in the databases. The pre-upgrade checker identifies potential upgrade issues in your environment so that you can address them before you upgrade. For more information, see Run the pre-upgrade checker (SharePoint Foundation 2010).
• Create a new server farm environment. For information about how to create the new environment, see Prepare the new SharePoint Foundation 2010 environment for a database attach upgrade.
• Check for and repair any database consistency errors. For more information, see Database maintenance for Windows SharePoint Services 3.0 (white paper).

Set the previous version databases to be read-only (database attach with read-only databases)

---

If you are using the read-only databases hybrid approach to upgrade, set the previous version databases to read-only before you back up the databases. In any type of database attach upgrade, you can also set the databases to read-only temporarily to ensure that you capture all the data in the backup so that you are restoring and upgrading the current state of the environment. If the databases are set to read-only, users can continue to view content, but they will be unable to add or change content.

Important

You cannot upgrade a database that is set to read-only. If you are using a database attach with read-only databases, you restore a copy of the database and perform the upgrade on the copy. If you are not using this method, but want to set content databases to read-only temporarily while you back up the current data, make sure that you set the databases to read-write before you attach and upgrade the databases.

Important
Be sure you have run the pre-upgrade checker before you perform this procedure. For more information, see Run the pre-upgrade checker (SharePoint Foundation 2010).

To set a database to read-only in SQL Server 2000

1. In SQL Server Enterprise Manager, right-click the name of the database that you want to set to read-only, and then click Properties.
2. In the Properties dialog box, click the Options tab.
3. Under Access, select the Read-only check box, and then click OK.

To set a database to read-only in SQL Server 2005

1. In SQL Server Management Studio, right-click the name of the database that you want to set to read-only, and then click Properties.
2. In the Select a page section, click Options.
3. In the right pane, under Other options, in the State section, next to Database Read-Only, click the arrow, and then select True.

To set a database to read-only in SQL Server 2008

1. In SQL Server Management Studio, in Object Explorer, connect to an instance of the Database Engine, expand the server, and then expand Databases.
2. Select the database that you want to configure to be read-only, right-click the database, and then click Properties.
3. In the Database Properties dialog box, in the Select a page section, click Options.
4. In the right pane, under Other options, in the State section, next to Database Read-Only, click the arrow, and then select True.

You can configure the READ_ONLY database availability option by using Transact-SQL. For more information about how to use the SET clause of the ALTER DATABASE statement, see Setting Database Options (http://go.microsoft.com/fwlink/p/?LinkId=148362).

Back up the previous version databases by using SQL Server tools

---

Follow the appropriate procedure to back up databases in SQL Server 2000, SQL Server 2005, or SQL Server 2008. Repeat these steps for each content database in your server farm.
You do not have to back up the configuration or admin content databases, because you will re-create these databases in the new server farm. For more information about the kinds of databases that you might have in a Windows SharePoint Services 3.0 server farm, see Database types and descriptions (Windows SharePoint Services 3.0).
At the end of this procedure, you will have created duplicates of the read-only content databases.
To back up a database in SQL Server 2000

1. On the database server, click Start, point to All Programs, point to Microsoft SQL Server, and then click Enterprise Manager.
2. In SQL Server Enterprise Manager, expand Microsoft SQL Servers.
3. Expand SQL Server Group.
4. Expand (local) (Windows NT).
5. Expand Databases.
6. Right-click the database that you want to back up, point to All Tasks, and then click Backup Database.
7. In the SQL Server Backup dialog box, in the Name box, specify a name for the backup, and then in the Backup area, select Database - complete.
8. In the Destination area, either select an existing destination or do the following:
   
   1. Click Add.
   2. In the Select Backup Destination box, select File Name, and then next to the File Name box, click Browse.
   3. In the Backup Device Location - (local) dialog box, in the File name box, type a file name, and then click OK.
   4. Click OK again to close the Select Backup Destination dialog box.
9. Click OK to start the backup process.
10. Click OK to acknowledge that the backup process is complete.

Repeat the previous procedure to back up all the other content databases that are used by Windows SharePoint Services 3.0 in your environment.
To back up a database in SQL Server 2005

1. On the database server, click Start, point to All Programs, point to Microsoft SQL Server 2005, and then click SQL Server Management Studio.
2. In the Connect to Server box, fill in the connection information, and then click Connect.
3. After you connect to the appropriate instance of the SQL Server 2005 Database Engine, in Object Explorer, expand the server tree by expanding the server name.
4. Expand Databases, right-click the database that you want to back up, point to Tasks, and then click Back Up. The Back Up Database dialog box appears.
5. In the Source area, in the Database box, verify the database name.
6. In the Backup type box, select Full.
7. Under Backup component, select Database.
8. In the Backup set area, in the Name text box, either accept the default backup set name that is suggested or type a different name for the backup set.
9. In the Destination area, specify the type of backup destination by selecting Disk or Tape, and then specify a destination. To create a different destination, click Add.
10. Click OK to start the backup process.

Repeat the previous procedure to back up all the other content databases that are used by Windows SharePoint Services 3.0 in your environment.
To back up a database in SQL Server 2008

1. On the database server, click Start, point to All Programs, point to Microsoft SQL Server 2008, and then click SQL Server Management Studio.
2. In the Connect to Server box, fill in the connection information, and then click Connect.
3. After you connect to the appropriate instance of the SQL Server 2008 Database Engine, in Object Explorer, expand the server name.
4. Expand Databases, right-click the database that you want to back up, point to Tasks, and then click Back Up. The Back Up Database dialog box appears.
5. In the Source area, in the Database box, verify the database name.
6. In the Backup type box, select Full.
7. Under Backup component, select Database.
8. In the Backup set area, in the Name text box, either accept the default backup set name or type a new name.
9. In the Destination area, specify the type of backup destination by selecting Disk or Tape, and then specify a destination. To create a different destination, click Add.
10. Click OK to start the backup process.

Repeat the previous procedure to back up all the other content databases that are used by Windows SharePoint Services 3.0 in your environment.

Detach the previous version databases (standard database attach)

---

Before you can attach your databases to the new environment and upgrade the data, you need to detach them from the current environment. After you have detached the databases, you can move them to a new database server or leave them on the existing database server and attach them to the Web applications.

Important
Do not use the following procedure if you are performing a database attach upgrade with read-only databases. To continue to provide your users with access to their content, you need to leave the databases attached, and follow the steps in the Restore a backup copy of the database (database attach with read-only databases) section later in this article to make a copy of the databases instead.

To detach a content database from a Web application

1. In Central Administration, on the Application Management page, in the SharePoint Web Application Management section, click Content databases.
2. On the Manage Content Databases page, click the content database you want to detach.
   

   Note
   If the content database does not appear, it might be associated with another Web application. To select another Web application, on the Web Application menu, click Change Web Application.

3. On the Manage Content Database Settings page, in the Remove Content Database section, select the Remove content database check box, and then click OK.
   

   Note
   Removing the content database does not delete the database; it only removes the association of the database with the Web application.

4. Repeat steps 2 and 3 for each content database that you want to detach.

You can also use the deletecontentdb Stsadm operation to detach a content database from a Web application. For more information, see Deletecontentdb: Stsadm operation (Windows SharePoint Services).
If you are moving the databases to a different database server, you must also detach the databases from the instance of SQL Server before you move them and attach them to the new instance of SQL Server after you move them.

Important
If you move your databases to a different instance of SQL Server, make sure to verify that security is configured correctly. Check that the accounts you use have the appropriate fixed roles and permissions on the databases, and that they will still be valid accounts if you are moving across domains.

To detach a database from an instance of SQL Server and move it to another instance of SQL Server

1. In SQL Server 2005 Management Studio, open the source instance of SQL Server, and then expand the Databases node.
2. Right-click the content database, point to Tasks, and then click Detach. Repeat this step for each content database that you want to detach and move.
   

   Note
   Use this procedure to move only content databases. Do not detach any other databases.

3. In Windows Explorer, browse to the location of the .mdf and .ldf files for the content databases.
4. Select the .mdf and .ldf files for the database you want to move and either copy or move them to the destination directory.
5. In SQL Server 2005 Management Studio, open the source instance of SQL Server.
6. Right-click the Databases node, point to Tasks, and then click Attach.
7. In the Attach Database dialog box, browse to the location to which you transferred the .mdf and .ldf files, select the .mdf file for the database you want to attach, and then click OK.
8. Repeat steps 6 and 7 for each content database that you are moving.

Restore a backup copy of the database (database attach with read-only databases)

---

After you configure the new server farm, you can restore the backup copies of the databases on one of the following: Microsoft SQL Server 2008 R2, SQL Server 2008 with Service Pack 1 (SP1) and Cumulative Update 2, and SQL Server 2005 with SP3 and Cumulative Update 3. Note that you must restore to a 64-bit version of SQL Server 2008 R2, SQL Server 2008 with SP1 and Cumulative Update 2, and SQL Server 2005 with SP3 and Cumulative Update 3. Start with one database, and then verify that the restoration has worked before you restore the other databases.
The following section provides procedures for restoring the backups.
To restore a backup copy of a database in SQL Server 2005 Enterprise Edition

1. In SQL Server Management Studio, right-click Databases, and then click Restore Database. The Restore Database dialog box appears.
2. In the Restore Database dialog box, on the General page, in the To database box, type the name of the database you are restoring.
3. In the To a point in time text box, keep the default (Most recent possible).
4. To specify the source and location of the backup sets to restore, click From device, and then click Browse to select the backup file.
5. In the Specify Backup dialog box, in the Backup media box, make sure that File is selected.
6. In the Backup location area, click Add.
7. In the Locate Backup File dialog box, select the file that you want to restore, and then click OK.
8. In the Select the backup sets to restore grid, select the Restore check box next to the most recent full backup.
9. In the Restore Database dialog box, on the Options page, under Restore options, select the Overwrite the existing database check box.
10. Click OK to start the restore process.

To restore a backup copy of a database in SQL Server 2008 Enterprise

1. After you connect to the appropriate instance of the SQL Server 2008 Database Engine, in Object Explorer, expand the server name.
2. Right-click Databases, and then click Restore Database. The Restore Database dialog box appears.
3. In the Restore Database dialog box, on the General page, type the name of the database to be restored in the To database list.
4. In the To a point in time text box, retain the default (Most recent possible).
5. To specify the source and location of the backup sets to restore, click From device, and then click Browse to select the backup file.
6. In the Specify Backup dialog box, in the Backup media box, be sure that File is selected.
7. In the Backup location area, click Add.
8. In the Locate Backup File dialog box, select the file that you want to restore, click OK, and then, in the Specify Backup dialog box, click OK.
9. In the Restore Database dialog box, under Select the backup sets to restore grid, select the Restore check box next to the most recent full backup.
10. In the Restore Database dialog box, on the Options page, under Restore options, select the Overwrite the existing database check box.
11. Click OK to start the restore process.

Set the databases to read-write (database attach with read-only databases)

---

You must also set the databases back to read-write before you attach and upgrade them.
To set a database to read-write in SQL Server 2008

1. In SQL Server Management Studio, in Object Explorer, connect to an instance of the Database Engine, expand the server, and then expand Databases.
2. Select the database that you want to configure to be read-write, right-click the database, and then click Properties.
3. In the Database Properties dialog box, in the Select a page section, click Options.
4. In the right pane, under Other options, in the State section, next to Database Read-Only, click the arrow, and then select False.

To set a database to read-write in SQL Server 2000

1. In SQL Server Enterprise Manager, right-click the name of the database that you want to set to read-write, and then click Properties.
2. In the Properties dialog box, click the Options tab.
3. Under Access, clear the Read-only check box, and then click OK.

Verify custom components

---

Before you attach the content databases to the Web applications, use the Test-SPContentDatabase Windows PowerShell cmdlet to verify that you have all the custom components that you need for that database.
To verify custom components are available by using Windows PowerShell

1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin.
2. On the Start menu, click All Programs.
3. Click Microsoft SharePoint 2010 Products.
4. Click SharePoint 2010 Management Shell.
5. At the Windows PowerShell command prompt, type the following command:
   
   Copy

   Test-SPContentDatabase -Name <DatabaseName> -WebApplication <URL>
   

   Where:
   
   • <DatabaseName> is the name of the database you want to test.
   • <URL> is the URL for the Web application that will host the sites.

For more information, see Test-SPContentDatabase.

Attach a content database to a Web application

---

When you attach a content database, make sure that the root site for the Web application is included in the first content database that you attach. In other words, before you continue, examine the root of the Web application in the original server farm to determine the first site collection. After you attach the database that contains the root site, you can attach the other content databases for the Web application in any order. You do not have to create any site collections to store the content before you attach the database; this process creates the site collections for you. Make sure that you do not add any new site collections until you have restored all the content databases. When you created the Web applications in the new environment, a content database was created for each Web application by default. You can ignore these default databases until after you have attached your previous version databases, and then you can delete the default databases.

Important
If you are moving the content databases across domains or forests or into another environment that has different service accounts, ensure that the permissions for the service accounts are still correct before you attach the databases.

You can use either the Mount-SPContentDatabase cmdlet in Windows PowerShell or the addcontentdb Stsadm command to attach a content database to a Web application. Using the SharePoint Central Administration pages to attach a content database is not supported for upgrading.
Ensure that the account you use to attach the databases is a member of the db_owner fixed database role for the content databases that you want to upgrade.

Important

If you were using forms-based authentication, you will need to configure claims-based authentication for your Web application before you attach any databases. You must also create a policy to grant Full Control to the Web application to the user account that will be performing the database attach upgrade. For more information, see Configure forms-based authentication for a claims-based Web application (SharePoint Foundation 2010).

Tip

You cannot attach the same content database more than once to a farm, even on different Web applications. Each site collection in a content database has a GUID that is associated with it, which is registered in the configuration database. Therefore, you cannot add the same site collection twice to the farm, even in separate Web applications. Although you can successfully attach the database in this situation, you will be unable to start the site collection. If you need a duplicate copy of a site collection in the same farm, first attach the database that contains the site collection to a separate farm, and then use the Stsadm backup and restore operations to copy the site collection over to the other farm. The Stsadm backup and restore process creates a new GUID for the site collection.

To attach a content database to a Web application by using Windows PowerShell

1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin.
2. On the Start menu, click All Programs.
3. Click Microsoft SharePoint 2010 Products.
4. Click SharePoint 2010 Management Shell.
5. At the Windows PowerShell command prompt, type the following command:
   
   Copy

   Mount-SPContentDatabase -Name <DatabaseName> -DatabaseServer <ServerName> -WebApplication <URL> [-Updateuserexperience]
   

   Where:
   
   • <DatabaseName> is the name of the database you want to upgrade.
   • <ServerName> is server on which the database is stored.
   • <URL> is the URL for the Web application that will host the sites.
   • Updateuserexperience is the choice to update to the new user experience or stay in the old user experience (part of Visual Upgrade). When you include this parameter, the site is set to preview the new user experience. Omit this parameter if you want the site to remain in the old user experience after upgrade. For more information, see Plan visual upgrade (SharePoint Foundation 2010).

For more information, see Mount-SPContentDatabase.

Note
We recommend that you use Windows PowerShell when performing command-line administrative tasks. The Stsadm command-line tool has been deprecated, but is included to support compatibility with previous product versions.

To attach a content database to a Web application by using the Stsadm command-line tool

1. On the drive on which SharePoint Products and Technologies is installed, change to the following directory: %COMMONPROGRAMFILES%\Microsoft shared\Web server extensions\14\Bin.
2. Type the following command, and then press ENTER:
   stsadm -o addcontentdb -url <URL> -databasename <DatabaseName>
   [-databaseserver <ServerName>] [-databaseuser <UserName>]
   [-databasepassword <Password>] [-sitewarning <SiteWarningCount>]
   [-preserveolduserexperience true/false]
   [-sitemax <SiteMaxCount>]
   [-assignnewdatabaseid] [-clearchangelog]
   

   Note

   When you set the preserveolduserexperience parameter to true, the sites in the content database keep the look of the previous version after upgrade. When you set this parameter to false, the sites are upgraded to the new look and feel. The default for this parameter is true, which preserves the old look and feel. This parameter is part of the Visual Upgrade feature. For more information, see Plan visual upgrade (SharePoint Foundation 2010).

   For more information, see Addcontentdb: Stsadm operation (Windows SharePoint Services).

Verification: Verify upgrade for the first database

---

After you have attached a database, you can use the Upgrade Status page in Central Administration to check the status of upgrade on your site collections. After the upgrade process is complete, you can review the upgrade log file to see whether there were any issues during upgrade. Also, you can review each upgraded site to find and address any issues with how the content is displayed. For more information, see Verify upgrade and review upgraded sites (SharePoint Foundation 2010).
To view the Upgrade Status page

• In Central Administration, click Upgrade and Migration, and then click Check upgrade status.

To open the upgrade log file

• The upgrade error log file and the upgrade log file are located at %COMMONPROGRAMFILES%\Microsoft Shared\web server extensions\14\LOGS. The logs are named in the following format: Upgrade-YYYYMMDD-HHMMSS-SSS-error.log and Upgrade-YYYYMMDD-HHMMSS-SSS.log, where YYYYMMDD is the date and HHMMSS-SSS is the time (hours in 24-hour clock format, minutes, seconds, and milliseconds). An example for an upgrade error log is Upgrade-20090415-132126-374-error.log, and an example for an upgrade log is Upgrade-20090415-132126-374.log.
  

  Note
  The upgrade log file includes the name of the content database being upgraded.

Attach the remaining databases

---

After you restore the first content database and verify the upgrade by reviewing the upgrade log file, you can continue by restoring and upgrading the next database or databases. You can attach multiple databases at the same time in separate Command Prompt windows to run multiple upgrades at one time. After you successfully restore and upgrade all the content databases, you can review the sites to make sure that they were upgraded correctly.

Verification: Verify upgrade for additional databases

---

After upgrading any additional databases, view the Upgrade Status page to monitor progress and verify that the upgrade process is complete. Review the log file to identify any other issues, and then review each upgraded site to find and address any issues with how the content is displayed. For more information, see Verify upgrade and review upgraded sites (SharePoint Foundation 2010) and Manage visual upgrade (SharePoint Foundation 2010).

See Also

---

Concepts

Troubleshoot upgrade issues (SharePoint Foundation 2010)

Other Resources

Resource Center: Updates for SharePoint 2010 Products

MOSS 2007 to SharePoint 2013: Migration using Database Attach Method

MOSS 2007 to SharePoint 2013: Migration using Database Attach Method

In one of my projects, I got a chance to work on the migration where we have migrated contents from MOSS 2007 to SharePoint 2013 environment with the huge content of about 40+ databases and 11000+ sites. We had decided to start the upgrade process using the database attach method as this is the only supported method for upgrading from MOSS 2007 to SharePoint 2013 without much of complications.

Let me tell you, we cannot upgrade the content directly from MOSS 2007 release to SharePoint 2013. The changes between versions are too great, and the hardware requirements differ so much between versions that a direct upgrade is not possible or supported. However, we can perform a series of database-attach upgrades to first upgrade our content to SharePoint 2010 Products and then to SharePoint 2013. The upgrade method is almost similar from MOSS 2007 to SharePoint 2010 and then from SharePoint 2010 to SharePoint 2013.

This blog describes how to perform these sequential database-attach upgrades from MOSS 2007 to SharePoint 2010 and then to SharePoint 2013.

Run preupgradecheck in MOSS 2007 Server
Preupgradecheck will provide us the invaluable information regarding the SharePoint 2007 farm and actions that may be required to be taken prior to upgrading to SharePoint 2010/SharePoint 2013
Run the preupgradecheck as below in command prompt:
stsadm.exe -o preupgradecheck

Once you get “Operation completed successfully”, it will launch the “SharePoint Products and Technologies Pre-Upgrade Check Report”. It can also be located under the following location;
%COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\Logs\

Analyze the report and Fix the following settings:
• Identify any third party components used and deploy them to SharePoint 2010 and SharePoint 2013 site. E.g. Nintex, 3rd party features, including web parts, solutions and custom workflows
• Setup Incoming/Outgoing email settings in SharePoint 2010 and SharePoint 2013environment
• Modified Web.Config entries
• Configure Alternate Access Mappings (AAM)
• Find the missing webpart, event receivers or features if any and delete them

Take the Content Database Backup from MOSS 2007
Set the databases to read-only before taking backups.
• On the MOSS 2007’s database server, click Start, point to All Programs, Microsoft SQL Server, and then click SQL Server Management Studio.



• Traverse to Databases node by expanding the tree
• Right-click the name of the database that you want to set to read-only, and then click Properties.
• In the Properties dialog box, click the Options tab.
• Under State, select the Database Read-only to True, and then click OK

Backup the database:
Follow these steps to take back-up:
• Traverse to Databases node by expanding the tree.
• Right-click the database you want to back up, point to Tasks, and then click Backup Database



• In the SQL Server Backup dialog box, specify a name for the backup, select Back-up type – Full, select a destination, and then Click OK to start the backup process.

Restore the Backup on SharePoint 2010 SQL server
• Open the SQL Server Management studio, traverse to “Databases” node. Then right click the “Databases” node and choose “Restore Database…” from the context menu.



• Specify the Database name, Restore Source, Destination, File names in the screens.
• Click “OK” to start the restore operation and Wait for the restore to complete! The time of restoring database depends upon the database size and server’s capacity.
• Make the Read-Only database to false after restore

Create web application in SharePoint 2010
• In the SharePoint Central Administration, click on “Application Management” and click on “Create or extend Web application” under “SharePoint Web Application Management”.
• Again click on “Create Web application”. Set the settings according to the need.
• Don’t create any site collection.
• Install & Copy the solutions, file system changes (like images, themes) from MOSS 2007 to SharePoint 2010 server.

Remove content database of the newly created web application in SharePoint 2010

Now, we need to delete the content db of the newly created web application in order to avoid any URL conflicts. Run the below stsadm command:
stsadm -o deletecontentdb -url <http://url> -databasename <MOSS2007_Migration_Content>

Attach restored database with the newly created web application in SharePoint 2010
• Test the content database: Before attaching the content databases to the Web applications, use the Test-SPContentDatabase PowerShell cmdlet to verify that all of the custom components that you need for that database. It checks for all artifacts such as feature, setup files, web parts etc. that are referred in the content database are installed in the farm and provide you with a report.
• Test-SPContentDatabase -Name <DatabaseName> -WebApplication <URL>
• Delete the corrupted objects
• stsadm -o databaserepair -url <URL of SharePoint site> -databasename <name of database> -deletecorruption
• Attach the Content DB to Webapplication
• Finally, we need to attach the restored MOSS 2007 database to SharePoint 2010 by running the STSADM command
o The Content DB containing the root site collection is always applied first.
o The other content DBs can be applied in any order. Attach the Content DB of the Root Site collection First. And then Attach the Content DBs of other Site Collections.
stsadm.exe -o addcontentdb -url <URL of SharePoint site> -databasename <MOSS2007_Portal_Content>

• Or you can use the PowerShell cmd-let: Mount-SPContentDatabase
Mount-SPContentDatabase -Name <DatabaseName> – databaseServer <ServerName> -WebApplicationURL

Migrate from Classic Mode to Claims mode
SharePoint 2013 authentication mode is by default Claims mode, so during migration from any previous versions, make sure to migrate authentication from Classic to Claims mode. If the authentication type is Claims already, then ignore this step.

Refer this Tech-net guide on how to migrate to claims – http://technet.microsoft.com/en-us/library/gg251985.aspx

Post Migration fixes
Once the content database attachment process is over, we have to manually fix the below things:
• Migrate any List/Site stp’s present from previous version to next version
• Migrate InfoPath forms and change the url ’s to the new url and then publish forms
• Perform the Visual upgrade to get the look and feel of the next version
o Following are the commands used in PowerShell to do visual upgrade
o SharePoint 2010 visual upgrade using PowerShell

//Use this for entire webapplication
$w = get-spweb http://server/site
$w.webs | ForEach-Object {$_.UIversion = 4; $_.UIVersionConfigurationEnabled = $false; $_.update()}

//Use this for individual site
$web = Get-SPWeb http://server/site
$web.UIVersion = 4
$web.UIVersionConfigurationEnabled = 0
$web.Update()
SharePoint 2013 visual upgrade using PowerShell
Upgrade-SPSite “http://server/site” –VersionUpgrade

Similarly to migrate content from SharePoint 2010 to SharePoint 2013, follow the steps from 1 – 8. Once all the operations are done, browse the migrated site and check the functionality.

Reference:
http://technet.microsoft.com/en-us/library/ee947141(v=office.15)