Oracle 10g RAC 配置物理dataguard系列1:RAC主库信息概览、备库准备工作

最近在学习Oracle dataguard相关知识。本系列就Oracle Enterprise Linux 5.5 X86_64位环境下Oracle 10g 10.2.0.5.0双节点RAC数据库配置一套物理dataguard做一记录,一来给自己的学习做一简单记录,二来,同样希望可以给广大网友及Oracle数据库技术爱好者提供思路。

在实施之前,简单介绍下背景、最终目标及配置步骤:

  •          背景介绍:主库是一套运行在Oracle Enterprise Linux 5.5 X86_64位环境下Oracle 10g 10.2.0.5.0双节点RAC数据库,主库用的是ASM存储,ASM磁盘利用raw来实现;
  •          最终目标:需要给该主库搭建一套同样是运行在Oracle Enterprise Linux 5.5 X86_64位环境下的物理备库,并且能够switchover,确保高可用
  •          配置步骤:    1 了解现有主库的配置信息;

                               2  搭建一台干净的新机器,用于创建物理备库使用;

                               3  在物理备机上安装oracle数据库软件,并且升级到同主库软件版本一致,即10.2.0.5.0;

                               4  在物理备机上创建ASM实例,ASM磁盘同样选择裸设备来实现;

                               5  配置物理备库;

                               6 确认switchover成功,双节点RAC+physical standby既可提供实例级别容灾(RAC功能)又可以提供存储级别容灾(Dataguard功能),做到真正的高可用!

     本篇是整个实施过程的系列1:本篇的内容主要是查看主库基本配置信息,及创建一台干净的Linux服务器,用作备库。

一  首先了解下现有双节点RAC数据库配置信息:

1 节点1系统基本信息:

[root@oracle-rac1 ~]# hostname 
oracle-rac1.gillion.com.cn
[root@oracle-rac1 ~]# uname -rm
2.6.18-194.0.0.0.3.el5 x86_64
[root@oracle-rac1 ~]# df -Th
Filesystem    Type    Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
              ext3     20G   12G  6.8G  64% /
/dev/sda1     ext3     99M   19M   75M  21% /boot
tmpfs        tmpfs    3.9G     0  3.9G   0% /dev/shm
[root@oracle-rac1 ~]# ifconfig 
eth0      Link encap:Ethernet  HWaddr 00:0C:29:3A:B8:31  
          inet addr:172.16.0.33  Bcast:172.16.15.255  Mask:255.255.240.0
          inet6 addr: fe80::20c:29ff:fe3a:b831/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:836563 errors:0 dropped:0 overruns:0 frame:0
          TX packets:10459 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:73068451 (69.6 MiB)  TX bytes:2856621 (2.7 MiB)
eth0:1    Link encap:Ethernet  HWaddr 00:0C:29:3A:B8:31  
          inet addr:172.16.0.35  Bcast:172.16.15.255  Mask:255.255.240.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
eth1      Link encap:Ethernet  HWaddr 00:0C:29:3A:B8:3B  
          inet addr:192.168.139.13  Bcast:192.168.139.255  Mask:255.255.255.0
          inet6 addr: fe80::20c:29ff:fe3a:b83b/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1484344 errors:0 dropped:0 overruns:0 frame:0
          TX packets:707841 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:327352385 (312.1 MiB)  TX bytes:353601291 (337.2 MiB)
lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:265726 errors:0 dropped:0 overruns:0 frame:0
          TX packets:265726 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:61035429 (58.2 MiB)  TX bytes:61035429 (58.2 MiB)
[root@oracle-rac1 ~]# cat /etc/hosts
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1               localhost
172.16.0.33             oracle-rac1.gillion.com.cn oracle-rac1
172.16.0.35             oracle-rac1-vip oracle-rac1-vip.gillion.com.cn
192.168.139.13          oracle-rac1-priv
172.16.0.34             oracle-rac2.gillion.com.cn oracle-rac2
172.16.0.36             oracle-rac2-vip oracle-rac2-vip.gillion.com.cn
192.168.139.14          oracle-rac2-priv
[root@oracle-rac1 ~]# su - oracle
[oracle@oracle-rac1 ~]$ . oraenv
ORACLE_SID = [oracle] ? glndb
[oracle@oracle-rac1 ~]$ export ORACLE_SID=glndb1
[oracle@oracle-rac1 ~]$ env | grep ORA
ORACLE_SID=glndb1
ORACLE_BASE=/u01/app/oracle
ORACLE_HOME=/u01/app/oracle/product/10.2.0/db_1
[oracle@oracle-rac1 ~]$

2 节点1数据库基本信息:

[oracle@oracle-rac1 ~]$ sqlplus
SQL*Plus: Release 10.2.0.5.0 - Production on Tue Feb 14 09:11:00 2012
Copyright (c) 1982, 2010, Oracle.  All Rights Reserved.
SQL> conn / as sysdba;
Connected.
SQL> select * from v$version;
BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bi
PL/SQL Release 10.2.0.5.0 - Production
CORE    10.2.0.5.0      Production
TNS for Linux: Version 10.2.0.5.0 - Production
NLSRTL Version 10.2.0.5.0 - Production
SQL> alter session set nls_date_format='yyyy/mm/dd hh24:mi:ss';
Session altered.
SQL> select dbid,name,created,log_mode,db_unique_name from gv$database;
      DBID NAME      CREATED             LOG_MODE     DB_UNIQUE_NAME
---------- --------- ------------------- ------------ ---------
3995745524 GLNDB     2010/08/03 10:44:04 ARCHIVELOG   glndb
3995745524 GLNDB     2010/08/03 10:44:04 ARCHIVELOG   glndb
SQL> show parameter db_name;
NAME                                 TYPE        VALUE
------------------------------------ ----------- ---------
db_name                              string      glndb
SQL> show parameter db_unique;
NAME                                 TYPE        VALUE
------------------------------------ ----------- ---------
db_unique_name                       string      glndb
SQL> archive log list;
Database log mode              Archive Mode
Automatic archival             Enabled
Archive destination            /home/oracle/arch1
Oldest online log sequence     7699
Next log sequence to archive   7700
Current log sequence           7700
SQL> show parameter spfile
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
spfile                               string      +ORADATA/glndb/spfileglndb.ora
SQL>

3 节点2基本信息:

[root@oracle-rac2 ~]# hostname 
oracle-rac2.gillion.com.cn
[root@oracle-rac2 ~]# uname -rm
2.6.18-194.0.0.0.3.el5 x86_64
[root@oracle-rac2 ~]# df -Th
Filesystem    Type    Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
              ext3     20G   12G  6.9G  63% /
