- 博客(601)
- 资源 (6)
- 收藏
- 关注
RSS订阅
原创 关于我的介绍
关于我：姓白，常被称"白工"、"小白"；就职于国内某知名专业第三方数据库服务厂商，具有多年专职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
578
原创 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
258
原创 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
373
原创 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
303
原创 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
718
原创 Oracle Exadata的SCAN监听程序异常重启问题分析
1、在这个Oracle Exadata环境，有多个数据库，未有人反馈问题，初步判断大部分系统是正常的。停止程序后，监听日志查看正常不再有高频连接，此后SCAN监听未发生过重启，系统恢复正常。2、SCAN监听问题，用了2、3个数据库的SERVICE_NAME去连，都有问题，判断为SCAN监听问题，不是个别数据库问题。常规思路下，遇到次问题，有一系列的排查、排除方向，去定位和处理问题。3、根据有问题的IP，找软件维护人员查看，关闭对应程序后，系统恢复。3、用VIP进行连接，连接、查询均正常。
2024-02-29 14:21:58
458
原创 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
389
原创 一次存储盘异常引起的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
756
原创 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
982
原创 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
495
原创 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
984
原创 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
2652
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
2042
原创 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
348
原创 一次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
672
原创 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
382
原创 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
270
原创 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
776
原创 中国南方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
2636
原创 一次业务系统无法使用对应的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
2951
原创 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
942
原创 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
937
原创 Exadata Stroage node reboot导致集群异常及Database crash分析处理
按Exadata一体机的冗余设计，单个存储节点重启是不影响集群及数据库运行的，本次存储节点故障却导致了CSSD进程异常、数据库实例 crash宕机，属于较为严重的故障。近期，有客户的Exadata一体机遇到存储节点重启，导致集群状态异常、Database crash。可以发现出现了IO异常，ASM中磁盘数据不一致，之后CKPT进程KILL了数据库实例。1.数据库实例crash宕机时信息分析。
2023-04-26 16:43:49
759
原创 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
639
原创 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
319
原创 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
595
原创 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
1294
原创 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
822
原创 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
2048
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
833
原创 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
208
原创 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
548
原创 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
1204
原创 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
1534
非IMU模式下一条update语句产生REDO RECORD条数的探究--日志打包
2014-01-07
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人