中華資料庫與運維大會

① 哪些因素影響了資料庫性能

網路寬頻，磁碟IO，查詢速度都會影響到資料庫的性能。

具體問題具體分析，舉例來說明為什麼磁碟IO成瓶頸資料庫的性能急速下降了。

為什麼當磁碟IO成瓶頸之後, 資料庫的性能不是達到飽和的平衡狀態，而是急劇下降。為什麼資料庫的性能有非常明顯的分界點，原因是什麼？

相信大部分做資料庫運維的朋友，都遇到這種情況。 資料庫在前一天性能表現的相當穩定，資料庫的響應時間也很正常，但就在今天，在業務人員反饋業務流量沒有任何上升的情況下，資料庫的變得不穩定了，有時候一個最簡單的insert操作， 需要幾十秒，但99%的insert卻又可以在幾毫秒完成，這又是為什麼了？

dba此時心中有無限的疑惑，到底是什麼原因呢? 磁碟IO性能變差了？還是業務運維人員反饋的流量壓根就不對？ 還是資料庫內部出問題？昨天不是還好好的嗎？

當資料庫出現響應時間不穩定的時候，我們在操作系統上會看到磁碟的利用率會比較高，如果觀察仔細一點，還可以看到，存在一些讀的IO. 資料庫伺服器如果存在大量的寫IO,性能一般都是正常跟穩定的，但只要存在少量的讀IO,則性能開始出現抖動，存在大量的讀IO時（排除配備非常高速磁碟的機器），對於在線交易的資料庫系統來說，大概性能就雪崩了。為什麼操作系統上看到的磁碟讀IO跟寫IO所帶來的性能差距這么大呢？

如果親之前沒有注意到上述的現象，親對上述的結論也是懷疑。但請看下面的分解。

在寫這個文章之前，作者閱讀了大量跟的IO相關的代碼，如非同步IO線程的相關的，innodb_buffer池相關的，以及跟讀數據塊最相關的核心函數buf_page_get_gen函數以及其調用的相關子函數。為了將文章寫得通俗點，看起來不那麼累，因此不再一行一行的將代碼解析寫出來。

咱們先來提問題。buf_page_get_gen函數的作用是從Buffer bool裡面讀數據頁，可能存在以下幾種情況。

提問. 數據頁不在buffer bool 裡面該怎麼辦？

回答：去讀文件，將文件中的數據頁載入到buffer pool裡面。下面是函數buffer_read_page的函數，作用是將物理數據頁載入到buffer pool, 圖片中顯示

buffer_read_page函數棧的頂層是pread64(),調用了操作系統的讀函數。

通過解析buf_wait_for_read函數的下層函數，我們知道其實通過首先自旋加鎖pin的方式，超過設定的自旋次數之後，進入等待，等待IO完成被喚醒。這樣節省不停自旋pin時消耗的cpu,但需要付出被喚起時的開銷。

再繼續擴展問題： 如果會話線程A 經過物理IO將數據頁1001讀入buffer之後，他需要修改這個頁，而在會話線程A之後的其他的同樣需要訪問數據頁1001的會話線程，即使在數據頁1001被入讀buffer pool之後，將仍然處於等待中。因為在數據頁上讀取或者更新的時候，同樣需要上鎖，這樣才能保證數據頁並發讀取/更新的一致性。

由此可見，當一個高並發的系統，出現了熱點數據頁需要從磁碟上載入到buffer pool中時，造成的延遲，是難以想像的。因此排在等待熱點頁隊列最後的會話線程最後才得到需要的頁，響應時間也就越長，這就是造成了一個簡單的sql需要執行幾十秒的原因。

再回頭來看上面的問題，mysql資料庫出現性能下降時，可以看到操作系統有讀IO。 原因是，在資料庫對數據頁的更改，是在內存中的，然後通過檢查點線程進行非同步寫盤，這個非同步的寫操作是不堵塞執行sql的會話線程的。所以，即使看到操作系統上有大量的寫IO，資料庫的性能也是很平穩的。但當用戶線程需要查找的數據頁不在buffer pool中時，則會從磁碟上讀取，在一個熱點數據頁不是非常多的情況下，我們設置足夠大的innodb_buffer_pool的size, 基本可以緩存所有的數據頁，因此一般都不會出現缺頁的情況，也就是在操作系統上基本看不到讀的IO。 當出現讀的IO時，原因時在執行buf_read_page_low函數，從磁碟上讀取數據頁到buffer pool, 則資料庫的性能則開始下降，當出現大量的讀IO，資料庫的性能會非常差。

