RE: Redolog movement

From: Mark W. Farnham <mwf_at_rsiz.com>
Date: Wed, 26 Jun 2013 11:00:21 -0400
Message-ID: <005001ce727d$e20722c0$a6156840$_at_rsiz.com>

I *think* that depends on how you do the move - will you add new redolog members on the new locations before you drop the old redolog members?

If you do that and switch through the logs before you drop the old members I'm not clear why that would need to cause a hiccup, especially if you allow the extract process to finish up on a log group from which you intend to remove members until extracts from that group are complete and then drop the member(s) to be dropped before the group becomes active again.

Having a lot of log groups (like maybe 10 or more instead of the default) should make this easy.

You could also create entirely new log groups on the new location, but you must be aware of where in the rotation of log groups the new log group is inserted if you want to maximize the time you have to leave the old groups you're going to drop in place so they are cleared by your extract before you drop them.

Finally, you *could* create an atypically large redo log group in the new location and switch to it, wait for the existing groups to clear, add the real future groups on the new location, drop the old groups, switch to a normal sized new log, wait for the temporary giant group to be cleared (and make sure it is archived) and then drop the giant group.

That is more dancing around, but I fail to see why extract would ever then be reading a log group or log group member you needed to drop.

mwf

-----Original Message-----
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Nagaraj S
Sent: Wednesday, June 26, 2013 9:46 AM
To: Guillermo Alan Bort
Cc: oracle-l
Subject: Re: Redolog movement

thanks for your reply! I assume we need to stop the application that were intended to replicate

On Wed, Jun 26, 2013 at 7:07 PM, Guillermo Alan Bort <cicciuxdba_at_gmail.com>wrote:

> Short answer: it will have no significant impact.
>
> at worst it may cause an ABEND in the extract process and then you
> just restart the process.
>
> I would suggest, however, testing this in development or QA
> environments before performing it in production. Then again, I suggest
> that for just about any change :P
>
> Cheers.-
>
> Alan.-
>
>
> On Wed, Jun 26, 2013 at 4:48 AM, Nagaraj S <nagaraj.chk_at_gmail.com> wrote:
>
>> Hello Gurus!
>> We have 2 node RAC and redologs are configured in RAID 5 disk, Since
>> we noticed the performance is slow we planned to move the redo
>> logfiles to RAID 1 disk.
>> We configured OGG from primary cluster to secondary cluster,in this
>> situation will my OGG extract process will be affected due to redo
>> log movement? Please advise
>>
>> -Nagaraj
>>
>>
>> --
>> http://www.freelists.org/webpage/oracle-l
>>
>>
>>
>

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


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

Received on Wed Jun 26 2013 - 17:00:21 CEST