Gooply

CMMI 预审

2008-10-22T08:21:00.000-07:00

参加了CMMI的预审，记录部分感受。

二级，关心需求的监控，变更管理，供应商的管理，配置管理，对设计和开发阶段并不关注。
需求部分关注如下：需求怎样传递到项目经理，以及怎样确定立项。重点要强调，和客户进行了需求调研，并形成了BA分析报告。而且BA报告进行了评审，评审通过才立项。参加评审人员包括业务部门代表，经理，PM，PMO，IT经理等。在BA分析报告，包含相关的基本的估算，级别的估算。

根据BA制定概要设计，需求跟踪矩阵。需求矩阵不仅仅只和需求相关，还和功能以及测试用例相关。

制定WBS。首先对项目进行更具体的估算，子任务的划分，包括工作量，工期，资源成本，然后再确定WBS。

怎样对项目进度进行监控？WBS有项目各任务完成时间，可以监控。然后项目Charter中也有各阶段开始和完成时间。

变更管理。需求变更的流程，评审，变更跟踪单。变更分析包括变更的影响，时间，成本，以及需要更改的文档等等。

配置管理。VSS相关功能，基线的种类。怎样比较版本和找到正确的版本。随来监控配置。

QA，项目的QA人员。QA提供什么（QA检查清单，培训）。

供应商的管理，供应商的QA，以及怎样对供应商进行监控。

.....

登录默认页面看到notifications提示

2008-03-17T09:12:00.000-07:00

Home FAQ Note:207541.1

QUESTIONS & ANSWERS-------------------
1. How can I create a notifications worklist in main menu?
Answer------
. Add Preferences responsibility to your user.
. Click Create and Modify Pages icon at the top of your menu page.
. Click New.
. New Page Name = Worklist.
. Apply.
. Select Worklist: single click on Worklist.
. Click edit.
. Choose Edit Content.
. Select Worklist.
. Single click on the ">" icon. . Done.

如果不能看到plus-in，需要增加职责。

Problem Description-------------------
11i when trying to customize homepage and clicking on edit content no available plug-in to choose from.
Navigation -> Sign On -> On the Main Menu page
Click on Create and Modify icon ->
Create a new page and click on edit button ->
Press the edit content button ->
No available plug-in to select from Solution Description--------------------

In System Administrator Responsibility add the Preference Responsibility Navigation -> System Administrator Responsibility -> Security / User / Define -> Query User and Add the 'Preference' Responsibiltiy

如果没有'Preference'职责，那就是'Preference SSWA'职责。

编译失效对象

2008-03-07T19:52:00.000-08:00

正在尝试XML Gateway，出现问题，做了一个debug，发现问题的大概位置，然后在系统标准的package中ECX_UTILS中增加了几行语句，然后编译到数据库。

发现无效的对象又多了一个，集中在ECX开头的几个Package，然后通过TOAD，查看系统中APPS这个Schema下的失效对象，将EXC开头的Package选中，重新编译。刷新后，失效对象越来越多。

最后没有办法，只有请DBA在Unix端，通过ADAdmin来运行编译命令，解决问题。

但是为什么会出现开始失效对象越来越多的情况呢？

怎样限制并发请求只能在指定时间运行?

2008-01-29T09:25:00.000-08:00

怎样限制并发请求只能在指定时间运行?

定义新的并发管理器，通过“Specialization Rules”将需要限定运行时间段的并发请求添加到新定义的并发管理器中。再定义work shift，定义并发请求的运行时间段，并将这个work shift分配给新定义的并发管理器。

步骤（没有图片，arsenefang已发）：
1）定义work shift。

2）定义并发请求管理器。

3）通过Specialization Rules将需要限制将需要限定运行时间段的并发请求添加到新定义的并发管理器中。

4）将work shift分配给并发管理器。

其他测试：
1）对于新定义的并发请求，并不会自动分配给某一个并发管理器，需要手工添加。
2）如果已经将一个并发程序分配到某一个并发管理器A，但是实际上却在另一个并发管理器B中运行，需要检查另一个并发请求管理器中是否也包括（include）了这个并发程序。如果不希望并发程序在B中运行，可以在B通过exclude这个并发程序。

想知道并发程序究竟在哪些并发管理器中？
通过界面查询比较麻烦，不能根据并发程序的名称进行查询，如果需要，可以通过如下SQL来完成。

SELECT a.type_id, a.queue_application_id, a.concurrent_queue_id, a.type_code,
a.type_id, a.include_flag, d.user_concurrent_program_name,
c.description, c.user_concurrent_queue_name
FROM applsys.fnd_concurrent_programs_tl d,
applsys.fnd_concurrent_queue_content a,
applsys.fnd_concurrent_programs b,
fnd_concurrent_queues_vl c
WHERE (a.type_id = b.concurrent_program_id)
AND (a.type_application_id = b.application_id)
AND (b.application_id = d.application_id)
AND (b.concurrent_program_id = d.concurrent_program_id)
AND a.concurrent_queue_id = c.concurrent_queue_id
AND d.user_concurrent_program_name = Your concurrent program name

3）对于有两个并发管理器都包括同一个并发程序，这个并发程序究竟在哪个并发管理器中运行，比较随机。可能，哪个free，哪个work。这和设定process的个数，sleep的时间相关，还请有研究的同志多多发言。

form的label变更影响了qarun的脚本

2008-01-15T09:21:00.000-08:00

一直运行的qarun脚本突然不能收集其中几个事务的性能数据了，搞了老半天才发现ERP升级之后，其中的某一个form的label名字更改了，从QUERY_MANAGER_×××变成了QM_×××。所以，脚本怎么也不能定位对应的field，出现错误，脚本便退出了。

是个小问题，开始还以为是预置文件的问题，因为还出现FND: Developer Mode未设置的错误，一直怀疑这个来着。

搞定手工。

sun-web.xml之痛

2007-12-13T07:46:00.000-08:00

去年开发的系统，突然出现了问题，问了原来的开发的成员，说时间太久忘了，只要找我，其实我也差不多忘了。

错误主要是在显示系统中详细信息和保存项目的时候，很快就定位是iplanet端数据库连接池配置问题。

于是，让DBA检查，将密码重新设置，没有成功。
让DBA发过来日志有如下错误，可能是sun-web.xml文件有问题，是不是UNIX下字符出现错误，将我本机的这个文件发过去给DBA，没有成功。

WEB0120: XML error parsing deployment descriptor [/~~~~~~~~/wwwroot/WEB-INF/sun-web.xml]
Failed to create the XML-DOM Document. Check your XML to make sure it is correct.
java.net.ConnectException: 连接超时 at org.apache.crimson.parser.Parser2.fatal(Parser2.java:3376) at org.apache.crimson.parser.Parser2.externalParameterEntity(Parser2.java:3064) at org.apache.crimson.parser.Parser2.maybeDoctypeDecl(Parser2.java:1347) at org.apache.crimson.parser.Parser2.parseInternal(Parser2.java:656)

最后，重新考虑这个日志的时候，忽略了“java.net.ConnectException: 连接超时 ” 这个错误。怎么会网络访问，重新检查sun-web.xml，发现DOCTYPE节点，其声明的dtd文件是指向http://www.sun.com/的，可能这就是问题所在。以前从来没有注意这个问题，对于DOCTYPE，PUBLIC指定DTD文件是在系统之外，需远程访问；如果是SYSTEM，就在本地找寻dtd文件。虽然在我机器上将网络断开，没有重现这个错误，但是比较肯定系统就是遇到这个问题。将这个节点去掉，将sun-web.xml发给系统管理员，果然成功了！

<!DOCTYPE sun-web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Application Server 8.1 Servlet 2.4//EN" "http://www.sun.com/software/appserver/dtds/sun-web-app_2_4-1.dtd">

另外，将系统迁移到iplanet的时候，磕磕碰碰，花费了以整体的时间，记录下来以备忘。

1）Iplanet的版本。
从sun的官方网站下载要注册，我原来有帐户但是忘了，于是从别的地方下载了一个。本来是要6.1版本的，下来发现是6.0的，这就是后面很多错误的根源。
部署完成之后，访问系统的时候，总是出现如下错误：
“"No WebApplicationContext found: no ContextLoaderListener registered"”
在web.xml中增加如下内容，可以Iplanet可以成功启动。

<servlet>
<servlet-name>context</servlet-name>
<servlet-class>
org.springframework.web.context.ContextLoaderServlet
</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>

但是访问系统的时候，出现Servlet 2.2中不支持setCharacterEncoding() 错误。乖乖，原来IPlanet只支持Servlet 2.2，而我需要的是2.3版本。于是从Sun上下载了6.1颁布，不需要在web.xml增加上述那段，部署成功。

2）数据库连接池的建立
在Iplanet端建立了连接池，出现总是找不到驱动程序的错误，而实际上classes2.jar已经在WEB-INF/lib路径下。最后在JVM Path Settings中将JDBC的路径直接出入，解决这个问题。

3）Iplanet程序的部署。

首先是将Web程序打包成war。但是Iplanet部署war文件的时候有大小限制，可以先不降lib目录打包，待部署完成再拷贝过去。
部署应用。其对应的路径为：
Administration Server > MyServer > vsclass1 > WebApplication。
其中MyServer是系统默认建立的服务器，vsclass1是系统默认建立的虚拟class。可以同时管理n个服务器，一个服务器上又可以建立n个vsclass1，一个vsclass可以对应多个WebApplication。所以，从左到右都是1:n的关系。为什么会有vsclass1的概念呢？这是因为对于某些Web Application，其配置可能绝大部分相同，所以可以统一在vsclass层次定义就可，这些Web Applications共享这些设置。这个设计应该是为哪些提供hosting服务的机构设定的吧。但是看看现在hosting，绝大部分都在使用LAMP。
然后就是在vsclass层建立，数据库链接池和JDBC的Resource。
最后别忘了将lib拷贝到Web Application的WEB-INF目录下。

总结，
1) 最初发现问题的时候，虽然大概定位，但是没有再深究问题的根本，再加上时差的问题，问题解决效率不高。
2) 没有模拟服务器环境，而开始只在Tomcat上测试，而sun-web.xml在Tomcat环境下是不需要的，对问题的重现带来困难。
3) 在定位sun-web.xml文件的错误之后，没有静下心来研究文档结构，而是意味怀疑字符问题，耽误解决问题的时间。

Any way，问题总算解决了，休息一下，休息一下。

拷贝定时执行的任务

2007-12-04T07:36:00.000-08:00

测试机器上的定期运行的任务停止运行已经有快两个星期，最后一次运行应该是感恩节前了。主要的问题是通过执行程序“Start ClientVantage.exe”再也不能生成计划任务 “Standard Transactions” 了。重新启动，OS升级，杀掉系统中的相关进程都不能。虽然是测试机器，但是数据有时候还是有一定参考意义，今天暂时找到一个方法。

1. 从别的机器上将Windows/tasks下的“Standard Transactions”任务拷贝到测试机器的Windows/tasks目录下。
2. 执行的时候应该会出现“Can not start”的错误，那么就编辑这个任务，将开始时间更改一下，系统会提示让你输入这个操作系统的密码，输入完成确定之后，任务就可以正常执行了。

这只是一个暂时的方法，对于每天重新启动，还是不能应付，再想办法。

怎样disable掉Supplier Item Catalog Window中的标签页

2007-11-06T07:43:00.000-08:00

怎样disable掉Supplier Item Catalog Window中的标签页
在采购模块中，如果从菜单Supplier Item Catalog进入，输入条件，点击Find，就会进入如下的界面。在这个界面中，如果我只想要用户只能够看到“Requisition Templates”，应该怎样设置呢？手册有这么一段，但是没有说具体怎么做：

========================
There are four tabbed regions in the upper screen of this folder window,but Function Security can be used to determine whether a user will beable to see all of them.

Metalink的一文：
=============================
Subject: How To Restrict Access To Specific Form's Tab In Oracle Applications 11i?
Doc ID: Note:189420.1 Type: HOWTO
Last Revision Date: 05-AUG-2003 Status: PUBLISHED

Goal: How to restrict access to specific form's tab in Oracle Applications 11i?
Fact: Oracle Application Object Library 11.5

Fix:

Every form's tab represents a function. Function security is controlled by Responsibilities. A system administrator should exclude the form's tab Corresponding function from the menu structure assigned to a responsibility, users belong to this responsibility will not be able to access this form's tab anymore. As an example, the following steps will disable the Costing tab in Orgination Items form for some users:
1. Create a new responsibility and attach INV_NAVIGATE menu to it.
2. Assign the new responsibility to users that will not access the above tab.
3. From System Administrator-->menus-->query INV_NAVIGATE and display the menu tree, drill down items -->Organization Items-->get the display name
of the function corresponding to the Costing tab 'Items:Costing Group'.
4. System Administrator-->Responsibilities-->Define, query the new responsibility and use the Menu Exclusions tab to exclude the function in step 3.
5. Logon to Applications using the new responsibility and navigate to
Organization Items form, the Costing tab is disabled.

采购 -> AutoCreate

2007-10-25T14:00:00.000-07:00

Action：
可以将请购单新增文档或则添加到已存在的文档。有两种方式，一种是Create，一种是Add To。

Add To
将新的请购单创建到采购文档T_ClosePoint1，新增加的采购行序号2。

是否可以将请购单Add To已经存在的采购单，必须依据采购文档的安全设置。如果Access Level为View Only。

那么当点击Manual按钮进行创建的时候，系统提示你选择一个已经存在的文档。如果当前用户原来没有创建采购订单，系统将找不对应的采购订单（因为采购文档的安全设置）

如果采购文档的安全设置为可以修改。那么这个时候再Add To，可以找到你需要将请购单提交进去的采购文档。

Document Type：
已经审批的请购单，可以创建如下4种。未审批的请购单只能创建RFQ。

如果针对为审批未通过的请购单创建Standard PO/Planned PO/Blanket Release，那么将会提示如下提示（Manual和Auto略有不同）。

Grouping：
如果是分组方式Default，在创建采购订单行的时候，将会根据请购单行的Item，Item版本，行类型，单位等进行分组。如果是Requisition，那么每一个请购行将会对应一个采购行。

针对如下两个请购行。

如果Grouping = Default，那么创建采购单的时候，将会分组到一个采购订单行上，采购数量为两个请购数量之和。也就是将两者合并了。

如果Grouping = Requisition，一个采购单行就会对应一个请购单行。上述的两个请购单行，创建了两个采购单行。

Return Requistion：
Path: AutoCreate（M）-> Tools （M）->Return Requisition（M）

Modify：
AutoCreate（M）-> Tools （M）->Modify（M）
将原来的一行分成两行。

完成之后，在AutoCreate窗口只能看到新创建的两行。

但是从Requisition Lines Summary可以看到新创建的两行，和原来存在的一行。

采购 -> Notification Routing Rules

2007-10-24T14:42:00.000-07:00

如果审批者由于出差不能及时审批订单，这时候采购员叫天天不应，叫地地不灵。那就叫系统管理员。
一种方法通过“Mass Forwarding Documents”功能，将提交给某一个审批者的订单，批量转发给另外的审批者。

这里讲述的是另外一种方法——Notification Routing Rules。这个功能按钮存在Notification页面上。主要功能就是创建一个Notification路由的规则，对于接收Notification，采取转发，重新分配，或者审批等。如果是系统管理员，那么可以针对任何用户接收的Notification可以创建规则。如果是普通用户，那么只能针对自己的接收的Notification创建规则。
假定，现在你要出差，对于出差这段时间，对所有提交给你审批的采购订单都需要转发到另外一个审批者代劳。那就，开始设置：

1. 点击Notification Summary打开Notification页面，点击页面上的Routing Rules按钮。

2. Routing Rules列表中，点击“Create Rule”来创建一个新的Rule。
在Notification的窗口，有创建Create Notification Rule的按钮。

3. 创建Rule的第一步，选择Item Type，可以选择PO Approval或者Requisition，或者两者。

4. 创建Rule的第二步，设置Notification的格式。

5. 创建Rule的第三步，设置Rule的有效日期，收到Notification后采取的动作。

6. 点击Submit。收拾东西出差吧，出自己的差，让别人去烦审批的事情吧。

7. 其他，测试过程中，不要将Forward To的用户设置为提交审批请求的Buyer，因为在文档类型中设置了Buyer不能审批，最后在系统中出现大量的提示信息——invalid forward-to person，界面也在提交审批界面Pending住，最后只要重新来过。

采购设置 ——> 3 财务选项

2007-10-23T13:50:00.000-07:00

还是没有图片

Supplier – Entry

Path：Setup (M) ->Organization (M) ->Financials Options (M)
是针对Supplier定义的相关设置。对于RFQ Only Site，Hold Unmatched Invoiced，Invoice Match Option等选项，这里的设置会默认到供应商以及供应商地点上对应选项值的设定。Supplier Number，是设置供应商编码的规则。

a. RFQ Only Site
如果Disable这个选项。
Path：Setup (M) ->Organization (M) ->Financials Options (M) -> Supplier Entry (T)

对于新创建的供应商地点，这个选项默认也是Disable的。
Path：Supplier Base (M) –> Suppliers (M) -> Sites (B)

如果Enable这个选项。
Path：Setup (M) ->Organization (M) ->Financials Options (M) -> Supplier Entry (T)

对于新创建的供应商地点，这个选项默认也是Enable的。
Path：Supplier Base (M) –> Suppliers (M) -> Sites (B)

如果供应商地点一旦被设置为RFQ Only，那么创建采购订单的时候将不能从Site中选择这个供应商地点。
Path：Purchase Orders（M） -> Purchase Orders（M）

b. Hold Unmatched Invoiced

如果Enable这个选项。
Path：Setup (M) ->Organization (M) ->Financials Options (M) -> Supplier Entry (T)

对于新创建的供应商以及地点，这个选项默认也是Enable的。
Path：Supplier Base (M) –> Suppliers (M) -> Sites (B)

c. Invoice Match Option

如果选择Purchase Order。
Path：Setup (M) ->Organization (M) ->Financials Options (M) -> Supplier Entry (T)

对于新创建的供应商以及地点，这个选项默认也是Purchase Order的。
Path：Supplier Base (M) –> Suppliers (M)

d. Supplier Number
供应商编码的编码规则。
Path：Setup (M) ->Organization (M) ->Financials Options (M) -> Supplier Entry (T)

e. Supplier – Payables

默认供应商定义窗口的Payment页上相关域的值。设置。
Path：Setup (M) ->Organization (M) ->Financials Options (M) -> Supplier - Payables (T)

从供应商Payment页检查。
Path：Supplier Base (M) –> Suppliers (M) -> Payment （T）

f. Supplier – Purchasing

默认供应商定义窗口的Purchasing页上相关域的值。设置。
Path：Setup (M) ->Organization (M) ->Financials Options (M) -> Supplier - Purchasing (T)

默认值被带入供应商定义窗口。
Path：Supplier Base (M) –> Suppliers (M)

g. Inventory Organization

创建主组织（000）创建新的Item，不将其分配给其他组织。将Inventory Organization更改为C10（非主组织）

