如何解析Oracle 18c对于DBA的影响及应对措施

这篇文章将为大家详细讲解有关如何解析Oracle 18c对于DBA的影响及应对措施，文章内容质量较高，因此小编分享给大家做个参考，希望大家阅读完这篇文章后对相关知识有一定的了解。

很显然不是，无论你是否相信，我要肯定地告诉你，上云之后，DBA在企业将会扮演更重要的角色。

我已经从事了17+年的DBA职业，对于这方面有比较深刻的体会和理解。很多朋友担心以后是否会失业，我们首先来看这个行业有哪些发展趋势：

1、会出现更多精细和高级的特性，每一个新的版本都是这样的。

2、在数据库中，越来越多的任务能够被系统自动完成，因此无论对于企业还是个人来说，尽快地升级到新版本是非常有好处的，而不要等到被迫升级

3、未来在云上，对于DBA的要求将会更高。

因此在本文中，我将会谈一谈Oracle自治数据库的推出对于DBA的影响，同时跟大家一起探讨DBA该如何应对新的趋势。

Oracle数据库18c是下一代业界领先的数据库。

Oracle在今年的OOW上引入了世界上第一款的自治数据库，其对应的云平台和服务以最低的成本实现了更高的性能、安全和可靠性的需求，并且降低了操作的复杂度，减少了人为误操作的几率，大部分的工作能够自主地完成，减少了手动操作的工作量。

在这里我要强调一下 ”Database Cloud“ 和”Oracle 自治数据库云“，因为当我们谈到云上的数据库， Oracle的自治数据库云事实上是一种云端数据库 的服务。 在这篇文章中，我们会将它称为”云端数据库“

自治数据库、云端数据库，这个话题其实可以从不同的角度进行分析，我看到的大部分的文章中，都在讲述这一款未来的数据库有多少的优势和好处。那么我们应该重点考虑哪些方面的问题呢？

1、谁来决定数据库将处于哪个服务模式下？

2、谁将为这些资质数据库植入政策约束？

3、 对于数据库的常规任务和行为，谁有足够的认知来决定如何减少这些服务的成本？

4、当我们有更多的选择的时候，IT的基础架构将会变得越来越复杂，谁来决定这些系统的设计？

很显然，这些问题的答案都是DBA，然而，不是任何一个普通的DBA都能完成。为了完成这些任务，DBA必须对这一款未来的云上数据库有深入全面的了解。

正如我刚才所说，自治数据库事实上就是一种不同的云端数据库服务。因此，首先要了解的内容就是如何将数据库从本地迁移到云端。关于数据库的云端迁移，请参考： Oracle Cloud (DBaaS): Migrating Databases to Oracle Cloud Using RMAN Backup

Oracle自主数据库是一种具有许多已经自动化的常规任务的数据库，这些可自动化完成的任务如下：

1、补丁的应用

2、升级

3、系统的自主优化

但是，这篇文章的重点还没有开始：

首先我引入我一个ACED朋友 Tim Hall的原话，他说，18c的预售对于DBA几乎是没有影响的，只有自治数据库的服务套件整体推出的时候才会对DBA产生比较大的影响。

对于这句话要怎么理解呢？

首先，对于前半句，Oracle18c对于DBA是没有影响的，它只不过是一个更高的版本罢了。它并不是一个运行在自治模式下的普通意义的关系型数据库的管理软件，事实上，自治数据库本身就是被设计用于今后的环境和需求的，它只是针对云上的，跟本地的数据库并不相关。

而后半句，自治数据库的服务套件对于DBA是有影响的。自治数据库是一款用于Oracle公有云上的可用的服务套件。这也就意味着本地的数据库是不可以被运行在自治的模式下的，当然也许以后会实现。

目前有很多DBA都担心，自治数据库服务套件是否会让他们失业，其实这还是很远的事情。

事实上有几种在Cloud上提供数据库的服务：

1、Oracle 数据库云服务

2、Oracle裸机云数据库服务

3、Oracle数据库一体机云服务

4、Oracle数据库一体机云机器

5、Oracle数据库快速云服务

自治数据库服务套件将代表你可以签约的其他可能的服务。

接下来我们将讨论，关于Oracle的自治数据库，我们还应该了解哪些内容：

