DG5—— 物理逻辑搭建错误处理

74 阅读 0 评论 49 点赞

我是靠谱客的博主清脆小笼包，最近开发中收集的这篇文章主要介绍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_MACHINESOFTWAREORACLEHOME0将该环境变量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的值忘了改，还是原来数据库的那个。改成新的那个，马上就好了。。长姿势了。。