创建采购订单，可以看到系统不能找到对应的采购编码。
Path：Purchase Orders（M） -> Purchase Orders（M）

结论：一旦财务选项中定义了Inventory Organization，那么对于整个OU，对应采购订单行上所有的Item只能这里定义的Inventory Organization上来。而对于Shipment上的Org，包括定义Item的Org以及分配了这个Item的Org。例如，如果将这个Item分配给C10，查看Shipment行，可以看到Org可以选择000或者C10。

发运行上的Org可以选择两个组织。
Path：Purchase Orders（M） -> Purchase Orders（M）-> Shipment （B）

h. Supplier – Encumbrance

尚未使用。
Path：Setup (M) ->Organization (M) ->Financials Options (M) -> Encumbrance (T)

i. Supplier – Tax

Path：Supplier Base (M) –> Suppliers (M) -> Sites (B)
这里设定的Tax Code带入到新创建的供应商和供应商地点。同时可以在采购选项中设定采购文档的Tax Code的继承层次。
Path：Setup (M) ->Organization (M) ->Purchase Options (M) -> Tax Defaults (T)

j. Enable Recoverable Tax
这里的设置会影响到新建的Tax Code，新建编码默认值从财务选项中带入。而创建的采购订单的Distribution行的Recoverable Tax会根据Tax Code的设定而来。

实际上，Recovery Rate的设置比较复杂。
首先Enable财务选项中的“Enable Recoverable Tax”以及设置“Default Recovery Rate”。
第二，在Purchasing Look Up Code中设置Vendor Type，并在Vendor定义中将Vendor Type分配给对应供应商。
第三，在Tax Recovery Rate中定义Tax Rule，指定帐户访问，以及条件，这里设定对“风险”类型的采购商，可退回税为50%。

第四，在Recovery Code中设定对应的Recovery Rate或者Rule Name。
如果是Rate会默认从财务选项中带入。

如果Rule Name，可以选定步骤三中新建的Rule。

第四：针对上述供应商创建采购订单，检查其Recovery Rate就是定义Rule中定义中的50%。

第五，如果需要对Tax Code和Recovery Rate 进行更改，可以设定两个预置文件。Tax: Allow Override of Tax Code和Tax: Allow Override of Tax Recovery Rate。

结论：财务选项中所设定的Recovery Rate只是会默认带入Tax Code中定义，可以在定义Tax Code的时候进行修改。
在定义Tax Code的时候也选择Recovery Rule来定义Recovery Rate。
最终决定采购文档上Recovery Rate是由Tax Code所定义的Recovery Rate而决定。
而采购文档上的Tax Code是根据采购选项中设定Tax Code的优先次序决定。有可能来自于财务选项，有可能来自于Item层，供应商地点层等。

采购设置 ——> 2 接收选项

2007-10-22T14:48:00.000-07:00

不再贴图，图片太多实在太耗费时间。

a. Receipt Date

设定接收日期的允许偏差。下面设置不能早于或者晚于计划接收日期5天。如果超过，出现提示信息。
Path：Setup（M）-> Organization （M）-> Receiving Option（M）

如果接收日期超过上述接收接收日期允许范围，将会出现如下提示错误。
Path：Receiving（M） -> Receipt（M）

结论：用于控制供应商交货日期。是否真的需要退回给供应商需要根据采购物品已经返回给供应商。如果需要，可以通过Correct窗口对采购订单进行订货。
问题：采购接收的接口部分应该也考虑了这里的选项，如果插入接口表的数据中，接收日期超过允许的范围，那么应该不会成功导入接收表。

b. Over Receipt Control

控制是否可以超过采购数据进行接收。
Path：Setup（M）-> Organization （M）-> Receiving Option（M）

如果超过允许超过的数量，将会有如下的提示。
Path：Receiving（M） -> Receipt（M）

结论：只会限制超过采购数量的接收，不会限制低于采购数量的接收。因为如果限制低于采购数量的接收，那么对同一个采购行接收将不能够进行分多次接收。

c. Receipt unordered

可以接收没有采购单的物料。
Path：Setup（M）-> Organization （M）-> Receiving Option（M）

如果需要进行unordered的接收，首先必须将Receipt Option中enable unordered receipt 选项。这样在Receipt窗口中Receipt Unordered的按钮才是enable的。同时指定能够进行未订购接收的供应商，具体是在供应商属性中enable receipt unordered。
然后如果Item层次如果的Allow Unordered Receipts没有设置覆盖上述两个选项的话，那么可以针对这些Item进行未采购接收。
Path：Items（M）-> Master Item（M）

通过unordered按钮进入接收窗口，接收20个，此时无订单。
Path：Receiving（M） -> Receipt（M）

然后创建采购订单TunorderRev3，然后通过Match Unordered Receipt窗口，进行Match。采购订单的采购数量必须大于Unordered Receipt的接收单的数量。
Path：Receiving（M） -> Match Unordered Receipt（M）

Match完成之后，可以继续进行后续检验入库操作了。
Path：Receiving（M） -> Receiving Transactions（M）

剩下的6个采购订单，可以还可以做正常的Receipt操作。
Path：Receiving（M） -> Receipt（M）

结论：进行没有采购单的接收，可以处理哪些供应商已经送货，但是实际上系统中下采购订单或者没有审批完成，可以系统中对供应商的送货进行接收，记录数据。待采购订单完成审批完成之后，再进行Match。
问题：在采购订单完成审批之前，这种接收不能入库，从而不能其他库存业务操作，例如生产发料，库存转移等等，后续流程不能还是不能在系统中完成。

d. Express Transactions

设置允许快速接收，提高接收的效率。
Path：Setup (M) ->Organization (M) ->Receiving Options (M)

查询处对应需要进行快速接收的采购订单
Path：Receiving (M) -> Receipts (M) -> Find (B)

点击Express按钮，会让选择快速接收的Final Destination
Path：Express (B)

从Receiving Transaction Summary刚才快速接收的事务。因为选择的为Final Destination，所以同时将Receipt和Deliver两步同时完成。
Path：Receiving（M） –> Receiving Transaction Summary（M）

是否进行快速接收存在一定的条件，对于不能快速接收的必须手动完成：
• The item revision/subinventory/locator is required and not obtainable as a default from the item definition and the destination is Final
• The early/late receipt date tolerance is exceeded and the exception control is Reject
• Lot/serial information is required
• Ship–to location is not available and the destination is Receiving
• Location is not available for Expense destination type and the destination is Final Destination
• Purchase order supplier and receipt header supplier do not match
• other receipts are pending for the specified shipment

结论：快速接收能够加快接收的效率。但是存在一定的前提，业务部门是否需要对接收的步骤进行的严格的控制。例如，必须进行了检验之后才入库。同时，要保证快速接收的效率，必须满足上述的条件，对于不满足条件的订单，必须手工完成。

e. Cascading Receipt

“级联”功能便于将从单个供应商处接收的指定物料数量在多个发运和分配之间进行分配。如果在“查找预计接收”窗口中指定了供应商和物料，并在“接收选项”窗口中启用了“允许级联事务处理”，则将可以在“接收”窗口中使用此功能。
Path：Setup (M) ->Organization (M) ->Receiving Options (M)

针对某一个供应商和物料编码进行查询接收，下面的接收行来于三个订单。
Path：Receiving（M） -> Receipt（M）

点击Cascade按钮，输入需要接收的数量以及单位。
Path：Receiving（M） -> Receipt（M）-> Cascade（B）

确定之后，发现系统自动计算5000数量所需要的接收行，注意最后一样的数量由2250更改为750。然后再进行接收。
Path：Receiving（M） -> Receipt（M）

如果实际的接收行为5000，而输入接收数量为5100，将会出现如下的提示。
Path：Receiving（M） -> Receiving Transactions（M）

结论：“级联”功能便于将从单个供应商处接收的指定物料数量在多个发运和分配之间进行分配。如果在“查找预计接收”窗口中指定了供应商和物料，并在“接收选项”窗口中启用了“允许级联事务处理”，则将可以在“接收”窗口中使用此功能。如果在“查找接收事务处理”窗口中指定了物料，则将可以在“接收事务处理”窗口中分发物料时使用此级联功能。在行中执行任何人工事务处理将禁用“级联”按钮，并且在您于相应的“查找”窗口中再次选择“查找”按钮之前，此按钮将一直处于禁用状态。

如果选择“级联”按钮，采购管理系统将显示“级联明细”窗口，您必须在其中输入级联数量和单位。选择“确定”按钮，系统将启动级联流程。

流程从第一个显示的行开始执行，并按您输入的相应级联数量为该行分配可用于接收/分发的供应。然后，流程将转至下一行继续执行并再次分配可用于接收/分发的数量（依此类推），直至查询到的最后一行或者用尽级联数量。由于这些行按承诺日期/需要日期顺序显示，因此流程的运行过程类似于先进/先出过程。如果输入的级联数量大于可用于接收/分发的数量，采购管理系统将显示一个对话框窗口以说明流程最多只能分配的数量；如果级联数量小于可用于接收/分发的数量，则最后一行分配到的接收/分发数量可能只是部分级联数量。为了明确表示级联数量已用尽，采购管理系统会将剩余行的事务处理数量显示为 0。

级联功能不会修改任何目的地信息；它使用由接收方式定义的，以及自发运默认的信息。

如果某发运行包含多项分配并且该行的接收方式默认为直接接收，级联流程将展开该行，并根据各项分配的可用供应将发运行的可用数量在其组成分配之间进行分配。如果超量分配某指定行，采购管理系统会将发运的所有剩余供应分配至最后一项分配；如果超量分发的事务处理先前已具有接收或事务处理，则该流程将使用非期望值来填写这些行；这种情况下，您可以在级联流程完成后进行重新分配。

