2017-05-11 DBA日记，DTCC DAY-1的收获

今天参加了2017年DTCC的第一天会议，在这里聆听了不同行业，不同岗位的技术同袍关于他们的工作历程、研究成果、研究感悟的分享，正因由他们无私的分享，才让我的思路更开阔。特别是以下一些内容。

未来的DBA职业发展方向，如何盘活“数据”？这里的数据可能是业务数据，也可能是运维数据。盘活业务数据更多就是DM，DW，BI方向的，这部份的数据在我公司目前是由专门的部门的负责，在职能或分上看，当前的DBA职责是很难盘活的，虽然难，但不是没有办法，正如之前老领导说的，不懂业务的DBA不是好的DBA，所以要想盘活这方面的数据，就不能把自己单一化，不能自己筑起围墙困住自己，而是要拿起手中的铁锤破壁，打开思路，与开发多接触多沟通了解业务。这里开出的方子：从SQL出发，研究SQL所表达的业务，与开发员沟通核实该业务，再从业务理解上看数据组，再从算法设计上优化SQL。

除了业务数据外，我们DBA接触更多的运维数据，这类运维数据有些是结构化的有些非结构化的，要想盘活这些数据就是要先清冼，清洗的方式将所有数据进行结构化处理，放在数据库上，然后进行数学模型建模，刻画数据画像。具体如下：

非结构数据：数据库日志——我们何以将数据库的错误信息抽象出来进行清洗，如：时间，ORA-00600，错误描述

结构化数据：CPU信息，内存信息，IO信息，AWR中的DB TIME，CPU TIME，EVNET，IO REQUEST，USER COMMIT，EXECUTES等等。

画像指标：180日没有出得重启过，没有出现ORA错误，---》稳定 ,根据资源使用情况，生成另一标签----》白天忙于交易，晚上空闲，（白天闲得慌，晚上批处理）,又或是交易达人，日志杀手，内存杀手，CPU杀手。。连接风暴女皇。等，，有了这些标签就能让我们感性得认知到各个数据库系统的特色，从而制定的相关的运维方案，数据库提供更长久的服务.

"DBA是一群只会说NO，NO，NO的人",听到这句话时，立刻就联想到平日的行径，好像真的是这样，我们说“NO， NO ，NO”是因为我们是基于规则来判断的，但是如果我们能够像优化器基于成本（数据）来判断的话，得出多个解决方案并对比，最后通过数据一对比，那就我们都是说YES、YES、YES.

"数据库弹性调配资源,如何快速为突击的市场活动的动态分配资源"，这个命题，主要针对分布式数据库与APP容器化的结合，打个比方，现在我们的场景是一场促销活动，持续三天，防止突发的负载不影响正常业务，就是我们就可以分布式数据库中增加一个节点，并完成数据同步，然后将APP容器复制到新的容器里的，就可以完成扩容了。这里的前提是，分布式数据库对节点的要求是不苛刻的，如OS VERSION，CPU频率等。。。还有一个就是新增加节点时的数据分布能够通过集群软件完成，效率要快。

"存储IO的QOS",当多个系统数据库共享同一个存储时，为防止其中一个数据库出现恶劣的IO操作，导致所有数据库的IO变慢，这时就需要存储IO的QOS了。

其实今天还谈到好多内容，如12C列式存储，数据库架构设计时需要考滤的问题（事务），分库分表的操作（那些表应该分，怎么分法，分完成APP的关键字指定）等等好多内容，就不一描描述了。