标签云
asm恢复 bbed bootstrap$ dul kcbzib_kcrsds_1 kccpb_sanity_check_2 kcratr_nab_less_than_odr MySQL恢复 obet ORA-00312 ORA-00704 ORA-00742 ORA-01110 ORA-01200 ORA-01555 ORA-01578 ORA-01595 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-600 kcratr_nab_less_than_odr 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 比特币加密文章分类
- MongoDB (1)
- MongoDB恢复 (1)
- Others (2)
- 中间件 (2)
- WebLogic (2)
- 操作系统 (112)
- 数据库 (1,884)
- DB2 (22)
- MySQL (82)
- Oracle (1,709)
- Data Guard (53)
- EXADATA (8)
- GoldenGate (24)
- ORA-xxxxx (168)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (15)
- ORACLE 21C (3)
- Oracle 23ai (8)
- Oracle ASM (73)
- Oracle Bug (8)
- Oracle RAC (56)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (29)
- Oracle备份恢复 (662)
- Oracle安装升级 (108)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (91)
- PostgreSQL (37)
- pdu工具 (7)
- PostgreSQL恢复 (13)
- SQL Server (34)
- SQL Server恢复 (14)
- TimesTen (7)
- 达梦数据库 (5)
- 达梦恢复 (3)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (51)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (34)
- MongoDB (1)
-
最近发表
- 记录19c ASM磁盘掉线触发ORA-59048故障处理
- aix平台Oracle数据库由于断电无法启动故障处理
- 断电引起ORA-600 3005故障处理
- 记录一次云存储资源到期之后引起的数据库恢复
- Firebird 损坏数据库数据抢救工具—firebirdext
- Oracle 19c 202610补丁(RUs+OJVM)-19.33
- 由于con$.con#值达到极限,触发数据库增加约束报ORA-600 12807错误
- MongoDB 离线提取工具—mongoext
- .bres勒索病毒加密数据库dmp文件可恢复
- ORA-600 krsm_mrp_rebuild_lf_list.lno_mismatch
- 记录一次0丢失的ORA-00354: 损坏重做日志块标头故障恢复
- 不当数据库恢复操作导致一个月数据丢失
- obet快速修复oracle 位图损坏块
- 不太常见的10.2.0.1的oracle redo损坏恢复
- obet forcecopy功能抢救硬件故障中的数据文件
- kcratr_nab_less_than_odr和system坏块故障处理
- 通过obet 恢复system坏块,打开数据库
- obet dbv功能完整说明
- 分享一例运行在aix上的sap系统数据库恢复过程
- OBET-Oracle Block Editor Tool使用说明
月归档:二月 2012
ARCn: Media recovery disabled原因分析
1.数据库版本
SQL> select * from v$version; BANNER ------------------------------------------------------------- Oracle9i Enterprise Edition Release 9.2.0.8.0 - Production PL/SQL Release 9.2.0.8.0 - Production CORE 9.2.0.8.0 Production TNS for Linux: Version 9.2.0.8.0 - Production NLSRTL Version 9.2.0.8.0 - Production
2.alert日志出现类此记录
Fri Feb 10 05:16:55 2012 ARC1: Media recovery disabled Fri Feb 10 05:17:23 2012 ARC0: Media recovery disabled Fri Feb 10 05:17:23 2012 ARC1: Media recovery disabled Fri Feb 10 05:18:23 2012 ARC1: Media recovery disabled Fri Feb 10 05:19:12 2012 Thread 1 advanced to log sequence 24 Current log# 1 seq# 24 mem# 0: /tmp/recover/redo01.log Fri Feb 10 05:19:12 2012 ARC0: Media recovery disabled Fri Feb 10 05:19:23 2012 ARC1: Media recovery disabled Fri Feb 10 05:20:23 2012 ARC1: Media recovery disabled Fri Feb 10 05:21:23 2012 ARC1: Media recovery disabled
3.数据库归档信息
SQL> archive log list; Database log mode No Archive Mode Automatic archival Enabled Archive destination /tmp/recover Oldest online log sequence 25 Current log sequence 27 SQL> show parameter log_archive_start NAME TYPE VALUE ------------------------------------ ----------- --------------- log_archive_start boolean TRUE
从这里可以看出,数据库处于非归档模式,但是log_archive_start=true,这样会导致归档进程自动启动(ARCn),因为数据库设置为非归档模式,从而导致该进程启动后,又自己关闭
4.解决方法
SQL> alter system set log_archive_start=false scope=spfile; System altered. SQL> startup force ORACLE instance started. Total System Global Area 202445176 bytes Fixed Size 450936 bytes Variable Size 167772160 bytes Database Buffers 33554432 bytes Redo Buffers 667648 bytes Database mounted. Database opened. SQL> show parameter log_archive_start NAME TYPE VALUE ------------------------------------ ----------- -------------- log_archive_start boolean FALSE SQL> ARCHIVE LOG LIST; Database log mode No Archive Mode Automatic archival Disabled Archive destination /tmp/recover Oldest online log sequence 26 Current log sequence 28
ALERT中无类此记录出现
手动提交分布式事务一例
一.alert文件中出现了很多类此记录
Fri Feb 10 05:25:01 2012 Errors in file /tmp/recover/ahcx216_reco_7956.trc: ORA-12154: TNS:could not resolve service name Fri Feb 10 05:25:01 2012 Errors in file /tmp/recover/ahcx216_reco_7956.trc: ORA-12154: TNS:could not resolve service name
这里可以看出来两个信息:
1.出错的进程是rec0进程,而该进程的作用是解决分布式事务失败后遗留问题(事务提交或者回滚)
2.错误信息是tns不能被解析
二.查看trace文件
/tmp/recover/ahcx216_reco_7956.trc Oracle9i Enterprise Edition Release 9.2.0.8.0 - Production With the Partitioning, OLAP and Oracle Data Mining options JServer Release 9.2.0.8.0 - Production ORACLE_HOME = /opt/oracle/product/9.2.0/db_1 System name: Linux Node name: localhost.localdomain Release: 2.6.9-89.0.0.0.1.ELhugemem Version: #1 SMP Tue May 19 04:38:38 EDT 2009 Machine: i686 Instance name: ahcx216 Redo thread mounted by this instance: 1 Oracle process number: 7 Unix process pid: 7956, image: oracle@localhost.localdomain (RECO) *** SESSION ID:(6.1) 2012-02-10 04:58:24.886 *** 2012-02-10 04:58:24.886 ERROR, tran=6.1.712757, session#=1, ose=0: ORA-12154: TNS:could not resolve service name ……………… *** 2012-02-10 05:25:01.580 ERROR, tran=6.1.712757, session#=1, ose=0: ORA-12154: TNS:could not resolve service name *** 2012-02-10 05:25:01.627 ERROR, tran=12.19.99059, session#=1, ose=0: ORA-12154: TNS:could not resolve service name
通过这里我们可以看出事务id分别为12.19.99059和6.1.712757有问题
三.查看dba_2pc_pending视图
SQL> select local_tran_id,state,fail_time,retry_time from dba_2pc_pending; LOCAL_TRAN_ID STATE FAIL_TIME RETRY_TIME -------------- ---------------- -------------- -------------- 6.1.712757 collecting 2010/12/1 13:39:03 2012/2/10 5:38:52 12.19.99059 collecting 2010/12/1 15:56:26 2012/2/10 5:38:52
可以看出,果然有两个分布式事务在2010年12月1日出了问题(本库是一个问题库,在把库拉起来后发现该问题)
因为是异机恢复,而且间隔时间较长,很多tns的信息都已经不存在,所以需要手工提交分布式事务
四.手动提交事务
SQL> BEGIN
2 DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY('6.1.712757');
3 DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY('12.19.99059');
4 END;
5 /
BEGIN
*
第 1 行出现错误:
ORA-30019: Illegal rollback Segment operation in Automatic Undo mode
ORA-06512: at "SYS.DBMS_TRANSACTION", line 65
ORA-06512: at "SYS.DBMS_TRANSACTION", line 85
ORA-06512: at line 2
SQL> alter session set "_smu_debug_mode"=4;
Session altered.
-------------------------------------------------------------
--设置UNDO_SUPPRESS_ERRORS=true也可以解决此问题
alter system set UNDO_SUPPRESS_ERRORS = TRUE;
EXECUTE DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY('<事务ID>');
commit;
alter system set UNDO_SUPPRESS_ERRORS = false;
--------------------------------------------------------------
SQL> commit;
SQL> exec DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY('6.1.712757');
PL/SQL procedure successfully completed.
SQL> exec DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY('12.19.99059');
BEGIN DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY('12.19.99059'); END;
*
ERROR at line 1:
ORA-01453: SET TRANSACTION must be first statement of transaction
ORA-06512: at "SYS.DBMS_TRANSACTION", line 65
ORA-06512: at "SYS.DBMS_TRANSACTION", line 85
ORA-06512: at line 1
--第一个分布式事务处理后,未提交导致
SQL> commit;
Commit complete.
SQL> exec DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY('12.19.99059');
PL/SQL procedure successfully completed.
SQL> commit;
Commit complete.
五.补充说明
开始在另一个会话中,执行失败原因
SQL> alter session set "_smu_debug_mode"=4;
会话已更改。
SQL> commit;
提交完成。
SQL> BEGIN
2 DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY('6.1.712757');
3 DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY('12.19.99059');
4 END;
5 /
BEGIN
*
第 1 行出现错误:
ORA-01453: SET TRANSACTION must be first statement of transaction
ORA-06512: at "SYS.DBMS_TRANSACTION", line 65
ORA-06512: at "SYS.DBMS_TRANSACTION", line 85
ORA-06512: at line 3
因为这里的begin end中包含了两个事务的清理,在清理完第一个事务之后,需要提交才能够清理第二个,这里因为没有提交,导致ORA-01453错误。
通过sql语句获取awr/statspack逻辑读/物理读
在日常的性能监控中,我们经常需要需要通过一段时间内数据库的逻辑读/物理读来大致反映数据库的性能情况,这里列出通过awr和statspack来获取相关数据(查询最近30天数据,除掉第一条和最后一条数据)
awr逻辑读
WITH A AS
(SELECT B.SNAP_ID, SUM(VALUE)/1024/1024/1024*8192 VALUE
FROM DBA_HIST_SYSSTAT B
WHERE B.DBID = (SELECT DBID FROM V$DATABASE)
AND b.INSTANCE_NUMBER = &INST_NUM
AND B.STAT_NAME IN ('session logical reads')
GROUP BY B.SNAP_ID
ORDER BY SNAP_ID)
SELECT A.SNAP_ID,
LAG(VALUE, 1, '0') OVER(ORDER BY A.SNAP_ID) "START_VALUE(G)",
VALUE "END_VALUE(G)",
TO_CHAR(END_INTERVAL_TIME,'YYYY-MM-DD HH24:MI:SS')"END_TIME",
VALUE - LAG(VALUE, 1, '0') OVER(ORDER BY A.SNAP_ID) "D-VALUE(G)"
FROM A,(SELECT END_INTERVAL_TIME,SNAP_ID
FROM DBA_HIST_SNAPSHOT B
WHERE B.DBID = (SELECT dbid FROM v$database)
AND B.INSTANCE_NUMBER = &INST_NUM) B
WHERE A.SNAP_ID=B.snap_id
AND END_INTERVAL_TIME>=SYSDATE-30;
awr物理读
WITH A AS
(SELECT B.SNAP_ID, SUM(VALUE)/1024/1024/1024*8192 VALUE
FROM DBA_HIST_SYSSTAT B
WHERE B.DBID = (SELECT DBID FROM V$DATABASE)
AND b.INSTANCE_NUMBER = &INST_NUM
AND B.STAT_NAME IN ('physical reads')
GROUP BY B.SNAP_ID
ORDER BY SNAP_ID)
SELECT A.SNAP_ID,
LAG(VALUE, 1, '0') OVER(ORDER BY A.SNAP_ID) "START_VALUE(G)",
VALUE "END_VALUE(G)",
TO_CHAR(END_INTERVAL_TIME,'YYYY-MM-DD HH24:MI:SS')"END_TIME",
VALUE - LAG(VALUE, 1, '0') OVER(ORDER BY A.SNAP_ID) "D-VALUE(G)"
FROM A,(SELECT END_INTERVAL_TIME,SNAP_ID
FROM DBA_HIST_SNAPSHOT B
WHERE B.DBID = (SELECT dbid FROM v$database)
AND B.INSTANCE_NUMBER = &INST_NUM) B
WHERE A.SNAP_ID=B.snap_id
AND END_INTERVAL_TIME>=SYSDATE-30;
statspack逻辑读
WITH A AS
(SELECT B.SNAP_ID, SUM(VALUE)/1024/1024/1024*8192 VALUE
FROM STATS$SYSSTAT B
WHERE B.DBID = (SELECT DBID FROM V$DATABASE)
AND B.INSTANCE_NUMBER = &INST_NUM
AND B.NAME IN ('session logical reads')
GROUP BY B.SNAP_ID
ORDER BY SNAP_ID)
SELECT A.SNAP_ID,
LAG(VALUE, 1, '0') OVER(ORDER BY A.SNAP_ID) "START_VALUE(G)",
VALUE "END_VALUE(G)",
TO_CHAR(SNAP_TIME, 'YYYY-MM-DD HH24:MI:SS') "END_TIME",
VALUE - LAG(VALUE, 1, '0') OVER(ORDER BY A.SNAP_ID) "D-VALUE(G)"
FROM A,
(SELECT SNAP_TIME, SNAP_ID
FROM STATS$SNAPSHOT B
WHERE B.DBID = (SELECT DBID FROM V$DATABASE)
AND B.INSTANCE_NUMBER = &INST_NUM) B
WHERE A.SNAP_ID = B.SNAP_ID
AND snap_time>=SYSDATE-30;
statspack物理读
WITH A AS
(SELECT B.SNAP_ID, SUM(VALUE)/1024/1024/1024*8192 VALUE
FROM STATS$SYSSTAT B
WHERE B.DBID = (SELECT DBID FROM V$DATABASE)
AND B.INSTANCE_NUMBER = &INST_NUM
AND B.NAME IN ('physical reads')
GROUP BY B.SNAP_ID
ORDER BY SNAP_ID)
SELECT A.SNAP_ID,
LAG(VALUE, 1, '0') OVER(ORDER BY A.SNAP_ID) "START_VALUE(G)",
VALUE "END_VALUE(G)",
TO_CHAR(SNAP_TIME, 'YYYY-MM-DD HH24:MI:SS') "END_TIME",
VALUE - LAG(VALUE, 1, '0') OVER(ORDER BY A.SNAP_ID) "D-VALUE(G)"
FROM A,
(SELECT SNAP_TIME, SNAP_ID
FROM STATS$SNAPSHOT B
WHERE B.DBID = (SELECT DBID FROM V$DATABASE)
AND B.INSTANCE_NUMBER = &INST_NUM) B
WHERE A.SNAP_ID = B.SNAP_ID
AND snap_time>=SYSDATE-30;
发表在 Oracle
评论关闭

加我微信(17813235971)
加我QQ(107644445)