在级联流程执行期间，系统会禁用记录验证以加快级联流程的运行；但在保存记录时，系统将对所有记录进行验证。数量将按默认接收方式对行的预期处理方式分配至各行。但您可以人工改写这些值。

f. Allow Blind Receiving

运行Blind接收保证接收的数量和采购的数量精确匹配，从而采购接收录入员没有机会更改接收的数量。接收的数量会显示为0。
Path：Setup (M) ->Organization (M) ->Receiving Options (M)

采购订单发运行的实际数量为1000。
Path：Purchase Order（M） -> Purchase Order Summary（M）

针对上述的采购订单发运行进行接收，系统显示的数量为0。
Path：Receiving（M） -> Receipt（M）

结论：通过这种方式，接收更为死板，不可能考虑分批次接收的情况。但是保证了接收数量与采购数量的一致性。同时一旦设置这个参数。

问题：现在系统中若进行这种业务，为什么会有错误？

g. Enforce Ship-To

确保接收的地点和采购订单的地点一致性，如果不一致，可以选择警告，拒绝或者忽略。
Path：Setup (M) ->Organization (M) ->Receiving Options (M)
采购接收的时候，发运地点从采购发运行上默认而来。
Path：Receiving（M） -> Receipt（M）

如果对其进行更改，更改为如下的地点。
Path：Receiving（M） -> Receipt（M）

保存，系统将会出现如下的警告提示。
Path：Receiving（M） -> Receipt（M）

结论：只是对于接收时候要确保地点的一致性，如果到了采购入库的步骤，可以更改而不会出现警告。

h. ASN Control
没有使用

i. Receipt Routing
设定接收的时候是否需要检验，这个选项可以被供应商/地点/物料属性/发运行的属性覆盖。
Path：Setup (M) ->Organization (M) ->Receiving Options (M)

查询一个客户退货，可以看到Routing字段为“Inspection Required”。
Path：Receiving（M） -> Receipt（M）

采购设置 ——> 1采购选项 ——> 1.2 Default/Accrual/Number

2007-10-19T11:56:00.000-07:00

Default

顾名思义，就是设定采购默认值的设置，这些默认值将会再创建请购单，采购等文档的时候，相关域从这里得到默认值。

a. Requisition Import Group-By

设定从请购接口表导入请购单的时候，请购单的分组规则。存在ALL，Vendor，Buyer，Item，Category等选项。这里的设置会影响到从MRP，WIP以及其他外部系统导入请购单的时候，请购单的分组。下面的例子以Requisition Import报表为例。测试，设置不同的分组，运行这个请求的时候，参数的默认值。

如果分组值设定为Buyer。

提交请求的时候，默认分组参数为Buyer。

如果分组值设定为Vendor。

提交请求的时候，默认分组参数为Vendor。

b. Rate Type:
设定Corporate。

请购单一旦设定非本位币，存在汇率转换的时候，可以看到默认汇率类型。

c. Minimum Release

在Blanket Purchasing Agreement 中的Term窗口检查默认值。

d. Price Break Type

在Blanket Purchasing Agreement 中的订单行上检查默认值。

e. Price Type

在请购行的Price Reference页检查默认值。

f. Receipt Close/Invoice Close/Line Type/Match Approval Level

在请购行/发运行上检查默认值。

g. RFQ Required

可以在Item层和请购行层覆盖这个选项。

Number
编码方式，可以选择自动生成编号或者手工输入。自动只能选择数字，手工可以是字母和数字。

Accrual
应计的时间点，是在接收的时候或者在期末的时候。对于库存，只能选择在接收时应计。对于费用项目，还可以选择在期末应计。
同时设定应计帐户。

采购设置 ——> 1采购选项 ——> 1.1 Control面板

2007-10-18T19:44:00.000-07:00

最近比较闲，开始学习采购设置。

采购设置 ——> 采购选项 ——> Control面板

a. Price Tolerance

通过Requisition Summary查询，请购行单价.9915。

如果采购选项中采购价格百分比做如下的设定。

通过Auto Create将这个请购单创建到标准订单的时候，将价格更改为15（大于20% * .9915，其中.9915为上述请购行的单价），保存，点击Approve按钮提交审批，可以弹出审批界面，证明系统没有因为单价超过容差百分比而限制订单的审批。

如果采购选项中采购价格百分比做如下的设定。

那么将会再通过Approve按钮去访问提交审批界面的时候，将会出现错误提示。

结论：Price Tolerance Percentage和Enforce Price Tolerance Percentage要结合使用。只有Enable了Enforce Price Tolerance Percentage的时候，在Price Tolerance Percentage设定的值才起作用。

如果将设定Price Tolerance Amount。

针对同样的采购订单，如果单价为1.1（累计Tolerance的金额为(1.1-.9915)*100 > 10 ），点击Approve按钮，出现如下错误。

结论：同Price Tolerance Percentage，只是一个侧重采购金额，一个侧重价格百分比。

b. Receipt Close Point

设定这个值，决定在什么时候对订单发运行进行Close For Receiving。一共有三个选型值，对应于采购接收的三个步骤——Receipt，Accept，Delivered。
下面测试这个值的设置，对发运行自动关闭的影响。

在采购选项中设置。

通常和Receipt Close结合使用（这个值在采购选项Default面板设置）。

创建采购订单，检查其发运行，其Closure Status为Open。

采购选项的值被带入发运行。

对审批的采购发运行做Receipt，发运行本来的数量为1000。

这里我们接收(1-10%)*1000 = 900数量，保存。

再检查发运行状态，已经为Closed For Receiving。

结论：这个选项控制在采购接收的什么步骤进行订单的自动关闭，通常需要和Receipt Close选项结合使用。从正常的业务逻辑来讲，设置为Delivery比较合理。

c. Cancel Requisition

这个选项只应用于通过Auto Create创建的订单的请购单。有三个选项Optionally，Always，Never。

Path：Purchasing Option（Menu）->Control（Tab）
设置其值为Optionally。

订单T_ClosePoint1通过Auto Create通过请购单创建而来。
Path：Purchase Order Summary（Window）-> Control （Menu）

从弹出的Control窗口中，有取消请购的选项。

如果设置为 Always

检查Control窗口，Cancel Requisition默认选择，且不让更改。

结论：用户控制在取消采购单的时候，是否取消采购单对应的请购单。
问题：如果取消了请购单，而请购单从MRP创建，对计划的影响（To Do）。

d. Notify If Blanket PO Exists

创建请购单的时候，如果对应Item已经存在BPA，给出提示。

e. Allow Item Description Update

是否在请购/采购行上更新Item的描述。

Item层的这个属性会覆盖采购选项的属性，所以必须在Item层上设置之后再测试。

请购行上的描述字段变成可编辑状态了。

结论：采购选项关于Item描述的更新设置通常没有什么用，一般在Item层属性都会覆盖采购选项的设置。在Item层应该设计为下拉框，有三个选项（Yes，No，Null）。其中Null表示在Item层不设置这个属性，从而不会覆盖采购选项层的设置。

如果Enable这个选项，对新创建的Item，Item层的可更新描述的选项默认也是Enable的。

f. Enforce Vendor Hold

同时在Supplier的定义的Purchasing也设置Purchase Order Hold。

针对这个Supplier创建采购订单，然后点击提交，系统将会出现如下的提示错误。

远程重新启动服务器

2007-10-15T08:09:00.000-07:00

上周通过远程桌面控制的时候，关闭其中一个窗口，没有响应，我就强行结束任务，没想到系统pending住，桌面蓝屏，远程桌面不能控制，VNC也不能登录了。看到web server等其他服务在正常运行，便回家过周末去了：）

本来想找系统管理员到机器旁边去看一下，不过看到是自己犯的错误，还是自己先想办法吧。网络真好，通过如下两个命令搞定了：

net use \\192.168.0.3\admin$ adminpasswd /user:administrator
shutdown -r -m \\192.168.0.3 -t 30 -f

几个itpub关于采购审批层次的帖子

2007-10-10T12:36:00.000-07:00

Q: 问个po审批层次的问题
在po中定义了审批层次，我想问一下，在采购订单提交审批的时候，按照什么样的规则提交给不同层次的审批者？比如：一级a，二级b，三级c，b有5000元的最高审批权限，那么c做的采购订单什么情况下会由a来审批呢？超出5000元么？是由b转给a ,还是直接发送到了a？？？？

A: 没有试验，不知道如下是否满足你的需求
1）首先需要设定两个审批组一个审判GroupB审批的金额1~5000,另外一个组Group审批金额为5001～99999999999999999。
2）审批组分配。将b的职位分配到GroupB，将a的职位分配到GroupA。
3）设置文档类型的Foward Method的属性。如果超过5000，直接到A，那么将Forward Method属性值设为Direct。如果需要B转交，那么将Forward Method属性值设为Hiberarchy

URL:http://www.itpub.net/649786.html

Q: 怎样指定审批层次的默认审批人
因为公司同时使用了HR和PO模块。在HR模块中处于同一个position（PA）的有多个人(MA,MB,MC等)，这个position在采购的审批层次中，而这个position的几个人中，只有一个(MB)负责采购审批业务。问题在于：用户提交单据的时候，发现审批路径上的人默认的时MA，而不是MB，这个用户带来很大的困惑。请问是否有什么可以预制文件或者设置的地方，将MB设定为默认的审批人呢？

