作者：Fenng 发布在 dbanotes.net.

简要回顾一下 2009 年数据库技术领域。过去的一年，差不多也可以说是过度的一年，数据库技术以及数据存储产品等都都或多或少发生一些方向上的转变。

Oracle 收购 Sun，MySQL 前途未卜

Oracle 收购 Sun 可谓一波三折。在获得美国司法部门的批准后，欧盟委员会又开始调查，Oracle 随后抛出一个"十条保证"，眼看着欧盟就要点头，没想到 MySQL 创始人 Michael Widenius(Monty) 则在这个当口不失时机的搞出来一个"拯救 MySQL"的抵制活动，让 Oracle 头疼不已。Monty 这人多少也有点上纲上线，现在已经将 MySQL 的命运和 "Internet Free"这个大话题绑在一起了。

没有人会相信 Oracle 会善待 MySQL，谁会干放虎归山的事情呢? 换了你也会把 MySQL 雪藏起来，毕竟商业公司就要逐利。但是，也很难说一旦收购完成后 ，MySQL 会在短期内消失，基于 MySQL 众多开源分支以及解决方案也都发展的不错，我相信最终决定权还是在用户的手里。就算没有 MySQL，也没准儿会有 YourSQL 出来的...

尽管口水战还在进行，MySQL 的开发者倒是没闲着，在年底发布了 5.5 第二个里程碑版本，原来站点上的 6.0 系列的信息全部撤掉。5.5 更像一个集成版本，将不少第三方贡献的功能改进(比如 Google 的 Patch)融合了进来。

而 Oracle 这一年在产品上的一个标志性事件是推出了 Exadata 存储第二版，与第一个版本不同的是，这一个版本在 OLTP 方面增强了许多。从这个版本开始，Oracle 正式拥有自己的存储硬件(第一版是和 HP 合作的产物)。RDBMS 上，除了发布 11g 第二版之外，也在做功能上的调整，这一次，面向的是数据中心。

NoSQL 的兴起

这是今年数据库领域最有趣的话题。NoSQL 的由来大约是这样的：当时还效力于 Last.FM 的 Johan Oskarsson （现在已经投靠 Twitter 了)组织了一个技术会议，话题是关于"open source, distributed, non relational databases"，为了方便一点，想出来一个 "NoSQL" 的术语。然后由 Rackspace 的 Eric Evans 引用，进而流传开来(refer)。NoSQL 在基于 Key-value 的存储解决方案上提倡去 SQL 化，尤其避免表连接，并且通过一些变通的办法提供 RDBMS 的 ACID 功能（如果需要的话）。

NoSQL 的理念能够短时间内被技术圈所接受，离不开基本的理论支撑：最终一致性、BASE 、CAP 这三大基石；一方面是基于 Key-Value 的数据存储解决方案更加成熟，

所谓 NoSQL ，是针对当前对关系型数据库的过度依赖与运用而言，不要将其当成万能药，也没必要过于激进的推行 NoSQL 的模式。在我看来，NoSQL 是针对争夺应用模式上的一种理念上的运用。对多数企业来说，仍属屠龙之技，没必要照搬解决方案。至于传统的 RDBMS 是不是已经走向末路，我认为不尽然。RDBMS 依然尤其广泛的应用场景，而NoSQL如果要有更大的作为也要有来自商业上的更大支持才会有所突破。

SSD 被更多企业接受

Jim Gray 在 2006 年的那句名言：Tape is Dead，Disk is Tape，Flash is Disk，RAM Locality is King ，现在正在被现实所验证。2009 这一年，用户已经开始进一步试水 SSD 产品，包括 MySpace、Last.FM 等网站已经开始在关键应用上部属 SSD(refer: 1, 2)。而国内也有很多企业对 SSD 进行尝试性的使用，这其中包括阿里巴巴、优酷。

更多的存储厂商已经在高端存储中兼容 SSD ，除了去年的 EMC 尝鲜之外，现在 IBM、HDS 、NetApp 都加入了这一阵营。

。

随着 SSD 的价格迅速下降，很多存储厂商已经开始调整硬件架构，现在有个看似可行的趋势是在 Cache 层与磁盘层之间多构建一个 SSD 存储层，在成本与性能之间做一个折衷。

在去年年底的回顾中，我曾大言不惭的说"相信2009 年会是 SSD 爆发的一年"，总体来看，2009 年对 SSD 的部属还谈不上"爆发"。中规中矩而已。

Amazon EC2 对 MySQL 企业版的支持

