When it comes down to it, nearly all auditing is useless until therešs a
problem . Do you ever look at the $ORACLE_HOME/rdbms/audit files? Have
you turned the auditing of sys operation on and perhaps changed
audit_file_dest to point somewhere else.
If an intrusion occurs, I hate to explain that I had turned off something
which might of helped us detect that intrusion or provide an audit trail of
it.
On 9/26/07 6:25 AM, "Paul Drake" <bdbafh_at_gmail.com> wrote:
>
>
> On 9/26/07, Mercadante, Thomas F (LABOR) <Thomas.Mercadante_at_labor.state.ny.us>
> wrote:
>> Steeve,
>>
>>
>>
>> I agree with John except for one thing. I leave listener_log status in the
>> off position. Unless I need to debug something (or some folks have a need
>> for auditing connections), this is a useless file, and it's just one more
>> thing that needs to be managed.
>>
>>
>>
>> Oracle has a bad habit of creating audit log files and growing them all over
>> the server with no option of turning them off. You don't know about them
>> until the disk is full and you go searching for them. Whenever I have the
>> option of turning one off, I usually do.
>>
>>
>>
>> Hope this helps.
>>
>>
>>
>> Tom
>>
>>
>> From: oracle-l-bounce_at_freelists.org [mailto: oracle-l-bounce_at_freelists.org
>> <mailto:oracle-l-bounce_at_freelists.org> ] On Behalf Of John Hallas
>> Sent: Wednesday, September 26, 2007 3:52 AM
>> To: bisst_at_touchtunes.com; oracle-l_at_freelists.org
>> Subject: RE: Listener.log not been updated
>>
>>
>>
>> It must be an internal 4Gb limit within Oracle if you can create a larger
>> file on the same server.
>>
>>
>>
>> TBH having a 4Gb is poor management anyway. Why not create a new one every
>> week or so. It will be a lot easier to manage and if you do need to view it I
>> think a 4Gb will be almost unreadable.
>>
>>
>>
>>
>> From: oracle-l-bounce_at_freelists.org [mailto: oracle-l-bounce_at_freelists.org
>> <mailto:oracle-l-bounce_at_freelists.org> ] On Behalf Of Steeve Bisson
>> Sent: 26 September 2007 02:20
>> To: oracle-l_at_freelists.org
>> Subject: Listener.log not been updated
>>
>>
>>
>> I am on Linux x86 OEL4 using Oracle 10.2.0.3 <http://10.2.0.3> .
>>
>> My listener.log is not been updated since the 30 May.
>>
>> cd /opt/oracle/app/oracle/product/10.2.0/db_1/network/log
>> [oracle_at_juk-prod log]$ ll
>> total 4203424
>> -rw-r--r-- 1 oracle oinstall 4294967428 May 30 21:49 listener.log
>>
>> If I do status in lsnrctl:
>> Listener Parameter File
>> /opt/oracle/app/oracle/product/10.2.0/db_1/network/admin/listener.ora
>> Listener Log File
>> /opt/oracle/app/oracle/product/10.2.0/db_1/network/log/listener.log
>>
>> Everything else seems fine. I connect to the database with no problem.
>> Any idea why the listener would stop writing log?
>>
>> To solve the problem, I did the following in lsnrctl:
>> SET LOG_FILE list.log
>>
>> Now I get information in list.log
>> [oracle_at_juk-prod log]$ ll
>> total 4222736
>> -rw-r--r-- 1 oracle oinstall 4294967428 May 30 21:49 listener.log
>> -rw-r--r-- 1 oracle oinstall 511462 Sep 16 19:41 list.log
>>
>>
>> Any idea why it would stop logging info once the log was at 4gig?
>> I have 32GIG datafile on that machine.
>> Is there a thresholds where oracle stop to log, so it is possible to vi the
>> log?
>> Anyone has documentation on this? Or a link on that subject?
>>
>>
>
> Either a full log or turning the listener logging off will leave one
> completely blind to a remote dictionary-based attack (guessing passwords).
>
> As far as maximum file size, the block size has something to do with that.
> You mentioned that you have a 32 GB datafile. Perhaps the db_block_size=8192
> bytes?
> I'm guessing that the block size for the filesystem on which the file
> listener.log resides is 1024 bytes.
>
> Sorry, I'm not supposed to guess.
> Would you mind supplying the database db_block_size and the filesystem block
> size for the file listener.log (under /opt/oracle/app)?
>
> thanks,
>
> Paul
>
>
>
--
http://www.freelists.org/webpage/oracle-l
Received on Wed Sep 26 2007 - 10:01:37 CDT
