ANBOB™

MySQL master slave replication doesn’t provide any solution in case of master failure, in that scenarios we have to manually do the configuration changes to make the next available server as master. Use keepalived to configure VIP, the application uses VIP to connect to the database, when the node is unavailable, the VIP automatically switches to other nodes.

Got fatal error 1236 from master when reading data from binary log: ‘Could not find first log file name in binary log index file’

Sometimes our MySQL master-slave environment has not been used for a long time,slave server is stopped for some reason for a few hours/days, and the master binlog has been automatically deleted. when you resume replication on the slave it fails with above error, and I don’t care about the loss of transactions between them in my test DB. Of course, the production environment may need to rebuild the slave database.

The MySQL root password is often used in practical applications. If you accidentally lose the root password, you can recover the MySQL root password through the methods in this article.

最近有个客户的表空间使用率使用50%左右就出现了ora-1653，我们知道ora-165N是空间无法扩展，这么多的free空间还无法扩展，其中有可能是存在碎片，也就是数据文件中不连续的”洞”free space， 在申请一个比较大的extents时，无法匹配连续空间而失败， 你是否想过查看数据文件上的段分布？或表空间的碎片情况？或move 哪个对象可以让datafile resize更小？

因为使用dblink需要分配undo段来标示分布式事务，如果在循环中使用dblink并commit，每次会分配新的undo段，同时undo retention如果保留时间较常，那可能会导致undo自动扩展很大(autoextent on )， 或者会出现undo段争用，从未过期的undo段偷窃， 就会影响正常的DML事务

一套MySQL V5.7主从同步(MTS)检查时延时较高，这是mysql的常见现象，如果重启备库时提示err 1236，又是mysql的常见错误, 分析slave上的进程发现 GRANT 在 FLUSH PRIVILEGES 之前获得锁时出现死锁，简单记录这个MySQL 5.7 bug。

就是因为HW的备份软件在备份前需要修改正常库的asm_diskstring 增加它的/dev/cdm*， 挂载它的存储设备到ASMDG， 因为他的软件bug导致期中一块盘处于中间态，磁盘名有，但iscsi未注册，挂载失败立即执行把它自己的ASMDG卸载，alter diskgroup xx dismount，但是这个动作又触发了ORACLE的ASM 自动disconnect 其它未使用diskgroup的预期行为

经典知识库：Oracle 19c避雷经验分享-2022云和恩墨大讲堂 时间： 2022年02月17日 20:0 […]

今天在测试一个小功能时发现个人用户密码已过期，当然这时只能去更改密码，改密码时递归更新密码最后更改时间来改变用户状态，此时profile延长过期天数PASSWORD_LIFE_TIME已无法解决， 但是大多数需求是希望是通过改密码的动作清除过期标记又不变原密码，当然这时又受到了user profile中PASSWORD_REUSE_TIME的限制， 你可能已想到了可以使用alter user identifed by VALUES ‘’; 但是这里也有个小细节。

生活看不透,年华算不清,岁月理不出,日子留不住， 2022已经到来，习惯性在春节来临前，小结一下今年收获。

自anbob.com从09年建站以来经历了12个年头，BLOG已经累计了1100余篇，截止2022春节前这一年里新发布近70篇的笔记， 脑子里的cache可以暂时的清空一下。

Trace File Analyzer(TFA) 是oracle用于分析和收集日志的程序，可以安装在独立或集群节点的数据库节点上。从Oracle12.2开始，这个工具包含在 RDBMS 软件中，当我们运行 root.sh 脚本时，这也是可选的，如果不需要，我们仍然可以跳过它,从19c开始Oracle将ORAchk，EXAchk，TFA等多个诊断工具合并入Autonomous Health Framework(AHF)，作为一个独立的安装软件，也被集成到了RAC安装介质中，AHF可以使用root或者非root用户安装，但是用root可以收集更全的日志

