之前写了两篇关于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) 正在疑惑的时候，又收到了开发发来的连接串： 开发同事：   <prop key="URL">jdbc:oracle:thin:@192.168.13.25:1528:test</prop>                 <prop key="user">demand</prop> 通讯平台链接的是这个用户 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的角度来做一些转换。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/23718752/viewspace-1847553/，如需转载，请注明出处，否则将追究法律责任。