Oracle, Odbc and DB2-CLI Template Library, Version 4.0

Frequently Asked Questions

Please, send your questions and comments to skuchin@ispwest.com, skuchin@gmail.com

Q. OTL: how does OTL handle NULLs?

• Call otl_stream::is_null() to check whether the value that was just read from the stream is NULL or not.
• Use template class otl_value<T>.
• If there is a need to set the output variable to a value when NULL is fetched (by default, OTL does not set the output byffer to any value in the case of NULL), the following #defines could be enabled:
  • OTL_DEFAULT_NUMERIC_NULL_TO_VAL
  • OTL_DEFAULT_DATETIME_NULL_TO_VAL
  • OTL_DEFAULT_STRING_NULL_TO_VAL
  • OTL_DEFAULT_CHAR_NULL_TO_VAL
  • OTL_USER_DEFINED_STRING_CLASS_DEFAULT_NULL_TO_VAL

Q. OTL: is it thread safe?

OTL does not set any mutex locks or critical sections. In case if each thread has its own otl_connect object, there is no need for mutex locks. In case of sharable connections, it is the devloper’s responsibility to wrap up OTL calls with mutexes. In general, database APIs do not guarantee thread safety. otl_connect::otl_initialize passes a flag to the underlying database API only to let the API know that the progam is running in a multi-threaded mode.

Q. OTL: does it work with SQLite?

Yes, it does. OTL/ODBC works with SQLite. See the following examples for detail.

Q. OTL: does it support Oracle 10g?

The answer is Yes. Use #define OTL_ORA10G, OTL_ORA10G_R2

Q. OTL: does it work with SAP DB?

Yes, it does. OTL/ODBC works with SAP DB. Fore more detail, see OTL examples for SAP DB.

Q. OTL: does it support CLOBs/BLOBs in PL/SQL?

The answer is: it depends. You need to keep in mind that “CLOB/BLOB” as a PL/SQL datatype is a locator of a large object, not a value. That is, the object itself needs to be created first, its locator needs to be retrieved from the database into C++, and only then the locator can be passed into PL/SQL. Also, see code example 378.

Q. OTL: does it support Unicode?

The answer is Yes. See OTL examples and the manual.

Q. OTL: does it support Oracle 9i?

The answer is Yes. Starting with version 4.0.0, OTL introduces #define OTL_ORA9I that is dedicated to Oracle 9i. In OTL 4.0.0 itself, it’s not much more than a synonym for OTL_ORA8I, but in subsequent releases, when OTL starts using OCI9 specific features, only OTL_ORA9I should be used. See “what’s new in OTL 4” for more detail.

Q. OTL: can it work with Interbase 6.x?

The answer is Yes. Starting with version 4.0.0, OTL supports an Open Source ODBC driver for Interbase. See “what’s new in OTL 4” for more detail.

Q. OTL: can it work with PostgreSQL 7.x?

The answer is Yes. Starting with version 4.0.0, OTL supports PostgreSQL via ODBC. See “what’s new in OTL 4” for more detail.

Q. OTL: can it work with DB2, Call Level Interface (CLI)?

The answer is Yes. Starting with version 3.2.7, there is a new flavor of OTL: OTL/DB2-CLI. OTL/DB2-CLI uses DB2′s native database API: the Call Level Interface. DB2-CLI is 99.5% compatible with the ODBC 3.x specification, plus extensions. The OTL header file #includes CLI’s native header files and can be used with DB2-CLI’s native object libraries in Windows or Unix (primarily AIX) platforms.

Q. OTL/ODBC: can it work with MyODBC/MySQL?

The answer is Yes. Starting with version 3.2.4, OTL/ODBC is compatible with MyODBC, and the following #define was introduced to do just that: #define OTL_ODBC_MYSQL. For more detail see also MyODBC for MySQLThe new #define turns off transactional ODBC function calls, since MySQL does not support transactions [yet].

Q. OTL/OCI8 and XA-connectivity: can they work together?

The answer is Yes. When an XA type connection is established, xaoEnv() and xaoSvcCtx() functions need to be invoked in order to get OCI8 compatible environment and service context handles. After that, otl_connect::rlogon() can be called to create an OTL connection from the handles. It is the same rlogon() that is used with Pro*C 8.x. How to use this type of rlogon() function, see example 59 for more detail.

