请教nologging的问题

lujiaguai

唐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点备份的那个时间点，除此任何时间都可能报错？

botang

1. alter database force logging高于一切，不管用户怎么设置，都有日志。
2. 事后alter tablespace xxx nologging， 这东西不管用，实践中发现还有大量日志。（待证实）
3. 没日志恢复，rman 不会报错，而是出现逻辑坏块ora-1578和ora-1100等等。
4. 看一个会话产生多少日志，关联v$session  v$sesstat v$statname。

lujiaguai

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吗?
还是说实际工作中有其他的运维模式，管理上的或者技术上的可以避免这样的问题？