Tabellen AsyncOperationBase indeholder oplysninger om Systemjobs, herunder også handlinger udført af Arbejdsprocesser (workflows), og tabellen kan vokse sig rigtig stor og derved påvirke ydelsen af SQL Serveren, og dermed også MS CRM. Dette indlæg handler om optimering af tabellen.

Dette indlæg er baseret på artiklen: Performance is slow if the AsyncOperationBase...

OBS! Backup anbefales før gennemførelse af nedenstående optimering, ligesom det anbefales ikke at gennemføre nedenstående optimering mens der er brugere på systemet, da det påvirker ydelsen af systemet og optimeringsprocessen. Sidst, men ikke mindst, bør man læse hele ovennævnte artikel, der der indgår en række forslag til hvad man kan gøre hvis forskellige situationer opstår under optimeringen.
 

Problemet

Tabellen AsyncOperationBase er en form for log, som med tiden vokser sig rigtig stor, især hvis man har mange arbejdsprocesser (workflows) kørende. Enhver hændelse omkring arbejdsprocesser bliver registreret og det fylder. Man kan antage den holdning, at når en arbejdsproces er fuldendt som en succes, er der ingen grund til at man gemmer en sådan information i årevis. Dog kan informationen være nyttig i en periode, da den jo dokumenterer en hændelse.

Jeg har netop arbejdet for en kunde som havde en organisationsdatabase (<organisation>_MSCRM), som havde en størrelse på knap 33 GB, hvor tabellen AsyncOperationBase alene fyldte godt 16 GB. Der var godt 24 millioner poster i tabellen. Tabellens størrelse påvirker ydelsen dramatisk.

En nærmere analyse viste, at ved at fjerne "unødvendige" poster kunne tabellen mindskes til ca. 300.000 poster. De såkaldt "unødvendige" poster omfatter, se også afsnittet "Om tabellen AsyncOperationBase" herunder:

• OperationType 1: Systemhændelser
• OperationType 9: Indsamling af data fra Customer Experience Program
• OperationType 10: Arbejdsproces/Workflow
• OperationType 12: Intern proces i MS CRM
• OperationType 25: Operation, som optimerer en organisations indeks til dokumentsøgning
• OperationType 27: Operation hvor kontrakter er blevet opdateret
• StateCode 3: Operationen er gennemført (Completed)
• StatusCode 30: Operationen er lykkedes (Succeeded)
• StatusCode 32: Operationen er annulleret (Canceled)
    

Eksempel på System Jobs, som indeholder registreringer af forskellig art (System Job Type og Status Reason)

Løsningen

Løsningen på problemet, var at optimere tabellen AsyncOperationBase ved at slette "unødvendige" poster. Dette gøres ved brug af et SQL Server-script, som anbefales i ovennævnte Knowledge Base-artikel.

Scriptet køres på den organisationsdatabase, som indeholder den AsyncOperationBase, der skal optimeres.

IF EXISTS (SELECT name FROM sys.indexes WHERE name = N'CRM_AsyncOperation_CleanupCompleted')
DROP INDEX AsyncOperationBase.CRM_AsyncOperation_CleanupCompleted
GO

--Create Index on AsyncOperationBase, to make operations faster
CREATE NONCLUSTERED INDEX CRM_AsyncOperation_CleanupCompleted
ON [dbo].[AsyncOperationBase] ([StatusCode],[StateCode],[OperationType])
GO

DECLARE @DeleteRowCount int
SELECT  @DeleteRowCount = 2000
DECLARE @DeletedAsyncRowsTable TABLE (AsyncOperationId UniqueIdentifier Not Null Primary Key)
DECLARE @continue int, @rowCount int
SELECT  @continue = 1

WHILE (@continue = 1)
BEGIN
  BEGIN TRAN
   INSERT INTO @DeletedAsyncRowsTable(AsyncOperationId)
   SELECT TOP (@DeleteRowCount) AsyncOperationId FROM AsyncOperationBase
    WHERE OperationType IN (1, 10, 9, 12, 25, 27) AND StateCode = 3 AND StatusCode in (30, 32)
   SELECT @rowCount = 0
   SELECT @rowCount = Count(*) FROM @DeletedAsyncRowsTable
   SELECT @continue = CASE WHEN @rowCount <= 0 THEN 0 ELSE 1 END
   IF (@continue = 1)
    BEGIN
     DELETE WorkflowLogBase FROM WorkflowLogBase W, @DeletedAsyncRowsTable d
      WHERE W.AsyncOperationId = d.AsyncOperationId
 
     DELETE BulkDeleteFailureBase FROM BulkDeleteFailureBase B, @DeletedAsyncRowsTable d
      WHERE B.AsyncOperationId = d.AsyncOperationId
 
     DELETE WorkflowWaitSubscriptionBase FROM WorkflowWaitSubscriptionBase WS, @DeletedAsyncRowsTable d
      WHERE WS.AsyncOperationId = d.AsyncOperationID
    
     DELETE AsyncOperationBase FROM AsyncOperationBase A, @DeletedAsyncRowsTable d
      WHERE A.AsyncOperationId = d.AsyncOperationId
    
     DELETE @DeletedAsyncRowsTable
   END
 COMMIT
END

--Drop the Index on AsyncOperationBase
DROP INDEX AsyncOperationBase.CRM_AsyncOperation_CleanupCompleted

Resultatet

Resultatet af optimeringen:

Scenarie 1

• Kørslen af scriptet tog ca. 5,5 time, med sletning af ca. 4,3 millioner poster i timen.
• Der blev slettet mere end 24 millioner poster. Der var 318.110 poster tilbage efter sletningen, herunder dem som indikerer ventende arbejdsprocesser
• En sammenligning af forskellige forespørgsler, ved brug af Avanceret søgning, viste en forbedret ydelse på mellem 40-470%.
• Databasen samlede størrelse, inklusive logfil, blev mindsket fra ca. 32,6 GB til 18,4 GB.

Scenarie 2

• Kørslen af scriptet tog ca. 30,5 time, med sletning af ca. 4,9 millioner poster i timen.
• Der blev slettet mere end 149 millioner poster. Der var 84.216 poster tilbage efter sletningen, herunder dem som indikerer ventende arbejdsprocesser
• Databasen samlede størrelse, inklusive logfil, blev mindsket fra ca. 209 GB til 21,5 GB.

Om tabellen AsyncOperationBase

Tabellen AsyncOperationBase indeholder mange forskellige typer poster, som hver især fortæller hvilken form for information posten indeholder. Informationerne fordeler sig primært over 3 felter.

Feltet OperationType kategoriserer informationer.

Felterne StateCode og StatusCode indikerer hvilken status og tilstand en operation er i.

Yderligere informationer

Du kan læse mere om emner i dette indlæg på følgende sider:

Grundlag for dette indlæg (Engelsk): Performance is slow if the AsyncOperationBase...
Indlæg om indstillinger i registreringsdatabasen (Engelsk): AsyncOperationBase and WorkflowLogBase tables grow...
Indlæg om indstillinger i registreringsdatabasen (Engelsk): Workflow Expansion Task records cause the AsyncOperationBase table to grow...