CRS-5008: Invalid attribute value

在用oifcfg修改一个11.2.0.2  RAC的public interface的时候遇到了该错误,该错误常见的原因是:

1. BUG 12559708 BUG 11077013 BUG 12888041 BUG 12870719 bug 12876147 bug 13425057 bug 13738734 bug 13846043
2. 用oifcfg 修改public 后未为使用 svrctl modify nodeapps -n <nodename> -A 90.224.207.150/255.255.255.224/nxge0\|nxge2 修改network服务资源属性
3. 子网掩码搞错,如果mask是 255.255.255.128,则网段结尾要求也是128

常见的诊断步骤是观察:

1.crsctl status resource  ora.net1.network -p
2.  $GRID_HOME/log/<hostname>/agent/crsd/orarootagent_root/orarootagent_root.log
3.考虑reboot node可能可以解决,最主要的仍是保证网段和掩码正确

 

常见错误信息为 orarootagent_root.log中出现:

2011-08-15 18:43:44.105: [ora.net1.network][21] {1:1729:2} [check] subnetmask=0.0.0.0
2011-08-15 18:43:44.105: [ora.net1.network][21] {1:1729:2} [check] subnetnumber=0.0.0.0
2011-08-15 18:43:44.105: [ AGENT][21] {1:1729:2} UserErrorException: Locale is
2011-08-15 18:43:44.106: [ora.net1.network][21] {1:1729:2} [check] CRS-5008: Invalid attribute value: lan900 for the network interface

 

11gR2新特性:LMHB Lock Manager Heart Beat后台进程

LMHB是11gR2中新引入的后台进程,官方文档的介绍是Global Cache/Enqueue Service Heartbeat Monitor,Monitor the heartbeat of LMON, LMD, and LMSn processes,LMHB monitors LMON, LMD, and LMSn processes to ensure they are running normally without blocking or spinning。  Database and ASM instances, Oracle RAC

该进程负责监控LMON、LMD、LMSn等RAC关键的后台进程,保证这些background process不被阻塞或spin。 LMHB可能是Lock Manager Heartbeat的缩写。

 

我们来看一下该进程的trace跟踪文件以便了解其功能:

按照 100s -> 80s -> 100s -> 80s的间隔监控并输出一次LMSn、LCKn、LMON、LMD等进程的状态及wait chain,由kjfmGCR_HBCheckAll函数控制

 

*** 2012-02-03 00:03:10.066
==============================
LMS0 (ospid: 17247) has not moved for 77 sec (1328245389.1328245312)
kjfmGCR_HBCheckAll: LMS0 (ospid: 17247) has status 2
  : waiting for event 'gcs remote message' for 0 secs with wait_id 15327.
  ===[ Wait Chain ]===
  Wait chain is empty.
kjgcr_Main: KJGCR_ACTION - id 5

*** 2012-02-03 00:04:50.091
==============================
LMS0 (ospid: 17247) has not moved for 88 sec (1328245489.1328245401)
kjfmGCR_HBCheckAll: LMS0 (ospid: 17247) has status 2
  : waiting for event 'gcs remote message' for 0 secs with wait_id 24546.
  ===[ Wait Chain ]===
  Wait chain is empty.
kjgcr_Main: KJGCR_ACTION - id 5

 LCK0 (ospid: 2662) has not moved for 95 sec (1309746735.1309746640)
  kjfmGCR_HBCheckAll: LCK0 (ospid: 2662) has status 6
  ==================================================
  === LCK0 (ospid: 2662) Heartbeat Report
  ==================================================
  LCK0 (ospid: 2662) has no heartbeats for 95 sec. (threshold 70 sec)
   : Not in wait; last wait ended 80 secs ago.
   : last wait_id 2317342 at 'libcache interrupt action by LCK'.
  ..
  .
   Session Wait History:
       elapsed time of 1 min 20 sec since last wait
    0: waited for 'libcache interrupt action by LCK'
  ..

 

大约每3分钟输出一次TOP CPU User,CPU使用率高的session信息:

 

*** 2012-02-03 00:05:30.102
kjgcr_SlaveReqBegin: message queued to slave
kjgcr_Main: KJGCR_ACTION - id 3
CPU is high.  Top oracle users listed below:
     Session           Serial         CPU
      29                 7             0
     156                23             0
       3                 1             0
       4                 1             0
       5                 1             0

*** 2012-02-03 00:08:30.147
kjgcr_SlaveReqBegin: message queued to slave
kjgcr_Main: KJGCR_ACTION - id 3
CPU is high.  Top oracle users listed below:
     Session           Serial         CPU
      29                 7             0
     156                23             0
       3                 1             0
       4                 1             0
       5                 1             0

 

如果发现有session的CPU使用率极高,根据内部算法可能会激活 资源计划(resource management plan) ,甚至于kill 进程:

 

*** 2012-02-03 00:08:35.149
kjgcr_Main: Reset called for action high cpu, identify users, count 0

*** 2012-02-03 00:08:35.149
kjgcr_Main: Reset called for action high cpu, kill users, count 0

*** 2012-02-03 00:08:35.149
kjgcr_Main: Reset called for action high cpu, activate RM plan, count 0

*** 2012-02-03 00:08:35.149
kjgcr_Main: Reset called for action high cpu, set BG into RT, count 0

 

从11.2.0.2 开始LMHB开始使用slave 进程GCRn来完成实际的任务(Global Conflict Resolution Slave Process Performs synchronous tasks on behalf of LMHB GCRn processes are transient slaves that are started and stopped as required by LMHB to perform synchronous or resource intensive tasks.) LMHB会控制GCRn进程的启停,以便使用多个GCRn完成同步和缓解资源紧张的任务(例如kill进程)。

可以看到实际LMHB调用的多为kjgcr或kjfmGCR开头的内部函数,GCR意为Global Conflict Resolution。

 

kjgcr_Main: KJGCR_ACTION – id 5

GCR 进程的trace :

*** 2011-11-28 02:42:44.466
kjgcr_SlaveActionCbk: Callback failed, check trace
Dumping GCR slave work message at 0x96b81fc0
GCR layer information: type = 1, index = 0
Unformatted dump of ksv layer header:

 

LMHB进程的出现是为了提高RAC的可用性,特别是在资源紧张的环境中他会主动地去尝试kill掉最耗费资源的服务进程,以保证LMS等关键的RAC后台进程能正常工作; 因为该进程定期监控LMS、LMON等后台进程的等待事件及session的CPU使用率等信息,所以该LMHB进程的跟踪日志也可能成为诊断RAC故障的之一,这是11.2.0.1以来RAC一个潜在的新特性和增强。

相关隐式参数

_lm_hb_callstack_collect_time hb diagnostic call stack collection time in seconds — 5s
_lm_hb_disable_check_list list of process names to be disabled in heartbeat check — none

 

11.2是第一个引入LMHB进程的版本,所以并不是太成熟,在实际过程中对于资源使用率很高的RAC系统而言LMHB可能会帮一些倒忙,若你确实遇到了相关的问题或者是在11.2 RAC上碰到了一些诡异的现象,那么可以关注一下以下这些MOS Note:

 

ORA-29770 LMHB Terminates Instance as LMON Waited for Control File IO or LIBRARY CACHE or ROW CACHE Event for too Long [ID 1197674.1]
Bug 8888434 – LMHB crashes the instance with LMON waiting on controlfile read [ID 8888434.8]
Bug 11890804 – LMHB crashes instance with ORA-29770 after long “control file sequential read” waits [ID 11890804.8]
Bug 11890804: LMHB TERMINATE INSTANCE WHEN LMON WAIT CHANGE FROM CF READ AFTER 60 SEC
Bug 13467673: CSS MISSCOUNT AND ALL ASM DOWN WITH ORA-29770 BY LMHB
Bug 13390052: KJFMGCR_HBCHECKALL MESSAGES ARE CONTINUOUSLY LOGGED IN LMHB TRACE FILE.
Bug 13322797: LMHB TERMINATES THE INSTANCE DUE TO ERROR 29770
Bug 11827088 – Latch ‘gc element’ contention, LMHB terminates the instance [ID 11827088.8]

Bug 13061883: LMHB IS TERMINATING THE INSTANCE DURING SHUTDOWN IMMEDIATE
Bug 12564133 – ORA-600[1433] in LMHB process during RAC reconfiguration [ID 12564133.8]
Bug 12886605: ESSC: LMHB TERMINATE INSTANCE DUE TO 29770 – LMON WAIT ENQ: AM – DISK OFFLINE
Bug 12757321: LMHB TERMINATING THE INSTANCE DUE TO ERROR 29770
Bug 10296263: LMHB (OSPID: 15872): TERMINATING THE INSTANCE DUE TO ERROR 29770
Bug 11899415: ORA-29771 AND LMHB (OSPID: XXXX) KILLS USER (OSPID: XXX
Bug 10431752: SINGLE NODE RAC: LMHB TERMINATES INSTANCE DUE TO 29770
Bug 11656856: LMHB (OSPID: 27701): TERMINATING THE INSTANCE DUE TO ERROR 29770
Bug 10411143: INSTANCE CRASHES WITH IPC SEND TIMEOUT AND LMHB TERMINATES WITH ORA-29770
Bug 11704041: DATABASE INSTANCE CRASH BY LMHB PROCESS
Bug 10412545: ORA-29770 LMHB TERMINATE INSTANCE DUE TO VARIOUS LONG CSS WAIT
Bug 10147827: INSTANCE TERMINATED BY LMHB WITH ERROR ORA-29770
Bug 10016974: ORA-29770 LMD IS HUNG FOR MORE THAN 70 SECONDS AND LMHB TERMINATE INSTANCE
Bug 9376100: LMHB TERMINATING INSTANCE DUE ERROR 29770

 

 

给11gR2 RAC添加LISTENER监听器并静态注册

之前有同学想要给11gR2的RAC添加LISTENER监听器,查看了listener.ora并发现问题:

 

[oracle@vrh2 ~]$ lsnrctl status
LSNRCTL for Linux: Version 11.2.0.3.0 - Production on 04-DEC-2011 02:51:40

Copyright (c) 1991, 2011, Oracle. All rights reserved.

Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521))
STATUS of the LISTENER
------------------------
Alias LISTENER
Version TNSLSNR for Linux: Version 11.2.0.3.0 - Production
Start Date 02-DEC-2011 05:40:09
Uptime 1 days 21 hr. 11 min. 31 sec
Trace Level off
Security ON: Local OS Authentication
SNMP OFF
Listener Parameter File /g01/11.2.0/grid/network/admin/listener.ora
Listener Log File /g01/orabase/diag/tnslsnr/vrh2/listener/alert/log.xml
Listening Endpoints Summary...
(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=LISTENER)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=192.168.1.163)(PORT=1521)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=192.168.1.164)(PORT=1521)))
Services Summary...
Service "+ASM" has 1 instance(s).
Instance "+ASM2", status READY, has 1 handler(s) for this service...
Service "VPROD" has 1 instance(s).
Instance "VPROD2", status READY, has 1 handler(s) for this service...
Service "VPRODXDB" has 1 instance(s).
Instance "VPROD2", status READY, has 1 handler(s) for this service...
The command completed successfully

[oracle@vrh2 ~]$ cat /g01/11.2.0/grid/network/admin/listener.ora

LISTENER_SCAN1=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER_SCAN1)))) # line added by Agent
LISTENER=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER)))) # line added by Agent
ENABLE_GLOBAL_DYNAMIC_ENDPOINT_LISTENER=ON # line added by Agent
ENABLE_GLOBAL_DYNAMIC_ENDPOINT_LISTENER_SCAN1=ON # line added by Agent
ENABLE_GLOBAL_DYNAMIC_ENDPOINT_LSN_MACLEAN=ON # line added by Agent

 

以上listener.ora配置文件中的信息是Grid Infrastructure安装过程中Agent自行添加的(During the Grid Infrastructure installation, the (default) node VIP listener is always created referencing the public network),比较难以理解的可能是LISTENER仅指定了PROTOCOL=IPC的信息, 而没有指定监听的地址、端口等信息。

 

实际上11.2 GI的LISTENER 监听器配置默认受到11.2新引入的endpoints_listener.ora配置文件的管理:

 

Listener.ora

[grid@netrac1 admin]$ more listener.ora
LISTENER_SCAN2=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER_SCAN2)))) # line added by Agent
LISTENER=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER))))# line added by Agent
LISTENER_SCAN1=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER_SCAN1)))) # line added by Agent

ENABLE_GLOBAL_DYNAMIC_ENDPOINT_LISTENER_SCAN1=ON # line added by Agent
ENABLE_GLOBAL_DYNAMIC_ENDPOINT_LISTENER=ON # line added by Agent
ENABLE_GLOBAL_DYNAMIC_ENDPOINT_LISTENER_SCAN2=ON # line added by Agent

The ENABLE_GLOBAL_DYNAMIC_ENDPOINT_ parameter is set to allow the listener to accept connections
for pre-11.2 databases which did not register the dynamic endpoint.

Listener status "listener" showing 1 instance registered, ie instance running on the node

[grid@netrac1 admin]$ lsnrctl status listener
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER)))
STATUS of the LISTENER
------------------------
Alias LISTENER
Version TNSLSNR for Linux: Version 11.2.0.1.0 - Production
Start Date 15-FEB-2011 10:57:09
Uptime 0 days 0 hr. 0 min. 46 sec
Trace Level off
Security ON: Local OS Authentication
SNMP OFF
Listener Parameter File /u01/app/11.2.0/grid/network/admin/listener.ora
Listener Log File /u01/app/grid/diag/tnslsnr/netrac1/listener/alert/log.xml
Listening Endpoints Summary...
(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=LISTENER)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=12.345.678.111)(PORT=1521))) ** Node IP Address **
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=12.345.678.888)(PORT=1521))) ** Node VIP Address **
Services Summary...
Service "v11gr2" has 1 instance(s).
Instance "v11gr21", status READY, has 2 handler(s) for this service...
The command completed successfully

New file for 11.2 called endpoints_listener.ora, showing the Node IP address and Node VIP address.

[grid@netrac1 admin]$ more endpoints_listener.ora
LISTENER_NETRAC1=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=netrac1-vip)(PORT=1521))
(ADDRESS=(PROTOCOL=TCP)(HOST=12.345.678.888)(PORT=1521)(IP=FIRST)))) # line added by Agent

Endpoints_listener.ora file is there for backward compatibility with pre-11.2 databases.
DBCA needs to know the endpoints location to configure database parameters and tnsnames.ora file.
It used to use the listener.ora file, 11.2 RAC listener.ora by default only has IPC entries.

"Line added by Agent" is the Oraagent is the process updating the listener.ora and endpoints_listener.ora files.
Endpoints_listener.ora showing the Node IP address and Node VIP address

[grid@netrac2 admin]$ more endpoints_listener.ora
LISTENER_NETRAC2=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=netrac2-vip)(PORT=1521))
(ADDRESS=(PROTOCOL=TCP)(HOST=12.345.678.999) (PORT=1521)(IP=FIRST)))) # line added by Agent

 

我一开始以为LISTENER默认监听的地址和端口被写到了OCR中,后来用ocrdump转储注册信息发现没有相关记录。 后来才发现原来11.2 GI中监听器的地址和端口信息被移到了 endpoints_listener.ora中, “Line added by Agent”说明是由Oraagent 进程更新的记录。

 

注意:使用 endpoints_listener.ora的情况 下不应使用lsnrctl管理LISTENER,而需使用srvctl或crsctl工具管理,否则lsnrctl将不会识别endpoints_listener.ora中的信息,造成监听没有在必要地址、端口上工作。如:

 

[grid@vrh1 admin]$ lsnrctl status LSN_MACLEAN

LSNRCTL for Linux: Version 11.2.0.3.0 - Production on 27-NOV-2011 10:45:26

Copyright (c) 1991, 2011, Oracle.  All rights reserved.

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=LSN_MACLEAN)))
STATUS of the LISTENER
------------------------
Alias                     LSN_MACLEAN
Version                   TNSLSNR for Linux: Version 11.2.0.3.0 - Production
Start Date                26-NOV-2011 08:33:14
Uptime                    1 days 2 hr. 12 min. 11 sec
Trace Level               off
Security                  ON: Local OS Authentication
SNMP                      OFF
Listener Parameter File   /g01/11.2.0/grid/network/admin/listener.ora
Listener Log File         /g01/orabase/diag/tnslsnr/vrh1/lsn_maclean/alert/log.xml
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=LSN_MACLEAN)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=192.168.1.161)(PORT=1588)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=192.168.1.162)(PORT=1588)))
Services Summary...
Service "VPROD" has 1 instance(s).
  Instance "VPROD1", status READY, has 1 handler(s) for this service...
Service "VPRODXDB" has 1 instance(s).
  Instance "VPROD1", status READY, has 1 handler(s) for this service...
The command completed successfully

[grid@vrh1 admin]$ lsnrctl reload LSN_MACLEAN

LSNRCTL for Linux: Version 11.2.0.3.0 - Production on 27-NOV-2011 10:45:39

Copyright (c) 1991, 2011, Oracle.  All rights reserved.

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=LSN_MACLEAN)))
The command completed successfully

[grid@vrh1 admin]$ lsnrctl status LSN_MACLEAN

LSNRCTL for Linux: Version 11.2.0.3.0 - Production on 27-NOV-2011 10:45:44

