Gripes

Database Mail on a cluster

Tara Kizer — Tue, 20 Feb 2007 19:49:36 GMT

In our production environment, we have two 4-node clusters. One cluster runs at the primary site; the other cluster runs at our disaster recovery site. Each cluster is running 11 SQL Server 2005 instances.

We setup Database Mail on all of the instances at both sites, so that we could e-mail internal customers the results of various ad-hoc queries. It was soon realized that Database Mail was not working properly at the primary site on any of the 11 instances. We got our Exchange, server, and network administrators involved, but we were unable to figure out what was wrong. We never received any errors but yet no e-mail was ever received. Since we were unable to resolve the issue, we decided to open a case with Microsoft. One of the things that they had me to do was increase the logging level of Database Mail so that it was more verbose. After the configuration change was made, I attempted to send an e-mail with Database Mail. As usual, no error was returned but also the e-mail never made it out of SQL Server. Microsoft wanted me to send them the Application Log in Event Viewer. While preparing to do this, I noticed the following error in it:

An error has occurred while establishing a connection to the server. When connecting to SQL Server 2005, this failure may be caused by the fact that under the default settings SQL Server does not allow remote connections.

Since remote connections was enabled on all of the instances, I decided to add an alias for one of the instances on all 4 nodes of the cluster. This worked, so I reported my findings back to Microsoft. After a bit of time, they reported back to me that the SQL Browser service was the culprit.

They don't have an exact reason as to why the SQL Browser service is unable to connect to a local instance (meaning an instance that is on the node where the service is running), but they did provide possible reasons:

Clustering

SQL Server Browser is not a clustered resource and does not support failover from one cluster node to the other. Therefore, in the case of a cluster, SQL Server Browser should be installed and turned on for each node of the cluster. On clusters, SQL Server Browser listens on IP_ANY.

Note: When listening on IP_ANY, when you enable listening on specific IPs, the user must configure the same TCP port on each IP, because SQL Server Browser returns the first IP/port pair that it encounters.

Using a Firewall

To communicate with the SQL Server Browser service on a server behind a firewall, open UDP port 1434, in addition to the TCP port used by SQL Server (e.g. 1433). For information about working with a firewall, see "How to: Configure a Firewall for SQL Server Access" in SQL Server Books Online.

If you are unable to get Database Mail to send e-mails when the SQL Server 2005 instance is on a cluster, try adding an alias for the virtual server. You can easily add aliases using the SQL Server Configuration Manager tool.

Something that I am dealing with today

Tara Duggan — Tue, 07 Oct 2003 21:56:00 GMT

Well today has definitely been interesting. I have been working with a co-worker who is responsible for trouble shooting customer problems. This specific customer is running our product with MSDE. We do not have dial-up access to the server, so everything is being done over the phone, plus the customer speaks Spanish, which I do not. It's hard enough explaining what to type at a cmd window to correct this problem and not knowing what they are typing cuz you can't see the screen. All that we are trying to do is recreate a user and grant sysadmin rights. I have been sending the commands to my co-worker through MS messenger who is translating them to the customer over the phone. But it just isn't working, most likely due to a typo. He is e-mailing the commands to the customer now. My poor co-worker has to deal with this kind of stuff everyday; I feel so bad for that team.

My gripe today

Tara Duggan — Tue, 30 Sep 2003 19:18:00 GMT

I have been asked to look into why a stored procedure is failing. The problem is that the application gets an error that a temp table doesn't exist. Here is the code with the problem (my comments in blue, contents were changed to protect company information):

       FETCH NEXT FROM @cursor
        INTO @ID, @Name

        IF @@FETCH_STATUS <> 0  This doesn't make sense, nor does the next WHILE statement. It says if there are records in the cursor (which is SELECT * FROM a temp table), drop the temp table, get rid of the cursor, raise an error that something couldn't be found. BUT IT WAS FOUND because there are records in the temp table.
        BEGIN
                DROP TABLE #tmp
                CLOSE @cursor
                DEALLOCATE @cursor
                RAISERROR('Raise Some Error',10,1,'LOG')
                RETURN 2
        END


        WHILE @@FETCH_STATUS = 0        This says if there aren't any records in the temp table, go to the next record in the temp table. BUT THERE AREN'T ANY!
        BEGIN

                SELECT @SomeString = @SomeString + ','

                FETCH NEXT FROM @cursor
                INTO @ID, @Name

        END

        DROP TABLE #tmp  This is where the app is having problems. It should check to see if the table exists first. The table is getting dropped above, so this statement will never work with the current logic problems.
        CLOSE @cursor
        DEALLOCATE @cursor

The WHILE statements should be reversed. The first one should be WHILE @@FETCH_STATUS = 0, and the second one should be WHILE @@FETCH_STATUS <> 0. If there was ever a time where the temp table didn't have any records, the stored procedure would go into an infinite loop.  Also, the other records in the temp table never get processed since it drops the temp table before doing anything with them.

Now I didn't write the stored procedure but need to fix it. Just complaining...