因not open force loggning 引起的DG ORA-1578 報錯

前天，部署實施公司xx生產中心錄入庫一套DG，但是在之前，這其中的一台primary 是我N就之前的一台測試機。記得當時我是通過寂寞方式安裝的版本 11.2g 03小版本。本來這這也沒什麼，可以前段時間，因為項目，部門經理突然把正式資料匯入，就這樣，變成了公司的正式庫運行生產。 為此，我狂汗，咋也不提前說一下。就這樣，我的測試機變成了生產，由於N就前的機子，我也忘記了，這台主機當時做了什麼操作。

周一上班，因其他事需處理，我也沒遠程看看這台xx生產中心庫的效能，及設定什麼的。 上午高峰期，也就這樣過了。

 下午，突然，RTX 閃爍這急忙忙的頭像，Y的，點開一下，測試部，質檢部，ETL部，xx資料生產部 都在呐喊，怎麼串連不進去了？ 我也趕緊遠程看看這xx伺服器，Y的，ORA-04031 報錯？

Errors in file /u01/app/Oracle/diag/rdbms/xxxdb_p/gtadb/trace/gtadb_ora_29163.trc (incident=4220):
ORA-04031: unable to allocate 56 bytes of shared memory ("streams pool","unknown object","streams pool","fixed allocation callback")
Incident details in: /u01/app/oracle/diag/rdbms/xxxdb_p/gtadb/incident/incdir_4220/gtadb_ora_29163_i4220.trc
Thu Dec 26 18:29:08 2013
Dumping diagnostic data in directory=[cdmp_20131226182908], requested by (instance=1, osid=29163), summary=[incident=4220].
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Error ORA-4031 occured during Initialization of Bufq KUPC$C_1_20131225143407
Starting background process QMNC
Thu Dec 26 18:29:09 2013
QMNC started with pid=37, OS id=29200

看看這庫到底分配了多少記憶體：

NAMETYPEVALUE
------------------------------------ ----------- ------------------------------
lock_sgabooleanFALSE
pre_page_sgabooleanFALSE
sga_max_sizebig integer 512M
sga_targetbig integer 512M

NAMETYPEVALUE
------------------------------------ ----------- ------------------------------
pga_aggregate_targetbig integer 5904M

在看看 dev/shm 共用記憶體:

tmpfs 9.8G 0 9.8G 0% /dev/shm

再通過系統看了看 實體記憶體及swap:

total used free shared buffers cached
Mem: 12299044 12233492 65552 0 15948 11230976
-/+ buffers/cache: 986568 11312476
Swap: 25165812 76372 25089440

top - 13:28:07 up 1 day, 3:40, 5 users, load average: 14.78, 16.62, 17.17
Tasks: 314 total, 8 running, 306 sleeping, 0 stopped, 0 zombie
Cpu(s): 64.5%us, 1.7%sy, 0.0%ni, 8.3%id, 25.4%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 12299044k total, 12230484k used, 68560k free, 16032k buffers
Swap: 25165812k total, 76372k used, 25089440k free, 11230472k cached

此時CPU ：Cpu(s): 97.8%us, 2.1%sy, 0.0%ni, 0.0%id, 0.1%wa, 0.0%hi, 0.0%si, 0.0%st 我也過去:

 看見這情況，知道了大概，通過系統登入，Y的，也登陸不了，原來公司的一種資料同步軟體在即時資料同步，原來cpu 這大，這同步軟體雖說也是通過對oracle 日誌分析提出的資料，其通過自己的一個專有column值變動達到資料同步，同時也做大量得 select count(*) tab 操作。

