Author:NinGoo posted on NinGoo.net

在oschina上闲逛，发现一款不错的os实时监控工具dstat，整合了vmstat, iostat, ifstat, netstat等常见os监控工具的优点，输出的结果简单直观，并且结果可以保存到csv文件，这样再写一个简单的perl脚本，就能将os的主要监控信息一次性全部抓取出来，保存到监控数据库中用于分析展示。试用了一下觉得非常不错，因此在这里分享一下这个用python写的工具。

$dstat
----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai hiq siq| read  writ| recv  send|  in   out | int   csw
  2   0  98   0   0   0|  80k   54k|   0     0 | 335B  381B|1297  1301
 22   2  74   0   0   2|   0   416k| 621k  219k|   0     0 |1158    26k
 23   3  72   0   0   2|  64k  484k|  11k   11k|   0     0 |1109    30k
 21   3  75   0   0   2|4096B  416k|  77k   77k|   0     0 |2104    25k
 29   4  66   0   0   2|   0  1240k| 996k  425k|   0     0 |1350    28k

$dstat -ta --output osstat.csv
-----time----- ----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system--
  date/time   |usr sys idl wai hiq siq| read  writ| recv  send|  in   out | int   csw
05-02 11:37:08|  2   0  98   0   0   0|  80k   54k|   0     0 | 335B  381B|1297  1301
05-02 11:37:09| 16   4  78   0   0   3|   0  1404k|1478k  939k|   0     0 |4316    33k
05-02 11:37:10| 20   2  76   0   0   2|   0  1144k|1109k  828k|   0     0 |5653    28k
05-02 11:37:11| 13   2  83   0   0   2|   0   588k|2590k 1684k|   0     0 |4256    23k

$dstat -h
Usage: dstat [-afv] [options..] [delay [count]]
Versatile tool for generating system resource statistics

Dstat options:
  -c, --cpu              enable cpu stats
     -C 0,3,total           include cpu0, cpu3 and total
  -d, --disk             enable disk stats
     -D total,hda           include hda and total
  -g, --page             enable page stats
  -i, --int              enable interrupt stats
     -I 5,eth2              include int5 and interrupt used by eth2
  -l, --load             enable load stats
  -m, --mem              enable memory stats
  -n, --net              enable network stats
     -N eth1,total          include eth1 and total
  -p, --proc             enable process stats
  -s, --swap             enable swap stats
     -S swap1,total         include swap1 and total
  -t, --time             enable time/date output
  -T, --epoch            enable time counter (seconds since epoch)
  -y, --sys              enable system stats
  --ipc                  enable ipc stats
  --lock                 enable lock stats
  --raw                  enable raw stats
  --tcp                  enable tcp stats
  --udp                  enable udp stats
  --unix                 enable unix stats

  -M stat1,stat2         enable external stats
     --mods stat1,stat2

  -a, --all              equals -cdngy (default)
  -f, --full             expand -C, -D, -I, -N and -S discovery lists
  -v, --vmstat           equals -pmgdsc -D total

  --integer              show integer values
  --nocolor              disable colors (implies --noupdate)
  --noheaders            disable repetitive headers
  --noupdate             disable intermediate updates
  --output file          write CSV output to file

  delay is the delay in seconds between each update
  count is the number of updates to display before exiting
  The default delay is 1 and count is unspecified (unlimited)

Related Articles

• tbstat:实时监控数据库统计状态的小工具
• 使用jpgraph绘制数据库监控图形
• 使用Oracle正则表达式监控应用到数据库的连接情况
• 如何监控MemCached的状态
• 用jQuery+Tablesorter实现客户端分页与排序
• 用Perl的hash数组实现个性化监控

PermLink: http://www.ningoo.net/html/2010/dstat_os_monitor_tool.html

Add Comments(0) | Follow NinGoo@Twitter | Google Reader

上个月忙于应付课程论文和考试，直到现在才有时间整理笔记，追忆王泽鉴先生当晚的讲座盛况。

王泽鉴先生应不必详细介绍，撰写“天龙八部”（《民法学说与判例研究》八册）的华人世界民商法学第一泰斗，念过法学的人都知道。先生作为光华法学院教授委员会成员，此番来杭参加年会，照例也给光华学子谈谈法学研习心得。

1月5日晚，整个月轮山上的师生都聚集在曾宪梓二楼阶梯大教室里，当时室外气温只有2-3度，满教室呼吸蒸腾出来的水汽，把窗玻璃都涂白了，令人眩晕。距此地不远的灵隐寺，恐怕只有大年三十半夜里烧头香时，才能看到如此盛景。

先生讲座题为《侵权责任法、人格权保护与基本权利——理论建构与台湾实务发展》，结合大陆最新出台的《侵权责任法》，从比较法的角度，通过剖析曾经发生在台湾的一系列案例来揭示侵权法要旨。笔记要点如下：

1. 上海世博会举办法政论坛《民法与世博会》，先生应邀出席并演讲《民法让城市生活更美好》。其中讲到，1900年法国巴黎举办第五届世博会，同时也举办了第一届世界比较法大会，可见世博会与比较法的渊源。中国法律发展百年左右的历史，其实也是一部比较法的发展史。中国政法大学最近看清楚了这一点，于是成立比较法高级研究院。早在民国民法制定之时，便是德国民法的继受过程。大陆民法通则诞生二十余年，该法作为民法典首部曲，深受德国法权利体系概念、法律行为之影响。至2009年《侵权责任法》通过，民法典架构方显雏型。

2. 法学院应建立在比较法的基础之上：

a. 认识自己，了解别人：比较法的特点是具有镜子的功能，籍此尊重别人、谦卑自己。

b. 保护合法权益，制裁不法：这是中国侵权法的特色，制裁是为了预防的目的。

c. 对于司法的解释作用：先生在清华授课时讲过如何借用比较法对侵权法解释适用，侵权法具有可比较性（case law）。

d. 司法的统一。

3. 推荐阅读外国的案例，比如 German Law of Torts: A Comparative Treatise by B. S. Markesinis and Hannes Unberath，其中有150个德国法案例（判决）。只有落实到具体的案例分析，才可以发现制度之不同。

4. 考察司法实务：

a. 工伤概不负责案（1988）。

b. 齐玉苓案（1999）。

c. 泸州二奶继承案（2001）。

参阅：郑永流《道德立场与法律技术——中德情妇遗嘱案的比较和评析》，《中国法学》2008年第4期。

5. 侵权责任立法管辖一般侵权行为，《民法通则》第106条第2款是侵权责任法的核心。（“公民、法人由于过错侵害国家的、集体的财产，侵害他人财产、人身的应当承担民事责任。”）

6. 大陆的法律没有明确的请求权概念，比如《侵权责任法》第2条以列举的方式罗列人身财产权利（“本法所称民事权益，包括生命权、健康权、姓名权、名誉权、荣誉权、肖像权、隐私权、婚姻自主权、监护权、所有权、用益物权、担保物权、著作权、专利权、商标专用权、发现权、股权、继承权等人身、财产权益。”），而法国民法相应的第1382条没有列举权利，德国民法第823条、第826条规定了三大类侵权行为，日本民法第709条规定的是扩大权利。

7. 人身权包括人格权和身份权。权利 v.s. 权利以外的利益：财产包括财产及财产利益。财产一般损失是契约问题，不是财产权受侵害。

8. 中国是民法研究的天堂：richness of cases.

9. 国家应使基本权利得以实现，应有义务注意法律的发展，及时修订宪法。

10. 人格权未进入侵权法保护范畴，受到德国一般人格权理论的影响，只能类推适用、扩大解释（以后会有问题）。

11. 释宪机构：亚洲地区很多国家都有宪法法院，虽然大陆没有，但是学者可以学说上的理论建构讨论现行法律，从而发挥违宪审查的作用。


12. 要多读外国的判决，比如《德国宪法法院判决》，学习他们论证的风格和说理的技术。

13. 台湾最高法院案例分析：资讯自主权（申请户籍时必须按指纹是否合宪？），子女获知自己血统来源的权利，私法上的人格权，言论自由与人格权保护（宋楚瑜 v. 李登辉，此案吸收了美国60年的言论自由相关判决之精华），死亡人格权保护（蒋孝严诉陈水扁毁谤蒋介石名誉案）。

