标签云
asm恢复 bbed bootstrap$ dul In Memory kcbzib_kcrsds_1 kccpb_sanity_check_2 MySQL恢复 ORA-00312 ORA-00607 ORA-00704 ORA-00742 ORA-01110 ORA-01555 ORA-01578 ORA-01595 ORA-08103 ORA-600 2131 ORA-600 2662 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)
- 操作系统 (103)
- 数据库 (1,749)
- DB2 (22)
- MySQL (76)
- Oracle (1,594)
- Data Guard (52)
- EXADATA (8)
- GoldenGate (24)
- ORA-xxxxx (162)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (15)
- ORACLE 21C (3)
- Oracle 23ai (8)
- Oracle ASM (68)
- Oracle Bug (8)
- Oracle RAC (54)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (28)
- Oracle备份恢复 (584)
- Oracle安装升级 (96)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (84)
- PostgreSQL (30)
- pdu工具 (6)
- PostgreSQL恢复 (9)
- SQL Server (30)
- SQL Server恢复 (11)
- TimesTen (7)
- 达梦数据库 (2)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (38)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (21)
-
最近发表
- [MY-013183] [InnoDB] Assertion failure故障处理
- Oracle 19c 202504补丁(RUs+OJVM)-19.27
- Oracle Recovery Tools修复ORA-600 6101/kdxlin:psno out of range故障
- pdu完美支持金仓数据库恢复(KingbaseES)
- 虚拟机故障引起ORA-00310 ORA-00334故障处理
- pg创建gbk字符集库
- PostgreSQL运行日志管理
- ora-600 kdsgrp1 错误描述
- GAM、SGAM 或 PFS 页上存在页错误处理
- ORA-600 krhpfh_03-1208
- VMware勒索加密恢复(vmdk勒索恢复)
- ORA-39773: parse of metadata stream failed故障处理
- sql数据库备份失败—失败: 23(数据错误(循环冗余检查)
- vmdk文件被加密恢复(虚拟机文件加密)
- 差点被误操作的ORA-600 kcratr_nab_less_than_odr故障
- win平台19c 打patch遭遇2个小问题汇总
- pg单个数据库目录恢复-pdu恢复单个数据库目录数据
- pg删除数据恢复—pdu恢复pg delete数据
- .[OnlyBuy@cyberfear.com].REVRAC勒索mysql恢复
- 表dml操作权限授权给public,导致只读用户失效
分类目录归档: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 条评论