2019年3月20日 星期三

SQL Server RML Utilities pressure testing tool

env: Windows Server 2016
         SQL Server 2016 SP2

 RML Utilities是一個好用的簡易壓測工具,這個工具已經有點歷史,這次在新環境安狀測試看看。

1.這次使用的版本是CU4
RML Utilities for SQL Server (x64) CU4
下載連結:
https://www.microsoft.com/en-us/download/details.aspx?id=4511

Supported Operating System
Windows 7, Windows 8, Windows 8.1, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2

2.安裝RML Utilities for SQL Server (x64) CU4
 
這次省略說明。附上安裝步驟畫面
 




















可以順利在Windows Server 2016安裝



3.檢查安裝程式,並開始使用RML

安裝程式清單

















點選"RML Cmd Prompt"













在"RML Cmd "輸入"ostress /?",顯示相關指令參數



















4.使用"RML Utilities"進行壓力測試

在RML指令視窗輸入以下指令:做查詢Server Name的測試
command:
ostress.exe -Q"Select @@VERSION"



這裡有一點要留意,在RML產生2個檔案,一個是LOG檔,一個是OUT檔。
LOG檔記錄執行結果。OUT檔紀錄SCRIPT結果。以我們這個測試案例,就是SELECT @@VERSION的產出結果。
檔案儲存目錄:
C:\Users\Administrator\AppData\Local\Temp\output\


 5.測試範例二
 command:
 ostress.exe -Q"SELECT @@VERSION" -r10

 -r 10 代表執行10次













6.測試範例三
command:
ostress.exe -Q"SELECT @@VERSION" -r10 -q

-q : 不會輸出查詢結果到dos 與檔案




7.測試範例四
command:
ostress.exe -dTBTEST03 -Q"SELECT * FROM dbo.test01" -r20 -n40

ostress.exe -SWIN-LON676ITMD5 -Usa -Ppa$$w0rd -dTBTEST03 -Q"EXECUTE dbo.TESTQUERY" -r20 -n40

RML跟sqlcmd很接近,也可以使用遠端連線進行壓測,留意指令格式即可。

-n 代表使用多Thread進行

以下是執行command後,查詢連線數
其中有一連線是查詢連線,所以有41個





這次測試安裝驗證到此一個段落!!!


2019年3月14日 星期四

SQL Server 2016 database mail queue inactive by bug

env: Windows Server 2016
        SQL Server 2016 SP2

這幾天發現某幾台的SQL Server怎麼都沒有發送一些警示的mail,是管理的太好嗎?感覺不太可能,因為機器的資源很少,難免會出現一些壓力測試的警訊。

所以開始一步一步檢查SQL Server database mail

1.檢查database mail queue與status
command:
EXEC msdb.dbo.sysmail_help_queue_sp

database mail queue竟然有383,很多mail沒有發送出來







2.檢查database mail是否啟動
command:
EXEC msdb.dbo.sysmail_help_status_sp

database mail確定有啟動






3.再次使用查詢指令確認是否有mail尚未發送,與哪些mail已送出
command:
SELECT * FROM msdb.dbo.sysmail_sentitems;
SELECT * FROM msdb.dbo.sysmail_unsentitems;


已sent的mail是0,但是有很多unsent的mail紀錄












4.確認msdb的service broker是否啟用
command:
SELECT is_broker_enabled FROM sys.databases WHERE name = 'msdb';

msdb的service broker已經啟用





5.因為一直找不到哪裡錯誤,所以往微軟官方找文件看看
結果找到以下訊息

SQL Server 2016 SP2 CU4
https://support.microsoft.com/en-gb/help/4464106/cumulative-update-4-for-sql-server-2016-sp2








When you install Cumulative Update 1(CU1), CU2 or CU3 for Microsoft SQL Server 2016 Service Pack 2, you will notice that the config file DatabaseMail.exe.config may be removed. Additionally, the Database Mail feature may not work correctly and cannot send email messages.

裡面提到DatabaseMail.exe.config這個檔案可能被移除。
在檢查後,可以確認是一定會被移除。


