Re: Article about supposed "murky" future for Oracle

From: Daniel Morgan <damorgan_at_x.washington.edu>
Date: Wed, 31 Mar 2004 21:52:23 -0800
Message-ID: <1080798723.472164@yasure>

rkusenet wrote:

>>Thanks. But then I could point out that if you did have Oracle
>>you'd have the DBMS_AQ built-in package and Oracle's Advanced
>>Queueing so the issue you describe wouldn't exist.

>
>
> No comments since I don't know AQ packages. Are they equivalent
> of database tables. Are they as simple to program as writing a SQL.
> Can data be loaded into a datamart/datawarehouse. And above al
> is that a separate product from Oracle and built into the database
> server.

A built in package is code written by Oracle to perform functionality not possible in SQL or PL/SQL such as reading and writing operating system files or in this case creating very sophisticated queues.

To quote Oracle documentation:
"Event publication uses the publish-subscribe mechanism of Oracle Advanced Queuing. A queue serves as a message repository for subjects of interest to various subscribers. Triggers use the DBMS_AQ package to enqueue a message when specific system or user events occur."

http://download-west.oracle.com/docs/cd/B10501_01/appdev.920/a96587/toc.htm

> Speaking for myself I like using database tables for
> work flow. It is a proven technology and IMO no database other
> informix work as well. Reason being that informix concept of non
> logged database is unique. It virtually eliminates any disk activity
> except writing to physical once per checkpoint. Of course you will
> lose data if a crash happens, but then u don't care either.

Perhaps you don't care if you lose data. I do. My bank does. My government does. Heck even my mother does. ;-)

> The only advantage I see of using a Queue series is that the application
> process need not poll the table. They can be called on events. But then
> with multiple processes polling the work flow table, the wait time is
> almost negligible. Actually we can convert it into an event by attaching
> a table trigger to a C code.

If you write C that is an entirely different matter as that is not functionality native to the product.

> I have been told that Oracle's concept of lock management is to write
> the lock information in the data block itself, instead of centralized
> lock manager. That means a SELECT FOR UPDATE will be two writes. One for
> the lock and one for the actual write of the data. Not OK for us
> in the given scenario.

Try looking at it another way. A lock in a block read into memory is not a disk write. Locking 1000 records is not writing 1000 times to disk. And in Informix you can run out of record level locks. Then what happens? You get lock escallation and start locking pages. The Oracle model provides an infinite number of row locks and lock escallation is impossible.

-- 
Daniel Morgan
http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp
http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
damorgan_at_x.washington.edu
(replace 'x' with a 'u' to reply)

Received on Wed Mar 31 2004 - 23:52:23 CST