Oracle打不開，求大神們幫幫忙。

試試這個(gè)方法：

創(chuàng)新互聯(lián)建站主要從事成都做網(wǎng)站、成都網(wǎng)站設(shè)計(jì)、網(wǎng)頁(yè)設(shè)計(jì)、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務(wù)。立足成都服務(wù)祁連,十載網(wǎng)站建設(shè)經(jīng)驗(yàn),價(jià)格優(yōu)惠、服務(wù)專業(yè),歡迎來電咨詢建站服務(wù):028-86922220

使用32位InstantClient，PL/SQL Developer連接Oracle：

?1. 下載32位Oracle InstantClient，并展開到某目錄，例如C:\instantclient-basic-nt-11.2.0.2.0；

?2. 將系統(tǒng)的tnsnames.ora拷貝到該目錄下；

?3. 在PLSQL Developer中設(shè)置Oracle_Home和OCI Library：

Tools?Preferences?Oracle?Connection：

Oracle_Home： C:\instantclient-basic-nt-11.2.0.2.0

OCI Library： C:\instantclient-basic-nt-11.2.0.2.0\oci.dll

?4. 在PLSQL Developer目錄下新建如下bat文件，替換其快捷方式，啟動(dòng)PLSQL Developer：

@echo off

set path=C:\instantclient-basic-nt-11.2.0.2.0

set ORACLE_HOME=C:\instantclient-basic-nt-11.2.0.2.0

set TNS_ADMIN=C:\instantclient-basic-nt-11.2.0.2.0

set NLS_LANG=AMERICAN_AMERICA.ZHS16GBK

start plsqldev.exe

oracle analytics desktop 一直打不開

參數(shù)設(shè)置不當(dāng)。

造成Oracle數(shù)據(jù)庫(kù)打不開，無法打開的情況大致有幾種，參數(shù)設(shè)置不當(dāng)，控制文件損壞，日志文件損壞，數(shù)據(jù)文件頭損壞，數(shù)據(jù)字典損壞，UNDO損壞，SMON回滾事務(wù)時(shí)遇到問題，如果自己搞不定可以找軟件專業(yè)ORACLE數(shù)據(jù)庫(kù)修復(fù)團(tuán)隊(duì)幫您恢復(fù)。

Oracle數(shù)據(jù)庫(kù)打不開 該怎么辦？我們公司的oracle數(shù)據(jù)庫(kù)壞了 打不開了，該如何處理？

如果自己搞不定可以找詩(shī)檀軟件專業(yè)ORACLE數(shù)據(jù)庫(kù)修復(fù)團(tuán)隊(duì)成員幫您恢復(fù)!

詩(shī)檀軟件專業(yè)數(shù)據(jù)庫(kù)修復(fù)團(tuán)隊(duì)

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檢測(cè)到存在物理壞塊問題，包括其檢測(cè)數(shù)據(jù)塊中的checksum不正確，或者tail_chk信息不正確等。 ORA-1578 is reported when a block is thought to be corrupt on read.

Block

數(shù)據(jù)塊

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錯(cuò)誤常見于從INDEX或其他途徑獲得的ROWID,到數(shù)據(jù)表中查詢發(fā)現(xiàn)沒有對(duì)應(yīng)的記錄。

該錯(cuò)誤可能因?yàn)閿?shù)據(jù)表與其索引存在不一致，也可能是分區(qū)的數(shù)據(jù)表本身存在問題。

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

數(shù)據(jù)行

Understanding The ORA-1410

Summary Of Bugs Containing ORA 1410

OERR: ORA 1410 “invalid ROWID”

ORA-8103

該ORA-8103可能由多個(gè)BUG引起，例如LOB在10.2.0.4之前可能會(huì)由于BUG覆蓋了另一張表的segment header，導(dǎo)致出現(xiàn)ORA-8103錯(cuò)誤。

診斷該問題可以從數(shù)據(jù)表的segment header和data_object_id入手。

The object has been deleted by another user since the operation began.

If the error is reproducible, 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

