We are currently implementing tdpo/lanfree backups for our large databases.
I'm not the dba, but I'm working
real close with him. Here is our understanding and what we have found.
> Their concerns:
>
> 1) RMAN doesn't deal with non-transactional DB data loads well.
>
> (i.e. data loaded not through the usual INSERT/UPDATE
> methods, but done via sqlldr. This doesn't generate redo logs.)
>
> True or false?
>
RMAN deals with changed blocks. In Oracle 9 it had to scan the
entire db to fine them. In Oracle 10, it can use a block change
table to determine changed blocks. Works very well and provides
very fast incremental backups.
> 2) RMAN requires a recovery database be created to do recoveries to
> (instead of recovering to original database/tablespaces in-place).
>
> True or false? I thought RMAN didn't need an intermediate temp
> database and could restore directly 'in-place'.
>
RMAN can restore directly to the database, or some other place. It can
restore a table, file, tablespace, or even a individual corrupt block,
and, roll it forward.
It's own metadata about the backup can be stored in the control files,
or, in another Oracle db. We have setup a Oracle db with a standby db
for DR to contain this data.
> 3) Will RMAN guarantee a good point-in-time view of DB data?
>
Yes
> 4) Same as #3 above, but what if the DB is currently processing
> a large series of INSERTs or UPDATEs or sqlldr run, will RMAN
> only send data that was present at the moment of backup start?
>
The db will be consistant, but I'm not sure where it will be. Remember,
you also have archive logs and redo logs to roll through, which rman will
also handle.
> 5) Does RMAN/TDPO use scale to really large DB setups? Say, tens
> or hundreds of terabytes? Or even sub-10 TB?
>
> Anybody using TDPO well with terabytes of Oracle data? (I
> think they're hoping for assurances that it really does work
> in the real world at that scale.)
>
We have db's up to 8-9tb. Initial testing has shown this throughput.
We are using 3592-E05 drives in a 3584 lib.
Using 1 drive on one path => 100mb/s
Using 2 drives on one path => 140mb/s
Using 2 drives on 2 paths => 160-180mb/s
Have not tested anything past 2 drives on 2 paths - we don't need it.
We tried multiple RMAN threads/openfiles per channel. I think he
settled on 20 concurrent files per channel (channel => drive).
I'm disappointed with the performance. We seem to be able to drive
the tape drive right at their native performance. I was expecting
to be able to drive them faster with drive compression. In our
tests we have over 2tb of data onto a 500gb tape - 4x compression.
I would have thought we could have through put of
at least 150-180 to one drive.
> 6) How does Oracle RMAN know what rows to send for an
> incremental backup? Does Oracle maintain a bitmap of some kind
> or time-based logging of changed blocks or something? Any
> pointers to whitepapers or information on how it works behind
> the scenes?
>
Depends on how you set it up. If you use the change block table
then yes, it will not have to scan the entire db for changed blocks.
It is not time based, but level based . . from full, incremential,
differential.
If you use RMAN to backup to local disk and merge
incremental backups into the full, you can perform tsm
style incremental-forever backups. The backups to tape
would come from the rman full and increnemtanl backup in
the rman staging area. Very cool.
> They would prefer to utilize Veritas DB Edition (DBED)
> checkpoint feature which is where a script runs to put all tablespaces
> in backup mode, brings DB-based filesystems to a consistent state,
> generate a checkpoint (snapshot-like) of the filesystem, then brings all
> tablespaces back to online mode. The TSM BA client then mounts the most
> recent checkpoint R/O then backs it up at the file level.
For years we have used EMC BCV volumes for this purpose. We're moving
to a new method.
We will be implementing a RMAN Merge option, where we . . .
- run a full oracle backup to local disk (yup, a +full size copy on disk)
- perform daily incrementals into this rman area.
- daily incrementals will be merged into the full, but be done
on a delay, so the full on disk will be several days behind production.
- perform a weekly full backup to tdpo/tsm/lanfree of the rman area
on disk
- perform daily rman incremental to tdpo/tsm/lanfree of the rman area
basically, we are moving to all increnemtal backups off the production
Oracle db, and weekly full with daily incrementals from the rman area
to tsm/tdpo/lanfree.
This is all explained in the RMAN manual.
>
> The problem with the above approach is this essentially results
> in what amounts to a full backup every single time it kicks off. That's
> just not practical in terms of tape cost as well as the length of
> backups.
That's why we're changing.
>
> I see TDPO as the only practical choice for much faster and more
> frequent backups (and restores) and is guaranteed for consistent
> point-in-time views of DB data. The BA client was also not meant to back
> up databases (though it *could* do so if properly quiescied).
>
> My issue? I don't have enough meaty information yet to put
> concerns to rest, and I'd really like to make use of TDPO after paying
> out $16,000. Any info would be much welcome.
>
> Thanks,
>
> -Dan
-----------------------------------------
The information contained in this message is intended only for the
personal and confidential use of the recipient(s) named above. If
the reader of this message is not the intended recipient or an
agent responsible for delivering it to the intended recipient, you
are hereby notified that you have received this document in error
and that any review, dissemination, distribution, or copying of
this message is strictly prohibited. If you have received this
communication in error, please notify us immediately, and delete
the original message.
|