Q. Are C++ strings (std::string) supported, and how is OTL integrated with the Standard Template Library (STL)?

OTL 3.2.0 and higher support std::strings (see examples 72, 73, 74). Also, OTL supports STL-compliant stream iterators: otl_input_iterator, otl_output_iterator.

Q. What major C++ compilers are supported, anyway?

• Sun C++ Workshop 5.x/6.0, Forte C++ (Sun C++ WS 6.1 and higher)
• GNU C++ 2.9x.x, 3.0.x, 3.1.x, 3.2.x., 3.3.x, 3.4.x, 4.0.x
• VC++ 6.0, VC++ 7.1, VC++ 8.0
• HP ANSI C++ (aCC) 1.x
• AIX, xlC 4.x and higher
• C++ in OSF Alfa Unix and Oracle 7.3.4
• Borland C++ 5.x
• KAI C++ 3.x and higher (multi-platform)
• Intel C++ 7.0, 8.0 (Windows, Linux)

In order to complete the list, you are welcome to send me an email with the name of your C++ compiler, if it’s not already in the list.

Q. Is there a way to read / write large BLOBs without having to allocate large buffers in memory?

OTL 3.1.4 supports stream mode for Oracle 8 CLOBs/BLOBs. Fore more detail, see examples 56, 57.

Q. Is there a way to call a stored procedure which takes PL/SQL tables as arguments ?

OTL 3.1 supports PL/SQL table via otl_streams and special template data containers.Fore more detail, see examples 49, 50, 51, 52.

Q. Will you stick with email delivery of your code, or do you intend to put it on your website later ?

From now on, the OTL header file is available for download.

Q. What is different in behavior of Large Objects (LOBs) compared to other datatypes as far as NULLs are concerned?

For more detail, see “Large Objects and NULLs.”

Q. How to read/write date&time informarion from/to the otl_stream?

The answer is: use the otl_datetime data container, which was introduced in OTL 3.1.26. For more detail, se examples 38, 39, 40.
Bottom line: Oracle DATE, or, say, MS SQL Server DATETIME, can be read/written with the use of otl_datetime variables.

Q. How to get the rows processed count after the SQL statement is finished?

The direct_exec() function returns a long int value, which, if it is >= 0, it retunrs the rows processed count of the constant SQL statement.Also, otl_stream::get_rpc() returns a long int value, which is the rows processed count. The rows processed count is defined for INSERT, UPDATE, and DELETE statements. For any other SQL statement, PL/SQL block, or a stored procedure call, the count is always 0.

1)Library Cache的命中率:

.计算公式:Library Cache Hit Ratio = sum(pinhits) / sum(pins)

SQL>SELECT SUM(pinhits)/sum(pins)
FROM V$LIBRARYCACHE;

通常在98%以上，否则，需要要考虑加大共享池，绑定变量，修改cursor_sharing等参数。

2)计算共享池内存使用率:

SQL>SELECT (1 - ROUND(BYTES / (&TSP_IN_M * 1024 * 1024), 2)) * 100 || '%'
FROM V$SGASTAT
WHERE NAME = 'free memory' AND POOL = 'shared pool';

其中: &TSP_IN_M是你的总的共享池的SIZE(M)

共享池内存使用率，应该稳定在75%-90%间，太小浪费内存，太大则内存不足。

查询空闲的共享池内存:

SQL>SELECT * FROM V$SGASTAT
WHERE NAME = 'free memory' AND POOL = 'shared pool';

3)db buffer cache命中率:

计算公式:Hit ratio = 1 – [physical reads/(block gets + consistent gets)]

SQL>SELECT NAME, PHYSICAL_READS, DB_BLOCK_GETS, CONSISTENT_GETS,
1 - (PHYSICAL_READS / (DB_BLOCK_GETS + CONSISTENT_GETS)) "Hit Ratio"
FROM V$BUFFER_POOL_STATISTICS
WHERE NAME='DEFAULT';

通常应在90%以上，否则，需要调整,加大DB_CACHE_SIZE

另外一种计算命中率的方法(摘自ORACLE官方文档<<数据库性能优化>>):

命中率的计算公式为:

