scoreking的博客

本人是一名Linux和Oracle技術的關注者，通過了OCP,RHCE,CIW(Security),MCSE,MCDBA,CCNA多項國際認證，希望對Linux和Oracle感興趣的朋友同我聯係，共同提高，我的聯係方式為：rootliu@sohu.com。

oracle temp表空间增长过快的解决方法

经常有人问temp表空间暴涨的问题,以及如何回收临时表空间,由于版本的不同,方法显然也多种多样,但这些方法显示是治标不治本的办法,只有深刻理解temp表空间快速增加的原因,才能从根本上解决temp ts的问题。

是什么操作在使用temp ts?
- 索引创建或重创建.
- ORDER BY or GROUP BY
- DISTINCT 操作.
- UNION & INTERSECT & MINUS
- Sort-Merge joins.
- Analyze 操作
- 有些异常将会引起temp暴涨

所以,在处理以上操作时,dba需要加倍关注temp的使用情况,v$sort_segment字典可以记载temp的比较详细的使用情况,而v$sort_usage将会告诉我们是谁在做什么.

sql>select tablespace_name,current_users,total_blocks,used_blocks,free_blocks from v$sort_segment;
TABLESPACE_NAME CURRENT_USERS TOTAL_BLOCKS USED_BLOCKS FREE_BLOCKS
------------------------------- ------------- ------------ ----------- -----------
TEMP 1 63872 30464 33408
sql>
SQL>select username,session_addr,sqladdr,sqlhash from v$sort_usage
USERNAME SESSION_ADDR SQLADDR SQLHASH
------------------------------ ---------------- ---------------- ----------
CYBERCAFE C0000000D7EF99E8 C0000000E1BFE970 4053158416

然后通过多表联接,我们可以找出更详细的操作:
SQL>select se.username,se.sid,su.extents,su.blocks*to_number(rtrim(p.value)) as Space,tablespace,segtype,sql_text from v$sort_usage su,v$parameter p,v$session se,v$sql s
where p.name='db_block_size' and su.session_addr=se.saddr and s.hash_value=su.sqlhash and s.address=su.sqladdr order by se.username,se.sid;
USERNAME SID EXTENTS SPACE TABLESPACE SEGTYPE
------------------------------ ---------- ---------- ---------- ------------------------------- ---------
SQL_TEXT
-------------------------------------------------------------------------------------------------------------------------
CYBERCAFE 42 238 249561088 TEMP SORT
select 1 from sys.streams$_prepare_ddl p where ((p.global_flag=1 and :1 is null) or (p.global_flag=0 and p.usrid=:2)) and rownum=1

本例应该是由一些异常引起的,其实大多数情况下sort都会在几乎内结束,如果在sort操作的若干秒内刚好就捕获了该SQL,应该走狗屎运的事情,即你知道某个SQL将会发生sort操作,当你想捕抓它们时,发现它们已经sort完了,排序完毕后sort segment会被smon清除。但很多时间,我们则会遇到临时段没有被释放，temp表空间几乎满的状况,这时该如何处理呢？

metalink上推荐的方法收集整理如下
-- 重启实例
重启实例重启时，smon进程会完成临时段释放,不过很多的时侯我们的库是不允许down的,
所以这种方法缺应用机会不多,不过这种方法还是很好用的,如果你的实例在重启后sort段
没有被释放,这种情况就需要慎重对待。
-- 修改参数 (仅适用于8i及8i以下版本)
SQL>alter tablespace temp increase 1;
SQL>alter tablespace temp increase 0;
-- 合并碎片
SQL>alter tablespace temp coalesce;
-- 诊断事件
SQL>alter session set events 'immediate trace name DROP_SEGMENTS level 4'
说明：temp表空间的TS#为3,So TS#+1=4
-- 重建temp
SQL>alter database temp tempfile '......' drop;
SQL>alter tablespace temp add tempfile '......';

可以说,以上的方法都是治标不治本的,因为temp增长过快显然是由于disk sort过多,造成disk
sort的原因也很多,比如sort area较小等原因,当然,sort area设置多大才合理？这个当然需要满足In-memory Sort大于99%以上哦。

Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %: 100.00 Redo NoWait %: 99.99
Buffer Hit %: 99.36 In-memory Sort %: 100.00
Library Hit %: 99.87 Soft Parse %: 99.84
Execute to Parse %: 1.17 Latch Hit %: 99.96
Parse CPU to Parse Elapsd %: 92.00 % Non-Parse CPU: 94.59

排序区域的分配
- 专用服务器分配sort area.
排序区域在PGA.
- 共享服务器分配sort area.
排序区域在UGA. (UGA在shared pool中分配).
在9i以前的版本,由sort_area_size决定sort area的分配,在9i及以后的版本,当workarea_size_policy等auto时,由pga_aggregate_target参数决定sort
area的大于,这时的sort area应该是pga总内存的5%.当workarea_size_policy等manual时,sort area的大小还是于sort_area_size决定.

无论是那个版本,如果sort area开得过小,In-memory Sort率较低,那temp表空间肯定会增长得很快,如果开得较高,在C/S结构中将会导致内存消耗严重(长连接较多).

由于smon进程每隔5分钟都要对不再使用的sort segment进行回收,如果你不想让
smon回收sort segment的话,可以使用以下两个event写入初始化参数文件,然后重启实例,这样如果你的磁盘排序较多,很快就会涨暴磁盘......

event="10061 trace name context forever, level 10" //禁止加收
event="10269 trace name context forever, level 10" //禁止合并碎片

通过合理地设置pga或sort_area_size,可以消除大部分的dist sort,那其它的disk
sort该如何处理呢？从sort引起的原因来看,索引/分析/异常引起的disk sort应该是很少的一部分,其它的应该是select中的distinct/union/group by/order by以及
merge sort join啦,那我们如何捕获这些操作呢？通常如何有磁盘排序的SQL,它的逻辑读/物理读/排序/执行时间等都是比较大的,所以我们可以对v$sqlarea或v$sql字典进行过滤,经过长期地监控数据库,相信可以把这些害群之马找出来.即然找出这些引起disk sort的SQL后怎么办呢？当然是对SQL进行分析,尽而优化之。
[oracle@www1 sql]$ more show_sql.sh
#!/bin/bash
sqlplus -s aaa/bbbcol sql_text format a81
col disk_reads format 999999.99
col bgets_per format 99999999.99
col "ELAPSD_TIME(s)" format 9999.99
col "cpu_time(s)" format 9999.99
set long 99999999999
set pagesize 9999
select address,hash_value,disk_reads/executions disk_reads,elapsed_time/1000000/executions as "ELAPSD_TIME(s)",
buffer_gets/executions bgets_per,executions,first_load_time as first_time,sql_text
from v$sql
where executions > 0 and (disk_reads/executions > 500 or buffer_gets/executions > 20000) and command_type = 3
order by 3,4;

--select s.disk_reads,s.buffer_gets/s.executions bgets_per,first_load_time,st.sql_text
-- from v$sql s,v$sqltext_with_newlines st
--where s.address=st.address and s.hash_value=st.hash_value
-- and s.disk_reads > 1000 or (s.executions > 0 and s.buffer_gets/s.executions > 50000)
--order by st.piece;
exit
!

总结,如何从根本上降低temp表空间的膨胀呢？方法有2个：
1 设置合理的pga或sort_area_size
2 优化引起disk sort的sql

表结构优化实例

-->

xzh2000 | 19 一月, 2005 16:14

应遵循的PL/SQL编码规则

http://www.net130.com　发布日期：2004-6-6

应遵循的PL/SQL编码规则 作者：Steven Feuerstein 提高编写PL/SQL代码数量及质量的四个简单易行指导方针 我从1990年就开始编写PL/SQL代码。这意味着我已经编写了几万行的软件代码，但我确信，其中的绝大多数代码都非常拙劣，而且难以维护。 幸运地是，我发现找到并遵循编写出更好代码的新方法还为时不晚。就是在去年，我的代码质量有了显著改进；这些改进主要是由于制定了一些简单的规则，并像纪律一样加以遵守。 本文为PL/SQL新手及有经验的开发人员提出了四条建议；遵守其中任何一条，你的代码质量都会有提高。这四点建议都采纳，你可能会惊奇地猛然发现：你竟然是一个非常好的程序员，要远远超乎你的想象。 所有工作都独自完成 我们很少有人是孤立工作的；大多数PL/SQL开发工作是在相对较大的机构中进行的。但我们基本上还是在自己的小隔间里用自己的设备独自工作。几乎没有PL/SQL开发小组进行正规的代码复查或系统测试。 我不可能通过这篇文章改变你们开发小组的基本状态。因此，我仔细地选取出以下几点建议。实施其中任何一点并不需征得管理人员同意。不论你的小组是大是小，都不必让其中的每个人都赞同这些编码规则。你只需按以下建议来改变你的本人的编码方式： 1. 严格遵循命名约定，好像它们就是你的生命支柱。 2. 戒除编写SQL的嗜好：编写的SQL越少越好。 3. 使执行部分短小：告别"意大利面条式的代码"。 4. 找一位伙伴：非常赞同找个人来监督你的工作。 1. 遵循命名约定 如果你建立并严格遵循一套命名约定，特别是对于应用程序组件的，你就可以节省很多时间。 当然，遵循命名约定的想法并没有什么新意，你可能已经听烦了。所以我并不提出什么宏伟的命名计划，而是给出一些非常具体而明确的约定，然后证明这些约定会多么有用。 前几个月我一直在为PL/SQL开发人员设计、构建一种新工具。它名为Swyg（可以在www.swyg.com中找到），可以帮助程序员完成代码的生成、测试及重用的工作。它具有几个独特的组件。我为每个组件指定了一个由两个字母组成的缩写名称，如下所示： SF-Swyg的基础部件 SM-Swyg的元数据 SG-Swyg的生成程序 SL-Swyg的代码库 ST-Swyg的单元测试 于是，我便遵循表1中的命名约定，同时使用这些缩写。遵循这些约定有什么好处呢？一般来讲，如果我要求一致的命名规则，我就可以更流畅更高效地编写代码。 明确地说，这些约定具有可预测性，意思是说我编写的SQL程序能生成有用的脚本。例如，通过使用表1中的约定，可以生成Swyg中所有基础包的安装脚本。执行这些工作的SQL*Plus脚本如清单1所示。这类脚本非常有用，因为它意味着我不必手动维护安装脚本。当我向Swyg方案中增加另一个表，并生成一组相关包时，我只要运行我的脚本，更新后的安装脚本便会跳出来。 2. 戒除编写SQL的嗜好 编写的SQL越少越好，这似乎与我们的直觉不太一致。对于PL/SQL开发人员来说，这是一个奇特的建议，因为PL/SQL的主要优点之一就是可以毫不费力地在代码中编写SQL语句。不过，这种简易性也是这种语言的一个致命的弱点。 可以将纯粹的SQL语句直接置于PL/SQL代码中，而无需JDBC或ODBC之类的中间层。因此，无论何时何地，PL/SQL开发人员只要需要SQL语句，他们通常就会向其应用程序代码中嵌入SQL语句。那么这样做有什么问题吗？ 在PL/SQL代码中到处使用SQL语句必然会导致以下后果： 　 尽管实际表现不同，但同一逻辑语句仍会出现重复，从而导致过多的语法分析，且难于优化应用程序的性能。 暴露商务规则和方案。这直接在SQL语句中包含了执行商务规则的逻辑。这些规则总在变化，所以应用程序的维护成本会急剧增加。 　 当然，你要编写的每一个PL/SQL应用程序几乎都是基于基础表和视图的。你需要执行SQL语句。问题不在于是否执行，而是何时执行、如何执行。 如果你对数据结构进行封装，或者将它们隐藏于一个PL/SQL代码层（通常是一个代码包）之后，那么你的应用程序将会更健壮，而且你还会发现创建和维护变得更易多了。 我们来看一个简单的例子。 假定我需要编写一个处理某员工工作的程序。第一件事是获取该员工的全名，定义为"姓名逗号（，）姓"；然后我可以进行详细分析。清单2给出了这种情况下我很可能要编写的这类代码的一个示例。 一切似乎都是这么简单和直接；这些代码可能会有什么错误呢？实际上真是非常糟糕。最主要的是我暴露了一个商务规则：全名的结构。我可能要花费数小时来对此代码及其所基于的应用程序进行测试。但就在它刚刚投入使用时，我才知道客户会不断地打电话告诉我，实际上，他们的全名应该表示为"名空格姓"。 现在怎么办？搜索所有位于引号内的单个逗号？ 现实的解决方案是使用隐藏所有细节、只提供一组预定义、预测试及预优化并能完成所有任务的程序包。清单3为基于封装代码重新编写的process_employee过程。hr_employee_tp包提供了用于定义保存姓名的局部变量的类型；hr_employee_rp包含有基于一种商务规则而返回全名的函数。 将显示PL/SQL语句灌入SQL代码很容易，同样，谈论封装这些语句是如何重要也不费劲。但另一方面，编写执行封装任务的代码却具有挑战性；甚至是不现实的。生成这些包或许更有意义。 几年前，我曾帮助构建这样一个生成程序。该程序段为PL/Generator，现在由Quest Software公司拥有，PL/SQL开发社区可以免费使用。你可以从我的网站www.StevenFeuerstein.com/puter/gencentral.htm下载。要知道，其封装体系结构与我在前面所概括的约定不同。PL/Generator创建了一个单独的包，它包含了一个表的类型、查询和变化逻辑的全部内容。 当你不再编写太多的SQL，而是调用执行SQL的程序时，无论你是生成还是编写自己的定制封装，你的应用程序都会受益匪浅。 3. 使执行部分短小 面对现实吧：总是与我们的判断和最新的一系列新年决议相左，我们必须停止编写意大利面条式的代码：庞大而冗长，人们实际上不可能理解它们，更不用说维护或升级了。怎样才能避免"意大利面条"呢? 实际上，答案很简单：决不允许执行部分超过50或60行。这种大小使你能在一页纸或一个屏幕上查看该代码块的整个逻辑结构，这也意味着你可以真实地领会该程序的意图，而且完全凭直觉就能理解它。 你可能非常同意上述观点，但同时又嘲笑我的建议：程序代码永远不超过50行。没错，你应当嘲笑，因为这当然是不可能的。毫无疑问，你需要超过50行的可执行代码；问题是你把这些代码放在哪，以及你怎样加以组织。 如果采取以下做法，你的确能够应对各种复杂的要求，并把代码限制在50行以内： 将所有的商务规则和离散逻辑块置于其自已的程序（通常是函数）中，从而在任何可能的时候慎重地重用代码。 尽量使用在程序的声明部分定义的局部模块、过程和函数。 假定我在编制一个呼叫中心应用程序。我需要编写一个程序，它要满足下面的要求： "对于特定部门的每个员工，将其工作量（分派给该员工的呼叫次数）同该部门员工的平均工作量进行比较。如果某员工的工作量低于平均工作量，便将下一待处理呼叫分派给此人，并基于这种情况安排约定。" 我从以前的工作中获悉：我的朋友Claudia已经编写了一个分析包，它会返回工作量方面的信息。但是分派待处理呼叫和安排约定都是全新的工作，需求文档的其余部分对此进行了详细说明。 最初我想把这15页的内容全都看完，但我没有那样做。我使用了一种称为"逐步求精法"或"由顶向下设计"的技术，并先编写了清单4中的代码来实现该程序。 下面给出了清单4中最关键代码行的解释；由该程序（紧凑的执行部分）的最后开始，向上进行。这似乎有悖于直觉，但这的确是通读用逐步求精法编写的程序的最好方式。 第22～30行。用一个游标FOR循环（cursor FOR loop）来对指定部门的所有员工进行迭代处理。在第24～25行，利用分析包中的程序判定当前的员工是否工作量不足。在第27～28行，调用三个程序：assign_next_open_case、schedule_case和next_appointment。我还不知道怎样实现这些程序，但我知道它们通过其名称和参数表表达了需要事先完成的工作。 第10～19行。为第27～28行中的三个程序创建"stub"，也就是占位程序。注意，它们是局部模块，在assign_workload中进行定义，且不能从其他任何程序调用。 第5～8行。定义一个游标，以获得指定部门的所有员工。现在可以设法编译此代码。 对这样一个小程序成功完成编译好像是个小胜利，也的确如此。完成正确编译，然后是简单测试，然后增加一点代码，再进行正确编译，以此类推，诸如此类的小胜利缔造出构造精良的程序，而且会非常满意。 我还可以验证该分析程序是有效的，并且找出了要分派的任务适当雇员。这些工作全部完成后，我将从三个程序中挑出一个，比如assign_next_open_case，进行下一步或下一级别的精细设计。我要阅读该任务的文档，并在assign_next_open_case里编写一个简短的执行部分，它可反映该任务的概况。 很快，我的局部过程有了它自己的局部过程和函数，但在该过程的每一步，我的代码都很短、可读、易于测试、可根据需要进行调整。 4. 找一位好伙伴 计算机并不会编程，人才会。 有多少次你弯着腰、驼着背坐在计算机前，因无法找出代码中的错误而感到非常郁闷？先是几分钟过去了，接着又过了几小时。最后，对自己都厌烦了，感到非常失败，你把头伸出你的小隔间并请朋友过来帮你看一看。 通常会有下面三种情况之一出现： 当你的朋友从她的椅子上站起来时，一切都在瞬间变得非常清楚。 你的朋友瞥了一眼屏幕，马上就指出了问题所在。 你的朋友不负责该系统中你所做的部分，所以你必须说明你的程序在干什么。当你逐步讲解逻辑时，引起错误的问题所在会突然暴露在你面前。 事实就是自己很难调试自己的代码，因为你自己对它太投入、太专注了。 这个问题最好的解决办法是由开发经理创造这样一种文化：各种想法是共享的、不懂是可以原谅的并不会受到处罚、定期进行建设性的代码评审。不幸的是，这些文化上的改变是难以实现的。 与此同时，我建议在帮助改变你所在小组的文化的过程中你应起带头作用。找到另一位开发人员，最好比你经验丰富，并建立一种"伙伴"关系：在出现问题时，他可以充当你的参谋，当然，你也可以充当他的参谋。事前达成共识：不知道所有问题的答案并没有什么不对。 然后为你自己制定一条简单的规则：不要为一个错误苦思冥想超过半个小时。30分钟过去后，把你的伙伴叫过来，让人类心理学为你服务，而不是跟你作对。 获得一种新工作方式的四个步骤 本文为你提供了可以采取的用于改变你的编程体验四个步骤，而无须投资新的工具或改变整个小组的工作流程。这四步甚至可以不全部遵循，只要遵守一步都会让你受益。 Steven Feuerstein (steven@stevenfeuerstein.com) 是PL/SQL语言方面的一位权威人士。Feuerstein撰写了9本有关PL/SQL （全部由O'Reilly & Associates出版公司出版）的书籍，其中包括《Oracle PL/SQL最佳实践（Oracle PL/SQL Best Practices）》和《Oracle PL/SQL编程（Oracle PL/SQL Programming）》。他还是Quest Software公司的资深技术顾问。 对象 名称结构 注释 生成（DDL）文件 表 _ 表名，如SM_TASK，用于在普通的Mentat组件中定义的任务。 _.tab 主键列 id 标准是：（几乎）每个表都包含一个按一个序列生成的id列。对于交叉表等有一些例外。 N/A 用于生成主键的序列 __seq 用于一个表主键的序列名，如SG_SCRIPT_SEQ，它为Mentat产生脚本表生成一个新主键。 _.seq 查询封装包 __qp 包含用以在基础表（如SL_SOURCE_QP）中检索数据的标准API，它有助于在Mentat可重用库中查询各元素的源代码。 说明：__qp.pks 主体：__qp.pkb 改变封装包 __cp 包含用以改变（INSERT、UPDATE、DELETE）某基础表（如ST_UNITTEST_CP）中的数据的标准API，它使我能够维护单元测试定义。 说明：__cp.pkb 主体：__cp.pks 类型封装包 __tp 包含用于指定表（如SG_GEN_RUN_TP）的预定义类型--包括集合、REF CURSORS、记录。 说明：__tp.pks 主体：NA (type definitions do not need a package body) 规则封装包 __rp 包含程序，通常是函数，它隐藏了关系到该实体的商务规则的细节。 说明：__rp.pks 主体：__rp.pkb 其他物件包 __xp 包含特定实体的自定义逻辑。 说明：__xp.pks 主体：__xp.pkb 　 关键字 是由两个字母组成的缩写。对于Swyg，它可以是SF、SM、SG、SL或ST。 是商务实体名，如TASK用于定义某人要完成任务列表；SCRIPT用于代码生成模板；等等。

