如果想以中文显示，则需要修改一些配置文件。
包括三个目录：
$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操作数量，自然检索时间会大大降低。

当一个数据块读入sga区，相应的buffer header会被放置到hash列表上,我们称其这hash chains,chain在中文的意为链条或串的意思，表达就是关连性.如果一个进程想访问或修改hash chain上的block,它首先要获得”cache buffers chains” latch。
原因一：低效率的SQL语句（主要体现在逻辑读过高）
cache buffers chains latch很大程度与逻辑读有关，所以要观注v$sql中BUFFER_GETS/EXECUTIONS大的语句。
同时每一个逻辑读需要一个latch get 操作及一个cpu操作，这样的sql也会很耗cpu资源。
原因二：热块（访问过于频繁）
找出热点块方法一：

--找出p1raw
select p1,p1raw from v$session_wait where event='latch: cache buffers chains';
--找到对象
SELECT /*+ RULE */
 E.OWNER || '.' || E.SEGMENT_NAME SEGMENT_NAME,
 E.PARTITION_NAME,
 E.EXTENT_ID EXTENT#,
 X.DBABLK - E.BLOCK_ID + 1 BLOCK#,
 X.TCH,
 L.CHILD#
  FROM SYS.V$LATCH_CHILDREN L, SYS.X$BH X, SYS.DBA_EXTENTS E
 WHERE X.HLADDR = '00000002576EE018'--p1raw
   AND E.FILE_ID = X.FILE#
   AND X.HLADDR = L.ADDR
   AND X.DBABLK BETWEEN E.BLOCK_ID AND E.BLOCK_ID + E.BLOCKS - 1
 ORDER BY X.TCH DESC;

找出热点块方法二：

--直接找出热点块
SELECT OBJECT_NAME, SUBOBJECT_NAME
  FROM DBA_OBJECTS
 WHERE DATA_OBJECT_ID IN
       (SELECT DATA_OBJECT_ID
          FROM (SELECT OBJ DATA_OBJECT_ID, FILE#, DBABLK, CLASS, STATE, TCH
                  FROM X$BH
                 WHERE HLADDR IN (SELECT ADDR
                                    FROM (SELECT ADDR
                                            FROM V$LATCH_CHILDREN
                                           ORDER BY (GETS + MISSES + SLEEPS) DESC)
                                   WHERE ROWNUM < 10)
                 ORDER BY TCH DESC)
         WHERE ROWNUM < 10);

LSNRCTL> change_password
Old password:
New password:
Reenter new password:
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=ecp-uc-db1)(PORT=1521)))
Password changed for LISTENER
The command completed successfully
LSNRCTL> set password
Password:
The command completed successfully
LSNRCTL> save_config
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=ecp-uc-db1)(PORT=1521)))
Saved LISTENER configuration parameters.
Listener Parameter File /opt/oracle/product/10.2.0/db_1/network/admin/listener.ora
Old Parameter File /opt/oracle/product/10.2.0/db_1/network/admin/listener.bak
The command completed successfully
[oracle@ecp-uc-db1 admin]$ cat listener.ora
#—-ADDED BY TNSLSNR 10-JUN-2011 18:13:24—
PASSWORDS_LISTENER = 6D7AA003392C436A
#——————————————–
note：10g数据库上需要上添加（重启监听）
LOCAL_OS_AUTHENTICATION_LISTENER = OFF
1、添加LOCAL_OS_AUTHENTICATION_LISTENER = OFF之前
Security ON: Password or Local OS Authentication
2、添加LOCAL_OS_AUTHENTICATION_LISTENER = OFF之后
Security ON: Password
LSNRCTL> status
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=ecp-uc-db1)(PORT=1521)))
TNS-01169: The listener has not recognized the password
LSNRCTL> stop
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=ecp-uc-db1)(PORT=1521)))
TNS-01169: The listener has not recognized the password
LSNRCTL> set password 123456
The command completed successfully
LSNRCTL> status
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=ecp-uc-db1)(PORT=1521)))
STATUS of the LISTENER
————————
Alias LISTENER
Version TNSLSNR for Linux: Version 10.2.0.4.0 – Production
Start Date 10-JUN-2011 18:15:49
Uptime 0 days 0 hr. 1 min. 16 sec
Trace Level off
Security ON: Password
SNMP OFF
Listener Parameter File /opt/oracle/product/10.2.0/db_1/network/admin/listener.ora
Listener Log File /opt/oracle/product/10.2.0/db_1/network/log/listener.log
Listening Endpoints Summary…
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=ECP-UC-DB1)(PORT=1521)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC0)))
Services Summary…
Service “PLSExtProc” has 1 instance(s).
Instance “PLSExtProc”, status UNKNOWN, has 1 handler(s) for this service…
Service “ecp” has 1 instance(s).
Instance “ecp”, status READY, has 1 handler(s) for this service…
Service “ecpXDB” has 1 instance(s).
Instance “ecp”, status READY, has 1 handler(s) for this service…
Service “ecp_XPT” has 1 instance(s).
Instance “ecp”, status READY, has 1 handler(s) for this service…
The command completed successfully

