RE: ZFS snapshots

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_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Donahue, Adam
Sent: Tuesday, December 12, 2006 10:28 AM
To: Hemant K Chitale; oracle-l_at_freelists.org
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_at_singnet.com.sg]
Sent: Tuesday, December 12, 2006 10:20 AM
To: Donahue, Adam; oracle-l_at_freelists.org
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.

--
http://www.freelists.org/webpage/oracle-l


--
http://www.freelists.org/webpage/oracle-l