Last Thursday I attempted to take apply the 8.1.6.3 patchset on top of a small 8.1.6.0 database. I had done this many times before; the four hours I alloted to backing up the system and applying the patch were an hour more than I needed. The patch installed without incident, but when I ran catalog.sql it hung. I checked v$session_wait, but for some reason didn't check the alert log which would have told me what was wrong. Time was running out. I called Oracle told them my problem. Explained that this was a downed production database, but the call screener made it priority 2. I called the analyst and kept on getting a message saying he was either on the phone or simply gone. I did not know the screener had made it a priority 2 problem, and thought, "Perhaps he was on the phone discussing the problem." My phone began to ring off the hook with people asking, "Where's the database?" I had backed up all the software as well as the database files. I began the restore saying to replace all the files. However when the restore go to an uneeded file, one of the .aud files in rdbms/audit, it hung. I needed to resintall the software from CD. The database base was recovered without incident. A few hours after it had been promised but unpatched. What was the problem? I use triggers on such system events as servererror to send pages and record informatiuon in a log table. These triggers can interfere with the running of scripts such as catalog.ora. The solution is to set the initilization parameter _SYSTEM_TRIG_ENABLED to false during an upgrade. My fun for the week was not over. This weekend we moved a large number of servers to a new UPS including all the Oracle servers. When I attempted to bring up the main database, a "cannot stat file ...." message was received. I called the sysadmin who had brought up the system. He said the file system was gone. I explained that it was there when the system was shutdown the night before. He asked for details so that he could recreate it. Luckily a more senior sysadmin looked at the problem and found that the raid configuration had a mismatch on which controller was assigned to the file system, straigtened that out, and the database came up without incident. Ian MacGregor Stanford Linear Accelerator Center [EMAIL PROTECTED] -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: MacGregor, Ian A. INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
