AVEVA Global User Guide
Hub Administration : Changing the Hub Location
Changing the Hub Location
The user may sometimes need to change the Hub to a different location. The old Hub will become a Satellite. The Global database will be copied from the old Hub (where it will become a secondary database) to the new Hub (where it will become a primary database). Before changing a Hub location a suitable license should be in place on the new project Hub.
Note:
This is a command line operation only, as the user will have to re-enter ADMIN to display the correct version of the GUI at both the new Hub and the old Hub. It also provides protection from initiating this operation accidentally.
Global can handle and recover from communication failure when changing the Hub, but we recommend that the user take the following preliminary steps to minimise the risk:
•
Make sure that the daemon is running at both the current Hub and the Satellite which will become the new hub by selecting Query > Global Status > Communications or by issuing a Ping command. This can be achieved from the Admin, Model, Draw or Spool module.
•
Make sure the project at the original Hub is backed up and at least the Global database (prjglb) at the Satellites backed up.
The following illustrates the sequence of tasks:
1.
Make sure that all databases are allocated to the new Hub by using one of the Data > Database Allocation options. (This must include all transaction databases.)
2.
To synchronise the databases at the location that is about to become the new Hub, which can be done locally at the Satellite, or remotely from the current Hub. Refer to Synchronisation.
3.
Change the Hub location: display the command window, and enter the command:
hublocation loc
For example:
hublocation OXF
This process may take some time to complete. The name of the Hub location is changed in the Global database. The Global database becomes secondary at the old Hub and primary at the new Hub.
Note:
The change of Hub location cannot complete while there are administrators logged in at the old or new Hubs.
4.
Confirm that the Hub change has been successful by checking the HUBRF of /*GL attributes of the two locations. For example, if changing the Hub from London to Tokyo:
Navigate to /*GL at the old Hub and Query the HUBRF attribute
/*GL
  Q HUBRF
The HUBRF should be set to the name of the new Hub location, in this example, /Tokyo. (As a secondary effect, the LOCRF of /London should now be /Tokyo.)
Then navigate to /*GL at the new Hub and Query its HUBRF:
/*GL
  Q HUBRF
The HUBRF should also be set to the name of the new Hub: in this example, /Tokyo. (As a secondary effect, the LOCRF of /Tokyo should now be Nulref.)
In the event of failure, use the Data>Recover>Hub Location option which will be available at the original Hub location. Try again when communications have been restored. The Hub recovery option should be used with extreme caution, as otherwise it is possible to end up with two Hubs. If this happens, no other administration should be done until the situation is resolved. Refer to Running Global Projects for further information
Note:
Recovery of a hub location is normally done automatically if a hublocation operation fails - check the progress of the command in the transaction database. An explicit recover operation applied to a hub location Db should only be used as a last resort. It is normally only required when daemons are down or for offline locations. (Refer to Administrator Command Reference Manual (HUBLOCATION and RECOVER, commands)).
5.
Exit from ADMIN and re-enter. The GUI will be started as a Satellite.
6.
The allocation lists of secondary databases at the old Hub and locations on the communications network between the old and new Hubs need to be reviewed and any redundant databases de-allocated.
Output to the Global daemon windows will indicate whether the location is now the Hub or a Satellite.
1974 to current year. AVEVA Solutions Limited and its subsidiaries. All rights reserved.
AVEVA Logo