Tag: Oracle11gR2

How to Use Oracle Restart in Oracle 11gR2

8 Comments

Oracle Restart是数据库组件监控方法向单实例数据库中的延展，之前srvctl命令可以用来管理RAC数据库中的各个组件，安装了Oracle Restart之后，对于单实例数据库组件（包括数据库实例，监听，ASM实例，ASM磁盘组，自建Service等）也可以使用srvctl命令来管理，同时Oracle会在这些组件发生意外关闭的时候自动重新启动。对于在Linux单机上安装的Oracle Instance，以前需要配置dbstart或者dbstop脚本来实现在操作系统起停时自动起停数据库实例的操作，现在通过Oracle Restart则无需这两个脚本了。

详细文档请参看 About Oracle Restart。

安装其实很简单，实际上没有单独安装Oracle Restart的过程，只需要安装Oracle Grid Infrastructure就可以，在安装的时候选择“仅安装网格基础结构软件”，我们的测试环境没有使用ASM，因此选择只安装软件可以跳过配置ASM的步骤。

如何在Windows单机上测试ASM，感兴趣的朋友可以参看 – How to use Files in place of Real Disk Devices for ASM。

在安装完GI以后，还需要使用root用户运行以下脚本，否则在$GI_HOME/bin目录中不会生成例如crsctl，crs_start之类的脚本，当然Oracle Restart也不会启动。

# $GRID_HOME/crs/install/roothas.pl

在运行完roothas.pl以后，可以使用crsctl命令来查看HAS(High Availability Services)的运行情况。

$ crsctl status res -t
--------------------------------------------------------------------------------
NAME           TARGET  STATE        SERVER                   STATE_DETAILS       
--------------------------------------------------------------------------------
Local Resources
--------------------------------------------------------------------------------
ora.ons
               OFFLINE OFFLINE      solaris                                      
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.cssd
      1        OFFLINE OFFLINE                                                   
ora.diskmon
      1        OFFLINE OFFLINE                                                   
ora.evmd
      1        ONLINE  ONLINE       solaris

我们是在创建完数据库之后再安装Grid Infrastructure的，因此还需要手工将数据库实例和监听加入Oracle Restart配置中，根据文档如果是在装完Grid Infrastructure之后再用netca创建监听，dbca创建数据库的话，将会自动加入Oracle Restart中，我个人没有测试。

添加数据库实例：

srvctl add database -d orcl -o D:\oracle\product\11.2.0\dbhome_1

检查配置情况：

D:\Temp>srvctl config database -d orcl
数据库唯一名称: orcl
数据库名:
Oracle 主目录: D:\oracle\product\11.2.0\dbhome_1
Oracle 用户: system
Spfile:
域:
启动选项: open
停止选项: immediate
数据库角色: PRIMARY
管理策略: AUTOMATIC
磁盘组:
服务:

检查数据库实例状态：

D:\Temp>srvctl status database -d orcl
数据库正在运行。

注意：如果在添加数据库实例之前数据库实例已经启动了，那么需要重新启动一次数据库，Oracle Restart才能正确监视到数据库实例状态。

添加监听：

srvctl add listener -o D:\oracle\product\11.2.0\dbhome_1

注意，如果是分用户安装（比如在Linux操作系统中），比如GI以grid用户安装，Oracle Database以oracle用户安装，那么在添加监听的时候应该指定GI_HOME，而非ORACLE_HOME。命令如下：

$ srvctl add listener -o /u02/app/oracle/product/11.2.0/grid

否则在用srvctl start listner命令启动监听的时候，会报错。

$ srvctl start listener
PRCR-1079 : Failed to start resource ora.LISTENER.lsnr
CRS-5010: Update of configuration file "/u01/app/oracle/product/11.2.0/db_1/network/admin/listener.ora" failed: details at "(:CLSN00014:)" in "/u02/app/oracle/product/11.2.0/grid/log/solaris/agent/ohasd/oraagent_grid/oraagent_grid.log"
CRS-2674: Start of 'ora.LISTENER.lsnr' on 'solaris' failed

如果在添加监听的时候，监听已经启动，那么会遇到PRCN-2065错误，停止监听以后再次添加即可。

D:\Temp>srvctl add listener -o D:\oracle\product\11.2.0\dbhome_1
PRCN-2061 : 无法添加监听程序 ora.LISTENER.lsnr
PRCN-2065 : 端口 1521 在指定的节点上不可用
PRCN-2035 : 端口 1521 在节点或虚拟主机上不可用: Kamus-PC

配置完毕以后，就可以通过srvctl命令起停数据库实例和监听了。

srvctl start|stop database -d 
srvctl start|stop listener [-l ]

可以通过crs_stat命令查看Oracle Restart管理的各个资源情况，这以前是我们查看Oracle Clusterware的方式。

D:\Temp>crs_stat -t
Name           Type           Target    State     Host
------------------------------------------------------------
ora....ER.lsnr ora....er.type ONLINE    ONLINE    kamus-pc
ora.cssd       ora.cssd.type  ONLINE    ONLINE    kamus-pc
ora.orcl.db    ora....se.type ONLINE    ONLINE    kamus-pc

