ITPub博客

浅显的理解（有问题的）：mssm所有段操作都在修改freelist，大批量操作会引起争用。而assm由L1/L2/L3管理块，一般L3可以管16个块（多的64也有），假如L2管200个那这一层就3200了，同时3200个进程一起插入操作没问题，随机分配到3200个块里。小无敌。深刻的理解：1.L3到L2不是随机的，L2到L1是随机的。L2到L1的随机是在高水位线之下的。2.建好表空间后，把某表的分

索引的根块、枝块的查询额度比叶块、表块高很多。索引根块、枝块绝大多数的操作都是读，除非发生索引分裂。普通索引的根块、枝块  和  Unique索引、索引Unique扫描时索引时，索引的根块、枝块、叶块、表块都是以CBC latch共享的模式保护。Unique索引如果Unique索引列使用等值条件查询时（id是Unique索引的索引列，语句为where id=某个值），那索引的根

一 问题描述如果在CDB最初创建时，启用了OMF文件管理功能进行创建，那么生成的所有文件将会使用OMF文件命名格式，此时我们应该如何创建出非OMF文件命名格式的PDB呢。二 使用file_name_convert包含全部数据文件创建PDB2.1.查看种子容器//连接种子容器，查看db_create_file_dest参数：SQL> alter session set container=PD

一、描述1.1 混合分区表的介绍从Oracle Database 19c开始，Oracle数据库支持Hybridpartitioned tables，也就是混合分区表，进一步扩展了Oracle分区技术。这里的混合指的是数据的分布，一些分区可以位于数据库中，另一些可以是位于数据库外部的文件（比如操作系统文件或Hadoop Distributed File System (HDFS) 文件）

open的时候报错ORA-01157 ORA-01110 ORA-27048 问题原因：数据文件的0号块（OS块信息）被更改导致。模拟报错：1.查看0号块信息方法一、（bvi）查看bb01.dbf文件的0开始到96字节（其实看前32字节就行，后面的无关紧要）bvi -b 0 -s 96 /tmp/soft/app/oracle/oradata/WLH/datafile/bb01.dbf方

1.新特性概述其实oracle的统计信息就是存储在数据字典里的一组数据，从多个维度描述了oracle数据库里对象的详细信息。CBO会利用这些统计信息来计算目标SQL各种可能的、不同的执行路径成本，并从中选择一条成本值最小的执行路径来作为目标SQL的执行计划，所以说收集统计信息对于数据库的SQL有着至关重要的作用！oracle数据库会在一个固定的时间将数据库里的表和索引的相关统计信息进行收集。我们可

一 自动化索引Automatic Indexing1.1 新特性概述在Oracle Database 19c引进了新的特性。Automatic Indexing自动划索引功能，顾名思义就是数据库能够根据应用程序工作负载自动管理索引，比如说创建索引，删除索引，重构索引。需要格外注意的是，目前自动索引只支持Oracle Exadata平台 关于自动索引的数据字典:DBA_AUTO_INDEX

方法一（2节点软件不删）1.踢出节点使用root用户登录，并执行下面的命令(所有节点，但最后一个节点除外)  （踢出当前节点）（perl失败，见4）# perl $GRID_HOME/crs/install/rootcrs.pl -verbose -deconfig -force2.跑root脚本加回节点root跑# GRID_HOME/root.sh方法二（2节点软件、实例全卸载）1.

故障说明XX银行数据库二代支付系统业务，在12月13日晚22点出现插入数据卡顿的现象，插入数据的业务表为JHB_IBPS_TXN故障描述工程师分析在22点的数据库等待事件，发现有1000多条的library cache lock等待事件  通过分析22点的历史等待事件发现，所有的会话都被931、以及859的会话锁住，产生了library cache lock的等待事件故障分析当

