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/

  • 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 '19 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 '19 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 '19 at 0:34