RE: Table with data but not segment

From: Powell, Mark D <>
Date: Fri, 30 Jan 2009 12:14:23 -0500
Message-ID: <>

Also EXTERNAL tables appear in dba_tables but have no segment though the only EXTERNAL table defined on the system I checked does have tablespace_name value of SYSTEM instead of null like I expected.
  • Mark D Powell -- Phone (313) 592-5148

[] On Behalf Of Nigel Thomas

	Sent: Friday, January 30, 2009 11:51 AM
	Subject: Re: Table with data but not segment
	Copy to list
	2009/1/30 Nigel Thomas <>

		A table with no rows is still a table, so it has to be
stored somewhere.                  

                One or more tables in a heap cluster would not have their own segments (eg SYS.USER$ is stored in cluster C_USER# along with SYS.TSQ$). Unless the cluster name is the same as (one of) the table(s).                  

                A partitioned table has no segment (the partitions each have a segment). Of course one of the partition names may be the same as the table name (eg see SYS.LOGMNR_IND$ in the XE install).

                Regards Nigel                 

                2009/1/30 <>

                        I would like to clarify or confirm. I can query
(user_tables union

                        user_indexes) minus user_segments and see about 4 tables and 9 indexes.

                        7 turn out to be normal and 2 are IOT - TOP indexes.                         

                        I guess the 3 tables with 0 rows and all the indexes that go with them

                        might not have a segment?                         

                        There is one table with and IOT - TOP index with 100000 rows. Two

                        indexes go with this table, one of them is IOT - TOP, the other normal.                         

                        Even and Index has a segment, why would I not have a segment for

                        this(ese) table(s) or Indexes?                                                                                                    


Received on Fri Jan 30 2009 - 11:14:23 CST

Original text of this message