Notification Services

Finding Notification Services Instances

Joe Webb — Tue, 06 May 2008 20:31:03 GMT

As most you already know, Notification Services is not part of Microsoft SQL Server 2008. I think this is a shame since SSNS is really a great product. It may be rather complex at first glance, but it's a great product nonetheless. I'll probably devote a blog to it's abrupt deprecation at some point in the future.

In the meantime, if you're preparing to upgrade to SQL Server 2008, you should verify that you don't have any rogue SSNS instances running on any of your servers. I hope your environment is more controlled than that, but I've seen more than one shop where change control was, well in a word, uncontrolled.

So, how can you tell if a server has a SSNS installed on it? Run the following query in the msdb database. It'll list all SSNS instances installed on that SQL Server instance.

SELECT 
     InstanceName
    ,DatabaseName
FROM     msdb.NS90.NSInstances

Cheers!

Joe

Upgrading to SSNS 2005

Joe Webb — Thu, 06 Mar 2008 13:30:13 GMT

Last week, I completed an upgrade of a SQL Server 2000 server to SQL Server 2005. Not really a big deal; servers are routinely upgraded to a newer version of software. Sometimes it seems the upgrades come too quickly. Other times it seems like we are waiting for the proverbial pot of water to boil while eagerly looking forward the next release.

This server, however, included a Notification Services instance. It got me to thinking about upgrades and some of the changes in SSNS between v2.0 and 2005. I've compiled a "Top 10" list of enhancements to SSNS 2005. (I wish I could have composed the Top 10 list for SQL Server 2008, but alas it's not there. I'm sure we're all aware by now of the its premature deprecation. That'll be the topic of another blog.)

Number 10. Support for the 64-bit platform.
As an add-on for the prior version of SQL Server, SQLNS was not supported on a 64-bit installation. In 2005, it is.

Number 9. Hostable execution engine.
With the newer version, each SQLNS instance may be hosted within an existing application or process; it no longer requires that a NS$InstanceName service be created.

Number 8. Better vacuuming performance.
The vacuumer now transverses through the obsolete data in a much more efficient manner.

Number 7. Analysis Services Event Provider.
You may now use MDX queries to collect event information.

Number 6. Management API.
The Microsoft.SqlServer.Management.nmo API may be used to programmatically create and manage SQLNS instances.

Number 5. Database independence.
The database objects historically created in the instance and application databases may now be created in a database that we specify during the build process.

Number 4. Subscriber defined conditions.
Under certain circumstances, subscribers may define query clauses over a pre-defined dataset.

Number 3. Management Studio integration.
SQLNS is now a full-fledged part of SQL Server and it\u2019s been integrated into Management Studio.

Number 2. New views.
There are new views in SQLNS 2005 we can use to create and manage subscribers, devices, and subscriptions using T-SQL. (Click here to see a prior post on this subject.)

And the Number 1 feature. Goodbye Notify() function!
A new view allows us to write T-SQL code in our matching rules which is not only more intuitive, but also offers improved performance. (Click here to see a prior post on this feature.)

And there you have it. My Top 10 List of new and greatly appreciated features in SQLNS 2005.

As for conducting the upgrade, here are a couple of resources to help.

Cheers!

Joe

Moving a Notification Services database

Joe Webb — Thu, 14 Feb 2008 13:46:24 GMT

The old adage "An ounce of prevention is worth a pound of cure" can be applied to many topics and areas of life. And while it has its origins in personal health care, nowhere is it more true than in an IT shop. Whether you're talking about high availability solutions or starting with a good database design, planning ahead is well worth the effort. Anyone who has been through an IT crisis can testify to that!

But alas, we live in a dynamic world and we can only make calculated guesses at what the the ounce of prevention should be. Sometimes we cannot anticipate what the future holds in store and we must adapt.

For example in my consultancy, I was recently asked to move all SQL Server databases to another drive on the client's server. No problem! Using sp_detach_db and sp_attach_db this is straightforward. Even moving the Master database and the other system databases is relatively simple using the process documented in the MSDN article.

But what about moving a SQLNS database? Can those simply be moved using the normal detach/attach methodology?

The short answer is yes, but!

Although the move process works, subsequent updates to the instance will be ineffective unless we take some additional actions.

When we attempt to update an SSNS instance, the configuration settings in the ICF and ADF files are compared to the current settings of the instance so that SSNS will know what changes to make to the instance. The update process also checks to ensure the validity of the new and old configurations. Herein lies the problem.

When we created the SQLNS instance, we had the choice of whether to create a new instance and application database or to use an existing database. To have a new one created for us, we had to specify the location of the database files in the FileName element of the ICF and ADF configuration files. This is shown below.

    <!--Instance database information-->    
    <Database>         
	<NamedFileGroup>
		 <FileGroupName>Primary</FileGroupName>
		 <FileSpec>
		 	<LogicalName>PrimaryFG</LogicalName>
		 	<FileName>
				C:\MSSQL\Data\ABCPressData.mdf
			</FileName>
		 	<Size>2MB</Size>
		 	<MaxSize>10MB</MaxSize>
		 	<GrowthIncrement>10%</GrowthIncrement>
		 </FileSpec>
	 </NamedFileGroup>
	 <LogFile>
		 <LogicalName>PrimaryLF</LogicalName>
		 <FileName>
			C:\MSSQL\Data\ABCPressLog.ldf
		</FileName>
		 <Size>1MB</Size>
		 <MaxSize>10MB</MaxSize>
		 <GrowthIncrement>10%</GrowthIncrement>
	 </LogFile>        
    </Database>

Later when we attempt to update the instance, the process will verify that the database files exist in the location defined in the FileName element of the configuration file. Since we just moved them, it will of course not be able to find them so the upgrade will abort with an error.

The obvious solution is to simply update the ICF and ADF file to reflect the new location of the database files. And that is indeed part of the answer. But according to Books Online, the FileName element of the ADF cannot be updated after the instance is built. So if you only change the FileName elements and attempt to run the update again, you'll receive another error.

You see, the location of each database file as defined in the original ICF and ADF is stored in the instance and application database itself. This can be seen using the following T-SQL and in the figure below, where ABCPressNSMain is the name of my Instance database and ABCPressPressRelease is the name of the associated application database.

SELECT 
      * 
FROM 
      ABCPressNSMain.dbo.NSDatabaseFiles;

SELECT 
      * 
FROM 
      ABCPressPressReleases.dbo.NSDatabaseFiles;

The update process compares the location as documented in the database itself with the information provided in the configuration files. If the two differ, the update aborts with another error.

So, how can we move the database files? In addition to updating the location in the ICF and ADF files, we need to update the information in the NSDatabaseFiles tables of the instance and application databases to reflect the new location. You can use the following T-SQL to do this. Of course you'll need to modify these statements with the name of your instance and application databases.

UPDATE 
      ABCPressNSMain.dbo.NSDatabaseFiles
SET 
      FilePath = 'E:\MSSQL\9.0\Data\ABCPressData.mdf' 
WHERE 
      FileId = 1;

UPDATE 
      ABCPressNSMain.dbo.NSDatabaseFiles
SET 
      FilePath = 'E:\MSSQL\9.0\Data\ABCPressLog.ldf' 
WHERE 
      FileId = 2; 

UPDATE 
      ABCPressPressReleases.dbo.NSDatabaseFiles
SET 
      FilePath = 'E:\MSSQL\9.0\Data\PressReleaseData.mdf' 
WHERE 
      FileId = 1;

UPDATE 
      ABCPressPressReleases.dbo.NSDatabaseFiles
SET 
      FilePath = 'E:\MSSQL\9.0\Data\PressReleaseLog.ldf' 
WHERE 
      FileId = 2;

Once you've done these two steps - updating the configuration files and the FilePath column in the instance and application database - future updates should work without problem.

Now for the caveat. Microsoft strongly discourages direct manipulation of the underlying tables in a SQLNS instance. I generally try to follow that advice. And although I have not found the process that I've described here to have any adverse side affects, you'll of course want to backup the databases, configuration files, etc, just in case.

Happy Notifying!

Joe

Using the SSNS Management.NMO NameSpace

Joe Webb — Thu, 31 Jan 2008 15:32:10 GMT

One the more welcomed enhancements of SQL Server 2005 Notification Services was the new Microsoft.SqlServer.Management.Nmo namespace. The namespace provides classes that may be used develop and administer SSNS instances and applications.

