數據庫常見告警、報錯與解決方法記錄

遇到的錯誤號,錯誤原因、處理方法及參考文檔小結

數據庫類型 報錯號 原因 參考 建議
Oracle ORA-609

The ORA-609 error is thrown when a client connection of any kind failed to complete or aborted the connection process before the connection/authentication process was complete.


Very often, this connection abort is due to a timeout.  Beginning with 10gR2, a default value for inbound connect timeout has been set at 60 seconds.  This time limit is often inadequate for the entire connection process to complete. 

文檔 ID 1116960.1

1.將SQLNET.INBOUND_CONNECT_TIMEOUT設爲120秒(默認60秒)應該能解決大多數ORA-609問題

2.如果該報錯發生在實例正在關閉時,可以忽略

Oracle ORA-46268: Conflicting operation on audit table(s) Session was interrupted by CTRL+C https://nazim-dba.blogspot.com/2018/06/error-sql-begin-dbmsauditmgmt.html 可忽略
Oracle

查看視圖相關sql執行計劃時報錯

ORA-01039: insufficient privileges on underlying objects of the view

用戶無視圖基表select權限

無,另外使用TKPROF EXPLAIN PLAN 時也可能遇到該報錯,參考 文檔 ID 1029064.6

授予視圖基表select權限
Oracle ORA-00700[kskvmstatact] 發生swap Doc ID 1919850.1 可忽略
Oracle

ORA-00600: [1433], [60], [], [], [], [], [], [], [], [], [], [] 導致數據庫宕機

----- Call Stack Trace -----
skdstdst <- ksedst <- dbkedDefDump <- ksedmp <- ksdxdmp
<- ksdxfdmp <- ksdxdocmdmultex <- 204 <- ksdxdocmdmult <- ksadms
<- ksbend <- ksadmp <- ksaamb <- ksasnd <- ksbasend
<- ksoreq_submit <- ksbsrv_opt <- ksvspawn <- ksvcreateex <- ksvcreate
<- kebm_mmon_schedule_ <- slave <- dbke_mmon_process_i <- ksb_run_managed_act <- ion
<- ksbcti <- ion <- ksbabs <- kebm_mmon_main <- ksbrdp
<- opirip <- opidrv <- sou2o <- opimai_real <- ssthrdmain
<- main <- libc_start_main <- start

命中Bug 13541842,Bug描述中並沒有記載觸發條件。後臺進程是Oracle進行調度的,很難確認具體在什麼情況下會觸發。

另外,從 Bug 13541842 的內容中並沒有找到DG相關的描述,所以這個問題不是DG特有的問題,是數據庫的問題。

這個問題發生在Oracle的進程間傳遞內部消息的動作上。當內部消息在message queue中找不到空閒緩衝的時候,
就會發生這個錯誤。可能與歸檔進程、mmon、dbwr進程或rac有關,遇到的情況是與MMON 進程有關,

故障發生過程:
DB遇到了Bug 13541842 -> 導致內部消息在message queue中找不到空閒緩衝 -> 導致ORA-00600 [1433],[60]報錯 -> DB宕機
 

Doc ID 13541842.8

數據庫掛了後一般可以直接startup

無workaround,需要打對應補丁13541842

Oracle

ORA-00600: [qerixSuspend:!miss]

 

Main Stack:

qerixSaveFetchState2 <- qertbSaveFetchState2 <- qerjoSaveMethod <- kcbpioqWillWaitForIO <- kcbgtcr <- kcbgtcr <- ktrget2 <- kdsgrp <- qetlbr <- qertbFetchByRowID <- qerjotRowProc <- qertbFetchByRowID <- qerjotFetch <- qerjotFetch <- qerjotFetch <- qerjotFetch <- qeruaFetch <- opifch2 <- opifch <- opiodr <- ttcpip <- opitsk <- opiino <- opiodr <- opidrv <- sou2o <- opimai_real <- ssthrdmain <- main

報錯sql執行計劃中使用了過多的NESTED LOOPS(沒查到限制值是多少)

 

Explain plan output shows that the query is using excessive NESTED LOOPS.  This resulted in this ORA-600[qerixSuspend:!miss] error.

文檔 ID 2389197.1

根本方法:優化sql

sql中可能使用了大量or條件(例如上百個),能否減少條件;使用NESTED LOOPS是否高效,能否用其他關聯方法

 

workaround

1.  At the session level:

alter session set "_nlj_batching_enabled"=0;

~or~

2.  At the query level(加hint):

/*+ opt_param('_nlj_batching_enabled',0) */

~or~

3.  At the system level:

alter system set "_nlj_batching_enabled"=0;

Oracle

ORA-00600 [733] [314572880] [top call heap]


Main Stack:
ksmarfg <- kghgex <- kghfnd <- kghalo <- kghgex <- kghfnd <- kghalo <- kghgrw <- msqapp <- msqfun
<- k2copnws <- msqopnws <- msqbin <- k2copnws <- msqopnws <- msqbin <- k2copnws <- msqopnws
<- msqbin <- k2copnws <- msqopnws <- msqbin <- k2copnws <- msqopnws <- msqbin <- k2copnws
<- msqopnws <- msqbin <- k2copnws <- msqopnws <- msqbin <- k2copnws <- msqopnws <- msqbin
<- k2copnws <- msqopnws <- msqbin <- k2copnws <- msqopnws <- msqbin <- k2copnws