Server processes 扫描 LRU 列表以获取free buffers （例如，在从磁盘读取块时，或为 CR 克隆缓冲区等时）。在将其扫描到阈值级别后，如果Server processes找不到free buffers，它会请求 DBWR 将 LRU 列表中的脏缓冲区写入磁盘，或a pinned buffer is freed。当 DBWR 写入脏缓冲区/释放固定缓冲区时，会话等待 ‘free buffer waits’。

Oracle 数据库中的 varchar 和 varchar2 数据类型都用于存储字母数字值的动态长度。但它们之间存在一些差异。varchar 数据类型是适用于所有关系数据库产品（Oracle、MySQL、PostgreSQL 和等）的 ANSI 标准数据类型，存储长度不同数据库差异较大。而 varchar2 数据类型是 Oracle 标准数据类型。VARCHAR是Varchar2的同义词，当我们创建 varchar 数据类型时，Oracle 服务器会在内部自动将 varchar 数据类型转换为 varchar2 数据类型。而部分国产库是VARCHAR2是VARCHAR的同义词。

前段时间一客户的Oracle数据库使用datapump做了迁移，发现相同数据LOB段迁移前后占用空间有原来的45G增长到了103GB, 朋友在墨天轮社区记录了这个问题click here, 主要原因是因为使用了不同的Lob Chunk Size，导致的空间浪费。这里简单的记录一下这个问题。

A core dump is an image copy of a processes state at the instant it ‘aborted’. It is produced in the form of a file called ‘core’ usually located in the current directory.

某年某月某一天，有个客户的oracle归档日志空间突然满了，实例挂起，客户的告警系统一如既往的保持沉默， 我们自己部署的“保镖”脚本被友军打上了#号，友军的“打手”脚本说sys用户密码已过期， wait!wait! are you kidding me? SYS user 密码过期？ 逻辑是这样的这套脚本是在DATAGUARD的standby 使用sys@tns方式远程查询已applyed 日志删除，在调用日志里提示“ORA-28002: the password will expire within 7 days“。

OSW工具不用多说oracle数据库环境建议采集OS系统数据的脚本集， 采集的数据可以拿到其它机器，如WINDOWS上分析输出图形， 在ORACLE 12c后 AHF自动健康框架中已自带， 同时还有oracheck等，当troubleshooting时使用tfactl 可以一并收集相对全面的日志数据,几年前记录过2篇OSW，不做过多介绍，这里简单记录一下在Windows上使用oswbba.jar分析时的一些小问题。

Troubleshooting 19c ORA-1: unique constraint (sys.i_indpart_bopart$) during ALTER TABLE SPLIT PARTITION
上一篇blog中提到LOCAL 分区，分区索引part#和分区表part#是相等的，上一篇在还原那个问题时，让part#占用时发现还不是那么简单，如果用10046跟split partition,时而insert,时而存在update, 其实oracle在这方面也是做了优化， 在split分区位置和个数也有性能上的细微的差别。

开始了19c的躺雷模式， 再次建议选择ORACLE 19C版本时安装19.11 以上RU。 最近一客户升级了19C, 本月拆分区时遇到了ora-1 内部字典表数据唯一性冲突， 下面简单记录，报错信息如下:

ALTER TABLE ANBOB.TLOG SPLIT PARTITION PART_110_MAX AT (110, TO_DATE(‘ 2022-02-01 00:00:00’, ‘SYYYY-MM-DD HH24:MI:SS’)) INTO (PARTITION PART_110_202201 ,PARTITION PART_310_MAX )
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-00001: unique constraint (SYS.I_INDPART_BOPART$) violated

Oracle 19c(19.9) RAC on linux, 应用执行一个update sql时报错ora-600, 错误日志如下
ORA-00600: internal error code, arguments: [kkshhcdel:wrong-bucket], [0x58445A790], [0x000000000], [0x67DFB5820], [], [], [], [], [], [], [], []