RE: ZFS snapshots
- From: "Bobak, Mark" <Mark.Bobak@xxxxxxxxxxxxxxx>
- To: <Adam.Donahue@xxxxxxxxx>, "Hemant K Chitale" <hkchital@xxxxxxxxxxxxxx>, <oracle-l@xxxxxxxxxxxxx>
- Date: Tue, 12 Dec 2006 17:45:08 -0500
Adam,
It's getting to be evening here, and I'm still at the office and have
not had dinner, so, perhaps I'm spacing out and missing
something....but, I totally do not understand what you mean by "lose our
ability to perform PITR to any SCN within the backup window".
As I see it, (and pehaps I'm just not seeing it), you'd either take a
"consistent snapshot" of the data, without the tablespaces in backup
mode, and you'd make sure to copy all datafiles, controlfiles AND online
redo log files, in which case you'd have a *restartable* copy of the
database, where you'd start it up, and it would do instance recovery,
and would immediately begin to diverge from the source database. This
is not good for recovery, but great for cloning databases.
Or, you'd put the tablespaces into backup mode, copy the data however
you wished, snapshot, cp, whatever, it doesn't matter at that point,
which would give you a *recoverable* copy of the database. This would
be useful for full recovery from media failure, point in time recovery,
imcomplete recovery, etc. You would, at a minimum, have to recover the
database by applying all the archivelogs from the time the database went
into backup mode to the time the tablespaces exited backup mode.
Short summary, if you have a system that has a means to take a
"consistent snapshot" (there are lots of names and underlying
mechanisms, depending on the technology employed), then you can either
put the tablespaces into backup mode to create a recoverable copy, or
not put tablespace into backup mode to make a restartable copy (but if
you choose this, you need controlfiles and redos copied consistently as
well).
Hope that helps,
-Mark
PS Let me know if I totally missed the point somewhere....
--
Mark J. Bobak
Senior Oracle Architect
ProQuest Information & Learning
There is nothing so useless as doing efficiently that which shouldn't be
done at all. -Peter F. Drucker, 1909-2005
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Donahue, Adam
Sent: Tuesday, December 12, 2006 10:28 AM
To: Hemant K Chitale; oracle-l@xxxxxxxxxxxxx
Subject: RE: ZFS snapshots
I replied privately, but I don't think this step is strictly necessary -
nor desired, as we'd then lose our ability to perform PITR to any SCN
within the backup window, no?
Adam
-----Original Message-----
From: Hemant K Chitale [mailto:hkchital@xxxxxxxxxxxxxx]
Sent: Tuesday, December 12, 2006 10:20 AM
To: Donahue, Adam; oracle-l@xxxxxxxxxxxxx
Subject: RE: ZFS snapshots
You would still be recommended to run
ALTER TABLESPACE (DATABASE in 10g) BEGIN BACKUP .. before you take
the Snapshot
and
ALTER TABLESPACE (DATABASE) END BACKUP followed by ALTER SYSTEM
ARCHIVE LOG CURRENT after the Snapshot.
Hemant
At 10:58 PM Tuesday, Donahue, Adam wrote:
>Well, a ZFS snapshot is atomic - meaning, it's not like copying a
>datafile in that it doesn't read things block-by-block, meaning the
>file can change underneath you while you copy it. Instead, because
>of the way ZFS works, it merely marks an existing "uberblock" to be
>preserved, which is a single, atomic state of the filesystem as of a
>given time.
>
>I admit it's not clean - even if it works. But I'm curious if I'm
>missing something that would make it not work at all in some cases.
>
>Adam
Hemant K Chitale
http://web.singnet.com.sg/~hkchital
--
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.
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
