web-dev-qa-db-ja.com

tnsnamesのサービス名/エイリアスのベストプラクティス

Tnsnames.ora(dblinksが使用するサーバー内のファイルではなく、パブリック用のファイル)ファイルの接続記述子に指定されたサービス名/エイリアスは、決してSIDではなく、サーバーの名前。

サーバーの名前は "myserver"で、インスタンスのSIDは "myinstance"です。

論理的なものと物理的なものを何らかの方法で結合しているため、接続文字列にエイリアス「myinstance-at-myserver」を指定することはお勧めできません。

  • 私は正しいのか間違っているのか、そしてその理由は?

これはベストプラクティスですか?:

# one server-instance-named descriptor
MYINSTANCE-AT-MYSERVER =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(Host = myserver)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = myinstance)
    )
  )

それともこれですか?

# several business-named descriptors pointing to the same listener
RRHH =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(Host = myserver)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = myinstance)
    )
  )

FINANCE =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(Host = myserver)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = myinstance)
    )
  )

SALES =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(Host = myserver)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = myinstance)
    )
  )
4

TNSエイリアスにサーバー名を含めたくありません。データベースが1つのサーバーから別のサーバーに移動したり、組織が複数のサーバーが存在するRACのようなものに移動したりするにつれて、これは時間の経過とともに変化すると思われます。

サービス名が有意義に選択されていると仮定すると、両方とも同じものの論理名であるため、サービス名はTNSエイリアスと一致すると予想されます。もちろん、それは難しくて速い規則ではありません。組織によっては、単一のサービスに対して2つの別々の論理名を使用する理由がある場合があります。たとえば、米国のユーザーのFINANCEサービスとフランスのユーザーのFINUSAサービスを指す単一のTNSエイリアスFINFRAが必要な場合があります。ただし、ほとんどの場合、TNSエイリアスがFINANCEの場合、サービス名もFINANCEにする必要があります。

4
Justin Cave

あなたにとって最も費用のかかるものは何ですか?優先する。

通常、最もコストがかかるのはユーザーの混乱です。通常のユーザーがTNS名を使用することはほとんどありません。彼らは通常、専用のアプリケーションを介してデータを使用し、CRMのようなアプリケーションの名前だけを知っています。パワーユーザーはTNS名に接続します(SQLdeveloperを考えてください)が、通常のアプリケーションにも接続します。アプリケーションCRMがORIONのTNS名を使用するのはなぜですか?パワーユーザーにはTNS名が表示され、気になるのはTNS名だけです。 SIDではなく、ホスト名ではありません。彼らはTNS名に関して他のユーザーと話します(FINANCEDB Johnからそのレポートを入手してください)。ユーザーの混乱が最小限の状態は、TNS名がそれを使用するアプリケーションの名前と同じである場合です。 「db」が追加されたものとまったく同じです。したがって、TNS名はCRMまたはCRMDBのようなものです。私は後者を好みます。

次にコストがかかるのは、tnsnames.ora内のすべてを変更することです。それがどこに配布されているかはわかりません。ファイルをクライアントマシンまたはアプリケーションサーバーに配置し、3か月後、ほんの数ダースに魔法のように表示されました。防げますか(いいえ、できません。)したがって、実際には、ユーザーにTNS名を付けると、その定義が確定します。したがって、そこにSIDを配置せず、SERVICE_NAMEを配置します。そこにIPアドレスを置かないで、ホスト名を入れてください。そして、これら2つはTNS名に「永久に」固執するため、それらがTNS名(Occamかみそり)と異なる理由はありません。

CRMDB=
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(Host = crmdb.mydomain.local)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = CRMDB)
    )
  )

コストの面で次に重要なのは、OS(マシン)とそのIPアドレスです。 TNS名ごとに個別のシステムを用意することはできません。そのため、IPアドレスの名前はcrmdb.mydomain.localだけではありません。同じIPアドレスは、financedb.mydomain.localのようにより多くの名前を持ちます。 OS管理者は、これを最善の方法で行う方法、およびOSのメインホスト名を決定する方法を決定します。他の多くのシステムでも同じ問題があり、1つのOSを指す複数の名前があるため、解決策を用意する必要があります。現在混乱しているのはDBAとOS管理者だけで、同じIPアドレスにつながる複数のホスト名が表示されます。しかし、ユーザーはそれを気にせず、混乱しません。 (ちなみに、このアプローチはSCANと一貫しています。)

コストに関して次のことは、Oracleインスタンスまたは「スキーマをインスタンスから分離するための管理コスト」のいずれかです。トレードオフはあなたが決めることです。

  • 多くのSERVICE_NAMESを1つのインスタンスに配置できますが、これは非常に一般的な方法です。警告の空っぽです。後でそれらを独自のインスタンスに分離することは非常に難しい場合があります。開発者がアプリケーションから別のアプリケーションのスキーマに「便利に」アクセスしようとするとき、開発者を寄せ付けないようにするのはあなた次第です。これはあなたの管理費です。この場合、データベース名とインスタンス名は、SERVICE_NAMEと同じであってはなりません。簡単にするために、メインのOSホスト名にいくぶん似た設定にしてください。
  • 独自のインスタンスを持つほどデリケートなSERVICE_NAMESがいくつかあります。または、インスタンスは、労力とメンテナンスの点で非常に安価であり、上記のコストを負担するよりも個別のインスタンスを使用することを好むかもしれません。このバリアントでは、データベース名とインスタンス名はCRMDBになります(RACまたはDataGuardを使用している場合、インスタンスはCRMDB1のようなものになります)。

また、SERVICE_NAMEは基本的に無料です。すべてのTNS名には、等しいSERVICE_NAMEが必要です。

3
kubanczyk