Copyright (c) 1991, 2011, Oracle.  All rights reserved.

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=LSN_MACLEAN)))
STATUS of the LISTENER
------------------------
Alias                     LSN_MACLEAN
Version                   TNSLSNR for Linux: Version 11.2.0.3.0 - Production
Start Date                26-NOV-2011 08:33:14
Uptime                    1 days 2 hr. 12 min. 30 sec
Trace Level               off
Security                  ON: Local OS Authentication
SNMP                      OFF
Listener Parameter File   /g01/11.2.0/grid/network/admin/listener.ora
Listener Log File         /g01/orabase/diag/tnslsnr/vrh1/lsn_maclean/alert/log.xml
Listening Endpoints Summary...
 (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=LSN_MACLEAN)))
The listener supports no services
The command completed successfully

[grid@vrh1 admin]$ srvctl stop listener -l LSN_MACLEAN

[grid@vrh1 admin]$ srvctl start listener -l LSN_MACLEAN  

[grid@vrh1 admin]$ lsnrctl status LSN_MACLEAN

LSNRCTL for Linux: Version 11.2.0.3.0 - Production on 27-NOV-2011 10:46:26

Copyright (c) 1991, 2011, Oracle.  All rights reserved.

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=LSN_MACLEAN)))
STATUS of the LISTENER
------------------------
Alias                     LSN_MACLEAN
Version                   TNSLSNR for Linux: Version 11.2.0.3.0 - Production
Start Date                27-NOV-2011 10:46:22
Uptime                    0 days 0 hr. 0 min. 4 sec
Trace Level               off
Security                  ON: Local OS Authentication
SNMP                      OFF
Listener Parameter File   /g01/11.2.0/grid/network/admin/listener.ora
Listener Log File         /g01/orabase/diag/tnslsnr/vrh1/lsn_maclean/alert/log.xml
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=LSN_MACLEAN)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=192.168.1.161)(PORT=1588)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=192.168.1.162)(PORT=1588)))
The listener supports no services
The command completed successfully

 

而在11.2 RAC中listener.ora仅记录LISTENER的IPC条目。这样做的目的是方便dbca配置数据库参数及tnsnames.ora配置文件。

了解到以上信息后可能你对当前11.2 RAC中的listener.ora文件中的监听配置信息不再感到奇怪。

 

 

我们可以使用netca图形化工具或者srvctl 命令行工具添加监听配置; 如果仅仅是手动在listener.ora中添加记录的话是无法被注册为Cluster Ready Service的服务的,将不会被CRS管理。

 

方法1:

使用netca和netmgr图形化工具,完成添加监听和静态注册的工作。

1) 以Grid Infrastructure GI用户登录任意节点,并运行netca启动图形界面:

su - grid
(grid)$ export DISPLAY=:0
(grid)$ netca

选择LISTENER Configuration

 

 

选择ADD

填入监听名字

 

 

选择subnet和availabe protocol ,一般默认即可,除非你有多个public network网段

 

填入端口号

选择NO

 

 

选择要启动的监听名,即方才你创建的监听名

之后选择FINISH退出netca 界面,启动netmgr界面,为监听加入静态注册的信息:

su - grid
(grid)$ export DISPLAY=:0
(grid)$ netmgr

 

点选方才创建的监听器,选择Database Services菜单

 

 

填入Global Database Name和本地实例的SID信息,并确认ORACLE HOME Directory(应是Grid Infrastructure的Home目录)正确后点选Save Network Configuration。

 

之后使用srvctl 或 crsctl 重启该监听即可生效:

 

[grid@vrh1 admin]$ crsctl status  res ora.MACLEAN_LISTENER.lsnr
NAME=ora.MACLEAN_LISTENER.lsnr
TYPE=ora.listener.type
TARGET=ONLINE        , ONLINE
STATE=ONLINE on vrh1, ONLINE on vrh2

[grid@vrh1 admin]$ crsctl stop  res ora.MACLEAN_LISTENER.lsnr
CRS-2673: Attempting to stop 'ora.MACLEAN_LISTENER.lsnr' on 'vrh1'
CRS-2673: Attempting to stop 'ora.MACLEAN_LISTENER.lsnr' on 'vrh2'
CRS-2677: Stop of 'ora.MACLEAN_LISTENER.lsnr' on 'vrh1' succeeded
CRS-2677: Stop of 'ora.MACLEAN_LISTENER.lsnr' on 'vrh2' succeeded

[grid@vrh1 admin]$ crsctl start  res ora.MACLEAN_LISTENER.lsnr
CRS-2672: Attempting to start 'ora.MACLEAN_LISTENER.lsnr' on 'vrh2'
CRS-2672: Attempting to start 'ora.MACLEAN_LISTENER.lsnr' on 'vrh1'
CRS-2676: Start of 'ora.MACLEAN_LISTENER.lsnr' on 'vrh1' succeeded
CRS-2676: Start of 'ora.MACLEAN_LISTENER.lsnr' on 'vrh2' succeeded

[grid@vrh1 admin]$ lsnrctl status MACLEAN_LISTENER

LSNRCTL for Linux: Version 11.2.0.3.0 - Production on 27-NOV-2011 11:00:42

Copyright (c) 1991, 2011, Oracle.  All rights reserved.

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=MACLEAN_LISTENER)))
STATUS of the LISTENER
------------------------
Alias                     MACLEAN_LISTENER
Version                   TNSLSNR for Linux: Version 11.2.0.3.0 - Production
Start Date                27-NOV-2011 11:00:11
Uptime                    0 days 0 hr. 0 min. 31 sec
Trace Level               off
Security                  ON: Local OS Authentication
SNMP                      OFF
Listener Parameter File   /g01/11.2.0/grid/network/admin/listener.ora
Listener Log File         /g01/orabase/diag/tnslsnr/vrh1/maclean_listener/alert/log.xml
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=MACLEAN_LISTENER)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=192.168.1.161)(PORT=1598)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=192.168.1.162)(PORT=1598)))
Services Summary...
Service "VPROD" has 1 instance(s).
  Instance "VPROD1", status UNKNOWN, has 1 handler(s) for this service...
The command completed successfully

[grid@vrh1 admin]$ srvctl stop listener -l MACLEAN_LISTENER

[grid@vrh1 admin]$ srvctl start listener -l MACLEAN_LISTENER  

[grid@vrh1 admin]$ srvctl config listener -l MACLEAN_LISTENER
Name: MACLEAN_LISTENER
Network: 1, Owner: grid
Home:
End points: TCP:1598

[grid@vrh1 admin]$ lsnrctl status MACLEAN_LISTENER

LSNRCTL for Linux: Version 11.2.0.3.0 - Production on 27-NOV-2011 11:01:42

Copyright (c) 1991, 2011, Oracle.  All rights reserved.

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=MACLEAN_LISTENER)))
STATUS of the LISTENER
------------------------
Alias                     MACLEAN_LISTENER
Version                   TNSLSNR for Linux: Version 11.2.0.3.0 - Production
Start Date                27-NOV-2011 11:01:10
Uptime                    0 days 0 hr. 0 min. 31 sec
Trace Level               off
Security                  ON: Local OS Authentication
SNMP                      OFF
Listener Parameter File   /g01/11.2.0/grid/network/admin/listener.ora
Listener Log File         /g01/orabase/diag/tnslsnr/vrh1/maclean_listener/alert/log.xml
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=MACLEAN_LISTENER)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=192.168.1.161)(PORT=1598)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=192.168.1.162)(PORT=1598)))
Services Summary...
Service "VPROD" has 1 instance(s).
  Instance "VPROD1", status UNKNOWN, has 1 handler(s) for this service...
The command completed successfully

 

以上使用netca和netmgr图形界面工具完成了新监听的添加和静态注册工作。

 

2. 使用srvctl 工具添加监听并手动加入静态注册信息

 

检查默认network的network number,红色的数字

[grid@vrh1 admin]$ srvctl config network
Network exists: 1/192.168.1.0/255.255.255.0/eth0, type static

srvctl 添加监听的语法如下

[grid@vrh1 admin]$  srvctl add listener -h

Adds a listener configuration to the Oracle Clusterware.

Usage: srvctl add listener [-l <lsnr_name>] [-s] [-p "[TCP:]<port>[, ...][/IPC:<key>]
[/NMP:<pipe_name>][/TCPS:<s_port>] [/SDP:<port>]"] [-o <oracle_home>] [-k <net_num>]
    -l <lsnr_name>           Listener name (default name is LISTENER)
    -o <oracle_home>         ORACLE_HOME path (default value is CRS_HOME)
    -k <net_num>             network number (default number is 1)
    -s                       Skip the checking of ports
    -p "[TCP:]<port>[, ...][/IPC:<key>][/NMP:<pipe_name>][/TCPS:<s_port>] [/SDP:<port>]"      
Comma separated tcp ports or listener endpoints
    -h                       Print usage

[grid@vrh1 admin]$  srvctl add listener -l NEW_MACLEAN_LISTENER -o $CRS_HOME -p 1601 -k 1

-k 填入方才获得的network number,-p填入端口号,-l填入监听名,-o 填入GI HOME路径

[grid@vrh1 admin]$ srvctl start listener -l NEW_MACLEAN_LISTENER

 

srvctl start listener启动新添加的监听后listener.ora和endpoints_listener.ora会出现新的记录:

 

[grid@vrh1 admin]$ head -1 listener.ora
NEW_MACLEAN_LISTENER=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=IPC)(KEY=NEW_MACLEAN_LISTENER))))           
# line added by Agent

[grid@vrh1 admin]$ head -1 endpoints_listener.ora
NEW_MACLEAN_LISTENER_VRH1=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=vrh1-vip)(PORT=1601))
(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.1.161)(PORT=1601)(IP=FIRST))))            
# line added by Agent

 

以上已经完成了监听的添加,足见使用srvctl管理更为简便。

 

之后仅需要加入静态注册信息即可,如:

 

SID_LIST_NEW_MACLEAN_LISTENER =
  (SID_LIST =
    (SID_DESC =
      (GLOBAL_DBNAME = VPROD)
      (ORACLE_HOME = /g01/11.2.0/grid)
      (SID_NAME = VPROD1)
    )
  )

 

加入如上信息到listener.ora配置文件中(SID_LIST_($LISTENER_NAME),并重启监听即完成静态注册:

 

[grid@vrh1 admin]$ srvctl stop listener -l NEW_MACLEAN_LISTENER

[grid@vrh1 admin]$ srvctl start listener -l NEW_MACLEAN_LISTENER  

[grid@vrh1 admin]$ lsnrctl status NEW_MACLEAN_LISTENER

LSNRCTL for Linux: Version 11.2.0.3.0 - Production on 27-NOV-2011 11:21:37

Copyright (c) 1991, 2011, Oracle.  All rights reserved.

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=NEW_MACLEAN_LISTENER)))
STATUS of the LISTENER
------------------------
Alias                     NEW_MACLEAN_LISTENER
Version                   TNSLSNR for Linux: Version 11.2.0.3.0 - Production
Start Date                27-NOV-2011 11:21:25
Uptime                    0 days 0 hr. 0 min. 11 sec
Trace Level               off
Security                  ON: Local OS Authentication
SNMP                      OFF
Listener Parameter File   /g01/11.2.0/grid/network/admin/listener.ora
Listener Log File         /g01/11.2.0/grid/log/diag/tnslsnr/vrh1/new_maclean_listener/alert/log.xml
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=NEW_MACLEAN_LISTENER)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=192.168.1.161)(PORT=1601)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=192.168.1.162)(PORT=1601)))
Services Summary...
Service "VPROD" has 1 instance(s).
  Instance "VPROD1", status UNKNOWN, has 1 handler(s) for this service...
The command completed successfully

 

以上利用srvctl管理工具完成了添加新监听和静态注册的任务。

近距离接触RAC DRM

drm 是Oracle rac中独有的动态资源管理操作, 我们听了很多关于DRM的理论, 但是你是否亲眼见证过DRM, 今天我们就来看一下:

 

SQL> select * from v$version;

BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
PL/SQL Release 11.2.0.3.0 - Production
CORE 11.2.0.3.0 Production
TNS for Linux: Version 11.2.0.3.0 - Production
NLSRTL Version 11.2.0.3.0 - Production

SQL>
SQL> select count(*) from gv$instance;

COUNT(*)
----------
2

SQL> create table drm_mac(t1 int) tablespace users;

Table created.

SQL> insert into drm_mac values(1);

1 row created.

SQL> commit;

Commit complete.

SQL> alter system flush buffer_cache;

System altered.

SQL>select * from drm_mac;

T1
----------
1

SQL> select object_id,data_object_id from dba_objects where object_name='DRM_MAC';

OBJECT_ID DATA_OBJECT_ID
---------- --------------
64046 64046

--FIRST FIND THE OBJECT IDS
With OBJ_IDS As
(Select DATA_Object_Id OBJECT_ID From Dba_Objects
Where Object_Name = 'DRM_MAC'), --注意替换这里!!!!!!!!!!!!!!!!!
Addr As (Select /*+ materialize */
Le_Addr, class, state From X$Bh, OBJ_IDS
Where Object_Id = Obj),
--NOW GET THE RESOURCE NAME IN HEX
Hexnames As (Select
Rtrim(B.Kjblname, ' '||chr(0)) Hexname
From X$Le A, X$Kjbl B, Addr
Where A.Le_Kjbl=B.Kjbllockp
and class = 1 and state <> 3
And A.Le_Addr = Addr.Le_Addr)
-- NOW FIND THE NODE MASTERS
Select A.Master_Node Mast, Count(*)
From Gv$Dlm_Ress A, Hexnames H
Where
Rtrim(A.Resource_Name, ' '||chr(0)) = H.Hexname
Group by A.Master_Node;

MAST COUNT(*)
---------- ----------
0 5

==> 说明DRM_MAC MASTER 在0节点,共5个BLOCk

登录 2节点

对2节点的LMS进程做DRM TRACE
oradebug setospid 29295;
oradebug event trace[RAC_DRM] disk highest;

之后使用 lkdebug -m pkey data_object_id 来手动出发对DRM_MAC的REMASTER操作

注意即便是手动触发DRM也仅仅是将该OBJECT放入DRM ENQUEUE

*** 2012-11-27 09:27:20.728
Processing Oradebug command 'lkdebug -m pkey 64045'
*****************************************************************
GLOBAL ENQUEUE SERVICE DEBUG INFORMATION
----------------------------------------
Queued DRM request for pkey 64045.0, tobe master 1, flags x1
***************** End of lkdebug output *************************
Processing Oradebug command 'lkdebug -m pkey 64045'
*****************************************************************
GLOBAL ENQUEUE SERVICE DEBUG INFORMATION
----------------------------------------
kjdrrmq: pkey 64045.0 is already on the affinity request queue, old tobe == new tobe 1
***************** End of lkdebug output *************************
SQL> oradebug setmypid
Statement processed.
SQL> oradebug lkdebug -m pkey 64046;

--FIRST FIND THE OBJECT IDS
With OBJ_IDS As
(Select DATA_Object_Id OBJECT_ID From Dba_Objects
Where Object_Name = 'DRM_MAC'), --Customize
Addr As (Select /*+ materialize */
Le_Addr, class, state From X$Bh, OBJ_IDS
Where Object_Id = Obj),
--NOW GET THE RESOURCE NAME IN HEX
Hexnames As (Select
Rtrim(B.Kjblname, ' '||chr(0)) Hexname
From X$Le A, X$Kjbl B, Addr
Where A.Le_Kjbl=B.Kjbllockp
and class = 1 and state <> 3
And A.Le_Addr = Addr.Le_Addr)
-- NOW FIND THE NODE MASTERS
Select A.Master_Node Mast, Count(*)
From Gv$Dlm_Ress A, Hexnames H
Where
Rtrim(A.Resource_Name, ' '||chr(0)) = H.Hexname
Group by A.Master_Node;

MAST COUNT(*)
---------- ----------
1 5

通过 oradebug lkdebug -m pkey 将 MACLEAN_DRM REMASTER到2节点。
SQL> select * from v$gcspfmaster_info where DATA_OBJECT_ID=64045;
FILE_ID DATA_OBJECT_ID GC_MASTERIN CURRENT_MASTER PREVIOUS_MASTER REMASTER_CNT
---------- -------------- ----------- -------------- --------------- ------------
0 64046 Affinity 1 0 1

SQL> select * from gv$policy_history
where DATA_OBJECT_ID=64046
order by EVENT_DATE;

no rows selected
SQL> select * from x$object_policy_statistics;

no rows selected

*** 2013-11-15 04:08:35.191
2013-11-15 04:08:35.191065 : kjbldrmnextpkey: AFFINITY pkey 64046.0
pkey 64046.0 undo 0 stat 5 masters[1, 1->2] reminc 13 RM# 18
flg x7 type x0 afftime x8b0628ee, acquire time 0
nreplays by lms 0 = 0
benefit 0, total 0, remote 0, cr benefit 0, cr total 0, cr remote 0
kjblpkeydrmqscchk: Begin for pkey 64046/0 bkt[0->8191] read-mostly 0
kjblpkeydrmqscchk: End for pkey 64046.0
2013-11-15 04:08:35.191312 : DRM(20) quiesced basts [0-8191]
2013-11-15 04:08:35.197815 :
* lms acks DRMFRZ (8191)
* lms 0 finished parallel drm freeze in DRM(20) window 1, pcount 47
DRM(20) win(1) lms 0 finished drm freeze
2013-11-15 04:08:35.200436 :
* kjbrrcres: In this window: 278 GCS resources, 0 remastered

