2. 程式人生 > >解決ORA-01111, ORA-01110, ORA-01157

解決ORA-01111, ORA-01110, ORA-01157

阿新 • • 發佈：2018-12-25

在備用資料庫中建立檔案為UNNAMED或MISSING的原因有很多，包括備用站點上的磁碟空間不足（或）與檔案管理相關的不正確的引數設定。

STANDBY_FILE_MANAGEMENT啟用或禁用自動備用檔案管理。啟用自動備用檔案管理後，將在備用資料庫上覆制主資料庫上的作業系統檔案新增和刪除。

例如，如果我們在主伺服器上將引數STANDBY_FILE_MANAGEMENT設定為MANUAL時在主伺服器上新增資料檔案，而恢復過程（MRP）正在嘗試應用存檔，由於該引數設定，它將在$ ORACLE_HOME / dbs中建立一個未命名的檔案將導致殺死MRP程序，錯誤將如下所示。

警報日誌檔案中的錯誤： -

#limsdbdg例項alert日誌告警資訊
AUDIT_TRAIL initialization parameter is changed to OS, as DB is NOT compatible for database opened with read-only access
Beginning Standby Crash Recovery.
Serial Media Recovery started
Managed Standby Recovery starting Real Time Apply
Standby Crash Recovery aborted due to error 1111.
Errors in file /app/oracle/diag/rdbms/lmisdbdg/lmisdbdg/trace/lmisdbdg_ora_5174.trc:
ORA-01111: name for data file 5 is unknown - rename to correct file
ORA-01110: data file 5: '/app/oracle/product/11.2.4/db_1/dbs/UNNAMED00005'
ORA-01157: cannot identify/lock data file 5 - see DBWR trace file
ORA-01111: name for data file 5 is unknown - rename to correct file
ORA-01110: data file 5: '/app/oracle/product/11.2.4/db_1/dbs/UNNAMED00005'
Completed Standby Crash Recovery.
Errors in file /app/oracle/diag/rdbms/lmisdbdg/lmisdbdg/trace/lmisdbdg_ora_5174.trc:
ORA-10458: standby database requires recovery
ORA-01157: cannot identify/lock data file 5 - see DBWR trace file
ORA-01111: name for data file 5 is unknown - rename to correct file
ORA-01110: data file 5: '/app/oracle/product/11.2.4/db_1/dbs/UNNAMED00005'
ORA-10458 signalled during: alter database open...

跟蹤檔案： - 

*** 2018-12-11 09:40:38.470
ORA-01110: data file 5: '/app/oracle/product/11.2.4/db_1/dbs/UNNAMED00005'
Managed Recovery: Real Time Apply enabled.
Managed Recovery: Startup posted.
Managed Recovery: Initialization posted.

*** 2018-12-11 09:40:38.470
Started Serial Media Recovery
*** 2018-12-11 09:40:38.479 4329 krsh.c
Managed Standby Recovery starting Real Time Apply
DDE: Problem Key 'ORA 1110' was flood controlled (0x1) (no incident)
ORA-01110: data file 5: '/app/oracle/product/11.2.4/db_1/dbs/UNNAMED00005'
DDE: Problem Key 'ORA 1110' was flood controlled (0x1) (no incident)
ORA-01110: data file 5: '/app/oracle/product/11.2.4/db_1/dbs/UNNAMED00005'
ORA-01157: cannot identify/lock data file 5 - see DBWR trace file
ORA-01111: name for data file 5 is unknown - rename to correct file
ORA-01110: data file 5: '/app/oracle/product/11.2.4/db_1/dbs/UNNAMED00005'
ORA-01111: name for data file 5 is unknown - rename to correct file
ORA-01110: data file 5: '/app/oracle/product/11.2.4/db_1/dbs/UNNAMED00005'
ORA-01157: cannot identify/lock data file 5 - see DBWR trace file
ORA-01111: name for data file 5 is unknown - rename to correct file
ORA-01110: data file 5: '/app/oracle/product/11.2.4/db_1/dbs/UNNAMED00005'