14. 大陆法律文本没有扣紧请求权基础理论，文字显得“亲切而丰富”。（v.s. 台湾法律文本“典雅而简约”。）

15. 国际公约和比较法可以参照，作为法律解释适用的方法之一，作为本国法律解释的基准。

16. 言论自由的目的：

a. 多元社会。

b. 市场机制（market of ideas）。

c. 真理愈辩愈明。

d. 促进社会民主制度发展。

17. 所谓伟大的国家：宁可不要高大的建筑物，也要见到向法官敬礼的农夫。


18. 欧洲人权法院的判决都在网上公开：http://www.echr.coe.int/echr/Homepage_EN

19. 台湾法官都是一人独立撰写判决书，在正式公布之前不能送审。


20. 法律没有规定，构成可以由法院填补的漏洞：法律漏洞、政策漏洞、价值变迁等。

21. 不用记理论，只要记案例事实、说理、法条的适用。

22. 政策即 legal policy，是法律体系内的价值理念。


23. 大陆“荷花女案”（陈秀琴诉魏锡林、《今晚报》名誉损害案），缺少比较法判例的分析，最高法院的解释没有被阐发。

24. 不要让法律成为万里长城，比较法可以突破心灵上的长城。（耶林：隔壁的药草也可以用来治自己的病。）

25. 先生正在撰写并即将出版两部著作：《人格权》和《比较法》。

26. 希望学生们在学习法律之外把经济学学好，花一年时间学好日文，再花三到五年时间学好德文，从而具备更广阔的视野。

27. 善用时间：晚睡一点、早起一点、勉强一点。史尚宽先生每天五点起床，工作到九点才出门上班。史尚宽先生这么伟大的人都要每天五点起床，愚笨如你我，还不得三四点起床，才有希望赶得上他？

参阅：

侵权责任法，人格权保护与基本权利——王泽鉴教授光华法学院学术讲座

作者：eygle 发布在 eygle.com

刚刚帮朋友处理一则CURRENT日志损坏的恢复，当然是使用到了：
_allow_resetlogs_corruption= TRUE

在初期恢复时出现了ORA-600 4000号错误，这个错误以前写过几个案例，一般没有好的办法，只能通过bbed修复。

不过4000号错误不一定非要用bbed修改坏块，有时候经过反复几次重新启动数据库，就可以暂时规避，尝试将数据导出。

首先出现的是：

Thu Feb 04 13:36:58 2010
Errors in file D:\oracle\admin\orcl\udump\ORA00592.TRC:
ORA-00600: internal error code, arguments: [4000], [3], [], [], [], [], [], []

SMON: disabling cache recovery
Thu Feb 04 13:36:59 2010
ORA-704 signalled during: alter database open resetlogs

多次重启后，出现4194错误：

Thu Feb 04 21:24:41 2010
SMON: enabling cache recovery
SMON: enabling tx recovery
Thu Feb 04 21:24:42 2010
Completed: alter database open
Thu Feb 04 21:24:43 2010
Errors in file D:\oracle\admin\orcl\bdump\orclSMON.TRC:
ORA-00600: internal error code, arguments: [4194], [14], [4], [], [], [], [], []

Thu Feb 04 21:24:44 2010
Recovery of Online Redo Log: Thread 1 Group 2 Seq 2 Reading mem 0
  Mem# 0 errs 0: D:\ORACLE\ORADATA\ORCL\REDO02.LOG
Thu Feb 04 21:24:44 2010
Errors in file D:\oracle\admin\orcl\bdump\orclSMON.TRC:
ORA-01595: error freeing extent (7) of rollback segment (2))
ORA-00600: internal error code, arguments: [4194], [14], [4], [], [], [], [], []

但是数据此时可以导出，4194错误出现在回滚段2上，当然也可以解决,这个都是大家所熟悉的了。

-The End-

相关文章|Related Articles

• ORA-07445 cold_qerfxArrayMaxSize 的Bug
  
• ORA-600 17285 错误 与 PL/SQL Developer
  
• 使用errorstack跟踪ORA-01438错误
  
• ORA-01157 - Mount状态下的文件存在性校验
  
• 使用DATAPUMP导致ORA-00600 17020错误
  

评论数量(0)|Add Comments

本文网址：http://www.eygle.com/archives/2010/02/ora_600_4000_4194.html

说EXPDP无语，那是因为它完全不customer focus，特别是导出数据量很大表很多的schema的时候，经常”假寐”。
“假寐”就是假死,hang.

今天用expdp作用户级别的逻辑备份，该用户有2200多个表，导出文件共85G，没有使用并行大概花费了3个小时不到。

运行命令后的半个小时内，导出文件大小没有任何变化，察看active session，有个在长时间等待”wait for unread message on broadcast channel”，给人的感觉是hang住，不靠普。

后来准备开窗口使用传统的exp,继续观察expdp。”假寐”后,EXPDP先把最大的一个表给导出来了，后来又导出了几个10g的表。原来我没有碰见真死的bug。观察日志文件，expdp基本按照表从大到小进行数据导出。倒是比exp快，可惜用户体验不行。

详细命令和日志如下

