2008年4月14日
#
某天，停車，圖方便隨便停在路邊，抱怨了兩句，ld隨即頂回一句：“只要有邊就能停”
一直認(rèn)為lob類型的性能要好過(guò)long，但是之前只了解到long的種種限制，oracle也是不推薦使用long類型，這幾天由于一個(gè)項(xiàng)目問(wèn)題，產(chǎn)品里面一個(gè)表字段用了long類型，分析下來(lái)操作long的時(shí)候，性能有所影響，想把它改成lob，就簡(jiǎn)單驗(yàn)證了一下
首先創(chuàng)建兩個(gè)測(cè)試表：
create table test_long (a int primary key,b long);
create table test_clob (a int primary key,b clob);
用附件java代碼，往兩個(gè)表里面各插入100條數(shù)據(jù)，保證插入數(shù)據(jù)是一樣的，lob字段長(zhǎng)度為10k（如果小于4k，oracle可以把它保存到到表內(nèi)，不會(huì)存儲(chǔ)在表外，性能沒(méi)有問(wèn)題，這個(gè)我基本確定，而且我們應(yīng)用中這個(gè)字段經(jīng)常會(huì)超過(guò)4k）。
做一個(gè)簡(jiǎn)單查詢對(duì)比一下：
SQL> set autotrace traceonly;
SQL> select * from test_clob where a=1;
統(tǒng)計(jì)信息
----------------------------------------------------------
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;
統(tǒng)計(jì)信息
----------------------------------------------------------
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
對(duì)比一下，long開(kāi)銷比lob小，當(dāng)然你可以把lob字段啟用緩存，把4次物理讀去掉，但還是多了（73-43）次邏輯讀，update也試了一下，lob產(chǎn)生的redo比long大，就不列出來(lái)了，有興趣的可以自己試試
測(cè)試下來(lái)，看來(lái)之前的認(rèn)識(shí)不對(duì)，不確定的東西最好還是動(dòng)手試試，當(dāng)然對(duì)于新應(yīng)用，還是不建議用long，畢竟oracle已經(jīng)廢棄它了。
testClobLong.java
用遠(yuǎn)程桌面連接登入服務(wù)器的時(shí)候，你可能會(huì)經(jīng)常碰到下面的情況：
也就是說(shuō)，服務(wù)器的連接數(shù)已經(jīng)滿了，很多時(shí)候，可能是別人異常斷開(kāi)連接，導(dǎo)致連接沒(méi)有釋放，一般這時(shí)候你需要去機(jī)房登入服務(wù)器斷開(kāi)連接，其實(shí)windows提供了tsdiscon命令來(lái)做這事情
有時(shí)候，我們可能希望看到lr的出錯(cuò)頁(yè)面：比如lr出錯(cuò)，但是后臺(tái)服務(wù)器沒(méi)有錯(cuò)誤日志，這時(shí)候，我們希望能看到錯(cuò)誤頁(yè)面的內(nèi)容來(lái)判斷問(wèn)題出在什么地方，但是lr沒(méi)有提供類似的功能
我們可以通過(guò)一種變通的辦法來(lái)實(shí)現(xiàn)：
首先找到你出錯(cuò)的頁(yè)面，保存該頁(yè)面到參數(shù)里面：
web_set_max_html_param_len(“2048”);
web_reg_save_param(“FILED”,”LB=”,”RB=”,”Search=Body”,LAST);
然后輸出到日志里面： lr_output_message(”#######################################%s”,lr_eval_string(”{FILED}”));
修改lr run-time的幾個(gè)設(shè)置：
1、Always send messages
2、continue on error （這樣才能保證運(yùn)行l(wèi)r_output_message)
這樣lr會(huì)把所有的lr_output_message輸出保存到日志文件
當(dāng)然你不要下載資源文件，否則保存到的就不是html頁(yè)面了，可能是一個(gè)gif :(
最后，結(jié)合lr controller的錯(cuò)誤信息，定位到出錯(cuò)的vuser id，查看該vuser的log文件就能看到錯(cuò)誤頁(yè)面了
非常有效的一個(gè)小技巧，用它解決了一個(gè)難纏的問(wèn)題。
慢慢變味了，一群無(wú)聊的人整天盯著別人捐了多少，很奇怪
最近一段時(shí)間特別忙，以至于發(fā)生地震這么大的事情都沒(méi)注意到，首都人民不斷告訴我被震了也沒(méi)當(dāng)回事，昨晚回家打開(kāi)電視，新聞?lì)l道，懵了，坐下來(lái)一直看，到晚上2點(diǎn)，滿目蒼痍，真為處于震中的人揪心，中間鼻子酸了N次，也憤怒了N次（那些惡心人的地方官，難道就不能說(shuō)點(diǎn)實(shí)際的東西嗎？）
1、政府反映非常迅速
2、子弟兵真好
2、有一個(gè)好總理
3、地方政府不作為，官話套話（被采訪的那個(gè)什么何彪，真想抽丫的）
4、為什么總是學(xué)校？處于地址多發(fā)地帶的學(xué)校和其他公共設(shè)施為什么都是豆腐渣
為所有受難的人祈禱！為我們飽受磨難的祖國(guó)祈禱！
公司員工捐款20W，盡點(diǎn)綿力
摘要: 這幾天測(cè)試一個(gè)引擎的性能，用一個(gè)單表查詢的case，測(cè)試出來(lái)的結(jié)果是210tps，cpu也正常，在85%左右，也沒(méi)懷疑。
后面再重新測(cè)試的時(shí)候，加上了gc log，用gc分析工具分析了一下gc的吞吐量，發(fā)現(xiàn)吞吐量奇低，竟然只有77%左右，很是奇怪，看了一下gc日志，所有都是global gc， 懷疑gc策略有問(wèn)題，查了一下資料，參考了下面一篇文章：
閱讀全文