内存结构

现代计算机中，CPU 对内存的访问速度要比从磁盘的速度快千倍，因此 Oracle 对于数据的访问 也尽量都在内存中完成，而不是直接修改硬盘上的数据。内存内容在合适的时候再同步到磁盘。 Oracle 利用内存来克服磁盘 IO的束缚，在内存中进行活动越多，系统性能越好，反之，在磁盘上进 行的操作越多，系统性能越差。

Oracle 是一个内存消耗大户，它消耗的内存可以分成两部分——进程共享部分和进程专有部分。 这里的进程专指Oracle 进程（Server Process 和Background Process），进程共享部分就叫做 SGA （Shared Global Area ），进程专有部分就叫做 PGA （Program Global Area）。

对于不同类型的应用系统，这两个部分的意义也不同。对于OLTP系统，其特征大量的小事务， SGA 要比PGA更为重要。对于OLAP 系统来说，其特征是大数据量的关联，因此PGA 要比SGA 对系统的影响更大。因为PGA 直接决定了大的排序、哈希操作效率。

1.SGA

SGA 是一大块内存的总称，其内部分成若干组成部分,每个部分都有独特的作用。

2．Data Buffer Cache

由Server Process 从磁盘读入的数据就放在这块内存中。而修改数据时，也是在这个区域中对数 据进行修改。Data Buffer Cache 中会同时保留数据库被修改前（Before Image，前镜像）和被修改后 （After Image ，后镜像）的拷贝。

Data Buffer Cache 中的内存可以被分成 3 类:

• Free Buffers：指那些不包含任何数据的内存，这些内存可以用来装载以后读入的数据。
• Dirty Buffer：这部分包含被修改过的，但是还没有写到磁盘上的数据块。
• Pinned Buffer：正在被用户使用的内存。

当用户进程请求数据时，Oracle 首先查看数据是否已经在 Data Buffer Cache 中，如果数据已在 Data Buffer Cache 中，则 Server Process不必再访问磁盘，直接从 SGA 中读取数据就可以了。如果 数据还没有加载到SGA ，Server Process就必须从磁盘读入数据，但是在读入之前，Server Process 必须保证Data Buffer Cache 中有足够的 Free Buffer 来容纳这些数据，如果Server Process在扫描一 定数量的Buffer 后还没有找到Free Buffer ，它就会通知DBWn 进程把Dirty Buffer写到磁盘上，一 旦些完成，原先这些Dirty Buffer 就变成 Free Buffer ，就可以重用了。

究竟把哪些个Dirty Buffer 写到磁盘？这就会用到LRU（Least Recently Used）算法了，这种算 法确保最近越少被使用的数据块，越先被写到磁盘，空间越先被释放。这种算法是基于这样一个假 设：“越近被用到的数据，就越有可能被再次用到”。在 Data Buffer Cache 中，不仅有一个 LRU List 存在，而是同时使用多个 LRU List ，如 Free Buffer 、Dirty Buffer 、Pinned Buffer 都是使用LRU算法。

（1）按照用途不同的多个 Buffer Cache。

大部分情况下数据库有一个缺省的Buffer Cache放置所有的数据就足够了，不过 Oracle 允许通 过多个Buffer Cache进行微调。

数据库中的不同数据的访问频率是不一样的，像用户属性、商品列表这种字典型数据可能需要 经常使用，因此这类数据应该尽可能久的放在 Buffer Cache中，而一些日志型数据只会偶尔采用到， 这类数据就应该尽快地从Buffer Cache中移走，以释放空间。对于符合这种特点的应用来说，Oracle 提供了其他两种Buffer Cache——Keep Buffer Pool和Recycle Buffer Pool，再加上缺省的 Buffer Cache 就有3 种Buffer Pool 了。这 3 种的区别在于对其中数据的保留策略，Keep就是保留得尽量久，而 Recycle就是尽快释放，如表所示。

