DG5—— 實體邏輯搭建錯誤處理

1、tnsping 不通

我遇到這個問題很簡單：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

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:

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 *

-rw-r----- 1 oracle oinstall 1249792 Sep 6 11:28 1_218_724504451.dbf

total 387116

從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=

(ADDRESS = (PROTOCOL = TCP)(HOST = standbydb )(PORT = 1521))

三. 問題解決

修改備庫伺服器的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

log_archive_dest_2 string service=standby mandatory reop

en=60

SQL>ALTER SYSTEM SET log_archive_dest_2='' SCOPE=BOTH;

[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

Thread 1 advanced to log sequence 221 (LGWR switch)

Current log# 1 seq# 221 mem# 0: /oradata/gridctl/redo01.log

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的值忘了改，還是原來資料庫的那個。改成新的那個，馬上就好了。。長姿勢了。。