Results 1 to 12 of 12
  1. #1
    Join Date
    Nov 2008
    Posts
    5

    Unanswered: DB2 ICE vs. xkoto

    Hi DBAs,

    Could anyone help me in understand differences between DB2 Integrated Cluster Environment and xkoto solutions? What are the pros and cons of each solutions?

    Best.

  2. #2
    Join Date
    Jun 2003
    Location
    Toronto, Canada
    Posts
    5,516
    Provided Answers: 1
    Integrated Cluster Environment is just prepackaged DB2 DPF on Linux. Each node has one database partition.

    Xkoto Gridscale is a kind of replication solution slapped on top of DB2, with its own JDBC drivers. Each node has a complete copy of the entire database.
    ---
    "It does not work" is not a valid problem statement.

  3. #3
    Join Date
    Nov 2008
    Posts
    5
    Quote Originally Posted by n_i View Post
    Integrated Cluster Environment is just prepackaged DB2 DPF on Linux. Each node has one database partition.

    Xkoto Gridscale is a kind of replication solution slapped on top of DB2, with its own JDBC drivers. Each node has a complete copy of the entire database.

    OK, so on my understanding DB2 + xkoto is better solution, because gridscale can mange new connections and distribute in on different machines, create some kind of cluster. Furthermore this solution is OS independent.

    ICE is only for Linux platform and have more restraint. I mean, if one of node is broken, so whole partition with data is broken, then ICE can't work. Am I right or not?

    I'm sorry if my question is trivial. I mainly work with Oracle Real Application Cluster and right now I probably will migrate RAC to something similar in DB2.. Can you please affirm my conclusion?

  4. #4
    Join Date
    Jan 2003
    Posts
    4,292
    Provided Answers: 5
    I know nothing about ICE, so I cannot comment on it. We looked at GRIDSCALE from xkoto and we could not use it because of its limitations. All GRIDSCALE is, is a intermediary for DB2. The applications talk to it instead of DB2 and then it uses a farm of "identical" DB2 servers to service the work. All writes (insert, update, delete) are written to each DB2 in the farm and queries are sent to only one server in the farm based on some load balancing algorithm. The main limitation of this is that the database must be kept identical, meaning any data that goes into one has to go into all of them. This eliminates being able to have the database supply data to the database like CURRENT TIMESTAMP. This means that Stored Procedures, Triggers, etc cannot supply any data to the database like a timestamp for logging changes to a table.

    Andy

  5. #5
    Join Date
    Jun 2003
    Location
    Toronto, Canada
    Posts
    5,516
    Provided Answers: 1
    Quote Originally Posted by tytoos View Post

    ICE is only for Linux platform and have more restraint. I mean, if one of node is broken, so whole partition with data is broken, then ICE can't work. Am I right or not?
    The database will continue to work as long as it does not need data from the failed partition. Data reside on SAN volumes, which is practically 100% reliable. If one of the database servers fail you can bring up a standby for that partition.

    Quote Originally Posted by tytoos View Post
    I'm sorry if my question is trivial. I mainly work with Oracle Real Application Cluster and right now I probably will migrate RAC to something similar in DB2.
    Look at IBM PureScale (IBM - DB2 pureScale Feature) - it supposed to be functionally similar to RAC, except that it has a central cache instead of the RAC's distributed cache.
    ---
    "It does not work" is not a valid problem statement.

  6. #6
    Join Date
    Nov 2008
    Posts
    5
    @ARWinner

    Thanks for your feedback! I don't realized that gridscale have so big restriction! For sure I will keep in mind this information.


    @n_i

    Also thank you for your response. Half a year ago I was at db2 bootcamp and I ask about solutions similar to Oracle RAC and no one told me about pureScale. It's great to know about it. I have to learn more about it. Thanks a lot again!

  7. #7
    Join Date
    Jan 2010
    Posts
    2

    comparing ICE/dpf to gridscale

    Others in the forum have already pointed out that ICE uses db2 dpf on linux only so scale is achieved through partitioning. However, ICE is not continuously available - things like planned maintenance, fixpak upgrades etc. require ICE to go down resulting in app downtime. Also, if the schema is not easy to partition, this represents another challenge.

    gridscale is also multi-node like ICE but each db2 node is complete and always active (and non-partitioned), although gridscale can also sit in front of a pair of dpf clusters so that dpf now becomes continuously available too.

    It's true that gridscale may require some schema changes to ensure data consistency across all nodes, but to use partitioning with dpf or ICE may also require some significant app and schema changes to become partitionable.

    Bottom line, not much works out of the box so pick the box that best suits your requirements.

  8. #8
    Join Date
    Jun 2009
    Posts
    272
    The best thing I like about gridscale is the version upgrades. One can have mixed environments - meaning one database connector can be in V9.1 and the other can be in V9.5 which enables us to do version upgrades without causing any outage. Version upgrades cannot be done without an outage with any of the existing HA solutions such as HADR, replication ... but could be done with XKOTO.

  9. #9
    Join Date
    Jun 2009
    Posts
    272
    Andy, did you mean that the timestamp values inserted using current timestamp will be different in both the database connectors of the gridscale ??

  10. #10
    Join Date
    Jan 2010
    Posts
    2
    gridscale now has a new function to replace the timestamp call - this does require an app change though but once the "replacement function" is called time will be supplied by the gridscale server so that it'll be the same in every db

  11. #11
    Join Date
    Jan 2003
    Posts
    4,292
    Provided Answers: 5
    Quote Originally Posted by blazer789 View Post
    Andy, did you mean that the timestamp values inserted using current timestamp will be different in both the database connectors of the gridscale ??
    What I meant was that if you have a stored procedure on each DB2 node in the Gridscale cluster that inserts/updates data in the database and part of that data is current timestamp, then the data will not be exact on all nodes of the Gridscale cluster because each node in the cluster will have a different timestamp value for the new data as there is no way to ensure that the value generated will be the same. This holds true for all database generated data.

    Andy

  12. #12
    Join Date
    Jan 2003
    Posts
    4,292
    Provided Answers: 5
    Quote Originally Posted by aykl View Post
    gridscale now has a new function to replace the timestamp call - this does require an app change though but once the "replacement function" is called time will be supplied by the gridscale server so that it'll be the same in every db
    Which means that BI can no longer be encapsulated in the database.

    Andy

  13. #13
    Join Date
    Aug 2001
    Location
    UK
    Posts
    4,650
    Quote Originally Posted by tytoos View Post
    Half a year ago I was at db2 bootcamp and I ask about solutions similar to Oracle RAC and no one told me about pureScale.
    PureScale was made public only in middle of October and Generally Available from December .. Your instructor at the bootcamp should have atleast hinted that something is on the pipeline.

    Purescale is available at the moment (and probably for the near future, i assume) on IBM Power Systems and AIX only, as the product is heavily reliant on technologies like RDMA, infinband etc. It is these technolgies that enable PureScale's "central cache instead of the RAC's distributed cache" .. Hence if you are running db2 on linux, purescale may not be an option for now.

    HTH
    Visit the new-look IDUG Website , register to gain access to the excellent content.

  14. #14
    Join Date
    Aug 2001
    Location
    UK
    Posts
    4,650
    Quote Originally Posted by tytoos View Post
    Half a year ago I was at db2 bootcamp and I ask about solutions similar to Oracle RAC and no one told me about pureScale.
    PureScale was made public only in middle of October and Generally Available from December .. Your instructor at the bootcamp should have atleast hinted that something is on the pipeline.

    Purescale is available at the moment (and probably for the near future, i assume) on IBM Power Systems and AIX only, as the product is heavily reliant on technologies like RDMA, infinband etc. It is these technolgies that enable PureScale's "central cache instead of the RAC's distributed cache" .. Hence if you are running db2 on linux, purescale may not be an option for now.

    HTH
    Visit the new-look IDUG Website , register to gain access to the excellent content.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •