1.Concepts of NonStop SQL/MXIntroduction to catalogs and other objectsTechnical white paperTable of contentsIntroduction ..................................................................................................................................2 Intended audience ....................................................................................................................2 Examples .................................................................................................................................2Introduction 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 .......................................................................................8Conclusion ...................................................................................................................................8References ...................................................................................................................................8

2. IntroductionWhen customers migrate Oracle applications to NonStop SQL/MX, DBAs with an Oracle background may feel a bitlost, since both products have their specific solutions to common practices such as disk storage and user access. Thisarticle is one in a series, inspired by the Oracle Database: Concepts 11g Release 2 manual, and tries to explainsome of those differences in implementation. Other articles will address other differences.Intended audienceThis article is written for DBAs and developers who know Oracle and want to learn about NonStop SQL/MX. It mayalso be useful for people who know NonStop and would like to know about similarities and differences between thetwo products.ExamplesIn this article, the Oracle examples use the SQL*Plus command interface and the NonStop SQL/MX examples aremade using the mxci equivalent. The SQL*Plus commands are indicated by the SQL> prompt; those in mxci areindicated by >>.Introduction to users and other database objectsThis concepts manual is downloadable from the Oracle Database Documentation Library athttp://www.oracle.com/pls/db112/homepage.Data structure and usersOracle and NonStop SQL/MX approach data structure organization in similar ways. Catalogs and schemas arelogical collections for data structures in NonStop SQL/MX, which follows the ANSI-92 naming scheme. Oracle omitsthe ANSI catalog collection and defines its data structures only in schemas. Differences in naming and accessing datastructures, however, are significant.In Oracle, the schema name has the same name as the database user who owns it. For example, the EMPLOYEEStable belonging to the HR user is called HR.EMPLOYEES. When one is logged into the database as user HR, the tablecan be accessed simply as EMPLOYEES.A NonStop SQL/MX catalog is created as a container for schemas; a schema contains a collection of databaseobjects like tables, views, and indexes. In SQL/MX, there is no relationship between the name of a schema and anyuser name. There is no specific database user for SQL/MX; instead, NonStop operating system (OS) users can begranted 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 objectname, for example, ADMINS 1.HR.EMPLOYEE. Users Joe and Joan of the HR department must be granted access bythe 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 connectingto the database published earlier in this series describes this default in more detail.)1The 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 itis quoted with double quotes. Like ADMIN.2 3. System data objectsSystem data is maintained by the DBMS software for its own purpose, and because of the different implementationof object ownership and object storage, the NonStop approach to system data objects differs significantly fromthat 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 containsadditional 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 adatabase is the creation of the first schema in an existing catalog. The CREATE CATALOG command only creates anentry in the systems metadata. However, when the first schema is created, SQL/MX creates a special schema calledDEFINITION_SCHEMA_VERSION_3000 2. This schema contains the base tables that hold the metadata for all theschemas 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 contentsof 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 objectsBoth Oracle and NonStop SQL store the business data in relational tables. NonStop SQL/MX implements a subset ofthe 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 Oracles 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.2Version 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 storageOracle maintains a set of logical storage structures that are not known to the underlying operating system. In contrast,NonStop SQL uses the operating systems data structures (disk files) to store data. The NonStop OS knows about thespecial 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 structuresdatabase objects thatcontain Oracle tables and indexesmap 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. Afile consists of extents, a unit of contiguous space allocation, in which the data is stored in OS blocks, typically 4 or32 Kbytes. The data is usually accessed in chunks the size of the data blocks, but large scans are performed in aspecial mode of 56k blocks, called Bulk-IO.Example: Create table and alter tableThe commands to create and to alter a table are the same in both products. In fact even the syntax to create a simpletable is very similar. Below is an example, based on example 2-1 in the Oracle concepts manual. The only syntaxdifferences for this example are: NonStop SQL uses the keyword NUMERIC instead of NUMBER NonStop SQL does not use VARCHAR2, but uses VARCHARExample 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_EMAILVARCHAR2(50) CONSTRAINT EMAIL_C NOT NULL , CUST_PHONEVARCHAR2(20) , CUST_LIMITNUMBER(8,2) CONSTRAINT LIMIT_C CHECK ( CUST_LIMIT < 100000) , CONSTRAINT CUST_EMAIL_UC UNIQUE (CUST_EMAIL) ) ;3There 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 actualattributes after the table has been created in SQL/MX. The mxci showddl command shows how SQL/MX has appliedany default values and shows all the physical attributes of the table. The products differ most in the physical storageattributes. Note that the full table name, including catalog and schema, all the constraints, the physical storagelocations 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_NAMEVARCHAR(20) CHARACTER SET ISO88591 COLLATE DEFAULT DEFAULTNULL, CUST_LAST_NAME VARCHAR(25) CHARACTER SET ISO88591 COLLATE DEFAULT NODEFAULT -- NOT NULL NOT DROPPABLE, CUST_EMAILVARCHAR(50) CHARACTER SET ISO88591 COLLATE DEFAULT NO DEFAULT --NOT NULL NOT DROPPABLE, CUST_PHONEVARCHAR(20) CHARACTER SET ISO88591 COLLATE DEFAULT DEFAULT NULL, CUST_LIMITNUMERIC(8, 2) DEFAULT NULL, CONSTRAINT FRANS.SAMPLES.CUSTOMER_451766711_4957 CHECK(FRANS.SAMPLES.CUSTOMER.CUST_LAST_NAME IS NOT NULL ANDFRANS.SAMPLES.CUSTOMER.CUST_EMAIL IS NOT NULL) NOT DROPPABLE)LOCATION NSKIT11.$DATA01.ZSDFJ004.TL68GM00NAME NSKIT11_DATA01_ZSDFJ004_TL68GM00ATTRIBUTES BLOCKSIZE 4096NO 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.GDMVHM00NAME NSKIT11_DATA01_ZSDFJ004_GDMVHM00ATTRIBUTES BLOCKSIZE 4096;ALTER TABLE FRANS.SAMPLES.CUSTOMERADD CONSTRAINT FRANS.SAMPLES.CUST_EMAIL_UC UNIQUE (CUST_EMAIL) DROPPABLE ;ALTER TABLE FRANS.SAMPLES.CUSTOMERADD 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 weregenerated automatically by the system based on the CREATE table syntax. The output of showddl also displays thefollowing 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 allowsthe 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 islocal. Note the following:oA 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.oThe Expand network name is not the same thing as the hostname used in TCP/IP networks although they could have the same value.oThe 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 iscomparable to a directory name. The name can be generated by SQL/MX when the schema is created, orthe DBA can specify a meaningful name. The first three characters of the subvolume name must be ZSD. Allobjects of a schema 5 are stored in the same subvolume, regardless of the volume they reside. This makes itpossible 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 charactersmust be 00. Typically, DBAs will let SQL/MX generate this name; however, there is one good reason tospecify the file name manually: if the table is used as a backup table in a Business Continuity setting wherethe 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.4NonStop 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. Seethe References section for reading tips.5NonStop SQL/MX stored procedure references also exist as files in the schema subvolume. However, the actual Java class files are stored in alocation that is defined by the DBA in the POSIX (OSS) file system.6 7. Primary key constraintsExample 2-2 of the Oracle concepts manual shows how integrity constraints are added after the employee table hasbeen created. One of these constraints is the primary key constraint. Primary keys are used to uniquely identify rowsin a table, just like the UNIQUE constraint that was used in example 2. However, according to the ANSI rules, atable can only have one primary key defined, and primary keys cannot contain NULL values.Example 3: Oracle example of adding a primary key constraintSQL> ALTER TABLE CUSTOMER2ADD ( 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 systemgenerated key, called the SYSKEY, which uniquely identifies the row in the table. The SYSKEY can be explicitlyrequested 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 tableis created, rather than adding the constraint separately in an ALTER TABLE statement. A single column primary keycan be specified with the column definition, like this:CUSTOMER_ID NUMERIC(6) NOT NULL PRIMARY KEYIf the primary key consists of multiple columns, the PRIMARY KEY clause can be specified after the column definitionsas is shown in example 4. Note that the combination of last-name and first-name is normally not a good candidate fora primary key.Example 4: Multicolumn primary key when creating a table in NonStop SQL/MX>>CREATE TABLE CUSTOMER+>( CUSTOMER_IDNUMERIC (6)+>, CUST_FIRST_NAME VARCHAR(20) NOT NULL+>, CUST_LAST_NAME VARCHAR(25) NOT NULL+>, CUST_EMAIL VARCHAR(50) NOT NULL+>, CUST_PHONEVARCHAR(20)+>, CUST_LIMITNUMERIC(8,2) CHECK ( CUST_LIMIT < 100000)+>, PRIMARY KEY (CUST_LAST_NAME, CUST_FIRST_NAME)+>)+>;--- SQL operation complete.>>7 8. Non-droppable primary key constraintsThe use of a non-droppable primary key constraint in NonStop SQL/MX, the default option, has some clearadvantages. Because all SQL/MX tables are index-organized, there will always be a B-tree index created inside ofthe file. If the primary key cannot be dropped, NonStop SQL/MX will use the base tables B-tree to store the primarykey values. The primary key can then be used as the storage key, sometimes referred to as the clustering key, andthat is the most efficient way of partitioning a table. In addition, these B-tree blocks can be used to scan tables acrossmultiple dimensions efficiently using a technique called Multi Dimensional Access Method (MDAM). However, if theprimary key can be dropped, the primary key constraint will be implemented using a separate index that uses thesystem generated SYSKEY values to locate the underlying table rows. Note that, in this case, two B-trees (the primarykey index followed by the base-tables B-tree) need to be accessed to locate the actual data.ConclusionThis 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 NonStopOS 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 distributedtransparently across a network of Expand-connected NonStop servers. The distributed nature of the NonStoparchitecture is further discussed in the two HP documents that are listed in the References section. More discussionsabout storage of data objects will be in a future article.ReferencesOracle Database Concepts 11g Release 2 (11.2)http://www.oracle.com/pls/db112/to_pdf?pathname=server.112/e16508.pdfClarifying HP NonStop server new terminologyhttp://h71028.www7.hp.com/ERC/downloads/4AA0-3158ENW.pdfTo 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. Theonly 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 oromissions contained herein.Intel Itanium is a trademark of Intel Corporation in the U.S. and other countries. Java and Oracle are registered trademarks of Oracleand/or its affiliates.4AA3-6541ENW, Created October 2011