Re: Informix and Oracle in the same shop

David Williams wrote:
>
> In article <5n1dv1$2ar_at_mew.corp.sgi.com>, Pablo Sanchez
> <news_reader_at_mew.corp.sgi.com> writes
> >
> >In article <33935782.7D9610FC_at_devnull.org>, Tim Schaefer <devnull_at_devnull.org>
> >writes:
> >> Pablo Sanchez wrote:
> >> >
> >> > No vendor, that I know of, is truly multi-threaded... at least in the
> >> > sense of user threads and the like.
> >> > --
> >>
> >> whoa!
> >>
> >> Finally somebody mentioned the threads thing, and you shoot it down
> >> so quickly! tsk tsk.... :-)
 

> >:-)!!!! Well they'll all claim it if it's the soup of the day kinda
> >thing...
> >
> >> Yes, as much as I hammer on Informix, they are truly and independently
> >> verified to have multi-threading--unless it's all bs... But Oracle
> >> last I heard was multi-process not multi-threaded...
> >
> >I know that you're statement of "hammer"ing informix is more in jest
> >than anything else... I'm not trying to hammer
> >informix/sybase/oracle. If you look closely enough, you can find
> >enough to hammer any one of them... for that matter, you can find
> >something in each to glee over... so with *that* outta da way....
> >
> >o Sybase isn't threaded in the sense of user threads as it conducts
> > its own type of thread management. IMHO, I believe that the
> > threads are too coarse to allow for a true multi-thread execution.
> >
> I'm not sure about Sybase.
>
> >o Informix isn't threaded because you have all 'em VP's running out
> > there. They aren't in the same execution space. They have their
> > own and thus there is *some* context switching. Of course Oracle
> > has a process for *everything* so that's taking context switching
> > to the max.
>
> So how do you get >1 CPU used simulatanously if you one have one UNIX
> process. Remember UNIX controls **EVERYTHING** even virtualising
> memory and I/O port usage. UNIX schedules PROCESSES to run NOT
> THREADS. In order to get >1 physical CPU used you must have >1
> process acitve. Hence Informix recommed 1 less CPU VP less than
> the number of physical CPUs (to allow other things apart from
> Informix to run).
>
> When doing I/O which is not kernel asychronous I/O than the PROCESS
> doing the I/O will be blocked. You don't want all your threads within
> that process to stop hence put the I/O thread into it's own process
> (AIO VPs). AIO VPs can be only 1 (to write to the online.log message
> file which must be a normal UNIX file...
>
> This is the least number of processes you can run i.e. most multi-
> threaded you can get under UNIX. I have seen 130 informix users with
> ~10-12 UNIX processes handling all their connections. Proof that
> Informix is truely mutli-threadeded.....
>
> >
> >With enough CPU's, though, the context switching isn't as much as an
> >issue... IMHO. You can always bind a process to a processor.
> >--
> >Pablo Sanchez | wk: 415.933.3812| pg: 800.930.5635 -or- pablo_p_at_pager.sgi.com
> >--------------+-----------------+--------------------------------------------
> >pablo_at_sgi.com ... when mailing me, place "not spam" in the Subject
>
> --
> David Williams

 David Williams wrote:
>
> In article <5n1dv1$2ar_at_mew.corp.sgi.com>, Pablo Sanchez
> <news_reader_at_mew.corp.sgi.com> writes
> >
> >In article <33935782.7D9610FC_at_devnull.org>, Tim Schaefer <devnull_at_devnull.org>
> >writes:
> >> Pablo Sanchez wrote:
> >> >
> >> > No vendor, that I know of, is truly multi-threaded... at least in the
> >> > sense of user threads and the like.
> >> > --
> >>
> >> whoa!
> >>
> >> Finally somebody mentioned the threads thing, and you shoot it down
> >> so quickly! tsk tsk.... :-)
 

> >:-)!!!! Well they'll all claim it if it's the soup of the day kinda
> >thing...
> >
> >> Yes, as much as I hammer on Informix, they are truly and independently
> >> verified to have multi-threading--unless it's all bs... But Oracle
> >> last I heard was multi-process not multi-threaded...
> >
> >I know that you're statement of "hammer"ing informix is more in jest
> >than anything else... I'm not trying to hammer
> >informix/sybase/oracle. If you look closely enough, you can find
> >enough to hammer any one of them... for that matter, you can find
> >something in each to glee over... so with *that* outta da way....
> >
> >o Sybase isn't threaded in the sense of user threads as it conducts
> > its own type of thread management. IMHO, I believe that the
> > threads are too coarse to allow for a true multi-thread execution.
> >
> I'm not sure about Sybase.
>
> >o Informix isn't threaded because you have all 'em VP's running out
> > there. They aren't in the same execution space. They have their
> > own and thus there is *some* context switching. Of course Oracle
> > has a process for *everything* so that's taking context switching
> > to the max.
>
> So how do you get >1 CPU used simulatanously if you one have one UNIX
> process. Remember UNIX controls **EVERYTHING** even virtualising
> memory and I/O port usage. UNIX schedules PROCESSES to run NOT
> THREADS. In order to get >1 physical CPU used you must have >1
> process acitve. Hence Informix recommed 1 less CPU VP less than
> the number of physical CPUs (to allow other things apart from
> Informix to run).
>
> When doing I/O which is not kernel asychronous I/O than the PROCESS
> doing the I/O will be blocked. You don't want all your threads within
> that process to stop hence put the I/O thread into it's own process
> (AIO VPs). AIO VPs can be only 1 (to write to the online.log message
> file which must be a normal UNIX file...
>
> This is the least number of processes you can run i.e. most multi-
> threaded you can get under UNIX. I have seen 130 informix users with
> ~10-12 UNIX processes handling all their connections. Proof that
> Informix is truely mutli-threadeded.....
>
> >
> >With enough CPU's, though, the context switching isn't as much as an
> >issue... IMHO. You can always bind a process to a processor.
> >--
> >Pablo Sanchez | wk: 415.933.3812| pg: 800.930.5635 -or- pablo_p_at_pager.sgi.com
> >--------------+-----------------+--------------------------------------------
> >pablo_at_sgi.com ... when mailing me, place "not spam" in the Subject
>
> --
> David Williams

Thanks David for clearing this up a bit more...

:-)

I had to go hunt down my literature to get this abit more documented so I don't just talk through my hat--or Pablos' :-)

This guy wrote a very nice report covering the differences of all the major data bases in >>>> 1993 <<<<< :

David McGoveran
Alternative Technologies
13150 Highway 9, #123
Boulder Creek, CA 95006
408-338-4621
REPORT: "An Evaluation of Database Server Architectures" Version 93.10

His report gave glowing remarks about Informix and a little bit to Sybase, but the beast was clearly the loser. I hope folks can contact this guy to get his latest report, however I have not done so, and am not able to verify if the above address is still accurate.

Here's a quote from Davids' report:

BEGIN QUOTED MATERIAL INFORMIX-OnLine Dynamic Server uses a true multi-threaded architecture. Multiple concurrent threads are scheduled based on resource availability. Although threads can be "interrupted" by a higher priority thread ( in the sense that a different thread is given the next time slice instead of the previously scheduled one), the scheduler is nonpreemtive.  Threads are scheduled independent of the platform operating system scheduling mechanism. As noted in the data base server architecture requirements discussion, resource management with true multi-threading is more efficient than a shared multi-process architecture.

END QUOTED MATERIAL In Informix's own literature, which they only allowed "partners" and internal people to read, they give a great overview of their multi-threading capability.

Try to get a copy of:
"Informix Dynamic Server Architecture Overview" Informix Part #000-20559-78 W

It clearly says on the cover "Informix Sales Kit. How to position and sell Informix Dynamic Server Overview, Versions 6.0, 7.0, and 8.0."

Even if half of what is presented is true, it blows the socks off Oracle. And thus my ever-present codependence on Informix, even with their lousy attitude these days.

:-)

BTW, Pablo, nice house! That hat though, hmmmmm....

Tim

-- 
Tim Schaefer                  \\|//               
tschaefe_at_mindspring.com       (6 6)               
------------------------oOOo---( )---o00o---------
http://www.inxutil.com