I give you a very simplified vision that, however, can help you to understand how EV integrates with SQL.
Enterprise Vault creates the following SQL databases:
-
Vault store databases. A vault store database holds information about each item that is archived in the associated vault store (logical container).
-
Directory database. The Directory database holds Enterprise Vault configuration data for one or more Enterprise Vault sites (meta information).
-
Fingerprint databases. Each fingerprint database holds information about the single instance storage parts for a vault store group (single instance).
-
Monitoring database. This database holds the status information that the Enterprise Vault monitoring agents gather about the Enterprise Vault servers.
-
Auditing database. This database holds the data that the Enterprise Vault auditing mechanism gathers.
What basically Enterprise Vault does (for Exchange) is to archive exchange messages / calendar items, appointmets, etc, creating files in a propietary format (savesets).
Those saveset are compressed and contain the message plus an indexable/searchable version of the information. Once the saveset has been secured or just after archiving (depends on the configuration), the message in the Exchange Store it is replaced by a shortcut that tipically uses 4kb of storage (depending on the shortcut content policy), saving this way space in the primary Exchange storage.
After archiving the content it is serchable. Different policies can be applied to identify what to archive, and the information it is retained based on retention categories.
The savesets ARE NOT stored in the database, but in vault store partitions that can be NTFS shares, CIFS volumes, EMC Centera / Celerra devices, etc.
EV uses SQL intensively, but the result of the archiving (savesets) it is stored outside the database.