Hit Ratio = 1 - ((physical reads - physical reads direct - physical reads direct (lob)) / (db block gets +
consistent gets - physical reads direct - physical reads direct (lob))

分别代入上一查询中的结果值,就得出了Buffer cache的命中率

SQL>SELECT NAME, VALUE
FROM V$SYSSTAT
WHERE NAME IN('session logical reads',
'physical reads',
'physical reads direct',
'physical reads direct (lob)',
'db block gets', 'consistent gets');

4)数据缓冲区命中率：

SQL> select value from v$sysstat where name ='physical reads';
SQL> select value from v$sysstat where name ='physical reads direct';
SQL> select value from v$sysstat where name ='physical reads direct (lob)';
SQL> select value from v$sysstat where name ='consistent gets';
SQL> select value from v$sysstat where name = 'db block gets';

这里命中率的计算应该是

令 x = physical reads direct + physical reads direct (lob)

命中率 =100 – ( physical reads – x) / (consistent gets + db block gets – x)*100

通常如果发现命中率低于90%,则应该调整应用可可以考虑是否增大数据缓冲区

5)共享池的命中率：

SQL> select sum(pinhits-reloads)/sum(pins)*100 "hit radio" from v$librarycache;

假如共享池的命中率低于95%,就要考虑调整应用（通常是没使用bind var ）或者增加内存

6)计算在内存中排序的比率:

SQL>SELECT * FROM v$sysstat t WHERE NAME='sorts (memory)';—查询内存排序数
SQL>SELECT * FROM v$sysstat t WHERE NAME='sorts (disk)';—查询磁盘排序数
--caculate sort in memory ratio
SQL>SELECT round(&sort_in_memory/(&sort_in_memory+&sort_in_disk),4)*100||'%' FROM dual;

此比率越大越好,太小整要考虑调整,加大PGA

7)PGA的命中率:

计算公式:BP x 100 / (BP + EBP)

BP: bytes processed

EBP: extra bytes read/written

SQL>SELECT * FROM V$PGASTAT  WHERE NAME='cache hit percentage';

或者从OEM的图形界面中查看

我们可以查看一个视图以获取Oracle的建议值:

SQL>SELECT round(PGA_TARGET_FOR_ESTIMATE/1024/1024) target_mb,
ESTD_PGA_CACHE_HIT_PERCENTAGE cache_hit_perc,
ESTD_OVERALLOC_COUNT
FROM V$PGA_TARGET_ADVICE;
The output of this query might look like the following:
TARGET_MB  CACHE_HIT_PERC  ESTD_OVERALLOC_COUNT
----------           --------------        --------------------
   63              23                   367
  125              24                    30
  250              30                     3
  375              39                     0
  500              58                     0
  600              59                     0
  700              59                     0
  800              60                     0
  900              60                     0

在此例中:PGA至少要分配375M

我个人认为PGA命中率不应该低于50%

以下的SQL统计sql语句执行在三种模式的次数: optimal memory size, one-pass memory size, multi-pass memory size:

SQL>SELECT name profile, cnt, decode(total, 0, 0, round(cnt*100/total,4)) percentage
FROM (SELECT name, value cnt, (sum(value) over ()) total FROM V$SYSSTAT WHERE name like 'workarea exec%');

8)共享区字典缓存区命中率

计算公式：SUM(gets – getmisses – usage -fixed) / SUM(gets)

命中率应大于0.85

SQL>select sum(gets-getmisses-usage-fixed)/sum(gets)
from v$rowcache;

9)数据高速缓存区命中率

计算公式：1-(physical reads / (db block gets + consistent gets))

命中率应大于0.90最好

SQL>select name,value
from v$sysstat
where name in ('physical reads','db block gets','consistent gets');

10)共享区库缓存区命中率

计算公式：SUM(pins – reloads) / SUM(pins)

命中率应大于0.99

SQL>select sum(pins-reloads)/sum(pins)
from v$librarycache;

11)检测回滚段的争用

SUM(waits)值应小于SUM(gets)值的1%

SQL>select sum(gets),sum(waits),sum(waits)/sum(gets)
from v$rollstat;

12)检测回滚段收缩次数

SQL>select name,shrinks
from v$rollstat, v$rollname
where v$rollstat.usn = v$rollname.usn;
-----------------------------------------------------------------------------

几个常用的检查语句

1. 查找排序最多的SQL:

SQL>SELECT HASH_VALUE, SQL_TEXT, SORTS, EXECUTIONS
FROM V$SQLAREA
ORDER BY SORTS DESC;