* In all windows: 278 GCS resources, 0 remastered
2013-11-15 04:08:35.201606 : kjbldrmnextpkey: AFFINITY pkey 64046.0
pkey 64046.0 undo 0 stat 5 masters[1, 1->2] reminc 13 RM# 18
flg x7 type x0 afftime x8b0628ee, acquire time 0
nreplays by lms 0 = 0
benefit 0, total 0, remote 0, cr benefit 0, cr total 0, cr remote 0
kjbldrmrpst: no more locks for pkey 64046.0, #lk 0, #rm 0, #replay 0, #dup 0 objscan 4
DRM(20) Completed replay (highb 8191)
DRM(20) win(1) lms 0 finished replaying gcs resources
kjbmprlst: DRMFRZ replay msg from 1 (clockp 0x92f96c18, 3)
0x1fe6a.5, 64046.0, x0, lockseq 0x13c5, reqid 0x3
state 0x100, 1 -> 0, role 0x0, wrt 0x0.0
GCS RESOURCE 0xb28963a0 hashq [0xbb4cdd38,0xbb4cdd38] name[0x1fe6a.5] pkey 64046.0
grant 0xb19a8370 cvt (nil) send (nil)@0,0 write (nil),0@65536
flag 0x0 mdrole 0x1 mode 1 scan 0.0 role LOCAL
disk: 0x0000.00000000 write: 0x0000.00000000 cnt 0x0 hist 0x0
xid 0x0000.000.00000000 sid 0 pkwait 0s rmacks 0
refpcnt 0 weak: 0x0000.00000000
pkey 64046.0 undo 0 stat 5 masters[1, 1->2] reminc 13 RM# 18
flg x7 type x0 afftime x8b0628ee, acquire time 0
nreplays by lms 0 = 0
benefit 0, total 0, remote 0, cr benefit 0, cr total 0, cr remote 0
hv 3 [stat 0x0, 1->1, wm 32768, RMno 0, reminc 3, dom 0]
kjga st 0x4, step 0.36.0, cinc 15, rmno 19, flags 0x20
lb 0, hb 8191, myb 8141, drmb 8141, apifrz 1
GCS SHADOW 0xb19a8370,4 resp[0xb28963a0,0x1fe6a.5] pkey 64046.0
grant 1 cvt 0 mdrole 0x1 st 0x100 lst 0x40 GRANTQ rl LOCAL
master 2 owner 1 sid 0 remote[0x92f96c18,3] hist 0x10c1430c0218619
history 0x19.0xc.0x6.0x1.0xc.0x6.0x5.0x6.0x1.0x0.
cflag 0x0 sender 0 flags 0x0 replay# 0 abast (nil).x0.1 dbmap (nil)
disk: 0x0000.00000000 write request: 0x0000.00000000
pi scn: 0x0000.00000000 sq[0xb28963d0,0xb28963d0]
msgseq 0x1 updseq 0x0 reqids[3,0,0] infop (nil) lockseq x13c5
GCS SHADOW END
GCS RESOURCE END
2013-11-15 04:08:35.204351 : 0 write requests issued in 72 GCS resources
0 PIs marked suspect, 0 flush PI msgs
2013-11-15 04:08:35.204493 : 0 write requests issued in 99 GCS resources
0 PIs marked suspect, 0 flush PI msgs
2013-11-15 04:08:35.204648 : 0 write requests issued in 54 GCS resources
0 PIs marked suspect, 0 flush PI msgs
2013-11-15 04:08:35.204790 : 0 write requests issued in 35 GCS resources
0 PIs marked suspect, 0 flush PI msgs
2013-11-15 04:08:35.204948 : 0 write requests issued in 18 GCS resources
0 PIs marked suspect, 0 flush PI msgs
2013-11-15 04:08:35.205048 : 0 write requests issued in 0 GCS resources
0 PIs marked suspect, 0 flush PI msgs
2013-11-15 04:08:35.205327 : 0 write requests issued in 0 GCS resources
0 PIs marked suspect, 0 flush PI msgs
2013-11-15 04:08:35.205590 : 0 write requests issued in 0 GCS resources
0 PIs marked suspect, 0 flush PI msgs

* kjbrrcfwst: resp x0xb28963a0, id1 x1fe6a, drm
2013-11-15 04:08:35.205799 : 0 write requests issued in 1 GCS resources
0 PIs marked suspect, 0 flush PI msgs
DRM(20) win(1) lms 0 finished fixing gcs write protocol
2013-11-15 04:08:35.207051 : kjbldrmnextpkey: AFFINITY pkey 64046.0
pkey 64046.0 undo 0 stat 5 masters[1, 1->2] reminc 13 RM# 18
flg x7 type x0 afftime x8b0628ee, acquire time 0
nreplays by lms 0 = 0
benefit 0, total 0, remote 0, cr benefit 0, cr total 0, cr remote 0
kjblpkeydrmqscchk: Begin for pkey 64046/0 bkt[8192->16383] read-mostly 0
kjblpkeydrmqscchk: End for pkey 64046.0
2013-11-15 04:08:35.207595 : DRM(20) quiesced basts [8192-16383]
2013-11-15 04:08:35.209146 :
* lms acks DRMFRZ (16383)
* lms 0 finished parallel drm freeze in DRM(20) window 2, pcount 47
DRM(20) win(2) lms 0 finished drm freeze
2013-11-15 04:08:35.211327 :
* kjbrrcres: In this window: 256 GCS resources, 0 remastered

* In all windows: 534 GCS resources, 0 remastered
2013-11-15 04:08:35.214797 : kjbldrmnextpkey: AFFINITY pkey 64046.0
pkey 64046.0 undo 0 stat 5 masters[1, 1->2] reminc 13 RM# 18
flg x7 type x0 afftime x8b0628ee, acquire time 0
nreplays by lms 0 = 0
benefit 0, total 0, remote 0, cr benefit 0, cr total 0, cr remote 0
kjbldrmrpst: no more locks for pkey 64046.0, #lk 0, #rm 0, #replay 0, #dup 0 objscan 4
DRM(20) Completed replay (highb 16383)
DRM(20) win(2) lms 0 finished replaying gcs resources
kjbmprlst: DRMFRZ replay msg from 1 (clockp 0x92f96d28, 3)
0x1fe6f.5, 64046.0, x0, lockseq 0x13ca, reqid 0x3
state 0x100, 1 -> 0, role 0x0, wrt 0x0.0
GCS RESOURCE 0xb2896520 hashq [0xbb4edd38,0xbb4edd38] name[0x1fe6f.5] pkey 64046.0
grant 0xb19a3750 cvt (nil) send (nil)@0,0 write (nil),0@65536
flag 0x0 mdrole 0x1 mode 1 scan 0.0 role LOCAL
disk: 0x0000.00000000 write: 0x0000.00000000 cnt 0x0 hist 0x0
xid 0x0000.000.00000000 sid 0 pkwait 0s rmacks 0
refpcnt 0 weak: 0x0000.00000000
pkey 64046.0 undo 0 stat 5 masters[1, 1->2] reminc 13 RM# 18
flg x7 type x0 afftime x8b0628ee, acquire time 0
nreplays by lms 0 = 0

SQL> alter system set "_serial_direct_read"=never;

System altered.

SQL> select count(*) from large_drms;

COUNT(*)
----------
999999

SQL> select blocks from dba_tables where table_name='LARGE_DRMS';

BLOCKS
----------
13233

SQL> select object_id,data_object_id from dba_objects where object_name='LARGE_DRMS';

OBJECT_ID DATA_OBJECT_ID
---------- --------------
64474 64474

With OBJ_IDS As
(Select DATA_Object_Id OBJECT_ID From Dba_Objects
Where Object_Name = 'LARGE_DRMS'), --Customize
Addr As (Select /*+ materialize */
Le_Addr, class, state From X$Bh, OBJ_IDS
Where Object_Id = Obj),
--NOW GET THE RESOURCE NAME IN HEX
Hexnames As (Select
Rtrim(B.Kjblname, ' '||chr(0)) Hexname
From X$Le A, X$Kjbl B, Addr
Where A.Le_Kjbl=B.Kjbllockp
and class = 1 and state <> 3
And A.Le_Addr = Addr.Le_Addr)
-- NOW FIND THE NODE MASTERS
Select A.Master_Node Mast, Count(*)
From Gv$Dlm_Ress A, Hexnames H
Where
Rtrim(A.Resource_Name, ' '||chr(0)) = H.Hexname
Group by A.Master_Node;

MAST COUNT(*)
---------- ----------
1 6605
0 6473

oradebug setmypid
oradebug lkdebug -m pkey 64474;

MAST COUNT(*)
---------- ----------
1 13078

 

DRM一张103MB大小的表可以通过AWR了解因为DRM操作而消耗的带宽等资源:

 

 

 

 

 

 

其中来源于RAC AWR的AWRGRPT报告的ininterconnect_device_statistics显示了正确的DRM网络流量, 而普通AWRRPT中的Interconnect Device Statistics似乎并不能正式反映网络流量。

Oracle队列锁:IV,Library Cache Invalidation

IV,Library Cache Invalidation Enqueue Lock

 

相关资源:

在Library cache中当前被缓存的有效或已存数据库对象,例如 表TABLE、视图View、存储过程procedure、package、package body、trigger、index、cluster、synonym;或cursor (SQL or PL/SQL)、pipe、等多种多样的库缓存资源类型

 

相关用户:

所有的可能的Oracle前台或后台进程

 

锁的原因:

LCK后台进程及其他进程视图在集群中的所有实例上使相关的library cache object失效(invalidate)

 

何时使用该队列锁?

当一个有效或现存的数据库对象被加载到library cache库缓存中,LCK RAC后台进程将针对该resource要求一个S共享模式的IV队列锁。直到该对象或者失效或者不再存在或者被age out出library cache,该IV lock才会被释放。 该IV lock存在的目的是在所有实例间使library cache中缓存的对象失效。 若一个进程想要使library cache object失效则首先请求以X mode锁定该对象资源,这将导致所有实例中均使该缓存对象失效以响应BAST并释放他们在该对象上的IV lock,之后发起invalidate进程将释放该X lock。

 

ID1、ID2的组合:

Object Number, Timestamp

 

Lock Value Block:
Not Used.
Init.ora Parameters:
None.

 

Scope:
Global Lock.

 

Deadlock Sensitive:
No.

 

Operation:
Synchronous.

Script: 收集RAC DRM 诊断信息

以下脚本可以用于收集 11gR2中 RAC DRM 动态资源管理 特性的诊断信息:

 

REM for 11.2 only
REM written by Maclean.Liu

set linesize 140 pagesize 1400

select DRMS, AVG_DRM_TIME, QUIESCE_T,FRZ_T,CLEANUP_T,REPLAY_T,FIXWRITE_T,SYNC_T from X$KJDRMAFNSTATS
/

select * from GV$DYNAMIC_REMASTER_STATS
/

select object, node, sopens, xopens, xfers
from x$object_policy_statistics
-- where object=&object_id
/

select data_object_id, current_master, previous_master, remaster_cnt from gv$gcspfmaster_info
/

select * from gv$policy_history
-- where object=&object_id
order by EVENT_DATE
/

select name, value
from v$sysstat
where name in ('gc local grants',
'gc remote grants')
/

再议RAC Brain Split脑裂

这2天在面试DBA Candidate的时候,我问到Oracle RAC中Brain Split脑裂决议的一些概念, 几乎所有的Candidate都告诉我当”只有2个节点的时候,投票算法就失效了,会让2个节点去抢占Quorum Disk,最先获得的节点将活下来” 。 我们姑且把这套理论叫做” 抢占论”。

“抢占论”的具体观点可能与下面这一段文字大同小异:

 

“在集群中,节点间通过某种机制(心跳)了解彼此的健康状态,以确保各节点协调工作。 假设只有”心跳”出现问题, 各个节点还在正常运行, 这时,每个节点都认为其他的节点宕机了, 自己是整个集群环境中的”唯一建在者”,自己应该获得整个集群的”控制权”。 在集群环境中,存储设备都是共享的, 这就意味着数据灾难, 这种情况就是”脑裂”
解决这个问题的通常办法是使用投票算法(Quorum Algorithm). 它的算法机理如下:

观点1:

集群中各个节点需要心跳机制来通报彼此的”健康状态”,假设每收到一个节点的”通报”代表一票。对于三个节点的集群,正常运行时,每个节点都会有3票。 当结点A心跳出现故障但节点A还在运行,这时整个集群就会分裂成2个小的partition。 节点A是一个,剩下的2个是一个。 这是必须剔除一个partition才能保障集群的健康运行。 对于有3个节点的集群, A 心跳出现问题后, B 和 C 是一个partion,有2票, A只有1票。 按照投票算法, B 和C 组成的集群获得控制权, A 被剔除。

 

 

观点2:

如果只有2个节点,投票算法就失效了。 因为每个节点上都只有1票。 这时就需要引入第三个设备:Quorum Device. Quorum Device 通常采用饿是共享磁盘,这个磁盘也叫作Quorum disk。 这个Quorum Disk 也代表一票。 当2个结点的心跳出现问题时, 2个节点同时去争取Quorum Disk 这一票, 最早到达的请求被最先满足。 故最先获得Quorum Disk的节点就获得2票。另一个节点就会被剔除。

 

 

以上这段文字描述中观点1 与我在<Oracle RAC Brain Split Resolution> 一文中提出的看法其实是类似的。  这里再列出我的描述:

在脑裂检查阶段Reconfig Manager会找出那些没有Network Heartbeat而有Disk Heartbeat的节点,并通过Network Heartbeat(如果可能的话)和Disk Heartbeat的信息来计算所有竞争子集群(subcluster)内的节点数目,并依据以下2种因素决定哪个子集群应当存活下去:

  1. 拥有最多节点数目的子集群(Sub-cluster with largest number of Nodes)
  2. 若子集群内数目相等则为拥有最低节点号的子集群(Sub-cluster with lowest node number),举例来说在一个2节点的RAC环境中总是1号节点会获胜。

补充:关于 我引入的子集群的概念的介绍:

“在解决脑裂的场景中,NM还会监控voting disk以了解其他的竞争子集群(subclusters)。关于子集群我们有必要介绍一下,试想我们的环境中存在大量的节点,以Oracle官方构建过的128个节点的环境为我们的想象空间,当网络故障发生时存在多种的可能性,一种可能性是全局的网络失败,即128个节点中每个节点都不能互相发生网络心跳,此时会产生多达128个的信息”孤岛”子集群。另一种可能性是局部的网络失败,128个节点中被分成多个部分,每个部分中包含多于一个的节点,这些部分就可以被称作子集群(subclusters)。当出现网络故障时子集群内部的多个节点仍能互相通信传输投票信息(vote mesg),但子集群或者孤岛节点之间已经无法通过常规的Interconnect网络交流了,这个时候NM Reconfiguration就需要用到voting disk投票磁盘。”

 

争议主要体现在 , “抢占论” 认为当 只有2个节点时 是通过抢占votedisk 的结果来决定具体哪个节点存活下来同时” 抢占论”没有介绍 当存在多个相同节点数目的子集群情况下的结论(譬如4节点的RAC , 1、2节点组成一个子集群,3、4节点组成一个子集群), 若按照2节点时的做法那么依然是通过子集群间抢占votedisk来决定。

 

我个人认为这种说法(“抢占论”)是错误的,不管是具体脑裂时的CRS关键进程css的日志,还是Oracle官方的内部文档都可以说明该问题。

 

我们来看10.2 RAC中的一个场景,假设集群中共有3个节点,其中1号实例没有被启动,集群中只有2个活动节点(active node),发生2号节点的网络失败的故障,因2号节点的member number较小故其通过voting disk向3号节点发起驱逐,具体日志如下:

观察红色部分的日志 ,明确显示了NM(Node Monitor)节点监控服务检查votedisk信息,并计算出了smaller cluster size

以下为2号节点的ocssd.log日志

[    CSSD]2011-04-23 17:42:32.022 [3032460176] >
TRACE: clssnmCheckDskInfo: node 3, vrh3, state 5 with leader 3
has smaller cluster size 1; my cluster size 1 with leader 2

检查voting disk后发现子集群3为最小"子集群"(3号节点的node number较2号大);2号节点为最大子集群

[    CSSD]2011-04-23 17:42:32.022 [3032460176] >TRACE:   clssnmEvict: Start
[    CSSD]2011-04-23 17:42:32.022 [3032460176] >TRACE:   clssnmEvict:
Evicting node 3, vrh3, birth 3, death 13, impendingrcfg 1, stateflags 0x40d
[    CSSD]2011-04-23 17:42:32.022 [3032460176] >TRACE:
clssnmSendShutdown: req to node 3, kill time 1643084

发起对3号节点的驱逐和shutdown request

以下为3号节点的ocssd.log日志:
[    CSSD]2011-04-23 17:43:15.913 [3032460176] >ERROR:   clssnmCheckDskInfo:
Aborting local node to avoid splitbrain.
[    CSSD]2011-04-23 17:43:15.913 [3032460176] >ERROR:                     :
my node(3), Leader(3), Size(1) VS Node(2), Leader(2), Size(1)

读取voting disk后发现kill block,为避免split brain,自我aborting!

 

 

此外Metalink 上一些官方Note 也明确说明了我以上的观点 , 摘录部分内容如下:

 

1.
When interconnect breaks – keeps the largest cluster possible up, other nodes will be evicted, in 2 node cluster lowest number node remains.
 

2.
Node eviction: pick a cluster node as victim to reboot.Always keep the largest cluster possible up, evicted other nodes two nodes: keep the lowest number node up and evict other

 

实际上有部分Vendor Unix Clusterware集群软件的脑裂可能如确实是以谁先获得 “Quorum disk”为决定因素, 但是自10g 推出的Oracle 自己的Real Application Cluster(RAC) 的clusterware 或者说 CRS( cluster ready services) 在Brain Split Resolution时并非如此,在这方面类推并不能帮助我们找出正确的结论。

 

 

RAC中增大db_cache_size引发的ORA-04031错误

几个礼拜前, 有一套10.2.0.2 的 二节点RAC 数据库因为增大db_cache_size , 引发其中一个实例发生著名的ORA-04031 错误,日志如下:

 

Errors in file /oracle/oracle/admin/maclean/udump/u1_ora_13757.trc:
ORA-00603: ORACLE server session terminated by fatal error
ORA-00604: error occurred at recursive SQL level 1
ORA-04031: unable to allocate 1048 bytes of shared memory
("shared pool","select name,online$,contents...","Typecheck","kgghteInit")
ORA-00604: error occurred at recursive SQL level 1
ORA-04031: unable to allocate 1048 bytes of shared memory
("shared pool","select name,online$,contents...","Typecheck","seg:kggfaAllocSeg")
Thu Oct 13 08:25:05 2011
Log from www.askmac.cn  & www.askmac.cn
Errors in file /oracle/oracle/admin/maclean/udump/u1_ora_1444.trc:
ORA-00603: ORACLE server session terminated by fatal error
ORA-00604: error occurred at recursive SQL level 1
ORA-04031: unable to allocate 4120 bytes of shared memory
("shared pool","select name,online$,contents...","Typecheck","kgghtInit")
ORA-00604: error occurred at recursive SQL level 1
ORA-04031: unable to allocate 4120 bytes of shared memory
("shared pool","select name,online$,contents...","Typecheck","kgghtInit")

 

以上错误出现的同时实例出现大量的row cache lock字典缓存和cursor:pin S wait on X等待事件,说明共享池中的row cache字典缓存和SQL area 执行计划因为Free Memory不足而被不断换出,导致硬解析增多并SQL解析性能下降,进一步造成了应用程序挂起,赶到现场后对该ORA-04031错误进行了分析。

SGA中的内存池包含不同大小的内存块。当数据库启动时,会有一块大的内存被分配并使用Free list的空闲列表追踪。随着时间推移,这些内存被不断分配和释放,内存块(chunk)被按照其大小在不同的Fress list中移动,当SGA里任何一个内存池出现不能满足内部分配一整块连续的内存块请求时,就可能出现ORA-04031错误。实际使用中造成ORA-04031错误的原因可能是Oracle软件bug、产品缺陷、应用程序设计不当、Oracle内存参数设置不当。

 

这里出现ORA-04031错误的内存池是shared pool即共享池,为了搞清楚ORA-04031错误发生的实际原因,我们通过AWR报告分析共享池的使用情况。

 

以下是 ORA-04031 问题发生前一天AWR报告中的共享池内存使用情况:

 

Pool Name Begin MB End MB % Diff
large free memory 112.00 112.00 0.00
shared ASH buffers 25.60 25.60 0.00
shared CCursor 19.44 20.16 3.70
shared Checkpoint queue 5.87 5.87 0.00
shared PCursor 10.57 11.14 5.38
shared event statistics per sess 7.72 7.72 0.00
shared free memory 32.99 33.00 0.02
shared gcs resources 78.75 78.75 0.00
shared gcs shadows 49.61 49.61 0.00
shared ges big msg buffers 15.03 15.03 0.00
shared ges reserved msg buffers 7.86 7.86 0.00
shared ges resource 5.28 5.28 0.00
shared kglsim heap 16.63 16.63 0.00
shared kglsim object batch 25.63 25.63 0.00
shared library cache 21.32 22.01 3.23
shared row cache 7.13 7.13 0.00
shared sql area 64.06 61.55 -3.91
streams free memory 64.00 64.00 0.00
buffer_cache 3,936.00 3,936.00 0.00
fixed_sga 2.08 2.08 0.00
log_buffer 3.09 3.09 0.00

 

以下是 ORA-04031 问题发生时AWR报告中的共享池内存使用情况:

 

Pool Name Begin MB End MB % Diff
large free memory 112.00 112.00 0.00
shared ASH buffers 25.60 25.60 0.00
shared Checkpoint queue 5.87 5.87 0.00
shared KCL name table 9.00 9.00 0.00
shared event statistics per sess 7.72 7.72 0.00
shared free memory 25.56 25.52 -0.12
shared gcs resources 143.39 143.39 0.00
shared gcs shadows 90.33 90.33 0.00
shared ges big msg buffers 15.03 15.03 0.00
shared ges reserved msg buffers 7.86 7.86 0.00
shared library cache 7.59 7.65 0.80
shared row cache 7.13 7.13 0.00
shared sql area 8.70 7.35 -15.57
streams free memory 64.00 64.00 0.00
buffer_cache 7,168.00 7,168.00 0.00
fixed_sga 2.09 2.09 0.00
log_buffer 3.09 3.09 0.00

 

红色部分标注了2个报告中差异最大的地方,在问题发生时共享池中gcs resources和gcs shadows 2种资源对比前一天增长了169M。 gcs资源在共享池中享有较高的优先级, 而普通的SQL语句或执行计划享有较低的优先级,因为gcs资源所占用空间的大量膨胀,导致在没有调大共享池大小的情况下sql area和row cache内存资源被换出进而引发SQL解析性能下降和ORA-04031问题。

 

gcs resources和gcs shadow资源均是Oracle RAC中特有的全局缓存服务资源,这些资源负责处理RAC中的全局buffer cache。 同时这些资源所占用共享池的空间视乎Oracle实例所使用高速缓存的大小而决定,Metalink文档说明了该问题:

 

“The ‘gcs resources’ and ‘gcs shadows’ structures are used for handling buffer caches in RAC, so their memory usages are depending on buffer cache size. We can use V$RESOURCE_LIMIT to monitor them.”

 

当实例高速缓存buffer cache被大小时gcs资源所占用的空间也相应增长,具体算法如下:

 

‘gcs_resources’ = initial_allocation * 120 bytes = “_gcs_resources parameter” * 120 bytes
‘gcs_shadows’ = initial_allocation * 72 bytes = “_gcs_shadow_locks parameter” * 72 bytes

select * from v$resource_limit where resource_name like '%gcs%';

RESOURCE_NAME CURRENT_UTILIZATION MAX_UTILIZATION INITIAL_ALLOCATION LIMIT_VALUE
------------------------------ ------------------- --------------- ---
gcs_resources 507772 514607 976083 976083
gcs_shadows 133862 139927 976083 976083

 

我们可以通过现有的v$resource_limit视图中的INITIAL_ALLOCATION估算Buffer cache增加后的INITIAL_ALLOCATION数量,例如我们准备将db_cache_size从10g增加到20g,那么可以通过下列公式算出有必要增加的共享池大小:

 

add_to_shared_pool_size= 140 * Buffer_cache增加的兆数 * 192 bytes * 1.6

= 140 * 10* 1024 * 192 * 1.6 = 440401920 = 420M

 

问题总结

 

由于RAC环境中Oracle 使用共享池中的gcs resource/shadow 资源管理 全局缓存 , 当实例的Buffer Cache总量增加时gcs resource/shadow 这些资源的数目也会相应上升 , 这导致共享池中可用的剩余空间大幅下降,又因为 gcs 全局缓存资源在共享池中享有较高的优先级( perm ,且在10.2中 gcs资源不能和其他如row cache或library cache 共享一个Extent的内存区间) , 引发了大量的row/dictionary cache字典缓存和SQL执行计划被换出共享池, 引发大量的解析等待: cursor pin s on x 和 row cache lock ,  最终还是 没有避免ORA-04031 的错误被触发。 这里要补充一句, 因为这套10g 的系统没有 启用ASMM(Automatic Shared Memory Management) 特性 且 共享池本身设置地较小(shared_pool_size=512MB) , 都是导致该ORA-04031 错误较为显性地被触发的因素 。

 

<深入了解ASMM>中我介绍了ASMM的一些优点, 这里再罗列一下:

手动管理SGA的缺点在于:

  • 个别组件如shared pool、default buffer pool的大小存在最优值,但组件之间无法交换内存
  • 在9i中就提供了多种内存建议(advisor),但都要求人工手动干预
  • 无法适应工作负载存在变化的环境
  • 往往会导致内存浪费,没有用到实处
  • 若设置不当,引发著名的ORA-04031错误的可能性大大提高

ASMM自动管理SGA的优势在于:

  • 全自动的共享内存管理
  • 无需再配置每一个内存组件大小参数
  • 仅使用一个参数sga_target驱动
  • 有效利用所有可用的内存,极大程度上减少内存浪费
  • 对比MSMM其内存管理模式:
    • 更加动态
    • 更加灵活
    • 并具备适应性
  • 易于使用
  • 一定程度上增强了性能,因为内存分配更为合理了
  • 当某个组件急需更多内存时可以有效提供,因此可以一定程度避免ORA-04031的发生

 

解决方案

 

可以通过以下2种方式避免该RAC环境中特有的由增大Buffer_Cache导致GCS资源空间膨胀造成的ORA-04031问题:

  1. 在增加Buffer_Cache的同时估算所需相应增长的shared pool共享池大小
  2. 使用10g的SGA自动管理内存ASMM方式可以一定程度上避免ORA-04031错误的发生,但是自动管理方式存在实际使用时存在一些缺点,建议在启用ASMM:SGA_Target的同时,设置 shared_pool_size和 db_cache_size的最小大小,以最大可能避免因resize造成的问题; 同时建议设置_enabled_shared_pool_duration=false,禁用shared pool duration特性,也可以一定程度上减少ORA-04031发生的概率。

_enabled_shared_pool_duration:该参数控制是否启用10g中特有的shared pool duration特性,当我们设置sga_target为0时该参数为false;同时在10.2.0.5前若cursor_space_for_time设置为true时该参数也为false,不过在10.2.0.5以后cursor_space_for_time参数被废弃

诊断 Oracle Clusterware 和 RAC 组件

本文永久链接地址: https://www.askmac.cn/archives/rac-clusterware-diag.html

RAC 调试中的一个黄金规则

  • 请始终确保各个节点具有完全相同的系统时间,这样才能实现以下目标:

便于进行日志信息分析

确保读取 GV$ 视图时获得准确结果

避免实例被过早逐出

  • 最好的建议方法是使用网络时间协议对各节点进行同步。

 

强烈建议在安装 RAC 之前就在所有集群节点上设置网络时间协议 (NTP)。这样可以使所有节点的时钟保持同步,并且便于根据时间戳以及对 GV$ 视图发出查询的结果对跟踪信息进行分析。

注:如果对时钟的调整超过 15 分钟,则可能导致实例被逐出。因此强烈建议在调整日期/时间之前,先关闭所有实例。

 

Oracle Clusterware 主要日志文件

Oracle Clusterware 将使用统一的日志目录结构来合并 Oracle Clusterware 组件日志文件。
这种合并结构简化了诊断信息收集过程,并有助于进行数据检索和问题分析。

本幻灯片显示了 Oracle Clusterware 用来存储其日志文件的主要目录:

  • CRS 日志位于 $ORA_CRS_HOME/log/<主机名>/crsd/。crsd.log 文件每隔
    10 MB 就进行一次归档(crsd.l01、crsd.l02…)。
  • CSS 日志位于 $ORA_CRS_HOME/log/<主机名>/cssd/。cssd.log 文件每隔
    20 MB 就进行一次归档(cssd.l01、cssd.l02…)。
  • EVM 日志位于 $ORA_CRS_HOME/log/<主机名>/evmd。
  • 取决于资源,具体日志位于 $ORA_CRS_HOME/log/<主机名>/racg 和 $ORACLE_HOME/log/<主机名>/racg 中。在最后一个目录中,imon_<服务>.log
    为各个服务每隔 10 MB 进行一次归档。系统为每个 RACG 可执行文件指定了一个专用子目录。该子目录的名称与该可执行文件的名称相同。

 

  • SRVM (srvctl) 和 OCR(ocrdump、ocrconfig、ocrcheck)日志位于 $ORA_CRS_HOME/log/<主机名>/client/ 和 $ORACLE_HOME/log/<主机名>
    /client/ 中。
  • 重要的 Oracle Clusterware 预警可以在 $ORA_CRS_HOME/log/<主机名> 目录的alert<节点名>.log 内找到。

 

 

诊断收集脚本

  • 用于收集所有重要日志文件的脚本应满足以下条件:

必须以 root 用户身份执行

位于 $ORA_CRS_HOME/bin/

名为 diagcollection.pl

  • 将在本地目录中生成以下文件:

basData _<主机名>.tar.gz

crsData _<主机名>. tar.gz

 

# export ORACLE_HOME=/u01/app/oracle/product/10.2.0/db_1

# export ORA_CRS_HOME=/u01/crs1020

# export ORACLE_BASE= =/u01/app/oracle

# cd $ORA_CRS_HOME/bin

# ./diagcollection.pl -collect

使用 diagcollection.pl 脚本可以从 Oracle Clusterware 安装过程中收集诊断信息。这些诊断提供了附加的信息,Oracle 技术支持可以使用这些信息来解决问题。该脚本位于 $ORA_CRS_HOME/bin 中。开始执行脚本之前必须以 root 用户身份登录并且必须设置以下环境变量:ORACLE_BASE、ORACLE_HOME、ORA_CRS_HOME、HOSTNAME。本幻灯片中的示例显示了如何调用该脚本以收集诊断信息。使用 –collect 选项调用该脚本时,该脚本将在本地目录中生成本幻灯片中提到的 4 个文件。basData.tar.gz 主要包含 $ORACLE_BASE/admin 目录中的日志文件。crsData.tar.gz 包含 $ORA_CRS_HOME/log/<主机名> 的日志文件。
ocrData.tar.gz 文件包含 ocrdump、ocrcheck 的结果以及 ocr 备份列表。oraData.tar.gz 包含 $ORACLE_HOME/log/<主机名> 的日志文件。
如果使用 -collect 选项调用该脚本,并且本地目录中已包括由先前某次运行生成的 4 个文件,则该脚本会询问您是否覆盖现有文件。还可以使用 –clean 选项来调用该脚本,以
清除本地目录中由先前某次运行所生成的文件。还可以调用该脚本,使其仅捕获日志文件的一个子集。为此,可以在 –collect 选项后添加额外的选项:添加 -crs 可收集 Oracle Clusterware 日志,添加 -oh 可收集 ORACLE_HOME 日志,添加 -ob 可收集 ORACLE_BASE 日志,而添加 –all 可收集所有日志。–all 为默认选项。–coreanalyze 选项可使您仅将生成的文件中的核心文件提取到文本文件中。

 

管理 RAC 中的诊断数据

Oracle RAC 实例出现的问题是要诊断的最难的问题类型。例如,您可能需要对多个实例的跟踪文件进行关联,并合并这些跟踪文件。Oracle Database Release 11g 包括一个高级错误诊断基础结构,用于收集和管理诊断数据,并使用基于自动诊断资料档案库 (ADR) 文件的资料档案库来存储数据库诊断数据。在共享磁盘上创建 ADR 基目录时,可将同一 Oracle RAC 数据库的所有实例置于 ADR 主目录中,还可将所有相应 ASM 实例置于同一 ADR 基目录下。由于一些 ADRCI 命令(如 SHOW INCIDENT)可以同时处理多个 ADR 主目录,因此通过共享存储,可使用 ADRCI 命令行工具对所有实例的诊断数据进行关联。

注:尽管未作要求,但还是建议您共享 RAC 数据库的 ADR 基目录。但是,如果使用共享的 Oracle 主目录,则必须共享 ADR 基目录。

 

集群验证:概览

  • 验证您是否有正确格式的集群对 Oracle Clusterware RAC 执行以下操作:

安装

配置

操作

  • 完整堆栈验证
  • 非干扰性验证
  • 诊断模式将进行查找,以确定导致任何验证任务失败的原因。
  • 界面简单易用:

登台期命令

组件命令

 

集群验证实用程序 (CVU) 随包含 Real Application Clusters 的 Oracle Clusterware 和 Oracle Database 10g 发行版 2 (10.2) 一起提供。提供 CVU 的目的是:在设置和配置过程中,允许您验证是否已正确安装和配置了成功安装 Oracle Clusterware 或 Oracle Clusterware 及 RAC 数据库所需的所有组件,并且在您需要更改 RAC 集群时随时为您提供实时帮助。

CVU 命令有两种:

  • 登台期命令属于 CVU 命令,用于测试系统设置,并测试是否已为成功的软件安装、数据库创建或更改步骤配置做好准备。还可以使用这些命令来验证是否已成功地完成了特定的集群配置步骤。
  • 组件命令是用来检查各个集群组件并确定其状态的 CVU 命令。

建议在安装 Oracle Clusterware 和 RAC 的过程中使用登台期检查。

此外,还可以在堆栈运行期间使用 CVU 来验证特定组件,或者隔离某个集群子系统以进行诊断。在诊断模式下运行时,CVU 将尝试确定导致任何验证任务失败的原因,以帮助诊断问题。

注:CVU 是一个非干扰性工具,因为它不会尝试修复所发现的任何问题。

 

集群验证登台期