② 資料庫維護的工作的主要內容是什麼

資料庫日常維護工作是系統管理員的重要職責。其內容主要包括以下幾個部分：
一、備份系統數據
SYBASE 系統的備份與恢復機制保證了在系統失敗時重新獲取數據的可能性。SQL Server 提供了兩種不同類型的恢復機制：一類是系統自動完成的恢復，這種措施在每次系統啟動時都自動進行，保證了在系統癱瘓前完成的事務都寫到資料庫設備上，而未完成的事務都被回退；另一類是人工完成的恢復，這是通過 DUMP 和 LOAD 命令來執行人工備份和恢復工作。因此定期備份事務日誌和資料庫是一項十分重要的日常維護工作。
1、備份資料庫
每一個資料庫都應在創建之後卸出，從而提供一個裝入基點。在此之後按排定的時間周期表卸出。比如每周五卸出資料庫。對一般資料庫系統卸出資料庫周期建議為每周一次。
除了按計劃周期卸出資料庫之外，還需在每次運行沒有日誌的操作後卸出資料庫。例如：
·每次強制地運行了 DUMP TRAN WITH NO_LOG （因為資料庫的磁碟空溢出）；
·每次用 sp_dboption 允許 select into/bulk 做快速拷貝，或用 SELECT INTO 命令創建一個永久性的表，或使用了 WRITETEXT 命令。
卸出資料庫的命令為：
DUMP DATABASE database_name
TO mp_device
database_name 是要卸出的資料庫名稱，mp_device 是卸出設備的名稱。用系統過程 sp_helpdevice 可以獲得設備的信息。
下面一條命令用來卸出資料庫 my_db ：
DUMP DATABASE my_db
TO db_bk_dev
2、備份事務日誌
如果事務日誌與資料庫放在同一個設備上，則事務日誌不應與資料庫分開備份。master 資料庫和小於 4M 的用戶資料庫就是這種情況。一般資料庫系統的資料庫和日誌分別放在不同的設備上，因此，可以用 DUMP TRAN 命令單獨備份日誌。
備份事務日誌的周期直接影響數據的恢復程度，因此建議每天備份。
備份事務日誌的命令格式為：
DUMP TRANsaction database_name
[TO mp_device]
[WITH TRUNCATE_ONLYWITH NO_LOGWITH NO_TRUNCATE]
其中 database_name 是要備份事務的資料庫名稱，mp_device 是備份設備名稱，僅當包含了 WITH TRUNCATE_ONLY 或 WITH NO_LOG 子句時，才可以備份到設備。
注意：如果總是用 DUMP DATEBASE （備份資料庫及其日誌），而不用 DUMP TRAN ，事務日誌將不會刷新，而變得非常龐大。
對於 master 資料庫和小型資料庫每次運行 DUMP DATEBASE 之後應當運行 DUMP TRANsaction 命令刷新日誌 。
下面一條命令備份資料庫 db160 的事務日誌到備份設備上：
DUMP TRANsaction db160
TO db_log_bk_dev
WITH TRUNCATE_ONLY
3、備份資料庫及其日誌間的相互作用
在至少卸出一次資料庫前，卸出事務日誌是毫無意義的。下圖顯示了備份資料庫及其日誌間的關系
如果在星期二下午5：01出現非硬體故障，需要做的所有工作是裝入磁帶5（參見下一節：數據恢復），由於磁帶5是下午5：00剛備份的，因此只有備份和裝入之間的一分鍾內的數據損失。
但是，如果在星期二下午4：49失效會怎麼樣呢？在這種情況下，要裝入磁帶1（在星期五下午5：00的卸出）。然後，依次裝入磁帶2，3以及4。這樣，系統將恢復到星期二上午10：00點的狀態，星期二的大部分工作丟失了。此例顯示了經常卸出事務的重要性。
二、萬一系統失敗時恢復資料庫系統
如果用戶資料庫存儲的設備失效，從而資料庫被破壞或不可存取，通過裝入最新的資料庫備份以及後來的事務日誌備份可以恢復資料庫。假設當前的事務日誌存在於一個並沒有毀壞的設備上，帶著 WITH NO_TRUNCATE 選項的 DUMP TRANsaction 命令卸出它。
要恢復資料庫按如下步驟去做：
1、如果日誌存在於一個分離的設備上，用帶著 NO_TRUNCATE 選項的 DUMP TRANsaction 命令卸出被毀壞的或者不可存取的用戶資料庫事務日誌。
2、用下面的查詢檢查設備分配已毀壞資料庫的設備使用情況。必須為同一目的賦同樣的空間塊。
下面的查詢顯示了分配給資料庫 mydb 設備使用和尺寸情況：
SELECT segmap，size FROMsysusages
WHERE dbid =
（ SELECT dbid FROM sysdatabases WHERE name = 「mydb」）
3、檢查查詢的輸出。在 segmap 列的 『3』代表數據分配，『4』代表日誌分配。size 列代表 2K 數據塊的數目。注意此信息的次序、使用和尺寸部分。例如，輸出為：
segmapSize
--------------------
310240//實際尺寸為：20M
35120//實際尺寸為：10M
45120//實際尺寸為：10M
31024//實際尺寸為：2M
42048//實際尺寸為：4M
4、用 DROP DATABASE 命令刪除毀壞設備上的資料庫。如果系統報錯，用DBCC DBREPAIR 命令的 DROPDB 選項。
5、刪除資料庫後，用 sp_dropdevice 刪除毀壞了的設備。
6、用 DISK INIT 初始化新的資料庫設備。
7、重建資料庫。用 CREATE DATABASE 命令從老的 sysusages 表拷貝所有的行，並包含第一邏輯設備。
對上例，命令為：
CREATE DATABASE mydb
ON datadev1=20，datadev2=10
LOG ON logdev1=10
8、用 ALTER DATABASE 命令重建其餘入口。在此例中，在datadev1上分配更多的空間，命令為：
ALTER DATABASE mydb ON datadev1=2
9、用 LOAD DATABASE 重新裝入資料庫，然後用 LOAD TRAN 裝入前面卸出的日誌。
LOAD DATABASE 命令語法是：
LOAD DATABASE database_name
FROM mp_device
LOAD TRANsaction 命令的語法是：
LOAD TRANsaction database_name
FROM mp_device
卸出資料庫和事務日誌的預設許可權歸資料庫所有者，且可以傳遞給其他用戶；裝載資料庫和事務的許可權也歸資料庫所有者，但不能傳遞。
二、產生用戶信息表，並為信息表授權；
系統維護人員的另一個日常事務是為用戶創建新的信息表，並為之授權。創建表以及為表授權的方法已經在講過，在此只將有關命令語法寫出來。
·創建表的命令為：
CREATE TABLE table_name
（ column_1 datatype [NULL NOT NULL IDENTITY]，
column_2 ……
）
go
ALTER TABLE table_name
ADD PRIMARY KEY （column_list）
go
·刪除表的命令格式為：
DROP TABLE table_name
go
·為表授權的命令格式為：
GRANT {ALLpermission_list}
ON table_name TO user_name
go
·收回許可權的命令格式為
REVOKE {ALLpermission_list}
ON table_name FROM user_name
go
三、監視系統運行狀況，及時處理系統錯誤；
系統管理員的另一項日常工作是監視系統運行情況。主要有以下幾個方面：
1、監視當前用戶以及進程的信息
使用系統過程：sp_who
說明：該命令顯示當前系統所有注冊用戶及進程信息，如下表是某系統的信息。

