ORA-01017: invalid username/password; logon denied

实际上用户名密码是正确的，并且在数据库服务器上使用SQL*Plus通过监听连接也是正常的。

C:\Users\Kamus>sqlplus "sys/oracle@orcl11g as sysdba"

SQL*Plus: Release 11.1.0.7.0 - Production on Fri Mar 12 12:17:01 2010

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

Connected to:
Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - Production
With the Partitioning, OLAP and Real Application Testing options

SQL> 

真正的问题是因为数据库密码文件缺失了。在windows下，Oracle数据库密码文件是储存在%ORACLE_HOME%\database目录下，命名为PWD%SID%.ora。

密码文件不存在，数据库实例完全可以正常启动，只是在尝试通过监听登陆SYSDBA的时候就会报ORA-01017错误。

那么为什么在本地使用SQL*Plus是正常的，这实际上是一个错觉，因为在Windows中Oracle默认安装以后会在sqlnet.ora文件中设置SQLNET.AUTHENTICATION_SERVICES = (NTS)，这表示支持“Windows NT native authentication”方式登陆数据库，也就是属于OSDBA组的Windows用户不用提供密码也可以通过SYSDBA登陆数据库。sqlnet.ora文件位于%ORACLE_HOME%\network\admin目录下。

我们随便使用一个不存在的用户名密码都是可以登录数据库的。

C:\Users\Kamus>sqlplus "NotExist/nopassword@orcl11g as sysdba"

SQL*Plus: Release 11.1.0.7.0 - Production on Fri Mar 12 13:10:49 2010

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

Connected to:
Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - Production
With the Partitioning, OLAP and Real Application Testing options

SQL>

修改SQLNET.AUTHENTICATION_SERVICES参数为NONE之后。

SQLNET.AUTHENTICATION_SERVICES = (NONE)

再次测试用SQL*Plus登陆，报ORA-01031错误，即使提供正确的SYS用户密码也会报同样的错误，因为此时密码文件不存在，不能通过密码文件校验SYS用户密码是否正确，而又不允许通过NTS方式登陆数据库。

C:\Users\Kamus>sqlplus "NotExist/nopassword@orcl11g as sysdba"

SQL*Plus: Release 11.1.0.7.0 - Production on Fri Mar 12 13:14:07 2010

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

ERROR:
ORA-01031: insufficient privileges

Enter user-name:

重新创建密码文件，保持sqlnet.ora文件中SQLNET.AUTHENTICATION_SERVICES = (NONE)。

orapwd file=D:\oracle\product\11.1.0\db_1\database\PWDorcl11g.ora password=oracle

这样就只能通过正确的SYS用户和密码才可以用SYSDBA登陆数据库了。

C:\Users\Kamus>sqlplus / as sysdba

SQL*Plus: Release 11.1.0.7.0 - Production on Fri Mar 12 13:18:32 2010

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

ERROR:
ORA-01031: insufficient privileges

Enter user-name:
C:\Users\Kamus>
C:\Users\Kamus>sqlplus sys/oracle as sysdba

SQL*Plus: Release 11.1.0.7.0 - Production on Fri Mar 12 13:18:44 2010

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

Connected to:
Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - Production
With the Partitioning, OLAP and Real Application Testing options

SQL>

同样在这种配置下，SQL Developer也可以正常用SYSDBA登陆数据库了。

我们希望能够为全中国的Oracle技术爱好者提供一个交流与活动的平台，我们希望能够激发更多人对于Oracle技术以及相关知识的兴趣，我们希望沉浸在这些技术中的人员获得更多的乐趣。这是我跟eygle一直以来的一个理想，但愿我们能为此付出并且有所回报。

我们认识到中国目前掌握Oracle技术的人员广度和深度都跟美国、欧洲甚或是印度存在着较大差距，这需要我们更有热情的去付出，但愿在不久的将来ACOUG在全球Oracle用户组中占据一席之地。

