如果想以中文显示，则需要修改一些配置文件。
包括三个目录：
$ORACLE_HOME/jdk/jre/lib
$ORACLE_HOME/jre/1.4.2/lib
$ORACLE_HOME/javavm/lib/ojvmfonts
这三个目录下都有 font.properties 和 font.properties.zh_CN.Redhat 文件。
如果DB中没有找够三个目录，那只要修改找到的目录下面的就可以啦。

font.properties文件备份：
cp $ORACLE_HOME/jdk/jre/lib/font.properties $ORACLE_HOME/jdk/jre/lib/font.properties.bak
cp $ORACLE_HOME/jre/1.4.2/lib/font.properties $ORACLE_HOME/jre/1.4.2/lib/font.properties.bak
cp $ORACLE_HOME/javavm/lib/ojvmfonts/font.properties $ORACLE_HOME/javavm/lib/ojvmfonts/font.properties.bak

用font.properties.zh_CN.Redhat替换font.properties
cp $ORACLE_HOME/jdk/jre/lib/font.properties.zh_CN.Redhat $ORACLE_HOME/jdk/jre/lib/font.properties
cp $ORACLE_HOME/jre/1.4.2/lib/font.properties.zh_CN.Redhat $ORACLE_HOME/jre/1.4.2/lib/font.properties
cp $ORACLE_HOME/javavm/lib/ojvmfonts/font.properties.zh_CN.Redhat $ORACLE_HOME/javavm/lib/ojvmfonts/font.properties

修改font.properties最后一行
filename.-misc-zysong18030-medium-r-normal–*-%d-*-*-c-*-iso10646-1=/usr/share/fonts/zh_CN/TrueType/zysong.ttf
我们发现字体文件 /usr/share/fonts/zh_CN/TrueType/uming.ttf 根本是不存在的，有些系统可以直接做一个链接文件链接到系统存在的字体文件就可以解决掉乱码问题，但是我的系统做了链接以后还是没能解决，只好修改三个目录下修改后的 font.properties 文件的最后一行为如下内容：
filename.-misc-zysong18030-medium-r-normal–*-%d-*-*-c-*-iso10646-1=/usr/share/fonts/chinese/TrueType/uming.ttf