---------------------------------------------------------------

2SleepingNULL0MasterNETWORK HANDLE
3SleepingNULL0MasterDEADLOCK TUNE
4SleepingNULL0MasterMIRROR HANDLER

SLEEP
從左向右依次顯示：進程號、當前狀態、注冊用戶名、主機名、佔用塊數、資料庫名以及當前命令。
如果監視時發現進程總數接近最大連接數（用系統過程：sp_configure 「user conn」 查看）時，應下掉不活動或無關進程，以保證系統正常運做；另外亦可監視非法用戶或用戶使用不屬於自己使用范圍的資料庫等情況。
2、監視目標佔用空間情況
使用系統過程：sp_spaceused
說明：該過程顯示行數、數據頁數以及當前資料庫中由某個目標或所有目標所佔用的空間。如下表是某資料庫日誌表的信息：
NameRow_totalreserveddataIndex_sizeunused
------------------------------------------------------------
SyslogsNot avail32KB32KB0KBNot avail
日常要監視的主要目標有：用戶資料庫、資料庫日誌表（syslogs）以及計費原始數據表等。如果發現佔用空間過大，對日誌表要進行轉儲；對其他目標則應擴充空間或清楚垃圾數據。
3、監視 SQL Server 統計數字
使用系統過程：sp_monitor
說明：sp_monitor 顯示SQL Server 的歷史統計數字，下表是某系統的統計數字：
Last_runCurrent_runSeconds
---------------------------------------------------------------
May 13 2000 1:27PMMay 13 2000 3:01PM5678
CPU_busyIO_busyIdle
---------------------------------------------------------------
16(6)-0%0(0)-0%5727(5672)-99%
Packets_receivedPackets_sentPacket_errors
---------------------------------------------------------------
21(17)100(97)0(0)
Total_readTotal_writeTotal_errorsConnections
--------------------------------------------------------
785(366)311(113)0(0)3(2)
上表依次給出該系統本次運行統計的上一次時間、本次時間、間隔秒數、CPU佔用、IO佔用、收發包情況、系統讀入寫出情況等信息
四、保證系統數據安全，周期更改用戶口令；
為保證系統數據的安全，系統管理員必須依據系統的實際情況，執行一系列的安全保障措施。其中，周期性的更改用戶口令是比較常用且十分有效的措施。
更改用戶口令是通過調用系統過程sp_password 來實現的。Sp_password 的語法為：
sp_password caller_password,new_password [,loginame]
其中caller_password 是登錄口令（老口令），new_password是新口令，loginame是登錄名稱。

