Just a couple more questions hopefully someone can help with.
I've set up a schedule in UAT to run weekdays from 8am to 12.
I've also set the NumConcurrentOps to 3 and added in a rotation of 7 days. Yesterday this worked as expected, but today when it's kicked off it's only ruining one thread at a time. Is this because all of the DB's were checked yesterday so it's only running single threaded now or am I missing something?
Another question I have that I can't find in the documentation (but I'm probably missing it) regards DBs in an AG group. I've installed the checkdb module on another test server and set it up, however this one is the primary node of an AG.
I setup everything to run on rotation, however when the agent job kicks off the only user databases it runs the CheckDB on are the ones that aren't part of any AGs Is there extra configuration needed to run checks on all databases regardless of if they're part of an AG or not?
Best Answer
S
Sean McCown
said
over 6 years ago
With NumConcurrentOps, it should always try to spin up the threads. In fact, even if there's only 1 DB to process I think it'll spin up the other threads anyway, and they'll just not have anything to do.
As for the AG issue, we're not limiting based on AG membership. In fact, you should be able to also run it on 2ndary AG nodes as well.
However, we've had some bugs that I hope have been fixed. So email me and I'll get you the updated version. It's pre-release but it's working in a couple places pretty well.
Come back and let me know how it works and we'll take it from there.
With NumConcurrentOps, it should always try to spin up the threads. In fact, even if there's only 1 DB to process I think it'll spin up the other threads anyway, and they'll just not have anything to do.
As for the AG issue, we're not limiting based on AG membership. In fact, you should be able to also run it on 2ndary AG nodes as well.
However, we've had some bugs that I hope have been fixed. So email me and I'll get you the updated version. It's pre-release but it's working in a couple places pretty well.
Come back and let me know how it works and we'll take it from there.
sean at MidnightDBA dot com.
P
Pete
said
over 6 years ago
I should have mentioned it did spin up three agent jobs. It's just only thread 3 ever showed as active at any one time.
I'll send you my email in regards to the AG issue. Thanks.
Sean McCown
said
over 6 years ago
Ahhh, well that's a relief. I couldn't figure out why it wasn't spinning them up. So does it cycle through them with one being active and then the other, and then the other? Or are the other 2 deadlocked and it's only running the one job?
P
Pete
said
over 6 years ago
I've just changed the schedule and re-run it there now.the jobs for thread 1 and two are failing with the following
Invalid object name '#ThreadQTemp'
Thread 3 seems to be running without issue.
Sean McCown
said
over 6 years ago
Ok, I'll get you that update.
P
Pete
said
over 6 years ago
Thanks Sean. The update seemed to fix the issues. One of the servers (the one that had failing threads) needed to have all of the minions tables and stored procs removed before I could get it to run properly (for some reason the job was just completing without doing anything after the update). But up to now everything is running OK. I'll post again if anything changes.
Pete
Just a couple more questions hopefully someone can help with.
I've set up a schedule in UAT to run weekdays from 8am to 12.
I've also set the NumConcurrentOps to 3 and added in a rotation of 7 days. Yesterday this worked as expected, but today when it's kicked off it's only ruining one thread at a time. Is this because all of the DB's were checked yesterday so it's only running single threaded now or am I missing something?
Another question I have that I can't find in the documentation (but I'm probably missing it) regards DBs in an AG group. I've installed the checkdb module on another test server and set it up, however this one is the primary node of an AG.
I setup everything to run on rotation, however when the agent job kicks off the only user databases it runs the CheckDB on are the ones that aren't part of any AGs Is there extra configuration needed to run checks on all databases regardless of if they're part of an AG or not?
With NumConcurrentOps, it should always try to spin up the threads. In fact, even if there's only 1 DB to process I think it'll spin up the other threads anyway, and they'll just not have anything to do.
As for the AG issue, we're not limiting based on AG membership. In fact, you should be able to also run it on 2ndary AG nodes as well.
However, we've had some bugs that I hope have been fixed. So email me and I'll get you the updated version. It's pre-release but it's working in a couple places pretty well.
Come back and let me know how it works and we'll take it from there.
sean at MidnightDBA dot com.
- Oldest First
- Popular
- Newest First
Sorted by Oldest FirstSean McCown
With NumConcurrentOps, it should always try to spin up the threads. In fact, even if there's only 1 DB to process I think it'll spin up the other threads anyway, and they'll just not have anything to do.
As for the AG issue, we're not limiting based on AG membership. In fact, you should be able to also run it on 2ndary AG nodes as well.
However, we've had some bugs that I hope have been fixed. So email me and I'll get you the updated version. It's pre-release but it's working in a couple places pretty well.
Come back and let me know how it works and we'll take it from there.
sean at MidnightDBA dot com.
Pete
I should have mentioned it did spin up three agent jobs. It's just only thread 3 ever showed as active at any one time.
I'll send you my email in regards to the AG issue. Thanks.
Sean McCown
Ahhh, well that's a relief. I couldn't figure out why it wasn't spinning them up. So does it cycle through them with one being active and then the other, and then the other? Or are the other 2 deadlocked and it's only running the one job?
Pete
I've just changed the schedule and re-run it there now.the jobs for thread 1 and two are failing with the following
Invalid object name '#ThreadQTemp'
Thread 3 seems to be running without issue.
Sean McCown
Ok, I'll get you that update.
Pete
Thanks Sean. The update seemed to fix the issues. One of the servers (the one that had failing threads) needed to have all of the minions tables and stored procs removed before I could get it to run properly (for some reason the job was just completing without doing anything after the update). But up to now everything is running OK. I'll post again if anything changes.
1 person likes this
Sean McCown
Excellent. We're always here if you need us.