标签云
asm 恢复 asm恢复 bbed bootstrap$ dul In Memory kcbzib_kcrsds_1 kccpb_sanity_check_2 kfed MySQL恢复 ORA-00312 ORA-00607 ORA-00704 ORA-01110 ORA-01555 ORA-01578 ORA-08103 ORA-600 2662 ORA-600 2663 ORA-600 3020 ORA-600 4000 ORA-600 4137 ORA-600 4193 ORA-600 4194 ORA-600 16703 ORA-600 kcbzib_kcrsds_1 ORA-600 KCLCHKBLK_4 ORA-15042 ORA-15196 ORACLE 12C oracle dul ORACLE PATCH Oracle Recovery Tools oracle加密恢复 oracle勒索 oracle勒索恢复 oracle异常恢复 ORACLE恢复 Oracle 恢复 ORACLE数据库恢复 oracle 比特币 OSD-04016 YOUR FILES ARE ENCRYPTED 勒索恢复 比特币加密文章分类
- Others (2)
- 中间件 (2)
- WebLogic (2)
- 操作系统 (100)
- 数据库 (1,589)
- DB2 (22)
- MySQL (70)
- Oracle (1,459)
- Data Guard (49)
- EXADATA (7)
- GoldenGate (21)
- ORA-xxxxx (158)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (13)
- ORACLE 21C (3)
- Oracle ASM (65)
- Oracle Bug (7)
- Oracle RAC (47)
- Oracle 安全 (6)
- Oracle 开发 (27)
- Oracle 监听 (27)
- Oracle备份恢复 (526)
- Oracle安装升级 (83)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (75)
- PostgreSQL (13)
- PostgreSQL恢复 (3)
- SQL Server (27)
- SQL Server恢复 (8)
- TimesTen (7)
- 达梦数据库 (2)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (36)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (19)
-
最近发表
- ORA-00600: internal error code, arguments: [16703], [1403], [4] 原因
- 最近遇到几起ORA-600 16703故障(tab$被清空),请引起重视
- ORA-600 2662快速恢复之Patch scn工具
- TNS-12518: TNS:listener could not hand off client connection
- ora.storage无法启动报ORA-12514故障处理
- 断电引起文件scn异常数据库恢复
- ORA-16188: LOG_ARCHIVE_CONFIG settings inconsistent with previously started instance
- .[hudsonL@cock.li].mkp勒索加密数据库完美恢复
- 模拟带库实现rman远程备份
- 又一例:ORA-600 kclchkblk_4和2662故障
- Oracle误删除数据文件恢复
- Oracle 19C 备库DML重定向—DML Redirection
- ORA-01595/ORA-600 4194处理
- 从ORA-00283 ORA-16433报错开始恢复
- 近期又遇到ORA-600 16703和ORA-702故障
- RECOVER_YOUR_DATA勒索恢复
- ORA-01033: ORACLE initialization or shutdown in progress 故障处理
- Oracle 19c/21c最新patch信息-202401
- 存储故障,强制拉库报ORA-600 kcbzib_kcrsds_1处理
- ORA-600 kcrf_resilver_log_1故障处理
月归档:十一月 2012
新删除data guard归档日志shell脚本
以前写过删除dataguard归档日志的方法(删除data guard归档日志),但是以前的方法确实不够灵活也不够简便,现在提供最新的一次在客户现场部署的dg删除归档日志的shell脚本
#!/bin/sh source ~/.bash_profile grep "Media Recovery Log" $ORACLE_BASE/admin/$ORACLE_SID/bdump/alert_${ORACLE_SID}.log| \ awk '{print $4}'|sed -e 's/^/rm /' >/tmp/rmarchlog.sh chmod +x /tmp/rmarchlog.sh /tmp/rmarchlog.sh cd $ORACLE_BASE/admin/$ORACLE_SID/bdump cat alert_${ORACLE_SID}.log >>alert_${ORACLE_SID}.log.bak echo ''>alert_${ORACLE_SID}.log rm -f /tmp/rmarchlog.sh $ORACLE_HOME/bin/rman target / <<XIFENFEI crosscheck archivelog all; delete expired archivelog all; YES exit; XIFENFEI
根据alert日志中dg应用日志的信息”Media Recovery Log”信息来删除掉相关的归档日志,可以保证应用过的归档日志都被删除,而没有应用的归档日志都保留.
发表在 Data Guard, Linux
2 条评论
shell监控dataguard备库是否正常应用日志
一直在思索怎么去监控dg比较方便,又能够做到比较适用.想到了几种方法:
1.使用主备库两边的alert日志,但是这样的方法需要配置ssh,用来一个节点获取另外一个节点的alert日志
2.通过查询v$archived_log或者其他相关视图,然后主备库进行比较,但是这个需要访问另外一个库,需要另外库的登录信息
3.通过查询备库的v$archived_log视图,粗略评估dg是否工作正常.
这里我选择了3,dg的监控大部分时候是为了让人及时的发现日志应用异常,然后人工干预处理,从而减少修改gap或者重建dg的概率.而这个额监控可以在很大程度上发现dg应用归档日志异常,从而确定dg是否工作正常,如果发现工作异常,及时处理,可以减少很多工作量,甚至拯救你的数据.
#!/bin/bash source ~/.bash_profile #check time(M) export CHECK_M=120 export RESULT_FILE=/tmp/dg_switch_check.log $ORACLE_HOME/bin/sqlplus -silent "/ as sysdba" <<XFF>/tmp/check_dg.log set pagesize 0 feedback off verify off heading off echo off select ceil((sysdate-next_time)*24*60) "M" from v\$archived_log where applied='YES' AND SEQUENCE#=(SELECT MAX(SEQUENCE#) FROM V\$ARCHIVED_LOG WHERE applied='YES'); exit; XFF GET_M=`cat /tmp/check_dg.log` rm /tmp/check_dg.log if [ ${CHECK_M} -lt ${GET_M} ]; then echo "check dataguard time:`date`">$RESULT_FILE echo "The last time application archivelog happened in $GET_M minutes ago">>$RESULT_FILE else echo ''>$RESULT_FILE fi
针对这样的脚本,根据你的dg归档切换的频率,设置监控dg的最近一次日志应用与当前时间差,然后判断dg是否工作正常.根据监控程序的特点,可以通过判断结果集文件,然后邮件/短信或者其他方式处理.
发表在 Data Guard, Linux
2 条评论
因v$archived_log视图记录异常导致dg MRP进程异常
版本信息
操作系统Linux 4.8 x86 数据库版本ORACLE 9.2.0.4
alert日志报错
MRP进程出现异常报ORA-00310/ORA-00334错误
………… Media Recovery Log /u01/oracle/oradata/lunar/arch/1_75.dbf Media Recovery Log /u01/oracle/oradata/lunar/arch/1_76.dbf Media Recovery Log /u01/oracle/oradata/lunar/arch/1_77.dbf Media Recovery Log /u01/oracle/oradata/lunar/arch/1_78.dbf Media Recovery Log /u01/oracle/oradata/xifenfei/redo02.log MRP0: Background Media Recovery terminated with error 310 Thu Nov 8 07:44:39 2012 Errors in file /u01/oracle/admin/lunar/bdump/lunar_mrp0_25625.trc: ORA-00310: archived log contains sequence 85; sequence 79 required ORA-00334: archived log: '/u01/oracle/oradata/xifenfei/redo02.log' Recovery interrupted. MRP0: Background Media Recovery process shutdown
trace文件
*** SESSION ID:(17.13) 2012-11-08 07:24:12.986 Background Managed Standby Recovery process started *** 2012-11-08 07:24:18.023 Managed Recovery: Active posted. *** 2012-11-08 07:41:03.171 Media Recovery Log /u01/oracle/oradata/lunar/arch/1_64.dbf Media Recovery Log /u01/oracle/oradata/lunar/arch/1_65.dbf Media Recovery Log /u01/oracle/oradata/lunar/arch/1_66.dbf Media Recovery Log /u01/oracle/oradata/lunar/arch/1_67.dbf Media Recovery Log /u01/oracle/oradata/lunar/arch/1_68.dbf Media Recovery Log /u01/oracle/oradata/lunar/arch/1_69.dbf Media Recovery Log /u01/oracle/oradata/lunar/arch/1_70.dbf Media Recovery Log /u01/oracle/oradata/lunar/arch/1_71.dbf Media Recovery Log /u01/oracle/oradata/lunar/arch/1_72.dbf Media Recovery Log /u01/oracle/oradata/lunar/arch/1_73.dbf Media Recovery Log /u01/oracle/oradata/lunar/arch/1_74.dbf Media Recovery Log /u01/oracle/oradata/lunar/arch/1_75.dbf Media Recovery Log /u01/oracle/oradata/lunar/arch/1_76.dbf *** 2012-11-08 07:41:39.083 Media Recovery Log /u01/oracle/oradata/lunar/arch/1_77.dbf *** 2012-11-08 07:44:39.171 Media Recovery Log /u01/oracle/oradata/lunar/arch/1_78.dbf Media Recovery Log /u01/oracle/oradata/xifenfei/redo02.log Background Media Recovery terminated with error 310 ORA-00310: archived log contains sequence 85; sequence 79 required ORA-00334: archived log: '/u01/oracle/oradata/xifenfei/redo02.log' ----- Redo read statistics for thread 1 ----- Read rate (ASYNC): 21990Kb in 1221.38s => 0.02 Mb/sec Longest record: 1Kb, moves: 0/92129 (0%) Change moves: 34869/213735 (16%), moved: 2Mb ---------------------------------------------- *** 2012-11-08 07:44:39.404 Managed Recovery: Not Active posted. Background Media Recovery process shutdown *** 2012-11-08 07:44:39.406
猜想数据库恢复需要sequence为79的归档日志,但是该归档日志对应的为文件为redo02.log,而该redo02的seq为85所以使得MRP进程异常
使用rman尝试恢复
RMAN> recover database ; Starting recover at 08-NOV-12 using target database controlfile instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: sid=8 devtype=DISK starting media recovery unable to find archive log archive log thread=1 sequence=79 RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of recover command at 11/08/2012 08:12:48 RMAN-06054: media recovery requesting unknown log: thread 1 scn 12286829427051
测试证明rman也无法正常的恢复该异常问题
验证猜想
SQL> select name from v$archived_log where SEQUENCE#=79; NAME ------------------------------------------------------------------- /u01/oracle/oradata/lunar/arch/1_79.dbf /u01/oracle/oradata/xifenfei/redo02.log /u01/oracle/oradata/lunar/arch/1_79.dbf SQL> select dest_id,name from v$archived_log where SEQUENCE#=79; DEST_ID NAME ---------- --------------------------------------------------- 2 /u01/oracle/oradata/lunar/arch/1_79.dbf 1 /u01/oracle/oradata/xifenfei/redo02.log 1 /u01/oracle/oradata/lunar/arch/1_79.dbf SQL> select sequence#,group# from v$log; SEQUENCE# GROUP# ---------- ---------- 86 1 85 2 87 3 SQL> select member from v$logfile where group#=2; MEMBER --------------------------------------------------------------- /u01/oracle/oradata/xifenfei/redo02.log
通过查询上面相关视图,证实了猜想是因为redo log被注册进入了v$archived_log导致该故障,解决该问题的思路是把redo log file从备库控制文件的v$archived_log视图中拿掉.具体方法是:
1.如果主库正常,那直接生成standby controlfile来实现
2.如果主库也是相同情况,那么先重建主库控制文件,然后重建standby controlfile来实现(该方法需要维护窗口)
解决问题思路
--查询主库,确定主库正常 SQL> select name from v$archived_log where SEQUENCE#=79; NAME ------------------------------------------------------------ /u01/oracle/oradata/xifenfei/archive/1_79.dbf lunar --重新创建standby controlfile ############################################################### 注:如果主库和备库的数据文件路径不完全一致, 建议通过设置db_file_name_convert来直接实现备库数据文件路径的转换, 而不建议通过alter database rename file来实现重命名 ############################################################### SQL> ALTER DATABASE CREATE STANDBY CONTROLFILE AS 2 '/u01/oracle/oradata/lunar/control01.ctl' reuse; Database altered. --重新启动备库 SQL> startup nomount; ORACLE instance started. Total System Global Area 353441008 bytes Fixed Size 451824 bytes Variable Size 184549376 bytes Database Buffers 167772160 bytes Redo Buffers 667648 bytes SQL> alter database mount standby database; Database altered. --开启日志应用 SQL> alter database recover managed standby database disconnect from session; Database altered. --alert日志 Thu Nov 8 08:28:16 2012 Completed: alter database recover managed standby database di Thu Nov 8 08:28:20 2012 Restarting dead background process QMN0 QMN0 started with pid=13 Thu Nov 8 08:29:45 2012 Fetching gap sequence for thread 1, gap sequence 79-87 Trying FAL server: xifenfei Media Recovery Log /u01/oracle/oradata/lunar/arch/1_79.dbf Media Recovery Log /u01/oracle/oradata/lunar/arch/1_80.dbf Media Recovery Log /u01/oracle/oradata/lunar/arch/1_81.dbf Media Recovery Log /u01/oracle/oradata/lunar/arch/1_82.dbf Media Recovery Log /u01/oracle/oradata/lunar/arch/1_83.dbf Media Recovery Log /u01/oracle/oradata/lunar/arch/1_84.dbf Media Recovery Log /u01/oracle/oradata/lunar/arch/1_85.dbf Media Recovery Log /u01/oracle/oradata/lunar/arch/1_86.dbf Media Recovery Log /u01/oracle/oradata/lunar/arch/1_87.dbf Media Recovery Log /u01/oracle/oradata/lunar/arch/1_88.dbf Media Recovery Waiting for thread 1 seq# 89
发表在 Data Guard
一条评论