设为首页收藏本站

Botang唐波's Oracle Station

查看: 925|回复: 2

请教nologging的问题

[复制链接]

80

主题

179

帖子

772

积分

高级会员

Rank: 4

积分
772
发表于 2016-10-19 10:08:53 | 显示全部楼层 |阅读模式
本帖最后由 lujiaguai 于 2016-10-19 10:33 编辑

唐sir:
   求教一下,如果说开发人员的账号权限较高,具有创建create tablespace nologging或者alter tablespace nologing以及alter table nologing或者create table nologging的权限
   那么两种情况来说:
   1,用户create tablespace nologing了一个表空间,那么今后这个表空间下所有的动作都是nologing的吗?还是说只有append高水位线加载,insert  /* + append */ ,才会导致日志缺失?
        如果今后该表空间下的操作都缺少redo记录,是否意味着所有的对表空间下数据的操作都会丢失原值的redo记录。
        这样的话rman的备份管理员如果不知道用户做了nologging的动作,出现问题的时,恢复会缺少redo及archivelog,导致rman恢复失败报错吗?        

        同样的,如果alter tablespace nologging的情况是否一样?
        rman的管理员是否应该重视这样的问题?在nologing时管理员应当知情吗?并在恢复logging以后做一次全备份?

   2 ,同样的问题,如果说用户权限不足,可能没有对tablespace的权限。那么在实际环境中,用户creat table 或者 alter table的权限总是有的。
         用户如果在表上应用了nologging 并且做了 append高水位线加载,insert  /* + append */ ,是否也会导致日志缺失,出现rman恢复的失败?

   上述的担心是否杞人忧天?对rman恢复来说,不会出现任何问题吗?
   我见到一个bi应用上,安装oracle biee的时候,乙方在创建表空间时,用了nologing参数,他的本意是否就是为了在该表空间减少redo的写入,从而达到快速插入数据的目的?
   可是这样的做法是否与rman冲突?另外dataguard的时候需要强制日志记录alter database force logging,这个配置是否会覆盖用户做的任何nologing配置?
   站在管理的角度,即使没有dataguard,实际工作中,是否也需要 force logging来避免上面说的问题?
   请唐SIR指点,我们在工作中对待这样的问题,正确的做法应该是怎么样的?


   这里rman出问题的场景是:0点做的备份,上午9点有人做了nologing,到了下午16点,要做不完全恢复到上午10点,是不是可能因为缺日志而失败?
   而同时,如果恢复到上午9点以前,是没有问题的吗?
   但如果整个tablespace都是nologging的,问题是否更严重,我们只能恢复到0点备份的那个时间点,除此任何时间都可能报错?
回复

使用道具 举报

640

主题

995

帖子

7333

积分

管理员

Rank: 9Rank: 9Rank: 9

积分
7333
发表于 2016-10-19 15:23:39 | 显示全部楼层
1. alter database force logging高于一切,不管用户怎么设置,都有日志。
2. 事后alter tablespace xxx nologging, 这东西不管用,实践中发现还有大量日志。(待证实)
3. 没日志恢复,rman 不会报错,而是出现逻辑坏块ora-1578和ora-1100等等。
4. 看一个会话产生多少日志,关联v$session  v$sesstat v$statname。
回复 支持 反对

使用道具 举报

80

主题

179

帖子

772

积分

高级会员

Rank: 4

积分
772
 楼主| 发表于 2016-10-20 09:11:47 | 显示全部楼层
本帖最后由 lujiaguai 于 2016-10-20 09:36 编辑

rman报告逻辑坏快的话,就会导致恢复失败吧?
我记得上课时逻辑坏快那个章节就是create tablespace nologging ,然后建表再高水位插入数据后出现的问题
当时的情况还是比较特殊的,append方式插入数据后,强行offline immediate掉表空间,这样再online的时候需要recover ,但是失败,出现逻辑坏快的报错
假设当时offline表空间的时候没有用immediate参数,那么再次online的时候就不会要求recover

我的理解是如果缺日志,recover时就会报错,如果当时那个实验不是去下线表空间,而是直接做不完全恢复,恢复的时间点再append 插入之后,restore后肯定要recover ,那么也会报错
就会导致不完全恢复失败。

能不能认为如果开发人员在导入数据的时候用了alter table nologging 并且用高水位加载append,导致redo日志缺失
或者干脆就是他建立表空间的时候 create tablespace nologging 然后再用append的方式做插入表的动作,就等于当初逻辑坏快试验的情况。

如果这个过程没有告知rman管理员的话,会导致意料外的恢复失败,那么是否可以认为这种管理运维模式整个有问题?
避免这类问题的办法就是管理员执行alter database force logging吗?
还是说实际工作中有其他的运维模式,管理上的或者技术上的可以避免这样的问题?


回复 支持 反对

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

QQ|手机版|Botang唐波's Oracle Station   

GMT+8, 2018-5-26 00:17 , Processed in 0.096920 second(s), 23 queries .

快速回复 返回顶部 返回列表