一、自我介绍
1、2010年毕业，一直从事政府项目，从一线项目实施做起2年项目实施，再做3年项目经理，后做专职Oracle DBA至今;
2、大学主学网络技术，后因兴趣转做DBA。目前主要从事Oracle、MySQL两种类型的数据库管理和性能优化工作;
3、当前管理数据库实际台数超过400台，其中10套Oracle RAC、80套Oracle DataGuard、12套MySQL Master-Slave，剩下的都是单节点业务库;
4、主要工作内容中：处理性能问题占比超过60%, 数据库迁移和升级占比20%，数据库的安装和部署工作占10%、数据库的故障处理占比10%;
5、日常专注于性能优化、及数据库高可用性两个方向。擅长: SQL语句优化，特别是索引的结构设计深入的理解和实际应用。以及Oracle RAC的故障处理及解决;
二、为何参加ACDU活动
1、我个人不善于言词，同时一直认为【技术的提升】需要自己长时间的积累和磨练，并不是参加某个活动，或参加某个培训就能够得到提升的;
2、所以在此之前，我一直是不想去的;
3、大概在两个月前，看到ACDU将在成都举行线下活动，突然想去看看。因为一直在《墨天轮》关注行业的动态，一些最新的信息，加上距离也不远。就想去看看;
4、我学东西本身慢，头脑也不灵活，悟性不高。如一本技术书没有2个月我是学不完的。虽然我也工作多年，属于老兵了。但与大咖相比我差得远，惭愧惭愧，真的是自叹不如！
5、这次是来学习的，来取经的，想进一步提升下自己。希望自己别走着走着，看不见路，也看不见方向，那么DBA的职业生涯也就结束了。
三、活动内容
1、以下收获与思考是仅代表我个人的观点，也存在局限性，有不妥之处望多多包涵。
2、很荣幸参加这次ACDU活动，再次感谢以下六位老师的分享；
分享1： 构建可靠MySQL服务：RPO=0实现方案分析--冯光普老师
收获:
1、了解了RPO=0实现方案的相关知识，拓展了自己的知识面;
2、大公司的技术人员，也会遇到各种各样的问题。
3、之所以成为大咖，可能真的是遇到的问题比我多而已。
思考:
1、虽然MySQL的双主架构可以做,但目前我接触到的和了解到的MySQL并双主架构并没有采用共享存储;
2、若两个节点的双主MySQL，同时对外提供服务。数据的一致性会存在问题;
3、因为双主MySQL的两个节点，都有数据，即存储是相互独立的。
A、同一台服务器中，针对并发的情况由内核完成各进程间的并发请求处理,可以确保数据一致性;
B、那么两台服务器之间的并发，在MySQL的双主节点中，没有机制做处理。单靠开发人员在应用层做处理，也有难度;
C、而Oracle RAC并不存在这个问题，因为Oracle 两个节点共用一份存储，通过Cache Fusion协调两个节点间的并发请求;
D、所以就是在部署MySQL双主场景下，应用层也只是其中一个节点写入数据，另一个节点仅做查询，这样或许才能够真正避免MySQl场景下的双主数据不一致的问题;
分享2: MogDB/openGauss数据库性能管理之道--熊军
收获:
1、熊军老师成名多年，一直坚持在技术一线,值得敬佩是我的学习榜样;
2、熊老师每天能够坚持学习6个小时，这是大部分人都不能做到的;
3、做到的技术实力都是能够独当一面的高手；
思考:
1、国产库还需要一代人的努力，希望占领国产库市场的厂商能够能够拿出足够的经费，打磨自己的产品;
2、借鉴国外的没有问题，不仅要皮毛，要借鉴的核心，更要深入到骨髓。
3、相信经过一代的努力后，以技术为前提的国库，前（钱）途一片光明;
分享3： 行远自迩，PostgreSQL修炼之道--熊灿灿
收获:
1、小熊老师厉害啊，17年毕业，除数据库以外的知识储备信息量，远在我之上。
2、类似操作系统原理的相关知识，信手拈来。而我却忘得差不多了，惭愧。
思考：
1、年龄比你小，还比你努力，也爱分享，能够举一反三，语言描述和文字组合清晰，头脑反映快，相信小熊老师能够走得更远;
2、向我这种走得慢的人，必须更努力才行。卷与不卷都没有关系，只是希望自己能够在数据库领域多走一点点而已;
分4: 浅析基于Golang的MySQL Proxy中间件实现原理 --冯浩
收获:
1、涉及的知识面比较广，不单纯的是数据库层。更多涉及到网络和操作系统层的知识;
2、通常我们只掌握了20%的知识，因为20%的知识能够解决80%的问题;
3、要向成为大咖，就得花时间掌握剩下80%的知识，虽然这80%的知识，只能解决20%的问题;
思考:
1、冯浩老师可能是为了便于展现，配置文件中 用户名 及 口令 竟然设置成了相同。这个还是不妥的;
2、不管是正式和测试环境， 用户名和口令都不应该设置为相同; 如: 买了个保险柜，口令竟然是初始密码。肯定是不妥的;
3、特别是当前信息安全问题尤为重要，目前我们国内信息安全层的技术人员占比要低于印度的。
分享5： 我们追赶的数据库：Oracle -- 尹海文
收获:
1、Oracle的确强大，个人认为Oracle仍然是未来10年最好的关系型数据库，没有之一;
2、是今天唯一分享Oracle相关知识的技术大咖。而且是通常难见Exadata 相关知识，也不虚此行的;
思考
1、能够用上Exadata的，在政府行业都是挺多省级的项目中，偶尔会少量的，但占比不高的;
2、目前我接触的项目中，只有北京有用到Exadata，而且还是Oracle原厂的人部署的，我谈不上熟悉;
3、尹老师与我几乎同龄，爱分享，善于交流沟通，技术能力也在我之上，我只能跟着后面慢慢学了;
分享6： 新一代PG数据库开源监控系统建设之路 --王军
收获:
1、对系统做监控，当系统遇到各种异常时间触发报警。
2、这是我们当前大部分监控系统能够做到的，只要提供的监控项和监控参数设置正确，都能够达到监控报警的能力;
思考:
1、目前监控系统的机制主要是报警机制，处警机制太弱。 报警与处警（处理报警的能力）个人认为是一体的，不应该分开;
2、比如: 监控系统对数据库层的监控，发现耗性能的SQL语句，那么针对耗性能的SQL语句，是否能够给出优化建议？ 或者自动完成SQL语句的优化？
A、今天分享的，和目前市面上所有的监控系统，都无法做到【自动优化】;
B、目前能够做到的，挺多是半自动，而且还不完善。或许本身优化就是一个难点，优化也需要足够的经验和业务场景相结合进行。
3、我个人对监控系统不很看好，意义不是很大。
A、因为业务系统只要是有人使用，使用过程中遇到任何问题，终端使用人员都是第一时间反馈。这就是现成实时的监控报警；
B、处理报警，最终也是由能够解决问题的技术人员处理的。并不是监控系统完成;
4、所以个人认为: 监控系统的报警和处警机制是一体，不能只做好做的部分，不好做的部分也要跟进。
四、活动意义
1、DBA的在市场供需比例中，本身就少; 大部分公司DBA的人数通常只有1个人。甚至没有设置DBA的岗位;
2、DBA经常是单打独斗，又是工作在幕后，特别把DBA工作做得井然有序的，系统往往不容易出现问题，DBA的价值很难体现出来;
3、通过线下活动，大家分享案例，分享最新的信息，了解最新技术趋势，最主要的是能够集中精力听完，看看大咖的精神风采！
4、本想上前与各位大咖虚心请教一番，但介于我目前的能力，不能够提供信息与大咖交换心得。
5、能够听大咖们讲，能够按照他们的方式走行，我已很满意了。
6、感谢墨天轮、感谢ACDU、感谢小墨等的辛苦付出！
评论
0 点赞
0
点赞
1向大佬学习 1 1 1 1 1 1 1
