I think I over use commas sometimes. 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@xxxxxxxxx> 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@xxxxxxx> 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@xxxxxxxxxxxxx [mailto: >> oracle-l-bounce@xxxxxxxxxxxxx] *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@xxxxxxxxx > -- Thomas Roach 813-404-6066 troach@xxxxxxxxx