Our production Enterprise GeoDatabase running on Oracle has been configured at the database level to force logging. ArcSDE DBTUNE defines many tables and indexes by default to be NOLOGGING for performance reasons. Is force logging not a good approach for geodatabases?

Some context : Our production database runs in archivelog mode. When we do a DB restore of our non-production database from RMAN backups of our production databases, these tables/indexes defined as NOLOGGING in DBTUNE run into block level corruption while the logs are applied after restore. The DBA recommends having force logging turned ON so we don't run into issues while applying the archive logs. Ref : https://chenguangblog.wordpress.com/tag/nologging/

Ref: https://resources.arcgis.com/en/help/main/10.1/index.html#/What_is_the_DBTUNE_table/002n0000001n000000/

closed as off-topic by Vince, LaughU, Fran Raga, whyzar, csk May 23 at 18:14

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions relating to general IT or with no clear GIS component, are off-topic here but can be researched/asked at Stack Overflow (software development), Super User (computing hardware and software), Database Administrators (relational databases) and other SE sites" – Vince, LaughU, Fran Raga, whyzar, csk
If this question can be reworded to fit the rules in the help center, please edit the question.

  • LOGGING is about database integrity, so the only place where Esri is going to specify NOLOGGING is where it can't do harm. Forcing the logging of objects which will never need recovery is a waste of CPU and disk. But this is more an Oracle topic than a GIS one. Or a philosophical discussion to have over a drink or three, not an answerable question. – Vince May 23 at 2:07
  • Thanks. But question is very simple, should we remove force logging for enterprise geodatabase. or should we consider ONLY force logging the schema / tablespace that contains data. ? Edited my question to give some context. please see above. – user3481432 May 23 at 2:55
  • Not once in 25 years of using Oracle did my customer experience block-level corruption due to NOLOGGING on EGDB feature classes. I think you may have a causality issue here, but it's better addressed with Tech Support. – Vince May 24 at 0:34