MySQL 5.7 memory_global_total view 内存使用不真实
有时做数据库监控像内存使用率,希望可以从数据库中使用SQL更加方便,在MySQL及同系的国产数据库(如GoldenDB)中同样有视图memory_global_total和sys.memory_global_by_current_bytes, 但是在早期的MySQL 5.7存在bug 可能会导致查询视图与ps、top操作系统级看到的相差很多。
提供综合数据库运维服务与优化方案(不限Oracle MySQL PG GaussDB GoldenDB OceanBase等), 微信/Tel:(+86)134-365-60330
有时做数据库监控像内存使用率,希望可以从数据库中使用SQL更加方便,在MySQL及同系的国产数据库(如GoldenDB)中同样有视图memory_global_total和sys.memory_global_by_current_bytes, 但是在早期的MySQL 5.7存在bug 可能会导致查询视图与ps、top操作系统级看到的相差很多。
前几天在一个YashahDB的测试场景中看到,yashanDB的一个分页查询SQL的相应时间比oracle要快很多,对比执行计划发现是列上没有Not null约束时,YashanDB可以走INDEX FULL SCAN,虽然YashanDB是heapTable, 那看来Null值也在index 中存储(pg同样),这点和oracle不同,下面实际查看一下Yashandb 的block是否有null记录?
近日一客户使用Oceanbase V4.2的环境中,OCP监控平台提示一个严重级别的信息”Variable assignment in order by items will cause uncertain behavior“ 带变量的order by 导致不确定性,文件源码src\sql\resolver\dml\ob_select_resolver.cpp, 下面记录一下该错误的原因
崖山数据库支持了YAC如oracle的集群RAC功能,RAC除了高可用外,大家可能比较关注像性能的提升效率比怎么样?因为大家还是希望增加节点为带了性能横向的扩展,那对于要求在cache fusion中的GES, GCS等资源与锁的管理就要求比较高,还有就是跨节点的并发争用,这里先简单测试row级争用的现象,与oracle还是有些不同。
众所周知,oracle 11g(11.2.0.4) RAC 在Linux 7上安装并不是很顺利,之前我整理过几个小坑,其中最常见的就是ohasd.bin 或ohasd.server 未启动,影响root.sh时,或操作系统重启后,或安装补丁时。一般手动创建个服务,或是安装个patch引入服务也可以,但这次这个case有点复杂,断电重启后CRS无法启动,简单记录。
Oracle RAC的共享存储架构始终是集中式数据库实现高可用的经典方案,承载了众多行业核心业务系统的稳定运行。昨日,这一架构阵营中又迎来一位新成员——崖山数据库正式发布了V23.5版本,推出了支持YAC共享集群架构。出于对这一技术的关注,我连夜申请了安装介质,并第一时间进行了部署与体验。
今天一个客户的Goldengate的extract进程组异常中断,分析ogg日志发现日志提示ora-00916错误,如下:
OGG-00916 Column FSE cannot be used as a key column. Define a unique index for table ANBOB.TAB_XXX without this column or use the KEYCOLS parameter to correct this issue.
在开展安全加固或等级保护相关工作的过程中,我个人倾向于保持一种务实的态度。这并非是对安全本身有任何异议,而是注意到部分安全厂商所提供的整改建议,有时过于注重形式化要求,可能在实际运维中引入“无效”成本,甚至影响系统稳定性。例如,在某些场景下,安全扫描工具本身就可能引发服务异常,这类情况在实际运维中并不少见。
近期在一个国产化数据库highgoDB的数据库环境,一主三从架构,主库的归档产生的较为频繁,且主库的参数关于wal的保留时间配置(wal_keep_size)也偏低, 后来因为备库有重建需求,在重建时发现主库的WAL日志缺失了,重建前也并未手动清理对应的物理槽。难道HighgoDB可以自动清理?
某医院客户一套.NET开发的应用,部署在Windows IIS 服务上,数据库是Oracle 12.1 RAC, 总是在早高峰时出现ORA-50012 Pooled connection request timed out的错误,困扰了客户好久,找到我们帮忙解决,下面简单记录。
最近有个客户的MySQL数据库(MariaDB 10.6.20)总是频繁的重启,查看mariadb-error.log中显示“InnoDB: Failing assertion: free + TRX_UNDO_LOG_XA_HDR_SIZE < srv_page_size - 100”, 简单记录该问题。
最近在一个从oracle到基于postgresql的国产数据库项目上,遇到使用copy加载到数据库中的表字段是空值数据无法过滤,因为在oracle中的\0x00、NULL、”(空值) 与postgresql中不同,所以在像瀚高、kingbase等PG系的数据库,oracle兼容模式下对于‘’空值的处理要格外注意,下面简单的记录。
近期在推进一个从 Oracle 迁移至 PostgreSQL 的项目时,我们遇到部分在 Oracle 中运行正常的索引无法在 PostgreSQL 中创建,系统报错:ERROR: index row size X exceeds maximum Y for index “index_name”。
经分析,这源于不同数据库对索引键(Index Key)长度的上限设计存在差异。为规避此类问题并助力迁移规划,我们特此整理了 Oracle, MySQL, PostgreSQL 三大主流数据库的索引键长度限制。
ob_query_timeout 是 OceanBase 数据库服务器的一个系统变量(System Variable)。它设置在数据库服务端,用于控制在该数据库连接上执行的所有 SQL 查询的最大执行时间。obdumper 是一个独立的客户端工具,它通过 OBDC 或 Java 驱动与数据库建立连接。理论来说也是一个客户端,应该是继承DB的变量设置,但是近期一客户obdumper一提示query timeou超时,且值并非DB级的参数,这是怎么回事?
今天在某个金融客户群看到客户咨询“在Oceanbase数据库中oracle租户,更新clob字段超过4000字符怎么弄?”,我们知道clob可以存储像Varchar类型的字符,如果不使用dbms_lob包处理,可以简单当varchar处理,而varchar的长度又有上限,在oracle和oceanbase中这个问题答案是不同的,下面我来演示。
最近一客户在使用obloader工具,做一个表的恢复时,遇到了下面的错误:
$obloader -h xx -P xx -u xxxx – p ‘xxxx’ -c XXX -t XX – D xx –csv –table xxxx -f xxxxx.csv –external-data
[ERROR] Invalid char between encapsulated token and delimiter. Token Content: ,\E,0,79,\E,\E,. Line[1,18]
有套业务库告警一套业务库的年龄age过高,这是防止事务回卷的监控项,超过是2亿(autovacuum_freeze_max_age)的80%,于时同事查询了一下age 最大的表发现top 1是业务用户下的TOAD_PLAN_TABLE,age 接近21亿,也就是最大允许的值。继续分析发现在Highgo数据库相比pg多的一种表类型。
最近遇到了一个很严重的问题,MySQL 的磁盘空间完全耗尽了,导致无法访问并崩溃。因此许多操作都报错。/var/lib/mysql 目录中一个名为 ibtmp1 的超大文件占用了硬盘空间。ibtmp1 是 MySQL 的一个临时工作文件。客户不得不不断重启服务器.
今天一客户的GoldenGate for bigdata, 从oracle同步到kafka时,应用端进程失败,报错如下:
2025-09-29 17:58:56 ERROR OGG-01163 Oracle GoldenGate Delivery, r_ka.prm: Bad column length (1287) specified for column XINFO in table ANBOB.T_PATH_INFO, maximum allowable length is 400
近日一客户的oceanbase OCP告警ocp_monagent agent服务不可用,日志显示OOM kill
oom-kill:constraint=CONSTRAINT_MEMCG,nodemask=(null),cpuset=ocp_monagent,mems_allowed=0-7,oom_memcg=/ocp_agent/ocp_monagent,task_memcg=/ocp_agent/ocp_monagent,task=ocp_monagent,pid=1948228,uid=0
Sep 28 14:00:01 anbob-2 kernel: [25155102.452094] Memory cgroup out of memory: Kill process 1948228 (ocp_monagent) score 1004 or sacrifice child