Oracle SQL
性能优化专题
分享
by SHOUG.
卢巍
How to Find SHOUG?
SQL优化（一）关于索引 (4)
Sql优化（二）关联(join) (8)
Sql优化(三) 关于oracle的并发 (12)
Sql优化（四）oracle优化器(optimizer)介绍 (16)
Sql优化（五）hint（提示）介绍 (18)
Sql优化（六）程序可扩展性：soft parse/hard parse，以及为什么要使用绑定变量 20
Sql优化(七)：程序的可扩展性----insert进程产生的争用 (22)
Sql优化(九) 程序的可扩展性-- 短连接的危害，以及数据库连接（connection）管
理 (24)
Sql优化(十) 程序的可扩展性—sequence上的竞争 (24)
Sql优化(十一) 避免对数据的重复扫描（1） (26)
Sql优化(十二)避免数据重复扫描(2) 使用with as子句提高性能 (28)
Sql优化(十三)分布式环境中的优化（1）合理设计数据流 (30)
Sql优化(十四)分布式环境中的优化（2）选择合适的驱动节点(driving site hint) (32)
Sql优化(十五) Oracle的分区表 (33)
Sql优化(十六) 使用数组技术提升性能 (36)
Sql优化(十七) 常用开发语言中的数组设置 (39)
Sql优化(十八) 调优工具（1）set autotrace和excute plan table (42)
Sql优化(十九) 调优工具（2）sql_trace (46)
Sql优化(二十) 绑定变量用法、适用场合 (49)
Sql优化(二十一) 如何判断和定位系统中未使用绑定变量的语句 (52)
Sql优化(二十二) 自动调优工具：sql tuning advisor和sql profile介绍 (53)
Sql优化(二十三) 如何稳定SQL执行计划(一) (57)
可以在系统级别或session级别，设置CREATE_STORED_OUTLINES参数。例如，alter session set CREATE_STORED_OUTLINES=true。这样该session之后运行的sql就都会被创建outline。 (57)
Sql优化(二十四) 如何稳定SQL执行计划(二) (58)
Sql优化(二十五) 程序可扩展性：如何减少parse (65)
DBA 日志（一）:用隐含参数_corrupted_rollback_segments打开数据库后遇到的离
奇问题 (68)
DBA日志(二) library cache: mutex等待事件分析方法及案例 (69)
SQL优化（一）关于索引
对于sql的执行效率而言，有两个非常重要的因素，一个是索引，另外一个是关联。本篇先
说说索引。
一、索引类型
1. B* tree index，即普通索引
2. 位图索引
3. Function based index函数索引
其他索引还包括bitmap join index，应用索引等，很少使用。下面介绍这3种最常用索引。
二、B*tree index
(一) 索引结构
1. 索引结构包括branch block和leaf block（leaf nodes）。最上面的branch block称为root block。Leaf block(叶子节点)包含index key和rowid信息。Root block到leaf block的层次称为索引高度(level，or height)
2. 根据索引读一行记录的过程是，从root block遍历到leaf block，再根据leaf block的index key找到rowid，再读出对应block找到相应的row。如果height是3,则需要3+1个block的io
3. 索引的所有leaf block在高度相同，这说明不管索引值是什么，遍历索引的开销是一致的。大多数表的索引高度是2-3层，检索的开销是2-3个block的io。这说明对于各种不同量级的表，b*tree的效率都是很高的。下面是**系统中几张不同数量级的表的索引高度
Table_name index_name 记录数BLEVEL
Rate_discount RATE_DISCOUNT_XDISC_ID 100961 2 PRODUCT PRODUCT_PK 37693660 2
CDR_BILLED_2012_06_01 CDR_BILLED_PK 146877600 3
(二) b*tree index的适用/不适用场合
1. 当访问一个表的少部分记录时应该用B*tree索引。前面说过索引检索2-3 block的io，然后根据rowid读取表中的记录。这种情况下比全表扫描效率高很多。
‘少部分’能否确切定义？不能。一个可参考的经验值是：
对于thin table，即每行字节数较少的表，2-3%
对于fat table，即每行字节数较多的表，20%以内
2. 如果表记录数很少，使用索引效率反而低。例如，只有几十条记录，所有数据在一个block内。则全表扫描只需1个block的io，而索引读可能需要几个block
3. 如果访问一个大表的较大部分记录，使用索引效率反而低。
4. 对于第3点，例外情况是如果索引键值已经包含了查询的要求。如index on t(a,b) Select count(*) from t;
Select a from t;
这种情况下，索引可以看作是'瘦身'的table，oracle会使用index full scan代替table full scan，毕竟索引比table小。
(三) 调优例子：不走索引提高性能
update product set no_bill=1 where parent_account_no = 48003823 and parent_subscr_no …;
由于parent_account_no上有索引，因此oracle会选择index range scan。但由于这个account_no的记录数约4000万，整个product表大约9500万，sql运行超过4小时还出不
来。
update product set no_bill=1 where parent_account_no+0 = 48003823 and parent_subscr_no …;强制不走parent_account_no上的索引，执行速度反而快了，时间小于2小时。
三、位图索引
(一) 索引结构
1. 和普通索引相比，位图索引只有少量index entry
2. 每个index entry指向很多行，用一个bit表示表一行，0表示不匹配，1表示匹配
(二) 位图索引适用场合
1. 字段值low distinct cardinality ，即唯一值相对于总行数的比例低，例如一个字段只有T/F两个值。
2. 适合ad hoc query（数据仓库领域有一个概念叫Ad hoc queries，中文一般翻译为“即席查询”。即席查询是指那些用户在使用系统时，根据自己当时的需求定义的查询）。
这类查询在OLAP或报表系统中是很常见的，where字段有各种组合，如
select *from t
where ( ( gender = 'M' and location = 20 )
or ( gender = 'F' or location = 22 ))
and age_group = '18 and under';
select count(*) from t where age_group = '41 and over' and gender = 'F';
如果是普通索引需要建多种组合的复合索引以便不同查询使用，索引空间会很大。而位图索引多个索引可以很方便地进行AND/OR操作，只需在字段上各建一个位图索引即可
以下测试显示，bitmap index两个索引能进行AND操作，而普通索引则不会
使用普通索引只用到一个索引
create table test_table as select owner,object_type,object_name from dba_objects;
create index test_idx1 on test_table(owner);
create index test_idx2 on test_table(object_name);
select count(*) from test_table where owner='HSS' AND object_name='TEST_TABLE'; Execution Plan
----------------------------------------------------------
Plan hash value: 3928831041
-------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time
|
-------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 29 | 4 (0)| 00:00:01 |
| 1 | SORT AGGREGATE | | 1 | 29 | | |
|* 2 | TABLE ACCESS BY INDEX ROWID| TEST_TABLE | 1 | 29 | 4 (0)| 00:00:01 |
|* 3 | INDEX RANGE SCAN | TEST_IDX2 | 2 | | 3 (0)| 00:00:01 |
-------------------------------------------------------------------------------------------
使用位图索引两个索引的检索结果能进行AND操作
drop index test_idx1;
drop index test_idx2;
create bitmap index test_idx1 on test_table(owner);
create bitmap index test_idx2 on test_table(object_type);
select count(*) from test_table where owner='HSS' AND object_type='TEST_TABLE'; Execution Plan
----------------------------------------------------------
Plan hash value: 1409243622
------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time
|
------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 13 | 2 (0)| 00:00:01 |
| 1 | SORT AGGREGATE | | 1 | 13 | |
|
| 2 | BITMAP CONVERSION COUNT | | 55 | 715 | 2 (0)| 00:00:01 |
| 3 | BITMAP AND | | | | |
|
|* 4 | BITMAP INDEX SINGLE V ALUE| TEST_IDX2 | | | | |
|* 5 | BITMAP INDEX SINGLE V ALUE| TEST_IDX1 | | | | |
(三) 什么时候不宜用bitmap index
位图索引适用在大量读的场合，但不适合大量写的环境，特别是并发写的环境。因为当一个index entry被修改时，这个index entry指向的所有行都会被锁，oracle无法锁住单独的bit，而是锁住整个bitmap index entry。因此一个update可能导致几百行被锁。因此位图索引在OLAP系统中较常见，而OLTP系统中几乎不用。
四、函数索引
(一) 函数索引有以下特点:
1. 函数索引在index entry中保存的是函数的计算结果,固化函数计算结果，提升性能select ename, hiredate
from emp
where my_soundex(ename) = my_soundex('Kings')
如果没有函数索引，假如有n行，会调用my_soundex函数n次。如果有，则只需1次
2. 使用方便，不需要改写现有表结构和程序
3. 性能上，对insert/update会有些负面影响，但对查询性能提高很多，需要进行权衡。通常来说insert一条记录只要1次，但查询可能会进行很多次，因而是值得建索引的。
4. 能在某些行上面建索引而忽略其他行，以节省空间。某些情景下可代替位图索引，比位图索引有更好的并发行，而且空间也小
(二) 应用例子
1. 函数索引仅在某些行上建索引的例子。
场景：假设1个表的字段process_flag只有两个值，N表示新记录未处理，处理后变为Y。大多数记录为Y。主要操作是查询process_flag='N'的记录进行处理，然后将process_flag值改为'Y'
如果使用B*tree索引，索引空间大，BLEVEL高。如果使用位图索引,并发修改性能又差。
这时可使用函数索引（只在值为N的记录上）：
create index processed_flag_idx
on big_table( case temporary when 'N' then 'N' end );
2. 用函数索引在某些值上实现完整性约束的例子
场景：project表（name,status）。对于status='ACTIVE'的project,name必须唯一。但
status='INACTIVE'则可以有多条重复记录。
Create unique index active_projects_must_be_unique
On projects ( case when status = 'ACTIVE' then name end );
五、未能走索引的几种情况
以下是使用索引不当所引起的不走索引的几种常见情况：
1. Index on t(x,y)但where 条件中只有y字段。通常情况会进行全表扫描。
2. select count(*) from t通常由于索引比table小，oracle会进行index full scan。但如果索引字段含有NULL值，则不会走索引，因为索引值不包含null，如果进行index full scan统计值就不准确了。
3. select * from t where f(index_column)=value 如果不是函数索引，where条件在索引字段上进行函数操作则不走索引
4. select * from t where indexed_column=5 字段类型需转换。例如indexed_column是字符但where条件中用了数字
5. oracle优化器认为全表扫描比走索引效率更高。这种情况下oracle选择全表扫描。如果开发人员觉得有必要走索引，可以使用hint强制走索引
6. 未及时对表进行analyze，statistics不准确。例如原先是小表，后来数据量大增。由于statistics仍是旧的，oracle优化器会选择不走索引
Sql优化（二）关联(join)
当sql访问多个表时，关联对sql效率就有很重要的影响。关联要考虑两个因素，join的类型和join的次序。
一、JOIN的分类
(一) Nested loop join
1. 适用条件
?关联少量数据(rows)，返回集小
?关联条件能高效访问第二张表(inner table)。高效访问的关联条件如'='，反之非高效的关联条件如
'!=','>'等;inner table（即非驱动表）上要有索引。
因此比较适合OLTP系统，因为一般返回数据量小，而且表上面索引较多。
2. 实现机制
1) 优化器选择驱动表(driving table)，指定其为outer table
2) 指定另一张表为inner table(非驱动表)
3) 根据outer table的每行记录的关联字段，来访问inner table。如下所示：
NESTED LOOPS
outer_loop
inner_loop
由于Nested loop从outer table向inner table查询，关联的次序就比较重要了。
3. nested loop join的例子
SELECT e.first_name, https://www.doczj.com/doc/8018306672.html,st_name, e.salary, d.department_name
FROM hr.employees e, hr.departments d
WHERE d.department_name IN ('Marketing', 'Sales')
AND e.department_id = d.department_id;
-------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 19 | 722 | 3 (0)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| EMPLOYEES | 10 | 220 |
1 (0)| 00:00:01 |
| 2 | NESTED LOOPS | | 19 | 722 | 3 (0)| 00:00:01 |
|* 3 | TABLE ACCESS FULL | DEPARTMENTS | 2 | 32 | 2 (0)| 00:00:01 |
|* 4 | INDEX RANGE SCAN | EMP_DEPARTMENT_IX | 10 | |
0 (0)| 00:00:01 |
-------------------------------------------------------------------------------------------------
(二) Hash join
1. 适用条件
1) 仅用于等值关联equijoin（如=）;
2) 满足下列任一条件：
?大表关联
?或者小表的大部分记录参与关联
2. 实现机制
1) 优化器选择较小的表，基于join key构建hash table。（驱动表）
2) 扫描另外一张较大的表，并在hash table中搜寻关联行
如果内存足够，小表全部在内存中，这种情况是最优的，成本可估算为两张表各一次全表读。
如果内存不够，则小表的一部分可以放在temporary tablespace中（Temp表空间应足够大），以尽可能提高io速度。
3. 例子
SELECT o.customer_id, l.unit_price * l.quantity
FROM orders o ,order_items l
WHERE l.order_id = o.order_id;
--------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
--------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 665 | 13300 | 8 (25)|
|* 1 | HASH JOIN | | 665 | 13300 | 8 (25)|
| 2 | TABLE ACCESS FULL | ORDERS | 105 | 840 | 4 (25)|
| 3 | TABLE ACCESS FULL | ORDER_ITEMS | 665 | 7980 | 4 (25)|
--------------------------------------------------------------------------
(三) Sort merge join
1. 适用情况
?通常情况下hash join性能更好，但如果关联的数据已经排序或不需排序，则sort merge join性能会更
好
?非等值关联（nonequi join,如<,> ）时很有用，因为sort merge join在返回集很大时比nested loop性能
好，而hash join又只能在equijoin中使用。
2. 实现机制
1) Sort操作：关联数据按照关联字段进行排序。如果数据本来就是排序的，就不需此操作
2) Merge操作：经过排序的数据进行merge操作。
需要说明的是,sort merge join没有driving table的概念
(四) 笛卡尔连接
无关联条件，应尽可能避免。
(五) Outer join
是simple join的扩展，
SELECT cust_last_name, sum(nvl2(o.customer_id,0,1)) "Count"
FROM customers c, orders o
WHERE c.credit_limit > 1000
AND c.customer_id = o.customer_id(+)
C表称为preserved table,o表称为optional table
Outer join分为：
Left outer join
Right outer join
Full outer join
和普通join相比，outer join也可以是nested loop、hash join、sort merge等。但有一些不同之处：
1. Nested loop outer join中，以preserved table作为驱动表，而不是像普通join基于cost 来选择驱动表
2. Full outer join（equijoin）在11g中，自动使用基于hash join的算法。执行计划中出现HASH JOIN FULL OUTER。
可以用hint:NATIVE_FULL_OUTER_JOIN/NO_NATIVE_FULL_OUTER_JOIN来指定使用或不使用这一算法。如果不使用，则full outer jion的执行计划是left outer join和right outer jion的union。
二、Join次序
基本原则是：记录少的先关联，这样参与后续关联的记录数就会少。具体来说：
?选择能排除掉最多记录的表作为driving table
?剩余的表中，选选择有最好的filter的表（排除最多记录）作为首先参与关联的表
?以此类推
看这个例子：
SELECT info
FROM taba a, tabb b, tabc c
WHERE a.acol BETWEEN 100 AND 200
AND b.bcol BETWEEN 10000 AND 20000
AND https://www.doczj.com/doc/8018306672.html,ol BETWEEN 10000 AND 20000
AND a.key1 = b.key1
AND a.key2 = c.key2;
假设a表经过filter后记录最少，b次之，c记录最多。那么可以用a作为driving table,先与b 关联，最后与c关联
三．使用hint选择关联方式和次序
(一)使用hint指定关联方式
Oracle优化器自动选择join的方式，但有时不是最优的，开发人员可使用hint来选择join方
式，比较执行效率。相关的hint有：
USE_NL,USE_HASH,USE_MERGE
Exists子句中，HASH_SJ,MERGE_SJ,NL_SJ
Not in子句中，HASH_AJ,MERGE_AJ，NL_AJ
(二) 使用hint指定关联次序
如果oracle优化器选择的关联次序不是你所希望的，可以用hint（leading和ordered）来指定。Ordered表示按照sql语句中表出现的先后次序，leading则可任意指定，更为通用。Leading指定了driving table的选定次序。（在nested loop中,driving table就是outer table，
在hash join中，是hash table。）
SELECT /*+ leading (a b c) */info
WHERE a.acol BETWEEN 100 AND 200
AND b.bcol BETWEEN 10000 AND 20000
AND https://www.doczj.com/doc/8018306672.html,ol BETWEEN 10000 AND 20000
AND a.key1 = b.key1
AND a.key2 = c.key2;
(三) Undocumented hint参数:swap_join_inputs
注意，上面例子中，a作为驱动表和b关联，关联结果作为驱动表，再和c关联。有时需要
改变次序,如下面例子
SELECT /*+ leading (a b c)*/ info
WHERE a.key1 = b.key1
AND b.key2 = c.key2;
假如a 1000条，b 10万条，c 1万条。由于a和c表没有关联字段，因此a和b先关联，再
和c关联。但a关联b产生2万条记录，和c关联时，希望以c为驱动表，能否实现呢？
在hash_join中可以用oracle的隐含hint参数swap_join_inputs实现：
SELECT /*+ leading (a b c) swap_join_inputs(c) */ info
WHERE a.key1 = b.key1
AND b.key2 = c.key2;
详见metalink：How to switch the driving table in a hash join [ID 171940.1]
Sql优化(三) 关于oracle的并发
Oracle的并发技术可以将一个大任务分解为多个小任务由多个进程共同完成。合理地使用并发可以充分利用系统资源，提高效率。
一、并发的种类
●Parallel query
●Parallel DML(PDML)
●Parallel DDL
●Parallel recovery
二、适用场合
适用parallel的两个条件
1）大的任务，如全表扫描大表
这和日常生活中的经验是一样的，小任务自己完成都比派发任务省事
2）系统有足够的资源(cpu/io)
换句话说，并发是在系统资源充足、用户少的系统上，为了充分利用系统资源以提高任务处理速度而设计的一种技术。以下是几种场景：
1）OLTP系统有大量用户和session，如果每个session使用并发查询将导致系统崩溃。如果批处理如帐务系统开账期间没有或用户很少访问，则可使用并发提高速度2）数据仓库系统通常可使用并发查询、PDML等并发，注意有些数据仓库系统也提供给大量用户访问，这种系统有某些OLTP特性应慎用并发
3）无论是OLTP还是数据仓库，维护期间使用parallel ddl和PDML对管理员来说是非常有用的
三、Parallel query
使用并发查询的方法：
1）修改表属性
Alter table big_table parallel 4;
Alter table big_table parallel ;由oracle根据系统资源情况决定。这是推荐的.Oracle根据cpu数
目乘以parallel threads per cpu参数（default 2），例如4cpu的机器，oracle决定parallel数目为8
2）使用hint , select * /*+ PARALLEL(emp,12) */ …
四、PDML
例子：
ALTER TABLE emp PARALLEL (10);
ALTER SESSION ENABLE PARALLEL DML;
INSERT INTO emp
SELECT * FROM t_emp;
COMMIT;
ALTER SESSION ENABLE PARALLEL DML;
INSERT /*+ PARALLEL(emp,12) */ INTO emp
SELECT /*+ PARALLEL(t_emp,12) */ * FROM t_emp;
COMMIT;
注意：使用parallel后，insert select * 语句自动就使用direct-load了，此时不再需要使用append hint（/*+APPEND */）
PDML的限制：
不支持有trigger的表,在上面做PDML，能成功，但忽略了并发性
不支持某些约束，例如self-referential integrity。原因是PDML分为多个独立的session 去修改数据，无法保证某些完整性；容易引起死锁已经其他锁问题
一个session使用了PDML，在commit/rollback之前，另一个session无法再使用PDML
Advanced replication不支持（因为使用了trigger）
Deferred constraints（约束的deferred模式指修改操作在提交时才去验证是否满足约束条件）不支持
分布式事务不支持
Clustered tables不支持
当违反这些限制，PDML要么报错，要么忽略并行度
五、并发与空间浪费
Parallel DDL以及某些PDML依赖于direct path load，即绕过databuffer直接写数据文件。例如，create table as select ，insert /*+APPEND */,
这会形成空间浪费，例如倒入1010M数据,每个extent 100m，direct path load会新分配100m 的extent来存放数据（如果有小于100m的extent，常规insert可以用这些空间）。假设10个并发，每个并发倒入101M数据，会创建2个extent,则总共会创建20个extent,则形成990m空间浪费。一方面浪费了空间（如果表创建之后有常规insert，则能使用这些空间），
另一方面全表扫描时会搜索这些空的extent，这也降低了全表扫描的速度。
表空间的extent管理有两种方式，unform size，则每个extent大小相同，autoallocate是oracle根据内部机制决定extent大小，更灵活
Uniform 方式不支持extent trimming，而autoallocate在parallel ddl中用到extent trimming，减少了空间浪费。
因此在频繁使用parallel DDL操作的表空间上，要么减少uniform size每个extent的大小，要么使用autoallocate ，以减少空间浪费。
六、存储过程的并发
以下是一个常见任务：扫描全表，修改数据，再写入新的表
如果一个进程处理太慢，我们通常会自己将数据划分，然后开多个进程调用。
使用11gr2 内置的并发包：DBMS_PARALLLEL_EXECUTE，大大简化了这一过程
（11gr2之前，没有内置的并发程序包，需要手工按照rowid或主键划分大表，然后通过dbms_job或dbms_schedule并发调用。）
我们以前两天***的一个程序为例，看看如何使用这一并发技术（本例较简单，不见得需要使用这样技术，仅仅作为例子来说明）
程序的目的是删除test_table中orig_bill_ref_no like '18%'的记录，本来一句sql可以完成，由
于数据量太大,系统回滚段不足。因此开发人员准备分多个进程运行
declare
cursor c1
is select orig_bill_ref_no from test_table where orig_bill_ref_no like '18%'
and mod(account_no, 5) = 0; （将数据分为5段）
begin
for r1 in c1 loop
delete from test_table where orig_bill_ref_no = r1.orig_bill_ref_no;
commit;
end loop;
commit;
end;
/
这样的写法会有什么问题呢，很快就遇到snapshot too old错误了。原因是select打开
test_table游标，同时修改test_table并commit数据，由于查询一致性要求，打开的游标要看到的是test_table修改之前的情况，这是从undo去读的，因此一旦时间超出undo_retention，undo信息过期，就报snapshot too old了。
使用ora11g提供的并发包的写法：
1) 创建过程serial过程，用来被多个并发线程调用
create or replace
procedure serial( p_lo_rid in rowid, p_hi_rid in rowid )
is
begin
delete from test_table
where rowid between p_lo_rid and p_hi_rid and orig_bill_ref_no like '15%'; end;
/
2) 按照rowid将表划分为多个chunk，供线程调用
begin
dbms_parallel_execute.create_task('PROCESS BIG TABLE');
dbms_parallel_execute.create_chunks_by_rowid
( task_name => 'PROCESS BIG TABLE',
table_owner => 'LUW',
table_name => 'TEST_TABLE',
by_row => false, --不按行记录数而按block数
chunk_size => 2000 );
end;
/
select *
from (
select chunk_id, status, start_rowid, end_rowid
from dba_parallel_execute_chunks
where task_name = 'PROCESS BIG TABLE'
order by chunk_id
)
where rownum <= 5
/
3) 发起并发任务，按照第2步对表的划分来分配并运行任务
begin
dbms_parallel_execute.run_task
( task_name => 'PROCESS BIG TABLE',
sql_stmt => 'begin serial( :start_id, :end_id ); end;',
language_flag => DBMS_SQL.NATIVE,
parallel_level => 4 );
end;
/
4) 删除并发作业
begin
dbms_parallel_execute.drop_task('process big table' );
end;
/
那么使用并发和简单的delete相比，速度怎样呢
nested loop
,所遵循的是
CBO
提到了first_rows两个缺点：
有时可能错误选择性能开销大的
Oracle保留这个参数是为了向后兼容（特别是升级时设此参数）
这说明oracle是推荐用first_rows_n的。那就简单了，听话就是了。
2) ALL_ROWS还是first_rows_n?
可以借鉴oracle自己的CRM系统siebel中的设置方法：
系统缺省：ALL_ROWS
Siebel应用中设置alter session set optimizer_mode=first_rows_10
这就兼顾了siebel系统中兼有oltp和批处理应用的情况。
批处理应该用ALL_ROWS，前台需要快速返回的应该用first_rows_n。ORACLE缺省设置是ALL_ROWS，这是有道理的，因为系统整体吞吐量较高。因此个人认为除了需要响应时间快的应用要设置first_rows_n（n值的大小根据应用特征来设），其他都可以使用默认设置。
5. optimizer mode设置方法
初始化参数optimizer_mode
Session级别：alter session set optimizer_mode=
语句级别,使用hint：select /*+FIRST_ROWS */ from …
6. 关于统计信息
8i/9i中，optimizer_mode=CHOOSE,当表上面缺统计信息，则会使用RBO。需要手工进行统计信息收集
10g/11g中，当表上面缺统计信息时，oracle在分析sql时会根据
optimizer_dynamic_sampling（default 2）动态取样，这会导致sql的分析变慢。因此保持统计信息准确对于优化器至关重要。
10g/11g中，oracle通过自动作业收集统计信息（当数据变化量超过10%，则触发）统计信息包括表、索引的物理特征，包括数据量、数据分布等。当字段存在大量重复值（skewed data），则应收集histograms
7. 访问路径和关联方法
根据优化目标，优化器决定sql的执行计划。执行计划的主要内容是：
1) 访问路径(access path)，就是访问数据的方式，包括：
Full table scan
Rowed scan(很少)
Index scan
Cluster scan
Hash scan
select /*+ PARALLEL(p,8) */ * from pro_chr_map p where parent_account_no+0 =56719189;
pro_cdr_map有上千万记录，该帐号的记录就占了30%,访问索引反而慢，因此选择全表扫描，并使用并发。
Parent_account_no+0使不走索引，也可通过hint实现：
select /*+ full(p) PARALLEL(p,8) */ * from pro_chr_map p where parent_account_no+0 =56719189;
2.Hints for join operation一例
SQL> set autotrace on
写法一：不使用hint，oracle优化器选择HASH JOIN
SQL> select count(*)
from PRINT_INVOICE_PO a
where exists (select 1 from print_cdr_data b
where b.account_internal_id = a.account_no
and b.trans_date < a.from_date - 5)
and a.task_sn = 'test_3398'
and a.bill_ref_no >= 181992967766
and a.bill_ref_no <= 181993099582; 2 3 4 5 6 7 8
COUNT(*)
----------
Elapsed: 00:02:36.49
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=77535 Card=1 Bytes=5
3)
1 0 SORT (AGGREGATE)
2 1 HASH JOIN (SEMI) (Cost=77535 Card=75 Bytes=3975)
3 2 TABLE ACCESS (BY INDEX ROWID) OF 'PRINT_INVOICE_PO' (C
ost=15862 Card=1495 Bytes=55315)
4 3 INDEX (RANGE SCAN) OF 'IDX_TASK_SN_PO' (NON-UNIQUE)
(Cost=1489 Card=598110)
5 2 INDEX (FAST FULL SCAN) OF 'INDEX_PRINT_CDR2' (NON-UNIQ
UE) (Cost=59870 Card=120489550 Bytes=1927832800)
写法二：用hint指定nested loop join
SQL> select COUNT(*)
from nprint.PRINT_INVOICE_PO a
where exists (select /*+ NL_SJ */ 1 from nprint.print_cdr_data b
where b.account_internal_id = a.account_no
and b.trans_date < a.from_date - 5)
and a.task_sn = 'test_3398'
and a.bill_ref_no >= 181992967766
and a.bill_ref_no <= 181993099582;
2 3 4 5 6 7 8
COUNT(*)
----------
Elapsed: 00:00:01.38
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=2735267 Card=1 Bytes
=53)
1 0 SORT (AGGREGATE)
2 1 NESTED LOOPS (SEMI) (Cost=2735267 Card=75 Bytes=3975)
3 2 TABLE ACCESS (BY INDEX ROWID) OF 'PRINT_INVOICE_PO' (C
ost=15862 Card=1495 Bytes=55315)
4 3 INDEX (RANGE SCAN) OF 'IDX_TASK_SN_PO' (NON-UNIQUE)
(Cost=1489 Card=598110)
5 2 TABLE ACCESS (BY INDEX ROWID) OF 'PRINT_CDR_DATA' (Cos
t=1819 Card=6024478 Bytes=96391648)
6 5 INDEX (RANGE SCAN) OF 'IDX_ACCOUNT_INTERNAL_ID' (NON
-UNIQUE) (Cost=8 Card=203)
Sql优化（六）程序可扩展性：soft parse/hard parse，以及为什么要使用绑定变量
有时单个sql运行效率还不错，但程序一发布，并发进程多了后，系统就运行很慢，这说明程序的扩展性较差。程序扩展性(scalability)差的原因有很多，例如设计不合理导致的互锁。除了锁之外，硬解析也是一个重要原因。硬解析会造成服务器cpu资源紧张，tom甚至认为不使用绑定变量往往是影响oracle性能和扩展性的最大问题。
一、soft parse和hard parse
当oracle执行一句sql时，会先在library cache中进行匹配（相同sql是否运行过？），如果匹配成功则直接使用，这称为soft parse;
如果匹配失败，则需要parse,name resolved,security-check,optimize等等，这称为hard parse(硬解析)，可以想像成源程序先编译后运行。
硬解析的危害：
1)占用资源更多,执行慢，因为不会重用已解析好的query plan
2)硬解析导致library cache上的latch竞争，这会降低系统的并发性，使oracle无法充分
利用系统资源。（此时即使系统资源看上去不忙，oracle也会很慢）
3)一个有很多硬解析的简单应用可能导致数据库所有应用变慢。
二、为什么必须使用绑定变量
如果不使用绑定变量而使用常量，会导致大量硬解析。以下是一个测试，对比使用绑定变量和使用常量时解析情况
SQL> select https://www.doczj.com/doc/8018306672.html, name, b.value
sql语句（mysql优化）绝对经典 误区1：count(1)和count(primary_key) 优于count(*) 很多人为了统计记录条数，就使用count(1) 和count(primary_key) 而不是count(*) ，他们认为这样性能更好，其实这是一个误区。对于有些场景，这样做可能性能会更差，应为数据库对count(*) 计数操作做了一些特别的优化。 误区2：count(column) 和count(*) 是一样的 这个误区甚至在很多的资深工程师或者是DBA 中都普遍存在，很多人都会认为这是理所当然的。实际上，count(column) 和count(*) 是一个完全不一样的操作，所代表的意义也完全不一样。count(column) 是表示结果集中有多少个column字段不为空的记录，count(*) 是表示整个结果集有多少条记录 误区3：select a,b from … 比select a,b,c from …可以让数据库访问更少的数据量 这个误区主要存在于大量的开发人员中，主要原因是对数据库的存储原理不是太了解。实际上，大多数关系型数据库都是按照行(row)的方式存储，而数据存取操作都是以一个固定大小的IO单元(被称作block 或者page)为单位，一般为4KB，8KB… 大多数时候，每个IO单元中存储了多行，每行都是存储了该行的所有字段(lob等特殊类型字段除外)。 所以，我们是取一个字段还是多个字段，实际上数据库在表中需要访问的数据量其实是一样的。当然，也有例外情况，那就是我们的这个查询在索引中就可以完成，也就是说当只取a,b两个字段的时候，不需要回表，而c这个字段不在使用的索引中，需要回表取得其数据。在这样的情况下，二者的IO量会有较大差异。(覆盖索引) 误区4：order by 一定需要排序操作 我们知道索引数据实际上是有序的，如果我们的需要的数据和某个索引的顺序一致，而且我们的查询又通过这个索引来执行，那么数据库一般会省略排序操作，而直接将数据返回，因为数据库知道数据已经满足我们的排序需求了。实际上，利用索引来优化有排序需求的SQL，是一个非常重要的优化手段。延伸阅读：MySQL ORDER BY 的实现分析，MySQL 中GROUP BY 基本实现原理以及MySQL DISTINCT 的基本实现原理。（order by null）
SQL 性能监控及SQL 语句优化 性能监控 作为SQL的数据库服务器，我们可以将其比作一个人，而SQL则是他的心脏，管理员就是他的大脑。要监控心脏是否健康首先要看他这个人是否健康。这两者是相辅相成的，少了一方都是不健康的。 数据库服务器的性能监视器 性能监视器 性能工具的介绍 性能监视器是一种简单而功能强大的可视化工具，用于实时收集系统状态并从日志文件中查看性能数据。 使用性能监视器可以: 获得对诊断系统问题和规划系统资源增长有用的性能数据、了解工作负载及其对系统资源的影响、观察工作负载和资源使用情况的变化和趋势，以便计划未来的升级、通过监视结果来测试配置变化、诊断问题并确定需要优化的组件或进程。 现在，可以开始选择这些对象和要监视的计数器了。 https://www.doczj.com/doc/8018306672.html, 应用程序性能计数器有关https://www.doczj.com/doc/8018306672.html, 应用程序性能计数器的大部分信息最近已被合并到一个题为“改善 .NET 应用程序的性能和伸缩性”的综合文档中。下表描述了一些可用于监视和优化 https://www.doczj.com/doc/8018306672.html, 应用程序（包括 Reporting Services）性能的重要计数器。
除了上表中介绍的这些核心监视要素之外，在您试图诊断 https://www.doczj.com/doc/8018306672.html, 应用程序具有的特定性能问题时，下表中的性能计数器也可对您有所帮助。
Reporting Services 性能计数器 Reporting Services 包括一组它自己的性能计数器，用于收集有关报告处理和资源消耗方面的信息。可通过 Windows 性能监视器工具中出现的两个对象来监视实例和组件的状态和活动：MSRS 2005 Web Service 和 MSRS 2005 Windows Service 对象。 MSRS 2005 Web Service 性能对象包括一组用来跟踪 Report Server 处理过程的计数器，这些处理过程通常通过在线交互式报告浏览操作而引发。这些计数器在https://www.doczj.com/doc/8018306672.html, 停止该 Web 服务后被重设。下表列出了可用于监视 Report Server 性能的计数器，并描述了它们的目的。 性能对象：RS Web Service
SQL Server 系统性能调优解决方案 前言 近几年,医药流通市场经历了激烈的震荡,导致行业逐步成熟和企业的快速变革,差异化经营成为众多医药流通的竞争选择。时空产品在中国医药流通企业的发展过程中得到了广泛且深入应用,大量的客户化开发和定制支撑了企业管理中横向和纵向的变化，很好的适应了企业在发展过程中不断变化的需求。 对于数据库管理系统的使用，很多用户都面临着一个很棘手的问题：系统效率下降。产生效率下降的因素是多方面： 1.硬件问题 2.软件问题 3.实施问题 正因为产生效率下降的因素很多，所以如何去查找原因成为我们首要关注的问题，时空公司也处在积极探索过程中。时空公司在解决一些客户问题的过程中积累了一些方法和思路，归纳总结后呈现给体系内的技术人员，本方案就系统效率调整所必需的基础知识、方法、技巧等几个方面进行阐述，从而让技术人员能够快速定位问题，解决问题，为合作伙伴提供优质，快捷的服务。 索引简介 索引是根据数据库表中一个或多个列的值进行排序的结构。索引提供指针以指向存储在表中指定列的数据值，然后根据指定的排序次序排列这些指针。数据库使用索引的方式与使用书的目录很相似，通过搜索索引找到特定的值，然后跟随指针到达包含该值的行。 索引键：用于创建索引的列。 索引类型 ?聚集索引： 聚集索引基于数据行的键值在表内排序和存储这些数据行。由于数据行按基于聚集索引键的排序次序存储，因此聚集索引对查找行很有效。每个表只能有一个聚集索引，因为数据行本身只能按一个顺序存储。数据行本身构成聚集索引的最低级别（叶子节点）。只有当表包含聚集索引时，表内的数据行才按排序次序存储。如果表没有聚集索引，则其数据行按堆集方式存储。 聚集索引对于那些经常要搜索范围值的列特别有效。使用聚集索引找到包含第一个值的行后，便可以确保包含后续索引值的行在物理相邻。例如：如果应用程序执行的一个查询经常检索某一日期范围内的记录，则使用聚集索引可以迅速找到包含开始日期的行，然后检索表中所有相邻的行，直到到达结束日期。这样有助于提高此类查询的性能。同样，如果对从表中检索的数据进行排序时经常要用到某一列，则可以将该表在该列上聚集（物理排序），避免每次查询该列时都进行排序，从而节省成本。 ?非聚集索引 非聚集索引具有完全独立于数据行的结构。非聚集索引的最低行包含非聚集索引的键值，并且每个键值项都有指针指向包含该键值的数据行。数据行不按基于非聚集键的次序存储。如
Oracle SQL性能优化方法探讨 Oracle性能优化方法(SQL篇) (1) 1综述 (2) 2表分区的应用 (2) 3访问Table的方式 (3) 4共享SQL语句 (3) 5选择最有效率的表名顺序 (5) 6WHERE子句中的连接顺序． (6) 7SELECT子句中幸免使用’*’ (6) 8减少访问数据库的次数 (6) 9使用DECODE函数来减少处理时刻 (7) 10整合简单,无关联的数据库访问 (8) 11删除重复记录 (8) 12用TRUNCATE替代DELETE (9) 13尽量多使用COMMIT (9) 14计算记录条数 (9) 15用Where子句替换HAVING子句 (9) 16减少对表的查询 (10) 17通过内部函数提高SQL效率 (11)
18使用表的不名(Alias) (12) 19用EXISTS替代IN (12) 20用NOT EXISTS替代NOT IN (13) 21识不低效执行的SQL语句 (13) 22使用TKPROF 工具来查询SQL性能状态 (14) 23用EXPLAIN PLAN 分析SQL语句 (14) 24实时批量的处理 (16)
1综述 ORACLE数据库的性能调整是个重要，却又有难度的话题，如何有效地进行调整，需要通过反反复复的过程。在数据库建立时，就能依照顾用的需要合理设计分配表空间以及存储参数、内存使用初始化参数，对以后的数据库性能有专门大的益处，建立好后，又需要在应用中不断进行应用程序的优化和调整，这需要在大量的实践工作中不断地积存经验，从而更好地进行数据库的调优。 数据库性能调优的方法 ●调整内存 ●调整I/O ●调整资源的争用问题 ●调整操作系统参数 ●调整数据库的设计 ●调整应用程序 本文针对应用程序的调整，来讲明对数据库性能如何进行优化。 2表分区的应用 关于海量数据的表，能够考虑建立分区以提高操作效率。建
《高盛帝国》读后感 近段时间拜读了挨利斯写的《高盛帝国》，很有感触。查尔斯·埃利斯在《高盛帝国》一书以传记的方式揭示了高盛成功之道，深入描述了高盛历史上最重要的时期，通过揭示那些关键的人和事件来讲述成就高盛今日地位的色彩丰富而且引人入胜的故事，并充分展现了为高盛播下成功种子的伟大人物的风采。 任何伟大都是应运而生，但并不是所有应运而生的都能够成为伟大。与高盛同期而生的许多顶级企业，如今已经不见踪迹。大浪淘沙始得金，风雨过后，我们才见彩虹之绚烂；浮云散尽，我们才能看到耸立苍崖郁郁青松那孤傲、领袖群伦的绝世风采。在历尽跌宕起伏的危机之后，高盛逐步铸成了企业之魂。从高盛帝国身上，我们可以学习到许多成功企业的特质和经验。 正如作者在前言中所说：一家真正的专业大型公司，应该具有这些共同特质：那些最能干的专业人士认同这是他们最想加入的公司，同时该公司招募并留住那些最好的人才；那些最挑剔的大客户则认可该公司能够持续地提供更好的服务；这家公司在以前和今后的很长一段时间内被其竞争对手看作行业的领军者；有些挑战者可能偶尔通过一两次杰出服务暂时超越，但是他们无法长期维持卓越水准。 尽管成功的模式并不是都可以复制的，但成功的经验却是可以值得学习和借鉴的。 站在不同的视角，我们可以领略出不同的风景。作为引领业界百年的顶级投资银行，无论是在企业经营管理之道，投行人士修身、展业之道，都有我们值得品味、汲取之处。 是因为帝国的辉煌才凸显领袖的伟大，还是因为领袖的伟大所以才铸就了企业的辉煌？这点已经不需要详细去分别。 正如我们一提起唐朝就会想起“贞观之治”、“开元盛世”，以及铸就这些辉煌的唐太宗李世民、唐明皇李隆基；一提起法兰西帝国就会想起席卷欧洲的拿破仑一世；可以说，铸就高盛帝国百年辉煌也离不开高盛帝国的那些元首领袖。而《高盛帝国》也重现了这些领袖的风采和成就：西德尼·温伯格——对市场具有高度敏感性；格斯利维——到将强烈的野性带入日常工作的每一部分；约翰·怀特黑德——对公司重新定位并书写了高盛以客户服务为导向的团队精神的核心价值；约翰·温伯格——非常杰出而又极其谦逊；罗伯特·鲁宾和汉克?保尔森——他们后来担任了美国财政部长；乔恩·科尔津——后来成为美国新泽西州州长；劳尔德·布莱克费恩——现任的CEO和董事会主席。 企业领袖对于企业的作用是毋庸置疑的。每个不同的企业领袖都会以其独特的个人魅力、行为风格、能力及倾向为企业打上个人烙印，而形成独特的企业灵魂，进而影响公司文化。领袖是企业灵魂的核心，君明而后则臣贤，古往今来，
团体心理咨询 团体名称：身心灵成长小组 团体性质：正常成长经验型小组 团体目的：减轻学生的学习压力，提升他们的交际能力，提升学生的学习动力，让他们懂得感恩父母、老师的难处，学会体谅父母、老师。 参加对象：高中在校学生，他们为在校的高三学生，学习成绩良好，有促进自己成长的愿望，能认真地对待小组活动，并且性格友善和坦诚，能和他人和睦相处。将不选择刚刚经历了重大事件或性情过于极端的组员。并且确保组员之间是陌生的。 团体规模：30~40名高中生 团体方案： 单元单元目标活动流程及内容 一、上午1、激发学生对课程的兴趣 2、建立团体规范 3、分组、让组员相互认识、了解1、有缘相识（并且分组） 2、名字的故事 3、团队风采展示 二、下午1、促进学员们的合作意识的增长 2、对生命的思考1、风雨同行 2、五件救生衣 三、晚上1、对学员与父母关系的一个调节 2、学会感恩父母1、父母亲联想 2、感恩父母 3、晚上的作业 四、第二天上午1、成功之路，勇于做领导 2、体会责任与担当 1、两点之间 2、领袖的风采 五、第二天下午1、现场感恩导师和教练，增加学员之间的 情谊 2、疑问解答 1、分享，谈话 具体实施方案： 开始之前由教练说一段比较有哲理而且风趣的话，可以加入存在主义对人生的思考，以及对生命感激。可以说一些过去过去本活动的经验，增加学员对本次活动的可以成功的信心！ 教练要求：每次活动开始前，教练要说一些关于学员分享的内容的话，这是教练对学员分享的反馈让学员与教练有一个互动，使他们可以相互信任。教练的衣着要正式，让学员感受到他们被尊重！需要有5~7名助教，帮助活动的进行！
有缘相识 一、活动目的 1．通过游戏让学生体验主动交往的乐趣。 2．学生在交流中发现共同爱好，寻找志同道合的朋友。 3. 并且让学生分组，八个人一组 三、活动道具 多种颜色的小方形纸若干，每张纸分别剪成四小块彼此能相互锲合的形状。 选择欢快的乐曲做背景音乐。场地可以做室内。 四、活动程序 1．在背景音乐的欢快气氛下，主持人要求每个参与者到场地中央的盘子里选取一张自己喜欢的纸片。 2．根据自己所选纸片的颜色与形状，到群体中寻找能与自己图形锲合的“有缘人”。 3．找到了“有缘人”后，两人坐在一起，相互介绍自己，通过交谈找出彼此间三 个以上的共同点。 4、继续寻找有缘人，四个人一起，让后同样的八个人一起，作为一个固定的小组参加本次咨询以后的活动！ 5．全班交流分享。 名字的故事 1、活动目的 促进组员之间的相互了解，让组员对自我进行反思，组员对他人分享做有效的回馈！ 2、活动步骤 （1）：大家相互介绍自己特点 （2）：由大家复述每个人的特点 （3）：活动分享 团队风采展示 1、活动目的： 促进大家有团队意识，让组员有合作意识，促进相互了解，组成一个团队！2、活动步骤 （1）：按照分组，让组员选出队长、队名、队呼、队歌、风采展示。 （2）：找一个舞台，让组员展示，同时要有竞争，有评委 （3）：大家分享自己的心得
综合系列—《领袖的风采-团队》核心课程(总6页) -CAL-FENGHAI.-(YICAI)-Company One1 -CAL-本页仅作为文档封面，使用请直接删除
[ 课程名称] 综合类-初级-《领袖的风采-团队》 [培训对象]：全员级 [培训天数]：2天 [培训讲师]：劳建民 [课程大纲] 领袖的风采 课程目标： 如何团队"具有"竞争致胜的思维方式？ 团队如何发现与应用"成功的规律" 如何运用企业文化的力量使团队战无不胜？ 如何激发团队的内在潜能？ 如何让组织高效沟通？ 如何让团队创造性解决问题？ 团队如何打造一个具有"我们是一个人"精神的团队？ 团队成员如何塑造人格魅力？ 团队如何具备"真正的风采" 课程特色： “地毯式”的训前研究：每一次内部训练，共三轮深入仔细的训前调查研究，确保课程有明确的针对性，以及“成败共性”背后的特殊表现。 “刻刀式”的训中体验：两天一夜、高密度、高参与度，独特的训练方式与训练内容会令您体验到对课程深深的感受、感悟与震憾。课程的本身就会让您体验到什么叫“流连忘返”。 “教练式”的训后跟踪：课后立即配备一套为期3个月的辅导跟踪训练，共25项系统的自我改造方案，让课程中的理念与方法真正深入您及团队的肌髓。 课程内容： 团队的思维模式 1、个人与团队成功的本源 2、让你的团队独立思考 3、让你的团队不在抱怨 4、打造一只无所不能的团队 5、让你的团队快速适应各种环境
6、稳步快速实现目标的策略 7、让你的团队对目标充满信心 8、每个人从我做起 9、面临困难快速调整到最佳状态的策略 课程时间： 两天一晚 培训对象：全员 领袖的风采 一、理念单元：团队的思维模式 1、成功的定义 2、成功的内涵 1)成功的定义 2)目标的威力 3)量化的价值 4)成功的标准 5)如何确定目标 6)何为职业 7)什么叫做职业化 3、职业素养 1)成功的大VS小、对VS错 2)大河VS小河 3)剥削关系VS合作关系 4)老板VS员工 5)跳楼VS跳槽 6)企业发展速度VS个人发展速度 4、职业化观念 1)成功是因为态度 2)我是我认为的我 3)我是一切的根源 4)不是不可能 5)山不过来我就过去 6)每天进步一点点 7)决心决定成功 8)天助自助者 9)太棒了 二、训练单元：团队的战地演练 如何打造团队
SQLServer性能优化工具 数据和工作负荷示例 使用下例说明 SQL Server 性能工具的使用。首先创建下表。 create table testtable (nkey1 int identity, col2 char(300) default 'abc', ckey1 char(1)) 接下来，在这个表中填充 10,000 行测试数据。可以为列 nkey1 中所填充的数据创建非聚集索引。可以为列 ckey1 中的数据创建聚集索引，col2 中的数据仅仅是填充内容，将每一行增加 300 字节。 declare @counter int set @counter = 1 while (@counter <= 2000) begin insert testtable (ckey1) values ('a') insert testtable (ckey1) values ('b') insert testtable (ckey1) values ('c')
insert testtable (ckey1) values ('d') insert testtable (ckey1) values ('e') set @counter = @counter + 1 end 数据库服务器将进行下面的两个查询： select ckey1,col2 from testtable where ckey1 = 'a' select nkey1,col2 from testtable where nkey1 = 5000 Profiler SQL Server Profiler 记录数据库服务器中所发生活动的详细信息。可以配置 Profiler 以便用大量的可配置性能信息监视并记录在 SQL Server 中执行查询的一个或多个用户。可在 Profiler 中记录的性能信息有：I/O 统计信息、CPU 统计信息、锁定请求、T-SQL 和 RPC 统计信息、索引和表扫描、警告和引发的错误、数据库对象的创建/除去、连接/断开、存储过程操作、游标操作等等。有关 SQL Profiler 可记录的全部信息，请在SQL Server Books Online 中搜索字符串“Profiler”。 将 Profiler 信息装载到 .trc 文件中以便用于 Index Tuning Wizard 中 Profiler 和 Index Tuning Wizard 是强大的工具组合，以帮助数
中国最有影响力的十大培训师 经常有朋友问，国内到底有哪些知名培训师，或者算得上大师级的培训师！ 其实国内比较不错的培训师是很多的，这里给大家分享我认为算的上真正大师，同时又比较有影响力的10个培训师！ 当然还有很多优秀的老师，比如于丹、易中天、翟鸿燊等只能称其教授不能称其培训大师的不在我列，还有像俞敏洪应该叫企业家的也不在我列！ 1、陈安之，华人成功学第一人，也是目前全亚洲第一名的演说家，陈安之的影响力不论是业界还是外界都是最知名的，也是最有号召力和影响力的知名培训师，只要哪个演讲会有他出席，一定会爆满！不论是从书籍的销量还是参加演讲会的人数都是最高的，而且他的舞台魅力及演说能力国内无人能及，是名符其实的第一名！ 2、林伟贤，这位身高只有1米66的全亚洲语速最快的讲师就是林伟贤，他的《MONEY&YOU》曾经是培训业最有影响力的课程之一，他的《BSE》也曾是培训业最贵的课程这一，其演讲风趣幽默，其出版的书籍众多也超级畅销，舞台魅力也非同寻常，他对商业理念上的诠释可谓是所有讲师中最懂商业的培训师，最近二年他退出商业演讲的舞台，投入于公益事业，也算是最有爱心的培训师之一。 3、曾仕强，曾仕强校长开创的中国式管理，对咨询业观念的影响是根本性的；曾仕强教授的大师风范，对咨询业行为模式的影响是革命性的；曾仕强教授的演讲风格，对咨询业表达水平的影响是颠覆性的；大智若愚、厚积薄发、化腐朽为神奇是曾教授的三大风格，曾仕强是少数可称为大师级的人物之一，曾仕强是咨询业当之无愧的风云人物。 4、余世维，这位从经理人转型成为培训师的余世维，他的知名度来源于《职业经理人常犯的11大错误》在网络上的疯狂下载，从而奠定了他是中国管理培训业最有影响力的人物，几乎的所有机场的书店都在播放着他的讲课视频，其在管理培训界的影响力可谓是无人能及。 5、张锦贵，敢号称“亚洲第一名嘴”的人就是张锦贵，他的演讲嘻笑怒骂，谈笑风声，其演讲的《谈情说爱话人生》把两性关系诠释一清二楚，他可谓是亚洲两性关系的权威，听他
近期因工作需要，希望比较全面的总结下SQL SERVER数据库性能优化相关的注意事项，在网上搜索了一下,发现很多文章,有的都列出了上百条,但是仔细看发现，有很多似是而非或者过时(可能对SQL SERVER6.5以前的版本或者ORACLE是适用的)的信息，只好自己根据以前的经验和测试结果进行总结了。 我始终认为，一个系统的性能的提高，不单单是试运行或者维护阶段的性能调优的任务，也不单单是开发阶段的事情，而是在整个软件生命周期都需要注意，进行有效工作才能达到的。所以我希望按照软件生命周期的不同阶段来总结数据库性能优化相关的注意事项。 一、分析阶段 一般来说，在系统分析阶段往往有太多需要关注的地方，系统各种功能性、可用性、可靠性、安全性需求往往吸引了我们大部分的注意力，但是，我们必须注意，性能是很重要的非功能性需求，必须根据系统的特点确定其实时性需求、响应时间的需求、硬件的配置等。最好能有各种需求的量化的指标。 另一方面，在分析阶段应该根据各种需求区分出系统的类型，大的方面，区分是OLTP（联机事务处理系统）和OLAP（联机分析处理系统）。 二、设计阶段 设计阶段可以说是以后系统性能的关键阶段，在这个阶段，有一个关系到以后几乎所有性能调优的过程—数据库设计。 在数据库设计完成后，可以进行初步的索引设计，好的索引设计可以指导编码阶段写出高效率的代码，为整个系统的性能打下良好的基础。 以下是性能要求设计阶段需要注意的： 1、数据库逻辑设计的规范化 数据库逻辑设计的规范化就是我们一般所说的范式，我们可以这样来简单理解范式： 第1规范：没有重复的组或多值的列，这是数据库设计的最低要求。 第2规范: 每个非关键字段必须依赖于主关键字，不能依赖于一个组合式主关键字的某些组成部分。消除部分依赖，大部分情况下，数据库设计都应该达到第二范式。 第3规范: 一个非关键字段不能依赖于另一个非关键字段。消除传递依赖，达到第三范式应该是系统中大部分表的要求，除非一些特殊作用的表。 更高的范式要求这里就不再作介绍了，个人认为，如果全部达到第二范式，大部分达到第三范式，系统会产生较少的列和较多的表，因而减少了数据冗余，也利于性能的提高。 2、合理的冗余 完全按照规范化设计的系统几乎是不可能的，除非系统特别的小，在规范化设计后，有计划地加入冗余是必要的。
MySQL数据库性能（SQL）优化方案本文探讨了提高MySQL 数据库性能的思路，并从8个方面给出了具体的解决方法。 1、选取最适用的字段属性 MySQL可以很好的支持大数据量的存取，但是一般说来，数据库中的表越小，在它上面执行的查询也就会越快。因此，在创建表的时候，为了获得更好的性能，我们可以将表中字段的宽度设得尽可能小。例如，在定义邮政编码这个字段时，如果将其设置为CHAR(255),显然给数据库增加了不必要的空间，甚至使用VARCHAR这种类型也是多余的，因为CHAR(6)就可以很好的完成任务了。同样的，如果可以的话，我们应该使用MEDIUMINT而不是BIGIN 来定义整型字段。 另外一个提高效率的方法是在可能的情况下，应该尽量把字段设置为NOT NULL，这样在将来执行查询的时候，数据库不用去比较NULL值。 对于某些文本字段，例如“省份”或者“性别”，我们可以将它们定义为ENUM类型。因为在MySQL中，ENUM类型被当作数值型数据来处理，而数值型数据被处理起来的速度要比文本类型快得多。这样，我们又可以提高数据库的性能。 2、使用连接（JOIN）来代替子查询(Sub-Queries) MySQL从4.1开始支持SQL的子查询。这个技术可以使用SELECT语句来创建一个单列的查询结果，然后把这个结果作为过滤条件用在另一个查询中。例如，我们要将客户基本信息表中没有任何订单的客户删除掉，就可以利用子查询先从销售信息表中将所有发出订单的客户ID取出来，然后将结果传递给主查询，如下所示： DELETE FROM customerinfo WHERE CustomerID NOT in (SELECT CustomerID FROM salesinfo )
《领袖的风采》——团队工作坊 【课程特色】 关于体验式学习课程包括两天一晚的课程：导师授课、体验式活动和学员分享，它是在体验式学习的基础上进行。 体验式学习并不是革命性的理论，而是一种自然学习的方法。就如你学会如何走路、说话、使用筷子、学会游泳、骑自行车的方法。在你生命的前五至十年正是透过此种学习方式学到了各类知识和技能，这种方式的学习占了一生所学的90%。体验式学习是人类学习最有效的方法之一。没有体验的学习就如同无水源之池塘。 体验式学习是一个探索的过程，是一个透过肢体、情感和理智层次参与而在直接感知中学习的过程。是个体与环境之间不断的交互作用的过程。在探索的过程中并没有人人适用的答案，而学习者会在体验中提升自我觉察与认知能力。它是以人为主的学习而不是把焦点放在人之外的事物上。 【课程索引】 如何做才是领袖，如何具备领袖的风采？ 领袖如何"移植"竞争致胜的思维方式？ 领袖如何发现与应用"成功的规律"？ 领袖如何运用企业文化的力量使团队战无不胜？ 领袖如何激发团队的内在潜能？ 领袖如何让组织高效沟通？ 领袖如何选择先进的管理"杠杆"？ 领袖如何创造性解决问题？ 领袖如何打造一个具有"我们是一个人"精神的团队？ 领袖如何塑造人格魅力？ 领袖如何具备"领袖的风采"？
在《领袖的风采》的体验式学习中，我们会发现所有探究的终点都会 通向我们最初的起点…… 【课程价值】 课程通过互动、音乐、灯光，教练引导，体验--欣赏、信任、激情、付出、负责任、承诺、共赢、感召、可能性等心态及信念。 通过体验活动，学员自发提升动力，强调自我认识、自我醒觉、自我定位，认识到我就是一切的根源，调动学员的自我生发激情。具体将从以下方面得到收获： ☆心智模式☆共同的价值观☆责任感☆激情☆感恩 ☆危机意识☆信任☆沟通☆协作力☆领导力 【课程大纲】 时间：第一天上午09:00-12:00 一、领袖的成功理念 1.团队角色分析及自我角色认知 1)体验式培训和传统式培训的区别 2)五秒钟体验 3)性格测试及团队角色分析 团队和团队精神 团队与个人的关系 体验活动（破冰分组团建结死党） 1)团队学习 2)团队公约 3)相见欢 4)共同语言 2.关于领袖成功 1)成功的定义
（1）选择最有效率的表名顺序(只在基于规则的优化器中有效)： ORACLE的解析器按照从右到左的顺序处理FROM子句中的表名，FROM子句中写在最后的表(基础表 driving table)将被最先处理，在FROM子句中包含多个表的情况下,你必须选择记录条数最少的表作为基础表。如果有3个以上的表连接查询, 那就需要选择交叉表(intersection table)作为基础表, 交叉表是指那个被其他表所引用的表. （2） WHERE子句中的连接顺序．： ORACLE采用自下而上的顺序解析WHERE子句,根据这个原理,表之间的连接必须写在其他WHERE条件之前, 那些可以过滤掉最大数量记录的条件必须写在WHERE 子句的末尾. （3） SELECT子句中避免使用 * ： ORACLE在解析的过程中, 会将'*' 依次转换成所有的列名, 这个工作是通过查询数据字典完成的, 这意味着将耗费更多的时间 （4）减少访问数据库的次数： ORACLE在内部执行了许多工作: 解析SQL语句, 估算索引的利用率, 绑定变量 , 读数据块等； （5）在SQL*Plus , SQL*Forms和Pro*C中重新设置ARRAYSIZE参数, 可以增加每次数据库访问的检索数据量 ,建议值为200 （6）使用DECODE函数来减少处理时间： 使用DECODE函数可以避免重复扫描相同记录或重复连接相同的表. （7）整合简单,无关联的数据库访问： 如果你有几个简单的数据库查询语句,你可以把它们整合到一个查询中(即使它们之间没有关系) （8）删除重复记录： 最高效的删除重复记录方法 ( 因为使用了ROWID)例子： DELETE FROM EMP E WHERE E.ROWID > (SELECT MIN(X.ROWID)FROM EMP X WHERE X.EMP_NO = E.EMP_NO); （9）用TRUNCATE替代DELETE： 当删除表中的记录时,在通常情况下, 回滚段(rollback segments ) 用来存放可以被恢复的信息. 如果你没有COMMIT事务,ORACLE会将数据恢复到删除之前的状态(准确地说是恢复到执行删除命令之前的状况) 而当运用TRUNCATE时, 回滚段不再存放任何可被恢复的信息.当命令运行后,数据不能被恢复.因此很少的资源被调用,执行时间也会很短. 译者按: TRUNCATE只在删除全表适 用,TRUNCATE是DDL不是DML) （10）尽量多使用COMMIT： 只要有可能,在程序中尽量多使用COMMIT, 这样程序的性能得到提高,需求
新时代新员工职业化训练 课程背景： 本课程以职业化精神和行为规范为主线，设计了角色、观念、行为、技能、职业生涯发展等方面几个模块内容。通过针对性地培训，使学员： 培养责任心和敬业精神，养成良好的职业习惯，树立下一道工序就是自己的客户的服务意识，实现从校园人或者社会人到企业人的角色转变。 端正心态，以积极正面的态度，正确对待工作中出现的问题和遇到的挫折，以高昂的热情和斗志投入工作。 课程收益： ●学会处理个人与公司的关系，服从组织规则，“小我”融入“大我” ●掌握沟通技能，学会与上司、同事和客户的相处技巧，减少误解和冲突，增进信任，提高工作绩效 ●分清轻重缓急，合理安排工作，忙要忙出成果与意义 ●学会习解决问题的程序和辅助的工具去分析并解决工作中出现的疑难问题 ●树立自我批判的意识，更新观念，规划职业生涯，适应公司的发展 ●树立结果思维，提升新员工向心力、凝聚力、驱动力、执行力、自主自发的完成各项任务 课程对象：新时代员工、新进员工、新进大学生 课程时间：标准版1-2天，6小时/天 课程方式：封闭训练、讲学互动、游戏体验、团队竞赛、分析诊断、实战答疑、小组研讨、心得分享 课程大纲 第一讲：角色篇——态度决定一切 一、从踏进公司到融入企业我们需要那些转变？ 1. 从“人生理想”转向“职业理想” 2. 由“校园人或者社会人”转向“职业人” 3. 从理论学习转向实际应用
4. 从散漫的生活转向紧张的工作状态 5. 从单纯的人际交往转向丰富的人际环境 6. 从浮躁转向理性 7. 从被呵护转向自立自强 二、小我融入大我 1. 入职焦虑 2. 新员工如何快速融入组织 3. 人的改变循环和脑啡效应 三、自我批判 1. 为什么要自我批评？ 2. 如何自我批判？ 3. 自我批判什么？ 案例：华为的自我批判 第二讲：心态篇——态度决定一切 一、心态的七大目标 1. 心态决定成败 2. 阳光心态 3. 积极心态 4. 老板心态 5. 共赢心态 6. 空杯心态 7. 感恩心态 二、服从组织规则 1. 什么是组织规则？ 2. 为什么要服从组织规则？ 3. 学会忍受“不公平”，正确对待挫折 4. 自我激励，妥善处理压力 三、责任心和敬业精神 1. 业务员一线的故事
1.问题发现 1.1一份AWR报告 今天，收到一份100个并发用户访问下压力测试的AWR报告，并发事务数平均每秒只有6个不到。 在这个26.53分钟间隔的报告里，CPU TIME在整个TOP 事件中最突出 占了近97.6%，在8个CPU系统中，数据库给CPU造成的压力为： (5740/(26.53*60*8)*100%=45.07%，这么小的压力下，CPU就能冲得这么高，说明
系统中肯定是有问题的。下面转向TOP SQL去确认下造成资源争用最明显的SQL语句。 1.2TOP SQL 1.2.1SQL ordered by Elapsed Time 1.2.2SQL ordered by CPU Time
1.2.3SQL ordered by Gets 1.3问题发现 对一个OLTP系统来说，每一个语句的执行，都是要将其消耗的资源降到最低，这跟 OLAP系统是有差别的。对于后者来说，它需要的是短的时间返回结果，不管中间你会拿多大的成本做代价。 从上面反映的问题来看，我们的性能，无疑就是葬送在了SQL_ID为4841ajtgh43qy、1hwqh7kvxn6yg、g295mubwupf52和anyty5rts5tzf这四个语句上面，下面将对这四个SQL语句一 一做出分析，并给出相应的调优建议。
2.SQL_ID为4841ajtgh43qy的语句 2.1调整前 2.1.1语句 SELECT * FROM (SELECT TT.*, ROWNUM AS ROWNO FROM (select to_char(c.cust_id), c.password from CUST_CERTIFICATION c where c.cust_id = :CUST_ID) TT WHERE ROWNUM <= 10) TABLE_ALIAS where TABLE_ALIAS.rowno > 0 ; 2.1.2解释计划 又见全表扫
SQL 高性能查询优化语句，一些经验总结 1.应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如： select id from t where num is null; 可以在num上设置默认值0，确保表中num列没有null值，然后这样查询：select id from t where num = 0; 2.应尽量避免在 where 子句中使用!=或$amp; 3.应尽量避免在 where 子句中使用 or 来连接条件，否则将导致引擎放弃使用索引而进行全表扫描，如： select id from t where num=10 or num=20; 可以这样查询： select id from t where num=10 union all select id from t where num=20; 4.in 和 not in 也要慎用，因为IN会使系统无法使用索引,而只能直接搜索表中的数据。如： select id from t where num in(1,2,3) 对于连续的数值，能用 between 就不要用 in 了：
select id from t where num between 1 and 3; 5.尽量避免在索引过的字符数据中，使用非打头字母搜索。这也使得引擎无法利用索引。 见如下例子： SELECT * FROM T1 WHERE NAME LIKE ‘%L%’; SELECT * FROM T1 WHERE SUBSTING(NAME,2,1)=’L’; SELECT * FROM T1 WHERE NAME LIKE ‘L%’; --第三个查询能够使用索引来加快操作 即使NAME字段建有索引，前两个查询依然无法利用索引完成加快操作，引擎不得不对全表所有数据逐条操作来完成任务。而第三个查询能够使用索引来加快操作。 6.必要时强制查询优化器使用某个索引，如在 where 子句中使用参数，也会导致全表扫描。因为SQL只有在运行时才会解析局部变量，但优化程序不能将访问计划的选择推迟到运行时；它必须在编译时进行选择。然而，如果在编译时建立访问计划，变量的值还是未知的，因而无法作为索引选择的输入项。如下面语句将进行全表扫描： select id from t where num=@num; 可以改为强制查询使用索引：
构建园本文化，提升团队品质 幼儿园园本文化建设汇报材料 一、构建园本文化，提升品牌形象 一个有品质的团体，一定会有好的文化传承。我们的“开放教育”研究有其独特的价值，它所建立的较完善的教育体系，为团队发展和教师的专业成长产生了重大作用。 （一）确立团队组织的核心要素 园本核心价值观：园本核心价值观是团队成员的共同追求，要求全体成员明确怎样才能把共同的愿景变为现实，即态度、行为和承诺。 共启愿景：共同愿景是组织发展的方向，为成员提供了清晰的目标和行动进程，是幼儿园从现实走向未来愿景的最重要桥梁，它激励每名成员为之努力。 互动机制：成员间以民主、开放、自由的对话方式发现问题，研究解决问题，实现共同发展。 合作学习：整合团体中每名成员的资源，超越个体学习力，形成具有更大潜能的学习群体，为团队的共同目标的实现发挥超出想象的作用，实现自我超越。 人际关系：在互信的环境中，成员间彼此尊重、信任、支持、合作，互惠互利，共享发展成果。
激励机制：尊重、支持和鼓励个体及团体的创新与奉献，在多元化的激励中让成员真切体验到组织的生命力、影响力、凝聚力，使其乐于为之付出行动，能感受到工作、生活中的幸福指数。 （二）蕴含执着追求的园徽 分析我们所处的地理环境，围绕我们的办园目标，带着我们的心灵感应，几经酝酿讨论，最终将我们的园徽定稿为： 圆形即天圆地方，是对天人合一理念的追求。其中两个变形字母“SY”为＃＃市实验幼儿园的缩写，大海鸥隐喻教师，小海鸥隐喻儿童，由“sy”和两个几何形体组成的图案隐喻帆船，象征着＃＃市实验幼儿园的老师们带领着天真烂漫的孩子，满载着希望，在浩瀚的大海上，向着梦想的彼岸，乘风破浪，勇往直前。 （三）天人合一，回归自然的外观形象 品牌应该有深厚的文化底蕴，大海赋予我们博大的胸怀，“海纳百川”就是对我们最高的要求。“开放教育”主张博大的教育之爱，这就是大海赋予我们的灵性和智慧，园徽彰显的是海文化，我们的外观形象同样应该以海文化来定位。 我们将门头设计成以橘红色为主的三角旗状的外观形象，在旗面的中间标识“＃＃实验幼儿园”的白色字样。橘红色的旗帜寓意着不断地探索求新，引领时代潮流。 主体楼外墙图案设计仍以天蓝色为主色调，有白云、海鸥、绿色、深蓝色、黄色搭配形成整体。它倡导的理念同样是“天人合一”。底部的深
数据库性能优化之SQL语句优化一、问题的提出 在应用系统开发初期，由于开发数据库数据比较少，对于查询SQL语句，复杂视图的的编写等体会不出SQL语句各种写法的性能优劣，但是如果将应用系统提交实际应用后，随着数据库中数据的增加，系统的响应速度就成为目前系统需要解决的最主要的问题之一。系统优化中一个很重要的方面就是SQL语句的优化。对于海量数据，劣质SQL语句和优质SQL语句之间的速度差别可以达到上百倍，可见对于一个系统不是简单地能实现其功能就可，而是要写出高质量的SQL语句，提高系统的可用性。 在多数情况下，Oracle使用索引来更快地遍历表，优化器主要根据定义的索引来提高性能。但是，如果在SQL语句的where子句中写的SQL代码不合理，就会造成优化器删去索引而使用全表扫描，一般就这种SQL语句就是所谓的劣质SQL语句。在编写SQL语句时我们应清楚优化器根据何种原则来删除索引，这有助于写出高性能的SQL语句。 二、SQL语句编写注意问题 下面就某些SQL语句的where子句编写中需要注意的问题作详细介绍。在这些where子句中，即使某些列存在索引，但是由于编写了劣质的SQL，系统在运行该SQL语句时也不能使用该索引，而同样使用全表扫描，这就造成了响应速度的极大降低。
1. 操作符优化 (a) IN 操作符 用IN写出来的SQL的优点是比较容易写及清晰易懂，这比较适合现代软件开发的风格。但是用IN的SQL性能总是比较低的，从Oracle执行的步骤来分析用IN的SQL与不用IN的SQL有以下区别： ORACLE试图将其转换成多个表的连接，如果转换不成功则先执行IN里面的子查询，再查询外层的表记录，如果转换成功则直接采用多个表的连接方式查询。由此可见用IN的SQL至少多了一个转换的过程。一般的SQL都可以转换成功，但对于含有分组统计等方面的SQL就不能转换了。 推荐方案：在业务密集的SQL当中尽量不采用IN操作符，用EXISTS 方案代替。 (b) NOT IN操作符 此操作是强列不推荐使用的，因为它不能应用表的索引。 推荐方案：用NOT EXISTS 方案代替 (c) IS NULL 或IS NOT NULL操作（判断字段是否为空） 判断字段是否为空一般是不会应用索引的，因为索引是不索引空值的。不能用null作索引，任何包含null值的列都将不会被包含在索引中。即使索引有多列这样的情况下，只要这些列中有一列含有null，该列就会从索引中排除。也就是
我们要做到不但会写SQL,还要做到写出性能优良的SQL,以下为笔者学习、摘录、并汇总部分资料与大家分享！ （1）选择最有效率的表名顺序(只在基于规则的优化器中有效)：ORACLE 的解析器按照从右到左的顺序处理FROM子句中的表名，FROM子句中写 在最后的表(基础表 driving table)将被最先处理，在FROM子句中包含多个表的情况下,你必须选择记录条数最少的表作为基础表。如果有3个以上的表连接查询, 那就需要选择交叉表(intersection table)作为基础表, 交叉表是指那 个被其他表所引用的表. （2） WHERE子句中的连接顺序．： ORACLE采用自下而上的顺序解析WHERE子句,根据这个原理,表之间的连接必须 写在其他WHERE条件之前, 那些可以过滤掉最大数量记录的条件必须写在WHERE子句的末尾. （3） SELECT子句中避免使用‘ * ‘： ORACLE 在解析的过程中, 会将'*' 依次转换成所有的列名, 这个工作是通过查询数据字典完成的, 这意味着将耗费更多的时间 （4）减少访问数据库的次数： ORACLE在内部执行了许多工作: 解析SQL语句, 估算索引的利用率, 绑定变量 , 读数据块等； （5）在SQL*Plus , SQL*Forms和Pro*C中重新设置ARRAYSIZE参数, 可以增加每次数据库访问的检索数据量 ,建议值为200 （6）使用DECODE函数来减少处理时间： 使用DECODE函数可以避免重复扫描相同记录或重复连接相同的表. （7）整合简单,无关联的数据库访问： 如果你有几个简单的数据库查询语句,你可以把它们整合到一个查询中(即使它 们之间没有关系) （8）删除重复记录： 最高效的删除重复记录方法 ( 因为使用了ROWID)例子： DELETE FROM EMP E WHERE E.ROWID > (SELECT MIN(X.ROWID) FROM EMP X WHERE X.EMP_NO = E.EMP_NO); （9）用TRUNCATE替代DELETE： 当删除表中的记录时,在通常情况下, 回滚段(rollback segments ) 用来存放可以被恢复的信息. 如果你没有COMMIT事务,ORACLE会将数据恢复到删除之前 的状态(准确地说是恢复到执行删除命令之前的状况) 而当运用TRUNCATE时, 回滚段不再存放任何可被恢复的信息.当命令运行后,数据不能被恢复.因此很少的资源被调用,执行时间也会很短. (译者按: TRUNCATE只在删除全表适 用,TRUNCATE是DDL不是DML) （10）尽量多使用COMMIT： 只要有可能,在程序中尽量多使用COMMIT, 这样程序的性能得到提高,需求也 会因为COMMIT所释放的资源而减少: COMMIT所释放的资源: a. 回滚段上用于恢复数据的信息. b. 被程序语句获得的锁 c. redo log buffer 中的空间 d. ORACLE为管理上述3种资源中的内部花费