1246

一sql导致数据库整体性能下降的诊断和解决的全过程

 查看全文

statspack的若干使用技巧

-->

xzh2000 | 17 一月, 2005 19:59

LINUX+ORACLE常用的环境设置 http://metalink.oracle.com/metal ... d=NOT&p_id=265262.1 Give general information about oracle on linux SCOPE & APPLICATION Provide information about limitation and features available for oracle version on different linux distributions Gerenal information about oracle on linux Linux Information Library <185752> Oracle Installation Guides SuSE Step by step Installation of RAC on linux (<184821>) Quick Start Guides (<201370>, <176865>, <114141>) 9iR2 RAC/NetApp/Red Hat Max os file size 2Gb (filesystem ext2): <= linux 2.2 >2Gb: >= linux 2.4 Large File Support Ext2, ReiserFS, JFS, XFS, OCFS <=16Tb: (kernel 2.4 limit) Raw device OS Header No header Max Oracle file size 2Gb: <=8.1.7 >2Gb: >= 9.0.1 Max SGA size Summary About the Large SGA & Address Space on Linux <260152> Red Hat adv Server Specific Async IO Yes for ext2, ext3, raw Yes for OCFS ≥ 1.0.9-4 but not yet activated in Oracle (as of 9.2.0.4) Red Hat AS 2.1+ <225751>(patch for RH3) UnitedLinux 1.0 aio-max-size must be <= 524288 RAC & Filesystems (<183408>) RH2.1+ & United Linux: OCFS Raw Devices on RedHat Advanced Server - FAQ <224302> Max IO Size . Must be >= db_file_multiblock_read_count*db_block_size db_file_direct_io_count*db_block_size hash_multiblock_io_count*db_block_size sort_multiblock_read_count*db_block_size aio-max-size (<225751>) Find it yourself! 256K (default VxVM Maximum I/O Size) and VxFS 3.4 Disk & File System layout fdisk -l Shared libraries support in PRO*C? Yes glibc 2.06 + List of dynamic libraries in executable file /usr/bin/ldd OS version /usr/bin/uname -s -r cat /proc/version cat /etc/issue Linux Memory Management linux-mm swap status /sbin/swapon -s free -t xosview cat /proc/swaps Swap Space on RedHat Advanced Server - FAQ (<225451>) Amount of RAM, hardware config cat /proc/meminfo cat /proc/cpuinfo /bin/dmesg cat /var/log/dmesg How to Read '/proc/meminfo' Output (<233753>) OS kernel parameters files (<68862>) /sbin/sysctl -a /etc/sysctl.conf /usr/src/linux/include/* /usr/src/linux/include/linux/shm.h for shared memory /usr/src/linux/include/linux/sem.h for semaphores How to permanently set kernel parameters on Linux (<242529>) OS kernel parameters values /sbin/sysctl -a ipcs -l Am I on a 32 or 64 bit OS? more /proc/cpuinfo Max number of semaphores sets (SEMMNI) /usr/bin/ipcs -ls (max number of arrays) /sbin/sysctl kernel.sem (4th & last value) awk '{print $4}' /proc/sys/kernel/sem Linux: How to Check Current Shared Memory, Semaphore Values (<226209>) Max number of semaphores per set (SEMMSL) /usr/bin/ipcs -ls (max semaphores per array) /sbin/sysctl kernel.sem (1st value) awk '{print $1}' /proc/sys/kernel/sem Max number of semaphores systemwide (SEMMNS) /usr/bin/ipcs -ls (max semaphores system wide) /sbin/sysctl kernel.sem (2nd value) awk '{print $2}' /proc/sys/kernel/sem Max number of shared segments /sbin/sysctl kernel.shmmni /usr/bin/ipcs -lm (max number of segments) cat /proc/sys/kernel/shmmni Max shared segment size /sbin/sysctl kernel.shmmax /usr/bin/ipcs -lm (max seg size (kbytes)) cat /proc/sys/kernel/shmmax (max value=4Gb) Max number of procs per user/system wide ?/MAX_TASKS_PER_USER (default NR_TASKS/2) From /usr/src/linux/include/linux/tasks.h Max number of open files per user/system wide /sbin/sysctl fs.file-nr Buffer cache size bdflush and buffermem parameters From /usr/src/linux/Documentation/sysctl/vm.txt cat /proc/sys/vm/buffermem (in % of RAM: buffer cache min size/prune(unused)/buffer cache max size) How to Get/Set Network parameters Get parameter value: /sbin/sysctl parameter Set parameter to value: /sbin/sysctl -w parameter value TCP keepalive parameters net.ipv4.tcp_keepalive_time (seconds) net.ipv4.tcp_keepalive_intvl (seconds) net.ipv4.tcp_keepalive_probes TCP tuning parameters send buffer size: net.core.wmem_default/net.core.wmem_max (128 to 256k recommended) receive buffer size: net.core.rmem_default/net.core.rmem_max (128 to 256k recommended) Auto tuning mode min/default/max send buffer size: net.ipv4.tcp_wmem min/default/max receive buffer size: net.ipv4.tcp_rmem low/default/max system memory for TCP stack (in pages): net.ipv4.tcp_mem UDP tuning parameters send/receive buffer sizes : same as TCP Process Limits (<188149>) ulimit -a Administration tool /bin/linuxconf System log file /var/log/messages Display system/error messages dmesg List of OS errors /usr/src/linux/include/asm/errno.h man errno Package installation rpm -Uvh or rpm -ivh Updating the Software RPM (Red Hat Package Manager (<233060>) Package deinstallation rpm -e Installed packages list rpm -qa To which package belongs file fname? rpm -qf fname Ex: rpm -qf /usr/lib/libm.so gives a result similar to glibc-devel-2.1.3-15 Latest kernel level/OS patch UL1.0 SLES8 x86: SP2a(2.4.19-304), SP3 (2.4.21-138) includes hangcheck-timer RedHat AS 2.1 x86: 2.4.9-e.38 RHEL 3.0 Update 1 Relinking Kernel cd /usr/src/linux;make config or make xconfig Debug and Miscellaneous /usr/bin/strace (system calls) - List of OS calls /usr/bin/ltrace (dynamic library calls) /usr/bin/vmstat (Memory Consumption tracing) the /proc File System The Linux Trace Toolkit hdparm for faster IO on IDE disk cat /proc/meminfo (Memory usage details <233753>) Top-level Files in the proc File System Core analysis (<1812>) /usr/bin/gdb -c core (gdb) type backtrace for stacktrace

kill session[metalink]
Problem Description -------------------

Killing the session will not clear the locks. The session on the remote
database will remain idle waiting for input until the network read times
out. Only then the kill session is processed, and locks are released.


Solution Description
--------------------

Options:
========

You can shutdown and restart the database or use the ORAKILL utility to kill
threads.


Oracle has provided an ORAKILL utility that will kill shadow threads. Each
user's connection is represented by a thread in the Oracle process. If a
user's session is killed, then their Oracle session is killed - not the thread.
Oracle has provided an ORAKILL utility which can be passed a thread ID and will
kill the specified thread.

To make sure you do not kill a background process (which would crash your
database), you must perform a select to ensure you get the correct thread.

---
select p.spid "OS Thread", b.name "Name-User", s.osuser, s.program
from v$process p, v$session s, v$bgprocess b
where p.addr = s.paddr
and p.addr = b.paddr UNION ALL
select p.spid "OS Thread", s.username "Name-User", s.osuser, s.program
from v$process p, v$session s
where p.addr = s.paddr
and s.username is not null;
---

This will list all Shadow processes and backgound processes.
Each shadow process will show the thread ID - this is what must be killed via
the ORAKILL utility.

The kill session behavior is mentioned in the ORACLE7 Server Administrator's
Guide (pg 4-13). It does not explicitly indicate what happens to the session
while it is in the KILLED PSEUDO state. What's happening is that PMON
periodically checks to see if any sessions have been killed.
If it finds one, it attempts to rollback the transaction for that session
(that was in progress when it was killed). The reason this can take a long time is
because PMON may have more than one transaction to rollback at a time
(if other sessions have been killed, or if processes have died etc).
Thus, it may take a while to finally cleanup the killed session and have it
disappear from the session monitor. The system i/o monitor correctly shows
the reads and writes being performed by PMON in order to rollback the
session's transaction.

PMON will not delete the session object itself until the client connected to
that session notices that it has been killed. Therefore, the sequence of
events is:

1) alter system kill session is issued - the STATUS of the session object in
V$SESSION becomes KILLED, its server becomes PSEUDO.

2) PMON cleans up the *resources* allocated to the session
(i.e., rolls back its transaction, releases its locks, etc).

3) the entry in V$SESSION remains there until the client of that session (the
client is the process associated with the OSUSER,MACHINE,PROCESS columns in
the V$SESSION view) tries to do another request.

4) the client attempts another SQL statement and gets back ORA-28.

5) PMON can now remove the entry from V$SESSION.
This behavior is necessary because the client still has pointers to the
session object even though the session has been killed. Therefore, the
object cannot be deleted until the client is no longer pointing at it.

一次教训，引以为鉴
数据库环境9.2.0.4 RAC两个节点
EMC存储

由于mail报警MIRRORRAC1 SPACE WILL BE USED UP SOON ..
要在裸设备新增数据文件
当时发现我记录的分区表，结合rawdevices表，发现由于在建立数据库初期给数据库预留的分区太少，到这次新增数据文件时
已经没有分区可以用了，必须用fdisk新增一个区，但是由于新增的区不会被OS认出（除非整个lun全部重新划分），
fdisk /dev/sdc 新建立sdc11（1026m），但是用dmesg|grep sdc11查不到，所以要想重新让OS能认，必须重新MOUNT这个区（没有试过），
但是由于sdc下面有很多区被使用了（除非数据库允许down机）。所以只能找其他捷径，因为我建立emc存储时划分了sdi,sdh,sdg没有被
划分（其实sdg已经划分了一个sdg5,问题就出在这），我看到这个sdg5已经在dmesg中可以看到，我看了一下相关的配置（当时建库时
的文档）没有发现使用了sdg5,当时好象也查了/etc/sysconfig/rawdevices也没有发现，在数据库中查了controlfile,redolog,datafile
等均未发现使用了sdg5,所以认为这个sdg5是可以被新增数据文件利用的，但是后来发现问题恰恰出现在这个sdg5,我后来恢复数据库后居然
在/etc/sysconfig/rawdevices中看到这个sdg5。
数据库是在alert中发现 600错误，发现monitor_kp无法访问，但是我在数据库中select count(*) from monitor_kp（其实是走索引的）
可以查到数据，认为数据库不存在问题。后来查看alert日志发现/opt/oracle/admin/oint/udump/oint1_ora_1842.trc文件中有
select * from monitor_kp order by id desc
该数据库读表数据错误。
先以为网站被攻击了，后来我发现可能跟我这次操作有关（这里也是一大过错，对自己过于相信是对的，没有及时去重起数据库，这里大概延时了15分钟）
于是准备重起数据库，shutdown abort时发生错误，ipcrm删除共享段，然后重起过程中就发现只能mount数据库，不能打开数据库，提示
/dbvol1/oradata/oint/appdata1m12.dbf数据文件坏了，然后我将数据库完全恢复起来，做了备份，网站数据库恢复正常。


添加数据文件的过程如下
raw /dev/raw/raw43 /dev/sdg5
/bin/ln -s /dev/raw/raw43 /dbvol1/oradata/oint/offerts03.dbf
chown oracle:oinstall /dbvol1/oradata/oint/offerts03.dbf
alter tablespace OFFERTS add datafile '/dbvol1/oradata/oint/offerts03.dbf' size 1025M;
数据文件添加成功



检查原因过程
1.cat /etc/sysconfig/rawdevices
...
/dev/raw/raw42 /dev/sdg5 --这这里发现了sdg5
...

2.于是我查一下由于被绑定的设备
[root@mirrorrac2 root]# raw -qa
...
/dev/raw/raw42: bound to major 8, minor 101 --原因找出来了，是由于原来就有文件/dbvol1/oradata/oint/appdata1m12.dbf使用了sdg5
/dev/raw/raw43: bound to major 8, minor 101 --我们看到绑定的设备都是101
...

就此可以确认是由于数据文件被覆盖的原因。
当前数据库的状态是数据完全恢复正常，但是两个数据文件公用同一个设备，当前设备的数据是raw42相关联的/dbvol1/oradata/oint/appdata1m12.dbf
而offerts的数据基本没用，过了一会offerts自动从online转换成recover状态，此时，数据库正常可以运行。

第2次恢复过程：
1.于是只能通过将offerts03.dbf从sdg5中分离出来。
利用sdi来保存offerts03.dbf
先在mirror2上建立fdisk /dev/sdi将所有的区建立起来

[root@mirrorrac1 root]# dmesg|grep sdi
Attached scsi disk sdi at scsi3, channel 0, id 0, lun 8
SCSI device sdi: 31457280 512-byte hdwr sectors (16106 MB)
sdi: unknown partition table
此时mirror1还是看不到sdi区
2.
[root@mirrorrac1 root]# blockdev --rereadpt /dev/sdi --同步mirror2的分区
[root@mirrorrac1 root]# dmesg|grep sdi
Attached scsi disk sdi at scsi3, channel 0, id 0, lun 8
SCSI device sdi: 31457280 512-byte hdwr sectors (16106 MB)
sdi: unknown partition table
SCSI device sdi: 31457280 512-byte hdwr sectors (16106 MB)
sdi: sdi1 < sdi5 sdi6 sdi7 sdi8 sdi9 sdi10 sdi11 sdi12 sdi13 sdi14 sdi15 >

--此时可以看到新的分区

3.
在两个节点同时运行绑定裸设备
[root@mirrorrac2 root]# raw /dev/raw/raw43 /dev/sdi5
/dev/raw/raw43: bound to major 8, minor 133
[root@mirrorrac1 root]# raw /dev/raw/raw43 /dev/sdi5
/dev/raw/raw43: bound to major 8, minor 133

4.检查raw绑定正确性，是否有重复绑定
[root@mirrorrac2 root]# raw -qa|awk '{print $7}'|wc -l
63
[root@mirrorrac2 root]# raw -qa|awk '{print $7}'| sort -u | wc -l
63

5.做备份
bash-2.05$ dd if=/dbvol1/oradata/oint/offerts03.dbf of=/mirror_backup/back_datafile/offerts03.dbf.0727 bs=10
49608k count=1
1+0 records in
1+0 records out

6.
SQL> alter database datafile '/dbvol1/oradata/oint/offerts03.dbf' offline;
Database altered.

7.
SQL> recover datafile '/dbvol1/oradata/oint/offerts03.dbf';
ORA-00283: recovery session canceled due to errors
ORA-01110: data file 38: '/dbvol1/oradata/oint/offerts03.dbf'
ORA-01122: database file 38 failed verification check
ORA-01110: data file 38: '/dbvol1/oradata/oint/offerts03.dbf'
ORA-01251: Unknown File Header Version read for file number 38
直接恢复不行

8.
alter database create datafile '/dbvol1/oradata/oint/offerts03.dbf'

9.
SQL> recover datafile '/dbvol1/oradata/oint/offerts03.dbf';
Media recovery complete.
SQL>
SQL>

10.
SQL> alter database datafile '/dbvol1/oradata/oint/offerts03.dbf' online;

Database altered.

11.检查文件状态
select name,status from v$datafile where file# in (37,38)
NAME STATUS
-------------------------------------- -------

/dbvol1/oradata/oint/appdata1m12.dbf ONLINE


/dbvol1/oradata/oint/offerts03.dbf ONLINE


12.检查OFFERTS03数据文件是否正常
SQL> select file#,name from v$datafile where name like '%offerts03.dbf%';
FILE# NAME
---------- --------------------------------------------------
38 /dbvol1/oradata/oint/offerts03.dbf

SQL> select * from dba_extents where file_id = 38;

no rows selected
--现在新增的数据文件没有对象

查看OFFERTS表空间的区大小
SQL> select NEXT_EXTENT/1024 from dba_tablespaces where TABLESPACE_NAME = 'OFFERTS';

NEXT_EXTENT/1024
----------------
32768

--由于OFFERTS有3个文件，那么要建立32M*3以上的表进行测试
SQL> select * from (select segment_name,bytes/1024/1024||'M' from user_segments order by bytes desc) where rownum < 10;

SEGMENT_NAME bytes/1024/1024||'M'
----------------------------------------- --------------------
......
COMPANY 188M
......

SQL> create table fanglf_test nologging tablespace offerts as select * from company;

Table created.

SQL> select segment_name from dba_extents where file_id = 38;

SEGMENT_NAME
--------------------------------------------------------------------------------
FANGLF_TEST
FANGLF_TEST
FANGLF_TEST
--表明该新增的数据文件是好的


13.检查appdata1m12.dbf数据文件是否正常
select file#,name from v$datafile where name like '%appdata1m12.dbf%';
FILE# NAME
---------- --------------------------------------------------
37 /dbvol1/oradata/oint/appdata1m12.dbf


SQL> select rowid from alibaba.COMPANY where DBMS_ROWID.rowid_relative_fno(rowid) = 37 and rownum < 10;

ROWID
------------------
AAACBSAAlAAAIgmAAC
AAACBSAAlAAAIiBAAB
AAACBSAAlAAAIihAAB
AAACBSAAlAAAIihAAC
AAACBSAAlAAAIihAAD
AAACBSAAlAAAIkEAAB
AAACBSAAlAAAIkEAAE
AAACBSAAlAAAIkEAAF
AAACBSAAlAAAIkXAAB

SQL> update alibaba.COMPANY
SET SITE = 'test'
where rowid = 'AAACBSAAlAAAIgmAAC';
2 3
1 row updated.

SQL> commit;

Commit complete.

SQL> update alibaba.COMPANY
SET SITE = '???'
where rowid = 'AAACBSAAlAAAIgmAAC';
2 3
1 row updated. --说明appdata1m12.dbf也没有问题

SQL> commit;
Commit complete.

修改vi /etc/sysconfig/rawdevices（在两个节点）
增加/dev/raw/raw43 /dev/sdi5

