Re: Drop empty table and lms flush message acks

Hi,

I am tempted to refer you to this post some weeks earlier,

http://groups.google.com/group/comp.databases.oracle.server/browse_thread/thread/345dd63133bbf863

What is your redolog configuration? how big are they and do they share the same ASM disk group as the datafiles and Undo tablespaces? how big is your redolog buffer?

i don't really see why your interconnect is an issue, unless you are using serial cables. i suppose your are using UDP. is it a gigabit ethernet connection? are you using default values for udp parameters?

As Morgan mentioned, what are the times for the 'gc' related statistics?

cheers
anand

DA Morgan wrote:
> mirfalk wrote:
> >> I would bet your analysis is incorrect and the device speed actually is
> >> one of the problems (and maybe the speed of the cluster interconnect).
> >
> > Speed of cluster interconnect is, in my opinion the problem. I got the
> > same behavior with TRUNCATE TABLE operations.
> >
> > Could you suggest me a way to investigate it?.
> >
> > While I'm talking with you I have a TRUNCATE table still running after
> > more then 5 miuntes (it's a staging table which has been truncated
> > without any problem till few days ago).
> >
> > TIA
> > A.D.
>
> What are you using for the mem interconnect? What technology?
> Have you run a StatsPack?
>
> Run the statspack.snap procedure and spreport.sql script on each node
> you want to monitor to compare to other instances.
>
> All times should be less than 15ms
> The ratio of global lock gets vs global lock releases should be near 1
>
> Also look in:
> gv$cache_transfer
> gv$class_cache_transfer
> gv$file_cache_transfer
> gv$temp_cache_transfer
> --
> Daniel A. Morgan
> University of Washington
> damorgan_at_x.washington.edu
> (replace x with u to respond)
> Puget Sound Oracle Users Group
> www.psoug.org
Received on Tue Aug 01 2006 - 00:51:22 CDT