OGG(12.3) Extract long time lag after Oracle RAC a instance Crash

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

,

Transportable Tablespace Failed with ORA-39360(TSLTZ datatype), How to continue ?

前几日在做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.

,

19c(19.4) RAC crash CSSD with ASSERT clsssc.c error On LinuxONE

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

LMSn not running in RT (real time) mode Oracle 19c RAC?

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

,

Linux Kdump for system panics

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.