The original intent of the Database GUID is for Audit Enabled databases, all audit-enabled databases need unique DB Identifiers in order to find which instance of a database an auditable event occurred. This GUUID is also used with the keystore on TDE enabled databases. There's no requirement that the database has to be audit-enabled or encryption enabled to use this information.
While the Database GUID was added in OpenEdge 10.1x, since OpenEdge 11.x we ensure that every new database has a system-generated globally unique identifier (UUID or universally unique ID). There were some inconsistencies with this in OpenEdge 10, but they can always be explicitly re-generated (see below). This unique identifier of the current instance of the database is known as the GUID, or the DB Identifier, converted from a uniquely universal (UUID) value, which is a 16-byte optional value.
By definition, the
_db-detail table may hold from one to #n records. Its purpose is to track all of the database's identities, where each database identity is identified by a unique uuid, throughout its history. A new record is added to the
_db-detail table of a database any time a new GUID is generated for the database - one for each GUID that the database has had during its lifetime and the
_Db._Db-guid field is updated to the current value.
The following actions generate a new GUID for the database:Over time a single database can accumulate multiple database
_db-detail records depending on the actions that were taken throughout it's history.
1. PROUTIL -C enable auditingWhen the current _Db._db-guid is UNKNOWN, otherwise the existing guid is preserved.
2. PROUTIL -C auditload Loading an audit data storage database will copy the source database's
_db-detail records and add them to the long term storage
_db-detail table. Resulting in the audit data storage database accumulating all of the _db-detail records from all of the source databases.
3. Change auditing's record level data integrity key4. PROSTRCT repair
5. PROUTIL -C conv1011
6. PROUTIL -C enable encryption7. Data Administration toolAdmin - > Database Identification -> Database Identification Maintenance -> New DB Passkey/Identifier
8. PROCOPY or PRODB or PROREST -newinstanceThe
-newinstance parameter gives the database a new and unique identity by virtue of assigning it a new uuid, which places a copy in the
_db-detail table
A restore with -newinstance is invalid for a replication-enabled database. Error 15123
When an encrypted database is created with -newinstance, the restored database cannot be opened until the key store is rebound with PROUTIL EPOLICY MANAGE KEYSTORE REBIND
9. ABL statement "CREATE DATABASE ... NEW-INSTANCE".The ABL code that implements the GUI Data Dictionary / Data Admin dialog to create a new database uses the NEW-INSTANCE option when creating the database. A database created in this way contains two
_Db-detail records:
- One with the GUID of the empty database in the DLC and
- One with a new GUID created for the new database copy.
When New Instance is not selected, the Data Dictionary assigns the source database's DB Identifier to the copy.
When a new database is created by copying an existing database provided by OpenEdge (empty database, demo database, or Sports2000 database), the new database is assigned a new GUID database identifier, the same as when a new database is created through PROCOPY (or PRODB) DLC\empty.
The following actions do not create a new GUID:1. PROSTRCT unlock2. PROCOPY or PRODB or PROREST without the -newinstance parameter Which Database GUUID is the current one?There is only ever one active DB GUID which can be viewed in the _Db._Db-guid table of the database.
FIND FIRST _Db NO-LOCK.
DISPLAY _Db._Db-guid.
The
_DB-Detail table, contains a historic record of each database GUID, and provides additional information such as a description of the database for reporting purposes.
FOR EACH _DB-Detail:
DISPLAY _DB-Detail._Db-guid _DB-Detail._Db-description.
END.
Why are Database Identifiers kept? As mentioned previously, the original intent of the GUID is for Audit Enabled databases
- Audit trail records have a 'source database' field that identifies the identity of the database the record was recorded into. Thereby identifying the identity (by uuid) of the source when running reports on an audit data storage database.
- Auditing can be set to add a data integrity check on each audit record so that altered records can be singled out as corrupted. The key used for the data integrity check algorithm is tied to the database's identity (uuid). Accumulating the _db-detail records with the uuid and key allows those audit trail records to be verified for the lifetime of the audit trail.
How else can Database Identifiers be used?As mentioned previously, there's no requirement that the database has to be audit-enabled (or encryption enabled) to use this information. A more common use-case is in
Identifying Copied DatabasesBeing aware of what actions that may be taken against production to change the GUID, a database that was copied from production can be identified. Additionally, a new GUID for the copied instance can be generated.
There is no easy way to determine which of the GUID values are for the same database except by using the related fields:
- Through the structured use of the description field (_DB-Detail._Db-description) or
- Using the custom detail field (_Db-Detail._Db-custom-detail), or
- Reading the list of GUID values from the originating database if access to this database is available (or recording these in a database table).
