Showing posts with label logged. Show all posts
Showing posts with label logged. Show all posts

Monday, March 19, 2012

Errors not logged

Hi :

I have created the followign ddl trigger to log all the ddl activities. It is workign fine for all the sucessfully created objects.

The problem is, how do i log errors also. Like if i am trying to create a table with same name twice then the trigger should log a stmt saying that the table already exists in the database. or while creating synonyms twice with same name, etc

I want to log all the failed DDL stmts also.

Any solution will be of good help to me.

CREATE TRIGGER [DDLLogging] ON DATABASE
FOR DDL_DATABASE_LEVEL_EVENTS AS
BEGIN
SET NOCOUNT ON;

DECLARE @.data XML;
DECLARE @.schema sysname;
DECLARE @.object sysname;
DECLARE @.eventType sysname;

DECLARE @.logstmt varchar(500);

DECLARE @.query VARCHAR(255)
DECLARE @.file VARCHAR(255)

SET @.data = EVENTDATA();
SET @.eventType = @.data.value('(/EVENT_INSTANCE/EventType)[1]', 'sysname');
SET @.schema = @.data.value('(/EVENT_INSTANCE/SchemaName)[1]', 'sysname');
SET @.object = @.data.value('(/EVENT_INSTANCE/ObjectName)[1]', 'sysname')
SET @.file = 'c:\xzy\'+REPLACE(CONVERT(char(10),GETDATE(),111),'/','_')+'.log'

IF @.object IS NOT NULL
BEGIN
SET @.logstmt = CONVERT(varchar(20),GETDATE(),9) + ', ' + @.eventType + ' ' + @.object + ' successful';
SET @.query = RTRIM('echo ' + COALESCE(LTRIM(@.logstmt),'-') + ' >> ' + RTRIM(@.file))
EXEC master..xp_cmdshell @.query, NO_OUTPUT
END
ELSE
BEGIN
SET @.logstmt = CONVERT(varchar(20),GETDATE(),9) + ', ' + @.eventType + ' successful';
SET @.query = RTRIM('echo ' + COALESCE(LTRIM(@.logstmt),'-') + ' >> ' + RTRIM(@.file))
EXEC master..xp_cmdshell @.query, NO_OUTPUT
END

END;

i am using sql express.

|||DDL Triggers only fire for successfully completed DDL. If the DDL fails due to a error like a duplicate object, then the DDL trigger is never fired. If you want to audit error messages for failed DDL, you will have to use profiler or trace to observe the failures.|||

Hi:

Thank you for the reply.

I would like to know if there is any other mechnism to log unsucessfully executed DDL stmt.

All error while executing DDL stmts should be logged into log file.

By looking the log file, we should know which ddl stmts have executed and which have failed.

Please let me know of any solution.

i am using sqlcmd for executing .sql files. SQL Express is my database.

|||

Hi,

there is no builtin way to do this, you can temporary setup profiler to get the exception that come up while using false DDL statement, but using the profiler should only be a temporary solution as it it (in my opinion) very expensive.

HTH, Jens Suessmeyer.

http://www.sqlserver2005.de

|||

Tracing is more expensive when capturing unneeded columns, when filtering rows (since events are generated no matter what is filtered), and (most importantly) when the trace consumer (i.e., the trace table or the trace file) cannot consume those traced events in an expedient manner. Traces will drive up logical reads. Your experience will depend upon the trace system you design/choose (in geometric addition to load upon the client/server system).

For failed DDL, one should hope that (say) 1000 such events per second (or minute) is never seen , or, you may need to throttle the client (if the rate of DDL failures gets "excessive"). IMO, good development includes scalability testing from about day one (of any project), thus improper tracing should be detectable from about day one .

You can fire up SQL Server Profiler (the GUI) to create a server-side script (best to forbid the GUI in production and strive to avoid the GUI in development), remove the "profiler" filter (if present), and (for that scalability testing) profile the impact of profiler. Just make sure you don't ever overload the consumer's I/O (the consumer must consume quickly), otherwise life will suck.