yumianfeilong$> more backup_expdp.log
Export: Release 10.2.0.4.0 - 64bit Production on Wednesday, 03 February, 2010 19:54:02
Copyright (c) 2003, 2007, Oracle. All rights reserved.
Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
FLASHBACK automatically enabled to preserve database integrity.
Starting “SCOTT”.”SYS_EXPORT_SCHEMA_01″: SCOTT/******** schemas=SCOTT directory=EXPDP dumpfile=backup_expdp.dmp logfile=backup_expdp.log
Estimate in progress using BLOCKS method…
Processing object type SCHEMA_EXPORT/TABLE/TABLE_DATA
Total estimation using BLOCKS method: 122.4 GB
Processing object type SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA
Processing object type SCHEMA_EXPORT/SEQUENCE/SEQUENCE
Processing object type SCHEMA_EXPORT/TABLE/TABLE
Processing object type SCHEMA_EXPORT/TABLE/GRANT/OWNER_GRANT/OBJECT_GRANT
Processing object type SCHEMA_EXPORT/TABLE/INDEX/INDEX
Processing object type SCHEMA_EXPORT/TABLE/CONSTRAINT/CONSTRAINT
Processing object type SCHEMA_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICS
Processing object type SCHEMA_EXPORT/TABLE/COMMENT
Processing object type SCHEMA_EXPORT/VIEW/VIEW
Processing object type SCHEMA_EXPORT/VIEW/GRANT/OWNER_GRANT/OBJECT_GRANT
Processing object type SCHEMA_EXPORT/TABLE/TRIGGER
Processing object type SCHEMA_EXPORT/TABLE/INDEX/FUNCTIONAL_AND_BITMAP/INDEX
Processing object type SCHEMA_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS
. . exported “SCOTT”.”TABLE725″ 11.39 GB 39455120 rows
. . exported “SCOTT”.”TABLE1085″ 10.87 GB 225445 rows
. . exported “SCOTT”.”adfadsfdsf” 11.07 GB 43002 rows
. . exported “SCOTT”.”adfasdf” 163.2 MB 640381 rows
. . exported “SCOTT”.”adfasdf” 6.170 GB 5758755 rows
. . exported “SCOTT”.”adfasdf” 4.362 GB 3667986 rows
. . exported “SCOTT”.”adfsdf” 1.325 GB 39455120 rows
. . exported “SCOTT”.”werwer” 1.303 GB 4759513 rows
. . exported “SCOTT”.”fadf” 102.9 MB 58882 rows
. . exported “SCOTT”.”zzzzzzzzzzzz” 21.27 MB 77610 rows
…………………………
. . exported “SCOTT”.”xxxxxxxxxxx” 381.5 MB 4443678 rows
. . exported “SCOTT”.”cccccccccc” 314.1 MB 50703 rows
. . exported “SCOTT”.”vvvvvvvv” 360.8 MB 19679 rows
. . exported “SCOTT”.”nnnnnnnnnn” 199.3 MB 79876 rows
…………………………
. . exported “SCOTT”.”mmmmmmmmmmmmm” 55.57 MB 4719 rows
. . exported “SCOTT”.”jjjjjjjjjjjjjj” 50.01 MB 27200 rows
. . exported “SCOTT”.”kkkkkkkkkkkkk” 36.18 MB 14629 rows
. . exported “SCOTT”.”llllllll” 49.89 MB 173582 rows
……………………
. . exported “SCOTT”.”ttttttttttttt” 3.667 MB 5810 rows
. . exported “SCOTT”.”tttttttttttttt” 3.843 MB 20287 rows
. . exported “SCOTT”.”ttttttttttttttt” 2.710 MB 79876 rows
. . exported “SCOTT”.”tttttttttttttttttt” 565.6 KB 16233 rows

. . exported “SCOTT”.”ahhhhhhhhhhhhhhh” 1.826 MB 38701 rows
. . exported “SCOTT”.”qqqqqqqqqqqqqqqq” 1.122 MB 65065 rows
. . exported “SCOTT”.”beeeeeeeeeee” 1.122 MB 65065 rows

. . exported “SCOTT”.”Tttttttt1119″ 2.600 MB 12544 rows
. . exported “SCOTT”.”T515″ 1.810 MB 15267 rows
. . exported “SCOTT”.”T518″ 2.571 MB 34564 rows
. . exported “SCOTT”.”Tttttttttt668″ 1.937 MB 1339 rows
. . exported “SCOTT”.”Tttttttttttttt994″ 984.5 KB 1502 rows
. . exported “SCOTT”.”Taaaaaaa541″ 1.455 MB 1153 rows
. . exported “SCOTT”.”Taaaaaa593″ 1.189 MB 768 rows
. . exported “SCOTT”.”aaaaaaaaaaaaaaa” 1.512 MB 3475 rows
…………………………………………
. . exported “SCOTT”.”ABC” 28.21 KB 177 rows
. . exported “SCOTT”.”jjjjjjjjjjjjj” 761.1 KB 43002 rows
. . exported “SCOTT”.”yyyyyyyyyy” 904.7 KB 3607 rows
. . exported “SCOTT”.”ffffffffffff” 91.74 KB 797 rows
. . exported “SCOTT”.”wwwwwwwww” 259.1 KB 1 rows
. . exported “SCOTT”.”rrrrrrrrrrrrrr” 7.687 KB 140 rows
. . exported “SCOTT”.”ddddddddddddde” 7.687 KB 140 rows
……………………………….
. . exported “SCOTT”.”T991″ 12.60 KB 3 rows
. . exported “SCOTT”.”T993″ 38.60 KB 429 rows
. . exported “SCOTT”.”TTTTTTTT” 0 KB 0 rows
. . exported “SCOTT”.”bbbbbbbbbb” 0 KB 0 rows
………………………………………
Master table “SCOTT”.”SYS_EXPORT_SCHEMA_01″ successfully loaded/unloaded
******************************************************************************
Dump file set for SCOTT.SYS_EXPORT_SCHEMA_01 is:
/oracle/TRACE/archive/EXPDP/backup_expdp.dmp
Job “SCOTT”.”SYS_EXPORT_SCHEMA_01″ completed with 0 error(s) at 22:46:43

单表expdp测试没有假死问题。

译者注: 本文翻译自Jonathan Lewis的文章Faking Stored Outlines in Oracle 9, 可以从此处下载原文的word版本: Stored Outlines in Oracle 9.
本文与前一篇Oracle 8i/9i中的执行计划稳定性是Jonathan Lewis先生写的关于stored outline具体使用以及其中可能涉及到的风险系列文章,也是我所见到的关于stored outline介绍的最详细的文档了. 关于stored outline还有以下相关资料可以对照阅读下:
Oracle Outlines - aka Plan Stability By Kerry Osborne
Plan stability in 10g - using existing cursors to create Stored Outlines and SQL profiles By Randolf Geist
Stored Outlines and Plan Stability By Tim Hall
Tuning Third-party Vendor Oracle Systems :Tuning when you can’t touch the code By Mark Ault

原文为在Oracle 9中伪造存储概要

在Oracle 9中伪造存储概要

在前面的文章中,我讨论到存储概要,并且描述了一种通过滥用系统来生成你所需要存储概要的方法.我同时也指出,在Oracle 9中使用这种方法存在一些风险,因为存储在数据库中的细节信息已经变得非常复杂.在接下来的文章中,我将介绍一种合法的操作存储概要的方法,这种方法可以应用在Oracle 8与Oracle 9中.这篇文章的细节都是基于实验得出的,实验环境是Oracle 8.1.7.0与Oracle 9.2.0.1的默认安装环境.

回顾

当你知道如何通过给一段DML语句添加提示就可以让它运行的快很多,但是你却没有访问源代码并将提示放到适当位置的途径, 你会怎么做?

在上一篇文章中,我展示了你可以如何用存储概要(也被称为执行计划稳定性)来驱使数据库引擎为你做这种工作.
一个存储概要由两个组件组成(宽泛地讲)-一个你希望控制的SQL语句,一组每当Oracle发现这条SQL被优化都将在它上面应用的提示.这两个组件都被保存在一个被称为outln的数据库schema中.

我们可以使用一组如图-1中类似的查询语句来检查保存在其中的SQL语句,以及附着在这条SQL语句上的提示.

select	name, used, sql_text
from	user_outlines
where	category = 'DEFAULT'
;

select	stage, node, hint
from	user_outline_hints
where	name = '{one of the names}'
;

Figure 1 Examining stored outlines.
在前面的文章中,我介绍了这样一种想法来欺骗系统, 使用合法的方法创建一个存储概要, 接着,使用一个文本相似的但已经添加过提示的语句来创建一个存储概要,最后,使用一组SQL语句来交换这两个存储概要的实际结果来修复存储概要.

当时,我曾提到这种方法对Oracle 8来讲或许是安全的,但是由于在新版本中引入的变化, 在Oracle 9中可能会导致问题.
这篇文章将对这些变化进行考查, 介绍一种合法的方法来得到你想要的一组存储到outln中的提示,用来解决你的那些问题语句.

相关变化

如果你登录到outln schema(在Oracle 9中它默认是锁住的)查看可用的表清单,你将发现Oracle 9比Oracle 8多出来一张表. 这些表为:

ol$	SQL语句
ol$hints	提示表
ol$nodes	查询块

第三张表是一张新表,被用来将提示列表与这条SQL语句(一份内部重写的版本)的多个不同查询块.你还将发现,提示列表(ol$hints)也被加强了,其中还包括文本长度与偏移量的细节信息.
图2为这三张表的详细描述,用星号标注了Oracle 9中出现的新字段.

ol$

OL_NAME          VARCHAR2(30)
SQL_TEXT         LONG
TEXTLEN          NUMBER
SIGNATURE        RAW(16)
HASH_VALUE       NUMBER
HASH_VALUE2      NUMBER           ***
CATEGORY         VARCHAR2(30)
VERSION          VARCHAR2(64)
CREATOR          VARCHAR2(30)
TIMESTAMP        DATE
FLAGS            NUMBER
HINTCOUNT        NUMBER
SPARE1           NUMBER           ***
SPARE2           VARCHAR2(1000)   ***

Ol$hints

OL_NAME          VARCHAR2(30)
HINT#            NUMBER
CATEGORY         VARCHAR2(30)
HINT_TYPE        NUMBER
HINT_TEXT        VARCHAR2(512)
STAGE#           NUMBER
NODE#            NUMBER
TABLE_NAME       VARCHAR2(30)
TABLE_TIN        NUMBER
TABLE_POS        NUMBER
REF_ID           NUMBER           ***
USER_TABLE_NAME  VARCHAR2(64)     ***
COST             FLOAT(126)       ***
CARDINALITY      FLOAT(126)       ***
BYTES            FLOAT(126)       ***
HINT_TEXTOFF     NUMBER           ***
HINT_TEXTLEN     NUMBER           ***
JOIN_PRED        VARCHAR2(2000)   ***
SPARE1           NUMBER           ***
SPARE2           NUMBER           ***

ol$nodes  (completely new in 9)

OL_NAME          VARCHAR2(30)
CATEGORY         VARCHAR2(30)
NODE_ID          NUMBER
PARENT_ID        NUMBER
NODE_TYPE        NUMBER
NODE_TEXTLEN     NUMBER
NODE_TEXTOFF     NUMBER

Figure 2 The outln tables.
你可能很快会注意到多处细节-有大量信息被基于这些表的视图排除在外了.视图user_outline_hints的视图定义完全没有改变,尽管表ol$hints上新增加了10个字段.实际上,这个视图在Oracle 8的时候就极度不足,因为它遗漏了相当有用的hint#字段.
你还会注意到,Oracle 9现在有两个hash_value字段.如果你在Oracle 8与Oracle 9中对同样的SQL语句创建存储概要,你将发现它们拥有同样的hash_value,但是Oracle 9中对应的hash_value可能完全不同.
你可以也会发现,Oracle 9中的signature(签名)字段的值与Oracle 8中的值是不同的. 这是由于Oracle这两个版本之间策略上的最主要的调整就是为了提高存储概要的重复利用.在Oracle 8中,只有在你的SQL语句与存储的SQL语句完全匹配(包含空格符/大小写以及换行符)的时候才可以使用.到Oracle 9之后,这个限制放宽了,只要在去除掉重复的”空字符”并且将文本都转换成同样的大小写之后SQL语句能够匹配就可以使用存储概要了.例如,下面的两条SQL语句将使用同一个存储概要.

select * from t1 where id = 5;

SELECT  *
FROM	T1
WHERE   ID = 5;

策略上的这个调整导致了第一次创建这个执行计划的SQL语句的签名的调整;如果你的数据库从Oracle 8升级到Oracle 9,就必须更新存储概要或者必须确认它们不再被使用.(事实上,别名为dbms_outln包outln_pkg包含一个特别的存储过程update_signatures来处理这个问题.
不过,关于Oracle 9中这些表的最意义重大的事情却是对查询语句中涉及到的文本与对象的极度详细描述.创建图-3中显示的例子,并在继续阅读之前详细查看ol$hints表中的内容.

drop table t1;

create table t1
nologging
as
select
	rownum		id,
	rownum		n1,
	object_name,
	rpad('x',500)	padding
from
	all_objects
where
	rownum <= 100
;

alter table t1
add constraint t1_pk primary key (id);

create index t1_i1 on t1(n1);

analyze table t1 compute statistics;

create or replace outline demo_1 on
select	* from t1
where	id = 5
and	n1 = 10
;

Figure 3 Sample code.
这个例子立足于一个简单的小表,包含两组相近的列,其中一个列为逐渐(从而也创建了索引),另外包含一个简单的非唯一索引.我们为一个典型的查询创建一个存储概要来查看我们可以如何对待它.
如果针对由这个例子创建的存储概要demo_1运行图-1中的示例查询,我们将发现这个查询将附带6个提示.

  STAGE  NODE  HINT
	    3     1  NO_EXPAND
	    3     1  ORDERED
	    3     1  NO_FACT(T1)
	    3     1  INDEX(T1 T1_PK)
	    2     1  NOREWRITE
	    1     1  NOREWRITE

不出意外,其中的第四行显示我们将使用主键索引来访问这张表.如果我们实际上想要Oracle使用这个非唯一索引T1_I1访问表,我们该对存储概要做什么呢?理论上讲,我们可以调整这个存储概要以使得

	    3     1  INDEX(T1 T1_PK)

变成

	    3     1  INDEX(T1 T1_I1)

新特性

我们可以做的第一件事是查看包dbms_outln_edit.这个包在Oracle 9中引入,正如它的名字提示的那样,它的目标是编辑存储概要,这看上去令人充满希望.
然而,查看包的方法列表,检查文档手册,我们发现这个包只包含如下几个”编辑相关”的方法.

	CREATE_EDIT_TABLES
	DROP_EDIT_TABLES
	CHANGE_JOIN_POS

前两个方法允许我们创建或删除outln用户拥有的表的本地拷贝.第三个方法允许我们交换一个存储概要计划中的表连接顺序. 哪怕仅仅是帮助我们修改一个简单的提示的方法也是没有的.目前,这个包看上去实际上一无是处-但是它们注定会越来越完善.
当然B方案就是去侵入它了!如果我们登录到outln用户,并自己诊察ol$hints表(也就是支撑视图user_outline_hints的表)的内容,我们可以尝试下面的这个更新操作:

update ol$hints
set
	hint_text = 'INDEX(T1 T1_I1)'
where
	ol_name = 'demo_1'
and hint# = 4
;

登录回到我们的测试Schema,清空共享池,并且打开存储概要:

connect test_user/test
alter system flush shared_pool;
alter session set use_stored_outlines = true;

实际上,我们将发现侵入的存储概要确实如你所愿了.但是这是一个让人不爽的解决方案,
因为我们一直会给一个关于”更改数据字典表”的严厉的警告.

旧方法(1)

接着,我们的目标就是寻找一种迂回但又看似无害的方法来改变存储概要表的内容,并且不需要直接的侵入存储概要表.
从前(在Oracle 9以前),我们有多种实现办法,它们都是基于这样一个事实,存储概要的效果仅仅取决于进来的SQL语句的文本,而完全不关心对对象类型或者对象的所有者.
将表替换成添加过提示的视图是一种有效的方法.(我相信,这种方法最初是由Tom Kyte在它的《Expert One on One: Oracle》这本书中介绍的).
连接到另外一个拥有表T1的访问权限的Schema，按照下面的定义创建一个添加过提示的视图,视图与表的名称保持一致.

Create or replace view t1 as
Select /*+ index(t1,t1_i1) */
	*
