RE: RAC application mix
From: Michael McMullen <ganstadba_at_hotmail.com>
Date: Wed, 3 Jun 2009 08:43:21 -0400
Message-ID: <BAY115-DAV4BA3FAF862A6D36FE505FA64A0_at_phx.gbl>
Message-ID: <9C33EDBC545F4F8FAFB9D61FF1FE98D1_at_vpmcm01>
I inherited a rac in the same situation you did. I find the best way to get a handle of a system is just to watch what it's doing. I use toad session browser sorted by active sessions. In a transaction based system I figure if I can see active sessions then those are the things that are slow in the system. I also find that users get so used to a slow system that they hardly complain and if the users are agents and the system is slow and a faster system means answering more calls then they never complain. Anyhow, the two node rac I inherited was designed just like yours (lots of multiple logging going on). I found the things that killed it performance wise were full table scans by multiple users no matter the size of the table (even a few KB). I was able to add indexes as how I saw fit and that fixed things fine. A bug got introduced in the app where the inserts/update/deletes in the logging table increased by 1000x and the box cruised along just fine, it went to 5GB/hr redo so it's not as if the system is being taxed to begin with. But any FTS ended up being a killer for scalability.
Date: Wed, 3 Jun 2009 08:43:21 -0400
Message-ID: <BAY115-DAV4BA3FAF862A6D36FE505FA64A0_at_phx.gbl>
Message-ID: <9C33EDBC545F4F8FAFB9D61FF1FE98D1_at_vpmcm01>
I inherited a rac in the same situation you did. I find the best way to get a handle of a system is just to watch what it's doing. I use toad session browser sorted by active sessions. In a transaction based system I figure if I can see active sessions then those are the things that are slow in the system. I also find that users get so used to a slow system that they hardly complain and if the users are agents and the system is slow and a faster system means answering more calls then they never complain. Anyhow, the two node rac I inherited was designed just like yours (lots of multiple logging going on). I found the things that killed it performance wise were full table scans by multiple users no matter the size of the table (even a few KB). I was able to add indexes as how I saw fit and that fixed things fine. A bug got introduced in the app where the inserts/update/deletes in the logging table increased by 1000x and the box cruised along just fine, it went to 5GB/hr redo so it's not as if the system is being taxed to begin with. But any FTS ended up being a killer for scalability.
-- http://www.freelists.org/webpage/oracle-lReceived on Wed Jun 03 2009 - 07:43:21 CDT