Re: Re:RE: Is this a well known ORACLE bug? Max uptime < 1 year

Wasn't the tread about Oracle on Solaris? You lucky guy running under HP-UX ;-)

Eric Lansu

• Original Message ----- From: <dgoulet_at_vicr.com> To: "Multiple recipients of list ORACLE-L" <ORACLE-L_at_fatcity.com> Sent: Monday, 28 August 2000 16:27 Subject: Re:RE: Is this a well known ORACLE bug? Max uptime < 1 year

> For the most part, I've not been too interested in this thread, But for
some
> weird reason this morning I read it and have to disagree. According to
what is
> written here we should see problems after 16.3 months of uptime on the
system
> (I'm on HP). Well if this is the case, how come one of my systems that
was up
> for 2 full years prior to Y2K did not have a single problem??? We had
Oracle
> 7.2 running on there. Something here does not wash.
>
> Dick Goulet
>
> BTW: That was an OLD HP9000/847 running HP-UX 9.02. Thankfully it retired
on 1
> Dec 1999 and we just let it run through 1 Jan 2000 to see what would
happen.
> Result: NOTHING, stayed up running just fine. (OS & Oracle) What a NON
event.
>
> ____________________Reply Separator____________________
> Author: "MacGregor; Ian A." <ian_at_SLAC.Stanford.EDU>
> Date: 8/25/00 3:14 PM
>
> Woah! I thought this was an Oracle 8 bug, are you now dragging Oracle 7
> into the picture?
>
> -----Original Message-----
> Sent: Friday, August 25, 2000 12:50 PM
> To: Multiple recipients of list ORACLE-L
>
>
> Hi,
>
> This is what I found out. The problem is with all versions of Oracle
> on Solaris 2.6. ( Fixed in 8.1.7 ) 64bit versions of Solaris ( 2.7 and
> above ) should not have this problem. Anyway this problem has only been
> reported on 2.6 and the patch is only available for that platform and
> version.
>
> Oracle uses the times system call and it returns a long ( structure
> clock_t ). On 32bit Solaris the maximum value can only be 2^31 but on
> 64bit Solaris it can be 2^63. I also checked on HP and it returns an
> unsigned integer ( both 32 and 64 bit ) and this problem should occur
> only after 497 days of uptime.
>
> Regards,
> Denny
>
> "Adams, Matthew (GEA, 088130)" wrote:
> >
> > Is this bug specific to Solaris?
> > I ask because on the bug header it list platform as solaris, but
> > it also lists affected platforms as generic.
> >
> > I tried to ask that question on one of the metalink forums, but
> > keep getting an error.
> >
> > > -----Original Message-----
> > > From: Paul van Dijken [mailto:paul.vandijken_at_sema.nl]
> > > Sent: Wednesday, August 23, 2000 8:48 AM
> > > To: Multiple recipients of list ORACLE-L
> > > Subject: RE: Is this a well known ORACLE bug? Max uptime < 1 year
> > >
> > >
> > > From another Oracle list:
> > >
> > > >
> > > > It's a legitimate bug (1084273/1227119) that is Solaris-specific.
> > > > There is a patch available for it outside of 8.1.7, however. The
> > > > patch is available on oracle-ftp.oracle.com under
> > > > /server/outgoing/SUN_SOLARIS2/BUG1227119
> > > >
> > > > The analyst said that the patch is for the 32-bit version, and is
> > > > checking to see if the patch needs to be applied to the 64-bit
> > > > version as well.
> > > >
> > >
> > > Since most systems have booted on january, 1, 2000, You can
> > > expect the first
> > > effects on September 4, 2000 around noon.
> > >
> > > Paul
> > >
> > > -----Original Message-----
> > > Sent: 23 August 2000 11:02
> > > To: Multiple recipients of list ORACLE-L
> > >
> > >
> > > Dear listers,
> > >
> > > From another system we learned that ORACLE 8.0.5
> > > should not be started if the unix (Sun ?) has
> > > been running for a very long time.
> > >
> > > Instead you should boot the unix first.
> > >
> > > uptime is the magic command giving you the
> > > number of days since the last boot.
> > >
> > > I tried to figure out what goes wrong and
> > > my theory is this: Unix keeps and ORACLE gets
> > > the value of uptime as 1/100 of a second.
> > > Max (signed int) = 2^31 corresponds to 248,55
> > > days (as 1/100 seconds). Then unsigned int
> > > is interpreted by ORACLE as negative =>
> > >
> > > 2698: sigprocmask(SIG_UNBLOCK, 0xEFFFE420, 0x00000000) = 0
> > > 2698: setcontext(0xEFFFE4F0)
> > > 2690: semop(524288, 0xEFFFE808, 1) (sleeping...)
> > > 2694: Received signal #14, SIGALRM, in semop() [caught]
> > > 2694: semop(524288, 0xEFFFE808, 1)
> > > Err#91 ERESTART
> > > 2694: sigprocmask(SIG_BLOCK, 0xEFFFE420, 0x00000000) = 0
> > > 2694: times(0xEFFFE3B0) =
> > > -1944987590
> > > 2694: setitimer(ITIMER_REAL, 0xEFFFE3B0, 0x00000000) = 0
> > > 2694: sigprocmask(SIG_UNBLOCK, 0xEFFFE420, 0x00000000) = 0
> > > 2694: setcontext(0xEFFFE4F0)
> > > 2706: Received signal #14, SIGALRM, in semop() [caught]
> > > 2706: semop(524288, 0xEFFFE808, 1)
> > > Err#91 ERESTART
> > > 2706: sigprocmask(SIG_BLOCK, 0xEFFFE420, 0x00000000) = 0
> > > 2706: times(0xEFFFE3B0) =
> > > -1944987544
> > >
> > > We were told that this has been fixed in 8.1.7
> > > but can that be true ?
> > >
> > > Do you know this ? Is this a problem in 8.0.5.2 or
> > > 8.0.6 or 8.1.6 ?
> > >
> > > There is a bell ringing somewhere in the back of my head someone on
> > > this list wrote something about rebooting at least ones a
> > > year. Is this
> > > related?
> > >
> > > Best regards / Met vriendelijke groeten / Ystävällisin terveisin
> > >
> > > Eric Lansu
>
> --
> Denny Koovakattu
> http://www.vitalsol.com/
> http://www.oneco.net/
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
> --
> Author: Denny Koovakattu
> INET: denny_vk_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).
> --
> Author: MacGregor, Ian A.
> INET: ian_at_SLAC.Stanford.EDU
>
> 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).
>
> --
> Author:
> INET: dgoulet_at_vicr.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
Received on Tue Aug 29 2000 - 00:52:44 CDT