IBM solidDB and solidDB Cache for DB2 & IDS Product Availability

作者: Maclean Liu , post on December 4th, 2010 , English Version
【本站文章除注明转载外,均为本站原创编译】
转载请注明:文章转载自: Oracle Clinic – Maclean Liu的个人技术博客 [http://www.oracledatabase12g.com/]
本文标题: IBM solidDB and solidDB Cache for DB2 & IDS Product Availability
本文永久地址: http://www.oracledatabase12g.com/archives/ibm-soliddb-and-soliddb-cache-for-db2-ids-product-availability.html

IBM solidDB Cache DBMS Support

  • DB2 LUW and z/OS
    • DB2 for Linux, UNIX, and Windows Enterprise Server Edition V9.5
    • DB2 for Linux, UNIX, and Windows Enterprise Server Edition V9.1
    • DB2 9 for z/OS
    • DB2 for z/OS V8
      • Restrictions: When running solidDB Cache for DB2 with DB2 for z/OS, the solidDB Connector must run on a Linux, UNIX, or Windows platform, not on the System z™ platform
      • Prerequisites: When running solidDB Cache for DB2 with DB2 for z/OS, a license of DB2 Connect is required and must run on the same server as the solidDB Connector
  • Informix IDS
    • IDS V11.5 Enterprise Edition
    • IDS V11.1 Enterprise Edition
  • Platforms: AIX, HP Unix, Linux, Sun Solaris, Windows

solidDB – Embedability

  • Connections to solidDB can be local or remote
  • Local = in-process/embedded - Remote = client/server
  • solidDB supports a maximum of ONE local process using its Linked Library access
  • Oracle TimesTen has no such limitation. A TimesTen database can be shared by many applications concurrently linked with the database, connected via shared memory IPC, and client/server
  • solidDB database invalidates if the local application process is killed
  • Oracle TimesTen implements patent-pending Micro-Logging technology to ensure the database continues to run despite of abrupt termination of any application process linked with the database
  • solidDB server shuts down if the “local” application disconnects, despite of the existing remote connections to the database
  • Oracle TimesTen is designed for multi-threaded multi-application deployments

solidDB In-Memory Engine

  • A solidDB database may contain a combination of in-memory tables and disk-based tables
  • solidDB In-Memory tables
    • Entire table must be in memory
    • Use pessimistic row-level concurrency control
    • No versioning  write operations blocked by read operations for the duration of the read transactions  possible deadlocks
    • Serializable isolation not supported
    • Maximum column size is 32KB (limited by size of a page)
  • Oracle TimesTen In-Memory Database
    • Designed for in-memory layout with optimized algorithms
    • Supports read-committed and serializable isolation
    • Row-level locking for concurrency
    • Non-block versioning  readers don’t block writer, writer don’t block readers
    • Column size up to 4MB in size depending on data types
    • Scalable for multi-applications
    • Enterprise ready

solidDB – Other features

  • solidDB supports stored procedures and triggers, but they are not compatible with DB2 and IDS
  • Stored procedures and triggers have not been a real necessity for TimesTen applications to reduce response time and increase throughput since any number of application processes can be linked directly with the database
  • Support for PL/SQL Stored Procedures is targeted for next release for Oracle compatibility and ease of application adoption
  • TimesTen offers a light-weight data change notification facility (XLA)
  • solidDB supports a hybrid approach for the database
    A table can either be in-memory or on disk
    solidDB was originally designed as a disk-based database; in-memory tables were added with lots of limitation

IBM solidDB Cache Connector 6.1

  • Feature Analysis
  • Primitive set of functionality
  • Coarse-grain replica (cache) definition specified in the backend database – support only partition and table-level replicas (no WHERE clause selection)
  • No support for incremental cache refreshes from the backend
  • No support for on-demand loading of cache data from the backend
  • Unproven product quality, features and implementation
  • Several years behind Oracle In-Memory Database Cache

Now let’s talk about the Replication product option. The TimesTen Replication product provides transactional data replication from a TimesTen database to another TimesTen database. TimesTen Replication is very high performance and reliable. An estimated of over 95% of TimesTen customers use the TimesTen Replication to provide high availability for their in-memory databases.

TimesTen Replication offers very flexible configuration options, including active-standby, active-active, n-way replication.

Asynchronous replication
Low latency, high throughput
Synchronous replication
Return-receipt, Return 2-Safe
Guarantee data in 2 memory locations

© 2010, www.oracledatabase12g.com. 版权所有.文章允许转载,但必须以链接方式注明源地址,否则追究法律责任.

相关文章 | Related posts:

  1. Oracle In-Memory Database Cache Oracle TimesTen In-Memory Database
  2. Oracle 11g Competing Against IBM DB2 9.5 for Linux,Unix and Windows
  3. Oracle vs. IBM DB2 9.5 LUW Performance and Scalability – Competitive Analysis
  4. Competitive Analysis of Data Warehousing Capabilities:Oracle Database 11g vs IBM DB2 9.5
  5. Rethink Migration, Another advertisement from db2
  6. Siebel Maximum Availability Architecture (MAA)
  7. Know More About Libarary Cache and Latches
  8. Oracle Data Integrator 11g Product Overview and New Features
  9. SQL*Loader Date Cache
  10. Managing Performance and Availability for 25,000 Siebel Contact Center Users with Oracle Real Application Clusters

Leave a Reply

  

  

  

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>