DBA和開發同事的一些代溝(三)

jeanron100發表於2015-11-26
之前寫了兩篇關於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/,如需轉載,請註明出處,否則將追究法律責任。

相關文章