IBM DB2 e-kit for Database Professionals

Learn how easy it is to get trained and certified for DB2 for Linux, UNIX, and Windows with the IBM DB2 e-kit for Database Professionals. Register now, and expand your skills portfolio, or extend your DBMS vendor support to include DB2. In an earlier developerWorks article we talked about how to leverage your MS SQL Server 2000 skills to learn DB2. Is your background in Oracle rather than SQL Server? If so, read on. In this article, we will show you how to use your current knowledge of Oracle 10g to quickly gain skills in DB2 9. On July 28 2006, IBM made available DB2 9 for Linux, UNIX, and Windows, a truly hybrid data server that meets today's rigorous business demands. DB2 9 is the only data server today to use pureXML technology that allows you to store XML natively, that is, internally in hierarchical format. Other features include row compression, label based access control (LBAC) security, and autonomic features such as the Self-tuning Memory Manager (STMM). This article starts with a comparison of DB2 and Oracle, and then focuses on introducing the new features available in DB2 9. Note: For the remainder of this article, we will use the term "Oracle" to refer to Oracle 10g Release 2 and "DB2" to refer to DB2 9 for Linux, UNIX, and Windows.

Back to top Overview of system structures To start out, we need to understand the architecture used by Oracle and how it compares with DB2. Figure 1 shows the system structure of Oracle. Compare it with Figure 2, which shows the system structure of DB2. Refer back to these figures for understanding as you read the article.

Figure 1. Oracle system structure on Linux, UNIX, and Windows Version 10.2

Figure 2. DB2 on Linux, UNIX, and Windows system structure

Back to top Instances The concept of an instance is similar in both Oracle and DB2. In both cases an instance is a combination of background processes and shared memory. The major difference between the two is that in Oracle there can only be one database per instance, while in DB2 multiple databases can share an instance. Because there is a one-to-one correspondence between database and instance, in Oracle you create an instance implicitly by creating a database with the CREATE DATABASE command. Alternatively, to create an Oracle instance on your machine you can use the Database Configuration Assistant, or you can use the ORADIM utility, available with Oracle 9i with the NEW option. You must also provide certain information including a System Identifier (SID) or a service name, instance password, maximum number of users, startup mode, and so on. Similarly, to delete the instance the ORADIM utility can be used with the DELETE option. You would need to pass in either the SID or the service name. There is no default instance created with a fresh install of Oracle unless you create a new database during the installation process. In DB2, after installing the product on the Windows platform, the instance "DB2" is created by default. In Linux and UNIX, the default instance name is called "db2inst1". To create another instance in the same machine, you simply execute the command db2icrt <instance name>. Figure 3 shows the default DB2 instance "DB2" (in Windows) and two other instances created with the db2icrt command from the DB2 Control Center GUI.

Figure 3. DB2 Control Center GUI showing DB2 instances

To reference a given DB2 instance from a command line interface, use the environment variable DB2INSTANCE. This variable lets you specify the current active instance to which all commands would apply. For example, if DB2INSTANCE is set to PROD, and then you issue the command create database MYDB1, you will create a database associated with instance PROD. If you wanted to create this database on instance DB2 instead, then you would first have to change the value of the DB2INSTANCE variable to DB2. This is similar to the ORACLE_SID (System Identifier) which is also used when users want to switch between instances.

Another easy way to identify the instance you want to work with is by using the DB2 Control Center GUI as shown in Figure 3. To see an entry for the new instance in this tool, you may have to add the instance to the GUI by right clicking on Instances and choosing Add. To drop an instance in DB2, you can execute the command db2idrop <instance name>. In summary, in Oracle the Database Configuration Assistant can be used to create, modify, start, stop and delete the instance, while in DB2 the Control Center GUI can be used for a similar purpose. Also an Oracle instance can only have a one-to-one relationship with a database, while in DB2 this is not the case. Multiple databases can exist and be concurrently used in a DB2 instance.

Back to top Databases In Oracle, a database can either be created manually using the CREATE DATABASE command or by using the Database Configuration Assistant. Creating the database manually requires that a series of steps be followed, including setting OS variables, preparing the parameter file, and creating a password file before the CREATE DATABASE command can be executed. Metadata information is stored and managed by the Data Dictionary, which is composed of base tables, and corresponding views. The base tables are created automatically during database creation, and the views are constructed by running the catalog.sql and catproc.sql scripts. The Oracle database is therefore seen as a collection of 3 file types: 1. Data File: Contains actual data, physical implementation of the database. (Similar to Containers in DB2) 2. Redo File: This is equivalent to Transaction Logs in DB2. 3. Control File: Contains information to maintain and verify database integrity. In DB2, an instance can contain several databases, as shown in Figure 2. Each database is a truly closed and independent unit. Each database has its own catalog table space, temporary table space, and user table space which are created by default upon successful database creation. DB2 does contain a binary file known as the system database directory that contains entries of all the databases you can connect from your DB2 machine. This directory is kept at the instance level. When an instance is created, no databases are created by default. You need to explicitly create a database using the create database command. You can also create a database using the Control Center as shown in Figures 4 and 5.

Figure 4. Creating a DB2 database using the Control Center GUI

Figure 5. Creating a DB2 database using the Control Center GUI (continued)

In Figure 5, you can also see what happens when you click Show Command. All DB2 Control Center GUI screens let you see the SQL statement or command that is actually executed in the background. These commands can be saved in scripts for execution at a later time, or can be