2.查找磁盘读写最多的SQL:

SQL>SELECT * FROM
(SELECT sql_text,disk_reads "total disk" , executions "total exec",disk_reads/executions "disk/exec" FROM v$sql
WHERE executions>0 and is_obsolete='N' ORDER BY  4 desc)
WHERE ROWNUM<11 ;

3.查找工作量最大的SQL(实际上也是按磁盘读写来排序的):

SQL>select substr(to_char(s.pct, '99.00'), 2) || '%' load,s.executions executes,p.sql_text
from(select address,disk_reads,executions,pct,rank() over (order by disk_reads desc) ranking from
(select address,disk_reads,executions,100 * ratio_to_report(disk_reads) over () pct
from sys.v_$sql
 where command_type != 47)
where disk_reads > 50 * executions) s,sys.v_$sqltext p
 where s.ranking <= 5 and p.address = s.address
order by 1, s.address, p.piece;

4. 用下列SQL工具找出低效SQL:

SQL>select executions,disk_reads,buffer_gets,round((buffer_gets-disk_reads)/buffer_gets,2) Hit_radio,round(disk_reads/executions,2) reads_per_run,sql_text
From v$sqlarea
Where executions>0 and buffer_gets >0 and (buffer_gets-disk_reads)/buffer_gets<0.8
Order by 4 desc;

5、根据sid查看对应连接正在运行的sql

SQL>select /*+ push_subq */command_type,sql_text,sharable_mem,persistent_mem,
runtime_mem,sorts,version_count,loaded_versions,open_versions,users_opening,executions,
users_executing,loads,first_load_time,invalidations,parse_calls,disk_reads,buffer_gets,
rows_processed,sysdate start_time,sysdate finish_time,’>’||address sql_address,’N’status
From v$sqlarea
Where address=(select sql_address from v$session where sid=&sid);
***************Oracle 缓冲区命中率低的分析及解决办法******************

首先确定下面的查询结果:

1,缓冲区命中率的查询(是否低于90%):

select round((1 - sum(decode(name,'physical reads',value,0)) /
(sum(decode(name,'db block gets',value,0)) + sum(decode(name,'consistent gets',value,0))) ),4) *100 || '%' chitrati
from v$sysstat;

2,使用率的查询(有无free状态的数据快.):

select count(*), status from v$bh group by status ;

3,相关等待事件的查询(是否有相关等待事件)

select event,total_waits from v$system_event where event in ('free buffer waits');

4,当前大小(是否已经很大)

select value/1024/1024 cache_size from v$parameter where name='db_cache_size'

5,top等待事件分析(Db file scatered read的比率是否大)

select event ,total_waits,suml
from
(select event,total_waits,round(total_waits/sumt*100,2)||'%' suml
from
(select event,total_waits from v$system_event ),
(select sum(total_waits) sumt from v$system_event)
order by total_waits desc)
where rownum<6
and event not like 'rdbms%'
and event not like 'pmon%'
and event not like 'SQL*Net%'
and event not like 'smon%';

6,db_cache_advice建议值（9i后的新特性,可以根据他更好的调整cache_size）

select block_size,size_for_estimate,size_factor,estd_physical_reads from v$db_cache_advice;

说明分析:

缓冲区命中率(低于90的命中率就算比较低的).

没有free不一定说明需要增加,还要结合当前cache_size的大小(我们是否还可以再增大,是否有需要增加硬件,增加开销),
空闲缓冲区等待说明进程找不到空闲缓冲区，并通过写出灰缓冲区，来加速数据库写入器生成空闲缓冲区，当DBWn将块写入磁盘后，灰数据缓冲区将被释放，以便重新使用.产生这种原因主要是:

1，DBWn可能跟不上写入灰缓冲区：i/0系统较慢，尽量将文件均匀的分布于所有设备，

2，缓冲区过小或过大。

3，可以增加db_writer_processes数量。

4,可能有很大的一个事物，或者连续的大事物

我们需要长期观察这个事件是否长期存在并数值一直在增大,如果一直在增大,则说明需要增大db_cache大小.或优化sql.
数据分散读等待,通常表现存在着与全表扫描相关的等待，逻辑读时，在内存中进行的全表扫描一般是零散地，而并非连续的被分散到缓冲区的各个部分，可能有索引丢失，或被仰制索引的存在。该等待时间在数据库会话等待多块io读取结束的时候产生，并把指定的块数离散的分布在数据缓冲区。这意味这全表扫描过多，或者io不足或争用，