SQL Server 2016 SP2 CU5








這裡也有修復database mail的錯誤

另外一篇
SQL Server 2016 SP1 CU1

FIX: SQL Server 2016 Database Mail does not work on a computer that does not have the .NET Framework 3.5 installed or stops working after applying SQL Server update


SQL Server 2016 SP1 CU2
https://support.microsoft.com/en-au/help/4013106/cumulative-update-2-for-sql-server-2016-sp1









6.確認修復方式與範圍
Database mail bug損害的版本範圍:
SQL Server 2016 SP1 CU1
SQL Server 2016 SP2 CU1, CU2, CU3

現行版本SQL Server 2016 SP2 CU1,可以利用service pack修復,但是要重開機。

7.找尋可以修復卻不用重開機的方式
用service pack的方式行不通
所找這篇來看看
SQL Server 2016 SP1 CU1

FIX: SQL Server 2016 Database Mail does not work on a computer that does not have the .NET Framework 3.5 installed or stops working after applying SQL Server update

裡面有提到做法:
To work around this issue, you can implement any one of the following:
1. Create the DatabaseMail.exe.config and drop it next to the DatabaseMail.exe under the Binn folder. You can use notepad.exe or any other editor to edit it. Just make sure you save it by using UTF-8 encoding (in notepad.exe, select Save As... and in the Encoding combo box, select UTF-8):
         <?xml version="1.0" encoding="utf-8" ?>
         <configuration>
         <startup useLegacyV2RuntimeActivationPolicy="true">
         <supportedRuntime version="v4.0"/>   
         <supportedRuntime version="v2.0.50727"/>
         </startup>
         </configuration>
2. Run a repair setup action of SQL Server 2016.
3. Manually install .Net Framework 3.5 on the machine.

但是我想不透為何與.Net Framework 3.5有關???

8.開始進行修復,確認DatabaseMail.exe.config是否存在
檔案目錄:
” C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\Binn”



9.修復database mail
因為我覺得這篇文件寫得有點誇張
https://support.microsoft.com/en-au/help/3186435/sql-server-2016-database-mail-doesn-t-work-when-net-framework-3-5

除了建立DatabaseMail.exe.config
還要執行下面步驟
Run a repair setup action of SQL Server 2016.
Manually install .Net Framework 3.5 on the machine.

所以我決定忽略後面兩個步驟。

建立DatabaseMail.exe.config的動作,我也找一台SQL Sserver 2016把檔案複製過來

接著執行下面指令:
USE msdb;
EXEC sysmail_stop_sp;
EXEC sysmail_start_sp;

沒錯,重啟database mail


10.確認重啟database mail後的狀態
一旦重啟後,database mail就會開始發送mail。
所以在重起錢可以考慮是否要把unsent mail刪除
刪除unsent mail指令:
EXECUTE msdb.dbo.sysmail_delete_mailitems_sp   
    @sent_status = 'unsent' ;  
GO  

11.利用指令確認mail是否還卡在queue中
command:
SELECT * FROM msdb.dbo.sysmail_sentitems;
SELECT * FROM msdb.dbo.sysmail_unsentitems;

確認沒有unsent mail











手動發送測試mail也有收到。

SQL Server database mail修復大功告成。



2019年3月9日 星期六

SQL Server data collection with error code -1071636372 and -1073450952

env: Windows Server 2016
        SQL Server 2016 SP2

很不幸Data Collection出現錯誤,這次錯誤訊息如下:
Executed as user: XXXX\XXXX. SSIS error. Component name: DFT - Upload collection snapshot, Code: -1071636372, Subcomponent: RFS - Read Current Upload Data [138], Description: String too long. The adapter read a string that was 256 bytes long, and expected a string no longer than 129 bytes, at offset 100587. This could indicate a damaged input file. The file shows a string length that is too large for the buffer column.   .  SSIS error. Component name: DFT - Upload collection snapshot, Code: -1073450952, Subcomponent: SSIS.Pipeline, Description: SSIS Error Code DTS_E_PRIMEOUTPUTFAILED.  The PrimeOutput method on RFS - Read Current Upload Data returned error code 0x80004005.  The component returned a failure code when the pipeline engine called PrimeOutput(). The meaning of the failure code is defined by the component, but the error is fatal and the pipeline stopped executing.  There may be error messages posted before this with more information about the failure.   .The master package exited with error, previous error messages should explain the cause.  Process Exit Code 5.  The step failed.



























