TTA -- when you believe

解析INDEX_DESC

Kevin.yuan — Wed, 07 Jan 2009 08:30:06 +0000

oracle执行计划中有类INDEX_DESC提示，我们知道，一般的索引是根据索引列的字段值升序排列，扫描会根据where条件的值判断entry，然后对索引树进行leaf的扫描，在读取leaf的顺序上，INDEX_DESC是个反向的过程，它从树的最后一个leaf往前读取，对于要求从大批量数据中返回少量top large value这类SQL需求来讲，无疑是比较高效的方式
来看一下/*+ index */和 /*+ index_desc */在读取上的不同。

SQL>create table test tablespace test as select * from dba_objects where object_id is not null order by dbms_random.value;
Table created
SQL> create index idx_test_1 on test(object_id) tablespace test;
Index created
SQL> exec dbms_stats.gather_table_stats(ownname => user,tabname => ‘test’,estimate_percent => 100,cascade => true);
PL/SQL procedure successfully completed
SQL> select /*+ index_desc(test,idx_test_1) */ OBJECT_NAME,OBJECT_ID,dbms_rowid.rowid_relative_fno(rowid) FILE_ID,dbms_rowid.rowid_block_number(rowid) BLOCK_ID from test where object_id>0 and rownum<5;
OBJECT_NAME OBJECT_ID FILE_ID BLOCK_ID
----------------------------- ---------- ---------------------------------------
TEST 3030 8 121
TEST_CD 13028 8 65
WRH$_SERVICE_WAIT_CLASS_PK 13027 8 149
WRH$_SERVICE_WAIT_CLASS_PK 13026 8 51

SQL> select /*+ index(test,idx_test_1) */ OBJECT_NAME,OBJECT_ID,dbms_rowid.rowid_relative_fno(rowid) FILE_ID,dbms_rowid.rowid_block_number(rowid) BLOCK_ID from test where object_id>0 and rownum<5;
OBJECT_NAME OBJECT_ID FILE_ID BLOCK_ID
--------------------------- ---------- ------------------------------ ----------------------
C_OBJ# 2 8 112
I_OBJ# 3 8 49
TAB$ 4 8 31
CLU$ 5 8 147

可以看到2者获取的row是不同的.
对先前使用index_desc的语句进行10046跟踪，跟踪之前需要flash buffer_cache.这样可以避免干扰的从trace文件看到从磁盘读取到的block。

—
PARSING IN CURSOR #1 len=178 dep=0 uid=28 oct=3 lid=28 tim=1202439326146305 hv=4287804886 ad=’297b5944′
select /*+ index_desc(test,idx_test_1) */ OBJECT_NAME,OBJECT_ID,dbms_rowid.rowid_relative_fno(rowid),dbms_rowid.rowid_block_number(rowid) from test where object_id>0 and rownum<5
END OF STMT
PARSE #1:c=14998,e=14540,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,tim=1202439326146297
EXEC #1:c=0,e=207,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=1202439326146604
WAIT #1: nam='SQL*Net message to client' ela= 1 driver id=1650815232 #bytes=1 p3=0 obj#=6314 tim=1202439326146617
WAIT #1: nam='db file sequential read' ela= 26 file#=8 block#=3610 blocks=1 obj#=13032 tim=1202439326146842
WAIT #1: nam=’db file sequential read’ ela= 117 file#=8 block#=3633 blocks=1 obj#=13032 tim=1202439326147139
WAIT #1: nam=’db file sequential read’ ela= 12 file#=8 block#=121 blocks=1 obj#=13030 tim=1202439326147269
FETCH #1:c=2000,e=1110,p=3,cr=3,cu=0,mis=0,r=1,dep=0,og=1,tim=1202439326147729
WAIT #1: nam=’SQL*Net message from client’ ela= 208 driver id=1650815232 #bytes=1 p3=0 obj#=13030 tim=1202439326147991
WAIT #1: nam=’db file sequential read’ ela= 13 file#=8 block#=65 blocks=1 obj#=13030 tim=1202439326148117
WAIT #1: nam=’SQL*Net message to client’ ela= 2 driver id=1650815232 #bytes=1 p3=0 obj#=13030 tim=1202439326148171
WAIT #1: nam=’db file sequential read’ ela= 21 file#=8 block#=149 blocks=1 obj#=13030 tim=1202439326148263
WAIT #1: nam=’db file sequential read’ ela= 16 file#=8 block#=51 blocks=1 obj#=13030 tim=1202439326148353
FETCH #1:c=0,e=369,p=3,cr=4,cu=0,mis=0,r=3,dep=0,og=1,tim=1202439326148400
*** 2009-01-07 11:11:26.616
WAIT #1: nam=’SQL*Net message from client’ ela= 16250106 driver id=1650815232 #bytes=1 p3=0 obj#=13030 tim=1202439342398571
STAT #1 id=1 cnt=4 pid=0 pos=1 obj=0 op=’COUNT STOPKEY (cr=7 pr=6 pw=0 time=751 us)’
STAT #1 id=2 cnt=4 pid=1 pos=1 obj=13030 op=’TABLE ACCESS BY INDEX ROWID TEST (cr=7 pr=6 pw=0 time=727 us)’
STAT #1 id=3 cnt=4 pid=2 pos=1 obj=13032 op=’INDEX RANGE SCAN DESCENDING IDX_TEST_1 (cr=3 pr=2 pw=0 time=583 us)’
=====================
PARSING IN CURSOR #2 len=55 dep=0 uid=28 oct=42 lid=28 tim=1202439342398576 hv=2217940283 ad=’0′
alter session set events ‘10046 trace name context off’
END OF STMT
PARSE #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,tim=1202439342398576
EXEC #2:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,tim=1202439342398576
—-

读取顺序为file#=8 block#=3610–file#=8 block#=3633–file#=8 block#=121–file#=8 block#=65–file#=8 block#=149
比较明显可以看出121-65-149 跟我们先前查询出来的结果顺序是一致的。为了更加清楚的显示读取过程，我们对idx_test_1进行treedump

SQL> select object_id from dba_objects where object_name=’IDX_TEST_1′;
OBJECT_ID
———-
13032
SQL> ALTER SESSION SET EVENTS ‘immediate trace name TREEDUMP level 13032′;
Session altered.

