RAR 5.2 Background Job Log "INFO" Messages

[Former Member]

Hi All,

I initiated my first full user risk analysis sync within RAR 5.2 The background job has been running for about 3 days and is about 5% complete. I have applied the following OSS notes, to help with the background processing: 999785 and 1121978. The background job log keeps giving me "INFO" messages and looking through the messages does not help me isolate the problem. For example:

Aug 18, 2008 9:12:00 AM com.virsa.cc.common.RiskAnalysisReport render

INFO: RiskAnalysisReport render: memory changed=1M, free=449M, total=1968M

Aug 18, 2008 9:12:09 AM com.virsa.cc.common.RiskAnalysisReport render

INFO: RiskAnalysisReport render: memory changed=1M, free=432M, total=1968M

Aug 18, 2008 9:12:09 AM com.virsa.cc.common.RiskAnalysisReport render

INFO: RiskAnalysisReport render: memory changed=2M, free=429M, total=1968M

Aug 18, 2008 9:12:22 AM com.virsa.cc.common.RiskAnalysisReport render

INFO: RiskAnalysisReport render: memory changed=1M, free=413M, total=1968M

Aug 18, 2008 9:56:23 AM com.virsa.cc.xsys.bg.CCWarDaemon deleteTempSpoolFiles

INFO: Clean up spool directory...

Does anyone know what "Clean up spool directory" refers to? When I look at the file location the spool log is located at, it is empty. I also don't know why it keeps cycling through the "memory change" messages. Does anyone have any advice?

There are no issues when it comes to running risk analysis in the foreground, in fact the system is very quick.

Thank you,

Joy

[former_member184114]

Even I had the same problem. Inspite of applyin the note, the problem persisted.

To solve this problem,kindly switch of the Archive Log at database level.

You can do this by user BRTOOLs. I dont remember exactly, however, you can see it there.

Once you switch it off, kindly re-run the reports. This time, it should come.

Regards,

Faisal

[former_member196034]

We installed GRC RAR 5.2 and faced similar issues. One of the notes we followed instructed us to index the table virsa_cc_pmvrl (i may have just misspelt the pmvrl, make sure you check before doing such a thing).

If you are running GRC on an Oracle database, consider this too.

Rgds,

Babak

[Former Member]

Thanks for the response. Do you happen to know what OSS note you are referring to?

Joy

[Former Member]

Hi Joy,

if you are using an oracle database have a look at note 1044174.

I hope the information will help you.

Regards

Dirk

[former_member196034]

Hi, I was referring to SAP note: 1044174 - Recommendation for CC 5.x running on Oracle 10G Database.

Check Gregory Cook's message in this thread:

[;

[Former Member]

All,

We applied OSS Note 1178370 - Risk Analysis and Remediation - Table sizes. Doing so, resolved the issue.

Thank you,

Joy

[Former Member]

Hi Joy,

Can you let me know what you specifically implemented from OSS Note 1178370? What did you change, etc? Right now we're having similiar issues as you are/were having.

Any info would be greatly appreciated!

Thanks

Jes Behrens

[Former Member]

Hello Joy,

The note that you are referring is correct, just make sure background daemon is running. In this note the following is mentioned.

[If the daemon still does not start check the Max Heap Size to ensure that it is set to 1024. This can be changed in the CONFIGTOOL on the SAP J2EE at the instance level. If the system is 32 BIT the maximum setting is 1024M, if system is 64 bit maximum setting is 2048M.

Check to see if the Background Workers and Web Service Workers are in IDLE status or RUNNING. All should show IDLE if the daemon is running properly.]

So first make sure background daemon is working. If it is working then follow this procedure to configure spool.

1) Go to miscellaneous setting in compliance calibrator under configuration tab.

2) Enter a spool file location for Background Job

for example G:/BJSF/ and go to you server G: drive and manually create these folders, BJSP as the root folder.

BJSP > virsa > bgJobSpool

then try scheduling a new background job, let's see what happens.

Best regards,

Amol Bharti

[Former Member]

Thanks for the advice, our background daemon is running, that doesn't seem to be the problem.

Joy