RE: Compressing Rman Disk Backups
- From: DENNIS WILLIAMS <DWILLIAMS@xxxxxxxxxxxxx>
- To: "'oracle-l@xxxxxxxxxxxxx'" <oracle-l@xxxxxxxxxxxxx>
- Date: Mon, 29 Mar 2004 10:09:13 -0600
Tom
If you can find enough disk space elsewhere, I was able to get RMAN to
split the backup pieces between multiple locations back in 8i. Your best
alternative may be to bite the bullet and buy some cheap disk, maybe even
network-attached.
Dennis Williams
DBA
Lifetouch, Inc.
dwilliams@xxxxxxxxxxxxx
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx]On Behalf Of Mercadante, Thomas F
Sent: Monday, March 29, 2004 10:00 AM
To: 'oracle-l@xxxxxxxxxxxxx'
Subject: RE: Compressing Rman Disk Backups
Stephen,
thanks for the reply. But doesn't using pipes require that I know the name
of the output "device" that Rman is using? At least the name of the logical
device?
I'll try piping the result to something - but I get the feeling that Rman
doesn't give us the opportunity to pipe the results anyplace.
Tom Mercadante
Oracle Certified Professional
-----Original Message-----
From: Stephen.Lee@xxxxxxxx [mailto:Stephen.Lee@xxxxxxxx]
Sent: Monday, March 29, 2004 10:50 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: RE: Compressing Rman Disk Backups
> -----Original Message-----
> other option is to break the backup into a tablespace by tablespace
> multi-Rman run process and gzip or compress the files in
> between each step.
>
> Anybody found a way to do this?
I think it would require the use of named pipes. Start up the compress
sessions, and have them suck on the pipes prior to running rman.
Complications I can think of are that rman is probably creating multiple
backup sets, and you would require a named pipe for every backup set. The
named pipe mechanism would require that once rman has started writing to the
pipe, it must continue to do so until it is completely finished with that
pipe because the compress process will stop sucking on the pipe as soon as
it thinks writing to the pipe has finished.
And a warning.
I have tried this with export/import on Tru64 using the compress utility and
have found that I occasionally get files that import says are bad. I don't
know why. This SHOULD be OK. But it isn't. So I don't do it any more.
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Other related posts:
