如何加速Oracle大批量数据处理？

一、 提高DML操作的办法：\x0d\x0a简单说来：\x0d\x0a1、暂停索引，更新后恢复.避免在更新的过程中涉及到索引的重建.\x0d\x0a2、批量更新，每更新一些记录后及时进行提交动作.避免大量占用回滚段和或临时表空间.\x0d\x0a3、创建一临时的大的表空间用来应对这些更新动作．\x0d\x0a\x0d\x0a4、批量更新，每更新一些记录后及时进行提交动作.避免大量占用回滚段和或临时表空间.\x0d\x0a\x0d\x0a5、创建一临时的大的表空间用来应对这些更新动作．\x0d\x0a\x0d\x0a6、加大排序缓冲区\x0d\x0a alter session set sort_area_size=100000000;\x0d\x0a insert into tableb select * from tablea;\x0d\x0a commit;\x0d\x0a\x0d\x0a如果UPDATE的是索引字段，就会涉及到索引的重建，暂停索引不会提高多少的速度，反而有可能降低UPDATE速度，\x0d\x0a因为在更新是索引可以提高数据的查询速度，重建索引引起的速度降低影响不大。\x0d\x0a\x0d\x0aORACLE优化修改参数最多也只能把性能提高15%，大部分都是SQL语句的优化！\x0d\x0a\x0d\x0aupdate总体来说比insert要慢 ：\x0d\x0a几点建议： \x0d\x0a 1、如果更新的数据量接近整个表，就不应该使用index而应该采用全表扫描 \x0d\x0a 2、减少不必要的index，因为update表通常需要update index \x0d\x0a 3、如果你的服务器有多个cpu，采用parellel hint，可以大幅度的提高效率\x0d\x0a 另外，建表的参数非常重要，对于更新非常频繁的表，建议加大PCTFREE的值，以保证数据块中有足够的空间用于UPDATE， 从而降低CHAINED_ROWS。 \x0d\x0a\x0d\x0a二、 各种批量DML操作：\x0d\x0a（1）、oracle批量拷贝：\x0d\x0aset arraysize 20\x0d\x0a set copycommit 5000\x0d\x0a copy from username/password@oraclename append table_name1\x0d\x0a using select * from table_name2;\x0d\x0a （2）、常规插入方式：\x0d\x0a insert into t1 select * from t;\x0d\x0a 为了提高速度可以使用下面方法，来减少插入过程中产生的日志:\x0d\x0a alter table t1 nologging;\x0d\x0ainsert into t1 select * from t;\x0d\x0acommit;\x0d\x0a (3)、CTAS方式：\x0d\x0a create table t1\x0d\x0aas\x0d\x0aselect * from t;\x0d\x0a为了提高速度可以使用下面方法，来减少插入过程中产生的日志，并且可以制定并行度:\x0d\x0acreate table t1 nologging parallel(degree 2) as select * from t;\x0d\x0a （4）、Direct-Path插入：\x0d\x0a insert /*+append*/ into t1 select * from t;\x0d\x0a commit;\x0d\x0a 为了提高速度可以使用下面方法，来减少插入过程中产生的日志：\x0d\x0a alter table t1 nologging;\x0d\x0a insert /*+append*/ into t1 select * from t;\x0d\x0a \x0d\x0a Direct-Path插入特点：\x0d\x0a1、 append只在insert ? select ?中起作用，像insert /*+ append */ into t values(?)这类的语句是不起作用的。在update、delete操作中，append也不起作用。\x0d\x0a2、 Direct-Path会使数据库不记录直接路径导入的数据的重做日志，会对恢复带来麻烦。\x0d\x0a3、 Direct-Path直接在表段的高水位线以上的空白数据块中写数据，不会重用高水位线以下的空间，会对空间的使用造成一定的浪费，对查询的性能也会造成一定的影响。而常规插入会优先考虑使用高水位线之下有空闲空间存在的数据块。因此理论上Direct-Path插入会比常规插入速度更快，因为Direct-Path直接使用新数据块，而常规插入要遍历freelist获取可用空闲数据块，如果同 nologging 配合，这种速度优势会更加明显。\x0d\x0a4、 以append方式插入记录后，要执行commit，才能对表进行查询。否则会出现错误：ORA-12838: 无法在并行模式下修改之后读/修改对象。\x0d\x0a5、 用append导入数据后，如果没有提交或者回滚，在其他会话中任何对该表的DML都会被阻塞（不会报错），但对该表的查询可以正常执行。\x0d\x0a6、 在归档模式下，要把表设置为nologging，然后以append方式批量添加记录，才会显著减少redo数量。在非归档模式下，不必设置表的 nologging属性，即可减少redo数量。如果表上有索引，则append方式批量添加记录，不会减少索引上产生的redo数量，索引上的redo 数量可能比表的redo数量还要大。\x0d\x0a7、 数据直接插入数据文件，绕过buffer cache并且忽略了引用完整性约束。\x0d\x0a8、 不管表是否在nologging 下，只要是 direct insert，就不会对数据内容生成undo。\x0d\x0a9、 Oracle在Direct-Path INSERT 操作末尾，对具有索引的表执行索引维护，这样就避免了在drop掉索引后，再rebuild。\x0d\x0a10、 Direct-Path INSERT比常规的插入需要更多的空间。因为它将数据插入在高水位之上。并行插入非分区表需要更多的空间，因为它需要为每一个并行线程创建临时段。\x0d\x0a11、 在插入期间，数据库在表上获得排他锁，用户不能在表上执行并行插入、更新或者删除操作，并行的索引创建和build也不被允许。但却可以并行查询，但查询返回的是插入之前的结果集。\x0d\x0a （5）、并行DML：\x0d\x0a 如果你的服务器有多个cpu，采用parellel hint，可以大幅度的提高效率\x0d\x0a ALTER SESSION ENABLE PARALLEL DML;\x0d\x0a\x0d\x0a INSERT /*+ PARALLEL(tableA, 2) */INTO tableA \x0d\x0a SELECT * FROM tableB;\x0d\x0a\x0d\x0a 为了提高速度可以使用下面方法，来减少插入过程中产生的日志：\x0d\x0a\x0d\x0a INSERT /*+ PARALLEL(tableA, 2) */INTO tableA NOLOGGING\x0d\x0a SELECT * FROM tableB;\x0d\x0a\x0d\x0aoracle默认并不会打开PDML，对DML语句必须手工启用。即需要执行\x0d\x0aalter table enable parallel dml命令。\x0d\x0a \x0d\x0a并行DML特点：\x0d\x0a1、在并行DML模式中，默认的就是DIRECT-PATH插入，为了运行并行DML模式，必须满足以下条件：\x0d\x0aa、必须是Oracle企业版；\x0d\x0ab、必须在session中使并行DML生效，执行以下sql语句：\x0d\x0aALTER SESSION { ENABLE | FORCE } PARALLEL DML;\x0d\x0ac、必须指定table的并行属性，在创建的时候或者其他时候，或者在insert操作时使用“PARALLEL”提示。\x0d\x0ad、为了使Direct-Path Insert模式失效，在INSERT语句中指定“NOAPPEND”提示，覆盖并行DML模式。\x0d\x0a 2、并行Direct-Path INSERT到分区表：\x0d\x0a 类似于serial Direct-Path INSERT，每个并行操作分配给一个或者多个分区，每个并行操作插入数据到各自的分区段的高水位标志之上，commit之后，用户就能看到更新的数据。\x0d\x0a 3、并行Direct-Path INSERT到非分区表：\x0d\x0a 每个并行执行分配一个新的临时段，并插入数据到临时段。当commit运行后，并行执行协调者合并新的临时段到主表段，用户就能看到更新的数据。\x0d\x0a 4、Direct-Path INSERT可以使用Log或者不使用Log。\x0d\x0a 5、另外不得不说的是，并行不是一个可扩展的特性，只有在数据仓库或作为DBA等少数人的工具在批量数据操作时利于充分利用资源，而在OLTP环境下使用并行需要非常谨慎。事实上PDML还是有比较多的限制的，例如不支持触发器，引用约束，高级复制和分布式事务等特性，同时也会带来额外的空间占用，PDDL同 样是如此。

