ANBOB™

Oracle 20-22c是12c后的下一个大版本集，也有了大的改变，如本身就云架构数据库定位从20c起不再支持非多租户，了解新版本可以了解数据库的发展方向，减少不必要的麻烦，如短时间内再次升级功能不再支持应用程序又要重写， 对于安全方面同样也有一些变化，这里简单的记录。

Oracle 11G r2 active dataguard端突然产生较大GAP，日志停止应用，大量前台查询进程等待”library cache load lock”， hanganalye 显示’rdbms ipc message’<='library cache lock' 等待链， library cache lock是一个parse lock，要知道在ADG 环境中也只有一个进程会在X-mode 持有lock，同时在ADG环境中存在一个相关bug, 这里记录一下这个问题。

Network/TTC related error ORA-12592, ORA-3137, ORA-3106 may be signaled on SQL*Net TCP/IP transport.
Usually this problem is seen with following circumstances.
– Sending large size data to database server, for example, using sqlldr, expdp
– Database version is 11.2.0.4

一套12C R2版本的4节点RAC数据库，记录一起高并发业务繁忙时，DDL导致数据库出现大量前台会话长时间等待”enq: US – contention” & “enq: IV – contention” ，该SQL（INSRT VALUE）的只是一个Children cursor无法执行(sql_start_exec 时间已过去数小时)，第二个的children cursor执行效率正常，最终KILL 这些长时间运行前端会话解决。

尽管新兴的分布式应用程序受益于去中心化信任模型中，但当今大多数应用程序都具有中央权限（银行，代管公司，交易交易所，政府办公室等），并且借助Oracle数据库中的区块链表，可以使这些应用程序更安全，而无需增加更改为托管服务器的复杂性去中心化模型。这就是使用Oracle Database 20c本机区块链表的原因

前段时间遇到的一个案例，当编译一个invalid procedure时，自已会话堵塞自己等待’library cache lock’. 数据库版本Oracle 12.2， 当然这个procedure里面用到了dblink 嵌套procedure跨了3个数据库，在查看procedures定义时发现附加了”EDITIONABLE”

之前测试过《DUL 支持Oracle 19c》，目前ORACLE 20C官方文档已发布， 按惯例2020年第一季度会发布ON cloud平台版本和工程系统，第二季度会发布可下载非工程系统版本，我先尝尝鲜搞个测试版本使用DUL测试是否继续支持20c,包括blockchain table.

当拆分一个(partition)分区为两个分区时，其中一个分区为空，另一个非空分区保持了与原来分区相同的存储属性时，因为未产生数据移动，只通过内部切换data_object_id的内部调用，同时保证原来的Global 和 partition 索引一直处于USABLE(可用)状态，该特性叫做fast split partition. 这是9.2开始的老特性，IOT类型是从10.2 开始支持。

redo中记录所有数据库的变化，包括所有数据文件上的变化，但不包含控制文件和参数文件的变化。redo最初记录在online redo logfile中，如果是归档模式会在填充满后生成离线的归档日志文件,有时会发现归档量突然某一天突增了需要查询原因， 更有甚者把降低redo生产量做为优化的目标。这里记录一些分析归档生成和分析变化的思路。

2019年“太难了”，没有难恐怕还有更难，2020年刚开始，春节期间一场突如其来的新型冠状病毒，一时间笼罩了整个武汉（湖北），又因为春运人类大迁徙，近年中国经济快速发展，交通更加便利，就业选择率提升，短时间全国沦陷无一省份避免，还走出了国门。经济飞速发展，我们其它方面准备好了吗？

Oracle 12.2 GoldenGate(ogg) 进程突然全部PROCESS ABENDING,MGR中配置了autostart，自动启动后恢复正常，但错误日志中出现了OGG-01224 Address already in use。

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

如何修复有事务的表上发生了坏块， 此时undo 中的事务会一直active， 无法清理，简单记录如何手动清理

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

从12c 版本开始新引入DBA_DB_LINK_SOURCES(link_sources$)记录了远程dblink 曾登录本地数据的会话信息（hostname、IP, dbname、用户名、logon_time、logon_count），在使用DBLINK的环境中有时会看到，dblink session在等待“Enq: SQ – contention ”

10g onwards, Instance recovery is done in two phases. First phase scans the blocks to be recoverd and applied from rdo log files and the second phase actually does that. In a RAC instance the during the instance recovery, first pass scan can be delayed by 300ms-1.5s waiting on GRD (Global resource directory).

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

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

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

Starting from version 12.2, only if the multi-tenant option is used, this is changed, and the wait event ‘log file parallel write’ only is shown if the submitted IOs are not available after they are submitted, and thus the logwriter process has to wait for them.