标签云
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 2131 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)
- 操作系统 (102)
- 数据库 (1,683)
- DB2 (22)
- MySQL (73)
- Oracle (1,545)
- Data Guard (52)
- EXADATA (8)
- GoldenGate (24)
- ORA-xxxxx (159)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (15)
- ORACLE 21C (3)
- Oracle 23ai (7)
- Oracle ASM (68)
- Oracle Bug (8)
- Oracle RAC (53)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (28)
- Oracle备份恢复 (565)
- Oracle安装升级 (92)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (79)
- PostgreSQL (18)
- PostgreSQL恢复 (6)
- SQL Server (27)
- SQL Server恢复 (8)
- TimesTen (7)
- 达梦数据库 (2)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (37)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (20)
-
最近发表
- ORA-15411: Failure groups in disk group DATA have different number of disks.
- 断电引起的ORA-08102: 未找到索引关键字, 对象号 39故障处理
- ORA-00227: corrupt block detected in control file
- 手工删除19c rac
- 解决oracle数据文件路径有回车故障
- .wstop扩展名勒索数据库恢复
- Oracle Recovery Tools工具一键解决ORA-00376 ORA-01110故障(文件offline)
- OGG-02771 Input trail file format RELEASE 19.1 is different from previous trail file form at RELEASE 11.2.
- OGG-02246 Source redo compatibility level 19.0.0 requires trail FORMAT 12.2 or higher
- GoldenGate 19安装和打patch
- dd破坏asm磁盘头恢复
- 删除asmlib磁盘导致磁盘组故障恢复
- Kylin Linux 安装19c
- ORA-600 krse_arc_complete.4
- Oracle 19c 202410补丁(RUs+OJVM)
- ntfs MFT损坏(ntfs文件系统故障)导致oracle异常恢复
- .mkp扩展名oracle数据文件加密恢复
- 清空redo,导致ORA-27048: skgfifi: file header information is invalid
- A_H_README_TO_RECOVER勒索恢复
- 通过alert日志分析客户自行对一个数据库恢复的来龙去脉和点评
分类目录归档:Linux
shell脚本获得extents分布
比较深入看过dba_extents视图的朋友都知道,它得到extent的信息不是通过普通的存储在数据库中的基表获得,而是x$相关的表获得(x$表是数据库启动时候在内存中创建,不存在数据文件中),因为当数据库未正常启动,我们无法直接确定某个block是否在某个对象中.其实关于extent的信息都已经记录在了segment header的block中,通过dump该block记录的rdba信息,未转化为file_id和block_id,这里写shell脚本实现把segment header dump 内容转化为类似dba_extents记录,方便在某些不能open的库中分析某个异常block是否属于某个表
#! /bin/bash dec2bin(){ val_16=$1 ((num=$val_16)); val=`echo $num` local base=$2 [ $val -eq 0 ] && bin=0 if [ $val -ge $base ]; then dec2bin $val $((base*2)) if [ $val -ge $base ]; then val=$(($val-$base)) bin=${bin}1 else bin=${bin}0 fi fi [ $base -eq 1 ] && printf $bin } for i in `grep "length:" $1 |awk '{print $1 $3}'`; do rdba=`echo ${i:0:10}` blocks=`echo ${i:10}` echo -n "rdba:"$rdba" " bin2=`dec2bin $rdba 1` len=`expr length $bin2` len_gd=22 len_jg=`expr $len - $len_gd` file_no_2=`echo ${bin2:0:$len_jg}` ((file_no=2#$file_no_2)) echo -n "file_id:"$file_no" " block_no_2=`echo ${bin2:$len_jg}` ((block_no=2#$block_no_2)) echo -n "block_id:"$block_no" " echo "blocks:"$blocks done;
trace文件中部分信息
----------------------------------------------------------------- 0x00400901 length: 7 0x00402e10 length: 8 0x00402e60 length: 8 0x00402e68 length: 8 0x00402ea0 length: 8 0x00402f20 length: 8 0x00402f48 length: 8 0x00403050 length: 8 0x00403180 length: 8 0x00403b38 length: 8 0x00404c48 length: 8 0x00404c78 length: 8 0x00404cf8 length: 8 0x00404da8 length: 8 0x00404db8 length: 8 0x00404de8 length: 8 0x00404e80 length: 128 0x00405900 length: 128 0x00406500 length: 128 0x00406980 length: 128 0x00407480 length: 128 0x00407500 length: 128 0x00407680 length: 128 0x00407800 length: 128 0x00407880 length: 128 0x00407a00 length: 128 0x00407a80 length: 128 0x00407c80 length: 128 …………
执行结果
[oracle@xifenfei tmp]$ ./get_extent.sh /u01/app/oracle/diag/rdbms/cdb/cdb/trace/cdb_ora_29565.trc rdba:0x00400901 file_id:1 block_id:2305 blocks:7 rdba:0x00402e10 file_id:1 block_id:11792 blocks:8 rdba:0x00402e60 file_id:1 block_id:11872 blocks:8 rdba:0x00402e68 file_id:1 block_id:11880 blocks:8 rdba:0x00402ea0 file_id:1 block_id:11936 blocks:8 rdba:0x00402f20 file_id:1 block_id:12064 blocks:8 rdba:0x00402f48 file_id:1 block_id:12104 blocks:8 rdba:0x00403050 file_id:1 block_id:12368 blocks:8 rdba:0x00403180 file_id:1 block_id:12672 blocks:8 rdba:0x00403b38 file_id:1 block_id:15160 blocks:8 rdba:0x00404c48 file_id:1 block_id:19528 blocks:8 rdba:0x00404c78 file_id:1 block_id:19576 blocks:8 rdba:0x00404cf8 file_id:1 block_id:19704 blocks:8 rdba:0x00404da8 file_id:1 block_id:19880 blocks:8 rdba:0x00404db8 file_id:1 block_id:19896 blocks:8 rdba:0x00404de8 file_id:1 block_id:19944 blocks:8 rdba:0x00404e80 file_id:1 block_id:20096 blocks:128 rdba:0x00405900 file_id:1 block_id:22784 blocks:128 rdba:0x00406500 file_id:1 block_id:25856 blocks:128 rdba:0x00406980 file_id:1 block_id:27008 blocks:128 rdba:0x00407480 file_id:1 block_id:29824 blocks:128 rdba:0x00407500 file_id:1 block_id:29952 blocks:128 rdba:0x00407680 file_id:1 block_id:30336 blocks:128 rdba:0x00407800 file_id:1 block_id:30720 blocks:128 …………
新删除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 条评论