Re: Backup optimization and transportable tablespaces
Date: Wed, 10 Jun 2015 13:11:16 -0600
Message-ID: <CAJzM94BPTTnYu38W26+WA2e6=o0rZzduEKt2hPrY-wfpaLG=MA_at_mail.gmail.com>
Apparently, it's all about the money. The database has never crashed so why spend the money on a good DR solution? Not the way I like to work, but I don't get to make the decisions. At this point, if I had to do a restore, I would probably skip all the tablespaces from 2007 through 2013 and restore only 2014 and 2015 (a tablespace per day created by our TTS process). Then worry about the others. Most customers are interested only in the last 12-18 months of data. The powers that be have decided that is an acceptable risk. Makes me very uncomfortable though.
To answer the comment about restoring then applying archivelogs. We do a level 0 roughly once a month. Without valid level 1 backups, that's a whole lot of archivelogs to apply. I need to get my once a week level 1 completing in a time frame that doesn't interfere with the TTS process. Also got my answers from the SEs about tape retention. Will need to make some adjustments to my plan since Level 0 backups are kept only 3 months.
Lots of good information in this thread and it has given me what I need to come up with a better backup strategy.
Thanks again everyone.
Sandy
On Wed, Jun 10, 2015 at 12:43 PM, raza siddiqui <raza.siddiqui_at_oracle.com> wrote:
> 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..
>
> Raza
>
> 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 <
> dmarc-noreply_at_freelists.org> 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 11.2.0.2
>>
>> 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.
>> - 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 DBAhttp://mgogala.freehostia.com
>>
>>
>
>
> --
> Sandy
> GHX
>
>
> --
>
>
-- Sandy GHX -- http://www.freelists.org/webpage/oracle-lReceived on Wed Jun 10 2015 - 21:11:16 CEST