新网Logo
首页>虚机资讯>

【问题处理】偶遇ORA- 01075: you are currently logged on错误

登录 注册

【问题处理】偶遇ORA- 01075: you are currently logged on错误

  • 来源:网络
  • 更新日期:2020-08-11

摘要:建站服务器 今天在创建物理DataGuard过程中,在主库调整完参数启动数据库后,连接数据库时便遭遇了ORA-01075错误,导致数据库无法登陆,后续工作

建站服务器 今天在创建物理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 --

新网虚拟主机