ACOUG计划定期举行线下活动，而线下活动也将是ACOUG未来工作的重点，邀请著名的业内人士（不仅限于国内）来进行主题演讲，并围绕相关主题进行广泛的讨论从而使更多人获益。

eygle的文章有关于ACOUG更多的阐述，请猛击这里。

预计在这个月的3月20日（周六）开展ACOUG第一次线下活动，详细的地点、场地以及演讲主题还未确定，但是请有兴趣的朋友时刻关注ACOUG网站，欢迎参加。

可以通过awrddrpt.sql脚本生成。

SQL> @?/rdbms/admin/awrddrpt.sql

脚本会要求输入需要比较的第一份和第二份AWR报告的起始结束Snap ID，生成的AWR报告基本上如下图所示。

在普通的AWR报告各个部分都增加了1st, 2nd以及%Diff，这表示第一份时，第二份时各自的情况以及两次的相差百分比。

如果我们因为某些原因（比如权限问题）无法读取awrddrpt.sql，那么也可以通过DBMS_WORKLOAD_REPOSITORY.AWR_DIFF_REPORT_TEXT函数来完成。

DBMS_WORKLOAD_REPOSITORY.AWR_DIFF_REPORT_TEXT(
   dbid1     IN NUMBER,
   inst_num1 IN NUMBER,
   bid1      IN NUMBER,
   eid1      IN NUMBER,
   dbid2     IN NUMBER,
   inst_num2 IN NUMBER,
   bid2      IN NUMBER,
   eid2      IN NUMBER)
  RETURN awrdrpt_text_type_table PIPELINED;

dbid通过以下SQL获取。

SQL> SELECT DBID FROM v$database;
 
      DBID
----------
 777920305

inst_num通过以下SQL获得。

SQL> SELECT instance_number FROM v$instance;
 
INSTANCE_NUMBER
---------------
              1

bid和eid分别是Begin Snap ID和End Snap ID，通过以下SQL获得。

SQL> SELECT snap_id, end_interval_time
  2  FROM dba_hist_snapshot
  3  WHERE end_interval_time > trunc(sysdate-1)
  4  ORDER BY snap_id;
 
   SNAP_ID END_INTERVAL_TIME
---------- --------------------------------------------------------------------------------
       377 25-FEB-10 01.10.10.657 PM
       378 25-FEB-10 02.00.21.884 PM
       379 25-FEB-10 04.49.00.861 PM

将上述获得值全部作为参数值传入AWR_DIFF_REPORT_TEXT函数，执行即可。由于输出结果较长，使用spool打印到文件中方便查看。

SQL>spool awrdiff_1_377_1_378.txt
SQL> SELECT * FROM 
  2  TABLE(DBMS_WORKLOAD_REPOSITORY.AWR_DIFF_REPORT_TEXT(777920305,1,377,378,
  3  777920305,1,378,379));
SQL>spool off

EXECUTE dbms_system.set_sql_trace_in_session (sid,serial,TRUE);

这样的trace相当于event 10046 level 1。

停止：EXECUTE dbms_system.set_sql_trace_in_session (sid,serial,FALSE);

EXECUTE dbms_system.set_ev (sid,serial,10046,12,'');

这样直接设置某个会话的10046 event level 12，相当于level 4+level 8，也就是binds和waits都记录下来。

停止：EXECUTE dbms_system.set_ev (sid,serial,10046,0,”);

2. DBMS_SUPPORT包

EXECUTE dbms_support.start_trace_in_session (sid,serial,binds=>true,waits=>true);

这样的trace相当于event 10046 level 12。

停止：dbms_support.stop_trace_in_session(sid,serial);

备注：dbms_support包默认不存在，需要执行下述SQL来安装。
$ORACLE_HOME/rdbms/admin/dbmssupp.sql

3. 在Oracle10g以后可以使用DBMS_MONITOR包

EXECUTE DBMS_MONITOR.SESSION_TRACE_ENABLE(sid,serial, binds=>true,waits=>true);

这样的trace相当于event 10046 level 12。

