DBA和开发同事的一些代沟(三)(r7笔记第29天)

时间:2022-05-04
本文章向大家介绍DBA和开发同事的一些代沟(三)(r7笔记第29天)，主要内容包括其使用实例、应用技巧、基本知识点总结和需要注意事项，具有一定的参考价值，需要的朋友可以参考一下。

之前写了两篇关于DBA和开发同事的一些代沟，产生了一些共鸣，本身写这个的目的就是能够让DBA也试着从开发的角度来理解问题，开发同学也能够多学习一些DB的知识，DB不是一个黑盒，不清楚不了解很容易出现问题。

关于DBA和开发同事的一些代沟，今天想到一个鲜活的例子，也是真实碰到的一个例子，和代价简单聊一聊。欢迎补充你们的意见。

早上突然聊天器弹出一个窗口来，开发同事开始问我了。

开发同事 11:18

亲

192.168.13.25:1528:test

这数据库是您负责吗？

亲，现在这个数据库我们程序链接的时候报 异常了

是不是这个数据库的连接数超了还是数据库down了？

DBA --->这个时候我的心里咯噔一下，难道数据库宕机了，oracle,还是mysql,oracle宕机我肯定受到报警的啊。是不是MySQL监控延迟或者是什么网络的问题？

带着疑问火速连接到这台服务器，印象中是有一个MySQL数据库在上面。

> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| test               |
| activity_log     |
+--------------------+
5 rows in set (0.00 sec)

可以看到没有问题啊，看看连接的情况。

> show processlist;
+----------+------------+--------------------+--------------+---------+------+-------+------------------+-----------+---------------+-----------+
| Id       | User       | Host               | db           | Command |  Time | State | Info             | Rows_sent | Rows_examined | Rows_read |
+----------+------------+--------------------+--------------+---------+------+-------+------------------+-----------+---------------+-----------+
| 23851798 | app_testlog | test_log_3.66:55109 | activity_log | Sleep    |   21 |       | NULL             |         1 |             0 |        198 |
| 23851799 | app_testlog | test_log_3.66:55110 | activity_log | Sleep    |   21 |       | NULL             |         1 |             0 |        198 |
..
| 23851883 | root       | localhost          | NULL         | Query    |    0 | NULL  | show processlist |         0 |             0 |         9  |
+----------+------------+--------------------+--------------+---------+------+-------+------------------+-----------+---------------+-----------+
13 rows in set (0.00 sec)

DBA 11:21

没问题啊。

不要吓dba

连接数就13个

开发同事 11:21

给加点连接数吧亲？

DBA:

我想难道是连接数不够了，才13个连接数怎么可能不够呢，带着疑惑查看了连接数。明明可以支持160个的。

> show variables like '%conn%';
+--------------------------+-----------------+
| Variable_name            | Value           |
+--------------------------+-----------------+
| character_set_connection | utf8            |
| collation_connection     | utf8_general_ci |
| connect_timeout          | 10              |
| init_connect             |                 |
| max_connect_errors       | 100000          |
| max_connections          | 160             |
| max_user_connections     | 0               |
+--------------------------+-----------------+
7 rows in set (0.00 sec)

正在疑惑的时候，又收到了开发发来的连接串：

开发同事：

  jdbc:oracle:thin:@192.168.13.25:1528:test
                demand

通讯平台链接的是这个用户

DBA:

我顿时感觉白忙活了一场，原来是个Oracle,真后悔最开始没问清。

看看这台服务器上的数据库实例情况，原来有两个数据库实例，其中一个就是test

# ps -ef|grep smon
oracle   10660     1  0  2013 ?        00:36:19 ora_smon_acctestdb
oracle   14467     1  0  2013 ?        00:46:18 ora_smon_test
root     15871 15021  0 11:26 pts/0    00:00:00 grep smon

开发同事：

帮忙增加连接数哈

我下工单

DBA:

好吧，都已经主动下工单了，我还能怎么拒绝呢。

首先开发同事反馈说，连接不上，最后得知是一个Oracle数据库连接不上，如果出现这种情况，一种情况就是本身数据库实例的连接数不够，另外一种情况就 是profile设置的sessions_per_user，即每个用户能够允许的最大session数。可以看到这个用户使用的本身就是DEFAULT 的profile