*** 2018-12-11 09:40:38.502
Completed Media Recovery
Managed Recovery: Not Active posted.
DDE: Problem Key 'ORA 1110' was flood controlled (0x1) (no incident)
ORA-01110: data file 5: '/app/oracle/product/11.2.4/db_1/dbs/UNNAMED00005'
ORA-10458: standby database requires recovery
ORA-01157: cannot identify/lock data file 5 - see DBWR trace file
ORA-01111: name for data file 5 is unknown - rename to correct file
ORA-01110: data file 5: '/app/oracle/product/11.2.4/db_1/dbs/UNNAMED00005'
Managed Recovery: Real Time Apply enabled.

*** 2018-12-11 14:34:34.181
Managed Recovery: THROUGH ALL SWITCHOVER posted.
Managed Recovery: DISCONNECT posted.
Managed Recovery: Startup posted.

*** 2018-12-11 14:44:39.505
Managed Recovery: Cancel posted.

*** 2018-12-11 14:44:56.218
Managed Recovery: Real Time Apply enabled.
Managed Recovery: THROUGH ALL SWITCHOVER posted.
Managed Recovery: DISCONNECT posted.
Managed Recovery: Startup posted.

 故障排除： -

檢查是否需要恢復檔案。

SQL> select * from v$recover_file where error like '%FILE%';

     FILE# ONLINE  ONLINE_ ERROR								CHANGE# TIME
---------- ------- ------- ----------------------------------------------------------------- ---------- -------------------
	 5 ONLINE  ONLINE  FILE MISSING 							      0
	 6 ONLINE  ONLINE  FILE MISSING 							      0

確認主庫資料檔案

SQL> select file#,name from v$datafile where file# in (5,6);

     FILE# NAME
---------- ------------------------------------------------------------------
	 5 /oradata/lmis/LMIS01.dbf
	 6 /oradata/lmis/LMIS02.dbf

識別在（備庫）中建立的虛擬檔名

SQL> select file#,name from v$datafile where file# in (5,6);

     FILE# NAME
---------- ------------------------------------------------------------------
	 5 /app/oracle/product/11.2.4/db_1/dbs/UNNAMED00005
	 6 /app/oracle/product/11.2.4/db_1/dbs/UNNAMED00006

檢查沒有執行MRP，並且在待機狀態下建立檔案後可以啟用STANDBY_FILE_MANAGEMENT

SQL> alter system set standby_file_management=manual scope=both;

System altered.

SQL> alter database create datafile'/app/oracle/product/11.2.4/db_1/dbs/UNNAMED00005' as '/oradata/lmisdbdg/LMIS01.dbf';

Database altered.

SQL> alter database create datafile'/app/oracle/product/11.2.4/db_1/dbs/UNNAMED00006' as '/oradata/lmisdbdg/LMIS02.dbf';

Database altered.

 檢查虛擬檔案是否被修復

SQL> select * from v$recover_file where error like '%FILE%';

no rows selected

啟用S​​TANDBY_FILE_MANAGEMENT為AUTO並啟動MRP。

SQL> show parameter standby_file_management

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
standby_file_management 	     string	 MANUAL
SQL> alter system set standby_file_management=AUTO scope=both;

System altered.

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;

Database altered.

建立檔案後，MRP將開始在備用資料庫上應用存檔。

