新聞中心
近年來,我們專注于提供全系列企業級性能管理方案和相關的IT服務,在幫助用戶提高業務效率和整體生產力的同時,降低運營和運維成本。
返回列表
首頁 / 新聞資訊 / 行業資訊
案例 | 12c新特性引發的ora-01017故障問題解決方案
來源:   日期:2018-07-02
微信圖片_20180626150309.jpg
東方龍馬(OLM)



作者:王飛揚  東方龍馬·北京

                                      

近日,某客戶反映應用連接數據庫異常,應用經常報錯ora-01017錯誤,經了解,數據庫版本為12.1.0.2.0RAC環境,操作系統為linuxRedhat 6.5,在詢問了詳細的異常情況后,得知錯誤是在應用連接時配置連接串為service name時導致,由于是生產系統,于是決定先做應急處理,讓用戶把連接串servicename改為sid方式,暫時指定到一個節點上,作為應急方案,不能影響用戶使用。


遠程連接到客戶現場,先驗證了幾個自己的猜想,首先想到密碼錯誤?用戶密碼大小寫敏感?口令文件出問題了?TNS文件配置問題?……


在查看alert日志后,沒有發現什么有價值的信息,隨后繼續查看監聽日志,也沒什么信息,而且監聽文件內容較多不適合檢索,在經過一系列的確認后,暫時未發現故障原因,于是決定手動重現異常現象,當我們使用sqlplus/ as sysdba本地連接時,兩節點均不報錯,但是使用sqlplus user/[email protected]連接時,故障現象重現了,下面就是本人基于故障現象模擬重現了一次。

 

解決方案過程


基于應用描述情況,新建用戶進行手動測試,測試過程如下:

1、  新建數據庫測試用戶test


2、建立本地tnsname文件,使用兩節點的vip建立tnsname文件,大致如下

TEST =

(DESCRIPTION =

(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.3.88)(PORT=1521)))

(CONNECT_DATA =

(SERVER = DEDICATED)

(SERVICE_NAME = orcl) 


3、使用sqlplus user/[email protected]方式多次測試連接,故障重現,故障現象為偶發報錯ORA-01017錯誤,并不是每一次都報錯,這很奇怪,數據庫偶爾可以登錄,偶爾失敗,且錯誤只在節點1上發生,節點2無異常現象。


$ sqlplus test/[email protected]         -------本次登錄正常

SQL*Plus: Release12.1.0.2.0 Production on Wed Jun 6 10:25:35 2018

Copyright (c) 1982, 2014,Oracle.  All rights reserved.

Last Successful login time:Wed Jun 06 2018 10:25:33 +08:00

Connected to:

Oracle Database 12cEnterprise Edition Release 12.1.0.2.0 - 64bit Production

With the Partitioning, RealApplication Clusters, Automatic Storage Management, OLAP,

Advanced Analytics and RealApplication Testing options

SQL> exit



登陸失敗 

報錯 ora-01017

$ sqlplus test/[email protected]         -------再次登錄失敗

SQL*Plus: Release12.1.0.2.0 Production on Wed Jun 6 10:25:38 2018

Copyright (c) 1982, 2014,Oracle.  All rights reserved.

ERROR:

ORA-01017: invalidusername/password; logon denied

Enter user-name: ^C


冷靜下來仔細思考一番,在排除其他問題原因后,再一次檢查監聽狀態和數據庫資源狀態,其中檢查監聽狀態時發現,節點1監聽狀態如下:


$ lsnrctl status

…….

Service "+ASM"has 1 instance(s).

  Instance "+ASM1", status READY, has1 handler(s) for this service...

Service"-MGMTDBXDB" has 1 instance(s).

  Instance "-MGMTDB", status READY,has 1 handler(s) for this service...

Service "_mgmtdb"has 1 instance(s).

  Instance "-MGMTDB", status READY,has 1 handler(s) for this service...

Service "orcl"has 2 instance(s).

  Instance "-MGMTDB", status READY,has 1 handler(s) for this service...

  Instance "orcl1", status READY, has1 handler(s) for this service...

Service "orclXDB"has 1 instance(s).

  Instance "orcl1", status READY, has1 handler(s) for this service...

The command completedsuccessfully



對比節點2監聽狀態:

Services Summary...

Service "+ASM"has 1 instance(s).

  Instance "+ASM2", status READY, has1 handler(s) for this service...

Service "orcl"has 1 instance(s).

  Instance "orcl2", status READY, has1 handler(s) for this service...

Service "orclXDB"has 1 instance(s).

  Instance "orcl2", status READY, has1 handler(s) for this service...

The command completedsuccessfully


突然發現了之前沒有注意的一個地方,就是節點1比節點2多出一個實例-MGMTDB,問了一下客戶,這個是什么,客戶說他們也不清楚,不是他們的東西,但是仔細一想,它們在同一個service下,如果連接被傳遞給mgmtdb實例的話,那么肯定會發生ora-01017。于是查閱相關資料,發現其與12c的新特性有關:原本在11g中由Berkeley DB管理的CHM repository改成了Oracle db管理:



 官方解釋如下:

MGMTDB is new databaseinstance which is used for storing Cluster Health Monitor (CHM) data. In 11gthis was being stored in berkley database but starting Oracle database 12c itis configured as  Oracle Database Instance.


在了解了MGMTDB是什么后,猜想這個會不會是12c的bug,于是到mos上進一步查看相關文檔,果然發現了如下bug:


MGMTDB registers Database Service (Doc ID 2063662.1)

GIMR (Management Database) Registers Into Same Service that the DatabaseInstance also registers On RAC (Doc ID 2024572.1)


文檔中描述,該問題在數據庫與cluster name同名時發生,會導致mgmtdb把自己注冊到這個與cluster name同名數據庫的default service下。


MGMTDB registers with default service which is same as the cluster name.  If the database nameis same as the cluster name,  MGMTDB registered to the service that isdatabase name because it is same as the cluster name.


于是和客戶確認,其數據庫名與Cluster name相同,均為orcl。


4.jpg


根據mos文檔,GIMR (Management Database) Registers Into Same Service that the DatabaseInstance also registers On RAC (文檔 ID2024572.1)



 官方給出的解決方案為:

The following workaroundworked for some, so try the following workaround if changing the database nameis not feasible:

1)connect to MGMTDB

