提供综合数据库运维服务与优化方案(不限Oracle MySQL PG GaussDB GoldenDB OceanBase等), 微信/Tel:(+86)134-365-60330
最近一套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并没有自动修复该错误。这里简单记录。
主从同步和Raft/Paxos是两种不同的技术，用于不同的目的。主从同步主要用于数据库的复制和读取性能优化，而Raft/Paxos主要用于确保分布式系统的一致性。虽然它们都涉及到数据的复制和分布式系统，但它们的设计目标、实现方式和一致性保证都有所不同。
在数据库中，有时需要一种快速简便的方法来生成随机字符串来填充文本列，因为目前PostgreSQL中没有生成随机字符串的函数，可以考虑使用 Orafce 扩展，其中包括一个生成随机字符串的PostgreSQL 函数。或者创建自定义函数实现，如果使用orafce中的dbms_random生成函数记的检查可能与oracle一些形为不同。
在Postgresql中可以使用format()打印SQL, 使用$[tag]$ 匹配引号，还可以使用format type格式化文本对齐与标识自动加引号，创建易于维护的脚本，没有硬编码文本，并且不会忽略标识符的双引号。
长期以来，oracle数据库一直是集中式数据库的领导者，基于共享存储的RAC和日志流的DATAGUARD数据保护，提供了数据的最大高可用，支撑的全球各行业的核心业务。然而从Google的Spanner发起的分布式SQL开始，出像了像CockroachDB、TiDB 和 YugabyteDB 通过 Raft 共识复制和OceanBASE通过Paxos共识复制的分布式数据库,Oracle 现在似乎在这个赛道成了追随者。在Oralce 23C中添加了Raft复制，做为主备配置的替代方案，但是并不是重新构建一套新的数据库架构，而是基于现有的Partition、Oracle Sharding、GDS技术之上做了创新.
去年在记录<案例：openGauss/postgreSQL 数据库手动清理膨胀Heap Bloat (dead tup)>时遇到过在opengauss系统drop table后，操作系统并未立即释放问题，当时没有过多研究，只是建议通过kill SESSIONS或重启可以达到效果，近日发现同事在postgresql中同样遇到了该问题，但Postgresql是进程模式可以和oracle一样通过kill OS 进程释放文件句柄，并且PostgreSQL在2021-02-11 Release的版本都改进这一问题，目前Opengauss V5依旧存在
Oracle数据库有dataguard主从，MySQL有主从或MGR，Goldengate同步支持从前两种数据库做数据抽取，但是在主从切换以后需要在Goldengate做相应的修改。这里记录一下MySQL因master 需要停机维护时，OGG主动切换到slave的方法。
前几个月有个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过程中遇到的问题时，可以考虑禁用该特性.
effective_cache_size 是一个参数，用于设置当 PostgreSQL 计划执行查询时，操作系统缓存和 Postgres 的共享缓冲区中将容纳多少数据的估计值。 此值用于确定数据库引擎对磁盘 I/O 的依赖程度，简而言之是planner对单个查询可用的磁盘缓存的有效大小的假设,这对数据库性能有重大影响。
当事务查询或使用了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], 记录一下该问题。
时间如白驹过隙，岁月从从又一年，回首过去的一年，我们都在努力的活着，平静中度过了我的35岁，按照惯例每年春节前需要简单总结一下，当回首往事时做为一点回忆。如同近期去北京出差，无意间在公交站台看到那个熟悉又陌生的路线，那是我18岁时经常追赶的记忆，不知当年一起坐车的我们是否还彼此惦记？
希望是龙年春节前的最后一个故障， 一客户Oracle 19c RAC环境中，做index rebuild online操作进行过程中，kill重建索引的会话，后面查询索引相关的表提示如下报错：ORA-00600: internal error code, arguments: [kkdlfjou_1], [], [], [], [], [], [], [], [], [], [], []
前几日一客户遇到了些安全事件，又把安全这个沉重的技术提高了要求， 安全投资再多也不过分但又可能看不到收益，还可能违背人性遭吐槽。 环境中有达梦数据库，领导想了解一下达梦安全做到什么程度，如审计像oracle中有AUDIT，还有AVDF,DV等专业组件，对数据库的访问控制保留记录，像对于“托库”oracle有监听日志和ASH \DASH配合如连接IP、 持续活动时间、持续IO量评估
上周有个客户咨询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的现象。