/******************************************************************************* / /* Document : Just a listing of a number of ORA- messages that you might * / /* encounter using Oracle RDBMS 9i, 10g, 11g. * / /* Doc. Version : 11 * / /* File : oracle_ora_messages.txt * / /* Purpose : providing some info on ORA- messages/errors, and * / /* possible solutions. * / /* This note is not meant to be a "reference" of any kind. * / /* It's just a very dumb collection of some ORA- errors * / /* and possible solutions. * / /* Date : 21-04-2009 * / /* Compiled by : Albert * / /* * / /* Best use : Just use find/search of your editor, to search * / /* for a keyword or ORA- number. * / /* Because such a ORA- message can be repeated many times in * / /* this document, it's advisable to search troughout the * / /* whole document (search multiple times). * / /******************************************************************************* /

################################################################################ #################### SECTION 1: Introduction - Probably a few of the most common (and simplest) Oracl e error codes: ################################################################################ #################### Although there are a couple of thousends of ORA- (error-) messages, the list bel ow shows (some) of the most common ones. ORA-00001 ORA-00600 ORA-03113 tion) ORA-03114 Unique constraint violated. (Invalid data has been rejected) Internal error (general identifier of some internal error) End-of-file on communication channel (you have lost the Network connec Not connected to ORACLE

ORA-00942 ORA-01017 ORA-01031 ORA-01034 ORA-01401 r column) ORA-01403 ORA-01555 has been ORA-12154 ORA-12203 ORA-12500 ORA-12545 ORA-12560

Table or view does not exist Invalid Username/Password Insufficient privileges Oracle not available (the database might be down) inserted value too large for column (or ORA-12899: value too large fo No data found Snapshot too old (Long running Query terminates, because Rollback/Undo overwritten) TNS:could not resolve service name TNS:unable to connect to destination TNS:listener failed to start a dedicated server process" TNS:name lookup failure" TNS:protocol adapter error"

Other prefix codes PLS-????? MOD-????? FRM-????? SQL-Loader-??? IMP-????? EXP-????? RMAN-????? ry tool) PL/SQL Error SQL Module error Oracle Forms error SQL Loader error Import error Export error RMAN messages (the 8i,9i,10g,11g main backup, restore, and recove

But there exists more categories. >> How do you "see" or find the ORA- errors? There are two main situations where you can be confronted with ORA- error messag es: - You might find them in the main logfile of an Oracle instance, namely the "ale rt.log" of the database which usually has a filename like "alert.log", like for exampl e "alertSALES.log". (In older versions of Oracle, and 9i, and 10g, the alert.log file is a simple ascii and thus readable file. In Oracle 11g, the situation is a little more complex. This wi ll not be the subject of this note. But in SECTION 4 you will find an article called "11g Diagnosab ility: Frequently Asked Questions"). - They might appear when you are working with a tool,like "sqlplus", and you wer e "doing something", that lead to some sort of error condition, and that the database reacted upon with an ORA- message. Usually, those messages (the more serious ones) are also written in the "alert.log" file. In fact, the ORA- messages that may arise because you are doing something that the database does not "like" much at that time, will probably N OT logged into the alert.log if the errorcondition only affects your session. But if (whatever yo u were doing), had any "database wide" impact, it will probably be logged in the alert.log fi le as well.

Simply put: you will see them on your screen (working with some application or t ool) when an error condition arose. Or you may find them when you inspect the alert.log file.

The ORA-600 or ORA-00600 error is a special type of general message, alerting yo u to "some serious internal error". It can be so that a "bug" has revealed itself and leads to a condition where the database throws this error to the alertlog. Or there was a some other sort of condition, severel y enough, to show this error. You cannot tell much from the ORA-600 iself. But it is almost always accompanied with a list of arguments, and some descriptive text, like in the following example: ksedmp: internal or fatal error ORA-00600: internal error code, arguments: [12700], [3383], [41957137], [44], [] , [], [], [] New to Oracle 11g are the ORA-700 errors or "soft asserts". ORA-700 errors are referred to as soft asserts in 11g. Basically these are inte rnal errors that do not cause anything fatal to occur in the process, and so the process can cont inue. You might consider them to be like "mild or soft" ORA-600 errors.

################################################################################ #################### SECTION 1: Notes about a number of important ORA- and ORA-600 messages. ################################################################################ ####################

======================================================================= Notes Related to ORA-1110 & ORA-1113 & ORA-1547 & ORA-1194 & ORA-1195: ======================================================================= ----Note: ----Applies to: Oracle Server - Enterprise Edition - Version: 9.0.1.0 to 10.2.0.1 Information in this document applies to any platform. Goal The goal of this article is to assist DBA's who encounter the ORA-1110, and to p oint them in the right direction. Several notes have been referenced depending on the subsequent errors. If the DBA is unable to resolve the issue after reading the appropriate note, a script to collect

diagnostic information has been provided below. The output of this script should be uploaded into the service request. Solution How to troubleshoot and resolve an ORA-1110 Definition Error: ORA 1110 Text: datafile : ------------------------------------------------------------------------------Cause: This message reports the filename involved with other messages. Action: See the associated messages for a description of the problem. The ORA-1110 displays the physical datafile in which Oracle is having a problem accessing. The ORA-1110 is followed by one or more messages. These messages may be Oracle s pecific messages or be related to the operating system. The first aim is to identify all error messages encounted prior to addressing th e issue: Below is a list of the common errors that may follow the ORA-1110. ORA-1157 ORA-1578 ORA-376 ORA-1194 ORA-1547 Addressing "cannot identify datafile - file not found" "ORACLE data block corrupted (file # %s, block # %s)" "file cannot be read at this time" "file needs more recovery to be consistent" "warning: RECOVER succeeded but OPEN RESETLOGS would get error" an ORA-1157 (cannot identify datafile - file not found)

Note 184327.1 covers the ORA-1157 in greater detail. Addressing an ORA-1578 (ORACLE data block corrupted (file # %s, block # %s)) Note 28814.1 covers the ORA-1578 in greater detail. Addressing an ORA-376 (file cannot be read at this time) Note 183327.1 covers the ORA-376 in greater detail. Addressing an ORA-1194 (file needs more recovery to be consistent) & ORA1547 (warning: RECOVER succeeded but OPEN RESETLOGS would get error) Note 435201.1 covers the ORA-1194 & ORA-1547 in greater detail. After following the above notes if you are not able to restore, recover and open the database please run the following script below. Please provide the output in the service request that you may raise. (upload re

covery_info.txt) set pagesize 20000 set linesize 180 set pause off set serveroutput on set feedback on set echo on set numformat 999999999999999 Spool recovery_info.txt select substr(name, 1, 50), status from v$datafile; select substr(name,1,40), recover, fuzzy, checkpoint_change# from v$datafile_header; select GROUP#,substr(member,1,60) from v$logfile; select * from v$recover_file; select distinct status from v$backup; select hxfil FILENUMBER,fhsta STATUS,fhscn SCN,fhrba_Seq SEQUENCE from x$kcvfh; select distinct (fuzzy) from v$datafile_header; spool off exit Keywords ORA-00376 ; ORA-01113 ; ORA-01157 ; ORA-01194 ; ORA-01547 ; ORA-01578 ; ORA-1113 ; ORA-1157 ; ORA-1194 ; ORA-1547 ; ORA-1578 ; ORA-376 ----Note: ----Subject: Doc ID: DIAGNOSING ORA-1547 & ORA-1194 ERRORS DURING RECOVERY 435201.1 Type: HOWTO

Applies to: Oracle Server - Enterprise Edition - Version: 9.0.0 to 10.2.0 Information in this document applies to any platform. Goal The following note provides an example of ORA-1157 & ORA 1194 and how to resolve it. Error message descriptions ORA 1157 Text: warning: RECOVER succeeded but OPEN RESETLOGS would get error ------------------------------------------------------------------Cause: The background process was not able to find one of the datafiles. The database will prohibit access to this file but other files will be unaffected. However, the first instance to open the database will need to access all online datafiles.

Accompanying messages from the operating system will describe why the file was not found. ORA 1194 Text: file needs more recovery to be consistent -----------------------------------------------------Cause: An incomplete recovery session was started, but an insufficient number of redo logs were applied to make the file consistent. The named file was not closed cleanly when it was last opened by the database. The most likely cause of this message is forgetting to restore the file from a backup before doing incomplete recovery. Solution Errors ORA-1157 & ORA 1194 are commonly received together following a recovery a ttempt. SQL> recover database using backup controlfile until cancel ORA-00279: change 2008250 generated at 06/07/2007 11:50:32 needed for thread 1 ORA-00289: suggestion : /recovery_area/V102/archivelog/2007_06_07/o1_mf_1_2_%u_.arc ORA-00280: change 2008250 for thread 1 is in sequence #2 Specify log: {=suggested filename AUTO CANCEL} cancel ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below ORA-01194: file 3 needs more recovery to be consistent ORA-01110: data file 3: '/oradata/V102/sysaux01.dbf' Following this error message issue the following SQL command, you will most comm only find at least one datafile which is in FUZZY mode. SQL> select file#,STATUS, FUZZY from v$datafile_header; FILE# STATUS FUZ -------- ------------ -----1 ONLINE NO 2 ONLINE NO 3 ONLINE YES 4 ONLINE NO This example shows file#3 in fuzzy mode. The best solution at this point is to apply more archivelogs in order to get off ending datafile/s out of FUZZY mode. In many cases the recovery session may be requesting an archivelog which has not been generated. The reason for this is because the recovery clause included "using backup contro lfile" If this is the case you need to apply the current online redo log to complete th e recovery:

This command below will return the current online redo log/s. SQL> select member from v$logfile lf , v$log l where l.status='CURRENT' and lf.g roup#=l.group#; then proceed to issue: SQL> recover database using backup controlfile until cancel; When the recovery session prompts for an archive log specify the online redo log from above and hit enter. This should complete the recovery and then you will be able to op en the database. SQL> alter database open resetlogs; Note: If after applying all archive logs and online redo logs the database does not op en please provide the following script output to Oracle support to assist with the recover y. ( Please upload recovery_info.txt) set pagesize 20000 set linesize 180 set pause off set serveroutput on set feedback on set echo on set numformat 999999999999999 Spool recovery_info.txt select substr(name, 1, 50), status from v$datafile; select substr(name,1,40), recover, fuzzy, checkpoint_change# from v$datafile_header; select GROUP#,substr(member,1,60) from v$logfile; select * from v$recover_file; select distinct status from v$backup; select hxfil FILENUMBER,fhsta STATUS,fhscn SCN,fhrba_Seq SEQUENCE from x$kcvfh; select distinct (fuzzy) from v$datafile_header; spool off exit ----Note: ----Problem: ======== When you startup your database, the mount is successful but the database fails to open with the following error: ORA-1571 redo version 8.0.5 incompatible with Oracle Version 8.0.0 Since the error is misleading, you try to recover until cancel and open the database with the ResetLogs option. When you apply the online redo

logs, you get the following stack of errors: recover database until cancel; -> apply log1orcl.ora ORA-331 log version 8.0.5 incompatible with Oracle version 8.0.0 ORA-334 archived log: log1orcl.ora ORA-1547 "warning: RECOVER succeeded but OPEN RESETLOGS would get error below" ORA-1194 file #1 needs more recovery to be consistent ORA-1110 file .. Solution: ========= Edit the init.ora file and assign the correct value to the COMPATIBLE parameter. Make this parameter the same as the database version. Explanation: ============ This problem occurs when your database is shutdown with the abort option and the compatible setting is commented out or changed to a lower value inside the init.ora file. If the compatible parameter inside the init.ora file is changed to a lower value or commented out, then this error appears when the redo log files are open ed

----Note: ----Important: Always be sceptical with advice and solutions from any type of docume nt (including this one). Suppose the system comes with: ORA-01194: file 1 needs more recovery to be consistent ORA-01110: data file 1: '/u03/oradata/tstc/dbsyst01.dbf' Either you had the database in archive mode or in non archive mode: archive mode RECOVER DATABASE UNTIL CANCEL USING BACKUP CONTROLFILE; ALTER DATABASE OPEN RESETLOGS; non-archive mode: # RECOVER DATABASE UNTIL CANCEL USING BACKUP CONTROLFILE; ALTER DATABASE OPEN RESETLOGS; If you have checked that the scn's of all files are the samed number, you might try in the init.ora file:

_allow_resetlogs_corruption = true You should be fully aware of what this init.ora parameter does with your instanc e. If you are not aware of the impact, please investigate that first. ----Note: ----Doc ID: Note:41767.1 Subject: ORA-600 [1113] "Parent SO is free when adding a child" Type: REFERENCE Status: PUBLISHED Content Type: TEXT/PLAIN Creation Date: 23-JAN-1997 Last Revision Date: 29-OCT-2002 Note: For additional ORA-600 related information please read [NOTE:146580.1] PURPOSE: This article discusses the internal error "ORA-600 [1113]", what it means and possible actions. The information here is only applicable to the versions listed and is provided only for guidance. ERROR: ORA-600 [1113][a][b][c][d][e] VERSIONS: versions 7.3.X to 8.1.7 DESCRIPTION: We are freeing a state object but it already appears to be on the free list. This is generally an in memory (SGA) corruption or due to a bug in mishandling the state objects. FUNCTIONALITY: STATE OBJECT MANAGER IMPACT: PROCESS FAILURE POSSIBLE INSTANCE FAILURE IF DETECTED BY PMON PROCESS NON CORRUPTIVE - No underlying data corruption. SUGGESTIONS: For repeatable occurrances and further analysis, please submit the trace files (include any PMON traces also) and alert.log to Oracle Support Services. Known Issues: Bug 425862: ORA-600 [1113] OR [KSSRMP1] WHEN SELECTING FROM V$PWFILE_USERS fixed in 8.0.6 and 8.1.6 releases. Workaround is to use ORDER BY clause in the select statement. Bug 1307247: ORA-600 [1113] WHEN AN ANALYZE OPERATION FAILS OR IS CANCELLED fixed in 8.0.6.3, 8.1.7.1 and 9.0.0 releases. REFERENCES: [NOTE:139162.1] ORA-600 [kssrmp1]

----Note: ----Problem Description ------------------You restored your hot backup and you are trying to do a point-in-time recovery. When you tried to open your database you received the following error: ORA-01195: online backup of file needs more recovery to be consistent Cause: An incomplete recovery session was started, but an insufficient number of redo logs were applied to make the file consistent. The reported file is an online backup that must be recovered to the time the bac kup ended. Action: Either apply more redo logs until the file is consistent or restore the file from an older backup and repeat the recovery. For more information about online backup, see the index entry "online backups" in the STARTUP MOUNT SVRMGR> ALTER DATABASE DATAFILE '[datafile_name]' OFFLINE; SVRMGR> RECOVER TABLESPACE [rollback_tablespace_name]; SVRMGR> ALTER TABLESPACE [rollback_tablespace_name] ONLINE; SVRMGR> ALTER ROLLBACK SEGMENT [rollback_segment_name] ONLINE; 3) reapply the ROLLBACK_SEGMENTS parameter in INIT.ORA for future instance startups When the above steps do not help in bringing the rollback segments online again, you can follow the steps in: drop the rollback tablespace. ----Note: ----if you cannot open the database, because a datafile needs recovery (and you do n ot have the corresponding archive logs), this method only helps IF YOU CAN AFFORD TO LOOSE T HAT DATAFILE. symptom: Database startup fails symptom: ORA-01113: file %s needs media recovery symptom: ORA-01110: data file %s: '%s' symptom: Database in archive log mode symptom: Backup available symptom: Datafile requiring media recovery is not needed change: The following command was issued: SQL> alter database datafile offline; cause: Datafile was taken offline while the database was up. Therefore, the database is expecting media recovery for that datafile.

fix: Do the following only if the datafile requiring recovery is not needed and can be dropped. 1. Mount the database: SVRMGR> startup mount pfile=xxxxx.ora 2. Offline drop the datafile needing media recovery: SVRMGR> alter database datafile 'full path filename' offline drop; 3. Open the database:

SVRMGR> alter database open; 4. Export the objects out of the remaining datafiles belonging to the affected tablespace. 5. Drop the affected tablespace: SVRMGR> drop tablespace including contents; 6. Recreate the tablespace. 7. Import the objects into the new tablespace from the export dump file. Please note that this will only work if the tablespace remains online. If it is taken offline for any reason (eg manually, by ALTER TABLESPACE xxxx OFFLINE IMMEDIATE, or automatically by Oracle) then you will not be able to bring it back online unless you recover ALL the datafiles. ----Note: -----

Subject: How to recover and open the database if the archivelog required for re covery is either missing, lost or corrupted? Doc ID: Note:465478.1 Type: HOWTO Last Revision Date: 28-MAY-2008 Status: PUBLISHED In this Document Goal Solution References

Applies to: Oracle Server - Enterprise Edition - Version: 8.1.7.4 to 11.1 Information in this document applies to any platform. Goal How to recover and open the database if the archivelog required for recovery is either missing, lost or corrupted? Solution The assumption here is that we have exhausted all possible locations to find ano ther good and valid copy or backup of the archivelog that we are looking for, which could be in one of the following: directories defined in the LOG_ARCHIVE_DEST_n another directory in the same server or another server standby database RMAN backup OS backup If the archivelog is not found in any of the above mentioned locations, then the approach and strategy on how to recover and open the database depends on the SCN (System Change Number ) of the datafiles,

as well as, whether the log sequence# required for the recovery is still availab le in the online redologs. For hen are ly) the SCN of the datafiles, it is important to know the mode of the database w the datafiles backed up. That is whether the database is open, mounted or shutdown (normal when the backup is taken.

If the datafiles are restored from an online or hot backup, which means that the database is open when the backup is taken, then we must apply at least the archivelog(s) or redol og(s) whose log sequence# are generated from the beginning and until the completion of the said backup tha t was used to restore the datafiles. However, if the datafiles are restored from an offline or cold backup, and the d atabase is cleanly shutdown before the backup is taken, that means that the database is either not open, is in nomount mode or mounted when the backup is taken, then the datafiles are already synchronized in terms o f their SCN. In this situation, we can immediately open the database without even applying archivelogs, because the datafiles are already in a consistent state, except if there is a requirement to roll the database for ward to a point-in-time after the said backup is taken. The critical key thing here is to ensure that all of the online datafiles are sy nchronized in terms of their SCN before we can normally open the database. So, run the following SQL statement, as shown below, to determine whether the datafiles are synchronized or not. Take note that we qu ery the V$DATAFILE_HEADER, because we want to know the SCN recorded in the header of the physical datafile, and not the V$DATAFILE, which derives the information from the controlfile. select status, checkpoint_change#, to_char(checkpoint_time, 'DD-MON-YYYY HH24:MI:SS') as checkpoint_time, count(*) from v$datafile_header group by status, checkpoint_change#, checkpoint_time order by status, checkpoint_change#, checkpoint_time; The results of the above query must return one and only one row for the online d atafiles, which means that they are already synchronized in terms of their SCN. Otherwise, if the results return more than one row for th e online datafiles, then the datafiles are still not synchronized yet. In this case, we need to apply archivelog(s) or redolog(s) to synchronize all of the online datafiles. By the way, take note of the CHECKPOINT_TIME in the V$DATAFILE_HEADER, which ind icates the date and time how far the datafiles have been recovered. The results of the query above may return some offline datafiles. So, ensure tha t all of the required

datafiles are online, because we may not be able to recover later the offline datafile once we open th e database in resetlogs. Even though we can recover the database beyond resetlogs for the Oracle database starting from 10g and late r versions due to the introduction of the format "%R" in the LOG_ARCHIVE_FORMAT, it is recommended that you online the required datafi les now than after the database is open in resetlogs to avoid any possible problems. However, in some cases, we intentionally offline the datafile(s), because we are doing a partial database restore, or perhaps we don't need the contents of the said data file. You may run the following query to determine the offline datafiles: select file#, name from v$datafile where file# in (select file# from v$datafile_header where status='OFFLINE'); You may issue the following SQL statement to change the status of the required d atafile(s) from "OFFLINE" to "ONLINE": alter database datafile online; If we are lucky that the required log sequence# is still available in the online redologs and the corresponding redolog member is still physically existing on disk, then we may apply them instead of the archivelog. To confirm, issue the following query, as shown below , that is to determine the redolog member(s) that you can apply to recover the database: set echo on feedback on pagesize 100 numwidth 16 alter session set nls_date_format = 'DD-MON-YYYY HH24:MI:SS'; select LF.member, L.group#, L.thread#, L.sequence#, L.status, L.first_change#, L.first_time, DF.min_checkpoint_change# from v$log L, v$logfile LF, (select min(checkpoint_change#) min_checkpoint_change# from v$datafile_header where status='ONLINE') DF where LF.group# = L.group# and L.first_change# >= DF.min_checkpoint_change#; If the above query returns no rows, because the V$DATABASE.CONTROLFILE_TYPE has a value of "BACKUP", then try to apply each of the redolog membes one at a time during the recovery. You may run the followi ng query to determine the redolog members: select * from v$logfile; If you have tried to apply all of the online redolog members instead of an archi velog during the recovery, but you always received the ORA-00310 error, as shown in the example below, then the log sequence# required for recovery is no longer available in the online redolog.

ORA-00279: change 189189555 generated at 11/03/2007 09:27:46 needed for thread 1 ORA-00289: suggestion : +BACKUP ORA-00280: change 189189555 for thread 1 is in sequence #428 Specify log: {=suggested filename AUTO CANCEL} +BACKUP/prmy/onlinelog/group_2.258.603422107 ORA-00310: archived log contains sequence 503; sequence 428 required ORA-00334: archived log: '+BACKUP/prmy/onlinelog/group_2.258.603422107' After trying all of the possible solutions mentioned above, but you still cannot open the database, because the archivelog required for recovery is either missing, lost or corrupte d, or the corresponding log sequence# is no longer available in the online redolog, since they are alrea dy overwritten during the redolog switches, then we cannot normally open the database, since th e datafiles are in an inconsistent state. So, the following are the 3 options available to allow you to open the database: Option#1: Force open the database by setting the _ALLOW_RESETLOGS_CORRUPTION=TRU E in the init.ora. But there is no 100% guarantee that this will open the database. However, once t he database is opened, then we must immediately rebuild the database. Database rebuild means doing the following, namely: (1) perform a full-database export, (2) create a brand new and separate database , and finally (3) import the recent export dump. This option can be tedious and time consuming , but once we successfully open the new database, then we expect minimal or perhaps no data lo ss at all. Before you try this option, ensure that you have a good and valid backup of the current database. Option#2: If you have a good and valid backup of the database, then restore the database from the said backup, and recover the database by applying up to the last available archi velog. In this option, we will only recover the database up to the last archivelog that is applied, and any data after that are lost. If no archivelogs are applied at all, then we can only recover th e database from the backup that is restored. However, if we restored from an online or hot backup, then we may not be able to open the database, because we still need to apply the archivelogs generated during the said backup in order to synchronize the SCN of the datafile s before we can normally open the database. Option#3: Manually extract the data using the Oracle's Data Unloader (DUL), whic h is performed by Oracle Field Support at the customer site on the next business day and for an extra charge. If the customer wants to pursue this approach, we need the complete name, phone# and email address of the person who has the authority to sign the work order in behalf of the cust

omer. ----Note: ----PURPOSE ------To consolidate the common reasons & solutions for the ORA-1113 error. SCOPE & APPLICATION -------------------Customers facing ORA-1113 and analysts requiring information on known issues with ORA-1113 errors. ORA-1113 ======== An ORA-1113 occurs when a datafile needs recovery. Error Explanation: -----------------01113, 00000, "file %s needs media recovery" Cause: An attempt was made to online or open a database with a file that is in need of media recovery. Action: First apply media recovery to the file. This error is usually followed with ORA-1110 error which will indicate the name of the datafile that needs media recovery. Eg: ORA-01113: file 28 needs media recovery ORA-01110: data file 28: '/h04/usupport/app/oracle/oradata/v817/nar.dbf' This error message indicates that a datafile that is not up-to-date with respect to the controlfile and other datafiles. Oracle's architecture is tightly coupled in the sense that all database files i.e., datafiles, redolog files, and controlfiles -- must be in sync when the database is opened or at the end of a checkpoint. This implies that the checkpoint SCN (System Commit Number) of all datafiles must be the same. If that is not the case for a particular datafile, an ORA-1113 error will be generated. For example, when you put a tablespace in hot backup mode, the checkpoint SCN of all its datafiles is frozen at the current value until you issue the corresponding end backup. If the database crashes during a hot backup and you try to restart it without doing recovery, you will likely get ORA-1113 for at least one of the datafiles in the tablespace that was being backed up, since its SCN will probably be lower than that of the controlfile and the

datafiles in other tablespaces. Likewise, offlining a datafile causes its checkpoint SCN to freeze. If you simply attempt to online the file without recovering it first, its SCN will likely be much older than that of the online datafiles, and thus an ORA-1113 will result. ********************************************** Before Starting these actions do the following: ********************************************** Note : If you are using Oracle9i, use SQL*Plus, instead of Server Manager to execute the mentioned commands, since Server Manager is not available in Oracle9i. Query the V$LOG and V$LOGFILE. 1. If the database is down, you need to mount it first. SVRMGR> STARTUP MOUNT PFILE=; 2. Then connect internal Server Manager and issue the query: SVRMGR> CONNECT INTERNAL; or SQL> connect / as sysdba (for Oracle9i) SVRMGR> SELECT V1.GROUP#, MEMBER, SEQUENCE#, FIRST_CHANGE# FROM V$LOG V1, V$LOGFILE V2 WHERE V1.GROUP# = V2.GROUP# ; This will list all your online redolog files and their respective sequence and first change numbers. The steps to take next depend on the scenario in which the ORA-1113 was issued. This is discussed in the following sections. POSSIBLE CAUSES AND SOLUTIONS SUMMARY: ===================================== I. II. III. IV. VERY AT STARTUP AFTER CRASH WITH TABLESPACE(S) IN HOT BACKUP AT STARTUP AFTER RESTORING A DATAFILE OR TABLESPACE FROM A BACKUP TRYING TO ONLINE A DATAFILE OR TABLESPACE WHEN RECOVERING ' USING BACKUP CONTROLFILE' OPTION TO DO INCOMPLETE RECO

I. AT STARTUP AFTER CRASH WITH TABLESPACE(S) IN HOT BACKUP ********************************************************** A. WITH ORACLE 7.1 OR LOWER 1. Mount the database.(If the database is NOT already mounted) SVRMGR> STARTUP MOUNT PFILE=; 2. Apply media recovery to the database.

SVRMGR> RECOVER DATABASE; 3. Confirm each of the archived logs that you are prompted for until you receive the message "Media recovery complete". If you are prompted for an archived log that does not exist, Oracle probab ly needs one or more of the online logs to proceed with the recovery. Compare the sequence number referenced in the ORA-280 message with the sequence numbers of your online logs. Then enter the full path name of one of the members of the redo group whose sequence number matches the one you are be ing asked for. 4. Open the database. SVRMGR> ALTER DATABASE OPEN; B. WITH ORACLE 7.2 OR HIGHER 1. Mount the database. SVRMGR> STARTUP MOUNT; 2. Find out which datafiles were in hot backup mode when the database crashed or was shutdown abort or the machine was rebooted by running the query: SVRMGR> SELECT V1.FILE#, NAME FROM V$BACKUP V1, V$DATAFILE V2 WHERE V1.STATUS = 'ACTIVE' AND V1.FILE# = V2.FILE# ; 3. For each of the files returned by the above query, issue the command: SVRMGR> ALTER DATABASE DATAFILE '' END BACKUP; 4. Open the database. SVRMGR> ALTER DATABASE OPEN; II. AT STARTUP AFTER RESTORING A DATAFILE OR TABLESPACE FROM A BACKUP ********************************************************************* A. WITH THE DATABASE IN ARCHIVELOG MODE 1. Mount the database. SVRMGR> STARTUP MOUNT; 2. Recover the datafile: SVRMGR> RECOVER DATAFILE ''; If recovering more than one datafile in a tablepace issue a SVRMGR> RECOVER TABLESPACE; If recovering more than one tablespace issue a

SVRMGR> RECOVER DATABASE; 3. Confirm each of the archived logs that you are prompted for until you receive the message "Media recovery complete". If you are prompted for an archived log that does not exist, Oracle probab ly needs one or more of the online logs to proceed with the recovery. Compare the sequence number referenced in the ORA-280 message with the sequence numbers of your online logs. Then enter the full path name of one of the members of the redo group whose sequence number matches the one you are being asked for. 4. Open the database. SVRMGR> ALTER DATABASE OPEN; B. WITH THE DATABASE IN NOARCHIVELOG MODE In this case, you will only succeed in recovering the datafile or tablespace if the redo to be applied to it is within the range of your online logs. Issue the query: SVRMGR> SELECT FILE#, CHANGE# FROM V$RECOVER_FILE; Compare the change number you obtain with the FIRST_CHANGE# of your online lo gs. If the CHANGE# is GREATER than the minimum FIRST_CHANGE# of your logs, the datafile can be recovered. In this case, the procedure to be followed is analogous to that of scenario II.A above, except that you must always enter the appropriate online log when prompted, until recovery is finished . If the CHANGE# is LESS than the minimum FIRST_CHANGE# of your logs, the file cannot be recovered.Your options at this point include: - If the datafile is in a temporary or index tablespace, you may drop it with an ALTER DATABASE DATAFILE '' OFFLINE DROP statement and then open the database. Once the database is up, you must drop the tablespace to which the datafile belongs and recreate it. - If the datafile is in the SYSTEM or in a rollback tablespace, restore an up-to-date copy of the datafile (if available) or your most recent full backup.In case you do not have either of this, then it might not be possible to recover the database fully. For more details or to assist you in your decision, please contact Oracle Customer Support. For all other cases in this scenario, you must weigh the cost of going to a backup versus the cost of recreating the tablespace involved, as described in the two previous cases.For more details or to assist you in your decision, please contact Oracle Customer Support. III. TRYING TO ONLINE A DATAFILE OR TABLESPACE **********************************************

1. Recover the datafile: SVRMGRL> RECOVER DATAFILE ''; If recovering a tablespace, do SVRMGRL> RECOVER TABLESPACE ; If recovering a database, do SVRMGRL> RECOVER DATABASE; 2. Confirm each of the archived logs that you are prompted for until you receive the message "Media recovery complete". If you are prompted for an archived log that does not exist, Oracle probab ly needs one or more of the online logs to proceed with the recovery. Compare the sequence number referenced in the ORA-280 message with the sequence numbers of your online logs. Then enter the full path name of one of the members of the redo group whose sequence number matches the one you are being asked for. 3. Open the database. SVRMGR> ALTER DATABASE OPEN;

IV. WHEN RECOVERING ' USING BACKUP CONTROLFILE' OPTION TO DO INCOMPLETE RECOVERY ******************************************************************************* If the database is recovered with the "RECOVER DATABASE USING BACKUP CONTROLFILE;" option without specifying the "UNTIL CANCEL" option, then upon "ALTER DATABASE OPEN RESETLOGS;" you will encounter the ORA-1113 error. Steps to workaround this issue: 1. Recover database again using: SVRMGR> RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL; 2. Cancel recovery by issuing the "CANCEL" command. 3. Open the database using: SVRMGR> ALTER DATABASE OPEN RESETLOGS; Notes that explain other possible recovery scenarios involving ORA-1113: -----------------------------------------------------------------------Note 116374.1 -- "ORA-1113 on Datafile After Moving Datafile Using USFDMP Utility" ORA-1113 on Datafile After Moving Datafile Using USFDMP -- "VMS: Mount Phase of Database Startup Results in ORA-01113, ORA-01186 & ORA-01122"

Note 1079626.6

ORA-1113 due to datafile getting locked on OpenVMS Note 1020262.102 -- "ORA-01113, ORA-01110: TRYING TO STARTUP DATABASE AFTER INCOMPLETE RECOVERY" Another scenario of ORA-1113 Note 168115.1 ilure" -- "ORA-01113 ORA-01110 on Database Startup after Write Disk fa Datafile header contains different SCN comparing to other database files due to a write disk failure Note 146039.1 -- "Database Startup Fails with ORA-01113, ORA-01110" Dropping the datafile while ORA-1113, if the datafile is not required

Some usefull queries: set pagesize 20000 set linesize 1000 set pause off set serveroutput on set feedback on set echo on set numformat 999999999999999 Spool recover.lst show parameter pfile; archive log list; select * from v$backup; select file#, status, substr(name, 1, 70) from v$datafile; select distinct checkpoint_change# from v$datafile_header; select status,resetlogs_change#,resetlogs_time,checkpoint_change#, to_char(checkpoint_time, 'DD-MON-YYYY HH24:MI:SS') as checkpoint_time,cou nt(*) from v$datafile_header group by status, resetlogs_change#, resetlogs_time, checkpoint_change#, checkpoi nt_time order by status, checkpoint_change#, checkpoint_time ; select substr(name,1,60), recover, fuzzy, checkpoint_change#, resetlogs_change#, resetlogs_time from v$datafile_header; select name, open_mode, checkpoint_change#, ARCHIVE_CHANGE# from v$database; select GROUP#,THREAD#,SEQUENCE#,MEMBERS,ARCHIVED,STATUS,FIRST_CHANGE# from v$log ; select GROUP#,substr(member,1,60) from v$logfile; select * from v$log_history; select * from v$recover_file;

select * from v$recovery_log; select HXFIL File_num,substr(HXFNM,1,70) File_name,FHTYP Type,HXERR Validity, FHSCN SCN, FHTNM TABLESPACE_NAME,FHSTA status ,FHRBA_SEQ Sequence from X$KCVFH; select hxfil FileNo,FHSTA status from x$kcvfhall; spool off

======================================================================= Notes Related to ORA-00313 ORA-00313 messages: ======================================================================= ORA-312 ORA-313 -----Note: -----ORA-00313 ,ORA-00312 open failed for members of log group Error Description: --------------------------Whenever you start your database you returned by the following message, ORA-00313: open failed for members of log group 2 of thread 1 ORA-00312: online log 2 thread 1: '/oradata2/data1/dbase/redo02.log' Cause of The problem: ----------------------------Your database was in archive log file, you shutdown your database and whenever y ou start it up either your redo log file is deleted or it is corrupted (if you overwrite or tru ncate the file). In this case you had 1 redo log member on each group. Solution of The problem: -------------------------------It is not possible to recover missing redo log file. In order to solve the probl em do the following. A)Mount the database. SQL>STARTUP MOUNT Database mounted. B)Check the status of the logile to see whether it is current. Here it is, SQL> SELECT STATUS FROM V$LOG WHERE GROUP#=2; STATUS ---------------CURRENT i)If the status did not CURRENT then simply drop the log file by,

SQL>ALTER DATABASE DROP LOGFILE GROUP 2; If there are only 2 log groups then it will be necessary to add another group be fore dropping this one. So, before dropping do, SQL>ALTER DATABASE ADD LOGFILE GROUP 4 '/oradata2/redo3.log' SIZE 10M; ii)If/As the status is CURRENT then simply perform fake recovery and then open r esetlogs. SQL>RECOVER DATABASE UNTIL CANCEL; and print CANCEL. SQL>ALTER DATABASE OPEN RESETLOGS;

-----Note: -----Subject: Loss Of Online Redo Log And ORA-312 And ORA-313 Doc ID: 117481.1 Type: BULLETIN Modified Date : 04-AUG-2008 Status: PUBLISHED Scenario -------You have a database in archive log mode, shutdown immediate and deleted one of the online redo logs, in this case there are only 2 groups with 1 log member in each. When you try to open the database you receive the following errors: ora-313 open failed for memebers of log group 2 of thread 1. ora-312 online log 2 thread 1 'filename' It is not possible to recover the missing log, so the following needs to be performed Mount the database and check v$log to see if the deleted log is current; -If the log is not current, simply drop the log group (alter database drop logfile group N). If there are only 2 log groups then it will be necessary to add another group before dropping this one. -If the log is current they should simply perform fake recovery and then open resetlogs connect internal startup mount recover database until cancel; (cancel immediately) alter database open resetlogs; The database will open up as required, providing the log file directory is available. If not available then create it and rerun the resetlogs. This will give error

ora-344

unable to recreate online log

search words -----------lost online redo ora-312 ora-313 Recovering After the Loss of Online Redo Log Files: Scenarios ============================================================= If a media failure has affected the online redo logs of a database, then the appropriate recovery procedure depends on the following: The configuration of the online redo log: mirrored or non-mirrored The type of media failure: temporary or permanent The types of online redo log files affected by the media failure: current, active, unarchived, or inactive 1) Recovering After Losing a Member of a Multiplexed Online Redo Log Group --------------------------------------------------------------------------If the online redo log of a database is multiplexed, and if at least one member of each online redo log group is not affected by the media failure, then the database continues functioning as normal, but error messages are written to the log writer trace file and the alert_SID.log of the database. ACTION PLAN ============= If the hardware problem is temporary, then correct it. The log writer process accesses the previously unavailable online redo log files as if the problem never existed. If the hardware problem is permanent, then drop the damaged member and add a new member by using the following procedure. To replace a damaged member of a redo log group: =============================================== Locate the filename of the damaged member in V$LOGFILE. The status is INVALID if the file is inaccessible: SQL> SELECT GROUP#, STATUS, MEMBER FROM V$LOGFILE WHERE STATUS='INVALID'; GROUP# ------0002 STATUS MEMBER ----------- --------------------INVALID /oracle/oradata/trgt/redo02.log

++ Drop the damaged member. For example, to drop member redo01.log from group 2, issue: SQL > ALTER DATABASE DROP LOGFILE MEMBER '/oracle/oradata/trgt/redo02.log'; ++ Add a new member to the group. For example, to add redo02.log to group 2, issue: SQL> ALTER DATABASE ADD LOGFILE MEMBER '/oracle/oradata/trgt/redo02b.log'

TO GROUP 2; If the file you want to add already exists, then it must be the same size as the other group members, and you must specify REUSE. For example: SQL > ALTER DATABASE ADD LOGFILE MEMBER '/oracle/oradata/trgt/redo02b.log' REUSE TO GROUP 2; 2) Losing an Inactive Online Redo Log Group =========================================== If all members of an online redo log group with INACTIVE status are damaged, then the procedure depends on whether you can fix the media problem that damaged the inactive redo log group. If the failure is . . Temporary... then Fix the problem. LGWR can reuse the redo log group when required. If the failure is ... Permanent then the damaged inactive online redo log group eventually halts normal database operation. ACTION PLAN ============ Reinitialize the damaged group manually by issuing the ALTER DATABASE CLEAR LOGFILE You can clear an inactive redo log group when the database is open or closed. The procedure depends on whether the damaged group has been archived. To clear an inactive, online redo log group that has been archived: -------------------------------------------------------------------If the database is shut down, then start a new instance and mount the database: STARTUP MOUNT Reinitialize the damaged log group. For example, to clear redo log group 2, issue the following statement: ALTER DATABASE CLEAR LOGFILE GROUP 2; Clearing Inactive, Not-Yet-Archived Redo ======================================== Clearing a not-yet-archived redo log allows it to be reused without archiving it. This action makes backups unusable if they were started before the last change in the log, unless the file was taken offline prior to the first change in the log. Hence, if you need the cleared log file for recovery of a backup, then you cannot recover that backup. Also, it prevents complete recovery from backups due to the missing log. To clear an inactive, online redo log group that has not been archived: If the database is shut down, then start a new instance and mount the database: STARTUP MOUNT Clear the log using the UNARCHIVED keyword. For example, to clear log group 2, issue: ALTER DATABASE CLEAR LOGFILE UNARCHIVED GROUP 2; If there is an offline datafile that requires the cleared log to bring it online, then the keywords UNRECOVERABLE DATAFILE are required. The datafile and its entire tablespace have to be dropped because the redo necessary to

bring it online is being cleared, and there is no copy of it. For example, enter: ALTER DATABASE CLEAR LOGFILE UNARCHIVED GROUP 2 UNRECOVERABLE DATAFILE; Immediately back up the whole database with an operating system utility, so that you have a backup you can use for complete recovery without relying on the cleared log group. For example, enter: % cp /disk1/oracle/dbs/*.f /disk2/backup Back up the database's control file with the ALTER DATABASE statement. For example, enter: ALTER DATABASE BACKUP CONTROLFILE TO '/oracle/dbs/cf_backup.f'; Failure of CLEAR LOGFILE Operation ---------------------------------------The ALTER DATABASE CLEAR LOGFILE statement can fail with an I/O error due to media failure when it is not possible to: * Relocate the redo log file onto alternative media by re-creating it under the currently configured redo log filename * Reuse the currently configured log filename to re-create the redo log file because the name itself is invalid or unusable (for example, due to media failure) In these cases, the ALTER DATABASE CLEAR LOGFILE statement (before receiving the I/O error) would have successfully informed the control file that the log was being cleared and did not require archiving. The I/O error occurred at the step in which the CLEAR LOGFILE statement attempts to create the new redo log file and write zeros to it. This fact is reflected in V$LOG.CLEARING_CURRENT.

-----Note: -----Subject: ORA-00313 at Startup After a New Redo Log Memeber is Added Doc ID: 1005110.6 Type: PROBLEM Modified Date : 02-JUL-2007 Status: PUBLISHED Problem Description: ==================== A new redo log member is added to the database. However, if a shutdown and a subsequent startup is issued BEFORE the status of the log member as per V$LOGFILE goes from 'INVALID' (which is expected) to blank entry (i.e., 'IN USE'), you get an ORA-00313 and a trace file is generated. This scenario takes place after adding a redo log member to the database. For example: SQLDBA> ALTER DATABASE ADD LOGFILE MEMBER '' TO GROUP ;

If you shutdown the database before the new member is used at the next startup, then an ORA-00313 is written to the alert.log file and a trace file (filename 'lgwr_xxxxx.trc') is also dumped. For the command above, such a trace file shows the following: *** SESSION ID:(3.1) ORA-00313: open failed for members of log group 1 of thread 1 The entire database, however, is still working just fine. Solution Description: ===================== This error message is meant to have useful information reported at startup. Since the new log member is still labeled as 'INVALID', it still does not have all file headers properly initialized, hence its contents cannot be trusted for recovery of any kind. However, once a log switch operation switches into the redo log group, the new redo log member will be then initialized and ready to write redo entries copied from the log buffer. What Development should have done was to just warn the DBA in the alert.log file. A trace file (lgwr_xxxxx.trc) is really not necessary. To accomplish this, however, Development has to come up with a new routine that only dumps warning messages of this nature to the alert.log file and NOT to the trace file.

-----Note: -----Subject: STARTING DATABASE, GETS ERROR, ORA-313. Doc ID: 1006148.6 Type: PROBLEM Modified Date : 20-JAN-2009 Status: PUBLISHED Problem Description: ==================== Database gives ORA-313 upon startup. ORA-00313: cannot open online '%s' (log #^ %s, log sequence # %s) Cause: The online log cannot be opened. Action: Restore online log. Solution Description: ===================== The Tape backup software had locked the logfile so Oracle could not update it. Everything worked fine once the tape backup job was terminated. Explanation: ============ The online logs are opened by the database at the time of startup. If these

online logs are not available (maybe they have been deleted by mistake) or have been locked by a process, the above error will occur. The solution is to find out why they are not available and make them available. In this particular case, the tape backup software had locked the logfile. Terminating the tape backup job removed the lock on the online log files and made them available to oracle. Note: The online redo logfiles is another name for redo logfiles.

-----Note: -----Subject: ORA-1157 ORA-1110 ORA-312 ORA-313 ORA-202 ORA-27086 Doc ID: 365560.1 Type: PROBLEM Modified Date : 06-NOV-2008 Status: MODERATED In this Document Symptoms Cause Solution

Applies to: Oracle Server - Enterprise Edition - Version: 9.2.0.1 to 10.2.0.2 This problem can occur on any platform. Symptoms You are receiving the following errors: Wed Nov 30 15:43:26 2005 Errors in file /oracle/dsprdb01_orabin/admin/dsprdb01/bdump/dsprdb01_dbw0_19375. trc: +RA-01157: cannot identify/lock data file 2 - see DBWR trace file +RA-01110: data file 2: '/oracle/dsprdb01_index/sub_rule_bal_tran_indexes_02.dbf ' +RA-27086: skgfglk: unable to lock file - already in use SVR4 Error: 11: Resource temporarily unavailable Additional information: 8 . . Errors in file /oracle/dsprdb01_orabin/admin/dsprdb01/bdump/dsprdb01_lgwr_19377. trc: +RA-00313: open failed for members of log group 3 of thread 1 +RA-00312: online log 3 thread 1: '/oracle/dsprdb01_redo_B/redo03B.log' +RA-27086: skgfglk: unable to lock file - already in use SVR4 Error: 11: Resource temporarily unavailable Additional information: 8 +RA-00312: online log 3 thread 1: '/oracle/dsprdb01_redo_A/redo03A.log' +RA-27086: skgfglk: unable to lock file - already in use SVR4 Error: 11: Resource temporarily unavailable Additional information: 8 . . ALTER DATABASE MOUNT

Wed Nov 30 16:10:19 2005 +RA-00202: controlfile: '/oracle/dsprdb01_redo_A/control01.ctl' +RA-27086: skgfglk: unable to lock file - already in use SVR4 Error: 11: Resource temporarily unavailable Additional information: 8

Cause Host name was changed which caused locking confusion between Oracle and the OS. If the netapp gets a fully qualified hostname from dns, then the machine's hostn ame must be fully qualified as well. E.g. Don't set the hostname to ca-test90(returned by uname -n) , if the dns look up returns ca-test90.us.oracle.com , otherwise lock recovery on the netapp will not work which will cause locking pro blems and the above errors to be reported. Solution Change the hostname so that hostname,as seen by uname -n, is same as the hostnam e returned by DNS to Netapps.

-----Note: -----Subject: ORA-313 Received Intermittently Doc ID: 210886.1 Type: PROBLEM Modified Date : 09-OCT-2002 Status: PUBLISHED Fact(s) ~~~~~~~ The OS is windows NT/2000. The errors generally appear intermittently. There are no hardware issues. (i.e. harddisk is healthy) Symptom(s) ~~~~~~~~~~ Following set of errors are recieved in the logwriter trace file: ORA-00321: ORA-00312: ORA-27091: OSD-04008: O/S-Error: ORA-00313: Cause ~~~~~ There is some 3rd party software that has acquired locks on the failing redolog member group file. This is generally caused by log 11 of thread 1, cannot update log file header online log 11 thread 1: 'U:\ORACLE\P01\MIRRLOGA\LOG_G11M2.DBF' skgfqio: unable to queue I/O WriteFile() failure, unable to write to file (OS 5) Access is denied. open failed for members of log group 11 of thread 1

some backup utility or antivirus software that has acquired locks on the failing log member. Solution(s) ~~~~~~~~~~~ Disable the file locking in the backup and antivirus software. -orDisable backup and scanning of Oracle datafiles. For more information, please consult your system administrator to find the exact application holding locks on the failing redolog file members.

======================================================================= Notes Related to other ORA- error messages: ======================================================================= ORA-00257: archiver error: ========================== Most of the time, it's due that the maximum in the flash recovery area is reache d, or db_recovery_file_dest_size . Solution: increase flash recovery area, or delete old backups.

ORA-00604: ========== 00604 - 604 -------Note 1: -------ORA-00604: error occurred at recursive SQL level string ORA-00604: error occurred at recursive SQL level string Cause: An error occurred while processing a recursive SQL statement (a statement applying to internal dictionary tables). Action: If the situation described in the next error on the stack can be correct ed, do so; otherwise contact Oracle Support.

ORA-00604 error can occur in so many different contexts. The following is one su ch scenario Connecting as DB User gives ORA-00604, ORA-01986: OPTIMIZER_GOAL is Obsolete and ORA-6512 Errors This error applies to Oracle Server - Enterprise Edition - Version: 10.1.0.2 to 10.2.0.3 This problem can occur on any platform When you try to log-in to the database as a particular user, you get disconnecte d with the error : ORA-01986 SQL> conn dvamin/dvamin ERROR: ORA-00604: error occurred at recursive SQL level 1 ORA-01986: OPTIMIZER_GOAL is obsolete ORA-06512: at line 2 Warning: You are no longer connected to ORACLE. You check the init.ora / spfile and verify that you haven't set any parameter : OPTIMIZER_GOAL still the database login errors out indicating that OPTIMIZER_GOAL is obsolete. In the alert.log, you find : Errors in file $ORACLE_BASE/admin/hrupg/udump/_ora_.trc: ORA-00604: error occurred at recursive SQL level 1 ORA-01986: OPTIMIZER_GOAL is obsolete ORA-06512: at line 2 Why this error is occurring ? Troubleshoot Please check the tracefile : $ORACLE_BASE/admin/hrupg/udump/_ora_.trc This shows : ---------------------------------------------------------------------------------------------------------*** SERVICE NAME:(SYS$USERS) 2006-11-21 08:20:41.909 *** SESSION ID:(104.17) 2006-11-21 08:20:41.909 Error in executing triggers on connect internal *** 2006-11-21 08:20:41.911 ksedmp: internal or fatal error ORA-00604: error occurred at recursive SQL level 1 ORA-01986: OPTIMIZER_GOAL is obsolete ORA-06512: at line 2 ---------------------------------------------------------------------------------------------------------You have configured some Database Login Triggers.

These triggers are trying to set a parameter that is obsolete in 10.2 Hence errors. You might have configured a login trigger of the type : ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ CREATE OR REPLACE TRIGGER LoginTrigger AFTER LOGON ON xxxxxx.SCHEMA BEGIN execute immediate 'alter session set OPTIMIZER_GOAL=FIRST_ROWS'; ... ... END; / ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SIMPLE TEST-CASE : +++++++++++++++++++++++++++++++++++++++++++++++++++++ ############################################################# SQL> create user dvamin identified by dvamin quota 5M on users; User created. SQL> grant connect to dvamin; Grant succeeded. SQL> CREATE OR REPLACE TRIGGER LoginTrigger AFTER LOGON ON dvamin.schema 2 BEGIN 3 execute immediate 4 'alter session set OPTIMIZER_GOAL=FIRST_ROWS'; 5 END; 6 / Trigger created. SQL> conn dvamin/dvamin ERROR: ORA-00604: error occurred at recursive SQL level 1 ORA-01986: OPTIMIZER_GOAL is obsolete ORA-06512: at line 2 Warning: You are no longer connected to ORACLE. ############################################################# What is the Solution? (i) Log-in as a user with ADMINISTER DATABASE TRIGGER privilege (ii) Drop this trigger. (iii) Log in as the required user successfully. SQL> conn / as sysdba Connected. SQL> drop trigger LoginTrigger; Trigger dropped. SQL> conn dvamin/dvamin Connected. Rewrite the trigger as necessary if required. Please refer to the Oracle Adminis trator's

Guide 10g as available in OTN if needed. --------Note 2: --------Check if invalid packages of SYS are present. If so: re-compiling all package using SYS. Running this repeatedly until invalid packa ges no longer show, should clear up any issues throwing ORA-00604. -------Note 3: -------Hi, I have the following problem: SQL> select * from t; select * from t * ERROR at line 1: ORA-00604: error occurred at recursive SQL level 1 ORA-04092: cannot COMMIT in a trigger ORA-06512: at line 12 ORA-00942: table or view does not exist And table `t' does not exist. But this happens no matter what user I am, no matter what I do but only if there are errors (assuming that it would normally give only the last error). I was looking for the trigger that might do commit but there is no single one in any schemas in our database. What does this ORA-00604 mean? Does it have something to do with recursive SQL queries? Is this some kind of internal problem? How can I get rid of it? Thanx in advance, Piotr

and we said... someone created an "after servererror" trigger and is committing in it. conside r: ops$tkyte@ORA9I.WORLD> drop user a cascade; User dropped. ops$tkyte@ORA9I.WORLD> ops$tkyte@ORA9I.WORLD> grant create session to a identifi

ed by a; Grant succeeded. ops$tkyte@ORA9I.WORLD> ops$tkyte@ORA9I.WORLD> @connect a/a ops$tkyte@ORA9I.WORLD> set termout off a@ORA9I.WORLD> REM GET afiedt.buf NOLIST a@ORA9I.WORLD> set termout on a@ORA9I.WORLD> select * from t; select * from t * ERROR at line 1: ORA-00942: table or view does not exist a@ORA9I.WORLD> a@ORA9I.WORLD> @connect / a@ORA9I.WORLD> set termout off ops$tkyte@ORA9I.WORLD> REM GET afiedt.buf NOLIST ops$tkyte@ORA9I.WORLD> set termout on ops$tkyte@ORA9I.WORLD> drop table log; Table dropped. ops$tkyte@ORA9I.WORLD> create table log( msg varchar2(255) ); Table created. ops$tkyte@ORA9I.WORLD> ops$tkyte@ORA9I.WORLD> create or replace trigger error_tr igger 2 after servererror on database 3 begin 4 insert into log values ( 'hi' ); 5 commit; 6 end; 7 / Trigger created. ops$tkyte@ORA9I.WORLD> ops$tkyte@ORA9I.WORLD> @connect a/a ops$tkyte@ORA9I.WORLD> set termout off a@ORA9I.WORLD> REM GET afiedt.buf NOLIST a@ORA9I.WORLD> set termout on a@ORA9I.WORLD> select * from t; select * from t * ERROR at line 1: ORA-00604: error occurred at recursive SQL level 1 ORA-04092: cannot COMMIT in a trigger ORA-06512: at line 3 ORA-00942: table or view does not exist a@ORA9I.WORLD> a@ORA9I.WORLD> @connect / a@ORA9I.WORLD> set termout off ops$tkyte@ORA9I.WORLD> REM GET afiedt.buf NOLIST ops$tkyte@ORA9I.WORLD> set termout on ops$tkyte@ORA9I.WORLD> select owner, trigger_name 2 from dba_triggers 3 where trigger_type = 'AFTER EVENT';

OWNER -----------------------------SYS OPS$TKYTE

TRIGGER_NAME -----------------------------AURORA$SERVER$STARTUP ERROR_TRIGGER

ops$tkyte@ORA9I.WORLD> ops$tkyte@ORA9I.WORLD> drop trigger error_trigger; Trigger dropped.

Use that last query to find the offending trigger and either make it an autonomo us transaction so it can commit or remove the commit. ---------Note 4: ----------

ORA-12705: ========== ----------Note 1: ----------On Windows, Verify your regional Settings in the Control Panel. In the "Regional Options" ta b, select English(United States). We had two machines with that problems and changing that setting solved.

----------Note 2: ----------ORA-12705 invalid or unknown NLS parameter value specified Cause: There are two possible causes: Either an attempt was made to issue an ALT ER SESSION statement with an invalid NLS parameter or value; or the NLS_LANG enviro nment variable contains an invalid language, territory, or character set. Action: Check the syntax of the ALTER SESSION statement and the NLS parameter, c orrect the syntax and retry the statement, or specify correct values in the NLS_LANG en vironment variable

---------Note 3: ---------Windows - The NLS_LANG must be unset in the Windows registry (re-named is best). Look for the NLS_LANG subkey in the registry at \HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE, and rename it. We tried changing it to what I had in my registry: AMERICAN_AMERICA.WE8MSWIN1252 That didn't work. Tried renaming it as the article suggested, that didn't work. Finally, my colleague (without prompting from me), cleared the key (didn't delet e, just blanked it)...and voila! Labels: obiee, ORA-12705, oradb ---------Note 3: ---------On unix, set the NLS_LANG variable to point to the right location.

----Note: ----Good article, describing how to deal with ORA-600 errors. Subject: How to Analyze Problems Related to Internal Errors (ORA-600) and Core Dumps (ORA-7445) using Metalink Doc ID: 260459.1 Type: TROUBLESHOOTING Modified Date : 05-SEP-2008 Status: PUBLISHED Applies to: Oracle Server - Enterprise Edition - Version: 8.1.7.4 to 11.1 Information in this document applies to any platform. Goal How to Analyze Problems Related to Internal Errors (ORA-600) and Core Dumps (ORA -7445) ================================================================================ = 1.1 Abstract ============ This document provides guidelines for customers to do an initial analysis of problems related to internal errors (ORA-600) and core dumps (ORA-7445) by using

Metalink keyword searches. After finding a set of documents, either bug database entries or notes, these must be correlated to the specific circumst ances to further narrow down the search results. Hints to do this are given. 1.2 Introduction ================= It is often the case that certain problems have been already discovered and are documented in Metalink notes and in published bug information. With the prop er techniques it is often possible to narrow down to a particular bug that matches your problem and find documented workarounds or patch information. This document is m ainly aimed at rediscovering bugs in Oracle code that cause internal errors or core du mps but it may be equally applicable to all kinds of problems that may be encountere d. The following paragraphs aim at extracting the relevant keywords from the trace file to find the documents that are relevant to the specific error condition. It also tries to help in further narrowing down the list of relevant documents by correl ating them to the specific circumstances of the error. Solution 2.1 ORA-00600: internal error code, arguments: [argument1] [argumentX] .... ========================================================================== The internal argument ORA-600 is raised within the Oracle kernel when an excepti onal condition occurs. Inside the kernel code at various stages of processing, so cal led assertions are executed.These are certain conditions that must be true to be abl e to proceed. The assertions are internal health checks and guard over the integri ty of memory and data of the instance and the database. When such an assertion fail s, an ORA-600 error is raised with either a numeric or alphanumeric first argument and possibly more arguments depending on the particular error. Note that not all ORA -600 errors are necessary fatal errors causing the session to terminate; some are quite benign. Others however can be severe so they must always be carefully inve stigated. 2.1.1 The First Argument of the Internal Error ORA-600 ====================================================== The single most important piece of information is the first argument of the inte rnal error, either numeric or alphanumeric; it uniquely identifies the specific modul e where it was raised and what assertion was failing. Always include this first ar gument in your keyword search when trying to rediscover known problems. 2.2 ORA-07445: exception encountered: core dump ============================================== A core dump is an exceptional condition similar to the internal error ORA-600, h owever, the big difference is that the kernel did not anticipate the error. Whereas in t he case

of the internal error the exceptional condition was discovered by an assertion w hich is a predefined check, the core dump happens because the operating system at some poi nt aborts the process because it is doing a forbidden action such as trying to access an a rea of memory that does not belong to the process. This is why core dumps are often ref erred to as access violations. The term 'core dump' stems from a period when memory was s tored with the use of magnetic cores, in computer terminology 'core' equates to 'memory'. A core dump means that the memory of the process was dumped in a file 'core' on the fil e system. 2.2.1 Identify the failing module ================================= It is important to know in which internal module the core dump occurs, this is o ften printed together with the error but not always. If not refer to the section 3.2.5 Call S tack Trace. If known include the failing module in your keyword search. 3.1 Trace files =============== For both internal errors and core dumps a trace file is written in either user_d ump_dest for user processes and background_dump_dest for background processes. In 11g all tra ce files will be written to the location defined by the parameter diagnostic_dest. The tr ace files for both types are treated in the same manner although the particular information in the trace files, whether a certain section is present, may depend on the particular error. In cas e of a core dump it is possible for the kernel to still dump relevant information by calling the dump routines such as ksedmp() because the error is trapped by a signal handler. On the other hand, for most internal errors, the process is crashed (aborted) when the dump is ready. 3.2 Relevant sections in Trace files ==================================== While not intended to provide a detailed explanation or in depth understanding, the following sections in the trace file can usually be identified, this will help you to glea n the relevant keywords for the search and understand the specific conditions under which the e rror occured, you should then be able to narrow down your search results. 3.2.1 Header ============ The header section includes such information as the name of the trace file, the specific oracle version, ORACLE_HOME ,system name, node name, OS version, instance name and proc ess information. While not directly relevant for your keyword search this informatio n is vital later to correlate the documents to your problem.

3.2.2 Error Section =================== The error as it was written in the alert.log is usually repeated, possibly along with some extra information dependent on the error. When an internal error occurs a develo per may have decided to write some crucial state information apart from the ORA-600 arguments directly to the trace file. When this is the case, those are usually gems for yo ur search. 3.2.3 Current SQL statement for this session ============================================ You may or may not know what was being conducted at the time of the error. While common keywords like 'insert', 'update' or 'delete' may not be beneficial to your search (they a re simply too common) this is of course very useful to correlate documented rediscovery inform ation to your problem. If for example a certain bug has in its rediscovery information that it happens on insert only and you are performing a delete statement, then it is safe to say that this bug is not your problem. See also 3.2.6 Cursor Dump in case the current SQL statement is not present in t he trace file. 3.2.4 PL/SQL Call Stack ======================= This section is present if the session was performing PL/SQL- it shows what user or internal PL/SQL packages where called. Call Stacks are read bottom up; if there are Oracl e packages in there include them in your keyword search. 3.2.5 Call Stack Trace ====================== The modules listed in the call stack trace provide excellent keywords that can b e used for rediscovery; they usually uniquely identify specific bugs. However, care must be taken to discard the top and bottom modules. Modules such as the following must be ignore d : sigacthandler(), ssexhd(), ksedmp(), ksesicX() (where X is a number that designates the number of extra arguments to an ora-600 besides the first). All kse* and kge* modules in general can be ig nored, they stand for Kernel Service Error and Kernel Generic Error respectively; these are modules th at are invoked AFTER the error has occurred and perform such tasks as dumping the trace file and as s uch are common to most internal errors and core dumps so will not help in narrowing down your sear ch. The same goes for the bottom modules that are always present because they are used to initiate process startup; everyting below (and including) opiexe() can safely be ignored. When you include three or four relevant modules from the top of the call stack trace (together with some other relevant keywords),

this will usually result in the relevant documents popping up on a Metalink sear ch. If none are returned you may have to reduce the number of modules searched upon, removing th e modules further down the stack from the search. If you still have no results returned yo u may have hit an as yet undiscovered problem. 3.2.6 Cursor Dump ================= Even when the current SQL statement is not listed in the top section of the trac e file together with the error, the cursor dump can still reveal the SQL statement being performed at time of error. Simply search for 'current cursor' identify the cursor number and scroll down until you find the cursor with that number. A a bonus you may also be able to identify the bind variables (if any) u sed for the statement in this section. See Note 154170.1 for further information. 3.2.7 Process State - Session State Object ========================================== A process state is a list of the process state objects, it is beyond the scope o f this document to explain these in detail, for now it is enough to understand that state objects a re used to organize memory objects that contain the relevant state information of a session in an hi erarchical manner. One of the state objects contains relevant session information that helps in narrowi ng down the specifics of the error condition. Simply search for 'program' in your trace file and you w ill find a section similar to the following : SO: 7000000223acfe0, type: 4, owner: 700000022357868, flag: INIT/-/-/0x00 (session) trans: 7000000230d47a0, creator: 700000022357868, flag: (18100041) USR/- BSY/-/-/-/-/DID: 0001-0012-00000083, short-term DID: 0000-0000-00000000 txn branch: 0 oct: 2, prv: 0, sql: 70000002831a5a0, psql: 70000002831a5a0, user: 48/ISIS O/S info: user: someuser, term: SOMETTY01, ospid: 628:1948, machine: BOX\SOM ETTY01 program: someprogram.exe application name: someprogram.exe, hash value=0 last wait for 'db file sequential read' blocking sess=0x0 seq=1054 wait_time =16729 file#=1, block#=2ec3, blocks=1 temporary object counter: 0 When a specific program is being used, you may want to include that in your keyw ord search, whether it is an oracle client program or not; we sometimes provide information on third pa rty products in relation to Oracle on an 'as is' basis. Try to identify what type of program is being use d, these include JDBC (thin or OCI), Pro*C, OCI etc. Some problems are for example specific to JDBC an d this will help greatly in identifying the problem.

4.1 Use 'Advanced Search' ========================= To find relevant bug database entries (more likely to contain call stack trace m odules) always perform the Advanced search and make sure to check the 'Bug Database' check box from the 'sources' section on the right of the page, in addition to the 'Knowledge Base' which consists of the Notes written by Oracle personnel. Uncheck the 'Technical Forum' checkbox at first; when nothing is found in the kn owlege base and bug database, some relevant info maybe found in the forums (this is not to downplay the forums, they just ha ve a different use). The tips on the advanced search page provide further guidelines on how to search efficiently. 4.2 General Comments on Keyword Searches ======================================== The important thing is trial and error. When a search returns an overwhelming mo und of documents, try to narrow it down by including another keyword that is unique to your problem. On t he other hand, when no results are returned, omit a few; if you have included too many modules from a call stack trace, delet e some from your search but retain the topmost module(s); the specific module may have been called from a different one to your's when the bug was discovered or the call stack trace was not clearly do cumented in the bug. 4.3 No Relevant Bug or Document is Found ======================================== You may of course be the first customer to have hit an as yet undiscovered probl em. In that case, file a service request using Metalink and try to describe in detail what the problem is . You may also include a summary of the analysis that you have already performed based on these guideli nes. 4.4 Provide Feedback ==================== If you find documents that are unclear or you think contain errors, or if you th ink you can add some relevant information based on your experience using our products, please use the feedback button and state the document number and your comment (use the 'Technical Library feedback/questions' radio button in step 2). We are very grateful for quality feedback as it improves our knowledge base. 5.1 Correlate Bugs and Documents to Your Problem ================================================ Now that you have gained more understanding of the problem by browsing through t he trace file's relevant sections and have identified sufficiently suitable keywords both in terms of qua ntity and quality (uniqueness) you have executed your search and you are presented with some relevant documents . The Notes are usually clear enough; they go through a well defined process of QA and will provide you with detailed circumstances to match your problem. Bugs can be more cumbersome to read; try scrolling down to the bottom immediatel

y (click 'Go to End') to find the 'Rediscovery' or 'Release Note' section (or search for it) to match the bug desc ription with your specifics. A closed published bug should have such a section unless it is a duplicate of an other bug. In that case the base bug must be checked. For bugs resolved in 9.2 onwards there is often a summary note, with the reference .8, which is easier to read. You are hitting a certain bug if you can match all circumstances listed in the r ediscovery information to your problem AND the designated fix (either a patch or workaround) solves the problem. 6.0 Summary =========== Good search keywords include error messages, first arguments of internal errors and relevant internal module names. Program names and type may help narrow down further. Correlate wit h the documented rediscovery information. If unsure, file a service request with your findings, t his helps the analyst. References Note 153788.1 - Troubleshoot an ORA-600 or ORA-7445 Error Using the Error Lookup Tool Note 154170.1 - How to find the offending SQL from a trace file Note 156657.1 - How To Find Known Issues or BUGs Through a MetaLink Search Note 1812.1 - TECH: Getting a Stack Trace from a CORE file Note 153788.1 - Troubleshoot an ORA-600 or ORA-7445 Error Using the Error Lookup Tool Note 211909.1 - Customer Introduction to ORA-7445 Errors

----Note: ----Control file missing Example ORA-00202: ORA-27041: OSD-04002: O/S-Error: controlfile: 'g:\oradata\airm\control03.ctl' unable to open file unable to open file (OS 2) The system cannot find the file specified.

Sat May 24 20:02:40 2003 ORA-205 signalled during: alter database airm mount... If the databse is down: - Unix: Is it really missing or is the filesystem(s) where they are placed, just not mounted? - Windows: are all filesystems "up" and the drive letters as they used to be? Possible Solution: just copy one good controlfile to the exact location of the m issing one. Note this: if the "bad" controlfile seems to be at the "right" location, first m

ake a copy of it, before you copy a "good" controlfile over the "bad" controlfile. Or follow you regular rman recovery procedure. ----Note: ----alter system disable distributed recovery ORA-2019 ORA-2058 ORA-2068 ORA-2050: FAILED DISTRIBUTED TRANSACTIONS for step by step instructions on how to proceed. The above errors indicates that there is a failed distributed transaction that needs to be manually cleaned up. See In some cases, the instance may crash before the solutions are implemented. If this is the case, issue an 'alter system disable distributed recovery' immediately after the database starts to allow the database to run without having reco terminate the instance. ----Note: ----SVRMGR> connect internal SVRMGR> startup mount SVRMGR> SELECT df.name,bk.time FROM v$datafile df,v$backup bk 2> WHERE df.file# = bk.file# and bk.status = 'ACTIVE'; Shows the datafiles currently in a hot backup state. SVRMGR> alter database datafile 2> '/u03/oradata/PROD/devlPROD_1.dbf' end backup; Do an "end backup" on those listed hot backup datafiles. SVRMGR> alter database open; ----Note: ----Subject: ORA-600 [4147] Experienced When Performing Query From FLASHBACK_TRANSA CTION_QUERY Doc ID: 467144.1 Type: PROBLEM Modified Date : 13-MAY-2008 Status: PUBLISHED Applies to: Oracle Server - Enterprise Edition - Version: 10.2.0.2.0 This problem can occur on any platform. Symptoms While attempting to perform queries against the flashback_transaction_query tabl e, an ORA-600 [4147] is experienced. Example:

--------------select * from flashback_transaction_query where start_timestamp > sysdate -1/6 ORA-00600: internal error code, arguments: [4147], [6], [5] Stack trace is similar to the following: ---------------------------------------ksedst ksedmp ksfdmp kgeriv kgesiv ksesic2 kturef kcbgtcr ktuq_get_urec ktuqup_g et_startslo ktuqup_init ktuqqp_init ktuqfcbk qerfxFetch opifch2 opifch opiodr ttcpip opitsk opiino opiodr opidrv sou2o opimai _real main Cause This is unpublished Bug 5726687. This is a non-corruptive issue that occurs during the query in flashback because the query is being performed against the undo blocks while the transaction id is most likely in memory. This is why the ORA-600 [4147] error is generated as the block scn's do not match. This bug is fixed in 11g, however, it can be back-ported to 10.2.0.3. Solution To implement the solution, please execute the following steps: Apply Patch 5726687. If you'd like to check for Patch Availability from Metalink 1) 2) 3) 4) 5) Click on Patches & Updates Click on Simple Search Enter patch number: 5726687 Select your O/S Click Go.

----Note: ----Subject: Database Crashes With ORA-07445 [kgldtin:xxxx[kgl.c] [SIGSEGV] [Addres s not mapped to object] Doc ID: 551885.1 Type: PROBLEM Modified Date : 12-MAY-2008 Status: MODERATED Applies to: Oracle Server - Enterprise Edition - Version: 9.2.0.6 to 10.2.0.1 This problem can occur on any platform. Symptoms The database crashes after the following errors: ORA-07445: exception encountered: core dump [kgldtin:7285[kgl.c]] [SIGSEGV] [Add ress not mapped to object] [0x000000000] [] [] ORA-07445: exception encountered: core dump [kglobcl:2690[kgl2.c]] [SIGSEGV] [Ad

dress not mapped to object] [0x000000000] [] [] The call stack will look similar to the following: kgldtin kgldti kkdlgob qcsfgob qcsprfro qcspqb kkmdrv opiSem opiprs kksald rpisw u2 kkslod kglobld kglobpn kglpim kglpin kksfbc kkspsc0 opiosq0 . . . The PROCESS STATE section in the tracefile may show a latch is being held. For example: holding 455b66948 Child library cache level=5 child#=1 Location from where latch is held: kgldti: 2child: Context saved from call: 0 state=busy Changes This problem is introduced in 9.2.0.6 by the fix for unpublished Bug 3749490. A ny database with a one-off or merge patch containing the fix for unpublished Bug 3749490 can be affected. Cause The problem is caused by unpublished Bug 3949307 " SGA memory corruption / OERI :KGHALO4 with high concurrency," which is fixed in the 9.2.0.7 patchset. Solution The following solutions are available: 1. Upgrade to 11g, when released for your platform. 2. Upgrade to 10gR2/ 3. For 10gR1, apply a patchset on top of 10.1.0.2 10.1.0.5 recommended). 4. Apply one-off Patch 3949307 if available for your RDBMS version and OS platf orm. References Keywords KGLOBCL; KGLDTIN; ----Note: ----Database does not start (1) SGADEF.DBF LK.DBF -------------------------------------------------Note:1034037.6 Subject: ORA-01102: WHEN STARTING THE DATABASE Type: PROBLEM Status: PUBLISHED Content Type: TEXT/PLAIN Creation Date: 25-JUL-1997 Last Revision Date: 10-FEB-2000 Problem Description:

==================== You are trying to startup the database and you receive the following error: ORA-01102: cannot mount database in EXCLUSIVE mode Cause: Some other instance has the database mounted exclusive or shared. Action: Shutdown other instance or mount in a compatible mode. or scumnt: failed to lock /opt/oracle/product/8.0.6/dbs/lkSALES Fri Sep 13 14:29:19 2002 ORA-09968: scumnt: unable to lock file SVR4 Error: 11: Resource temporarily unavailable Fri Sep 13 14:29:19 2002 ORA-1102 signalled during: alter database mount... Fri Sep 13 14:35:20 2002 Shutting down instance (abort) Problem Explanation: ==================== A database is started in EXCLUSIVE mode by default. Therefore, the ORA-01102 error is misleading and may have occurred due to one of the following reasons: - there is still an "sgadef.dbf" file in the "ORACLE_HOME/dbs" directory - the processes for Oracle (pmon, smon, lgwr and dbwr) still exist - shared memory segments and semaphores still exist even though the database has been shutdown - there is a "ORACLE_HOME/dbs/lk" file Search Words: ============= ORA-1102, crash, immediate, abort, fail, fails, migration Solution Description: ===================== Verify that the database was shutdown cleanly by doing the following: 1. Verify that there is not a "sgadef.dbf" file in the directory "ORACLE_HOME/dbs". % ls $ORACLE_HOME/dbs/sgadef.dbf If this file does exist, remove it. % rm $ORACLE_HOME/dbs/sgadef.dbf 2. Verify that there are no background processes owned by "oracle" % ps -ef grep ora_ grep $ORACLE_SID

If background processes exist, remove them by using the Unix command "kill". For example:

% kill -9 3. Verify that no shared memory segments and semaphores that are owned by "oracle" still exist % ipcs -b If there are shared memory segments and semaphores owned by "oracle", remove the shared memory segments % ipcrm -m and remove the semaphores % ipcrm -s NOTE: The example shown above assumes that you only have one database on this machine. If you have more than one database, you will need to shutdown all other databases before proceeding with Step 4. 4. Verify that the "$ORACLE_HOME/dbs/lk" file does not exist 5. Startup the instance Solution Explanation: ===================== The "lk" It seems that still locked. oracle has of . ----Note: ----Note:1013221.6 Subject: RECOVERING FROM A LOST DATAFILE IN A ROLLBACK TABLESPACE Type: PROBLEM Status: PUBLISHED Content Type: TEXT/PLAIN Creation Date: 16-OCT-1995 Last Revision Date: 18-JUN-2002 Solution 1: --------------Error scenario: 1. 2. 3. 4. 5. set transaction use rollback segment rb1; INSERTS into's... SHUTDOWN ABORT; (simulate Media errors) Delete file rb1.ora (Tablespace RB1 with segment rb1 ); Restore a backup of the file and "sgadef.dbf" files are used for locking shared memory. even though no memory is allocated, Oracle thinks memory is By removing the "sgadef" and "lk" files you remove any knowledge shared memory that is in use. Now the database can start.

Recover: 1. comment out INIT.ORA ROLLBACK_SEGMENT parameter , so ORACLE does not try to find the incorrect segment rb1 2. STARTUP MOUNT 3. ALTER DATABASE DATAFILE 'rb1.ora' OFFLINE; 4. ALTER DATABASE OPEN # now we are in business 5. CREATE ROLLBACK SEGMENT rbtemp TABLESPACE SYSTEM; # We need Temporary RBS for further steps; 6. ALTER ROLLBACK SEGMENT rbtemp ONLINE; 7. RECOVER TABLESPACE RB1; 8. ALTER TABLESPACE RB1 ONLINE; 9. ALTER ROLLBACK SEGMENT rb1 ONLINE; 10. ALTER ROLLBACK SEGMENT rbtemp OFFLINE; 11. DROP ROLLBACK SEGMENT rbtemp; Result: Successfully rollback uncommitted Transactions, no suspect instance. Solution 2: --------------INTRODUCTION -----------Rollback segments can be monitored through the data dictionary view, dba_rollback_segs. There is a status column that describes what state the rollback segment is currently in. Normal states are either online or offline. Occasionally, the status of "needs recovery" will appear. When a rollback segment is in this state, bringing the rollback segment offline or online either through the alter rollback segment command or removing it FROM the rollback_segments parameter in the init.ora usually has no effect. UNDERSTANDING ------------A rollback segment falls into this status of needs recovery whenever Oracle tries to roll back an uncommitted transaction in its transaction table and fails. Here are some examples of why a transaction may need to rollback: 1-A user may do a dml transaction and decides to issue rollback 2-A shutdown abort occurs and the database needs to do an instance recovery in which case, Oracle has to roll back all uncommitted transactions. When a rollback of a transaction occurs, undo must be applied to the data block the modified row/s are in. If for whatever reason, that data block is unavailable, the undo cannot be applied. The result is a 'corrupted' rollback segment with the status of needs recovery. What could be some reasons a datablock is unaccessible for undo? 1-If a tablespace or a datafile is offline or missing. 2-If the object the datablock belongs to is corrupted. 3-If the datablock that is corrupt is actually in the rollback segment itself rather than the object. HOW TO RESOLVE IT

----------------1-MAKE sure that all tablespaces are online and all datafiles are online. This can be checked through v$datafile, under the status column. For tablespaces associated with the datafiles, look in dba_tablespaces. If that still does not resolve the problem then 2-PUT the following in the init.oraevent = "10015 trace name context forever, level 10" Setting this event will generate a trace file that will reveal the necessary information about the transaction Oracle is trying to roll back and most importantly, what object Oracle is trying to apply the undo to. 3-SHUTDOWN the database (if normal does not work, immediate, if that does not work, abort) and bring it back up. Note: An ora-1545 may be encountered, or other errors. If the database cannot startup, contact customer support at this point. 4-CHECK in the directory that is specified by the user_dump_dest parameter (in the init.ora or show parameter command) for a trace file that was generated at startup time. 5-IN the trace file, there should be a message similar toerror recovery tx(#,#) object #. TX(#,#) refers to transaction information. The object # is the same as the object_id in sys.dba_objects. 6-USE the following query to find out what object Oracle is trying to perform recovery on. SELECT owner, object_name, object_type, status FROM dba_objects WHERE object_id = ; 7-THIS object must be dropped so the undo can be released. An export or relying on a backup may be necessary to restore the object after the corrupted rollback segment goes away. 8-AFTER dropping the object, put the rollback segment back in the init.ora parameter rollback_segments, removed the event, and shutdown and startup the database. In most cases, the above steps will resolve the problematic rollback segment. If this still does not resolve the problem, it may be likely that the corruption is in the actual rollback segment. At this point, if the problem has not been resolved, please contact customer support. Solution 3: --------------Recovery FROM the loss of a Rollback segment datafile containing active transact ions