故障说明在12月19日晚19点半左右，客户收到内部告警信息，二节点集群无法连接服务器，并且通过显示器直连服务器时，任然无法直接连接。故障描述12月19日故障，工程师分析故障时间点集群日志，在17点53分到18点50分之前，都存在大量线程未分配的报错 故障分析查看2022年12月19日2节点的主机日志，发现报大量的内核死锁故障，从而导致后面主机卡死，即使显示器直连服务器也是连接不上。&nb

故障说明在12月27日凌晨5点左右，客户收到业务告警业务无法正常运行，6点半左右将service name服务移到2节点，并且重启1节点主机，恢复业务。故障描述12月27日故障，工程师分析故障时间点数据库alert日志发现大量缓冲区不足的报错，从12月27日00:54分开始一直报错到早上6点半重启数据库。 故障分析12月27日的报错完全匹配上oracle mos上的（Doc ID 204

常用历史语句：dba_hist_active_sess_historyv$active_session_historydba_hist_sqlstat  dba_hist_active_sess_historydba_hist_active_sess_history是v$active_session_history的持久化视图。多个触发条件写入dba视图中。 mmon

汇总：硬解析Hard parses解决方法：1.绑定变量2.看shared pool是否太小或者变小（子游标放在Sga-shared pool-library cache）awr 搜shared pool可以看到大小改变：这时候如果出现大量的硬解析，就会出现这个等待。最终的原因是因为一个全表扫描导致oracle的SGA自动管理把share pool缩小来增大DB CACHE，踢出去了一部分的执行计

按1可以看每个cpu的使用情况第一行当前时间   运行时间   当前登陆用户   负载均衡（1分钟、5分钟、10分钟）load average数据是每隔5秒钟检查一次活跃的进程数，然后按特定算法计算出的数值。如果这个数除以逻辑CPU的数量，结果高于5的时候就表明系统在超负荷运转了第二行总共248个进程    &nbsp

故障描述2023年06月30号，客户应用反馈imagedb数据库无法登录。原因分析检查cpu使用正常；内存耗尽只剩余200M左右的空间。检查会话，大概有800个左右的会话，如下图所示： 检查执行计划： 经过检查，SQL走IDX_SER_CKINVOICE_NUM这个索引是没有问题的，执行计划没有问题。检查活动会话的等待事件：EVENT      &

可能性1：rac参数文件没有*.cluster_database=true可能性2：原因：实例已经关闭，但是共享内存段还存在。oracle认为内存还是锁住的。1.到dbs下，可以看到一个lkabcd(abcd是实例名，=lk实例名)2.mv掉lkabcd3.注意用大小写ps -ef |grep ora_ |grep abcd存在后台进程的话kill掉即可kill -9 xxxxx4.起库即可

ORA-03137: TTC 协议内部错误: [12333] [11] [88] [72] [] [] [] []

大概率删除备份片的时候，想删除过期备份片，报错。但是发现实际备份片的物理文件已经之前被物理rm删掉了。解决方法：检查备份（如果完整检查备份没看到删了的备份，就单独crosscheck备份）crosscheck backup;或者crosscheck backuppiece '/data1/backup/jiangsu/20080814_iljnvkad_1_1';或者crossch

故障描述       2023年09月14号 9:33左右，客户反馈his数据库可能存在问题，当时数据库可以使用，应用比较缓慢。让检查数据库是否存在问题。       排查过程中，业务那边反馈问题从8点左右就开始，应用页面报错如下图所示：原因分析-ORA-30006应用页面报ORA-30006错误，检查早上8:00左右

故障描述2022年7月16号早上9点49左右，客户jsbas生产库。客户反馈应用系统慢并且报超时错误； 后续反馈应用用户无法连接数据库，其他用户登录没问题。这套RAC环境总共6个节点，上面运行5套数据库。  出问题的是jsbas数据库，jsbas数据库实例运行在节点3，4，5，6。其他数据库都正常。临时处理方法检查当前等待事件：检查发现，大部分都是library cache lock等待