SQL Server – Get CPU Usage History for last 256 minutes

The other day, I was asked by our Application Team Lead to check why the CPU usage is very high in the Production DB server. It remained consistently high throughout the day. He asked whether it is coming from SQL Server or other processes.

 

 

Below is a useful script to review the CPU usage history for last 256 minutes (This will work on SQL Server 2008 and up)​​ 

 

 

DECLARE​​ @ts_now​​ bigint​​ =​​ (SELECT​​ cpu_ticks/(cpu_ticks/ms_ticks)​​ FROM​​ sys.dm_os_sys_info​​ WITH​​ (NOLOCK));​​ 

 

SELECT​​ TOP(256)​​ SQLProcessUtilization​​ AS​​ [SQL Server Process CPU Utilization],​​ 

 ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​​​ SystemIdle​​ AS​​ [System Idle Process],​​ 

 ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​​​ 100​​ -​​ SystemIdle​​ -​​ SQLProcessUtilization​​ AS​​ [Other Process CPU Utilization],​​ 

 ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​ ​​​​ DATEADD(ms,​​ -1​​ *​​ (@ts_now​​ -​​ [timestamp]),​​ GETDATE())​​ AS​​ [Event Time]​​ 

FROM​​ (​​ 

  ​​​​ SELECT​​ record.value('(./Record/@id)[1]',​​ 'int')​​ AS​​ record_id,​​ 

 record.value('(./Record/SchedulerMonitorEvent/SystemHealth/SystemIdle)[1]',​​ 'int')​​ 

AS​​ [SystemIdle],​​ 

 record.value('(./Record/SchedulerMonitorEvent/SystemHealth/ProcessUtilization)[1]',​​ 

'int')​​ 

AS​​ [SQLProcessUtilization],​​ [timestamp]​​ 

  ​​​​ FROM​​ (​​ 

SELECT​​ [timestamp],​​ CONVERT(xml,​​ record)​​ AS​​ [record]​​ 

FROM​​ sys.dm_os_ring_buffers​​ WITH​​ (NOLOCK)

WHERE​​ ring_buffer_type​​ =​​ N'RING_BUFFER_SCHEDULER_MONITOR'​​ 

AND​​ record​​ LIKE​​ N'%<SystemHealth>%')​​ AS​​ x​​ 

  ​​​​ )​​ AS​​ y​​ 

ORDER​​ BY​​ record_id​​ DESC​​ OPTION​​ (RECOMPILE);

 

 

Now, if the value in “Other Process CPU Utilization (%)” column is higher​​ than​​ “SQL Server Process CPU”, then you may​​ ask​​ your sys admins to investigate the cause. But in our case, it​​ was indicated​​ clearly that the cause of high CPU usage was coming from SQL Server Process.​​ Below is the output of the​​ script.

 

 

 

After seeing the results, I investigated from the SQL queries perspective and found out that there are few​​ expensive queries that are​​ causing high CPU usage. ​​ How did I find out? That would be the subject of another blog.​​ 

Knowledge worth sharing...Share on linkedin
Linkedin
Share on facebook
Facebook
Share on google
Google
Share on twitter
Twitter

SQL Server – Error: 5042 – The file ‘MyFileName’ cannot be removed because it is not empty.

I was trying to delete a data file but I encountered the error below.

 

Error: 5042 - The file 'MyFileName' cannot be removed because it is not empty.

 

 

 

I executed the script below​​ to empty the file.

 

DBCC​​ SHRINKFILE(First_Data_File,EMPTYFILE​​ )

 

 

After the file has been emptied, I was able to remove the data file.

 

ALTER​​ DATABASE​​ DBNAME​​ REMOVE​​ FILE​​ First_File;

 

 

 

EMPTYFILE​​ Migrates all data from the specified file to other files in the same filegroup. In other words, EmptyFile will migrate the data from the specified file to other files in the same filegroup. Emptyfile assures you that no new data will be added to the file.The file can be removed by using the ALTER DATABASE statement.

Knowledge worth sharing...Share on linkedin
Linkedin
Share on facebook
Facebook
Share on google
Google
Share on twitter
Twitter

SQL Server – Agent Job Fails with Error: Unable to connect to SQL Server ‘(local)’. The step failed

I was​​ checking one of our client’s DB server for the first time.​​ I noticed a​​ couple of their SQL Agent Jobs have been failing due to the error “Unable to connect to SQL Server ‘(local)’”

 

 

 

The reason for this error is because the Database (drop down box) to run the step from is empty.

 

 

 

The solution is to choose the relevant database to run the job step against.

 

Knowledge worth sharing...Share on linkedin
Linkedin
Share on facebook
Facebook
Share on google
Google
Share on twitter
Twitter

SQL Server – Msg 1468, Level 16, State 1, Line 1

ERROR

 

Msg 1468, Level 16, State 1, Line 1

The operation cannot be performed on database "DBName" because it is involved in a database mirroring session or an availability group. Some operations are not allowed on a database that is participating in a database mirroring session or in an availability group.

Msg 5069, Level 16, State 1, Line 1

ALTER DATABASE statement failed.

 

 

Below are the steps I did to resolve the error.

 

  • Remove DBName from AAG

  • Enable Service Broker

ALTER​​ DATABASE​​ DBName​​ SET​​ ENABLE_BROKER;

 

  • Verify Service Broker Enabled

SELECT​​ is_broker_enabled​​ FROM​​ sys.databases​​ WHERE​​ name​​ =​​ 'DBName';

 

  • Add DBName to AAG

 

 

 

 

ue]

Knowledge worth sharing...Share on linkedin
Linkedin
Share on facebook
Facebook
Share on google
Google
Share on twitter
Twitter

SQL Server – The Transaction Log for Database is Full Due to Replication (Error 9002 Severity 17 State 6)

We have a 3 node AAG (below is our setup). Our transaction log file has a growth limit of​​ 60GB. I found out that this error occurred because the CDC failed. I could not start CDC and the transaction log is not truncating.

 

 

I checked the log_reuse_wait_desc and it indicated REPLICATION which means that there are committed transactions that haven’t yet been scanned by the transaction replication Log Reader Agent job for the purpose of sending them to the replication distributor or harvesting them for​​ Change Data Capture​​ (which uses the same Agent job as transaction replication). The job could have been disabled, could be broken, or could have had its SQL Agent schedule changed.

 

SELECT​​ name,​​ recovery_model_desc,​​ log_reuse_wait_desc

FROM​​ sys.databases

WHERE​​ name​​ =​​ 'DB_Name'

 

 

 

I also ran the command DBCC OPENTRAN and saw Replicated Transaction​​ Information.

 

 

 

To resolve the issue, I did the following steps.

  • Create a new transaction log file (it is a good thing that our currently t-log file has a growth limit else it could have occupied all the disk space.)

  • I started CDC and it ran​​ successfully.

 

But the t-log was still not truncating. I checked the log_reuse_wait_desc again and it indicated “AVAILABILITY REPLICA” which means that the database mirroring partnership has some latency in it and there are log records on the mirroring principal that haven’t yet been sent to the mirroring mirror (called the send queue). This can happen if​​ the mirror is configured for asynchronous operation, where transactions can commit on the principal before their log records have been sent to the mirror.​​ It can also happen in synchronous mode, if the mirror becomes disconnected or the mirroring session is suspended. The amount of log in the send queue can be equated to the expected amount of data (or work) loss in the event of a crash of the principal.

 

I​​ waited for few minutes and I checked the log_reuse_wait_desc and now I see “NOTHING” which means that SQL Server thinks there is no problem with log truncation.

 

Knowledge worth sharing...Share on linkedin
Linkedin
Share on facebook
Facebook
Share on google
Google
Share on twitter
Twitter