Honey, I Shrunk the Database! Why Is My Database Smaller after Migration?

In a recent migration, a customer noticed that the size of the database decreased dramatically after the import. The size of the data files went from 500 GB to only 300 GB. Data Pump didn’t report any errors. Nevertheless, the customer was afraid that data was lost during migration.

The customer asked:

Am I missing data?

Why Would a Database Shrink During Import?

First, the following applies to Data Pump imports. If you migrate with transportable tablespaces or Data Guard, things are different.

Fragmentation

If you perform a lot of DML on a table, it will become fragmented over time. A fragmented table will use much more space, because the database will only re-use a data block with free space, once the free space reaches a certain limit (PCTUSED). Often, this leads to blocks that are never filled and waste of space.

When you import, the database neatly packs all blocks, and the table is completed defragmented.

Depending on the nature of your DML statements, you can see a dramatic impact on space usage for a defragmented table.

Indexes

After importing the data, Data Pump rebuilds the indexes. In many cases, an index has some level of fragmentation, but a rebuild removes all that, resulting in a neatly packed and efficient index. Most often, an index rebuild ends up using less space.

PCTFREE

If you change PCTFREE for an existing object, it applies to new blocks only. The existing blocks are left untouched. Any space saving from the lower setting applies to new data blocks only.

However, during an import (or index rebuild) the database builds the object from scratch and applies the setting to all the blocks. Now, all blocks have the new settings.

Connor’s Words

Connor McDonald was part of the original conversation with the customer. He phrased it like this:

Create a 100 GB table, and a 1 GB table. Your database is now (at least) 101 GB. Drop the 100 GB table and do an export/import. You now have a 1 GB database.

How Can You Know No Data Is Lost?

If you can’t use the database’s size to indicate whether data is lost, what do you do?

We covered this in one of our webinars, Migrating Very Large Databases.

Can the Database Become Bigger?

The headline of this blog post is a reference to Honey, I shrunk the kids. The sequel is called Honey, I Blew Up the Kid.

Then, can the database become bigger as part of an import? Yes, it may.

  • If you move from a singlebyte character set to Unicode, then characters stored in your database may take up more space. In particular, LOBs now take up much more space.
  • PCTFREE setting of your segments may also cause them to increase in size. Opposite of the case above.

2 thoughts on “Honey, I Shrunk the Database! Why Is My Database Smaller after Migration?

  1. “If you move from a singlebyte character set to Unicode, then characters stored in your database may take up more space.”

    It really depends – my experiences are from migrating from 8-Bit database character sets like WEISO8859P15 and somesuch: in this I have observed growth rates of between 1% and 5% of the original volume if using in-place migration using DMU. CLOBs or no CLOBS does not matter.

    Migrating into an AL32UTF8 database using datapump I often observed the effect you have described or the volume of the data migrated remained essentially unchanged.

    Except for LOBS in certain cases when using datapump – you wrote:

    “In particular, LOBs now take up much more space.”

    That I have observed in one case with an increase of storage by a factor of 5,5 to 6 IIRC.

    That happened when we imported a CLOB which was stored internally using the old UCS2 internal storage format and which was expanding it during datapump due to the conversion of the internal storage format of the CLOB segment in question to AL16UTF16. That was on a big-endian-environment (HP/UX).

    See: “CLOBs and NCLOBs character set storage in Oracle Release 8i, 9i, 10g and higher (Doc ID 257772.1)”

    The import was from Oracle 10.2 but the CLOB segment in question was created when the source database was 9.2 and during upgrades the LOB storage format of course does not get to be changed.

    Quite an unpleasant surprise at that time but we had enough spare storage on hand.

    Like

    1. Hi Christian,

      Thanks for your input. An increase in the range 5-6x does seem excessive, something else would be in play. Normally, you can see characters expand from 1 to 3 bytes (depending on the character), whereas LOBs take up min 3 byte pr. character.

      But interesting observation. Thanks for sharing.

      Daniel

      Like

Leave a reply to Daniel Overby Hansen Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.