DBASK問答集萃第三期

引言
近期咱們在DBASK小程序增長了衆多專欄，其中包括蓋國強、楊廷琨、羅海雄、張樂奕、黃廷忠、崔華、熊軍、李真旭、何劍敏等專家欄目，還有2019年6月SCN兼容性問題、XTTS、備份恢復等技術專欄，另外螞蟻金服OceanBase入駐小程序。歡迎你們閱讀分享小程序中的專題欄目。

問答集萃
接下來，咱們分享本期整理出的問題和診斷總結，供你們參考學習，詳細的診斷分析過程能夠經過標題連接跳轉到小程序中查看。

問題1、RMAN-20039: format requires %c when duplexing

備份時報錯：

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of backup command
RMAN-20039: format requires %c when duplexing

備份數據文件不加%C就會報錯，加%C有兩份同樣的？

----備份腳本
run{ 
allocate channel c1 device type disk;
allocate channel c2 device type disk;
allocate channel c3 device type disk;
allocate channel c4 device type disk;
crosscheck backup;
sql 'alter system archive log current';
backup spfile format '/bak/backup/spfile_%T_%s_%p_%c';
#backup database format '/bak/backup/dbbk_0_%d_%t_%u_%s_%p';
backup as compressed backupset incremental level 0 database format '/bak/backup/dbbk_0_%d_%t_%u_%s_%p';
sql 'alter system archive log current';
backup archivelog all format '/bak/backup/arc_%T_%s_%p_%c' delete all input;
backup current controlfile format '/bak/backup/cntrl_%T_%s_%p_%c';
crosscheck archivelog all;
delete noprompt expired backup;
delete noprompt obsolete;

release channel c1;
release channel c2;
release channel c3;
release channel c4;
}

診斷結論：若是設置不冗餘就不須要加c%，不然就會出現你的報錯。若是設置了冗餘必須加%c，那麼也就會產生相應的備份片。

問題2、RAC實例沒法啓動ORA-01157 ORA-01110 ORA-27041 OSD-04002

服務器未知緣由故障恢復後，啓動數據庫實例報錯，錯誤信息以下：

ALTER DATABASE OPEN /* db agent *//* {2:38813:23181} */
This instance was first to open
Errors in file D:\APP\...\orcl2_ora_7780.trc:
ORA-01157: ????/?????? 11 - ??? DBWR ????
ORA-01110: ???? 11: 'D:\APP\...\NXPT.DBF'
ORA-1157 signalled during: ALTER DATABASE OPEN /* db agent *//* {2:38813:23181} */...
Fri Mar 01 10:00:59 2019
Shutting down instance (abort)
License high water mark = 2
USER (ospid: 13460): terminating the instance
Instance terminated by USER, pid = 13460
Fri Mar 01 10:01:16 2019
Instance shutdown complete
Fri Mar 01 10:34:34 2019

診斷結論：從報錯看，這個是一個本地數據文件

'D:\APP\ADMINISTRATOR\PRODUCT\11.2.0\DBHOME_1\DATABASE\NTBS.DBF'

應該是將RAC中的數據庫文件誤建到本地磁盤，因此其餘實例沒法啓動，致使錯誤。

問題3、Oracle 12.2 expdp 很是慢

我有一個12.2.0.1的庫，非容器單實例。使用expdp導出，導出文件總共不到4G，但要花將近6個小時。alert沒有任何報錯。新庫基本都是空的分區表。

診斷結論：請先嚐試收集系統、數據字典統計信息。另外能夠嘗試以下方法：
一、最小配置stream_pool_size最小到256M，可能的話設置512M或者1GB；
二、加大expdp的並行度，若是CPU壓力不大，能夠設置爲CPU核數的1半或更多；
三、EXCLUDE=GRANT exclude = statistic
四、METRICS=YES
五、若是導出停留在TABLE_DATA階段，而且上述處理無效，能夠打補丁Bug 28100495

問題4、RAC CTSS狀態觀察模式，時間不一樣步

2節點RAC，其中一臺物理故障。修復後RAC報CTSS狀態爲觀察模式，時間不一樣步

Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production 0

PL/SQL Release 12.2.0.1.0 - Production 0
CORE 12.2.0.1.0 Production 0
TNS for Linux: Version 12.2.0.1.0 - Production 0
NLSRTL Version 12.2.0.1.0 - Production 0
CPUs:56 Cores:28 Sockets:2
內存188.26G

診斷結論：CTSS狀態爲觀察模式一般是由於本地的NTP服務啓動了。因此能夠先檢查一下新修復的那臺服務器上是否是默認啓動了NTP。若是是，禁用掉一般就能夠了。