$ su - grid
$ export ORACLE_SID=-MGMTDB
$ sqlplus / as sysdba


將MGMTDB實例的local_listener參數設置成監聽私網ip


2)modify local_listener ofMGMTDB
SQL> alter system set local_listener='(ADDRESS=(PROTOCOL=TCP)(HOST=<node1interconnect IP>)(PORT=<mgmtlsnr port number>))','(ADDRESS=(PROTOCOL=TCP)(HOST=<node2interconnect IP>)(PORT=<mgmtlsnr port number>))' scope=both;


于是按照MOS給出的解決方案,進行修改。

修改完成后,再次查看兩節點監聽狀態:


節點1

Services Summary...

Service "+ASM"has 1 instance(s).

  Instance "+ASM1", status READY, has1 handler(s) for this service...

Service "orcl"has 1 instance(s).

  Instance "orcl1", status READY, has1 handler(s) for this service...

Service "orclXDB"has 1 instance(s).

  Instance "orcl1", status READY, has1 handler(s) for this service...

The command completedsuccessfully


節點2

Services Summary...

Service "+ASM"has 1 instance(s).

  Instance "+ASM2", status READY, has1 handler(s) for this service...

Service "orcl"has 1 instance(s).

  Instance "orcl2", status READY, has1 handler(s) for this service...

Service "orclXDB"has 1 instance(s).

  Instance "orcl2", status READY, has1 handler(s) for this service...

The command completedsuccessfully


可以看到此處,MGMTDB消失了,于是再次測試是否還會出現ora-01017問題,經測試,問題沒有再出現,經檢查,兩節點狀態均正常,于是告知客戶,可以把連接串修改回service name,后經應用測試,原有連接方式可以正常使用,故障解決。


以上就是我本次故障處理的經過了,分享給大家希望可以給大家一些幫助。



微信圖片_20180626150221.jpg


|  北京    |    上海    |   廣州    |   成都    |


4008-906-960


微信圖片_20180626150229.png


4008-906-960

全國免費咨詢電話
  • 官方微博
  • 官方微信
Copyright 1998-2016 版權所有 北京東方龍馬軟件發展有限公司 京ICP備14000200號-1
上海时时彩加盟 一个高中生能做什么赚钱 三分快三能赚钱吗 捕鱼平台游戏 安卓软件试玩怎么赚钱吗 内蒙古老友麻将技巧 有没有捕鸟达人老版本 语音平台如何赚钱 天津后广场干啥赚钱 阿里彩票首页 二十多女生做什么生意本钱小赚钱多 穿越火线世界最赚钱游戏下载器 大红鹰彩票游戏 快手怎么赚钱秒懂 哪个手游挂机赚钱的 麻将怎么算赢 棋牌室怎么开赚钱