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。

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

Install discoverer 4i in windows XP

2007-07-27T19:15:00.000-07:00

需要调优一个工作簿，参考Metalink上的一篇文章，一种比较方便方法直接更改desktop注册表中的一个条目的值便可以进行诊断。由于是通过Citrix的方式访问Discoverer Desktop，并没有Citrix那台主机的管理员权限，所以想在自己的机器上安装Discoverer Desktop。

下面是安装的过程：
1. 下载Discoverer Desktop4.1.37。
下载Discoverer Desktop Edition, Version 4.1.37 for MS Windows 95/98/NT/2000。

2. 安装Discoverer Desktop4.1.37。
接压安装文件，右健点击Setup.exe，点击“Properties”菜单，在弹出的属性窗口中切换到“Compatibility”页。选中“Compatibility mode”的复选框，然后选择“Windows 2000”作为兼容模式。点击确定。

运行Setup.exe文件安装。

如果以前的机器没有安装Oracle相关产品，可以直接跳到步骤3。由于我的机器原来安装有Oracle 9i，如果在安装的时候新建立一个Oracle Home，安装会提示让你必须选在Oracle 9i所对应的Oracle Home。这个时候，如果选择Oracle 9i对应的Oracle Home，安装会提示目录已经存在就是不让你继续。

在网上找到答案，根本的原因就是安装数据库的时候，没有使用DEFAULT_HOEM。有两种方法。
方法一，删除Oracle数据库，现安装Discoverer，再安装数据库，其实不简单。
方法二，修改注册表中。找到注册表中的健值，HKEY_LOCAL_MACHINE/SOFTWARE/ORACLE/ALL_HOMES，建立一个new key，并建立对应的String value（NAME，NLS_LANG,PATH-等）。例如：NAME: Oracle_Default，NLS_LANG :NA，PATH: C:\Oracle_Default其中PATH为自己定义的DEFAULT目录。

将ALL_HOMES下的Oracle_Default的值改为刚才上面定义的“Oracle_Default”。原来的值为Oracle9i的Oracle Home。

运行Oracle Home Selector，选中Oracle_Default。
然后再运行安装程序，选中Oracle_Default进行安装。

3. 安装补丁3201601，将版本升级到4.1.48.6.0。
同样需要更改兼容性。如果不升级，连接EBS的时候，会出现用户名和密码错误的提示，从而不能登录。

参考：Metalink：Note:365285.1

EBS表定时分析

2007-07-26T07:14:00.000-07:00

EBS中默认定义了并发程序对数据库对象的进行分析，从而对基于Cost的优化器能够有效的工作。这些并发程序主要通过调用程序包FND_STATS来完成。而实际上，这几个并发程序并不是很方便。例如Gather Schema Statistics算是比较方便的一个，一次可以对数据库中的某个Schema下的对象进行分析。但是如果Oracle中有这么多的Schema，需要提交很多次请求才能完成。实际中，通过自己编写的并发程序来完成批量多个Schema下对象的分析。

Gather Table Statistics
Backup Table Statistics
Restore Table Statistics
Gather Schema Statistics
Gather Column Statistics

步骤：
1. 通过SQL*PLUS程序，SPOOL实际饱含分析语句的fnd_stats_run.sql文件，输出到一个应用的目录下，例如$FND_TOP。在这个文件中，对每一个需要分析的对象，都有如下三行语句组成，例如，对于ABM.ABM_BATCH_CALCS：

EXEC DBMS_STATS.DELETE_TABLE_STATS(ownname => 'ABM', tabname => 'ABM_BATCH_CALCS');
ANALYZE TABLE ABM.ABM_BATCH_CALCS ESTIMATE STATISTICS SAMPLE 1 ROWS;
EXEC FND_STATS.GATHER_TABLE_STATS(ownname=>'ABM',tabname=>'ABM_BATCH_CALCS',percent=>30,degree=>1,granularity=>'DEFAULT');

所以，在这个SQL*PLUS中，可以自己编写逻辑确定哪些Schema下的对象需要分析，根据表的记录数，确定分析的百分比等。

2. 将步骤1种程序定义成并发程序FND STATS PRODUCE。

3. 将步骤1中输出到$FND_TOP目录下的SQL*PLUS程序fnd_stats_run.sql，定义成并发程序FND STATS RUN。

4. 定义请求集，将上述两个请求加入请求集。并定义，只有当FND STATS PRODUCE运行成功之后，才运行FND STATS RUN。

5. 最后，定时运行请求集。

在ITPub上提问调查，到底要不要使用系统自带并发程序，意见还真多，FYI:
http://www.itpub.net/822695.html

XML Publisher的Excel输出文件字段前面的所有零不丢失

2007-07-25T09:31:00.000-07:00

在Itpub上看到问题，Metalink上正好有人问到这个问题，测试通过。

问题：
请教在Oracle XML Publisher，如何解决Excel输出文件自动使前面的所有零不丢失？现在用Excel输出文件时，如果某一个值，如001，会只显示1，自动使前面的所有零丢失。暂时只能加一个单引号，如‘001，避免此情况，但不是好办法，用户需要做修正工作，量多了挺讨厌的。如加一个不可见字符，XML文件报错。有否一个不可见字符，可以使XML文件不报错，或其它办法，以实现上述目的？

方法：
In the rtf template, use the “Insert -> Symbol” function to insert a very small0xA0 (NO-BREAK SPACE) character (font size 1 or 2pt) in front of the number string field.

另外，尝试用Oracle以及Word自带的formate是否都没有办法，Oracle的formate语法支持数字和日期。

参考：
Metalink:Note:417811.1
http://www.itpub.net/820447.html

publish image with xml publisher in ebs

2007-07-24T19:55:00.000-07:00

本文通过一个例子，展示怎样在EBS使用XMLP输出报表，并在报表中输出存储在数据库Blob字段中的图片。下面将整个开发的过程简略描述一下， EBS 版本为11.5.10.2。
1) 建立数据表。
2) 载入数据。
3) 编写数据编码的函数。
4) 编写报表。
5) 注册并发请求。
6) 运行并发请求，得到用于开发的临时XML数据文件。
7) 开发模板文件。
8) 注册XMLP的数据和模板文件。
9) 运行检查结果。

例子以及拷屏请参考Itpub帖子：http://www.itpub.net/815723.html

已经在Itpub发布，获得一个精华，高兴!

Error:Function not available to this responsibility

2007-07-11T14:32:00.000-07:00

新环境克隆出来，用户发现对于所有的客户化Form都不能访问，提示的错误为：
Function not available to this responsibility. Change responsibilities or contact you System Administrator.

按照Responsibility，Menu，Function检查，相关定义都没有更改。对比了另外一个环境，发现，发现应用层的服务器上相关Costumer的TOP目录都没有在环境中设置。通过echo $CUSTOMER_TOP，输出为空。所以，当通过Function去找Form的时候，就会遇到如上的错误。

回头想想，问题本应该这样：
1） Form和Report在不同的tie上，客户化的Report都没有问题，只有客户化的Form有问题。
2）客户化的Menu指向一个客户化的Function（Function对应客户化Form）有问题，如果指向系统标准的Function（例如：Standard Request Submit）没有问题。

XML Publisher

2007-07-08T18:27:00.000-07:00

已经在itpub中看到不少的关于xml publisher的文章了，在网上已经找到一个非常好入门例子：
XML Publisher Concurrent Program - XMLP

《Expert one on one Oracle》- 表- 笔记-4

2007-07-05T08:31:00.000-07:00

嵌套表

类似于父/子表，但是有较大的差别。其中一个就是，在嵌套表中，父表中有多少行，就有多少嵌套表。使用嵌套表的两种方法：PL/SQL以及存储机制。
创建，查询，更新嵌套表的例子：

SQL> create or replace type emp_type
2 as object
3 (empno number(4),
4 ename varchar2(10),
5 job varchar2(9),
6 mgr number(4),
7 hiredate date,
8 sal number(7, 2),
9 comm number(7, 2)
10 );
11 /
Type created.

SQL> create or replace type emp_tab_type
2 as table of emp_type
3 /
Type created.

SQL> create table dept_and_emp
2 (deptno number(2) primary key,
3 dname varchar2(14),
4 loc varchar2(13),
5 emps emp_tab_type
6 )
7 nested table emps store as emps_nt;
Table created.

SQL> alter table emps_nt add constraint emps_empno_unique
2 unique(empno)
3 /
Table altered.

SQL> insert into dept_and_emp--插入嵌套表
2 select dept.*,
3 CAST( multiset( select empno, ename, job, mgr, hiredate, sal, comm
4 from emp
5 where emp.deptno = dept.deptno ) AS emp_tab_type )
6 from dept
7 /
5 rows created.
--multiset告诉Oracle子查询可能返回多行
--CAST告诉Oracle将返回结果作为一个集合

SQL> insert into table--插入嵌套子表
2 ( select emps from dept_and_emp where deptno = 10 )
3 values
4 ( 1234, 'NewEmp', 'CLERK', 7782, sysdate, 1200, null );
1 row created.

SQL> delete from table--删除嵌套子表
2 ( select emps from dept_and_emp where deptno = 20 )
3 where ename = 'SCOTT';
1 row deleted.

SQL> select d.dname, e.empno, ename--查询嵌套子表
2 from dept_and_emp d, table(d.emps) e
3 where d.deptno in ( 20 );

DNAME EMPNO ENAME
-------------- ---------- ----------
RESEARCH 7369 SMITH
RESEARCH 7566 JONES
RESEARCH 7876 ADAMS
RESEARCH 7902 FORD

SQL> update--更新嵌套子表
2 table( select emps
3 from dept_and_emp
4 where deptno = 10
5 )
6 set comm = 100
7 /
3 rows updated.

SQL> update
2 table( select emps
3 from dept_and_emp
4 where deptno = 1
5 )
6 set comm = 100
7 /
update
*
ERROR at line 1:
ORA-22908: reference to NULL table value

通过exp/imp可以查看到嵌套表的创建语句。通过运行如下的语句，可以进一步得到：

SQL> SELECT SQL_TEXT FROM V$SQL WHERE UPPER(SQL_TEXT) LIKE
2 '%EMP%';
……
SELECT /*+NESTED_TABLE_GET_REFS+*/ NESTED_TABLE_ID,SYS_NC_ROWINFO$ FROM "SCOTT"."EMPS_NT"

--执行上述查询出来的SQL语句
SQL> SELECT /*+NESTED_TABLE_GET_REFS+*/ NESTED_TABLE_ID,SYS_NC_ROWINFO$
2 from
3 "SCOTT"."EMPS_NT";

--得到表EMPS_NT中两列的值
NESTED_TABLE_ID
--------------------------------
SYS_NC_ROWINFO$(EMPNO, ENAME, JOB, MGR, HIREDATE, SAL, COMM)
--------------------------------------------------------------------------------

A704A65FA4D14709807E86B8741D5ED7
EMP_TYPE(7782, 'CLARK', 'MANAGER', 7839, '09-JUN-81', 2450, 100)

A704A65FA4D14709807E86B8741D5ED7
EMP_TYPE(7839, 'KING', 'PRESIDENT', NULL, '17-NOV-81', 5000, 100)

A704A65FA4D14709807E86B8741D5ED7
EMP_TYPE(7934, 'MILLER', 'CLERK', 7782, '23-JAN-82', 1300, 100)

实际上，这两列NESTED_TABLE_ID，SYS_NC_ROWINFO$被隐藏。NESTED_TABLE_ID列是父表实际的外健，SYS_NC_ROWINFO$列，让ORACLE将一列看作一个对象。通过这种方式，ORACLE通过系统产生的主健和外健实现父子表。可以查看系统为父表创建的主健：

SQL> select name
2 from sys.col$
3 where obj# = ( select object_id
4 from user_objects
5 where object_name = 'DEPT_AND_EMP')
6 /

NAME
------------------------------
DEPTNO
DNAME
LOC
EMPS
SYS_NC0000400005$

系统为父表创建了一列SYS_NC0000400005$，为子表的外健，通过如下查询可以确定:

SQL> select SYS_NC0000400005$ from dept_and_emp WHERE SYS_NC0000400005$ = 'A704A
65FA4D14709807E86B8741D5ED7';

SYS_NC0000400005$
--------------------------------
A704A65FA4D14709807E86B8741D5ED7

