SQL Server と Oracle の用語 -
SQL Server では、2 つのアプリケーションがあり、データベースを完全に分離したい場合、アプリケーションごとに 1 つのデータベースを作成するだけでよいため、最終的に 2 つのデータベースになります。
オラクルで同じことをしたい場合、何を作成する必要がありますか? - 新しい「データベース」を作成しますか? アプリケーションごとの「インスタンス」、「スキーマ」、または「テーブルスペース」? (注: これら 2 つのアプリケーションは、2 つの異なる企業が使用する同じアプリケーションであり、データを共有していません!)
参照: http://www.codeproject.com/Tips/492342/Concept-mapping-between-SQL-Server-and-Oracle
過去に SQL Server で多くの作業を行ってきたので、同じことで苦労したため、Oracle がどのように整理されているかを理解しようとすることに共感を覚えます。以下の私のコメントは SQL Server 2000 および 2003 のものです。それ以降に変更があった場合はご容赦ください。
以前のレスポンダーは役に立ちました。ここで問題となる仮定の 1 つは、SQL Server と Oracle の間に正確な「レベル」の同等性があるということだと思います。「レベル」とは、上で図解した階層内の同じスペースを占めるものです (ところで、これは開始するのに適した場所だと思いますが、いくつかの場所で少し編集する必要があるかもしれません。 Oracle階層で「ユーザー」と「スキーマ」をどのように図解したかの例、私はそれらを並べて配置するかもしれません.)これらの概念「レベル」がDBプラットフォーム間で正確に一致するとは思いません.
Oracle のスキーマは、SQL Server の個別のデータベースと多少同等ですが、完全ではありません。
SQLサーバーのデータベース間の「壁」（正確な専門用語ではありませんが、まあ）は、Oracleのスキーマ間の「壁」よりも少し高いと言えます。他の人は同意しないかもしれませんが、ここに私の理由があります：
を。Oracle のスキーマは、純粋な論理構造です。誰がオブジェクトの所有権を持っているかを示します。オブジェクトの物理的な位置やレイアウトとは関係ありません。表領域 (以前のポスターで指摘された直交概念) は、物理的なオブジェクトの場所。表領域は複数のスキーマにあるオブジェクトを保持でき、その逆も可能です。SQL Server では、これらの 2 つの概念が 1 つにマージされます。データベースは多かれ少なかれテーブルスペースとスキーマの両方ですが、SQL Server の DB 内にはいくつかの点で、さまざまなオブジェクト所有権を持つ複数の所有者がいます。NT認証を使用しない場合、ユーザーはサーバーレベルで定義され、個々のDBのユーザーに「リンク」する必要があるため、これは少し混乱する可能性があります.
b. SQL Server の 2 つの別々の DB へのユーザーが、Oracle で見つけたよりも、相対的な他のユーザーの DB にアクセスできないことを確認する方が簡単、または少なくとも少し簡単だと思ったことを覚えています。
c. SQL サーバーの DB は物理ストレージと論理所有権の両方を表すため、DB をデタッチし、別の SQL Server インスタンスに移動してアタッチできます。Oracle のスキーマではこれを行うことはできません。つまり、データを別のサーバーや別のスキーマにデータ ポンプしたり、バックアップしたりできますが、そのためには、少なくともスクリプトを作成したり、Enterprise Manager でかなりの回数クリックしたりする必要があります。SQL Serverにあるワンクリックの「Detach DB」オプションは提供されないため、SQL Server DBは多かれ少なかれ前後に移動できるユニットであるという考えをより簡単に得ることができますデータベース。
結論から言うと、どちらでもいいと思います。つまり、1) アプリケーションごとに各インスタンスに 1 つのスキーマを持つ 2 つの別個の Oracle インスタンスを作成するか、2) 1 つの Oracle インスタンスに 2 つの別個のスキーマを作成します。
各オプションには長所と短所があります。オプション 1 は、セットアップと構成の作業が増える可能性がありますが、DB ごとに分離、独立性、個別のハードウェアを持つ機能なども得られます。オプション 2 はかなり単純になりますが、データ間の分離が少なくなり、構成の失敗や、あるスキーマのユーザーが別のスキーマにアクセスできるようになるなどのリスクが高くなります。また、あるスキーマのデータにアクセスするクエリを作成する人が、すべての CPU および IO リソースを使用して、他のスキーマのユーザーを枯渇させないように、もう少し注意する必要があることも意味します。
また、はい、12c でプラガブル データベースを使用できます。ただし、これらの質問をする必要があるという事実を考えると (恥ずかしいことではありません。自分がどこにいるのかを指摘するだけです)、より複雑なセットアップになりやすいものを推奨することを躊躇します.
TL;DR -- SQL Server は Oracle ではなく、Oracle は SQL Server ではありません。どちらのオプションも機能し、それぞれに長所と短所があります。
同じデータベースに新しいインスタンス (スキーマ) を作成する必要があります。ここで、Oracle のスキーマは SQL サーバー データベースと同じです。