只聽了下午場,連續三個半天,今年我參加的應該算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


84 - 72 =