今天参加了DBGeek的技术交流活动，感触还蛮多。也是在一个偶然的机会中，受肉丝（魏兴华）邀请，欣然答应了他们组织的技术分享活动，好久没有动动筋骨，也是跃跃欲试，一来可以总结一下最近的工作情况，二来这种分享会让自己对于我原本有些模糊的工作理念深信不疑。而技术分享相比于纯商业的活动的一个大的区别，就是技术分享的受众比较纯粹，而且主题内容比较专一，专业，不会因为营销而有标题党，博眼球的内容。而对于这次技术分享来说，我也感受到了社区，圈子里的DBA的热情。
今天涉及的数据库有Oracle,MySQL,PG,Toprow DB(Informix),这些主题内容量非常大，有很多因为时间关系也无法一一扩展，其实对于这次的技术分享，自己也比较担心，因为主题的跨越度较大，一般的DBA要么是Oracle+MySQL组合，要么就是Oracle+PG组合等，如果知识交叉很多，可能在接受上会有一定的难度，从现场的情况来看，其实还不错，因为主题的内容也会有意无意的和其它数据库做一个更加形象的对比。所以这种多种技术主题的组合还是蛮成功的。
其实对于里面的主题内容，里面让我比较有感触的是关于SQL审核的部分，主要原因是这让我想起了哪些人工审核的痛点，可能Oracle中的痛点还要多。当然竹峰兄勇于实践，解放自己，造福社区，这种利己利人的事情值得大赞。我是从我的一些感受和对于Oracle审核的角度有下面的而一些想法：
从我目前的了解和同行业中的一些实践来看，对于SQL语法的审核说简单也简单说复杂也复杂，为什么这么说呢，我以之前的公司为例，我们的开发人员，无论系统业务，对于DB级的结构变更都是使用统一的工具入口，生成了xmll配置文件（这个和阿里的方式有些类似），会自动编译生成规范的SQL语句，所以在这个层面，我几乎没有做过语法审核的工作，更多的关注语句本身的意义和优化空间等。但是在没有这样一个统一的入口的情况下，SQL的质量情况也是五花八门，对于一些让人无语的SQL，比如DDL+commit; DML无commit这种，在不太规范的环境中我还真见过不少，当然这个不是重点，对于Oracle来说还有一些审核的情况可能是灰色地带，或者实现起来会有很大的局限性，比如我们有一个生产环境，内部涉及很多的schema关联和db link，如果开发提交了一个SQL语句或者PL/SQL，他可能对于这些权限的信息就不够清楚，这部分内容简单通过SQL审核还是审不出来的，其实严格来说这应该是开发提供，但是开发对于生产系统也确实了解有限，所以这种工作就需要一种中和，而不是彻底的划清界限。
而对于SQL审核中的性能考虑，从Oracle的层面来说，有一些场景目前的审核还是会有一些局限性。比如对于提交的SQL是否需要结合表变更情况考虑是否需要添加索引，对于大表添加字段，设置default的时间窗口评估，提交的PL/SQL因为性能考量转换为单一SQL等情况，这些功能可能直接实现还是存在一些限制，依赖对于DDL操作敏感而且无法做很具体的尝试，二来对于真实环境中的执行窗口时间是一个非常模糊的评估，而这些信息其实对于关键应用来说又是格外需要的，我的个人观点是对于大表的DDL还不如集中火力处理，如果万不得已还是不要做在线重定义，因为数据内部复制也本身消耗极大，这个过程其实也是时间+空间来平衡高可用。而我对于此的一个基本思路就是11g中snapshot standby,备库完全可读可写，完全可以闪回，我觉得简直就是为SQL审核而生的新特性，目前虽然来看，了解的人少，用的人少，还是没有找到太适合的场景，其实SQL审核中就是一个利器，真刀真枪的审核，对于主库完全无影响，但是参考标准更加贴近实际，更加准确。对于DDL类的敏感操作是非常好的评估标准，对于DML的影响范围非常切合实际。而且把SQL审核中的数据同步工作也一并解决了。因为在指定的时间范围内，主备本身就是同步一致，无需更多的配置。同时也能进一步降低回滚的几率。
今天同时也和李书琪同学聊了不少OGG的东西，对于一个比较棘手的迁移方案自己也有了一些新的收获，其实本来对于这方面不太熟悉的东西，这种面对面的交流着实有收获。
晚上大家聚在一起吃饭，在五道口附近，着实让我感受到了高校周围的火爆，到处都充满了青春的气息，但是对于这种火爆，我显得格格不入，我觉得在各种等待中的生活不是我想要的状态，大家聚在一起，也就打开了话匣子，发现不同数据库之间其实也没有什么隔阂，都能再一起聊得很尽兴，对于很多公司的高可用实现原来有非常多的坑和痛点，而且很多问题都是不得已而为之。总体感觉目前的数据库瓶颈已经逐步从SAS的时代逐步改进，互联网中的SSD还是大行其道，而且这也在潜移默化中促进了产业的发展和成就。还一度聊到了3.5寸软盘，这也是一件暴露年龄的事情，当然桌中还有几位90后的年轻精英，从他们对于技术的热爱程度，我们还是亚历山大。其实对于运维来说我是持有一种非常保守的态度，现在服务器规模如此庞大，云计算，大数据是势不可挡的缺失，在这个背景下的Devops其实还是有多的发展空间，当然更多的产出，无形之中也是在逐步削弱运维的角色，而对于运维我们就需要有更高的眼界和思维能力去处理那些更高级的事情，在四处救火的同时，还是需要沉淀下来一些对于行业的思考和内功，才能在这种大形势下避免更多的断崖式发展，这是危机也是机遇。
今天涉及的数据库有Oracle,MySQL,PG,Toprow DB(Informix),这些主题内容量非常大，有很多因为时间关系也无法一一扩展，其实对于这次的技术分享，自己也比较担心，因为主题的跨越度较大，一般的DBA要么是Oracle+MySQL组合，要么就是Oracle+PG组合等，如果知识交叉很多，可能在接受上会有一定的难度，从现场的情况来看，其实还不错，因为主题的内容也会有意无意的和其它数据库做一个更加形象的对比。所以这种多种技术主题的组合还是蛮成功的。
其实对于里面的主题内容，里面让我比较有感触的是关于SQL审核的部分，主要原因是这让我想起了哪些人工审核的痛点，可能Oracle中的痛点还要多。当然竹峰兄勇于实践，解放自己，造福社区，这种利己利人的事情值得大赞。我是从我的一些感受和对于Oracle审核的角度有下面的而一些想法：
从我目前的了解和同行业中的一些实践来看，对于SQL语法的审核说简单也简单说复杂也复杂，为什么这么说呢，我以之前的公司为例，我们的开发人员，无论系统业务，对于DB级的结构变更都是使用统一的工具入口，生成了xmll配置文件（这个和阿里的方式有些类似），会自动编译生成规范的SQL语句，所以在这个层面，我几乎没有做过语法审核的工作，更多的关注语句本身的意义和优化空间等。但是在没有这样一个统一的入口的情况下，SQL的质量情况也是五花八门，对于一些让人无语的SQL，比如DDL+commit; DML无commit这种，在不太规范的环境中我还真见过不少，当然这个不是重点，对于Oracle来说还有一些审核的情况可能是灰色地带，或者实现起来会有很大的局限性，比如我们有一个生产环境，内部涉及很多的schema关联和db link，如果开发提交了一个SQL语句或者PL/SQL，他可能对于这些权限的信息就不够清楚，这部分内容简单通过SQL审核还是审不出来的，其实严格来说这应该是开发提供，但是开发对于生产系统也确实了解有限，所以这种工作就需要一种中和，而不是彻底的划清界限。
而对于SQL审核中的性能考虑，从Oracle的层面来说，有一些场景目前的审核还是会有一些局限性。比如对于提交的SQL是否需要结合表变更情况考虑是否需要添加索引，对于大表添加字段，设置default的时间窗口评估，提交的PL/SQL因为性能考量转换为单一SQL等情况，这些功能可能直接实现还是存在一些限制，依赖对于DDL操作敏感而且无法做很具体的尝试，二来对于真实环境中的执行窗口时间是一个非常模糊的评估，而这些信息其实对于关键应用来说又是格外需要的，我的个人观点是对于大表的DDL还不如集中火力处理，如果万不得已还是不要做在线重定义，因为数据内部复制也本身消耗极大，这个过程其实也是时间+空间来平衡高可用。而我对于此的一个基本思路就是11g中snapshot standby,备库完全可读可写，完全可以闪回，我觉得简直就是为SQL审核而生的新特性，目前虽然来看，了解的人少，用的人少，还是没有找到太适合的场景，其实SQL审核中就是一个利器，真刀真枪的审核，对于主库完全无影响，但是参考标准更加贴近实际，更加准确。对于DDL类的敏感操作是非常好的评估标准，对于DML的影响范围非常切合实际。而且把SQL审核中的数据同步工作也一并解决了。因为在指定的时间范围内，主备本身就是同步一致，无需更多的配置。同时也能进一步降低回滚的几率。
今天同时也和李书琪同学聊了不少OGG的东西，对于一个比较棘手的迁移方案自己也有了一些新的收获，其实本来对于这方面不太熟悉的东西，这种面对面的交流着实有收获。
晚上大家聚在一起吃饭，在五道口附近，着实让我感受到了高校周围的火爆，到处都充满了青春的气息，但是对于这种火爆，我显得格格不入，我觉得在各种等待中的生活不是我想要的状态，大家聚在一起，也就打开了话匣子，发现不同数据库之间其实也没有什么隔阂，都能再一起聊得很尽兴，对于很多公司的高可用实现原来有非常多的坑和痛点，而且很多问题都是不得已而为之。总体感觉目前的数据库瓶颈已经逐步从SAS的时代逐步改进，互联网中的SSD还是大行其道，而且这也在潜移默化中促进了产业的发展和成就。还一度聊到了3.5寸软盘，这也是一件暴露年龄的事情，当然桌中还有几位90后的年轻精英，从他们对于技术的热爱程度，我们还是亚历山大。其实对于运维来说我是持有一种非常保守的态度，现在服务器规模如此庞大，云计算，大数据是势不可挡的缺失，在这个背景下的Devops其实还是有多的发展空间，当然更多的产出，无形之中也是在逐步削弱运维的角色，而对于运维我们就需要有更高的眼界和思维能力去处理那些更高级的事情，在四处救火的同时，还是需要沉淀下来一些对于行业的思考和内功，才能在这种大形势下避免更多的断崖式发展，这是危机也是机遇。
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/23718752/viewspace-2104474/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/23718752/viewspace-2104474/
920
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