臨時通過 alter system flush shared_pool ; 還是不行！ 依舊登陸不了！ 最後殺掉不必要的服務進程還是不行，最後 我恨，只能stop 監聽了。 管理登陸，還是不行，通過執行alter system flush shared_pool ； 確保這ora-04031 錯。最後最後，我直接幹掉oracle 進程，庫關了！(心情涼透了，萬一起不來咋辦？ 幸好，周末晚上，這庫我備了控制檔案，開了歸檔）。

 調整記憶體大小，重啟了一下，串連OK 。 雖說有點小怨言部門經理。其他不說了! 串連正常，可以開工了，RTX 通知可用，看看時間，只發了5分鐘，沒造成大的影響。

考慮的這primay cpu 很大，部門經理要求部署一台standby，讀寫分離，分擔負載。

開始搭建了，按照那些記憶，一點點的配置起來，查看庫基本資料： 歸檔、密碼檔案、參數檔案、監聽測試、資料檔案，記錄檔、備份、 拷貝、 duplicate、查看備庫進程、模式 、修改日誌。ok都弄好了！查看trace檔案，一切正常。

突然瞄了一下trace 日誌： Y的，怎麼又壞塊，剛跑的dg， 日誌如下：

Thu Dec 26 20:20:22 2013
Errors in file /u01/app/oracle/diag/rdbms/gtadb_s/gtadb2/trace/gtadb2_ora_16302.trc (incident=24222):
ORA-01578: ORACLE ?版.?..?.(?.歡??18, ?.. 399904)
ORA-01110: ?版.?.歡 18: '/u01/app/oracle/datafile/gta_input_data_07.dbf'
ORA-26040: ?版.?..浣跨. NOLOGGING ?.」?.澆?
Thu Dec 26 20:20:25 2013
Errors in file /u01/app/oracle/diag/rdbms/gtadb_s/gtadb2/trace/gtadb2_ora_16306.trc (incident=24223):
ORA-01578: ORACLE ?版.?..?.(?.歡??17, ?.. 410498)
ORA-01110: ?版.?.歡 17: '/u01/app/oracle/datafile/gta_input_data_06.dbf'
ORA-26040: ?版.?..浣跨. NOLOGGING ?.」?.澆?
Thu Dec 26 20:21:05 2013
Sweep [inc][28066]: completed
Sweep [inc][28065]: completed
Sweep [inc][24223]: completed
Sweep [inc][24222]: completed

看了一下，再看看錶18:15，這壞塊估計是那個開發的，在建立表，索引是估計加了nologging引起，先不管，回家再說，這段時間比較累,先補補覺！

第二天上班，再看看trace 檔案：

Thu Dec 26 23:00:02 2013
Errors in file /u01/app/oracle/diag/rdbms/gtadb_s/gtadb2/trace/gtadb2_ora_20463.trc (incident=24577):
ORA-01578: ORACLE ?版.?..?.(?.歡??17, ?.. 410512)
ORA-01110: ?版.?.歡 17: '/u01/app/oracle/datafile/gta_input_data_06.dbf'
ORA-26040: ?版.?..浣跨. NOLOGGING ?.」?.澆?
Thu Dec 26 23:00:05 2013
Sweep [inc][24577]: completed
Thu Dec 26 23:00:17 2013
DDE: Problem Key 'ORA 1578' was completely flood controlled (0x6)
Further messages for this problem key will be suppressed for up to 10 minutes
Thu Dec 26 23:00:24 2013
DDE: Problem Key 'ORA 1578' was completely flood controlled (0x6)
Further messages for this problem key will be suppressed for up to 10 minutes
Thu Dec 26 23:16:02 2013

又報後面的錯，　百度了一下DDE: Problem Key 'ORA 1578' was completely flood controlled (0x6)　，和猜測一樣，說是trace 檔案比較頻繁，所以。。。。。

開始動手了：

通過 v$archived_gap,v$recovery_log,v$recover_file 都顯示no row

通過DBV FILE 體檢一下,

SQL> l
1 SELECT SEGMENT_TYPE,OWNER||'.'||SEGMENT_NAME
2 FROM DBA_EXTENTS
3 WHERE FILE_ID = 17 AND 410512 BETWEEN BLOCK_ID
4* AND BLOCK_ID+BLOCKS -1

SEGMENT_TYPE||'.'||SEGMENT_NAME
--------------------------------------------------------------------------------
INDEX.IUM46669939

看來看，原來是一條索引，好辦， 同時心想，難道我忘記了forcelogging？ 建立dg 的時候？？

於是，毫不猶豫的 v$database 看了一下，還真是！ 於是毫不猶豫在primary 上執行 alter database force logging!

通知通過user_indexes 查看這索引到底屬於那張表：

SQL> select index_name,index_type,TABLE_OWNER,table_name,logging,TABLESPACE_NAME from user_indexes where index_name='IUM46669939';

INDEX_NAMEINDEX_TYPE TABLE_OWNERTABLE_NAMELOG TABLESPACE_NAME
------------------------------ --------------------------- ------------------------------ ------------------------------ --- ------------------------------
IUM46669939NORMAL INPUTTBL_ZZ_I_PERF YES GTA_INPUT_DATA

最後，通過溝通，查看，這張表上午基本沒有操作，於是毫不猶豫 rebuild indexes , 強制切換日誌，查看備庫，ok ! 問題解決。

當然，如果是控制檔案，或者其他就更具不同 而解決了！ 不管bbed ，aul 或者dul , 我覺得，備份對於DBA 來說，重於一切！

DBA 必須將兩份檔案保持為最新狀態： 一份是好的簡曆，一份是最近的備份！ --我覺得比較贊！