Oracle、MySQL、PostgreSQL等数据库比较系列(十四): drop table being selected
对于一个连续7*24小时的业务,如果session 1正在select查询一张大表,而另一个session尝试drop 相同的表,会发生什么?对于最流行的MVCC数据库oracle,mysql,postgreql需要对比,因为drop不只是字典表更新标记,还需要回收物理空间。在这几个数据库中的表现一样吗?Oceanbase和goldenDB及GreatDB的表现.
Troubleshooting Oracle open database 报错ORA-01122 ORA-01110 ORA-01200
近期一个客户在vm环境外挂虚拟共享盘部署的oracle,类似AIX双机主备, 近期1主机异常hang死,另一主机启动数据库报错如下
ORA-01122: database file 2 failed verification check
ORA-01110: data file 2: ‘/oradata/anbob/sysaux01.dbf’
ORA-01200: actual file size of 1990400 is smaller than correct size of 2064640 blocks
密码保护:Troubleshooting ASM diskgroup mount fail with ORA-15040&ORA-15041 ASM Disk Header corrupted
无法提供摘要。这是一篇受保护的文章。
Troubleshooting Oracle instance start fail join cluster wait control file enqueue
最近1 Oracle Exadata X7客户ora instance 2被驱逐后,重启db instance 2启动挂起,影响另一实例instance 1, 随后终止启动,实例1运行正常。分析db instance 2启动时在等待control file enqueue超时,OS 日志显示“RDS/IB: conn <192.168.*.3,192.168.*.6,4> racing for more than 1s, retry”
Troubloshooting Oracle RAC node reboot and OS log show “kernel: qla2xxx[ ] Abort command issued”
近期1客户Oracle RAC 节点OS重启,协助分析原因,db层无日志错误输出,RAC层有vote disk I/O timeout, OS层 qla2xxx [0000:81:00.0]-801c:7: Abort command 和DEVICE RESET 操作。qla2xxx 是QLogic FC HBA的驱动,怀疑重启是HBA卡导致IO失败,导致disk timeout, CRS发起reboot. 简单记录该问题。
Troubleshooting Oracle 12c/19c expdp slow due to query for V$OPEN_CURSOR
最近一客户的Oracle 19c环境在使用expdp导出分区变慢任务积压很严重,对于这个客户每月几万分区的EXPDP备份无法忍受,几M小空分区都要6分钟以上,导出速度和导出需求一样不科学☺。对datapump进程可以做sql trace跟踪,同时从导出时间段的AWR的TOP SQL看,这库似乎也没啥正常业务负载, TOP 1 SQL是DATA pump worker在查询v$open_cursor
Oracle ASM rebanlance fail with ORA-59048 when drop failgroup disk
Oracle数据库在12.1.0.2 以上版本asm中,如果normal冗余的磁盘组Failgroup少于3个或者High冗余的Failgroup少于5个是不允许删除Failgroup的 。或配置Normal或Flex冗余 ASM 磁盘组,具有 3 个常规故障组和至少 1 个仲裁故障组, 当Drop 1 个常规故障组时, rebalance 结束时,在 v$asm_operation 中可以看到 ORA-59048。
More abort Oracle 12c RMAN ACTIVE DUPLICATE
最近一个200TB的oracle需要创建standby dataguard, 大量的bigfile 表空间,这么大的数据库适合不落的duplicate方式,在搭建过程出现了bug,修复单个报错的文件遇到了问题,思路如何提速时发现了这个特性,意识到好久没有看oracle新特性了。USING BACKUPSET这个特性很棒。
PostgreSQL/openGauss explain解析(二): indexonlyscan cost
PostgreSQL系(openGASUSS)数据库中的所有索引都是二级索引, 数据表段( heap)和索引段(index)分别存储,通常对于多列表的SQL只返回或where中仅少量的列时,希望可以只从索引中检索,而不用再从索引回表返回数据(本篇不考虑可见性)提高查询效率,像在oracle中有index full scan和index fast full scan的执行计划,在Postgresql中也支持Btree index的indexonlyscan, MySQL中同样支持,但发现PostGreSQL默认配置的SQL优化器通常判断索引的cost大于表扫描,导致仅查询索引列也未使用索引
使用dblink产生的”SELECT /*+ FULL(P) +*/ * FROM XXXXX P ” 解析
在MES平台看到一个提问,应用程序总时会自动产生类似”SELECT /*+ FULL(P) +*/ * FROM XXXXX P “这类SQL,确认不是应用代码中调用,看到FULL hint对于SQL调优人员可能会捶开发人员的冲动 ,同样对于SQL审核或SPA、 数据库国产迁移性能分析等需求抓到这类SQL可能就白白浪费感情。这SQL是数据库自动产生的吗?是!它是DBLINK调用的。
Troubleshooting oracle CRS start cssd fail with log show “unable to escalate to real time“
Oracle 11.2.0.4 RAC 安装完重启CRS启动失败,提示ocssd无法启动,ocssd日志中查看提示如下错误, 提示在提升CSSD进程为real time模式失败。
clssscSetPrivEnv: unable to set priority to 4
SLOS: cat=-2, opn=scls_set_priority_realtime, dep=1, loc=setsched
unable to escalate to real time
10个PostgreSQL中常见SQL错误
SQL语言当今在数据查询分析这块地位至今无法撼动,曾经的NoSQL也开始疲软,口号从”no SQL”也变成了“not only SQL”或“no , SQL!”, 但SQL的开发能力参差不齐,有些是从ORACLE数据库转到postgreSQL的,相同SQL的结果不并相同,在性能上也并不是所有人都可以编写高效正确查询,这里简单列几个在PG中几个SQL注意事项。
Troubleshooting ORA-04036: PGA memory used by the instance exceeds PGA_AGGREGATE_LIMIT
最近有家银行客户一套核心凌晨跑批时报出了ORA-04036,与12c后增加的PGA_AGGREGATE_LIMIT有关,环境oracle RAC 12.1.0.2 on AIX, 临时增加了PGA_AGGREGATE_LIMIT参数大小解决,事后找我分析原因
ORA-04036: PGA memory used by the instance exceeds PGA_AGGREGATE_LIMIT
Troubleshooting Oracle 11g ORA-07445 [kkqteSetSubPartNums()+355] and ORA-00600 [kghrst:ds]
一家内衣品牌的客户,环境oracle 11.2.0.4 rac on linux, db alert log日志中出现应用查询提示oracle ORA-07445: exception encountered: core dump [kkqteSetSubPartNums()+355] [SIGSEGV] [ADDR:0x7FEFCA3BDFB8] [PC:0x7818D8F] [Invalid permissions for mapped object] [] 和ORA-00600: 内部错误代码, 参数: [kghrst:ds], [0x7FFC26461030], 简单记录该问题
Troubleshooting oracle 19c RAC ‘gc cr block lost’ and ‘Library Cache Load Lock’
最近遇到这个案例大量FG prorcess堵塞,19c (19.4) 2nodes RAC, 等待Library Cache Load Lock, 堵塞会话为REC0, 该进程等待gc cr block lost. 同时在rec0进程trace文件中提示
IPCLW:[0.0]{-}[WAIT]:PROTO: [1661188358080974]ipclw_data_chunk_process:1165 Discarding msg with seq # 875492546, expecting 2730385062
IPCLW:[0.0]{-}[WAIT]:PROTO: [1661188358080974]ipclw_data_chunk_process:1165 Discarding msg with seq # 875492587, expecting 2730385062
Troubleshooting Oracle 19c hang wait ‘enq: TX – contention’ when RECO distributed Transaction recovery
Oracle 19c RAC实例大量会话hang,等待事件为’enq: TX – contention’, 做hanganalyze 堵塞进程为RECO, ‘buffer busy waits’<='enq: TX - contention' (cycle) RECO与前台进程形成死锁, 分布式事务表dba_2pc_pendings无记录。简单记录处理过程.
Troubleshooting Performance SQL执行计划改变因为Height Balanced Histogram 的Popular Value
最近有个银行客户咨询,他们一个系统有个SQL在凌晨1点左右执行计划突然变差了,数据库为oracle 11.2.0.4 RAC, 从AWR看数据库该时段实例级几乎空闲,上线很久的业务,问题时间点无人为操作,SQL特征是查询一个分区表,2个列上查询条件,并不包含分区键列, 其中有一个列使用了绑定变量,执行计划有原来使用绑定变量列的索引改为全表分区扫描,直到白天10点以后人为收集了统计信息恢复正常。
oracle to openGauss: 迁移后中间件socket closed,这锅DB不背
有一个项目从oracle迁移到了opengauss(MogDB发行版)后,有部分应用在运行一段时间后会超时, 日志中一些Socket closed错误, 执行的是从数据库中unload一些查询数据离线存储,常见的问题有网络防火墙, 或有一些timeout配置,或网络闪断等,逐一排除,当然在出问题时,应用厂家可能出于责任原因并不会坦诚,变更的是DB,会把怀疑方向指向DB, 但最终确认是中间件配置问题, 这里简单记录一下.
How to migrate data from Oracle or another Schema or another openGauss to openGauss(PostgreSQL)?
在openGauss数据库后期维护中难免有数据迁移或复制, 比如从oracle异构数据迁移,或在同一个server中复制一个schema到另一schema, 或是从另一个server复制到本server, 有一些命令行工具可以高效率的处理这些需求,并且可以迁移数据不生成落地文件,提升迁移速度,这里简单记录三种需求。
Troubleshooting Start HAS fail “Operating System function: opendir failed with error data: 2 error location: scrsearch1”
一套Oracle 11G standalone环境数据库文件在ASM中,几年没有重启的老系统,操作系统重启后,启动HAS服务失败, 提示如下错误:
as root
# /u01/app/11.2.0.3/grid/bin/crsctl start has
CLSU-00100: Operating System function: opendir failed with error data: 2
CLSU-00101: Operating System error message: No such file or directory
CLSU-00103: error location: scrsearch1
CLSU-00104: additional error information: cant open scr home dir scls_scr_getval
CRS-4000: Command Start failed, or completed with errors.