—– begin tree dump
branch: 0×2000e1a 33558042 (0: nrow: 23, level: 1)
leaf: 0×2000e1b 33558043 (-1: nrow: 485 rrow: 485)
leaf: 0×2000e1c 33558044 (0: nrow: 479 rrow: 479)
leaf: 0×2000e1d 33558045 (1: nrow: 479 rrow: 479)
leaf: 0×2000e1e 33558046 (2: nrow: 478 rrow: 478)
leaf: 0×2000e1f 33558047 (3: nrow: 479 rrow: 479)
leaf: 0×2000e20 33558048 (4: nrow: 479 rrow: 479)
leaf: 0×2000e21 33558049 (5: nrow: 479 rrow: 479)
leaf: 0×2000e22 33558050 (6: nrow: 479 rrow: 479)
leaf: 0×2000e23 33558051 (7: nrow: 479 rrow: 479)
leaf: 0×2000e24 33558052 (8: nrow: 478 rrow: 478)
leaf: 0×2000e25 33558053 (9: nrow: 479 rrow: 479)
leaf: 0×2000e26 33558054 (10: nrow: 479 rrow: 479)
leaf: 0×2000e27 33558055 (11: nrow: 478 rrow: 478)
leaf: 0×2000e28 33558056 (12: nrow: 479 rrow: 479)
leaf: 0×2000e29 33558057 (13: nrow: 479 rrow: 479)
leaf: 0×2000e2a 33558058 (14: nrow: 479 rrow: 479)
leaf: 0×2000e2b 33558059 (15: nrow: 479 rrow: 479)
leaf: 0×2000e2c 33558060 (16: nrow: 478 rrow: 478)
leaf: 0×2000e2d 33558061 (17: nrow: 479 rrow: 479)
leaf: 0×2000e2e 33558062 (18: nrow: 460 rrow: 460)
leaf: 0×2000e2f 33558063 (19: nrow: 448 rrow: 448)
leaf: 0×2000e30 33558064 (20: nrow: 449 rrow: 449)
leaf: 0×2000e31 33558065 (21: nrow: 6 rrow: 6)
—-

第1次io file#=8 block#=3610 读取的block为索引的root节点所在的block — 对应treedump里面 branch: 0×2000e1a 33558042 (0: nrow: 23, level: 1)
第2次io file#=8 block#=3633 读取的block为索引树的最后一个leaf — 对应treedump里面 leaf: 0×2000e31 33558065 (21: nrow: 6 rrow: 6)
以下io便是对leaf: 0×2000e31 33558065所存的条目进行回表访问。
DUMP leaf: 0×2000e31 33558065,也就是file#=8 block#=3633。
转换关系如下：

SQL> select dbms_utility.data_block_address_file(33558065) file_id#,dbms_utility.data_block_address_block(33558065) block_id# from dual;

FILE_ID# BLOCK_ID#
———- ———-
8 3633
SQL> alter system dump datafile 8 block 3633;

Leaf block dump
===============
header address 216754268=0xceb685c
kdxcolev 0
KDXCOLEV Flags = - - -
kdxcolok 0
kdxcoopc 0×80: opcode=0: iot flags=— is converted=Y
kdxconco 2
kdxcosdc 0
kdxconro 6
kdxcofbo 48=0×30
kdxcofeo 7948=0×1f0c
kdxcoavs 7900
kdxlespl 0
kdxlende 0
kdxlenxt 0=0×0
kdxleprv 33558064=0×2000e30
kdxledsz 0
kdxlebksz 8032
row#0[8018] flag: ——, lock: 0, len=14
col 0; len 4; (4): c3 02 1f 18
col 1; len 6; (6): 02 00 01 09 00 01 —-对应datafile 8，block 265
row#1[8004] flag: ——, lock: 0, len=14
col 0; len 4; (4): c3 02 1f 1a
col 1; len 6; (6): 02 00 00 59 00 41 —-对应datafile 8，block 89
row#2[7990] flag: ——, lock: 0, len=14
col 0; len 4; (4): c3 02 1f 1b
col 1; len 6; (6): 02 00 00 33 00 4d —-对应datafile 8，block 51
row#3[7976] flag: ——, lock: 0, len=14
col 0; len 4; (4): c3 02 1f 1c
col 1; len 6; (6): 02 00 00 95 00 46 —-对应datafile 8，block 149
row#4[7962] flag: ——, lock: 0, len=14
col 0; len 4; (4): c3 02 1f 1d
col 1; len 6; (6): 02 00 00 41 00 23 —-对应datafile 8，block 65
row#5[7948] flag: ——, lock: 0, len=14
col 0; len 4; (4): c3 02 1f 1f
col 1; len 6; (6): 02 00 00 79 00 04 –对应datafile 8，block 121
—– end of leaf block dump —–

转换关系–
col 1; len 6; (6)转换成64位，
前10位=>file id
中22位=>block id
后16位=>row id

看一下执行计划成本情况

[oracle@test1 getsql]$ ./get_sql.sh 2 2570394218

SQL_TEXT
——————————————————————————–
select * from (select /*+ index(test,idx_test_1) */ * from test
where object_id>0 order by object_id desc) where rownum<10

ID P_ID execution_plan COST CARDINALITY BYTES
--- ---- -------------------------------------------------- -------- ----------- --------
0 SELECT STATEMENT 10606
1 0 COUNT STOPKEY
2 1 VIEW 10606 10466 1852482
3 2 SORT ORDER BY STOPKEY 10606 10466 889610
4 3 TABLE ACCESS BY INDEX ROWID TEST 10396 10466 889610
5 4 INDEX RANGE SCAN IDX_TEST_1 24 10466

[oracle@test1 getsql]$ ./get_sql.sh 2 3221081669

SQL_TEXT
--------------------------------------------------------------------------------
select * from (select /*+ index_desc(test,idx_test_1) */ * from
test where object_id>0 order by object_id desc) where rownum<10

ID P_ID execution_plan COST CARDINALITY BYTES
--- ---- -------------------------------------------------- -------- ----------- --------
0 SELECT STATEMENT 11
1 0 COUNT STOPKEY
2 1 VIEW 11 9 1593
3 2 TABLE ACCESS BY INDEX ROWID TEST 11 9 765
4 3 INDEX RANGE SCAN DESCENDING IDX_TEST_1 2 10466

在10gR2版本下，oracle会根据成本计算自动选择index_desc方式来作为最优的执行计划，9i下未做测试验证。

9i RAC静默升级至10g RAC

Kevin.yuan — Sun, 21 Dec 2008 10:06:02 +0000