from test_user.t1;

一旦视图创建完成,就在这个schema下使用下面的这个命令”重编译”这个已存在的存储概要.

	alter outline demo_1 rebuild;

注意:必须拥有权限alter any outline才可以执行这个命令.
如果登录回到原来的schema,清空缓存(flush shared pool),并且启用存储概要,我们将会发现原来的查询语句现在如愿以偿的使用上了索引T1_I1.

	    3      1  INDEX(T1 T1_I1)

这样为什么可行?因为存储概要并不属于任何一个schema. 当我们在另外一个schema中重编译这个称为demo_1的存储概要的时候,名称T1应用到了一个本地的包含提示的视图上了,因此Oracle将这个提示包装进了真实的执行计划中,从而也进入了这个存储概要.通过查看视图user_outline_hints,将会发现关键的那一行已经变成了
3 1 INDEX(T1 T1_I1)

很不幸,我们还将注意到它现在包含3行如下形式的提示:

	    2      1  NOREWRITE
	    1      2  NOREWRITE
	    1      1  NOREWRITE

而原来我们只有两行:

	    2     1  NOREWRITE
	    1     1  NOREWRITE

我们引入了一个新的提示,也就是”Stage 1,Node 2″.我不敢说我确切的知道这是什么意思,但是它一定与这样一个事实有关,为了在另外一个Schema解析优化这个查询,Oracle执行了一个额外的步骤来将视图引用转换成基础表的引用.
虽然目前这不会导致存储概要无法正确使用(或者如同它在这个简单的例子中这样),谁又能说Oracle在将来的版本又会有多挑剔呢.

旧方法(2)

因为视图引入了一个可能在将来版本变成错误的异常,我们不得不更加挑剔. 让我们试试下面的这种方法:

Create a new schema.
Create table T1 in that schema.
Create ONLY the index T1_I1.
Rebuild the outline in that schema

如果比较存储概要重建前后user_outline_hints的详细内容(必须重新登录到原来的Schema来做这件事),我们将发现除了我们想要改变的那一行,它们是完全一样的.重新登录回原来的Schema,通过清空共享池以及打开存储概要做一个常规检查,我们将会发现修改后的存储概要已经被使用了.

然而,还有一个潜在的威胁,不过这一次更加隐蔽.再回去看图-2中出现在Oracle 9中的新字段的定义-你认为字段user_table_name中保存的值将会是什么啊?它应该是有限制的表名称,例如:
{User_name}.{table_name}

