Return-Path: X-Original-To: oracle-l@orafaq.com Delivered-To: oracle-l@orafaq.com Received: from puck1183.startdedicated.com (localhost [127.0.0.1]) by puck1183.startdedicated.com (Postfix) with ESMTP id 8BC3C19605A1 for ; Tue, 2 Feb 2016 00:18:49 +0100 (CET) Received: from turing.freelists.org (freelists-180.iquest.net [206.53.239.180]) by puck1183.startdedicated.com (Postfix) with ESMTPS for ; Tue, 2 Feb 2016 00:18:49 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 5B4E931654; Mon, 1 Feb 2016 18:18:48 -0500 (EST) X-Virus-Scanned: Debian amavisd-new at turing.freelists.org Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x5rbiZMjLkKZ; Mon, 1 Feb 2016 18:18:48 -0500 (EST) Received: from turing.freelists.org (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 909F6315C9; Mon, 1 Feb 2016 18:18:07 -0500 (EST) Received: with ECARTIS (v1.0.0; list oracle-l); Mon, 01 Feb 2016 18:17:26 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 87CB73158F for ; Mon, 1 Feb 2016 18:17:26 -0500 (EST) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ANYFUxSJPoVN for ; Mon, 1 Feb 2016 18:17:26 -0500 (EST) Received: from mail-qg0-f46.google.com (mail-qg0-f46.google.com [209.85.192.46]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTPS id 4DAC93139B for ; Mon, 1 Feb 2016 18:17:26 -0500 (EST) Received: by mail-qg0-f46.google.com with SMTP id e32so134493057qgf.3 for ; Mon, 01 Feb 2016 15:17:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=fOzY3TZ8HlLmGC1FPpY+9lLNwigphcQ807JZMcbkk88=; b=OtX0ZEDl37Rr11xpVBVme+INee32sTUa89VotE+pluIoK40IGZfWPdRe9YZcBc4pwI jfBxfNI6qlsDiSrWXKV9R8vhEcpW5YePjzITStWQpsQL7hLeQMoyrvCFQYnz8rOTTwwh Ka3kNFLiXHdz0JABfOqR6ZRz13M+VVEH/cizL+6Xj8QWus3puNmvUK7NYEwrZ2VuiwEk 5mXKQu9UTMkbREn4b/sFzK2TUQYLtW54FFbqq913+M+ACZ2XSrobBz/A1YY8Z6WBzTJo BDCwcOepuB55nebDJRxKCfyia3xk4F/dGnFdEAhFXEiTRDvvzN6g6o2zJ4plCVEWrZMV itOA== X-Gm-Message-State: AG10YORrDclQaGhdPe++NKuFq853Os+JAERGZv/Ni5Ak/1ipx0aw2gI8mPINQZM0JE4u+hiTo7m0ytXp3DO1PQ== MIME-Version: 1.0 X-Received: by 10.140.95.111 with SMTP id h102mr31671299qge.2.1454368645774; Mon, 01 Feb 2016 15:17:25 -0800 (PST) Received: by 10.55.19.14 with HTTP; Mon, 1 Feb 2016 15:17:25 -0800 (PST) In-Reply-To: <024101d15d45$874333f0$95c99bd0$@rsiz.com> References: <56AFC7F8.7090700@gmail.com> <024101d15d45$874333f0$95c99bd0$@rsiz.com> Date: Mon, 1 Feb 2016 17:17:25 -0600 Message-ID: Subject: Re: compress dbf backup files From: Andrew Kerber To: "Mark W. Farnham" Cc: Mladen Gogala , =?UTF-8?B?T1JBQ0xFLUzvu7/vu7/vu7/vu78=?= Content-Type: multipart/alternative; boundary=001a11c16152810462052abd9640 X-archive-position: 63251 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-to: oracle-l-bounce@freelists.org X-original-sender: andrew.kerber@gmail.com Precedence: normal Reply-To: andrew.kerber@gmail.com List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: oracle-l X-List-ID: oracle-l List-subscribe: List-owner: List-post: List-archive: X-list: oracle-l --001a11c16152810462052abd9640 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 wrote: > A few things: > > > > 1) Mladen=E2=80=99s questions are directly on point. > > 2) =E2=80=9CThey are the only copies of the existing readonly dbffiles= =E2=80=A6=E2=80=9D > > a. Farnham=E2=80=99s Law: =E2=80=9CDon=E2=80=99t trust your career to= a single piece of > spinning rust or ribbon rust.=E2=80=9D (Ribbon rust is a tape. This shoul= d probably > be updated to =E2=80=9Csingle piece of media=E2=80=9D but spinning rust a= nd ribbon rust are > helpful images to remember how fragile your career might be if you violat= e > Farnham=E2=80=99s 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/operati= ng > system you no longer have in close enough detail. (Did I ever tell you th= e > one about 9-track tapes and the changing hardware specifications over tim= e > of maximum drift adjustments where the new =E2=80=9Cbetter=E2=80=9D tape = drive simply could > not be adjusted to read **some** of the tapes that had been written on > the =E2=80=9Cgone=E2=80=9D drives with a larger than average drift. Sigh.= It wasn=E2=80=99t funny > at the time either=E2=80=A6. > > 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 a= s > compressed as you plan to keep it. Partition exchange methods might be > helpful. > > b. Consider using direct load so you don=E2=80=99t have any delayed cl= eanout > issues reading things much later. > > c. Consider making the destination a less expensive =E2=80=9Cclass=E2= =80=9D 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@freelists.org [mailto: > oracle-l-bounce@freelists.org] *On Behalf Of *Mladen Gogala > *Sent:* Monday, February 01, 2016 4:03 PM > *To:* oracle-l@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=E2=80= =99t want > me deleting them. So to garnish space, can I compress these? They are > only copies of the existing readonly dbffiles=E2=80=A6 > > > > > > 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 > > --=20 Andrew W. Kerber 'If at first you dont succeed, dont take up skydiving.' --001a11c16152810462052abd9640 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ditto on Mark's comments.=C2=A0 Though I have used 9 t= rack tapes, I did not run his particular problem.=C2=A0 I recommend two cop= ies of the data files, and an export of them also.=C2=A0 Just to be safe.

On Mon, F= eb 1, 2016 at 5:08 PM, Mark W. Farnham <mwf@rsiz.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

A few things:

=C2=A0

1)=C2=A0=C2=A0=C2= =A0 Mladen=E2=80=99s questions are directly on point.<= /p>

2)=C2=A0=C2=A0=C2=A0 <= /span>=E2=80= =9CThey are the only copies of the existing readonly dbffiles=E2=80=A6=E2= =80=9D