問題5、OGG-00665 OCI Error (status = 3114-ORA-03114）

OGG 同步序列，進程ABENDING，重啓進程問題仍然存在，數據庫正常，其餘ogg的進程正常，且排除掉該序列的同步後進程能夠正常啓動

2019-03-07 17:06:39  ERROR   OGG-00665 Oracle GoldenGate Delivery for Oracle, rptsqe.prm:  OCI Error describe for query
(status = 3114-ORA-03114: not connected to ORACLE), SQL<select status, deferrable from dba_constraints where owner =UPPER('BOSDATA') and table_name='TASK_SEQ' and constraint_type = 'P' >.
2019-03-07 17:06:39  ERROR   OGG-01668 Oracle GoldenGate Delivery for Oracle, rptsqe.prm:  PROCESS ABENDING.

診斷結論：
一、我昨天查了不少資料，有一個一樣的報錯，RAC環境，OGG版本也是11.2，不過是抽取進程，說是重啓集羣后問題消失，因此之後再遇到SEQ同步報錯了，能夠嘗試下。
二、有多是複製進程中的這個參數引發，或者未知BUG
DBOPTIONS _NOAUTOMATICSEQUENCEFLUSH
三、通常狀況下目標端不會使用sequence，因此能夠考慮排除全部SEQ的同步
四、升級OGG版本，至少12

問題6、數據庫大量殭屍進程未自動清理

數據庫出現客戶端鏈接不上，查看alert日誌

Wed Mar 13 09:21:50 2019
ORA-00020: No more process state objects available
ORA-20 errors will not be written to the alert log for
 the next minute. Please look at trace files to see all
 the ORA-20 errors.
Process J002 submission failed with error = 20
kkjcre1p: unable to spawn jobq slave process
Errors in file /export/home/u01/app/oracle/diag/rdbms///trace/_cjq0_25517.trc:

此時查看 v$process 爲738個進程，參數process進程數設置爲800.如下語句查詢結果爲380

select count(*) from v$process where addr not in (select paddr from v$session)；

殺掉這些進程，客戶端能夠正常鏈接。整體進程維持在400左右。
問題點：一、pmon爲什麼沒有清理掉這380個沒有會話的進程。二、是否有參數設置pmon清除殭屍進程的條件，好比空閒時間之類的。
診斷結論：通常kill session後會出現這種狀況，可是不會出現幾百個的狀況。首先請檢查是否存在頻繁kill session的操做，和應用創建鏈接、斷開鏈接的方式是否規範；其次，臨時將數據庫的process參數調高，避免應用出錯。最後，提供一個自動清理殭屍process的腳本。

問題7、oracle 10gR2 expdp報錯ORA-00376

expdp導出報錯

Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bit Production

With the Partitioning, OLAP and Data Mining options

ORA-39001: invalid argument value
ORA-00376: file 53 cannot be read at this time
ORA-01110: data file 53: '/oracle/oracle/oradata/xxx/xxx.dbf'

53號數據文件因爲硬件故障致使文件損壞，沒法修復。庫爲非歸當模式，因此將53號數據文件offline drop,將庫強制啓起來了。如今備份的時候報錯了，導出命令以下；

expdp user/passwd parfile=cfg_except_tables.cfg

cat  cfg_except_tables.cfg
EXCLUDE=TABLE
COMPRESSION=METADATA_ONLY
DIRECTORY=DPUMP_DIR1
DUMPFILE=auto_backup.dmp
LOGFILE=auto_backup.log

經過以下SQL查爲空，我把53號數據文件已經清空了，但仍是報上面的錯

select * from dba_extents where file_id=53

診斷結論：ASSM 管理模式下dba_extents是存放在數據文件中的，脫機文件是看不到對象的。由於你這種報錯說明53號文件仍是有對象存在的，原則上是能夠跳過這些對象導出正常的對象的，要確認53號的對象須要使用以下SQL。

問題8、oracle 10G 創建dblink 訪問9i的遠程庫執行sql很慢

oracle 10G 創建了dblink 鏈接9i 數據庫 執行了 select from table --table中只有兩條記錄 耗時 20s 兩臺服務器間網絡正常 再9i 直接執行sql 很快 還多是什麼緣由呢？查看等待事件爲 SQLNet message from dblink
診斷結論：是由於 10g 的服務器操做系統版本是 windows server 2012 從windows server 2008 之後 增長了 接收窗口自動調諧級別 功能致使，調整接收窗口自動調諧級別解決。

問題9、安裝rac，IO有什麼要求？
安裝rac，IO有什麼要求麼？參考過 rac安裝有最佳實踐,可是官方並無指出IO具體參考範圍（IOPS）。因此，想諮詢下，貴司有沒有針對RAC安裝對IO的要求或IO範圍參考值？我想對比下本身的存儲IO性能，看是否達標。
診斷結論：是由於 10g 的服務器操做系統版本是 windows server 2012 從windows server 2008 之後 增長了 接收窗口自動調諧級別 功能致使，調整接收窗口自動調諧級別解決。

問題10、雙機切換後TNS-12537 ORA-609
數據庫是Oracle，操做系統是Windows，高可用是rose雙機。把主服務器切換到備用服務器時，會出現程序鏈接不上，報錯以下：

可是切回來之後就正常了，通過查看日誌，發現以下報錯：

Fatal NI connect error 12537, connecting to:
 (LOCAL=NO)
  VERSION INFORMATION:
TNS for 64-bit Windows: Version 11.2.0.1.0 - Production
Oracle Bequeath NT Protocol Adapter for 64-bit Windows: Version 11.2.0.1.0 - Production
Windows NT TCP/IP NT Protocol Adapter for 64-bit Windows: Version 11.2.0.1.0 - Production
 Time: 12-3月 -2019 20:15:08
 Tracing not turned on.
 Tns error struct:
    ns main err code: 12537

TNS-12537: TNS: 鏈接關閉
    ns secondary err code: 12560
    nt main err code: 0
    nt secondary err code: 0
    nt OS err code: 0
opiodr aborting process unknown ospid (10796) as a result of ORA-609
Tue Mar 12 20:15:28 2019

請問是什麼緣由致使的呢？怎麼去解決這個問題呢
診斷結論：檢查雙機各自監聽日誌，發現節點監聽日誌4G，清空問題節點監聽日誌問題解決。

問題11、oracle 導入數據報ORA-39242錯誤
提示因爲表屬性緣由，沒法導入入成功

ORA-39242: Unable to export/import TABLE_DATA: … due to table attributes.

診斷結論：檢查表上面索引的狀態是否正常，若是不是VALID就作下rebuild再導入