我们拥有10年网页设计和网站建设经验，从网站策划到网站制作，我们的网页设计师为您提供的解决方案。为企业提供成都做网站、成都网站建设、成都外贸网站建设、微信开发、微信小程序定制开发、成都做手机网站、H5建站、等业务。无论您有什么样的网站设计或者设计方案要求，我们都将富于创造性的提供专业设计服务并满足您的需求。

更改oracle 标准工作流的通知怎么做

工作流

系统关于工作流的设置工作包含两部分工作，一是基于企业的特殊需要，使用Workflow Builder软件包工具自定义工作流。详情需参考ORACLE的相关文档，这里不赘述。二是为系统设置工作流管理员。系统在安装后的初始化工作流管理员是系统超级用户SYSADMIN，企业应当首先使用SYSADMIN进入系统，将工作流管理员改为一个真实的用户，或者输入“*”，则所有用户都“可以”具有工作流管理员权限（用户实际是否有工作流管理权限还必须取决于其被赋予的“责任”或“菜单”功能），如下图48所示：

系列之四：ORACLE EBS基础设置要点简介（E） - season - season

实际具有工作流管理权限的用户在进入工作流管理“开发员工作室”TAB页后，可以查询出系统所有的“工作流类型”，可选择其一作具体设置，如下图49所示：

系列之四：ORACLE EBS基础设置要点简介（E） - season - season

