SQLserver2012のログファイル物理サイズ縮小

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

 

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

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

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

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

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

 

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

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

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みたいです）

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

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

 

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

 

 

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