So the first one out is the simple backup/restore stsadm operations. The problem with this is that when doing the restore it’s not possible to specify what database to restore it to. So to be able to do this you need to lock the other content databases except the one you want to add it to. This might not be possible and the you could use a maintenance farm.

A much better option is the mergecontentdbs stsadm operation that was introduced in SP1 of Microsoft Office SharePoint Server 2007 and allows 3 different options. The first option only analyse the situation and calculate the amount of site collections in the content database and their size. The second option is to move all sites in the specified source content database and move them to the specified destination content database. Our last option is to use an xml file containing the sites that we want to move as an input file to the command and the operation will only move the sites specified in that xml-file

The best thing with the last option is that we can use the enumsites operation to get an xml file of all sites for our a specific web application.

Example: stsadm -o enumsites -url [webAppUrl] -showlocks > "D:tempsites.xml"

The only problem with the above is that if you have a large amount of site collection and a number of content databases you will need to modify the list and remove the site collections that should not be moved to another content database. Later in this post I will show you how this problem can easily be addressed using PowerShell

Before using the mergecontentdbs operation you should consider two things. The first one is that since the mergecontentdbs operation is using the Content Deployment API it’s not suitable for sites larger then 10 GB. The other is that if content is changed during the operation you will not only risk losing the content but it could also cause database corruption as described in this KB: http://support.microsoft.com/kb/969242. So before moving the sites it’s a good recommendation to lock the site collections before the move.

To solve this I created a PowerShell script that does the following:

1. Exports all the site collection for specific web application to an xml-file
2. Remove all sites in the file that is not located in the database I have specified
3. Sets the site collections to no access to prevent data loss
4. Move the sites from the source database to the destination database using the xml file
5. Offers you to make an IISreset on all WFEs in the farm (Recommended after the stsadm operation)
6. Set the site collection lock back to it’s original

$env:PATH = $env:PATH +
";C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions12BIN" 

$webAppUrl = "http://myWebAppUrl"
$sourceContentDB = "SourceContentDB"
$destinationContentDB = "DestinationContentDB"
$xmlfile = "d:tempsites.xml" 

# enumerate through all site collections and save them to the XML-file
Write-Host "Retreives all site collections located at"
$webAppUrl "and save it to " $xmlfile
stsadm -o enumsites -url $webAppUrl -showlocks > $xmlfile | out-null 

# Import the XML file content $sites = [xml](Get-Content $xmlfile)
# Remove only the site collections located in the source database
Write-Host "Cleaning up the" $xmlfile "file and remove sites that should not be affected"
$sites.Sites.Site | Where-Object {$_.ContentDatabase -ne $sourceContentdb} |
ForEach-Object { $_.ParentNode.RemoveChild($_) | out-null } 

# Enumerate through all the sites in the xml file and make necessary preparations 

foreach($site in $sites.sites.site) {
# Lock the sites to prevent errors when migration and data loss
Write-Host "Locking the site" $site.url "to prevent data loss"
stsadm -o setsitelock -url $site.URL -lock Noaccess
} 

# Moving sites
stsadm -o mergecontentdbs -url $webAppUrl -sourcedatabasename $sourceContentDB
  -destinationdatabasename $destinationContentDB -operation 3 -filename $xmlfile 

