TechDays 2015筆記-D3
1 |
只聽了下午場,連續三個半天,今年我參加的應該算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的複雜示範(超出我能力範圍,看不懂)
Comments
# by James Tsai
小弟的課程居然被黑暗大的筆記下來了...淚奔~~