©作者：eygle 发布在 eygle.com

不少朋友一直记得以前的优化推荐：Redo Log Buffer不要高于3M。

而实际上大家也发现，从Oracle10g开始，Redo Log Buffer缺省的已经是大大超过了原来的想象。
从Oracle 9i引入了Granule的概念后，在Oracle10g中，Oracle的内存分配会为'Fixed SGA Size'和'Redo Buffers'共享整数倍个Granule。

看看不同SGA设置下的内存分配情况：

SQL> select * from v$version;

BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Prod
PL/SQL Release 10.2.0.4.0 - Production
CORE    10.2.0.4.0      Production
TNS for Linux: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production
SQL> select * from v$sgainfo where name in ('Fixed SGA Size','Redo Buffers','Granule Size');

NAME                                  BYTES RES
-------------------------------- ---------- ---
Fixed SGA Size                      1267212 No
Redo Buffers                       15507456 No
Granule Size                       16777216 No

SQL> select sum(bytes)/1024/1024 from v$sgainfo where name in ('Fixed SGA Size','Redo Buffers');

SUM(BYTES)/1024/1024
--------------------
            15.99757

在另外的系统中，供分配了2个Granule，每个4M：

SQL> select * from v$sgainfo where name in ('Fixed SGA Size','Redo Buffers','Granule Size');

NAME                                  BYTES RES
-------------------------------- ---------- ---
Fixed SGA Size                      1263320 No
Redo Buffers                        7122944 No
Granule Size                        4194304 No

SQL> select sum(bytes)/1024/1024 from v$sgainfo where name in ('Fixed SGA Size','Redo Buffers');

SUM(BYTES)/1024/1024
--------------------
          7.99776459

摘录一部分Oracle文档中关于Granule的描述供参考：

With dynamic SGA, the unit of allocation is called a granule. Components, such as the buffer cache, the shared pool, the java pool, and the large pool, allocate and free SGA space in units of granules. Oracle tracks SGA memory use in integral numbers of granules, by SGA component. All information about a granule is stored in a corresponding granule entry. Oracle maintains the state of each granule in the granule entry and the granule type.

Granule size is determined by total SGA size. On most platforms, the size of a granule is 4 MB if the total SGA size is less than 128 MB, and it is 16 MB for larger SGAs. There may be some platform dependency, for example, on 32-bit Windows NT, the granule size is 8 MB for SGAs larger than 128 MB.

The granule size that is currently being used for SGA can be viewed in the view V$SGA_DYNAMIC_COMPONENTS. The same granule size is used for all dynamic components in the SGA.

Note: If you specify a size for a component that is not a multiple of granule size, then Oracle rounds the specified size up to the nearest multiple. For example, if the granule size is 4 MB and you specify DB_CACHE_SIZE as 10 MB, you will actually be allocated 12 MB.

Oracle keeps information about the components and their granules in a scoreboard. For each component that owns granules, the scoreboard contains the number of granules allocated to the component, any pending operations against this component, the target size in granules, and the progress made toward the target size. The start time of the operation is also logged. Oracle maintains the initial number of granules and the maximum number of granules for each component.

For operations that modify the number of granules, Oracle logs the operation, the target size, and the start time to the appropriate SGA component in the scoreboard. Oracle updates the progress field until the operation is complete. When the operation is complete, Oracle replaces the current size with the target size and clears the target size field and the progress field. At the end of the operation, a database administrator can see how the number of granules was changed. Oracle updates the initialization parameter values to reflect the updated amount of SGA in use.

Oracle maintains a circular buffer of the last 100 operations made to the scoreboard. Fixed views show the state of the scoreboard and the current contents of last 100 operations to the scoreboard.

Allocating Granules at Startup

At startup, Oracle reads the values in the initialization parameter file, queries the operating system memory limits, and allocates virtual address space for the SGA. The initialization parameter SGA_MAX_SIZE specifies the maximum size of the SGA for the life of the instance in bytes. Its value is rounded up to the next granule size.

Adding Granules to Components

A database administrator grows a component's SGA use with ALTER SYSTEM statements to modify the initialization parameter values. Oracle takes the new size, rounds it up to the nearest multiple of 16MB, and adds or takes away granules to meet the target size. Oracle must have enough free granules to satisfy the request. If the current amount of SGA memory is less than SGA_MAX_SIZE, then Oracle can allocate more granules until the SGA size reaches SGA_MAX_SIZE.

相关文章|Related Articles

• 关于Oracle归档进程的运行机制
  
• 关于Oracle归档进程的运行机制
  
• 关于《深入浅出Oracle》中granule的补充
  
• 设置ARCHIVE_LAG_TARGET 强制日志切换
  
• 磁盘IO故障 导致Redo损坏一例
  

评论数量(0)|Add Comments

本文网址：http://www.eygle.com/archives/2009/07/granule_log_buffer.html

作者：Fenng 发布在 dbanotes.net.

金庸小说中的美女? 这可能是一个比较老的话题了。如果"到Google上百度一下"，能找到不下百万条的记录结果。之所以会有这么多结果，可能和每个读者心目中的理想美女标准不一吧。

尽管是个老掉牙的话题，考虑到公司(注：阿里巴巴集团)崇尚武侠文化，所以唠叨几句，再做点普及可能也不算过时。有些人物形象，比如黄蓉小龙女等已是深入人心，再此略过不表。再者，美与不美是相对的，比如《《天龙八部》中的怪人包不同就觉得自己女儿包不靓最美嘛。

小昭

小昭是金庸最喜欢的女性人物。其容貌"双目湛湛有神，修眉端鼻，颊边微现梨涡，直是秀美无伦"，我们又从文中得知小昭生父韩千叶系中土人士，其母黛绮丝人家还是波斯的圣女，居然是个混血儿，考虑到遗传因素，所以美貌自不待言，比一般的美女更美也是情理之中的事情。

小昭武功不弱，聪明伶俐，通音律，且精通奇门八卦之术，绿柳庄外曾救得群雄性命，从这一点来看，人家是个完美的知识女性，用现在的话说，那叫知性美女。小昭对爱情忠诚，富有牺牲精神，最后为了张无忌而痛心远走波斯，这是颇为读者神伤的一段。

小昭恐怕也是金庸先生心目中的理想女性的化身，另外一个和她人物形象有点重叠的是双儿，当然，双儿更多了一点温柔（所以能得圆满?）。类似的女性人物形象在金庸作品中出现两次，可见作者心目中的理想美女亦相去不远。暗自揣测，这两个人物形象或许是参照金庸第三任妻子林乐怡而写的，当然这个一家之言，还有待考证。

小昭堪称金庸小说中的绝顶佳人。不知道是否有武侠小说迷按照这个标准寻找意中人的，哈哈。

郭襄

《神雕侠侣》中的郭襄，是金庸所有小说中最具亲和力的人物，"潇洒如诗"，也是金庸所有小说中最闪亮的配角人物，一见难忘，所以让何足道与张三丰"为君沉吟"。

痴情者如郭襄者，少见又少见。"天涯思君不敢忘"，一遇杨过误终身，爱慕杨过而不可得，杨过喜欢的那句话"世间不如意者，十居七八"倒应在了她身上。不是有人说了么，"得不到的东西最美好"，如果郭襄真的能和杨过在一起，反而未必那么圆满，"得不到的东西最美好"，但愿如此。郭襄这样的女子当今社会怕是没有了----都直接当小三去了。顺便说一下，郭襄的徒孙周芷若是金庸小说中相当令人生厌的人物，从某种角度上看，不亚于康敏。

王语嫣家族女性

看来遗传因素决定了一切，王语嫣一家的女性貌似都貌美得不得了。好像只有他妈王夫人稍微差了一点，估计隔代遗传的因素作怪吧。容貌归容貌，这个家族的人物性格并不讨人喜欢。