周末帮朋友升级了一个9i rac的数据库，版本是9.2.0.4/操作系统 redflag，数据文件采用裸设备,需要升级到10g rac (10.2.0.4),由于数据量不算小而且属于同机升级，决定不采用逻辑导入导出的方式，安装好10.2.0.4的版本的crs和db后，直接升级数据字典.

由于当时环境限制比较多，不能采用图形化界面操作，于是整个过程在静默模式下完成，中间碰到了一点点问题，算是顺利完成。
以下是升级过程。
<一> 安装前准备工作
1.备份9i rac数据库软件以及数据库文件
2.10g rac环境准备
(1).创建用于10gR2 CRS 所需的OCR和vote disk(采用裸设备)

[root@node1 install]#lvcreate -L200M -nocr vgdata
[root@node1 install]#lvcreate -L200M -nvotingdisk vgdata

在两节点对新加入lv激活并做裸设备绑定/授权
(2).创建相应目录,配置环境(编辑/etc/hosts,profile,创建ssh互信节点等…)
<二>静默安装10.2.0.1版本软件并打10.2.0.4patch
1.静默安装crs先安装10.2.0.1

[oracle@node1 install]$./runInstaller -silent -force -ignoreSysprereqs -responseFile /home/oracle/crs.rsp

安装过程会出错，需要手工在两节点执行/opt/oracle/product/10.2.0/crs_1/root.sh.在第二节点执行root.sh的会抛出异常，

Running vipca(silent) for configuring nodeapps
The given interface(s), “eth0″ is not public. Public interfaces should be used to configure virtual IPs.

这是10.2.0.1下面的一个bug，必须用root用户以OUI方式来执行vipca，由于没有图形界面环境，所以这个错误暂时不理，关闭每个节点上的crs服务，直接打10.2.0.4补丁，打完补丁后，再静默调用vipca.

[root@node1 install]#/opt/oracle/product/10.2.0.4/crs_1/vipca -silent -nodelist node1 -nodevips node1/node1-vip/255.255.255.0/eth1
[root@node1 install]#/opt/oracle/product/10.2.0.4/crs_1/vipca -silent -nodelist node2 -nodevips node2/node2-vip/255.255.255.0/eth1

执行成功后，查看：

[oracle@node1 ~]$ crs_stat -t
Name Type Target State Host
————————————————————
ora.node1.gsd application ONLINE ONLINE node1
ora.node1.ons application ONLINE ONLINE node1
ora.node1.vip application ONLINE ONLINE node1
ora.node2.gsd application ONLINE ONLINE node2
ora.node2.ons application ONLINE ONLINE node2
ora.node2.vip application ONLINE ONLINE node2

接下来执行

[oracle@node1 ~]$/opt/oracle/product/10.2.0/crs_1/cfgtoollogs/configToolFailedCommands

用以配置ons和oifcfg
2.静默安装datbase software
同样，先安装10.2.0.1，然后patch到10.2.0.4

[oracle@node1 install]$./runInstaller –silent –force -ignoreSysprereqs –responseFile /home/oracle/db_software.rsp

<三>升级数据库

1.准备10g database启动环境

copy 9i目录下dbs文件目录到10g对应目录下，编辑参数文件，配置shared_pool java_pool的大小，修改cluster_database=false,并去掉相关废弃参数.

2.启动数据库并升级数据字典

(1)创建sysaux表空间

SQL>startup upgrade pfile=’/home/oracle/pfiletmp.ora’;
SQL>CREATE TABLESPACE sysaux DATAFILE ‘/oradata/test/sysaux01.dbf’ SIZE 500M EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO

(2) 升级数据字典

SQL>@?/rdbms/admin/catupgrd
–show upgrade result
SQL>@?/rdbms/admin/utlu102s.sql

升级完毕后，关闭数据库，修改参数文件并创建成spfile，正常启动后，编译失效的对象

SQL>@?/rdbms/admin/utlrp

<四>注册资源

1.注册监听
采用crs_register的方式注册编写的ora.node1.LISTENER_NODE1.lsnr.cap文件

[oracle@node1 admin]$ crs_register ora.node1.LISTENER_NODE1.lsnr -dir /home/oracle

[oracle@node1 admin]$ crs_register ora.node2.LISTENER_NODE2.lsnr -dir /home/oracle

2.注册database和instance

[oracle@node1 admin]$ srvctl add database -d gzfk
[oracle@node1 admin]$ srvctl add instance -d gzfk -i test1 -n node1
[oracle@node1 admin]$ srvctl add instance -d gzfk -i test2 -n node2
[oracle@node1 admin]$ crs_stat -t
Name Type Target State Host
————————————————————
ora….E1.lsnr application ONLINE ONLINE node1
ora….E2.lsnr application ONLINE ONLINE node2
ora.node1.gsd application ONLINE ONLINE node1
ora.node1.ons application ONLINE ONLINE node1
ora.node1.vip application ONLINE ONLINE node1
ora.node2.gsd application ONLINE ONLINE node2
ora.node2.ons application ONLINE ONLINE node2
ora.node2.vip application ONLINE ONLINE node2
ora.fzfk.db application ONLINE ONLINE node1
ora….k1.inst application ONLINE ONLINE node1
ora….k2.inst application ONLINE ONLINE node2

接下来做一系列收尾和配置工作.

下午部署DG，顺手写的几个dg维护脚本/

Kevin.yuan — Thu, 11 Dec 2008 11:43:36 +0000

