リストア時に対象DBへのアクセスを強制的に落とす

Slave側のDBをログシッピングのStandbyモードで動かしている場合、
SSMSのユーザーセッションが残っているとリストアが失敗する事がある。

会社のとあるシステムでは、15分毎にLSCOPYを行い、深夜に1回、LSRESTOREジョブが動いているが、その良く失敗する。
酷い時は週5回は失敗して、「データが更新されてない!」と利用部門からクレームが来て手動でジョブを実行していた。

接続を切って帰ってくれればいいのだが、何度言ってもダメなので、
LSRESTOREジョブにステップを追加して、当該DBへのアクセスを全てkillする事にした。

その時に動いている処理があるのかもしれないが、ムシャクシャして書いた。

SET NOCOUNT ON
CREATE TABLE #sp_who (
    spid smallint
    ,ecid smallint
    ,status nchar(30)
    ,loginame nchar(128)
    ,hostname nchar(128)
    ,blk char(5)
    ,dbname nchar(128)
    ,cmd nchar(16)
    ,request_id int)


INSERT INTO #sp_who EXEC sp_who


DECLARE CUR_SPID CURSOR FOR  select spid from #sp_who where dbname = 'DB名'

DECLARE @SPID nchar(5)

OPEN CUR_SPID

FETCH NEXT FROM CUR_SPID INTO @SPID

WHILE (@@FETCH_STATUS = 0)
 
BEGIN
    DECLARE @command nchar(128)
	SET @command = N'kill ' + @SPID

    EXEC sp_executesql @command

    FETCH NEXT FROM CUR_SPID INTO @SPID

END

CLOSE CUR_SPID
DEALLOCATE CUR_SPID
DROP TABLE #sp_who

これで、翌朝にドタバタ&イライラしなくても済みそう。

一時テーブルにストアド結果を入れる

SQLServerで一時テーブルの作成とストアド結果をINSERTするやり方。
いつも忘れてしまうからメモ。

CREATE TABLE #sp_who (
    spid smallint
    ,ecid smallint
    ,status nchar(30)
    ,loginame nchar(128)
    ,hostname nchar(128)
    ,blk char(5)
    ,dbname nchar(128)
    ,cmd nchar(16)
    ,request_id int)


INSERT INTO #sp_who EXEC sp_who

select * from #sp_who

DROP TABLE #sp_who

dirnameが無い!?

centosでdirnameを実行すると、そんなコマンド無いよ!と怒られたのでメモ
※他のメンバーがOSインストールしたんだけど、baseだけしか入れてないのかな?

