Re: ASM versus Filesystems

I said

"What we do is we keep at least 1 full backup in FRA, plus all incrementals for 1 week, and keep anything over that on tape."

Should be

"What we do is we keep at least 1 full backup in FRA plus all incrementals for 1 week, and then keep anything over 7 days on tape."

On Fri, Mar 5, 2010 at 9:51 PM, Thomas Roach <troach_at_gmail.com> wrote:

> Hi,
>
> I would like to add a couple of things. You can still do your backups to an
> ASM diskgroup. In our case, we backup to FRA and then backup our FRA to
> Tape. When we restore from tape, it will restore directly to the DB from
> tape if the backup is not in FRA.
>
> What we do is we keep at least 1 full backup in FRA, plus all incrementals
> for 1 week, and keep anything over that on tape.
>
> Also, you can have disk snapshot facilities, but you need to put your
> database in backup mode (and test your backups). The reason you need to do
> this is because database operations are still happening and blocks are being
> written to disk. This is so that blocks that are touched for the first time
> during the backup window are written to the redo stream since a block can be
> corrupted while it is being backed up (Oracle is in the middle of a write
> operation and only half the new data gets written during a snapshot of that
> block). The benefit RMAN has is that it can check a block for corruption
> where snapshots are unaware of what is and isn't a valid oracle block, it
> just backs up the data.
>
> ASM is very powerful and scalable. I was able to add luns and remove luns
> (rebalancing them into ASM) without having to take my database down. Also,
> only use ASM with block devices (scsi, iscsi etc...) and not on top of a
> filesystem or NFS as the extra layers don't gain you anything. If you do use
> disk based snapshots then if you add luns/remove luns, make sure you update
> what you snapshot. If you miss just one disk, you are in deep trouble.
>
> I also bought the Oracle Press Book by Nitin Vengurlekar (spelling) which
> is a very good book.
>
> Good Luck!
>
> Tom
>
>
> On Fri, Mar 5, 2010 at 9:09 PM, Crisler, Jon <Jon.Crisler_at_usi.com> wrote:
>
>> The only bad thing about ASM is the learning curve; honestly I think it
>> was fear of the unknown that kept me away from ASM for so long. Once you
>> jump in and get comfortable with it you too will wonder why you stayed away.
>>
>> If you do backups to disk that are later picked up by a tape program, you
>> will still need a filesystem to hold the backup, or if you use some sort of
>> disk snapshot facility it may not support ASM, but those are the only
>> drawbacks I am aware of. It does require one to get more familier with
>> RMAN. Compared with OCFS2 or other clustering filesystems it seems to be
>> quite reliable, and if you are using it with RAC then you save a bundle on
>> license cost for other clustering filesystem software (like GFS, Veritas
>> etc.).
>>
>>
>>
>> Jon - aka “Capt Aubrey”
>>
>>
>>
>> *From:* oracle-l-bounce_at_freelists.org [mailto:
>> oracle-l-bounce_at_freelists.org] *On Behalf Of *patrick obrien
>> *Sent:* Friday, March 05, 2010 5:45 PM
>> *To:* Oracle L
>> *Subject:* ASM versus Filesystems
>>
>>
>>
>> Oracle Admins,
>>
>> I've been an AIX Admin for years, I'm a junior Oracle DBA and I apologize
>> if the ASM Topic has come up lately. As an AIX Admin, using filesystems
>> seems the best option for me.
>>
>> Reading up on Oracle's ASM technology, it looks like this could be a great
>> option, primarily for performance reasons. Oracle would then own more real
>> estate, so it can use its tools to better tune the entire system. Its almost
>> too good to be true.
>>
>> But what are the caveats?
>>
>> AIX Filesystems offer me control on filesystems/directory sizes, increased
>> performance and systems control. Filesystems are nice when managing backups
>> too. With the advent of the NAS/SAN, maybe I can just hand it all over to
>> Oracle.
>>
>> Any body not like ASM out there?
>>
>> Thank you,
>> Patrick.
>>
>>
>>
>>
>>
>>
>
>
>
> --
> Thomas Roach
> 813-404-6066
> troach_at_gmail.com
>

-- 
Thomas Roach
813-404-6066
troach_at_gmail.com

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