/dev/sda1     ext3     99M   19M   75M  21% /boot
tmpfs        tmpfs    3.9G     0  3.9G   0% /dev/shm
[root@oracle-rac2 ~]# ifconfig 
eth0      Link encap:Ethernet  HWaddr 00:0C:29:D1:B5:4C  
          inet addr:172.16.0.34  Bcast:172.16.15.255  Mask:255.255.240.0
          inet6 addr: fe80::20c:29ff:fed1:b54c/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:833250 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8442 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:72725394 (69.3 MiB)  TX bytes:2440410 (2.3 MiB)
eth0:1    Link encap:Ethernet  HWaddr 00:0C:29:D1:B5:4C  
          inet addr:172.16.0.36  Bcast:172.16.15.255  Mask:255.255.240.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
eth1      Link encap:Ethernet  HWaddr 00:0C:29:D1:B5:56  
          inet addr:192.168.139.14  Bcast:192.168.139.255  Mask:255.255.255.0
          inet6 addr: fe80::20c:29ff:fed1:b556/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1534148 errors:0 dropped:0 overruns:0 frame:0
          TX packets:655976 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:424024468 (404.3 MiB)  TX bytes:256611983 (244.7 MiB)
lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:274642 errors:0 dropped:0 overruns:0 frame:0
          TX packets:274642 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:61783289 (58.9 MiB)  TX bytes:61783289 (58.9 MiB)
[root@oracle-rac2 ~]# cat /etc/hosts
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1               localhost
172.16.0.33             oracle-rac1.gillion.com.cn oracle-rac1
172.16.0.35             oracle-rac1-vip oracle-rac1-vip.gillion.com.cn
192.168.139.13          oracle-rac1-priv
172.16.0.34             oracle-rac2.gillion.com.cn oracle-rac2
172.16.0.36             oracle-rac2-vip oracle-rac2-vip.gillion.com.cn
192.168.139.14          oracle-rac2-priv
[root@oracle-rac2 ~]# su - oracle
[oracle@oracle-rac2 ~]$ . oraenv
ORACLE_SID = [oracle] ? glndb
[oracle@oracle-rac2 ~]$ export ORACLE_SID=glndb2
[oracle@oracle-rac2 ~]$ env |grep ORA
ORACLE_SID=glndb2
ORACLE_BASE=/u01/app/oracle
ORACLE_HOME=/u01/app/oracle/product/10.2.0/db_1
[oracle@oracle-rac2 ~]$

4 点2数据库基本信息:

[oracle@oracle-rac2 ~]$ sqlplus
SQL*Plus: Release 10.2.0.5.0 - Production on Tue Feb 14 09:25:47 2012
Copyright (c) 1982, 2010, Oracle.  All Rights Reserved.
SQL> conn / as sysdba;
Connected.
SQL> select * from v$version;
BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bi
PL/SQL Release 10.2.0.5.0 - Production
CORE    10.2.0.5.0      Production
TNS for Linux: Version 10.2.0.5.0 - Production
NLSRTL Version 10.2.0.5.0 - Production
SQL> alter session set nls_date_format='yyyy/mm/dd hh24:mi:ss';
Session altered.
SQL> set line 160
SQL> select dbid,name,created,log_mode,db_unique_name from gv$database;
      DBID NAME      CREATED             LOG_MODE     DB_UNIQUE_NAME
---------- --------- ------------------- ------------ ---------
3995745524 GLNDB     2010/08/03 10:44:04 ARCHIVELOG   glndb
3995745524 GLNDB     2010/08/03 10:44:04 ARCHIVELOG   glndb
SQL> show parameter db_name
NAME                                 TYPE        VALUE
------------------------------------ ----------- --------------
db_name                              string      glndb
SQL> show parameter db_unique
NAME                                 TYPE        VALUE
------------------------------------ ----------- --------------
db_unique_name                       string      glndb
SQL> archive log list;
Database log mode              Archive Mode
Automatic archival             Enabled
Archive destination            /home/oracle/arch2
Oldest online log sequence     3270
Next log sequence to archive   3271
Current log sequence           3271
SQL> show parameter spfile
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
spfile                               string      +ORADATA/glndb/spfileglndb.ora
SQL>

5 数据文件、 控制文件基本信息:

SQL> select name,bytes/1024/1024 M from v$datafile
  2  union
  3  select name,0 from v$controlfile
  4  order by 2
  5  ;
NAME                                                        M
-------------------------------------------------- ----------
+ORADATA/glndb/controlfile/current.256.726057849            0
+ORADATA/glndb/datafile/example.435.756233417               2
+ORADATA/glndb/datafile/users.265.726057871                 2
+ORADATA/glndb/datafile/undotbs3.268.774870843            200
+ORADATA/glndb/datafile/undotbs2.264.726057869            261
+ORADATA/glndb/datafile/sysaux.262.726057863             1290
+ORADATA/glndb/datafile/system.260.726057851             6039
7 rows selected.
SQL>

6 联机日志文件信息:

SQL> select * from v$log;
    GROUP#    THREAD#  SEQUENCE#      BYTES    MEMBERS ARC STATUS           FIRST_CHANGE# FIRST_TIME
---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- -------------------
         1          1       7700   52428800          1 NO  CURRENT              445626703 2012/02/13 23:06:00
         2          1       7699   52428800          1 YES INACTIVE             445622543 2012/02/13 23:05:29
         4          2       3271   52428800          1 NO  CURRENT              445627780 2012/02/13 23:05:58
         5          2       3270   52428800          1 YES INACTIVE             445332258 2012/02/13 09:05:39
SQL>

7 资源状态信息:

[oracle@oracle-rac2 ~]$ /u01/app/oracle/product/10.2.0/crs/bin/crs_stat -t
Name           Type           Target    State     Host        
------------------------------------------------------------
ora.glndb.db   application    ONLINE    ONLINE    oracle-rac2 
ora...._svc.cs application    ONLINE    ONLINE    oracle-rac1 
ora....db1.srv application    ONLINE    ONLINE    oracle-rac1 
ora....b1.inst application    ONLINE    ONLINE    oracle-rac1 
ora....b2.inst application    ONLINE    ONLINE    oracle-rac2 
ora....svc2.cs application    ONLINE    ONLINE    oracle-rac2 
ora....db2.srv application    ONLINE    ONLINE    oracle-rac2 
ora....SM1.asm application    ONLINE    ONLINE    oracle-rac1 
ora....C1.lsnr application    ONLINE    ONLINE    oracle-rac1 
ora....ac1.gsd application    ONLINE    ONLINE    oracle-rac1 
ora....ac1.ons application    ONLINE    ONLINE    oracle-rac1 
ora....ac1.vip application    ONLINE    ONLINE    oracle-rac1 
ora....SM2.asm application    ONLINE    ONLINE    oracle-rac2 
ora....C2.lsnr application    ONLINE    ONLINE    oracle-rac2 
ora....ac2.gsd application    ONLINE    ONLINE    oracle-rac2 
ora....ac2.ons application    ONLINE    ONLINE    oracle-rac2 
ora....ac2.vip application    ONLINE    ONLINE    oracle-rac2 
[oracle@oracle-rac2 ~]$

