Author: mac

G-bed G-sofa: TV Rack: HANNAH Coffee Table

今天居然接到一个印度打来的电话，一印度MM操着纯正的印度英语居然说是从Linkedin上找到我的，希望我能参加他们杭州公司的面试，费了很大的劲也没让她弄明白我不愿意relocate。 只能说节后的人才市场就像快烧开的水，分子们开始活跃了。

Question:某客户的应用做过变更（短链变长链），现cpu利用率较之前有明显改善，参见附件中的awr报告。想咨询一下sql语句的执行时间，cpu Time等指标，是否会受到短链变长链影响，因为从awr报告看，性能有明显改善。 Load Profile 变更前: Per Second Per Transaction Redo size: 244,606.59 13,269.94 Logical reads: 5,964.59 323.58 Block changes: 1,278.41 69.35 Physical reads: 339.03 18.39 Physical writes: 35.30 1.92 User calls: 693.44 37.62 Parses: 241.46 13.10 Hard parses: 0.16 0.01 Sorts: 97.93 5.31 Logons: 16.05 0.87 Executes: 617.55 33.50 Transactions: 18.43 变更后: Per Second Per…

不少人大概和我一样在创建物化视图的时候会犯头痛，怎样合理的改写SQL语句以及添加物化视图日志需要经过慎重精密的考虑。有了DBMS_ADVISOR.TUNE_MVIEW存储过程这个帮手后，极大地方便了DBA或应用设计人员创建和优化物化视图。该TUNE_MVIEW存储过程可以做到优化物化视图中的查询定义，修正物化视图日志的问题，此外它还能为原先不能refresh fast的物化视图提出建议以使得其可以快速刷新。 SQL> CREATE MATERIALIZED VIEW MACLEAN.STRMTS 2 USING INDEX REFRESH FAST ON DEMAND 3 ENABLE QUERY REWRITE 4 AS select distinct t1,t2 from MACLEAN.strb; AS select distinct t1,t2 from MACLEAN.strb * ERROR at line 4: ORA-12015: cannot create a fast refresh materialized view from a complex query /* 以select distinct查询语句为例，该语句本身不符合refresh fast的标准，但TUNE_MVIEW存储过程 可以将这种查询变形使得满足快速刷新的条件 */ –…

并不是所有的SQL operations都是可并行化的；不少人认为sort merge join这种排序合并操作是不能并行化的，这显示是一种错误的认识。有了这样一个列表你就可以更好地理解Oracle中的Parallel Execution了： Parallel Query: Table scan Nested loop join Sort merge join NOT IN GROUP BY Hash join SELECT DISTINCT UNION and UNION ALL Aggregation PL/SQL functions called from SQL ORDER BY DDL: CREATE TABLE AS SELECT CREATE INDEX Rebuild index Move partition Split partition DML: UPDATE on partitioned table DELETE on…

在Oracle 10g中出现了column encryption列加密特性，通过对列上的数据加密实现数据安全性的目的。当然实现这一加密特性是有代价的，一方面会导致所加密列数据每行所占磁盘空间字节数增长，另一方面会消耗更多的cpu和内存资源。 当使用Oracle的TDE(transparent data encryption)加密数据表的某一列时将导致该表上每行数据所占用的空间大致增加33-51个字节，这几十个字节用作以下用途： 其中20个字节用以对加密值的完整性检查,该部分可以通过’nomac’选项来省略 同时加密会填补加密值到16个字节(如果列本身长度不够的话)，举例来说如果是9个字节长度的number类型，那么加密该number字段时就会需要将该数据填补到16个字节，也就是额外地多用了7个字节 加密时默认采用salt选项(default)，salt是指一串长度为16个字节的随机string，在数据被正式加密前这串string将会被添加到列上，这种做法使得黑客无法通过比对已知的密文来匹配加密值(steal patterns of ciphertext to known ciphertext);salt总是位于加密数据的末尾；该部分可以通过no salt选项来省略。 注意默认使用salt选项加密的列是不能创建索引的，所以强烈建议加密列时强制使用no salt选项！加密列上的索引不支持范围扫描操作(Range scans on encrypted columns can’t use index)，而加密表空间(encryption tablespace)没该限制。 SQL> create table enctab (t1 int encrypt); Table created. SQL> create index ind_enc on enctab(t1); create index ind_enc on enctab(t1) * ERROR at line 1: ORA-28338: Column(s) cannot be…

