由于ODU命令比较多，特别是关键的unload命令比较复杂，本文将简单介绍几种场景下使用ODU进行数据恢复时，使用的命令序列。本文不会详细介绍每个命令的使用，详细的命令请参考本网站ODU页面下的链接。
场景1. 数据库不能启动，但是SYSTEM表空间中的数据字典是完整的。
- 生成数据字典：unload dict
- 列出用户: list user
- 列出用户下的所有表: list table username
- 恢复表: unload table username.tablename
- 也可以按用户恢复： unload user username
场景2. 表被TRUNCATE。
- OFFLINE表所在的表空间
- 生成数据字典：unload dict
- 显示表的段头：desc username.tablename
- 找到实际的data object id： dump datafile file# block block#
- 扫描数据：scan extent
- 恢复表：unload table username.tablename object object_id
UPDATE:
从3.0.7版本开始，恢复Truncate表更方便，只需要执行下面的步骤:
- OFFLINE表所在的表空间
- 生成数据字典：unload dict
- 扫描数据：scan extent
- 恢复表：unload table username.tablename object auto
场景3. 表被DROP。
- OFFLINE表所在的表空间
- 使用logminer从日志里面挖掘被drop掉的表其data object id，如果不能挖掘，按下面的场景4进行恢复。
- 扫描数据：scan extent
- 如果没有表结构信息，需要自动来判断：unload object data_object_id sample
- 恢复表：unload object data_object_id column coltype coltype...
场景4. 系统表空间损坏。
- 扫描数据：scan extent
- 搜索数据：unload object all sample
- 从结果文件sample.txt查找需要的数据
- 恢复需要的表：unload object data_object_id column coltype coltype...
场景5. 表中数据被DELETE。
- 将参数unload_deleted设置为YES
- 生成数据字典：unload dict
- 恢复表: unload table username.tablename
manual, ODU
我们经常使用Sql Trace和10046 event来诊断Oracle数据库性能问题。而level超过1的10046事件通常称为extended sql trace，通常用于诊断确定的单个SQL、存储过程或会话的性能问题，具有如下的几个优点：
- 可以得到SQL执行时实际的执行计划。
- 可以得到SQL执行时所花时间的具体分布，CPU消耗了多长时间，多块读消耗了多长时间等等。
- 可以得到SQL执行时的各种与性能相关的统计数据，逻辑读、物理读、fetch次数、parse次数等等。
- 不仅能够用于性能测试，同时能够用于诊断正在执行的SQL或存储过程的性能。
- 有很多的工具用于格式化生成的trace文件，除了Oracle自带的TKPROF、Metalink Note 224270.1 Trace Analyzer，以及第三方的免费工具如orasrp，《Troubleshooting Oracle Performance》作者开发的TVD$XTAT，甚至还有商业化的软件Hotsos Profiler等。
不过前段时间在用10046事件诊断一个性能问题的时候，却让生成的结果误导了。后来仔细检查发现，在会话开启sql trace的情况下，SQL语句会重新解析，导致开启sql trace之后与开启之前相比，执行计划可能发生了变化，导致sql trace的结果不能真实地反映会话执行SQL的情况，在分析时容易发生偏差。
下面是一个测试：
测试的环境是Oracle 10.2.0.1 for Windows，不过前面提到的案例，是发生在Oracle 9i下的，所以9i和10g都有这个问题，而11g目前还没有测试过，有兴趣的朋友可以在11g上进行测试。
首先创建一个sql文件，内容为：
select /*+ testsql */ sum(value) from t1 where flag=:v_flag;
创建一个列上数据有倾斜的表：
SQL> create table t1 (value number ,flag number,pad varchar2(2000));
表已创建。
SQL> insert into t1 select rownum,mod(rownum,2000),lpad('x',1000,'x') from dba_objects;
已创建49796行。
SQL> commit;
提交完成。
SQL> insert into t1 select rownum,3000,lpad('x',1000,'x') from dba_objects where rownum<=10000;
已创建10000行。
SQL> commit;
提交完成。
SQL> create index t1_idx on t1(flag);
索引已创建。
SQL> exec dbms_stats.gather_table_stats(ownname=>user,tabname=>'T1',cascade=>true,method_opt=>'for all indexed columns');
PL/SQL 过程已成功完成。
SQL> select column_name,num_distinct,num_buckets from user_tab_columns where table_name='T1';
COLUMN_NAME NUM_DISTINCT NUM_BUCKETS
------------------------------ ------------ -----------
VALUE
FLAG 2030 75
PAD
在创建的测试表中，FLAG列有2001个不同的值，其中，0-1999之间每个值约为25个，而有一个特殊的值3000，有10000个。收集统计信息时，在FLAG列上收集了直方图。
下面运行test.sql：
SQL> var v_flag number;
SQL> exec :v_flag:=3000;
SQL> set autot on stat
SQL> @test
SUM(VALUE)
----------
50005000
统计信息
-------------------------------------------------------
0 recursive calls
0 db block gets
8575 consistent gets
0 physical reads
0 redo size
412 bytes sent via SQL*Net to client
384 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
我们来看看SQL的执行计划：
Read the rest of this entry
performance, trace
其实这是一篇技术文章。
最近比较忙，通宵干活也逐渐平常起来，BLOG更新也少了，其实想写的东西挺多的。
闲话少扯，切入正题。
■ Poor connection management can cause poor response times and unreliable
systems.
----摘自《Oracle Database Performance Tuning Guide 10g Release 2 (10.2)》”Understanding Scalability--Factors Preventing Scalability“一节.
■ Good Database Connection Management
Connecting to the database is an expensive operation that is highly unscalable.
Therefore, the number of concurrent connections to the database should be
minimized as much as possible. A simple system, where a user connects at
application initialization, is ideal. However, in a Web-based or multitiered
application, where application servers are used to multiplex database connections
to users, this can be difficult. With these types of applications, design efforts
should ensure that database connections are pooled and are not reestablished for
each user request.
----摘自《Oracle Database Performance Tuning Guide 10g Release 2 (10.2)》”Application Design Principles--SQL Execution Efficiency“一节.
1. Bad Connection Management
The application connects and disconnects for each database interaction. This
problem is common with stateless middleware in application servers. It has over
two orders of magnitude impact on performance, and is totally unscalable.
----摘自《Oracle Database Performance Tuning Guide 10g Release 2 (10.2)》”The Oracle Performance Improvement Method--Top Ten Mistakes Found in Oracle Systems“一节.
以上的内容，全部是关于连接管理（connection management）的，也就是应用系统连接到数据库的方式，其中之一就是，是使用长连接还是短连接。其实在以前，我看到如上所述的内容，并没有引起重视的，甚至可以说是不以为然。因为现在的使用Oracle数据库的大型的高并发的应用系统，在连接数据库上，一般都是使用了连接池，连接管理基本上都不存在什么问题。
然而事实证明，我错了。就在前不久，遇上一套系统，Oracle数据库的会话数保持在4000以上的高并发系统，一个关键的应用居然用的短连接。不幸的是，这个应用连接数据库的速率非常的快，而创建一个数据库的连接耗时非常的长，闲时都在150ms以上。在业务高峰期，连接数据库的排队已经非常高，Listener已经不能够及时处理连接请求，连接数据库通常需要1s以上，甚至数秒，严重影响了系统的性能。就算使用两个Listener都已经承受不了压力。
解决这个问题的根本办法还是修改应用，使用连接池。
看起来真是“只有想不到，没有做不到”，一切皆有可能啊。
performance