Comments on: v$object_usage empty? http://www.oracloid.com/2006/05/vobject_usage-empty/ The Alex Gorbachev Oracle Blog Fri, 21 Nov 2008 23:06:01 +0000 http://wordpress.org/?v=2.5.1 By: Alex Gorbachev http://www.oracloid.com/2006/05/vobject_usage-empty/#comment-7 Alex Gorbachev Fri, 19 May 2006 23:51:00 +0000 http://blog.oracloid.com/?p=12#comment-7 Hi Lutz, Your logic is correct. But it's a good security practice to lock accounts that own the objects and use separate application accounts having minimal set of DML/SELECT privileges on the object. If account is locked than you cannot login as this user. Of course, being DBA everything is possible but it's a hassle. Especially, if database have several schema hosting the objects (very common in our environments) than you need to login as different user several time - again hassle. Anyway, even if rationale behind having V$OBJECT_USAGE is valid than is should be at least documented and the view better called V$USER_OBJECT_USAGE. Thanks for the hint. To generalize it - monitoring should be enabled for, at least, one full cycle of product life, be it day, week, or month. In addition, it's a good idea to get in touch with development team and find out why the index was created in the first place (well, might not always be possible :). Hi Lutz,

Your logic is correct. But it’s a good security practice to lock accounts that own the objects and use separate application accounts having minimal set of DML/SELECT privileges on the object. If account is locked than you cannot login as this user. Of course, being DBA everything is possible but it’s a hassle. Especially, if database have several schema hosting the objects (very common in our environments) than you need to login as different user several time - again hassle.

Anyway, even if rationale behind having V$OBJECT_USAGE is valid than is should be at least documented and the view better called V$USER_OBJECT_USAGE.

Thanks for the hint. To generalize it - monitoring should be enabled for, at least, one full cycle of product life, be it day, week, or month. In addition, it’s a good idea to get in touch with development team and find out why the index was created in the first place (well, might not always be possible :).

]]> By: lutz_hartmann http://www.oracloid.com/2006/05/vobject_usage-empty/#comment-6 lutz_hartmann Fri, 19 May 2006 17:54:00 +0000 http://blog.oracloid.com/?p=12#comment-6 Hi Alex, to my mind the question is: why do I monitor usage of indexes? The answer is: because I want to find out, if I have indexes which I do not need because they atre never ued by teh application and just consume loads of space on disk. Now who could be interested in this question => 1. the dba who wants to reclaim disk space 2. the dba who wants to get rid of indexes which slow down the performance because they need to be maintained. In both cases it is the dba and if she/he enables table monitoring he/she will be able to see the used indexes. On hint: do not drop an idex before the last report has been run. Maybe there is one report which is only run once a year or every n years which needs the index! Hi Alex,
to my mind the question is:
why do I monitor usage of indexes?
The answer is: because I want to find out, if I have indexes which I do not need because they atre never ued by teh application and just consume loads of space on disk.
Now who could be interested in this question =>
1. the dba who wants to reclaim disk space
2. the dba who wants to get rid of indexes which slow down the performance because they need to be maintained.

In both cases it is the dba and if she/he enables table monitoring he/she will be able to see the used indexes.

On hint:
do not drop an idex before the last report has been run. Maybe there is one report which is only run once a year or every n years which needs the index!

]]>