RE: Terabytes of archived redo logs
- From: "Mercadante, Thomas F \(LABOR\)" <Thomas.Mercadante@xxxxxxxxxxxxxxxxx>
- To: <JApplewhite@xxxxxxxxxxxxx>
- Date: Thu, 3 May 2007 10:22:14 -0400
How does Rman fit into this picture? Are you saying he should run a
Physical Stand-by system just to fix a backup issue? It's not a
horrible idea. But I'm wondering what the cost-benefit-ratio would be.
Acquiring a completely new server and stocking it with enough disk to
hold the database and the archivelog files?
Doesn't sound like a reasonable financial solution to me.
--------------------------------------------------------
This transmission may contain confidential, proprietary, or privileged
information which is intended solely for use by the individual or entity to
whom it is addressed. If you are not the intended recipient, you are hereby
notified that any disclosure, dissemination, copying or distribution of this
transmission or its attachments is strictly prohibited. In addition,
unauthorized access to this transmission may violate federal or State law,
including the Electronic Communications Privacy Act of 1985. If you have
received this transmission in error, please notify the sender immediately by
return e-mail and delete the transmission and its attachments.
________________________________
From: JApplewhite@xxxxxxxxxxxxx [mailto:JApplewhite@xxxxxxxxxxxxx]
Sent: Thursday, May 03, 2007 10:11 AM
To: Mercadante, Thomas F (LABOR)
Cc: avramil@xxxxxxxxxxxxxx; oracle-l@xxxxxxxxxxxxx;
oracle-l-bounce@xxxxxxxxxxxxx
Subject: RE: Terabytes of archived redo logs
Here's a, perhaps, wild, thought. Could you establish Physical Standby
databases on (an)other server(s)? Then you could let your Prod datbases
automatically shovel the archived redo logs to them, periodically remove
them from the Prod environment as you see they've been transferred to
the Standbys. You could also gzip them on the Standby side to further
save space. Gzip is such a CPU hog that I'd not want it running on the
Prod server.
You'd also get disaster recovery databases in the process. Just a
thought.
Jack C. Applewhite - Database Administrator
Austin (Texas) Independent School District
512.414.9715 (wk) / 512.935.5929 (pager)
Same-Day Stump Grinding! Senior Discounts!
-- Mike's Tree Service
Other related posts:
