Reflects the current release of Nintex for SharePoint 2016. For your version, please access assistance through the Help button in the product.
This topic describes how to split existing SharePoint and Nintex content databases.
If Nintex Workflow was installed using its default configuration of one all-inclusive database, this data can be divided and distributed to one or more new databases. If SharePoint content needs to be similarly subdivided, there is a SharePoint method to achieve this. This document describes a process using both methods in conjunction to achieve a 1-to-1 mapping of SharePoint and Nintex data.
Note: If you do not want a 1-to-1 mapping of SharePoint and Nintex content databases, the SharePoint content can be left as-is and only a dedicated Nintex database created and the Nintex data moved. With this mapping, whenever a backup and restore is done in the future, the entire SharePoint content database and all the Nintex Workflow content databases will need to be backed up at the same time and restored at the same time. For more information, see Backup and restore databases.
For guidance on planning database mapping and maintenance, see Design databases.
Please read this entire article to familiarize yourself with the process and its requirements. As always, Nintex recommends testing this process on a non-production environment first.
The SharePoint method for moving database content: The PowerShell Move-SPSite command is used to move the content of a SharePoint site collection from one database to another on the same SQL Server. This process can be done independently of Nintex – if a SharePoint site collection is given its own SharePoint content database, it will use its existing Nintex content database until directed otherwise.
The Nintex method for moving database content: The NWAdmin movedata command is used to move the Nintex workflow progress data of a site collection into its own Nintex content database. The new database can be created using the Central Administration interface, but the data itself must be remapped using NWAdmin.
To split a SharePoint content database and a Nintex content database to enable one-to-one content for each
To move SharePoint content from an existing content database to another database, use Windows PowerShell Move-SPSite.
This move will keep all GUIDs including SiteID. For more information on using this command, see Using Windows PowerShell Move-SPSite.
To test the process
To split out site collections to maintain a 1-to-1 mapping between SharePoint and Nintex Workflow content databases, use Move-SPSite in Windows PowerShell. This operation provides the ability to move a site collection to an another content database while preserving all SharePoint GUIDs (except the Content Database ID, of course).
For these procedures to work, the following conditions must be true.
For more information on Move-SPSite, see the following Microsoft articles.
Before performing the below steps, disable access to the farm using Microsoft’s standard methods.
This section describes the use of -movedata for the above example. For more information about this command, see NWAdmin Guide.
This operation is used to move all workflow progress data for a site collection to a selected workflow content database. This command should be run as the Farm Account, as this identity will have access to each workflow database.
The utility will begin by warning the user to pause all services that can run or interact with workflow. You will need to stop the web application that is to be restored. This includes stopping the IIS site mapped to the web application and stopping the SharePoint Timer Service and all servers in the farm. This is important: if the workflow data changes during the migration process it may become corrupted. Once the migration is complete, the tool will attempt to detect any changes to the data and handle this by warning the user and moving the changed data, but we recommend avoiding this situation.
In a command prompt, type the following.
nwadmin.exe -o moveData –Url http://YourFullyQualifiedDomanName/sites/sitename
The tool will list the workflow content databases that are configured with numeric identifiers and prompt the user to choose which of these databases the site collection workflow data should be moved in to.
The data for each workflow instance is moved one by one. If any fails to move, the tool will display error details and prompts the user either to retry moving the instance, skip the instance or abort the process, rolling back any changes.
Once the operation is complete, restart all services to continue workflow operation. From this point on, workflows in the site collection will use the new database. If any services were not stopped during the migration process, they will contain cached references to use the old database so it is critical they are restarted at this point (which will cause them to clear the cached database pointer and use the new database).
NWAdmin.exe -o MoveData [-Url <siteCollectionUrl>] [-SourceDatabase <connection string>] [-TargetDatabase <connection string>] [-RetainSourceData]
|-Url||The url to the top level site of the site collection that data will be moved for.|
|-SourceDatabase||A database connection string to the Nintex Workflow database to extract data from. Use when retrieving data from an external database not connected to the target environment.|
A database connection string to the Nintex Workflow database to move data from. If a value is not provided the console UI will prompt for the target database.