只聽了下午場，連續三個半天，今年我參加的應該算TechHalfDays 2015（誤） XD
Xamarin
- 講師分享了Maker（創客）經驗
Maker = 連結「想」與「做」的過程，有助找到答案並解決問題，更可能誘發新的創意與發明，是當前開創性動力的來源 - HackNTU的專案：手貼玻璃識別開門，Intel開發板＋Arduino-->電磁開關開啟3D列印出來的門
- C# on Arduino的選項
- NETMF (.NET Micro Framework)
- Win10 IoT Core
- 實機展示：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的複雜示範（超出我能力範圍，看不懂）