Return-Path: Delivered-To: 2-oracle-l@orafaq.com Received: (qmail 15549 invoked from network); 13 Dec 2007 18:25:11 -0600 Received: from freelists-180.iquest.net (HELO turing.freelists.org) (206.53.239.180) by static-ip-69-64-49-119.inaddr.intergenia.de with SMTP; 13 Dec 2007 18:25:10 -0600 Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 23C207D86F8; Thu, 13 Dec 2007 19:25:11 -0500 (EST) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10219-01; Thu, 13 Dec 2007 19:25:11 -0500 (EST) Received: from turing (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 8454D7D8906; Thu, 13 Dec 2007 19:25:10 -0500 (EST) Received: with ECARTIS (v1.0.0; list oracle-l); Thu, 13 Dec 2007 18:38:14 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 3787C7D894F for ; Thu, 13 Dec 2007 18:38:14 -0500 (EST) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00482-08 for ; Thu, 13 Dec 2007 18:38:14 -0500 (EST) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.180]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 4A9317D87F1 for ; Thu, 13 Dec 2007 18:38:07 -0500 (EST) Received: by py-out-1112.google.com with SMTP id u77so585017pyb.3 for ; Thu, 13 Dec 2007 15:38:02 -0800 (PST) Received: by 10.65.242.7 with SMTP id u7mr5592007qbr.34.1197589081588; Thu, 13 Dec 2007 15:38:01 -0800 (PST) Received: by 10.64.112.6 with HTTP; Thu, 13 Dec 2007 15:38:01 -0800 (PST) Message-ID: <611ad3510712131538k5dff98f0u100d6ebf6ed83cd8@mail.gmail.com> Date: Thu, 13 Dec 2007 17:38:01 -0600 From: "Jeremy Schneider" To: "Ghassan Salem" Subject: Re: superblock backups, ASM vs OCFS2 Cc: "Finn Jorgensen" , Oracle-L In-Reply-To: <411d50f60712131159x14fbba40s96196278f18108a3@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_19830_27668718.1197589081577" References: <611ad3510712130850j4575aea3k4d43481b27699908@mail.gmail.com> <74f79c6b0712130924ke0aed62i15e4ee7fc302460a@mail.gmail.com> <611ad3510712131103u14df81ecl43800d5d1a21fce6@mail.gmail.com> <411d50f60712131159x14fbba40s96196278f18108a3@mail.gmail.com> X-archive-position: 3936 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-to: oracle-l-bounce@freelists.org X-original-sender: jeremy.schneider@ardentperf.com Precedence: normal Reply-to: jeremy.schneider@ardentperf.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: Debian amavisd-new at localhost.localdomain ------=_Part_19830_27668718.1197589081577 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline FYI, from the traffic on the ocfs-users list it sounds like the disk headers contain information that isn't captured by md_backup. But I'm going to hold off on saying anything else until I've tried it out... On 12/13/07, Ghassan Salem wrote: > > Jeremy, > asmcmd, in 11.1.0.6 already has a 'backup' command (and a restore). Is it > enough? I haven't tried it yet to see what it can recover. > > rgds > > On Dec 13, 2007 8:03 PM, Jeremy Schneider > wrote: > > > OCFS2 and ASM both support async and directIO (note 279069.1)**. > > Performance-wise, I'm pretty sure that there's not a big difference one way > > or the other for day-to-day operation. There may be some minor differences > > when extending files or creating new ones but I don't think that they're > > anything to fuss over. > > > > Since there's no major difference in performance-related capabilities, > > for me the choice would probably hinge on other factors. > > > > - OCFS2 is open-source. (+1 for power-users!) > > - OCFS2 already does superblock backups. (+1 for recoverability.) > > - ASM is integrated with Database Console/Grid Control. (+1 for > > manageability.) > > - ASM does cluster-aware volume management. (+1 for flexibility.) > > > > I do think that the last one is a strong point in favor of ASM. Volume > > management really can simplify things. And with ASM you get volume > > management and still have a single point of contact for any bugs you > > discover - no finger-pointing. Also, I don't know of any open-source LVM > > that I'd really want to use to do any kind of redundancy - so if you need > > software mirroring on linux then I think that ASM is really the best > > solution for you. And if you want ease-of-management then ASM is better in > > that area too. > > > > Now you could get volume management and stay open-source with OCFS2 by > > using cLVM. However I don't think that cLVM currently supports mirroring or > > parity. IBM's EVMS also has cluster functionality and is GPL - but from the > > release history and mailing lists it seems like noone's maintaining it > > anymore. And I think you can buy ServiceGuard for Linux and get > > cluster-aware volume management there too. There might be more commercial > > solutions that I'm not aware of. > > > > Not to mention GFS, which I'd also really like to spend more time > > learning someday. GFS has its own feature called "pools" which also provide > > volume management though I think that RedHat is moving toward cLVM for > > cluster volume management with GFS. You can run your Oracle RAC database on > > GFS (note 329530.1) but if there are any filesystem-related bugs then > > Oracle will tell you to call RedHat for the fix (note 423207.1). > > > > Anyway, just some random musings... I've always liked being able to dig > > into the source code of whatever's running on my systems so I'm kindof keen > > on OCFS2... but it does appear that the general push is toward ASM these > > days. > > > > DB+RAC+ASM/OCFS+OEL+Oracle VM... is there anything Oracle doesn't do > > these days? Next year I'm anticipating Oracle Open Office... after all > > it's the final frontier... > > > > ======== > > Addendum: while I was writing this email there were a few responses on > > the ocfs-users list (I cross-posted). > > > > Definitive answers: > > OCFS: "Backup superblock has been available with ocfs2-tools 1.2.3 (Mar > > 2007)." > > http://oss.oracle.com/projects/ocfs2/dist/documentation/ocfs2_faq.html#BACKUPSB > > > > > > ASM: "In 11.1.0.7 (and beyond) we will have a backup of the disk header > > (the > > first 4k). Prior to that, we have been able in most circumstances to > > reconstruct the disk header using KFED. KFED will still be the tool to > > restore the disk header going forward, it will just be a simpler, more > > reliable procedure." > > > > So it looks like OCFS backs up your superblock as long as you got it > > after March. And it is often possible to reconstruct an ASM disk header and > > backups will be made in 11.1.0.7 and beyond. And if you ever wondered > > what that KFED tool was for... > > ======== > > > > > > On 12/13/07, Finn Jorgensen wrote: > > > > > > Jeremy, > > > > > > I don't know the answer to your question but this reasoning : > > > > > > >This seems to me to be a great reason to choose OCFS2 over ASM. > > > Recovering a backup superblock is MUCH faster than recreating the entire > > > volume and restoring data from backup!!! > > > > > > is like saying you should use MySQL instead of Oracle because if you > > > lose one file you can just restore that one file and carry on. No downtime, > > > no recovery. Once human error enters the picture all bets are off. What if > > > your "someone" had decided to dd a bunch of data into the device your OCFS2 > > > filesystem is built on? Your superblock backup would have been obsolete. > > > What if the performance requirements for your database aren't satisfied by > > > OCFS2? > > > > > > Your question is valid and interesting I just don't see it as a reason > > > to choose one option over the other. > > > > > > Finn > > > > > > > > > On 12/13/07, Jeremy Schneider > > > wrote: > > > > > > > > Just wondering, does anyone know much about "superblock" backups in > > > > ASM vs OCFS2? > > > > > > > > I ran into an interesting case a month or so back where someone had > > > > accidentally tried to initialize their ASM disks with linux LVM... and > > > > written the LVM headers to the disk. It was just a few bytes at the very > > > > top of the disk - but it was enough to totally hose ASM. Which started me > > > > thinking, "if this was a filesystem then I'd have a backup superblock that I > > > > could recover". Who knows - maybe ASM has a backup of its header block - > > > > but it's all proprietary and if there's a tool that will recover an ASM > > > > header then it's probably buried at Oracle support somewhere. > > > > > > > > Looks like OCFS2 includes superblock backups since this patchset: > > > > http://lkml.org/lkml/2007/1/22/148 > > > > > > > > Not sure if ckfs will recover them but since it's open source it'd > > > > be trivial to put together a utility that would recover a superblock. > > > > > > > > This seems to me to be a great reason to choose OCFS2 over ASM. > > > > Recovering a backup superblock is MUCH faster than recreating the entire > > > > volume and restoring data from backup!!! I don't even know if you could use > > > > dd to try to backup your ASM disk headers - since it's proprietary I don't > > > > know what's in those blocks. > > > > > > > > Anyone have any thoughts on this? Is there something I'm missing > > > > here? > > > > > > > > Jeremy > > > > > > > > > > > > -- > > > > Jeremy Schneider > > > > Chicago, IL > > > > http://www.ardentperf.com/category/technical > > > > > > > > > > > > > > > > -- > > Jeremy Schneider > > Chicago, IL > > http://www.ardentperf.com/category/technical > > > > -- Jeremy Schneider Chicago, IL http://www.ardentperf.com/category/technical ------=_Part_19830_27668718.1197589081577 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline FYI, from the traffic on the ocfs-users list it sounds like the disk headers contain information that isn't captured by md_backup.  But I'm going to hold off on saying anything else until I've tried it out...


