バックアップの種類

データベースには通常バックアップ機能が備えられている。DBMSによって若干異なるが、コマンドラインで行うもの、対話的にできるツールがあるもの、など。

SQL Server ではバックアップの方式や対象が異なる３種類のバックアップがある。バックアップは、テーブル単位ではなくデータベース単位で行われる。

・完全バックアップ
データベースの状態をそのまますべて確保するバックアップである。フルバックアップともいう。以下に挙げる２つのバックアップ方式を実行する場合であってもこのバックアップが一度は実施されていることが前提となる。つまりは、データベースが壊れたとき、これがないことには復旧できない、ということになる。

・差分バックアップ
直前の完全バックアップ時点からの差分のみを確保するバックアップである。差分のみなので全てを確保するより実行時間が短くて済む。
完全バックアップ後に差分バックアップを複数回実行したときはどうなるか？前述の通り「直前の完全バックアップ時点からの差分のみ」を確保するので、最新の状態を確保しておくためには完全バックアップと、最新の差分バックアップがあればよい、ということになる。

・トランザクションバックアップ
データベースのデータではなく、そのログファイルを確保するバックアップである。ログファイルとは「実行された更新系のSQL文が確保されているもの」である。直前の完全バックアップまたはトランザクションバックアップ時点からの差分のみを確保する。差分のみではあるが、更新量が多いデータベースの場合はかなり時間が掛かるケースがある。


さて、使い方である。これは「どのくらいの履歴まで再現が必要か」「どのくらいの重要度があるのか」に依存する。
どの時点まで戻す、というようなこともなく、日中は稼働させるが夜間はほぼ動かすことがないような場合
　・週に一度　or　月に一度　完全バックアップ
　・上記以外の毎日　　　　　差分バックアップ
くらいで十分だろう。更新されるテーブルを含むデータベースであれば最低限このくらいの対応はしたいものだ。これ以外ばケースバイケースである。


参考まで。ごく当たり前の話として「バックアップを確保する先は、バックアップ元と同じ物理ドライブには置かない」ということを理解しておく必要がある。
データが壊れる最大の要因はHDDなどのメディアの故障である。おなじドライブ上に入れていては「バックアップもろとも消滅」となる。
USB接続のHDD等でもよいから、バックアップは必ず別の物理メディアに格納しよう。

なお、ワークグループではなくドメインを構築している場合、LAN上のドライブに直接バックアップを確保するのは少々知識や設定が要るので注意が必要だ。
簡単に言えば
・SQL Server を実行しているIDがワークグループ上で、該当するLANのドライブに読み書き権限があること。
だそうだ。サーバーであれば「そのサーバー独自の管理」とし、ドメイン参加させないケースも多いと聞く。このあたりはハマるポイントらしい。

プロフェッショナルマネージャー

プロフェッショナルマネジャー/ハロルド・ジェニーン

￥1,400
Amazon.co.jp


プロフェッショナルマネージャーという書籍はユニクロの柳井CEO曰く「これが私の最高の教科書だ」と言わしめた本である。数年前に買っていたが、第二章あたりで面白くなく読んでいなかった。
しかし、つい最近、一から読み直すこととした。


さて、再読を初めて感じたこと。この本は「読みこなせる人」「読みこなせない人」が分かれるのではないかと思う。日本で多い「知識の要約を解説したハウツー本」に慣れている人は読解できないように思う。実際に経営やマネジメントに携わり、悩める人にはよい道しるべとして理解されるかな、と思う。
私自身の感想としては、第七章「エグゼクティブの机」は今の時代ちょっと・・、と思うが、第五章「経営者の条件」は「やはりそうか！」と思う部分がたくさんあったし、第八章「最大の病－エゴチズム」は「こういうことは蔓延している。しかし組織（経営層から見て）としてマイナスかどうかは分からなかった。それが氷解した」と思える。

人の上に立つ立場になったらだまされたと思って読んでみると、いくらかは役に立つと思う。おそらく、経験を重ねてから読めば以前とは違った感想にもなるだろう。
ときどき読み返すのがいい本だろうと思う。

VBAでのデータベースアクセス問題 セキュリティ面

VBAからのデータベースアクセスを止め、データベースアクセスはサーバー側の処理に任せた方がいいのではないかと考えている件の、セキュリティ面の観点について。


【意図しないSQLの問題】
まず、意図しないSQL文が要求されることが挙げられる、

VBAのプログラムからSQL文を直接発行するケースは多いだろう。アプリケーションからDBMSに対して直接SQL文でリクエストできるのは通常であるが、少しの技術と悪意があれば、クライアントアプリケーションから
・データ破壊
・データベースへの高負荷な要求
を行うことが可能である。

例えばWebのシステム。リクエストはサーバーのアプリケーション（CGI含む）が受け取っているが、要求は特定の命令とパラメータとして受け取り、内部で処理をするようになっている。それにより、想定しないSQL文を排除できている、ということだ。

クライアントアプリケーションから直接SQL文を実行させる、ということはセキュリティ面で考えるとリスクを包含している、ということは認知して頂きたい。

なお、過去に「データベースへの高負荷な要求」によりサーバーを停止させかけた経験がある。過去記事にあるので興味があればどうぞ。
　カテゴリ：　VBA構築事例
　記事　　：　汎用機DBのテーブル定義書作成ツール　（１～５）
　　　　　　　　　１　２　３　４　５