My Question here is does it really effect the performance if a Log Manager reads the AUD$ Table at an Interval of 10 seconds ?

Are you sure your log manager CONNECTs every 10 seconds?

eading/scanning the whole SYS.AUD$ table does not cause the performance issue ?

its the connection frequency that can cause performance issue.

create or replace PROCEDURE SAMPLESTOREDPROC_GET ( rc OUT 
SYS_REFCURSOR,offsetStr IN string)
is 
begin
open rc for 'SELECT * FROM SAMPLETABLE WHERE s_db_offset > offsetStr;
end SAMPLESTOREDPROC_GET;
/

The Oracle stored procedure should have two parameters, the OUT parameter of type
SYS_REFCURSOR that returns a cursor that could be used to retrieve data and an IN parameter,
which is an offset that can be used to decide which data is selected.

The important thing is that the parameter must of the same type than the column it is checked again (I think "timestamp# > [last date]" in this case).

grant CREATE SESSION to <user>;
grant select on v_$session to <user>;
grant select on v_$version to <user>;
grant select on SYS.DBA_AUDIT_TRAIL to <user>;

What should be interesting is the actual query or procedure code used by the tool.
If you have not it, you can ask your DBA to trace the tool and then get it.

If it is the case, then your DBA should create an index on sys.aud$.timestamp# column but before, to keep your contract with Oracle, you have to ask them to confirm this will not invalidate your Oracle support (it should not but you must ask them to keep their support). After that, your DBA must keep statistics up to date on sys.aud$; the frequency depends on the insert rate into this table (how many rows are inserted per hour/day).
Your DBA should also take care that he must drop the index before applying any patch/patchset and recreate it afterwards.

Are you sure your log manager CONNECTs every 10 seconds?

But as DBA is complaining that reading audit events by log manager are causing performance issue..

rather then reading the DBA_AUDIT_TRAIL all the times(or continuously) as a quick fix would you recommend me to start the Log Manager JDBC connector at an interval of 1 hour for five minutes only and then stop it.

Dear Support,

would appreciate if you please pass the following recommendation I received from an Oracle Expert to the developement team

The best option is to directly query SYS.AUD$ and not DBA_AUDIT_TRAIL and add an index on SYS.AUD$.NTIMESTAMP# as TIMESTAMP# is no more used
The query should be rewrite as follow:

with db_version as (select /*+ materialize */ banner from v$version where BANNER LIKE 'Oracle%' and rownum=1)
SELECT spare1 as OS_USERNAME, 
       userid as USERNAME, 
       USERHOST, 
       TERMINAL,
       TO_CHAR(from_tz(ntimestamp#,'00:00') at local,'YYYY/MM/DD HH24:MI:SS.FF6 TZR') 
         AS EXTENDEDTIME,
       TO_CHAR(logoff$time,'YYYY/MM/DD HH24:MI:SS') AS LFTIME,	
       TO_CHAR(cast((from_tz(ntimestamp#,'00:00') at local) as date),'YYYY/MM/DD HH24:MI:SS') 
         as TIMESTAMP,  
       aud.action# as ACTION, 
       act.name as ACTION_NAME, 
       SESSIONID, 
       ENTRYID, 
       statement as STATEMENTID, 
       RETURNCODE, 
       obj$creator as OWNER, 
       obj$name as OBJ_NAME, 
       user$guid as GLOBAL_UID, 
       SCN, 
       auth$grantee as GRANTEE, 
       to_nchar(substr(sqlbind,1,2000)) as SQL_BIND, 
       to_nchar(substr(sqltext,1,2000)) as SQL_TEXT,
       sys_context('USERENV','SERVER_HOST') as DHN,
       banner as DB_VERSION
FROM SYS.aud$ aud, audit_actions act, db_version 
WHERE ntimestamp# >= FROM_TZ(TO_TIMESTAMP ('%s', 'YYYY/MM/DD HH24:MI:SS.FF6'),dbtimezone) at time zone 'UTC'
  and rownum <= %d
  and act.action (+) = aud.action# 
ORDER BY ntimestamp#

I don't understand why EXTENDED_TIMESTAMP is used when the query ignores the specific part of this column: the time zone; this will lead to interpretation error if client and
server are not in the same time zone (and also subsecond is ignored); so TIMESTAMP is sufficient and you know it is in the server time zone.
If you really want to have the extended timestamp then the format should be something like "YYYY/MM/DD HH24:MI:SS.FF6 TZR".