中华数据库与运维大会

① 哪些因素影响了数据库性能

网络宽带，磁盘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许多其他职业方向那样“唯一不变的是变化”，其知识是东风压倒西风还是西风压倒东风的关系。
因此， 数据库工程师职业是一个高挑战和高回报的职业，有一定能力的和聪明的技术人员应该挑战自我，进入这个被二十多年事实不断证明的越来越有前景的职业 。