真實(shí)世界Oracle故障診斷一千零一夜-張維照

2云和恩墨--張維照34目錄：Oracle日常維護(hù)中的風(fēng)險(xiǎn)升級12c+后的常見問題案例：優(yōu)化SQL解析觸發(fā)的一系列BUG,PostgreSQL的PreparestatementOracle19c自動索引一種場景5Oracle的風(fēng)險(xiǎn)CPUCPUlms一致導(dǎo)致gccr¤tgrant2-wayerverprocessdiff同集群不同節(jié)點(diǎn)CPU個(gè)數(shù)(lmd)不一致導(dǎo)致enq:IV–contention_ges_server_processes(12cR1)anceORAIn/,weincreasethedefaultPROCESSESbasedonthenumberofCPUcores,butthedefaultMEMORY_TARGETvalueisnotincreased.Recommendation:memory_max_target=4096m&memory_target=1536m(default272m)7Oracle日常維護(hù)中的風(fēng)險(xiǎn)內(nèi)存7noutsqlpluslogonslowswapiness是的一個(gè)Linux內(nèi)核參數(shù)，目的是用來控制頁交換比例的，其設(shè)置范圍為0-100，這個(gè)值默認(rèn)RHEL5&6為60,RHEL7為30,10.2最大168GBSGA(1268668.1)8Oracle日常維護(hù)中的風(fēng)險(xiǎn)網(wǎng)絡(luò)8reassemblesfailedzzzThuMar11:40:31CST2017semblesfailedzzzThuMar11:40:52CST2017assemblesfailedping-s8192和traceroute還可能顯示正常.解決方法etipvipfraghighthreshMpvipfraglowthreshMeRAC割接后，原環(huán)境記的銷毀，不一定哪天啟動了SCAN\VIP影響了現(xiàn)有的RAC.9Oracle盤空間9“這是一個(gè)800GB的庫，之前表空間老滿，這次把存儲都給加進(jìn)去吧160TB！”ExtExt-FSdirectoryindexfullOracle險(xiǎn)安裝oneoffpatch例無法啟動Oracle險(xiǎn)安裝oneoffpatch例無法啟動ailailistOracle險(xiǎn)安裝oneoffpatch例無法啟動補(bǔ)丁缺陷安裝該oneoffpatch后,第一次啟動實(shí)例要使用crsctlstartinstance,而不是sqlplus如果使用sqlplus需要先后動修改oracle執(zhí)行文件權(quán)限r(nóng)aclepatch兩實(shí)例上的參數(shù)不一兩實(shí)例上的參數(shù)不一致patchlsinvraclepatch注：注：Linux可以stringsoracle|grepparameter,但hpux不可以patchlsinv看看到libserver11.a文件實(shí)際是更新了的，后來嘗試了relink提示錯(cuò)誤rollbackpatchreinstallpatchOracle日常維護(hù)中的風(fēng)險(xiǎn)Linux7/Suse12敗Oracle日常維護(hù)中的風(fēng)險(xiǎn)Linux7/Suse12敗OHASD服務(wù)，SYSTEMD就是PID=1的程序，有它來統(tǒng)一管理啟動，標(biāo)準(zhǔn)化系統(tǒng)啟 或重啟操作系統(tǒng)Oracle數(shù)據(jù)泵導(dǎo)數(shù)packagebodyrmnewdirectorydumpdirdumpfilermdmpCTRANSPKGSQLFILEddlsqlOracle數(shù)據(jù)泵導(dǎo)數(shù)packagebodypedOracleRMAN份恢復(fù)使用rman備份恢復(fù)升級后的數(shù)據(jù)庫同存儲，慢了7倍parallelismhostonVeritasFSparallelism現(xiàn)象：SQLfulltablescanG幾分鐘RMANcpuwait有些高使用了VeritasODM(OracleDiskManager)OracleRMAN份恢復(fù)使用rman備份恢復(fù)升級后的數(shù)據(jù)庫同存儲，慢了7倍imeteredreadOracleRMAN份恢復(fù)使用rman備份恢復(fù)升級后的數(shù)據(jù)庫同存儲，慢了7倍OracleRMAN份恢復(fù)使用rman備份恢復(fù)升級后的數(shù)據(jù)庫同存儲，慢了7倍OracleRMAN份恢復(fù)使用rman備份恢復(fù)升級后的數(shù)據(jù)庫同存儲，慢了7倍OracleRMAN份恢復(fù)使用rman備份恢復(fù)升級后的數(shù)據(jù)庫同存儲，慢了7倍tafile#fsmap-a/vxfs/oracle/oradata/user01.dbf>user01.map當(dāng)有巨量的碎片，執(zhí)行每一個(gè)文件的操作時(shí)，需要從元數(shù)據(jù)中檢索到每個(gè)擴(kuò)展(extent)信息，如此巨大的metadata數(shù)據(jù)量操作，是一定會消耗大量的CPU資源和費(fèi)時(shí)，這也是為什么rman備份時(shí)會有cpuwait.采用了OracleRMAN并行寫入的方式，即多個(gè)數(shù)據(jù)文件在同時(shí)不停的追加，并沒有事先為這些文件預(yù)留連續(xù)空間。因此，數(shù)據(jù)在寫入下層介質(zhì)時(shí)，不是連續(xù)的一個(gè)整體，頻繁分配新的extent，導(dǎo)致產(chǎn)生巨量extent，最終引發(fā)文件讀寫性能問題#nohupfsadm–EeDd/acct/oradata01/&Oraclechar\0DMLtrigger數(shù)據(jù)的程序運(yùn)行報(bào)錯(cuò)(Clanguage)Oraclechar\0DMLtrigger數(shù)據(jù)的程序運(yùn)行報(bào)錯(cuò)(Clanguage)Oraclechar\0DMLtrigger數(shù)據(jù)的程序運(yùn)行報(bào)錯(cuò)(Clanguage)””\0″字符是在C語言O(shè)raclechar\0DMLtrigger數(shù)據(jù)的程序運(yùn)行報(bào)錯(cuò)(Clanguage)ated序列trace內(nèi)容說明解決方法1----CursorObsoletionDumpsql_id=5p8a9d4017bq3-----Parentcursorobsoleted1time(s).maxchild=1024basephd=00007FFB8AD45CB0phd=00007FFB8AD45CB0用于SQL游標(biāo)達(dá)obsoletethreshold時(shí)生成診斷信息，通過在父游標(biāo)被廢棄N次之后轉(zhuǎn)儲有關(guān)過時(shí)的父游標(biāo)及其子游標(biāo)的信息來改善游標(biāo)共享診斷。patch22075064(=1)--or--"_kks_obsolete_dump_threshold"=02KSIPC:KSIPC:Unabletoattachtoipcortoposvcobject每個(gè)會話登錄都會創(chuàng)建一個(gè)trace，發(fā)生在IPC層重啟實(shí)例3MMONTRACE:AUTOSGA:kmgs_parameter_update_timeoutgen00mmonalive1mmonbgprocesstrace每3秒寫一條記錄Bug254157134ORA-12805:parallelqueryserverdiedunexpectedlyalert日志每40秒一條記錄BUG275791595KRB:krbb.c@7963:krbbtgb():readingfileKRB:krbb.c@16076:krbbnbf()KRBB==>>KernelRecoveryBackupRestoreCreationOfABackuppiecerman相關(guān)的操作都會生成一個(gè)trace文件Bug28174827Bug28390273altersystemsetevents'trace[krb.*]diskdisable,memorydisable';6Result:(7)CLSGPNP_IO.(:GPNP01002:)Failedtoopenwalletfile12.1dbalert中出錯(cuò)該錯(cuò)誤，只是一個(gè)錯(cuò)誤提示，可以忽略BUG188934637WARNING:toomanyparseerrorsdbalertlog中顯示，類似10035event分析解決失敗信息寫入alertlog，60分鐘內(nèi)每出現(xiàn)100次_kks_parse_error_warning推薦參數(shù)"_use_single_log_writer”=true禁用多l(xiāng)ogwriterwaitevent:LGWRworkergroupidle&logfilesync:SCNordering“_cursor_obsolete_threshold”=200對于NO-CDB,先確認(rèn)highversion原因waitevent:Cursor:mutexS/X,SQLhighversion“_dlm_stats_collect”=0禁用DLM統(tǒng)計(jì)信息SCM0進(jìn)程的CPU使用率“_ksxp_ipclw_enabled”=0forbug28111583truncate大表導(dǎo)致心跳網(wǎng)流量高，節(jié)點(diǎn)crashxpdp12cnewfeaturemastertableolutionInstallMergePatch12.2createtablesystem.test_t1(minbillcycle12.2ntosystemtesttselecttocharsysdateyyyymmfromdualcreatetablesystemtesttasselectfromsystemtesttwhere=0;cyclenumber;nECTintoaa7selectmonths_between(to_date(CYCLE#,'yyyymm'),to_date(minbillcycle,'yyyymm'))nbillcycleDEBTSUBSFROMsystemtestt1PBYmonthsbetweentodateCYCLEyyyymmtodateminbillcycleyyyymm11SELECT0DEBTTIME,0DEBTSUBSFROMsystemtestt)*PLSQLSESSION器參數(shù)，嘗試修改哪個(gè)參數(shù)可以改變這種行為。(基于x$qksceses、x$ksppi、x$ksppcv、把把報(bào)錯(cuò)腳本存為script.sql定定位出修改以下三項(xiàng)任何一個(gè)，原SQL就不在報(bào)錯(cuò)：Set_optimizer_distinct_agg_transform=false--or--Set_gby_hash_aggregation_enabled=false--or--set"_fix_control"='11657903:1'與11與11gR2時(shí)存在Bug11657903有些相似，此bug12.1已修復(fù)，12cR2目前看來還是存在問題。如果MOS以參數(shù)為關(guān)鍵字搜索，會發(fā)現(xiàn)關(guān)于上面兩個(gè)隱藏參數(shù)在11G時(shí)也是問題特性參數(shù)，所以12.2建議還是關(guān)閉。(生產(chǎn)庫記的測試！)altersystemset"_gby_hash_aggregation_enabled"=falseSCOPE=SPFILE;altersystemset"_optimizer_distinct_agg_transform"=falseSCOPE=SPFILE;SQL觸發(fā)的一系列BUGLCREATETABLEANBOBLOCANBOBVARLOG"OID"NUMBER(14,0)NOTNULLENABLE,VARIABLEIDVARCHAR32)NOTNULLENABLE,"SQLBANDVAL"VARCHAR2(256),RUNTIMEVARCHARNOTNULLENABLE,"INTIME"DATEDEFAULTsysdatePARTITIONBYHASH("OID")partitions8storeinDATA);Tablecreated.SQLinsertintoANBOBloc_ANBOB_varlogdvariableidsqlbandvalruntimeintimeesANBOBseqoidnextval':RECDATE:20180905;','2.272908',sysdate);ANBOBseqoidnextvalRECDATE05;','2.272908',sysdate)*alerrorcodeargumentsqesmaGetTblSegxDFECxLgrantselectinsertonANBOBLOCANBOBVARLOGtoWEEJARntselectinsertonANBOBLOCANBOBVARLOGtodbmt*traceevent"grant"ildSIGSEGVADDRxPCxDFotmappedtoobjectSQL觸發(fā)的一系列BUGrootlocalhostcattrace_file.txt|sed-n'/CallStackTrace/,/main()/p'|sed-n'5,/*/p'|cut-c1-29|sed'/^[[:space:]]*$/d'|awk-wCBKdpoolpartaccessversionbynumberSQL觸發(fā)的一系列BUGORAORAkssfirstchild()+8]SQL觸發(fā)的一系列BUGemIOSQL觸發(fā)的一系列BUGswitchAStreams/GoldenGate/LogMiner/etc..logminingoperation.Manualdumpingofredologcontents4.AutomaticBlockMediaRecoverySQL觸發(fā)的一系列BUG段的incident信息KCBZWFCROKCBZWFCRO==>KernelCacheBufferssubroutinesforkcbWaitingForceCROverrideSQL觸發(fā)的一系列BUGzwfcrotracefileFlushbuffercacheORtorestarttheinstanceSet“_gc_override_force_cr”=falseSQL觸發(fā)的一系列BUG..dbmssharedpoolmarkhot起問題ORA-600[qesmaGetTblSeg1]BUG19689979ORA7445[kss_first_child()+8]Bug22293453ora-600[kcbzwfcro_2]ORA600[ktecgsc:kcbz_objdchk]ora-600[ktecgsc:objdchk_kcbgcur_3]Bug18259031ora600[kgltti-no-dep1]Bug19620099PreparedStatements的方法是在PostgreSQLV7.3版本引入，在SQL語義的檢查，那些元數(shù)據(jù)存在system表空間(oracle)或systemcatalog(PostgreSQL).然后根據(jù)之前預(yù)準(zhǔn)備的統(tǒng)計(jì)信息(可能動態(tài)采在sharedpool(Librarycache)中對于所有會話可以共享，但是PG存儲在program復(fù)用。sintegerasupdatetanbobsetcncnwhereidteprepareps在PostgreSQLV12版本中引入一個(gè)參數(shù)HYPERLINK"/docs/devel/static/runtime-config-query.htm