DB2 running on Linux, Unix, and Windows (LUW ... - GSE Belux

DB2 running on Linux, Unix, and Windows (LUW) continues to grow at a rapid pace. This rapid growth has resulted in a shortage of experienced non-mainframe DB2 DBAs. IT departments today have to deal with tightening budgets and shrinking staffs. The luxury of being a single platform DBA is quickly becoming a thing of the past. Many DB2 mainframe DBAs now find themselves having to support DB2 on multiple platforms. This presentation focuses in on comparing the key architectural and administrative differences between DB2 running on LUW vs. vs z/OS. z/OS DBAs having to manage DB2 on multiple platforms will find this information essential.

1

Basic database components C Component t comparison i What version of DBMS do I use? Native access methods Architectural overview Terminology Similar terms, similar meaning Subsystem vs. Instance comparison Storage Management Terminology for each platform How space is allocated on LUW vs. z/OS Object Comparisons Bufferpools Databases Tablespaces Tables Indexes Administrative Differences Differences in optimizer Parallelism differences Monitoring options Backup/Recovery Differences in logging Differences in Utilities

2

Most of the object types and functionalities are very similar across the platforms. Probably the biggest difference is in storage management.

3

4

5

Control Center being deprecated with DB2 LUW 9.7

6

z/OS SMS – System Managed Storage. A storage group definition in an SMS environment is typically defined with a volume list containing an *. This in turn allows SMS to decide which volume to put the dataset on. Extent – This is a physical extension of a dataset. This is not limited to DB2 datasets. When defining any type of dataset in S/390 a secondary value is specified. In the event primary y allocation becomingg full an extension is taken with the amount of of the datasets p space specified on the secondary allocation. LUW SMS – System Managed Space When a tablespace is defined as SMS no space parameters are specified, only a device. DB2 will use the space available on the device as needed. This is very useful for t temporary tables t bl or tables t bl which hi h grow/shrink / h i k often. ft See S the th tablespace t bl f il for foil f more details Extent – An extent is a block of data pages which get allocated based on the EXTENTSIZE parameter of the tablespace definition. See the tablespace foil for more details.

7

z/OS A subsystem is the physical installation of DB2. When a subsystem is defined a DB2 catalog is defined for the entire subsystem. A subsystem typically has many databases running on it. If a data sharing or sysplex environment is defined there is one catalog for all members (subsystems) of the data sharing group DSNZPARM – configuration parameters for entire subsystem LUW 2 configuration files Database Manager configuration file – configuration parameters for entire instance D t b Database configuration fi ti file fil – Created C t d for f eachh database d t b

8

9

The biggest difference at the database level is how the system catalog is defined. •In z/OS there is one common system catalog for all databases defined within a subsystem. • On the LUW platform a new system catalog gets generated for every database defined within an instance. •The catalog tables and memory structures are actually defined within the database itself. •3 SMS tablespaces are created by default •SYSCATSPACE – Contains system catalog tables •TEMPSPACE1 – Holds temp tables used by LUW •USERSPACE1 – Contains user tables unless tablespace specified (DSNDB04) •This This makes the database on LUW more like a subsystem

10

USERSPACE1 is a temporary table space for holding temporary data from tables created with a DECLARE GLOBAL TEMPORARY TABLE statement.

11

z/OS Multiple subsystems per machine. Each subsystem has 1 set of: •Logs •Catalog •Bufferpools •DSNZPARM – configuration parameters LUW •On a single machine, one or more instances can exist •DB2 Administration Server (DAS) •Enables remote administration of DB2 servers •Provides scheduler used to schedule local and remote jobs •Provides a mechanism for DB2 discovery to return information to remote clients •Can connect to one or more databases at the same time on different instances and/or machines • Cannot have SQL statements joining tables from different databases. • Database Manager Configuration file •created when an instance is created •parameters affect system wide resources at the product or instance level •parameters can be changed from system default values improve performance or increase capacity. • Database Configuration file •one config file is created when the database is created •specifies amount of resources to be allocated to the database

12

The only option for physical storage on z/OS is a physical device (volume). DB2 on LUW allows for 3 different ways to specify storage depending on the type of tablespace defined.

13

Some of the most common terms used when talking about storage on z/OS DASD – This is the name for the physical storage devices on z/OS. Essentially the same as a disk drive on a LUW platform. The volume serial or volser is the label of the drive Storage Group is a user defined DB2 object identifying a group of volumes. volumes When a TS is created a stogroup can be identified and DB2 will use one of the volumes in the list to allocate the VSAM dataset.

14

15

•Most common are segmented and partitioned. •simple tablespaces no longer supported as of V9. Segmented tablespaces offer superior performance. •Segmented tablespaces allow for efficient access of data particularly when multiple tables are defined into a table space, or variable row lengths. The table data for each table is physically separated into segments. I/O performance in general is much better with a segmented vs a simple tablespace. •Partitioned Tablespaces p are typically yp y used for very y large g tables. Only y one table can be defined into a partitioned tablespace. A partitioned tablespace can have up to 254 partitions. Each partition is a separate physical dataset which can be placed on different volumes for optimal performance. Partitioning allows for easier maintenance such as loads, copies, or reorgs because each partition can be acted on independently. •Universal Tablespaces- A universal table space is a table space that is both

segmented and partitioned. Two types of universal table spaces are available: the ppartition-by-growth yg table space p and the range-partitioned g p table space. p Allocation methods VCAT method is really obsolete. It requires that the VSAM dataset be pre-defined via an IDCAMS job prior to the tablespace being created. In the early days of DB2 this was desirable from a recoverability standpoint because if a tablespace was dropped the underlying dataset would not be deleted. A storage group defined tablespace which when dropped would delete the underlying VSAM dataset as well well. The option to keep the VSAM dataset in storage group defined tablespaces was added several releases ago. Stogroup defined tablespaces lets DB2 do all the VSAM allocation work for you. It actually runs the IDCAMS job under the covers when the create statement is executed.

16

The VSAM dataset for a z/OS tablespace or indexspace has a fixed format. The first level or VCAT is usually the subsystem identifier. The last level of the name A001 can increment if multiple datasets are required for a simple/segmented tablespace. This value will also represent the partition number of a partitioned table space. The instance number will be incremented if tables have been cloned.

17

SMS – System Managed Space allows for the operating system to allocate space for the table as needed. No space parameters are specified. This is the easiest method as far as storage management. It is good for small tables or tables which grow for short periods and shrink back down. DMS – Database Managed Space requires the specification of space when the tablespace is created. This space is immediately taken and reserved for use by the tablespace. tablespace Automatic - specify the MANAGED BY AUTOMATIC STORAGE clause or omit the MANAGED BY clause. You do not need to provide container definitions in this case because the database manager assigns the containers automatically. If you create a table space as a regular or large table space, it is created as a DMS table space p with file containers. If yyou create a table space p as a user or system temporary table space, it is created as an SMS table space with directory containers.

18

The type of tablespace chosen depends on the characteristics of the data stored within the tablespace. While DMS tablespaces clearly provide more flexibility for storage capacity, SMS tablespaces are generally recommended for temporary tablespaces and catalog tablespaces. In addition to understanding the types of tablespaces, it is important to understand how data is managed within the tablespace. All data within DB2 LUW is stored in pages. A page size is defined at tablespace creation and can be specified in 4k, 8k, 16k, and 32k sizes. i Row size, i random d vs. sequential i l access, and d severall other h factors f must be b evaluated l d to determine the optimal page size for the tablespace. Pages are grouped into allocation units called extents. Each time the tablespace needs to allocate additional storage, the extent size is used to determine the size. During insert activity, DB2 LUW will write to a container until the extent size has reached capacity, at that point, DB2 LUW will allocate an extent on the next container and continue the write activity i i

19

Partition by Growth New n V9 - segmented tables benefit from increased table space limits and SQL and utility parallelism that were formerly available only to partitioned tables. No need to reorganize a table space to change the limit keys. Range Partitioned - operations that are supported on a regular partitioned or segmented g table space p are supported pp on a range-partitioned g p table space. p You can create a range-partitioned table space by specifying both SEGSIZE and NUMPARTS keywords on the CREATE TABLESPACE statement.

20

The biggest difference in the table definitions between z/OS and LUW is the way index definitions are handled. In z/OS there are no predefined indexspaces as there are in LUW. When the CREATE INDEX statement is executed the same rules apply as those when creating a tablespace. You can either specify it to be VCAT or storage group defined. The underlying VSAM file is then created. Each index has it’s own VSAM dataset.

21

22

In z/OS there are no predefined indexspaces as there are in LUW. When the CREATE INDEX statement is executed the same rules apply as those when creating a tablespace. You can either specify it to be VCAT or storage group defined. The underlying VSAM file is then created. Each index has it’s own VSAM dataset

23

When creating a table in DB2 LUW you must have a tablespace pre-defined for both the table and any indexes you might add to the table. The indexspace specification is part of the table definition. Therefore all indexes for the table use the same indexspace.

24

25

26

Optimizer Class Static SQL Controlled on PREP and BIND statements Stored in QUERYOPT in SYSCAT.PACKAGES Dynamic SQL CURRENT QUERY OPTIMIZATION register using SET command If not set, DFT_QUERYOPT database parmater

27

•The EXPLAIN statement is also extended to insert information into two new tables for V6. •The DSN DSN_FUNCTION FUNCTION table is useful for finding out information about function resolution resolution. •The DSN_STATEMENT table is useful for finding out the estimated cost of SQL statements. •The DSN_STATEMENT_CACHE table collects information about tables in the dynamic SQL cache. There are additional explain tables that are used by IBM’s optimization tools Visual Explain, and OSC. •DSN_PREDICAT_TABLE •DSN_STRUCT_TABLE •DSN_PGROUP_TABLE •DSN_PTASK_TABLE •DSN_FILTER_TABLE •DSN_DETCOST_TABLE •DSN_SORT_TABLE •DSN_SORTKEY_TABLE •DSN_PGRANGE_TABLE •DSN_VIEWREF_TABLE •DSN_QUERY_TABLE •Unlike U lik the th plan l ttable, bl neither ith th the ffunction ti ttable bl nor th the statement t t t ttable bl h has tto exist i t tto use EXPLAIN. LUW EXPLAIN_ARGUMENT: Represents the unique characteristics for each individual operator. EXPLAIN_INSTANCE: Main control table for all explain information. Each row of data in the explain tables is explicitly linked to one row in this table. Basic information about the source of the SQL statements being explained and environment information is kept in this table. EXPLAIN_OBJECT: Contains data objects required by the access plan to satisfy the SQ statement. EXPLAIN_OPERATOR: Contains all the operators needed to satisfy the SQL statement. EXPLAIN PREDICATE: Identifies which predicates are applied by a specific operator. EXPLAIN_PREDICATE: operator EXPLAIN_STATEMENT: Contains the text of the SQL statement in two forms. The original version entered by the user, and a rewritten version generated by the compilation process. EXPLAIN_STREAM: This table represents the input and output data streams between individual operators and data objects.

28

29 4

DPF - Allows you to break up very large databases into manageable chunks. MPP- Massively Parallel Processor (pictured) •

Multiple machines with single processors grouped together in a cluster

•

“Shared nothing” configuration

SMP – Symmetric multi-processor •

Multiple processors on a single machine

30 4

z/OS I/O – DB2 concurrently prefetches data from multiple partitions. CPU – DB2 starts multiple tasks across servers or LPARs in parallel to process query. SYSPLEX – Same as CPU except tasks are spread across machines in sysplex EEE

I/O p parallelism When there are multiple p containers for a table space, p , the database manager can exploit parallel I/O. Parallel I/O refers to the process of writing to, or reading from, two or more I/O devices simultaneously; it can result in significant improvements in throughput. Query parallelism Intrapartition parallelism Intrapartition parallelism refers to the ability to break up a query into multiple parts. Some DB2 LUW utilities also perform this t type off parallelism. ll li I t Intrapartition titi parallelism ll li subdivides bdi id what h t is i usually ll considered a single database operation such as index creation, database loading, or SQL queries into multiple parts, many or all of which can be run in parallel within a single database partition. Interpartition parallelism Interpartition parallelism refers to the ability to break upp a qqueryy into multiple p parts p across multiple p ppartitions of a ppartitioned database, on one machine or multiple machines. The query is run in parallel. Some DB2 LUW utilities also perform this type of parallelism. Interpartition parallelism subdivides what is usually considered a single database operation such as index creation, database loading, or SQL queries into multiple parts, many or all of which can be run in parallel across multiple partitions of a partitioned database on one machine or on multiple machines.

31

LUW

Activity event monitor This monitor captures information about individual activities in a service class, workload, or work class or activities that violated a threshold. A common use for activity data is to use it as input to tools such as db2advis or to use access plans (from the explain utility) to help determine table, column, and index usage for a set of queries. Th h ld violations Threshold i l ti eventt monitor it This monitor captures information when a threshold is violated. It indicates what threshold was violated, the activity that caused the violation, and what action was taken when it occurred. Statistics event monitor This monitor serves as a low-overhead alternative to capturing detailed activity ti it information i f ti by b collecting ll ti aggregate t data d t (for (f example, l the th number of activities completed and average execution time). Aggregate data includes histograms for a number of activity measurements including lifetime, queue time, execution time and estimated cost. You can use histograms to understand the distribution of values, identify outliers, and compute additional statistics such as averages and standard deviations. For example, histograms can help you understand the variation in lifetime th t users experience. that i Th The average life lif time ti alone l does d nott reflect fl t what h ta user experiences if there is a high degree of variability. z/OS z/OS traces offer much greater detail but can also cause much more overhead. Records can be output to either SMF, or GTF record types. DB2PM

th

3rd

t

it

b

dt

d

t

32 t

33

z/OS V9 - The online BACKUP SYSTEM utility invokes z/OS® DFSMShsm™ (Version 1 Release 7 or above) to copy the volumes on which the DB2® data and log information resides for either a DB2 subsystem or data sharing group. You can use BACKUP SYSTEM to copy all data for a single application (for example, when DB2 is the database server for a resource planning solution). All data sets that you want to copy must be SMS-managed data sets. You can subsequently run the RESTORE SYSTEM utility to recover the entire system.

34

35

z/OS Logs are defined at the subsystem level and are global for all objects. All update activity is logged in the current active log. When the active log is full it is automatically archived. Dual Logging provides a redundant backup of log files in case of media failure LUW No concept of auto-archiving. When a primary log file is filled a secondary file will be allocated. This will continue until no more secondaries are available Dual Logging added in 7.2

36

Supports both crash and version type recoveries Primary log files are allocated when the database is created. Secondary log files are allocated as needed. •

Automatically de-allocated when no longer needed

•

Good for periodic large units of work

37

Active (15,16) – Contains information related to units of work that have not yet been committed or rolled back. They also contain information for transactions that have committed, but whose changes have not been written to disk. Online archive (14) – Contains information related to completed transactions that no longer require crash recovery protection. These are called online because they reside in the same subdirectory as the active logs. Offline archive (12,13) – log files which have been removed from the active log subdirectory The files must be moved manually. subdirectory. manually There is no auto-archiving auto archiving in LUW

38

LOCAL TIME allows you to recover to anytime, even to an incomplete unit of work.

39

This is not an exhaustive list of all utilities available. It is just highlighting the more commonly used ones.

40

IBM introduced their new high performance unload utility in version 7. This utility will allow you to unload data from either a table or an image copy.

41

LUW Load only locks table being loaded instead of entire table space. READ Access allows queries against pre-existing rows while load is running. LOCK WITH FORCE – Forces applications to release locks on tables to be loaded. CURSOR file type – Load directly from query result set without first saving to an external file.

42

LUW - The automatic reorganization feature can be enabled or disabled by using the AUTO_REORG, AUTO_TBL_MAINT, and AUTO_MAINT database configuration parameters.

43

LUW A statistics profile is a set of options that specify which statistics are to be collected on a particular table, for example, table statistics, index statistics, or distribution statistics.

44

z/OS Use the QUIESCE utility also to establish a single point of consistency (a quiesce point) for one or more page sets. Typically, you name all the table spaces in a table space set that you want recovered to the same point in time to avoid referential integrity violations LUW Users with sysadm, sysmaint, and sysctrl authority always have access to an instance while it is quiesced, and users with sysadm and dbadm authority always have access to a database while it is quiesced.

45

46

47

Jim Wankowski has more than 26 years of development and database administration experience with DB2. Jim is currently the DB2 product manager at Quest Software. Prior to joining Quest , he worked for nine years as a DB2 product specialist at Platinum Technology, and prior to that he worked as a DB2 DBA for Northrop Aircraft in Los Angeles. Jim is a well-known international speaker who has written articles for DB2 Magazine, and Z/Journal, and regularly presents at IDUG , regional DB2 user groups, groups and vendor seminars worldwide. worldwide

48