Monday, September 1, 2008

Comparison of DB2 and VSAM.....Cont 2

Feature

DB2

VSAM

Performance Tuning


Can be tuned anytime

Writes SMF records

Can be at SQL level

Tools available for aiding

Subsystem level tuning possible

Abundant tuning skills

Depends on initial design

No SMF records

Only application level

No tuning aids

Not a subsystem

Tuning skills are rare

CPU & IO parallelism


Scanning is Faster

No parallelism

Parallel Sysplex


Can participate

Optimizer handles

Can participate

No optimization

Reorganization


Direct reorganization

Online reorg possible

Parallel reorg

Delete & recreate

Downtime needed

No parallelism

Recovery


Managed by DB2

Always recoverable

From log / backup

Auto Recovery

Parallel recovery

Managed by CICS/IMS

No recovery in batch

From backup only

Manual Restore

No parallelism

Backup


Online backup possible

Incremental backup

Parallel backup

Downtime needed

No incremental backup

No parallelism

Availability


Parallel reorg, backup

Online reorg, backup

Less downtime

No online maintenance

No parallelism

More Downtime

Disaster Recovery


Supported by DB2

Part of DASD recovery

Comparison of DB2 and VSAM

Feature

DB2

VSAM

Hardware Independence

PC to mainframe

Only Mainframe

OS Independence

NT, Unix & OS/390

Only OS/390

Vendor Independence

RBDMS with ANSI std.

Only IBM

Scalability

PC to mainframes

Upto 4000 terabytes for LOB

Only Mainframe

Maximum size is 128 terabytes

Ease of development

Standard SQL

Stored procedure & triggers

Not so simple

No such option

Ease of maintenence

Standard SQL

Difficult

Security

High degrees of security

Only at Dataset level

Referential Integrity

DB2 enforces it

Manages even externally stored data

Developers responsibility

Not applicable

Query Interface

Easy to view/modify

Not available

Products/tool suite

IBM & 3rd Parties

Not available

Data Capacity

254 times largest VSAM

Limited to 2 terabytes

Data sharing

Across CICS, IMS, Batch, TSO

Very limited support

Web & Java support

JDBC, SQLJ, Net.data

Need custom interfaces

Distributed environment

Consistent across platforms

Stored procs reduce network traffic

Only Mainframe

Not applicable

XML support

XML extenders

Not supported

Performance

For less data

Better for large data

Optimizer handles

Partitioning improves performance

Better when data is less

For less data

Developer responsible

No partitioning

MVS

MVS (Multiple Virtual Storage) is an operating system from IBM that continues to run on many of IBM's mainframe and large server computers. MVS has been said to be the operating system that keeps the world going and the same could be said of its successor systems, OS/390 and z/OS. The payroll, accounts receivable, transaction processing, database management, and other programs critical to the world's largest businesses are usually run on an MVS or successor system. Although MVS has often been seen as a monolithic, centrally-controlled information system, IBM has in recent years repositioned it (and successor systems) as a "large server" in a network-oriented distributed environment, using a 3-tier application model.

The follow-on version of MVS, OS/390, no longer included the "MVS" in its name. Since MVS represents a certain epoch and culture in the history of computing and since many older MVS systems still operate, the term "MVS" will probably continue to be used for some time. Since OS/390 also comes with Unix user and programming interfaces built in, it can be used as both an MVS system and a UNIX system at the same time. A more recent evolution of MVS is z/OS, an operating system for IBM's zSeries mainframes. MVS systems run older applications developed using COBOL and, for transaction programs, CICS. Older application programs written in PL/I and FORTRAN are still running. Older applications use the Virtual Storage Access Method access method for file management and Virtual Telecommunications Access Method for telecommunication with users. The most common program environment today uses the C and C++ languages. DB2 is IBM's primary relational database management system (RDBMS). Java applications can be developed and run under OS/390's UNIX environment.

MVS is a generic name for specific products that included MVS/SP (MVS/System Product), MVS/XA (MVS/Extended Architecture), and MVS/ESA (MVS/Enterprise Systems Architecture). Historically, MVS evolved from OS/360, the operating system for the System/360, which was released in 1964. It later became the OS/370 and the System/370. OS/370 evolved into the OS/VS, OS/MFT, OS/MVT, OS/MVS, MVS/SP, MVS/XA, MVS/ESA, and finally OS/390 and then z/OS. Throughout this evolution, application programs written for any operating system have always been able to run in any of the later operating systems. (This is called forward compatibility.)

An MVS system is a set of basic products and a set of optional products. This allows a customer to choose the set of functions they need and exclude the rest. In practice, most customers probably use almost all of the functions. The main user interface in MVS systems is TSO (Time Sharing Option). The Interactive System Productivity Facility (ISPF) is a set of menus for compiling and managing programs and for configuring the system. The main work management system is either Job Entry Subsystem 2 or 3 (JES2 or JES3). Storage (DASD) management is performed by DFSMS (Distributed File Storage Management Subsystem). MVS is considerably more complex and requires much more education and experience to operate than smaller server and personal computer operating systems.

The Virtual Storage in MVS refers to the use of virtual memory in the operating system. Virtual storage or memory allows a program to have access to the maximum amount of memory in a system even though this memory is actually being shared among more than one application program. The operating system translates the program's virtual address into the real physical memory address where the data is actually located. The Multiple in MVS indicates that a separate virtual memory is maintained for each of multiple task partitions.

Other IBM operating systems for their larger computers include or have included: the Transaction Processing Facility (TPF), used in some major airline reservation systems, and VM, an operating system designed to serve many interactive users at the same time

VSAM

VSAM is a high-performance access method used in the MVS, OS/390 and VSE/ESA operating systems. It was initially released by IBM in 1973 and is part of the Base product.

VSAM provides a number of data set types or data organization schemes. They are:

  • Key-sequenced data set (KSDS)
  • Entry-sequenced data set (ESDS)
  • Relative record data set (RRDS)
  • Variable-length relative record data set (VRRDS)
  • Linear data set (LDS)

Installations have been using VSAM data sets to hold more and more of their data to the point where many have reached the 4-gigabyte architectural limit for the size of VSAM data sets. Beginning with DFSMS V1.3, you can create and use VSAM KSDSs that can be much larger than the 4-gigabyte limit imposed on any VSAM data set defined before this release. DFSMS V1.5 allows non-KSDS file types (ESDS, RRDS, VRRDS and LDS) to exceed 4 gigabytes.

VSAM record-level sharing (RLS) was introduced to provide the value of the Parallel Sysplex to the existing applications. RLS itself does not provide transactional recovery. CICS provides a file access interface on top of VSAM. It is a CICS file control function that includes transactional recovery for VSAM files. This isolation and rollback capability enables VSAM data to be shared among CICS applications.

'


Ads By CbproAds