③ 正在做it運維，linux和資料庫方面的有什麼好建議

linux系統如果是學習可以選用redhat或centos，特別是centos在企業中用得最多，當然還會有其它版本的，但學習者還是以這2個版本學習就行，因為這兩個版本都是兄弟，沒區別的，有空可以再研究一下SUSE，有些公司也喜歡用，例如我公司 。。。。。

工具如下：

1、linux系統基礎，這個不用說了，是基礎中的基礎，連這個都不會就別幹了，參考書籍，可以看鳥哥linux基礎篇，至少要掌握這書60%內容，沒必須全部掌握，但基本命令總得會吧

2、網路服務，服務有很多種，每間公司都會用到不同的，但基礎的服務肯定要掌握，如FTP, DNS,SAMBA, 郵件, 這幾個大概學一下就行，LAMP和LNMP是必須要熟練，我所指的不是光光會搭建，而是要很熟悉裡面的相當配置才行，因為公司最關鍵的絕對是WEB伺服器，所以nginx和apache要熟悉，特別是nginx一定要很熟悉才行，至少有些公司還會用tomcat，這個也最好學一下。其實網路服務方面不用太擔心，一般公司的環境都已經搭建好，就算有新伺服器或讓你整改，公司會有相應的文檔讓你參照來弄，不會讓你亂來的，但至少相關的配置一定要學熟，而且肯定是編譯安裝多，那些模塊要熟悉一下他的作用，特別是php那些模塊。
這面2點只是基礎，也是必要條件，不能說是工具，下以才是真正的要掌握的工具。

