Oracle在使用rownum select資料時
select rownum from orderTable where rownum between 100 and 200 ;
不會有資料出現，因為rownum 在select出結果的時候才會產生，有點像增加一個臨時的欄位，從1開始; between 100 and 200還沒有結果，所以不會出現資料!!
可以用下面的方法解決:
select * from orderTable where rownum <=200 minus (select * from orderTable where rownum <=100);
或是使用ROW_NUMBER函數
SELECT NO, NAME FROM (
SELECT NO, NAME, ROW_NUMBER() OVER (ORDER BY NO) RNUM
FROM ROWNUM_TEST ) WHERE RNUM BETWEEN 5 AND 10
繪製圖表的API除了使用商業產品(Crystal Report等)，以及Office Web Component(Excel)，其實也有很多免費的工具，如下面10個，其中最特別的Google Chart是線上服務，把資料打在google chart的url裡面，就會在網頁上畫出圖表，Google果然是online應用的專家！
另外自己現在寫C#，搭配使用的是ZedGraph，也相當的好用。
列舉部份供參考：
| Object | Counter | Preferred Value |
| Memory | Available Mbytes | > 100MB |
| Paging File | %Usage | < 70% |
| Process (sqlservr) | %Privileged Time | < 30% of %Processor Time (sqlservr) |
| Processor | %Privileged Time | < 30% of Total %Processor Time |
| PhysicalDisk | Avg. Disk Sec/Read | < 8ms |
| PhysicalDisk | Avg. Disk sec/Write | < 8ms (non cached) < 1ms (cached) |
| SQLServer:Access Methods | Forwarded Records/sec | < 10 per 100 Batch Requests/Sec |
| SQLServer:Access Methods | FreeSpace Scans/sec | <10 per 100 Batch Requests/Sec |
| SQLServer:Access Methods | Full Scans / sec | (Index Searches/sec)/(Full Scans/sec) > 1000 |
| SQLServer:Access Methods | Workfiles Created/Sec | < 20 per 100 Batch Requests/Sec |
| SQLServer:Access Methods | Worktables Created/Sec | < 20 per 100 Batch Requests/Sec |
| SQL Server:Buffer Manager | Buffer Cache hit ratio | > 90% |
| SQL Server:Buffer Manager | Free list stalls/sec | < 2 |
| SQL Server:Buffer Manager | Lazy Writes/Sec | < 20 |
| SQL Server:Buffer Manager | Page Life Expectancy | > 300 |
| SQLServer:Buffer Manager | Page lookups/sec | (Page lookups/sec) / (Batch Requests/sec) < 100 |
| SQL Server:Locks | Lock Requests/sec | (Lock Request/sec)/(Batch Requests/sec) < 500 |
| SQLServer:SQL Statistics | SQL Compilations/sec | < 10% of the number of Batch Requests/Sec |
| SQLServer:SQL Statistics | SQL Re-Compilations/sec | < 10% of the number of SQL Compilations |
詳細資訊：
TechNet Webcast: SQL Server Performance Counter Guidance (Level 300)
資料庫實在是IT又愛又恨的東西，以前公司的資料庫，大約在table成長到約100萬筆資料時，效能瞬間down到不能用，只能靠刪除資料的方式恢復效能，大約回到90萬筆就很快了，SQL Server你真行! Orz
不過比起另一個系統把預約單檔案(1~5KB)，存放在另一台server的share folder(EMC DMX等級的SAN哦)，等要用到時再去讀取，結果就是檔案到了約10萬個以後開始讀取寫入都會漏資料!! 最慘的是沒有log，無從找出問題。
現在回想起來，如果選擇用資料庫來處理這種需求。100萬筆資料vs.100萬個檔案，很明顯資料庫對100萬筆資料處理還算輕而易舉，DB雖然也會有瓶頸及tuning的問題，但好歹有方法可以依循，有架構可以利用，更重要的有很多工具找出問題。
在32-bit CPU memory 配置中
在64-bit CPU memory 配置中
前天裝好了x86-64的2003+sql2005想說把爛爛的server多榨出一點效能來，看能不能撐到user要的5年資料(估計150G)，結果廠商來裝他們的軟體竟然說"我們的程式抓不到64位元os的odbc"...Orz
odbc不就是個API嗎？還會抓不到，真詭異。不過更詭異的還在後面，3台ap用odbc連線竟然只有一台連的到，還都在同網段。今天一不作二不休，就重灌成32bit的吧，果然就很順利了!! 想想可能是請廠商在裝os的時候，HP的導引光碟好像是拿成x86 32bit的...難怪裝好以後有幾樣裝置沒抓到，以後還是要多細心點，不要顧聊天 XD
Raid Controller:
HP Smart Array E200: 64MB cache, support raid 0/1/1+0
HP Smart Array P400: 256MB cache(大4倍!!), support raid 0/1/1+0/5/6
IBM ServerRAID 8K: 256MB cache, support raid 0/1/1+0/5/6
Dell PERC5/i: 256MB cache, support raid 0/1/1+0/5/6
測試參數:
接下來要PK大亂鬥啦：
E200，4顆硬碟作1+0，配置在2個channel
E200，2顆硬碟作1+0，配置在1個channel
P400，2顆硬碟作1+0，配置在2個channel
IBM，2顆硬碟作1+0，配置在1個channel
Dell，2顆硬碟作1+0，配置在1個channel
結論：
IIS 6.0中設定HTTP壓縮的步驟如下：
我拿系統的一個aspx網頁測試得到底下的結果，有48.10%好像挺不賴吧，壓縮率設定是6，cpu loading沒有什麼增加。