二      在获取了RAC主库的基本信息之后,接下来搭建一套新的机器做物理dataguard用

本文采用的是在一套虚拟机上搭建另外的备库机器,该虚拟机软件是VMware ESX 4.0,该软件其实可以认为是一个操作系统,是直接装在物理机器上的,有别于Vmware公司的VMware Server、VMware Workstation软件,后两者是先需要有操作系统,然后在操作系统上安装该虚拟机软件。而且,VMware ESX 4.0虚拟机软件相对来说也要比后两者稳定。

  1.     用Vmware vSphere Client工具登录虚拟机控制台:

登录控制台后,虚拟机信息概览:

2       选择File–New–Virtual Machine,新建虚拟机命名为10gRAC-Dataguard:

3      接下来一步一步走,同在VMware Server、VMware Workstation里创建新虚拟机一样,在此不再赘述。配置后的虚拟机概览如下:

4        给10gRAC-Dataguard加电,开始安装操作系统,虚拟机磁盘分区如下:

5        虚拟机网络配置信息如下:

IPv4:172.16.0.202

Netmask:255.255.240.0

Gateway:172.16.15.254

DNS:Null

Hostname:ora10grac-dg

6     软件包安装时,选择客户化,其中,下述是选择要安装的软件包:

 Desktop Environments:GNOME Desktop Environment

 Applications:  

           Editors

           Graphics

 Development:

           Development Libraries

           Development Tools

           GNOME Software Development

           Legacy Software Development

           X software Development

 Base System: 

           Administration Tools

           Base

           Legacy Software Support

           System Tools (其中,选择oracleasm软件包。注:默认情况下并没有oracleasmlib-2.0.4-1.el5软件包,如果采用asmlib来管理和创建asm磁盘的话,仍需要后续手工安装该RPM包,否则将来配置ASM存储时会找不到ASM磁盘!!!)

         暂时,先安装这些软件包,稍后在安装oracle软件时,如有缺失软件包的话,再续安装,至于其它的Server,虚拟化,集群软件包一概不装!

       7        接下来,进行格式化文件系统,进入系统安装。稍后,还有一些后续的配置工作,记得不要开启SELinux并且关闭防火墙!最后,一台新的虚拟机配置成功,登录界面如下:

        8          新虚拟机基本信息如下:

[root@ora10grac-dg ~]# hostname 
ora10grac-dg
[root@ora10grac-dg ~]# uptime 
 11:17:18 up 2 min,  2 users,  load average: 1.98, 1.23, 0.47
[root@ora10grac-dg ~]# df -Th
Filesystem    Type    Size  Used Avail Use% Mounted on
/dev/sda1     ext3    7.8G  2.8G  4.7G  37% /
tmpfs        tmpfs    1.1G     0  1.1G   0% /dev/shm
[root@ora10grac-dg ~]# ifconfig 
eth0      Link encap:Ethernet  HWaddr 00:0C:29:2E:60:24  
          inet addr:172.16.0.202  Bcast:172.16.15.255  Mask:255.255.240.0
          inet6 addr: fe80::20c:29ff:fe2e:6024/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3356 errors:0 dropped:0 overruns:0 frame:0
          TX packets:196 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:333071 (325.2 KiB)  TX bytes:21084 (20.5 KiB)
lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:1056 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1056 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:1753796 (1.6 MiB)  TX bytes:1753796 (1.6 MiB)
[root@ora10grac-dg ~]# uname -rm
2.6.18-194.el5 x86_64
[root@ora10grac-dg ~]#

这样,一台新的物理备库机器配置成功!接下来需要在该机器上安装oracle软件,配置ASM,升级oracle软件到10.2.0.5.0版本下篇继续

删除undo表空间遇到ORA-30013及ORA-01548的解决思路

今天在一套RAC环境下删除、切换其中一个实例的undo表空间时,遭遇ORA-30013及ORA-01548的错误,下面记录过程及解决方法。

1 创建新的UNDO表空间UNDOTBS3,并将当前实例的UNDO切换到UNDOTBS3之后,删除旧的UNDOTBS1时,遇到下述错误:

SQL> drop tablespace undotbs1 including contents and datafiles;
drop tablespace undotbs1 including contents and datafiles
*
ERROR at line 1:
ORA-30013: undo tablespace 'UNDOTBS1' is currently in use

2 从上可以看到UNDOTBS1目前正在被使用。查询MetaLink,Unable to Drop Undo Tablespace ORA-30013 [ID 835944.1]获取基本思路,依据该文档给出的提示,执行下述命令:

SQL> select segment_name,owner,tablespace_name,status from dba_rollback_segs 
  2  where tablespace_name='UNDOTBS1' and status = 'ONLINE';

SEGMENT_NAME     OWNER  TABLESPACE_NAME    STATUS
---------------- ------ ------------------ ---------
_SYSSMU2$        PUBLIC UNDOTBS1           ONLINE
_SYSSMU3$        PUBLIC UNDOTBS1           ONLINE
_SYSSMU6$        PUBLIC UNDOTBS1           ONLINE
_SYSSMU8$        PUBLIC UNDOTBS1           ONLINE
SQL> SELECT KTUXEUSN, KTUXESLT, KTUXESQN, /* Transaction ID */ KTUXESTA Status,
  2  KTUXECFL Flags FROM x$ktuxe WHERE ktuxesta!='INACTIVE';
  KTUXEUSN   KTUXESLT   KTUXESQN STATUS           FLAGS
---------- ---------- ---------- ---------------- ------------------------
         2         38     583286 PREPARED         SCO|COL|REV|DEAD|EXTDTX
         3         29     982959 PREPARED         SCO|COL|REV|DEAD|EXTDTX
         6         14     945326 PREPARED         SCO|COL|REV|DEAD|EXTDTX
         8          7     957413 PREPARED         SCO|COL|REV|DEAD|EXTDTX
        13         19     507098 PREPARED         SCO|COL|REV|EXTDTX
SQL> select local_tran_id, state from dba_2pc_pending; 
LOCAL_TRAN_ID          STATE
---------------------- ----------------
14.28.100017           collecting
2.38.583286            prepared
8.7.957413             prepared
3.29.982959            prepared
6.14.945326            prepared
13.19.507098           prepared
6 rows selected.

3 从上步的结果,结合文档ID 835944.1,基本上可以找到问题的原因:当前数据库中有未结束的分布式事务,而这些未结束的分布式事务占用了UNDOTBS1,最终导致不能删除UNDOTBS1。 文档ID 835944.1给出的解决方案是结束掉这些分布式事务。MetaLink上给出的思路是参照 Note 401302.1文档,而不凑巧的是,现在这篇文档无法查看,不得已,尝试重启数据库并删除UNDOTBS1。 重启之后,alert日志里看到如下错误信息:

*** SERVICE NAME:(SYS$BACKGROUND) 2012-02-10 11:27:15.527
*** SESSION ID:(431.1) 2012-02-10 11:27:15.527
*** 2012-02-10 11:27:15.527
ERROR, tran=14.28.100017, session#=1, ose=0:
ORA-02019: connection description for remote database not found
ORA-02019: connection description for remote database not found
*** 2012-02-10 11:27:50.676
ERROR, tran=14.28.100017, session#=1, ose=0:
ORA-02019: connection description for remote database not found
ORA-02019: connection description for remote database not found
*** 2012-02-10 11:28:42.707
ERROR, tran=14.28.100017, session#=1, ose=0:
ORA-02019: connection description for remote database not found
ORA-02019: connection description for remote database not found

尝试再次删除UNDOTBS1:

SQL> drop tablespace undotbs1 including contents and datafiles;
drop tablespace undotbs1 including contents and datafiles
*
ERROR at line 1:
ORA-01548: active rollback segment '_SYSSMU2$' found, terminate dropping tablespace

这次报出ORA-01548的错误!!!原来还是分布式事务未提交导致的:

SQL> SELECT KTUXEUSN, KTUXESLT, KTUXESQN, /* Transaction ID */ KTUXESTA Status,
  2  KTUXECFL Flags FROM x$ktuxe WHERE ktuxesta!='INACTIVE';
  KTUXEUSN   KTUXESLT   KTUXESQN STATUS           FLAGS
---------- ---------- ---------- ---------------- ------------------------
         2         38     583286 PREPARED         SCO|COL|REV|DEAD|EXTDTX
         3         29     982959 PREPARED         SCO|COL|REV|DEAD|EXTDTX
         6         14     945326 PREPARED         SCO|COL|REV|DEAD|EXTDTX
         8          7     957413 PREPARED         SCO|COL|REV|DEAD|EXTDTX
        13         19     507098 PREPARED         SCO|COL|REV|EXTDTX
SQL> select local_tran_id, state from dba_2pc_pending; 
LOCAL_TRAN_ID          STATE
---------------------- ----------------
14.28.100017           collecting
2.38.583286            prepared
8.7.957413             prepared
3.29.982959            prepared
6.14.945326            prepared
13.19.507098           prepared
6 rows selected.
SQL>

4 继续MetaLink:ORA-1548 Dropping UNDO Tablespace Distributed Transaction Pending:Prepared / Dead [ID 1321093.1]根据该文档,执行下述命令:

SQL> Select segment_id,segment_name,status,tablespace_name
  2  from dba_rollback_segs where status not in ('ONLINE','OFFLINE');

SEGMENT_ID SEGMENT_NAME                   STATUS           TABLESPACE_NAME
---------- ------------------------------ ---------------- ------------------------------
         2 _SYSSMU2$                      PARTLY AVAILABLE UNDOTBS1
         3 _SYSSMU3$                      PARTLY AVAILABLE UNDOTBS1
         6 _SYSSMU6$                      PARTLY AVAILABLE UNDOTBS1
         8 _SYSSMU8$                      PARTLY AVAILABLE UNDOTBS1
SQL>

You find you have segments that are 'Partly Available' This usually means they still have active transactions pending and you can not drop the tablespace until the transaction is committed or rolled back. 当回滚段状态为Partly Available时,说明还是有事务没结束!!!

SQL> SELECT KTUXEUSN, KTUXESLT, KTUXESQN, /* Transaction ID */
  2  KTUXESTA Status,
  3  KTUXECFL Flags
  4  FROM x$ktuxe
  5  WHERE ktuxesta!='INACTIVE'
  6  AND ktuxeusn
  7  in(2,3,6,8);

  KTUXEUSN   KTUXESLT   KTUXESQN STATUS           FLAGS
---------- ---------- ---------- ---------------- ------------------------
         2         38     583286 PREPARED         SCO|COL|REV|DEAD|EXTDTX
         3         29     982959 PREPARED         SCO|COL|REV|DEAD|EXTDTX
         6         14     945326 PREPARED         SCO|COL|REV|DEAD|EXTDTX
         8          7     957413 PREPARED         SCO|COL|REV|DEAD|EXTDTX
SQL> select local_tran_id, state from dba_2pc_pending; 

LOCAL_TRAN_ID          STATE
---------------------- ----------------
14.28.100017           collecting
2.38.583286            prepared
8.7.957413             prepared
3.29.982959            prepared
6.14.945326            prepared
13.19.507098           prepared

6 rows selected.

SQL>

通过上面的结果,看到2、3、6、8号回滚段上有活动的事务。该文档依然指出解决方案是查看Note 401302.1文档,而该文档又无法打开,不得已Google之,参照 http://blog.itpub.net/post/38439/477038  获得解决问题的最终方法。 

5 根据http://blog.itpub.net/post/38439/477038 直接强制提交这些活动的分布式事务:

SQL> select local_tran_id, state from dba_2pc_pending; 

LOCAL_TRAN_ID          STATE
---------------------- ----------------
14.28.100017           collecting
2.38.583286            prepared
8.7.957413             prepared
3.29.982959            prepared
6.14.945326            prepared
13.19.507098           prepared

6 rows selected.

SQL> commit force '2.38.583286';

Commit complete.

SQL> select local_tran_id, state from dba_2pc_pending; 

LOCAL_TRAN_ID          STATE
---------------------- ----------------
14.28.100017           collecting
2.38.583286            forced commit
8.7.957413             prepared
3.29.982959            prepared
6.14.945326            prepared
13.19.507098           prepared

6 rows selected.

SQL> commit force '8.7.957413';

Commit complete.

SQL> commit force '3.29.982959';

Commit complete.

SQL> commit force '6.14.945326';

Commit complete.

SQL> commit force '13.19.507098';

Commit complete.

SQL> select local_tran_id, state from dba_2pc_pending; 

LOCAL_TRAN_ID          STATE
---------------------- ----------------
14.28.100017           collecting
2.38.583286            forced commit
8.7.957413             forced commit
3.29.982959            forced commit
6.14.945326            forced commit
13.19.507098           forced commit