存在这个事件,多数都是问题的,这说明大量的全部扫描而未采用索引.

db_cache_advice对我们调整db_cache_size大小有一定的帮助,但这只是一个参考，不一定很精确。

通过上面6种情况的综合分析,判断是否需要增加大cache_size. 或者把常用的（小）表放到keep区。

但多数的时候做这些不会解决质的问题,

而真正的问题主要是对sql语句的优化(如:是否存在大量的全表扫描等)

索引是在不需要改变程序的情况下,对数据库性能，sql语句提高的最实用的方法.

我在生产中遇到过类似的问题,200M的cache_size,命中率很低21%,但通过对sql语句的优化(添加索引,避免全表扫描),命中率增加到96%,程序运行时间由原来的2小时减少到不到10分钟.

这就提到了怎么定位高消耗的sql问题.全表扫描的问题,在这里不做细致的解说,这里只说明方法,我会在相关的章节专门介绍怎么使用这些工具

1,sql_trace跟踪session.用tkprof 分别输出磁盘读,逻辑读,运行时间长的sql进行优化.这些高消耗的sql一般都伴随着全表扫描.

2,statspack分析.在系统繁忙时期进行时间点的统计分析,产看TOP事件是否有Db file scatered read.并查看TOP sql语句是否存在问题等.

注：电脑学习网首发。

还要说一句：当然在硬件允许的情况下，尽量增大db_cache_size 减少磁盘读，但并不是越大越好，一定要根据自己的库数据量的程度来调节，因为大的db_cache_size同样会增大数据库管理的开销，当然可能开销并不会明显的影响数据库的性能，硬件价格也越来越低，这就需要我们具体问题具体分析了，在我看来物尽其用就最好了，尽量不要浪费，找到问题的本质。调优是一件很艺术的事。

***********************Oracle数据库缓冲区命中率*****************
1、查看Oracle数据库缓冲区命中率

select a.value + b.value "logical_reads", c.value "phys_reads",
    round(100 * ((a.value+b.value)-c.value) / (a.value+b.value)) "BUFFER HIT RATIO"
    from v$sysstat a, v$sysstat b, v$sysstat c
    where a.statistic# = 40 and b.statistic# = 41
    and c.statistic# = 42;

2、Tags: oracle

数据库缓冲区命中率：

sql>select value from v$sysstat where name ='physical reads';
value
3714179
sql>select value from v$sysstat where name ='physical reads direct';
value
0
sql>select value from v$sysstat where name ='physical reads direct(lob)';
value
0
sql>select value from v$sysstat where name ='consistent gets';
value
856309623
sql>select value from v$sysstat where name ='db block gets';
value
19847790

这里命中率的计算应该是

令x＝physical reads direct + physical reads direct(lob)

命中率＝100－(physical reads -x)/(consistent gets +db block gets -x)*100

通常如果发现命中率低于90%，则应该调整应用可以考虑是否增大数据加

共享池的命中率

sql> select sum(pinhits)/sum(pins)*100 "hit radio" from v$librarycache;

如果共享池的命中率低于95％就要考虑调整应用（通常是没应用bind var)或者增加内存。

关于排序部分

sql> select name,value from v$sysstat where name like '%sort%';

如果我们发现sorts(disk)/(sorts(memory)+sorts(disk))的比例过高，则通常意味着sort_area_size部分内存教较小，可考虑调整相应的参数。

关于log_buffer

sql>select name,value from v$sysstat where name in ('redo entries','redo buffer allocation retries');

假如redo buffer allocation retries/redo entries的比例超过1%我们就可以考虑增加log_buffer.

1）设立合理的Oracle性能优化目标。
2）测量并记录当前的Oracle性能。
3）确定当前Oracle性能瓶颈（Oracle等待什么、哪些SQL语句是该等待事件的成分）。
4）把等待事件记入跟踪文件。
5）确定当前的OS瓶颈。
6）优化所需的成分（应用程序、数据库、I/O、争用、OS等）。
7）跟踪并实施更改控制过程。
8）测量并记录当前性能
9）重复步骤3到7，直到满足优化目标

