Return-Path: Delivered-To: 2-oracle-l@orafaq.com Received: (qmail 32275 invoked from network); 12 Dec 2006 08:19:26 -0600 Received: from freelists-180.iquest.net (HELO turing.freelists.org) (206.53.239.180) by 69.64.49.119 with SMTP; 12 Dec 2006 08:19:22 -0600 Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 89FC7565560; Tue, 12 Dec 2006 09:18:22 -0500 (EST) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22583-05-5; Tue, 12 Dec 2006 09:18:22 -0500 (EST) Received: from turing (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 048F25655F8; Tue, 12 Dec 2006 09:18:21 -0500 (EST) Received: with ECARTIS (v1.0.0; list oracle-l); Tue, 12 Dec 2006 09:17:17 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 06A7D565577 for ; Tue, 12 Dec 2006 09:17:17 -0500 (EST) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22082-05 for ; Tue, 12 Dec 2006 09:17:16 -0500 (EST) Received: from ns1.nyc.kbcfp.com (ns1.nyc.kbcfp.com [204.253.248.123]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with SMTP id B0D96565532 for ; Tue, 12 Dec 2006 09:17:15 -0500 (EST) Received: from deputy.nyc.kbcfp.com ([204.253.250.11]) by ns1.nyc.kbcfp.com with SMTP id M2006121209184228544 for ; Tue, 12 Dec 2006 09:18:42 -0500 Received: from EXNY2-VS1.nyc.kbcfp.com (exny2a.nyc.kbcfp.com [204.253.250.37]) by deputy.nyc.kbcfp.com ((mta/smtp)) with ESMTP id kBCEI8sF009341 for ; Tue, 12 Dec 2006 09:18:09 -0500 (EST) X-From: Adam.Donahue@kbcfp.com Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C71DF8.590F9B2A" Subject: ZFS snapshots Date: Tue, 12 Dec 2006 09:18:08 -0500 Message-ID: <248A58C2AB63304C82F0706DE62FB345015AA299@nyc.kbcfp.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ZFS snapshots From: "Donahue, Adam" To: X-KBCDisclaimer: 1 X-Scanned-By: MIMEDefang 2.55 on 204.253.250.11 X-archive-position: 43024 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-to: oracle-l-bounce@freelists.org X-original-sender: Adam.Donahue@kbcfp.com Precedence: normal Reply-to: Adam.Donahue@kbcfp.com List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: oracle-l X-List-ID: oracle-l List-subscribe: List-owner: List-post: List-archive: X-list: oracle-l X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at avenirtech.net ------_=_NextPart_001_01C71DF8.590F9B2A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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@n zfs snapshot log@n zfs send -i data@n-1 data@tag | rsh target zfs receive data zfs send -i log@n-1 data@tag | rsh target zfs receive log zfs clone data@n data-qa zfs clone log@n log-qa=20 - all with the database online and running without any instance downtime? 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 --=20 This message may contain confidential, proprietary, or legally privileged i= nformation. No confidentiality or privilege is waived by any transmission t= o an unintended recipient. If you are not an intended recipient, please not= ify 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 KB= C Financial Products group of companies (together referred to as "KBC FP").= =20 This message does not create any obligation, contractual or otherwise, on t= he 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 necessaril= y represent current market prices, prices at which KBC FP would enter into = a transaction, or prices at which similar transactions may be carried on KB= C FP's own books. The information contained in this message is provided "as= is", without representations or warranties, express or implied, of any kin= d. Past performance is not indicative of future returns. ------_=_NextPart_001_01C71DF8.590F9B2A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline ZFS snapshots

Folks,

Sanity check question for those familiar w= ith ZFS.

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

        zfs snapshot data@n
        zfs snapshot log@n
        zfs send -i data@n-1 <= FONT SIZE=3D2 FACE=3D"Arial">data@tag | rsh target zfs receive data<= I>
        zfs send -i log@n-1 data@tag | rsh target zfs receive log
        zfs clone data@n data-qa
        zfs clone log@n log-qa

- all with the database online and runn= ing without any instance downtime?=

Given the granularity of writes to the red= o 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 lik= e 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 privi= leged information. No confidentiality or privilege is waived by any transmi= ssion to an unintended recipient. If you are not an intended recipient, ple= ase notify the sender and delete this message immediately. Any views expres= sed 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 "KB= C FP").=20

This message does not create any obligation, contractual or otherwise, on t= he 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 necessaril= y represent current market prices, prices at which KBC FP would enter into = a transaction, or prices at which similar transactions may be carried on KB= C FP's own books. The information contained in this message is provided "as= is", without representations or warranties, express or implied, of any kin= d. Past performance is not indicative of future returns.

= ------_=_NextPart_001_01C71DF8.590F9B2A-- -- http://www.freelists.org/webpage/oracle-l