Current SQL: select * from v$sql_plan where plan_hash_value='xxxx'

BUG 19846328 - ORA-00600 [733] [TOP CALL HEAP] WHILE SELECTING FROM V$SQL_PLAN
Status: 36 - Duplicate Bug


BUG 28741243 - FA QUERIES FAIL WITH EXPLAIN PLAN

Doc ID 19846328.8

Doc ID 28741243.8

workaround 

alter session set query_rewrite_enable = false;

或打對應補丁

Oracle

ORA-00600: [17113], [0x000000000]

 

Main Stack:
kgherror <- kghprmalo <- kghalp <- kksalc <- qksbgCreateCursorEnv <- qksbgGetCursorVal
<- kxsBindPeekEnabled <- kxsPeekBinds <- kkscsCompareBinds <- kksfbc <- opiexe <- kpoal8
<- opiodr <- ttcpip <- opitsk <- opiino <- opiodr <- opidrv <- sou2o <- opimai_real <- ssthrdmain
<- main

This appears to be a memory management problem in attempting to acquire a chunk of memory.

Select fails With ORA-600 [17113] ( Doc ID 1399120.1 ) Solution
==================
This should be treated similar to an ORA-4031 error.
  • Perform alter system flush shared_pool and retry the failing transaction.
  • Shutdown and startup of the database may also help.
  • Please check the available memory for the database instance and if possible increase the SGA or shared_pool_size.
Oracle

ORA-03170: deadlocked on readable physical standby (undo segment 401)

僅在從庫執行select count(*) from tmp_v類似語句查詢特定視圖時纔會報錯,重啓DB後依舊報錯

CALL STACK
============
skdstdst <- ksedst <- dbkedDefDump <- ksedmp <- dbkdaKsdActDriver
<- dbgdaExecuteAction <- dbgdaRunAction <- dbgdRunActions <- dbgdProcessEventAct <- ions
<- dbgdChkEventKgErr <- dbkdChkEventRdbmsEr <- ksfpec <- dbgePostErrorKGE <- 1063
<- dbkePostKGE_kgsf <- kgesev <- ksesec1 <- ktuGetUsegDba <- ktuGetCommitTimesMa
<- ktuGetCommitTimes <- ktrvgxct1 <- kdlw_locator_op_rea <- kdlw_locator_op <- kdlf_locator_op
<- koklCurrentDataInli <- koklglen2 <- ne <- koklglen <- kokle_l2be_intermed
<- iate <- kokle_l2be <- iate <- evaopn2 <- evaopn2
<- evareo <- expepr <- evaiand <- expeal <- kdstfRRRRRRRRRRRRRR
<- kmP <- kdsttgr <- kmP <- qertbFetch <- rwsfcd
<- qerlbFetch <- qerhjFetch <- rwsfcd <- qerhjFetch <- qersoProcessULS
<- qersoFetchSimple <- 1196 <- qersoFetch <- rwsfcd <- qerltFetch
<- insdlexe <- insExecStmtExecIniE <- ngine <- insexe <- ngine
<- qes3tExecSQL <- qerleStart <- rwsstd <- qergsStart <- selexe0
<- opiexe <- kpoal8 <- opiodr <- ttcpip <- opitsk
<- opiino <- opiodr <- opidrv <- sou2o <- opimai_real
<- ssthrdmain <- main <- libc_start_main <- start

命中 Bug 24578056

Bug 25883955 - QUERIES FAIL WITH ORA-3170 ON ACTIVE DATA GUARD --> Closed as Duplicate of Unpublished Bug 24578056

Queries Fail Intermittently With ORA-3170 On ADG ( Doc ID 2311894.1 )

1. upgrade your DB to DATABASE BUNDLE PATCH 12.1.0.2.190716

2. 打補丁 24578056

 

workaround

建議業務方將報錯sql移到主庫查詢

Oracle ORA-22921: length of input buffer is smaller than amount requested

there is no any known bug found, and
according other case, there is a workaround can solve this issue,
so please take following action to avoid this issue.

Action Plan
=================

SQL> alter system set "_report_capture_cycle_time"=0 scope=both sid='*‘;

無文檔,SR回覆

workaround

alter system set "_report_capture_cycle_time"=0 scope=both sid='*‘;

將該參數設爲0會禁用12c的"Automatic Report Capturing Feature"新特性,該新特性由MMON_SLAVE監控資源消耗高的sql並自動產生監控報告,禁用該新特性對DB無害。

Oracle

ORA-12516:TNS監聽程序找不到符合協議堆棧要求的可用處理程序

ORA-12516:TNS:listener could not find available handler with matching protocol stack

當前連接數超了最大連接數,登錄時會遇到ORA-00020 maximum number of processes (%s) exceeded報錯  

常規做法:

利用 lsnr_analyzer.pl 分析突增的連接來源並聯系業務方調整連接數。

緊急做法(難定位或需要快速恢復):

1. 停監聽 lsnrctl stop,等數據庫訪問連接數下降用戶再登錄;或者ps -ef |grep LOCAL=NO,kill掉幾個進程然後進去;或者ps -ef|grep LOCAL=NO|grep -v grep|cut -c 9-15|xargs kill -9,殺掉部分oracle連接

