㈠ 為什麼我的電腦啟動不了oracle資料庫
法 1： 手動啟動 Oracle 資料庫服務
更改啟動行為的 Oracle 資料庫服務在運行 Oracle 資料庫的計算機上手動類型，然後手動啟動 Oracle 資料庫服務。 這樣做，請按照下列步驟操作：
Oracle 資料庫服務的啟動類型更改為手動方式。這樣做，請按照下列步驟操作：
單擊 開始，指向 設置，然後單擊 控制面板。
在 $ 控制面版中雙擊 管理工具。
在管理工具窗口中雙擊 服務。
在服務的右窗格窗口，雙擊 OracleService<sid>.
在 $ OracleService<sid>屬性中 (本地計算機) 對話框框中，單擊 常規 選項卡。
單擊 手動啟動鍵入 列表中，然後單擊 確定。
更改啟動設置的實例的 Oracle 資料庫如 Oracle 資料庫服務啟動時的 Oracle 資料庫實例未自動啟動。這樣做，請按照下列步驟。
重要此分區、 方法，或任務包含告訴您如何修改注冊表的步驟。但是，如果注冊表修改不當可能會出現嚴重問題。因此，請確保您仔細按照這些步驟。附加的保護注冊表之前先備份您對其進行修改。然後，您可以在出現問題時還原注冊表。有關如何備份和還原注冊表的詳細信息，請單擊下面的文章編號，以查看 Microsoft 知識庫中相應的文章：
322756 (http://support.microsoft.com/kb/322756/ ) 如何備份和還原在 Windows 注冊表
單擊 開始，然後單擊 運行。
在 打開 框中鍵入 regedit，然後單擊 確定。
在注冊表編輯器中找到以下注冊表項： HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\HOME0
注意數字零 (0) 不字母 o 以結束此注冊表項的名稱。
在注冊表編輯器的右窗格，雙擊 ORA_ <sid>_AUTOSTART.
注意： <sid>替換 Oracle 資料庫服務的名稱。
編輯字元串 對話框中在 數值數據 框中鍵入 FALSE，然後單擊 確定。
關閉注冊表編輯器。
以下的批處理文件創建名為 StartupOracleORCL.sql:
connect <username>/<password>
startup PFILE=<Full path of the INIT.ORA file for the instance of Oracle database>
exit
創建以下 Windows 批處理文件中關閉 net start < Oracle 服務名稱 > 步驟 3:
@echo off
net start <Oracle Service Name>
set ORACLE_SID=<Oracle SID>
svrmgrl @<Full path of startupOracleORCL.sql created in Step 3>
exit
注意您必須替換 < Oracle 服務名稱 > 和 < Oracle SID > 與 Oracle 資料庫服務名稱和的 Oracle 資料庫服務，SID 分別。
在命令提示符處運行 Orastart.bat 文件。
注意您可能會注意到 Oracle 資料庫的實例已成功啟動。
回到頂端
方法 2： 通過使用 Windows 資源工具包實用程序自動化 Oracle 服務的啟動
通過使用服務安裝程序實用程序 (Instsrv.exe） 和應用程序服務實用程序 (Srvany.exe） 作為自動啟動的 Oracle 服務，請按照下列步驟操作。
注意該服務安裝程序實用程序 (Instsrv.exe） 和應用程序服務實用程序 (Srvany.exe） 作為將包含在 Windows Server 2003 資源工具包。
下載並安裝 Windows 資源工具包實用程序。收起這個圖片展開這個圖片Download the Rktools.exe package now. (http://www.microsoft.com/downloads/details.aspx?FamilyID=9d467a69-57ff-4ae7-96ee-b18c4790cffd&DisplayLang=en)
創建一個文件夾來將 OracleStartup 上被命名為根的驅動器 c。
In the C:\OracleStartup folder, create a text file that is named OracleStartup.reg and that contains the following information:
REGEDIT4
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\OracleStartup\Parameters]
"Application"="C:\\OracleStartup\\OracleStartup.cmd"
[HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\HOME0]
"ORA_ORCL_AUTOSTART"=hex(2):34,00,36,00,2c,00,30,00,30,00,2c,00,34,00,31,00,2c,00,30,00,30,\
00,2c,00,34,00,63,00,2c,00,30,00,30,00,2c,00,35,00,33,00,2c,00,30,00,30,00,\
2c,00,34,00,35,00,2c,00,30,00,30,00,2c,00,30,00,30,00,2c,00,30,00,30,00,00,\
00
雙擊 C:\OracleStartup\Oracle.reg 文本文件，以將此信息導入到您的注冊表。
C:\OracleStartup 文件夾中創建名為 OracleStartup.cmd 的文本文件，並包含以下信息：
sleep 60
net start OracleServiceORCL
SET ORACLE_SID=ORCL
svrmgrl @C:\OracleStartup\OracleStartup.sql
sleep 15
EXIT
創建一個 C:\OracleStartup\OracleStartup.sql 的文本文件，其中包含以下信息：
connect internal/oracle
startup PFILE=C:\init.ora
筆記 的啟動參數必須包含 Init.ora 文件的完全限定的路徑。
重要C:\OracleStartup\OracleStartup.cmd 文件包含用戶憑據以明文形式。 因此，限制對管理員和 Oracle 服務啟動帳戶僅此文件的訪問。您可以通過配置在 Oracle 伺服器的 Windows 身份驗證來避免包括 C:\OracleStartup\OracleStartup.cmd 文件中的用戶憑據。 有關如何配置 Oracle 的 Windows 身份驗證獲得筆記： 60634.1 （贏得： 安裝操作系統身份驗證） 從 Oracle 公司。有關如何與 Oracle 公司的信息，請訪問以下網站：
http://www.oracle.com/ (http://www.oracle.com/)
作為服務啟動 OracleStartup，通過使用該 InstSrv.exe 和 $ SrvAny.exe 資源工具包實用程序，以及通過使用以下命令：
"是 Files\Resource Kit\instsrv.exe"OracleStartup"是 Files\Resource Kit\SRVAny.exe"
sc 配置"OracleServiceORCL"開始 = 請求
退出
重新啟動 Windows。
㈡ oracle資料庫打不開，怎麼解決
「對於資料庫而言，備份重於一切」是所有DBA心中謹記的格言，但現實環境千差萬別，企業的資料庫環境中數據備份空間不足，采購的存儲設備短期內無法到貨，甚至於雖然進行了備份但是卻在數據恢復過程中發現備份實際不可用等問題均屬常見的場景。
為了應對這些真實世界中常見的數據恢復困局，需要特殊的恢復手段才能恢復其ORACLE DB中的數據。可以應對在完全沒有備份情況下的SYSTEM表空間丟失、誤操作ORACLE數據字典表、由於斷電引起的數據字典不一致等資料庫無法順利打開的場景，也可以挽回誤截斷(Truncate)/刪除(Delete)/業務數據表等人為的誤操作，並從容恢復數據。
甚至於僅僅接觸過ORACLE資料庫幾天的非DBA 人員也可以輕松地使用PRM，這得益於PRM簡單的安裝、和全程圖形化的人機交互界面；實施恢復的人員不需要專業的資料庫知識，不需要學習任何命令，更無需了解資料庫底層的存儲結構。僅僅需要輕輕點擊幾下滑鼠就能從容恢復數據。
對比傳統恢復工具DUL，DUL是ORACLE原廠內部恢復工具，其使用需要通過ORACLE內部流程，一般僅有購買了ORACLE原廠的現場服務的用戶能夠在原廠工程師的協助下使用該工具。PRM打破了只有少數專業人士才能實施資料庫恢復任務的限制，極大地縮短了從資料庫故障到完整恢復數據的失敗時間,降低了企業恢復數據的總成本。
㈢ Oracle資料庫無響應故障處理方式
Oracle資料庫無響應故障處理方式
Oracle資料庫無響應故障，簡單地講就是資料庫實例不能響應客戶端發起的請求，客戶端提交一個SQL後，就一直處於等待資料庫實例返回結果的狀態。更嚴重的現象是客戶端根本不能連接到資料庫，發起一個連接請求後，一直處於等待狀態。Oracle資料庫無響應故障怎麼處理呢?下面跟我一起來學習Oracle資料庫無響應故障的處理方法吧!
無響應的故障現象一般有以下幾種：
1.Oracle的進程在等待某個資源或事件
這種現象一般可以從V$SESSION_WAT、V$LATCH、V$LATCHHOLDER等動態視圖中檢查進程正在等待的資源或事件，而被等待的資源或事件，一直都不能被獲取，甚至是很長時間都不可獲得。如果這個正在等待的進程持有了其他的資源，則會引起其他的進程等待，這樣就很可能引起實例中大范圍的會話發生等待。由於進程在等待資源或事件時，通常都處於SLEEP狀態，消耗的CPU資源非常少(在等待latch時要稍微多消耗一些CPU資源)，所以從OS來看，CPU的消耗並不高，甚至是非常低。
這種因為等待而引起的個別進程Hang，相對比較容易處理。
2. OracleProcess Spins
所謂Spin，就是指Oracle進程中的代碼在執行某個過程時，陷入了循環。在V$SESSION視圖中，往往可以看到Hang住的會話，一直處於“ACTIVE”狀態。對於這樣的會話，用“alter system kill session ‘sid,serial#’”命令也不能完全斷開會話，會話只能被標記為“killed”，會話會繼續消耗大量的CPU。進程Spins由於是在做循環，CPU的消耗非常大，從OS上明顯可以看到這樣的進程，通常會消耗整個CPU的資源。
而對於這樣的Hang住的會話，處理起來相對比較復雜，並且為了從根本上解決問題，需要超過DBA日常維護所需要的技能。
從故障范圍來看，無響應故障可以分為以下幾種情況：
1. 單個或部分會話(進程)Hang住
這種情況屬於小范圍的故障，業務影響相對較小，一般來說只會影響業務系統的個別模塊。在一個多應用系統的資料庫上面，如果Hang住的會話比較多，則影響的可能是其中的一個應用系統。這里有一個例外，如果Hang住的進程是系統後台進程，如pmon、smon等，則影響的范圍就非常大了，最終甚至會影響整個資料庫及所有應用系統。還有值得注意的是，即使是少部分會話Hang住，也要及時處理，否則極有可能會擴散到整個系統。
2. 單個資料庫實例Hang住
這種情況造成的影響非常大。在這個實例上的所有應用系統均受到嚴重影響，並且在找到根源並最終解決問題之前，資料庫實例往往須要重啟。
3. OPS或RAC中的多個實例或所有實例都Hang住
在這種情況下，即使是OPS或RAC，都已經沒辦法提供高可用特性了。使用這個資料庫的所有應用系統將不能繼續提供服務，這種情況往往須要重啟。
無響應故障成因分析
Oracle資料庫無響應，一般主要由以下幾種原因引起：
1. 資料庫主機負載過高，嚴重超過主機承受能力
比如應用設計不當，資料庫性能低下，活動會話數的大量增加，導致資料庫主機的負載迅速增加，資料庫不能正常操作，並最終Hang住;主機物理內存嚴重不足，引起大量的換頁，特別是在SGA中的內存被大量換出到虛擬內存時，資料庫實例往往就會Hang住。
2. 日常維護不當、不正確的操作引起資料庫Hang住
比如歸檔日誌的存儲空間滿，導致資料庫不能歸檔，引起資料庫Hang住;在一個大並發的繁忙的系
統上，對DML操作比較多的大表進行move、增加外鍵約束等操作也可能使系統在短時間內負載大幅升高，並引起資料庫系統Hang住;不正確的資源計劃(Resource Plan)配置，使進程得不到足夠的CPU等。
3. Oracle資料庫的Bug
幾乎每個版本都存在著會導致資料庫系統Hang住的Bug，這些Bug會在一些特定的條件下觸發，特別是在RAC資料庫中，引起資料庫Hang住的Bug比較多。
4. 其他方面的一些原因
比如在RAC資料庫中，如果一個節點退出或加入到RAC的過程中，當進行Resource Reconfiguration時，會使系統凍結一段時間，也有可能使系統Hang住。
以上所描述的幾種常見的會導致Oracle資料庫實例Hang住的原因中，大部分的情況是可以避免的，只要維護得當，一般不會出現這種故障。對於Oracle資料庫Bug所導致的資料庫無響應故障，由於是在特定的情況下才會觸發，所以如果能夠盡量對資料庫打上最新版本的補丁，並且熟悉當前版本中會導致系統Hang住的Bug以及觸發條件，就能夠最大限度地避免這種故障的發生，提高系統的可用性。
那麼，在資料庫Hang住的情況下，如何去分析並發現導致問題的根源?一方面，由於系統Hang住會導致業務系統不可用，為了能夠盡快地恢復業務，須快速地判斷問題所在，然後Kill掉引起故障的會話和進程，或者資料庫實例不得不重啟以迅速恢復業務;但另一方面，如果只是重啟資料庫或Kill會話和進程來解決問題，在很多情況下是治標不治本的辦法，在以後故障隨時可能會出現。如何在二者之間進行抉擇呢?對於資料庫Hang故障的處理，首先是盡可能地收集到系統Hang住時的狀態數據，然後盡快地恢復業務，恢復業務後分析收集到的數據，找到資料庫系統Hang住的真正原因，然後再進行相應的處理。下一節將詳細描述資料庫系統Hang住後的處理流程。
無響應故障處理流程
對於Oracle無響應故障的處理，我們可以按下圖所示的流程進行。
值得注意的是，上圖並不是一個完整的Oracle資料庫故障處理流程圖，只是處理Oralce資料庫無響應這一類特定的故障的流程，只列出了針對這一特定類型故障處理時的關鍵處理點。不過既然是故障，所以這類故障的處理流程與其他故障的處理流程，有著非常相似的地方。
下面是整個流程的詳細說明：
1. 在出現資料庫無響應故障後，首先確認系統的影響范圍，如上節所描述的'，是部分業務系統或模塊還是所有的業務系統都受影響，是不是整個實例或多個實例都無響應。同時應詢問系統維護和開發人員，受影響的系統在出現故障前是否有過變動，包括主機硬體、操作系統、網路、資料庫以及應用等。有時一個細小的變動就可能導致出現資料庫Hang住這樣嚴重的故障。曾經遇到一個庫，應用只是修改了一個SELECT語句就導致了資料庫Hang住。
2. 為了避免由於網路、資料庫監聽或客戶端因素影響分析，建議都登錄到主機上進行操作。
3. 如果主機不能登錄(為了避免干擾流程主線，這里不討論如網路問題這樣也會導致不能連接的故障)，嘗試關閉出現問題的業務系統，甚至是所有的業務系統。如果關閉了所有的業務系統之後，仍然不能連接，則只有考慮重新啟動資料庫主機。在資料庫主機重新啟動後，使用操作系統工具或OSW等長期監控操作系統的資源使用，同時監控Oracle資料庫的性能和等待等。
4. 登錄上主機後，先用top、topas等命令簡單觀察一下系統。看看系統的CPU使用、物理內存和虛擬內存的使用、IO使用等情況。
5. 使用SQLPLUS連接資料庫，如果不能連接，則只能從操作系統上觀察系統中是否有異常的現象，比如佔用CPU過高的進程。使用gdb、dbx等debugger工具對資料庫進行system state mp;使用strace、truss等工具檢查異常進程的系統調用;使用pstack、procstack等工具察看異常進程的call stack等。
6. 使用SQLPLUS連接上資料庫後，進行hanganalyze、system state mp等操作;或檢查等待事件、異常會話等正在執行的SQL等待。
7. 找到故障產生的原因，如果暫時找不到原因，盡量收集數據。
8.確良如果應用急須恢復，可通過Kill會話、重啟資料庫實例等方式，先恢復應用。
9. 根據最終診斷結果，對資料庫升級打補丁，或者修改應用等方式從根本上解決問題。
怎樣避免資料庫出現無響應故障
作為Oracle資料庫DBA，除了處理故障之外，更重要的是如何預防故障的發生。根據前面對資料庫無響應故障的成因分析，在日常的維護工作中，須做到以下幾點：
1. 進行正確的維護操作
很多的資料庫無響應故障都是由於不正確的維護操作引起的。應避免在業務高峰期做大的維護操作，比如像move、加主外鍵約束等會長時間鎖表的操作。如果的確需要，盡量使用正確的操作方法。比如用ONLINE方式重建索引;建主鍵、唯一鍵約束時先建索引，然後在建約束時指定新建的索引，等等。也就是保證系統的並發性、可伸縮性，避免系統串列操作的出現。
2. 優化應用設計，優化資料庫性能
為避免性能問題導致在業務高峰期資料庫不能及時有效處理來自業務的請求，甚至於完全Hang住。對於資料庫中存在串列訪問的部分進行優化，比如latch、enqueue，還包括不合理的sequence設計等。特別是在RAC資料庫中，嚴重串列訪問等待往往更容易引起嚴重的性能問題。優化應用設計，使資料庫具有更好的可伸縮性和並行處理能力，能夠有效地避免性能問題引起的資料庫Hang住。
3. 利用監控系統隨時監控系統負載
遇到系統負載過高，內存不足，OS中虛擬內存換頁很頻繁等情況時，及時採取措施;監控Oracle資料庫的核心進程，如pmon、smon等，看是否有異常，如過高的CPU消耗。出現異常應立即處理;監控歸檔空間和日誌切換;監控資料庫中的等待事件，比如是否有大量的enqueue、log file switch (archiving needed)、resmgr:become active等待事件等。
4. 為資料庫打上補丁
很多的無響應故障是由於Oracle的Bug引起的，資料庫DBA應關注當前版本中有哪些Bug會導致資料庫Hang住，盡量為資料庫打上解決這些Bug的補丁。
;㈣ oracle 資料庫啟動失敗，該怎麼辦
PRM-DUL 可以直接從Oracle .DBF數據文件中抽取出表的數據。
Oracle DBA神器：PRM災難恢復工具，Schema級別數據恢復。PRM For Oracle Database – schema級別oracle資料庫數據恢復特性 ，PRM即ParnassusData Recovery Manager是企業級別Oracle資料庫災難恢復工具。PRM可以在無備份的情況下恢復被truncated掉的表，也可以恢復無法打開的Oracle資料庫(Alter Database Open失敗)中的數據。
㈤ oracle 資料庫異常停止，現在不能啟動資料庫
1，首先排除設置了正確的SID連接
如：C:\Users\Administrator>set ORACLE_SID = orcl //確定本機資料庫實例名
linux下用export ORACLE_SID=orcl
2，以sysdba連接，關閉資料庫
sqlplus / as sysdba
shutdown immediate
如果不能關閉，windows下殺掉oracle進程，停掉oracle的服務
linux下：ps -ef|grep smon找到對應的pid
kill -9 <pid>
3,重新啟動試試
startup
如果還是不行，查看報錯原因，這里可能有很多，比如數據文件錯誤
4.這里假如你的錯誤是數據文件引起
shutdown immediate
startup mount
recover datafile <datafile number>;
alter database open;
就可以了
如果不是數據文件錯誤，貼出來看看吧
㈥ Oracle資料庫打不開 該怎麼辦我們公司的oracle資料庫壞了 打不開了，該如何處理
如果自己搞不定可以找詩檀軟體專業ORACLE資料庫修復團隊成員幫您恢復!
詩檀軟體專業資料庫修復團隊
Oracle的損壞/壞塊 主要分以下幾種：
ORA-1578
ORA-8103
ORA-1410
ORA-1499
ORA-1578
ORA-81##
ORA-14##
ORA-26040
ORA-600 Errors
Block Corruption
Index Corruption
Row Corruption
UNDO Corruption
Control File
Consistent Read
Dictionary
File/RDBA/BL
Error Description Corruption related to:
ORA-1578 ORA-1578一般為Oracle檢測到存在物理壞塊問題，包括其檢測數據塊中的checksum不正確，或者tail_chk信息不正確等。 ORA-1578 is reported when a block is thought to be corrupt on read.
Block
數據塊
OERR: ORA-1578 「ORACLE data block corrupted (file # %s, block # %s)」 Master Note
OERR: ORA-1578 「ORACLE data block corrupted (file # %s, block # %s)」
Fractured Block explanation
Handling Oracle Block Corruptions in Oracle7/8/8i/9i/10g/11g
Diagnosing and Resolving 1578 reported on a Local Index of a Partitioned table
ORA-1410
ORA-1410錯誤常見於從INDEX或其他途徑獲得的ROWID,到數據表中查詢發現沒有對應的記錄。
該錯誤可能因為數據表與其索引存在不一致，也可能是分區的數據表本身存在問題。
This error is raised when an operation refers to a ROWID in a table for which there is no such row.
The reference to a ROWID may be implicit from a WHERE CURRENT OF clause or directly from a WHERE ROWID=… clause.
ORA 1410 indicates the ROWID is for a BLOCK that is not part of this table.
Row
數據行
Understanding The ORA-1410
Summary Of Bugs Containing ORA 1410
OERR: ORA 1410 「invalid ROWID」
ORA-8103
該ORA-8103可能由多個BUG引起，例如LOB在10.2.0.4之前可能會由於BUG覆蓋了另一張表的segment header，導致出現ORA-8103錯誤。
診斷該問題可以從數據表的segment header和data_object_id入手。
The object has been deleted by another user since the operation began.
If the error is reprocible, following may be the reasons:-
a.) The header block has an invalid block type.
b.) The data_object_id (seg/obj) stored in the block is different than the data_object_id stored in the segment header. See dba_objects.data_object_id and compare it to the decimal value stored in the block (field seg/obj).
Block
數據塊
ORA-8103 Troubleshooting, Diagnostic and Solution
OERR: ORA-8103 「object no longer exists」 / Troubleshooting, Diagnostic and Solution
ORA-8102 ORA-8102常見於索引鍵值與表上存的值不一致。 An ORA-08102 indicates that there is a mismatch between the key(s) stored in the index and the values stored in the table. What typically happens is the index is built and at some future time, some type of corruption occurs, either in the table or index, to cause the mismatch.
Index
索引
OERR ORA-8102 「index key not found, obj# %s, file %s, block %s (%s)
ORA-1499 對表和索引做交叉驗證時發現問題 An error occurred when validating an index or a table using the ANALYZE command.
One or more entries does not point to the appropriate cross-reference.
Index
索引
ORA-1499. Table/Index row count mismatch
OERR: ORA-1499 table/Index Cross Reference Failure – see trace file
ORA-1498 Generally this is a result of an ANALYZE … VALIDATE … command.
This error generally manifests itself when there is inconsistency in the data/Index block. Some of the block check errors that may be found:-
a.) Row locked by a non-existent transaction
b.) The amount of space used is not equal to block size
c.) Transaction header lock count mismatch.
While support are processing the tracefile it may be worth the re-running the ANALYZE after restarting the database to help show if the corruption is consistent or if it 『moves』.
Send the tracefile to support for analysis.
If the ANALYZE was against an index you should check the whole object. Eg: Find the tablename and execute:
ANALYZE TABLE xxx VALIDATE STRUCTURE CASCADE; Block
OERR: ORA 1498 「block check failure – see trace file」
ORA-26040 由於採用過nologging/unrecoverable選項的redo生成機制，且做過對應的recover，導致數據塊中被填滿了0XFF，導致報錯ORA-26040。 Trying to access data in block that was loaded without redo generation using the NOLOGGING/UNRECOVERABLE option.
This Error raises always together with ORA-1578
Block
數據塊
OERR ORA-26040 Data block was loaded using the NOLOGGING option
ORA-1578 / ORA-26040 Corrupt blocks by NOLOGGING – Error explanation and solution
ORA-1578 ORA-26040 in a LOB segment – Script to solve the errors
ORA-1578 ORA-26040 in 11g for DIRECT PATH with NOARCHIVELOG even if LOGGING is enabled
ORA-1578 ORA-26040 On Awr Table
Errors ORA-01578, ORA-26040 On Standby Database
Workflow Tables ORA-01578 ORACLE data block corrupted ORA-26040 Data block was loaded using the NOLOGGING option
ORA-1578, ORA-26040 Data block was loaded using the NOLOGGING option
ORA-600[12700]
從索引獲得的ROWID，對應到數據表時發現不存在數據行錯誤。
一把是一致性度consistent read問題
Oracle is trying to access a row using its ROWID, which has been obtained from an index.
A mismatch was found between the index rowid and the data block it is pointing to. The rowid points to a non-existent row in the data block. The corruption can be in data and/or index blocks.
ORA-600 [12700] can also be reported e to a consistent read (CR) problem.
Consistent Read
一致性讀
Resolving an ORA-600 [12700] error in Oracle 8 and above.
ORA-600 [12700] 「Index entry Points to Missing ROWID」
ORA-600[3020] 主要問題是redo和數據塊中的信息不一致 This is called a 『STUCK RECOVERY』.
There is an inconsistency between the information stored in the redo and the information stored in a database block being recovered. Redo
ORA-600 [3020] 「Stuck Recovery」
Information Required for Root Cause Analysis of ORA-600 [3020] (stuck recovery)
ORA-600[4194] 主要是redo記錄與回滾rollback/undo的記錄不一致 A mismatch has been detected between Redo records and rollback (Undo) records.
We are validating the Undo record number relating to the change being applied against the maximum undo record number recorded in the undo block.
This error is reported when the validation fails. Undo
ORA-600 [4194] 「Undo Record Number Mismatch While Adding Undo Record」
Basic Steps to be Followed While Solving ORA-00600 [4194]/[4193] Errors Without Using Unsupported parameter
ORA-600[4193] 主要是redo記錄與回滾rollback/undo的記錄不一致 A mismatch has been detected between Redo records and Rollback (Undo) records.
We are validating the Undo block sequence number in the undo block against the Redo block sequence number relating to the change being applied.
This error is reported when this validation fails. Undo
ORA-600 [4193] 「seq# mismatch while adding undo record」
Basic Steps to be Followed While Solving ORA-00600 [4194]/[4193] Errors Without Using Unsupported parameter
Ora-600 [4193] When Opening Or Shutting Down A Database
ORA-600 [4193] When Trying To Open The Database
ORA-600[4137] transaction id不匹配，問題可能存在與回滾段中或者對象本身存在訛誤 While backing out an undo record (i.e. at the time of rollback) we found a transaction id mis-match indicating either a corruption in the rollback segment or corruption in an object which the rollback segment is trying to apply undo records on.
This would indicate a corrupted rollback segment. Undo/Redo
ORA-600 [4137] 「XID in Undo and Redo Does Not Match」
ORA-600[6101] Not enough free space was found when inserting a row into an index leaf block ring the application of undo. Index
ORA-600 [6101] 「insert into leaf block (undo)」
ORA-600[2103] Oracle is attempting to read or update a generic entry in the control file.
If the entry number is invalid, ORA-600 [2130] is logged. Control File
ORA-600 [2130] 「Attempt to access non-existant controlfile entry」
ORA-600[4512] Oracle is checking the status of transaction locks within a block.
If the lock number is greater than the number of lock entries, ORA-600 [4512] is reported followed by a stack trace, process state and block mp.
This error possibly indicates a block corruption. Block
ORA-600 [4512] 「Lock count mismatch」
ORA-600[2662] 主要是發現一個數據塊的SCN甚至超過了當前SCN，常規解決途徑有調整SCN等，但11.2以後Oracle公司使較多調整SCN的方法失效了 A data block SCN is ahead of the current SCN.
The ORA-600 [2662] occurs when an SCN is compared to the dependent SCN stored in a UGA variable.
If the SCN is less than the dependent SCN then we signal the ORA-600 [2662] internal error. Block
ORA-600 [2662] 「Block SCN is ahead of Current SCN」
ORA 600 [2662] DURING STARTUP
ORA-600[4097] 訪問一個回滾段頭以便確認事務是否已提交時，發現XID有問題 We are accessing a rollback segment header to see if a transaction has been committed.
However, the xid given is in the future of the transaction table.
This could be e to a rollback segment corruption issue OR you might be hitting the following known problem. Undo