1、Oracle自治数据库或者说拯救我驱动数据库，将会在18c的版本中全面推出，这与当前的12c的版本跨度很大。

2、Oracle12.1的版本应该至少还有4年的时间，预计在2021年之前都不会被淘汰

3、Oracle12.2则应该在2025年都会提供扩展服务，我们都知道，在一个新版本推出的时候，很多用户都不会着急将数据库升级到最新版本，而是到需要响应的服务或者新的版本的扩展服务将要到期的时候才会升级。这样考虑的话，Oracle18c要被真正大规模投入生产环境的话，还是需要很长的时间，

目前，Oracle自治数据库是针对Exadata设计的，我们知道Oracle Exadata虽然很强大，但非常昂贵，因此很多用户都不会选择，尤其是对于一些中小型的企业来说。

因此，DBA们不用担心，从目前来看Oracle18c并不会完全自治，而自治数据库也不会完全取代传统数据看的运行机制。

接下来我们要讨论几个在比较重要的话题：

1、Oracle 18c 并不是自治的数据库服务，反之亦然，这是两个概念

2、自治数据库服务组件目前只适用于Oracle公有云服务

3、根据目前的情况，自治数据库服务组件仅支持Exadata的环境。（当然也许以后会变化）

4、Oracle 18c只是数据库的一个新的版本而已

当我们了解这些之后，我们就可以很确定地说，自治数据库的推出，对于当前运维本地的DBA并没有多大的影响。但 这并不意味着面对云的趋势和与数据库的趋势，我们不需要做改变。我们只有 深入了解新的技术和方向，了解其优势和不足，提前做准备，才不至于被新的浪潮打得措手不及。

接下来我们聊一下Oracle的自治数据库中一些最吸引人的一些功能和特性。毕竟Oracle 自治数据仓库云在今年12月份就推出了。

自动应用补丁：在当前的情况下，如果你想给数据库应用补丁集的话，过程是很简单的。到官网查询最新的补丁集，并根据安装文档和说明进行，很快就可以完成。

因此，这种流程化的手动操作很快被系统自动化的程序来实现也是预料之中的。

还有一些补丁集在应用的时候，是需要停机的，因为程序会对系统中的二进制文件进行修改。但这种情况Oracle很可能也已经有了相应的自动化实现的机制，其实只要能够将意见任务分解成一些按顺序的步骤，那么就有可能通过系统的自动化实现，因此，对于打补丁这样的流程化的工作，自然而然会成为首先要自动化的任务之一。

升级：在使用databse cloud service的时候，如果要升级一个云中运行的数据库的话，唯一的办法就是创建一个新的服务，在这个新的服务中，有一个专门的计算节点我们可以用来完成升级数据库的过程。不过我们要明确一点的是，在PDB的管理方面，Oracle努力建立了很高级的机制，比如我们能够对PDB进行热克隆，在不影响业务和运行的情况下，将PDB从一个容器迁移到另一个容器当中。这些功能从本质上来讲，跟在线迁移数据文件的原理是差不多的，但实现的级别更高级，因此我们看到Oracle的技术是越来越成熟了。

像是升级这种工作，也能够很快被定义为：比如在PDB上需要完成哪些任务，在CDB上需要做什么样的配置保证数据库升级之后能够正常地运行。而且我确定，这些工作将能够在线的完成，无需关闭数据库。从这个角度来讲，自动升级的技术跟我们现在在本地数据库上使用的技术本质上并没有区别，只是说在一个新的服务模式下，这些技术可以在更高的级别进行应用。

接下来的内容，我的ACED朋友Tim帮助我解释清楚了一些元素，能让大家更好地理解Oracle 18c数据库。以下我引用他的原话“Oracle已经解释了自动升级和打补丁的过程在18c数据库中是如何实现的，针对的是18c运行在Exadata环境下的数据库，由于18c 支持滚动进行升级和打补丁的所有过程，包括OJVM，针对Oracle提供的服务，也能够进行在线打补丁”

自我优化：这个听起来很复杂，事实上是很简单的原理。在当前的环境下，当我们使用数据库中一些adaptive特性的时候，数据库相当于在进行自我优化，比如自动创建索引等，这些都是在线完成的，同时，在数据库中加入AI的引擎对数据进行更好地收集和分析处理，之后体现到SQL查询的工程中，并不是一件很难的事情。

