Poor CLOB performance over dblink

Question

These statements take 4 seconds to complete:
drop table t_test purge;
create table t_test as
SELECT CONTENT_ID,SITEID
from sitecontent@remotedb;These statements don't complete after at least 10 minutes of waiting:
drop table t_test purge;
create table t_test as
SELECT CONTENT_ID,SITEID, BODY
from sitecontent@remotedb;The only difference is that the second SQL contains a reference to BODY, which is a CLOB column.
The SITECONTENT table consists of just 2815 records. The CONTENT_ID and SITEID columns are NUMBER. A max(length(body)) returns a result of 29,005. And a count where length(body)>15000 returns just 115. So we are not talking about huge amounts of data for the table, nor large amounts for very many rows. Certainly not enough, I would have thought, to explain a difference in completion times between about 4 seconds and apparently forever.
Is this a known issue with CLOBs over database links? (I have looked, but not found anything relevant). Is there anything I can do to remedy the situation (not asking for quick fixes, just any steps I can plod my way through!). When I look at the local database, it's just constantly waiting on SQL*Net message from dblink.
This is 11.2.0.1 on RHEL5.5 x86_64.
Thanks in advance.

Answer 1

Well, I tried that:
Connected.
SQL> set autotrace traceonly explain statistics;
SQL> create table t_test as select ctext from clobtest@remotedb;
Table created.
SQL>No statistics were displayed, in other words. (Same result when selecting vtext, as it happens). I don't think autotrace works on DDL statements, does it? It's working fine for selects, though. So, ignoring the create table bit for now, here's the Vtext statistics:
SQL> select vtext from clobtest@remotedb;
2831 rows selected.
Execution Plan
Plan hash value: 1402521094
| Id  | Operation              | Name     | Rows  | Bytes | Cost (%CPU)| Time     | Inst   |
|   0 | SELECT STATEMENT REMOTE|          |  2994 |  5853K|   312   (1)| 00:00:04 |        |
|   1 |  TABLE ACCESS FULL     | CLOBTEST |  2994 |  5853K|   312   (1)| 00:00:04 |   RMDB |
Note
   - fully remote statement
   - dynamic sampling used for this statement (level=2)
Statistics
          0  recursive calls
          0  db block gets
          0  consistent gets
          0  physical reads
          0  redo size
    3629480  bytes sent via SQL*Net to client
       2428  bytes received via SQL*Net from client
        190  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
       2831  rows processedI can't produce the equivalent Ctext statistics, of course, since a select from a remote clob simply generates an ORA_22992.
I'm sort-of stumped at this point.