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
