今天碰到一个奇怪的小问题，看起来是一个非常简单的问题。
我先说一下问题背景。有一台DB服务器，因为需要搭建备库，现在找了一台已有的机器临时用一下，这台临时的服务器上已经安装了Oracle软件是11.2.0.4.0，而我们需要安装的备库版本是11.2.0.3.0所以为了兼容，所以需要在临时的服务器上再安装一套Oracle软件，把11.2.0.4的ORACLE_HOME切换过来，直接从主库拷贝了安装目录，开始克隆安装。
克隆安装的步骤其实内部就是在做relink，当然这个也没什么问题，很快就操作完成了。
在$ORACLE_HOME/clone/bin下执行下面的命令即可，$ORACLE_HOME,$ORACLE_BASE根据需要配置
perl clone.pl ORACLE_BASE=/DATA/app/oracle ORACLE_HOME=/DATA/app/oracle/product/11.2.3/db_1 ORACLE_HOME_NAME=OraDb11g_home2
简单验证sqlplus -v没有任何问题。
$ sqlplus -v
SQL*Plus: Release 11.2.0.3.0 Production
但是尝试sqlplus / as sysdba的时候却抛出了一个错误。这个问题看起来比较奇怪，记得之前碰到过，但是全然不记得是怎么处理的了。然后重新来过。
$ sqlplus / as sysdba
SQL*Plus: Release 11.2.0.3.0 Production on Thu Dec 31 23:09:19 2015
Copyright (c) 1982, 2011, Oracle. All rights reserved.
ERROR:
ORA-01031: insufficient privileges
这个步骤才开始验证参数文件，密码文件还没有开始做校验，为什么会抛出这个问题呢。但是使用sysoper就看起来没有问题了。
$ sqlplus / as sysoper
SQL*Plus: Release 11.2.0.3.0 Production on Thu Dec 31 23:21:07 2015
Copyright (c) 1982, 2011, Oracle. All rights reserved.
Connected to an idle instance.
对于这个问题，还得从几个小的细节说起，一个就是操作系统认证，对于操作系统认证对于Windows和Linux,Unix都会有一些不同的设置，但是思路都是相通。
在Linux下对应有操作系统的用户组，使得sysdba和操作系统用户组绑定起来。至于哪个是dba组，哪个是oper组，为什么sysoper就可以登录，而sysdba却不可以。这个可以参考一个文件。
为了突显出对比的效果来，我找出了正常运行的主库,config.c的内容如下：
$ORACLE_HOME/rdbms/lib/config.c
$ cat config.c
/* SS_DBA_GRP defines the UNIX group ID for sqldba adminstrative access. */
/* Refer to the Installation and User's Guide for further information. */
/* IMPORTANT: this file needs to be in sync with
rdbms/src/server/osds/config.c, specifically regarding the
number of elements in the ss_dba_grp array.
*/
#define SS_DBA_GRP "oinstall"
#define SS_OPER_GRP "oinstall"
#define SS_ASM_GRP ""
char *ss_dba_grp[] = {SS_DBA_GRP, SS_OPER_GRP, SS_ASM_GRP};
而在备库机器上，config.c的内容如下：
$ cat config.c
/* SS_DBA_GRP defines the UNIX group ID for sqldba adminstrative access. */
/* Refer to the Installation and User's Guide for further information. */
/* IMPORTANT: this file needs to be in sync with
rdbms/src/server/osds/config.c, specifically regarding the
number of elements in the ss_dba_grp array.
*/
#define SS_DBA_GRP "dba"
#define SS_OPER_GRP "oinstall"
#define SS_ASM_GRP ""
char *ss_dba_grp[] = {SS_DBA_GRP, SS_OPER_GRP, SS_ASM_GRP};
由此一来，可以看出为什么sysoper的可以正常登录了。
来简单对比一下主库的用户组情况，发现确实存在一个用户组为dba
[oracle@rolequery product]$ id oracle
uid=500(oracle) gid=500(oinstall) groups=500(oinstall),501(dba),502(oper),503(asmadmin),504(asmdba)
而在备库中只有oinstall的用户组
[oracle@BX_133_45 lib]$ id oracle
uid=501(oracle) gid=501(oinstall) groups=501(oinstall)
那么这个问题怎么修复呢，可以在备库中创建一个对应的用户组，然后把oracle用户加入dba组中，
# groupadd dba
# usermod -a -G dba oracle
# id oracle
uid=501(oracle) gid=501(oinstall) groups=501(oinstall),505(dba)
这个时候最好还是再relink一下，还是使用克隆安装的部分，不过需要在OraInventory中需要手工删除一下原本的安装信息，删除inventory.xml中的Oracle_HOME即可。
但是这个时候还是存在 ORA-01031: insufficient privileges的问题，是修改的用户的问题没有解决彻底吗。
其实还有一个就是sqlnet.authentication的服务认证，MOS( 730067.1)是这么描述的。
sqlnet.authentication_services must be set to (ALL) or to (BEQ, ) for this to work. On Windows this parameter must be set to (NTS).
这个时候再来看一看配置$ cat sqlnet.ora
# sqlnet.ora Network Configuration File: /home/U01/app/oracle/product/11.2.3/db_1/network/admin/sqlnet.ora
# Generated by Oracle configuration tools.
SQLNET.AUTHENTICATION_SERVICES= (NTS)
NAMES.DIRECTORY_PATH= (TNSNAMES, EZCONNECT)
ADR_BASE = /DATA/app/oracle
所以 SQLNET.AUTHENTICATION_SERVICES= (NTS)的设置存在问题的。注释掉之后，再次登录就没有问题了。
[oracle@BX_133_45 admin]$ sqlplus / as sysdba
SQL*Plus: Release 11.2.0.3.0 Production on Thu Dec 31 23:36:31 2015
Copyright (c) 1982, 2011, Oracle. All rights reserved.
Connected to an idle instance.
那么是不是就是因为 SQLNET.AUTHENTICATION_SERVICES直接导致的，用户组不同行不行呢，都已经试到这个份上了，我就继续玩玩。
删除原有的dba组，再次尝试就会看到原有的问题。
# groupdel dba
# id oracle
uid=501(oracle) gid=501(oinstall) groups=501(oinstall)
# su - oracle
$ sqlplus / as sysdba
SQL*Plus: Release 11.2.0.3.0 Production on Thu Dec 31 23:09:19 2015
Copyright (c) 1982, 2011, Oracle. All rights reserved.
ERROR:
ORA-01031: insufficient privileges
我继续想，是不是直接修改config.c就可以了，不需要再创建一个dba组了，行不行？
$ vi config.c
#define SS_DBA_GRP "oinstall"
#define SS_OPER_GRP "oinstall"
#define SS_ASM_GRP ""
然后再次登录，发现还是有问题。所以这两者在我的这个问题里都是缺一不可。
$ sqlplus / as sysdba
SQL*Plus: Release 11.2.0.3.0 Production on Thu Dec 31 23:11:14 2015
Copyright (c) 1982, 2011, Oracle. All rights reserved.
ERROR:
ORA-01031: insufficient privileges
看起来一个很简单的问题，没有很快解决，看起来还是有些尴尬啊，不过知道了原委，发现这些东西还是需要好好理解。
我先说一下问题背景。有一台DB服务器，因为需要搭建备库，现在找了一台已有的机器临时用一下，这台临时的服务器上已经安装了Oracle软件是11.2.0.4.0，而我们需要安装的备库版本是11.2.0.3.0所以为了兼容，所以需要在临时的服务器上再安装一套Oracle软件，把11.2.0.4的ORACLE_HOME切换过来，直接从主库拷贝了安装目录，开始克隆安装。
克隆安装的步骤其实内部就是在做relink，当然这个也没什么问题，很快就操作完成了。
在$ORACLE_HOME/clone/bin下执行下面的命令即可，$ORACLE_HOME,$ORACLE_BASE根据需要配置
perl clone.pl ORACLE_BASE=/DATA/app/oracle ORACLE_HOME=/DATA/app/oracle/product/11.2.3/db_1 ORACLE_HOME_NAME=OraDb11g_home2
简单验证sqlplus -v没有任何问题。
$ sqlplus -v
SQL*Plus: Release 11.2.0.3.0 Production
但是尝试sqlplus / as sysdba的时候却抛出了一个错误。这个问题看起来比较奇怪，记得之前碰到过，但是全然不记得是怎么处理的了。然后重新来过。
$ sqlplus / as sysdba
SQL*Plus: Release 11.2.0.3.0 Production on Thu Dec 31 23:09:19 2015
Copyright (c) 1982, 2011, Oracle. All rights reserved.
ERROR:
ORA-01031: insufficient privileges
这个步骤才开始验证参数文件，密码文件还没有开始做校验，为什么会抛出这个问题呢。但是使用sysoper就看起来没有问题了。
$ sqlplus / as sysoper
SQL*Plus: Release 11.2.0.3.0 Production on Thu Dec 31 23:21:07 2015
Copyright (c) 1982, 2011, Oracle. All rights reserved.
Connected to an idle instance.
对于这个问题，还得从几个小的细节说起，一个就是操作系统认证，对于操作系统认证对于Windows和Linux,Unix都会有一些不同的设置，但是思路都是相通。
在Linux下对应有操作系统的用户组，使得sysdba和操作系统用户组绑定起来。至于哪个是dba组，哪个是oper组，为什么sysoper就可以登录，而sysdba却不可以。这个可以参考一个文件。
为了突显出对比的效果来，我找出了正常运行的主库,config.c的内容如下：
$ORACLE_HOME/rdbms/lib/config.c
$ cat config.c
/* SS_DBA_GRP defines the UNIX group ID for sqldba adminstrative access. */
/* Refer to the Installation and User's Guide for further information. */
/* IMPORTANT: this file needs to be in sync with
rdbms/src/server/osds/config.c, specifically regarding the
number of elements in the ss_dba_grp array.
*/
#define SS_DBA_GRP "oinstall"
#define SS_OPER_GRP "oinstall"
#define SS_ASM_GRP ""
char *ss_dba_grp[] = {SS_DBA_GRP, SS_OPER_GRP, SS_ASM_GRP};
而在备库机器上，config.c的内容如下：
$ cat config.c
/* SS_DBA_GRP defines the UNIX group ID for sqldba adminstrative access. */
/* Refer to the Installation and User's Guide for further information. */
/* IMPORTANT: this file needs to be in sync with
rdbms/src/server/osds/config.c, specifically regarding the
number of elements in the ss_dba_grp array.
*/
#define SS_DBA_GRP "dba"
#define SS_OPER_GRP "oinstall"
#define SS_ASM_GRP ""
char *ss_dba_grp[] = {SS_DBA_GRP, SS_OPER_GRP, SS_ASM_GRP};
由此一来，可以看出为什么sysoper的可以正常登录了。
来简单对比一下主库的用户组情况，发现确实存在一个用户组为dba
[oracle@rolequery product]$ id oracle
uid=500(oracle) gid=500(oinstall) groups=500(oinstall),501(dba),502(oper),503(asmadmin),504(asmdba)
而在备库中只有oinstall的用户组
[oracle@BX_133_45 lib]$ id oracle
uid=501(oracle) gid=501(oinstall) groups=501(oinstall)
那么这个问题怎么修复呢，可以在备库中创建一个对应的用户组，然后把oracle用户加入dba组中，
# groupadd dba
# usermod -a -G dba oracle
# id oracle
uid=501(oracle) gid=501(oinstall) groups=501(oinstall),505(dba)
这个时候最好还是再relink一下，还是使用克隆安装的部分，不过需要在OraInventory中需要手工删除一下原本的安装信息，删除inventory.xml中的Oracle_HOME即可。
但是这个时候还是存在 ORA-01031: insufficient privileges的问题，是修改的用户的问题没有解决彻底吗。
其实还有一个就是sqlnet.authentication的服务认证，MOS( 730067.1)是这么描述的。
sqlnet.authentication_services must be set to (ALL) or to (BEQ, ) for this to work. On Windows this parameter must be set to (NTS).
这个时候再来看一看配置$ cat sqlnet.ora
# sqlnet.ora Network Configuration File: /home/U01/app/oracle/product/11.2.3/db_1/network/admin/sqlnet.ora
# Generated by Oracle configuration tools.
SQLNET.AUTHENTICATION_SERVICES= (NTS)
NAMES.DIRECTORY_PATH= (TNSNAMES, EZCONNECT)
ADR_BASE = /DATA/app/oracle
所以 SQLNET.AUTHENTICATION_SERVICES= (NTS)的设置存在问题的。注释掉之后，再次登录就没有问题了。
[oracle@BX_133_45 admin]$ sqlplus / as sysdba
SQL*Plus: Release 11.2.0.3.0 Production on Thu Dec 31 23:36:31 2015
Copyright (c) 1982, 2011, Oracle. All rights reserved.
Connected to an idle instance.
那么是不是就是因为 SQLNET.AUTHENTICATION_SERVICES直接导致的，用户组不同行不行呢，都已经试到这个份上了，我就继续玩玩。
删除原有的dba组，再次尝试就会看到原有的问题。
# groupdel dba
# id oracle
uid=501(oracle) gid=501(oinstall) groups=501(oinstall)
# su - oracle
$ sqlplus / as sysdba
SQL*Plus: Release 11.2.0.3.0 Production on Thu Dec 31 23:09:19 2015
Copyright (c) 1982, 2011, Oracle. All rights reserved.
ERROR:
ORA-01031: insufficient privileges
我继续想，是不是直接修改config.c就可以了，不需要再创建一个dba组了，行不行？
$ vi config.c
#define SS_DBA_GRP "oinstall"
#define SS_OPER_GRP "oinstall"
#define SS_ASM_GRP ""
然后再次登录，发现还是有问题。所以这两者在我的这个问题里都是缺一不可。
$ sqlplus / as sysdba
SQL*Plus: Release 11.2.0.3.0 Production on Thu Dec 31 23:11:14 2015
Copyright (c) 1982, 2011, Oracle. All rights reserved.
ERROR:
ORA-01031: insufficient privileges
看起来一个很简单的问题，没有很快解决，看起来还是有些尴尬啊，不过知道了原委，发现这些东西还是需要好好理解。
