Query to find a tablespace is autoextensible r not

Question

Hi all,
Can you please help me with a query to get tablespace detail which are autoextensible.
Actually with the below query am able to get results but it is including datafiles that are not autoextensible for a particular tablespace. Therefore it is giving me two results for a particular tablespace. Help me.
SQL> select df.TABLESPACE_NAME,
2 round(((df.BYTES - fs.BYTES) / df.BYTES) * 100) usage_pct,
3 round(decode(df.MAXBYTES, 34359721984, 0, (df.BYTES - fs.BYTES) / df.MAXBYTES * 100)) max_pct,
4 df.AUTOEXTENSIBLE
5 from
6 (
7 select TABLESPACE_NAME,
8 sum(BYTES) BYTES,
9 AUTOEXTENSIBLE,
10 decode(AUTOEXTENSIBLE, 'YES', sum(MAXBYTES), sum(BYTES)) MAXBYTES
11 from dba_data_files
12 group by TABLESPACE_NAME,
13 AUTOEXTENSIBLE
14 )
15 df,
16 (
17 select TABLESPACE_NAME,
18 sum(BYTES) BYTES
19 from dba_free_space
20 group by TABLESPACE_NAME
21 )
22 fs
23 where df.TABLESPACE_NAME=fs.TABLESPACE_NAME
24 order by df.TABLESPACE_NAME asc
25 /
TABLESPACE_NAME USAGE_PCT MAX_PCT AUT
CORE_DATABASE_DATA 95 0 YES
CORE_DATABASE_DATA 96 96 NO
V2_DATA 100 0 YES
V2_DATA 100 100 NO
XDB 94 0 YES

Answer 1

1) What do you believe this query shows?
2) How do you define "bubble fragmentation" and "honeycomb fragmentation"?
3) Why (and when) do you believe a DBA would act to solve either problem?
4) Since your script is identifying tablespaces, how would you propose determining which objects in your estimation need to be rebuilt?
5) How have the answer to these questions changed since the move to locally managed tablespaces a decade ago?
Back in the old days of dictionary managed tablespaces, fragmentation was a real thing that DBAs had to keep track of because every table was potentially allocating differently sized extents in a tablespace, there were lots of odd extent sizes, and it was relatively easy to end up with free space in a data file that no object in the tablespace could ever use because it was smaller than the next extent size of the objects. That is no longer a concern with locally managed tablespace-- it is not (practically) possible to have (a reasonable quantity) of disk space that is free but unusable in a locally managed tablespace, particularly when you are using uniform extents.
Justin