這個錯誤看來已經有一段時間,導致儲存cache有1GB的檔案。
開始修復這個錯誤。

1.嘗試重新啟動這支job
結果還是一樣的錯誤

2.停用Data Collection














3.重新設定cache folder,設定到新的位置


































4.設定完後,可以把舊的cache folder裡面的資料刪除

5.重新啟動Data Collection排程
結果成功












2019年3月6日 星期三

SQL Server fix data collection error -1073741819 did not generate any output

env: Windows Server 2016
        SQL Server 2016 SP2

Data Collection是一項簡易的內建監控程式,可以透過SSMS設定並且將資料存放到遠端的SQL Server。但是對於此功能重度依賴的單位,一旦此功能出現無法完整運作的狀況,就會立即出現極度的不便的情形。

遇到以下的訊息,造成收集"Server Active"的功能無法運作。
message:
Executed as user: XXXX\XXXX. The step did not generate any output.  Process Exit Code -1073741819.

這個狀況僅只有少部分SQL Server有此狀況。

1.確認Data Collection排程失敗狀況
message:
Executed as user: XXXX\XXXX. The step did not generate any output.  Process Exit Code -1073741819.  .  NOTE: The step was retried the requested number of times (3) without succeeding.  The step failed.




































2.嘗試清除Data Collection並且重啟Data Collection
結果不成功




















3.檢查Data Collection的SSIS執行狀況
可以利用SSMS並且選擇Integration service來找到相關的Package.
與正常運作Data Collection的SQL Server比較後沒有不同。



4.利用SQL Profiler紀錄Data Collection執行語法語過程

SERVER1:Data Collection失敗
--無資料
exec sp_executesql N'[msdb].[dbo].[sp_ssis_getpackage] @P1, @P2',N'@P1 nvarchar(4000),@P2 uniqueidentifier',N'TSQLQuery_TW-UGSSTAGDB01_MSSQL13_MSSQLSERVER_{49268954-4FD4-4EB6-AA04-CD59D9BB5714}_3_Collect','39163C42-602B-42C9-B4F7-1843614F9625'

--有資料
exec sp_executesql N'[msdb].[dbo].[sp_ssis_getfolder] @P1, @P2',N'@P1 nvarchar(4000),@P2 uniqueidentifier',N'Generated','8877FE4B-A938-4A51-84B9-C5BDAD74B0AD'

--有資料
exec sp_executesql N'[msdb].[dbo].[sp_ssis_getfolder] @P1, @P2',N'@P1 nvarchar(4000),@P2 uniqueidentifier',N'Data Collector','00000000-0000-0000-0000-000000000000'

--有資料
declare @p5 nvarchar(max)
set @p5=N'4C134E66-FB60-4811-BA8F-3A1689695D22'
declare @p6 nvarchar(max)
set @p6=N'4AF3DD56-37D5-47E4-8C53-B225E19C2740'
declare @p7 nvarchar(max)
set @p7=N'TSQLQuery_TW-UGSSTAGDB01_MSSQL13_MSSQLSERVER_{49268954-4FD4-4EB6-AA04-CD59D9BB5714}_3_Collect'
declare @p8 nvarchar(max)
set @p8=N'TSQLQuery_TW-UGSSTAGDB01_MSSQL13_MSSQLSERVER_{49268954-4FD4-4EB6-AA04-CD59D9BB5714}_3_Upload'
exec sp_executesql N'EXEC dbo.sp_syscollector_get_tsql_query_collector_package_ids @P1, @P2, @P3 OUTPUT, @P4 OUTPUT, @P5 OUTPUT, @P6 OUTPUT',N'@P1 nvarchar(38),@P2 int,@P3 nvarchar(max) OUTPUT,@P4 nvarchar(max) OUTPUT,@P5 nvarchar(max) OUTPUT,@P6 nvarchar(max) OUTPUT',N'{49268954-4FD4-4EB6-AA04-CD59D9BB5714}',3,@p5 output,@p6 output,@p7 output,@p8 output

