 | Level: Introductory Paul Zikopoulos (paulz_ibm@msn.com), Senior Database Specialist, IBM
14 Dec 2006
Updated 15 May 2008 Are you trying to ensure you're licensing your IBM® DB2® Version 9.5 for Linux®, UNIX®, and Windows® (DB2 9.5) data servers correctly in a high availability environment? Don't have the time nor the will to read through the announcement letters, PLETs, or your licensing sheets? Author Paul Zikopoulos explains it all in plain English and covers some importants changes in DB2 9.5 too!
Customers choose the IBM DB2 data server because of its incredible time to value, its ability to scale and integrate across disparate environments, its robustness, and for the minimization of 'down-time' (both planned and unplanned). In this article, I focus on the high-availability aspects of DB2, not so much from a functionality point of view (of which much has been written), but from the point of view of licensing.
I hear a lot of questions about licensing DB2 in a high availability (HA) environment -- configurations that are designed to address unplanned outages (and sometimes planned ones too). Usually the first level of confusion is caused by wide variations in how different vendors price their database products in high availability environments.
Another level of confusion centers on the terms used in discussions that relate to high availability. For example, the term clusters. Sometimes the IT industry refers to highly available environments as clusters. I don't like using this term by itself anymore, as it has become somewhat overloaded as of late in that clusters can refer to clustering for scalability (like the DB2 database partitioning feature - DPF) or clustering for availability (for example, using DB2 9.5's built-in Tivoli System Automation (TSA) clustering feature on a group of servers). Despite not liking the term, it's used; so for this article, when referring to the term cluster, I mean clustering for high availability (unless otherwise noted). For simplicity, I recommend you prefix the term cluster with high availability or scalability when discussing clusters with your clients or colleagues.
Another source of confusion arises from the terms used to describe the server that acts as the failover server in the event of an outage. For example, this server may be referred to as a standby or secondary server (among other names). If you've been around long enough, you've likely run the gambit of terms describing the function that this one server performs. These terms include: idle, active, cold, warm, hot, and passive.
For the most part, IBM Software Group (IBM SWG) literature uses the cold, warm, and hot taxonomy to describe standby servers. Before DB2 9.5, things in "DB2-land" were a little different. DB2 8 and DB2 9 used the terms idle and active to describe a standby data server. As a result, DB2 8 and DB2 9 had pricing and licensing terms that didn't map to IBM SWG terms and this caused some confusion for clients licensing a blue stack for high availability.
The good news is that DB2 9.5 now conforms to the IBM SWG taxonomy and licensing terms with respect to high avaiability pricing. For example, if you configured a DB2 9 data server in a high availability cluster like HACMP such that one server sat idle (and not started), you would have to partially license that server. In DB2 9.5, this would no longer be the case. If you had DB2 installed on a server that was powered off in DB2 9, you had to partially license that server too. In DB2 9.5, you don't pay for a DB2 license on a data server that isn't powered on. I've updated this article for the DB2 9.5 release to help you sort out DB2 high availability licensing rules and put you in-the-know.
Figure 1 gives a good description of the DB2 9.5 high
availability taxonomy and some examples of the types configurations that
fall into each category.
Figure 1. Some helpful
hints when it comes to the DB2 9.5 Hot, Warm, and Cold high availability
taxonomy
In Figure 2, I've mapped the most common terms used to describe high availability environments to the DB2 9.5 taxonomy and licensing terms:
Figure 2. Mapping industry
high availability terms to DB2 9.5 licensing terms
In the previous figure I appended a general rule of thumb below each category, but after reading this article, it will hopefully by clear.
Quite simply, how you license a DB2 server in a high-availability environment depends on your answers to these several key questions:
-
What edition of the DB2 data server do you have installed?
Is it: DB2 Express-C, DB2 Express-C FTL, DB2 Express, DB2 Workgroup, or DB2 Enterprise? For example, DB2 Express-C FTL doesn't have the concept of hot, warm, or cold for a standby server (more on that in a bit). In addition, DB2 Express-C isn't allowed to be clustered for high availability.
-
How did you license the DB2 data server that you want to ensure is highly available?
For the mainstream DB2 9.5 data servers (DB2 Express, DB2 Workgroup, and DB2
Enterprise), options include the authorized user license (as its name implies, this
follows the per end user identification methodology) and the IBM SWG processor-based metric (which follows the unlimited no need to count users methodology) called a Processor Value Unit (PVU). If you licensed DB2 Express-C FTL, the licensing methodology is per physically installed server. (If you're looking for an overview of all the distributed DB2 9 data servers and how to license them, refer to "Which distributed edition of DB2 9.5 is right for you?".)
-
How is the standby machine being used when a failure has not occurred?
For example, is it being used as a production data server for DB2 transaction and query work? Is the DB2 instance on this server started? Perhaps the instance is performing some form of work, but only to help prime a recovery in the event of a failure (for example, in an HADR scenario). Quite simply, what the standby server is doing when everything is running just fine has pretty much everything to do with how DB2 on that server needs to be licensed.
DB2 9.5 actually lowers the cost of your high availability environments because of the following changes that are explained in this article:
- You no longer have to license a cold standby machine.
- You no longer have to license feature packs on a server that is acting as a warm or cold standby server.
- DB2 9.5 comes with integrated high availability clustering software (IBM TSA for Multiplatforms) which means you don't have to buy separate clustering software to automate HADR failover or set up a simple high availability cluster.
- HADR is now included in DB2 Workgroup at no extra charge; if you look around the competitive landscape there is no other vendor that offers the same kind of functionality (there are no restrictions for the HADR technology on DB2 Workgroup) for any SMB-targeted server.
- The limit for DB2 Workgroup has been changed to 480 PVUs (from 400 PVUs); if you consider this with the last point, you can see that you're transactional workloads on a 480 PVU server got cheaper and more available. (A 480 PVU server can handle a heck of lot of transactions.)
The best place to start a discussion of the effects of high availability clusters on DB2 9.5 licensing is with examples that corrleatewith the newly introduced taxonomy. As you've seen, DB2 9.5 defines three types of standby servers:
hot
,
warm
, and
cold
.
Hot standby
A hot standby configuration is one in which all servers have independent operational DB2 databases that service user transactions and queries. This configuration is sometimes called an active/active configuration since all the machines in the cluster are performing some level of business production work at all times. If one of the servers in the high availability cluster was to fail, then clustering software would transfer that failed server's workload to a surviving server in the cluster.
If a failure were to happen, the transfer of resources would effectively double the workload on the hot standby server (the lone surviving machine in a two-node cluster) because it now has to handle its original workload plus the failed server's workload. This is something that you need to consider when setting up any highly-available environment where each server backs the other up, but also has its own service level it had to adhere to. If you are a database administrator (DBA) who's laying it all on the line for a tight service-level agreement (SLA), then this may or may not be the best choice (unless you size for it or use technolgoies that limit this impact such as Xkoto GRIDSCALE).
To summarize, in DB2, a hot standby server is any machine being used to service user transactions and queries during normal operational periods. When a failure of another server in the cluster occurs, the hot standby server takes on the load of the failed server machine in addition to the work that it was performing during normal operations. Because the active standby machine is still used for user transactions and query, even if no failure occurs, it must be fully licensed. For example, imagine having two databases on two separate machines, one running an enterprise resource planning (ERP) packaged application and the other running a supply chain management (SCM) packaged application. If the SCM database was to fail, the machine running the ERP workload would have to service all the SCM users too.
A scenario with a hot standby server is shown in Figure 3. In this example, there is a pair of servers that are both being used for transaction and query workloads during periods of normal operation (the solid boxes represent where the workload for each machine occurs before a failure, the cross-hatched boxes are where work would occur in the event of a failure of a respective machine). In our sample scenario, machine 2 fails and its workload is transferred to its failover partner, machine 1. Machine 1 is a hot standby server to machine 2 (and vice-versa when you look closely at this figure - note the cross-hatched box for machine 1 on machine 2). This type of configuration is often referred to as a
high-availability clustering pair, twin failover pair, or active/active pair and is quite common in today's IT landscape. There are many ways in which to implement an active/active high availability cluster in DB2, and depending on what you need from the solution, you can use the database partitioning feature, HADR in conjunction with a database on each server failing over to the other, HADR and Q-Replications, using an active standby for reporting via snapshot technology or disk image copies, leveraging the xKoto GRIDSCALE technology, and more.
Again, both machine 1 and machine 2 in Figure 3 were being used all along for their own transactional and query workload; when machine 2 failed, its DB2 workload was simply transferred to machine 1. Don't forget, in this case, if you did not correctly size machine 1's resources for machine 2's failed workload responsibilities (and vice-versa), you could have performance issues after an outage occurs as a result of the transfered workload.
Figure 3. Machine 1 is a hot standby for machine 2 and machine 2 is a hot standby for machine 1. Machine 2's workload fails over to machine 1 in the event of a failure.
Licensing considerations for a hot standby machine
As a general rule of thumb, an active/active configuration should be licensed in the same way you would license each server as if they
weren't clustered for high availability. The following section details the licensing considerations you should be aware of depending on how your DB2 data server is licensed.
Processor Value Unit (PVU) licensing:
For any DB2 data server that is licensed using the PVU model, the entire PVU rating of the hot standby server (machine 1 in this example) must be licensed (unless you are using sub-capacity licensing that's available for DB2 Enterprise). Of course this is how you would license such a server even if it weren't part of an HA cluster since it is servicing production work, so there shouldn't be any surprises here.
If the server in Figure 3 was a four core POWER6 server, and assuming each machine was running DB2 Workgroup which is limited to servers with a maximum PVU rating of 480, you would have to purchase a total of 960 PVUs for this solution: 480 PVUs for machine 1 and 480 VUs for machine 2. (In 2Q08, the PVU limit for DB2 Workgroup was changed from 400 PVUs to 480 PVUs to accomodate the new POWER6 processors whose per core rating is 120 PVUs; this essentially means that you can run DB2
Workgroup on a 4-core POWER6 server.
Authorized user licensing
For any DB2 server product that is licensed by the authorized user model, you must license the hot standby server by purchasing the total number of authorized users that will access it, in addition to the corresponding number of users that will access the active primary data server too (since they are both effectively primary data servers for their own applications and standby servers for each other). An authorized user is a single individual (in some cases, it can be an application or appliance so long as it doesn't act on behalf of other users) with a specific identity that resides inside or outside your company. These licenses can be used over the Internet as well (like an online banking application) because the end user is well known since they must be specifically identifiable for this license. Authorized user licenses are full entitlements; there is no need for separate server licenses as was the case with DB2 8 where you bought user entitlements along with a base server license. If you are using multiplexing or connection concentration software, these users need to be fully identified and accounted for before such technologies are applied to the counted connection.
You need an authorized user license for anyone accessing the data server. However, no matter how many users are accessing your data server, at the very least you need to license a DB2 Express or DB2 Workgroup data server with five minimum authorized user licenses and a DB2 Enterprise data server with 25 authorized users per 100 PVUs on the server. (Each 100 PVUs requires a new 25 users pack; for example, a server with 480 PVUs would require 125 authorized users since you effectively round up the PVU count for user minimum determination.) Authorized user licenses are not transferable across work shifts (though they can be transferred for employment turnover) and they are only valid for a specific data server. Of course since this example is an active/active configuration, these rules are moot since they have to be licensed like independent fully active servers.
In the example shown in Figure 3, if you had 100 users that needed to access both active DB2 Workgroup data servers, you would need to purchase a total of 200 DB2 Workgroup authorized user licenses for these 100 users: 2 servers x 100 authorized users per server. Even if only 12 of these users were ever connected to either data server at one time, all 100 users would still have to be licensed for each data server (so you still need 200 of these authorized user licenses for this example). If you were using DB2 Express or DB2 Workgroup in Figure 3, and you only had 3 users in your company, you would need a total of 10 DB2 Express or DB2 Workgroup authorized user licenses (2 servers x 5 minimum authorized users) to satisfy the minimum authorized user requirements associated with these editions of DB2.
If the data server being used in Figure 3 was DB2 Enterprise things are a little different. Continuing with the example in the previous paragraph, if you had 100 users that needed to access both active DB2 Enterprise data servers, you would need to purchase a total of 250 DB2 Enterprise authorized user licenses for these 100 users:
2 servers x 125 authorized users per server (assuming the server in our
example is a 4-core POWER6-based server which would be rated at 480 PVUs).
Again, even if only 12 of these users were ever connected to either data server at one time, all 125 users would still have to be licensed for each data server (so you still need 250 DB2 Enterprise authorized user licenses for this example). If the DB2 Enterprise data servers in Figure 3 were 2 socket Intel x86-based dual core servers, the total PVU rating for these servers would be 200 PVUs each. If you only had 3 users in your company, you would need a total of 100 authorized users (2 servers x 200/100 PVUs x 25 authorized users) to satisfy the minimum authorized user requirements associated with this edition of DB2. However, if the servers in Figure 3 were 2 socket Power5+-based dual core servers, the total PVU rating for each server would be 400 PVUs. So with this kind of server hardware, if you only had 3 users in your company, you would need a total of 200 authorized users (2 servers x 400/100 PVUs x 25 authorized users) to satisfy the minimum authorized user requirements associated with this edition of DB2.
As previously mentioned, DB2 Express-C does not support high-availability configurations. However, DB2 Express-C FTL does. When you license DB2 Express-C FTL in a high-availability environment, you don't follow the rules outlined in this section. Since DB2 Express-C is a free data server, and the Fixed Term License (the FTL part) is a support and feature contract that you can purchase, there is a different way. When you license DB2 Express-C FTL in a high availability environment you simply buy a support contract for each server in the cluster no matter what type of standby (hot, warm, or cold) it is; there is no need to identify the activity level of the server, user minimums, the value unit rating of the underlying data server, or anything else: simple!
Warm standby
A warm standby configuration is one in which at least one server in the high availability cluster does not have a DB2 database that is servicing user transactions or query workloads during periods of normal operation. It is idle in the sense that the data server is not performing "useful" work. Work that is classified as "not useful" (although ironically it could be the most useful work your standby servers ever do) includes administrative actions that assist in failover scenarios such as having a database in rollforward pending state to support log shipping, supporting transaction-level log shipping for an HADR environment, and so on. If one of the servers in the high availability cluster fails, then the clustering software transfers the workload to the warm standby data server.
One common misconception many have about a warm standby configuration is that a warm standby machine is a waste of resource when solely dedicated to recovery operations. This is an incorrect understanding of this type of configuration. The truth is that you can leverage a warm stadnby machine for many uses (both DB2 and non-DB2 related) beyond the standby role. For example, you could create a separate DB2 instance on the warm standby machine (depending what DB2-related work you choose to perform here, it could have licensing implications) and use it as a test machine, or perhaps offload other workloads and functions on it. In the event of a failure, you could scale back these workloads and allow the warm standby machine to use all of its resources to handle the load of the failed server, thereby circumventing the load considerations outlined in the hot standby discussion in the last section. Also consider a warm standby machine rolling forward through the DB2 logs, while at the same time, it is running test scenarios in another instance (or test scenarios for non-DB2 purposes - like application testing and so on). In the event of a failure, you simply queisce the test workload and let the DB2 standby assume the load of the failed server without consideration for throughput reduction.
A warm standby scenario is shown in Figure 4. In this example, during periods of normal operations, machine 2 is being used for transaction and query workloads (noted as active work in the figure), while machine 1 is sitting as an idle standby for machine 2's workload, and perhaps supporting some additional functions like application development. Machine 2 fails and its DB2 workload is passed to its warm partner machine 1. In this scenario, it would likely be the case that if any work (of any kind) was being performed on machine 1 before the failure, it would be scaled back to handle the new workload after the failure of machine 2 (or machine 1 was originally sized to support its workload and machine 2's workload at the same time - otherwise you'll see a performance issue).
Since during periods of normal operation, only one machine is hot from a DB2 perspective in Figure 4, while the other is doing some warm activity like priming an HADR failover partner, this configuration is often referred to as an active/idle. The important concept to note here is that machine 1 wasn't doing any "meaningful" DB2 work before the outage occurred.
Figure 4. Machine 2's workload is transferred to the warm standby server, machine 1
Depending on your availability requirements, workload, and so on, a warm standby may or may not be the right choice for your environment; however, when planning for the kind of standby you want to support, never forget why you have a high availability environment in the first place - to minimize the mean time to repair (MTTR) from an outage. The point is that DB2 has options for active/active as well - and the notion that an idle standby server (from a DB2 perspective) is just sitting around wasting resources is an often very misunderstoond notion.
Licensing considerations for a warm standby machine
Processor Value Unit (PVU) licensing:
For any DB2 data server that is licensed using the PVU model, you license a warm standby server for 100 PVUs no matter what kind of processing core architecture the server is based on. In other words, the fact that a server with a four dual core AMD processors equates to 400 PVUs and a server with four dual core POWER6 processors to 960 PVUs VUs (and trust me, it will more than double the performance of previous server), with a warm standby server, you just license it with 100 PVUs of the corresponding DB2 edition.
If the server in Figure 4 was again a four core POWER6 server, and assuming each machine was running DB2 Workgroup which is limited to servers with a maximum PVU rating of 480, you would have to purchase a total of 960 PVUs for this solution: 480 PVUs for machine 1 and 480 VUs for machine 2. (In 2Q08, the PVU limit for DB2 Workgroup was changed from 400 PVUs to 480 PVUs to accomodate the new POWER6 processors whose per core rating is 120 PVUs; this essentially means that you can run DB2
Workgroup on a 4-core POWER6 server.
Authorized user
For any DB2 server product that is licensed by the authorized user model, you must license the warm standby server by purchasing the minimum number of authorized users for that edition in consideration of it being a warm standby server. For DB2 Express and DB2 Workgroup, since the minimum number of authorized users you must license is 5 for the physical server, a warm standby server would require five authorized user licenses. In the example above, if one DB2 Workgroup server was hot and was configured to participate in an active/idle cluster, and you had 100 users, you would need to purchase a total of 105 DB2 Workgroup authorized user licenses for these 100 users: 100 authorized users + 5 authorized users for the warm standby server. (Of course the minimum number of authorized user licenses for the hot server needs to be met if the number of users is less than this number.)
If the data server being used in Figure 4 was DB2 Enterprise, you would have to purchase 25 authorized user licenses for the warm standby server because in the PVU model, you only license 100 PVUs for a DB2 Enterprise warm standby server and this equates to 25 authorized users in consideration of the minimum number of DB2 Enterprise authorized users per 100 PVUs.
Continuing with the example illustrated in Figure 4, if the
servers in Figure 4 were two socket Intel x86-based dual core
servers, the total PVU rating for the hot server would be 200 PVUs. If you only had three users accessing the hot DB2 Enterprise data server, you would still need a total of 75 authorized users for this configuration: (200/100 x 25 authorized users) for the hot server + 25 authorized users for the DB2 Enterprise warm standby server. However, if the servers in Figure 4 were two socket POWER6 dual core servers, the total PVU rating for the hot server would be 480 PVUs. If you only had three users accessing the hot DB2 Enterprise data server, you would still need a total of 150 authorized users for this configuration: (480/100 rounded up is 5 x 25 authorized users for the hot server) + 25 authorized users for the DB2 Enterprise warm standby server; notice the user licensing required for the warm DB2 Enterprise server isn't associated with the PVU rating of the underlying procesor architecture.
As previously mentioned, DB2 Express-C does not support high-availability configurations. However, DB2 Express-C FTL does. When you license DB2 Express-C FTL in a high-availability environment you don't follow the rules outlined in this section. Since DB2 Express-C is a free data server, and the Fixed Term License (the FTL part) is a support and feature contract that you can purchase, there is a different way. When you license DB2 Express-C FTL in a high availability environment, you simply have to buy a support contract for each server in the cluster no matter what type of standby (hot, warm, or cold) it is; there is no need to identify the activity level of the server, user minimums, the value unit rating of the underlying data server, or anything else: simple!
Cold standby
A cold standby configuration is one in which at least one server in the cluster does not have a DB2 database that is servicing user transactions or query workloads during periods of normal operation, it isn't performing any administrative actions that assist in failover scenarios such as having a database in rollforward pending state to support HADR; in fact, it may not even be powered on.
A cold standby scenario is shown in Figure 5.
Figure 5. Machine 1 is a cold standby server for Machine 2
In this example, during periods of normal operations, machine 2 is being used for transaction and query workloads (noted as active work in the figure), while machine 1 doesn't have a started DB2 instance. Perhaps machine 2 is turned off, but DB2 is installed and in the event of a failure, Machine 1 is booted up, recovered to a certain point in time from a backup image and opened up for user trasnactions. It could also be the case that Machine 1 is configured to be part of a TSA high availability cluster, but the database instance isn't started. As you can imagine, a cold standby configuration isn't much of an availability solution in that the MTTR is typically going to be a heck of a lot longer than a hot or warm standby configuration; that said, it may suit your needs and if it does, the cost of this solution gets cheaper in DB2 9.5 for a number of reasons.
As previously mention, there are some environments where a cold standby server is appropriate. Typically, I recommend clients create multi-tier classifications for applications that require availability; for example, Copper, Silver, and Gold ratings. Perhaps it's the case that anyting rated Copper would leverage a cold standby while a Silver rated solution a hot configuration, and a Gold rated solution a hot or warm standby. Did that last sentence catch you off guard. In my opinion, if I needed the most availability possible, I would leverage a warm solution with HADR. By having a dedicated server, you're likely (but not always) to experience better mean time between failure (MTBF) and MTTR times than if you loaded the standby machine in a hot configuration (unless you've appropriately sized for it). Of course I put hot in the gold category because you could leverage technology like Xkoto GRIDSCALE.
Licensing considerations for cold standby machine
As of DB2 9.5, a cold standby server doesn't need to be licensed and therefore there are obvioulsy no licensing considerations. A good rule of thumb to determine if a standby machine can be classified as cold is to see if the DB2 instance is started; however, there are some exceptions. For exampple, if you took a snapshot image off of a production server and started the DB2 standby data server for the sole purpose of performing a backup, then stopped it, we would consider that a cold standby and no license for that server would be required.
So here is a perfect example how the new high availability licensing rules in DB2 9.5 are going to save you money. Let's assume you were licensing a DB2 9 environment using a feature pack. In DB2 9 you would have to fully license the hot server (as expected); in addition, the cold server would have to be licensed for 100 PVUs of the DB2 edition you are using and the feature pack. In DB2 9.5, you would just license the hot server as there is no charge for a cold standby and you don't license feature packs for availability purposes in hot/warm or hot/cold high availability clusters.
High availability pricing with HADR
When HADR is used in a high availability configuration, the standby server must be licensed as a warm or hot server (depending on if you've set up a twin HADR failover scenario).
As of DB2 9.5, HADR is included in DB2 Workgroup (it's always been a part of DB2 Enterprise). In DB2 9, the only way you could add HADR to a DB2 Workgroup data server was purchasing the High Availability Feature Pack for both the production and the standby servers! Well you no longer have to do this as of DB2 9.5, so that will save you a good amount of money: you just license the DB2 Workgroup standby server as a warm server and follow the guidelines above.
In addition, you still have to purchase the DB2 High Availability Feature Pack if you want to use HADR on a DB2 Express data server; however, as of DB2 9.5, you no longer need to license the High Availability Feautre Pack on the standby machine unless you are using that machine as a hot standby within an HADR twin cluster.
Finally, DB2 Express-C FTL has always allowed you to set up a high availability cluster using HADR; there are no licensing considerations for this configuration, simply buy a support contract for each server where you install DB2 Express-C FTL.
Resources Learn
- "Compare the distributed DB2 9.5 data servers"
(developerWorks, March 2007): In a side-by-side comparison table, author Paul Zikopoulos makes it simple to understand the basic licensing rules, functions, and feature differences between the members of the distributed DB2 9.5 data server family.
- "Which DB2 9.5 client connectivity option is right for
you?" (developerWorks, April 2008): Learn the details and the history of connectivity options for the DB2 data
servers since DB2 Version 8 to DB2 9.5. In addition, learn about the specifications
for each connectivity option in DB2 9.5, with some tips along the way.
- "Which distributed edition of DB2 9.5 is right for you?"
(developerWorks, March 2007): Learn the details on what makes each edition of DB2 9.5 unique. The author lays out the specifications for each edition, outlines licensing considerations, historical changes from DB2 9, and describes some interesting things customers are doing with each edition of DB2.
- "DB2 and IBM's Value Unit pricing"
(developerWorks, Nov 2006): This article describes how to license DB2 using the new Value Unit metric as well as a number of helpful everyday scenarios.
-
Visit the developerWorks resource page for DB2 for Linux, UNIX, and Windows to read articles and tutorials and connect to other resources to expand your DB2 skills.
-
Learn about DB2 Express-C, the no-charge version of DB2 Express Edition for the community.
-
developerWorks Information Management: Learn more about IBM Information Management products. You'll find technical documentation, how-to articles, education, downloads, product information, and more.
Get products and technologies
-
Download a free trial version of DB2 Enterprise 9.
-
Now you can use DB2 for free. Download DB2 Express-C, a no-charge version of DB2 Express Edition for the community that offers the same core data features as DB2 Express Edtion and provides a solid base to build and deploy applications.
Discuss
About the author | 
| |
Paul C. Zikopoulos, BA, MBA, is an award-winning writer and speaker with the IBM Database Competitive Technology team. He has more than ten years of experience with DB2 and has written over sixty magazine articles and several books about it. Paul has co-authored the books:
Information on Demand: Introduction to DB2 9 New Features, IBM DB2 9: New Features, DB2 Version 8: The Official Guide, DB2: The Complete Reference, DB2 Fundamentals Certification for Dummies, DB2 for Dummies, and A DBA's Guide to Databases on
Linux. Paul is a DB2 Certified Advanced Technical Expert (DRDA and Cluster/EEE) and a DB2 Certified Solutions Expert (Business Intelligence and Database Administration). In his spare time, he enjoys all sorts of sporting activities, running with his dog Chachi, and trying to figure out the world according to Chloë - his new daughter. You can reach him at: paulz_ibm@msn.com.
|
Rate this page
| |