Oracle数据库升级向来是一门纷繁复杂的工程，DBA需要为产品数据库的升级耗费大量时间精力在准备工作上；因为其升级复杂度高，所以即便做了较为充分的准备仍可能在升级过程中遇到意想不到的问题，为了更高效地完成升级任务和减少停机时间，我们有必要为升级工作营造一种”舒适的”防御式的数据库”氛围”: 1.为了保障升级后的数据库性能，我们有必要在升级前有效地收集数据库的性能统计信息，以便升级后若发生性能问题可以做出对比: 为了保证性能统计信息真实有效，有必要在数据库升级前的一个月即开展收集工作 收集的性能统计信息应当尽可能的精确真实 在Oracle 8i/9i中使用Statspack性能报表，将快照级别设置为6或更高，设置快照间隔为30分钟，在具体升级前将perfstat用户使用exp工具导出，参考Metalink文档Note:466350.1介绍了若何对比升级前后的Statspack快照 在Oracle 10g/11g中使用AWR自动负载仓库性能报告，保证采集30天左右的快照，快照间隔最好为30-60分钟;之后可以使用dbms_swrf_internal.awr_extract存储过程将AWR导出到dumpfile文件，在升级完成后载入这部分AWR信息，并可以使用DBMS_WORKLOAD_REPOSITORY.AWR_DIFF_REPORT_HTML函数对比升级前后的性能 2.正式升级前的防御性措施: 过多的审计信息可能会导致升级速度下降，可以在升级前将审计数据导出，并清理审计字典基表: 截断SYS.AUD$基表: SQL>TRUNCATE TABLE SYS.AUD$; 同样的有必要清理10g后出现的回收站： 清理DBA回收站: SQL>purge DBA_RECYCLEBIN; 移除一些”过期”的参数，设置这些参数的原因很有可能是为了修正原版本上的一些问题，例如我们都会做的设置event参数；但在新版本中这些参数是否仍有必要设置是一个值得讨论的问题，当然你完全可以就此事去提交一个SR： 这些”过期”参数可能包括:过老的如optimizer_features_enable=8.1.7.4,_always_semi_join=off,_unnest_subquery=false 或者event = “10061 trace name context forever, level 10″，如此之类等等。 为数据库中的数据字典收集统计信息: 在Oracle 9i中可以执行以下过程收集数据字典统计信息, SQL> exec DBMS_STATS.GATHER_SCHEMA_STATS (‘SYS’, options => ‘GATHER’,estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, method_opt => ‘FOR ALL COLUMNS SIZE AUTO’, cascade => TRUE); 在Oracle10g/11g中收集字典统计信息可以由GATHER_DICTIONARY_STATS存储过程来完成: SQL> exec DBMS_STATS.GATHER_DICTIONARY_STATS;…

到底是谁扣动了database writer的扳机？初学Oracle的朋友都会对dbwr这个后台进程有一种模糊的印象，dbwr何时会被触发？很多人大约会回答当发生检查点或者当某些脏块在LRU链表上处于较冷的一端时。同时又有许多关注于宏观架构的工程师会将dbwr的写出规律归结为是lazy(懒)的。Oracle作为目前市场占有率最高的商用数据库，其各种内部算法都可以算得上是商业机密；虽然不断有专家为我们”解密”，但在我的观念中这些内部原理都与真理之冠有着不大不小的差别。所以显然我要描述的是我个人对于database writer以及cache management(缓存管理)的理解，这些理解在一定程度上是能够自洽的，但我无法保证它们必然准确无误。 要详细描述dbwr的工作原理，我们需要从久远年代的版本V7323说起，当时的db writer和cache management已经十分成熟了，8i以后只是引入了增量检查点等特性，dba不用再关心db writer受一些细节参数的影响，而只需要关注增量检查点的活跃程度就可以了。以下我们列出在V7323中，dbwr可能被触发写出的几种情况: a.当前台进程需要将磁盘上的物理数据块读取到数据库高速缓存中(db cache)时，其首先需要在数据库缓存中寻找到一块可用的free(空闲) buffer。为了寻找这样free buffer，该前台进程首先需要以排他方式持有相关LRU链表的latch(闩)，并在该LRU链表上扫描所可用的Free buffer，扫描都会从LRU链表的尾端开始，也就是”较冷”的一端。在此过程中，前台进程沿着由尾到头的方向所遍历到的脏块将被移动到LRUW链表上(注意：一个buffer同时只可能处于一个链表上)；此外相关的统计信息如dirty buffer inspected及free buffers inspected将会累增。若该前台进程在LRU链表上搜索的范围超过了整个LRU链表长度*(隐式参数_db_block_max_scan_count/100)所规定的阀值时，其搜索操作将自行中止，该前台进程还会以信号通知dbwr进程并释放其所持有的LRU latch。dbwr后台进程在收到前台进程的信号信息后，会执行一次大批量的写出操作以使得LRU链表上有干净的clean buffer可用，在此过程中前台进程将处于free buffer wait等待事件中。dbwr后台进程为了写出LRUW与(LRU链表尾部)的脏块，其会主动去持有LRU latch并扫描该LRU链表(也是从尾部开始)试图找出脏块，并批量写出这些收集到得脏块。该DBWR的扫描深度(DBWR scan depth)由隐式参数_db_writer_scan_depth_pct的所指定，当DBWR所扫描的LRU链表长度等于整个LRU链表长度*(_db_writer_scan_depth_pct/100)时，DBWR将停止继续扫描LRU链表。 8i以后：以上这种情况一言以蔽之就是DBWR write for Free Request，这种情况在8i以后仍然奏效；hidden parameter _db_block_max_scan_pct依然健在，其默认值为40，当然也可以从x$kvit视图中”Max percentage of LRU list foreground can scan for free”相关列观察到。到10.1版本中_db_writer_scan_depth_pct(Percentage of LRU buffers for dbwr to scan when looking for dirty)仍健在其默认值为25，在10.2中被彻底废弃。由于引入了增量检查点，DBWn也会主动去遍历LRU链表，将发现的Dirty Buffer移至Checkpoint Queue(dirty queue)上，该扫描同样也受到隐式参数_db_writer_scan_depth_pct的限制。 b.若前台进程在遍历LRU链表，顺带将脏块(dirty…

一套Linux上的11.2.0.2 RAC系统，其中一个节点startup mount时出现ORA-19808错误，日志如下： SQL> alter database mount; alter database mount * ERROR at line 1: ORA-01105: mount is incompatible with mounts by other instances ORA-19808: recovery destination parameter mismatch SQL> exit Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 – 64bit Production With the Partitioning, Real Application Clusters, OLAP, Data Mining and Real Application…

January 2011补丁集更新在大约2周前发布了，与Oracle Database相关的psu分别为10.2.0.5.2,10.2.0.4.7(REQUIRES PRE-REQUISITE 10.2.0.4.4),11.2.0.1.4,11.2.0.2.1.