A:OSS给出回复：
1）如果是11.5.9版本，没有这个功能，以字母的ascii码顺序默认审批人。
参考Metalink:Note 106596.1
Another method that must be considered is one where the application choosesthe forward-to person when multiple employees are tied to one position. Theapplication will select the forward-to person based on alphabetical nameorder. Here is an example to better clarify how the system chooses the nextapprover name when multiple approvers are assigned to one position:Position: ClerkEmployees Assigned: ManyReports To: Vice President, MaterialsPostion: Vice President, MaterialsEmployees Assigned: Dough, John S.Smith, Bob A.In this example, if a clerk chooses the Approve button without entering aforward-to person, and the next position above the clerk is theVice President of Materials, the document would be routed to John Dough.John Dough is selected because the system will choose the employee assignedto the position in alphabetical order, and since Dough comes before Smith,John Dough is selected. Therefore, unless the clerk selects a specificperson to forward the document to, the document will always be routed to thefirst person alphabetically assigned to the position.
2）如果是11.5.10版本，安装Oracle Approvals Management (AME) ，可以设定默认审批人。
参考Metalink:Note 229663.1
Oracle Approvals Management (AME) is a web–based application which is integrated with Oracle Workflow and which enables you to define business rules to control your approvals processes. With AME, you use the following components to define your approvals processes. They are associated with a transaction type for a particular application.• Attribute – this is a business variable, for example, a salary amount, user ID, or workflow process name.• Condition – a condition compares an attribute value with a set of allowed attribute values. For example, a condition could look at a salary amount. If the salary is greater than a specified value, a particular approver list is created.• Approval type and approval specifications – these components define the type of approver list that is generated. For example, to generate a supervisor–based approver list with 5 levels, you use the ’supervisory level’ approval type with the ’requires approval up to the first 5 approvers’ approval specification.• Rules – a rule links the other components together by associating one or more conditions with the approval type and approval rule

http://www.itpub.net/616596,2.html

访问form界面，IE窗口退出

2007-09-02T09:02:00.000-07:00

今天突然发现访问不了ERP，一旦需要打开Form界面的时候，IE窗口自动退出。同时桌面有一个日志文件，部分内容如下。

An unexpected exception has been detected in native code outside the VM.Unexpected Signal : EXCEPTION_ACCESS_VIOLATION occurred at PC=0x77ea364eFunction name=NdrRpcSsDefaultAllocateLibrary=C:\WINDOWS\system32\RPCRT4.dll

通过google查询，发现部分关于vista中怎样使用Jinitiator是用高版本的jvm替换对应的jvm。发现并不能解决问题，卸载掉部分jre的版本也没能够解决问题。最后还是在metalink上找到了解决方法，是msn的插件的问题，想起来前两天还错点了msn的按钮，应该是这个原因吧：

Solution
-- To implement the solution, please execute the following steps::Suggest to check if this plug in is installed and enabled. If this is the case disable it using the following actions:1.Tools - Manage Add-ons - Enable or Disable Add-ons
2. In Show option - "Add-ons that have been used by Internet Explorer"Select from the list and check for Name "Windows Live ...."
e.g "Windows Live Messenger", "Windows Live Sing-in Helper" etc.
3. Select "Disable" option4. Close all the Internet explorer browser sessions. Restart the client machine.
5. Retest the issue.

参考：Note:435562.1

2000 servers终于可以通过网络访问了

2007-08-25T16:17:00.000-07:00

自从在HP dv9207us机器被我从Vista降级安装windows 2000 server之后，问题一直不断。先是硬件驱动器的问题，后来是无限局域网内其他机器不能访问它的问题。所以，又作服务器有做客户端，够辛苦的。网络上有很多关于这种能够Ping通，但是不能通过网上邻居访问的解决方法，主要有：
1、是否添加了“文件和打印共享”
2、组策略中是否禁止了你用来访问的用户？

发现都不是这些问题所在。无意在组策略的安全设置中，发现“IP安全策略，在本地机器中-〉安全服务器”是选中的，将其去掉就OK。

现在终于可以从其他两台机器来访问这台服务器了。

数据库导入导出乱码问题

2007-08-17T21:28:00.000-07:00

项目数据需要清理，DBA将数据按照用户导出发过了。导入数据的时候，发现数据库中文全部变成问号。上网找了一下资料，发现原来是数据库字符集不兼容。导入数据库的字符集WE8ISO8859P9，而导出数据库的字符集为ZHS16GBK。

第一个想法就是更改导入数据库的字符集，通过如下语句：ALTER DATABASE CHARACTER SET ZHS16GBK进行更改，系统提示“ORA-12712 new character set must be a superset of old character set”。原来使用这个语句还需要考虑更改的字符集与原来数据库的字符集兼容。Metalink Note:119164.1上定义了不同字符集的兼容关系。

只有重新建立一个库，设定字符集为ZHS16GBK/AL16UTF16。Imp的时候，系统显示的日志为：
import done in ZHS16GBK character set and AL16UTF16 NCHAR character set
export client uses ZHS16CGB231280 character set (possible charset conversion)
export server uses ZHS16GBK NCHAR character set (possible ncharset conversion)

可以看到DBA导出的时候客户端字符集为“ZHS16CGB231280”，导出的数据库字符集为“ZHS16GBK”，这两个字符集也不完全兼容，以后导出的时候需要注意更改客户端字符集。导入的数据库的字符集为“ZHS16GBK”。导入完成之后，没有发现乱码问题。

总结：
1. 导入导出过程中涉及4个字符集，需要保证字符集的兼容性，才可能避免汉字乱码问题。
源数据库字符集
Export过程中用户会话字符集（通过NLS_LANG设定）
Import过程中用户会话字符集（通过NLS_LANG设定）
目标数据库字符集
2. 字符集兼容可以通过Metalink Note:119164.1查询。
3. 同时，在安装数据库的时候，应该根据业务需求选定好字符集，而不是采用安装过程的默认设置。

参考：
网上非常好的一篇文章：http://silverw0396.javaeye.com/blog/90554

Trace Discoverer Workbook

2007-08-14T13:36:00.000-07:00

两种方法：修改注册表，或者通过SQL。

修改注册表的值

\\HKEY_CURRENT_USER\Software\Oracle\Discoverer\Database\SqlTrace
type DWORD
numeric value 1

使用这个的前提是需要trace的工作簿查询尚未运行。如果已经运行了，可以通过方法2来完成。

另，完成trace之后，别忘记更改回去。

通过SQL

a. 通过如下SQL定位discoverer的session以及spid。从而可以对对应的session进行跟踪。从而可以通过spid知道trace文件的名称。

SELECT s.SID, s.serial#, s.username, s.program, p.spid
FROM v$session s, v$process p
WHERE p.addr = s.paddr
AND s.program LIKE '%DIS4USR.EXE%'

得到

SID:72 serial#49228 SPID:5865
SID:132 serial#56294 SPID:5877

b. ENABLE TRACE
exec dbms_system.set_sql_trace_in_session(72, 49228, TRUE)
exec dbms_system.set_sql_trace_in_session(132, 56294, TRUE)

c. 执行discoverer相关操作，例如运行工作簿，共享工作簿等。

d. 从文件菜单中推出discoverer，这一步比较重要，如果是进行性能分析话，保证执行计划相关资源数据的完整性。

e. Disable trace.

f. 通过步骤a得到的spid，从数据库下载对应的trace文件。格式化trace文件，判断哪一个是需要的trace文件，对正确的trace文件进行分析。

tkprof onidau1_ora_5865.trc 14_2_1.txt sys = no;
tkprof onidau1_ora_5877.trc 14_2_2.txt sys=no;

参考：metalink. Note:273928.1

《Expert one on one Oracle》- 物化视图 - 笔记

2007-08-10T13:30:00.000-07:00

物化视图概念类似于discoverer中的summary table。在discoverer的管理端，可以创建不同的summary table。在discoverer进行查询的时候，discoverer首先对查询进行解析，判断查询是否可以使用对应的summary table，如果可以，将会改写查询去查询对应的summary table。

一个例子

通过如下的例子，对比统计数据需求的情况下，使用物化视图会有更快的访问速度。

--创建一张大表
SQL> create table my_all_objects
2 nologging
3 as
4 select * from all_objects
5 union all
6 select * from all_objects
7 union all
8 select * from all_objects
9 /
Table created.

SQL> insert /*+ APPEND */ into my_all_objects
2 select * from my_all_objects;
87945 rows created.

SQL> commit;
Commit complete.

SQL> insert /*+ APPEND */ into my_all_objects
2 select * from my_all_objects;
175890 rows created.

SQL> commit;
Commit complete.

SQL> analyze table my_all_objects compute statistics;
Table analyzed.

SQL> set autotrace traceonly

--通过执行计划可以得知直接对数据进行count计算，需要访问4800数据块
SQL> select owner, count(*) from my_all_objects group by owner;
28 rows selected.

Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=989 Card=28 Bytes=14
0)
1 0 SORT (GROUP BY) (Cost=989 Card=28 Bytes=140)
2 1 TABLE ACCESS (FULL) OF 'MY_ALL_OBJECTS' (Cost=471 Card=3
51780 Bytes=1758900)

Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
4804 consistent gets
3004 physical reads
0 redo size
973 bytes sent via SQL*Net to client
510 bytes received via SQL*Net from client
3 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
28 rows processed

SQL> set autotrace off

--赋予测试用户query rewrite的权限
SQL> grant query rewrite to scott;
Grant succeeded.

--更改当前session能够query rewrite
SQL> alter session set query_rewrite_enabled=true;
Session altered.

--设定query_rewrite_integrity的值为enforced，有三个置可选，enforced，trusted，STALE_TOLERATED
SQL> alter session set query_rewrite_integrity=enforced;
Session altered.

--创建物化视图
SQL> create materialized view my_all_objects_aggs
2 build immediate
3 refresh on commit
4 enable query rewrite
5 as
6 select owner, count(*)
7 from my_all_objects
8 group by owner
9 /
Materialized view created.

