ANBOB™

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导出过程中，报错如下:

时间如白驹过隙，岁月从从又一年，回首过去的一年，我们都在努力的活着，平静中度过了我的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的现象。