2

We have a SQL Server 2014 set up on Always on AG with one primary node and 2 secondary nodes. On the primary node, DBCC CHECKDB for one of the databases is scheduled on SQL agent job. This job was running fine till last month and now its getting failed and the job logs read "DBCC CHECKDB terminated abnormally due to error state 6." when running the DBCC CHECKDB command manually, getting the same result.

During the job/Command runtime , there is a spike in I/O , Memory and CPU utilization is full. Storage team had also checked and reported that there are no storage related errors

On the Secondary nodes, the job runs fine without any issues.

I did try to restore the DB on a test instance and the DBCC CHECKDB runs fine.

Could anyone help me to find the cause of this.

Improve this question
4
  • Do you see the elapsed time along with the error reported? Is it same every time it fails? What is the elapsed time when it was successful? And, you have mentioned that the resource utilization is high during the job execution, can you limit the MAXDOP for checkDB and see if that works?
    – S.D.
    Commented May 26, 2022 at 3:08
  • And, tempdb plays a key role especially when the size of the DB is greater than instance max memory, what is you DB size, instance max memory and tempdb allocation? This is one good article that probably helps to handle consistency checks on VLDBs.
    – S.D.
    Commented May 26, 2022 at 3:16
  • @SivaDasari, Thanks for your Suggestion . Yes the DB is around 1.3 TB. Usually the run time is 5 hours . but it just getting terminated in 3 hours lately. I will try to adjust the MaxDOP and check the Database.
    – GopiMth
    Commented May 26, 2022 at 14:28
  • Also the secondary nodes have the same DB capacity and just runs fine without issues
    – GopiMth
    Commented May 26, 2022 at 14:30

1 Answer 1

Reset to default
1

DBCC CHECKDB terminated abnormally due to error state 6

The error state 6 means process is killed or terminated by external process at least as far as my experience goes, this is not documented though. I have witnessed this and in my case this was due to a monitoring query running killing long running job. Please double, triple check is any user process/agent job/third part software (in some case) is killing the process.

Improve this answer
3
  • Yes I did check that but there were no processes interrupting the job. @shanky
    – GopiMth
    Commented May 26, 2022 at 14:33
  • @GopiMth the reasons for some of my questions is the same, as you are running it on a Primary instance the resources needs to be shared with your other active workload. May be something with higher precedence is killing for it, try limiting the MAXDOP on just the DBCC CHECDB command and see. The only caveat with that is the runtime would increase.
    – S.D.
    Commented May 26, 2022 at 20:36
  • @SivaDasari Higher precedence killing is highly unlikely. SQL Server kills process AFAIK only when deadlock happens. Gopi can u check about deadlock
    – Shanky
    Commented May 27, 2022 at 7:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.