3、shell腳本和另一個腳本語言，shell是運維人員必須具備的，不懂這個連入職都不行，至少也要寫出一些系統管理腳本，最簡單也得寫個監控CPU，內存比率的腳本吧，這是最最最基本了，別以為會寫那些猜數字和計算什麼數的，這些沒什麼作用，只作學習意義，寫系統腳本才是最有意義，而另一個腳本語言是可選的，一般是3P，即python, perl和php，php就不需要考慮了，除非你要做開發，我個人建議學python會比較好，難實現自動化運維，perl是文本處理很強大，反正這兩個學一個就行了。

4、sed和awk工具，必須要掌握，在掌握這兩個工具同時，還要掌握正則表達式，這個就痛苦了，正則是最難學的表達式，但結合到sed和awk中會很強大，在處理文本內容和過濾WEB內容時十分有用，不過在學shell的同時一般會經常結合用到的，所以學第3點就會順便學第4點。

5、文本處理命令，sort , tr , cut, paste, uniq, tee等，必學，也是結合第3點時一並學習的。

6、資料庫，首選mysql，別問我為什麼不學sqlserver和oracle，因為linux用得最多絕對是mysql，增刪改查必學，特別要學熟查，其它方面可能不太需要，因為運維人員使用最多還是查，哪些優化和開發語句不會讓你弄的。

7、防火牆，不學不行，防火牆也算是個難點，說難不難，說易不易，最重要弄懂規則，如果學過CCNA的朋友可能會比較好學，因為iptables也有NAT表，原理是一樣的，而FILTER表用得最多，反正不學就肯定不合格。

8、監控工具，十分十分重要，我個人建議，最好學這3個，cacti，nagios，zibbix，企業用得最多應該是nagios和 zibbix，反正都學吧，但nagios會有點難，因為會涉及到用腳本寫自動監控，那個地方很難。

9、集群和熱備，這個很重要，肯定要懂的，但到了公司就不會讓你去弄，因為新手基本不讓你碰，集群工具有很多，最好學是LVS，這是必學，最好也學學nginx集群，反向代理，還有熱備，這個就更多工具能實現了，像我公司是自己開發熱備工具的，mysql熱備也要學，就是主從復制，這個別告訴我容易，其實不容易的，要學懂整個流程一點也不容易，只照著做根本沒意思。

10、數據備份，不學不行，工具有很多，但至少要把RAID的原理弄懂，特別是企業最常用的1+0或0+1，自己做實驗也要弄出來，備份工具有很多，如tar, mp, rsync等，最好多了解一下。
算了，說到這10點已經夠你受了，應該可以入門了，因為有些技術會比較難學，例如apache和nginx中還有些很重要的技術，如系統調優和服務優化，還有程序優化，這些在沒接觸工作前很難學習到的，所以先把這10點學了吧，估計要學熟至少3個月不止，就腳本那部分已經讓你很吃力了，我建議是先學熟shell，等工作後再學另一門腳本語言，這樣會比較好。

以上就是踏入linux運維工程師需要掌握的工具，其實還有很多工具要掌握的，但你在學習環境中是很難學到，最後我再提醒一下，這里所指的工具相當於技能，而不是像windows或ubuntu那些圖形化工具，那些工具沒用的，還有，學linux就別裝圖形界面，這樣虛擬機就不用吃太多內存，而且絕對不建議在真機上裝linux，根本達不到學習效果。

更多相關內容可參考資料http://www.viiboo.cn

④ linux運維VS資料庫管理員

