I wanted to write a post on one of Oracle's newest products (Well not that new).. The ZDLRA.
The ZDLRA is often referred to as "Zelda". I know the name ZDLRA does not roll off the tongue well. Zelda is a much better (and easier to say name).
The other name you will hear the ZDLRA referred to as is RA or Recover Appliance.
Recover Appliance is probably the best description of the product. One of the things that makes this product unique is the emphasis on RECOVERY.. Notice there is not a mention of backup in the name.
Here is a great starting point for information
It does a lot of it's magic by using incremental forevers --
I know what you are thinking... The incremental forever strategy has been around for a long time (since 10.2 I think). The idea is simple. You take a full backup (database copy NOT backup set), and then take incrementals from then on. You use RMAN to apply the incremental to the full, and create a new full (destroying the old full in the process). I've seen many customers (and me also) use the rolling incrementals in the online recovery area to keep a full backup online from the previous day.
This is used with a second backup strategy for longer term storage to a backup device.
The way the RA handles this differently, is that it creates "virtual fulls" for each incremental backup you take. You also tell it how far back to store virtual fulls. Using this methodology, if you do an incremental backup nightly, you can keep "virtual fulls" from each night as far back as you want.
There is no need to keep an online backup, and one in backup appliance.
Why is the RA different from most backup strategies ?
1) The use of only needing to do incremental forevers uses less I/O to read database blocks, and less backup network I/O - Using this method, the RA ONLY needs the incremental backups to keep a restore point. This saves the I/O of doing a full, and it saves the bytes going across the network.
2) RMAN keeps track of all the backups. RMAN is the backbone of the RA, and the RA contains a recovery catalog. RMAN verifies that backups are good, and you will always know if you have a good backup to restore.
3) Real time apply. You can think of the RA receiving redo log information in the same vein as a Dataguard database. Without the RA, you would backup archive logs as they are written from the redo logs. This leaves you open to data loss from your backup.. The RA reads from the current Redo log stream in the database (like dataguard) to ensure there there is almost no data loss. Nothing else does this.
4) Performance. The performance the RA is phenomenal. You can find a whitepaper here on the performance with multiple databases backing up to a single RA appliance.
This is a fantastic product to backup multiple databases and most importantly be able to recover your databases with next-to-no data loss.
The ZDLRA is often referred to as "Zelda". I know the name ZDLRA does not roll off the tongue well. Zelda is a much better (and easier to say name).
The other name you will hear the ZDLRA referred to as is RA or Recover Appliance.
Recover Appliance is probably the best description of the product. One of the things that makes this product unique is the emphasis on RECOVERY.. Notice there is not a mention of backup in the name.
Here is a great starting point for information
It does a lot of it's magic by using incremental forevers --
I know what you are thinking... The incremental forever strategy has been around for a long time (since 10.2 I think). The idea is simple. You take a full backup (database copy NOT backup set), and then take incrementals from then on. You use RMAN to apply the incremental to the full, and create a new full (destroying the old full in the process). I've seen many customers (and me also) use the rolling incrementals in the online recovery area to keep a full backup online from the previous day.
This is used with a second backup strategy for longer term storage to a backup device.
The way the RA handles this differently, is that it creates "virtual fulls" for each incremental backup you take. You also tell it how far back to store virtual fulls. Using this methodology, if you do an incremental backup nightly, you can keep "virtual fulls" from each night as far back as you want.
There is no need to keep an online backup, and one in backup appliance.
Why is the RA different from most backup strategies ?
1) The use of only needing to do incremental forevers uses less I/O to read database blocks, and less backup network I/O - Using this method, the RA ONLY needs the incremental backups to keep a restore point. This saves the I/O of doing a full, and it saves the bytes going across the network.
2) RMAN keeps track of all the backups. RMAN is the backbone of the RA, and the RA contains a recovery catalog. RMAN verifies that backups are good, and you will always know if you have a good backup to restore.
3) Real time apply. You can think of the RA receiving redo log information in the same vein as a Dataguard database. Without the RA, you would backup archive logs as they are written from the redo logs. This leaves you open to data loss from your backup.. The RA reads from the current Redo log stream in the database (like dataguard) to ensure there there is almost no data loss. Nothing else does this.
4) Performance. The performance the RA is phenomenal. You can find a whitepaper here on the performance with multiple databases backing up to a single RA appliance.
This is a fantastic product to backup multiple databases and most importantly be able to recover your databases with next-to-no data loss.
No comments:
Post a Comment