6 rows selected.

SQL> Select segment_id,segment_name,status,tablespace_name           
  2  from dba_rollback_segs where status not in ('ONLINE','OFFLINE');

no rows selected

SQL> SELECT KTUXEUSN, KTUXESLT, KTUXESQN, /* Transaction ID */ 
  2  KTUXESTA Status,                                          
  3  KTUXECFL Flags                                            
  4  FROM x$ktuxe                                              
  5  WHERE ktuxesta!='INACTIVE'                                
  6  AND ktuxeusn                                              
  7  in(2,3,6,8);                                              

no rows selected

SQL> drop tablespace undotbs1 including contents and datafiles;

Tablespace dropped.

SQL> 

6 终于干掉了那个旧的UNDO,而此时,alert日志里的信息如下:

Fri Feb 10 15:08:16 CST 2012
DISTRIB TRAN 44444444.D7D4863A714B974489CD48496956271900000000
  is local tran 2.38.583286 (hex=02.26.8e676)
  change pending prepared tran, scn=125560421 (hex=0.077be665)
  to     pending forced commit tran, scn= (hex=0.00000000) 
Fri Feb 10 15:08:56 CST 2012
DISTRIB TRAN 44444444.D88A6D59B486E44D8BAD8DABFDCF289C00000000
  is local tran 8.7.957413 (hex=08.07.e9be5)
  change pending prepared tran, scn=194136242 (hex=0.0b9248b2)
  to     pending forced commit tran, scn= (hex=0.00000000) 
Fri Feb 10 15:09:08 CST 2012
DISTRIB TRAN 44444444.4A67F0F3F3EA464081883577EE646AAB00000000
  is local tran 3.29.982959 (hex=03.1d.effaf)
  change pending prepared tran, scn=195270309 (hex=0.0ba396a5)
  to     pending forced commit tran, scn= (hex=0.00000000) 
Fri Feb 10 15:09:20 CST 2012
DISTRIB TRAN 44444444.97CB87A6BAE9E943B761C9C7FDA9844600000000
  is local tran 6.14.945326 (hex=06.0e.e6cae)
  change pending prepared tran, scn=196753377 (hex=0.0bba37e1)
  to     pending forced commit tran, scn= (hex=0.00000000) 
Fri Feb 10 15:09:36 CST 2012
DISTRIB TRAN 44444444.192AEFF6D316B2468F5D74FE5EBDC9EC00000000
  is local tran 13.19.507098 (hex=0d.13.7bcda)
  change pending prepared tran, scn=332059676 (hex=0.13cad41c)
  to     pending forced commit tran, scn= (hex=0.00000000) 
Fri Feb 10 15:13:17 CST 2012
drop tablespace undotbs1 including contents and datafiles
Fri Feb 10 15:13:25 CST 2012
Deleted Oracle managed file +ORADATA/glndb/datafile/undotbs1.261.726057859
Completed: drop tablespace undotbs1 including contents and datafiles

7 总结:对于分布式事务,目前还不是很清楚。而这个案例中涉及到的情况还有可能出现更为复杂的情况,需要深入研究一下,而我遇到的这种情况属于比较简单的。

删除用户报ORA-24005错误及解决办法

在一套10.2.0.5.0的双节点RAC数据库上,删除用户时报出ORA-00604及ORA-24005的错误:

 
SQL> conn / as sysdba;
Connected.
SQL> select * from v$version;
BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bi
PL/SQL Release 10.2.0.5.0 - Production
CORE    10.2.0.5.0      Production
TNS for Linux: Version 10.2.0.5.0 - Production
NLSRTL Version 10.2.0.5.0 - Production
SQL> drop user gdhytest cascade;
drop user gdhytest cascade
*
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-24005: must use DBMS_AQADM.DROP_QUEUE_TABLE to drop queue tables
SQL> 

后经查找MetaLink:Ora-24005 Error Trying To Drop User Sysman Cascade [ID 456437.1] 找到原因:被删除的用户ghhytest拥有queue table。

 
SQL> set pagesize 100 
SQL> col object_name format a40 
SQL> select object_name,object_type from dba_objects
  2  where owner='GDHYTEST' AND OBJECT_NAME LIKE '%AQ%'
  3  ;
OBJECT_NAME                              OBJECT_TYPE
---------------------------------------- -------------------
AQ$_GPSSTATUS_QUEUE_TABLE_H              TABLE
AQ$_GPSSTATUS_QUEUE_TABLE_I              TABLE
AQ$_GPSSTATUS_QUEUE_TABLE_NR             TABLE
AQ$_GPSSTATUS_QUEUE_TABLE_T              TABLE
AQ$_GPS_TEMP_QUEUE_TABLE_NR              TABLE
SQL>

解决方法:

1 gdhytest登录数据库,执行DBMS_AQADM.DROP_QUEUE_TABLE进行删除queue talbe:

 
SQL> conn gdhytest/gdhytest
Connected.
SQL> exec DBMS_AQADM.DROP_QUEUE_TABLE(queue_table=>'AQ$_GPSSTATUS_QUEUE_TABLE_H',
force=>true);
BEGIN DBMS_AQADM.DROP_QUEUE_TABLE(queue_table=>'AQ$_GPSSTATUS_QUEUE_TABLE_H',
force=>true); END;
      *
ERROR at line 1:
ORA-06550: line 1, column 7:
PLS-00201: identifier 'DBMS_AQADM' must be declared
ORA-06550: line 1, column 7:
PL/SQL: Statement ignored

2 发现权限不够,赋权,重新删除:

 
SQL> conn / as sysdba;
Connected.
SQL> grant dba to gdhytest;
Grant succeeded.
SQL> conn gdhytest/gdhytest
Connected.
SQL> exec DBMS_AQADM.DROP_QUEUE_TABLE(queue_table=>'AQ$_GPSSTATUS_QUEUE_TABLE_H',
force=>true);
BEGIN DBMS_AQADM.DROP_QUEUE_TABLE(queue_table=>'AQ$_GPSSTATUS_QUEUE_TABLE_H',
force=>true); END;
*
ERROR at line 1:
ORA-24019: identifier for QUEUE_TABLE too long, should not be greater than 24
characters
ORA-06512: at "SYS.DBMS_AQADM_SYS", line 4310
ORA-06512: at "SYS.DBMS_AQADM", line 197
ORA-06512: at line 1
SQL> exec DBMS_AQADM.DROP_QUEUE_TABLE(queue_table=>'GPSSTATUS_QUEUE_TABLE_H',
force=>true);
BEGIN DBMS_AQADM.DROP_QUEUE_TABLE(queue_table=>'GPSSTATUS_QUEUE_TABLE_H',
force=>true); END;
*
ERROR at line 1:
ORA-24002: QUEUE_TABLE GDHYTEST.GPSSTATUS_QUEUE_TABLE_H does not exist
ORA-06512: at "SYS.DBMS_AQADM_SYS", line 4310
ORA-06512: at "SYS.DBMS_AQADM", line 197
ORA-06512: at line 1

