Oracle 10g RAC performance
Robert Jaroszuk
How (approximately) performance increase can I expect when i migrate one
dual-core Xeon server into two dual-core Xeon servers in RAC ?
Do you know any benchmarks comparing vertical-scaling vs
horizontal-scaling of Oracle servers?
What about two-server RAC vs three-servers RAC ?
How performance increase can I expect ? 30% ?
Best regards,
--
... Robert Jaroszuk ...
GCS/IT/O d? s: a- C++ ULB++++$ P+ L++++$ E- W++ K- N+ DI+ V-
w M- PS+ PE Y(+) PGP-(+++) t-- 5? X R !tv b++>++++ D- y+ G++
. http://zim.iq.pl/ . RJ735-RIPE . http://zim.iq.pl/photo/ .
.. The superior warrior wins without fighting -- Sun Tzu. ..
-> New photos: http://zim.iq.pl/photo/
Cristian Cudizio
Oracle says you can reach 80-90% of performance increment for each
node. But the real answer depends on your application.
On kevinclosson blog http://kevinclosson.wordpress.com/2007/01/31/dell-compares-rac-and-non-rac-performance-and-cost/
there is an interesting comparation.
Bye
Cristian Cudizio
http://cristiancudizio.wordpress.com/
http://oracledb.wordpress.com
Mladen Gogala
> Oracle says you can reach 80-90% of performance increment for each node.
I work with parallel technologies for a few months now and it hasn't been
my experience. As a matter of fact, my first parallel installation was
Oracle 6.22 on 2 node VAX Cluster, I was working with SGI Challenge and
clustered them under Oracle 7.x, I was maintaining Oracle 8i OPS and 9i
RAC systems and I am maintaining 10.2 RAC databases now. As Gopal (K.
Gopalakrishnan, one of the foremost Oracle's RAC experts) will tell you,
RAC is not just a bigger box, it's much more complex then that.
Performance increase is highly dependent upon the type of the application
you plan to run. Realistic testing is the key. Problem is that DML locks
are now global and take network communication which makes them much more
expensive then the local locks. Also, you cannot track them. The key to
the V$LOCK table are UNDO segments which provide the values for ID1 and
ID2 columns. You can easily find out who are you waiting for, as long as
everybody is using the same undo segments, something that is not the case
on a properly set up RAC system. With global locks, you don't know who's
holding the lock on the row you need. With all improvements made to RAC/
OPS (cache fusion, dynamic remastering, dynamic locks) global locks are
still much more expensive then the local ones and if your application is
a high intensity OLTP application in which many users occasionally
cluster around just a few blocks, RAC will not provide any benefits to
you. It will provide baptism by fire instead. RAC is not a silver bullet
and is, in my opinion, the greatest possible tool for DW type applications
and warehouses. OLTP applications take careful functional partitioning and
very expensive HW, such as EMC disk arrays, Infiniband and BFM (very big
machines, in Doom terminology).
DA Morgan
> Hello.
>
> How (approximately) performance increase can I expect when i migrate one
> dual-core Xeon server into two dual-core Xeon servers in RAC ?
> Do you know any benchmarks comparing vertical-scaling vs
> horizontal-scaling of Oracle servers?
>
> What about two-server RAC vs three-servers RAC ?
> How performance increase can I expect ? 30% ?
>
> Best regards,
Oracle's published numbers for adding CPUs are roughly 84%. From what
I have seen in my lab they are being reasonable. Sometimes I see better
and sometimes worse depending on the application.
Which adds up to what Cristian said ... you will need to try your app
and determine your own metrics.
The performance of dual-core vs adding a separate CPU I have not tested
nor have I seen published metrics.
--
Daniel A. Morgan
University of Washington
damo...@x.washington.edu
(replace x with u to respond)
Puget Sound Oracle Users Group
www.psoug.org
Valentin Minzatu
> Hello.
>
> How (approximately) performance increase can I expect when i migrate one
> dual-core Xeon server into two dual-core Xeon servers in RAC ?
> Do you know any benchmarks comparing vertical-scaling vs
> horizontal-scaling of Oracle servers?
>
> What about two-server RAC vs three-servers RAC ?
> How performance increase can I expect ? 30% ?
>
> Best regards,
>
> --
> ... Robert Jaroszuk ...
> GCS/IT/O d? s: a- C++ ULB++++$ P+ L++++$ E- W++ K- N+ DI+ V-
> w M- PS+ PE Y(+) PGP-(+++) t-- 5? X R !tv b++>++++ D- y+ G++
>
> -> New photos:http://zim.iq.pl/photo/
My two cents: if your application scales very well in a single node
configuration, then you should expect it to scale in a cluster
configuration as well (up to 90-95% according to Oracle). If your
application does NOT scale well in a single node configuration, then
forget about RAC: it will only make things worse. Also keep in mind
that the most penalty you pay in a RAC environment is when you add the
3rd node. An interesting presentation can be found on RAC SIG website:
http://www.oracleracsig.org/pls/htmldb/Z?p_url=RAC_SIG.download_my_file?p_file=1000920&p_id=1000920&p_cat=documents&p_user=ERIK&p_company=550311706566234.
Cheers,
Valentin
joel garry
> Hello.
>
> How (approximately) performance increase can I expect when i migrate one
> dual-core Xeon server into two dual-core Xeon servers in RAC ?
> Do you know any benchmarks comparing vertical-scaling vs
> horizontal-scaling of Oracle servers?
>
> What about two-server RAC vs three-servers RAC ?
> How performance increase can I expect ? 30% ?
>
At Collaborate07 I went to some session about performance case studies
by a fellow named Gaja (dbperfman.com), and he answered something I
had been idly wondering about since hearing rumors of people doing it
at an Openworld a couple of years ago. Namely, dedicating one
instance to OLTP, and the other to reporting.
Seems when you do that, there might be severe performance degradation
as the reporting instance is constantly having to query the OLTP
instance undo to maintain consistency. For a FTS - oops!
I also overheard people talking about Oracle not quite handling "split-
brain" the way they would like yet... in 11g.
So, as with everything, it depends. Apologies if I'm rumor-mongering.
Hey, nice photos.
jg
--
@home.com is bogus.
Happy to be obscurist.
DA Morgan
Given that no one has seen 11g production code it is too early to know
how it will handle split-brain.
With respect to running OLTP and reporting on a cluster it would depend
on the application. In some cases it might be fine: Partitioning, Hash
Clusters, etc. where what is being inserted is not what is being queried.
As with everything else ... it depends.
hpuxrac
wrote:
>
> Cheers,
> Valentin
Well geez let's not start putting out some half way reasonable
interpretations around cdos it's going to spoil the fun of the oracle
marketing fossils.
There's a reasonable smart guy who wrote "Why you probably don't need
RAC" ... there's somebody who is clued in to the real world.
The 90 to 95 percent thing sounds more like a "forget about it" with
carefully pre-arranged benchmarking of painfully created non quite
real world applications.
Mladen Gogala
> There's a reasonable smart guy who wrote "Why you probably don't need
> RAC" ... there's somebody who is clued in to the real world.
Pushing RAC to everybody is, at least in my opinion, a very dangerous
policy yet Oracle is doing just that. RAC is not a solution for
everything. One would think that they would learn from IBM, DEC and
Microsoft but, apparently, not so. I usually explain the concept like
this: if you have a car capable of taking 4 people across 55 miles in
1 hour, then adding a second car, chained to the first car, bumper to
bumper, will not help you with taking 4 people across 110 miles in 1 hour.
Buying a faster car (and a radar detector) will.
That is precisely what people are trying to do: making their apps running
twice as fast by adding a second node, chained to the first in bumper to
bumper fashion.
--
http://www.mladen-gogala.com
DA Morgan
I would agree that "pushing" RAC is not the solution. But providing
information to customers on what RAC is and what it does is an
invaluable service in a world where management and customer expectations
are often 7x24x365.
If nothing elsee, the implementation of RAC everywhere, will force a lot
of companies selling junk to clean up their schemas and their code.
While I agree with Mogens on many things ... RAC is quite often a good
solution and Windows quite often is not.
Mladen Gogala
> If nothing elsee, the implementation of RAC everywhere, will force a lot
> of companies selling junk to clean up their schemas and their code.
Or, to switch to another database. Personally, I am studying PostgreSQL
as I believe that it will present a serious challenge to Oracle very soon.
K Gopalakrishnan
> At Collaborate07 I went to some session about performance case studies
> by a fellow named Gaja (dbperfman.com), and he answered something I
> had been idly wondering about since hearing rumors of people doing it
> at an Openworld a couple of years ago. Namely, dedicating one
> instance to OLTP, and the other to reporting.
>
> Seems when you do that, there might be severe performance degradation
> as the reporting instance is constantly having to query the OLTP
> instance undo to maintain consistency. For a FTS - oops!
Gaja strikes again,
I completely understand what Gaja is talking. However there are lot of
internal optimizations (and you can further tune them if required)
done in this area like 'lightwork rule ' and 'fairness threshold'. If
you ever had a chance to have a look at my book you will understand
what I am talking here. In case if you could not find the book in the
bookstore near to you, here again.
***Quoting from Oracle 10g RAC Handbook****
Lightweight Rule and Fairness Threshold
When there are too many CR requests for a particular buffer, it will
be too much of work for the holder to serve the CR buffer to the
requestors. In these situations, the holder just disowns the lock on
the buffer and writes the block to the disk. Now the requestor can
read the block from the disk after acquiring the required lock on the
object. The number of consecutive request after the holder down
converts the lock elements is configurable via _fairness_threshold
parameter. This parameter defaults to 4, which is usually enough for
most of the instances. However, it requires special setting when one
instance in the cluster is always used for queries.
Lightwork rule is invoked when the CR construction involves too much
of work when there is no current block or PI blocks are not available
in the cache for block cleanouts. The number of times the instance
does the fairness down covertion and lightwork rule is invoked is
shown in the V$CR_BLOCK_SERVER. And the view V$CR_BLOCK_SERVER also
lists additional details about the CR request processing and the
distribution of block requests.
V$CR_BLOCK_SERVER
Name Type Notes
------------------------ --------- ------------------------
CR_REQUESTS NUMBER CR+CUR =Total Requests
CURRENT_REQUESTS NUMBER
DATA_REQUESTS NUMBER
UNDO_REQUESTS NUMBER
TX_REQUESTS NUMBER DATA+UNDO+TX= CR+CUR
CURRENT_RESULTS NUMBER
PRIVATE_RESULTS NUMBER
ZERO_RESULTS NUMBER
DISK_READ_RESULTS NUMBER
FAIL_RESULTS NUMBER
FAIRNESS_DOWN_CONVERTS NUMBER # of downconverts from X
FAIRNESS_CLEARS NUMBER # of time Fairness counter cleared
FREE_GC_ELEMENTS NUMBER
FLUSHES NUMBER Log Flushes
FLUSHES_QUEUED NUMBER
FLUSH_QUEUE_FULL NUMBER
FLUSH_MAX_TIME NUMBER
LIGHT_WORKS NUMBER # of times light work rule evoked
ERRORS NUMBER
The number of times the down coverts happens and the lightweight rule
invoked from the instance startup can be obtained form the following
query.
SQL> SELECT CR_REQUESTS, LIGHT_WORKS ,DATA_REQUESTS,
FAIRNESS_DOWN_CONVERTS
2 FROM
3 V$CR_BLOCK_SERVER;
CR_REQUESTS LIGHT_WORKS DATA_REQUESTS FAIRNESS_DOWN_CONVERTS
----------- ----------- ------------- ----------------------
80919 5978 80918 17029
When the data request to down convert ratio is more than 40%, then
lowering the _fairness_threshold from default may improve the
performance and greatly reduce the interconnect traffic for the CR
messages. This parameter can be set to 0 when the systems, which are
used for, query only purposes. Setting _fairness_threshold to 0
disables the fairness down converts. This parameter can only be
altered with the consent of Oracle Support.
***END QUOTE***
Having said that, it is the trade off between the disk-IO to the
cached-networked-IO. If your disk or IO subsystem is the bottleneck
this will further complicate the issue as it goes back to disk to read
the blocks (like your old OPS 'ping') instead of asking the holder to
ship the block via wire.
Dedicating one node to reports has its own advantages/disadvantages.
You have to carefully benchmark and test things in RAC before doing it
in prime-time. All I can say is it can be (further) optimized if you
know your application well.
YMMV!
Best Regards,
K Gopalakrishnan
Co-Author: Oracle Wait Interface, Oracle Press 2004
http://www.amazon.com/exec/obidos/tg/detail/-/007222729X/
Author: Oracle Database 10g RAC Handbook, Oracle Press 2006
http://www.amazon.com/gp/product/007146509X/
DA Morgan
Not to start a religious war here but the feature set of all of the
open source RDBMS products makes them only suitable for the kinds of
projects one might reasonably do in MS Access. For example there isn't
a single enterprise application that runs on PostgreSQL and my personal
gold standard, dice.com, currently show 17,535 Oracle jobs and only 211
PostgreSQL jobs. If the point is to pay the mortgage you might have
better odds forming a rock band.
The Boss
> Mladen Gogala wrote:
>> On Sat, 28 Apr 2007 11:42:09 -0700, DA Morgan wrote:
>>
>>> If nothing elsee, the implementation of RAC everywhere, will force
>>> a lot of companies selling junk to clean up their schemas and their
>>> code.
>>
>> Or, to switch to another database. Personally, I am studying
>> PostgreSQL as I believe that it will present a serious challenge to
>> Oracle very soon.
>
> Not to start a religious war here but the feature set of all of the
> open source RDBMS products makes them only suitable for the kinds of
> projects one might reasonably do in MS Access. For example there isn't
> a single enterprise application that runs on PostgreSQL and my
> personal gold standard, dice.com, currently show 17,535 Oracle jobs
> and only 211 PostgreSQL jobs. If the point is to pay the mortgage you
> might have better odds forming a rock band.
Read again.
Mladen isn't saying _he_ will switch to another dbms, just _adding_ another
one to his repertoire.
I don't see how that can be a bad idea.
There will be some companies moving from Oracle to PostgreSQL, others will
start with PostgreSQL and afterwards maybe will come to the conclusion they
need Oracle (or DB2 or whatever). In both cases they might have a need for
someone with skills in both databases.
Regarding your rather condescending comparison to MS Access, have a look at:
http://www.enterprisedb.com/news_events/press_releases/04_23_07.do
--
Jeroen
Ana C. Dent
news:4633d466$0$326$e4fe...@news.xs4all.nl:
Marketing hype vs. Market reality
Which enterprise application(s) support PostgreSQL?
HAND!
hpuxrac
> Mladen Gogala wrote:
> > On Fri, 27 Apr 2007 17:48:53 -0700, hpuxrac wrote:
>
> >> There's a reasonable smart guy who wrote "Why you probably don't need
> >> RAC" ... there's somebody who is clued in to the real world.
>
> > Pushing RAC to everybody is, at least in my opinion, a very dangerous
> > policy yet Oracle is doing just that. RAC is not a solution for
> > everything. One would think that they would learn from IBM, DEC and
> > Microsoft but, apparently, not so. I usually explain the concept like
> > this: if you have a car capable of taking 4 people across 55 miles in
> > 1 hour, then adding a second car, chained to the first car, bumper to
> > bumper, will not help you with taking 4 people across 110 miles in 1 hour.
> > Buying a faster car (and a radar detector) will.
> > That is precisely what people are trying to do: making their apps running
> > twice as fast by adding a second node, chained to the first in bumper to
> > bumper fashion.
>
> I would agree that "pushing" RAC is not the solution. But providing
> information to customers on what RAC is and what it does is an
> invaluable service in a world where management and customer expectations
> are often 7x24x365.
>
> If nothing elsee, the implementation of RAC everywhere, will force a lot
> of companies selling junk to clean up their schemas and their code.
Clueless again eh?
Try reading Mogen's recent post about high availability.
>
> While I agree with Mogens on many things ... RAC is quite often a good
> solution and Windows quite often is not.
People that really need RAC are a very small percentage. For what it
does for high availability there is nothing else like it in the
marketplace.
People that may attempt to implement it and actually hurt their uptime
in the long run ... no shortage of experiences like that going around.
Mladen Gogala
> There will be some companies moving from Oracle to PostgreSQL, others
> will start with PostgreSQL and afterwards maybe will come to the
> conclusion they need Oracle (or DB2 or whatever). In both cases they
> might have a need for someone with skills in both databases.
Basically, what I am complaining about is the tendency to push RAC to
everybody. What people don't understand is that adding machines also
adds a layer of complexity. I have a lot of experience with Oracle and
I needed a lot of help from Gopal when I did my first Oracle 10G/ASM
installation. I am very grateful for his help and his book has been of
immense help, but RAC is a very complex product. Essentially, RAC
makes a good DBA a must. Very few small companies are willing to hire
a full time DBA just to manage a database.
In addition to that, I once worked for a company that went from Oracle to
Postgres, just because they felt that Oracle is too big, too complex and
too expensive for them. Wang Trading was a small hedge fund in Norwalk,
CT that got rid of both Oracle and me. That sort of things tends to catch
my attention. Now, they're out of business, I have no idea why.
DA Morgan
> People that may attempt to implement it and actually hurt their uptime
> in the long run ... no shortage of experiences like that going around.
<sarcasm>
Yeah the outages are killing Amazon.com.
</sarcasm>
I think the problem is contained in the way you phrased your statement.
You wrote: "people that may attempt to implement." I think you will find
similar horror stores with any technology when the self-taught try to
design, deploy, and manage technology based on reading a few PDFs and a
PowerPoint presentation.
Perhaps you should come out here and take the PSOUG's RAC class. <g>
DA Morgan
> On Sun, 29 Apr 2007 01:10:30 +0200, The Boss wrote:
>
>> There will be some companies moving from Oracle to PostgreSQL, others
>> will start with PostgreSQL and afterwards maybe will come to the
>> conclusion they need Oracle (or DB2 or whatever). In both cases they
>> might have a need for someone with skills in both databases.
>
> Basically, what I am complaining about is the tendency to push RAC to
> everybody. What people don't understand is that adding machines also
> adds a layer of complexity.
I really don't think our fellow DBAs are that dense. You don't give
enough credit where credit is due. I think everyone understands that
there is an added layer, clusterware, of technology. And possibly two
if you throw in ASM.
But the decisions are not being made by DBAs they are being made by
CTOs. And the fault, if I can find any, is that those CTOs are willing
to invest in the RAC licenses but not in training their team so that
they will be successful.
> I have a lot of experience with Oracle and
> I needed a lot of help from Gopal when I did my first Oracle 10G/ASM
> installation. I am very grateful for his help and his book has been of
> immense help, but RAC is a very complex product. Essentially, RAC
> makes a good DBA a must.
You will get no argument from me on that. Nor would I argue that
training, or a mentor, are essential for a successful design and
deployment. But that has been true of every major technology advance
I have witnessed in the last 30 years.
Of course there are self-taught DBAs that are very good. But lets be
honest and acknowledge the majority couldn't describe how an Oracle
transaction works if given a snap test.
> Very few small companies are willing to hire
> a full time DBA just to manage a database.
Our here in Seattle that is not true but it may be the case where you
are located. Here if they are willing to step up to the plate for
Oracle ... they are willing to step up to the plate for a DBA or 500.
That said there is still a problem with their willingness to invest in
that person's training though some companies out here are extremely good
at taking care of their people.
We have companies in Seattle and Portland that, literally, sent their
entire DBA team to take Jonathan Lewis' classes when he has been here.
Amazon.com is extremely supportive of their employees and has gone so
far as to contract the University of Washington to teach classes for
them.
> In addition to that, I once worked for a company that went from Oracle to
> Postgres, just because they felt that Oracle is too big, too complex and
> too expensive for them.
No doubt. I know companies that have gone bankrupt making bad decisions.
One or ten or fifty examples does not make a trend.
> Wang Trading was a small hedge fund in Norwalk,
> CT that got rid of both Oracle and me. That sort of things tends to catch
> my attention. Now, they're out of business, I have no idea why.
I could hazard a guess ... and I will ... bad decision making. A better
management team likely would have kept both Oracle and you.
joel garry
> Mladen Gogala wrote:
> > On Sun, 29 Apr 2007 01:10:30 +0200, The Boss wrote:
>
> >> There will be some companies moving from Oracle to PostgreSQL, others
> >> will start with PostgreSQL and afterwards maybe will come to the
> >> conclusion they need Oracle (or DB2 or whatever). In both cases they
> >> might have a need for someone with skills in both databases.
>
> > Basically, what I am complaining about is the tendency to push RAC to
> > everybody. What people don't understand is that adding machines also
> > adds a layer of complexity.
>
> I really don't think our fellow DBAs are that dense. You don't give
> enough credit where credit is due. I think everyone understands that
> there is an added layer, clusterware, of technology. And possibly two
> if you throw in ASM.
I don't think they are that dense either, but from what I've seen they
often
have the idea that since Oracle is pushing RAC to everybody, it must
be
a good thing. And I do get the feeling people underestimate the
additional
risk more layers of complexity adds. People seem to think each
layer's
problems are additive or even independent, when they are actually
multiplicative.
>
> But the decisions are not being made by DBAs they are being made by
> CTOs. And the fault, if I can find any, is that those CTOs are willing
> to invest in the RAC licenses but not in training their team so that
> they will be successful.
I'm sure Oracle would be quite willing to certify their team as
professionals :-O
Regardless, Mladen is right: RAC is pushed to everybody.
>
> > I have a lot of experience with Oracle and
> > I needed a lot of help from Gopal when I did my first Oracle 10G/ASM
> > installation. I am very grateful for his help and his book has been of
> > immense help, but RAC is a very complex product. Essentially, RAC
> > makes a good DBA a must.
>
> You will get no argument from me on that. Nor would I argue that
> training, or a mentor, are essential for a successful design and
> deployment. But that has been true of every major technology advance
> I have witnessed in the last 30 years.
The real question is, how many of those advances are pushed to those
who really don't need them? (And of course, there is a corollary
question of those who stall at particular technologies, only to need
to
catch up later, we certainly see that a lot in this ng).
>
> Of course there are self-taught DBAs that are very good. But lets be
> honest and acknowledge the majority couldn't describe how an Oracle
> transaction works if given a snap test.
Not to mention if they can describe how a snap works if given a
transaction
test :-)
>
> > Very few small companies are willing to hire
> > a full time DBA just to manage a database.
>
> Our here in Seattle that is not true but it may be the case where you
> are located. Here if they are willing to step up to the plate for
> Oracle ... they are willing to step up to the plate for a DBA or 500.
This kind of caught my attention: my observation (Southern
Californai)
jibes with Mladen's. I couldn't help but wonder if the Seattle area
is
different because any smaller shop would likely be MS...
>
> That said there is still a problem with their willingness to invest in
> that person's training though some companies out here are extremely good
> at taking care of their people.
>
> We have companies in Seattle and Portland that, literally, sent their
> entire DBA team to take Jonathan Lewis' classes when he has been here.
> Amazon.com is extremely supportive of their employees and has gone so
> far as to contract the University of Washington to teach classes for
> them.
>
> > In addition to that, I once worked for a company that went from Oracle to
> > Postgres, just because they felt that Oracle is too big, too complex and
> > too expensive for them.
>
> No doubt. I know companies that have gone bankrupt making bad decisions.
> One or ten or fifty examples does not make a trend.
>
> > Wang Trading was a small hedge fund in Norwalk,
> > CT that got rid of both Oracle and me. That sort of things tends to catch
> > my attention. Now, they're out of business, I have no idea why.
>
> I could hazard a guess ... and I will ... bad decision making. A better
> management team likely would have kept both Oracle and you.
Another Wang once was a big computer company. Must be a jinx there.
I guess the moral must be if you have a wang, keep it private.
K Gopalakrishnan:
Thanks!
jg
--
@home.com is bogus.
And the award for "the largest human alteration of the Earth's
surface." goes to... http://www.fresnobee.com/263/story/43270.html
DA Morgan
>> You will get no argument from me on that. Nor would I argue that
>> training, or a mentor, are essential for a successful design and
>> deployment. But that has been true of every major technology advance
>> I have witnessed in the last 30 years.
>
> The real question is, how many of those advances are pushed to those
> who really don't need them? (And of course, there is a corollary
> question of those who stall at particular technologies, only to need
> to catch up later, we certainly see that a lot in this ng).
I'd like to step back and suggest some consideration with respect to
two things you wrote. The first is the word "push" and the second is
the question of "need."
Anyone that lets any salesperson into their office knows the nature
of the relationship. So is the word "push" really appropriate? Are
CTOs and DBAs that incapable of evaluating the "need" for 7x24?
I see a lot here in this group about the added complexities, etc., of
RAC but that is not mirrored in my phone ringing with requests for
support. Does that mean that we're that good or that our customers
are that lucky? I doubt either. I think RAC is a solid technology
when implemented on the right hardware in the right way.
I'm not saying it isn't more complex but from my experience well
trained people have stable environments.
>> Of course there are self-taught DBAs that are very good. But lets be
>> honest and acknowledge the majority couldn't describe how an Oracle
>> transaction works if given a snap test.
>
> Not to mention if they can describe how a snap works if given a
> transaction
> test :-)
>
>>> Very few small companies are willing to hire
>>> a full time DBA just to manage a database.
>> Out here in Seattle that is not true but it may be the case where you
>> are located. Here if they are willing to step up to the plate for
>> Oracle ... they are willing to step up to the plate for a DBA or 500.
>
> This kind of caught my attention: my observation (Southern
> Californai)
> jibes with Mladen's. I couldn't help but wonder if the Seattle area
> is
> different because any smaller shop would likely be MS...
You might well be correct but I can only speak from my experience here
where I am located.
Speaking of which when one local aerospace firm decided to implement the
Oracle grid they requested a quote to train 300 DBAs. And that is not
the entire team.
>>> Wang Trading was a small hedge fund in Norwalk,
>>> CT that got rid of both Oracle and me. That sort of things tends to catch
>>> my attention. Now, they're out of business, I have no idea why.
>> I could hazard a guess ... and I will ... bad decision making. A better
>> management team likely would have kept both Oracle and you.
>
> Another Wang once was a big computer company. Must be a jinx there.
> I guess the moral must be if you have a wang, keep it private.
A lot of fathers will appreciate that advise.
Data Cruncher
"The Boss" <use...@No.Spam.Please.invalid> wrote in message
news:4633d466$0$326$e4fe...@news.xs4all.nl...
> There will be some companies moving from Oracle to PostgreSQL
"Then there is EnterpriseDB which, while it may be a pinprick to Oracle, has
picked up 100 or so potential or actual Oracle customer installations over
the last year; and finally, there are the data warehouse appliance vendors,
such as Netezza, that have won a number of major deals against Oracle (and
others)."
http://www.it-analysis.com/technology/data_mgmt/content.php?cid=9428