#lmisdbdg例項修復過程中的日誌資訊
Tue Dec 11 14:21:23 2018
alter database recover managed standby database cancel
ORA-16136 signalled during: alter database recover managed standby database cancel...
Tue Dec 11 14:23:12 2018
alter database create datafile'/app/oracle/product/11.2.4/db_1/dbs/UNNAMED00005' as '/oradata/lmisdbdg/LMIS01.dbf'
ORA-1275 signalled during: alter database create datafile'/app/oracle/product/11.2.4/db_1/dbs/UNNAMED00005' as '/oradata/lmisdbdg/LMIS01.dbf'...
Tue Dec 11 14:23:47 2018
ALTER SYSTEM SET standby_file_management='MANUAL' SCOPE=BOTH;
alter database create datafile'/app/oracle/product/11.2.4/db_1/dbs/UNNAMED00005' as '/oradata/lmisdbdg/LMIS01.dbf'
Tue Dec 11 14:24:07 2018
Completed: alter database create datafile'/app/oracle/product/11.2.4/db_1/dbs/UNNAMED00005' as '/oradata/lmisdbdg/LMIS01.dbf'
Tue Dec 11 14:24:33 2018
alter database create datafile'/app/oracle/product/11.2.4/db_1/dbs/UNNAMED00006' as '/oradata/lmisdbdg/LMIS02.dbf'
Tue Dec 11 14:24:43 2018
Completed: alter database create datafile'/app/oracle/product/11.2.4/db_1/dbs/UNNAMED00006' as '/oradata/lmisdbdg/LMIS02.dbf'
Tue Dec 11 14:34:17 2018
ALTER SYSTEM SET standby_file_management='AUTO' SCOPE=BOTH;
Tue Dec 11 14:34:34 2018
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION
Attempt to start background Managed Standby Recovery process (lmisdbdg)
Tue Dec 11 14:34:34 2018
MRP0 started with pid=52, OS id=15498 
MRP0: Background Managed Standby Recovery process started (lmisdbdg)
 started logmerger process
Tue Dec 11 14:34:39 2018
Managed Standby Recovery starting Real Time Apply
Parallel Media Recovery started with 20 slaves
Waiting for all non-current ORLs to be archived...
All non-current ORLs have been archived.
Media Recovery Log /arch/1_21_992735965.arc
Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION
Tue Dec 11 14:34:49 2018
Recovery created file /oradata/lmisdbdg/LMIS_HIS01.dbf
Successfully added datafile 7 to media recovery
Datafile #7: '/oradata/lmisdbdg/LMIS_HIS01.dbf'
Recovery created file /oradata/lmisdbdg/INF01.dbf
Successfully added datafile 8 to media recovery
Datafile #8: '/oradata/lmisdbdg/INF01.dbf'
Tue Dec 11 14:35:01 2018
Recovery created file /oradata/lmisdbdg/WCS01.dbf
Successfully added datafile 9 to media recovery
Datafile #9: '/oradata/lmisdbdg/WCS01.dbf'
Tue Dec 11 14:35:13 2018
Recovery created file /oradata/lmisdbdg/LMIS_HIS02.dbf
Successfully added datafile 10 to media recovery
Datafile #10: '/oradata/lmisdbdg/LMIS_HIS02.dbf'
Recovery created file /oradata/lmisdbdg/LMIS_HIS03.dbf
Successfully added datafile 11 to media recovery
Datafile #11: '/oradata/lmisdbdg/LMIS_HIS03.dbf'
Tue Dec 11 14:35:25 2018
Media Recovery Log /arch/1_22_992735965.arc
Media Recovery Log /arch/1_23_992735965.arc
Media Recovery Log /arch/1_24_992735965.arc
Media Recovery Log /arch/1_25_992735965.arc
Tue Dec 11 14:35:37 2018
Media Recovery Log /arch/1_26_992735965.arc
Media Recovery Log /arch/1_27_992735965.arc
Media Recovery Log /arch/1_28_992735965.arc
Media Recovery Log /arch/1_29_992735965.arc
Tue Dec 11 14:35:49 2018
Media Recovery Log /arch/1_30_992735965.arc
Media Recovery Log /arch/1_31_992735965.arc
Media Recovery Log /arch/1_32_992735965.arc
Media Recovery Log /arch/1_33_992735965.arc
Media Recovery Log /arch/1_34_992735965.arc
Tue Dec 11 14:36:01 2018
Media Recovery Log /arch/1_35_992735965.arc
Media Recovery Log /arch/1_36_992735965.arc
Media Recovery Waiting for thread 1 sequence 37 (in transit)
Recovery of Online Redo Log: Thread 1 Group 4 Seq 37 Reading mem 0
  Mem# 0: /oradata/lmisdbdg/standby04.log

檢查主備庫歸檔應用情況

--lmis例項歸檔日誌資訊
SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME, APPLIED FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;

 SEQUENCE# FIRST_TIME	       NEXT_TIME	   APPLIED
