SQL Server Transaction Log 還原

將  bak 檔與 trn 檔複製到另一台 SQL Server 測試還原的步驟

選擇 bak 與 trn 檔案，剩下就跟一般還原一樣選擇處理

WCF 回傳為錯誤

在本機測試都沒問題，放上正式環境後就掛掉，最後只好把 Web.Config 開啟紀錄來看看

在 system.web 加入了紀錄 Trace 的功能

<system.diagnostics>

    <sources>

      <source name="System.ServiceModel.MessageLogging" switchValue="Warning, ActivityTracing">

        <listeners>

          <add name="ServiceModelTraceListener" />

        </listeners>

      </source>

      <source name="System.ServiceModel" switchValue="Verbose,ActivityTracing">

        <listeners>

          <add name="ServiceModelTraceListener" />

        </listeners>

      </source>

      <source name="System.Runtime.Serialization" switchValue="Verbose,ActivityTracing">

        <listeners>

          <add name="ServiceModelTraceListener" />

        </listeners>

      </source>

    </sources>

    <sharedListeners>

      <add initializeData="App_tracelog.svclog" type="System.Diagnostics.XmlWriterTraceListener, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" name="ServiceModelTraceListener" traceOutputOptions="Timestamp" />

    </sharedListeners>

  </system.diagnostics>

在同一資料夾就會有 App_tracelog.svclog 這個檔案產生，成長速度飛快，我才紀錄 2 天就大到  2G 了，還好已經紀錄到我要看的，趕緊將記錄功能從 Web.Config 中移除。

使用 Microsoft Service Trace Viewer 就可以開啟，沒有也有可以記事本，只是很難閱讀。

最後才發現，原來這次我的調整用了新的 DataTable 但是沒給 TableName 造成的。

呼~~~虛驚一場。

App_tracelog.svclog 太大

上次清 WCF Log 應該是一年前了吧，全部加起來有兩千多個檔案，佔去快 100G 空間，

其中主要那個還佔了 85.3G。

我會先到 Web.Config 中把 App_tracelog.svclog 紀錄先改掉，刪除檔案，再改回 App_tracelog.svclog

      <add initializeData="App_tracelog.svclog" type="System.Diagnostics.XmlWriterTraceListener, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" name="ServiceModelTraceListener" traceOutputOptions="Timestamp" />

 

Could not load file or assembly 'ADODB, Version=7.0.3300.0, Culture=neutral

最怕就是系統移機了，畢竟隨便一個系統都是已經建置部屬超過三五年，中間經過很多人，到底在系統上安裝了什麼，也不見得會有人記得。

這次要將 Web Service 從 Windows Server 2008 R2 移機到 Windows Server 2012 R2 的機器就遇到了

開網頁直接跳

Could not load file or assembly 'ADODB, Version=7.0.3300.0, Culture=neutral 布拉布拉的錯誤

安裝了一大堆版本的 MDAC 還是一樣，錯誤。

最後只好找來 adodb.dll 加上 gacutil.exe 強制註冊到 GAC 中才行

用系統管理員權限開啟命令提示字元

.\gacutil.exe -i .\adodb.dll

打完收工

Synology DS216+II 升級記憶體跟擴大硬碟

利用今年雙 11 買了兩顆 Toshiba【企業碟】(MG06ACA800E) 8TB /7200轉/256MB/3.5吋/5Y 來把原本的 Seagate【IronWolf】那嘶狼 4TB 3.5吋NAS硬碟 (ST4000VN008) 過保固的替換掉，

順便試試看 DS216+II  Repair 需要花多少時間，關機後換上硬碟後立刻重開機，DS216+II 就開始大聲叫了，登入立刻後先把警報聲先關掉

先到儲存空間管理員中確認硬碟有正確被認出

然後就在動作中點選修復開始漫長的等待了

蠻長的等了五天，才修復完成

由於還有一顆要換，再等五天 NAS 很慢不太能用會很 OOXX，反正都過保了，就順便把記憶體從 1G 加大成 8G 吧，拿了一條 TS1GSK64V6H-I 換上，運氣很好的安裝上就可以用了

換上記憶體後，再換上新硬碟開始修復，這次竟然 7 小時就修復完成了，比上次整整快了 17 倍，果然記憶體擴大後整個效能都提升了。

修復完之後，因為是擴大硬碟，所以還要進來儲存空間動作內的設定執行最大化來擴張可使用空間大小，這個操作系統瞬間就完成了，這是 NAS 升級完成，打完收工。

