Message-Id: <10602.115699@fatcity.com> From: "Eric Lansu" Date: Tue, 29 Aug 2000 07:52:44 +0200 Subject: 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: To: "Multiple recipients of list ORACLE-L" 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." > 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@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@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@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@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@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@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@fatcity.com (note EXACT spelling of 'ListGuru') and in > the message BODY, include a line containing: UNSUB ORACLE-L