在最近新修版的《天龙八部》中，王语嫣的人物形象较之先前有了较大改变，最后热衷寻求长生不老之术，幻想青春永驻。个人认为，这是金庸小说中体现的西方神话形象那西塞斯（Narcissus）的女性版。以王语嫣为代表的女性可能是美女，但非常无趣。如果段誉娶了这样的媳妇，绝对糟糕透顶。王语嫣可算上美女，但无论如何不是佳人。

冯蘅

这是一个必须一提的人物。也是个相对比较陌生的名字，冯蘅是谁? 黄蓉她妈，黄药师的妻子。

仅仅通过其他人物的口中就已经能够得知绝代风貌，且不说黄药师如此另类人物被其折服，其过目不忘之能也当世少有，令人心驰神往，原来美貌与智慧是可以并存的。考虑到黄蓉同学多少只是他母亲的影子，加上大家太熟悉这个角色，不复赘言。

新修版中居然情节更改为黄药师因为弟子们说闲话而斗气娶了冯蘅，实在是大煞风景。这个变动相当的蛇足。

程灵素

金庸先生书中女主人公绝大多数都算美女，但程灵素除外。"头发稀疏，肌肤枯黄，脸有菜色"，如果分析一下，可能是这个古代化学专家整天接触药石之故，如果放到现在，人家就是个化学兼医学双料女博士，外表不美，心灵美，这也顶顶重要。其实内在美重要,还是外在美重要，不同的历史时期人们的价值取向也是不同的，也或许有人喜欢程灵素也说不定。

程灵素最后为胡斐牺牲，不由得让人埋怨作者下笔残酷，如果武侠小说允许假设，那么胡斐娶了程灵素是不会让人感到意外的。

香香公主

香香公主之美，美到不够真实，而其不谙世事，也似乎不是凡间之人。激战双方的兵士见到她居然"便似中邪昏迷一般，人人都呆住了...无数长矛都掉下地来，弓箭手的弓矢也收了回来...人人神色和平，收刀入鞘"，如果在今天，维护世界和平旧靠她了:) 塑造这个小说人物的时候恐怕也多少投射了一些西方经典美女海伦的有关因素在里面吧。

金庸早期小说人物形象多半缺乏立体感，香香公主也是如此，甚至在同一部小说中，还不如霍青桐更能赢得人好感。

陈圆圆

当然，香香公主再美，可能还敌不过陈圆圆，陈圆圆有多美，无法形容(所以不可能留下'西施捧心'之类的形象给世间人)！因为无法形容，所以作者描写陈圆圆多用映衬笔法，纵观全部金庸小说，这是相当精彩的地方，丝毫不亚于纯文学作品。在《碧血剑》中曾有一幕，写到闯王帐下群雄见到当世第一美人莫不疯狂，甚至袁承志这样的人见到她也是心中荡漾。多年之后，韦小宝第一次见到陈圆圆时虽已韶华不再，但风韵不减当年，仍禁不住"张大了口竟然合不拢来..."；再说，女儿阿珂都把韦小宝震撼得"我要死了"，更别说人家老娘了。

貌美不是好事情，汉族文化的传统思维是红颜祸水，其实"冲冠一怒为红颜"关卿何事? 不过是政治家争权夺势的借口罢了。陈圆圆终其一生，何其不幸也。在吴三桂和李自成这两个枭雄中间注定得不到得不到幸福，更为天下人唾骂，这也是造化使然。金庸小说中的陈圆圆，是不折不扣的悲剧形象，其后半生青灯古佛，心怀天下苍生，那是万分难得的菩萨心肠了。

最后多说一笔，如果陈圆圆不那么美貌的话，恐怕中国历史要改写吧? 当然，这个有点扯远了，否则，该有同学说"丘处机不该路过牛家村"这回事儿了。

--EOF--

金庸小说本来是网友写烂了的题材。这是给公司内刊投稿的文章（美女题材在家里是个禁忌，我这也是冒着被老婆揍的风险)。算是重温了一下渐行渐远的武侠文化吧。

---

相关文章|Related Articles

• 鸠摩智-没有了屠刀才成为好人 - Jul 4, 2005
• 任我行-大独裁者 - Jul 4, 2005
• 周芷若-初恋情人反目成仇 - Jul 4, 2005
• 归辛树--笨蛋神拳失败教育家 - Jul 4, 2005

评论数(10)|添加评论 | 最近作者还说了什么? Follow Fenng@Twitter
本文网址：http://www.dbanotes.net/mylife/beauty.html

DBA Notes 理念: 用简约的技术取得最大的收益...

1.1.1. 5月1日 在家聊天

今天是5月1日，劳动节7天长假的第一天。我自从几年前5.1节的时候和老婆去了趟三亚，就决定再也不长假出游了。所以长假期间我一般选择在家休息，每个长假的最后2天才安排在深圳周边玩玩。由于昨晚Richard要对系统的IO做一次小的调整，最近一直担惊受怕的老万十分紧张，怕调整后系统出现严重的问题，所以他希望我今天能帮他盯一天系统。

选择昨天晚上选择优化实施实际上不是一个好主意，今天是5.1长假的第一天，即将入夏的时节，又赶上放假，正是白家电促销的好日子。今天全国的白家电销量应该是一个小高峰，根据业务部门的测算，老万他们这套系统的负载肯定高于4月30日。选择昨天晚上动手优化的风险十分高，一旦今天出现问题，那么Richard将面临的形势将十分严峻。我一直不理解Richard这么做的真实意图，也许是老外并不知道5.1这个日子的特殊性，也许真的是Richard对昨天的动作十分有把握。不过无论如何，如果是我，绝对不敢选择在CPU这么高的时候单独去优化IO，也许这回我真的遇到了高人了，如果真的是这样，那就太好了，我也可以好好和他切磋切磋。

登录到VPN后，感觉今天系统的状况出奇的好，现在已经是上午的10点左右了，按理说应该是一天中业务量比较大的时段，CPU空闲还有15%左右，IO系统的表现和很好，AVWAIT基本少接近于0，AVSERV在20左右。难道是Richard的优化起了作用？我马上做了一个STATSPACK的采样，并且和9点的采样生成了一份报告。

由于Statspack的采样很久没有清理了，所以报告生成的很慢。在报告生成的时候，我看了看QQ的在线用户，老万的QQ状态是“忙碌”。我于是发信息过去给老万打了个招呼：“万科，早”。

老万回信息说：“老白，今天的情况异常的好，我看了个把小时了，active的会话数量一直低于80，CPU使用率也不高。看样子Richard昨天的优化效果十分明显，别看这老外五大三粗的像个土匪，不过还是有两下子的。”

我说：“按照理论来说，Richard所做的优化操作并不是很合理，不应该会有这样的效果。万科，有没有可能今天的业务量不大？”

老万说：“这一点我也疑问过，所以刚才我给国内几个工贸公司都打了电话，他们反馈回来的信息是今天的产品销售量比昨天普遍略高5-10%。”

这太不正常了，难道昨天晚上Richard还做了什么我不知道的调整？这个时候Statspack报告已经生成完毕了，我马上打开了报告

Load Profile

~~~~~~~~~~~~                            Per Second       Per Transaction

                                   ---------------       ---------------

                  Redo size:            184,507.91              6,333.90

              Logical reads:            133,335.76              4,577.23

              Block changes:              1,053.27                 36.16

             Physical reads:              2,535.17                 87.03

            Physical writes:                127.19                  4.37

                 User calls:              3,996.10                137.18

                     Parses:                568.89                 19.53

                Hard parses:                 49.98                  1.72

                      Sorts:                 26.44                  0.91

                     Logons:                  0.38                  0.01

                   Executes:                772.16                 26.51

               Transactions:                 29.13

 

  % Blocks changed per Read:    0.79    Recursive Call %:                21.92

 Rollback per transaction %:    0.51       Rows per Sort:              2971.01

 

