Responding to some of the responses :
- RMAN is a recovery tool. I would expect to use RMAN to recover my database
from a valid backup. Let's say your data was flat files and backed-up using
"tar" or "cpio", 5 / 10 / 15 years ago. Can you restore it ? YES.
Let's say your data was MS Word DOC or XLS Files of versions 5 years ago.
Can you open those files with newer versions ? Most probably Yes.
What's the catch with Oracle RMAN Versions then ? Why does Oracle
have to make life difficult.
- Legal / Audit requirements can specify that I must be able to restore
my data
as of 5 or 11 years ago. Now, a well designed database may either
- Keep ALL data available in the current database -- such that I do not
need to
restore data {and without impacting performance}, provided that
total volume growth isn't very large
OR
- Implement Archive and Purge routines
A poorly implemented database might just have the Application Administrator
deleting data [in the course of 5 years, the Application might pass through
multiple hands with successive owners not understanding the initial Legal/Audit
requirements about data retention OR even the first Administrator might have
not done his homework properly] {Substitute Developer / Designer / Data
Owner /
Dept Manager / IT Manager for "Application Administrator"}
When the application was first implemented did the designers consider
Retention/Archive/Purge/Remerge requirements ? Supposing that initially
it was designed for 1 years data. Two years later, on a stable system,
Legal requirements now state that this data must be retained for 5 or 11 years.
Well, we've already lost the first year's data. And we have a stable system
which was NOT designed to retain 11 years data online and also doesn't
have Archive/Purge/Remerge routines.
Tom's "properly designed database that can produce reports
of what the database looked like 5 years ago " isn't always What You Get.
Where do you go from here ? Ensure that you have monthly / quarterly / yearly
backups which are, from this day forward, retained for 11 years.
- With Archive and Purge routines, the data *might* be transferred to
flat files and
burnt on CDs, it *might* be copied out as Oracle Exports and then backed up
to tape.
Either way, there must be a routine to restore and "re-merge" the
data. How many
systems have actually tested and implemented "restore and re-merge" well ?
- The argument that when you upgrade a database you delete the Oracle_Home
isnt' convincing. If your Legal requirements say that you must be able to
restore
data, well you better ensure that you have that same version of the RDBMS and
Application as well. Why do you think we backup the Root, /etc/passwd, /usr,
ORACLE_BASE and Applications Software as well with the Database in
Daily/Weekly/Monthly/Yearly backups ? Similarly with documentation on
the software. [I do have a couple of 7.0 CDs and some 7.3.4 ORACLE_HOMEs
on disk, other than those on tape]
Because we know that we will need the same versions back.
However, HW compatibility is the problem. Whether newer HW supports
restoring [from tape] and reading [opening the database and running the
application]
the data is a concern. Also, whether the tapes are readable.
So some companies do invest in "refreshing" tapes . My organisation had begun
a project to migrate data from older tapes to DLT-IVs a year ago [that we had
hardware issues converting the data is an "add-on" story !]
- Who says that I must frequently be upgrading my RDBMS version ? What
significant benefit do I get trying to upgrade a mature database with a
well-entrenched
application ? You may call this heresy but frequently upgrading RDBMS versions
isn't really justified. How frequently do I change to a new home with more
rooms
and better wallpaper ?
Yes, newer applications go on new RDBMS versions.
Hemant K Chitale
http://web.singnet.com.sg/~hkchital
--
http://www.freelists.org/webpage/oracle-l
Received on Fri Oct 15 2004 - 10:06:50 CDT
