1. Copyright © 2002 VERITAS Software Corporation. All rights reserved
Copyright © 2002 VERITAS Software Corporation. All rights reserved. VERITAS, the VERITAS logo, and all other VERITAS product names and slogans are trademarks or registered trademarks of VERITAS Software Corporation. VERITAS and the VERITAS Logo Reg. U.S. Pat. & Tm Off. Other product names and/or slogans mentioned herein may be trademarks or registered trademarks of their respective companies.

2. Solving Real World DB2 Challenges Availability, Performance and Manageability
Dhiren Patel
Technical Product Manager
Storage Foundation for DB2
VERITAS Software
Rahul Kitchlu
DB2 Strategy and Planning
IBM
Introduce yourself
Would be good if you mentioned your IBM experience
Tell any good/funny stories you have

3. VERITAS Software Today
World’s Largest Storage Software Company
$2.1B Revenues
8700+ Employees
39 Countries
24x7x365 Global Support
99% Of The Fortune 500 Run VERITAS Software
Level setting slide to make sure everyone in the audience knows how big/successful we are.
Many DBAs particularly DB2 DBAs might not know a lot about VERITAS. Those that have heard of use have likely only heard of NBU.
I often mention the $2B+ cash we have in the bank, we are going to be around for the long haul, there is no risk in buying VERITAS!

4. Why is VERITAS here? To show DB2 is a strategic platform for VERITAS
Present the value we add to a DB2 environment
Availability
Performance
Manageability
Announce our new LINUX Solutions for DB2
This is the agenda slide
During the presentation, we will address the three major points.
The bulk of the presentation is in the 2nd section, the DB2 specific piece

5. VERITAS Commitment to DB2
Solving Real World DB2 Challenges
VERITAS Commitment to DB2

6. VERITAS Solutions for DB2 UDB
Increased Storage Availability and Manageability
Increased Database Availability and Manageability
Optimizing Performance for DB2 Across Architectural Tiers
Protecting Critical Data stored in a DB2 Database
VERITAS
Storage
Foundation
for DB2
VERITAS
Cluster
Server for DB2
VERITAS
NetBackup
for DB2
VERITAS
Indepth for DB2
There are 4 main solution areas from VERITAS that support DB2
Storage Foundation for storage management
VCS for server/database management
Indepth for performance management
Netbackup for Data Protection

7. VERITAS and DB2 VERITAS Storage Foundation validated by IBM
Solaris, AIX and Linux
VERITAS / DB2 technology integration
Availability
FlashSnap, automatic quiesce/resume of DB2
Cluster Server and NetBackup agents for DB2
Performance
Concurrent I/O (CIO)
Indepth for DB2 with DB2 Design Advisor
Our Storage Foundation software has been validated by IBM on Solaris, AIX and Linux.
The link is a pointer to IBM’s webpage that shows our Linux validation, we have validation certificates for AIX and Solaris as well.
The second major bullet highlights places where we have true software level integration.
Transparent Quick I/O (aka Concurrent I/O) is a new feature in Stinger (DB 8.2) and also in our AIX 4.0 release. This was a joint engineering effort.
Indepth, Flashsnap, and VCS pieces were done by us, but they are integrated with DB2. I.e. VCS knows exactly which processes to look for to make sure DB2 is running. It also knows how to start and stop DB2 insatances

8. VERITAS and DB2 Continued VERITAS/IBM collaboration
Joint DB2 testing and integration at DB2 Toronto Labs
Joint Whitepapers - DB2 HA, Replication, etc.
Joint DB2 Benchmark with NetBackup
IBM Customer Benchmark Center in Montpellier, France includes VERITAS Solutions
DB2 Solutions highlighted at VERITAS Briefing Center
More examples of our integration with DB2
Uli has an office in Toronto, and is a good integration point between the teams.
We have done several joint whitepapers (co-branded by IBM and VERITAS)
Vesna installed SF for DB2 during here trip to France
Again, the point of this slide is to show the high level of commitment that we have to the DB2 market.

9. VERITAS Storage Foundation for DB2 UDB
Solving Real World DB2 Challenges
VERITAS Storage Foundation for DB2 UDB

10. What is VERITAS Storage Foundation for DB2?
Host based storage virtualization software optimized for DB2 UDB
Layer between database (or application) and storage.
Provides
Point-in-time Copies
Improved performance
Storage Mapping
Tiered storage
Storage Provisioning, Online administration and much more
High Availability through the integration with VERITAS Cluster Server