Instance Efficiency Percentages (Target 100%)

            Buffer Nowait %:   99.98       Redo NoWait %:              100.00

            Buffer  Hit   %:   98.12    In-memory Sort %:               99.99

            Library Hit   %:   98.26        Soft Parse %:               91.22

         Execute to Parse %:   26.32         Latch Hit %:               98.12

Parse CPU to Parse Elapsd %:    8.08     % Non-Parse CPU:               93.36

从单块读的响应时间来看，确实今天的IO系统性能有了十分明显的提升：

                                                                   Avg

                                                     Total Wait   wait    Waits

Event                               Waits   Timeouts   Time (s)   (ms)     /txn

---------------------------- ------------ ---------- ---------- ------ --------

db file sequential read         6,508,594          0     41,645      6     62.0

latch free                        983,166          0     12,239     12      9.4

db file scattered read            194,469          0      2,674     14      1.9

我算了一下平均事务响应时间，是732毫秒，比前一阵子的3秒左右有了很大的提升。这真是太不可思议了。我让老万立即对今天的WORK_ORDER表进行一个统计，看看业务量和昨天对比相差多大。老万统计了一下后告诉我从9点到10点的工单量来看，今天的的工单量比4月30号少15%左右，看来有些工贸公司的量还是略有下降。看样子今天虽然销售量比较大，不过安排送货安装的并不多，也许商场的送货人员也放假了，要等4号才开始工作。不过从另外一个方面考虑，15%的业务量下降也不应该有这么大的效果啊。

我认真看了看Load Profile，突然发现今天报告里的平均事务数量是每秒29个，而前几天是57，也就是说今天系统的平均事务量是30号的一半。从刚才老万他们对工单表的统计来看，不应该有这么大的差异，是什么地方出现了问题呢？

“老万，今天工贸公司放不放假？”，我突然问老万。

“放啊，今天除了值班的都放假，这有什么关系？”，老万疑惑的问我。

我恍然大悟了：“老万，你别忘了，你这个系统除了业务人员用以外，工贸公司的1500个管理岗位也在用啊，而且这1500个管理岗位消耗的系统资源是相当的大，他们总是在做一些统计和分析。今天的现象只是一个暂时性的，等长假结束了，你就会看到情况并不这么乐观。”

老万一听就笑了：“我还真忘了这茬了，这帮大爷经常自己写SQL去做统计，我们每天的主要工作就是杀那帮家伙的会话”。

如果工贸公司的1500个终端没有开的话，系统负载起码少了30%以上，看样子老万是空欢喜了一场，不过我的心情却无比的好，看来我的判断并没有错，仅仅靠Richard的那几招，想要解决问题还是不可能的。

看看时间，已经是中午12点了，我说：“万科，今天下午就没必要盯着了，估计长假前三天都不会有什么问题，4号后可能会有一些工贸公司的人加班，压力会大一些，不过也不会有大的问题，关键是8号。”

老万想了想说：“是啊，看样子这几天也不会有太大的负载，5.1节促销的效果也没有想象的那么明显，又被业务部门忽悠了一把，还增长20%的业务量，都是拍脑袋拍出来的，明显不是那回事。老白，你这几天也没必要盯着了，不过8号你一定帮我盯紧了，8号我预感会发生点什么。”

中午睡了个午觉，一觉醒来已经是3点半了。VPN连过去看了看，系统负载依然很小。看样子这几天确实都不需要怎么关心了。想想也对，以前就出过几次问题，当时是把内网工贸公司的应用停了来应急的，每次都是立竿见影的，一停内网应用，系统马上就缓过来了。

刚上网就发现马工也在网上，我问他在做什么，他说下午他值班，万科自己回家了，不过还是让他盯到5点。小马自己一个人在青岛，也没什么朋友，加班挣点加班费还是挺不错的。正和小马聊着，Richard通过MSN发了一条消息：“Hi,老兄，今天系统十分完美”。

Richard 用了perfect，足以表明他现在的心情。Richard认为今天的性能情况和他昨天的动作有很大关系。我想给他泼泼冷水，不过费了半天脑子，也没有想好怎么说。“5.1长假”这个词汇我用了好几个英文单词去描述，他还是没有听明白什么意思。后来我只好解释说今天就类似他们西方的圣诞新年假期一样，很多业务人员都休息去了，所以今天的系统负载只是平时的60-70%。总算，Richard听明白了我要表达的意思，不过他还是认为优化获得了阶段性的成果。

我想我也很难说服他，老外都是一根筋，你很难去说服他。只有到5月8日，系统真正体现出了压力，才能让他明白老万他们这个项目的优化并不像他想象的那么简单。以今天的业务量，CPU资源肯定会出现瓶颈

©作者：eygle 发布在 eygle.com

Oracle 10g可以使用LOGMNR在线分析和挖掘日志，使用当前在线的数据字典，非常方便。

首先执行一些DDL或DML操作：

SQL> connect eygle/eygle
Connected.

SQL> alter system switch logfile;

System altered.

SQL> create table eygle as select * from dba_users;

Table created.

SQL> set autotrace on
SQL> select count(*) from eygle;

  COUNT(*)
----------
        19


Execution Plan
----------------------------------------------------------
Plan hash value: 3602634261

--------------------------------------------------------------------
| Id  | Operation          | Name  | Rows  | Cost (%CPU)| Time     |
--------------------------------------------------------------------
|   0 | SELECT STATEMENT   |       |     1 |     3   (0)| 00:00:01 |
|   1 |  SORT AGGREGATE    |       |     1 |            |          |
|   2 |   TABLE ACCESS FULL| EYGLE |    19 |     3   (0)| 00:00:01 |
--------------------------------------------------------------------

Note
-----
   - dynamic sampling used for this statement


Statistics
----------------------------------------------------------
          5  recursive calls
          0  db block gets
          7  consistent gets
          5  physical reads
          0  redo size
        411  bytes sent via SQL*Net to client
        400  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

然后可以执行LOGMNR解析工作：

SQL> connect / as sysdba
Connected.
SQL> select * from v$log where status='CURRENT';

    GROUP#    THREAD#  SEQUENCE#      BYTES    MEMBERS ARC STATUS           FIRST_CHANGE# FIRST_TIME
---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- ------------
         2          1        100   52428800          1 NO  CURRENT               12729697 01-JUL-09

SQL> SELECT MEMBER from v$logfile where group#=2;

MEMBER
------------------------------------------------------------------------------------------------------------------------
/opt/oracle/oradata/mmstest/redo02.log

SQL> exec dbms_logmnr.add_logfile('/opt/oracle/oradata/mmstest/redo02.log',dbms_logmnr.new);

PL/SQL procedure successfully completed.

SQL> exec dbms_logmnr.start_logmnr(options=>dbms_logmnr.dict_from_online_catalog);

PL/SQL procedure successfully completed.

SQL> select count(*) from v$logmnr_contents;

  COUNT(*)
----------
       136
SQL> select sql_redo from v$logmnr_contents;

