はじめに
システム運用や設計変更の際、「このテーブルにはどんなカラムがあったか？」「主キーは何だったか？」を確認するために、いちいちGUIツールでプロパティ画面を開いていませんか。実務において、DBAはテーブル定義をSQLで直接抽出できるスキルが不可欠です。今回は、単なる一覧取得にとどまらず、現場で即戦力となるクエリの活用術を紹介します。
INFORMATION_SCHEMAの限界とシステムカタログの活用
多くのDBMSで共通して使えるINFORMATION_SCHEMAは便利ですが、特定のRDBMS（PostgreSQLやOracle、SQL Serverなど）が持つ拡張機能や詳細な物理設計（インデックスのフラグメンテーション状況やストレージ特性など）までは取得できません。
例えば、PostgreSQLでテーブルのサイズや実質的な行数を確認したい場合、標準規格のビューでは不十分です。この場合、pg_classやpg_attributeといったシステムカタログを直接参照する必要があります。
実務で頻出する「欲しい情報」の抽出クエリ
現場で最も重宝されるのは、単なるテーブル名の一覧ではなく、「そのテーブルが何のために存在し、誰が管理しているか」を紐づけた情報です。
例えば、PostgreSQLで「コメント（テーブル定義の論理名）」を抽出するクエリは以下の通りです。
SELECT
relname AS table_name,
obj_description(oid) AS table_comment
FROM
pg_class
WHERE
relkind = ‘r’
AND relnamespace = (SELECT oid FROM pg_namespace WHERE nspname = ‘public’);
このように、システムカタログを叩くことで、ドキュメントが整備されていないレガシー環境でも、データベース自身から最新の定義を逆引きすることが可能です。
DBAとしての独自の視点：メタデータの「鮮度」を可視化する
テーブル情報を取得する際、あわせて「最終更新日時」や「統計情報の更新日」を取得する癖をつけることを推奨します。
単純にテーブル一覧を出すだけでなく、「最後にデータが更新されたのはいつか」「統計情報が古くなっていないか」という情報を付加することで、パフォーマンスチューニングの優先順位を判断する材料になります。
おわりに
SQLでテーブル定義を自由に抽出できるようになると、変更履歴の差分比較や、インフラ移行時の棚卸しが劇的に速くなります。GUIに頼り切らず、カタログを操作するクエリを「マイ・ライブラリ」としてストックしておきましょう。これこそが、トラブル対応の初動を早めるプロのDBAの備えです。
コメント