登台期是指 Oracle Clusterware 或 RAC 部署过程中的一个特定阶段。在登台期中执行任何操作之前,必须先执行一组预定义的检查,以确保集群已准备好进入该登台期。这些检查称为该登台期的“预”检查。同样,完成某个登台期后也必须执行一组预定义的检查,以确保在该登台期中正确执行了操作。这些检查称为该登台期的“后”检查。可以使用 cluvfy stage -list 命令来列出可验证的登台期。所有登台期都包括预检查或后检查步骤,某些登台期还同时包含两者。有效的登台期选项和登台期名称包括:

  • post hwos:对硬件和操作系统进行后检查
  • pre cfs:对 CFS 设置进行预检查
  • post cfs:对 CFS 设置进行后检查
  • pre crsinst:对 CRS 安装进行预检查
  • post crsinst:对 CRS 安装进行后检查
  • pre dbinst:对数据库安装进行预检查
  • pre dbcfg:对数据库配置进行预检查

 

集群验证组件

  • RAC 集群的单个子系统或模块被称为 CVU 中的组件。
  • 可以对集群组件的可用性和完整性进行验证。
  • 组件可能很简单(如某个特定的存储设备),也可能很复杂(如 Oracle Clusterware 堆栈):

空间可用性

共享存储可访问性

节点连接

集群文件系统完整性

Oracle Clusterware 完整性

集群完整性

管理权限

对等对象兼容性

系统要求

 

$ cluvfy comp -list

CVU 支持组件验证。这一类的验证不与任何特定登台期相关联。组件的范围很广,既可以是可用磁盘空间等基本组件,也可以是 Oracle Clusterware 堆栈等复杂组件(跨多个子组件)。可以对集群组件的可用性、完整性或任何其它特定行为进行验证。可以使用 cluvfy comp -list 命令来列出可验证的 CVU 组件。

  • nodereach检查各节点之间的可访问性
  • nodecon检查节点连接
  • cfs检查 Oracle 集群文件系统完整性(OCFS2 1.2.1 版本和更高版本支持对文件系统的共享检查)
  • ssa检查共享存储的可访问性
  • space检查空间可用性
  • sys检查最低系统要求
  • clu检查集群完整性
  • clumgr检查集群管理器完整性
  • ocr检查 OCR 完整性
  • crs检查 CRS 完整性
  • nodeapp检查是否存在节点应用程序
  • admprv检查管理权限
  • peer与对等对象进行属性比较

 

集群验证位置

  • OTN 下载:

创建本地目录。

复制和提取 cvu_<OS>.zip

  • Oracle 软件 DVD:

Disk1 目录

runcluvfy.sh

  • Oracle Clusterware 主目录:

$ORA_CRS_HOME/bin/cluvfy

  • Oracle 主目录:

$ORACLE_HOME/bin/cluvfy

集群验证实用程序 (CVU) 最初在 Oracle Clusterware 10.2.0.1.0 发行版中发行。CVU 支持 Oracle Clusterware 和 RAC 产品的 11gR1、10gR2,以及 10gR1。可以通过三种不同的方式获得 CVU:

  • 通过 Oracle 技术网 (OTN):http://www.oracle.com/technology/products/database/clustering/cvu/cvu_download_homepage.html
    在这里,您需要下载程序包并将该程序包解压缩到本地目录 (<cvhome>)。您可以使用 <cvhome>/bin 中的 cluvfy 命令。根据需要,还可以设置 CV_DESTLOC 环境变量。该变量将指向所有节点上的可写区域。CVU 将根据此位置的需要尝试复制必要的位。如果未设置此变量,CVU 将使用 /tmp 作为默认目录。
  • 通过打包版本的 11.1 Oracle 软件 DVD。如果没有安装任何软件,则需要使用 runcluvfy.sh。可以在 Disk1 中找到它。
  • 它同时安装在 11.1 Oracle Clusterware 主目录和 RAC 主目录中。如果安装了 CRS 软件堆栈,则利用 cluvfy。如果安装了 CRS 软件,则可以在 $ORA_CRS_HOME/bin 下找到 cluvfy。

注:对于手动安装,只需要在一个节点上安装 CVU。在需要访问远程节点的执行过程中,CVU 会在远程节点上部署自身。

 

集群验证配置文件

$ cat cvu_config

# Configuration file for CVU

# Version: 011405

#

 

#CV_ORACLE_RELEASE=11gR1

 

#CV_NODE_ALL=

 

CV_RAW_CHECK_ENABLED=TRUE

 

CV_ASSUME_DISTID=Taroon

 

#CV_XCHK_FOR_SSH_ENABLED=TRUE

 

#ORACLE_SRVM_REMOTESHELL=/usr/bin/ssh

 

#ORACLE_SRVM_REMOTECOPY=/usr/bin/scp

 

可以使用 CVU 的配置文件来定义执行 CVU 所需的特定输入。配置文件的路径为 $CV_HOME/cv/admin/cvu_config。下面是 cvu_config 中支持的关键字列表:

  • CV_NODE_ALL如果设置了该关键字,则将指定当未安装 Oracle Clusterware 并在命令行中使用了 -n all 选项时应选取的节点列表。
  • CV_RAW_CHECK_ENABLED如果设置为 TRUE,则启用检查以检查 Red Hat 3.0 发行版或更高版本中共享的 SCSI 磁盘的可访问性。此共享磁盘可访问性检查要求在所有节点上安装 cvuqdisk rpm。默认情况下,此关键字被设置为 TRUE,并且共享磁盘检查为启用状态。
  • CV_ASSUME_DISTID指定 CVU 所使用的分发 ID。例如,要将 CVU 与 SuSE 9 ES 结合使用,请将该关键字设置为 Pensacola。
  • CV_XCHK_FOR_SSH_ENABLED如果设置为 TRUE,则将启用 X-Windows 检查,以使用 ssh 验证用户等同性。默认情况下,该项将被注掉,并且 X-Windows 检查为禁用状态。
  • ORACLE_SRVM_REMOTESHELL如果设置了该关键字,则指定 ssh/rsh 命令的位置以改写 CVU 的默认值。默认情况下,此项被注掉,工具使用 /usr/sbin/ssh 和 /usr/sbin/rsh。

注:如果 CVU 未找到配置文件中定义的关键字项,则将搜索与该关键字的名称匹配的环境变量,否则 CVU 使用默认值。

  • ORACLE_SRVM_REMOTECOPY:如果设置了该关键字,则指定 scp 或 rcp 命令的位置以改写 CVU 的默认值。默认情况下,此项被注掉,CVU 使用 /usr/bin/scp 和 /usr/sbin/rcp。

如果 CVU 未找到配置文件中定义的关键字项,则将搜索与该关键字的名称匹配的环境变量。如果设置了该环境变量,则 CVU 将使用它的值,否则将使用该实体的默认值。

要为 CVU 提供集群的所有节点的列表,可以在执行命令时使用 -n all 选项。CVU 将尝试按以下顺序获取节点列表:

  1. 如果供应商集群件可用,则 CVU 将使用 lsnodes 实用程序从供应商集群件中选择所有已配置的节点。
  2. 如果安装了 Oracle Clusterware,则 CVU 将使用 olsnodes 实用程序从 Oracle Clusterware 中选择所有已配置的节点。
  3. 如果既未安装供应商集群件,也未安装 Oracle Clusterware,则 CVU 将在配置文件中搜索 CV_NODE_ALL 关键字的值。

如果未安装供应商集群件和 Oracle Clusterware,并且配置文件中不存在名为 CV_NODE_ALL 的关键字,则 CVU 将为 CV_NODE_ALL 环境变量搜索值。如果未设置该变量,则 CVU 会报告错误。

 

集群验证:示例

$ cluvfy comp sys -n node1,node2 -p crs -verbose

$ cluvfy comp ssa -n all -s /dev/sda1

$ cluvfy comp space -n all -l /home/product -z 5G

$ cluvfy comp nodereach -n node2 –srcnode node1

$ cluvfy comp nodecon -n node1,node2 –i eth0 -verbose  

$ cluvfy comp admprv -n all -o user_equiv -verbose  

$ cluvfy comp nodeapp -n all -verbose

$ cluvfy comp peer -n all –verbose | more

 

本幻灯片显示了一些有趣的可能示例:

  1. 要在安装 Oracle Clusterware 或 RAC 之前验证最低系统要求,请使用 sys 组件验证命令。要检查安装 RAC 的系统要求,请使用 -p database 参数,要检查安装 Oracle Clusterware 的系统要求,请使用 -p crs 参数。要检查从 Oracle Database 10g 1 发行版 (10.1) 安装 Oracle Clusterware 或 RAC 的系统要求,请使用 -r 10gR1 参数。本例验证了在称为 node1 和 node2 的集群节点上安装 Oracle Clusterware 的系统要求。
  2. 要验证是否在集群数据库的各节点之间共享存储,或者要标识系统中可用并且能够在各集群节点之间共享的所有存储,请使用组件验证命令 ssa。本例使用 –s 选项指定了要检查的路径。
  3. 您计划在集群中每个节点的 /home/product 本地文件系统中安装其它软件,该软件在每个节点上需要 5 GB 的空间。如果每个节点的 /home/product 中有 5 GB 的可用空间,该命令将成功,否则,该命令将失败。

注:–verbose 选项可与任何命令结合使用。它主要用于在输出中为您提供更多的信息。

  1. 要验证是否可以从本地节点或任何其它集群节点访问集群节点,请使用组件验证命令 nodereach。本例尝试检查是否可以从 node1 访问 node2。
  2. 要通过所有可用网络接口或特定网络接口来验证集群节点之间的连接,请使用组件验证命令 nodecon。本例将检查 node1 和 node2 是否可以通过 eth0 网络接口进行通信。如果不使用 -i 选项,CVU 将搜索集群节点上的所有可用网络接口,查看接口所对应的 IP 地址和子网,获取适合用作 VIP 的接口列表以及适合用作专用互连的接口列表,并通过这些接口验证所有节点之间的连接。
  3. 要针对用户等同性、Oracle Clusterware 安装和 RAC 安装来验证与用户帐户和管理权限相关的问题,请使用组件验证命令 admprv。在 Linux 和 UNIX 平台上,本例将验证所有节点的用户等同性,方法是:首先使用 ssh,如果 ssh 检查失败,再使用 rsh。要仅使用 ssh 验证等同性,请使用 -sshonly 选项。默认情况下,等同性检查不会验证 X-Windows 配置,例如,当使用 DISPLAY 环境变量的设置禁用了
    X-forwarding 时。要在用户等同性检查过程中验证 X-Windows 的各个方面,请在运行该命令之前,在配置文件中将 CV_XCHK_FOR_SSH_ENABLED 关键字设置为 TRUE。使用 -o crs_inst 参数可验证您是否有权安装 Oracle Clusterware。可以使用 -o db_inst 参数验证安装 RAC 所需的权限,并可以使用 -o db_config 参数验证创建 RAC 数据库或修改 RAC 数据库配置所需的权限。
  4. 本例将验证在所有节点上是否均存在节点应用程序,即 VIP、ONS 和 GSD。要验证所有 Oracle Clusterware 组件的完整性,请使用组件验证命令 crs。要验证每个集群管理器子组件 (CSS) 的完整性,请使用组件验证命令 clumgr。要验证 Oracle 集群注册表的完整性,请使用组件验证命令 ocr。要检查整个集群的完整性,即验证集群中的所有节点是否都具有相同的集群配置视图,请使用组件验证命令 clu。
  5. 本例将对所有节点进行比较,并确定预选属性的值之间是否存在任何差异。如果发现所有节点上的设置都相同,则该命令将成功。还可以将 comp peer 命令与
    -refnode 选项结合使用,以针对参考节点比较其它节点的属性。使用此命令可以指定 –r 10gR1 选项。下面显示了一个截取的预选属性列表:
    各种组件(glibc、make、binutils、gcc、compat-db …)的总内存、交换空间、内核版本、系统体系结构、程序包存在性,”oinstall” 的组存在性,”dba” 的组存在性,”nobody” 的用户
    存在性。

注:对于登台期示例,请参阅本课程中的安装课程。

 

集群验证输出:示例

$ cluvfy comp crs -n all -verbose

Verifying CRS integrity

Checking CRS integrity…

Checking daemon liveness

Liveness of all the daemons

  Node Name     CRS daemon     CSS daemon       EVM daemon

  ————  ————-  —————  ———-

  atlhp9        yes            yes              yes

  atlhp8        yes            yes              yes

Checking CRS health…

Check: Health of CRS

  Node Name                           CRS OK?

  ———————————-  ————————

  atlhp9                              yes

  atlhp8                              yes

Result: CRS health check passed.

CRS integrity check passed.

Verification of CRS integrity was successful.

 

幻灯片显示了 cluvfy comp crs –n all –verbose 命令的输出。此命令用于检查整个 Oracle Clusterware 堆栈。

注:由于格式方面的原因,输出被截断。

 

 

Oracle 管理10g/11.1 Clusterware CRS/CSS

本文永久地址: https://www.askmac.cn/archives/oracle-clusterware-management-11.html

 

学完本课后,应能完成以下工作:

  • 手动控制 Oracle Clusterware 堆栈
  • 更改表决磁盘配置
  • 备份或恢复表决磁盘
  • 手动备份 OCR
  • 恢复 OCR
  • 替换 OCR 镜像
  • 修复 OCR 配置
  • 更改 VIP 地址
  • 使用 CRS 框架
  • 防止实例自动重新启动

本课的目标是了解可在 Oracle Clusterware 级别执行的各种管理任务。虽然本课清楚详细地介绍了一些重要过程,但并没有系统地说明所使用的每个命令行工具的完整语法。在本课中,您将使用以下工具管理 Oracle Clusterware:

  • crsctl
  • crs_stat
  • ocrconfig
  • ocrcheck
  • ocrdump
  • srvctl
  • oifcfg
  • crs_profile、crs_register、crs_setperm、crs_start、crs_relocate、crs_stop、crs_unregister

有关可在本课中看到的各种命令选项的详细信息,请参阅《Oracle Database Oracle Clusterware and Oracle Real Application Clusters Administration and Deployment Guide》。

 

 

 

Oracle Clusterware概览

 

  • 可为 RAC 数据库和(或)其它应用程序提供 HA 的可移植集群基础结构:

监视应用程序的运行状况

出现故障时重新启动应用程序

节点出现故障时可以对应用程序进行故障转移

 

 

Oracle Clusterware 是向 RAC 数据库和其它应用程序提供高可用性 (HA) 的可移植集群基础结构。Oracle Clusterware 通过以下方式确保应用程序的高可用性:监视应用程序的运行状况,在出现故障时重新启动应用程序,在当前使用的节点出现故障或应用程序无法再在当前节点中运行时将应用程序重新定位到其它集群节点。节点出现故障时,某些类型的受保护应用程序(如数据库实例)不会被故障转移到正常节点。

此处,集群是两个或多个节点的集合,这些节点共享一个由 Oracle Clusterware 系统文件(OCR 和表决磁盘)、公用网络互连和公用操作系统使用的公用存储池。

本幻灯片中的图形说明了一个可能的三节点配置,其中节点 1 运行 RAC 数据库实例、监听程序和应用程序 A,它们都受 Oracle Clusterware 保护。

在节点 2 上,只有 RAC 数据库实例和监听程序受 Oracle Clusterware 保护。

在节点 3 上,应用程序 B 受 Oracle Clusterware 保护。

Oracle Clusterware 定期监视所有受保护的应用程序,它可以根据定义的故障转移策略,在同一节点上重新启动这些应用程序,或将这些应用程序重新定位到其它节点,也可以决定不重新启动这些应用程序。

注:虽然 Oracle Clusterware 是使用 RAC 时的必需组件,但如果仅用于保护 RAC 数据库以外的应用程序,则不需要 RAC 许可证。

 

Oracle Clusterware 运行时视图

 

在 UNIX 上,Oracle Clusterware 堆栈通过 respawn 从 /etc/inittab 中的项运行。在 Windows 上,该堆栈使用服务控制器运行。下面是对各进程的基本描述:

  • 集群同步服务守护程序 (OCSSD):此进程既可以在供应商集群件环境中运行,也可以在非供应商集群件环境中运行。它能够与现有供应商集群件(如果存在)相集成。OCSSD 的主要工作是监视节点间运行状况(主要使用网络互连和表决磁盘来执行此工作),以及通过组服务发现数据库/ASM 实例端点。OCSSD 以 oracle 用户身份运行,在因故障退出时可以使计算机重新启动,以防止在出现裂脑 (split brain) 时数据遭到损坏。
  • 进程监视器守护程序 (OPROCD):此进程是在任意非供应商集群件环境中衍生的。如果 OPROCD 检测到问题,它就会终止相应节点。它以 root 用户身份运行。此守护程序用于检测计算机硬件问题及驱动程序冻结问题。如果某台计算机被冻结了很长时间,以致其它节点将其从集群中逐出,则该计算机需要自行终止,以防止在集群的其余节点重新配备锁定后向磁盘重新发出任何 I/O。
  • 集群就绪服务守护程序 (CRSD):此进程是高可用性操作的引擎。它管理由 Oracle Clusterware 注册的应用程序,它通过特殊操作脚本启动、停止和检查这些应用程序,并对其进行故障转移。CRSD 可衍生名为 RACGIMON 的专用进程,后者用于监视数据库和 ASM 实例的运行状况,并存储各种功能线程,如快速应用通知 (FAN)。将为每个实例衍生一个 RACGIMON 进程。CRSD 将在 OCR(Oracle 集群注册表)中维护配置概要文件以及资源状态。它以 root 用户身份运行,在出现故障时可以自动重新启动。此外,CRSD 可以衍生临时子项,用于执行某些特殊操作,例如:

-racgeut(按计时器执行),用于终止在某个时间段后未完成的操作

