Concepts of NonStop SQL/MXIntroduction to catalogs and other objectsTechnical white paperTable of contentsIntroduction ......
Introduction    When customers migrate Oracle applications to NonStop SQL/MX, DBAs with an Oracle background may feel a bi...
System data objectsSystem data is maintained by the DBMS software for its own purpose, and because of the different implem...
Database object storage    Oracle maintains a set of logical storage structures that are not known to the underlying opera...
Not surprisingly, different defaults apply in Oracle and NonStop SQL/MX. The example below shows the actualattributes afte...
The example also illustrates the use of the ALTER TABLE statement to add constraints. These ALTER statements were    gener...
Primary key constraintsExample 2-2 of the Oracle concepts manual shows how integrity constraints are added after the emplo...
Non-droppable primary key constraints                              The use of a non-droppable primary key constraint in No...
Nächste SlideShare
Wird geladen in …5
×

Concepts of NonStop SQL/MX: Part 2 - Introduction to catalogs and other objects

1.432 Aufrufe
1.307 Aufrufe

Veröffentlicht am

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.

Veröffentlicht in: Technologie
0 Kommentare
1 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

Keine Downloads
Aufrufe
Aufrufe insgesamt
1.432
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
11
Aktionen
Geteilt
0
Downloads
54
Kommentare
0
Gefällt mir
1
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Concepts of NonStop SQL/MX: Part 2 - Introduction to catalogs and other objects

  1. 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. 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. 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 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 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 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. 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. 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_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. 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. 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 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 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_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. 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. 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

×