evil0305的博客

latch: shared pool,Library cache lock,oracle

前提：主库安装数据库，备库只安装oracle软件即可。1、DG基础环境oracle 主库ip：192.168.220.11 ORACLE_SID:orcldb_name=‘orcl’ 主机名：oracle19cSERVICE_NAME = orcloracle 备库ip：192.168.220.12 ORACLE_SID：orcldg db_name=‘orcl’ 主机名：oracle19cdgSERVICE_NAME = orcldg2、主库和备库监听配置以及TNS配置(主备库tns一样)

OracleDatabase 11g及以后版本中不再提供BBED库文件，但是可以用10g的文件编译出来，需要先从10g中复制如下文件到相应目录，然后再执行上述连接命令，参考如下步骤：（1）复制Oracle 10g文件cp $ORA10g_HOME/rdbms/lib/ssbbded.o to$ORA11g_HOME/rdbms/libcp $ORA10g_HOME/rdbms/lib/sbbdpt.o to $ORA11g_HOME/rdbms/libcp $ORA10g_HOME/rdbms/m

本文适用范围：一、通过BBED方式进行坏块修复二、通过备份表空间或者全库备份进行坏块修复三、没有备份、使用跳过坏块方式处理，此方法会丢数首先我们创建数据1、创建测试数据SQL> select * from test;A1 A2-------------------- --------------------lifang qwertxiaoqing poiuy2、查看对应file#,block#select rowid, dbm

select a.instance_number,a.sample_time,a.session_id,a.session_serial#, a.sql_id, b.sql_text from dba_hist_active_sess_history a, dba_hist_sqltext b where a.sql_id = b.sql_id and a.sample_time > to_date('2020-09-25 15:30:30', 'yyyy-mm-dd ..

巡检发现用户临时表空间在08：30左右，上涨50%1、查看临时表空间变化趋势图2、找到造成这一问题的sql语句通过捕获同一时间段的sql语句 ，发现是sql_id为8yquvdakbcjqz 导致的3、查看执行计划发现存在笛卡尔积MERGE JOIN CARTESIAN4、原因分析笛卡尔积的出现会严重影响执行效率，出现此问题的原因是：1)两个表的不对等(不属于本次问题)2)CBO优化器选择错误，统计信息收集不准确(1)只返回一行数据的表，查看是否需要收集统计信息select ta

巡检发现日志切换过于频繁，通过查看上图两处awr报告分析对应原因1、选取两段对应的时间2、查看产生日志量3、查看日志切换频率前者每小时切换日志15次4、查看是什么对象造成的问题由于涉及用户名和表名，已进行隐藏。查看发现主要是由于画框处对应的对象引起的，根据对应对象查看sql语句5、查看该对象对应的sql语句6、查看其他日志切换频繁时段AWR报告，发现都是同一个对象引发的7、分析该sql对应的作用发现是由于厂商的失误导致唯一标识过少，致使每次登陆时都会进行update语句更新，.