下午给项目搭建了套DG，没啥好说的，顺手写了几个脚本，后面还需完善完善.
1.主备库开机自动启动(自动判断库运行模式，如果为Primary ，则启动到open状态，如果为Standby，则启动到recover managed standby database状态）

#!/bin/sh
#Author:Kevin.yuan
#Create_Time:2008-12-11
#Description:
#1.The script just put /etc/init.d/rc.local ==> su - oracle -c “/home/oracle/dbstart.sh
#2.The script is used to startup the datbase automatically when the OS is up.If the database is primary role,then “alter database open”, if the role is standby,then “recover managed standby database…”

#This function is used to get the database’s current role (Primary: 1 /Standby 2 Other(error) 3)
get_role()
{
sqlplus -s “/as sysdba” << !
startup mount;
spool /home/oracle/jurge_role.log
set head off
set feedback off
select database_role from v\$database;
spool off
exit;
!
role=`cat /home/oracle/jurge_role.log|tail -1`
if [ $role = "PRIMARY" ]
then
return 1
elif [ $role = "STANDBY" ]
then
return 2
else
return 3
fi
}
#-----main begin------
source /home/oracle/.bash_profile
lsnrctl start
get_role
role_stat=$?
if [ $role_stat -eq 1 ]
then
sqlplus -s "/as sysdba"<< !
alter database open;
exit
!
elif [ $role_stat -eq 2 ]
then
sqlplus -s "/as sysdba"<< !
alter database recover managed standby database disconnect from session;
exit
!
fi

2.定期自动删除主库/备库端已经在备库上apply过的归档日志，我不太喜欢用OS命令下的rm删除归档，容易出毛病，而且不灵便，还是喜欢调用Rman的delete archivelog命令.

#!/bin/sh
#Create_time:2008.12.11
#Author:Kevin.yuan
#Description:Delete the archived logs which had applied on Standby database using Rman.
source /home/oracle/.bash_profile
Dir=/opt/oracle/script/standby
cd $Dir
echo “rman target / log rman_delete_arch.log append << !">rman_delete_arch.sh
echo “crosscheck archivelog all;”>>rman_delete_arch.sh
sqlplus -s “sys/sys@paybilldg as sysdba”>>rman_delete_arch.sh << !
set head off
set feedback off
select 'delete noprompt archivelog until logseq '||max(sequence#)||';' from v\$log_history;
exit
!
echo "exit;">>rman_delete_arch.sh
echo “!”>>rman_delete_arch.sh
sed -i ‘/^$/d’ rman_delete_arch.sh
##delete the archived logs
sh rman_delete_arch.sh

不过还是写了一个利用os的rm命令来删除的脚本.

#!/bin/sh
#Create_time:2008.12.11
#Author:Kevin.yuan
#Description:Delete the archived logs which had applied on Standby database Using os command.
source /home/oracle/.bash_profile
##Here is the primay/standby archive dest
Arch_dest=/archive/test
Sc_dir=/opt/oracle/script/standby
cd $Sc_dir
sqlplus -s “sys/sys@paybilldg as sysdba”>standby.log << !
set head off
set feedback off
select '1_'||a.SEQUENCE#||'_'||a.RESETLOGS_ID||'.dbf' from v$archived_log a where a.APPLIED='YES' and first_time>sysdate-8;
exit
!
##
cat /dev/null>rm_arch.sh
for i in `ls -l $Arch_dest|grep ‘1_’|awk ‘{print $NF}’` ; do
for j in `cat standby.log` ; do
if [ $i = $j ]
then
if [ `grep $i rm_arch.sh|wc -l` -eq 0 ]
then
echo “rm -f $Arch_dest/”$i>>rm_arch.sh
fi
fi
done
done
sh rm_arch.sh

No Related Post

[HA]利于heartbeat构建Oracle高可用

Kevin.yuan — Fri, 24 Oct 2008 04:05:35 +0000

Linux下有很多集群软件,不同程度的在企业的高可用和负载均衡环境中发挥着作用. Heartbeat作为Linux-HA项目组开发出来的一套开源软件,也可以为应用/系统提供高可用服务.官方网站这样描述它:

Heartbeat currently supports a very sophisticated dependency model for n-node clusters. It is both extremely useful and quite stable at this point in time. The following types of applications are typical:
• Database servers
• ERP applications
• Web servers
• LVS director (load balancer) servers
• Mail servers
• Firewalls
• File servers
• DNS servers
• DHCP servers
• Proxy Caching servers
• Custom applications
• etc.

相应版本可以从http://www.linux-ha.org/下载.
下面就让我们来搭建一套基于heartbeat的oracle双机热备体系.

物理需求:

两台主机(双网卡或者使用心跳线连接2-node),共享磁盘.

环境描述:

本次搭建在CentOS 4.4下,使用网卡eth1作为node互联. heartbeat.版本为2.1.4. 数据库版本为10.2.0.1,数据库文件创建在/oradata上,各nodeIP分配如下:

HA1– eth0:192.168.18.201 eth1:10.10.10.201
HA2–eth0:192.168.18.202 eth1:10.10.10.202
Active IP: 192.168.18.200

1. 分别在2节点安装heartbeat软件,我下载的是rpm包并打齐必要的依赖包.

heartbeat-2.1.4-2.1.i386.rpm
heartbeat-devel-2.1.4-2.1.i386.rpm
heartbeat-ldirectord-2.1.4-2.1.i386.rpm
heartbeat-pils-2.1.4-2.1.i386.rpm
heartbeat-stonith-2.1.4-2.1.i386.rpm
ipvsadm-1.24-6.i386.rpm
libnet-1.1.2.1-2.1.i386.rpm
…….>>

2.在2节点本地安装database softwore,并在一个节点上创建配置database.数据库文件需要创建到共享磁盘上.
3.在2节点上配置heartbeat.(需要用到的主要有3个配置文件. ha.cf/ authkeys/ haresources,分别在/etc/ha.d/路径下)
(1) ha.cf. HA服务配置文件

logfile /var/log/ha-log # Log file address
keepalive 2 # Heartbeat interval
deadtime 20 # dead time
warntime 10 # warning time
udpport 694 # Heartbeat port
bcast eth1 # Linux Heartbeat interface
auto_failback off # the failure node automatic comes back automaticly
node ha1 # list node
node ha2 # list node
ping 192.168.18.1 #check the node health status;
respawn hacluster /usr/lib/heartbeat/ipfail

(2) authkeys. 双机互联验证文件,本次搭建采用的是crc模式.

auth 1
1 crc

注意权限:chmod 600 authkeys
(3) haresources. 配置资源文件,这个是heartbeat提供服务的关键.

ha1 192.168.18.200 oradb

ha1:主节点名称
192.168.18.200: 提供的active ip
oradb:高可用服务,在本次搭建中,需要用oradb来实现节点切换后的database启动/停止.
Heartbeat将从/etc/init.d 或者/etc/ha.d/resource.d 来搜索这个脚本.
我将它放到/etc/ha.d/resource.d下,以下是个简化功能的script:

#!/bin/sh
# kevinyuan 2008/10/24
#It’s used to startup/shutdown oracle database
export ORACLE_BASE=/opt/oracle
export ORACLE_HOME=$ORACLE_BASE/product/10.2.0/db_1
export ORACLE_SID=ha
export PATH=/home/oracle/bin:$ORACLE_HOME/bin:$PATH
MOUNTDEV=/dev/sdb1
MOUNTPOINT=/oradata
case $1 in
start)
mount $MOUNTDEV $MOUNTPOINT
su – oracle –c “dbstart”
;;
stop)
su – oracle –c “dbshut”
fuser -k -m -v $MOUNTPOINT
umount $MOUNTPOINT
;;
*)
echo “Usage: $0 {start|stop}”
;;
esac

其中dbstart 和dbshut是调用了$ORACLE_HOME/bin下面的dbstart 和dbshut,作用是启动/停止数据库和监听.

3.数据库监听和tnsnames.ora配置
两节点上的Listener.ora 中IP可以配置成Active ip,这样在各个tnsnames.ora里面就需要使用这个Active ip,在本例为192.168.18.200.
也可以两节点上Listener.ora 中IP仍然使用各自真实IP,这样tnsnames.ora需要配置connect-time failover策略,如下:

HA =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.18.201)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.18.202)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = ha)
)
)

4. 简单测试

SQL> conn sys/mecoyoo@ha
Connected.
SQL> !hostname
Ha1

在ha1上,停掉网卡,然后重新连接sqlplus,查询

SQL> conn sys/mecoyoo@ha
Connected.
SQL> !hostname
Ha2

此时连接已经从ha1转移到ha2上.
Ha2:

ha2-> ps -ef|grep ora_|wc -l
17

Ha1:

ha1-> ps -ef|grep ora_|wc –l
1

基本功能得以实现,后续将进一步测试,看是否满足要求.

SCN之 Block scn/commit scn/delayed block cleanout

Kevin.yuan — Thu, 23 Oct 2008 06:24:19 +0000

Block的cache header部分，记录着一个block scn,它是当前块最后一次变更的时间戳（确切说，这个更新并不是指itl上的scn的最新更新，在接下来delayed block cleanout下的slot重用情况下，可以看到block scn并不等于itl上的最后一次更新的scn）。可以通过dump获得block scn/last itl scn 和发布ora_rowscn语句获得last itl scn。