# Get the farm object to find get all the WFEs in the farm
[void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")
$farm = [Microsoft.SharePoint.Administration.SPFarm]::Local
Write-Host "To complete the move you need to make an IISreset on all WFEs in the farm"
Write-Host "You will now get the option to make an IISreset on all your WFEs"
Write-Host "" 

# Enumerate through all servers in the farm 

foreach ($svr in $farm.Servers) {
  foreach ($svc in $svr.ServiceInstances) {
    # If the server has the Windows SharePoint Services Web Application service it
    # is most likely it's a WFE.
    if($svc.TypeName -eq "Windows SharePoint Services Web Application"){
      # Ask if we should make an IISReset on the server
      $IISReset = Read-Host "Do you want to make an IIS-reset on"
      $svr.DisplayName "server (yes/No)?"
      if($IISReset.ToLower() -eq "yes") {
        iisreset $svr.DisplayName
      }
    }
  }
}
# Enumerate through all the sites in the xml file and finalize the move
foreach($site in $sites.sites.site) {
  # Set the original lockstate for the site collection
  Write-Host "Setting the original lock state for site" $site.url "to prevent data loss"
  stsadm -o setsitelock -url $site.URL -lock $site.Lock
}

You can download the script [Download not found]. Just make sure you run it with an account that has sufficient permissions as described in the enumcontentdbs TechNet article and to modify the first 4 paramaters.

Another option to move site collections is to use the Batch Site Manager that is included in the SharePoint Administration Toolkit. This tool is packaged as a solution that you deploy to your farm. When deployed (and activated), it will then have a new option in Central Administration under Application Management.

The tool allows you to very nicely see all site collection for each content database, select the ones you want to move and create a timer job for the move. The Batch Site Manager is using the stsadm operations backup and restore in the background. It usually takes a bit longer then the mergecontentdbs but you get the option to specify when the timer job should be run, where to store the temporary file and you can get a email notification telling you the status of the move. As you can see in the screenshot above the tool also offers you to batch locking and deletion of sites.

The Batch Site Manager is recommended to use with sites up to 15 GB. The mentioned recommendations for the both tools should be seen as recommendation and it’s possible to test your way forward and what works in your environment.

So what about really large site collections?
When moving really large sites none of the mentioned tools might work and you will then have to take on a different approach. In short this is what you need to do.

1. Set the site collection that needs to be moved (farm 1) to read only and make a SQL backup of the content database (ContentDB A).
2. Restore the content database with a new name (ContentDB B) and attach it to your Maintanence farm (Farm B) or if you don’t have one to a different web application. Make sure you use the –assignnewdatabaseid since we will later on restore the database back to it’s original location
3. When it’s attached to farm B, use the stsadm -deletesite operation using the -gradualdelete parameter (introduced in the April CU) to remove the sites from ContentDB B that should not be moved.
4. Backup the ContentDB B and restore it (but don’t attach it yet) to your Farm A
5. Delete the large site from ContentDB A using stsadm and -gradualdelete.
6. When the site is deleted you can attach ContentDB A to Farm A
7. Unlock the site collection when done.

The reason for that is that the rebuild of the index is quite aggressive in it’s nature and does not have any logic built in to it. It simply rebuilds the whole index daily.

If you look at the information from Microsoft at technet (http://technet.microsoft.com/en-us/library/cc678870.aspx) about the job it says:

If you have installed Office SharePoint Server 2007 with SP2:

• The job updates the query optimization statistics by sampling key tables every time that it runs, instead of performing a full scan.
• If you are running SQL Server 2005 or SQL Server 2008, the job rebuilds all indexes in the content databases every time that it runs.
• If you are running an Enterprise edition of SQL Server 2005 or SQL Server 2008, the job rebuilds most indexes online.
• If you are running a Standard edition of SQL Server 2005 or SQL Server 2008, the job rebuilds the indexes offline.
• If you are running SQL Server 2000, the job does not rebuild any indexes.

It actually also specifies that the job should only run weekly if you are running MOSS and daily if your using WSS. I assume that this is just a mistake in the documentation because in all environments I looked in it’s set to daily no matter if you are using Moss or WSS with SP2.

So what happens if you have a large environment where your have backups, or maybe a crawl running at the same time. Or maybe your SQL DBA’s have done their job and have their own reindex and update statistics job put directly in SQL? Well, you could run in to performance problems and extreme slow environments together with backups taking longer time then they should, error messages and maybe even corrupt databases. The later I have not seen but potentially it’s possible.

I’m not saying that bad things will happen to your environment with this job, but more of be aware and have a look at how this is configured in your environment. Maybe you should reschedule it if it’s in conflict with any other SQL job. And if you are not the SQL DBA talk to the DBAs and make sure that they don’t have any similar already in place. If they have, is it better with built in logic where they look at the fragmentation level? Then maybe you should disable the SharePoint Timer Job and only run the job put on the SQL server.

If you want to find out what settings you have you could first look in Central Administration. You have one Database Statistics job for each Web Application and you can see that under Operations and Timer Job Status. In the Timer Job Definition, found at the same place in Central administration, you can see if the job is run weekly or daily.
The best  way is however to use STSADM or SPDiag to get the information on when it’s scheduled. To reschedule jobs you need to use STSADM.

This is how you get the settings you have using STSADM:

stsadm -o getproperty -pn job-database-statistics -url http://YourSPSite

And to set a new value you do like this:

stsadm -o setproperty -pn job-database-statistics -pv “Weekly between Fri 22:00:00 and Sun 06:00:00″ -url http://YourSPSite

Here you have the STSADM reference for this particular task: http://technet.microsoft.com/en-us/library/cc424963.aspx

Listening to Shane and Todd is always entertaining, it’s like a mix of Chandler from Friends and Jim Carry (Is it only me that thinks they actually are quite alike from a distance?) giving you performance on stage. But they are very good on what they do and are very inspiring, so thanks guys!

So what did they talk about? Well, patching in SharePoint 2010 is such a relief for Admins. Finally we can install the bits on the machines, wait for our maint window and kick of the DB upgrade, and you want to do the psconfig? Well, you are now able to kick them of simultaneously on all your WFEs.

Another new feather is that you are now able to mount multiple content databases, it will of course put a heavy load on the SQL but find out what your system can handle and just run it to get up to speed.

In SharePoint 2010 you will now be able to monitor the upgrade and patching from Central Administration. It’s great! And you are able from a “dashboard” like page see the patch status of your servers, and if you are missing a patch on one of the servers that will be displayed and it will show where to find the patch with a link, just lovely.

Other things picked up from the session is that MS will continue to have CU (Cumulative updates) on an every other month basis. What Microsoft also has promised is to never push a SharePoint path out through Windows update, thank god!

This is a summary of the: Server and Health Monitoring session held by Dan Winter and Umesh Unnikrishnan at the SharePoint Conference 2009.

Are you on the admin side as me? Well then we have some really interesting things to look forward to in 2010. It’s just so much good things that I will not be able to get everything here. But to take 4 of then that was discussed at this session.

ULS Improvements.
They way to handle what is getting logged from Central Admin has been very much improved and with Event Throtteling and Event Flood Protection that basically is a way to say that; I have had this exact same errors during a short amount of time. I will stop logging this now.
You now have the option to set the amount of GB that you logs should be using and not only the, critical events will be sent to the logging database.
Together with the Correlation ID’s and the new ULS Viewer tool that was revealed today (and that will work on 2007 environments as well) you are able to easily find the problems and track them down. You find the ULS Viewer at: http://code.msdn.microsoft.com/ULSViewer

Logging Database
I wrote a bit yesterday about this but the logging database is a new database that will be set up by default where different log entries will end up and by doing so you are able to hook it up to SCOM (System Center Operation Manager) to manage your SharePoint farm. The DB schema is documented so be sure that this will end up in a lot of third-party products to help you monitor the logging database. MS will ship two reports with RTM and that will be: Slowest pages and most frequent users.

Developer dashboard
Feels like I have already covered it in my earlier posts, but what it basically is that it allows admins to get a report on each site on for instance what parts took long time to lead etc. Very useful!

Server Health
Last but not least is the new Server Health page in Central Administration. Here you get a dashboard of the servers in your farm. For instance, among the approx. 100 built in “rules”, for monitoring it might check for accounts used on Web applications, disk space etc. So you can from there see what you need to do and correct it. Best think is that this is extensible so that you can build your own rules and plug in to SharePoint.

I was sitting in my Moss environment and had a couple of tasks in front of me where I should recreate a web application we had been using for test purposes. We now wanted to recreate it and start all over again. So what I did was that I first went in to the Central Administration, selected the Web Application and then Content Databases. I selected the Content DB and clicked Delete.

I then recreated the Web Application with some changes in the setup from before, applied a couple of Solution Packages and then as a last step I should create a new Root Site Collection. This I did with STSADM. Then, when running the STSADM command I got an error message saying that there were already a site collection in the specified location. I double, triple and quadruple checked the syntax of my STSADM command, it was correct written. I then tried to surf to the site and for some reason there where what I just a couple of minutes earlier had deleted. It where somewhere here I started to lose faith on my memory, what did I just do? Have I could I have…

But as Dana Scully always said, -”There is always a logical explanation” and it certainly was this time as well. It turned out that If you delete the database from that Content Database list it just detaches the database and does not actually delete the database from the SQL server. But if you instead select delete Content Database when you delete the Web Application it’s deleted from the SQL Server. So what happened was that I recreated the Web Application I choose the same name for the Content DB as I just had used and the, not that surprisingly all content where still there.

Well, at least I learned something new, isn’t it wonderful with Mondays?