eygle.com   eygle.com
eygle.com  
 
留言簿 - Oracle Life - Powered by Eygle.com
eygle.com 我要留言
唯书有色,艳于西子 唯文有华,秀于百卉
昵称
内容 页: < 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 > >> - 403
# 45989
流浪的野狼


来自: 深圳


To: 盖老师
  盖老师,有个问题想咨询一下您,
描述:数据库在归档模式下丢失了全部的控制文件,故此我在nomount状态下通过之前的rman备份恢复了控制文件,然后alter database mount;接着执行了recover database;在打开数据库时要求以resetlogs方式打开。执行alter database open resetlogs 后顺利开启数据库。
我的问题是:
  1、控制文件既然是旧的,如何同步信息到当前的状态,控制文件所需的同步信息从哪里来,如何使控制文件与数据文件达到一致的状态?
  2、我执行的既然是recover database;属于完全恢复的指令,为何还需要以resetlogs方式打开数据库呢?
From: 流浪的野狼
2013.11.17 03:42
To: 流浪的野狼
  控制文件可以重建得来,如果日志文件完好,数据文件完好,甚至不要做Resetlogs。

控制文件中的信息,可以从数据文件头、日志文件头等处获得。
From: eygle
2013.11.26 00:34

版主选项: 回复 编辑
# 45988
石秀


来自: 广东.深圳


To: 盖老师
  老师您好,看了好几本您写的oracle方面的书,但如何通过操作系统的优化来提高数据库的性能这方面的书太少了,老师可否建议下在操作系统方面我们该如何正对数据库进行调整,或者有什么书籍推荐下。
From: 石秀
2013.11.08 05:41
To: 石秀
  这些知识都是关联在一起的,我建议在遇到相关主题时,通过网络找到相关资源,广泛阅读,深入学习。
From: eygle
2013.11.26 00:32

版主选项: 回复 编辑
# 45987
cuixd_mjoys




To: eygle
  头回来这里留言,学习盖总的《深入浅出 ORACLE 备份恢复》
做实验过程中遇到点问题:
10.2.0.1在通过使用表删除前的全库备份对已删除表做基于时间点的不完全恢复后
alert日志中总有这些trc文件,如:
Errors in file /opt/oracle/admin/mjoysdb/udump/mjoysdb_ora_20086.trc:
....
打开其中某个trc的内容:
WARNING: Archival will be performed using 2 passes.
The first pass will attempt to determine the end-of-file
of the online redo logfile.The end-of-file is determined
by identifying what is described as a "corrupt" block
header.This will be reported as an ORA-00354 error.
However, this is not really a corrupt block - it is the
end of the redo data.
.....
krvscm(+): kccdiflg [404001] kccdifl2 [1000]
krvscm(+): kccdi2ldscn [0x0000.00000000]
krvscm(+): kccdi2lrscn [0x0000.00000000]
krvscm(+): Inspecting logical metadata
krvscm(+): Metadata state
krvscm(+): hasPrepSwitchSta [0]
请教什么原因,要紧吗? 谢谢盖总~~
From: cuixd_mjoys
2013.10.29 19:29
To: cuixd_mjoys
  把Redo Clear或者重建一下看看。
From: eygle
2013.11.06 20:46

版主选项: 回复 编辑
# 45986
Noc




To: 盖老师
  盖老师:
  请问一下,如何查看11gR2中的gv$session的真实语句,v$fixed_view_definition中只能显示4000字节,看您以前的帖子贴出了4344个字符,请指教一下!
From: Noc
2013.10.25 19:55
To: Noc
  从源文件里去找,rdbms 目录下可以找到。
From: eygle
2013.10.29 06:39

版主选项: 回复 编辑
# 45985
石秀


来自: 深圳


To: 盖老师
  非常感谢老师对之前问题的解答,我之后仔细看了下相关日志信息。的确像老师说的一样,sap同仁在做备份的时候,将归档日志备到带库之后是立即删除了归档日志了的
一直在学盖老师您的书,尤其对《深入浅出oracle DBA入门》、《oracle DBA 手记》系列的书,虽然《深入浅出oracle DBA入门》这本书已过去蛮久了,但是感觉每次看总有新的体会
From: 石秀
2013.10.23 04:43

版主选项: 回复 编辑
# 45984
海参


来自: 厦门


To: 盖老师
  我这里的oracle数据库是建立在window 2003 双机上,MSCS做的双机.oracle时常卡住,10来分钟后正常.oracle日志里
