之前写了两篇关于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的角度来做一些转换。
关于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的角度来做一些转换。