从而通过NESTED_TABLE_GET_REFS可以单独查询子表，例如：
SQL> select /*+ nested_table_get_refs */ empno, ename from emps_nt where ename l
ike '%AR%';

EMPNO ENAME
---------- ----------
7782 CLARK
7521 WARD
7654 MARTIN

通过如上查询结果，嵌套表的物理结构为：
如果EXP/IMP嵌套表，那么可以发现嵌套表的定义中有RETURN AS VALUE因子，这表示会将潜套表行全部返回给应用的客户端。可以改写为RETURN AS LOCATOR，那么只是将指针方会给应用的客户端。

同时，从上面的例子可以看到，嵌套子表系统创建的主健实际上是没有索引的，而在访问这个子表的时候，ORACLE总是需要关联这个字段，所以最好为这个字段创建索引。更进一步，最好的方式将嵌套子表建立成索引组指表。

临时表

创建临时表时并不分配存储参数。当运行的时候，一个SESSION第一次将数据存入临时表，一个临时段将会创建。每个SESSION都有自己的临时段。

ORACLE的临时表应该预先创建了，只是通常情况下它们都没有数据，直到SESSION存入数据。有两种类型的临时表，基于SESSION的/基于事务的。

create global temporary table temp_table_session
on commit preserve rows--on commit delete rows
as
select * from scott.emp where 1=0
/

临时表的限制：
a. 不能定义参考完整性约束
b. 不能有VARRAY和NESTED TABLE类型的列
c. 不能是IOT/分区表/索引（HASH）CLUSTER表
d. 不能通过ANALYZE产生统计信息

针对最后一条，如果需要临时表在运行的时候有参考的统计信息，可以采用如下的方式：
a. 创建与临时表一样的普通表（表名，数据量都相同），创建索引
b. 对表和索引进行分析
c. 将统计信息导出

begin
dbms_stats.create_stat_table( ownname => USER,
stattab => 'STATS');

dbms_stats.export_table_stats( ownname => USER,
tabname => 'TEMP_ALL_OBJECTS',
stattab => 'STATS');

dbms_stats.export_index_stats( ownname => USER,
indname => 'TEMP_ALL_OBJECTS_IDX',
stattab => 'STATS');
end;
/

d. 删除普通表，创建临时表
e. 导入步骤c中导出的统计信息

begin
dbms_stats.import_table_stats( ownname => USER,
tabname => 'TEMP_ALL_OBJECTS',
stattab => 'STATS');
dbms_stats.import_index_stats( ownname => USER,
indname => 'TEMP_ALL_OBJECTS_IDX',
stattab => 'STATSʹ');
end;
/

对象表

对象表和嵌入表类似，ORACLE为了维持对象表，在普通表上增加了许多隐藏的东西。其实，其最终还是转换成关系型数据库的行和列。所以，对于物理存储的表而言，倾向于不使用对象表，因为不会知道背后隐藏的机制究竟会产生什么样的副作用。当然在存储过程，程序开发中使用是一个不错的选择。例如，用对象视图来同步对象与数据库数据。

SQL> create table people_tab
2 ( name varchar2(30) primary key,
3 dob date,
4 home_city varchar2(30),
5 home_street varchar2(30),
6 home_state varchar2(2),
7 home_zip number,
8 work_city varchar2(30),
9 work_street varchar2(30),
10 work_state varchar2(2),
11 work_zip number
12 )
13 /
Table created.

SQL> create or replace type address_type
2 as object
3 ( city varchar2(30),
4 street varchar2(30),
5 state varchar2(2),
6 zip number
7 )
8 /
Type created.

SQL> create or replace type person_type
2 as object
3 ( name varchar2(30),
4 dob date,
5 home_address address_type,
6 work_address address_type
7 )
8 /
Type created.

SQL> create view people of person_type
2 with object identifier (name)
3 as
4 select name,dob,
5 address_type(home_city,home_street,home_state,home_zip) home_a
6 address_type(work_city,work_street,work_state,work_zip) work_a
7 from people_tab
8 /
View created.

SQL> insert into people values ( 'Tom','15-mar-1965',
2 address_type( 'Reston','123 Main Street','Va','45678' ),
3 address_type( 'Redwood','1 Oracle Way','Ca','23456' ) );
1 row created.

SQL> select name, p.home_address.city from people p;
NAME HOME_ADDRESS.CITY
------------------------------ ------------------------------
Tom Reston

SQL> select name from people_tab;
NAME
------------------------------
Tom

《Expert one on one Oracle》- 表- 笔记-3

2007-07-03T13:30:00.000-07:00

聚簇表

Cluster就是将拥有相同列的一些表存储在同一个数据块上，将相关数据存储在一起。例如：值为a的行都存储在同一个数据块上。Cluster不同于IOT，是以堆的形式存储。

看一个Cluster的定义：
create cluster emp_dept_cluster
( deptno number(2) )
size 1024
/
Size指定有1024byte的数据每个cluster的key值相关。对于8k的block而言，大概每个块将会存储7个cluster keys。当插入的值不在这些cluster keys中，那么将会插入新的块。Size影响cluster使用的最重要的参数，这个值太大，会造成存储空间的浪费，值太小，会影响到造成过多数据链（类似于IOT的overflow）。

create index emp_dept_cluster_idx
on cluster emp_dept_cluster
/
这条数据的主要工作就是根据cluster的key值，返回块中包含key值的地址。Key实际上是主健。首先会查找cluster key，然后决定block的地址，从而读取数据。

create table dept_clu
( deptno number(2) primary key,
dname varchar2(14),
loc varchar2(13)
)
cluster emp_dept_cluster(deptno)
/

create table emp_clu
( empno number primary key,
ename varchar2(10),
job varchar2(9),
mgr number,
hiredate date,
sal number,
comm number,
deptno number(2) references dept(deptno)
)
cluster emp_dept_cluster(deptno)
/
和普通表相同，除了多了一个关键词cluster，告诉Oracle哪一列映射到cluster的cluster key。

begin
for x in ( select * from scott.dept )
loop
insert into dept_clu
values ( x.deptno, x.dname, x.loc );
insert into emp_clu
select *
from scott.emp
where deptno = x.deptno;
end loop;
end;
/
如果通过如下两个SQL查询，可以发现这两个表的数据都存储在同一个数据块上。
SELECT ROWID, deptno, DBMS_ROWID.rowid_block_number (ROWID) BLOCK
FROM dept_clu;

SELECT ROWID, deptno, DBMS_ROWID.rowid_block_number (ROWID) BLOCK
FROM emp_clu;

上述的例子是插入dept_clu的值然后再插入emp_clu表中和这个值关联的值，为什么不先完全插入完成dept_clu，然后再插入emp_clu呢？如果这样，由于dept_clu中dept中行很小，根据size设置为1024，每块就能存储下7个cluster key相关的行。当完成dept_clu的插入之后，再插入emp_clu。由于emp_clu的行比较大，可能针对一个cluster key，超过1024byte的大小，从而造成了过多的数据链。而采用上述方式载入数据，就会以更紧凑的方式存储数据，而一定是每块7个cluster key。

分别以两种方式载入数据进行对比：
SQL> create table dept_clu
2 ( deptno number(2) primary key,
3 dname varchar2(14),
4 loc varchar2(13)
5 )
6 cluster emp_dept_cluster(deptno)
7 /

Table created.

SQL> create table emp_clu
2 ( empno number primary key,
3 ename varchar2(10),
4 job varchar2(9),
5 mgr number,
6 hiredate date,
7 sal number,
8 comm number,
9 deptno number(2) references dept(deptno),
10 data char(1000) default '*'--与前面不同，这里更改了行大小
11 )
12 cluster emp_dept_cluster(deptno)
13 /
Table created.

--以顺序的方式插入
SQL> insert into dept_clu select * from scott.dept;
5 rows created.

SQL> insert into emp_clu select emp.*,'*' from scott.emp;
14 rows created.

--Highlight部分显示超过半数emp的block与dept不在同一个block
SQL> select dbms_rowid.rowid_block_number(dept_clu.rowid) dept_rid,
2 dbms_rowid.rowid_block_number(emp_clu.rowid) emp_rid,
3 dept_clu.deptno
4 from emp_clu, dept_clu
5 where emp_clu.deptno = dept_clu.deptno
6 /

DEPT_RID EMP_RID DEPTNO
---------- ---------- ----------
18 20 10
18 19 10
18 19 10
18 18 20
18 18 20
18 20 20
18 19 20
18 19 20
18 18 30
18 18 30
18 18 30
18 18 30
18 19 30
18 19 30
14 rows selected.

--以交叉的方式插入
SQL> begin
2 for x in ( select * from scott.dept )
3 loop
4 insert into dept_clu
5 values ( x.deptno, x.dname, x.loc );
6 insert into emp_clu
7 select emp.*,'x'
8 from scott.emp
9 where deptno = x.deptno;
10 end loop;
11 end;
12 /
PL/SQL procedure successfully completed.

--Highlight部分显示只有两个emp的block与dept不在同一个block
SQL> select dbms_rowid.rowid_block_number(dept_clu.rowid) dept_rid,
2 dbms_rowid.rowid_block_number(emp_clu.rowid) emp_rid,
3 dept_clu.deptno
4 from emp_clu, dept_clu
5 where emp_clu.deptno = dept_clu.deptno
6 /

DEPT_RID EMP_RID DEPTNO
---------- ---------- ----------
19 19 30
19 19 30
19 19 30
19 19 30
19 19 30
19 19 30
20 20 20
20 20 20
20 20 20
20 18 20
20 18 20
20 20 10
20 20 10
20 20 10
14 rows selected.

什么情况下不使用cluster？

a. 更新比较频繁的表。
b. 需要经常全表扫描的表。因为可能需要扫描更多的表。
c. 需要频繁truncate的表。

什么情况下使用cluster?

a. 数据主要用来读取，通过索引读取，join比较频繁的表。

Hash Cluster Table

在Hash Cluster Table中，对于一行得健值，Oracle通过内部或者外部函数进行三列（hash）计算，从而决定着一行应该在磁盘位置。采用Hash算法的一个副作用是，如果没有表上建立索引，不能对hash cluster中的表进行range scan。例如：对于select * from emp where deptno between 10 and 20，如果表emp在hash cluster中，那么将会是全表扫描。

在Index Cluster Table中，空间是动态分配的，而在hash cluster table中，空间预先分配的。空间的计算公式为：(HASHKEYS/trunc(blocksize/SIZE))。

散列表有冲突值也是可以OK的。冲突的值被散列表聚簇在一起，这也是散列表的特性。这也是为什么Oracle需要指定HASHKEY和SIZE。当然，要避免那些没有预期的冲突。例如：指定HASHKEY为1000（实际应该为1009，取最接近素数），如果在这个表中放入1100个部分，那么至少就会存在一个冲突。

通过一个SHOW_SPACE的存储过程看，创建一个HASH_CLUSTER，然后查看其空间使用的情况。
SQL> create or replace
2 procedure show_space
3 ( p_segname in varchar2,
4 p_owner in varchar2 default user,
5 p_type in varchar2 default 'TABLE',
6 p_partition in varchar2 default NULL )
7 as
8 l_free_blks number;
9
10 l_total_blocks number;
11 l_total_bytes number;
12 l_unused_blocks number;
13 l_unused_bytes number;
14 l_LastUsedExtFileId number;
15 l_LastUsedExtBlockId number;
16 l_last_used_block number;
17 procedure p( p_label in varchar2, p_num in number )
18 is
19 begin
20 dbms_output.put_line( rpad(p_label,40,'.')
21 p_num );
22 end;
23 begin
24 dbms_space.free_blocks
25 ( segment_owner => p_owner,
26 segment_name => p_segname,
27 segment_type => p_type,
28 partition_name => p_partition,
29 freelist_group_id => 0,
30 free_blks => l_free_blks );
31
32 dbms_space.unused_space
33 ( segment_owner => p_owner,
34 segment_name => p_segname,
35 segment_type => p_type,
36 partition_name => p_partition,
37 total_blocks => l_total_blocks,
38 total_bytes => l_total_bytes,
39 unused_blocks => l_unused_blocks,
40 unused_bytes => l_unused_bytes,
41 last_used_extent_file_id => l_LastUsedExtFileId,
42 last_used_extent_block_id => l_LastUsedExtBlockId,
43 last_used_block => l_last_used_block );
44
45 p( 'Free Blocks', l_free_blks );
46 p( 'Total Blocks', l_total_blocks );
47 p( 'Total Bytes', l_total_bytes );
48 p( 'Unused Blocks', l_unused_blocks );
49 p( 'Unused Bytes', l_unused_bytes );
50 p( 'Last Used Ext FileId', l_LastUsedExtFileId );
51 p( 'Last Used Ext BlockId', l_LastUsedExtBlockId );
52 p( 'Last Used Block', l_last_used_block );
53 end;
54 /

Procedure created.

SQL> create cluster hash_cluster
2 ( hash_key number )
3 hashkeys 1000
4 size 8192
5 /

Cluster created.

SQL> exec show_space('HASH_CLUSTER',user,'CLUSTER');

PL/SQL procedure successfully completed.

SQL> set serveroutput on;
SQL> exec show_space('HASH_CLUSTER',user,'CLUSTER');
Free Blocks.............................0
Total Blocks............................1024
Total Bytes.............................8388608
Unused Blocks...........................14
Unused Bytes............................114688
Last Used Ext FileId....................12
Last Used Ext BlockId...................1033
Last Used Block.........................114

PL/SQL procedure successfully completed.

可以看到，为这个一共分配了1024个块，其中有14个未使用的，1个块用于管理extends，所以共有1024-14-1共有1009个块在HWM下。1009也是1000之后下一个素数。所以，ORACLE总共为这个表分配了8192*1009空间。

刚创建一张表的时候，HWM下的块的数量为0。然而创建一个HASH CLUSTER，由于ORACLE需要初始化每一个块，类似于将数据架载到这张表上，所以花费的时间较长。同时，对于HASH CLUSTER而言，数据的多少对于全表扫描花费同样多的时间。但是不用担心，创建HASH CLUSTER主要通过HASH KEY来查找，而不是全表扫描来查找。

对于数据相同的两张表，A表存入HASH CLUSTER，B表以堆表的方式存储。查询通常，A表的查询通常会消耗较多的CPU，B表的查询会消耗较多的内存。
什么情况下使用HASH CLUSTER
a. 在一定程度上知道表中行的数量或者上限，能够正确设置HASHKEY以及SIZE，避免重构。如果表生命周期很短，可以容易做到。
b. DML，特别是插入语句消耗资源很少，也不会产生太多负担，更新语句更新HASHKEY则不一样，会产生行迁移。
c. 适合经常需要访问的数据。

INSERT堆表时，数据块写入的顺序

2007-07-01T10:56:00.000-07:00

读到《Expert one on one Oracle》表部分，TOM说，对于堆表数据的插入，数据会被写到最适合的块，而不是以特定的顺序写入。

进行了测试，了解了FREELIST的部分结构，虽然还有一个疑问，记录于此，以后再解决。表空间非ASSM。

SQL> show parameters db_block_size--8k大小的 block
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_block_size integer 8192

SQL> create table t ( i number, a varchar2(4000), b varchar2(4000) );
Table created.

SQL> select FILE_ID, block_id, blocks from dba_extents where segment_name = 'T'
AND OWNER = 'SCOTT';--找到这个表所对应SEGMETN的头，对于8k数据块来说，数据块是从第9个块开始的
FILE_ID BLOCK_ID BLOCKS
---------- ---------- ----------
12 9 8

SQL> alter system dump datafile 12 block 9;--dump segment header
System altered.

nfl = 1, nfb = 1 typ = 1 nxf = 0 ccnt = 0
SEG LST:: flg: UNUSED lhd: 0x00000000 ltl: 0x00000000
End dump data blocks tsn: 13 file#: 12 minblk 9 maxblk 9
-- 根据nfl得知，有一个freelist，根据flag得知，这个freelist尚未使用

SQL> insert into t values ( 1, rpad('*',100,'*'), rpad('*',100,'*') );
1 row created.

SQL> SELECT ROWID, i, DBMS_ROWID.rowid_object (ROWID) OBJECT,
2 DBMS_ROWID.rowid_relative_fno (ROWID) file_no,
3 DBMS_ROWID.rowid_block_number (ROWID) BLOCK,
4 DBMS_ROWID.rowid_row_number (ROWID) rowno
5 FROM t;
ROWID I OBJECT FILE_NO BLOCK ROWNO
------------------ ---------- ---------- ---------- ---------- ----------
AAAHkEAAMAAAAAKAAA 1 30980 12 10 0

SQL> alter system dump datafile 12 block 10;--插入数据位于第10块，dump出来
System altered.

Block header dump: 0x0300000a
Object id on Block? Y
seg/obj: 0x7904 csc: 0x00.55c15a itc: 2 flg: O typ: 1 - DATA
fsl: 0 fnx: 0x0 ver: 0x01
--根据flag得知，这个块在freelist上

SQL> alter system dump datafile 12 block 9;
System altered.

alter system dump datafile 12 block 9;
nfl = 1, nfb = 1 typ = 1 nxf = 0 ccnt = 1
SEG LST:: flg: USED lhd: 0x0300000a ltl: 0x0300000a
End dump data blocks tsn: 13 file#: 12 minblk 9 maxblk 9
--顺便看一下block9, flg标示已经变为USED， lhd的值指向block 10的

SQL> insert into t values ( 2, rpad('*',3900,'1'), rpad('*',3900,'1') );
1 row created.

SQL> SELECT ROWID, i, DBMS_ROWID.rowid_object (ROWID) OBJECT,
2 DBMS_ROWID.rowid_relative_fno (ROWID) file_no,
3 DBMS_ROWID.rowid_block_number (ROWID) BLOCK,
4 DBMS_ROWID.rowid_row_number (ROWID) rowno
5 FROM t;
ROWID I OBJECT FILE_NO BLOCK ROWNO
------------------ ---------- ---------- ---------- ---------- ----------
AAAHkEAAMAAAAAKAAA 1 30980 12 10 0
AAAHkEAAMAAAAALAAA 2 30980 12 11 0

SQL> alter system dump datafile 12 block 10;
System altered.

alter system dump datafile 12 block 10;
Block header dump: 0x0300000a
Object id on Block? Y
seg/obj: 0x7904 csc: 0x00.55c15a itc: 2 flg: - typ: 1 - DATA
fsl: 0 fnx: 0x0 ver: 0x01
--flg的值为"-"，表示当插入第二行的时候，block10已经从freelist中移掉。为什么？？？block10有超过 8k*pctfree的空间啊？

SQL> alter system dump datafile 12 block 11;
System altered.
Block header dump: 0x0300000b
Object id on Block? Y
seg/obj: 0x7904 csc: 0x00.55c5b5 itc: 2 flg: O typ: 1 - DATA
fsl: 0 fnx: 0x0 ver: 0x01
--block11这个时候已经加入freelist

结论：如果不是assm类型表空间，存在这种可能block不能被插入一个新的数据的时候将从 freelist中摘掉了

后续问题： oracle根据什么算法，将block10丛freelist移除？不应该啊，因为block10有超过 8k*pctfree的空间。

参考：
在itpub的求助贴
Oracle Freelist和HWM原理及性能优化

《Expert one on one Oracle》- 表- 笔记-2

2007-06-29T08:43:00.000-07:00

堆表

平常我们使用的绝大多数的表都是堆表。堆，在数据结构中就是一块大的空间，磁盘或者内存，并以随机的方式管理。所以，查询堆表结果并不是以插入的顺序输出。

SQL> show parameters db_block_size;

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_block_size integer 8192

SQL> create table t
2 ( a int,
3 b varchar2(4000) default rpad('*',4000,'*'),
4 c varchar2(3000) default rpad('*',3000,'*')
5 )
6 /
Table created.

SQL> insert into t (a) values ( 1);
1 row created.

SQL> insert into t (a) values ( 2);
1 row created.

SQL> insert into t (a) values ( 3);
1 row created.

SQL> delete from t where a = 2 ;
1 row deleted.

SQL> insert into t (a) values ( 4);
1 row created.

SQL> SELECT a, DBMS_ROWID.rowid_object (ROWID) OBJECT,
2 DBMS_ROWID.rowid_relative_fno (ROWID) file_no,
3 DBMS_ROWID.rowid_block_number (ROWID) BLOCK,
4 DBMS_ROWID.rowid_row_number (ROWID) rowno
5 FROM t; ;--输出顺序不是134，而是143, 最后插入的块被插入到中间的块

A OBJECT FILE_NO BLOCK ROWNO
---------- ---------- ---------- ---------- ----------
1 30943 12 10 0
4 30943 12 11 1
3 30943 12 12 0

创建表的时候有非常多选项，但是我们通常只需要关心PCTFREE，PCTUSED，INITRANS，FREELISTS。通过如下的方式可以查看创建过程的其他参数：创建的内容在T.SQL文件中。
exp userid=scott/scott tables=t
imp userid=scott/scott full=y indexfile=t.sql

索引组织表

以索引的结构存储数据的表。表的数据就是索引，索引也即数据。相对堆表来讲，索引表需要更高的管理和维护成本。因为索引表的存储是顺序的，所以对于数据的增删改都需要较大的成本。

对于更新相对少的表，可以考虑使用索引表，例如一些代码表等。还有，对于那些物理上希望存储在一块的数据，也可以考虑使用索引表，例如：在父子表关联中，希望子表的多条记录物理上存储在一块。

索引表的选项：

相对堆表，无PCTUSED。因为索引表的数据，由于数据的值已经决定它所在的数据块，而不管这块空余空间的大小。同样的原因，PCTFREE值也只在对象创建和填充索引结构的时使用。

NOCRPRESS，让ORACLE存储索引和值的时候不要压缩。如果为CRPRESS，后面整形参数，表示需要压缩的列的数量。从而使得那些重复的列值不再存储。
下面的例子中，表的owner，type是存在大量重复的。所以，可以采用压缩的方式创建索引表。

如果压缩因子为2，创建完成之后，可能的存储为：
Scott/table
11111
22222
33333
44444
55555
…
99999
如果不压缩：可能存储为：
Scott/table/11111
Scott/table/22222
Scott/table/33333
Scott/table/44444
Scott/table/55555
Scott/table/66666
…
Scott/table/99999

通过如下例子，对比压缩和非压缩所使用的空间。

SQL> create or replace
2 procedure show_iot_space
3 ( p_segname in varchar2 )
4 as
5 l_segname varchar2(30);
6 l_total_blocks number;
7 l_total_bytes number;
8 l_unused_blocks number;
9 l_unused_bytes number;
10 l_LastUsedExtFileId number;
11 l_LastUsedExtBlockId number;
12 l_LAST_USED_BLOCK number;
13 begin
14 select 'SYS_IOT_TOP_' object_id
15 into l_segname
16 from user_objects
17 where object_name = upper(p_segname);
18
19 dbms_space.unused_space
20 ( segment_owner => user,
21 segment_name => l_segname,
22 segment_type => 'INDEX',
23 total_blocks => l_total_blocks,
24 total_bytes => l_total_bytes,
25 unused_blocks => l_unused_blocks,
26 unused_bytes => l_unused_bytes,
27 LAST_USED_EXTENT_FILE_ID => l_LastUsedExtFileId,
28 LAST_USED_EXTENT_BLOCK_ID => l_LastUsedExtBlockId,
29 LAST_USED_BLOCK => l_LAST_USED_BLOCK );
30
31 dbms_output.put_line
32 ( 'IOT used ' to_char(l_total_blocks-l_unused_blocks) );
33 end;
34 /
Procedure created.

SQL> create table iot
2 ( owner, object_type, object_id,
3 primary key(owner,object_type,object_id)
4 )
5 organization index
6 NOCOMPRESS
7 as
8 select owner, object_type, object_id from all_objects
9 order by owner, object_type, object_id
10 /
Table created.

SQL>
SQL> set serveroutput on
SQL> exec show_iot_space( 'iot' );
IOT used 96
PL/SQL procedure successfully completed.

SQL> drop table iot;
Table dropped.

SQL> create table iot
2 ( owner, object_type, object_id,
3 primary key(owner,object_type,object_id)
4 )
5 organization index
6 compress 1
7 as
8 select owner, object_type, object_id from all_objects
9 order by owner, object_type, object_id
10 /
Table created.

SQL> exec show_iot_space('iot' );
IOT used 74
PL/SQL procedure successfully completed.