copied and executed from the Command Line Processor (CLP) tool or Command Center GUI tool. These tools are equivalent to Oracle's SQL*Plus and iSQL *Plus respectively. A DB2 database can be dropped by using the 'DROP DATABASE' command or from the DB2 Control Center GUI. In Oracle there is no such command; a database is deleted by deleting all the associated datafiles. Databases within an instance normally don't interact with each other. However, if your application needs to interact with more than one database, this requirement can be supported by enabling federation support. See the resources section for an article about federation.

Back to top Containers, table spaces, bufferpools and pages In Oracle, data is physically stored in files called Data Files. This is similar to DB2's containers where data is physically stored. Every Oracle database contains a table space named SYSTEM, which Oracle creates automatically when the database is created. Other table spaces for user, temporary and index data need to be created after the database has been created, and a user needs to be assigned to these table spaces before they can be used. In DB2, a table space is the logical object used as a layer between logical tables and physical containers. When you create a table space, you can associate it with a specific buffer pool (database cache) as well as to specific containers. This gives you flexibility in managing performance. For example, if you have a "hot" table, you can define it in its own table space associated with its own buffer pool. This helps ensure the data for this table is continuously cached in memory. In DB2 three default table spaces are created automatically upon database creation when using default values for the CREATE DATABASE command. Table 1 describes the default DB2 table spaces: Table 1. DB2 table spaces created by default when a database is created with default values Table space Description Name SYSCATSPACE Catalog table space containing metadata. System temporary table space used to perform operations such as joins and TEMPSPACE1 sorts. The name of this table space can be changed. This table space is optional and can be used to store user tables when a table USERSPACE1 space is not explicitly indicated at table creation time. Because databases in DB2 are independent units, table spaces are not shared across databases. Since they are only known within a database, two different databases can have table spaces of

the same name. You can see this in Figure 2 where database MYDB1 has a table space named MYTBLS and database MYDB2 has a table space of the same name. DB2 table spaces can be classified as SMS (system-managed spaces) or DMS (databasemanaged spaces). SMS table spaces are managed by the operating system and can only be directories. They grow automatically as needed; thus SMS provides good performance with minimum administration. DMS table spaces are managed by DB2, and can be files or raw devices. This type of table space allows for best performance, but some administration is required. For example, you need to specify ahead of time the amount of space you want to allocate for the table space, because growth is not automatic. Oracle does not have the SMS concept for its storage model but its data files are similar to DB2 DMS table spaces. That is, you can increase a database size by either adding a datafile to the table space, by increasing the size of the data file, or by adding a new table space. Table 2 below shows how Oracle databases or table spaces map to DB2 databases or table spaces. Table 2. How Oracle databases map to DB2 databases and table spaces Oracle database or table space SYSTEM is the table space that holds the catalog (Data Dictionary) information. Data Dictionary (contains metadata in form of tables and views) and resides inside the SYSTEM table space. SCOTT database TEMP table space UNDO table space USER table space DB2 database or table space SYSCATSPACE (catalog table space); as in Oracle, this information is kept only at the database level. System Catalog Tables (identified by the SYSIBM schema) and system views (identified by the SYSCAT OR SYSSTAT schema) and reside inside the SYSCATSPACE table space SAMPLE database System Temporary table space (By default it is called tempspace1) N/A User table space. By default, USERSPACE1 is normally created after database creation

As indicated earlier, Oracle's data buffer concept is equivalent to DB2's bufferpool; however, DB2 allows for multiple bufferpools to exist. There is no predefined number of bufferpools that you can create, and they can have any name. The concept of an Oracle block is most similar to DB2's page. A DB2 page can have a size of 4k, 8k, 16k or 32k. A table row must fit in only one page; it cannot span to other pages as in Oracle.

Back to top

Object names An Oracle object name takes the following form:

[Schema_name.]object_name[@database]

In DB2, objects also have a two-part structure:

Schema_name.object_name

As in Oracle, the DB2 schema name is used to group objects logically. An important difference, however, is that in DB2, a schema name does not have to match to a user id. Any user with a privilege called IMPLICIT_SCHEMA can create an object using a non-existing schema. For example, suppose that "Peter" has IMPLICIT_SCHEMA privilege and executes this command:
CREATE TABLE WORLD.TABLEA (lastname char(10))

In this case, the table WORLD.TABLEA is created, where WORLD is the newly created schema. If Peter had not explicitly indicated the schema, then the table PETER.TABLEA would have been created, because the connection ID is used by default. In DB2 you always connect to a database before issuing database specific commands; therefore, under this architecture, object names need not include the database name.

Back to top Tables, views, and indexes Tables, views and indexes are basically the same in both Oracle and DB2. DB2 provides a utility called Design Advisor which can be used to recommend indexes for a particular query or workload. The Design Advisor can be invoked from the DB2 Control Center or from the DB2 CLP using the db2advis command. In DB2, indexes are directly tied to the table definition. For example, when using DMS table spaces you can specify in which table space the indexes can reside as follows:
CREATE TABLE mytable (col1 integer, col2 char(10)) in tbls1 index in tbls2

The above example shows that the data for the table will be stored in table space 'tbls1', while the index pages will be stored in table space 'tbls2'. This is in contrast to Oracle syntax where the CREATE INDEX statement provides an option to specify in which table space the index will reside. Also, once an index has been created in DB2, you cannot alter any clause of the index definition. You would need to drop the index and create it again in order to implement changes.

As in Oracle, DB2 tables, views and indexes in different databases can have the same names. Tables and views within the same database must have distinct names, but creating an index with the same name as either an existing table or view is allowed.

