歡迎光臨
每天分享高質量文章

DBASK資料庫提問平臺問題集萃,首批近二十位專家團曝光

引言


最近註意到19C官方檔案中部分檢視已經沒有了說明,MOS上很多檔案也隱藏了起來,開源公司不斷被資本收購,但是我們始終嚮往構建一個開放開源、互幫互助的社群環境,我們也再不斷為之努力,平臺上運維工具免費使用,資源共享下載,舉辦線上線下的活動,就在一個月前我們推出了DBASK資料庫提問平臺(點選“閱讀原文”,馬上提問題),當您遇到任何資料庫疑難雜症都可在DBASK提問,平臺認證專家免費線上解答。我們還開放了專家整理歸檔的知識庫,供您免費學習和搜尋排錯。

小程式的釋出可以讓大家隨時隨地提問,專家也可在小程式內即時回覆,減少了提問的門檻,加快問題互動的流程。另外可以在微信小程式中瀏覽知識庫,方便查詢學習相關問題。

使用指導


  1. 微信小程式搜尋DBASK,或微信直接掃描下方小程式碼;
  2. 首次進入需要微信授權,系結手機號;
  3. 熱門問題 – 瀏覽學習專家歸檔的熱門問答(可增加評論);
  4. 提交問題 – 輸入問題描述和詳情快速提交問題;
  5. 我的問題 – 檢視我提交的問題,更新問題(可上傳圖片);
  6. 專家回覆問題後,會在微信內通知使用者;
  7. 新增到“我的小程式“,問答更方便。

     

常駐專家團


蓋國強(Eygle)

Oracle ACE Director

張樂奕(Kamus)

Oracle ACE Director

李軼楠(ORA-600)

Oracle ACE 

楊廷琨(Yangtingkun)

Oracle ACE Director,Oracle百科全書

熊軍

Oracle ACE Director

侯聖文

Oracle ACE Director,OCM聯盟創始人

Joel

Oracle ACE Director

李真旭(Roger)

Oracle ACE,精通開源資料庫(MySQL,MongoDB等)

羅海雄

Oracle ACEA 

張維照

Oracle ACE

薑勁松 擅長Oracle和SQL Server的效能最佳化和故障診斷
李華 擅長效能最佳化和各種疑難雜症處理
懷曉明 Troubleshooting,資料庫、Web設計、開發,精於故障診斷和處理

劉偉

開源資料庫(MySQL、PostgreSQL等)、分散式資料庫資深研究員

崔虎龍

MySQL技術顧問,擅長MySQL、Redis、MongoDB設計、故障處理、恢復、升級最佳化等

……

 

接下來,我們分享本期整理出的精彩問答,供大家參考學習,防患於未然。

問題一、安裝Grid執行root.sh報錯ORA-27504


問題描述:

在centos7.4 64bit上安裝oracle 12.2的grid執行root.sh報錯如下:

ASM failed to start. Check /grid/app/grid/grid_base/cfgtoollogs/asmca/asmca-181205AM124153.log for details.2018/12/05 13:42:18 CLSRSC-184: Configuration of ASM failed2018/12/05 13:42:20 CLSRSC-258: Failed to configure and start ASMDied at /grid/app/grid/grid_home/crs/install/crsinstall.pm line 2091.The command '/grid/app/grid/grid_home/perl/bin/perl -I/grid/app/grid/grid_home/perl/lib -I/grid/app/grid/grid_home/crs/install /grid/app/grid/grid_home/crs/install/rootcrs.pl ' execution failed
[root@crm-db1 ~]#[main] [ 2018-12-05 02:22:57.058 EST ] [UsmcaLogger.logException:186]  SEVERE:method oracle.sysman.assistants.usmca.backend.USMInstance:configureLocalASM[main] [ 2018-12-05 02:22:57.058 EST ] [UsmcaLogger.logException:187]  ORA-27504: IPC error creating OSD context[main] [ 2018-12-05 02:22:57.058 EST ] [UsmcaLogger.logException:188]  oracle.sysman.assistants.util.sqlEngine.SQLFatalErrorException: ORA-27504: IPC error creating OSD context
(左右滑動檢視完整程式碼,下同)

專家解答:

透過對dmp檔案仔細檢查發現在執行root.sh時檢測到ens3f0:1沒有插網線,然後直接報錯ORA-27504,非常隱蔽。

 

可以嘗試透過引數_disable_interface_checking = true再執行root.sh

問題二、XD上Oracle使用者無法登入


問題描述:

Linux上作業系統 就算輸入了正確的密碼也不能登入 是有哪個配置檔案決定?

其他幾個節點oracle使用者可以正常登入,某個節點oracle不能直接登入,用root改了密碼也不行

 

專家解答:

這種限制預設在exadata上開啟的,輸錯一次密碼以後,此使用者被鎖10分鐘;

檢視錯誤次數:

pam_tally2 --user oracle

重置登入錯誤

pam_tally2 --user oracle --reset

過10分鐘以後再登入,並且輸入正確的密碼。