SQL> drop table iot;
Table dropped.

SQL> create table iot
2 ( owner, object_type, object_id,
3 primary key(owner,object_type,object_id)
4 )
5 organization index
6 compress 2
7 as
8 select owner, object_type, object_id from all_objects
9 order by owner, object_type, object_id
10 /
Table created.

SQL> exec show_iot_space( 'iot' );
IOT used 38
PL/SQL procedure successfully completed.

通过如上的例子可以看到，参数COMPRESS可以节省存储空间，减少I/O（通常也会消耗更多的CPU）。

PCTTHRESHOLD, OVERFLOW, and INCLUDING

这三个参数用来确保索引的叶块（实际存储索引数据的块）能够有效的存储数据。
a. OVERFLOW：当行的数据增大的时候，通过OVERFLOW设置另外一个段，可以让行数据OVERFLOW到那个段去。在OVERFLOW中也有PCTUSED，PCTFREE设置，这些都与堆表的相同。
b. PCTTHRESHOLD：当行的数量超过一定数量的时候，将会将行的一部分存到其他地方。对于8K的BLOCK，如果PCTTHRESHOLD为10，那么当行的大小超过800BYTE的时候，行的部分内容将不会存储在这个索引块上了。
c. INCLUDING：INCLUDING指定的列以及前面的列，都存储到索引块中，其他的列存储到溢出块中。

这几个参数是创建IOT的重要参数，可以根据列的访问频率考虑是否需要将其放到OVERFLOW中去，可以根据一块要存储的行数来计算PCCTHRESHOLD。
可以在IOT表上创建索引。由于IOT表的行与堆表的行不同，经常移动。IOT表中的行根据主健的值在索引结构中确定位置，当索引本身的大小和形状改变的时候，位置也会更改。所以，ORACLE采用了逻辑ROWID，ROWID基于IOT的主健。IOT表上的索引效率通常比堆表的索引低。

《Expert one on one Oracle》- 表- 笔记-1

2007-06-28T19:45:00.000-07:00

术语

高水位标示（HIGH WATER MARKET）

HWM是已经使用过的存储空间和未使用过的存储空间之间的分界线。在表刚创建的时候，HWM从第一数据块开始。随着数据插入的增多，HWM会上升。如果删除数据行，虽然部分被删除的哪些块不再包含数据，但是这些块仍然在HWM之下，HWM位置不会改变，直到HWM被重建或者TRUNCATE。ORACLE会扫描HWM下所有的块，即使这些块已经不包含数据。所以，这也会影响到性能。如果需要删除表中所有的行，尝试使用TRUNCATE。

FREELISTS

对于HWM下那些还有空闲空间的块，ORACLE使用FREELIST来记录。每个对象至少有一个FREELISTS。只有在HWM下的块才可以在FREELIST中找到。如果FREELISTS已经为空，那么HWM就会上移，新增块到FREELIST。一个对象可以拥有多个FREELIST。如果一个对象只有一个FREELIST，那么对于并发访问同一些的块，就会发生块等待事件。

但是也不是将FREELISTS设置越多越好。因为当一个进程用完一个FREELIST空闲块的时候，并不去使用这个对象的其他FREELIST的空闲块，而是上移HWM。如果当前的EXTENT不够，将会使用其他的EXTENT。所以，设置太多的FREELIST会造成空间上的浪费。

PCTFREE 和PCTUSED

这两个参数用来控制什么条件下将块加入FREELIST和从FREELIST中移除。PCTFREE默认的大小为10，意味着当块被使用了90%之后，将会从FREELIST中移除。剩下的10%的空间用于块中数据行的更新。PCTUSED的默认的大小为40，意味着对于那些不在FREELIST中的块，如果其空余空间达到61%的时候，ORACLE会将这些块重新加入到FREELIST中去。怎样设置这两个值需要根据数据处理情况，例如对于那些很少更新的数据，设置过大的PCTFREE是空间的浪费。

行迁移

由于行的更新，使得行所占用的空间增大，当行原来所在数据块空间不够容纳更新后的行，行必须迁移到新的数据块上。行迁移的过程，会将行的数据迁移到新的块，同时在原来块中保留指向新行的指针。这是因为索引的物理指针仍然需要知道原来数据行的地址。由于这样，行迁移会带来更多的I/O访问（访问原来所在块，然后再通过指针访问前以后所在的块）。

已经迁移到新块的行，由于被再次更新，新块的空余空间也不能容纳，这行将会再次迁移。如果原来的块中现在有足够的空间了，这行将会迁移回去。否则，将会迁移到第三个块上去。

PCTFREE 和PCTUSED设置

下面的例子看设置PCTFREE和PCTUSED怎样影响FREELIST。
SQL> create table t ( x int, y char(1000) default 'x' );
Table created.

SQL> create or replace procedure measure_usage
2 as
3 l_free_blks number;
4 l_total_blocks number;
5 l_total_bytes number;
6 l_unused_blocks number;
7 l_unused_bytes number;
8 l_LastUsedExtFileId number;
9 l_LastUsedExtBlockId number;
10 l_LAST_USED_BLOCK number;
11
12 procedure get_data
13 is
14 begin
15 dbms_space.free_blocks
16 ( segment_owner => USER,
17 segment_name => 'T',
18 segment_type => 'TABLE',
19 FREELIST_group_id => 0,
20 free_blks => l_free_blks );
21
22 dbms_space.unused_space
23 ( segment_owner => USER,
24 segment_name => 'T',
25 segment_type => 'TABLE',
26 total_blocks => l_total_blocks,
27 total_bytes => l_total_bytes,
28 unused_blocks => l_unused_blocks,
29 unused_bytes => l_unused_bytes,
30 LAST_USED_EXTENT_FILE_ID => l_LastUsedExtFileId,
31 LAST_USED_EXTENT_BLOCK_ID => l_LastUsedExtBlockId,
32 LAST_USED_BLOCK => l_last_used_block ) ;
33
34
35 dbms_output.put_line( L_free_blks ' on FREELIST, '
36 to_number(l_total_blocks-l_unused_blocks-1 )

37 ' used by table' );
38 end;
39 begin
40 for i in 0 .. 10
41 loop
42 dbms_output.put( 'insert ' to_char(i,'00') ' ' );
43 get_data;
44 insert into t (x) values ( i );
45 commit ;
46 end loop;
47
48
49 for i in 0 .. 10
50 loop
51 dbms_output.put( 'update ' to_char(i,'00') ' ' );
52 get_data;
53 update t set y = null where x = i;
54 commit;
55 end loop;
56 end;
57 /
Procedure created.

SQL> exec measure_usage
insert 00 0 on FREELIST, 0 used by table
insert 01 1 on FREELIST, 1 used by table
insert 02 1 on FREELIST, 1 used by table
insert 03 1 on FREELIST, 1 used by table
insert 04 1 on FREELIST, 1 used by table
insert 05 1 on FREELIST, 1 used by table
insert 06 1 on FREELIST, 1 used by table
insert 07 1 on FREELIST, 1 used by table
insert 08 1 on FREELIST, 2 used by table--插入到第八行数据的时候，由于原来块上的空间不足，新增一个块供使用
insert 09 1 on FREELIST, 2 used by table
insert 10 1 on FREELIST, 2 used by table
update 00 1 on FREELIST, 2 used by table
update 01 1 on FREELIST, 2 used by table
update 02 1 on FREELIST, 2 used by table
update 03 1 on FREELIST, 2 used by table
update 04 2 on FREELIST, 2 used by table--更新到第四行的时候，将空间返回给FREELIST
update 05 2 on FREELIST, 2 used by table
update 06 2 on FREELIST, 2 used by table
update 07 2 on FREELIST, 2 used by table
update 08 2 on FREELIST, 2 used by table
update 09 2 on FREELIST, 2 used by table
update 10 2 on FREELIST, 2 used by table

PL/SQL procedure successfully completed.

INITIAL, NEXT, PCTINCREASE

定义初始EXTENT的大小以及后续EXTENT的大小。例如：INITIAL为1，NEXT为2，PCTINCREASE为为50，那么从EXTENT的一次大小为：1M，2M，3M，4.5M。如果数据库使用本地管理的表空间，EXTENT设置为UNIFORM的，那么INITIAL等于NEXT，PCTINCREASE没有意义。如果没有使用本地管理的表空间，也建议设置INITIAL等于NEXT，将PCTINCREASE设置为0。

MINEXTENTS，MAXEXTENTS

设置一个对象拥有最小和最大的EXTENT。当然，最大的EXTENT表空间的限制。

LOGGING，NOLOGGING

LOGGING，创建表的时候产生重做日志。使用NOLOGGING，创建表不产生重做日志，但是插入等操作仍然产生重做日志。

INITRANS，MAXTRANS

对象的每个块都有一个块头。块头中有一张事务表。在这张事务表中记录那些事务锁住了这个块上的那些行。初始值由INITRANS指定，最大值有MAXTRANS指定。

《Expert one on one Oracle》- 重做回滚- 笔记-3

2007-06-27T14:10:00.000-07:00

临时表以及重做/回滚

Oracle不会为临时表的数据块产生重做日志，所以临时表上的操作都是不可“恢复”的。当对临时标的数据块进行更改的时候，更改的纪录不会在重做日志中记录。然而，临时表会产生回滚，回滚信息会被重做日志纪录。所以，临时表会产生重做日志。临时表之所以会产生回滚信息，这是为了支持事务中回滚。例如：临时表和普通表一样也有约束（constrain），所以当不满足约束的数据更新或者插入的临时表的时候，必须能够回滚。

插入临时表产生的回滚数据非常少，查询临时表不产生回滚数据。但是更新和删除临时表数据将会产生较多的回滚信息。

SQL> create table perm
2 ( x char(2000) default 'x',
3 y char(2000) default 'y',
4 z char(2000) default 'z' )
5 /
Table created.

SQL>
SQL> create global temporary table temp
2 ( x char(2000) default 'x',
3 y char(2000) default 'y',
4 z char(2000) default 'z' )
5 on commit preserve rows
6 /
Table created.

SQL> create or replace procedure do_sql( p_sql in varchar2 )
2 as
3 l_start_redo number;
4 l_redo number;
5 begin
6 select value into l_start_redo from redo_size;
7
8 execute immediate p_sql;
9 commit;
10
11 select value-l_start_redo into l_redo from redo_size;
12
13 dbms_output.put_line
14 ( to_char(l_redo,'9,999,999') ' bytes of redo generated for "'
15 substr( replace( p_sql, chr(10), ' '), 1, 25 ) '"...' );
16 end;
17 /

Procedure created.