--分析物化视图
SQL> analyze table my_all_objects_aggs compute statistics;
Table analyzed.

--通过执行计划可以得知再进行同样的count计算，只需要访问5个数据块。同时，通过执行路径也可以看到，查询是通过物化视图来完成的。如果业务上对于这种count的计算比较频繁的话，采用物化视图将会节省更多的资源。是一种以空间换取时间的方法。
SQL> set autotrace traceonly
SQL> select owner, count(*)
2 from my_all_objects
3 group by owner;
28 rows selected.

Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=2 Card=28 Bytes=252)
1 0 TABLE ACCESS (FULL) OF 'MY_ALL_OBJECTS_AGGS' (Cost=2 Card= 28 Bytes=252)

Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
5 consistent gets
0 physical reads
0 redo size
973 bytes sent via SQL*Net to client
510 bytes received via SQL*Net from client
3 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
28 rows processed

SQL> set autotrace off

--插入新的纪录
SQL> insert into my_all_objects
2 ( owner, object_name, object_type, object_id )
3 values
4 ( 'New Owner', 'New Name', 'New Type', 1111111 );
1 row created.

SQL> commit;
Commit complete.

SQL> set timing on

--对新纪录的count计算仍然通过物化视图来访问。由于创建物化视图的时候，使用“refresh on commit”语句，表的新增纪录已经刷新到物化视图。
SQL> select owner, count(*)
2 from my_all_objects
3 where owner = 'New Owner'
4 group by owner;

OWNER COUNT(*)
------------------------------ ----------
New Owner 1

Elapsed: 00:00:00.00
SQL> set timing off
SQL>
SQL> set autotrace traceonly
SQL> select owner, count(*)
2 from my_all_objects
3 where owner = 'New Owner'
4 group by owner;

Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=2 Card=1 Bytes=9)
1 0 TABLE ACCESS (FULL) OF 'MY_ALL_OBJECTS_AGGS' (Cost=2 Card= 1 Bytes=9)

Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
4 consistent gets
0 physical reads
0 redo size
442 bytes sent via SQL*Net to client
499 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed

SQL> set autotrace off

--更改sql，不查询owner字段，只count，发现Oracle足够聪明，即使没有创建物化视图的group语句，还是从物化视图来访问
SQL> set autotrace traceonly
SQL> select count(*)
2 from my_all_objects
3 where owner = 'New Owner';

Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=2 Card=1 Bytes=9)
1 0 SORT (AGGREGATE)
2 1 TABLE ACCESS (FULL) OF 'MY_ALL_OBJECTS_AGGS' (Cost=2 Card=1 Bytes=9)

Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
3 consistent gets
0 physical reads
0 redo size
379 bytes sent via SQL*Net to client
499 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed

SQL> set autotrace off

对于事物频繁的OLTP系统，尽量少使用物化视图。

设置参数

如下参数可以在数据库层或者Session层设置QUERY_REWRITE_ENABLED和
QUERY_REWRITE_INTEGRITY值。对于QUERY_REWRITE_INTEGRITY有三种值可设：
Enforced：重写只使用数据库中定义的约束和关系。
Trusted：除了数据库中定义的约束和关系，Oracle还会使用其他我们告知Oracle表的某些关系，从而使得数据库能够重写更多的查询。
Stale_Tolerated：最弱的参数，及时物化视图没有同步更新，也会使用物化视图来重写SQL。

查询重写

全文精确匹配
如果查询的语句与存储在数据词典中物化视图字符串精确匹配，那么将会重写查询。这里的精确匹配相对于共享池的比较而言更友好，它会忽略空格，大小写以及其他的一些格式。

部分文本匹配
比较From因子后面的文本，即使Select部分的不匹配。例如：
接前面的例子，物化视图的查询部分的SQL：
Select owner, count(*) from my_all_objects group by owner
如下的查询能够被重写：
Select lower(owner) from my_all_objects group by owner

一般性重写方法
a. 数据满足：查询的数据列在物化视图的查询列中
b. 连接兼容：查询语句中的关联列需要在物化视图的查询列中
c. 分组兼容：查询语句和物化视图都必须有Group by语句，同时物化视图的Group by分组层次应该高于或者等于查询的语句。
d. 聚集兼容：查询语句和物化视图都必须包含聚集语句。如果物化视图包含SUM ()/COUNT () 函数，对于同样列采用AGE () 函数进行计算可以被重写。

确保使用物化视图

如下的例子将会说明在怎样的条件下可以确保采用物化视图重写查询，也会比较QUERY_REWRITE_INTEGRITY值Enforced和Trusted的不同。

--这一部分语句验证如果在数据库中相关约束，而这种约束在定义物化视图
--使用。那么，如果查询即使满足其它被重写的条件（数据满足，关联兼容，
--分组兼容等），也不会被重写。

--创建测试表和物化视图
SQL> create table emp as select * from scott.emp;
Table created.

SQL> create table dept as select * from scott.dept;
Table created.

SQL> alter session set query_rewrite_enabled=true;
Session altered.

--注意这里使用的参数值为enforced，只有查询中的约束和关系在物化视图中存在，才会重写查询。
SQL> alter session set query_rewrite_integrity=enforced;
Session altered.

--创建物化视图，注意这里是“refresh on demand”，需要手动刷新物化视图
SQL> create materialized view emp_dept
2 build immediate
3 refresh on demand
4 enable query rewrite
5 as
6 select dept.deptno, dept.dname, count (*)
7 from emp, dept
8 where emp.deptno = dept.deptno
9 group by dept.deptno, dept.dname
10 /
Materialized view created.

SQL> alter session set optimizer_goal=all_rows;
Session altered.

SQL> set autotrace on

--通过执行计划可以看到这个查询并没有被重写，而是直接访问表“EMP”。这是因为我们并没有定义表emp和dept的之间的主外健之间的关系，这种关系物化视图中使用，例如“emp.deptno = dept.deptno”
SQL> select count(*) from emp;

COUNT(*)
----------
14

Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=2 Card=1)
1 0 SORT (AGGREGATE)
2 1 TABLE ACCESS (FULL) OF 'EMP' (Cost=2 Card=82)

Statistics
----------------------------------------------------------
….略

--这一部分语句验证增加相关约束后，查询被重写。

--增加相关的约束和关系
SQL> alter table dept
2 add constraint dept_pk primary key(deptno);
Table altered.

SQL> alter table emp
2 add constraint emp_fk_dept
3 foreign key(deptno) references dept(deptno);
Table altered.

SQL> alter table emp modify deptno not null;
Table altered.

SQL> set autotrace on

--由于增加了约束，Oracle能够重写查询使其通过物化视图“EMP_DEPT”来访问数据。可以查看下面的highlight部分的执行计划。
SQL> select count(*) from emp;

COUNT(*)
----------
14

Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=2 Card=1 Bytes=13)
1 0 SORT (AGGREGATE)
2 1 TABLE ACCESS (FULL) OF 'EMP_DEPT' (Cost=2 Card=82 Bytes=
1066)

Statistics
----------------------------------------------------------
略….

SQL> set autotrace off

--下面这部分SQL将会在比较query_rewrite_integrity在取值为Enforced和
--Trusted情况下，是否被重写。

--删除上述步骤建立的约束
SQL> alter table emp drop constraint emp_fk_dept;
Table altered.

SQL> alter table dept drop constraint dept_pk;
Table altered.

SQL> alter table emp modify deptno null;
Table altered.

--插入数据
SQL> insert into emp (empno,deptno) values ( 1, 1 );
1 row created.

--手工刷新物化视图，这是因为物化视图创建的时候使用的是“refresh on demand”
SQL> exec dbms_mview.refresh( 'EMP_DEPT' );
PL/SQL procedure successfully completed.

--再次增加约束，但是这次增加了NOVALIDATE因子。这样即使数据不符合约束也能够成功创建。
SQL> alter table dept
2 add constraint dept_pk primary key(deptno)
3 rely enable NOVALIDATE
4 /
Table altered.

SQL> alter table emp
2 add constraint emp_fk_dept
3 foreign key(deptno) references dept(deptno)
4 rely enable NOVALIDATE
5 /
Table altered.

SQL> alter table emp modify deptno not null NOVALIDATE;
Table altered.

SQL> set autotrace on

--设置query_rewrite_integrity值为enforced
SQL> alter session set query_rewrite_integrity=enforced;
Session altered.

--检查增加约束但数据不满足约束的情况下，如果是query_rewrite_integrity的值为enforcedenforced，那么物化视图不会被利用来重写查询。
SQL> select count(*) from emp;
COUNT(*)
----------
15

Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=2 Card=1)
1 0 SORT (AGGREGATE)
2 1 TABLE ACCESS (FULL) OF 'EMP' (Cost=2 Card=164)

Statistics
----------------------------------------------------------
略….

--设置query_rewrite_integrity值为trusted
SQL> alter session set query_rewrite_integrity=trusted;
Session altered.

--检查增加约束但数据不满足约束的情况下，如果是query_rewrite_integrity的值为trusted，那么物化视图将会被利用来重写查询。
SQL> select count(*) from emp;
COUNT(*)
----------
14

Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=2 Card=1 Bytes=13)
1 0 SORT (AGGREGATE)
2 1 TABLE ACCESS (FULL) OF 'EMP_DEPT' (Cost=2 Card=82 Bytes=
1066)

Statistics
----------------------------------------------------------
略….

Dimension
创建纬度映射不同列之间的父子关系，类似于在discoverer中创建的维度，使得在查询的时候根据需求下钻上卷。在这里可以为Oracle提供更多的信息，从而使得重写查询的可能性增大。非常类似discoverer中的hierarchy的概念。

