DBA和開發同事的一些代溝(三)
之前寫了兩篇關於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/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- DBA和開發同事的一些代溝(四)
- DBA和開發同事的一些代溝(五)
- DBA和開發同事的一些代溝(一)
- DBA和開發同事的代溝（二）
- 開發DBA和產品DBA
- 和開發人員“結仇”的10種溝通方式
- DBA常用的一些SQL和檢視SQL
- Flutter開發中的一些Tips（三）Flutter
- DBA常用的一些SQL和檢視（轉）SQL
- 產品經理：你是怎樣和開發gg溝通的？
- WEB開發的需求溝通並不難Web
- 開發中用到的一些第三方
- 來自開發同事推薦的免費好用apiAPI
- 生活和開發所用到的一些工具
- 【DBA】Oracle Database 11g： 面向 DBA 和開發人員的重要特性 資料庫重放OracleDatabase資料庫
- oracle dba 的一些指令碼Oracle指令碼
- ReactJS元件間溝通的一些方法ReactJS元件
- 科技巨頭的裁員潮：AI轉型的代價是同事？AI
- Flutter提升開發效率的一些方法和工具Flutter
- 敏捷開發案例:用白板解決專案管理和團隊溝通敏捷專案管理
- 不經意發現的dba_objects和dba_tables中的細節Object
- 三代開源社群的協作模式模式
- 淺析軟體開發專案的前期溝通工作
- 快速軟體開發專案中的有效溝通（轉）
- DBA參與開發專案的意義
- 三星Note 9手機首次曝光 開發代號“皇冠”
- 知名上市集團公司聘開發DBA及MySQL DBA（杭州）MySql
- 開發和設計溝通有多難？ - 你只差一個設計規範
- DBA 面試題 (三)面試題
- 關於軟體開發的一些常識和思考
- dolphindb dba一些常用的維護sqlSQL
- ［屌絲PM］行業“代溝”（上）——基佬山伯爵行業
- 開發中的一些小事
- 策劃入門（八）開發中的溝通與協調
- 一些開發中比較好用的第三方外掛
- 公司用到的一些 iOS 開源庫和第三方元件iOS元件
- 現代Web開發方法Web
- 解讀微信第三方平臺-代小程式開發