Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> RE: ZFS snapshots

RE: ZFS snapshots

From: Donahue, Adam <Adam.Donahue_at_kbcfp.com>
Date: Tue, 12 Dec 2006 09:58:38 -0500
Message-ID: <248A58C2AB63304C82F0706DE62FB345015AA29D@nyc.kbcfp.com>


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


From: Kerber, Andrew [mailto:Andrew.Kerber_at_umb.com] Sent: Tuesday, December 12, 2006 9:32 AM To: Donahue, Adam; oracle-l_at_freelists.org Subject: RE: ZFS snapshots

Your problem will probably be matching up the Oracle scn's. They change rapidly, and if they don't match Oracle will give you the old need media recovery message. I am not sure if you can copy them quick enough to keep all the Oracle scn's in sync. I know it can be done with the DB down, but I wouldn't count on doing it with the DB up.  

Andrew W. Kerber
Oracle DBA
UMB
816-860-3921
andrew.kerber_at_umb.com  

"If at first you dont succeed, dont take up skydiving"

-----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 8:18 AM To: oracle-l_at_freelists.org
Subject: ZFS snapshots  

Folks,

Sanity check question for those familiar with ZFS.

Is there any reason, assuming all datafiles were on a single ZFS filesystem (which is the level of consistent snapshot granularity), that something like the following wouldn't work to copy a database (and refresh on a regular basis) -

        zfs snapshot data_at_n 
        zfs snapshot log_at_n 
        zfs send -i data_at_n-1 data_at_tag | rsh target zfs receive data 
        zfs send -i log_at_n-1 data_at_tag | rsh target zfs receive log 
        zfs clone data_at_n data-qa 
        zfs clone log_at_n log-qa 

Given the granularity of writes to the redo logs, I'm trying to think of how corruption might be introduced here, if it could. From what I see above, though, it would be more-or-less like a straight-forward database crash - which would on the target side would be recovered automatically during instance startup.  

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.




NOTICE: This electronic mail message and any attached files are confidential. The information is exclusively for the use of the individual or entity intended as the recipient. If you are not the intended recipient, any use, copying, printing, reviewing, retention, disclosure, distribution or forwarding of the message or any attached file is not authorized and is strictly prohibited. If you have received this electronic mail message in error, please advise the sender by reply electronic mail immediately and permanently delete the original transmission, any attachments and any copies of this message from your computer system. Thank you.

-- 
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
Received on Tue Dec 12 2006 - 08:58:38 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US