ORACLE管理员认证方法小记 关键字：OS认证 密码文件认证 参考： http://download-west.oracle.com/ ... .920/a96521/dba.htm １、 管理员的权限： SYSDBA: 默认schema 为SYS SYSOPER: 默认schema 为 PUBLIC 这两种权限允许用户在数据库没有打开的时候就可以登陆数据库，所以这种权限的控制权在数据库之外。通常这种权限也可以被看做一种允许你对数据库进行某种操作的连接，比如CONNECT / AS SYSDBA ２、 两种管理员权限认证方法 1) Operating system (OS) authentication :操作系统认证 --以下情况使用该方法： 管理远程数据库时，具有安全的网络连接（secure connection）。 管理本地数据库时，想使用OS认证。 --操作步骤： a.建立一个os系统用户 b.将这个用户加入到OSDBA或者OSOPER的OS组。 c.设置参数REMOTE_LOGIN_PASSWORDFILE=NONE d.CONNECT / AS SYSDBA --关于OSDBA和OSOPER组 OSDBA对应: UNIX为dba; WINDOWS为ORA_DBA OSOPER对应:UNIX为oper; WINDOWS为ORA_OPER 这些用户组在安装数据库的时候手工或者自动创建，这些组的成员以 as sysdba/sysoper 连接数据库后，自动授予sysdba/sysoper的管理权限。 2) Password files ：密码文件认证 --以下情况使用该方法： 管理远程数据库时，没有安全的网络连接（secure connection），比如TCP/IP和DECnet协议。 管理本地数据库时，不想使用OS认证。 --操作步骤： a.使用ORAPWD创建密码文件(其中的password选项是为SYS用户设置的) b.设置参数REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE c.使用sys用户登陆 d.在数据库中创建用户 create user donny1 identified by donny1; e. 赋予其SYSDBA/SYSOPER权限 　　grant sysdba to donny1; 这样就将用户和密码加入到密码文件中。 f.使用自己的密码logon: connect donny1/donny1 as sysdba; g.OS认证优先于密码文件认证： 只要OS用户属于OSDBA OR OROPER组，并且使用connect as sysdba / sysoper登录,则可以忽略输入的username/password. ３、 关于REMOTE_LOGIN_ PASSWORDFILE None: 使得oracle不使用密码文件，只能使用OS认证，不允许通过不安全网络进行远程管理。 Exclusive: 可以使用唯一的密码文件，但只限一个instance 。密码文件中可以包括除了sys用户的其他用户。 Shared: 可以在多个数据库上使用共享的密码文件。但是密码文件中只能包含sys用户。通常用于一个dba管理多个数据库的时候。 ４、 V$PWFILE_USERS 使用该视图查看密码文件中的member ５、 非管理员级别用户的OS认证方法： 关键字： os_authent_prefix=ops$ 注意：如果用户名为donny.chen，需要用引号。这个时候要用大写"OPS$DONNY.CHEN"，否则可以 SQL> create user ops$oracle identified externally 2 default tablespace users; conn / winnt下面需要注意的就是在HKEY_LOCAL_MACHINE/SOFTWARE/ORACLE/HOME0/OSAUTH_PREFIX_DOMAIN项。如果为没有或者为true，表示建用户时需要这样"OPS$主机名用户名"。 所以通常将OSAUTH_PREFIX_DOMAIN改称false

表碎片起因及解决办法
跟表碎片有关的基础知识：
什么是水线(High Water Mark)?
----------------------------
所有的oracle段(segments，在此，为了理解方便，建议把segment作为表的一个同义词) 都有一个在段内容纳数据的上限，我们把这个上限称为"high water mark"或HWM。这个HWM是一个标记，用来说明已经有多少没有使用的数据块分配给这个segment。HWM通常增长的幅度为一次5个数据块，原则上HWM只会增大，不会缩小，即使将表中的数据全部删除，HWM还是为原值，由于这个特点，使HWM很象一个水库的历史最高水位，这也就是HWM的原始含义，当然不能说一个水库没水了，就说该水库的历史最高水位为0。但是如果我们在表上使用了truncate命令，则该表的HWM会被重新置为0。

HWM数据库的操作有如下影响：
a) 全表扫描通常要读出直到HWM标记的所有的属于该表数据库块，即使该表中没有任何数据。
b) 即使HWM以下有空闲的数据库块，键入在插入数据时使用了append关键字，则在插入时使用HWM以上的数据块，此时HWM会自动增大。

如何知道一个表的HWM？
a) 首先对表进行分析:
ANALYZE TABLE ESTIMATE/COMPUTE STATISTICS;
b) SELECT blocks, empty_blocks, num_rows
FROM user_tables
WHERE table_name = ;

BLOCKS 列代表该表中曾经使用过得数据库块的数目，即水线。
EMPTY_BLOCKS 代表分配给该表，但是在水线以上的数据库块，即从来没有使用的数据块。

让我们以一个有28672行的BIG_EMP1表为例进行说明：
1) SQL> SELECT segment_name,segment_type,blocks
FROM dba_segments
WHERE segment_name='BIG_EMP1';
SEGMENT_NAME SEGMENT_TYPE BLOCKS EXTENTS
----------------------------- ----------------- ---------- -------
BIG_EMP1 TABLE 1024 2
1 row selected.

2) SQL> ANALYZE TABLE big_emp1 ESTIMATE STATISTICS;
Statement processed.

3) SQL> SELECT table_name,num_rows,blocks,empty_blocks
FROM user_tables
WHERE table_name='BIG_EMP1';
TABLE_NAME NUM_ROWS BLOCKS EMPTY_BLOCKS
------------------------------ ---------- ---------- ------------
BIG_EMP1 28672 700 323
1 row selected.

注意：
BLOCKS + EMPTY_BLOCKS (700+323=1023)比DBA_SEGMENTS.BLOCKS少个数据库块，这是因为有一个数据库块被保留用作segment header。DBA_SEGMENTS.BLOCKS 表示分配给这个表的所有的数据库块的数目。USER_TABLES.BLOCKS表示已经使用过的数据库块的数目。

4) SQL> SELECT COUNT (DISTINCT
DBMS_ROWID.ROWID_BLOCK_NUMBER(rowid)||
DBMS_ROWID.ROWID_RELATIVE_FNO(rowid)) "Used"
FROM big_emp1;
Used
----------
700
1 row selected.

5) SQL> DELETE from big_emp1;
28672 rows processed.

6) SQL> commit;
Statement processed.

7) SQL> ANALYZE TABLE big_emp1 ESTIMATE STATISTICS;
Statement processed.

8) SQL> SELECT table_name,num_rows,blocks,empty_blocks
FROM user_tables
WHERE table_name='BIG_EMP1';
TABLE_NAME NUM_ROWS BLOCKS EMPTY_BLOCKS
------------------------------ ---------- ---------- ------------
BIG_EMP1 0 700 323
1 row selected.

9) SQL> SELECT COUNT (DISTINCT
DBMS_ROWID.ROWID_BLOCK_NUMBER(rowid)||
DBMS_ROWID.ROWID_RELATIVE_FNO(rowid)) "Used"
FROM big_emp1;
Used
----------
0 -- 这表名没有任何数据库块容纳数据，即表中无数据
1 row selected.

10) SQL> TRUNCATE TABLE big_emp1;
Statement processed.

11) SQL> ANALYZE TABLE big_emp1 ESTIMATE STATISTICS;
Statement processed.

12) SQL> SELECT table_name,num_rows,blocks,empty_blocks
2> FROM user_tables
3> WHERE table_name='BIG_EMP1';
TABLE_NAME NUM_ROWS BLOCKS EMPTY_BLOCKS
------------------------------ ---------- ---------- ------------
BIG_EMP1 0 0 511
1 row selected.

13) SQL> SELECT segment_name,segment_type,blocks
FROM dba_segments
WHERE segment_name='BIG_EMP1';
SEGMENT_NAME SEGMENT_TYPE BLOCKS EXTENTS
----------------------------- ----------------- ---------- -------
BIG_EMP1 TABLE 512 1
1 row selected.

注意:
TRUNCATE命令回收了由delete命令产生的空闲空间，注意该表分配的空间由原先的1024块降为512块。
为了保留由delete命令产生的空闲空间，可以使用
TRUNCATE TABLE big_emp1 REUSE STORAGE
用此命令后，该表还会是原先的1024块。

行链接(Row chaining) 与行迁移(Row Migration)当一行的数据过长而不能插入一个单个数据块中时，可能发生两种事情：行链接(row chaining)或行迁移(row migration)。

行链接
当第一次插入行时，由于行太长而不能容纳在一个数据块中时，就会发生行链接。在这种情况下，oracle会使用与该块链接的一块或多块数据块来容纳该行的数据。行连接经常在插入比较大的行时才会发生，如包含long, long row, lob等类型的数据。在这些情况下行链接是不可避免的。

行迁移
当修改不是行链接的行时，当修改后的行长度大于修改前的行长度，并且该数据块中的空闲空间已经比较小而不能完全容纳该行的数据时，就会发生行迁移。在这种情况下，Oracle会将整行的数据迁移到一个新的数据块上，而将该行原先的空间只放一个指针，指向该行的新的位置，并且该行原先空间的剩余空间不再被数据库使用，这些剩余的空间我们将其称之为空洞，这就是产生表碎片的主要原因，表碎片基本上也是不可避免的，但是我们可以将其降到一个我们可以接受的程度。注意，即使发生了行迁移，发生了行迁移的行的rowid 还是不会变化，这也是行迁移会引起数据库I/O性能降低的原因。其实行迁移是行链接的一种特殊形式，但是它的起因与行为跟行链接有很大不同，所以一般把它从行链接中独立出来，单独进行处理。

行链接和行迁移引起数据库性能下降的原因：
引起性能下降的原因主要是由于引起多余的I/O造成的。当通过索引访问已有行迁移现象的行时，数据库必须扫描一个以上的数据块才能检索到改行的数据。这主要有一下两种表现形式：
1) 导致row migration 或row chaining INSERT 或 UPDATE语句的性能比较差，因为它们需要执行额外的处理
2) 利用索引查询已经链接或迁移的行的select语句性能比较差，因为它们要执行额外的I/O

如何才能检测到行迁移与行链接：
在表中被迁移或被链接的行可以通过带list chained rows选项的analyze语句识别出来。这个命令收集每个被迁移或链接的行的信息，并将这些信息放到指定的输出表中。为了创建这个输出表，运行脚本UTLCHAIN.SQL。

SQL> ANALYZE TABLE scott.emp LIST CHAINED ROWS;
SQL> SELECT * FROM chained_rows;

当然你也可以通过检查v$sysstat视图中的'table fetch continued row'来检查被迁移或被链接的行。

SQL> SELECT name, value FROM v$sysstat WHERE name = 'table fetch continued row';
NAME VALUE
---------------------------------------------------------------- ---------
table fetch continued row 308

尽管行迁移与行链接是两个不同的事情，但是在oracle内部，它们被当作一回事。所以当你检测行迁移与行链接时，你应该仔细的分析当前你正在处理的是行迁移还是行链接。

解决办法
o 在大多数情况下，行链接是无法克服的，特别是在一个表包含象LONGS, LOBs 等这样的列时。当在不同的表中有大量的链接行，并且哪些表的行的长度不是很长时，你可以通过用更大的block size重建数据库的方法来解决它。

例如：当前你的数据库的数据块的大小为4K，但是你的行的平均长度为6k，那么你可以通过用8k大小的数据块来重建数据库的办法解决行链接现象。

o 行迁移主要是由于设置的PCTFREE参数过小，导致没有给update操作留下足够的空闲空间引起。为了避免行迁移，所有被修改的表应该设置合适的PCTFREE 值，以便在每个数据块内为数据修改保留足够的空间。可以通过增加PCTFREE值的办法来避免行迁移，但这种解决办法是以牺牲更多的空间为代价的，这也就是我们通常所说的以空间换效率。 而且通过增加PCTFREE值的办法只能缓解行迁移现象，而不能完全解决行迁移，所以较好的办法是在设置了合适的PCTFREE值的后，在发现行迁移现象比较严重时，对表的数据进行重组。
下面是对行迁移数据进行重组的步骤(这种方法也被成为CTAS):
-- Get the name of the table with migrated rows:
ACCEPT table_name PROMPT 'Enter the name of the table with migrated rows: '

-- Clean up from last execution
set echo off
DROP TABLE migrated_rows;
DROP TABLE chained_rows;

-- Create the CHAINED_ROWS table
@.../rdbms/admin/utlchain.sql
set echo on
spool fix_mig
-- List the chained and migrated rows
ANALYZE TABLE &table_name LIST CHAINED ROWS;

-- Copy the chained/migrated rows to another table
create table migrated_rows as
SELECT orig.*
FROM &table_name orig, chained_rows cr
WHERE orig.rowid = cr.head_rowid
AND cr.table_name = upper('&table_name');

-- Delete the chained/migrated rows from the original table
DELETE FROM &table_name WHERE rowid IN (SELECT head_rowid FROM chained_rows);

-- Copy the chained/migrated rows back into the original table
INSERT INTO &table_name SELECT * FROM migrated_rows;

spool off

当对一个表进行全表扫描时，我们实际上忽略行迁移中各个指向其它行的指针，因为我们知道，全表扫描会遍历全表，最终会读到发生行迁移的行的行数据，在此时才会处理这些行数据。因此，在全表扫描中，行迁移不会引发其它额外的工作。
当通过索引读一个表的数据时，被迁移的行会引起额外的I/O操作。这是因为从所引中我们会读到数据行的rowid，它告诉数据库到指定文件的指定数据块的指定slot上可以找到需要的数据，但是因为发生了行迁移，此处只存放一个指向数据的指针，而不是真正的数据，所以数据库又需要根据该指针(类似rowid)到指定文件的指定数据块的指定slot上去找真正的数据，重复上面的过程，知道找到真正的数据。我们可以看出，这会引入额外的I/O操作。

发现又严重表碎片的表的步骤：表需要整理原因有2:
a) 有太多的migration rows
b) 表经过删除数据后有大量的空块, 而全表扫描时，仍需要读这些空块

发现需要reorganization的表，需要从表的实际使用的空间与表的hwm入手

首先分析表：
Alter table emp compute statistics.

然后可以查询出有数据的数据块的个数:
For ORACLE 7:
SELECT COUNT(DISTINCT SUBSTR(rowid,15,4)||
SUBSTR(rowid,1,8)) "Used"
FROM schema.table;

For ORACLE 8+:
SELECT COUNT (DISTINCT
DBMS_ROWID.ROWID_BLOCK_NUMBER(rowid)||
DBMS_ROWID.ROWID_RELATIVE_FNO(rowid)) "Used"
FROM schema.table;
or
SELECT COUNT (DISTINCT SUBSTR(rowid,1,15)) "Used"
FROM schema.table;

查询出HWM以下的数据块的个数(可能由于delete, 数据块中并不包含数据):
This will update the table statistics. After generating the statistics, to determine the high water mark:
SELECT blocks, empty_blocks, num_rows
FROM user_tables
WHERE table_name = ;

下面给出一个综合的sql语句，它可以查询出浪费空间的表(浪费超过25%)，而且还计算出其它信息(使用时根据具体情况修改where子句中的blocks，owner限制条件)：
SELECT OWNER, SEGMENT_NAME TABLE_NAME, SEGMENT_TYPE,
GREATEST(ROUND(100 * (NVL(HWM - AVG_USED_BLOCKS,0)/GREATEST(NVL(HWM,1),1) ), 2), 0) WASTE_PER,
ROUND(BYTES/1024, 2) TABLE_KB, NUM_ROWS,
BLOCKS, EMPTY_BLOCKS, HWM HIGHWATER_MARK, AVG_USED_BLOCKS,
CHAIN_PER, EXTENTS, MAX_EXTENTS, ALLO_EXTENT_PER,
DECODE(GREATEST(MAX_FREE_SPACE - NEXT_EXTENT, 0), 0,'N','Y') CAN_EXTEND_SPACE,
NEXT_EXTENT, MAX_FREE_SPACE,
O_TABLESPACE_NAME TABLESPACE_NAME
FROM
(SELECT A.OWNER OWNER, A.SEGMENT_NAME, A.SEGMENT_TYPE, A.BYTES,
B.NUM_ROWS, A.BLOCKS BLOCKS, B.EMPTY_BLOCKS EMPTY_BLOCKS,
A.BLOCKS - B.EMPTY_BLOCKS - 1 HWM,
DECODE( ROUND((B.AVG_ROW_LEN * NUM_ROWS * (1 + (PCT_FREE/100)))/C.BLOCKSIZE, 0),
0, 1,
ROUND((B.AVG_ROW_LEN * NUM_ROWS * (1 + (PCT_FREE/100)))/C.BLOCKSIZE, 0)
) + 2 AVG_USED_BLOCKS,
ROUND(100 * (NVL(B.CHAIN_CNT, 0)/GREATEST(NVL(B.NUM_ROWS, 1), 1)), 2) CHAIN_PER,
ROUND(100 * (A.EXTENTS/A.MAX_EXTENTS), 2) ALLO_EXTENT_PER,A.EXTENTS EXTENTS,
A.MAX_EXTENTS MAX_EXTENTS, B.NEXT_EXTENT NEXT_EXTENT, B.TABLESPACE_NAME O_TABLESPACE_NAME
FROM SYS.DBA_SEGMENTS A,
SYS.DBA_TABLES B,
SYS.TS$ C
WHERE A.OWNER =B.OWNER and
SEGMENT_NAME = TABLE_NAME and
SEGMENT_TYPE = 'TABLE' AND
B.TABLESPACE_NAME = C.NAME
UNION ALL
SELECT A.OWNER OWNER, SEGMENT_NAME || '.' || B.PARTITION_NAME, SEGMENT_TYPE, BYTES,
B.NUM_ROWS, A.BLOCKS BLOCKS, B.EMPTY_BLOCKS EMPTY_BLOCKS,
A.BLOCKS - B.EMPTY_BLOCKS - 1 HWM,
DECODE( ROUND((B.AVG_ROW_LEN * B.NUM_ROWS * (1 + (B.PCT_FREE/100)))/C.BLOCKSIZE, 0),
0, 1,
ROUND((B.AVG_ROW_LEN * B.NUM_ROWS * (1 + (B.PCT_FREE/100)))/C.BLOCKSIZE, 0)
) + 2 AVG_USED_BLOCKS,
ROUND(100 * (NVL(B.CHAIN_CNT,0)/GREATEST(NVL(B.NUM_ROWS, 1), 1)), 2) CHAIN_PER,
ROUND(100 * (A.EXTENTS/A.MAX_EXTENTS), 2) ALLO_EXTENT_PER, A.EXTENTS EXTENTS,
A.MAX_EXTENTS MAX_EXTENTS, B.NEXT_EXTENT,
B.TABLESPACE_NAME O_TABLESPACE_NAME
FROM SYS.DBA_SEGMENTS A,
SYS.DBA_TAB_PARTITIONS B,
SYS.TS$ C,
SYS.DBA_TABLES D
WHERE A.OWNER = B.TABLE_OWNER and
SEGMENT_NAME = B.TABLE_NAME and
SEGMENT_TYPE = 'TABLE PARTITION' AND
B.TABLESPACE_NAME = C.NAME AND
D.OWNER = B.TABLE_OWNER AND
D.TABLE_NAME = B.TABLE_NAME AND
A.PARTITION_NAME = B.PARTITION_NAME),
(SELECT TABLESPACE_NAME F_TABLESPACE_NAME,MAX(BYTES)
MAX_FREE_SPACE
FROM SYS.DBA_FREE_SPACE
GROUP BY TABLESPACE_NAME)
WHERE F_TABLESPACE_NAME = O_TABLESPACE_NAME AND
GREATEST(ROUND(100 * (NVL(HWM - AVG_USED_BLOCKS, 0)/GREATEST(NVL(HWM, 1), 1) ), 2), 0) > 25
AND OWNER = '??' AND BLOCKS > 128
ORDER BY 10 DESC, 1 ASC, 2 ASC;

各列的说明：
WASTE_PER：已分配空间中水线以下的空闲空间(即浪费空间)的百分比。
TABLE_KB：该表目前已经分配的所有空间的大小，以k为单位。
NUM_ROWS：在在表中数据的行数
BLOCKS：该表目前已经分配的数据块的块数，包含水线以上的部分
EMPTY_BLOCKS：已分配空间中水线以上的空闲空间
HIGHWATER_MARK：目前的水线
AVG_USED_BLOCKS：理想情况下(没有行迁移)，该表数据应该占用的数据块的个数
CHAIN_PER：发生行迁移现象的行占总行的比率
EXTENTS：该表目前已经分配的extent数
MAX_EXTENTS：该表可以分配的最大extent的个数
ALLO_EXTENT_PER：目前已分配的extent的个数占可以分配最大extent的比率
CAN_EXTEND_SPACE：是否可以分配下一个extent
NEXT_EXTENT：下一个extent的大小
MAX_FREE_SPACE：表的已分配空间中最大的空闲空间