删除OEM缓存文件
rm -rf $ORACLE_HOME/oc4j/j2ee/oc4j_applications/applications/em/em/cabo/images/cache/zhs/*

重启OEM
emctl stop dbconsole
emctl start dbconsole

说明：
修改的前提必须保证系统里存在这个字体文件
ls /usr/share/fonts/chinese/TrueType/fonts.dir fonts.scale ukai.ttf uming.ttf
自己可以找本系统对应的中文字体文件。

来自Thomas Kyte 《Oracle9i/10g/11g编程艺术》 12章节中.由于long的操作限制,那么在操作long之前可以将该类型的结果转换为varchar2然后再使用,long_help.substr_of的基本意思是将long结果的的前4000字节转换为varchar2类型.如果long的数据超过了4000字节,那么可以将循环调用此函数

create or replace package long_help
authid current_user
as
function substr_of
( p_query in varchar2,
p_from  in number,
p_for   in number,
p_name1 in varchar2 default NULL,
p_bind1 in varchar2 default NULL,
p_name2 in varchar2 default NULL,
p_bind2 in varchar2 default NULL,
p_name3 in varchar2 default NULL,
p_bind3 in varchar2 default NULL,
p_name4 in varchar2 default NULL,
p_bind4 in varchar2 default NULL )
return varchar2;
end;

create or replace package body long_help
as
    g_cursor number := dbms_sql.open_cursor;
    g_query  varchar2(32765);
procedure bind_variable( p_name in varchar2, p_value in varchar2 )
is
begin
    if ( p_name is not null )
    then
        dbms_sql.bind_variable( g_cursor, p_name, p_value );
    end if;
end;

function substr_of
( p_query in varchar2,
  p_from  in number,
  p_for   in number,
  p_name1 in varchar2 default NULL,
  p_bind1 in varchar2 default NULL,
  p_name2 in varchar2 default NULL,
  p_bind2 in varchar2 default NULL,
  p_name3 in varchar2 default NULL,
  p_bind3 in varchar2 default NULL,
  p_name4 in varchar2 default NULL,
  p_bind4 in varchar2 default NULL )
return varchar2
as
    l_buffer       varchar2(4000);
    l_buffer_len   number;
begin
    if ( nvl(p_from,0) <= 0 )
    then
        raise_application_error
        (-20002, 'From must be >= 1 (positive numbers)' );
    end if;
    if ( nvl(p_for,0) not between 1 and 4000 )
    then
        raise_application_error
        (-20003, 'For must be between 1 and 4000' );
    end if;
    if ( p_query <> g_query or g_query is NULL )
    then
        if ( upper(trim(nvl(p_query,'x'))) not like 'SELECT%')
        then
            raise_application_error
            (-20001, 'This must be a select only' );
        end if;
        dbms_sql.parse( g_cursor, p_query, dbms_sql.native );
        g_query := p_query;
    end if;
    bind_variable( p_name1, p_bind1 );
    bind_variable( p_name2, p_bind2 );
    bind_variable( p_name3, p_bind3 );
    bind_variable( p_name4, p_bind4 );
    dbms_sql.define_column_long(g_cursor, 1);
    if (dbms_sql.execute_and_fetch(g_cursor)>0)
    then
        dbms_sql.column_value_long
        (g_cursor, 1, p_for, p_from-1,
         l_buffer, l_buffer_len );
    end if;
    return l_buffer;
end substr_of;
end;

使用方法:查询DBA_TAB_PARTITIONS中的HIGH_VALUE

SELECT *
  FROM (SELECT TABLE_OWNER,
                TABLE_NAME,
                PARTITION_NAME,
                LONG_HELP.SUBSTR_OF('SELECT HIGH_VALUE
FROM   DBA_TAB_PARTITIONS WHERE TABLE_OWNER=:TABLE_OWNER 
AND TABLE_NAME=:TABLE_NAME
AND PARTITION_NAME=:PARTITION_NAME',
                                     1,
                                     4000,
                                     'TABLE_OWNER',
                                     TABLE_OWNER,
                                     'TABLE_NAME',
                                     TABLE_NAME,
                                     'PARTITION_NAME',
                                     PARTITION_NAME) HIGH_VALUE
           FROM DBA_TAB_PARTITIONS);

前几天被人问到聚簇因子被问住了，所以今天做了个试验说明这个问题
1、准备试验条件

--创建表t_1
CREATE TABLE t_1
AS
SELECT ROWNUM rn,a.* FROM all_objects a ORDER BY object_name DESC;

--创建t_1表关于rownum索引
CREATE INDEX ind_t_1 ON t_1(rn);

--创建表表t_2
CREATE TABLE t_2
AS
SELECT * FROM (
SELECT ROWNUM rn,a.* FROM all_objects a ) ORDER BY rn ASC;

--创建t_2表关于rownum索引
CREATE INDEX ind_t_2 ON t_2(rn);

--分析两张表及其索引
EXEC DBMS_STATS.gather_table_stats(USER, 'T_1');
EXEC DBMS_STATS.gather_table_stats(USER, 'T_2');
EXEC DBMS_STATS.gather_index_stats(USER, 'IND_T_1');
EXEC DBMS_STATS.gather_index_stats(USER, 'IND_T_2');

--说明：两个表的区别就是t_2表中的rn是有序的，刚刚建立t_2表的索引一致

2、执行查询操作
SQL> set autot traceonly stat;
SQL> SELECT * FROM t_1 WHERE rn BETWEEN 100 AND 120;

已选择21行。

统计信息
———————————————————-
0 recursive calls
0 db block gets
17 consistent gets
0 physical reads
0 redo size
1807 bytes sent via SQL*Net to client
357 bytes received via SQL*Net from client
3 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
21 rows processed

SQL> SELECT * FROM t_2 WHERE rn BETWEEN 100 AND 120;

已选择21行。

统计信息
———————————————————-
0 recursive calls
0 db block gets
7 consistent gets
0 physical reads
0 redo size
1807 bytes sent via SQL*Net to client
357 bytes received via SQL*Net from client
3 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
21 rows processed

3、观察试验结果
通过执行统计信息观察，t_1表的查询一致读是17，而t_2表的一致读只有7，尽然t_1的一致读尽然是t_2的2倍还多，是不是有点奇怪，同样的表结构，同样的数据（t_2多两条数据）

4、分析原因
通过查询聚簇因子发现，两个表的聚簇因子差别很大，基于rn的索引在rn是顺序排列的表中，clustering_factor的值相差很大。
在表中数据有时候属于无序状态，这个时候的CLUSTERING_FACTOR比较接近NUM_ROWS，说明如 果扫描整个表，每次都要根据Index来读取相应行的RowID，这个时候的IO操作很多，自然检索时间会比较长。如果数据有序的 话，CLUSTERING_FACTOR比较接近BLOCKS，说明相邻的数据在一个块中，减少了IO操作数量，自然检索时间会大大降低。