ORACLE DATAGUARD中手工处理日志v$archive_GAP的方法

最近在还原Oracle数据库后open的时候碰到了ORA-00392: log 3 of thread 1 is being cleared, operation not allowed,其字面含义则是日志文件正在被清除,不允许操作. 通常情况下,当我们基于不完全恢复的时候,日志文件需要被清空,而此时是正在被清空.不是很好理解啊.下面是这个问题的解决方案. 一.故障现象 <code class="hljs vhdl">SQL> alter database open

正在看的ORACLE教程是:Oracle数据库系统紧急故障处理方法.Oracle物理结构故障是指构成数据库的各个物理文件损坏而导致的各种数据库故障.这些故障可能是由于硬件故障造成的,也可能是人为误操作而引起.所以我们首先要判断问题的起因,如果是硬件故障则首先要解决硬件问题.在无硬件问题的前提下我们才能按照下面的处理方发来进一步处理. 控制文件损坏: 控制文件记录了关于oracle的重要配置信息,如数据库名.字符集名字.各个数据文件.日志文件的位置等等信息.控制文件的损坏,会导致数据库异常关闭.一

在网上查了几天的资料,尝试综合清除告警日志内容及建外部表的方式来解决这一问题. 一:备份并清除告警日志内容 将每天的告警日志备份好,然后进行清除. 1:备份报警日志 在$ORACLE_HOME/SID/bdump/   目录下, 按日期备份alert_ORACLE_你的实例名.LOG这个文件,如:alert_ORACLE_orcl_201408111639_bak.LOG. 2:清除日志内容 打开报警日志文件,用true > 文件名 可清除掉里面的内容 具体示例: 假如,我现在第一次进行该设置,

1.了解oracle外部表 外部表定义:结构被存放在数据字典,而表数据被放在OS文件中的表 作用:在数据库中查询OS文件的数据,还可以将OS文件数据装载到数据库中 与其它表的区别:在外部表上不能执行DML操作,也不能在外部表上建索引,只能执行select操用 2.建一个简单的外部表1.建一个OS上的文件 因为外部表主要是查看OS上的文件,首先在OS上建一个文件mkdir -p /oracle/ext vi /oracle/ext/ext.dat 10,20,30 40,50,60 70,80,9

复制代码 代码如下: #!/bin/sh export BACK_DATE=`date +%Y%m%d` export BACKUP_PATH=/home/oracle/dbbak echo `mkdir -p ${BACKUP_PATH}/archivelog/${BACK_DATE}` rman msglog=$BACKUP_PATH/archivelog/${BACK_DATE}/arch_0_$BACK_DATE.log << EOF connect target /; delete

oracle 11g的监听日志和警告日志都是在/u01/oracle/diag/tnslsnr/oracle/listener目录和/u01/oracle/diag/rdbms/db1/db1目录下都有以下分别简称listener目录和db1目录.这两目录下都有如下目录:alert cdump hm incident incpkg ir lck metadata stage sweep trace 其中警告日志在alert目录下,监听日志在trace目录下.listener目录下产生的日志文件比

查看oracle数据库是否为归档模式 SQL> select name,log_mode from V$database; NAME LOG_MODE ------------------ ------------------------ TEST NOARCHIVELOG SQL> archive log list Database log mode No Archive Mode Automatic archival Disabled Archive destination USE_DB_

从9i以后,oracle dataguard 备库一般都不需要手工处理丢失的日志,FAL自动会帮我们处理,下面通过个案例来讲下手工处理丢失的日志的方法: 1.在备库查询有哪些日志丢失,没应用到备库 SQL> select * from V$ARCHIVE_GAP; THREAD# LOW_SEQUENCE# HIGH_SEQUENCE# ---------- ------------- -------------- 1 9873 9876 我们可以看到9873到9876这四个归档日志丢失, 2.