在我们的例子中,这将告诉Oracle表T1实际上是一个属于新的Schema的表,而不是原来的Schema下面的表.即使Oracle确实在使用这个存储概要,这个表里的信息也充分说明Oracle是在错误的对象上面应用这个存储概要.
另外,它现在现在有效,但是为什么有这个信息在这儿呢-可能是为了将来的版本增强做准备呢.

可靠的赌注

看来,要生成存储概要,而又不面临将来的风险就只有一种方法了,那就是尽可能的真实.

在这个示例中,你需要删除主键索引,生成执行计划,然后替换掉主键.

当然,你可能不想在生产环境做这件事,即使你在生产环境做了,存储概要也有可能选择走全表扫描(而不是走你想要的那个索引).
底线是你必须至少在另一个数据库中有一个这个Schema的空闲拷贝,接着需要非常小心的操作这个拷贝以得到需要的存储概要.一旦得到这个存储概要,你就可以从一个数据库导出它并将其导入另外一个数据库.
例如:在这个空闲的数据库上,删除主键以避免PK唯一扫描就是可行的.如果Oracle并没有自动的采用另外一个索引,你可以对系统说各种谎言,诸如:

• 将optimizer_mode改成first_rows_1
• 构造数据使得列N1上的数据是唯一的.(不过,不要将其改成唯一索引,这样生成出来的存储概要将是unique scan而不是range scan了).
• 使用dbms_stats来使这个索引获得一个难以置信的clustering_factor.
• 调整参数optimiser_index_caching来告诉系统,这个索引已经完全被缓存.
• 调整optimiser_index_cost_adj来告诉系统,多块读要比单块读要慢100倍.
• 使用dbms_stats修改aux_stats$表来达到上一条同样的宣称效果,并且添加这样一个事实,一次多块读的典型大小为2个块.
• 重建这个索引以包含where从句中的所有字段.

给定存储概要表中的内容,假使表的所有者不变,对象类型不变以及不改变索引的唯一度,几乎任何事情都可以做. 如果你可以构造一个数据集与环境来生成一份与生产系统没有内部不一致的存储概要,那么你就可以以任何方式来欺骗系统.

结论
相对于Oracle 8来讲,在Oracle 9中进入存储概要的信息变更更加精细了.之前可以非常容易也很明显无风险的”调整”存储概要的方法,现在还仍然可以工作,但是Oracle 9中收集的巨量的附加信息表明,之前的那种方法现在可能会给将来留下隐患.

虽然Oracle 9中引入了一个编辑存储概要的包,但它当前还只是局限在交换表的连接顺序.除了使用第二套系统来调整索引(通过改变环境参数以及人造的统计信息)外, 看似不存在安全的干预存储概要的方法.

参考文献
Oracle 9i Release 2: Database Performance Tuning Guide and Reference - Chapter 7.
Oracle 9I Release 2: Supplied PL/SQL Packages and Types Reference - Chapters 41 - 42

    一直以来, DataReport都是用表格方式显示多行数据, 当我们查询少量字段数很多的记录时, 就不希望以表格方式显示记录, 而希望以Form格式显示, 如下面显示的员工表的信息.

EMPNO	7782
ENAME	CLARK
JOB	MANAGER
MGR	7839
HIREDATE	1981-06-09 00:00:00.0
SAL	2450
COMM
DEPTNO	10
EMPNO	7839
ENAME	KING
JOB	PRESIDENT
MGR
HIREDATE	1981-11-17 00:00:00.0
SAL	5000
COMM
DEPTNO	10

    实现这个功能, 并没有修改任何一行代码, 只是改了一下控制显示格式的XSL文件, 然后在报表定义文件中加入一行.

WEBCHART.XMLATTR=form="yes"
WEBCHART.QUERY_1=SELECT * FROM EMP WHERE DEPTNO=10

    想要更丰富的格式, 只需要再改进一下XSL文件即可, 不需要修改Java代码, 不过这需要你对XML和XSLT比较熟悉.

Relative Posts:

• 2010/01/20 -- 逻辑连接层与物理连接层 (3)
• 2010/01/08 -- DataReport中的超级表达式 (0)
• 2010/01/08 -- DataReport的重复值合并 (0)
• 2010/01/05 -- DataReport中的FORALL循环 (0)
• 2009/12/29 -- DataReport中的Cache为王 (4)
• 2009/12/28 -- 统一DataReport的Servlet (2)
• 2009/12/02 -- 添加URL/HTML字符转义功能 (1)
• 2009/09/21 -- 多支持了四种业务图 (0)
• 2009/07/28 -- DataReport增加JfreeChart支持 (7)
• 2009/07/25 -- DataReport的图片服务功能 (0)

记得刚开始看InnoDB文档的时候，Double Write一节（其实只有一小段）就让我很困惑。无奈当时内力太浅，纠缠了很久也没弄明白。时隔几个月，重新来整理一下。

涉及到的概念：Buffer Pool简称BP，Dirty Page，Log file，Flush，innodb tablespace。

1. 什么是Double Write

在InnoDB将BP中的Dirty Page刷（flush）到磁盘上时，首先会将Page刷到InnoDB tablespace的一个区域中，我们称该区域为Double write Buffer。在向Double write Buffer写入成功后，再择机将数据拷贝到正在的数据文件对应的位置。

咋一看，这个过程有些多余

2. 为什么需要Double Write

InnoDB中有记录（Row）被更新时，先将其在Buffer Pool（简称BP）中的page更新，并将这次更新记录到Log file中，这时候BP中的该page就是被标记为Dirty。在适当的时候（BP不够、系统闲置等），这些Dirty Page会被flush到磁盘上。

试想，在某个Dirty Page（一般是16K）flush的过程中，发生了系统断电（或者OS崩溃），16K的数据只有8K被写到磁盘上，这种现象被称为（partial page writes、torn pages、fractured writes）。一旦partial page writes发生，那么在InnoDB恢复时就很尴尬：在InnoDB的Log file中虽然知道这个数据页被修改了，但是却无法知道这个页被修改到什么程度，和这个页面相关的redo也就无法应用了。

举个例子：在InnoDB的log file中有如下Log：

Log sequence number 0 4285149977
Log sequence number 0 4287355447
Log sequence number 0 4289260680
Log sequence number 0 4291279900
Log sequence number 0 4293359020

其中第1、3个Log修改了该page，但是在断电时，BP中该page只被flush了一部分。那么InnoDB是无法决定上面的Log是否应该被应用的。这时，数据就出现了不一致。

所以，Log file的有效应用，前提是InnoDB的数据文件中的Page是一致的。

简而言之，Double write就是为了避免Partial page writes而设计的。

3. Double Write对性能的影响

系统需要将数据写两份，一般认为，Double Write是会降低系统性能的。peter猜测可能会有5-10%的性能损失，但是因为实现了数据的一致，是值得的。Mark Callaghan认为这应该是存储层面应该解决的问题，放在数据库层面无疑是牺牲了很多性能的。

事实上，Double Write对性能影响并没有你想象（写两遍性能应该降低了50%吧？）的那么大。在BP中一次性往往会有很多的Dirty Page同时被flush，Double Write则把这些写操作，由随机写转化为了顺序写。而在Double Write的第二个阶段，因为Double Write Buffer中积累了很多Dirty Page，所以向真正的数据文件中写数据的时候，可能有很多写操作可以合并，这样有可能会降低Fsync的调用次数。

基于上面的原因，Double Write并没有想象的那么糟。另外，Dimitri在测试后，发现打开和关闭Double Write对效率的影响并不大。

4. 相关参数与状态

是否打开了double write:

root@(none) 07:16:16>show variables like "%double%";
+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| innodb_doublewrite | ON    |
+--------------------+-------+

Double write的使用情况：

root@(none) 07:15:50>SHOW STATUS LIKE "%innodb_dblwr%";
+----------------------------+-----------+
| Variable_name              | Value     |
+----------------------------+-----------+
| Innodb_dblwr_pages_written | 145373349 |
| Innodb_dblwr_writes        | 2249336   |
+----------------------------+-----------+

