Session 1: 10gR2 RMAN Enhancements – session 418
In this session Dave Anderson of Skillbuilders.com went over enhancements of 10gR2 RMAN. Dave’s presentation was well designed and he included a nice mix of live demos to illustrate the enhancements. Of interest here are the following:
1) v$flash_recovery_area_usage – will show you flash recovery area usage by FILE type (backup sets, image copies, archive logs, …)
2) rman> backup recovery area; – will copy the entire recovery area to tape. T
3) You can use RMAN to switch the currently operating database to an image copy. Image copies are a second type of backup option. Basically an image copy of all the datafiles is made and is then maintained (delta changes) by rman.
4) Simplified recovery THROUGH reset logs. This mean that you can now recover to points prior to a reset logs and then roll forward through the reset logs. This also means that you no longer have to do a full backup immediately after a reset logs!
5) New archive log format %r keeps track of the reset logs version. i.e. with every reset logs this is increased
6) Compression of backup sets. It used to be that the backups sets themselves would be uncompressed and you would leave it up to your tape backup to compress them as they went to tape. now that Oracle can compress the backups sets BEFORE they go to tape people are seeing dramatic drops in network utilization as the backup sets are moved to tape. Supposedly there is a negligible performance hit for asking Oracle to do the compression both during backups and restores
7) Encrypted backups. This was mentioned but not gone into any sort of detail. Something worthy of more research. Briefly this encryption can be transparent utilizing the Oracle wallet or an explicit password can be used.
Block Change Tracking. Introduced to dramatically improve the performance of backups by tracking and then only backing up blocks that have changed this technology is intended to make those HUGE databases now ‘backupable’. This utilizes a separate ‘Change Tracking File’ that acts very much like a bitmap index marking blocks as changed or not since the last backup. THere is an impact on normal database operations and so this must be weighed against the improvement in backups. The resulting backup data is predicted to be 1/30,000 of the original database size but of course mileage will vary.
9) Incrementally updated backup sets and image copies. RMAN can now maintai level 0 backup sets and image copies by applying changes directly to the originals. The result is a reduced recovery time as the existing backup set or image copy is up to date as of the last incremental backup. The downside is that if this is ALL that you are doing you’ll be hard pressed to be back beyond the last incremental backup . Logic seems to dictate that this plus a more traditional level 0’s + archive logs would be prudent.
10) VALIDATE. RMAN now has a VALIDATE command that can be used to validate the integrity of a given backup set or image copy.
11) MINIMIZE LOAD parameter can now be specified to indicate to RMAN that it should not be overly gready with system resources during a backup or restore
12) PREVIEW can be used to simulate a recovery. RMAN will list all files that will be used to do a recovery but not actually DO the recovery.
13) TEMPFILES are now recreated during recovery.
14) ORACLE BACKUP -Oracle just announced ‘Oracle Backup’ their very own Oracle very own MML. I’ll have to dig into that and see what it is all about but one of the interesting things is that you can now use RMAN to backup not only the database but also the Oracle code tree via ORACLE_BACKUP?
All in all a very informative session that once again indicates that the time is right to give RMAN a spin !!!
www.skillbuilders.com contains an updated presentation plus all of the text files used during the presentation. I think THIS is the correct URL:
http://www.skillbuilders.com/News-V2/news.cfm
Session 2: Cluster Architecture for Large Scale Server Consolidation – session 221
This one was one of the few stinkers that I attended at COLLABORATE ‘06. Basically Polyserv has been working with IBM to create what I would term a ‘blade center application management’ tool that lets you specify for one or more applications primary and failover blades. While not a 24×7 uptime solution it is useful to do this. If it works as smoothly as advertised it might be of interest to some. Basically it felt a lot like a sales pitch.
The presenter then went off on a tangent about what he termed Microbenchmarking but I took it as nothing more than storage benchmarking.
Interesting throwaways:
yotta yotta – a solution for long distance storage replication (http://www.yottayotta.com/). The presenter worked to build a 3 node implementation with distances in the 2,500 km range utilizing this technology for underlying storage.
AMD – once again I heard about how AMD64 serves rock performance wise.
Orion – he suggested that we get familiar with oracles Orion benchmarking tool and have vendors supply Orion performance numbers. Nothing like seeing how the storage will WORK before you buy.
hammerora – I heard about this one but didn’t look into it. Basically another oracle based storage benchmarking tool.
Session 3: Integration of RMAN and RAC – session 212
Another presentation by Ashok Singh of Fastenal (I attended an earlier session about iAS clustering) I appreciate the direct and down home style and content. There wasn’t a whole lot of new information in this but as usual there is always SOMETHING to be learned.
1) HA recommends using a catalog but for the actual backup you could use the control file and then resync to the catalog. This makes the catalog itself not a single point of failure – i.e. backups will continue to work even if the database holding the catalog should fail. Good idea!!!
2) I got the impression that there may be a problem in a RAC environment with having to use the same node to recover as did the backup. I’ll have to dig into this as it doesn’t sound quite right – maybe I misheard.
3) RMAN has a checksyntax command that can be used to validate the syntax of an RMAN script without executing it.
4) To duplicate a RAC database you can use RMAN to back it up and then restore to another database (single instance) and then extend this to a full cluster database. In the future we should see functionality to clone a RAC database to another RAC database directly…
Wrap UP
And with that it was a quick trip to the airport and after much waiting I finally arrived home safe and sound 9 and a half hours later. I would have liked to hang around for the ‘debates’ (One of the debates was going to be Linux VS Commercial Unix) that ran from noon to 1 but of course the airlines suggest you give yourself 2 hours prior to boarding so who am I to argue??!!
A very enjoyable conference and one I’d recommend to anyone in the Oracle realm. Next year it’s being held in Vegas!