create dimension sales_dimension
--这一部分定义类似于数据库字段的别名
level cust_id is customer_hierarchy.cust_id
level zip_code is customer_hierarchy.zip_code
level region is customer_hierarchy.region
level day is time_hierarchy.day
level mmyyyy is time_hierarchy.mmyyyy
level qtr_yyyy is time_hierarchy.qtr_yyyy
level yyyy is time_hierarchy.yyyy
--定义其中一个层次结构
hierarchy cust_rollup
(
cust_id child of
zip_code child of
region
)
--定义另外一个层次结构
hierarchy time_rollup
(
day child of
mmyyyy child of
qtr_yyyy child of
yyyy
)
--mmyyyy和mon_yyyy是同义词
attribute mmyyyy
determines mon_yyyy;

DBMS_OLAP
通过DBMS_OLAP，可以完成如下工作：
a. 估算物化视图的大小
b. 验证维度对象是否有效
c. 建议建立起它物化视图，找出需要删除的视图并重命名
d. 评估物化视图的使用状况

《Expert one on one Oracle》- 索引- 笔记-2

2007-08-06T11:50:00.000-07:00

位图索引（略）

基于函数的索引（略）

使用索引常见问题：

a. 能否在视图上创建索引？只能在视图所基于的基表上创建。

b. B树索引不存储完全为NULL的条目，对于索引至少其中有一列定义为NOT NULL的时候，查询才能使用索引。

对于表T1，create table t1( x int, y int)，创建索引create unique index t_inx(x,y)之后，如果执行select * from t1 where x is null，执行计划显示不会利用索引。
如果对于表T2，create table t1( x int, y int not null)，创建索引create unique index t_inx(x,y)之后，如果执行select * from t2 where x is null，执行计划显示不会利用索引。

c. 为何不使用索引

查询的列超出索引的列的范围。例如，在T(x,y)上创建索引，而实际的查询为Select x, y, z from t where x = 5；那么，由于查询的z列必须访问数据块才能得到，这种情况下，有可能不使用索引而效率更高。
索引的列包含NULL值。执行Select count(*) from T查询，在索引表上建有B树索引。对于NULL值，不在索引中记录，所以不能通过索引来计算count。而会通过全表扫描的方式。
列上建有索引，但是查询的时候在列上使用了函数。例如：select * from t where f(indexed_column)=value
错误的使用条件。例如，对于建有索引的字符列，这列中只包含数字，使用如下查询将不会使用索引，select * from t where indexed_column = 5，将会被转换成select * from t where to_number(indexed_column) = 5。还有，对于这种TRUNC(DATE_COL) = TRUNC(SYSDATE)条件，改写成date_col between trunc(sysdate) and trunc(sysdate)+1‐1/(1*24*60*60)。
表未分析，或者统计数据错误。

《Expert one on one Oracle》- 索引- 笔记-1

2007-08-03T12:17:00.000-07:00

B树索引

对于非唯一性索引，rowid和索引key组成唯一性。唯一性索引，oracle不将rowid加入索引的key。

索引压缩

可以对索引进行压缩，例如all_objects中有大量重复的owner，object_type的值。增加CPU的时间，减少I/O的时间。

create index t_idx on all_objects(owner,object_type,object_name);
create index t_idx on all_objects(owner,object_type,object_name) compress 1;
create index t_idx on all_objects(owner,object_type,object_name) compress 2;

Reserve Key indexes

对于那些邻近得值，如果对它们创建索引，索引也是序列递增的，非常可能存放在同一个块上，这样增加冲突的可能性。通过反转，可以让索引更好的分布。但是对于条件where X>5，X列上的反转索引就会失效。

SQL> select 90101, dump(90101,16), dump(reverse(90101),16) from dual
2 union all
3 select 90102, dump(90102,16),dump(reverse(90102),16) from dual
4 union all
5 select 90103, dump(90103,16),dump(reverse(90103),16) from dual
6 /
90101 DUMP(90101,16) DUMP(REVERSE(90101),1
---------- --------------------- ---------------------
90101 Typ=2 Len=4: c3,a,2,2 Typ=2 Len=4: 2,2,a,c3
90102 Typ=2 Len=4: c3,a,2,3 Typ=2 Len=4: 3,2,a,c3
90103 Typ=2 Len=4: c3,a,2,4 Typ=2 Len=4: 4,2,a,c3

降序索引

索引创建的时候，是按照索引字段的值升序排列，查询的时候排序因子的字段使用不同的排序方式（例如一个字段升序，一个字段降序），那么通过执行计划可以看到数据库会多执行一个Sort的步骤。这种情况下，可以建立降序索引。感觉类似于基于函数的索引。

SQL> CREATE TABLE T AS select * from all_objects;
Table created.

--建立多个字段的索引
SQL> create index t_idx on t(owner,object_type,object_name);
Index created.

--结果升序排列，使用索引，执行计划中无排序步骤
SQL> select owner, object_type
2 from t
3 where owner between 'T' and 'Z'
4 and object_type is not null
5 order by owner ASC,object_type ASC;

Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE
1 0 INDEX (RANGE SCAN) OF 'T_IDX' (NON-UNIQUE)

--结果降序排列，使用索引，有排序步骤
SQL> select owner, object_type
2 from t
3 where owner between 'T' and 'Z'
4 and object_type is not null
5 order by owner DESC, object_type DESC;

Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE
1 0 SORT (ORDER BY)
2 1 INDEX (RANGE SCAN) OF 'T_IDX' (NON-UNIQUE)

--分析表
SQL> exec dbms_stats.gather_TABLE_stats( user, 'T' );
PL/SQL procedure successfully completed.

--分析表之后，结果降序排列，使用索引，无排序步骤
SQL> select owner, object_type
2 from t
3 where owner between 'T' and 'Z'
4 and object_type is not null
5 order by owner DESC, object_type DESC;

Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=7 Card=7018 Bytes=10
5270)
1 0 INDEX (RANGE SCAN DESCENDING) OF 'T_IDX' (NON-UNIQUE) (Cos
t=7 Card=7018 Bytes=105270)

--两个字段排序方式不一致，有排序步骤
SQL> select owner, object_type
2 from t
3 where owner between 'T' and 'Z'
4 and object_type is not null
5 order by owner ASC,object_type DESC;

Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=34 Card=7018 Bytes=1
05270)
1 0 SORT (ORDER BY) (Cost=34 Card=7018 Bytes=105270)
2 1 INDEX (FAST FULL SCAN) OF 'T_IDX' (NON-UNIQUE) (Cost=4 C
ard=7018 Bytes=105270)

--建立降序索引
SQL> create index desc_t_idx on t(owner ASC,object_type DESC);
Index created.

--根据排序语句建立对应索引后，无排序步骤，使用降序索引
SQL> select owner, object_type
2 from t
3 where owner between 'T' and 'Z'
4 and object_type is not null
5 order by owner ASC,object_type DESC;

Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=7 Card=7018 Bytes=10
5270)
1 0 INDEX (RANGE SCAN) OF 'DESC_T_IDX' (NON-UNIQUE) (Cost=7 Ca
rd=7018 Bytes=105270)

使用B树索引的两个原则

a. 如果访问的记录数占整个表纪录数百分比较少。
b. 如果索引包含足够的信息，而查询的时候需要再去查询标的数据块。
继续上面的例子：

--使用T-IDX索引，因为这个查询中多了object_name字段，通过T-IDX索引就不需要访问表的数据块，通过FAST FULL SCAN可以完成
SQL> select owner, object_type,object_name
2 from t
3 where owner between 'T' and 'Z'
4 and object_type is not null
5 order by owner ASC,object_type DESC;

Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=62 Card=7018 Bytes=2
73702)

1 0 SORT (ORDER BY) (Cost=62 Card=7018 Bytes=273702)
2 1 INDEX (FAST FULL SCAN) OF 'T_IDX' (NON-UNIQUE) (Cost=4 C
ard=7018 Bytes=273702)

--再增加一个查询字段created，这两个索引中都没有这个字段，所以都需要访问表的数据块。而，查询返回的结果占表纪录行的大部分（owner between 'T' and 'Z'），通过先访问索引再访问数据块，效率更低。Oracle选择全表扫描。
SQL> select owner, object_type,object_name,created
2 from t
3 where owner between 'T' and 'Z'
4 and object_type is not null
5 order by owner ASC,object_type DESC;

Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=108 Card=7018 Bytes=
329846)

1 0 SORT (ORDER BY) (Cost=108 Card=7018 Bytes=329846)
2 1 TABLE ACCESS (FULL) OF 'T' (Cost=40 Card=7018 Bytes=3298
46)

--限定只返回少量的纪录，发现又重新开始使用索引。
SQL> select owner, object_type,object_name,created
2 from t
3 where owner = 'T'
4 and object_type is not null
5 order by owner ASC,object_type DESC;

Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=31 Card=1046 Bytes=4
9162)

1 0 TABLE ACCESS (BY INDEX ROWID) OF 'T' (Cost=31 Card=1046 By
tes=49162)

2 1 INDEX (RANGE SCAN) OF 'DESC_T_IDX' (NON-UNIQUE) (Cost=2
Card=1046)

当然上述两条原则并不是适用于任何情况，有许多因素影响到执行计划。下面这个例子说明数据的存储对索引的影响。通过建立两张表，一张无序存储，一张有序存储，来比较两种情况下使用索引所消耗的资源和时间。

--创建有序存储的表，相邻记录存储在同一个数据块
SQL> create table colocated ( x int, y varchar2(2000) ) pctfree 0;
Table created.

SQL> begin
2 for i in 1 .. 100000
3 loop
4 insert into colocated values ( i, rpad(dbms_random.random,75,'*'
) );
5 end loop;
6 end;
7 /
PL/SQL procedure successfully completed.