一点整理的statspack内容信息
Instance Efficiency Percentages

Data Buffer Hit Ratio#<#90#数据块在数据缓冲区中的命中率，通常应该在90%以上，否则考虑加大 db_block_buffers(9i 以上可是db_cache_size)
Buffer Nowait Ratio#<#99#在缓冲区中获取buffer 的未等待比率
Library Hit Ratio#<#98#主要代表着sql在共享区的命中率，通常在98%以上
In Memory Sort Ratio#<#0#如果过低说明有大量的排序在临时表空间中进行，可尝试增加sort_area_size
Redo Nowait Ratio#<#98#写日志的不等待比率,太低可调整log_buffer(增加)和 _log_io_size(减小，默认为1/3*log_buffer/log_block_size,使得 _log_io_size 为合适的值，比如128k/log_block_size)
Soft Parse Ratio#<#90#近似当作sql在共享区的命中率，通常高代表使用了绑定变量,太低需要调整应用使用绑定变量，或者参考 cursor_sharing = force (9i 中增加了 similar )
Latch Hit Ratio#<#99#内部结构维护锁命中率，高于99%,通常低是因为shared_pool_size过大和没有使用绑定变量导致硬解析过多，可参考 _spin_count 参数设置
Percent Non-Parse CPU#<#95#查询实际运行时间/(查询实际运行时间+sql解析时间)，太低表示解析消耗时间过长
Percent Parse CPU to Parse Elapsed#<#90#解析实际所用时间/(解析实际所用时间+解析中等待资源时间),越高越好
Execute to Parse Percent#<#10#该值越高表示一次解析后被重复执行的次数越多，如果过低可以考虑设置 session_cached_cursors > 0
Memory Usage Percent#<#75#共享池的使用率，应该稳定在75%--90%之间，太小浪费内存，太大则显内存不足
Percent of SQLs with Execution>1#<#40#执行次数大于1的sql的比率（若太小可能是没有使用绑定变量）
Percent of Memory for SQl with Execution>1#<#0#执行次数大于1的sql消耗内存/(所有sql消耗内存)

Instance Load Profile

Redo Size/Sec#>#100000#每秒产生的日志大小（单位字节），可标志数据库任务的繁重与否
Redo Size/Tx#>#0#平均每个事务的日志生成量
Logical Reads/Sec(逻辑读)#>#0#平均每秒产生的逻辑读,单位是block
Logical Reads/Tx#>#0#平均每个事务产生的逻辑读,单位是block
Block Changes/Sec#>#100#每秒block变化数量，数据库事务带来改变的块数量
Block Changes/Tx#>#0#平均每个事务所导致的改变的块数
Physical Reads/Sec#>#100#平均每秒数据库从磁盘读取的block数
Physical Reads/Tx#>#0#平均每个事务从磁盘读取的block数
Physical Write/Sec#>#50#平均每秒写磁盘的block数
Physical Write/Tx#>#0#平均每个事务写磁盘的block数
User Calls/Sec#>#0#每秒用户call次数
User Calls/Tx#>#0#每事务用户call次数
Parses/Sec#>#100#每秒解析次数，近似反应了每秒语句的执行次数
Parses/Tx#>#0#每事务产生的解析次数
Hard Parses/Sec#>#10#每秒产生的硬解析次数
Hard Parses/Tx#>#0#每事务产生的硬解析次数
Sorts/Sec#>#20#每秒产生的排序次数
Sorts/Tx#>#5#每事务产生的排序次数
Transactions/Sec#>#0#每秒产生的事务数
Rows/Sort#>#0#每次排序所涉及到的行数
Percent of Block Changed/Read#>#0#发生变化的块数/读次数，变化的块需要从回滚段来数据
Recursive Call Percent#>#0#递归操作占所有操作的比率
Rollback/Tx Percent#>#5#事务回滚率（回滚开销很大）
Executes/Sec#>#0#每秒执行次数
Execute/Tx#>#0#每个事务执行次数
--45: Logons/Sec
--46: Logons/Tx

I/O Statistics(I/O统计数据)

Table Space I/O#>#0#表示各表空间在IO上的分布，若出现严重不均衡，则要重新考虑对象的存储规划和表空间中数据文件的磁盘规划
Datafile I/O#>#0#表示各数据文件的IO分布，若不均衡则需要重新考虑对象的存储规划
Table I/O（表I/O）#>#0#对这些IO很大的表，要考虑放置在高速磁盘上，并且尽可能的分布在不同的磁盘上

TOP SQL

Top SQL with High Buffer Gets#>#0#这类sql进行了大量的block的读，要检查该sql是否用到了索引，或者说表上是否存在合理的索引，对于必须全表扫描的大表可以考虑recycle buffer ,对于频繁进行全表扫描的小表可以考虑keep buffer，还有一种需要注意的情况就是如果通过索引获取数据比例占表数据比例过大，比如20%(举例数据)，就能导致buffer gets过大
Top SQL with High Physical Reads#>#0#这类sql导致了大量的从磁盘获取数据，可能因为数据缓冲区太小，也可能是过多的全表扫描，需要考察索引是否合理，是否用到索引
Top SQL with High Execution Count#>#0#这类sql是需要重点关注的，也许这些sql本身一次执行并没有消耗大量的时间或者空间，但由于频繁的执行对系统影响极大，所以只要有优化的可能到要对这些sql进行优化。还有另外一些情况，就是某些程序中可能大量频繁地使用dual表来获取一些信息(比如时间的计算等)，尽可能的使这类sql转化为应用本地能解决的函数，或者还存在一些由于设计上的缺陷导致不必要的查询，都要在设计的角度避免这些查询
Top SQL with High Shared Memory#>#0#这类sql使用了大量的内存，不一定执行的频繁，但是它可能把执行的频繁的sql涉及的一些数据挤出缓冲区，这同样将导致很多问题，所以也需要从尽可能的优化
Top SQL with High Version Count#>#20#表示多个用户的sql在字面上是一样的，或者sql虽然一样但是session的一些参数发生了改变（比如sort_area_size发生了变化）

Wait Events(等待事件)

alter system set mts_dispatcher#>#0#当会话决定执行"ALTER SYSTEM SET MTS_DISPATCHERS = <string> "的时候等待DISPATCHERS的启动
BFILE check if exists#>#0#检查外部的bfile文件是否存在
BFILE check if open#>#0#检查外部的bfile文件是否已经open
BFILE closure#>#0#等待关闭外部bfile文件
BFILE get length#>#0#获得外部bfile文件的大小
BFILE get name object#>#0#得到外部bfile文件的名字
BFILE get path object#>#0#得到外部bfile文件的路径
BFILE internal seek#>#0#
BFILE open#>#0#等待外部bfile被打开
BFILE read#>#0#等待外部bfile文件读取完毕
buffer busy due to global cache#>#0#
buffer busy waits#>#0#block正被读入缓冲区或者缓冲区正被其他session使用,出现此情况通常可能通过几种方式调整：增大data buffer,增加freelist，减小pctused,增加回滚段数目，增大initrans,考虑使用LMT
buffer deadlock#>#0#由于系统缓慢所产生而非应用产生了死锁
buffer latch#>#0#会话等待'buffer hash chain latch'
buffer read retry#>#0#OPS下读buffer的过程中内容发生了变化于是重新读取
Cache simulator heap#>#0#
checkpoint completed#>#0#等待检查点的完成，通常出现这个问题的原因是IO问题严重，可调整跟检查点相关参数log_checkpoint_interval,log_checkpoint_timeout,db_block_max_dirty_target,fast_start_io_target 等，可间接的增大日志文件大小和增加日志文件组数
Contacting SCN server or SCN lock master#>#0#
control file parallel write#>#0#等待写所有控制文件的完成，可将控制文件分散在不同的磁盘上
control file sequential read#>#0#读控制文件，在备份控制文件、OPS等情况下产生
control file single write#>#0#OPS下同一时刻只允许一个session将共享信息写入磁盘
conversion file read#>#0#
db file parallel read#>#0#做恢复的并行从数据文件获取数据
db file parallel write#>#0#当多个IO可以同时发生时(多磁盘)，DBWR可并行写入，DBWR等待最后一个IO的完成
db file scattered read#>#0#一次获取的block被分散在buffer的不连续空间中，通常表示全表扫描过多，可检查应用程序是否合理的使用了索引，数据库是否合理的创建了索引
db file sequential read#>#0#通常暗示着通过索引获取数据量比较大（比如通过索引进行范围扫描获取表数据百分比过大），多表连接的时候连接顺序不当，hash join时hash_area_size无法容纳hash table
db file single write#>#0#更新数据文件头出现等待
debugger command#>#0#
DFS db file lock#>#0#OPS下每个实例在数据文件上有一个共享的全局锁，当要offline数据文件的时候等候其他实例同步文件
DFS lock handle#>#0#会话等待一个全局锁请求
direct path read#>#0#通常发生在临时表空间排序、并行查询中
direct path read (lob) #>#0#
direct path write#>#0#direct方式导入数据(sqlldr,CTAS)、PDML、临时表空间排序
direct path write (lob)#>#0#
dispatcher listen timer#>#0#
dispatcher shutdown#>#0#
dispatcher timer#>#0#
DLM generic wait event#>#0#
dupl. cluster key#>#0#
enqueue#>#0#对共享资源的获取要求一种排队(FIFO)的机制以保护共享资源，ST enqueue表示空间分配或者释放导致的问题可采用LMT表空间来避免，TX enqueue主要产生于唯一索引重复、bitmap index 的频繁更新、initrans太小或者pctfree过小
file identify#>#0#
file open#>#0#
free buffer waits#>#0#在缓冲区中寻找可用buffer出现等待，可能数据缓冲区太小，也可能检查点间隔太长，也可能频繁的DML而IO成为瓶颈
free global transaction table entry#>#0#分布式数据库中会话等待一个全局事务槽
free process state object#>#0#
global cache bg acks#>#0#
global cache cr request#>#0#
global cache freelist wait#>#0#
global cache lock busy#>#0#会话等待将一个buffer从当前共享状态转换为当前独占状态
global cache lock cleanup#>#0#
global cache lock null to s#>#0#
global cache lock null to x#>#0#
global cache lock open s#>#0#
global cache lock open x#>#0#
global cache lock s to x#>#0#
global cache multiple locks#>#0#
global cache pending ast#>#0#
global cache pending asts#>#0#
global cache retry prepare#>#0#
global cache retry request#>#0#
imm op#>#0#
inactive session#>#0#
inactive transaction branch#>#0#
index block split#>#0#当在索引中查找一个key的时候如果发现该索引block正在裂变则等待裂变完成
io done#>#0#会话等待IO的完成
KSIM GDS request cancel#>#0#
latch activity#>#0#
latch free#>#0#latch是一种维护内存的锁，不采用排队机制，快速的获取然后很快释放，造成的原因通常有程序没有使用绑定变量、shared_pool_size设置过大（比如1G）、LRU竞争、某些块过热（访问太频繁）
LGWR wait for redo copy#>#0#表示等待redo allocation and redo copy latches,可增加 _log_simulteneous_copies(默认为 2*CPUs)，但同时也容易引入redo allocation latch contention,所以需要慎重
library cache load lock#>#0#
library cache lock#>#0#
library cache pin#>#0#
listen endpoint status#>#0#
LMON wait for LMD to inherit communication channels#>#0#
local write wait#>#0#
lock manager wait for dlmd to shutdown#>#0#
lock manager wait for remote message#>#0#
log buffer space#>#0#生成日志等待lgwr赶快写文件而腾出log buffer,可在init参数文件中增大 log_buffer,放置日志文件于高速磁盘上
log file parallel write#>#0#当lgwr写日志文件的过程中出现等待，这个等待通常会导致 log file sync事件,放置日志文件于高速磁盘上
log file sequential read#>#0#
log file single write#>#0#
log file switch (archiving needed)#>#0#当日志切换的时候由于日志组循环使用了一圈但日志归档还没有完成，通常是io有严重问题，可增大日志文件和增加日志组，调整log_archive_max_processes
log file switch (checkpoint incomplete)#>#0#当日志切换的时候由于日志组循环使用了一圈但将被使用的日志组中的checkpoint还没有完成造成，通常是io有严重问题，可增大日志文件和增加日志组
log file switch (clearing log file)#>#0#
log file switch completion#>#0#
log file sync#>#0#当用户commit的时候通知lgwr写日志但lwgr正忙，造成的可能原因是commit太频繁或者lgwr一次写日志时间太长（可能是因为一次log io size 太大），可调整 _log_io_size，结合log_buffer,使得 (_log_io_size*db_block_size)*n = log_buffer,这样可避免和增大log_buffer引起冲突;放置日志文件于高速磁盘上

write complete waits#>#0#用户等候buffer被写进文件，暗示着写数据文件等待

一个关于ORACLE性能优化的好贴
ORACLE 8.0.X 版本