Clear ClickOnce Cache

方法1. 用命令提示字元進行刪除，

rundll32 dfshim CleanOnlineAppCache

等待跑一下就刪光了

方法2. 到使用者資料夾刪除

將這個資料夾下的資料夾跟檔案都刪除

C:\Users\username\AppData\Local\Apps\2.0\

SQL Server ERRORLOG 太大

SQL Server 因為硬碟壞掉，造成了ErrorLog 成長速度飛快，直接把 C 槽吃到沒有空間，一路長到21.6 GB，還有一大堆 Dump 的 檔案就佔了 40 G。

 

只好把有問題的 DB 都刪掉或是卸載掉，把 Dump 的紀錄檔都刪除，剩下就是這個肥大的 ERRORLOG 了。

為了不重啟服務，只好用來回收當前的 Log，因為 ERRORLOG 數量最少為 6，所以跑七次後就都清空了。

EXEC sp_cycle_errorlog;

兒子的第一次發燒

兒子在 9/30 打完滿兩個月的預防針五合一、肺炎鏈球菌跟口服輪狀疫苗，當天下午都還好，晚上體溫就開始一路往上飆，直達 38.5 度，嚇的我立刻幫兒子洗一個溫水澡，降降溫，洗完之後有降一些，沒多久要標到 38度 XXDD。

醫生也沒特別說明會發燒還怎麼樣，女兒以前打也都很正常，上網查了一下，很多小孩都是這針發燒的，寶寶手冊上面還寫發燒是罕見，這個罕見發生機率頗高，我問了身邊至少有五成以上都有，又是一個 OOXX。

好在 10/01 早上兒子已將降到 37.5 了，比正常高一點而已，就沒有立刻帶他去看醫生。

結果下午三點多，托嬰中心老師打電話說兒子的耳溫有量到39度，半小時了都在 38.5度之上，我一聽，立刻請假衝回家拿健保卡接兒子去台安掛急診。

在急診室等了一下，還被急診醫生告誡這種情況應該早上有門診的時候就帶給專科醫生檢查，應該只有兩個月大，發燒就是要住 NICU，但目前滿床，小兒科不收小於四個月大的，醫生問我要轉診還是回家觀察，看了看兒子，已經沒那麼燒了，而且食慾還不錯都有把奶喝完，

我就帶著兒子跟退燒藥回家了 (急診醫生總算 開了退燒藥了)，兒子整晚暖烘烘的在 37.5度上下徘徊，到了 10/02 早上，燒退了，正常了，在 37度上下。

這次真的很嚇人，好在沒有吃退燒藥自己降下來了。

電子發票 Turnkey 軟體憑證更新

軟體憑證到期後，紀錄一下如何變更傳送憑證，前面軟體憑證申請下來之後，
最後會得到一個 PFX 檔，從『系統管理』中的『憑證管理』這邊點選「新增」，
之後將新的憑證加入。

接著在 『系統管理』中的『送方管理』選擇要變更的送方點選「編輯」，在送方憑證選擇新的憑證，接著就會用新的憑證進行上傳了。

最後，還要到電子發票整合服務平台網站上傳軟體憑證，路徑在『營業人功能清單』->『基本資料』->『軟體憑證登錄作業』，選擇剛剛新憑證的 CER 檔案，這邊就會需要主卡的工商憑證來進行驗證，驗證完成後就真的可以上傳成功了。

申請軟體憑證的方法請參考：申請軟體憑證手冊

SQL Server MSDB 檔案太大

發現硬碟空間不足，一查之下才知道是 MSDB 用去太多空間了，

根據 微軟的說法 msdb  應該就是我們存放太多紀錄了

查了一下，原來是 SQL Server Agent 的 Job 紀錄從來就沒有刪除過

只好開始刪除

 EXEC msdb.dbo.sp_purge_jobhistory @oldest_date = '20180101';

最後在設定 Agent 的屬性避免再次發生

這次找了一堆的參考，MSDB 跟 TempDB 都換位置了，才有空間可以給 Log 去成長，特別紀錄一下這次參考的網站們。

參考:
MSDB Log File Very Large - In Simple Recovery Mode
How to move the MSDB database
[MSSQL] 好胖的MSDB
一鍵幫你收縮所有DB文檔大小
MSDB数据库太大的问题
介紹 SQL Server 的系統資料庫