HOPEX Administration > Administrator Guide > Managing Repositories > GBMS Repositories > Checking and Physically Restoring a GBMS Repository
Checking and Physically Restoring a GBMS Repository
*A repository should be physically restored only in the event of system failure or to check that the backup is valid.
Checking a GBMS repository 
To facilitate the decision on repository reorganization, breakdown of volumes in the repository is presented during the check.
A repository check enables physical and logical verification of the repository on the main data storage file (.EMB extension). A repository check consists of:
• reading the file block by block
• checking the data
• checking all data indexing mechanisms contained in these data blocks.
As well as this physical integrity check, repository check gives a full technical report that can help the administrator decide whether or not to reorganize the repository to improve data access times (slow diagram loading, slow workspace opening, etc.).
To start the check:
1. Connect to HOPEX Administration and select the repository concerned.
2. Right-click the repository and select Check.
The Repository Check dialog box opens.
3. (Optional) Select the File option if you want to create a report file.
By default when you run a check at level:
• of a "Test" repository, the Testxxxx.txt file is generated in the Test folder (eg: MyEnvironment\db\test).
• of the "systemdb" system repository, the SystemDb0000.txt file is generated in the sysDb folder (eg: MyEnvironment\SysDb).
*No writing access should occur during this process.
*This repository check does not check private workspaces. It does not detect defective private workspaces.
4. Click Apply to start checks.
The report is displayed in the dialog box.
The following table explains the meaning of the different disk spaces used:
 
Type
Definition
Disk space occupied
Physical size of repository data file (.EMB).
Sum of the used, free, reserved and freeable space.
This space is not limited.
Disk space used
Disk space used by data limited to 4 GB.
Free disk space
Free disk space for consumption by progressive updates.
Freeable space by private workspaces
Space required for multi-user management and not
compressible while older private workspaces remain
Reserved space
Space temporarily reserved for updates without validation (generally zero).
From a physical standpoint, a repository is usually divided into four parts if it has never been reorganized:
• 80% usable space
• 10% or less free space
• 10% or less space that can be freed by private workspaces
• 0% preformatted space
*We recommend that you reorganize the repository when the space occupied by its logical backup represents less than 3 times the disk size occupied by the repository itself or when space used by the data represents less than 20% of disk size occupied.
For more information on repository reorganization, see Reorganizing an RDBMS Repository.
Physical restore 
A physical restore consists of copying previously saved repository files.
The following table shows different problems that may impact your repository. If any of these problems occur, you may have to restore your repository.
 
Cause
check
Problems of disk integrity
The following system tools can detect errors on your disk:
- Run the Scandisk utility if Dos > V6 or Win95
- Run the server utility if server disk
Server saturation (lack of space, disk controller failure)
- Consult the server log.
Other applications are also encountering errors.
Server disk controller is operating incorrectly
- Consult the server log.
Other applications are also encountering errors.
Restore the lock file only if restoring recent files.