溫馨提示×

溫馨提示×

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

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

【問題處理】偶遇ORA- 01075: you are currently logged on錯誤

發布時間:2020-08-11 19:30:46 來源:ITPUB博客 閱讀:242 作者:路途中的人2012 欄目:建站服務器
今天在創建物理DataGuard過程中,在主庫調整完參數啟動數據庫后,連接數據庫時便遭遇了ORA-01075錯誤,導致數據庫無法登陸,后續工作無法進行。
這個問題不局限在DataGuard配置這個場景。簡單排查一下這個錯誤,供參考。

1.問題現象
1)登陸時的報錯
[oracle@secdb1
~]$ sqlplus / as sysdba

SQL*Plus: Release 10.2.0.1.0 - Production on Sun Jul 24 20:01:10 2010

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

ERROR:
ORA-01075: you are currently logged on

2)即便登陸成功在執行SQL命令的時候一樣會收到報錯
sys@secdb> select * from dual;
select * from dual
              *
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-00018: maximum number of sessions exceeded

2.問題分析
單純從ORA-01075報錯信息本身無法定位問題。
從alert日志中發現“ORA-00018: maximum number of sessions exceeded”報錯信息。細查之后發現此時后臺出現大量的歸檔進程,而且數據庫中的processes=50,是由于超出了session限制導致的這個報錯。

數據庫后臺的進程信息如下:
[oracle@secdb1 ~]$ ps -ef | grep secdb | grep -v grep
oracle   10023     1  0 19:13 ?        00:00:00 ora_pmon_secdb
oracle   10025     1  0 19:13 ?        00:00:00 ora_psp0_secdb
oracle   10027     1  0 19:13 ?        00:00:00 ora_mman_secdb
oracle   10029     1  0 19:13 ?        00:00:00 ora_dbw0_secdb
oracle   10031     1  0 19:13 ?        00:00:00 ora_lgwr_secdb
oracle   10033     1  0 19:13 ?        00:00:00 ora_ckpt_secdb
oracle   10035     1  0 19:13 ?        00:00:00 ora_smon_secdb
oracle   10037     1  0 19:13 ?        00:00:00 ora_reco_secdb
oracle   10039     1  0 19:13 ?        00:00:00 ora_cjq0_secdb
oracle   10041     1  0 19:13 ?        00:00:00 ora_mmon_secdb
oracle   10043     1  0 19:13 ?        00:00:00 ora_mmnl_secdb
oracle   10063     1  0 19:13 ?        00:00:00 ora_p000_secdb
oracle   10065     1  0 19:13 ?        00:00:00 ora_p001_secdb
oracle   10067     1  0 19:13 ?        00:00:00 ora_p002_secdb
oracle   10069     1  0 19:13 ?        00:00:00 ora_p003_secdb
oracle   10071     1  0 19:13 ?        00:00:00 ora_p004_secdb
oracle   10077     1  0 19:13 ?        00:00:00 ora_arc0_secdb
oracle   10079     1  0 19:13 ?        00:00:00 ora_arc1_secdb
oracle   10081     1  0 19:13 ?        00:00:00 ora_arc2_secdb
oracle   10083     1  0 19:13 ?        00:00:00 ora_arc3_secdb
oracle   10085     1  0 19:13 ?        00:00:00 ora_arc4_secdb
oracle   10087     1  0 19:13 ?        00:00:00 ora_arc5_secdb
oracle   10089     1  0 19:13 ?        00:00:00 ora_arc6_secdb
oracle   10091     1  0 19:13 ?        00:00:00 ora_arc7_secdb
oracle   10093     1  0 19:13 ?        00:00:00 ora_arc8_secdb
oracle   10095     1  0 19:13 ?        00:00:00 ora_arc9_secdb
oracle   10100     1  0 19:13 ?        00:00:00 ora_arca_secdb
oracle   10103     1  0 19:13 ?        00:00:00 ora_arcb_secdb
oracle   10105     1  0 19:13 ?        00:00:00 ora_arcc_secdb
oracle   10107     1  0 19:13 ?        00:00:00 ora_arcd_secdb
oracle   10109     1  0 19:13 ?        00:00:00 ora_arce_secdb
oracle   10111     1  0 19:13 ?        00:00:00 ora_arcf_secdb
oracle   10113     1  0 19:13 ?        00:00:00 ora_arcg_secdb
oracle   10115     1  0 19:13 ?        00:00:00 ora_arch_secdb
oracle   10117     1  0 19:13 ?        00:00:00 ora_arci_secdb
oracle   10119     1  0 19:13 ?        00:00:00 ora_arcj_secdb
oracle   10121     1  0 19:13 ?        00:00:00 ora_arck_secdb
oracle   10123     1  0 19:13 ?        00:00:00 ora_arcl_secdb
oracle   10125     1  0 19:13 ?        00:00:00 ora_arcm_secdb
oracle   10127     1  0 19:13 ?        00:00:00 ora_arcn_secdb
oracle   10132     1  0 19:13 ?        00:00:00 ora_arco_secdb
oracle   10135     1  0 19:13 ?        00:00:00 ora_arcp_secdb
oracle   10137     1  0 19:13 ?        00:00:00 ora_arcq_secdb
oracle   10139     1  0 19:13 ?        00:00:00 ora_arcr_secdb
oracle   10141     1  0 19:13 ?        00:00:00 ora_arcs_secdb
oracle   10143     1  0 19:13 ?        00:00:00 ora_arct_secdb
oracle   10173     1 29 19:13 ?        00:00:26 ora_qmnc_secdb
oracle   10229     1  0 19:14 ?        00:00:00 ora_q000_secdb
oracle   10296 10294  0 19:14 ?        00:00:00 oraclesecdb (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))

可見后臺啟動了非常多的歸檔進程,正是這些進程占滿了所有50個session,導致系統無法登陸。

3.問題處理
1)停止數據庫
既然已經無法正常登陸到數據庫,只能強制使用操作系統命令將其終止。
$ ps -ef |grep $ORACLE_SID|grep -v grep|awk '{print $2}' | xargs kill -9
$ ipcs -m | grep oracle | awk '{print $2}' | xargs ipcrm shm

嚴重警告:以上命令嚴禁在任何數據庫服務器上進行嘗試!
關于上面兩條命令的闡述請參考《【Kill】兩條Linux命令徹底殺死Oracle》(http://space.itpub.net/519536/viewspace-619787)

2)修改系統參數processes為500

3)重新啟動數據庫
問題處理完畢。

4.小結
此處遭遇的這個問題比較巧合,后臺正好超過了50個session,在我調整完processes為500之后,后臺session數還是穩定在50左右。
這個案例告訴我們:在項目實施過程之前一定要對每一個參數細細斟酌和考量,不要人為的給自己增加困難。

Good luck.

secooler
10.07.24

-- The End --

向AI問一下細節

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

AI

亚洲午夜精品一区二区_中文无码日韩欧免_久久香蕉精品视频_欧美主播一区二区三区美女