On 12/13/07, Ghassan Salem <salem.ghassan@gmail.com> wrote:
Jeremy,
asmcmd, in 11.1.0.6 already has a 'backup' command (and a restore). Is it enough? I haven't tried it yet to see what it can recover.

rgds


On Dec 13, 2007 8:03 PM, Jeremy Schneider <jeremy.schneider@ardentperf.com> wrote:
OCFS2 and ASM both support async and directIO (note 279069.1). Performance-wise, I'm pretty sure that there's not a big difference one way or the other for day-to-day operation.  There may be some minor differences when extending files or creating new ones but I don't think that they're anything to fuss over.

Since there's no major difference in performance-related capabilities, for me the choice would probably hinge on other factors.

- OCFS2 is open-source. (+1 for power-users!)
- OCFS2 already does superblock backups.  (+1 for recoverability.)
- ASM is integrated with Database Console/Grid Control.  (+1 for manageability.)
- ASM does cluster-aware volume management.  (+1 for flexibility.)

I do think that the last one is a strong point in favor of ASM.  Volume management really can simplify things.  And with ASM you get volume management and still have a single point of contact for any bugs you discover - no finger-pointing.  Also, I don't know of any open-source LVM that I'd really want to use to do any kind of redundancy - so if you need software mirroring on linux then I think that ASM is really the best solution for you.  And if you want ease-of-management then ASM is better in that area too.

