Series of articles written for DBA’s and developers who know Oracle and want to learn about NonStop SQL/MX. Useful for people who know NonStop, and would like to know about similarities and differences between the two products.

1. Concepts of NonStop SQL/MX
Introduction to catalogs and other objects
Technical white paper
Table of contents
Introduction ..................................................................................................................................2
Intended audience ....................................................................................................................2
Examples .................................................................................................................................2
Introduction to users and other database objects ..............................................................................2
Data structure and users.............................................................................................................2
System data objects ..................................................................................................................3
User data objects ......................................................................................................................3
Database object storage ............................................................................................................4
Example: Create table and alter table .........................................................................................4
Primary key constraints ..............................................................................................................7
Non-droppable primary key constraints .......................................................................................8
Conclusion ...................................................................................................................................8
References ...................................................................................................................................8

2. Introduction
When customers migrate Oracle applications to NonStop SQL/MX, DBAs with an Oracle background may feel a bit
lost, since both products have their specific solutions to common practices such as disk storage and user access. This
article is one in a series, inspired by the Oracle Database: Concepts 11g Release 2 manual, and tries to explain
some of those differences in implementation. Other articles will address other differences.
Intended audience
This article is written for DBAs and developers who know Oracle and want to learn about NonStop SQL/MX. It may
also be useful for people who know NonStop and would like to know about similarities and differences between the
two products.
Examples
In this article, the Oracle examples use the SQL*Plus command interface and the NonStop SQL/MX examples are
made using the mxci equivalent. The SQL*Plus commands are indicated by the “SQL>” prompt; those in mxci are
indicated by “>>”.
Introduction to users and other database objects
This concepts manual is downloadable from the Oracle Database Documentation Library at
http://www.oracle.com/pls/db112/homepage.
Data structure and users
Oracle and NonStop SQL/MX approach data structure organization in similar ways. Catalogs and schemas are
logical collections for data structures in NonStop SQL/MX, which follows the ANSI-92 naming scheme. Oracle omits
the ANSI catalog collection and defines its data structures only in schemas. Differences in naming and accessing data
structures, however, are significant.
In Oracle, the schema name has the same name as the database user who owns it. For example, the EMPLOYEES
table belonging to the HR user is called HR.EMPLOYEES. When one is logged into the database as user HR, the table
can be accessed simply as EMPLOYEES.
A NonStop SQL/MX catalog is created as a container for schemas; a schema contains a collection of database
objects like tables, views, and indexes. In SQL/MX, there is no relationship between the name of a schema and any
user name. There is no specific database user for SQL/MX; instead, NonStop operating system (OS) users can be
granted access to any table of any schema by the schema owner, who must also be an OS user with OS credentials.
A table in NonStop SQL/MX has a three-part name consisting of the catalog name, the schema name and the object
name, for example, ADMINS 1.HR.EMPLOYEE. Users Joe and Joan of the HR department must be granted access by
the schema owner before they can use the data contained in the table.
Users can set the default environment using the SET SCHEMA command as is shown in the mxci example below:
>>set schema admins.hr;
--- SQL operation complete.
>>
If no schema name is supplied, SQL/MX uses the OS group and user name to set a default. (The article “connecting
to the database” published earlier in this series describes this default in more detail.)
1
The reason the plural version of ADMIN is used is that the word ADMIN is a SQL/MX reserved word and cannot be used as an object name, unless it
is quoted with double quotes. Like “ADMIN”.
2

