[code]
# cpu情報を表示
Get-WmiObject -Class Win32_Processor
# 物理コア数を表示
Get-WmiObject -Class Win32_Processor | Format-List NumberOfCores
# 論理コア数を表示（THH）
Get-WmiObject -Class Win32_Processor | Format-List NumberOfLogicalProcessors
[/code]
と、色々と調べたけど、
[code]
Get-WmiObject -Class Win32_Processor | Format-List NumberOfCores, NumberOfLogicalProcessor
[/code]
が一番すっきりする
オンプレ環境のSQL Server開発機からAWS Auroraにマイグレーションした際、DMS（Database Migration Service）を使って見たので、ハマった処をメモ。
https://aws.amazon.com/jp/dms/
※仕様をよく読んだら書いてあるのかもしれない。
【移設方法】
オンプレのSQLServerは、DMSからアクセスが出来ないネットワークにある為、セキュリティを弄らずに移設をする方法を考えました。
結果的に、[開発機] – [RDS for SQL Server] – [DMS] – [RDS for Aurora]
と余計なSQLServerを挟んでいます。
【移行時の注意点】
・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で変更しておきましょう。
上手く動かねないじゃん！と思ってググった備忘録
一般的な事かもしれないけど、書き方のルールは以下の通り
その場合は設定変更の場合は、対象をユニークになるように指定する必要がある。
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”
→ ユニーク
netsh advfirewall firewall set rule name=”Windows リモート管理 (HTTP 受信)” dir=in profile=”domain,private” new profile=any
今までEnterprise版でのみ利用可能だったSQLServerのAlwaysONについて2016から一定の制限はありますが、高可用性グループの作成が出来るようになりましたので早速構築してみました。
【制限】
・1つの高可用性データベースに所属できるスキーマは1つのみ
複数のリスナーは作成は出来るが、Masterを片寄出来ないのが難点。
もちろんjoin句も利用出来ないのでアプリケーション側で結合するか、Linkサーバーとやらを使うしかない（？）
サーバーA：
サーバーB：
構築方法は、SQLServer2012と基本的に同じ。
ただし、SSMSの日本語ローカライズ版はにはバグがあり、現時点では以下の事が出来ません。
マイクロソフトに確認したが、修正リクエスト中でいつ直るか解らないとの事だったので、英語版のSSMSを使って構築するとすんなり行く。
T-SQLで、シングルクォート内で変数を展開するに上手いやり方が解らない・・・
例えば以下のようなクエリ。
[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
[/sql]
効率悪いと思うけど、1時間ほどググってこれで落ち着いたが正しいのかな？
個人的には、以下のように書きたい。書いたらスッキリすると思う。
[sql]
DECLARE @d nvarchar(50)
SET @d = N’C:\database\backup’
exec master..xp_cmdshell ‘dir @{d} /b’
— とか
exec master..xp_cmdshell ”’dir’ + @d + ‘ /b”’
[/sql]
スケール調整の覚書
グラフ枠のプロパティ/グラフ/垂直スケール の最大値を100から1000に上げる
NetworkInterface/NIC名/Bytes Sent/sec
・・・ GigaNicを積んでいる場合、スケールは0.00001 でxxxMB/s
※グラフ赤線
NetworkInterface/NIC名/Packet Sent/sec
・・・ GigaNicを積んでいる場合、スケールは0.001 でxxxMbps
※グラフ黄緑線
先日、AWSのRDS for SQLServerのフルバックアップがS3のバケット上に置けるようになったので、触ってみる。
現時点ではトランザクションログバックアップが出来ないが、S3を使うことによりオンプレ環境から取得したフルバックアップのリストアや、解析用にフルバックアップを別サーバーにリストアするなど、
利用用途が増える。
参考：
Amazon RDS for SQL Server – Amazon S3 でネイティブバックアップと復元をサポート
Importing and Exporting SQL Server Databases
事前準備：
リンク先に記載の通り、S3のバケット作成とIAMロールの作成を行う。
S3のバケット作成とIAMロールの作成は、RDSのオプショングループの作成画面からも行える。
ちなみに、default:sqlserver-xx グループには、オプションを追加することが出来ないので新規でオプショングループを準備する。
作成したオプショングループをインスタンスに割り当て、インスタンスの再起動を行うとRDS for SQLServerからS3へのアクセスが可能になる。
S3操作：
S3への操作は、AWSが準備したストアドプロシージャを実行する。
【フルバックアップ取得】
[sql]
exec msdb.dbo.rds_backup_database
@source_db_name=’DBスキーマ名’,
@s3_arn_to_backup_to=’arn:aws:s3:::S3バケット名/ファイル名.bk’,
@overwrite_S3_backup_file=1;
[/sql]
【DBリストア】
[sql]
exec msdb.dbo.rds_restore_database
@restore_db_name=’DBスキーマ名’,
@s3_arn_to_restore_from=’arn:aws:s3:::S3バケット名/ファイル名.bk’;
[/sql]
【タスク状態確認】
[sql]
exec msdb.dbo.rds_task_status @db_name=’DBスキーマ名’
[/sql]
RDS for SQLServerではメンテナンスプランが使えない為、以下のような処理をエージェントジョブで回すとフルバックアップ取得の代わりになる。
※保持期間を過ぎたバックアップファイルの削除を、lambdaなりAWSCLIなりで行う事。
[sql]
USE msdb
declare @Backet nvarchar(20)
declare @DATE nvarchar(10)
declare @DBNAME nvarchar(30)
declare @BackupFile nvarchar(50)
SET @Backet = ‘s3バケット名’
SET @DATE = (SELECT CONVERT(date, getdate()))
–データベース一覧を取得(master(ID=1),tempdb(ID=2),model(ID=3),msdb(ID=4) 以上)
DECLARE C1_DBNAME CURSOR FOR
SELECT NAME FROM SYS.DATABASES WHERE DATABASE_ID > ‘5’
OPEN C1_DBNAME
FETCH NEXT FROM C1_DBNAME INTO @DBNAME
WHILE (@@FETCH_STATUS = 0)
BEGIN
SET @BackupFile = N’arn:aws:s3:::’ + @Backet + ‘/’ + @DBNAME + ‘_’ + @DATE + ‘.bak’
IF @BackupFile IS NOT NULL
exec msdb.dbo.rds_backup_database
@source_db_name = @DBNAME,
@s3_arn_to_backup_to = @BackupFile,
@overwrite_S3_backup_file = 1;
FETCH NEXT FROM C1_DBNAME INTO @DBNAME
END
CLOSE C1_DBNAME
DEALLOCATE C1_DBNAME
GO
[/sql]
新規にwindows2012サーバーを準備し、WindowsでポリシーベースのQOSを使ってS3へのアップロードスピードを帯域制御する方法をトレースしてみた。
QoSの設定はこの通りだが、「出力方向のスロットル率を指定する」には注意が必要。
検証では200MBbpsに設定を行ったが、物理1Gの回線環境で800MBps以上トラフィックが流れてしまう。
MSに問い合わせをして調査、検証を行った結果、
windows2012のインストール時点のQoSのバグっぽい事まで突き止める。
（Windowsアップデートしたら動きが改善されているので、どこかでパッチが当たった模様）
Windowsアップデート前： 制限の設定値の10倍が実際の制限値となる。
・ QoSを200MBps（204800 KBps）に制限 → トラフィックが200MBps以上
・ QoSを 20MBps（20480 KBｐｓ） に制限 → トラフィックは200MBps以下になる
Windowsアップデート後： 制限の設定値と同じ値が実際の制限値となる。
・ QoSを200MBps（204800 KBps）に制限 → トラフィックが200MBps以下になる
MSからKB番号の返答が来たら追記します。
覚書
以下のファイルを、ConfigurationFile.iniという名前で保存する。
[code]
;SQL Server 2012 Configuration File
[OPTIONS]
; INSTALL、UNINSTALL、UPGRADE などのセットアップ ワークフローを指定します。これは必須のパラメーターです。
ACTION="Install"
IACCEPTSQLSERVERLICENSETERMS="True"
; コマンド ライン引数 ENU の詳細なヘルプが定義されていません。
ENU="False"
; ユーザー インターフェイスの動作を制御するパラメーターです。
; 有効な値は Normal (完全な UI の場合)、AutoAdvance (簡易 UI の場合)、および EnableUIOnServerCore (GUI ブロックをバイパスする Server Core セットアップの場合) です。
; UIMODE="NOMAL"
; ユーザー インターフェイスは表示されません。
QUIET="False"
; ユーザー操作はなく、進行状況だけが表示されます。
QUIETSIMPLE="True"
; SQL Server セットアップで更新プログラムを検出して含める必要があるかどうかを指定します。
; 有効な値は、True と False または 1 と 0 です。既定では、SQL Server セットアップには、検出された更新プログラムが含まれます。
UpdateEnabled="True"
; インストール、アンインストール、またはアップグレードを行う機能を指定します。
; 最上位の機能には、SQL、AS、RS、IS、MDS、ツールなどがあります。
; SQL 機能では、データベース エンジン、レプリケーション、フルテキスト、および Data Quality Services (DQS) サーバーがインストールされます。
; ツール機能では、管理ツール、オンライン ブック コンポーネント、SQL Server Data Tools、その他の共有コンポーネントがインストールされます。
FEATURES=SQLENGINE,BIDS,CONN,BC,SDK,SSMS,ADV_SSMS,SNAC_SDK
; SQL Server セットアップが更新プログラムを取得する場所を指定します。
; 有効な値は、"MU" (Microsoft Update を検索)、有効なフォルダー パス、.\MyUpdates のような相対パス、または UNC 共有です。
; 既定では、SQL Server セットアップは Microsoft Update を検索するか、Window Server Update Services を通じて Windows Update サービスを検索します。
UpdateSource="MU"
; コマンド ライン パラメーターの使用方法を表示します
HELP="False"
; 詳細なセットアップ ログをコンソールにパイプすることを指定します。
INDICATEPROGRESS="False"
; セットアップで WOW64 にインストールするよう指定します。このコマンド ライン引数は、IA64 や 32 ビット システム上ではサポートされません。
X86="False"
; 共有コンポーネントのルート インストール ディレクトリを指定します。このディレクトリは、共有コンポーネントのインストール後は変更されません。
INSTALLSHAREDDIR="C:\Program Files\Microsoft SQL Server"
; WOW64 共有コンポーネントのルート インストール ディレクトリを指定します。このディレクトリは、WOW64 共有コンポーネントのインストール後は変更されません。
INSTALLSHAREDWOWDIR="C:\Program Files (x86)\Microsoft SQL Server"
; 既定のインスタンスまたは名前付きインスタンスを指定します。既定のインスタンスは、Express 以外のエディションの場合は MSSQLSERVER、Express エディションの場合は SQLExpress です。SQL Server データベース エンジン (SQL)、Analysis Services (AS)、または Reporting Services (RS) のインストール時には、このパラメーターが必須です。
INSTANCENAME="MSSQLSERVER"
; 指定した SQL Server 機能のインスタンス ID を指定してください。SQL Server のディレクトリ構造、レジストリ構造、およびサービス名には、SQL Server インスタンスのインスタンス ID が組み込まれます。
INSTANCEID="MSSQLSERVER"
; SQL Server 機能の使用状況データを収集して Microsoft へ送信できるようにするかどうかを指定します。この機能を有効にするには 1 または True を指定し、無効にするには 0 または False を指定します。
SQMREPORTING="False"
; 今後のリリースの SQL Server の改善のため、Microsoft にエラーを報告できるようにするかどうかを指定します。この機能を有効にするには 1 または True を指定し、無効にするには 0 または False を指定します。
ERRORREPORTING="False"
; インストール ディレクトリを指定します。
INSTANCEDIR="C:\Program Files\Microsoft SQL Server"
; エージェント アカウント名
AGTSVCACCOUNT="gree-rogue\Administrator"
AGTSVCPASSWORD="パスワード"
; インストール後にサービスを自動的に開始します。
AGTSVCSTARTUPTYPE="Automatic"
; CM ブリックの TCP 通信ポート
COMMFABRICPORT="0"
; マトリックスでのプライベート ネットワークの使用方法
COMMFABRICNETWORKLEVEL="0"
; ブリック間の通信を保護する方法
COMMFABRICENCRYPTION="0"
; CM ブリックで使用される TCP ポート
MATRIXCMBRICKCOMMPORT="0"
; SQL Server サービスのスタートアップの種類。
SQLSVCSTARTUPTYPE="Automatic"
; FILESTREAM 機能を有効にするレベル (0、1、2、または 3)。
FILESTREAMLEVEL="0"
; SQL Server Express で RANU を有効にするには、"1" に設定します。
ENABLERANU="False"
; データベース エンジンに使用する Windows 照合順序または SQL 照合順序を指定します。
SQLCOLLATION="Japanese_CI_AS"
; SQL Server サービスのアカウント: ドメイン\ユーザーまたはシステム アカウント。
SQLSVCACCOUNT="administrator"
SQLSVCPASSWORD="パスワード"
; SQL Server のシステム管理者として準備する Windows アカウント。
SQLSYSADMINACCOUNTS="administrator"
; 既定値は Windows 認証です。混合モード認証の場合は "SQL" を使用してください。
SECURITYMODE="SQL"
; データベース エンジンのバックアップ ファイルの既定のディレクトリ。
SQLBACKUPDIR="C:\database\backup"
; データベース エンジンのユーザー データベースの既定のディレクトリ。
SQLUSERDBDIR="F:\database\db"
; データベース エンジンのユーザー データベース ログの既定のディレクトリ。
SQLUSERDBLOGDIR="C:\database\log"
; データベース エンジンの TempDB ファイルのディレクトリ。
SQLTEMPDBDIR="F:\database\db"
; データベース エンジンの TempDB ログ ファイルのディレクトリ。
SQLTEMPDBLOGDIR="F:\database\tmp"
; 現在のユーザーを SQL Server 2012 Express のデータベース エンジン システム管理者として準備します。
ADDCURRENTUSERASSQLADMIN="False"
; TCP/IP プロトコルを無効にするには 0 を、有効にするには 1 を指定します。
TCPENABLED="1"
; Named Pipes プロトコルを無効にするには 0 を、有効にするには 1 を指定します。
NPENABLED="0"
; Browser サービスのスタートアップの種類。
BROWSERSVCSTARTUPTYPE="Disabled"
[/code]
コマンドプロンプトを開き、
[code]
インストールメディア内setup.exe /SAPWD="SQL認証時のsaのパスワード" /ConfigurationFile="保存したConfigurationFile.ini"
[/code]
以前windows用カスタムインストールメディアを作成するで、
OSインストール後に、アプリケーションをインストールをしたい場合の設定を調べたので記載。
動きとしては、
注意点としては、
会社のOSはWindowsServer2008R2なので、SetupComplete.cmdに以下の処理を追記。
[code]
# ログイン後のセットアップに使うスクリプト群をC:直下に配置
xcopy %windir%\Setup\scripts\custum_setup C:\setup\ /Y
# ドットネットフレームワーク4.5をインストール
%windir%\Setup\scripts\Packages\dotnetfx45_full_x86_x64.exe /q
# Windowsアップデート関連の何かをインストール
%windir%\Setup\scripts\Packages\Windows6.1-KB3138612-x64.msu /quiet /norestart
# Powershell4.0をインストール（再起動あり）
%windir%\Setup\scripts\Packages\Windows6.1-KB2819745-x64-MultiPkg.msu /quiet /forcerestart
[/code]