For example, the following C# console application may be used to iterate through each SSNS instance of a SQL Server 2005 instance, printing its name to the console window. If you'd like to try this code for yourself, don't forget to add a reference to the microsoft.sqlserver.smo.dll in your Visual Studio 2005 project.

using System;

using Microsoft.SqlServer.Management.Nmo;

using Microsoft.SqlServer.Management.Smo;

namespace ConsoleApp

    class Program

        static void Main(string[] args)

            //SQL Server instance

            string myServer = @"CEDAR\SS2005";

            Server server = new Server(myServer);

            //Notification Services object

            NotificationServices ns = server.NotificationServices;

            //enumerate through each instances

            for (int cnt = 0; cnt < ns.Instances.Count; cnt++)

                string nam = ns.Instances[cnt].Name;

                Console.WriteLine(nam);

            //pause to view the output

            Console.WriteLine("Press the Enter key to continue");

            Console.Read();

Although the quickest way to create a SSNS instance and application is still to craft an XML-based Instance Configuration File (ICF) and Application Definition File (ADF), it's nice to have the nmo namespace available to automate some tasks as needed.

Cheers!

Joe

SQL Server Notification Services Resources

Joe Webb — Wed, 23 Jan 2008 03:18:22 GMT

In my initial post here on the SQLTeam site, I mentioned that for the prior three years I had blogged on another site. That blog was almost exclusively dedicated to SQL Server Notification Services.

If you are a regular reader of this new blog, you've undoubtedly noticed that I've broadened the scope to include topics of interest to DBAs, database developers, and general technologists.

As time permits, I'm still attempting to recover the SSNS tutorials and commentary from my prior blog. I'll post what I can recover as it becomes available.

In the meantime, here are a few links to other SSNS-related resources I've written over the years.

SQL Server Notification Services Architecture - An SQL Server Central article that was adapted from a chapter in The Rational Guide to: SQL Server Notification Services.
Building Effective SQL Server Notification Applications, part 1 - A Simple-Talk article that provides a step by step path for upgrading to SSNS 2005 from SSNS 2.0
Building Effective SQL Server Notification Application, part 2 - A Simple-Talk article that discusses what I consider to be the top 10 enhancements in SSNS 2005.
Creating a Custom Content Formatter for SSNS 2005 - A Simple-Talk article that demonstrates how SSNS can be extended beyond its built-in content formatter.
SQL Server 2005 Upgrade Technical Reference Guide - One chapter in this 350 page upgrade guide is dedicated to the changes required to upgrade or migrate to SSNS 2005 from SSNS 2.0.

I hope you find these articles of interest.

Cheers!

Joe

Creating a Notification Services Instance

Joe Webb — Wed, 09 Jan 2008 04:19:20 GMT

Even though SQL Server 2008 does not include the Notification Services (SSNS) component, it seems that companies still consider SSNS a very viable option for upcoming notification projects. I'm planning to write a blog or SQLTeam article in the near future to address some questions I'm frequently asked.

In the meantime, if you have decided to create a new notification application using SSNS, I'm reposting a short tutorial I created a couple of years ago. It's been modified and updated slightly.

In this blog we'll go through the simple steps that can be used to create a new SQL Server 2005 Notification Services instance using Management Studio. I've included a series of images to help illustrate the process.

Step 1:

After you've installed SQL Server 2005 and Notification Services, you'll find a Notification Services folder in the Object Explorer. Initially this will be empty since there are no instances defined. By right-clicking on the folder you'll expose a context menu that allows you to create a new instance. This is illustrated in Figure 1.

Figure 1 - Creating a new instance.

Step 2:

Click the New Notification Services Instance menu item on the context menu to open a New Notification Services Instance dialog window. This window allows you to select the Instance Configuration File for the instance. Click the Browse button to navigate to the file you've created. You do not have to select the Application Definition Files; they are defined in the Instance Configuration File. Click Ok to create the instance. Figure 2 depicts the New Notification Services Instance dialog window.

Figure 2 - Selecting the ICF.

Step 3:

If everything is configured correctly in your ICF (Instance Configuration File), a new instance is created. You can watch the progress and examine the final results in a dialog window as shown in Figure 3.

Figure 3 - Examining the results.

Step 4:

After the instance is created, it may be registered by right-clicking the instance in Management Studio and selecting Tasks, Register as demonstrated in Figure 4.

