ORA-15041,ORA-01274 故障解决实例
和客户沟通了下,他们打算把DG停掉,暂时不用了,因此也没有做进一步处理,如果不想让归档日志传递到备库,可以设置主库参数log_
上周五去客户处巡检时,发现原来配置的DG备库未与主库同步,特此记录一下
在5月14日13:58出现故障,3398日志无法应用,以下是alert日志
Thu May 14 13:58:01 2015
Errors in file /u01/app/Oracle/diag/rdbms/tcdg/tc/trace/tc_pr00_3473760.trc:
ORA-01119: error in creating database file '+data'
ORA-17502: ksfdcre:4 Failed to create file +data
ORA-15041: diskgroup "DATA" space exhausted
File #108 added to control file as 'UNNAMED00108'.
Originally created as:
'+DATA/tc/datafile/oa2015.387.879688649'
Recovery was unable to create the file as:
'+data'
MRP0: Background Media Recovery terminated with error 1274
Errors in file /u01/app/oracle/diag/rdbms/tcdg/tc/trace/tc_pr00_3473760.trc:
ORA-01274: cannot add datafile '+DATA/tc/datafile/oa2015.387.879688649' - file could not be created
Managed Standby Recovery not using Real Time Apply
Recovery interrupted!
Recovered data files to a consistent state at change 10293976250522
Thu May 14 13:58:06 2015
MRP0: Background Media Recovery process shutdown (tc)
由于空间不足,出现了ORA-15041错误,然后MRP0进程被终止
再来看trace文件内容:
*** 2015-05-14 13:58:01.562
----- START Event Driven Actions Dump ----
---- END Event Driven Actions Dump ----
----- START DDE Actions Dump -----
Executing SYNC actions
Executing ASYNC actions
----- END DDE Actions Dump (total 0 csec) -----
ORA-01119: error in creating database file '+data'
ORA-17502: ksfdcre:4 Failed to create file +data
ORA-15041: diskgroup "DATA" space exhausted
File #108 added to control file as 'UNNAMED00108'.
Originally created as:
'+DATA/tc/datafile/oa2015.387.879688649'
Recovery was unable to create the file as:
'+data'
*** 2015-05-14 13:58:01.598 4329 krsh.c
MRP0: Background Media Recovery terminated with error 1274
ORA-01274: cannot add datafile '+DATA/tc/datafile/oa2015.387.879688649' - file could not be created
*** 2015-05-14 13:58:01.613 4329 krsh.c
Managed Standby Recovery not using Real Time Apply
*** 2015-05-14 13:58:01.616
MRP: Prodding archiver at standby for thread 1 seq 3398
----- Redo read statistics for thread 1 -----
Read rate (ASYNC): 1631875714Kb in 8455733.63s => 0.19 Mb/sec
Total redo bytes: 1631903362Kb Longest record: 53Kb, moves: 546631/3909060988 moved: 2869Mb (0%)
Longest LWN: 61559Kb, reads: 53311640
Last redo scn: 0x095c.c0cc389a (10293976250522)
Change vector header moves = 505014709/3028421495 (1%)
----------------------------------------------
*** 2015-05-14 13:58:01.626
Media Recovery drop redo thread 1
KCBR: Redo cache copies/changes = 7576594/7576586
Wait to push change maps to slaves = 136500s
*** 2015-05-14 13:58:02.545
Completed Media Recovery
Checking to start in-flux buffer recovery from SCN 2396.3234383719 to SCN (non-inclusive) 2396.3234609306
Influx recovery found in-flux buffers
*** 2015-05-14 13:58:02.622
Influx Media Recovery add redo thread 1
Managed Standby Recovery: Standby online log for thr 1 seq 3397 not found. Looking whether archived..
Looking for archived log thr 1 seq 3397 recovery branch id 869789191 that contains SCN 10293976024935
Checking whether scn 10293976024935 in los 10293976024935 and nxs 10293976125751
Managed Standby Recovery: Opening archived log /oraarch/ARC_CRM5_3397_869789191_1.log during invocation of recoverable recovery
*** 2015-05-14 13:58:03.937
Resized overflow buffer to 2435K (for 2435K LWN)
Resized overflow buffer to 3923K (for 3923K LWN)
Resized overflow buffer to 14242K (for 14242K LWN)
*** 2015-05-14 13:58:06.105
MRP: Prodding archiver at standby for thread 1 seq 3398
Managed Recovery: Not Active posted.
由于redo apply的进程被终止,因此应用到3397归档后,之后的日志都未被应用,但是归档日志都已经顺利传到了备库
SQL> select thread#,sequence#,applied from v$archived_log where sequence#>3391;
THREAD# SEQUENCE# APPLIED
---------- ---------- ---------
1 3392 YES
1 3393 YES
1 3394 YES
1 3395 YES
1 3396 YES
1 3397 YES
1 3398 NO
1 3399 NO
1 3400 NO
1 3401 NO
1 3402 NO
1 3403 NO
1 3404 NO
1 3405 NO
1 3406 NO
1 3407 NO
1 3408 NO
1 3409 NO
1 3410 NO
1 3411 NO
1 3412 NO
1 3413 NO
还可以通过下面的SQL语句去分析备库落后了多少归档日志未完成应用。