SGA=((db_block_buffers * block size)+(shared_pool_size+large_pool_size+log_buffers)+1MB

ORACLE 8.1.X 版本

SGA=((db_block_buffers * block size)+(shared_pool_size+large_pool_size+java_pool_size+log_buffers)+1MB

理论上SGA可占OS系统物理内存的1/2——1/3，我们可以根据需求调整

我推荐SGA=0.45*(OS RAM)

假设服务器运行ORACLE 8.1.X 版本, OS系统内存为2G MEM, db_block_size 是8192 bytes,
除了运行ORACLE数据库外, 没有其它的应用程序或服务器软件.

这样SGA合计约为921M ( 0.45*2048M ),

设shared_pool_size 300M (300*1024*1024 bytes)

设database buffer cache 570M (72960*8192 bytes)

initorasid.ora文件里具体各参数如下:

shared_pool_size = 314572800
# 300 M

db_block_buffers = 72960
# 570 M

log_buffer = 524288
# 512k (128K*CPU个数)

large_pool_size = 31457280
# 30 M

java_pool_size = 20971520
# 20 M

sort_area_size = 524288
# 512k (65k--2M)

sort_area_retained_size = 524288
# MTS 时 sort_area_retained_size = sort_area_size

SUN Solaris里/etc/system文件里的几个参数同样跟内存分配有关

ORACLE安装时缺省的设置: 建议修改的设置:
set shmsys:shminfo_shmmax=4294967295
set shmsys:shminfo_shmmin=1
set shmsys:shminfo_shmmni=100
set shmsys:shminfo_shmseg=15
set semsys:seminfo_semmns=200
set semsys:seminfo_semmni=70
set ulimit=3000000
set semsys:seminfo_semmni=315
set semsys:seminfo_semmsl=300
set semsys:seminfo_semmns=630
set semsys:seminfo_semopm=315
set semsys:seminfo_semvmx=32767
set shmsys:shminfo_shmmax=4294967295
set shmsys:shminfo_shmmni=315
set shmsys:shminfo_shmseg=10
set shmsys:shminfo_shmmin=1

其中这些参数的含义

shmmax - 共享内存段，建议设大点， 达到最大SGA
shmmin - 最小的共享内存段.
shmmni - 共享内存标志符的数量.
shmseg - 一个进程可分配的最大内存段数.
shmall - 最大可允许的内存数，比SGA还要大.
semmns - 信号灯，跟ORACLE的PROCESS数有关.
semmsl - 一个信号灯中最大的信号灯数.

Oracle9i初始化参数中文说明
转自 聚贤庄（http://www.ncn.cn） 作者：zzyy
=======================================
Blank_trimming:

说明: 如果值为TRUE, 即使源长度比目标长度 (SQL92 兼容) 更长, 也允许分配数据。

值范围: TRUE | FALSE

默认值: FALSE

serializable:

说明: 确定查询是否获取表级的读取锁, 以防止在包含该查询的事务处理被提交之前更新任何对象读取。这种操作模式提供可重复的读取,

并确保在同一事务处理种对相同数据的两次查询看到的是相同的值。

值范围: TRUE | FALSE

默认值: FALSE

row_locking:

说明: 指定在表已更新或正在更新时是否获取行锁。如果设置为 ALWAYS, 只有在表被更新后才获取行锁。如果设置为 INTENT,

只有行锁将用于

SELECT

FOR

UPDATE, 但在更新时将获取表锁。

值范围: ALWAYS | DEFAULT | INTENT

默认值: ALWAYS

shared_servers

说明 : 指定在启动例程后, 要为共享服务器环境创建的服务器进程的数量。

值范围: 根据操作系统而定。

默认值 : 1

circuits:

说明 : 指定可用于入站和出站网络会话的虚拟电路总数。 该参数是构成某个例程的总 SGA 要求的若干参数之一。

默认值 : 派生: SESSIONS 参数的值 (如果正在使用共享服务器体系结构); 否则为 0。

Mts_multiple_listeners:

说明: 指定多个监听程序的地址是分别指定的, 还是用一个 ADDRESS_LIST 字符串指定。如果该值为 TRUE,

MTS_LISTENER_ADDRESS 参数可被指定为:

(ADDRESS_LIST=(ADDRESS=(PROTOCOL=tcp)(PORT=5000)(HOST=zeus))

(ADDRESS=(PROTOCOL=decnet)(OBJECT=outa)(NODE=zeus))

此参数在 8.1.3 版中已废弃。

值范围: TRUE | FALSE

默认值: FALSE

mts_servers:

说明 : 指定在启动例程后, 要为共享服务器环境创建的服务器进程的数量。

值范围: 根据操作系统而定。

默认值 : 1

mts_service:

说明 : 一个共享服务器参数, 用于指定已在调度程序上注册,

用来建立数据库连接的唯一服务名。如果要在没有调度程序的情况下仍能连接到数据库, 请将该值设置为与例程名相同。此参数自

8.1.3 版起已废弃。

值范围: 根据操作系统而定。

默认值 :0

mts_sessions:

说明 : 指定允许的共享服务器体系结构用户会话的总数。设置此参数可为专用服务器保留一些用户会话。

值范围: 0 到 SESSIONS - 5

默认值 : 派生: MTS_CIRCUITS 和 SESSIONS - 5 两者中的较小值

shared_server_sessions:

说明 : 指定允许的共享服务器体系结构用户会话的总数。设置此参数可为专用服务器保留一些用户会话。

值范围: 0 到 SESSIONS - 5

默认值 : 派生: MTS_CIRCUITS 和 SESSIONS - 5 两者中的较小值

mts_max_dispatchers

说明 : 指定在一个共享服务器环境中可同时运行的调度程序进程的最大数量。

值范围: 根据操作系统而定。

默认值 : 如果已配置了调度程序, 则默认值为大于 5 的任何数目或配置的调度程序的数目

mts_max_servers:

说明 : 指定在一个共享服务器环境中可同时运行的共享服务器进程的最大数量。

值范围: 根据操作系统而定。

默认值 : 20

dispatchers:

说明 : 为设置使用共享服务器的共享环境而设置调度程序的数量和类型。可以为该参数指定几个选项。有关详细信息,

请参阅“Oracle8i 管理员指南”和“Oracle Net Administrator's

Guide”。这是字符串值的一个示例: '(PROTOCOL=TCP)(DISPATCHERS=3)'。

值范围: 参数的有效指定值。

默认值 : NULL

max_shared_servers:

说明 : 指定在一个共享服务器环境中可同时运行的共享服务器进程的最大数量。

值范围: 根据操作系统而定。

默认值 : 20

mts_circuits:

说明 : 指定可用于入站和出站网络会话的虚拟电路总数。 该参数是构成某个例程的总 SGA 要求的若干参数之一。

默认值 : 派生: SESSIONS 参数的值 (如果正在使用共享服务器体系结构); 否则为 0。

Mts_listener_address:

说明 : 指定共享服务器的监听程序配置。监听程序进程需要一个监听地址, 以便处理系统所用的各个网络协议的连接请求。 除非

MTS_MULTIPLE_LISTENERS=TRUE, 否则每个条目都必须有一个独立的相邻值。此参数自 8.1.3

版起已废弃

语法 : (ADDRESS=(PROTOCOL=tcp)(HOST=myhost)(PORT=7002))

默认值 : NULL

mts_dispatchers:

说明 : 为设置使用共享服务器的共享环境而设置调度程序的数量和类型。可以为该参数指定几个选项。有关详细信息,

请参阅“Oracle8i 管理员指南”和“Oracle Net Administrator's

Guide”。这是字符串值的一个示例: '(PROTOCOL=TCP)(DISPATCHERS=3)'。

值范围: 参数的有效指定值。

默认值 : NULL

max_dispatchers:

说明 : 指定在一个共享服务器环境中可同时运行的调度程序进程的最大数量。

值范围: 根据操作系统而定。

默认值 : 如果已配置了调度程序, 则默认值为大于 5 的任何数目或配置的调度程序的数目

nls_nchar_conv_excp:

说明: (如果值为 TRUE) 当在隐式转换中丢失数据时返回错误的参数。

值范围: FALSE | TRUE

默认值: TRUE

nls_numeric_characters:

说明: 指定将用作组分隔符和小数位的字符。组分隔符就是用来分隔整数位组 (如千, 百万等等)

的字符。小数分隔符用来将一个数字的整数部分与小数部分分隔开。其格式是

<decimal_character><group_separator>。

值范围: 任何单字节字符, '+', '-', '<', '>' 除外。

默认值: 从 NLS_TERRITORY 中获得

nls_sort:

说明: 指定 ORDER BY 查询的比较顺序。对于二进制排序, ORDER BY 查询的比较顺序是以数值为基础的。对于语言排序,

则需要进行全表扫描, 以便将数据按照所定义的语言排序进行整理。

值范围: BINARY 或有效的语言定义名。

默认值: 从 NLS_LANGUAGE 中获得

nls_territory:

说明: 为以下各项指定命名约定, 包括日期和星期的编号, 默认日期格式, 默认小数点字符和组分隔符, 以及默认的 ISO

和本地货币符号。可支持的区域包括美国, 法国和日本。有关所有区域的信息, 请参阅 Oracle8i National

Language Support Guide。

值范围: 任何有效的地区名。

默认值: 根据操作系统而定

nls_timestamp_format:

说明: 与 NLS_TIME_FORMAT 相似, 只不过它设置的是 TIMESTAMP 数据类型的默认值, 该数据类型既存储

YEAR, MONTH 和 DAY 这几个日期值, 也存储 HOUR, MINUTE 和 SECOND 这几个时间值。

语法: TIMESTAMP '1997-01-31 09:26:50.10' (将值存储为 11 个字节)。

默认值: 从 NLS_TERRITORY 中获得

nls_time_format:

说明: 指定一个字符串值, 设置 TIME 数据类型的默认值, 该数据类型包含 HOUR, MINUTE 和 SECOND

这几个日期时间字段。

语法: TIME '09:26:50' (将值存储为 7 个字节)。

默认值: 从 NLS_TERRITORY 中获得

nls_time_tz_format:

说明: 指定一对值 (UTC,TZD), 设置 TIME WITH TIME ZONE 数据类型的默认值, 该数据类型包含

HOUR, MINUTE, SECOND, TIMEZONE_HOUR 和 TIMEZONE_MINUTE

这几个日期时间字段。UTC 是世界时而 TZD 是当地时区。

语法: TIME '09:26:50.20+ 02:00' (将值存储为 9 个字节)。

默认值: 从 NLS_TERRITORY 中获得

nls_length_semantics:

说明: 使用字节或码点语义来指定新列的创建, 如 char, varchar2, clob, nchar, nvarchar2,

nclob 列。各种字符集对字符都有各自的定义。在客户机和服务器上使用同一字符集时,

应以该字符集所定义的字符来衡量字符串。现有的列将不受影响。

值范围: BYTE 或 CHAR。

默认值: nls_length_semantics 的数据库字符集的字符所使用的度量单位。BYTE。

nls_date_format:

说明: 指定与 TO_CHAR 和 TO_DATE 函数一同使用的默认日期格式。该参数的默认值由 NLS_TERRITORY

确定。该参数的值可以是包含在双引号内的任何有效的日期格式掩码。例如: ''MMM/DD/YYYY''。

值范围: 任何有效的日期格式掩码, 但不得超过一个固定长度。

默认值: 派生

nls_timestamp_tz_format:

说明: 与 NLS_TIME_TZ_FORMAT 相似, 其中的一对值指定 TIMESTAMP 数据类型的默认值, 该类型除存储

YEAR, MONTH 和 DAY 日期值, HOUR, MINUTE 和 SECOND 时间值, 还存储

TIMEZONE_HOUR 和 TIMEZONE_MINUTE。

语法: TIMESTAMP '1997- 01- 31 09:26:50+ 02:00' (将值存储为 13 个字节)。

默认值: 从 NLS_TERRITORY 中获得

nls_language:

说明: 指定数据库的默认语言, 该语言将用于消息, 日期和月份名, AD, BC, AM 和 PM 的符号,

以及默认的排序机制。可支持的语言包括英语, 法语和日语等等。

值范围: 任何有效的语言名。

默认值: 根据操作系统而定

nls_comp:

说明: 在 SQL 语句中, 应避免使用繁琐的 NLS_SORT 进程。正常情况下,

WHERE 子句中进行的比较是二进制的, 但语言比较则需要 NLSSORT 函数。可以使用 NLS_COMP 指定必须根据

NLS_SORT 会话参数进行语言比较。

值范围: Oracle8i National Language Support Guide 中指定的任何有效的10 字节字符串。

默认值: BINARY

nls_currency:

说明: 为 L 数字格式元素指定用作本地货币符号的字符串。该参数的默认值由 NLS_TERRITORY 确定。

值范围: Oracle8i National Language Support Guide 中指定的任何有效的10 字节字符串。

默认值: 从 NLS_TERRITORY 中获得

nls_date_language:

说明: 指定拼写日期名, 月名和日期缩写词 (AM, PM, AD, BC) 的语言。该参数的默认值是由 NLS_LANGUAGE

指定的语言。

值范围: 任何有效的 NLS_LANGUAGE 值。

默认值: NLS_LANGUAGE 的值

nls_dual_currency:

说明: 用于覆盖 NLS_TERRITORY 中定义的默认双重货币符号。如果不设置该参数, 就会使用默认的双重货币符号;

否则就会启动一个值为双重货币符号的新会话。

值范围: 任何有效的格式名。。

默认值: 双重货币符号

nls_iso_currency:

说明: 为 C 数字格式元素指定用作国际货币符号的字符串。该参数的默认值由 NLS_TERRITORY 确定。

值范围: 任何有效的 NLS_TERRITORY 值。

默认值: 从 NLS_TERRITORY 中获得

nls_calendar:

说明: 指定 Oracle 使用哪种日历系统作为日期格式。例如, 如果 NLS_CALENDAR 设置为 'Japanese

Imperial', 那么日期格式为 'E YY-MM-DD'。即: 如果日期是 1997 年 5 月 15 日, 那么

SYSDATE 显示为 'H 09-05-15'。

值范围: Arabic Hijrah, English Hijrah, Gregorian, Japanese Imperial, Persian, ROC Official (Republic of China) 和 Thai Buddha。

默认值: Gregorian

plsql_native_c_compiler:

说明: 指定用于将生成的 C 文件编译为目标文件的 C 编译程序的完整路径名。此参数是可选的。随每个平台附带的特有的 make

文件中包含此参数的默认值。如果为此参数指定了一个值, 则该值将覆盖 make 文件中的默认值。

值范围: C 编译程序的完整路径。

默认值: 无

remote_dependencies_mode:

说明: 用于指定数据库为远程 PL/SQL 存储的过程处理被依赖对象的方式。如果设置为 TIMESTAMP,

只有在服务器与本地时间戳相匹配的情况下, 才能执行该过程。如果设置为 SIGNATURE,

在签名安全的情况下即可执行该过程。

值范围: TIMESTAMP | SIGNATURE

默认值: TIMESTAMP

utl_file_dir:

说明: 允许数据库管理员指定 PL/SQL 文件 I/O 许可的目录。使用多个 UTL_FILE_DIR

参数即可指定多个目录。请注意所有用户均可读取或写入 UTL_FILE_DIR 参数中指定的所有文件。

值范围: 任何有效的目录路径。

默认值: 无

plsql_v2_compatibility:

说明: 设置 PL/SQL 兼容级。如果设置为 FALSE, 将执行 PL/SQL V3 行为, 而不允许 V2 行为;

否则在运行 PL/SQL V3 时将接受某些 PL/SQL V2 行为。

值范围: TRUE | FALSE

默认值: FALSE

plsql_native_make_utility:

说明: 指定 make 实用程序 (如 UNIX 中的 make 或 gmake, 即 GNU make)

的完整路径名。要从生成的 C 源中生成共享对象或 DLL, 需要使用 make 实用程序。

值范围: make 实用程序的完整路径名。

默认值: 无

plsql_native_library_dir:

说明: 由 PL/SQL 编译程序使用。它指定目录名, 其中存储了本机编译程序生成的共享对象。

范围值: 目录名。

默认值: 无

plsql_compiler_flags:

说明: 由 PL/SQL 编译程序使用。它将编译程序标志列表指定为一个用逗号分隔的字符串列表。

值范围: native (PL/SQL 模块将按本机代码来编译。), interpreted (然后 PL/SQL 模块将被编译为 PL/SQL 字节代码格式), debug (PL/SQL 模块将用探测调试符号来编译), non_debug。

默认值: " interpreted, non_debug "

plsql_native_linker:

说明: 此参数指定链接程序 (如: UNIX 中的 ld, 或用于将目标文件链接到共享对象或 DLL 的 GNU ld)

的完整路径名。此参数是可选的。随每个平台附带的特有的 make 文件中包含此参数的默认值。如果为此参数指定了一个值,

则该值将覆盖 make 文件中的默认值。

值范围: 链接程序的完整路径名。

默认值: 无

plsql_native_make_file_name:

说明: 指定 make 文件的完整路径名。make 实用程序 (由 PLSQL_NATIVE_MAKE_UTILITY 指定)

使用此 make 文件生成共享对象或 DLL。每个平台附带有端口专用的 make 文件, 该文件包含使用 make

实用程序在该平台上生成 DLL 时要遵循的规则。

值范围: make 文件的完整路径名。

默认值: 无

plsql_v2_compatibility:

说明: 设置 PL/SQL 兼容级。如果设置为 FALSE, 将执行 PL/SQL V3 行为, 而不允许 V2 行为;

否则在运行 PL/SQL V3 时将接受某些 PL/SQL V2 行为。

值范围: TRUE | FALSE

默认值: FALSE

remote_dependencies_mode:

说明: 用于指定数据库为远程 PL/SQL 存储的过程处理被依赖对象的方式。如果设置为 TIMESTAMP,

只有在服务器与本地时间戳相匹配的情况下, 才能执行该过程。如果设置为 SIGNATURE,

在签名安全的情况下即可执行该过程。

值范围: TIMESTAMP | SIGNATURE

默认值: TIMESTAMP

shared_memory_address:

说明: SHARED_MEMORY_ADDRESS 和 HI_SHARED_MEMORY_ADDRESS 指定运行时 SGA

的起始地址。许多平台在链接时间指定 SGA 起始地址, 在这类平台上这些参数将被忽略。如果两个参数都设置为 0 或

NULL, 那么地址将根据平台而定。

值范围: 任何整数值。

默认值: 0

lock_sga:

说明: 用于将整个 SGA 锁定在物理内存中。在不支持这种功能的平台上, 该值将被忽略。

值范围: TRUE | FALSE

默认值: FALSE

hi_shared_memory_address:

说明: 指定系统全局区 (SGA) 的运行时起始地址。在指定 SGA 连接时起始地址的平台上, 该值被忽略。在 64 位平台上,

请使用该值来指定高 32 位和低 32 位。如果不指定该值, 默认值是平台指定的位置。

值范围: 任何整数值。

默认值: 0

pre_page_sga:

说明: 一个根据平台而定的参数, 如果该参数为 TRUE, 将把所有 SGA 页装载到内存中,

以便使该例程迅速达到最佳性能状态。这将增加例程启动和用户登录的时间, 但在内存充足的系统上能减少缺页故障的出现。

值范围: TRUE | FALSE

默认值: FALSE

sga_max_size:

说明: 指定例程存活期间所占用的系统全局区的最大大小。

值范围: 0 到各操作系统所允许的最大值。请注意, 由于该参数值的最小值在启动时已经调整完毕, 因而它无关紧要。

默认值: 如果未指定值, sga_max_size 的默认值将与启动时 SGA 的最初大小 (比如说 X) 相同。该大小取决于 SGA 中各种池的大小, 如缓冲区高速缓存, 共享池, 大型池等。如果指定的值小于 X, 则所使用的 sga_max_size 的值将为 X。也就是说, 它是 X 与用户指定的 sga_max_size 值两者之间的较大值。

Fast_start_parallel_rollback:

说明: 执行并行回退时确定进程的最大数量。在多数事务处理的运行时间都较长的系统上, 该值很有用。

值范围: FALSE | LOW | HIGH

默认值: LOW (2 * CPU_COUNT)

transaction_auditing:

说明: 确定事务处理层是否生成一个特殊的重做记录, 其中包含用户登录名, 用户名, 会话 ID,

部分操作系统信息以及客户机信息。在使用某一重做日志分析工具时, 这些记录可能很有用。

值范围: TRUE | FALSE

默认值: TRUE

transactions:

说明: 指定并行事务处理的最大数量。如果将该值设置得较大, 将增加 SGA 的大小,

并可增加例程启动过程中分配的回退段的数量。默认值大于 SESSIONS, 以实现递归事务处理。

值范围: 一个数值。

默认值: 派生 (1.1 * SESSIONS)

enqueue_resources:

说明: 入队可使并行进程能够共享资源。例如, Oracle 允许一个进程以共享模式锁定一个表, 以共享更新模式锁定另一个表。

值范围: 10 - 65535 (7.3) 或 10 - 无限制 (8.1)。

默认值: 派生 (该值大于 DML_LOCKS + 20 即已足够)

dml_locks:

说明: 所有用户获取的表锁的最大数量。对每个表执行 DML 操作均需要一个 DML 锁。例如, 如果 3 个用户修改 2 个表,

就要求该值为 6。

值范围: 0 或 20 到无限制。

默认值: 4 * TRANSACTIONS (派生)

hash_join_enabled:

说明: 如果设置为 TRUE, 优化程序将在计算最有效的联接方法时考虑散列联接。Oracle 建议数据仓库应用程序应使用 TRUE

值。

值范围: TRUE | FALSE

默认值: TRUE

optimizer_features_enable:

说明: 允许更改 init.ora 参数, 该参数控制着优化程序的行为。受此影响的参数包括 PUSH_JOIN_PREDICATE,

FAST_FULL_SCAN_ENABLED, COMPLEX_VIEW_MERGING 和

B_TREE_BITMAP_PLANS。

值范围: 8.0.0; 8.0.3; 8.0.4; 8.1.3。

默认值: 8.0.0

query_rewrite_integrity:

说明: Oracle Server 执行的查询重写的程度。如果设置为 ENFORCED, Oracle

将保证其一致性和完整性。如果设置为 TRUSTED, 将使用明确声明的关系来允许重写。如果设置为

STALE_TOLERATED, 即使实体化视图与基础数据不一致, 也仍可以进行重写。

值范围: ENFORCED, TRUSTED, STALE_TOLERATED

默认值: ENFORCED

query_rewrite_enabled

说明: 启用或禁用对实体化视图的查询重写。一个特定实体化视图只在如下条件下启用: 会话参数和单独实体化视图均已启用,

并且基于成本的优化已启用。

值范围: TRUE | FALSE

默认值: FALSE

partition_view_enabled:

说明: 如果将 PARTITION_VIEW_ENABLED 设置为 TRUE, 该优化程序将剪除 (或跳过)

分区视图中不必要的表访问。该参数还能更改基于成本的优化程序从基础表统计信息计算分区视图统计信息的方式。

值范围: TRUE | FALSE

默认值: FALSE

optimizer_max_permutations:

说明: 对带有大量联接的查询进行语法分析时,

优化程序将会考虑限制表的交换数。这有助于确保对查询进行语法分析的时间保持在可接受的限制范围内,

但代价是无法找到最佳计划。如果该值小于 1000, 就应该可以确保每次查询的时间仅为几秒钟或更短。

值范围: 4-2^32 (~4.3 G)。

默认值: 80,000

optimizer_index_cost_adj:

说明: 在考虑太多或太少索引访问路径的情况下, 可以用来优化优化程序的性能。该值越低, 优化程序越容易选择一个索引。也就是说,

如果将该值设置为 50%, 索引访问路径的成本就是正常情况下的一半。

值范围: 1 -10000

默认值: 100 (一个索引访问路径的常规成本)

star_transformation_enabled:

说明: 确定基于成本的查询转换是否将被应用到星型查询中。如果设置为 TRUE, 优化程序将考虑将基于成本的转换应用于星型查询中;

如果设置为 FALSE, 将不使用任何转换; 如果设置为 TEMP_DISABLE, 将考虑查询转换, 但不使用临时表。

值范围: TRUE | FALSE | TEMP_DISABLE

默认值: FALSE

optimizer_mode:

说明: 指定优化程序的行为。如果设置为 RULE, 就会使用基于规则的优化程序, 除非查询含有提示。如果设置为 CHOOSE,

就会使用基于成本的优化程序, 除非语句中的表不包含统计信息。ALL_ROWS 或 FIRST_ROWS

始终使用基于成本的优化程序。

值范围: RULE | CHOOSE | FIRST_ROWS | ALL_ROWS

默认值: CHOOSE

optimizer_index_caching:

说明: 调整基于成本的优化程序的假定值,

即在缓冲区高速缓存中期望用于嵌套循环联接的索引块的百分比。它将影响使用索引的嵌套循环联接的成本。将该参数设置为一个较高的值,

可以使嵌套循环联接相对于优化程序来说成本更低。

值范围: 0 - 100 %。

默认值: 0

job_queue_processes:

说明: 只用于复制环境。它指定每个例程的 SNP 作业队列进程的数量 (SNP0, ... SNP9, SNPA, ...

SNPZ)。要自动更新表快照或执行由 DBMS_JOB 创建的请求, 请将该参数设置为 1 或更大的值。

值范围: 0 到 36

默认值: 0

max_transaction_branches:

说明: 控制分布式事务处理中分支的数量。将 MAX_TRANSACTION_BRANCHES 设置为较低的值, 可以根据

MAX_TRANSACTION_BRANCHES * DISTRIBUTED_TRANSACTIONS * 72 字节,

略微减少共享池的空间量。此参数在 8.1.3 版中已废弃。

值范围: 1 - 32

默认值: 8

compatible:

说明: 允许您使用一个新的发行版, 同时保证与先前版本的向后兼容性。

值范围: 默认为当前发行版。

默认值: 由发行版确定

archive_lag_target:

说明: 此参数与基于时间的线程高级功能相关联。

值范围: 0 或 [60, 7200] 中的任意整数。

默认值: 0 为默认值, 此时将禁用基于时间的线程高级功能。否则, 值将代表秒数

aq_tm_processes:

说明: 如果大于零, 就会启用对队列消息的时间监视。该时间值可用于指定消息的延迟和失效属性 (用于应用程序的开发)。

值范围: 0 - 10

默认值: 0

tracefile_identifier:

spfile:

说明: 指定当前使用的服务器参数文件的名称。

值范围: 静态参数

默认值: SPFILE 参数可在客户端 PFILE 中定义, 以指明要使用的服务器参数文件的名称。服务器使用默认服务器参数文件时, SPFILE 的值要由服务器在内部设置。

Logmnr_max_persistent_sessions:

Standby_file_management:

Trace_enabled:

Ifile:

说明: 用于在当前参数文件中嵌入其他参数文件。您可以在一个参数文件的多个行上多次使用该参数, 但最多只能有三级嵌套。

值范围: 任何有效的参数文件名 (语法是 IFILE = parameter_file_name)。

默认值: NULL

remote_listener:

global_context_pool_size:

说明: 从 SGA 分配的用于存储和管理全局应用程序环境的内存量。

值范围: 任意整数值。

默认值: 1 M

plsql_native_library_subdir_count:

fixed_date:

说明: SYSDATE 返回的数据。对于必须始终返回固定日期而非系统日期的测试,

该值很有用。使用双引号或不使用引号。请勿使用单引号。

值范围: YYYY-MM-DD-HH24:MI:SS (或默认的 Oracle 日期格式)。

默认值: NULL

db_name:

说明: 一个数据库标识符, 应与

CREATE DATABASE 语句中指定的名称相对应。

值范围: 任何有效名称最多可有 8 个字符。

默认值: 无 (但应指定)

cluster_database:

cluster_interconnects:

cluster_database_instances:

sql_version:

replication_dependency_tracking:

说明: 跟踪相关性对复制服务器以并行方式传播所作的更改至关重要。如果设置为 FALSE, 数据库上的读/写操作将运行得更快,

但无法为复制服务器产生并行传播的相关性信息。

值范围: TRUE | FALSE

默认值: TRUE (即启用读/写相关性跟踪)

remote_os_roles:

说明: 将 REMOTE_OS_ROLES 设置为 TRUE, 允许由远程客户机的操作系统来分配角色。如果设置为 FALSE,

则由远程客户机的数据库来识别和管理角色。

值范围: TRUE | FALSE

默认值: FALSE

remote_os_authent:

说明: 将 REMOTE_OS_AUTHENT 设置为 TRUE, 允许使用 OS_AUTHENT_PREFIX

的值来验证远程客户机。

值范围: TRUE | FALSE

默认值: FALSE

open_links:

说明: 指定在一次会话中同时打开的与远程数据库的连接的最大数量。该值应等于或超过一个引用多个数据库的单个 SQL

语句中引用的数据库的数量, 这样才能打开所有数据库以便执行该语句。

值范围: 0 - 255 (如果为 0, 不允许分布式事务处理)。

默认值: 4

open_links_per_instance:

说明: 指定 XA 应用程序中可移植的打开连接的最大数量。XA 事务处理使用可移植的打开的连接,

以便在提交一个事务处理后能将这些连接高速缓存。如果创建连接的用户就是拥有事务处理的用户, 各事务处理则可共享连接。

值范围: 0 - UB4MAXVAL

默认值: 4

remote_login_passwordfile:

说明: 指定操作系统或一个文件是否检查具有权限的用户的口令。如果设置为 NONE, Oracle 将忽略口令文件。如果设置为

EXCLUSIVE, 将使用数据库的口令文件对每个具有权限的用户进行验证。如果设置为 SHARED, 多个数据库将共享

SYS 和 INTERNAL 口令文件用户。

值范围:NONE | SHARED | EXCLUSIVE

默认值: NONE

hs_autoregister:

说明: 启用或禁用“异构服务 (HS)”代理的自动自注册。如果启用, 信息将被上载到数据字典中,

以便在通过同一代理建立后续连接时降低开销。

值范围: TRUE | FALSE

默认值: TRUE

global_names:

说明: 指定是否要求数据库链接与所连接的数据库同名。如果该值为 FALSE, 则不执行检查。要使分布式处理中的命名约定一致,

请将该参数设置为 TRUE。

值范围: TRUE | FALSE

默认值: TRUE

distributed_transactions:

说明: 一个数据库一次可参与的分布式事务处理的最大数量。如果由于网络故障异常频繁而减少该值, 将造成大量未决事务处理。

值范围: 0 - TRANSACTIONS 参数值。

默认值: 根据操作系统而定

commit_point_strength:

说明: 一个用于确定分布式事务处理中提交点的位置的值。

值范围: 0 -255

默认值: 根据操作系统而定

db_domain:

说明: 指定数据库名的扩展名 (例如:US.ORACLE.COM) 为使一个域中创建的数据库名唯一, 建议指定该值。

值范围: 由句点分隔的任何字符串, 最长可以有 128 个字符。

默认值: WORLD

dblink_encrypt_login:

说明: 在连接到其他 Oracle Server 时, 数据库链接是否使用加密口令。

值范围: TRUE | FALSE

默认值: FALSE

backup_tape_io_slaves:

说明: 一个恢复管理器参数, 用于确定读取或写入磁带是否要使用服务器进程或一个附加的 I/O 从属。

值范围: TRUE | FALSE

默认值: FALSE

tape_asynch_io:

说明: 用于控制对顺序设备的 I/O 操作 (例如, 将 Oracle 数据备份或复原到磁带上, 或从磁带上备份或复原

Oracle 数据) 是否异步。只有在您的平台支持对顺序设备的异步 I/O 操作的情况下, 将该值设置为 TRUE

才有效; 如果异步 I/O 的执行情况不稳定, 请将该值设置为 FALSE。

值范围: TRUE | FALSE

默认值: FALSE

log_file_name_convert:

说明: 将主数据库上的一个日志文件的文件名转换为备用数据库上对等的路径和文件名。将一个日志文件添加到一个主数据库后,

必须将一个相应的文件添加到备用数据库中。该参数替代 Oracle7 中的 LOG_FILE_NAME_CONVERT

参数。

值范围: 任何格式为 ''主体日志文件的路径/文件名'' 和 ''备用日志文件的路径/文件名'' 的有效路径/文件名

默认值: NULL

fal_server:

说明: 指定此备用数据库的 FAL 服务器。该值是一个 Oracle Net 服务名。此 Oracle Net

服务名被假定为已在备用数据库系统上正确配置, 可指向期望的 FAL 服务器。

值范围: Oracle Net 服务名的字符串值。

Fal_client:

说明: 指定供 FAL 服务 (通过 FAL_SERVER 参数配置) 来引用 FAL 客户机的 FAL

客户机名称。该参数的值是一个 Oracle Net 服务名。此 Oracle Net 服务名被假定为已在 FAL

服务器系统上正确配置, 可指向 FAL 客户机 (即: 此备用数据库)。

值范围: Oracle Net 服务名的字符串值。

Drs_start:

说明: 使 Oracle 可以确定是否应启动 DRMON 进程。DRMON 是一种不会导致致命错误的 Oracle 后台进程,

只要例程存在, 该进程就存在。

值范围: TRUE | FALSE。

默认值: FALSE

remote_archive_enable:

说明: 控制是否可向远程目标执行重做日志文件归档操作。必须将该参数值设置为 "TRUE", 以便 Oracle

数据库例程对重做日志文件进行远程归档, 并且/或者接收远程归档的重做日志文件。

值范围: FALSE | TRUE

默认值: TRUE

standby_preserves_names:

说明: 表明备用数据库上的文件名是否与主数据库上的文件名相同。

值范围: TRUE 或 FALSE。注: 如果将值设置为 True, 且备用数据库与主数据库位于同一系统上, 则主数据库文件可能被覆盖。

默认值: FALSE。

Standby_archive_dest:

说明: 指定来自一个主例程的归档日志的到达位置。STANDBY_ARCHIVE_DEST 和 LOG_ARCHIVE_FORMAT

用于在备用位置上虚拟完全合格的归档日志文件名。备用数据库上的 RFS 服务器将使用该值, 而不是

ARCHIVE_LOG_DEST。

值范围: NULL 字符串或非 RAW 类型的有效路径/设备名。

默认值: NULL

db_file_name_convert:

说明: 将主数据库上的一个新数据文件的文件名转换为备用数据库上的文件名。

值范围: 一个有效的主/备用目录和文件名对。

默认值: 无

max_enable_roles:

说明: 指定一个用户可以启用的数据库角色 (包括子角色) 的最大数量。用户可启用的角色的实际数量是 2 加上

MAX_ENABLED_ROLES 的值, 因为每个用户都有两个附加的角色: PUBLIC 和用户自己的角色。

值范围: 0 -148

默认值: 20

O7_DICTIONARY_ACCESSIBILITY:

说明: 主要用于从 Oracle7 移植到 Oracle8i。如果该值为 TRUE, SYSTEM 权限 (如

SELECT ANY TABLE) 将不限制对 SYS 方案中各对象的访问 (Oracle7 行为)。如果该值为

FALSE, 只有被授予了 SELECT_CATALOG_ROLE, EXECUTE_CATALOG_ROLE 或

DELETE_CATALOG_ROLE 权限的用户才能访问 SYS 方案中的各对象。

值范围: TRUE | FALSE

默认值: TRUE

sql92_security:

说明: 指定要执行一个更新或删除引用表列的值是否需要具有表级的

SELECT 权限。

值范围: TRUE | FALSE

默认值: FALSE

audit_trail:

说明: 启用或禁用数据库审计。如果该参数为 TRUE 或 DB, 审计记录将被写入 SYS.AUD$ 表中; 如果参数为 OS,

则写入一个操作系统文件。

值范围: NONE | FALSE | DB | TRUE | OS

默认值: NONE

rdbms_server_dn:

说明: RDBMS 服务器的唯一判别名。它用于在一个企业目录服务中检索企业角色。有关详细信息, 请参阅“Oracle

Advanced Security Administrator's Guide”。

值范围: 所有 X.500 唯一判别名格式值。

默认值: 无

os_roles:

说明: 确定操作系统或数据库是否为每个用户标识角色。如果设置为 TRUE, 将由操作系统完全管理对所有数据库用户的角色授予。否则,

角色将由数据库标识和管理。

值范围: TRUE | FALSE

默认值: FALSE

os_authent_prefix:

说明: 使用用户的操作系统帐户名和口令来验证连接到服务器的用户。该参数的值与各用户的操作系统帐户连接在一起。要去除 OS 帐户前缀,

请指定空值。

值范围: 任何标识符。

默认值: 根据操作系统而定 (通常是 'OPS$')

object_cache_max_size_percent:

说明: 指定会话对象的高速缓存增长可超过最佳高速缓存大小的百分比,

最大大小等于最佳大小加上该百分比与最佳大小的乘积。如果高速缓存大小超过了这个最大大小,

系统就会尝试将高速缓存缩小到最佳大小。

值范围: 0% 到根据操作系统而定的最大值。

默认值: 10%

object_cache_optimal_size:

说明: 指定在高速缓存超过最大大小的情况下, 会话对象高速缓存将被缩小到的大小。

值范围: 10K 到根据操作系统而定的最大值。

默认值: 100K

session_max_open_files:

说明: 指定可在任一给定会话中打开的 BFILE 的最大数量。一旦达到这个数量,

此后将无法在该会话中打开更多文件。该参数还取决于操作系统参数 MAX_OPEN_FILES。

值范围: 1 - 至少为 (50, OS 级上的 MAX_OPEN_FILES)。

默认值: 10

parallel_execution_message_size:

说明: 指定并行执行 (并行查询, PDML, 并行恢复和复制) 消息的大小。如果值大于 2048 或 4096,

就需要更大的共享池。如果 PARALLEL_AUTOMATIC_TUNING = TRUE,

将在大存储池之外指定消息缓冲区。

值范围: 2148 - 无穷大。

默认值: 如果 PARALLEL_AUTOMATIC_TUNING 为 FALSE, 通常值为 2148; 如果 PARALLEL_AUTOMATIC_TUNING 为 TRUE , 则值为 4096 (根据操作系统而定)。

Paralle_min_percent:

说明: 指定并行执行要求的线程的最小百分比。设置该参数, 可以确保并行执行在没有可用的恰当查询从属进程时, 会显示一个错误消息,

并且该查询会因此而不予执行。

值范围: 0 -100

默认值: 0, 表示不使用该参数。

Parallel_automatic_tuning:

说明: 如果设置为 TRUE, Oracle 将为控制并行执行的参数确定默认值。除了设置该参数外,

你还必须为系统中的表设置并行性。

值范围: TRUE | FALSE

默认值: FALSE

parallel_threads_per_cpu:

说明: 说明一个 CPU 在并行执行过程中可处理的进程或线程的数量,

并优化并行自适应算法和负载均衡算法。如果计算机在执行一个典型查询时有超负荷的迹象, 应减小该数值。

值范围: 任何非零值。

默认值: 根据操作系统而定 (通常为 2)

parallel_broadcast_enabled:

说明 : 通过使用一个散列联接或合并联接, 可以在将多个大结果集联接到一个小结果集 (以字节而不是行为单位来衡量大小)

时改善性能。如果该值设置为 TRUE, 优化程序可以将小结果集内的每个行都传播到大型集内的每个集群数据库处理行中。

值范围: TRUE | FALSE

默认值 : FALSE

parallel_adaptive_multi_user:

说明: 启用或禁用一个自适应算法, 旨在提高使用并行执行方式的多用户环境的性能。通过按系统负荷自动降低请求的并行度,

在启动查询时实现此功能。当 PARALLEL_AUTOMATIC_TUNING = TRUE 时, 其效果最佳。

值范围: TRUE | FALSE

默认值: 如果 PARALLEL_AUTOMATIC_TUNING = TRUE, 则该值为 TRUE; 否则为 FALSE

parallel_max_servers:

说明: 指定一个例程的并行执行服务器或并行恢复进程的最大数量。如果需要, 例程启动时分配的查询服务器的数量将增加到该数量。

值范围: 0 -256

默认值: 由 CPU_COUNT, PARALLEL_AUTOMATIC_TUNING 和 PARALLEL_ADAPTIVE_MULTI_USER 确定

parallel_min_servers

说明: 指定为并行执行启动例程后, Oracle 创建的查询服务器进程的最小数量。

值范围: 0 - PARALLEL_MAX_SERVERS。

默认值: 0

log_archive_dest_state_3:

说明: 指定相应的归档日志目标参数 (仅 LOG_ARCHIVE_DEST_3) 的可用性状态。如果启用,

日志目标将被归档。如果延迟, 该目标将被排除在归档操作之外直至重新启用。

值范围: ENABLE | DEFER

默认值: ENABLE

log_archive_dest_state_4:

说明: 指定相应的归档日志目标参数 (仅 LOG_ARCHIVE_DEST_4) 的可用性状态。如果启用,

日志目标将被归档。如果延迟, 该目标将被排除在归档操作之外直至重新启用。

值范围: ENABLE | DEFER

默认值: ENABLE

log_archive_dest_state_5:

说明: 指定相应的归档日志目标参数 (仅 LOG_ARCHIVE_DEST_5) 的可用性状态。如果启用,

日志目标将被归档。如果延迟, 该目标将被排除在归档操作之外直至重新启用。

值范围: ENABLE | DEFER

默认值: ENABLE

log_archive_dest_state_6:

说明: 标识特定日志归档目标的最近的用户定义状态。

值范围: ENABLE--如果目标属性有效, 则启用归档日志目标; DEFER--即使目标属性有效, 也要延迟处理归档日志目标; 或者是 ALTERNATE--延迟处理归档日志目标, 直到另一个目标的失败导致自动启用了此目标 (前提是备用目标的属性必须有效)。

log_archive_dest_state_7:

说明: 标识特定日志归档目标的最近的用户定义状态。

值范围: ENABLE--如果目标属性有效, 则启用归档日志目标; DEFER--即使目标属性有效, 也要延迟处理归档日志目标; 或者是 ALTERNATE--延迟处理归档日志目标, 直到另一个目标的失败导致自动启用了此目标 (前提是备用目标的属性必须有效)。

log_archive_dest_state_8:

说明: 标识特定日志归档目标的最近的用户定义状态。

值范围: ENABLE--如果目标属性有效, 则启用归档日志目标; DEFER--即使目标属性有效, 也要延迟处理归档日志目标; 或者是 ALTERNATE--延迟处理归档日志目标, 直到另一个目标的失败导致自动启用了此目标 (前提是备用目标的属性必须有效)。

log_archive_dest_state_9:

说明: 标识特定日志归档目标的最近的用户定义状态。

值范围: ENABLE--如果目标属性有效, 则启用归档日志目标; DEFER--即使目标属性有效, 也要延迟处理归档日志目标; 或者是 ALTERNATE--延迟处理归档日志目标, 直到另一个目标的失败导致自动启用了此目标 (前提是备用目标的属性必须有效)。

Log_archive_start:

说明: n只在数据库处于“归档日志”模式的情况下适用。它指定重做日志是自动还是手动复制。建议值是 TRUE, 即执行自动归档;

否则就需要手动干预, 使用

ALTER SYSTEM ARCHIVE LOG ... 命令来阻止例程挂起。

值范围: TRUE | FALSE

默认值: FALSE

log_archive_duplex_dest:

说明: 指定 LOG_ARCHIVE_DEST 外的另一个归档目标。在 Oracle8i 企业版中, 该参数被

LOG_ARCHIVE_DEST_n 代替。

值范围: 一个 NULL 字符串, 或者任何有效的路径或设备名, 原始分区除外。

默认值: NULL

log_archive_format:

说明: LOG_ARCHIVE_FORMAT 只在数据库处于“归档日志”模式的情况下有用。文本字符串与变量 %s (日志序列号)

和 %t (线程号) 结合使用, 用于指定各归档重做日志文件的唯一文件名。该字符串被附加到

LOG_ARCHIVE_DEST 参数。

值范围: 任何有效的文件名。

默认值: 根据操作系统而定

log_archive_max_processes:

说明: 指定要求的 ARCH 进程的数量。如果 LOG_ARCHIVE_START = TRUE, 该值可以在例程启动时被评估;

也可以在通过 SQL*Plus 或 SQL 语法调用 ARCH 进程时评估。

值范围: 1 - 10 (包括端点) 的任何整数。

默认值: 1

log_archive_dest_2:

说明: 五个本地 (指定 LOCATION) 或远程 (指定 SERVICE) 目标位置中的第二个,

归档重做日志文件可以在这些目标位置上被复制。该参数只在企业版 oracle8i 数据库或更高版本的数据库中有效。

值范围: 语法为 (null_string | SERVICE=tnsnames-service | LOCATION=directory-spec)[MANDATORY | OPTIONAL][REOPEN=integer]

默认值: NULL

log_archive_min_succeed_dest:

说明: 定义在可以覆盖日志文件前必须将其复制到的目标的最小数量。该值应大于或等于 LOG_ARCHIVE_DEST_n 中

MANDATORY 目标的数量。

值范围: 1 - 5 (如果与 LOG_ARCHIVE_DEST 和 LOG_ARCHIVE_DUPLEX_DEST 共同使用, 则限制在 1-2)。

默认值: 1

log_archive_trace:

说明: 控制归档日志进程生成的输出。此进程可以通过下列方式启动

ARCn 后台进程 (在输出日志中指定为 ARCn)

明确的会话调用的前台进程 (在输出日志中指定为 ARCH) 或

“受管备用数据库”的远程文件服务器 (RFS) 进程。

值范围:

0: 禁用归档日志跟踪 (这是默认设置)

1: 重做日志文件的追踪归档

2: 每个归档日志目标的追踪归档状态

4: 追踪归档操作阶段

8: 追踪归档日志目标活动

16: 追踪详细的归档日志目标活动

32: 追踪归档日志目标参数修改

64: 追踪 ARCn 进程状态活动

默认值: 0

log_archive_dest_10:

log_archive_dest_3:

说明: 五个本地 (指定 LOCATION) 或远程 (指定 SERVICE) 目标位置中的第三个,

归档重做日志文件可以在这些目标位置上被复制。该参数只在企业版 oracle8i 数据库或更高版本的数据库中有效。

值范围: 语法为 (null_string | SERVICE=tnsnames-service | LOCATION=directory-spec)[MANDATORY | OPTIONAL][REOPEN=integer]

默认值: NULL

log_archive_dest:

说明: 五个本地 (指定 LOCATION) 或远程 (指定 SERVICE) 目标位置中的第三个,

归档重做日志文件可以在这些目标位置上被复制。该参数只在企业版 oracle8i 数据库或更高版本的数据库中有效。

值范围: 语法为 (null_string | SERVICE=tnsnames-service | LOCATION=directory-spec)[MANDATORY | OPTIONAL][REOPEN=integer]

默认值: NULL

log_archive_dest_state_2:

说明: 指定相应的归档日志目标参数 (仅 LOG_ARCHIVE_DEST_2) 的可用性状态。如果启用,

日志目标将被归档。如果延迟, 该目标将被排除在归档操作之外直至重新启用。

值范围: ENABLE | DEFER

默认值: ENABLE

log_archive_dest_5:

说明: 五个本地 (指定 LOCATION) 或远程 (指定 SERVICE) 目标位置中的第五个,

归档重做日志文件可以在这些目标位置上被复制。该参数只在企业版 oracle8i 数据库或更高版本的数据库中有效。

值范围: 语法为 (null_string | SERVICE=tnsnames-service | LOCATION=directory-spec)[MANDATORY | OPTIONAL][REOPEN=integer]

默认值: NULL

log_archive_dest_6:

log_archive_dest_1:

log_archive_dest_8:

log_archive_dest_9:

log_archive_dest_state_1:

说明: 指定相应的归档日志目标参数 (仅 LOG_ARCHIVE_DEST_1) 的可用性状态。如果启用,

日志目标将被归档。如果延迟, 该目标将被排除在归档操作之外直至重新启用。

值范围: ENABLE | DEFER

默认值: ENABLE

log_archive_dest_state_10

说明: 指定归档日志的目标。

值范围: 本地文件系统位置 (磁盘位置) 或通过 Oracle Net 服务名 (tns 服务) 指定的远程归档位置。:

log_archive_dest_4:

说明: 五个本地 (指定 LOCATION) 或远程 (指定 SERVICE) 目标位置中的第四个,

归档重做日志文件可以在这些目标位置上被复制。该参数只在企业版 oracle8i 数据库或更高版本的数据库中有效。

值范围: 语法为 (null_string | SERVICE=tnsnames-service | LOCATION=directory-spec)[MANDATORY | OPTIONAL][REOPEN=integer]

默认值: NULL

create_bitmap_area_size:

说明: CREATE_BITMAP_AREA_SIZE 指定为创建位图索引而分配的内存量。

值范围: 根据操作系统而定。

默认值: 8 MB

pga_aggregate_target:

说明: 指定连接到例程的所有服务器进程的目标 PGA 总内存。请在启用自动设置工作区之前将此参数设置为一个正数。这部分内存不驻留在

SGA 中。数据库将此参数值用作它所使用的目标 PGA 内存量。设置此参数时, 要将 SGA 从可用于 Oracle

例程的系统内存总量中减去。然后可将剩余内存量分配给 pga_aggregate_target。

值范围: 整数加字母 K, M 或 G, 以将此限值指定为千字节, 兆字节或千兆字节。最小值为 10M, 最大值为 4000G

默认值: "未指定", 表示完全禁用对工作区的自动优化。

Sort_area_size:

说明: SORT_AREA_SIZE 以字节为单位, 指定排序所使用的最大内存量。排序完成后, 各行将返回,

并且内存将释放。增大该值可以提高大型排序的效率。如果超过了该内存量, 将使用临时磁盘段。

值范围: 相当于 6 个数据库块的值 (最小值) 到操作系统确定的值 (最大值)。

默认值: 根据操作系统而定

sort_area_retained_size

说明: 以字节为单位, 指定在一个排序运行完毕后保留的用户全局区 (UGA) 内存量的最大值。最后一行从排序空间中被提取后,

该内存将被释放回 UGA, 而不是释放给操作系统。

值范围: 从相当于两个数据库块的值到 SORT_AREA_SIZE 的值。

默认值: SORT_AREA_SIZE 的值

bitmap_merge_area_size:

说明: 指定合并从对索引的某一范围进行扫描而检索得到的位图要使用的内存量。

值范围: 根据系统而定。

默认值: 1MB

workarea_size_policy:

说明: 指定调整工作区大小的策略。此参数控制优化工作区时所处的模式。

值范围: AUTO, MANUAL。

默认值: 如果设置了 PGA_AGGREGATE_TARGET, 则为 AUTO; 否则为 MANUAL。

Hash_area_size:

说明: 与并行执行操作和 DML 或 DDL 语句相关。它以字节为单位, 指定要用于散列联接的最大内存量。有关详细信息,

请参阅手册 Oracle8i Concepts。

值范围: 0 到根据操作系统而定的值。

默认值: 派生:2 * SORT_AREA_SIZE 参数值

db_create_online_log_dest_4:

说明: 设置所创建的联机日志和控制文件的默认位置。如果在创建联机日志或控制文件时未指定文件名, 则使用默认文件名。

值范围: 文件系统目录名。该目录必须已存在。该目录必须具有可让 Oracle 在其中创建文件的许可。

db_create_online_log_dest_3:

说明: 设置所创建的联机日志和控制文件的默认位置。如果在创建联机日志或控制文件时未指定文件名, 则使用默认文件名。

值范围: 文件系统目录名。该目录必须已存在。该目录必须具有可让 Oracle 在其中创建文件的许可。

Db_files:

说明: 可为该数据库打开的数据文件的最大数量。

值范围: MAXDATAFILES - 根据操作系统而定。

默认值: 根据操作系统而定 (在 Solaris 系统上为 200)

db_create_online_log_dest_2:

说明: 设置所创建的联机日志和控制文件的默认位置。如果在创建联机日志或控制文件时未指定文件名, 则使用默认文件名。

值范围: 文件系统目录名。该目录必须已存在。该目录必须具有可让 Oracle 在其中创建文件的许可。

db_create_online_log_dest_1:

说明: 设置所创建的联机日志和控制文件的默认位置。如果在创建联机日志或控制文件时未指定文件名, 则使用默认文件名。

值范围: 文件系统目录名。该目录必须已存在。该目录必须具有可让 Oracle 在其中创建文件的许可。

Db_create_file_dest:

说明: 设置所创建的数据文件, 控制文件和联机日志的默认位置。

值范围: 文件系统目录名。该目录必须已存在。该目录必须具有可让 Oracle 在其中创建文件的许可。

Control_files:

说明: 指定一个或多个控制文件名。Oracle 建议对于不同设备或 OS 文件镜象使用多个文件。

值范围: 1 - 8 文件名 (带路径名)。

默认值: 根据操作系统而定

db_create_online_log_dest_5:

说明: 设置所创建的联机日志和控制文件的默认位置。如果在创建联机日志或控制文件时未指定文件名, 则使用默认文件名。

值范围: 文件系统目录名。该目录必须已存在。该目录必须具有可让 Oracle 在其中创建文件的许可。

Large_pool_size:

说明 : 指定大型池的分配堆的大小, 它可被共享服务器用作会话内存, 用作并行执行的消息缓冲区以及用作 RMAN

备份和恢复的磁盘 I/O 缓冲区。

值范围: 600K (最小值); >= 20000M (最大值是根据操作系统而定的)。

默认值 : 0, 除非配置了并行执行或 DBWR_IO_SLAVES

shared_pool_size:

说明: 以字节为单位, 指定共享池的大小。共享池包含如: 共享游标, 存储的过程,

控制结构和并行执行消息缓冲区等对象。较大的值能改善多用户系统的性能。

值范围:300 KB - 根据操作系统而定。

默认值: 如果是 64 位操作系统, 值为 64MB; 其他情况下, 值为 16MB。

Java_pool_size:

说明: 以字节为单位, 指定 Java 存储池的大小, 它用于存储 Java 的方法和类定义在共享内存中的表示法,

以及在调用结束时移植到 Java 会话空间的 Java 对象。有关详细信息, 请参阅 Oracle8i Java

Developer's Guide。

值范围: 根据操作系统而定。

默认值: 根据操作系统而定

shared_pool_reserved_size:

说明: 指定要为较大连续共享池内存请求而保留的空间,

以避免由碎片引起的性能下降。该池的大小应符合这样的条件:能存储为防止对象从共享池刷新而普遍要求的所有大型过程和程序包。

值范围: SHARED_POOL_RESERVED_MIN_ALLOC 到

SHARED_POOL_SIZE 的一半 (字节)。

默认值: SHARED_POOL_SIZE 值的 5%

cursor_sharing:

说明: 控制可以终止共享相同的共享游标的 SQL 语句类型。

值范围:

强制: 强制表达方式不同但语句意思相同的语句共享一个游标。

EXACT: 只令完全相同的 SQL 语句共享一个游标。

默认值: EXACT

open_cursors:

说明: 指定一个会话一次可以打开的游标 (环境区域) 的最大数量, 并且限制 PL/SQL 使用的 PL/SQL

游标高速缓存的大小, 以避免用户再次执行语句时重新进行语法分析。请将该值设置得足够高,

这样才能防止应用程序耗尽打开的游标。

值范围: 1 - 操作系统限制值。

默认值: 64

serial_reuse:

说明: 指定何种类型的 SQL 游标应利用串行可重用内存功能。如果 CURSOR_SPACE_FOR_TIME = TRUE,

那么 SERIAL_REUSE 值将被忽略, 当作被设置为

DISABLE 或 NULL 的情况处理。

值范围: DISABLE | SELECT | DML | PLSQL | ALL | NULL

默认值: NULL

session_cached_cursors:

说明: 指定要高速缓存的会话游标的数量。对同一 SQL 语句进行多次语法分析后,

它的会话游标将被移到该会话的游标高速缓存中。这样可以缩短语法分析的时间, 因为游标被高速缓存, 无需被重新打开。

值范围: 0 到根据操作系统而定的值。

默认值: 0

cursor_space_for_time:

说明: 在一个游标引用共享 SQL 区时, 确定将 SQL 区保留在共享池中还是从中按过期作废处理。

值范围: TRUE | FALSE

默认值: FALSE (过期作废)

rollback_segments:

说明: 指定要在例程启动过程中获取的一个或多个回退段, 即使其数量超过了 TRANSACTIONS /

TRANSACTIONS_PER_ROLLBACK_SEGMENT 的值。公式为 ROLLBACK_SEGMENTS =

(rbseg_name [, rbseg_name] ...)

值范围:除 SYSTEM 外, DBA_ROLLBACK_SEGS 中列出的任何回退段。

默认值: NULL (默认情况下使用公用回退段)

undo_suppress_errors:

说明: 允许用户在 SMU 模式下尝试执行 RBU 操作 (如

ALTER ROLLBACK SEGMENT ONLINE) 时忽略错误。这样能让用户在将所有应用程序和脚本转换到 SMU

模式之前即可使用 SMU 功能。

值范围: True 或 False

默认值: False。

Max_rollback_segments:

说明: 指定 SGA 中高速缓存的回退段的最大大小。该数值指定一个例程中可同时保持联机状态 (即状态为 INUSE)

的回退段的最大数量。

值范围: 2 -65535

默认值: 最大值 (30, TRANSACTIONS/TRANSACTIONS_PER_ROLLBACK_SEGMENT)

undo_retention:

说明: UNDO_RETENTION

参数用来指定要在数据库中保留的已提交的撤消信息总量。可在例程启动时设置该参数值。可以计算满足撤消保留要求所需的撤消空间量:

UndoSpace = RD * UPS, 其中 UndoSpace 以撤消块数来表示, RD 用以秒为单位的

UNDO_RETENTION 来表示, UPS 以每秒撤消块数来表示。

值范围: 所允许的最大值为 (2 ** 32) 秒。

默认值: 30 秒。

Transactions_per_rollback_segment:

说明: 指定每个回退段允许的并行事务处理的数量。启动时获取的回退段的最小数量为 TRANSACTIONS

除以该参数值的结果。如果在参数 ROLLBACK_SEGMENTS 中命名了其他回退段, 就可以获取这些回退段。

值范围: 1 - 根据操作系统而定。

默认值: 5

undo_management:

说明: 指定系统应使用哪种撤消空间管理模式。如果设置为 AUTO, 例程将以 SMU 模式启动。否则将以 RBU 模式启动。在

RBU 模式下, 撤消空间会象回退段一样在外部分配。在 SMU 模式下, 撤消空间会象撤消表空间一样在外部分配。

值范围: AUTO 或 MANUAL

默认值: 如果启动第一个例程时忽略了 UNDO_MANAGEMENT 参数, 则将使用默认值 MANUAL, 并且例程将以 RBU 模式启动。如果这不是第一个例程, 则将按其他现有例程启动时使用的撤消模式来启动该例程。

Undo_tablespace:

说明: 撤消表空间仅用于存储撤消信息。UNDO_TABLESPACE 仅允许在系统管理撤消 (SMU)

模式下使用。例程将使用指定的撤消表空间, <undoname>。如果该表空间不存在, 或不是撤消表空间,

或正在由另一例程使用, 则例程 STARTUP 将失败。

默认值: 每个数据库都包含 0 个或更多的撤消表空间。在 SMU 模式下, 将为每个 ORACLE 例程分配一个 (且仅限一个) 撤消表空间。

Instance_name

说明: 在多个例程使用相同服务名的情况下, 用来唯一地标识一个数据库例程。INSTANCE_NAME 不应与 SID 混淆,

它实际上是对在一台主机上共享内存的各个例程的唯一标识。

值范围: 任何字母数字字符。

默认值: 数据库 SID

service_names:

说明 : 为 Oracle Net 监听程序用来识别一个服务 (如: 复制环境中的一个特定数据库)

的例程指定服务名。如果该服务没有域, 将附加 DB_DOMAIN 参数。

语法 : SERVICE_NAMES = name1.domain, name2.domain

默认值 : DB_NAME.DB_DOMAIN (如果已定义)

local_listener:

说明 : 一个 Oracle Net 地址列表, 用于标识 Oracle Net

监听程序所在的同一台计算机上的数据库例程。所有例程和调度程序都在该监听程序上注册, 以便启用客户机连接。该参数覆盖在

8.1 版本中废弃的 MTS_LISTENER_ADDRESS 和 MTS_MULTIPLE_LISTENERS 参数。

值范围: 一个有效的 Oracle Net 地址列表。

默认值: (ADDRESS_LIST=(Address=(Protocol=TCP)(Host=localhost)(Port=1521)) (Address=(Protocol=IPC)(Key=DBname)))

license_sessions_warning:

说明: 指定对并行用户会话数量的警告限制。达到该限制后, 其他用户仍然可以连接, 但一条消息将被写入 ALERT 文件。具有

RESTRICTED SESSION 权限的用户将收到一条警告消息, 表明系统已接近最大容量。

值范围: 0 - LICENSE_MAX_SESSIONS

默认值: 0

license_max_sessions:

说明: 指定允许同时进行的并行用户会话的最大数量。达到该限制后, 只有具有 RESTRICTED SESSION

权限的用户才能连接到服务器。所有其他用户都会收到一条警告消息, 表明已达到系统最大容量的限制。

值范围: 0 - 会话许可的数量。

默认值: 0

license_max_users:

说明:

指定您可在该数据库中创建的用户的最大数量。并行会话使用许可和用户使用许可不应被同时启用。LICENSE_MAX_SESSIONS

或 LICENSE_MAX_USERS 或这两者的值应为零。

值范围: 0 - 用户许可的数量。

默认值: 0

db_block_checksum:

说明: DBWn, ARCH 和 SQL*loader 是否为每一个数据块读或写计算或校验块的校验和。

值范围: TRUE | FALSE

默认值: FALSE

shadow_core_dump:

说明: 一个针对 UNIX 的参数, 用于指定是否将 SGA 信息转储到一个生成的核心文件中。如果设置为 FULL, SGA

将被包括在核心转储中。如果设置为 PARTIAL, SGA 将不被转储。

值范围: FULL | PARTIAL

默认值: FULL

db_block_checking:

说明: 用于控制是否检查事务处理管理的块有无损坏。

值范围: TRUE | FALSE

默认值: FALSE

background_core_dump:

说明: 是否将 SGA 信息转储到一个生成的核心文件中 (用于 UNIX)。

值范围: FULL | PARTIAL

默认值: FULL

event:

说明: 由 Oracle 技术支持人员使用, 以调试系统。一般情况下, 不应变更该值。

值范围:不可用。

默认值: 无

user_dump_dest:

说明: 为服务器将以一个用户进程身份在其中写入调试跟踪文件的目录指定路径名。例如, 该目录可这样设置: NT 操作系统上的 C:/

ORACLE/UTRC; UNIX 操作系统上的 /oracle/utrc; 或 VMS 操作系统上的

DISK$UR3:[ORACLE.UTRC]。

值范围: 一个有效的本地路径名, 目录或磁盘。

默认值: 根据操作系统而定

timed_statistics:

说明: 收集操作系统的计时信息, 这些信息可被用来优化数据库和 SQL 语句。要防止因从操作系统请求时间而引起的开销,

请将该值设置为零。将该值设置为 TRUE 对于查看长时间操作的进度也很有用。

值范围: TRUE | FALSE

默认值: FALSE

timed_os_statistics:

说明 : 由系统管理员使用, 以收集操作系统统计信息。为了有效地使用资源, 请只在需要时才设置该值。对于专用服务器,

会在用户连接, 断开连接以及弹出调用 (如果超出了指定的时间限制) 的情况下收集操作系统统计信息。对于共享服务器,

将为推入或弹出的调用收集统计信息。

值范围: 以秒为单位的时间。

默认值 : 0 (操作系统统计信息不被刷新)

core_dump_dest:

说明: 指定核心转储位置的目录名 (用于 UNIX)。

值范围: 任何有效的目录名。

默认值: ORACLE_HOME/dbs

oracle_trace_collection_name:

说明: 指定 Oracle Trace 收集名, 并在输出文件名中使用 (收集定义文件 .cdf 和数据收集文件

.dat)。如果该参数不为空, 且 ORACLE_TRACE_ENABLE = TRUE, 就会启动一个默认的

Oracle Trace 收集, 直到该值再次设置为 NULL。

值范围: 一个有效的收集名, 最长可为 16 个字符 (使用 8 个字符文件名的平台除外)。

默认值: NULL

oracle_trace_collection_path:

说明: 指定 Oracle Trace 收集定义文件 (.cdf) 和数据收集文件 (.dat) 所在的目录路径名。

值范围: 完整的目录路径名。

默认值: 根据操作系统而定 (通常是 ORACLE_HOME/otrace/admin/cdf)

background_dump_dest:

说明: 指定在 Oracle 操作过程中为后台进程 (LGWR, DBW n 等等) 写入跟踪文件的路径名

(目录或磁盘)。它还定义记录着重要事件和消息的数据库预警文件的位置。

值范围: 任何有效的目录名。

默认值: ORACLE_HOME/rdbms/log (根据操作系统而定)

oracle_trace_enable:

说明: 要为服务器启用 Oracle Trace 收集, 请将该值设置为 TRUE。如果设置为 TRUE, 该服务器就可以使用

Oracle Trace。要启动一个收集过程, 请为 ORACLE_TRACE_COLLECTION_NAME

指定一个非空值; 或者使用 Oracle Trace Manager 来启动一个收集。

值范围: TRUE | FALSE

默认值: FALSE

oracle_trace_collection_size:

说明: 以字节为单位, 指定 Oracle Trace 收集文件的最大大小。一旦该收集文件的大小达到这个最大值,

收集就会被禁用。如果值范围指定为零, 就表示没有大小限制。

值范围: 0 -4294967295

默认值: 5242880

oracle_trace_facility_path:

说明: 指定 Oracle TRACE 工具的定义文件 (.fdf) 所在的目录路径名。

值范围: 完整的目录路径名。

默认值: ORACLE_HOME/otrace/admin/fdf/ (根据操作系统而定)

sql_trace:

说明: 禁用或启用 SQL 跟踪设备。如果设置为 TRUE, 将收集优化信息, 这些信息对改善性能很有用。由于使用 SQL

跟踪设备将引发系统开销, 只应在需要优化信息的情况下使用 TRUE。

值范围: TRUE | FALSE

默认值: FALSE

oracle_trace_facility_name:

说明: 指定 Oracle Trace 产品定义文件名 (.fdf 文件名)。该文件包含可为使用 Oracle Trace

数据收集 API 的产品收集的所有事件和数据项的定义信息。Oracle 建议使用默认的文件 ORCLED.FDF。

值范围: 一个有效的设备名, 最长可有 16 个字符。

默认值: oracled

max_dump_file_size:

说明: 指定每个跟踪文件的最大大小。如果您担心跟踪文件会占用太多空间, 可更改该限制。如果转储文件可以达到操作系统允许的最大大小,

请将该值指定为“无限制”。

值范围: 0 - 无限制 (可以用 'K' 或 'M' 为单位)

默认值: 10000 块

resource_limit:

说明: 确定是否在数据库概要文件中实行资源限制。如果设置为 FALSE, 将禁用资源限制。如果值为 TRUE, 即启用资源限制。

值范围: TRUE | FALSE

默认值: FALSE

resource_manager_plan:

说明: 如果指定该值, 资源管理器将激活计划和例程的所有子项 (子计划, 指令和使用者组)。如果不指定, 资源管理器将被禁用,

但使用

ALTER SYSTEM 命令还可以启用。

值范围: 任何有效的字符串。

默认值: NULL

sessions:

说明: 指定用户会话和系统会话的总量。默认数量大于 PROCESSES, 以允许递归会话。

值范围: 任何整数值。

默认值: 派生 (1.1 * PROCESSES + 5)

java_soft_sessionspace_limit:

说明: 以字节为单位, 指定在 Java 会话中使用的 Java 内存 的 '软限制'。如果用户的会话持续时间 Java

状态使用过多的内存, Oracle 将生成一个警告并向跟踪文件写入一则消息。

值范围: 0 - 4GB

默认值: 0

cpu_count:

说明: Oracle 可用的 CPU 的数目 (用于计算其他参数值)。请勿更改该值。

值范围: 0 - 无限制。

默认值: 由 Oracle 自动设置

java_max_sessionspace_size:

说明: 以字节为单位, 指定可供在服务器中运行的 Java 程序所使用的最大内存量。它用于存储每次数据库调用的 Java

状态。如果用户的会话持续时间 Java 状态超过了该值, 则该会话会由于内存不足而终止。

值范围: 根据操作系统而定。

默认值: 0

processes:

说明: 指定可同时连接到一个 Oracle Server 上的操作系统用户进程的最大数量。该值应允许执行所有后台进程, 如:

作业队列 (SNP) 进程和并行执行 (Pnnn) 进程。

值范围: 6 到根据操作系统而定的一个值。

默认值: 由 PARALLEL_MAX_SERVERS 确定

control_file_record_keep_time:

说明: 控制文件中可重新使用部分中的记录必须保留的最短时间 (天数)。

值范围: 0 -365

默认值: 7

log_checkpoint_timeout:

说明: 指定距下一个检查点出现的最大时间间隔 (秒数)。将该时间值指定为 0,

将禁用以时间为基础的检查点。较低的值可以缩短例程恢复的时间, 但可能导致磁盘操作过量。

值范围: 0 - 无限制。

默认值: Oracle8i:900 秒。企业版: 1800 秒

recovery_parallelism:

说明: 指定参与例程或介质恢复的进程的数量。如果值为 0 或 1, 就表明恢复将由一个进程以串行方式执行。

值范围: 根据操作系统而定 (不能超过 PARALLEL_MAX_SERVERS)。

默认值: 根据操作系统而定

fast_start_mttr_target:

说明: 指定从单个数据库例程崩溃中恢复所需的时间 (估计秒数)。FAST_START_MTTR_TARGET

将在内部被转换为一组参数, 用于修改数据库的操作, 从而将它的恢复时间控制在总 "恢复平均时间 (MTTR)"

中的一定范围之内。只有具有 "快速启动故障恢复" 功能的版本才支持此参数。

值范围: [0, 3600]。它将计算数据缓冲区高速缓存条目数之上, 且大于最大日志中的块数的限值。

默认值: 0

log_checkpoints_to_alert:

说明: 指定将检查点信息记录到预警文件中。该参数对于确定检查点是否按所需频率出现很有用。

值范围: TRUE | FALSE

默认值: FALSE

fast_start_io_target:

说明: 指定在系统崩溃或例程恢复期间需要的 I/O 数量。该值比 DB_BLOCK_MAX_DIRTY_TARGET

对恢复过程的控制更加精确。

值范围: 0 (禁用 I/O 恢复限制) 或 1000, 到高速缓存中的所有缓冲区数。

默认值: 高速缓存中的所有缓冲区数

log_checkpoint_interval:

说明: 指定在出现检查点之前, 必须写入重做日志文件中的 OS 块 (而不是数据库块) 的数量。无论该值如何,

在切换日志时都会出现检查点。较低的值可以缩短例程恢复所需的时间, 但可能导致磁盘操作过量。

值范围: 无限制 (指定 0 即可禁用该参数)。

默认值: 根据操作系统而定

log_buffer:

说明: 以字节为单位, 指定在 LGWR 将重做日志条目写入重做日志文件之前,

用于缓存这些条目的内存量。重做条目保留对数据库块所作更改的一份记录。如果该值大于 65536, 就能减少重做日志文件 I/

O, 特别是在有长时间事务处理或大量事务处理的系统上。

值范围: 根据操作系统而定。

默认值: 最大值为 500K 或 128K * CPU_COUNT, 两者之中取较大者

read_only_open_delayed:

说明: 用于加速某些操作, 如: 启动一个很大的数据库而其中大多数数据存储在只读的表空间中。如果设置为 TRUE,

从表空间中读取数据时, 将首先访问只读表空间中的数据文件。有关可能产生的副作用, 请参阅 Server Reference

manual。

值范围: TRUE | FALSE

默认值: FALSE

parallel_instance_group

说明 : 一个集群数据库参数, 标识用来大量产生并行执行从属的并行例程组。并行操作只对在其 INSTANCE_GROUPS

参数中指定一个匹配组的例程大量产生并行执行从属。

值范围: 一个代表组名的字符串。

默认值 : 由所有当前活动例程构成的组

parallel_server:

说明 : 将 PARALLEL_SERVER 设置为 TRUE, 可以启用集群数据库选项。

值范围: TRUE | FALSE

默认值 : FALSE

parallel_server_instances:

说明: 当前已配置的例程的数量。它用于确定 SGA 结构的大小, 该结构由已配置的例程数量来确定。正确设置该参数将改善 SGA

的内存使用情况。 有几个参数是用该数量计算得到的。

值范围: 任何非零值。

默认值: 1

thread:

说明 : 一个集群数据库参数, 用于为每个例程指定一个唯一的重做线程号。在例程的重做线程被禁用的情况下,

该例程无法启动。如果该值为零, 就表示有一个已启用的公用线程可供选择。

值范围: 0 - 已启用线程的最大数量。

默认值 : 0

gc_files_to_locks:

说明 : 一个集群数据库参数, 用于

转贴:诊断性能问题-----Oracle杂志上的一篇文章
诊断性能问题
作者：Cary Millsap
使用扩展SQL跟踪数据来了解是什么在耗费这么长的时间。
假如有一天你开车去上班，但最后还是没能及时参加一个重要会议。你无法将你的革命性的想法呈现给客户，所以他们也不会采用。你的拖拖拉拉使你感到沮丧，你发誓决不再犯同样的错误。那么，为了不再发生类似情况，你怎么判断问题的原因呢？按照下面这个列表进行检查怎么样？
检查汽车外表是否有缺陷，因为外表有缺陷会使汽车的最高速度降低1%或更多。
检查车轮定位，因为外倾角、后倾角或前束角不合适都会导致汽车的操纵不灵活并且耗费时间。
检查发动机，以确保达到额定马力的99%或更高。如果不是这样，则要考虑重装或更换发动机。
不，你可能不会采用这种检查方法；那样太可笑了。你可能会以完全不同的方式来判断问题之所在，可能只是问你自己一个简单的问题：什么事情让我花了这么长时间？
从这个角度出发，问题就迎刃而解了。如果开车需要40分钟，而你在会议开始前20分钟才动身，那么下次就要提前30分钟动身。如果因为交通拥堵浪费了20分钟，那么，下次要么再早一些动身，换条路线，要么更仔细地查看早7点的路况报告。如果是你迷了路，结果浪费了20分钟去兜圈子，那么下次你大概就要事先看看地图。如此等等。
我感到奇怪的是，那些擅长解决日常性能优化问题的数据库专业人员在工作中却使用完全不同的方法来解决数据库性能问题。许多数据库"调优人员"从来不问，"是什么让这个程序运行了这么长时间？"相反，他们会参考检查内容清单，并试图阻止错误发生：
检查所有Oracle块请求是否都由数据库缓存提供服务
检查是否有全表扫描
检查所有排序是否都在内存中进行
检查重做日志是否与其他所有数据库文件进行了适当的隔离
等等。
对于某些工作来说，使用检查内容清单也许很好。但是对于判断性能问题这样的工作，试图确定理论上可能会出错的每一件事，从而对这个问题进行处理的做法的效率会很低。更有效的方法就是找到这个简单问题的答案：
是什么花了这么长时间？
用于优化Oracle程序的好的策略就如同日常生活中用到的策略。就像这样：
1. 使用专门的仪器来测定程序的性能，从而监视运行速度慢的程序。
2. 为运行慢的程序创建资源描述，把程序的响应时间细分为几种有用的类型。
3. 通过首先处理响应时间最长的部分来缩短程序的响应时间。
当你了解了若干技术细节之后，这个方法就非常简单了。如果你真的这样做，那么每次你都能获得一个有用的方法，久而久之，你将能在进行性能改进之前预知其结果。
跟踪
如果你有用于收集程序中每个执行步骤的时间统计信息的高级工具，那就用吧。但只收集汇总数据（如通过对系统全局区[SGA]或其基础共享存储段采样获得的数据）的工具对于某些类型的问题就不适合。
使用昂贵的监控工具时最常见的汇总错误是它们会跨整个Oracle数据库实例来汇总某一给定时间间隔内资源的使用情况。但是，运行速度慢的程序实际上可能不受资源争用问题的影响，而这个问题却完全控制着系统中一些不太重要的程序的性能。
即便是那些在Oracle数据库会话级上汇总信息的工具在诊断一些重要的问题类型时也存在着缺陷。例如，假设一个程序运行10分钟，调用了10000次Oracle SQL*Net message from client 这一"等待事件"，会话等待该事件的总用时为8.3分钟。这意味着会话对SQL*Net message from client事件的等待时间平均为3秒。但是单从汇总数据看，你无法知道这10000次调用是否每次都用3秒，还是这些调用中也许有一个用了5分钟，而其余9999次调用每次只用0.02秒。这两种情况需要进行完全不同的处理。
在这种情况下最能为你提供帮助的诊断数据是Oracle的扩展SQL跟踪数据。扩展SQL跟踪文件按时间顺序显示了Oracle数据库内核在指定时间内所完成工作的逐条记录。收集扩展SQL跟踪数据几乎是免费的。最大的花销是存储每一个需要引起注意的跟踪文件所需磁盘空间（很少超过几兆字节）的费用。
跟踪自己的代码。如果能访问程序的源代码，则打开其扩展SQL跟踪就非常容易。首先必须确保会话的TIMED_STATISTICS和MAX_DUMP_ FILE_SIZE参数设置正确：

Code:	[Copy to clipboard]
alter session set timed_statistics=true; alter session set max_dump_file_size=unlimited;

如果没有设置TIMED_STATISTICS=TRUE，则数据库内核将把0值而不是真正的持续时间发送到跟踪文件中。如果对MAX_DUMP_ FILE_SIZE严加限制，则会在跟踪文件中生成下面这样的消息，而不是你想要的时间数据：
*** DUMP FILE SIZE IS LIMITED TO 1048576 BYTES ***
接下来是激活跟踪。有几种方法可以采用。过去的方法是使用ALTER SESSION命令，如下所示：

Code:	[Copy to clipboard]
alter session set events '10046 trace name context forever, level 12' /* code to be traced goes here */ alter session set events '10046 trace name context off'

更好的方法是使用DBMS_SUPPORT包来激活扩展SQL跟踪：

Code:	[Copy to clipboard]
dbms_support.start_trace(waits=>true, binds=>true) /* code to be traced goes here */ dbms_support.stop_trace()

请注意DBMS_SUPPORT 没有文档说明，可能也不是数据库默认安装的一部分。要了解DBMS_SUPPORT的信息，请参考MetaLink ( metalink.oracle.com)。
跟踪别人的代码。如果你想跟踪没有读/写权限的代码，则激活扩展SQL跟踪就有点麻烦了。但也不会难很多。你首先要获得你想跟踪的会话的V$SESSION.SID和V$SESSION.SERIAL#值。然后使用下面的过程调用，可以设置所选会话的TIMED_STATISTICS和MAX_DUMP_FILE_SIZE参数：

Code:	[Copy to clipboard]
dbms_system.set_bool_param_in_session( sid => 42, serial# => 1215, parnam => 'timed_statistics', bval => true) dbms_system.set_int_param_in_session( sid => 42, serial# => 1215, parnam => 'max_dump_file_size', intval => 2147483647)

（对于Oracle8 8.1.6以前的版本，你可以用ALTER SYSTEM命令处理这些参数。）
接下来要激活跟踪。有几种方法可以采用，包括下面两个：
方法一是使用DBMS_SUPPORT：

Code:	[Copy to clipboard]
dbms_support.start_trace_in_session( sid => 42, serial# => 1215, waits => true, binds => true) /* code to be traced executes during this time window */ dbms_support.stop_trace_in_session( sid => 42, serial => 1215)

若想激活扩展SQL跟踪，请不要使用名为SET_SQL_TRACE_IN_SESSION的DBMS_SUPPORT过程。该过程不允许在跟踪文件中指定等待和绑定的数据。
第二种方法更为精致，但在Oracle数据库10g之前的版本中并不支持这种方法。 DBMS_MONITOR包的引入解决了许多复杂诊断数据收集问题，这些问题是由连接共享和多线程操作所引起的。你可以在Oracle数据库10g中指定要跟踪的服务、模块或行动，而不指定要跟踪的Oracle数据库会话：

Code:	[Copy to clipboard]
dbms_monitor.serv_mod_act_trace_enable( service_name => 'APPS1', module_name => 'PAYROLL', action_name => 'PYUGEN', waits => true, binds => true, instance_name => null) /* code to be traced executes during this time window */ dbms_monitor.serv_mod_act_trace_disable( service_name => 'APPS1', module_name => 'PAYROLL', action_name => 'PYUGEN')

利用DBMS_MONITOR包，Oracle可为要跟踪的特定的业务操作提供完全支持激活或停止诊断数据收集的方法。
测试扩展SQL跟踪。试一试吧。查看第一个跟踪文件只需使用一个简单的SQL*Plus会话，就如同下面这样：

Code:	[Copy to clipboard]
alter session set timed_statistics=true; alter session set max_dump_file_size=unlimited; alter session set tracefile_identifier='Hello'; /* only in Oracle Database 8.1.7and later */ alter session set events '10046 trace name context forever, level 12'; select 'Howdy, it is '||sysdate from dual; exit;

然后在由USER_DUMP_DEST实例参数的值命名的目录中寻找文件名中包含字符串"Hello"的最新写入的.trc文件。用你最喜欢的文本编辑器打开它。 阅读Oracle MetaLink注释39817.1或（Optimizing Oracle Performance，《优化Oracle性能》）一书，以便大概了解原始跟踪文件中有些什么。一定要运行跟踪文件上的tkprof，并研究其输出，但也不要由于有了tkprof就不再看原始的跟踪文件。跟踪文件中还有许多tkprof没有向你展示的内容。
如果你不仅需要一个由简单的SELECT from DUAL 生成的跟踪文件，还需要一个更感兴趣的跟踪文件，那么需要跟踪下面这条SQL语句：

Code:	[Copy to clipboard]
select object_type, owner, object_name from dba_objects;

由此得到的跟踪数据会让你感到很满意，因为Oracle数据库内核替你完成了惊人的工作量。
创建资源描述
了正确而详细的诊断数据之后，你需要以摘要的形式对其进行查看，这有助于你以最快的速度做出响应。至少是从20世纪70年代开始，计算机程序员使用的摘要格式就是资源描述。资源描述只是一张表，它将所用时间分解为若干有用的子集，并按各子集所用时间降序排列。下面是一个资源描述的例子：

Code:	[Copy to clipboard]
Response Time Component Duration -------------------------- ---------- Freeway at <50% speed limit 28.3m 59% Finding a parking spot 7.2m 15% Waiting at traffic lights 5.2m 11% Freeway at ≥50% speed limit 4.0m 8% Other 3.1m 6% -------------------------- ---------- Total 47.8m 100%

这个资源描述说明买一辆速度更快的车不会使你能够更快地到达工作地点。
要从跟踪文件创建资源描述，有两种方法可以采用。
自己动手。《Optimizing Oracle Performance》一书中有所说明。
使用别人的工具。Oracle的tkprof和trcanalyzer（跟踪分析器）工具可为你完成一部分工作，但不是全部。
对数据做出响应
有了详细的诊断数据及其要点，就要决定对所看到的东西如何做出响应。对资源描述做出响应的经验做法非常可靠且相当简单：首先减少花费时间最长的部分，方法是减少调用它的次数。
这种方法几乎总是正确的。理解减少给定组件的调用次数的方法，需要对不同等待事件名称的含义有所了解。例如，当被跟踪的Oracle会话等待"buffer busy waits"这个等待事件时，该会话会向跟踪文件发送会生成足够多的信息，并显示正在等待哪一个缓冲区以及为什么要等待。当一个会话等待SQL*Net message from client事件时，跟踪文件中生成的数据的位置会告诉你执行过的数据库调用哪个是多余的。
在Oracle9i第2版中，有350多个不同的等待事件。在Oracle数据库10g中，几乎有700个等待事件。但不必担心：你根本不必知道它们都是什么意思。你只需知道你的重要程序花费大部分时间所等待的那些事件是什么意思。
看看你能做些什么
有了合适的诊断数据，你就能迅速解决相应的问题，或者证明这些问题不值得解决。
下面给出诊断数据能够解决的一部分问题清单：
整个系统的问题以及个别用户（业务）操作的具体问题
查询错误，包括写得不好的SQL语句、有问题的索引以及数据密度问题
A应用程序错误，包括解析过度、不使用数组运算等等在内的应用程序
串行化错误，包括不必要的频繁发生或费时的锁定、锁存或存储缓冲区活动
网络错误，如选择的协议不当、网络设备有问题
磁盘输入/输出错误，如高速缓存大小不适当、负载不平衡以及配置不当
容量不足，如交换、分页和CPU占用过多

使用Oracle的扩展SQL跟踪数据以及提出"什么如此费时？"这种问题的方法能带来的最好结果是在开始诊断和解决问题之前你将不必再猜测性能问题会是什么。