a.=C2=A0=C2=A0=C2=A0=C2=A0 = Farnham=E2=80=99s Law= : =E2=80=9CDon=E2=80=99t trust your career to a single piece of spinning ru= st or ribbon rust.=E2=80=9D (Ribbon rust is a tape. This should probably be= updated to =E2=80=9Csingle piece of media=E2=80=9D but spinning rust and r= ibbon rust are helpful images to remember how fragile your career might be = if you violate Farnham=E2=80=99s Law.)

b.=C2=A0=C2=A0= =C2=A0 I hope you mount these for a few minutes and read something from the= m every time you patch anything in the entire stack. Otherwise they might b= ecome 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 ab= out 9-track tapes and the changing hardware specifications over time of max= imum drift adjustments where the new =E2=80=9Cbetter=E2=80=9D tape drive si= mply could not be adjusted to read *some* of the tapes that had been= written on the =E2=80=9Cgone=E2=80=9D drives with a larger than average dr= ift. Sigh. It wasn=E2=80=99t funny at the time either=E2=80=A6.

3)=C2=A0=C2=A0=C2= =A0 If space and compression is an issue then I suggest that in addition to= possibly reloading and compressing as per the methods Seth mentioned earli= er in the thread you use a reasonable protocol for tablespaces that have be= come read only whether or not you leave them unmounted most of the time. Am= ong the features of such a protocol:

a.=C2=A0=C2=A0=C2= =A0=C2=A0 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 help= ful.

b.=C2=A0=C2=A0=C2=A0 <= span style=3D"font-size:14.0pt;color:#1f497d">Consider using direct load so= you don=E2=80=99t have any delayed cleanout issues reading things much lat= er.

c.=C2=A0=C2=A0=C2=A0=C2=A0 = Consider making the dest= ination a less expensive =E2=80=9Cclass=E2=80=9D of storage than your activ= e database files is on.

d.=C2=A0=C2=A0=C2=A0 Make anoth= er copy somewhere else that will survive independently of the campus this f= ile is on.

=C2=A0

There is probably m= ore.

=C2=A0

mwf<= /p>

=C2=A0

From: oracle-l-bounc= e@freelists.org [mailto:oracle-l-bounce@freelists.org] On Behalf Of = Mladen Gogala
Sent: Monday, February 01, 2016 4:03 PM
To: oracle-l@fre= elists.org
Subject: Re: compress dbf backup files

=C2=A0

On 02/01/2016 12:09 PM, Zelli, Brian wrote:=

I have copies of dbf files sitting on a server.=C2= =A0 Management doesn=E2=80=99t want me deleting them.=C2=A0 So to garnish s= pace, can I compress these?=C2=A0 They are only copies of the existing read= only dbffiles=E2=80=A6

=C2=A0

=C2=A0

Brian

=C2=A0


This email message may contain legally privileged and/or confident= ial information. If you are not the intended recipient(s), or the employee = or agent responsible for the delivery of this message to the intended recip= ient(s), you are hereby notified that any disclosure, copying, distribution= , or use of this email message is prohibited. If you have received this mes= sage in error, please notify the sender immediately by e-mail and delete th= is 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 t= ake backups?
Regards
= 

-- 
Mladen Gogala=

Oracle DBA
Tel: (347) 321-1217=



--
Andrew W. Kerber

= 'If at first you dont succeed, dont take up skydiving.'
--001a11c16152810462052abd9640-- -- http://www.freelists.org/webpage/oracle-l