Errata

in the first paragraph under "blocking factor" it is written "use dd to
read the volume, and pipe the output of dd to dump...." then there is an
example of what to type, in bold courrier, where the output is piped to
restore..

basically, the text shout read "use dd to read the volume, and pipe the
output to restore" (as the example shows)

The author says (as I say) that wild cards aren't supported in tar in the definition of files you're trying to recover. This is wrong. Here is an
example of a wild card use that works:

el bid

A lot of folks seem to think this. However, wild cards to define recovery
targets are just fine in GNU tar. The trick is to make sure they're protected
from expansion by the shell. For example:

tar xvzf LiVid.tgz "*news.html"

...will happily recover LiVid/html/news.html from the tarball.

In the last paragraph, the author states that dump, tar, and cpio do not have the capability of piping their output through compress.

Dump and tar (Solaris versions) allow the "-" specifier with the "f" option to
send their output to stdout instead of a file or device. The stdout can then
be piped to compress (or any other compress utility such as gzip, bzip2, etc.).

In the 1st full paragraph, the author states that tar cannot use ssh for networked backups. The table on the next page also states that tar can only
use rsh for backup across the network.

In fact GNU tar, in my opinion, deserves another look:

The option --rsh-command=<cmd> accepts any command, not only other locations
for the standard rsh, as is mentioned in the GNU tar manual. Thus, adding
--rsh-command=ssh prevents most problems piping might create, e.g.,
nonfunctional multivolume backups on a remote tape server.

"can be used in conjunction with rman to back up to disk."

Should read:

"can be used in conjunction with rman to back up to tape."

{Online Chapter 14} Could this be better?

There are two problems with the preceding scenario described. The
first problem is that the log of Art's transaction should have been
flushed to disk as soon as the transaction was committed. Changing
the instance to unbuffered logging fixes this problem. With the
previous buffered logging example, Art's transaction would be lost.
However, if it were flushed as soon as it was committed, the chances
of the transaction being lost would be greatly reduced.

To be honest, I can't find a good reason to run an instance in
buffered-logging mode anymore. Buffered logging used to provide a
performance gain, but in Informix 7.x, the performance difference
between unbuffered and buffered logging is minimal. (In fact, many
DBAs tell me the gain was never that great.) This performance gain
was the only reason for using >unbuffered< logging, and I believe
the risk of database corruption is just too great.

Another error: "last" <unbuffered> word should be <buffered>?

The two log files
listed in italics have the same pathname, I suspect the 2nd italicized
entry should be:

/db/Oracle/b/oradata/crash/redocrash01.log

which will result in two more corrections in the subsequent paragraph:

---------------------------------------------------------------------------
For example, if /db/Oracle/a/oradata/crash/redocrash01.log was missing,
but /db/Oracle/b/oradata/crash/redocrash01.log was intact, issue the
following command:

$ cp /db/Oracle/b/oradata/crash/redocrash01.log
/db/Oracle/a/oradata/crash/redocrash01.log
---------------------------------------------------------------------------

/logs1redolog01.log
/logs1redolog02.log
/logs1redolog03.log

/logs2redolog01.log
/logs3redolog01.log
/logs2redolog02.log
/logs3redolog02.log
/logs2redolog03.log
/logs3redolog03.log

These should read as:

/logs1/redolog01.log
/logs1/redolog02.log
/logs1/redolog03.log

/logs2/redolog01.log
/logs3/redolog01.log
/logs2/redolog02.log
/logs3/redolog02.log
/logs2/redolog03.log
/logs3/redolog03.log

(Note the addidtion of the / )