2. 登錄並改大processes參數,重啓數據庫

Oracle ORA-235

Concurrent update activity on a control file caused a process to read inconsistent information from the control file without a lock.

文檔 ID 2312580.1 可忽略
Oracle

grid中出現大量類似信息 

[OLOGGERD(9360)]CRS-8500: Oracle Clusterware OLOGGERD process is starting with operating system process ID 9360

Bug 24339991(內部文檔,無法查看)

Doc ID 2279733.1

SR 3-16292501171

以下workaround爲SR提供

root用戶執行

/u01/app/products/grid/12.1.0/bin/crsctl stop resource ora.crf -init
/u01/app/products/grid/12.1.0/bin/crsctl modify resource ora.crf -attr "AUTO_START=never" -init -unsupport

驗證方法
crsctls stat res ora.crf -t -init <<< This command should return: "OFFLINE/OFFLINE"
crsctl stat res ora.crf -p -init|grep AUTO_START <<< This command should return: never.

Oracle

[ORAAGENT(29527)]CRS-5818: Aborted command 'check' for resource 'ora.ractest.racsrv.svc'. Details at (:CRSAGF00113:) {0:25:2} in /.../crsd_oraagent_oracle.trc

[ORAAGENT(29527)]CRS-5832: Agent '/.../oraagent_oracle' was unable to process commands. Details at (:CRSAGF00128:) {1:17772:489} in /.../crsd_oraagent_oracle.trc

     
Oracle

ORA-07445: exception encountered: core dump [__intel_ssse3_rep_memcpy()+10272] [SIGSEGV] [ADDR:0x7F36575F2903] [PC:0x5A9AD50] [Address not mapped to object] [] 

Main Stack:
qerocConvertToSQL <- qerocPlsFetch <- qerocFetch <- kpofchswcbk <- rpiswu2 <- kpofrws
<- opifch2 <- kpoal8 <- opiodr <- ttcpip <- opitsk <- opiino <- opiodr <- opidrv <- sou2o
<- opimai_real <- ssthrdmain <- main

Bug 18191823 - Hang / ORA-600 [19708] etc.. referencing stale REFCURSOR bind Doc ID 18191823.8

1. Upgrade to 12.2.0.1 or apply 12.1.0.2.160719, where the bug is fixed.

2. Apply patch 18191823 -> to be able to suggest one, provide the output of 'opatch lsinventory -detail'. Copy/paste the output into a file and upload the file.

3. As a workaround, ensure the duration of the bound PL/SQL variable is at least as long as that of the ref cursor to which it is bound.

Oracle

ORA-07445: exception encountered: core dump [qerocPlsFetch()+117] [SIGSEGV] [ADDR:0x7F964F70FCC0] [PC:0xAA7BD45] [Invalid permissions for mapped object] []

Main Stack:
qerocPlsFetch <- qerocFetch <- kpofchswcbk <- rpiswu2 <- kpofrws <- opifch2 <- kpoal8
<- opiodr <- ttcpip <- opitsk <- opiino <- opiodr <- opidrv <- sou2o <- opimai_real <- ssthrdmain
<- main

Bug 18191823 - Hang / ORA-600 [19708] etc.. referencing stale REFCURSOR bind

有沒有發現雖然報錯不同,但是Main Stack和bug跟上面那個是一樣的

 

Doc ID 18191823.8

1. Upgrade to 12.2.0.1 or apply 12.1.0.2.160719, where the bug is fixed.

2. Apply patch 18191823 -> to be able to suggest one, provide the output of 'opatch lsinventory -detail'. Copy/paste the output into a file and upload the file.

3. As a workaround, ensure the duration of the bound PL/SQL variable is at least as long as that of the ref cursor to which it is bound.

Oracle

 

     
Oracle ORA-07286: sksagdi: cannot obtain device information *Cause:  Stat on the log archiving device failed.
無法進行歸檔或將歸檔發送至從庫
Doc ID 316281.1 找到無法歸檔的原因,一般在alter日誌中可以看到詳細報錯。可能是LOG_ARCHIVE_DEST設置錯誤、可能是主庫或從庫歸檔目錄(或FRA區)滿了,確定後具體處理
Oracle ORA-48913 MAX_DUMP_FILE_SIZE 設置過低,trace file寫滿 文檔 ID 1153040.1 視情況而定,可以加大MAX_DUMP_FILE_SIZE的值或將其設爲unlimited,如果夠大了可以忽略
Oracle ORA-3136 從 10.2.0.1 開始,參數 SQLNET.INBOUND_CONNECT_TIMEOUT 的默認設置是60秒。如果客戶端無法在60秒內進行身份驗證,警告將出現在警報日誌中,客戶端連接將被終止。 文檔 ID 2331569.1

通常需要在監聽器和數據庫中加大 INBOUND CONNECT TIMEOUT 的值。通常建議將數據庫(sqlnet.ora)值設置得稍微高於監聽器(listener.ora)

 

當oracle性能壓力過大時,也可能出現大量此報錯

Oracle ORA-01555 快照過舊  

檢查undo大小是否合理,如果合理通常是找到對應的SQL語句進行優化。