-racgmdb(管理数据库),用于启动/停止/检查实例

-racgchsn(更改服务名称),用于添加/删除/检查实例的服务名称

-racgons,用于向 OCR 添加/删除 ONS 配置

-racgvip,用于启动/停止/检查实例虚拟 IP

  • 事件管理守护程序 (EVMD):此进程可在发生事件时转发集群事件。它可以衍生一个永久性的子 evmlogger,而后者可根据需要衍生用于调用调出的子项(如 racgevtf)。它以 oracle 用户身份运行,在出现故障时可以自动重新启动。

注:RACG 基础结构用于在高可用的集群环境中部署 Oracle DB。此基础结构主要使用 racgwrap 脚本实现,该脚本将调用 racgmain 程序。CRS 将使用此基础结构为所有以节点为中心的资源执行各种操作,并为 RACGIMON 的所有以实例为中心的资源执行代理操作。一般情况下,此基础结构负责管理所有 ora.* 资源。

 

 

手动控制 Oracle Clusterware 堆栈

要实现计划停机,可能需要使用以下命令:

# crsctl stop crs -wait

# crsctl start crs -wait

# crsctl disable crs

# crsctl enable crs

 

添加 Oracle Clusterware 节点时,Oracle Clusterware 进程会自动启动。可以通过使用 crsctl 命令来控制此操作。在应用补丁程序或任何计划停机期间,可能必须手动控制 Oracle Clusterware 堆栈。此外,当与 Oracle Clusterware 组合使用时,第三方集群件也可以使用这些命令。

可以使用 crsctl stop crs 命令停止 Oracle Clusterware 堆栈。

也可以使用 crsctl start crs 命令启动 Oracle Clusterware 堆栈。–wait 选项可显示每个守护程序的进度和状态。没有该选项,命令会立即返回。

使用 crsctl disable crs 命令可以阻止 Oracle Clusterware 在以后重新启动时被启动。此命令不会停止当前正在运行的 Oracle Clusterware 堆栈。

使用 crsctl enable crs 命令可以允许 Oracle Clusterware 在以后重新启动时被启动。

注:必须以 root 用户身份运行这些命令。

 

CRS 资源

  • 资源是受 CRS 管理的应用程序
  • 应用程序概要文件属性存储在 OCR 中:

检查间隔

故障策略

  • 操作脚本必须能够执行以下操作

启动应用程序

停止应用程序

检查应用程序

  • 资源的生命周期:

CRS 是管理集群中应用程序的高可用性操作的主要应用程序。CRS 所管理的应用程序统称为资源。默认情况下,CRS 可以管理 RAC 资源,如数据库实例、ASM 实例、监听程序、实例 VIP、服务、ONS 和 GSD 等。CRS 还可以管理其它类型的应用程序进程和应用程序 VIP。系统将根据存储在 OCR 中的 CRS 资源配置参数(资源概要文件)及存储在任意位置的操作脚本来管理 CRS 资源。资源概要文件包含检查间隔、故障策略、操作脚本名称、CRS 管理应用程序时应使用的权限,以及资源相关性等信息。操作脚本必须能够启动、停止和检查应用程序。

CRS 提供了以下工具来支持资源的生命周期:

  • crs_profile,用于创建和编辑资源概要文件。
  • crs_register,用于向 CRS 所管理的应用程序列表添加资源。
  • crs_start,用于根据资源的概要文件启动资源。资源启动后,CRS 会定期使用检查操作来持续地监视其应用程序进程。此外,如果应用程序意外脱机,系统将根据应用程序的资源概要文件重新启动该应用程序并(或)将其故障转移到其它节点。
  • crs_stat,用于通知资源列表的当前状态。
  • crs_relocate,用于将资源移到集群中的其它节点。
  • crs_unregister,用于将资源从 CRS 的监视范围中删除。

 

RAC 资源

$ /bin/crs_stat -t
Name                            Type        Target State  Host
----------------------------------------------------------------
ora.atlhp8.ASM1.asm             application ONLINE ONLINE atlhp8
ora.atlhp8.LISTENER_ATLHP8.lsnr application ONLINE ONLINE atlhp8
ora.atlhp8.gsd                  application ONLINE ONLINE atlhp8
ora.atlhp8.ons                  application ONLINE ONLINE atlhp8
ora.atlhp8.vip                  application ONLINE ONLINE atlhp8
ora.atlhp9.ASM2.asm             application ONLINE ONLINE atlhp9
ora.atlhp9.LISTENER_ATLHP9.lsnr application ONLINE ONLINE atlhp9
ora.atlhp9.gsd                  application ONLINE ONLINE atlhp9
ora.atlhp9.ons                  application ONLINE ONLINE atlhp9
ora.atlhp9.vip                  application ONLINE ONLINE atlhp9
ora.xwkE.JF1.cs                 application ONLINE ONLINE atlhp8
ora.xwkE.JF1.xwkE1.srv          application ONLINE ONLINE atlhp8
ora.xwkE.JF1.xwkE2.srv          application ONLINE ONLINE atlhp9
ora.xwkE.db                     application ONLINE ONLINE atlhp9
ora.xwkE.xwkE1.inst             application ONLINE ONLINE atlhp8
ora.xwkE.xwkE2.inst             application ONLINE ONLINE atlhp9



crs_stat –t 命令显示了当前受 Oracle Clusterware 控制的所有资源。在本幻灯片所示的示例中,仅包含以前缀 ora. 开头的资源。它们是在集群环境中实现 RAC 高可用性的资源。

可以看到,默认情况下 Oracle Clusterware 可以控制数据库、数据库实例和 ASM 实例、VIP/ONS/GSD/监听程序(也称为 nodeapps)、服务和服务成员。

在本幻灯片中,资源的 Target 状态为 ONLINE,这表示在节点下一次重新启动时,Oracle Clusterware 将尝试自动启动它们。

State 显示了资源的当前状态。

Target 可以为 ONLINE 或 OFFLINE。

State 可以为 ONLINE、OFFLINE 或 UNKNOWN。UNKNOWN 是失败的启动/停止操作所产生的状态,只能由 crs_stop -f resourceName 命令重置。可以使用 Target 和 State 的组合来确定资源是将要启动还是将要停止。

Host 显示了在其中管理资源的主机的名称。

注:由于格式方面的原因,使用 crs_stat –t 命令时会截断资源名称。为了清楚起见,输出示例恢复了资源的完整名称。

 

资源属性:示例

$ /bin/crs_stat -p ora.JFDB.JFDB1.inst
NAME=ora.JFDB.JFDB1.inst
TYPE=application
ACTION_SCRIPT=/u01/app/oracle/product/10g/bin/racgwrap
ACTIVE_PLACEMENT=0
AUTO_START=1
CHECK_INTERVAL=600
DESCRIPTION=CRS application for Instance
FAILOVER_DELAY=0
FAILURE_INTERVAL=0
FAILURE_THRESHOLD=0
HOSTING_MEMBERS=atlhp8
PLACEMENT=restricted
REQUIRED_RESOURCES=ora.atlhp8.ASM1.asm
RESTART_ATTEMPTS=5
…
$ /bin/crs_stat –t ora.xwkE.xwkE1.inst
Name           Type         Target    State    Host
-----------------------------------------------------
ora....E1.inst application  ONLINE    ONLINE   atlhp8


 

可以使用 crs_stat –p resource_name 命令打印已命名的资源的 OCR 内容。本幻灯片中的示例显示了需要为 RAC 数据库实例获取的 OCR 内容。对于每个资源而言,并非所有属性都是必需的。下面简要介绍了上述输出中所显示的最重要的属性:

  • NAME 是应用程序资源的名称。
  • 对于所有 CRS 资源,TYPE 必须为 APPLICATION。
  • ACTION_SCRIPT 是 CRS 用于启动、检查和停止应用程序的操作脚本的名称和位置。默认路径是 <CRS 主目录>/crs/script。
  • ACTIVE_PLACEMENT 默认值为 0。将其设置为 1 时,Oracle Clusterware 在添加或重新启动集群节点时会重新评估资源的位置。
  • AUTO_START 是一个标记,用于指示无论在集群重新启动之前资源是否处于运行状态,Oracle Clusterware 是否都应在集群重新启动后自动启动某个资源。如果将其设置为 0,则仅当资源在集群重新启动之前处于运行状态时,Oracle Clusterware 才会启动该资源。如果将其设置为 1,则 Oracle Clusterware 会在集群重新启动后始终启动该资源。如果将其设置为 2,则 Oracle Clusterware 从不重新启动资源(无论资源在节点停止时处于何种状态)。
  • CHECK_INTERVAL 是重复执行应用程序的检查命令的时间间隔(以秒为单位)。
  • DESCRIPTION 是对资源的描述。
  • FAILOVER_DELAY 是 Oracle Clusterware 在尝试重新启动资源或对其进行故障转移之前所等待的时间(以秒为单位)。
  • FAILURE_INTERVAL 是 Oracle Clusterware 应用故障阈值的间隔(以秒为单位)。如果该值为零 (0),则禁用故障跟踪。
  • FAILURE_THRESHOLD 是在 Oracle Clusterware 将资源标记为不可用并不再对其进行监视之前,在指定 FAILURE_INTERVAL 内检测到的故障数。如果资源的检查脚本多次超出此阈值,则将停止资源并将其设置为脱机。如果该值为零 (0),则禁用故障跟踪。最大值为 20。
  • HOSTING_MEMBERS 是可作为资源宿主的集群节点的顺序列表,各节点之间用空格分隔。运行 olsnodes 命令可查看节点名称。
  • PLACEMENT 定义位置策略(balanced、favored 或 restricted),该策略指定 Oracle Clusterware 如何选择在其中启动资源的集群节点:

-balanced:Oracle Clusterware 支持在当前运行最少资源的节点上启动或重新启动应用程序。将选择包含最少资源的主机。如果没有符合这些条件的节点,则会选择任何可用节点。

-favored:Oracle Clusterware 将引用应用程序概要文件的 HOSTING_MEMBERS 属性中的节点列表。只有位于此列表中并满足资源要求的集群节点才纳入位置考虑中。宿主节点的顺序确定了哪个节点应运行应用程序。如果宿主节点列表中没有可用节点,则 Oracle Clusterware 会将应用程序放在任意可用节点上。此节点可能包含也可能不包含在 HOSTING_MEMBERS 列表中。

-restricted:与 favored 策略相似,但有一点除外:如果宿主列表中没有可用节点,则 Oracle Clusterware 不会启动或重新启动应用程序。restricted 位置策略可确保从不在该列表中未包含的节点上运行应用程序,即使手动将该应用程序重新定位到该节点也是如此。

  • REQUIRED_RESOURCES 是此资源所依赖的资源名称的顺序列表,各名称之间用空格分隔。如果所需的资源不可用,则 Oracle Clusterware 会重新定位或停止应用程序。因此,在上一张幻灯片的示例中,可以看到要启动 JFDB1 实例,必须先启动 ASM 实例 ASM1。
  • RESTART_ATTEMPTS 是 Oracle Clusterware 在尝试重新定位单个集群节点上的资源之前尝试重新启动该资源的次数。超过 UPTIME_THRESHOLD 设置所指示的时段后,Oracle Clusterware 会将重新启动计数器的值 (RESTART_COUNTS) 重置为 0。一般来说,RESTART_COUNTS 在 UPTIME_THRESHOLD 时段内不能超过 RESTART_ATTEMPTS。

crs_stat –t resource_name 命令将显示已命名的资源的状态。在本幻灯片中,资源的 Target 状态为 ONLINE,这表示在节点下次重新启动时,Oracle Clusterware 将尝试启动该实例。State 显示该实例的当前状态。

注:由于格式方面的原因,本幻灯片中显示的输出被截断。

 

主要的表决磁盘voting  disk 功能

 

CSS 是一种服务,用于确定集群中哪些节点可用,并向其它进程提供集群组成员资格和简单锁定服务。CSS 通常通过专用网络与用作辅助通信机制的表决磁盘进行通信,从而确定节点的可用性。一般来说,此操作是通过网络和表决磁盘发送脉动消息来完成的,如位于本幻灯片顶部的图形所示。表决磁盘是集群文件系统上的共享裸磁盘分区或文件,集群中的所有节点都可以访问该磁盘。表决磁盘的主要用途是在专用网络通信失败的情况下提供帮助。如果发生这种情况,集群无法将所有节点都保持为可用状态,因为这些节点无法再使 I/O 与共享磁盘同步。因此,必须使其中某些节点脱机。这时,将使用表决磁盘传送节点状态信息,用于确定哪些节点脱机。如果不使用表决磁盘,则孤立的节点将无法确定是否遇到了网络故障或者其它节点是否不再可用。因此,集群就会进入以下状态:即节点的多个子集群无法同步访问相同的数据库文件。这种情况通常称为集群裂脑 (split-brain) 问题。

位于本幻灯片底部的图形说明了当节点 3 无法再向集群中的其它成员发送脉动时所发生的情况。如果其它节点无法再看到节点 3 的脉动,它们就会决定使用表决磁盘逐出该节点。当节点 3 读到删除消息时,通常会自行重新启动以确定所有未处理的写入 I/O 都已丢失。

 

注:除了表决磁盘机制以外,系统还为 RAC 数据库实例提供了一种类似的机制。在实例级别,所有参与实例均使用控制文件进行表决。此操作很有必要,因为即使节点之间的网络连接仍能正常工作,也会出现逐出实例的情况。

例如,如果 LMON 或 LMD 在一个实例上出现停滞,则可能会导致集群数据库被冻结。因此,为了避免整个集群被挂起,RAC 会从集群中逐出有问题的实例。

如果检测到问题,实例会竞相获得控制文件上的锁定。获得锁定的实例会记录实例的表决以确定成员资格。这称为实例成员资格重新配置 (IMR)。

 

重要的 CSS 参数

  • MISSCOUNT:

表示网络脉动超时

确定重新配置期间磁盘 I/O 超时

默认值为 30 秒

不能进行更改

  • DISKTIMEOUT:

表示重新配置以外的磁盘 I/O 超时

默认值为 200 秒

当表决磁盘遇到很长时间的 I/O 延迟时可临时进行更改:

  1. 关闭除一个节点之外的所有节点上的 Oracle Clusterware
  2. 在可用节点上以 root 用户身份使用以下命令:crsctl set css disktimeout M+1
  3. 重新启动可用节点。
  4. 重新启动所有其它节点。
  • 只有在 Oracle 技术支持明确指导下才能进行更改

 

CSS misscount 参数表示在输入集群重新配置以逐出节点之前,互连上的网络脉动可缺失的最长时间(以秒为单位)。misscount 参数的默认值为 30 秒。misscount 参数的值会推进集群成员资格的重新配置,并直接影响集群的可用性。其默认设置应为可接受的值。修改该值不仅会影响表决磁盘 I/O 的超时间隔,而且还会影响互连上缺失网络脉动的容限。这会直接影响数据库和集群可用性。使用供应商(非 Oracle)集群件时,CSS misscount 的默认值也为 30 秒。如果使用供应商集群件,则不应更改默认 misscount 值。

CSS disktimeout 参数表示在为了逐出节点而输入集群重新配置之前,磁盘脉动可缺失(集群重新配置事件以外)的最长时间(以秒为单位)。默认值为 200 秒。不过,如果表决磁盘的 I/O 延迟大于默认的内部 I/O 超时,则集群可能会遇到 CSS 节点被逐出的情况。导致这些延迟的最常见原因与多路径 I/O 软件驱动程序,以及因 I/O 路径故障而产生的重新配置次数有关。因此,在解决基础存储 I/O 延迟之前,可以仅根据“表决磁盘的最大 I/O 延迟”(因 I/O 路径重新配置而产生的延迟加上一秒,即 M+1)临时修改 disktimeout。

 

多路复用表决投票voting disk 磁盘

  • 表决磁盘是提供集群可用性的重要资源。
  • 如果表决磁盘存储在可靠磁盘中,则使用一个表决磁盘即可。
  • 对于其它情况,应使用多路复用表决磁盘:

不必依赖多路径解决方案。

多路复用副本应存储在独立的设备中。

确保表决磁盘设备具有足够的 I/O。

至少使用三个多路复用副本。

  • CSS 使用简单的多数决定规则来确定表决磁盘读数是否一致:

v = f*2+1

通过用多个表决磁盘来配置 CSS,可提高 CSS 的可用性。如果集群被配置为使用单个高可用性共享磁盘(数据库文件和 CSS 表决磁盘都位于该磁盘上),则只需一个表决磁盘就足够了。但如果使用可靠性较差的存储,则最好使用多个表决磁盘副本。此外,也可以使用多个表决磁盘,这样就无需依赖多路径解决方案。

实施表决磁盘多路复用的方法要求您必须至少具有三个表决磁盘。为避免单点故障,
多路复用表决磁盘应位于物理上独立且在低于饱和度的情况下具有良好可预测负荷的
存储设备中。

使用表决磁盘的多路复用副本时,CSS 会将表决数据多路复用到所有表决磁盘。每当 CSS 需要读取表决磁盘时,就会从所有表决磁盘中读取全部信息。如果确实有一半以上的表决磁盘处于正常运行状态并且包含一致的信息,则 CSS 可以使用与单个表决磁盘配置相同的方式来使用这些一致数据。如果不到一半的表决磁盘包含一致的可读数据,则 CSS 需要自行终止,这与 CSS 无法读取单个表决磁盘的情况相似。该自行终止旨在防止出现分离的子集群。最多可以有 32 个表决磁盘,请使用以下公式确定应使用的表决磁盘数:
v = f*2+1,其中 v 是表决磁盘数,f 是要恢复的磁盘故障数。

注:典型的表决磁盘配置包含 3 到 5 个磁盘。

 

更改表决磁盘配置

  • 可以动态更改表决磁盘配置。
  • 要添加新的表决磁盘,请使用以下命令:

# crsctl add css votedisk <新表决磁盘路径>

  • 要删除表决磁盘,请使用以下命令:

# crsctl delete css votedisk <旧表决磁盘路径>

  • 如果所有节点上的 Oracle Clusterware 都已关闭,请使用 force 选项:

# crsctl add css votedisk <新表决磁盘路径> force

# crsctl delete css votedisk <旧表决磁盘路径> force

 

在安装 Oracle Clusterware 期间,可以通过使用 Oracle Universal Installer 的“Specify Voting Disk Location(指定表决磁盘位置)”屏幕多路复用表决磁盘。通过此屏幕可以指定三个表决磁盘位置。不过,可以在安装 Oracle Clusterware 后,使用下列命令,以 root 用户身份动态添加和删除表决磁盘。

  • 要添加表决磁盘,请使用以下命令:crsctl add css votedisk path
  • 要删除表决磁盘,请使用以下命令:crsctl delete css votedisk path

其中 path 是全限定路径。

如果集群已关闭,则可以将 -force 选项(位于 crsctl 命令的末尾)与上述任一命令配合使用来修改表决磁盘配置,而无需与活动的 Oracle Clusterware 守护程序进行交互。但是,在任何集群节点处于活动状态时使用 -force 选项都可能会破坏配置。

 

备份和恢复表决磁盘

 

  • 应该不需要执行此操作,相反,应执行添加/删除操作。
  • 建议使用符号链接。
  • 使用 dd 命令备份一个表决磁盘。

在安装 Oracle Clusterware 之后

在添加或删除节点之后

不能联机执行

 

$ crsctl query css votedisk

 

$ dd if=<表决磁盘路径> of=<备份路径> bs=4k

 

  • 可以使用以下方法恢复表决磁盘:使用 dd 命令恢复第一个表决磁盘,然后根据需要对该磁盘进行多路复用。
  • 如果没有可用的表决磁盘备份,则应重新安装 Oracle Clusterware

应该不需要备份表决磁盘。只需添加一个新的表决磁盘和删除一个错误的表决磁盘即可。

建议使用符号链接指定表决磁盘路径。这是因为表决磁盘路径直接存储在 OCR 中,而系统不支持直接编辑 OCR 文件。通过使用指向表决磁盘的符号链接,可以在表决磁盘的原始位置无法再用作还原位置时更轻松地还原表决磁盘。

只要添加了新节点或删除了现有节点,就应对可用表决磁盘创建新的备份。建议使用 dd 命令(在 Windows 环境中为 ocopy)执行此操作。作为适用于大多数平台(包括 Linux 和 Sun)的通用规则,用于 dd 命令的块大小至少应为 4 KB,这样可以确保表决磁盘备份获得完整的块。

使用 dd 命令备份表决磁盘之前,请务必停止所有节点上的 Oracle Clusterware。

crsctl query css votedisk 命令可列出 CSS 当前所使用的表决磁盘。这有助于确定要备份的表决磁盘。

本幻灯片显示了备份和还原表决磁盘时可以遵循的过程。

注:如果所有表决磁盘都已丢失,并且没有任何备份,则必须重新安装 Oracle Clusterware。

 

OCR 体系结构

 

集群配置信息在 Oracle 集群注册表 (OCR) 中进行维护。OCR 依赖分布式共享高速缓存体系结构来优化查询,并对集群资料档案库执行集群范围的原子更新。集群中的每个节点都维护一个 OCR 内存中副本,以及访问其 OCR 高速缓存的集群就绪服务守护程序 (CRSD)。实际上,只有其中一个 CRS 进程对共享存储上的 OCR 文件执行读取和写入操作。该进程负责刷新自己本地的高速缓存,此外还会刷新集群中其它节点上的 OCR 高速缓存。对于集群资料档案库查询,OCR 客户机将直接与其来源节点上的本地 OCR 进程进行通信。客户机需要更新 OCR 时,会通过其本地 CRS 进程与正在执行输入/输出 (I/O) 的 CRS 进程进行通信,以便将更新后的 OCR 写入到磁盘上的资料档案库中。

主要的 OCR 客户机应用程序包括:Oracle Universal Installer (OUI)、SRVCTL、Oracle Enterprise Manager (EM)、Database Configuration Assistant (DBCA)、Database Upgrade Assistant (DBUA)、NetCA 和 Virtual Internet Protocol Configuration Assistant (VIPCA)。此外,OCR 还维护在 Oracle Clusterware 中定义的应用程序资源(具体指数据库、实例、服务和节点应用程序)的相关性和状态信息。

 

Oracle Clusterware 安装过程为您提供了自动镜像 OCR 的选项。使用此选项可创建另一个 OCR 文件(OCR 镜像文件),以复制原始 OCR 文件(OCR 主文件)。可以将 OCR 镜像文件放在集群文件系统上,也可以将其放在共享裸设备上。建议在安装期间对 OCR 进行镜像,但并不强制这么做。

在基于 UNIX 的系统上,OCR 配置文件的名称为 ocr.loc,OCR 文件的位置变量为 ocrconfig_loc 和 ocrmirrorconfig_loc。

如果基础存储不是 RAID,则强烈建议使用 OCR 镜像文件。这可防止 OCR 成为单点故障。

注:OCR 还可用作 ASM 单一实例中的配置文件,在该实例中,每个节点对应一个 OCR。

 

OCR 内容和组织结构

 

每种集群技术都需要有一个资料档案库,集群软件和其它识别集群的应用程序进程可以通过该资料档案库共享信息。Oracle Clusterware 使用 Oracle 集群注册表存储与它所管理的资源相关的信息。这些信息存储在一个使用键值对的树状结构中。

本幻灯片显示了构成 OCR 结构的主要分支:

  • SYSTEM 键,包含与 Oracle Clusterware 主要进程(如 CSSD、CRSD 和 EVMD)相关的数据。例如,CSSD 键包含有关 misscount 参数和表决磁盘路径的信息。
  • DATABASE 键,包含与在 Oracle Clusterware 中注册的 RAC 数据库相关的数据。如本幻灯片所示,您具有与实例、nodeapps、服务等有关的信息。
  • 可在 OCR 中找到的最后一类键与资源概要文件相关,Oracle Clusterware 将使用这些文件来维护其它已注册的应用程序的可用性。这些资源将包含其它应用程序 VIP、监视脚本和检查间隔值。

注:位于本幻灯片右侧的 XML 数据是使用 ocrdump –xml 命令获取的。

 

管理 OCR 文件及位置:概览

 

使用 ocrconfig 工具(Oracle 集群注册表的主要配置工具)可以执行以下操作:

  • 使用 –export 选项生成 OCR 的逻辑备份,以后又使用 –import 选项从这些备份还原 OCR 信息
  • 升级或降级 OCR
  • 使用 –showbackup 选项查看生成的备份(默认情况下,定期备份 OCR)。在默认位置(可使用 –backuploc 选项更改该位置)生成这些备份。如果需要,可在以后使用 –restore 选项还原 OCR 的物理副本。也可使用 -manualbackup 选项手动创建 OCR 备份。
  • 使用 –replace ocr 或 –replace ocrmirror 选项添加、删除或替换 OCR 主文件或 OCR 镜像文件。
  • 在支持服务的指导下使用 –overwrite 选项,通过该选项,可以在集群中的一个或多个节点因 OCR 损坏而无法启动时改写某些 OCR 保护机制。
  • 使用 –repair 选项更改列出 OCR 和 OCR 镜像位置的参数。

使用 ocrcheck 工具可以验证 OCR 及其镜像的 OCR 完整性。使用 ocrdump 实用程序可以将 OCR 内容(或其中一部分内容)写入文本文件或 XML 文件。

 

自动备份 OCR

 

  • OCR 内容对于 Oracle Clusterware 至关重要。
  • 实际上,OCR 会在以下时间自动进行备份:

每 4 小时:CRS 会保留最后 3 个副本。

每天结束时:CRS 会保留最后 2 个副本。

每周结束时:CRS 会保留最后 2 个副本。

 

$ cd $ORACLE_BASE/Crs/cdata/jfv_clus

$ lslt

rw-r–r– 1 root root 4784128 Jan  9 02:54 backup00.ocr

rw-r–r– 1 root root 4784128 Jan  9 02:54 day_.ocr

rw-r–r– 1 root root 4784128 Jan  8 22:54 backup01.ocr

rw-r–r– 1 root root 4784128 Jan  8 18:54 backup02.ocr

rw-r–r– 1 root root 4784128 Jan  8 02:54 day.ocr

rw-r–r– 1 root root 4784128 Jan  6 02:54 week_.ocr

rw-r–r– 1 root root 4005888 Dec 30 14:54 week.ocr


  • 更改自动备份的默认位置:

  # ocrconfigbackuploc /shared/bak

 

OCR 包含 RAC 和 Oracle Clusterware 的重要集群和数据库配置信息。集群中的一个 Oracle Clusterware 实例(CRSD 主实例)每 4 小时就会自动创建一次 OCR 备份,CRS 会保留最后 3 个副本。此外,该 CRSD 进程还会在每天和每周开始时创建 OCR 备份,并保留最后 2 个副本。本幻灯片对此进行了说明,可在其中看到 CRSD 主实例的默认备份目录的内容。

虽然无法定制备份频率或保留的副本数,但可以使用 ocrconfig -showbackup 命令标识自动保留的副本的名称和位置。

每个自动生成的 OCR 备份文件的默认目标位置均为
<CRS 主目录>/cdata/<集群名称> 目录。建议使用
ocrconfig -backuploc <新位置> 命令将此位置更改为由集群中所有节点共享的位置。此命令将采用一个参数,即新位置的完整路径目录名。

 

手动备份 OCR 

 

  • 每天都应在其它存储设备上备份 OCR 自动备份:

使用首选备份工具。

  • 按需执行物理备份:

# ocrconfigmanualbackup

  • 在进行重大更改之前和之后应对 OCR 进行逻辑备份:

# ocrconfig –export file name

  • 确保还原与当前系统配置相匹配的 OCR 备份。

由于 OCR 信息非常重要,因此还建议手动为自动生成的物理备份创建副本。可以使用任意备份软件来复制自动生成的备份文件。建议至少每天执行一次将这些文件备份到其它设备(不同于 OCR 主文件所在的设备)的操作。

可根据需要使用 –manualbackup 选项执行 OCR 备份。备份将在 -backuploc 选项指定的位置中生成。

此外,还应在进行重大配置更改(如在环境中添加或删除节点、修改 Oracle Clusterware 资源或创建数据库)之前和之后,导出 OCR 内容。请以 root 用户身份使用 ocrconfig -export 命令生成 OCR 逻辑备份。需要指定一个文件名作为该命令的参数,该命令会生成一个二进制文件,您将无法编辑该文件。

所做的大多数配置更改不仅会更改 OCR 内容,而且还会创建文件和数据库对象。还原 OCR 时,其中某些更改通常不会得到还原。如果其中某些配置更改失败,则不要将执行 OCR 还原作为恢复到先前配置的更正方法,因为这可能导致 OCR 的内容与系统其余部分的状态不相符。

注:如果尝试在 OCR 客户机运行过程中导出 OCR,则会发生错误。

 

使用物理备份恢复 OCR

1.找到物理备份:

$ ocrconfigshowbackup

2.检查其内容:

# ocrdumpbackupfile file_name

3.停止所有节点上的
Oracle Clusterware

# crsctl stop crs

 

4.还原 OCR 物理备份:

# ocrconfig –restore <CRS 主目录>/cdata/jfv_clus/day.ocr  

5.重新启动所有节点上的
Oracle Clusterware

# crsctl start crs

 

6.检查 OCR 完整性:

$ cluvfy comp ocr -n all

在基于 UNIX 的系统上,使用以下过程还原 OCR:

  1. 使用 ocrconfig -showbackup 命令标识 OCR 备份。可以作为 oracle 用户从任何节点执行此命令。输出会显示要在其中检索自动和手动生成的备份的节点和路径。使用 auto 或 manual 参数只显示一个类别。
  2. 使用 ocrdump -backupfile file_name 检查备份内容,其中 file_name 是备份文件的名称。
  3. 通过以 root 用户身份在所有节点上执行
    crsctl stop crs 命令,停止集群中所有节点上的 Oracle Clusterware。
  4. 通过以 root 用户身份使用以下命令应用步骤 1 中标识的 OCR 备份文件来执行还原,其中 file_name 是要还原的 OCR 文件的名称。在运行此命令之前,请确保 OCR
    配置文件 (/etc/oracle/ocr.loc) 中指定的 OCR 设备存在并且有效:ocrconfig -restore file_name
  5. 通过以 root 用户身份重新启动每个节点或运行 crsctl start crs 命令,重新启动集群中所有节点上的 Oracle Clusterware。
  1. 运行以下命令以验证 OCR 完整性,其中 -n all 参数将检索配置为集群一部分的所有集群节点的列表:
    cluvfy comp ocr -n all

使用逻辑备份恢复 OCR

1.找到使用 OCR 导出文件创建的逻辑备份。

2.停止所有节点上的 Oracle Clusterware

# crsctl stop crs

3.还原逻辑 OCR 备份:

# ocrconfig –import /shared/export/ocrback.dmp  

4.重新启动所有节点上的 Oracle Clusterware

# crsctl start crs

5.检查 OCR 完整性:

$ cluvfy comp ocr -n all

 

在基于 UNIX 的系统上,可使用以下过程导入 OCR:

  1. 通过标识先前使用 ocrconfig -export file_name 命令创建的 OCR 导出文件,标识要导入的 OCR 导出文件。
  2. 通过以 root 用户身份在所有节点上执行
    crsctl stop crs 命令,停止 RAC 数据库中所有节点上的 Oracle Clusterware。
  3. 通过使用以下命令应用步骤 1 中标识的 OCR 导出文件来执行导入操作,其中 file_name 是要从中导入 OCR 信息的 OCR 文件的名称:ocrconfig -import file_name
  4. 通过以 root 用户身份运行 crsctl start crs 命令重新启动每个节点,重新启动集群中所有节点上的 Oracle Clusterware。
  5. 运行以下集群验证实用程序 (CVU) 命令来验证 OCR 完整性,其中 -n all 参数将检索配置为集群一部分的所有集群节点的列表:cluvfy comp ocr -n all

 

替换 OCR 镜像:示例

 

 

# ocrcheck
Status of Oracle Cluster Registry is as follows:
   Version                  :          2
   Total space (kbytes)     :     200692
   Used space (kbytes)      :       3752
   Available space (kbytes) :     196940
   ID                       :  495185602
   Device/File Name         : /oradata/OCR1
    Device/File integrity check succeeded
   Device/File Name         : /oradata/OCR2
    Device/File needs to be synchronized with the other device

# ocrconfig –replace ocrmirror /oradata/OCR2

本幻灯片中的代码示例显示了如何替换现有 OCR 镜像文件。该示例假设您已具有了一个 OCR 镜像,但此镜像无法再按预期方式进行工作。触发此类重组的原因可能为:在 Enterprise Manager 中收到 OCR 故障预警,或直接在 Oracle Clusterware 预警日志文件中看到预警。

通过使用 ocrcheck 命令,可以清楚地看到 OCR 镜像不再与 OCR 主文件保持同步。然后,可以发出 ocrconfig –replace ocrmirror filename 命令将现有镜像替换为 OCR 主文件的副本。在该示例中,如果还决定重新定位 OCR 镜像文件,则 filename 可以是一个新文件名。

如果是 OCR 主文件发生故障,而 OCR 镜像仍可以正常工作,则可以改用 ocrconfig –replace ocr filename 命令。

注:本幻灯片中的示例显示了一个替换方案。但也可以使用类似的命令来添加或删除 OCR 主文件或镜像文件:

  • 通过执行 ocrconfig –replace ocr|ocrmirror filename,将 OCR 主文件或镜像文件添加到环境中(如果该文件尚未存在)。
  • 通过执行 ocrconfig –replace ocr|ocrmirror,删除 OCR 主文件或镜像文件。

 

修复 OCR 配置:示例

1.停止节点 2 上的 Oracle Clusterware

# crsctl stop crs

2.从节点 1 添加 OCR 镜像:

# ocrconfig –replace ocrmirror /OCRMirror

3.修复节点 2 上的 OCR 镜像位置:

# ocrconfig –repair ocrmirror /OCRMirror

 

4.启动节点 2 上的 Oracle Clusterware

# crsctl start crs

 

应使用 ocrconfig –repair 命令修复不一致的 OCR 配置信息。OCR 配置信息将存储在以下位置:

  • Linux 和 AIX 上的 /etc/oracle/ocr.loc 中
  • Solaris 和 HP-UX 上的 /var/opt/oracle/ocr.loc 中
  • Windows 上的注册表项 HKEY_LOCAL_MACHINE\SOFTWARE\Oracle\ocr 中

如果在某个特定节点处于停止状态时 OCR 配置发生了更改,则可能需要修复该节点上的 OCR 配置。例如,如果在添加、替换或删除 OCR 期间某个节点未处于运行状态,则可能需要修复该节点上的 OCR。

本幻灯片中的示例说明了当集群中的第二个节点未运行 Oracle Clusterware 时,将 OCR 镜像文件添加到第一个节点的情况。

不能对正在运行 Oracle Clusterware 的节点执行此操作。

注:此操作只修复 OCR 配置信息,不会修复 OCR 自身。

 

OCR 注意事项

  • 如果使用裸设备还原 OCR 文件,则在执行添加或替换操作之前需要先确保这些文件已存在。
  • 使用 ocrconfig 时,必须使用 root 用户身份才能添加、替换或删除 OCR 文件。
  • 添加或替换 OCR 文件时,其镜像需要处于联机状态。
  • 如果删除了 OCR 主文件,则 OCR 镜像文件将成为
    主文件。
  • 任何时候都不能删除最后一个保留的 OCR 文件。

下面列出了使用 ocrconfig –replace 命令时的重要注意事项:

  • 如果使用裸设备,则在使用 ocrconfig 发出添加或替换操作之前,应确保文件名已存在。
  • 要使用 ocrconfig 执行添加、替换或删除操作,必须以 root 用户身份登录。
  • 要替换的 OCR 文件既可以处于联机状态,也可以处于脱机状态。
  • 如果删除了 OCR 主文件,则 OCR 镜像文件将成为 OCR 主文件。
  • 除非至少有另外一个活动 OCR 文件处于联机状态,否则不要执行 OCR 删除操作。

 

 

更改 VIP 地址

1.确定用于支持 VIP 的接口:

$ ifconfig -a

2.停止依赖 VIP 的所有资源:

$ srvctl stop instance -d DB –i DB1

$ srvctl stop asm -n node1

# srvctl stop nodeapps -n node1

 

3.验证 VIP 不再处于运行状态:

$ ifconfig -a

$ crs_stat

4.更改 /etc/hosts 中的 IP DNS。

 

 

VIP 地址是静态 IP 地址,包含一个通过 DNS 或主机文件定义和解析的虚拟主机名。在安装 Oracle Clusterware 期间,系统会提示您为集群中的每个节点输入一个虚拟 IP 地址和虚拟主机名。这些 VIP 将存储在 OCR 中,Oracle Clusterware HA 框架中的各种组件都依赖这些 VIP。如果出于某些原因需要更改 VIP 地址,应对每个节点执行以下过程(一次执行一个过程):

  1. 通过运行 ifconfig –a 命令,确认 VIP 的当前 IP 地址。在 Windows 上,运行 ipconfig /all 命令。此操作将显示绑定到其中一个网络接口的当前 VIP。
  2. 停止依赖于该节点上 VIP 的所有资源:首先停止数据库实例,然后停止 ASM 实例。完成后,停止 nodeapps。
  3. 通过再次执行 ifconfig -a 命令,验证 VIP 不再处于运行状态,并确认输出中不再列出其接口。如果接口仍显示为联机,则表示依赖该 VIP 的某个资源仍在运行。使用 crs_stat -t 命令有助于显示仍处于联机状态的资源。
  4. 对所有节点的 /etc/hosts 文件(在 UNIX 上)或 \WINNT\System32\drivers\etc\hosts 文件(在 Windows 上)进行任何必要的更改,然后对 DNS 进行必要的更改,从而使新 IP 地址与旧主机名相关联。

 

更改 VIP 地址

5.使用 srvctl 修改 VIP 地址:

# srvctl modify nodeapps -n node1 -A 192.168.2.125/255.255.255.0/eth0  

6.启动 nodeapps 及依赖它的所有资源:

# srvctl start nodeapps -n node1

7.对下一节点重复执行从步骤 1 开始的步骤。

  1. 修改 nodeapps 并提供新的虚拟 IP 地址。使用带有 –A 选项的 srvctl modify nodeapps 命令。应以 root 用户身份运行此命令。在本幻灯片的示例中,依次指定了新 IP 地址 (192.168.2.125)、相应的网络掩码 (255.255.255.0) 以及希望 VIP 使用的接口 (eth0)。
  2. 重新启动 nodeapps。
  3. 对集群中的所有节点重复上述步骤。由于 srvctl 是集群范围的管理工具,因此可以与第一个节点保持连接。

注:如果只更改了 IP 地址,并且 listener.ora、tnsnames.ora 和初始化参数文件使用的是虚拟主机名,则无需对这些文件进行更改。如果同时更改了节点的虚拟主机名和 VIP 地址,则需要用新的虚拟主机名修改这些文件。对于 listener.ora 文件,可以使用 netca 来删除旧监听程序并创建一个新监听程序。此外,还需要对连接到旧虚拟主机名的所有客户机的 tnsnames.ora 文件进行更改。

 

更改公用/互连 IP 子网配置:示例

可使用 oifcfg 添加或删除 OCR 中的网络接口信息:

$ <CRS 主目录>/bin/oifcfg getif

eth0 139.2.156.0 global public

eth1 192.168.0.0 global cluster_interconnect  

$ oifcfg delif -global eth0

$ oifcfg setif –global eth0/139.2.166.0:public  

$ oifcfg delif –global eth1

$ oifcfg setif –global eth1/192.168.1.0:cluster_interconnect  

$ oifcfg getif

eth0 139.2.166.0 global public

eth1 192.168.1.0 global cluster_interconnect  

 

在安装 Oracle Clusterware 和 RAC 时,在 OUI 交互阶段,您可能会指定与 Oracle Clusterware 将使用的公用和互连接口有关的错误信息。如果发生这种情况,则 Oracle Clusterware 可以在安装过程结束时启动,但以后在与集群中的其它节点进行通信时可能会遇到问题。如果公用网络和互连的接口、IP 子网或 IP 地址不正确或需要进行更改,则应使用 Oracle 接口配置工具 (oifcfg) 进行更改,因为这样可以更新相应的 OCR 信息。

在本幻灯片所显示的示例中,公用网络和专用网络的 IP 子网都不正确:

  1. 使用 getif 选项可以获取当前接口信息。
  2. 先使用 delif 选项删除与公共接口对应的项,然后使用 setif 选项输入正确的信息。
  3. 对专用互连执行相同的操作。
  4. 检查新信息是否正确。

注:可以将网络接口存储为全局接口或节点特定的接口。如果 RAC 集群的所有节点都具有连接到同一子网的同一接口(推荐),则会将接口存储为全局接口。仅当集群中的某些节点具有不同的接口和子网集时,才会将接口存储为节点特定的接口。

 

 

第三方应用程序保护:概览

  • 高可用性框架:

使用命令行工具在 CRS 中注册应用程序

调用控制应用程序代理以管理应用程序

使用 OCR 描述应用程序的 CRS 属性

  • 高可用性 C API:

直接修改 OCR 中的 CRS 属性

空闲时修改 CRS 属性

  • 应用程序 VIP:

用于通过网络方式进行访问的应用程序

NIC 冗余

NIC 故障转移

  • OCFS:

存储应用程序配置文件

在集群节点之间共享文件

 

Oracle Clusterware 提供了两种可用的公共组件,可用于帮助保护集群上的任何应用程序:

  • 高可用性框架提供了通过命令行工具(如 crs_register、crs_start 和 crs_stop)管理受 CRS 保护的应用程序的工具。此框架还可用于自动调用已创建的控制脚本,以便 CRS 可以启动、停止和监视应用程序。可以将 OCR 用作资料档案库来定义故障转移策略和其它重要参数,以便 CRS 能够控制应用程序。
  • 可以使用 C API 直接操纵 OCR,以定义 CRS 保护应用程序的方式。可以在运行时使用此 API 修改 CRS 管理应用程序的方式。有关 C API 的内容不在本课程讨论范围内。

如果通过网络方式访问希望得到 CRS 保护的应用程序,则可以为应用程序创建虚拟 Internet 协议地址。这称为应用程序 VIP。Oracle Clusterware 所创建的应用程序 VIP 可以从一个网卡 (NIC) 故障转移到同一节点上的另一个网卡,并且可以在给定节点上的所有公用网络都关闭的情况下,从一个 NIC 故障转移到另一个节点上的 NIC。

此外,应用程序可能需要将配置文件存储在磁盘上。为了能在节点之间共享这些文件,Oracle Corporation 还提供了 Oracle 集群文件系统 (OCFS)。

 

应用程序 VIP RAC VIP 之间的差异

  • RAC VIP 主要用于发生节点关闭事件的情况中:

VIP 将被故障转移到正常节点。

VIP 会从该节点将 NAK 返回到客户机,从而强制客户机重新进行连接。

无需对与 VIP 关联的资源进行故障转移。

  • 应用程序 VIP 主要用于发生应用程序关闭事件的情况中:

VIP 将与应用程序一起被故障转移到其它节点。

从该节点中,客户机仍可通过 VIP 进行连接。

可使用一个 VIP 为多个应用程序提供服务,但不建议这样做。

 

附加到应用程序 VIP 的资源和 RAC VIP 驻留资源之间的主要区别是它们在 Oracle Clusterware 中的配置方式不同。例如,从 RAC 的角度来说,对数据库实例或监听程序进行故障转移没有任何意义,因为在另一个节点上已经有一个处于等待状态的监听程序和实例。因此,该监听程序不会在一个节点特定的 VIP 之外的任何其它 VIP 上进行监听。查看这些资源的 CRS 概要文件时,可以看到这些差异。此外,在多数情况下,有许多应用程序被附加到 RAC VIP,如监听程序、数据库实例和 ASM 实例等。虽然可以将一个应用程序 VIP 与多个应用程序关联,但并不建议这样做,因为如果其中一个应用程序在某一节点上无法启动或重新启动,它就会通过 VIP 故障转移到另一个节点,而该节点又会强制其它应用程序也重新定位。当应用程序是独立应用程序时尤其如此。但是,RAC VIP 与应用程序 VIP 之间存在一个显著差异,即在 RAC VIP 故障转移到正常节点后,将不再接受连接 (NAK),因此会强迫尝试访问该地址的客户机使用其它地址重新进行连接。如果接受新连接,并发生故障恢复,则在发生故障转移的节点恢复后,该节点上经由 VIP 的当前连接会因为没有接口而断开。而另一方面,应用程序 VIP 在进行故障转移后将完全恢复正常,并继续接受连接。

如果节点出现故障,则主要使用 RAC VIP,因为客户机可使用其它节点进行连接。如果应用程序无法在节点上重新启动,则主要使用应用程序 VIP。

 

使用 CRS 框架:概览 

1.根据需要创建应用程序 VIP:

a.创建概要文件:网络数据 + usrvip 预定义的脚本

b.注册应用程序 VIP。

c.设置对应用程序 VIP 的用户权限。

d.通过使用 crs_start 启动应用程序 VIP。

2.编写接受以下三个参数的应用程序操作脚本:

  • start脚本将启动应用程序。
  • check脚本将确认应用程序是否处于正常运行状态。
  • stop脚本将停止应用程序。

本幻灯片演示了注册受 CRS 框架监视的应用程序所需的基本步骤:

  1. 如果通过网络访问应用程序,并且在出现某些网络问题后仍希望应用程序可用,则建议为应用程序创建一个应用程序 VIP。
  2. 首先,应创建一个应用程序概要文件来定义与此 VIP 关联的网络信息。例如,要使用的公用网络适配器名称、IP 地址和网络掩码。在该概要文件中,还应指定 Oracle Clusterware 所提供的 usrvip 操作脚本。然后便可以使用故障转移策略的默认值。
  3. 使用 crs_register 命令将此应用程序 VIP 添加到所管理的应用程序列表中。
  4. 在基于 UNIX 的操作系统上,必须以 root 用户身份运行应用程序 VIP 脚本。因此,可以使用 crs_setperm 将 VIP 的所有者更改为 root。使用同一命令工具,还可以允许其他用户(如 oracle)启动应用程序 VIP。
  5. 完成后,可以使用 crs_start 命令启动 VIP 应用程序。
  6. 现在,您可以创建一个操作脚本,以支持对应用程序执行启动、检查和停止操作。

 

使用 CRS 框架:概览

3.创建应用程序概要文件:

  • 操作脚本位置
  • 检查间隔
  • 故障转移策略
  • 应用程序 VIP(如果需要)

4.设置对应用程序的权限。

5.Oracle Clusterware 中注册概要文件。

6.通过使用 crs_start 启动应用程序。

 

  1. 为应用程序创建概要文件。应使用足够的资源属性至少定义操作脚本的位置和名称、检查间隔、故障转移策略及所需的应用程序 VIP 资源(如果需要)。可以按如下所示方式管理应用程序的可用性:

-指定在启动集群或节点时启动资源。

-重新启动失败的应用程序。

-如果应用程序无法在其当前位置运行,则应将其重新定位到其它节点。

  1. 与对 VIP 应用程序使用的操作相似,可以定义以何种用户身份运行应用程序以及哪些用户可以启动应用程序。因此,在基于 UNIX 的平台上,Oracle Clusterware 必须以 root 用户身份运行;而在基于 Windows 的平台上,Oracle Clusterware 必须以 Administrator 用户身份运行。
  2. 完成后,就可以通过使用 crs_register 命令来注册应用程序。
  3. 现在,您可以启动要由 Oracle Clusterware 监视的应用程序了。请通过执行 crs_start 命令来执行此操作。

 

 

使用 CRS 框架:示例

 

# crs_profile –create AppVIP1 –t application \

–a <CRS 主目录>/bin/usrvip \
–o oi=eth0,ov=144.25.214.49,on=255.255.252.0

# crs_register AppVIP1

# crs_setperm AppVIP1 –o root

# crs_setperm AppVIP1 –u user:oracle:r-x

$ crs_start AppVIP1

 

紧接着前面的概览幻灯片,此处提供了一个使用 Oracle Clusterware 保护 apache 应用程序的示例:

  1. 通过使用 crs_profile –create 命令创建 AppVP1 应用程序 VIP 概要文件。下面按顺序列出了该示例中指定的参数:

-应用程序 VIP 的名称

-应用程序类型

-位于 <CRS 主目录>/bin 中预定义的操作脚本 usrvip

-公用网络适配器的名称、用于定位应用程序的 VIP 地址(与应用程序在其中运行的节点无关)及用于 VIP 的网络掩码

此命令的结果是在 <CRS 主目录>/crs/profile 中创建一个名为 AppVP1.cap 的文本文件。该文件包含属性,并由 crs_register 进行读取。如果没有以 root 用户身份运行会话,则在 <CRS 主目录>/crs/public 中创建 .cap 文件。

  1. 使用 crs_register 命令在 Oracle Clusterware 中注册应用程序 VIP。
  1. 在基于 UNIX 的操作系统上,必须以 root 用户身份运行应用程序 VIP 操作脚本。以 root 用户身份使用 crs_setperm –o 命令更改所示资源的所有者。
  2. 作为 root 用户,使 oracle 用户可以通过 CRS 命令管理应用程序 VIP。使用 crs_setperm –u 命令。
  3. 以 oracle 用户使用 crs_start 命令启动应用程序 VIP。

 

 

使用 CRS 框架:示例

 

#!/bin/sh 
 
VIPADD=144.25.214.49 
HTTDCONFLOC=/etc/httpd/conf/httpd.conf 
WEBCHECK=http://$VIPADD:80/icons/apache_pb.gif 
case $1 in  
'start') 
    /usr/bin/apachectl –k start –f $HTTDCONFLOC 
    RET=$? 
    ;; 
'stop') 
    /usr/bin/apachectl –k stop 
    RET=$? 
    ;; 
'check') 
    /usr/bin/wget –q –delete-after $WEBCHECK 
    RET=$? 
    ;; 
*) 
    RET=0 
    ;; 
esac 
exit $RET 


  1. 应用程序 VIP 正常工作后,可以为应用程序编写操作脚本。Oracle Clusterware 可将本幻灯片中所示的示例用作保护 apache 应用程序的操作脚本。这是一个 shell 脚本,可分析一个具有三个不同值的参数。该脚本可使用 apachectl 命令工具启动和停止节点上的 apache 应用程序。该脚本将使用 wget 命令检查是否可以访问某个网页。它们是 CRS 在保护应用程序时执行的三个操作。

对于后续步骤,假定此脚本名为 myApp1.scr。

注:请务必在集群的所有节点上的同一位置中分配此脚本。在此例中,假定默认位置为 <CRS 主目录>/crs/script。

 

 

使用 CRS 框架:示例

# crs_profile –create myApp1 –t application –r AppVIP1 \

–a myapp1.scr –o ci=5,ra=2

# crs_register myApp1

# crs_setperm myApp1 –o root

# crs_setperm myApp1 –u user:oracle:r-x

$ crs_start myApp1

 

  1. 现在,可以为应用程序创建概要文件了。资源在此处称为 myApp1。该资源将使用 myApp1.scr 作为其操作脚本,并依赖 AppVIP1 应用程序。如果 AppVIP1 失败或者被重新定位到其它节点,则 Oracle Clusterware 将停止或移动 myApp1 应用程序。该示例还将资源的检查间隔定义为 5 秒钟,并将尝试重新启动应用程序的次数定义为 2。这意味着第二次发生本地故障后,Oracle Clusterware 会将应用程序故障转移到其它节点。
  2. crs_register 命令用于在 Oracle Clusterware 中注册 myApp1。
  3. 由于希望 apache 服务器监听默认端口 80,因此需要以 root 用户身份执行应用程序。以 root 用户身份使用 crs_setperm –o 命令更改所示资源的所有者。
  4. 作为 root 用户,使 oracle 用户可以通过 CRS 命令管理应用程序 VIP。使用 crs_setperm –u 命令。
  5. 以 oracle 用户身份使用 crs_start 命令启动 myApp1。

 

 

 

沪ICP备14014813号-2

沪公网安备 31010802001379号