ITPub博客

故障描述时间脉络：故障时间（2025年01月10日）故障现象处理动作08:33hihis数据库出现卡顿迹象工程师开始排查故障08:33～08:48hihis数据库出现卡顿迹象服务器卡顿，排查动作受阻，准备切换容灾08:48～08:55hihis库服务器重启hihis主库重启完切换容灾08:55～当前数据库排查故障排查数据库故障原因，支持应用厂家恢复业务 2025年01月10日08点20分

1.Awr报告抓取问题语句   2.绑定变量、字符集、格式调整select a.jlxh,        b.zyhm,        b.brch,      &

现象描述        2025年11月06日19:00开始关闭his库1节点，准备更换内存。于19:46完成关库动作，开始更换内存。业务于20:04发现连接不上。20:15一节点服务器启动，尝试恢复业务，20:44分scan切换完成，业务恢复。问题详细诊断一节点于19:00开始shutdown immediate关库，一直卡住

一、故障描述故障简述客户RAC节点2集群无法启动。操作系统linux   6数据库版本11.2.0.4   RAC 二、处理过程步骤动作【检查环境】检查集群日志，确认异常节点2集群无法读取Voting File导致。【OCR磁盘组修复】通过NFS临时添加OCR磁盘。添加成功，Voting   File问题修复。【RAC部分进程端口号冲突】通过排查发现节点1、

一、故障描述1.客户生产库出现卡顿现象，cpu跑满，排查。2.一线工程师事后查看dba历史视图发现与卡顿时间看到的event不同。 二、问题详细诊断过程1、问题一（卡顿）根据cpu消耗排序查看语句与等待事件（方法很多、非唯一）set line 222 pages 999 col username for a10 c

如图所示可在plsql中形成线形图时间范围/节点自己改一下set linesize 300SELECT  TO_CHAR(TRUNC(ash.sample_time, 'MI'), 'YYYY-MM-DD HH24:MI') AS minute_interval,  ash.snap_id,  ash.instance_number A

 Fri May 31 22:33:12 2024WARNING: cache read  a corrupt block: group=1(DATA) fn=1 blk=5137 disk=0 (DATA_0000) incarn=2212612836 au=5 blk=0 count=256Errors in file /u01/app/grid/diag/asm/+asm

如果发现解析有问题，只认第一个scan ip默认是multi on的（可多个scan ip），如果off的话会导致该问题 1.修改hosts 2.确认sacn信息srvctl config scansrvctl status scansrvctl status scan_listener  3.关闭scan监听、scan服务srvctl stop scan_

7.tidb缓存7.1虽然结果都是从tikv中读出，但是执行计划中使用了表连接、hash join、子查询，做不到从某个tikv中得到数据，可能散落在多个tikv中。从多个tikv中汇聚到tidb server的缓存中，汇聚成2个表，然后两表再做连接。7.2事务（比如要改3g的数据）要先放缓存中，然后提交。 7.3线程池需要缓存。 7.4解析、编译中用到的元数据也放在tidb

4.sql语句的执行 解析好的执行计划给到excutor，excutor去执行 执行计划。复杂：范围查询、join、子查询、表连接、嵌套查询等等，走distsql模块，将对tikv复杂的请求封装起来，提供一个简单的方法。最终呈现：转化成多个对单表的范围查询。 简单（点查）：根据主键索引、唯一索引进行等值查询，查一行或零行的这种，走KV模块。  点查（KV）和

1.处理客户端的连接protocol layer 2.sql语句的解析和编译语句解析和编译（parse、compile）解析 编译 前面语法解析完生成的ast语法树传给compile验证（preprocess）：合法性验证，表是否在数据库中存在等等逻辑优化：不需要的列消除（类似去重distinct）、外连接变内连接、等等物理优化：根据前面的结果，结合统计信息，去看走全

1.protocol layer（处理客户端的连接）parse、compile（sql的解析和编译，生成执行计划）主要负责sql语句的解析和编译（可以理解为优化），生成语句的执行计划给excutor执行2.excutor（拿着执行计划到tikv节点上执行）distsql（索引扫描查由这个负责）kv（点查，根据索引之类的，直接从kv里找）sql语句的执行执行计划给excutor来执行、distsql

主库：查看闪回功能是否开启select flashback_on from v$database;创建闪回空间路径mkdir -p /oracle/fast查询归档一天的产生量，根据割接的时长，配置对应的闪回区大小。select to_char(completion_time,'yyyy-mm-dd') as date1,count(0) a

手工打补丁错误汇总1.rootcrs.pl -prepatch execution failed2.OPatch failed with error code 733.OUI-67073错误一(rootcrs.pl -prepatch execution failed)在跑二步骤的2节点命令时，若出现下图错误，建议手动关集群之后重新再跑一遍命令。手动关集群方法root:<grid_home&

跟踪会话的级别Level 1：跟踪SQL语句，等于sql_trace=trueLevel 4：包括变量的详细信息Level 8：包括等待事件Level 12：包括绑定变量与等待事件16  在11g中为每一次执行生成STAT信息，仅在11.1之后可用32  比level 1少执行计划64  和level 1 相比 在第一次执行后还可能生成执行计划信息 ； 条件是某个游标

介绍：作为官方的rac监控，oswatch有着至关重要的作用，可以协助dba进行详细排查。在系统卡顿、网络异常等情况下，外部通过网络的监控检测不到内部情况，而oswatch很好的解决了这个问题，因为它是布置在服务器上的，并且性能消耗极低。下载：mos ID 301137.1OSwatch安装:1、创建osw空间 在RAC集群两个节点上分别建立Oswatch目录/osw，大小为5

概念：大意就是，通过dblink连接另一个数据库的表是，对另一个数据库的表进行dml操作，同时也可能在同一个事务中对本库中的本地表做事务提交操作，那么对于dblink的表，需要确保远端的数据库也要提交，那么在本地像远端确认提交的时候，先由本地库发一个prepare的确认信息，远端回复prepare了以后，本地在执行commit信息；此种情况就是在本地执行commit以后，此时远端库还没有完全com

1.全表扫描TABLE ACCESS FULL多块读优化方式：前面带*，有谓词。访问的列少的话，存在多个谓词过滤条件（where），创建组合索引，选择性高的放前面，顺序排放2.rowid查询使用rowid获取数据，单块读，性能最好TABLE ACCESS BY USER ROWID 产生原因：对rowid进行等值查询where rowid='xxxxxxxxxxxx'优化

背景XX银行一套业务系统反馈晚上跑批非常慢，后来客户发现是在处理truncate分区表分区的时候慢。数据库版本 12.1.0.2操作系统类型 linux初步分析truncate的实质是在不修改数据块的情况下，通过修改segment header的data_object_id,hwm,extent map，aux map等信息来实现清空表的目的，其中还涉及数据字典基表以及L1、L2位图块的修改，所以

误操作truncate oracle bbed 修复