本文演示关于19c RU补丁常见报错问题的分析处理： 1.查看补丁应用失败的原因 2.问题解决后可继续应用补丁 3.发现DB的RU补丁未更新 4.opatchauto应用DB补丁报错解决 1.查看补丁应用失败的原因 补丁应用失败有详细日志记录原因; 故意使用oracle用户解压补丁，然后测试是否可以
转眼间已经2023年，再有一周就要过年了，在这里先给大家拜个早年，祝大家新的一年万事顺利。 Oracle如今版本号也和年份挂钩，在前段时间的OCW上也宣布发布了beta版本的23c，因为23c是继19c之后的另一个长期支持版本，所以今天就下载安装测试尝尝鲜。 自己的测试环境目前剩余资源有限，就先装个
有Exadata客户在进行exachk巡检之后反馈，发现系统中，exachk进程占用了大量CPU资源。 了解之前的变更，只是巡检之前升级了AHF，然后进行标准的exachk巡检。 现象： 目前机器整体CPU使用率是20%+，但被使用到的具体CPU core基本都是满负荷，都是这些exachk进程，这
问题现象： 在自己的工作站中安装的RAC测试环境，使用了iSCSI模拟共享存储，环境运行OK，但是在messages信息中频繁报错如下： [root@db01rac2 ~]# tail -20f /var/log/messages Jan 13 23:08:37 db01rac2 iscsid: i
测试环境： 客户端：Oracle 11.2.0.1 服务端：Oracle 19.16 测试过程： 1.低版本客户端连接高版本数据库报错ORA-28040 2.低版本客户端连接高版本数据库报错ORA-01017 3.总结经验 1.低版本客户端连接高版本数据库报错ORA-28040 使用oracle 1
春节假期整理历史物件时发现一些书籍的光盘，虽然买了多年但一直没有看过，因为自己在用的电脑都没有光驱。正好老爸的电脑是带光驱的，想着趁过节把这些光盘的内容读取出来存在NAS上方便后续使用。 使用UltraISO软件直接“制作光盘映像文件”就可以将光盘的内容制作成iso文件，便于保存在磁盘等介质上。基本
运行书中自带光盘中的程序，在该程序的readme说明中，提到这类错误，解决方式是： 因为是免安装程序，需要运行“setup”文件夹下的setup.exe文件，安装控件。在安装完成后，运行开发资源库程序，控件注册错误问题解决。 但是我这里运行完成后，发现依然有报错“flash8.ocx或其附件之一不能
环境： Oracle 19.16 ADG (Single Instance -> RAC) 在配置ADG的场景，发现ADG不能同步。 1.查看报错信息 2.oerr查看该错误说明 3.尝试sqlplus连接到standby 4.尝试relocate监听 5.继续排查发现是参数问题 6.总结和延伸 1
**环境：**Single Instance -> RAC Single Instance: db_name=demo db_unique_name=demo instance_name=demo service_names=demo RAC（2 nodes）: db_name=demo db_un
问题现象： 在一套2节点的19c RAC 环境下，节点2 alert告警 ORA 7445，且频度固定为每分钟报一次；期间有重启实例，但故障依旧： 2023-02-07T12:51:04.359849+08:00 PL/SQL package SYS.DBMS_RCVMAN version 19.1
作为IT运维人员，尤其是数据库岗位，数据的备份重于一切。 现在很多用户会有一个普遍误区，认为现在类似ADG这类灾备已经很完善，且实时性也更佳，往往就忽略了传统的备份效用。 但实际上，我们千万不能因为有了容灾建设就盲目忽略备份的作用，二者其实有着本质区别。很多场景，灾备都是无法替代传统备份的，二者是缺
背景： 环境未配置DG Broker，手工切换ADG，19c也要比11g时代的切换更简单。 使用自己的测试环境，具体可参见： 单实例Primary快速搭建Standby RAC参考手册(19.16 ADG) 1.主库demo切换到RAC环境demorac： 在主库demo执行命令： SQL> alt
技术人当遇到具体问题，能给出的各种解决方案，有一种类型叫做workaround，翻译过来通常为“应变方法”、“变通方法”； 其实这种方式通常是没有找到根本的解决方案，但是为了快速恢复业务而采用的一种巧妙规避/跳过的方式。 举个具体的例子：我有测试需求要在主库创建一个新的PDB： 1.创建新的PDB
最近，自己的一个测试环境，遭遇了hacker攻击。 具体是oracle用户被攻破了，原因是该环境通过DDNS连接到了外网，而因为只是测试，没有注意安全防范，设置的口令过于简单。 下面记录下，也作为警醒。 1.发现资源使用异常 CPU告警，使用top去查询资源使用情况发现CPU使用率非常高，达到94%
本文主要介绍Oracle In-Memory 选件，Oracle在12.1.0.2就已经推出了In-Memory这个选件，现在通常会建议所有使用19.8及之后版本的用户，有条件都要留给In-memory一点内存区域。 因为该选件在19.8之后推出了16GB及以下免费使用的福利，作为优化的又一利器。
在上一篇 优化利器In-Memory开启和效果 中，提到的两个SQL对比，使用的是传统的dbms_xplan.display_cursor方式来查看执行计划，好处是文本输出的通用性强，基本信息也都有。 但如果大家参加过我们的RWP培训，就会发现O原厂强烈推荐大家使用的一个工具是 SQL Monito
环境： Oracle 19.16 多租户架构 1.问题现象： SQL> create table T1 as select * from v$active_session_history * ERROR at line 1: ORA-65114: space usage in container i
环境： Oracle 19.16 多租户架构 经常会在网上看到有人写exists和in的效率区别，其实在新版本的数据库中，是不存在这个问题的，优化器会自己判断选择最优的执行计划。 为了直观的说明，我在PDB中构造如下测试用例： vi 1.sql select count(*) from v$acti
DBSAT是Oracle官方提供的脚本，用于数据库的安全评估检查，用户可以放心下载使用。 下载链接具体参见MOS： Oracle Database Security Assessment Tool (DBSAT) (Doc ID 2138254.1) 下面介绍DBSAT脚本快速收集方法： 1.上传d
环境： Oracle 19c ADG（主库：单实例；备库：RAC） 1.主库新建测试文件 2.主库创建测试表 3.查询表对应数据文件信息 4.模拟数据文件物理坏块 5.查询对应测试表 6.进一步查询日志信息 7.确认当前参数设置 1.主库新建测试文件 主库在AWR的PDB中做测试，为了不影响其他测试
