DG5 | 您所在的位置:网站首页 › ora-16009 › DG5 |
1、tnsping 不通 首先我们来详细了解一下tnsping这个命令的使用:http://blog.csdn.net/changyanmanman/article/details/7439632 我遇到这个问题很简单:ORA-12560: TNS: 协议适配器错误 造成ORA-12560: TNS: 协议适配器错误的问题的原因有三个: 1.监听服务没有起起来。windows平台个一如下操作:开始---程序---管理工具---服务,打开服务面板,启动oraclehome92TNSlistener服务。 (我自己测试了下,在redhat5.0下,服务器端,如果关闭了listener监听:执行:lsnrctl stop ==>结果在客户端报tns-12541:no listener错误;继续测试,在服务器端,打开防火墙:service iptables start ==>这下子报了tns-12560:TNS:protocol adapter error。关闭防火墙:service iptables stop,又可以tnsping通了,这个是一个很小的地方,但是如果你忘了关闭,那就像我一样憋了2天才弄出来。。。) 2.database instance没有起起来。windows平台如下操作:开始---程序---管理工具---服务,打开服务面板,启动oracleserviceXXXX,XXXX就是你的database SID. (这个我自己测试了下,shutdown immediate数据库,一样可以tnsping通。。) 3.注册表问题。regedit,然后进入HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\HOME0将该环境变量ORACLE_SID设置为XXXX,XXXX就是你的database SID.或者右几我的电脑,属性--高级--环境变量---系统变量--新建,变量名=oracle_sid,变量值=XXXX,XXXX就是你的database SID.或者进入sqlplus前,在command line下输set oracle_sid=XXXX,XXXX就是你的database SID. 经过以上步骤,就可以解决问题。 ==================================================================================================== ORA-12500:TNS:监听程序无法启动专用服务器进程或ORA-12560:TNS:协议适配器错误 原因:ORACLE的数据库服务没有启动。使用命令net start ORACLESERVICEORADB(ORADB为数据库名字)即可。如果仍没有解决,请继续向下看。 如果数据库服务启动失败,则很有可能是其注册表项值损坏,最好的做法是以下两步: 1)ORADIM -DELETE -SID oradb 删除数据库服务项 2)ORADIM -NEW -SID oradb 新增数据库服务项 注:这个过程中如果出错,就重启计算机! ORA-12154:TNS:能解析服务名 原因:ORACLE的网络服务名没有正确配置。请使用“Net8 Configuration Assistant”工具向导之“本地网络服务名配置”配置TNS即可。如果仍没有解决,请继续向下看。 ORA-1034 :TNS:ORACLE不可用 原因:ORACLE的数据库服务正确启动,但是数据库没有打开! 使用命令: 1)svrmgrl 启动服务管理器 2)connect internal 以internal身份登陆 3)startup 打开数据库 ORA-12560:TNS:协议适配器错误(顽固性的) 原因:未知。 解决:必杀技--打开“Windows任务管理器”,杀死ORACLE.exe及ORADIM.exe进程,书写自己的 ora_startup.bat,执行之! PS: 1、我的ora_startup.bat: net start OracleOraHome81TNSListener net start ORACLESERVICEORADB svrmgrl 一般情况下不用,不过有时少不了它的,具体步骤见第5步。 2、我的ora_shutdown.bat: net stop OracleOraHome81TNSListener net stop ORACLESERVICEORADB ORACLE_HOME=/u01/app/oracle/product/8.1.6 export ORACLE_HOME/ 包括Oracle软件的目录 / LD_LIBRARY_PATH=/u01/app/oracle/product/8.1.6/lib; export LD_LIBRARY_PATH ORACLE_BASE=/u01/app/oracle export ORACLE_BASE/ 包括Oracle软件的目录和管理软件的目录 / ORACLE_SID=ORCL export ORACLE_SID/ 缺省数据库的标识 / ORACLE_TERM=vt100 export ORACLE_TERM ORA_NLS33=/u01/app/oracle/product/8.1.6/ ocommon/nls/admin/data export ORA_NLS33 / 语言支持 / PATH=$PATH: /u01/app/oracle/product/8.1.6/bin export PATH 2、DataGuard切换报ora-16009 一. 问题描述 在做oracle data-guard的切换测试时,将生产环境切换到备库服务器上后,进行了日志的切换,这时发现,日志文件是复制到了主库服务器(此时数据库的角色为standby database)的相关目录,当没有得到正常的应用,在主库服务器的alert日志中报"ORA-16009: remote archive log destination must be a STANDBY database"错误; ORACLE 对错误的描述为: $ oerr ora 16009 16009, 00000, "remote archive log destination must be a STANDBY database" // *Cause: The database associated with the archive log destination service // name is other than the required STANDBY type database. // Remote archival of redo log files is not allowed to non-STANDBY // database instances. // *Action: Take the necessary steps to create the required compatible STANDBY // database before retrying the ARCHIVE LOG processing. 二. 问题分析 主库服务器的hostname为:primarydb,备库服务器的hostname为:standbydb 数据库生产环境原来是运行在primarydb上,现在已经通过切换命令,完成了生产环境从主库服务器切换到备库服务器。在备库服务器(数据库角色为primary),进行日志切换时,发现日志文件已经拷贝到主库服务器的相关目录,但在应用日志时报了ora-16009的错误,具体的日志描述如下: [oracle@primarydb bdump]$ tail -f alert_gridctl.log 。。。。。。 Media Recovery Log /oradata/archivelog/standby_arc/1_219_724504451.dbf Media Recovery Waiting for thread 1 sequence 220 Mon Sep 6 11:33:16 2010 Errors in file /oracle/admin/gridctl/bdump/gridctl_arc1_15207.trc: ORA-16009: remote archive log destination must be a STANDBY database Mon Sep 6 11:33:16 2010 PING[ARC1]: Heartbeat failed to connect to standby 'standby'. Error is 16009. 。。。。。。 [oracle@standbydb bdump]$ tail -f alert_gridctl.log Errors in file /oracle/admin/gridctl/udump/gridctl_rfs_24014.trc: ORA-16009: remote archive log destination must be a STANDBY database Redo Shipping Client Connected as PUBLIC -- Connected User is Valid RFS[9]: Assigned to RFS process 24049 RFS[9]: Database mount ID mismatch [0xc95dd6eb:0xc95e148e] RFS[9]: Client instance is standby database instead of primary RFS[9]: Not using real application clusters Mon Sep 6 11:36:16 2010 [oracle@primarydb archivelog]$ ls -lt * standby_arc: -rw-r----- 1 oracle oinstall 119808 Sep 6 11:32 1_219_724504451.dbf -rw-r----- 1 oracle oinstall 1249792 Sep 6 11:30 1_218_724504451.dbf primary_arc: total 484140 -rw-r----- 1 oracle oinstall 15872 Sep 6 11:14 1_217_724504451.dbf -rw-r----- 1 oracle oinstall 49836032 Sep 6 11:14 1_216_724504451.dbf -rw-r----- 1 oracle oinstall 98818048 Sep 5 23:32 1_215_724504451.dbf -rw-r----- 1 oracle oinstall 99174912 Sep 5 02:15 1_214_724504451.dbf [oracle@standbydb archivelog]$ ls -lt * primary_arc: -rw-r----- 1 oracle oinstall 119808 Sep 6 11:32 1_219_724504451.dbf -rw-r----- 1 oracle oinstall 1249792 Sep 6 11:28 1_218_724504451.dbf standby_arc: total 387116 -rw-r----- 1 oracle oinstall 15872 Sep 6 11:14 1_217_724504451.dbf -rw-r----- 1 oracle oinstall 49836032 Sep 6 11:14 1_216_724504451.dbf -rw-r----- 1 oracle oinstall 98818048 Sep 5 23:32 1_215_724504451.dbf -rw-r----- 1 oracle oinstall 99174912 Sep 5 02:15 1_214_724504451.dbf 从alert日志文件中,发现:"PING[ARC1]: Heartbeat failed to connect to standby 'standby'. Error is 16009",于是考虑是不是log_archive_dest_2的设置有问题,目前主库服务器的数据库角色已经转换为standby database,不需要设置归档日志的远程路径,所以考虑将这个参数置空。 主库,备库服务器的ORACLE 相关配置文件内容如下: [oracle@primarydb /]$ more /etc/hosts 168.0.3.92 primarydb 168.0.3.93 standbydb [oracle@primarydb /]$ more $ORACLE_HOME/network/admin/tnsnames.ora PRIMARY= (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = primarydb )(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = gridctl) ) ) STANDBY= (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = standbydb )(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = gridctl) ) ) 三. 问题解决 修改备库服务器的log_archive_dest_2,将归档日志指向主库服务器,同时修改主库服务器的log_archive_dest_2参数值为空. [oracle@standbydb /]$sqlplus / as sysdba SQL> show parameter log_archive_dest_2 NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ log_archive_dest_2 string SQL> alter system set log_archive_dest_2='service=primary mandatory reopen=60' scope=both; System altered. [oracle@primarydb /]$ sqlplus / as sysdba SQL> show parameter log_archive_dest_2 NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ log_archive_dest_2 string service=standby mandatory reop en=60 SQL>ALTER SYSTEM SET log_archive_dest_2='' SCOPE=BOTH; System altered. [oracle@standbydb /]$ sqlplus / as sysdba SQL>alter system switch logfile; 该参数修改完成后,在备库服务器上进行日志的切换,发现主库服务器的日志文件立即得到了应用,具体的过程可以通过alert日志查询到. [oracle@primarydb /]$ tail -f alert_gridctl.log ALTER SYSTEM SET log_archive_dest_2='' SCOPE=BOTH; Mon Sep 6 11:38:35 2010 RFS[1]: Archived Log: '/oradata/archivelog/standby_arc/1_220_724504451.dbf' Mon Sep 6 11:38:39 2010 Media Recovery Log /oradata/archivelog/standby_arc/1_220_724504451.dbf Media Recovery Waiting for thread 1 sequence 221 Mon Sep 6 11:39:17 2010 RFS[2]: Archived Log: '/oradata/archivelog/standby_arc/1_221_724504451.dbf' Mon Sep 6 11:39:19 2010 Media Recovery Log /oradata/archivelog/standby_arc/1_221_724504451.dbf Media Recovery Waiting for thread 1 sequence 222 [oracle@primarydb /]$ tail -f alert_gridctl.log Thread 1 advanced to log sequence 221 (LGWR switch) Current log# 1 seq# 221 mem# 0: /oradata/gridctl/redo01.log Mon Sep 6 11:39:17 2010 Thread 1 advanced to log sequence 222 (LGWR switch) Current log# 2 seq# 222 mem# 0: /oradata/gridctl/redo02.log 正的的话到红色字体部分已经可以了,但是我的还不行,接着到$ORACLE_BASE/admin/mynew1/bdump/alert.mynew1.log 查看警报日志,发现已经没有16009错误了,但是出现了如下错误: 3、ora-12533:TNS:不合法的地址参数 这个问题不难,是我自己疏忽造成的,我找到sqlnet.ora 参数,发现了一个大问题,我的协议参数不是TCP,而是写了一个什么ICP什么的,估计当时是自己手误,所以,这个问题解决后,数据库的日志迅速的同步了。 4、重建数据库后总是引用原来的参数启动,查看进程时都是原来的oracle_sid 这个问题但是很纠结啊,明明已经删除了原来数据库的所有信息,可是当我用新建的pfile参数来创建spfile的时候,生成的spfile竟然是原来的那个数据库sid的spfile,这下盲目了。。去论坛问了下,原来是因为oracle用户下的环境变量.bash_profile里面的ORACLE_SID的值忘了改,还是原来数据库的那个。改成新的那个,马上就好了。。长姿势了。。 |
CopyRight 2018-2019 实验室设备网 版权所有 |