测试Oracle Restart的功能，我们可以在后台进程中直接杀死oracle.exe，可以观察到数据库实例立刻会重新启动。

注意：所有在SQL*PLUS中发出的关闭数据库命令均不会导致Oracle Restart重启实例，包括shutdown abort。

如果暂时不想用Oracle Restart管理某个资源，可以通过srvctl disable命令暂时禁用，需要的时候再enable即可。

srvctl disable database -d orcl

如果机器名称发生了改变，需要重新配置Oracle Restart，请参考Metalink Note [ID 986740.1]。

Find waiter with Oradebug 11gR2

1 Comment

原文链接自：Miladin Modrakovic’s Blog – Oraclue

实际上，昨天刚有朋友问怎么找到TX enqueu的锁对象以及语句。在Oracle11gR2中我们可以使用oradebug unit_test per_session_find_one_waiter语句来进行简单的blocker定位。

oradebug unit_test per_session_find_one_waiter的用法如下：

usage: 
  oradebug unit_test per_session_find_one_waiter
    find_waiters_for=
    wait_event=""
    waiter_min_secs_blkd=
    min_results=
    [ timeout_mins= ]

实际测试如下，还是测试简单的enq: TX – row lock contention等待事件。

在第1个session中：
[sourcecode language=”sql”]SQL> create table t (n int primary key);

Table created.

SQL> insert into t values(1);

1 row created.

SQL> commit;

Commit complete.

SQL> update t set n=2 where n=1;

1 row updated.[/sourcecode]

在第2个session中：
[sourcecode language=”sql” light=”true”]SQL> update t set n=3 where n=1;[/sourcecode]

在第3个session中：
[sourcecode language=”sql” light=”true”]SQL> update t set n=4 where n=1;[/sourcecode]

在另外一个session中用sysdba登陆，然后执行oradebug。
[sourcecode language=”sql”]SQL> oradebug unit_test per_session_find_one_waiter find_waiters_for=all_local_sess wait_event="enq: TX – row lock contention" waiter_min_secs_blkd=1 min_results=1
WAITERS_FOUND_BEGIN
(inst=1, sid=16, osid=30658) is blocking (inst=1, sid=17) for at least 501 secs
(inst=1, sid=17, osid=30668) is blocking (inst=1, sid=25) for at least 486 secs
WAITERS_FOUND_END[/sourcecode]

从以上的输出中可以得知：
1. sid=16的会话锁住了sid=17的会话，已经有至少501秒
2. sid=17的会话锁住了sid=25的会话，已经有至少486秒

此时如果commit会话1，那么会话2和会话3的”enq: TX – row lock contention” 锁都会消失，但是两个会话都不会更新到任何记录，因为n=1的记录已经被会话1更新为n=2。

在目前的测试中，如果在oradebug中指定的wait_event在当前数据库中并不存在，那么oradebug命令将长时间没有反应，并最终报出ORA-00600的错误，这应该是bug，有望在今后的版本中得到修改。

[sourcecode language=”sql”]SQL> oradebug unit_test per_session_find_one_waiter find_waiters_for=current_sess wait_event="enq: TX – row lock contention" waiter_min_secs_blkd=1 min_results=1

ORA-00600: internal error code, arguments: [ksdhng:waiting_sessions_not_found], [enq: TX – row lock contention], [10], [10], [], [], [], [], [], [], [], [][/sourcecode]

Oracle Database Instance Startup Fails With Error ORA-27302 ORA-27301

Leave a comment

今天启动Oracle Enterprise Linux 5虚拟机中的Oracle11gR2数据库，但是报错。

[oracle@dbserver ~]$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.1.0 Production on Wed Dec 16 13:28:44 2009

Copyright (c) 1982, 2009, Oracle.  All rights reserved.

Connected to an idle instance.

SQL> startup
ORA-27154: post/wait create failed
ORA-27300: OS system dependent operation:semget failed with status: 28
ORA-27301: OS failure message: No space left on device
ORA-27302: failure occurred at: sskgpsemsper

sskgpsemsper函数可以很简单的猜测是跟semaphore有关，而ORA-27301则是No space left on device，那么很容易判断应该是操作系统内核参数中semaphore设置的问题。

[root@dbserver ~]# /sbin/sysctl -a | grep sem
kernel.sem = 250        100     32      128

而实际上，安装Oracle11gR2的semaphore需求是：
semmsl：250
semmns：32000
semopm：100
semmni：128

很明显semmns和semopm都不足。

[root@dbserver ~]# /sbin/sysctl -w kernel.sem="250 32000 100 128"
kernel.sem = 250 32000 100 128
[root@dbserver ~]# /sbin/sysctl -a | grep sem
kernel.sem = 250        32000   100     128
[root@dbserver ~]# echo "kernel.sem = 250 32000 100 128"  >> /etc/sysctl.conf
[root@dbserver ~]#

重新启动数据库实例正常。