Oracle Life

May 8, 2013

Oracle数据库恢复:风险意识缺乏导致的数据风险

这是发在微信账号上（ OraNews ）的文章，收录在这里。

【数据库的风险逐渐升级】最近有客户遇到了一则数据库故障，起因是当进行一个数据表创建时遭遇到限制约束。

该数据表来自MySQL数据库，在MySQL中，表名的长度限制是64个字符，但是Oracle的表名（ table_name ）不能超过30个字符，这是数据库的内在限制。

然后如何解决呢？应该说是数据库知识已经足够普及了，程序员们找到了数据字典表，将限制字段的长度改掉了。大家能够评估后果么？数据字典被修改，整个数据库开始出现ORA-600错误，就此触发一次故障。

很多时候我们说，无知者无畏，当动手能力太过于强大时，也会使数据库遭遇不测。而对于企业数据库环境来说，内部的风险往往大于外部。

不以规矩，不成方圆。做任何事都要遵循一定的守则和规范。

【Raid 并非安全无忧】最近两周，收到了两则关于Raid损坏的数据恢复请求。都是来自较为偏远的地区，客户使用RAID 5磁盘冗余，但是没有数据备份。时至今日，仍然有很多客户相信仅仅凭借磁盘级别的Raid保护就已经足够保障数据安全了。而现实是残酷的。

在技术快速发展的今天，一方面是大城市、中心地区的IT技术更新及时，另一方面则是很多二三线城市的信息和技术传播严重滞后。

这两个案例，一个是Raid 5中损坏了2块硬盘，只能从残存的盘片上恢复局部的数据；另一则是Raid 5中损坏了1块硬盘，但是恢复后发现Windows上的文件部分变为0字节，无法打开，这种情况可以通过底层扫描恢复文件，再校验完好性进行数据级别的恢复。

但是无论如何，在Raid的保护之外，有效的备份和容灾机制是必不可少的，无论我们技术人身在何处，不要忘了及时更新自己的技术知识。

Posted by eygle at 8:54 AM | Permalink | Case (154)

May 4, 2013

恩墨学院集训实验室（OCM 数据库方向）即将投入使用

今天是一个青年的节日，5月4日，恩墨学院的侯院长在这一天仍然在挥汗如雨的粉刷墙壁，恩墨学院的集训实验室即将投入使用。

恩墨学院自创建以来，就以培养实践人才为使命，通过自我开发的实训课程，结合Oracle原厂的OCP、OCM认证培训课程，培养出了即能够快速入手、完成工作使命的DBA，又使得大家能够顺利通过认证考试，拿到OCP、OCM认证证书。

新的集训实验室位于广渠门：

侯院长为此奔波行走数日，又亲自操刀粉刷，足见用心良苦：

非学无以广才，非志无以成学，望恩墨学院再接再厉，不断培养出色人才！

Posted by eygle at 7:53 PM | Permalink | Activity (109)

May 3, 2013

我的Oracle技术主题演讲列表和简介

记录一下我做过的Oracle主题相关演讲和简介，这些主题的PPT散见于各处，希望将来有机会在其他场合再次分享这些主题：

1.运用之妙存乎一心 - Oracle优化器案例与算法解析 （2013 DTCC数据库技术大会）
内容简介：优化器算法是Oracle数据库最为核心的技术之一，也是最为复杂多变的技术部分，在很多人眼里，优化器无比神秘莫测，然而理解了优化器的基本原理之后，就能够自如的运用其知识解决日常遇到的一些复杂问题。在这个主题中，演讲者将与我们分享一些Oracle优化器的相关案例和优化器算法，并解释如何将这些知识巧妙的和实践结合起来。

2.察微知变 - Oracle数据库的全流程优化 （2013年3月主题）
内容简介：通过多年常规与深入的Oracle数据库优化，总结上升到企业级数据库全流程优化的经验与实践，同时分享Eygle在最近一年中遇到的有价值案例与解决思路。