停止：EXECUTE DBMS_MONITOR.SESSION_TRACE_DISABLE(sid,serial);

如果这几个问题是问到我，那么我怎么回答呢？

1. dedicated模式、非RAC、无连接池、要求支持2000个连接，在这样的条件下如何设置PGA？
根据应用程序特性的不同，SQL语句优化的程度，PGA的设置会相差很远。即使是知道专属连接方式，有2000个连接，恐怕我也无法再没有测试前就知道该设置多大的PGA。有一点默认的考虑，一个应用程序如果要支持2000个连接，那么通常不会是数据仓库系统，那么是OLTP系统的话，单个会话使用的PGA理应不需要很大。按照一般的经验值，给每个连接3M-5M，那么PGA的初始设置应该在6G-10G，然后跑测试，根据statspack或者awr report，再去判断是需要增加还是减少PGA。

2. 如何解决ORA-04031问题？
ORA-04031:unable to allocate string bytes of shared memory (“string”,”string”,”string”,”string”)
通常表示Shared Pool不足，一种情况是确实设置过小，另外一种情况是共享池碎片太多，没有足够的连续空间来放置一个稍大的空间请求，前一种情况就是增大共享池，大概到2G如果还报4031错误，那么应该是后一种情况了，而后一种情况则很可能是由于绑定变量不足导致过多的SQL Cursor存在，优化应用程序吧。再有那就可能是Oracle Database的bug了，那就五花八门不一而足了。

3. Current online redo log被删掉或者损坏后如何恢复？
当前联机日志损坏或者被删除，那么通常意味着必然会有数据损失，如果有备份，那么做full database restore，然后做不完全恢复，open resetlogs启动数据库。如果没有备份，那么利用_allow_resetlogs_corruption的隐含参数强制open数据库，做全库export，然后重建新库，做import。

4. oracle里的补丁具体分为哪几种类型？
我所知道的包括：大的Patchset，比如10.2.0.4的Patchset；Oneoff patch，修补某个bug或者某些bug的小Patch；Bundle Patch，一个时间段之后，发布的对于某一产品的集合Patch，修补一堆问题；CPU，也就是安全性Patch。dbsnake列出的其它那些，都不知道了。
其实，我的意思是这个问题有意义吗？

dbsnake – cuihua是这几年里我见到的对于Oracle数据库Internal研究最富有热情的朋友，在他的blog中有大量对于Oracle数据库内部机制的研究，比如类似于上面的第三个问题，哪怕是最棘手的数据库恢复，我相信dbsnake也是可以完成的。

实际上，昨天刚有朋友问怎么找到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=<current_sess or all_local_sess>
    wait_event="<wait_event_name_to_search_for>"
    waiter_min_secs_blkd=<secs>
    min_results=<num>
    [ timeout_mins=<mins - default is 10 mins> ]

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

在第1个session中：

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.

在第2个session中：

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

在第3个session中：

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

在另外一个session中用sysdba登陆，然后执行oradebug。

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

从以上的输出中可以得知：
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，有望在今后的版本中得到修改。

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], [], [], [], [], [], [], [], []

[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 ~]#

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

Block and Raw Devices Not Supported with OUI
With this release, OUI no longer supports installation of Oracle Clusterware files on
block or raw devices. Install Oracle Clusterware files either on Automatic Storage
Management diskgroups, or in a supported shared file system.

不再支持将文件存储在裸设备上，但是仅仅局限于使用OUI图形界面创建数据库，那么命令行方式应该还是可以的。

For new installations, OCR and voting disk files can be placed either on ASM, or on a
cluster file system or NFS system. Installing Oracle Clusterware files on raw or block
devices is no longer supported, unless an existing system is being upgraded.

Oracle Clusterwae需要的OCR和Voting disk可以存储在ASM或者集群文件系统或者NFS中，对于全新安装，裸设备不再被支持，但是如果是升级而来的话（比如从10g升级到11g），仍然支持。

