Re: Oracle: Naked King in database land?

"Anne" <anne_at_thereistoomuchspam.com> wrote in message news:9oqia.9952$Pp.1241589_at_amsnews03.chello.com...
> Hi,

<snip>

> I am constantly having problems with Oracle server on three hardware
> platforms, AMD and Intel, 1+ Ghz, 1.5+ Gbyte, no Raid, Raid 0, 1, 1+0, 5,
> enough free disk and table space. All on MS Windows 2000 server (maybe
that
> is the problem?) and win NT, Win2K and WinXP as client. Oracle 9.01 and
> 9.02. The problems below occur only when using tables larger than about
250
> 000 records, but on amounts below that I would really consider using
> MS-Access or something the like (don't start on transactions, multi-user,
> security etc., to me that's the vi freak - much used argument for little
> used features - point of view)

If you don't need multiple sessions, don't care about security and don't worry about logical units of work then really any RDBMS is beyond your requirements. Use flat files and a programming language.

>
> Problems encountered in the last few weeks:
> * crashing the whole database running an insert query, having to reinstall
> and rebuild the whole thing (once)

never seen

> * spontaneous shutdown of the database running an insert query (twice)

never seen

> * constantly having ORA4030 (out of memory errors) when using Designer
> created insert-triggers

Never seen, but then most of my code gets written in wordpad or vs .net. these days

> * very time-consuming TAR handling, having to install patch on patch on
> patch and sending trace after trace after trace until you give up (I would
> prefer to send them script + data and get replies only when they solve the
> easily reproducible, common case, problem).

Absolutely fair point, though using MS PSS is not exactly the most user friendly process either.

> * internal errors ORA00600 when using "order by" on indexed 1.5 million
> record tables

Never seen.

> * internal errors ORA00600 when creating indexes on large tables

Never seen

> * does "end of communication channel" sound familiar?

No. Well yes but only when something is setup badly.

> * prehistoric net client. Why not use dns + port by default and invent
those
> error prone tnsnames workarounds only for "probably better but much less
> used" alternative network systems?

host naming.

>Why install thousands of files and
> millions of bytes as smallest version oracle net client and not include an
> odbc driver by default on the 98% most used OS in the world?

Fair comment, though I would always want to install a current ODBC driver.

> * so what is revolutionary about having multiple long/blob columns in a
> single table?

It's a new feature for Oracle. What's so revolutionary about indexed views in MSSQL 2000 - its a new feature.

> * queries crash when autoextending tablespaces start to autoextend even on
> lots of empty disk space

never seen.

> * getting a "processor too fast" diagnose for (a previous version) oracle
> installer

Never seen, was it a certified installer/product for the platform you were installing on

> * query optimizer clearly less intelligent than MS-Access and MySQL on
some
> cases. Never found to be more intelligent.(Oracle workaround: analyze
tables
> compute statistics, forcing use of indexes by removing wrongly used ones,
> forcing change of query execution plan by using nested queries).

All optimizers for RDBMS use stats - using the product as designed cannot seriously be described as a 'work around'. BTW how do you view the execution plan in MS Access?

> * unable to first-time connect to oracle from a new process within 1
second
> (necessary for standard websever cgi implementations). As comparison:
> MS-Access and MySQL connect times are negligable.

Almost certainly misconfigured net8 software.

> Then why, you may ask, am I still using Oracle?
> * my boss tells me to and our customers believe they will have a very
robust
> and stable database solution

They will.

> * after spending a huge amount of time on building and tuning the
database,
> I must admit, the lookup-queries are quite fast

Build and tune the SQL before you start to look at the database. That will be where 80% of your tuning issues lie.

Niall Litchfield
Oracle DBA
Audit Commission UK Received on Wed Apr 02 2003 - 05:48:12 CST