I have SQL event logged filled by these kind of messages and bloats the event log file. Is there a way to disable logging of receiving Queue messages?
The activated proc '[dbo].[QueueReceiveTriggerProcedure]' running on queue 'xxx.dbo.xxxQueue' output the following: '3301'
Check the code of dbo.QueueReceiveTriggerProcedure, the output is being logged because the procedure has a select or print or raiserror statement.
Cross-site duplicate courtesy Martin Smith.
Related
I am newbie to SSIS. I am facing an issue executing sp_send_dbmail in one of my stored procedures which is being run by Execute SQL task in SSIS. Main problem is, it is not throwing any error and completing successfully even though profile with which I am running this SP doesn't exist. I suspect there is a configuration issue but I am not able to diagnose it.
I have found that SMTP is not configured on my staging server. Can it be the only reason? Even if it is, it should at least throw an error, but in logs I do not see any error messages for the same.
Also, if I am running this SP directly through SQL, I get "Profile doesn't exists" error. But when I am running same SP through SSIS (execute sql task), then it is executing successfully.
Any guidance on this issue can be a great help.
This is how I am calling sp_send_dbmail.
EXEC msdb.dbo.sp_send_dbmail
#profile_name = 'Stagging Trigger',
#recipients = 'myemailID#test.com',
#subject = 'this is the SP to send mail from SP'
sp_send_dbmail only queues up the mail. Does not attempt to deliver, does not validate the email profile, cannot raise any of the errors you complain are missing.
Read here how to check the status of emails queued: Check the Status of E-Mail Messages Sent With Database Mail:
USE msdb ;
GO
-- Show the subject, the time that the mail item row was last
-- modified, and the log information.
-- Join sysmail_faileditems to sysmail_event_log
-- on the mailitem_id column.
-- In the WHERE clause list items where danw was in the recipients,
-- copy_recipients, or blind_copy_recipients.
-- These are the items that would have been sent
-- to danw.
SELECT items.subject,
items.last_mod_date
,l.description FROM dbo.sysmail_faileditems as items
INNER JOIN dbo.sysmail_event_log AS l
ON items.mailitem_id = l.mailitem_id
WHERE items.recipients LIKE '%danw%'
OR items.copy_recipients LIKE '%danw%'
OR items.blind_copy_recipients LIKE '%danw%'
GO
More articles on the topic:
Troubleshooting Database Mail Failures
Complete Troubleshooting Guide for SQL Server Database Mail
Your error is pretty clear in what is required. First off, create a profile and note down all the values that you will input on the wizard. This guide will help you create the profile correctly.
Once you have verified that the dbmail profile has been setup, its time to put it to test. If you cant send out email through the stored proc, I would want to talk to the AD admin or the person responsible for setting up the email server. This is to make sure that you can anonymously send emails and to take care of any potential relay server issues. Hope this helps.
I have implemented SQL Server Service Broker with error handling according to this article by Remus Resanu.
When I ran the process and the activation script got kicked off but never stopped processing. According to the SQL Server log file it looks like I have a typo in my error handling and it is now stuck in an infinite loop.
I have tried to kill the process using kill <pid> but I get the message Only user processes can be killed. I have also tried restarting the server but the activation script would start again.
How do I kill the runaway activation process?
I was not able to find a solution through google/bing search. I eventually remembered that we enabled the Service broker through a SQL command, so I tried disabling it and that seems to have worked:
ALTER DATABASE dbname SET DISABLE_BROKER;
It looks like undocumented feature. If activated procedure do not issue END CONVERSATION it keeps restarting in an infinite loop. So, to stop it you need to make it successfully run END CONVERSATION of any dialog. If the queue gets disabled due to poison message detection you need to drop it to stop activation proc - no need to reset broker. I did not found either solution to this problem out there so I played with it a bit and hope this gives you a hint.
I am trying to configure auditing on my SQL Server using Service Broker. I did all the configuration needed to capture the DDL Events (queue, routes, endpoints, event notification). It is working properly except that I am not able to get the hostname of the client from where the DDL event originated from.
Using the service broker's activation procedure, I tried reading the value from the message_body, but there's no xml element that contains the hostname. I can see a value for the SPID but am unable to make use of it. Exec'ing sp_who and querying sys.processes against this SPID doesn't return any value. And running sp_who without parameter shows only one process (I think it's the background process used by the service broker). Is it all because the message was sent asynchronously? But why will it cause the activation context to see different data on sys.processes view?
I am aware that there are DDL triggers that can achieve the same goal, but it seems it is tightly coupled to the command that causes it to fire. So if the triggers fails, the command will also fail.
UPDATE: I managed to retrieve the Hostname by using a combination of xp_cmdshell and sqlcmd (command line app). But I also realized that since the message is asynchronous, it is not always reliable (The SPID who issue the DDL command might have been disconnected already before the message is read from the queue).
I'm not exactly sure what you're trying to implement here, but it's expected that activated procedure will only see a subset of rows in DMVs. This has to do with activation context which often impersonates a different user that you use when debugging the procedure. That impersonated user will only see these rows of server-level views and DMVs to which it has permissions. See here and here for more info.
Can I ask what is the difference between xp_sendmail and sp_send_dbmail proc? They are both send e-mail message, which may include a query result set attachment, to the specified recipients.....
What is the difference?
xp_sendmail requires a MAPI client installed, such as Outlook, on the server. This is the only option for SQL Server 2000 and before.
sp_send_dbmail is a simple SMTP solution, added for SQL Server 2005+
sp_send_dbmail is by far better.
Another difference between the two is that email message sent using sp_send_dbmail() will be rolled back (not sent) if the transaction is rolled back. This does not happen with email sent using xp_sendmail().
So, if you want the email message to be sent regardless of the end result of the transaction you'll need to use xp_sendmail().
I was sending emails to notify users if an SP was unable to complete it's processing. Of course, I was rolling back the transaction in that event. When I switched to sp_send_dbmail() the transactions that were being rolled back (the very ones I wanted to get an email notification from) stopped sending emails.
we don't control the calling code - it's closed and calls the sp in a transaction. We need a feature in SQL Server to send direct or flush the mail queue.
I need to signal a running application (Windows service) when certain things happen in SQL Server (2005). Is there a possibility to send a message from a trigger to an external application on the same system?
You can use a SQL Service Broker queue to do what you want.
The trigger can create a conversation and send a message on the queue.
When it starts, the external process should connect to the database and issue a WAITFOR (RECEIVE) statement on this queue. It will receive the message when the trigger sends it.
Not sure DBA's would approve of this, but there is a way to run commands using xp_cmdshell
"Executes a given command string as an operating-system command shell and returns any output as rows of text. Grants nonadministrative users permissions to execute xp_cmdshell."
Example from MS's site:
CREATE PROC shutdown10
AS
EXEC xp_cmdshell 'net send /domain:SQL_USERS ''SQL Server shutting down
in 10 minutes. No more connections allowed.', no_output
EXEC xp_cmdshell 'net pause sqlserver'
WAITFOR DELAY '00:05:00'
EXEC xp_cmdshell 'net send /domain: SQL_USERS ''SQL Server shutting down
in 5 minutes.', no_output
WAITFOR DELAY '00:04:00'
EXEC xp_cmdshell 'net send /domain:SQL_USERS ''SQL Server shutting down
in 1 minute. Log off now.', no_output
WAITFOR DELAY '00:01:00'
EXEC xp_cmdshell 'net stop sqlserver', no_output
Either:
Use RAISERROR (severity 10) to fire a SQL agent alert and job.
Load a separate table that is polled periodically by a separate mail handling process. (as HLGEM suggested)
Use a stored procedure to send the message and write to the table.
Each solution decouples the transactional trigger from a potentially long messaging call.
You can send an email from a trigger, but it isn't a recommended practice becasue if the email ssystem is down, no data changes can be made to the table.
Personally if you can live with less than realtime, I would information about the event you are interested in to another table (so the real change of data can go smoothly even if email is down for some reason.) Then I would have a job that checks that table every 5-10 minutes for any new entries and emails those out.
You can use a dbmail email message. It should not slow the trigger down if the mail server is down because the message is queued and then sent by and external (to sql) process.
The table idea sounds good if the application can access sql server.
You could also give access to that same table via sql 2005 native XML Services - which exposes procs through xml.
http://msdn.microsoft.com/en-us/library/ms345123(SQL.90).aspx
Depending on what sort of message you want to send, you could use a CLR stored procedure to connect to a socket on the running process and write the message to that. If you have no control over the process (i.e. can't modify it) you could build a bridge or use a library that can issue a message in a suitable format.
For reliable delivery, you could do something that uses MSMQ to deliver the message.
A reminder that triggers can be problematic for stuff like this because they are embedded in set-operations. And being associated with tables, they aren't very sensitive to the context in which they are fired. The problem can be if they fire on an operation that involves multiple rows, because it's hard to avoid invoking as many instances of your action as there are records in the operation. Several hundred emails are not unlikely, for instance.
Hopefully "things that happen" can be detected in closer association with the context in which they happen (which also can be interesting to try to backtrack from a trigger.)