SQL> select username,profile from dba_users where username='DEMAND';
USERNAME                       PROFILE
------------------------------ ------------------------------
DEMAND                         DEFAULT

难道profile发生了改变,专门做了定制？

SQL> select *from dba_profiles where profile='DEFAULT';
PROFILE                        RESOURCE_NAME                    RESOURCE LIMIT
------------------------------ -------------------------------- -------- ----------------------------------------
DEFAULT                        COMPOSITE_LIMIT                  KERNEL   UNLIMITED
DEFAULT                        SESSIONS_PER_USER                KERNEL   UNLIMITED
DEFAULT                        CPU_PER_SESSION                  KERNEL   UNLIMITED
DEFAULT                        CPU_PER_CALL                     KERNEL   UNLIMITED
DEFAULT                        LOGICAL_READS_PER_SESSION        KERNEL   UNLIMITED
DEFAULT                        LOGICAL_READS_PER_CALL           KERNEL   UNLIMITED
DEFAULT                        IDLE_TIME                        KERNEL   UNLIMITED
DEFAULT                        CONNECT_TIME                     KERNEL   UNLIMITED
DEFAULT                        PRIVATE_SGA                      KERNEL   UNLIMITED
DEFAULT                        FAILED_LOGIN_ATTEMPTS            PASSWORD 10
DEFAULT                        PASSWORD_LIFE_TIME               PASSWORD UNLIMITED
DEFAULT                        PASSWORD_REUSE_TIME              PASSWORD UNLIMITED
DEFAULT                        PASSWORD_REUSE_MAX               PASSWORD UNLIMITED
DEFAULT                        PASSWORD_VERIFY_FUNCTION         PASSWORD NULL
DEFAULT                        PASSWORD_LOCK_TIME               PASSWORD UNLIMITED
DEFAULT                        PASSWORD_GRACE_TIME              PASSWORD UNLIMITED
16 rows selected.

可以看到都是默认的值，那么开发同事反应连接不了，到底是什么原因呢？

开发同事 11:29

亲，加了吗？

DBA 11:30

我给你电话吧？

然后带着疑问向开发同学了解问题的原因。

。。。。

最后他们说通过某个服务器连接数据库连接失败。那么这个服务器的IP我得知道，看看防火墙是否有限制，

结果一查看，马上发现是这个问题导致的。原来问题描述和问题本身相差这么远。

# iptables -nvL|grep 136.20

DBA:

开通防火墙中。。。。

开发同事 11:38

亲，工单哈

27741 未开始 申请开通xxxxxx的权限

多谢了

开通了喊我哈

那边用户着急使用嘿嘿

多谢多谢

DBA 11:39

已经开通了

开发同事 11:39

好哒

然后过了一会，我觉得还是得问问。

DBA 11:39

可以了吗？

开发同事 11:40

我正在联系运维试一试哈

开发同事 11:42

麻烦给这两台也开一下

192.168.8.224 192.168.140.224

还是开通刚才那两个库的

刚才那个数据库IP

DBA:

带着无奈开始帮同事开通防火墙，还好我有一套自己的脚本，可以做一些自动化的工作，结果一检查，防火墙已经开通了。

服务器1：

1 ip address is founded from firewall list

nothing to do

服务器2：

1 ip address is founded from firewall list

nothing to do

DBA 11:47

开通了的

开发同事 11:48

恩行

然后又过了一会，我觉还是得问明白。

DBA 11:51

可以了吧？

开发同事 11:54

恩

感谢亲

这是一个真实的案例，我改动了几个错别字，碰到这个案例也是让人无可奈何，我的小心脏已经被刺痛了，最开始以为是故障，心里各种内心翻腾，最后发现不是那么回事，那么开发同事 的问题原因在哪儿呢，最后一番了解才发现原来是某一台服务器访问失败，对于原因自己也分析了几个场景，最后发现还是很常规的问题，是防火墙的网络权限问 题。那么这个小案例也是一波三折，可见DBA和开发同事之间还是存在某些代沟，可能对于DBA来说还是需要冷静，要了解目标环境，了解清楚之后才能有针对 性的分析和检查。对于开发同学的问题，需要做一些转换，可能有一些表述还是会有一些差别。需要从DBA的角度来做一些转换。

随机文章
本站知识点必读
最近更新