Buffer Pool 名称	初始化参数	说 明
Keep Buffer Pool	DB_KEEP_CACHE_SIZE	这个区域内的数据会尽可能久地保留在内存中。 对于那些体积较小、访问频繁的表，比如用户属 性表，可以考虑放在这个Cache 中，以提高访问 速度
Recycle Buffer Pool	DB_RECYCLE_CACHE_SIZE	放在这个区域中的数据一用完就会被移出。对于 那些体积巨大、偶尔使用的日志表，可以考虑放 在这个内存中，以尽快释放内存
Default Buffer Pool	DB_CACHE_SIZE	缺省的Cache

（2 ）按照数据块大小的多个 Buffer Pool 。

除了按照保留时间划分Buffer Cache，Oracle 还可以按照数据块的大小分配多个 Buffer Cache。 Oracle 10g 中允许创建不同数据块大小的表空间，DBA 在创建数据库时需要使用的 DB_BLOCK_SIZE 参数，这个参数决定的是数据库标准数据块大小，以后创建的表空间缺省会继承 这个块大小。但是DBA也可以用其他数据块大小创建表空间，最多可以使用5 种不同数据块大小 （2KB 、4KB 、8KB 、16KB、32KB），这些表空间叫做非标准数据块大小的表空间。要想在一个数据 库内同时使用多种数据块大小，一个重要的条件就是必须要配置对应的非标准Buffer Cache。对应 参数是DB_nK_CACHE_SIZE。

之前提到的Keep Buffer Pool、Recycle Buffer Pool都只用于标准数据块。而Default Buffer Pool 则是由所有的标准和非标准Buffer Pool 组和在一起的。所谓标准、非标准是根据创建数据库时指定 的DB_BLOCK_SIZE 而言的，如果这个值是2KB ，那么其他的4KB 、8KB 、16KB、32KB 就叫做 非标准数据块。如果定义成 32KB，那么 2KB 、4KB 、8KB 、16KB 就叫做非标准数据块。

3．Shared Pool

Shared Pool是SGA 中另一个非常重要的区域，尤其对于OLTP系统来说，Shared Pool配置对 于系统性能的意义尤为重要。和 Data Buffer Cache 存放的是用户数据不同，Shared Pool 中存放的是 代码，包括PL/SQL 代码、SQL 语句以及数据字典信息。Shared Pool又可以分成 Library Cache 和 Dictionary Cache两个区域。

如果用户有过其他语言的开发经验，一定知道编译过程，也就是要把用户代码转换成机器语言，比如Java 语言要把*.java 文件编译成.class 文件。数据库也是一样，用户提交的无论是用 PL/SQL 编 写的存储过程或者纯粹的SQL 代码，这些代码都是基于人类语言编写的，要想计算机能够执行这些 代码，首先要把它们编译成 CPU 可识别的机器代码，这个过程就是编译。而编译产生的机器代码就 保存在Library Cache 中，Shared Pool 是一个所有用户可以共享的区域，这样就可以获得两个好处： 首先，用户如果再次执行同一段代码时，就可以省掉解析过程，直接重用先前生成的机器代码；其 次，如果其他用户执行相同代码，也能够重用，减少解析。

一个SQL 语句完整执行过程可以分成 4 个阶段:

（1） 解析。 
在这个阶段，要进行语义、语法分析、权限检查，包括语句是否拼写正确、是否有语法错误、 数据库是否有a 这个对象、用户是否有 a 的访问权限等。

这些检查通过后，再检查这个语句之前是否已经解析过了。Oracle 对每个语句都会计算出哈希 值，用这个值在Shared Pool 中查看是否有对应的执行计划。如果有，就说明这个语句曾经执行过， 已有的执行计划拿过来就可以使用，而不再需要执行下面的（2 ）、（3）步（这也就是只进行软解析 Soft Parse）；如果没有，则必须（1 ）、（2 ）、（3 ）步都执行完后才能产生执行计划（也就是所谓的 Hard Parse）。

（2 ）优化。

这个阶段根据对象的统计信息、当前选择的优化器模式（CBO/RBO）来确定最佳访问路径。所 谓对象的统计信息，比如一个表里面有多少条记录、每条记录平均长度、占据多少个数据块、索引 的高度等。这些信息记录在系统字典中，比如user_tables.num_rows 。