上面可以看到，从BP共Flush了145373349个Pages到double write buffer中；一共调用了2249336次write写到真正的数据文件。可见，相当于每次write合并了 145373349 / 2249336 = 64.6次Flush。（这就是为什么double write buffer为什么并不会对效率有很大影响的原因）

5. 我的看法

在某些文件系统（ZFS等）层面能够保证不出现Partial page writes时，可以关闭Double Write。因为它对性能影响并不大，一般情况都建议打开，毕竟带来的数据安全性保障可能是我们更关心的。

参考文献：

[0]. Manual about Double Write

[1]. Innodb Double Write

[2]. Do you need the InnoDB doublewrite buffer

[3]. MySQL Performance: InnoDB Doublewrite Buffer Impact

---

© orczhou for 一个故事@MySQL DBA, 2010. | Permalink | No comment | Add to del.icio.us
Post tags: innodb

Feed enhanced by Better Feed from Ozh

 

 

DBA日记第三部 像ORACLE一样思考

 

1 前言

每个来应聘DBA的人我都会问他们一个问题：“Oracle到底是什么？”，有些人会用数据库基础的理论来回答我：“数据库是数据的集合”，也有些人会感到茫然，不知道我问这个问题是什么意思。实际上很多Oracle DBA从来没有思考过这个问题。“Oracle就是Oracle，是一个产品，还能有什么意思呢？我不知道Oracle到底是什么也没有影响到我做一个合格的DBA”，很多人都会这么想。

实际上对于Oracle我们确实还需要重新去认识认识，每个DBA在学习Oracle的时候都往往注重于学习如何建库、如何管理、如何编程、如何优化。虽然说这也是学习Oracle数据库最为常见的一种方法，但是这样学习下去，我们总是在记忆一些枯燥的语法和脚本，虽然经过数年我们积累下了大量的经验，但是我们还是无法真正的理解Oracle，数据库升级了，系统变化了，我们就必须从头去学习。常年累月，我们总是在一次一次的循环往复的重复着同样的事情，直到我们筋疲力尽，对Oracle失去往日的激情，最终DBA成为一个职业，Oracle成为我们谋生的手段。

事实上，我们可以换一种方式来学习Oracle，让Oracle的精神融入DBA的血液中，让DBA像Oracle一样思考问题，Oracle作为我们的爱好，作为我们生活的一部分存在。对于大多数DBA来说，这也许只是一个乌托邦式的理想，对于绝大多数DBA来说，我们需要有一份工作，需要靠这份工作来生存，娶妻生子，享受生活。并不是所有的人希望让Oracle成为生活的一部分，这是很现实的，不过我们虽然可以仅仅把Oracle当做是生活的一部分，当做是谋生手段，但是我们也可以同时尝试了解更多的Oracle的本质，让我们像Oracle一样思考。

像Oracle一样思考虽然不能带给你更多的生活乐趣，但是通过这样的方式去学习和思考，我们会更加精确的了解Oracle的精髓，让我们在DBA的成长过程中少走弯路。10多年前我第一次接触JAVA的时候，感到十分头痛。不是自夸，10多年前，我是一个相当不错的C程序员，最高纪录是一天之内编写500多行复杂的代码，而且一次性编译通过，一次性测试通过，这样的记录的诞生是基于十分良好的过程思维能力的。不过当我这个自认为的编程高手第一次接触JAVA的时候，却感到十分吃力。我无法用面向对象的思想去编写程序，所以我学习JAVA的过程十分痛苦，几次学习，最后都放弃了。直到有一天我看到了一本英文的书籍《Thinking in JAVA》，通过这本书，我掌握了JAVA和面向对象设计、编程的主要思路。自从看了这本书之后，我再次面对JAVA程序的时候，发现一切都是那么的简单。很快我就掌握了JAVA编程。现在我虽然还仍然只是一个三流的JAVA程序员，不过粉丝网的一些修修补补的工作我完全能够胜任了，而且在一些和开发人员交流的时候，我也能够很快的理解他们的思路。

后来我总结了一下，在看《Thinking in JAVA》这本书之前，我在编写JAVA程序的时候，并没有理解面向对象编程的概念，只能是照猫画虎，拿着一个例子在上面修改，实际上我的编程风格还是面向过程的，因此写出来的代码质量很差。而通过《Thinking in JAVA》的阅读，我终于学会了硬面向对象的方法，用JAVA本身的思想去考虑问题，因此我能够更加准确的抓住问题的本质。我想，学习Oracle数据库也是这样，如果我们通过一个案例一个案例的去学习Oracle，那么我们将永远停留在表层上，哪怕我们干上10年20年DBA，也可能只能学到Oracle的一些皮毛，一旦碰到一个我们没有见到的案例，可能我们就会感到手足无措。

这些年里我接触过大量的DBA，我一般把这些DBA分为四大类。第一类DBA是经验型的，他们处理问题的主要方式取决于以往的经验，他们往往都有很好的习惯，会把每一个处理过的案例整理出来，今后再碰到这类案例的时候，他们会很快的解决问题。这类DBA随着工作时间的增长，他们的技术也会相应的提高。第二类DBA是理论型的，他们具有很深的理论基础，经常探讨一些“Oracle Internal Only”的高深问题，但是他们在某些方面的研究很深，比如他们能够很清晰的告诉你共享池分配的算法，告诉你checkpoint的工作原理，但是这些DBA往往缺乏实际的工作经验，他们研究Oracle但是很少有机会接触大型的数据库系统，因此他们实际解决问题的能力并不强。第三类DBA是技巧型的，他们并不注重理论的学习和经验的积累，他们在处理问题的时候往往能够利用metalink和谷歌百度之类的工具去搜索解决方案，这类DBA是我见到过的最多的，这类DBA处理问题的时候，往往取决于运气。第四类DBA是虚心请教型的，这类DBA无论碰到什么问题，甚至连错误信息都没有看明白，就开始到处叫“我的系统出问题了”，然后到处去问如何解决。

实际上，这四类DBA都是有缺陷的，第一类DBA可能经过多年的工作，有十分丰富的经验，处理问题的能力很强，而且对分析问题十分敏感，很容易抓到问题的关键，但是由于缺乏深入理解Oracle的理论，因此在碰到一些较为深入的问题的时候，在初期总是很难把握住问题的关键，虽然凭借着自身丰富的经验和问题分析排查能力，他们最终也能解决大部分的问题，但是很多时候问题解决后还是无法真正的弄明白为什么会解决问题，下一次碰到类似的问题，可能还是要花很大的代价。

第二类DBA在某些方面的理论知识很强，总是喜欢研究一些十分高深的原理性的东西，但是这类DBA的主要精力都放在了研究一些Oracle内部原理上了，他们没有更多的时间去实践，去把他们学到的理论融合到实践中去。这类DBA往往知识面较为狭窄，仅精通于自己研究比较深入的领域，在实际工作中也很难发挥出自身对理论研究的成果来。

第三类DBA实际上在我们的现实生活中是最常见的，“万事不明问百度，百度不明就抓瞎”，确实谷歌百度和Metalink能够帮助我们解决不少问题，但是这类DBA往往在问题解决后没有好好思考一下，为什么这个方法能够帮助我们解决问题，更没有认真总结和归纳一下，于是下一次碰到类似的问题，还是无法依靠自己的思考去解决问题，于是再google一把，也许这一次运气没有这么好了，google出来的资料不是上回的那个了，于是结果很可能是很悲惨的。

第四类DBA在我们现实生活中也经常出现，网络社会十分发达，打个电话或者在qq群里，msn里问问，也许就有人帮我解决问题，久而久之，这些人放弃了自己思考问题，碰到一点点小问题都首先问起再说。

