Re:RE: Oracle and Tru64

I never saw Ultrix but have heard other horror stories on this list and elsewhere.

My first exposure to Dec was in '93 on the brand new Alpha's running openVMS. 64 bit and VLM long before any other vendor (and long before Oracle supported 64 bit, unfortunately)...and if the DEC wire-heads I worked for were right, a superior implementation of RISC architecture. Later on, we had to migrate our application to OSF which very soon after was renamed DEC Unix...which COMPAQ marketing renamed TRU64. Very fast and reliable. Now I get to do another platform migration in my spare time...

Kip Bryant

|Guess we had different experiences. OSF was being
|replaced in favor of digital unix when I started my
|sys admin days on DECs. They were also Oracle's
|preferred platform at the time. Things have changed a
|lot since then.

|--- dgoulet_at_vicr.com wrote:
|> Peter,
|>
|> Please allow me to disagree. I came from the
|> USAF with a very deep love for
|> DEC hardware and software (VAX/VMS), only to be VERY
|> disappointed by them when I
|> was presented with DEC Ultrix. Their straying into
|> the Unix world was a real
|> nightmare. First off their sales folks over sold
|> the capabilities of the
|> 5000/240 workstation. A database server it was not.
|> Ultrix was a failure right
|> out of the gate. That monster combination was a
|> guarantee that I would get a
|> page every night that it was here and the server a
|> re-boot. It finally took me
|> three years to get a Ultrix tech to admit that they
|> had not implemented a
|> TCP_KEEP_ALIVE capability into Ultrix and that I
|> would never see it. At that
|> time the only path was to upgrade to an Alpha with
|> OSF-1 which was crashing on a
|> daily basis. Oracle back then recommended a cold
|> backup of the database twice a
|> day. One of the soccer dads whose's daughter was on
|> the same team as mine was a
|> DEC/Compaq employee. His recommendation was to stay
|> away from OSF at all costs.
|> He was one of the lucky ones when Compaq sold off
|> the CASE tools operation. Oh
|> how I would have loved moving back onto a VAX, but
|> DEC was not interested in
|> that platform any more and HP's 9000 platform was
|> not only cheaper to acquire
|> and support, but faster and more capable as well.
|> We benchmarked a DEC Ultrix
|> box specifically tailored by DEC to database work
|> against an HP9000 that 'just
|> happen to between owners'. The DEC was a multi
|> processor unit, stuffed with
|> every bite of RAM it could hold, multi scsi ports
|> with load balancing on their
|> (at that time) best disk system and a custom Oracle
|> install with a highly tuned
|> (by DEC engineers) Ultrix kernel. We passed then a
|> dmp file with 1 million rows
|> of data for two tables and 4 SQL scripts to run
|> against the data. Took them all
|> day to get the results. Did the same test with the
|> HP that had minimal RAM, one
|> scsi port and only the internal drives and a default
|> Oracle install and only
|> that tweaking of the HP kernel in Oracle's install
|> manual. Same test ran in 4.5
|> hours hands down. I left DEC behind at that time,
|> never to return. As of
|> today, I love the HP's I have to work with. I do
|> not believe them to be
|> outclassed anywhere and that they do outclass all in
|> terms of reliability and
|> dependability. I must admit to really enjoying a
|> server platform that does it's
|> job day in and day out for months or years without
|> so much as a burp. I'm sure
|> that part of that are three very good SA's, but the
|> hardware/OS speaks for
|> itself as well.
|>
|> I did not shed one tear when DEC fell to Compaq,
|> and will not now that
|> Compaq is falling to HP. I am sure that the good of
|> DEC/Compaq will find it's
|> way into HP-UX as well as the HP9000 series. So
|> we've only good things to look
|> forward to.
|>
|> Dick Goulet
|>
|> ____________________Reply
|> Separator____________________
|> Author: Peter Barnett <regdba_at_yahoo.com>
|> Date: 6/4/2002 8:08 AM
|>
|> It's a shame that Digital had such good computer
|> scientists and such lousy marketing. Digital Unix
|> and
|> the AlphaServer were the most stable Unix boxes in
|> the
|> world. Compaq never did understand the gem it
|> purchased and HP will never admit that their current
|> generation of hardware was outclassed by Digital 10
|> years ago.
|>
|> All good runs must come to an end. It is just too
|> bad
|> that the end is an execution by technical nitwits.
|>
|>
|> --- DENNIS WILLIAMS <DWILLIAMS_at_LIFETOUCH.COM> wrote:
|> > Stephane, Hemant
|> > Below is the official word that I pulled off
|> HP's
|> > website. It is
|> > straight PR material, so read between the words as
|> > you choose. As I recall,
|> > Compaq had already decided not to build the
|> > next-generation Alpha chip
|> > before the merger arose. If you are interested, I
|> > would suggest that you
|> > attend the HP roadshow when it comes to a city
|> near
|> > you and ask them the
|> > hard questions yourself. Having worked for a
|> > computer manufacturer in the
|> > past, I can assure you that the manufacturer would
|> > appreciate it if you
|> > bought the last system to come off the production
|> > line, then never called
|> > them for support. My company plans to continue
|> > operating our Tru64 systems
|> > for several years to come, and they have provided
|> > wonderful service. But
|> > we're purchasing new Sun systems.
|> >
|> > "In this session, an HP Executive will highlight
|> the
|> > important current and
|> > future role HP's business critical and high
|> > performance AlphaServer(tm)
|> > products play. We will also discuss the latest
|> > advancements across the hp
|> > AlphaServer product family, the latest on the
|> future
|> > ItaniumR processor
|> > family, and provide an update on the related
|> > operating systems strategy. In
|> > particular, we will share the updated OpenVMS(tm)
|> > roadmap for continued
|> > development and support on the AlphaServer
|> platform
|> > as well as a review of
|> > the progress to date for porting OpenVMS to
|> > ItaniumR-based systems.
|> > Discussion will also include the most
|> > up-to-the-minute plans for integrating
|> > Tru64(tm) UNIXR into HP-UX on the ItaniumR
|> > architecture and the continued
|> > development and support of Tru64 UNIX on the
|> > AlphaServer platform."
|> >
|> > Dennis Williams
|> > DBA
|> > Lifetouch, Inc.
|> > dwilliams_at_lifetouch.com
|> >
|> >
|> > -----Original Message-----
|> > Sent: Monday, June 03, 2002 9:53 AM
|> > To: Multiple recipients of list ORACLE-L
|> >
|> >
|> >
|> > I'd never heard that Oracle has stopped
|> > or is stopping support for Tru64.
|> > We have more than 35 production databases
|> > on Tru64 and have no intention of moving
|> > out of Alpha-Tru64 in a hurry. We're even
|> > looking at upgrading a mission critical
|> > 8iOPS cluster on Tru64 to 9iRAC on Tru64.
|> >
|> > Hemant K Chitale
|> >
|> > ----- Original Message -----
|> > To: "Multiple recipients of list ORACLE-L"
|> > <ORACLE-L_at_fatcity.com>
|> > Sent: Sunday, 02 June, 2002 9:28 PM
|> >
|> >
|> > > Stephane Faroult wrote:
|> > >
|> > > > ...Historically, Oracle was a port to
|> > > > Digital (remember this brand?)
|> > >
|> > > Interesting. I'm reading this list because of a
|> > recent
|> > > project to retire the Digital-Alpha
|> workstations.
|> > > The main reason that these machines must be
|> > de-commissioned is
|> > > because Oracle stopped supporting Tru64.
|> > > (Although it needs to be done EVENTUALLY, since
|> > Alpha
|> > > is basicly dead anyway.)
|> > >
|> > > The Alphas were bought to retire the VMS from
|> 4-7
|> > years ago!
|> > >
|> > > Talk about unfortunate planning!
|> > > --
|> > > Aaron Birenboim | The top three attributes of a
|>
|=== message truncated ===

|=====
|Pete Barnett
|Lead Database Administrator
|The Regence Group
|pnbarne_at_regence.com

|__________________________________________________
|Do You Yahoo!?
|Yahoo! - Official partner of 2002 FIFA World Cup
|http://fifaworldcup.yahoo.com
|--
|Please see the official ORACLE-L FAQ: http://www.orafaq.com
|--
|Author: Peter Barnett
| INET: regdba_at_yahoo.com

|Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
|San Diego, California -- Public Internet access / Mailing Lists
|--------------------------------------------------------------------
|To REMOVE yourself from this mailing list, send an E-Mail message
|to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
|the message BODY, include a line containing: UNSUB ORACLE-L
|(or the name of mailing list you want to be removed from). You may
|also send the HELP command for other information (like subscribing).

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: 
  INET: Kip.Bryant_at_Vishay.com

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).