From oracle-l-bounce@freelists.org Wed Mar 24 11:14:38 2004 Return-Path: Received: from air189.startdedicated.com (root@localhost) by orafaq.com (8.11.6/8.11.6) with ESMTP id i2OHEch22019 for ; Wed, 24 Mar 2004 11:14:38 -0600 X-ClientAddr: 206.53.239.180 Received: from turing.freelists.org (freelists-180.iquest.net [206.53.239.180]) by air189.startdedicated.com (8.11.6/8.11.6) with ESMTP id i2OHESo21985 for ; Wed, 24 Mar 2004 11:14:29 -0600 Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 6D9B6391727; Wed, 24 Mar 2004 12:09:53 -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 23584-13; Wed, 24 Mar 2004 12:09:53 -0500 (EST) Received: from turing (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id B0597390E3F; Wed, 24 Mar 2004 12:09:52 -0500 (EST) Received: with ECARTIS (v1.0.0; list oracle-l); Wed, 24 Mar 2004 12:08:43 -0500 (EST) X-Original-To: oracle-l@freelists.org Delivered-To: oracle-l@freelists.org Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 6FE6D391257 for ; Wed, 24 Mar 2004 12:08:42 -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 22140-97 for ; Wed, 24 Mar 2004 12:08:42 -0500 (EST) Received: from relay00.uchicago.edu (relay00.uchicago.edu [128.135.12.75]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id F31083916D5 for ; Wed, 24 Mar 2004 12:08:39 -0500 (EST) Received: from AIS-PC2.uchicago.edu (ais-pc2.uchicago.edu [128.135.15.112]) by relay00.uchicago.edu (8.12.10/8.12.9) with ESMTP id i2OHFlbq015834 for ; Wed, 24 Mar 2004 11:15:47 -0600 (CST) Message-Id: <5.2.0.9.2.20040324101243.0262cc88@nsit-imap.uchicago.edu> X-Sender: mschmitt@nsit-imap.uchicago.edu X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 24 Mar 2004 11:14:45 -0600 To: oracle-l@freelists.org From: Mike Schmitt Subject: RE: Falconstor/IPStor with Clariion, EMC Timefinder with Symmetrix In-Reply-To: <6.0.1.1.0.20040324144451.4444bdb0@pop.xs4all.nl> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new at freelists.org X-archive-position: 1700 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-To: oracle-l-bounce@freelists.org X-original-sender: mschmitt@uchicago.edu Precedence: normal Reply-To: oracle-l@freelists.org X-list: oracle-l X-Virus-Scanned: by amavisd-new at freelists.org I worked with a similar EMC solution that you are talking about at my last job. It worked pretty well for what we needed to do, however we did things different then you are talking about First, you are talking about splitting your BCV mirror every 30 minutes. You might want to look into that more because if I remember correctly, our synchronize was taking over 2 hours. However, we needed to attach broken mirrors every time. You might be able to make that time by only needing to sync your changes (depending on how much you have going on in the database). Second, we always placed the database in backup mode whenever we split the BCV. We used the archive logs to recover the dbfiles that were copied in the split, just as if recovering from a hot backup. We sent continuos copies of our archive logs over to the DR site along with the BCV split site to do a recovery if it was needed. We never went for the "one single atomic action", mainly because we just never felt 100% comfortable with it. Add in the fact that there really is no rolling forward if you are not placing the database in backup mode. If you are only taking a snapshot every x minutes, x minutes of data loss is guaranteed. As far as being certified by Oracle, our on site support said no at the time. It is pretty much the same as taking a backup of a database after a shutdown abort. It might work fine, just wasn't supported/recommended by Oracle. Perhaps things have changed since then, but I haven't heard that they have Good luck At 02:58 PM 3/24/2004 +0200, you wrote: >Lex, > >It _is_ expensive. Of course this was advised by EMC. The first step was >to consolidate three EMC Symmetrix boxes into one single 20 TB box. >That thing has three sets of disks: The normal mirrored set (2) and a BCV >(the 3rd). The BCV acts as a second mirror. Every 30 minutes the BCV is >split from the mirror, and all changed blocks are forwarded to the DR site >some 70 miles away. Where, of course, a symmetric Symmetrix setup is >needed. After sending the blocks, the BCV is added to the mirror again, >synchronizes and it all starts over again. In the mean time, at the >DR-site the normal mirror synchronizes with the BCV volume. Having all >storage in one EMC box enables the EMC box to do the BCV-split in one >atomic action. > >This works in theory, and in most cases it will do so in practice as well. >However, is there a situation this can be broken? I'm curious. If it >breaks, it's probably due to a bug in the EMC-SW. > >Another problem is that this setup will not recover from many human >errors, like dropping a table or tablespace. On the contrary, TimeFinder >will replicate the error flawless/flawfull (depending on the point of >view) to the other end. > >Mike's description pretty much covers the way Snapmirror of NetApp works. >That does the same, but enables you to keep several snapshots on-line, >thus enabling you to recover from a human error by activating the last >snapshot before the problem, probably do a TSPITR and continue work. >Falconsoft claims to have the same solution, HW-independent virtualizing >the storage. I'm curious about real-life stories about that! > >Regards, Carel-Jan > >=== >If you think education is expensive, try ignorance. (Derek Bok) >=== > > >At 03:26 PM 3/24/2004, you wrote: >>Mike, Carel-Jan, >> >>this sounds like a pretty expensive solution (and I am not talking money >>here) -- just imagine how many I/O activity you typically have against an >>online Oracle database... this means that after the "snapshot point in time" >>you basically start writing every block twice -- once to the database, and >>once to the snapshot. >> >>well, I can tell you, the Oracle mechanism (activated by putting files in >>backup mode) is definitely cheaper, because it is a more intelligent >>algorithm; it only writes full block images to the redo log when needed for >>recoverability, and definitely NOT for every change ... >> >>cheers, >>Lex. >> >>-----Original Message----- >>From: oracle-l-bounce@freelists.org >>[mailto:oracle-l-bounce@freelists.org]On Behalf Of Michael Boligan >>Sent: woensdag 24 maart 2004 13:52 >>To: oracle-l@freelists.org >>Subject: RE: Falconstor/IPStor with Clariion, EMC Timefinder with >>Symmetrix >> >> >> >> >> >> >>Carel-Jan, >> >> We are looking at using Compaq's Virtual Snapshot Replicator for one >>of >>our Sqealserver databases. The way it works is that when you create a >>snapshot >>it creates a file which contains a pointer to the database file. When >>someone >>changes the database, the before image is written to the snapshot file. At >>this >>point the file is no longer just a pointer it containts before image data. >>The >>backup, will backup the snapshot, not the database file. This provides a >>consistent image. This is very different than EMC Timefinder, which is used >>to >>backup a mirrored database. When you break the mirror Timefinder ensures >>that >>no data is in the buffers that would make the mirrored data incomplete. At >>this >>point you can bring the mirrored database down and get a cold backup, then >>resync the mirrors. I have not used it so I can't give any feedback as to >>if it >>works as advertised or not. >> Timefinder is a better option, in my opinion, and more expensive. >>Snapshot replication is for the lower end disk arrays that can't provide >>anything like Timefinder because the array doesn't have an on board CPU. >> >>HTH, >>Mike >> >> >>|---------+-----------------------------> >>| | "Lex de Haan" | >>| | >| | aljoin.nl> | >>| | Sent by: | >>| | oracle-l-bounce@fr| >>| | eelists.org | >>| | | >>| | | >>| | 03/24/2004 06:27 | >>| | AM | >>| | Please respond to | >>| | oracle-l | >>| | | >>|---------+-----------------------------> >> >> >--------------------------------------------------------------------------- >>--------------------------------------------| >> | >>| >> | To: >>| >> | cc: >>| >> | Subject: RE: Falconstor/IPStor with Clariion, EMC Timefinder with >>Symmetrix | >> >> >--------------------------------------------------------------------------- >>--------------------------------------------| >> >> >> >> >>Carel-Jan, >> >>the *one and only* reason why you need to put Oracle data files in backup >>mode is to avoid fractured blocks -- that is, ending up with Oracle blocks >>(spanning multiple OS blocks) with the header and footer out of sync. >>I don't know the technology of "snapshotting" all data files in a single >>atomic action -- sounds interesting to me... how do they do this? be >>careful, this might be marketing language, with some vipers under the grass >>;-) >> >>anyway, if it is really true that they can guarantee this "atomic >>snapshotting" you would be able to do hot backups without the need to put >>your tablespaces or data files in backup mode. By the way, you don't really >>need it at the database level; at the data file level it is good enough. >> >>Whether this is supported, that's another story. >> >>Cheers, >>Lex. >> >>-----Original Message----- >>From: oracle-l-bounce@freelists.org >>[mailto:oracle-l-bounce@freelists.org]On Behalf Of Carel-Jan Engel >>Sent: woensdag 24 maart 2004 10:12 >>To: oracle-l@freelists.org >>Subject: Falconstor/IPStor with Clariion, EMC Timefinder with Symmetrix >> >> >>Hi list, >> >>Does anyone know these products for HA-solutions? Especially, is it >>possible/certified to snapshot databases without putting the database in >>backup mode? >> >>The idea behind it is that all datafiles (incl. control and online >>redolog) are snapshotted in one single atomic action. The snapshot is >>stored at a local mirror, and asynchronously transferred to the DR-site. >>Failover can be performed by starting and (auto)recovering the database at >>the DR site. Because all files were copied in the state they were in one >>point in time, starting the database at the remote site should be the same >>as starting a database after a power failure. >> >>I'm not interested in all kinds of other HA solutions, the site I'm >>currently working for has implemented these solutions, but needs >>verification. It's hard to get commitment from the vendors that their >>products are certified for Oracle, although they advised and sold the >>solution :-(. >> >> >>Thanks, Carel-Jan >> >>=== >>If you think education is expensive, try ignorance. (Derek Bok) >>=== >> >> >>---------------------------------------------------------------- >>Please see the official ORACLE-L FAQ: http://www.orafaq.com >>---------------------------------------------------------------- >>To unsubscribe send email to: oracle-l-request@freelists.org >>put 'unsubscribe' in the subject line. >>-- >>Archives are at http://www.freelists.org/archives/oracle-l/ >>FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html >>----------------------------------------------------------------- >> >>---------------------------------------------------------------- >>Please see the official ORACLE-L FAQ: http://www.orafaq.com >>---------------------------------------------------------------- >>To unsubscribe send email to: oracle-l-request@freelists.org >>put 'unsubscribe' in the subject line. >>-- >>Archives are at http://www.freelists.org/archives/oracle-l/ >>FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html >>----------------------------------------------------------------- >> >> >> >>---------------------------------------------------------------- >>Please see the official ORACLE-L FAQ: http://www.orafaq.com >>---------------------------------------------------------------- >>To unsubscribe send email to: oracle-l-request@freelists.org >>put 'unsubscribe' in the subject line. >>-- >>Archives are at http://www.freelists.org/archives/oracle-l/ >>FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html >>----------------------------------------------------------------- >> >>---------------------------------------------------------------- >>Please see the official ORACLE-L FAQ: http://www.orafaq.com >>---------------------------------------------------------------- >>To unsubscribe send email to: oracle-l-request@freelists.org >>put 'unsubscribe' in the subject line. >>-- >>Archives are at http://www.freelists.org/archives/oracle-l/ >>FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html >>----------------------------------------------------------------- > >---------------------------------------------------------------- >Please see the official ORACLE-L FAQ: http://www.orafaq.com >---------------------------------------------------------------- >To unsubscribe send email to: oracle-l-request@freelists.org >put 'unsubscribe' in the subject line. >-- >Archives are at http://www.freelists.org/archives/oracle-l/ >FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html >----------------------------------------------------------------- ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request@freelists.org put 'unsubscribe' in the subject line. -- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------