3 依然报错!!!QUEUE_TABLE too long,不得已,重命名queue table进行删除:

 
SQL> rename  AQ$_GPSSTATUS_QUEUE_TABLE_H to queue1;
Table renamed.
SQL> select * from tab;
TNAME                          TABTYPE  CLUSTERID
------------------------------ ------- ----------
AQ$_GPSSTATUS_QUEUE_TABLE_I    TABLE
SYS_IOT_OVER_60452             TABLE
AQ$_GPSSTATUS_QUEUE_TABLE_NR   TABLE
AQ$_GPSSTATUS_QUEUE_TABLE_T    TABLE
SYS_IOT_OVER_60459             TABLE
AQ$_GPS_TEMP_QUEUE_TABLE_NR    TABLE
QUEUE1                         TABLE
7 rows selected.
SQL> exec DBMS_AQADM.DROP_QUEUE_TABLE(queue_table=>'QUEUE1',force=>true);
PL/SQL procedure successfully completed.
SQL> select * from tab;
TNAME                          TABTYPE  CLUSTERID
------------------------------ ------- ----------
AQ$_GPSSTATUS_QUEUE_TABLE_I    TABLE
SYS_IOT_OVER_60452             TABLE
AQ$_GPSSTATUS_QUEUE_TABLE_NR   TABLE
AQ$_GPSSTATUS_QUEUE_TABLE_T    TABLE
SYS_IOT_OVER_60459             TABLE
AQ$_GPS_TEMP_QUEUE_TABLE_NR    TABLE
6 rows selected.
SQL> 
4 如法炮制,重命名其它queue table,然后执行删除:
 
SQL> rename AQ$_GPSSTATUS_QUEUE_TABLE_I to queue_a;
Table renamed.
SQL> rename AQ$_GPSSTATUS_QUEUE_TABLE_NR to queue_b;
Table renamed.
SQL> rename AQ$_GPSSTATUS_QUEUE_TABLE_T to queue_c;
Table renamed.
SQL> rename aq$_GPS_TEMP_QUEUE_TABLE_NR to queue_d;
Table renamed.
SQL> select * from tab;
TNAME                          TABTYPE  CLUSTERID
------------------------------ ------- ----------
SYS_IOT_OVER_60452             TABLE
SYS_IOT_OVER_60459             TABLE
QUEUE_B                        TABLE
QUEUE_A                        TABLE
QUEUE_C                        TABLE
QUEUE_D                        TABLE
6 rows selected.
SQL> exec DBMS_AQADM.DROP_QUEUE_TABLE(queue_table=>'QUEUE_A',force=>true);
PL/SQL procedure successfully completed.
SQL> exec DBMS_AQADM.DROP_QUEUE_TABLE(queue_table=>'QUEUE_B',force=>true);
PL/SQL procedure successfully completed.
SQL> exec DBMS_AQADM.DROP_QUEUE_TABLE(queue_table=>'QUEUE_C',force=>true);
PL/SQL procedure successfully completed.
SQL> exec DBMS_AQADM.DROP_QUEUE_TABLE(queue_table=>'QUEUE_D',force=>true);
PL/SQL procedure successfully completed.
SQL> select * from tab;
no rows selected

5 最后彻底删除gdhytest用户:

 
SQL> conn / as sysdba;
Connected.
SQL> drop user gdhytest cascade;
User dropped.
SQL> 

调试存储过程:ORA-0131 Insufficient privileges 处理

昨天,一开发同事反映说在PL/SQL Developer工具里无法调试存储过程,报错信息如下:

ORA-0131:Insufficient privileges.

Note:Debugging requires the DEBUG CONNECT SESSION system privileges.                                                                                                                                        

后经查找,是缺失  DEBUG CONNECT SESSION 系统权限所致。

解决办法:以SYS用户登录数据库,执行赋权操作:

SQL> grant  DEBUG CONNECT SESSION to user_name;

附1:有网友指出还需赋予DEBUG ANY PROCEDURE的权限,经测试,该权限可不用赋予!

附2:可以从数据字典role_sys_privs表查看该权限相关信息:

SQL> conn / as sysdba;
Connected.
SQL> select * from role_sys_privs where privilege like 'DEBUG%' order by 2;
ROLE             PRIVILEGE                ADM
---------------- ------------------------ ---
DBA              DEBUG ANY PROCEDURE      YES
JAVADEBUGPRIV    DEBUG ANY PROCEDURE      NO
DBA              DEBUG CONNECT SESSION    YES
JAVADEBUGPRIV    DEBUG CONNECT SESSION    NO

简单记录,以作备忘!

知识还是点点记录好!

impdp ORA-31655错误处理一例

今天上午,收到开发同事发过来的邮件:

需要将从之前用EXPDP备份的dump文件中,将某张表还原到一个新的schema下。

电话沟通后,原来是想要将逻辑备份的dump文件中FR8_ZH这个用户下的SB_DATA_RIGHT,导入到同库下的FR8_TEST9这个schema下。

①  于是开始干活:

C:\Documents and Settings\Administrator>impdp directory=my_dump dumpfile=2012-01
-23.dmp logfile=fr8_test9.log remap_schema=fr8_zh:fr8_test9 tables=SB_DATA_RIGHT
Import: Release 10.2.0.5.0 - Production on 星期五, 03 2月, 2012 11:32:53
Copyright (c) 2003, 2007, Oracle.  All rights reserved.
用户名: sys/oracle as sysdba
连接到: Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

ORA-31655: 尚未为作业选择数据或元数据对象

已成功加载/卸载了主表 "SYS"."SYS_IMPORT_TABLE_01"

