談?wù)凮racle為2019年埋下的雷：Oracle關(guān)于DBLINK的預(yù)警

最近一個(gè)月，Oracle在MOS上發(fā)布了兩篇與DBLINK相關(guān)的預(yù)警：

Oracle Databases Need to be Patched to a Minimum Patchset/PSU/RU level before April

2019 (Doc ID 2361478.1)

Mandatory Patching Requirement for Database Versions 11.2.0.3 or Earlier, Using DB

Links (Doc ID 2335265.1)

文章大概的意思是：11.2.0.3 及以前版本，使用DB Link的，在2019年4月前必須應(yīng)用到推薦的補(bǔ)丁，否則你使用DBLINK的場(chǎng)景可能會(huì)遇到故障。

看似很?chē)?yán)重，有點(diǎn)以前2000年說(shuō)的千年蟲(chóng)的味道，其實(shí)仔細(xì)研究，這個(gè)預(yù)警其實(shí)沒(méi)多大的事。

1.?????? 這個(gè)補(bǔ)丁是什么用途？

增加DBMS_SCN的工具包，設(shè)置在2019年6月23日，自動(dòng)啟用 3 級(jí)兼容性，提升SCN的可用量。從16K/s或32K/s的增長(zhǎng)率，提升到 96K/s 的增長(zhǎng)率，目標(biāo)是讓數(shù)據(jù)庫(kù)支持的變化更多，承載能更強(qiáng)。

但是注意：圖1中可以看出，3級(jí)兼容性的SCN上限是高很多的，但畢竟還是有上限的，所以就算啟動(dòng)3級(jí)兼容性，SCN 越界的ORA-19706問(wèn)題仍然可能會(huì)遇到。

2.?????? 本次預(yù)警涉及哪些版本需打補(bǔ)丁？

豁免版本：11.2.0.4 和 12.1.0.2 及以上版本，已然自帶加持；

10g 版本：你可以選擇升級(jí)到 11g 或者 12c；

11.1版本：你可以選擇升級(jí)到11.1.0.7 版本，應(yīng)用補(bǔ)丁升級(jí)到11.1.0.7.20+；

11.2版本：你可以選擇升級(jí)到11.2.0.3 版本，應(yīng)用補(bǔ)丁升級(jí)到11.2.0.3.9+；

12.1版本：你至少升級(jí)到 12.1.0.2.0 版本；

版本對(duì)應(yīng)的補(bǔ)丁：

3.?????? 怎么檢查數(shù)據(jù)庫(kù)有沒(méi)包含相關(guān)的補(bǔ)丁和它的一些信息？

最簡(jiǎn)單的是在sqlplus下,desc dbms_scn

如果存在這個(gè)工具，就是包含補(bǔ)丁的。

可以在sqlplus下用以下腳本檢查：

vi scncomp.sql

declare

v_date date;

v_compat number;

v_enable boolean;

begin

dbms_scn.getscnautorolloverparams(v_date, v_compat, v_enable);

dbms_output.put_line('date:' || to_char(v_date, 'yyyymmddhh24miss') || ', compatiable:' || v_compat );

if v_enable then

dbms_output.put_line('Auto-rollover is enabled');

else

dbms_output.put_line('Auto-rollover is disabled');

end if;

end;

很明顯，這個(gè)補(bǔ)丁將會(huì)在20190623這天啟動(dòng)3級(jí)兼容性

4.?????? 相關(guān)補(bǔ)丁和SCN有關(guān)系，但好像與DBLINK沒(méi)啥關(guān)系啊？

低版本和高版本之間的數(shù)據(jù)庫(kù)通過(guò)DB Link互聯(lián)，可能受到影響，主要取決于高SCN系統(tǒng)的高度，因?yàn)楦甙姹镜腟CN增長(zhǎng)算法改變，當(dāng)高版本的current SCN值在高位時(shí)，可能瞬間抬升低版本的SCN至越界（認(rèn)真觀察圖1，3級(jí)兼容的上限高很多），DBLINK的訪(fǎng)問(wèn)就被拒絕和報(bào)錯(cuò)了。