未來5年裡面從社會需要上來看運維工程師肯定是比資料庫管理員的需求大~
其實嘛我感覺這兩個職業沒有絕對的好和壞只有最適合自己的~關鍵是興趣。另外，看你的描述感覺是還在讀書（更像是在某個培訓機構學習），如果面試的時候問你對運維或者是dba職業的看法「如果你來一句」如果沒事 你就萬事大吉「 你就可以自求多福了。不管是linux還是dba都是屬於運維的，而運維本來就是一個沒事找事的工作，維護其穩定性只不過是運維裡面一個最最基礎的工作，試想一下一個系統連三天兩頭宕一次的誰受得了？切記穩定是運費最最基礎的工作，不斷的優化才是運維的首要工作，不管是在集市上的優化比如腳本化日常工作或者是在流程上的優化比如減少不必要無效的溝通 優化及同應用的溝通才是運費的核心工作~
主機裡面的lamp或者lnmp那些我只是之前學過但是沒有那個方面的工作經驗~不太好說 就那oracle的事情來說吧，一個甚至是N個的數據擺在你面前你要管理你需要了解的東西絕對不僅僅是磁碟管理這么一點點的東西，資料庫是一個應用的核心，從大的方面來說有應用你要清楚，技術上的話要懂開發（JAVA，PLSQL），shell這個必須的，存儲知識（比如raid，LV劃分、鏡像配置，IO優化）網路知識（這個了解下就差不多了NA足以），技術上就不扯了，總之oracle比系統難度大多了~
小公司和大公司的區別：要看你小到什麼程度和大到什麼程度了，太小的公司別去，小公司就意味著公司業務面窄，那麼高端點的東西你肯定接觸不到，也許你管理的系統就是一個windows的PC機，這些在技術上的影響到時其次，關鍵是影響眼界。大公司嘛，流程性太強，有的像機器人的感覺，但是相對來說畢竟專業，資料庫的就是資料庫，系統的就是系統網路的就是網路。公司怎樣還有的就是看他的業務了~！

⑤ 運維方面的工作好一些還是資料庫方面的工作好一些

這個其實要看個人機遇的，成功=70%運氣+30%努力.....不要問別人做哪方面好，要自己想好，覺得自己做哪個會更快上手..更喜歡哪個方面的工作，經驗的確是一方面，但是最重要的還是一個態度問題，不是么？好好努力吧,,,,,加油！

⑥ 資料庫運維的工作，主要是做什麼的

1、資料庫的配置、維護
2、伺服器的配置與維護
3、應用軟體的運行與維護
4、功能的擴展

⑦ 影響資料庫性能的因素

影響資料庫性能的因素
對於資料庫愛好者們，資料庫底層的各種細節，內幕，等待事件，隱藏參數等津津樂道，對於調整好一條SQL語句使之在查詢優化器/查詢引擎下能高性能運轉具有巨大的滿足感成功感，彷彿自己掌握了天下最有價值的真理，駕馭了天下最有難度的技術。但對於設計和開發出這個資料庫系統的人來說，他們看到此情此景，只好躲在一邊偷偷的笑了。那麼問題來了，使用別人資料庫的人被稱為大師（如：OCM），那麼自己寫出一個資料庫來的人又該稱為什麼呢？到底誰才是真正的高手呢？
資料庫系統優化中的一些觀點：
「系統性能出現問題進行優化，一定要深入了解資料庫內部參數、等待事件、Latch、緩沖池、trace文件、查詢/優化引擎等底層細節。」
這種觀點往往出自資料庫「高手」，這部分人以了解資料庫底層實現細節而感到非常驕傲。但是從優化角度講資料庫的等待事件、Latch等指標高等等都只是問題的表象，懂得底層細節和內幕固然是好。但是解決問題的關鍵往往是在應用層進行優化。
「只要系統參數調整了，性能就能提高。系統優化應該調整那些參數…」
這種觀點往往出自於一些偏運維和應用層的DBA，迷戀參數配置來調優。
調整系統參數是非常重要的，但不一定能解決性能問題，否則就不會有去IOE了，問題可能性最大的還是應用設計和開發問題。
同理，很多運維人員和系統架構師比較迷戀「Linux系統調優」。認為對「文件句柄數、磁碟子系統…」那些做了優化，就能提升整個應用系統的性能。其實不然。有些場景下，針對業務特點和應用類型做操作系統調優是能取到立竿見影的效果，但是大多數時候往往提升並不明顯。所以最關鍵的還是找出瓶頸所在，對症下葯。*/
「系統性能問題需要從架構上解決，與應用開發關系不大。」
系統性能與各個層面都有關，架構很重要，但應用開發也是非常重要的一環。
影響資料庫性能的因素
1.業務需求和技術選型
2.應用系統的開發及架構
3.資料庫自身
3.1表結構的設計
3.2查詢語句
3.3索引設計
3.4Mysql服務（安裝、配置等）
3.5操作系統調優
3.6硬體升級（SSD、更強的CPU、更大的內存）
4.數據架構（讀寫分離、分庫分表等）
在很多情況下，資料庫可能是互聯網應用系統的瓶頸。但是單純從資料庫角度去做優化，可能未必能達到理想的效果。
說點題外話，最近看到很多公司使用中間件或者分布式數據訪問層來做資料庫分片，說明也許該公司業務發展很快。但另一個方面，也令人擔憂，他們的資料庫壓力真的已經到了必須切分不可的程度了嗎？分庫分表真的像科普的那麼簡單嗎？他們能搞定分庫分表帶來的成本和問題嗎？有沒有更合適的優化方法呢？
當然是有的。其實「過度設計」和「提前優化」就是系統萬惡之源。

