在 Dataguard 环境中诊断 SQLNET 错误

在 Dataguard 环境中诊断 SQLNET 错误

在 Data Guard 环境中数据库之间是通过 Oracle Net 连接的（SQLNET/Database Networking）。 以下面的环境为例： Primary db_unique_name=chicago Standby db_unique_name=boston 连接别名以及在 Data Guard 配置中的主库以及备库的 service 为： chicago = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS=(PROTOCOL= TCP)(HOST=prmy-scan)(PORT = 1521)) ) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = chicago) ) ) boston = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS=(PROTOCOL = TCP)(HOST=stby-scan)(PORT = 1521)) ) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = boston) ) ) 在配置中最好的 service 就是使用默认的 DB_UNIQUE_NAME，因为默认情况下，数据库动态注册到 Listener 的 service 就是 DB_UNIQUE_NAME，所以不需要做额外的配置。在这里使用的 service 不能是可以被集群软件(Oracle Restart, RAC One Node or RAC)动态管理的 service，也就是不能使用通过 srvctl 配置的 service。更多关于在 Oracle Data Guard Redo 传输以及 Broker 连接中使用什么数据库 service 的信息请参考文档 (Doc ID 1937089.1)。 如果在 Data Guard 环境中没有按照最佳实践来配置 SQLNET，那么可能会碰到下面提到的问题： - 传输不工作 - 下面的语句的结果中 error 列显示各种不同的值： SELECT thread#, dest_id, gvad.status, error, fail_sequence  FROM gv$archive_dest gvad, gv$instance gvi  WHERE gvad.inst_id = gvi.inst_id AND destination is NOT NULL ORDER BY thread#, dest_id; - 在备库端 RFS 不工作 - 等待接收主库日志，日志应用 hang 住 要解决这些问题，第一步需要先在有问题的机器上执行下面的语句来确认是否 sqlplus 连接是成功的： tnsping <net_service_name> sqlplus sys@<net_service_name> as sysdba 如果 sqlplus 连接成功了，那么根据错误的不同可以参照下面的步骤来 debug： 1. Errors: ORA-01033: ORACLE initialization or shutdown in progress ORA-01034: ORACLE not available ORA-01089: immediate shutdown in progress - no operations are permitted 诊断步骤： a. 确认 TNS 别名的 CONNECT_DATA 部分包含了 SERVICE_NAME（而不是 SID）。 b. 确认使用的是动态注册，而不是静态注册。确认 listener.ora 文件的 SERVICE_NAME 没有出现在任何 SID_LIST_LISTENER 参数中。 c. 如果有的话，删除静态注册并且重启/reload listener。 d. 如果使用的是 12c 的版本并且使用了集群，确认在 CRS 里配置了密码文件。 e. (UR=A) 没有配置。 参考： Add Standby Database To Data Guard Configuration Returns ORA-01033 (Doc ID 2133681.1) Failover Connections for Data Guard Error with ORA-1033 (Doc ID 461874.1) Data guard Switchover Via Broker Fails With ORA-12523/ORA-12518(Doc ID 2150384.1)  OERR: ORA-1089 "immediate shutdown or close in progress - no operations are permitted" (varies by version) Reference Note(Doc ID 18663.1)  OERR: ORA-1034 "ORACLE not available" Reference Note(Doc ID 18625.1) 2. ORA-12154 Error (Doc ID 114085.1) 按照文档 RFS Is not coming up on standby Due to ORA-12154 on transport (primary side)(Doc ID 2196182.1)中的步骤一步步来解决这个错误。在修正后，大部分情况下可以通过杀掉主库的 archive 进程来解决问题，有时也需要重启主库的数据库/实例。 3. ORA-12514: listener could not resolve SERVICE_NAME given in connect descriptor 这个错误在下面的 note 中有描述：OERR: ORA-12514 / TNS-12514 "TNS:listener does not currently know of service requested in connect descriptor" (varies by version) Reference Note (Doc ID 71924.1) 以及 TNS-12514 Unable to connect to RAC database using SCAN name(Doc ID 1459768.1). 在 switchover 时出现这个错误是正常的，因为 PMON/LREG 进程需要花一些时间来动态注册 service 到 listener 上。如果 sqlplus 连接是正常的，而这个错误一直显示在上面的语句的 error 列，那么需要重启主库实例。 4. 下面的错误一般是由于防火墙的一些特性引起的： TNS/ORA-12592 TNS:bad packet TNS/ORA-12170 with "nt secondary err code:" TNS/ORA-12152 TNS:unable to send break message ORA-12570: TNS:packet reader failure ORA-3113/ORA-3135/ORA-3111 需要和网络管理员一起确保下面的防火墙的功能是关闭的： SQLNet fixup protocol Deep Packet Inspection (DPI) SQLNet packet inspection SQL Fixup SQL ALG (Juniper firewall) 功能的名字根据防火墙提供商的不同而有区别，但是有些网络数据包会受到影响（并不是所有的网络数据包）。有些防火墙会对某些特定的 SQL 包的传输有影响（再次申明，仅对某些有影响而不是全部的数据包）。 参考文档： Document 1286376.1 Fatal NI Connect Error 12170, 'TNS-12535: TNS:operation timed out' Reported in 11g Alert Log Document 257650.1 Resolving Problems with Connection Idle Timeout With Firewall Document 21505.1 OERR: ORA-12592 / TNS-12592 "TNS:bad packet" Reference Note Document 373431.1 Troubleshooting guide for ORA-12592 / TNS-12592: TNS: bad packet Document 550103.1 Log Shipment Between Primary and Standby Intermittently Errors with ORA-12570 Document 739522.1 ORA - 03135 : Connection Lost Contact While Shipping from Primary Server to Standby server Document 1130523.1 Logs are not shipped to the physical standby database