Let’s stop and think about the title of the article. Perhaps I should have chosen “Does your SQL server send alerts” but I wanted to make a big point here: IF YOU ARE RUNNING MICROSOFT SQL SERVER YOU ARE HOSTING A BACK END TO YOUR APPLICATION AND IF YOU ARE RUNNING SYTELINE YOU ARE RUNNING A MISSION CRITICAL APPLICATION. Who in the world would want their application to have a back end that is silent and doesn’t tell you when there are issues???
When you run an enterprise ERP application that potentially supports hundreds or thousands of concurrent users both internal to the company and external to customers and vendors the last thing you want to deal with is recovering from a failure after the fact when your users are in a panic that they cannot enter an order into the system or perform another tasks that keeps the company in business. When a consultant is done setting everything up and puts the keys to the kingdom in the hands of the on-site IT delegate, they need to be equipped with as much knowledge as possible to keep everything running smoothly and that involves not only a maintenance plan to keep everything tidy but also an alert system set up so that SQL can tell you when there is a problem rather than simply putting the error in the SQL Server log file repository. The basic ingredients to activating the alert system is as follows:
Open SSMS and connect to the database engine. Expand object explorer until you find Management /Database Mail and right click to set up
SQL will alert you that you are about to set up a new profile. The wizard will guide you through the entire process and you will of course need to know the IP or Hostname of the mail server including the authentication method needed.
Lastly, it will ask whether you want it to be your default profile and whether or not it is public or private. I would make it your default profile and choose public as my profile type.
Lastly, I would increase the retry attempts to 5 and change the maximum size to 10MB
After setting up database mail, go ahead and right click on database mail once more and test it. Make sure to send one to both an internal address and an external one to ensure that mail is authorized to travel outside of the network
At this point, you have hopefully received test emails that arrived on your smartphone and your desktop/laptop/tablet. Now its time to activate the alert system. To do this, you scroll to the bottom of SSMS, and right click on the agent and go to properties
Activate the alert system by checking the box and ensuring database mail is the preferred choice
Now it’s time to define who gets the alerts. In Microsoft SQL, a recipient is known as an “operator”. The operator can be a user or a distribution group depending on whether or not you want the alert to go to multiple people. You can also define more than one operator and separate out the alerts however most of the Infor Syteline customers tend to have only a small group of people that would be dedicated to keeping the server up so it’s not unreasonable for only one operator to be defined in a SMB.
In the below example, instead of adding an individual, I chose to make it a group. Name can be anything you want it to be and email address will either be a person’s email address or the email address of a distribution list
All options regarding pager settings and on duty settings are optional. I don’t know many people that still have pagers but I imagine there are a few out there where this is applicable. Repeat adding operators if needed and save when done
The last step is to define the alerts that are applicable. There are some alerts that everyone should have set up no matter what while there are other alerts that are more custom to how you run your business or specific issues that you are plagued with such as deadlocks or user limits exceeded. For now, keeping this in scope of critical alerts is a good starting place.
I have created a generic script that you can download here
Before running this script in SSMS you must do a mass replace with the word OPERATORNAME to whatever you named your operator or the script will partially fail. If you forget or fail to read this message before execution, all this means is that you will need to go back to each alert and manually specify the operator or run just the part of code that is needed for setting up the operator.
This is just the beginning of what alerts there should be on your system. With a little creativity, you can find creative ways for SQL to be your eyes for your Syteline system when you are not around.