Vaults
A vault is a storage location residing in the underlying database that is defined by an ENOVIA Live Collaboration System Administrator for use by ENOVIA Live Collaboration. Vaults allow the designer of the ENOVIA Live Collaboration database to construct one or more logical storage locations within the database. The Business Administrator determines what the vault is for, while the System Administrator defines where the vault is located on the network. Vaults should use actual host and path names, not mounted directories. Paths must be exported on the host to all users
who require access to the vaults.
You must be a System Administrator to access vaults.
In addition to the business object vaults created by the System Administrator, a vault called the Administration vault that is created automatically when ENOVIA Live Collaboration is installed on your system. The Administration vault is used for administrative purposes only and serves as the master definition vault. The Administration vault is used for definitions only. You cannot use it for storing business objects. Vaults contain metadata (information about objects), while stores contain the application files associated with business objects. All vaults contain a complete set of ENOVIA Live Collaboration definitions. These definitions identify the characteristics of items such as persons, roles, types, formats, etc. When you make changes to a definition (such as add, modify, or delete), all definition copies must be updated to reflect the change. This update of the vaults occurs simultaneously if all the copies are available. If any of the copies are not available (a vault is not available), you cannot alter the definitions. This prevents partial alteration of the ENOVIA Live Collaboration definitions. For example, assume you want to add a new format definition. After you enter the Add Format command, ENOVIA Live Collaboration will attempt to add the definition. If the definition is valid (no errors), all copies of the ENOVIA Live Collaboration definitions are changed to include this new format. But assume that a vault resides on a host that is currently offline. In this case, no changes to the definitions are made. If changes were allowed, the one vault would not be updated to contain the change. Therefore, you should ensure that all defined vaults are available before modifying the ENOVIA Live Collaboration definitions.
Types of Vaults
There are four types of vaults:
- local
- remote
- foreign
- external.
- Most vaults are local.
- Remote vaults are used for loosely-coupled databases, which allow two entirely different ENOVIA Live Collaboration installations to share data.
- Foreign vaults are used with Adaplets, which allow data from virtually any source to be modeled as ENOVIA Live Collaboration objects.
- External (Web Service Adaplet) vaults are used with External stores that contain data maintained by external servers.
When defining a vault in MQL, you don’t need to specify which type it is. The system knows which type of vault you are defining by the parameters you specify for the vault.
- For local vaults, you define Oracle tablespaces using the Tablespace and Indexspace clauses.
- For remote vaults, you specify the server using the Server clause.
- For foreign vaults, you specify tablespaces, and Interface and Map fields (using the Interface and Map clauses).
- External vaults need only a parameters file.
Defining a Vault
Use the Add Vault command to define a vault:
add vault NAME [ADD_ITEM {ADD_ITEM}];
NAME is the name of the vault you are creating.
ADD_ITEM is an Add Vault clause that provides more information about the vault you are creating.
Printing a vault definition
print vault NAME;
If the NAME contains embedded spaces, use quotation marks
Delete Vault
delete vault NAME;
Clear Vault
The Clear Vault command is used to delete all business objects and associations in a vault:
clear vault NAME [minorrevision] [relationship] [full] [size NUMBER];
NAME is the name of the vault you want to clear.
NUMBER is the size of the transaction before a database commit. The Size clause only applies when any of the other optional clauses are included.
Once a Vault has been established and used, you should NOT use the Clear Vault command. In addition, you should not use it when users are online.
Minorrevision Clause
Include this clause before actually clearing the vault to have first remove the business objects in the named vault from revision chains of objects in other vaults. This involves modifying rows in the vaults lxBO table (marking rows that need to be cleaned up). Upon successful execution of this command, all revision chains that need adjustment prior to the clear vault command are fixed.
Relation Clause
Include this clause before actually clearing the vault to have ENOVIA Live Collaboration first disconnect business objects in the named vault from objects in other vaults. This involves modifying rows in the vaults lxRO table (marking rows that need to be cleaned up). Upon successful execution of this command, all connections to objects in other vaults are removed.
Full Clause
Include this clause before actually clearing the vault to have ENOVIA Live Collaboration first perform both a “clear vault relationship” and a “clear vault revision.” Additionally all tables of the vault are dropped and recreated, cleaning up the marked rows.
Size Clause
Include this clause of the clear vault command to indicate a transaction size before the relation or revision changes are committed to the database. For example, to remove all connections to or from objects in other vaults and commit the changes 100 at a time use the following:.
clear vault MyVault relation size 100;
When used without the Revision, Relation or Full clauses, the Size clause is ignored.
Index Vault
The index command should be used periodically after modification and deletions to clean up the database indices.
index vault NAME [table TABLE_NAME [indexspace TABLESPACE_NAME]];
NAME is the name of the vault to index. You can run the index vault command against any vault, including ADMINISTRATION.
Re-indexing vaults can improve find performance whether or not transaction boundaries have been used in the data loading process. If data is loaded from a sequentially sorted data file, the resulting index will be less than optimal. Re-indexing randomizes the index, making find performance noticeably better. Indexing a vault in this manner rebuilds the system indices that must be present for locating objects by name, type, and owner, as well as other SQL convertible fields.
To show the SQL commands for a particular index vault command, without actually changing the indices, use the validate index vault command as follows:.
validate index vault NAME [table TABLE_NAME [indexspace TABLESPACE_NAME]];
This is helpful to use on very large databases, where indexing a vault may take many hours. The validate output shows the SQL commands that need to be run. You could then manually run the commands in order, to make progress with minimal disruption.
Each clause is described below.
- Table Clause
Include this clause to indicate which database tables should be re-indexed. Only those columns that have indexing defined will be re-indexed. You should include up to and including the “_” in a table name, since what follows is specific to the vault specified. For example:
index vault "Engineering-1" table lxbo_;
This command might generate and execute SQL similar to:
alter index lxBO_abbe6b7a_lxOid_Index rebuild;
alter index lxBO_abbe6b7a_lxName_Index rebuild;
alter index lxBO_abbe6b7a_lxOwner_Index rebuild;
alter index lxBO_abbe6b7a_lxPolicy_Index rebuild;
The Engineering-1 vault is associated with the abbe6b7a table.
- Indexspace Clause
Use this clause to specify an alternate database tablespace to use for processing this command. For example:
index vault “Engineering-1” table lxbo_ indexspace USER_DATA;
This SQL generated is as follows:
alter index lxBO_abbe6b7a_lxOid_Index rebuild tablespace USER_DATA;
alter index lxBO_abbe6b7a_lxName_Index rebuild tablespace USER_DATA;
alter index lxBO_abbe6b7a_lxOwner_Index rebuild tablespace USER_DATA;
alter index lxBO_abbe6b7a_lxPolicy_Index rebuild tablespace USER_DATA;
alter index lxBO_abbe6b7a_lxState_Index rebuild tablespace USER_DATA;
This command adds indices to all columns of lxBO_ table (of the vault Engineering-1) that have indexing defined, and the command would use tablespace USER_DATA to hold the index data.
You must also include the table clause with using the indexspace clause.
Fixing Fragmented Vaults
As objects are deleted from a vault, storage gaps will occur in the vault database file. These gaps represent wasted disk space and can cause an increase in access time. MQL provides the tidy vault command to fix fragmentations in the database file of the vault.
tidy vault NAME [commit N];
NAME is the name of the vault you want to fix. You can specify the ADMINISTRATION vault to remove unused records of deleted administration objects.
When this command is executed, ENOVIA Live Collaboration consolidates the fragmented database file. It deletes rows in the database tables that are marked for deletion.
Commit N Clause
Include this clause when tidying large vaults. The number N that follows specifies that the command should commit the database transaction after this many objects have been tidied. The default is 1000. For example:tidy vault “Engineering” commit 200
The Commit N clause cannot be used for the ADMINISTRATION vault.
List of Vaults
A vault is a grouping of objects that depends on the types of objects used, the relationships they have to one another, and the people who need access to them.
The following code demonstrates how to get a list of vaults.
try{
getContext().connect();
VaultList list = Vault.getVaults(getContext());
_context.disconnect();
VaultItr itr = new VaultItr(list);
while(itr.next())
{
Vault vault = itr.obj();
System.out.println("vault: " + vault.getName());
}
getContext().disconnect();
}catch (MatrixException e){
// Can’t load vaults
}