One of the most important obligations for DBA's is regularly checking alert log file.
To help myself I've written shell script which connects to several unix machines and examines alert log files looking for ORA- errors or 'Checkpoint not complete' lines.
Script was working fine for several months but yesterday it reported 'Binary file (standard input) matches'.
I've searched for that error and found solution:
grepreport "Binary file matches"?
greplisted all matching "lines" from a binary file, it would probably generate output that is not useful, and it might even muck up your display. So GNU
grepsuppresses output from files that appear to be binary files. To force GNU
grepto output lines even from files that appear to be binary, use the `-a' or `--binary-files=text' option. To eliminate the "Binary file matches" messages, use the `-I' or `--binary-files=without-match' option.
Source : http://www.gnu.org/software/grep/doc/grep_13.html
In my script I'm using egrep and grep powerful unix tools to search for specified pattern, so my problem was there. I don't know what happened with that alert log file but grep supressed output like it was binary file.
To fix that problem I've added -a along the grep lines and everything worked fine.
I've found what was causing this error and fixed little bug in my script. On specified database server logrotate was started with compression option. I'm analyzing whole log files (rotated with logrotate also), so in this case I've tried to read compressed logfile with cat tool. As I was reading binary file with cat output was little fuzzy and unreadable. To fix this I've used less tool which shows compressed log file in decompressed version as a text. Now script works like a clock.