---------- ------------------- ------------------- ---------
	18 2018-11-26 13:38:24 2018-11-30 12:12:48 YES
	19 2018-11-30 12:12:48 2018-12-03 15:55:06 YES
	20 2018-12-03 15:55:06 2018-12-07 00:14:24 YES
	20 2018-12-03 15:55:06 2018-12-07 00:14:24 NO
	21 2018-12-07 00:14:24 2018-12-08 22:13:14 NO
	21 2018-12-07 00:14:24 2018-12-08 22:13:14 NO
	22 2018-12-08 22:13:14 2018-12-08 22:13:17 NO
	22 2018-12-08 22:13:14 2018-12-08 22:13:17 NO
	23 2018-12-08 22:13:17 2018-12-08 22:13:22 NO
	23 2018-12-08 22:13:17 2018-12-08 22:13:22 NO
	24 2018-12-08 22:13:22 2018-12-08 22:14:40 NO

 SEQUENCE# FIRST_TIME	       NEXT_TIME	   APPLIED
---------- ------------------- ------------------- ---------
	24 2018-12-08 22:13:22 2018-12-08 22:14:40 NO
	25 2018-12-08 22:14:40 2018-12-09 00:16:43 NO
	25 2018-12-08 22:14:40 2018-12-09 00:16:43 NO
	26 2018-12-09 00:16:43 2018-12-09 05:11:13 NO
	26 2018-12-09 00:16:43 2018-12-09 05:11:13 NO
	27 2018-12-09 05:11:13 2018-12-09 09:42:43 NO
	27 2018-12-09 05:11:13 2018-12-09 09:42:43 NO
	28 2018-12-09 09:42:43 2018-12-09 14:17:43 NO
	28 2018-12-09 09:42:43 2018-12-09 14:17:43 NO
	29 2018-12-09 14:17:43 2018-12-09 19:09:43 NO
	29 2018-12-09 14:17:43 2018-12-09 19:09:43 NO

 SEQUENCE# FIRST_TIME	       NEXT_TIME	   APPLIED
---------- ------------------- ------------------- ---------
	30 2018-12-09 19:09:43 2018-12-10 00:00:10 NO
	30 2018-12-09 19:09:43 2018-12-10 00:00:10 NO
	31 2018-12-10 00:00:10 2018-12-10 04:39:43 NO
	31 2018-12-10 00:00:10 2018-12-10 04:39:43 NO
	32 2018-12-10 04:39:43 2018-12-10 09:35:13 NO
	32 2018-12-10 04:39:43 2018-12-10 09:35:13 NO
	33 2018-12-10 09:35:13 2018-12-10 14:54:04 NO
	33 2018-12-10 09:35:13 2018-12-10 14:54:04 NO
	34 2018-12-10 14:54:04 2018-12-10 16:53:31 NO
	34 2018-12-10 14:54:04 2018-12-10 16:53:31 NO
	35 2018-12-10 16:53:31 2018-12-10 16:59:19 NO

 SEQUENCE# FIRST_TIME	       NEXT_TIME	   APPLIED
---------- ------------------- ------------------- ---------
	35 2018-12-10 16:53:31 2018-12-10 16:59:19 NO
	36 2018-12-10 16:59:19 2018-12-11 07:15:46 NO
	36 2018-12-10 16:59:19 2018-12-11 07:15:46 NO

36 rows selected.


--lmisdbdg例項歸檔日誌資訊
SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME, APPLIED FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;

 SEQUENCE# FIRST_TIME	       NEXT_TIME	   APPLIED
---------- ------------------- ------------------- ---------
	 9 2018-11-22 18:26:23 2018-11-22 18:41:30 YES
	10 2018-11-22 18:41:30 2018-11-22 18:45:14 YES
	11 2018-11-22 18:45:14 2018-11-22 19:05:07 YES
	12 2018-11-22 19:05:07 2018-11-22 19:07:06 YES
	13 2018-11-22 19:07:06 2018-11-22 19:12:05 YES
	14 2018-11-22 19:12:05 2018-11-22 16:11:44 YES
	15 2018-11-22 16:11:44 2018-11-22 16:11:48 YES
	16 2018-11-22 16:11:48 2018-11-22 16:12:12 YES
	17 2018-11-22 16:12:12 2018-11-26 13:38:24 YES
	18 2018-11-26 13:38:24 2018-11-30 12:12:48 YES
	19 2018-11-30 12:12:48 2018-12-03 15:55:06 YES

 SEQUENCE# FIRST_TIME	       NEXT_TIME	   APPLIED