看到这里，大家可能明白了，老白实际上说的不是四类DBA，而是DBA的四种性格，这四种性格可能会集中在某一个人身上，以老白学习DBA的经验来看，理论结合实践是十分重要的。在2000年前，老白虽然做了很多项目，也是很多人眼里的Oracle数据库高手，但是在2000年前，老白就是第一类DBA的典型，没有经过多少理论学习，几乎所有的Oracle数据库的技能都是从实践中获得的。虽然在实践中我总结出大量的经验，甚至有很多客户建议我写一本书，把我对Oracle的理解写出来。不过当我自信满满的开始写书的时候，我突然发现，我的一些知识需要进行确认，否则写出来就贻笑大方了。于是我开始大量的学习Oracle的一些理论知识，随着写书的过程的深入，我越发感到自身理论水平的不足。《Oracle数据库深度历险》这本书我写了3年，实际上2002年我就彻底放弃了出版这本书的念头，因为我发现我的理论知识确实还需要进一步的梳理，但是我并没有放弃写书，因为我发现通过写书，我更为系统的将Oracle的理论知识梳理了一遍，这次梳理是通过我以前的知识体系、工作经验，用Oracle Concepts的理论基础进行了一次完整的整合。通过这3年的写作，我终于完全疏通了Oracle的理论体系，好像一个练武术的人，终于打通了任督二脉，感到无比的畅快。

听老白说了这么一大通，是不是很多人都感觉到手脚发凉，难道成为一个合格的DBA有这么难吗？如果我没有打通任督二脉，就不算一个合格的DBA吗？实际上DBA成长的道路是很多的，并不一定要走老白这一条路，老白仅仅是根据自身的经历，通过这本书来帮助大家梳理Oracle的一些基础知识而已，还是那句话，如果Oracle是你的爱好，那么你无论花多大代价去研究它都是值得的，如果Oracle只是你职场生涯中的一个工作而已，那么只要你认真对待他就可以了，没必要像老白那样执着。

在这本书里，老白会把《Oracle数据库深度历险》中的一些内容，结合老白的实际工作经验，剖析起原理，并结合案例来说明这些理论知识如何在实践中实际应用，展现给大家，希望老白的这次写作经历，能够给大家带来一些帮助。

 

 

昨天早上从浦东机场送走老婆孩子后，坐在大巴上，美美的笑了一下：接下来的几天自由了！ 可是早上出门换了件衣服，没带钱，售票员走过来的时候，才发现钱包里除了一堆出租车票，只有1枚硬币。 搜刮衣服的各个兜，终于找到一张5元，一张十元的纸钞和另外4个钢蹦。从浦东机场到龙阳路是16块，从龙阳路到杨高南路地铁是3块，剩余2块！又乐了一下：） 地铁快到站的时候，才找钥匙，发现钥匙也在另一件衣服里，心情有点郁闷。 打电话给老爹，问问老妈有没有在门外什么地方给我放过钥匙。可惜老爹不在家，说等回家后给我打回来。 那只能等了，笔记本也在家里，哪也去不了。转眼已经11点了，肚子有点饿，从裤兜里再搜出3个硬币，去菜市场吃了碗2两的河南拉面。 时间还早，老婆至少要到30分钟后才会达到机场。给岳父打个电话，他已经到机场等着接了，告诉他等她们到了后给我打个电话。 无聊，烦躁，天还下起了小雨！ 到50 的时候，老婆来短信说，到了。 于是回了个短信说我钥匙没带，门外钥匙没有钥匙的话，我就要找师傅来开锁了。 过了两分钟，短信还没回来，打电话过去，没人接。估计是在路上了。老丈人估计把我的话忘记了。没辙，去农工商超市逛逛，我有信用卡，可以在里面卖点吃的喝的。 再不知过了多久，老婆终于来电，说换锁吧，本来老婆还要埋怨两句的，我手机电只有2格了，赶快匆匆挂掉，打电话给换锁师傅（换过2次了，所以电话我一直留着）。 师傅说人在三林，明天换行不？我说不行，他说那我30分钟到吧。 回到小区，雨有点大了，去门卫室，一老头在。 我看到门卫室居然有电脑在开着，桌面上什么也没有，就问他这里怎么会有电脑呢？ 他说“×头”，我问他是不是摄像头，他还说是“X头”，我还是没听懂，他走到门外指给我看，原来就是摄像头，他说的是啥我还是没搞懂。 我问他，那怎么不开画面啊，他说坏了。反正没事，就想帮他看看。原来是28号小区停电后，就一直没用，要输入密码，说明书上是说密码已经设置过，只要点OK就行，可是用户名和密码栏是空白的。 他说管他呢，公安局来装的（包含小区的防盗电缆），这东西又没啥用，由着他吧（类似的话）。 看看那些设备：一台PC机，3台华三的交换机（没搞懂用来干啥），一台viewsonic显示器，机柜大小倒是刚刚合适。 我说，唉，纳税人的钱啊。他说，哪啊，政府的钱，我们下岗了也不让我们退休，买这些破玩意摆样子。 我想，这世道不就是这样么？那么多下岗工人，政府给的起么？ 换锁师傅穿着皮裤，骑着摩托进了小区，还是挺快的，明显不到30分钟。 撬锁，换把手，锁芯。老婆临出门没有提把手（上锁），所以整个过程很快，师傅准备的电钻没有用上。 师傅问，你打电话到公司了没，我说没，他说那200，打到公司的话是300。我说，我上次换锁锁芯才100不是? 他说，那是去年了吧，现在经理换了，铜价也涨了，所以全部提价了。 已经1点多了，进公司。 快下班了，找人吃饭。丫的，都有安排了。 快7点，回到家，煮面条，牛肉，鸡蛋，白菜。 吃完了，看电视，连换了几个台，好久没看电视，连兴趣都没有了。看来要是很久不茉莉，可能性趣也会消失的。 看看书，居然开着灯就睡着了。醒来是早上6点了。 围城无处不在啊

Good Demo.

Author:NinGoo posted on NinGoo.net

PostgreSQL也支持逻辑备库和物理备份两种方式。物理备份可以和Oracle一样实现联机热备份，并且同样也需要将数据库设置为归档模式。

逻辑备份

PostgreSQL提供了pg_dump/pg_dumpall两个程序可以用来将数据dump成文本文件，实现数据的逻辑备份。使用不同的参数，可以将数据dump成PostgreSQL专用的数据格式(生成copy语句)或者标准SQL语句(生成insert语句)格式。恢复只需要简单的使用psql将文件执行一遍即可。另外也可以使用pg_restore工具来恢复数据。

利用pg_dump备份test数据库(只有一张test表)，包括重建表的DDL语句，授权语句等所有信息，生成copy格式的文件：

$ ./pg_dump test
--
-- PostgreSQL database dump
--
SET statement_timeout = 0;
SET client_encoding = 'UTF8';
SET standard_conforming_strings = off;
SET check_function_bodies = false;
SET client_min_messages = warning;
SET escape_string_warning = off;
SET search_path = public, pg_catalog;
SET default_tablespace = '';
SET default_with_oids = false;
--
-- Name: test; Type: TABLE; Schema: public; Owner: postgres; Tablespace:
--
CREATE TABLE test (
    i integer
);
ALTER TABLE public.test OWNER TO postgres;
--
-- Data for Name: test; Type: TABLE DATA; Schema: public; Owner: postgres
--
COPY test (i) FROM stdin;
1
2
\.
--
-- Name: public; Type: ACL; Schema: -; Owner: postgres
--
REVOKE ALL ON SCHEMA public FROM PUBLIC;
REVOKE ALL ON SCHEMA public FROM postgres;
GRANT ALL ON SCHEMA public TO postgres;
GRANT ALL ON SCHEMA public TO PUBLIC;
--
-- PostgreSQL database dump complete
--

利用pg_dump备份test库，只保存数据，insert语句格式：

[postgres@dbconsole bin]$ ./pg_dump --inserts -a test
--
-- PostgreSQL database dump
--
SET statement_timeout = 0;
SET client_encoding = 'UTF8';
SET standard_conforming_strings = off;
SET check_function_bodies = false;
SET client_min_messages = warning;
SET escape_string_warning = off;
SET search_path = public, pg_catalog;
--
-- Data for Name: test; Type: TABLE DATA; Schema: public; Owner: postgres
--
INSERT INTO test VALUES (1);
INSERT INTO test VALUES (2);
--
-- PostgreSQL database dump complete
--

物理备份