3. System data objects
System data is maintained by the DBMS software for its own purpose, and because of the different implementation
of object ownership and object storage, the NonStop approach to system data objects differs significantly from
that of Oracle.
Oracle automatically creates two administrative accounts and corresponding schemas when a database is created.
The SYS schema stores the base tables and views for the Oracle data dictionary. The SYSTEM schema contains
additional tables and views for administrative purposes.
In NonStop SQL/MX, a database is not created as a single entity; the operation that most resembles the creation of a
database is the creation of the first schema in an existing catalog. The CREATE CATALOG command only creates an
entry in the system’s metadata. However, when the first schema is created, SQL/MX creates a special schema called
“DEFINITION_SCHEMA_VERSION_3000 2”. This schema contains the base tables that hold the metadata for all the
schemas that belong to the catalog. Only a few system tables, for example those that contain statistics information
(HISTOGRAMS and HISTOGRAM_INTERVALS) are stored in the user schemas. More information about the contents
of the metadata and how to access it will appear in a future article in this series, “introduction to SQL/MX metadata”,
that will appear later in this series.
User data objects
Both Oracle and NonStop SQL store the business data in relational tables. NonStop SQL/MX implements a subset of
the object types that are available in Oracle. This list shows the common objects.
• Tables store data in rows. In SQL/MX, all tables are index-organized, that is, they are structured like an index and
the key is the primary or clustering key. Oracle supports different types of tables, such as heap structured and index
organized.
• Indexes provide fast access to table rows. They contain an entry for each indexed row of a table. NonStop
SQL/MX provides one type of index, a B-tree. Oracle provides multiple types such as B-tree, bit-mapped, and
function-based indexes.
• Partitions split tables and indexes into multiple parts. Both Oracle and NonStop SQL support range-partitioning and
hash-partitioning.
• Views. Normal views do not contain data; instead they provide a shorthand way to access one or more tables.
Both Oracle and NonStop SQL/MX have normal views. Oracle also has materialized views which are often used
in data warehousing. A materialized view is used to pre-compute and store aggregate data, such as the sum of
sales or the results of complex joins. Materialized views will be implemented in a later SQL/MX release.
• Stored procedures are pieces of code that can be called using SQL syntax. Oracle stored procedures are typically
written in Oracle’s own PL/SQL language, although Java is also supported. The objects are stored in the database
itself. NonStop SQL/MX stored procedures are written in Java. They are stored in the file system outside the
database, but references to the object as well as the procedure signature are stored in the schema metadata.
2
Version 3000 is the version number that is used for SQL/MX version 3.0 and higher. The previous versions used value 1200.
3

4. Database object storage
Oracle maintains a set of logical storage structures that are not known to the underlying operating system. In contrast,
NonStop SQL uses the operating system’s data structures (disk files) to store data. The NonStop OS knows about the
special status of these files 3 and will not allow access to the data outside the control of the DBMS.
The Oracle concepts manual provides a good overview of how logical tablespace structures—database objects that
contain Oracle tables and indexes—map to physical structures or data files.
For NonStop SQL, the organization is simpler: a table or index is stored in as many OS files as there are partitions. A
file consists of extents, a unit of contiguous space allocation, in which the data is stored in OS blocks, typically 4 or
32 Kbytes. The data is usually accessed in chunks the size of the data blocks, but large scans are performed in a
special mode of 56k blocks, called Bulk-IO.
Example: Create table and alter table
The commands to create and to alter a table are the same in both products. In fact even the syntax to create a simple
table is very similar. Below is an example, based on example 2-1 in the Oracle concepts manual. The only syntax
differences for this example are:
• NonStop SQL uses the keyword NUMERIC instead of NUMBER
• NonStop SQL does not use VARCHAR2, but uses VARCHAR
Example 1: Create table statement in Oracle syntax
CREATE TABLE CUSTOMER
( CUSTOMER_ID NUMBER (6)
, CUST_FIRST_NAME VARCHAR2(20)
, CUST_LAST_NAME VARCHAR2(25) CONSTRAINT LAST_NAME_C NOT NULL
, CUST_EMAIL VARCHAR2(50) CONSTRAINT EMAIL_C NOT NULL
, CUST_PHONE VARCHAR2(20)
, CUST_LIMIT NUMBER(8,2) CONSTRAINT LIMIT_C CHECK ( CUST_LIMIT < 100000)
, CONSTRAINT CUST_EMAIL_UC UNIQUE (CUST_EMAIL)
)
;
3
There are actually two OS files for a data object: a small file called the “resource fork” that contains metadata and one that contains the data itself,
called the “data fork”.
4