11. VERITAS Storage Foundation for DB2 Architecture
DB2 Manager
Storage Foundation for DB2
VEA or CLI
I/O operations
Storage Mapping
VCS and VCS DB2 Agent
VERITAS File System -Storage Checkpoint, CIO, QIO, PDC, MVS, etc
VERITAS Volume Manager – Volume Snapshots, DMP, etc
DB2 Database
Availability
Performance
Manageability

12. FlashSnap Point-in-time Images
File System based  Storage Checkpoints
Volume Manager based  Volume Snapshots
Application Integration with Point-in-time Images
Databases
Backup
Point-in-time copies (PITC) enable you to capture an image of a database or file
system at a selected instant for use in applications such as backups, decision
support, reporting, and development testing.
Point-in-time copy solutions may additionally be configured for off-host
processing to remove much of the performance overhead on a production system.
A variety of technologies are used to create point-in-time copies. All the
technologies involve “readying” the file system or application by putting it into a
consistent state.
Availability
Performance
Manageability

13. File System - Storage Checkpoint
Persistent File System point-in-time image
Space Optimized
Keeps track of changes in File System blocks
Flexible Management
Available on-line
Enables Storage Rollback
Availability
Performance
Manageability

14. File System Storage Checkpoint Internals
Pre-Checkpoint FS
Checkpoint created
/ckptfs/foo.txt
A B C D E F G H
Logical
/foodir/foo.txt
A B C D E F G H
Physical
/foodir/foo.txt
A B C D E
F G H
Availability
Performance
Manageability

15. File System Storage Checkpoint Copy on First Update
File is being updated
Checkpoint shows original data
Logical
/foodir/foo.txt
/ckptfs/foo.txt
A B C D E F G H A’
A B C D E F G H
Physical
/foodir/foo.txt
/ckptfs/foo.txt A
A B C D E A’
F G H
Availability
Performance
Manageability

16. Standard DB2 Recovery from Backup
Full DB2
Backup
Did you drop a table by accident?
Time 0:00
12: :00
15:00
Transactions
If you only have tape backup for protection you are at risk of a long outage
If an error occurs at 3 in the afternoon, you have to go back and restore from the nightly backup and then replay the transaction logs. The entire process (both tape based restore and replay logs) is a very time consuming process. It’s possible that this process could take several hours to recover.
The example that is highlighted (dropped table) is one that many DBAs have experienced. It’s a common type of logical corruption.
Restore from backup
Reapply transactions 00: :59
Back in service
Availability
Performance
Manageability

17. Integrated, Instant Recovery with VERITAS Storage Rollback
Full DB2
Backup
Storage Checkpoints - on-disk, file system-based images
Time 0:00
10: : : :00
15:00
Transactions
Storage checkpoints greatly simplifies the recovery process.
We have a scheduler built in so you can for example, arrange a checkpoint every other hour.
When an outage occurs (dropped table) it easy to rollback to the checkpoint. This is part of the demo.
Also, a much smaller number of transactions need to be replayed.
The recovery in this scenario is minutes (as opposed to hours)
Checkpoints address the majority case (logical outages) for unplanned downtime.
We also show how to use this with PDC later, to perform a quick disk based backup.
Restore from last checkpoint
Reapply transactions 14: :59
Great protection from logical corruption
(80% unplanned downtime)
Back in service - fast
Availability
Performance
Manageability

