Shrink Database從8T壓縮到5T要多久?

        有機會碰到這樣的需求應該不多，特此記錄一下，執行環境尚未上線，所以可以有時間來處理，硬碟是SAS 10K 1.2T的，使用Raid 5，用Backup測試一下IO的速度如下

        實際在Shirk的IO如下，沒有其他活動喔，以上數據僅供參考

[MySQL]Row size too large. The maximum row size for the used table type, not counting BLOBs, is 8126.

        最近遇到下面這個錯誤，該Table有近三百個欄位，因為這是為了分析來源文字檔所產生Table，來源文字檔欄位數及欄位長度不是我能控制的，還有愈來愈多的跡象

[MySQL]用SELECT INTO OUTFILE匯出資料成CSV

        一般在要在命令列模式下要將MySQL的資料匯出成CSV，我通常都是直接mysql -e "SQL Statement" > /tmp/output.csv，然後SQL Statement用CONCAT組成逗號分隔的字串出來

        後來看書上提到用SELECT INTO OUTFILE更快，於是測試了一下，寫了兩個Shell，主要的SQL Statement是一樣的，只是一個用CONCAT，一個用INTO OUTFILE

        第一個Shell，測試時間的方法如下圖，其中SQLCMD是為一般SELECT CONCAT

無法開啟SQL Server Error Log

        今天在檢查某台SQL Server，在本機上透過SSMS要開啟Error Log，等了好久居然打不開？出現如下錯誤

An exception occurred while executing a Transect-SQL statement or batch.
(Microsoft.SqlServer.ConnectionInfo)
A severe error occurred on the currentcommand. The results, if any, should be discarded

[SSIS][Error]ADO NET Source: Object reference not set to an instance of an object.

Description: System.NullReferenceException: Object reference not set to an instance of an object.  
Description: ADO NET Source failed the pre-execute phase and returned error code 0x80004003.

        突然有天，運行數月的SSIS排程失敗了，這SSIS主要是從MySQL匯入資料到SQL Server上，錯誤訊息如上，用的是MySQL ODBC Provider

        為什會有NullReferenceException的異常讓我百思不解？最後研究發現應該是網路的問題，詢問網管後才得知，公司前一天有被DDOS攻擊，防火牆有做調整，造成大資料量的傳輸會被封鎖，小資料量的傳輸就都沒有問題，DB間使用的網段加入白名單就解了，很瞎吧

     

[SSAS]Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host

        原本運作正常的Cube，突然間連線時出現下面這個錯誤

Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host

        查了半天，想說我什都沒動啊，到底哪出了錯，該不會遇到什bug吧，因為用2014的，結果是個愚蠢的錯，windows account忘了勾永不過期，預設45天就過期了XD

[Oracle優化]CPU使用率突然飆高了！

        某天管理的Oracle，它的CPU使用率突然飆高了一倍，平常使用率很低的，所以飆高了一倍還好。對一個穩定的系統來講，CCU沒有多一倍，CPU卻飆高一倍是很奇怪的，而且接下公司有辦活動，要是CCU暴增就不敢保證不會有問題了，所以要想辦法找出什麼原因造成CPU飆高

        首先看飆高當天的AWR，下圖是Top 5 Timed Foreground Events，第一名的DB CPU約佔73%，第二名的library cache: mutex X只佔10%左右，這還算正常