I have an interesting issue. I will try to keep it simple as explanation.
I have a SSIS package which has an Event Handler (OnError, including some extra logging info) with Send Mail Task which is working just fine when the package fails
Database Mail is configured and Job Failure notifications are enabled in SQL Server Agent.
The idea behind that is because I use proxy to run the SSIS package and when the proxy is not working I need to receive email with error (which is now working). When the job starts it cannot go to SSIS OnError handler and if I'm not checking the jobs I will never know If the job is working or not.
Now when I have proxy problem I receive only one mail which is fine but when something in the SSIS package fails I receive 2 mails: one from SQL Server Agent notification, and another one from the OnError event handler from SSIS, which is something I'm trying to avoid.
I need only 1 email when an error occurs. Is it possible to prioritize it somehow and when the SQL job notification is sending mail another one from SSIS to be ignored?
I'm thinking to create one sample SSIS package only with one SQL Task and include it before all the SSIS steps just to check If the job is able to start. I don't know. I don't like the idea.
Do you have any ideas? Thanks.
Best regards.
What do you mean by the Proxy isn't working?
If you can define and test that, add a job step that does proxy test, and emails with send_dbmail as step 1. Keep the SSIS package as step 2 with it's inbuilt error notification, and disable the job notifications.
We have a AG Group setup for 2 server A (Primary) ,B (Secondary)
A,B have identical setup for sql agent job
A job run successful and
B job's failed in initial step when trying to access the db (Due to The target database , is participating in an availability group and is currently not accessible for queries.)
Once A failover and B become Primary. We notice a behaviour that A & B sql agent Job also running successfully, so the job run twice.
We tried to modify script in sql agent Job, by adding printing ##servername variable, we found that A & B sql agent job are also printing B(now is primary) servername. Likely 2 job are also running in B(primary) server.
The only way to resolve is currently just to restart the sql agent service. Would like to know if any other solution?
SQL server version is 13.0.5888.11
Below Issue is similar to mine, but no solution yet
[https://stackoverflow.com/questions/47433964/sql-server-ag-agent-jobs-running-successfully-on-secondary-replica][1]
I am using SQL Server 2008 to create a job to calculate some values from an external db and store to another db table. A task scheduler has been created for automating this to run daily and update results to the 2nd table. The job is getting failed with SQL message ID 3621 and severity 14. I googled this message id and got to know that it is due to insufficient privileges for the user.
By default which user will be invoking the SQL job by the task scheduler?
If you open the Task properties, you can see what account it is running as:
My eventlog is cluttered with Package "<name>" finished successfully messages; is there any way to stop these from being added to the log?
The packages in question run very frequently and are making the eventlog harder to use
This is running from SQL Server 2008 R2 (Standard)
The job properties are set with Write to the Windows Application event log - When the job fails (and sends an email to an operator and in the corresponding maintenance plan, the settings for "Reporting and Logging" are all set with nothing checked.
And the SQL Server Agent properties are set only with the fail-safe operator; by email
For the life of me, I cannot see anywhere in SQL where I can suppress the "success" messages and would appreciate help.
I have just encountered a very similar scenario.
I have a couple of packages that are scheduled frequently. Monitoring of these non-critical packages can be managed within SQL Server Management Studio itself, I have no need to log events to the Windows Application logs.
In fact the logs are now "bloating" insofar as they are filling at a far greater pace than I am happy with.
It is possible to switch package logging on or off within the SSIS package itself.
From within BIDS (Business Intelligence Design Studio), right click anywhere within the control flow and select "Logging..." from the menu that appears.
From what I have read of this, to set your own custom logging options you have to tick the option on in the "Providers and Logs" screen and then add the "SSIS log provider for Windows Event Log" provider.
Once you have done that, you can tick options on and off within the "Details" tab. The options are all unchecked by default.
In the alternative, you could set up logging to the "SSIS log provider for SQL Server" and select the items that you do want to monitor. This then logs activity to a table called dbo.sysssislog in whichever database you configure within the provider.
You can get details on SSIS package logging here: http://msdn.microsoft.com/en-gb/library/ms181205(v=sql.100).aspx
I have a problem setting up email notifications in SQL Server 2008.
I am using SQL Server 2008 to build a data cube. This process consists of several jobs, that are all scheduled to run each night at a specific time. To see whether a job was running without any failure, it is possible to set up email notification.
(source: smilinginthesun.de)
(source: smilinginthesun.de)
Unfortunately, no email is sent even though I think I have set up database mail correctly.
All guides I can found just explains, how to set up database mail (eg. http://blog.sqlauthority.com/2008/08/23/sql-server-2008-configure-database-mail-send-email-from-sql-database/), but thats it.
If I sent a mail to test functionality (via test email button or from T-SQL script) it works just fine and the email arrives. But when using the notification feature in a job, it doesn't even create a sysmail_mailitems or sysmail_log entry.
I have also send an email using sp_notify_operator, successfully. So the operator set up seems to work, too. (Thanks, Joe Stefanelli, for the hint.)
There is a great workaround written for SQL Server 2005, that works for me, too: http://www.howtogeek.com/howto/database/sending-automated-job-email-notifications-in-sql-server-with-smtp/, but why isn't it possible to just use that build-in functionality?
Does anyone knows if there is anything else to do, to make that email notification task work properly? Thanks in advise.
I am late but I saw your post having the same problem.
The solution is to enable a mail profile for alerts.
For this:
Right click on "SQL Server Agent"
Then "Properties".
Then go to "Alert System" section.
Tick the "Enable mail profile" box.
Then "OK".
Restart the SQL Server Agent service.
To send email notifications from agent jobs in SQL Server Agent, the alarm system must be activated. We did that. After restarting the agent, the Database Mail system should be used. Unfortunately, this does not work. The agent was still trying to reach a Mapi profile (as in SQL 2000).
The following registry value wasn't set: "UseDatabaseMail"=dword:00000001
After setting it to 1, the database mail system was used.
You can do that in SQL server, directly:
EXEC master.dbo.xp_instance_regwrite N'HKEY_LOCAL_MACHINE', N'SOFTWARE\Microsoft\MSSQLServer\SQLServerAgent', N'UseDatabaseMail', N'REG_DWORD', 1
I've tried what ZeuG. indicated and still didn't have success... then I restarted the SQL Agent. That's what made the job email notification work for me.
For me, SQL email worked fine when I right-clicked Database Mail and said Send Test Email. However, after setting up alerts for all severities and running RAISERROR (N'Test alert!', 20, 1) WITH LOG;, no email came through. The issue is the service account that SQL Server Agent runs under. Apparently, the virtual account NT Service\SQLSERVERAGENT (or whatever your default may be) does not have permissions to access objects on the network and this includes e-mail.
To fix, change the service to use a local account under the Users group, restart SQL Server agent, and then try running a command that throws an error like the RAISERROR statement above. You should now receive the email.