18. Off-Host Processing with Volume Snapshots
VERITAS FlashSnap
DSS, Reporting, Testing, Backups without impacting production
Periodic, Storage-based
Little on-going CPU overhead, it won’t slow your transactions down!
Fast Resync, in either direction
Integrated with DB2
Hardware Independent
Create snapshot
Break off copy
Import on secondary
Database
Database
Mirror
Database Snapshot
Performance on the primary database server can be significantly degraded by routine tasks such as backup and running decision support queries.
If it was possible to off-load these tasks to a replica of the primary server, its performance could increase dramatically.
To avoid excess overhead on the network, just passing changed data at the block level could dramatically cut down on the amount of data passing over the network. VERITAS can do this today.
This can be done today by taking snapshots of the file system that have the ability to track what blocks have changed in real time. Then the database on the primary is quiesced and the changed blocks are passed to the replica where they are resynchronized. Users can continue to access their data on the primary as if nothing occurred.
VERITAS FlashSnap is an option of VSFW. It includes several technologies that together enable users to perform certain operations with minimal impact to the applications or users. The snapshot functionality is enabled with VERITAS FlashSnap. It allows a point in time copy of data to be created. This copy may be mounted to the same host or may be moved to another host for off-host processing.
Today volumes can only reside in the diskgroups they were created in. If you decide to reorganize the diskgroup, there is no easy method that is available. The Dynamic Group Split and Join feature of FlashSnap addresses this. This technology enables users to split a mirror from a server and join the disk group to another server. This will allow users to deport a split mirror to another host to offload operations such as backups or decision support from the production server. The disk group can then be imported back into the production machine.
FlashSnap supports up to 32 (the original volume plus 31) concurrent copies of data. These may be mounted on different hosts and all changes to all copies of the data are tracked so that once you require a data copy to be brought up to date, it may be resynchronized to the primary or production copy of the data quickly with little overhead at the disk or the host.
FlashSnap is hardware independent, allowing you to leverage current investments in storage and giving you the freedom to easily make changes in storage in the future. FlashSnap allows your point in time copies to span multiple storage subsystems so that I/O loads are shared throughout your environment.
Availability
Performance
Manageability

19. Volume Snapshots Start Original Volume Snapstart Snapshot
Refresh on Snapback
Original Volume
Snapshot Mirror
Snapshot Mirror
Snapshot Volume
The vxassist snapstart command creates a mirror to be used for the snapshot, and
attaches it to the volume as a snapshot mirror. (The vxassist snapabort command can
be used to cancel this operation and remove the snapshot mirror.)
When the attachment is complete, the vxassist snapshot command is used to create a
new snapshot volume by taking one or more snapshot mirrors to use as its data plexes.
The snapshot volume contains a copy of the original volume’s data at the time that you
took the snapshot. If more than one snapshot mirror is used, the snapshot volume is itself
mirrored.
The command, vxassist snapback, can be used to return the snapshot plex to the original volume from which it was snapped. The snapback operation will resynchronize the full snapshot mirror with the data on original volume even if the only small amount of data is changed. The full resynchronization of the snapshot mirror is slower process.
For example, this enables you to refresh the data in a snapshot after each time that you use it to make a backup.
As described in “FastResync” on page 41, you can use the FastResync feature of VxVM to minimize the time needed to resynchronize the data in the snapshot mirror. If FastResync is not enabled, a full resynchronization of the data is required.
Snapback
Availability
Performance
Manageability

20. Configure the storage required for database FlashSnap
FlashSnap – Integration with DB2
Configure the storage required for database FlashSnap
Primary Host
Secondary Host
dbed_vmchecksnap
Modify and validate the storage and snapshot plan
Import snapshot disk group to the primary host and resync the snapshot mirror
dbed_vmsnap
dbed_vmsnap
Create volume snapshot of the database
Shut down the clone database and deport the snapshot disk group
dbed_vmclonedb
dbed_vmclonedb
Import snapshot disk group on the second host and start the database
Clone database available for off-host processing
Availability
Performance
Manageability

21. DB2 Storage Checkpoints, Rollback and FlashSnap
D E M O N S T R A T I O N
DB2 Storage Checkpoints, Rollback and FlashSnap
Start Checkpoints
Start FlashSnap
Introduce Vesna
She will run through the two demos.
The demos are a series of screenshots, captured in Flash.
If people want to see the real software in action, they should come to the VERITAS booth.
Availability
Performance
Manageability 1 38 2

22. Storage Foundation/HA for DB2
VERITAS Cluster Server DB2 agent
Proactive monitoring and automatic failover
No scripting required
Very easy to use, both GUI and CLI
Come to the VERITAS booth for demo!!
Role Based Administration DBAs can see the status!
Little/No Consulting Required to Install and configure
VERITAS Cluster Server Supports 7.X, 8.1, 8.2, EE, EEE-SMP, EEE-MPP, Solaris, AIX, and Linux
No we extend the SF offering by including VCS
One of the main customer benefits of VCS is its easy of use.
It has a pre-built agent that knows how to start, stop and moniter DB2. This avoids the scripting that is required with HACMP.
VCS also has role based administraion, so even if the system admins control clustering, the DBA can get a read only login to see what is happening. This can facilitate troubleshooting.
VCS support all flavors of DB2, on several OS.
We are still in the testing/validation pahse with stinger, but expect to be able to support it shortly (a few weeks)
Availability
Performance
Manageability

