- 博客(601)
- 资源 (6)
- 收藏
- 关注
原创 关于我的介绍
关于我:姓白,常被称"白工"、"小白";就职于国内某知名专业第三方数据库服务厂商,具有多年专职Oracle数据库相关技术支持经验,现居杭州;日常工作涉及对银行、保险、政府、电信、广电、医疗、大型制造业等行业客户提供Oracle技术支持;包括MAA高可用/容灾架构的咨询/规划/实施、基于OWI/SQL等方面的性能调优服务、Oracle数据库跨版本跨平台升级迁移等;持有10g ocm认证。在csd...
2017-05-03 12:47:36 1717 2
原创 oracle 19c数据库W00n进程使用很多PGA内存资源的分析
今天,客户反馈测试环境的数据库PGA资源不足,报错ORA-04036: 实例使用的 PGA 内存超出 PGA_AGGREGATE_LIMIT;查看总的PGA分布:select sum(pga_alloc_mem)/(1024*1024) "Mbytes allocated", sum(pga_used_mem)/(1024*1024) "Mbytes used" from v$process;1、民间办法:KILL进程、或者定期重启数据库。查找占用内存多的进程:使用SQL;
2024-04-16 17:13:09 710
原创 ORACLE RAC集群CRSD服务异常后无需重启集群的处理方法
/crsctl start res ora.crsd -init),不影响集群其它资源,数据库等均持续正常运行。3.集群日志排查发现OCR不能读导致CRSD资源异常;具体为5/26号12:19分时候asm日志显示OCR仲裁盘有问题,13:23分出现读写错误。监控软件连不上TEST集群节点1,发现监听中不存在IP 1.80.检查巡检数据发现5/18日正常。1.根据监控软件报错时间排查,监听日志无异常,监听状态中不存在IP 1.80物理IP。排查发现为CRSD服务异常,其它集群资源正常,所以数据库没有宕机。
2024-04-11 10:17:52 263
原创 ORACLE 19C版本PGA使用率告警问题分析处理
近期,某客户数据库告警平台经常发出告警“告警名称: PGA超限使用”,需要进行分析处理。在ORACLE 11G时代,PGA基本可以任务是不受参数限制的,因此对于老DBA来说,PGA参数随便设置的情况是存在的。因此,对于这个19C环境的告警,需要进行分析。最终判断,数据库进程数量稳定,PGA使用量稳定,偶尔的使用率偏高,最终调大PGA_AGGREGATE_LIMIT值来避免告警。3、查看数据库进程数量,使用PGA量大的进程信息。1、查看数据库进程数量,使用PGA量大的进程信息。4、查看PGA的历史使用量。
2024-04-11 10:10:25 382
原创 oracle切换ADG后JVM组件查询报错ORA-29516处理
此时,我们将X86 LINUX架构服务器上JAVA版本更新为一致的非OPENJDK版本的JAVA:java version "1.8.0_241",使变量生效,之后重启数据库,仍然未能解决问题。结合实际情况分析对比,EXADATA上的JAVA版本为:java version "1.8.0_241";DBCA在监控过程充安装组件会用到本地的一些环境、变量,而X86架构的LINUX环境存在一些差异导致无法正常运行JAVA组件;前面的人工安装JAVA来实现X86架构的LINUX环境一致的方式已经验证不可行;
2024-03-25 16:43:27 307
原创 ORACLE RAC反应卡顿时enq: SV - contention和latch: row cache objects的分析
2、从基本信息来看,出现了很多异常等待数据,如典型的enq: SV - contention 、enq: TX - row lock contention、enq: SQ - contention、cursor: pin S wait on X、latch: row cache objects、enq: US - contention;4、看起来问题比较清楚,大量回滚端请求,查看对应UNDO表空间使用率,可以发现UNDO表空间使用率高,查看UNDO段状态,大量在UNEEXPIRED状态;
2024-03-06 16:52:04 721
原创 Oracle Exadata的SCAN监听程序异常重启问题分析
1、在这个Oracle Exadata环境,有多个数据库,未有人反馈问题,初步判断大部分系统是正常的。停止程序后,监听日志查看正常不再有高频连接,此后SCAN监听未发生过重启,系统恢复正常。2、SCAN监听问题,用了2、3个数据库的SERVICE_NAME去连,都有问题,判断为SCAN监听问题,不是个别数据库问题。常规思路下,遇到次问题,有一系列的排查、排除方向,去定位和处理问题。3、根据有问题的IP,找软件维护人员查看,关闭对应程序后,系统恢复。3、用VIP进行连接,连接、查询均正常。
2024-02-29 14:21:58 460
原创 12.2RAC环境从RAC转为单机模式的问题处理
一开始只是将数据库软件通过make -f ins_rdbms.mk rac_off 和 make -f ins_rdbms.mk ioracle关闭RAC模式;然后在启动数据库(sqlplus / as sysdba登录后startup时报错:ORA-00600: internal error code, arguments: [kgfz_getDiskAccessMode:ntyp], [0], [], [], [], [], [], [], [], [], [], []2.启动数据库实例时的报错。
2023-09-08 19:12:00 391
原创 一次存储盘异常引起的ASM磁盘OFFLINE处理
4.尝试重新MOUNT磁盘组,以及修复OCR(NORMAL冗余)磁盘组中OFFLINE后超过REPAIR时间的DROP状态磁盘。2.检查操作系统的日志(linux /var/opt/message),确定出现了存储盘的IO报错(事后分析为链路问题)登陆系统查看,数据库实例异常关闭,日志指向ASM DISKGROUP异常;1.检查集群状态、ASM实例状态,发现ASM磁盘组已经DISMOUNT;3.目前检查测试,磁盘已经恢复;2.MOUNT 磁盘组报错的解决。3.处理DROP状态的ASM磁盘。
2023-07-26 16:38:24 771
原创 kernel.shmall 参数导致的Oracle数据库无法启动问题分析与测试
Oracle不再把sga放到共享段中,pmap工具诠释了进程相关共享内存的情况,可以看到许多个4MB的"文件"(此处的大小可能不是4M,可能是16M等)对应了Oracle服务进程的空间地址.这是linux上POSIX风格的共享内存管理模式,使用"文件"形式包含共享内存段.借助于将sga分割成许多块,Oracle可以很容易地把sga部分内存返回给OS,而服务器进程即可以利用到这些内存.(当memory_max_target>1024时,颗粒为16MB,否则为4MB).。修改完成后 sysctl -p。
2023-05-31 23:49:33 988
原创 oracle19c版本会导致数据库实例crash的bug32653669
近期,某客户的数据库系统出现运行时突然宕机,查看数据库后台alert日志,无明显的ORA-00600或ORA-07445等错误;深入分析后,问题原因为存放业务数据的表空间使用满后,业务数据的表使用了LOB字段,触发了BUG:Bug 32653669 - ORA-1652 ON GEN0 CRASHED INSTANCE,导致数据库实例宕机。分析此BUG的出发条件:1.表空间使用满 2.使用LOB字段(严格来说是securefile lob,11G后默认此种类型)。检查GEN0进程的TRACE文件,对。
2023-05-26 13:43:51 497
原创 oracle WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK问题分析
程在等待latch: row cache objects资源,根据故障时ALERT日志中systemstate dump prod2_ora_3191.trc信息来看,以典型的LCK0进程为例,此进程在等待和kghfrunp(释放shared pool中内存)有关的latch,此进程的历史等待事件中也大量存在'latch: shared pool'、latch: row cache objects;这2个参数是立即生效的,在所有的节点上设置这2个参数之后,系统不再进行DRM。具体值应结合历史AWR报告中。
2023-05-25 10:03:35 985
原创 oracle数据库主机CPU使用率高问题的分析及SQL优化
因此建议改写SQL,使用绑定变量。对TOP SQL的SQL文本进行分析,这些SQL的文本事实上一致,因未使用绑定变量,只在一些WHERE条件中不同;对TOP SQL的SQL文本进行分析,这些SQL的文本基本一致,只在一些WHERE条件中不同;当前的应急解决方案是针对出现问题的SQL,进行相应的索引创建,从而降低逻辑读(逻辑读会消耗CPU资源),提高SQL执行效率,缓解当前CPU使用率高的问题。对TOP SQL的SQL文本进行分析,这些SQL的文本事实上一致,因未使用绑定变量,只在一些WHERE条件中不同;
2023-05-23 12:00:20 2673 3
原创 oracle数据库大量产生trace文件导致空间不足问题原因的分析
运维人员发现备份出现问题,通过查看数据库日志及主机运行信息,发现遇到大量ORA-00060死锁报错,产生大量TRACE文件,导致ORACLE软件目录空间资源耗尽;通过数据库参数MAX_DUMP_FILE_SIZE限制单个TRACE文件的上限值,一定程序上会减少TRACE文件占用的空间,但是无法限制TRACE文件的个数。同时限制单个TRACE文件的上限值后,例如限制为10M,当问题进程对应的TRACE文件达到10M时,后续的TRACE信息无法写入TRACE文件;可以发现产生死锁进程涉及的SQL语句为。
2023-05-23 11:54:30 2065
原创 ORA-600 [17112]错误导致的数据库实例crash分析
客户的一套老系统,AIX环境的oracle 8i(8.1.7.4)版本,出现数据库宕机。分析ALERT日志,报错信息为ORA-00600: internal error code, arguments: [17112], [875767708];从告警日志中,我们可以确认到数据库实例中断是由于 PMON 进程中报 ORA-600 [17112] 所导致的。然而,Oracle DB 8.1.7.4 上没有补丁修复,建议您将数据库升级到 Oracle DB 11.2.0.4 来进行对应。
2023-05-23 11:42:46 353
原创 一次oracle环境 enq: TX - allocate ITL entry锁问题分析
默认情况下创建的表ITL槽数最小为1,pctfree为10,那么如果是这样一种情况,如果表中经常执行update语句,然后块中剩余的10%空间所剩无几,而且业务的并发量还很大,此时就很容易遇到enq: TX - allocate ITL entry等待。每当一个事务需要修改一个数据块时,需要在数据块头部获得一个可用的ITL槽,其中记录了当前事务的id,使用的undo数据块,还有对应的scn,事务是否提交等信息。此处遇到的问题即是ITL上发生的死锁,SQL同时对一个块进行操作时,对I。
2023-05-21 22:05:29 676
原创 ORACLE 12.2.0.1版本的BUG30403763 修复过程
参考MOS文档: ORA-600 [qkexrXCopn1] -OR- ORA-7445 [qerhnprobeinner] -OR- Other Internal Errors Followed By Instance Crash due to Memory Corruption (Doc ID 2899072.1)。BUG:30403763会导致数据库实例的宕机,本次用户就遇到了此问题并出现多次数据库实例宕机。参照ORACLE的解决方案,进行BUG对应的DBRU补丁包安装修复后,数据库运行正常。
2023-05-21 21:55:14 385
原创 ORA-07445 [qerhnFetch()+590] 及ORA-00600 [qkexrXCopn1]引起的数据库crash问题分析
应用程序出现报错显示为 ORA-01034 ORACLE not available,程序无法正常使用。接到数据库故障通知后,通过远程方式接入数据库环境进行故障排查,通过对相关日志等信息的深入分析,最终找到问题点并进行处理,数据库恢复正常,根据当时的问题处理情况整理汇总此文档。经过对数据库相关日志分析,数据库出现的故障和2023-05-10出现故障一致,问题SQL的执行计划没有改变,SQL无法进行优化的情况下,只能安装补丁解决BUG:30403763。
2023-05-21 21:50:43 271
原创 enq: TM - contention等待事件引起的数据库卡顿分析
因此结合ORACLE官方文档中(High 'enq: TM - contention' Wait Event Causing Session Hangs in an Oracle Streams Environment (Doc ID 740728.1)),对于OGG附加日志时执行的语句:BEGIN DBMS_CAPTURE_ADM.PREPARE_TABLE_INSTANTIATION(table_name => '"AA"."BB"', supplemental_logging => 'none');
2023-05-21 21:40:14 779
原创 中国南方ORACLE用户组会议:Oracle 19c 升级及关键特性的最佳实践
如何在灾难场景下实现零数据丢失的快速恢复是长久以来困扰Oracle DBA的问题,Oracle 19c的新特性有效解决了这一难题,显著提升了Oracle数据库稳定性,极致接近实现RTO
2023-05-21 21:32:58 132
原创 ORACLE 10G版本数据库系统产生大量归档日志问题的分析
ORACLE 11Gr2开始,数据库AWR中的segment部分的block change小节,可以显示块变更多的表或索引信息,依据此信息结合TOP SQL部分,可以很快速的确定导致产生很多归档日志的SQL语句、程序模块信息等。,当日采样人员过多,超过上限导致程序混乱,产生大量update,导致归档暴增,应用采取加模组方式暂时解决,后续修改采样编码上限。导致,正常的SQL在出现异常执行时,也会产生问题,出现大量的归档,应该对SQL执行次数进行监控,出现异常执行次数时, 立即处理。秒取样时间内,sql。
2023-05-09 16:43:39 2643
原创 一次业务系统无法使用对应的oracle数据库性能分析过程
(主机名WIN2008R2180409)连接到数据库的进程,有严重的TX行锁(enq: TX - row lock contention)等待,对应的SQL语句是SQL_ID:10y4yb0924b1p,SQL_TEXT: UPDATE GY_BINGRENXX SET NIANLINGDW = :B2 WHERE BINGRENID = :B1;排查,通过对相关日志等信息的深入分析,找出问题点并提出相应的解决建议,根据相关问题日志及分析处理情况整理汇总此文档。上午8-10点时有此SQL执行的记录。
2023-05-09 16:28:33 672
原创 一次典型的ORA-04031问题的处理
2.检查数据库alert日志,发现后台日志不停报错ORA-04031: 无法分配 ORA-04031: 无法分配 4160 字节的共享内存 ("shared pool","unknown object","sga heap(1,0)","modification ")6.调整内存SGA参数,增大shared_pool_size=2048m scope=spfile,重启生效后解决问题。4.临时flush shared_pool,无法根本性解决问题。字节的共享内存 ("","","","")
2023-04-28 12:05:09 2979
原创 RAC集群节点2异常时节点1的database实例无法提供服务问题的分析
直到节点1完成了重配,节点1恢复正常。,持续到13:45:45分,节点1检查到节点2异常,开始进行实例的Reconfiguration,13:45:51时完成,系统即恢复正常。数据库alert日志显示,13:42:40秒开始出现LGWR进程无响应80秒,推算13:41:20秒出现问题,持续到13:45:45分,节点1检查到节点2异常,开始进行实例的Reconfiguration,13:45:51时完成,系统即恢复正常。3.在此期间,由于节点2异常,大量程序的进程都连接到节点1,加剧了节点一的性能问题。
2023-04-26 17:19:32 946
原创 GRID集群软件GIPC进程引起的节点HANG住分析
通过对相关日志的分析,首先出现的GIPC worker thread non-responsive,GIPC本身是与通讯有关的进程,反复报出一些警告信息,可能说明当时通讯当时可能受到一些影响。通过对相关日志的分析,首先出现的GIPC worker thread non-responsive,GIPC本身是与通讯有关的进程,反复报出一些警告信息,可能说明当时通讯当时可能受到一些影响。节点2 开始关闭的时间是13:41:19,实际完成关闭的时间是13:44:25,再次重启的时间是13:52:40。
2023-04-26 17:05:11 942
原创 Exadata Stroage node reboot导致集群异常及Database crash分析处理
按Exadata一体机的冗余设计,单个存储节点重启是不影响集群及数据库运行的,本次存储节点故障却导致了CSSD进程异常、数据库实例 crash宕机,属于较为严重的故障。近期,有客户的Exadata一体机遇到存储节点重启,导致集群状态异常、Database crash。可以发现出现了IO异常,ASM中磁盘数据不一致,之后CKPT进程KILL了数据库实例。1.数据库实例crash宕机时信息分析。
2023-04-26 16:43:49 765
原创 ORACLE 19C后台报错ORA-00600 [qosdExpStatRead: expcnt mismatch]错误处理
近期,在数据库巡检时,发现某用户的ORACLE 19C RAC数据库系统,后台alert日志出现大量的ORA-00600 [qosdExpStatRead: expcnt mismatch]错误,同时产生了很多的cdmp文件,导致TRACE目录的磁盘空间不足问题。2.设置隐含参数 "_fix_control"='31143146:on' (可以动态设置)。本次使用设置隐含参数方式,设置后报错问题得到解决。
2023-04-25 16:05:56 647
原创 IMPDP导入时ORA-7445 [kpodpals]错误的处理
近期,某客户在进行从linux环境ORACLE数据库,将数据导入到WINDOWS环境的ORACLE时,遇到报错,无法导入。根据MOS文档ORA-7445 [kpodpals] During DataPump Import (Doc ID 1096837.1)描述,问题为导出的数据中,存在表的字段有空格的问题( A no-name column "" is included in the table definition.)2.找到问题表,重新导出,导入。1.排除问题表,重新导入。
2023-04-25 15:34:09 412
原创 activate standby database时无法找到standby redo的处理
一次在activate standby database方式打开备机时,出现报错无法找到standby redo:ORA-00313: open failed for members of log group 7 of thread 1;处理方式为clear standby redo方式重新生产(路径要正确。
2023-04-18 00:52:44 419
原创 ORA-00600: [12807]错误的分析
近期,一个用户数据库出现无法创建主键约束的情况,分析报错为ORA-00600: [12807];原因为大量的创建、删除表动作(把表当做临时表用),导致CON$值达到4294967294,之后触发Bug 13781691 ORA-600 [12807] if CON$.CON# very high due to bug 13784384。
2023-04-18 00:48:45 321
原创 srvctl不能启动数据库问题ORA-29760 instance_number parameter not specified
在一次数据库迁移过程中,发现数据库使用srvctl start database命令无法启动,ORA-29760: instance_number parameter not specified、PRCD-1120 : The resource for database mes could not be found.等问题,原因的DB_UNIQUE_NAME发生了改变。在11G中无此问题。
2023-04-18 00:42:39 598
原创 ORACLE11.2.0.3版本RAC集群SCAN监听服务注册失败问题
分析SCAN监听程序日志,在RAC节点故障前,listener_scan日志中,两个节点都可以正常注册 service_update关键字可看到。近期,某用户的核心系统RAC数据库节点出现宕机,正常情况下,RAC集群环境一个节点宕机后,SCAN监听服务自动运行在另外一个存活节点,业务可以继续连接使用数据库。本次问题,SCAN监听程序切换到了存活节点,但是存活节点的数据库实例,无法注册到监听程序服务;也就导致程序无法通过SCAN监听连接数据库,导致业务受到影响。3.检查SCAN监听状态、查看程序连接。
2023-02-08 10:32:42 1299
原创 ORACLE Exadata 一体机节点主机重启ib0 (mlx4_core): transmit queue 0 timed out“问题
对操作系统日志中的报错进行分析,系统正常运行时突然出现kernel: NETDEV WATCHDOG: eth3 (bnxt_en): transmit queue 4 timed out告警,之后大量kernel报错、网卡down等报错。查看操作系统日志,可见在08:46:57突然出现: XXX kernel: NETDEV WATCHDOG: eth3 (bnxt_en): transmit queue 4 timed out,之后出现大量kenerl错误并网卡异常,之后主机发生重启。
2023-02-08 10:21:46 829
原创 ORACLE 19C环境WRI$_ADV_OBJECTS占用空间大的问题
巡检发现一个ORACLE 19C环境WRI$_ADV_OBJECTS占用很大空间。在ORACLE 11G时,一般默认会关闭AUTO_SQL_TUNING_PROG、auto_space_advisor_prog这两个自动任务,来避免自动任务执行带来的问题。---参照MOS文档可以先备份数据、TRNCATE后可以数据INSERT回来。
2023-01-02 21:46:13 2067 2
原创 ORACLE 12C环境报错ORA-00904: “DECL_OBJ#“: invalid identifier
按照文档Doc ID 2476156.1)的说明,重新datapatch -verbose或者修改工具的配置方式解决:Open SQL Developer Set the PLScope identifiers parameter (Tools > Preferences > Database > PL/SQL Compiler > PLScope identifiers) from All to None.。最终用户反馈是将列数量降低后,解决的。
2022-12-14 12:59:49 835
原创 Data Guard archive gap检测及解决方案
归档日志间隙是在 Standby 端一系列丢失的重做日志,导致日志应用服务无法继续运行。这通常发生在 Standby 端无法从 Primary Database 接收重做日志或重做日志在 Standby Database 上不可用时。网络连接断开或者日志传输服务停止Standby Database 不可用日志传输服务的配置错误Standby 端的 IO 问题归档日志在应用到 Standby 前被手工删除Primary 和 Standby 之间的网络带宽不足。...
2022-08-18 13:36:08 676
原创 ORACLE 8I环境启动数据库实例时报ORA-01599问题的处理
一个客户的老数据库环境ORACLE 8I在重启时出现问题,报ORA_01599,这是以前人工管理回滚段时的问题,即超过了MAX_ROLLBACK_SEGMENTS参数的值,参要改大此参数即可。MOS文档ORA-01599 Error on Startup of Database After Recovery (Doc ID 107415.1)对此有解释:处理方法及原理如下:cause: The number of rollback segments created for this database
2022-05-20 21:59:56 209
原创 DATAGUARD备机报ORA-01555错误的问题
近期,某用户的DATAGUARD备机,在只读查询模式,隔一段时间就出现ORA-01555错误。在ADG备机中,ORA-01555错误有几个相关的BUG,本次为典型的SQL执行Query Duration=0 sec时报错,可以参考文档ORA-01555 on Active Data Guard Standby Database (文档 ID 1273808.1)来进行排查。一般建议就是安装最新的PSU来规避这些问题,有些可以通过重启或刷共享池等方式解决,也可以在ADG备机上写成定时脚本每天执行来处理此问
2022-05-20 21:55:57 549
原创 ORA-14047问题的处理
有个用户系统异常,需要临时将一个业务表改名,改的时候报错:SQL> alter table RADTS.TEST_HISTORY rename to RADTS.TEST_HISTORYbak; *ERROR at line 1:ORA-14047: ALTER TABLE|INDEX RENAME may not be combined with other operations...
2022-05-20 21:50:23 1213
原创 ORACLE 19C版本RAC重启后无法启动CSS进程问题分析
近期,一个客户新安装的ORACLE 19C版本RAC;在重启主机测试高可用功能时,发现数据库集群无法正常启动。根据集群的运行机制,一步步分析日志,可以发现是CSSD进程启动异常。分析日志,问题在于CRS-1726: Process failed to run in real-time priority;之后CSSD进程异常。这个问题MOS文档CRS Will Not Successfully Restart After Node Reboot (Doc ID 2720950.1)有提到,将/etc/sy
2022-05-19 11:59:20 1542
非IMU模式下一条update语句产生REDO RECORD条数的探究--日志打包
2014-01-07
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人