上图中，工作流管理员选定具体需设置的工作流后，点击“运行”则可以打开该工作流的“属性”设置界面（具体有哪些属性可设置，不同工作流各不相同），如下图50所示：

系列之四：ORACLE EBS基础设置要点简介（E） - season - season

工作流管理员在工作流管理“状态监控程序”TAB页，可以监控选定工作流的具体运行情况的若干条目列表，针对每一个条目，可以查看其“活动历史记录、状态图、参与者回应、详细资料”等若干信息（必要时工作流管理员可实施干预，如更新属性、倒退、暂停、取消等等）。如下图51所示：

系列之四：ORACLE EBS基础设置要点简介（E） - season - season

系统在各应用模块基于业务处理功能，预置有若干不同工作流，有关详情容以后结合具体业务模块应用再来讨论。以下重点介绍一个比较特殊的工作流：在多个业务模块中均需使用且系统实施必须事先完善设置的“账户生成器流程”。

传统的手工业务模式下，所有可能涉及会计记账处理的业务处理例如物料接收、发出等等，作为业务处理人员在日常工作过程中是不需要考虑如何记账的，只是需要将有关业务处理记录例如入库单、出库单等作为原始凭证提交给会计人员去做处理。会计人员依据这些原始凭证制作“记账凭证”并手工为之指定“会计科目”或“账户代码”，以便正确地向总账GL实施“过账”。

手工业务模式或会计电算化模式下，由于作为原始凭证的业务单据不包含准确的记账信息（会计科目或账户代码），需要会计人员手工去做处理，这在业务量很大，记账科目数量设置较多的情况下，会计人员的工作负担将十分繁重。再考虑人工处理难免有疏漏，可能需要反复“对账”，每月月底必须及时结账关账、时间紧迫等等因素，故非人工的、高度准确的“会计分录（日记账）”自动生成功能（即所谓“自动会计”）是系统设计时必须考虑解决的重要问题。

在EBS系统中，账户代码被扩展为一个包含多个段组合的会计科目弹性域结构，系统在业务流程类表单例如采购订单、发票等做业务处理时，依赖所谓“账户生成器流程”根据业务处理的自身属性，自动生成准确的帐户代码组合并记录于业务表单的相关字段中，如下图52所示采购申请界面每个申请行（分配）所对应的“会计账户”（弹性域结构）：

系列之四：ORACLE EBS基础设置要点简介（E） - season - season

系统周期或人工启动向总账GL的“过账”流程，对符合条件的“事务处理”成批生成会计分录（日记账，是否还需复核审批视乎企业规定），一般来说无需再做繁琐的“对账”工作。这就大大减轻了会计人员的工作负担，记账科目数量的多少一般也不再成为障碍。（手工或电算化模式下，会计人员往往不愿意设置某些过渡性的“中间科目”，例如物料接收的“应计负债”等等，这对于会计工作的准确性有不小的影响）

ORACLE系统基于每个新定义的分类帐（帐套）自动生成所需的“账户生成器”，系统预置有14个账户生成器（工作流类型），对于每个“账户生成器”可以根据需要设置不同的“流程”（每个工作流类型有其LOV值，还可以使用Workflow Builder自定义添加），如下图53所示：

系列之四：ORACLE EBS基础设置要点简介（E） - season - season

“账户生成器流程”是基于“会计科目弹性域结构”来设置的，弹性域结构不同，流程设置可以不同。对于每个“账户生成器”，ORACLE都提供了默认的流程供使用。R11的账户生成器生成的账户代码被直接用之于向总账GL传送，而R12由于存在“多账簿”的不同“会计方法”因素，各子分类帐产品（业务模块）基于事务处理会计科目弹性域结构通过账户生成器而生成的帐户代码，在向总账GL传送时，还需结合“会计方法”中的“账户推导规则”等设置，才能在总账GL生成正确的会计分录（日记账）。

八、系统初始化设置

（一）关于安全性。

一个全新安装的EBSR12系统（Fresh Database），以SYSADMIN用户名登录，密码为sysadmin（注意EBS密码区分大小写），Home Page 可见系统所初始预置的10多个“责任”中包含“系统管理员”（System Administrator），如下图54所示：

系列之四：ORACLE EBS基础设置要点简介（E） - season - season

进入系统的GUI界面后，在“用户”定义界面，可查询到有30多个初始化的User，比较特殊与重要的User 是两个“SYSADMIN、GUEST”，GUEST无密码设置，可以作为测试时的特殊用户使用。如下图55所示：

系列之四：ORACLE EBS基础设置要点简介（E） - season - season

其中有些User是系统残留，并不可用，还有些是只有用户名，但并未为之分配责任。注意，上图初始的GUI界面默认配色方案，为演示方便已通过配置文件“Java color scheme”做调整。

