f 五月 2019 ~ 迪貝之家

Microsoft SQL Server Log Shipping

SQL 7就有的技術,簡單的說就是資料庫複本資料同步的技術,而這份複本可以開放讀取的功能以分散營業資料庫的負載,也可純粹當成備援資料庫,不管是在本地還是異地。怎麼達成? 透過SQL Agent自動化排程進行備份、傳檔及復原等作業。

Oracle GolGateden

機房搬遷跨Site能即時同步資料庫利器

Nagios 資料庫維運自動化

一開始設計這架構時,就排除使用remote agent的想法因為在專業分工的組織下,要求安裝新軟體於既有系統是一件不太可行的方案,既然身為DBA就只能把資料庫instance當作是一個最大的agent 想辦法在資料庫內做到我想做的事情

This is default featured post 4 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

This is default featured post 5 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

資料細度(data granularity)

這個案例是在行銷部門做活動時,Postgres 資料庫所發生的錯誤,它比較麻煩的是,之前就發生過兩次 sorry, too many clients already,但沒有發生任何障礙,所以日檢發現後通知AP單位,他們沒理我。但這次被鬧大了,因為HA切換中斷了服務太久。 系統上的user process limit 設為1024,資料庫連線的max_connections 設為1000,再加上其他的Process的運作,就觸發了RHCS進行HA切換,又好死不死地,切換因為某些因素不成功而卡著,所以被深深地關心了一下下
could not fork new process for connection: Resource temporarily unavailable




發生問題時,我是被質疑,是不是有額外的管理session耗光了資源,我當下是腹誹了一陣。主機單位提出他們的效能數據,顯示CPU及記憶體資源都很充足,我當時就覺得,你是在跟我說笑話嗎?? 資料庫的系統記錄是甚麼 ?? 被要求開會面對面檢討,我當時忙得要死,再加上手上沒資料,我就直接說"沒空",你們想要怎麼做,我就是配合。

因為是固定週期性活動,再次活動時間前十分鐘左右進了系統下了指令vmstat 5 1000,output 如下
vmstat

硬體就只有40 Core,第一個欄位run queue的值就已經有超過40的狀況了,再去對照其他我標出紅色的數值,這是系統資源很充足的狀態嗎?系統在活動期間,有1~2分鐘的時間是處於 CPU資源被耗盡的狀態,主機單位他們的工具抓取資料的間隔應該至少都是5分鐘。我看完資料後,就mail 給主機單位的主管及負責人我的結論

再隔一個禮拜,他就來跟我說兩個點
1. 他們有trace DBA端使用的process,用量很少
2. AP在很短的時間內爆量把資源用光會調降AP 連線數
接著提到,主機端會調整ulimit值,資料庫端不需做任何處理
這個案例,我想要講的是,DBA不講話不表示沒意見,只是沒有充分的證據來表達意見,DBA是一個專業度很高的職務,所以懂的東西不會比主機單位少

Oracle DATAPUMP impdp network_link 所碰到的問題

由18c 透過impdp 經由network_link及啟用parallel移轉12.1資料時,就發覺怎麼好像在index的部份很慢,叫起top畫面,怎麼會只有一個server process在運作,到metalink查詢文件,發現底下這篇文件
DataPump Import Does Not Use Multiple Parallel PX Processes For Index Creation (Doc ID1081069.1)

文件內的說法

Bug 8604502
但我的環境是18c,再加上打了2019年第一季的RU,怎麼還會發生這個問題。所以我就開了一個call給global support,結果居然問我碰到了甚麼問題?我真的是發覺,中國大陸的support實在是有點........。心裡就想,連這個錯也會犯,Oracle真的是新版出的太快了。算了,還是自己改變匯入的方式,把data與index匯入分開

首先當然再12.1的環境把index 定義萃取出來

expdp system/xxx content=metadata_only dumpfile=index.dmp log=expdp.log directory=data_pump_dir include=INDEX,constraint SCHEMAS=test1,test2,test3
接著把定義匯出檔轉為sql 語法


我們來看其中一段萃取出來的索引建立語法

impdp system/xxx dlogfile=index.logirectory=data_pump_dir dumpfile=index.dmp sqlfile=index.sql 

