不動の鳥の勉強記録

時間があるときに勉強したことをメモします。

pm2でNode.jsのプロセスを永続化する

■はじめに

遅くなりましたが2020年あけましておめでとうございます。今年もよろしくお願いします。
久々に投稿はNode.jsに関するものとなりました。
Expressを使用したアプリで予期せぬエラーが発生するたびにプロセスが停止してしまい、対応工数が膨らんでしまっているため、プロセスの永続化方法を調べました。

node.jsのプロセスをデーモン化するツール

「node デーモン」で検索するとforeverとpm2という2つのツールがヒットしました。npmのサイトを見るとpm2の方が週間ダウンロード数が多いのと、管理画面がかっこよかったのでpm2を試してみることにします。
Expressのサイトにもプロセスマネージャーのページがあったため、こちらを参考にしていただけるといいと思います。Express アプリケーション用のプロセス・マネージャー

早速実機で起動確認をしていきます。

■テスト環境

  • OS: Windows Server 2016 Standard
  • Node: v12.15.0
  • npm: 6.13.4
  • express-generator: 4.16.1
  • pm2: 4.2.3

■アウトライン

  1. Nodeアプリケーションの準備
  2. pm2のインストール
  3. pm2の実行

1. Nodeアプリケーションの準備

Nodeアプリケーションはexpress-generatorで作成したものを使用していきます。
以前の下記記事と同じように実行します。
テスト環境ではまっさらなOSにNode.jsをインストールしています。
npm startを行い画面が表示されたのでアプリケーションの準備はOKです。

hiyo-ac.hatenablog.com

2. pm2のインストール

pm2については下記コマンドを実行することでインストールできます。
プロセスマネージャーはNodeをインストールしたマシンで共通で利用するべき機能だと思うため、globalインストールしています。

# npm install -g pm2

Windows環境だと一部のモジュールのOSが対応していないみたいでSKIPされましたが、無視して進みます。

3. pm2の実行

pm2でexpress-generatorで作成したアプリを起動してみます。 pm2の基本的な実行方法は、

# pm2 start app.js

となっています。筆者のサンプルはexpress-generatorで作成したアプリなので、このアプリの起動方法を検討します。いくつか方法があるようですがそのうち一つだけ紹介します。
簡単にググってみると下記コマンドで起動できるという記事を目にしましたが、Windows環境からなのか正常に起動しませんでした。

# pm2 start npm -- start

※pm2コマンドは成功したように見えますが、pm2 startしてもstatusがonlineにならずerrorとなりました。

解決策npmの起動スクリプトを直接実行する

「npm start」コマンドを実行したときの起動コマンドはpackage.jsonに記載されています。 デフォルトだと

"start": "node ./bin/www"

と記載されているので、その通りに実行します。

# pm2 start ./bin/www

下記ログが表示されました。

f:id:hiyo-ac:20200208210620p:plain
pm2起動ログ
idが0で名前がwwwで起動されています。http://localhost:3000にアクセスするとページが表示されるので起動できているようです。 またプロセス停止も試してみます。下記のようにid指定で停止します。

# pm2 stop 0

下記ログが表示され、statusがstoppedとなっており停止されています。またhttp://localhost:3000にアクセスするとページが表示されなくなりました。

f:id:hiyo-ac:20200208211456p:plain
pm2停止ログ

■おわりに

Windows環境で今回テストを行いましたが、CentOSなどのLinux環境だとpm2がそのまますんなり起動できるのか気になるところです。
どちらにせよ起動はできましたが、内部処理の挙動がわかっていないのでプロダクション環境にデプロイするのはまだ先になりそうです。
それまでは古典的ですがwindowsタスクスケジュールからプロセス監視の処理を流し続けます…

tSQLt のアサーションを紹介する

■はじめに

tSQLtについて引き続き勉強したことを記載していきます。
本記事ではtSQLtのアサーションについて紹介します。

■Assertions

tSQLtの公式ドキュメントに下記ページがあります。

tsqlt.org

このページではtSQLtが用意してるアサーションのストアドプロシージャと、
失敗のストアドプロシージャが記載されています。
シンタックスは公式ページを見てもらえればと思います。

AssertEmptyTable

AssertEmptyTableストアドプロシージャは、第一引数のテーブルが空かどうかをチェックします。
例ではビューの結果セットが空かどうかをチェックするコードが記載されています。

AssertEquals

