Ditto on Mark's comments. Though I have used 9 track tapes, I did not run
his particular problem. I recommend two copies of the data files, and an
export of them also. Just to be safe.
On Mon, Feb 1, 2016 at 5:08 PM, Mark W. Farnham <mwf@xxxxxxxx> wrote:
A few things:
1) Mladen’s questions are directly on point.
2) “They are the only copies of the existing readonly dbffiles…”
a. Farnham’s Law: “Don’t trust your career to a single piece of
spinning rust or ribbon rust.” (Ribbon rust is a tape. This should probably
be updated to “single piece of media” but spinning rust and ribbon rust are
helpful images to remember how fragile your career might be if you violate
Farnham’s Law.)
b. I hope you mount these for a few minutes and read something from
them every time you patch anything in the entire stack. Otherwise they
might become the only copies of these files that run on a machine/operating
system you no longer have in close enough detail. (Did I ever tell you the
one about 9-track tapes and the changing hardware specifications over time
of maximum drift adjustments where the new “better” tape drive simply could
not be adjusted to read **some** of the tapes that had been written on
the “gone” drives with a larger than average drift. Sigh. It wasn’t funny
at the time either….
3) If space and compression is an issue then I suggest that in
addition to possibly reloading and compressing as per the methods Seth
mentioned earlier in the thread you use a reasonable protocol for
tablespaces that have become read only whether or not you leave them
unmounted most of the time. Among the features of such a protocol:
a. If the tablespace to become unmounted has more than trivial free
space, copy everything in the tablespace into something just big enough as
compressed as you plan to keep it. Partition exchange methods might be
helpful.
b. Consider using direct load so you don’t have any delayed cleanout
issues reading things much later.
c. Consider making the destination a less expensive “class” of
storage than your active database files is on.
d. Make another copy somewhere else that will survive independently of
the campus this file is on.
There is probably more.
mwf
*From:* oracle-l-bounce@xxxxxxxxxxxxx [mailto:
oracle-l-bounce@xxxxxxxxxxxxx] *On Behalf Of *Mladen Gogala
*Sent:* Monday, February 01, 2016 4:03 PM
*To:* oracle-l@xxxxxxxxxxxxx
*Subject:* Re: compress dbf backup files
On 02/01/2016 12:09 PM, Zelli, Brian wrote:
I have copies of dbf files sitting on a server. Management doesn’t want
me deleting them. So to garnish space, can I compress these? They are
only copies of the existing readonly dbffiles…
Brian
This email message may contain legally privileged and/or confidential
information. If you are not the intended recipient(s), or the employee or
agent responsible for the delivery of this message to the intended
recipient(s), you are hereby notified that any disclosure, copying,
distribution, or use of this email message is prohibited. If you have
received this message in error, please notify the sender immediately by
e-mail and delete this email message from your computer. Thank you.
Hi Brian,
How old are those files? What does your management expect from having
them? What is your company's backup strategy? Do you have an enterprise
backup suite? How frequently do you take backup and where do you store it?
How do you take backups?
Regards
--
Mladen Gogala
Oracle DBA
Tel: (347) 321-1217
