www.eygle.com

---

July 28, 2007

猜一猜Oracle11g的第一个发布版本

作者:eygle

出处:http://blog.eygle.com

自从纽约7.11的发布会之后，大家都在期待着Oracle11g的出现，但是除了部分文档之外，Oracle Database11g的安装软件始终没有出现，这说明Oracle11g发布前的准备工作还没有完成。

在下周开始的上海Oracle Open World大会上，更多、更集中的Oracle11g介绍将会涌现。
那么Oracle究竟在什么时候才会提供软件的下载？Oracle第一个发布的11g版本将会是多少么？

这些猜测的答案可能很快揭晓。

目前已知的，Oracle11g的测试版版本已经达到了11.1.0.5.0：

SQL> select * from v$version;
BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.1.0.5.0 - Beta
PL/SQL Release 11.1.0.5.0 - Beta
CORE 11.1.0.5.0 Beta
TNS for Linux: Version 11.1.0.5.0 - Beta
NLSRTL Version 11.1.0.5.0 - Beta

这说明Oracle的第一个发布版本至少是从11.1开始的，而且版本号会相当高
根据时间推测，Oracle11g的第一个正式版本的版本号极有可能为11.1.0.6;当然如果好玩一点，Oracle可以发布一个11.1.0.11版本：）

不过不管怎样，版本号的升高表示了Oracle做了越来越多的测试，发现和解决了大量的软件问题。
所以，我们应该有足够的耐心进行等待。

另外据可靠消息，Oracle将以9月19日于上海，9月20日于北京举行Oracle11g的Launch大会，到那个时候，大家应该已经看到了Oracle11g。

-The End-

Posted by eygle at 4:12 PM | Comments (6)

---

遭遇Magpie多年前的一个Bug

作者:eygle

出处:http://blog.eygle.com

昨天有朋友在MSN上告诉我，我的Erss不能访问了，我看了一下果然是出了问题，错误提示是：

Fatal error: Only variables can be passed by reference
in .../inc/magpie/rss_parse.inc on line 352

我的RSS订阅用的是DCBA增强过的Lilina,而Lilina的后台用的是Magpie，这个问题显然出在Magpie上。

Google一下，赫然发现居然遭遇了几年前Magpie的一个Bug，解决方案早已给出，extlib/rss_parse.inc需要修正，diff文件在以下地址可以找到：
http://svn.gregarius.net/trac/attachment/ticket/175/namespace.diff

主要的变更为：

extlib/rss_parse.inc

old	new
350	350	if ( $this->current_namespace )
351	351	{
352	352	if ( $this->initem ) {
	353	$real_element = "";
	354
	355	$element_tree = explode("_", $el);
	356	$real_element =& $this->current_item[ $this->current_namespace ];
	357
	358	foreach ($element_tree as $tree_element) {
	359	if (!is_array($real_element)) {
	360	$real_element = array();
	361	}
	362
	363	$real_element =& $real_element[$tree_element];
	364	}
	365
353	366	$this->concat(
354		$this->current_item[ $this->current_namespace ][ $el ], $text);
	367	$real_element, $text);
355	368	}
356	369	elseif ($this->inchannel) {
357	370	$this->concat(
...	...
367	380	}
368	381	}
369	382	else {
370		if ( $this->initem ) {
	383	if ( $this->initem && !is_array($this->current_item[ $el ])) {
371	384	$this->concat(
372	385	$this->current_item[ $el ], $text);
373	386	}

不过有一点不解的是，这个Bug是怎么触发的？为什么今天被我遇到了?
记录一下，也许还有别人会遇到的。

-The End-

Posted by eygle at 2:13 PM | Comments (2)

---

一则简单的磁盘的iops测试

作者:eygle

出处:http://blog.eygle.com

刚刚通过ftp从服务器上下载一个大文件，顺便观察了一下服务器的io负载。
通过iostat获取了以下数据：

[root@jumper init.d]# iostat -d hda 2
Linux 2.4.21-15.EL (jumper.hurray.com.cn) 07/28/2007
Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
hda 122.00 14364.00 60.00 28728 120
hda 129.50 14624.00 104.00 29248 208
hda 162.00 14164.00 208.00 28328 416
hda 118.00 12844.00 76.00 25688 152
hda 140.00 16912.00 72.00 33824 144
hda 137.00 16276.00 60.00 32552 120
hda 110.50 12472.00 28.00 24944 56
hda 139.00 16664.00 76.00 33328 152
hda 124.50 13616.00 88.00 27232 176
hda 143.00 16272.00 128.00 32544 256
hda 136.00 17040.00 8.00 34080 16

iostat的tps代表：

tps
Indicate the number of transfers per second that were
issued to the device. A transfer is an I/O request to the
device. Multiple logical requests can be combined into a
single I/O request to the device. A transfer is of inde-
terminate size.

在单存的IO压力下，这个数据可以认为就是表征磁盘处理能力的iops，同时通过vmstat观察系统资源情况:

[gqgai@jumper gqgai]$ vmstat 2
procs memory swap io system cpu
r b swpd free buff cache si so bi bo in cs us sy id wa
1 2 276824 6568 4284 462568 0 0 0 2 1 1 0 0 1 0
0 3 276824 6324 4144 463644 44 98 3186 186 1416 630 0 13 0 86
0 2 276824 6524 4040 463364 22 168 2266 172 929 507 1 6 0 92
0 2 276824 6540 4008 463720 6 114 2338 196 1073 525 2 11 0 87
3 0 276936 6628 4016 463588 76 168 4202 170 1785 652 1 17 0 81
1 2 276948 6388 3968 463752 50 40 3786 88 1686 682 2 16 0 82
1 2 276948 6548 3780 463856 110 92 4074 236 1796 723 1 20 0 79
1 0 276864 6832 3692 464928 88 98 3502 304 1620 733 1 19 0 80
1 0 276864 6452 3628 465464 2 102 5116 168 2400 860 0 26 26 48

此时系统iowait很高，可以近似认为IO负载达到了峰值。
通过下图我们可以看到：

这块磁盘的iops最大可以达到160，而平均在120～140之间。单磁盘的iops速度这么多年没有发生什么太大的变化。

-The End-

Posted by eygle at 10:19 AM | Comments (0)

---

记录一下Drop表空间的速度

作者:eygle

出处:http://blog.eygle.com

上次为了测试，创建了一个大表空间，这个表空间有28G,创建时极其耗时，今天需要空间，删除这个表空间，速度非常的快：

C:\>sqlplus "/ as sysdba"

SQL*Plus: Release 9.2.0.6.0 - Production on 星期六 7月 28 09:54:30 2007
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

连接到:
Oracle9i Enterprise Edition Release 9.2.0.6.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.6.0 - Production

SQL> select sum(bytes)/1024/1024/1024 from dba_data_files
2 where tablespace_name='EYGLE';

SUM(BYTES)/1024/1024/1024
-------------------------
28.1152344

SQL> set timing on
SQL> drop tablespace eygle including contents and datafiles;

表空间已丢弃。

已用时间: 00: 00: 14.01

可见建设复杂，毁坏却极其容易。

-The End-

Posted by eygle at 9:56 AM | Comments (6)

---