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

Managing an SQL/MX Distributed Database
HP NonStop SQL/MX Installation and Management Guide—544536-007
13-23
Dropping Distributed Objects
Dropping Distributed Objects
Before you can drop a distributed table, index, or view, all objects dependent on that
table and its metadata must be accessible.
For range-partitioned tables or indexes, use the MODIFY utility to drop empty partitions
on remote nodes. For hash-partitioned tables and indexes, use MODIFY to drop
nonempty partitions only.
Enhancing the Performance of a Distributed
Database
The performance issues of a distributed database encompass those of a local
database and also include:
•
Using Co-located Indexes in a Distributed Database on page 13-23
•
Using Remote Application Processes on page 13-23
These other issues, not covered in this manual, also affect performance of a distributed
database:
•
Network availability and use
•
Remote node availability
For additional information about enhancing performance, see Section 15, Enhancing
SQL/MX Database Performance.
Using Co-located Indexes in a Distributed Database
Co-locating indexes with their parent table is an effective way of using NonStop
SQL/MX to improve performance and allow for better data distribution, both in a
standalone and distributed environment.
For example, assume the EMPLOYEES table contains an EMPLNAME and
EMPLCITY column, and each employee resides in San Francisco, Chicago, or New
York City. The table is partitioned on the EMPLCITY column and each partition resides
on a different node (for example, \SF, \CHI, and \NYC). In addition, the EMPLOYEES
table has an index on the EMPLNAME column. This index can be partitioned on the
EMPLCITY column even though the indexing column is on the EMPLNAME column.
This way, all the San Francisco employees are stored on the \SF node and can be
retrieved efficiently by EMPLNAME.
For information about co-locating an index on the same disk volume as its underlying
table, see Using Co-located Indexes on page 15-17.
Using Remote Application Processes
When you use a network-distributed database, you often control whether remote data
is updated directly by a local application process or indirectly by an application process