另外一个影响优化的因素是“优化器模式”（Optimizer Mode ）。这个配置是告诉 Oracle 希望如 何返回记录，比如 first_rows_n代表尽快返回头 n 条记录；all_rows 代表着尽快返回整个记录集，而 不关心头几条的返回速度。模式不同会产生不同的执行计划。

根据这两类信息，Oracle 的优化起引擎会产生多个访问路径，如全表扫描、索引扫描、Nest Loop Join 或Hash Join 等，Oracle 会计算每种访问路径的成本，把成本最小的访问路径作为最佳路径。

（3 ）产生执行计划。

这一阶段根据上一阶段产生的最小成本的访问路径，生成最终的执行计划。

（4 ）返回查询结果。

依据上一步的执行计划，访问数据获得结果集，返回给用户。如果是DML语句，而修改数据 并返回结果。
前3 个阶段是资源密集型操作，包括 CPU 、Latch、Lock各种资源，对于系统性能影响比较明 显。而Shared Pool 的目的就是为了减少前 3 个阶段的活动。

Library Cache 中存放的代码部分，Dictionary Cache中存放的数据字典信息。在解析阶段，解析 器要判段表名、列名是否正确、用户是否有权限执行请求的操作，这些信息就是数据字典，包括在 接下来的优化阶段，CBO生成执行计划所用到的对象统计数据都来自于数据字典。如果这些数据不 在内存中，Oracle 就需要从数据字典把这些数据读入 Dictionary Cache。数据字典在 Dictionary Cache 缓存的越多、保留时间越长，解析时间越短，系统性能越好。

4．Redo Log Buffer

Redo Log Buffer 使用来保存Redo 记录，和 Buffer Cahce、Shared Pool 比起来，这个区域空间 非常小，通常只有几MB。当一个Server Process 改变 Data Buffer Cache 中的数据时（DML操作）， 就会产生Redo记录，这些记录保存在 Redo Log Buffer 中。LGWR 进程负责把Redo Log Buffer 中的 内容写到磁盘上的Redo Log File 中。

Redo Log Buffer是采用循环方式工作的，一旦LGWR 进程把日志内容写到磁盘，LGWR 就可 以覆盖这块内容。LGWR 通常是系统中最繁忙的进程，Oracle 提供了一种 Nologging技术可以跳过 Redo Log生成，从而减少 LGWR 的负载，不过这个技术只是在有限的几种场合有用，比如直接数 据加载。

5．Large Pool 、Java Pool、Stream Pool

这几个内存组件相对来说就不是很重要了，Large Pool 最主要的用途就是供 RMAN 备份和共享 连接模式。Java Pool 用于支持 Java 虚拟机（JVM ），Stream Pool 用于支持流。

6．SGA自动管理

在Oracle 10g之前的版本中，SGA 各个组件的调整也是 DBA的日常工作之一。从 Oracle 10g开 始，这个区域能够自动调整了，这个特性是Oracle 自动管理功能的一部分，用户只需要设置一个新增 的参数 SGA_TARGET就可以实现 SGA 的自动调整。SGA 自动调整见后面章节。

PGA

对于每个服务进程、后台进程，Oracle 都会为其分配一个 PGA ，这块内存区域用于保存每个用 户的私有数据。和SGA 的共享不同，PGA 是排他使用的。PGA 可以分成两部分。

• Private SQL Area：这块区域用于保存 SQL 绑定变量信息，虽然 SQL 语句的执行计划可以 共享，但是每个用户的绑定变量信息却要保存在 PGA 中；OPEN_CRUSRO 定义的就是在 这块区域中，用户保留的 Cursor 数量。

• Runtime Area：每当 Session 执行一个语句时分配的空间，这块空间可以用于数据排序、 Hash、连接等，当语句执行完毕后，这块区域就被 Oracle 释放了。

