Re: performance of insert/delete/update

On Mon, 2002-11-25 at 18:43, Rich Scott wrote:
[snip]
> upgrades and/or lawsuits against Oracle. An astute cohort of mine asked
> to
> see some of the code, and found out that the original developers (at the
> telco)
> had created a bloated and slow control system in C++, using semaphores or
> somesuch,
> to *serialize* inserts/updates/deletes, and so they had gigantic
> home-built
> queues of insert jobs. Not only were they not bundling updates in
> transactions,
> they were only ever doing one transaction at a time. (Apparently, they
> never
> learned RDBMS fundamentals.) He told them to rip out all that code, and
> let
> Oracle (like any other decent RDBMS) handle the update ordering. The
> resultant
> speed-up factor was several hundred times.

Just goes to show the difference between RDBMSs. Even with the biggest
Alphas possible at the time, our Customer Service Center app was
crawling because of lock conflicts (each transaction affected ~10-12
tables). Rdb/VMS works best with a TP monitor (specifically ACMS).
We were'nt using one, and weren't handling lock conflicts in the best
way. Thus, the slowdowns.

The developers finally wrote a home-grown dedicated TP-like server,
using DEC Message Queue and /serialized/ data flow. Without all
of the lock conflicts, performance warped forward.

The reason for this, I think, is that Oracle serializes things itself,
whereas Rdb/VMS expects ACMS to do the serialization. (Since both
Rdb & ACMS were both written by DEC, that's understandable I think.)

--
+------------------------------------------------------------+
| Ron Johnson, Jr. mailto:ron(dot)l(dot)johnson(at)cox(dot)net |
| Jefferson, LA USA http://members.cox.net/ron.l.johnson |
| |
| "they love our milk and honey, but preach about another |
| way of living" |
| Merle Haggard, "The Fighting Side Of Me" |
+------------------------------------------------------------+