某天，停車，圖方便隨便停在路邊，抱怨了兩句，ld隨即頂回一句：“只要有邊就能停”
一直認為lob類型的性能要好過long，但是之前只了解到long的種種限制，oracle也是不推薦使用long類型，這幾天由于一個項目問題，產品里面一個表字段用了long類型，分析下來操作long的時候，性能有所影響，想把它改成lob，就簡單驗證了一下
首先創建兩個測試表：
create table test_long (a int primary key,b long);
create table test_clob (a int primary key,b clob);
用附件java代碼，往兩個表里面各插入100條數據，保證插入數據是一樣的，lob字段長度為10k（如果小于4k，oracle可以把它保存到到表內，不會存儲在表外，性能沒有問題，這個我基本確定，而且我們應用中這個字段經常會超過4k）。
做一個簡單查詢對比一下：
SQL> set autotrace traceonly;
SQL> select * from test_clob where a=1;
統計信息
----------------------------------------------------------
331 recursive calls
0 db block gets
69 consistent gets
4 physical reads
0 redo size
1278 bytes sent via SQL*Net to client
837 bytes received via SQL*Net from client
5 SQL*Net roundtrips to/from client
12 sorts (memory)
0 sorts (disk)
1 rows processed
SQL> select * from test_long where a=1;
統計信息
----------------------------------------------------------
236 recursive calls
0 db block gets
43 consistent gets
0 physical reads
0 redo size
675 bytes sent via SQL*Net to client
531 bytes received via SQL*Net from client
3 SQL*Net roundtrips to/from client
5 sorts (memory)
0 sorts (disk)
1 rows processed
對比一下，long開銷比lob小，當然你可以把lob字段啟用緩存，把4次物理讀去掉，但還是多了（73-43）次邏輯讀，update也試了一下，lob產生的redo比long大，就不列出來了，有興趣的可以自己試試
測試下來，看來之前的認識不對，不確定的東西最好還是動手試試，當然對于新應用，還是不建議用long，畢竟oracle已經廢棄它了。
testClobLong.java
用遠程桌面連接登入服務器的時候，你可能會經常碰到下面的情況：
也就是說，服務器的連接數已經滿了，很多時候，可能是別人異常斷開連接，導致連接沒有釋放，一般這時候你需要去機房登入服務器斷開連接，其實windows提供了tsdiscon命令來做這事情