- 17.9K All Categories
- 3.4K Industry Applications
- 3.3K Intelligent Advisor
- 62 Insurance
- 536K On-Premises Infrastructure
- 138.2K Analytics Software
- 38.6K Application Development Software
- 5.7K Cloud Platform
- 109.4K Database Software
- 17.5K Enterprise Manager
- 8.8K Hardware
- 71.1K Infrastructure Software
- 105.2K Integration
- 41.5K Security Software
Change parameter _diag_adr_enabled to documented
ADR or Automatic Diagnostic Repository was considered a big improvement in database management when it came out in 11g. But over the years, real-life experience suggests that not many shops are using it as designed, for example, purging old trace files with adrci, packaging incident files with ips command (see 738732.1). When we create an SR, we don't package trace files with ADR. When we check database log or trace files, we read alert_<SID>.log or trc files.
On the other hand, ADR unnecessarily creates one trm file for EVERY trc file. This design completely ignores the frequently occurring situation in real life that the trace file directory could accumulate a large number of files quickly for various reasons including bugs; doubling the number of files in a directory makes certain commands run slow or cause inconvenience. Generating these trm files and log.xml for alert_<SID>.log and listener logs not only add space pressure, but also drag performance.
While there's a documented way to disable Oracle Net ADR (454927.1), the database ADR can only be disabled by setting _diag_adr_enabled. Since this is an undocumented parameter, purely for supportability reasons, we have to get Oracle Support's approval to change its value even if this is a trivial matter. It's time to make this parameter documented and let customers decide whether we want ADR or the traditional logging.