SQL>
SQL> set serveroutput on format wrapped
SQL>
SQL> begin
2 do_sql( 'insert into perm (x,y,z)
3 select 1,1,1
4 from all_objects
5 where rownum <= 500' );
6
7 do_sql( 'insert into temp (x,y,z)
8 select 1,1,1
9 from all_objects
10 where rownum <= 500' );
11
12 do_sql( 'update perm set x = 2' );
13 do_sql( 'update temp set x = 2' );
14
15 do_sql( 'delete from perm' );
16 do_sql( 'delete from temp' );
17 end;
18 /
3,263,576 bytes of redo generated for "insert into perm (x,y,z) "...
58,428 bytes of redo generated for "insert into temp (x,y,z) "...
2,160,600 bytes of redo generated for "update perm set x = 2"...
1,082,848 bytes of redo generated for "update temp set x = 2"...
3,353,108 bytes of redo generated for "delete from perm"...
3,253,220 bytes of redo generated for "delete from temp"...

PL/SQL procedure successfully completed.

通过如上可以看到，插入非临时表产生大量的重做日志，插入临时表则只有回滚段的“重做”日志产生，所以非常小。

更新非临时表产生大概两倍于更新临时表的“重做”日志。对于临时表，“镜像”前的更新被保存，而“镜像”后的更新无需保存。

删除在临时表和非临时表上产生的重做日志大小基本相同。这是因为，删除操作产生大量的回滚数据，而产生的更改块的重做日志非常小。

对于临时表，总结起来有如下规则：
a. 插入操作产生相当少的回滚/重做活动。
b. 删除操作产生的重做数量基本等于非临时表。
c. 更新操作产生的重做数量是更新非临时表的一半（如果字段的所有的值为空，以2000bytes的值更新这个字段，那么产生的重做类似于插入操作。反之，如果字段几乎所有的值有2000bytes，全部以NULL更新，那么产生的重做类似于DELETE）。

拥有如上知识后，在临时表实际的应用中，尽量只使用INSERT和SELECT操作。避免删除临时表，而是使用TRUNCATE命令或者让临时表在提交之后自行清空表。

分析表

可以通过LogMiner能够将重做日志载入系统的动态表（V$），从而能够方便的查询日志。可以看到执行DML语句之后，列值的变化；可以看到重做和回滚事务的SQL；可以当删除一个表的时候Oracle在OBJ$表上删除操作。这些都有利于DBA进行分析，找到恢复所需要的数据和时间点。
回滚

什么操作产生最少/最多UNDO

INSERT操作产生很少的UNDO，因为ORACLE只需要记录需要删除的ROW ID。UPDATE操作通常列第二位，因为ORACLE需要纪录更改的BYTES，而UPDATE通常只更新整行的部分字段。DELETE操作一般意义来说，产生最多的UNDO。因为需要纪录删除前整行的数据。

SET TRANSACTION

通过这个语句可以指定事务运行所使用的回滚段。一般不用使用这种方式，而是将MAXEXTENTS设置足够大，然ORACLE自动区扩展回滚段。如果需要，设置参数使得回滚段在扩展到一定大小之后，再自动缩减到一定大小。

使用打得回滚段的一个主要问题就是——不能阻止其他事务使用这个回滚段。所以最好的方式是让系统挑选回滚段，并让其能够自动扩展。同时，有些工具并不支持指定回滚段。IMP不支持，SQLLDR不支持，SNAPSHOT的刷新支持。

如果确实存在有一次性的大量的数据需要使用大的回滚段，也可以创建一个，然后进行处理，然后再置为OFFLINE，然后再删除。对于这种情况，将标分为几个部分，然后采用多个任务同时更新，这样各自的任务能够使用各自的回滚段，也许更有效。

ORA-01555：回滚段太旧

如下三个原因会造成这个错误：
a. 回滚段太小
b. 程序跨COMMITS取数
c. 块清除

前面两个都和ORACLE持续读相关。ORACLE使用回滚段来回滚那些查询开始后已经更改的块。通过这种方式，ORACLE提供一个连续的数据库的快照。通过两个Session来验证：

步骤1：
Session 1:创建表，插入数据，更新一条数据不提交
SQL> create table t1 ( a number );
Table created.

SQL> insert into t1 values(1);
1 row created.

SQL> commit;
Commit complete.

SQL> update t1 set a = 10 where a = 1;
1 row updated.

步骤2：
Session 2:插入数据
SQL> insert into t1 select * from t1 where a = 1;
1 row created.

步骤3：
Session 1:提交更新结果，查询表数据
SQL> commit;

Commit complete.

步骤4：
Session 2: 提交插入，查询数据表
SQL> commit;
Commit complete.

SQL> select * from t1;--由于一致性读，步骤2仍然能够插入数据
A
----------
10
1

处理这种ORA-01555的方法有：
a. 分析表，进行块清除。
b. 分配更大的回滚段。
c. 优化查询SQL。

回滚段太小造成ORA-01555的错误

重现错误:
a. Session A 发起一个查询。
b. Session B 发起一个更新并且提交。相关回滚信息记录在回滚段，同时因为已经提交，回滚段信息在需要的时候可能被覆盖。假定第1000个数据块被修改了。
c. Session A 继续运行，查询到第800个数据块。由于其他的一些操作，占用了大量的回滚段，回滚段的空间不够，特别地，1000个数据块更改的回滚信息被覆盖。
d. Session A 查询到1000个数据块的时候，发现数据块已经被更改，尝试查找回滚信息来保证一致性读，发现回滚信息已经被覆盖，从而引发了了ORA-01555错误。
即使将会滚段的MAXEXTENT设置足够大，但是由于查询语句并不自动扩展（更新语句能够自动扩展），所以通常还是在查询的时候会出现ORA-01555的错误。所以，不要让其自动扩展，而是通过手工调节。

对于9i的数据库，因为是自动管理回滚段，所以需要将其更改为手动管理之后，重新启动之后，才能运行如下的例子。
alter system set undo_management= manual scope=spfile;

步骤1：
Session1:创建很小的回滚段，创建测试表，执行更新语句
SQL> create rollback segment rbs_small--创建一个很小的回滚段
2 storage
3 ( initial 8k next 8k
4 minextents 2 maxextents 3 )
5 --tablespace rbs_test
6 /
Rollback segment created.

SQL> alter rollback segment rbs_small online;--设置为online
Rollback segment altered.

SQL> create table t
2 as
3 select *
4 from all_objects
5 /
Table created.

SQL> create index t_idx on t(object_id)
2 /
Index created.

SQL> begin
2 for x in ( select rowid rid from t )--执行更新语句，更新过程全表扫描
3 loop
4 commit;
5 set transaction use rollback segment rbs_small;--设置事务使用刚才建立回滚段
6 update t
7 set object_name = lower(object_name)
8 where rowid = x.rid;
9 end loop;
10 commit;
11 end;
12 /

步骤2：
Session2：执行查询语句（要确保步骤1的更新还未完成的时候运行）
SQL> select object_name from t where object_id > 0 order by object_id;
…….
ERROR: 出现ORA-01555错误
ORA-01555: snapshot too old: rollback segment number 11 with name "RBS_SMALL"
too small

由于步骤2中的查询是通过索引，所以其访问数据块是顺序是随机的，查询访问那些步骤1中被更新的快的几率会增大，从而可能造成ORA-01555的错误。如果是步骤2中使用全表扫描查询（通过RULE指定），那么由于步骤2的查询比步骤1的更新所花费的时间更少，所以经常是查询完成再去更新，从而产生ORA-01555错误的几率将会非常小。

交叉提交造成ORA-01555的错误

如下的例子中，将会每100行更新之后就提交一次。就有可能，查询会重新访问已经提交更新的块。而由于回滚段的信息已经被覆盖，所以也会造成ORA-01555错误。

SQL> declare
2 l_cnt number default 0;
3 begin
4 for x in ( select rowid rid, t.* from t where object_id > 0 )
5 loop
6 if ( mod(l_cnt,100) = 0 )
7 then
8 commit;
9 set transaction use rollback segment rbs_small;
10 end if;
11 update t
12 set object_name = lower(object_name)
13 where rowid = x.rid;
14 l_cnt := l_cnt + 1;
15 end loop;
16 commit;
17 end;
18 /
declare
*
ERROR at line 1:
ORA-01555: snapshot too old: rollback segment number 11 with name "RBS_SMALL"
too small
ORA-06512: at line 4

块延迟清除造成ORA-01555的错误

造成错误的原因是非常严格的，所以现实情况中由这种原因而造成的ORA-01555非常少，需要满足如下条件：
a. 一个更新被提交，部分块没有被自动清除事务标示。
b. 在某个SQL访问这些块前，这些块不被其他的SESSION访问。
c. 这个SQL开始运行，其SCN为T1。这个SQL最终会访问到上述没有被清除事务标示的块。
d. 系统中又有许多其它的事务提交，但这些事务并不访问上述的块。
e. 由于其他事务的提交，最初的更改数据事务的事务实体被循环重用。
f. 最终，回滚段中最小的SCN号已经大于T1。这个时候，SQL访问这些块的时候，不能判断COMMIT SCN是大于T1（如果大于T1，回滚）还是小于T1（如果小于T1，SQL将会使用这个块）。

参考：回滚段探究

《Expert one on one Oracle》- 重做回滚- 笔记-2

2007-06-26T14:52:00.000-07:00

块清除

当Oracle更改数据块时，会对这个数据块进行跟踪。在提交的时候，将会重新访问这个块并将更改标记为已经提交。但是只标示那些还没有从db_block_buffers中清除的块。而且，如果更改了太多的块，那么也只有前面少数的块（db_block_buffers的10%）被重新访问。

当提交的时候，如果这些块还在缓存中，那么Oracle将会进行fast commit，清除块头部的事务信息。对于那些已经从db_block_buffers中清除，被写入磁盘的数据块，Oracle将会忽略这些块。当下次的DML或者查询语句再访问这些块的时候，由这些语句负责清除，这就是所谓的delayed block cleanout。所以，即使是查询语句也可能产生重做日志。

通过如下的方法来验证：
a. 创建表，保证一块只能存储一行，在8K大小数据块中，创建每行大小为6K的数据库；
b. 插入499行纪录，使用499个数据块，其大小已经超过30（也即300的10%）；
c. 提交；
d. 对于在db_block_buffers的数据块（同时保证小于db_block_buffers 10%），Oracle执行fast commit，对于其他的数据块Oracle将忽略；
e. 执行全表扫描的查询语句。这条语句将会重新访问步骤d中没有被清除的块，对这些块头的事务信息进行清除，这个步骤将会产生重做日志。
f. 检查通过步骤e查询所产生的重做日志。
g. 执行新的查询，由于步骤e已经清除块头的事务信息，这个时候查询将不会需要清除块，也不会产生重做日志。

SQL> create table t --保证一块只能存储一行
2 ( x char(2000) default 'x',
3 y char(2000) default 'y',
4 z char(2000) default 'z' )
5 /

Table created.

SQL>
SQL> insert into t --插入499行纪录，使用499个数据块
2 select 'x','y','z'
3 from all_objects where rownum <500
SQL> commit;-- 提交，插入过程中部分快会执行fast commit，部分块被忽略

Commit complete.

SQL>
SQL> column value new_value old_value
SQL>
SQL> select * from redo_size;

VALUE
----------
3332424

SQL>
SQL> select *
2 from t
3 where x = y;

no rows selected

SQL> select value-&old_value REDO_GENERATED from redo_size;
old 1: select value-&old_value REDO_GENERATED from redo_size
new 1: select value- 3332424 REDO_GENERATED from redo_size

REDO_GENERATED
--------------
10740 --查询过程产生了重做日志，证明进行了块清除操作

SQL> commit;

Commit complete.

SQL>
SQL> select value from redo_size;

VALUE
----------
3343164

SQL>
SQL> select *
2 from t
3 where x = y;

no rows selected

SQL>
SQL> select value-&old_value REDO_GENERATED from redo_size;
old 1: select value-&old_value REDO_GENERATED from redo_size
new 1: select value- 3343164 REDO_GENERATED from redo_size

REDO_GENERATED
--------------
0--查询过程没有产生重做日志，前面的查询已经清除块，第二次查询不再有清除动作

上面的第一个查询产生了重做日志，有可能促使这些块被DBWR重写。Oracle必须采用delayed clear out的策略，否则在提交的时候必须重新访问更新块，还可能从磁盘中读取快，这将会是相当耗时的工作。

有些事务创建“干净的”数据块，例如：CREATE TABLE AS SELECT。

在某些情况下，进行大量的数据更新之后，也可以主动访问数据块，让最终用户访问的时候速度会更快。例如通过ANALYZE命令，可以清除块。

参考：
Block cleanout - fast or delayed.

《Expert one on one Oracle》- 重做回滚- 笔记-1

2007-06-25T14:39:00.000-07:00

“重做”允许Oracle重做事务。“回滚”则允许Oracle撤销或者回滚事务。

重做

重做日志文件是数据库的事务日志，只用来恢复数据库。Oracle有两种类型重做日志文件：在线重做日志和归档重做日志。在线重做日志以循环的方式来写入，当其中一个日志文件写满，就会切换写另外的日志文件，循环往复。归档日至是当在线日志写满的时候，将在线日志拷贝到另外一个地方。

COMMIT

COMMIT语句的执行并不消耗太多时间，而且并不是事务越大COMMIT所消耗的时间越多。实际的情况是，在COMMIT执行之前，Oracle已经完成所要提交事务的大部分工作。

SQL> create table t ( x int );
Table created.

SQL> set serveroutput on
SQL>
SQL> declare
2 l_start number default dbms_utility.get_time;
3 begin
4 for i in 1 .. 10000
5 loop
6 insert into t values ( 1 );
7 end loop;
8 commit;
9 dbms_output.put_line
10 ( dbms_utility.get_time-l_start ' hsecs' );
11 end;
12 /
135 hsecs

PL/SQL procedure successfully completed.

SQL>
SQL> declare
2 l_start number default dbms_utility.get_time;
3 begin
4 for i in 1 .. 10000
5 loop
6 insert into t values ( 1 );
7 commit;
8 end loop;
9 dbms_output.put_line
10 ( dbms_utility.get_time-l_start ' hsecs' );
11 end;
12 /
161 hsecs

PL/SQL procedure successfully completed.

从上面可以看到，插入多样的数据一次提交比进行多次提交消耗更少的时间。所以，提交的响应时间和事务大小并无太大关系。因为提交之前，Oracle已经完成99%的工作，具体为：
a. 回滚段的纪录已经在SGA中产生。
b. 更改的数据块已经在SGA中产生。
c. 上述两项的缓存的REDO已经在SGA产生。
d. 基于如上三项的的大小以及所消耗时间，上述数据的部分已经写入磁盘。
e. 已经获取所有需要的锁。

那么提交的时候，需要完成如下工作：
a. 为事务产生SCN。
b. LGWR将余下的缓存的重做日志写入磁盘，同时将SCN好记入到重做日志文件。完成这一步之后，事务实际上已经提交。事务实体被移除。在V$TRANSACTION表中找不到事物的相关纪录。
c. Session所持有的锁被释放。
d. 如果被事务所修改的快还在缓存中，那么大多数将被访问以及被“清除”。

真正消耗时间的在于LGWR将重做日志写入磁盘，因为这是物理的I/O访问。但是COMMIT之后，LGWR并不是将所有的内容写入重做日志。在COMMIT之前，LGWR已经持续的写重做日志。当如下条件满足的时候，LGWR写重做日志：
a. 每三秒
b. 当达到1/3或者1MB大小
c. 当COMMIT的时候

SCN是ORACLE用户保证事务的顺序，确保数据库能被正确恢复。同时，它也用来保证数据库的读一至性以及检查点（checkpointing）。每当事务提交，SCN号增一。

SQL> create table t
2 as
3 select * from all_objects
4 /
Table created.

SQL> insert into t select * from t;
29257 rows created.

SQL> insert into t select * from t;
58514 rows created.

SQL> insert into t select * from t where rownum < 12000;
11999 rows created.

SQL> commit;
Commit complete.

SQL>
SQL> create or replace procedure do_commit( p_rows in number )
2 as
3 l_start number;
4 l_after_redo number;
5 l_before_redo number;
6 begin
7 select v$mystat.value into l_before_redo
8 from v$mystat, v$statname
9 where v$mystat.statistic# = v$statname.statistic#
10 and v$statname.name = 'redo size';
11
12 l_start := dbms_utility.get_time;
13 insert into t select * from t where rownum < name =" 'redo">
SQL> set serveroutput on format wrapped
SQL> begin
2 for i in 1 .. 5
3 loop
4 do_commit( power(10,i) );
5 end loop;
6 end;
7 /
9 rows created
Time to INSERT: .05 seconds
Time to COMMIT: .00 seconds
Generated 1,368 bytes of redo
99 rows created
Time to INSERT: .00 seconds
Time to COMMIT: .00 seconds
Generated 11,596 bytes of redo

999 rows created
Time to INSERT: .03 seconds
Time to COMMIT: .00 seconds
Generated 116,732 bytes of redo

9999 rows created
Time to INSERT: 1.34 seconds
Time to COMMIT: .00 seconds
Generated 1,079,844 bytes of redo

99999 rows created
Time to INSERT: 5.56 seconds
Time to COMMIT: .00 seconds
Generated 11,175,056 bytes of redo

PL/SQL procedure successfully completed.
从上述运行结果可以看到，随着插入数据量的增大，产生的重做日志也逐渐增大，插入所消耗的时间也增多，但是COMMIT所消耗的时间仍然相当的少。所以，也验证了上述结论：在COMMIT之前，ORACLE已经完成了绝大多数的工作，所以COMMIT锁耗用的时间是相当少的。

回滚

将上述程序的COMMIT（23，25行）替换成ROLLBACK，再执行察看回滚所消耗的时间。

Time to INSERT: .04 seconds
Time to ROLLBACK: .00 seconds
Generated 1,504 bytes of redo

99 rows created
Time to INSERT: .00 seconds
Time to ROLLBACK: .00 seconds
Generated 12,288 bytes of redo

999 rows created
Time to INSERT: .03 seconds
Time to ROLLBACK: .00 seconds
Generated 123,736 bytes of redo
9999 rows created
Time to INSERT: .42 seconds
Time to ROLLBACK: .00 seconds
Generated 1,146,652 bytes of redo

99999 rows created
Time to INSERT: 3.99 seconds
Time to ROLLBACK: 1.64 seconds
Generated 11,883,064 bytes of redo

PL/SQL procedure successfully completed.

从上述运行结果可知，与COMMIT不同，随着数据量的增大，回滚所消耗的时间也增加。这是因为回滚是一个消耗时间的操作。

回滚之前，数据库所完成的工作与提交部分（可以参考上述COMMIT部分）相同。
回滚时，ORACLE所需要完成的工作为：
a. 回滚所有的更改。从回滚段中读取数据，并执行与原来相反的操作。例如，如果原来插入一行，回滚时便删除一行。如果更新一行，回滚时候必须更新回去。
b. Session所持有的锁被释放。

测量产生的日志数量

创建如下的一个视图，可以方便的查询系统中的重做日志。
create or replace view redo_size
as
select value
from v$mystat, v$statname
where v$mystat.statistic# = v$statname.statistic#
and v$statname.name = 'redo size';

通过测试脚本，可以看到：通过一条语句更新N行，与通过N条语句来更新N行，所产生的重做日志的数量大致相同。对于删除操作，结果也类似。但对于更新操作，批量更新产生的重做日志更小一些。

还有，如果我们插入2000bytes的行，实际每行产生的重做日志要高于2000bytes。对于删除操作也类似。对于更新操作，将会是2000betys的两倍数量（需要记录数据以及回滚）。

触发器对重做日志的影响：
a. 删除操作的BEFORE和AFTER触发器不会增加额外的重做日志。
b. 插入操作的BEFORE和AFTER触发器都会增加额外的重做日志。
c. 更下操作的BEFORE触发器产生额外重做日志，而AFTER触发器不产生。
d. 行的大小影响插入过程额外重做日志，更新操作不受影响。

能否关闭重做日志

尽量不要关闭重做日志功能，有些语句NOLOGGING因子，但是实际上还是会产生重做日志。这些日志因为记录数据词典更改而产生的。多于NOLOGGING，有如下几点需要注意：
a. 即使使用NOLOGGING，还是会产生少量的重做日志，这用来保护数据词典。
b. NOLOGGING之影响当前操作。例如如果在创建表的语句中使用了NOLOGGING，那么只是在创建表的过程中不产生重做日志。后续对于标的插入删除以及更新还是会产生日志。其他的特殊操作例如INSERT /*+ APPEND */和SQLLDR插入数据不会产生日志。
c. 在以归档模式运行的数据库中，一旦使用NOLOGGING，那么尽快将受影响的文件备份。

待续....

《Expert one on one Oracle》- 事务 - 笔记

2007-06-22T09:09:00.000-07:00

事务的四个属性ACID（Atomicity，Consistency，Isolation，Durability）。

1.1 事务控制语句

Oracle中没有“开始事务”的语句，当第一条更改数据的语句（第一个获取TX锁语句）执行的时候，便隐式地开始了一个事物。

可以通过COMMIT或者ROLLBACK来显式结束事务。否则，你使用的工具将会为你结束事务。例如在SQL*PLUS中，退出session时SQL*PLUS就会替你提交事务，而在PRO*C中会替你回滚事务。

相关控制语句语句有COMMIT，ROLLBACK，SAVEPOINT，ROLLBACK TO ，SET TRANSACTION。通过语句SET TRANSACTION可以指定事务的隔离级别，是否只读，以及使用的回滚段。

Oracle中事务具有Atomicity，语句也具有Atomicity。单条语句的失败，不会影响到前面已经执行语句的回滚。察看下面例子：

SQL> create table t( a int check(a>0 ) );
Table created.
SQL> insert into t values(1);
1 row created.
SQL> insert into t values(-1);
insert into t values(-1)
*
ERROR at line 1:
ORA-02290: check constraint (SCOTT.SYS_C003586) violated
SQL> select * from t;
A
----------
1
SQL>

上面例子，显示即使单条语句也具有原子性，第二条语句执行失败，但是第一条语句仍然成功。实际上Oracle处理上述语句的时候，隐式的按照如下方式执行：

Savepoint statement1;
Insert into t values ( 1 );
If error then rollback to statement1;
Savepoint statement2;
Insert into t values ( ‐1 );
If error then rollback to statement2;

另为对于存储过程的调用Oracle也将其作为原子性语句来执行。

SQL> create table t( a int check(a>0 ) );
Table created.

SQL> create or replace procedure p1
2 as
3 begin
4 insert into t values (1);
5 insert into t values (-1);
6 end;
7 /
Procedure created.

SQL> begin p1; end;
2 /
begin p1; end;
*
ERROR at line 1:
ORA-02290: check constraint (SCOTT.SYS_C003588) violated
ORA-06512: at "SCOTT.P1", line 5
ORA-06512: at line 1

SQL> select * from t;
no rows selected

由于整个存储过程的调用作为一个原子性操作，所以第一条插入语句也被回滚。Oracle默认在调用存储过程之前插入了一个SAVEPOINT，所以P1调用失败，标回滚到调用P1之前，所以第一条插入语句也被回滚。

如果采用另外一段语句来调用P1：

SQL> begin p1;
2 exception
3 when others then null;
4 end;
5 /
PL/SQL procedure successfully completed.
SQL> select * from t;
A
----------
1

这是因为在调用过程中增加了异常处理函数。虽然捕获异常不做任何处理，Oracle还是认为执行成功了。这个时候，“如果错误，那么回滚”的原则在这里将不起作用。同时，在P1中，由于两条插入语句也是原子性操作，这个时候P1是提交这两条语句的Oracle客户端，所以第一条语句执行成功。

从上可以看到，在开发程序的过程中，对事物的控制是多么的重要。如果上述P1的例子的业务要求两次插入要么全部成功要么全部失败，增加异常处理语句而实际不做任何处理，将会带来与业务需求相悖的结果。

1.2 事务与完整约束性检查：

a. 是SQL语句的而不是语句的完整约束性检查。如果一个存储过程中包含多个SQL语句，那么每条SQL语句执行完成的时候，都需要检查。

b. 是在语句执行完成之后检查，而不是在执行过程中。如果更新10行纪录，那么是要等到10行记录更新之后才检查，而不是更新其中的某几条就检查。

c. 可以通过DEFERRED选项来延迟约束性检查。
DEFERRABLE INITIALLY DEFERRED：允许延迟验证约束，默认方式为延迟，等待提交后验证，可以修改为第二种状态。
DEFERRABLE INITIALLY IMMEDIATE：允许延迟验证约束，默认方式为立即，处理完一条记录就立即验证，可以修改为第一种状态
NOT DEFERRABLE：不允许延迟验证约束，不能与上面两种状态进行转换。

SQL> create table pt
2 ( pk int primary key )
3 /
Table created.

SQL> create table ct
2 ( fk int constraint c_fk
3 references pt(pk)
4 deferrable
5 initially immediate -- 立即检查
6 )
7 /
Table created.

SQL> insert into pt values (1);
1 row created.

SQL> insert into ct values (1);
1 row created.

SQL> insert into ct values (2);--如果是立即检查，一旦不符合完整性约束，就会出错
insert into ct values (2)
*
ERROR at line 1:
ORA-02291: integrity constraint (SCOTT.C_FK) violated - parent key not found

SQL> rollback;
Rollback complete.

SQL> insert into pt values (1);
1 row created.

SQL> set constraint c_fk deferred;--更换成提交的时候再检查
Constraint set.

SQL> insert into ct values (2);
1 row created.

SQL> commit;--直到提交的时候才检查
commit
*
ERROR at line 1:
ORA-02091: transaction rolled back
ORA-02291: integrity constraint (SCOTT.C_FK) violated - parent key not found

1.3 编程的坏习惯

两个坏习惯
a. 可以一次提交的事务而多次提交。
b. 不设定足够大的回滚段。

关于第一点的测试，可以编写循环，在循环中多次提交，同一次提交所耗用的时间进行对比。

对于第二点的测试，可以将原来的rollback置为offline的状态，创建小的回滚段，执行循环更新的语句，检查结果是否报ORA‐01555错误。

对于ODBC和JDBC，默认都是自动提交。ODBC最初由SQL Server的开发人员设计。而在SQL Server中，锁是稀少资源，所以被设置为自动提交。而对于JDBC，在开发的时候最好将其设置为不自动提交。

1.4 分布式事务

Oracle能够透明的处理分布式事务，采用2PC协议来实现。通过DBLink，不同数据库之间可以相互访问。客户端最初登录的那个数据库，将作为事务的协调者。这样，这个数据库会询问其他数据库是否准备提交，其他的数据库就会反馈状态。如果都是YES，那么这个事务将会提交。如果有一个数据库反馈NO，那么整个事务就会回滚。

通常作为事务协调者的数据库如果出现故障，那么其他的数据库事务就会挂起等待。这个时候，需要手工在其他的数据库上进行提交或者回滚（因为有回滚段的存在）。

DBLink的使用有如下的限制：
a. 不能通过DB Link提交Commit语句。
b. 不能通过DB Link执行DDL语句。
c. 不能通过DB Link创建SAVEPOINT。

1.5 Redo和Undo
待续………….

执行计划中Row 数量为0，为什么

2007-06-21T11:16:00.000-07:00

从Metalink中找到答案
如果游标没有关闭，那么通过TKPROF生成的输出将不会包含精确的执行计划，在原始的trace文件中要么没有STAT行，或则行数量遗失。当然可以通过EXPLAIN选项来产生执行计划，但这个时候产生的执行计划不一定是正确的。如果游标关闭，STAT行写入原始的trace文件。

解决方法：
可以通过执行其他无关的SQL来关闭游标或通过dbms_session.reset_package过程来完成。

验证方法：
对比两种不同方式，检查在游标关闭和非关闭两种情况下，是否生成了对应的执行计划。

验证过程：
1. 创建一个过程，在过程中打开一个游标，执行某些操作，然后关闭游标。

创建表：

SQL> desc t_plan;
Name Null? Type
----------------------------------------- -------- --------------------

OWNER NOT NULL VARCHAR2(30)
OBJECT_NAME NOT NULL VARCHAR2(30)

创建过程：
CREATE OR REPLACE PROCEDURE scott.tkprof_test
AS
counts NUMBER;

CURSOR c1
IS
SELECT COUNT (*)
FROM t_plan
GROUP BY owner;
BEGIN
OPEN c1;

LOOP
FETCH c1
INTO counts;
EXIT WHEN c1%NOTFOUND;
DBMS_OUTPUT.put_line ('counts:' counts);
END LOOP;

CLOSE c1;
END;

2. 登录SQL*PLUS，打开一个session，设置SQL_TRACE为true，执行步骤1中创建的过程，不执行reset_package过程，设置SQL_TRACE为false。
SQL> alter session set sql_trace=true;

Session altered.

SQL> exec tkprof_test;
counts:99

PL/SQL procedure successfully completed.

SQL> alter session set sql_trace=false;

Session altered.

3. 通过TKPROF命令，检查步骤2输出文件。

********************************************************************************

SELECT COUNT (*)
FROM t_plan
GROUP BY owner

call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.11 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 2 0.00 0.00 0 4 0 1
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 4 0.00 0.11 0 4 0 1

Misses in library cache during parse: 0
Optimizer goal: CHOOSE
Parsing user id: 59 (recursive depth: 1)
********************************************************************************
4. 登录SQL*PLUS，打开一个session，设置SQL_TRACE为true，执行步骤1中创建的过程，执行reset_package过程，设置SQL_TRACE为false。
SQL> alter session set sql_trace=true;

Session altered.

SQL> exec tkprof_test;
counts:99

PL/SQL procedure successfully completed.

SQL> exec dbms_session.reset_package;

PL/SQL procedure successfully completed.

SQL> alter session set sql_trace=false;

Session altered.
5. 通过TKPROF命令，检查步骤4输出文件。

********************************************************************************

SELECT COUNT (*)
FROM t_plan
GROUP BY owner

call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.03 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 2 0.01 0.00 0 4 0 1
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 4 0.01 0.03 0 4 0 1

Misses in library cache during parse: 0
Optimizer goal: CHOOSE
Parsing user id: 59 (recursive depth: 1)

Rows Row Source Operation
------- ---------------------------------------------------
1 SORT GROUP BY
99 TABLE ACCESS FULL T_PLAN

********************************************************************************

注意：
1. 执行reset_package必须在alter session set sql_tracle = false命令之前执行，否则同样不能得到执行计划。
2. 对于单个在SQL*PLUS中执行的语句，执行完成后，可以通过“Select * from dual”或者“alter session set sql_tracle = ture”，游标会立刻关闭。
3. 今天读到Tom的《Oracle Expert one by one》10章的时候，提到通过原始的trace文件判断是否已经生成可信任的执行计划。在原始的trace文件中，STAT行纪录了运行时精确的执行计划，同时也会包含每一步执行计划中关联的正确的记录行数。也提到了只有当相关游标关闭之后，才会产生相关纪录。回过头看一下上面关闭游标的例子，其生成的trace文件相关部分内容为：

=====================
PARSING IN CURSOR #2 len=61 dep=1 uid=59 oct=3 lid=59 tim=19288630504 hv=2097396184 ad='66c8c0a4'
SELECT COUNT (*)
FROM t_plan
GROUP BY owner
END OF STMT
PARSE #2:c=0,e=38470,p=0,cr=2,cu=0,mis=0,r=0,dep=1,og=4,tim=19288630498
EXEC #2:c=0,e=50,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=19288660693
FETCH #2:c=15625,e=170,p=0,cr=4,cu=0,mis=0,r=1,dep=1,og=4,tim=19288665392
FETCH #2:c=0,e=17,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=19288670162
EXEC #1:c=15625,e=83199,p=0,cr=6,cu=0,mis=0,r=1,dep=0,og=4,tim=19288675090
=====================
PARSING IN CURSOR #3 len=52 dep=0 uid=59 oct=47 lid=59 tim=19288679793 hv=1697159799 ad='66c61e20'
BEGIN DBMS_OUTPUT.GET_LINES(:LINES, :NUMLINES); END;
END OF STMT
PARSE #3:c=0,e=108,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=19288679789
EXEC #3:c=0,e=209,p=0,cr=0,cu=0,mis=0,r=1,dep=0,og=4,tim=19288702763
*** 2007-06-13 14:35:20.000
=====================
PARSING IN CURSOR #1 len=40 dep=0 uid=59 oct=47 lid=59 tim=19313599313 hv=1443640743 ad='66b81f64'
BEGIN dbms_session.reset_package; END;
END OF STMT
PARSE #1:c=0,e=342,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=19313599304
STAT #2 id=1 cnt=1 pid=0 pos=1 obj=0 op='SORT GROUP BY '
STAT #2 id=2 cnt=99 pid=1 pos=1 obj=30711 op='TABLE ACCESS FULL T_PLAN '
EXEC #1:c=0,e=21520,p=0,cr=0,cu=0,mis=0,r=1,dep=0,og=4,tim=19313684039
=====================
已经将相关部分highlight，可以看到当查询的SELECT COUNT (*) FROM t_plan GROUP BY owner; 执行完成之后，并没有生成STAT纪录。直到调用dbms_session.reset_package方法之后，生成了STAT相关纪录。从STAT的记录行，可以看到操作以及对应的行数。

对大表的分析

2007-06-20T11:13:00.000-07:00

怎样对数据库中的大表进行分析
1)分析前备份统计信息: dbms_stats.EXPORT_TABLE_STATS
2)察看是否统计：user_table中的last_anaylyzed更新日起，user_index表中也存在对应字段。
3)对于数据量大的表要抽样分析，用dbms_stats分析对表的影响比analyze 更小一些。
4)对于数据变化比较频繁的表，需要定时分析，否则会产生性能问题。

