I am trying to integrate SQL Server using JDBC PROTOCOL. Following is Mandatory view, for QRadar to work as mentioned in DSM guide

create view dbo.AuditData as

SELECT * FROM sys.fn_get_audit_file

('C:\inetpub\logs\SQLAudits*’,default,default);

GO

Now every time QRadar connect with our Database Engine and fetch AuditData view created above.

Suppose Qradar already fetch 1 billion audit lines and save that data in its own DB.

Next time , normally after 1 second, It again come to fetch the data in case any new audit available, and for doing this it again reads all the previous 1 billion logs then check new logs from it and save them in its own DB.

My point is that QRadar should not always fetch complete previous logs, which are no use of it.

But due to this scenario (which I believe Mandatory for QRadar) again and again reading all previous logs makes Disk I/O busy , processor busy and even Database Engine also become busy, and all these resources become busy for those LOGS which are old and not usable for Qradar.

Due to this scenario, system performance become very low, even server not allows to stop audit services. Then we have to start DB services to Stop Audit.

Kindly solve this issue.

Kindly suggest any way around

If you have a value other than event_time in the Compare Field for your JDBC log source configuration, then this is likely the issue. QRadar uses the compare field to track what data has been collected when it polls the remote database for information: https://www.ibm.com/docs/en/dsm?topic=SS42VS_DSM/c_dsm_JDBC_logsource_ms_sql.html

If the compare field is correct, then you likely need to get a case opened so we can evaluate what is going on with this log source. The Compare field value is typically set after the initial poll of the data. So, when you first create the log source, QRadar would import the available data. The compare field is like a bookmark where QRadar records the value of the last data queries from the database. The compare field allows QRadar to identify where to start the next query to the Microsoft SQL DB.

So, if your compare field is correct or that there is not another issue going on, the protocol should not retrieve old events. It should poll the existing state of the table, then use the compare field going forward to identify what events are collected in the next polling interface (i.e. event_time).

If you query your dbo.AuditData table, does it include a event_time column? If yes, open a case with support so we can review the configuration in the log source or put the protocol in to debug so we can review the detailed logs.