Customers choose DB2 as their database of choice 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 highly availabile environments.
Another source of confusion stems from 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. Of course, some solutions try to address both scalability and high availability solutions with a cluster - so just ensure you're always communicating what you're trying to do when talking to your 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 also 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 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 conforms to the IBM SWG taxonomy and licensing terms with respect to high availability pricing. For example, if you configured a DB2 9 data server in a high availability cluster using IBM's High Availability Cluster Multiprocessing (HACMP) such that one server sat idle (and not started), you would have to partially license that server. In DB2 9.5, this is no longer 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 server that isn't powered on. I've updated this article for the DB2 9.5 release (as well as any changes that came about with the interim packaging changes announced on February 10th, 2009) 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 the 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 DB2 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 event allowed to be clustered for high availability.
- How did you license your DB2 server that you want to ensure is highly available?
For the mainstream DB2 9.5 data, 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 your licensing a Express-C FTL server, the licensing methodology is per server installation. For example, if you've installed DB2 Express-C FTL in 5 separate virtualization sessions on a single server, you'd have to purchase 5 DB2 Express-C FTL licenses. (If you're looking for an overview of all the distributed DB2 9 servers and how to license them, refer to "Which distributed edition of DB2 9.5 is right for you?" For comparisons of the features, functions, and benefits between the different DB2 server editions, read "Compare the distributed DB2 9.5 data servers.")
- How is the standby machine being used when a failure has not occurred?
For example, is it being used as a production 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 a High Availability Disaster Recovery (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.
The HA licensing changes to 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. For example, if you licensed the Storage Optimization Feature Pack (which provides deep row compression) on your DB2 Enterprise server and configured the database to participate in an HADR cluster, you would only need to purchase 100 PVUs of DB2 Enterprise on the standby server. Before DB2 9.5 became generally available, you would have also needed to puchase 100 PVUs of the Storage Optimization Feature Pack for the standby server as well. Obviously, you have to fully license the hot server in this configuration with both DB2 Enterprise and the Storage Optimization Feature Pack.
- When a single server is acting as a warm standby for multiple production servers, you only have to license the warm standby server once. For example, if you licensed a hot DB2 server for an unlimited number of users, the warm standby server would require 100 PVUs. If 5 different 400 PVU-rated servers running were running DB2 Workgroup and each server was configured in an HADR cluster to fail over to the same sever, you would only have to license 2100 PVUs (5 servers x 400 PVUs + 100 PVUs for the standby server) as opposed to 2500 PVUs.
- 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. (This functionality must be purchased for DB2 Express through an add-on Feature Pack.)
- HADR is 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; I'm talking hundreds of thousands of transactions per minute here.)
The best place to start a discussion of the effects of high availability clusters on DB2 9.5 licensing is with examples that correlate to DB2's high availability taxonomy. As previously mentioned, DB2 9.5 defines three types of standby servers: hot, warm, and cold.
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 (in the DB2 taxonomy, active=hot). If one of the servers in the high availability cluster was to fail, then clustering software would transfer the 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 has 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 technologies 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, yet acts as a standby for another server that is also used to service user transactions during normal operational periods too. When a failure of the 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.
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 and vice versa.
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, hot/hot, or active/active pair and is quite common in today's IT landscape. There are many ways in which to implement an hot/hot 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-Replication, using a hot 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 transferred workload.
As previous metioned, even an HADR cluster can function as an hot/hot cluster as shown in Figure 4 below:
Figure 4. An HADR hot/hot cluster.
In the previous figure you can that Server A hosts a production database called Database A as well as a standby database in an HADR cluster called Database B1. At the same time, Server B hosts a production database called Database B as well as a standby database in the same HADR cluster called Database A1. In this case, when there is no failure, both Server A and Server B are busy servicing production work on Database A and Databaes B and thus this is cosidered an hot/hot (or active/active) configuration and both servers must be fully licensed as you will see below.
Licensing considerations for a hot standby machine
As a general rule of thumb, a hot/hot 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 server is licensed.
Processor Value Unit (PVU) licensing:
For any DB2 server that's licensed using the PVU model, the entire PVU rating of the hot standby server (machine 1 in this example) must be licensed. An exception to this would be if you are using the sub-capacity licensing that's available for all DB2 editions as of February 10th, 2009; in this case, you just license the PVU rating for the virtualized session. (There are some pre-requisites to this kind of licensing that you should be aware of, so ensure you know all the details before deploying DB2 in this kind of environment.) Of course, you would use this same approach to license your DB2 server even if it weren't part of an HA cluster since it is servicing production work anyway, 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 a DB2 Workgroup (which is limited to servers with a maximum PVU rating of 480 as of 2Q08), you would have to purchase a total of 960 PVUs for this solution: 480 PVUs for machine 1 and 480 PVUs for machine 2.
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 hot standby server too (since they are both effectively hot 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 server. However, no matter how many users are accessing your server, there are some edition-dependent minimums that you need to account for. The DB2 Express or DB2 Workgroup editions requure a minimum of five authorized user licenses. DB2 Enterprise requires a minimum 25 authorized users per 100 PVUs for the underlying server. Put another way, for every 100 PVUs on the server, you require a pack of 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 server. Of course since this example is an hot/hot configuration, these rules are moot since they have to be licensed like independent fully hot servers.
In the example shown in Figure 3, if you had 100 users that needed to access both hot DB2 Workgroup 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 server at any one time, all 100 users would still have to be licensed for each server (so you still need 200 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 servers being used in Figure 3 were DB2 Enterprise, as previously mentioned, things are a little different. Lets continue with the example where we assume that each server is a 4-core POWER6-based server rated at 480 PVUs). Continuing with this example, if you had 100 users that needed to access both hot DB2 Enterprise 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 because of the 25 users per 100 PVU minimum for each DB2 Enterprise server. 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 server (so you still need 250 DB2 Enterprise authorized user licenses for this example). If the DB2 Enterprise 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 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 an FTL 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 PVU rating of the underlying server, or anything else: simple! While in a hot/hot configuration this rule has no effect on licensing (since both machines are hot), you will see in a warm standby configuration, the licening requirements are different compared to its DB2 edition counterparts.
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 warm in the sense that the 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 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 standby 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 (or resources allocated to a virtualized partition where they run) and allow the warm standby machine to use all of the server's resources to handle the load of the failed server; thereby circumventing the load considerations outlined in the hot/hot standby discussion in the last section. Another example of a hot/warm confguration is when the standby server is 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 quiesce 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 5; this configuration is typical of an HADR configuration. 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).
Figure 5. Machine 2's workload is transferred to the warm standby server, machine 1
Since during periods of normal operation, only one machine is hot from a DB2 perspective in Figure 5, while the other is doing some warm activity like priming an HADR failover partner, this configuration is often referred to as an hot/warm (or active/idle). The important concept to note here is that machine 1 wasn't doing any "meaningful" DB2 work before the outage occurred.
Clients take all sorts of different approaches to standby machines. I recommend that you prioritize your goals and business requirements with regards to a standby machine. For example, some clients may choose to set up a log shipping environment on a standby machine. At the same time, they also want to use this same standby database for a somewhat current read-only version of the production machine - thereby spreading out cost allocations over more and more resources (accountants really like to see this). Most vendors limit this model to either/or; meaning that while you are reading the database, you cannot roll forward through the logs to keep it current (if it isn't either/or, there is a compromise with respect to how fast the rolling forward process can keep up: as in a logical standby server through a snapshot). Subsequently, leaving the database open for extended periods of time for read-only operations increases the mean time to repair (MTTR) in the event of a failure: the very issue this configuration is designed to avoid. My advice, if you need outstanding availability characteristics, then price and size the environment with that as the premier goal and leave it as that (no one really appreciates the resource put into a high availability solution if they haven't had to use it in a while). If you can afford longer MTTR gaps, then you'll get more options with respect to the use of the standby machine (like using it for read queries): just remember, it's an inverse curve. As much as any vendor would love you to believe, the higher the availability levels you want, the more it costs. The key is to find what's right for your solution.
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 MTTR from an outage. The point is that DB2 has options for hot/hot as well - and the notion that an warm standby server (from a DB2 perspective) is just sitting around wasting resources is an often very misunderstood concept when you really look at it.
Licensing considerations for a warm standby machine
Processor Value Unit (PVU) licensing:
For any DB2 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 (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 5 was again a four core POWER6 server, and assuming each machine was running DB2 Workgroup (in 2Q08, the PVU limit for DB2 Workgroup was changed from 400 PVUs to 480 PVUs), you would have to purchase a total of 580 PVUs for this solution: 480 PVUs for machine 2 and 100 PVUs for machine 1.
For any DB2 server 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 hot/warm (or active/idle) HADR 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 server being used in Figure 5 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 5, if the servers in this figure 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 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 (so there are a total of 4 cores on this server), the total PVU rating for the hot server would be 480 PVUs. If you only had three users accessing the hot DB2 Enterprise 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. Again, notice the user licensing required for the warm DB2 Enterprise server isn't associated with the PVU rating of the underlying processor architecture in either the authorized user or PVU pricing model?
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 an FTL 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 PVU rating of the underlying server, or anything else: simple! In a hot/warm scenario (such as HADR), you can see that you would still need to buy 2 DB2 Express-C FTL licenses to properly license the two servers in this high availability configuration (since DB2 Express-C FTL can only be licensed per server installation).
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 and 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, a cold server may not even be powered on.
A cold standby scenario is shown in Figure 6.
Figure 6. 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 it's even the case that DB2 is installed on machine and it's turned off; 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 transactions. 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 the needs of some of your applications, and if it does, the cost of this solution gets cheaper in DB2 9.5 for the reasons outlined earlier in this article.
Licensing considerations for cold standby machine
As of the general availability date of the DB2 9.5 release, a cold standby server doesn't need to be licensed and therefore there are obviously 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 example, if you took a snapshot image off of a production server and started the DB2 standby 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 Workgroup 9 environment and the pureXML Feature Pack. In DB2 9, you would have to fully license the hot server (as expected) for both DB2 and the pureXML Feature Pack; in addition, the cold server would have to be licensed for 100 PVUs of DB2 Workgroup and 100 PVUs of the pureXML Feature Pack. In DB2 9.5, you would just properly 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. Oh ya! This example saves you even more money as of February 10th, 2009 because the pureXML Feature Pack is now free in all DB2 editions, so you don't have to pay for that on the hot server either; but that's a different article!
Reach higher - availability that is
As you can see, you have a lot of high availability options with DB2. 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 anything rated Copper would leverage a cold standby while a Silver rated solution a hot standby, 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 technologies like Xkoto GRIDSCALE or some other advanced configurations. The bottom line is not everything needs to be ultra-available; be smart and definately leverage the unique capability to use HADR in all DB2 server editions (it's on add-on Feature Pack for DB2 Express) to provide Gold service levels at Copper and Silver prices; this is unique in the industry because the HADR available to the DB2 server editions is no compromise.
- "Compare the distributed DB2 9.5 servers" (developerWorks, February 2009): 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 server family.
- "Which DB2 9.5 client connectivity option is right for you?" (developerWorks, February 2009): Learn the details and the history of connectivity options for the DB2 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, February 2009): 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 Processor Value Unit (PVU) pricing" (developerWorks, February 2009): 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 for Linux, UNIX, and Windows.
- 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 Edition and provides a solid base to build and deploy applications.
- developerWorks if thif: Get involved in the developerWorks community.
Dig deeper into Information management on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Experiment with new directions in software development.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.