ora-12737 http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14294/install.htm
修改oracle server字符集
STARTUP MOUNT;
ALTER SYSTEM ENABLE RESTRICTED SESSION;
ALTER SYSTEM SET JOB_QUEUE_PROCESSES=0;
ALTER SYSTEM SET AQ_TM_PROCESSES=0;
ALTER DATABASE OPEN;
ALTER DATABASE CHARACTER SET <new_character_set>;
SHUTDOWN IMMEDIATE; -- OR NORMAL
STARTUP;oracle认证方式:
oracle登陆认证方式的一些帖子 现象:
C:/>sqlplus "/as sysdba"
SQL*Plus:Release 10.2.0.1.0 - Production on Fri Nov 2 16:16:22 2007
Copyright (c) 1982, 2005, Oracle. All right reserved.
ERROR:
ORA-01031: insufficient privileges
Enter user-name:这个错误一般是由于oracle登录认证出现了问题:
Oracle登录认证有两种方式,基于操作系统的登录认证,基于oracle的验证。
可以通过改变sqlnet.ora文件,可以修改oracle登录认证方式:
IXDBA.NET技术社区
SQLNET.AUTHENTICATION_SERVICES= (NTS)是基于操作系统验证;SQLNET.AUTHENTICATION_SERVICES= (NONE)是基于Oracle验证;SQLNET.AUTHENTICATION_SERVICES= (NONE,NTS)是二者共存。
经过测试,以上规则只适用于windows服务器,在linux下规则如下:
默认情况下linux下的oracle数据库sqlnet.ora文件没有SQLNET.AUTHENTICATION_SERVICES参数,此时是基于操作系统认证和oracle密码验证共存的,加上SQLNET.AUTHENTICATION_SERVICES参数后,不管SQLNET.AUTHENTICATION_SERVICES设置为NONE或者NTS,都是基于oracle密码验证的。
Windows下设置oracle登录验证为操作系统验证方式的方法:
1 :把 os 用户加到 ora_dba 组
2 :设置 sqlnet.ora SQLNET.AUTHENTICATION_SERVICES = (NTS)
或者你可以重建口令文件来改密码,只不过原来授予 sysdba 和 sysoper 权限的用户,就不再具有这 2 个权限了。有一种oracle的登录方式是操作系统验证登录方式,即常说的OS验证登录方式,在SQL server中也有这种方式。
当用Windows的管理员帐户登陆系统后登陆数据库,只要加上 as sysdba,不管用什么用户名和密码登陆,都正确,因为这时系统已经忽略了/ 两边的用户名和密码,默认就是sys用户。
有些朋友经常使用connect / as sysdba登录,但不知道为什么没有提供用户名和密码就得到了sysdba的权限。还认为这样是不是不安全呢?Oracle在常见的多用户操作系统上都可以进行OS认证方式来登录。例如solaris,windows等等。
下面以常见的windows操作系统来说明看一下这个操作系统认证方式登录的原理。如果你的机器可以使用connect / as sysdba获取sysdba的权限,那么下面的每一个过程你的机器上都会得到验证,如果不能,按照下面的操作更改后,你也能以这种方式登录。- 在命令行下敲入compmgmt.msc 进入计算机管理
- 选择本地用户和组—>组
- 看是不是有一个组的名字叫做ORA_DBA
- 双击改组可以看到里面是不是有administrator用户
- 想一想你是不是以administrator用户登录的呢?
- 再进入Oracle安装目录(即$ORACLE_HOME 一般是D:"oracle)"ora92"network"admin 找到sqlnet.ora文件看看里面的是不是有SQLNET.AUTHENTICATION_SERVICES= (NTS)
- 如果这些都对的话,你就能已操作系统认证的方式(connect / as sysdba)来登录Oracle
接下来的问题是,如果你的数据很重要,出于安全考虑,希望禁止这种操作系统认证的方式。那么该怎么做呢?
很简单,找到在刚才的第6步骤中的sqlnet.ora文件,将SQLNET.AUTHENTICATION_SERVICES= (NTS)改为SQLNET.AUTHENTICATION_SERVICES=none即可。你再试一下看看会不会得到到如下结果:
ERROR:
ORA-01031: insufficient privileges
警告: 您不再连接到 ORACLE。如果你的机器不能以系统认证的方式登录,检查以上几个步骤,你总可以找到原因的。
oracle两种认证方式总结
ORACLE 数据库通过 sqlnet.ora 文件中的参数 sqlnet.authentication_services, 参数文件中的 remote_login_passwordfile 和口令文件 pwdsid.ora 三者协同作用实现身份认证 .
Sqlnet.authentication_services=(NTS)|(NONE)
NTS: 操作系统认证方式 , 不使用口令文件 ;
NONE: 口令文件认证方式
Remote_login_passwordfile=(NONE)|(EXCLUSIVE)|(SHARED)
NONE: 不使用口令文件 , 操作系统认证 ;
EXCLUSIVE: 口令文件认证方式 , 但只有一个数据库实例可以使用此文件 ;
SHARED: 口令文件认证方式 , 可以有多个数据库实例可以使用此文件 , 但此设置下只有 SYS 帐号能被识别 , 即使文件中存在其他用户的信息 , 也不允许他们以 SYSOPER/SYSDBA 登录 .
(1).sqlnet.authentication_services=(NTS)
同时 Remote_login_passwordfile=(NONE), 此时为操作系统认证方式 .
当以 oracle_dba 组下的用户登录进入本地的操作系统后 , 进行以下操作 :
sqlplus /nolog
SQL>conn / as sysdba
可以以 sysdba 身份登录成功 , 进行数据库方面的操作 .
当以远程进行登录时 , 执行 :
sqlplus /nolog
SQL>conn / as sysdba
则会显示 :
ERROR:ORA-01031:insufficient privileges
即不允许以 sysdba 身份远程登录系统 , 这也是 OS 认证这所以称为本地认证方式的原因 .
(2).Sqlnet.authentication_services=(NONE), 同时
Remote_login_passwordfile=(EXCLUSIVE)|(SHARED), 配合口令文件 PWDsid.ora, 此时为口令文件认证方式 :
当在本地以 oracle_dba 组下的用户登录进入系统时 , 进行以下操作 :
sqlplus /nolog
SQL>conn / as sysdba
则会显示 :
ERROR:ORA-01031:insufficient privileges
在本地或远程进行下边的操作 :
sqlplus /nolog
SQL>conn sys/ 密码 @ 服务名 as sysdba
可以进入系统 , 也就是说口令文件认证方式允许用户从本地或远程以 sysdba 身份登录 , 但必须提供口令字 .
(3).Sqlnet.authentication_services=(NTS), 同时
Remote_login_passwordfile=(EXCLUSIVE)|(SHARED), 配合口令文件 PWDsid.ora, 此时为操作系统认证和口令文件认证同时起作用 :
当在本地以 oracle_dba 组下的用户登录进入操作系统后 , 进行下边的操作 :
sqlplus /nolog
SQL>conn / as sysdba
可以进入系统 . 即操作系统认证方式登录成功 .
当在远程执行 :
sqlplus /nolog
SQL>conn sys/ 密码 @ 服务名 as sysdba
同时可正常登录到数据库系统 , 即口令文件认证方式登录成功 .附:要知道以下几种登陆方式不是一种概念
sqlplus /nolog
1: conn / as sysdba 本机登陆,使用操作系统认证,有无监听都可以
2: conn sys/password as sysdba 本机登陆,使用密码文件认证,有无监听都可以
3: conn sys/password@dbanote as sysdba 可以本机可以远程,使用密码文件认证,必须有监听,必须有 tnsnames.ora,remote_login_passwordfile 必须是 EXCLUSIVE说明:
从 oracle 的解释可以知道, SQLNET.AUTHENTICATION_SERVICES=(NTS) 是 WINDOWS 系统专用的,对 linux/UNIX 是不适用的。
最后做一个简单的总结:
1 、在 windows 下, SQLNET.AUTHENTICATION_SERVICES 必须设置为 NTS 或者 ALL 才能使用 OS 认证;不设置或者设置为其他任何值都不能使用 OS 认证。
2 、在 linux 下,在 SQLNET.AUTHENTICATION_SERVICES 的值设置为 ALL ,或者不设置的情况下, OS 验证才能成功;设置为其他任何值都不能使用 OS 认证。文章来自互联网,感谢作者!
查询修改ORACLE的server、客户端和导出dmp文件的字符集编码方式
测试的时候,本机oracle安装采用了utf8字符集,而项目的要求是gbk字符集,为了防止以后有不同字符集数据信息导入导出的问题,整理以下文档。
修改oracle字符集新装了oracle,装为AL32UTF8格式,无奈一个工程导出包是ZHS16GBK格式,想了想办法转换,以下是学习一、什么是oracle字符集
Oracle字符集是一个字节数据的解释的符号集合,有大小之分,有相互的包容关系。ORACLE 支持国家语言的体系结构允许你使用本地化语言来存储,处理,检索数据。它使数据库工具,错误消息,排序次序,日期,时间,货币,数字,和日历自动适应本地化语言和平台。影响oracle数据库字符集最重要的参数是NLS_LANG参数。它的格式如下:
NLS_LANG = language_territory.charset
它有三个组成部分(语言、地域和字符集),每个成分控制了NLS子集的特性。其中:
Language 指定服务器消息的语言,territory 指定服务器的日期和数字格式,charset 指定字符集。如:AMERICAN _ AMERICA. ZHS16GBK
从NLS_LANG的组成我们可以看出,真正影响数据库字符集的其实是第三部分。所以两个数据库之间的字符集只要第三部分一样就可以相互导入导出数据,前面影响的只是提示信息是中文还是英文。
二、如何查询Oracle的字符集
很多人都碰到过因为字符集不同而使数据导入失败的情况。这涉及三方面的字符集,一是oracel server端的字符集,二是oracle client端的字符集;三是dmp文件的字符集。在做数据导入的时候,需要这三个字符集都一致才能正确导入。开始—运行—sqlplus,用户名输入:system as sysdba
密码:XXXX1、查询oracle server端的字符集
有很多种方法可以查出oracle server端的字符集,比较直观的查询方法是以下这种:SQL>select userenv(‘language’) from dual;
结果类似如下:AMERICAN _ AMERICA. ZHS16GBK (本机结果SIMPLIFIED CHINESE_CHINA.AL32UTF8)
2、如何查询dmp文件的字符集
用oracle的exp工具导出的dmp文件也包含了字符集信息,dmp文件的第2和第3个字节记录了dmp文件的字符集。如果dmp文件不大,比如只有几M或几十M,可以用UltraEdit打开(16进制方式),看第2第3个字节的内容,如0354,然后用以下SQL查出它对应的字符集:
SQL> select nls_charset_name(to_number('0354','xxxx')) from dual;
ZHS16GBK
如果dmp文件很大,比如有2G以上(这也是最常见的情况),用文本编辑器打开很慢或者完全打不开,可以用以下命令(在unix主机上):
cat exp.dmp |od -x|head -1|awk '{print $2 $3}'|cut -c 3-6
然后用上述SQL也可以得到它对应的字符集。
3、查询oracle client端的字符集
这个比较简单。在windows平台下,就是注册表里面HKEY_LOCAL_MACHINE/SOFTWARE/ORACLE/HOME0/NLS_LANG 。还可以在dos窗口里面自己设置,比如:
set nls_lang=AMERICAN_AMERICA.ZHS16GBK
这样就只影响这个窗口里面的环境变量。
在unix平台下,就是环境变量NLS_LANG。
$echo $NLS_LANG
AMERICAN_AMERICA.ZHS16GBK
如果检查的结果发现server端与client端字符集不一致,请统一修改为同server端相同的字符集。
三、修改oracle的字符集
上文说过,oracle的字符集有互相的包容关系。如us7ascii就是zhs16gbk的子集,从us7ascii到zhs16gbk不会有数据解释上的问题,不会有数据丢失。在所有的字符集中utf8应该是最大,因为它基于unicode,双字节保存字符(也因此在存储空间上占用更多)。
一旦数据库创建后,数据库的字符集理论上讲是不能改变的。因此,在设计和安装之初考虑使用哪一种字符集十分重要。根据Oracle的官方说明,字符集的转换是从子集到超集受支持,反之不行。如果两种字符集之间根本没有子集和超集的关系,那么字符集的转换是不受oracle支持的。对数据库server而言,错误的修改字符集将会导致很多不可测的后果,可能会严重影响数据库的正常运行,所以在修改之前一定要确认两种字符集是否存在子集和超集的关系。一般来说,除非万不得已,我们不建议修改oracle数据库server端的字符集。特别说明,我们最常用的两种字符集ZHS16GBK和ZHS16CGB231280之间不存在子集和超集关系,因此理论上讲这两种字符集之间的相互转换不受支持。
1、修改server端字符集(不建议使用)
在oracle 8之前,可以用直接修改数据字典表props$来改变数据库的字符集。但oracle8之后,至少有三张系统表记录了数据库字符集的信息,只改props$表并不完全,可能引起严重的后果。正确的修改方法如下:
$sqlplus /nolog
SQL>conn / as sysdba;
以上方法测试不行,用scott/tiger登陆sqlplus然后connect sys/sys as sysdba,然后输入命令即可
若此时数据库服务器已启动,则先执行SHUTDOWN IMMEDIATE命令关闭数据库服务器,然后执行以下命令:SQL>STARTUP MOUNT;
SQL>ALTER SYSTEM ENABLE RESTRICTED SESSION;
SQL>ALTER SYSTEM SET JOB_QUEUE_PROCESSES=0;
SQL>ALTER SYSTEM SET AQ_TM_PROCESSES=0;
SQL>ALTER DATABASE OPEN;
SQL>ALTER DATABASE CHARACTER SET INTERNAL_USE ZHS16GBK; //跳过超子集检测
SQL>ALTER DATABASE national CHARACTER SET INTERNAL ZHS16GBK;
这一行不起作用,执行后出错ORA-00933: SQL 命令未正确结束,不过执行上一行命令已经生效,其他文章里未提到本行。
SQL>SHUTDOWN IMMEDIATE;SQL>STARTUP
2、修改dmp文件字符集
上文说过,dmp文件的第2第3字节记录了字符集信息,因此直接修改dmp文件的第2第3字节的内容就可以‘骗’过oracle的检查。这样做理论上也仅是从子集到超集可以修改,但很多情况下在没有子集和超集关系的情况下也可以修改,我们常用的一些字符集,如US7ASCII,WE8ISO8859P1,ZHS16CGB231280,ZHS16GBK基本都可以改。因为改的只是dmp文件,所以影响不大。
具体的修改方法比较多,最简单的就是直接用UltraEdit修改dmp文件的第2和第3个字节。比如想将dmp文件的字符集改为ZHS16GBK,可以用以下SQL查出该种字符集对应的16进制代码:
SQL> select to_char(nls_charset_id('ZHS16GBK'), 'xxxx') from dual;
0354
然后将dmp文件的2、3字节修改为0354即可。
如果dmp文件很大,用ue无法打开,就需要用程序的方法了。网上有人用java存储过程写了转换的程序(用java存储过程的好处是通用性教好,缺点是比较麻烦)。我在windows下测试通过。但要求oracle数据库一定要安装JVM选项。有兴趣的朋友可以研究一下程序代码
在注册表中更改ORACLE的字符集编码方式的操作:regedit
注册表路径:HKEY_LOCAL_MACHINE/SOFTWARE/ORACLE/HOME0
把 NLS_LANG 的值从 SIMPLIFIED CHINESE_CHINA.ZHS16GBK
改为 AMERICAN_AMERICA.US7ASCII american_america.we8dec