Oracle 和 DB2，比较与兼容性/架构/摘要
本章开头介绍的通用关系数据库架构，为描述关系数据库主要功能组件提供了一个框架。然后，每个主要的架构区域，存储、内存和进程，都将针对 Oracle 和 DB2 的具体情况进行更详细的讨论。虽然在实际数据库代码级别上的实现存在很大差异，但数据库的工作方式非常相似。这并不奇怪，因为它们使用标准的经过验证的计算机科学技术进行内存管理，使用 Codd 博士开创性著作中描述的结构来处理关系数据，并且都在实现相同的基本功能。可以看出，两者都使用在实例、数据库和应用程序级别分配的内存，并且这些内存区域中实现的结构取决于数据库是独立的（专用）还是共享的（分区）。在两种情况下，都使用相同技术将磁盘数据存储在内存中（缓冲池），缓冲池由类似的 LRU 算法提供服务。
本章中描述的架构必然是简化的。本章旨在提供 Oracle 和 DB2 相当详细的功能概述，但为了清晰起见，省略了一些驻留在磁盘上的文件、内存结构和进程。在适当的后续部分将介绍此架构概述中未包含的重要实例，并参考此处使用的通用架构以提供上下文。Oracle 和 DB2 是复杂且成熟的产品，并且存在特定于每个数据库中不同选项和功能的结构和流程。其中一些将在后续部分介绍，但本部分的主要目的是介绍有关每个 DBMS 如何实现和管理基本数据库操作（从内存到磁盘以及反之亦然的读写数据，记录更改，处理用户连接，锁定数据库中的对象以及管理缓冲池）的通用概念。
熟悉 Oracle 和/或 DB2 的专业人员可以轻松识别特定于两者的组件，以及每个组件的独特结构。软件的一大优势（也是劣势）在于，通常有很多不同的方式来实现相同的功能。这些差异通常由数据库供应商描述为“竞争差异化”；他们选择这种实现的原因是它更优越。
从通用架构开始的原因是，只熟悉一个数据库的人可以了解另一个数据库如何实现相同的功能——如果你愿意，可以将其比作英语到西班牙语的翻译。本书的目标不仅仅是比较和对比数据库实现，而是描述在 DB2 中如何实现 Oracle 兼容性，为此，有必要了解每个数据库如何处理我们需要在两者中等效的功能实现。
对于希望更改数据库的组织来说，关于相似性和差异的架构讨论只是一个起点。必须对所有相似性和差异进行详细比较，因为没有两个 Oracle 或 DB2 实现是相同的。不同的组织实现不同的功能和选项，而更改数据库是一个重要的过程。墨菲定律指出，在这个过程开始时被忽视的一些差异将导致整个项目失败，因此重要的是尽可能全面地涵盖所有差异，以便你能够从一开始就找到两个非常重要的问题的答案
a) 我们是否已经确定对我们重要的差异，以及
b) 我们是否已经确定了所有差异？
所有关系数据库都将用户数据存储为表中的行和列。这种结构及其访问方法由 Codd 博士在 1970 年的开创性论文中描述。数据库的操作由软件处理。由于模型本质上是相同的，并且软件是灵活的，因此数据和 DBMS 似乎应该是可互换的。随着数据库功能的发展，通用功能的实现差异以及有价值但专有的功能的添加意味着数据库实现已经分化，现在仅仅知道数据库如何工作是不够的，还需要了解你正在使用的哪个数据库。自原始数据库实现以来，一直存在数据库迁移——将数据从一个供应商的数据库迁移到另一个供应商的数据库。这涉及到全面的数据操作，称为提取、转换和加载 (ETL)。数据落地后，还需要进行另一项工作，即修改应用程序逻辑（在用户程序中，以及在数据库中的存储过程、触发器、规则和函数中），以使你的系统能够与新迁移的数据库协同工作。
这一过程中的下一个逻辑步骤是兼容性，最终目标是能够将数据从一个数据库卸载并加载到另一个数据库，而无需担心操作不兼容的数据结构，并且访问这些数据的应用程序只需将其连接从原始数据库路由到新数据库即可。这种方法是通过供应商实现竞争供应商的功能来实现的。目的是使整体数据库迁移或异构数据库的互操作性变得无缝。虽然确实有一些项目已经顺利完成了，但所有这些项目都需要以下内容
• 了解源数据库的实现细节。
• 了解目标数据库的实现细节。
• 了解源数据库系统中使用的功能（数据结构和应用程序逻辑）的清单
• 将源数据库中的结构映射到目标数据库。
所有用户实现都是不同的，它们使用数据库功能的不同子集，并且并非所有这些功能在不同的数据库之间都是完全等效的。
本维基教科书的剩余部分提供了有关 Oracle 和 DB2 实现细节的更全面列表，使用内存模型、进程模型和存储模型的框架进行比较。