Danny's 單車,工作與生活

一般而言SQL 的Performance Tuning 可使用SQL Profiler , 但是如果要調教的機器上SQL Server上並未安裝SQL Profiler 或使用者不會使用SQL Profiler時, 則可用指令的方式執行. 本案例的狀況是: 對方的機器是SQL Server 2008 且未安裝SQL Profiler. 筆者手上的機器只有SQL Server 2005 , 但有安裝SQL Profiler . 1.建立SQL Profiler 的指令檔. 1.1 開啟SQL Server 2005 , 進入SQL Profiler.   1.2. 選擇追蹤的事件    可設定常用的事件, 包括 RFC:Completed, SP:StmtCompleted,SQL:BatchCompleted 1.3.設定資料行篩選,     可設定篩選條件例如針對Reads 的次數大於1000以上才記錄. 1.4. 設定完成後, 點選執行後, 在將其停止, 並匯出指令檔. 1.5. 產生的SQL 如下: (若上述的追蹤項目可用, 可直接使用以下的SQL 追蹤） -- Create a Queue declare @rc int declare @TraceID int declare @maxfilesize bigint set @maxfilesize = 5 -- Please replace the text InsertFileNameHere, with an appropriate -- filename prefixed by a path, e.g., c:\MyFolder\MyTrace. The .trc extension -- will be appended to the filename automatically. If you are writing from -- remote server to local drive, please use UNC path and make sure server has -- write acce...

  下載位址: http://www.dbcomparer.com/ 版權: Free 適用資料庫版本: Microsoft SQL Server 2008 (and 2005) 功能說明: DBCompare 可以比對SQL Server 2008 與 2005 的資料庫的Schema,其比較的項目包括整個Schema 所有項目.   1. 安裝DBcomparer 2. 輸入兩個資料庫的位置與認證資訊 3.設定比對項目 點選Compare Options 可以選擇比對的項目. 3.開始比對 點選Compare Now 開始執行比對. 4.比對結果   上方視窗顯示兩個Schema 的差異 5.差異說明 黑色字表是兩者相同 紅色與欄色字皆表示可能有差異 差異可能是欄位也可能是索引, 因此可以展開有差異的檔案逐一檢視.

BPM、SOA、Workflow、電子表單 打開Google 輸入BPM、SOA、Workflow、電子表單任何一個單字，至少可你看到數十種以上得產品,包括ultimus、K2、AgilePoint、華苓(AgentFlow)、超義(Power Process)、新人類(FlowMaster)甚至Oracle、IBM、Mircosoft…等等都有相對應的產品,早期最常被客戶問到的是BPM與Workflow 有什麼不同?要導入SOA或BPM呢?現在大家已經不在意這個問題了, 因為現在所有的產品都說是自己是BPM或SOA. 每個產品都號稱自己功能強大, 只要簡單的拖拖拉拉工作就完成了,真的是這樣嗎?如果導入了一個錯誤的產品, 簡單的需求當然沒有問題, 但是面對複雜的問題時, 因為東西已經買了, 要退貨或解約, IT 主管不只要面對廠商, 也要面對內部老板的壓力, 在這種情形下只好改變公司的流程去迎合產品. 有句話說不管黑貓白貓能抓的到老鼠的就是好貓,同樣的不管叫SOA或BPM只要能符合企業需求的就是好流程. 為了避免導入不適合的產品, 在導入前應該更審慎的評估, 先了解本身的需求, 再評估那一個產品適合自己的企業, 可是面對市場上琳瑯滿目的產品或平台該如何選擇呢? 企業應該導入一個BPM產品(電子表單系統)或SOA的架構? 在評估適合產品時,我們可以先看一下兩個最常見的產品類別,不論是Workflow或電子表單我們統一叫作BPM, 另一類是屬於較完整的架構的我們稱為SOA.  導入SOA 在一個SOA的平台中不論外掛或整合都會含有BPM的模組, 目前市場上所看的到的SOA平台都是屬於資訊界的大廠所推出的產品. SOA平台(含BPM 模組)其特點是平台架構完整, 因此具有未來擴充性, 同時SOA的平台通常可以用程式語言開發流程所需要用到表單與各種整合的元件,可是導入一個SOA的平台不是只由技術層面來考量, 還要由公司整體IT發展的策略來看, 因此架構完整的另一個義意, 代表了覆雜, 因此很難短時間內看到成效. 通常SOA的平台較擅長的是在自動化流程或系統整合部份, 面對華人地區覆雜的簽核流程時組織簽核的功能通常較弱, 我常開完笑講在歐美是符合規則就不用簽, 在台灣是符合規則就要簽, 而且這個規則的彈性很高, 其實台灣的企業都...

  循序簽核 企業流程中, 大部份的行政流程都採用申請者逐級簽核的方式進行, 由申請者開始依組織的層級逐級向上簽核,當導入BPM或Workflow時也會面臨同樣的問題, 一般常見的作法是逐一繪出組織層級與流程. 上述的流程雖然很清楚的呈現簽核者的層級與流程, 可是問題也不少,因為一般流程的訪談都是以最基層的員工為主, 因此很容易發生以自己為出發點去設計流程,試問 1.如果經理自己申請是否要自己核准, 如果協理申請是否要給經理簽 ? 2. 如果有一個部門沒有協理怎麼辦 ?一個流程如果要適用於生產部門的工廠與行政支援部門, 通常其組織結構是不同的, 傳統的作法是把每個組織了流程劃出來, 整個流程密密麻麻. 逐級簽核 新的流程設計通常改用逐級簽核的方式, 以類似迴圈的方式判斷是否達到核決的權限, 如未達到則在找上一階主管, 已達到則離開迴圈, 不論申請者是何層級或組織階層為何皆可執行.   AgilePoint 提供很有彈性的逐級簽核的判斷,可在單一條件的流程元件(Single Condition) 是否達核決權限中判斷指定的流程變數(圖中IsPrivileged)為True或False, 因此只要在流程中依組織的核決規則去設定流程變數值即可. 判斷是否達核決權限的判斷有許多種方法, 第一種是在人工簽核作業元件中設定判斷的基准,該元件會依設定的內容指定流程變數的值. 內件元件可以依人員或部門甚至流程變數的值作判斷, 判斷的方法有特定的值(等於某個層級), 特定欄位值是否符核該層級的區間(經理可准假幾天, 協理可以核准採購金額多少),上簽幾階等不同的方式. 如果內建的內容無法滿足時,亦可在表單上運算然後將結果(True/False)直接設定給流程變數, 不過我們通常不建議將判斷寫於表單上, 比較建議的方法是寫成一個流程元件(AgilePart), 其優點除了簡化表單的設計外, 另一個好處是可以重覆利用這個元件, 達到組合流程的目的. 資產處分流程中, 依資產使用年限與殘值決定核決層級, 以AgilePart 製作核決權限判斷元件. 設計一個可參數化的流程元件直接設定所需的核決層級. 透過上述幾個案例, 可以發現逐級簽核有兩個重點, 一個是需要一個樹狀...