---------- ------------------- ------------------- ---------
	20 2018-12-03 15:55:06 2018-12-07 00:14:24 YES
	21 2018-12-07 00:14:24 2018-12-08 22:13:14 NO
	22 2018-12-08 22:13:14 2018-12-08 22:13:17 NO
	23 2018-12-08 22:13:17 2018-12-08 22:13:22 NO
	24 2018-12-08 22:13:22 2018-12-08 22:14:40 NO
	25 2018-12-08 22:14:40 2018-12-09 00:16:43 NO
	26 2018-12-09 00:16:43 2018-12-09 05:11:13 NO
	27 2018-12-09 05:11:13 2018-12-09 09:42:43 NO
	28 2018-12-09 09:42:43 2018-12-09 14:17:43 NO
	29 2018-12-09 14:17:43 2018-12-09 19:09:43 NO
	30 2018-12-09 19:09:43 2018-12-10 00:00:10 NO

 SEQUENCE# FIRST_TIME	       NEXT_TIME	   APPLIED
---------- ------------------- ------------------- ---------
	31 2018-12-10 00:00:10 2018-12-10 04:39:43 NO
	32 2018-12-10 04:39:43 2018-12-10 09:35:13 NO
	33 2018-12-10 09:35:13 2018-12-10 14:54:04 NO
	34 2018-12-10 14:54:04 2018-12-10 16:53:31 NO
	35 2018-12-10 16:53:31 2018-12-10 16:59:19 NO
	36 2018-12-10 16:59:19 2018-12-11 07:15:46 NO

28 rows selected.

注意：-

設定STANDBY_FILE_MANAGEMENT為AUTO使Oracle在備用資料庫上自動建立檔案，並在某些情況下覆蓋現有檔案。設定時必須小心STANDBY_FILE_MANAGEMENT，DB_FILE_NAME_CONVERT以免意外覆蓋現有備用檔案。

相關推薦

解決ORA-01111, ORA-01110, ORA-01157

在備用資料庫中建立檔案為UNNAMED或MISSING的原因有很多，包括備用站點上的磁碟空間不足（或）與檔案管理相關的不正確的引數設定。 STANDBY_FILE_MANAGEMENT啟用或禁用自動備用檔案管理。啟用自動備用檔案管理後，將在備用資料庫上覆制主資料庫上的作業系統檔案新增和刪除。

ORACLE重建控制檔案，ORA-01122;ORA-01110;ORA-01207問題解決經驗總結

1.SQL>sqlplus / as sysdba 2.SQL>startup ORACLE 例程已經啟動。 Total System Global Area 293601280 bytes Fixed Size 1248624 bytes Variable

解決oracle報錯：ora-00257 archiver error. connect interval only,unit freed

通過navicat連線oralce資料庫時，發現彈出報錯：ora-00257 archiver error. connect interval only,unit freed。 經查詢，大致定位為日誌滿了，需要清理日誌。 1、以oracle身份登入資料庫 su - oracle

12C ORA-錯誤彙總6 ORA-07500 to ORA-09859

分享一下我老師大神的人工智慧教程！零基礎，通俗易懂！http://blog.csdn.net/jiangjunshow 也歡迎大家轉載本篇文章。分享知識，造福人民，實現我們中華民族偉大復興！        

【ORA】一些oracle-ora等錯誤記錄

1、ORA-12560: TNS: 協議介面卡錯誤 場景：在cmd視窗輸入：sqlplus "/as sysdba"想開啟資料庫時報的錯； 原因：沒有啟動Oracle伺服器； 解決：WIN+R，跳出執行

12C ORA-錯誤彙總2 ORA-00910 to ORA-01497

                ORA-00910 to ORA-01497 3ORA-00910: specified length too long for its datatypeCause: for datatypes CHAR and RAW, the length specified was &g