系统初始预置的“责任”有1500多个，范围涉及所有模块的几乎所有“岗位角色”，企业可基于自身的管理习惯制定相应的责任“命名规则”，以定义新的“责任”。如下图56所示：

系列之四：ORACLE EBS基础设置要点简介（E） - season - season

系统初始预置的“菜单”有12000多个，基本上覆盖了几乎所有可能应用的需要，如企业需要“个性化”的菜单显示效果（prompt），则可以自定义用户菜单，形成特定的菜单结构。如下图57所示：

系列之四：ORACLE EBS基础设置要点简介（E） - season - season

本文为测试需要，在系统中建立用户名MFG，并将常用模块的超级用户责任均与之关联。为测试方便，建一包含所有常用超级用户菜单的总菜单，并以此建一超级总责任，也与用户MFG关联。

（二）关于配置文件

系统配置文件总数有6600多个，绝大多数有初始化的默认值，可以有需要时再来修改，有关系统配置文件的设置情况（初始化时尤其可能希望了解），可以使用工具栏“File—Export”将它们全部导出，以方便的格式如EXCEL集中查看，如下图58所示：

系列之四：ORACLE EBS基础设置要点简介（E） - season - season

有些必须设置且没有默认值的配置文件，例如“GL Ledger Name ”、“MO：Operating Unit”等，由于其LOV取决于系统的其它具体设置如分类账（帐套）、业务实体OU等，故这些特殊的配置文件初始进入时会报错，如下图59所示：

系列之四：ORACLE EBS基础设置要点简介（E） - season - season

这些少数的特殊配置文件是系统初始化参数配置是的重点与难点，在完成相关会计科目弹性域结构、分类账、组织架构等等设置后，应及时为这些特殊“配置文件”赋值。

（三）值集与弹性域

EBS系统初始预置有16000多个值集名（Value Set Name，包括近2000个“验证”类型为“无”、无需LOV的特殊值集名），基本上都属于系统各表单所使用LOV的值集，有着特定的用途，这些值集也可以根据需要修改添加新的条目行。如下图60所示。而对于系统键弹性域与说明性弹性域所使用到的值集，则需要根据企业具体情况，进行完善的定义设置（尤其是38个键弹性域所需使用的值集）。

系列之四：ORACLE EBS基础设置要点简介（E） - season - season

关于键弹性域的设置，除了使用范围广泛的Item类别弹性域（Item Categories），系统已经预置有20个不同结构表示其在不同场合的多个应用之外（还可根据需要添加结构，系统预置的结构也可以进行更改，如下图61所示：）

系列之四：ORACLE EBS基础设置要点简介（E） - season - season

其它键弹性域如“会计科目弹性域”基本只有一个结构名称范例，并无具体的结构设置，需要企业根据自己的情况来完成设置。所有的说明性弹性域均无预置结构，均需根据需要从值集开始设置。

弹性域结构的段也可以不选择值集而留空，则此时，此段就好象使用了这样一个值集：验证类型为“无”，格式类型为“字符”，宽度与基础键弹性域段列相同（即与弹性域系统设计所允许的段最大字符长度相同），允许混合大小写字母字符，无右对齐或填零。对于基础列不是“字符”列的任何段，则必须使用值集，否则将不能够编译弹性域。但需注意，“会计科目弹性域”必需使用值集。

已经定义并编译好的弹性域结构（键或说明性），在使用时均会打开弹出式窗口，以便逐段输入数据。但这样输入对于一些常用到的“代码组合”，既不方便记忆，也不方便输入，为此，ORACLE为定义的每一弹性域结构的代码组合提供了“别名”（Aliases）定义的功能。例如，实际工作使用得比较多的“账户代码”的“账户别名”就是一个典型。其它弹性域结构是否需要使用“别名”，取决于实际业务需要。

（四）分类账（帐套）与组织架构

这是系统初始化设置最复杂的工作。R12较之R11，由于引入了“会计方法”的新维度，在设置方法与顺序方面有较大的变化，其过程也更为复杂。R12的法人实体LE的设置与R11相比也有很大变化，只能在“会计科目管理器”中设置，原在GUI组织设置界面的LE设置的值不再有效（即使设定也无法分配给分类账）。有关多组织、多账簿的接入功能还需与“安全性配置文件（Security Profile）、数据访问权限集（Data Access Set）”的定义，配置文件“BG：安全配置文件、MO：安全配置文件、GL：数据访问权限集”等等参数的设置进行协调配合，包括运行“转换为多组织体系结构（仅R11，在AD Utility 工具中执行；R12安装已经是多组织结构）”以及为新添OU“复制系统初始数据”（在“系统管理员”责任下，运行“Replicate Seed Data”请求）公用程序等等。有关详情，限于篇幅，这里不再赘述。

（五）单据编号

新安装的EBS系统初始并未定义单据编号发生器，需要全新定义，如下图62所示：