Figure 4 - Registering the instance.

This will open a Register Instance dialog windows that allows you to configure the service account for the Windows Service and its authentication credentials for SQL Server 2005. The Register Instance dialog window is shown in Figure 5.

Figure 5 - Specifying credentials.

After clicking Ok to register the instance, progress will be reported in the Registering Instance window shown in Figure 6.

Figure 6 - Examining the registration progress.

Step 5:

Next Management Studio may be used to enable the instance as shown in Figure 7.

Figure 7 - Enabling the instance.

Step 6:

Finally Figure 8 depicts how Management Studio may be used to start the Windows service.

Figure 8 - Starting the instance.

And there you have it; if everything has gone well you have a functioning SQL Server 2005 Notification Services instance running on your computer. If you've encountered an error along the way, the progress dialog windows generally provide enough information for you be start troubleshooting the ICF.

If you're a command line junkie or just prefer the predictable results of scripting out the steps, don't worry, NSControl is still around in SQL Server 2005 Notification Services. But it sure is nice to have a graphical method, too.

Cheers!

SQL Server 2005 Notification Services web cast

Joe Webb — Sun, 30 Dec 2007 14:45:38 GMT

Microsoft's Ken Henderson hosted a web cast called “Introducing Notification Services in SQL Server 2005”. It was recorded three years, but it’s still a great material. If you’ve ever sat in on one of his sessions at PASS, you know he’s a great presenter.

Of course much to my and other's chagrin, SQL Server Notification Services is not part of the SQL Server 2008 product. Perhaps that will become the fodder for another post.

In the meantime, enjoy the web cast!

Cheers!

DevLink Technical Conference presentation

Joe Webb — Mon, 15 Oct 2007 13:19:09 GMT

Thanks to all of you who attended the DevLink Technical Conference in Nashville, Tennessee! It was great to see such a turnout for the event. Big kudos goes to all those who carried the load and championed this event. Putting on an event like this is no minor task and is definitely a labor of love.

As promised in my session, here are the presentation materials I used - the slide deck and the demo scripts.

I hope you found it worth your while.

Cheers!

Joe

SSNS Status Codes

Joe Webb — Tue, 25 Sep 2007 03:09:28 GMT

Have you ever been troubleshooting a SQLNS instance and noticed the status code column in some of the views and underlying tables? For example, the NSSMTPNotifications view has a column named DeliveryStatusCode with a values that range from 0 to 6. But what does that mean? What does a value of 6 actually tell you?

Fortunately, the SSNS database contains tables with status code descriptions. Try running the following query in your application database. Note: you'll need to replace dbo with the appropriate schema name.

SELECT * FROM dbo.NSNotificationDeliveryStatusCodes

Figure 1 shows the results. You can see that a value of 6 in the Description column of the view indicates Delivery succeeded.

Here are some other status code lookup tables that you may find useful as you troubleshoot your SQLNS instance.

SELECT * FROM dbo.NSDistributorWorkItemStatusCodes

SELECT * FROM dbo.NSNotificationBatchesStatusCodes

SELECT * FROM dbo.NSNotificationDeliveryStatusCodes

SELECT * FROM dbo.NSQuantumStatusCodes

SELECT * FROM dbo.NSRuleFiringStatusCodes

SELECT * FROM dbo.NSVacuumProcReturnCodes

Cheers!

Joe

Come out, come out, wherever you are: Finding SSNS instances using T-SQL

Joe Webb — Thu, 23 Aug 2007 13:59:40 GMT

As database professionals, we may responsible for dozens, if not scores, of SQL Servers throughout our department or enterprise. Now that Microsoft has announced that Notification Services will not ship as part of the SQL Server 2008 product, how can you readily identify which of the servers in your charge have SSNS instances installed?

Fortunately for us it's rather easy. SSNS 2005 registers each installed instance in the msdb system database. The following query returns a list of every SSNS instance for the SQL Server instance.

SELECT
*
FROM
msdb.NS90.NSInstanceInfo

To retrieve a list of all SSNS applications for the given SQL Server instance, you can run the following query.

SELECT
*
FROM
msdb.NS90.NSApplicationInfo

As you make preparations for Katmai, you can run these scripts using your mechanism of choice to examine each server in your environment.

Cheers!

Joe