<rt id="bn8ez"></rt>
<label id="bn8ez"></label>

  • <span id="bn8ez"></span>

    <label id="bn8ez"><meter id="bn8ez"></meter></label>

    2008年5月18日 #

    語錄一

    某天,停車,圖方便隨便停在路邊,抱怨了兩句,ld隨即頂回一句:“只要有邊就能停”

    posted @ 2008-11-18 23:32 tacy lee 閱讀(251) | 評論 (0)編輯 收藏

    oracle 的lob & long

    一直認為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

    posted @ 2008-06-24 01:18 tacy lee 閱讀(464) | 評論 (0)編輯 收藏

    殺掉服務器上的遠程桌面連接

    用遠程桌面連接登入服務器的時候,你可能會經常碰到下面的情況:

    mstsc-exceed-456x114

     

    也就是說,服務器的連接數已經滿了,很多時候,可能是別人異常斷開連接,導致連接沒有釋放,一般這時候你需要去機房登入服務器斷開連接,其實windows提供了tsdiscon命令來做這事情

    posted @ 2008-06-22 17:12 tacy lee 閱讀(474) | 評論 (0)編輯 收藏

    通過保存錯誤頁面到日志中解決一些后臺看不到異常的錯誤

    有時候,我們可能希望看到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文件就能看到錯誤頁面了

    非常有效的一個小技巧,用它解決了一個難纏的問題。

    posted @ 2008-05-28 23:05 tacy lee 閱讀(843) | 評論 (3)編輯 收藏

    捐款

    慢慢變味了,一群無聊的人整天盯著別人捐了多少,很奇怪

    posted @ 2008-05-18 19:45 tacy lee 閱讀(256) | 評論 (0)編輯 收藏

    主站蜘蛛池模板: 亚洲av永久无码天堂网| 亚洲AV综合色区无码一二三区| 美女无遮挡免费视频网站| 国产免费牲交视频免费播放 | 国产成人免费片在线观看| 亚洲精品97久久中文字幕无码| 久久狠狠高潮亚洲精品| 国产午夜亚洲精品不卡| 亚洲美女视频免费| 国产成人精品日本亚洲专区| 天天爽亚洲中文字幕| 中国内地毛片免费高清| 国产成人高清精品免费鸭子 | 亚洲国产成人久久三区| 一个人看的www在线免费视频| 日本阿v免费费视频完整版| 亚洲国产精品无码av| 尤物视频在线免费观看| 最近高清国语中文在线观看免费| 亚洲春色在线视频| 色欲国产麻豆一精品一AV一免费 | 99视频免费观看| 红杏亚洲影院一区二区三区| 亚洲精品永久在线观看| 国产成人福利免费视频| 亚洲AV成人片色在线观看高潮| 高潮内射免费看片| 亚洲国产日韩在线视频| 五级黄18以上免费看| 久久亚洲高清观看| 毛片免费全部播放一级| 污视频网站在线观看免费| 国产大片51精品免费观看| 久香草视频在线观看免费| 亚洲av日韩av激情亚洲| 午夜男人一级毛片免费| 亚洲成a人片在线看| 亚洲AV成人精品日韩一区18p| 日本亚洲高清乱码中文在线观看| 暖暖在线日本免费中文| 亚洲AV无码一区二区乱子仑|