同事在新客戶端佈署測試網站,部分電腦連線時發現網站外觀與預期不同(破版),肉眼可見的功能表消失、位置跑掉等問題油然而生,但透過網站本機或是其它伺服器端開啟網站卻很正常。客戶IT人員很有經驗的說明是瀏覽器與網站間的相容性模式所造成,由於客戶端還有許多舊版IE才能瀏覽的網站,因此ie瀏覽器預設的相容性模式是開啟的。
除了在Client端將網站新增到相容性檢視清單 或 取消[在相容性檢視下顯示內部網路網站]的勾選(因為user多),來試試從IIS網站(伺服器端)來解決問題。
同事在新客戶端佈署測試網站,部分電腦連線時發現網站外觀與預期不同(破版),肉眼可見的功能表消失、位置跑掉等問題油然而生,但透過網站本機或是其它伺服器端開啟網站卻很正常。客戶IT人員很有經驗的說明是瀏覽器與網站間的相容性模式所造成,由於客戶端還有許多舊版IE才能瀏覽的網站,因此ie瀏覽器預設的相容性模式是開啟的。
除了在Client端將網站新增到相容性檢視清單 或 取消[在相容性檢視下顯示內部網路網站]的勾選(因為user多),來試試從IIS網站(伺服器端)來解決問題。
昨天留在駐點辦公室驗證需求,客戶端的程式開發人員來討論一個主管交辦的任務,產表時,要多幾個下拉欄位給user選,而且希望透過程式動態帶出下拉選單的值,趁女兒睡著,來試試用NPOI實現從後端作Excel資料驗證。
星期日晚上來寫blog,上一篇先解決了列印時的表頭資訊,這一篇來解決同事其他的需求:依照資料筆數分頁列印、小計等。順邊筆記2的十次方分頁問題。
同事剛加入急急如律令的專案幫忙開發報表,使用者有一項需求是列印報表時,表頭要出現頁數、標題、欄位名稱等,專案中使用的是NPOI,之前自己參加專案時都是同事寫好了元件,對NPOI操作不太熟悉,這次捲起袖子來試試。
最近在駐點的客戶端遇到一個很神奇的問題,剛匯入大筆資料的隔天(50%以上的異動量),同事有一支程式跑了很久都沒執行完,想辦法和AP人員清理舊資料、加索引,更新統計值後,程式瞬間秒殺,但過沒多久,同事另一支類似功能的程式又塞住,這次即使更新統計值、清除plan cache 、Recompile SQL都沒效。
在SQL2016以前,當自動更新統計值選項啟用後,20% + 500筆是一般資料表觸發重新統計的門檻(RT),資料異動累積量達標後,第一個使用統計值的交易會先更新統計值才完成編譯後再實際執行,在某些資料表比較胖的時候,也許先更新統計值再查詢資料的順序可能就會影響OLTP個案交易的執行效能,此時可以試試非同步更新統計值。
上一篇我們注意到統計值(Statistics)不夠即時可能造成SQL Optimizer無法產生最佳的執行計畫,另外也發現自動更新統計值並不是發生在資料更新的同時,而是發生在更新後第一次使用統計值的SQL指令作編譯前,那麼多少的異動量條件會觸發統計值更新?
去年底上線前的一次系統轉換演練,碰到某支轉檔SQL執行變慢,表象是執行計畫改變(plan change),進一步找原因則發現是不太即時的統計值造成Query Optimizer產生較差的執行計畫。
去年底的跨年,終於把駐點14個月的專案上線了,這個客戶和幾年前上線的客戶最近都遇上統計值影響效能,來記錄問題,順便重修統計值(Statistics)。
統計值是描述欄位值與索引欄位值的分佈統計,也是SQL Query Optimizer進行基數估計(cardinality estimate)的分析來源,透過基數預估,進而決策出優秀的執行計畫來擷取或更新資料。
統計值統治的範圍包含一般資料表、#臨時資料表以及幾個新的企業版本@資料表變數都有統計值。
資料庫因為胖胖的讓公司測試環境很擠,但想透過上個月月初備份檔(.bak)還原幾個資料表來比較測試結果,測試環境的空間及資源都不足,當初也沒把幾個資料表放在指定檔案群組(File Group),這次不能使用還原檔案群組招式。
來筆記付費的Third party工具,透過ApexSQL Recover工具,不需要還原整個資料庫就能還原單一資料表。
在SQL 2016以前,Insert Into Select一直都只能用一條執行緒執行資料表插入,SQL Server先在2014版本時優化了Select Into新增了平行,到了SQL 2016版本也優化了Insert Into Select,只要資料庫相容性層級設置為130(SQL 2016),搭配WITH (TABLOCK)的Table Hint,我們也可以在非叢集索引資料表平行執行Insert Into Select了。來筆記實驗過程。
在SQL Server 2014以前,Select Into一直都只能用一條執行緒執行資料表插入,即使Into到tempdb也是;不過到了SQL 2014之後,只要資料庫相容性層級設置為120(SQL 2014)就可以在成本大的語法平行執行Select Into了。來筆記實驗過程。
維護SQL2000的系統要作資料移轉時,除了寫AP程式或是用ETL工具轉換資料,其實也能繼續用舊機卸離 x 新機附加直接移轉user databse的資料庫檔案。
上一篇實驗了移轉SQL2005的檔案到SQL2017,實驗結果可以直升;這次實驗SQL2000的user database,事前從ms blog的討論發現需要先轉到SQL2005或SQL2008,再跳到SQL2017。
這次不用升級SQL Instance版本(就地升級),但要移轉幾個User Database到新機器上新版本的SQL Instance。在學校曾上過SQL 2000的課,幾年前重新接觸SQL Server,已經是SQL 2008R2 ,幾年下來慢慢也從SQL 2008移轉到2012/2014/2016,好在SQL資料庫的相容性,每次都很順利,不過這次是自己沒使用過的SQL 2005,試試SQL2005到SQL2017,一個12生肖的距離。
同事報案在Server2012R2環境測試Windows Form程式指定在背景下(session 0)執行時看不到UI,已經確認互動偵測服務(Interactive Services Detection)啟動,Windows排程啟動程式後,在工作管理員(Task manager)也在Background process看到程式閃耀著,但切到背景下(session 0)查看UI時卻看不到?
以前只有寫判斷銀行營業、關帳日、計息起息結息日的,趁中午吃點心來補同事們需要的函數(判斷月初、月底、季初、季底、年初、年底)。
很開心在上周末下班前一起和客戶端的.NET架構師解決了開發人員的NHibernate交易使用問題,好久沒用Hibernate這個老牌ORM武器了,連開保險上膛都很生疏,來筆記Hibernate問題解決,順便回憶。
客戶端開發人員的問題是在同一個Transaction中,有三個資料庫的操作,但後面的操作無法讀取到同一個Transaction先前寫入的資料。
經過上一篇的實驗,磁碟資料表(Disk-based table)啟用讀取認可快照(RCSI)或是快照隔離(Snapshot isolation)都能到使用資料列版本讀取到前一版的資料而避免封鎖(blocked),特別兩者在處理”資料一致性的層級”以及”交易發生衝突的處理上”有些不同;那麼到了記憶體資料表(Memory-optimized table)?
SQL Server在磁碟資料表(Disk-Base)提供了兩種與快照有關的樂觀鎖定機制: RCSI(Read Committed Snapshot Isolation)及Snapshot Isolation,他們都是減少查詢交易被封鎖的武器之一,當資料被其他交易更新時,這兩種機制都可以透過Tempdb加上row version查詢到資料的前一版,讓交易免於被封鎖(blocked)的命運。明晚要參加SQL Pass,Rico大的主題是進擊的In-Memory OLTP,學習記憶體資料表交易前,先來預習傳統磁碟資料表在這兩種機制下的查詢一致性。
想移除歷史交易資料時,很直覺想到串DML Delete;但如果刪除交易量大,怕影響線上交易時,辛苦的攻城師需要改成預存程序分批刪除,每次刪2,000筆還放慢半秒,但鎖定物件較多,批次時間也久;如果資料表能獲得DBA大人同意設置成Partition Table,用上Switch Partition可以飛快的轉出資料;不過Switch Partition手續有些繁瑣,得先建立相同分割檔案群組、相同結構的空資料表再轉移。
SQL Server 2016更方便了,TRUNCATE TABLE支援指定分割編號,秒殺的概念,來試試。