--DBMS_SCHEDULER 运行信息
select job_name,state,enabled,to_char(last_start_date,'yyyy-mm-dd hh24:mi:ss'), schedule_name
from dba_scheduler_jobs;
--DBMS_SCHEDULER运行成功与否信息
SELECT log_id, job_name, status,TO_CHAR(ACTUAL_START_DATE,'yyyy-mm-dd HH24:MI:ss') start_date,
           TO_CHAR (log_date, 'yyyy-mm-dd HH24:MI:ss') log_date
      FROM dba_scheduler_job_run_details
     WHERE job_name = 'GATHER_STATS_JOB'
     order by 4 DESC;
--查询执行时间情况
select t1.window_name,t1.repeat_interval,t1.duration from dba_scheduler_windows t1,dba_scheduler_wingroup_members t2
 where t1.window_name=t2.window_name and t2.window_group_name='MAINTENANCE_WINDOW_GROUP';
--修改执行时间
begin
dbms_scheduler.set_attribute('WEEKEND_WINDOW','REPEAT_INTERVAL','freq=daily;byday=SAT;byhour=0;byminute=0;bysecond=0');
dbms_scheduler.set_attribute('WEEKEND_WINDOW','DURATION','+002 00:00:00');
end;

一般来说，调优的第一手资料，很可能就是典型业务期的一个statspack报告，那么如何根据statspack报告来判断是哪些SQL消耗了最多的系统资源?哪些SQL是最需要调整的呢?这里给出了一个大致的优化思路。当然，思路是死的，人是活的，优化也需要随需应变。
　　一般来说，需要关注下面四种Top SQL
　　消耗最多CPU的(逻辑IO过多)
　　导致过多物理I/O的
　　执行次数较频繁的
　　执行时间较长的
　　我们知道，一个语句的响应时间有个很著名的公式：
　　响应时间=服务时间+等待时间
　　其中服务时间就是CPU为执行该语句花费的时间。
　　服务时间=分析时间+递归时间+执行时间
　　分析时间是CPU用于分析语句的时间，递归时间是CPU用于语句的递归SQL的时间，剩下的则就是CPU用于执行语句的真正时间了。
　　那么，上面的这些时间信息从哪里来的?Oracle提供的系统统计信息中就有部分的时间统计信息：
　　服务时间=CPU used by this session
　　分析时间=parse time cpu
　　递归时间=recursive cpu usage
　　那么，执行时间就可以根据上面三个统计信息计算得出：
　　执行时间=CPU used by this session – parse time cpu – recursive cpu usage
　　如果执行时间在整个响应时间中占较大的比例，那么下一步就是找出那些造成了最多逻辑IO的SQL语句，可以从statspack报告的SQL ordered by Gets部分找到。
　　如果分析时间在整个响应时间中占较大的比例，那么下一步就是查找哪些SQL分析过多，这在statspack报告中在SQL ordered by Parse Calls中列出。
　　如果等待时间在整个响应时间中占较大的比例，并且主要是块读取相关的等待时，下一步就是找出哪些SQL造成了过多的物理读，可以查看statspack报告中的SQL ordered by Reads部分。
　　那么，根据上面列出的一个简单的原则，我们需要关注三个关于CPU时间的统计信息: CPU used by this session, parse time cpu和recursive cpu usage，以及top5等待事件中和IO相关的等待时间。如果是其他的一些等待事件出现在Top5中，那么可能需要根据不同的等待事件来分析原因了。然后优先调优时间消耗最多的相关SQL。
　　除了上面的SQL ordered by Gets(逻辑IO最多)，SQL ordered by Parse Calls(软解析过多)，SQL ordered by Reads(物理IO过多)，statspack还按照其他的一些方式列出了Top SQL，这些Top SQL在某些情况下都是需要给予特别关注的。比如：
　　SQL ordered by Executions 执行次数超过100的
　　SQL ordered by Sharable Memory 占用library cache超过1M的
　　SQL ordered by Version Count 子cursor超过20的
　　如果没有statspack，那么根据v$sysstat/v$sesstat中的统计信息，结合v$sql/v$sqlarea，一样可以得到相关的SQL。
　　v$sql对于每一个子cursor都有一行统计记录，而v$sqlarea则对同一个父cursor只有一行统计记录，也就是v$sqlarea是对v$sql按照父cursor进行group by后的一个结果。这两个视图中都有诸如buffer_gets,parse_calls,disk_reads,,executions,sharable_mem等列，和上面提到的statspack中列出Top SQL的条件对应。

