| January 17, 2024
All About HCL DevOps Code ClearCase Semi-Live ReformatVOB (SLRV)
This blog post explores the details of the semi-live reformatVOB (SLRV) feature available in HCL DevOps Code ClearCase 3.0.1. It covers the following topics:
- Why use semi-live reformatVOB (SLRV)
- How standard reformatvob works — pictorial explanation
- How semi-live reformatVOB (SLRV) works — pictorial explanation
- Comparison of semi-live reformatVOB (SLRV) and standard reformatvob
Why use Semi-live reformatVOB (SLRV)
Here are some of the key benefits of using SLRV to reformat the VOB:
- SLRV offers a better solution for:
Updating VOBs to a new schema level
Performing database clean-up - It provides the ability to reformat VOBs with a much shorter lock time.
- In SLRV, the reformat dump and load process occurs in the background. This allows the normal end user's day-to-day activities to continue on the production VOB.
- SLRV can be completed when the team is ready to lock the VOB(s) and perform the final cutover process.
HOW STANDARD REFORMATVOB WORKS
Before getting into how the SLRV works, let’s take a quick look at how standard reformatvob works and what some of its key pain points are.
The following diagram represents a typical standard reformatvob operation being performed on a VOB.
- The db_dumper reads from the current schema and outputs data into a few text files.
- The db_loader reads those text files and writes data into the new schema.
- At the end of that process, directories are switched around and the new database with a new schema is available for use.
- The reformatvob process takes a considerable amount of time for large databases.
- Throughout this process, the VOB is locked and is therefore is not usable.
- In the UCM environments, if even a single component VOB is unavailable then all UCM operations are unavailable on that UCM project.
How Semi-live reformatVOB (SLRV) works
The semi-live reformatVOB process works in two stages:
Stage 1: Initiating the semi-live reformatVOB process
Stage 2: Completing the semi-live reformatVOB process
Stage 1: Initiating the semi-live reformatVOB process
In this first stage, the SLRV is started for a given VOB by issuing the command:
cleartool reformatvob -semilive <vob_stg_path>
The diagram below represents the tasks performed in this stage:
- The reformatvob -semilive operation silently upgrades that database to schema level 55 (if the original db is schema 54) or schema level 81 (if the original db is schema 80).
- The VOB is then locked.
- The existing database (just the VOB db directory) is copied to db.copy.
- The VOB is then unlocked.
- The copied database is dumped and loaded to db.semilive.
- The db_replay_server process is started to replay transactions from the current VOB db into the db.semilive copy of the database.
- End users can continue to work on the VOB, since the current VOB db is unlocked once the copy has been made (point 4). There is consequently no impact on end user operations.
- The db_replay_server process will keep replaying the new changes made in the VOB db to the new db.semilive in the background.
Stage 2: Completing the semi-live reformatVOB process
To complete the SLRV that is underway on the VOB, the admin runs the following SLRV complete command:
cleartool reformatvob -semilive -complete <vob_stg_path>
The diagram below represents the tasks performed in this stage after the SLRV complete command is issued:
- Once the “complete” command is issued, the VOB is once again locked to prevent any further changes by end users.
- A “complete” message is sent to the db_replay_server.
- The db_replay_server replays all outstanding transactions from the current VOB db to the “db.semilive” db copy and then exits.
- The current VOB db directory is renamed to “db.pre-semilive.
. ” for future backup and reference purposes. - The db.semilive with a schema 81 database is renamed to “db” and will act as the new upgraded db for the VOB.
- The VOB is unlocked and ready for use by end users, thus completing the SLRV operation.
The VOB has now been upgraded to the new schema.
Comparison between semi-live reformatVOB (SLRV) and standard reformatvob
The following table compares of the semi-live reformatVOB (SLRV) and standard reformatvob methods.
|
|
Comparison table |
|
|
Semi-live reformatVOB (SLRV) |
Standard reformatvob |
|
|
Efficiency |
The production VOB is unlocked as soon as the current VOB db is copied as db.copy |
The VOB remains locked throughout the reformatvob operation |
|
The db_dumper and db_loader act on the db.copy and not on the current VOB db |
The db_dumper and db_loader act on the actual VOB db itself; the VOB will thus remain locked until the complete reformatvob is done and the VOB remains unavailable to end users |
|
|
Impact on end user operations is minimized, since end users can start using the VOB again as soon as the copy is made |
Impact on end users is greater, since the VOB remains locked throughout the reformatvob operation |
|
|
The impact in terms of downtime on the UCM projects will be minimal |
If even one UCM component is undergoing standard reformatvob (including huge VOBs which take more time to complete), the whole UCM project will be unusable by end users until the reformatvob is complete |
|
|
Flexibility |
The admin has the flexibility to control the SLRV process and decide when to complete it, taking downtime and the impact on end users into account |
Once the reformatvob command is issued, there is no control or flexibility: the admin and end users must wait until the reformatvob command and process are complete |
|
The admin can initiate the SLRV and perform the SLRV complete step at any point in the future |
Once the standard reformatvob is started, it cannot be stopped or completed later to take downtime and impact on end users into account |
|
|
Operation |
The db_replay_server process is created by SLRV to sync the current VOB db changes to the db.semilive copy |
The db_replay_server process is not created in standard reformatvob process |
|
VOB describe output shows a line reading semilive reformatvob in progress: true, which helps in determining whether the VOB is undergoing an SLRV process |
There is no such option to determine whether a VOB is undergoing standard reformatvob |
|
|
cleartool reformatvob –semilive –status <vob_stg_pname> can be used to check the count of pending transactions on the VOB |
There is no such option in standard reformatvob; instead, the admin must rely on the dumping and loading messages seen in the reformatvob command output display |
|
|
Once the SLRV completes the original VOB, the db will be renamed to |
Standard reformatvob renames the old database to db.date for future backup and reference purposes |
|
Comment wrap