23. VERITAS / IBM Collaboration
Solving Real World DB2 Challenges
VERITAS / IBM Collaboration

24. Fast DB2 failover using CVM/CFS
DB2 Database
Network
Card IP
Address
Network
Card IP
Address
DB2 Database
Network
Card
DB2 Database IP
Address
DB2 Database
Network
Card IP
Address
Network
Card IP
Address
DB2 Database
Cluster File
Systems
Cluster
Volumes
Physical
Disk
Cluster File
Systems
Cluster
Volumes
Physical
Disk
Cluster File
Systems
Cluster
Volumes
Physical
Disk
ANIMATED SLIDE
Different to the first example there are now two different service groups.
Parallel Service Group (green)
All storage resources in a clustered version:
- Physical Disks in a SAN environment
- Cluster Volume Manager
- Cluster File System
Failover Service Group (blue)
All DB2 related resources:
- Network Card - OnOnly because it can be uses by multiple applications / service groups
- virtual IP for transparent network client access
- DB2 resource
Joint IBM/VERITAS Whitepaper available at:
ftp://ftp.software.ibm.com/software/data/pubs/papers/db2vrtsha.pdf
Availability
Performance
Manageability

25. Fast DB2 failover using CVM/CFS
Significant reduction of failover time using VERITAS Cluster Server
Observed a 35% improvement in failover time
Fast failover using Clustered File System
Observed up to an 86% improvement in failover time
No significant DB2 performance tradeoffs for clustered file systems
Key Highlights from Failover Tests:
1st Series:
The first series of tests focused on minimizing the standard DB2 UDB database recovery time and optimizing VERITAS Database Edition / HA for DB2 and associated VERITAS Cluster Server agent for DB2 UDB detection of a system fault.
Our tuning modifications of the default DB2 UDB and VERITAS Cluster Server parameters resulted in approximately 35% faster failover time (reduced from 61 to 40 seconds) for a database on two file systems, without compromising the database performance.
2nd Series:
In the second series of tests, we examined the impact of various storage configurations on the failover time following a system failure.
Using VERITAS Database Edition / HA for DB2 in conjunction with VERITAS Cluster Volume Manager and VERITAS Cluster File System (CVM/CFS), we were able to reduce failover time by up to 86%, thereby providing DB2 UDB recovery that was more than 7 times faster than the solution without CVM / CFS.
Failover times remained constant using the components itemized above, regardless of the number of file systems (ranging from 2 to 86), DB2 UDB data containers or control files used in the tests.
These test results clearly indicate that VERITAS Database Edition / HA for DB2 with VERITAS Cluster Volume Manager/Cluster File System provides fast, consistent failover capabilities for even very large and complicated storage configurations.
3rd Series:
For the final series of tests, we leveraged the hot standby feature of DB2 UDB by starting the instance database manager on the standby host before the failover occurred.
Using two modified Cluster Server Agents, we reduced the failover time for all the various storage configurations by approximately 10 seconds. In the clustered storage primary pre-set case, the total failover time was improved by almost 40%.
The fastest DB2 UDB failover time achieved was 19 seconds. As with our 2nd series of tests mentioned above, this fast failover capability could be consistently reproduced for a variety of clustered storage configurations, independent of the number of file systems and container files.
Availability
Performance
Manageability

26. Disaster Recovery for DB2 Using VERITAS Volume Replicator (VVR )
VVR provides Synchronous as well as Asynchronous replication
White Paper
ftp://ftp.software.ibm.com/software/data/pubs/papers/db2-vrts-rep.pdf
Describes the implementation and design of a replication solution
Guidance and best practices are provided for replication and off-host processing
Availability
Performance
Manageability