Back to top Stored procedures, triggers and user-defined functions (UDFs) DB2 stored procedures can be written in any language supported by the DB2 precompilers, including Java, C, C++, REXX, Fortran, and COBOL. However, the recommended language to use is the SQL Procedural Language (SQL PL), which is fairly similar to Oracle's PL/SQL. SQL PL stored procedures are easy to create and have good performance. DB2 stored procedure development also supports SQLJ and Java using JDBC drivers type 2 and 4. Type 3 is discontinued. DB2 stored procedures can be written in any language supported by the DB2 precompilers, including Java, C, C++, REXX, Fortran, and COBOL. However, the recommended language to use is the SQL Procedural Language (SQL PL), which is fairly similar to Oracle's PL/SQL. A C compiler is needed to develop SQL PL stored procedures, as these are first translated into C. A C implementation of stored procedures may provide performance advantages because the code is compiled once (especially if run in unfenced mode); however, it also adds the requirement of having this compiler on the development system. In a future release of DB2, support for SQL PL stored procedures without the need of a C compiler is expected. DB2 stored procedure development also supports SQLJ and Java using JDBC drivers type 1 through 4. Development of triggers and functions can use inline SQL/PL, a subset of SQL PL. The DB2 Developer Workbench tool can be used to easily create, build, debug and deploy DB2 stored procedures and user-defined functions.

Back to top Configuration files Traditionally Oracle stores all session and system-related parameters in a text file, normally referred to as initSID.ora. However due to the non-persistent nature of this text file, starting from Oracle 9i, Oracle introduced Server Parameter File (SPFILE), which is a binary parameter file stored on the server. This persists across instance shutdown and startup. The initSID.ora file is still used, however, when an SPFILE is not available. Prior to the introduction of SPFILE, any ALTER SYSTEM and ALTER SESSION commands that affected parameters would only persist during that instance or that session. The DBA would have had to manually modify the initSID.ora text file whenever a rebound of a database instance was intended. Network access configurations are typically stored in listener.ora for listener and tnsnames.ora for client access.

With DB2, configuration parameters are also stored at the instance level, known as the database manager configuration file, and at the database level, known as the database configuration file. Most of these parameters can be changed dynamically, that is, there is no need to stop and restart the instance or force all connections before the change to the parameter value takes effect. If you would like to manually change a specific database manager parameter from the CLP, use the command UPDATE DBM CFG USING <parameter name> <new value>. If you would like to manually change a specific database parameter from the CLP, use the command UPDATE DB CFG FOR <database name> USING <parameter name> <new value>. These commands would be the equivalent to Oracle's ALTER SYSTEM and ALTER SESSION. Alternatively, using the Control Center, you can review and change values for these parameters; if you right click on a given instance and choose Configure Parameters, you will see the window shown in Figure 6.

Figure 6. DB2 Database Manager configuration parameters (instance level)

At the database level, right clicking on a given database, and choosing Configure Parameters displays the window shown in Figure 7.

Figure 7. Database configuration parameters (database level)

DB2 provides many parameters you can use to configure your system; however, if you would like an easy way to configure the system automatically, use the autoconfigure command (or the Configuration Advisor GUI) which sets the database manager and database configuration parameters to optimal values based on some information you provide. Figure 8 shows the Configuration Advisor.

Figure 8. - DB2 Configuration Advisor

In addition to configuration files, DB2 also uses DB2 Registry variables normally for platformspecific configurations. Note, the DB2 Registry variables have no relationship whatsoever to the Windows registry. Use the command db2set to review and change these variables. Connectivity (network access) information is stored in the System database directory, local database directory and node directory. These are binary files and can only be modified with the CATALOG and UNCATALOG commands.

Back to top Memory architecture and background processes Next we'll look at the memory architecture and background processes, and will compare and contrast the way they are used in Oracle and DB2.

Figure 9: Oracle memory architecture and background processes

The System Global Area (SGA) in Oracle is a group of shared memory areas that stores information for the instance. Examples include statement cache, redo log buffers, and data buffer cache. The Program Global Area (PGA) and the User Global Area (UGA) shared memory areas contain data and control information for server processes and user sessions. Oracle supports multiple instances within the same machine but background processes are not shared. For example, three instances in one machine will require three set of background processes. Therefore it is generally recommended to have one database, one instance and multiple schemas within the same machine.

Figure 10: DB2 Memory architecture and background processes

Both DB2 and Oracle use shared memory areas, but DB2's memory architecture is implemented in a slightly different way than Oracle's. Since a DB2 instance can contain more than one database, two levels of configuration exist. As we mentioned in the previous section, instance level configuration can be done in the DBM CFG file while the database level configuration is done in the DB CFG file. Configuration parameters at both levels can be adjusted to tune memory usage. The section below provides a bit more detail on DB2's memory structures and different background processes. Unlike Oracle where memory is allocated to both the instance and the database upon startup, DB2 allocates memory at different levels. This is primarily due to the fact that a DB2 instance can contain multiple databases. There are three main memory structures in DB2:

Instance shared memory: This refers to the database manager global shared memory, which is allocated when the instance is started using the db2start command, and remains allocated until a db2stop command is issued to stop the instance. Database shared memory: This refers to the database global memory, which is allocated when the database is activated or connected to for the first time. Memory allocated includes buffer pools, locklist, database heap, utility heap, package cache and catalog cache.

Application shared memory: This refers to the memory allocated when an application connects to a database and is used by agents that do the work requested by the connected clients. Each application connected to the database has memory allocated to it; therefore accurate configuration of the parameters affecting the application shared memory becomes crucial.

In DB2 for Windows, server activities are conducted in the form of threads, while in Linux and UNIX environment these are implemented as background processes. DB2 processes operate in the following levels:

