Re: Is there any way to push Standby database to delete archivelogs quicker (ARCHIVELOG DELETION POLICY in use)?
- From: Jack van Zanen <jack@xxxxxxxxxxxx>
- To: j.velikanovs@xxxxxxxxx
- Date: Fri, 22 May 2009 14:26:00 +1000
Hi Jurijs
How about the possibility to exclude certain filesystems from the
standard monitoring (FRA filesystem)
and put your own monitoring in place to monitor the FRA? Surely
excluding a filesystem should be fairly simple
We have most of our oracle filesystems excluded from regular
filesystem monitoring as we like to fill them up to avoid wasting disk
space.
As for the purging from the FRA can't you just use RMAN to delete
them? (not tested)
Jack
2009/5/22 Jurijs Velikanovs <j.velikanovs@xxxxxxxxx>:
> Hello everyone,
>
> Just to give you a better idea why I am looking for something like that:
> - A customer uses a file system to store archivelogs on Standby side
> - In order to let Oracle to manage those automatically we decided to
> use FRA and RMAN ARCHIVELOG DELETION POLICY. This would allow to avoid
> any custom scripts implemented on standby side for that purpose.
> This works very good with one exception.
>
> The customer is a big shop with huge commonly used infrastructure
> around different systems. There are a standard monitoring procedure
> for all File Systems out there. If FS is 95% (X%) full the monitoring
> system starts to send alerts. If we use FRA Oracle tends to use 100%
> of space and delete applied archivelogs if running our of space only.
> The proper way of handling this issue probably would be introducing a
> new FS check routine which would use V$RECOVERY_FILE_DEST;
> V$FLASH_RECOVERY_AREA_USAGE views for monitoring purposes. The problem
> is that as in any BIG organizations nobody willing change existing
> procedures and if even would like to change it would take a
> significant amount of time (BTW: Oracle is just 10% of RDBMS systems
> used in that organisation).
> If we say this isn't an option in that case what would be possible solutions?
>
> I see 2:
> - Find the way to let Oracle to clear FRA earlier then FS check
> threshold is reached. (This is what I asked in first post).
> - I don't like it: Lower db_recovery_file_dest_size parameter to be
> 95% (x%) of a file system size. Oracle DBA still will have some space
> to increase parameter back and work on the problem when system will
> hit 100% utilization of FRA. The obvious disadvantages are: the
> standard monitoring will not alarm when FRA running out of space,
> primary DB might stop until the FRA is cleaned.
>
> What is your experience in monitoring FRA utilization (excluding
> V$RECOVERY_FILE_DEST; V$FLASH_RECOVERY_AREA_USAGE option) if there are
> any?
>
> Best regards,
> Yury
>
>
> On Wed, May 20, 2009 at 6:22 PM, Jurijs Velikanovs
> <j.velikanovs@xxxxxxxxx> wrote:
>> Hello dear List members,
>>
>> Just wonder if someone came across the following question:
>> 10.2.0.4 Data Guard configuration
>> Backups are taken on primary. As soon as an archivelog applied on a
>> standby it could be deleted.
>> ON STANDBY:
>> log_archive_dest_1='LOCATION=use_db_recovery_file_dest'
>> CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY;
>>
>> Oracle deletes applied archivelogs in a "lazy" mode. I assume as soon
>> as space usage reach some threshold of db_recovery_file_dest_size
>> Oracle starts to delete some "old"/applied archivelogs from fra.
>> There are the following messages in the alert.log file:
>> Deleted Oracle managed file
>> +DATA/gtst/archivelog/2009_06_16/thread_1_seq_83.349.689686855
>> Deleted Oracle managed file
>> +DATA/gtst/archivelog/2009_06_16/thread_1_seq_84.351.689687247
>> ...
>>
>> Just wonder if someone knows any way to change the "threshold" to push
>> Oracle to delete applied archivelogs faster? Let say do not keep those
>> at all on keep a small amount of those?
>>
>> Thank you in advance,
>> Yury
>>
>
>
>
> --
> Jurijs
> +371 29268222 (+2 GMT)
> ============================================
> http://otn.oracle.com/ocm/jvelikanovs.html
> --
> //www.freelists.org/webpage/oracle-l
>
>
>
--
Jack van Zanen
-------------------------
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient. If you are not the intended
recipient, please be aware that any disclosure, copying, distribution
or use of this e-mail or any attachment is prohibited. If you have
received this e-mail in error, please contact the sender and delete
all copies.
Thank you for your cooperation
--
//www.freelists.org/webpage/oracle-l
Other related posts:
