通过最大分区数据错误看Oracle 23ai 错误提示友好增强
之前在写《Oracle 23c 几个开发相关新特性》有简单记录在报错上的友好增强,最近oracle发布了23版本命名为从C(cloud)系转向ai系,通过官方下载了个vmbox磁盘镜像分分钟运行起了oracle 23c free ,今天刚好公司内部讨论一个interval partition分区个数上限的问题,我们看看23ai版本的提示有多明确。
提供综合数据库运维服务与优化方案(不限Oracle MySQL PG GaussDB GoldenDB OceanBase等), 微信/Tel:(+86)134-365-60330
数据库oracle
之前在写《Oracle 23c 几个开发相关新特性》有简单记录在报错上的友好增强,最近oracle发布了23版本命名为从C(cloud)系转向ai系,通过官方下载了个vmbox磁盘镜像分分钟运行起了oracle 23c free ,今天刚好公司内部讨论一个interval partition分区个数上限的问题,我们看看23ai版本的提示有多明确。
今天一套oracle 19c(19.16)dataguard 环境,一个维护数据库用户(非sys, system)在primary和standby side都是OPEN状态,但是在备库登录时依旧提示ora-28000 : the account is locked, 记录一下处理方法。
现象oracle 19c RACon linux 7.6, GI alert log一直在输出“2024-04-28 01:07:20.305 [GIPCD(53662)]CRS-42216: No interfaces are configured on the local node for interface definition virbr0(:.*)”,但不影响RAC的稳定和使用,在安装clufy时有时也提示PRVF-7617,在oracle 11g还有bug 记录可能影响私网通信 简单记录处理方法。
最近,有一位海南客户报告了Oracle 19c RAC数据库启动时出现的错误,提示ORA-07445: exception encountered: core dump [ipcor_net_get_ibdevname()+71][SIGSEGV]。这个崩溃报告的异常原因是由于Oracle的一个bug引起的,但根本原因是由于数据库无法访问某些特定设备的API而导致的。通常这样的问题源于硬件方面的原因。在这里,我只是简要记录一下问题的表现。
在Oracle数据库中,索引是提高查询性能的关键工具之一。通过使用索引,数据库可以快速地定位和检索数据,从而加快查询速度并降低系统资源消耗。在索引扫描过程中,有两种主要的方法:索引快速全扫描(Index Fast Full Scan)和索引全扫描(Index Full Scan)。然而,在某些情况下,数据库可能会出现错误的执行计划,选择索引全扫描而不是预期的索引快速全扫描,导致性能下降和资源浪费。该类问题可能不容易发现,仅是SQL性能差,或主要的等待事件为db file sequential read.
环境为Oracle 11.2.0.4 2节点RAC的情况下,今天我们遇到了一个问题。同事在使用DBCA删除一个已经损坏的数据库实例时,意外地导致了当前唯一存活的数据库实例崩溃。进一步的检查发现,ASM磁盘组不可用,而ASM警报日志显示了ASM磁盘文件头损坏、ASM元数据损坏以及ORA-15196: 无效的ASM块头的错误。为什么删除数据库实例会导致ASM磁盘组不可用,并且发现ASM元数据损坏呢?
几年前测试oracle RAC的节点间UDP通信《The FG(server process) and remote node LMSn process communication over the interconnect?(用户进程会和另一节点的LMS进程直接通信么?)》测试过节点间存在Server进程与LMS的udp连接,使用的是HAIP(169.254.*.*), 而Linux操作系统的网络端口可用范围net.ipv4.ip_local_port_range 参数控制,适用于TCP和UDP,最大值是65535. 如果RAC中就一个private network 网卡,假设不排除所有进程都和某一个LMS进程通信如LMS1,LMS1分配1个IP addr+UDP port, 那FG进程的上限就是net.ipv4.ip_local_port_range /单个FG进程打开的UDP个数。
最近一套oracle 12c R2的数据库日志应用总是中断,并且在standby 节点发现了一些坏块,存储检查正常,并且primary db端并没有发现坏块,standby db alert log中发现了大量的ora-600报错,当前可能为logical corruption(Internal inconsistency in the block while the block may have good header and footer. The block checksum will be correct but the block structures may be corrupt.),ADG的ABMR并没有自动修复该错误。这里简单记录。
长期以来,oracle数据库一直是集中式数据库的领导者,基于共享存储的RAC和日志流的DATAGUARD数据保护,提供了数据的最大高可用,支撑的全球各行业的核心业务。然而从Google的Spanner发起的分布式SQL开始,出像了像CockroachDB、TiDB 和 YugabyteDB 通过 Raft 共识复制和OceanBASE通过Paxos共识复制的分布式数据库,Oracle 现在似乎在这个赛道成了追随者。在Oralce 23C中添加了Raft复制,做为主备配置的替代方案,但是并不是重新构建一套新的数据库架构,而是基于现有的Partition、Oracle Sharding、GDS技术之上做了创新.
前几个月有个XD的客户遇到过linux bug导致OS频繁重启,当时整理了笔记
2c 引入了log segment功能,针对xml格式的alert log达到某大小后自动生成新文件,解决日志过大查看和监控采集的问题,我在很多年前专门写过listener log和alert log的text格式的shell用于切换,Log writer(LGWR)进程在switch时会写db alert log, 如果在写日志时有性能问题有可能会导致LGWR进程性能问题,导致实例出现等待log file sync。
事务隔离级别是数据库事务处理的基础,ACID 中的 “I”,即 Isolation,指的就是事务的隔离性。ANSI/ISO SQL 标准定义了4 种事务隔离级别,对于相同的事务,采用不同的隔离级别分别有不同的结果。这些隔离级别是根据3 个“现象”定义的,
最近遇到一个oracle 19c(19.15)的多租户环境,在查询cdb_data_files时显示的文件大小偶尔不正确的现象,这可能影响我们对于数据库空间类检测,通过分析发现在多租户环境中查询CDB_或共享对象时(sharing=object ),递归查询中使用了result cache.简单记录。
近日一银行客户巡检发现一内存使用率高的oracle 19c(19.4) RAC数据库环境,因为是linuxone拆分的多机器,内存分配不是很充足,在当前动辄1T内存可能并不易发现,分析内存使用主要是因为Oracle的多个后台进程ora_wNNN_xxx进程,每个进程PGA使用近600MB。WNNN后台进程是SMCO(Space Management Coordinator Process)的slave进程,从oracle 11g引入的智能空间预分配space preallocation的新特性,在oracle 12c后SMCO也负责生命周期管理ILM(Information Lifecycle Management).由于SMCO 或W00n在完成space preallocation过程中遇到的问题时,可以考虑禁用该特性.
当事务查询或使用了flashback query(如expdp中指定了flashback_scn)中指定的时间或SCN小于表及附属对象的LAST_DDL_TIME时,会遇到ORA-01466: unable to read data – table definition has changed的报错,因为一些alter table 或truncate table等DDL操作会使表相关的UNDO数据失效,导致查询之前的数据镜像报错,提示很明显,表的结构发生了变化,常见EXPDP导出过程中,报错如下:
一套oracle 11gR2数据库环境, SQL监控工具在采集SQL性能指标时,报错 ORA-00600: internal error code, arguments: [733], [1258291280], [top call heap], 记录一下该问题。
希望是龙年春节前的最后一个故障, 一客户Oracle 19c RAC环境中,做index rebuild online操作进行过程中,kill重建索引的会话,后面查询索引相关的表提示如下报错:ORA-00600: internal error code, arguments: [kkdlfjou_1], [], [], [], [], [], [], [], [], [], [], []
上周有个客户咨询Oracle数据库历史时间SQL性能变慢的问题, 还是个偏重要的核心业务,当然最终确认因为人员的一些变更操作非专业性,导致JOB未运行,产生的数据累积,思考一些问题,Oracle 9i没有AWR, 没有ASH, 甚至当时或当前国内也是没有太多的技术团队储备,是不是像极了现在的国产库现状?
之前曾经在《oracle add column xx default value 增强(二)》记录过,在日常运维中增加column是常见的操作,对于大表增加列时是否会导致回写表还是只修改数据字典影响DDL的执行时间和停机窗口长短。之前也在《“alter table ” modify column in Oracle、MySQL、PostGreSQL(数据库比较系列十三)》记录修改column时不同库的表现, 这里简单记录测试一下当前主流的几个库对于add column的现象。
在Oracle存储空间中,表空间的大小(dba_data_files size)几乎等于空闲空间的大小(dba_free_space size)加上段的大小(dba_segments size)。通常情况下,这两个值之间的差异是很小的,可能是由于一些header和bitmap block未计算在其中,但这些差异通常是很小的,以KB或MB为单位。然而,同事遇到了在一个bigfile表空间发现巨大的差异,达到了10TB以上。现在的问题是,这些空间去了哪里?