DEADLOCK DETECTED ( ORA-00060 )
[Transaction Deadlock]
The following deadlock is not an ORACLE error. It is a
deadlock due to user error in the design of an application
or from issuing incorrect ad-hoc SQL. The following
information may aid in determining the deadlock:
Deadlock graph:
———Blocker(s)——– ———Waiter(s)———
Resource Name process session holds waits process session holds waits
TX-000a0002-00005420 68 440 X 65 496 S
TX-0001001b-00002b19 65 496 X 68 440 S
session 440: DID 0001-0044-000A2346 session 496: DID 0001-0041-000CBA54
session 496: DID 0001-0041-000CBA54 session 440: DID 0001-0044-000A2346
Rows waited on:
Session 496: obj – rowid = 00014282 – AAAUKCAAMAAAEZrAAA
(dictionary objn – 82562, file – 12, block – 18027, slot – 0)
Session 440: no row
Information on the OTHER waiting sessions:
Session 496:
pid=65 serial=58006 audsid=1896040 user: 88/VAS
O/S info: user: web_meg, term: unknown, ospid: , machine: ezg-web1
program: JDBC Thin Client
application name: JDBC Thin Client, hash value=2546894660
Current SQL Statement:
insert into TAB_XN_CONTENT_TEMP (key,content) values (:1,:2)
End of information on OTHER waiting sessions.
Current SQL statement for this session:
insert into TAB_XN_CONTENT_TEMP (key,content) values (:1,:2)
我一看到这个错误，有点不明白，oracle 的insert操作竟然导致表被锁，然后查找些资料终于有了眉目：
当ORACLE执行insert等DML语句时，会首先自动在所要操作的表上申请一个TM锁，当TM锁获得后，再自动申请TX类型的锁。当两个或多个会话在表的同一条记录上执行DML语言时，第一个会话在记录上加锁，其它的会话处于等待状态，一直到第一个会话提交后TX锁释放，其它的会话才可以加锁。考虑是因为两个insert语句同时试图向一个表中插入PK或unique值相同的数据，而造成其中会话被阻塞，等待其它会话提交或回滚，因而造成死锁。这种情况，只要其中任何一个session提交，另外一个就会报出ORA-00001：违反唯一性约束条件，死锁终止；或者其中一个session回滚，另外一个即可正常执行。
通过对这段话的理解，应该是一个会话插入了一条记录未提交，然后另外一个会话继续插入主键或者唯一索引列相同的记录，导致死锁的发生。
环境模拟：
在会话1中执行下面语句
CREATE TABLE t1(ID NUMBER);
ALTER TABLE t1 ADD primary key (ID);
INSERT INTO t1 VALUES(1);
INSERT INTO t1 VALUES(2);
然后在会话2中执行下面语句
INSERT INTO t1 VALUES(1);
INSERT INTO t1 VALUES(2);
在会话3中查询死锁情况
通过上面模拟，重现了insert死锁现象，说明红色标注出来的文字的正确性

