分类归档: Database

Oracle 9iR2 的扩展服务支持

偶然发现 Oracle 宣布了对 9iR2 的扩展服务支持(Extended Support)。原定 9i 的产品周期是到 07 年的七月终止。可能是考虑到 10g 的不稳定或者是 9i 不想迁移的用户实在太多了吧，Oracle 现在提供对 9i 产品继续支持，而且是免费的。具体的内容包括：

Extended Support fee waived for period August 1, 2007 to July 31, 2008.
Access to Fixes and Critical Patch Updates (CPUs) during the first year of Extended Support at no additional cost.
Patch set 9.2.0.8 will be the last patch set available for Oracle9i Database Release 9.2.

Effective August 1, 2007 all CPUs and Fixes will be created against the 9.2.0.8 code line.

其中要注意的是 9.2.0.8 一下的 PatchSet 已经不被支持。想得到 Oracle 的支持服务卡那里必须要升级到 9.2.0.8 才成。
这个扩展服务支持为期一年，不知道一年后将怎样，到时候都奥运了 :)
–EOF–

在 AMD64 机器 (RHEL 4) 上部署 Oracle 9i

这几天一直忙着折腾系统，抽空安装了好几台大大小小的服务器上的 Oracle，简单说说在 AMD 64 机器(RHEL 4) 上部署 Oracle 的注意事项。

首先, Werner Puschitz 的 Oracle 安装指导肯定是要看看的，特别注意其中要求的安装包，glibc-devel 包 32 位与 64 位都是需要的。查询语句如下：

rpm  --queryformat "%{NAME}-%{VERSION}.%{RELEASE} (%{ARCH})\n" -q make \
binutils \
gcc \
cpp \
glibc-devel \
glibc-headers \
glibc-kernheaders \
compat-db \
compat-gcc \
compat-gcc-c++ \
compat-libstdc++ \
compat-libstdc++-devel \
gnome-libs \
openmotif21 \
setarch

第二个必需要注意的地方是 gcc 工具的处理，与 32 位操作系统略有不同：

mv /usr/bin/gcc /usr/bin/gcc.orig
mv /usr/bin/g++ /usr/bin/g++.orig
ln -s /usr/bin/x86_64-redhat-linux-gcc32 /usr/bin/gcc
ln -s /usr/bin/x86_64-redhat-linux-g++32 /usr/bin/g++

$LD_ASSUME_KERNEL 环境变量要设定:

export LD_ASSUME_KERNEL = 2.4.19

这个变量如果不设定的话，安装的画面会一直 Hang 在那里。

有的兼容软件可以在 Oracle Compatibility 项目主页上下载，compat-libcwait 与 compat-oracle 这 2 个包是必须的。

Oracle 的安装还是一如既往的麻烦，考虑到每台机器还要打 Patchset，然后是一堆过渡性补丁，绝对是体力活。

–EOF–

闲扯 DST (Daylight Saving Time) 与 Oracle

这段时间在邮件列表中讨论最多的一个话题就是 DST(Daylight Saving Time)。这个 DST 我们以前称之为”夏令时”，不过英文的叫法似乎更直接(日光节省时、节能时)，更能引起人们重视–节约能源。

啥是 DST?

美国加拿大实行 DST 的时间是 3 月的第二个星期天早晨两点开始到 11 月的第一个星期日的早晨两点。三月第二个个星期日早晨两点所有时钟向前回拨一个小时，到 11 月 DST 截止再拨回来。我查了一下，以前似乎不是强制的，这和现任总统小布什签署的 Energy Policy Act of 2005 法案有关。而 2007 年是改方案实行的第一年。
Daylight Saving Time , DST.gif
很明显，对于计算机操作系统与数据库来说，这样折腾来折腾去的不可能靠人手工去调整时间，所以很多欧美软件产商纷纷推出软件补丁来解决这个问题。规模之大足以让人想起千年虫的事件。

DST 与 Oracle

Oracle 数据库的调整可以从 Oracle 站点上的这个指导开始： Oracle Database Daylight Saving Time Update Guide。因为需要打新的软件补丁，数据库必需要进行重新启动。所以很多在线应用必需要忍受这次调整带来的影响。

DST 影响中国么?

我国因为取消了夏令时制度，这可能是因为能源问题虽然更加紧迫，但因为时间变来变去给人们带来的麻烦更多而取消的吧。具体的原因我不清楚，谁知道麻烦告诉我一下。如前所述，国内的 DST 问题实际上是不存在的。当然，如果你的服务器是放在美国或者加拿大，或者是面向这两个地区的用户，就需要评估一下影响了。

关于夏令时

我国曾于1986年到1991年每年从四月的第二个星期天早上2点钟，到九月的第二个星期天早上2点钟，在这段时期内，全国都将时间拨快1小时，实行夏令时。从九月的第二个星期天早上2点钟起，又将拨快的时间重新拨回来，直到第二年四月的第二个星期天早上2点钟。

Linux 怎么应对 DST?

Linux 厂商会有一个官方指导(比如 Redhat 的 DST 指导 )。如果是个人 PC，不妨参考这个：Switching your Linux systems to the new DST。
-EOF–

Oracle 内存数据库 – TimesTen

闲扯,关于 Cache

在 Google 上用 define:cache 搜索关于 Cache 的定义，简体中文内容中的定义是这样的：

在本地放置、隐藏或存储常用信息以供快速检索。

英文内容挑一条，内容如下：

A memory area where frequently accessed data can be stored for rapid access.

说白了，其实也就是减小开销最大或比较大的那步不必要的交互。

TimesTen

Oracle 的内存数据库 TimesTen 从某种角度上来看，也是一种 Cache 机制，是磁盘数据库的 ‘Cache’，通过物理内存中的数据存储区的直接操作，减少了到磁盘间的 I/O 交互。TimesTen 中的这个 Ten 据说就是指速度能达到基于磁盘的 RDBMS 10倍，从去年开始在国内市场也有很多活动，逐渐吸引了很多技术人员的注意。实际上，这个产品也是有一定潜在市场的。

TimesTen 与基于磁盘的 RDBMS 架构的比较

如图：

这个示意图引用自 Oracle TimesTen In-Memory Database Introduction，下载该文档请到官方网站。
这个数据库的 License 报价并不贵，List 价格是 $12K/CPU，对于响应速度要求比较高，可靠性要求不是非常非常高(安装 TimesTen 的系统内存可靠性会比你的 SAN 存储系统可靠性高么?)的系统，TimesTen 作为大事务数据库的前端数据库会是一个不错的选择：

引用自：oracle-timesten-accelerate.pdf
–EOF–