也就是说，自我优化就是通过AI程序进行分析后在使用类似adaptive特性影响SQL的执行路径的选择等。

对于以上系统能够自主完成的一些事情，我们来看一下其执行的频率：

1、应用补丁集：应用补丁集并不是一项频繁的任务，定期打一次，执行频率很低。

2、升级：频率更低，一般数据库版本好几年才更新一次，但对于绝大部分的客户来说，并不会紧随着新版本的发布就着急升级，因此这样的操作的需求就更少了。

3、自我优化 ：频率会很高，几乎是持续在发生，因为数据库中数据变更是很频繁的，对数据进行增删查改，几乎都会用到相应的优化，也就是说，这个功能的启用会开销很大。我们知道在当前的数据库中，有 tuning advisors，在我们的经验中，效果并不是太好。很多时候，我们采纳了advisor给出的优化建议进行调整之后，性能反而更差了，那么在自治数据库中自动优化的特性将会达到什么样的效果呢？如果真的很完美，能够在真实的应用场景中进行很好的优化，那的确是会减少对DBA相应的需求。

因此，有一个很重要的事情就是，在没有百分百的肯定下，你觉得一个企业有多大的可能会完全采用系统的自我优化，而不附加任何的人为检测和控制。

我认为这样的可能性是很低的，因而优化要考虑的因素很多，除了SQL本身，还要考虑应用的逻辑，架构的设计，甚至一些政策限制等等，很多时候，人为在进行优化的时候都做不到完美顾及每一个方面，何况是机器。

我们举一个简单的例子，在一些环境下，Oracle Dataguard有自动failover的机制，有时候在数据库中发生一些人为的错误导致数据库会自动进行failover的切换，事实上这些场景我们并不希望切换。因此为了避免自动failover带来的影响，很多企业都很怕使用FSF（Fast Start Failover），该特性虽然功能很好，但总是会在系统中应用很多系统并不允许植入的数据。

综合来讲，我认为自主数据库将会在很大程度上减少对DBA工作的需求，但并不能够完全取代DBA的存在和作用。

自治数据库向用户承诺了以下优势：

1、减少管理时间

在基础架构搭建上，在升级和打补丁上，在保障高可用上，以及在性能有划伤，时间都将大幅减少

2、增加了创新的时间

在数据分析，数据政策，数据安全以及在数据库的设计上，都将需要花更多的时间。

因此，上云之后，DBA必须增强在安全方面的管理技能。

那么，重点来了，面对Oracle的云端数据库，DBA的未来将是什么样的？

17年前，那时候我刚开始做DBA，那个时候设计一套数据库架构是很简单的，只需要决定将数据库安装在什么环境下，比如服务器，大型机或者在一些特定的场景下，是安装在桌面机器也就是PC上的。

现在数据库可选的部署环境很多，比如服务器，虚拟机，集成式系统比如Exadata,还有很多其他的选择。

还必须决定数据库将植入何种架构，比如最通用的本地的选项，私有云，混合云，集成云，而随着18c的推出，选择还在增多。

那么这种情况下，谁来决定将数据库部署在上面环境下，以何种服务模式部署，当然，还是DBA。因此，不是不需要DBA，而是要求DBA要懂得系统以外更多的知识，要了解业务，了解平台等。

我把现在的Oracle DBA分为以下三类，他们的方向如下：

第一类：日常工作只围绕一些最基础常规的任务展开，比如打补丁，扩容等等。那么当自治数据库推出后，如果他们不努力求变的话，很可能会失业

第二类：在运维数据库的同时，还做IT相关的其他工作，或者在其他领域也有比较丰富的经验，那么这类DBA就可以通过各类知识的全面学习，为公司做更重要的决定，而不局限于数据库。这就是我们常说的，从DBA到架构师的转型。

第三类：对于那些决定在Oracle领域深入走下去的DBA来说，由于系统变得越来越智能和强大，对DBA的要求也越来越高，因此这类DBA需要努力学习跟多的知识，去了解业务，了解云，了解所有在云上需要到的技能，才能在Oracle 众多的选择中做合理规划设计而不至迷失。

关于如何解析Oracle 18c对于DBA的影响及应对措施就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。