标签云
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,768)
- DB2 (22)
- MySQL (77)
- Oracle (1,609)
- Data Guard (52)
- EXADATA (8)
- GoldenGate (24)
- ORA-xxxxx (166)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (15)
- ORACLE 21C (3)
- Oracle 23ai (8)
- Oracle ASM (69)
- Oracle Bug (8)
- Oracle RAC (54)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (29)
- Oracle备份恢复 (591)
- Oracle安装升级 (97)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (86)
- PostgreSQL (30)
- pdu工具 (6)
- PostgreSQL恢复 (9)
- SQL Server (32)
- SQL Server恢复 (13)
- TimesTen (7)
- 达梦数据库 (3)
- 达梦恢复 (1)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (39)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (22)
-
最近发表
- ORA-600 kokiasg1故障分析(obj$中核心字典序列全部被恶意删除)
- ORA-00756 ORA-10567故障数据0丢失恢复
- 数据库文件变成32k故障恢复
- tcp连接过多导致监听TNS-12532 TNS-12560 TNS-00502错误
- 文件系统格式化MySQL数据库恢复
- .sstop勒索加密数据库恢复
- 解决一次硬件恢复之后数据文件0kb的故障恢复case
- Error in invoking target ‘libasmclntsh19.ohso libasmperl19.ohso client_sharedlib’问题处理
- ORA-01171: datafile N going offline due to error advancing checkpoint
- linux环境oracle数据库被文件系统勒索加密为.babyk扩展名溯源
- ORA-600 ksvworkmsgalloc: bad reaper
- ORA-600 krccfl_chunk故障处理
- Oracle Recovery Tools恢复案例总结—202505
- ORA-600 kddummy_blkchk 数据库循环重启
- 记录一次asm disk加入到vg通过恢复直接open库的案例
- CHECKDB 发现了 N 个分配错误和 M 个一致性错误
- 达梦数据库dm.ctl文件异常恢复
- Oracle Recovery Tools修复ORA-00742、ORA-600 ktbair2: illegal inheritance故障
- 可能是 tempdb 空间用尽或某个系统表不一致故障处理
- 11.2.0.4库中遇到ORA-600 kcratr_nab_less_than_odr报错
分类目录归档:数据库
Data Guard出现gap sequence修复
一、出现gap sequence现象
备库
Fetching gap sequence in thread 1, gap sequence 710-716 Tue May 31 15:02:38 2011 FAL[client]: Failed to request gap sequence GAP - thread 1 sequence 710-716 DBID 3240478808 branch 746916894 FAL[client]: All defined FAL servers have been attempted. ------------------------------------------------------------- Check that the CONTROL_FILE_RECORD_KEEP_TIME initialization parameter is defined to a value that is sufficiently large enough to maintain adequate log switch information to resolve archivelog gaps. -------------------------------------------------------------
主库
Tue May 31 13:50:47 2011 FAL[server]: Fail to queue the whole FAL gap GAP - thread 1 sequence 710-716 DBID 3240478808 branch 746916894
二、修复操作
1、查询备库的scn
SQL> SELECT CURRENT_SCN FROM V$DATABASE; CURRENT_SCN ----------- 1154337 --在出现意外datafile header scn不一致的时候,需要根据提示归档日志,找出最小scn
2、确定主库是否添加数据文件
SQL> select FILE#,name from v$datafile where CREATION_CHANGE#> =1154337; no rows selected
确定主库在这个scn之后是否有添加数据文件,如果添加文件,需要手工在备库添加
3、备库停止日志应用
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
4、主库增量备份并传输到备库上
主库进行增量备份
RMAN> BACKUP INCREMENTAL FROM SCN 1154337 DATABASE FORMAT '/home/oracle/xff_%U' tag 'XIFENFEI'; [oracle@localhost ~]$ scp xff* 192.168.1.30:/home/oracle/rman
说明:主库之前必须要做过rman的全备(没有全备的库,基于scn的增量备份也能够成功)
5、备库上进行恢复
RMAN> CATALOG START WITH '/home/oracle/rman'; RMAN> RECOVER DATABASE NOREDO;
说明:CATALOG START WITH是10g及其以后版本中才存在功能,没有该功能可以采用catalog或者复制主库的控制文件,rman备份放置和主库备份时相同目录实现。
6、主库上创建standby controlfile文件并传输到备库
RMAN> BACKUP CURRENT CONTROLFILE FOR STANDBY FORMAT '/home/oracle/xff_ctl.bck'; [oracle@localhost ~]$ scp xff_ctl.bck 192.168.1.30:/home/oracle/rman
创建standby controlfile两步可以需要根据实际情况考虑,大多数情况下不需要
7、备库恢复控制文件
RMAN> shutdown; RMAN> STARTUP NOMOUNT; RMAN> RESTORE STANDBY CONTROLFILE FROM '/home/oracle/rman/xff_ctl.bck'; RMAN> alter database mount;
8、清空备库日志组
SQL> ALTER DATABASE CLEAR LOGFILE GROUP 1; 注:如果采用了standby log模式,不需要清空,如果清空会出现 SQL> ALTER DATABASE CLEAR LOGFILE GROUP 1; ALTER DATABASE CLEAR LOGFILE GROUP 1 * ERROR at line 1: ORA-19527: physical standby redo log must be renamed ORA-00312: online log 1 thread 1: '/u01/oradata/xienfei/redo01.log'
说明:如果没有采用standby log模式,有几组需要清空几组
9、备库重设flashback
SQL> ALTER DATABASE FLASHBACK OFF; SQL> ALTER DATABASE FLASHBACK ON;
10、备库重新接收并应用日志
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
三、修复成功标志
1、sql中操作
在主库中执行alter system switch logfile;
分别主备库中执行select max(sequence#) from v$archived_log;如果一致标示修复成功
2、通过alert文件
主库
PING[ARC0]: Error 3113 when pinging standby xff. Tue May 31 14:11:51 2011 Thread 1 advanced to log sequence 719 Current log# 3 seq# 719 mem# 0: /u01/oradata/xienfei/redo03.log Tue May 31 14:20:05 2011 Thread 1 advanced to log sequence 720 Current log# 1 seq# 720 mem# 0: /u01/oradata/xienfei/redo01.log Tue May 31 14:20:16 2011 ARC0: Standby redo logfile selected for thread 1 sequence 719 for destination LOG_ARCHIVE_DEST_2
备库
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION Tue May 31 15:30:37 2011 Attempt to start background Managed Standby Recovery process (xff) MRP0 started with pid=18, OS id=14704 Tue May 31 15:30:37 2011 MRP0: Background Managed Standby Recovery process started (xff) Managed Standby Recovery not using Real Time Apply parallel recovery started with 2 processes Media Recovery Log /u01/archive/1_718_746916894.arc Tue May 31 15:30:43 2011 Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION Tue May 31 15:30:52 2011 RFS[1]: Successfully opened standby log 4: '/u01/oradata/xienfei/s_redo1.log' Media Recovery Log /u01/archive/1_719_746916894.arc Media Recovery Waiting for thread 1 sequence 720
发表在 Data Guard
2 条评论
单网卡绑定多IP导致TNS-12542等错误
今天想在家中访问下公司的oracle数据库,我了解的情况是那台服务器是有内外网ip,内网可以访问数据库。所以按照常理推断我只要配置下listener,外网应该也就可以正常访问
于是我就登陆到服务器上,修改listener.ora文件
SID_LIST_LISTENER = (SID_LIST = (SID_DESC = (SID_NAME = PLSExtProc) (ORACLE_HOME = /opt/oracle/product/10.2.0/db_1) (PROGRAM = extproc) ) ) LISTENER = (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.11.12)(PORT = 1521)) (ADDRESS = (PROTOCOL = TCP)(HOST = 211.155.227.172)(PORT = 1521)) (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC0)) ) )
lsnrctl start 不能正常启动,报错如下:
Error listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=211.155.227.172)(PORT=1521))) TNS-12542: TNS:address already in use TNS-12560: TNS:protocol adapter error TNS-00512: Address already in use Linux Error: 98: Address already in use
根据错误提示,意思是HOST=211.155.227.172这个(地址+端口+协议)已经被占用
第一反应:使用netstat -an|grep 1521没有发现该地址有1521端口启动,说明没有被占用
第二反应:防火墙,通过查看发现防火墙是关闭
通过以上两项查看都没有问题,那我修改下监听端口尝试下,然后我把监听端口改成了1522,监听能够正常启动,并且开始监听1522端口。通过实验证明1522端口是正常的,那问题出在哪里呢?为什么1521不行,我查看下ip地址的设置情况
eth0 Link encap:Ethernet HWaddr 00:E0:4D:C3:D5:18 inet addr:192.168.11.12 Bcast:192.168.11.255 Mask:255.255.252.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:5000774 errors:0 dropped:0 overruns:0 frame:0 TX packets:1610691 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:1828268348 (1.7 GiB) TX bytes:436101782 (415.8 MiB) eth0:1 Link encap:Ethernet HWaddr 00:E0:4D:C3:D5:18 inet addr:211.155.227.172 Bcast:211.155.227.175 Mask:255.255.255.240 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
发现192.168.11.12和211.155.227.172都是绑定在eth0的网卡上,因为监听在192.168.11.12启动了1521端口,所以211.155.227.172上的1521不能起来(因为同一张网卡)
我想既然是公用同一张网卡,那么监听了192.168.11.12:1521,那我用211.155.227.172:1521应该可以正常访问,除掉监听中的(ADDRESS = (PROTOCOL = TCP)(HOST = 211.155.227.172)(PORT = 1522)),然后直接在自己的电脑上修改tns,使用 211.155.227.172地址访问,果然能够访问。
通过这次事件得出结论:单网卡绑定多IP,只要监听主IP地址,其他绑定的IP均可以访问,不需要修改任何监听信息
OEM在Linux系统中乱码问题解决方法(redhat 5/ORACLE 10g)
如果想以中文显示,则需要修改一些配置文件。
包括三个目录:
$ORACLE_HOME/jdk/jre/lib
$ORACLE_HOME/jre/1.4.2/lib
$ORACLE_HOME/javavm/lib/ojvmfonts
这三个目录下都有 font.properties 和 font.properties.zh_CN.Redhat 文件。
如果DB中没有找够三个目录,那只要修改找到的目录下面的就可以啦。
font.properties文件备份:
cp $ORACLE_HOME/jdk/jre/lib/font.properties $ORACLE_HOME/jdk/jre/lib/font.properties.bak
cp $ORACLE_HOME/jre/1.4.2/lib/font.properties $ORACLE_HOME/jre/1.4.2/lib/font.properties.bak
cp $ORACLE_HOME/javavm/lib/ojvmfonts/font.properties $ORACLE_HOME/javavm/lib/ojvmfonts/font.properties.bak
用font.properties.zh_CN.Redhat替换font.properties
cp $ORACLE_HOME/jdk/jre/lib/font.properties.zh_CN.Redhat $ORACLE_HOME/jdk/jre/lib/font.properties
cp $ORACLE_HOME/jre/1.4.2/lib/font.properties.zh_CN.Redhat $ORACLE_HOME/jre/1.4.2/lib/font.properties
cp $ORACLE_HOME/javavm/lib/ojvmfonts/font.properties.zh_CN.Redhat $ORACLE_HOME/javavm/lib/ojvmfonts/font.properties
修改font.properties最后一行
filename.-misc-zysong18030-medium-r-normal–*-%d-*-*-c-*-iso10646-1=/usr/share/fonts/zh_CN/TrueType/zysong.ttf
我们发现字体文件 /usr/share/fonts/zh_CN/TrueType/uming.ttf 根本是不存在的,有些系统可以直接做一个链接文件链接到系统存在的字体文件就可以解决掉乱码问题,但是我的系统做了链接以后还是没能解决,只好修改三个目录下修改后的 font.properties 文件的最后一行为如下内容:
filename.-misc-zysong18030-medium-r-normal–*-%d-*-*-c-*-iso10646-1=/usr/share/fonts/chinese/TrueType/uming.ttf
删除OEM缓存文件
rm -rf $ORACLE_HOME/oc4j/j2ee/oc4j_applications/applications/em/em/cabo/images/cache/zhs/*
重启OEM
emctl stop dbconsole
emctl start dbconsole
说明:
修改的前提必须保证系统里存在这个字体文件
ls /usr/share/fonts/chinese/TrueType/fonts.dir fonts.scale ukai.ttf uming.ttf
自己可以找本系统对应的中文字体文件。
发表在 Oracle
评论关闭