Re: Backup optimization and transportable tablespaces

From: raza siddiqui <>
Date: Wed, 10 Jun 2015 11:43:36 -0700
Message-ID: <>

Hi Sandra,

Just a tad tangental - when was the last time a *_successful _*FULL recovery was performed from these backups (whether for real or as part of a DR exercise) ?

If so, how long did it take and was the business able to cope being offline at that time ? This would be the case for using DG. Interested if somebody used "superfluous" in the same sentence as DG then..


On 6/10/2015 11:29 AM, Sandra Becker wrote:
> Thanks for the suggestions. I don't have 19T of disk to do the
> file-copy, and will not get it right now even if I justify it. I
> asked for it once before. I think they're still laughing at my
> request. I also will not be able to get active DG and a standby.
> Used to have a standby, but with the shake up in the company in the
> past year, DG and standbys were deemed too costly and superfluous.
> I'm stuck with using tape and the current TTS process. The only
> upside is that these two databases are slated to be replaced within
> the next 6-9 months. Of course, I've heard that story before and it
> was nothing more than a fairy tale.
> Still trying to find out from my SEs how long tape backups are kept.
> I have already informed my manager the current backup strategy is not
> acceptable. I'm not sure he really understands the risks even though
> I said, "I can't restore the database to a reasonably current P-I-T."
> Sandy
> On Wed, Jun 10, 2015 at 11:32 AM, Mladen Gogala
> < <>> wrote:
> My advice would be to scrap the TTS process and create an active
> DG standby DB. You could also use it to backup the primary. Also
> to consider is SAN snapshot.
> Regards,
> On 06/10/2015 11:33 AM, Sandra Becker wrote:
>> OS: Solaris10
>> DB: EE
>> Current database and backup configuration:
>> * 19T database that we backup to tape--disk is not an option for me
>> * Level 0 backups roughly once a month, Level 1 weekly,
>> archivelogs multiple times per day
>> * Backup optimization is OFF
>> * No READ ONLY tablespaces
>> * TTS process that runs 7 times a week to create new
>> tablespaces, one per day, using transportable tablespaces
>> between two databases. The target database is the 19T one.
>> o Once data has been loaded, it is rarely updated after 90 days
>> * Backups and the TTS process are not allowed to run at the
>> same time. The people who wrote the very complex backup and
>> TTS process scripts left the company over 2 years ago and
>> they are not well documented.
>> * Level1 backups are now running long enough that the TTS
>> process doesn't run at it's next scheduled time causing us to
>> fall behind and customer frustration because the expected
>> data is not in the database
>> I am looking at options to improve backup performance. From what
>> I've read, I can set most of the tablespaces to READ ONLY and
>> enable backup optimization so the tablespaces that don't change
>> do not get backed up every week. Given the length of time for a
>> Level 1 backup, schedule of Level 0 backups, and tape retention
>> policy, I am currently at risk of not being able to restore this
>> database if needed.
>> Questions:
>> 1. What would be valid reasons for not letting the backups and
>> TTS process run at the same time? The TTS process can take
>> up to 4 hours for a single day.
>> 2. If backups and creating/loading the new tablespaces should
>> not be done at the same time, I'm thinking that modifying the
>> schedule would be an option I should consider so the TTS
>> process completes before the backup kicks off. Does this
>> sound reasonable?
>> 3. Is my thinking around optimizing my backups valid? Is there
>> another/better way I should consider? We would need to
>> script something to change the tablespaces to READ ONLY on a
>> daily or weekly basis.
>> 4. If a tablespace is READ ONLY and has not been backed up yet.
>> will it get picked up in a Level 0 or 1 backup even with
>> backup optimization on?
>> I am new to the transportable tablespace feature and haven't been
>> able to figure out everything our TTS scripts are doing or why
>> yet. I appreciate any suggestions and insight.
>> --
>> Sandy
>> GHX
> --
> Mladen Gogala
> Oracle DBA
> --
> Sandy


Received on Wed Jun 10 2015 - 20:43:36 CEST

Original text of this message