2 ダウンタイムなしのパッチ適用の準備

この章では、新しいOracleホームのインストールとパッチ適用、新しいJavaバージョンのインストールまたは各ノードでの更新されたアプリケーションのインストールを含む、パッチ適用ワークフローを構成する前に完了する事前ステップについて説明します。ZDTパッチ適用の制限についても説明します。

この章の構成は、次のとおりです。

ZDTパッチ適用の制限
シングルトン・サービスの移行の準備
パッチが適用されたOracleホームのロールアウトの準備
新しいJavaバージョンへのアップグレードの準備
新しいアプリケーション・バージョンへの更新の準備

ZDTパッチ適用の制限

ZDTパッチ適用ワークフローを準備および作成する前に、次の制限を確認してください。

管理サーバーがワークフローに含まれる場合、ノード・マネージャを使用して起動する必要があります。ドメインのbinディレクトリのstartWebLogicコマンドを使用して管理サーバーを起動しないでください。詳細は、「ノード・マネージャを使用した管理サーバーの起動」を参照してください。
ワークフローに含まれる管理対象サーバーは、クラスタの一部である必要があり、そのクラスタは2つ以上のノードにまたがる必要があります。
管理サーバーは更新される管理対象サーバーとは別のノードにある必要があります。
管理サーバーが存在するノードを含む、ワークフローに含まれる各ノードでは、固有のノード・マネージャが実行中である必要があります。
パッチが適用されたOracleホームへと更新している場合、現在のOracleホームは、ワークフローに含まれる各ノードにローカルにインストールされる必要があります。必須ではありませんが、各ノードでOracleホームも同じ場所にすることをお薦めします。
指定したノードに、異なるクラスタに属する管理対象サーバーがある場合、それらのクラスタは同じOracleホームで共有され、それらのクラスタのいずれかがワークフローに含まれている場合、他のクラスタもワークフローに含める必要があります。たとえば、Node 1のCluster 1にManaged Server 1があり、Cluster 2にManaged Server 2があり、Cluster 1とCluster 2の両方が同じOracleホームを共有している場合、ワークフローにCluster 1が含まれていれば、Cluster 2も含める必要があります。これはJavaホーム、Oracleホームおよびアプリケーションの更新のロールアウトに適用されます。
ドメイン・ディレクトリは、Oracleホームのディレクトリの外部に配置する必要があります。
Coherenceアプリケーション(GARファイル)は、WLSTのrolloutApplicationsコマンドまたはWebLogic Server管理コンソールのZDTの「アプリケーション」機能によりサポートされません。
(Windowsのみ) WLSTを使用して、新しいOracleホームのロールアウトを起動する場合、ワークフローの一部として更新されるOracleホームからWLSTを実行することはできません。かわりに、次のいずれかのオプションを使用します。
- ワークフローに含まれていないノードのOracleホームからWLSTを実行します。このOracleホームは他のノードの更新されているOracleホームと同じバージョンである必要があります。
- 更新されているドメインの一部ではない別のOracleホームからWLSTを実行します。このOracleホームは更新されているOracleホームと同じバージョンである必要があります。これは更新されているドメインの管理サーバー・ノードを含む、任意のノードに配置できます。
- WebLogic Server管理コンソールを使用して、ワークフローを起動します。
(Windowsのみ) ZDTロールアウト操作中、Windowsファイルのロックは問題を引き起こす可能性があります。ロールアウトの失敗を避けるため、Windowsでロールアウトを実行する前に、これらの共通のファイル・ハンドルのロックの問題の修正を試みる必要があります。
- 管理コンソールを使用してアプリケーションをデプロイしている場合、管理サーバーはアプリケーションのソース・ファイルでロックを保持することができます。このロックが解放されないと、後続のアプリケーション・ロールアウトが適切に機能しない可能性があります。ロックを解放するには、アプリケーションのデプロイ後でロールアウトの起動前の任意の時点で、管理コンソールをログアウトする必要があります。
- 管理サーバーでWLSTクライアントを使用すると、Oracleホーム・ディレクトリのロックを引き起こします。これはそのノードのロールアウト(ドメインのロールアウトを含む)が失敗する原因になります。これを避けるには、ロールアウトのターゲットではないノードにインストールされたWLSTクライアントを使用するか、または管理コンソールを使用したロールアウトを起動します。
- Oracleホームの下の任意のディレクトリに存在する、コマンド・ターミナルまたはアプリケーションを開くことで、ファイルのロックが発生する可能性があります。結果として、特定のOracleホームを更新できなくなります。
- アプリケーション・ソース・ファイルまたはjarファイルを参照することがあるコマンド・ターミナルまたはアプリケーションは、ファイル・ロックを引き起こす可能性があり、それにより特定のアプリケーションを更新できなくなります。

