SQL/MX 3.2 Management Manual (H06.25+, J06.14+)

Local Autonomy
If a query requires data only from the node on which it executes, the query succeeds regardless
of the availability of remote nodes on which the query’s accessed objects have partitions. For
SQL/MX Release 3.x, query compilation and late name resolution of ANSI names require access
to the nodes on which the accessed objects’ definition schema exist.
For more information, see “Maintaining Local Autonomy in a Network for SQL/MX Release 3.x”
(page 271).
Naming Network Nodes
After an SQL/MX database node has been installed and initialized, do not attempt to change the
node name or number. The node name is recorded in the system metadata entries and is entered
in the file labels throughout the database. The node number is recorded in the file labels.
NOTE: Do not attempt to change the node name or node number. Choose node names and
numbers carefully so that you do not need to change them.
Naming SQL/MX Database Objects
SQL/MX database objects have location-independent ANSI names. The database objects themselves
are represented by Guardian files on disk. The correspondence between ANSI names and Guardian
file names is stored in SQL/MX metadata. NonStop SQL/MX resolves these ANSI names to the
corresponding underlying Guardian file names.
NOTE: For more information about naming SQL/MP database objects, including guidelines on
using DEFINEs for network objects names, see the SQL/MP Installation and Management Guide.
ANSI Names
SQL/MX database objects have three-part, location-independent ANSI names of the form
catalog.schema.object. Location independence means that there is no identification of the
node or volume on which an SQL/MX database object exists.
SQL/MX objects that reside on one node and are accessed from other nodes must be visible from
those other nodes. Use REGISTER CATALOG to register a catalog on remote nodes. The objects
of a catalog registered on a remote node are accessible from that node.
A location-independent ANSI name is not always unambiguous within a network. It is possible
and legitimate for each of two nodes in a network (\A and \B) to have a catalog with the same
name (for example, CATX). Each node can access its own catalog CATX and the database objects
in it by using location-independent ANSI names. However, node \A cannot access anything in
the catalog CATX on node \B, and vice versa.
Guardian Names
The Guardian files that represent SQL/MX database objects follow these naming rules:
• They reside in protected subvolumes with names that start with the letters ZSD. DP2 prevents
the creation of non-SQL/MX files in these subvolumes. The subvolume name is exactly eight
characters, except for the ZSD0 and ZSD1 subvolumes used for the system and MXCS schema,
which are four characters.
• The file name part of Guardian files that represent SQL/MX objects is exactly eight characters
and ends with the digits 00 or 01.
• All database objects in a schema are represented by Guardian files with identical subvolume
name parts, referred to as the schema subvolume. These files can occupy multiple volumes
distributed across nodes in an Expand network.
• Each schema has a schema subvolume name that starts with the letters ZSD. You can specify
subvolume and file names on certain statements, like CREATE TABLE. The file and subvolume
Managing a Network-Distributed SQL/MX Database 267