下面来一一详述。

1.设立合理的Oracle性能优化目标

重点：关于设立目标的最重要的一点是它们必须是可量化和可达到的。

方法：目标必须是当前性能和所需性能的的陈述形式的语句。

2.测量并记录当前Oracle性能重点：

1）需要在峰值活动时间获得当前系统性能快照

2）关键是要在出现性能问题的时间段内采集信息

3）必须在合理的时间段上采集，一般在峰值期间照几个为期15分钟的快照

3.确定当前Oracle性能瓶颈重点：从Oracle 等待接口v$system_event、v$session_event和v$session_wait中获得等待事件，进而找出影响性能的对象和sql语句。方法如下：

1)首先，利用v$system_event视图执行下面的查询查看数据库中某些常见的等待事件：

select * from v$system_event
where event in ('buffer busy waits',
'db file sequential read',
'db file scattered read',
'enqueue',
'free buffer waits',
'latch free',
'log file parallel write',
'log file sync');

2)接着，利用下面对v$session_event和v$session视图进行的查询，研究具有对上面显示的内容有贡献的等待事件的会话：

select se.sid,s.username,se.event,se.total_waits,se.time_waited,se.average_wait
from v$session s,v$session_event se
where s.sid = se.sid
and se.event not like 'SQL*Net%'
and s.status = 'ACTIVE'
and s.username is not null;

3)使用下面查询找到与所连接的会话有关的当前等待事件。这些信息是动态的，为了查看一个会话的等待最多的事件是什么，需要多次执行此查询。

select sw.sid,s.username,sw.event,sw.wait_time,sw.state,sw.seconds_in_wait SEC_IN_WAIT
from v$session s,v$session_wait sw
where s.sid = sw.sid
and sw.event not like 'SQL*Net%'
and s.username is not null
order by sw.wait_time desc;

4)查询会话等待事件的详细信息

select sid,event,p1text,p1,p2text,p2,p3text,p3
from v$session_wait
where sid between &1 and &2
and event not like '%SQL%'
and event not like '%rdbms%';

5)利用P1、P2的信息，找出等待事件的相关的段

select owner,segment_name,segment_type,tablespace_name
from dba_extents
where file_id = &fileid_in
and &blockid_in between block_id and block_id + blocks - 1;

6)获得操作该段的sql语句：

select sid, getsqltxt(sql_hash_value,sql_address)
from v$session
where sid = &sid_in;

7)getsqltxt函数

8)至此已经找到影响性能的对象和sql语句，可以有针对性地优化

4.把等待事件记入跟踪文件

重点：如果在跟踪系统上的等待事件时，由于某种原因遇到了麻烦，则可以将这些等待事件记入一个跟踪文件。方法如下：

1)对于当前会话：

alter session set timed_statistics=true;
alter session set max_dump_file_size=unlimited;
alter session set events '10046 trace name context forever, level 12';

2)执行应用程序，然后在USER_DUMP_DEST指出的目录中找到跟踪文件。

3)查看文件中以词WAIT开始的所有行。

4)对于其它的会话

5)确定会话的进程ID（SPID）。下面的查询识别出名称以A开始的所有用户的会话进程ID：

select S.Username, P.Spid from V$SESSION S, V$PROCESS P
where S.PADDR = P.ADDR and S.Username like 'A%';

6)以sysdba进入sqlplus执行

alter session set timed_statistics=true;
alter session set max_dump_file_size=unlimited;
oradebug setospid
oradebug unlimit
oradebug event 10046 trace name context forever, level X /* Where X = (1,4,8,12) */

7)跟踪某个时间间隔得会话应用程序。

8)在USER_DUMP_DEST 的值指出的目录中利用SPID查看跟踪文件

9)查看文件中以词WAIT开始的所有行。

5.确定当前OS瓶颈1）Windows NT上的监控

使用控制面板-〉管理工具-〉性能即可

2）UNIX上的监控

使用通用性的工具，包括sar、iostat、cpustat、mpstat、netstat、top、osview等。

6．Oracle性能优化所需的成分（应用程序、数据库、I/O、争用、OS等）。

7．跟踪并实施更改控制过程。

8．测量并记录当前Oracle性能

9．重复步骤3到7，直到满足优化目标

【转自】http://database.51cto.com/art/201004/196136.htm