シングルトン・サービスの移行の準備

すべてのZDTロールアウトでは、ロールアウトに含まれるサーバーの再起動が必要です。ロールアウトの機能の1つは、JTAおよびJMSなどのシングルトン・サービスの検出と処理です。環境にシングルトン・サービスがある場合、『Oracle WebLogic Serverクラスタの管理』のサービスの移行に関する項で説明されているように、サービスの移行がそのために構成されます。サービスが移行用に構成され、移行ポリシーがexactly-onceの場合、サービスはサーバーの正常なシャットダウン中に自動的に移行されます。しかし、サービスの移行ポリシーがmanualまたはfailure-recoveryの場合、サーバーのシャットダウン中に、安全に移行されたことを確認するステップを実行する必要があります。手順は次のとおりです。

この項での説明に従って、このようなサービス用の移行プロパティを定義するJSONファイルを作成します
第3章「ワークフローの構成と監視」の説明に従って、JSONファイルを使用するロールアウトを構成します。

JSONファイルは、次の行で始まる必要があります。

{"migrations":[

移行する必要のある各シングルトン・サービスの移行は、次の表で説明しているパラメータを使用して定義されます。

パラメータ	説明
`source`	サービスが移行される元のソース・サーバーの名前。このパラメータは必須です。
`destination`	`migrationType`が`jms`、`jta`または`all`の場合、サービスが移行される先のサーバーの名前。 `migrationType`が`server`の場合、ノード・マネージャが実行しているドメイン内の別のマシン(ノード)の名前。 `migrationType`が`jms`、`jta`、`server`または`all`の場合、このパラメータは必須です。
`migrationType`	移行のタイプ。次のタイプのいずれかです。 `jms`—すべてのJMS移行可能ターゲットをソース・サーバーから移行先サーバーへ移行します。 `jta`—すべてのJTAサービスをソース・サーバーから移行先サーバーへ移行します。 `server`—サーバーの移行を実行するサーバー全体の移行を起動します。移行先はノード・マネージャが実行しているマシン(ノード)である必要があります。 `all`—すべてのサービス(JTAやJMSなど)をソース・サーバーから移行先サーバーへ移行します。 `none`—ソース・サーバーからのサービスの移行を無効にします。このタイプを指定する場合、`failback`は必要ありません。
`failback`	`true`に設定すると、フェイルバックが実行されます。フェイルバックは、サービスを元のホスティング・サーバー(ロールアウト前にサービスが実行していたサーバー)にリストアします。デフォルト値は、`false`です(フェイルバックしない)。注意: JTAサービスは移行用に起動されたときに自動的にフェイルバックされます。したがって、JTAサービスには適用されないため、`failback`オプションを使用しないでください。

次のサンプルJSONファイルに、様々な移行シナリオの定義方法を示します。

    {"migrations":[           

# Migrate all JMS migratable targets on server1 to server2. Perform a fail back
# if the operation fails.
    {
    "source":"server1",                
    "destination":"server2",
    "migrationType":"jms",
    "failback":"true"
    },

# Migrate only JTA services from server1 to server3. Note that JTA migration
# does not support the failback option, as it is not needed.
    {
    "source":"server1",
    "destination":"server3",
    "migrationType":"jta"
    },

# Disable all migrations from server2
    {
    "source":"server2",
    "migrationType":"none" 
    },
    {

# Migrate all services (for example, JTA and JMS) from server 3 to server1 with
# no failback
    "source":"server3",
    "destination":"server1",
    "migrationType":"all"
    },
 
# Use Whole Server Migration to migrate server4 to the node named machine 5 with
# no failback
    {
    "source":"server4",
    "destination":"machine5",
    "migrationType":"server"
    }
 
    ]}

注意:

ZDTロールアウトでは、シングルトン・サービスが移行されるか、またはパッチの適用中にシャットダウンするだけかを指定できます。サービスを同じマシンの別のサーバー・インスタンスに移行するためのサポートもユーザーに提供します。しかし、同じマシンではなく別のマシンのサーバーへのサービスの移行を常に指定することをお薦めします。それは、1つのマシン上のすべてのサーバーがロールアウト中にシャットダウンすることにより、ユーザーに回避できない停止時間が発生する可能性があるからです。

パッチが適用されたOracleホームのロールアウトの準備

この項では、パッチが適用されたOracleホームを管理対象サーバーにロールアウトするための準備方法について説明します。これを行うには、次の2つの方法があります。

OPatchAutoツールを使用して、Oracleホームの自動的なクローン作成、パッチの適用、パッチを適用したOracleホームのアーカイブの作成を行うことができます。次にOPatchAutoを使用してパッチが適用されたOracleホームのアーカイブをドメイン内のノードに配布できます。より自動化されている、この手法の使用をお薦めします。詳細は次の項を参照してください。
- OPatchAutoを使用したパッチを適用するOracleホームのアーカイブの作成
- OPatchAutoを使用したパッチを適用するアーカイブの各ノードへの配布
手動で2つ目のOracleホームを作成、OPatchを使用してそれにパッチを適用、copyBinaryを使用してパッチが適用されたOracleホームのアーカイブを作成、その後そのアーカイブをドメイン内のノードにコピーできます。詳細は次の項を参照してください。

どちらの場合も、準備プロセスに管理対象サーバーのシャットダウンは必要ないので、アプリケーションの可用性に影響はありません。

注意:

ドメインにWebLogic Server以外のFusion Middleware製品(SOAやWebCenterなど)が含まれていて、Oracleホームのそれらのアプリケーションにパッチを適用済の場合、ロールアウトを実行中に現在のアクティブ・セッションを保持するには、パッチが適用されたバージョンがZDTパッチ適用と互換性があることを確認します。たとえば、適用されたパッチはセッション形状への変更に制限があり、ドメインで実行中の他のFusion Middleware製品と下位互換性を持つ必要があります。

OPatchAutoを使用したパッチを適用するOracleホームのアーカイブの作成

この項では、既存のOracleホームのクローンの作成方法、そこへのパッチの適用方法、OPatchAutoツールを使用した、パッチが適用されたOracleホームのアーカイブの作成方法について説明します。適用するパッチはOPatchを使用してpatch_homeディレクトリにダウンロードしておく必要があります。

パッチが適用されたOracleホームのアーカイブを作成するには、次のコマンドを入力します。イメージを作成する元のORACLE_HOMEからこのコマンドを実行する必要があります。このコマンドは、パッチが未適用のOracleホームのクローンを作成し、指定したpatch_homeディレクトリのパッチを適用してから、パッチが適用されたアーカイブを作成します。

cd ORACLE_HOME/OPatch/auto/core/bin
opatchauto.sh apply patch_home -create-image -image-location path -oop

次の表に、このコマンド内のパラメータを示します。

パラメータ	説明
`patch_home`	適用するパッチが保存されているOPatch ${PATCH_HOME}ディレクトリ。
`-create-image`	ORACLE HOMEディレクトリのイメージを作成することを示します。イメージにはpatch_homeのパッチが含まれます。
`-image-location` `path`	作成するイメージJARファイルのフルパスとファイル名を指定します。次に例を示します。 `-image-location /u01/images/OH-patch1.jar`
`-oop`	これがホーム外パッチ適用アーカイブであることを示します。

パッチが適用されたアーカイブのOPatchAutoを使用した各ノードへの配布

パッチが適用されたアーカイブを作成したら、OPatchAutoを使用して、そのアーカイブをOracleホームのパッチ適用ワークフローに含まれる各ノードに配布します。

アーカイブを配布するには次のコマンドを使用します。

cd ORACLE_HOME/OPatch/auto/core/bin
opatchauto.sh apply -plan wls-zdt-push-image -image-location path 
-wls-zdt-host adminserver:port -wls-zdt-target target 
-wls-zdt-remote-image path -wallet path -walletPassword password

次の表に、このコマンド内のパラメータを示します。

パラメータ	説明
`-plan`	`opatchauto apply`により実行される操作のタイプを示します。ZDTのパッチが適用されたOracleホームの配布では、このパラメータの値として`wls-zdt-push-image`を必ず指定します。
`-image-location` `path`	配布するイメージJARファイルのフルパスとファイル名を指定します。次に例を示します。 `-image-location /u01/images/OH-patch1.jar`
`-wls-zdt-host` `adminserver:port`	パッチが適用されたOracleホームのロールアウト先のドメインの、管理サーバーのホスト名とポート番号を指定します。アーカイブはこのノードに配布されます。
`-wls-zdt-target` `target`	ロールアウトに含まれるクラスタまたはクラスタのカンマ区切りリストを指定します。アーカイブはこれらのクラスタが構成されるすべてのノードに配布されます。
`-wls-zdt-remote-image` `path`	ZDTロールアウトに含まれる各ノードに作成するアーカイブ・ファイルへのフルパス。これは、元のアーカイブと同じファイル名である必要はありません。次に例を示します。 `-wls-zdt-remote-image /u01/images/rollout-OH-image.jar`
`-wallet` `path`	`configWallet.sh`または`configWallet.cmd`を使用して作成されたウォレット・ディレクトリへのフルパス。次に例を示します。 `-wallet $HOME/wallet`
`-walletPassword` `password`	必要な場合、指定したウォレットのパスワード。次に例を示します。 `-walletPassword mypassword`

これらのステップを完了すると、Oracleホームのパッチ適用を含むワークフローを作成する準備ができます。第3章「ワークフローの構成と監視」を参照してください。

注意:

同じパッチ適用ワークフローを使用してJavaバージョンまたはアプリケーションも更新する場合、ワークフローの作成前に、これらのアップグレードのための準備ステップを先に実行します。

2つ目のOracleホームの作成

パッチが適用されたOracleホームを手動で作成するには、最初に、copyBinaryおよびpasteBinaryを使用して既存のOracleホームのコピーを作成します。

注意:

適用するパッチをテストできるように、本番マシン以外に2つ目のOracleホームを作成してパッチを適用することをお薦めしますが、必須ではありません。新しいOracleホームにパッチを適用するノードで、次の手順を実行する必要があります。そのノードのOracleホームは、本番ドメインで使用しているOracleホームと同じである必要があります。

パッチを適用する2つ目のOracleホームを作成するには、次の手順を実行します。

次のディレクトリに移動します。ここでORACLE_HOMEはパッチを適用するOracleホームです。
```
cd ORACLE_HOME/oracle_common/bin
```
次のコマンドを実行します。ここで、archiveは作成するアーカイブ・ファイルのフルパスおよびファイル名で、oracle_homeは既存のOracleホームへのフルパスです。$JAVA_HOMEはOracleホームのインストールに使用されたJavaホームとして定義される必要があることに留意してください。

UNIX
```
./copyBinary.sh -javaHome $JAVA_HOME -archiveLoc archive -sourceOracleHomeLoc oracle_home
```
Windows
```
copyBinary.cmd -javaHome %JAVA_HOME% -archiveLoc archive -sourceOracleHomeLoc oracle_home
```
たとえば、次のコマンドは、/u01/oraclehomes/wls1221にあるOracleホームを使用して、Oracleホーム・アーカイブwls1221.jarをネットワークの場所/net/oraclehomes/に作成します。
```
./copyBinary.sh -javaHome $JAVA_HOME -archiveLoc /net/oraclehomes/wls1221.jar -sourceOracleHomeLoc /u01/oraclehomes/wls1221
```
次のコマンドを実行して、2つ目のOracleホームを作成します。ここで、archiveは作成するアーカイブ・ファイルのフルパスおよびファイル名で、patch_homeはパッチを適用する新しいOracleホームへのフルパスです。$JAVA_HOMEは元のOracleホームのインストールに使用されたJavaホームとして定義される必要があることに留意してください。

UNIX
```
./pasteBinary.sh -javaHome $JAVA_HOME -archiveLoc archive -targetOracleHomeLoc patch_home
```
Windows
```
pasteBinary.cmd -javaHome %JAVA_HOME% -archiveLoc archive -targetOracleHomeLoc patch_home
```

たとえば、次のコマンドは、アーカイブ/net/oraclehomes/wls1221.jarを使用して、Oracleホームwls1221_patchedを/u01/oraclehomes/に作成します。

./pasteBinary.sh -javaHome $JAVA_HOME -archiveLoc /net/oraclehomes/wls1221.jar -targetOracleHomeLoc /u01/oraclehomes/wls1221_patched

2つ目のOracleホームへのパッチの適用

2つ目のOracleホームにパッチを適用するには、OPatchツールを使用して個別のパッチ、バンドル・パッチ、セキュリティ・パッチの更新、またはパッチ・セットの更新を、2つ目のオフラインのOracleホームへ適用します。特定のパッチまたはパッチのグループを適用する前に、すべての前提条件のパッチが適用済であることを確認します。

OPatchを使用したOracleホームへのパッチの適用および準備方法の詳細は、『Opatchによるパッチ適用』を参照してください。

アーカイブの作成および各ノードへの配布

パッチが適用されたOracleホームを作成したら、次のステップを使用してOracleホームのアーカイブを作成し、それをロールアウトに含まれる各ノードにコピーします。

次のディレクトリに移動します。ここでORACLE_HOMEは前の項で作成したパッチが適用されたOracleホームです。
```
cd ORACLE_HOME/oracle_common/bin
```
次のコマンドを実行します。ここで、archiveは作成するアーカイブ・ファイルのフルパスおよびファイル名で、patched_homeは前の項で作成したパッチが適用されたOracleホームへのフルパスです。$JAVA_HOMEは現在のOracleホームのインストールに使用されたJavaホームとして定義される必要があることに留意してください。

UNIX
```
./copyBinary.sh -javaHome $JAVA_HOME -archiveLoc archive -sourceOracleHomeLoc patched_home
```
Windows
```
copyBinary.cmd -javaHome %JAVA_HOME% -archiveLoc archive -sourceOracleHomeLoc patched_home
```
たとえば、次のコマンドは、/01/oraclehomes/wls1221_patchedにあるパッチが適用されたOracleホームを使用して、Oracleホーム・アーカイブwls1221.11.jarをネットワークの場所/net/oraclehomes/に作成します。
```
./copyBinary.sh -javaHome $JAVA_HOME -archiveLoc /net/oraclehomes/wls_1221.11.jar -sourceOracleHomeLoc /u01/oraclehomes/wls1221_patched
```
パッチ適用ワークフローに含まれる各ノードで、置き換えるOracleホームの親フォルダにアーカイブ・ファイルをコピーします。たとえば、アーカイブがネットワークの場所/net/oraclehomes/wls_1221.11.jarにあり、置き換えられるOracleホームは/u01/oraclehomes/wls1221にある場合:
```
cp /net/oraclehomes/wls1221.11.jar /u01/oraclehomes/
```
多数のノードにコピーしている場合、このステップを実行するのにサードパーティ製ソフトウェアの配布アプリケーションを使用することができます。

注意:

新しいJavaバージョンへのアップグレードの準備

この項では、より新しいバージョンのJavaにアップグレードするための準備方法について説明します。準備には管理対象サーバーのシャットダウンが必要ないので、アプリケーションの可用性が中断することはありません。

新しいJavaバージョンにアップグレードするには、次の手順を実行します。

新しいJavaバージョンをインストールする前に、ノード・マネージャと管理対象サーバーが、新しいバージョンをインストール予定のすべてのノードで実行していることを確認します。これにより、Javaインストーラが既存のJavaホームのパスを変更するのを防ぎます。
アップグレードに含まれる各ノードで、新しいJavaバージョンを各ノードの同じパスにインストールします。新しいJavaバージョンへのフル・パスは、アップグレードが正常に行われるために、各ノード上で同じである必要があります。

新しいJavaバージョンを各ノードへコピーしたら、新しいJavaホームへのアップグレードを含むワークフローを作成する準備ができます。第3章「ワークフローの構成と監視」を参照してください。

新しいアプリケーション・バージョンへの更新の準備

この項では、ZDTワークフローを使用して新しいアプリケーションにアップグレードするための準備方法について説明します。内容は次のとおりです。

ステージング・モードの影響
アプリケーションの更新用JSONファイルの作成

ステージング・モードの影響

管理対象サーバー間でデプロイされたアプリケーションは、アプリケーションの配布方法と最新に保つ方法を示す、3つのステージング・モードのいずれかを使用してデプロイできます。それらは、ステージ・モード、非ステージ・モードおよび外部ステージ・モードです。

アプリケーションの更新ワークフローの準備方法は、アプリケーションをステージングしたときに使用されたモードによって異なります。次の表で、アプリケーションをデプロイするのに使用するステージング・モードに基づく、アプリケーションの更新の準備方法について説明します。

表2-1 ステージング・モードに基づくアプリケーションの更新の準備

ステージング・モード	必要な準備と結果
ステージ	各更新済アプリケーション・ディレクトリのコピーを、ドメインの管理サーバーに配置します。結果: ワークフローでは、元のアプリケーション・ディレクトリを管理サーバーに配置し、WebLogic Serverがそれを各管理対象サーバーにコピーします。
非ステージ	更新済アプリケーション・ディレクトリのコピーを、影響を受ける各ノードに配置します。このディレクトリは各ノード上で同じ場所にある必要があります。結果: ワークフローは、既存のアプリケーション・ディレクトリを更新済アプリケーション・ディレクトリで置き換えることにより、各ノードを順次更新し、元のアプリケーション・ディレクトリを指定したバックアップの場所に移動します。
外部ステージ	更新済アプリケーション・ディレクトリのコピーを、影響を受ける各ノードに配置します。このディレクトリは各ノード上で同じ場所にある必要があります。結果: ワークフローはアプリケーションが外部ステージ・アプリケーションであることを検出し、ノード上の各管理対象サーバーのステージ・ディレクトリの正しいパスを特定し、更新済アプリケーションをその場所にコピーし、元のアプリケーションを指定したバックアップの場所に移動します。

ステージング・モード

必要な準備と結果

ステージ

各更新済アプリケーション・ディレクトリのコピーを、ドメインの管理サーバーに配置します。

結果: ワークフローでは、元のアプリケーション・ディレクトリを管理サーバーに配置し、WebLogic Serverがそれを各管理対象サーバーにコピーします。

非ステージ

更新済アプリケーション・ディレクトリのコピーを、影響を受ける各ノードに配置します。このディレクトリは各ノード上で同じ場所にある必要があります。

結果: ワークフローは、既存のアプリケーション・ディレクトリを更新済アプリケーション・ディレクトリで置き換えることにより、各ノードを順次更新し、元のアプリケーション・ディレクトリを指定したバックアップの場所に移動します。

外部ステージ

結果: ワークフローはアプリケーションが外部ステージ・アプリケーションであることを検出し、ノード上の各管理対象サーバーのステージ・ディレクトリの正しいパスを特定し、更新済アプリケーションをその場所にコピーし、元のアプリケーションを指定したバックアップの場所に移動します。

様々なステージング・モードの詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』のステージング・モードの説明とベスト・プラクティスに関する項を参照してください。

アプリケーションの更新用JSONファイルの作成

1つのワークフローでドメイン内の1つまたは複数のアプリケーションを更新できます。アプリケーションの更新は、各アプリケーションに対して次のことを定義する、JSONファイルを作成することで実行されます。

アプリケーション名(applicationName)
更新されたアプリケーション・アーカイブに対するパスおよびファイル名(patchedLocation)
元のアプリケーション・アーカイブをバックアップする先のパスおよびファイル(backupLocation)

WLSTまたはWebLogic Server管理コンソールのいずれかを使用してワークフローを構成する場合、更新に使用するJSONファイルのファイル名を指定します。

次の例に、2つのアプリケーションMyAppおよびAnotherAppを新しいバージョンに更新することを意図するJSONファイルの構造を示します。1つのJSONファイルを使用して必要な数のアプリケーションを更新できます。

例2-1 複数のアプリケーションを更新するJSONファイルの例

{"applications":[
{
"applicationName":"MyApp",
"patchedLocation":"/u01/applications/MyAppv2.war",
"backupLocation": "/u01/applications/MyAppv1.war"
},
{
"applicationName":"AnotherApp",
"patchedLocation":"/u01/applications/AnotherAppv2.war",
"backupLocation": "/u01/applications/AnotherAppv1.war"
}
]}

更新済アプリケーションを必要な場所すべてにコピーし、JSONファイルを作成したら、アプリケーションの更新を含むワークフローを作成する準備ができます。第3章「ワークフローの構成と監視」を参照してください。