We had a situation whem the database was running fine since yesterday but itwas noticable slow today. So, first thing I suspected that a developer might have altered a stored procedure that ight have aused a delay ( bad query or a missing join ????)
In order to find out I took the following step.
--Find if the default race is enabled
SELECT * FROM sys.configurations WHERE configuration_id = 1568
--if it is not enabled we can enable it by running the following
sp_configure 'show advanced options' ,1;GO RECONFIGURE ;
GO
sp_configure 'default trace enabled', 1;
GO
RECONFIGURE;GO --find the location of the default trace in the server
select * from :: fn_trace_getinfo(default)Go --property 1 - value 2 means the trace is set for rollover when the file has reached the maximum size.
--property 2 shows the location of the default trce file in the server
--property 3 shows the maximum size in MB of the file
--property 4 shows if there is a stop time. NULL means the trace is not set to stop
--property 5 shows if the trace is enabled, value 1 means yes it is.
Now to find all the event since yesterday
select e.name , t.starttime , t.DatabaseName , objectname , LoginName , t.HostName , t.ApplicationName , t.spid , t.eventclass
from fn_trace_gettable( 'E:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Log\log_469.trc' , 5 ) as t
join sys.trace_events e
on e.trace_event_id = t.EventClass
where ObjectName is not null
and t.EventClass = 164 -- object altered
and starttime > '08/30/2012'
order by t.StartTime
This pointed me to the right direction as I started to analyze the store procedures that was rolled out.
This blog is created to add all the information and experiences that I have learnt while working on MS sql server as a DBA. The blog is also updated frequently with the real world problem that I encounter hands on at work and the resolutions to resolve them. I hope this blog will be of some use to you and you will revisit. Thank you for stopping by and you are welcome to leave comments.
Friday, August 31, 2012
Tuesday, August 28, 2012
Database Mail Executable Minimum Lifetime
We are facing some issue with Sql Server 2008 R2 Database Mail Queue functionality using "msdb.dbo.sp_send_dbmail" system stored procedure. After some time email functionality goes into suspended mode. SQL server executes a SP named "msdb.dbo.sp_readrequest;" which goes into suspended mode. This happen most of the time and we get dead locks alert
I adjusted the database mail executable minimum lifetime ( in seconds ) from 600 to 10 and this problem seems to have dissapear.
Databasemail object on SSMS --------> Configure databasemail ----------------->View or change system parameters--------->Database mail executable minimum lifetime change it to 10 seconds
.
I adjusted the database mail executable minimum lifetime ( in seconds ) from 600 to 10 and this problem seems to have dissapear.
Databasemail object on SSMS --------> Configure databasemail ----------------->View or change system parameters--------->Database mail executable minimum lifetime change it to 10 seconds
.
Monday, August 20, 2012
BC30554: masterpage is ambiguous
I did not get this error on my dev machine. I did not get this compilation error in the staging site. I got this error in the produciton site.
Resolution: There was another file called masterpage2.aspx that was using the same namespace masterpage. It looked like a test file or for some reason a blank masterpage file was renamed this. Removed the masterpage2.aspx file , did a build and it worked fine.
Resolution: There was another file called masterpage2.aspx that was using the same namespace masterpage. It looked like a test file or for some reason a blank masterpage file was renamed this. Removed the masterpage2.aspx file , did a build and it worked fine.
Friday, August 17, 2012
Error handling in transactions in sql 2008
BEGIN TRANSACTION TRAN1
BEGIN TRY
--put all the valid statements here--
CREATE TABLE #test(intREsult int);
INSERT INTO #test Values (4/0);
INSERT INTO #test Values (1/2);
COMMIT TRAN TRAN1
END TRY
BEGIN CATCH
--the error handling code including the rollback
DECLARE @errorMEssage nvarchar(1000);
SELECT @errorMEssage = ERROR_MESSAGE();
ROLLBACK TRAN TRAN1;
RAISERROR(@errorMEssage,16,1);
END CATCH
BEGIN TRY
--put all the valid statements here--
CREATE TABLE #test(intREsult int);
INSERT INTO #test Values (4/0);
INSERT INTO #test Values (1/2);
COMMIT TRAN TRAN1
END TRY
BEGIN CATCH
--the error handling code including the rollback
DECLARE @errorMEssage nvarchar(1000);
SELECT @errorMEssage = ERROR_MESSAGE();
ROLLBACK TRAN TRAN1;
RAISERROR(@errorMEssage,16,1);
END CATCH
Subscribe to:
Posts (Atom)