BO4 - Audit data one hour behind

[former_member272336]

Hi,

Running some audit reports and finding that in audit report which uses audit universe from sap developer network forum showing all reports starting hour later than actually did.

e.g. If run query which uses

BOAUDIT.ADS_EVENT.START_TIME and query audit database directly shows data always one hour behind

if query select sysdate

from dual on database shows correct date but all date being written to BOAUDIT.ADS_EVENT.START_TIME  1 hour earlier than should be.

CMC/Auditing shows correct time

ADS Last Updated On

12/09/13 15:27:03 o'clock BST

just problem with data being written to BOAUDIT.ADS_EVENT.START_TIME

Any ideas?

Thanks

[former_member182521 · Accepted solution]

Hello Philip,

To make you understand about how auditing works,

CMS server or service acts as an system auditor which captures the information of an event and the server or application that triggers an auditable event is known as auditee. When an audited event is triggered, the auditee will generate a record and store it in a local temporary file. At regular intervals, the CMS communicates with the auditees to request these records and write the data to a database called Auditing Data Store (ADS).

The steps are as follows:-

1. An auditable event is performed by the server.
2. The auditee writes events in a temporary file.
3. The auditor polls the auditee and requests a batch of auditing events.
4. The auditee retrieves the events from the temporary files.
5. The auditee transmits the events to the auditor.
6. The auditor writes events to the ADS and signals the auditee to delete the events from the temporary files.

I would recommend you to have a look at CMS Polling interval, if you can do something with this

Regards

Mani

[former_member272336 · Accepted solution]

Hi Mani,

Our polling interval is 180 secs - auditing dataconsistently exacly 1 hour behind time it should be.

Suspect time setting controlling time recorded in audit database.

Not sure where this is setthough.

Any ideas?

Thanks

[Former Member]

We also had this same issue where Auditing data was not being written to the Audit DB for over two weeks. We tried everything we could think of, including taking the DB offline and then online; returning Auditing to default levels rather than custom levels; and resetting the Auditing DB password config in the CMC > Auditing screen. In the end, what we loosely determined is that around the point in time when Auditing logs ceased to be collected and written to the ADS, there were some large Auditing logs of 300-500KB+ queued in the file system whilst normal size logs were only 1-2KB. We deleted those large logs >20KB as well as some other old logs (but not all old logs, just the oldest and largest ones we were suspcicious of) and within about 3 minutes (the normal polling interval), the CMS collected and wrote all the old backed-up data to the Auditing DB. It then flushed the log files to 0KB in size.

If you're struggling with this issue, it's worth clearing some or all of the old or suspiciously large Audit logs from <install folder>\SAP BusinessObjects\SAP BusinessObjects Enterprise XI 4.0\Auditing. Then, either allow at least 4-5 minutes to elapse to see if old events are cleared and written to the Audit DB. If not, try restarting the SIA or at least the Auditing APS. In our case, deleting one or more problematic log files from that folder was all that was required and then the 'good' logs files got flushed to 0KB and written into the Audit DB.

The only thing we can think that triggered this problem was that we were heavily troubleshooting AD SSO with Kerberos keytab files at the exact time Auditing data ceased to be written to the Audit DB for two environments. One environment was running BI 4.1 SP2 Patch 4, the other was running BI 4.1 SP5 base. Both quit writing to the ADS within 50 minutes of each other, and both were having their AD SSO settings heavily adjusted (key tab files, service accounts, SIA restarting, Tomcat logging, SPNs being created, AD domain passwords, Vintela logging, bscLogin.conf edits, krb5.ini edits, etc.) All three other BI 4.1 SP2 Patch 4 environments were not being configured with AD SSO keytab files at that time and they continued to write Audit events normally. Therefore we conclude it was something we were doing with AD SSO that caused at least one Audit log to get corrupted on these two environments, and that corrupted file or files backed up the Auditing queue for over two weeks.

[former_member272336]

Thanks for update.

[CdnConnection]

Philip,

    The Audit database records the data in GMT timezone. What is your timezone?  You need to update the SQL within the UNX to reflect the required timezone.

Regards,

Ajay

[former_member272336]

Hi,

Our timezone is already gmt.

Thanks

[former_member182521]

Moreover If your environment creates numerous Audit events, The recommendation is to create a dedicated APS with Client Auditing Proxy Service. refer the ADAPT below.

-------------------------------------------------------------------------------------------------------------------

Delay in recording auditing events for high-volume systems

ADAPT01331216

Users who are expecting to generate large numbers of events may experience some delays in having those events recorded. Administrators for these systems are advised to create individual Adaptive Processing Server instances for any service or Client Application Proxy Service that will see heavy use. Consult the SAP BusinessObjects Enterprise XI Administrator's Guide for instructions.

-------------------------------------------------------------------------------------------------------------------

Regards

Mani