select @p5, @p6, @p7, @p8


SERVER2:Data Collection正常運作
--有資料
exec sp_executesql N'[msdb].[dbo].[sp_ssis_getpackage] @P1, @P2',N'@P1 nvarchar(4000),@P2 uniqueidentifier',N'TSQLQuery_TW-UGSQADB04_MSSQL13_MSSQLSERVER_{49268954-4FD4-4EB6-AA04-CD59D9BB5714}_3_Collect','39163C42-602B-42C9-B4F7-1843614F9625'

--有資料
exec sp_executesql N'[msdb].[dbo].[sp_ssis_getfolder] @P1, @P2',N'@P1 nvarchar(4000),@P2 uniqueidentifier',N'Generated','8877FE4B-A938-4A51-84B9-C5BDAD74B0AD'

--有資料
exec sp_executesql N'[msdb].[dbo].[sp_ssis_getfolder] @P1, @P2',N'@P1 nvarchar(4000),@P2 uniqueidentifier',N'Data Collector','00000000-0000-0000-0000-000000000000'

--有資料
declare @p5 nvarchar(max)
set @p5=N'F96A230F-00EA-4A54-86DC-0E1D0318B1A1'
declare @p6 nvarchar(max)
set @p6=N'C8051C44-55BC-42AD-A824-72C87EDEE5CF'
declare @p7 nvarchar(max)
set @p7=N'TSQLQuery_TW-UGSQADB04_MSSQL13_MSSQLSERVER_{49268954-4FD4-4EB6-AA04-CD59D9BB5714}_3_Collect'
declare @p8 nvarchar(max)
set @p8=N'TSQLQuery_TW-UGSQADB04_MSSQL13_MSSQLSERVER_{49268954-4FD4-4EB6-AA04-CD59D9BB5714}_3_Upload'
exec sp_executesql N'EXEC dbo.sp_syscollector_get_tsql_query_collector_package_ids @P1, @P2, @P3 OUTPUT, @P4 OUTPUT, @P5 OUTPUT, @P6 OUTPUT',N'@P1 nvarchar(38),@P2 int,@P3 nvarchar(max) OUTPUT,@P4 nvarchar(max) OUTPUT,@P5 nvarchar(max) OUTPUT,@P6 nvarchar(max) OUTPUT',N'{49268954-4FD4-4EB6-AA04-CD59D9BB5714}',3,@p5 output,@p6 output,@p7 output,@p8 output

select @p5, @p6, @p7, @p8

差異在第一句有無產生資料
exec sp_executesql N'[msdb].[dbo].[sp_ssis_getpackage] @P1, @P2',N'@P1 nvarchar(4000),@P2 uniqueidentifier',N'TSQLQuery_TW-UGSSTAGDB01_MSSQL13_MSSQLSERVER_{49268954-4FD4-4EB6-AA04-CD59D9BB5714}_3_Collect','39163C42-602B-42C9-B4F7-1843614F9625'


5.嘗試重新設定效能計數器
結果不成功

Fix PerfNet
1. Rebuilding the counters:
     cd c:\windows\system32
     lodctr /R
     cd c:\windows\sysWOW64
     lodctr /R

C:\Windows\system32>cd c:\windows\system32
C:\Windows\system32>lodctr /R
Info: Successfully rebuilt performance counter setting from system backup store
C:\Windows\system32>cd c:\windows\sysWOW64
c:\Windows\SysWOW64>lodctr /R
Info: Successfully rebuilt performance counter setting from system backup store
c:\Windows\SysWOW64>

2. Resyncing the counters with Windows Management Instrumentation (WMI):
     WINMGMT.EXE /RESYNCPERF

