MySQL PXC集群修改表名大小写不敏感

新搭建的一套PXC集群,采用了Percona的最新版本,如下所示:

需要修改系统配置为大小写不敏感,因此需要修改配置参数lower_case_table_names=1。
修改以后需要重启集群,这里涉及到一系列问题的发生,具体如下所述。
只在节点1修改后立即启动失败,需要3个节点都改完,都关闭,再次启动才可以。
如下可见,最后关闭的[……]

阅读全文>>

MySQL启动报错

某项目急需一个MySQL库,于是在CentOS 7.5下配置了系统自带的mariadb server,正常启动是没有问题的。
但是我想把相关的数据文件放置到专门的文件系统,这样就修改了配置,也确认目录是可写的,但是一直无法正常启动!
具体的报错如下:

意思就是无法在那个目录下写!
查遍了所有的日志文件,再没有有用的信息了。
只好网搜[……]

阅读全文>>

清理FLASHBACK LOG

19.9 ADG环境,查看Flash Recovery Area Usage发现FLASHBACK LOG占用了90%多的FRA空间,而ARCHIVED LOG仅占用不到10%,这还了得,这是一个繁忙的生产环境,一般是不需要长时间的Flash Back的,得想办法清理一下,以免影响归档。【注:其实是不会影响归档的,具体的实践观察见后】
如下是清理前的占用情况:

[crayon-6045f4d691[……]

阅读全文>>

linux大内存页设置for 19c(continue)

在CentOS7.6下配置oracle 19.9时,如果没有显式设置HugePages为SGA所需的合适的值大小,而是设置了较大的值,尽管有时可以分配一些HugePages,但是一般不会是所设置的数目,结论是,必须显式设置合适的值。
如下关于wydb两个实例的alertlog输出,最后一次输出是正确设置并重启之后的:

以下关于zzj[……]

阅读全文>>

ORA-30013: undo tablespace ‘UNDOTBS2’ is currently in use

一体机的19c新数据库,由于项目人员修改undo,导致出现有的pdb无法open的情况:

oerr查看报错信息:

可见问题比较清楚,undo被别的实例占用了,这样的话,原因基本确认是修改undo配置时出了问题。
因此需确认目前的配置,改正即可。
当前数据库建库时采用了[……]

阅读全文>>

一次意外的ADG主备切换过程分析

■2021-01-14 15:07
存储开始出现问题,主数据库2个节点(node1、node2)均报共享存储’I/O error’

■2021-01-14 15:37
备库监控开始报错,主库长时间失联,导致主备切换

■分析结论
当时厂家人员做心跳故障模拟测试,可能有相[……]

阅读全文>>

RAC心跳断开导致脑裂

关闭网络心跳ip后,此时磁盘心跳正常,数据库主集群的2个节点发生脑裂,导致数据库重新配置。
重新配置的基本原则:节点数多的子集群存活,如果子集群包含的节点数相同,那么包含最小编号节点的子集群存活。
所以2节点集群,如果停掉所有的心跳ip后,node1存活,继续对外提供服务。
实际日志顺序如下:
1、node2的数据库实例被强行终止
2、node1确认检测到node2实例终止后,自我调整后继续提供数[……]

阅读全文>>

1962破记录了

1962分,总算打破自己尘封已久的1862分记录了,看来是水平有所长进,不容易啊,时隔太久了,截图记录一下。

19c用opatchauto打19.9补丁后无法操作ASM(二)

前期19c上出现的这个问题,后期在操作ASM磁盘时,再次复发:
ORA-15137: The ASM cluster is in rolling patch state

此时确认两个节点的patch level完全一致,如下:

解决办法,只需在任一节点执行:
crsctl stop rollingpatch
如下操作:

[crayo[……]

阅读全文>>

oraInventory异常

在查看补丁情况及冲突检查时,相关操作结果异常,如下

可见节点2的oraInventory异常,会导致无法继续操作打补丁。
根据相关的错误提示,检查oraInventory配置文件,如下

对比节点1的配置内容:

[crayon-6045f4d69a01932162249[……]

阅读全文>>