Author: mac

今天早上应用人员反映一个原本在9i上可以顺利完成的CTAS脚本，迁移到10g后运行总是报“ORA-1652: unable to extend temp segment by 128 in tablespace TS_HQY1_TEMP “无法扩展临时表空间的错误。应用人员表示该脚本涉及的数据量在迁移前后变化不大，而且令人匪夷所思的是在新的10g库上临时表空间大小已达40多个G，要远大于原9i库。很显然这不是由于临时表空间过小导致的该问题，更多的原因肯定是出在迁移后Oracle不同的行为方式上。 该脚本每月执行一次用以汇总数据，其中一个单表接近4亿行记录，GROUP BY操作涉及到的数据量十分庞大。我们来具体看一下这个SQL: create table gprs_bill.zou_201007_cell_id as select /* g_all_cdr01,60 */ calling_num mobile_number, lac, lpad(cell_id, 5, ‘0’) cell_id, count(*) c, sum(call_duration) call_duration, sum(decode(record_type, ’00’, 1, 0) * call_duration) moc_call_duration, sum(decode(record_type, ’01’, 1, 0) * call_duration) mtc_call_duarion from gprs_bill.g_all_cdr01 where substr(calling_num, 1, 7) in (select…

大约2个月前，一位业内人士问我为什么9i CBO迁移到10g上会出现许多执行计划改变导致的性能，他当然是为了能考考我；实际上我接触过的环境大多在8i/9i下没有使用CBO优化模式，从8i/9i的RBO模式跨越到10g上较为成熟的CBO优化模式，这当中出现执行计划讹误可以说是情理之中的；而9i CBO到10上的CBO问题也不少，我首先想到的是统计信息收集上存在区别，但具体是什么区别却又说不上。那位业内人士听了我的回答，笑，笑而不语。 Oracle十分博大，博大到可以称为Oracle的世界，很多东西长期不用就会遭人淡忘；我们来复习下9i和10g上统计信息收集的一些改动。 在9i中收集统计信息时其默认的MOTHOD_OPT模式为’FOR ALL COLUMNS SIZE 1’，使用这种模式时Oracle只收集所有列上最基础的统计信息，包括了最小/大值，distinct值等信息;但是不会收集列上的直方图。对那些数据均匀分布和没有出现在SQL语句中where子句中作为条件的列来说，这样的统计信息完全足够了。然而如果列上的数据分布并不均匀就可能导致CBO的执行计划成本计算不准确，这时我们需要手动对这些列上的直方图进行统计。 10g上对dbms_stats包中默认的METHOD_OPT模式做了修正，这显然是引起9i CBO迁移到10g CBO后易发地执行计划变化的一个重要因素，也是那位业内人士所要问的题眼。 新的默认METHOD_OPT值为”FOR ALL COLUMNS SIZE AUTO”，这意味着Oracle将通过内部算法自动决定那些列上需要收集统计信息，而那些列上不需要。是否收集直方图取决于列上数据的分布情况和与对应表相关的工作负载,这种工作负载可以解释为数据库中存在某些需要参考这些列的详细信息来计算执行成本的SQL语句。 这种方式听上去十分理想，似乎Oracle可以默默无闻地为我们抓取所有急需的统计信息。 然而问题是在许多环境中Oracle没有做出是否需要收集列上直方图的正确决定。实践证明Oracle有可能收集许许多多不必要的直方图，同时又放弃了许多需要收集的直方图。 在轻量级的应用环境中这种直方图收集不当的问题造成的影响大多数时间不为人们所察觉，相反在performance critical或已经形成性能瓶颈的环境中则可能是一场不大不小的麻烦。 此外Oracle还改变了列上密度(density)信息的计算方式。该值常被Oracle用来确定谓词选择性，当突然出现额外不必要的直方图时可能造成的广泛显著地性能影响(当然好的影响也可能出现，只是概率上……)。 显然这些莫名出现的不速之客也会给共享池造成影响，library cache与row cache相关的闩可能短期内车水马龙，如果您的应用数据表上有成百上千的列那么情况可能更糟(所以说开发要遵循范式，没有规矩的最后结果往往是应用不可用，项目失败。别告诉我你的应用苟且地活着，那同样意味着项目失败)！

Oracle中SQL解析的主要流程: 我们说的游标概念比较复杂，它可以是客户端程序中的游标，服务进程中的私有游标，以及服务器端共享池里的共享游标。假设一个游标被打开了，一般来说它的共享游标信息(包括执行计划，优化树等)总是会在SQL AREA里，无需再次软/硬解析。 SESSION_CACHED_CURSORS是Oracle中的一个初始化参数(修改必须重启实例)，指定了每个会话缓存的游标上限(保留在PGA中)；客户端程序中open cursor的要求仍会被传递给服务进程，服务进程首先扫描自身缓存的游标信息，如果命中则可以避免软解析，也有人称它为“软软解析”。 HOLD_CURSOR是预编译程序中的一个参数，它指定了私有游标是否因该被缓存，这里不做展开。 在分析工具tkprof中hard parse与soft parse被同等对待，都被认为是parse；软解析即会造成parse总数上升。 软解析避免了硬解析过程中的几个步骤，但仍包括了初始化的语法，语义解析并计算语句HASH值与SQL AREA中已有语句进行对比；若匹配则查询优化等昂贵的操作得以避免。 另请注意，10053事件仅在硬解析过程中被触发。

一位黑客建立了该网站(JailbreakMe.com)，可以通过浏览器登录的形式破解几乎所有的iOS，这包括了iPhone,iPad,和iPod Touch，将解除Apple对这些设备的软件限制。 用户如果想尝试未经授权的app或者想在多个不同国家使用这些设备，都可以登录http://jailbreakme.com来实现破解。 很显然这是自上周关于破解iPhone等设备并不属于非法行为的判决后，对于Apple反对破解行为并声称破解对设备安全与稳定会造成影响的公然挑衅；我们不得不赞叹于黑客的卓越技术和开发速度。 破解设备将影响到设备正常的保修，Apple这样解释。但是实际上，破解操作可以很容易地被例如重置到出厂设置等操作撤销，如果安装了新版本的Apple mobile Operating System-iOS, 也可以达到撤销破解效果的目的。 “JailbreakMe”迅速成为Twitter上的热门话题，这极有可能是第一个以浏览器为基础的破解程序。在过去，用户一般都采用下载破解程序到个人电脑上，然后连通电脑与需要破解的设备的模式。 已经尝试的用户反映除了针对运行3.2.1版本的iPad存在问题外破解程序近乎完美。从打开Safari浏览器到登陆JailbreakMe.com下载程序完成大约耗时1分钟，程序会告知已将自身加入home screen，并祝你”have fun”！

Our team deleted some archivelog by mistake. Rolled the database forwards by RMAN incremental recovery to an SCN. Did a manual recovery to sync it with the primary. Managed recovery is now failing. alter database recover managed standby database disconnect Alert log has : Fri Jan 22 13:50:22 2010 Attempt to start background Managed Standby…

2010年7月4日的样子，敲了很多墙： 7月31日，开始吊顶，大多数瓷砖都进场了，今天还去把马赛克买了。 买的马赛克： 厅里用的瓷砖到了： 开始铺客厅瓷砖: ‘

下午尝试用Toad For Data Analysts生成查询语句和ER模型图，感觉还不错；同时配有图形化的执行计划示意图，配合Toad的SQL optimizer可以算是一个很不错的数据库开发组合。 生成查询的Query Builder界面: 生成的SQL语句: 图形化的执行计划:

Oracle中联机日志文件(online redo log)在大多平台上以512 字节为一个标准块。 (HPUX,Tru64 Unix上是1024bytes,SCO UNIX,Reliant UNIX上是2048bytes,而MVS,MPE/ix上是4096bytes,虽然以上许多UNIX已经不再流行,实际情况可以通过 select max(l.lebsz) log_block_size_kccle from sys.x$kccle l where l.inst_id = userenv(‘Instance’)   语句查询到) LGWR后台进程写出REDO时未必能填满最后的当前日志块。举例而言，假设redo buffer中有1025字节的内容需要写出，则1025=512+512+1 共占用三个重做日志标准块，前2个标准块被填满而第三个标准块只使用了1个字节。在LGWR完成写出前，需要释放”redo allocation”闩，在此之前SGA中索引”redo buffer”信息的变量将指向未被填满块后面的一个重做块，换而言之有511字节的空间被LGWR跳过了，这就是我们说的redo wastage；我们可以通过分析v$sysstat动态视图中的redo wastage统计信息了解实例生命周期中的重做浪费量。 SQL> col name for a25 SQL> select name,value from v$sysstat where name like ‘%wastage%’; NAME                           VALUE ————————- ———- redo wastage                  132032 redo wastage的一个图示: 为什么要浪费这部分空间呢？实际上，这种做法十分有益于LGWR的串行I/O模式。redo wastage并不是问题或者Bug，而是Oracle故意为之的。当然过量的redo wastage也不是什么好事，一般是LGWR写出过于频繁的症状表现。9i以后很少有因为隐式参数_log_io_size过小而导致的LGWR过载了，如果在您的系统中发现redo wastage的问题不小，那么无限制地滥用commit操作往往是引起问题的罪魁祸首，减少不必要的commit语句，把commit从循环中移除都将利于减少redo wastage。 我们来看一下关于redo wastage的演示: SQL> select…

天知道这在法庭上会是什么说法！Apple采取了一种积极防御的态度，他们指出破解(jailbreaking)iPhone,在今天可能是合法的，但仍将影响到保修。此外他们还表示真正会去破解IPhone的人只是那么一小撮，实在没必要因此而太过兴奋。 昨天的法律仲裁可能会是近几年最大的科技趣闻，同时也给了Apple一个机会。Apple公司的法律支持大概要花一阵子时间搞清楚破解(jailbreaking)这档子事了。事实是经过仲裁认定这是百分之百合法的。苹果公司当然没有义务为你提供一个专门用来破解的应用(jailbreaking application)-jailbreaking.app；但他们也不能够直接回绝你：“抱歉，我们禁绝任何破解！”。 一位苹果公司发言人这样对Mac狂热爱好者说： 苹果公司的目标是保证在使用iPhone时能获得美妙的用户体验，而且我们了解到破解其实是有损于这种体验的。正如我们之前所说的，绝大多数用户并没有破解的打算，因为那样做会影响到保修并且导致iPhone极不稳定也不可靠。 大体上我们不用质疑这份声明的诚意，但在末尾关于破解会导致iPhone极不稳定的纯属无中生有。如果破解存在诸多问题，怎么可能使整个社区致力于此？

数月之前，一位新疆的同事反映客户的某套单节点数据库存在性能问题，某个SQL长时间运行没有结束，在该SQL运行期间大量回话处于latch free等待中。因为相隔遥遥千里，同事之间是通过Email交流的；他首先给我发来了该问题SQL的相关explain_log。其中该语句的执行计划如下: ———————————————————————————————– | Id | Operation | Name | Rows | Bytes | Cost | ———————————————————————————————– | 0 | SELECT STATEMENT | | 1 | 1956 | 13 | |* 1 | FILTER | | | | | | 2 | NESTED LOOPS OUTER | | 1 | 1956 | 13 | | 3…