| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> c.d.o.server -> Re: Online backup: Backup online redologs?
On Thu, 10 May 2001, Howard J. Rogers wrote:
> Charles, have you any idea what you're posting. Read my lips: your script
> assumes the REDO LOGS are not corrupt. If they are, you're little script is
> about as useful as a hole in the head.
Howard, in a perfect world, where business processes adjusted themselves to the needs of idealogy, and all of us spent our leisure time arduously studying Robert's Rules of Order, you advice would be excellent.
This is not a perfect world. I am sorry to disappoint you. At times, practical considerations might cause us to turn away from our high-minded ideals.
Oracle reference manuals are not dogma. All software has undocumented functionality, and we must not be afraid to exploit such functionality when it has demonstrated value.
The script I authored is by the book, excepting the execution of cp operations on the redologs. This action in no way corrupts the value of the material in the backup which uses the orthodox approach, but merely adds the possible functionality and flexibility of multiple approaches to data restoration.
Please do not become upset over a UNIX administrator running cp a few times in a non-destructive manner. There are many things in life which are much more worthy of our care and concern. I am more interested in your scientific curiousity.
I am not in any way assuming that the redologs are not corrupt, but I am assuming that the Oracle software is very flexible in dealing with corruption, perhaps a bit more flexible than the documentation would have us believe. We might condemn the Oracle documentation for not "telling the whole story," but we would then owe the Oracle software even greater praise for providing this "secret" flexibility.
In theory, theory would be the same as practice, but not in practice.
> Charles, for the last time: this is not "my" recovery methodology. There is
> only one recovery methodology that is guaranteed to work, and it's Oracle's.
Howard, perhaps we should review your comments on the issue:
"Your last statement is entirely true... There is no alternative (save relying on a method which may or may not work, depending on which way the wind is blowing, and how busy the database was when you hot-backed it up)."
Oracle *has* no formal recovery methodology in the case which interests me.
Please bear in mind that I had to restore 11 gigabytes of data several times before I had the evidence which coaxed your admission. I certainly worked for it. I am probably not finished with my investigations.
I am interested in a more rigorus understanding of the exact circumstances governing a successful hotbackup of online redologs. This is my aim.
> No, a standby database doesn't guarantee total data recoverability either,
> because it relies on the transfer of archives -and yes, there's always one
> redo log that hasn't been archived yet.
While I have not studied standby servers in minute detail, I was aware of these limitations.
> Does *your* manager know what you're doing with his system? Does he know
> you are flouting every backup and recovery rule in the book on the grounds
> that you've got away with it in the past? Does he know that you don't
> appear to have the distinction between backup and cloning clear in your
> head?
My manager wants to hold everything required to restore the database on a tape in his hand. I've explained the limitations and the unsupported status. I would like to give him a better answer, but I don't seem to be getting much help.
As I said, 6 cp operations do not me a heretic make.
What is your real hesitation in testing the approach and adding the same steps to your backup procedure, in light of your previous admission? I must say that I am dumbfounded by the community reaction.
> > There are two cases where we can be assured that recovery will NOT be
> > possible:
> > 1. SCNs appearing in the datafiles which are not in the redologs.
> > 2. Zero or multiple active redologs produced by the redolog hotbackup.
> And 3. I've internally corrupted my current redo log by attempting to do
> things to it which all Oracle documentation, all Oracle support personnel
> and the Wizard of Oz told me not to do -ie, back it up hot.
Is the database lost every time a shutdown abort takes place?
We are both making assumptions, but they are different assumptions. You assume that the redologs are fragile, I assume that they are durable.
There are three sides to the issue: your side, my side, and the truth.
> > However, the UNIX "cp" process will not be coordinating activity with
> > other processes; it spends most of its time in IO system calls. We must
> > assume that under most normal circumstances, the "velocity" of cp through
> > the files is much greater than LGWR's, and that on a system with no
> > in-flight transactions, the hot backup of the active log group will
> > closely resemble a "point" failure.
> "We must assume". Really? No thanks.
I might certainly be wrong in this approach; the man page for ftio under HP-UX certainly presents cause for concern.
Additional quantitative data is required.
> > In any case, it seems to me that it is worthwhile to take hotbackups of
> > the redologs, given Oracle's inability to perform complete recovery
> > without them. This probably explains why so many people adhere to the
> > practice when it is directly discouraged.
> Most people don't. They have far more sense.
I am utterly and completely incapable of understanding your point of view on this question. I have presented valid data and a partial hypothesis which you have rejected out-of-hand. Your position is contrary to the last thousand years of occidental thought.
> > My script does exhibit a certain flaw in this respect - it compresses the
> > redologs as it copies them, thus reducing the cp "velocity" and increasing
> > the risk of a log switch. I will rectify the flaw.
> I'm not discussing this issue with you anymore, Charles, I'm afraid. You
> have your head in the sand on this issue, your methodology sucks, and I've
> explained over and over *why*. And still you insist on a bunch of
> assumptions, parameters and ideas which have no bearing on the matter
> (Oracle guarantees complete recoverability of committed transactions,
> provided you retain all archives since the start of your last backup cycle
> and don't lose all members of the current redo log group, and that guarantee
> has sod all to do with "velocity" or any other iffy concepts you want to
> throw into the pot.) You're making a mountain out of a very simple molehill.
Howard, you are simply asking me to abandon my sandpile for yours. My particular sandpile is scientific enlightenment. It is not without its flaws, but I do not think that we as a community can afford any further migration from this position.
 |
 |