死锁的原理 当对于数据库某个表的某一列做更新或删除等操作,执行完毕后该条语句不提 交,另一条对于这一列数据做更新操作的语句在执行的时候就会处于等待状态, 此时的现象是这条语句一直在执行,但一直没有执行成功,也没有报错.    死锁的定位方法 通过检查数据库表,能够检查出是哪一条语句被死锁,产生死锁的机器是哪一台.   1)用dba用户执行以下语句 select username,lockwait,status,machine,program from v$session where sid in

ORACLE DATAGUARD的主备库同步,主要是依靠日志传输到备库,备库应用日志或归档来实现.当主.备库间日志传输出现GAP,备库将不再与主库同步.因此需对日志传输状态进行监控,确保主.备库间日志没有GAP,或发现GAP后及时处理.除了在告警日志中查看日志同步情况外,还可以通过查看相关视图来对日志传输状态进行监控. 1.主.备库查看当前日志状况 SELECT SEQUENCE#,STATUS FROM V$LOG; 2.备库查看RFS接收日志和MRP应用日志同步主库情况 SELECT PRO

数据库环境: 数据库版本(RU):  19.10 GRID_HOME:       /u01/app/19.0.0/grid ORACLE_HOME:     /u01/app/oracle/product/19.0.0/db_1 DB_NAME: orcl 1.创建adump目录(每个节点执行) mkdir -p /u01/app/oracle/admin/orcl/adump 2.修改$ORACLE_HOME/bin/oracle文件权限(每个节点执行) /u01/app/19.0.0/gr

在使用ORACLE的过程中,会出现各种各样的问题,各种各样的错误,其中ORA-12899就是前段时间我在将数据导入到我本地机器上的时候一直出现的问题.不过还好已经解决了这个问题,现在分享一下,解决方案; 出现ORA-12899,是字符集引起的,中文在UTF-8中占3个字节,ZHS16GBK中占2个字节,而源dmp文件字符集是ZHS16GBK库里倒出来的数据,现在要导入到目标字符集为UTF-8的库里,所以会出现ORA-12899 其实只要修改一下ORACLE 的字符集就可以很好的解决这个问题; 但

一.控制文件 作用: 二进制文件 记录了数据库当前实例的结构和行为,数据文件日志文件的信息,维护数据库一致性 参数文件中定义了控制文件的位置和大小 很小的二进制文件,一般不超过100m mount阶段open以后,一直在用 一套控制文件只能连接一个database 分散放置,至少一份,至多八份 相关视图: v$controlfile ---- 列出实例的所有控制文件的名字和状态 v$parameter ---- 列出所有参数的位置和状态(where name='control_files') v

Oracle表中重复数据去重的方法实例详解 我们在项目中肯定会遇到一种情况,就是表中没有主键 有重复数据 或者有主键 但是部分字段有重复数据 而我们需要过滤掉重复数据 下面是一种解决方法 delete from mytest ms where rowid in (select aa.rid from (select rowid as rid, row_number() over(partition by s.name order by s.id) as nu from mytest s) aa

SQL%NOTFOUND 是一个布尔值.与最近的sql语句(update,insert,delete,select)发生交互,当最近的一条sql语句没有涉及任何行的时候,则返回true.否则返回false.这样的语句在实际应用中,是非常有用的.例如要update一行数据时,如果没有找到,就可以作相应操作.如: begin update table_name set salary = 10000 where emp_id = 10; if sql%notfound then insert into

在SQL语句优化过程中,我们经常会用到hint,现总结一下在SQL优化过程中常见Oracle HINT的用法: 1. /*+ALL_ROWS*/ 表明对语句块选择基于开销的优化方法,并获得最佳吞吐量,使资源消耗最小化. 例如: SELECT /*+ALL+_ROWS*/ EMP_NO,EMP_NAM,DAT_IN FROM BSEMPMS WHERE EMP_NO='SCOTT'; 2. /*+FIRST_ROWS*/ 表明对语句块选择基于开销的优化方法,并获得最佳响应时间,使资源消耗最小化.