尽管我不愿意谈云计算，不过 Amazon 这一年在云计算方面还是做了很大的突破，Amazon EC2 上面现在已经可以跑 MySQL 企业版了，采取按照增长付费 ('Pay-as-we-Grow') 的模式让初创公司有更多的选择，这比 SimpleDB 可以说是前进了一大步。 这种模式在国内是否可行，考虑到当前内容审查的问题，还有待商榷。

国内 Key-Value 产品

这一年来国内对 Key-Value 产品的研究与运用和国外基本没太大的距离，豆瓣网先作出了不错的表率，发布了 BeansDB 存储系统，这是一个豆瓣风格的 Dynamo 实现，采用类似 Memcached 的去中心化结构。而最近得到的消息说人人网也要将其内部使用的存储系统 Nuclear 开源。相信在新的一年可供参考的 Key-Value 会层出不穷。

其它方面

Hadoop 过去一年中没有太大的变化，上了一点规模的网站都在用，快成了 Web 数据分布式计划的标准组件了。Doug Cutting 出走 Yahoo! 还是带来了一定的影响 ，不知道今后 Yahoo! 在 Hadoop 方面的支持力度会如何。至于面向列的 DB 发展情况，在过去的一年中进展不大。SQL Server 和 DB2 等方面似乎没什么可圈可点的大事，倒是 PostgreSQL 因为 MySQL 的不确定性而取得了不小的增长。

有一点要补充的是，假以时日，Open Data 或许也将成为一个趋势。

当然，这份回顾有浓郁的个人色彩，有不同意见请留言探讨吧。

--EOF--

本文发表在《程序员》杂志，不过这里的有些许更新。本文写作时，Oracle 收购 Sun 还没有尘埃落定，现在看起来，一切都变化太快。

---

最近文章|Recent Articles

• 借助 Complemento 测试 DoS 攻击风险
• Oracle Exadata 技术浅析
• 编程语言的选择并非无关紧要
• 大象跳舞

本站赞助商：豆瓣网

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

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

有朋友在itpub上问backupset和backuppiece的区别，我很能理解这位朋友为什么会有这样的疑问，因为我在六年前看9i OCP的培训教材的时候也不明白这两者之间的区别是什么。

 

我们只需要做如下这样一些测试并配合list backup就可以知道backupset和backuppiece的区别了：

1、多个channel并且指定filesperset：

configure device type disk parallelism 3;

run{

backup incremental level=0

format 'D:\oracle\oradata\testdb\backup\testdb_%t_%s_%p.bak' database

filesperset 3;

}

 

2、单个channel且不指定filesperset：

configure device type disk parallelism 1;

run{

backup incremental level=0

format 'D:\oracle\oradata\testdb\backup\testdb_%t_%s_%p.bak' database;

}

 

3、单个channel且指定maxsetsize：

configure device type disk parallelism 1;

configure maxsetsize to 450M;

run{

backup incremental level=0

format 'D:\oracle\oradata\testdb\backup\testdb_%t_%s_%p.bak' database;

}

 

4、单个channel且指定maxpiecesize：

configure device type disk parallelism 1;

configure maxsetsize to unlimited;

run{

allocate channel c1 device type disk maxpiecesize 300M;

backup incremental level=0

format 'D:\oracle\oradata\testdb\backup\testdb_%t_%s_%p.bak' database;

release channel c1;

}

 

5、多个channel且指定filesperset，但请注意filesperset的位置：

configure device type disk parallelism 3;

run{

backup incremental level=0

format 'D:\oracle\oradata\testdb\backup\testdb_%t_%s_%p.bak' database

plus archivelog

format 'D:\oracle\oradata\testdb\backup\testdb_arc_%t_%s_%p.bak'

delete all input

filesperset 2;

}

 

6：多个channel且指定filesperset，但请注意filesperset的位置：

configure device type disk parallelism 3;

run{

backup incremental level=0

format 'D:\oracle\oradata\testdb\backup\testdb_%t_%s_%p.bak' database filesperset 2

plus archivelog

format 'D:\oracle\oradata\testdb\backup\testdb_arc_%t_%s_%p.bak'

delete all input;

}

 

从结果里我们可以得到如下结论：

1、  backupset由backuppiece组成，每一个backuppiece就是一个单个的物理文件；

2、  如果你在分配channel的时候不指定maxpiecesize，则每个backupset只会包含一个backuppiece；反之一个backupset里会有多个backuppiece（即物理文件）；

