Sequences : Should they be Gap Free ?

Frequently through your career as a DBA you are either asked "Why is there a gap in my Number series ?" OR are _told_ "the business-requirement/user/auditor CANNOT accept missing numbers". Then you have to keep your cool as you try to explain how Sequences work in Oracle. Sequences are designed to generate Unique Numbers, by default they do _NOT_ guarantee consecutive (ie "Gap Free") numbers. Some programmers try to beat sequences by using their own number generators, based on a single row in a table or the max() of a particular column in a table and causing either contention or repeated physical/FTS reads.
I was just reading Tom Kyte's responses at http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:4343369880986 -- "There is a fact about sequences -- an UNDENIABLE, UNESCAPABLE fact -- they are not gap free, will never be gap free, they will have gaps!".

Using Partial Recoveries to test Backups

When testing new backup technologies on "fairly large" databases [see my previous post http://hemantoracledba.blogspot.com/2007/01/deleting-data-doesnt-reduce-size-of.html for a definition of "fairly large"] sometimes you can contrive to do Partial Recoveries to test Restoration and Recovery of Backups. This has become necessary, for instance, in one case where the vendors' [multiple vendors involved] Snap* based backup method while seemingly restoring the whole database wouldn't be seen as consistent datafiles by Oracle whenever I issued RECOVER commands. While the SnapShot and SnapRestore wasn't taking very long, when I wanted to "prove" the Oracle BEGIN/END BACKUP scripts and the RECOVER scripts that I was using, I had to use "cp" as a Restoration method. This allowed me to prove that when I used "cp" to backup and restore the datafiles, there were no errors in the RECOVER command. Unfortunately, the database being "fairly large", I would have been spending far many more hours in the "cp" then in the actual BEGIN/END BACKUP and RECOVER commands !. So I simulated transactions and did a "cp" based restoration of only the SYSTEM and UNDO tablespaces. That way I could "copy" the "whole" database much faster.
Essentially what I did was
a) BEGIN BACKUP for all tablespaces
b) copy out SYSTEM and UNDOTBS
c) END BACKUP
d) Restore SYSTEM and UNDOTBS to the alternate location
e) CREATE CONTROLFILE with only SYSTEM and UNDOTBS
f) RECOVER only SYSTEM and UNDOTBS

So I was using a TSPITR method to test backup and restoration.

I could prove that when the vendors technologies were being used, I was getting inconsistent database files [database files seemed to be of a point-in-time _before_ the BEGIN BACKUP -- ie, the Snap* mechanism was copying the files __before__ the BEGIN BACKUP had been run]. This WAS resolved by the vendors finally.

Deleting data doesn't reduce the size of the backup

You sometimes may have a fairly large ["fairy large" is relative to a) the average size of database in your organisation b) the disk storage and I/O capacity it is running on c) the backup throughput and tape sizes] database that is taking many hours to backup. You are doing full image backups. You or your users may be tempted to delete data to "reduce the size of the backup" and/or to "reduce the time it takes to backup" and/or to "reduce the duration that datafiles are in backup mode".
Unfortunately, merely deleting rows [even 10% or 99%] in table[s] doesn't really reduce the size or duration of most image backups. The delete operation only adds to the total amount of undo and a very large increase in redo and archivelog generation for which you may have to scramble for disk space.
An image backup [whether by "cp" or "cpio" or "tar"] of the Datafiles will still see the Datafiles as having the same size because the delete doesn't shrink the datafiles.
An RMAN backup will still have to backup as many datablocks as before the delete. This is true _even_ if you are successful in deleting rows in such a manner that some or many blocks are 100% empty. Once a datablock has got formatted it will always be backed-up by RMAN, whether there are rows or no rows in it subsequently.