在数据库的使用过程中，数据库连接、登录失败是最常见的问题，大部分情况下解决起来都较为简单，但复杂起来也挺恼火的。

以下是我个人遇到的一些相关问题整理，目前已整理五个案例供大家参考，后续遇到新的情况持续更新...

数据库首次使用连接失败排查思路：

       本地数据库连接失败
        1)数据库服务是否启动 【ps -ef|grep dmserver】
        2)用户名密码是否正确      
        3)端口是否正确

       应用或远程连接失败
        1)数据库IP/端口是否可达 【telnet 服务器IP 端口号 ssh -v -p 端口号 服务器IP】
        2)防火墙策略
        3)连接串配置是否正确
        5)使用数据库服务器上自带的disql工具尝试连接

突发连接失败问题排查思路：

  现场是/否做了什么操作导致的数据库异常。第一确定环境是否正常（网络、磁盘、内存）。现象是什么、错误提示是什么、异常日志是什么。

      1）网络：ping 服务器网络是/否可通，telnet数据库端口是/否可通

      2）磁盘：df –h 查看服务器磁盘是/否有剩余空间,关注根目录和数据盘

      3）系统盘/数据盘读写情况：是/否只读（创建文件测试）、是/否繁忙（busy100%）

      4）内存：free 查看服务器内存是/否有剩余

      5）系统日志：系统日志是否有明显报错（搜索dmserver，如：oom）

数据库异常现象：

      1）数据库进程存在：

          a、disql 是/否能连接数据库（排序、分组、插入、建表等）

          b、查看数据库server日志是否正常刷新（ckpt值、ERROR等）

      2）数据库进程不存在：

          a、是否生成core（分析core堆栈，找到触发的sql语句）

          b、查看数据库server日志及其他日志（集群情况wacher、monitor日志等）

          c、数据库是否可以正常启动

【在排查连接不上数据库的问题时，首先，必须，一定先查看数据库服务是否启动 (ps -ef|grep dms) ！,如果排查了一大堆多么复杂，高大上的配置参数以后，回头一看只是数据库服务没有启动，溢出屏幕的尴尬...】

案例一：本地数据库disql登陆失败

解决方案：

遇到这个问题可能是修改了数据库端口号，数据库默认端口为5236，只需要指定数据库端口号就可以登陆成功。

案例二：用户被锁定

在用户登录失败一定次数以后，用户会被锁定

解决方案：

--用户解锁
./disql SYSDBA/SYSDBA123
alter user "用户名" account unlock;

附：锁定用户语句

alter user "用户名" account lock;

案例三：应用服务器使用高峰期时，连接不上数据库，高峰期过后，数据库连接正常。

这个问题是数据库最大连接数达到上限，可以在数据库日志中看到相关报错，这种问题在用户使用过程中触发率颇高，所以在部署数据库时需要和应用了解用户并发量。

解决方案：

查询当前最大连接数

select SF_GET_PARA_VALUE(2,'MAX_SESSIONS');

修改最大连接

ALTER SYSTEM SET 'MAX_SESSIONS' =1000 spfile;

重启数据库

案例四：数据库授权key连接数存在限制。

在项目上有遇到过一次，现象就是登录数据库一直卡在登录界面，日志无报错、无达到最大连接数提示等，重启数据库后，SYSDBA登录数据库持续关注连接数变化，发现到25个会话后就不再增加，且新的窗口登录就登不进去了。

0为没有连接数限制。

案例五：服务名配置导致数据库登录失败

有一次给用户同时初始化了三个实例没有进行任何参数配置修改，环境上操作系统、CPU配置等也是完全一致的，但其中一个实例就死活是登录不进去，请看VCR

导致该问题的原因：

dm_svc.conf文件是连接达梦数据库集群需要用到的配置文件，而其中LOGIN_MODE=1参数表示只连接数据库主库，一般配置在局部变量中，这个连接失败问题的原因是该参数配置到了全局变量中，在单机情况下数据库是普通打开模式，而在LOGIN_MODE=1配置在全局变量中连接时会去匹配主库模式，匹配不到就会输出报错“没有匹配的可登录服务器”。

正确规范的配置写法如下：

TIME_ZONE=(480)
LANGUAGE=(cn)
DM=(XX.XX.24.16:5236,XX.XX.24.17:5236)

[DM]
LOGIN_MODE=(1)
SWITCH_TIMES=(3)
SWITCH_INTERVAL=(100)

案例六：用户反馈没有超过目前数据库设置的2000的链接数量，但是经常连接服务器超时，影响部分应用运行，这可能是服务器最大线程数设置不合理导致

默认的open files是1024，一般我们会在 /etc/security/limits.conf文件中加入线程设置参数，指定用户最大线程数，参数如下：
dmdba soft nofile 65536
dmdba hard nofile 65536

但不是修改了这个参数就完事大吉了的，如上图截图所示，从ulimit -a来看，open files已经生效为65536，但从数据库运行进程下看，open files还是1024， 后来修改了/etc/systemd/system.conf文件，将DefaultLimitNOFILE=65536修改后，重启数据库服务，查看服务进程max open files生效了

1. Systemd 中的 /etc/security/limits.conf 文件的配置作用域缩小了，只适用于通过PAM认证登录用户的资源限制，对Systemd的service的资源限制不生效。
2. 登录用户的限制，通过 /etc/security/limits.conf 和 /etc/security/limits.d/*.conf 来配置。
3. 系统全局的配置，在文件 /etc/systemd/system.conf 和/etc/systemd/system.conf.d/*.conf 来设定。

可评论收录...