参考:http://www.itpub.net/787943,1.html

V$OPEN_CURSOR, V$SESSION_CACHED_CURSOR

2007-06-19T11:09:00.000-07:00

概念：
OPEN_CURSOR，定义每个Session最大能够打开的游标数量。在init.ora文件中定义，可以通过select * from v$parameter where name = 'open_cursors'查询。
V$OPEN_CURSOR，当前Session缓存的游标，而不是曾经打开的游标。
V$SESSION_CACHED_CURSOR，当前Session已经关闭并被缓存的游标。
V$OPEN_CURSOR中显示的当前Session游标缓存中游标，如果要精确查询当前Session打开的游标总数，需要从V$ SESSTAT中查询。
select a.value, s.username, s.sid, s.serial#
from v$sesstat a, v$statname b, v$session s
where a.statistic# = b.statistic# and s.sid=a.sid
and b.name = 'opened cursors current';

Session Cache的原理
当设定SESSION_CACHED_CURSOR的值之后，当有parse请求的时候，Oracle会从library cache中查询。如果有超过3次同样的parse请求，这个游标将会存入Session的游标缓存中。对于将来同样的查询，就甚至不要soft parse，直接从Session的游标缓存中取。

登录两个SQL*PLUS客户端，分别为Session test和Session monitor。