AssertEqualsストアドプロシージャは、第一引数の値と、第二引数の値が一致しているかどうかをチェックします。
ドキュメントのページでは、オブジェクトの型も比較した例が記載されていてわかりやすいです。

AssertEqulasString

AssertEqualsStringストアドプロシージャは、第一引数と第二引数の文字列が一致しているかどうかをチェックします。
NullとNullではない文字列はエラーとなります。

AssertEqualsTable

AssertEqualsTableストアドプロシージャは、第一引数のテーブル名のテーブルと、第二引数のテーブル名のテーブルの中身を比較し同一の場合は成功となります。

AssertEqualsTableScheme

AssertEqualsTableSchemeストアドプロシージャは、第一引数のテーブル名のテーブルと、第二引数のテーブル名のテーブルのスキーマを比較し同一の場合は成功となります。
AssertEqualsTableはテーブルの中身を比較するのに対して、AssertEqualsTableSchemeはテーブルのスキーマを比較しています。

AssertLike

AssertLikeストアドプロシージャは、第一引数のパターンと、第二引数の値を比較し一致するパターンの場合は成功となります。

AssertNotEquals

AssertNotEqualsストアドプロシージャは、第一引数と第二引数の値が一致してない場合に成功します。

AssertObjectDoesNotExist

AssertObjectDoesNotExistストアドプロシージャは、第一引数のオブジェクトがない場合に成功します。

AssertObjectExists

AssertObjectExistsストアドプロシージャは、第一引数のオブジェクトが存在する場合に成功します。

Fail

Failストアドプロシージャは、実行された場合に失敗を返します。引数にエラーメッセージを記載することができます。

■おわりに

アサーションも多くの種類が用意されており、単体でテストの結果判定には十分なのではないかと思いました。
残りのExpectationsとIsolating dependenciesを学んだら実際の単体テストの例を記載できたらいいかなと思ってます。

tSQLtでテストケースの作成と実行を行う

■はじめに

ひとつ前の記事でtSQLtのインストールについて記載しました。
これからtSQLtの用意する処理を公式ドキュメントをもとに勉強します。

ひとつ前の記事

hiyo-ac.hatenablog.com

■Test Creation and Execution

tSQLtの公式ドキュメントに次のページがあります。このページについて本記事では紹介します。

tsqlt.org

このドキュメントのページではテストクラスを作成するとどうなるのか?と、テストクラスを実行するとどうなるのかが記載されています。

テストクラスを作成するとどうなるのか?

tSQLt.NewTestClassを用いてテストクラスを作成するとスキーマが作成されます。このスキーマを用いてテストクラスを識別して実行します。注意点はすでに同じスキーマがあった場合ははじめに削除してから作成されます。

テストクラスを実行するとどうなるのか?

  1. テストクラスのスキーマ名のすべてのストアドプロシージャを調べ、これらをテストケースとみなします。
  2. 各テストケースについて下記処理が実行されます。
    1. tSQLt.TestResultテーブルにテストケースが実行されていることを示すレコードが作成されます。
    2. トランザクションを開始します。
    3. テストクラスにSetUpという名前のストアドプロシージャがある場合は、SetUpストアドプロシージャを実行します。
    4. テストケースのストアドプロシージャを実行します。
    5. トランザクションロールバックします。
    6. tSQLt.TestResultのレコードをテストケースの実行結果をで更新します。
  3. すべてのテストケースが完了すると、コンソールに結果が表示されます。

テストケースの実行用のストアドプロシージャに、tSQLt,RunTestClassとtSQLt.RunAllの2種類があります。tSQLt.RunTestClassは引数のスキーマ名のテストクラスを実行します。tSQLt.RunAllはデータベース内のすべてのテストクラスを実行します。

■関連するストアドプロシージャ

ドキュメントサイトには下記ストアドプロシージャについて説明があります。シンタックスなどはドキュメントを参照いただくとし、簡単に概要を記載します。

DropClass

引数のスキーマ名のテストクラスを削除します。スキーマの中に存在するテストケース(ストアドプロシージャ)も削除されるので注意して実行するのをお勧めします。

NewTestClass

引数の名前のテストクラスのスキーマを作成します。すでに同名のスキーマが存在する場合は、存在するスキーマを削除したのち作成します。

RenameClass

第一引数のテストクラスを、第二引数のテストクラス名に変更を行います。テストクラス名を変更した場合は、変更対象のテストクラス内のストアドプロシージャのスキーマ名も変更になります。