5. Not surprisingly, different defaults apply in Oracle and NonStop SQL/MX. The example below shows the actual
attributes after the table has been created in SQL/MX. The mxci showddl command shows how SQL/MX has applied
any default values and shows all the physical attributes of the table. The products differ most in the physical storage
attributes. Note that the full table name, including catalog and schema, all the constraints, the physical storage
locations and even the system-generated index are displayed.
Example 2: Complete definition of a table in NonStop SQL/MX
>>showddl customer;
CREATE TABLE FRANS.SAMPLES.CUSTOMER (
CUSTOMER_ID NUMERIC(6, 0) DEFAULT NULL
, CUST_FIRST_NAME VARCHAR(20) CHARACTER SET ISO88591 COLLATE DEFAULT DEFAULT
NULL
, CUST_LAST_NAME VARCHAR(25) CHARACTER SET ISO88591 COLLATE DEFAULT NO
DEFAULT -- NOT NULL NOT DROPPABLE
, CUST_EMAIL VARCHAR(50) CHARACTER SET ISO88591 COLLATE DEFAULT NO DEFAULT --
NOT NULL NOT DROPPABLE
, CUST_PHONE VARCHAR(20) CHARACTER SET ISO88591 COLLATE DEFAULT DEFAULT NULL
, CUST_LIMIT NUMERIC(8, 2) DEFAULT NULL
, CONSTRAINT FRANS.SAMPLES.CUSTOMER_451766711_4957 CHECK
(FRANS.SAMPLES.CUSTOMER.CUST_LAST_NAME IS NOT NULL AND
FRANS.SAMPLES.CUSTOMER.CUST_EMAIL IS NOT NULL) NOT DROPPABLE
)
LOCATION NSKIT11.$DATA01.ZSDFJ004.TL68GM00
NAME NSKIT11_DATA01_ZSDFJ004_TL68GM00
ATTRIBUTES BLOCKSIZE 4096
NO PARTITION
;
-- The following index is a system created index --
CREATE UNIQUE INDEX CUST_EMAIL_UC ON FRANS.SAMPLES.CUSTOMER (
CUST_EMAIL ASC
)
LOCATION NSKIT11.$DATA01.ZSDFJ004.GDMVHM00
NAME NSKIT11_DATA01_ZSDFJ004_GDMVHM00
ATTRIBUTES BLOCKSIZE 4096
;
ALTER TABLE FRANS.SAMPLES.CUSTOMER
ADD CONSTRAINT FRANS.SAMPLES.CUST_EMAIL_UC UNIQUE (CUST_EMAIL) DROPPABLE ;
ALTER TABLE FRANS.SAMPLES.CUSTOMER
ADD CONSTRAINT FRANS.SAMPLES.LIMIT_C CHECK (FRANS.SAMPLES.CUSTOMER.CUST_LIMIT
< 100000) DROPPABLE ;
--- SQL operation complete.
>>
5

6. The example also illustrates the use of the ALTER TABLE statement to add constraints. These ALTER statements were
generated automatically by the system based on the CREATE table syntax. The output of showddl also displays the
following important aspects of a SQL/MX table:
• The Oracle data type NUMBER (6) must be changed to SQL/MX data type NUMERIC (6), and this then defaults to
NUMERIC (6,0).
• By default, the NOT NULL constraint is a not-droppable constraint and is kept with the CREATE TABLE statement.
Columns that may contain NULL values have a two-byte NULL indicator column added.
• The LOCATION and NAME attributes are system generated values, but these can be specified explicitly to ease
system maintenance or, in the case of LOCATION, to enhance performance.
– LOCATION is the unique storage place in the cluster of NonStop servers and it consists of 4 parts:
 The Expand network name of the NonStop server that controls the storage device. The Expand product allows
the distribution of database data across geographically separated systems, up to 255 servers in a network.
This is transparent to the applications, which only refer to the tables by their ANSI table names as if all data is
local. Note the following:
o A single NonStop server is already a cluster of up to 16 nodes 4 that are virtualized by the NonStop OS
as a single system. These nodes provide the instant, in most cases transparent, take-over of work should a
node fail.
o The Expand network name is not the same thing as the hostname used in TCP/IP networks although they
could have the same value.
o The TCP/IP hostname is, in fact, the name of a cluster of up to 16 nodes.
 The Volume (disk) name on that NonStop server (7 characters).
 The Subvolume, a logical name of maximum 8 characters. This is defined when the schema is created and is
comparable to a directory name. The name can be generated by SQL/MX when the schema is created, or
the DBA can specify a meaningful name. The first three characters of the subvolume name must be “ZSD”. All
objects of a schema 5 are stored in the same subvolume, regardless of the volume they reside. This makes it
possible for a system manager to know the OS files that belong to a particular schema.
 The Filename is also an 8 character value. It must start with an alphabetic character, and the last 2 characters
must be “00”. Typically, DBAs will let SQL/MX generate this name; however, there is one good reason to
specify the file name manually: if the table is used as a backup table in a Business Continuity setting where
the NonStop Remote Database Facility (RDF) is used to synchronize data between multiple systems.
– NAME is a logical name for the physical location described above. It is used in some maintenance utilities such
as Backup/Restore2. DBAs often use it to contain the partition number, as in PARTITION_10 and
PARTITION_11.
• The physical block size of the table can be either 4k or 32k.
• The table in example 2 is not partitioned, as shown by the NO PARTITION attribute. For partitioned tables, the
partition details will be reported.
• The UNIQUE constraint on the CUST_EMAIL column causes SQL/MX to create a unique index automatically, if
there is not a suitable index on the table already. The index has LOCATION, NAME, BLOCKSIZE, and PARTITION
attributes just like the base table.
• Constraints are metadata objects only. However, as the unique constraint shows, they can use data objects
like an index.
4
NonStop servers are constructed using standard Intel® Itanium® servers or blades as building blocks. They are connected via an internal high-speed,
low-latency network, called ServerNet. For historical reasons, these nodes, when used in a NonStop server are often referred to as logical CPUs. See
the References section for reading tips.
5
NonStop SQL/MX stored procedure references also exist as files in the schema subvolume. However, the actual Java class files are stored in a
location that is defined by the DBA in the POSIX (OSS) file system.
6