Instance Level: These are processes that are initialized when an instance is started: 1. DB2 Daemon Spawner (db2gds): Global daemon processor started for each instance (only in UNIX) 2. DB2 System Controller (db2sysc): Main DB2 process 3. DB2 Watchdog (db2wdog): Parent process for all other processes 4. DB2 Format Log (db2fmtlg): Similar to the ARCn process in Oracle, preallocates log files in the log path

Database Level: These are processes that are initialized when a connection is made to a database. 1. DB2 Log Reader (db2loggr): Similar to the subset of Oracle's PMON process. This process reads log files during rollback, restart recovery and roll forward. 2. DB2 Log Writer (db2loggw): Flushes log from log buffer to the transaction log files on disk. Equivalent to LGWR process in Oracle. 3. DB2 Page Cleaner (db2pclnr): Equivalent to DBWR process in Oracle, this process cleans the buffer pool before pages from the disk are moved into the BP. 4. DB2 Prefetcher (db2pfchr): Retrieves pages from disk and places into the buffer pool before it is needed. 5. DB2 Deadlock Detector (db2dlock): Deadlock detector process.

Application Level: Each application connecting to the database would have its own share of application-level background processes associated with it. These are as follows: 1. DB2 Communication Manager (db2ipccm): Inter-process communication process for each locally connected client. 2. DB2 TCP Manager (db2tcpcm): TCP communication manager process for remote clients connecting using TCP/IP. 3. DB2 Coordinating Agent (db2agent): Process that handles all requests on behalf of an application. 4. DB2 Subagent (db2agnta): Idle subagent. 5. Active Subagent (db2agntp): Active subagent used when SMP parallelism is enabled so that multiple processes are used for a single task.

For a comprehensive explanation of DB2's processes please refer to the article 'Everything you wanted to know about DB2 processes'.

Back to top Locking mechanisms Locking in Oracle can be either manual or automatic. The Oracle Lock Manager can implicitly lock table data at the row level, or default locks can be overridden at transaction or session level using the following SQL statements:
1. SET TRANSACTION ISOLATION LEVEL 2. LOCK TABLE 3. SELECT FOR UPDATE

Oracle supports a mechanism called Multi-Version Read Consistency which is implemented by undo data in the undo segments. DB2 implements ANSI standard Isolation levels such as Uncommitted Read, Cursor stability, Read stability and Repeatable Read. A user will only see committed data unless the Uncommitted Read isolation level is used. Row locks are acquired implicitly according to the isolation level. Database objects that are lockable are table spaces, tables and rows, however, only tables and table spaces can be explicitly locked. The LOCK TABLE command can be used to lock a table instead of using the default row locking. Unlike Oracle, in DB2, locks are stored in the memory and not in data pages. The LOCKLIST database configuration parameter can be used to configure the memory available for locks, while the MAXLOCKS configuration parameter defines the maximum amount of memory for a particular application's locks.

Back to top Security Both Oracle and DB2 are secure databases with basic and advanced security features. In Oracle, there are 4 different user authentication methods, as follows:

Database: The database performs both identification and authentication of users. External: The operating system or network service performs authentication Global authentication and authorization: The user is authenticated globally by SSL Proxy authentication and authorization: The middle-tier server performs authentication.

The authentication method is specified when creating the user using the CREATE USER command. There are several Data Dictionary views that contain information about these users. In DB2, users do not exist within the database, but are rather managed by the operating system. No database login information is kept in any database table. Any operating system user can potentially access DB2; however, unless they have been granted a given DB2 authority or privilege, there is not much they can do. Granting and revoking authorities and privileges can easily be handled through the Control Center GUI. You first may have to add a user or group to the Control Center from the available operating system users or groups. Also in DB2 the term "roles" is not used; instead, DB2 uses the term "authorities", which are similar to Oracle's database roles, whereby privileges are granted to certain groups or users. The authorities supported with DB2 are: SYSADM, SYSCTRL, SYSMAINT, SYSMON, SECADM, DBADM and LOAD. The SYSADM, SYSCTRL and SYSMAINT authorities cannot be granted using the GRANT SQL statement. These special authorities can only be set from the database manager configuration file. DB2 also uses the term "privilege" which is similar to Oracle's system and schema object privileges. There are database privileges (connect, createtab, and so on) and database object privileges (schema, table, view, and so on). Figure 11 shows DB2 security information obtained from the Control Center GUI. Most of the tabs shown on the Change User window correspond to the privileges supported by DB2.

Figure 11. DB2 Security

Oracle 10g security remains largely the same with some enhancements. Following is a list of the enhancements in Oracle 10g:

DML support of FGA - SQL support of fine-grained auditing (FGA) has been enhanced to support granular auditing of queries as well as UPDATE, INSERT, and DELETE operations. Communication over SASL - This feature provides an alternate secure channel for communication between Oracle Internet Directory (OID) and the database or between two databases. If your enterprise deploys password-authenticated users, then you no longer have to invest in and administer public key infrastructure (PKI). Simple Authentication and Security Layer (SASL) communication provides an equally secure channel. Unified user model - A single sign on user defined in the directory can now use the features offered by Enterprise User Security. No additional administration tasks are required for provisioning and credential management. In addition, the administrative groups for Enterprise User Security can now designate an owner, which facilitates stronger security overall.

Easy database registration - This feature eliminates the need for the RDBMS_SERVER_DN parameter, making configuration of enterprise users easier. Extended and uniform audit trail - This feature improves security administration by providing a uniform audit trail for RDBMS auditing in the form of standard and finegrained audit tables. Transactions and SQL information have been added to the audit tables to further improve accountability of all users. Oracle Label Security directory integration - You can now manage Oracle Label Security policies and user label authorizations in a central OID/LDAP repository. This reduces administration costs and increases security by eliminating multiple management points.