Oracle ORA-00028 session 被kill Doc ID 1230858.1 可忽略
Oracle ORA-12012: error on auto execute of job "SYS"."ORA$AT_OS_OPT_SY_38" Seed database was most likely not created right by package dbms_stats.init_package not being ran.  文檔 ID 2127675.1

sqlplus / as sysdba

EXEC dbms_stats.init_package();

oracle ORA-00600[pmuocon2#1:invalid magic number] 自定義匯聚函數bug Bug 21519686 - ORA-600 [pmuocon2#1: invalid magic num] from SQL using UDAG (used defined aggregate) (Doc ID 21519686.8)

以下選擇其一:

1.打patch 21519686

2.升級至12.2

3.修改隱含參數_odci_aggregate_save_space = true

oracle

ORA-00600:[qernsRowP], [1], [], [], [], [], [], [], [], [], [], []

可能是GROUP BY NOSORT hit中了Oracle的bug,但遇到的sql並不符合mos 文檔中bug的描述 ID 285913.1

 Alter session set events '10119 trace name context forever, level 1';

(注意在系統級別設置這個事件可能會對數據庫性能造成影響)

oracle ORA-1652

Failed to allocate an extent of the required number of blocks for a temporary segment in the tablespace indicated.

文檔 ID 1267351.1
NOTE:364417.1

增加tempfile或找出使用temp tablespace使用過量的語句,進行優化

 

oracle CRS-10001 ACFS-9203:true

ADVM/ACFS device drivers were installed/loaded.

oerr acfs 9203

可忽略
 oracle ORA-12751 
  • There is a database issue that prevents the slave action from completing on time
  • There is an issue related to how long the action being performed is taking such that it violates in internal run time policy (i.e. a run time policy violation). For example: A specific SQL or set of SQL statements in a particular thread of operation is taking too long to complete 
  • A thread of operation exceeds pre-determined CPU usage levels.

文檔 ID 761298.1

 

When encountering this issue, check for other database issues at the time and investigate those as they could be slowing the actions such that limits are exceeded.

If the database is generally performing slowly then investigate the cause of the slowness, if the database hangs then investigate the hang

oracle ORA-03137: TTC protocol internal error : [12333] [254] [64] [49] [] [] [] [] merge語句中綁定變量太長

一個綁定變量太長

ORA-3137[12333] on a MERGE Statement using a Bind Variable Larger than 1000 Bytes(文檔 ID 2307683.1)

 

兩個綁定變量太長

Merge or Insert is Failing with ORA-3137 [12333](文檔 ID 2039740.1)

一個綁定變量太長,可以選擇以下任一種解決方法:

  • 升級到18.1
  • 安裝補丁21616967
  • 將merge語句改寫爲insert或者update

兩個綁定變量太長:

修改merge語句,避免在sql語句中使用兩個太長的綁定變量

 oracle  ORA-01274: cannot add data file that was originally created as '/path/data01.dbf'

 Automated standby file management was disabled, so an added file could not automatically be created on the standby. 

 The error from the creation attempt is displayed in another message. The control file file entry for the file is 'UNNAMEDnnnnn'.

 文檔 ID 739618.1

 alter database create datafile '/oracle/product/GSIPRDGB/dbs/UNNAMED00210' as new;

ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=AUTO scope=both;

alter database recover managed standby database using current logfile disconnect;

oracle

ORA-00600: internal error code, arguments: [kcbgtcr_13], [], [], [], [], [], [], [], [], [], [], [] on ADG導致備庫hang死

----- Call Stack Trace -----

skdstdst <- ksedst1 <- ksedst <- dbkedDefDump <- ksedmp
<- ksfdmp <- dbgexPhaseII <- dbgexExplicitEndInc <- dbgeEndDDEInvocationImpl <- dbgeEndDDEInvocation
<- nImpl <- kcbgtcr <- kcbgcurstdby <- kcbgcur <- ktfbhget
<- ktfbfef <- qerfxFetch <- qerjotFetch <- qerjotFetch <- rwsfcd
<- qeruaFetch <- qervwFetch <- qerghFetch <- qervwFetch <- qersoProcessULS
<- qersoFetch <- qerjotFetch <- opifch2 <- kpoal8 <- opiodr
<- ttcpip <- opitsk <- opiino <- opiodr <- opidrv
<- sou2o <- opimai_real <- ssthrdmain <- main <- libc_start_main
<- start

命中Bug 18899974,在備庫上,對錶空間的元數據進行檢查時,通過調用kcbgcur()內部函數發生異常,SCN出現問題,備庫自身的SCN與主庫同步過來的SCN號不能達成一致。

 

Bug Symptoms:

- ORA-00600: internal error code, arguments: [kcbgtcr_13]
- Current SQL was selecting from SYS.DBA_TABLESPACES, SYS.DBA_DATA_FILES, SYS.DBA_FREE_SPACE, SYS.DBA_TEMP_FILES, GV$SORT_SEGMENT, SYS.TS$, V$PARAMETER for 'UNDO'
- The call stack matches
- This is not RAC specific and the problem can be manifested in non-RAC databases

Bug 18899974 - ORA-600 [kcbgtcr_13] on ADG for SPACE metadata blocks and UNDO blocks ( Doc ID 18899974.8 )

緊急處理方法

DBA重啓備庫。若hang死無法登錄,使用sqlplus -prelim。參考 https://blog.csdn.net/Hehuyi_In/article/details/89492911

 

文檔方法:

  • 升級到 12.2 版本
  • Apply patch 18899974
Oracle ORA-04030(koh-kghu sessi,pmuccst: adt/record) 單個進程使用內存超出4G(默認) Doc ID 1325100.1

DBA介入,找出消耗內存超過限制的進程。

可以修改以下參數將單個進程使用內存限制提高至16G

For versions 11.2.0.4 and lower:
_use_realfree_heap=TRUE
_realfree_heap_pagesize_hint = 262144

For 12.1 and higher:
_use_realfree_heap=TRUE
_realfree_heap_pagesize = 262144

Oracle ORA-00054: resource busy and acquire with NOWAIT specified or timeout expired

1.執行DML時,當要操作的數據已經被加鎖,這時在另一個回話中再次要取得這個對象的鎖時,新會話要麼被掛起,要麼拋出ORA-00054異常。


2.當DML在執行中,又同時在相同對象上執行DDL語句。比如Update操作的事務尚未提交,在另一個會話中開始執行表結構修改、變更索引的SQL時,也往往會出現ORA-00054異常。

文檔 ID 1945579.1

找出佔用資源的會話正在執行的語句,聯繫開發判斷能否kill掉釋放資源

Oracle

ORA-27300: OS system dependent operation:fork failed with status: 11
ORA-27301: OS failure message: Resource temporarily unavailable
ORA-27302: failure occurred at: skgpspawn5

The error messages indicating that oracle has problem in forking more process, the maximum number of PROCESSES allowed per user could be too low

Doc ID 392006.1

① 調整/etc/security/limits.conf 中ora用戶的nproc限制值

② 修改/etc/security/limits.d/90-nproc.conf配置,這是linux 6 中的新特性,在5中沒有該文件

RHEL6下引入了配置文件/etc/security/limits.d/90-nproc.conf
只有當使用*號讓全局用戶生效的時候,生效的nproc的值大小是受文件/etc/security/limits.d/90-nproc.conf中nproc值大小制約的,而如果僅僅是針對某個用戶,那麼就不受該文件nproc值大小的影響。

③ 重啓監聽,可以的話最好也重啓數據庫

Oracle

報錯與上面類似,但是原因不同

ORA-00603: ORACLE server session terminated by fatal error
ORA-27504: IPC error creating OSD context
ORA-27300: OS system dependent operation:sendmsg failed with status: 105
ORA-27301: OS failure message: No buffer space available
ORA-27302: failure occurred at: sskgxpsnd2

This happens due to less space available for network buffer reservation.

報錯信息說明udp buffer耗盡,需要增加udp buffer避免此問題發生

Oracle Linux: ORA-27301:OS Failure Message: No Buffer Space Available ( Doc ID 2041723.1 )

 

For udp buffer, oracle-rdbms-server-12cR1-preinstall requirement lower limits.
To avoid unnecessary UDP buffer overflow and 'gc cr multi block request' wait, we always suggest to set them to 4K:
Please refer to:
https://community.oracle.com/login.jspa?referer=https://community.oracle.com/message/12081569#12081569

disabled NUMA and increased MTU and UDP buffer

改法參考

https://blog.csdn.net/Hehuyi_In/article/details/89562117

 

UDP buffer是指:

net.core.rmem_default = 4194304
net.core.rmem_max = 4194304
net.core.wmem_default = 4194304
net.core.wmem_max = 4194304

Oracle ORA-07445: 出現異常錯誤: 核心轉儲 [qecinisub()+60] [SIGSEGV][ADDR:0x8A8] [PC:0xCCDF3
0C] [Address not mapped to object] []
hit中Oracle bug 21522416,該問題不一定會復現

Bug 21522416(內部文檔,無法訪問)

 alter system set optimizer_dynamic_sampling=0; 

若問題繼續出現,建議聯繫Oracle Support

Oracle

ORA-16401: archive log rejected by Remote File Server (RFS)

ORA-16055: FAL request rejected

主庫切換日誌過於頻繁 文檔 ID 1243177.1

1. Ignore these Messages as long as the Standby Database keeps synchronized with the Primary

2. Database Increase the Size of the Online Redologs to reduce Redolog Switch Frequency

3. Increase Network Bandwith between the Primary and Standby Database

Oracle ora-1882 occured when executing a select statement with dblink

Bug 16731148 ORA-1882 using TIMESTAMP literals over a database link

An unexpected ORA-1882 may be raised when using TIMESTAMP literals
across a database link connection if the NLS_NUMERIC_CHARACTERS setting
does not use a dot (".") as the decimal separator.

Doc ID 16731148.8

workaround

alter session set NLS_NUMERIC_CHARACTERS = ',.';
select timestamp '2012-07-24 07:00:00.00' from dual@somelink;

Oracle PRVG-1101 : SCAN name "cluscan.us.oracle.com" failed to resolve
PRVF-4664 : Found inconsistent name resolution entries for SCAN name "cluscan.us.oracle.com"
PRVF-4657 : Name resolution setup check for "scanclunm" (IP address: 10.4.0.202) failed

Cause 1. SCAN name is expected to be resolved by local hosts file instead of DNS or GNS

Cause 2. nslookup fails to find record for SCAN name

Cause 3. SCAN name is canonical name(CNAME record) in DNS

文檔 ID 887471.1 如果rac安裝時scan name 是通過hosts文件而非DNS或GNS解析,該報錯可忽略
Oracle ORA-04031: unable to allocate 65576 bytes of shared memory ("shared pool","unknown object","ktli log buf s","ktli log bufs")

一般ORA-04031錯誤可能由兩個原因引起:

1.內存中存在大量碎片,導致在分配內存的時候,沒有連續的內存可存放

2.   共享池容量不足

 

對於第一種原因,一般是需要在開發的角度上入手,比如增加綁定變量、縮短sql語句、減少硬解析來改善和避免

對於第二種,需要調整sga及shared_pool相關參數可能還需要擴大內存

Oracle ORA-00600: internal error code, arguments: [ktecgsc:objdchk_kcbgcur_3]

原因可能是truncate的併發或者速度太快,來不及將段頭的信息更新,就進行了CR(consistent read)校驗。這個校驗其實是不必要的。在11.2.0.3中進行了這個CR校驗,在11.2.0.4中就取消了。

SR 3-17769074971

文檔 ID 2101512.1

文檔 ID 2230425.1

文檔 ID 2101512.1

以下選擇其一:

  1. 升級至11.2.0.4或更高版本
  2. 安裝補丁15974138
Oracle ORA-02063: preceding 2 lines from MES  

https://blog.csdn.net/haiross/article/details/47275965

http://blog.itpub.net/27042095/viewspace-751953/

 
Oracle Ocssd.Bin Process Consumes 100% CPU in only one node of the RAC OneNode environment Bug 22986384 - OCSSD threads 7,8 and 13 are using large amount of cpu

Doc ID 22986384.8

安裝補丁 Patch 22986384 
Oracle

ora_m001_p+ process consumed high CPU

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
14932 oracle 20 0 5277220 329092 260452 R 100.0 2.0 0:29.17 ora_m001_p+
3852 root 20 0 1885036 34864 19104 S 2.0 0.2 437:20.36 ohasd.bin
5688 root 20 0 1050156 22068 14072 S 2.0 0.1 418:32.31 orarootage+
3978 root 20 0 1589596 56604 20016 S 1.0 0.4 199:10.02 orarootage+

命中bug 20636003

ORA-12751: "Cpu Time Or Run Time Policy Violation" Reported Due to DBMS_FEATURE_AWR Running Slow on 12c ( Doc ID 2095583.1 )

apply the patch 20636003

OR
A number of workarounds are available:

1)If a very high retention period is not needed, lower it to 14 days, or a week, to have less snapshots.


