LcsCDR & QoEMetrics Purge and Usage Summary SQL Agent Jobs

Question

Hello.
On our SQL instance that hosts the LcsCDR & QoEMetrics databases I have the following SQL Server Agent Jobs:
LcsCDR_Purge
LcsCDR_UsageSummary
QoEMetrics_Purge
QoEMetrics_UsageSummary
I'd like to know if anyone else has these same jobs on their instances as it's unclear looking at the job descriptions, when they were created, and the code they run if these are part of the core Lync system or something that has been set up randomly
afterwards.
One thing I do know is that these jobs don't work correctly when you use database mirroring. I will elaborate on this if/when I can find out any more information about them first.
Thanks

Answer 1

Thank you for the reply.
The problem with these jobs is that when they attempt to run against a database which is a mirror, it causes the job to fail. That would not seem to be a big deal right, except our policy (and many other SQL shops I imagine) is to send e-mail notifications
each and every time a SQL agent job fails on any server, not just those associated with Lync.
As it stands these jobs are not configured on either the principal or mirror server to notify anyone as I’d get an e-mail every hour on the hour from the mirror server telling me that a job has failed  (even though it didn’t actually need to do anything
) giving the impression something is wrong somewhere. This is quite a common trap to fall into with SQL Agent jobs and database mirroring.
Remember that because as Lync uses automatic failover either server could be the mirror at any given time so there is no mileage in setting the e-mail notifications on just the server that is currently the principal.
What this job should do then is when it attempts to run on the mirror, check if it’s the mirror first and if it is then do nothing instead of failing each time.  This will enable e-mail notifications to be set up on the jobs on both servers, so when
the job fails we know there is potentially a genuine problem to be investigated.
Each job contains two steps, I’ll use the QoEMetrics_UsageSummary as the example.
The code in step 1 is this, which causes the job to error out if it is attempting to run against the mirror.
declare @_MirroringRole int
set @_MirroringRole = (
select mirroring_role
from sys.database_mirroring
where database_id = DB_ID('QoEMetrics')
if (@_MirroringRole is not NULL and @_MirroringRole = 2) begin
raiserror('Database is mirrored', 16, 1)
end
else begin
print ('Database is not mirrored')
end
I re-wrote this job to run in one-step like this, which runs from the master database, which as I mentioned above doesn’t make the job error out when it realises it’s trying to run against a mirror.
DECLARE @_MirroringRole INT
SET @_MirroringRole = ( SELECT mirroring_role
FROM sys.database_mirroring
WHERE database_id = DB_ID('QoEMetrics'))
-- if this is not a mirrored database or it's the principal, attempt to run usage summary op
IF (@_MirroringRole IS NULL OR @_MirroringRole = 1)
BEGIN
DECLARE @_Sql NVARCHAR(4000)
SET @_Sql =
'USE [QoEMetrics];
DECLARE @_UpdatingSkipped INT
EXEC dbo.RtcRegularMaintainDatabase @_UpdatingSkipped = @_UpdatingSkipped output'
EXEC (@_Sql)
END
ELSE -- if the database is a mirror, don't do anything
BEGIN
PRINT 'there is nothing to do, the database is a mirror'
END
The same logic can be applied to the other 3 jobs and I was intending to suggest it as a connect item, except there doesn’t seem to be a section for Lync so I will contact product support and see what they think.
Thanks again.