3、  一次备份中backupset的数量跟分配channel的个数、是否指定filesperset、filesperset的位置、是否指定maxsetsize有关。

 

filesperset的位置很关键，比如我这里有10个datafile需要备份，那么上述测试5对这10个datafile（不含archivelog）会产生多少个backupset？测试6呢？

 

答案是测试5产生了3个backupset，测试6产生了6个backupset（这里请正确理解filesperset 的含义）。

 

杭州市人大于2009年5月1日颁布实施《杭州市计算机信息网络安全保护管理条例》（下称《条例》），其中设立的“网络实名制”条款，属国内首创，十分引人注目。该《条例》第十九条规定：“互联网信息服务提供者应当建立并落实以下安全保护制度和安全保护技术措施：......（三）提供电子公告、网络游戏和其他即时通信服务的，具有用户注册信息和发布信息审核功能，并如实登记向其申请开设上述服务的用户的有效身份证明”。

早在2002年，清华大学李希光教授就提出“人大应该禁止任何人网上匿名”，引来网友集体炮轰，最后不了了之。在全国其它省市都尚未出台“网络实名制”相关规定的状况下，杭州《条例》是否能在本地管辖范围内的网站有效推行，值得研究。

首先，该《条例》由杭州市人大颁布，只能管辖杭州市行政区划范围内的网络信息服务提供商。若有关部门严格按照《条例》中的“网络实名制”条款实施，那么必将导致杭州本地网站显得“鹤立鸡群、独树一帜”，从而促使用户向杭州之外的其它网络管制宽松地区迁移。众所周知，互联网中的迁移成本极低，不必像“春运”那样漏夜排队、长途颠簸，只消轻点鼠标，刹那间便可转到千里之外。如果杭州一直坚持严格实施《条例》，而其它地方在短期内不出台“网络实名制”规定，那么杭州本地网站也会逐步迁移到运营成本较低的其它地区。

其次，“网络实名制”条款如果要完全严格实施，监管成本也很高。在假证泛滥的当今时代，仅仅“见证注册”显然是不能符合《条例》立法本意的。只有让各网站的注册系统与公安部全国身份证查验系统对接，才能验证所提交身份证的真实性。这还远远不够，为了防止盗用他人身份证，得通过生物信息验证手段，如虹膜、指纹等，确认申请人与所提交身份证的一致性。如此，才能真正实现立法本意。然而，由此带来的成本是巨大的，公安部全国身份证查验系统的并发承受能力，生物信息验证设备的成熟度和普及率，都将面临挑战。

作者：eygle 发布在 eygle.com

今天帮助客户在RedFlag Linux上安装了一套Oracle 10gR2 RAC，这是第一次接触红旗Linux，发现其中文化和Windows办公化作的很好，X Windows启动就仿佛Windows 2000的样子。

而且红旗内置了为Oracle而设置的参数和软件包，客户装好了OS之后，我没有打任何rpm包即可正常安装Oracle软件。

基础安准过非常顺利，但是设置高内存是遇到OUT OF MEMORY的错误，Kamus遇到过：

SQL> startup nomount
ORA-27102: out of memory
Linux-x86_64 Error: 28: No space LEFT ON device

这和内核参数 shmall 有关，修改设置 kernel.shmall = 16475728 。

后来离开没多久，客户打电话说两台机器都挂了，我检查了一下message信息：

Feb  5 16:57:22 ywg1 kernel: bnx2: eth1 NIC Copper Link is Down
Feb  5 17:02:55 ywg1 syslogd 1.4.1: restart.
Feb  5 17:02:55 ywg1 syslog: syslogd startup succeeded
Feb  5 17:02:55 ywg1 kernel: klogd 1.4.1, log source = /proc/kmsg started.
Feb  5 17:02:55 ywg1 kernel: 4.S2E0.S2E9 OSHP fails=0x5
Feb  5 17:02:55 ywg1 syslog: klogd startup succeeded
Feb  5 17:02:56 ywg1 irqbalance: irqbalance startup succeeded
Feb  5 17:02:56 ywg1 netfs: Mounting other filesystems:  succeeded
Feb  5 17:02:56 ywg1 rc: Starting lm_sensors:  succeeded
Feb  5 17:02:56 ywg1 mDNSResponder:  startup succeeded
Feb  5 17:02:56 ywg1 acpid: acpid startup succeeded
Feb  5 17:02:57 ywg1 sshd:  succeeded
Feb  5 17:02:57 ywg1 crond: crond startup succeeded
Feb  6 01:02:18 ywg1 rc.sysinit: -e

