之前写了两篇关于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的角度来做一些转换。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/23718752/viewspace-1847553/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/23718752/viewspace-1847553/