Oracle物理设计及性能优化
ORACLE 性能优化
ORACLE 数据库性能优化参考书目：《ORACLE 9i Database Performance Tuning Guide and Reference》《ORACLE 9i Database Reference》《ORACLE 9i SQL Reference》《ORACLE 9i Database Administrator’s Guide》一、数据库实例创建过程参数确定在创建数据库实例过程中，需要确定以下几个参数：1. 数据块大小（DB_BLOCK_SIZE）该参数指明了ORACLE所处理的数据存贮于数据文档以及SGA内存中的数据块大小。
该参数的可选择的范围为:4k,8k,16k,32k,64k。
对于OLTP系统而言，取值可以为4K或8K，对于DSS系统而言，则可以取较大的数据，如32K或64K 建议统一取8K（即8192）说明DB_BLOCK_SIZE的大小将影响创建表时的EXTENT的大小。
例如指定db_block_size=16K,某表空间的EXTENT MANAGEMENT 为local autoallocate，则其系统将extent的大小最小指定为1M.所以将可能导致空间的浪费。
2. 字符集(Character set)该参数确定数据库以何种字符集来存贮CHAR以及V ARCHAR、V ARCHAR2等字符类型的值。
对于ORACLE数据字典中的字符（如表及字段的COMMENT 内容）具有同样的作用。
因此需要考虑如字符集的使用。
对于国际项目，因为数据库中的comment内容（包括表及字符、存贮过程中的中文字符等内容）可能性需要以中文存贮，而用户业务数据使用的字符可能性是使用本地的语言，基于此，该参数需要选择支持UNICODE的字符编码的字符集。
目前ORACLE9i支持以下二种UNICODE字符集：⏹UTF8⏹AL32UTF8建议统一取AL32UTF83. 扩展段管理(EXTENT MANAGEMENT)该参数指明表空间中的扩展段的管理方式。
基于Oracle数据库开发系统的物理设计优化策略
一
个成 功 的数据库应 用系 统要经过需求分析 、概 念 设
的最小单位 。它们 的结构如图１ 所示 。
计、逻￣ ９ ＂ Ａｔ 、物理设计、程序设计、数据库实施等多个 阶 段 ．其中物理设计阶段的主要任务是在数据库支持系统中建 立数据库对象 （ 包括库表 、索 日等）。由于该阶段只是搭建 Ｉ 数据库应用系统 的后台支撑环境 ．因此在系 统开发与实施 阶 段往往会被忽略设计优化 。这样的系统在实际应 用中 ，一 旦 用户数 目增多．规模变大 ．数据库的效率将明显降低 。并 且 由于前期没有很好的物理设计 ，后期又投有进行相应的系 统 优化 ． 往往系统会在运行一段 时间后，性能下降很快 。因此 在系统的整个开发和实施 周期 内应重视物理设计和后期的优 化 ，系统开发人员应与数据库管理员进行充分的交流 ，根据 系统 的实际情 况进行 详细科 学的物理设计 。在 后期运 行 阶 段 ，数据库管理员应定期地对系统进行优化谓整 ，使系统变
文 标 码： 献 识 Ａ
中 分 号：Ｔ３１３３ 朗 类 Ｐ１１ ． －２
基于Ｏｒｃ 数据库开发 系统的物理设计优化策略 ａｌ ｅ
苏大威 ．张 乐
（ 河海大学计算机信 息工程学院 ．南京 ２ ０ ９ ） １０ ８ 攮 赛 ：一十成功的数据库 应用系统取击＝Ｉ 的规划和设 计 ．而多数的开发人员倒 重于逻辑和程序的设 计优化。文章通过 分析Ｏ ａｌ ｔｆ ＝ ｒ ｅ ｃ 数据 库 的物理文件特性 阐述在物理设计阶殷和后期运行阶￣ Ｊ ｒ ］ 发 Ｏ ａ ｄ 据库文件的优化策 略。 ｃ 关斟 胃 Ｏ ａ ｌ ： ｘ ｃ ｃ ；物理设计 ；性蛆优 化；碎片
得稳定高效 。
ｏ ｃ 文件系 ｍｋ 件系境
圈１ Ｏ ａｌ ｒｃ 敦胖 ｅ
论Oracle数据库的性能优化问题
马 红 云
（ 中国民用航 空大连 空中交通管理站 辽宁大连 １ １ ６ ０ ３ ３ ）
摘要 ： Ｏｒ ａ ｃ ｌ ｅ 数 据库作 为 目前适 用性 最好 的关 系数据库 引擎之 一， 能够 支持 各种业 务形式 、 处理各 种复 杂事务 ， 得 到极 为广泛 的应 用。
１对数据库服务器 内存分配的调整
由于对服务器 内存参数 的调整对ｏ ｒ ａ ｃ ｌ ｅ 的性能影响显著 ， 它成 为Ｏ ｒ ａ ｃ ｌ ｅ ￣据库性能调 优的首选对象。 服务器 内存参数 的调整主要 是对数据库系统全局 区的调整 ， 系统全局 区包括共享池、 数据缓冲 区、 日志缓冲区 。 其 中最主要的是对数据缓冲区和共享池 的参数调
３ ． ２表 的分 区和 并行 技 术
如果必须要在数据库运行特别耗时的操作。 应尽量地把这样的 操作分解 ， 严格 限制操作所涉及的记录数 ， 并设法使操作并行 ， 充分 地提高 执行效率 。 （ １ ） 使用分区 分区技术有两个潜在的好处： 提高查询性能和提 高数据 库可用性 。 数据库查询 时， 优化器知道那些分区包含查询所 要的数据 。 而其它分 区数据将不会被读取 ， 从而查询 任务将更快完 成。 许 多 管 理 工 作 可 在 只 一个 分 区上 进 行 ， 而 不 影 响 其它 分 区 的数 据。 例 如 可 以选 择 只 删 除一 个 表 分 区 中 的数 据 。 可对 表 分 区进 行 再 分割 ， 把一个表分区迁移到不同的表 空间上 。 可只对 一个表分 区进 行分析 统计 。 表分区的这 些特性 。 （ ２ ） 使用并行 。 Ｏｒ ａ ｃ ｌ ｅ 数据库 中几乎 所有的操作都 支持 并行 特 性， 包括查询、 插入 、 和数据加载。 并行选项可 以使多个处理器 同时 处理一条命令 ， 在创建库数据库对象 时可以设定 并行参数 ， 也可在 查询语句 中重新设 。
oracle双机热备架构方案
Oracle双机热备架构方案一想到Oracle双机热备，我脑海中立刻浮现出那些无数个夜晚，灯火通明的数据中心，以及那些为了保证数据安全、系统稳定而奋斗的工程师们。
在这个方案中，我们要解决的问题是如何确保关键业务数据的实时备份和快速恢复，下面就是我构思这个方案的过程。
我们需要明确Oracle双机热备的架构。
Oracle双机热备，顾名思义，就是两台服务器互为备份，一台为主机，另一台为备机。
当主机发生故障时，备机能够迅速接管主机的业务，保证业务的连续性。
1.架构设计（1）硬件设备我们需要两台性能相近的服务器，最好是同一型号，这样可以减少硬件兼容性问题。
服务器需要具备较高的处理能力，以满足业务需求。
（2）存储设备为了实现数据的实时备份，我们需要使用共享存储设备。
这里有两种选择：磁盘阵列和存储网络。
磁盘阵列可以提供较高的数据读写速度，但成本较高；存储网络则相对便宜，但性能略有不足。
根据实际需求，我们可以选择合适的存储方案。
（3）网络设备为了实现数据的实时同步，我们需要搭建一个高速网络。
这里建议使用万兆以太网，以保证数据传输速度。
2.软件配置（1）操作系统（2）Oracle数据库在两台服务器上安装Oracle数据库，并配置好数据库实例。
为了保证数据的一致性，我们需要使用OracleDataGuard来实现实时数据备份。
（3）集群管理软件为了实现故障切换，我们需要使用集群管理软件。
这里推荐使用OracleClusterware，它可以帮助我们实现快速的故障切换和恢复。
3.实施步骤（1）搭建硬件环境我们需要将两台服务器连接到共享存储设备，并配置好网络设备。
（2）安装操作系统在两台服务器上安装相同的操作系统，并配置好网络参数。
（3）安装Oracle数据库在两台服务器上安装Oracle数据库，并配置好数据库实例。
（4）配置OracleDataGuard在主机上创建一个物理备份，然后将备份传输到备机。
在备机上配置OracleDataGuard，实现实时数据备份。
Oracle数据库性能优化的分析
性 的特 点 。
２ 发展 与特点
Ｏａｌ 数据库是一 个功 能极其强大 的数据库系统 。它起始 ｒ ｅ ｃ 于七十年代末 的关 系型数据库技术。Ｏａｌ 数据库 的关键是 怎 ｒｃ ｅ
样 理解 数 据 问 的关 系 ，然后 构 造 反 映这 些 关 系 的信 息 库 。
３ 性 能优化 目标
随着 Ｏ ａｌ ｒｃ ｅ数据库 规模 的扩 大 ，Ｏａｌ 数 据库 系统 的性 ｒｃｅ 能问题越来越突出 ，Ｏａｌ 数据库性能优化是通过优化应用程 ｒ ｅ ｃ
ＤＴＢＳ Ｄ ＮＯ Ｍ Ｔ Ｎ Ａ Ａ Ｅ Ｅ Ｔ ＡＡＡＥ Ｎ ＦＲ Ａ１ Ｎ Ｇ Ｍ Ｎ Ａ Ｉ ０Ｍ
数据库与信息管理
Ｏ ａｌ 数据库 性 能优 化的分析 ｒｃ ｅ
潘 敏 ，傅扬 ，史晓翠
（ 武警黄金地质研究所 ，廊坊 ０ ５０ ） ６ ０ ０
摘
要 ： Ｏａｌ 数据 库 系统的优化 对于整个 系统 的正常运行起着 至关重要 的作 用 ，但 是 它却 是一项 非常复杂 的工 ｒｃｅ
象技术 和关系型数据库的结合 ，使用户现有 Ｏａｌ７ ｒｃｅ 数据 库应 用软件无需移植 ，便可在 Ｏ ａｌ８ ｒｃｅ 数据库上使用 ， Ｏ ａｌ 数据 ｒｃｅ
库发展 到现在的 Ｏ ａｌ ０ ，它是第一款为 网格计算 而设计 的 ｒｃ １ｇ ｅ
数据 库 ，集成 了 Ｏ ａｌ ｒｃ ｅ数据库 管理技术 的各种优势 ，又融入 了网格计算的各种新 的性能特点 。Ｏ ａｌ数据库 系统 的特点是 ｒｃ ｅ 支持大数据库 、多用户 的高性能事务处理 ，Ｏ ａｌ 数据库具有 ｒ ｅ ｃ
Ａｂ ｔ ａ ｔ ｈ ｕ ｉ ｇ ｆｒＯｒ ｃ ｅ ｄ ｔ ｂ ｓ ｙ ｔｍ ｓ ｖｔ ｌ ｏ ｔ ｅ ｎ ｒ ｌ ｕ ｎ ｎ ｆｔ ｅ ｗ ｏｅ ｓ ｓｅ ｓ ｒ ｃ ：Ｔ ｅ ｔ ｎ ｎ ｏ ａ ｌ ａ ａ ａ ｅ ｓ ｓｅ ｉ ｉ ｈ ｏ ｍａ ｎ ｉ ｇ ｏ ｈ ｌ ｙ ｔ ｍ，ｂ ｔｉ ｉ ｏ ｌ ａ ｅ ａｔ ｒ ｈ ｕ ｔ ｓａ ｃ ｍｐ ｉ ｔ ｄ ｃ ｗｏ ｋ ｈ ｒ ｆｒ ， ｅｆ ｒ ｎ ｅ ｔ ｎ ｎ ｎ ｐ ｉ ｚ ｔ ｎ ｏ ａ ｌ ａａ ａ ｅ ｓ ｓｅ ，ｗ ｉｈ ｃ ｎ ｅｎ ｍｕ ｔ ｌ ｓ ｅ ｔ，ｃ ｎ ｉ ｒ ．Ｔ ｅ ｅｏ ｅ ｐ ｒｏ ｍａ ｃ ｕ ｉ ｇ ａ ｄ ｏ ｔ ｍｉａ ｉ ｆＯｒ ｃ ｅ ｄ ｔｂ ｓ ｙ ｔ ｍｓ ｈ ｃ ｏ ｃ ｒ ｌ ｐ ｅ ａ ｐ ｃｓ ａ ｍ－ ｏ ｉ
Oracle数据库性能优化分析
千里之行，始于足下。
Oracle数据库性能优化分析Oracle数据库性能优化分析是指对Oracle数据库进行综合性能分析和优化的过程。
通过分析数据库的运行状况、识别潜在的性能瓶颈、确定解决方案并实施优化措施，可以提高数据库的性能和效率。
以下是Oracle数据库性能优化分析的一般步骤：1. 收集性能数据：通过Oracle的性能监控工具，如AWR报告、统计信息收集等，收集数据库的性能数据，包括CPU利用率、I/O响应时间、锁定情况等。
2. 确定性能瓶颈：通过分析性能数据，确定数据库中存在的性能瓶颈，如高CPU使用率、高IO等待、长时间的锁等待等。
3. 优化SQL语句：分析执行频次较高的SQL语句，通过重写SQL语句、调整索引和统计信息等方式，优化SQL语句的执行计划，减少IO开销和CPU消耗。
4. 优化数据库结构：根据应用的需求和查询模式，调整表结构、分区策略、索引设计等，以提高查询性能和数据访问效率。
5. 优化数据库配置参数：调整数据库的配置参数，包括缓冲区大小、日志大小、并发连接数等，以最大限度地利用硬件资源，提高数据库的吞吐量和响应时间。
6. 确保数据完整性和一致性：通过使用合适的约束和触发器，确保数据的完整性和一致性，防止数据错误和冲突对性能造成负面影响。
第1页/共2页锲而不舍，金石可镂。
7. 监控和调优：定期监控数据库的性能指标，如响应时间、吞吐量等，及时识别和解决潜在的性能问题，保持数据库的高可用性和性能稳定性。
需要注意的是，性能优化是一个综合性的工作，需要结合具体的应用场景和需求来进行分析和优化，没有一种通用的解决方案，需要根据实际情况进行定制化的优化措施。
同时，性能优化是一个持续改进的过程，需要定期评估数据库的性能状况，并根据需求进行调整和优化。
Oracle数据库性能优化与案例分析
Oracle数据库性能优化与案例分析
性能优化探讨
• 原因：为什么？ • 慢（响应时间） • 慢（吞吐量）
性能优化探讨
• 目的：为了什么？ • 快（响应时间） • 快（吞吐量）
性能优化之案例分析
• 案例之方法论 • 案例之登录访问 • 案例之资源 • 案例之锁
性能优化方法论发展
• 登录输入指标测量 • Logons：= EndSnap. logons cumulative– StartSnap. logons
cumulative。 • Logons Per Second:= Logons / TimeInterval
案例之登录访问
登录输出指标测量：
Logon Response Time:= Network Response Time * 10 + Native TCP Logon :=Network Response Time * 10 + Listener Response Time + Native IPC Logon Time 。
案例之登录访问
• 例：
•
某医院HIS业务系统的账户登录操作异常缓慢，部分情况下
甚至会出现长时间的卡壳情况，业务影响主要发生在每天早上
的上班时刻。
案例之登录访问
优化过程： • 账户登录过程一般涉及到在账户表格以及对应日志表格上的冲
突，比如Buffer busy waits或者TX lock。AWR未体现该特征。 • AWR报告显示connection management call elapsed time时间偏长
成功率：98% 高 失败率：2% 低
失败人数：500*2%=10
第09章Oracle的性能优化
9.2 SQL语句的优化
9.2.1 SQL语句的优化规则 9.2.2 SQL语句优化的具体方法
9.2.1 SQL语句的优化规则
（1）去掉不必要的大表、全表扫描。不必要的大表、全表 扫描会造成不必要的输入输出，而且还会拖垮整个数据库；
（2）检查优化索引的使用 这对于提高查询速度来说非常重 要；
（3）检查子查询，考虑SQL子查询是否可以用简单连接的 方式进行重新书写；
系统的服务器，可以使用sar –u命令查看CPU的使用率；NT 操作系统的服务器，可以使用NT的性能管理器来查看CPU 的使用率。
出现CPU资源不足的情况是很多的：SQL语句的重解析、 低效率的SQL语句、锁冲突都会引起CPU资源不足。
2．查看SQL语句的解析情况 （1）数据库管理员可以执行下述语句来查看SQL语句的解析 情况：
9.3 Oracle运行环境的优化
9.3.1 内存结构的调整 9.3.2 物理I/O的调整 9.3.3 CPU的优化调整 9.3.4 网络配置的优化 9.3.5 Oracle碎片整理 9.3.6 Oracle系统参数的调整
9.3.1 内存结构的调整
内存参数的调整主要是指Oracle数据库的系统全局区 （SGA）的调整。SGA主要由三部分构成：共享池、数 据缓冲区、日志缓冲区。
2．数据缓冲区 数据库管理员可以通过下述语句，来查看数据库数据缓冲区
的使用情况。
SELECT name， FROM v$sysstat WHERE name IN （'db block gets','consistent gets','physical reads'）;
根据查询出来的结果可以计算出数据缓冲区的使用命中率：
Oracle数据库物理设计规范
1.数据库物理设计规范1.1.操作系统环境本项目运行在Linux 64位操作系统上，数据库采用Oracle 11g。
1.2.内存要求由于Oracle数据库对内存要求比较高，一般情况下，操作系统的内存越高，数据库响应能力就越大。
所以建议采用大于32G的内存。
1.3.交换区设计当物理内存在2G以下的情况下，交换分区swap为物理内存的3倍，当物理内存>2G的情况下，swap大小为物理内存的1～2倍。
其他环境变量参考Oracle相关的安装文档和随机文档。
1.4.数据库SID数据库SID是唯一标志数据库的符号，命名长度不能超过5个字符。
对于单节点数据库，以字符开头的5个长度以内字串作为SID的命名。
对于集群数据库，当命名SID后，各节点SID自动命名为SIDN，其中N为节点号：1，2，…,64。
例如rac1、rac2、rac24。
1.5.数据库全局名数据库全局名称：Rac1.6.数据库类型选择对于海量数据库系统，采用Data Ware House的类型。
对于小型数据库或OLTP类型的数据库，采用Transaction Processing类型。
1.7.数据库连接类型选择Oracle数据库有专用服务器连接类型和多线程服务器MTS连接类型。
对于批处理服务，需要专用服务器连接方式，而对于OLTP服务则MTS的连接方式比较合适。
由于采用MTS后，可以通过配置网络服务实现某些特定批处理服务采用专用服务器连接方式，所以数据库设计时一般采用MTS类型。
1.8.数据库SGA配置数据库SGA可以采用手工配置或按物理内存比例配置，在数据库初始设计阶段采用按比例配置方式，在实际应用中按系统调优的方式修改SGA。
1.9.数据库字符集选择为了使数据库能够正确支持多国语言，必须配置合适的数据库字符集，采用UTF8字符集。
注意：如果没有大对象，在使用过程中进行语言转换没有什么影响，具体过程如下（切记设定的字符集必须是ORACLE支持，不然不能start）SQL>’shutdownimmediate’;SQL>’startup Mount’;SQL>’alter system enabler restricted session’;SQL>’alter system set job Queue processes’=0;SQL>’alter Database open’;SQL>’shutdown Immediate’;SQL>startup1.10.数据库文件配置dB files是数据库能够同时打开的文件数量，默认值是200个。
Oracle的性能优化
千里之行，始于足下。
Oracle的性能优化
Oracle的性能优化是提高数据库系统性能和响应速度的关键步骤，可以通
过如下几个方面进行优化：
1. 数据库设计和规范化：合理的数据库设计和良好的规范化可以减少数据冗余，提高查询效率，避免数据冲突和不一致。
2. 索引优化：在频繁查询的字段上创建适当的索引，可以加快查询速度。
但是，索引不宜过多，因为它们会增加数据修改和插入的时间。
3. 查询优化：优化查询语句的执行计划，使用正确的连接方法（如内连接、外连接），避免全表扫描。
4. 硬件升级：增加内存、硬盘和处理器等硬件资源，可以显著提高
Oracle数据库的性能。
5. 优化配置参数：根据数据库的特点和应用的需求，调整数据库的配置参数，例如SGA大小、PGA大小、日志文件大小等，以提高性能。
6. 数据库优化：使用合适的数据库特性，如分区表、分区索引、物化视图等，优化数据库的存储和查询效率。
7. 监控和调优：持续监控数据库的性能指标，如CPU利用率、内存使用率、磁盘IO等，并及时进行适当的调优操作。
第1页/共2页
锲而不舍，金石可镂。
总体来说，Oracle的性能优化需要综合考虑数据库设计、硬件配置、查询优化和系统监控等多个方面，通过不断的调整和优化，提高数据库的性能和响应速度。
Oracle性能分析的一些总结
Oracle性能分析的一些总结在Oracle数据库中进行性能分析是关键工作之一，他能够帮助我们了解数据库的性能瓶颈并提供优化建议。
下面是一些关于Oracle性能分析的总结。
1.数据库性能分析的目标是找出数据库系统中的性能瓶颈，并提供优化建议。
性能瓶颈可能出现在数据存储、查询语句、索引、服务器配置等方面。
2. Oracle数据库中的性能分析可以通过多种手段进行。
常用的性能分析方法包括使用Oracle自带的工具和视图，如AWR报告、ASH报告、执行计划等；使用第三方性能分析工具，如Oracle Enterprise Manager、TOAD、SQL Developer等。
3. AWR（Automatic Workload Repository）报告是Oracle数据库中性能分析的重要工具之一、AWR报告可以提供数据库的性能指标、历史性能数据、系统事件等信息，帮助我们定位性能问题。
4. Oracle数据库中的执行计划是性能分析的关键工具之一、执行计划显示了查询语句或PL/SQL代码在数据库内部是如何执行的，通过分析执行计划可以了解查询语句的性能瓶颈。
5.数据库索引是性能分析的重要方面之一、索引可以提高查询性能，但过多或不合适的索引也会导致性能下降。
通过分析执行计划和优化器统计信息，可以判断索引是否合理。
6. Oracle数据库中的缓存也是性能分析的关键点之一、数据库缓存包括数据块缓存、SQL语句缓存等。
通过监视缓存的利用率和命中率，可以判断缓存是否合理。
7.数据库服务器的硬件配置也会影响性能。
硬件配置包括CPU、内存、磁盘等。
通过监视服务器的负载、资源使用情况，可以判断硬件配置是否合理。
8.数据库性能分析还需要考虑应用程序的影响。
应用程序的设计和实现可能会导致性能瓶颈。
通过分析应用程序的SQL语句、PL/SQL代码等，可以定位性能问题所在。
9.在进行性能分析时，需要进行实验和测试。
通过在测试环境中模拟生产环境的负载测试，可以了解数据库在不同负载下的性能表现。
基于ORACLE数据库性能优化的研究
（ 独立的表．索引和回滚段。表及其索 ２ ）
引使用的数据文件应存放在独立的磁盘上． 以避免数据查询期间的竞争。而在数据处理 事务时．回滚段在存放数据的表和索 被处 ｌ
理时使用。
ｔ ｌｐｃ ａｌ ｏｅ ｅ语句消除 ａｅ ａ ｎⅡ ａｓ ｓ ｂ ｓ ｅ ｅ １ｃ ｃ 表空间 碎片．
１ 。 ２表空间的 物理设计和优化
表空间物理设计和优化的目标．是尽量 减少各表空间之间磁盘Ｉ ／ ０的竞争， 因此需要 把不 同的表空间分布到不同的物理磁盘上。 在进行数据库物理规划时应考虑： （） １ 采用Ｏ ａｌ推荐的表空间优化结构 ｒｃ ｅ
（Ｆ ） Ｏ Ａ。
缺省表空间和临时表空间 否则用户的缺省
亦可利用Ｅ Ｐ Ｒ Ｘ Ｏ Ｔ和Ｉ Ｏ Ｔ程序． ＭＰ Ｒ 使用先 导出、后导入数据库的方法清除之。
１ 队Ｃ Ｅ ． ０ Ｌ 数据块的物理设计及优化 ４
Ｏ ａｌ ｒｅ ｃ 数据块的大小由ｄ—ｏｋｓｅ ｂ ｌ ．ｚ参数 ｂｃ ｉ
（ 独立的回滚段和在线重写Ｂ志文件。 ３ ） 与事务相关数据被写入回滚段一样．事务的 记录被写入在线重写Ｂ志文件。 （） ４ 独立的在线重写Ｂ志文件和归档重 写 Ｂ志文件 。若数据库运行在归档 Ｂ志模 式（ Ｒ Ｈ Ｖ Ｌ Ｇ ．在线重写Ｂ志文件将 Ａ Ｃ ＩＥ Ｏ ） 会被归档。 在活动的高峰期． 联机和归档Ｂ
在创建数据库时 决定． 一旦数据库生 成则无
法修改。选择时要充分考虑操作环境的许可 状况．同时尽量减少行链接碎片和行迁移碎 片。 前者的产生是由于一行数据太大． 无法存
１ ． ３段和区空间的物理设计及优化
段和区空间物理设计及优化的目标 ． 是 尽量减少存储结构的动态扩展。动态扩展一 方面将运行复杂费时的Ｓ Ｌ Ｑ 语句存取数据字 典来发现并分配空闲空间：另一方面亦可导
Oracle数据库性能优化浅析
一
、
择 的联结 次序应 该让 最少 数 目的行 参加 到与 其他表 的联 结 中 。
（ ）有 效 的Ｗ Ｅ Ｅ 二 Ｈ Ｒ 子句 。Ｗ Ｅ Ｅ Ｈ Ｒ 子句 中 的选择 性条 件可 以显 著减 少Ｓ Ｌ 句 在 一 个 查 询 周 期 内得 到 的数 据 量 ，所 以在 构 建 Ｏ语 Ｗ Ｅ Ｅ 句时 ，遵 循 一些 原则 可 以提高语 句 的执行 效率 ： ＨＲ 子 １尽 可能 少的使 用通 配 符：如果 在ＷＥ Ｅ ． Ｈ Ｒ 子句 中有通配 符 ， 则 需要 对整 个数 据列 进行 模式 匹配 来检 索数 据 ，即数 据库 只 能跳过 索 引并进 行一 次全表 扫 描 。 ２使 用Ｗ ＥＥ ． Ｈ Ｒ 语句代 替Ｈ ＶＮ 语 句 ：Ｗ Ｅ Ｅ Ａ ＩＧ Ｈ Ｒ 子句 在 一开始 就 限 制 了被检 索 的行数 ，而Ｈ Ｖ Ｎ 子句则 需要 检索 比需要 的还要 多 的 Ａ ＩＧ
ｄ ｃ ｎ ａ ｂ ｓ ｐ ｒ ｒ ｎ ｅ ｈ ａ ｅ ｏ ｔ ｚｔ ｎ ｏ Ｑ ｔ ｅ ｎｓ ｈ ｄ ｓ ｎ ｏ ｍ ｒ， ｓ Ｏ ｔ ｅ ｄ ｓ ｅ ｔ ｅ ｌ ｅｉ ｄ ｔ ａｅ ｅ ｏｍａ ｃ， ｉ ｐ ｐｒ ｐｉ ａ ｏ ｆ Ｌ ｓ ｔ ｉ ｎ ａ ｆ ｔｓ ｍｉ ｉ Ｓ ａ ｍｅ ｔ ｔ ａｊ ｔ ｔ ｆ ， ｅ ｕ ｍｅ ｍｅ ｏ ｙ ｉ Ｉ ， ｒｅａ ｊ ｔ ｎ ｄｋ／ ｈ ｕｍ ｓ
数据 ，会 加重 求和和 排序 的负担 。 ３ 执 行有 效 的子查 询 ： ． 如果 子查 询有 选择 性 的Ｗ Ｅ Ｅ Ｈ Ｒ 子句 ， 最 好使 用 “ Ｎ Ｉ 子句 ”； 果父 查 询 Ｅ Ｉ Ｔ 子句 ” 。 （ ）高 效 的索 引策略 。索 引是 对一 个表 遍历 的快 速方 法 ， 三 它只 需要 查找 必要 的数 据行 ，而 不需 要进 行全 表扫 描 。如果 在一
ORACLE数据库性能调整与优化分析
ORACLE数据库性能调整与优化分析摘要Oracle数据库的主要作用是对多种业务形式进行处理，保障各项业务的稳定运行，因此，Oracle数据库应用系统性能优化至关重要。
对此，本文首先对Oracle数据库进行了介绍，然后对ORACLE数据库性能调整与优化的必要性进行了分析，并对具体的性能调整优化策略进行了详细探究。
关键词Oracle数据库；性能；优化前言现如今，oracle数据库技术日漸完善，其应用范围也越来越广泛，但是，随着数据信息的不断增加，oracle数据库的应用安全性也受到了较大威胁，在数据库信息的实际应用中，偷取、破坏等问题较为常见，这样就会影响oracle数据库的正常运行，甚至会造成信息丢失的问题。
因此，亟须对oracle数据库使用性能进行调整和优化。
1 Oracle数据库随着oracle数据库的快速发展，其规范性逐渐加强，使用性能也日渐完善，oracle数据库是一种通用型数据库，具有完善的数据管理功能，其害是一项关系型数据，在实际应用中，可以对中业务的数据关系进行仔细清理，从而构建出针对性较强的数据库结构形式，然后将所有信息数据传递至计算机终端，通过应用计算机终端相关软件，为oracle数据库运行提供良好的操作环境。
在oracle数据库的分布式操作环境中，可以对数据库中的各类信息进行及时更新，从而满足不同数据使用者的查询需要。
现如今，oracle数据库注意被应用于公共部门中，比如医院、银行等等，oracle数据库的内存结构形式如图1所示。
2 ORACLE数据库性能调整与优化的必要性数据库是一种数据集合，其具有组织性、共享性特征，并被长期存放于计算机中。
数据库系统是由很多部分所组成的，包括计算机硬件设备、计算机软件、数据库管理人员等等，在各项信息系统操作过程中，都需要依赖后台数据库的辅助。
在大数据时代，数据资源量逐渐增多，网络用户对于数据库的访问量逐渐增大，同时，对于数据库的访问要求也越来越高，很多数据信息被长期读取，并被修改和存储，这样很容易增加数据库负荷，导致数据库负载增加，很难对系统内部资源进行科学合理的分配，同时还会影响数据库的响应效率，无法更好地服务于数据库访问用户。
基于ORACLE系统的数据库性能优化设计
第 １ ４卷
第 ６期
北 京 印 刷 学 院 学 报
Ｊ ｕ ｎ ｌ ｆ ｅ ｉｇ Ｉｓｉ ｔ ｆ ｒ ｐ ｉ Ｃ ｍｍｕ ｉ ｔ ｎ ｏ ｒ ａ ｏ ｉｎ ｎ ｔ ｕｅｏ ａ ｈｃ ｏ Ｂ ｊ ｔ Ｇ ｎｃ ｉ ａｏ
２０ ０ ６年 １ ２月
ｔ ｔ ｎ ａｄ ｏ ｉ ｉ ｎ ｃ ｍｐ ｔ ｔ ｎ ｏ ｔ ｅ ｍｐ ｅ ｎ ｉ ｇ ｏ ｄ ｔ ｎ ｍａ ｏ ｕ ａ ｉ ｆ ｈ ｉ ｌ ｍｅ ｔｎ ｃ ｎ ｉ ｏ ． ｏ ｉ Ｔｈ ｅ ｆ ｒ ｎ ｅ ｏ ｔ ｚ ｔｏ ｎ ｔ ｅ ｄ ｓｇ ｒ ｃ ｓ ｓ ｃ ｒ ｅ ｐ ｒｏ ｍａ ｃ ｐ ｉ ａ ｉ ｎ ｉ ｈ ｅ ｉ ｎ ｐ ｏ ｅ ｓ ｉ ａ — ｍｉ
序 中加入大 量管 理完 整性 代码 ， 会增 加 服 务 器 的 还
ｒｃ ｕ ｎｔ ｅｐ ｒ ｐ ｃｉｅ ｆｔ ｅｄ ｔｂ ｓ ｏ ｉａ ｔｕ ｔｒ ｉｄ ｏ ｔｉ ｈ ｅｓ ｅ ｔ ｓｏ ｈ ａａ ａｅ ｌｇｃ ｌｓｒｃ ｕ ｅ ｖ ａ ｄ ｔ ｅｐ ｙ ｉａ ｎ ，ｒｓ ｅ ｔｖ ｌ． Ｔｈ ｅ ｆｒ ｎ ｅｏ ｈ ｎ ｈ ｈ ｓｃｌｏ ｅ ｅ ｐ ｃｉｅｙ ｅ ｐ ｒｏｍａ ｃ ｆｔ ｅ
有效 的数据 库 应用 系统性 能优 化解决 方 案 。
Ｄａ ａ ａ ｅ Ｂａ ｅ ｎ ｔ ｅ Ｏｒ ｃｅ Ｓ ｓｅ ｔ ｂ ｓ ｓ ｄ ｏ ｈ ａ ｌ ｙ ｔｍ
ＬＩＸｕ － ｉｎ ＬＵＯ ｈ ｎ — ｉｎ ｅ ｑａ ｇ， Ｓ ｅ ｇ ｘａ
（ ｅ ｇ ｕ Ｕｎｖ ｒ ｉ ｆＴｅｈ ｌｇ ， Ｃｈ ｎ ｄｕ６１ ０ ９，Ｃｈｎ ） Ｃｈ ｎ ｄ ｉｅｓｔ ｏ ｃ ｎｏｏ ｙ ｙ ｅｇ ０ ５ ｉａ
ｌ 逻 辑 结 构 的 优 化
Oracle数据库性能优化方法
［ 中图分类号］ＴＰ １． ３ ［ ３ Ｉ１ 文献标识码］Ａ ［ 文章编 号］１ ７ — ３ ９ ２ ０ ）３ ０ ３ —２ ６ ３ ９２ （０ ７ ０ —０ ２ ０
０ 概 述
Ｏ ａｌ 数 据 库 是 一 个 高 性 能 的 大 型 数 据 库 ， 内外 的 ｒｃ ｅ 国 很 多 企 业 、 府 单 位 及 电 子 商 务 网 站 都 采 用 Ｏｒｃｅ 为 数 政 ａｌ 作 据库 服务 器 ． ａｌ 分 考 虑 了 Ｒ Ｂ Ｏｒｃ ｅ充 Ｄ ＭＳ的性 能 、 活 性 与 灵 稳定 性． 只要 数 据 库 设 计 合 理 ， 确 配 置 实 例 ， 供 规 模 足 正 提 够 的 服务 器 和 性 能 优 异 的硬 件 ， 并正 确调 整操 作 系 统 ， 可 就 以得 到很 好 的 性 能 ． Ｏｒｃｅ 据 库 的优 化 没 有 绝 对 的 指 标 ， 常 用 优 化 前 ａｌ 数 通 后 数 据 库 的各 种性 能 指 标 作 为 评 价 依 据 ， 比如 Ｓ ＱＬ语 句 的 执 行 速 度 ， 据 库 的命 中 率 ， 源 占 用 情 况 等 等． 化 工 作 数 资 优 通 常 是 由 一 系 列 的 “ 衷 ” 组 成 ． 旦 用 户 识 别 出 瓶 颈 问 折 所 一 题 所 在 ， 可 能 需 要 牺 牲 其 他 系 统 资 源来 获 得 预 期 的效 果 ． 就 １ Ｏ ａｌ 数 据 库 的优 化方 法 ｒｃ ｅ
许 华 容
（ 州 大学 计 算 机 科 学 与技 术 学 ，贵 阳 ５ ０ ２ ） 贵 ５ ０ ５
［ 摘
要 ］Ｏｒｃｅ 据 库 是 现 在 使 用 最广 泛 的大 型 数 据 库 之 一 ， 性 能 的优 化 为 大 量 用 户 所 关 注 的 焦 点 ． 文 从 Ｏｒ ａｌ 数 其 本 ａ
Oracle数据库的性能优化
Ｔ Ｂ级 ，磁 盘 的 输 入 ／ 出数 据 量 很 高 ，但 输
对 响应 时 间 要求 不 高 。
（ ２）销 账 系 统 。 主 要 负 责 缴 费 销 账 ， 面 对 的 是 前 台 营 业 员 以 及 电 信 客 户 ， 用
户 数 多 ， 数 据 库 连 接 数 可 以 达 到 ３００ 以 上 ， 数 据 量 一 般 在 ３ ０ ＧＢ 左 右 ， 磁 盘 的 ０
维普资讯
电信投 求
。
袁 胜 中
数 据 库 的
性能优 化
武 汉 电信分公 司 武汉 ４０ ３ ０７ １
Ｏｒ ｃ ｅ数 据 库 在 运 行 过 程 中 会 产 生 大 ａｌ
不 影 响 外 界 对 数 据 库 的 访 问 ， 这 样 可 以 实 现 故 障 的 无 缝 切 换 ） 从 电信 计 费 系统 。
统 ，主 要 负 责 采 集 用 户 的 原 始 话 单 ，并 根 据 计 费 策 略 和 规 则 进 行 账 务 结 算 ， 最 后 形 成 用 户 的 缴 费 信 息 。 计 费 系 统 的 主 要 使 用 对 象 是 计 费 人 员 ，用 户 数 少 ，数 据 库
连接 数一 般在 ４ ０～ ５ ０个 ， 数 据 量 一 般 在
单 点故 障 时能 够保 证 对 外服 务不 问断 。 电信 计 费 系统 从 功能 和 运 行 特 点上 可 以划 分 为 如下 两个 部 分 。 （１ ） 计 费 系 统 。 它 是 一 个 批 处 理 系
据 ， 同时 使 统 计 人 员 取 得 所 需 的 计 费 数 据
为 经营 分 析提 供决 策 依 据等 。
该 区 域 的 调 整 主 要 是 根 据 应 用 环 境 调 整 ｋ ｅ 池 、循 环 池 和 默 认 池 ｅＰ
让Oracle跑得更快
让Oracle跑得更快—Oracle 10g性能分析与优化思路目录第1章引起数据库性能问题的因素11.1 软件设计对数据库的影响11.1.1 软件架构设计对数据库性能的影响11.1.2 软件代码的编写对数据库性能的影响21.2 数据库的设计81.2.1 OLTP数据库91.2.2 OLAP数据库101.3 数据库的硬件设计141.3.1 存储容量151.3.2 存储的物理设计161.3.3 数据的安全171.4 小结19第2章锁和阻塞202.1 关于锁202.2 锁和阻塞222.3 引起阻塞的其他情况302.3.1 select for update 302.3.2 外键和索引36第3章Latch和等待443.1 共享池中的Latch争用45.3.2 数据缓冲池Latch争用543.2.1 表数据块543.2.2 索引数据块593.2.3 索引根数据块623.2.4 段头数据块65第4章优化器664.1 RBO基于规则的优化器664.2 CBO基于成本的优化器69第5章执行计划855.1 Cardinality （基数）855.2 SQL的执行计划94第6章Hint 1096.1 和优化器相关的Hint 1156.1.1 all_rows和first_rows（CBO）1156.1.2 RULE Hint 1176.2 访问路径相关的Hint 1176.2.1 FULL Hint 1186.2.2 INDEX Hint 1186.2.3 NO_INDEX Hint 1186.2.4 INDEX_DESC Hint 1196.2.5 INDEX_COMBINE Hint 1196.2.6 INDEX_FFS 1196.2.7 INDEX_JOIN 1206.2.8 INDEX_SS Hint 1206.3 表关联顺序的Hint 1256.3.1 LEADING Hint 1256.3.2 ORDERED Hint 1266.4 表关联操作的Hint 1276.4.1 USE_HASH，USE_NL和USE_MERGE Hint 127 6.4.2 NO_USE_HASH Hint 1326.4.3 NO_USE_MERGE Hint 1336.4.4 NO_USE_NL Hint 1336.5 并行执行相关的Hint 1346.5.1 PARALLEL Hint 1346.5.2 NO_PARALLEL Hint 1346.6 其他方面的一些Hint 1356.6.1 APPEND Hint 1356.6.2 DYNAMIC_SAMPLING Hint 1356.6.3 DRIVING_SITE Hint 1366.6.4 CACHE Hint 1366.7 小结136第7章分析及动态采样1387.1 直方图1417.2 DBMS_STATS包1477.3 动态采样1767.3.1 什么是动态采样1767.3.2 动态采样的级别1827.3.3 什么时候使用动态采样？1857.4 小结185第8章并行执行1868.1 并行和OLAP系统1878.2 并行处理的机制1898.3 读懂一个并行处理的执行计划1918.4 一个很常见的并行执行等待事件1928.5 并行执行的适用范围1948.5.1 并行查询1948.5.2 并行DDL操作1958.5.3 并行DML操作2038.6 并行执行的设定2108.6.1 并行相关的初始化参数2108.6.2 并行度的设定2118.7 直接加载2138.7.1 直接加载和REDO 2168.7.2 直接加载和索引2198.7.3 直接加载和并行2218.7.4 直接加载和SQL*LOADER 226第9章变量绑定2329.1 什么是变量绑定，为什么要做变量绑定2329.2 为什么说OLTP必须要求变量绑定而OLAP不应该绑定变量241 9.3 bind peaking 248第10章SQL_TRACE和10046事件25410.1 SQL_TRACE 25410.2 TKPROF工具25610.3 10046事件268第11章10053事件276第12章性能视图和性能参数29412.1 性能视图29412.1.1 V$SQL 29512.1.2 V$SQL_SHARED_CURSOR 30012.1.3 v$session 30512.1.4 V$sessstat 30912.1.5 V$session_wait 31012.2 性能参数31212.2.1 Cursor_sharing 31312.2.2 DB_FILE_MULTIBLOCK_READ_COUNT 32812.2.3 PGA_AGGREGATE_TARGET和SGA_TARGET 33412.2.4 OPTIMIZER_DYNAMIC_SAMPLING 334第13章性能报告33513.1 AWR性能报告33513.1.1 生成AWR性能报告33713.1.2 AWR性能报告分析34213.2 Statspack性能报告38613.2.1 Statspack的安装38613.2.2 Statspack性能采集39113.3 ASH性能报告39413.3.1 生成ASH性能报告39513.3.2 ASH性能报告分析40513.4 小结416附录A 常见的等待事件417后记关于数据库的学习方法434。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
O r a c l e物理设计及性能优化设计资料整理汤延涛yantao929@2007-12-20目录1前言 (1)2硬件体系构架 (1)2.1SMP (1)2.2MPP (2)2.3PVFS(并行虚拟文件系统) (4)2.3.1概述 (4)2.3.2PVFS的存取机制 (5)2.3.3PVFS的应用实例与性能 (7)2.4OPS(O RACLE P ARALLEL S ERVER) (8)2.4.1体系结构 (8)2.4.2并行处理 (9)2.4.3分区技术 (12)3ORACLE体系结构 (12)3.1内存结构和进程结构 (12)3.2O RACLE实例 (13)3.3O RACLE 10G动态内存管理 (14)3.3.1系统全局区SGA（System Global Area） (14)3.3.2Oracle实例的进程结构（Process Structure） (22)4存储管理 (28)4.1ASM（自动存储管理） (28)4.2DMT,LMT,ASSM (28)4.3自动管理问题 (32)5时间空间转换平衡 (32)5.1数据压缩 (32)5.2索引机制分析 (32)5.2.1Index full scan VS Index fast full scan (32)5.2.2Index range scan VS Index skip scan (33)6设计注意问题 (34)6.1字符集问题 (34)6.2代理主键 (34)6.3程序监控 (34)6.4临时表空间和回滚表空间释放 (34)6.5并行操作 (34)6.6关于APPEND提示 (35)6.7数据库统计信息收集 (35)7SQL语句优化 (35)7.1选用适合的ORACLE优化器 (35)7.3共享SQL语句 (36)7.4选择最有效率的表名顺序 (37)7.5WHERE子句中的连接顺序 (38)7.6SELECT子句中避免使用‘*‘ (38)7.7减少访问数据库的次数 (38)7.8使用DECODE函数来减少处理时间 (39)7.9整合简单,无关联的数据库访问 (40)7.10删除重复记录 (41)7.11用TRUNCATE替代DELETE (41)7.12尽量多使用COMMIT (41)7.13计算记录条数 (41)7.14用W HERE子句替换HAVING子句 (41)7.15减少对表的查询 (42)7.16通过内部函数提高SQL效率 (43)7.17使用表的别名(A LIAS) (44)7.18用EXISTS替代IN (44)7.19用NOT EXISTS替代NOT IN (44)7.20用表连接替换EXISTS (45)7.21用EXISTS替换DISTINCT (45)7.22识别“低效执行”的SQL语句 (46)7.23使用TKPROF工具来查询SQL性能状态 (46)7.24用EXPLAIN PLAN分析SQL语句 (47)7.25用索引提高效率 (48)7.26索引的操作 (48)7.27基础表的选择 (50)7.28多个平等的索引 (50)7.29等式比较和范围比较 (51)7.30不明确的索引等级 (51)7.31强制索引失效 (52)7.32避免在索引列上使用计算 (53)7.33自动选择索引 (54)7.34避免在索引列上使用NOT (54)7.35用>=替代> (55)7.36用UNION替换OR(适用于索引列) (56)7.37用IN来替换OR (58)7.38避免在索引列上使用IS NULL和IS NOT NULL (59)7.39总是使用索引的第一个列 (59)7.40ORACLE内部操作 (60)7.41用UNION-ALL替换UNION(如果有可能的话) (60)7.42使用提示(H INTS) (61)7.43用WHERE替代ORDER BY (62)7.44避免改变索引列的类型 (63)7.45需要当心的WHERE子句 (64)7.47CBO下使用更具选择性的索引 (66)7.48避免使用耗费资源的操作 (66)7.49优化GROUP BY (66)7.50使用日期 (67)7.51使用显式的游标(CURSORS) (67)7.52优化EXPORT和IMPORT (67)7.53分离表和索引 (68)1前言要对数据库进行优化，首先要从数据库的设计方面入手，包含数据的概念模型，逻辑模型，物理模型（设计对以后的优化维护起决定性的作用，好的设计是优化维护的决定性条件）；所以：在设计阶段一定要确定好系统的模型构架，逻辑构架，硬件构架等，尽量做到软件和硬件的无缝结合；维护只是对程序的处理流程和相关的SQL进行调整，而不会太多涉及到对结构的调整；本文主要在硬件体系结构，存储管理机制，数据压缩，SQL语句优化等几个方面进行数据库设计及程序开发方面的描述。
备注：（此文档仅用于内部交流，文档中引用从网上收集的图片等资料，为了保持格式及一致性，没有将引用来源加入文档中，如果侵犯个人或团体利益，请告知，我们将从文档中删除此部分内容或者添加参考资料来源）2硬件体系构架2.1 SMPSMP的全称是"对称多处理"（Symmetrical Multi-Processing）技术，是指在一个计算机上汇集了一组处理器(多CPU),各CPU之间共享内存子系统以及总线结构。
它是相对非对称多处理技术而言的、应用十分广泛的并行技术。
在这种架构中，一台电脑不再由单个CPU组成，而同时由多个处理器运行操作系统的单一复本，并共享内存和一台计算机的其他资源。
虽然同时使用多个CPU，但是从管理的角度来看，它们的表现就像一台单机一样。
系统将任务队列对称地分布于多个CPU之上，从而极大地提高了整个系统的数据处理能力。
所有的处理器都可以平等地访问内存、I/O和外部中断。
在对称多处理系统中，系统资源被系统中所有CPU共享，工作负载能够均匀地分配到所有可用处理器之上。
我们平时所说的双CPU系统，实际上是对称多处理系统中最常见的一种，通常称为"2路对称多处理"，它在普通的商业、家庭应用之中并没有太多实际用途，但在专业制作，如3DMax Studio、Photoshop等软件应用中获得了非常良好的性能表现，是组建廉价工作站的良好伙伴。
随着用户应用水平的提高，只使用单个的处理器确实已经很难满足实际应用的需求，因而各服务器厂商纷纷通过采用对称多处理系统来解决这一矛盾。
在国内市场上这类机型的处理器一般以4个或8个为主，有少数是16个处理器。
但是一般来讲，SMP结构的机器可扩展性较差，很难做到100个以上多处理器，常规的一般是8个到16个，不过这对于多数的用户来说已经够用了。
这种机器的好处在于它的使用方式和微机或工作站的区别不大，编程的变化相对来说比较小，原来用微机工作站编写的程序如果要移植到SMP机器上使用，改动起来也相对比较容易。
SMP结构的机型可用性比较差。
因为4个或8个处理器共享一个操作系统和一个存储器，一旦操作系统出现了问题，整个机器就完全瘫痪掉了。
而且由于这个机器的可扩展性较差，不容易保护用户的投资。
但是这类机型技术比较成熟，相应的软件也比较多，因此现在国内市场上推出的并行机大量都是这一种。
PC服务器中最常见的对称多处理系统通常采用2路、4路、6路或8路处理器。
目前UNIX服务器可支持最多64个CPU 的系统，如Sun公司的产品Enterprise 10000。
SMP系统中最关键的技术是如何更好地解决多个处理器的相互通讯和协调问题。
要组建SMP系统，首先最关键的一点就是需要合适的CPU相配合。
我们平时看到的CPU都是单颗使用，所以看不出来它们有什么区别，但是，实际上，支持SMP功能并不是没有条件的，随意拿几块CPU来就可以建立多处理系统那简直是天方夜谈。
要实现SMP功能，我们使用的CPU必须具备以下要求：1、CPU内部必须内臵APIC（Advanced Programmable Interrupt Controllers）单元。
Intel 多处理规范的核心就是高级可编程中断控制器（Advanced Programmable Interrupt Controllers--APICs）的使用。
CPU通过彼此发送中断来完成它们之间的通信。
通过给中断附加动作（actions），不同的CPU可以在某种程度上彼此进行控制。
每个CPU有自己的APIC（成为那个CPU的本地APIC），并且还有一个I/O APIC来处理由I/O设备引起的中断，这个I/O APIC是安装在主板上的，但每个CPU上的APIC则不可或缺，否则将无法处理多CPU之间的中断协调。
2、相同的产品型号，同样类型的CPU核心。
例如，虽然Athlon和Pentium III 各自都内臵有APIC单元，想要让它们一起建立SMP系统是不可能的，当然，即使是Celeron和Pentium III，那样的可能性也为0，甚至Coppermine核心的Pentium III和Tualatin的Pentium III也不能建立SMP系统--这是因为他们的运行指令不完全相同，APIC中断协调差异也很大。
3、完全相同的运行频率。
如果要建立双Pentium III系统，必须两颗866MHz 或者两颗1000MHz处理器，不可以用一颗866MHz，另一颗1000MHz来组建，否则系统将无法正常点亮。
4、尽可能保持相同的产品序列编号。
即使是同样核心的相同频率处理器，由于生产批次不同也会造成不可思议的问题。
两个生产批次的CPU作为双处理器运行的时候，有可能会发生一颗CPU负担过高，而另一颗负担很少的情况，无法发挥最大性能，更糟糕的是可能导致死机，因此，应该尽可能选择同一批生产的处理器来组建SMP系统。
2.2 MPPSMP系统与MPP系统比较（说明：SMP集群系统和MPP比较更有意义）SMP (Symmetric Multi Processing),对称多处理系统内有许多紧耦合多处理器，在这样的系统中，所有的CPU共享全部资源，如总线，内存和I/O系统等，操作系统或管理数据库的复本只有一个，这种系统有一个最大的特点就是共享所有资源。
MPP (Massively Parallel Processing)，大规模并行处理系统，这样的系统是由许多松耦合的处理单元组成的，要注意的是这里指的是处理单元而不是处理器。
每个单元内的CPU都有自己私有的资源，如总线，内存，硬盘等。
在每个单元内都有操作系统和管理数据库的实例复本。
这种结构最大的特点在于不共享资源。
既然有两种结构，那它们各有什么特点呢？采用什么结构比较合适呢？通常情况下，MPP系统因为要在不同处理单元之间传送信息（请注意上图），所以它的效率要比SMP要差一点，但是这也不是绝对的，因为MPP系统不共享资源，因此对它而言，资源比SMP要多，当需要处理的事务达到一定规模时，MPP的效率要比SMP好。