发现有网卡Down的信息，问了客户，有人折腾网线。

再看message信息里有大量的pci告警信息，系统初始化之后就存在，原因未知，不知道有人遇到过没有：

Nov 29 18:12:33 YWG1 kernel: pciehp: acpi_pciehprm:\_SB_.PCI0.PT04.S2E0.S2E9 OSHP fails=0x5
Nov 29 18:12:33 YWG1 kernel: pciehp: acpi_pciehprm:\_SB_.PCI0.PT04.S2E0.S2E9 _HPP fail=0x5
Nov 29 18:12:33 YWG1 kernel: pciehp: acpi_pciehprm:\_SB_.PCI0.PT04.S2E0.S2E9 OSHP fails=0x5
Nov 29 18:12:33 YWG1 kernel: pciehp: acpi_pciehprm:\_SB_.PCI0.PT04.S2E0.S2E9 _HPP fail=0x5
Nov 29 18:12:33 YWG1 kernel: pciehp: acpi_pciehprm:\_SB_.PCI0.PT04.S2E0.S2E9 OSHP fails=0x5
Nov 29 18:12:33 YWG1 kernel: pciehp: acpi_pciehprm:\_SB_.PCI0.PT04.S2E0.S2E9 _HPP fail=0x5
Nov 29 18:12:33 YWG1 kernel: pciehp: acpi_pciehprm:\_SB_.PCI0.PT04.S2E0.S2E9 OSHP fails=0x5
Nov 29 18:12:33 YWG1 kernel: pciehp: acpi_pciehprm:\_SB_.PCI0.PT04.S2E0.S2E9 _HPP fail=0x5
Nov 29 18:12:33 YWG1 kernel: pciehp: acpi_pciehprm:\_SB_.PCI0.PT04.S2E0.S2E9 OSHP fails=0x5
Nov 29 18:12:33 YWG1 kernel: pciehp: acpi_pciehprm:\_SB_.PCI0.PT04.S2E0.S2E9 _HPP fail=0x5

安装难度不大，不过遇到不少问题。

-The End-

相关文章|Related Articles

• Oracle10g Rac For Linux安装环境检查
  
• Linux RAC OCFS文件系统与INODES
  
• Linux many lost ticks 和 NIC Copper Link Down
  
• 10.2.0.4 RAC CRS-0184错误 CRS 无法启动案例
  
• 并行查询的 PX Deq: reap credit 等待
  

评论数量(1)|Add Comments

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

作者：Fenng 发布在 dbanotes.net.

前几天从 Sourceforge 上的一篇文章了解到 Complemento 这个工具包，其中的 LetDown 用来做网站网络的压力测试，预防 DoS (拒绝服务)攻击还是不错的，起码可以熟悉一些常见的场景。另外，这个工具可以比较方便的嵌入到 Python 脚本中，用来做更大规模的压力测试(注意随意测试是有风险的)。

Complemento 的 HowTo 文档比较完备，可以用作参考。这个工具包现在也已经内置到 BackTrack 这个用作安全渗透的 Linux 发行版中了。

最近一两年，DDoS 攻击在国内现在更加"流行"而且商业目的明显，经常用做打击竞争对手的武器。当然现在也不只是打Web服务器，也可能会打打 DNS 什么的...

其实我非常好奇各个公司的技术人如何应对 DDoS 的，除了拼硬件，拼带宽，或许饭桌和钱是最好的防御手段。

--EOF--

BTW，Nessus 仍然是扫描系统漏洞的最佳工具，居家旅行...必备...

---

最近文章|Recent Articles

• 借助 Complemento 测试 DoS 攻击风险
• Oracle Exadata 技术浅析
• 编程语言的选择并非无关紧要
• 大象跳舞

本站赞助商：豆瓣网

评论数(4)|添加评论 | 最近作者还说了什么? Follow Fenng@Twitter
本文网址：http://www.dbanotes.net/security/complemento_denial-of-service.html

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

最近一直在看中医，主要么，是调理肠胃兼气血。

发现自从吃了中药以后，每天吃饭都会比以前多很多，以前吃饭都不会添第二碗的，现在一般米饭要吃两碗了，而且，第一次哟，体重称的时候，超过60kg（当然是毛重了），以前都是56-58的。

看来中医还是很牛逼的，就是中药有点贵，基本上，一副中药分两次喝，每杯都和两岸的卡布奇诺价格差不多了。

 继续中医。

 

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