本文共 1495 字，大约阅读时间需要 4 分钟。

今天参加了2017年DTCC的第一天会议，这场会议让我受益匪浅。在会上，我聆听了不同行业、不同岗位的技术同袍关于他们的工作历程、研究成果以及研究感悟的分享。正是通过他们的无私分享，我的思路得到了极大的开阔。

未来的DBA职业发展方向：如何盘活"数据"？

在会议中，关于DBA职业发展方向的讨论让我印象深刻。数据可能是业务数据，也可能是运维数据。盘活业务数据更多涉及DM、DW、BI等领域，而这些数据在公司中通常由专门部门负责。从职能或分上看，当前DBA的职责在业务数据方面确实较为困难，但并非没有办法。正如前辈所说，不懂业务的DBA不是好的DBA。因此，要想盘活这方面的数据，就不能将自己局限在技术细节中，而是要拿起手中的铁锤破壁，打开思路，与开发团队多接触多沟通，深入了解业务。

开出的第一方格是：从SQL出发，研究SQL所表达的业务，与开发人员沟通核实该业务，再从业务理解上看数据组，再从算法设计上优化SQL。

此外，除了业务数据，DBA还需要接触更多的运维数据。这些运维数据有些是结构化的，有些是非结构化的。要想盘活这些数据，就需要先进行清洗，通过结构化处理，将所有数据放在数据库上，然后进行数学模型建模，刻画数据画像。

如何处理非结构化数据：以数据库日志为例

非结构化数据的处理是一个重要课题。以数据库日志为例，我们可以通过抽象和清洗，将错误信息提取出来进行处理。例如，时间、ORA-00600错误代码、错误描述等信息都可以被清洗和结构化。

结构化数据的处理

结构化数据方面，我们可以从CPU信息、内存信息、IO信息、AWR中的DB TIME、CPU TIME、EVENT、IO REQUEST、USER COMMIT、EXECUTES等方面入手。通过对这些数据的采集和分析，可以为数据库优化提供重要依据。

数据画像的构建

通过对运维数据的清洗和建模，我们可以构建以下画像指标：

• 180天没有重启过，且没有出现ORA错误：稳定性表现
• 根据资源使用情况生成另一标签：白天忙于交易，晚上空闲（白天闲得慌，晚上批处理）
• 或者是交易达人、日志杀手、内存杀手、CPU杀手、连接风暴女皇等角色识别

通过这些标签，我们可以更直观地了解数据库的特点，从而制定相应的运维方案，为数据库提供更长久的稳定服务。

"DBA是一群只会说NO，NO，NO的人"

听到这句话时，我立刻联想到平日的工作状态。确实，作为DBA，我们常常需要基于规则做出"NO"的判断。然而，如果我们能够像优化器一样，基于数据和成本来判断，并得出多个解决方案进行对比，最终通过数据验证，那我们就能成为"YES、YES、YES"的DBA。

数据库弹性调配资源：如何快速应对突击市场活动

在会议中，还讨论了数据库弹性调配资源的方案。这个命题主要针对分布式数据库与APP容器化结合的场景。以促销活动为例，当遇到突发负载时，可以通过在分布式数据库中添加节点进行数据同步，同时将APP容器复制到新的容器中完成扩容。前提是分布式数据库对节点的要求相对宽松，例如OS版本、CPU频率等。同时，新增加节点时的数据分布需要通过集群软件完成，效率要尽可能快。

存储IO的QOS

在多个系统数据库共享同一个存储的情况下，为防止其中一个数据库因恶劣的IO操作影响到其他数据库的性能，这时就需要存储IO的QOS（Quality of Service）了。

其他讨论内容

此外，会议还涉及诸多其他内容，例如12C列式存储、数据库架构设计时需要考量的事务性问题、分库分表的操作（哪些表应该分，如何进行分法，以及分完成APP的关键字指定）等。这些内容就不一一描述了。