ADSM-L

Re: [ADSM-L] PA-RISC system shelf life

2010-07-28 12:37:56
Subject: Re: [ADSM-L] PA-RISC system shelf life
From: Thomas Denier <Thomas.Denier AT JEFFERSONHOSPITAL DOT ORG>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 28 Jul 2010 12:37:21 -0400
-----Wanda Prather wrote: -----

>The TDP for Oracle is just a connector/driver; it's actually Oracle
>RMAN that is selecting the data out of the data base on a backup, and
>writing it back to the DB on restore.  So if you have issues
>restoring from PA-RISC to Itanium, that is actually a question for
>Oracle rather than TSM.

I don't think we have any grounds for opening an Oracle trouble
report. If I am understanding our DBA's correctly, Oracle has
never made any statement that could be construed as a commitment
to support RMAN as an archiving mechanism or a cross-platfrom
transport mechanism.

>But the answer to your question is NO.  Don't plan on any server
>working for 20 years.
>TSM will happily store the data, because you can keep migrating it
>from one type of storage media to the next.
>But besides the question of keeping the server physically working,
>you will be reliant on the version of Oracle you have installed on
>it.
>If your restore fails (and again, it's RMAN handling the DB, not
>TSM), you aren't going to be able to get assistance from Oracle (or
>anybody else).

As the matter has been explained to me, we have no way of doing a
good job of meeting the regulatory requirements, but the legislation
involved requires a 'best effort' or words to that effect. This is
currently understood to imply an essentially unlimited obligation to
expend resources to do the least bad job we can. Our DBA's are well
aware that they cannot offer anything close to a guarantee that they
will be able to restore the Oracle database years or decades in the
future. Barring a better alternative to retaining Oracle backups,
any non-zero probability of success will apparently require us to
keep moving forward with the current proposal.

>I would also point out, if you have a requirement to keep the data
>for 20 years, it's probably not just 1 copy of the data- it's
>probably many copies over the years.  If you do need to recover
>something 10 years from now, how are you going to FIND it?  Restore
>every copy sequentially until you find what you're looking for?

We are currently planning on 25 year retention for every full backup,
every incremental backup, and every transaction log from the time
the current regulation went into effect until the time (expected to
be in the next year or two) when the application is upgraded to
provide for logging designed specifically to address the regulatory
requirements. The retained data already accounts for over a fifth of
our TSM inventory (in terms of GB, not files) and will keep growing
until the application upgrade mentioned above.

The capability the DBA's are expected to provide is recreating the
database as it existed at a particular time (a time chosen when and
if we have to respond to a complaint, not when the data is saved).
There is no indexing issue involved, but this does raise interesting
questions about the scalability of the facilities for tracking
multiple backups and multiple transaction logs.

>The way to handle legal retention of that sort of stuff is with one
>of the archiving products.  (Tivoli has one, and there are others
>that use TSM as the backstore).  They not only put the data out in a
>machine-independent form, they index it so you have a clue of finding
>it in 10 years.

Do any of these products provide the ability to see the database
contents as they were at an arbitrary point in time?

>Barring implementation of an archiving system (which is not without
>cost), you need to have your DBA's set up some sort of periodic dump
>to a non-DB dependent format (e.g. an ASCII text flat file) and
>archive that.

The arbitrary point in time requirement precludes the use of any
sort of periodic snapshots.