91超碰碰碰碰久久久久久综合_超碰av人澡人澡人澡人澡人掠_国产黄大片在线观看画质优化_txt小说免费全本

溫馨提示×

溫馨提示×

您好,登錄后才能下訂單哦!

密碼登錄×
登錄注冊×
其他方式登錄
點擊 登錄注冊 即表示同意《億速云用戶服務條款》

12cR2 RAC+RAC+ADG ORA-16854

發布時間:2020-07-01 04:38:43 來源:網絡 閱讀:1023 作者:roidba 欄目:關系型數據庫

近期在某銀行生產搭建了一套RAC+RAC+ADG+BROKER的生產系統,遇到了不少坑,再此做一個記錄。大家有疑問,可以給我留言,一起討論學習。

1、環境描述
Oralce 12cR2 RAC+RAC ADG broker

2、類似現象
DGMGRL> show configuration verbose

Configuration - FSF

Protection Mode: MaxAvailability
Members:
test_a - Primary database
standby_c - Physical standby database
standby_b - Physical standby database
Warning: ORA-16854: apply lag could not be determined
##告警ORA-16854 無法確認應用延遲,告警現象和我遇到的是一模一樣的。

3、解決方法
MOS 官方提供了兩個方法,具體情況還需要進一步分析
1)有可能是BUG
Workaround: set the ApplyLagThreshold=0 but this means you will not receive notifications of apply lag in Broker for the specified Standby database:

dgmgrl> edit database <standby db_unique_name> set property ApplyLagThreshold=0;

Please download and apply existing fix for BUG 28803345 or open SR and request backport of BUG 28803345 to resolve the issue.
2)重建控制文件
To solve this issue, recreate the standby controlfile.

Here steps for how to recreated the standby controlfile:

Steps to recreate a Physical Standby Controlfile (Doc ID 459411.1)

Please note in few cases apply lag in v$dataguard_stats was null in the database and Clearing ORLs in standby helped resolve the NULL value issue.

4、開SR
有條件或者服務的朋友可以開一個SR,明確一下問題。

向AI問一下細節

免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。

AI

九江市| 昂仁县| 湖口县| 镇坪县| 辽宁省| 客服| 搜索| 沾益县| 平阳县| 屯门区| 蓬安县| 蛟河市| 清远市| 松阳县| 浪卡子县| 瓮安县| 于都县| 石楼县| 德清县| 六枝特区| 洛南县| 昌江| SHOW| 体育| 望江县| 淮阳县| 濮阳市| 石棉县| 普宁市| 哈尔滨市| 泰宁县| 观塘区| 乐业县| 宿松县| 马公市| 江达县| 永兴县| 阳城县| 县级市| 招远市| 台湾省|