CREATE INDEX "TEST"."BACKWARD_ITEM_IDX2" ON "TEST"."BACKWARD_ITEM" ("TEMPLATE_DATE", "ITEM", "PERIOD")
PCTFREE 10 INITRANS 2 MAXTRANS 255
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1
BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)
TABLESPACE "TEST_INDEX"
PARALLEL 1 ;
ALTER INDEX "TEST"."BACKWARD_ITEM_IDX2" PARALLEL 4;

也許你會認為會不會是只有這個index原本定義的問題,所以我用下列語法去掃create時使用的parallel 參數

grep -i parallel index.sql|grep -i TABLESPACE|more
確定轉出來的都是PARALLEL 1,datapump 是在索引建立出來之後,再透過alter index把原來的PARALEL 參數設上
也許你還會質疑,會不會是expdp或者impdp沒有帶parallel參數,兩者我都帶過parallel=8測過,狀況一樣。所以如果要加快資料移轉的速度,索引與資料的匯入要切開。再來就是直接打開index.sql修改PARALLEL 後的數值,你當然要去比對表格大小來設定該數值。我能說甚麼?Oracle 想要凸顯DBA的價值.....
我們來看我怎麼進行資料匯入的語法
impdp system/xxx network_link=temp_nwds log=nwds_impdp_0508.log directory=nwds_impdp full=y parallel=16 EXCLUDE=SCHEMA:\"IN \(\'MONITOR\'\,\'SQLTXPLAIN\'\,\'SQLTXADMIN\'\,\'WMSYS\'\,\'I3AGENT\'\,\'SYSTEM\'\,\'SYS\'\,\'OLAPSYS\'\,\'SI_INFORMTN_SCHEMA\'\,\'AUDSYS\'\,\'GSMUSER\'\,\'ORDPLUGINS\'\,\'SPATIAL_WFS_ADMIN_USR\'\,\'SPATIAL_CSW_ADMIN_USR\'\,\'XDB\'\,\'SYSDG\'\,\'DIP\'\,\'OUTLN\'\,\'ANONYMOUS\'\,\'CTXSYS\'\,\'ORDDATA\'\,\'SYSBACKUP\'\,\'MDDATA\'\,\'GSMCATUSER\'\,\'GSMADMIN_INTERNAL\'\,\'SYSKM\'\,\'XS\$NULL\'\,\'OJVMSYS\'\,\'APPQOSSYS\'\,\'ORACLE_OCM\'\,\'WMSYS\'\,\'DBSNMP\'\,\'ORDSYS\'\,\'MDSYS\'\)\" exclude=INDEX,constraint REMAP_TABLESPACE=TEST1:DATA REMAP_TABLESPACE=TEST2:DATA 
最後當然就是執行修改過後的index.sql

RMAN Restore Upgrade from 10.2.0.5 to 12.1.0.2

基本上就分成兩個部份,一是在source 端執行preupgrade 工具程式,處理報表內出現的ERROR,其他可以不用理會,等完成restore之後,在target端再來處理,因為沒有人想在源頭系統上進行變更,風險太大。另一則是restore作業及升級的步驟。

preupgrade 工具的來源有二,一是安裝12.1.0.2 Oracle Binary 之後,到$ORACLE_HOME/rdbms/admin,把preupgrd.sql及utluppkg.sql拷貝到10.2.0.5的環境執行,一則是你到metalink網站下載,去找文件884522.1,各版本都有。你也許會懷疑,在既有的環境跑preupgrade工具程式會不會有問題,因為這也當初猶豫了好久的點,我可以告訴你,就放一百個心去run 該工具。

在source 端該做的動作,我覺得沒有必要談太多,我僅提供我所碰到的該修正的兩個ERROR,第一個是報表提到系統用的表格空間不夠,就是擴空間囉;第二就是要求關掉或者purge recyclebin,照做就是了,因為我的環境需要進行OGG 抄寫,在OGG建置過程中就會要求關掉recyclebin,所以我後來的測試就乾脆直接關掉。最後就是進行controlfile 的備份,指令如下,記得switch logfile。

BACKUP AS COPY CURRENT CONTROLFILE FORMAT '/tmp/control01.dbf';

把檔案傳到restore主機,db instance開在mount mode


接著當然就是進行restore,我的rman script如下
run {
set archivelog destination to '/ora_data/arch';
sql "alter session set nls_date_format=''YYYY-MM-DD HH24:MI:SS'' ";
set until scn 9390628700021;
allocate channel ch00 type 'sbt_tape';
SET NEWNAME FOR DATABASE TO '/ora_data/%b';
SET NEWNAME FOR tempfile 1 TO '/ora_data/%b';
SET NEWNAME FOR tempfile 2 TO '/ora_data/%b';
SET NEWNAME FOR tempfile 3 TO '/ora_data/%b';
SET NEWNAME FOR tempfile 4 TO '/ora_data/%b';
SET NEWNAME FOR tempfile 5 TO '/ora_data/%b';
SET NEWNAME FOR tempfile 6 TO '/ora_data/%b';
restore database;
switch datafile all;
switch tempfile all;
recover database ;
SQL "ALTER DATABASE RENAME FILE ''/oradata/redo/redo01.log'' TO ''/ora_data/redo01.log'' ";
SQL "ALTER DATABASE RENAME FILE ''/oradata/redo/redo02.log'' TO ''/ora_data/redo02.log'' ";
SQL "ALTER DATABASE RENAME FILE ''/oradata/redo/redo03.log'' TO ''/ora_data/redo03.log'' ";
SQL "ALTER DATABASE RENAME FILE ''/oradata/redo/sbredo01.log'' TO ''/ora_data/sbredo01.log'' ";
SQL "ALTER DATABASE RENAME FILE ''/oradata/redo/sbredo02.log'' TO ''/ora_data/sbredo02.log'' ";
SQL "ALTER DATABASE RENAME FILE ''/oradata/redo/sbredo03.log'' TO ''/ora_data/sbredo03.log'' ";
SQL "ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP 1 ";
SQL "ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP 2 ";
SQL "ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP 3 ";
SQL "alter database disable block change tracking ";
SQL "alter database noarchivelog ";
SQL "alter database open resetlogs upgrade ";
}


script內容裡我覺得要解釋的是
1.redo log一定得透過alter database rename file 來進行,不然open resetlogs時,依舊會建在原路徑
2.until scn 9390628700021 是因為這份資料是做為OGG Initial Load,怎麼取得SCN,請參照Oracle Restore 時出現ORA-01547 及 ORA-01152一文內所給的語法
準備好你的rman script後,當然就是啟動rman放著讓它跑,跑的過程中,就是去傳檔archive log,傳完後就透過catalog 指令把archivelog 位置寫入control file裡,然後就是等rman 做完它該做的事情。

緊接著就是要進行升級datase internal catalog 等相關物件,既然是rman restore,archive log mode 一定會啟動,我的rman script裡頭就已經下了關掉archive log mode的指令,所以跑升級用catupgrd.sql檔案前,記得關掉資料庫先,然後startup upgrade,沒跑完catupgrd.sql是沒辦法把資料庫正常開啟的,指令如下。
cd $ORACLE_HOME/rdbms/admin
$ORACLE_HOME/perl/bin/perl catctl.pl -n 8 catupgrd.sql
internal catalog 升級完之後,catupgrd.sql會shutdown 資料庫instance,此時進行startup指令就能順利開啟資料庫,照升級的正規的步驟,緊接著要執行@utlu121s.sql看升級的報表,看是否有問題。但因為我的環境要透過OGG 同步DDL,開啟了DB Level的trigger,所以得透過下列幾個指令把OGG的schema砍掉,不然只要執行procedure就會出錯。
sqlplus / as sysdba
SQL> @ddl_disable
SQL> @ddl_remove
SQL> @marker_remove
SQL> drop user ggadmin cascade;
移除掉OGG之後,升級報表程式utlu121s.sql的執行才會正常,我貼個output給大家看
Oracle Database 12.1 Post-Upgrade Status Tool           05-08-2019 12:42:46

Component                               Current         Version  Elapsed Time
Name                                    Status          Number   HH:MM:SS

Oracle Server                          UPGRADED      12.1.0.2.0  00:07:34
JServer JAVA Virtual Machine              VALID      12.1.0.2.0  00:01:08
Oracle Workspace Manager                  VALID      12.1.0.2.0  00:00:28
OLAP Analytic Workspace                   VALID      12.1.0.2.0  00:00:16
OLAP Catalog                         OPTION OFF      10.2.0.5.0  00:00:00
Oracle OLAP API                           VALID      12.1.0.2.0  00:00:18
Oracle XDK                                VALID      12.1.0.2.0  00:01:22
Oracle Text                               VALID      12.1.0.2.0  00:00:31
Oracle XML Database                       VALID      12.1.0.2.0  00:01:40
Oracle Database Java Packages             VALID      12.1.0.2.0  00:00:10
Oracle Multimedia                         VALID      12.1.0.2.0  00:02:12
Spatial                                UPGRADED      12.1.0.2.0  00:02:58
Final Actions                                                    00:00:39
Post Upgrade                                                     00:02:06

Total Upgrade Time: 00:22:24

PL/SQL procedure successfully completed.
最後就是要升級timezone的版本,做到這個步驟的時候,我就覺得Oracle有點奸詐,因為執行升級的script一定得從metalink下載,我不知道沒做升級會不會在運作上出問題,因為眼前正在做的資料庫只是做為upgrade到18c的一個中繼資料庫,我後續還要透過datapump移轉資料到18c,但如果你是為了營運用,那我還是建議你把timezone版本升上去,不然就是透過datapump 直接把資料從10g轉到12.1timezone的升級文件請參看metalink文件"Scripts to automatically update the RDBMS DST (timezone) version in an 11gR2 or 12c  database . (Doc ID 1585343.1)"我把執行結果貼出來供大家參考


SQL> exec DBMS_STATS.PURGE_STATS(systimestamp);
PL/SQL procedure successfully completed.
SQL> exec dbms_stats.alter_stats_history_retention(31);
PL/SQL procedure successfully completed.
SQL> spool upg_tzv_check.log
SQL> @upg_tzv_check.sql
INFO: Starting with RDBMS DST update preparation.
INFO: NO actual RDBMS DST update will be done by this script.
INFO: If an ERROR occurs the script will EXIT sqlplus.
INFO: Doing checks for known issues ...
INFO: Database version is 12.1.0.2 .
INFO: Database RDBMS DST version is DSTv4 .
INFO: No known issues detected.
INFO: Now detecting new RDBMS DST version.
A prepare window has been successfully started.
INFO: Newest RDBMS DST version detected is DSTv18 .
INFO: Next step is checking all TSTZ data.
INFO: It might take a while before any further output is seen ...
A prepare window has been successfully ended.
INFO: A newer RDBMS DST version than the one currently used is found.
INFO: Note that NO DST update was yet done.
INFO: Now run upg_tzv_apply.sql to do the actual RDBMS DST update.
INFO: Note that the upg_tzv_apply.sql script will
INFO: restart the database 2 times WITHOUT any confirmation or prompt.
SQL> @upg_tzv_apply.sql
INFO: If an ERROR occurs the script will EXIT sqlplus.
INFO: The database RDBMS DST version will be updated to DSTv18 .
WARNING: This script will restart the database 2 times
WARNING: WITHOUT asking ANY confirmation.
WARNING: Hit control-c NOW if this is not intended.
INFO: Restarting the database in UPGRADE mode to start the DST upgrade.
Database closed.
Database dismounted.
ORACLE instance shut down.
Fixed Size 2934168 bytes
Variable Size 1543506536 bytes
Database Buffers 8086618112 bytes
Redo Buffers 30617600 bytes
Database mounted.
Database opened.
INFO: Starting the RDBMS DST upgrade.
INFO: Upgrading all SYS owned TSTZ data.
INFO: It might take time before any further output is seen ...
An upgrade window has been successfully started.
INFO: Restarting the database in NORMAL mode to upgrade non-SYS TSTZ data.
Database closed.
Database dismounted.
ORACLE instance shut down.
ORACLE instance started.
Total System Global Area 9663676416 bytes
Fixed Size 2934168 bytes
Variable Size 1543506536 bytes
Database Buffers 8086618112 bytes
Redo Buffers 30617600 bytes
Database mounted.
Database opened.
INFO: Upgrading all non-SYS TSTZ data.
INFO: It might take time before any further output is seen ...
INFO: Do NOT start any application yet that uses TSTZ data!
INFO: Next is a list of all upgraded tables:
Table list: "GSMADMIN_INTERNAL"."AQ$_CHANGE_LOG_QUEUE_TABLE_S"
Number of failures: 0
Table list: "GSMADMIN_INTERNAL"."AQ$_CHANGE_LOG_QUEUE_TABLE_L"
Number of failures: 0
Table list: "SQLTXPLAIN"."SQLT$_WRI$_OPTSTAT_AUX_HISTORY"
Number of failures: 0
Table list: "SQLTXPLAIN"."SQLT$_SQL_STATEMENT"
Number of failures: 0
Table list: "SQLTXPLAIN"."SQLT$_OPTSTAT_USER_PREFS$"
Number of failures: 0
Table list: "SQLTXPLAIN"."SQLT$_DBA_TAB_STATS_VERSIONS"
Number of failures: 0
Table list: "SQLTXPLAIN"."SQLT$_DBA_SCHEDULER_JOBS"
Number of failures: 0
Table list: "SQLTXPLAIN"."SQLT$_DBA_OPTSTAT_OPERATIONS"
Number of failures: 0
Table list: "SQLTXPLAIN"."SQLT$_DBA_IND_STATS_VERSIONS"
Number of failures: 0
Table list: "SQLTXPLAIN"."SQLT$_DBA_HISTGRM_STATS_VERSN"
Number of failures: 0
Table list: "SQLTXPLAIN"."SQLT$_DBA_COL_STATS_VERSIONS"
Number of failures: 0
Table list: "SQLTXPLAIN"."SQLT$_DBA_AUTOTASK_CLIENT_HST"
Number of failures: 0
INFO: Total failures during update of TSTZ data: 0 .
An upgrade window has been successfully ended.
INFO: Your new Server RDBMS DST version is DSTv18 .
INFO: The RDBMS DST update is successfully finished.
INFO: Make sure to exit this sqlplus session.
INFO: Do not use it for timezone related selects.
我們來看看版本
SQL> SELECT version FROM v$timezone_file;
VERSION
----------
18
1 row selected.

