Skip to Content
author's profile photo Former Member
Former Member

Tablespace grows to quick

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?

Add a comment
10|10000 characters needed characters exceeded

Assigned Tags

Related questions

5 Answers

  • author's profile photo Former Member
    Former Member
    Posted on Jul 30, 2014 at 02:15 PM

    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

    Add a comment
    10|10000 characters needed characters exceeded

  • author's profile photo Former Member
    Former Member
    Posted on Aug 01, 2014 at 03:05 PM

    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

    Add a comment
    10|10000 characters needed characters exceeded

    • 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

  • author's profile photo Former Member
    Former Member
    Posted on Aug 05, 2014 at 02:52 PM

    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

    Add a comment
    10|10000 characters needed characters exceeded

  • author's profile photo Former Member
    Former Member
    Posted on Aug 15, 2014 at 06:55 AM

    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


    Add a comment
    10|10000 characters needed characters exceeded

    • 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

  • author's profile photo Former Member
    Former Member
    Posted on Aug 27, 2015 at 05:35 PM

    Hi Harald,

    Is the issue resolved?

    Zarina

    Add a comment
    10|10000 characters needed characters exceeded

Before answering

You should only submit an answer when you are proposing a solution to the poster's problem. If you want the poster to clarify the question or provide more information, please leave a comment instead, requesting additional details. When answering, please include specifics, such as step-by-step instructions, context for the solution, and links to useful resources. Also, please make sure that you answer complies with our Rules of Engagement.
You must be Logged in to submit an answer.

Up to 10 attachments (including images) can be used with a maximum of 1.0 MB each and 10.5 MB total.