启动 "SYS"."SYS_IMPORT_TABLE_01":  sys/******** AS SYSDBA directory=my_dump dump
file=2012-01-23.dmp logfile=fr8_test9.log remap_schema=fr8_zh:fr8_test9 tables=S
B_DATA_RIGHT

作业 "SYS"."SYS_IMPORT_TABLE_01" 已于 11:33:19 成功完成

发现,报出ORA-31655的错误!!!

SQL> !oerr ora 31655

31655, 00000, "no data or metadata objects selected for job"

// *Cause:  After the job parameters and filters were applied,

//          the job specified by the user did not reference any objects.

// *Action: Verify that the mode of the job specified objects to be moved.

//          For command line clients, verify that the INCLUDE, EXCLUDE and

//          CONTENT parameters were correctly set.  For DBMS_DATAPUMP API

//          users, verify that the metadata filters, data filters, and

//          parameters that were supplied on the job were correctly set.
SQL>

而ORA-31655的错误是说,在导入数据的命令中,impdp没有找到正确的对象元数据。

②  加上INCLUDE关键字,重新执行导入:

 
C:\Documents and Settings\Administrator>impdp directory="my_dump" dumpfile=2012-
01-23.dmp logfile=fr8_test9.log remap_schema=fr8_zh:fr8_test9 tables=SB_DATA_RIG
HT include=table:\"like \'SB_DATA_RIGHT%\'\"
Import: Release 10.2.0.5.0 - Production on 星期五, 03 2月, 2012 11:36:35
Copyright (c) 2003, 2007, Oracle.  All rights reserved.
用户名: sys/oracle as sysdba
连接到: Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

ORA-31655: 尚未为作业选择数据或元数据对象
已成功加载/卸载了主表 "SYS"."SYS_IMPORT_TABLE_01"

启动 "SYS"."SYS_IMPORT_TABLE_01":  sys/******** AS SYSDBA directory=my_dump dump
file=2012-01-23.dmp logfile=fr8_test9.log remap_schema=fr8_zh:fr8_test9 tables=S
B_DATA_RIGHT include=table:"like \'SB_DATA_RIGHT%\'
"
作业 "SYS"."SYS_IMPORT_TABLE_01" 已于 11:37:02 成功完成

发现依然报ORA-31655的错误!

③ 不得已,查找Metalink,ORA-31655 On imdp As a Privileged User Wih INCLUDE= After Upgrade To 10.2.0.5/11.2 [ID 1225108.1] 得到下述的解决办法:

Applies to:

Oracle Server – Enterprise Edition – Version: 10.2.0.5 and later   [Release: 10.2 and later ]
Oracle Server – Enterprise Edition – Version: 11.2.0.1.0 to 11.2.0.2.0   [Release: 11.2 to 11.2]
Information in this document applies to any platform.

 

Symptoms

Datapump import raises an ORA-31655 “no data or metadata objects selected for job” on import when using the REMAP_SCHEMA and INCLUDE= clauses when performed as a privileged user (i.e. a user with the IMP_FULL_DATABASE role).

Changes

The database has been upgraded to 10.2.0.5 or 11.2.

Cause

This is intended behavior and occurs due to the fix for bug:6831823 which went in to 11.2 and 10.2.0.5.

The ORA-31655 error is now signaled following the fix for bug:6831823, as that bug which existed in previous versions meant that if a privileged user performed a table import from a full export dump, and the specified table name existed in multiple schemas, then all the tables would be imported where as only the table for the importing user should have been imported, as documented in the Oracle� Database Utilities 10g Release 2 (10.2) manual, chapter 3 ‘Data Pump Import’, under the definition of the TABLES= clause, which states “If you do not supply a schema_name, it defaults to that of the current user”.  This also applies to the INCLUDE= clause, and hence the error is now raised.

Documentation bug:10140472 has been created to get this more clearly stated under the INCLUDE and REMAP_SCHEMA options in future documentation sets.

Solution

Perform the import using the TABLES= clause rather than the INCLUDE=TABLE: clause, e.g.:

 

Change From:

impdp system directory=data_pump_dir dumpfile=scott.dmp remap_schema=scott:scott_test include=TABLE:\”IN \(\’EMP\’, \’DEP\’\)\”

To:

impdp system directory=data_pump_dir dumpfile=scott.dmp remap_schema=scott:scott_test tables=SCOTT.EMP,SCOTT.DEPT

or 

impdp scott directory=data_pump_dir dumpfile=scott.dmp remap_schema=scott:scott_test include=TABLE:\”IN \(\’EMP\’, \’DEPT\’\)\” 

找到问题的原因后,执行下述命令重新导入成功!

 
C:\Documents and Settings\Administrator>impdp directory="my_dump" dumpfile=2012-
01-23.dmp logfile=fr8_test9.log remap_schema=fr8_zh:fr8_test9 tables=fr8_zh.sb_d
ata_right
Import: Release 10.2.0.5.0 - Production on 星期五, 03 2月, 2012 11:48:02
Copyright (c) 2003, 2007, Oracle.  All rights reserved.
用户名: sys/oracle as sysdba
连接到: Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

已成功加载/卸载了主表 "SYS"."SYS_IMPORT_TABLE_01"
启动 "SYS"."SYS_IMPORT_TABLE_01":  sys/******** AS SYSDBA directory=my_dump dump
file=2012-01-23.dmp logfile=fr8_test9.log remap_schema=fr8_zh:fr8_test9 tables=f
r8_zh.sb_data_right

处理对象类型 SCHEMA_EXPORT/TABLE/TABLE

处理对象类型 SCHEMA_EXPORT/TABLE/TABLE_DATA

. . 导入了 "FR8_TEST9"."SB_DATA_RIGHT"                 5.328 MB    4484 行

处理对象类型 SCHEMA_EXPORT/TABLE/INDEX/INDEX

处理对象类型 SCHEMA_EXPORT/TABLE/CONSTRAINT/CONSTRAINT

处理对象类型 SCHEMA_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICS

处理对象类型 SCHEMA_EXPORT/TABLE/COMMENT

处理对象类型 SCHEMA_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS

作业 "SYS"."SYS_IMPORT_TABLE_01" 已于 11:48:49 成功完成

最后,登录数据库后,检查FR8_TEST9用户下的SB_DATA_RIGHT表中的数据,发现一切正常。

解决ORA-12516错误一则

在上周五晚上通宵加班将一套10.2.0.5.0的Linux 虚拟机环境下的数据量为260GB 的双节点RAC数据库顺利迁移至一台物理机器的开发数据库后,这两天开发的同事反映说连不上物理机开发库了。

起初,我也没有太在意,的确是因为这两天公司内部网络不太正常,ping物理开发库延时比较严重,偶有timed out现象,就一直以为是网络的问题了。直到中午的时候,同事说网络基本正常了,用PL/SQL Developer客户端工具连数据库的时候报出Ora-12516的错误,这才引起了我的注意!

上Metalink查了一下,看了“Troubleshooting Guide TNS-12519 TNS-12516 ORA-12519 ORA-12516 [ID 552765.1]”的文章后,才知道了自己迁移数据库后粗心大意犯下的错误。原来的RAC数据库中每个实例中都将process初始化参数都设置了400,sessions=445,而现在是单台数据库对外提供服务,导致会话数不够用,最终导致的Ora-12516的错误!其实,对于这种开发库而言,公司的开发同事并不多,怎么可能导致445个会话还不够连接使用呢?其实,造成问题的最根本原因是开发人员的应用程序中的连接池配置的有问题,连接数配置过高导致的!!!!

找到了问题的基本原因后,就将process初始化参数从400改为600,进而sessions自动被置为665,transactions参数自动置为731。然后,重启数据库。

        在oracle数据库的初始化参数中,有一类参数是推倒参数,其中:

        sessions=1.1*processes+5,transactions=1.1*sessions.

这样,问题得到了基本的解决。

事后,又出现了一些不痛不痒的问题。

这不,年后简单记录下发生在这个春节前的种种问题,及解决问题的方法:

① 会话数不够用,导致Ora-12516的错误。解决方法,加大process初始化参数,或者通知修改应用程序中的连接数;

② 通过在数据库端配置profile来控制每个会话的活动时间,过期由数据库自动断开会话;

③ 通过使用共享服务器模式来控制数据库服务器端的进程资源;

④ 最头大的问题就是,有个开发的同事将自己PC机器的IP地址设置了同数据库服务器相同的IP地址,导致其他开发人员一直连接不上数据库!!!这个问题可不是第一次遇见,解决办法,协同网络管理员将数据库服务器IP绑定到MAC。

 

其实,这本来是去年春节前遇到的一则案例,后来由于太忙,赶着要回家,于是拖到了今天才发布出来!

Oracle OCP考试1z0-007系列2:学会使用WHERE和ORDER BY从句

继上篇日志,Oracle OCP考试1z0-007系列1:学会使用基本的SQL语句后,本篇是系列2,学会使用WHERE和ORDER BY从句。 本篇是1z0-007课程的第二章,主要内容: 1 学会使用WHERE从句从结果集中过滤数据; 2 学会使用ORDER BY从句对结果集进行排序。 本篇内容比较简单,只涉及到WHERE从句和ORDER BY从句两个知识点。 附:具体文档和讲义。

Oracle OCP考试1z0-007系列1:学会使用基本的SQL语句

在上一篇博文里提到Oracle OCP考试1z0-007考试的题库。从本篇开始,将带来Oracle OCP 1z0-007考试的相关文档和资料。

本篇是1z0-007课程的第一章,主要内容:
1 学会使用基本的SQL语句;
2 了解SQL语句的功能;
3 学会如何执行基本的SQL语句
4 了解SQL语句与iSQL*PLUS命令的差别

附:下述是具体文档和讲义。

Oracle OCP考试1z0-007题库

有不少学习Oracle的同学,或者是已经从事Oracle DBA相关工作的职场人士,都想通过Oracle官方考试,获取OCP证书,从而提高自己的技能、含金量。

然而,拥有Oracle OCP证书并不能代表您的Oracle技能水平就与众不同,但是至少对于新入行的DBA来说,证书至少是敲门砖。相比之下,拥有证书的DBA也应该更受雇主青睐。即使,目前市面上到处飘着的都是Oracle OCP,随手一抓就是一大把,我想,我们绝对不可以只做Paper DBA,我们每一个通过自己认真看书、学习、总结、实践,通过自身不断努力,凭借硬实力,而非背题库,最终顺利获取OCP证书的过来人来讲,证书对于我们还是有意义的,即使它只是一张纸而已!

好了,不过多堆砌文字了,奉上经典的Oracle 9i 1z0-007考试的题库,希望可以对即将准备OCP考试的网友们有益。

How to resolve ksvcreate: Process(m000) creation failed

在一套10.2.0.1.0的一主一备dataguard测试环境中,physical standby database的告警日志文件里,经常报出下述错误信息:

Thu Dec  1 08:47:59 2011
alter database open
Thu Dec  1 08:48:00 2011
SMON: enabling cache recovery
Thu Dec  1 08:48:06 2011
Physical standby database opened for read only access.
Completed: alter database open
Thu Dec  1 08:48:11 2011
ksvcreate: Process(m000) creation failed
Thu Dec  1 08:48:38 2011
ksvcreate: Process(m000) creation failed
Thu Dec  1 08:49:38 2011
ksvcreate: Process(m000) creation failed
Thu Dec  1 08:50:39 2011
ksvcreate: Process(m000) creation failed
Thu Dec  1 08:51:39 2011
ksvcreate: Process(m000) creation failed
Thu Dec  1 08:52:39 2011
ksvcreate: Process(m000) creation failed
Thu Dec  1 08:53:39 2011
ksvcreate: Process(m000) creation failed
Thu Dec  1 08:54:39 2011
ksvcreate: Process(m000) creation failed
Thu Dec  1 08:55:39 2011
ksvcreate: Process(m000) creation failed
Thu Dec  1 08:56:39 2011
ksvcreate: Process(m000) creation failed
Thu Dec  1 08:57:39 2011
ksvcreate: Process(m000) creation failed
Thu Dec  1 08:58:40 2011
ksvcreate: Process(m000) creation failed
Thu Dec  1 08:59:40 2011
ksvcreate: Process(m000) creation failed
Thu Dec  1 09:00:40 2011
ksvcreate: Process(m000) creation failed
Thu Dec  1 09:01:41 2011
ksvcreate: Process(m000) creation failed
Thu Dec  1 09:02:41 2011
ksvcreate: Process(m000) creation failed

后经查找MetaLink:
‘Ksvcreate: Process(m000) creation failed’ after Standby Database Open Read Only Multiple Times [ID 418553.1]

Applies to:

Oracle Server – Enterprise Edition – Version: 10.2.0.1 to 10.2.0.1 – Release: 10.2 to 10.2
Information in this document applies to any platform.
***Checked for relevance on 15-APR-2011***
Symptoms

Switching a Physical Standby Database multiple to READ ONLY Mode will report the following Errors in the ALERT.LOG:

ksvcreate: Process(m000) creation failed

Changes

Switch Physical Standby from READ ONLY to apply and back to READ ONLY.
Cause

The Cause of this Problem has been identified in Bug 5583049.
Solution

There are two Workarounds available:
Restart the Instance..
or
Disable ADDM – Should be re-enabled if Standby takes up the Primary Role
* Set SGA_TARGET=0 and set shared_pool_size, db_cache_size, etc if using
Automatic SGA Memory Management (ASMM)

* Set STATISTICS_LEVEL=BASIC to disable statistics gathering
References

BUG:5583049 – ‘KSVCREATE: PROCESS(M000) CREATION FAILED’ AFTER STANDBY OPEN RO MULTIPLE TIMES

原来是oracle在10g上的bug,原因是physical standby database在没有完全关闭的情况下多次以read only方式打开。照着Oracle给出的解决方案1,重启Physical standby实例,暂且规避了该错误信息