Kbase P107926: How to determine how much disk space is needed when auditing a database?
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
7/12/2010 |
|
Status: Verified
GOAL:
How to determine how much disk space is needed when auditing a database?
GOAL:
Formula to determine disk space requirements when auditing a database
FIX:
Estimating Disk Space Usage
By
OpenEdge Auditing Service
The OpenEdge auditing service is founded upon a highly configurable core that allows for application only auditing, raw database-record only auditing, or a mixture of both. The OpenEdge supplied configuration exists as a merging of one, or more, auditing policies that manage which optional audit records and fields of information is recorded. Note that all OpenEdge auditing records are optional, and that a number of fields in those records are also optional. The second major other factor in OpenEdge auditing is the application-level configuration that derives from auditing code-statements inserted into the application itself. This application configuration determines when, and how much, optional context information is added to the total record space used. Application context information adds definition to the raw record auditing for items such as what the application is, what type of operation is being performed, where in the application it is, and user login information.
With all of this application configurable auditing, the amount of space used and the overhead in recording information is almost totally in the hands of the application developer. For those developers, estimating disk space consumption for the OpenEdge auditing service is a process of analyzing their Progress application?s operations and applying that information to the auditing policy it implements.
OpenEdge auditing contains three record definitions:
· Audit data record ( in the _aud-audit-data table )
· Audit data value record ( in t.he _aud_audit-data-value table )
· Client login session ( in the _client-session table )
One audit data record is created when a configurable audit event occurs. None of these events are configured to record audit events in the default configuration. The size of these records is comprised of a set of fixed-size information fields, two variable length informational fields controlled by the application, and zero or more optional fixed length fields that are controlled by the application. The summary of configurable audit events is:
· Database record-change events:
· An audited OpenEdge database table record is created
· An audited OpenEdge database table record is updated
· An audited OpenEdge database table record is deleted
· Database schema changes (create, update, delete)
y: Symbol; mso-bidi-font-family: Symbol">· Application context events:
o An application-context code statement is executed
o An auditing-event-group code statement is executed
o An application defined auditing event code statement is executed
o An application user logs in or out
o An application connects or disconnects from an OpenEdge database
o The OpenEdge database application sets a new user-identity
· Miscellaneous events:
o /SPAN>An audited OpenEdge database utility is executed
o The effective run-time auditing policy is changed
An audit data value record is created each time a configured OpenEdge table field?s value changes. By default no table field are configured to be audited. The size of these records is comprised of a fixed size set of informational fields, with the remaining size being the actual new, and optionally old, table-field values.
A client login session record is recorded when an application user successfully logs into the application. It contains additional login details. None of these records is configured to be recorded in the default configuration. The size of these records is comprised of a few fixed-length informational fields and a number of variable length fields that hold application defined information.
The first step in estimating total audit space is analyzing the application?s total auditing configuration, including both OpenEdge database and application events.
The second step is determining the average size of an audit record that records OpenEdge database CREATE, UPDATE, and DELETE row-changes:
Fixed size of OpenEdge supplied data fields: ______104
Add the average size of a user account name: _________
Add the average size of the event context:
Average table name size . _______
Average primary key field names _______
Context size: _______ à _________
Add 22 if application-context is recorded by the application: _________
Add 22 if audit-event-groups are recorded by the application: _________
Add 22 if user-login sessions are used by the application: _________
Add 28 if record-level data integrity checks is configured: _________
DB audit record size: N>_________
The third step is determining the average size of an audit record that record events that are NOT an OpenEdge database CREATE, UPDATE, and DELETE row-changes:
Fixed size of OpenEdge supplied data fields: _______78
Add the average size of a user account name: _________
Add the average size of the application-defined event context: _________
Add the average size of the application-defined event detail information: _________
Add 22 if application-context is recorded by the application: _________
Add 22 if audit-event-groups are recorded by the application: _________
Add 22 if user-login sessions are used by the application: _________
Add 28 if record-level data integrity checks is configured: _________
&n.bsp; App audit record size: _________
The fourth step is to determine the average size of a database table-field value record if configured:
Fixed size of OpenEdge supplied data fields: _______26
Add the average table-field name as defined in the data dictionary: _________
Add the average old field value size in bytes if configured: _________
Add the average new field value size in bytes: _________
Add 28 if record-level data integrity checks is configured: _________
Field value size:: 1"> _________
The fifth step is to determine the average size of a client login session record, if configured:
Fixed size of OpenEdge supplied fields: _______52
Add the size of the client workstation name if configured: _________
Add the size of the application defined authentication system: _________
Add the size of the application defined authentication system type: _________
Add 28 if the user login operation is performed in an application server: _________
Add 28 if record-level data integrity checks is configured: _________
Login session size: _________
.The next step is to characterize the application?s operation by estimating average number of auditable database and application events that it will perform for a set period of time. Choose a time period that is relevant to your customer?s operations (hour, day, week, etc).
Estimate the number of record changes that are configured:
# of audited tables X # of CREATE,UPDATE,DELETE ops _________
Multiply by the average size of the database audit records (above) X _________
Total record changes: _________
Estimate the number of record-fields value changes that are configured: _________
Multiply by the average size of the field value change records (above) X _________
Total value changes: _________
Estimate the number of application context events that are configured: _________
GIN: 0in 0in 6pt">Multiply by the average size of the App event records (above) X _________
Total app events: _________
Estimate the number of user login session events that are configured: _________
Multiply by the average size of an login session event (above) X _________
Total login events: _________
The last step is to add all of the totals above:
Total record changes: _________
imes New Roman" size=3>Total value changes: _________
Total app events: _________
Total login events _________
Total events: _________
.