自訂色彩中有三項,中英文比對
1.對比度 -> Contrast
2.鮮明度 -> Sharpness (<-所以 想調整銳利度,就是這一項~)
3.色彩飽和度 -> Saturation
剩下可調的部份則是 R,G,B,skin tone(膚色,這個不錯用!)
推測G9的最佳光圈應該是在F4-F5.6間。根據Bob的測試，G9最佳的光圈值是F5.6。
個人的實際使用經驗。我認為F4.5最適合，一方面是光圈值夠大，一方面是畫面很銳利。F4.5配合機身的最高銳利值設定，後製時幾乎不必再管銳利化的問題。
G9的MTF http://www.diwa-labs.com/photoalbum/view/?size=org&id=237638
F8平均起來有比較差一點但大致上任何焦段任何光圈都很銳利
若根據DIWA Labs的測試，G9最佳光圈值應該是F4。
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
結論：