將/etc/pam.d/sshd 和 /etc/pam.d/login這兩個檔案中的lock_time條目移除。即將auth required pam_tally2.so deny=5 onerr=fail lock_time=600修改為auth required pam_tally2.so deny=5 onerr=fail

問題三、RAC環境下啟動實體報錯ORA-01157


問題描述:

伺服器未知原因故障恢復後,啟動資料庫實體報錯,錯誤資訊如下:

ALTER DATABASE OPEN /* db agent *//* {2:38813:23181} */This instance was first to openFri Mar 01 10:00:41 2019Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\orcl\orcl2\trace\dbw0_5844.trc:ORA-01157: ????/?????? 11 - ??? DBWR ????ORA-01110: ???? 11: 'D:\APP\ADMINISTRATOR\PRODUCT\11.2.0\DBHOME_1\DATABASE\X.DBF'ORA-27041: ??????OSD-04002: ÎÞ·¨´ò¿ªÎļþO/S-Error: (OS 2) ϵͳÕÒ²»µ½Ö¸¶¨µÄÎļþ¡£Abort recovery for domain 0

專家解答

從報錯看,這個是一個本地資料檔案’D:\APP\ADMINISTRATOR\PRODUCT\11.2.0\DBHOME_1\DATABASE\X.DBF’,應該是你們將RAC中的資料庫檔案誤建到本地磁碟,所以其他實體無法啟動,導致錯誤。

 

處理方法:

1. 將此資料檔案離線,實體可以馬上拉起,然後將此資料檔案移動到共享儲存,視資料檔案大小會有一定時間不能讀寫;

2. 使用rman copy到共享儲存中,離線做一次switch datafile to copy,不可用讀寫時間更小。但是完成遷移後實體才能拉起。

問題四、並行查詢時禁用直接路徑讀


問題描述:

針對11g以及後面的版本的oracle資料庫,設定了_serial_direct_read引數為never,禁用了direct path read,但是加了並行時設定的引數失效了,同樣會走direct path read。

 

我的問題是有沒有辦法進行控制,讓業務陳述句使用並行,不走direct path read,而是走db file scatt read全表掃描呢?

 

專家解答:

 

偶爾走走direct path read也還好,前段時間我們還特意把一個job強置direct path read

ALTER SESSION SET EVENTS '10949 TRACE NAME CONTEXT off';alter session set events 'trace[NSMTIO] disk=medium';alter session set "_very_large_object_threshold"=1;alter session set "_small_table_threshold"=1;alter session set "_serial_direct_read"=always;alter session set "_direct_read_decision_statistics_driven"=false;

 

一般透過設定10949事件,再結合_small_table_threshold、_very_large_object_threshold兩個引數就完全禁用直接路徑了

 

問題五、登入失敗使用者被鎖


 

問題描述:

Oracle 11G使用者登入失敗,資料庫大量library cache lock等待事件,隨後使用者被鎖。

 

問題解答:

這種使用者被鎖的情況可能由如下3個因素引起:

 

1. 11G密碼延遲驗證新特性

在 Oracle 11g 中,為了提升安全性,Oracle 引入了『密碼延遲驗證』的新特性。這個特性的作用是,如果使用者輸入了錯誤的密碼嘗試登入,那麼隨著登入錯誤次數的增加,每次登入前驗證的時間也會增加,以此減緩可能對於資料庫重覆的口令嘗試攻擊。

 

但是對於正常的系統,由於口令的更改,可能存在某些被遺漏的客戶端,不斷重覆嘗試,從而引起資料庫內部長時間的 Library Cache Lock的等待,這種情形非常常見。

 

如果遇到這一類問題,可以透過Event 28401關閉這個特性,從而消除此類影響,以下命令將修改設定在引數檔案中:

ALTER SYSTEM SET EVENT = '28401 TRACE NAME CONTEXT FOREVER, LEVEL 1' SCOPE = SPFILE;

2. 11G登入區分大小寫新特性

在11g之前,密碼不區分大小寫,如果是從之前的老版本升級到11g,可能會遇到這個問題,可以將SEC_CASE_SENSITIVE_LOGON引數修改為FALSE不區分大小寫,也可以修改應用的連線密碼。

 

3. 預設登入失敗過多鎖定賬號

使用者預設的profile中FAILED_LOGIN_ATTEMPTS為10,也就是用錯誤密碼嘗試登陸10次,就會鎖定賬戶,可以透過修改引數避免使用者被鎖定(有可能存在用錯誤密碼惡意攻擊的情況)

alter profile default limit FAILED_LOGIN_ATTEMPTS UNLIMITED;

 

問題六、刪除的分割槽能夠透過Flashback進行閃回嗎?


 

問題描述:

透過DROP 刪除的分割槽,能夠透過 Flashback Drop 閃回嗎?

 

專家解答:

在Oracle資料庫中,單個刪除的分割槽並不會進入回收站,全表刪除的分割槽才可能和全表一起放入回收站。這是因為單個分割槽刪除之後,是無法透過簡單的閃回加入原分割槽表中,既然無法保證一致性,這個分割槽就不會進入回收站中。

 

以下這個測試展示了這個過程:


SQL> select * from v$version;BANNER           CON_ID-------------------------------------------------------------------------------- ----------Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production   0PL/SQL Release 12.2.0.1.0 - Production        0CORE 12.2.0.1.0 Production         0TNS for Linux: Version 12.2.0.1.0 - Production       0NLSRTL Version 12.2.0.1.0 - Production        0
SQL> CREATE TABLE enmotech (2 PartID  integer  not null,3 CretTm  date  not null,4 PartCD  varchar2(2) not null5 ) partition by list (partcd) automatic (6 partition pBJ values ('BJ'),7 partition pCD values ('CD'),8 partition pGZ values ('GZ'),9 partition pSH values ('SH')10 );Table created.
SQL> insert into enmotech values (1, sysdate, 'KM');1 row created.
SQL> select partition_name from user_tab_partitions2 where table_name = 'ENMOTECH';PARTITION_NAME--------------------------------------------------------------------PBJPCDPGZPSHSYS_P281
SQL> alter table enmotech drop partition SYS_P281 purge;alter table enmotech drop partition SYS_P281 purge*ERROR at line 1:ORA-14048: a partition maintenance operation may not be combined with other operations
SQL> alter table enmotech drop partition PSH;Table altered.
SQL> select * from user_recyclebin;no rows selected
SQL> drop table enmotech;Table dropped.
SQL> select object_name,original_name,type from user_recyclebin;OBJECT_NAME     ORIGINAL_NAME  TYPE---------------------------------------- -------------------- -------------------------BIN$TflQLiTmWX7gUwo4qMBX+A==$0   ENMOTECH  TABLEBIN$TflQLiTmWX7gUwo4qMBX+A==$0   ENMOTECH  Table PartitionBIN$TflQLiTmWX7gUwo4qMBX+A==$0   ENMOTECH  Table PartitionBIN$TflQLiTmWX7gUwo4qMBX+A==$0   ENMOTECH  Table PartitionBIN$TflQLiTmWX7gUwo4qMBX+A==$0   ENMOTECH  Table Partition

 

很多時候,想當然的結果可能並不可信,實踐操作方能出真知,多動手,是技術人的王道。

 

問題七:ORA-15025:could not open disk unable to open file


問題描述:

系統昨天下午5點報ORA-15025 could not open disk和ORA-27041 unable to open file,經排查,是因為/bin/oracle的group不正確導致。

 

客戶的資料庫版本是11.2.0.4 for Solairs,半年內沒有做過任何改動。

 

請教大家:沒有人為原因,系統未做變化,還有什麼情況會導致oracle二進位制檔案的group發生變化?

 

問題解答:

這種檔案許可權變更排除人為因素後,一般都是安裝補丁引起。

檢視bin/oracle檔案上次修改時間為2018年8月17日:

 

 

上次打補丁的時間也是這個時間:

Patch  18740837     : applied on Fri Aug 17 18:53:49 CST 2018Unique Patch ID:  20360406   Created on 18 Jul 2016, 18:56:51 hrs UTC   Bugs fixed:     18740837

所以這個屬組應該是打補丁時被修改了,現在才報錯的原因可能如下:

1. 新連線才會報錯,

2. 透過Oracle使用者啟動的listener連過來會報錯,透過grid使用者啟動的listener連過來不會報錯。

 

問題八:資料檔案處於recover狀態ORA-00376

問題描述:

告警日誌中出現ORA-00376,檢視檔案處於ercover狀態,請問怎麼處理,為什麼會出現這樣的情況?

ORA-12012: error on auto execute of job 4ORA-00376: file 1084 cannot be read at this timeORA-01110: data file 1084: '/dev/vx/rdsk/dg_ora_4adb/vol_ora_4adb_dev1089' --datafile in recover modesys >select name,status from v$datafile where name like '/dev/vx/rdsk/dg_ora_4adb/vol_ora_4adb_dev108%';NAME STATUS----------------------------------------------- -------/dev/vx/rdsk/dg_ora_4adb/vol_ora_4adb_dev1089 RECOVER

 

專家解答:

直接recover並online資料檔案即可:


sys >recover datafile 1084;Media recovery complete.sys >select name,status  from v$datafile where ts#=1;NAME-------------------------------------STATUS-------/dev/vx/rdsk/dg_ora_4adb/vol_ora_4adb_dev1089OFFLINE sys >alter database datafile 1084 online;Database altered. sys >select name,status  from v$datafile where ts#=1;NAME                                                                             STATUS-------------------------------------------------------------------------------- -------/dev/vx/rdsk/dg_ora_4adb/vol_ora_4adb_dev1089                                    ONLINE

 

另外,關於資料檔案處於recover樣式的原因一般有以下幾種:

1. 不正確的方式開啟資料檔案,或者突然關閉資料檔案

2. 作業系統故障

3. 由於病毒、惡意軟體、人為因素導致

4. 硬體故障、軟體bug導致資料檔案損壞

5. 資料庫開啟時網路突然斷開或者中斷

 

想看更多精彩問答,歡迎關註“DBASK”小程式,你也有機會成為專家團的一員!

    已同步到看一看
    贊(0)

    分享創造快樂