# dirname
dirname: missing operand
詳しくは `dirname –help’ を実行して下さい.

yum -y install coreutils.x86_64

SQLServer on Linuxを触ってみる

先週、SQLServer on Linuxのpublic Public Previewが開始されたので、さっそく触ってみた。

[環境]
VirtualBOX上の CentOS7
CPU :2コア
メモリ: 4096MB ※3250MB以下は、インストール時にエラーが出ます。

インストールは、公開されているリポジトリを追加してyumコマンド叩くだけ!
非常に簡単!

# リポジトリ追加
curl https://packages.microsoft.com/config/rhel/7/mssql-server.repo > /etc/yum.repos.d/mssql-server.repo
curl https://packages.microsoft.com/config/rhel/7/prod.repo > /etc/yum.repos.d/msprod.repo

# インストール
yum -y install mssql-server mssql-tools

# 途中、ライセンス確認のチェックが入るので、大文字でYESと入力
Do you accept the license terms? (Enter YES or NO) YES

インストールPATHは/opt配下。

ls -1 /opt/
microsoft   → odbcドライバ
mssql       → SQLServer
mssql-tools → bcpとsqlcmd

続いて、初期セットアップを行う。

/opt/mssql/bin/sqlservr-setup
(中略)
Setting system administrator (SA) account password...

Do you wish to start the SQL Server service now? [y/n]: y
Do you wish to enable SQL Server to start on boot? [y/n]: y
Created symlink from /etc/systemd/system/multi-user.target.wants/mssql-server.service to /usr/lib/systemd/system/mssql-server.service.
Created symlink from /etc/systemd/system/multi-user.target.wants/mssql-server-telemetry.service to /usr/lib/systemd/system/mssql-server-telemetry.service.

Setup completed successfully.

セットアップスクリプトが動いたっぽい。

プロセスも動いている!
mssql 2257 1 2 18:37 ? 00:00:00 /opt/mssql/bin/sqlservr
mssql 2263 1 0 18:37 ? 00:00:00 /opt/mssql/bin/sqlservr-telemetry /var/opt/mssql/.system
mssql 2270 2257 43 18:37 ? 00:00:04 /opt/mssql/bin/sqlservr

ポートも空いている!
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:1433 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:1434 0.0.0.0:* LISTEN
tcp6 0 0 :::22 :::* LISTEN

最後にSSMSで接続してみます。
sqlserver_on_linux
当然、Windows認証は使えませんが、セットアップ時に決めたSAのパスワードで接続する事が出来ました。

Versionは、
Microsoft SQL Server vNext (CTP1) – 14.0.1.246 (X64) Nov 1 2016 23:24:39 Copyright (c) Microsoft Corporation on Linux (CentOS Linux 7 (Core))

と出ているので、インストール自体は成功したようです。

powershellでCPU情報を取得するアレコレ

# cpu情報を表示
Get-WmiObject -Class Win32_Processor

# 物理コア数を表示
Get-WmiObject -Class Win32_Processor | Format-List NumberOfCores

# 論理コア数を表示(THH)
Get-WmiObject -Class Win32_Processor | Format-List NumberOfLogicalProcessors

と、色々と調べたけど、

Get-WmiObject -Class Win32_Processor | Format-List NumberOfCores, NumberOfLogicalProcessor

が一番すっきりする

SQL Server から AWS Auroraにマイグレーションする時の注意事項

オンプレ環境のSQL Server開発機からAWS Auroraにマイグレーションした際、DMS(Database Migration Service)を使って見たので、ハマった処をメモ。
https://aws.amazon.com/jp/dms/

eyecatch_dms-200x200
※仕様をよく読んだら書いてあるのかもしれない。

【移設方法】
オンプレのSQLServerは、DMSからアクセスが出来ないネットワークにある為、セキュリティを弄らずに移設をする方法を考えました。
結果的に、[開発機] – [RDS for SQL Server] – [DMS] – [RDS for Aurora]
と余計なSQLServerを挟んでいます。

20161108_1

【移行時の注意点】
・DMSはスキーマ単位になりますが、Auroraはスキーマの概念がありません。
 SQLServerで
 [db_name1].[dbo].[table_name]
 [db_name2].[dbo].[table_name]
 は別テーブルとして扱われますが、Auroraでは[dbo].[table_name]と単一になります。

 その為、事前にスキーマを[ALTER SCHEMA db_name1 TRANSFER dbo.table_name]等のコマンドで変更しておく必要があります。
 対象は、一般テーブル、システムテーブルです

 また、ストアドもスキーマを変更する必要があります。
 こちらは変更のコマンドが解らなかったので、SSMSでストアドのCreate文作成 → dboの部分をdb_nameに変更して新規作成を行いました。

・LOBサイズ
 DMSのLOBサイズの上限は、デフォルトで24KBになっています。
 大きめのデータが格納されている場合、この上限に引っかかる場合がありますので、適時変更を行ってください。
 分からなくても、1024KBぐらいあれば十分かと。

・移行元がSQLServerの場合、継続的なレプリケートが出来ない。
 DMSの強みである継続的レプリケート。
 これにより、大容量のデータベースでもダウンタイムを低減させる事が出来ます。
 が、現時点でSQLServerからAuroraへは、レプリケートが行いません。

・IDENTITIYはAutoIncrimentにならない
・datetimeoffset(7) → varchar(34)
この辺はエンジンの違いが出てきます。

追加のデータが入らないうちに、Alter Tableで変更しておきましょう。

コマンドからWindowsFilewallを操作する

上手く動かねないじゃん!と思ってググった備忘録

一般的な事かもしれないけど、書き方のルールは以下の通り

  1. rule= や name=はダブルクォテーションで囲う
  2. profile=で複数プロファイルを指定する時もダブルクォテーションで囲う
  3. 既存のルールには同じ名前でプロファイルが異なる物が多い。
  4. その場合は設定変更の場合は、対象をユニークになるように指定する必要がある。
    netsh advfirewall firewall show rule name=”Windows リモート管理 (HTTP 受信)” dir=in
    → 2つある
    netsh advfirewall firewall show rule name=”Windows リモート管理 (HTTP 受信)” dir=in profile=”domain,private”
    → ユニーク
    netsh advfirewall firewall show rule name=”Windows リモート管理 (HTTP 受信)” dir=in profile=”pblic”
    → ユニーク

  5. 変更の場合は、set name=<対象の名前> <対象をユニークにする条件> new <変更後の設定> と書く
  6. netsh advfirewall firewall set rule name=”Windows リモート管理 (HTTP 受信)” dir=in profile=”domain,private” new profile=any

SQL Server 2016 StandardのAlwaysONを試す

今までEnterprise版でのみ利用可能だったSQLServerのAlwaysONについて2016から一定の制限はありますが、高可用性グループの作成が出来るようになりましたので早速構築してみました。

【制限】
・1つの高可用性データベースに所属できるスキーマは1つのみ

複数のリスナーは作成は出来るが、Masterを片寄出来ないのが難点。
もちろんjoin句も利用出来ないのでアプリケーション側で結合するか、Linkサーバーとやらを使うしかない(?)

サーバーA:

  • リスナー 192.168.x.10 データベース名1(Primary) 
  • リスナー 192.168.x.11 データベース名2(Replica)

    サーバーB:

  • リスナー 192.168.x.10 データベース名1(Replica) 
  • リスナー 192.168.x.11 データベース名1(Primary)

    構築方法は、SQLServer2012と基本的に同じ。
    ただし、SSMSの日本語ローカライズ版はにはバグがあり、現時点では以下の事が出来ません。

  • 対象DBの完全同期(ウィザードからフルバックアップ、リストア)が出来ない。
  • レプリカサーバーがAGに自動参加しない
  • レプリカサーバーにNORECOVERYでリストアし、可用性DBに参加させようとすると、データ差異があると言われて可用性データベースに参加できない。

    20161017_1

    マイクロソフトに確認したが、修正リクエスト中でいつ直るか解らないとの事だったので、英語版のSSMSを使って構築するとすんなり行く。

  • シングルクォート内で変数を展開する

    T-SQLで、シングルクォート内で変数を展開するに上手いやり方が解らない・・・
    例えば以下のようなクエリ。

    DECLARE @d nvarchar(50)
    DECLARE @cmd nvarchar(100)
    
    SET @d = N'C:\database\backup'
    SET @cmd = N'dir ' + @d + ' /b'
    exec master..xp_cmdshell @cmd
    

    効率悪いと思うけど、1時間ほどググってこれで落ち着いたが正しいのかな?
    個人的には、以下のように書きたい。書いたらスッキリすると思う。

    DECLARE @d nvarchar(50)
    SET @d = N'C:\database\backup'
    exec master..xp_cmdshell 'dir @{d} /b'
    -- とか
    exec master..xp_cmdshell '''dir' + @d + ' /b'''
    

    パフォーマンスカウンタのネットワークのスケール

    スケール調整の覚書

    グラフ枠のプロパティ/グラフ/垂直スケール の最大値を100から1000に上げる

    NetworkInterface/NIC名/Bytes Sent/sec
     ・・・ GigaNicを積んでいる場合、スケールは0.00001 でxxxMB/s
         ※グラフ赤線

    NetworkInterface/NIC名/Packet Sent/sec
     ・・・ GigaNicを積んでいる場合、スケールは0.001 でxxxMbps
         ※グラフ黄緑線

    perfmon_20160913