熱AI工具

Undresser.AI Undress
人工智慧驅動的應用程序,用於創建逼真的裸體照片

AI Clothes Remover
用於從照片中去除衣服的線上人工智慧工具。

Undress AI Tool
免費脫衣圖片

Clothoff.io
AI脫衣器

Video Face Swap
使用我們完全免費的人工智慧換臉工具,輕鬆在任何影片中換臉!

熱門文章

熱工具

記事本++7.3.1
好用且免費的程式碼編輯器

SublimeText3漢化版
中文版,非常好用

禪工作室 13.0.1
強大的PHP整合開發環境

Dreamweaver CS6
視覺化網頁開發工具

SublimeText3 Mac版
神級程式碼編輯軟體(SublimeText3)

MySQL在Web應用中的主要作用是存儲和管理數據。 1.MySQL高效處理用戶信息、產品目錄和交易記錄等數據。 2.通過SQL查詢,開發者能從數據庫提取信息生成動態內容。 3.MySQL基於客戶端-服務器模型工作,確保查詢速度可接受。

InnoDB使用redologs和undologs確保數據一致性和可靠性。 1.redologs記錄數據頁修改,確保崩潰恢復和事務持久性。 2.undologs記錄數據原始值,支持事務回滾和MVCC。

MySQL与其他编程语言相比,主要用于存储和管理数据,而其他语言如Python、Java、C 则用于逻辑处理和应用开发。MySQL以其高性能、可扩展性和跨平台支持著称,适合数据管理需求,而其他语言在各自领域如数据分析、企业应用和系统编程中各有优势。

MySQL索引基数对查询性能有显著影响:1.高基数索引能更有效地缩小数据范围,提高查询效率;2.低基数索引可能导致全表扫描,降低查询性能;3.在联合索引中,应将高基数列放在前面以优化查询。

MySQL的基本操作包括創建數據庫、表格,及使用SQL進行數據的CRUD操作。 1.創建數據庫:CREATEDATABASEmy_first_db;2.創建表格:CREATETABLEbooks(idINTAUTO_INCREMENTPRIMARYKEY,titleVARCHAR(100)NOTNULL,authorVARCHAR(100)NOTNULL,published_yearINT);3.插入數據:INSERTINTObooks(title,author,published_year)VA

MySQL適合Web應用和內容管理系統,因其開源、高性能和易用性而受歡迎。 1)與PostgreSQL相比,MySQL在簡單查詢和高並發讀操作上表現更好。 2)相較Oracle,MySQL因開源和低成本更受中小企業青睞。 3)對比MicrosoftSQLServer,MySQL更適合跨平台應用。 4)與MongoDB不同,MySQL更適用於結構化數據和事務處理。

MySQL通過表結構和SQL查詢高效管理結構化數據,並通過外鍵實現表間關係。 1.創建表時定義數據格式和類型。 2.使用外鍵建立表間關係。 3.通過索引和查詢優化提高性能。 4.定期備份和監控數據庫確保數據安全和性能優化。

InnoDBBufferPool通過緩存數據和索引頁來減少磁盤I/O,提升數據庫性能。其工作原理包括:1.數據讀取:從BufferPool中讀取數據;2.數據寫入:修改數據後寫入BufferPool並定期刷新到磁盤;3.緩存管理:使用LRU算法管理緩存頁;4.預讀機制:提前加載相鄰數據頁。通過調整BufferPool大小和使用多個實例,可以優化數據庫性能。