3.Oracle性能优化 - 从索引到架构以及软件测试过程优化（2013年3月主题）
内容简介：在企业软件开发的过程中，数据库优化应当贯穿始终，从开发环节的数据架构设计与优化，到运行阶段对性能至关紧要的索引设计与优化，甚至推进到业务上线前的测试过程优化。优化应该无处不在的、无时不在的渗透到企业技术架构之中，在这个主题中，我们将和大家分享从数据整体架构设计到运行优化案例，以及开发测试过程中的SQL审计实现，我们也将通过来自保险、金融等领域的案例积累和大家分享实践中遇到的点点滴滴。

4.天道酬勤 - 我走我的路，Oracle职业生涯回眸 （校园行主题和学习经验分享）
内容简介：我在Oracle的技术之路上，已经走过了10多年的历程，见证了这个行业从无到有，从混乱到有序，从单兵到团队的发展历程，在这个主题中我将和大家分享我的学习探索历程，也将和大家分享我最看重的初学者品质和我们的招聘需求。

5.Oracle之道 - 数据库安全与深入恢复实践 （2012 DTCC数据库大会主题）
主题简介：2011年是数据安全事件大爆发的一年，众多网站泄露出很多安全事故，在这个主题中，Eygle将和大家分享Oracle数据库的安全防范与安全手段。此外，对于从事Oracle技术多年的DBA们，如何深入到Oracle技术核心是很多人关心的内容之一，在这个主题中，EYGLE将和大家分享如何基于"猜测"的问题分析和诊断方法。

6.深入解析Oracle：栓锁竞争与Latch优化实践 （2011 DTCC数据库大会主题）
主题简介：数据库的架构设计对于性能影响巨大,不当的架构可能在后期导致数据库出现严重的性能瓶颈，而影响性能的因素是多样和复杂的，在这个主题中，我们将和大家分享在数个大型优化项目中所遭遇的性能问题及其解决方案，通过这些案例我们从高屋建瓴以及细致入微的角度来对数据库性能问题进行剖析。
Oracle的性能体系，Oracle的内存与外存，内存的并发控制，Oracle的Latch机制与竞争，由于Latch机制引发的CPU 100%故障原因的分析，索引与性能。
在去年的2010数据库大会上，盖国强老师为大家分享了"深入解析Oracle - 数据库架构设计与性能优化实践"。今年，盖老师还将分享深入解析Oracle系列，今年把主题锁定在了：栓锁竞争与Latch优化实践。

7.深入解析Oracle - 数据库架构设计与性能优化实践（2010 DTCC数据库大会主题）

主题简介：Oracle数据库的前期规划、建模与数据结构设计对于系统的性能至关重要，本主题将通过几个实践优化案例的分析与处理，与大家分享数据库设计对于性能的重要影响，并通过性能分析与优化过程分享，与大家探讨解决此类问题的一般思路。

Posted by eygle at 10:51 AM | Permalink | Activity (109)

April 27, 2013

云和恩墨（北京）信息技术有限公司官方网站

云和恩墨（北京）信息技术有限公司的官方网站已经发布，其网址为：

http://www.enmotech.com

我们精心制作了网站版式和内容，期望大家帮忙提提意见。

我们的理念：以数据驱动，成就客户；以技术创造价值，助力客户发展。

在最近举行的DTCC 2013年中国数据库技术大会上，云和恩墨（北京）信息技术有限公司的专家团集体亮相，

云和恩墨基于数据安全、连续运行、高效优化、商务智能四大领域为用户提供全面的解决方案。

在很多客户环境中，云和恩墨通过性能优化和改进，帮助用户实现了数十倍乃至上百倍的性能改进提升，性能优化是实现性能飞跃，增强用户体验的主要手段;

我们的客户就在您的身边，云和恩墨期待与您携手开启云和之旅，以先进技术，帮助用户增强其核心竞争力，真正助力用户成长。