2)Disable Feature Usage Statistics 
alter system set "_swrf_mmon_dbfus"=false;

3)The problem query is recursive and is run as part of Dynamic Sampling Directives introduced in 12c (the /* DS_SVC */ comment identifies that this statement is from the SYS.DBMS_FEATURE_AWR package). These directives can be disabled while the Feature Usage Statistics remain enabled. In order that this expensive recursive query will not run anymore, Dynamic Sampling Directives can be disabled using the following command:
alter system set "_optimizer_dsdir_usage_control"=0;

Oracle ORA-00600: internal error code, arguments: [ktecgsc:objdchk_kcbgcur_3], [1654385], [4], [0], [0], [], [], [], [], [], [], []

從報錯信息看,大部分都是在報錯前執行了truncate語句。而truncate table的時候,表的object id不變,但是data object id是會變。

段頭中記錄的信息,和buffer cache中記錄的信息,由於某些原因不一致,導致校驗報錯了。

原因可能是truncate的併發或者速度太快,來不及將段頭的信息更新,就進行了CR(consistent read)校驗。這個校驗其實是不必要的。在11.2.0.3中進行了這個CR校驗,在11.2.0.4中就取消了。

SR 3-17769074971

安裝補丁 Patch 15974138: UNNECESSARY FORCE CR SEGMENT HEADER REQUEST
Oracle ORA-00904:"WM_CONCAT":標識符無效 12c中刪除了WM_CONCAT函數,改用LISTAGG代替 文檔 ID 2215183.1 改用LISTAGG代替
Oracle ORA-07445: 出現異常錯誤: 核心轉儲 [kghalp()+51] [SIGSEGV] [ADDR:0x7FC0FF4671DB] [PC:0xCD890C3] [Address not mapped to object] []  The error seems to be hit when allocating memory from the SQL Costing code as we have kkeutlCompHistActVals() -> qksshMemAllocPerm() 

