SQL/MX 2.x Installation and Management Guide (G06.24+, H06.03+)

Managing an SQL/MX Distributed Database
HP NonStop SQL/MX Installation and Management Guide—523723-004
13-24
Changing Network Environments
change, and the needs of the node with respect to the database or application can
change.
Many of these changes do not affect the SQL/MX database or environment and need
not concern you if you are a system manager. Certain changes, however, can cause
problems or affect the SQL/MX environment and should be anticipated.
Consider these changes on a case-by-case basis:
•
A new node is added to the network. This addition does not affect the existing
database scheme. To access this node and incorporate it into the overall
environment, however, network passwords and security must be added to all other
nodes. Catalogs on existing nodes must be registered on the new node to make
the catalogs and their underlying objects visible to the node. After NonStop
SQL/MX is initialized on this node, register the catalogs from other nodes on the
new node, and then you can place new objects that you create in those catalogs
on this new node.
•
An existing node is permanently removed from the network. Move all object data
on this node to other nodes before dropping the objects and removing the node. If
the objects are table or index partitions, use the MODIFY utility to move the data to
another node before dropping the objects and removing the node.
•
A node needs to be renamed. Changing a node name can be difficult or impossible
to do because the node name is embedded in the file labels and stored in the
metadata.
•
The operating system at a node is updated. Usually nodes run compatible but
different operating systems. Consult the current software release documents for
compatibility issues between operating system releases. In some cases, upgrading
the operating system release imposes compatibility issues on the database. For
more information about versioning issues, see Versioning Issues on page 1-12.
•
Communication to a node is lost. Nodes can become unavailable for a variety of
reasons. For planned outages, you should systematically make inactive all network
transactions to the affected node before taking it offline. For unplanned outages,
transactions are rolled back by NonStop SQL/MX as errors and are reported as
communication problems. Sometimes, you might need to use one of the TMF
interfaces (for example, TMFCOM) to manually back out the transactions. After
communications are restored, transactions can resume and proceed normally.
•
Recovery takes place for a system crash on a single node. If a node crashes, it
can be recovered by using a TMF recovery method. HP recommends that you
initiate the START TMF, TRANSACTIONS OFF operation at the crashed node.
This approach enables TMF to resolve any network-distributed transactions active
at the time of the crash and to attempt volume recovery.
Keeping TRANSACTIONS OFF in effect during this procedure enables the function
to complete successfully, before new transactions are introduced to the database.
TMF does not allow new transactions to start before START TMF is completed
because new transactions require network transaction resolution and volume