还剩18页未读，继续阅读
本资源只提供10页预览，全部文档请下载后查看！喜欢就下载吧，查找使用更方便
文本内容:
2025Oracle的BUG Oracle安装的Oracle打补丁及升级正文第11页第三章BUG1OG部署bug11G部署bug12C部署bug19C部署bugOracle安装尽然这么多BUG这些规避方式，泰裤啦！.qq.eom/s/_Oi2NR8PRjQkex50mRj2IQ
（一）DB闪回区100%相关故障处理♦
（二）Oracle Redo被删生产事故
（三）参数设置不合理用户误操作故障现象♦业务反馈操作时数据库住没有反应hang操作系统版本AIX6100数据库版本Oracle11g单机
11.2・
0.4Unable toallocate flashbacklog of30118blocks fromcurrentrecovery areaof size21474836480bytes.Recovery WriterRVWR isstuck untilmore spaceisavailable inthe recoveryarea.Unable towrite Flashbackdatabase logdata becausetherecovery areais full,presence ofa guaranteedrestore、cpoint andno reusableflashback logs.日志报错显示闪回区满，无法从闪回区中分配新的闪回日志DB闪回区故障日志误删除参数设置错误SQL〉Col time format a20;正文第14页SQL〉Col restorejoint.timeformat a20;SQL〉Col nameformata40;第三章SQL〉select*from v$restore_point;SCN DATABASEJNCARNATION#GUARANTEE STORAGEJIZETIME PRESERVEDNAME243423522771YES2147483648003-HAY-
1612.
27.
43.0YES UPGRADEPOINT2016050300000000PH数据库仓建了GUARANTEE RESTOREPOINT,时间点为2016年5月3日，是当时数据库做升级时创建的强制还原点.当设置了GUARANTEE RESTOREPOINT时，闪回日志是无法被覆盖，闪回日志一直是增长的，当闪回区使用率为100%时,数据库就会hang住，因此需要删除该还原点.设置guarantee restorepoint后，flashback databaselog不会被覆盖，且一直在增加，当闪回空间满后，数据库会hang住当guarantee restorepoint不再使用后，需要及时drop掉，否则容易导致空间撑满细节决定成败，看似简单的一个疏忽就能导致致命的故障，数据库操作无小事，一些细微的问题可能存在严重的隐患，因此每个操作都要小心谨慎，每个修改都不容轻视DB闪回区故障日志误删除参数设置错误正文■第15页第三章凌晨的2点，我还做着美梦，被一阵电话吵醒，3套核心业务库发生了无法连接的________________报错，应用全部中断，客户着急，一起现场的小伙伴也慌了我开始了远程i.i监听报错监听已经无法启动，应用连接报错
1.2数据库down机数据库down机，启动数据库报错提示，无法找到在线日志redo
02.logKedoButters118231640bytesDatabaseMounted.0RA06313:openfailedforaembersofloggroup2ofthread1ORA-96312:onlinelog2thread1:/u61/app/oracle/oradata/MESDB/redo
62.logORA-27037:unabletoobtainfilestatusLinux-x8664Error:2:NosuchfileordirectoryAdditionalinfonaation:7■公众号•IT邦德Oracle Redo被删生产事故，跪了！凉经分享.qq.eom/s/LSewC7VSrB8-vssgnCfCdg频发发生的索引分裂事件1IIUCAIddllull0312vvvnulanyco/V V.w V5index fetchby key42,472,41611,7902313702index scanskdiixsl12,560,1053,48665405■a!叱1，小1神仿-A Mn n£leaf nodesplits14,98441600!IV/U IVdU^0984,08186,351lob writes517306lob writesunaligned1OA OXQ_BL.T4r0京c不会甩锅的厨子不是好的DBA.qq.eom/s/TUuy8qBn6PSOoCufYonOPg偷偷分享下某大厂运行15年百套RAC上线前的调参….qq.eom/s/G0of1D4yKDvd71noBQ7ZWg
（一）1个SQL干崩核心系统
（二）硬件性能故障性能故障SQL性能硬件性能正文■笫18页第四章4AKQu0m16大周末的接到项目组的电话，反馈应用从凌晨4点开始持续卡顿，起初并未关注,到下午2点左右，核心系统是彻底干绷了，远程接入后发现，数据库后台有大量的异常等待事件Second PerTransactionDB Timers14201DB CPUs:1800Redo sizebytes
235.
27071.5737Logical readblocks:
150.
16171.0044Block changes
1.157277Physical readblocks:135,37829055Physical writeblocks31902Read10requests1309488Write10requests202|Read10MB1,05761众书•嚼a ZxITTop10ForegroundEventsbyTotal WaitTime■F”nt1Wxif*1TntulWAHTinw»Writ I%DRtinw»1WxitCIJMS|directpathread
3.067,468322K10631UserI/ODBCPU6538128dbfilescatteredread4036195203513102UserI/O*八仆空鸣公众口砧德logfilesync1628974026610161J9cl.0Wrdbfilesequentialread348149readbyothersession4465138169216UserI/O好烦啊，1个SQL干崩核心系统长达12小时.qq.eom/s/gGJIOOZDon4e5haE88CjRgSQL性能硬件性能正文第19页我们发现出现了gc bufferbusy等待事件第四章Top10Foreground Eventsby Total Wait TimeiEvent WaitsTotalWaitTime secAvg Wait%DB timeWait Class
234.8K
53.7DB CPU|gc bufferbusy release856,
275121.4K
141.80ms
27.8Clusterlog filesync549,
16823.2K
42.25ms.
5.3Commit1gc bufferbusy acquire384,
56918.6K
48.32ms
4.2Cluster|r67K H5ms
2.4Clustergc currentblock busy1,674,910enq:TX-row lockcontention6,
7399596.
61424.04ms
2.2Applicationgc indexoperation76,
0424815.
963.33ms
1.1Cluster〜c-JI——L4OOOAWR中新引入的后台进程ping会定期测量网络统计信息Interconnect PingLatency Statistics•Pinglatencyof theroundtripofa messagefromthisinstanceto•targetinstances.•Thetarget instanceisidentifiedbyaninstance number.•Averageand standarddeviationof pinglatencyis givenin microseconds•formessagesizes of500bytesand8K.•Notethat latencyofamessagefrom theinstancetoitselfis usedas•control,sincemessage latencycaninclude waitforCPUTargetInstance500BPing CountAvg Latency500BmsgStddev500B msg8KPing CountAvg Latency8K msgStddev8K msg公发邦惠12,
3082220.
032.518Wm208・||322,
3085170.282,
5185800.29RAC OneNode,双胞胎变独生子？.qq.eom/s/LNPHsSK6zzu6b4gPJc3xRg所有的故障都是变化（变更）引起的硬件故障软件故障用户误操作性能故障开篇案例开篇案例根据客户反馈，因为岁修产生了大量的归档，手动物理删除归档后，备份就失败,报错如下ORA・27037:unable toobtain filestatusLinux-x86_64Error:2:No suchfile ordirectory息汴BR aomI itml安I全I皿效彷诲实例你会怎么处理？时间紧，任务急|过渡■第5页页
（一）控制文件丢失，RAC实例无法启动
（二）在线日志破坏，无法启库♦
（三）RAC集群服务器主板烧毁致命生产故障硬件故障第一章最近核心业务使用的一套Oracle数据库故障，由于自己的疏忽，导致恢复失败，彻底瘫痪了，分享经验给大家，引以为鉴Oracle的RAC的2个数据库实例异常停止，查看日志发现控制文件坏块，跟用户确认得知怀疑是近期服务器突发掉电导致，让人吐血的是多路复制的2个控制文件同时被破坏,Corruptblockrelative dba:0x00000004file0,block4Badheader foundduringcontrol fileblockreadDatainbadblock:type:2format:0rdba:0x015e9d07lastchange sen:0x
0000.7ffc.d2649bf0seq:0x0fig:0x00spare3:0xd264consistencyvalue intail:0x00001501checkvalue inblockheader:0x9f70blockchecksum disabledControlfileblockreadforfixedtableaccess hasfailedduetoconcurrentcontrolfileupdates.This isnotareal datacorruption.Please retrythequery.2e24e6-25T1604:54,020881*08:00—八邦德ScnorsIn rp/ORA-082e2:controlfile:•♦OCRVOTE/BjMPTINTnrn FILE/current.2£.115i4i^7’Control fileblockreadforfixedtable accesshasfailedduetoconcurrentcontrolfileupdates,rhisisnot arealdatacorruption.Pleaseretrythequery.be24-06-25T1604:
54.341196*08:06Errorsinfile/oracle/app/diag/rdbms/c«»»••••*L/trace***H_imr0_
27830.tre:□RA-0e202:controlfile:♦DATA/Cmm/CONTROLFILE/current.
319.1158425577,2024-06-25T1604:
54.396466*68:00Errorsinfile/oracle/app/diag/rdbms/di»«A^»Wbl/trace/^»*4M_i«ir0_2783e-trc:公众号*邦缶pRA-63995:fracturedblockdetectedincontrolfile:block4,•blocks ITDRA-80202:controlfile:♦DATA/MM/CONTROLFILE/current.
319.115842S577老司机翻车，一次失败的备份恢复，核心应用彻底瘫痪….qq.eom/s/z_zvperCIGh22djy9PUbJA3r16为笳七〜.夕第一章客户反馈数据库处于非归档的模式下，而联机重做日志又currupted,数据库无法启动一Database mounted.ORA-00313:open failedfor membersof loggroup1of thread1ORA-00312:online log1thread1:7u01/app/oracle/oradata/ORCL/redo
01.log,ORA-27037:unable toobtain filestatusLinux-x86_64Error:2:No suchfile ordirectoryAdditional information:7ORA-00313:open failedfor membersof loggroup1of thread1ORA-00312:online log1thread1:*/uOl/app/oracle/oradata/ORCL/redoOl.log*ORA-27037:unable toobtain filestatusLinux-x86_64Error:2:No suchfile ordirectoryAdditional information:7ORA-313signalled during:ALTER DATABASEOPEN...2024-03-07T23:27:
29.486301+08:00Errors infile/u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_mz00_
5733.trc:ORA-00312:online log1thread1:*/uOl/app/oracle/oradata/ORCL/redoOl.log,__________________________________________ORA-27037:unable tobtain filestatus99%的人不知道，resetlogs强制开库需要推进SCN.qq.eom/s/GGEOl6MK36YwgKYoCdWZlA糟糕,归档满RMAN进不去,CPU98%了！.qq.eom/s/Z_MsCQKKbB_u8oDYq5_YwA控制文件丢失在线日志破坏实例故障正文凌晨1点32分，接到项目组的电话，生产环境的一套Oracle19CRAC节点1发生服第一章务器主板烧毁导致业务中断，因为应用没有配置FAILOVER_MODE1，urrLINE urrLINEb1AULtbra.LISTENER SCANl.Ism11ONLINE ONLINEracdb2STABLEbra.OCR.dgora.asmgroup1OFFLINE OFFLINESTABLE2ONLINE ONLINEracdb2STABLE3OFFLINE OFFLINESTABLE□ra.asmora.asmgroup1ONLINE OFFLINESTABLE2ONLINE ONLINEracdb2Started,STABLE3OFFLINE OFFLINESTABLEora.asmnetl.asmnetworkora.asmgroup1ONLINE OFFLINESTABLE2ONLINE ONLINEracdb2STABLE3OFFLINE OFFLINESTABLEora.cvu1ONLINE ONLINEracdb2STABLEora.prod.db1ONLINE OFFLINESTABLE2ONLINE ONLINEracdb2Open,H0ME=/u01/app/oracle/product/
19.
0.0/dbhome_l,STABLEbra.qosmserver1ONLINE ONLINEracdb2STABLE□ra.racdbl.vip1ONLINE INTERMEDIATEracdb2FAILED OVER,STABLEora.racdb
（二）Oracle安装部署的BUG
（三）Oracle打补丁及升级软件故障Oracle的Oracle安装的BUG Oracle打补丁及升级BUGOracle至今未解决的BUG,真的让我看不下去了….qq.eom/s/ZYBZmvoemrVWvuwOOrAOkwC1020304创建本地数据文件bug数据字典Bug OGG的bug lag延迟。
个人认证
优秀文档
获得点赞 0