Bug 21522416 - ORA-7445 [KGHALP()+51] [SIGSEGV]
SR 3-17358806271 : What caused ORA-07445:[kghalp()+51] [SIGSEGV] error

alter system set optimizer_dynamic_sampling=0; 

 

The parameter OPTIMIZER_DYNAMIC_SAMPLING controls the level of sampling performed by the optimizer. The only impact of setting it to 0 will be that at the run time (while an SQL is running), if there is a better plan available, it won't switch to the better plan, it will rather stick to the present plan. 

Oracle

ORA-07445: 出現異常錯誤: 核心轉儲 [kkeutlCompHistActVals()+235] [SIGSEGV] [ADDR:0x7FA39F33B968] [PC:0xCA87E9B] [Address not mapped to object] []

 

----- Call Stack Trace -----

skdstdst <- ksedst <- dbkedDefDump <- ksedmp <- ssexhd
<- sslsshandler <- sighandler <- kkeutlCompHistActVa <- kkeh1sl_Int <- ls
<- kkehsl_Int <- kkehslCursorMatch <- kkocsPredSel <- kkscsVerifyBindEqui <- vRP
<- kkscsVerifyBindEqui <- valence <- kkscsMatchEquivLite <- rals <- kkscsCompareBinds
<- kksfbc <- opiexe <- kpoal8 <- opiodr <- ttcpip
<- opitsk <- opiino <- opiodr <- opidrv <- sou2o
<- opimai_real <- ssthrdmain <- main <- libc_start_main <- start

