Re: Minimize recovery time

Yes they are on different datacenter and those too in different locations.

 And backup is being taken in both primary and secondary through ZDLRA and i believe the respective backups must be kept in the respective data centre in their configured ZDLRA storage.

On Wed, 27 Apr 2022, 4:06 pm Andy Sayer, <andysayer_at_gmail.com> wrote:

> Your dataguard is using the same storage as your primary? Usually it would
> be a whole different data centre. Where are your backups going?
>
>
> On Wed, 27 Apr 2022 at 11:35, Lok P <loknath.73_at_gmail.com> wrote:
>
>> Yes we have dataguard setup , but this agreement is in place in case of
>> both primary and dataguard DB fails because of disaster or corruption etc.
>>
>>
>> On Wed, 27 Apr 2022, 3:30 pm Andy Sayer, <andysayer_at_gmail.com> wrote:
>>
>>> Have you considered Dataguard? You’d have a secondary database always
>>> ready to failover to.
>>>
>>> Thanks,
>>> Andy
>>>
>>>
>>> On Wed, 27 Apr 2022 at 10:50, Lok P <loknath.73_at_gmail.com> wrote:
>>>
>>>> Hello Listers, We have an Oracle Exadata (X7) database with 12.1.0.2.0
>>>> and it's now grown up to size 12TB now. As per client agreement and
>>>> criticality of this application the RTO(Recovery time objective) has to be
>>>> within ~4hrs. The team looking after the backup recovery has communicated
>>>> the RTO(recovery time objective) as ~1hrs for ~2TB of data with current
>>>> infrastructure. So going by that, this current size of the database will
>>>> have RTO ~6hrs which is more than the client agreement(which is ~4hrs).
>>>>
>>>> Going through the top space consumers, we see those are table/index
>>>> sub-partitions and non partitioned indexes. Should we look into table/index
>>>> compression here? But then i think there is also downside of that too on
>>>> the DML performance.
>>>>
>>>> Wanted to understand Is there any other option to get this achieved
>>>> (apart from exploring possible data purge) to have this RTO faster or under
>>>> the service agreement? How should we approach.
>>>>
>>>>
>>>> Regards
>>>>
>>>> Lok
>>>>
>>>

--
http://www.freelists.org/webpage/oracle-l