12C ORA-錯誤彙總12 ORA-24280 to ORA-28709

ORA-24280: invalid input value for parameter string Cause: The parameter has been provided a negative, out of range, or NULL input val

12C ORA-錯誤彙總8 ORA-12150 to ORA-12236

ORA-12150 to ORA-12236 9 ORA-12150: TNS:unable to send data Cause: Unable to send data. Connection probably disconnected. Action: Reestab

ORA-01157 和 ORA-01110錯誤

ORA-01157 cannot identify datafile name - file not found Cause The background process was not able to find one of the datafiles. The dat

Oracle ORA-01157: 無法標識/鎖定資料檔案 解決方法

本文轉自http://www.linuxidc.com/Linux/2012-05/60761.htm 在使用sqlplus進行啟動oralce時，會丟擲oracle Ora-01157：無法標誌/鎖定資料檔案；出現此問題的的原因是，資料庫中表空間的資料檔案被刪除，找不到對

ORA-10458、ORA-01196和ORA-01110錯誤解決辦法

ges 啟動報錯 返回結果 mounted shadow https src recover require oracle DG 備庫啟動報錯如下SQL> startupORACLE instance started. Total System Global Area

執行DBMS_METADATA.get_ddl報ORA-39212的解決方法

ddl api div lec connect ext rom 查看 local 環境： 數據庫：oracle 10.2.0.4 --64位 操作系統：紅旗dc 5.0 --64位以sys登陸，執行DBMS_METADATA.get_ddl得到某個表空間的元數

ORACLE 11G DB RAC ORA-00257archiver error解決辦法

orcale11g rac   ora00257   處理asm磁盤空間不足問題ORA-00257archiver error解決辦法1.之前有處理單機過oracle 11.2.0.4歸檔日誌磁盤空間不足的問題 ，但是沒有處理過ORACLE RAC的歸檔日誌磁盤空間不足的問題 所以沒

ORA-01950: 表空間'USERS'中無權限的2種解決辦法

text tro 表空間 ant 解決 style str spa -s 總的來說這個錯誤是由於對表空間操作的權限不足造成的，所以這個時候就可以檢查出錯之前對於所操作的表賦權grant connect,resource to zhangbojie ; ORA-01950:

診斷並解決 ORA-4030 錯誤 (Doc ID 1548826.1)

area 2gb version trace note master cached detach ogr 適用於: Oracle Database - Enterprise Edition - 版本號 8.1.7.4 和更高版本號 本文檔所含信息適用於全部平臺

ORA-01653 無法在表空間擴展的解決辦法 -- 增加表空間大小或給表空間增加數據文件

xid com 滿了 height log rod details 空閑 weight 轉自原文 ORA-01653 無法在表空間擴展的解決辦法 -- 增加表空間大小或給表空間增加數據文件 當前系統的數據量越來越大的，昨天還運行正常的數據庫，突然無法使用了。經過定位發現

oracel 數據庫問題 ORA-12547 ORA-12571 解決記錄

錯誤解決 11.2 log 解決辦法 數據 nis ati tor 服務 Oracel 業務數據庫近期頻繁出現：ORA-12547：TNS：lost contact 和 ORA-12571：TNS：packet writer failure 錯誤 排除了端口及監聽程序的問

ORA-12638: 身份證明檢索失敗 解決方法

nav ref fig tle mage 連接 man 技術分享 rac 用PL/SQL或Navicat連接本地或遠程Oracle數據庫的時候報錯：ORA-12638: 身份證明檢索失敗 解決方法： 開始 -> 所有程序 -> Oracle - Oracle_

oracle 11g錯誤ora-01033:oracle initialization or shutdown in progress解決辦法

想要 文件 area .net total rop shutdown 一個 pro 原文出自：http://blog.csdn.net/liverliu/article/details/6410287 一、首先：問題的產生原因，先前我在f:/llh/目錄創建的一個book

ORA-12519: TNS:no appropriate service handler found 解決

ace 數據庫 pfile service set 重啟 area .sql med 最近做項目遇到一個連接Oracle的問題，報錯如題：ORA-12519: TNS:no appropriate service handler found，應該是項目中的有些算法把所有連接