Authentication in DB2 does not only involve encrypting user names and passwords but also allows for encryption of data as it travels across the network between the clients and the server. The location of the authentication process is determined by the value of the database manager configuration parameter AUTHENTICATION. The following are the valid options for enabling authentication for DB2:

SERVER_ENCRYPT - This value specifies that the authentication occurs on the server. The user id and password specified during connection are encrypted and sent to the server where they are compared with the user and password on the server side. If the match is successful, the user is allowed to access the database. KRB_SERVER_ENCRYPT - This specifies that the server accepts KERBEROS authentication or encrypted SERVER authentication schemes. DATA_ENCRYPT - This setting specifies that the server allows for SERVER authentication, and also that the data traveling over the network between the client and server is encrypted. DATA_ENCRYPT_CMP - This specifies that the server accepts encrypted SERVER authentication schemes and the encryption of user data. This authentication type allows for compatibility with down-level products not supporting the DATA_ENCRYPT authentication type. GSS_SERVER_ENCRYPT - This specifies that the server accepts GSS API-based plug-in authentication or encrypted server authentication schemes.

To update the AUTHENTICATION instance parameter, for example to a value of DATA_ENCRYPT, use the commands shown below:

Listing 1. Updating AUTHENTICATION instance parameter

UPDATE DBM CFG USING AUTHENTICATION DATA_ENCRYPT db2stop db2start

DB2 further extends security by offering a Label Based Access Control (LBAC) mechanism. The LBAC feature provides for greater granularity for controlling read and write access to

individual rows and table columns. A new security administrator role (SECADM) has been provided in DB2 which is needed to manipulate LBAC objects. Users attempting to access an object must have its security label granted to them. When there's a match, access is permitted; without a match, access is denied. There are basically three steps for implementing LBAC security in DB2:

Create a security policy. A security policy describes the criteria that are used to decide who has access to specific data. Only one security policy can be used to protect any one table, but different tables can be protected by different security policies. This is done using the CREATE SECURITY POLICY statement. All the management of the security policies is done using SQL statements. Create a security label. There are three types of security labels: o Row security labels. A security label associated with a data row or record in a database table. o Column security labels. A security label associated with a column in a database table. o User security labels. A security label granted to a database user. The SECADM creates security labels that are part of that policy. Once created, a security label can be associated with individual columns and rows in a table to protect the data held there.

Grant security labels to a users to allow them to access the data. The security administrator allows users access to protected data by granting them security labels. When a user tries to access protected data, that user's security label is compared to the security label protecting the data.

There are other aspects of database security beyond privileges and authorities. Briefly, here are some of the differences and similarities between Oracle and DB2: User authentication and authorization Oracle uses an encrypted password stored in the dictionary once a user is created. DB2 supports passwords for user authentication and uses the underlying operating user for authentication. Both Oracle and DB2 support LDAP (Oracle Internet Directory and IBM Directory Server). Both Oracle and DB2 support single sign on (SSO). Data encryption Oracle supports data encryption where sensitive data such as credit card numbers and some highly sensitive business data can be encrypted. DB2 allows data encryption at the column level. Network encryption

Oracle provides network encryption with its Oracle Advanced Security. Oracle uses DES, 3DES and RC4 industry standard encryptions. DB2 by itself does not enforce network encryption. However network encryption can be achieved using add-on Tivoli SecureWay. Audit trail Oracle allows you to audit trail users and objects. Log miner can also be used for investigating and analyzing suspicious queries. DB2 provides a similar auditing facility. The db2audit utility can be used for this purpose.

Back to top XML support In this section we compare Oracle's support forXML to DB2's. Shipped with Oracle 9i Release 2, Oracle XML DB feature provides a way to manage XML storage, retrieval and schema by defining XMLTYPE tables and columns which are stored as CLOB or shredded (decomposed) to small pieces into relational tables. Oracle 10g comes with some improvements to manage XML documents; for example, changes in schema can be dynamically reflected by mapping existing data without the need to re-import. Oracle 10g includes toolkits such as:

XML-SQL Util (XSU) - Interface provided for PL/SQL and Java XML Developer's kits (XDK) - For supported languages such as PL/SQL, C++ and Java

Oracle 10g is still an XML-enabled database. All interfaces, APIs, and packages provided are to ease the burden, complexity, and maintenance incurred to translate and map to and from XML to relational tables. XML-enabled databases, either using the CLOB or shredding methods are not good for performance. In the case of CLOBs for example, the XML documents are stored as image files inside the database. As you probably know, managing image files is often cumbersome. The shredding approach is also not good for performance. After shredding an XML document into pieces storing it in several tables, when you want to compose the XML document back to the original, you will have to use an SQL JOIN operation. JOINs in SQL are expensive, especially for a large number of tables. Keeping the fidelity of digital signatures can be a challenge as well. On the other hand, DB2 9 pureXML technology, stores XML documents natively, that is, internally in tree format. It also allows for the use of SQL with XML extensions, Xquery and Xpath to access relational and XML data. Storing XML documents natively is a better approach, and IBM's research indicates that there is a better performance for search and retrieval of XML documents, and reduction in the lines of codes for certain programs. In order to use the pureXML feature in your database, create the database as UNICODE (for example using codeset UTF-8). Failure to create a UNICODE database prior to creating a table will result in an error as shown below:

SQL1239N XML features can only be used in a Unicode database with a single database partition. SQLSTATE=42997