報錯語句 "select ... decode(ma.iffreesample, 'Y', '是', 'N', '否') as ifFreeSample," 中有中文逗號,可能這個中文逗號實際上是有一些不可見字符,而不可見字符無法複製,所以在您那邊執行沒報錯而在sqlt採集重現時報錯是ora-0091

<<<一般中文逗號有可能會導致ORA-07445的報錯嗎?
如前所述,從call stack上看這是個解析時的報錯(kkscsCompareBinds、kkscsVerifyBindEquivalence、kkocsPredSel、kkehslCursorMatch這些都是跟綁定變量和謂詞選擇性相關的),而這個中文逗號前後的不可見字符會影響到sql解析,所以是有可能導致這個7445報錯的。

SR回覆:

這個ORA-07445的確沒有已知的bug相匹配,但是開bug的話也要經過嚴格審計,首先需要排除這個中文逗號的常規語法問題纔行。只能先建議您修正這個sql的語法問題再觀察是否還有ORA-07445[kkeutlCompHistActVals()+235]報錯。

修正中文逗號爲英文,並檢查前後是否有不可見字符。修改後的代碼已發版,目前暫時沒有遇到報錯。

Oracle

14:36:09

ORA-00600: internal error code, arguments: [pfri.c: pfri8: plio mismatch ], [], [], [], [], [], [], [], [], [], [], []
ORA-04061: existing state of package body "XXX" has been invalidated
ORA-04065: not executed, altered or dropped package body "XXX" 

15:00

ORA-07445: 出現異常錯誤: 核心轉儲 [kgmexec()+400] [SIGSEGV] [ADDR:0x30] [PC:0x93C9750] [Address not mapped to object] []

 

Error: ORA-600[pfri.c: pfri8: plio mismatch]/ORA-4061/ORA-4065
Main Stack:
pfri8_inst_spec <- pfri1_inst_spec <- pfrrun <- plsql_run <- pricar <- pricbr <- prient2
<- prient <- kkxrpc <- kporpc <- opiodr <- ttcpip <- opitsk <- opiino <- opiodr <- opidrv <- sou2o
<- opimai_real <- ssthrdmain <- main

 

Error: ORA-07445 [kgmexec()+400] [SIGSEGV] [ADDR:0x30] [PC:0x93C9750] [Address not mapped to object]
Main Stack:
kgmexec <- evapls <- evaopnc <- rpiswu2 <- evaopn2 <- qeruaRowProcedure <- qerjoFetch
<- rwsfcd <- qeruaFetch <- qersoProcessULS <- qersoFetch <- qervwFetch <- qercoFetch
<- opifch2 <- opifch <- opiodr <- ttcpip <- opitsk <- opiino <- opiodr <- opidrv <- sou2o
<- opimai_real <- ssthrdmain <- main

SR回覆:

They do not appear at the same time, I do not see them being related. It could be related to the invalid objects, but it's not the same issue.
Please compile the invalid objects, especially the ones under APPS schema and check if the ORA-07445 is still seen. If the error is still seen then it will have to be investigated separately.

 

the timeline is: package APPS.OE_ORDER_UTIL is invalid -> ORA-00600[pfri.c: pfri8: plio mismatch] -> recompilation of the invaild object -> library cache pin wait event

無相關文檔,SR回覆這兩個bug應無關聯,應與invalid objects相關

Seems that package "XXX" is invalid. Please recompile the package and try again.

alter package "XXX" compile;
alter package "XXX" compile body;

Oracle ORA-28040: 沒有匹配的驗證協議 9i clients are not supported with Oracle Database 12

文檔 ID 2111118.1

https://blog.csdn.net/ddd306/article/details/42805959

以下選擇其一:

1. 升級jdbc至11g或12c(官方文檔推薦)

2. 在sqlnet.ora文件的最後添加SQLNET.ALLOWED_LOGON_VERSION=8

Oracle ORA-08102:index key not found,obj#57848,file 6, block 6324(2)

ORA-08102這種錯誤說明索引或表出現了數據不一致的,索引上記錄的鍵值和表裏的數據不一致,引起訪問失敗

 

遇到的情況是在online創建索引過程中恰好碰上了CLEANUP_ONLINE_IND_BUILD job 運行。可能是online建索引的時候,會創建一些臨時extent,但是CLEANUP_ONLINE_IND_BUILD會清理掉。導致create index online雖然顯示是創建成功的,但是實際索引是有問題的。
後續查詢的時候,去找這些被job清理的extent去了。所以就找不到索引的對象。

 

查看官方文檔這個報錯還可能和bug 21532755 有關

文檔 ID 8102.1

https://www.linuxidc.com/Linux/2014-11/109648.htm

