- 博客(36)
- 资源 (1)
- 收藏
- 关注
RSS订阅原创 一次TongWeb应用问题处理的经历
摘要：本文记录了东方通中间件系统三个典型问题的排查与解决方法。问题一为控制台访问异常，原因是启用了DNS解析，通过移除主机DNS配置解决；问题二为数据库连接故障，诊断发现是虚拟机与物理机MTU值不匹配（1500 vs 1450），调整虚拟网卡MTU值后恢复；问题三为JVM Metaspace内存溢出导致前台崩溃，通过分析jstat监控数据发现Metaspace持续GC，最终增大MaxMetaspaceSize至512MB解决。三个案例展示了从现象观察、日志分析到参数调整的完整故障处理流程。（149字）
2025-06-17 10:40:47
484
原创 Oracle集群OCR磁盘组掉盘问题处理
摘要：HP-UNIX环境下的Oracle 11.2.0.4两节点RAC集群发生OCR磁盘组故障，/dev/rdisk/disk52被自动踢出磁盘组导致仲裁盘从三块减为两块。问题表现为集群仍能运行但冗余性降低。分析显示故障磁盘虽被offline_drop，但磁盘头仍保留元数据，直接添加会报错。解决方案包括：1）清除原磁盘头信息后重新加入；2）使用新磁盘替换（推荐方案）。通过测试环境验证了强制添加磁盘的方法，但生产环境建议采用方案2以确保安全。最终通过adddisk force命令成功恢复三副本冗余，ASM自动
2025-06-11 10:15:10
817
原创 问题复盘-当前日志组损坏问题
Oracle日志组损坏场景恢复方法总结 在CentOS7/Oracle11g测试环境中，当当前日志组所有成员被删除后，数据库不会立即崩溃（因文件缓存机制），但后续切换时会出现问题。分析发现：1)事务提交仍可用内存缓存；2)日志切换时因磁盘文件缺失导致操作卡死。 解决方案： 文件恢复：通过lsof找到进程ID，从/proc/<pid>/fd/<fd>复制文件内容 数据库未崩溃时： 执行完全检查点 尝试强制清除未归档日志组 数据库已崩溃时： 基于日志的不完全恢复 使用闪回数据库 终极方案
2025-06-09 17:25:20
916
原创 数据库会话锁定监控与会话简单管理
监控数据库会话锁定对象状态的脚本有助于分析和解决资源争用或性能问题，通过查询相关视图获取会话和锁定对象的详细信息，并根据需要终止会话以避免潜在风险。
2025-06-06 10:30:09
230
原创 Oracle勒索病毒故障恢复的案例分析
摘要：客户Oracle 11g数据库突发连接故障，日志显示存在ORA-600[16703]和ORA-07445错误，经分析确认是安装介质被植入木马导致。问题表现为数据库运行超300天后重启会清空TAB$基表。解决方案包括： 有备份时优先采用逻辑备份恢复或RMAN修复system表空间 无备份时需跨平台使用BBED工具修复： 从10g介质提取库文件在Linux编译BBED 通过同平台正常数据库文件进行块级修复 针对删除标记(0x3c)进行反向修改 最终建议：严格管控安装介质、做好多重备份、建立高可用架构，出现
2025-06-05 10:18:38
579
原创 一条MySQL数据库慢SQL优化思路详解
（这个也是来自于oceanbase）物化视图这个概念是oracle中存在的，它比普通视图多了物化两个字，其与前者的区别就是物化视图不光在数据字典中存储视图定义，还负责将该视图得到的结果存放到数据文件中的数据块里，成为一个“实体表”，物化视图的意义就在于省去每次调用视图时重复运算视图定义的过程，也避免了多次调用视图可能会导致视图合并而带来的性能问题，除此之外，对基表建立物化视图还可以起到降低逻辑读，查询重写的好处。在SQL中可以发现大量的关联子查询，半连接，函数计算等等，按照查询逻辑来说算是比较复杂的。
2025-06-03 10:25:47
761
原创 Cache数据库的高可用架构设计与选择
要启用自动故障转移，镜像必须包含两个故障转移成员，物理上独立的系统，每个都托管一个 Caché 实例。在任何给定时间，一个故障转移实例充当主要实例，为应用程序提供对镜像中数据库的访问权限，而另一个充当备份实例，维护这些数据库的同步副本，以准备接管作为主要实例。当主 Caché 实例变得不可用时，备份将接管，提供对数据库的不间断访问，而没有数据丢失的风险。当然镜像成员的类型还分同步和异步，这里不再详细阐述。
2025-05-30 10:09:48
957
原创 常见的SQLserver问题排查
摘要：SQLServer管理和维护需有效利用内置功能及第三方工具进行问题诊断。内置功能如动态管理视图(DMVs)、查询存储、扩展事件等，可帮助分析性能瓶颈和追踪操作。第三方工具如Redgate、SolarWinds DPA提供更直观的监控和分析功能。常见问题场景包括：1) CPU问题排查，通过活动监视器和系统视图追踪高CPU使用SQL；2) 执行计划分析，使用多种方法显示执行计划；3) 内存占用分析，检查内存模块分配和数据库缓存情况。这些方法能快速定位问题，提高管理效率。
2025-05-29 10:42:13
376
原创 Oracle20200714GI_PSU补丁流程及问题收集
本文详细记录了Oracle 11gR2 RAC集群升级PSU补丁的全过程。主要内容包括：1) 准备工作，停止集群并备份；2) 检查并升级Opatch工具版本；3) 解压并应用补丁包31326410；4) 执行数据库升级脚本；5) 处理升级过程中出现的各类问题，包括中文目录报错、集群启动失败、权限问题等；6) 最终通过手动应用补丁和调整权限使集群恢复正常。文章提供了详细的操作命令和错误排查方法，对Oracle RAC环境升级具有重要参考价值。整个升级过程涉及补丁安装、集群管理、故障诊断等多方面技术要点。
2025-05-27 09:43:11
594
原创 SQLserver数据库insert为啥会阻塞select？
摘要：在SQLServer测试环境中复现了INSERT阻塞SELECT的问题。分析发现这是由于默认READ COMMITTED隔离级别的特性所致，未提交事务会阻塞其他会话的读取操作。通过启用SNAPSHOT隔离级别可避免此阻塞，但需注意其对系统性能的影响。测试证实切换至SNAPSHOT隔离级别后SELECT查询不再被阻塞，但关于快照隔离两个子级别的差异仍需进一步实验验证。
2025-05-26 09:32:06
745
原创 Oracle查看SQL执行计划的方法
通过这些方法，我们可以更深入地理解SQL语句的执行过程，并据此进行性能优化，虽然文档提供了多种查看执行计划的方法，但在实际应用中，如何根据不同的业务场景和性能需求，选择最合适的执行计划查看方法，以及如何根据执行计划的结果进行有效的SQL优化，仍然是一个值得深入探讨的问题。当检测到符合条件的SQL执行时，Oracle数据库将默认启动对该SQL语句的监视过程，并将收集到的相关数据存储于专用的内存区域中，以便后续用于性能分析与优化。在Oracle数据库中，执行计划主要分为两类：估算的执行计划和实际的执行计划。
2025-05-23 09:54:10
1016
原创 Oracle RAC节点时间差异同步测试
本文探讨了Oracle RAC集群中节点时间同步的重要性及其对集群稳定性的影响。通过四个测试案例，分析了不同时间同步设置对集群运行的影响。测试结果表明，即使节点使用不同时区或时间调整，只要时间差异不大，集群仍能正常运行。然而，显著的时间偏差可能导致数据错乱，需通过NTP或ctssd进行同步。文章还提出了单节点时间修改的可行方案，并指出在时间差异较大时，需先停止服务以避免数据不一致。最后，文章提出了关于时间差异触发集群脑裂的遗留问题，为后续研究提供了方向。
2025-05-22 09:40:12
1002
原创 一次mysql备份影响业务的案例分享
2024年5月14日上午9时左右，急诊业务出现异常，业务人员发现MySQL主机的xtrabackup进程占用大量CPU资源。处理过程中，业务人员杀掉了xtrabackup进程后，业务恢复正常。问题原因在于主机定时任务中的backupmysql.sh脚本在9时执行，调用xtrabackup进行数据库备份时，由于数据库中存在长查询，导致备份进程卡住，进而影响其他远程连接线程。解决方案包括优化业务层面的慢查询、设置数据库层面的慢查询超时时间，以及增加备份时的锁等待超时时间。通过这些优化措施，可以减少xtrabac
2025-05-21 09:32:09
342
原创 记一次UNDO爆满的排查分析经历
很快业务就给出了反馈，20日涉及到这个SQL的更新比对模块确实出现了问题，基本上是锁了一整天，经分析是数据站点数据转码出现了问题，原更新的筛选列ID全部变成了0，这可真是个大批量的数据更新啊，如此大批量的更新对UNDO的需求量也很大，这也是一大早就发现UNDO爆满的原因，再加上有并行操作的原因，锁的问题最终引起了业务的重视，就直接杀掉大量会话，后来的事情就很明显了，触发并行事务回滚导致数据库争用回滚段造成大量wait for a undo record等待事件，ORA-01555报错不断。
2025-05-20 14:27:24
701
原创 Xtrabackup备份阻塞测试以及优化思路
Xtrabackup是一款广泛用于MySQL和MariaDB数据库的开源备份工具，支持热备份和增量备份。然而，在实际使用中，Xtrabackup备份操作可能会对数据库的正常查询产生阻塞影响。通过测试发现，当数据库中存在长查询时，Xtrabackup在执行FLUSH NO_WRITE_TO_BINLOG TABLES步骤时会被阻塞，导致备份线程卡住，进而影响其他查询操作。为解决这一问题，建议从数据库层面优化慢SQL，并设置max_execution_time参数。此外，可以通过调整Xtrabackup的--f
2025-05-19 10:15:37
725
原创 一个日志量突增的问题分析处理经历
在一次日常巡检中，发现生产区集群的一个实例在周末出现了日志量突增的异常情况。通过分析告警日志和AWR报告，发现日志组切换频繁，检查点未完成的情况异常增多。进一步调查发现，这是由于一个物化视图采用了完全刷新的方式，导致大量日志产生。物化视图的基表数据量大且频繁更新，加上手动刷新操作，进一步加剧了日志量的增长。最终，通过将物化视图的刷新方式改为增量刷新，解决了日志量突增的问题。此次经历强调了物化视图在OLTP系统中的使用需谨慎，并需根据实际情况选择合适的刷新方式，以避免对系统性能造成不利影响。
2025-05-14 15:27:33
558
原创 重建控制文件的几种考虑情况
在重建Oracle控制文件前，需优先从备份中恢复控制文件。重建控制文件仅在以下情况下进行：所有当前控制文件丢失或损坏、备份中的控制文件损坏或缺失、需要更改控制文件中的硬限制参数、或将数据库迁移到另一服务器且文件位置不同。官方推荐使用CREATE CONTROLFILE命令重建控制文件。重建前需确认数据库是否能够挂载（mount）以及redo日志是否损坏。如果数据库可以挂载且redo日志未损坏，可直接在挂载状态下执行备份脚本并重建控制文件。若redo日志损坏，则需使用RESETLOGS方式重建控制文件，并进行
2025-05-13 09:31:40
610
原创 Oracle集群多副本控制文件异常问题
系统名称集群中的Oracle RAC 11.2.0.4数据库实例频繁重启，告警日志显示控制文件头块返回的序列号过旧，可能已损坏。问题发现后，建议的处理步骤包括保存控制文件副本、挂载实例并备份控制文件到跟踪文件、卸载实例，并使用跟踪文件中的脚本重新创建控制文件以打开数据库。问题原因可能是存储系统故障导致控制文件被旧版本覆盖。解决方案包括优先排查存储问题，必要时重新创建控制文件，并在存储问题解决后，根据情况决定是否执行进一步操作。建议在数据库可操作时备份控制文件，并考虑重新创建控制文件的相关测试和问题。
2025-05-12 09:31:30
1006
原创 一次TEMP 表空间爆满问题排查处理
4月5日下午，业务系统因数据库性能问题导致运行缓慢，业务停滞。检查发现TEMP表空间爆满，扩展至1.2T，且以每秒1G的速度增长。通过AWR报告分析，发现一条SQL语句因产生笛卡儿积导致大量排序和表连接操作，严重消耗TEMP空间。该SQL语句执行计划成本高达23G，实际占用TEMP空间330G，导致数据库性能急剧下降。通过SQL Monitor实时监控，确认该SQL仍在执行并持续消耗资源。最终，通过杀死相关会话稳定了TEMP表空间使用率，并在下班时间手动收缩表空间。后台研发分析认为前台模块入参出现问题，对该
2025-05-09 09:31:47
862
原创 一次通过osw分析数据库性能问题的经历（二）
本次性能排查还真是发现不少问题，实际上这个数据库系统更偏向于OLAP，注重数据比对功能，系统中还是有很多问题需要管理员与业务多多配合处理。但是那句话怎么说来着，ORACLE固然高效但复杂，系统性能调整这一块一定要遵循几个准则：1）自顶向下，抓主要矛盾2）选择可获得最大收益的事件入手3）目标达到后见好就收
2025-05-07 10:27:34
636
原创 一次通过osw分析数据库性能问题的经历（一）
OSW是非常好用的工具，对于数据库管理员来说还需要关注服务器主机资源的损耗，以防性能隐患，服务宕机后也可以通过相关快照获取更多的信息以定位问题根源。
2025-05-06 10:08:12
1056
原创 SQL优化学习-动态采样的妙用-level34
在执行计划中，如果表的行数估算出现显著偏差，比如由于相关列问题、多列连接导致的低估、WHERE子句中使用了substr、instr、like等函数，或是存在非等值过滤条件，以及GROUP BY操作后引发的估算不准确等情况，建议采用动态采样技术来改善这一状况。同时，推荐将动态采样的级别至少设定为4级，以确保更精确的数据分析和处理。
2025-04-30 16:34:06
731
原创 SQL优化学习-动态采样的妙用level2
作为Oracle数据库的默认动态采样级别，Level 2针对未收集统计信息的表启用动态采样机制。在此级别下，系统将对表进行64个数据块的采样；若表的实际数据块数量少于64，则会对其全部数据块进行采样。基于此逻辑，对于那些数据块数量接近或不超过64的小型表而言，在无特殊查询需求的情况下，似乎没有必要额外执行统计信息的收集工作。
2025-04-29 16:38:25
552
原创 Oracle数据库锁问题的抓包分析（猜想）
很多时候我们在排查数据库历史问题（尤其是锁表情况），需要理清楚过去一段时间甚至当前时间段内数据库某些会话都执行过什么SQL语句，如果客户的现场没有审计设备，数据库也不可能把所有会话的SQL操作都记录到ASH视图中，这个时候我们可以在服务端或者客户端进行抓包(tcpdump)。
2025-04-28 11:42:35
713
原创 SQL优化学习-表与表之间的关系
在Oracle数据库的SQL优化过程中，明确表间关系至关重要，这对于SQL性能优化及等价改写尤为关键。关系型数据库中表与表之间的关联类型主要可以归纳为以下三种：
2025-04-27 11:46:27
633
原创 Oracle GoldenGate19c & Oracle GoldenGate Veridata12c 实验（二）
一、部署Oracle GlodenGate Veridata软件Oracle GoldenGate Veridata不需要安装OracleGoldenGate复制软件。如果您确实使用该软件，请在其他位置安装Oracle GoldenGate Veridata。在为您的操作系统安装经过认证的JDK之后，请使用Oracle Fusion Middleware12.2.1.4.0基础结构安装程序来安装Oracle WebLogic Server 12.2.1.4.0和Oracle Java必需文件（JR
2021-02-26 09:33:05
774
原创 Oracle GoldenGate19c & Oracle GoldenGate Veridata12c 实验（一）
Oracle GoldenGate19c & Oracle GoldenGate Veridata12c 实验 **概述** 文档类别测试文档文档时间2021-02文档标题对Oracle GoldenGate及Ogg Veridata功能验证（一）作者Ora_Ckpt_Lu **目的** 1.Oracle
2021-02-25 10:32:24
1129
原创 达梦数据守护（单主备）集群实践
1.0自杀实验故障自动切换模式下，必须配置确认监视器，且确认监视器最多只能配置一个。#关闭主库服务器[root@Centos7-STD root]# reboot查看监视器#捕捉到主库异常[monitor] 2020-11-13 15:22:52: Received message timeout from(GRP1_PR) WTIME WSTATUS INST_OK INAME
2020-11-16 15:46:07
568
原创 达梦数据守护（单主备）集群
1.1安装规划角色配置实时主备，需要俩块网卡，一个外网网卡对外提供访问，一个内部网卡为mal系统传递归档文件实时主备需要配置数据守护进程（dmwatcher)，分别在俩台主机上配置相同数据守护监视器用来监控主备集群状态及主备角色事件变更，可以部署至远程节点，这里直接部署至主节点端口规划一台主机部署实时主备，需要四个端口，分别为实例、实例watcher、mal实例、mal实例watcher端口操作系统：Centos7.4DM版本：DM81.2主机配置俩台主机均采用最小
2020-11-16 15:37:24
510
原创 Oracle Smart Flash 新特性性能测试说明
Oracle Smart Flash 新特性性能测试说明1.1测试之前的工作1.1.1 Oracle Smart Cache简介1.1.2 Oacle Smart Cache测试方向1.1.3 Oacle Smart Cache 测试环境1.1.4 Oracle Smart Cache测试实现办法1.1.4.1 准备工作1.4.1.2 设置数据库相关参数1.1.5 Oracle Smart Ca...
2020-04-14 15:55:31
739
1
原创 一次超详细oggDDL单项复制配置记录
一次超详细oggDDL单项复制配置记录OS层面的配置清单配置大致过程（source与target）1.1 修改IP地址，hostname，添加hosts信息1.2 创建相关的用户，用户组，用户分组,目录分配1.3 oracle用户的环境变量~/.bash_profileDATABASE层面配置清单基本信息DBCA建库SOFT 层面配置清单1.1 基于单向的source-target原理介绍1.1....
2020-04-10 17:05:16
1969
原创 一次Oracle频繁DeadLock问题分析处理经历
一次Oracle频繁DeadLock问题分析处理经历事件描述处理过程分析结果事件描述早上十点，客户电话打来，描述了一下业务缓慢，卡的已经不能正常进行下去，几句询问赶紧着手处理。接过远程后，赶紧连上数据库服务器查看资源状态，发现整体状态趋于正常，询问客户，得知目前业务已恢复正常，就是刚刚卡的进行不下去。这是怎么回事呢？好吧，首先翻看告警日志，发现早上九点到十点钟死锁报错间断进行。...
2020-04-09 15:37:40
3047
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人