ORA-32771 and ORA-32772

Bigfile tablespaces were introduced, and this example was run, in Oracle 10. They have only one datafile. Usually, this will be very large, although this is not the case in the example below:

 

SQL> create bigfile tablespace andrew

  2  datafile '/tmp/andrew.dbf' size 10m

  3  /

 

Tablespace created.

 

SQL>

 

There are two ways to extend an ordinary tablespace. You can add an extra datafile or you can extend an existing datafile. You cannot add an extra datafile to a bigfile tablespace so, to avoid running out of space altogether, you should use them with file systems which can be dynamically extended. These can be created, for example, on an EMC Celerra. You can identify these tablespaces as follows:

 

SQL> l

  1  select bigfile from dba_tablespaces

  2* where tablespace_name = 'ANDREW'

SQL> /

 

BIGFILE

-------

YES

 

SQL>

 

If you try to add an extra file to a bigfile tablespace, you get the following error:

 

SQL> alter tablespace andrew

  2  add datafile '/tmp/one_file_too_many.dbf'

  3  size 10m

  4  /

alter tablespace andrew

*

ERROR at line 1:

ORA-32771: cannot add file to bigfile tablespace

 

SQL>

 

Bigfile tablespaces must be locally managed, they cannot be dictionary managed so, in the example below, you would replace extent management dictionary with extent management local:

 

SQL> l

  1  create bigfile tablespace fred

  2  extent management dictionary

  3* datafile '/tmp/fred.dbf' size 5m

SQL> /

create bigfile tablespace fred

*

ERROR at line 1:

ORA-32772: BIGFILE is invalid option for this type of

tablespace

 

SQL>

More...

ORA-03297

This example, which I tested in an Oracle 9 database, explains the cause of this error message. First create a 20 megabyte tablespace with 1 datafile. Put 2 tables in it, each with a single 9 megabyte extent:

SQL> create tablespace andrew
  2  datafile '/database/andrew.dbf'
  3  size 20m
  4  extent management dictionary
  5  /

Tablespace created.

SQL> create table tab1(col1 number)
  2  tablespace andrew
  3  storage (initial 9m)
  4  /

Table created.

SQL> create table tab2(col1 number)
  2  tablespace andrew
  3  storage (initial 9m)
  4  /

Table created.

SQL>

Next create a map of the tablespace. I wrote this SQL in 2002 but it still seems to work. Its output shows the two 9 megabyte tables at the start of the datafile and a 2 megabyte free area at the end:

SQL> select file_id, block_id, segment_name, bytes

  2  from dba_extents

  3  where tablespace_name = 'ANDREW'

  4  union

  5  select file_id, block_id, 'FREE', bytes

  6  from dba_free_space

  7  where tablespace_name = 'ANDREW'

  8  order by file_id, block_id

  9  /

   FILE_ID   BLOCK_ID SEGMENT_NAME         BYTES

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

        26          2 TAB1               9441280

        26       2307 TAB2               9441280

        26       4612 FREE               2084864

SQL>

Now drop the first table and redo the tablespace map. This shows a 9 megabyte free area at the start of the datafile where TAB1 used to be:

SQL> drop table tab1

  2  /

Table dropped.

SQL> select file_id, block_id, segment_name, bytes

  2  from dba_extents

  3  where tablespace_name = 'ANDREW'

  4  union

  5  select file_id, block_id, 'FREE', bytes

  6  from dba_free_space

  7  where tablespace_name = 'ANDREW'

  8  order by file_id, block_id

  9  /

   FILE_ID   BLOCK_ID SEGMENT_NAME         BYTES

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

        26          2 FREE               9441280

        26       2307 TAB2               9441280

        26       4612 FREE               2084864

SQL>

Try to resize the datafile to 10 megabytes as it now only contains a 9 megabyte table. This fails as it can only recoup space from the end of the datafile and TAB2 is there already:

SQL> alter database

  2  datafile '/cisdpt/ebedpt1/ebe_tables/andrew.dbf'

  3  resize 10m

  4  /

alter database

*

ERROR at line 1:

ORA-03297: file contains used data beyond requested

RESIZE value

SQL>

You need to do something to free up the space at the end of the  datafile. On this occasion you are in luck. If you move TAB2 within the tablespace, it will take up the space at the start of the datafile:

SQL> alter table tab2 move

  2  /

Table altered.

SQL>

Redo the tablespace map. This shows a large enough area of free space at the end of the datafile to allow it to be resized successfully:

SQL> select file_id, block_id, segment_name, bytes

  2  from dba_extents

  3  where tablespace_name = 'ANDREW'

  4  union

  5  select file_id, block_id, 'FREE', bytes

  6  from dba_free_space

  7  where tablespace_name = 'ANDREW'

  8  order by file_id, block_id

  9  /

   FILE_ID   BLOCK_ID SEGMENT_NAME         BYTES

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

        26          2 TAB2               9441280

        26       2307 FREE              11526144

SQL> alter database

  2  datafile '/cisdpt/ebedpt1/ebe_tables/andrew.dbf'

  3  resize 10m

  4  /

Database altered.

SQL>

Redo the tablespace map to show the effect of the resize:

SQL> select file_id, block_id, segment_name, bytes

  2  from dba_extents

  3  where tablespace_name = 'ANDREW'

  4  union

  5  select file_id, block_id, 'FREE', bytes

  6  from dba_free_space

  7  where tablespace_name = 'ANDREW'

  8  order by file_id, block_id

  9  /

   FILE_ID   BLOCK_ID SEGMENT_NAME         BYTES

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

        26          2 TAB2               9441280

        26       2307 FREE               1040384

SQL>

Finally, drop the tablespace:

SQL> drop tablespace andrew
  2  including contents and datafiles
  3  /

Tablespace dropped.

SQL>

And now for a history lesson. I started to use Oracle 7 in the late 1990s. I had a development server all to myself and would often use create controlfile to clone databases. On one occasion I made the datafiles smaller beforehand using the resize command shown above. This caused the create controlfile to fail with an actual file size of <num> is smaller than correct size of <num> blocks message. The only workaround I found was to return the files to their original size and try again. For a long time I thought I was doing something wrong but I eventually discovered that this problem was caused by bug 309181, which was apparently fixed in Oracle 7.3.3.