1. 检查是否参数设置，以及执行的SQL语句是否在V$OPEN_CURSOR找到。
Session Test:
SQL> show parameter session_cached_cursors;

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
session_cached_cursors integer 0
SQL> select sid from v$mystat where rownum=1;

SID
----------
9

SQL> select sid from v$mystat where rownum=1;

SID
----------
9

通过如上的执行结果可以知道，当前参数设置session_cached_cursors的值为0，不缓存当前Session关闭的游标。当前Session的ID为9。
Session Monitor:
SQL> SELECT SID, n.NAME para_name, s.VALUE used
2 FROM SYS.v_$statname n, SYS.v_$sesstat s
3 WHERE n.NAME IN ('opened cursors current', 'session cursor cache count')
4 AND s.statistic# = n.statistic#
5 AND SID = 9;

SID PARA_NAME USED
--- ------------------------------ ----------
9 opened cursors current 1
9 session cursor cache count 0

SQL> select SID, USER_NAME,SQL_TEXT from v$open_cursor where sid=9;

SID USER_NAME SQL_TEXT
--- ---------- ------------------------------------------------------------
9 SCOTT select sid from v$mystat where rownum=1
通过如上的执行结果可以知道，当前在V$OPEN_CURSOR存储一个游标，对应SQL为Session Test执行的最后一条语句。V$SESSION_CACHED_CURSOR没有存储游标。

2. 更改参数V$SESSION_CACHED_CURSOR值。
Session Test:
SQL> alter session set session_cached_cursors = 1;

Session altered.

SQL> show parameter session_cached_cursors;

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
session_cached_cursors integer 1

3. 验证如下结论。
如果游标被存入SESSION_CACHED_CURSOR，前提是游标已经关闭，游标对应的SQL被执行3次以上。OPEN_CURSOR中会存储保存在SESSION_CACHED_CURSOR以及打开的游标（不是精确值）。
Session Test:
SQL> select sid from v$mystat where rownum =1;

SID
----------
9

SQL> select sid from v$mystat where rownum =1;

SID
----------
9

SQL> select sid from v$mystat where rownum =1;

SID
----------
9

Session Monitor:

SQL> select SID, USER_NAME,SQL_TEXT from v$open_cursor where sid=9;

SID USER_NAME SQL_TEXT
--- ---------- ------------------------------------------------------------
9 SCOTT select sid from v$mystat where rownum =1

SQL> SELECT SID, n.NAME para_name, s.VALUE used
2 FROM SYS.v_$statname n, SYS.v_$sesstat s
3 WHERE n.NAME IN ('opened cursors current', 'session cursor cache count')
4 AND s.statistic# = n.statistic#
5 AND SID = 9;

SID PARA_NAME USED
--- ------------------------------ ----------
9 opened cursors current 1
9 session cursor cache count 0
v$open_cursor dooes not show all open cursors. it shows more than that, the best option to find the number of open cursors is from v$sysstat.

通过如上的执行结果可以知道，即使同一个游标被打开3次，在SESSION_CACHED_CURSOR的数量仍然为0。下面，将会在Session Test中关闭游标（通过执行一条其他的语句）。
Session Test:
SQL> select * from t where rownum!=7;

