library cache lock或row cache lock, Failed Logon Delay 因为错误的密码尝试

数据库为了防止频繁的错误密码登录或暴力破解,如果user profile中配置了无限次失败而不lock用户,或当修改了应用用户的数据库密码,有遗漏的应用程序配置未及时更新,就会因密码错误而导致性能问题,Oracle 11g引入了密码延迟验证的新特性, 想法虽好但也成了问题特性。 错误的密码尝试在不同的版本中,对数据库带来的性能问题等待事件可能不同, Oracle 10g R2, 11g R1 等待事件的是row cache lock, 11g R2等待事件library cache lock, 12C是的等待事件Failed Logon Delay。

Oracle 19c RAC 频繁重启 OS log show “avahi-daemon : Withdrawing address record”

总会有一些创新型的客户走在技术的最前端,但有些问题无参考这是最担忧的问题,最近就一个非常新的环境ORACLE 19C 2-nodes RAC on IBM LinuxONE大机,同一大机部分节点上oracle实例频繁重启,重启前OS日志中有输出“avahi-daemon[4537]: Withdrawing address record for 28.83.70.4 on bond0.3112”…

使用pg_top动态monitoring PostgreSQL实例

操作系统有top (AIX topas)可以监视系统的进程信息, oracle也有著名的oratop 工具显示顶级会话信息,目前在oracle 12c以后的版本oratop已经集成到了安装介质中, PostgreSQL 也有一个类似的工具pg_top, 用于监视数据库中的实时活动,以及查看数据库主机本身的基本信息,也可以交互显示及定期自动刷新。

细说“Error: cannot fetch last explain plan from PLAN_TABLE”

前几日有位小兄弟问为什么有时使用explain plan for ….., 然后用dbms_xplan.display查看执行计划, 有时会提示“Error: cannot fetch last explain plan from PLAN_TABLE” 错误? 其实这个问题在Oracle 12c 以后应该基本不存在,因为这是explain plan一种悄悄的行为变化

DUL 支持Oracle 19c , 如何手动处理延迟段创建的表

oracle dul是oracle的恢复利器, 它的传奇功能不再解释,但是dul和其它工具一样也是需要段块信息恢复数据,但是从oracle 11g开始支持了延迟段创建,那么使用dul unload table, unload user默认是不会导出未生成段的表对象, 这样恢复的数据理论也会因为表不存在而丢失部分空表。但是表结构是在数据字典中可以手动生成建表语句。