DBCollect/Why: Difference between revisions

From Dirty Cache Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
 
(7 intermediate revisions by the same user not shown)
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:
Question: Why can't we just send some AWR reports?
** 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 reports are great but have a few problems and limitations for our purpose:
** No disk/network configuration
 
** No UNIX SAR/sysstat performance data
* We need AWR reports with a consistent format (HTML, single instance, correct timezone) and over a long period (default 10 days, with a standard 1-hour interval this results in about 240 AWR reports per database instance)
** No compression, backup, archiving details
* We need the AWRs for each database instance. DBCollect detects all instances automagically (in most cases). The alternative is to manually start SQL*Plus for each instance and generate all reports
** AWRs are sometimes generated using non-English locale (cannot be parsed)
* 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. DBCollect runs additional (SELECT) queries to get this additional database information
** AWRs are sometimes generated in txt format instead of html (hard to parse, error-prone)
* No OS configuration or hardware information (such as CPU type & model, memory, etc)
** AWRs are sometimes provided as RAC versions (completely different layout, hard to parse)
* No disk/network configuration
** 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 UNIX SAR/sysstat performance data
** No way to know if there are other instances on the same system for which we need to know details
* 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
 
= Security / Stability considerations =
 
* {{dbcollect}} does not modify database or OS data/files (except temporary files) and uses only SELECT statements
* It can be run as UNIX <code>nobody</code> and with a database read-only user (<code>DBSNMP</code>)
* There is some performance overhead for generating AWR reports - this can be managed using the <code>--tasks</code> option.
* No network connections are initiated. The workload data is stored on the host itself, in <code>/tmp</code>.
 
For more information, see [[DBCollect/Considerations]]

Latest revision as of 07:30, 27 August 2025


Why DBCollect

Question: Why can't we just send some AWR reports?

AWR reports are great but have a few problems and limitations for our purpose:

  • We need AWR reports with a consistent format (HTML, single instance, correct timezone) and over a long period (default 10 days, with a standard 1-hour interval this results in about 240 AWR reports per database instance)
  • We need the AWRs for each database instance. DBCollect detects all instances automagically (in most cases). The alternative is to manually start SQL*Plus for each instance and generate all reports
  • 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. DBCollect runs additional (SELECT) queries to get this additional database information
  • No OS configuration or hardware information (such as CPU type & model, memory, etc)
  • 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

Security / Stability considerations

  • dbcollect does not modify database or OS data/files (except temporary files) and uses only SELECT statements
  • It can be run as UNIX nobody and with a database read-only user (DBSNMP)
  • There is some performance overhead for generating AWR reports - this can be managed using the --tasks option.
  • No network connections are initiated. The workload data is stored on the host itself, in /tmp.

For more information, see DBCollect/Considerations