为了减少用户等待时间，加快响应速度，Oracle 会尽量在内存中完成排序、Hash、连接等操作， 这块内存就是PGA 的Runtime Area 中。如果操作能够在内存中完成，不需要磁盘IO，这种操作就 叫做Optimal Mode Operation。否则，如果不能在内存中完成，就会把部分中间数据先转移到磁盘上， 这种操作就叫做One（Multiple）-Pass（一路或多路）Operation。磁盘操作会降低系统性能。因此 PGA 大小和性能有密切关系。这些内存区域通过 SORT_AREA_SIZE、HASH_AREA_SIZE、 BITMAP_AREA_SIZE 定义。

Oracle 9i 开始引入了 PGA 的自动管理，通过把WORKAREA_SIZE_POLICY设置为AUTO 来 启用PGA 自动管理，如果这个参数设置成 MANUAL，就退回到手动管理。自动管理只需要定义一 个参数PGA_AGGREGATE_TRAGET 就好了。PGA 自动管理对于内存使用效率更高，比如如果使 用手动管理，那么每个会话分配的 PGA 不会自动归还给系统，无论会话是否执行操作还是 IDLE 状 态，都必须在用户退出后（Log Off）PGA 空间才会归还给系统，这就可能造成大量内存被闲置，而 真正需要工作的会话有无法获得足够的PGA ，而自动管理中，一旦会话执行的操作结束，使用的 Runtime-Area 就会自动归还给操作系统。

转载自：http://www.sunansheng.com/2016/04/29/oracle-memory/

一、Oracle EBS的组织架构

        软件系统的“组织设置”必须以业务流程运作为核心，要求尽可能简单并保持相对稳定，在公司（人员）规模扩大的过程中具有延续性与继承性。 
        ORACLE  EBS系统组织划分为“业务组（Business Group）、法律实体（Legal Entity）、业务实体（Operating Unit）、库存组织（Inventory Org）”等，与企业实际的行政组织不是完全等同的概念，而是基于系统业务运作需要而设定的。

二、业务组（BG，Business Group）

“业务组”的概念可以视同企业的“集团”概念，但不同的是一个企业在系统中可以设置多个“业务组（集团）”。 
通常对于一个企业来说，系统中有一个“业务组”就够了，这表示企业就是一个“集团公司”。而对于某些业务“多元化”的特大型公司（如跨国公司），则可能需要在系统中设置多个“业务组”，表示企业由多个“集团公司”组成。 
业务组设置是系统组织设置的第一步，是最高层级的组织形态，但它主要是与人力资源信息的分隔有关，即“人员信息”的设置在一个BG范围内是由各业务模块共享的（如果需要）。一旦系统设置的用户名（User）被与“人员”（Employee）关联，无论使用什么“责任”进入系统，都会定位至一个确定的BG中，任何责任在任意时刻只能关联一个BG。EBS安装好后，系统里面已经预置了一个名为“Setup Business Group”的“初始业务组”。

三、法律实体（LE，Legal Entity）

对应实际的按国家法律法规注册的法人公司。 
R12中在定义“分类帐”时的“会计科目设置管理器”WEB中定义并分配法人实体LE。一个分类帐设置（主辅分类帐）可以添加多个LE，但每个LE只能具有一个分类帐设置。 
业务实体（OU，Operating Unit）是EBS系统组织设置的重点也是难点之一。它与法人主体LE本身没有必然的关系，与会计科目弹性域结构中的“公司段”也没有直接关系。
从企业实际业务管理需要的角度去看，业务实体OU可以看作是在系统中按照业务的相似性，把多个不同公司（包括LE）的业务处理过程及数据划分成相对独立的“管理单元”。在每个管理单元内部，各公司的业务运作共享相关数据并执行统一的业务策略。

四、库存组织（Inventory Org）

