Re: is Oracle technically better than Ingres ?

From: Mark D Powell <Mark.Powell_at_eds.com>
Date: 10 Aug 2004 16:27:49 -0700
Message-ID: <2687bb95.0408101527.3b886012_at_posting.google.com>


michaelnewport_at_yahoo.com (michael newport) wrote in message news:<63b202d.0408101012.1d178269_at_posting.google.com>...
> ...so anyway I have not had time to implement the IOT suggestion
> (people keep giving me other work !), but its nice to know that I can
> do the same thing in Oracle that I used to do in Ingres. So thanks for
> the help.
>
> But pre-ordering your data is a handy feature that saves time (during
> the day) and hassle.
>
> But getting back to my original question, "is Oracle technically
> better than Ingres". I still can not say that it is. I was waiting for
> a smoking gun from some Oracle people as to why Oracle is better.
>
> Furthermore I kept having an Oracle "snapshot too old" problem which
> meant that after weeks of studiously putting my SQL query together, I
> am now having to split it up again. Something to do with the query
> taking too long.
>
> regards
> Mike

Mike, sometimes you get a "snapshot too old" because your rollback segments really are too small. How large are your segments in relation to the amount of data (include index changes) you are trying to change. Another common cause is too frequently committing during a process that reads and updates the same table.

Unlike say DB2 UDB which says to commit often Oracle is designed so that you should do large amounts of work between commits if concurrent access requirements allow. If your are updating then OLTP activity against the same table limits how long you want to hold a modified row while inserts have no such concurrent activity and can be held for a longer period without affecting any other session.

Also as you mentioned speeding up the processing of the query will also reduce the chance of a snapshot too old error if the cause of the problem is other sessions changing and committing data you need in very small transactions. How does the explain look? Does the join order appear to be the best order? Is the join method the best choice for the data in question? Are you dealing with skewed data values?

If you are using an UNDO tablespace instead of manually configured rollback setting the undo_retention period to be longer may help you out.

HTH -- Mark D Powell --

HTH -- Mark D Powell -- Received on Wed Aug 11 2004 - 01:27:49 CEST

Original text of this message