DB2 stores relational data as in previous versions; however, XML data is stored in hierarchical format (as a tree using the Xquery Data Model, XDM). There is tight integration between both XML and relational services. To store XML documents, a user needs to create a table, and specify a column to use a new data type, XML, as shown in the example below.

Listing 2. Create a table with XML datatype

create table T (i int, doc xml)

The following diagram depicts graphically how the two columns will look:

Figure 12. DB2 storage model

As XML documents are stored in parsed hierarchical format natively in the XQuery Data Model (XDM), there is no need for translation or mapping; the format used to store XML documents is the format used to process it. This allows for greater performance. Utilities such as backup, restore, import apply to tables with XML columns the same as in any other tables. XML data can be inserted into the XML column either by using the INSERT statement or by using the DB2 IMPORT utility (Note: DB2 LOAD utility does not support XML yet). Prior to importing XML documents received from third parties, it is a good idea to validate these documents against a pre-defined XML schema. To register against an XML schema, DBAs

are required to issue the REGISTER XML SCHEMA command, ended with COMPLETE XML SCHEMA to complete the registration process. DB2 9 also supports indexes to be created on a subset of an XML document, or on the entire document. An XPATH needs to be specified when creating an index which would point to that particular element/attribute to be indexed. With DB2 9 you now have four ways to access relational and XML data as shown in Figure 13:

Plain SQL (no XQuery involved) SQL/XML, that is, XQuery embedded in SQL XQuery as a stand-alone language (no SQL involved) Xquery with embedded SQL

Figure 13. PureXML Query possibilities

Table 3 compares the XML capabilities between DB2 9 and Oracle 10g. Table 3. XML Feature Comparisons Oracle XML capabilities IBM DB2 9 for Linux, Unix and Windows 10g XML-enabled store Not Applicable XML native store Ease of maintenance for big environment Highly scalable Store XML documents as To move forward however, XML native CLOBs storage is encouraged. To move forward however, XML native Shredding storage is encouraged. There are more developerWorks articles on IBM pureXML capabilities such as Query DB2 XML data with XQuery, Query DB2 XML Data with SQL amongst others for more in-depth discussions.

Back to top

Partitioning DB2's table partitioning (a.k.a Range partitioning), is similar to Oracle's partitioning. It basically allows a single logical table to be broken up into multiple physical storage objects across one or more table spaces. Each of the objects would correspond to a 'partition' and would allow each table space to contain a range of data which can be accessed very easily. In DB2 there are several ways to partition your data, and you can apply these methods simultaneously on the same data. To avoid confusion, here is a short explanation about the different ways to provide this partitioning:

DATABASE PARTITIONING - distributing data by key hash across logical nodes of the database (DPF). RANGE/TABLE PARTITIONING (Available with DB2 9) - splitting data by key range over multiple physical objects within a logical database partition. MULTI DIMENSIONAL CLUSTERING (MDC) - organizing data in table (or range of a table) by multiple key values.

With Table partitioning, new in DB2 9, table data can be divided based on particular values in one or more table columns across different table spaces. These partitions can be backed up and restored individually, and improve performance of certain queries, as the DB2 optimizer is aware of the existence of these partitions and can eliminate scanning of data partitions not required in the query. For example, if you had partition your table in four quarters of the year, and your query only needs data from the 4th quarter, DB2 would skip parsing the first three quarters and would go straight to the fourth quarter and parse it. This is called partition elimination. As mentioned before, it is important to note that all 3 methods of data organization i.e. Database Partitioning, Table Partitioning and Multi Dimensional Clustering can be used simultaneously in DB2 9. The following example creates a table customer where rows with l_shipdate >= '01/01/2006' and l_shipdate <= '03/31/2006' are stored in table space ts1, rows with l_shipdate >= '04/01/2006' and l_shipdate <= '06/30/2006' are in table space ts2, etc. More exhaustive explanation can be obtained from developerWorks article, Table partitioning in DB2 9. Listing 3. Range partitoning a table
CREATE TABLE customer (l_shipdate, l_name CHAR(30)) IN ts1, ts2, ts3, ts4, ts5 PARTITION BY RANGE(l_shipdate) (STARTING FROM ('01/01/2006') ENDING AT ('12/31/2006') EVERY (3 MONTHS))

Back to top

Compression There are two compression features provided by Oracle; index and table level compression. Improper planning of these features may have adverse effect in performance. Oracle introduced index compression since version 8i. Indexes that can be compressed are bitmap, btree and index organized tables. To use index compression is straightforward; for example, to create an index with the compression feature, use Listing 4. Create index with compression
CREATE INDEX ord_customer_ix_demo ON orders (customer_id, sales_rep_id) COMPRESS 1;

For indexes that were not created initially with compression, you can turn them to compression by altering them. The following shows a sample how index can be altered to include compression. Listing 5. Alter index with compression
alter index ord_customer_ix_demo rebuild compress

