Page tree
Skip to end of metadata
Go to start of metadata

Purpose

It's very common that when running full sync jobs customers experience a slow performance. The jobs take a long time to complete, and this is talking about days to complete for those jobs. This document will explain why and what common practice that will help resolve this issue.

Overview 

When the GRC application is first installed on a R/3 platform it is a new or brand new system. After the installation, the database is newly created. When running those full sync jobs for GRC for the first time like User/Role/Profile or batch risk analysis the full sync jobs will take a long time since  the database doesn't have any up-to-date paths yet, and the jobs can get to a stanstill status.

Section 

For optimal responses, a full update statistics for the database needs to be run for the entire database, where it will scan through each table. After this first full update statistics, this update should be scheduled to run as a frequent job. It depends on how often and how much the data will get changed this job can be scheduled either weekly, monthly or quarterly. This will help speed up the full sync jobs.

Related Content 

Related Notes

1700811 - Scheduling the action usage full sync job

588668 - FAQ: Database statistics