Oracle rant

On Wed, 15 Jan 2003, mlw wrote:

I just wanted to post this note.

I have been in Oracle hell for four days now, and in between the 5
minutes of work and the hours of watings, dealing with table spaces,
extents, and all that, I just keep thinking about how much easier
PostgreSQL is to work with.

We all may bitch and moan about bugs and stuff, but my project would
have been easier with PostgreSQL.

Has anyone ever noticed that Oracle has all these nice little arcane
ways to fail?

Yes.

I was doing some work with a company. I wanted to introduce
Postgres. They're traditionally an oracle shop. "Our Oracle DBAs don't
know Postgres, we're going to have to employ *another* DBA". No they
don't. :-)

Gavin Sherry wrote:

On Wed, 15 Jan 2003, mlw wrote:

I just wanted to post this note.

I have been in Oracle hell for four days now, and in between the 5
minutes of work and the hours of watings, dealing with table spaces,
extents, and all that, I just keep thinking about how much easier
PostgreSQL is to work with.

We all may bitch and moan about bugs and stuff, but my project would
have been easier with PostgreSQL.

Has anyone ever noticed that Oracle has all these nice little arcane
ways to fail?

Yes.

I was doing some work with a company. I wanted to introduce
Postgres. They're traditionally an oracle shop. "Our Oracle DBAs don't
know Postgres, we're going to have to employ *another* DBA". No they
don't. :-)

This is the truth, we have had an oracle box for two and a half years,
we have had 4 PostgreSQL boxes with it. The Oracle system is on a 4 CPU
Sun box. The PostgreSQL systems are on 2 CPU PIII boxes.

We had "certified oracle DBA"s setup the oracle box. I setup the
PostgreSQL boxes. The PostgreSQL boxes NEVER had an unscheduled
interruption in service. The Oracle system stops from time to time
because of various arcane reasons. You get the error message, look it up
on alltheweb.com, and fix it. The whole system is bogus. It DEMANDS a
full time DBA. PostgreSQL does not.

<snippage>

The Oracle system stops from time to time because of various arcane
reasons. You get the error message, look it up on alltheweb.com, and
fix it. The whole system is bogus. It DEMANDS a full time DBA.
PostgreSQL does not.

I could be accused of being cynical here (gosh)... but I think thats the
whole idea - (hook'em with product and leverage "consulting" or "expert
dba"..). One could be excused for thinking that "its all about money".

<extra rant>
Once upon a time I did the Oracle 7.3 certification thing , however I
subsequently I feel that I really dont *need* to buy into this "Dba
Guild" mentality that the whole business seemed to be about (i.e. arcane
little "need to know" things that trap all but the initiated... and of
course certification is all about *being* the initiated...oh...and...
maybe the exam fees help perpetuate this thing too...).
</extra rant>

Thanks to you guys for providing the opportunity to share this ;-)

Mark

(i.e. arcane
little "need to know" things that trap all but the initiated...

So, for postgres, that means:
- a good thing the autovacuum thingy is coming along
- postgres should auto-tune itself - the *cost could perhaps be
adjusted after some statistics have been collected, and there should be
some sensible way to determine an optimal setting for the famous
shared_buffers (and the default should be something that gets reasonable
performance on common cases)

No, I don't expect the second one soon - I know how hard it is. No, I'm
not debating that PostgreSQL is not much, much, much easier to
administrate and set up than Oracle. I'm just saying that there are
*some* small arcane details in postgres, too (although, at least, they
don't affect stability, just performance).

cheers
-- vbi

--
pub 1024D/92082481 2002-02-22 Adrian von Bidder
Key fingerprint = EFE3 96F4 18F5 8D65 8494 28FC 1438 5168 9208 2481

Adrian 'Dagurashibanipal' von Bidder wrote:

I'm just saying that there are
*some* small arcane details in postgres, too (although, at least, they
don't affect stability, just performance).

Indeed you are right... Pg has its own collection of arcane details too,
but hopefully the culture of Postgesql (in common with all open source
projects) is to "expose and educate" rather than "confine to a group of
the initiated".

Does that sound better ? ( i.e no so rabid Oracle bashing)

Cheers

mark

On Thu, 2003-01-16 at 08:29, Mark Kirkwood wrote:

Adrian 'Dagurashibanipal' von Bidder wrote:

I'm just saying that there are
*some* small arcane details in postgres, too (although, at least, they
don't affect stability, just performance).

Indeed you are right... Pg has its own collection of arcane details too,
but hopefully the culture of Postgesql (in common with all open source
projects) is to "expose and educate" rather than "confine to a group of
the initiated".

Does that sound better ? ( i.e no so rabid Oracle bashing)

Yes, sounds better. Seriously: I absolutely agree that Oracle is not
inclined to make it easier to use their product - after all, as was
said, they sell courses and certifications, while pg tries to be easy to
use. I just got the impression from the first few messages that some
people think that pg has no secret tricks you're supposed to know at
all. Experience counts. With all systems. (And knowing the secret tricks
is what experience comes down to, basically).

cheers
-- vbi

--
signature virus v1.0 - please use me in your own mail.

I work in an all Oracle shop, with server instances around the world. At
least 20 servers are 400Gb+ and a couple are 4 Terabyte+. I tooks $15k worth
of Oracle training, have set up my own instances and done Perl/CGI/Apache
work along with setting up really big data warehousing apps for factories and
engineers.

I also am a Linux Nut and use Postgres whenever possible because I like the
freedom of access to the HACKERS mailing list...something only a few highly
renound DBA snobs have with Oracle.

I have been impressed however, with the degree to which Oracle(synonymous
with Ellison) has attempted to become "Open". Oracle is getting into Linux
almost as heavily as IBM, mostly prompted by their common rivalry with M$ and
SQLServer. Oracle's licensing policy of "download it if you want and we'll
trust you to do the right thing and give us money if you meet the criteria"
does build a sense of trust with the technical world. And, their
documentation is fairly open and detailed. What their docs don't cover, a
search on Google or something else(like attending Oracle World events) will
generally illuminate.

So, as far as "Openness" goes, I would say that PostgreSQL is more open than
Oracle, but Oracle is pretty good.

The one thing I notice about PostgreSQL however, is this tendency to keep the
DBA away from considerations of hardware..."don't worry about the man behind
the curtains folks...." mentality.

With Oracle, you can screw around with files and tablespaces and extents and
segments and partition striping and local and global indexing and block sizes
and 400+ other tuning parameters to your heart's content. And, if you
happened to put your data on separate server instances, you and use database
links to join the data together. With Oracle's transaction logging and
rollback segments, a paranoid DBA can do all sorts of replication schemes,
backup schemes, and point in time recovery...to ANY POINT IN TIME, whether or
not there was a crash or simple a user who issued a really dumb SQL
statement. Perhaps this is a tremendous waste of time and leads to a lot of
crashes with arcane error messages, but it gives the DBA control.

I am a control freak and I think a lot of other people are too. Oracle is
tremendously complex and has a steep learning curve, but it gives me control.
With PG, a lot of effort has been made to simplify. This removes DBA
control, but probably also contributes to the stability you guys think you
have over Oracle. Perhaps Oracle's supposed instability is partially due to
allowing DBAs to fiddle with too much. I know that some is sometimes due to
Oracle releasing poorly coded features too soon, but I think a lot of it is
also due to DBAs screwing with stuff too.

Of course, if the boss just wanted me to get the DB running and quit screwing
with coallescing free extents in tablespaces, then I would just run PG.

If PostgreSQL were to open up all the internals of storage and become as
complex as Oracle, there probably would be a lot of high profile crashes and
PG would get a bad reputation. However, I think that having a mode of
operation(controlled at compile time) where all the dirty details of storage
was made accessible in the data dictionary, would be something good to pacify
the control freaks.

Food for thought. If you need someone play devils advocate in the Oracle vs.
PG debates, I'll do it. I think that a little critique of PG

Fred

On 1/16/2003, "Adrian 'Dagurashibanipal' von Bidder" <avbidder@fortytwo.ch>
wrote:

On Wed, 15 Jan 2003, mlw wrote:

I just wanted to post this note.

I have been in Oracle hell for four days now, and in between the 5
minutes of work and the hours of watings, dealing with table spaces,

I've been in Informix hell for the month or so.
At first, we were getting the message "No more extents" - so I look up the
documentation and it says the only way to fix it is to either delete data
or unload and reload the data. Ok. fine. I talked with a bunch of people
and they agreed that is how to fix the problem. Unfortunatly, we cannot
have much downtime and a reload would take days and days. So I went about
writing a little appliation to do it (Since I could not use a lovely sql
statement to do it because of a lack of logical log space - turning the
logs off is also not something I want to do.. especially on a multi-day
operation).

So the thing runs. A week later the data is loaded, indexes built. We're
about to switch the tables and I'm replaying my "audit trail" to make sure
the new table is up to date when I get "No more exents". Luckly I had a
bottle of rum handy. After some searching around on newsgroups and
message boards it turns out that the problem is not that there are not
enough extents, but there are 16.7M pages of data in the table. The only
fixes for THAT are to fragment the table (Kind of like an internal union
view type thing - which I couldn't do because informix doesn't let you do
union with a text blob). So after lots of testing and finding out the
version of informix we run has a bug where max() doesn't work if your
index is fragmented, we've finally started the copy again.

A long time ago I managed to win a battle to get a PG system (7.0.1) for a
thing I developed. That machine has NEVER <knock knock> had a problem.
And since that time we've moved lots of stuff onto it... currently is only
about 4GB in size. Someday I'll upgrade to a newer version, but if it
ain't broke, don't fix it.

So with all that, you gotta appreciate both sides - hte fact pg "just
works" and the tunability of bigger db's (Oh yeah - and we've actually had
informix on the horn about the problem - their solution was "upgrade to
9.4 - it'll be out in march").

Hopefully this last thing will complete and I'll be done with it.

------------------------------------------------------------------------------
Jeff Trout <jeff@jefftrout.com> http://www.jefftrout.com/
Ronald McDonald, with the help of cheese soup,
controls America from a secret volkswagon hidden in the past
-------------------------------------------------------------------------------

Due to the fact that we are growing out of our current system (PostgreSQL on
PCs) we are looking for ways to expand and one of the suggestions has been to
toss PostgreSQL in favour of Oracle with Remote Access Cluster (RAC)
software. The theory is that you can just plug machines into the cluster if
the database appears to be straining and they automagically take over some of
the load. Not knowing much about it I can only argue about price and source
code availability. The first has some value but the second is harder to
argue without knowing about RAC. Is it really as simple as it sounds or
would we just be giving up the other two for a new set of problems.

My idea is to create a new middleware layer that allows me to split things up
based on various criteria without changing my application. RAC sounds like
it does that at the database/SQL level. Does it?

We are also looking at hardware solutions, multi-CPU PCs with tons (24GB) of
memory. I know that memory will improve access if it prevents swapping but
how well does PostgreSQL utilize multiple CPUs?

And finally, if you had your dream machine to run on, what would it be? We
are also looking outside of PC hardware but we are concerned about not having
access to that nice, cheap, generic hardware for when we need to grow again
or for redundant backup.

Thanks for any tips and suggestions.

-- 
D'Arcy J.M. Cain <darcy@{druid|vex}.net>   |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 425 1212     (DoD#0082)    (eNTP)   |  what's for dinner.

On Thu, Jan 16, 2003 at 11:17:42AM -0500, Jeff wrote:

On Wed, 15 Jan 2003, mlw wrote:

So with all that, you gotta appreciate both sides - hte fact pg "just
works" and the tunability of bigger db's (Oh yeah - and we've actually had
informix on the horn about the problem - their solution was "upgrade to
9.4 - it'll be out in march").

Here lies the real secret to why Open Source of all types keeps the
techies (like us) maximally happy: I know I've seen Tom Lane (and
others) often suggest an upgrade as the real fix for a problem, but the
suggestion to upgrade to a not yet released version invariably includes
the option of applying the patch yourself. Not something Oracle can offer.

Ross

On Thu, 2003-01-16 at 17:42, D'Arcy J.M. Cain wrote:

We are also looking at hardware solutions, multi-CPU PCs with tons (24GB) of
memory. I know that memory will improve access if it prevents swapping but
how well does PostgreSQL utilize multiple CPUs?

At most one CPU is used for any single postgres backend (that means for
any single database connection). So, if your load problem is single
queries being too slow, thee's nothing you can do with adding more CPUs.
If your problem is many connections maxing out the db, PostgreSQL can
take full advantage of multiple CPUs.

Of course, most db apps still are not cpu bound, so you'd have to do
some careful benchmarking first or you'll be spending too much money.

cheers
-- vbi

--
get my gpg key here: http://fortytwo.ch/gpg/92082481

On Thu, 2003-01-16 at 11:42, D'Arcy J.M. Cain wrote:

Is [Oracle RAC] really as simple as it sounds or would we just be
giving up the other two for a new set of problems.

That's a question you should be asking to an authority on Oracle RAC
(which pgsql-hackers is not).

My idea is to create a new middleware layer that allows me to split things up
based on various criteria without changing my application.

Personally, I would not be very eager to use home-brew replication for a
heavy-load, production-critical application (which is what your app
sounds like). But YMMV...

We are also looking at hardware solutions, multi-CPU PCs with tons (24GB) of
memory. I know that memory will improve access if it prevents swapping but
how well does PostgreSQL utilize multiple CPUs?

The estimates I've heard from a couple parties are that PostgreSQL tends
to scale well up to 4 CPUs. I've been meaning to take a look at
improving that, but I haven't had a chance yet...

Another option is to put some money toward the current development
effort to get truly scalable replication for PostgreSQL. In the end, I'd
think the cost of subsidizing some of that development would be a
fraction of the license fees you'll end up paying Oracle over the
years...

Cheers,

Neil
--
Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC

On Thu, Jan 16, 2003 at 10:50:49AM -0600, Ross J. Reedstrom wrote:

suggestion to upgrade to a not yet released version invariably includes
the option of applying the patch yourself. Not something Oracle can offer.

Not for a sane price, I guess. I believe the high end support contracts
include getting custom patched versions in a short period of time.

Petru

Adrian 'Dagurashibanipal' von Bidder writes:

- postgres should auto-tune itself - the *cost could perhaps be
adjusted after some statistics have been collected, and there should be
some sensible way to determine an optimal setting for the famous
shared_buffers (and the default should be something that gets reasonable
performance on common cases)

Over the last couple of years PostgreSQL has transformed from hardly
configurable to fully configurable. Currently we're in a mode where we
add new configuration parameters whenever there's a degree of uncertainty.
Sooner rather than later we need to shift to the next phase, which is as
you say autoconfiguration, because ease of administration is one of the
great advantages of PostgreSQL.

--
Peter Eisentraut peter_e@gmx.net

Peter Eisentraut wrote:

Adrian 'Dagurashibanipal' von Bidder writes:

- postgres should auto-tune itself - the *cost could perhaps be
adjusted after some statistics have been collected, and there should be
some sensible way to determine an optimal setting for the famous
shared_buffers (and the default should be something that gets reasonable
performance on common cases)

Over the last couple of years PostgreSQL has transformed from hardly
configurable to fully configurable. Currently we're in a mode where we
add new configuration parameters whenever there's a degree of uncertainty.
Sooner rather than later we need to shift to the next phase, which is as
you say autoconfiguration, because ease of administration is one of the
great advantages of PostgreSQL

I think the idea of adding a parameter when ever you are not sure, is a
great idea. That does preclude, however, the ability for a process
within PostgreSQL from analyzing the metrics and updating the parameter
file or table.

Due to the fact that we are growing out of our current system
(PostgreSQL on
PCs) we are looking for ways to expand and one of the suggestions
has been to
toss PostgreSQL in favour of Oracle with Remote Access Cluster (RAC)
software.

You mean Real Application Clusters?

Chris

Fred Zellinger wrote:

I also am a Linux Nut and use Postgres whenever possible because I like the
freedom of access to the HACKERS mailing list...something only a few highly
renound DBA snobs have with Oracle.

Indeed, I think this is a significant component of the appeal of open
source

I have been impressed however, with the degree to which Oracle(synonymous
with Ellison) has attempted to become "Open". Oracle is getting into Linux
almost as heavily as IBM, mostly prompted by their common rivalry with M$ and
SQLServer.

I wonder if the "conversion" to openness may more a mechanism to
distinguish themselves from Microsoft, than a heart-felt belief in the
principles themselves.... but its nice anyway !

regards

Mark

On Thursday 16 January 2003 12:23, Neil Conway wrote:

On Thu, 2003-01-16 at 11:42, D'Arcy J.M. Cain wrote:

Is [Oracle RAC] really as simple as it sounds or would we just be
giving up the other two for a new set of problems.

That's a question you should be asking to an authority on Oracle RAC
(which pgsql-hackers is not).

True but I already have their perspective. Now I am looking for reasons to
stay with PostgreSQL.

My idea is to create a new middleware layer that allows me to split
things up based on various criteria without changing my application.

Personally, I would not be very eager to use home-brew replication for a
heavy-load, production-critical application (which is what your app
sounds like). But YMMV...

Not replication per se although I suppose that could be built in. What I am
talking about is an application that knows our business logic and brokers
requests for data from the database(s) in an OO way. The idea is to split
data up in the middleware whenever necessary.

We are also looking at hardware solutions, multi-CPU PCs with tons (24GB)
of memory. I know that memory will improve access if it prevents
swapping but how well does PostgreSQL utilize multiple CPUs?

The estimates I've heard from a couple parties are that PostgreSQL tends
to scale well up to 4 CPUs. I've been meaning to take a look at
improving that, but I haven't had a chance yet...

Cool. I am looking at Tyan boards that have 4 CPUs and 24GB memory.

Another option is to put some money toward the current development
effort to get truly scalable replication for PostgreSQL. In the end, I'd
think the cost of subsidizing some of that development would be a
fraction of the license fees you'll end up paying Oracle over the
years...

This is definitely an option. I can probably put both people and money into
such an effort. I would be happy to hear from people who can work on that.

-- 
D'Arcy J.M. Cain <darcy@{druid|vex}.net>   |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 425 1212     (DoD#0082)    (eNTP)   |  what's for dinner.

On Thursday 16 January 2003 20:54, Christopher Kings-Lynne wrote:

toss PostgreSQL in favour of Oracle with Remote Access Cluster (RAC)
software.

You mean Real Application Clusters?

Oops, yes.

-- 
D'Arcy J.M. Cain <darcy@{druid|vex}.net>   |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 425 1212     (DoD#0082)    (eNTP)   |  what's for dinner.