Objectivity/DB Administration : Administration Tasks : Container Tasks
Container Tasks
A container is the third level in the Objectivity/DB logical storage hierarchy, existing as a component of a database. Containers organize the data within a database. A container is physically stored either within a database file or in its own separate container file. Administering a container mainly involves updating the storage characteristics of container files to help you better utilize your disk and network resources.
This chapter describes:
General information about containers.
Getting information about an external container.
Creating a container.
Setting access permissions on a container file.
Troubleshooting access problems.
About Containers
Logically, a container belongs to exactly one database, and contains persistent objects. Physically, the binary representations of a container and its persistent objects are stored in one of two ways:
For an embedded container, these representations are stored within the file of the database to which the container belongs.
For an external container, these representations are stored in a separate container file.
Whereas every database is stored as a separate file, individual containers are designated as either embedded or external by the database designer. Normally, embedded containers are used, unless their aggregate size exceeds the practical capacity of a single database file. A database can have any combination of external containers and embedded containers to keep the database file size manageable.
Container Properties
A container’s properties specify its various physical and logical characteristics. The following properties describe a container’s logical identity, and apply to both embedded and external containers:
The containing database—the database to which the container belongs. The container and its properties are listed in this database’s catalog of containers.
Container identifier—the unique integer identifier within the scope of the containing database.
System name—unique logical name of the container within the scope of the containing database.
The following properties describe the physical container-file location of an external container:
File host—the host machine on which the container file resides.
File path—the container file’s pathname and filename.
The following properties specify the container’s:
Storage-page size—the size (in bytes) of the storage pages in the container. See Pages and the Objectivity/DB Cache. (An embedded container uses the same storage-page size as the containing database; an external container may have a different storage-page size.)
Note:A container is read/write if its containing database is read/write. If the containing database is read-only, so are all its containers, including any external containers.
A container’s properties are set when it is created.
Container Identifier Formats
Every container has a single, nonnegative integer identifier—for example, 5. In addition, every container is uniquely identified by an object identifier written in D‑C‑P‑S format; see Referencing Objects in a Federated Database.
In general, a container C in a database D has the object identifier D-C-1-1. For example, the object identifier 78‑5‑1‑1 identifies the container with the integer identifier 5 in the database with the integer identifier 78. Occasionally, the object identifier may be of the form DCP-1 or DCP-0, where the page number P is a low integer.
Getting Information About External Containers
To get information about external containers and their container files, use one of the following Objectivity/DB tools:
To list information about a particular container file, use FileInfo followed by the name of the file.
To get information about the external containers in all databases, use DumpCatalog followed by the -bootFile option specifying the federated database. Entries for the external containers belonging to a database are listed under the entry for the database.
Creating a Container
Containers are created automatically as needed to accommodate new persistent objects being created by an Objectivity/DB application.
The federated database’s placement model determines:
When a new container is needed.
The database in which to place the new container.
The properties of the new container, including whether it is embedded or external.
The storage location of the container file for an external container.
Setting File Permissions on a Container File
You can prevent unauthorized users from writing to or deleting a container file by using operating-system commands to set appropriate permissions on that file and, if necessary, the directory that contains it. Be sure to grant adequate permissions to the account(s) that run AMS or the lock server so that these servers can read and write all Objectivity/DB files.
Troubleshooting Access Problems
Any of the following conditions can prevent access to an individual container file:
The container file is missing or corrupted.
The database’s catalog of containers is incorrect or corrupted.
The container file protections are incorrect.
The container file’s data-server host is down.
The containing database is read-only.
A workstation or network error can cause you to lose data. If you determine that the container file is missing or corrupted, restore the file from a backup.
For troubleshooting access to an entire federated database, see Troubleshooting Federated-Database Problems.