通過(guò)DBLINK的查詢(xún)會(huì)同步數(shù)據(jù)庫(kù)的SCN，這個(gè)結(jié)論的實(shí)驗(yàn)就不做了，蓋總博客有，可以自行觀察有DBLINK互相訪(fǎng)問(wèn)的那幾個(gè)庫(kù)，current scn值是否都在同一個(gè)數(shù)量級(jí)，即可以驗(yàn)證。

注：高版本就是 11.2.0.4 和 12.1.0.2 及其以上版本，和打過(guò)補(bǔ)丁的 11.1.0.7和 11.2.0.3 版本；其他的都為低版本。

5.?????? 怎么檢查SCN還多久到達(dá)上限？

SCN其實(shí)有2個(gè)上限值，一個(gè)是硬限制：

Oracle 使用了6 Bytes 記錄SCN，也就是48位，即SCN的最大值是281萬(wàn)億（281,474,976,710,656），到達(dá)這個(gè)數(shù)值后，數(shù)據(jù)庫(kù)將再也啟動(dòng)不了，需要重建數(shù)據(jù)庫(kù)才能解決。按3級(jí)兼容的96K/s的速度，也可以用90年，所以這不是我們考慮的上限，遠(yuǎn)達(dá)不到。

我們需要考慮的是軟上限，還是得認(rèn)真觀察圖1，

下面是Oracle提供的計(jì)算多久到達(dá)軟上限的公式：

select

version,

date_time,

dbms_flashback.get_system_change_number current_scn,

Headroom

from

(

select

version,

to_char(SYSDATE,'YYYY/MM/DD HH24:MI:SS') DATE_TIME,

((((

((to_number(to_char(sysdate,'YYYY'))-1988)*12*31*24*60*60) +

((to_number(to_char(sysdate,'MM'))-1)*31*24*60*60) +

(((to_number(to_char(sysdate,'DD'))-1))*24*60*60) +

(to_number(to_char(sysdate,'HH24'))*60*60) +

(to_number(to_char(sysdate,'MI'))*60) +

(to_number(to_char(sysdate,'SS')))

) * (16*1024)) - dbms_flashback.get_system_change_number)

/ (16*1024*60*60*24)

) Headroom

from v$instance

)

這些顯示還有629天，是否到629天我數(shù)據(jù)庫(kù)就不能用呢？

不是的，

1)????? Oracle提供的公式，用的是兼容性1的16K速度來(lái)計(jì)算，而我實(shí)際版本是兼容性2的32K速度的，所以這個(gè)HEADROOM值只能大概參考。

2)????? current scn是在不斷增大的，可每天可到達(dá)的SCN limit值也在增大啊（看圖1），629天后，那時(shí)都被自動(dòng)開(kāi)啟過(guò)兼容性3了，那當(dāng)天SCN limit值又倍增不少（看圖1）。結(jié)合根據(jù)計(jì)算公式來(lái)看，629天后也遠(yuǎn)達(dá)不到軟上限值。

補(bǔ)充下SCN Headroom概念：

Headroom（天） = (Reasonable SCN Limit -CurrentSCN)/ SCN每秒最大可能增長(zhǎng)

速率/3600/24

也就是如果SCN按最大速率增長(zhǎng)，達(dá)到當(dāng)前理論最大值需要的天數(shù)。這個(gè)值可以用來(lái)

判斷SCN增長(zhǎng)速率是否過(guò)快。

補(bǔ)充下計(jì)算公式中，兼容級(jí)別1-3中用于計(jì)算的初始時(shí)間：

1：~1988/01/01

2：~ 1998/07/01

3： ~ 2008/03/30

接近上限值的時(shí)候，就可能開(kāi)始報(bào)錯(cuò)了：

--相關(guān)隱含參數(shù)_external_scn_rejection_threshold_hours, 采集自11.2.0.3.9

