OracleとSQL Server、導入・構築・運用の違いとは？：RDBMSアーキテクチャの深層（3）（1/3 ページ）

はじめに

　前回「OracleとDB2、アーキテクチャはこれだけ違う」では、OracleとDB2のアーキテクチャの比較を行いました。今回は、OracleとSQL Serverの根本的なアーキテクチャの違いを簡単に解説し、その後、特に導入・構築・運用に際してどのような相違点があるのかを解説していきます。

　なお、以降の説明では、特に断りのない限り、「Oracle」はOracle9i Enterprise Edition、および「SQL Server」はSQL Server 2000の各製品に関する説明とします。

今回扱うRDBMSとその対象内容

　同じRDBMSとはいえ、OracleとDB2が違うように、SQL Serverもアーキテクチャが違います。前回では、OracleとDB2のそれぞれのRDBMSの“癖”を解説しながら、使用するうえでのポイントなどを紹介しました。今回はアーキテクチャの相違点を解説するとともに、多少視点を変えて、それが実際に導入・構築・運用といったフェイズの中でどのような違いとして現れてくるのかを解説していきます（図1）。

図1　今回扱うRDBMSとその対象内容

　ここで取り上げる内容は、すでにOracleデータベース管理の経験があり、今後、SQL Serverの導入を検討されているデータベース管理者に参考となる内容です。また、アーキテクチャにとどまらず導入・構築・運用について通して触れますので、導入を決定する立場の方にも参考になるでしょう。

アーキテクチャ

　前回はOracleとDB2について、両者のインスタンス・データベースにおける異なる概念について解説しました。SQL Serverのインスタンス・データベースの概念はDB2に近く、Oracleとは異なります。例えば、SQL ServerもDB2と同様に1つのインスタンスに複数のデータベースを対応させられます（図2）。

図2　インスタンスとデータベースの関係

　SQL Serverでは1つのインスタンス内においてデータベースを複数持つことで、データベース構成に関する個別の設定などを明確に分けることができ、Oracleに比べて少ないハードウェア・リソースでより独立した環境を開発者に提供することを可能とします。

　具体的な例を挙げると、「ハードウェアは1つしかない、用途が違う開発環境を2つ用意したい、かつそれぞれの環境にバックアップ時のダウンタイムを別々に設けたい」という要件があったとします。

• Oracleの場合
  Oracleデータベースでは、通常この要件はインスタンスを複数作成するか、スキーマを使用してカバーします。インスタンスを複数作成した場合はメモリなどのハードウェア・リソースをその分消費してしまいます。またスキーマ単位で複数面の環境を立ち上げた場合は、表領域単位やデータファイル単位のバックアップ管理が必要になります。スキーマと表領域などの対応がうまく取れていないと、スキーマ単位のダウンタイムを個別に設定する必要が生じ、管理が煩雑になります。
• SQL Serverの場合
  SQL Serverでは、通常このような要件はデータベースを複数作成することでカバーします。インスタンスは1つで済むので、ハードウェア・リソースも余分に消費することはありません。バックアップはデータベース単位で行うことが可能です。スキーマと表領域の対応といったことを考慮する必要がないので、管理は容易になります。

　またSQL Serverは1つのサーバ内にシステムデータベース、ユーザーデータベースと呼ばれる2種類のデータベースを持っています。Oracleはインスタンスに関する共通の情報をSYSスキーマ、SYSTEMスキーマとして保持していますが、SQL Serverではそれに相当するものがシステムデータベースになります。

　次ページでは、導入フェイズにおける両者の違いについて解説していきます。