Re: performance drop of >35% from Oracle 7.1 to 8.05

Oracle in the past announced it would drop the single task implementation of Oracle, available on VMS *only*.
The two-task interface, uncommon, but available on VMS, but the *only* option on *all* other platforms, was going to be the only interface. So, yes, this was to be expected (mailboxes probably being implemented using $QIO and/or $QIOW calls) and, regrettably, there is *no* workaround, as this is an architectural change. The only other option would be (depending on the number of users) implement the MultiThreaded Server, if that's available for VMS.
IMO, frankly I think VMS is on the way out. I remember seeing remarks on KPN dropping this platform too. This is of course a pity, but was to be expected after DEC was bought by Compaq
Hopefully you are going to replace it by some Unix flavor, instead of that flaky NT

Regards,

Sybrand Bakker
Oracle DBA
former VMS user/enthusiast

Dirk Munk <d.munk_at_kpn.com> schreef in berichtnieuws 01bfcf04$73b73ab0$ab4815ac_at_HKTGN0002251944...
> After an upgrade from VMS 6.2 & Oracle 7.1 to VMS 7.2 & Oracle 8.0.5 we
> noticed a performance drop of > 35 %.
>
> At the same time the buffered IO rate went sky high and CPU utilization
> went up too.
>
> After close examination we found that in the old situation a given program
> with SQL statements consisted out of one process that communicated with
 the
> database listner.
>
> In the new situation the program is made up out of two processes, one
> process with the same name as the old process, and a second Oracle process
> that communicates with the database listener.
>
> The communication between both processes is done by means of mailboxes,
 and
> that explains the terrible loss in performance and the high buffered IO
> rate & CPU utilization.
>
> A mailbox in VMS is a device like any other device, and writing to and
 from
> a mailbox is normal IO with all overhead attached to it.
>
> Has anyone experienced this problem before (seems Oracle 7.3.4 already had
> this problem), and did anyone find a workaround ?
>
> Regards,
>
> Dirk Munk
> KPN Telecom
>
>
>
Received on Mon Jun 05 2000 - 00:00:00 CDT