Hello again! See below for original story/question. Thanks to Hans Engren [hans@swip.net] who told me this: ------------ In version 8.0.X up to 8.1.6 of Oracle, there is a problem running it on Solaris/UNIX. If your system clock ticks is set to milliseconds, the bug affects systems with uptime of 24.8+ days, while centiseconds configured (which is default and quite normal) will translate to 248 days. The bug affects start/stop of Oracle if the uptime is higher than the above mentioned. A better description of the bug would be a timer overflow, which causes background processes to loop forever after this amount of uptime. This is reported by Oracle support, document ID 118228.1 (aswell as Oracle bugID# 1084273). The solution to the problem is either to reboot the system every 247:th day (or every 24th depending on your clock settings) or patch it with any of the available patches that solves this problem. If I remember correctly, patch #1265297 would be the correct patch for 8.0.6 to solve this problem. Hope this helps, -- Hans. ------------ I have not applied the patch yet, but I made some counting... Last time the machine was rebooted was Oct 4 2001. Counting days we come to 248 days on June 9 or 10. The day of the hang was - of course - June 10! I am quite sure this patch will help me. Thanks /jonas -----Ursprungligt meddelande----- Fren: Jonas Bleberg Skickat: den 20 juni 2002 09:25 Till: sunmanagers@sunmanagers.org Dmne: oracle hang hello! A week ago I had a strange hang and I cannot decide what caused this hang. This might look like an oracle problem, but I think this has something to do with the operating system. Well, here is the long story: On this machine (a rather stripped Solaris 7 on a 420R) we have 7 separate instances of Oracle 8.0.6 (which should be better patched). All of the instances are using the same installation. The instances are not logically connected to each other. The problems were recognized for one of the database instances where sqlplus sessions, connecting each 10 minutes, were hanging, and the web application was not working very well. Then I tried to shut down the database instance using shutdown immediate, which was not working. I had to use shutdown abort. I tried to start the database instance once more, and it hang when trying to mount. I restored the database files from a backup and used recover to redo all transactions. And the database was up and running. Great! I made a full export of the database using exp (there is not lot of data in this database). Then I tried to restart the database instance once more. But the shutdown immediate just hang, and I had to use shutdown abort as the first time. I also tried to recreate the control file with the same result. Ok I have an export file, let's make a brand new database instance instead of the old one! So I created a new database, tablespaces and so on. In the middle of executing catalog.sql the svrmgrl process just hang, and I had to abort the creation. I removed that one, and desperately created another database instance. This time the database creation hang during the first statement; "create database". I checked the mem for runaway memory using ipcs -a, but I could not see anything remarkable. The number of oracle owned shared memory chunks were related to the number of oracle instances. I decided I had to reboot the machine, to hopefully get rid of all problems. When shutting down using init 6, all 6 remaining database instances hang when till kill script running shutdown immediate. I had to manually kill the svrmgrl process for each database instance to let the init 6 process continue. When the machine was up and running again all database instances were started ok, and I was able to create a new database, import the export file, and everything was ok again. Finally to my question: What could have caused the hang? I come to the conclusion that this is something operating system related or resource related since there was the same problem with all database instances. And some additional non-info; there were no messages on the console, in messages file. The memory usage was normal. This is the first time this error occurs. I will summarize. Hopefully there is something to summarize... /jonas Jonas Bleberg Cell Network Sverige AB Kruthusgatan 17,6 S-411 04 Gvteborg jonas.blaberg@cellnetwork.com @office: +46-(0)31-739 84 54 <----- Number has changed! not@office: +46-(0)709-95 00 68 _______________________________________________ sunmanagers mailing list sunmanagers@sunmanagers.org http://www.sunmanagers.org/mailman/listinfo/sunmanagers _______________________________________________ sunmanagers mailing list sunmanagers@sunmanagers.org http://www.sunmanagers.org/mailman/listinfo/sunmanagersReceived on Thu Jun 20 04:25:50 2002
This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:42:47 EST