Tablespace grows to quick

[Former Member]

Hi together,

We have a productive SAP GRC 10.1 AC System SP04

Our table space growth very quck.

By checking the running jobs I found the job "GRAC_REPOSITORY_SYNC" which runs weekly in full sync mode

and daily incremental.

In my understanding it´s enough, when the Job runs only incremantal.

So that I can delete the full Sync job

Had anybody infromation if we run into criticals?

In the Documents I found, this Point was not described detailed.

Kind regards,

Harald

PS: a curiosity in our System we had change the runtime from our "GRAC_PFCG_ AUTHORIZATION_SYNC" Job from daily to weekly which reduce

the tablespace - is there any dependances between both Jobs known?

[Former Member]

Hi Harald,

Is the issue resolved?

Zarina

[Former Member]

Hi Gray,

after I had reduced the runtime of the Jobs the tables growth slowlier.

The big table grower which I had identified are the tables

GRACACTPERM and GRACACTERMSYS

As on the System is not so much traffic caused - why does it grow?

Have you got an idea.

Regards,

Harald

[gary_prewett]

These are significantly larger than what I've seen - by any chance, have you either:

1) Changed the analysis scope for a large number of your GRC/Access Control SOD functions from Single System to Cross System?

2) Have you added any systems/connectors to a cross system group, or made any other changes to cross system groups?

If that is the case, rule generation would definitely increase the size of these tables. The solution would be to re-visit your requirements and only select those functions where cross system SODs truly cross-system in scope, or remove unnecessary connectors from your cross-system groups (or both!) - and then regenerate your rules.

Adding connectors could be another reason - removing unneeded connectors would help reduce the size of these tables.

Regards,

Gary

[Former Member]

Hi Sabita,

I'm slow as far as to believe you. On our test System I hav both Jobs deleted but the data Volumina still growing - and that is on the test System! Where nearly nobody really work.

Any idea why?

for any idea open

Harald

[Former Member]

the phenomenon is, that the Archiv log which we had seperatet growth slowlier since we had Change the runtime from our "GRAC_PFCG_Sync.." from daliy to weekly in our productiv system. So is there a relation between this two Jobs.

And by the way - whey should I run a full sync when I run daliy incremental run.

What do you think.

Waiting for your response

Harald

[Former Member]

HI Harald,

In regards to the "PFCG_AUTH_SYNC" job, I would run this once a month to pick up any new transaction codes or authorisation objects created/maintained from the target system. The only time I may see this job being performed as a shorter time interval is during a big project build phase where new programs and roles are being created. Some GRC admins do this sync "Ad-hoc"/On-Demand.

As for why you should do a full sync (particularly the object repository sync) on a regular basis - this is because there have been cases at many implementations where the incremental syncs has not always accurately picked up the actual changes within the target systems. By scheduling this once a week, or even once a month, the data in regards to users and roles and assignments is maintained to be as accurate as possible.

Apart from the initial order of the job runs (PFCG first, then Object repository) there is no set rule of when the jobs must be performed. You are free to run your sync jobs as and when you wish as long as you are happy with the data obtained for the GRC system.

[Former Member]

Hi Harald,

PFCG or Repository sync should not cause quick table growth.

Please check if your spool location is DB and there is a long history of un removed Risk analysis jobs.

Check your audit requirements and delete the older jobs. after that you need  to run tableespace reorg jobs for related tables.

Thanks,

Sabita

[gary_prewett]

My two cents -

I've seen inconsistencies in ARA user level reporting that were only fixed by a full GRAC_REP_OBJ_SYNC (earlier than SP04). Recommendation from me would be to keep your weekly full sync job.

As for tablespace growth - not sure what tables are impacting growth but the GRACUSER* tables should be an accurate reflection of current user to role, user to profile, etc. assignments - that is, if your users and roles are fairly static you shouldn't see significant growth in these tables. Do you know what tables are impacting tablespace growth?

One report worth exploring is GRAC_DELETE_REPORT_SPOOL - if your temp tablespace is growing as a result of storing ARA reports (i.e., the growth is due to data in the GRACSODREP* tables), this report can purge older spooled reports for you.

Regards,

Gary

[Former Member]

Hi Harald

Which tables are you specifically referring to? If they are the GRAC tables containing the Object repository information, then the only way this will grow is if the number of users/roles/profiles and the assignments of roles/profiles to users has grown exponentially within your target systems.

The Full Sync will take a read of the target systems from scratch (i.e overwrite), whilst the Incremental syncs will only pick up the changes and update the GRAC tables accordingly (i.e. Append/Remove).

As far as I am aware, historical data is not kept within the related tables from the Object Repository sync.

Await your response