27. Enhance DB2 offerings - HADR
Offsite Disaster Recovery
Target Market
Online commercial applications
Challenge
24 x 7 Availability
Failover in seconds
Disaster recovery
Solution : HADR
Single solution handles
Ultra-fast failover
Local and remote site recovery
Value
Business continuation
Tight integration; Very simple to use
Toronto
Portland
HADR
Primary
Standby
Standby
HTTP & App.
Database
Database
HTTP & App.
Servers
Server
Server
Servers
Onsite Hot Standby
HADR = High Availability Disaster Recovery
Delivered in V8.2 (V8.1 FP 7)
Basic Principles of HADR
Two active machines
Primary
Processes transactions
Ships log entries to the other machine
Standby
Cloned from the primary
Receives and stores log entries from the primary
Re-applies the transactions
If the primary fails, the standby can take over the transactional workload
The standby becomes the new primary
If the failed machine becomes available again, it can be resynchronized
The old primary becomes the new standby
Automatic Reroute
HADR
Client
Application Server
Standby Database
Server
Primary Database
Server
Availability
Performance
Manageability

28. Enhance DB2 offerings - HADR
Current HADR Limitations
No access to Standby database
Solution – SF
Instant, space optimized volume snapshot
Fully accessible snapshot copy of the standby database available for off host processing
No automated failover
Solution – VCS
Agent to detect failover required and trigger the action
There are a few restrictions with HADR
Currently, you can not connect to the standby database and the failover is not automated
Integrating with VERITAS technology can provide this functionality
With the release 4.0 of VERITAS Volume Manager (VM) a new feature called instant, space optimized volume snapshot was introduced. Now multiple, single point in time copies of the replicated storage can be created with only a small amount of additional disk space. Combining HADR replication with volume snapshots is like merging the concept of continuous storage replication with periodic log shipment / database roll-forward technologies. Thus a solution whereby a fully accessibly copy of the standby database is available.
To Automate the failover in a HADR setup – changes to the VCS agent are required
This work is currently in progress – will have whitepapers
Availability
Performance
Manageability

29. DB2 Direct I/O Support in 8.2
NO FILE SYSTEM CACHING enables Direct I/O for particular tablespaces
CREATE/ALTER TABLESPACE  recommended
Surest way to determine which is in effect is to use tablespace snapshot
CREATE TABLESPACE <tablespace name> NO FILE SYSTEM CACHING
ALTER TABLESPACE <tablespace name> NO FILE SYSTEM CACHING
Tablespace name = TS1
Tablespace ID = 3
Tablespace Type = Database managed space
Tablespace Content Type = Any data
Tablespace Page size (bytes) = 4096
Tablespace Extent size (pages) = 32
Automatic Prefetch size enabled = Yes
Buffer pool ID currently in use = 1
Buffer pool ID next startup = 1
File system caching = No
GET SNAPSHOT FOR TALBESPACE ON <dbname>
Tablespace Page size (bytes) = 4096 …
File system caching = No
Availability
Performance
Manageability

30. VERITAS Concurrent I/O Manageability with Performance
In the past, you had to choose
one or the other
Setup DB2 to run on a
file
Setup DB2 to run on a raw device
Simplified database manageability
Simplified growth
Simplified backup/restore
Direct writes to disk
Eliminate locking
Could be a slight advantage in AIX environments…certainly no disadvantage in AIX with Concurrent I/O…you’re getting all the performance benefits plus easier manageability…no need to rename the file extensions…we’ve integrated our Files System with AIX Concurrent I/O API in lieu of JFS and take advantage of DB2’s Direct I/O benefits, which bypass our file system cache.
**competitive benefits are still there in Solaris and Linux environments…in AIX, point out the integration that was done with them and that we won’t lose on performance to JFS…***
Now you can have both using Concurrent I/O
Availability
Performance
Manageability

31. Storage Mapping VERITAS Storage Mapping services
Allows DBA to drill down the I/O stack from database containers to physical disks (including LUN-to-disk inside storage arrays such as IBM, EMC and HDS)
Display consolidated statistics
Availability
Performance
Manageability

32. Storage Mapping Find the data and eliminate hotspots
Where does the table reside?
Map database objects down to the spindle
I/O statistics provided for each layer
Tablespace
File System
Volume
LUN
Disk
Lets start with the Application Performance Management solution. Precise “I Cubed”.
A user initiates a transaction.
If you are running screen show, hit enter.
Precise INDEPTH™ traces/logs a transaction from the user through the various levels of the application infrastructure (from web, application, and database servers all the way to storage devices). It isolates performance degradation/bottlenecks at any point in the “maze”.
If you are running screen show, hit enter again.
If a performance issue has been identified, Precise INFORM™ alerts administrators and suggests corrective actions. This allows businesses to proactively resolve potential service issues and deliver consistent and committed quality of service.
Precise INSIGHT™ focuses on user experience of service, and delivers end to end application performance management
SEGUE: Lets take a look at the specific application performance products that Precise has to offer in more detail… (move to next slide)
Availability
Performance
Manageability

