Is having Guardium configured for that database will help in getting the
details of the exact DDL query/source? Or it depends on what logging has
happened through the guardium there ? I see, the DBA's there are not aware
of how to fetch the guardium log/report so any information on that part
will be helpful.
Regards
Pap
On Mon, Jun 28, 2021 at 4:31 PM Andy Sayer <andysayer@xxxxxxxxx> wrote:
The additional logging is only going to be a problem if you have extremely
frequent DDL going on. If that is the case then you’ll find the problem
relatively soon and will be able to turn it off again afterwards. I would
be confident that any performance impact is going to be negligible.
Be on the lookout for truncate as well as drops.
The other option is to check the contents of dba_objects, it will have
last DDL times at both the table and partition level.
In order to work around it, you may find that you are able to rewrite the
failing query so that it is always only targeting specific partitions that
will not be dropped/truncated, although this could be tricky.
Hope that helps,
Andrew
On Mon, 28 Jun 2021 at 11:51, Pap <oracle.developer35@xxxxxxxxx> wrote:
This question came from a friend in a forum for version 19.9.0.0.0 of
oracle , stating, one of the SELECT query is failing with ora-08103 object
no longer exists error intermittently and rerun makes that query finish
without any error. And the query does have some partition tables used but
they aren't able to find any partition maintenance activities during this
period. But there must be some DDL happening and thus the SELECT query is
failing. And it might be that the DDL is too quick that it's not logged in
ASH/AWR views. So is there any method to get hold of the DDL statement and
its source ? I saw enabling DDL_LOGGING at the system level is one
approach, but thinking if it's having any negative sides if it's set at
system level for a long duration and if any other possible approach
exists?
Regards
Pap