系列之四：ORACLE EBS基础设置要点简介（E） - season - season

需要指出的是，这里的“单据编号”仅是“系统内部”使用的标识，都是不包含任何业务管理信息的数字代码。某些特殊单据如采购申请、采购订单以及供应商等虽具有自己专门的编号管理机制，其所生成的也是不包含业务信息的数字代码。这些数字代码和实际业务管理中所需使用到的“业务标识”可能有一定区别，例如对于采购订单、供应商，基于管理的某些特殊需要，除了系统自动生成（或手工输入）的单据代码标识外，可能还需使用单据头的“说明性弹性域”生成包含“采购员代码、业务类别代码、行业代码、地域代码”等等管理信息的“业务标识”（可能需要打印在纸面单据上），以方便相关业务信息的统计分析工作。

系统初始预置有若干数量的“单据类别（Document Categories）”（属于GL/AP/AR），每个单据类别对应数据库中的某个表（Table）。可以根据需要为相关业务模块如INV/PO/OM等等的某些表（Table，是否允许取决于Table本身的设计）添加“单据类别”，以便对表中的相关字段应用编号机制。未来在完成系统设置过程中，还会基于某些表单的业务类别设置（例如销售订单类别等）自动生成新的单据类别。如下图63所示：

系列之四：ORACLE EBS基础设置要点简介（E） - season - season

单据类别与单据编号发生器的关联分配是基于分类账（帐套）的，故在每次新定义分类账或帐套后，均需完成有关的单据编号“分配”工作。

（六）层次性设置结构

不涉及具体应用模块或具全局性、属于EBS系统层面的初始化设置，还包括工作流、预警、文件夹、配置文件定义、查找代码定义、消息定义、地区维护、打印机等等一系列内容，限于篇幅，这里不再赘述。下图64所示表达了EBS（R11）全系统公共层面的基础设置内容与层次结构： Common Applications Process Hierarchy

系列之四：ORACLE EBS基础设置要点简介（E） - season - season

EBS核心系统习惯上可以划分为四大分支系统：财务、制造、分销、人力资源。每一大分支系统也有相关的公用层面设置，如下图65所示是EBS（R11）公共“分销系统”的基础设置内容与层次结构（公共财务、制造、人力资源的相关层次结构比较简单，故略）：

Common Distribution Process Hierarchy

系列之四：ORACLE EBS基础设置要点简介（E） - season - season

而涉及具体应用模块的系统初始设置，情况就更为复杂，通常需要按照应用模块的设置流程图，结合全系统与分支系统的设置情况来决定具体如何执行。如下图66所示是EBS（R11）采购系统的设置步骤：

系列之四：ORACLE EBS基础设置要点简介（E） - season - season

对应上述设置步骤的是下述列表清单。流程图和设置步骤清单概括了各设置步骤，其中一些步骤是必需的，而另外一些步骤则是可选的。“具有默认值的必需步骤”是指在数据库中预植了默认值的设置功能。但是，通常需要复查一下这些默认值，以决定是否要对其进行更改。其中有些步骤在“系统”或“分支系统”层如果已经设置，则在应用模块层就无需再执行这些设置步骤。

步骤

必需

步骤

AIW 参考

1

必需

设置系统管理员

Common Applications

2

必需

定义会计键弹性域

Common Applications

3

必需

设置日历、币种和帐套

Common Applications

4

必需

定义人力资源键弹性域

Common Applications

5

必需

定义地点

Common Applications

6

必需

定义组织和组织关系

Common Applications

7

可选

转换为多组织体系结构

Common Applications

8

必需

定义库存键弹性域

Common Applications

9

必需

定义单位

Common Applications

10

可选

定义承运人

Common Applications

11

具有默认值的必需步骤

定义物料属性、代码和模板

Common Applications

12

必需

定义类别

Common Applications

13

可选

定义目录组

Common Applications

14

必需

设置人事

Common Applications

15

必需

设置 Oracle Workflow

Common Applications

16

必需

决定如何使用帐户生成器

Oracle Purchasing

17

必需

打开库存和采购会计期

Common Distribution

18

可选

定义子库存地点

Common Distribution

19

可选

定义交叉引用类型

Oracle Purchasing

20

可选

定义税码

Common Financial

21

可选

定义付款条件

Common Financial

22

必需

设置审批信息

Oracle Purchasing

23

具有默认值的必需步骤

定义查找和分类

Oracle Purchasing

24

可选

定义标准附件

Oracle Purchasing

25

必需

定义采购选项

Oracle Purchasing

26

必需

定义采购员

Oracle Purchasing

27

可选

定义物料

Oracle Purchasing

28

具有默认值的必需步骤

定义行类型

Oracle Purchasing

29

必需

启动采购数据库管理程序

Oracle Purchasing

30

必需

定义财务选项

Common Financial

31

可选

定义事务处理原因

Oracle Purchasing

32

必需

定义接收选项

Oracle Purchasing

33

必需

设置事务处理管理器和重新提交时间间隔

Oracle Purchasing

34

必需

定义供应商

Common Financial

35

具有默认值的必需步骤

设置工作流选项

Oracle Purchasing

36

必需

提交工作流相关流程

Oracle Purchasing

37

可选

定义说明性弹性域

Common Applications

38

可选

设置自动来源补充

Oracle Purchasing

39

必需

执行附加的系统管理员设置

Common Applications

40

必需

定义制造系统和用户配置文件

Oracle Purchasing

如果要实施多个 Oracle Applications 模块产品，ORACLE建议使用 Oracle Applications 实施向导 (AIW，Oracle Applications Implementation Wizard User's Guide) 来协调设置活动。该“向导”将指导用户完成对已安装应用产品的设置步骤，给出满足交叉产品相关性要求的逻辑实施顺序并免去多余的设置步骤。用户可以使用“向导”来查看以图形表示的设置步骤概览、查阅设置活动的联机帮助和打开相应的设置窗口。通过使用“向导”来为每个步骤记录备注信息，还可以记录实施情况以供日后参考和复查。

Oracle数据库无响应故障处理方式

Oracle数据库无响应故障处理方式

Oracle数据库无响应故障，简单地讲就是数据库实例不能响应客户端发起的请求，客户端提交一个SQL后，就一直处于等待数据库实例返回结果的状态。更严重的现象是客户端根本不能连接到数据库，发起一个连接请求后，一直处于等待状态。Oracle数据库无响应故障怎么处理呢?下面跟我一起来学习Oracle数据库无响应故障的处理方法吧!

无响应的故障现象一般有以下几种：

1.Oracle的进程在等待某个资源或事件

这种现象一般可以从V$SESSION_WAT、V$LATCH、V$LATCHHOLDER等动态视图中检查进程正在等待的资源或事件，而被等待的资源或事件，一直都不能被获取，甚至是很长时间都不可获得。如果这个正在等待的进程持有了其他的资源，则会引起其他的进程等待，这样就很可能引起实例中大范围的会话发生等待。由于进程在等待资源或事件时，通常都处于SLEEP状态，消耗的CPU资源非常少(在等待latch时要稍微多消耗一些CPU资源)，所以从OS来看，CPU的消耗并不高，甚至是非常低。

这种因为等待而引起的个别进程Hang，相对比较容易处理。

2. OracleProcess Spins

所谓Spin，就是指Oracle进程中的代码在执行某个过程时，陷入了循环。在V$SESSION视图中，往往可以看到Hang住的会话，一直处于“ACTIVE”状态。对于这样的会话，用“alter system kill session ‘sid,serial#’”命令也不能完全断开会话，会话只能被标记为“killed”，会话会继续消耗大量的CPU。进程Spins由于是在做循环，CPU的消耗非常大，从OS上明显可以看到这样的进程，通常会消耗整个CPU的资源。

而对于这样的Hang住的会话，处理起来相对比较复杂，并且为了从根本上解决问题，需要超过DBA日常维护所需要的技能。

从故障范围来看，无响应故障可以分为以下几种情况：

1. 单个或部分会话(进程)Hang住

这种情况属于小范围的故障，业务影响相对较小，一般来说只会影响业务系统的个别模块。在一个多应用系统的数据库上面，如果Hang住的会话比较多，则影响的可能是其中的一个应用系统。这里有一个例外，如果Hang住的进程是系统后台进程，如pmon、smon等，则影响的范围就非常大了，最终甚至会影响整个数据库及所有应用系统。还有值得注意的是，即使是少部分会话Hang住，也要及时处理，否则极有可能会扩散到整个系统。

2. 单个数据库实例Hang住

这种情况造成的影响非常大。在这个实例上的所有应用系统均受到严重影响，并且在找到根源并最终解决问题之前，数据库实例往往须要重启。

3. OPS或RAC中的多个实例或所有实例都Hang住

在这种情况下，即使是OPS或RAC，都已经没办法提供高可用特性了。使用这个数据库的所有应用系统将不能继续提供服务，这种情况往往须要重启。

无响应故障成因分析

Oracle数据库无响应，一般主要由以下几种原因引起：

1. 数据库主机负载过高，严重超过主机承受能力

比如应用设计不当，数据库性能低下，活动会话数的大量增加，导致数据库主机的负载迅速增加，数据库不能正常操作，并最终Hang住;主机物理内存严重不足，引起大量的换页，特别是在SGA中的内存被大量换出到虚拟内存时，数据库实例往往就会Hang住。

2. 日常维护不当、不正确的操作引起数据库Hang住

比如归档日志的存储空间满，导致数据库不能归档，引起数据库Hang住;在一个大并发的繁忙的系

统上，对DML操作比较多的大表进行move、增加外键约束等操作也可能使系统在短时间内负载大幅升高，并引起数据库系统Hang住;不正确的资源计划(Resource Plan)配置，使进程得不到足够的CPU等。

3. Oracle数据库的Bug

几乎每个版本都存在着会导致数据库系统Hang住的Bug，这些Bug会在一些特定的条件下触发，特别是在RAC数据库中，引起数据库Hang住的Bug比较多。

4. 其他方面的一些原因

比如在RAC数据库中，如果一个节点退出或加入到RAC的过程中，当进行Resource Reconfiguration时，会使系统冻结一段时间，也有可能使系统Hang住。

以上所描述的几种常见的会导致Oracle数据库实例Hang住的原因中，大部分的情况是可以避免的，只要维护得当，一般不会出现这种故障。对于Oracle数据库Bug所导致的数据库无响应故障，由于是在特定的情况下才会触发，所以如果能够尽量对数据库打上最新版本的补丁，并且熟悉当前版本中会导致系统Hang住的Bug以及触发条件，就能够最大限度地避免这种故障的发生，提高系统的可用性。

那么，在数据库Hang住的情况下，如何去分析并发现导致问题的根源?一方面，由于系统Hang住会导致业务系统不可用，为了能够尽快地恢复业务，须快速地判断问题所在，然后Kill掉引起故障的会话和进程，或者数据库实例不得不重启以迅速恢复业务;但另一方面，如果只是重启数据库或Kill会话和进程来解决问题，在很多情况下是治标不治本的办法，在以后故障随时可能会出现。如何在二者之间进行抉择呢?对于数据库Hang故障的处理，首先是尽可能地收集到系统Hang住时的状态数据，然后尽快地恢复业务，恢复业务后分析收集到的数据，找到数据库系统Hang住的真正原因，然后再进行相应的处理。下一节将详细描述数据库系统Hang住后的处理流程。

无响应故障处理流程

对于Oracle无响应故障的处理，我们可以按下图所示的流程进行。

值得注意的是，上图并不是一个完整的Oracle数据库故障处理流程图，只是处理Oralce数据库无响应这一类特定的故障的流程，只列出了针对这一特定类型故障处理时的关键处理点。不过既然是故障，所以这类故障的处理流程与其他故障的处理流程，有着非常相似的地方。

下面是整个流程的详细说明：

1. 在出现数据库无响应故障后，首先确认系统的影响范围，如上节所描述的'，是部分业务系统或模块还是所有的业务系统都受影响，是不是整个实例或多个实例都无响应。同时应询问系统维护和开发人员，受影响的系统在出现故障前是否有过变动，包括主机硬件、操作系统、网络、数据库以及应用等。有时一个细小的变动就可能导致出现数据库Hang住这样严重的故障。曾经遇到一个库，应用只是修改了一个SELECT语句就导致了数据库Hang住。

2. 为了避免由于网络、数据库监听或客户端因素影响分析，建议都登录到主机上进行操作。

3. 如果主机不能登录(为了避免干扰流程主线，这里不讨论如网络问题这样也会导致不能连接的故障)，尝试关闭出现问题的业务系统，甚至是所有的业务系统。如果关闭了所有的业务系统之后，仍然不能连接，则只有考虑重新启动数据库主机。在数据库主机重新启动后，使用操作系统工具或OSW等长期监控操作系统的资源使用，同时监控Oracle数据库的性能和等待等。

4. 登录上主机后，先用top、topas等命令简单观察一下系统。看看系统的CPU使用、物理内存和虚拟内存的使用、IO使用等情况。

5. 使用SQLPLUS连接数据库，如果不能连接，则只能从操作系统上观察系统中是否有异常的现象，比如占用CPU过高的进程。使用gdb、dbx等debugger工具对数据库进行system state dump;使用strace、truss等工具检查异常进程的系统调用;使用pstack、procstack等工具察看异常进程的call stack等。

6. 使用SQLPLUS连接上数据库后，进行hanganalyze、system state dump等操作;或检查等待事件、异常会话等正在执行的SQL等待。

7. 找到故障产生的原因，如果暂时找不到原因，尽量收集数据。

8.确良如果应用急须恢复，可通过Kill会话、重启数据库实例等方式，先恢复应用。

9. 根据最终诊断结果，对数据库升级打补丁，或者修改应用等方式从根本上解决问题。

怎样避免数据库出现无响应故障

作为Oracle数据库DBA，除了处理故障之外，更重要的是如何预防故障的发生。根据前面对数据库无响应故障的成因分析，在日常的维护工作中，须做到以下几点：

1. 进行正确的维护操作

很多的数据库无响应故障都是由于不正确的维护操作引起的。应避免在业务高峰期做大的维护操作，比如像move、加主外键约束等会长时间锁表的操作。如果的确需要，尽量使用正确的操作方法。比如用ONLINE方式重建索引;建主键、唯一键约束时先建索引，然后在建约束时指定新建的索引，等等。也就是保证系统的并发性、可伸缩性，避免系统串行操作的出现。

2. 优化应用设计，优化数据库性能

为避免性能问题导致在业务高峰期数据库不能及时有效处理来自业务的请求，甚至于完全Hang住。对于数据库中存在串行访问的部分进行优化，比如latch、enqueue，还包括不合理的sequence设计等。特别是在RAC数据库中，严重串行访问等待往往更容易引起严重的性能问题。优化应用设计，使数据库具有更好的可伸缩性和并行处理能力，能够有效地避免性能问题引起的数据库Hang住。

3. 利用监控系统随时监控系统负载

遇到系统负载过高，内存不足，OS中虚拟内存换页很频繁等情况时，及时采取措施;监控Oracle数据库的核心进程，如pmon、smon等，看是否有异常，如过高的CPU消耗。出现异常应立即处理;监控归档空间和日志切换;监控数据库中的等待事件，比如是否有大量的enqueue、log file switch (archiving needed)、resmgr:become active等待事件等。

4. 为数据库打上补丁

很多的无响应故障是由于Oracle的Bug引起的，数据库DBA应关注当前版本中有哪些Bug会导致数据库Hang住，尽量为数据库打上解决这些Bug的补丁。

;

oracle数据处理

使用行转列进行转换一下就可以了，脚本如下：

insert into othertable ( zddm, cjsj, f1110101, f1110102, f1110103 )

select zddm,

cjsj,

sum(f1110101) f1110101,

sum(f1110102) f1110102,

sum(f1110103) f1110103

from (select zddm,

cjsj,

decode(xdm, '1110101', xsj, 0) f1110101,

decode(xdm, '1110102', xsj, 0) f1110102,

decode(xdm, '1110103', xsj, 0) f1110103

from table_name) a

group by a.zddm, z.cjsj

-- 如果是新建表的时候

create table othertable as

select zddm,

cjsj,

sum(f1110101) f1110101,

sum(f1110102) f1110102,

sum(f1110103) f1110103

from (select zddm,

cjsj,

decode(xdm, '1110101', xsj, 0) f1110101,

decode(xdm, '1110102', xsj, 0) f1110102,

decode(xdm, '1110103', xsj, 0) f1110103

from table_name) a

group by a.zddm, z.cjsj

以上是数据项代码个数固定的时候可以这样转换，如果数据项代码个数不确定的话，就要使用动态SQL了，最好写个存储过程，每天来执行

有问题请追问，希望可以帮到你

请问连接Oracle的时候，Orale的详细处理过程是？

oracle服务器有一个监听程序，你在安装数据库的时候会配置监听，一般所有通过数据库的连接都是发出请求到oracle的监听的，像楼上安装完客户端配置tnsnames.ora文件的过程，就相当于在配置一个找到oracle服务器监听的配置文件

MYLIS =

(DESCRIPTION =

(ADDRESS_LIST =

(ADDRESS = (PROTOCOL = TCP)(HOST = 10.1.13.62)(PORT = 1521))

)

(CONNECT_DATA =

(SERVICE_NAME = dev)

)

)

其中host一般是oracle服务器的ip，server_name是监听的服务名，可以在服务器上用lsnrctl status或在监听配置文件$ORACLE_HOME/network/admin/lisenter.ora里面看到。

java一般是通过jdbc连接oracle数据库的。其它的应用原理都是差不多，告诉服务器ip，监听端口或监听服务名用户名密码就能连了。

谁能讲讲关于ORACLE的流式制造Flow Manufacturing

离散型制造（Intermittent Manufacturing)分车间任务型生产、流水线型生产 流程型制造（Flow Manufacturing）分重复生产型、连续生产型 重入离散型制造(Re-entrant Manufacturing) 车间任务型生产的特点是每项生产任务仅使用整个企业的一小部分能力和资源，另一特点是生产设备一般按机群方式布置。、 流水线型生产的特征有以下几点：（1）工作地专业划程度高，按产品或加工对象组织生产。 （2）生产按节拍进行，各工序同期进行作业，重复相同的作业内容。 （3）各道工序的单件作业时间与相应工序的工作地（或设备）数比值相等。 （4）工艺过程是封闭的。 流程型制造特点：1) 配方的管理要求很高，如配方的安全性、保密性； 2) 需要对产品的质量进行进行跟踪，往往需要从产成品到半成品、供应商等进行跟踪，因此对批次管理要求较高； 3) 某些产品常常有保质期； 4) 生产过程中常常出现联产品、副产品、等级品。

本文标题：oracle怎么流式处理 oracle 流式查询
浏览路径：http://azwzsj.com/article/hjpijj.html