We got a query from DBA team as TempDB monitoring Job is running and its random called by CV,
This Job is calling 2 procs in CV and they are the one using OLE Automation, So, disabling won’t help either since it’s externally called. What to do with this job if we keep OLE Automation disabled. do we need to disable OLE automation on commserver and any idea why this job is running on commserve ?
Page 1 / 1
Team,
Attached is the job which DBA were questioning. hope this may help to get some answer.
@Allan0105 What good timing - I just popped in here looking into the same thing. In our environment the objects were create on 3/16/23 - I’m guessing we picked up some kind of an update to our Commvault environment.
@Allan0105 What good timing - I just popped in here looking into the same thing. In our environment the objects were create on 3/16/23 - I’m guessing we picked up some kind of an update to our Commvault environment.
Nice! Hopping someone could give us some insight soon from our community.
@Allan0105 I just spoke to our Commvault Admin and he said that he’d upgraded our Commvault s/w on the same day that these issues cropped up. Looking at it from a SQL Server perspective, it feels to me like the stored procedureCommvault..CaptureTempDBDetails is the one at fault. It looks like they’re using an Automation call to write to a log file in the file system - something that I’m not particularly keen on.
Looking at this, we’re going to disable the job. We have other tools that we use to monitor the size of our databases and, if TempDB grew to be unwieldy, we’d arrange to bounce the server so that it would revert to its original size.
Looking at this, we’re going to disable the job. We have other tools that we use to monitor the size of our databases and, if TempDB grew to be unwieldy, we’d arrange to bounce the server so that it would revert to its original size.
yeah, but just wondering why these jobs are running and who is calling it and finally why commvault is having these jobs automated and running. just looking for some answers before taking action so i am waiting for someone to help us.
Oh, I agree with you. It looks like the job is getting invoked via the SQL Agent job “Monitor_TempDB”. I do consider it a “bad” on CV’s part to have made it a requirement to be able to execute sp_OACreate, which does create something of a security loophole, without making this jump out in the upgrade instructions - which is why we’re just going to disable it. I’ve seen instances where enabling the OLE extensions of SQL Server has been worth it - this doesn’t achieve that threshold, IMO.
If the log files are necessary, they should’ve just absorbed this functionality into one of their executables. That would’ve been trivial to do.
More information to share:-
This job is triggered by any of 4 associated alerts:
When triggered it collects troubleshooting information to Base\Temp on the CS, or to the TroubleshootingDB if a trace is active.
It's safe to disable the job, the alerts, or both if you prefer and it's new in 11.28. If disabled, the extra information won't be captured in the case of tempdb overgrowth.
Presently if you disable these, installing a Feature Release is likely to reenable them. We need to create a CMR to address that.