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.