Currently, Oracle doesn't provide any automated advisor to pinpoint which indexes should be compressed. Most of the benefits gained by index compression requires proper planning by seasoned DBAs who with intimate knowledge of Oracle CBO. Table compression on the other hand, was introduced in Oracle 9i release 2. It can be used to compress entire tables, table partitions, and materialized views. The compression can be applied to all partitions or some partitions. Though table compression works for a non-partitioned table, its usage for non-partitioned tables in OLTP workloads may not be desirable as insert and update performance may suffer. In Oracle table compression, duplicate values are removed in a database block, and information is stored to recreate the uncompressed data within the block. The following example shows how to create partition table with compression. Listing 6. Create table with compression
CREATE TABLE costs_demo ( prod_id NUMBER(6), time_id DATE, unit_cost NUMBER(10,2), unit_price NUMBER(10,2)) PARTITION BY RANGE (time_id) (PARTITION costs_old VALUES LESS THAN (TO_DATE('01-JAN-2003', 'DD-MONYYYY')) COMPRESS, PARTITION costs_q1_2003 VALUES LESS THAN (TO_DATE('01-APR-2003', 'DD-MONYYYY')), PARTITION costs_q2_2003 VALUES LESS THAN (TO_DATE('01-JUN-2003', 'DD-MON-

YYYY')), PARTITION costs_recent VALUES LESS THAN (MAXVALUE));

To turn a table into a compressed table, use alter table <table name> move compress. A compressed table, however, does not allow adding or dropping of columns. With respect to DB2, there were several compression methods prior to DB2 9, however, it is with DB2 9 that row compression is introduced. Row compression requires the creation of a dictionary which stores a mapping between repetitive patterns or entries and numeric keys. The compression algorithm is intelligent enough not to compress rows that will not realize in any significant disk-space saving. DB2's row compression, unlike Oracle's key compression, does not require keys to be specified. Compression is enabled at individual table level via the CREATE TABLE or ALTER TABLE commands. For example: Listing 7. Create/Alter table with COMPRESSION YES
CREATE TABLE Sales COMPRESS YES ALTER TABLE Sales COMPRESS YES

To achieve the same effect using the DB2 Control Center, during the column definition (second step in the table creation wizard), ensure that you choose the checkbox, Store table data in a compressed format located at the bottom of the panel (as the following diagram shows).

Figure 14. DB2 Control Center - Creating table with compression

The table dictionary is built only when a REORG is performed, after which the data in the table can be compressed. The dictionary gets updated for every subsequent REORG operation. The compressed data is kept both on disk and memory and DB2 also compresses user data stored in log files, thereby reducing log file size. Note that each partition of a partitioned table can have a different compression dictionaries and each partition of a table in DPF can have a different compression dictionaries. Besides, data row compression, other compression mechanisms offered by DB2 9 include:

NULL and Default Value Compression (V8 GA): Compression for null, zero length data in variable length columns and system default value. Multidimensional Clustering (V8 GA): Implements a form of index compression by using block indexes, one index entry for thousands of records. Database Backup Compression (V8 FP4): Compression to result in smaller backup images. XML Parsing

Back to top Autonomic Going from Oracle 9i to 10g, there are few tuning improvements provided by Oracle. Oracle automated the following tuning areas:

Redo Logfile Sizing Advisor - This feature recommends the optimal size of redo log files in order to avoid excessive disk I/Os due to frequent checkpointing. Automatic Checkpoint Tuning - The Oracle Database can now self-tune checkpointing to achieve good recovery times with low impact on normal throughput. You no longer have to set any checkpoint-related parameters. Automatic Shared Memory Tuning - Automatic Shared Memory Tuning automates the configuration of System Global Area (SGA) memory-related parameters (buffer cache, shared pool) through self-tuning algorithms. It simplifies database configuration, ensures most efficient utilization of available memory and improves performance. Transaction Rollback and Recovery Monitoring - This feature enables you estimate how long it will take to roll back a transaction. You can also monitor the progress of transactions being recovered and estimate the average speed of transaction recovery.

Oracle also provides some advisors such as segment and undo advisors. The segment advisor is based on the level of space fragmentation within an object, and as result, gives advice on whether an object is a good candidate for the new online shrink operation. As well, this advisor give reports on the historical growth trend of segments, and proved to be especially informative for capacity planning. Undo Advisor, on the other hand, helps administrators to make the right judgement in sizing the undo table space in both flash back and non-flashback features. It advises administrators in setting UNDO_RETENTION appropriately to avoid the age-old 'snapshot too old' problem. DB2 9 introduces several new autonomic enhancements. For example, DB2 9 introduces a new self-tuning memory feature (using the self_tuning_mem database configuration parameter) that simplifies the task of memory configuration by automatically setting values for several memory configuration parameters. When enabled, the automatic tuner acting as dispatcher, will figure out the memory resources available and distribute them to several memory consumers for the database dynamically.

Other than the self tuning memory, DB2 9 introduces other enhancements as seen below. It is a non-exhaustive but important list. Automatic configuration Version 8 of DB2 introduced the Configuration Advisor that detected the system and database characteristics - CPUs, memory, database size, number of tables, etc. and recommended values for configuration parameters. DB2 9 goes even further - it runs the configuration advisor automatically after you create a database, and makes some basic tuning decisions by default. For example it configures the size of the default buffer pool, I/O cleaners and I/O servers, etc. This initial automatic tuning means that your database will have better performance than a database created with the previous database configuration default values, enabling better out-of-the-box operation. Automatic data statistics collection DB2 9 also enables automation of certain ongoing tasks by default. With this feature, DB2 determines which statistics are required and need to be updated and then automatically executes the RUNSTATS utility in the background. Automatic storage management DB2 9 extends the automated storage features first introduced in DB2 V8.2.2. Automatic storage automatically grows the size of your database across disk and file systems and since it automatically grows the size of the database, it removes the need to managing storage containers by DBAs. When you create databases in DB2 9, the automatic storage management feature is enabled by default. Automatic table and index reorganization enhancements Automatic reorg was introduced since version 8.2. However, DB9 brings it further to allow you to do the following

Specify the use of a system temporary table space with an appropriate pagesize for an offline table reorganization. Tables to be reorg-ed can be limited in size. Specify that automatic index reorganizations should be run online and in the online maintenance window. Specify whether to keep or rebuild compression dictionaries during reorganization.

Back to top Tools

We shall look at tools from different areas such as database creation and maintenance, network, administration GUI, performance tuning, data movement and backup-recovery tools. Figure 15 shows the DB2 9 GUI tools.

Figure 15. DB2 9 GUI Tools

Let's take a look at how similar tasks are performed in Oracle and DB2 9. Database Creation and Maintenance Oracle provides the Database Configuration Assistant (dbca) as the GUI tool to create databases. For database maintenance, Oracle provides the Oracle Enterprise Manager. DB2 databases can be created and maintained from the DB2 Control Center. Network Oracle provides the Network Configuration Assistant (netca) for network configuration. Alternatively, you can use the Oracle Network Manager to configure service naming, listener, profile and Oracle name servers. DB2 uses the CATALOG command to catalog nodes and databases. Cataloging can also be done using either the DB2 command line or DB2 Configuration Assistant GUI. Administration The Oracle Enterprise Manager provides a wide range of administrative capabilities for the dayto-day tasks of administrators. DB2 Control Center provides similar functions as Oracle Enterprise Manager. Apart from the DB2 Control Center, the DB2 command line processor can

also be used to issue DDL and DML statements. This utility is similar to the Oracle SQLPLUS utility. Figure 16 shows the DB2 command line processor.

Figure 16. DB2 Command Line Processor

Commands can also be issued from the Command Center, shown in Figure 17.

Figure 17. Command Center GUI (GUI version of DB2 Command Line Processor)

Performance tuning Oracle Enterprise Manager comes with Change Management pack, Tuning Pack, and Diagnostic Pack. DB2 provides the Event Analyzer, Health Center, Indoubt Transaction Manager and Memory Visualizer as GUI tools for performance tuning tasks. Data movement Oracle provides SQL Loader (sqlldr) for loading data in delimited text format. Import (imp) and export (exp) can be used to perform logical import and export. DB2 provides similar import, export and load utilities . For cross platform data movement, DB2 provides the db2move utility. Backup and Recovery Oracle provides Recovery Manager as an option for hot backup. Backing up databases in DB2 can be accomplished using the backup command or the DB2 Control Center.

Oracle 10g Enteprise Manager comes with new performance overview charts. The enhanced Oracle Enterprise Manager HTML interface provides a central point of access to all database performance-related statistics and facilitates complete monitoring and diagnostics. Apart from interfaces that were shipped with DB2 UDB version 8, DB2 9 introduces a new nocharge application development tool, based on the Eclipse framework called tbe DB2 Developer Workbench (DWB). This tool, which comes as a separate download or CD, replaces DB2 version 8's Development Center. The DWB is a one-stop center for creating, editing, debugging, deploying, and testing DB2 stored procedures and user-defined functions. You can also use the DWB to develop SQLJ applications, and create, edit, and run SQL statements and XML queries. The DWB has several views for developing DB2 business objects, such as:

Database Explorer view - Shows what's in the database (tables, stored procedures, user defined functions, dependencies, remote servers, etc) and allows you to perform actions on these objects. Data Project Explorer view - Lets you perform development actions for procedures, user defined functions, and SQL statements, with easy operations such as drag & drop, copy & paste, wizards, context sensitive completion options, etc. Data Output view - Lets you see reports of data development actions against a database.

Other than the functionality of DB2 version 8's Development Center, the new Developer Workbench includes support for migrating projects, comparing routines, XML functions and building XQueries using the XQuery Builder, etc. You can download the DB2 Developer Workbench from the partner web site. For more details about the DB2 Developer Workbench review this tutorial tutorial in developerWorks. For more exhaustive examples and features, refer to the Application development enhancements article in developerWorks. Figure 18 shows how DWB can be used to create stored procedures:

Figure 18. DB2 Developer WorkBench

Back to top Summary In this article we've introduced you to DB2 9 for Linux, UNIX and Windows by using your current knowledge of Oracle 10g Release 2 as leverage. We briefly described the DB2 9 architecture, background processes, memory model, security, tools, and so on. There are many similarities between Oracle and DB2 9, and we have pointed out some of the differences so you can use your current knowledge to become successful with DB2 9. Table 3 summarizes the differences and similarities between Oracle and DB2 9 that we've discussed. Table 3 - Summary of Oracle vs. DB2 9 concepts Oracle Instance Database DB2 9 Instance Database Comment A DB2 instance can contain several databases DB2 uses two levels of configuration:- Database Manager Configuration (DBM CFG) (at the instance level)- Database Configuration (DB CFG) (at the database level).Like in Oracle, many of these configuration parameters can be dynamically changed. DB2 supports SMS and DMS Table spaces. DMS Table spaces are similar to Oracle's. DB2 supports these page sizes: 4k, 8k, 16k, 32k. A row must fit any of these page sizes. It cannot span to other pages like in Oracle's.

initSID.ora DBM CFG andDB OR SPFILE CFG

Table spaces Table spaces Data Blocks Pages

Extents Data Files Redo Log Files

Extents DMS Table space containers Transaction Log Files

Containers for DMS table spaces can be raw devices or files.

Data Buffers Buffer pools. Database Manager and Database Shared memory Catalog Package cache Utility Heap Catalog cache SYSCATSPACE table space

DB2 does not have a predefined set of bufferpools, but you can create as many as desired. A bufferpool of a given page size must be exist prior to creating a table space with the given page size.

SGA Data Dictionary Library cache Large Pool Data Dictionary Cache SYSTEM table space

Resources