Oracle、MySQL、PostgreSQL/openGauss、达梦、OceanBase数据库比较系列(十六): Index scan MIN/MAX
在关系数据库中常见的一种需求统计表的记录的最大值或最小值,SQL中使用max min,为了最佳效率通常希望可以在列上创建索引,减少表段的IO量,如果可以可以使用更佳的执行计划如直接访问索引的头和尾(btree index的有序结构),减少index 块的访问,我们对比一下几款数据库在该方面的能力。
提供综合数据库运维服务与优化方案(不限Oracle MySQL PG GaussDB GoldenDB OceanBase等), 微信/Tel:(+86)134-365-60330
数据库oracle
在关系数据库中常见的一种需求统计表的记录的最大值或最小值,SQL中使用max min,为了最佳效率通常希望可以在列上创建索引,减少表段的IO量,如果可以可以使用更佳的执行计划如直接访问索引的头和尾(btree index的有序结构),减少index 块的访问,我们对比一下几款数据库在该方面的能力。
近期一套Oracle Database 12c (12.1.0.2.0)数据库在RAC ADG , 在standby端一个查询select语句涉及分区表, SQL解析时触发ora-600 [kksgaGetNoAlloc_Int0], [34], [24], 因为11.2.0.4对分区表对象在DDL后除了基础对象外引入了一个KGL handle 多版本对象,当分区计数和详细信息之间不匹配报错。
今天在调试我的oracle数据库巡检脚本odbhc时,发现一套19c rac 测试库的top 1 event为 “dispatcher listen timer” , 影响脚本的显示,该数据库并没有配置共享会话模式,实际上是一个idle wait event算是AWR统计类Bug 19865595 , 后期版本已修复。
最近在做一批Oracle database datafile 从1个ASM diskgroup 迁移到另1个ASM diskgroup时,单个datafile一直无法完成或挂起或多出几倍的时间,正常时1个datafile 30g在150s, 而突然间变的600s都没有完成, 数据库版本oracle 11.2.0.4 。 问题时尝试查询v$asm_diskgroup[_stats]或asmcmd lsdg一样很慢或hang。 登录ASM实例查询会话在等待“buffer busy”和”GCS lock esc” 这里简单的记录一下。
最近一个客户的数据库归档空间满,导致数据库挂起,无法连接,sys登录时提示ORA-00257: Archiver Error, 确认数据库使用的是flash recovery area,从oracle 10g R2提供了V$FLASH_RECOVERY_AREA_USAGE 可以查看flash recovery area中每类文件使用的比例,但是加起来不足10%,且当前flash recover area size已经达2TB, 因为无法远程,临时更改数据库归档路径为具体ASM DISKGROUP不再使用FRA, 这里简单记录一下排查方法
近期一个客户oracle 11g 11.2.0.4 的环境, 业务出现拥堵, 活动会话的等待事件是latch free, 并且P2# 显示是一个不常见的mostly latch-free SCN ,简而言之就是过去oracle版本用这个latch 保护scn,现在已经不在需要的一个latch bug.
如果你不幸数据库在启动时提示ora-600 16703,那很可能是从网上下载安装的oracle数据库软件安装介质中被人篡改了, 增加了启动时判断启动时间,然后删除tab$数据字典的老套的破坏方法, 这个网上的修复方法很多,情况有时也不同,建议找专业人事修复且不要造成二次破坏,这种如果只是最初的版本,修复还是相对比较简单,顺利的话个半小时,0数据丢失恢复
当您尝试在其中一个数据库会话正在执行 NOLOGGING 操作时,尝试将数据库置于 FORCE LOGGING 模式时,将观察到“enq: XR – database force logging”等待事件。这很容易证明。 连接到数据库(例如会话 1)并执行 NOLOGGING 操作:通过从不同的会话(例如会话 2)执行以下 SQL,将数据库置于 FORCE LOGGING 模式:您将观察到 Session-2 不会立即完成,而是等待enq: XR – database force logging。
oracle ASM 从12c后引入了诸多特性,如FLEX ASM、Increased ASM storage limits、ASM instance V$ACTIVE_SESSION_HISOTRY 、ASM Disk Scrubbing外,最近发现还有一个关于ASM DISK rebalance 的增强EXPLAIN WORK FOR命令。12c 中新的 EXPLAIN WORK FOR 语句测量给定 ASM rebalance所需的工作量,并将结果输入 V$ASM_ESTIMATE 动态视图中.
近日,一位客户的Oracle 19c(19.18)环境中出现了一些查询堵塞等待较高的“latch free”情况。通过分析AWR报告中的ASH(Active Session History)数据,我们发现某些查询频繁等待“latch free”,并且p2值对应的latch号为39,latch名称为“object stats modification”。
“latch free”等待事件在Oracle 11g之后相对较少见到,通常我们会看到具体的latch名称。 “object stats modification” latches 又是一个较为罕见的等待事件。为了便于后续跟踪和分析,这里记录一下该问题及其相关细节。
oracle 11g R2环境1组normal冗余的ASM DISKGROUP包含3个cell的,每个cell为1个failgroup, 每个failgroup有48块ASM disks.因为一些硬件原因1个cell掉了19块disk,但offline后并未reblance完成,超过了“_asm_disk_repair_time”时间内没有online,被磁盘组自动drop force, 手动reblance时因为有1块asm disk使用不均衡free接近0MB,所以rebance会提示ora-15041错误。 此时add force与undrop均报错ora-15047. 处理rebalance需要空间,但加空间需要等上一个reblance完成的死结循环中。
SQL Translation框架是 12c 中的一项新功能,使开发人员能够在不更改底层代码的情况下替换SQL代码。这个特性是sql profile baseline的增强,原来是可以不动SQL文本替换执行计划,现在是连sql文本都可以“隐式”替换。这功能可用于在异构数据库向oracle迁移时,替换SQL代码。
《如何恢复Truncate sys.IDL_UB1$?》之前分享过这个对象被清空时的恢复,近期又有用户发现system表空间占用较大,发现IDL_UB1$是top对象,于是乎采用取表DDL,rename原表名,新建该表,数据导出导入方式重建该表。但是发现rename IDL_UB1$表,新创建IDL_UB1$后,exp无法导出,所有DDL无法执行, 包括无法rename回退,庆幸的是当前数据库还没有重启,否则就无法正常启动了,恢复更加复杂。
前不久一套oracle 12c RAC环境,客户反馈数据库出现过行锁enq: tx row content和library cache lock。blocker session为dbms_scheduler执行的sql是在收集统计信息,同时db alert log频繁提示qsmqChkOCMV : Timeout while locking object:NNNN, 简单记录.
最近客户一套oracle 19.14 standalone Database做的cascade dataguard环境,暂且认为是A->B->C三台单实例, 但总是A->B的延迟,从oracle 12c后引入real time cascade,所以如果依赖该特性对延迟要求较高, 分析A->B延迟发现,B库总时会出现GAP,并且未自动FAL,需要人为干预, 并且主库alert日志报错出现:
ORA-03135: connection lost contact
TT02 (PID:64459): Error 3135 for LNO:3 to“xxx”。
最近一套oracle 11.2.0.3 2-nodes RAC on AIX环境数据库,触发ora-600 [kjucvl:!busy] 和 ORA-00600: , : [kjuscv]后db instance crash, 但重启后使用plsql dev客户连接实例的两个节点,sysdate返回不同的时间,同时从db alert log 的时间也能发现实例重启后日志倒退了8小时,看来还是timezone问题,简单记录。
试想一下如果你的OpenGauss或postgreSQL数据库主机告警使用率超过了90%, 且因为使用local 存储,所有硬盘槽位已用完,除了迁移或扩展外部存储以外,是否可以给数据库做”瘦身”, 在PostgreSQL数据库中,有几种技术可以帮助减少数据库存储空间的使用
上个月那次“盆泼大瓢”式的暴雨差点导致一客户的服务器上船,但还是导致电源故障,在UPS支撑了一会儿中断,再次启动RAC中的一个节点,查看/u01 oracle 软件所在的文件系统无法使用, 重启后操作系统无法启动,后修复文件系统再次出现ASM无法启动问题,简单记录一下这个故障。
一套oracle 19c 多租户环境,安装19.19RU时datapatch失败,日志提示其中某个PDB执行SQL时,ORA-25153: Temporary Tablespace is Empty (DBD ERROR: OCILobCreateTemporary) ,简单记录处理方法.
前段时间一套Oracle Exadata的环境, 2个ib做的private network和cell存储网络,但总有一条存储链路从db server到cell server ping不通,但是ibstat ibping rds-ping都正常, 因为一个IB链路出问题同样影响IO,无法做到高可用。后分析发现是出于安全检查只是从内存级修改了rp_filter值为1启用了严格的反向路径校验,禁用rp filter后恢复正常。