Re: RAC is slower than non-RAC for batch job with lots of update/delete?

Qihua,

I believe that to be a fair assessment. Granted, I am still a RAC novice, but I think what is happening is that your batch job is doing dml against blocks that are mastered on both nodes, hence the gc waits as you pointed out.
See this pdf<http://www.google.com/url?sa=t&ct=res&cd=7&url=http%253A%252F%252Fiougew.prod.web.sba.com%252Fclient_files%252F51%252FACF527A.doc&ei=qT0XR8KDG56wiwGG6JyMBw&usg=AFQjCNEPcLgNRcgRrUVRWiyF4HXfy1ha1g&sig2=8Gs-2RUSKJHha_MpajT4zA> .

I have heard that the Oracle kernel will keep track of how many times a gc request is made, and upon hitting a certain threshold, will remaster a particular block (or table?) to the node making a majority of the requests. Which makes me wonder. If your batch job is always connecting to a specific node, could the blocks be mastered explicitly to that node? I ask that of the list.

On 10/18/07, qihua wu <staywithpin_at_gmail.com> wrote:
>
> Hi, everyone,
>
> After our database changed into RAC enviroment, the batch job is very
> slow. I am wondering whether RAC is not good for batch job. As batch job
> only use one session and only connect to one instance, but when
> update/delete data, sometime "gc current request" wait occurs as the block
> must be read from the other node. Without RAC, then this kind of wait will
> gone, so I think RAC is not good for batch job with plenty of update/delete
> operations. Anyone doesn't agree?
>
> Thanks,
> Qihua
>

-- 
Charles Schultz

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