The contents of the CentraSite Registry Repository are stored physically in an internal database. The internal database typically exists as a set of files on disk for persistent storage, together with a large memory cache during normal runtime operation.
The workings of the internal database are not revealed to end users by means of any user interface or API. Only the product administrator can access and maintain the internal database, using the techniques described in the following sections.
While the CentraSite Registry Repository is running, you can monitor the disk space and memory cache requirements of its internal database. Based on these values, you can optimize your installation for best use of memory and disk space.
To display the database activity information, use the following command:
inoadmin showactivity CentraSite
This displays the following items of information:
Item | Description |
---|---|
Bufferpool size | The total amount of memory available for caching database blocks. |
Current used bufferpool size | The amount of memory currently being used to store cached database blocks. |
Current number of Index blocks | The number of currently cached blocks from the Index part of the database. |
Current number of Data blocks | The number of currently cached blocks from the Data part of the database. |
Current number of Temp blocks | The number of currently cached blocks from the Temp part of the database. |
Number of buffer flushes |
The number of physical writes from the buffer pool to the disk that have occurred during the current CentraSite session. A buffer flush is the process whereby CentraSite copies the entire contents of the buffer pool to disk, then deletes the contents of the buffer pool. This frees up the buffer pool for subsequent logical I/O operations. |
Logical reads | The number of database read operations that accessed the buffer pool during the current CentraSite session. |
Physical reads | The number of database read operations that caused a physical disk access during the current CentraSite session. |
Bufferpool hit rate | The ratio of times that a read operation was satisfied from the buffer pool rather than from the disk during the current CentraSite session, expressed as a percentage. |
Current bufferpool hit rate |
The buffer pool hit rate, limited to the time period between the previous and current activation of the command "inoadmin showactivity CentraSite". |
Flush limit | The maximum amount of buffer pool space that can be in use before a buffer flush takes place. If this value is exceeded, an automatic buffer flush occurs. |
Modified pages in bufferpool | The ratio of modified pages to unmodified pages in the buffer pool, expressed as a percentage. |
Dynamic pool size |
The size of the dynamic pool. The dynamic pool is a separate cache area, not part of the main buffer pool, and is used as a work area for certain operations such as sort and search operations. The dynamic pool is shared across all users of the system. |
Current used dynamic pool size |
The amount of the dynamic pool currently in use. |
Maximum pool usage |
The high-water mark of the dynamic pool usage during the current session. |
Current number of space waiters |
The number of users/applications that are currently waiting for space allocation in the dynamic pool. |
Total number of space waiters |
The total number of users/applications that have waited for space allocation in the dynamic pool during the current session. |
You can display information about the physical disk requirements of CentraSite's internal database. The database consists of several components called spaces, and each database space is stored in its own physical file. There are several kinds of database space:
Database space | Description |
---|---|
Data |
Contains the data of the CentraSite Registry Repository. The file type of a data space is "2D0". An example of a file name is "AAB00001.2D0". |
Index |
Contains the indexes that CentraSite maintains for retrieving stored data. The file type of an index space is "2I0". An example of a file name is "AAB00001.2I0". |
Journal |
Contains information required for rolling back transactions. The file type of a journal space is "2J0". An example of a file name is "AAB00001.2J0". |
Log |
Contains a log of all database modifications that have occurred in the current CentraSite session. The file type of a log space is "2L0". An example of a file name is "AAB000010000000052.2L0". The name is composed of the filename of the database's data and index spaces (for example, "AAB00001"), followed by a sequence number. The sequence number is incremented by 1 for each new log space. |
Backup |
Contains a backup of the CentraSite Registry Repository. There is an initial backup The file type of a backup space is "2B0". An example of a file name is "AAB00001001334723430.2B0". The name is composed of the filename of the database's data and index spaces (for example, "AAB00001"), followed by an integer that represents the date and time when the backup was created. |
To display information about the database spaces, use the following command:
inoadmin listdbspaces CentraSite
For each database space, the following information is displayed:
The type of database space, e.g. Data, Index, Journal, Log or Backup. There can be several spaces of the same type.
The amount of disk storage that this database space uses.
The location of the database space in the file system and the name of the physical file that contains the database space.
To protect against accidental loss of data, we recommend you to take regular backups of the internal database in which CentraSite's registry and repository data is stored. When you make a backup, you copy the contents of the internal database to a file on the file system. At a later stage, you can retrieve the contents of a backup and restore them into the internal database.
When you create a backup, the backup file is stored by default in the predefined location for backups, but you can optionally specify a different backup location. See the section Locations for information about predefined locations.
Note:
During the installation of CentraSite, a backup of the initial
database state is automatically created, with a timestamp equal to the date and
time when you install the product. If you for any reason wish to restore the
database to its initial state, i.e., the state immediately after product
installation, you can use this backup.
To back up the internal database
Decide whether you want to create the backup in the default backup location or in a different location. See the section Locations for information about defining a default backup location.
If you want to create the backup in the default backup location, using the following command:
inoadmin backup CentraSite
If you want to create the backup in a location other than the default backup location, using the following command:
inoadmin backup CentraSite <Location>
where <Location> is the path where the backup will be created, for example:
inoadmin backup CentraSite C:\SoftwareAG\AnotherBackupLocation
The location you specify must exist already, otherwise the backup will not run.
When the backup completes, a status message is output on the command line, indicating the date and time when the backup was created. In addition, a backup key is displayed. The backup key is a unique identifier for the backup. If you wish to restore the backup at a later stage, you identify the backup using the backup key.
You can change the contents of CentraSite's internal database back to a previous state by restoring a backup. When you restore a backup, you completely replace the current contents of the database by the contents that existed when the backup was made.
Repository changes that are made between one backup and the subsequent backup are stored in session logs. When you restore from a backup, you can optionally choose to include or omit the data from the session logs.
As soon as the restore step successfully finishes, the repository is automatically started in standby mode. Then the recover step is started, in which all changes that were made since the last backup are reapplied from the session logs. Finally, the repository is shut down again. The restore function can only be used when the repository is inactive (stopped).
Note:
During the installation of CentraSite, a backup of the initial
repository state is automatically created, with a timestamp equal to the date
and time when you install the product. If you for any reason wish to restore
the repository to its initial state, i.e., the state immediately after product
installation, you can use this backup.
To restore the database from a backup
First make a backup of the current database, in case you decide to return to this database state at a later time.
If the CentraSite Registry Repository is running, stop it before continuing.
Decide which backup file you wish to use for the restore operation. You can show a list of all available backups and their backup keys (the unique identifiers for the backups) by using the command:
inoadmin listbackups CentraSite
Use a command of the following form to restore from the chosen backup:
inoadmin restore CentraSite <BackupKey> <RecoverOption>
Select the recover option that you want to use. If you do not specify a recover option, this has the same effect as using the option "recover all". The following recover options are available:
Option | Action |
---|---|
recover all |
The database will be restored to the state stored in the backup, and all session logs created since the backup are included. This is the default option. |
recover no |
The database will be restored to the state stored in the backup. No session log data will be processed. |
recover <UntilDateTime> |
All session logs created after the specified time and date are excluded from the recovery. The format of this field is: DD-MMM-YYYY:HH:MM:SS Note that the month is given as a 3-letter abbreviation, using the first 3 characters of the month's name. Example: 23-OCT-2012:16:52:30 |
recover | This has the same effect as "recover all". |
The following example restores the database from a backup whose backup key is "001334732430". All database changes that occurred after the backup was made, up to and including 11:30am on October 25, 2012, will also be retrieved from the session logs.
inoadmin restore CentraSite 001334732430 recover 25-OCT-2012:11:30:00
If you choose to restore a backup without full recovery by using the recovery option "no", and there are one or more backups that are more recent than the backup being restored, these more recent backups will be set to disabled.
If you choose to restore a backup without full recovery by using the option "recover <UntilDateTime>", and there are one or more backups that are more recent than the time specified by this option, these more recent backups will be set to disabled.
A disabled backup cannot be accessed any more from any of the CentraSite user interfaces, and in particular cannot be accessed for restore or recover operations. It is not displayed in the list of available backups.
Disabled backups remain on the backup location on your disk as long as there are older, non-disabled backups. If you delete all non-disabled backups that are older than a given disabled backup, CentraSite automatically deletes the disabled backup.
If you should wish to reactivate a disabled backup, please archive it using standard operating system functionality and contact your software supplier.
Under normal circumstances, a database backup that is created on one machine can only be restored to the same machine. However, as described in the section Moving a CentraSite Database to Another Location, a database backup that originated on one machine can be configured so that it can be restored onto another machine.
You can delete backups that are no longer required. Deleting a backup removes all of the backup spaces that are associated with it, but the associated session log information is not removed, since it may subsequently be required if the database has to be recovered.
To delete a backup
Identify the backup that you wish to delete. You can list the available backups and their backup keys using the command:
inoadmin listbackups CentraSite
Enter the following command:
inoadmin deletebackup CentraSite <BackupKey>
where <BackupKey> is the backup key of the backup you wish to delete.
Example:
inoadmin deletebackup CentraSite 001334732430
Note:
If, after you delete a backup, there are one or more disabled backups
older than the oldest remaining non-disabled backup, CentraSite automatically
deletes all of these older disabled backups. See the discussion on disabled
backups in the section Restoring the Database from
a Backup for more details.
Under certain circumstances you might wish to move a CentraSite database from an existing CentraSite installation into another CentraSite installation, either on the same machine or on a different machine. Examples of such situations are:
When resources for processing become insufficient.
In a disaster recovery scenario.
As part of a side-by-side product installation, whereby two versions of CentraSite can exist on the same machine.
Moving a CentraSite database to another machine is not supported in the following scenarios:
if the architectures of the source and the target machine is with different byte orders (big-endian versus little-endian)
if the source machine is a Unix system and the target machine is a Windows system.
If you are not sure whether moving a database is supported in your environment, contact a technical representative of Software AG.
The CentraSite registry/repository contains environment-dependent data. This data has to be adjusted to the new environment when the data is moved to another machine.
The CentraSite kit contains a command line script that allows you to create a new database from an existing backup and to modify the data to the needs of the new environment. On Windows, the script is MoveCentraSiteRR.cmd, and on UNIX the script is MoveCentraSiteRR.sh.
The steps performed by the script are:
Calculate database space sizes
Delete the existing CentraSite database
Create a new CentraSite database
Adjust the environment specific data
Create a new backup containing the modifications
The script is called with 3 parameters as follows:
MoveCentraSiteRR.cmd <BackupFilename> <Username> <Password>
The parameter <BackupFilename> is the name and path of the existing backup file. The script can only be run using the credentials of the predefined user "DefaultUser", so <Username> must be "DefaultUser" and <Password> must be the password of this user.
The script must be called from the bin\cfg location of the target CentraSite installation.
Important:
The contents of the backup file will overwrite the database of
the target CentraSite installation.
Example:
cd C:\SoftwareAG\CentraSite\bin\cfg MoveCentraSiteRR.cmd C:\temp\CS820test.2B0 DefaultUser PwdForDefUser
CentraSite uses certain default locations on disk to store information about the active CentraSite Registry Repository session and the backup environment. These locations are:
Location type | Purpose | Default path |
---|---|---|
temporary | The Temporary Working Location. This location contains temporary data that is required during normal database operation. | <CentraSiteInstallDir>\data |
backup | The Backup Location. This is the location where backup files are created by default. | <CentraSiteInstallDir>\data |
log |
The Log Location. This is the location where session log files are created by default. If the log archive location is defined (see next table entry), the log location holds only the most recent session log, and all other logs are stored in the log archive location. |
<CentraSiteInstallDir>\data |
archive |
The Log Archive Location. This is the location where all session logs other than the current session log are stored. If no log archive location is defined, all session log files are held in the log location (see previous table entry), regardless of whether they are the log file of the current session or a previous session. |
(no default defined) |
reserved | The Reserved Location. This location is used as an overflow area if the database's standard locations have filled up. | <CentraSiteInstallDir>\data |
The CentraSite installation procedure defines default paths for each of these location types. Depending on your storage requirements, you can change these defaults to use different or additional paths.
You can list the currently defined locations as follows:
To list the currently defined locations
Use the following command:
inoadmin showlocations CentraSite
You can change the currently defined path of a location as follows:
To change the currently defined path of a location
Use a command of the following form:
inoadmin setlocation CentraSite <LocationType> <path> [<path> ...]
where <LocationType> is one of the location types shown in the table above. The location can be assigned to more than one path. If several paths are defined, they are used in the order specified from left to right; when there is no more disk space available in a path, the next path is used.
If the path contains spaces or characters that the operating system treats as escape characters in the command line (for example, the backslash character "\" in Windows), you must enclose the path in quotes.
The path or paths you specify completely replace the previously specified path or paths. If you want to extend the current path specification with an additional path, you need to use the "inoadmin setlocation" command and specify both the existing path and the new path.
The following example sets the new default path for the Backup location to C:\backuploc1 and D:\backuploc2. This means that C:\backuploc1 will be used as long as there is available disk space; if it is full, then D:\backuploc2 will be used instead.
inoadmin setlocation CentraSite backup "C:\backuploc1 D:\backuploc2"
You can configure various properties of CentraSite's internal database. The available properties are:
Property | Description |
---|---|
buffer pool size |
This defines the size of the buffer pool that is used for storing intermediate results during normal processing. |
maximum transaction duration |
This defines the maximum time, in seconds, that a transaction is allowed to exist. |
non-activity timeout |
This defines the maximum time, in seconds, that a transaction is allowed to be inactive. |
XML work threads |
This defines the number of XML-processing threads that be active concurrently in the internal processing engine. |
XML maximum sessions |
This defines the maximum number of user sessions that CentraSite can process concurrently. |
number of backup generations |
The number of full backups that CentraSite will keep in parallel. When this number is exceeded, the oldest backup and the corresponding log spaces will be deleted. |
write_limit |
The amount of the modified buffer pool space that triggers a flush (disk write) of the modifications present in the buffer pool. The default for the buffer pool size is 60MB. If this property is set to 0, CentraSite will adjust the flush limit automatically. |
For each property, the following information is available:
minimum
The minimum allowed value that can be configured for this
property.
maximum
The maximum allowed value that can be configured for this property
current
The current value of the property.
type
The datatype of the property (string, numeric etc.).
unit
The unit of measurement for the property's value, e.g. megabytes or
seconds.
If you wish to examine or modify the database properties, you have the following possibilities:
Command | Description |
---|---|
inoadmin listproperties
CentraSite |
Show a list of all of the available database properties and their values. The information displayed includes (where appropriate) the property name, the maximum and minimum allowed values, the current value, the configured value, high water mark. |
inoadmin getproperty CentraSite
<PropertyName> |
Show the value of the given property. If the property name contains one or more spaces, enclose the name in quotes. |
inoadmin setproperty CentraSite
<PropertyName>
<PropertyValue> [no]restart |
Change the value of the given property to the given value. If the property name or property value contains one or more spaces, enclose the name or value in quotes. The changed value will take effect at the next restart of the CentraSite Registry Repository. You can cause an automatic restart by specifying "restart", otherwise specify "norestart". |
inoadmin setproperties CentraSite
<XMLInputFile> [no]restart |
Change the values of several properties to the values specified in
the supplied XML file. The XML file must use the same element structure as the
XML file created by the The changed values will take effect at the next restart of the CentraSite Registry Repository. You can cause an automatic restart by specifying "restart", otherwise specify "norestart". |
Within the CentraSite's internal database a considerable amount of data may be stored temporarily, e.g. log data that is purged regularly or metrics data stored by other webMethods sub systems. When such data is stored the space required for the database increases. However, after deleting such data the space allocated will remain. Although the allocated space is re-used when additional data of the same type is stored again, the administrator may prefer to reorganize the database in a way that unused space can be de-allocated.
The reorganize function uses a temporary backup to defragment the free space. Thus it is a pre-requisite that the space required for one CentraSite backup is available on the backup location. This temporary backup will be deleted when the reorganize function completes successfully.
To execute database reorganization, use the following command:
inoadmin reorganize CentraSite
The reorganize
command reduces the diskspace
by returning blocks no longer used to the file system.
To check the available free disk space, execute the following command:
inoadmin reorganize CentraSite evaluate
The evaluate
command returns the current amount of free disk space in the form INODSI1183: 161.84 MB empty data space found
.
Remember that for the reorganize
command, the database must be stopped beforehand and restarted afterwards as
execution of this command against an
active database will be denied. However, the database need not be stopped when using the evaluate
option.