1

只聽了下午場，連續三個半天，今年我參加的應該算TechHalfDays 2015（誤） XD

Xamarin

  • 講師分享了Maker（創客）經驗
    Maker = 連結「想」與「做」的過程，有助找到答案並解決問題，更可能誘發新的創意與發明，是當前開創性動力的來源
  • HackNTU的專案：手貼玻璃識別開門，Intel開發板＋Arduino-->電磁開關開啟3D列印出來的門
  • C# on Arduino的選項
  • 實機展示：netduino 3 wifi 板子控制LCD模組顯示文字（LCD模組Driver自己寫），SignalR網路聊天室，netduino接收聊天內容顯示在LCD。
  • Xamarin要解決跨裝置開發App的困擾
    開發環境多樣：Swift/Xcode、Java/Eclipse、C#/Visual Studio
    Xamarin用C#寫程式，轉譯成三個行動平台的原生程式
    iOS上用AOT方式編譯、Android用JIT編譯
  • 優點共用邏輯抽取成為共用程式庫，不同平台App只差在UI，70%-85%程式碼可共用
  • Xamarin.Form<=相同的UI模型，95%的程式碼共用
  • 插曲：線上聊天室好像有人開始試玩XSS XD
  • 自動測試功能，測試雲（Test Cloud）：上傳UI測試，自動以不同裝置測試，回報結果。

SQL經典效能問題案例實戰

  • 來自微軟CSS部門SQL茶包射手的心得分享，完全是我的菜
  • 介紹效能瓶頸緊急處理步驟，有什麼工具可用？分享四個案例
  • 案例1 CPU使用率飆高
    SQL 2000->SQL 2008R2，VB6程式，上線前測試正常，效能OK。正式上線後，CPU居高不下。
    • VB6程式使用Ad-Hoc語法，編譯SQL指令頻率過高，CPU 100％
    • 好用工具：SSMS的Activity Monitor，活動監視器
    • 觀察到CPU％高、等候項目多、批次執行時間長
    • 等待類型：ASYNC＿NETWORK＿IO （等待網路傳輸）、CXPACKET（出現時代表SQL大量平行處理）
    • 資源等候（Resource Waits）：等侯類型Network IO/Logging/Compilation （前幾年講Blocking的簡報裡有詳細介紹，搜尋未獲）
    • 聚焦最近且費時的查詢，觀注每分鐘執行的次數，找到語法顯示執行計劃，遺漏索引的詳細資料
    • 除了用活動監視器，也可跑SQL查詢系統檢視、資料表找出可疑的活動
    • SQL Server Property/進階/平行處理原則的成本臨界值，預設5，平行處理則的最大程度: 0不限CPU、1每個批次最多用1顆（延伸閱讀：認識平行(parallelism)處理，以MAXDOP、cost threshold for parallelism與max degree of parallelism選項為例）
    • 舊版升級的SQL，有個「參數化」屬性：簡單->強制，相近的查詢共用編譯計劃，減少編譯時間
    • optimize for ad hoc workloads->如果Ad-Hoc的比重極高，可考慮，但是雙面刃，不適用.NET AP/SP（延伸閱讀：[SQL SERVER][Performance]別忘記開啟optimize for ad hoc workloads）
    • CPU偏高觀察重點：
      • 連線數是否大量增加（不要漏掉壓力測試）
        分散使用量（調整商業邏輯）、升級硬體
      • 是否同時執行大型批次作業
      • 舊程式，使用太多AdHoc查詢
      • 執行計劃不佳？定期更新統計資訊、大量異動後即刻更新
      • 特別慢的作業：缺索引？分多批執行，離峰再做
  • 案例2 股市公司重要核心SP，執行時間從5ms升到3分鐘，軟硬體沒動，有更新統計資料
    常發生於營業時間開始，重啟SQL後問題消失（執行計劃跑掉）
    • 模擬：很大的資料表，WHERE prodId = ＠prodId，
      第一次查詢用Index Seek
      更新筆數過20％引發自動更新統計（Profiler可錄到AutoStat事件），SP會重新編譯執行計劃
      第二次查詢變Index Scan
    • Parameter Sniffing議題 （這個前陣子剛好探討過）
    • 解決之道：將執行計劃固定下來（Plan Guides）
    • Parameter Sniffing處理要點
      • 找出TOP 5語法，將執行次數多、耗用資源多者挑出來調校，改善查詢計劃（例如：Index Scan)
      • 使用Partition Table
      • 一些Plan Guide
        Trace Flag 4136, OPTIMIZE FOR UNKNOWN
        OPTION (HASH JOIN)強迫使用雜湊聯結
        OPTIMIZE FOR UNKNOWN
        OPTIMIZE FOR (@CITY='Taipei')
        @hints = N'OPTION (QUERYTRACEON 4199, QUERYTRACEON 4136)'
  • 案例3 少數程式開發人員有sysadmin權限，部分開發人員有View System State權限
    某幾個系統更新後，系統效能愈來愈慢，但看不出任何硬體瓶頸
    • 根源：開發人員開了SQL Profiler玩吃到飽，所有SQL動作全都錄
    • 活動監視器的資源等候（Resource Waits）可以看到Trace Wait
    • 解決辦法：
      使用Server-Side Trace取代Profiler，Profiler UI先設定好條件，再匯出成Server-Side Trace。
      Server-Side Trace造成的負荷比Profiler UI小很多。
      記得要限DB ID、AppName，只特定追蹤特定的AP活動，減少負擔，結果較易判讀
    • 可排Job定期清理Server-Side Trace
  • 案例4 程式跑幾天後愈來愈慢，幾秒變十幾秒，特定單號出現Timeout，愈來愈多單號Timeout，重啟後問題消失
    • 嫌犯：Memory或Blocking
    • 模擬：DBCC TRACEON 1244 ＜＝不要自動升級鎖定範圍，故意產生更多鎖定。開啟Transaction執行更新指令後，不Commit也不Rollback，留下一堆Lock
    • 用活動監視器封鎖者、源頭封鎖者
    • KILL封鎖者 Process前要注意：
      > 若它已耗用大量資源，Rollback也需耗用大量資源（可達1.5倍）。用總IO排名報表查詢
      > 刪除Process會不會影響前端作業？
    • 案例：Running->Rollback，等了一個小時，使用重覆Kill導致Deadlock，最後只能重啟SQL
    • 常見嫌犯：Idle時間長，Sleeping/Awaiting Command、IO高（Reads/Writes）時間又長，容易造成Blocking
    • 重建索引會產生Lock，大型資料表可能得以小時計，注意會不會影響其他程式
    • Transaction記得加Error Handling，一出錯馬上Rollback

