tag:blogger.com,1999:blog-6585541677364366622.post3484644661178541613..comments2023-10-25T07:28:49.046-07:00Comments on Oracle Tips and Tricks: Exadata Backup and Recovery-1Andy Blackhttp://www.blogger.com/profile/13735674972296527233noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-6585541677364366622.post-8365443880390689732011-05-24T12:32:38.224-07:002011-05-24T12:32:38.224-07:00This is a great question...like I said, it was my ...This is a great question...like I said, it was my preference to do it that way. The problem comes down to performance needs for the RTO and the fact that we're required to have 7 days on disk.<br /><br />In order to have 7 days on disk if we were doing merged incrementals we'd have to have 20TB, plus ~1-2TB/day of incrementals (non-cumulative), so say 30TB. We have 4 environments, so that would be 120TB...and we only have a little less than 96TB of usable ZFS storage. But, we could probably get past that issue by using ZFS compression.<br /><br />In my latest post, I showed some of the performance results from testing. If we used ZFS compression instead of rman compression, ignoring overhead from ZFS decompression, we'd be limited by the single head throughput of the 7420 of ~1.21GB/s. So, since we have the "7 days on ZFS" requirement, we'd have to restore the full and then merge (worst case scenario) 6 incrementals to it. <br /><br />With a merged incremental full (20TB) and then 6 non-cumulative incrementals (~10TB):<br />30TB=30,720GB, at 1.21GB/s=7.05 hrs, plus 4 hrs for archivelog apply...so we wouldn't be able to hit the RTO.<br /><br />With compressed 20TB Lev 0 and 6TB Lev 1 cumulative:<br />26TB=26,624GB, at 3.11GB/s=2.38 hrs (due to decompression happening after it passes the 1.21GB/s 7420 head bottleneck. There was only ~754MB/s transferring at that point from ZFS over IB to the compute nodes. When it got to the compute nodes it decompressed at 3187MB/s. RMAN compression made it actually faster.)<br /><br />If we didn't have the "7 days on ZFS" requirement, it would take 4.7 hrs to move the 20TB uncompressed image backup to Exadata, which wouldn't give us enough time to apply the archivelogs to meet the 8 hr RTO.<br /><br />I really wanted merged incrementals to work...I just couldn't get the numbers to match our requirements. I played with the idea of doing multiple incrementals per day to reduce the number of archivelogs we'd need to apply, but then we'd be copying more from ZFS. We'd be applying fewer archivelogs, but I couldn't get the savings in redo apply time to make up for the cost in zfs transfer time. <br /><br />If we had 2 heads on the ZFS, I bet this would have worked in about 3.5 hrs which would have let us hit the RTO. But that's not going to happen for about 3 years, and by then the db will have grown.<br /><br />Sorry for the delayed response to your question, I've been very busy with testing the tape performance numbers.Andy Blackhttps://www.blogger.com/profile/13735674972296527233noreply@blogger.comtag:blogger.com,1999:blog-6585541677364366622.post-15202787819584841142011-04-26T06:26:23.861-07:002011-04-26T06:26:23.861-07:00what's wrong with using incremental merge stra...what's wrong with using incremental merge strategy on zfs and than just doing the restore back to the storage cells when you need it.<br /><br />The "switch" trick is only temporary anyone. I don't imagine people are going to run with their data files living in the FRA diskgroup for very long, so why not get the benefits of incremental merge and plan on the RTO including the restore from ZFS back to the cells.Norah Millerhttps://www.blogger.com/profile/04471385520212590549noreply@blogger.com