AnySQL.net

    在Oracle 10g CRS中没有直接添加Listener的命令, 但可以创建一些配置文件, 然后注册这些文件来向CRS中添加临听器. 首先在每台机器中配置临听器, 手工创建listener.ora文件, 包括所有节点的监听器, 这里面的node名称用大写.

SID_LIST_LISTENER_<node>=
LISTENER_<node>=

    接下来要创建配置文件, 有几个节点就要创建几个文件, 第一个node用小写的, 后面的用大写.

${ORA_CRS_HOME}/crs/public/ora.<node>.LISTENER_<node>.lsnr.cap

    每个文件中包写入如下几行, 假设节点的名字是db03.

NAME=ora.db03.LISTENER_DB03.lsnr
TYPE=application
ACTION_SCRIPT=${ORACLE_HOME}/bin/racgwrap
CHECK_INTERVAL=600
ACTIVE_PLACEMENT=1
DESCRIPTION=CRS application for listener on node
HOSTING_MEMBERS=db03
PLACEMENT=favored
REQUIRED_RESOURCES=ora.db03.vip

    然后用如下命令来注册这些监听器.

crs_register ora.<node>.LISTENER_<node>.lsnr.cap

    按照这种方法搞进去的Listener, 在VIP被接管后, 会在另一个节点自动启动, 这正是我想要的模式.

    Oracle 10G RAC中多了一个VIP资源, 也许应当叫服务, 如下所示, 其中db01, db02, db03都是RAC节点的名称.

[root@db02 oracle]# crs_stat | grep vip
NAME=ora.db01.vip
NAME=ora.db02.vip
NAME=ora.db03.vip

    正常安装后, 有两个资源或服务依赖于vip这个资源, 分别是listener和instance.

[root@db02 oracle]# crs_stat | grep db01
NAME=ora.db01.LISTENER_DB01.lsnr
NAME=ora.db01.gsd
NAME=ora.db01.ons
NAME=ora.db01.vip
NAME=ora.racdb.db01.inst

    这样也就是说如果vip出现服务, RAC会自动停止监听器和数据库实例. 停止监听器, 我们可以理解, 因为vip的问题造成数据库实例停止, 我认为是有些不合理的. 监听器还是依赖于vip服务, 但数据库实例不会依赖于vip服务, 可以说整个RAC系统中, 比较弱的环境就是这个vip服务了.

    不知道这样的设置合理不? 象在9i RAC中是没有vip服务的, 因此实例和vip不应当有依赖关系.

    由于VMWare GSX Server和Windows XP sp2的不兼容, 就安装了VMware Server版本, 却发现安装的Oracle RAC不能好好工作了, 最大的原因是, VIP服务不能自动启动了, 怎么找也找不出原因.

    用oifcfg命令看RAC的网卡设置, 没有发现问题.

[root@db01 /]# oifcfg getif -global
eth0  138.1.137.0  global  public
eth1  192.168.20.0  global  cluster_interconnect

    冲其量来说, VIP只是在网卡上绑定了另一个IP, 手工运行如下命令都没有问题.

[root@db01 /]# ifconfig eth0:1 138.1.137.11 netmask 255.255.255.0 up
[root@db01 /]# ifconfig eth0:2 138.1.137.21 netmask 255.255.255.0 up
[root@db01 /]# ifconfig eth0:3 138.1.137.31 netmask 255.255.255.0 up

    实在想不出理由, 就胡思乱想了. 联系起安装VMware Server时, 网络设置那块并不顺利, 而用了vmnet8作为eth0的接口, 可能是问题所在, 于是在注册表中一通搜索, 将原来的vmnet1和vmnet8删除干净后, 重新加入新的两块host only的网卡, 配好ip后启动虚拟机, 发现VIP工作正常了.

    因此不要用vmnet8 (NAT)来作为RAC节点的虚拟网卡接口.

    几分钟前一网友问我如何删除一个实体化视图, 当然不是什么语法不会的问题了, 是发了Drop命令后一直挂着, 几个小时都没有结束, 你可以想想为什么? 先看一下创建的语法.

create materialized view  user_order_mavi
     build immediate  
     refresh   on commit  
     enable query rewrite
as
select  service_id,substr(user_isdn,1,7),
         bill_type,follow_action,count(user_isdn)  
from user_order
group by service_id,substr(user_isdn,1,7),
          bill_type,follow_action

    看到这个语句, 应当是刷新的类型那儿有问题, 在ON COMMIT刷新模式下, 如果基表的DML很频繁, 会造成刷新很频繁, 这可能是DROP语句一直挂起的原因. 建议先运行以下命令:

ALTER MATERIALIZED VIEW user_order_mavi
   DISABLE QUERY REWRITE
   REFRESH ON DEMAND;

    由于新很频繁, 上面的ALTER语句也等了有半分多钟, 但最后成功执行了. 接下来再进行删除就没有任何问题了, 也很快!

    如何用好物化视图, 也是一门不小的学问!

    在一个分区表上去执行一个SQL时(在Where条件中用了分区列等于的条件, 分区列为主键索引的最后一列), 发现用错了执行计划, Oracle居然认为某个SQL的执行计划的成本为0, 实际上是肯定没有本为0的执行计划的, 因此是明显的不合理的现象.

SQLPLAN                                          COST CARD KBYTE PS PE
------------------------------------------------ ---- ---- ----- -- --
  0     SELECT STATEMENT Optimizer=RULE             0    1     0
  1   0   SORT (GROUP BY)                                1     0
  2   1     PARTITION RANGE (SINGLE)                0    1     0 3  3
  3   2       TABLE ACCESS (BY LOCAL INDEX ROWID    0    1     0 3  3
  4   3         INDEX (SKIP SCAN) OF TEST_TAB_PK    0    1       3  3

    产生的原因是因为分区的统计信息是过时的, 执行分析时这个分区还没有任何记录, 就产生了这个问题.

ASQL> SELECT PARTITION_NAME, BLEVEL,LEAF_BLOCKS,
    2        DISTINCT_KEYS,NUM_ROWS
    3 FROM DBA_IND_PARTITIONS
    4 WHERE INDEX_NAME='TEST_TAB_PK';

PARTITION_NAME   BLEVEL LEAF_BLOCKS DISTINCT_KEYS NUM_ROWS
---------------- ------ ----------- ------------- --------
TEST_TAB_PK_P06       0           0             0        0
TEST_TAB_PK_P07       3      364320      73835520 73835520
TEST_TAB_PK_P08       0           0             0        0
TEST_TAB_PK_P09       0           0             0        0
TEST_TAB_PK_P10       0           0             0        0
TEST_TAB_PK_PMAX      0           0             0        0

    但很显然Oracle这样算是不合理的, 谁能天天去分析表呢, 又有谁敢呢? 最好是当统计值为0时, 当作默认值来处理, 在另一个没有分析过的数据库上就是好的. 现在最好的做法, 就是分析后, 将空的分区上的统计信息删除, 当然可以用程序来做到这一点.

    在7x24小时的OLTP系统中, 分区是要用的, 出了问题是严重的, 你有什么高见?