主要是使用DBMS_REDEFINITION包实现，我这里主要是实现一个由普通表转为分区表的处理
在线重定义的表自行验证，看该表是否可以重定义
EXEC DBMS_REDEFINITION.CAN_REDEF_TABLE(user, ‘T_DEF’, DBMS_REDEFINITION.CONS_USE_PK);
–如果T_DEF表无主键，请添加上，不然会爆如下错误
begin DBMS_REDEFINITION.CAN_REDEF_TABLE(user, ‘T_DEF’, DBMS_REDEFINITION.CONS_USE_PK); end;
ORA-12089: cannot online redefine table “CHF”.”T_DEF” with no primary key
ORA-06512: at “SYS.DBMS_REDEFINITION”, line 137
ORA-06512: at “SYS.DBMS_REDEFINITION”, line 1479
ORA-06512: at line 2
执行表的在线重定义
EXEC DBMS_REDEFINITION.START_REDEF_TABLE(USER, ‘T_DEF’, ‘T_DEF_NEW’);
同步数据
exec dbms_redefinition.sync_interim_table(USER, ‘T_DEF’, ‘T_DEF_NEW’);
执行结束在线定义过程
EXEC DBMS_REDEFINITION.FINISH_REDEF_TABLE(user, ‘T_DEF’, ‘T_DEF_NEW’);
说明：
1、和使用交换分区的办法处理，这个是在线的，不用停业务
2、在线重定义处理后，原表中的数据不会被清空，可能需要额外的空间
3、处理速度没有直接使用交互分区快

oracle权限体系中有个default role，比较难以理解。下面用实例说明一下作用。
我们可以给某个用户分配一些角色，比如role r1,r2,r3,r4，而其中可以将某些角色比如r1设置为default role，其他的不设置成default role，这样，当该用户登录时，自动具有default role中所包含的权限，其他的角色所具有的权限要通过set role 角色来获得。
下面我们举个例子：
（1）sys用户作为sysdba登录，创建4个角色：
create role r1;
create role r2 identified by r2;
create role r3 identified by r3;
create role r4 identified by r4;
（2）sys用户赋予这四个角色对应的权限：
grant create session to r1;
grant select on hr.test to r2;（这里hr.test是我新创建的一个表，里面有ID和name两列）
grant update(name) on hr.test to r3;
grant insert on hr.test to r3;
grant delete on hr.test to r4;
（3）sys用户创建一个用户u3
create user u3 identified by u3;
（4）将角色r1,r2,r3,r4赋予用户u3
grant r1,r2,r3,r4 to u3;
在修改用户u3的默认角色前，r1,r2,r3,r4 角色均为u3的 default role，以u3用户登录，查询、增删改hr.test，都没有问题。
（5）现在sys用户修改用户u3的default role，仅将r1作为u3的默认角色：
alter user u3 default role r1; –此时将覆盖原来的设置，u3 的default role =r1，仅仅有登录权限。
（6）用户u3 log off ，然后再log on，进去后发现，
查询、增删改hr.test都不能进行。
（7） 用户自己打开role权限
set role r2 identified by r2;
这时执行 select * from hr.test,发现没有问题。增删改不行。
将对应的角色打开：
set role r3 identified by r3;
此时修改和插入记录没有问题，但是select * from hr.test 确发现不行了。证明此时用户所属的角色仅仅是默认角色r1，和刚刚打开的角色r3，而r2被set role r3 identified by r3;覆盖掉了。
那要同时有r2，r3，r4的权限怎么办呢？
set role r2 identified by r2,r3 identified by r3,r4 identified by r4。此时就同时对hr.test可以进行查询，增删改了。
不过set role 的效果是临时的，只是当前session有效，其他的session无效，当结束当前session后再登录，又只有default role 的权限了。