As most of you know, the Database Mail feature in SQL Server 2008 is the life blood of any notification system for your instances. If Database Mail fails to send notifications, you may not be warned if a job fails, or worst, a backup job. We had a server last week that was exhibiting a weird behavior within Database Mail. I was receiving mail from all parts of the Database Mail environment except for Agent Job Notifications. I was able to send test emails from Database Mail, able to receive maintenance plan summary reports and even receive emails from within maintenance plans using the notification task. Why was Agent Job Notifications the only area that was mis-behaving? As I started diagnosing the issue I checked the main areas that usually stumped me in the past:
- Verified database mail profile was enabled under SQL Server agent (Alert System Page)
- Verified profile security was public and default
- Restarted SQL Server Agent
The above three items usually resolved any issue I have with Database Mail. Did some more testing with my Agent Job and sure enough, still not working. Then I started digging into the logs, under SQL Server 2008 you can see logs from SQL Server, SQL Server Agent, Database Mail, and Windows all under the same screen. I dove into the Database Mail Log and there was an error for “ An attempt was made to send an email when no email session has been established”. Never seen this before. I started searching Google and found similar issues but none seemed to fit my situation or solve my problem. Because we have a simple setup for Database Mail, one account and one profile, I decided to rebuilt the configuration.
I deleted the profile and account, and then went back in and went through a complete rebuilt of the configuration. I used the same account and same profile settings as before. After I had the Database Mail configuration complete, I needed to make sure the profile was enabled under SQL Server Agent. Right click on SQL Server Agent and click Properties. Under the Alert System page, make sure Enable Database Mail is enabled and that your mail system is selected along with the correct profile name. With that done, I need to restart the SQL Server Agent. Upon restart the 264 error did not appear and I was able to receive emails from my Agent Job Notifications. Don’t know what caused the issue in the first place, but the rebuild seemed to clear things up.
As the name suggests, SQL Family feels like family. There is no other professional organization in the world that supports a product line as well as #SQLFamily. My introduction to #SQLFamily was in the summer of 2011 when I decided to get back into SQL Server full-time after going to the dark side, management, for the two previous years. I had a strong background in SQL Server 2000 & 2005 but not the full-time experience under 2008 & 2008 R2.
As I started searching for training opportunities for SQL Server, I came across Pragmatic Works. Every Tuesday and Thursday throughout the year, they have a one hour web cast on all areas of SQL Server. This allowed me to catch up on what was new under 2008 and brush up on the daily DBA tasks that I was accustomed to. Each of the presenters had a personal blog and twitter address that had even more content over the session that was offered. This got me interested in blogging for myself and starting to use twitter. As I started searching for ways to get started in blogging and using twitter, I came across Brent Ozar (blog, twitter). He built a great guide to help understand what twitter was all about. I wasn’t interested in following celebrities or sports figures, I just wanted to use it for SQL Server. It just so happened that Brent was a DBA and a photographer. This one-two punch was just the right mix to start me on my way into WordPress and Twitter.
As I started following Brent, I started reading posts from him and other SQL Server professionals about the passion the SQL Server community had for helping others. This was perfect for me as I started on my way to becoming a full-time DBA. Each new blog entry or twitter post gave me a new understand of SQL Server and how strong the community was. This also introduced me to PASS and the local user groups that were offered in my area. As I started attending the local events, that same passion within the on-line community was equally as strong at the local level. This allowed me to network with other SQL Server DBAs and get their input on ways to get back into the field full-time.
The local PASS events lead me to SQL Saturday. I was able to attend the Atlanta #89 event in the fall of 2011. This was very eye-opening for me. There were over 400 people gathered for a full day of free training on a Saturday. I was finally able to meet a few folks that I had only meet via twitter. The highlight for me was hearing Bob Ward from Microsoft talk about wait types. His session was level 500 and then some. It was cool to see the inter-workings of SQL Server from one of the people who has access to the source code.
By the fall of 2011, I was already talking to a few companies about DBA positions and felt confident about finding the perfect DBA job. As I accepted my current DBA role, I thought back to the family that got me there. With out #SQLFamily, this would have not been possible. This has given me the drive to give back to the community so others out there can find their perfect DBA role like I did. My first step is our local PASS chapter and presenting during the summer of 2012. I’m also working on blogging more regularly throughout the month, so others can learn from my view of being a SQL Server DBA.
I love being a part of the #SQLFamily. Looking forward to a great year in 2012!
Being raised within SQL Server 6.5 & 7.0, SQL Server instances were not available in those versions. I never fully understood the advantage of having multiple instances on the same server so I never embraced it. I always had a single, default instance per physical server. Once I got involved with virtualization a few years ago, having multiple instances of an OS running on a single physical server finally got me thinking about multiple instances of SQL Server.
My lab at home has been the perfect place to install, configure and understand multiple SQL Server instances. I have two servers running ESXi 4.1 U1 and VM’s to support a small Windows Domain.
I started with a copy of Windows Server 2008 R2 64bit as the guest OS. I installed my first copy of SQL Server 2005 Standard under a named instance of SQL03\SQL2005Standard (I currently don’t have a standard instance of SQL Server installed on this VM). I then proceeded to install SQL Server 2005 Enterprise, SQL Server 2008 Standard & SQL Server 2008 Enterprise all as named instances on the same VM as SQL03\SQL2005Ent, SQL03\SQL2008Standard, SQL03\SQL2008Ent, respectively.
Here is what I learned about supporting multiple instances of SQL Server from a DBA point of view:
- The default instance of SQL Server, known as MSSQLSERVER, runs under TCP port 1433
- Under Windows Server 2008, the firewall is enabled by default so you need to create inbound rules to allow outside connections to be able to reach SQL Server.
- SQL Server Browser service is responsible for taking requests for named instances and forwarding them to the correct port, whether it’s dynamic or statically configured. If there are no named instances of SQL Server, the Browser service is not required.
- The SQL Server Browser service runs under UDP port number 1434. This will need to be opened under the firewall.
- With out the SQL Server Browser service running, you would need to provide the IP and Port number (xxx.xxx.xxx.xxx:yyyy) in order to connect to a SQL Server instance.
- To connect to a SQL Server instance by name, you use the <computer name>\<instance name> syntax.
- By default, named instances are set to dynamic ports. This causes an issue trying to open ports on the Windows firewall because each time SQL Server is restarted a new port can be set. With the firewall enabled, it’s best to switch to static ports for all named instances and then create inbound rules for those TCP ports.
- If you prefer to use dynamic ports, you can also exclude the sqlserver.exe process from the firewall. This would allow inbound connections for just the SQL Server process and thus all clients to connect to dynamic or static ports without having to create individual rules for each TCP port number.
- To set an instance to a static port, open SQL Server Configuration Manager (SSCM) and drill through SQL Server Network Configuration and expand the Protocols tree for your named instance. Right click on TCP/IP and select Properties. Click on the IP Address tab and scroll all the way to the bottom of the list until you see ‘All IP’. Clear out the TCP Dynamic box and under TCP Port, provide the desired TCP port number. To switch back to dynamic port allocation, just clear out the TCP Port box and place a zero in the TCP Dynamic box. Any time you make a change to the Protocol settings, you will need to restart the SQL Server service for the named instance.
- TCP and UDP ports are registered with a national directory. You can reference them by using this Wikipedia article. I chose to use TCp ports 1435 through 1438 for my instances. Well known ports are from 0 – 1023, Registered ports are from 1024 – 49151, and Dynamic ports are from 49152 – 65535.
- To see a list of ports the server is using, run ‘netstat -an’ from the command prompt. Use this data along with available ports from Wikipedia to determine what ports are available on your system.
I hope you find this useful when you try to install SQL Server with multiple instances when the Windows Firewall service is enabled.