⑧ 什麼樣的公司要資料庫運維

數據量大，想在大量數據中挖掘到商機的公司，一般的小公司一般用的不是很多。
用的多的有互聯網服務公司，接下去就是銀行了，再接下去證券類公司，再接下去就是連鎖的零售業，其實現在公司越來越看重數據在公司決策中的作用，自然就對資料庫就有要求了，自然就有資料庫的運維了。很多中小公司也想做，它們一般選擇外包，這樣省事方便，還有就是費用會比自己做少太多了。
來源：360oracle運維。。。。，，，提供。。oracle。。運維。。。外、、、、包、、、、、、

⑨ 資料庫工程師的職業發展

資料庫作為整個系統的一部分，它的表現直接受伺服器、操作系統、存儲、網路、應用程序中SQL語句的質量、資料庫設計的質量、以及其它諸多因素的影響，這些因素加在一起非常復雜，經驗起著非常重要的作用。因此一個好的資料庫工程師除了知識作為基礎，經驗的多寡、見識的薄廣，往往決定了是否合格與優秀。
優秀的資料庫工程師不僅關心自己運維的資料庫系統的原理和發展，而且緊跟業界資料庫前沿技術，並關注資料庫領域的頂級會議。其中包括國際著名的資料庫三大會議SIGMOD、VLDB、ICDE，還有知名資料庫公司Percona主辦的Percona Live和Oracle主辦的Open World，以及國內知名的資料庫工程師盛會中國資料庫技術大會(DTCC)等。
從另外一個角度說，資料庫工程師工作領域對實踐經驗和獨立工作能力要求較高，沒有經過大量的動手實踐是很難勝任資料庫工程師相關工作的 。
正是由於上述原因，其職場現狀是資料庫工程師職位不易進入，而用人單位很難找到合適的從業人員，人員缺口非常大。
也正是由於上述原因，隨著工作年限的增長，資料庫工程師的經驗在增加，就像醫生一樣，其價值會越來越高，可以逐步成長為資深資料庫工程師、系統架構師、信息主管（CIO）等等，而不會出現許多軟體開發從業人員在一定年齡後面臨的轉行問題。
另外，從職業前景看，從事資料庫工程師有著更多的職場機遇 。一般而言，系統中的軟硬體都是IBM、HP、Oracle等業界一流廠商提供的，在與廠商談判、合作、測試、實施、維護、優化等等過程中，會產生許多極佳的職場機遇，這一點是從事開發工作很難比擬的。
從資料庫工程師的工資統計數據看，隨著工作經驗的積累，資料庫工程師工資的增長幅度會遠大於其它的計算機方向。
從工作的穩定性上看，系統的復雜性和經驗的重要性已經決定了資料庫工程師職位的不可替代性。
從知識的積累、更新和替代角度看，資料庫的根基始終沒變，變的是不斷增強的功能和不斷擴展的應用范圍。因此，在不同時期所學的知識和獲得的經驗是疊加和累積的關系，而不像IT許多其他職業方向那樣「唯一不變的是變化」，其知識是東風壓倒西風還是西風壓倒東風的關系。
因此， 資料庫工程師職業是一個高挑戰和高回報的職業，有一定能力的和聰明的技術人員應該挑戰自我，進入這個被二十多年事實不斷證明的越來越有前景的職業 。