不是真实业务的“仓库管理部门”那么简单，它除了是有“物料接收与发出”等业务功能之外，更重要的是，它还是EBS系统有关计划（MPS主生产计划/MRP物料需求计划）、在制品管理（WIP）、物料清单（BOM）等模块业务功能的操作与管理平台。 
在EBS中还有两个组织概念“MRP组织、WIP组织”，它们实际是必须构建于库存组织之上的组织概念，表示该库存组织还可以进行MRP或WIP的功能。系统之所以如此处理，主要是为了控制某些INV不能做MRP或WIP而已，因为基于物料接收或发出需要所设定的INV数量可能比较多。
对于绝大多数基于库存组织INV的业务功能（个别除外），系统用户在做业务操作时，均必须首先进行INV的选择切换，以便进入确定的INV上下文环境。库存组织的作用是如此基础，以至于EBS的相关文档在提及组织（Org）概念时，如果未作特别说明，默认就是指INV组织。 
一个库存组织INV只能属于一个确定的帐套SOB、一个确定的法人实体LE、一个确定的业务实体OU。反之，一个“帐套/法人实体/业务实体”组合则可以有多个库存组织INV。 

五、HR组织

系统的HR组织设置是与HRM模块的相关业务处理功能相关，与核心业务、财务处理功能关系不大

六、资产组织

“资产组织”的设置，它是在企业需使用到资产管理模块FA时才涉及到。“资产组织”实际上是所谓“资产账簿”的代名词，它只是表示有关资产信息的一个数据维度，作用主要在于分隔数据范围

七、多组织访问控制

EBS组织设置界面中，所谓的组织“类型”（Type）划分仅是基于组织自身的统计分析工作需要而定义的一个“维度”，例如“公司总部、产品线”等等，并不影响系统的业务处理功能。真正起作用的是设置界面中的“组织分类”，系统预置的组织分类LOV除了上述“业务组、法律实体、业务实体、库存组织”等之外，还有诸如“资产组织、运营公司、雇主”等等选项。在EBS系统中各应用模块所具有的业务处理功能通常需构建在一个确定的“组织分类”之上，“组织”是相关业务处理功能的平台，企业是否需要作相关组织分类设置、如何设置，取决于企业所需要使用到的应用模块功能。
ORACLR系统通过“组织”所具有的“层次结构”（Hierarchy）概念来达到“多组织访问”权限的控制功能。
这里的组织“层次结构”与真实企业的行政管理组织层次结构没有直接关系（尽管可能有所参考），它只是企业根据某种需要（如权限管理控制、数据统计汇报等）而人为设定的一个“层次结构”，例如将系统中已经设置的任意数量的“业务实体”或“库存组织”等组织，人为地设定一个具有上下级关系、自顶向下的金字塔形多层结构。

八、配置文件

所有定义的“安全性配置文件”构成系统多组织接入控制参数“MO：安全性配置文件”的LOV
EBS 通过“MO：业务实体”、“MO：安全性配置文件”、“MO：默认业务实体”这三个系统配置文件的共同作用，实现所谓“多组织访问”控制功能。 
对于“MO：业务实体”：在R12中， 一旦设定“MO：安全性配置文件”，则此配置文件失效而不起作用。 
对于“MO：安全性配置文件”，：在R12中，该参数如果不设定，则必须设定“MO：业务实体”参数；一旦该参数被设定，则就起决定作用，系统主要依赖其实现“多组织访问”控制功能。 
对于“MO：默认业务实体”： 在R12中，随“MO：安全配置文件”起作用后才起作用，其LOV是所有已定义OU，但如果设定值不在“MO：安全配置文件”所选择的“组织层次架构”的范围内，则仍不起作用（即在与OU相关诸如PO、OM等的FORM界面，OU字段的默认值仍然为空）。 
ORACLE强调其“多组织接入MOAC”功能主要是针对业务实体OU而言。库存组织的访问是在“组织访问”控制功能中，专门设定“库存组织”与“责任”的关联性 。
EBS系统通过“弹性域段值安全性”、“帐套/分类帐安全性”、“多组织访问控制（MOAC）”、“库存组织访问控制”等多维度、多方面的组合系统设置，提供了灵活、方便的用户权限管理功能，理清并掌握它们的复杂关系是系统实施的一项重要基础性工作。

转载自：http://blog.csdn.net/sunansheng/article/details/72636643