Keep it short, sweet, and simple. And remember that you cannot squeeze an elephant through the eye of a needle.

Friday, March 9, 2012

errors but finished with success

My ssis package errors out because one of the database connection failed. I successfully logged error but also indicated that package finished successfully. My confusion is if a sheduling software schedules this package, what would be return code sent by dtexe... . would it be success or failure? In this scnerio i want it to return failure so that appropriate team can be contacted.

thanks,

kushpaw

Hi Kushpaw,

There is a property on the tasks in the control flow entitled FailPackageOnFailure. If you set this to true on the tasks that fail then the entire package will fail. The returned value should reflect this.

Hope this helps,

Grant

Sunday, February 19, 2012

Error: The replication agent has not logged a progress message in 10 minutes

Hello,

We are consistently getting the error message below on our subscribers that have blob images. Is there a way to increase a setting to avoid SQL to throw this error, or another suggestion? Thanks in advance.

John

Error messages:

The replication agent has not logged a progress message in 10 minutes. This might indicate an unresponsive agent or high system activity. Verify that records are being replicated to the destination and that connections to the Subscriber, Publisher, and Distributor are still active.

18 -BcpBatchSize 100000
18 -ChangesPerHistory 100
18 -DestThreads 2
18 -DownloadGenerationsPerBatch 5
18 -DownloadReadChangesPerBatch 100
18 -DownloadWriteChangesPerBatch 100
18 -FastRowCount 1
18 -HistoryVerboseLevel 3
18 -KeepAliveMessageInterval 300
18 -LoginTimeout 15
18 -MaxBcpThreads 2
18 -MaxDownloadChanges 0
18 -MaxUploadChanges 0
18 -MetadataRetentionCleanup 1
18 -NumDeadlockRetries 5
18 -PollingInterval 60
18 -QueryTimeout 400
18 -SrcThreads 2
18 -StartQueueTimeout 0
18 -UploadGenerationsPerBatch 3
18 -UploadReadChangesPerBatch 100
18 -UploadWriteChangesPerBatch 100
18 -Validate 0
18 -ValidateInterval 60

Due to the memory leak issue with respect to replicating blobbed images we have changed UploadGenerationsPerBatch to = 3.

Unfortunately, you are seeing something that I've had severe problems with at several customers. Support refuses to acknowledge this as a problem and also refuses to offer any kind of valid solution. My particular case was in having tens or hundreds of thousands of level 18 errors thrown into the logs for a normal operational state. The only solution from support was to completely disable error logging for absolutely everything on the instance. Yours is a slightly smaller issue, but still a major one. Unfortunately, there is no setting at all to allow someone to suppress error messages. My only solution was to run the SQL Server in an unsupported state by directly editing system stored procedures and commenting out the offending code within the replication procs. I've filed several bugs on the tremendous amount of logging that the replication agents do, but every one has either fallen off the face of the earth or been closed as "by design". (One of the customers that I shut the logging of 14151 errors off on saw their processor utilization on a 32 way machine drop from an average of about 75% to less than 25%. So, I'm not really sure how a design feature of SQL Server could be to chew up about 50% of the processor cycles just to log error messages.)

My first suggestion is to open a support case. Maybe after a couple hundred people open support cases on the fact that logging in 2005 is substantial and a DBA has zero control over suppressing things that they consider a normal operational state, we might start getting somewhere.

|||

Have you tried setting these 2 parameters:

-OutputVerboseLevel 0

-HistoryVerboseLevel 0

?

|||

Mahesh,

I have used the above mentioned setting for transactional replication. Replication runs fine for 2 days or so and after that without any error message I get 'subscriber re-initialization' required message. I have replication running every minute for 12 publication and you would imagine the amount of logging from distribution agent. Unfortunately, running replication continously is not an option because we are currently experiencing network-related issue that drop the connection every 10 minutes or so.

I would appreciate if you could offer me some thoughts on that.

|||please refer to:

http://msdn2.microsoft.com/en-us/library/ms146868.aspx

especially the section:

-- Change the heartbeat interval at the Distributor to 5 minutes.
USE master
exec sp_changedistributor_property
@.property = N'heartbeat_interval',
@.value = 5;
GO

Setting this to a higher value will have the agents only log at this higher value.

This setting was introduced in SQL 7 IIRC.

Error: The replication agent has not logged a progress message in 10 minutes

Hello,

We are consistently getting the error message below on our subscribers that have blob images. Is there a way to increase a setting to avoid SQL to throw this error, or another suggestion? Thanks in advance.

John

Error messages:

The replication agent has not logged a progress message in 10 minutes. This might indicate an unresponsive agent or high system activity. Verify that records are being replicated to the destination and that connections to the Subscriber, Publisher, and Distributor are still active.

18 -BcpBatchSize 100000
18 -ChangesPerHistory 100
18 -DestThreads 2
18 -DownloadGenerationsPerBatch 5
18 -DownloadReadChangesPerBatch 100
18 -DownloadWriteChangesPerBatch 100
18 -FastRowCount 1
18 -HistoryVerboseLevel 3
18 -KeepAliveMessageInterval 300
18 -LoginTimeout 15
18 -MaxBcpThreads 2
18 -MaxDownloadChanges 0
18 -MaxUploadChanges 0
18 -MetadataRetentionCleanup 1
18 -NumDeadlockRetries 5
18 -PollingInterval 60
18 -QueryTimeout 400
18 -SrcThreads 2
18 -StartQueueTimeout 0
18 -UploadGenerationsPerBatch 3
18 -UploadReadChangesPerBatch 100
18 -UploadWriteChangesPerBatch 100
18 -Validate 0
18 -ValidateInterval 60

Due to the memory leak issue with respect to replicating blobbed images we have changed UploadGenerationsPerBatch to = 3.

Unfortunately, you are seeing something that I've had severe problems with at several customers. Support refuses to acknowledge this as a problem and also refuses to offer any kind of valid solution. My particular case was in having tens or hundreds of thousands of level 18 errors thrown into the logs for a normal operational state. The only solution from support was to completely disable error logging for absolutely everything on the instance. Yours is a slightly smaller issue, but still a major one. Unfortunately, there is no setting at all to allow someone to suppress error messages. My only solution was to run the SQL Server in an unsupported state by directly editing system stored procedures and commenting out the offending code within the replication procs. I've filed several bugs on the tremendous amount of logging that the replication agents do, but every one has either fallen off the face of the earth or been closed as "by design". (One of the customers that I shut the logging of 14151 errors off on saw their processor utilization on a 32 way machine drop from an average of about 75% to less than 25%. So, I'm not really sure how a design feature of SQL Server could be to chew up about 50% of the processor cycles just to log error messages.)

My first suggestion is to open a support case. Maybe after a couple hundred people open support cases on the fact that logging in 2005 is substantial and a DBA has zero control over suppressing things that they consider a normal operational state, we might start getting somewhere.

|||

Have you tried setting these 2 parameters:

-OutputVerboseLevel 0

-HistoryVerboseLevel 0

?

|||

Mahesh,

I have used the above mentioned setting for transactional replication. Replication runs fine for 2 days or so and after that without any error message I get 'subscriber re-initialization' required message. I have replication running every minute for 12 publication and you would imagine the amount of logging from distribution agent. Unfortunately, running replication continously is not an option because we are currently experiencing network-related issue that drop the connection every 10 minutes or so.

I would appreciate if you could offer me some thoughts on that.

|||please refer to:

http://msdn2.microsoft.com/en-us/library/ms146868.aspx

especially the section:

-- Change the heartbeat interval at the Distributor to 5 minutes.
USE master
exec sp_changedistributor_property
@.property = N'heartbeat_interval',
@.value = 5;
GO

Setting this to a higher value will have the agents only log at this higher value.

This setting was introduced in SQL 7 IIRC.