RMAN Testing brainstorm

[jodie]

Hi everyone!
It's been a while since I posted... but I have a "brainstorming" question.

I'm at a new company, that doesn't use RMAN right now. We are trying to "prove" what a benefit it is. Our main test is to show how much quicker a restore will be using incrementals instead of applying days worth of Archive Logs.

Our first plan was to restore a backup of an existing database to a new server, do an Incremental 0, then apply it's logs for a day or 2, then do an Incremental 1. Then test a restore using the incrementals. As you can probably guess, this didn't work because we had to open with "reset Logs" and then Incremental 0 from before was no longer valid.

My next thought was to do an rman backup of an existing production database, let it run for a day, then do an incremental 1. Then restore to a different server. The problem is, the archive logs are cpio'd and moved off throughout the day, so I can't get them saved off with rman without changing current production procedures. So that won't work either.

So, any ideas on how to test this? I can get backups of production, etc. But I can't USE current production. Make sense?

Thanks for any insight. I'm a bit stumped right now.

Thanks!
Jodie

[marist89]

Yuck. Why have cpio manage the archivelogs? (I already know the answer, because that's the way it's setup.) Mixing technologies in this case, IMHO, is a big no-no because one doesn't communicate with the other and you can't be 100% sure everything is backed up.

Anyway, I'd have rman manage the archivelogs by backing and removing them once they've been backed up according to your cpio logic.

If you can't twist arms enough to do that, I'd restore my db and simulate the traffic against the dev db so that it generates about the same number of archived redo logs and do my testing on that.

Don't be surprised if your level 1 backups aren't significantly faster (on 9i) as all the blocks have to be inspected to see if they need to be backed up (different in 10 with block change tracking). The restores might be smokin (or not) depending on the number of hot blocks you have.

[jodie]

Yuck. Why have cpio manage the archivelogs? (I already know the answer, because that's the way it's setup.) Mixing technologies in this case, IMHO, is a big no-no because one doesn't communicate with the other and you can't be 100% sure everything is backed up.

Anyway, I'd have rman manage the archivelogs by backing and removing them once they've been backed up according to your cpio logic.

If you can't twist arms enough to do that, I'd restore my db and simulate the traffic against the dev db so that it generates about the same number of archived redo logs and do my testing on that.

Don't be surprised if your level 1 backups aren't significantly faster (on 9i) as all the blocks have to be inspected to see if they need to be backed up (different in 10 with block change tracking). The restores might be smokin (or not) depending on the number of hot blocks you have.

Yeah, this is why we are trying to "prove" RMAN. If you've seen many of my previous posts... I'm a big fan of RMAN... I just have to get them to see the benefits.
We aren't allowed to touch production, so backing them up with RMAN after the cpio is out of the question.

We can't simulate real traffic, since we are testing on a dummy box. There's no application attached. We can't use real test/dev since developers are on there. I guess we can just generate dummy DML to simulate 500 log switches (which is about how many we see in a day). I'd just need make sure we simulate roughly the same number of blocks changing. I need to find out more about the app and if it's got a bunch of hot blocks or if it's new data.

Thanks for your input. Any other insight would also be welcome!

Thanks!
Jodie

[jodie]

Don't be surprised if your level 1 backups aren't significantly faster (on 9i) as all the blocks have to be inspected to see if they need to be backed up (different in 10 with block change tracking). The restores might be smokin (or not) depending on the number of hot blocks you have.

Oh forgot to comment on this...

Yeah, I've already warned them that Incremental 1's aren't going to be faster (I've actually seen them slower). Our main objective is to show how much time can be saved by using Incrementals instead of applying 5 days of archive logs.

[marist89]

Oh forgot to comment on this...

Yeah, I've already warned them that Incremental 1's aren't going to be faster (I've actually seen them slower). Our main objective is to show how much time can be saved by using Incrementals instead of applying 5 days of archive logs.

Yeah, you're still reading the same number of blocks (9i), just writing less (in theory). If you have really slow output devices (tape) incrementals will probably be faster as the limiting factor is how fast you can pump data to tape. Less data to move = faster backups.

[Bore]

Could try the following:
On the prod:
make level 0
let it run for a while
make level 1
let it run for a while
shutdown the prod immediate ( if possible)
Copy all the data files, control files, redo logs, archive logs to the test machine and the backup sets (at the same locations as in the prod)
Up the instamce and open the db at the test ( no resetlog required)
Start the RMAN and do whatever you want

[jodie]

Could try the following:
On the prod:
make level 0
let it run for a while
make level 1
let it run for a while
shutdown the prod immediate ( if possible)
Copy all the data files, control files, redo logs, archive logs to the test machine and the backup sets (at the same locations as in the prod)
Up the instamce and open the db at the test ( no resetlog required)
Start the RMAN and do whatever you want

Bore - I don't see how this helps.. I still have the problem that I can't get my archive logs backed up with RMAN so the level 1 won't work. If I misunderstand, let me know.

Thanks!
Jodie

[simply_dba]

The restores might be smokin (or not) depending on the number of hot blocks you have.

Will you kindly elucidate this

[marist89]

Will you kindly elucidate this

It depends on how frequently the same block changes. For example, if you have a system that inserts a row every second but never deletes rows, you will continually be adding blocks to the "need to get backed up" list. Here, your backup sets will be relatively large and you may have to go through several level 1's (depending on how you actually do the backup) to do a restore to current.

A system with a small number of hot blocks, on the other hand, will backup the current state of those hot blocks. The "need to get backed up" list has that small number of blocks and those blocks are backed up in every level 1 (since they're always changing). The restore will only have to go to the level 0 and then to the level 1 to find the current state and apply archivelogs. This will be faster.

[Bore]

maybe I misunderstood something, but the idea is to test how faster the restore with incremental is, compared to the restore of level 0 + arch log application, so... I do not see the problem
All you need is
1) level 0 backup
2) Level 1 backup
3) All the archive logs, located where they should be - in the corresponding directory or in a backup set
4) A controlfile where all this is described

So if you do all that with your primary database ( the level 0 backup, the level one backup and generation of archived logs)
You could simply shut the database down, copy all the files mentioned above to the test machine UNDER AN IDENTICAL DIRECTORY STRUCTURE and try restore level 0 and recover
Then restoer level 0 and level 1 and recover

BTW I really do not see why you need resetlogs here