數(shù)據(jù)塊

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 對(duì)表和索引做交叉驗(yàn)證時(shí)發(fā)現(xiàn)問題 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選項(xiàng)的redo生成機(jī)制，且做過對(duì)應(yīng)的recover，導(dǎo)致數(shù)據(jù)塊中被填滿了0XFF，導(dǎo)致報(bào)錯(cuò)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

數(shù)據(jù)塊

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，對(duì)應(yīng)到數(shù)據(jù)表時(shí)發(fā)現(xiàn)不存在數(shù)據(jù)行錯(cuò)誤。

一把是一致性度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 due 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和數(shù)據(jù)塊中的信息不一致 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不匹配，問題可能存在與回滾段中或者對(duì)象本身存在訛誤 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 during 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 dump.

This error possibly indicates a block corruption. Block

ORA-600 [4512] “Lock count mismatch”

ORA-600[2662] 主要是發(fā)現(xiàn)一個(gè)數(shù)據(jù)塊的SCN甚至超過了當(dāng)前SCN，常規(guī)解決途徑有調(diào)整SCN等，但11.2以后Oracle公司使較多調(diào)整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] 訪問一個(gè)回滾段頭以便確認(rèn)事務(wù)是否已提交時(shí)，發(fā)現(xiàn)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 due to a rollback segment corruption issue OR you might be hitting the following known problem. Undo

oracle數(shù)據(jù)庫(kù)打不開，怎么解決

“對(duì)于數(shù)據(jù)庫(kù)而言，備份重于一切”是所有DBA心中謹(jǐn)記的格言，但現(xiàn)實(shí)環(huán)境千差萬(wàn)別，企業(yè)的數(shù)據(jù)庫(kù)環(huán)境中數(shù)據(jù)備份空間不足，采購(gòu)的存儲(chǔ)設(shè)備短期內(nèi)無法到貨，甚至于雖然進(jìn)行了備份但是卻在數(shù)據(jù)恢復(fù)過程中發(fā)現(xiàn)備份實(shí)際不可用等問題均屬常見的場(chǎng)景。

為了應(yīng)對(duì)這些真實(shí)世界中常見的數(shù)據(jù)恢復(fù)困局，需要特殊的恢復(fù)手段才能恢復(fù)其ORACLE DB中的數(shù)據(jù)?？梢詰?yīng)對(duì)在完全沒有備份情況下的SYSTEM表空間丟失、誤操作ORACLE數(shù)據(jù)字典表、由于斷電引起的數(shù)據(jù)字典不一致等數(shù)據(jù)庫(kù)無法順利打開的場(chǎng)景，也可以挽回誤截?cái)?Truncate)/刪除(Delete)/業(yè)務(wù)數(shù)據(jù)表等人為的誤操作，并從容恢復(fù)數(shù)據(jù)。

甚至于僅僅接觸過ORACLE數(shù)據(jù)庫(kù)幾天的非DBA 人員也可以輕松地使用PRM，這得益于PRM簡(jiǎn)單的安裝、和全程圖形化的人機(jī)交互界面；實(shí)施恢復(fù)的人員不需要專業(yè)的數(shù)據(jù)庫(kù)知識(shí)，不需要學(xué)習(xí)任何命令，更無需了解數(shù)據(jù)庫(kù)底層的存儲(chǔ)結(jié)構(gòu)。僅僅需要輕輕點(diǎn)擊幾下鼠標(biāo)就能從容恢復(fù)數(shù)據(jù)。

對(duì)比傳統(tǒng)恢復(fù)工具DUL，DUL是ORACLE原廠內(nèi)部恢復(fù)工具，其使用需要通過ORACLE內(nèi)部流程，一般僅有購(gòu)買了ORACLE原廠的現(xiàn)場(chǎng)服務(wù)的用戶能夠在原廠工程師的協(xié)助下使用該工具。PRM打破了只有少數(shù)專業(yè)人士才能實(shí)施數(shù)據(jù)庫(kù)恢復(fù)任務(wù)的限制，極大地縮短了從數(shù)據(jù)庫(kù)故障到完整恢復(fù)數(shù)據(jù)的失敗時(shí)間,降低了企業(yè)恢復(fù)數(shù)據(jù)的總成本。