大功告成!!

Oracle Restore 時出現ORA-01547 及 ORA-01152

如果你去查metalink,找到文章"278856.1 Incomplete recovery gives ORA-01152",它會要你拿之前比較舊的備份來進行還原。我真的很懷疑,這篇文章是哪尊大神寫出來的,基本上就是我們在系統上做了一個control file 備份,準備拿它來還原到我們認為資料鮮度最近的時間點,這通常都跟db clone或者升級作業有關,常會伴隨著底下的錯誤
Incomplete recovery,RMAN-06053,RMAN-06025




其實看到錯誤就很直覺地想,有沒有方式能把這些archive log給RMAN ?
你只要把原機上的還未被備份拉走的archive log 傳到restore 主機上,然後透過catalog 指令把它寫入controlfile裡頭,讓rman 在進行restore的時候,能夠找到所需要的archive log存放的位置,restore就能順利跑下去了。

這是catalog 的語法範例
catalog archivelog '/ora_data/arch/1_278784_759598750.dbf';


278856.1文件裡有用的是作者給的sql 語句,用來查看產出control file時的SCN,這在建置OGG Incremental Replicat非常重要。

sql> select file#, status, checkpoint_change# from v$datafile;
sql> select file#, status, fuzzy, checkpoint_change# from v$datafile_header;

Oracle BIGFILE tablespace 效能疑慮

少說有10年了,有一次參加微軟的seminar,講師提到一個案例,碰到file group 資料檔只建了一個檔案,I/O 的效能不佳,找了storage 廠商來看了一下,說是作業系統端沒送多少指令到storage端,因此講師就建議implement的人新增多個data file,效能問題就解了。所以當Oracle 的bigfile table space 的功能出來的時候,我就在想,會不會碰到同樣的問題?適逢一個資料庫升級專案,連硬體都整套換新,剛好AP Leader拋了一個問題過來,就拿來測看看做比較吧!!
AP Leader 是覺得某個功能內的insert append執行速度不夠快,就把parallel DML 打開來,結果系統就拋了ORA-12838的exception出來,問我有沒有方式可以改善,我查了一下metalink 資料,如果照他的程式架構,應該沒辦法改程式,總不能在該段insert append 結束後,馬上commit,真這樣做的話,他程式的exception處理就要多花很多工來處理資料回復。因為新系統上我使用bigfile tablespace 來存放資料(不然800GB及600GB,我要花很多KEY IN的工),所以想說,會不會是bigfile tablespace的I/O效能問題,就回覆了AP Leader,另建兩個傳統的表格空間(small file)來給他進行測試,測完他說,沒差異。

因為新系統storage 是SSD,基本上I/O的表現應該不會弱於舊系統,我就接著問,有比舊系統快嗎 ?? 他說有,但不像其他的模組,快上11倍及15倍,只不到2倍.........................

喔!!好吧.......那我也沒輒了!!至少這個case解了我心中的疑問了,我沒數據,因為是別人的測試。