c:\Windows\SysWOW64>WINMGMT.EXE /RESYNCPERF

c:\Windows\SysWOW64>

6.調整registry key
調整:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems

SharedSection的第三個值從768調整為1536,重啟Windows server。
重啟Data Collection排程,成功運作。


from
%SystemRoot%\system32\csrss.exe ObjectDirectory=\Windows SharedSection=1024,20480,768 Windows=On SubSystemType=Windows ServerDll=basesrv,1 ServerDll=winsrv:UserServerDllInitialization,3 ServerDll=sxssrv,4 ProfileControl=Off MaxRequestThreads=16

to
%SystemRoot%\system32\csrss.exe ObjectDirectory=\Windows SharedSection=1024,20480,1536 Windows=On SubSystemType=Windows ServerDll=basesrv,1 ServerDll=winsrv:UserServerDllInitialization,3 ServerDll=sxssrv,4 ProfileControl=Off MaxRequestThreads=16


7.若SharedSection調整為1536沒有功用,可以調整為2048試試。




2019年3月3日 星期日

SQL Server join to hash join and optimize plan

env:Windows Server 2016
       SQL Server 2016 SP2

報表有一個新需求,在測試期間執行完畢大都需要11分鐘左右,在嘗試調整語法後還是一直卡在11分鐘。在想不到任何方法下,想說看看執行計畫是不是有遇到警告,可以優化警告的訊息來拯救我這一個建議要做倉儲卻被否決的DBA。

1.嘗試把部分資料取到要執行報表的DB,並補上需要的索引
command:
CREATE CLUSTERED INDEX [IX_CreatOn] ON [dbo].[TESTTB01]
(
[CreatOn] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, 
DROP_EXISTING = OFF, ONLINE = ON, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON,
DATA_COMPRESSION=PAGE) ON [PRIMARY]
GO

USE [TESTDB01]
GO
CREATE NONCLUSTERED INDEX [IX_Brand_Session_Date]
ON [dbo].[TESTTB01] ([Brand],[Session],[Date])
INCLUDE ([GId],[CreatOn],[Amount],[Revenue])
WITH(ONLINE=ON, DATA_COMPRESSION=PAGE)
GO


2.在執行計畫發現inner join出現警告訊息
message:
Operator used tempdb to spill data during execution with spill level 2 and 1 spilled thread(s)

一開始看到這個訊息完全想不透,跟TEMPDB有什麼關係?
上網找了一下,大多圍繞在TEMPDB空間,SQL Server記憶體。看到下面第四張圖更出現"NO STATS()",這一定更會認為是缺少統計資訊。























































3.嘗試檢查tempdb,統計資訊是否不足或缺失
command:
check cpu
SELECT cpu_count AS [Logical CPU Count], hyperthread_ratio AS [Hyperthread Ratio],
cpu_count/hyperthread_ratio AS [Physical CPU Count], 
physical_memory_kb/1024 AS [Physical Memory (MB)], affinity_type_desc, 
virtual_machine_type_desc, sqlserver_start_time
FROM sys.dm_os_sys_info WITH (NOLOCK) OPTION (RECOMPILE);

chack memory:
SELECT
(physical_memory_in_use_kb/1024) AS Memory_usedby_Sqlserver_MB,
(locked_page_allocations_kb/1024) AS Locked_pages_used_Sqlserver_MB,
(total_virtual_address_space_kb/1024) AS Total_VAS_in_MB,
process_physical_memory_low,
process_virtual_memory_low
FROM sys.dm_os_process_memory

更新統計資訊,tempdb空間充足

結果還是一樣。


4.變更inner join為inner hash join
有這個想法是剛好想起看某個教學影片講到execution plan提到hash join

調整後重新看執行計畫警告消失了,速度也有加快,剩下1分鐘。
在其他使用到這2個表的語法也改為inner hash join也有加速的效果
























5.心得
個人覺得這是一個特例,看到這個狀況還是第一次。網路上找到的都是通例。倒是多嘗試找到新方法比較有成就感。