--同一个数据块储存数据不相邻
SQL> create table disorganized nologging pctfree 0
2 as
3 select x, y from colocated ORDER BY y
4 /
Table created.

--创建主健，同时也会创建索引
SQL> alter table colocated add constraint colocated_pk primary key(x);
Table altered.

SQL> alter table disorganized add constraint disorganized_pk primary key(x);
Table altered.

SQL> commit;
Commit complete.

SQL> set timing on
SQL> set autotrace traceonly

--对于有序存储的数据，查询的时候只有3000的逻辑I/O，时间为0.03秒
SQL> select * from COLOCATED where x between 20000 and 40000;

20001 rows selected.

Elapsed: 00:00:00.03

Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE
1 0 TABLE ACCESS (BY INDEX ROWID) OF 'COLOCATED'
2 1 INDEX (RANGE SCAN) OF 'COLOCATED_PK' (UNIQUE)

Statistics
----------------------------------------------------------
156 recursive calls
0 db block gets
2908 consistent gets
43 physical reads
0 redo size
1805701 bytes sent via SQL*Net to client
15162 bytes received via SQL*Net from client
1335 SQL*Net roundtrips to/from client
4 sorts (memory)
0 sorts (disk)
20001 rows processed

--对于无序存储的数据，查询的时候只有将近20000的逻辑I/O，时间为8秒。同样的数据和索引，相对而言，无序存储的数据使用索引查询消耗更多的时间。
SQL> select * from DISORGANIZED where x between 20000 and 40000;
20001 rows selected.
Elapsed: 00:00:08.00

Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE
1 0 TABLE ACCESS (BY INDEX ROWID) OF 'DISORGANIZED'
2 1 INDEX (RANGE SCAN) OF 'DISORGANIZED_PK' (UNIQUE)

Statistics
----------------------------------------------------------
156 recursive calls
0 db block gets
21388 consistent gets
1119 physical reads
0 redo size
1805701 bytes sent via SQL*Net to client
15162 bytes received via SQL*Net from client
1335 SQL*Net roundtrips to/from client
4 sorts (memory)
0 sorts (disk)
20001 rows processed

--对于无序存储的数据，强制用全表扫描只需要0.04秒，说明全表扫描比使用索引更有效。那为什么Oracle执行计划中为什么不使用全表扫描来查询呢？在CBO的优化模式下，因为没有对表进行分析，Oracle并没有足够的信息来选择最优的执行路径。下面对表进行分析。
SQL> select /*+ FULL(DISORGANIZED) */ * from DISORGANIZED where x between 20000
and 40000;
20001 rows selected.
Elapsed: 00:00:00.04

Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=105 Card=220 Bytes=2
23300)

1 0 TABLE ACCESS (FULL) OF 'DISORGANIZED' (Cost=105 Card=220 B
ytes=223300)

Statistics
----------------------------------------------------------
60 recursive calls
0 db block gets
2407 consistent gets
1 physical reads
0 redo size
1805701 bytes sent via SQL*Net to client
15162 bytes received via SQL*Net from client
1335 SQL*Net roundtrips to/from client
2 sorts (memory)
0 sorts (disk)
20001 rows processed

--分析表
SQL> set autotrace off;
SQL> set timing off;
SQL> analyze table colocated
2 compute statistics
3 for table
4 for all indexes
5 for all indexed columns
6 /
Table analyzed.

--分析表
SQL> analyze table disorganized
2 compute statistics
3 for table
4 for all indexes
5 for all indexed columns
6 /
Table analyzed.

--一旦分析完成，可以查询user_indexes表中的CLUSTERING_FACTOR字段的值。如果这个值接近数据块的数量，证明这张表是存储相当好。单个索引叶子节点的索引项通常指向同一个数据块。如果这个值接近数据行的数量，说明这张表是随机存储的。单个索引叶子节点的索引项通常不指向同一个数据块。如上的两张表中，表'COLOCATED_PK'的主健的CLUSTERING_FACTOR字段的值为1073，接近块的数量，存储有序。表'DISORGANIZED_PK'的主健CLUSTERING_FACTOR字段的值为99907，接近行的数量，存储无序。

SQL> select a.index_name,
2 b.num_rows,
3 b.blocks,
4 a.clustering_factor
5 from user_indexes a, user_tables b
6 where index_name in ('COLOCATED_PK', 'DISORGANIZED_PK' )
7 and a.table_name = b.table_name
8 /

INDEX_NAME NUM_ROWS BLOCKS CLUSTERING_FACTOR
------------------------------ ---------- ---------- -----------------
COLOCATED_PK 100000 1073 1073
DISORGANIZED_PK 100000 1076 99907

SQL> set timing on
SQL> set autotrace traceonly

--经过表分析之后，Oracle拥有足够的信息知道通过全表访问更有效，这个时候不用通过增加hint，Oracle会自动选择全表扫描的方式查询。
SQL> select * from DISORGANIZED where x between 20000 and 30000;
10001 rows selected.

Elapsed: 00:00:00.01

Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=105 Card=9995 Bytes=
839580)

1 0 TABLE ACCESS (FULL) OF 'DISORGANIZED' (Cost=105 Card=9995
Bytes=839580)

Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
1743 consistent gets
0 physical reads
0 redo size
903094 bytes sent via SQL*Net to client
7825 bytes received via SQL*Net from client
668 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
10001 rows processed

Personalization: 从并发定义Form打开可执行Form

2007-08-01T18:38:00.000-07:00

Oracle Form Personalization的Demo，从用户定义界面的职责列表中，选中某一个职责行然后从Tools菜单中，选中子菜单打开职责定义界面察看职责的详细信息。仿照这个Demo，练习了一个从并发程序定义界面，打开并发可执行界面，察看和这个并发程序关联的可执行的详细信息。

Personalization分为两部分，一部分是针对并发程序Form的，主要功能是定义打开可执行的菜单，打开可执行的Form。另一部分是针对可执行Form的，主要功能是根据从并发程序传递过来的可执行的参数，进行查询显示。

并发程序Form的Personalization

1. 打开Personalization的界面

选择“Application Developer”职责，打开“Concurrent->Program”。然后从Help菜单打开Personalize。

2. 定义Executable Details的菜单

设置条件：
定义只对职责“Application Developer”有效。

设置Action：
新增一个菜单“Executions”，指定Menu Entry为SPECIAL1，这样菜单会挂在TOOLS下。

3. 设置判断逻辑
如果当前的Execution Name域没有可执行的名称，那么如果用户这个时候点击“Executions”菜单，提示错误。

设置Condition：
根据Item项CONC_PROG.EXECUTABLE_ID是否有值来判断。
注意，这里的Trigger为所定义菜单“SPECIAL1”。

设置Action：
通过Message类型的错误，显示提示信息。

4. 打开菜单

设置Condition：
根据Item项CONC_PROG.EXECUTABLE_ID是否有值来判断。
注意，这里的Trigger为所定义菜单“SPECIAL1”。

设置Action1：
将CONC_PROG.EXECUTABLE_ID值放入全局变量XX_EXECUTION_ID保存起来。

设置Action2：
通过执行FND_FNDCPMPE，将可执行的界面

可执行Form的Personalization：

5. 打开Personalization的界面
选择“Application Developer”职责，打开“Concurrent->Executable”。然后从Help菜单打开Personalize。

6. 初始化查询变量

设置Condition：

设置Action：
初始化全局变量XX_EXECUTION_ID。这里比较关键的一点是“Property Name”一定要选择“INITIAL VALUE”而不是“VALUE”。选择“INITIAL VALUE”表示，如果原来全局变量XX_EXECUTION_ID已经初始化，那么这里不会对其再次赋值。这种设置适应于从并发程序Form打开可执行Form的情况，因为在并发程序Form中已经对XX_EXECUTION_ID初始化，在可执行的Form中就需要保持这个变量原来值，而不是将其覆盖。如果设置“VALUE”，那么这里的赋值语句将会执行。设置为“VALUE”适应于直接打开可执行Form的情况。

7. 进入查询界面（类似于按下F11）

设置Condition：

设置Action：

8. 设置查询的可执行的ID并执行查询（类似于按下Ctrl + F11）

设置Condition：
注意这里的Processing Mode为“Only in Enter-Query Mode”

设置Action1：
将全局变量XX_EXECUTION_ID的值赋给FND_EXECUTABLES.EXECUTABLE_ID，类似于输入了可执行的名称。

设置Action2：
执行查询，类似于按下Ctrl + F11。

9. 重置全局变量
让其他直接打开可执行Form的用户，不至于打开Form的时候就进入已经查询出某个可执行的Form。如果重值变量为Null，当用户直接打开可执行Form的用户，第一个Condition将不会满足，将会显示一个“干净”的可执行Form。

设置Condition：

设置Action：

同名Sheet引起Discoverer Viewer的“Internal Server Error”

2007-08-01T14:52:00.000-07:00

一个工作簿，以前存入数据库共享给用户。昨天通过Discoverer Viewer打开工作簿查询数据的时候，出现如下拷屏的错误（Internal Server Error）。

查询Apache相关日志，只发现“14664 internal servlet error in server”。
发现只针对这一个工作簿，存在这个问题。
通过Discoverer Desktop可以打开这个工作簿并且可以查询出结果。
将工作簿保存到本地然后再重新存入数据库，问题依然存在。

后来发现，这个工作簿竟然有两个同样的名字“Sheet 1”，如果尝试通过手工建立两张同名的Sheets，这是不允许的。一定是Oracle内部发生了什么错误，从而产生两张同样的Sheets。

将其中一个删除或者更名，搞定问题。