跨國重大SQL管理實務

  • 趨勢科技實例分享，一位國際DBA的日常（只聽了五分鐘就發現自己在越級打怪，只能看熱閙長見識）
  • High Available的多種選擇：Always On、DB Mirror、Replication、Log Shipping
  • Log Shipping沒什麼人用，其實很強大，機器斷線很久也能繼續接關
  • 很華麗的Demo，資料庫横跨美國、日本、台灣
  • Always On也可以做Two Way Replication，祕技：Distributor拉出來
  • 防止有人將Recovery Mode由Full->Simple，DDL Trigger是一種做法，另一種方法是建Mirror在DB加上鎖定
  • 實務上DBA作業時很少用UI，不用精靈，幾乎全靠指令完成
  • Repication沒什麼除錯工具，全靠指令logread.exe，去Publisher抓資料，操作Distributor讀Tracton Log
  • Distributor Agent Profile千萬不要用預設值
    ＊Skip Error: 略過目的資料被改掉Replication失敗，避免中斷。某組設定自2010至今Replication沒壞掉過，不曾Initial（一次要十幾個小時），但要小聲說，不要被SQL聽到，否則… XD
  • Replication重做前要清設定，不然會建不起來，像是備份資料還原後冒出發行集，UI砍不掉（Pubisher缺Distributor之類的狀況）sp_removedbreplication @dbname = '...', @type = 'both'
  • Log Shipping很古老很好用
    Commit或未Commit都送，Mirror/Always On只送Commit的結果，需要AD認證處理Log檔案複製，類似MSDTC，機器間要相互認得
  • Log Shipping/Replication目的資料庫名稱可以不同，DB Mirroring/Always On不行，可以1對8
  • 當心Job用的是當地時區
  • 一個Log Shipping升級到Replication的複雜示範（超出我能力範圍，看不懂）

Comments

# by James Tsai

小弟的課程居然被黑暗大的筆記下來了...淚奔~~

Post a comment