Run

引数のテストクラスを実行します。tSQLt.RunTestClassとの違いは、tSQLt.Runの場合は第二引数にテスト結果のフォーマットを指定することができます。指定できるフォーマットは後ほど調べてわかったらコメントに記載したいと思います。

RunAll

データベース内のすべてのテストクラスを実行します。

■おわりに

導入しようとしているフレームワークがどのように動作するのかを把握するのは、非常に大事だと思っています。ブラックボックスのままだと、何か問題が起きた場合にどこが問題かわからないので、公式ドキュメントをもとに基本的な動作を学べました。次の記事もまた公式ドキュメントをもとに、アサーションについて記載していきたいと思います。

SQL Server用のテストフレームワークtSQLtのインストール

■はじめに

SQL Server上で動くモジュールの品質を高めるためのテストフレームワークにtSQLtというものがあると聞いたので勉強しました。
環境面での安定稼働は進めてきたので、今後はビジネスロジックにも手を伸ばして品質向上を進めていきたいと思っています。

■tSQLtとは

tSQLtはSQL Server用の単体テストフレームワークオープンソースです。下記サイトが公式サイトです。

tsqlt.org

SQL Server 2005 Service Pack 2エディション以降のすべてのエディションのSQL Serverとの互換性があるとのことです。SQL Server 2000を利用している人は…早く利用しなくする活動をしましょう…

■インストール方法

サイトからダウンロードしたzipファイルを解凍すると5つのファイルがあります。
それぞれ下記内容となっています。

  • Example.sql: サンプルのsqlファイルです。
  • Lincense.txt: ライセンス事項が記載されているファイルです。
  • ReleaseNotes.txt: リリースノートが記載されているファイルです。
  • SetClrEnabled.sql: tSQLtの実行で必要なclr enabledを有効にするクエリが記載されています。
  • tSQLt.class.sql: tSQLtの必要セットがインストールされるsqlファイルです。

まず、tSQLtを利用するには、SQL Server構成オプションのclr enabledが有効になっている必要があるため、必要に応じて、SetClrEnabled.sqlを実行します。SQL Server 2017ではclr strict securityというサーバ構成オプションも追加されており、SQL Server 2017の環境ではこのサーバ構成オプションを無効にする必要があります。

次にtSQLt.class.sqlを実行します。これでインストールは完了です。
初めて利用するので公式サイトに記載のQuick Startを実行してみます。

チュートリアル 1 FIX THE FAILING TEST

Quick Startに記載のチュートリアルに従い実行してみます。 ここでは、テスト用のDBを作成しテストケースの実行とバグフィクスを体験できます。

tsqlt.org

まずExample.sqlを実行します。このファイルを実行すると、tSQLt_ExampleというDBがインスタンス上に作成されます。このDB内にtSQLt.class.sqlの内容と同時にチュートリアル用の処理(スキーマがAcceleratorのオブジェクト)が作成されます。

tSQLtを実行してみます。

EXEC tSQLt.RunALL;

実行するとエラーメッセージが表示されます。

-- 抜粋
[AcceleratorTests].[test ready for experimentation if 2 particles] failed: Expected: <1> but was: <0>

内容はそのまま[AcceleratorTests].[test ready for experimentation if 2 particles]というストアドプロシージャで期待値と異なる値が返ってきたというものになります。
次に[AcceleratorTests].[test ready for experimentation if 2 particles]を見てみます。

ALTER PROCEDURE 
  AcceleratorTests.[test ready for experimentation if 2 particles]
AS
BEGIN
  --Assemble: Fake the Particle table to make sure 
  --          it is empty and has no constraints
  EXEC tSQLt.FakeTable 'Accelerator.Particle';
  INSERT INTO Accelerator.Particle (Id) VALUES (1);
  INSERT INTO Accelerator.Particle (Id) VALUES (2);
  
  DECLARE @Ready BIT;
  
  --Act: Call the IsExperimentReady function
  SELECT @Ready = Accelerator.IsExperimentReady();
  
  --Assert: Check that 1 is returned from IsExperimentReady
  EXEC tSQLt.AssertEquals 1, @Ready;
  
END;

中を見てみると、Accelerator.Particleテーブルに2行データを入れて、Accelerator.IsExperimentReady()という関数を実行しその結果が1と等しいか確認するテストケースです。Accelerator.IsExperimentReady関数を見てます。

