Objectivity/DB Administration : Administration Tasks : Database Tasks
6 
Database Tasks
A database is the second highest level in the Objectivity/DB logical storage hierarchy, existing as a component of a federated database. Databases store application-created data organized in containers. Because a database is physically a separate file, you can use databases to distribute data across your network. Administering a database mainly involves updating its storage characteristics to help you better utilize your disk and network resources.
This chapter describes:
General information about databases.
Getting information about a database.
Creating a database
Deleting a database.
Setting access permissions on a database file.
Troubleshooting access problems.
About Databases
Logically, a database belongs to exactly one federated database, and contains one or more containers. Physically, a database exists as a file containing the binary representations of containers and the persistent objects in them. A database file contains only the representations of the embedded containers belonging to the database; any external containers are stored in separate container files. The location of each container is listed in the database’s catalog of containers.
Database Properties
A database’s properties specify its various logical and physical characteristics. The following properties describe a database’s logical identity:
The containing federated database—the federated database to which the database is attached and that serves as the point of administration for this database.
Database identifier—the unique integer identifier within the scope of the containing federated database.
System name—the unique logical name of the database within the scope of the containing federated database.
The following properties describe a database’s physical file location:
File host—the host machine on which the database file resides.
File path—the database file’s pathname and filename.
The following properties specify:
Whether the database is read-only or read/write.
The database’s storage-page size—the size (in bytes) of the storage pages in the database.
A database’s properties are set when it is created. You can view a database’s properties using Objectivity/DB administration tools; see Getting Database Information.
Database Identifier Formats
Many administration tools allow you to use a database identifier to specify a database. You find out a database’s identifier by listing file or property information for the database; see Getting Database Information.
A database identifier is usually a single, nonnegative integer—for example, 5. Database identifiers can also be represented as object identifiers written in D‑C‑P‑S format; see Referencing Objects in a Federated Database. For example, a database identifier of 5 is equivalent to an object identifier of 5‑0‑0‑0. You can use either format to specify a database to a tool.
Getting Database Information
You can get information about a database, including the current values of its properties.
To list properties of a database in a particular database file, run FileInfo followed by the -fileName option.
To list all databases and their properties, run DumpCatalog with the -bootFile option.
The following subsections provide more details about using Objectivity/DB tools to get specific information about a particular database.
Getting a System Name or Database Identifier
To get the system name or database identifier of a particular database:
If you know only the name of a database file, you can use FileInfo to find the database’s system name or identifier.
Getting a Database’s Storage-Page Size
To get the size of the storage pages in a particular database:
1. Get the database’s file path.
2. Using the database’s file path, run FileInfo.
Creating a Database
Databases are created automatically as needed. The need for a new database, as well as its storage location, is determined by the federated database’s placement model.
By default, new databases are created in the directory containing the federated database’s system-database file. You specify any nondefault storage locations for new databases by registering these locations in the federated database’s main storage group; see Chapter 4, “Specifying File Storage.”
Each newly created database and its storage location are recorded in the federated database’s global catalog.
Deleting a Database
You can delete a database from a federated database.
To delete a database:
Run DeleteDb with the ‑db or ‑id option and the -bootFile option.
Example This command deletes the database partsDb from the federated database myFD:
objy DeleteDb -db partsDb -bootFile myFD
 
Deleting a database deletes the database file, updates the federated database’s global catalog, and removes all bidirectional relationships (associations) and all unidirectional relationships (associations) to objects in other databases. The container files of any external containers belonging to the database are also deleted. Deleting a database automatically updates placement model’s internal map of placed objects.
Setting File Permissions on a Database
You can prevent unauthorized users from writing to or deleting a database 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 database:
The database file is missing or corrupted.
The federated database’s global catalog is incorrect or corrupted.
The access permissions on the database file are incorrect.
The database file’s data-server host is down.
The database is read-only, and the federated database contains other read-only databases that are currently being accessed. (A read-only database cannot be changed back to read/write if any other read-only database in the federation is currently being read.)
A workstation or network error can cause you to lose data. If you determine that the database file is missing or corrupted, restore the file from a backup. For troubleshooting access to an entire federated database, see Troubleshooting Federated-Database Problems.