Dear Friends,
Our CMS server health status is red due to the pending audit events.
Auditing Metrics
Current Number of Auditing Events in the Queue 4658 (it is still growing)
any help would be appreciated
-Thanks-
Mahesh
k_mahesh9 (BOB member since 2012-01-30)
This happened to me once too. I’m using BI4 SP2. I opened a ticket with SAP and they walked me through a few steps.
First, remove zero length files from the auditing folder (C:\Program Files (x86)\SAP BusinessObjects\SAP BusinessObjects Enterprise XI 4.0\logging). Wait to see if the log files get written. This didn’t work for me and I don’t really think it’s significant because my system is working fine now and there are currently several zero length files in that folder.
Second, check the ODBC connection for the auditing database.
Third, re-enter database credentials on the CMC Auditing page. Restart the SIA.
Finally, and this is what finally worked for me, remove ALL files from the logging folder and restart the SIA. Perform some actions that will get audited and monitor to see that they get written to the logging folder and then to the database. In my case, it worked fine. One can only assume that one of the files got corrupted and that’s what was keeping them from being written to the database.
Be aware that removing all the files from the temp logging folder means the events in those files will never get written to the audit database. They’re lost.
Good luck.
monkeydog 
(BOB member since 2010-10-21)
We’re having the same issue. Since this is some time down the road since the last post, has any way to reintegrate the log files into the db been found? Does anyone know what B.O. process takes the log data and transfers it to the audit database? It seems ridiculous that the data is just ‘lost’ though we have the log files.
MizarKey (BOB member since 2009-12-16)
The symptoms we faced were a partial updating of the audit data within BI 4.0. The issue was solved as follows.
First one has to know that in a clustered environment there are several temporary auditing folders where auditing files are written and where the CMS picks them up. So on each server of the cluster check the Auditing folder under the default installation directory. It might happen that a specific problem on one server blocks the auditing processing flow, while for other servers the processing is still ok. Hence the partial updating of the audit.
Once you see an Auditing folder with a lot of (older) unprocessed auditing files, you are close to the problem. Most likely the oldest file has an entry that stops the Auditing from processing this file. In our case it was a field in a record for the SQL of a query that was too large to be inserted in the Monitoring database tables. At that point one can remove that record from the file or place a remark instead. What we did was unchecking the checkbox to capture the SQL for the queries in the Auditing pane of the CMC. The capturing of a query might be of interest, but not on a routine basis, hence our solution.
lc14190 (BOB member since 2002-08-29)
That does work, but we modified it to remove the files only from the first day where it got stuck. Presumably, the corrupt file that’s preventing it from running happened about where the last Audit Update Date is.
pcgeekus (BOB member since 2003-10-16)