Voting Disk Backup Procedure Change
In prior releases, backing up the voting disks using a dd command was a required
postinstallation task. With Oracle Clusterware release 11.2 and later, backing up and
restoring a voting disk using the dd command is not supported.
Backing up voting disks manually is no longer required, as voting disks are backed up
automatically in the OCR as part of any configuration change and voting disk data is
automatically restored to any added voting disks.

之前Voting disk因为是存储在裸设备中的，因此备份需要使用dd命令来手动执行，在11gR2中，通过dd备份Voting disk不再被支持，同时，也无需通过任何方法手动备份Voting disk了，备份将自动进行。

那么在Oracle9i数据库中到底跨平台表空间传输能不能够实现呢？Oracle官方文档中提到：

The source and target database must be on the same hardware platform. For example, you can transport tablespaces between Sun Solaris Oracle databases, or you can transport tablespaces between Windows NT Oracle databases. However, you cannot transport a tablespace from a Sun Solaris Oracle database to an Windows NT Oracle database.

必须要在同一硬件平台上，并且举例无法从Solaris平台传输表空间到Windows平台。

但是实际上，这样的约束仅仅是由于字符序的限制。

SQL> SELECT * FROM v$transportable_platform ORDER BY PLATFORM_NAME;
 
PLATFORM_ID PLATFORM_NAME                            ENDIAN_FORMAT
----------- ---------------------------------------- --------------
          6 AIX-Based Systems (64-bit)               Big
         16 Apple Mac OS                             Big
         19 HP IA Open VMS                           Little
         15 HP Open VMS                              Little
          5 HP Tru64 UNIX                            Little
          3 HP-UX (64-bit)                           Big
          4 HP-UX IA (64-bit)                        Big
         18 IBM Power Based Linux                    Big
          9 IBM zSeries Based Linux                  Big
         10 Linux IA (32-bit)                        Little
         11 Linux IA (64-bit)                        Little
         13 Linux x86 64-bit                         Little
          7 Microsoft Windows IA (32-bit)            Little
          8 Microsoft Windows IA (64-bit)            Little
         12 Microsoft Windows x86 64-bit             Little
         17 Solaris Operating System (x86)           Little
         20 Solaris Operating System (x86-64)        Little
          1 Solaris[tm] OE (32-bit)                  Big
          2 Solaris[tm] OE (64-bit)                  Big

可以看到所有的Windows平台上Oracle数据库均是小字符序的，而Solaris SPARC平台是大字符序，因此Oracle官方文档笼统地说不支持跨平台传输表空间。

选择同样为大字符序的操作系统Solaris SPARC 64bit和HP-UX IA (64-bit)，做Oracle9i数据库的跨平台表空间传输，实验证明是完全可行的。

Solaris平台配置：Solaris10，Oracle9.2.0.6
HP-UX平台配置：HP-UX11，Oracle9.2.0.8

无论是操作系统平台还是数据库小版本号都是不一样的。

在Solaris端，USERS表空间中有数据文件/dev/md/rdsk/d29（裸设备），并且存在两张表，KAMUS.T1和SYSTEM.T。

SQL> SELECT segment_name,owner FROM dba_segments WHERE tablespace_name='USERS';
 
SEGMENT_NAME                   OWNER
------------------------------ ------------------------------
T                              SYSTEM
T1                             KAMUS

将USERS表空间设置为READONLY之后，开始传输表空间。

$ exp TRANSPORT_TABLESPACE=y TABLESPACES=(users)
 TRIGGERS=n CONSTRAINTS=n GRANTS=n FILE=/install/expdat.dmp
 
Export: Release 9.2.0.6.0 - Production on Thu Nov 19 17:25:48 2009
 
Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.
 
 
Username: SYS/oracle AS SYSDBA
 
Connected to: Oracle9i Enterprise Edition Release 9.2.0.6.0 - 64bit Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.6.0 - Production
Export done in US7ASCII character set and AL16UTF16 NCHAR character set
server uses ZHS16GBK character set (possible charset conversion)
Note: table data (rows) will not be exported
Note: grants on tables/views/sequences/roles will not be exported
Note: constraints on tables will not be exported
About to export transportable tablespace metadata...
For tablespace USERS ...
. exporting cluster definitions
. exporting table definitions
. . exporting table                              T
. . exporting table                             T1
. end transportable tablespace metadata export
Export terminated successfully without warnings.

