データベースを復元しようとしたところ、SQL Serverがクラッシュし続けました。ネットワークトランスポートエラーが発生したことを示すメッセージがSSMSに表示されます(接続がクラッシュして破棄されました)。ログを確認したところ、SQL Serverが予期せず終了しただけでした。その後、サービスを再起動する必要があります。
GUIが実行しようとしたスクリプトに問題を絞り込みました。問題は、ログ末尾のバックアップを取るときに、バックアップファイルへのパスが間違っていることです。そのはず D:\mapbenefits\...
BACKUP LOG [mapbenefits]
TO DISK = N'D:mapbenefits_LogBackup_2019-02-21_13-58-24.bak'
WITH NOFORMAT, NOINIT, NAME = N'mapbenefits_LogBackup_2019-02-21_13-58-24',
NOSKIP, NOREWIND, NOUNLOAD, NORECOVERY , STATS = 5
2つの質問があります。
このパスを修正するにはどうすればよいですか?サーバーの設定に行ってみましたが、バックアップパスはD:
スラッシュなし。スラッシュを追加すると、GUIはそれを削除します。これはSSMS v17.9.1です。私は選ぶことができますD:\mapbenefits\
と動作しますが、私はD:\DATABASE\...
これはバグですか?パスが誤って入力されたからといってSQLサーバーがクラッシュするのでしょうか?ファイルパスを修正したら問題ありません。ファイルパスをいじるだけでいつでも再現できます。
クエリを実行してバージョンを確認するとCU13になりますが、設定に入るとバージョン14.0.1000.169が表示されます。
これはバグで再現可能であるため、ここに投稿しました: https://feedback.Azure.com/forums/908035-sql-server/suggestions/36920542-incorrect-filepath-with-backup- log-command-causes
これを再現することができました。
2016年にそのような無効なパスを指定すると、次のメッセージが表示されます。
バックアップデバイス「D:mapbenefits_LogBackup_2019-02-21_13-58-24.bak」を開けません。オペレーティングシステムエラー3(システムは指定されたパスを見つけることができません。)
2017 CU 13(14.0.3048.4)では、サービスがクラッシュします。最新の修正プログラム(14.0.3049.1)では、サービスはクラッシュしませんが、セッションは強制終了されると既に述べました。
同じ動作がRESTORE DATABASE
にも当てはまることを確認しました-「D:Backups」(バックスラッシュがない)または「D ::\Backups」(余分なコロン)のようなパスを渡すと、SQL Serverインスタンスがクラッシュします(これを紹介してくれてありがとう Michael K Campbell )。
存在しない「有効な」パスを入力すると、2017で正しい動作(「指定されたパスが見つかりません」)になります。
これはバグです-CU 13とホットフィックスビルドの両方で。 BACKUP
またはRESTORE
コマンドに誤ったパラメーターを渡しても、サービスがクラッシュしたりまたはセッションが終了したりすることはありません。 フィードバックサイト で報告できます。
注:このバグのサービスクラッシュバージョンは、SQL Server 2019のパブリックプレビューバージョンで再現できます(CTP2.2- Denis Rubashkin のおかげでこれを指摘してくれましたアウト)
デバッガでこれを見ると、パス検証コードが単純に壊れているようです。提供されたパスの通常の(そして非常に広範な)チェックが意味を理解できなかった後、sqlmin!CheckFileStreamReserved
を再帰的に呼び出すことにより、スタックオーバーフローを引き起こします。スタックオーバーフローはビルド3048でサービスをダウンさせます。スタックオーバーフローを処理しようとすると一連のアクセス違反が発生し、サーバー全体を停止するのではなく接続を切断することを除いて、3049でも同じことが起こります。
このバグの修正は、SQL Server 2017 CU 15でリリースされました。
修正:データベースマスターをディスクにバックアップしようとすると、スタックオーバーフローが原因でSQL Server 2017がクラッシュします
この問題は、SQL Server 2019 CTP 3.0でも解決されています。