33. Storage Mapping
Availability
Performance
Manageability

34. D E M O N S T R A T I O N
DB2 Storage Mapping
Start 1 38 2

35. Tiered storage 80% of data is inactive Option:
Keeping it is too expensive
Archiving it is too drastic
Option:
Move it to another tier of storage
Traditional Solution
VERITAS Solution
INTRODUCTION:
I want to talk frankly about the truth of tiered storage.
Tiered Storage goes by many names, ILM, DLM, Migration, Archiving, etc.
All working on the same problem:
PROBLEM:
80% of data is inactive (analyst and customer reports)
Keeping data on expensive storage is expensive
Sending it off to tape is the only option available today, but it’s too drastic
RECOMMENDATION:
ADVANCE SLIDE
Move to another tier
Not new concept
Few vendors are actually shipping something
VERITAS Unique approach that doesn’t require new technology
Use the file system
Feature called QoSS
BENEFIT:
Critical data on Tier 1 Storage
Less critical data on lower tiers of storage
No change to the way users access those files
PROOF:
Traditional solutions make it difficult to separate critical and stale data outside of a single file system
VRTS uses the a single file system to span multiple volumes
Moves the data around within that file system
In fact, that’s a file system’s Job! Map physical location to logical name, therefore, the FS is the most logical place to do it!
TRANSITION
Tiered storage not just about moving files to different storage devices
Also concerned with larger blocks of data such as mirrors and snapshots
One of the major issues with snapshots is that they require two or three times the storage space
NOTES
Common Questions Regarding QoSS:
Does it work with Windows? Not currently. QoSS requires both a file system and a volume manager. Storage Foundation for Windows does not include a file system at this time. We’re working to try and find alternatives to this situation.
What policies can I use to migrate data? Basically, anything the file system is aware of such as the time it was last accessed, the size of the file, the name of the file, the directory of the file, the owner of the file, etc.
Does it work with databases as well? Certainly. Any file can be migrated. It does not, however, migrate individual cells within a single database file.
Is it done online? Yes, completely online.
Resources for more information:
QoSS Whitepaper (
Availability
Manageability
Performance

36. Heavily Used DB2 Container
Implementing Tiered-Storage for DB2 Migrate Files to Improve Utilization
Heavily Used DB2 Container
Rarely Used DB2 Container
Rarely Used DB2 Container
File System
File System
File System
50%
90%
25%
60%
Again, it is transparent to user since the path and file name information is not changed.
VERITAS is the only company that can do this since we have a multi-volume file system.
Today, DB2 granularity is at file level…sub file level with future release. Also keep in mind that QoSS would require a very brief “off line” of the file; I.e. few seconds. NOTE: database would be in write/suspend mode but doesn’t require the database to be shut down…
We didn’t think that the log file example would be the most practical, however, given that it’s recommended that users keep their data files and log files on separate file systems, therefore we used the example of heavily used and lightly used DB2 containers (files).
Talk about using QoSS to speed up performance as well…I.e. moving a busy index table to another volume within the same file system…
EMC Symmetrix $$$ per GB
SATA $ per GB
Availability
Manageability
Performance

37. How it Works: Disk to Disk
VERITAS Storage Foundation
Create two or more Volumes
Group Volumes into Volume Set
Create a File System on Top of Volume Set
Set and Run Relocation Policies
VERITAS File System
Availability
Performance
Manageability

38. VERITAS for DB2 DB2 is a strategic platform for VERITAS
We add value to a DB2 environment
Enhancing Availability, Performance, Manageability
Infrastructure to application
Integration with DB2
Announce LINUX Solutions from VERITAS
Summary of agenda / presentation

39. Your Next Steps Come by the VERITAS booth for:
Demos of Storage Foundation and Indepth for DB2
Free trial software CDs
Independent product evaluation papers from DB2 experts
Visit VERITAS Architect Network (van.veritas.com)
DB2 eBook featuring chapters from leading DB2 experts
DB2 Technology Zone
White papers and full documentation

40. &
QUESTIONS
ANSWERS