Now you could get volume management and stay open-source with OCFS2 by using cLVM.  However I don't think that cLVM currently supports mirroring or parity.  IBM's EVMS also has cluster functionality and is GPL - but from the release history and mailing lists it seems like noone's maintaining it anymore.  And I think you can buy ServiceGuard for Linux and get cluster-aware volume management there too.  There might be more commercial solutions that I'm not aware of.

Not to mention GFS, which I'd also really like to spend more time learning someday.  GFS has its own feature called "pools" which also provide volume management though I think that RedHat is moving toward cLVM for cluster volume management with GFS.  You can run your Oracle RAC database on GFS (note 329530.1) but if there are any filesystem-related bugs then Oracle will tell you to call RedHat for the fix (note 423207.1).

Anyway, just some random musings...  I've always liked being able to dig into the source code of whatever's running on my systems so I'm kindof keen on OCFS2...  but it does appear that the general push is toward ASM these days.

DB+RAC+ASM/OCFS+OEL+Oracle VM...  is there anything Oracle doesn't do these days?  Next year I'm anticipating Oracle Open Office...  after all it's the final frontier...

========
Addendum: while I was writing this email there were a few responses on the ocfs-users list (I cross-posted).

Definitive answers:
OCFS: "Backup superblock has been available with ocfs2-tools 1.2.3 (Mar 2007)."
http://oss.oracle.com/projects/ocfs2/dist/documentation/ocfs2_faq.html#BACKUPSB

ASM: "In 11.1.0.7 (and beyond) we will have a backup of the disk header (the
first 4k).  Prior to that, we have been able in most circumstances to
reconstruct the disk header using KFED.  KFED will still be the tool to
restore the disk header going forward, it will just be a simpler, more
reliable procedure."

So it looks like OCFS backs up your superblock as long as you got it after March.  And it is often possible to reconstruct an ASM disk header and backups will be made in 11.1.0.7 and beyond.  And if you ever wondered what that KFED tool was for...
========


On 12/13/07, Finn Jorgensen <finn.oracledba@gmail.com> wrote:
Jeremy,
 
I don't know the answer to your question but this reasoning :
 
>This seems to me to be a great reason to choose OCFS2 over ASM.  Recovering a backup superblock is MUCH faster than recreating the entire volume and restoring data from backup!!! 
 
is like saying you should use MySQL instead of Oracle because if you lose one file you can just restore that one file and carry on. No downtime, no recovery. Once human error enters the picture all bets are off. What if your "someone" had decided to dd a bunch of data into the device your OCFS2 filesystem is built on? Your superblock backup would have been obsolete. What if the performance requirements for your database aren't satisfied by OCFS2?
 
Your question is valid and interesting I just don't see it as a reason to choose one option over the other.
 
Finn

 
On 12/13/07, Jeremy Schneider <jeremy.schneider@ardentperf.com > wrote:
Just wondering, does anyone know much about "superblock" backups in ASM vs OCFS2?

I ran into an interesting case a month or so back where someone had accidentally tried to initialize their ASM disks with linux LVM...  and written the LVM headers to the disk.  It was just a few bytes at the very top of the disk - but it was enough to totally hose ASM.  Which started me thinking, "if this was a filesystem then I'd have a backup superblock that I could recover".  Who knows - maybe ASM has a backup of its header block - but it's all proprietary and if there's a tool that will recover an ASM header then it's probably buried at Oracle support somewhere.

Looks like OCFS2 includes superblock backups since this patchset:
http://lkml.org/lkml/2007/1/22/148

Not sure if ckfs will recover them but since it's open source it'd be trivial to put together a utility that would recover a superblock.

This seems to me to be a great reason to choose OCFS2 over ASM.  Recovering a backup superblock is MUCH faster than recreating the entire volume and restoring data from backup!!!  I don't even know if you could use dd to try to backup your ASM disk headers - since it's proprietary I don't know what's in those blocks.

Anyone have any thoughts on this?  Is there something I'm missing here?

Jeremy


--
Jeremy Schneider
Chicago, IL
http://www.ardentperf.com/category/technical




--
Jeremy Schneider
Chicago, IL
http://www.ardentperf.com/category/technical




--
Jeremy Schneider
Chicago, IL
http://www.ardentperf.com/category/technical
------=_Part_19830_27668718.1197589081577-- -- http://www.freelists.org/webpage/oracle-l