DBCollect/Why: Difference between revisions

From Dirty Cache Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 3: Line 3:
= Why DBCollect =
= Why DBCollect =


* Why can't we just send some AWR reports? AWR reports are great but have a few problems and limitations for our purpose:
Q: Why can't we just send some AWR reports? AWR reports are great but have a few problems and limitations for our purpose:
** AWR only provides performance and limited configuration metrics. There is no database size/config information such as sizes of tablespaces, redo logs, temp files, segments, ASM disks/diskgroups, archive/flashback/bct files
 
** No OS configuration or hardware information (such as CPU type & model)
* AWR only provides performance and limited configuration metrics. There is no database size/config information such as sizes of tablespaces, redo logs, temp files, segments, ASM disks/diskgroups, archive/flashback/bct files
** No disk/network configuration
* No OS configuration or hardware information (such as CPU type & model)
** No UNIX SAR/sysstat performance data
* No disk/network configuration
** No compression, backup, archiving details
* No UNIX SAR/sysstat performance data
** AWRs are sometimes generated using non-English locale (cannot be parsed)
* No compression, backup, archiving details
** AWRs are sometimes generated in txt format instead of html (hard to parse, error-prone)
* AWRs are sometimes generated using non-English locale (cannot be parsed)
** AWRs are sometimes provided as RAC versions (completely different layout, hard to parse)
* AWRs are sometimes generated in txt format instead of html (hard to parse, error-prone)
** Usually only a few AWRs are provided, sometimes with a very large interval (many hours or even days) which is not detailed enough to do accurate sizings or performance analysis
* AWRs are sometimes provided as RAC versions (completely different layout, hard to parse)
** No way to know if there are other instances on the same system for which we need to know details
* Usually only a few AWRs are provided, sometimes with a very large interval (many hours or even days) which is not detailed enough to do accurate sizings or performance analysis
* No way to know if there are other instances on the same system for which we need to know details

Revision as of 07:22, 27 August 2025


Why DBCollect

Q: Why can't we just send some AWR reports? AWR reports are great but have a few problems and limitations for our purpose:

  • AWR only provides performance and limited configuration metrics. There is no database size/config information such as sizes of tablespaces, redo logs, temp files, segments, ASM disks/diskgroups, archive/flashback/bct files
  • No OS configuration or hardware information (such as CPU type & model)
  • No disk/network configuration
  • No UNIX SAR/sysstat performance data
  • No compression, backup, archiving details
  • AWRs are sometimes generated using non-English locale (cannot be parsed)
  • AWRs are sometimes generated in txt format instead of html (hard to parse, error-prone)
  • AWRs are sometimes provided as RAC versions (completely different layout, hard to parse)
  • Usually only a few AWRs are provided, sometimes with a very large interval (many hours or even days) which is not detailed enough to do accurate sizings or performance analysis
  • No way to know if there are other instances on the same system for which we need to know details