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的值忘了改，还是原来数据库的那个。改成新的那个，马上就好了。。长姿势了。。