CREATE FUNCTION Accelerator.IsExperimentReady()
RETURNS BIT
AS
BEGIN 
  DECLARE @NumParticles INT;
  
  SELECT @NumParticles = COUNT(1) FROM Accelerator.Particle;
  
  IF @NumParticles > 2
    RETURN 1;

  RETURN 0;
END;

この関数では、Accelerator.Particleの行数をカウントし、2を超える場合は1を返却し、2以下の場合は0を返すとなっています。テストケースを正とすると、この関数では2の場合に1を返却する想定となっており、「IF @NumParticles > 2」の判定式が誤りとわかります。そのためAcclerator.IsExperimentReady関数の判定式を 「IF @NumParticles >= 2」に修正を行います。

そして再度テストケースを実行してみます。

EXEC tSQLt.RunALL;

実行するとエラーメッセージの出力がなくなりました。

チュートリアル 2 WRITE YOUR OWN NEW TEST

こちらでは自分のテストケースを作成する方法が紹介されています。

まずテストクラスを作成します。

EXEC tSQLt.NewTestClass 'TryItOut';
GO

これを実行するとTryItOutという名前のテストクラスが作成されます。このテストクラス名をスキーマとし、テストケースを作成していきます。

必ず失敗が記録されるテストケースを1つ作ります。

CREATE PROCEDURE TryItOut.[test this causes a failure]
AS
BEGIN
    EXEC tSQLt.Fail 'This is what a failure looks like';
END;
GO

続いて成功のテストケースを1つ作成します。

CREATE PROCEDURE TryItOut.[test this one passes]
AS
BEGIN
    DECLARE @sum INT;
    SELECT @sum = 1 + 2;

    EXEC tSQLt.AssertEquals 3, @sum;
END

テストを実行してみます。

EXEC tSQLt.RunAll;
GO

実行結果は下記のようになります。

[TryItOut].[test this causes a failure] failed: This is what a failure looks like

+---------------------+
|Test Execution Sumary|
+---------------------+

|No|Test Case Name                         |Result |
+--+---------------------------------------+-------+
|1 |[TryItOut].[test this one passes]      |Success|
|2 |[TryItOut].[test this causes a failure]|Failure|
-----------------------------------------------------------------------------
Msg 50000, Level 16, State 10, Line 1
Test Case Summary: 2 test case(s) executed, 1 succeeded, 1 failed, 0 errored.
-----------------------------------------------------------------------------

TryItOutスキーマ配下のテスト用のストアドプロシージャが2つ実行されたことが確認できます。

最後にテストケースを削除します。

EXEC tSQLt.DropClass 'TryItOut';
GO

先ほど作成した2つのストアドプロシージャが削除されていることが確認できました。

■おわりに

まずはtSQLtを使うにはどうやったらいいかというところで、tSQLtのインストールとチュートリアルを記載しました。次回はtSQLtが用意している関数などを見ていきたいと思います。

SQL Serverのsp_whoisactiveについて

■はじめに

SQL Serverで実行しているクエリを調査するときにsp_whoやsp_who2など利用することがあると思いますが、海外ではsp_WhoIsActiveが有名だと聞いたので勉強してみました。

■sp_WhoIsActiveとは

sp_whoやsp_who2、DMVなどSQL Serverが提供されている調査情報を一括で取得する機能を持った調査用のストアドプロシージャのようです。SQL Serverが提供されている機能だと、sys.dm_exec_requestをみて、sys.db_dm_os_wait_statsをみてといったように複数の動的管理ビューの情報を個別に調査して分析を行う必要があります。sp_whoisactiveを利用すれば一括で必要な情報を取得することができます。

ソースコードは下記にあります。

github.com

また、ドキュメントは下記になります。

whoisactive.com

ドキュメントの中にはインストール方法や設計概念などいろいろ記載があるので、見ていただけたらどんなものかわかるのではないかと思います。その中からいくつかピックアップして学んだことを記載していきます。

■インストール方法

githubからwho_is_active.sqlをダウンロードして実行します。このクエリを実行すると、dbo.sp_WhoIsActiveという名前のストアドプロシージャが作成されます。
どのデータベースに作成するか?ですが、ドキュメントにもありますがデータベース特有の機能ではなく、サーバ全体の状況を把握するもののため、masterに作成するのが良いのではないかと思います。
また、実行するにはview server state権限が必要になります。sp_whoisactiveを実行したアカウントで権限がなかったら追加してください。

■実行パラメータ