和Oracle一样，物理备份可以分为冷备份和热备份。冷备份就是将数据库实例关闭，然后直接复制data目录的所有文件，恢复时只需要将文件copy到data目录，无须利用日志(WAL–Write-Ahead Logging）进行恢复。而热备份，则需要利用日志将数据库恢复到一致状态，因此需要先将数据库置于归档模式。

PostgreSQL归档模式使用参数archive_mode控制，这是一个静态参数，修改postgresql.conf文件，加入如下参数，然后重启生效：

archive_mode = on
archive_command = 'cp "%p" /u01/postgresql/arch/"%f"'
archive_timeout = 600

postgres=# show archive_mode;
 archive_mode
--------------
 on
(1 row)

由于postgresql没有归档进程，因此归档是通过外部命令(OS)完成的，archive_command用于指定该外部命令，具体格式请参考文档。如果是linux归档到本地，使用cp即可，如果是到远程，则可以使用scp或者rsync。archive_timeout强制N秒以后进行一次归档，这个和Oracle的archive_lag_target参数的作用一样。当然也可以手工进行日志切换：

postgres=# select pg_switch_xlog();
 pg_switch_xlog
----------------
 0/7000000
(1 row)

热备份前，需要先将数据库置于备份状态，这一点和Oracle的手工也备份也是一样的。该命令会导致一次checkpoint，可能在业务高峰期会带来一些压力和风险，因此备份还是需要安排在业务低谷期间执行比较稳妥。

postgres=# select pg_start_backup('test_backup');
 pg_start_backup
-----------------
 0/8000020
(1 row)

然后在os层面将data目录进行复制备份。完成后，再取消备份状态，该命令同时会执行一次日志切换，并进行归档，以保证热备份期间的日志都已经归档，保证恢复数据库到一致状态的所有日志都能从归档中找到：

postgres=# select pg_stop_backup();
 pg_stop_backup
----------------
 0/8000088
(1 row)

备份完成后，可以在归档目录找到一个记录了本次备份信息的文件：

$ more 000000010000000000000008.00000020.backup
START WAL LOCATION: 0/8000020 (file 000000010000000000000008)
STOP WAL LOCATION: 0/8000088 (file 000000010000000000000008)
CHECKPOINT LOCATION: 0/8000020
START TIME: 2010-02-03 12:24:57 CST
LABEL: test_backup
STOP TIME: 2010-02-03 12:24:59 CST

PostgreSQL官方并没有提供和Oracle的rman一样的备份工具，不过因为PostgreSQL是开源的数据库，因此也有一个开源的工具pg_rman可以使用，从命令行来看功能已经非常强大，暂时还没有测试，有兴趣的可以研究一下。

pg_rman [ OPTIONS ] { init | backup | restore | show [ DATE | timeline ] |
 validate [ DATE ] | delete DATE }

Related Articles

• PostgreSQL安装
• PostgreSQL简介
• lvm2与powerpath的Found duplicate PV问题
• 入手Canon 450D
• 震撼推荐：魔兽史诗巨作《远古传说3》
• XtraDB存储引擎

PermLink: http://www.ningoo.net/html/2010/postgresql_backup.html

Add Comments(0) | Follow NinGoo@Twitter | Google Reader

今天上午我一个同事误truncate了一个表uplbth，她问我是否可以恢复？

我们先去看一下这个表现在的状况：

SQL> select owner,object_name,object_id,data_object_id from dba_objects where object_name='UPLBTH';

 

OWNER                        OBJECT_NAME      OBJECT_ID DATA_OBJECT_ID

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

CAIPRA                         UPLBTH               52210          95137

从结果里我们可以看到，这个表的data object id已经比其object id大了太多，极有可能是曾经被多次truncate过。

后来我问了一下她是否多次truncate过这个表，她说是。然后我对她说，你等我信儿吧。

 

熊哥曾经在"使用ODU恢复Truncate表"这篇文章里提到了如何确定被多次truncate后的data object id，我这里用另外一种方式来精确定位我要恢复的data object id。

 

利用的原理就是：oracle里有system回滚段，而oracle对数据字典的操作基本上是DML，既然是DML，那就好办了，我们有很大的概率可以成功执行flashback query。

 

回到刚才的例子，我首先从dba_objects里知道了uplbth的last_ddl_time是2010-2-3 10:18:57；接着，我们直接执行flashback query来确定在执行truncate操作的那个时间点之前uplbth的data object id：

SQL> select  owner,object_name,object_id,data_object_id from dba_objects as of timestamp to_timestamp('2010-02-03 10:18:00','YYYY-MM-DD HH24:MI:SS') where object_name='UPLBTH';

 

OWNER                          OBJECT_NAME      OBJECT_ID DATA_OBJECT_ID

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

CAIPRA                         UPLBTH               52210          77675

 

可以看到，当时的data object id是77675，精确的确定了data object id后，剩下的事情就都交给ODU好了：

ODU> unload table caipra.uplbth object 77675

 

Unloading table: UPLBTH,object ID: 52210

Unloading segment,storage(Obj#=52210 DataObj#=77675 TS#=16 File#=15 Block#=18828 Cluster=0)

1888 rows unloaded

 

可以看到，我们成功恢复出来了1880条数据。

注意，这里你用logmnr在缺省情况下是挖不出来data object id的，朋友们可以自己试一下。

在前两篇（前篇、中篇）中，分别介绍了Key Cache的基本原理（LRU和Midpoint Insertion Strategy）。最后，将介绍一些相关的参数、状态参数和命令。

Key Cache的配置很灵活，可以针对全局配置，还可以针对某个单独数据表分配Key Cache的大小；如果一个数据表某部分的索引块被访问的非常频繁（较之其他索引块），那么可以配置Midpoint Insertion Strategy达到最大的利用率(参考)。

1. 如何配置Key Cache的大小

另外，Key Cache的大小可以动态的改变

2. 给数据表划分单独的Key Cache

例如：划分一块128K的Key buffer空间，指定数据表t1的Key cache放在里面。最后演示了如何删除这个特定的Key buffer空间。

3. 预先载入某些数据表的索引

4. 关于Key Cache的使用情况观察 Flush现象

mysql> show status like "key%";
+------------------------+----------+
| Variable_name          | Value    |
+------------------------+----------+
| Key_blocks_not_flushed | 14468    |
| Key_blocks_unused      | 0        |
| Key_blocks_used        | 14497    |
| Key_read_requests      | 30586575 |
| Key_reads              | 157      |
| Key_write_requests     | 7100408  |
| Key_writes             | 1199800  |
+------------------------+----------+
mysql> flush tables;             （注意，请不要在业务高峰期执行）
+------------------------+----------+
| Variable_name          | Value    |
+------------------------+----------+
| Key_blocks_not_flushed | 0        |   #所有修改的block都已经被flush了
| Key_blocks_unused      | 0        |
| Key_blocks_used        | 14497    |
| Key_read_requests      | 38333936 |
| Key_reads              | 207      |
| Key_write_requests     | 8819898  |
| Key_writes             | 1255245  |
+------------------------+----------+

5. 需要注意的事项

内存中缓存的索引块（Key Cache），有时候并不会及时刷新到磁盘上，所以对于正在运行的数据表的索引文件（MYI）一般都是不完整的。如果此时拷贝或者移动这些索引文件。多半会出现索引文件损坏的情况。

可以通过Flush table命令来将Key Cache中的block都flush到磁盘上。所以，一般要动态移动MyISAM表需要执行以下步骤：

首先，刷新数据表，并锁住数据表：（注意，请不要在业务高峰期执行）

可以通过下面的命令来查看没有被Flush的索引块数量

mysql> show status like "Key_blocks_not_flushed";
+------------------------+----------+
| Variable_name          | Value    |
+------------------------+----------+
| Key_blocks_not_flushed | 0        |
+------------------------+----------+

最后，移动对应的文件（MYI MYD FRM）。

参考

1. MySQL Manual about Key cache

---

© orczhou for 一个故事@MySQL DBA, 2010. | Permalink | No comment | Add to del.icio.us
Post tags: MyISAM, MyISAM Key Buffer

Feed enhanced by Better Feed from Ozh