SQL_REDO
------------------------------------------------------------------------------------------------------------------------
set transaction read write;
insert into "SYS"."OBJ$"("OBJ#","DATAOBJ#","OWNER#","NAME","NAMESPACE","SUBNAME","TYPE#","CTIME","MTIME","STIME","STATUS
","REMOTEOWNER","LINKNAME","FLAGS","OID$","SPARE1","SPARE2","SPARE3","SPARE4","SPARE5","SPARE6") values ('25847','25847'
,'31','EYGLE','1',NULL,'2',TO_DATE('01-JUL-09', 'DD-MON-RR'),TO_DATE('01-JUL-09', 'DD-MON-RR'),TO_DATE('01-JUL-09', 'DD-
MON-RR'),'1',NULL,NULL,'0',NULL,'6','1',NULL,NULL,NULL,NULL);

set transaction read write;
update "SYS"."CON$" set "CON#" = '10823' where "CON#" = '10822' and ROWID = 'AAAAAcAABAAAACqAAM';

commit;
set transaction read write;

SQL_REDO
------------------------------------------------------------------------------------------------------------------------
update "SYS"."CON$" set "CON#" = '10824' where "CON#" = '10823' and ROWID = 'AAAAAcAABAAAACqAAM';

commit;
set transaction read write;
update "SYS"."CON$" set "CON#" = '10825' where "CON#" = '10824' and ROWID = 'AAAAAcAABAAAACqAAM';

commit;
set transaction read write;
update "SYS"."CON$" set "CON#" = '10826' where "CON#" = '10825' and ROWID = 'AAAAAcAABAAAACqAAM';

commit;


set transaction read write;
update "SYS"."CON$" set "CON#" = '10827' where "CON#" = '10826' and ROWID = 'AAAAAcAABAAAACqAAM';

commit;
set transaction read write;
update "SYS"."CON$" set "CON#" = '10828' where "CON#" = '10827' and ROWID = 'AAAAAcAABAAAACqAAM';

commit;
set transaction read write;
update "SYS"."CON$" set "CON#" = '10829' where "CON#" = '10828' and ROWID = 'AAAAAcAABAAAACqAAM';

commit;
create table eygle as select * from dba_users;
set transaction read write;


Unsupported
update "SYS"."TSQ$" set "TS#" = '0', "GRANTOR#" = '43080', "BLOCKS" = '0', "MAXBLOCKS" = '0', "PRIV1" = '0', "PRIV2" = '
0' where "TS#" = '0' and "GRANTOR#" = '43072' and "BLOCKS" = '0' and "MAXBLOCKS" = '0' and "PRIV1" = '0' and "PRIV2" = '
0' and ROWID = 'AAAAAKAABAAAABbAAF';

commit;
set transaction read write;
SQL> exec dbms_logmnr.end_logmnr

PL/SQL procedure successfully completed.

很多时候拿LOGMNR来追踪一些误操作是很有效的方式，甚至在自己定制的数据同步中，LOGMNR也大有可为。

相关文章|Related Articles

• Streams散记之一-如何清除流配置
  
• Archive Log Current及Archive Log路线图
  
• 如何更改监听器日志文件名称
  
• 获得Redo Block Size的非典型方法
  
• 隐含参数_disable_logging的几点说明
  

评论数量(0)|Add Comments

本文网址：http://www.eygle.com/archives/2009/07/oracle10g_logmnr_easyuse.html

    这几天有几个分区表上的SQL执行计划不正常, 感觉上不应当, 已经设置了几个容易引起优化器选错执行计划的参数了.

ALTER SYSTEM SET OPTIMIZER_DYNAMIC_SAMPLING=0;
ALTER SYSTEM SET "_optim_peek_user_binds"=false;

    按照现行的表分析原则, 只统计了表的全局索引, 不统计表分区上的索引, 因为分区会有增减操作, 不是每个分区都有数据, 也没有定下来要经常分析表, 而是分析后如果不出问题就不再分析. 现在SQL走错了, 可能的原因有什么呢? 重新分析一下不行, 看了一下执行计划, 发现全表扫描的COST值很底, 估计是用了分区上的统计信息了, 于是手动将全局的统计信息复制到每一个分区上得以解决.

    为了得到原因, 回顾了一下当时的SQL, 发现有一个特征, 就是出问题的SQL都能定位到某个分区或某些分区, 今天就模拟了一下情况, 先只有全局统计信息. 首先用分区列范围查询, 去试了一下, 发现用的是分区级的统计信息.

SQL> select * from database_perf_statistics
  2  where day > sysdate - 100 and day < sysdate + 300;

----------------------------------------------------------------
| Id  | Operation                 | Cost (%CPU)| Pstart| Pstop |
----------------------------------------------------------------
|   0 | SELECT STATEMENT          |     3   (0)|       |       |
|*  1 |  FILTER                   |            |       |       |
|   2 |   PARTITION RANGE ITERATOR|     3   (0)|   KEY |   KEY |
|*  3 |    TABLE ACCESS FULL      |     3   (0)|   KEY |   KEY |
----------------------------------------------------------------

    然后全表扫描, 涉及所有的分区时, 用的是全局的统计信息.

SQL> select * from database_perf_statistics;
             
----------------------------------------------------------
| Id  | Operation           | Cost (%CPU)| Pstart| Pstop |
----------------------------------------------------------
|   0 | SELECT STATEMENT    |  2196   (1)|       |       |
|   1 |  PARTITION RANGE ALL|  2196   (1)|     1 |     4 |
|   2 |   TABLE ACCESS FULL |  2196   (1)|     1 |     4 |
----------------------------------------------------------

    再测试一个开包的查询条件, 发现用的也是分区的统计信息.

SQL> select * from database_perf_statistics where day > sysdate - 100;

---------------------------------------------------------------
| Id  | Operation                | Cost (%CPU)| Pstart| Pstop |
---------------------------------------------------------------
|   0 | SELECT STATEMENT         |     3   (0)|       |       |
|   1 |  PARTITION RANGE ITERATOR|     3   (0)|   KEY |     4 |
|*  2 |   TABLE ACCESS FULL      |     3   (0)|   KEY |     4 |
---------------------------------------------------------------

    重新设置了一下各分区的统计信息, 再验证一下上面的SQL的COST值, 就确定了是这个原因引起的, 需要更改一下我们的分析策略了.

Relative Posts:

• 2009/06/25 -- oramon如何收集V$SYSTEM_EVENT数据? (0)
• 2009/06/25 -- oramon如何从V$SESSION收集性能数据? (0)
• 2009/06/24 -- oramon如何从V$SYSSTAT收集性能数据? (1)
• 2009/05/22 -- 从oramon新报警中受益 (1)
• 2009/05/21 -- 用oramon的数据进行报警 (3)
• 2009/05/19 -- 新版oramon正式上线 (4)
• 2009/05/08 -- 分析性能数据之二 (3)
• 2009/05/08 -- 分析性能数据之一 (0)

©作者：eygle 发布在 eygle.com

近日，恩墨科技为ChinaCahce提供了紧急数据库援助服务。

ChinaCache成立于1998年，是中国领先的专业CDN服务提供商，向客户提供全方位网络内容快速分布解决方案。作为2000年就获信产部许可的 CDN服务提供商，目前ChinaCache在全国100多个大中城市拥有近500个节点，覆盖中国电信、中国网通、中国移动、中国联通、中国铁通和中国 教育科研网等各大运营商。2007年，ChinaCache北美公司的建立，使ChinaCache网络覆盖了北美及亚太地区。

ChinaCahce与恩墨科技长期以来一直保持着良好的合作与联系，最近的一次意外断电事故，使得客户的数据库系统受到了影响，在经过了数小时的排查之后，客户请求我们介入协助寻求解决方案，在经过了全面的思考和一系列的尝试之后，我们成功的帮助用户恢复了数据库服务，使得TB级数据库能够再次提供服务。

感谢用户的信赖和支持，希望我们的服务能够继续为用户创造价值！

相关文章|Related Articles

• 恩墨科技为中电财提供顾问咨询及容灾服务
  
• 恩墨科技成功签约北京资和信集团
  
• 恩墨科技为中国国际电子商务中心提供服务
  
• 恩墨科技成功签下第一个企业客户
  
• 北京恩墨科技有限公司 即日宣告成立
  

评论数量(3)|Add Comments

本文网址：http://www.eygle.com/archives/2009/06/enmotech_chinacache.html

对index直接rebuild的时候一定会是index fast full scan吗？

呵呵，当然不是，我们来看一个反例：

 

SQL> create table testindex

  2  (pvalue varchar2(1),

  3   pkey number)

  4  partition by range (pkey)

  5  (

  6  partition testindex_part_1 values less than (2)

  7  tablespace TESTTBS1,

  8  partition testindex_part_2 values less than (3)

  9  tablespace TESTTBS2

 10  )

 11  enable row movement;

 

Table created

 

SQL> insert into testindex values('a',1);

 

1 row inserted

 

SQL> insert into testindex values('b',1);

 

1 row inserted

 

SQL> insert into testindex values('c',2);

 

1 row inserted

 

SQL> insert into testindex values('d',2);

 

1 row inserted

 

SQL> commit;

 

Commit complete

 

SQL> create index idx_testindex_pvalue on testindex(pvalue);

 

Index created

 

我把pvalue='a'的那条记录的pkey由1改为2，这时候因为上述分区在不同的表空间下，所以索引idx_testindex_pvalue中对应于键值为'a'的global rowid一定会变。

 

好了，我们来验证一下：

未改之前：

row#0[8017] flag: -----, lock: 0

col 0; len 1; (1):  61

col 1; len 10; (10):  00 01 50 dd 21 80 07 99 00 00

row#1[8002] flag: -----, lock: 0

col 0; len 1; (1):  62

col 1; len 10; (10):  00 01 50 dd 21 80 07 99 00 01

row#2[7987] flag: -----, lock: 0

col 0; len 1; (1):  63

col 1; len 10; (10):  00 01 50 de 22 00 11 19 00 00

row#3[7972] flag: -----, lock: 0

col 0; len 1; (1):  64

col 1; len 10; (10):  00 01 50 de 22 00 11 19 00 01

 

SQL> update testindex set pkey=2 where pvalue='a';

 

1 row updated

 

SQL> commit;

 

Commit complete

 

SQL> select * from testindex;

 

PVALUE       PKEY

------ ----------

b               1

c               2

d               2

a               2

 

改过之后：

row#0[8017] flag: ---D-, lock: 2

col 0; len 1; (1):  61

col 1; len 10; (10):  00 01 50 dd 21 80 07 99 00 00

row#1[7957] flag: -----, lock: 2

col 0; len 1; (1):  61

col 1; len 10; (10):  00 01 50 de 22 00 11 19 00 02

row#2[8002] flag: -----, lock: 0

col 0; len 1; (1):  62

col 1; len 10; (10):  00 01 50 dd 21 80 07 99 00 01

row#3[7987] flag: -----, lock: 0

col 0; len 1; (1):  63

col 1; len 10; (10):  00 01 50 de 22 00 11 19 00 00

row#4[7972] flag: -----, lock: 0

col 0; len 1; (1):  64

col 1; len 10; (10):  00 01 50 de 22 00 11 19 00 01

这里我们可以从trace文件中看到索引idx_testindex_pvalue中对于键值为'a'的global rowid已经由00 01 50 dd 21 80 07 99 00 00变成了00 01 50 de 22 00 11 19 00 02。

 

现在我们重建上述index，再来验证将上述index设为unusable的情况下索引idx_testindex_pvalue中对应于键值为'a'的global rowid是否会变？

SQL> update testindex set pkey=1 where pvalue='a';

 

1 row updated

 

SQL> commit;

 

Commit complete

 

SQL> select * from testindex;

 

PVALUE       PKEY

------ ----------

b               1

a               1

c               2

d               2

 

SQL> drop index idx_testindex_pvalue;

 

Index dropped

 

SQL> create index idx_testindex_pvalue on testindex(pvalue);

 

Index created

 

未改之前：

row#0[8017] flag: -----, lock: 0

col 0; len 1; (1):  61

col 1; len 10; (10):  00 01 50 dd 21 80 07 99 00 02

row#1[8002] flag: -----, lock: 0

col 0; len 1; (1):  62

col 1; len 10; (10):  00 01 50 dd 21 80 07 99 00 01

row#2[7987] flag: -----, lock: 0

col 0; len 1; (1):  63

col 1; len 10; (10):  00 01 50 de 22 00 11 19 00 00

row#3[7972] flag: -----, lock: 0

col 0; len 1; (1):  64

col 1; len 10; (10):  00 01 50 de 22 00 11 19 00 01

 

SQL> alter index idx_testindex_pvalue unusable;

 

Index altered

 

SQL> update testindex set pkey=2 where pvalue='a';

 

update testindex set pkey=2 where pvalue='a'

 

ORA-01502: index 'DRAS.IDX_TESTINDEX_PVALUE' or partition of such index is in unusable state

 

SQL> ALTER SESSION SET SKIP_UNUSABLE_INDEXES = TRUE;

 

Session altered

 

SQL> update testindex set pkey=2 where pvalue='a';

 

1 row updated

 

SQL> commit;

 

Commit complete

 

SQL> select * from testindex;

 

PVALUE       PKEY

------ ----------

b               1

c               2

d               2

a               2

 

改过之后：

row#0[8017] flag: -----, lock: 0

col 0; len 1; (1):  61

col 1; len 10; (10):  00 01 50 dd 21 80 07 99 00 02

row#1[8002] flag: -----, lock: 0

col 0; len 1; (1):  62

col 1; len 10; (10):  00 01 50 dd 21 80 07 99 00 01

row#2[7987] flag: -----, lock: 0

col 0; len 1; (1):  63

col 1; len 10; (10):  00 01 50 de 22 00 11 19 00 00

row#3[7972] flag: -----, lock: 0

col 0; len 1; (1):  64

col 1; len 10; (10):  00 01 50 de 22 00 11 19 00 01

可以从结果里看到，这时候当我将上述index设为unusable的情况下索引idx_testindex_pvalue中对应于键值为'a'的global rowid没有变！

 

这时候如果我们rebuild online的话是能修正上述错误的，因为rebuild online走的是全表扫描。但是如果我们只是rebuild，因为rebuild走的是index fast full scan，那这里oracle能正确的修正上述global rowid的错误吗？我们来验证一下：

SQL> alter index idx_testindex_pvalue rebuild;

 

Index altered

 

rebuild之后：

row#0[8017] flag: -----, lock: 0

col 0; len 1; (1):  61

col 1; len 10; (10):  00 01 50 de 22 00 11 19 00 03

row#1[8002] flag: -----, lock: 0

col 0; len 1; (1):  62

col 1; len 10; (10):  00 01 50 dd 21 80 07 99 00 01

row#2[7987] flag: -----, lock: 0

col 0; len 1; (1):  63

col 1; len 10; (10):  00 01 50 de 22 00 11 19 00 00

row#3[7972] flag: -----, lock: 0

col 0; len 1; (1):  64

col 1; len 10; (10):  00 01 50 de 22 00 11 19 00 01

从结果里我们可以看到，即便我这里用的是rebuild，oracle这里也已经将上述global rowid的错误修正。

 

为什么会这样？

很简单，因为在index是unusable的情况下，即使是直接rebuild，oracle这里也会走全表扫描。

SQL> select status from dba_indexes where index_name='IDX_TESTINDEX_PVALUE';

 

STATUS

--------

VALID

 

SQL> explain plan for alter index idx_testindex_pvalue rebuild;

 

Explained

 

SQL> select * from table(dbms_xplan.display);

 

PLAN_TABLE_OUTPUT

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

| Id  | Operation              |  Name                 | Rows  | Bytes | Cost  |

--------------------------------------------------------------------------------

|   0 | ALTER INDEX STATEMENT  |                       |  9802 | 19604 |    13 |

|   1 |  INDEX BUILD NON UNIQUE| IDX_TESTINDEX_PVALUE  |       |       |       |

|   2 |   SORT CREATE INDEX    |                       |  9802 | 19604 |       |

|   3 |    INDEX FAST FULL SCAN| IDX_TESTINDEX_PVALUE  |  9802 | 19604 |       |

--------------------------------------------------------------------------------

Note: cpu costing is off, PLAN_TABLE' is old version

 

11 rows selected

 

SQL> alter index idx_testindex_pvalue unusable;

 

Index altered

 

SQL> select status from dba_indexes where index_name='IDX_TESTINDEX_PVALUE';

 

STATUS

--------

UNUSABLE

 

SQL> explain plan for alter index idx_testindex_pvalue rebuild;

 

Explained

 

SQL> select * from table(dbms_xplan.display);

 

PLAN_TABLE_OUTPUT

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

| Id  | Operation              |  Name                 | Rows  | Bytes | Cost  |

--------------------------------------------------------------------------------

|   0 | ALTER INDEX STATEMENT  |                       |  9802 | 19604 |    13 |

|   1 |  INDEX BUILD NON UNIQUE| IDX_TESTINDEX_PVALUE  |       |       |       |

|   2 |   SORT CREATE INDEX    |                       |  9802 | 19604 |       |

|   3 |    PARTITION RANGE ALL |                       |       |       |       |

|   4 |     TABLE ACCESS FULL  | TESTINDEX             |  9802 | 19604 |    13 |

--------------------------------------------------------------------------------

Note: cpu costing is off, PLAN_TABLE' is old version

 

12 rows selected

 

    用oramon将数据库的主要负载信息收集到了性能数据库, 用DataReport去显示这些性能数据时, 发现要写很多个SQL语句, 要不同的列显示一次, 例如要显示三幅图片(平均Load值, 用户CPU消耗, SQL执行次数)就得执行三个SQL.

WEBCHART.QUERY_1=SELECT TIME, LOAD FROM DATABASE_LOAD ...
WEBCHART.QUERY_2=SELECT TIME, CPUUSR FROM DATABASE_LOAD ...
WEBCHART.QUERY_3=SELECT TIME, EXECS FROM DATABASE_LOAD ...

    其实DATABASE_LOAD是一个宽表, 可以一次查询出多个列的数据来, 几个图片可以共享一次查询的结果, 就可以减少数据库的执行次数, 提高页面访问速度. 如下所示, 只需要指定某个查询的SQL语句为减号.

WEBCHART.XCOL=TIME
WEBCHART.QUERY_1=SELECT TIME, LOAD, CPUUSR, EXECS
  FROM DATABASE LOAD ...
WEBCHART.YCOL_1=LOAD
WEBCHART.QUERY_2=-
WEBCHART.YCOL_2=CPUUSR
WEBCHART.QUERY_3=-
WEBCHART.YCOL_3=EXECS

    最近做了一次大的数据库改造, 用DataReport分析性能数据比较繁烦, 因此才注意到这个方面的性能提升.

Relative Posts:

• 2009/04/20 -- 设定WebChart多行值 (0)
• 2009/04/01 -- WebChart的颜色定制 (0)
• 2009/06/04 -- 如何打开WebChart的链接? (0)
• 2009/06/03 -- WebChart的CLOB支持 (0)
• 2009/06/03 -- 添加WebChart超文本链接 (1)
• 2009/03/18 -- 配置Tomcat的HTTPS访问 (1)
• 2009/03/17 -- MySQL上的WebChart (0)
• 2009/03/12 -- WebChart密码加密功能 (4)

第一次遇到这个问题是在2006年，后来陆陆续续的遇到过好几次，都是在9205的版本上。

可是一直没有在自己的blog上好好总结一下。我以为自己写过了，今天想找给别人时才发现没有写过。

数据库版本当时为9205。问题表现为大量的active session等待在mod为6的HW enqueue上。

当前获得enqueue的session执行非常慢，平时小于一秒钟的DML操作现在大约需要几十秒钟才能完成。

查询v$lock得到下面的信息：

SID TY ID1 ID2 LMODE REQUEST CTIME BLOCK
———- — ———- ———- ———- ———- ———- ———-
3575 HW 16 159461642 6 0 18 1
3546 HW 16 159461642 0 6 257 0
3542 HW 16 159461642 0 6 348 0
3468 HW 16 159461642 0 6 31 0
3329 HW 16 159461642 0 6 46 0
2634 HW 16 159461642 0 6 171 0
2565 HW 16 159461642 0 6 94 0
2532 HW 16 159461642 0 6 77 0
2497 HW 16 159461642 0 6 304 0
2179 HW 16 159461642 0 6 386 0
1972 HW 16 159461642 0 6 116 0
1927 HW 16 159461642 0 6 183 0
1777 HW 16 159461642 0 6 209 0
1690 HW 16 159461642 0 6 249 0
1637 HW 16 159461642 0 6 164 0
1616 HW 16 159461642 0 6 17 0
1601 HW 16 159461642 0 6 109 0
1353 HW 16 159461642 0 6 134 0
1236 HW 16 159461642 0 6 320 0
1218 HW 16 159461642 0 6 64 0
1163 HW 16 159461642 0 6 234 0
1150 HW 16 159461642 0 6 291 0
1082 HW 16 159461642 0 6 150 0
1074 HW 16 159461642 0 6 219 0
987 HW 16 159461642 0 6 195 0
713 HW 16 159461642 0 6 374 0
683 HW 16 159461642 0 6 331 0
672 HW 16 159461642 0 6 275 0
535 HW 16 159461642 0 6 361 0
404 HW 16 159461642 0 6 400 0

ID2是DBA,我们可以用“oracle DBA convertor”工具得到相应的File#和Block#

SQL> !dba 159461642

Oracle DBA convertor

by Stephan Haisley, Center Of Expertise, Oracle Corporation
RDBA: 0×981310a (159461642) File#: 38 Block#: 78090

SQL> select segment_name,partition_name,header_file,header_block from
SQL> dba_segments where segment_name=’SYS_LOB0000009458C00013$$’;

SEGMENT_NAME PARTITION_NAME HEADER_FILE HEADER_BLOCK

—————————————- —————————— ———– ————
SYS_LOB0000009458C00013$$ SYS_LOB_P19 38 65289
SYS_LOB0000009458C00013$$ SYS_LOB_P20 46 52489
SYS_LOB0000009458C00013$$ SYS_LOB_P21 38 78089 — 78090 = 78089+1

然后你会发现这个Block并不是Lob segment header，而是Lob segment header后面一个block。注意这一点非常重要，这是这一类问题的标准特征。

如果等待的block是segment header，那么你遇到的不是本文所描述的问题。

一般的HW enqueue发生在segment header上，而后面这个block是什么呢？

说到这个block，要从Lob segment的undo方式说起。Lob segment将old image存放在自己的segment中，而不是undo segment中。
这块存放old image的空间的大小有两种方式来定义，pctversion或者是retention。
对此不熟悉的同学可以参考我以前的两篇文章当ORA-01555遇到了LOB和PCTVERSION or RETENTION?

而这个block就是用来记录这些可以被回收的old image blocks，采用bitmap方式存储。

当可回收的old image space超过PCTVERSION定义的百分比时，新增加的数据可以从这些old image space中回收。

但是oracle在回收时有两个bug：

Bug 4867884(Note:4867884.8) - Lob HW lock contention with space reclaimation — fixed in 10.1.0.6, 10.2.0.3, 11g (Future version)
Bug 4113930(Note:4113930.8) - Space reclaimation shows HW enqueue contention with concurrent insert of LOBs — fixed in 9.2.0.8 , 10.1.0.5 , 10.2.0.1

触发这个bug有两个条件
1. 可回收的old image space超过PCTVERSION定义的百分比
2. concurrent transaction超过一定的数值，具体的值不清楚，我遇到问题时的concurrent transaction数目大约为30

所以解决这个问题就从上面两点来入手。

1.

最快解决问题的方法就是调大pctversion。

dump segment header后的那个block（38，78090）
alter system dump datafile 38 block 78090;

找到一行free blocks:10109615，根据这个可以算出free blocks所占的百分比，然后调整pctversion使其大于该百分比，这样就不会有回收空间的动作。
这一方法可以很快的解决问题，就是比较浪费空间。如果有维护的时间，可以通过move的方式来回收空间。

2.

从segment上的并发数入手，例如减少并发量，或者hash partition table使每个segment上面的并发数减少

©作者：eygle 发布在 eygle.com

近日，恩墨科技为中国电力财务有限公司提供数据库容灾环境实施及顾问咨询工作。

近年来，国内越来越多的公司开始认识到数据安全的重要，以各种手段和方式开始实施数据库安全架构。在众多的可选方案中，Oracle的DataGuard技术以其成本低、可用性及安全性能够满足绝大多数需求成为了很多企业的首选。在下个月即将发布的Oracle Database 11gR2版本中，Oracle Active DataGuard技术将得到进一步增强，可以预计，这一新版的的卓越新特性将为Oracle带来更多的客户。

中国电力财务有限公司（以下简称中国电财）成立于1993年，是经中国银行业监督管理委员会批准的一家全国性非银行金融机构。中国电财注册资本金50亿元，由国家电网公司控股、各省（市、区）电力公司等50家电力企、事业单位共同参股组建。经银监会批准，中国电财拥有东北、西北、华中和华东等多家区域性分公司，注册资本金、资产规模、利润总额等多项指标在国内财务公司行业中均名列前茅，在电力和金融行业树立了良好的企业形象，当选为中国财务公司协会理事长单位。

客户的数据库采用Oracle Database 10g RAC架构，异地容灾以Oracle DataGuard技术为主体实现。

感谢用户及合作伙伴用友公司的信赖与支持，希望稳健架构的实施可以帮助用户实现数据安全和业务连续性的需要。

相关文章|Related Articles

• 恩墨科技为ChinaCache提供紧急救援服务
  
• 恩墨科技成功签约北京资和信集团
  
• 恩墨科技为中国国际电子商务中心提供服务
  
• 恩墨科技成功签下第一个企业客户
  
• 北京恩墨科技有限公司 即日宣告成立
  

评论数量(1)|Add Comments

本文网址：http://www.eygle.com/archives/2009/06/enmotech_zdc.html

在"利用10053分析执行计划的一个例子"这篇文章里，我提到----"这个默认值不是固定的，感觉这里这个默认值取决于Blks"。

 

当时为什么这么说是因为我看到的所有关于10053的文章中都或直接或隐约的指出当没有统计信息的时候，oracle是根据Blks来计算默认的统计信息。

 

呵呵，这个观点误导了我，我们来看一下真相是什么。

 

SQL> create table tb0624 (type number,ts timestamp) pctfree 90;

 

Table created

 

SQL> begin

  2  for i in 1..10000 loop

  3  insert into tb0624 values (1,sysdate);

  4  insert into tb0624 values (3,sysdate);

  5  end loop;

  6  commit;

  7  end;

  8  /

 

PL/SQL procedure successfully completed

 

SQL> begin

  2  for i in 1..10 loop

  3  insert into tb0624 values (2,sysdate);

  4  end loop;

  5  commit;

  6  end;

  7  /

 

PL/SQL procedure successfully completed

 

SQL> exec dbms_stats.gather_table_stats('IPRA','TB0624',CASCADE=>FALSE,METHOD_OPT => 'FOR ALL INDEXED COLUMNS')

 

PL/SQL procedure successfully completed

 

SQL> SELECT NUM_ROWS,BLOCKS,AVG_ROW_LEN FROM USER_TABLES WHERE TABLE_NAME='TB0624';

 

  NUM_ROWS     BLOCKS AVG_ROW_LEN

---------- ---------- -----------

     20010        438          14

 

SQL> create index idx_type on tb0624(type);

 

Index created

 

这里我们分别修改NUM_ROWS，BLOCKS和AVG_ROW_LEN，以便来看看ix_sel到底取决于哪个值。

 

1、修改#Blks后的10053：

SQL> exec dbms_stats.set_table_stats(ownname => 'IPRA',tabname => 'TB0624',numblks => 538);

 

PL/SQL procedure successfully completed

 

SQL> SELECT NUM_ROWS,BLOCKS,AVG_ROW_LEN FROM USER_TABLES WHERE TABLE_NAME='TB0624';

 

  NUM_ROWS     BLOCKS AVG_ROW_LEN

---------- ---------- -----------

     20010        538          14

 

***************************************

BASE STATISTICAL INFORMATION

***********************

Table Stats::

  Table: TB0624  Alias: TB0624

    #Rows: 20010  #Blks:  538  AvgRowLen:  14.00

Index Stats::

  Index: IDX_TYPE  Col#: 1

    LVLS: 1  #LB: 40  #DK: 3  LB/K: 13.00  DB/K: 267.00  CLUF: 801.00

***************************************

SINGLE TABLE ACCESS PATH

  Column (#1): TYPE(NUMBER)  NO STATISTICS (using defaults)

    AvgLen: 22.00 NDV: 625 Nulls: 0 Density: 0.0015992

  Table: TB0624  Alias: TB0624    

    Card: Original: 20010  Rounded: 200  Computed: 200.10  Non Adjusted: 200.10

  Access Path: TableScan

    Cost:  121.28  Resp: 121.28  Degree: 0

      Cost_io: 119.00  Cost_cpu: 7837335

      Resp_io: 119.00  Resp_cpu: 7837335

  Access Path: index (AllEqGuess)

    Index: IDX_TYPE

    resc_io: 17.00  resc_cpu: 151884

    ix_sel: 0.004  ix_sel_with_filters: 0.004

    Cost: 17.04  Resp: 17.04  Degree: 1

  Best:: AccessPath: IndexRange  Index: IDX_TYPE

         Cost: 17.04  Degree: 1  Resp: 17.04  Card: 200.10  Bytes: 0

可以看到，当我在只改变#Blks的情况下，ix_sel的值未变。

 

2、修改#Rows后的10053

SQL> exec dbms_stats.set_table_stats(ownname => 'IPRA',tabname => 'TB0624',numblks => 438,numrows => 30010);

 

PL/SQL procedure successfully completed

 

SQL> SELECT NUM_ROWS,BLOCKS,AVG_ROW_LEN FROM USER_TABLES WHERE TABLE_NAME='TB0624';

 

  NUM_ROWS     BLOCKS AVG_ROW_LEN

---------- ---------- -----------

     30010        438          14

 

***************************************

BASE STATISTICAL INFORMATION

***********************

Table Stats::

  Table: TB0624  Alias: TB0624

    #Rows: 30010  #Blks:  438  AvgRowLen:  14.00

Index Stats::

  Index: IDX_TYPE  Col#: 1

    LVLS: 1  #LB: 40  #DK: 3  LB/K: 13.00  DB/K: 267.00  CLUF: 801.00

***************************************

SINGLE TABLE ACCESS PATH

  Column (#1): TYPE(NUMBER)  NO STATISTICS (using defaults)

    AvgLen: 22.00 NDV: 938 Nulls: 0 Density: 0.0010663

  Table: TB0624  Alias: TB0624    

    Card: Original: 30010  Rounded: 300  Computed: 300.10  Non Adjusted: 300.10

  Access Path: TableScan

    Cost:  100.66  Resp: 100.66  Degree: 0

      Cost_io: 98.00  Cost_cpu: 9127191

      Resp_io: 98.00  Resp_cpu: 9127191

  Access Path: index (AllEqGuess)

    Index: IDX_TYPE

    resc_io: 18.00  resc_cpu: 173806

    ix_sel: 0.005999  ix_sel_with_filters: 0.005999

    Cost: 18.05  Resp: 18.05  Degree: 1

  Best:: AccessPath: IndexRange  Index: IDX_TYPE

         Cost: 18.05  Degree: 1  Resp: 18.05  Card: 300.10  Bytes: 0

可以看到，当我在只改变#ROWS的情况下，ix_sel的值已经发生了改变。

 

3、修改AvgRowLen后的10053：

SQL> exec dbms_stats.set_table_stats(ownname => 'IPRA',tabname => 'TB0624',numblks => 438,numrows => 20010,avgrlen => 24);

 

PL/SQL procedure successfully completed

 

SQL> SELECT NUM_ROWS,BLOCKS,AVG_ROW_LEN FROM USER_TABLES WHERE TABLE_NAME='TB0624';

 

  NUM_ROWS     BLOCKS AVG_ROW_LEN

---------- ---------- -----------

     20010        438          24

 

***************************************

BASE STATISTICAL INFORMATION

***********************

Table Stats::

  Table: TB0624  Alias: TB0624

    #Rows: 20010  #Blks:  438  AvgRowLen:  24.00

Index Stats::

  Index: IDX_TYPE  Col#: 1

    LVLS: 1  #LB: 40  #DK: 3  LB/K: 13.00  DB/K: 267.00  CLUF: 801.00

***************************************

SINGLE TABLE ACCESS PATH

  Column (#1): TYPE(NUMBER)  NO STATISTICS (using defaults)

    AvgLen: 22.00 NDV: 625 Nulls: 0 Density: 0.0015992

  Table: TB0624  Alias: TB0624    

    Card: Original: 20010  Rounded: 200  Computed: 200.10  Non Adjusted: 200.10

  Access Path: TableScan

    Cost:  100.08  Resp: 100.08  Degree: 0

      Cost_io: 98.00  Cost_cpu: 7125191

      Resp_io: 98.00  Resp_cpu: 7125191

  Access Path: index (AllEqGuess)

    Index: IDX_TYPE

    resc_io: 17.00  resc_cpu: 151884

    ix_sel: 0.004  ix_sel_with_filters: 0.004

    Cost: 17.04  Resp: 17.04  Degree: 1

  Best:: AccessPath: IndexRange  Index: IDX_TYPE

         Cost: 17.04  Degree: 1  Resp: 17.04  Card: 200.10  Bytes: 0

可以看到，当我在只改变AvgRowLen的情况下，ix_sel的值未变。

 

从上述测试中我们可以很清晰的得出如下结论：

在无统计信息的情况下，ix_sel的值取决于#Rows，而不是取决于#Blks。

Fenng(dbanotes) posted a photo:

GreenPlum 还是给DB集群带来一些新的思路和可能的。

或许，DBA 真的不应该只关注关系数据库了。

• MySQL5.0.3开始,VARCHAR的最大存储限制已经更改为字节数，且不再存在单独的固定限制，而受到单条记录除TEXT和BLOB类型字段外最大长度不超过65536 Bytes的限制。定义的M仍是字符数，所以定义后的VARCHAR字段实际最大可存放数据长度与字符集相关的。 #
• RT: @fireshort: mysql的varchar是从哪个版本开始储存最多65535个字符的？一直记得是只能存储最多255个字符的啊。[5.0.3] #
• 今年到目前起床最早的一个周末，7:30 醒！ #
• RT: @chagel: rt @virushuo上海塌房事件直播 http://is.gd/1fi3z [这幢房子倒得还真是很整齐啊，幸好还没有人入住，否则...] #
• RT:@kimihuang: 为了纪念MJ，今晚晚上去跑西湖了，从北山路开始，苏堤一个往返…在上白堤…在edushi.com上测量了一下，刚好10公里 (via @karlzheng)关键是用多少时间。10公里不多，我晨跑也有5公里呢[锻炼身体的长跑在于慢而久，而不是快] #
• RT: @eygle: 据说 Oracle Database 11gr2下个月亚洲将举行新闻发布会 #
• RT: @esunchien: 迈克尔·杰克逊的唱片和传记要大卖了。 #
• RT: @esunchien: … RT @momoran80: RT: @huairen: RT @virushuo: 强烈谴责百度 http://is.gd/1cKCd 【未成年人请勿点击，成人教育图片，当然出品人：更懂中文的那口子】[很强大] #
• RT:@Fenng:方滨兴，首先提出了建设国家网络与信息安全基础设施的理念，并组织研制、实现了相应的系统…在信息安全理论方面，将涉及了物理、运行(网络安全）、数据（狭义的信息安全）及内容的信息安全概念给出了统一的形式化定义…[是要人肉么？] #
• RT: @Fenng: 寻找 Zion http://www.dbanotes.net/review/zion.html [这个值得一推] #
• RT: @niedongming: 刚才求证了下，原来我们公司自己架了DNS服务器，直接把google访问地址解析到了访问IP上去了。［造福大家啊，值得称颂］ #
• RT: @smallfish_xy: RT: @sky000: 太阳… Linux下通过Pidgin上msn也能中毒？【这个要顶，没遇见过】[好几个人反应总收到我MSN发出的减肥广告信息。。。] in reply to smallfish_xy #
• 太阳… Linux下通过Pidgin上msn也能中毒？ #

Powered by Twitter Tools.

---

作者： Sky.Jian  发布在：www.jianzhaoyang.com  欢迎 订阅本站Feed
Copyright © 2004-2008， 可以任意转载, 但转载时务必以超链接形式标明文章原始出处 和 作者信息 及 版权声明
链接：http://www.jianzhaoyang.com/sky-on-twitter/twitter-%e4%b8%80%e5%91%a8-for-2009-06-28 )

No related posts.

常见的例子，表中记录按照creation_date作purge，且该字段上有个索引。

如果不加index_desc hint，purge job执行时间长了可能会越来越慢。如下consistent read明显要比current read多很多。是因为Index range scan从index tree的最左面开始扫描，扫描了很多空块。

SQL> DELETE FROM  vltb_data_0   where creation_date < (SYSDATE - 3)  and rownum < 1000;
999 rows deleted.

———————————————————-
| Id  | Operation          | Name                        |
———————————————————-
|   0 | DELETE STATEMENT   |                             |
|   1 |  DELETE            | RULE_OBJECT_ATTR_DATA_0     |
|*  2 |   COUNT STOPKEY    |                             |
|*  3 |    INDEX RANGE SCAN| RULE_OBJECT_ATTR_DATA_0_IX3 |
———————————————————-
Predicate Information (identified by operation id):
—————————————————
2 - filter(ROWNUM<1000)
3 - access(”CREATION_DATE”<SYSDATE@!-3)

Statistics
———————————————————-
1  recursive calls
21167  db block gets
427848  consistent gets
0  physical reads
1341824  redo size
1  sorts (memory)
0  sorts (disk)
999  rows processed

通过添加index_desc, Index range descending scan从index tree的中间或者右边进入扫描，更快定位到存在纪录的block.

SQL> DELETE /*+ index_desc(rule_object_attr_data_0) */ FROM  vltb_data_0   where creation_date < (SYSDATE - 3)  and rownum < 1000;
999 rows deleted.

Statistics
———————————————————-
1  recursive calls
21177  db block gets
59  consistent gets
288  physical reads
1368592  redo size
814  bytes sent via SQL*Net to client
833  bytes received via SQL*Net from client
3  SQL*Net roundtrips to/from client
1  sorts (memory)
0  sorts (disk)
999  rows processed

从而避免了无用功。这样的例子时常在工作中遇到。

—————-人工分割线————————

最近上海一个刚盖的差不多快结盘的13层房子倒了一个，整体倒的。是有一个小的房地产开发公司开发的。全国人民都知道了。

估计会对房地产市场特别是中小房地产开发公司开发的楼盘带来严重信任危机。那些早些年盖的二手房或许将火爆。

很壮观。

Amoeba 默认设置支持客户端设置编码的方式是 ： set names gbk 其他方式目前还没考虑到。

Discuz遇到编码问题，可以通过修改 include/db_mysql.class.php 里的 设置编码方式改成：

 set names utf8

 –即支持utf8编码格式

  原文来自：

http://hi.baidu.com/hlxwell/blog/item/ea0d445913af102d2834f0d5.html

该版本基于0.32版本之上进行bugs fixed,非常感谢阿权提供的一些bug列表

这次版本跳跃比较大，也是我打算在amoeba这个项目花下时间的决心。因此将amoeba提升到新的起点1.0.0版本

下面是这次主要的变更：

1、修复sql解析 explain 关键字开始的sql
2、修复FORCE INDEX (xx) 之类的sql无法解析问题
3、修复包含转义符合在内的sql 比如：insert into xx values(’\'test\’)
4、修复包含 Order by rand()的sql
5、调整默认 网络接受发送缓冲区成128k

下载地址： http://www.sf.net/projects/amoeba