7. Primary key constraints
Example 2-2 of the Oracle concepts manual shows how integrity constraints are added after the employee table has
been created. One of these constraints is the primary key constraint. Primary keys are used to uniquely identify rows
in a table, just like the UNIQUE constraint that was used in example 2. However, according to the ANSI rules, a
table can only have one primary key defined, and primary keys cannot contain NULL values.
Example 3: Oracle example of adding a primary key constraint
SQL> ALTER TABLE CUSTOMER
2 ADD ( CONSTRAINT CUSTID_PK PRIMARY KEY (CUSTOMER_ID)
….
Table rows are internally accessed by Rowids in Oracle, but NonStop SQL/MX accesses them by their primary keys.
This is why every SQL/MX table has a primary key. If no primary key is explicitly defined, SQL/MX adds a system
generated key, called the SYSKEY, which uniquely identifies the row in the table. The SYSKEY can be explicitly
requested by its name in a SQL statement but is otherwise invisible to the application.
The preferred method for specifying the primary key of a NonStop SQL/MX table is to do it explicitly when the table
is created, rather than adding the constraint separately in an ALTER TABLE statement. A single column primary key
can be specified with the column definition, like this:
CUSTOMER_ID NUMERIC(6) NOT NULL PRIMARY KEY
If the primary key consists of multiple columns, the PRIMARY KEY clause can be specified after the column definitions
as is shown in example 4. Note that the combination of last-name and first-name is normally not a good candidate for
a primary key.
Example 4: Multicolumn primary key when creating a table in NonStop SQL/MX
>>CREATE TABLE CUSTOMER
+>( CUSTOMER_ID NUMERIC (6)
+>, CUST_FIRST_NAME VARCHAR(20) NOT NULL
+>, CUST_LAST_NAME VARCHAR(25) NOT NULL
+>, CUST_EMAIL VARCHAR(50) NOT NULL
+>, CUST_PHONE VARCHAR(20)
+>, CUST_LIMIT NUMERIC(8,2) CHECK ( CUST_LIMIT < 100000)
+>, PRIMARY KEY (CUST_LAST_NAME, CUST_FIRST_NAME)
+>)
+>;
--- SQL operation complete.
>>
7

8. Non-droppable primary key constraints
The use of a non-droppable primary key constraint in NonStop SQL/MX, the default option, has some clear
advantages. Because all SQL/MX tables are index-organized, there will always be a B-tree index created inside of
the file. If the primary key cannot be dropped, NonStop SQL/MX will use the base table’s B-tree to store the primary
key values. The primary key can then be used as the storage key, sometimes referred to as the clustering key, and
that is the most efficient way of partitioning a table. In addition, these B-tree blocks can be used to scan tables across
multiple dimensions efficiently using a technique called Multi Dimensional Access Method (MDAM). However, if the
primary key can be dropped, the primary key constraint will be implemented using a separate index that uses the
system generated SYSKEY values to locate the underlying table rows. Note that, in this case, two B-trees (the primary
key index followed by the base-table’s B-tree) need to be accessed to locate the actual data.
Conclusion
This article introduced the NonStop SQL/MX catalog as an extra level to group schemas logically. Unlike Oracle,
there is no implicit relationship between a user and a schema in NonStop SQL/MX. Users are defined in the NonStop
OS and are granted access by the schema owner. The most common table attributes were introduced in this article,
as were the advantage of having non-droppable primary key constraints. The data objects can be distributed
transparently across a network of Expand-connected NonStop servers. The distributed nature of the NonStop
architecture is further discussed in the two HP documents that are listed in the References section. More discussions
about storage of data objects will be in a future article.
References
Oracle Database Concepts 11g Release 2 (11.2)
http://www.oracle.com/pls/db112/to_pdf?pathname=server.112/e16508.pdf
Clarifying HP NonStop server new terminology
http://h71028.www7.hp.com/ERC/downloads/4AA0-3158ENW.pdf
To know more about NonStop SQL/MX, visit www.hp.com/go/NonStop
© Copyright 2011 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. The
only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services.
Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or
omissions contained herein.
Intel Itanium is a trademark of Intel Corporation in the U.S. and other countries. Java and Oracle are registered trademarks of Oracle
and/or its affiliates.
4AA3-6541ENW, Created October 2011