Re: Weirdness with dba_tab_modifications

  • From: Ram Raman <veeeraman@xxxxxxxxx>
  • To: MAdams@xxxxxxxxxxxxxxxxxxx
  • Date: Wed, 7 Oct 2015 10:18:53 -0500

Could you be logged in as two different users/databases for those two
queries?

On Wed, Oct 7, 2015 at 9:56 AM, Matt Adams <MAdams@xxxxxxxxxxxxxxxxxxx>
wrote:

I’m investigating several foreign keys that do not appear to have
corresponding indexes on them. During the course of the investigation, I
started querying DBA_TAB_MODIFICATIONS.



First I ran the following:



SQL> select * from dba_tab_modifications where table_owner = 'HCSC_OWNER'
and table_name = 'BILL'

/

2

TABLE_OWNER TABLE_NAME

------------------------------ ------------------------------

PARTITION_NAME SUBPARTITION_NAME INSERTS

------------------------------ ------------------------------ ----------

UPDATES DELETES TIMESTAMP TRU DROP_SEGMENTS

---------- ---------- ----------- --- -------------

HCSC_OWNER BILL

139434

130149 15329 06-OCT-2015 NO 0





Now, since we have (supposedly) identical schemas for various reasons, I
wanted to see where else this table might exist and how busy they might be.



SQL> select * from dba_tab_modifications where table_name = 'BILL'

SQL> /



no rows selected



I don’t understand how the less restrictive query returns no rows.



When I switch both queries to use all_tab_modifications (rather than
dba_tab_modifications), I get expected results…1 row for fist query, and 16
rows for less restrictive query.

I’ve retyped the queries by hand several times, so I’m sure that I don’t
have some weird invisible control character in there.



Has anybody seen this before?



Matt Adams

madams@xxxxxxxxxxxxxxxxxxx



**** This communication may contain privileged and/or confidential
information. If you are not the intended recipient, you are hereby notified
that disclosing, copying, or distributing of the contents is strictly
prohibited. If you have received this message in error, please contact the
sender immediately and destroy any copies of this document. ****




--

Other related posts: