Effectively troubleshoot latency in SQL Server Transactional replication: Part 1
Are you struggling with latency issues in SQL Server Transactional replication? This article provides clear, step-by-step instructions to effectively troubleshoot and resolve these challenges. Dive into proven techniques and best practices that will help you enhance your SQL Server's performance and ensure seamless data replication. Don't let latency slow you down—master the art of SQL Server troubleshooting today! I hope you find this teaser engaging! If you need any adjustments or additional content, feel free to let me know. Thanks to Collin Benkler, Senior Escalation Engineer in Microsoft for SQL Server for his valuable feedbacks.
SQL Server R Services またはSQL Server Machine Learning Servicesをオフラインでインストールまたは更新プログラムを適用するための方法
こんにちは SQL Server サポートチームです。 今回は、SQL Server R Services またはSQL Server Machine Learning Servicesをオフラインでインストールまたは更新プログラムを適用するための方法について紹介します。 日本語版のSQL Server をご利用いただいているお客様より、オフライン環境でSQL Server R Services またはSQL Server Machine Learning Servicesをインストールまたは更新プログラムを適用した際に、失敗するというお問い合わせをいただくことがあります。 これはSQL Server の不具合が原因となりますが、修正目途がたっていない状況となりますため、ブログで回避策を紹介させていただきます。 作業の流れは下記の通りとなります。 １．SQL Server R Services またはSQL Server Machine Learning Servicesをオフラインでインストールする場合 1) インターネットに接続できる環境で、リリースバージョンにあったcab ファイルをダウンロードします。 各リリースバージョンのcabファイルのダウンロード URL は、次のページをご確認ください。 SQL Server 2019 の場合： https://learn.microsoft.com/ja-jp/sql/machine-learning/install/sql-ml-component-install-without-internet-access?view=sql-server-ver15#1---download-2019-cabs SQL Server 2017 の場合： https://learn.microsoft.com/ja-jp/sql/machine-learning/install/sql-ml-component-install-without-internet-access?view=sql-server-2017#1---download-2017-cabs SQL Server 2016 の場合： https://learn.microsoft.com/ja-jp/sql/machine-learning/install/sql-ml-component-install-without-internet-access?view=sql-server-2016#1---download-2016-cabs 2) 適用対象のサーバーに、cabをコピーします。 ※ 任意のパスで結構です。ここでは例として、C:\Temp にコピーするとします。次からの手順は、C:\Temp 配下にコピーした場合の手順となります。 3) 各cabファイルの末尾が1033となっているため、1041にコピーします。 例）SQL Server 2019 の場合 SPO_4.5.12.120_1033.cab -> SPO_4.5.12.120_1041.cab SPS_9.4.7.25_1033.cab -> SPS_9.4.7.25_1041.cab SRO_3.5.2.125_1033.cab -> SRO_3.5.2.125_1041.cab SRS_9.4.7.25_103 3.cab -> SRS_9.4.7.25_1041.cab この結果C:\Temp 配下に、次のファイルが存在することになります。 SPO_4.5.12.120_1033.cab SPO_4.5.12.120_1041.cab SPS_9.4.7.25_1033.cab SPS_9.4.7.25_1041.cab SRO_3.5.2.125_1033.cab SRO_3.5.2.125_1041.cab SRS_9.4.7.25_1033.cab SRS_9.4.7.25_1041.cab 4) インストールを行います。 ※ [Microsoft Machine Learning Server コンポーネントのオフライン インストール] では [インストール パス] に、「C:\Temp」を指定します。 4-1) インストール メディアを開き、setup.exe を右クリックし、管理者として実行します。 4-2) セットアップ ウィザードで、オープンソースの R または Python コンポーネントに対するライセンスのページが表示されたら、 [同意する] をクリックします。 ライセンス条項に同意すると、次の手順に進むことができます。 4-3) [オフライン インストール] ページが表示されたら、 [インストール パス] に、以前にコピーした CAB ファイルが格納されているフォルダーを指定します。 図1．Microsoft Machine Learning Server コンポーネントのオフライン インストール画面 4-4) 画面の指示に従って続行し、インストールを完了します。 参考情報 セットアップの実行 https://docs.microsoft.com/ja-jp/sql/machine-learning/install/sql-ml-component-install-without-internet-access?view=sql-server-ver15#run-setup 2．SQL Server R Services またはSQL Server Machine Learning Servicesの更新プログラムをオフラインで適用する場合 1) インターネットに接続できる環境で、更新プログラムにあったcab ファイルをダウンロードします。 各更新プログラム用のcabファイルのダウンロード URL は、次のページをご確認ください。 SQL Server 2019 の場合： https://docs.microsoft.com/ja-jp/sql/machine-learning/install/sql-ml-cab-downloads?view=sql-server-ver15#sql-server-2019-cabs SQL Server 2017 の場合： https://docs.microsoft.com/ja-jp/sql/machine-learning/install/sql-ml-cab-downloads?view=sql-server-2017#sql-server-2017-cabs SQL Server 2016 の場合： https://docs.microsoft.com/ja-jp/sql/machine-learning/install/sql-ml-cab-downloads?view=sql-server-2016#sql-server-2016-cabs 2) 適用対象のサーバーに、cabをコピーします。 ※ 任意のパスで結構です。ここでは例として、C:\Temp にコピーするとします。次からの手順は、C:\Temp 配下にコピーした場合の手順となります。 3) 各cabファイルの末尾が1033となっているため、1041にコピーします。 例）SQL Server 2019 CU8 の場合 SPO_4.5.12.479_1033.cab -> SPO_4.5.12.479_1041.cab SPS_9.4.7.958_1033.cab -> SPS_9.4.7.958_1041.cab SRO_3.5.2.777_1033.cab -> SRO_3.5.2.777_1041.cab SRS_9.4.7.958_1033.cab -> SRS_9.4.7.958_1041.cab この結果C:\Temp 配下に、次のファイルが存在することになります。 SPO_4.5.12.479_1033.cab SPO_4.5.12.479_1041.cab SPS_9.4.7.958_1033.cab SPS_9.4.7.958_1041.cab SRO_3.5.2.777_1033.cab SRO_3.5.2.777_1041.cab SRS_9.4.7.958_1033.cab SRS_9.4.7.958_1041.cab 4) インストールを行います。 ※ [Microsoft Machine Learning Server コンポーネントのオフライン インストール] では [インストール パス] に、「C:\Temp」を指定します。 4-1) 更新プログラムのインストーラーを実行します。ライセンス条項に同意し、[機能の選択] ページで、累積的な更新プログラムが適用される機能を確認します。 機械学習機能を含む、現在のインスタンスにインストールされているすべての機能が表示されます。 図2. 機能の選択画面 4-2) ウィザードを続行し、R および Python ディストリビューションのライセンス条項に同意します。 [オフライン インストール] ページが表示されたら、 [インストール パス] に、以前にコピーした CAB ファイルが格納されているフォルダーを指定します。 図3. Microsoft Machine Learning Server コンポーネントのオフライン インストール画面 参考情報 累積的な更新プログラムの適用 https://docs.microsoft.com/ja-jp/sql/machine-learning/install/sql-ml-component-install-without-internet-access?view=sql-server-ver15#apply-cumulative-updates ※ 本Blogの内容は、2021年5月現在の内容となっております。イメージのランダム化を強制する(必須ASLR) に「既定でオンにする」を設定した場合、Express Edition の日本語版のインストーラの起動に失敗します
こんにちは。日本マイクロソフト SQL Server サポートチームです。 事象： イメージのランダム化を強制する(必須ASLR) に「既定でオンにする」を設定した場合、SQL Server 2016 ならびにSQL Server 2019 のExpress Edition の日本語版のインストーラ(SQLEXPR_x64_JPN.exe) の起動に失敗します。 なお、イメージのランダム化を強制する(必須ASLR) の規定値は「既定でオフにする」であり、既定値では発生しません。 また、SQL Server 2014、SQL Server 2017、SQL Server 2022 のExpress Edition の日本語版のインストーラー(SQLEXPR_x64_JPN.exe) では発生しません。 ※ 公開時点 イメージのランダム化を強制する(必須ASLR)の設定手順は以下となります。 スタートメニューより[設定] -> [更新とセキュリティ] -> [Windows セキュリティ] -> [アプリとブラウザーの制御] -> [Exploit Protection の設定] -> [システム設定] -> [イメージのランダム化を強制する (必須ASLR)] 図．Windows セキュリティ画面(ご参考) 原因： SQL Server のセットアップは、イメージのランダム化を強制する(必須ASLR) を想定しておらず、SQL Server 2016 ならびにSQL Server 2019 のExpress Edition の日本語版のインストーラ(SQLEXPR_x64_JPN.exe) では、対応が行われていません。 イメージのランダム化を強制する(必須ASLR) に「既定でオンにする」を設定した環境で、インストーラ(SQLEXPR_x64_JPN.exe) の起動に失敗する以外の問題はありません。 回避策： 恐れ入りますが、SQL Server 2016 ならびにSQL Server 2019 のExpress Edition の日本語版のインストーラ(SQLEXPR_x64_JPN.exe) を変更し、再リリースする予定はありません。 そのため、イメージのランダム化を強制する(必須ASLR) に「既定でオンにする」を設定している環境では、次のように一時的に「既定でオフにする」に変更して展開し、SQL Server をインストールします。 1) イメージのランダム化を強制する(必須ASLR)を、「既定でオフにする」に変更します。 2) SQL Server 2016 またはSQL Server 2019 のExpress Edition の日本語版のインストーラー(SQLEXPR_x64_JPN.exe) を起動してファイル群を展開します。 3) イメージのランダム化を強制する(必須ASLR)を、「既定でオンにする」に変更します。 4) SQL Server のインストールを進めます。 なお、SQL Server Express を再配布されている場合、現時点でパッケージを展開して再配布することは、モジュールの変更とはみなされないことを確認しています。
SQL Server Database Mail Failure Troubleshooting & Two Common Issues
This blog discusses troubleshooting steps to investigate the failure of SQL Server Database Mail service on sending email. It also discusses 2 special scenarios with SQL Server Database Mail that commonly cause mail sending failure General Troubleshooting Steps to Narrow Down RCA Special Scenarios: Scenario 1: Implicit SSL/TLS mode is not supported for SQL Server DB Mail. If your SMTP server requires implicit TLS, then SQL Server DB Mail will not be able to send email using this SMTP server. Scenario 2: SQL DB Mail failure caused by SMTP mail server requesting TLS 1.2. In this case, TLS 1.2 needs to be enabled at DB Mail server. Commonly Used Protocols and Port ======================== protocol No encryption TLS/SSL TLS/SSL Plain port Explicit port Implicit port FTP 21 21 990 SMTP 25 or 587 25 or 587 465 IMAP 143 143 993 POP3 110 110 995 Telnet 23 23 992 HTTP 80 - 443 General Troubleshooting Steps to Narrow Down RCA ===================================== Check SQL DB Mail errors from DMV and logs /*List all DB Mail event log*/ SELECT * FROM msdb.dbo.sysmail_event_log ORDER BY log_date DESC /*List all failed items */ SELECT er.log_id AS [LogID], er.event_type AS [EventType], er.log_date AS [LogDate], er.description AS [Description], er.process_id AS [ProcessID], er.mailitem_id AS [MailItemID], er.account_id AS [AccountID], er.last_mod_date AS [LastModifiedDate], er.last_mod_user AS [LastModifiedUser], fi.send_request_user, fi.send_request_date, fi.recipients, fi.subject, fi.body FROM msdb.dbo.sysmail_event_log er LEFT JOIN msdb.dbo.sysmail_faileditems fi ON er.mailitem_id = fi.mailitem_id ORDER BY [LogDate] DESC Check and ensure DB Mail has been enabled sp_configure 'show advanced options', 1; GO RECONFIGURE; GO sp_configure 'Database Mail XPs', 1; GO RECONFIGURE GO Check and ensure the SQL Server service account has permission to call the Database mail’s executable file (DatabaseMail.exe) Example: Install Path:\Program Files\Microsoft SQL Server\MSSQL1.SQL2019\MSSQL\Binn\DatabaseMail.exe Check DB Mail account profile’s security configuration options and port number you have chosen for further troubleshooting purpose The Port Number you have chosen for this account Whether or not you have checked the box “this server requires a secure connection(SSL)” The type of SMTP authentication you have chosen Steps: Open SSMS, select Management, right-click Database Mail, and select Configure Database Mail -> Manage Database Mail accounts and profiles > Next. Telnet Port and IP of SMTP Server. In SQL DB Mail server, telnet the SMTP server to see if SQL machine can communicate with the IP and port of your SMTP (the port number configured in your profile). Most SMTP servers use port 25. If the telnet is not successful, it means the network communication from DB Mail server to SMTP server has caused the problem. If the DB Mail server can communicate with other server without issue, then the problem lies on the network traffic with SMTP server Open CMD as administrator and run below command to telnet your target server IP and port telnet [domain name or ip] [port] For example, to verify connection to 192.168.0.10 on port 25, issue the command: telnet 192.168.0.10 25 Configure TELNET in your server: Windows 7, 8. 10: Open Windows Start menu > Type "Control Panel" > Press Enter > “Programs” > "Programs and Features" > Turn Windows features on or off > Select "Telnet Client" > Press “OK" Windows Server 2012, 2016: Open “Server Manager” > “Add roles and features” > click “Next” until reaching the “Features” step > tick “Telnet Client” > click “Install” > when the feature installation finishes, click “Close”. Run Testing Script to Send email. If telnet to the IP and port from DB Mail server to SMTP server is successful, it means the network from DB server to SMTP server is good. We will need to test and see if we can send DB Mail via PowerShell or other scripts (rule out impact of DB Mail service and see if we could directly send email to your SMTP server to isolate the issue further). Also, we suggest to test and see if we can switch to a public SMTP server for the same DB Mail profile as well as switch to different DB Mail profile to narrow down whether it is profiler issue, SMTP server issue, or SQL Server DB Mail service issue. Below is a sample PowerShell Script to send DB mail $UserCredential = Get-Credential enter this: user:test@chimex.onmicrosoft.com password:yourpassword Send-MailMessage -to "youremail" -from "test@chimex.onmicrosoft.com" -subject "powershell" -body "powershell" -BodyAsHtml -smtpserver smtp.office365.com -usessl -Credential $UserCredential If step 6 is not able to be directly tested in your environment, kindly collect a network monitor trace when you reproduce the issue (failed to send DB Mail) If you do not see clear evidence to find RCA in the network trace for client or SMTP server reset, based on the symptom, you may need to collect a TTT debug trace for dbmail.exe and work with Microsoft support. Special Scenarios: =============== Scenario 1: Implicit TLS mode is not supported for SQL Server DB Mail. If your SMTP server requires implicit TLS, then SQL Server DB Mail will not be able to send email with this SMTP server. You can consider the options of switching to a different SMTP Server (such as a public one) that support STARTTLS or making modification in your SMTP server to support STARTTLS If your DB Mail profile has enabled SSL encryption, then STARTTLS would be required in the secured communication between your DB Mail server and SMTP Server. For SQL Server Database Mail architecture, as our service relies on .Net System.Net.Mail (SmtpClient class) and System.Net.Mail does not support “Implicit SSL/TLS“mode, SQL Server Database Mail does not support it as well. In the past, port 465 can be used to support “Implicit SSL/TLS“mode (SMTP over SSL). Now it is no longer supported. (more details , kindly refer SmtpClient.EnableSsl Property (System.Net.Mail) | Microsoft Docs ) More Details with STARTTLS and “Implicit SSL/TLS” --------------------------------------------------------------------- “STARTTLS” is an email protocol command that would turn an insecure network connection into a secured one. If email client server has enabled/request SSL or TLS encryption, then STARTTLS would be required for SQL Server DB Mail service to successfully send email. “Implicit SSL/TLS” is another mode for secured client to server communication. The major two differences between “STARTTLS” and “Implicit SSL/TLS” are summarized as below (while there are a couple of other differences) : With the “Implicit SSL/TLS” mode, email client server connects to the SMTP server and TLS/SSL encryption is switched on implicitly as soon as the connection is established while under “STARTTLS” mode, client explicitly requests TLS/SSL encryption to be switched on after initial TCP handshake. With “Implicit SSL/TLS” mode, if the connection is not able to be built with encrypted security mode, the email will be prevented from being sent. However, with “STARTTLS”, if the SMTP mail server not able to support TLS encryption as requested by email client server, the email client server will negotiate with the SMTP server and agree to downgrade to an unencrypted connection. Thus, with “STARTTLS”, you can use the same port for encrypted and plain text mail. Scenario 2: SQL DB Mail failure caused by SMTP mail server requesting TLS 1.2. In this case, TLS 1.2 needs to be enabled at DB Mail server. Multiple DB Mail cases have seen its failure being caused by client DB Mail server not supporting TLS 1.2 while the SMTP mail server is requesting TLS 1.2. Unfortunately, most often the error observed in Database Mail Log Viewer (sysmail_event_log) is very generic as below. From network monitor trace, you may not see any STARTTLS traffic as the connection can be reset by DB mail server after initial handshake. The mail could not be sent to the recipients because of the mail server failure. (Sending Mail using Account 2 (2022-03-14T16:58:54). Exception Message: Cannot send mails to mail server. (Failure sending mail.). ) If Schannel errors are detected in Windows system event logs around the same time when DB Mail failure happens, you are suggested to use below troubleshooting steps to see if the failure is related to TLS 1.2 requested by SMTP server. Use the first 7 steps mentioned earlier to narrow down other issues that can play a role in the scene. Check system event log for any Schannel errors (or any errors) from the same time as the database mail failure occurred Below are a few examples but there could be others. Any Schannel error occurring at the same time as the database mail failure should be cautiously checked. {timestamp},Error,{servername},36887,Schannel,A fatal alert was received from the remote endpoint. The TLS protocol defined fatal alert code is 70. {timestamp},Error,0,36871,Schannel,{servername},A fatal error occurred while creating a TLS client credential. The internal error state is 10013. If Schannel errors are spotted at the same time when DB Mail fails which can easy to be reproduced, check and ensure your SQL Server and Windows has the necessary hotfixes to support TLS 1.2 (refer link https://support.microsoft.com/en-us/topic/kb3135244-tls-1-2-support-for-microsoft-sql-server-e4472ef8-90a9-13c1-e4d8-44aad198cdbe ) Check registry settings in DB Mail server and make sure the needful ones are present. Reboot is needed for the change to take effects. (Please first take a backup of your registry key and store them in another machine before you make any change! ) [HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v2.0.50727] "SystemDefaultTlsVersions"=dword:00000001 "SchUseStrongCrypto"=dword:00000001 [HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319] "SystemDefaultTlsVersions"=dword:00000001 "SchUseStrongCrypto"=dword:00000001 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727] "SystemDefaultTlsVersions"=dword:00000001 "SchUseStrongCrypto"=dword:00000001 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319] "SystemDefaultTlsVersions"=dword:00000001 "SchUseStrongCrypto"=dword:00000001 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2] [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client] "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server] "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001 DISCLAIMER : THIS CODE AND INFORMATION IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.Use Orca.exe Tool to Verify Corrupted MSI/MSP file in Failed SQL Patching
DISCLAIMER : THIS CODE AND INFORMATION IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. Multiple reasons can cause the failure of installing SQL Server patch. For example, corrupted registry key record for your SQL components , missing or corrupted MSI/MSP files for your SQL components, lack of permission for the required file or file in use during patch installation process, etc. One of the common causes is corrupted SQL Server's Windows Installer database file (.MSI) or the Windows Installer patch file (.MSP) cached in your local server's Windows Installer Cache folder located on %windir%\installer. This type of corruption can happen frequently when you have anti-virus software, VM backup tool, or 3rd party security software that scans the file/folder. As enlightened by a discussion with my colleague Richard Chen, SQL Server Escalation Engineer and a couple of cases investigation, this article discusses a simple way to narrow down the corruption and resolve this type of corrupted MSI/MSP file issue via Orca.exe tool that cannot be easily detected by FixMissingMSI tool nor fixed by 'Repair' option provided by 'setup.exe' program. (Similar error has also been discussed on this blog while a few other common issues for failed SQL patch/uninstallation are discussed already on this official document.) ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- Depends on the features you have installed for your SQL Server, a few shared components of SQL Database Engine and SQL feature-based components will be verified and patched during one sitting of patch installation process. If any of these required components' MSI/MSP file or registry key record is unreachable(for example, corrupted file, missing registry key removed by 3rd party anti-virus tool, etc.), the patch installation process will fail. Please be noted that multiple issues can all play a role in your server that contribute to the patch failure. For example, your MSP files are corrupted while you also have a few registry key record missing. In this case, after resolving one issue, you will hit a different exception next time when you try to install. We need to resolve them one by one in order to successfully complete the patch installation process. (NOTE: It is recommended to take backup of all related files before the change to ensure we don't have any potential data loss.) Symptoms ======= You have encountered error 'No valid sequence could be found for the set of updates' in 'Details.txt' log for your failed patch attempt. You have tried to use FixMissingMSI tool to restore all your issued MSI/MSP files on the server . You also tried 'Repair' option provided by setup.exe program to recover your SQL instance. However, the same failure persists. Troubleshooting =========== Step 1: Check 'Details.txt' log in your SQL Server version's Setup Bootstrap 'Log' folder to narrow down the cause of the patch installation failure. The 'Log' folder in the 'Setup Bootstrap' folder stores log and error details for all installation, uninstallation , and repair attempts for your SQL instance on the server. Default Path: “C:\Program Files\Microsoft SQL Server\<Your SQL Version Number>\Setup Bootstrap\Log\<Your Issued Setup Timestamp>” Step 2: If you see below error 'no valid sequence could be found' in 'Details.txt' log, search for all of this error's occurrence on this log and note down all the SQL components' name that encounters this exception(example see below). This exception means the sequence number for this component's cached MSI/MSP file fails to be mapped during the process of installing subsequence patch. It can either be caused by corrupted MSI/MSP file or missing/corrupted record on the registry key that record the related component's MSI/MSP file information 2021-10-20 14:02:01 Slp: No valid sequence could be found for the set of updates. 2021-10-20 14:02:01 Slp: Watson bucket for Msi based failure has been created 2021-10-20 14:02:01 Slp: Error: Action "Install_sql_*****_Action" failed during execution. <---------in here will print the name of the SQL component that encounters this exception during the upgrade process. Step 3: Go to each of the issued component's separate log (These logs are stored on the same folder) and check if we have hit error "PATCH SEQUENCER ERROR: failed to open **". If that's the case, check the actual cached MSI and MSP files' name used in the sequence patch process in the log as the example in my LAB showed in below. These MSI and MSP files are used in the patch sequence verification process and some of their information suspected to be compromised to cause the patch sequence verification failure. We will need to verify the actual file's integrity as well as the mapping registry key record to narrow down the problem. MSI : Opening existing patch 'C:\Windows\Installer\12a3b45.msp'. //*Testing example file name as each of these MSP files should be uniquely named in your server *// MSI : Opening existing patch 'C:\Windows\Installer\23a4f56.msp'. //*Testing example file name as each of these MSP files should be uniquely named in your server *// MSI : Note: 1: ******: 3: MsiPatchSequence MSI : Patch we're running from ==> C:\Windows\Installer\c12d345.msp//*Testing example file name as each of these MSP files should be uniquely named in your server *// MSI : SequencePatches starts. Product code: *****, Product version: *****, Upgrade code: ****, Product language **** MSI : Note: 1 MsiPatchSequence MSI : Note: 1: Target01ToUpgrade01 **** MSI : PATCH SEQUENCER ERROR: failed to open Target01ToUpgrade01 transform in ****** patch! (****** ) Step 4 : Check the MSP file 's integrity on Windows Installer Cache folder, located in c:\windows\installer. Use Orca.exe tool ( a public tool shipped with Windows SDK - MSI tool in this link) to open each of these MSI/MSP files and check its integrity. A common issue you will see is missing the 'MsiPatchSequence' table for this file on Orca.exe's result. When this happens, the file's internal sequence information is corrupted and thus, will cause the error for failing the sequence patch process. Below is an example of a corrupted MSP file on an issued server and a healthy copy of the same MSP file extracted from its corresponding source SQL patch package. 1) Corrupted MSP file's Orca result : missing the 'MsiPatchSequence' table 2) A healthy copy for the same MSP file extracted from its source SQL patch package Step 5: In order to fix this corrupted MSI/MSP file, you will need to get a healthy copy for the same file from its source SQL patch package. To do so, you will need to know its source SQL patch's KB number or version and its original name before cached to your local server. You can either directly get it from the Orca.exe's result or use the SQLInstall.vbs script's result to check as sometimes the file may be too corrupted to be queried by the Orca.exe tool. SQLInstall.vbs will script out all your existing SQL instances' MSI and MSP file information as long as they exist on your registry key record. Sometimes if the corresponding registry key record is missing or corrupted, you will also not get any valid information for this MSI/MSP file in the script result. Below is the steps for getting this script's result (you can also refer to this official document that discusses it) 1) Download the FindSQLInstalls.vbs from its raw page in this link 2) Select all of the contents on this page, copy, and paste it to a text file. Save the text file as FindSQLInstalls.vbs. 3) Open an elevated command prompt to the directory to which you saved the FindSQLInstalls.vbs file, and run the command: Cscript FindSQLInstalls.vbs %computername%_sql_install_details.txt . 4) Open the file output from Step 3, and search for your issued MSI/MSP file's actual cached name on your server. Then, you will get its registry key record result as scanned by this script. Step 6: Once you get the information in step 5, download the SQL patch package and then, you will need to extract the package directly. Once you get the healthy copy of the file, rename it to its cached name as you find on the component's log and replace the corrupted one with this new copy in the Windows Cache folder. You can use below script to extract your SQL patch package. 1) Download the target SQL patch package from Microsoft Catalog 2) Open an elevated CMD window and change the directory to the path where you have stored the downloaded package: pushd C:\temp\package 3) Run the same command for each “.exe” file in the package to extract installation files into the same destination path (the new folder created in step 2) by changing the file name and the destination path in below script. Each time you execute the command, a pop up window may ask you to specify the destination path. Please ensure it is the path specified. SQLServer2016SP1-KB3182545-x64-ENU.exe /s /x /b"C:\temp\youroutputfoldername" /v"/qn" Step 7: Perform the same check for all the SQL components that hit the exactly same exception and ensure the corrupted MSI/MSP files are replaced. Retry the patch installation. If you hit failure again, check the latest 'Details.txt' log first and narrow down the new exception for next step of resolution.SQL Server : Large RAM and DB Checkpointing
First published on MSDN on Jun 29, 2017 SQL Server : large RAM and DB Checkpointing Hi everyone,This post’s purpose is to establish a summary of the specific behaviors with relation to DB Checkpoint that may happen within SQL Server when running with a large quantity of allocated memory and when applicable, how to best address them.
