微軟再裁撤800名員工
文/陳曉莉 (編譯) 2009-11-05
http://www.ithome.com.tw/itadm/article.php?c=57940
根據TechFlash報導，微軟已於周三通知被裁的員工，並證實這已超過當初預估的5000名。
科技部落格TechFlash周三（11/4）報導，微軟周三再裁撤了800名員工，超出原本微軟在今年初預估的5000名裁員規模。
微軟在今年1月揭露了首度的大規模裁員計畫，預計在18個月內裁減5000名員工；而微軟近日提交給美國證券管理委員會（SEC）的2010財年第一季財報（2009年7月～9月）中表示，該公司已完成年初的裁員計畫，縮減了約5000個職位以及4600名員工。
不過，微軟卻在本周三額外裁撤了800名員工。根據TechFlash報導，微軟已於周三通知被裁的員工，並證實這已超過當初預估的5000名。
雖然微軟表示經過此新一波裁員後，已提前完成此一裁員計畫，但微軟仍舊不排除未來裁員的可能性，指出該公司將會根據業務需求持續進行人力調整。今年10月微軟全球員工人數約為9.1萬。（編譯/陳曉莉）
台哥大跨年斷訊事件：委外工程師遭求刑2年
文/蘇文彬 (記者) 2009-10-30
http://www.ithome.com.tw/itadm/article.php?c=57871
該名工程師透過違反合約的特定路徑入侵台哥大委託維護的主機，致使主要營運和備援系統同時當機，造成北部大斷訊。
年初台灣大哥大北部地區斷訊事件，經調查為台哥大所委託諾基亞西門子（NSN）離職工程師惡意入侵破壞，該工程師遭求刑2年。
今年初跨年夜台灣大哥大新竹以北地區發生大規模斷訊事件，影響百萬用戶通訊權益，事件發生後台灣大哥大遭外界質疑資安措施不足，導致駭客入侵造成系統當機。
今天台灣大哥大發出聲明指出，整起斷訊事件經檢調偵辦確認為台哥大電信網路系統、維護委外業者NSN離職工程師惡意入侵所致，板橋地檢署依刑法入侵電腦、破壞電磁紀錄提起公訴，具體求刑2年。
台哥大表示，北部地區使用兩套NSN門號可攜認證服務網路系統，置於兩機房內由簽有維護合約的NSN負責系統維護、保養。該工程師先前任職NSN時即負責台哥大主機維護管理，以違反合約的非法途徑入侵主機破壞原始設定，讓主要和備援兩個網路系統同時當機，造成新竹以北網路斷訊。
事發後，台哥大與NSN調查蒐證後交檢調偵辦，確認該工程師為造成斷訊的犯罪者起訴，台哥大表示，未來將做好防範措施，確保未來不再發生入侵事件。
安全鏈條的強度取決於最弱一環
文/iThome (記者) 2009-10-27
http://www.ithome.com.tw/itadm/article.php?c=57683
管理機制上採取分工的目的，就是為了防弊，防弊就是安全。可是到了電腦世界，我們難道就不需要防弊了嗎？
在臺灣，我實地參觀過很多企業的資訊部門，發現他們都有很嚴重的安全問題卻不自知，甚至是營業額達數百億元的上市公司，儘管導入了種種資安設備，但是，我還是認為這些公司的資訊安全不及格。
安全的強度，就像是鏈條，整體鏈條的強度取決於最弱的那一環。一間公司的安全防線中，即便所採用的技術達到90分的水準，但管理制度只有20分，兩者相加，整體安全強度還是只有20分。這個最弱的一環其實也是很多企業常忽略的一環。
有一家上市公司將IT部門分成五個科，一個專管資料庫、一個負責網路架構建置，另外三個科則是系統開發一科、二科和三科。將使用者部門分成三群，由每個開發科負責一群。從系統分析、開發、營運、維護到除錯，都是相同一個科來負責，這正是一般企業常採行的作法。
以人事系統來舉例，人事部在每個月底，會利用系統結算當月薪資。這間公司由開發一科的小王來負責人事系統的開發與維護。
漏洞在哪裡呢？小王可以在28日晚上，偷偷修改系統程式，自動將每個人的薪水減少十元，再全部放入另外一個秘密帳號中，隔天等人事部門薪資結算完成，再將系統程式更新為原來的版本。公司薪水支出總數不變，系統程式相同，沒有人會知道小王偷了每一個人的錢。只能仰賴其他會計資料的勾稽才有可能在事後發現，而不能防範於未然。
這種讓同一個人負責開發和維護的作法，缺乏專業分工，完全違背基本任務分工的管理原則，這正是臺灣資訊部門最大的弊病，就會導致不安全。
任何超過十個人的企業，會計跟出納一定不是同一人，管錢的人不管帳，管帳的人不管錢。雖然兩個人也可能串通作弊，但是人越多，串通的難度越高，就能達到防弊的效果。如果都由同一個人負責，就完全無法制衡。
管理機制上採取分工的目的，就是為了防弊，防弊就是安全。可是到了電腦世界，我們難道就不需要防弊了嗎？在沒有電腦的年代中所建立的種種管理機制，例如專業分工這些管理制度中的基本概念，都有其意義，不會因為IT出現就需要拋棄。
但是，現在有很多企業的CIO，拚命導入各種技術性的資安產品，卻連這麼簡單的管理問題都沒有處理，缺乏分工才是會發生安全漏洞的地方。
在有制度的美國大公司中， IT部門的組織架構上，一定會將開發人員和日常作業人員分開成兩個部門，兩個部門的成員不會混合。
開發者依據需求變更請求修改程式後，就必須將程式放到獨立的測試環境中，再由作業人員進行差異分析，找出新舊版程式的異同。然後由開發者和作業者以及雙方主管共同開會，審視這些有差異的程式碼。審查完畢後，由上線人員負責編譯程式，更新系統，開發人員完全不能再接觸到程式碼。作業者無法私自修改程式內容，開發者也無從暗中更新系統，這樣就能建立安全性。企業即使無法採取這樣大動干戈的作法，至少也要做到部分分工，沒有分工就沒有安全性可言。
以上只是眾多例子中的一個。大部分人談論資訊安全時，多半只講到安全的技術，很少有人論及安全的管理。公司高層必須要有決心來推動像權責分工這樣的安全管理，而不是多花兩百萬元採購資安設備。因為整個安全鏈條的強度，取決於最弱的那一環。口述⊙范錚強，整理⊙王宏仁
作者簡介：
范錚強－中央大學管理學院特聘教授
曾任國立中央大學資管系主任多年，任內創立資管所碩士班，曾應邀到北京大學光華管理學院任客座教授。學術方面，擔任過中華民國資訊管理學會第一、二屆常務理事，以及第三、四屆理事長。范教授長期擔任多項政府專案審查人，包括經濟部軟五計畫、ABCDE計畫、企業體系電子化計畫、商業體系電子化計畫、物流運籌業電子化計畫、行政院科技顧問組旗艦計畫等。
遠東商銀、第一銀行通過ISO 27001三年重新驗證
文/黃彥棻 (記者) 2009-10-22
http://www.ithome.com.tw/itadm/article.php?c=57503
對銀行業而言，ISO 27001資安驗證不只在內部IT流程有幫助，對企業銀行也有正面意義。因而業者都願意繼續取得ISO 27001驗證
為了砥礪企業持續在資訊安全上政策與作為上的精進，ISO 27001資安驗證在3年到期後，企業都必須進行資格完整複審一次，才可以能到第二次的資格驗證。臺灣銀行業者中，已有遠東商銀、第一銀行第一個3年資安驗證資格到期。這兩間銀行表示，因為通過ISO 27001對公司營運以及IT整體管理有大的成效，驗證到期後，都決定重新複審資格，持續取得ISO 27001資安驗證。
臺灣BSI副總經理蒲樹盛表示，以驗證公司立場來看，目前多數先前取得ISO 27001資安驗證的企業，在3年認證到期後，若沒有IT預算的壓力，多數都會重新驗證、取得第二次的3年認證資格，只有少數因為公司支出刪減，或者是當初只是為了虛應故事的單位，不會繼續取得驗證。他認為，這除了證明企業普遍重視資安外，更證明資安已經是企業營運的重要關鍵之一。
遠東商業銀行在今年6月，通過ISO 27001三年到期後的重新審驗。遠東商銀資訊管理處處長邱維川表示，金融業高度依賴IT提供各種服務，遠東商銀選擇導入ISO 27001，就是希望能提供一個內部包含IT甚至是金融產品開發上，做到安全又符合標準的作業程序。
他說：「當所有開發流程作業程序很清楚，許多產品、系統規畫和建置的時間，因為有遵循的標準，反而可以縮短開發時間、更有效率。」邱維川以2008年統計數據為例，導入ISO 27001後，作業系統與服務效率整體提升40％，系統中斷服務時間（Downtime）也大幅減少。
ISO 27001資安認證對於遠東商銀在香港分行業務拓展上，幫了很大的忙；但對內部同仁而言，因為相關管控措施已經內化到每日的工作流程，同仁不僅有同樣溝通語言，對自己的角色扮演與權責更為清楚。他認為，這些都有助於遠東商銀同仁對內、對外提供服務時，在資安上把關。
第一銀行資訊中心副總經理柯明川指出，一銀今年7月通過ISO 27001重新驗證，回首過去3年，一銀不僅大幅提高內部IT資安控管能力，對於銀行業務發展上，例如海外分行作業集中化或者新業務的申辦，都產生極高的效益。
他說，第一銀行在今年初就提出「ISO 27001三年重新驗證專案」，在ISO 27001驗證到期後，還要通過重新驗證。柯明川指出，取得ISO 27001後，對於一銀在Open Server實體管理上，有很大的進步，「連資訊風險更是逐年下降20％，」他說。
ISO 27001最大的效益反而是有利於第一銀行許多海外分行業務的推廣與申請。柯明川指出，海外分行連線作業要集中回臺北，甚至是海外分行要增加網銀等新興業務，當地政府都是因為看到一銀已取得ISO 27001認證，而同意一銀可以開辦相關業務。
第一銀行系統開發處副處長陳淑峰補充表示，金融業要申請或新增業務時，經常需要舉證公正第三者審查通過的標準，像是今年8月紐約海外分行要連線回臺北，也是因為第一銀行提出ISO 27001資安驗證的客觀標準，才得以順利進行。文⊙黃彥棻
線上購物停擺七小時 PChome：系統維護
文/蘇文彬 (記者) 2009-10-20
http://www.ithome.com.tw/itadm/article.php?c=57657
儘管晚間六點半已恢復服務，但PChome長時間且在白天暫停線上購物服務，仍引發網友諸多猜測。
國內知名網路購物業者PChome線上購物今天無預警停止網購服務長達七小時。對於這次不尋常的服務停擺，PChome官方表示，只是進行系統維護。
今天上午11點，PChome線上購物平台突然無預警停擺，網友進入線上購物頁面，第一時間發現錯誤訊息。稍後PChome系統貼上公開說明，表示因系統進行維護而暫時停止交易，不僅無法下單，也看不到商品頁面陳列。晚間6點半左右，PChome線上購物終於恢復服務，但暫停服務時間長達7個小時左右。
對今天線上購物平台暫停服務，PChome行銷處公關副理楊璿表示，主要是系統正進行維護，內部正對資料庫程式作更新，所以暫停線上購物的交易，待更新完成後就會恢復網購服務。
雖然晚間6點半左右PChome線上購物已恢復，但PChome線上購物這次長時間停擺令人懷疑是否背後有重大原因。事實上記者在下午四點多與PC home連絡時，該公司當時表示，何時可以恢復上線並不確定。
由於先前曾有下單網友回應曾接到自稱PChome商店街賣家來電的詐騙電話，疑似買家個人資料外露，因此有網友就懷疑，PChome是否被駭客入侵因而需要暫停，確保系統安全。
不過經過細查，其實讓網友個人資料外洩的應該是PC home商店街裡的店家，因此，對於網友反應，楊璿表示，PChome已要求商店街賣家與下單網友聯繫時以加密方式進行，以避免交易資訊外露。
事實上，對於大型網購平台交易而言，由於網路購物交易的便利性，24小時全天候開放下單購物，需隨時確保系統穩定與安全性，以避免因系統問題產生可能的消費糾紛。例如日前戴爾烏龍標價事件，第二次出錯即因為系統問題，將原本高價的筆電以極低價格出售，引發第二次消費糾紛。
像PC home購物網站在上班時間內突然長時間停機，相當不符合大型網站系統維護或昇級方式。通常來說，為避免影響前端服務並波及到使用者，除了會在後端建立備援系統外，也會選擇在網路流量最少的時候，例如深夜時段，以及周末假期時。甚至像PC home這樣的升級方式，如果是計畫之內的系統維護，照常理也會對使用者進行事前的宣導。
例如，對於Yahoo!的拍賣、超級商城、購物中心三大電子商務平台的系統維護方式，Yahoo!公共關係部資深總監歐玫英就表示，在系統例行性的維護或更新昇級時通常不會影響到前端服務，若真因系統穩定、安全需要而暫停服務，為避免影響用戶權益Yahoo!也會事先公告時間及影響性，並選擇在清晨或假日等離峰時間進行更新、昇級。
http://www.ithome.com.tw/itadm/article.php?c=57465&s=1
2009-10-12
－－幫關聯式資料庫裝上了渦輪引擎
如果你對系統的反應時間要求嚴苛，而且發現效能瓶頸總是卡在資料往返磁碟的存取過程，不妨考慮記憶體資料庫，它可以提升6～20倍的存取效率
很多線上交易的作業不容許等待，例如股票交易、電話費率計算、線上的訂票服務，或者客服系統。如果等待時間過長，或者客戶總是買不到想要的東西，滿意度就會往下掉。如果你對系統的反應時間要求嚴苛，而且發現效能瓶頸總是卡在資料往返磁碟的存取過程，不妨考慮記憶體資料庫，它可以提升6～20倍的存取效率。
少了硬碟瓶頸，資料存取大躍進
當記憶體的價格越來越平易近人，IT人員不用為了記憶體空間的運用錙銖必較，市面上也出現記憶體資料庫這類解決方案，使資料的存取省掉磁碟存取過程，效能因此加速6～20倍
徹底了解IBM與Oracle記憶體資料庫解決方案的差異
兩家的解決方案在基礎設計架構上差異不大，同樣有快取及單機兩種模式，也都提供Hot Standby備援機制。主要差異在後端串連資料庫的開放性
該用記憶體資料庫嗎？
記憶體資料庫同樣有完整的備份與復原方案，所以需考量的是調整架構的軟、硬體成本
少了硬碟瓶頸，資料存取大躍進
在硬體快速發展的情況下，記憶體的容量與處理器運算速度，以超越想像的發展大幅成長，價格也越來越便宜。過去在記憶體的容量少、價格高的時候，資料庫的應用，為了善用有限的記憶體空間，系統只能把需要使用的資料上載到記憶體，待資料處理完成之後，便釋放記憶體空間供給其他系統使用。
然而，時至今日，記憶體的取得越來越便宜，無論個人電腦或是伺服器，動輒都有數GB甚至數十GB的記憶體。這樣的變化也使得軟體運作的模式隨之改變。
由於記憶體和處理器不再是執行效能的主要瓶頸，磁碟的存取（Disk I/O）和網路反而成了拖慢效能的最大元兇。於是記憶體資料庫（In Memory Database）應運而生，它與傳統的關聯式資料庫相同，採用SQL語法、可以撰寫預存程序，提供索引、備份、復原及備援等所有關聯式資料庫具備的管理機制，也會產生快照檔（Checkpoint File）及交易日誌檔（Transaction Log）。
當企業可以把資料直接放到記憶體進行存取與計算，少了存取磁碟的往返過程，效能比起傳統的資料庫（Disk Based Database）足足快上6～10倍。
當資料存取效能影響獲利，加速就是必要
事實上，資料庫的發展已經相當成熟，企業只要搭配足夠等級的硬體設備，系統的存取效能已能滿足多數應用的要求。尤其對於內部的使用者而言，就算需要等個幾秒鐘，也是可以容許的範圍。
然而，對於即時交易型的應用就另當別論，差個幾秒影響所及，不是「等一下」的時間差而已。尤其是電信及金融產業，他們也是採用記憶體資料庫的第一批客戶。
以股票與期貨的電子下單為例，是分秒必爭的交易，客戶在乎的是「成交與否」與「價格高低」，因為有沒有買到、成交價格多少，直接影響到投資的利益。所以客戶對於系統下單的效率，要求比較嚴苛。
再者，以運動彩券為例，使用者下注某位球員、比數及賠率等都是關注的焦點，慢個幾秒可能就是「賺」和「賠」的不同結局了。這些是資料庫的存取效率有明顯影響的案例。
再就企業角度而論，電信產業的易付卡應用，餘額的計算對於企業而言是效能要求相當嚴苛的應用。電信公司不可能讓客戶在餘額扣光之後，還毫無限制地通話。所以當易付卡用戶開始撥打電話，系統就要持續地計算扣款金額、比對帳戶餘額，當餘額低於下限的時候，例如只剩50元，必須要發出訊息提醒使用者。
另一種應用是針對客戶服務部門。事實上，客戶在電話線上等待操作人員回覆的時間，與企業的服務形象正相關，同時也影響仍在線上等待接聽的客戶數量。尤其特定領域的客戶服務部門，例如銀行的信用卡、帳單的查詢或者與產品銷售相關的電話服務，動輒數百位客服人員在線上接聽電話，當客服人員接聽電話時，要能夠馬上調出客戶的資料，以因應後續的諮詢與處理。
另外，臺灣高科技製造業生產線的監控作業，需要五分鐘計算一次良率並產出報表，因此目前也有採用記憶體資料庫的企業。臺灣澳圖美德資訊長杜奕鋒解釋：「如果資料庫存取的效能存在瓶頸，可能發生上一個五分鐘的良率還沒算完，下一個五分鐘的良率又要開始計算的情況。」
這類的報表問題在其他產業也有不同程度的瓶頸，許多企業運用晚上資料庫的離峰時間，設定排程做一些運算或產出報表，然而當某一個排程因為各種因素而未成功執行，隔天的作業可能就大受影響。
傳統的解決方式──快取
在沒有記憶體資料庫之前，針對磁碟存取造成拖慢資料庫效能的瓶頸，資訊部門已衍生一些因應的方式。
就以上述所舉高科技製造業的良率計算為例，過去的作法是每5分鐘產生一個快照檔（Checkpoint File），丟到另一臺主機專門應付報表用途。然而額外建置伺服器的軟、硬體及儲存設備的成本頗高。
而多數企業比較可能採取的技巧是──增加記憶體，然後用各種快取（Cache）技巧提升效能。
在資料庫方面，企業可以把使用者經常查詢的資料上載到記憶體，以加速查詢的效能。快取的設計方式有很多種，例如當使用者查詢某一筆資料時，把時間相近或者順序相近的其他資料，連帶也快取到記憶體，那麼如果下次查詢的資料落在快取的範圍中，就不用再回磁碟去找資料。
這樣的作法，可以增加快取擊中率（Cache Hit Rate），如果資料量不大或者記憶體容量足夠，企業甚至可以選擇把特定幾個使用者經常查詢的資料表（Table）整個上載到記憶體。然而，企業需要快取的資料通常有一定的規模，所以擊中率未必能夠達到百分之百，當使用者需要的資料不在記憶體中，仍需存取磁碟。
還有一個加速查詢的方式，是將查詢結果製作成網頁。有一些Web應用，不同使用者查詢的結果大同小異，那麼開發者可撰寫程式，事先把查詢結果製作成網頁，所以使用者查詢的是早已產生好的網頁，即省掉資料庫重複存取造成的負擔。
這麼做的先決條件，是查詢結果的變異性不大，資料可能間隔數小時或數天之後，才會有所變化，那麼就可以考慮以這種方式處理。
當然，快取的技巧已經不只應用在資料層面，現在連程式及物件也有快取的解決方案。像是Oracle的Coherence及開放源碼的JCACHE及OSCache，用意都是把常用的功能或物件快取在記憶體以加速效能的設計。
快取擊中率（Cache Hit Rate）
就處理器而言，所謂的「快取（Cache）」，是指處理器架構中的「高速緩衝儲存器」，它位於處理器與記憶體之間。由於處理器的執行效能優於主記憶體，所以用快取來暫存可能頻繁存取的指令或資料，用以縮短存取 記憶體的時間。
而「快取擊中率」，指的是快取中暫存的資料是剛巧符合處理器需求的比例。例如處理器所需讀取的資料，100次中有70次在快取內找得到，便表示快取擊中率是70％。
而就軟體領域而言，「快取」指的就是記憶體。以應用程式為例，當記憶體發展到一個程度，開發者假定使用者的電腦有更大的容量可以存放資料，就會調整設計方式。例如文書或影像處理軟體，它們將更多的資料上載至記憶體，如此一來使用者存取資料時，快取擊中率便提高。
同樣的，資料庫應用也因為記憶體急速發展而有所改變，當使用者運用各種快取技巧，把使用者可能用到的資料上載至記憶體，便增 加了快取擊中率，也減少磁碟存取的機會。
記憶體資料庫與傳統資料庫相較，效能提升6～20倍
就資料的存取加速而言，無論是快取資料於記憶體，或事先產出結果頁的方式，加速的部分，其實僅在「查詢」層面。一旦使用者觸發「寫入」的行為，例如透過電子下單買／賣商品，快取的設計就發揮不了作用，系統仍需寫入資料至硬碟。
也就是說，針對「讀取」和「寫入」行為都很頻繁的應用，快取的作法幫助有限。唯有整個資料庫都搬到記憶體上運行，讀取和寫入資料的速度才能明顯加快。
加快多少呢？
根據Oracle針對自家記憶體資料庫TimesTen所做的測試，讀取1筆資料需要的時間是5微秒，也就是說1秒鐘可以查詢20萬筆資料；而更新一筆資料則需15微秒，等於是1秒鐘可以更新6.67萬筆資料。
對照專門測試IT產品並計算性價比的TPC（Transaction Processing Performance Council），在2009年以不同廠牌伺服器測試Oracle 11G標準版資料庫的存取效能，最佳的存取效能記錄是每秒完成10654.37筆交易，所謂「交易」有可能是查詢或者更新行為。
兩相對照起來，TimesTen 11G和Oracle 11G的存取效能有6～20倍的差距。
而IBM在相同軟硬體環境下，測試自家SolidDB和DB2的存取效能，更新資料SolidDB快5.26倍，而查詢資料的效能，SolidDB則快了19.27倍，也差不多是這樣的比例。
一般而言，資料庫應用通常是查詢的次數遠高於更新的頻率，以線上交易為例，使用者通常是廣泛地查詢各類商品後，才選定商品下單購物。在這樣的行為模式之下，記憶體資料庫對於存取效能的幫助更加明顯。 
引擎針對記憶體特性最佳化，讀取效能比快取更好
記憶體資料庫在市場已經有幾年的時間，不過臺灣IT界對這類產品的熟悉度有限。事實上，就IBM和Oracle推出的解決方案而言，它就是一個運行於記憶體的關聯式資料庫，可以單機運行，或者建置在傳統資料庫的前端。
對於熟悉關聯式資料庫的IT人而言，導入記憶體資料庫的學習門檻並不高。
那麼記憶體資料庫何以能超越傳統資料庫，提供快6至20倍的效能呢？首要原因是它把資料存放於記憶體，因此省去往返磁碟讀寫資料的過程，克服I/O的瓶頸。
其次，企業就算利用快取機制，把讀取頻繁的資料表甚至整個資料庫都上載到記憶體，仍舊不敵記憶體資料庫的讀取效能。原因在於，記憶體資料庫調整了演算法，它的引擎已針對記憶體的特性做了最佳化的處理。
交易日誌檔存於硬碟，關機資料不漏失
即使記憶體資料庫有優異的效能，不過很多臺灣企業沒聽說過這方面的解決方案。而相關解決方案廠商最需要努力的方向，是IT人對於資料存放於記憶體的信任程度。
硬碟畢竟是比較可以信賴的儲存設備，記憶體在一般的觀念中，屬於暫存資料的設備，伺服器一旦關機，資料將隨之消失。更不用說一個打雷、閃電或是供電不穩，記憶體就有可能發生漏失資料的情況。
事實上，相關廠商也了解這方面可能造成的問題，以IBM和Oracle的記憶體資料庫而言，為確保資料的完整性，快照資料庫的Checkpoint File和記錄每筆交易的Transaction Log，仍舊是存放於硬碟，當資料有所漏失或者發生伺服器需要關機重啟的情況，透過本身系統硬碟中的快照集和交易日誌，可復原資料庫至意外事件發生前的狀態。
當然，如果經費充足企業不妨選擇以兩臺主機搭配熱備援（Hot Standby）機制，當主要資料庫無法正常運行，自動由備援資料庫接手。
以IBM和Oracle記憶體資料庫的Hot Standby機制來說，在主要（Active）資料庫的伺服器出現異常狀況而無法正常運作時，系統會自動切換至備援（Standby）資料庫的那臺伺服器，接續線上的交易作業，使企業提供的服務不至中斷。
除此之外，備援資料庫還可分擔應用程式的查詢要求（Request），達到負載平衡的效果。
傳統的備援機制，在正常的狀態下，主要資料庫的任何異動，會透過Transaction Log將內容同步至備援資料庫。然而，除了同步資料，備援資料庫的資源幾乎是閒置的。
而目前兩家的記憶體資料庫解決方案，備援資料庫在預設情況下，不允許執行新增、修改及刪除資料的工作，但是可以處理讀取的要求，也就是說，它可以分擔來自應用程式的查詢需求。
快取模式下，記憶體資料庫的後端還有一個傳統資料庫
除此之外記憶體資料庫分為快取（Cache）及單機（Stand Alone）兩種運作模式。單機模式當然就是由記憶體資料庫獨立運行，藉由存放於硬碟的日誌及快照檔確保資料安全無虞。
不過，根據IBM和Oracle的經驗，多數企業選擇快取模式，畢竟不是所有的資料服務，都需要搭配極限的回應速度，資料全部都存放在記憶體資料庫的話，相對而言投資於記憶體的成本也會墊高。
而在快取模式下，記憶體資料庫只存放部分需要加速回應的資料表，而後端串連儲存資料於硬碟的傳統資料庫，前端記憶體資料庫的任何異動，會同步至後端的資料庫。若設計上前端的記憶體資料庫只提供查詢的機制，由後端資料庫負責處理資料的新增、刪除及修改，那麼後端的異動，也可同步至前端。 
適合計算不複雜且高吞吐量的資料庫應用
記憶體資料庫加速存取的效果明顯，不過，並非所有的資料庫應用都適合，分析它的特性，我們歸納出有以下3種特徵的應用，適合採用此類解決方案：
● 對資料存取的反應時間（Response Time）要求嚴苛
● 交易吞吐量大
● 計算不複雜
綜合3項特性，杜奕鋒認為：「B2C的電子商務網站可以考慮記憶體資料庫解決方案。」目前電信及金融業在國內外都有導入的案例。以電信業為例，每年耶誕、元旦及春節的簡訊量，經常超出資料庫的負荷，若善用記憶體資料庫，便可以更即時地消化簡訊用戶的需求。
那麼，哪些情況不適合採用這類的解決方案呢？目前看來，包含複雜運算的商業智慧應用，未必適合採用記憶體資料庫，原因在於記憶體資料庫目前尚不支援MPP（Massive Parallel Processing，巨量平行處理）架構。
也就是說，一個SQL指令無法由多個處理器平行處理，所以運用記憶體資料庫執行大量資料的複雜運算，效益未必明顯，因為「處理器」有可能成為效能瓶頸。
此外，如果資料庫的交易行為需要跨多個資料表，而且這些資料表的資料量很大的話，企業勢必要把巨量的資料都上載到記憶體資料庫，那麼就得評估此類解決方案的性價比（性能／價格）是否划算。
再者，雲義科技研發部協理王建興表示舉例：「現今有許多大型網站，例如Facebook運用多臺伺服器建置一個叢集（Cluster），組成一個巨量的記憶體快取，以加速網站的存取。」也是可行。
不過，可以確定的是，雖然，記憶體資料庫的可靠性未必低於傳統資料庫，但它目前仍然難以完全取代傳統資料庫。杜奕鋒表示：「最終還是需要一個硬碟保存的版本。」
再者，就成本考量，記憶體的成本高於硬碟，所以就現階段的企業案例，大多應用記憶體資料庫存放即時性需求高的資料，並不會把所有資料移往記憶體，因為這麼做並不划算。
所以對於企業而言，到底是採購多臺機器並設計快取，還是在少數伺服器上充實記憶體數量，並搭配記憶體資料庫，何者是划算的選擇，得視應用而定。這方面企業得評估多方條件，精算自身適合的解決方案。
資料「In Memory」的設計已存在多年
現今仍有不少企業擔心記憶體資料庫的可靠性 ，然而這並不是一個很新的技術。事實上，在IBM與Oracle推出的記憶體資料庫之前，市面上早已存在其他搭配記憶體資料庫的應用或產品。
只不過它們搭配的資料庫，並非傳統的關聯式資料庫，而是採用專屬的資料格式，而「In Memory」的用意，無非是希望加速存取的效能。
例如，在香港有一家稱為「MemDB」的公司，設計者專門為中小企業開發會計、零售、庫存、條碼列印及客戶管理軟體。這家廠商設計了運行於記憶體的物件導向資料庫，用它來儲存中小企業的會計、商品及客戶等資料。
不過，MemDB並不單獨販售記憶體資料庫，而是設計在應用系統中，透過程式存取。
這麼做的優點，是對於中小企業而言，系統占用的空間不多，而且使用簡單。缺點則是目前IT人員普遍對物件導向資料庫並不熟悉，而且企業若未來希望移轉MemDB中的資料至關聯式資料庫，以便自行管理，必須尋求廠商的協助。
其次，商業智慧應用產品QlikView也有「In Memory」的概念，企業匯入QlikView的資料，是以專屬格式運行於記憶體，有效加速了分析與執行的速度，而且根據廠商提供的資訊，資料壓縮比為1:20，所以可以節省記憶體的空間使用量。不過，專屬格式也代表被平臺綑綁，未來若有分享資料或轉換平臺的需求，同樣需考量資料移轉的問題。
事實上，也有一些線上遊戲業者自行實作「In Memory」的資料處理模式。因為線上遊戲玩家的位移、地圖及個人資訊，有即時更新的需求，一場戰役可能數千人同時上線，因此資訊異動的頻率很高，任何經驗值的變動都會影響戰役的勝敗。對廠商而言，記憶體化的資料存取才能應付如此巨量又即時性的需求。
這些例子顯示記憶體中的資料存取應用，已在各領域出現。只是評估解決方案時，是延續關聯式資料庫應用的產品，還是自行開發或者選擇格式專屬的封閉產品，是企業必須考量的重點。
徹底了解IBM與Oracle記憶體資料庫解決方案的差異
目前關聯式資料庫中，已正式推出記憶體資料庫解決方案的廠商，包括IBM的SolidDB及Oracle TimesTen，兩者的功能及架構大同小異。
主要的不同是IBM SolidDB支援串連多種異質資料庫，Oracle則限自家產品。SolidDB的開放性讓企業的選擇性更多，然而另一個層面也代表異質資料庫之間的語法差異，也會使開發及改寫的成本較高。Oracle因支援資料庫的限定，沒有這方面的負擔。
相同之處都有兩種模式可應用，並具備提升可靠度的機制
這兩家的解決方案，都分為快取及單機兩種模式。快取是比較多企業採取的策略，把需要加快存取速度的資料置於記憶體資料庫，而其他沒有即時性需求的部分，仍存放在傳統資料庫。而且他們都有Hot Standby，能提供企業高可用性的記憶體資料庫解決方案。
有快取及單機兩種應用模式可選擇
雖然Oracle和IBM提供快取（Cache）及單機（Stand Alone）兩種選擇，但目前多數的企業案例以前者為主。在快取模式下，記憶體資料庫只存放即時性需求高的資料，而大多數的資料仍存放於後端的傳統資料庫。
以線上交易為例，前端的記憶體資料庫，存放與交易相關、有高速存取需要的資料，由於少了硬碟的效能瓶頸，可以提供使用者更快的回應速度（Response Time）。而記憶體資料庫中的異動，透過Transaction Log仍會同步到後端的傳統資料庫。
而單機模式下，記憶體資料庫是獨立運行的系統，如果整體資料庫的資料量不大，可以考慮這樣的架構。企業不用擔心發生無法預期的狀況，導致伺服器當機或需要重新啟動時，儲存在記憶體資料庫中的資料將隨關機而消失。事實上無論快取或單機的運作模式，系統都會將Transaction Log和Checkpoint File儲存於硬碟，所以系統在重新開機後，可以恢復資料庫至關機前的狀態。
Hot Standby可供負載平衡及故障復原
事實上，從硬碟「倒」資料至記憶資料庫，算是比較沒有效率的故障復原（Failover）方式，企業可以善用IBM和Oracle提供的Hot Standby機制，當主要（Active）記憶體資料庫的伺服器，因軟、硬體種種的原因而導致無法正常運行時，能自動切換至備援（Standby）記憶體資料庫，接續線上的交易作業，使服務不中斷。
Hot Standby機制除了故障復原的作用之外，還兼具負載平衡的作用。也就是當主要伺服器正常運作時，備援的記憶體資料庫並非閒置狀態，等待切換，它可分擔來自應用程式的查詢需求，這使備援的那臺伺服器可以分擔主要資料庫的部分流量與工作。
當然，若要達到真正的負載平衡，可以設定多臺資料庫同時為「Active」狀態，不過，針對不同來源同時更新同一筆資料的衝突管理，管理者就必須手動設定管理原則。
不同之處IBM強調整合異質資料庫，Oracle較重視網格應用
分析兩家解決方案的不同之處，主要是IBM透過CDC（Change Data Capture）機制，使快取模式下，後端連接的資料庫沒有廠牌的限制。而Oracle則利用Cache Grid機制，使多臺TimesTen可以共享資料。
IBM的CDC機制使後端不限資料庫廠牌
相對於Oracle TimesTen的快取模式，限制只能搭配自家Oracle資料庫，IBM的SolidDB在最新6.3版，結合CDC（全名是InfoSphere Change Data Capture）機制，使後端可以串連各種廠牌的資料庫。
事實上，複製資料至異質資料庫的方式很多種，例如透過程式，設計資料同時寫入兩個資料庫。此外，也可以在資料庫中設定Trigger，當資料庫的內容發生任何異動，便自動觸發程式同步到另一個資料庫。然而，無論採用哪一種方案，都可能發生程式出問題或者資料庫「漏接」，導致資料庫內容不一致的情況。而且也會占用資料庫的資源。
而有了CDC 同步資料的好處，是透過Transaction Log異動資料，處理速度快，且耗用資源少。由於各家資料庫的Transaction Log格式都有一些差異，而透過CDC的運作，它介於SolidDB及後端資料庫之間，所以當任何一方資料有異動時，CDC的Access Server便解讀並轉換Transaction Log，成為目標資料庫可解讀的格式，達到資料同步的目的。 
Oracle的Cache Grid架構，使記憶體資料庫可共享資料
Oracle TimesTen最新版11G推出的Cache Grid，也是有別於IBM的重要特色。Oracle一直致力於Grid（網格）的應用，在記憶體資料庫方面也不例外。在Cache Grid架構之下，TimesTen資料庫可以在各自獨立運行的情況下，又共享資料。
Cache Grid適合相同應用但資料區分成不同主機的情況。以證券交易為例，券商依北、中、南區因客戶不同而區分不同的交易資料庫，但是當原本南部的客戶經由北部的交易主機下單時，北部的資料庫會詢問Cache Grid下的所有資料庫，是否有該筆客戶資料，如果有的話，複製到本機並回覆應用程式。
記憶體資料庫加速了資料存取的速度，但Cache Grid架構下，資料若在別臺TimesTen中，透過網路傳輸會稍微折損效能。不過Oracle原廠表示，由於資料庫傳送單筆資料的訊息量很小，所以對效能的影響並不明顯。 
該用記憶體資料庫嗎？
企業對於記憶體資料庫的常見疑慮在於：資料儲存在記憶體中安全嗎？斷電時怎麼辦？事實上，你還有一份足供備援的Transaction Log檔儲存於硬碟，所以並不需要擔心資料會消失。
其他問題如：備份機制為何？使用的語法還是SQL嗎？改寫系統的主要負擔何在？還有，使用上划算嗎？關於這些問題，這裡都有完整的回答。
Q1一旦斷電，資料就不見了？
這是目前大部分企業面對記憶體資料庫的最大疑慮，尤其記憶體的可信賴度遠低於硬碟。
然而記憶體資料庫除了儲存資料於記憶體，也有記錄檔存放於硬體，所以可以避免資料漏失的情況發生。
若是採用快取模式，記憶體資料庫的角色則類似「快取（Cache）」，所以相同的內容會同步到後端的傳統資料庫（Disk- based Database）。而即使在單機模式下也不用擔心，因為記憶體資料庫的交易日誌檔（Transaction Log）和快照檔（Checkpoint File）仍是儲存於硬碟，所以可以透過這些檔案復原。
Checkpoint File主要的作用是依管理者的設定，每隔一段時間對資料庫做一次快照（Snapshot），儲存資料庫當時的樣子，管理者可以利用快照集還原資料庫在某一個時間點的內容。
而記憶體資料庫在發生電腦當機或斷電的情況，在重新啟動時便透過Checkpoint File還原資料庫至最近一次快照的狀態，而從快照那個時間點到當機前的異動，則搭配Transaction Log填補，如此便可還原至斷電前的狀態。
以上是補救資料的方法，不過，相較於此，企業更在意的是線上作業停擺。
關於這方面，IBM和Oracle都推出Hot Standby的機制來因應。在正常的狀態下，主要（Active）資料庫透過Transaction Log將交易同步至備援（Standby）資料庫。除此之外，備援資料庫還可分擔應用程式的查詢要求（Request），達到負載平衡的效果。
而當系統偵測到主要資料庫的運作發生異常，即自動切換到備援資料庫，接續線上的交易作業，管理者不需要手動設定或重新啟動電腦。 
Q2在快取模式下，如果記憶體資料庫和後端的傳統資料庫斷線，系統如何處理？
若在記憶體資料庫的後端串連傳統資料庫，前後端雙方的資料同步，主要還是根據Transaction Log的內容。所以，即使發生斷線的狀況，主機恢復連線時，仍可透過Transaction Log補齊斷線階段異動資料。
這部分由於TimesTen的Transaction Log已調整成與Oracle資料庫相同的格式，所以兩者的資料同步沒有困難，管理者甚至可以設定逐筆更新或者定時批次處理。
而IBM則採取開放策略，SolidDB的後端可串連多種廠牌的資料庫，而資料的同步由CDC（Change Data Capture）機制處理，它自動轉換Transaction Log的內容，以符合各廠牌資料庫的格式，達到同步的目的。
Q3與其建置記憶體資料庫，何不擴充記憶體就好？
單純把記憶體放大的作法，與記憶體資料庫相較，存取效率還是會有數倍的差距。
傳統應用記憶體快取的作法，是把讀取機率比較高的資料，快取在記憶體，如此一來，可以增加查詢的Hit Rate（擊中率），減少磁碟存取（Disk I/O）的機會。事實上，依據資料庫的設計原理，在一般情況下，使用者查詢一筆資料，資料庫通常會連帶把該筆資料前後的資料，也一併快取在記憶體，方便後續的查詢使用。
然而使用者下一次的查詢，若未在快取的範圍之內，仍必須回硬碟查詢。再加上，使用者若有「寫入」的動作，勢必得將異動更新到實體資料庫，所以尤其是針對寫入動作頻繁的資料庫應用，增加記憶體以提升存取效能的作法，效果有限。
再者，記憶體資料庫的引擎，與傳統資料庫的設計有所不同，甲骨文大中華區臺灣技術諮詢部資深諮詢經理黃久安表示：「傳統資料庫找資料的方式，需要比較多的判斷。」而記憶體資料庫已針對記憶體的特性，做了最佳化的處理，所以效能優於資料庫搭配更大記憶體快取容量的作法。
Q4它的查詢語法與傳統資料庫有差別嗎？
就IBM和Oracle提出的記憶體資料庫方案而論，他們本身都是典型的關聯式資料庫，差別僅在於存取與執行的載體，是記憶體而非硬碟。
所以，也同樣採用SQL語法，對於熟悉關聯式資料庫應用的IT人，沒有太大的學習門檻。
不過，記憶體資料庫仍無法避免傳統資料庫存在的各家SQL語法有小差異的情況。這方面IBM SolidDB遵循ANSI SQL-92標準，而Oracle TmesTen則採用Oracle PL/SQL。
Q5既有系統若改採記憶體資料庫，主要的負擔何在？
無論採取快取或單機模式的記憶體資料庫，架構調整與程式的修改是主要的工作，哪些資料表需要藉助記憶體資料庫強化存取的效能，必須定義出來的。
架構面的調整方式與成本有關，如果資料量很大的話，整個資料庫改成記憶體資料庫的成本很高。
就資料庫的成本來看，根據廠商提供的建議售價，Oracle Standard版是5,800美元／處理器、Enterprise版的售價是47,500美元／處理器，TimesTen的售價是14,500美元／處理器。而IBM SolidDB的售價大致上是35,300美元／100 Processor Value Unit（PVU），而PVU的算法又與伺服器及處理器的等級有關。
大致上看來，記憶體資料庫的售價有可能高於傳統資料庫。再加上，伺服器的記憶體價格高於個人電腦。所以資料量、記憶體、資料庫授權如何搭配的性價比最高，企業需要進一步精算。
確立架構之後，畫出程式改寫的範圍。當架構改變，資料庫連結必須隨之調整。而就IT人員而言，程式的改寫是最主要的負擔。
臺灣澳圖美德資訊長杜奕鋒分析：「傳統寫SQL語法，為了避免Disk I/O，會盡量減少磁碟存取的次數。而在記憶體資料庫中，因為磁碟導致的瓶頸因素消失，SQL的寫法或多或少會有不同。」
尤其各家資料庫的SQL語法有小差異，所以程式及SQL的改寫是免不了的。這方面原先即採用Oracle的企業，導入TimesTen的負擔會小一點，因為兩者都採用PL/SQL，不用調整SQL語法。而選擇SolidDB則有不被特定資料庫平臺綑綁的好處。
如何面對與避免Legacy Code
文/iThome (記者) 2009-10-01
http://www.ithome.com.tw/itadm/article.php?c=57107
借助極限編程的作法，可以避免程式變成孤兒，此外，有效的測試能讓程式的修改者更具信心
大多的程式人都不愛他人遺留下來的程式碼（有些人甚至是用「痛恨」等更激烈的字眼），尤其是當這些程式碼的原作者已經離職而且無法聯絡上。這樣的程式碼，有人將它們稱為「Legacy Code」，中文則譯為「既有程式碼」。
這類的程式碼的特性，並不是在於它存活了很長一段時間，而是在於已經沒有人能夠理解甚至進一步修改。從這邊可以觀察出來，Legacy Code造成的困擾，正是在這兩個面向上──一個是理解，另一個則是修改。
既有程式碼可能代表著組織長久的經驗及智慧
Legacy Code固然會造成困擾，但是它偏偏又存在。大多數的軟體開發組織，都難免面臨開發成員來來去去的情況，只要有人離開，這人所負責的程式碼，便搖身一變成為Legacy Code。
尚在維護的系統毋需多言，只要還在線上運行一天，就不能因為有人離職而把它廢掉。而共用程式碼，對於開發組織的價值同樣很大，因為它代表組織長久以來的許多經驗及智慧的結晶。這些程式碼，通常代表著可重複使用的程式碼，使用它們可以大幅提升生產力。而這生產力的來源，不單只是因為它減少了撰寫程式的時間，同時這些程式碼經過反覆地運用，早已久經測試、百鍊成鋼。
這些程式碼累積了許多的經驗，長期以來的考驗及修改，有能力應付各種可能的情況。
砍掉重練未必是最好的選擇
Legacy Code無法拋棄，然而也讓人退避三舍，因為之所以會被稱為「Legacy」，是因為已經沒有人熟悉、能夠很有把握地修改。但只要我們還無法捨棄、作廢，終究必須試著和它和平相處，甚至進一步善用它的力量。
面對Legacy Code的第一個難題，就是了解並熟悉這些既有的程式碼。程式人都不愛了解別人所寫下的程式碼，寧願重寫。這是因為重寫新的程式碼，能夠有機會運用新的技術，另一方面，心中又會有那種「昨日種種譬如昨日死」的痛快感覺。
把一切打掉全新做起，就像毀壞一切的大革命，將建立起全新的國度，而在新的國度裡，一切都是那麼美好。不過，事實上，大多數人寫的程式碼一旦過了「保存期限」，終是落到慢慢「腐敗」的局面，新的世界並未來到，而程式人只是選擇再一次「砍掉重練」。
借助極限編程的作法，避免程式碼成為Legacy Code
對Legacy Code的了解與熟悉，是處理Legacy Code的基本功課，一點都不了解，就別說要做什麼處理了。
從技術的角度來處理這個議題，可以從兩個方向努力：加強閱讀程式碼的技巧及提升所寫程式碼的可讀性。
那麼，從管理上又要如何協助面對Legacy Code呢？簡單來說，就是從管理上盡量避免程式碼變成Legacy Code，也就是避免程式碼變得「沒有人能夠理解甚至修改」。
著名的極限編程（eXtreme Programming，XP）對此便多有著墨。或許你的組織並不是採用極限編程或者是其他輕量級的開發方法，但這精神也值得多加借鏡。
XP的12項實務中，系統隱喻（System Metaphor）、程式共享（Collective Ownership）、搭檔編程（Pair Programming）、以及編程標準（Coding Standards）等，都能避免程式碼漸漸成為Legacy Code。
關鍵在於，首先，它建立起組織裡共同而且持續性的符號及撰寫風格，使得每個程式人寫出來的程式碼幾無分別，其次，避免特定程式碼總是由特定人所維護。
這兩個關鍵是有關聯的，倘若不能做到所有程式人都使用相同的符號（主要是命名方式）以及撰寫風格，那麼同一份程式碼，便很難交由其他人維護或改寫。兩人搭檔編程的作用，不僅在於讓一人專職監看，同時也有利於內含在程式碼中的資訊及知識在組織中流動。
搭檔編程不見得廣為眾人所接受，但是它的基本精神值得參考。組織除了可以透過分散程式碼的撰寫及維護責任之外，也可以透過其他的方式，讓程式碼中的資訊及知識，有效地在組織之中流動。
大家都知道，由於時間的限制，工作的交接通常僅具形式，缺乏實質作用。因此，程式碼的撰寫及維護責任，倘若能平均的分散在組織中，而且資訊及知識也能有效流動，這便是一個長期持續作用的事情，即便有人員異動，程式碼也不容易成為Legacy Code，因為沒有任何人是任何程式碼的唯一主人。
Legacy和Non-Legacy Code區分的關鍵在測試
以上是針對避免Legacy Code產生而提出的應對方向。但即使是自己所寫下的程式碼，曾經深知所有細節，也有可能因為時間的過去，而對這些細節不復記憶，這些程式碼也有可能成為Legacy Code。倘若已經存在Legacy Code時，要如何與它和平相處呢？這顯然是一門大學問。
Michael Feathers曾經對Legacy Code下了另一個定義，他認為Legacy和Non-Legacy Code區分的關鍵，在於測試。
我想，如果害怕看不懂一組數量龐大的程式碼，是淺層恐懼的話，那麼Michael Feathers便捕捉到人們對於Legacy Code的深層恐懼──害怕修改數量龐大的程式碼。
的確，具備閱讀程式碼技巧的程式人，不難快速理解一組程式碼的基本運行架構，即使規模龐大。但是，我想絕大多數的程式人，都害怕修改規模龐大的程式碼，因為你深深明白，你知道如何修改來達成目的，但是，你也知道這修改真正難的地方，不在於了解並且修改程式碼，而是難在你不知道是否會引出許多意料之外的副作用。
Legacy Code只要能正常運作的話，本身並不會造成傷害，傷害都是企圖修改時產生的。所以，Michael Feathers明白地指出關鍵在於測試。有足夠的測試資本包括為了測試而寫的程式碼和測試案例，在了解大致運作方式之後，便有信心修改，因為測試會協助你找出因修改而發生錯誤的所在。
安心修改的前提──程式能有效測試
關於這個主題，Michael Feathers有本相當著名的書籍值得推薦──《Working Effectively with Legacy Code》。在這本書中，你會看到一套完整的理論及方法。簡單來說，測試是處理Legacy Code時的重要工具，必須倚靠它做為修改的信心後盾，以檢視修改作用是否造成不預期的副作用。
除了測試之外，這本書中所建議的技巧，可以協助我們找出Legacy Code中需要被截斷的相依性。為什麼相依性需要被截斷？因為相依性是修改發生時，衝擊所會傳遞的路徑。
依據他的建議，我們必須要適當地截斷一些相依性，使得我們能夠針對我們所做的修改進行測試。因為很明顯地，倘若沒有截斷一些相依性，縮小改變影響的範圍，那麼修改所影響的層面，便有可能隨著相依性擴散出去，這麼一來，測試的難度以及需要覆蓋的範圍便高上許多。
從測試來談Legacy Code是很有趣、也很實用的觀點。的確，處理Legacy Code的難處在於修改，想要安心地修改就要能有效地測試。透過截斷相依性的技巧，來輔助測試進行，更能確保我們對Legacy Code的修改更具信心。
甲骨文及昇陽聯袂展示新的OLTP伺服器
http://www.ithome.com.tw/itadm/article.php?c=57040
文/陳曉莉 (編譯) 2009-09-16
Exadata原為甲骨文品牌下專供資料倉儲使用的資料庫伺服器，只是先前甲骨文是採用惠普（HP）所製造的硬體。現在甲骨文則將Exadata 2.0稱之為Sun Oracle Database Machine。
甲骨文（Oracle）與昇陽（Sun）在周二（9/15）聯手展示了全球首款專供線上交易處理（OLTP）使用的資料庫伺服器─Exadata 2.0。該伺服器整合了甲骨文的軟體及昇陽硬體，為雙方宣布併購以來第一個採用共同品牌的產品。
Exadata原為甲骨文品牌下專供資料倉儲使用的資料庫伺服器，只是先前甲骨文是採用惠普（HP）所製造的硬體。現在甲骨文則將Exadata 2.0稱之為Sun Oracle Database Machine。昇陽則宣稱此一採用該公司FlashFire技術的Exadata產品為市場上供應資料倉儲及線上交易處理最快的資料庫伺服器。
甲骨文執行長Larry Ellison表示，Exadata 1.0曾是世界上最快的資料倉儲應用程式伺服器，但2.0版在資料倉儲上的處理速度為1.0的兩倍，而且它是目前唯一可執行OLTP應用程式的資料庫伺服器。
Exadata 2.0配備了甲骨文的Database 11g資料庫軟體及Oracle Exadata Storage Server軟體，內含混合列式壓縮技術（Hybrid columnar compression）、可鎖定壓縮資料進行智慧型掃描的系統及儲存索引等功能；在硬體上則採用了昇陽的伺服器，並運用昇陽的FlashFire高速傳輸處理技術。
昇陽表示，Exadata 2.0為一穩固的平行架構，可連結快速的伺服器，以及在儲存與資料庫伺服器間提供高速的寬頻連結，可加速資料庫的處理並呈現極佳的效能。它除了可加速線上交易處理能力外，亦適用於資料倉儲及各種資料庫任務。
此外，昇陽指出，Exadata 2.0結合了運算、儲存及網路技術，其處理器、輸入/輸出、記憶體系統、網路及效能都是針對甲骨文技術進行設計及微調。因此，該產品效能超越了前一代的Exadata，例如在FlashFire技術的烘托下，其隨機I/O的速度為第一代產品的20倍，I/O寬頻速度是Exadata 1.0的5倍，運算及網路效能則是1.0版的2倍。
Exadata 2.0總計有四種配置，企業可根據需求採購不同的資料庫及儲存伺服器數量，目前已開始供貨。
甲骨文在今年7月宣布將以74億美元買下昇陽，美國司法部已於今年8月通過此一併購案，但歐盟仍在審查該併購案，預計最慢會在明年1月19日前完成調查。（編譯/陳曉莉）
Oracel追查授權費發酵？IBM指DB2已成功搶客
http://www.ithome.com.tw/itadm/article.php?c=56957
文/蘇文彬 (記者) 2009-09-10
透過技術、移轉服務，IBM試圖瓜分部份甲骨文資料庫市場版圖，表示目前已有幾家國內企業通過POC，未來轉向DB2的可能性不低。
透過新版DB2 9.7及行銷、資料庫移轉方案的推動，IBM表示已有4家企業可望從Oracle倒向DB2陣營，這場資料庫市場攻防戰愈趨白熱化。
今年6月IBM發新版DB2 9.7，新版資料庫首度支援Oracle資料庫語法，其編譯器支援基於甲骨文資料庫開發的應用程式，讓企業不需要重新改寫應用程式，就可從Oracle平臺轉移到DB2 9.7。適逢甲骨文向企業用戶追查授權費引發不滿，使用戶醞釀出走潮。IBM祭出資料庫移轉、免費評估方案，強力拉攏甲骨文用戶。
今天IBM向媒體說明資料庫移轉內容時指出，透過移轉方案及企業資料庫移轉成本分析、效益評估，部份企業可望從Oracle轉移至DB2市場。IBM表示，目前已有38家企業對DB2感興趣，10家企業接近進行POC概念驗證，4家完成POC的企業雖還未簽約，但未來可望轉向DB2，包括銀行、證券及製造等產業。
IBM軟體事業處經理胡育銘表示，以往資料庫移轉對企業最大的困難就是應用程式改寫的問題，不過在最新的DB2 9.7推出後，因開始支援Oracle資料庫語法，如PL/SQL、SQLPlus、Package、Currency Control、SQL等程式設計語言、格式，已能在DB2上執行原來於Oracle資料庫環境下開發的應用程式。不過支援甲骨文語法只是過渡，基於開發容易的觀點，IBM還是希望企業最終改以IBM DB2語法開發應用。
不過，IDC企業應用分析師鍾翠玲則認為，雖然其他業者積極以技術、價格、服務增加誘因，試圖提昇其市場版圖，但資料庫轉移對企業而言茲事體大，還要考慮到資料庫寫入、程式語言、穩定性等等因素，且需經過至少3個月以上測試期，故短時間內因競爭產生的移轉效果還不會那麼快浮現。另一方面，採用其他資料庫也涉及企業文化、習慣問題，這些都會影響企業轉移決策。
而對於IBM祭出移轉方案拉攏甲骨文客戶，甲骨文則表示，未感受到市場風向改變，據IDC數據，甲骨文仍以39%的市佔領先第二名11個百分點。
甲骨文資料庫銷售顧問資深經理黃久安認為，企業在規劃資料庫採購預算時，除初期軟體授權費用外，更重要的還包括後面隱藏成本，如重複採購成本、系統維運穩定性、效能調校、擴充彈性、維護服務及管理人力等等，應得總成本方面來思考。
他進一步指出，隱藏成本包括平台轉換產生的重複採購成本，儘管軟體成本低，但仍會有重複成本產生；平台上運行的應用系統及IT架構也須跟著修改，而轉移後還要很長一段時間測試確認沒問題才能上線，上線後也還需要一段測試期才能邁向穩定應用，種種轉移間的冗長過程、測試、改寫成本都要考量進來
離職工程師「好玩」惡搞 成台哥大跨年夜當機元兇
http://www.nownews.com/2009/09/01/91-2499852.htm
NOWnews 更新日期:"2009/09/01 11:29" 社會中心／綜合報導
台灣大哥大在今年跨年夜發生大當機，導致2萬多名用戶訊號中斷，原以為是話務量大造成系統故障，但經公司內部清查懷疑是有人蓄意惡搞。調查局北機組調查發現，是承包台哥大維修工程的諾基亞公司離職工程師陳懷先所為，最後檢方依妨害電腦使用罪嫌將他起訴。
台哥大當機造成新竹以北以及花蓮縣等地逾2萬名用戶訊號中斷，事後，業者趕緊提出補償方案，依用戶所選擇月租費方案，贈送價值10至25元不等的簡訊費用。據台哥大估計，當機事件共造成約1500萬的損失。
台哥大原以為是跨年夜話務量大，才導致系統故障；不過經過內部清查發現，是遭人入侵主機刪除資料造成大當機。台哥大同時向調查局北機組檢舉，最後查出是離職工程師陳懷先(29歲)所為，他在接受檢方偵訊時表示，是因為一時興起，單純只為了「好玩」才這麼做。
根據檢方調查，陳嫌原是承包台哥大維修工程的諾基亞公司的工程師，也因此熟知內部處理通訊主機的操作以及帳號與密碼。他在去年3月底遭公司解雇，在心生不滿的情況下，涉嫌以女友名義，在跨年夜登入台哥大主機刪除資料，導致無法重新開機，造成用戶訊號中斷。
板橋地檢署依妨害電腦使用罪嫌將陳嫌起訴，由於陳嫌是蓄意惡搞造成用戶無法通訊，可能因此妨礙緊急事故聯繫，檢方認為其行為罪性重大，將具體求刑2年。
用了 Oracle 騙很大，用 Oracle 的資訊主管就該死嗎？
從去年底開始，軟體公司為了救業績祭出殺手金間，有的不顧過往與客戶對於授權數量的協議，而要求企業限期內補足授權數量；有的不顧企業的營運壓力沉重，反而選在不景氣的時候調漲軟體維護合約價格。
2009 年5月我多家企業都收到Oracle軟體授權管理服務部門來函，要求企業限期補足資料庫的授權數量。收到通知的資訊主管都相當氣憤，他們指出，廠商為了把軟體賣給企業，一開始就允許企業不必買足授權數量，然而卻在此時打破這個默契，二話不說就寄來要求補齊授權的存證信函，使得資訊主管難以面對老闆的質問，甚至是信譽掃地。
軟體廠商瘋狂追補授權，企業開始反撲
企業面對一波又一波的軟體使用清查，如何釐清合法使用情況以及授權方式不合理等問題都浮上檯面。企業所質疑的，不只是軟體廠商背離誠信追補授權的表象，對於隱藏在這個表象後面的諸多不合理處，才是爭議所在
企業十分不滿廠商主宰軟體授權
總共有166 家企業回覆了本次的問卷調查，其中有126 家企業都透過文字寫出了軟體授權的不合理之處，無奈之情溢於言表
企業必須覺醒，尋找替代方案才能有籌碼
面對軟體廠商的不平等條約，企業必須覺醒，找尋其他替代方案的可能性，展現一種態度，增加談判籌碼
軟體授權只授予企業使用權，而非著作權
依照臺灣對著作權法的保障，企業若違反軟體授權合約，極易同時違反著作權法
軟體廠商的回應
針對126 位資訊主管提出的軟體授權與維護合約問題，提問9家大型軟體廠商
政府應立法讓軟體授權可轉移
企業對於軟體授權不合理之處，可以透過向公平交易委員會檢舉，對軟體廠商施壓，以爭取更合理的軟體授權方式
認清BSA如何執行查緝
當BSA 夥同檢察官與警察進行查緝工作時，要仔細看搜索票的執法範圍，並詳細確認執法人員清查的軟體種類與數量
降低軟體費用的四大策略
廠商查盜版，企業開始思考尋找替代方案
以資產管理軟體快速清查軟體使用狀況
透過資產管理軟體可以即時知道企業內部軟體的數目與種類
用Workflow串接工作流程節省軟體授權數量
連展科技以Workflow串接流量，降低企業使用軟體的授權數量，並達到稽核的效果
Oracle追補企業軟體授權
廠商狂追授權 企業群起控訴
http://www.ithome.com.tw/itadm/article.php?c=56462&s=1
http://www.ithome.com.tw/itadm/article.php?c=56461
戰國策爆發客戶資料外洩事件
http://www.ithome.com.tw/itadm/article.php?c=53022
戰國策資料全都露 用戶毫不知情
http://www.ithome.com.tw/itadm/article.php?c=53031
知名主機代管商戰國策，爆發客戶資料外洩事件，包括代管主機的登入密碼與客戶的資料，都在搜尋引擎上找得到，目前多數搜尋引擎已經清除這些個資，建議使用者立即更換密碼
國內知名的網站主機代管服務廠商戰國策，日前爆發訂單系統資料外洩事件。當時透過Google輸入特定的關鍵字，可以找到4,270筆「訂單詳細資料」網頁，而這些網頁的資訊包括了客戶公司名稱、聯絡人姓名、身分證字號、電話、地址、電子郵件、交易方式、金額、主機方案，以及代管主機的IP位址、帳號、密碼、網域名稱等資訊。建議使用該代管服務的使用者，應該立即更換密碼。
戰國策行銷部經理吳婉真表示，該公司於1月9日上午就已經發現此一事件，旋即做出處理，並且通知Google，要求將快取檔案移除，Google已於1月10日將相關快取頁面移除。吳婉真說：「我們內部系統一直以來都有IP認證，這次會發生這樣的問題，是因為Google的網路蜘蛛程式不知何故造成，詳細的原因我們也還在調查中。之後我們會持續改進，強化資訊安全的防護，對客戶負責到底。」
由於戰國策不願說明造成此事件的原因，目前也只能透過幾個方面猜測原因。一位不願透露姓名的主機代管廠商主管表示，如果有做到登入身分的控管，例如IP位址與登入帳號、密碼的比對等，Google的網路蜘蛛程式不可能有辦法存取內部訂單系統的資訊。他說：「最有可能的是系統做了異動之後，忘記加上身分認證的功能，然後內部管理人員的瀏覽器安裝了類似Google Toolbar的工具軟體，使得Google的伺服器可以收集到內部系統的網址，網路蜘蛛才有辦法循線收集到這些網頁。」
一般人可能沒有注意， Google在隱私權條款中寫到，「當您造訪我們網站或使用我們的其他產品時，Google伺服器會自動記錄資料，包括URL、IP地址、瀏覽器的類型和使用的語言以及造訪日期和時間。」
為了防止網路蜘蛛程式搜尋資訊，多數網站會在網頁上放上宣告網路蜘蛛禁止存取範圍的「robots.txt」文件檔，根據記者的調查，現在戰國策網站上的robots.txt最後的修改時間是在1月9日下午7點。但並無法確定當時這個宣告檔是否有起任何作用。
截至記者發稿前，仍可在較不知名的搜尋引擎上找到這些「訂單詳細資料」的網頁，建議該公司的客戶應該立刻更改系統的密碼，以免網站被入侵。
研究：2008企業資料外洩大幅增加
http://www.ithome.com.tw/itadm/article.php?c=52921
2008資料外洩件數總計有656件，比2007年的446件增加了47%；一般企業的資料外洩有愈來愈嚴重的傾向，自2006年佔21%增加到去年的36.6%。
根據資料竊盜資源中心（The Identity Theft Resource Center，ITSC）周二（1/6）所公布的報告，2008資料外洩件數總計有656件，比2007年的446件增加了47%；其中一般企業的資料外洩情況更有愈來愈嚴重的傾向。
去年8月ITSC就曾發表相關數據，指出截至去年8月為止，資料外洩件數就已超越前年一整年的結果。不過，此一資料外洩增加的案件比例與去年相仿，2007年的資料外洩件數亦比2006年增加4成。
ITSC主要觀察五個產業的資料外洩情況，包括一般企業、教育、政府及軍事單位、健康及醫藥產業及金融產業，發現一般企業的資料外洩有愈來愈嚴重的傾向，自2006年佔21%增加到去年的36.6%，教育領域則是自28%減少到20%，政府及軍事單位則是自30%大幅降低到16.8%，健康醫療產業從前年的13%到去年的14.8%，金融產業則是自8%增加到11.9%。
根據ITSC的報告，所有的資料外洩案件中，只有2.4%採用加密等重要保護方式，只有8.5%有密碼保護，這代表非常多的外洩資料完全沒有加密或密碼保護。
至於資料外洩的途徑，ITSC表示，雖然人為的疏失已有大幅改善，但仍佔35.2%；而旅行中資料遺失則佔20.7%，意外揭露佔14.4%，駭客惡意攻擊及內部竊賊的比例約佔29.6%。其中，內部竊賊的比例達15.7%，為前年的兩倍，駭客則佔13.9%。
電子型態的資料外洩也以82.3%遠超過文件資料外洩的17.7%。而有通報的外洩資料總計為3570萬筆，但其中尚有41.9%的案例未通報，因此波及的資料筆數應該更多。依此比例換算，2008年外洩的資料約達8520萬筆。
根據這三年來的結果分析，ITSC建議各單位盡量減少讓使用者存取個人身份資料的機會、要求在行動裝置上儲存身份資料的用戶要加密這些資料、限制可將機密資料帶出辦公司的人數、加密所有傳送或備份的資料、要丟掉紙本機密資料時務必完全銷毀、確保儲存機密資料的電腦或伺服器安全，以及訓練員工保護資料的習慣等。
資料完全銷毀
http://www.ithome.com.tw/itadm/article.php?c=56148&s=1
很多不同的資料銷毀方式，流傳在這個世間。但是到底要做到什麼樣的程度才能確保儲存媒介上的資料完全銷毀呢？以硬碟為例，如果把硬碟丟到水裡，就完成了銷毀工作嗎？
很多不同的資料銷毀方式，流傳在這個世間。
但是到底要做到什麼樣的程度才能確保儲存媒介上的資料完全銷毀呢？以硬碟為例，如果把硬碟丟到水裡，就完成了銷毀工作嗎？消磁機真的萬無一失嗎？或是用火燒整臺硬碟，真的就可以完全銷毀資料嗎？
這些疑問，我們都將透過這次的報導替你解答。透過各個領域的專家，剖析紙類、硬碟、磁帶等儲存媒介，用哪一些方法才能真正達到「資料完全銷毀」的結果，解答各種小道偏方的實用度。
資料真的徹底銷毀了嗎?
網路上常會看到一種摧毀硬碟的方法，那就是把硬碟丟到水裡泡水，但是這樣真的就完全不可能救回資料嗎？這可能不一定。
硬碟篇─徹底銷毀硬碟資料的7大方法
我們將要介紹7種不同銷毀硬碟的方法，這些方法分別是格式化、滴鹽酸、火燒、鐵鎚敲、泡水、消磁與刀割碟片。
紙類篇─碎斷式碎紙機才能夠完全銷毀紙張
如果碎紙時，依照文字排列的方向放入長條式碎紙機，結果就很有可能會是整行的字依然清晰可見，無法達成資料銷毀的效果。
磁帶篇─縱面剪斷才能確保磁帶銷毀
之所以要用縱面剪斷的方式，是因為如果採用橫面剪斷的方式，還是有可能讓有心人士從片段的磁帶取得資訊。
重大個資外洩又一起
http://www.ithome.com.tw/itadm/article.php?c=55693
目前立法院在協商的「個人資料保護法」，要求擁有5千筆個資的機構就必須要遵守個資法的規定
上個禮拜東森購物又傳出一起個人資料外洩的事件，這次是有一位自稱為阿哲的民眾，在網路上張貼販售東森購物交易資料的訊息，說他因為輸錢而急於求現，1筆資料只賣0.5元，而且他還為了取信於人，特別將內含8千筆交易資訊的Excel檔案，放在網路硬碟供人下載。
我們知道消息之後，循線下載到這個Excel檔案，看到裏面所記錄的交易資料，真是觸目驚心。這個檔案是2008年11月7日的交易記錄，內容詳細記載了訂單日期、客戶姓名、商品名稱、訂單金額、付款方式、配送地址、家裏電話、行動電話、信用卡號、發卡銀行、信用卡過期日期等等資料，看了不禁讓人捏一把冷汗。
8千筆個人資料已經是不小的數目了，目前立法院在協商的「個人資料保護法」，要求擁有5千筆個資的機構就必須要遵守個資法的規定，更何況這位阿哲釋出的這8千筆資料只是做為示範，如果他真有打算要藉此謀利，而且1 筆只賣0.5元的話，那顯然他手上握有大量的東森購物交易資料，如此事態就更加嚴重了。
從初期外洩資料的完整性來看，這份資料很可能是由內部流出的。據知情人士指出，東森購物是以一個單獨的資料庫來記錄交易信用卡的卡號，而客戶訂購商品品項則記錄在另一個資料庫，然而這份Excel檔則同時記載著信用卡卡號與商品品項，可見這個Excel檔已經合併了多個資料庫的資料，也因此，其中不乏資料整併的錯誤。姑且不論資料的正確性，光是要能合成出這份Excel資料，而且還被公開地展示，用來招攬生意，足以見得事態的嚴重性。
線上購物網站掌握的客戶資料頻頻外洩，讓詐騙集團有機可乘，事件層出不窮，無法有效杜絕，使得各界不得不重視個人資料隱私保護的重要性。現在，新版的個人資料保護法立法在即，雖然仍處於藍綠立委協商的階段，但在整個國際大潮流的趨使下，個人資料保護法終究會通過，只是時間的早晚而已。而東森購物這件個資外洩的事件，正可以讓我們思考個資外洩的防護上，除了要抵擋外部竊取之外，也得防範內部同仁蓄意外流。關於這個事件的經過與進一步的分析，請見本期新聞報導（請見第16頁）。
本期封面故事則是報導明年企業財報格式的新標準──XBRL，全名為Extensible Business Reporting Language，是一個以XML為基礎的財務報告語言，希望藉由XML結構化標籤的優點，讓財務報告有一個共通的資料格式的標準，使得財務資料的取得、交換與分析能夠更加方便。
你可以想像一下，德國公司的系統可以直接讀臺灣公司的財報？這件事在目前並不容易達成，需要透過種種的轉譯才行；但是如果臺灣公司的財報是遵循XBRL格式，那麼德國公司就算是看不懂中文，只要其系統能支援XBRL，就可以直接讀出財務報表裏的財務資訊，絲毫不須理會這份財報可是用中文寫的。
可以想見，企業財報採用XBRL國際標準後，可以跟國外的資本市場有更好的連結，這也就是證交所要求上市櫃公司提交XBRL格式財報的原因。明年9月以後，所有上市櫃公司的財報就都有XBRL版本，而未來XBRL還可以延伸至非財報的應用，目前有些國家已經率先進行，值得觀注。（請見第24頁）
http://www.ithome.com.tw/itadm/article.php?c=55399
國泰世華銀行的核心系統轉換，在端午節4天連假中順利完成。不過，新核心系統上線第一天，部分交易服務就一度停擺，其中，除了網路銀行以及補摺機等自動化交易服務之外，匯出匯款業務也曾暫停。國泰世華銀行表示，主要是因為交易量爆增，加上分行人員對新核心系統還不熟悉，進而影響到系統效能。
國泰世華銀行資訊長章光祖說：「新系統上線，小狀況多多少少一定會有，但是整體來看一切都很順利。」而新系統上線第一天就出現部分服務停擺的棘手問題，主要是因為交易量瞬間爆增，加上分行臨櫃人員對於新系統不熟悉，進而造成系統的反應速度緩慢。
章光祖進一步表示，為了讓分行臨櫃作業順暢執行，國泰世華不得不短暫停止自動化交易等局部服務，進而調整硬體資源配置，並且把資源集中在分行等第一線交易系統上。國泰世華銀行的新核心系統，在經過2年多的開發之後，去年11月正式邁入測試階段，過程中，經過將近半年的嚴格測試，最後決定在5月底的4天連假進行轉換，但是，新系統上線的第一天，就承載了70萬筆的交易量，相較於平日至少增加了3成，對於系統造成的負擔無庸置疑。
由於新核心系統上線的第一個營業日，是在4天連假結束之後，而且又適逢月底轉換月初，所以，交易都擠在同一天而爆增。國泰世華銀行新核心系統專案經理闕壯興表示，新核心系統上線之前，就經過10次的測試，舉凡月初日、月底日、發薪日等都是原本就預想過的情況，也針對這些情境做過測試，因此，即使新系統上線的第一天，就出現系統資源緊繃的狀況，但在經過適當的調整之後，自動化交易服務等問題都在半小時內得到解決。
除此之外，為了讓第一線的作業即時完成，國泰世華也把一般匯款業務，放到第二順位處理，進而把IT資源集中在公司戶以及證券交割等方面的業務處理。為了因應這樣的調整，國泰世華銀行事先已經跟財金公司提出申請，才能把匯款業務的作業時間往後延長一個小時。
國泰世華銀行原本的核心系統在5月28日零點正式走入歷史，新的核心系統也在5月29日凌晨1點鐘啟動，中間只有停機25個小時，遠低於國泰世華銀行合併時，停機40個小時的記錄，也比原訂目標提早了1小時完成。過程中，國泰世華銀行把服務據點區分成分行、便利商店以及捷運等4大群組，然後依序啟動。文⊙楊惠芬
機場當機與希捷韌體事件的省思─你的硬碟還健康嗎？
http://www.ithome.com.tw/itadm/article.php?c=53597&s=2
機場當機與希捷韌體事件的省思─你的硬碟還健康嗎？
今年初始，就發生了兩起和硬碟相關的大事件，首先是1月5日，桃園機場大當機36個小時。根據移民署的說法，起因是硬碟與磁碟陣列系統過度老舊，導致1、2航廈儲存系統的硬碟同時損壞，讓整個出入境系統無法運作，這一事件的後果就是，在當機的36個小時中，有8名通緝犯成功的逃亡出境。然後在1月19日，全球最大硬碟製造商希捷（Seagate）在官網上坦承包括Barracuda 7200.11、DiamondMax 22以及企業等級的Barracuda ES.2在內的3個系列硬碟產品，許多型號的韌體都必須更新，否則可能會導致BIOS無法找到硬碟、通電後無法動作、系統當機等問題。此消息一出，使用者一片譁然，某位不願具名的磁碟陣列經銷商更表示，他至少賣出了數千顆有問題的硬碟，幾乎不可能一一協助企業更新韌體。
機場當機事件：
備援系統的硬碟也失效
先來看看桃園機場的事件，內政部移民署副署長黃碧霞在先前接受iThome電腦報周刊訪問時指出，因為系統老舊，線上和備援系統的硬碟同時損壞，是當時機場大當機主因。此外，維護廠商對系統的不熟悉可能也是原因之一。據了解，由於護照查驗系統的維護，是每年一標的維護案，而「98年度電腦設備暨相關軟體維護案」的競標，是在2008年12月31日決標，系統維護廠商在事發前，才剛從大同公司轉由神通電腦負責，兩家公司並沒有正式完成交接，神通電腦是在完全不了解系統架構與概況的情況下，搶修護照查驗系統。
由桃園機場的事件，企業使用者可以看到幾個教訓，首先就是，硬碟定期更換對於企業和組織的重要性。但問題是有多少企業有定期監測硬碟的使用狀況？超過保固年限是否就會更換？桃園機場的前車之鑑正好再次提醒了使用者，在企業的應用環境中，硬碟健康狀況的確認，是十分重要的一環。除此之外，維護人員對於儲存系統的了解，也必須是企業重視的一環，否則在系統出問題時，很有可能會因此無法快速修復系統，導致影響營運的時間更為拖長。
希捷硬碟韌體事件：
出錯原因不明，開關機頻繁可能會導致硬碟失效
而另一個事件，希捷的韌體出錯事件，則和上述不同，是企業自己也無法預防的產品瑕疵事件，當企業遇到這樣的事情時，為求安心，可能需要大規模的更新韌體。這件事說起來簡單，實際上卻是吃力不討好的工作，因為這代表著企業的資訊人員必須先將資料備份，然後停止磁碟陣列的運作，之後再一臺一臺的將硬碟拿出來與電腦連接，進行韌體更新。如果硬碟數量一多，在實際執行上，這幾乎是不可能的任務。在網路上討論區中，就有人指出，依照希捷提出的型號，該公司有480顆硬碟必須更新韌體，如果依照上述的做法進行更新，非常曠日廢時。
關於這次事件，希捷的官方聲明稿中坦承韌體出錯，但對於韌體如何出錯的技術細節，則完全沒有提及，僅在聲明稿中重申，硬碟因為此一問題而毀壞，資料並不會因此消失，並且提供客戶服務的網址與連繫電話。一位不願具名的磁碟陣列廠商表示，他們現在也無法確定韌體出錯的真正問題，與希捷技術人員溝通的過程中，技術人員對於問題所在也語焉不詳。但根據他們的實測，系統開關機的次數越頻繁，硬碟越有可能發生希捷所描述的症狀。
對於此一問題，截至截稿前，臺灣希捷都不願意提供我們關於此一事件技術方面的任何回應，因此我們也無法證實是否上述的說法為真。不過企業也不需過度恐慌，根據目前的了解，多數磁碟陣列廠商都表示，目前希捷硬碟有問題的型號，在企業端磁碟陣列上使用，都還沒有客戶回傳發生錯誤的消息，可見影響層面不大。
1月19日，希捷在官方網站上坦承三種型號的硬碟韌體出錯，可能會造成BIOS無法找到硬碟、通電後無法動作、系統當機等問題。
上市櫃公司明年財報須遵循XBRL
http://www.ithome.com.tw/itadm/article.php?c=53185
2010年中開始，臺灣所有上市上櫃公司申報的財務報表格式將有重大變化，企業必須採用XBRL標準來製作財務報表，證交所已先建立XBRL示範平臺來宣導。
臺灣證券交易所於去年12月29日啟用XBRL示範平臺，宣示了臺灣股市財務資訊開始邁向標準化的第一步。未來，所有上市上櫃公司申報的財務報表格式，將有重大變化。
上市上櫃公司必須定期申報企業財務資料，過去主要用Excel檔或PDF檔來製作這些財務報表。但是，從2010年的半年報開始，金管會要求上市上櫃公司，須採用XBRL格式來製作申報的財務報表。金管會表示，初期參考國外實施方式，先採雙軌制，企業同時要提供新舊格式的財務報表。
XBRL（eXtensible Business Reporting Language）是國際最常使用的財報資料格式，在XBRL格式中，採用XML語法來呈現財務報表的會計欄位資訊，美國早在4年前就開始試行。
上個月17日，美國聯邦證券交易委員會（SEC）更進一步強制規範，資本額500億美元以上規模的企業，從2009年起，要開始提供XBRL格式的財務報表，其他公司則需在兩年內採用。
相較於美國，臺北商業技術學院會計資訊系教授周濟群表示：「臺灣導入XBRL的時間比較晚，大約和南韓、泰國同步。日本、中國早已採用，新加坡甚至運用XBRL格式來製作一般工商資訊的相關報表。」
金管會表示，臺灣將從2010年的半年報開始實施XBRL，強制規範上市上櫃公司採用XBRL格式來製作財務報表，同時也增加申報的報表種類，從過去的兩大表增加為四大表，包括資產負債表、損益表、現金流量表及股東權益變動表。
不過，對於企業提供的附註資料，例如公司介紹、文字敘述、圖片等資訊，則是參考美國2005年的簡化版本，以段落為單位來加註XML標籤，減少企業的轉換負擔。金管會表示，在轉換初期，會先採取雙軌制，讓新舊格式並行，確保資訊的正確性和完整性。
換言之，從2010年下半年開始，企業必須提供兩種不同格式的財務報表電子檔，包括舊有格式和XBRL格式各一份。
為了向企業推廣XBRL格式，從去年底開始，臺灣證券交易所舉辦公聽會，並且建立示範平臺，將過去五年的財務報表資料轉成XBRL格式的資訊，還在平臺上提供交叉分析工具。臺灣證券交易所上市服務部副理陳欣昌表示：「財報資訊透明化以後，更容易進行深入的投資分析。」
陳欣昌解釋，格式統一後，投資人就能很方便地使用電腦軟體來分析XBRL格式的財報資料，不需自行從各家企業的報表中人工彙整資訊。此外，「因為XBRL是國際標準，所以，還能用來和國外企業的財報資訊比較，財報資訊的利用更多元。」陳欣昌說。
對企業而言，周濟群認為，XBRL有助於跨國企業的內部營運，他說：「若企業ERP總帳採用XBRL格式，就能用同一套標準來符合各國的規範，更容易管理各地子公司的財務資訊，像SAP或Oracle等國際大廠的ERP都已內建了XBRL格式。」
企業財報採用XBRL格式，還需有一套共同的會計分類標準。臺灣證券交易所的XBRL工作小組已開始制訂這套分類標準，目前正在蒐集企業與各家會計師事務所的意見，預定於今年第三季公布。
為了降低企業轉換報表格式的負擔，陳欣昌表示，臺灣證券交易所將免費提供轉換格式的軟體，類似現行的軟體報稅工具，讓企業或會計師事務所可以很容易製作出符合XBRL規範的財務報表。
目前，臺灣證券交易所宣導XBRL的對象，先以企業財務人員與會計師事務所為主，但是，周濟群建議企業資訊部門可以開始了解，他說；「以臺灣現行會計運作方式，多由會計師事務所產出最後的財務報表，初期對資訊部門的影響不大，但長期而言，XBRL是企業會計資訊的基礎，CIO需要開始了解XBRL的發展。」文⊙王宏仁
透過XBRL，傳統財務報表的會計資訊可轉換成用XML表示的資料檔，讓投資人更容易用電腦軟體來分析財務資料。
資料整合的新一波趨勢︰主資料(Master Data)管理
http://www.ithome.com.tw/itadm/article.php?c=52201&s=1
在企業IT整合的方法中，專門針對主資料管理的解決方案和技術，逐漸成為許多大型軟體供應商所強調的部分，包含ERP、資料庫、資料倉儲等廠商，都已正式推出具體的產品。
對當前的企業來說，如何讓既有的資訊變得更正確、精準，仍不太容易。而且這些資訊當中，有些類型相當特別，因為是許多應用系統、交易程序都會用到、存取的部分，所以很重要，等於與企業營運的命脈密切相關，這種資料稱為主資料（Master Data），舉例來說，它們可能是所謂的基本資料，包括顧客、產品、員工、地點、資產、原料等主題。
企業必須設法維護主資料本身，做到一定的品質，例如內容的可信度高，同時又是獨特而不重複的；而且，重點是主資料要在既有的營運流程中妥善運用，例如銷售、行銷、財務等，協助企業內外相關的使用者，能夠在流程上更快速地作業。
此外，企業也逐漸意識到，可以藉助主資料與既有系統的搭配、運用，來改善既有的商業流程與決策，這些因素都使得主資料管理（Master Data Management，MDM）受到更大的關注，幾乎是繼商業智慧之後，再次驅動資料整合下一波應用的新動力。
用法上容易與資料倉儲混淆
因為牽涉到交易系統的處理程序，MDM的實際資料處理作業上相當複雜，而且需要考量到多種因素。所以當我們一開始去修改資料時，雖然執行程序和路徑要維持不變，但這些資訊的變更，不只是要傳到主資料管理系統上，然後這套系統的資訊，也要能再傳回既有系統上。
而且，到了其他系統都可以和MDM相互存取的階段，會有一種複雜的狀況發生：當後端的資料庫異動，而主資料管理系統本身的資料，也因其他系統的作業而變更主資料內容時，這兩邊的資料同步該怎麼處理？
從MDM到既有系統之間，固然可以採用發布與訂閱的方式來同步處理，但相反地，資料從既有系統如何同步到MDM才是重點。目前雖然有既定的工具可運用，但是這些又跟主資料管理系統無關，只是執行專案過程中一定要做的事情。總而言之，這些過程企業需要通盤考量，並且找到比較理想的技術和方式。
還有更複雜的，例如MDM和資料倉儲相互搭配。很多人可能會把資料倉儲和主資料管理混為一談，以為兩者都在做一樣的事情。其實資料倉儲對MDM而言，屬於既有系統的範疇，因為那邊的資料通常是由應用系統端，透過ETL工具再進到資料倉儲，然後這裡面又可能衍生出好幾個資料超市（Data Mart）。
這麼看來，主資料管理和資料倉儲之間似乎存在一些曖昧的關係，但它們之間有何不同？
如果主資料管理裡面的顧客資料，已經有一個完整的檢視，而且內容是最新的，這些資料其實是可以給資料倉儲來使用的。但資料倉儲本身在處理過程中，會再分析出很多資訊，這些過去很少回饋至交易系統端。如果能做到，前端服務的專員能夠同時掌握顧客的VIP等級與流失率，業務運作上會更妥善。
就主資料管理和資料倉儲而言，它們之間是相互協調的，而不是彼此取代。
兩者的定位差異在於，主資料管理系統必須要能讓前端的服務人員可以使用，而不只是藏在後端系統而已。
兩者也有共通之處──都要求資料是正確的。由於資料倉儲會執行資料清理（Data Cleaning）的工作，當資料進到資料倉儲時會經過修正，但這些異動不會自動回溯到應用系統當中的後端資料庫，因此錯的資訊還是錯的，而對主資料管理來說，這些錯誤的確是需要去更正的。
一般人或許會認為，資料倉儲只是客服中心的一種應用系統。我只能說，的確是可以在這樣的系統上去建立一個客服中心系統，大部分企業雖然已經建置了，但裡面的系統其實只服務客服中心本身的需求，而不是全部的人，所以觀念上不同。單靠客服中心手上的資訊來整併，成效還是有限，而且一不注意，可能會因此誤認所有的主資料，都需要以客服中心的資料為重。
用Data Hubs的做法來整合主資料
很多人也許會問，透過資料庫這類儲存庫來彼此同步裡面的內容，不是就可以解決主資料整合的需求嗎？
問題在於，這樣的關係裡，當某個系統的資料更動之後，另一個系統就面臨到是否需要同步處理的狀況。企業通常有N個系統，它們之間或許會相互將資料同步處理，但並非全部系統的資料都處於同步的狀態，通常只選幾個來實作，光是這樣的串連，機制就很複雜，因此會產生很多技術上的問題。
這其實和資料庫處理的觀念有關。也就是所謂的兩階段確認（Two phase commit）。如果修改資料，按下「完成」後，內容直接變更（Update），這叫做One phase commit；但兩階段確認是資料處理完成後，由於要連帶更新另一個系統的資料，所以並不立即宣告「完成」，而是確保兩邊的資料都變更了，交易才算完成。
如果沒有一套系統在中間串連，企業就要自行在不同系統之間，設法做到兩階段確認，這將會衍生一個問題：假設有12個系統要同步更新資料，資料變更時，要等12個系統都完成作業時，前端才會收到「完成」的資訊，也就是說，企業完全無法控制資料處理的效能。
對MDM來說，資料變更時，這些異動只發生在這個系統內，但MDM會將這些資料的最新版本，發布給相關其他的系統去同步。
如果是由主資料管理系統來協調這些動作，是有點像是中介軟體在扮演的角色。IBM軟體產品處軟體系統架構顧問巫介唐提到，就該公司的解決方案來說，實際上是靠EAI和Services元件的技術。
換句話說，MDM本身不直接去處理這些資料的異動，但是它會去擷取（Capture）那些資訊，把它們送給EAI，現在很多MDM廠商的產品都具備這樣的功能。通常這種技術叫做「發布與訂閱（Publish and Subscribe）」，幾乎是所有EAI廠商都具備的特色。
也許你會以為，MDM直接溝通每個系統後端的資料庫、儲存庫等資料儲存。其實不然，既有的應用系統仍直接依照原先的方式，去存取後面的資料庫系統。不過想做到這個目標，困難之處在於如何相容於既有的架構，逐漸發展成理想的架構。
巫介唐說，像這樣去改變資料處理與存取的路徑需要時間，固然須靠有經驗的廠商來引導，但目前臺灣還沒有企業以這樣的方式去發展，所以整體上，仍缺乏實際可參考的案例；而且過程可能得花上10年以上，絕對不是花點錢、1年內就能做得出來的。
妥善運用，能使企業免於違反法規
MDM應該是在企業內部裡面去建置、使用的，不過就像上述研究機構所分析的全球各地的應用狀態，有些企業以SaaS的方式來應用主資料管理。根據巫介唐的判斷，這種狀況可能是因為國外的企業可以合法買到顧客資料，例如Gartner將這種業務稱為Customer Data Integration（CDI），但這類解決方案較針對Party，即顧客資料，其他層面的主資料較少涵蓋到。
有種CDI的做法其實也和SaaS有關，Gartner稱為External Reference Style。在這種方式中，當企業要去查一個顧客的資訊時，可以從外部的系統取回資訊，更進一步了解顧客的基本資料，作為後續評估，例如是否結過婚、所需照顧的子女數。
這種服務的形成，是因為有很多顧客本身的基本資訊，在其他廠商的應用系統當中，都已經建檔，既然當地允許企業販售顧客資訊，所以這種SaaS是有可能存在的。
至於MDM跟法規遵循有關，也不難理解。因為透過這類型系統的操作，企業將能看到所謂的Portfolio──顧客所擁有或購買的產品，以及跟公司的關係。看到這些資訊後，企業能夠發起一些行銷活動，去延伸規畫更引起對方購買欲的產品組合，像是這個顧客是否適合其他產品的交叉銷售（Cross-sale）。這些資訊除了來自企業自身營運用應用系統內的主資料，也很可能是從資料倉儲端匯入，更進一步地還可能包括隱私資料或是偏好。
一旦企業直接運用這些資料，卻沒有注意到有人可能對接收這樣的行銷廣告行為感到反彈時，就很可能會因此觸法。因為企業發起行銷活動時，並沒有主動排除那些不想受打擾的顧客。
某些國家甚至有這樣的法令來約束公司行號的行銷手法。像美國國會曾經制定「勿來電」執行法 （Do-Not-Call Implementation Act），並且授權聯邦貿易委員會建置「勿來電」登記系統，成立一個National Do Not Call Registry的資料庫，任何一個人只要打電話去登記資訊、加入這個計畫，政府就保障這個顧客不會受到所有廠商的電話產品推銷，造成騷擾。
這將會造成一種狀況：通常這些情報往往只能全部蒐集進來，之後企業以此大量發送傳單，如果沒有這方面的過濾機制，例如在主資料管理系統裡面加註，就無法確定本身是否能遵守這樣的法令要求，作業上一定會有失誤。
DB2與關聯式資料庫的深厚淵源
http://www.ithome.com.tw/itadm/article.php?c=50930&s=5
關聯式資料庫管理系統這項技術發展已將近40年，它和IBM有很深厚的淵源，從理論、實作、產品化，到了1983年正式推出DB2第一版，這個時間點距今剛好滿25年。
從第二版開始參與該項產品研發的IBM矽谷實驗室查詢技術部DB2 z/OS資深研發經理傅毓勤表示，DB2不只是IBM的第一套關聯式資料庫產品，假如也將早期IBM奠定理論和推動實際應用的基礎等因素考慮進來，說它是業界第一套關聯式資料庫，當之無愧。
理論建構：關聯式模型
關聯式的資料模型理論是在1970年出現，由IBM研究院的E.F. Codd發表了業界第一篇關於關聯式資料庫技術的重要論文，題目為〈A Relational Model of Data for Large Shared Data Banks〉。
Codd認為，將來如果在共享的環境下，需要管理大量資料，關聯式模型（Relational Model）是最強大的一種構想。當時這僅止為一個研究方向，必須要發展、實現出一些基礎的技術，因此IBM繼續在這方面發展。
SQL語法與查詢最佳化的濫觴
首先要建構的是程式語言，這些關聯性需要特定的運算子（Operator）去表達、怎麼做聯結（Join），都需要靠一套語言來加以規範與定義。後來SEQUEL查詢語言的出現，再加上查詢最佳化的技術理論的推出，都是很關鍵的發展，讓這個模型可行性越來越高。
在1974年，IBM的Don Chamberlin和Ray Boyce共同提出一篇論文〈SEQUEL:A Structured English Query Evaluation Language〉，主要關於一套全新設計的程式語言，用在關聯式資料庫的資料存取和操作上。顧名思義，SEQUEL是一種口語化查詢語言，使用上就像一段英語敘述，而且語意是完備的、不會有矛盾。
這部分的成就也成為1986年後的ANSI/ISO SQL標準的基礎。這兩位等於SQL語言的鼻祖。這項技術，等於把關聯式模型落實成一套真正存在的語言，你可以用它來描述怎麼去查詢，在實用度和處理能力上是一個躍進。
SQL運用在程式開發上，和既有的程序式程式語言（Procedural Language）上有很大不同，傅毓勤認為，你所要描述的是What而不是How，例如你只要指定特定的資料表加以連結，而非把宣告變數、資料型別、運算子、表示式、迴圈相關的敘述等所有細節，一五一十地寫出來。當時，這也是被人質疑的。究竟這樣的語言能不能有效地實現出來，換句話說，還需寫出一個編譯器來剖析這樣的程式，執行最佳化。
於是，1979年，IBM的Patricia Selinger在美國電腦協會的SIGMOD 大會上發表一篇〈Access Path Selection in a Relational Database Management System〉，這是第一份有關於關聯式模型查詢最佳化的論文，也確立了今後SQL查詢最佳化（SQL Query Optimization in RDBMS）的發展方向。傅毓勤說，放眼望去，幾乎所有的優化工具，都是憑藉這個基礎發展出來的。
在資料庫發展上要做到最佳化查詢，通常會遇到NP Hard等級的問題，要找到最好的演算法一直很難，因為時間耗費通常與資料表數量的增加成指數成長，比如要處理30個資料表，可能就得用到天文數字般的處理量，但Patricia Selinger提出用工程來解決的方法，例如根據查詢的複雜度、回傳結果的資料量、也就是預估各種存取資料方法的成本，用布林表示式來決定對應的存取計畫。
SQL/DS和DB2 for z/OS
這兩項理論讓關聯式資料模型就不再是那麼抽象的名詞，實現的可能性大增。接下來還有三件事在歷史上很重要，就是如何產品化，使DB2成為一套能夠真正用在業界的產品。
1982年，IBM基於System R和SQL推出全世界最早的商業化關聯式資料庫SQL/DS，用在VSE和VM這兩個大型主機的作業系統上，它也是第一個針對查詢處理程序（Query Processing）的系統；隔年他們又將SQL/DS一部份作為新的資料庫產品Database 2的基礎，DATABASE 2即為我們目前慣稱的DB2。也就是說，SQL/DS是DB2的前身，所以DB2也算是從System R衍生出來。
為什麼叫做Database 2？原因是IMS是IBM發展出的第一套階層式資料庫管理系統，而相對於階層式模型，他們認為這套新的系統是第二代的資料庫系統。
DB2的第一個版本，當時主要用在決策支援方面的少量查詢，還無法真正運用在交易上，例如銀行的核心業務。到了1988年第二個版本發行時，又有了一個革命性的改變，Don Haderle、Jim Teng（鄧之嘉）、Howard Herron帶領開發團隊，將交易率大幅提升，讓DB2成為可以真正用在交易的資料庫系統。
加入並行處理演算法和資料分享的架構
一套資料庫管理系統除了能簡化資料存取、負擔線上交易，在可用性、延展性和可靠度也需要提出保障。
可用性的強化上，主要是Aries的並行處理演算法，它是由C. Mohan和Don Haderle在1980年代中、晚期所發展的。這個計畫主要是針對並行處理的控制（Concurrency Control）上，把鎖定（Lock）的技術從資料頁（Page）降到資料列（row）的等級，因為粒度變小了，所以並行處理的效率大大提升，這也讓系統復原比較有效率。
在可用性和延展性，還有一項關鍵技術，傅毓勤特別強調是DB2至今仍獨有的，那就是資料共享（Data Sharing）。在1988到1994年當中，IBM極力想讓這個平臺的處理能力能夠獲得突破性的改變，他們提出了Sysplex的架構和資料共享的技術，這是由Inderpal Narang、C. Mohan, Don Haderle、Jim Teng和Jeff Josten帶領的團隊所發展出來的。在DB2 for MVS V4，IBM也開始運用這樣的技術。
這個架構是指，你可以同時有多個執行DB2系統的成員，它們能在不同的主機上執行，然後合起來成為一個叢集，共享同一個資料庫；它們可以各自執行自己的應用程式，也可以合起來執行同一個應用程式。
傅毓勤表示，以可用性來說，合起來之後，它們之間是共享的，假設成員當中有一個停機、無法運作，其他成員會自動繼續維持運作，系統不需要額外執行其他容錯的機制，除非全部成員停止運作。
Sysplex還能用於延展性和工作負載平衡，例如動態加入新成員來分攤處理。這些成員共享了資料庫，它們可以執行在相同或不同的邏輯分割區（LPAR）；如果分散在不同硬體上，它們彼此還可以相互支援處理，將工作負載分配至同時段比較閒置的主機上。文⊙李宗翰
SQL Injection新威脅大剖析
http://www.ithome.com.tw/itadm/article.php?c=50860&s=1
現在只要花400元，不論是否懂駭客攻防原理、原則，幾乎人人可變成SQL Injection駭客，而面對這些不斷翻新手法的SQL Injection攻擊，企業必須掌握駭客經濟學的特性，才能找到有效的縱深防禦策略。
從駭客經濟學看SQL Injection攻防
SQL Injection是一個有10年歷史的老問題了，而駭客的攻擊手法隨著時間的演進也不斷的推陳出新，企業必須要站在駭客的角度思考，從駭客經濟學的角度來思考戰略，才能持續打贏這場沒有終點的網路攻防戰。
4大SQL Injection防護絕招
絕招1 借力使力，從攻擊手法學防守
資安專家一致認為SQL Injection攻擊手法其實是老問題，但企業網站遭受SQL Injection攻擊的事件卻層出不窮，若要有效建立防護機制，企業必須借力使力，善用各種可用資源，甚至懂得利用駭客的攻擊資訊，來建構網站的防禦系統，讓防護人力發揮最大的效果。
絕招2 中途攔截，及時打斷攻擊路線
從SQL Injection攻擊地圖來看，不論是MS SQL/ASP或是MySQL/PHP，從前端網頁入侵到後端資料庫的過程，是一連串的攻擊組合，必須一氣呵成，才能達到入侵的效果。因此只要監控SQL Injection攻擊路線，及時打斷駭客入侵的連續程序，就能達到防禦效果。
絕招3 縱深防禦，用隔離與監控來鞏固
資料庫是SQL Injection攻擊的主要目標，理論上，採取徹底的隔離策略，就能有效降低潛在的入侵風險。若能清查資料庫帳號權限，只允許有經驗的資料庫人員接觸，就能有效預防潛在風險。
絕招4 先擋再修，以應用防火牆搶時間
企業網站發生SQL Injection問題後，不論是添加檢查使用者輸入資料的程式碼，或者是調整資料庫權限架構等，都需耗費數周時間才能達到一定的防護效果。而應用程式防火牆雖然要價百萬，卻可快速建立網站基本防護，爭取修補程式的緩衝時間，也是一個不錯的防護方法。
更新日期:2009/07/23 04:09 記者林相美／台北報導
騎自行車減重當心越騎越胖。一家健檢中心昨天發表問卷調查結果，6成7的車友在騎車後，會選擇當地餐廳或小吃進食；營養師分析，騎一趟淡水至三芝，沿線小吃熱量超過3000大卡，而騎車消耗的熱量約1500大卡，反而吃進更多熱量。
問卷調查總計203個有效樣本，健檢中心院長楊培鎮表示，此項問卷可複選，其中選項最多者如下：近8成受訪者的騎車目的是「為了健康或減重」；8成1「一週騎一次以上」；5成7「一週會約朋友騎一次以上」；39%「每次約騎3小時」；38%「每次約騎40公里」，以80公斤體重計算，騎40公里，約消耗1200大卡。
楊培鎮說，每次騎車消耗1200卡，看似健康，但騎車後，6成7的車友會就近選擇當地餐廳或小吃；24%選擇便利商店進食；其中7成選擇標準是「好吃」，僅有16%考慮低熱量。
楊培鎮表示，57%車友吃冰、20%選吃海產店或土雞城、22%吃便當、18%喝啤酒。健檢中心營養師洪誼芬解釋，冰品的糖漿、加料熱量高，吃海產店、土雞城一桌菜，平均每人吃下1200卡的熱量。
以北部熱門路線淡水至三芝為例，來回52公里，沿途美食阿給、魚丸湯、鐵蛋、魚酥、冰淇淋、蛋糕搭配紅茶，總熱量高達3710大卡。
車友胡肇威說，4年前開始騎車，身高185公分的他體重115公斤，每次都是邊騎邊吃，騎完再吃，騎一年多，反而胖了12公斤；為了不讓「小摺」負擔太重，他決定減重。騎車後，避吃小吃或和別人共享，經過8週運動及飲食控制，體重由121.6公斤降至94.8公斤，減了近27公斤。
洪誼芬建議，車友運動後進食，應遵守低油、低糖、高纖、高蛋白原則，運動會導致肌肉組織斷裂，可補充豆腐、豆乾等黃豆製品、鮮奶、一顆蛋或一份手掌心大小的肉，補充蛋白質，修復肌肉，增加身體肌肉比例，提高基礎代謝率，讓減重效果更好。
資料來源：
http://tw.news.yahoo.com/article/url/d/a/090723/78/1nkwy.html
令人深思的一段文字，說明 Michael Jackson 所承受的壓力。
我已經厭倦了被人操縱的感覺。這種壓迫是真實存在的！他們是撒謊者，歷史書也是謊言滿佈。你必須知道，所有的流行音樂，從爵士到搖滾到hip-hop，然後到舞曲，都是黑人創造的！但這都被逼到了史書的角落裡去！你從來沒見過一個黑人出現在它的封面上，你只會看到貓王，看到滾石樂隊，可誰才是真正的先驅呢？
自從我打破唱片紀錄開始——我打破了貓王的紀錄，我打破了披頭四的紀錄——然後呢？他們叫我畸形人，同性戀者，性騷擾小孩的怪胎！他們說我漂白了自己的皮膚，做一切可做的來詆毀我，這些都是陰謀！當我站在鏡前時看著自己，我知道，我是個黑人！
——麥可‧傑克森
時至今日，仍有部分「白人」自命不凡。可悲、可嘆…那些盲目崇洋的女人。
資料來源：
紀念永遠的流行樂之王 ! Michael Jackson
http://www.wretch.cc/blog/wto404/12603654
最近朋友去聽恆X的 Oracle 說明會。這家收費不但貴，而且還很臭屁的講考過可以百萬。
這種鬼話，還有人在講。我已經考過一年多，連加薪都沒有。
拜託一下，景氣這麼差，誰用 Oracle 這種貴東西。
用 Oracle 比較快，哈哈...?????那你要去問那個單位花都少＄＄＄在硬體上，
硬體已經花數千萬了，那跑在上面軟體本來就該快呀。
在 Top Ten TPC-C by Performance(http://www.tpc.org/tpcc/results/tpcc_perf_results.asp)最快的是 DB2啦。
會用 Oracle 的單位被是 Oracle 制約了。
SUN 的 solaris 還是會當呀，數千萬的機器，在台灣的境X局一次可以兩組都壞掉。
作業系統用 Linux 才是王道。省錢好用，不用被硬體維護商給制約。資料庫用 PostgreSQL、MySQL 才對。
感覺上那些被制約資訊人員，才會說這個案子一定要用 Oracle，一定要用 solaris。