select ksppinm,ksppstvl,ksppdesc from x$ksppi x,x$ksppcv y where x.indx=y.indx and ksppinm like '_external_scn_rejection_threshold_hours';

這個(gè)參數(shù)在11.2.0.2版本之前是744，也就是31天。意思是SCN Headroom剩下31天時(shí)，就會(huì)拒絕DBLINK訪(fǎng)問(wèn)。

例子：

ORA-19706錯(cuò)誤：最常見(jiàn)的就是拒絕dblink連接的時(shí)候，如A庫(kù)跟B庫(kù)通過(guò)dblink連接，

A的SCN有通過(guò)人為調(diào)整增大許多，連接B庫(kù)的時(shí)候，Oracle會(huì)判斷該SCN傳播過(guò)來(lái)之

后，如果會(huì)導(dǎo)致SCN headroom小于_external_scn_rejection_threshold_hours設(shè)置的

閾值，則拒絕連接。

6.?????? 打了補(bǔ)丁后，DBLINK就肯定不會(huì)出問(wèn)題么？哪些庫(kù)最優(yōu)先要打補(bǔ)丁？

不，打了補(bǔ)丁，只是讓數(shù)據(jù)庫(kù)可以支持到96K/s秒的速率，這樣就極大增高當(dāng)天的SCN LIMIT（看圖1），讓你很難達(dá)到SCN軟上限。

但是

1）我們怕SCN被DBLINK傳染，有沒(méi)可能DBLINK連到一個(gè)曾經(jīng)壞過(guò)，用推進(jìn)多次SCN的方法開(kāi)庫(kù)又未重建的數(shù)據(jù)庫(kù)呢？一堆數(shù)據(jù)庫(kù)DBLINK互聯(lián)傳染SCN呢？

2）我們怕數(shù)據(jù)庫(kù)BUG等異常造成的SCN異常。

如果你的數(shù)據(jù)庫(kù)不使用DBLINK連其他庫(kù)，業(yè)務(wù)也不忙，確實(shí)可以不打補(bǔ)丁。

11.2.0.2之前的數(shù)據(jù)庫(kù)版本，SCN的默認(rèn)的最大增長(zhǎng)速率是16K/s，

11.2.0.2及之后的數(shù)據(jù)庫(kù)版本，SCN的默認(rèn)的最大增長(zhǎng)速率是32K/s，

--相關(guān)隱含參數(shù)_max_reasonable_scn_rate，采集自11.2.0.3.9

select ksppinm,ksppstvl,ksppdesc from x$ksppi x,x$ksppcv y where x.indx=y.indx and ksppinm like '_max_reasonable_scn_rate';

如果你的業(yè)務(wù)增長(zhǎng)速度可能超過(guò)16K或者32K的（超過(guò)兼容性級(jí)別的速率），就需要小心了。

可以取業(yè)務(wù)高峰時(shí)的AWR，觀察calls to kcmgas的速率。

在2018年3月份里，兼容性為1（16K速率）的SCN極限值為15.9萬(wàn)億，兼容性為2（32K速率）的SCN極限值為20.7萬(wàn)億。

select to_char(current_scn) from v$database;

查詢(xún)自己庫(kù)的current SCN和極限值對(duì)比，如果接近，就要小心了。

查詢(xún)select * from dba_db_links，看看自己庫(kù)和其他系統(tǒng)的關(guān)聯(lián)。

主要是計(jì)算以業(yè)務(wù)高峰的速率，SCN還多久會(huì)達(dá)到軟上限。

綜合這些情況下，自己的庫(kù)和DBLINK目標(biāo)庫(kù)都要盡早打上補(bǔ)丁。

參考文檔

恩莫公眾號(hào)、中亦安圖公眾號(hào)

開(kāi)發(fā)者 數(shù)據(jù)庫(kù)

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶(hù)投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請(qǐng)聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶(hù)投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請(qǐng)聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。