====== MS SQLServer ======
===== 名前付きインスタンス で複数のDBを動かしている場合 =====

Listen portは動的に割り当てられる
また、固定することも可能
その場合、portはインスタンス毎に変える必要ある

===== 通信の暗号化 =====
「Force Encryption」オプションを「Yes」に設定すると、すべてのデータ通信が暗号化される
SQL Serverとクライアントアプリケーション間のすべての通信が自己署名証明書を使用して暗号化される((クライアントも対応必要))

設定が有効になっているかどうかを確認するには、以下のSQLコマンドでできるらしい

<code sql>
SELECT session_id, connect_time, net_transport, encrypt_option, auth_scheme, client_net_address FROM sys.dm_exec_connections
</code>

===== バックアップ セットは、既存のデータベース ‘%ls’ 以外のデータベースのバックアップを保持しています  =====

バックアップからリストアするときに表示される\\
webなどでは
  * 「既存のデータベースを上書きする」チェックを入れる
  * mdf,ldfファイルのパスが間違ってる
などがあるが、それでも解消できなかった場合、以下のSQLでリストアできた


<code sql>
RESTORE DATABASE kingdb -- 復元対象DB
FROM DISK = 'D:/DATA/kingdb.bak'
with replace,
MOVE 'test1' TO 'D:/DATA/test1.mdf', -- 復元対象DB名を変更する可能性がある
MOVE 'test1_log' TO 'D:/DATA/test1_log.ldf' -- 復元対象DB名を変更する可能性がある
</code>


===== SQL Server のデータベースユーザーを削除しようとしたら「スキーマを所有しているので削除できません」 =====

これは、いずれかのスキーマを所有しているため削除できませんという意味です。

  * そのユーザでテーブルを作成した
  * そのユーザでViewを作成した
  * 権限スキーマの所有者になってる

等の原因が考えられます。解決法としては以下のようなものになります

----

　

<code sql>
-- いったん、ユーザーと、そのユーザー名と同名のスキーマを明示的に関連付け、
ALTER USER ユーザ名 WITH DEFAULT_SCHEMA = ユーザ名
-- そのスキーマを明示的に削除してから、
DROP SCHEMA ユーザ名
-- ユーザーを削除。
DROP USER ユーザ名
GO
</code>


----
　
  - データベース→スキーマ→db_owner((等))の所有者を確認
  - 該当ユーザが所有者にになっていたら、ほかの所有者に変更
  - たぶんこれで削除できるはず

==== 原因 ====
SQL Server 2012以前では、SQL Serverのデータベースエンジンのインスタンス間でデータベースを移行または復旧すると、データベースユーザーに関連付けられたサーバログインは、移行先／復旧先のインスタンスに自動でコピーされない。\\
そのため、孤立したユーザーが生まれ、移行直後のデータベースは機能しない。