no rows selected
Session Monitor:
SQL> SELECT SID, n.NAME para_name, s.VALUE used
2 FROM SYS.v_$statname n, SYS.v_$sesstat s
3 WHERE n.NAME IN ('opened cursors current', 'session cursor cache count')
4 AND s.statistic# = n.statistic#
5 AND SID = 9;

SID PARA_NAME USED
--- ------------------------------ ----------
9 opened cursors current 1
9 session cursor cache count 1

SQL> select SID, USER_NAME,SQL_TEXT from v$open_cursor where sid=9;

SID USER_NAME SQL_TEXT
--- ---------- ------------------------------------------------------------
9 SCOTT select sid from v$mystat where rownum=1
9 SCOTT select * from t where rownum!=7
通过如上的执行结果可以知道，游标被打开3次之后，如果这个游标关闭之后，游标会被存储到SESSION_CACHED_CURSOR当中。同时，通过OPEN_CURSOR中显示的SQL可以得知，OPEN_CURSOR中会存储保存在SESSION_CACHED_CURSOR以及打开的游标（不是精确值）。

SESSION_CACHED_CURSOR采用的是LRU算法，如果如果有新的游标需要缓存，而当前游标缓存已经满，最少使用的游标将会被清除出去。
调整SESSION_CACHED_CURSOR参数。通过如下SQL得到从缓存中取游标以及取PARSE的数量，为调整作参考。
select cach.value cache_hits, prs.value all_parses,
prs.value-cach.value sess_cur_cache_not_used
from v$sesstat cach, v$sesstat prs, v$statname nm1, v$statname nm2
where cach.statistic# = nm1.statistic#
and nm1.name = 'session cursor cache hits'
and prs.statistic#=nm2.statistic#
and nm2.name= 'parse count (total)'
and cach.sid= &sid and prs.sid= cach.sid ;

参考：
Monitoring Open and Cached Cursors
http://www.orafaq.com/node/758
v$open_cursor与session_cached_cursor
http://wzwanghai.spaces.live.com/Blog/cns!1p6cztYuyVBgutMjvxSWkuhw!151.entry

Jinitiator默认大小

2007-06-18T11:02:00.000-07:00

问题：
Compuware统计结果显示许多instance的launce transaction都显示为red，证明性能没有达到定义的SLA水平。其实这个Launce transaction的动作就是——打开浏览器，输入ERP的Form登录地址，载入显示登录界面。为什么这么简单的事务性能却很差。作为访问ERP客户的Agent离ERP服务器很近，网络不应该是考虑因素。最后定位为Cache问题。通过控制面板中，点开Jinitiator，察看Cache面板，缓存大小为安装默认的50M。察看存放缓存的目录，已经达到48M。因为在这个Agent上会访问很多的Instance，所以会有相当多的Jar需要Cache。然后，在Basic面板，Enable Java Console，这样可以从Console查看Applet载入的过程。打开一个最近很少访问的ERP地址，从Console可以看到有部分Jar文件需要重新Download（因为不在Cache目录中），有部分Jar从Cache目录中删除（因为已经达到Cache目录的最大限制），这些都是消耗时间的步骤。

解决方法：
增大Cache目录大小。选定无限制，这是因为这个Agent还有20G，而只用来测试ERP性能。

其他：
可以通过控制台设定Java使用的Cache大小，如果系统运行过程中发现是因为客户端速度太慢的问题。先观察一下更改Cache后的结果在说。有资料说The caching mechanism uses a smart expansion algorithm to store JAR files in an uncompressed format。找了很久没有找到到底是什么smart expansion algorithm。算了，也不重要了。

登录Agent后，发现Cache目录的大小刚刚被人改掉了，出手太慢。检查一下Cache目录大小，已经达到61M了。应该和设想的一样。其他性能较差部分，需要再检查一遍QRun的脚本，看到底是服务器性能问题还是脚本问题。

参考：
Metalink: Doc ID: Note:310976.1
http://www.oracle.com/technology/software/products/developer/files/1.3.1.25/readme.html

察看当前Session登录的数据库

2007-06-17T11:12:00.000-07:00

如果可以访问V$表，可以通过
select instance_name, version from v$instance;

如果没有相关权限，也可以通过SYS_CONTEXT得到Session登录的数据库。
select SYS_CONTEXT('USERENV' ,'DB_NAME') db_name from dual;

通过sys_context( namespace, parameter, [ length ] )，可以获取Oracle相关的环境信息。如果需要得到当前session的Oracle相关信息，在namespace的参数值为'USERENV'。还可以通过userenv函数来获取当前session的Oracle相关信息，这是一个遗留函数，Oracle推荐使用sys_context来获取。DBMS_SESSION.set_context设置parameter的值。

select SYS_CONTEXT('USERENV' ,'TERMINAL') terminal from dual;
select SYS_CONTEXT('USERENV' ,'LANGUAGE') language from dual;
select SYS_CONTEXT('USERENV' ,'SESSIONID') sessionid from dual;
select SYS_CONTEXT('USERENV' ,'INSTANCE') instance from dual;
select SYS_CONTEXT('USERENV' ,'ENTRYID') entryid from dual;
select SYS_CONTEXT('USERENV' ,'ISDBA') isdba from dual;
select SYS_CONTEXT('USERENV' ,'NLS_TERRITORY') nls_territory from dual;
select SYS_CONTEXT('USERENV' ,'NLS_CURRENCY') nls_currency from dual;
select SYS_CONTEXT('USERENV' ,'NLS_CALENDAR') nls_calendar from dual;
select SYS_CONTEXT('USERENV' ,'NLS_DATE_FORMAT') nls_date_format from dual;
select SYS_CONTEXT('USERENV' ,'NLS_DATE_LANGUAGE') nls_date_language from dual;
select SYS_CONTEXT('USERENV' ,'NLS_SORT') nls_sort from dual;
select SYS_CONTEXT('USERENV' ,'CURRENT_USER') current_user from dual;
select SYS_CONTEXT('USERENV' ,'CURRENT_USERID') current_userid from dual;
select SYS_CONTEXT('USERENV' ,'SESSION_USER') session_user from dual;
select SYS_CONTEXT('USERENV' ,'SESSION_USERID') session_userid from dual;
select SYS_CONTEXT('USERENV' ,'PROXY_USER') proxy_user from dual;
select SYS_CONTEXT('USERENV' ,'PROXY_USERID') proxy_userid from dual;
select SYS_CONTEXT('USERENV' ,'DB_DOMAIN') db_domain from dual;
select SYS_CONTEXT('USERENV' ,'DB_NAME') db_name from dual;
select SYS_CONTEXT('USERENV' ,'HOST') host from dual;
select SYS_CONTEXT('USERENV' ,'OS_USER') os_user from dual;
select SYS_CONTEXT('USERENV' ,'EXTERNAL_NAME') external_name from dual;
select SYS_CONTEXT('USERENV' ,'IP_ADDRESS') ip_address from dual;
select SYS_CONTEXT('USERENV' ,'NETWORK_PROTOCOL') network_protocol from dual;
select SYS_CONTEXT('USERENV' ,'BG_JOB_ID') bg_job_id from dual;
select SYS_CONTEXT('USERENV' ,'FG_JOB_ID') fg_job_id from dual;
select SYS_CONTEXT('USERENV' ,'AUTHENTICATION_TYPE') authentication_type from dual;
select SYS_CONTEXT('USERENV' ,'AUTHENTICATION_DATA') authentication_data from dual;

执行DBMS_SESSION的SET_CONTEXT函数
http://www.dbazine.com/blogs/blog-cf/chrisfoot/blogentry.2006-11-18.7319544765

定义SQL*PLUS类型的并发请求

2007-06-16T11:03:00.000-07:00

在定义可执行的时候，其中有一种类型为SQL*PLUS。虽然可能使用不频繁，但是这种类型在系统中的确存在。可以通过如下SQL查询当前系统中，各种类型可执行的数量。
SELECT COUNT (*), meaning
FROM fnd_executables_vl fev, fnd_lookups fl
WHERE fev.execution_method_code = fl.lookup_code(+)
AND fl.lookup_type = 'CP_EXECUTION_METHOD_CODE'
GROUP BY meaning;
通过输出结果可以发现，ERP中最多的类型为PL/SQL Stored Procedure，有2000多个，SQL*Plus只有300多个，Java类型的70个。记得Tom曾经说过，如果你的任务能够用SQL完成，那么就选择SQL，其次选在SQL*PLUS，然后PL/SQL，然后Java Procedure，然后C*PROC。Oracle绝大多数的并发请求都通过PL/SQL Stored Procedure实现。

那么怎样定义一个SQL*PLUS的并发请求呢？
1. 编写SQL*PLUS脚本，后缀为.sql。
clear buffer;
set heading on
set verify off
set feed off
set linesize 80
set pagesize 4
set underline '='
set serveroutput on size 1000000
begin
dbms_output.put_line('this is output by procedure dbms_output');
end;
/
set heading off
prompt
select application_short_name app_name from applsys.fnd_application where rownum <>

手工修改spife出现错误

2007-06-15T10:56:00.000-07:00

问题：
正在阅读到Expert One on One Oracle，想验证log_buffer的最小值为最大数据块的4倍。打开位于${ORACLE_HOME}/database/ SPFILEORA9I.ORA的数据库参数文件，发现没有对应的参数条目，然后手工增加log_buffer=1，通过服务控制台重新启动数据库。然后通过sql/plus连接，发现不能连接数据库。出现的错误为“ORA- 01034 : ORACLE not available”，“ORA-27101 : shared memory realm does not exist”。Google一下，许多人提到这是因为数据库没有启动。手工启动数据库，相关命令如下：
c:>sqlplus /nolog
sql>conn sys/abcdefg@server as sysdba
sql>startup
而执行如上语句，能够连接数据库，但是startup的时候，系统却报错：“ora-00600,[][][]”。通过“Database Configuration Assistant”进行参数修改的时候，出现同样的错误。

解决方法：

Google一下，原来有人和我犯了同样的错误：Sfile是一个二进制文件，不能通过文本的方式修改。如果需要修改，必须通过“alter system set ... scope=.. ”或者先修改，然后通过“create spfile from pfile;”将pfile里的内容复制到spfile里。参考：http://www.itpub.net/226670,1.html。

1) 将${ORACLE_HOME}/admin/ora9i/pfile/init.ora.4162007215332文件（这是数据库的pfile参数文件，8i前使用，可以手工编辑）拷贝到${ORACLE_HOME}/database目录下，更名为init.ora。

2) 运行如下命令，使用Pfile参数文件打开数据库。
sqlplus /nolog
conn sys/abcdefg@server as sysdba
startup pfile =${ORACLE_HOME}/databaseinit.ora;

3) 从Pfile重新创建Spfile。create spfile from pfile = 'init.ora';

Spfile相关内容：
找到了eygle关于Spfile的文章（http://www.eygle.com/faq/Oracle9i.New.Feature.Spfile.01.htm）。

1). Oracle通过startup时候，搜索参数文件的顺序：
a.spfile${ORACLE_SID}.ora in (NT: ${ORACLE_HOME}/database)
b.spfile.ora in (NT: ${ORACLE_HOME}/database)
c.init${ORACLESID}.ora in (NT: ${ORACLE_HOME}/database or${ORACLE_HOME}/admindb_name/pfile)

2).修改参数ALTER SYSTEM ，SCOPE参数有三个可选值：MEMORY ,SPFILE , BOTH。

3).查询是否使用了Spfile。

SELECT name,value FROM v$parameter WHERE name='spfile';
SHOW PARAMETER spfile;
SELECT COUNT(*) FROM v$spparameter WHERE value IS NOT NULL;

4).使用Rman备份Spfile。

5).使用Spfile屏蔽或者更改Oracle行为。alter system set event='10841 trace name context forever' scope=spfile;

其他问题。

解决问题的过程中，使用“Startup pfile”命令的时候还出现过“ORA-01031: insufficient privileges upon instance startup”错误。一般检查两个地方，登录系统的O/S用户是否在ORA_DBA用户组中。另为，是否配置${ORACLE_HOME}/network/admin下的sqlnet.ora文件是否存在，以及是否有“SQLNET.AUTHENTICATION_SERVICES = (NTS)”条目，否在Oracle不能使用O/S认证。