eygle.com   eygle.com
eygle.com  
 
留言簿 - Oracle Life - Powered by Eygle.com
eygle.com 我要留言
DBA警世录:备份重于一切
昵称
内容 页: < 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
# 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

版主选项: 回复 编辑
# 45979
qmxle




To: 盖老师
  盖老师你好,请教一个问题:项目中有一个特别长特别复杂的存储过程,根据传入的一个参数执行4种不同的逻辑。某天生产系统发现一个奇怪的现象,传入的这个参数值是3,执行的却是参数值为1的分支的逻辑;传入的这个参数值是4,执行的却是参数值为2的分支的逻辑。经理说一定是程序传错了参数值,但是我不认为是程序传错了,因为这个存储过程里面记录了传入的这个参数值,确实是3或者4,但奇怪的是执行的却是1或者2的分支的逻辑。后来程序重启之后这个现象就消失了。我想问问老师,这是不是可能是Oracle的BUG,跳转分支的逻辑跳转错了地址,因为我理解分支应该就是一个JMP的CPU指令啊。我们生产系统Oracle服务器的版本是10.2.0.4,Oracle客户端的版本是11.1.0.6.0。谢谢老师!
From: qmxle
2013.09.10 05:27
To: qmxle
  似乎不太可能是Oracle的Bug。很可能是程序的Bug。
From: eygle
2013.09.13 01:10

版主选项: 回复 编辑
# 45978
小欧


来自: china


To:
  老师好:请帮忙看看,10.2.0.1系统,AIX5,OLTP,PGA自动管理,pga_aggregate_target=1G,有64个进程来自某一个客户端机器连接,v$process.pga_alloc_mem和pga_used_mem非常大,每个进程用掉261M,导致AIX 系统内存和分页空间耗光,系统无法连接:
select pga_used_mem/1024/1024,pga_alloc_mem/1024/1024 from v$process
261.654592514038 262.579404830933
261.656766891479 262.579404830933
261.65878868103 262.579404830933
261.658811569214 262.516904830933
261.659093856812 262.579404830933
261.659452438354 262.641904830933
261.659833908081 262.579404830933
261.71689414978 262.579404830933
261.717290878296 262.641904830933
261.721410751343 262.704404830933
261.783842086792 262.704404830933
261.784353256226 262.704404830933
261.786046981812 262.704404830933
261.842351913452 262.704404830933
261.842557907104 262.766904830933
261.843252182007 262.766904830933
261.846227645874 262.766904830933
261.846311569214 262.704404830933
261.846754074097 262.766904830933
261.84677696228 262.704404830933
261.848173141479 262.766904830933
...
为什么单个进程内存突然出现这么大?
From: 小欧
2013.09.09 21:39
To: 小欧
  需要检查是执行了什么任务。

很有可能是排序、并行、大的查询等,显然用到了单进程最大PGA内存。需要具体分析执行的SQL、任务来判断。
From: eygle
2013.09.12 23:59

版主选项: 回复 编辑
# 45977
海郎




To: 盖老师
  盖老师,你好,我想咨询您一个问题:用低版本的数据库客户端连接高版本的数据库服务端,这样和同版本的客户端连接服务端比较的话,有什么劣势,或者说差别吗?谢谢!
From: 海郎
2013.08.28 03:12
To: 海郎
  如果用低版本连接高版本,某些新的特性可能无法利用,最好同等匹配。
From: eygle
2013.09.03 02:56

版主选项: 回复 编辑
# 45973
zhefeng


来自: canada


To: 盖国强
  盖老师,怎么订阅你的RSS啊,我用feedly,只显示很旧的post。
From: zhefeng
2013.08.09 13:42
To: zhefeng
   这个是及时的:
http://feeds2.feedburner.com/EyglesOracleBlog
From: eygle
2013.08.13 17:24

版主选项: 回复 编辑

页: < 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