1. SQL> select distinct ora_rowscn,dbms_rowid.rowid_block_number(rowid) from test_ind where dbms_rowid.rowid_block_number(rowid)=31501;
ORA_ROWSCN DBMS_ROWID.ROWID_BLOCK_NUMBER(
———- ——————————
617405 31501

2. SQL> alter system dump datafile 4 block 31501;
Start dump data blocks tsn: 4 file#: 4 minblk 31501 maxblk 31501
buffer tsn: 4 rdba: 0×01007b0d (4/31501)
scn: 0×0000.00096bbd seq: 0×01 flg: 0×02 tail: 0×6bbd0601
frmt: 0×02 chkval: 0×0000 type: 0×06=trans data
――――――――――――――――――――――――――――――――――――――
Itl Xid Uba Flag Lck Scn/Fsc
0×01 0×000a.001.00000089 0×008033be.0046.14 C— 0 scn 0×0000.00065b9e
0×02 0×0008.02b.000000ac 0×00802fea.004a.28 –U- 1 fsc 0×0000.00096bbd

发布transaction后，未提交之前，block scn是不会改变的，对应的itl中也并不做scn记录。Block scn的改变，确切的说不是在发布commit之时（因为有delayed block cleanout的情况存在），而是在transaction对应的itl获得commit scn之时。
当发生fast commit cleanout，系统将transaction提交时刻的scn作为commit scn，更新block上 itl和undo segment header的Transaction table的slot上的 scn，并修改block scn，三者是一致的。发生delayed block cleanout的时候，之前的transaction commit更新的只是Transaction table，而并未做block上的处理，等待下次使用此blobk的时候，更新block scn和itl状态。block scn和itl的更新又分2种情况：
（1）当不产生slot重用的时候， delayed block cleanout时，根据Transaction table里面的信息，更新block scn和itl上的Scn/Fsc为transaction曾经提交时候的scn。
（2）当产生slot重用的时候，更新对应itl上scn为control scn，而block scn 为delayed block cleanout发生时刻的scn。

简单看一下这个测试过程。
（一）fast commit cleanout
1.建表/插入数据

SQL> create table test_scn(see char(500)) pctfree 90 tablespace test_a ;
Table created
SQL> insert into test_scn values(’see1′);
1 row inserted
SQL> insert into test_scn values(’see2′);
1 row inserted
SQL> commit;
Commit complete
SQL> select dbms_rowid.rowid_block_number(rowid),ora_rowscn from test_scn;
DBMS_ROWID.ROWID_BLOCK_NUMBER( ORA_ROWSCN
—————————— ———-
25617 622604
25618 622604

2.发布事务更新

SQL> update test_scn set see=’kao’ where see=’see1′;
SQL> select dbms_rowid.rowid_block_number(rowid),ora_rowscn from test_scn;

DBMS_ROWID.ROWID_BLOCK_NUMBER( ORA_ROWSCN
—————————— ———-
25617 622604
25618 622604 ――发现block scn并未改变
SQL>commit;

SQL> select dbms_rowid.rowid_block_number(rowid),ora_rowscn from test_scn;

DBMS_ROWID.ROWID_BLOCK_NUMBER( ORA_ROWSCN
—————————— ———-
25617 622604
25618 622683 ――已经更新

（二） delayed block cleanout：

1.创建一个小undo表空间.

SQL> create undo tablespace undo datafile ‘E:\ORACLE\PRODUCT\10.2.0\ORADATA\DEMO\undo.dbf’ size 2M;
Tablespace created
SQL> alter system set undo_tablespace=’undo’;
System altered

2 .发布更新后，清空buffer_cache，创造延时块清除条件，然后提交

SQL> select dbms_rowid.rowid_block_number(rowid),dbms_rowid.rowid_relative_fno(rowid), ora_rowscn,t.* from test_scn t;
DBMS_ROWID.ROWID_BLOCK_NUMBER( DBMS_ROWID.ROWID_RELATIVE_FNO( ORA_ROWSCN SEE
—————————— —————————— ———- ——————–
25617 6 625000 kao1
25618 6 693298 see2
SQL> update test_scn set see=’kao2′ where see=’see2′;
1 row updated
SQL> select XIDUSN，XIDSLOT，XIDSQN from v$transaction;
XIDUSN XIDSLOT XIDSQN
———- ————- —————- —————- —————-
20 33 21 ――得到XIDUSN，XIDSLOT的使用情况，后续发布重用脚本
SQL> alter system flush buffer_cache;
System altered
SQL> commit;
Commit complete
SQL> select timestamp_to_scn(systimestamp) from dual;
TIMESTAMP_TO_SCN(SYSTIMESTAMP)
——————————
693323 —–大概的commit scn

3．发布脚本，使XIDUSN 20 XIDLOT 33 重用。

SQL>exec proc_go_break_reuse(20，33，21);

代码如下：

create or replace procedure proc_go_break_reuse
(v_XIDUSN number,
v_XIDSLOT number,
v_XIDSQN number)
/* ————————————————–
Create_user :Mecoyoo
Time:2008-5-08
Description:It’s used to make transaction slot reused
—————————————————*/
AS
nsid number;
type transaction_record_type is record(
XIDUSN number,
XIDSLOT number,
XIDSQN number);
transaction_record transaction_record_type;
begin
select sys_context(’userenv’, ’sid’) into nsid from dual;
loop
insert into goon
select * from dba_objects where rownum<100;
select XIDUSN, XIDSLOT, XIDSQN
into transaction_record
from v$transaction a, v$session b
where a.ADDR = b.TADDR
and b.SID = nsid;
if (transaction_record.XIDUSN = v_XIDUSN and
transaction_record.XIDSLOT = v_XIDSLOT and
transaction_record.XIDSQN > v_XIDSQN) then
goto resue_end;
end if;
commit;
delete from goon;
select XIDUSN, XIDSLOT, XIDSQN
into transaction_record
from v$transaction a, v$session b
where a.ADDR = b.TADDR
and b.SID = nsid;
if (transaction_record.XIDUSN = v_XIDUSN and
transaction_record.XIDSLOT = v_XIDSLOT and
transaction_record.XIDSQN > v_XIDSQN) then
goto resue_end;
end if;
commit;
end loop;
<< resue_end >>
commit;
end;

4.产生延时块清除，记录相应scn号

SQL> select * from test_scn;
SEE
——————————————————————————–
kao1
kao2
SQL> select timestamp_to_scn(systimestamp) from dual;

TIMESTAMP_TO_SCN(SYSTIMESTAMP)
——————————
703860 ―――发生延时块清除时候的大概scn

SQL> select dbms_rowid.rowid_block_number(rowid), ora_rowscn from test_scn t where see=’kao2′;

DBMS_ROWID.ROWID_BLOCK_NUMBER( ORA_ROWSCN
—————————— ———-
25618 701061 —最后一次itl 上的 commit scn

5.dump undo header和block 25618

SQL> alter system dump undo header ‘_SYSSMU15$’;

System altered
TRN CTL:: seq: 0×0340 chd: 0×002b ctl: 0×0021 inc: 0×00000000 nfb: 0×0001
mgc: 0×8201 xts: 0×0068 flg: 0×0001 opt: 2147483646 (0×7ffffffe)
uba: 0×0200009b.0336.0a scn: 0×0000.000ab285 －这是control scn
―――――――――――――――――――――――――――――――――――――
index state cflags wrap# uel scn dba parent-xid nub stmt_num cmt
————————————————————————————————
0×00 9 0×00 0×0018 0×0001 0×0000.000ab2f0 0×0200009b 0×0000.000.00000000 0×00000001 0×00000000 1210262128
―――――――――――――――――――――――――――――――――――――――――――――
0×21 9 0×00 0×0018 0xffff 0×0000.000abd20 0×02000084 0×0000.000.00000000 0×00000052 0×00000000 1210262179 －－该slot已经被重用，重用的提交scn为000abd20
―――――――――――――――――――――――――――――――――――――――――――――
0×2f 9 0×00 0×0017 0×002e 0×0000.000ab387 0×0200009b 0×0000.000.00000000
0×000000

SQL> alter system dump datafile 6 block 25618;

Start dump data blocks tsn: 6 file#: 6 minblk 25618 maxblk 25618
buffer tsn: 6 rdba: 0×01806412 (6/25618)
scn: 0×0000.000abd72 seq: 0×01 flg: 0×00 tail: 0xbd720601 ―――这个scn 就是block scn，scn号为703858，可见应该是延时块清除的时候的scn
frmt: 0×02 chkval: 0×0000 type: 0×06=trans data

Hex dump of block: st=0, typ_found=1
Dump of memory from 0×074C8400 to 0×074CA400
……………………………………………………………………..
Block header dump: 0×01806412
Object id on Block? Y
seg/obj: 0×2966 csc: 0×00.abd72 itc: 2 flg: E typ: 1 - DATA
brn: 0 bdba: 0×180640e ver: 0×01 opc: 0
inc: 0 exflg: 0

Itl Xid Uba Flag Lck Scn/Fsc
0×01 0×0014.021.00000015 0×0200009f.02c5.0e C-U- 0 scn 0×0000.000ab285 －－这个scn就是control scn，在TRN CTL有记录，对应为701061
0×02 0×0010.016.00000014 0×02000074.0294.0d C— 0 scn 0×0000.000a9432

[Troubleshooting Assemble]本帖集合故障处理,不再另行开帖.

Kevin.yuan — Wed, 22 Oct 2008 10:27:16 +0000

把以后碰到的问题处理,都汇集到这个帖子里面吧,也不另行开帖了.想写的时候就写点,方便以后查阅.

Problem Time : 2008-10-22
Problem summary: 主库重建控制文件引起备库日志缺失以及后续备库应用归档日志过程中出现SMON: Parallel transaction recovery tried

问题的起源为一个物理primary/standby环境.由于备库前期进行硬件升级,停机了有段时间,恢复使用后,顺便观察了一下日志的receive和apply情况.
发现接收的日志文件从sequence 179到 sequence 315缺失.alert.log中出现这么可疑的一段:

Wed Oct 22 9:18:27 2008
FAL[client]: Failed to request gap sequence
GAP - thread 1 sequence 179-315
DBID 3397069132 branch 663290110
FAL[client]: All defined FAL servers have been attempted.
————————————————————-
Check that the CONTROL_FILE_RECORD_KEEP_TIME initialization
parameter is defined to a value that is sufficiently large
enough to maintain adequate log switch information to resolve
archivelog gaps.
————————————————————-

由于控制文件并非放在裸设备上,没有空间扩展限制,所以感觉问题的根源并非CONTROL_FILE_RECORD_KEEP_TIME的设置上,察看归档目录,发现的确存在sequence 179-315 对应的日志文件,查v$archived_log发现

SQL> select NAME,SEQUENCE# from v$archived_log where DEST_ID=1;
NAME SEQUENCE#
E:\ORACLE\ARCHIVE\demo\ARC00316_0663290110.001 316
E:\ORACLE\ARCHIVE\demo\ARC00317_0663290110.001 317
E:\ORACLE\ARCHIVE\demo\ARC00318_0663290110.001 318
E:\ORACLE\ARCHIVE\demo\ARC00319_0663290110.001 319
.
.
E:\ORACLE\ARCHIVE\demo\ARC00420_0663290110.001 420

归档记录竟然从logseq 316开始,应该是最近重建了控制文件,造成日志记录的丢失,而恰好这些归档因为备库当时未能工作而未及时传输到备库.继续在alert.log往上看,发现前几天的确重建过控制文件,而且数据库没有被resetlogs过.

问题原因至此找到.

对于应用丢失的这部分archivelog,解决办法也比较多.可以在备库端重新手动注册,也可以拷贝归档到备库的归档目录下,执行恢复操作.简单期间,我采用了主库端重新注册archivelog的方式,然后通过RFS进程传输到备库应用.

C:\rman target sys/password@demo
恢复管理器: Release 10.2.0.3.0 - Production on 星期三 10月 22 9:45:28 2008
Copyright (c) 1982, 2005, Oracle. All rights reserved.
连接到目标数据库: DEMO (DBID=3397069132)
RMAN> catalog start with ‘E:\Oracle\archive\demo’ noprompt;
使用目标数据库控制文件替代恢复目录
搜索与样式 E:\Oracle\archive\demo 匹配的所有文件

数据库未知文件的列表
=====================================
文件名: E:\ORACLE\ARCHIVE\demo\ARC00130_0663290110.001
.
.
文件名: E:\ORACLE\ARCHIVE\demo\ARC00179_0663290110.001
文件名: E:\ORACLE\ARCHIVE\demo\ARC00180_0663290110.001
文件名: E:\ORACLE\ARCHIVE\demo\ARC00181_0663290110.001
.
.
文件名: E:\ORACLE\ARCHIVE\demo\ARC00315_0663290110.001
.
.
正在编制文件目录…
目录编制完毕
已列入目录的文件的列表
=======================
=====================================
文件名: E:\ORACLE\ARCHIVE\demo\ARC00130_0663290110.001
.
.
文件名: E:\ORACLE\ARCHIVE\demo\ARC00179_0663290110.001
文件名: E:\ORACLE\ARCHIVE\demo\ARC00180_0663290110.001
文件名: E:\ORACLE\ARCHIVE\demo\ARC00181_0663290110.001
.
.
文件名: E:\ORACLE\ARCHIVE\demo\ARC00315_0663290110.001
.
.
RMAN>

SQL> select count(*) from v$archived_log where SEQUENCE# between 179 and 315 and DEST_ID=1;
COUNT(*)
———-
137

备库端:
发现这部分gap日志已经传送并开始恢复.
一段时间后,查看日志应用进度,进度比较慢,alert.log中又报出SMON: Parallel transaction recovery tried 错误,字面上看是并行恢复的时候出了问题,
于是将参数fast_start_parallel_rollback改为false,

SQL>alter system set fast_start_parallel_rollback=false;

重新执行日志应用.再无问题出现.

SQL> select max(SEQUENCE#) from v$archived_log where applied=’YES’;
MAX(SEQUENCE#)
————–
423

THE END.

天下没有免费的午餐…

Kevin.yuan — Fri, 12 Sep 2008 13:55:31 +0000

近期着实运气背了点，让我不得不重新审视自己的生活态度，也渐渐印证了自己的一贯信奉：运气是种因果。

有点唐突的离职，陡然发现路途并不平坦。舍弃与收获并非彰显分明，生活需要在拿捏之中历练。从现实意义上来讲，需要不断提醒自己，路要往前看。

早上一觉醒来，发觉blog失效，登陆主机后台管理，方知出了大问题，自己的管理帐号被删掉了。索性发邮件给主机商，石沉大海。这个号称推出免费网站服务的站点竟然改头换面，搞起了免费硬盘服务，真好笑。比这糟的是，没太在意这段时间blog使用的数据库自动备份出了问题，只能找到7月29号的一次备份。还好自己的blog更新频率比较慢，丢失不算太多。在对比考察了N多免费虚拟主机之后，决定还是让blog走付费路线（一个顶级域名+一个php/mysql虚拟主机，全年188元，这个价格让我怦然心动）。

至此，本站域名，从www.easyora.cn 更新为 www.easyora.net.

也许天下真的没有免费的午餐。建站初，出于稳定考虑，决定青睐于国外的主机运营商，实际发现，外国和尚也是和尚。也许，免费总是一个美好的幌子，之所以免费，使因为选择收费的模式代价太高。

No Related Post

小议Oracle 调度程序作业( dbms_scheduler )

Kevin.yuan — Mon, 01 Sep 2008 18:22:16 +0000

整理scheduler 这一部分,源于最近发现系统上自动采集统计信息的执行时间有些异常,执行时间被定义到了上午 (这并不是一个很合理可靠的时间 ).在重新修改配置的同时,也顺便整理了这一块内容.

首先简单讲一下oracle 10g scheduler,10g引入dbms_scheduler来替代先前的dbms_job,在功能方面,它比dbms_job提供了更强大的功能和更灵活的机制/管理.它主要由以下几大块构成:

1.作业(job) :

一个调度程序作业的实体.可以由dbms_scheduler.create_job创建生成.它可以自行指定作业属性,也可以调用我们预先创建的一系列scheduler/ program/ chain/ job_class/ window/ window_group来匹配其作业属性.

2.调度(scheduler) :
一个任务计划执行的时间策略.比如我们想要创建一个晚上3点执行的任务计划,就可以创建一个调度,凡是符合这个调度要求的,都可以调用这个我们预先创建好的调度.可以用dbms_scheduler.create_schedule来创建一个调度.

比如我创建一个名字叫MYTEST_SCHEDULE的调度,每天4:00执行.

Begin
dbms_scheduler.create_schedule(
repeat_interval => ‘FREQ=DAILY;BYHOUR=4;BYMINUTE=0;BYSECOND=0′,
start_date => systimestamp at time zone ‘PRC’,
comments => ‘—this is my test schedule—’,
schedule_name => ‘MYTEST_SCHEDULE’);
end;

3.程序(program):

10g下的program支持分为3种形式,PL/SQL BLOCK/STORED PROCEDURE/EXECUTABLE.可以使用DBMS_SCHEDULER.CREATE_PROGRAM来创建一个program.

BEGIN
DBMS_SCHEDULER.CREATE_PROGRAM(
program_name=>’mytest_program_1′,
program_action=>’update mytest set id=id+1;’,
program_type=>’PLSQL_BLOCK’,
number_of_arguments=>0,
comments=>”,
enabled=>TRUE);
END;

4.链(chain):
链可以看作是一个/几个program/event scheduler的集合,为了维护需要,我们可能需要将很多不同的program放到一起依次执行,按照以前的模式,要么将这几个program能整合成一个大的整体,要么分开几个job来单独执行,这无疑加重了维护负担,而chain的出现,可以优化这个问题,我们将实现定义好的program集合到一起,然后统一制定一个job来执行,可以使用dbms_scheduler.create_chain来创建一个chain.

比如,在我的系统中,我分别创建了一个EXECUTABLE类型的和一个STORED PROCEDURE类型的program,我需要他们顺次执行,于是我可以这么做:

BEGIN
dbms_scheduler.create_chain(
chain_name => ‘MYTEST_CHAIN’);
dbms_scheduler.define_chain_step(
chain_name => ‘MYTEST_CHAIN’,
step_name => ‘mytest_chain_1′,
program_name => ‘P_1′);
dbms_scheduler.alter_chain(
chain_name => ‘MYTEST_CHAIN’,
step_name => ‘mytest_chain_1′,
attribute => ’skip’,
value => FALSE);
dbms_scheduler.define_chain_step(
chain_name => ‘MYTEST_CHAIN’,
step_name => ‘mytest_chain_2′,
program_name => ‘P_2′);
dbms_scheduler.alter_chain(
chain_name => ‘MYTEST_CHAIN’,
step_name => ‘mytest_chain_2′,
attribute => ’skip’,
value => FALSE);
dbms_scheduler.enable(’MYTEST_CHAIN’);
END;

4.作业类(job_class):

定义了运行作业的资源使用者组.通过使用窗口中的资源计划, 我们可以在不同资源组和不同作业类之间分配资源.可以使用dbms_scheduler.create_job_class创建一个作业类.

BEGIN
dbms_scheduler.create_job_class(
logging_level => DBMS_SCHEDULER.LOGGING_RUNS,
log_history => 100,
resource_consumer_group => ‘AUTO_TASK_CONSUMER_GROUP’,
job_class_name => ‘MYTEST_JOB_CLASS’);
END;

5.窗口(window):

可以看成是一个更高功能的调度,窗口可以调用系统中存在的调度(也可以自行定义执行时间),而且,具有资源计划限制功能,窗口可以归属于某个窗口组.

可以使用DBMS_SCHEDULER.CREATE_WINDOW来创建一个窗口.

例如我创建了一个名为mytest_windows_1的窗口,采用DAILY_PURGE_SCHEDULE的调度方式,资源计划限制方案为SYSTEM_PLAN,持续时间为4小时.

BEGIN
DBMS_SCHEDULER.CREATE_WINDOW(
window_name=>’mytest_windows_1′,
resource_plan=>’SYSTEM_PLAN’,
schedule_name=>’SYS.DAILY_PURGE_SCHEDULE’,
duration=>numtodsinterval(240, ‘minute’),
window_priority=>’LOW’,
comments=>”);
END;

6.窗口组(window_group):

一个/几个窗口的集合.10g默认的自动采集统计信息的调度就是一个窗口组的形式,譬如,设置两个窗口,窗口一指定任务周日—–周五,晚上12点执行,而窗口二设定周六凌晨3点执行,这两个窗口组成了一个窗口组,形成了这个job的执行调度策略.

可以使用DBMS_SCHEDULER.CREATE_WINDOW_GROUP来创建一个窗口组.

BEGIN
DBMS_SCHEDULER.CREATE_WINDOW_GROUP(
group_name=>’mytest_window_group’,
window_list=>’MYTEST_WINDOWS_1,WEEKEND_WINDOW’);
END;

于是,使用dbms_scheduler创建一个job,我们可以调用各种预先定义的复杂属性,也可以简单的手动约定各个需要的属性.

简单的,如

BEGIN
dbms_scheduler.create_job(
job_name => ‘ MYTEST_JOB_1′,
job_type => ‘PLSQL_BLOCK’,
job_action => ‘update mytest set id=id+1;’,
repeat_interval => ‘FREQ=MINUTELY;INTERVAL=10′,
start_date => sysdate,
auto_drop => FALSE,
enabled => TRUE);
END;

跟采用dbms_job并不太大区别,只是repeat_interval等语法上有差别.

复杂点的,如:

BEGIN
dbms_scheduler.create_job(
job_name => ‘MYTEST_JOB_2′,
job_type => ‘CHAIN’,
job_action => ‘MYTEST_CHAIN’,
schedule_name => ‘SYS.MYTEST_WINDOW_GROUP’,
job_class => ‘DEFAULT_JOB_CLASS’,
auto_drop => FALSE,
enabled => FALSE);
dbms_scheduler.set_attribute( name => ‘MYTEST_JOB_2′, attribute => ’stop_on_window_close’, value => FALSE);
END;

调度程序作业属性的修改:

大部分的调度作业属性的修改,都可以通过dbms_scheduler.SET_ATTRIBUTE和dbms_scheduler.SET_ATTRIBUT_NULL来完成.在此仅几个举例来说明,更多使用方法雷同.

^比如,重新定义scheduler属性:

BEGIN
dbms_scheduler.set_attribute( name => ‘DAILY_PURGE_SCHEDULE’, attribute => ‘repeat_interval’, value => ‘FREQ=DAILY;BYHOUR=1;BYMINUTE=0;BYSECOND=0′);
END;

^比如重新修改program;

BEGIN
DBMS_SCHEDULER.SET_ATTRIBUTE(
name=>’P_1′,
attribute=>’PROGRAM_ACTION’,
value=>’/backup/2.sh’);
END;

^比如重新定义一个job属性

BEGIN
dbms_scheduler.set_attribute_null( name => ‘GATHER_STATS_JOB’, attribute => ’schedule_name’);
dbms_scheduler.set_attribute( name => ‘GATHER_STATS_JOB’, attribute => ‘repeat_interval’, value => ‘FREQ=DAILY;BYHOUR=2;BYSECOND=0′);
END;

等等…….