Contents

What is a data container?

A data container is a live clone (i.e perfect replica) of a full database instance defined by the information stored in a data image. There is no limit to the amount of data containers that can be created from the same data image.

Data containers are live clones of a data image

From a single data image you can create as many data containers as you want, exact replicas with the same data, very quickly. This means that data containers are:

• Running instances of your data images.
• Fully functioning database servers that are no different in behaviour from any other database instance.
• Running clones of the original database instance stored in the data image if you will.
• Perpetually consuming resources (e.g. disk and memory).

In short, live database servers you will be able to connect to and use. When our Using the CLI returns connection details, it's the data container that you're working against.

Data containers are shallow copies

One important thing to note though is that data containers are tightly coupled with the parent data image and are in reality shallow copies of its original data, where only the file differences to the source data are stored on disk.

Some consequences arise from this:

• A data container cannot exist without its parent data image.
• A data image cannot be deleted if it has any active attached data containers.
• Any changes you make apply only to the data container, not to the parent data image.
• Data container creation time is a fixed-duration operation (a few seconds) that is not dependent on the size of the original database (i.e. creating a data container from a 5TB data image has roughly the same duration as from a 128MB one).
• The initial size of a data container is only a small fraction of the original database instance.
  • After creation though, data containers will continue to grow and the rate varies greatly depending on what you are doing with them (again, remember that only differences in relation to the parent database are stored to disk). For example, if you do a operation that causes a lot of modifications to the whole database instance (e.g. reindexing), then expect the data container to grow substantially and to consume much more disk space.
  • In some scenarios, the data container can substantially grow past the original data image size.
  • Also, the longer you let a data container live, the more storage it will claim over time (e.g. transaction logs being written to disk).

Because of all of this, data containers should be short lived (ideally with a lifetime of less than 1 week).

How do I create data containers?

The first step is creating a data image from a data image definition file. This is a relatively slow process, roughly equivalent to restoring a database, but this step will be performed relatively infrequently and can be automated, for example so that it runs overnight.

The second step is creating one or more data containers, from a data image. Creating each data container takes only seconds and can also be automated.

Data container properties

This section provides an overview of the data container properties that can be set during creation or later.

Name

Data container names can contain letters, digits, and -, _ and . special characters. The names are case sensitive, and have to include non-numeric characters (i.e., a name cannot be a number). A name cannot be longer than 63 characters.

When creating a data container it's optional to provide a name. If you don't specify a name, Redgate Clone automatically generates a unique name for the new data container.

Lifetime

If you specify a lifetime for a data container it will be automatically deleted after the time specified, in time duration format (number followed by a unit suffix. Valid units are "h", "m", "s").

If no value is provided, your data container will use the instance default data container lifetime.

Storage

Like data images, data containers are automatically stored in dedicated disks (block device volumes) attached to the cloning nodes in the cluster. Please see data storage for more information.