sp_whoisactiveは24のパラメータで取得したい情報を細かく制御することができます。すべての状況を俯瞰してみるよりは見たい情報を抽出してみるべきという概念で作成されているとのことです。
例えばいくつかのパラメータを見てます。パラメータの制御内容はwho_is_active.sqlに記載されています。

   --Controls how sleeping SPIDs are handled, based on the idea of levels of interest
    --0 does not pull any sleeping SPIDs
    --1 pulls only those sleeping SPIDs that also have an open transaction
    --2 pulls all sleeping SPIDs
    @show_sleeping_spids TINYINT = 1,

この@show_sleeping_spidsではデフォルトが1となっており、1だとトランザクションを開いていればsleepingの状態のトランザクションも表示する設定になります。すべてのsleeping中のspidを表示したければ2に設定すれば表示することができるようになります。

    --Get associated query plans for running tasks, if available
    --If @get_plans = 1, gets the plan based on the request's statement offset
    --If @get_plans = 2, gets the entire plan based on the request's plan_handle
    @get_plans TINYINT = 0,

また、@get_plansでは、1を設定するとクエリの実行プランを取得することができます。
他にも多くのパラメータがあるので、検証を行いながら必要な情報を取得するお気に入りのパラメータが見つかるのではないかと思います。全部の情報を取得しようとすると分析も大変になってしまうので、発生している事象と調査項目は分けておくとよいと思います。

■おわりに

普段問題なくサーバが動作しているとこのような調査は不要です。ただし、時々トラブルが発生する場合があり調査の知見を必要とすることがあります。そういったときに調査方法などを事前に整理/訓練しておくことはとても重要なので、今回のsp_whoisactiveを有事の際にすぐに利用できるように検証機で検証作業を進めていきたいと思います。

SQL Serverの仮想ログファイル(VLF)の数が多くなりすぎたときの対応

■はじめに

いままでSQL Serverを運用してて気が付かなったことに先日気が付いたので記事にまとめたいと思います。 ログファイルの容量などはいままで監視していたのですが、仮想ログファイル(VLF)の数が多すぎるという見たことがないアラートを検知したので何だろうと調べました。

■仮想ログファイル(VLF)とは

単語だけで調べるとマイクロソフト社の下記ページがヒットします。

docs.microsoft.com

仮想ログファイル(VLF)とは、上記サイトの中ほどにある「トランザクション ログの物理アーキテクチャ」に記載されていました。

  • 物理ファイルは内部的に多くの仮想ログファイル(VLF)に分割されていること
  • ログファイルの作成時や拡張時にデータベースエンジンにより動的に選択されること
  • 管理者が仮想ログファイルのサイズや数を構成または設定できない

という性質のファイルです。注意には仮想ログファイルの数の増え方が記載されています。これをみると自動拡張サイズが1MBなどの初期の自動拡張サイズにしたまま、自動拡張をさせ続けると仮想ログファイル数が尋常じゃない数になりそうです。さらに注意点としては

このような状況では、データベースの起動、ログのバックアップ操作、およびログの復元操作の速度が低下する場合があります。

と記載されていることは新発見でした。普段常に動かし続けているうえでは、定期的なログのバックアップは必須なため対策が必要と感じました。

■仮想ログファイル数の減らし方

下記サイトが参考になります。

blogs.msdn.microsoft.com

ページ中ほどにある「対処」に対応方法が記載されています。
簡単にまとめると、

  1. ログファイルをシュリンクして圧縮する。
  2. 適切なファイルサイズまで明示的に拡張する。

となります。試しにアラートが出ていたデータベースに対して対処をやってみたところ、確かにファイル数が激減したことを確認しました。仮想ログファイルの数が尋常じゃないデータベースは、自動拡張のサイズも規定値(1MBの自動拡張サイズ)だったりするので、今後同様のことが発生しないよう自動拡張ファイルのサイズも変更しておくとよいです。

トランザクションログの自動拡張サイズについての、マイクロソフト社のベストプラクティスは、1,024MB以下とすることなのでそれ以上にせず丁度良い時間に設定するのがよいです。具体的にどのようなサイズに設定すればよいかは次のスクリプトを実行すると結果が返ってきますので参考にしてみてはいかがでしょうか。

github.com

■終わりに

いままで見ていないアラートを検知したので調査してみました。これ以外にも実は見ないといけない項目が潜んでいそうなので継続的に勉強しなきゃいけないなと感じました。

