タグ: SQLServer

今週は弊課に新人がいらっしゃいました。

その為、システム利用に関するユーザー追加依頼がチラホラとありまして。

 

中でもちょっと面倒だなと思ったのが、SQLserverのユーザ追加。

管理中のシステムにおいて、DB（全部SQLserver）接続ユーザは個人別になっており、

ユーザの立場によって割り当てる権限（ロール）が決まっています。

私はそれを付与する立場です。

何が出来るか出来ないか、私の指先一つです。ふひひ。

 

 

大きく３つ（本番環境、結合環境、単体環境）に区分される環境に、

それぞれ数台ずつのDBサーバ（１サーバ１インスタンス）、

各インスタンスにはいくつかのデータベース。

ユーザの立場によって使うデータベースはバラバラ。

 

今回は急かされたのもあっていつもどおりにSSMSで接続して作業してたのですが、

コマンドラインでパパパっと出来るんじゃないのかー、と思って調べてみました。

 

 

■SQLCMD

そういう訳でSQLCMDです。

sqlcmd ユーティリティを使用すると、Transact-SQL ステートメントやシステム プロシージャ、スクリプト ファイルを使用可能なさまざまなモードで入力できます。

• コマンド プロンプト。
• クエリ エディターでの SQLCMD モード。
• Windows スクリプト ファイル。
• SQL Server エージェント ジョブのオペレーティング システム (Cmd.exe) ジョブ ステップ。

このユーティリティでは、ODBC を使用して、Transact-SQL バッチを実行します。

利用前提環境

Windows インストーラー 4.5 と Microsoft ODBC Driver for SQL Server 17 の両方が必要です。

私のPCにはSQLserverを入れてるのですが、ODBCドライバは入って無い状態でした。

インストールで躓く事は特にないと思います。

 

■使ってみる

コマンドプロンプトを起動して SQLCMD と叩くだけ。

管理者モードで起動する必要もなく、パスも通してくれてます。

 

じゃあなんか適当にSQLを実行してみようかと

あれ。

どうやったら実行出来るんだろ？まだDBに繋がっていないとかかな？DB変えてみよ。

あっ

 

なるほど。goで実行、そういえばそうでしたね。

 

うんうん。

 

 

抜けるときはgo不要です。

 

さて、別サーバに接続するには…

-H -U -P　あたりでしょうか。

 

 

来週出社したら試してみたいと思います。

 

余談ですが、SQLserverでサーバとかインスタンスとか言うとややこしいですね。

発言者のバックボーンによって、何を指してるのかが違ったりして…

 

今勤めているのは出戻り現場。５年前から２年間お世話になってました。

 

当時、まともにドキュメントもなく管理されていないシステムを前に、

サーバーの一覧（すらなかった！）を初めに、管理資料や手順書群を作り、

後続要員に半年かけて引き継いだのですが。

全く運用されてないしドキュメントも修正されてない有様で…

５年前と同じく、調査とドキュメント作成に勤しむ毎日です。

 

そんな愚痴から始まる今回の記事は、

昨日からトライ＆エラーでやってた事を書いてみようかと。

SQLserverの基本的な事は知ってる前提になりますが、

それがそもそも何なのかは私もわかりません。。。

 

■発端

テスト用DBサーバのDBバックアップが失敗してました。

調べてみると、容量不足。

 

■原因調査

で、SSMSからDBのプロパティを眺めていると、

初期サイズ50GBも取ってる癖に使用可能が49GBという、

なかなかの乱暴者を発見。

主に利用するチームのリーダーに確認した所、

当初要件でサイズ見積したが、要件ドロップした為

DBのサイズは小さくしても構わない。

但し今テストで使ってるので、中身は壊すな、との事。

 

■愚痴

要件落ちた時点で再見積もりしてくれよ…

ディスク領域には限りがある事を意識したまえ。

サポート問い合わせしようとしたら、契約切れてました。。。

取り敢えず自宅PCにSQLserverをインストールして、

あれこれ試してみることに。

 

■手順確認

まずGUIでSSMSからの容量削減を試す。

①初期サイズとしてデータ1000MB、ログ10MBのDBを作成。

②適当にテーブルを作ってデータを投入

③SSMSのプロパティで初期サイズを小さくしてみる。

 

あっさり縮小可能。物理ファイル(.mdf)も小さくなっているし、

中身も問題なくselect出来る。

 

次に、

④初期サイズを超えるくらいデータを作成する

⑤データを一旦truncate後、再度データを少しだけ入れてみる

⑥ここで③同様の操作で初期サイズまで削減

 

これも問題なく動作。

じゃあ、もっとガツンと小さくしたらどうなるのか？

という興味が湧いて、サイズを1MBに指定してみました。

すると、初期サイズの指定値が”３”に変化しました。

 

 

つまり、指定値が小さすぎたからと言ってDBが破損する訳ではなく、

可能な限りで頑張って小さくしてくれる、という事みたいです。

 

 

■疑問が増える

あれこれ試したせいか、トランザクションログが大きくなってしまいました。

これをDBと同じようにちいさく…できませんでした。そうですよね。

DBを作成する時に完全復旧モデルにしていたので、

正しいお作法で縮小しないといけないようです。

 

１，初期状態

 

まずはDB圧縮を試してみました。

 

２．DB圧縮後

お、ちょっと縮んだ。

 

そういえばトランザクションログはバックアップで切り捨てられるんだっけ、

という何となくの記憶に従って、次はバックアップを実行。

 

結果。あれ？小さくならない…

 

再圧縮してみる。

 

おおー、小さくなった！

 

つまり、トランザクションログのバックアップを実行して、

中身が切り捨て可能な状態になってから圧縮するのだな！

よし、もう一回確認しておこう。

 

同じSQLを流してログを増やしてから、

 

ログをバックアップしてサイズ確認。この時点ではこのくらい。

 

今度はファイル指定の圧縮を試す。

 

・・・あれ？バックアップ後と一緒？？

 

この後、DBの完全バックアップ→DB単位の圧縮→ファイル単位のログ圧縮、

と繰り返してみましたが、ログの容量が小さくならない。

困ってしまったので、DBを削除して１からやり直しました。

 

■結局正しい手順は・・・

MSの正規の手順というものがあるのだとは思いますが。

見つけられませんでしたので、あくまで個人的な実験の結果として。

 

１．まず圧縮（どっちのやり方でもOKみたいです）

２．次にトランザクションログのバックアップ

３．最後にもう一度圧縮（こちらはファイル単位圧縮しか試してません）

 

この方法で３度くらい試して、毎回ログは縮小されました。

 

 

無事に来週を迎えられそうで、ホッとしています。