ZFS snapshots
- From: "Donahue, Adam" <Adam.Donahue@xxxxxxxxx>
- To: <oracle-l@xxxxxxxxxxxxx>
- Date: Sat, 16 Dec 2006 21:22:06 -0500
I am just sending this FTR. It was in follow up to our discussion of
ZFS snapshots and online backups, which I believe intermingled two
related but separate issues. I've outlined them below.
I. ZFS Snapshot-Based Refreshes
The goal is to find a fast way to periodically update a pre-prod
environment using a copy of the current production database, and to do
so with minimal production outage and without requiring a long restore,
recover operation.
So we have a production environment, running on ZFS, from which we take
a base snapshot and populate the target server. (This is effectively an
entire copy of the filesystem, and will thus take some time, but will
only need to be performed once.) Note that the copy of the snapshot is
never opened by Oracle - it's merely a backup of the production database
as of a point in time.
Going forward, we periodically snapshot production (without needing to
bring it down) and applying that snapshot incrementally to the most
recent target snapshot copy. If we do this frequently enough we end up
with a series of small updates to the copy.
And all of this, for our use case, is to simplify the occasional
rebuilding of the pre-production database. To do the rebuild, we simply
clone the latest ZFS snapshot on the target, freeing us from the need to
restore (duplicate) from RMAN, and allowing us to avoid any production
down time. It's just a clone of the most recent snapshot on the target.
But, of course, that clone is inconsistent, in that the snapshot was
taken when the datafiles may have been in an inconsistent state (SCN
wise). Because we took the datafile snapshot first, though, we can
recover them using the snapshotted logs, allowing us to open the
database. Voila!
(In case it's not clear, pre-production will diverge from production at
times, hence the need for the refresh. This is an operational
requirement here.)
I haven't yet heard an argument as to why this wouldn't work, and I'm
fairly convinced, indeed, that it will.
II. BEGIN BACKUP ... END BACKUP AND PITR
I posited that a hot backup via BEGIN BACKUP ... END BACKUP would not
allow one to recover the associated datafile(s) to a point in time
between those calls.
I found this note in the Oracle documentation that led me to this
hypothesis (emphasis mine):
Like any other backup, an online backup is composed of image
copies of all the datafiles that make up a tablespace. The point
to
remember is that as these files are being backed up they may
also be
in the process of being written to by the detached process DBWR.
Some
characteristics of an online backup are
o users are allowed normal access to all online
tablespaces;
thus, users can access the tablespace being backed up.
o when used for recovery the backup can only be used to
return
to the most recent state of the database, not to a
previous
state
o only the database files comprising a tablespace are
backed
up; the log files are being archived and the control
file
does not need to be backed up if there had been no
structural change to the database since the last
control file
backup
Yet if every change during the hot backup copies the changed block to
the log, I'm not exactly clear why PITR wouldn't be possible. It's a
lot more data in the log, sure, but the implication is that every SCN
reflected in the redo stream is associated with the block that changed,
indeed, the entire block change.
So perhaps I am misinterpreting that statement.
[Note that the statement The point to remember is that as these files
are being backed up they may also be in the process of being written to
by the detached process DBWR does not apply to the ZFS scenario I
outlined above, hence my conclusion we could do without ever having the
bring the datafiles into backup mode.]
Adam
--
This message may contain confidential, proprietary, or legally privileged
information. No confidentiality or privilege is waived by any transmission to
an unintended recipient. If you are not an intended recipient, please notify
the sender and delete this message immediately. Any views expressed in this
message are those of the sender, not those of any entity within the KBC
Financial Products group of companies (together referred to as "KBC FP").
This message does not create any obligation, contractual or otherwise, on the
part of KBC FP. It is not an offer (or solicitation of an offer) of, or a
recommendation to buy or sell, any financial product. Any prices or other
values included in this message are indicative only, and do not necessarily
represent current market prices, prices at which KBC FP would enter into a
transaction, or prices at which similar transactions may be carried on KBC FP's
own books. The information contained in this message is provided "as is",
without representations or warranties, express or implied, of any kind. Past
performance is not indicative of future returns.
Other related posts:
