Re: compress dbf backup files

From: Andrew Kerber <andrew.kerber_at_gmail.com>
Date: Mon, 1 Feb 2016 17:17:25 -0600
Message-ID: <CAJvnOJZSNEuBmD0Du66mQFL03NYviNr2=h11f-jTyNEW8bsCkA_at_mail.gmail.com>

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_at_rsiz.com> 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_at_freelists.org [mailto:
> oracle-l-bounce_at_freelists.org] *On Behalf Of *Mladen Gogala
> *Sent:* Monday, February 01, 2016 4:03 PM
> *To:* oracle-l_at_freelists.org
> *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
>
>

-- 
Andrew W. Kerber

'If at first you dont succeed, dont take up skydiving.'

--
http://www.freelists.org/webpage/oracle-l

Received on Tue Feb 02 2016 - 00:17:25 CET