Re: How about tailredo?

> Generally, when you tail -f on a log file without piping to a filter,
> you know the server is not busy. If it is, you're probably trying to
> filter on something specific and optionally take action on it, like
> this:
>
> #Only check user Joe's activity on this web server
> tail -f access_log | grep ^123.45.67.89
>
> #Email me immediately if Oracle has ORA-600
> nohup tail -f alert_ORCL.log | nohup perl -nle 'system("mailx -s 'ORCL
> error' youremail < /dev/null") if /^ORA-00600/' &

Good points.

> Similarly, it's up to the user of the redotail utility to make a useful
> filter.
>
> Attaching tail -f to a file (or redotail to an Oracle logfile) won't
> cause any contention on the filesystem. Since a long time ago, most if
> not all UNIX filesystems have adopted shared read locks. The overhead
> of tail -f on a file is negligible. Hopefully the same is true with
> OP's redotail. If not, Oracle may bundle this tool in a future version.

I was not talking about contention from the standpoint of locking. I was talking about contention with respect to disk resources. I have the disk head writing to the file. And now I have another process trying to perform a concurrent read of that file. In systems with a lot of activity, adding one more process to the mix to contend with the disk head resources can be noticable in your performance. Of course, this could be said for a large number of scenarios, not just this one.....

Cheers,
Brian

-- 
===================================================================

Brian Peasland
oracle_dba_at_nospam.peasland.net
http://www.peasland.net

Remove the "nospam." from the email address to email me.


"I can give it to you cheap, quick, and good.
Now pick two out of the three" - Unknown