Addendum - JL's posting

I swear there was a posting by Jonathan Lewis here before but I don't see it on this
replication. He said something to the affect that Oracle may have taken the files off line
when it realized they were corrupt, and that under certain circumstances Oracle can
write to certain kinds of datafiles. In any case, the alert log didn't have anything other
than log switches up until the time of the shutdown. Also I was using the standard UNIX
compression utitlity "compress" that affixes a .Z to the end. Here is a piece of the alert
log from the restart:

alter database open
ORA-1113 signalled during: alter database open... Mon May 10 18:01:22 1999
ALTER DATABASE RECOVER database

Mon May 10 18:01:22 1999
Media Recovery Start
WARNING! Recovering data file 40 from a fuzzy backup. It might be an online backup taken without entering the begin backup command. WARNING! Recovering data file 59 from a fuzzy backup. It might be an online backup taken without entering the begin backup command. Media Recovery Log
Mon May 10 18:01:47 1999
Media Recovery Complete
Completed: ALTER DATABASE RECOVER database

What are these fuzzy backup messages? Also, we noticed that the files could not be
uncompressed while Oracle was still up because Oracle reserved the space for the original
uncompressed size of the file, and so there wasn't enough room without bringing Oracle down.

Also, how can Oracle write to a compressed file? What kinds of compressed files.

Doug Cowles wrote:

> Recently, someone compressed 3 live datafiles by accident on a
> production system. After
> much scurrying about and even arguing with an Oracle duty manager on the
> phone, we
> did the following. We shut down abort, uncompressed the datafiles, and
> brought it back
> up again, it then recovered, and everything was fine. We lost nothing.
> We made the case for this approach because we had very large redo logs,
> only switched about 3 times a day. Also, we had received no errors
> about writting to a non-existent datafile, so we concluded that they
> hadn't been touched, and that therefore, the header information in the
> compressed file was still consistent with what the control file would
> expect. In addition, we would not
> lose the redo information, which would roll forward, and then roll back
> from rollback accordingly when it was brought back up again. I've
> been thinking about this again, and I don't get it. I know we've been
> through this a lot on this group lately, but why weren't the datafiles
> touched? Why didn't Oracle try to touch the datafiles. If you execute
> a transaction, doesn't the info go straight out to redo, the datafiles,
> and rollback, until it is committed, and then when it is committed,
> doesn't the rollback just flush out? In which case, over the course of
> 2 hours, why no arguments from Oracle about having no datafiles?
>
> Thanks in advance,
> Dc.
Received on Tue May 25 1999 - 14:01:16 CDT