文檔 ID 21532755.8

https://chandlerdba.com/2017/05/12/online-index-rebuild-problem-in-12c/

法一

SELECT owner, object_name, object_type
FROM Dba_Objects WHERE object_id IN (57848);

可以查出object_name的名字,然後重建索引

alter index PK_TB_WARE rebuild online; (記得要用rebuild online ,因爲他會重新讀表來創建索引,而rebuild可能會讀取原先的索引段而不會去讀表)

注意,這個時候千萬不要人爲終止,否則會遇到ora-08104

 

如果還不能解決,就刪除重新創建

drop index PK_TB_WARE;

create index PK_TB_WARE on tb_ware(id);

 

法二

analyze table t validate structure cascade

檢查表裏的行數據的完全性,並檢查表或者索引的結構,並把分析過的結果寫入INDEX_STATS 數據字典中

Oracle

控制文件備份遇到報錯

ORA-00230: operation disallowed: snapshot control file enqueue unavailable

控制文件備份需要持有查看持有CF enqueue,但該鎖目前被其他會話持有(一般會是其他rman進程或者CKPT進程) http://ju.outofmemory.cn/entry/179736

查看持有CF enqueue會話

SELECT s.SID, USERNAME AS "User", PROGRAM, MODULE, ACTION, LOGON_TIME "Logon" FROM V$SESSION s, V$ENQUEUE_LOCK l WHERE l.SID = s.SID AND l.TYPE = 'CF'  -- AND l.ID1 = 0 AND l.ID2 = 2;

 

根據查到的進程信息判斷是kill掉還是等待當前持鎖會話運行完

Oracle

ORA-00600 [KTSLU_PUA_REMCHK-1]

導致主從同步中斷

The assert is raised when trying to apply Redo for Secure LOB Segment. Redo was generated with changes introduced by fix for Bug:22905136. This fix was included in 12.1.0.2.170418DBBP. The error is generated because redo generated is not compatible with environments running on a release lower than  12.1.0.2.170418 DBBP or without patch:22905136 installed.

 

遇到的情況是主庫打了12.1.0.2.170418 DBBP而從庫沒打,兩邊小版本不一致

ORA-00600:[KTSLU_PUA_REMCHK-1] Could be generated after Applying April 2017 Database Bundle Patch (12.1.0.2.170418 DBBP) (文檔 ID 2267842.1)

兩邊小版本必須一致,要麼沒打補丁的庫打補丁,要麼打了補丁的庫回滾;一般第一種比較推薦

 

Oracle ORA-07445[pesld10_Undo_XREF_Instance()+23]

This issue is caused by a product defect.

It was investigated in:

     Bug 13554646 - ORA-7445 [PESLD10_UNDO_XREF_INSTANCE()+60]

which was ultimately closed as a duplicate of unpublished Bug 13429702.

Error in the Alert Log: ORA-7445[pesld10_Undo_XREF_Instance()+4] (文檔 ID 1456810.1)

法一:升級到已修復版本

 

法二:打補丁Patch 13429702 

Oracle ORA-00600: internal error code, arguments: [qcscbndv1], [65535] sql中綁定變量數超過oracle上限65535,在11.2前該報錯爲ORA-7445[opiaba] ORA-600[qcscbndv1], [65535, ORA-600[Kghssgfr2], ORA-600[17112] Instance Failure (文檔 ID 1311230.1) 業務方請改sql謝謝
         
SQL Server eventlog:SSPI handshake failed with error code 0x8009030c, state 14 while establishing a connection with integrated security; the connection has been closed. Reason: AcceptSecurityContext failed. The Windows error code indicates the cause of failure. The logon attempt failed   [CLIENT: 192.168.1.3]

192.168.1.3中有賬號連到數據庫時登錄驗證失敗。

 

常見於192.168.1.3中曾用A用戶(遇到的情況是域賬號)連接到數據庫,後來A用戶密碼被修改,但192.168.1.3中仍在使用舊密碼嘗試連接,導致登錄驗證報錯

 

登錄192.168.1.3服務器斷開以前使用A用戶的連接

或者

登錄數據庫服務器kill掉A用戶的連接

 

SQL Server eventlog:BackupIoRequest::ReportIoError: write failure on backup device 'VNBU0-10424-14500-1538441467'. Operating system error 995(The I/O operation has been aborted because of either a thread exit or an application request.). NBU備份服務器內存不足導致備份失敗   一般下次備份時會成功,如果不成功可以手動發起
SQL Server

Error 8623

The query processor ran out of internal resources and could not produce a query plan. This is a rare event and only expected for extremely complex queries or queries that reference a very large number of tables or partitions. Please simplify the query. If you believe you have received this message in error, contact Customer Support Services for more information.

sql語句過於複雜,例如in中有太多值或者sql嵌套太多層

 

Explicitly including an extremely large number of values (many thousands of values separated by commas) within the parentheses, in an IN clause can consume resources and return errors 8623 or 8632.

https://docs.microsoft.com/en-us/sql/t-sql/language-elements/in-transact-sql?view=sql-server-2017

可以利用擴展事件找到對應語句

https://www.cnblogs.com/kerrycode/p/9860653.html

 

To work around this problem, store the items in the IN list in a table, and use a SELECT subquery within an IN clause.

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章