Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> RE: RMAN-NetBackup without an RMAN Catalog

RE: RMAN-NetBackup without an RMAN Catalog

From: Mark W. Farnham <>
Date: Thu, 14 Oct 2004 19:06:06 -0400
Message-ID: <>

And all excellent food for thought, so I didn't snip a bit of it.

Back to one component of the issue, about which I think the OP was concerned and about which Oracle VLDB raised concerns in the early 90's:

I made my tablespace read only, dammit, and I want the data back. Sure it is my problem to figure out what to do with it, and maybe no apps will still run on it and maybe the apps that would have run on it only work on hardware that I'll have to break into the computer museum to use, but I want the doggone data back.

So they didn't get a general solution into 7.1, 8.0, 8.1, 9.whatever. But transportable tablespaces should do it. I'm not sure whether RMAN handles that (yet). What is needed is that from now on (10g and forward, right?) an emulation mode for tablespaces marked read only should be provided, and it would be a major big deal to deprecate support for an old release (meaning from 10g forward, right?) So all the sparcs little-endian computers bite the dust. No problem, load that puppy up on your big-endian machine and read it transportable.

Load an old O version? I'm doubting that.

Read the contents of an old read only tablespace via the transportable tablespace feature? Yes, that *should* work. Of course you're going to have to make sure that you copy the media image forward as technology rolls forward. Real soon now old CD formats will probably get dropped and the bits are rusting off your old tapes even as I type.

I'm not sure whether Oracle has stated a policy on this. I would encourage them to make it part of the plan from 10g on. I've mentally kissed my export file from a V4 database goodbye. No more ufi! I suppose I might have a 5 and 1/4 inch floppy drive around here somewhere, but I doubt I can make it work. Wait a minute - over in the corner there, behind the stack of V6.0 manuals with hand written corrections dictated over the phone by Jonathan Klein and Bill Bridge..... Nope. I'm resisting the urge to even try. If I plug that thing in I'll probably short out the UPS.



-----Original Message-----
[]On Behalf Of Jared Still Sent: Thursday, October 14, 2004 5:52 PM To:
Cc: Mercadante, Thomas F; Subject: Re: RMAN-NetBackup without an RMAN Catalog

On Thu, 14 Oct 2004 13:28:13 -0700, Joel Garry <> wrote:
> It boils down to Oracle not wanting to spend the bucks to allow backward
> compatibility, and no one yet seeing the value of designing software for
> the ages. Even if nothing else will grant the latter, restoration
> software must deal with aging. I think RMAN should be able to deal with
> multiple versions, restoring the O install if it has to. Well, maybe
> not without a catalog... :-)

This problem is bigger than Oracle.

Say you can restore your 5 year old data?

Do you have an app that can work with it?

Archived copies of the application?

A place to run it?

Documentation that tells you how to do so?

I recently ran into a scenario like this where the financial wizards needed old finance data to make it through an audit.

The data was/is in Great Plains. A version that is about 6 or 7 years old.

Fortunately, we still have a CD of the original version.

A local consultant had a copy of the old Btrieve database binaries, and the expertise to set it up. It took quite a while to get this all figured out and setup.
Our consultant ( the second one we called, not the first) knew her stuff, sorted
it all out and saved the day.

In the meantime, the finance wizards were forced to go back to the paper trail,
which some predecessor had thoughtfully created during the migration to SAP, and prepared their data from these reports, because there was a lot more involved
to setting up an old version of GP than copying some files around.

Food for thought.

Jared Still
Certifiable Oracle DBA and Part Time Perl Evangelist

Received on Thu Oct 14 2004 - 18:02:18 CDT

Original text of this message