DEBUG: Replaying xcb 0xd4b85558, pmd 0xcf430a60 for failed op 8
ReconstructingUhdr 0x800079 for xcb 0xd4b85558, pmd 0xcf430a60
Doing block recovery for file 2 block 121
Block recovery from logseq 79891, block 32960 to scn 13421614668818
Flush retried for xcb 0xd230a448, pmd 0xcf441d78
DEBUG: Restoring block headers for xcb 0xd230a448, pmd 0xcf441d78
Recovery of Online Redo Log: Thread 1 Group 2 Seq 79891 Reading mem 0
Mem# 0: FATABASEXMJMNEWREDO201.LOG
Mem# 1: FATABASEXMJMNEWREDO202.LOG
Block recovery completed at rba 79891.38159.16, scn 3124.4136836115
DEBUG: Restoring block headers for xcb 0xd4b85558, pmd 0xcf430a60
DEBUG: Finished replay for xcb 0xd4b85558, pmd 0xcf430a60 for failed op 8
规律是,卡住后10分钟左右正常后,系统日志会报一个ql2300的警告,内容是"已复位设备device aidport2."有升级HBA卡的驱动到最新,ql2300的警告明显减少,每天就1-2个,但是oracle卡的问题还在,而每次卡完还有ql2300的警告。不知道这是HBA卡的问题导致oracle的不正常还是oracle本身有问题?或是存储有问题(数据文件是放在两台镜像的emcvnx5300上,麻烦您给指点一下,谢谢。
From: 海参
2013.10.14 00:25
To: 海参
  你给我发个awr报告,我帮你分析一下,涵盖异常点的报告。 eygle@eygle.com
From: eygle
2013.10.21 08:21

版主选项: 回复 编辑
# 45983
石秀


来自: 深圳


To: 盖老师
  老师您好,我想咨询一个oracle恢复的问题:
 最近遇到一个比较奇怪的问题,我window下的oracle数据库(与sap绑定安装的),在运行过程中我直接重启了window下的oracle服务,然后再重新开启数据库的时候提示需要大量的归档日志(七天之内的)进行恢复方可打开。不得已我追回了七天的归档日志才得以开启数据库。
 我的问题是:这样的异常关闭数据库不是应该是实例崩溃恢复吗?为什么还需要归档日志呢?下面是警告日志中我个人感觉唯一可能有问题的信息:
ALTER DATABASE RECOVER  CONTINUE DEFAULT 
ARCH: Warning. Log sequence in archive filename wrapped
to fix length as indicated by %S in LOG_ARCHIVE_FORMAT.
Old log archive with same name might be overwritten.
Sat Oct 12 10:57:15 2013
Media Recovery Log G:ORACLExxxxxxxARC99763_0593867878.001
Errors with log G:ORACLExxxxxxxARC99763_0593867878.001
ORA-308 signalled during: ALTER DATABASE RECOVER  CONTINUE DEFAULT ...

From: 石秀
2013.10.12 02:16
To: 石秀
  因为SAP是用热备进行的,应该未停止备份,所以需要日志久远。
另外,日志格式需要重新设置。
From: eygle
2013.10.21 08:22

版主选项: 回复 编辑
# 45982
石秀


来自: 深圳


To:
  老师您好,我想咨询一个oracle恢复的问题:
  最近遇到一个比较奇怪的问题,我window下的oracle数据库(与sap绑定安装的),在运行过程中我直接重启了window下的oracle服务,然后再重新开启数据库的时候提示需要大量的归档日志(七天之内的)进行恢复方可打开。不得已我追回了七天的归档日志才得以开启数据库。
 我的问题是:这样的异常关闭数据库不是应该是实例崩溃恢复吗?为什么还需要归档日志呢?下面是警告日志中我个人感觉唯一可能有问题的信息:
ALTER DATABASE RECOVERCONTINUE DEFAULT
ARCH: Warning.Log sequence in archive filename wrapped
to fix length as indicated by %S in LOG_ARCHIVE_FORMAT.
Old log archive with same name might be overwritten.
Sat Oct 12 10:57:15 2013
Media Recovery Log G:ORACLExxxxxxxARC99763_0593867878.001
Errors with log G:ORACLExxxxxxxARC99763_0593867878.001
ORA-308 signalled during: ALTER DATABASE RECOVERCONTINUE DEFAULT...
From: 石秀
2013.10.12 01:48

版主选项: 回复 编辑
# 45981
小方




To: 盖老师
  DBWR在写数据到磁盘的时候,CKPT每3秒钟查看一下DBWR沿检查点队列写到了哪里,并且将这个位置设置为检查点位置,并记录在控制文件中。那么假如,DBWR写了2秒的时候突然宕机了。oracle是用什么策略恢复的?从哪个点开始跑日志?那个点记录在哪里?是最后一个检查点对应的RBA吗?但是那个RBA已经不再跟数据库同步了呀,因为dbwr又写了2秒,ckpt却还没来得及更新检查点位置。
From: 小方
2013.09.23 18:49
To: 小方
  从low-cache rba开始恢复啊,只要是提交成功的,就已经记录了Redo日志,下次可以根据提交是否成功进行事务重演。DBWR写的是DB Block,通过redo能够重演事务。

如果DBWR写出了,但是相应的RBA没有记录到控制文件,这是没有关系的,脏数据写到文件,提交和未提交都有可能,必须以来Redo来进行判断。

当然,Oracle会有非常细粒度的检查,比如判断最后一个写是否成功:
http://www.eygle.com/archives/2010/05/ora-00600_kcratr1_lostwrt.html
From: eygle
2013.10.07 23:27

版主选项: 回复 编辑
# 45980
小方




To: 盖老师
  盖老师,您好,我想咨询一下。DBWR在写数据到磁盘的时候,CKPT每3秒钟查看一下DBWR沿检查点队列写到了哪里,并且将这个位置设置为检查点位置,并记录在控制文件中。那么假如,DBWR写了2秒的时候突然宕机了。oracle是用什么策略恢复的?
From: 小方
2013.09.23 18:06

版主选项: 回复 编辑

页: < 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 > >> - 403
我要留言
Copyright © 2003~2012 eygle.com All Rights Reserved.
Powered by: www.eygle.com