2008年3月18日
#
某天，停車，圖方便隨便停在路邊，抱怨了兩句，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命令來做這事情
有時候，我們可能希望看到lr的出錯頁面：比如lr出錯，但是后臺服務器沒有錯誤日志，這時候，我們希望能看到錯誤頁面的內容來判斷問題出在什么地方，但是lr沒有提供類似的功能
我們可以通過一種變通的辦法來實現：
首先找到你出錯的頁面，保存該頁面到參數里面：
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的幾個設置：
1、Always send messages
2、continue on error （這樣才能保證運行lr_output_message)
這樣lr會把所有的lr_output_message輸出保存到日志文件
當然你不要下載資源文件，否則保存到的就不是html頁面了，可能是一個gif :(
最后，結合lr controller的錯誤信息，定位到出錯的vuser id，查看該vuser的log文件就能看到錯誤頁面了
非常有效的一個小技巧，用它解決了一個難纏的問題。
慢慢變味了，一群無聊的人整天盯著別人捐了多少，很奇怪
最近一段時間特別忙，以至于發生地震這么大的事情都沒注意到，首都人民不斷告訴我被震了也沒當回事，昨晚回家打開電視，新聞頻道，懵了，坐下來一直看，到晚上2點，滿目蒼痍，真為處于震中的人揪心，中間鼻子酸了N次，也憤怒了N次（那些惡心人的地方官，難道就不能說點實際的東西嗎？）
1、政府反映非常迅速
2、子弟兵真好
2、有一個好總理
3、地方政府不作為，官話套話（被采訪的那個什么何彪，真想抽丫的）
4、為什么總是學校？處于地址多發地帶的學校和其他公共設施為什么都是豆腐渣
為所有受難的人祈禱！為我們飽受磨難的祖國祈禱！
公司員工捐款20W，盡點綿力
摘要: 這幾天測試一個引擎的性能，用一個單表查詢的case，測試出來的結果是210tps，cpu也正常，在85%左右，也沒懷疑。
后面再重新測試的時候，加上了gc log，用gc分析工具分析了一下gc的吞吐量，發現吞吐量奇低，竟然只有77%左右，很是奇怪，看了一下gc日志，所有都是global gc， 懷疑gc策略有問題，查了一下資料，參考了下面一篇文章：
閱讀全文
Sybase ASE有三種鎖模式：AllPages,DataPages,DataRows
Sybase的數據有table pages和index pages，最小分配單位為pages，不同的鎖模式對于table pages和index pages有不同的表現，具體如下：
| Locking Schema | Locks on Index | Locks on Data |
| All Pages | Page | Page |
| DataPages | Not locked | Page |
| DataRows | Not locked | Row |
如上表所示：
1、AllPages鎖模式對于并發的限制最高，他對index pages和table pages都加頁鎖（當頁被鎖住的時候，頁上的所有rows都不能被其他session訪問）
2、DataPages對table pages加頁鎖
3、DataRows：強烈建議用這個鎖模式，對于oltp應用，如果用前兩種鎖模式會導致頻繁死鎖
另外，DataPages和DataRows對于index pages的控制采用latch方式，一種輕量級的鎖機制（熟悉oracle會比較清楚）
對于Sybase ASE來說，鎖是非常寶貴的資源，不要長時間持有鎖，所以一般我們在寫應用的時候盡量減少長事務
另：Sybase ASE缺省的事務隔離級別：Read Committed
一個用戶點擊就是一個用戶請求，一個webservice類似的調用也算一個請求，等等
一個用戶在某個時間點上當然只能發起一個用戶請求，一個用戶請求就是一個并發
我們一般糾纏在同一事物并發還是不同事務并發。
可能在一個時間點上，有100個用戶在發送瀏覽，查詢動作，10個用戶在下訂單，5個用戶在做付款動作，你說這個時間點上有多少個并發請求，當然是115個了
衡量一個系統性能主要靠的就是這個吞吐量（tps）
當然我們也非常關心同時100個用戶并發下訂單的時候系統是否能支撐（這是通常我們大部分人理解的并發），我們會說這是核心業務，我們要得出數據（是否要考慮背景業務呢，呵呵，很難說的清楚，我一般就不考慮）