ANBOB™

前几天朋友问无论使用asmcmd rm还是rman 在删除一个归档日志时，提示ora-15028 文件正在被访问，分析是O002进程占用，该进程是oracle instance修改asm instance metadata的进程， 经测试是非致命进程，可以尝试kill, 不必重启instance. 下面是诊断方法。

oracle 11g后引入adrci 仓库管理trace文件，12c后更把把GI和DB全转到了adrci， 我还是比较喜欢用它小工具，今天一套友商安装的数据库使用adrci 查看日志提示No ADR base is set, 检查了$ORACLE_BASE环境变量也存在，同时也未使用symbolic links 目录，临时解决当然可以使用adrci中SET BASEADR_BASE DIR手动指定ADR BASE, 对于使用频繁的工具，手动set，不能忍。

对于UDTs自定义数据库类型是oracle扩展的数据类型，对一个对象存储更多的信息，在oracle8版本就存在， 可以在创建表对象用于列类型，前段在一套库迁移时遇到个问题，应用软件使用了ArcGIS 空间数据库组件， 对应数据库中的SDE schema用户，应用部署希望drop sde用户使用软件安装重新生成，但是这会导致其它用户的table使用了该用户的类型导致数据丢失。

Oracle 12c RAC 1个实例因硬件原因突然crash, 另一实例上的goldengate Extract 进程Lag At Chkpt 持续增加，read checkpoint并不动，开始是因为归档日志被rman备份任务备份后删除，但restore 归档日志从Recovery Checkpoint到当前确认都存在后依旧hang, 清除了BR 文件再次启动extract进程恢复正常

前几日在做oracle 迁移升级使用FTTS 从11.2.0.4 升级到19c pdb时，因为对象包含数据类型TimeStamp with Local Time Zone(TSLTZ )， 导入matadata过程中报错ORA-39360而终止，报错如下:
Full Transportable tablespace import fails with:
ORA-39360: Table “xxx” was skipped due to transportable import and TSLTZ issues resulting from time zone mismatch.

这是一套Oracle 19.4 的RAC 环境，硬件是IBM 大机LinuxONE(Zlinux), 节点出几次重启目前已确认是由于oracle代码级bug，cssd错误的Reference count 记录为0，导致再次ASSERT资源时异常终止。

Oracle 希望在数据库主机CPU使用率枯竭时，尽可能让核心的几个后台进程可以最大优先级获取CPU, 当然CPU过高会导致I/O 响应时间变长和网络延迟增加，也会间接影响数据的整体性能, 使用ps -c在查看LMS时发现没有在RT模式引起了注意，在19c中 LMS还是有一些变化，下面简单的记录

The received warning means the kdump operation might fail and the crashdump parameter should be configured correctly. This is the procedure of kdumping:

The normal kernel is booted with crashkernel=… as a kernel option, reserving some memory for the kdump kernel. The memory reserved by the crashkernel parameter is not available to the normal kernel during regular operation. It is reserved for later use by the kdump kernel.
The system panics.