然后通过dd命令将数据文件以及dmp文件copy到HP-UX机器上，在我的实验环境中，最终是dd到/dev/testvg/rlvol4上。

然后在HP-UX上导入metadata：

imp  PARFILE='par.f'

其中par.f文件的内容如下：

TRANSPORT_TABLESPACE=y 
FILE=/oracle/oradata/expdat.dmp
DATAFILES=('/dev/testvg/rlvol4')
TABLESPACES=(users) 
TTS_OWNERS=(system,kamus)  
FROMUSER=(system,kamus) 
TOUSER=(system,system)

成功导入之后，查看USERS表空间中的数据。

SQL> SELECT segment_name,owner FROM dba_segments WHERE tablespace_name='USERS';
 
SEGMENT_NAME                   OWNER
------------------------------ ------------------------------
T                              SYSTEM
T1                             SYSTEM

继续在该表空间中做其他操作，比如create table等，也一切正常。

只做了使用裸设备作为数据文件的测试，不确认是不是如果数据文件存储在文件系统上也同样可以成功。如果是AIX平台，要注意一下，在AIX中裸设备头部有4K的OS Reserved Area，dd的时候需要skip掉。

没有做更多平台的测试，但是可以推测，即使是Oracle9i，Linux,Windows这两个平台或者AIX,HP-UX,SOLARIS SPARC这三个平台之间都应该是可以顺利地完成表空间传输的。

Update@2009-12-28
朋友测试的结果，从HP-UX IA (64-bit)平台传输表空间到 AIX-Based Systems (64-bit)平台无法成功。即使dd了文件头也仍然会报错。

表现为：
当关闭RAC环境的某一个实例之后（无论是shutdown abort还是shutdown immediate），再用远程客户端通过tns连接RAC Service都会间歇性报ORA-01034错误。

$ sqlplus system/oracle@prod 
 
SQL*Plus: Release 9.2.0.8.0 - Production ON Tue Nov 17 20:52:09 2009
 
Copyright (c) 1982, 2002, Oracle Corporation.  ALL rights reserved.
 
ERROR:
ORA-01034: ORACLE NOT available
ORA-27101: shared memory realm does NOT exist
HPUX-ia64 Error: 2: No such file OR directory

客户端的TNS配置是很常规的客户端failover。

PROD  =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = VIP1)(PORT = 1521))
      (ADDRESS = (PROTOCOL = TCP)(HOST = VIP2)(PORT = 1521))
      (LOAD_BALANCE = yes)
    )
    (CONNECT_DATA =
      (SERVICE_NAME = prod)
      (FAILOVER_MODE=
       (TYPE=SELECT)
       (METHOD=BASIC))
    )
  )

纳闷许久，仔细检查服务器端的listener.ora配置，才发现设置了GLOBAL_DBNAME，这是对于还没有往本地监听动态注册服务名功能的Oracle8和Oracle7才需要设置，在Oracle9i之后，如果设置了该参数，将会导致Failover失败。

将listener.ora中的配置从：

SID_LIST_LISTENER_PROD2 =
  (SID_LIST =
    (SID_DESC =
      (GLOBAL_DBNAME=prod)
      (ORACLE_HOME = /oracle/product/9.2)
      (SID_NAME = prod2)
    )
  )

修改为：

SID_LIST_LISTENER_PROD2 =
  (SID_LIST =
    (SID_DESC =
      (ORACLE_HOME = /oracle/product/9.2)
      (SID_NAME = prod2)
    )
  )

再次测试Failover，一切正常。

结论：
1. 对于监听依然存在，然后数据库实例关闭的情况，必须是在监听中动态注册的服务，才可以实现Failover。
2. GLOBAL_DBNAME会影响Failover。