| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: Oracle Standard Edition & RAC
If you are use to having clients enable session level trace through some config file, the activation of a logon trigger, or some switch in command line arguments at startup and than trying to get the client to replay the problematic action, or re-run the problematic batch jobs to try and catch the actual problem in that session, than the idea of having AWR/diagnostics pack data should be well worth the $.
If you are a speedy tuner and can absorb the diagnostics info from a statspack report or a session level trace and than implement your own recommendation on how to fix it with additional access structures, improved stats, an outline/hint, sql re-write, etc, than maybe the tuning stuff isn't all that helpful for you.
If you routinely spend weeks tuning single or groups of statements than maybe it is worth the money. Maybe you are fortunate to have the perfect ERP system that doesn't issue bad SQL because all of its developers are the most DB knowledgable folks out there...
Since profiles are part of tuning pack, you will be stuck with outlines though if the CBO can't possibly understand the overall selectivity of multiple inter-related predicates (as an example). So the idea of profiles and their utility would lead me to wanting tuning also.
If initial software outlay costs were the primary driver for the project, and I wanted to ensure I had the maximum amount of diagnostic info, I'd probably use diagnostics for db and app server and SLM for end-user performance monitoring.
SLM will let me routinely test the performance of all kinds of "known interactions" with the app, the db, the ldap, the network, my own perl/csh test/data collection scripts on a routine basis from the end user perspective. that set of diagnostic/metric data on routine performance of all services provided by the db/application is more valuable than all the low-level db metric stuff that doesn't necessarily correlate well to a particular end-user's single important action they executed through a series of web app screens.
in certain fields/industries, software acquisition costs are understood to be such a small part of the overall IT project that these options (while they may add up), if they lead to more robust diagnosis/testing while in development and production may be well worth it over the long time.
Job
"Polarski, Bernard" <Bernard.Polarski_at_atosorigin.com> wrote:
“
I suppose you refer to the failure of the interconnect? But in two nodes RAC, you still have the primary so the voting will occurs. I can’t see a specific reason for a split brain linked to the condition of a RAC being only of two nodes. I always thought that split brain is only linked to the usage of an extended (storage) RAC.
“
Standard Edition RAC can be useful, I am sure. And I have little doubt that somebody is using it. Somewhere. But I would think that an application that genuinely requires the "high availability" offered by RAC while simultaneously living comfortably within the limits of a 4 CPU cluster would be a very rare combination.
“
Well, I can give a good and common example of a standard usage of this combination: the back end of an Oracle Portal DB. Don’t need much sophistication, just have the DB available to serve the portal which is itself duplicated. Many are just windows dual xeon cpu boxes.
I am quite confident that Oracle will adapt the policy of SE RAC to the new wave of dual/quad core CPU or SE RAC will be limited to one box which means no RAC. SE RAC exists to occupy the low end market and prevent customer that use apps like Oracle portal to switch to web M$ while introducing the RAC technology in house so that people my one day expand its usage to EE and offer their cash to Larry Hat.
Bernard Polarski
-- http://www.freelists.org/webpage/oracle-lReceived on Wed Jan 03 2007 - 09:39:58 CST
 |
 |