第一隻用在實務管理上的Perl 程式

延續Oracle 非最高權限怎麼砍session ,就算開發了讓AP自行砍SESSION的程式給他們來使用,還是會碰到session status是KILLED, 但會因為dblink等不到對方回應的狀況下,Oracle RDBMS沒辦法把server process 釋放掉,而造成process逐步累積後,最終達到參數檔裡頭processes 參數值的上線,導致無法連線,發生障礙而影響到業務。所以我用Perl 寫了一隻清理process的程式,它是被包在底下的shell script裡頭的,因為我要先把相關資料透過sqlplus 拋出,然後用Perl 強而有力的regex找出process id ,然後由Perl來呼叫系統指令kill -9 來砍process





PROCESS_FILE=/tmp/$ORACLE_SID.$EXEC_TIME

sqlplus "/ as sysdba" << !>$PROCESS_FILE

SET sqlprompt ''

SET sqlnumber off

SET verify off

SET pages 0

SET echo off

SET feedback off

SET feed off

select 'a' from dual;

select spid, program from v\$process

where program!= 'PSEUDO'

and addr not in (select paddr from v\$session)

and addr not in (select paddr from v\$bgprocess)

and addr not in (select paddr from v\$shared_server);

exit

!

perl clear_process.pl $PROCESS_FILE



底下perl 的程式碼,夠簡單了吧~~

這就是它regex強悍的地方

如果用shell script來寫,我可能得想破腦袋



use strict;

use warnings;

my $filename = shift;

open(my $fh, '<', $filename) or die "Could not open file '$filename' $!"; while (my $row = <$fh>) {

chomp $row;

if ($row =~ /^\d/ ) {

my @line = split /\s* /, $row;

if ( not defined $line[2] )

{

print "$line[0] ,$line[1] \n";

my $cmd = "kill -9 $line[0]";

system($cmd);

sleep(1);

}

}

}

RMAN Restore Upgrade from 10.2.0.5 to 12.1.0.2 所碰到的問題

本來沒有想寫這一篇的,因為看Internet 有人寫得很詳細,而且oracle-base網站也貼了相同的主題,都沒提到有錯誤發生,怎麼會我就奶油桂花手,在restore的過程中就是會發生錯誤,我就把我碰到的錯誤及解法寫出來,供有興趣的人參考。

首先我碰到的是ORA-10561及600的錯誤
ORA-10561









碰到這個問題,當然是去查metalink的資料,文件ID 25481759.8開頭的描述如下
ORA-600 [6101] in 12c during recovery of INDEX blocks when applying redo log generated in 11.2
它的workaround 講的是廢話.....
後來找到了這篇14301592.8,嘗試使用它的workaround
run the recovery with ALLOW 1 CORRUPTION
這個資料庫其實只是要用來做為移轉到18c的中繼資料庫,想說index掛了就掛了,又不會用到,所以就下了recover database allow 1 corruption 讓restore的過程能夠順利進行。
再次進行restore upgrade 測試就發現rman 在recover 的過程中卡在一個archive log,也不秀錯誤訊息,看top 的output,就是pr02 這個背景行程一直在跑,耗用掉一個 cpu core的運算資源,去看alert log就有錯誤訊息了,一樣是600[6101]的錯誤
alter database recover logfile '/ora_data/arch_orcl/1_319579_759438825.dbf'
Mon May 06 14:32:01 2019
Media Recovery Log /ora_data/arch_orcl/1_319579_759438825.dbf
Errors in file /u01/app/oracle/diag/rdbms/orcl/ORCL/trace/ORCL_ora_8133.trc&nbsp; (incident=108887):
ORA-00600: internal error code, arguments: [6101], [3342], [3347], [32], [], [], [], [], [], [], [], []
Incident details in: /u01/app/oracle/diag/rdbms/orcl/ORCL/incident/incdir_108887/ORCL_ora_8133_i108887.trc
我只好請NBU負責人幫我備一份Incremental,再重新進行restore,用以跳過出問題的archive log 的修復,這方式是可行的

最後我還是開了一個 Case給Oracle Global Support,說是要上patch 25481759,只好打上去看看,做了一次restore,還真的解決了。


說也奇怪,我在兩個資料庫都下了指令進行validate structure,找不到錯誤,每日查看Data Guard的同步狀況,也都很正常,沒看到任何錯誤,應該真的是個bug。