SQL Server 2017の新機能のダイジェストを見てみる

■はじめに

SQL Server 2008 R2のEOSL対応で、SQL Server 2017にアップグレードするので、
自習書のダイジェストをもとに2012からの新機能を勉強します。
SQL Server 2016は前回記事作ったので、SQL Server 2017の新機能を見てます。

hiyo-ac.hatenablog.com

www.microsoft.com 上記リンクから、「SQL Server 2017 の自習書シリーズ No.1」をもとにしました。

下記の番号は自習書の目次の番号に合わせ、私の個人的なメモを記載します。

2.1 Dockerを利用したSQL Server on Linux

Dockerイメージで提供されているとのことで、簡単にLinux環境で動作できるようになったとのことです。
簡単に起動できるので便利ですね。

2.2 Linux環境へのSQL Server 2017のインストール

Dockerではなく直接Linux環境にインストールできるとのことです。

2.3 SQL Server 2017 on Linuxのセキュリティ

Windows版と同様のセキュリティ機能が利用できるとのこと。
OSレイヤーの層とMWレイヤーのAPI等を分けてあれば、依存せずに動くのでしょうか。

2.4 SQL Server 2017 on Linuxで利用できる機能/利用できない機能

Linuxを利用せざるをえない状況になったら詳しく勉強します。

3.1 Machine Learning Servicesの概要/インストール方法

以前はRをサポートしていましたが、今度はPythonができるようになったとのことでした。

4.1 グラフデータベース(Graph Database)

グラフデータベースを利用できるようになったとのことでした。
ただグラフデータベースの設計って難しそうです。

4.2 自動チューニング(Automatic Tuning)

クエリストアの履歴を用いて自動で実行プランを選択する機能とのことでした。
使い方によってはとても便利そうな機能です。

4.3 Adaptive Query Processing(適応型クエリ処理)

列ストアインデックスを利用しており、おかつ互換性レベル140の場合に利用できる機能とのことで、
性能向上した実行プランが動作できる処理のようです。適応型Joinというイテレータが実行プランに登場したらこの機能のようです。

4.4 データベースの互換性レベル140

SQL Server 2017では互換性レベル140が登場したとのことです。

4.5 クエリストア機能の強化(クエリのWait情報の記録)

クエリストアでWait情報を記録することができるようになったとのことで、原因特定が早く行えそうですね。

4.6 データベースエンジンチューニングアドバイザーの強化

いままでインデックスを作成するとコストが減るよというアドバイスを提案してくれていましたが、
列ストアインデックスなどもチェックしてくれるようになったとのことでした。

4.7 列ストアインデックスの強化

SQL Server 2017では非クラスター化列ストアインデックスはオンライン再構築ができるようになったとのことで、メンテナンス性が大きく向上したそうです。

4.8 インメモリ OLTP機能の強化

インメモリOLTPの機能がもろもろ強化されているようです。メモリで処理する時代になりつつある感じがします。

4.9 再開可能なオンラインインデックス再構築

これは個人的には待望の機能です。オンラインインデックス再構築をしているときに、長走して停止しなけばならないということがあり、結局オフラインインデックス再構築をしているということがありました。
利用するには、WITHオプションで RESUMABLE=ONを指定すればよいとのことです。
進行状況を見れたりできるのも嬉しいですね。

4.10 AlwaysOn 可用性グループの強化

DTCのサポートや非クラスター環境下での可用性グループ構築ができるようになったとのことでした。

5.1 Transact-SQLの強化

新しい関数の追加などがされているとのことです。個人的には一括操作でのFORMAT=CSVによるCSVファイルの取り込みのサポートが便利そうでした。

5.2 セットアップ時の変更点(tempdbファイルの設定)

インストール時のtempdb設定で設定ファイルサイズなどが変更になっているとのことでした。
気にしたことなかったのですが便利なのかもしれないです。

5.3 スマートバックアップ

これは個人的には奇怪な機能です。
運用設計時にいつの時点まで復旧できるのか決めて、バックアップスケジュール作成すると思うのですが…
たとえ効率が良くても、そのスケジュールが動的に変わってしまうと困惑が生まれそうです。

5.4 新しいDMV(動的管理ビュー)

多くの動的管理ビューが強化、登場しているようです。
動的管理ビューも勉強しないといけないですね…

■おわりに

SQL Server 2017の目玉はLinux対応とは聞いていました。ただ、他にもいろいろな機能が追加されているようで勉強になりました。