Re: Is it just me
- From: J.Velikanovs@xxxxxxxx
- To: oracle-l@xxxxxxxxxxxxx
- Date: Thu, 12 Aug 2004 16:43:45 +0300
We have one customer who implemented few years ago auditing using AQ, like
Carel-Jan Engel described. They have one auditing table and auditing
stream realized thought AQ.
At the moment, after some time in production, client is VARY unhappy with
this solution.
.
Particularly with tow things:
1. Maintenance of AQ administration overhead. One case for example: If for
some reason reader process of AQ stopped for while, then the AQ supported
table growing rapidly. After auditing process is up & running, WHM of AQ
table still height.The performance of auditing process is unacceptable.
They need to introduce production system unavailability for maintenance of
this table (lower HWM).
2. Serialization that is provided by this mechanism; overall auditing
performance not so good, as they would like.
.
Jurijs
On 12.08.2004 16:19:39 oracle-l-bounce wrote:
>Hi Lisa,
>Although you said you can't update to 10g yet, I just got a brainfart
>that _might_ be helpful in a 10g environment and can be adopted to 9i as
>well. I have not tested this, so I cannot go into detail about all
>consequences, but by chance I will elaborate on the idea some time in
>the future. Of course, I encourage anyone to do this testing and share
>the results.
>
>When enabling flashback, you are able to peek into old and new values of
>a column in the (near) past using flashback queries. The trigger for the
>logging can just push a message in a queue, containg the user involved,
>table, rowid and timestamp or SCN. The job handling the queue will
>retrieve old and new values using flashback, and write the proper audit
>trail info into the logtable. Of course one of the assumptions is that
>the serialization isn't moved from the insert in the logtable to the
>adding of the message to the queue. Furthermore, the savings on the
>inserts in the logtable have to outweigh the cost of the extra I/O
>involved with flashback, and the processing of the queue. The whole idea
>is just making the logging asynchronous, without risking the loss of
>information. AQ can be of great help doing that. I think that adding the
>extra info of columns and old/new values to the message might make this
>working for 9i as well. Of course I would only go this way when the
>logging becomes a bottleneck. When the system works fine, don't change
>it. I wouldn't encourage you to introduce more complexity, although I'm
>a director of a (small) Oracle consultancy company as well ;-).
>
>Just my $0.02.
>
>
>
>Best regards,
>
>Carel-Jan Engel
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Other related posts:
