Showing posts with label SQL Server 2008 R2. Show all posts
Showing posts with label SQL Server 2008 R2. Show all posts

Wednesday, 4 July 2012

SQL Server CPU running at 100% during a full or incremental crawl


We were researching which SQL versions were ok while troubleshooting a problem we had with the SQL Server CPU running at 100% during a full or incremental crawl.
After verifying there were no bottlenecks elsewhere in the farm we turned to SQL and CU version.
Despite there being no errors on the SQL server the SQL guy noticed that some of the SQL queries were not being handled well. 
We were running SQL 2008 R2 Service Pack 1 with Cumulative Update 3 so re-check for recommended SQL versions.


SharePoint 2010 and SQL Hotfix Dependencies
SharePoint Joel has a great article on SQL versions and hotfix dependencies

The above article showed that we should be ok but a short Google later turned up these chaps with the same issue with SQL CPU running at 100%.


An upgrade to SQL 2008 R2 SP1 CU 7 fixed the problem and we were able to do a Search Content source crawl without crippling our SQL server. 



This SQL article has more info on the issue.
Article ID: 2658214 - Last Review: April 12, 2012 - Revision: 5.0
FIX: Poor performance when you run a query that contains correlated AND predicates in SQL Server 2008 or in SQL Server 2008 R2 or in SQL Server 2012
To resolve this issue, apply the following cumulative update. After you apply the update, you must enable trace flag 4137 to add the new logic for the cardinality estimation of AND predicates.
After patching it is necessary to add the switch /4137 (or -4137) as a startup parameter for the patched SQL instance in order to activate the remedy for this particular problem

Wednesday, 18 April 2012

Move SharePoint content to another Farm by backing up and restoring the SQL DB


At some point you will need to restore/move/backfill content from a Production Farm to a test or developer Farm.
You can do this by copying the SQL DB to your test SQL server and reattaching the DB in CA to the Target web application.

A few things to remember :
You will have to have the same solutions deployed on your target Farm.
Check the dependencies of any service applications i.e. Managed Metadata Service & others...
Make sure you have the same SQL server versions on target and source.

These instructions are for SQL Server 2008 R2 and SP 2010.
It is also possible to do this via PS, check the article at the end for further details.


On SQL Server
Get the current SQL permissions set on your target SQL DB.

Check the permissions set on the DB.

1.      SQL DB Properties > Files > Owner > record the account listed
2.      SQL DB Properties > Files > Permissions > record the accounts listed
3.      Security > Logins > accounts from step 2 >  Properties > User Mapping > select the target DB name > select source DB > record Permissions listed

Create a SQL DB backup of your Source web application DB.
Right click your target DB > Tasks > Backup > Backup type > select Full
Under Destination > Click remove > Click add > File name > browse … > Select your backup dir > enter a relevant filename > click ok > ok
Click OK to kick off your backup.
Copy the source SQL DB backup to your Target SQL Server.


To have a recovery option in case this doesn’t work. Backup your target SP web application DB either in SQL or via a SP Farm backup, both if you want to cover all bases.



On your SP Farm
At this point I normally stop the IIS sites on all SP WFE’s that use this target SQL DB to try stop connections to the DB’s. timer jobs may still kick off though.

On your target SP Farm, navigate to > Central Admin > application management > Databases > Manage content databases > Select you web application > select the target DB Name.
Select “Remove content DB” > OK


On SQL Server
On the target SQL server, restore the source DB over the Target DB
Check there are no connections to the source DB.
In SQL mgmt Studio, right click the server > Activity monitor > expand processes > filter by target db > right click and Kill Process on any connections.
Close the activity Monitor pane.

Right click your target DB > Tasks > Restore > Database.
Under To Database > ensure the target DB is selected.
Unser Source for restore select From Device > browse … > backup media File > Click Add > browse to backup location and source DB Backup file > click ok > Ok
Select the backup sets to restore > check the box
Select Options on the left > restore options > Overwrite the existing DB (with replace)
Click OK to kick off the restore.

Once completed, refresh the DB view, right click the restored DB > Files > Change the Owner to the correct account listed in step 1. Above (normally your SP farm account)
Click ok
Expand the target DB > select security > Users > remove any accounts from your source SP farm.

From the top level of SQL mgmt Studio, Select the server > Security > Logins > Select the equivalent account listed above in step 2. for your target SP Farm.
Right click > properties > user mapping > Users mapped to this login > select the target DB name > enable the permissions listed from step 3. above > click OK.

Your target DB should now have the same permissions set as before the restore.


On your SP Farm
On your target SP Farm, navigate to Central Admin > application management > Databases > Manage content databases > Select you web application > click “Add a Content DB”
Ensure the correct Web application and Database Server is listed.
Under “Database Name” Enter the target DB name.
Enter any configuration specifics, if any for the rest of the DB settings.
Click OK.

Your restored DB should now be attached successfully.
Start all IIS sites that use the Target DB’s is you stopped them.
Reset IIS on your WFE’s if you can.  
If you have a warm up script for your target web application, run this then access the site.

The site should eventually come up, if you got all your SQL permissions correct.
It can be really slow sometimes so be patient.


Natalia Tsymbalenko has some common errors in this useful article.
How restore a SharePoint 2010 content database on the different farm :