云和恩墨（北京）信息技术有限公司，现在已经在广州、上海、成都设立分公司和办事处，在云南、贵州、四川、兰州、杭州、沈阳、黑龙江等省市为用户提供服务。

云和恩墨（ http://www.enmotech.com ）感谢您的支持与帮助。

Posted by eygle at 10:57 AM | Permalink | Life (523)

April 25, 2013

2013数据库大会:崔华-基于Oracle的SQL优化案例分析

崔华的新书即将出版，其数据库大会上的演讲也非常精彩，他的新书十分值得期待。

原文链接：http://cio.it168.com/a2013/0419/1474/000001474420.shtml

2013年中国数据库技术大会第二天的"Oracle架构与优化"专场中，来自中航信资深Oracle数据库工程师崔华为大家分享了《基于 Oracle的SQL优化典型案例分》主题演讲。从演讲的内容来看，这是一次非常实用的技术分享。据资料显示，崔华从2004年开始从事DBA工作，拥有 Oracle 数据库技术各个领域的经验。除了工作外，崔化在博客上撰写大量的文章并在Oracle活动中进行演讲，此外还与他们合作撰写三本专业图书，《Oracle DBA手记 2》、《Oracle DBA手记3》和《海量数据库解决方案I》。

▲中航信资深Oracle数据库工程师崔华

　　Oracle优化从理论说起：SQL优化方法论

　　提到Oracle的优化，太过理论性质的内容无需赘述，崔华先生简单为与会者分享了3个方面，分别是：

　　·Oracle里的SQL优化实际上是基于对CBO和执行计划的深刻理解

　　·Oracle里的SQL优化不能脱离实际的业务

　　·Oracle里SQL优化需要适时使用绑定变量

　　提起CBO不得不多说两句，ORACLE 早先提供了CBO、RBO两种SQL优化器。CBO在ORACLE7 引入并不断深入，而同时9i以后版本中基本上都是基于CBO的优化。

　　崔华认为SQL优化最有技术含量的部分不在于你通过种种手段(比如重新收集统计信息等)调整了目标SQL的执行计划、缩短了其执行时间、解决了该SQL的性能问题，而是在于你要知道CBO为什么在一开始会选错执行计划，你要知道CBO选错执行计划的根本原因。

　　深入分析很多案例后发现很多问题的原因都有一定共性，在本次演讲的案例显示导致CBO评估出对一个实际数据量为730多万且统计信息准确的大表 S_EVT_ACT执行全表扫描操作后的成本值仅为2，其原因是参数OPTIMIZER_MODE的值在session级别被修改成了 FIRST_ROWS_10，这同时也是导致上述坐席登陆慢的问题多次不间断出现的根本原因。而对于这种问题的改进方法崔华建议：

　　• 修改各个session中对于参数OPTIMIZER_MODE的设置，将其值修改为默认值ALL_ROWS

　　• 如果不能在session级修改参数OPTIMIZER_MODE的值，我们还可以使用SQL Profile。在上述18个表关联SQL中加入Hint(即/*+ index(T18 S_EVT_ACT_P1) */)，并用加入Hint后改写SQL的执行计划替换原SQL的执行计划

　　引实例讲方法

　　在下面的SQL 语句中包含了IN，而IN之后的括号内是一个包含视图的子查询(即select grppolno from v_bc_lcpol where polno = '9022000000000388')，它不是一个常量的集合，所以Oracle这里不能对该SQL做"IN-List Iterator"和"IN-List Expansion /OR Expansion";

崔华：基于Oracle的SQL优化案例分析

　　上述SQL中的视图V_BC_LCGRPPOL和V_BC_LCPOL均包含了集合运算符UNION ALL，所以Oracle这里也不能对该SQL做视图合并;于是Oracle现在就只剩下了两条路可走：要么对该SQL走FILTER类型的执行计划(即 "IN-List Filter")，要么对该SQL做子查询展开。

　　而把sql语句改写以后，效果则会发生巨大的变化：

崔华：基于Oracle的SQL优化案例分析