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

• VERIFY obtains read-only locks on metadata while verifying an object. Other operations that
read metadata can run concurrently. Operations that change metadata or labels such as DDL,
partition management, PURGEDATA, and UPDATE STATISTICS statements cannot run
concurrently.
• To verify some objects, NonStop SQL/MX might need to access remote systems. In this case,
the remote systems must be available, and you must have privileges to view information on
them.
• If VERIFY tries to access objects on a remote system that were created on a schema version
later than the current system version, you receive a versioning error.
Using INFO to Display Guardian File Information
Use the mxtool INFO command to request specific SQL/MX information for a given Guardian
file name. NonStop SQL/MX automatically generates Guardian file names that are randomly
created. Use the INFO command to determine which Guardian file names belong to which ANSI
object, without writing complex queries against metadata. With INFO you can obtain this
information even if metadata is unavailable. In addition, you can use the MXCI SHOWLABEL
command to get more details for a specific Guardian file. For more information, see the SQL/MX
Reference Manual.
Guardian files have a set of DP2 labels attached to them that contain basic information, such as
file type, extent sizes, security, and timestamps. A separate entity, a resource fork, is attached to
an SQL/MX file. A resource fork contains additional information about an SQL/MX file, including
its associated ANSI name, ANSI namespace, versioning information, record structure, key structure,
partition maps, and so on.
INFO displays:
• The ANSI file name
• The ANSI namespace, including the table namespace (which includes views and stored
procedures), index namespace, and trigger namespace
• Versioning elements, including the object schema version
Using FIXUP to Correct Problem Data and Objects
NonStop SQL/MX stores information about object structures in metadata, resource forks, and DP2
file labels. DP2 file labels consist of file structure information and security settings. Resource forks
contain specific SQL/MX information that includes, among other things, the ANSI name, partition
maps, row and key information, and system metadata location. Metadata contains descriptions
of all objects in a database.
While performing database operations, information between metadata, DP2 labels, and resource
forks can become inconsistent. For example, a failed TMF transaction might leave a file in the
broken state, or a software bug might not set the redefinition timestamp correctly. When such an
inconsistency is detected, it must be fixed to guarantee proper execution of NonStop SQL/MX.
Options for repairing broken objects include:
• A label repair operation, which enables you to change a select group of file attributes for a
partition or an object. Use this option to get a system back and running without performing
an expensive restore or TMF recover operation.
• A metadata repair operation, which allows the super ID user to make explicit metadata changes
through UPDATE, DELETE, and INSERT statements on metadata tables issued from a licensed
MXCI process.
Recovering Consistent Files
When a disk volume or network node fails, files that are open at the time of failure are left in a
questionable state. In many cases, files are inconsistent because they were actively involved in
256 Performing Recovery Operations