Oracle® Exadata Database Machine

メンテナンス・ガイド

12cリリース2 (12.2)

E84907-03(原本部品番号:E81012-04)

2017年7月

Oracle Exadata Database Machineメンテナンス・ガイド, 12c リリース2 (12.2)

E84907-03

Copyright © 2008, 2017, Oracle and/or its affiliates. All rights reserved.

原本著者: Janet Stern

原本協力著者: Lypp-Tek Khoo-Ellis

原本協力者: Doug Archambault、Leo Agranonik、Andrew Babb、Bharat Baddepudi、Michael Belef、Nilesh Choudhury、Henry Chow、Kevin Closson、Bob Cyphers、Ravindra Dani、Boris Erlikhman、Jaime Figueroa、Gurmeet Goindi、Roger Hansen、Shrikumar Hariharasubrahmanian、Kevin Jernigan、Caroline Johnston、Sarat Karkarla、Leslie Keller、Frank Kobylanski、Poojan Kumar、René Kundersma、Robert S.Lee、Sue Lee、Jennifer Leung、Yang Liu、Juan Loaiza、Barb Lundhild、Catherine Luu、Varun Malhotra、Bagish Mishra、Valarie Moore、Philip Newlan、Adrian Ng、Dan Norris、Michael Nowak、Bharat Paliwal、Umesh Panchaksharaiah、Hector Pujol、Sugam Pandey、Dmitry Potapov、Darryl Presley、Vince Pulice、Ashish Ray、Samitha Samaranayake、Richard Scales、Olly Sharwood、Jia Shi、Kesavan Srinivasan、Mahesh Subramaniam、Michelle Sun、Krishnadev Telikicherla、Cliff Thomas、Alex Tsukerman、Shreyas Udgaonkar、Kothanda Umamageswaran、Doug Utzig、James Viscusi、Vern Wagman、Zheren Zhang

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。お客様との間に適切な契約が定められている場合を除いて、オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。お客様との間に適切な契約が定められている場合を除いて、オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

例一覧

図一覧

表一覧

タイトルおよび著作権情報

はじめに

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

1 一般的な保守情報

- 1.1 役割および職責の概要

- 1.1.1 Oracle Exadata Database Machineでの管理面の差異の理解

- 1.2 Oracle Exadataラックの電源投入および切断

- 1.2.1 非緊急時の電源の投入と切断の手順

- 1.2.1.1 Oracle Exadataラックの電源の投入

- 1.2.1.1.1 ILOMを使用したリモート・サーバーの電源投入

- 1.2.1.2 Oracle Exadataラックの電源の切断

- 1.2.1.2.1 データベース・サーバーの電源切断

- 1.2.1.2.2 Exadata Storage Serverの電源切断

- 1.2.1.2.3 複数のサーバーの一括電源切断

- 1.2.1.3 ネットワーク・スイッチの電源の投入および切断

- 1.2.2 緊急時の電源切断の考慮事項

- 1.2.2.1 緊急時の電源切断の手順

- 1.2.2.2 緊急時の電源切断スイッチ

- 1.2.3 注意事項と警告

- 1.3 自動サービス・リクエストの理解

- 1.3.1 ASRのインストールおよび構成

- 1.4 Oracle Enterprise Manager Cloud Controlを使用したシステムの監視

- 1.5 Oracle Configuration Managerを使用したシステムの監視

- 1.6 コンポーネントのパスワードの変更

- 1.6.1 データベース・サーバーのパスワードの変更

- 1.6.1.1 データベース・サーバーでのユーザー・アカウントのパスワードの変更

- 1.6.1.2 データベース・サーバーでのGRUBアカウントのパスワードの変更

- 1.6.2 Exadata Storage Serverのパスワードの変更

- 1.6.3 配電ユニットのパスワードの変更

- 1.6.4 ILOMのパスワードの変更

- 1.6.5 InfiniBandスイッチのパスワードの変更

- 1.6.6 Ciscoイーサネット・スイッチのパスワードの変更

- 1.6.7 KVMのパスワードの変更

- 1.7 サーバー・モデルの判別

- 1.8 サーバーの周囲温度の監視

- 1.9 ディスク・コントローラ・バッテリ・バックアップ・ユニットの交換

- 1.9.1 データベース・サーバーのディスク・コントローラBBUの交換

- 1.9.1.1 手順1: ディスク・コントローラBBUの取り外しの準備

- 1.9.1.2 手順2: ディスク・コントローラBBUの交換

- 1.9.1.3 手順3: 新しいディスク・コントローラBBUの有効化および確認

- 1.9.2 Exadata Storage Serverのディスク・コントローラBBUの交換

- 1.9.2.1 手順1: ディスク・コントローラBBUの取り外しの準備

- 1.9.2.2 手順2: ディスク・コントローラBBUの交換

- 1.9.2.3 手順3: 新しいディスク・コントローラBBUの有効化

- 1.10 dbmsrvサービスの概要

- 1.11 dbmsrvのユーザーIDおよびグループIDの変更

- 1.12 構成変更中のセルおよびデータベース・ノードの状態

- 1.13 レスキュー計画

- 1.14 ExaWatcherチャート

- 1.14.1 IOチャート

- 1.14.1.1 IO統計サマリー

- 1.14.1.2 I/O統計詳細

- 1.14.2 CPUチャート

- 1.14.3 CPU詳細

- 1.14.4 セル・サーバー・チャート

- 1.14.5 アラート履歴

2 Oracle Exadata Database Machineのデータベース・サーバーの保守

- 2.1 データベース・サーバー上の管理サーバー

- 2.2 Oracle Database Serverの物理ディスクの保守

- 2.2.1 データベース・サーバー構成の検証

- 2.2.1.1 ディスク・コントローラ構成の検証

- 2.2.1.2 仮想ドライブ構成の検証

- 2.2.1.3 物理ドライブ構成の検証

- 2.2.2 データベース・サーバーRAIDセットの再構築の監視

- 2.2.3 Oracle Exadata Storage Server Softwareリリース12.1.2.1.0以上へのアップグレード後のホット・スペア・ドライブのリクレイム

- 2.2.4 自動ファイル削除のポリシーについて

- 2.3 データベース・サーバーへのディスク拡張キットの追加

- 2.4 データベース・サーバーへのメモリー拡張キットの追加

- 2.5 Oracle Exadata X6-2でのネットワーク・カードの追加および構成

- 2.5.1 非Oracle VM環境での追加のネットワーク・カードの構成

- 2.5.2 Oracle VM環境での追加のネットワーク・カードの構成

- 2.6 データベース・サーバーのアクティブ・コア数の増加

- 2.7 ベア・メタルOracle RACクラスタからOracle VMのOracle RACクラスタへの移行

- 2.8 Oracle Exadata Database MachineのOracle VMドメインの管理

- 2.8.1 実行中のドメインの表示

- 2.8.2 ユーザー・ドメイン・コンソールの監視

- 2.8.3 ユーザー・ドメインの開始

- 2.8.4 ユーザー・ドメインの自動起動の無効化

- 2.8.5 ユーザー・ドメイン内部のユーザー・ドメインのシャットダウン

- 2.8.6 管理ドメイン内部のユーザー・ドメインのシャットダウン

- 2.8.7 Oracle VMユーザー・ドメインでのOracle Databasesのバックアップおよびリストア

- 2.8.8 ユーザー・ドメインに割り当てられたメモリーの変更

- 2.8.9 ユーザー・ドメインに割り当てられた仮想CPU数の変更

- 2.8.10 ユーザー・ドメインのディスク領域の増加

- 2.8.10.1 新規LVMディスクのユーザー・ドメインへの追加

- 2.8.10.2 rootファイル・システムのサイズの増加

- 2.8.10.3 /u01ファイル・システムのサイズの増加

- 2.8.10.4 Oracle Grid InfrastructureホームまたはDatabaseホーム・ファイル・システムのサイズの増加

- 2.8.10.5 スワップ領域のサイズの増加

- 2.8.11 データベース・サーバーのディスク拡張後の管理ドメインの/EXAVMIMAGESの拡張

- 2.8.12 Oracle VM Oracle RACクラスタの作成

- 2.8.13 ExadataでのOracle VM Oracle RACクラスタの拡張

- 2.8.14 Oracle Grid InfrastructureおよびOracle Databaseの存在しないユーザー・ドメインの作成

- 2.8.15 ユーザー・ドメインの別のデータベース・サーバーへの移動

- 2.8.16 Oracle VMで実行するOracle RACクラスタの削除

- 2.8.17 Oracle VM Oracle RACクラスタからのユーザー・ドメインの削除

- 2.8.18 タグVLANインタフェースの実装

- 2.8.19 Oracle ExadataでのOracle VM Oracle RACクラスタ間のInfiniBandパーティションの実装

- 2.8.19.1 OVM RACクラスタ間のInfiniBandパーティションの実装: 要件

- 2.8.19.2 OVM RACクラスタ間のInfiniBandパーティションの実装: 手順

- 2.8.19.3 OVM RACクラスタ間のInfiniBandパーティションの実装: 制限されたメンバーシップの設定

- 2.8.20 Oracle EXAchkの実行

- 2.9 LVMパーティションの拡張

- 2.9.1 ルートLVMパーティションの拡張

- 2.9.1.1 Oracle Exadata Storage Server Softwareリリース11.2.3.2.1以上を実行するシステムでの、ルートLVMパーティションの拡張

- 2.9.1.2 Oracle Exadata Storage Server Softwareリリース11.2.3.2.1より前のリリースを実行するシステムでの、ルートLVMパーティションの拡張

- 2.9.2 ルート以外のLVMパーティションのサイズ変更

- 2.9.2.1 Oracle Exadata Storage Server Softwareリリース11.2.3.2.1以上を実行するシステムでの、非ルートLVMパーティションの拡張

- 2.9.2.2 Oracle Exadata Storage Server Softwareリリース11.2.3.2.1より前のリリースを実行するシステムでの、非ルートLVMパーティションの拡張

- 2.9.2.3 Oracle Exadata Storage Server Softwareリリース11.2.3.2.1以上を実行するシステムでの、非ルートLVMパーティションの縮小

- 2.9.3 スワップ・パーティションの拡張

- 2.10 Oracle Linuxデータベース・サーバーのスナップショット・ベースのバックアップの作成

- 2.10.1 Oracle Linuxデータベース・サーバーのスナップショット・ベースのバックアップの作成 - パーティションをカスタマイズしていない場合

- 2.10.2 Oracle Linuxデータベース・サーバーのスナップショット・ベースのバックアップの作成 - パーティションをカスタマイズしている場合

- 2.11 Oracle Virtual Serverデプロイメントの管理ドメイン(dom0)とユーザー・ドメイン(domU)のバックアップ

- 2.11.1 スナップショット・ベースのバックアップを使用した管理ドメインdom0のバックアップ

- 2.11.2 ユーザー・ドメインのバックアップ

- 2.11.2.1 方法1: すべてのユーザー・ドメインをバックアップする

- 2.11.2.2 方法2: ユーザー・ドメイン内からユーザー・ドメインをバックアップする

- 2.12 スナップショット・ベースのバックアップを使用したOracle Linuxデータベース・サーバーのリカバリ

- 2.12.1 Oracle Linuxデータベース・サーバーのリカバリ - パーティションをカスタマイズしていない場合

- 2.12.2 Oracle Linuxデータベース・サーバーのリカバリ - パーティションをカスタマイズしている場合

- 2.12.3 Oracle Exadata Database Machineエイス・ラックのOracle Linuxデータベース・サーバーのリカバリ後の構成

- 2.13 Oracle Virtual Serverデプロイメントでのリカバリ

- 2.13.1 シナリオ1: Oracle Virtual Serverとすべてのユーザー・ドメインのバックアップからのリカバリ

- 2.13.2 シナリオ2: dom0の再イメージ化およびバックアップからのユーザー・ドメインのリストア

- 2.13.3 シナリオ3: スナップショット・バックアップからのユーザー・ドメインのリストアおよびリカバリ

- 2.14 Oracle Linuxデータベース・サーバーの更新

- 2.14.1 データベース・サーバーの更新のパス

- 2.14.2 Oracle Linuxデータベース・サーバーの更新の概要

- 2.14.3 Oracle Exadataチャンネル・コンテンツでのyumリポジトリの準備と設定

- 2.14.3.1 ULN Oracle Exadataチャンネルのローカル・ミラーの別個のサーバー上への設定

- 2.14.3.1.1 ローカルULNミラーの作成および維持

- 2.14.3.1.2 ローカルULNミラーの確認

- 2.14.3.2 ULN Oracle ExadataチャンネルのISOイメージのダウンロードおよび圧縮されたイメージの場所のdbnodeupdate.shユーティリティへの手渡し

- 2.14.3.3 ISOイメージをダウンロードしてWebサーバーで使用できるようにする

- 2.14.4 データベース更新時の停止時間の短縮

- 2.14.4.1 データベース・サーバーの更新前のバックアップおよび前提条件チェックの実行

- 2.14.5 リリース11.2.3.n.nまたは12.1.n.n.nにパッチ適用またはイメージ化を以前にしているデータベース・サーバーの更新

- 2.14.5.1 データベース・サーバー・パッケージのカスタマイズとMinimumおよびExact依存性の理解

- 2.14.5.2 dbnodeupdate.shユーティリティの実行の準備

- 2.14.5.3 廃止パッケージ・リスト、除外パッケージ・リストおよび自動パッケージ削除の確認

- 2.14.5.4 更新モードでのdbnodeupdate.shユーティリティの実行

- 2.14.5.4.1 dbnodeupdate.shユーティリティの実行の例

- 2.14.6 リリース11.2.2.4.2を実行中のデータベース・サーバーの更新

- 2.14.6.1 リリース11.2.2.4.2のデータベース・サーバー上でのdbnodeupdate.shユーティリティの使用の準備

- 2.14.6.2 dbnodeupdate.shユーティリティの実行

- 2.14.7 データベース・サーバー上のローリング・バック更新

- 2.14.8 patchmgrによるデータベース・ノードの更新

- 2.14.8.1 dbserver.patch.zipの入手とインストール

- 2.14.8.2 非ローリングのアップグレードの動作

- 2.14.8.3 更新手順

- 2.14.8.4 patchmgrのオプション

- 2.14.8.5 前提条件の確認

- 2.14.8.6 (データベース)ノードの更新

- 2.14.8.7 更新のロール・バック

- 2.14.8.8 patchmgrによるデータベース・ノードの更新時における失敗のトラブルシューティング

- 2.14.9 sudoによるdbnodeupdate.shおよびpatchmgr (およびdbnodeupdateオーケストレーション)の実行

- 2.14.9.1 sudoによるdbnodeupdate.shの実行

- 2.14.9.2 sudoによるpatchmgr (およびdbnodeupdateオーケストレーション)の実行

- 2.15 Oracle Linuxデータベース・サーバーの再イメージ化

- 2.15.1 作業1: Oracleサポート・サービスへの連絡

- 2.15.2 作業2: クラスタ検証ユーティリティの最新リリースのダウンロード

- 2.15.3 作業3: クラスタの障害が発生したデータベース・サーバーの削除

- 2.15.4 作業4: イメージ化に使用するUSBフラッシュ・ドライブの準備

- 2.15.5 作業5: 交換データベース・サーバーのイメージ化

- 2.15.6 作業6: 交換データベース・サーバーの構成

- 2.15.7 作業7: クラスタの交換データベース・サーバーの準備

- 2.15.8 作業8: 交換データベース・サーバーへのOracle Exadata Storage Server Softwareパッチ・バンドルの適用

- 2.15.9 作業9: 交換データベース・サーバーへのOracle Grid Infrastructureのクローニング

- 2.15.10 作業10: 交換データベース・サーバーへのOracle Databaseホームのクローニング

- 2.16 データベース・サーバーの既存のエラスティック構成の変更

- 2.16.1 クラスタへの新しいデータベース・サーバーの追加

- 2.16.2 別のクラスタへの既存データベース・サーバーの移動

- 2.16.3 Oracle RACからのデータベース・サーバーの削除

- 2.17 高冗長性ディスク・グループのためのQuorumディスクの管理

- 2.17.1 Quorumディスク管理の概要

- 2.17.2 Quorumディスク管理のソフトウェア要件

- 2.17.3 Quorumディスクのデータベース・ノードへの追加

- 2.17.4 quorumディスクの再作成

- 2.17.5 ユースケース

- 2.17.5.1 Oracle Exadata 12.1.2.3.0以降での新規デプロイメント

- 2.17.5.2 Oracle Exadataリリース12.1.2.3.0以降へのアップグレード

- 2.17.5.3 12.1.2.3.0より前のOracle Exadataリリースへのダウングレード

- 2.17.5.4 エラスティック構成の変更

- 2.17.5.4.1 データベース・ノードの追加

- 2.17.5.4.2 データベース・ノードの削除

- 2.17.5.4.3 Oracle Exadata Storage Serverの追加および既存の高冗長性ディスク・グループの拡張

- 2.17.5.4.4 Oracle Exadata Storage Serverの削除

- 2.17.6 quorumdiskmgrリファレンス

- 2.17.6.1 Quorumディスク管理ユーティリティの構文

- 2.17.6.2 quorumdiskmgrオブジェクト

- 2.17.6.3 Quorumディスク構成の作成(--create --config)

- 2.17.6.4 ターゲットの作成(--create --target)

- 2.17.6.5 デバイスの作成(--create --device)

- 2.17.6.6 Quorumディスク構成のリスト(--list --config)

- 2.17.6.7 ターゲットのリスト(--list --target)

- 2.17.6.8 デバイスのリスト(--list --device)

- 2.17.6.9 構成の削除(--delete --config)

- 2.17.6.10 ターゲットの削除(--delete --target)

- 2.17.6.11 デバイスの削除(--delete --device)

- 2.17.6.12 所有者とグループ値の変更(--alter --config)

- 2.17.6.13 InfiniBand IPアドレスの変更(--alter --target)

- 2.18 vmetricsの使用

- 2.18.1 vmetricsサービスのインストールと起動

- 2.18.2 vmetricsパッケージ内のファイル

- 2.18.3 統計の表示

- 2.18.4 vmetricsへのメトリックの追加

3 Oracle ExadataラックのExadata Storage Serverの保守

- 3.1 Exadata Storage Serverの保守

- 3.1.1 Exadata Storage Serverのシャットダウン

- 3.1.2 Exadata Storage Serverの削除

- 3.1.3 リバランス操作のステータスのチェック

- 3.1.4 Exadataセルのパッチ適用の理解

- 3.1.4.1 ローリング更新の理解

- 3.1.4.2 非ローリング更新の理解

- 3.1.5 診断ISOを使用したネットワーク接続の有効化

- 3.2 Exadata Storage Serverの物理ディスクの保守

- 3.2.1 ハード・ディスク・コントローラのライトスルー・キャッシュ・モードの監視

- 3.2.2 ディスク障害による物理ディスクの交換

- 3.2.3 ディスクの問題による物理ディスクの交換

- 3.2.4 低いパフォーマンスによる物理ディスクの交換

- 3.2.5 物理ディスクの事前交換

- 3.2.6 Exadata Storage Serverから別のExadata Storage Serverへのすべてのドライブの移動

- 3.2.7 物理ディスクの再利用

- 3.2.8 同じ物理ディスクの取外しおよび交換

- 3.2.9 拒否された物理ディスクの再有効化

- 3.3 フラッシュ・ディスクの保守

- 3.3.1 フラッシュ・ディスク障害によるフラッシュ・ディスクの交換

- 3.3.2 フラッシュ・ディスクの問題によるフラッシュ・ディスクの交換

- 3.3.3 ソフトウェア・バージョン11.2.3.3.1以上のライトバック・フラッシュ・キャッシュの有効化および無効化

- 3.3.3.1 11.2.3.3.1以上でのライトバック・フラッシュ・キャッシュの有効化

- 3.3.3.2 11.2.3.3.1以上でのライトバック・フラッシュ・キャッシュの無効化

- 3.3.4 11.2.3.3.1より前のソフトウェア・バージョンでのライトバック・フラッシュ・キャッシュの有効化および無効化

- 3.3.4.1 ローリング形式でのライトバック・フラッシュ・キャッシュの有効化

- 3.3.4.2 非ローリング形式でのライトバック・フラッシュ・キャッシュの有効化

- 3.3.4.3 ローリング形式でのライトバック・フラッシュ・キャッシュの無効化

- 3.3.4.4 非ローリング形式でのライトバック・フラッシュ・キャッシュの無効化

- 3.3.5 フラッシュ・キャッシュの圧縮の有効化

- 3.3.6 フラッシュ・キャッシュの圧縮の無効化

- 3.4 グリッド・ディスクのサイズ変更

- 3.4.1 使用可能な領域の容量の判別

- 3.4.2 ドナー・ディスク・グループのOracle ASMディスクの縮小

- 3.4.3 ドナー・ディスク・グループのグリッド・ディスクの縮小

- 3.4.4 使用可能な領域によるグリッド・ディスクのサイズの拡張

- 3.4.5 Oracle ASMディスクのサイズの拡張

- 3.5 Oracle Exadata Storage Server Softwareレスキュー手順の使用

- 3.5.1 CELLBOOT USBフラッシュ・ドライブを使用したレスキューの実行

- 3.5.1.1 Oracle Exadata Database Machineエイス・ラックのストレージ・サーバーのレスキュー後の構成

- 3.5.2 損傷したCELLBOOT USBフラッシュ・ドライブの再作成

- 3.6 ストレージ・セルの既存のエラスティック構成の変更

- 3.6.1 セル・ノードの追加

- 3.6.2 既存のExadataストレージ・グリッドの拡張

- 3.6.3 既存のディスク・グループまたはストレージ・グリッドからのストレージ・セルの削除

4 Oracle Exadataラックの他のコンポーネントの保守

- 4.1 配電ユニットの交換

- 4.1.1 PDU交換のガイドラインの確認

- 4.1.2 PDUの交換

- 4.2 無反応になったILOMのリセット

- 4.2.1 SSHを使用したILOMのリセット

- 4.2.2 ILOMリモート・コンソールを使用したILOMのリセット

- 4.2.3 IPMItoolを使用したILOMのリセット

- 4.2.4 Oracle Exadata Database Machine X2-2 ServerおよびExadata Storage ServerでのSPリセット・ピンを使用したILOMのリセット

- 4.2.5 Sun Fire X4800 Oracle Database ServerおよびSun Server X2-8 Oracle Database ServerからのSPの取り外し

- 4.2.6 ILOM電源からプラグを抜く

- 4.3 サービス・プロセッサおよびILOMネットワーク設定の構成

- 4.4 1GbE接続から10GbE接続への変更

- 4.4.1 作業1: ping機能の検証

- 4.4.2 作業2: 現在のインタフェース・ファイルのバックアップ

- 4.4.3 作業3: 10GbEインタフェース設定の編集

- 4.4.4 作業4: 10GbEインタフェースの検証

- 4.5 InfiniBandネットワークの保守

- 4.5.1 スイッチ設定のバックアップおよびリストア

- 4.5.1.1 2.1.3-4ファームウェアを使用したスイッチの設定のバックアップ

- 4.5.1.2 1.1.3-2ファームウェアを使用したスイッチの設定のバックアップ

- 4.5.1.3 1.0.1ファームウェアを使用したスイッチの設定のバックアップ

- 4.5.1.4 2.1.3-4ファームウェアを使用したスイッチの設定のリストア

- 4.5.1.5 1.1.3-2ファームウェアを使用したスイッチの設定のリストア

- 4.5.1.6 1.0.1ファームウェアを使用したスイッチの設定のリストア

- 4.5.2 2.2.2へのアップグレード・プロセスで発生する可能性があるアラート

- 4.5.3 Oracle Exadata Database Machine X3-8フル・ラックおよびOracle Exadata Database Machine X2-8フル・ラックのデータベース・サーバーのInfiniBandカード障害の修正

- 4.5.4 障害が発生したSun Datacenter InfiniBand Switch 36スイッチの交換

- 4.5.5 InfiniBandネットワーク構成の確認

- 4.5.5.1 トポロジ検証ユーティリティの使用

- 4.5.6 InfiniBandネットワーク動作の確認

- 4.5.7 ネットワーク・サブネット・マネージャ・マスターの理解

- 4.5.8 InfiniBandスイッチのファームウェアのアップグレード

- 4.5.8.1 スイッチ・ソフトウェアのダウングレード

- 4.6 InfiniBandパーティションの構成

- 4.7 InfiniBand IPアドレスおよびホスト名の変更

- 4.7.1 InfiniBandネットワーク情報の変更

- 4.8 データベース・サーバーでのネットワーク・ルーティングの構成

- 4.8.1 作業1: ブート時ルーティングのための構成

- 4.8.2 作業2: リアルタイム・ルーティングのための構成

- 4.8.3 作業3: ネットワーク・ルーティング・ルールおよびルートの検証

- 4.8.4 トラブルシューティングのためのネットワーク・ルーティング構成の削除

- 4.8.5 デフォルトのルーティングへの再設定

- 4.9 DNSサーバーの変更

- 4.9.1 作業1: Sun Datacenter InfiniBand Switch 36スイッチでのDNSサーバー・アドレスの変更

- 4.9.2 作業2: Ciscoイーサネット・スイッチでのDNSサーバー・アドレスの変更

- 4.9.3 作業3: データベース・サーバーでのDNSサーバー・アドレスの変更

- 4.9.4 作業4: Exadata Storage ServerでのDNSサーバーの変更

- 4.9.5 作業5: KVMスイッチでのDNSサーバーの変更

- 4.10 NTPサーバーの変更

- 4.10.1 作業1: データベース・サーバーでのNTPサーバー・アドレスの設定

- 4.10.2 作業2: Sun Datacenter InfiniBand Switch 36スイッチでのNTPサーバー・アドレスの設定

- 4.10.3 作業3: Ciscoイーサネット・スイッチでのNTPサーバー・アドレスの設定

- 4.10.4 作業4: Exadata Storage ServerでのNTPサーバーの設定

- 4.11 タイムゾーン設定の変更

- 4.11.1 作業1: Exadata Storage Serverでのタイムゾーン設定の変更

- 4.11.2 作業2: データベース・サーバーでのタイムゾーン設定の変更

- 4.11.3 作業3: InfiniBandスイッチでのタイムゾーン設定の変更

- 4.11.4 作業4: Ciscoスイッチでのタイムゾーン設定の変更

- 4.12 KVMスイッチの構成

- 4.12.1 サーバーにアクセスするKVMスイッチの構成

- 4.12.2 KVMスイッチを使用したサーバーのアクセス

5 Exadataソフトウェアの更新

- 5.1 ソフトウェア・メンテナンスの計画

- 5.1.1 Exadata Database Machineソフトウェアおよび更新の理解

- 5.1.1.1 ソフトウェア・リリース・タイプ

- 5.1.1.2 ソフトウェア・リリース可用性

- 5.1.1.3 ソフトウェア更新頻度

- 5.1.1.4 ソフトウェア更新ユーティリティ

- 5.1.2 ソフトウェア・メンテナンスの構成および操作のベスト・プラクティス

- 5.1.2.1 ローリング更新および非ローリング更新の理解

- 5.1.2.2 Oracle LinuxカーネルおよびOracle Databaseの個別修正のオンライン更新

- 5.1.2.3 最適なソフトウェア・メンテナンスの構成プラクティス

- 5.1.2.4 最適なソフトウェア・メンテナンスの操作のプラクティス

- 5.1.2.5 バージョン互換性および複合バージョンのサポート

- 5.1.2.6 更新の順序

- 5.1.3 Exadataソフトウェア・バージョンの理解

- 5.1.3.1 新しいExadataバージョンへの更新のルール

- 5.1.4 Exadata Patchmgr更新ユーティリティ

- 5.1.4.1 Patchmgrの取得

- 5.1.4.2 Patchmgrの構文

- 5.2 Exadataソフトウェア更新の実行の概要

- 5.2.1 ソフトウェア・メンテナンス前に実行するアクション

- 5.2.2 Exadataストレージ・サーバー更新の実行の概要

- 5.2.3 Exadataデータベース・サーバー更新の実行の概要

- 5.2.3.1 非仮想化構成を更新する手順

- 5.2.3.2 仮想化構成を更新する手順

- 5.2.4 Exadata InfiniBandスイッチ更新の実行の概要

- 5.2.5 Grid InfrastructureおよびDatabase更新の実行の概要

- 5.3 Exadataデータベース・サーバーの更新

- 5.3.1 Exadataデータベース・サーバーの更新パス

- 5.3.2 Exadata以外のソフトウェアのインストール、更新および管理

- 5.3.3 カスタマイズのレベルと影響

- 5.3.4 Exadataデータベース・サーバーの更新ユーティリティ

- 5.3.5 ツール実行ホストの更新

- 5.3.6 root以外のユーザーとしての更新ユーティリティの実行および複数の起動の同時実行

- 5.3.7 Exadataデータベース・サーバーを更新する場合にお薦めするタイムライン

- 5.3.8 Oracle Exadataチャンネル・コンテンツでのyumリポジトリの準備と設定

- 5.3.8.1 My Oracle SupportからISOイメージをYUMリポジトリとしてダウンロードし、圧縮イメージの場所を更新ユーティリティに渡す

- 5.3.8.2 独立したサーバー上のULN Oracle Exadataチャンネルからローカル・ミラーをYUM HTTPリポジトリとして設定する

- 5.3.8.3 My Oracle SupportからISOイメージをYUMリポジトリとしてダウンロードし、それをWebサーバー上でYUM HTTPリポジトリとして使用できるようにする

- 5.3.9 Exadata廃止パッケージの管理

- 5.3.10 個々のパッケージの更新

- 5.3.11 前提条件チェックの実行

- 5.3.12 計画メンテナンスの前のExadataデータベース・サーバーのバックアップ

- 5.3.13 更新の実行

- 5.3.14 更新のロールバック

- 5.3.15 Exadataデータベース・サーバー更新のトラブルシューティング

- 5.4 Exadataストレージ・サーバーの更新

- 5.4.1 Oracle Exadata Storage Serverの更新ユーティリティ

- 5.4.2 Exadataストレージ・サーバーを更新する場合にお薦めするタイムライン

- 5.4.3 Exadataストレージ・サーバーを更新するための準備

- 5.4.4 Exadataストレージ・サーバーの更新の実行

- 5.4.5 Exadataストレージ・サーバーに対する更新のロールバック

- 5.4.6 Exadataストレージ・サーバー更新の監視、検証およびトラブルシューティング

- 5.5 Exadata InfiniBandスイッチ・ファームウェアの更新

- 5.5.1 InfiniBandスイッチ・ファームウェア更新の準備

- 5.5.2 InfiniBandスイッチ・ファームウェア・ソフトウェアの更新

- 5.5.3 InfiniBandスイッチ・ファームウェア・ソフトウェアのダウングレード

- 5.6 SSH等価の設定

- 5.7 Exadataデータベース・サーバーの依存性問題が原因で失敗した前提条件チェックのトラブルシューティング

- 5.8 Exadataデータベース・サーバーでのmultilib問題のトラブルシューティング

6 DBMCLIユーティリティの使用

- 6.1 DBMCLIユーティリティの概要

- 6.1.1 DBMCLIの起動

- 6.1.2 DBMCLIのコマンド構文およびオプションの理解

- 6.1.3 予約語

- 6.1.4 DBMCLIのコマンドライン編集

- 6.1.5 DBMCLIの入力および出力オプション

- 6.1.6 DBMCLIスクリプトのコメント

- 6.1.7 DBMCLIコマンドの行継続文字

- 6.2 DBMCLIの管理コマンドについて

- 6.3 DBMCLIのオブジェクト・コマンドについて

- 6.4 DBMCLIのオブジェクト・タイプについて

- 6.5 DBMCLIのオブジェクト属性

- 6.5.1 共通の属性値の制限

- 6.5.2 LISTコマンドの属性リスト

- 6.5.3 LISTコマンドの属性フィルタ

- 6.6 メトリックを使用したデータベース・サーバーの監視

- 6.6.1 メトリックについて

- 6.6.2 メトリックの表示

- 6.6.2.1 メトリック定義の表示

- 6.6.2.2 現在のメトリックの表示

- 6.6.2.3 メトリック履歴の表示

- 6.6.3 データベース・サーバーのメトリック

- 6.7 DBMCLIコマンド・リファレンス

- 6.7.1 ALTER

- 6.7.1.1 ALTER ALERTHISTORY

- 6.7.1.2 ALTER DBSERVER

- 6.7.1.3 ALTER IBPORT

- 6.7.1.4 ALTER THRESHOLD

- 6.7.1.5 ALTER USER

- 6.7.2 CREATE

- 6.7.2.1 CREATE DBSERVER

- 6.7.2.2 CREATE DIAGPACK

- 6.7.2.3 CREATE ROLE

- 6.7.2.4 CREATE THRESHOLD

- 6.7.2.5 CREATE USER

- 6.7.3 DESCRIBE

- 6.7.3.1 DESCRIBE ALERTDEFINITION

- 6.7.3.2 DESCRIBE ALERTHISTORY

- 6.7.3.3 DESCRIBE DBSERVER

- 6.7.3.4 DESCRIBE IBPORT

- 6.7.3.5 DESCRIBE LUN

- 6.7.3.6 DESCRIBE METRICCURRENT

- 6.7.3.7 DESCRIBE METRICDEFINITION

- 6.7.3.8 DESCRIBE METRICHISTORY

- 6.7.3.9 DESCRIBE PHYSICALDISK

- 6.7.3.10 DESCRIBE ROLE

- 6.7.3.11 DESCRIBE THRESHOLD

- 6.7.3.12 DESCRIBE USER

- 6.7.4 DROP

- 6.7.4.1 DROP ALERTHISTORY

- 6.7.4.2 DROP DBSERVER

- 6.7.4.3 DROP ROLE

- 6.7.4.4 DROP THRESHOLD

- 6.7.4.5 DROP USER

- 6.7.5 GRANT

- 6.7.5.1 GRANT PRIVILEGE

- 6.7.5.2 GRANT ROLE

- 6.7.6 HELP

- 6.7.7 LIST

- 6.7.7.1 LIST ALERTDEFINITION

- 6.7.7.2 LIST ALERTHISTORY

- 6.7.7.3 LIST DBSERVER

- 6.7.7.4 LIST DIAGPACK

- 6.7.7.5 LIST IBPORT

- 6.7.7.6 LIST LUN

- 6.7.7.7 LIST METRICCURRENT

- 6.7.7.8 LIST METRICDEFINITION

- 6.7.7.9 LIST METRICHISTORY

- 6.7.7.10 LIST PHYSICALDISK

- 6.7.7.11 LIST ROLE

- 6.7.7.12 LIST THRESHOLD

- 6.7.7.13 LIST USER

- 6.7.8 REVOKE

- 6.7.8.1 REVOKE PRIVILEGE

- 6.7.8.2 REVOKE ROLE

- 6.7.9 SET

- 6.7.10 SPOOL

- 6.7.11 START

7 ExaCLIユーティリティの使用

- 7.1 ExaCLIの概要

- 7.2 ExaCLIの構文

- 7.3 ExaCLIの例

- 7.4 認証

- 7.5 ユーザー管理

- 7.6 ExaCLIとDBMCLI/CellCLIでのコマンドの違い

- 7.7 証明書

- 7.7.1 デフォルトの自己署名証明書の使用

- 7.7.2 CA認証済セキュリティ証明書の使用

- 7.8 URLを使用したリモートからのコマンドの実行

8 exadcliユーティリティの使用

- 8.1 exadcliの概要

- 8.2 exadcliの構文

- 8.3 exadcliの例

A 交換ユニット

- A.1 修理カテゴリの理解

- A.2 法規制および認定規格に対するコンプライアンス

- A.2.1 電気・電子機器における特定有害物質の欧州の使用制限指令の準拠

- A.3 ディスク・コントローラのバッテリ

- A.3.1 データベース・サーバーのバッテリの監視

- A.3.2 ディスク・コントローラのバッテリの交換

- A.4 F20 PCIeエネルギー・ストレージ・モジュール

- A.4.1 フラッシュESMの交換

- A.5 LEDステータスの説明

- A.5.1 Oracle Server X6-2 Oracle Database ServerのLED

- A.5.2 Oracle Server X5-2 Oracle Database ServerのLED

- A.5.3 Sun Server X4-2 Oracle Database ServerのLED

- A.5.4 Sun Server X3-2 Oracle Database ServerのLED

- A.5.5 Sun Fire X4170 M2 Oracle Database ServerのLED

- A.5.6 Sun Fire X4170 Oracle Database ServerのLED

- A.5.7 Oracle Server X5-8およびX6-8 Oracle Database ServerのLED

- A.5.8 Sun Server X4-8 Oracle Database ServerのLED

- A.5.9 Sun Server X2-8 Oracle Database ServerのLED

- A.5.10 Sun Fire X4800 Oracle Database ServerのLED

- A.5.11 Exadata Storage Server X5-2 Server

- A.5.12 Exadata Storage Server X4-2L Server

- A.5.13 Exadata Storage Server X3-2 Server

- A.5.14 Sun Fire X4270 M2 Serverを使用したExadata Storage Server

- A.5.15 Sun Fire X4275 Serverを使用したExadata Storage ServerのLED

- A.5.16 Sun Flash Accelerator F20 PCIeカードのLED

- A.5.17 Sun Datacenter InfiniBand Switch 36スイッチのLED

- A.6 Oracle Database Serverの部品

- A.6.1 Oracle Server X6-2 Oracle Database Serverの部品

- A.6.2 Oracle Server X5-2 Oracle Database Serverの部品

- A.6.3 Sun Server X4-2 Oracle Database Serverの部品

- A.6.4 Sun Server X3-2 Oracle Database Serverの部品

- A.6.5 Sun Fire X4170 M2 Oracle Database Serverの部品

- A.6.6 Sun Fire X4170 Oracle Database Serverの部品

- A.6.7 Oracle Server X5-8およびX6-8 Oracle Database Serverの部品

- A.6.8 Sun Server X4-8 Oracle Database Serverの部品

- A.6.9 Sun Server X2-8 Oracle Database Serverの部品

- A.6.10 Sun Fire X4800 Oracle Database Serverの部品

- A.7 Exadata Storage Serverの部品

- A.7.1 High Capacity Exadata Storage Server X6-2 Serverの部品

- A.7.2 Extreme Flash Exadata Storage Server X6-2 Serverの部品

- A.7.3 High Capacity Exadata Storage Server X5-2 Serverの部品

- A.7.4 Extreme Flash Exadata Storage Server X5-2 Serverの部品

- A.7.5 Exadata Storage Server X4-2L Serverの部品

- A.7.6 Exadata Storage Server X3-2L Serverの部品

- A.7.7 Sun Fire X4270 M2 Serverを使用したExadata Storage Serverの部品

- A.7.8 Sun Fire X4275 Serverを使用したExadata Storage Serverの部品

- A.8 InfiniBandスイッチの部品

- A.9 Ciscoスイッチの部品

- A.10 KVMスイッチおよびKMMトレイの部品

- A.11 配電ユニットの部品

- A.12 Oracle Exadataラックのケーブルおよびケーブル・アクセサリ

B ExaCLIエラー・メッセージ

C Oracle Exadata Database MachineおよびOracle Exadataラックのエラー・メッセージ

- C.1 汎用アラート・メッセージ: HALRT-00001 - HALRT-00500

- C.2 温度アラート・メッセージ: HALRT-00513 - HALRT-00600

- C.3 ファン・アラート・メッセージ: HALRT-00616 - HALRT-00700

- C.4 電源/電力変換装置アラート・メッセージ: HALRT-00717 - HALRT-00800

- C.5 ネットワーク・アラート・メッセージ: HALRT-00912 - HALRT-01000

- C.6 ハード・ディスクおよびフラッシュ・ディスク・アラート・メッセージ: HALRT-01015 - HALRT-01200

- C.7 アクセラレータ/コントローラ・アラート・メッセージ: HALRT-01209 - HALRT-01300

- C.8 電圧アラート・メッセージ: HALRT-01301 - HALRT-01400

- C.9 物理ディスク・アラート・メッセージ: HALRT-01401 - HALRT-01500

- C.10 Exadata Storage Serverの自動サービス・リクエスト・アラート・メッセージ: HALRT-02001 - HALRT-02013

- C.11 HDDコントローラのバッテリ・アラート・メッセージ: HALRT-02101 - HALRT-02200

- C.12 USBアラート・メッセージ: HALRT-02401 - HALRT-02404

- C.13 アラート・メッセージの汎用処理: HALRT-10001 - HALRT-10500

- C.14 アラート・メッセージの汎用処理: HALRT-10503 - HALRT-11000

- C.15 アラート・メッセージの汎用処理: HALRT-11001 - HALRT-11100

- C.16 Oracle Exadata Database Machineコマンドライン・インタフェース・エラー・メッセージ

- C.16.1 エラー・メッセージ: DBM-00001 - DBM-00500

- C.16.2 エラー・メッセージ: DBM-10001 - DBM-10500

- C.17 Oracleサポート・サービスへの連絡

索引

例の一覧

- 例1-1 dcliユーティリティを使用したOracle Exadataラックの電源切断

- 1-2 Exadata Storage Server SNMPトラップの例

- 1-3 Oracle Database Server SNMPトラップ

- 1-4 ストレージ・セルのレスキュー計画

- 1-5 データベース・サーバーのレスキュー計画

- 1-6 セルのレスキュー計画スクリプトの作成

- 1-7 データベース・サーバーのレスキュー計画スクリプトの作成

- 2-1 dbnodeupdate.shユーティリティの実行

- 2-2 yum HTTPリポジトリとのpatchmgrの使用

- 2-3 yumの圧縮ISOリポジトリとのpatchmgrの使用

- 2-4 yum HTTPリポジトリを使用したローリング更新

- 2-5 yumの圧縮ISOリポジトリを使用した非ローリング更新

- 4-1 Ciscoスイッチでのタイムゾーンの設定

- 5-1 本番システム・ソフトウェアのメンテナンス計画

- 5-2 本番システム・ソフトウェアの更新の少ないメンテナンス計画

- 5-3 開発およびテスト・システム・ソフトウェアのメンテナンス計画

- 5-4 ストレージ・サーバー更新の前提条件チェックの実行後のストレージ・サーバーの更新

- 5-5 ローリング形式でのストレージ・サーバーの更新

- 5-6 複数のストレージ・サーバーの一度での更新

- 5-7 データベース・サーバーのバックアップ後の更新の実行

- 5-8 YUMリポジトリのISOイメージを使用した更新の実行

- 5-9 YUMリポジトリのHTTPの場所を使用した更新の実行

- 5-10 ロールバックの実行

- 6-1 特定の属性でのMETRICHISTORYの表示

- 6-2 メトリック定義の表示

- 6-3 現在のメトリック値の表示

- 6-4 メトリック履歴の値の表示

- 6-5 データベース・サーバーのメトリックの表示

- 6-6 ALERTHISTORY属性の変更

- 6-7 snmpSubscriberのasrmPortの設定

- 6-8 自動診断パックのアップロードの有効化と無効化

- 6-9 データベース・サーバーへの電子メール通知の構成

- 6-10 データベース・サーバー上の電子メール設定の確認

- 6-11 電子メールのメッセージの形式の変更

- 6-12 データベース・サーバー上のSNMP設定の確認

- 6-13 電子メール・アラートのタイプの指定

- 6-14 データベース・サーバー・サービスの起動および停止

- 6-15 データベース・サーバーLEDの設定

- 6-16 保留コア数の設定

- 6-17 アクティブ・コア数の増加

- 6-18 syslogconf属性の使用

- 6-19 ルールの追加および検証

- 6-20 すべてのsyslog.confルールの削除

- 6-21 IBPORT属性の変更

- 6-22 しきい値の属性の変更

- 6-23 ALTER USERコマンドの使用

- 6-24 interconnectN属性のDBSERVERオブジェクトへの設定

- 6-25 packStartTimeでの「now」の使用

- 6-26 継続時間の指定

- 6-27 ロールの作成

- 6-28 しきい値の作成

- 6-29 ユーザーの作成

- 6-30 ALERTDEFINITIONオブジェクトの説明

- 6-31 ALERTHISTORYオブジェクトの説明

- 6-32 DBSERVERオブジェクトの説明

- 6-33 IBPORTオブジェクトの説明

- 6-34 LUNオブジェクトの説明

- 6-35 METRICCURRENTオブジェクトの説明

- 6-36 METRICDEFINITIONオブジェクトの説明

- 6-37 METRICHISTORYオブジェクトの説明

- 6-38 データベース・サーバーのハード・ドライブ上のPHYSICALDISKオブジェクトの説明

- 6-39 ROLEオブジェクトの説明

- 6-40 THRESHOLDオブジェクトの説明

- 6-41 USERオブジェクトの説明

- 6-42 データベース・サーバーのアラート履歴の削除

- 6-43 データベース・サーバーの削除

- 6-44 ロールの削除

- 6-45 しきい値の削除

- 6-46 ユーザーの削除

- 6-47 ロールへの権限の付与

- 6-48 すべての属性とオプションのロールへの付与

- 6-49 指定のアクション、オブジェクトおよび属性のすべてのオプションの付与

- 6-50 指定のアクション、オブジェクトおよびオプションのすべての属性の付与

- 6-51 ユーザーへのロールの付与

- 6-52 HELPコマンドを使用したヘルプ・テキストの表示

- 6-53 ALERTDEFINITIONの属性の表示

- 6-54 ALERTHISTORYの属性の表示

- 6-55 DBSERVERの属性の表示

- 6-56 rescuePlan属性の表示

- 6-57 「list diagpack」コマンドの出力

- 6-58 DETAILオプション付きの「list diagpack」コマンドの出力

- 6-59 IBPORTの属性の表示

- 6-60 LUNの属性の表示

- 6-61 METRICCURRENTの属性の表示

- 6-62 METRICDEFINITIONの属性の表示

- 6-63 NameおよびCollectionTime属性を使用したMETRICHISTORYの表示

- 6-64 ds_cput属性のMETRICHISTORYの表示

- 6-65 物理ディスクの属性の表示

- 6-66 ロールの表示

- 6-67 しきい値の属性の表示

- 6-68 LIST USERコマンドの使用

- 6-69 権限の取消し

- 6-70 ユーザーからのロールの取消し

- 6-71 SETコマンドを使用した日付形式の設定

図一覧

- 1-1 左パネルのExaWatcherメニュー

- 1-2 IOサマリー・チャート

- 1-3 範囲セレクタが表示されているIOサマリー・チャート

- 1-4 IO詳細チャート

- 1-5 CPUチャート

- 1-6 CPU詳細チャート

- 1-7 セル・サーバー・チャート

- 1-8 アラート履歴

- 2-1 OEDAのクラスタ定義ページ

- 2-2 OEDAの「クラスタ」ページ

- 2-3 Oracle Virtual EnvironmentのNICレイアウト

- 2-4 VLANタグ付けをしたOracle Virtual EnvironmentのNICレイアウト

- 2-5 クラスタ間でInfiniBandネットワーク分離がないOracle Exadata上のOracle VM Oracle RACクラスタ

- 2-6 InfiniBandパーティションを使用してクラスタ間でInfiniBandネットワーク分離があるOracle Exadata上のOracle VM Oracle RACクラスタ

- 2-7 diagnostics.isoファイルを選択するための「ストレージ・デバイスの追加」ダイアログを表示するILOM Webインタフェース

- 2-8 アクティブ-アクティブ・システムにおいて、両方のiSCSIデバイスに接続するマルチパス・デバイス

- 2-9 Oracle VM Oracle RACクラスタ上のquorumディスク・デバイス

- A-1 Oracle Server X6-2 Oracle Database Serverの前面図

- A-2 Oracle Server X6-2 Oracle Database Serverの背面図

- A-3 Oracle Server X5-2 Oracle Database Serverの前面図

- A-4 Oracle Server X5-2 Oracle Database Serverの背面図

- A-5 Sun Server X4-2 Oracle Database Serverの前面図

- A-6 Sun Server X4-2 Oracle Database Serverの背面図

- A-7 Sun Server X3-2 Oracle Database Serverの前面図

- A-8 Sun Server X3-2 Oracle Database Serverの背面図

- A-9 Sun Fire X4170 M2 Oracle Database Serverの前面図

- A-10 Sun Fire X4170 M2 Oracle Database Serverの背面図

- A-11 Sun Fire X4170 Oracle Database Serverの前面図

- A-12 Sun Fire X4170 Oracle Database Serverの背面図

- A-13 Oracle Server X5-8 Oracle Database Serverの前面図

- A-14 Oracle Server X5-8 Oracle Database Serverの背面図

- A-15 Sun Server X4-8 Oracle Database Serverの前面図

- A-16 Sun Server X4-8 Oracle Database Serverの背面図

- A-17 Sun Server X2-8 Oracle Database Serverの前面図

- A-18 Sun Server X2-8 Oracle Database Serverの背面図

- A-19 Sun Fire X4800 Oracle Database Serverの前面図

- A-20 Sun Fire X4800 Oracle Database Serverの背面図

- A-21 High Capacity Exadata Storage Server X5-2 Serverの前面図

- A-22 High Capacity Exadata Storage Server X5-2 Serverの背面図

- A-23 Extreme Flash Exadata Storage Server X5-2 Serverの前面図

- A-24 Extreme Flash Exadata Storage Server X5-2 Serverの背面図

- A-25 Exadata Storage Server X4-2L Serverの前面図

- A-26 Exadata Storage Server X4-2L Serverの背面図

- A-27 Exadata Storage Server X3-2L Serverの前面図

- A-28 Exadata Storage Server X3-2L Serverの背面図

- A-29 Sun Fire X4270 M2 Serverを使用したExadata Storage Serverの前面図

- A-30 Sun Fire X4270 M2 Serverを使用したExadata Storage Serverの背面図

- A-31 Sun Fire X4275 Serverの前面図

- A-32 Sun Fire X4275 Serverの背面図

表一覧

- 1-1 Oracle Exadata Database Machine管理の共通管理タスク

- 1-2 Oracle Exadata Database Machineのサーバー・モデル

- 1-3 dbmsrvのユーザー

- 1-4 dbmsrvのグループ

- 1-5 操作時のセルおよびデータベース・ノードの状態

- 1-6 IOStatサマリーの統計

- 1-7 IO統計詳細の統計

- 2-1 キャパシティ・オンデマンドのコア・プロセッサの構成

- 2-2 既存の構成

- 2-3 pkeyインタフェースによって要求される新しいIPアドレスとネットマスク

- 2-4 クラスタ・ノードに対する4回の実行

- 2-5 ストレージ・セルに対する2回の実行

- 2-6 Oracle EXAchkによって実行される監査チェック

- 2-7 Oracle EXAchkのコマンドライン・オプション

- 2-8 データベース・サーバーの更新パス

- 2-9 patchmgrのオプション: 必須オプション

- 2-10 patchmgrのオプション: アクション・オプション

- 2-11 patchmgrのオプション: サポート・オプション

- 2-12 patchmgrのオプション: メール・オプション

- 3-1 Exadata Storage Serverの物理ディスク・ステータス

- 5-1 更新パス

- 5-2 カスタマイズとそのリスク

- 5-3 更新を実行するためのタイムライン

- 5-4 更新を実行するためのタイムライン

- 6-1 Oracle Exadata Storage Server Softwareのオブジェクト・タイプ

- 6-2 属性フィルタでサポートされる演算子

- 6-3 データベース・サーバーのメトリックおよび説明

- 6-4 DESCRIBE ALERTDEFINITIONの属性

- 6-5 DESCRIBE ALERTHISTORYの属性

- 6-6 DESCRIBE DBSERVERの属性

- 6-7 DESCRIBE IBPORTの属性

- 6-8 DESCRIBE LUNの属性

- 6-9 DESCRIBE METRICCURRENTの属性

- 6-10 DESCRIBE METRICDEFINITIONの属性

- 6-11 DESCRIBE METRICHISTORYの属性

- 6-12 DESCRIBE PHYSICALDISKの属性

- 6-13 DESCRIBE ROLEの属性

- 6-14 DESCRIBE THRESHOLDの属性

- 6-15 DESCRIBE USERの属性

- 6-16 SPOOLのオプション

- 7-1 ExaCLIのオプション

- 8-1 exadcliのオプション

- A-1 Oracle Exadataラックの修理カテゴリ

- A-2 Oracle Server X6-2 Oracle Database ServerのLEDステータスの説明

- A-3 LEDに基づいたOracle Server X6-2 Oracle Database Serverのディスク・ステータス

- A-4 Oracle Server X5-2 Oracle Database ServerのLEDステータスの説明

- A-5 LEDに基づいたOracle Server X5-2 Oracle Database Serverのディスク・ステータス

- A-6 Sun Fire X4170 M2 Oracle Database ServerのLEDステータスの説明

- A-7 LEDに基づいたSun Server X4-2 Oracle Database Serverのディスク・ステータス

- A-8 Sun Server X3-2 Oracle Database ServerのLEDステータスの説明

- A-9 LEDに基づいたSun Server X3-2 Oracle Database Serverのディスク・ステータス

- A-10 Sun Fire X4170 M2 Oracle Database ServerのLEDステータスの説明

- A-11 LEDに基づいたSun Fire X4170 M2 Oracle Database Serverのディスク・ステータス

- A-12 Sun Fire X4170 Oracle Database ServerのLEDステータスの説明

- A-13 LEDに基づいたSun Fire X4170 Oracle Database Serverのディスク・ステータス

- A-14 Oracle Server X5-8およびX6-8 Oracle Database ServerのLEDステータスの説明

- A-15 LEDに基づいたOracle Server X5-8およびX6-8 Oracle Database Serverのディスク・ステータス

- A-16 Sun Server X4-8 Oracle Database ServerのLEDステータスの説明

- A-17 LEDに基づいたSun Server X4-8 Oracle Database Serverのディスク・ステータス

- A-18 Sun Server X2-8 Oracle Database ServerのLEDステータスの説明

- A-19 LEDに基づいたSun Server X2-8 Oracle Database Serverのディスク・ステータス

- A-20 Sun Fire X4800 Oracle Database ServerのLEDステータスの説明

- A-21 LEDに基づいたSun Fire X4800 Oracle Database Serverのディスク・ステータス

- A-22 LEDステータスの説明

- A-23 LEDに基づいたExadata Storage Server X5-2 Serverのディスク・ステータス

- A-24 LEDステータスの説明

- A-25 LEDに基づいたExadata Storage Server X4-2L Serverのディスク・ステータス

- A-26 LEDステータスの説明

- A-27 LEDに基づいたExadata Storage Server X3-2 Serverのディスク・ステータス

- A-28 LEDステータスの説明

- A-29 Sun Fire X4270 M2 Serverを使用したExadata Storage ServerのLEDに基づいたディスク・ステータス

- A-30 Sun Fire X4275 Serverを使用したExadata Storage ServerのLEDステータスの説明

- A-31 Sun Fire X4275 Serverを使用したExadata Storage ServerのLEDに基づいたディスク・ステータス

- A-32 Sun Flash Accelerator F20 PCIeカードのLEDステータスの説明

- A-33 Sun Datacenter InfiniBand Switch 36スイッチのLEDステータスの説明

- A-34 Oracle Server X6-2 Oracle Database Serverの交換部品

- A-35 Oracle Server X5-2 Oracle Database Serverの交換部品

- A-36 Sun Server X4-2 Oracle Database Serverの交換部品

- A-37 Sun Server X3-2 Oracle Database Serverの交換部品

- A-38 Sun Fire X4170 M2 Oracle Database Serverの交換部品

- A-39 Sun Fire X4170 Oracle Database Serverの交換部品

- A-40 Oracle Exadata X5-8およびX6-8 Oracle Database Serverの交換部品

- A-41 Sun Server X4-8 Oracle Database Serverの交換部品

- A-42 Sun Server X2-8 Oracle Database Serverの交換部品

- A-43 Sun Fire X4800 Oracle Database Serverの交換部品

- A-44 High Capacity Exadata Storage Server X6-2 Serverの交換部品

- A-45 Extreme Flash Exadata Storage Server X6-2 Serverの交換部品

- A-46 High Capacity Exadata Storage Server X5-2 Serverの交換部品

- A-47 Extreme Flash Exadata Storage Server X5-2 Serverの交換部品

- A-48 Exadata Storage Server X4-2L Serverの交換部品

- A-49 Exadata Storage Server X3-2L Serverの交換部品

- A-50 Sun Fire X4270 M2 Serverを使用したExadata Storage Serverの交換部品

- A-51 Sun Fire X4275 Serverを使用したExadata Storage Serverの交換部品

- A-52 InfiniBandスイッチの交換部品

- A-53 Ciscoスイッチの交換部品

- A-54 KVM/KMMの交換部品

- A-55 配電ユニットの交換部品

- A-56 Oracle Exadataラックの交換ケーブル

はじめに

このガイドでは、Oracle Exadata Database Machineの保守手順について説明します。このガイドには、保守と修理に関する情報、および交換部品の情報が記載されています。

対象読者

このマニュアルは、Oracle Exadata Database Machineのカスタマおよびデータ・センターのサイト計画、サイト構成、Oracle Exadata Database Machineのメンテナンス担当者を対象としています。

ドキュメントのアクセシビリティについて

Oracleのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)を参照してください。

Oracle Supportへのアクセス

サポートを購入したオラクル社のお客様は、My Oracle Supportを介して電子的なサポートにアクセスできます。詳細情報は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info) か、聴覚に障害のあるお客様は (http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs)を参照してください。

関連ドキュメント

Oracle Exadata Database Machineドキュメント・セットに加えて、次のガイドにOracle Exadata Database Machineのハードウェア情報が記載されています。

- Oracle Exadata Database Machineシステム概要

- Oracle Exadata Database Machineセキュリティ・ガイド

- Oracle Exadata Database Machineセーフティおよびコンプライアンス・ガイド、コンプライアンス・モデル番号XD4A

- Oracle Exadata Database Machine拡張およびマルチラック・ケーブリング・ガイド

- Oracle Exadata Database Machineメンテナンス・ガイド

- Sun Fire X4170、X4270およびX4275 Serverサービス・マニュアル(http://docs.oracle.com/cd/E19477-01/820-5830-13/index.html)

- Sun Fire X4170 M2 Serverサービス・マニュアル(http://docs.oracle.com/cd/E19762-01/E22369-02/index.html)

- Sun Fire X4270 M2 Serverサービス・マニュアル(http://docs.oracle.com/cd/E19245-01/E21671/index.html)

- Sun Fire X4800 Serverサービス・マニュアル(http://docs.oracle.com/cd/E19140-01/html/821-0282/index.html)

- Sun Server X2-8 (旧Sun Fire X4800 M2)サービス・マニュアル(http://docs.oracle.com/cd/E20815_01/html/E20819/index.html)

- Sun Server X3-2 (旧Sun Fire X4170 M3)サービス・マニュアル(http://docs.oracle.com/cd/E22368_01/html/E27242/gentextid-14840.html#scrolltoc)

- Sun Server X3-2L (旧Sun Fire X4270 M3)サービス・マニュアル(http://docs.oracle.com/cd/E23393_01/html/E27229/gentextid-14804.html#scrolltoc)

- Sun Server X4-2サービス・マニュアル(http://docs.oracle.com/cd/E36975_01/html/E38045/gentextid-14757.html#scrolltoc)

- Sun Server X4-2Lサービス・マニュアル(http://docs.oracle.com/cd/E36974_01/html/E38145/gentextid-14728.html#scrolltoc)

- Sun Server X4-8サービス・マニュアル(http://docs.oracle.com/cd/E40591_01/html/E40317/index.html)

- Oracle Server X5-2サービス・マニュアル(http://docs.oracle.com/cd/E41059_01/html/E48312/napsm.html)

- Oracle Server X5-2Lサービス・マニュアル(http://docs.oracle.com/cd/E41033_01/html/E48325/cnpsm.html#scrolltoc)

- Oracle Server X6-2サービス・マニュアル(http://docs.oracle.com/cd/E62159_01/html/E62171/index.html)

- Oracle Server X6-2Lサービス・マニュアル(http://docs.oracle.com/cd/E62172_01/html/E62184/index.html)

- Sun Datacenter InfiniBand Switch 36ファームウェア、バージョン2.1のドキュメント(http://docs.oracle.com/cd/E36265_01/index.html)

- Sun Flash Accelerator F20 PCIe Cardユーザーズ・ガイド(http://docs.oracle.com/cd/E19682-01/E21358/index.html)

- Sun Flash Accelerator F40 PCIe Cardユーザーズ・ガイド(http://docs.oracle.com/cd/E29748_01/html/E29741/index.html)

- Sun Flash Accelerator F80 PCIe Cardユーザーズ・ガイド(http://docs.oracle.com/cd/E41278_01/html/E41251/index.html)

- Sun Storage 6 Gb SAS PCIe RAID HBAのドキュメント(http://docs.oracle.com/cd/E19221-01/)

- Oracle Integrated Lights Out Manager (ILOM)のドキュメント(http://www.oracle.com/goto/ilom/docs)

- MIBに関する情報: Cisco Catalyst 4948スイッチのデータ・シート(http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps6021/product_data_sheet0900aecd8017a72e.html)

- MIBに関する情報: Cisco Catalyst 4948Eおよび4948E-Fイーサネット・スイッチのデータ・シート(http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps6021/ps10947/data_sheet_c78-598933.html)

表記規則

このマニュアルでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック体

イタリックは、ユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

$プロンプト

ドル記号($)プロンプトは、oracleユーザーとして実行されるコマンドを示します。

#プロンプト

シャープ(#)プロンプトは、rootユーザーとして実行されるコマンドを示します。

1 一般的な保守情報

この章では、Oracle Exadata Database Machineの一般的な保守について説明します。

- 役割および職責の概要

- Oracle Exadataラックの電源の投入および切断

- 「自動サービス・リクエストの理解」

- Oracle Enterprise Manager Cloud Controlを使用したシステムの監視

- Oracle Configuration Managerを使用したシステムの監視

- コンポーネントのパスワードの変更

- サーバー・モデルの判別

- サーバーの周囲温度の監視

- 「ディスク・コントローラ・バッテリ・バックアップ・ユニットの交換」

- dbmsrvサービスの概要

- dbmsrvのユーザーIDおよびグループIDの変更

- 構成変更中のセルおよびデータベース・ノードの状態

- レスキュー計画

- ExaWatcherチャート

注意:

- 読みやすさを考慮して、Oracle Exadata Database MachineとOracle Exadata Storage拡張ラックの両方に言及する場合、「Oracle Exadataラック」という名前を使用します。

- この章のすべての手順は、Oracle Exadata Database MachineおよびOracle Exadata Storage拡張ラックに適用されます。

関連トピック

- 交換ユニット

- Oracle Exadata Database MachineおよびOracle Exadataラックのエラー・メッセージ

1.1 役割および職責の概要

ほとんどのIT組織には、データベース管理者、システム管理者、ネットワーク管理者およびストレージ管理者のチームがあります。これらの管理者はシステム実装および操作の続行を担当します。Oracle Exadata Database Machine環境では、通常、データベース管理者がシステム管理者のサポートを受けながらOracle Exadata Database Machine管理の主要な役割を担当するようにすると、より効率的かつ効率的になります。これは、Oracle Exadata Database MachineがOracle Databaseを実行するように設計され、管理がOracle DatabaseおよびOracle Exadata Storage Server Softwareに固有であるためです。その他のチームに異なる職責を与えるか、または第2レベルとしてサポートするようにできます。

通常、初期システム・デプロイメントはOracleエンジニアが実行します。データベース管理者の主要職責は通常の操作タスクで開始されます。次の表は、Oracle Exadata Database Machine環境の管理に必要なタスクの一部を示しています。表1-1に、共通管理タスクを示します。

表1-1 Oracle Exadata Database Machine管理の共通管理タスク

タスクまたはイベント

管理者

アクション

パフォーマンスの低下

データベース管理者

システム管理者

Oracle Enterprise Manager Grid Controlからパフォーマンスのしきい値を超えたというアラートを受け取ります。

すべてのサーバーのシステム・パフォーマンス、CPU、メモリーおよびI/Oで異常な傾向を確認します。

データベース・パフォーマンス、待機イベント、ロック、並列処理および実行計画を確認します。

パッチ適用またはアップグレード

データベース管理者

システム管理者

Oracle Exadata Storage Server Softwareのパッチまたはアップグレード、およびSun Datacenter InfiniBand Switch 36スイッチのファームウェアのアップグレードを適用します。

Oracle Databaseのパッチ、グリッド・インフラストラクチャのパッチまたはアップグレードを適用します。

システム停止または障害

データベース管理者

システム管理者

Integrated Lights Out Manager(ILOM)に接続し、現在のシステム状態を確認し、ハードウェアの問題点の識別またはシステムの再起動を行い、およびログを確認して根本的な原因分析を行います。

残存インスタンスでエラーのチェック、残存インスタンスのパフォーマンスの監視およびアプリケーション機能が損われていないことの確認を行います。

疑いのあるネットワークの問題点

データベース管理者

システム管理者

ネットワーク・インタフェースでエラーまたは削除されたパケットを検出し、再起動したスイッチがあるかどうかをチェックし、必要に応じてネットワーク管理チームにエスカレートします。

データベース側のパフォーマンスを検査して影響を評価します(影響がある場合)。

データベースのバックアップ

データベース管理者

システム管理者

データベースのバックアップ・ルーチンを実行し、データベース・サーバーのバックアップが完了していることを確認します。

障害ディスクの交換

データベース管理者

システム管理者

ハードウェア交換に関するアラートを受け取り、自動サービス・リクエスト(ASR)がサービス・リクエストを開いたことを確認し、オペレータがデータ・センターのフィールド・サービス技術者にドライブの交換またはスペアのドライブの提供を許可していることを確認します。

通常、発生した問題の主担当は個人またはグループです。システムに問題が発生すると、この担当者または担当するグループがOracle Enterprise Manager Grid Control、ヘルプ・デスクまたは操作チームから最初に連絡を受けます。Oracle Exadata Database Machineの場合、通常、主に連絡を担当するのはデータベース管理者です。データベース管理者が問題解決に別のチームのサポートを必要とする場合は、協力して問題を解決します。問題の担当者を明確にしておく必要があります。

1.1.1 Oracle Exadata Database Machineでの管理面の差異の理解

Oracle Exadata Database Machineのサーバー上でのほとんどの管理タスクは、従来のデータベース・サーバーおよびストレージ・サーバーと似ています。ただし、違いがいくつかあります。

次のリストは、Oracle Exadata Database Machineサーバーの相違点と例外を示しています。

- Oracle Exadata Database Machineのデータベース・サーバー、Sun Datacenter InfiniBand Switch 36スイッチおよびその他のコンポーネントの構成は、テストおよびパフォーマンス基準に基づいて設定されています。会社の方針またはその他の理由により、データベース・サーバーのファームウェアまたはカーネル・パラメータなどの構成設定を変更する場合は、Oracle Exadata Database Machineに対する影響の可能性を確認する必要があります。

- サーバーを不正に再起動すると、データベースが壊れる可能性があります。ストレージ・サーバーには、サーバーを再起動する前にグリッド・ディスクをオフラインにする、一度に複数のサーバーを再起動できないなど、データベースの破壊を最小化するために従う必要がある特別な手順とガイドラインがあります。

- Exadata Storage Serverはデータベース・サーバーと同じように変更できません。NTPサーバーまたはDNSサーバーなどのネットワークの変更は、ipconfユーティリティを使用して行います。ネットワークの変更は構成ファイルを編集して手動で行うことはできません。さらに、ストレージ・サーバーにソフトウェアまたは追加パッケージをインストールすることはできません。この制約にはソフトウェアの監視が含まれます。Exadata Storage Serverシステムのアップデートは、Oracle Exadata Storage Server Softwareのアップグレードで行われます。

- Exadata Storage Serverのバックアップは不要で、自己保守される内部USBドライブがあり、セルのリカバリにこれを使用できます。バックアップ・クライアントはストレージ・サーバーにインストールできません。

- Exadata Storage Serverを使用するOracle Real Application ClusterデータベースのOracle待機イベントには、名前に%cell%が付いたイベントを含めることができます。これらのイベントは、ストレージ・サーバー関連のものです。

- V$CELLビューには、Exadata Storage Serverを使用するデータベースの行が含まれています。

- Oracle Automatic Storage Management (Oracle ASM)ディスクのパス名の形式は、o/cell_ip_address/cell_griddisk_nameで、たとえば、次のようになります。

o/192.168.10.1/data_CD_01_dm01cel01

- SQL計画にstorageを含めると、操作の一部をExadata Storage Serverに肩がわりさせて負荷を軽減できることを示すことができます。

- バックアップやリカバリなどの操作では、Oracle Recovery Manager(RMAN)が使用され、バックアップおよびリカバリ用のすべてのデータは引き続きデータベース・インスタンスを経由します。RMANのバックアップ・クライアントをOracle Exadata Database Machineのデータベース・サーバーにインストールし、従来の環境の場合と同じようにエンタープライズ・バックアップ・ソリューションとの統合を容易にする必要があります。

- 開発、テストおよび品質保証用の1つ以上の非本稼働環境のデプロイの実行は、Oracle Exadata Database Machine環境にも適用されます。

関連項目:

- Exadata Storage Serverのシャットダウン

- ipconfユーティリティの詳細は、『Oracle Exadata Storage Server Softwareユーザーズ・ガイド』を参照してください

1.2 Oracle Exadataラックの電源の投入および切断

この項には次のトピックが含まれます:

- 非緊急時の電源の投入と切断の手順

- 緊急時の電源切断の考慮事項

- 注意事項と警告

1.2.1 非緊急時の電源の投入と切断の手順

この項では、Oracle Exadataラックのコンポーネントの電源を正しく投入および切断する手順を説明します。この項では、次の項目について説明します。

- Oracle Exadataラックの電源の投入

- Oracle Exadataラックの電源の切断

- ネットワーク・スイッチの電源の投入および切断

1.2.1.1 Oracle Exadataラックの電源の投入

Exadata Storage Serverの電源を投入するには、サーバー前面にある電源ボタンを押すか、ILOMインタフェースにログインしてシステムに電源を投入します。データベース・サーバーの電源が投入され、オペレーティング・システムがブートすると、Oracle Clusterwareがインストールされている場合にOracle Clusterwareが自動的に起動します。Oracle Clusterwareは、自動的に起動する構成のすべてのリソースを起動します。

電源投入の手順は次のとおりです。

1. ラック(スイッチを含む)。

Exadata Storage Serverの起動前に、スイッチに数分間電力が投入されて電源投入の構成が完了していることを確認してください。

2. Exadata Storage Server。

データベース・サーバーの起動前に、すべてのExadata Storage Serverのブート・プロセスが完了していることを確認してください。すべてのサービスの起動に5から10分かかる場合があります。

3. データベース・サーバー。

1.2.1.1.1 ILOMを使用したリモート・サーバーの電源投入

ILOMインタフェースを使用して、サーバーの電源をリモートで投入できます。

Webコンソール、コマンドライン・インタフェース(CLI)、IPMIまたはSNMPを使用して、ILOMにアクセスできます。たとえば、IPMIを使用してサーバーdm01cel01に電源を投入するには、電源を投入するサーバーのILOMのホスト名がdm01cel01-ilomの場合、IPMItoolがインストールされているサーバーから次のコマンドを実行します。

# ipmitool -I lanplus -H dm01cel01-ilom -U root chassis power on

前述のコマンドにより、システムのパスワードの入力が要求されます。

関連トピック

- Oracle Integrated Lights Out Manager (ILOM)のドキュメント

1.2.1.2 Oracle Exadataラックの電源の切断

Oracle Exadataラックの電源切断順序は、次のとおりです。

1. データベース・サーバー(Oracle Exadata Database Machineのみ)。

2. Exadata Storage Server。

3. ラック(スイッチを含む)。

1.2.1.2.1 データベース・サーバーの電源切断

データベース・サーバーの電源を切断する場合、データベース・サーバーを再起動または停止する前にOracle Clusterwareを停止する必要があります。次のコマンドを使用して、Oracle Clusterwareを停止します。

crsctl stop cluster

次の手順は、データベース・サーバーの推奨されている停止手順になります。

1. 次のコマンドを使用して、Oracle Clusterwareを停止します。

# GRID_HOME/grid/bin/crsctl stop cluster

crsctl stop clusterコマンドの発行後にOracle Clusterwareで管理されるリソースが実行されている場合、コマンドが失敗します。-fオプションを使用してすべてのリソースを無条件で停止し、Oracle Clusterwareを停止します。

2. 次のコマンドを使用して、オペレーティング・システムを停止します。

# shutdown -h now

1.2.1.2.2 Exadata Storage Serverの電源切断

Linux shutdownコマンドを使用して、Exadata Storage Serverの電源を切断し、再起動します。次のコマンドを使用して、Exadata Storage Serverを直接停止します。

# shutdown -h now

Exadata Storage Serverの電源を切断すると、すべてのストレージ・サービスが自動的に停止します。

次のコマンドを使用して、Exadata Storage Serverを直接再起動します。

# shutdown -r now

Exadata Storage Serverの電源を切断する際は、次の点に注意してください。

- 複数のExadata Storage Serverを停止する前に、すべてのデータベースおよびOracle Clusterwareプロセスを停止する必要があります。

- 1つのExadata Storage Serverの電源を切断しても、実行中のデータベース・プロセスまたはOracle ASMに影響しません。

- Exadata Storage Serverの電源切断または再起動により、データベースの可用性に影響を与える場合があります。

- shutdownコマンドを使用して、データベース・サーバーの電源切断または再起動を実行できます。

関連項目:

- Exadata Storage Serverの電源を切断してデータベースまたはOracle Clusterwareを稼働したままにする場合は、「Exadata Storage Serverのシャットダウン」を参照してください。

- 詳細は、SHUTDOWN(8)マニュアル・ページを参照してください。

1.2.1.2.3 複数のサーバーの一括電源切断

dcliユーティリティを使用すると、複数のサーバーで同時にshutdownコマンドを実行できます。停止するサーバーでdcliユーティリティを実行しないでください。たとえば、dcliユーティリティを使用してすべてのExadata Storage Serverを停止するには、データベース・サーバーからコマンドを実行します。次に、コマンドの構文を示します。

# dcli -l root -g group_name shutdown -h now

前述の構文のgroup_nameは、すべてのExadata Storage Serverリストのcell_groupまたはデータベース・サーバー・リストのdbs_groupを含むファイルです。

次のコマンドは、同時にすべてのExadata Storage Serverを停止する構文を示しています。

# dcli -l root -g cell_group shutdown -h now

例1-1に、dcliユーティリティを使用して同時に複数のサーバーを停止する場合のOracle Exadataラックの電源切断手順を示します。コマンドはデータベース・サーバーから実行されます。

例1-1 dcliユーティリティを使用したOracle Exadataラックの電源切断

1. 次のコマンドを使用して、すべてのデータベース・サーバーのOracle Clusterwareを停止します。

# GRID_HOME/grid/bin/crsctl stop cluster -all

2. 次のコマンドを使用して、すべてのリモート・データベース・サーバーを停止します。

# dcli -l root -g remote_dbs_group shutdown -h now

前述のコマンドのremote_dbs_groupは、すべてのリモート・データベース・サーバーのリストを含むファイルです。

3. 次のコマンドを使用して、すべてのExadata Storage Serverを停止します。

# dcli -l root -g cell_group shutdown -h now

前述のコマンドのcell_groupは、すべてのExadata Storage Serverのリストを含むファイルです。

4. 次のコマンドを使用して、ローカル・データベース・サーバーを停止します。

shutdown -h now

5. ラックから電源を切断します。

1.2.1.3 ネットワーク・スイッチの電源の投入および切断

ネットワーク・スイッチには電源スイッチがありません。配電ユニット(PDU)やデータ・センターのブレーカを介して電力が投入されなくなると、これらの電源は切断されます。

1.2.2 緊急時の電源切断の考慮事項

緊急時には、Oracle Exadataラックの電源をすぐに停止してください。次のような緊急時に、Oracle Exadataラックの電源切断が必要となります。

- 地震、洪水、ハリケーン、竜巻、またはサイクロンなどの自然災害の場合。

- マシンから異常な騒音、臭い、または煙が発生した場合。

- 人の安全を脅かす場合。

1.2.2.1 緊急時の電源切断の手順

緊急時にOracle Exadataラックの電源切断手順を実行するには、ブレーカの電源を切断するか、コンピュータ・ルームの緊急時の電源切断スイッチを切ってください。その後、Oracleサポート・サービスに連絡してマシンの電源を元に戻します。

1.2.2.2 緊急時の電源切断スイッチ

緊急時の電源切断(EPO)スイッチは、5分より長く750を超えるボルトアンペアを供給できるバッテリがコンピュータ機器に含まれる場合に必要になります。このようなバッテリがシステムで使用される場合、そのシステムには、サイトのEPOスイッチまたはリレーに接続するための内部EPOハードウェアがあります。EPOスイッチを使用すると、Oracle Exadataラックに電力が投入されなくなります。

1.2.3 注意事項と警告

Oracle Exadataラックには、次の注意事項と警告が適用されます。

- この製品の高圧電力を使用する部分には触れないでください。触れた場合、重傷を負う可能性があります。

- 緊急時以外は、Oracle Exadataラックの電源を切断しないでください。緊急時は、「緊急時の電源切断の手順」に従ってください。

- キャビネットの前のドアと後のドアを閉めた状態にしてください。扉を閉めないと、システム障害や、ハードウェア・コンポーネントの破損が生じることがあります。

- 空気が適切に循環し、コンポーネントが過熱しないように、キャビネットの上部、前部および後部に障害物がない状態にしてください。

- 付属のハードウェア以外は使用しないでください。

1.3 「自動サービス・リクエストの理解」

自動サービス・リクエスト(ASR)は、特定のOracle Exadataラックのハードウェアに障害が発生すると自動的にサービス・リクエストを開くように設計されています。

この機能を有効にするには、ハードウェア障害の遠隔測定情報をASRマネージャ・ソフトウェアに送信するように、Oracle Exadataラック・コンポーネントを構成する必要があります。このサービスでは、ディスクやフラッシュ・カードなどのExadata Storage ServerおよびOracle Database Serverのコンポーネントが対象となります。

Oracle Exadataラックの接続、およびHTTPSまたはHTTPSプロキシを使用したアウトバウンド・インターネット接続が可能なサーバーに、ASRマネージャをインストールする必要があります。Oracle Exadataラックの外部のサーバーにASRマネージャをインストールすることをお薦めします。推奨理由の一部は、次のとおりです。

- ASRマネージャがインストールされたサーバーがダウンすると、ASRマネージャはOracle Exadata Database Machineのその他のコンポーネントには使用できません。設置場所にASRを使用するOracle Exadata Database Machineが複数ある場合、これは非常に重要です。

- サービス・リクエスト(SR)を送信するには、サーバーがインターネットにアクセスできる必要があります。

注意:

ASRでは管理ネットワークのみを使用できます。ASRを実行できるように管理ネットワークが設定されていることを確認してください。

ハードウェアの問題が検出されると、ASRマネージャはサービス・リクエストをOracleサポート・サービスに送信します。多くの場合、データベース管理者が問題を認識する前に、Oracleサポート・サービスで問題の解決作業を開始できます。

ASRを使用する前に、次を設定する必要があります。

- Oracle Premier Support for SystemまたはOracle/Sun Limited Warranty

- Oracle Exadataラックの技術担当窓口

- Oracle Exadataラック部品の有効な発送先

電子メールメッセージが技術担当窓口に送信され、アクティブ化されたアセットでサービス・リクエストの作成が通知されます。次に、ディスク障害が発生した場合にASRマネージャに送信されるSimple Network Management Protocol (SNMP)トラップの例を示します。

注意:

- ASRはコンポーネントの障害のみに適用されます。すべてのコンポーネント障害が対象となるわけではありませんが、ディスク、ファン、電源などのほとんどの共通コンポーネントは対象となります。

- ASRは、SMTP、SNMPアラートなど、カスタマ・データ・センター内のその他の監視メカニズムに代わるものではありません。ASRは、交換ハードウェアの発送を促進および簡素化する補完メカニズムです。ASRは、高優先度システムのダウンタイム・イベントに使用することはできません。高優先度イベントの場合は、Oracleサポート・サービスまで直接ご連絡ください。

- サービス・リクエストが自動的に送信されない場合があります。これは、SNMPプロトコルの低い信頼性やASRマネージャの接続解除により発生する可能性があります。システムの障害について継続的に監視して、サービス・リクエストが自動的に提出されたことを示す通知が送られてこない場合は、Oracleサポート・サービスに問い合せることをお薦めします。

- ASRは、リリース11.2.3.3.0以上を実行しているOracle Exadata Database Machineの、ファームウェア・リリース2.1.2以上のSun Datacenter InfiniBand Switch 36スイッチを監視できます。フィールド・エンジニアによるスイッチへのエンタイトルメント・シリアル番号の設定が必要になる場合があります。

例1-2 Exadata Storage Server SNMPトラップの例

この例は、Exadata Storage Serverディスク障害のSNMPトラップを示しています。対応するハードウェア・アラート・コードは強調表示されています。

2011-09-07 10:59:54 server1.example.com [UDP: [192.85.884.156]:61945]:
RFC1213-MIB::sysUpTime.0 = Timeticks: (52455631) 6 days, 1:42:36.31
SNMPv2-SMI::snmpModules.1.1.4.1.0 = OID: SUN-HW-TRAP-MIB::sunHwTrapHardDriveFault
SUN-HW-TRAP-MIB::sunHwTrapSystemIdentifier = STRING: Sun Oracle Database Machine
1007AK215C
SUN-HW-TRAP-MIB::sunHwTrapChassisId = STRING: 0921XFG004
SUN-HW-TRAP-MIB::sunHwTrapProductName = STRING: SUN FIRE X4270 M2 SERVER
SUN-HW-TRAP-MIB::sunHwTrapSuspectComponentName = STRING: SEAGATE ST32000SSSUN2.0T;
Slot: 0SUN-HW-TRAP-MIB::sunHwTrapFaultClass = STRING: NULL
SUN-HW-TRAP-MIB::sunHwTrapFaultCertainty = INTEGER: 0
SUN-HW-TRAP-MIB::sunHwTrapFaultMessageID = STRING: HALRT-02001
SUN-HW-TRAP-MIB::sunHwTrapFaultUUID = STRING: acb0a175-70b8-435f-9622-38a9a55ee8d3
SUN-HW-TRAP-MIB::sunHwTrapAssocObjectId = OID: SNMPv2-SMI::zeroDotZero
SUN-HW-TRAP-MIB::sunHwTrapAdditionalInfo = STRING: Exadata Storage Server:
cellname  Disk Serial Number:   E06S8K
server1.example.com failure trap.

例1-3 Oracle Database Server SNMPトラップ

この例は、Oracle Database Serverのディスク障害からのSNMPトラップを示しています。対応するハードウェア・アラート・コードは強調表示されています。

2011-09-09 10:59:54 dbserv01.example.com [UDP: [192.22.645.342]:61945]:
RFC1213-MIB::sysUpTime.0 = Timeticks: (52455631) 6 days, 1:42:36.31
SNMPv2-SMI::snmpModules.1.1.4.1.0 = OID: SUN-HW-TRAP-MIB::sunHwTrapHardDriveFault
SUN-HW-TRAP-MIB::sunHwTrapSystemIdentifier = STRING: Sun Oracle Database Machine
1007AK215C
SUN-HW-TRAP-MIB::sunHwTrapChassisId = STRING: 0921XFG004
SUN-HW-TRAP-MIB::sunHwTrapProductName = STRING: SUN FIRE X4170 M2 SERVER
SUN-HW-TRAP-MIB::sunHwTrapSuspectComponentName = STRING: HITACHI H103030SCSUN300G
Slot: 0SUN-HW-TRAP-MIB::sunHwTrapFaultClass = STRING: NULL
SUN-HW-TRAP-MIB::sunHwTrapFaultCertainty = INTEGER: 0
SUN-HW-TRAP-MIB::sunHwTrapFaultMessageID = STRING: HALRT-02007
SUN-HW-TRAP-MIB::sunHwTrapFaultUUID = STRING: acb0a175-70b8-435f-9622-38a9a55ee8d3
SUN-HW-TRAP-MIB::sunHwTrapAssocObjectId = OID: SNMPv2-SMI::zeroDotZero
SUN-HW-TRAP-MIB::sunHwTrapAdditionalInfo = STRING: Exadata Database Server: db03
Disk Serial Number: HITACHI H103030SCSUN300GA2A81019GGDE5E
dbserv01.example.com failure trap.

関連トピック

- Oracle Exadata Database Machine Oracle Auto Service Requestクイック・インストレーション・ガイド

1.3.1 ASRのインストールおよび構成

ASRは、Oracle SolarisまたはLinuxを実行しているスタンドアロン・サーバーにインストールすることをお薦めします。

インストールが完了したら、Oracle Exadata Database Machineのサーバーに対して障害の遠隔測定情報の送信先を構成します。Oracle Exadata Database Machineのサーバーは、初期構成時に設定できます。Oracle Exadata Database Machine Deployment Assistantで構成情報を収集し、サーバーを構成します。

注意:

ILOMアラート設定を構成する場合、ルール・リストの上部にあるルールを削除しないでください。新しいルールを追加するには、ルール・リストの一番下にルールを入力します。

- 初期構成後にASRをインストールして構成する方法の詳細は、『Oracle Auto Service Request Oracle Exadata Database Machineクイック・インストレーション・ガイド』に記載されているインストールおよび構成の情報を参照してください。

関連項目:

- Oracle Exadata Database Machine Oracle Auto Service Requestクイック・インストレーション・ガイド

- Oracle Exadata Deployment AssistantのASRの構成ページの詳細は、『Oracle Exadata Database Machineインストレーションおよび構成ガイド』を参照してください

- Oracle Auto Service Requestのユーザー・ドキュメント(http://www.oracle.com/technetwork/systems/asr/documentation/index.html)

- Oracleサポート・サービスへの連絡の詳細は、「Oracleサポート・サービスへの連絡」を参照してください。

1.4 Oracle Enterprise Manager Cloud Controlを使用したシステムの監視

最初のデータベース・サーバーにOracle Enterprise Manager Cloud Controlエージェントを配置したOracle Enterprise Manager Cloud ControlおよびExadata Storage ServerのOracle System Monitoring Plug-Inを使用して、Oracle Exadata Database Machineを監視できます。各Exadata Storage Serverは、Oracle Enterprise Manager Cloud Controlの単一のターゲットとして監視されます。Oracle Exadata Database Machineのシステム・ダッシュボードにサーバーがグループ化されるので、グループ単位で監視できます。Oracle Enterprise Managerのセットアップの自動化キットのエージェント・キットでは、単純な1つのコマンドを使用して、Oracle Management Agentsおよび必要なすべてのプラグインをOracle Exadata Databaseの一部であるすべての計算ノードにデプロイできます。

Exadata Storage Serverメトリックは、管理サーバー(MS)によって収集および管理されます。Oracle Enterprise Manager Cloud Controlと一緒に使用すると、Oracle Enterprise Manager Cloud Controlメトリックとしてメトリックが示されます。

SNMPにより、すべてのExadata Storage ServerアラートがOracle Enterprise Manager Cloud Controlに配信されます。Exadata Storage ServerとOracle Enterprise Manager Cloud Control間の通信は、Exadata Storage ServerのOracle System Monitoring Plug-Inで実行されます。Exadata Storage Serverのサーバー・アラートのタイプは、次のとおりです。

- ハードウェア・コンポーネントは、ILOMによって監視されます。ハードウェア・コンポーネントが障害またはしきい値を超えたことを報告した場合、ILOMはSNMPトラップとして障害をMSに報告します。MSは、トラップを処理してアラートを作成し、アラートをOracle Enterprise Manager Cloud Controlに配信します。

注意:

ILOMアラート設定を構成する場合、ルール・リストの上部にあるルールを削除しないでください。新しいルールを追加するには、ルール・リストの一番下にルールを入力します。

- ハードウェアおよびソフトウェア・コンポーネントもMSによって直接監視されます。障害またはしきい値を超えると、MSは、トラップを処理してアラートを作成し、アラートをOracle Enterprise Manager Cloud Controlに配信します。

エンドユーザーの観点から、2つのタイプのアラートに違いはありません。アラート・メッセージには、アラートを解決する訂正処理が含まれています。

関連項目:

- Oracle Enterprise Manager Cloud Controlのインストールの詳細は、『Oracle Exadata Database Machineインストレーションおよび構成ガイド』を参照してください

- Oracle Enterprise Manager ExadataプラグインでサポートされているExadata Storageソフトウェア・バージョン(My Oracle SupportのドキュメントID 1626579.1)

- Exadata用のOracle Enterprise Managerのセットアップの自動化キットの取得(My Oracle SupportのドキュメントID 1440951.1)

- 修復の実行時に不要なアラートを回避するブラックアウトの使用方法の詳細は、Oracle Enterprise Manager管理を参照してください。

1.5 Oracle Configuration Managerを使用したシステムの監視

Oracle Configuration Managerは、構成情報を収集してOracleリポジトリにアップロードします。

構成情報が毎日アップロードされると、Oracleサポート・サービスでデータを分析して適切なサービスを提供できます。サービス・リクエストが記録されると、構成データがサービス・リクエストに関連付けられます。次に、Oracle Configuration Managerの利点の一部を示します。

- 問題解決の時間の短縮

- 事前の問題回避

- ベスト・プラクティスおよびOracleナレッジ・ベースのアクセスの向上

- お客様のビジネス・ニーズの詳細な理解

- 一貫したレスポンスおよびサービス

サーバーの各ORACLE_HOMEディレクトリに、Oracle Configuration Managerソフトウェアがインストールおよび構成されます。クラスタ化されたデータベースには、Oracle Configuration Managerに1つのインスタンスのみが構成されます。構成スクリプトは、サーバーのすべてのデータベースで実行されます。Oracle Configuration Managerコレクタが集中管理されているOracleリポジトリにデータを送信します。

関連トピック

- 『Oracle Configuration Managerインストレーションおよび管理ガイド』

- Oracle Configuration Managerコレクション概要

1.6 コンポーネントのパスワードの変更

コンポーネントのパスワードは、初期構成後に変更できます。この項には次のトピックが含まれます:

- データベース・サーバーのパスワードの変更

- Exadata Storage Serverのパスワードの変更

- 配電ユニットのパスワードの変更

- ILOMのパスワードの変更

- InfiniBandスイッチのパスワードの変更

- 「Ciscoイーサネット・スイッチのパスワードの変更」

- KVMのパスワードの変更

1.6.1 データベース・サーバーのパスワードの変更

ユーザー・アカウントとGRUBのパスワードは、データベース・サーバーで変更できます。データベース・サーバーのデフォルトのユーザー・アカウントはrootおよびソフトウェア所有者のアカウントです。通常、ソフトウェア所有者のアカウントはoracleまたはgridです。

1.6.1.1 データベース・サーバーでのユーザー・アカウントのパスワードの変更

データベース・サーバーでユーザー・アカウントを変更するには、オペレーティング・システム・プロンプトで次のコマンドを使用します。

passwd user_name

前述のコマンドのuser_nameは、変更対象のアカウントの名前です。

1.6.1.2 データベース・サーバーでのGRUBアカウントのパスワードの変更

次のコマンドを実行して、データベース・サーバーでGRUBアカウントのパスワードを変更します。

/opt/oracle.cellos/host_access_control grub-password

1.6.2 Exadata Storage Serverのパスワードの変更

Exadata Storage Serverのデフォルトのユーザー・アカウントはroot、celladminおよびcellmonitorです。

- Exadata Storage Serverのいずれかのパスワードを変更するには、オペレーティング・システムのpasswdコマンドを使用します。

オペレーティング・システム・プロンプトで次のコマンドを使用します。ここで、user_nameは、変更対象のアカウントの名前です。

passwd user_name

1.6.3 配電ユニットのパスワードの変更

配電ユニット(PDU)のデフォルトのユーザー・アカウントはadminです。次の手順では、PDUのパスワードを変更する方法について説明します。

1. Webブラウザのアドレス行にPDUメーター・ユニットのIPアドレスを入力して、ユニットにアクセスします。現在の測定ページが表示されます。

2. ページの左上の「ネットワーク構成」をクリックします。

3. PDUメーター・ユニットにadminユーザーとしてログインします。

4. 管理/ユーザー・フィールドを探します。ユーザー名とパスワードには、アルファベットと数字のみを使用できます。

5. 管理/ユーザー・フィールドにユーザーとパスワードを最大で5つまで入力します。

6. 各ユーザーを管理者またはユーザーとして指定します。

7. 「送信」をクリックして、ユーザーとパスワードを設定します。

1.6.4 ILOMのパスワードの変更

Integrated Lights Out Manager (ILOM)のデフォルトのユーザー・アカウントはrootです。次の手順では、ILOMのパスワードを変更する方法について説明します。

1. SSHを使用してILOMにログインします。

2. パスワードを変更するには、次のコマンドを使用します。

set /SP/users/user_name password

前述のコマンドのuser_nameは、変更対象のユーザー・アカウントです。このコマンドの例を次に示します。

set /SP/users/user1 password

Changing password for user /SP/users/user1/password...
Enter new password:********
Enter new password again:********
New password was successfully set for user /SP/users/user1

1.6.5 InfiniBandスイッチのパスワードの変更

この手順では、InfiniBandスイッチのパスワードを変更する方法について説明します。

InfiniBandスイッチのデフォルトのユーザー・アカウントはroot、ilom-admin、ilom-user、ilom-operatorおよびnm2userです。

1. SSHを使用した次のコマンドで、InfiniBandスイッチにログインします。

ssh user_name@switch_name

前述のコマンドのuser_nameはユーザーの名前、switch_nameはInfiniBandスイッチの名前です。

2. スイッチのファームウェアのバージョンをチェックします。

3. ILOMで次のコマンドを使用して、パスワードを変更します。

ssh -l ilom-admin switch_name

set /SP/users/user_name password

関連項目:
Sun Datacenter InfiniBand Switch 36ファームウェア・バージョン2.1管理ガイド(http://docs.oracle.com/cd/E36265_01/html/E36266/gentextid-2626.html#scrolltoc)

1.6.6 「Ciscoイーサネット・スイッチのパスワードの変更」

スイッチへのシリアル・ポート・アクセスとSSHアクセスの両方のパスワードを変更できます。

スイッチにアクセスするには、2つの異なる方法があります。1つはシリアル・ポートを使用し、もう1つはsshを使用します。シリアル・ポート・アクセスを使用する場合は、ユーザー・アカウントがないため、enableパスワードのみが必要となります。sshを介してスイッチにアクセスする場合は、パスワードを変更する前に、ユーザー・アカウントとパスワードを指定する必要があります。システムのインストール中にadminユーザーが作成されるため、このユーザーを使用してsshでスイッチにアクセスできます。

シリアル・ポート・アクセスのパスワードの変更

1. telnet、sshまたはシリアル・ポートを使用してスイッチにアクセスします。アクセスにシリアル・ポートを使用する場合は、プロンプトが表示されるのみで、ユーザー名またはパスワードが要求されることはありません。
次に例を示します。

my_host> ssh admin@my_switch
Using keyboard-interactive authentication.
Password:

注意:

- Oracle Linux 5 Update 5以上では、セキュリティ上の理由から、telnetが削除されました。telnetを使用してスイッチにアクセスするには、事前に計算ノードにTelnetクライアント・パッケージをインストールする必要がある場合があります。

- SSHを使用してスイッチにアクセスする前に、「Configuring SSH on Cisco Catalyst 4948 Ethernet Switch」(My Oracle SupportのドキュメントID 1415044.1)で説明されている手順に従ってスイッチでSSHを有効化する必要があります。

2. 次のコマンドを使用して、有効モードに変更します。

Switch> enable

3. 次のようにパスワードを設定します。

Switch# configure terminal
Enter configuration commands,one per line.End with CNTL/Z.
Switch(config)# no enable password
Switch(config)# enable secret new_password
Switch(config)# end
Switch# write memory
*Sep 15 14:25:05.893:%SYS-5-CONFIG_I:Configured from console by console
Building configuration...
Compressed configuration from 2502 bytes to 1085 bytes [OK ]

4. 次のコマンドを使用して、現在の構成を保存します。

Switch# copy running-config startup-config

5. セッションを終了します。

Switch# exit

TelnetまたはSSHアクセスのユーザー・パスワードを変更する手順

1. telnet、sshまたはシリアル・ポートを使用してスイッチにアクセスします。アクセスにシリアル・ポートを使用する場合は、プロンプトが表示されるのみで、ユーザー名またはパスワードが要求されることはありません。

次に例を示します。

my_host> ssh admin@my_switch
Using keyboard-interactive authentication.
Password:

2. 次のコマンドを使用して、有効モードに変更します。

Switch> enable
Password:

3. パスワードが暗号化された形式で送信されることを確認します。

次のコマンドを使用して、サービス・パスワード構成が-encryptionに設定されていることを確認します。

Switch# show running-config all | include service password-encryption
service password-encryption

これがno service password-encryptionに設定されている場合は、パスワードがクリア・テキストで送信されます。手順5に示すように、この設定を変更できます。

4. 構成モードに入ります。

Switch# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.

5. パスワードの暗号化がno service password-encryptionに設定されている場合は、service password-encryptionに変更します。

Switch(config)# service password-encryption

6. 特定のユーザーのパスワードを変更します。

Switch(config)# username user_name password new_password

7. 構成モードを終了し、変更を保存します。

Switch(config)# end
Switch# write memory

1.6.7 KVMのパスワードの変更

KVMのデフォルトのユーザー・アカウントはAdminです。次の手順では、KVMのパスワードを変更する方法について説明します。

1. ラックの前面からKVMトレイを引き出して、ハンドルを使用して開きます。

2. タッチ・パッドに触れます。

3. マウスのダブルクリックと同じように左側の[Ctrl]キーを2回押して、ホストとKVMインタフェースを切り替えます。

4. ユーザー・アカウントから「ローカル」を選択します。

5. ユーザーの下の「管理」をクリックします。

6. Adminアカウントのパスワードを設定します。他のパラメータを変更しないでください。

7. 「保存」をクリックします。

1.7 サーバー・モデルの判別

セル・サーバーまたはデータベース・サーバーのモデルを判別するには、次のコマンドを使用します。

/usr/sbin/exadata.img.hw --get model

次の表に、各Oracle Exadata Database Machineのサーバー・モデル番号を示します。

表1-2 Oracle Exadata Database Machineのサーバー・モデル

Oracle Exadata Database Machine

データベース・サーバーのモデル

Exadata Storage Serverのモデル

Oracle Exadata Database Machine X6-2

Oracle Server X6-2 Database Server

ORACLE SERVER X6-2

Exadata Storage Server X6-2L Server

ORACLE SERVER X6-2L

Oracle Exadata Database Machine X6-8

Oracle Server X5-8 5U Database Server

ORACLE SERVER X5-8

Exadata Storage Server X6-2L Server

ORACLE SERVER X6-2L

Oracle Exadata Database Machine X5-2

Oracle Server X5-2 Database Server

ORACLE SERVER X5-2

Exadata Storage Server X5-2L Server

ORACLE SERVER X5-2L

Oracle Exadata Database Machine X5-8

Oracle Server X5-8 Database Server

ORACLE SERVER X5-8

Exadata Storage Server X5-2L Server

ORACLE SERVER X5-2L

Oracle Exadata Database Machine X4-2

Sun Server X4-2 Oracle Database Server

SUN SERVER X4-2

Exadata Storage Server X4-2L Server

SUN SERVER X4-2L

Oracle Exadata Database Machine X3-2

Sun Server X3-2 Oracle Database Server

SUN FIRE X4170 M3

Exadata Storage Server X3-2 Server

SUN FIRE X4270 M3

Oracle Exadata Database Machine X2-2

Sun Fire X4170 M2 Oracle Database Server

SUN FIRE X4170 M2 SERVER

Sun Fire X4270 M2 Serverを使用したExadata Storage Server

SUN FIRE X4270 M2 SERVER

Oracle Exadata Database Machine X4-8フル・ラック

Sun Server X4-8 Oracle Database Server

SUN SERVER X4-8

Exadata Storage Server X4-2L Server

SUN SERVER X4-2L

Oracle Exadata Database Machine X3-8フル・ラック

Sun Server X2-8 Oracle Database Server

Sun Fire X4800 M2

Exadata Storage Server X3-2 Server

SUN FIRE X4270 M3

Oracle Exadata Database Machine X2-8フル・ラック

Sun Fire X4800 Oracle Database ServerまたはSun Server X2-8 Oracle Database Server

Sun Fire X4800またはSun Fire X4800 M2

Sun Fire X4270 M2 Serverを使用したExadata Storage Server

SUN FIRE X4270 M2 SERVER

Oracle Exadata Database Machine

Sun Fire X4170 Oracle Database Server

SUN FIRE X4170 SERVER

Sun Fire X4275 Serverを使用したExadata Storage Server

SUN FIRE X4275 SERVER

1.8 サーバーの周囲温度の監視

環境温度条件をOracle Exadataラックの設計仕様内に維持すると、最大限の効率化とコンポーネント・サービスの目標存続期間の達成に役立ちます。周囲温度範囲の検証による影響は最小です。是正処置による影響は、環境条件によって異なります。

摂氏21から23度(華氏70から74度)の外部周囲温度は、Oracle Exadataラックのすべてのコンポーネントに影響し、パフォーマンス上の問題が発生し、サービス存続期間が短くなることがあります。

次のコマンドをクラスタの最初のデータベース・サーバーのrootユーザーとして使用し、すべてのサーバーの周囲温度範囲を検証します。

dcli -g /opt/oracle.SupportTools/onecommand/all_group -l root 'ipmitool   \
sunoem cli "show /SYS/T_AMB" | grep value'

次に、コマンドの出力例を示します。

dm01db01: value = 21.440 degree C
dm01db02: value = 21.440 degree C
dm01db03: value = 22.190 degree C
...
dm01db08: value = 21.940 degree C
dm01cel01: value = 22.000 degree C
dm01cel02: value = 22.000 degree C
dm01cel03: value = 23.000 degree C
...
dm01cel14: value = 22.080 degree C

出力が周囲温度範囲外の場合は、問題を調査して是正します。次の項目をチェックする必要があります。

- ラックに十分な通気がある

- 室温が指定範囲内にある

- ラックの背面に障害物がない

1.9 「ディスク・コントローラ・バッテリ・バックアップ・ユニットの交換」

ディスク・コントローラ・バッテリ・バックアップ・ユニット(ディスク・コントローラBBU)は、データベースおよびExadata Storage Serverのドライブ・トレイにあります。ディスク・コントローラBBUは、サーバーおよびサーバー上で実行されているアプリケーションの停止時間なしで交換できます。次の手順では、ディスク・コントローラBBUを交換する方法について説明します。

- データベース・サーバーのディスク・コントローラBBUの交換

- Exadata Storage Serverのディスク・コントローラBBUの交換

注意:

この項の手順は、コントローラに内蔵のバッテリ・バックアップ・ユニットには適用されません。これらのユニットを交換する場合は、システムを開いてコントローラ・カードにアクセスするため、システムを停止する必要があります。

1.9.1 データベース・サーバーのディスク・コントローラBBUの交換

この項では、データベース・サーバーのディスク・コントローラBBUを交換する方法について説明します。高度な手順は次のとおりです。

- 手順1: ディスク・コントローラBBUの取り外しの準備

- 手順2: ディスク・コントローラBBUの交換

- 手順3: 新しいディスク・コントローラBBUの有効化および確認

注意:

保守手順の終了後は常にExachkツールを使用することをお薦めします。このツールはMy Oracle Supportノート1070954.1から入手できます。

1.9.1.1 手順1: ディスク・コントローラBBUの取り外しの準備

特定のX3-2、X4-2およびX4-8データベース・ノード、X3-2、X4-2、およびX3-8、X4-8ストレージ・サーバーでは、BBUはリモートでマウントされ、アクセスするのにシステムのシャットダウンは不要です。ただし、ディスク・ボリュームへのデータ破損を回避するには、RAID HBAから取り外せるように準備する必要があります。X3-8データベース・ノードのリモート・マウントBBUオプションはありません。

システムにリモート・マウントBBUがある場合は、「リモート・マウントBBUがあるシステムの場合」の手順に従います。システムにリモート・マウントBBUがない場合は、「リモート・マウントBBUがないシステムの場合」を参照してください。

リモート・マウントBBUがあるシステムの場合

次の手順は、リモート・マウントBBUがあるシステム用です。システムにリモート・マウントBBUがない場合は、「リモート・マウントBBUがないシステムの場合」を参照してください。

1. rootユーザーとしてログインします。

2. サービスを必要とするラックのサーバーで実行されているイメージのバージョンを取得します。

# imageinfo -ver
11.2.3.2.1.130302

例の最初の5つの部分の"11.2.3.2.1"はバージョンです。最後の部分はイメージの日付です。

3. ディスク・コントローラBBUの取り外しの準備。
バージョン12.1.2.1.0以上を実行している場合:

a. 交換対象のディスク・コントローラBBUを削除します。

DBMCLI> alter dbserver bbu drop for replacement

b. 次のことを確認します。

DBMCLI> list dbserver attributes bbustatus -
dropped for replacement

バージョン11.2.3.3.0から12.1.2.1.0を実行している場合:

a. 交換対象のディスク・コントローラBBUを削除します。

# /opt/oracle.cellos/compmon/exadata_mon_hw_asr.pl -drop_bbu_for_replacement

b. 次のことを確認します。

# /opt/oracle.cellos/compmon/exadata_mon_hw_asr.pl -list_bbu_status
BBU status: dropped for replacement.

バージョン11.2.3.2.xを実行している場合:

a. サービス対象のラックのサーバーを特定し、インジケータ・ライトをオンにします。
Exadata Storage Serverは、1から18の番号で識別され、RU2に取り付けられたラックの最下段のStorage Serverが1で、ラックの上部に向かって番号が順に上がっていきます。

Exadata Database Nodeは、1から8の番号で識別され、RU16に取り付けられたラックの最下段のデータベース・ノードが1です。

サービス対象のサーバーを簡単に識別できるように、検出インジケータ・ライトをオンにします。サーバーの番号が確認されたら、前面パネルの検出ボタンを押すことができます。

インジケータ・ライトをリモートでオンにし、次の方法を使用します。

Exadata Storage ServerのCellCliにログイン:

CellCli> alter cell led on

サーバーのILOMにログイン:

-> set /SYS/LOCATE value=Fast_Blink

サーバーのrootアカウントにログイン:

# ipmitool chassis identify force
Chassis identify interval: indefinite

b. HBAでバッテリと現在のステータスを表示できることを確認します。

注意:

Solarisで実行している場合は、次のコマンドの/opt/MegaRAID/MegaCli/MegaCli64の代わりに/opt/MegaRAID/MegaCliを使用します。

# /opt/MegaRAID/MegaCli/MegaCli64 -adpbbucmd -a0

デフォルトの出力には、バッテリがまだ表示されていることが表示されますが、障害に応じて低電圧またはその他の問題が表示される場合もあります。BBUに重大な障害が発生し、HBAにアクセスできなくなった場合、BBUの読取りエラーが返されることがあります。

c. すべての論理ボリュームで現在のキャッシュ・ポリシーを確認します。

# /opt/MegaRAID/MegaCli/MegaCli64 -ldpdinfo -a0 | grep BBU

デフォルトのキャッシュ・ポリシーは、すべてのボリュームで"ライトバック"です。バッテリが正常に機能している場合、現在のキャッシュ・ポリシーは"ライトバック"としてレポートされます。ただし、障害は発生した場合、現在のキャッシュ・ポリシーは"ライトスルー"としてレポートされることがあります。

d. すべての論理ボリュームのキャッシュ・ポリシーをライトスルー・キャッシュ・モード(バッテリを使用しない)に設定します。

# /opt/MegaRAID/MegaCli/MegaCli64 -ldsetprop wt -lall -a0

e. すべての論理ボリュームの現在のキャッシュ・ポリシーがライトスルーになっていることを確認します。

# /opt/MegaRAID/MegaCli/MegaCli64 -ldpdinfo -a0 | grep BBU

リモート・マウントBBUがないシステムの場合

次の手順は、リモート・マウントBBUがないシステム用です。システムにリモート・マウントBBUがある場合は、「リモート・マウントBBUがあるシステムの場合」を参照してください。

リモート・マウントされたバッテリがシステムに取り付けられていない場合は、バッテリの交換が必要なノードをシャットダウンする必要があります。

1. すべてのRAIDディスク・ボリュームをライトスルー・モードに戻し、RAIDキャッシュ・メモリーのすべてのデータがディスクにフラッシュされ、バッテリの交換時にデータの損失が発生しないことを確認します。

a. すべての論理ボリュームのキャッシュ・ポリシーをライトスルー・キャッシュ・モードに設定します。

注意:

Solarisで実行している場合は、次のコマンドの/opt/MegaRAID/MegaCli/MegaCli64の代わりに/opt/MegaRAID/MegaCliを使用します。

# /opt/MegaRAID/MegaCli/MegaCli64 -ldsetprop wt -lall -a0

b. すべての論理ボリュームの現在のキャッシュ・ポリシーがライトスルー(バッテリーを使用しない)になっていることを確認します。

# /opt/MegaRAID/MegaCli/MegaCli64 -ldpdinfo -a0 | grep BBU

2. サーバー・オペレーティング・システムをシャットダウンします。

a. My Oracle Supportノート1093890.1「Exadata構成でExadataおよびRDBMSサービスおよびセル/計算ノードをシャットダウン/起動する手順」の手順を実行します。

b. データベース・ノードの電源を切断する前に、CRSサービスを停止します。次のコマンドをrootユーザーとして実行します。

# . oraenv
ORACLE_SID = [root] ? +ASM1
The Oracle base for ORACLE_HOME=/u01/app/11.2.0/grid is /u01/app/oracle

前述の出力例では、+ASM1の1はデータベース・ノード番号を指します。たとえば、ノード3のデータベースでは、値は+ASM3になります。

# $ORACLE_HOME/bin/crsctl stop crs

または

# <GI_HOME>/bin/crsctl stop crs

<GI_HOME>は、通常は/u01/app/11.2.0/gridに設定されますが、設定によって変わる場合があります。

c. CRSが停止していることを確認します。実行中のCRSプロセスはありません。

# ps -ef | grep css

d. サーバー・オペレーティング・システムをシャットダウンします。
Linux:

# shutdown -hP now

Solaris:

# shutdown -y -i 5 -g 0

1.9.1.2 手順2: ディスク・コントローラBBUの交換

この手順では、古いディスク・コントローラBBUを取り外し、新しいBBUと交換します。

リモート・バッテリを装着したExadata X3-2、X4-2またはX4-8計算ノード、およびX3-2、X3-8、X4-2またはX4-8ストレージ・セル・ノード

これらの手順は、リモート・バッテリが取り付けられたX3-2、X4-2、X4-8およびX3-2L、X4-2Lサーバーに基づいたExadataノードに適用されます。

1. オレンジ色と白色のBBUラベルのマークが付いたバッテリを特定します。
X3-2およびX4-2計算ノード: BBUのラベルが付いたシャーシの前面の右上隅のスロットです(以前に指定した"HDD7")。

X4-8計算ノード: BBUのラベルが付いたシャーシの背面の左上隅のスロットです。

X3-2LおよびX4-2Lストレージ・セル: BBUのラベルが付いた、PS1の上のシャーシ背面の右側のスロットです(以前に指定した"REAR HDD 1")。

2. ラッチを解除し、古いBBUキャリアをスライドさせて慎重に引き出します。

3. 新しいBBUキャリアを挿入して慎重にスライドさせ、ラッチで固定して閉じます。

リモート・バッテリのないExadata X3-2LまたはX4-2Lストレージ・セル・ノード

Supportノート1561949.1に詳細に記載されているCAPに従い、既存のHBA BBUとリモート・マウントされたバッテリ・キット(部品番号7060020)を交換します。

リモート・バッテリのないExadata X3-2またはX4-2データベース・マシン計算ノード

Supportノート1561949.1に詳細に記載されているCAPに従い、既存のHBA BBUとリモート・マウントされたバッテリ・キット(部品番号7060020)を交換します。

Exadata X3-8データベース・マシン計算ノード

これらの手順は、X2-8サーバー(旧称x4800m2)に基づいたExadataノードに関連します。

1. CMOD0をサーバーから取り外し、平らな静電気防止面の上に置きます。

2. CMODの上部カバーを取り外します。

3. BBUが取り付けられているHBA REMを取り外します。

a. REMイジェクタ・ハンドルを持ち上げ、開位置まで回転します。

b. REMのコネクタの端を持ち上げ、前面の支持金具の固定クリップからREMを引き抜きます。

4. 古いBBUをREMから取り外します。

a. プラスのねじ回し(Phillipsの1番)を使用して、バッテリをREMカードに固定している3本の留めねじを外します。REMとバッテリ・パックの上側のねじは外さないでください。これらのねじは、底部にねじ穴のある支持具を固定しており、バッテリ・パックに付けたままにしておく必要があります。

b. 回路基板を含むバッテリ・パックを、回路基板コネクタからゆっくり持ち上げ、REMから取り外します。

5. 新しいBBUをREMに取り付けます。

a. バッテリ・パックの回路基板コネクタを取り付け、REMのコネクタに接続します。

b. プラスのねじ回し(Phillipsの1番)を使用して、バッテリをREMに固定します。BBUに新しいねじのパッケージが付属している場合は、それらのねじを使用し、古いBBUアタッチメントのねじは再利用しないでください。

6. BBUが取り付けられているHBA REMを元どおりに取り付けます。

a. REMイジェクタ・レバーが閉位置になっていることを確認します。レバーはREM支持金具と平らになっている必要があります。

b. バッテリが下を向いており、コネクタとマザーボードのコネクタの位置が合うように、REMの位置を合わせます。

c. REMの反対の端を前面の支持金具の固定クリップの下に滑らせ、REMの端のノッチが金具の位置合せポストの周囲に位置していることを確認します。

d. REMがマザーボードのコネクタに接する位置まで、REMのコネクタの端を慎重に押し下げ、コネクタの位置が合っていることを確認します。コネクタを固定するには、レベル位置までREMを慎重に押し込みます。

7. カバーをCMODに取り付けます。

8. CMODをCMOD0スロットのユニットに戻します。

1.9.1.3 手順3: 新しいディスク・コントローラBBUの有効化および確認

「手順1: ディスク・コントローラBBUの取り外しの準備」と同様、この手順には2つのサブ項目があります。

- リモート・マウントBBUがあるシステムの場合

- リモート・マウントBBUがないシステムの場合

リモート・マウントBBUがあるシステムの場合

リモート・マウントBBUがあるシステムの場合、「手順1: ディスク・コントローラBBUの取り外しの準備」の終了時にシステムはシャットダウンされていません。

イメージ・バージョン11.2.3.3.0以上を使用している場合:

1. ルート・ユーザーとしてログインします。

2. ディスク・コントローラBBUのバッテリ状態が存在し、RAIDコントローラで表示されていることを確認します。新しいBBUバッテリが検出されるまでに数分かかる場合があります。

注意:

Solarisで実行している場合は、次のコマンドの/opt/MegaRAID/MegaCli/MegaCli64の代わりに/opt/MegaRAID/MegaCliを使用します。

# /opt/MegaRAID/MegaCli/MegaCli64 -AdpAllInfo -a0 | grep BBU
BBU : Present
BBU : Yes
Cache When BBU Bad : Disabled

3. ディスク・コントローラBBUおよびディスク・キャッシュを再有効化します。

# /opt/oracle.cellos/compmon/exadata_mon_hw_asr.pl -reenable_bbu
HDD disk controller battery has been reenabled.

4. ディスク・コントローラBBUのバッテリ状態がOperationalであることを確認します。

# /opt/oracle.cellos/compmon/exadata_mon_hw_asr.pl -list_bbu_status
BBU status: present

5. 現在の論理ディスク・ドライブのキャッシュ・ポリシーでライトバック・モードが使用されていることを確認します。

# /opt/MegaRAID/MegaCli/MegaCli64 -ldpdinfo -a0 | grep -i bbu
Default Cache Policy: WriteBack, ReadAheadNone, Direct, No Write Cache if Bad BBU
Current Cache Policy: WriteBack, ReadAheadNone, Direct, No Write Cache if Bad BBU
... <repeated for each logical volume present>

6. 現在のキャッシュ・ポリシーがライトスルー・モードで、ライトバックでない場合は、バッテリのステータスをチェックします。

# /opt/MegaRAID/MegaCli/MegaCli64 -adpbbucmd -getbbustatus -a0|grep Battery
BatteryType: iBBU08
Battery State : Operational
Battery Pack Missing : No
Battery Replacement required : No

バッテリの状態が"Operational"または"Optimal" (正確な用語はイメージ・バージョンによって異なります)以外の場合は、続行する前に問題を調査して修正します。

次に示すイメージ・バージョンは、"Optimal"および"Operational"を使用しています。

Exadata image version       Battery State         Raid f/w version
---------------------       -------------------   -----------------
X4    12.1.2.1.0            Optimal              12.12.0-0178
X4    12.1.1.1.1            Optimal              12.12.0-0178
X3    11.2.3.3.0            Optimal              12.12.0-0178
X3    11.2.3.2.2            Optimal              12.12.0-0178
X3    11.2.3.2.1            Operational          12.12.0-0140

イメージ・バージョン11.2.3.2.xを使用している場合:

1. ルート・ユーザーとしてログインします。

2. サーバーの検出LEDをオフにします。

# ipmitool chassis identify off
Chassis identify interval: off

3. HBAが認識され、新しいBBUと通信を開始するまで、約5分間待機します。

4. HBAバッテリ・ステータスがOperationalで、充電中であることを確認します。

# /opt/MegaRAID/MegaCli/MegaCli64 -adpbbucmd -a0

5. すべての論理ドライブのキャッシュ・ポリシーをライトバック・キャッシュ・モードに設定します。

# /opt/MegaRAID/MegaCli/MegaCli64 -ldsetprop wb -lall -a0

6. すべての論理ドライブの現在のキャッシュ・ポリシーがライトバック・キャッシュ・モードを使用していることを確認します。

# /opt/MegaRAID/MegaCli/MegaCli64 -ldpdinfo -a0 | grep -i bbu
Default Cache Policy: WriteBack, ReadAheadNone, Direct, No Write Cache if Bad BBU
Current Cache Policy: WriteBack, ReadAheadNone, Direct, No Write Cache if Bad BBU
... <repeated for each logical volume present>

リモート・マウントBBUがないシステムの場合

リモート・マウントBBUがないシステムの場合、「手順1: ディスク・コントローラBBUの取り外しの準備」の終了時にシステムをシャットダウンします。この項では、システムを再起動して新しいBBUを有効にします。

1. 電源ボタンを押して、サーバーの電源を入れます。

2. ILOMが起動したら、電源ボタンを押してサーバーの電源を入れ、サーバーのコンソールに接続します。
ILOM Webブラウザからコンソールに接続する手順(推奨): リモート制御→リダイレクト・タブにアクセスし、リモート・コンソールの起動ボタンをクリックします。ILOM 3.1.xシステムでは、コンソール・ボタンは最初の「サマリー情報」画面から起動できます。

ILOM CLIからコンソールに接続する手順:

> start /SP/console

3. サーバーのコンソールから、システム・ブートを監視します。特に、ロード中のLSIコントローラのBIOSを監視してください。保存されているキャッシュがあるドライブに関する警告メッセージが表示される場合、"D"を選択すると、キャッシュを破棄して続行されます。ASMによる起動後に、ディスクが再同期されるため、これは問題ではありません。バッテリ低下によりライトスルー・モードになっているドライブに関する警告メッセージが表示される場合は、選択して続行します。
その後、Exadataの起動が正常に続行されると、Exadataのブート・スプラッシュ画面が表示され、通常のOSブート・メッセージが引き続き表示されます。後続の起動手順中に、ILOMシリアル・コンソールの画面出力の間の停止時間が長くなる場合がありますが、これは、デフォルトのコンソールがグラフィックで、Exadataブート・スプラッシュ画面が表示されないためです。

4. 起動がすべて完了したら、rootユーザーとしてログインし、新しいバッテリが表示されて充電中であることを確認します。

# /opt/MegaRAID/MegaCli/MegaCli64 -adpbbucmd -a0

5. すべての論理ドライブのキャッシュ・ポリシーを、バッテリを使用するライトバック・キャッシュ・モードに設定します。

# /opt/MegaRAID/MegaCli/MegaCli64 -ldsetprop wb -lall -a0

6. すべての論理ドライブの現在のキャッシュ・ポリシーがライトバック・キャッシュ・モードを使用していることを確認します。

# /opt/MegaRAID/MegaCli/MegaCli64 -ldpdinfo -a0 | grep BBU

7. データベース・サービスが自動的に開始されたことを確認します。

a. CRSが実行中であることを確認します。

# . oraenv
ORACLE_SID = [root] ? +ASM1
The Oracle base for ORACLE_HOME=/u01/app/11.2.0/grid is /u01/app/oracle

# crsctl check crs
CRS-4638: Oracle High Availability Services is online
CRS-4537: Cluster Ready Services is online
CRS-4529: Cluster Synchronization Services is online
CRS-4533: Event Manager is online

前述の出力では、+ASM1の1はデータベース・ノード番号を指します。たとえば、ノード#3のデータベースでは、値は+ASM3になります。

b. インスタンスが実行中であることを検証します。

# ps -ef |grep pmon

ASMインスタンスのレコードと各データベースのレコードが返されます。

1.9.2 Exadata Storage Serverのディスク・コントローラBBUの交換

この項では、Exadata Storage Serverのディスク・コントローラBBUを交換する方法について説明します。手順の概要は次のとおりです。

- 手順1: ディスク・コントローラBBUの取り外しの準備

- 手順2: ディスク・コントローラBBUの交換

- 手順3: 新しいディスク・コントローラBBUの有効化

注意:

保守手順の終了後は常にExachkツールを使用することをお薦めします。このツールはMy Oracle Supportノート1070954.1から入手できます。

1.9.2.1 手順1: ディスク・コントローラBBUの取り外しの準備

特定のX3-2、X4-2およびX4-8データベース・ノード、X3-2、X4-2、およびX3-8、X4-8ストレージ・サーバーでは、BBUはリモートでマウントされ、アクセスするのにシステムのシャットダウンは不要です。ただし、ディスク・ボリュームへのデータ破損を回避するには、RAID HBAから取り外せるように準備する必要があります。X3-8データベース・ノードのリモート・マウントBBUオプションはありません。

リモート・マウントBBUがあるシステムの場合

システムにリモート・マウントBBUがある場合は、この項の手順を実行します。システムにリモート・マウントBBUがない場合は、「リモート・マウントBBUがないシステムの場合」の手順を実行します。

1. rootユーザーとしてログインします。

2. サービスを必要とするラックのサーバーで実行されているイメージのバージョンを取得します。

# cellcli -e list cell attributes releaseVersion
11.2.3.2.1

3. ディスク・コントローラBBUを削除します。
バージョン11.2.3.3.0以上を実行している場合:

a. 交換対象のディスク・コントローラBBUを削除します。次のコマンドを"celladmin"または"root"ユーザーとして実行します。

# cellcli -e alter cell bbu drop for replacement
HDD disk controller battery has been dropped for replacement

b. 交換対象のBBUが削除されたことを確認します。

# cellcli -e list cell attributes bbustatus
dropped for replacement.

バージョン11.2.3.2.xを実行している場合:

a. サービス対象のラックのサーバーを特定し、インジケータ・ライトをオンにします。
Exadata Storage Serverは、1から18の番号で識別され、RU2に取り付けられたラックの最下段のStorage Serverが1で、ラックの上部に向かって番号が順に上がっていきます。

Exadata Database Nodeは、1から8の番号で識別され、RU16に取り付けられたラックの最下段のデータベース・ノードが1です。

サービス対象のサーバーを簡単に識別できるように、検出インジケータ・ライトをオンにします。サーバーの番号が確認されたら、前面パネルの検出ボタンを押すことができます。

インジケータ・ライトをリモートでオンにし、次の方法を使用します。

Exadata Storage ServerのCellCliにログイン:

CellCli> alter cell led on

サーバーのILOMにログイン:

-> set /SYS/LOCATE value=Fast_Blink

サーバーのrootアカウントにログイン:

# ipmitool chassis identify force
Chassis identify interval: indefinite

b. HBAでバッテリと現在のステータスを表示できることを確認します。

注意:

Solarisで実行している場合は、次のコマンドの/opt/MegaRAID/MegaCli/MegaCli64の代わりに/opt/MegaRAID/MegaCliを使用します。

# /opt/MegaRAID/MegaCli/MegaCli64 -adpbbucmd -a0

デフォルトの出力には、バッテリがまだ表示されていることが表示されますが、障害に応じて低電圧またはその他の問題が表示される場合もあります。BBUに重大な障害が発生し、HBAにアクセスできなくなった場合、BBUの読取りエラーが返されることがあります。

c. すべての論理ボリュームで現在のキャッシュ・ポリシーを確認します。

# /opt/MegaRAID/MegaCli/MegaCli64 -ldpdinfo -a0 | grep BBU

デフォルトのキャッシュ・ポリシーは、すべてのボリュームで"ライトバック"です。バッテリが正常に機能している場合、現在のキャッシュ・ポリシーは"ライトバック"としてレポートされます。ただし、障害は発生した場合、現在のキャッシュ・ポリシーは"ライトスルー"としてレポートされることがあります。

d. すべての論理ボリュームのキャッシュ・ポリシーをライトスルー・キャッシュ・モード(バッテリを使用しない)に設定します。

# /opt/MegaRAID/MegaCli/MegaCli64 -ldsetprop wt -lall -a0

e. すべての論理ボリュームの現在のキャッシュ・ポリシーがライトスルーになっていることを確認します。

# /opt/MegaRAID/MegaCli/MegaCli64 -ldpdinfo -a0 | grep BBU

リモート・マウントBBUがないシステムの場合

システムにリモート・マウントBBUがない場合は、この項の手順を実行します。システムにリモート・マウントBBUがある場合は、「リモート・マウントBBUがあるシステムの場合」を参照してください。

リモート・マウントされたバッテリがシステムに取り付けられていない場合は、バッテリの交換が必要なノードをシャットダウンする必要があります。

1. すべてのRAIDディスク・ボリュームをライトスルー・モードに戻し、RAIDキャッシュ・メモリーのすべてのデータがディスクにフラッシュされ、バッテリの交換時にデータの損失が発生しないことを確認します。

a. すべての論理ボリュームのキャッシュ・ポリシーをライトスルー・キャッシュ・モードに設定します。

# /opt/MegaRAID/MegaCli/MegaCli64 -ldsetprop wt -lall -a0

b. すべての論理ボリュームの現在のキャッシュ・ポリシーがライトスルー(バッテリーを使用しない)になっていることを確認します。

# /opt/MegaRAID/MegaCli/MegaCli64 -ldpdinfo -a0 | grep BBU

2. サーバー・オペレーティング・システムをシャットダウンします。
Exadata Storage Serverの電源を切断する際は、次の点に注意してください。

- ディスク障害が発生したストレージ・サーバーが他にないことを確認します。別のディスクで障害が発生中にストレージ・サーバーをシャットダウンすると、データベース・プロセスおよびOracle ASMがクラッシュする場合がありますが、その可能性があるのは、サーバーのディスクがオフラインになったときに、パートナー・ペアの両方のディスクが失われる場合です。

- ラックの残りにディスクの障害が発生していない1つのExadata Storage Serverの電源を切断しても、実行中のデータベース・プロセスまたはOracle ASMには影響しません。

- 複数のExadata Storage Serverを停止する前に、すべてのデータベースおよびOracle Clusterwareプロセスを停止する必要があります。これが必要な場合の詳細は、Exadataオーナーズ・ガイドを参照してください。

オフラインに切り替えられるとすぐに、ディスクはASMによって削除されます。リストア対象のASMディスクの修復タイマーよりも長い時間ストレージ・サーバーがオフラインの場合、Exadata Storage Serversの電源を切断するか再起動すると、データベースのパフォーマンスが影響を受けることがあります。デフォルトのDISK_REPAIR_TIME属性値は3.6時間で、コンポーネントの交換には適切ですが、長い時間が必要な場合は、変更が必要になることがあります。

a. ASMにログインして次の問合せを実行し、ディスクの修復時間を確認します。

SQL> select dg.name,a.value from v$asm_attribute a, v$asm_diskgroup dg
where a.name = 'disk_repair_time' and a.group_number = dg.group_number;

交換対象のコンポーネントの交換に十分な値の場合は、変更する必要はありません。

変更する必要がある場合は、次の文を使用できます。

SQL> ALTER DISKGROUP DATA SET ATTRIBUTE 'DISK_REPAIR_TIME'='8.5H';

b. ASMが問題なく、グリッド・ディスクがオフラインになるかどうかを確認します。次のコマンドは、リストされているグリッド・ディスクで"Yes"を返します。

# cellcli -e list griddisk attributes name,asmmodestatus,asmdeactivationoutcome
...sample ...
DATA_CD_09_cel01 ONLINE Yes
DATA_CD_10_cel01 ONLINE Yes
DATA_CD_11_cel01 ONLINE Yes
RECO_CD_00_cel01 ONLINE Yes
RECO_CD_01_cel01 ONLINE Yes
...repeated for all griddisks....

1つ以上のディスクでasmdeactivationoutcome='Yes'が返されない場合は、各ディスク・グループを確認し、そのディスク・グループのデータ冗長性をリストアします。ディスク・グループのデータ冗長性が完全にリストアされたら、コマンドを再実行して、すべてのグリッド・ディスクでasmdeactivationoutcome='Yes'になっていることを確認します。すべてのディスクでasmdeactivationoutcome='Yes'が返されたら、次の手順に進みます。

注意:

1つ以上のグリッド・ディスクがasmdeactivationoutcome='Yes'を返さない場合に、セル・サービスを停止すると、影響を受けるディスク・グループがOracle ASMによってディスマウントされ、データベースが突然停止します。

c. 保守用に電源を切断する必要があるセルのすべてのグリッド・ディスクを非アクティブ化します。これは、最大で10分以上になる場合があります。

# cellcli
...sample ...
CellCLI> ALTER GRIDDISK ALL INACTIVE
GridDisk DATA_CD_00_dmorlx8cel01 successfully altered
GridDisk DATA_CD_01_dmorlx8cel01 successfully altered
GridDisk DATA_CD_02_dmorlx8cel01 successfully altered
GridDisk RECO_CD_00_dmorlx8cel01 successfully altered
GridDisk RECO_CD_01_dmorlx8cel01 successfully altered
GridDisk RECO_CD_02_dmorlx8cel01 successfully altered
...repeated for all griddisks...

d. グリッド・ディスクがオフラインになったことを確認します。ディスクがオフラインになり、ASMで非アクティブなると、出力には、asmmodestatus='UNUSED'または'OFFLINE'、およびasmdeactivationoutcome=Yesがすべてのグリッド・ディスクで表示されます。

CellCLI> list griddisk attributes name,status,asmmodestatus,asmdeactivationoutcome
DATA_CD_00_dmorlx8cel01 inactive OFFLINE Yes
DATA_CD_01_dmorlx8cel01 inactive OFFLINE Yes
DATA_CD_02_dmorlx8cel01 inactive OFFLINE Yes
RECO_CD_00_dmorlx8cel01 inactive OFFLINE Yes
RECO_CD_01_dmorlx8cel01 inactive OFFLINE Yes
RECO_CD_02_dmorlx8cel01 inactive OFFLINE Yes
...repeated for all griddisks...

e. すべてのディスクがオフラインになり、非アクティブになると、セルをシャットダウンできます。

# shutdown -hP now

Exadata Storage Serverの電源を切断すると、すべてのストレージ・サービスが自動的に停止します。

1.9.2.2 手順2: ディスク・コントローラBBUの交換

「手順2: ディスク・コントローラBBUの交換」を参照してください。

1.9.2.3 手順3: 新しいディスク・コントローラBBUの有効化

「手順1: ディスク・コントローラBBUの取り外しの準備」と同様、この項には2つのサブ項目があります。

- リモート・マウントBBUがあるシステムの場合

- リモート・マウントBBUがないシステムの場合

リモート・マウントBBUがあるシステムの場合

システムにリモート・マウントBBUがある場合は、この項の手順を実行します。このシナリオでは、「手順1: ディスク・コントローラBBUの取り外しの準備」の終了時にシステムはシャットダウンされていません。

イメージ・バージョン11.2.3.3.0以上を実行している場合:

1. celladminまたはrootユーザーとしてログインします。

2. BBUを再有効化します。

# cellcli -e alter cell bbu reenable
HDD disk controller battery has been reenabled

3. ディスク・コントローラBBUのバッテリ状態がOperationalであることを確認します。

# cellcli -e list cell attributes bbustatus
normal

"BBUステータス"が"normal"以外の場合は、続行する前に問題を調査して修正してください。

イメージ・バージョン11.2.3.2.xを実行している場合:

1. ルート・ユーザーとしてログインします。

2. サーバーの検出LEDをオフにします。

# ipmitool chassis identify off
Chassis identify interval: off

3. HBAが認識され、新しいBBUと通信を開始するまで、約5分間待機します。

4. HBAバッテリ・ステータスがOperationalで、充電中であることを確認します。

# /opt/MegaRAID/MegaCli/MegaCli64 -adpbbucmd -a0

5. すべての論理ドライブのキャッシュ・ポリシーをライトバック・キャッシュ・モードに設定します。

# /opt/MegaRAID/MegaCli/MegaCli64 -ldsetprop wb -lall -a0

6. すべての論理ドライブの現在のキャッシュ・ポリシーがライトバック・キャッシュ・モードを使用していることを確認します。

# /opt/MegaRAID/MegaCli/MegaCli64 -ldpdinfo -a0 | grep -i bbu
Default Cache Policy: WriteBack, ReadAheadNone, Direct, No Write Cache if Bad BBU
Current Cache Policy: WriteBack, ReadAheadNone, Direct, No Write Cache if Bad BBU
... <repeated for each logical volume present>

リモート・マウントBBUがないシステムの場合

「手順1: ディスク・コントローラBBUの取り外しの準備」の終了時に、リモート・マウントBBUがないシステムはシャットダウンされています。システムを再起動する必要があります。

1. 電源ボタンを押して、サーバーの電源を入れます。

2. ILOMが起動したら、電源ボタンを押してサーバーの電源を入れ、サーバーのコンソールに接続します。
ILOM Webブラウザからコンソールに接続する手順(推奨): リモート制御→リダイレクト・タブにアクセスし、リモート・コンソールの起動ボタンをクリックします。ILOM 3.1.xシステムでは、コンソール・ボタンは最初の「サマリー情報」画面から起動できます。

ILOM CLIからコンソールに接続する手順:

> start /SP/console

3. サーバーのコンソールから、システム・ブートを監視します。特に、ロード中のLSIコントローラのBIOSを監視してください。保存されているキャッシュがあるドライブに関する警告メッセージが表示される場合、"D"を選択すると、キャッシュを破棄して続行されます。ASMによる起動後に、ディスクが再同期されるため、これは問題ではありません。バッテリ低下によりライトスルー・モードになっているドライブに関する警告メッセージが表示される場合は、選択して続行します。
その後、Exadataの起動が正常に続行されると、Exadataのブート・スプラッシュ画面が表示され、通常のOSブート・メッセージが引き続き表示されます。後続の起動手順中に、ILOMシリアル・コンソールの画面出力の間の停止時間が長くなる場合がありますが、これは、デフォルトのコンソールがグラフィックで、Exadataブート・スプラッシュ画面が表示されないためです。

4. 起動がすべて完了したら、rootユーザーとしてログインし、新しいバッテリが表示されて充電中であることを確認します。

# /opt/MegaRAID/MegaCli/MegaCli64 -adpbbucmd -a0

5. すべての論理ドライブのキャッシュ・ポリシーを、バッテリを使用するライトバック・キャッシュ・モードに設定します。

# /opt/MegaRAID/MegaCli/MegaCli64 -ldsetprop wb -lall -a0

6. すべての論理ドライブの現在のキャッシュ・ポリシーがライトバック・キャッシュ・モードを使用していることを確認します。

# /opt/MegaRAID/MegaCli/MegaCli64 -ldpdinfo -a0 | grep BBU

7. セルをサービスに戻します。

a. グリッド・ディスクをアクティブ化します。

# cellcli
CellCLI> alter griddisk all active
GridDisk DATA_CD_00_dmorlx8cel01 successfully altered
GridDisk DATA_CD_01_dmorlx8cel01 successfully altered
GridDisk DATA_CD_02_dmorlx8cel01 successfully altered
GridDisk RECO_CD_00_dmorlx8cel01 successfully altered
GridDisk RECO_CD_01_dmorlx8cel01 successfully altered
GridDisk RECO_CD_02_dmorlx8cel01 successfully altered
...etc...

b. すべてのディスクがアクティブになっていることを確認します。

CellCLI> list griddisk
DATA_CD_00_dmorlx8cel01         active
DATA_CD_01_dmorlx8cel01         active
DATA_CD_02_dmorlx8cel01         active
RECO_CD_00_dmorlx8cel01         active
RECO_CD_01_dmorlx8cel01         active
RECO_CD_02_dmorlx8cel01         active
...etc...

c. すべてのグリッド・ディスクが正常にオンラインになったことを確認します。すべてのグリッド・ディスクで"asmmodestatus"のステータスが"ONLINE"になるまで待機します。アクティブ化プロセスの最初の出力の例を次に示します。

CellCLI> list griddisk attributes name,status,asmmodestatus,asmdeactivationoutcome
DATA_CD_00_dmorlx8cel01 active ONLINE Yes
DATA_CD_01_dmorlx8cel01 active ONLINE Yes
DATA_CD_02_dmorlx8cel01 active ONLINE Yes
RECO_CD_00_dmorlx8cel01 active SYNCING Yes
RECO_CD_01_dmorlx8cel01 active ONLINE Yes
...etc...

'RECO_CD_00_dmorlx8cel01'の上の例は、まだ'SYNCING'プロセスの実行中です。すべてのグリッド・ディスクが'asmmodestatus=ONLINE'を示したときに、Oracle ASMの同期化が完了します。このプロセスは、個別のサーバーが修復のために停止している間マシンがビジー、またはビジーであった状態に応じて時間がかかる場合があります。

1.10 dbmsrvサービスの概要

- リリース12.1.2.1.2以上の場合
12.1.2.1.2リリース以上では、データベース・ノードの管理サーバー(MS)でsudoが使用されなくなりました。つまり、sudoersの構成は必要なくなりました。

- 12.1.2.1.2より前のリリースの場合
セキュリティ上の理由から、データベース・ノードの管理サーバーはrootとして実行されません。ただし、ディスク・ステータス、ILOM、電源ユニットなど、システムを監視する特定のユーティリティを実行し、ASRおよびアラートを送信するには、root権限が必要になります。これを達成するために、sudoers構成ファイルのdbmsvc_sudo_confが追加され、dbmmgmtユーザーがroot権限でユーティリティを実行できるようになっています。

dbmmgmtサービスまたはdbserverdを無効にしたり、sudoers構成ファイルを編集したりしないでください。ファイルのエントリが削除されると、dbmmgmtサービスでシステムの一部の部分を監視できなくなる場合があります。たとえば、ディスクに障害が発生すると、ASRを時間内に送信できなくなり、データベース・ノードで破損が発生し、リカバリが遅延する場合があります。

1.11 dbmsrvのユーザーIDおよびグループIDの変更

Oracle Exadata Database Machine 12.1.2.1.0以降:

- データベース・ノードで管理サーバー(MS)が実行されるようになりました。以前のMSは、ストレージ・ノードでのみ実行されていました。

- データベース・マシン・サービス(dbmsrv)という名前の新しいサービスがデータベース・ノードで実行されるようになりました。この新しいサービスがベースとするMSは、ストレージ・サーバー上で実行され、データベース・ノードに拡張管理機能を提供します。

新しいdbmsrvサービスを管理するために、新しいユーザーとグループが追加されました。

表1-3 dbmsrvのユーザー

ユーザー

デフォルトのユーザーID

dbmsvc

12137

dbmadmin

12138

dbmmonitor

12139

表1-4 dbmsrvのグループ

グループ

デフォルトのグループID

dbmsvc

11137

dbmadmin

11138

dbmmonitor

11139

dbmusers

11140

デフォルト値と競合が発生している場合(たとえば、LDAPまたは別のディレクトリを使用している場合、または、デフォルト値と異なる値を必要とするセッション管理ツールを使用している場合)、DBMユーザーのユーザーIDとグループIDを変更できます。

これらの手順は、DBMサービスのユーザーとグループのみに固有です。これらを使用して、他のOracle製品のユーザーとグループを変更しないでください。

デフォルトのDBMユーザーおよびグループIDを変更する手順:

1. dbserverサービスを停止します。次のコマンドをrootまたはdbmadminユーザーとして実行します。

dbmcli -e alter dbserver shutdown services all

2. ユーザーのグループIDを変更します。次のコマンドをrootとして実行します。

groupmod -g <NEW_GID> <GROUPNAME>

次に例を示します。

groupmod -g 3001 dbmusers

3. 古いグループIDを含むファイルを更新します。次のコマンドをrootとして実行します。

find / -gid <OLD_GID> -exec chgrp -h <NEW_GID> {} \;

次に例を示します。

find / -gid 11140 -exec chgrp -h 3001 {} \;

4. ユーザーIDを変更します。これは、グループIDの変更後に実行する必要があり、そうしないと、GIDが存在しませんエラーが表示されます。次のコマンドをrootとして実行します。

usermod -u <NEW_UID> -g <NEW_GID> <USER>

次に例を示します。

usermod -u 2998 -g 3001 dbmsvc

5. 古いユーザーIDを含むファイルを更新します。次のコマンドをrootとして実行します。

find / -uid <OLD_UID> -exec chown -h <NEW_ID> {} \;

次に例を示します。

find / -uid 12137 -exec chown -h 2998 {} \;

6. dbrsMain実行可能ファイル上のsetuid bitをリセットし、これが実行されるようにします。setuid bitは、chgrpおよびchownコマンドによって変更されています。次のコマンドをrootとして実行します。

chmod 6550 /opt/oracle/dbserver/dbms/bin/dbrsMain

7. dbserverサービスを再起動します。次のコマンドをdbmadminユーザーとして実行します。

dbmcli -e alter dbserver startup services all

1.12 構成変更中のセルおよびデータベース・ノードの状態

表1-5は、構成変更中にセル・ノードとデータベース・ノードをオフラインとオンラインのどちらにしておく必要があるかを示しています。

表1-5 操作時のセルおよびデータベース・ノードの状態

操作

セル・ノード

データベース・ノード

DNSサーバーの更新

オンライン

オンライン

NTPサーバーの更新

オンライン

オンライン

タイム・ゾーンの更新

オフライン

オンライン

管理ネットワークのIPアドレス、ネットマスク、ゲートウェイ、ホスト名の変更

オフライン

オンライン

クライアント・ネットワークのIPアドレス、ネットマスク、ゲートウェイ、ホスト名の変更

オフライン

オンライン

ILOM IPアドレスの変更

オフライン

ipmitool sunoem getval/setvalコマンドがサポートされている場合はオンライン

その他のILOMパラメータの変更

ipmitool sunoem getval/setvalコマンドがサポートされている場合はオンライン

ipmitool sunoem getval/setvalコマンドがサポートされている場合はオンライン

InfiniBand IP、ネットマスク、ホスト名の変更

オフライン

オンライン

pkeyの変更

オフライン

オンライン

1.13 レスキュー計画

12.2.1.1.0より前のExadataリリースでは、ストレージ・サーバーまたはデータベース・サーバーのレスキュー後に、複数のコマンドを再実行して、IORMプラン、しきい値、ストレージ・サーバーおよびデータベース・サーバーの通知設定などの項目を構成する必要があります。

Oracle Exadataリリース12.2.1.1.0では、cellとdbserverの各オブジェクトにrescuePlanという新しい属性があります。データベース・サーバーとストレージ・サーバーの構成が完了したとき、rescuePlan属性の値をファイルに保存する必要があります。レスキューされたサーバーのデータはレスキュー時に消去されるため、ファイルをリモート・サーバーに保存する必要があります。サーバーのレスキュー後に、リモート・サーバーからファイルを取得し、ファイルを実行して設定をリストアできます。次の例3を参照してください。

セキュリティ上の理由から、レスキュー計画には、パスワードを必要とする構成は含めません。

例1-4 ストレージ・セルのレスキュー計画

ストレージ・サーバーのrescuePlan属性は、次のようになります。

$ cellcli -e list cell attributes rescuePlan

CREATE ROLE "admin"

GRANT PRIVILEGE all actions ON diagpack all attributes WITH all options TO ROLE "admin"

CREATE ROLE "diagRole"

GRANT PRIVILEGE download ON diagpack all attributes WITH all options TO ROLE "diagRole"

GRANT PRIVILEGE create ON diagpack all attributes WITH all options TO ROLE "diagRole"

GRANT PRIVILEGE list ON diagpack all attributes WITH all options TO ROLE "diagRole"

ALTER CELL accessLevelPerm="remoteLoginEnabled", diagHistoryDays="7", metricHistoryDays="7", notificationMethod="mail,snmp",
notificationPolicy="warning,critical,clear", snmpSubscriber=((host="localhost", port=162, community="public", type=asr)),
bbuLearnCycleTime="2016-10-17T02:00:00-07:00", bbuLearnSchedule="MONTH 1 DATE 17 HOUR 2 MINUTE 0",
alertSummaryStartTime="2016-09-21T17:00:00-07:00", alertSummaryInterval=weekly,
hardDiskScrubInterval=biweekly, hardDiskScrubFollowupIntervalInDays="14"

ALTER IORMPLAN objective=basic

例1-5 データベース・サーバーのレスキュー計画

データベース・サーバーのrescuePlan属性は、次のようになります。

$ dbmcli -e list dbserver attributes rescuePlan

CREATE ROLE "listdbserverattrs"

GRANT PRIVILEGE list ON dbserver ATTRIBUTES bbuStatus, coreCount WITH all options TO ROLE "listdbserverattrs"

ALTER DBSERVER diagHistoryDays="7", metricHistoryDays="7", bbuLearnSchedule="MONTH 1 DATE 17 HOUR 2 MINUTE 0",
alertSummaryStartTime="2016-09-26T08:00:00-07:00", alertSummaryInterval=weekly, pendingCoreCount="128" force

例1-6 セルのレスキュー計画スクリプトの作成

次のコマンドで、rescuePlan属性のコマンドが、リモート・サーバー上のrescue.cliというファイルに格納されます。

$ cellcli -e list cell attributes rescuePlan >& /location/on/remote/server/rescue_cell.cli

サーバーをレスキューする必要がある場合は、サーバーのレスキュー後にスクリプトを実行して設定をリストアできます。次のコマンドでは、CellCLIのstartコマンドを使用してrescue_cell.cliファイルを実行します。

$ cellcli -e start /location/on/remote/server/rescue_cell.cli

例1-7 データベース・サーバーのレスキュー計画スクリプトの作成

次のコマンドで、rescuePlan属性のコマンドが、リモート・サーバー上のrescue_db.cliというファイルに格納されます。

$ dbmcli -e list dbserver attributes rescuePlan >& /location/on/remote/server/rescue_db.cli

サーバーをレスキューする必要がある場合は、サーバーのレスキュー後にスクリプトを実行して設定をリストアできます。次のコマンドでは、CellCLIのstartコマンドを使用してrescue_cell.cliファイルを実行します。

$ dbmcli -e start /location/on/remote/server/rescue_db.cli

1.14 ExaWatcherチャート

ExaWatcherは、Exadataシステムのストレージ・サーバーおよびデータベース・サーバーのパフォーマンス・データを収集するユーティリティです。収集されるデータには、iostat、セル統計(cellsrvstat)、ネットワーク統計などのオペレーティング・システム統計情報が含まれます。

ExaWatcherで収集されたデータを抽出するには、GetExaWatcherResults.shを実行して、対象の時間範囲の開始時間と終了時間を指定します。結果は、ExtractedResultsというディレクトリの圧縮アーカイブ・ファイルに配置されます。

次に例を示します。

$ GetExaWatcherResults.sh --from 08/24/2016_17:00:00 --to 08/25/2016_17:00:00

注意:
GetExaWatcherResults.shで-cまたは--scpのオプションを使用して、結果のアーカイブ・ファイルを別の場所にコピーできます。

リリース12.2.1.1.0では、GetExaWatcherResults.shで、IO、CPU使用率、セル・サーバー統計およびアラート履歴のチャートを含むHTMLページも生成されます。IOとCPU使用率のチャートではiostatからのデータが使用され、CPUの詳細ではmpstatからのデータが使用され、セル・サーバー統計ではcellsrvstatからのデータが使用されます。アラート履歴は、指定した時間枠を対象として取得されます。

結果のアーカイブ・ファイルには、新しいチャートがあります。アーカイブ・ファイルには、Charts.ExaWatcher.<hostname>/<timestamp>_<duration>/ (例: Charts.ExaWatcher.xxxxceladm13.oracle.com/2016_08_24_17_00_00_01h00m00s_0)という名前のサブディレクトリがあります。

HTMLページを表示するには、インターネットにアクセスできるローカル・ブラウザを持つマシンにアーカイブ・ファイルを移動する必要があります。ファイルは、bz2圧縮ファイルを解凍してから、tar -xvfを使用してtarファイルを解凍する必要があります。その後、ブラウザでCharts.ExaWatcher.<hostname>/<timestamp>_<duration>/index.htmlを開くことができます。そのページの左パネルには、次のメニューが表示されます。

図1-1 左パネルのExaWatcherメニュー

注意:
スクリーン・リーダーのユーザーは、メニュー項目は上下の矢印キーを使用してナビゲートし、スペース・バーを使用してアクティブ化します。[Tab]キーを使用すると、右側のフレームに移動します。

「CellSrvStat」メニュー項目は、ストレージ・サーバーに対して実行した場合にのみ使用できます。「アラート履歴」メニュー項目は、要求した時間枠にアラートが発生した場合にのみ使用できます。

1.14.1 IOチャート

IO統計には2つのページがあります。

- IO統計サマリー

- I/O統計詳細

1.14.1.1 IO統計サマリー

IOStatサマリーには、サーバー全体のIOパフォーマンスのサマリーが示されます。このページには次の4つのチャートが表示されます。

表1-6 IOStatサマリーの統計

統計

説明

フラッシュIOP

ハード・ディスクIOP

サーバーの1秒当たりの読取りの合計数、1秒当たりの書込みの合計数および1秒当たりのIOの合計数(1秒当たりの読取り数 + 1秒当たりの書込み数)。

ここでは、iostatのr/sとw/sが使用されます。

フラッシュMB/s

ハード・ディスクMB/s

1秒当たりの読取りの合計量(MB)、1秒当たりの書込みの合計量(MB)および1秒当たりのIOの合計量(MB)。

ここでは、iostatのrsec/sとwsec/sが使用されてMBに変換されます。

統計は、適用可能な場合にフラッシュおよびハード・ディスクに対して表示されます。Exadata Extreme Flashには、ハード・ディスクはありません。データベース・サーバーには、フラッシュ・デバイスはありません。

I/Oのパフォーマンスの問題が疑われる場合は、ストレージ・サーバーのIOPとMB/sの統計をデータ・シートと比較して、ストレージが最大容量に達したかどうかを特定できます。データベースの確認された読取り回数が多い場合は、それをiostatからのサービス時間および平均待機時間と比較して、ストレージ・サーバーが原因で読取り回数が多い可能性があるかどうかを特定することもできます。通常、このデータベースでの回数には、フラッシュ・キャッシュおよびハード・ディスクで対応されたIOが含まれます。また、これらのチャートでは、時間枠内のピークをビジュアル化できます。

次の部分的なスクリーンショットに、フラッシュおよびハード・ディスクのIOPとMB/sのチャートを示します。

図1-2 IOサマリー・チャート

各チャートの下に、チャート内の特定の時間のドリルダウンに使用できる範囲セレクタがあります。いずれかのチャートの範囲セレクタを移動すると、ページ上のすべてのチャートに影響します。

注意:
範囲セレクタは、スクリーン・リーダーにアクセスできません。また、チャートに表示されるすべての値がスクリーン・リーダーにアクセスできるわけではありません。それぞれのチャートのデータ・ポイントの最初の値のみが該当します。

図1-3 範囲セレクタが表示されているIOサマリー・チャート

範囲セレクタを使用すると、表示されるチャートが変更されて、範囲セレクタで指定した時間枠のデータのみが表示されます。

1.14.1.2 I/O統計詳細

IOStat詳細には、ストレージ・サーバーの各ディスクのパフォーマンスが示されます。このページには、次のチャートが表示されます。

表1-7 IO統計詳細の統計

統計

説明

フラッシュ・サービス時間

ハード・ディスク・サービス時間

待機時間の範囲に対する、ディスクごとの平均サービス時間。

フラッシュ待機時間

ハード・ディスク待機時間

ディスクごとの平均待機時間

デフォルトでは、チャートには、サーバー上のすべてのディスクの平均を示す線が含まれます。影付きのバックグラウンド・イメージは、統計の最小と最大の範囲を示しています。ドロップダウン・セレクタを使用して、個別のディスクを表示することを選択できます。

バックグラウンド・イメージの範囲が広い場合は、ディスク・パフォーマンスに差異がある可能性があることを示します。このメトリックを使用して、ストレージ・サーバーの個々のディスクをより詳細に確認することで、不均衡が発生しているかどうかを知ることができます。バックグラウンド・イメージの範囲が狭い場合は、ディスクのパフォーマンスが似ていることを示します。

また、ストレージ・サーバーの個別のディスクのIOPとMB/sをデータ・シートの数値と比較して、ディスクが最大容量に達した可能性があるかどうかを確認することもできます。

図1-4 IO詳細チャート

1.14.2 CPUチャート

CPUチャートには、サーバーのCPU使用率が示されます。これらの統計は、iostat (avg-cpu: %user、%system、%iowait)に基づきます。

図1-5 CPUチャート

1.14.3 CPU詳細

CPU詳細チャートには、CPU IDごとのCPUの平均使用率などの、CPU使用状況の詳細情報が示されます。これらの統計は、mpstatに基づきます。

図1-6 CPU詳細チャート

1.14.4 セル・サーバー・チャート

セル・サーバー統計は、Exadata Storage Serverに固有の機能を追跡する場合に役立ちます。このページには、スマート・フラッシュ・キャッシュおよびスマートIOに関連する統計が示されます。

図1-7 セル・サーバー・チャート

1.14.5 アラート履歴

このページには、指定した時間枠に表示されたアラートが示されます。アラートは、サーバーでのIOのパフォーマンスの問題を引き起こす可能性のあるエラーまたは問題によって生成される場合があります。

図1-8 アラート履歴

2 Oracle Exadata Database Machineのデータベース・サーバーの保守

この章のトピックは、次のとおりです:

- データベース・サーバー上の管理サーバー

- Oracle Database Serverの物理ディスクの保守

- データベース・サーバーへのディスク拡張キットの追加

- データベース・サーバーへのメモリー拡張キットの追加

- Oracle Exadata X6-2でのネットワーク・カードの追加および構成

- データベース・サーバーのアクティブ・コア数の増加

- ベア・メタルOracle RACクラスタからOracle VMのOracle RACクラスタへの移行

- Oracle Exadata Database MachineのOracle VMドメインの管理

- LVMパーティションの拡張

- Oracle Linuxデータベース・サーバーのスナップショット・ベースのバックアップの作成

- Oracle Virtual Serverデプロイメントの管理ドメイン(dom0)とユーザー・ドメイン(domU)のバックアップ

- スナップショット・ベースのバックアップを使用したOracle Linuxデータベース・サーバーのリカバリ

- Oracle Virtual Serverデプロイメントでのリカバリ

- Oracle Linuxデータベース・サーバーの更新

- Oracle Linuxデータベース・サーバーの再イメージ化

- データベース・サーバーの既存のエラスティック構成の変更

- 高冗長性ディスク・グループのためのQuorumディスクの管理

- vmetricsの使用

注意:

読みやすさを考慮して、Oracle Exadata Database MachineとOracle Exadata Storage拡張ラックの両方に言及する場合、「Oracle Exadataラック」という名前を使用します。

2.1 データベース・サーバー上の管理サーバー

データベース・サーバー上で実行される管理サーバー(MS)は監視やアラートなどの管理機能を提供します。DBMCLIコマンドライン管理ツールも提供します。

関連項目:

- Oracle Exadata Database Machineシステム概要ガイドのデータベース・サーバー上の管理サーバー

- DBMCLIユーティリティの使用

2.2 Oracle Database Serverの物理ディスクの保守

物理ディスクを修理する際には、Oracle Exadata Database Machineのデータベース・サーバーをシャットダウンする必要はありません。ラックの停止時間は必要ありませんが、個別のサーバーが停止して、一時的にクラスタの外部で処理される場合があります。

この項の内容は次のとおりです。

- データベース・サーバー構成の検証

- データベース・サーバーRAIDセットの再構築の監視

- Oracle Exadata Storage Server Softwareリリース12.1.2.1.0以上へのアップグレード後のホット・スペア・ドライブのリクレイム

- 自動ファイル削除のポリシーについて

関連項目:

- 修理手順は、「Oracle Database Serverの部品」を参照してください。

- LEDの詳細は、「LEDステータスの説明」を参照してください

2.2.1 データベース・サーバー構成の検証

各データベース・サーバーのディスク・ドライブは、LSI MegaRAID SAS 9261-8iまたは9361-8iディスク・コントローラによって管理されます。

ディスクの構成はRAID-5構成です。Oracle Exadata Database Machine X6-2、Oracle Exadata Database Machine X5-2、Oracle Exadata Database Machine X4-2、Oracle Exadata Database Machine X3-2およびOracle Exadata Database Machine X2-2の各データベース・サーバーには4つのディスク・ドライブがあります。各Oracle Exadata Database Machine X4-8フル・ラック・データベース・サーバーには、7つのドライブがあります。デフォルトでは、1つのグローバル・ホット・スペア・ドライブを搭載した1つの6ディスクRAID-5として構成されます。Oracle Exadata Database Machine X5-8およびOracle Exadata Database Machine X3-8にはそれぞれ8つのディスク・ドライブがあります。RAIDセットには、仮想ドライブが1つ作成されています。

データベース・サーバーRAIDデバイスのステータスを確認して、パフォーマンスへの影響がないか、または停止しないようにすることをお薦めします。RAIDデバイスの検証による影響は最小です。是正処置による影響は未対応の特定の問題によって異なり、単純な再構成から停止が必要になる場合があります。

2.2.1.1 ディスク・コントローラ構成の検証

次のコマンドを使用して、データベース・サーバーのディスク・コントローラ構成を確認します。

/opt/MegaRAID/MegaCli/MegaCli64 -AdpAllInfo -aALL | grep "Device Present" -A 8

次に、Oracle Exadata Database Machine X3-2またはOracle Exadata Database Machine X2-2の場合のコマンドの出力例を示します。

Device Present
================
Virtual Drives    : 1
Degraded        : 0
Offline         : 0
Physical Devices  : 5
Disks           : 4
Critical Disks  : 0
Failed Disks    : 0

次に、Oracle Exadata Database Machine X4-8フル・ラックのコマンドの出力例を示します。

Device Present
================
Virtual Drives    : 1
Degraded        : 0
Offline         : 0
Physical Devices  : 8
Disks           : 7
Critical Disks  : 0
Failed Disks    : 0

次に、Oracle Exadata Database Machine X5-8フル・ラックのコマンドの出力例を示します。

Device Present
================
Virtual Drives   : 1
Degraded       : 0
Offline        : 0
Physical Devices : 9
Disks          : 8
Critical Disks : 0
Failed Disks   : 0

Oracle Exadata Database Machine X4-2、Oracle Exadata Database Machine X3-2およびOracle Exadata Database Machine X2-2の場合、予想される出力は仮想ドライブ1、パフォーマンス低下0、オフライン0、物理デバイス5 (1つのコントローラ + 4つのディスク)、ディスク4、クリティカル・ディスク0、障害が発生したディスク0です。

Oracle Exadata Database Machine X3-8フル・ラックおよびOracle Exadata Database Machine X2-8フル・ラックの場合、予想される出力は仮想ドライブ1、パフォーマンス低下0、オフライン0、物理デバイス11 (1つのコントローラ1 + 2つのSAS2拡張ポート + 8つのディスク)、ディスク8、クリティカル・ディスク0、障害が発生したディスク0です。

出力が異なる場合は、問題点を調査して修正します。パフォーマンスが低下した仮想ドライブは、通常は存在しない物理ディスクまたは障害が発生したディスクです。ノードで障害が発生したディスクの数が、システムの動作を維持するのに必要な数を超えた場合は、データ損失のリスクを回避するために、クリティカル・ディスクをすぐに交換してください。障害が発生したディスクもすぐに交換してください。

注意:

その他の仮想ドライブまたはホット・スペアが存在する場合は、デプロイ時にディスク再利用手順が実行されなかったか、dualboot=no修飾子を使用せずにベア・メタル・リストア手順が実行された可能性があります。詳細または是正処置は、My Oracle Supportノート1323309.1を参照してください。

ホット・スペアがあるデータベース・サーバーをOracle Exadata Storage Server Softwareリリース11.2.3.2.0以上にアップグレードする場合、ホット・スペアは削除され、アクティブ・ドライブとしてRAID構成に追加されます。データベース・サーバーはRAID 5冗長性の観点では同じ可用性で稼働し続け、ドライブが1つ失われても存続できます。ドライブで障害が発生した場合は、自動サービス・リクエストにより、そのドライブをできるだけ早く交換するように求める通知が送信されます。

2.2.1.2 仮想ドライブ構成の検証

仮想ドライブの構成を検証するには、次のコマンドを使用して、仮想ドライブの構成を検証します。

/opt/MegaRAID/MegaCli/MegaCli64 CfgDsply -aALL | grep "Virtual Drive:";    \
/opt/MegaRAID/MegaCli/MegaCli64 CfgDsply -aALL | grep "Number Of Drives";  \
/opt/MegaRAID/MegaCli/MegaCli64 CfgDsply -aALL | grep "^State"

次に、Oracle Exadata Database Machine X4-2、Oracle Exadata Database Machine X3-2およびOracle Exadata Database Machine X2-2の場合の出力例を示します。仮想デバイス0は4つのドライブを持ち、状態はOptimalです。

Virtual Drive                 : 0 (Target Id: 0)
Number Of Drives              : 4
State                         : Optimal

Oracle Exadata Database Machine X3-8フル・ラックおよびOracle Exadata Database Machine X2-8フル・ラックの場合は、仮想デバイスが8つのドライブを持ち、状態がOptimalであることを示す出力が表示されると予想されます。

注意:

データベース・サーバーでdualboot=noオプションを使用しないでディスク交換がされた場合、データベース・サーバーには3つの仮想デバイスがある可能性があります。詳細または是正処置は、My Oracle Supportノート1323309.1を参照してください。

2.2.1.3 物理ドライブ構成の検証

物理ドライブの構成を検証するには、次のコマンドを使用して、データベース・サーバーの物理ドライブの構成を検証します。

Linuxの場合は、次のコマンドを使用して、データベース・サーバーの物理ドライブの構成を検証します。

/opt/MegaRAID/MegaCli/MegaCli64 -PDList -aALL | grep "Firmware state"

次に、Oracle Exadata Database Machine X4-2、Oracle Exadata Database Machine X3-2およびOracle Exadata Database Machine X2-2の場合の出力例を示します。ドライブはOnline, Spun Upです。出力順序は重要ではありません。Oracle Exadata Database Machine X3-8フル・ラックまたはOracle Exadata Database Machine X2-8フル・ラックの場合は、Online, Spun Upの状態を示す出力が8行になります。

Firmware state: Online, Spun Up
Firmware state: Online, Spun Up
Firmware state: Online, Spun Up
Firmware state: Online, Spun Up

出力が異なる場合は、問題点を調査して修正します。

パフォーマンスが低下した仮想ドライブは、通常は存在しない物理ディスクまたは障害が発生したディスクです。ノードで障害が発生したディスクの数が、システムの動作を維持するのに必要な数を超えた場合は、データ損失のリスクを回避するために、クリティカル・ディスクをすぐに交換してください。障害が発生したディスクもすぐに交換してください。

2.2.2 データベース・サーバーRAIDセットの再構築の監視

データベース・サーバーのRAIDセットのドライブを交換した場合は、RAIDセットの再構築の進捗状況を監視する必要があります。

ディスクを交換したデータベース・サーバーで次のコマンドを使用します。コマンドはrootユーザーとして実行します。

/opt/MegaRAID/MegaCli/MegaCli64 -pdrbld -showprog -physdrv \
[disk_enclosure:slot_number] -a0

前述のコマンドで、disk_enclosureおよびslot_numberは、MegaCli64 -PDListコマンドによって識別された交換ディスクを示します。次に、コマンドの出力例を示します。

Rebuild Progress on Device at Enclosure 252, Slot 2 Completed 41% in 13 Minutes.

2.2.3 Oracle Exadata Storage Server Softwareリリース12.1.2.1.0以上へのアップグレード後のホット・スペア・ドライブのリクレイム

Oracle Exadata Storage Server Softwareリリース12.1.2.1.0以上にアップグレードしたホット・スペア・ドライブがあるOracle Exadata Database Machinesは、reclaimdisks.shスクリプトを使用してドライブをリクレイムできません。手動でドライブをリクレイムする手順は、次のとおりです。

注意:

この手順の実行中に、データベース・サーバーが2度再起動されます。この項の手順では、サーバーの再起動の後、Grid Infrastructureの再起動が無効であることを前提としています。

ディスクが4つあるOracle Exadata Database Machine X2-2データベース・サーバーの出力例を、次に示します。エンクロージャ識別子、スロット番号などは、使用するシステムにより異なる場合があります。

1. 次のコマンドを使用して、ホット・スペア・ドライブを識別します。

# /opt/MegaRAID/MegaCli/MegaCli64 -PDList -aALL

ホット・スペア・ドライブのコマンドの出力例を、次に示します。

...
Enclosure Device ID: 252
Slot Number: 3
Enclosure position: N/A
Device Id: 8
WWN: 5000CCA00A9FAA5F
Sequence Number: 2
Media Error Count: 0
Other Error Count: 0
Predictive Failure Count: 0
Last Predictive Failure Event Seq Number: 0
PD Type: SAS
Hotspare Information:
Type: Global, with enclosure affinity, is revertible

Raw Size: 279.396 GB [0x22ecb25c Sectors]
Non Coerced Size: 278.896 GB [0x22dcb25c Sectors]
Coerced Size: 278.464 GB [0x22cee000 Sectors]
Sector Size: 0
Logical Sector Size: 0
Physical Sector Size: 0
Firmware state: Hotspare, Spun down
Device Firmware Level: A2A8
Shield Counter: 0
Successful diagnostics completion on : N/A
...

コマンドが、ホット・スペア・ドライブをエンクロージャ識別子252、スロット3で識別しました。

2. 次のコマンドを使用して、仮想ドライブの情報を取得します。

# /opt/MegaRAID/MegaCli/MegaCli64 -LDInfo -Lall -Aall

次に、コマンドの出力例を示します。

Adapter 0 -- Virtual Drive Information:
Virtual Drive: 0 (Target Id: 0)
Name :DBSYS
RAID Level : Primary-5, Secondary-0, RAID Level Qualifier-3
Size : 556.929 GB
Sector Size : 512
Is VD emulated : No
Parity Size : 278.464 GB
State : Optimal
Strip Size : 1.0 MB
Number Of Drives : 3
Span Depth : 1
Default Cache Policy: WriteBack, ReadAheadNone, Direct, No Write Cache if Bad BBU
Current Cache Policy: WriteBack, ReadAheadNone, Direct, No Write Cache if Bad BBU
Default Access Policy: Read/Write
Current Access Policy: Read/Write
Disk Cache Policy : Disabled
Encryption Type : None
Is VD Cached: No

コマンドが、仮想ドライブ0のRAID 5構成をアダプタ0で識別しました。

3. 次のコマンドを使用して、ホット・スペア・ドライブを削除します。

# /opt/MegaRAID/MegaCli/MegaCli64 -PDHSP -Rmv -PhysDrv[252:3] -a0

4. 次のコマンドを使用して、ドライブをアクティブRAID 5ドライブとして追加します。

# /opt/MegaRAID/MegaCli/MegaCli64 -LDRecon -Start -r5     \
-Add -PhysDrv[252:3] -L0 -a0

Start Reconstruction of Virtual Drive Success.
Exit Code: 0x00

注意:

Failed to Start Reconstruction of Virtual Driveというメッセージが表示された場合は、My Oracle Supportノート1505157.1「Failed to Start Reconstruction of Virtual Drive - Adding a hot-spare manually」の手順に従ってください。

5. 次のコマンドを使用して、RAID再構築の進捗状況を監視します。

# /opt/MegaRAID/MegaCli/MegaCli64 -LDRecon -ShowProg -L0 -a0

Reconstruction on VD #0 (target id #0) Completed 1% in 2 Minutes.

ホット・スペア・ドライブがRAID 5に追加され、再構築が終了した場合に表示されるコマンドの出力例を、次に示します。

Reconstruction on VD #0 is not in Progress.

6. 次のコマンドを使用して、ドライブの数を確認します。

# /opt/MegaRAID/MegaCli/MegaCli64 -LDInfo -Lall -Aall

次に、コマンドの出力例を示します。

Adapter 0 -- Virtual Drive Information:
Virtual Drive: 0 (Target Id: 0)
Name :DBSYS
RAID Level : Primary-5, Secondary-0, RAID Level Qualifier-3
Size : 835.394 GB
Sector Size : 512
Is VD emulated : No
Parity Size : 278.464 GB
State : Optimal
Strip Size : 1.0 MB
Number Of Drives : 4
Span Depth : 1
Default Cache Policy: WriteBack, ReadAheadNone, Direct, No Write Cache if Bad BBU
Current Cache Policy: WriteBack, ReadAheadNone, Direct, No Write Cache if Bad BBU
Default Access Policy: Read/Write
Current Access Policy: Read/Write
Disk Cache Policy : Disabled
Encryption Type : None
Is VD Cached: No

7. 次のコマンドを使用して、RAIDのサイズをチェックします。

# parted /dev/sda print

Model: LSI MR9261-8i (scsi)
Disk /dev/sda: 598GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos

Number Start End Size Type File system Flags
1 32.3kB 132MB 132MB primary ext3 boot
2 132MB 598GB 598GB primary lvm

8. 変更を有効にするためにサーバーを再起動します。

9. 次のコマンドを使用して、RAIDのサイズをチェックします。

# parted /dev/sda print

Model: LSI MR9261-8i (scsi)
Disk /dev/sda: 897GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos

Number Start End Size Type File system Flags
1 32.3kB 132MB 132MB primary ext3 boot
2 132MB 598GB 598GB primary lvm

RAIDのサイズが大きいと、ボリューム・グループを拡張できます。ボリューム・グループを拡張するには、ドライブにパーティションを更に追加する必要があります。

10. 次のコマンドを使用して、セクター内に新しいサイズを取得します。

# parted /dev/sda

GNU Parted 2.1
Using /dev/sda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) unit s
(parted) print
Model: LSI MR9261-8i (scsi)
Disk /dev/sda: 1751949312s
Sector size (logical/physical): 512B/4096B
Partition Table: msdos

Number Start End Size Type File system Flags
1 63s 257039s 256977s primary ext3 boot
2 257040s 1167957629s 1167700590s primary lvm

上記の例では、セクター1167957630で開始し、ディスクの末尾のセクター1751949311で終了する3番目のパーティションが作成されます。

11. 次のコマンドを使用して、ドライブに追加のパーティションを作成します。

# parted /dev/sda

GNU Parted 2.1
Using /dev/sda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) unit s

(parted) mkpart

Partition type? primary/extended? primary
File system type? [ext2]? ext2
Start? 1167957630
End? 1751949311
Warning: The resulting partition is not properly aligned for best performance.
Ignore/Cancel? Ignore
Warning: WARNING: the kernel failed to re-read the partition table on /dev/sda (Device or resource busy). As a
result, it may not reflect all of your changes until after reboot.
(parted)

(parted) print
Model: LSI MR9261-8i (scsi)
Disk /dev/sda: 1751949312s
Sector size (logical/physical): 512B/4096B
Partition Table: msdos

Number Start End Size Type File system Flags
1 63s 257039s 256977s primary ext3 boot
2 257040s 1167957629s 1167700590s primary lvm
3 1167957630s 1751949311s 583991682s primary

(parted) set 3 lvm on

Warning: WARNING: the kernel failed to re-read the partition table on /dev/sda (Device or resource busy). As a
result, it may not reflect all of your changes until after reboot.
(parted) print
Model: LSI MR9261-8i (scsi)
Disk /dev/sda: 1751949312s
Sector size (logical/physical): 512B/4096B
Partition Table: msdos

Number Start End Size Type File system Flags
1 63s 257039s 256977s primary ext3 boot
2 257040s 1167957629s 1167700590s primary lvm
3 1167957630s 1751949311s 583991682s primary lvm

12. データベース・サーバーを再起動します。

13. 次のコマンドを使用して、物理ボリュームを作成します。

# pvcreate /dev/partition_name

14. 次のコマンドを使用して、物理ボリュームを既存のボリューム・グループに追加します。

# vgextend volume_group /dev/partition_name

Volume group "volume_name" successfully extended

15. 「LVMパーティションの拡張」の手順に従い、論理ボリュームおよびファイル・システムのサイズを変更します。

2.2.4 自動ファイル削除のポリシーについて

Management Server (MS)には、データベース・サーバー内の/ (root)ディレクトリからファイルを削除するポリシーがあり、ファイル・システムの使用率が高い場合にトリガーされます。ファイルの削除はファイル使用率が80パーセントの場合にトリガーされ、削除開始前にアラートが送信されます。アラートには、ディレクトリの名前と、サブディレクトリの領域の使用率が含まれます。削除ポリシーは次のとおりです。

次に示すディレクトリ内のファイルは、ファイル変更のタイム・スタンプに基づいたポリシーを使用して削除されます。

- /opt/oracle/dbserver/log

- /opt/oracle/dbserver/dbms/deploy/config/metrics

- /opt/oracle/dbserver/dbms/deploy/log

metricHistoryDays属性によって設定された日数より古いファイルが最初に削除され、続けて古いファイルから変更タイムスタンプが10分以前のファイル、またはファイル・システムの使用率が75パーセントまでのファイルが削除されます。metricHistoryDays属性は/opt/oracle/dbserver/dbms/deploy/config/metrics内のファイルに適用されます。その他のログ・ファイルとトレース・ファイルには、diagHistoryDays属性を使用します。

12.1.2.2.0以上では、ms-odl.trcファイルとms-odl.logファイルの領域の最大容量は、trcファイル用が100MB (20個の5MBファイル)、logファイル用が100MB (20個の5MBファイル)です。以前は、trcファイルとlogファイルの両方とも、50MB (10個の5MBファイル)でした。

ms-odl生成ファイルは5MBに達すると名前が変更され、100MBの領域を使い切ると、最も古いファイルが削除されます。

2.3 データベース・サーバーへのディスク拡張キットの追加

ディスクの追加手順は、次のとおりです。

注意:

- ディスク拡張キットはOracle Exadata Database Machine X5-2およびX6-2システムでのみサポートされています。

- Oracle Exadataソフトウェア12.1.2.3.0以上が必要です。

1. プラスチック・フィルタをディスク拡張キットの4つのドライブに交換します。

2. ディスク拡張キットが検出され、既存のRAID5構成にそれらのドライブが自動的に追加されたこと、および対応する仮想ドライブの再構築を開始することを通知するアラートが生成されます。

3. 仮想ドライブの再構築が完了したときに、再度アラートが生成されます。

4. /opt/oracle.SupportTools/reclaimdisks.sh -extend-vgexadbを実行し、VGExaDbボリューム・グループを/dev/sdaシステム・ディスクの残存領域まで拡張します。

注意:

reclaimdisks.shは、データベース・ソフトウェアがインストールされる前の、初回のデプロイメント中にのみ機能します。すでにしばらくOracle Exadata Database Machineを実行している場合は、初回のデプロイメント中にすでにこれを実行しているため、実行する必要はありません。初回のデプロイメント中にこれが実行されなかった場合、この時点では、/u01に加えられた変更が多すぎるため、実行できません。reclaimdisks.shでは、/u01ファイル・システムに対する変更を検出すると、エラー・メッセージを返します。デフォルトでは、新しいシステムでは/u01ファイル・システムは空です。

注意:

このコマンドは仮想ドライブの再構築が完了した後にのみ実行してください。完了前に実行した場合、次のメッセージが表示されます。

[WARNING ] Reconstruction of the logical drive 0 is in progress: Completed: 14%. Left: 5 Hours 32 Minutes
[WARNING ] Continue after reconstruction is complete

この場合は、仮想ドライブの再構築が完了してから再度コマンドを実行します。

GPT (GUIDパーティション表)を修復するか、または現在の設定で続行するかを尋ねるプロンプトが表示された場合は、"F"を入力してGPTを修復します。

[root@dbnode01 ~]# /opt/oracle.SupportTools/reclaimdisks.sh -extend-vgexadb
Model is ORACLE SERVER X6-2
Number of LSI controllers: 1
Physical disks found: 8 (252:0 252:1 252:2 252:3 252:4 252:5 252:6 252:7)
Logical drives found: 1
Linux logical drive: 0
RAID Level for the Linux logical drive: 5
Physical disks in the Linux logical drive: 8 (252:0 252:1 252:2 252:3 252:4 252:5 252:6 252:7)
Dedicated Hot Spares for the Linux logical drive: 0
Global Hot Spares: 0
Valid. Disks configuration: RAID5 from 8 disks with no global and dedicated hot spare disks.
Valid. Booted: Linux. Layout: Linux + DOM0.
[INFO     ] Size of system block device /dev/sda: 4193GB
[INFO     ] Last partition on /dev/sda ends on: 1797GB
[INFO     ] Unused space detected on the system block device: /dev/sda
[INFO     ] Label of partition table on /dev/sda: gpt
[INFO     ] Adjust the partition table to use all of the space on /dev/sda
[INFO     ] Respond to the following prompt by typing 'F'
Warning: Not all of the space available to /dev/sda appears to be used, you can fix the GPT to use all of the space (an extra 4679680000 blocks) or
continue with the current setting?
Fix/Ignore? F
Model: LSI MR9361-8i (scsi)
Disk /dev/sda: 4193GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system  Name     Flags
1      32.8kB  537MB   537MB   ext4         primary  boot
2      537MB   123GB   122GB                primary  lvm
3      123GB   1690GB  1567GB               primary
4      1690GB  1797GB  107GB                primary  lvm

[INFO     ] Check for Linux with inactive DOM0 system disk
[INFO     ] Valid Linux with inactive DOM0 system disk is detected
[INFO     ] Number of partitions on the system device /dev/sda: 4
[INFO     ] Higher partition number on the system device /dev/sda: 4
[INFO     ] Last sector on the system device /dev/sda: 8189440000
[INFO     ] End sector of the last partition on the system device /dev/sda: 3509759000
[INFO     ] Unmount /u01 from /dev/mapper/VGExaDbOra-LVDbOra1
[INFO     ] Remove inactive system logical volume /dev/VGExaDb/LVDbSys3
[INFO     ] Remove xen files from /boot
[INFO     ] Remove logical volume /dev/VGExaDbOra/LVDbOra1
[INFO     ] Remove volume group VGExaDbOra
[INFO     ] Remove physical volume /dev/sda4
[INFO     ] Remove partition /dev/sda4
[INFO     ] Remove device /dev/sda4
[INFO     ] Remove partition /dev/sda3
[INFO     ] Remove device /dev/sda3
[INFO     ] Create primary partition 3 using 240132160 8189439966
[INFO     ] Set lvm flag for the primary partition 3 on device /dev/sda
[INFO     ] Add device /dev/sda3
[INFO     ] Primary LVM partition /dev/sda3 has size 7949307807 sectors
[INFO     ] Create physical volume on partition /dev/sda3
[INFO     ] LVM Physical Volume /dev/sda3 has size 3654340511 sectors
[INFO     ] Size of LVM physical volume less than size of device /dev/sda3
[INFO     ] Remove LVM physical volume /dev/sda3
[INFO     ] Reboot is required to apply the changes in the partition table

5. 必要であればノードを再起動し、パーティション表に変更を適用します。再起動が必要な場合は、前述のコマンドのメッセージの末尾にそのように表示されます。

[root@dbnode01 ~]# reboot

再起動が不要の場合は、手順7に進みます。

6. /opt/oracle.SupportTools/reclaimdisks.sh -extend-vgexadbを実行します。

この手順は、お客様が追加領域を使用して何を実行するかに応じて異なります。たとえば、既存のボリューム・グループのサイズを大きくしたり、追加領域を使用する新しいVGを作成してマウントすることができます。

このコマンドで次のようなエラーが表示されることがあります。このエラーは無視しても問題ありません。

[root@dbnode01 ~]# /opt/oracle.SupportTools/reclaimdisks.sh -extend-vgexadb
Model is ORACLE SERVER X6-2
Number of LSI controllers: 1
Physical disks found: 8 (252:0 252:1 252:2 252:3 252:4 252:5 252:6 252:7)
Logical drives found: 1
Linux logical drive: 0
RAID Level for the Linux logical drive: 5
Physical disks in the Linux logical drive: 8 (252:0 252:1 252:2 252:3 252:4 252:5 252:6 252:7)
Dedicated Hot Spares for the Linux logical drive: 0
Global Hot Spares: 0
Valid. Disks configuration: RAID5 from 8 disks with no global and dedicated hot spare disks.
Valid. Booted: Linux. Layout: Linux.
[INFO     ] Check for Linux system disk
[INFO     ] Number of partitions on the system device /dev/sda: 4
[INFO     ] Higher partition number on the system device /dev/sda: 4
[INFO     ] Last sector on the system device /dev/sda: 8189440000
[INFO     ] End sector of the last partition on the system device /dev/sda: 8189439966
[INFO     ] Next free available partition on the system device /dev/sda:
[INFO     ] Primary LVM partition /dev/sda4 has size 4679680000 sectors
[INFO     ] Create physical volume on partition /dev/sda4
[INFO     ] LVM Physical Volume /dev/sda4 has size 4679680000 sectors
[INFO     ] Size of LVM physical volume matches size of primary LVM partition /dev/sda4
[INFO     ] Extend volume group VGExaDb with physical volume on /dev/sda4
[INFO     ] Create 100Gb logical volume for DBORA partition in volume group VGExaDb
[WARNING  ] Failed command at attempt: lvm lvcreate -L 100GB -n LVDbOra1 VGExaDb at 1/1
[ERROR    ] Failed command: lvm lvcreate -L 100GB -n LVDbOra1 VGExaDb
[ERROR    ] Unable to create logical volume LVDbOra1 in volume group VGExaDb
[ERROR    ] Unable to reclaim all disk space

7. 確認のため、/opt/oracle.SupportTools/reclaimdisks.shを実行します。

[root@dbnode01 ~]# /opt/oracle.SupportTools/reclaimdisks.sh
Model is ORACLE SERVER X6-2
Number of LSI controllers: 1
Physical disks found: 8 (252:0 252:1 252:2 252:3 252:4 252:5 252:6 252:7)
Logical drives found: 1
Linux logical drive: 0
RAID Level for the Linux logical drive: 5
Physical disks in the Linux logical drive: 8 (252:0 252:1 252:2 252:3 252:4 252:5 252:6 252:7)
Dedicated Hot Spares for the Linux logical drive: 0
Global Hot Spares: 0
Valid. Disks configuration: RAID5 from 8 disks with no global and dedicated hot spare disks.
Valid. Booted: Linux. Layout: Linux.

8. 「LVMパーティションの拡張」の手順に従い、論理ボリュームおよびファイル・システムのサイズを変更します。

2.4 データベース・サーバーへのメモリー拡張キットの追加

データベース・サーバーにはメモリーを追加できます。メモリーの追加手順は、次のとおりです。

1. データベース・サーバーの電源を切ります。

2. プラスチック・フィルタをDIMMに交換します。

- X6-2: Oracle Server X6-2サービス・マニュアルのDIMMのサービス(CRU)に関する項(http://docs.oracle.com/cd/E62159_01/html/E62171/z40003f01425075.html#scrolltoc)を参照してください

- X5-2: Oracle Server X5-2サービス・マニュアルのDIMMのサービス(CRU)に関する項(http://docs.oracle.com/cd/E41059_01/html/E48320/z40003f01425075.html)を参照してください

- X4-8: Sun Server X4-8サービス・マニュアルの障害が発生したDIMMの交換に関する項(http://docs.oracle.com/cd/E40591_01/html/E40317/gnsdu.html#scrolltoc)を参照してください

- X4-2: Sun Server X4-2サービス・マニュアルのDIMMのサービス(CRU)に関する項(http://docs.oracle.com/cd/E36975_01/html/E38045/z40003f01425075.html#scrolltoc)を参照してください

- X3-2: Sun Server X3-2 (旧称Sun Fire X4170 M3)サービス・マニュアルのDIMMのサービス(CRU)に関する項(http://docs.oracle.com/cd/E22368_01/html/E27242/z40003f01425075.html#scrolltoc)を参照してください

- X2-8: Sun Server X2-8 (旧称Sun Fire X4800 M2)サービス・マニュアルのDIMMの取外しおよび取付け(CRU)に関する項(http://docs.oracle.com/cd/E20815_01/html/E20819/gjfvw.html#scrolltoc)を参照してください

- Sun Fire X4170 M2: Sun Fire X4170 M2 Serverサービス・マニュアルのDDR3 DIMMのサービスに関する項(http://docs.oracle.com/cd/E19762-01/E22369-02/motherboard_x4170.html#50581523_71526)を参照してください

3. データベース・サーバーの電源を投入します。

4. データベース・サーバーをクラスタに接続します。

注意:

- Sun Server X4-2 Oracle Database ServerおよびSun Server X3-2 Oracle Database Server用のメモリーは、メモリー拡張キットを使用して最大512GBに拡張できます。

- Sun Fire X4170 Oracle Database Serverのメモリーは、既存のメモリーを取り外して、3個のX2-2メモリー拡張キットと交換することで、最大144GBに拡張できます。

- Sun Fire X4170 M2 Oracle Database Serverは、8GB DIMMを使用した18個のDIMMスロットのうち12個が搭載された96GBのメモリーで工場から出荷されます。オプションのX2-2メモリー拡張キットを使用すると、残りの6つの空スロットに16GB DIMMを使用して合計メモリーを192GB (12 x 8GBおよび6 x 16GB)に拡張できます。
メモリー拡張キットは、主に各データベース・サーバー上で多くのデータベースを実行する場合のワークロード統合用です。このシナリオでは、メモリー使用率が非常に高くても、CPU使用率が低いことがよくあります。

ただし、DIMMメモリーの周波数が1333MHzから800MHzに落ちるため、すべてのメモリー・スロットの使用量は減ります。メモリーのパフォーマンス効果が遅いので、CPU使用率が高くなったように感じます。CPU使用率を測定すると、通常、増加率は平均して5%から10%です。増加量はワークロードによって大きく異なります。テスト用ワークロードでは、複数ワークロードの場合、増加率はほぼゼロでしたが、1つのワークロードの場合の増加率は約20%でした。

- Oracle Linuxを実行しているOracle Exadata Database Machineにメモリーを追加する場合、次の値を使用して/etc/security/limits.confファイルを更新することをお薦めします。

oracle    soft     memlock 75%
oracle    hard     memlock 75%

2.5 Oracle Exadata X6-2でのネットワーク・カードの追加および構成

Oracle Exadataデータベース・サーバーX6-2では、マザーボードで高可用性の銅線10Gネットワークが提供され、スロット2のPCIカードを介して光学10Gネットワークが提供されます。オラクル社では、追加の接続を必要とするお客様のために追加のイーサネット・カードを用意しています。追加のカードにより、デュアル・ポートの10GEの銅線接続(部品番号7100488)またはデュアル・ポートの10GEの光学接続(部品番号X1109A-Z)が提供されます。Oracle Exadata X6-2データベース・サーバーのPCIeスロット1にこのカードを設置します。

設置してネットワークに接続すると、Exadataソフトウェア12.2.1.1.0は自動的に新しいカードを認識し、データベース・サーバーのeth6およびeth7インタフェースとして2つのポートを構成します。これらの追加のポートを使用して追加のクライアント・ネットワークを提供することも、個別のバックアップまたはデータ・リカバリ・ネットワークを作成することもできます。仮想マシンを実行するデータベース・サーバーでは、これを使用して2つの仮想マシンからトラフィックを分離できます。

データベース・サーバーにカードを追加した後、カードを構成する必要があります。次の項を参照してください。

- 非Oracle VM環境での追加のネットワーク・カードの構成

- Oracle VM環境での追加のネットワーク・カードの構成

ネットワーク・インタフェースを表示するには、ipconf.plコマンドを実行します。次に、ネットワーク・カードを追加していないX6-2データベース・サーバーの出力例を示します。

# cd /opt/oracle.cellos/

# ./ipconf.pl
Logging started to /var/log/cellos/ipconf.log
Interface ib0   is                      Linked.    hca: mlx4_0
Interface ib1   is                      Linked.    hca: mlx4_0
Interface eth0  is                      Linked.    driver/mac: ixgbe/00:10:e0:8b:24:b6
Interface eth1  is .....                Linked.    driver/mac: ixgbe/00:10:e0:8b:24:b7
Interface eth2  is .....                Linked.    driver/mac: ixgbe/00:10:e0:8b:24:b8
Interface eth3  is .....                Linked.    driver/mac: ixgbe/00:10:e0:8b:24:b9
Interface eth4  is                      Linked.    driver/mac: ixgbe/90:e2:ba:ac:20:ec (slave of bondeth0)
Interface eth5  is                      Linked.    driver/mac: ixgbe/90:e2:ba:ac:20:ec (slave of bondeth0)

出力には2つのネットワーク・カードが示されます。

- eth0からeth3のクアッド・ポート10Gbカード

- eth4およびeth5のデュアル・ポート10Gbカード

2.5.1 非Oracle VM環境での追加のネットワーク・カードの構成

非Oracle Virtual Machine (Oracle VM)環境でOracle Exadata X6-2データベース・サーバーに追加のネットワーク・カードを構成できます。

この手順は、すでにOracle Exadata X6-2データベース・サーバーにネットワーク・カードを設置していることを前提としています。

1. 新しいネットワーク・カードについて、次の情報を確認します。
ipconf.plを実行するとき、この情報を入力することが必要になります。

- IPアドレス

- ネットマスク

- ゲートウェイ

2. ipconf.plスクリプトを実行して、カードを構成します。

次の例は、ipconf.plセッションのサンプルを示しています。出力には3つのネットワーク・カードが示されます。

- eth0からeth3のクアッド・ポート10Gbカード

- ポートが1つのみ接続された、eth4およびeth5のデュアル・ポート10Gbカード

- ポートが1つのみ接続された、eth6およびeth7のデュアル・ポート10Gbカード。これが新しいネットワーク・カードです。

# cd /opt/oracle.cellos/
# ./ipconf.pl

Logging started to /var/log/cellos/ipconf.log
Interface ib0   is                      Linked.    hca: mlx4_0
Interface ib1   is                      Linked.    hca: mlx4_0
Interface eth0  is                      Linked.    driver/mac:
ixgbe/00:10:e0:8b:22:e8 (slave of vmeth0)
Interface eth1  is                      Linked.    driver/mac:
ixgbe/00:10:e0:8b:22:e9 (slave of bondeth0)
Interface eth2  is                      Linked.    driver/mac:
ixgbe/00:10:e0:8b:22:e9 (slave of bondeth0)
Interface eth3  is                      Linked.    driver/mac:
ixgbe/00:10:e0:8b:22:eb
Interface eth4  is                      Linked.    driver/mac:
ixgbe/90:e2:ba:ac:1d:e4
Interface eth5  is .................... Unlinked.  driver/mac:
ixgbe/90:e2:ba:ac:1d:e5
Interface eth6  is ...                  Linked.    driver/mac:
ixgbe/90:e2:ba:78:d0:10
Interface eth7  is .................... Unlinked.  driver/mac:
ixgbe/90:e2:ba:78:d0:11

bondeth0 eth1,eth2 UP      vmbondeth0 10.128.1.169  255.255.240.0
10.128.0.1  SCAN       test08client02.example.com
bondeth1 None      UNCONF
bondeth2 None      UNCONF
bondeth3 None      UNCONF
Select interface name to configure or press Enter to continue: eth6
Selected interface. eth6
IP address or up or none: 10.129.19.34
Netmask: 255.255.248.0
Gateway (IP address or none) or none: 10.129.16.0

Select network type for interface from the list below
1: Management
2: SCAN
3: Other
Network type: 3

Fully qualified hostname or none: test08adm02-bkup.example.com
Continue configuring or re-configuring interfaces? (y/n) [y]: n
...
Do you want to configure basic ILOM settings (y/n) [y]: n
[Info]: Custom changes have been detected in /etc/sysconfig/network-script
s/ifcfg-eth6
[Info]: Original file /etc/sysconfig/network-scripts/ifcfg-eth6 will be
saved in /opt/oracle.cellos/conf/network-scripts/backup_by_Exadata_ipconf
[Info]: Original file /etc/ssh/sshd_config will be saved in /etc/ssh/sshd_
config.backupbyExadata
[Info]: Generate /etc/ssh/sshd_config with ListenAddress(es) 10.128.18.106,
10.129.19.34, 10.128.1.169, 192.168.18.44, 192.168.18.45
Stopping sshd:                                             [  OK  ]
Starting sshd:                                             [  OK  ]
[Info]: Save /etc/sysctl.conf in /etc/sysctl.conf.backupbyExadata
[Info]: Adjust settings for IB interfaces in /etc/sysctl.conf
Re-login using new IP address 10.128.18.106 if you were disconnected after
following commands
ip addr show vmbondeth0
ip addr show bondeth0
ip addr show vmeth0
ip addr show eth0
ifup eth6
sleep 1
ifup vmeth6
sleep 1
ip addr show vmeth6
ip addr show eth6
sleep 4
service sshd condrestart

3. VLANでネットワーク・カードを設定する必要がある場合は、次の手順を実行します。

a. /opt/oracle.cellos/cell.confファイルにVLAN IDを追加します。

- ファイル内でイーサネット・インタフェースを探します。次に例を示します。

<Interfaces>
<Gateway>10.129.16.0</Gateway>
<Hostname>test08adm02-bkup.example.com</Hostname>
<IP_address>10.129.19.34</IP_address>
<IP_enabled>yes</IP_enabled>
<IP_ssh_listen>enabled</IP_ssh_listen>
<Inet_protocol>IPv4</Inet_protocol>
<Name>eth6</Name>
<Net_type>Other</Net_type>
<Netmask>255.255.248.0</Netmask>
<State>1</State>
<Status>UP</Status>
<Vlan_id>0</Vlan_id>
</Interfaces>

- <Vlan_id>要素にVLAN IDを追加します。次の例は、2122のVLAN IDで構成したインタフェースを示しています。

<Interfaces>
<Gateway>10.129.16.0</Gateway>
<Hostname>test08adm02-bkup.example.com</Hostname>
<IP_address>10.129.19.34</IP_address>
<IP_enabled>yes</IP_enabled>
<IP_ssh_listen>enabled</IP_ssh_listen>
<Inet_protocol>IPv4</Inet_protocol>
<Name>eth6</Name>
<Net_type>Other</Net_type>
<Netmask>255.255.248.0</Netmask>
<State>1</State>
<Status>UP</Status>
<Vlan_id>2122</Vlan_id>
</Interfaces>

b. 次のコマンドを実行して、変更したcell.confファイルを使用してネットワーク・インタフェースを構成します。

# /opt/oracle.cellos/ipconf.pl -init -force

c. ファイル名にVLAN IDを含むファイルが/etc/sysconfig/network-scriptsディレクトリ内に含まれることを確認して、インタフェースでVLANが構成されていることを検証します。たとえば、VLAN IDが2122の場合、次のファイルが表示されます。

# ls -ltr /etc/sysconfig/network-scripts/*2122*

-rw-r----- 1 root root 250 Sep  7 14:39 /etc/sysconfig/network-scripts/ifcfg-eth6.2122
-rw-r----- 1 root root  85 Sep  7 14:39 /etc/sysconfig/network-scripts/route-eth6.2122
-rw-r----- 1 root root  56 Sep  7 14:39 /etc/sysconfig/network-scripts/rule-eth6.2122

4. データベース・サーバーを再起動し、変更を有効にします。

5. ゲートウェイをpingして、ネットワークが機能していることを確認します。次に例を示します。

# ping 10.129.16.0

2.5.2 Oracle VM環境での追加のネットワーク・カードの構成

Oracle VM環境でOracle Exadata X6-2データベース・サーバーに追加のネットワーク・カードを構成できます。

この手順は、すでにOracle Exadata X6-2データベース・サーバーにネットワーク・カードを設置していることを前提としています。

1. dom0の/EXAVMIMAGES/conf/virtual_machine_config_file構成ファイルで、新しいネットワークのセクションを追加します。

次の例では、ブリッジの名前をvmeth6、インタフェースの名前をeth1としています。仮想マシンの構成ファイル名は、/EXAVMIMAGES/conf/test08adm01vm01.example.com-vm.xmlです。

<Interfaces>
<Bridge>vmeth6</Bridge>
<Gateway>10.129.16.0</Gateway>
<Hostname>test08adm02-bkup.example.com</Hostname>
<IP_address>10.129.19.34</IP_address>
<Name>eth1</Name>
<IP_enabled>yes</IP_enabled>
<IP_ssh_listen>disabled</IP_ssh_listen>
<Net_type>Other</Net_type>
<Netmask>255.255.248.0</Netmask>
<Vlan_id>0</Vlan_id>
<State>1</State>
<Status>UP</Status>
</Interfaces>

VLANを使用している場合は、<Vlan_id>要素に適切なVLAN ID [1-4095]を入力します。

2. ブリッジを作成します。

a. vmeth6という名前の、ボンディングされていないブリッジを作成するには、次のコマンドを使用します。

# /opt/exadata_ovm/exadata.img.domu_maker add-single-bridge-dom0 vmeth6

b. ボンディングされたブリッジを作成するには、次のようなコマンドを使用します。

# /opt/exadata_ovm/exadata.img.domu_maker add-bonded-bridge-dom0 bridge_name slave1 slave2 [vlan]

slave1とslave2は、結合されたインタフェースの名前です。

次に例を示します。

# /opt/exadata_ovm/exadata.img.domu_maker add-bonded-bridge-dom0 vmbondeth1 eth6 eth7

3. InfiniBand GUIDを割り当てます。

# /opt/exadata_ovm/exadata.img.domu_maker allocate-guids virtual_machine_config_file virtual_machine_config_file_final

仮想マシンの構成ファイルは、/EXAVMIMAGES/confディレクトリにあります。次に例を示します。

# /opt/exadata_ovm/exadata.img.domu_maker allocate-guids /EXAVMIMAGES/conf/
test08adm01vm01.example.com-vm.xml /EXAVMIMAGES/conf/final-test08adm01vm01
.example.com-vm.xml

4. ゲストを停止してから再起動します。

# /opt/exadata_ovm/exadata.img.domu_maker remove-domain /EXAVMIMAGES/conf
/final-test08adm01vm01.example.com-vm.xml

# /opt/exadata_ovm/exadata.img.domu_maker start-domain /EXAVMIMAGES/conf
/final-test08adm01vm01.example.com-vm.xml

5. ゲストが実行されたら、ip addrコマンドを使用して、インタフェースが有効であることを確認します。

次の例では、eth1インタフェースを確認します。

# ip addr show eth1
eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
link/ether 00:16:3e:53:56:00 brd ff:ff:ff:ff:ff:ff
inet 10.129.19.34/21 brd 10.129.23.255 scope global eth1
valid_lft forever preferred_lft forever

2.6 データベース・サーバーのアクティブ・コア数の増加

キャパシティ・オンデマンドを使用して、Oracle Exadata Database Machineのアクティブ・コア数を増やすことができます。

Oracle Exadata Database Machine X4-2以降のシステムで実行されるデータベース・サーバー上のアクティブ・コア数を、インストール中に減らすことができます。追加の容量が必要な場合は、アクティブ・コア数を増やすことができます。これは、キャパシティ・オンデマンドと呼ばれます。

追加のコアは、Oracle Exadata Database Machine X4-2およびそれ以降のシステムでは2コア増分で、Oracle Exadata Database Machine X4-8フル・ラックおよびそれ以降のシステムでは8コア増分で増やします。次の表に、キャパシティ・オンデマンドのコア・プロセッサの構成を示します。

表2-1 キャパシティ・オンデマンドのコア・プロセッサの構成

Oracle Exadata Database Machine

対象となるシステム

サーバー当たりの最小コア数

サーバー当たりの最大コア数

コアの増分

Oracle Exadata Database Machine X6-2

エイス・ラック以外の構成

14

44

14から44、2の倍数。

14, 16, 18, ..., 42, 44

Oracle Exadata Database Machine X6-2

エイス・ラック

8

22

8から22、2の倍数。

8, 10, 12, ..., 20, 22

Oracle Exadata Database Machine X5-2

エイス・ラック以外の構成

14

36

14から36、2の倍数。

14, 16, 18, ..., 34, 36

Oracle Exadata Database Machine X5-2

エイス・ラック

8

18

8から18、2の倍数。

8, 10, 12, ..., 16, 18

Oracle Exadata Database Machine X6-8およびX5-8

任意の構成

56

144

56から144、8の倍数。

56, 64, 72, ..., 136, 144

Oracle Exadata Database Machine X4-2

フル・ラック

ハーフ・ラック

クオータ・ラック

12

24

12から24、2の倍数。

12, 14, 16, ..., 22, 24

Oracle Exadata Database Machine X4-8

フル・ラック

48

120

48から120、8の倍数。

48, 56, 64, ..., 112, 120

注意:

フェイルオーバーに備えて、各サーバーに同数のコアをライセンスすることをお薦めします。

追加できるデータベース・サーバーは一度に1つずつで、キャパシティ・オンデマンドは個別のデータベース・サーバーに適用されます。このオプションはOracle Exadata Database Machine X5-2エイス・ラックでも使用できます。

追加したコアを有効化してから、データベース・サーバーを再起動する必要があります。データベース・サーバーがクラスタの一部の場合、ローリング方式で有効化されます。

1. 次のコマンドを使用して、アクティブ物理コア数を確認します。

DBMCLI> LIST DBSERVER attributes coreCount

2. 次のコマンドを使用して、アクティブ・コア数を増やします。

DBMCLI> ALTER DBSERVER pendingCoreCount = new_number_of_active_physical_cores

3. 次のコマンドを使用して、承認待ちのアクティブ物理コア数を確認します。

DBMCLI> LIST DBSERVER attributes pendingCoreCount

4. サーバーを再起動します。

5. 次のコマンドを使用して、アクティブ物理コア数を確認します。

DBMCLI> LIST DBSERVER attributes coreCount

関連トピック

- 『Oracle Exadata Database Machineライセンス情報ユーザーズ・ガイド』

2.7 ベア・メタルOracle RACクラスタからOracle VMのOracle RACクラスタへの移行

注意:

この項は、2ソケットのx86サーバーにのみ適用されます。8ソケット・サーバーおよびSPARCサーバーには適用されません。

ベア・メタルOracle RACクラスタからOracle VMのOracle RACクラスタへの移行は次の方法で実行できます。

- 既存のベア・メタルOracle RACクラスタを使用して、Oracle VMにOracle RACクラスタを移行します。ダウンタイムは発生しません

- Oracle VMに新しいOracle RACクラスタを作成して、Oracle VMにOracle RACクラスタを移行します。多少のダウンタイムが発生します

- Oracle Data Guardを使用してOracle VMにOracle RACクラスタに移行します。多少のダウンタイムが発生します

- RMANバックアップとリストアを使用してOracle VMのOracle RACクラスタに移行します。ダウンタイムが発生します

ベア・メタルOracle RACクラスタからOracle VMのOracle RACクラスタに変換することは、次のことを示唆します。

- 各データベース・サーバーがOracle Virtual Serverに変更されます。Oracle Virtual Serverには管理ドメインと、デプロイされるOracle RACクラスタの数に応じて1つ以上のユーザー・ドメインが作成されます。データベース・サーバー上の各ユーザー・ドメインは特定のOracle RACクラスタに所属します。

- 変換手順の一環として、ベア・メタルOracle RACクラスタが、Oracle VM内の1つのOracle RACクラスタに変換されます。データベース・サーバーごとに1つのユーザー・ドメインがあります。

- 変換が終わった後のストレージ・セルのセル・ディスクとグリッド・ディスクの構成は、変換の開始時の構成と同じになります。

- 各データベース・サーバー上で管理ドメインによって使用されるシステム・リソースの量は同じになります。通常、管理ドメインでは8GBのメモリーと4つの仮想CPUが使用されます。この点を考慮してOracle VMのOracle RACクラスタで実行するデータベースのSGAのサイズを決定してください。

関連トピック

- 「ベア・メタルRACクラスタのExadata上のOVM RACクラスタへの移行」(Doc ID 2099488.1)

2.8 Oracle Exadata Database MachineのOracle VMドメインの管理

Oracle Exadata Database Machine上のOracle VMユーザー・ドメインを管理するには、管理ドメイン(domain-0またはdom0)からxm(1)コマンドを実行します。xm helpを実行すると、すべてのOracle VM管理コマンドの一覧が表示されます。

注意:

次に示すxmサブコマンドは、Oracle Exadata Database Machineではサポートされていません。

mem-set
mem-max
migrate
restore
resume
save
suspend
sched-*
cpupool-*
tmem-*

この項では、次の項目について説明します。

- 実行中のドメインの表示

- ユーザー・ドメイン・コンソールの監視

- ユーザー・ドメインの開始

- ユーザー・ドメインの自動起動の無効化

- ユーザー・ドメイン内部のユーザー・ドメインのシャットダウン

- 管理ドメイン内部のユーザー・ドメインのシャットダウン

- Oracle VMユーザー・ドメインでのOracle Databasesのバックアップおよびリストア

- ユーザー・ドメインに割り当てられたメモリーの変更

- ユーザー・ドメインに割り当てられた仮想CPU数の変更

- ユーザー・ドメインのディスク領域の増加

- データベース・サーバーのディスク拡張後の管理ドメインの/EXAVMIMAGESの拡張

- Oracle VM Oracle RACクラスタの作成

- ExadataでのOracle VM Oracle RACクラスタの拡張

- Oracle Grid InfrastructureおよびOracle Databaseの存在しないユーザー・ドメインの作成

- ユーザー・ドメインの別のデータベース・サーバーへの移動

- Oracle VMで実行するOracle RACクラスタの削除

- Oracle VM Oracle RACクラスタからのユーザー・ドメインの削除

- タグVLANインタフェースの実装

- Oracle ExadataでのOracle VM Oracle RACクラスタ間のInfiniBandパーティションの実装

- Oracle EXAchkの実行

注意:

特に明記された場合を除き、前述の手順で実行するすべてのコマンドはrootユーザーとして実行します。

2.8.1 実行中のドメインの表示

次の手順では、実行中のドメインを表示する方法について説明します。

1. 管理ドメイン、domain zeroまたはdom0に接続します。

2. xm listコマンドを実行します。次に、出力の例を示します。

Example
# xm list
Name                         ID   Mem   VCPUs      State   Time(s)
Domain-0                      0   8192     4       r-----  409812.7
dm01db01vm01                  8   8192     2       -b---- 156610.6
dm01db01vm02                  9   8192     2       -b---- 152169.8
dm01db01vm03                 10  10240     4       -b---- 150225.9
dm01db01vm04                 16  12288     8       -b---- 113519.3
dm01db01vm05                 12  12288     8       -b---- 174101.6
dm01db01vm06                 13  12288     8       -b---- 169115.9
dm01db01vm07                 14   8192     4       -b---- 175573.0

2.8.2 ユーザー・ドメイン・コンソールの監視

次の手順では、ユーザー・ドメインを監視する方法について説明します。

1. rootユーザーとして管理ドメインに接続します。

2. xm listコマンドを使用して、ドメイン名を取得します。

3. 次のコマンドを使用して、ユーザー・ドメイン・コンソールに接続します。

# xm console DomainName

上記のコマンドで、DomainNameはドメインの名前です。

4. CTRL+]を押して、コンソールの接続を解除します。

2.8.3 ユーザー・ドメインの開始

次の手順では、ユーザー・ドメインを開始する方法について説明します。

1. 次のコマンドを使用して、ユーザー・ドメインを起動します。

# xm create /EXAVMIMAGES/GuestImages/DomainName/vm.cfg
Using config file "/EXAVMIMAGES/GuestImages/dm01db01vm04/vm.cfg".
Started domain dm01db01vm04 (id=23)

上記のコマンドで、DomainNameはドメインの名前です。

注意:

Oracle Linux起動メッセージをユーザー・ドメイン起動中に表示する場合は、起動中に-cオプションを使用してコンソールに接続します。起動が終了したら、CTRL+]を押してコンソールの接続を解除します。

2.8.4 ユーザー・ドメインの自動起動の無効化

次の手順では、管理ドメインが起動した場合に、ユーザー・ドメインが自動的に起動するのを無効にする方法について説明します。

1. 管理ドメインに接続します。

2. 次のコマンドを使用して、/etc/xen/autoディレクトリ内のユーザー・ドメイン構成ファイルへのシンボリック・リンクを削除します。

# rm /etc/xen/auto/DomainName.cfg

上記のコマンドで、DomainNameはドメインの名前です。

2.8.5 ユーザー・ドメイン内部のユーザー・ドメインのシャットダウン

次の手順では、ユーザー・ドメイン内部でユーザー・ドメインをシャットダウンする方法について説明します。

1. rootユーザーとしてユーザー・ドメインに接続します。

2. 次のコマンドを使用して、ドメインをシャットダウンします。

# shutdown -h now

2.8.6 管理ドメイン内部のユーザー・ドメインのシャットダウン

次の手順では、管理ドメイン内部でユーザー・ドメインをシャットダウンする方法について説明します。

1. rootユーザーとして管理ドメインに接続します。

2. 次のコマンドを使用して、ドメインをシャットダウンします。

# xm shutdown DomainName -w

上記のコマンドで、DomainNameはドメインの名前です。

注意:

-wオプションを使用すると、ドメインのシャットダウンが完了するまで待機してからxmコマンドが戻ります。xm shutdownコマンドを使用すると、ユーザー・ドメインでshutdown -h nowを実行した場合と同じ順序でシャットダウンが実行されます。

次のコマンドを使用して、管理ドメイン内部のすべてのユーザー・ドメインをシャットダウンします。

# xm shutdown -a -w

次に、出力の例を示します。

Domain dm01db01vm04 terminated
All domains terminated

2.8.7 Oracle VMユーザー・ドメインでのOracle Databasesのバックアップおよびリストア

Oracle VMユーザー・ドメインでのOracleデータベースのバックアップとリストアは、物理ノードでのOracleデータベースのバックアップとリストアと同じです。

- OracleデータベースをOracle VMユーザー・ドメインでバックアップする場合、次の4つのパラメータをデータベース・ノード(ユーザー・ドメイン)の/etc/sysctl.confファイルに設定する必要があります。また、Oracle Exadataストレージを使用してバックアップを保持する場合、パラメータをExadataストレージ・セルの/etc/sysctl.confファイルに設定する必要があります。

net.core.rmem_default = 4194304
net.core.wmem_default = 4194304
net.core.rmem_max = 4194304
net.core.wmem_max = 4194304

- Exadataストレージを使用している場合、各Oracle VM RACクラスタでは、それぞれのOracle Automatic Storage Management (Oracle ASM)ディスク・グループを+RECOなどの高速リカバリ領域(FRA)として指定する必要があります。詳細は、ホワイト・ペーパー『Exadata Database Machineのバックアップとリストア構成および操作のベスト・プラクティス』を参照してください。

- Oracle ZFS Storage Applianceを使用している場合は、ホワイト・ペーパー『Oracle ZFS Storage ApplianceによるExadata Database Machineの保護: 構成のベスト・プラクティス』を参照してください。

2.8.8 ユーザー・ドメインに割り当てられたメモリーの変更

次の手順では、ユーザー・ドメインに割り当てられたメモリーを変更する方法について説明します。

注意:

ユーザー・ドメインに割り当てられるメモリーの量を減らす場合は、ユーザー・ドメインで実行中のデータベースのSGAサイズおよび対応するヒュージ・ページ・オペレーティング・システム構成を最初に確認して調整する必要があります。そうしない場合、Linuxオペレーティング・システムのブート中に、多すぎるメモリーがヒュージ・ページに予約されるため、ユーザー・ドメインを起動できなくなることがあります。詳細は、My Oracle Supportノート361468.1を参照してください。

注意:

この手順では、ユーザー・ドメインを再起動する必要があります。メモリー割当てを変更する場合、xm mem-setコマンドはサポートされていません。

1. 管理ドメインに接続します。

2. 次のコマンドを使用して、割当てを増やす場合に使用できる空きメモリーの量を判別します。

# xm info | grep free_memory

注意:

空きメモリーをユーザー・ドメインに割り当てる場合、空きメモリーの約1から2パーセントがメタデータおよび制御構造で使用されます。つまり、増加可能なメモリーの量は、空メモリーの値の1から2パーセント未満です。

3. xm listコマンドで取得した名前を使用して、ユーザー・ドメインを正常にシャットダウンします。-wオプションを使用すると、ドメインがシャットダウンするまで待機してからxmコマンドが戻ります。

# xm shutdown DomainName -w

上記のコマンドで、DomainNameはドメインの名前です。

4. /EXAVMIMAGES/GuestImages/DomainName/vm.cfgファイルのバックアップ・コピーを作成します。

5. /EXAVMIMAGES/GuestImages/DomainName/vm.cfgファイルのmemory設定およびmaxmem設定を、テキスト・エディタを使用して編集します。memory設定およびmaxmem設定の値は、同一です。

注意:

メモリーおよびmaxmemパラメータの値が同一でない場合、ユーザー・ドメインの起動でInfiniBandネットワーク・インタフェースが構成されないため、Oracle CRSおよびデータベースが正常に起動しません。

6. 次のコマンドを使用して、ユーザー・ドメインを起動します。

# xm create /EXAVMIMAGES/GuestImages/DomainName/vm.cfg

注意:

Oracle Linux起動メッセージをユーザー・ドメイン起動中に表示する場合は、起動中に-cオプションを使用してコンソールに接続します。起動が終了したら、CTRL+]を押してコンソールの接続を解除します。

2.8.9 ユーザー・ドメインに割り当てられた仮想CPU数の変更

仮想CPU (vCPUs)の数を変更する場合、次の点に留意します。

- ユーザー・ドメインに割り当てられた仮想CPU数を変更するためのすべてのアクションは、管理ドメインで実行されます。

- ユーザー・ドメインに可能な仮想CPU数は、ユーザー・ドメインのmaxvcpusパラメータで設定される値の範囲内で、動的に増減します。

- 仮想CPUをオーバーコミットすると、すべてのドメインに割り当てられた仮想CPUを、システム上の物理CPU数より多く割り当てることができます。ただし、CPUのオーバーコミットは、過剰に収容されたリソースへの競合するワークロードが十分理解され、同時に発生する要求が物理能力を超えない場合にのみ、実行する必要があります。

次の手順では、ユーザー・ドメインに割り当てられた仮想CPU数を変更する方法について説明します。

1. 次の手順に従い、物理CPU数を判別します。

a. 管理ドメインで、次のコマンドを実行します。

# xm info | grep -A3 nr_cpus
nr_cpus                : 24
nr_nodes               : 2
cores_per_socket       : 6
threads_per_core       : 2

出力で、nr_nodes行はソケットの数を示しています。コマンドが実行されるExadataデータベース・サーバーのプロセッサは2ソケットで、ソケット当たり6コアであるため、物理CPUスレッドは24個(2ソケット x 6コア/ソケット = 12コア。12コア x 2スレッド/コア = 24 CPUスレッド)です。

b. 次のコマンドを実行して、ユーザー・ドメインに構成されオンラインである仮想CPUの現在の設定を判別します。

# xm list DomainName -l | grep vcpus

(vcpus 4)
(online_vcpus 2)

前述のコマンドで、DomainNameはユーザー・ドメインの名前です。コマンドの出力例では、ユーザー・ドメインの仮想CPUの最大数は4で、現在のオンライン仮想CPUは2です。このユーザー・ドメインのオンラインの仮想CPUの数は、ユーザー・ドメインがオンラインの間に、vcpusパラメータよりも大きくない数に調整されます。オンラインの仮想CPUの数をvcpusパラメータよりも大きい値に増やすには、ユーザー・ドメインをオフラインにする必要があります。

2. 次の手順に従い、仮想CPU数を小さくするまたは大きくします。

- 仮想CPU数を減らす手順は、次の通りです。

a. 次のコマンドを使用して、ユーザー・ドメインに現在割り当てられている仮想CPUの数を判別します。

# xm list DomainName

b. 次のコマンドを使用して、現在割り当てられている仮想CPU数を減らします。

# xm vcpu-set DomainName vCPUs_preferred

前述のコマンドで、vCPUs_preferredは、推奨される仮想CPU数の値です

- 仮想CPU数を増やす手順は、次の通りです。

a. 次のコマンドを使用して、vcpusパラメータの現在の設定を判別します。

# xm list DomainName -l | grep vcpus
(vcpus 4)
(online_vcpus 2)

b. 推奨される仮想CPU数が、vcpusパラメータの値より小さいか等しい場合、次のコマンドを実行して、オンライン仮想CPU数を増やします。

# xm vcpu-set DomainName vCPUs_preferred

前述のコマンドで、vCPUs_preferredは、推奨される仮想CPU数の値です

c. 推奨される仮想CPU数が、vcpusパラメータの値より大きい場合、オンラインの仮想CPUの数をvcpusパラメータよりも大きい値に増やすには、ユーザー・ドメインをオフラインする必要があります。次の手順を実行します。
i.ユーザー・ドメインをシャットダウンします。

ii./EXAVMIMAGES/GuestImages/DomainName/vm.cfgファイルのバックアップ・コピーを作成します。

iii./EXAVMIMAGES/GuestImages/DomainName/vm.cfgファイルを編集し、vcpusパラメータを推奨される仮想vCPUの数に設定します。

注意: デフォルトでは、ユーザー・ドメインは、vcpusパラメータで構成された仮想CPUの数をオンラインにします。一部の仮想CPUをオフラインにしてユーザー・ドメインを起動する場合は、maxvcpusパラメータをvm.cfgに追加し、ユーザー・ドメインでオンラインにできる仮想CPUの最大数に設定します。vcpusパラメータを仮想CPUの数に設定し、ユーザー・ドメインの起動時にオンラインにします。たとえば、2つの仮想CPUがオンラインのユーザー・ドメインを起動し、そのユーザー・ドメインがオンラインの間に、さらに6つの仮想CPUをユーザー・ドメインに追加する場合は、次の設定をvm.cfgに使用します。

maxvcpus=8
vcpus=2

iv.ユーザー・ドメインを開始します。

2.8.10 ユーザー・ドメインのディスク領域の増加

次の手順では、ユーザー・ドメインにおける論理ボリューム・マネージャ(LVM)、スワップ領域およびファイル・システムのサイズを増やす方法について説明します。この項では、次の項目について説明します。

- 新規LVMディスクのユーザー・ドメインへの追加

- rootファイル・システムのサイズの増加

- /u01ファイル・システムのサイズの増加

- Oracle Grid InfrastructureホームまたはDatabaseホーム・ファイル・システムのサイズの増加

- スワップ領域のサイズの増加

2.8.10.1 新規LVMディスクのユーザー・ドメインへの追加

次の手順では、新LVMディスクをユーザー・ドメインに追加して、ユーザー・ドメイン内で使用できるLVMディスク領域の量を増やす方法について説明します。この手順を実行すると、ファイル・システムまたはスワップLVMパーティションのサイズを増やすことができます。これはシステムがオンラインの場合に実行できます。

注意:

この手順は、管理ドメイン(Domain-0)およびユーザー・ドメイン内で実行する必要があります。

すべての手順を、rootユーザーとして実行してください。

1. 管理ドメインで、次のコマンドを使用して/EXAVMIMAGES内の空きディスク領域を確認します。

# df -h /EXAVMIMAGES

次に、コマンドの出力例を示します。

Filesystem            Size  Used Avail Use% Mounted on
/dev/sda3            721G  111G  611G  16% /EXAVMIMAGES

2. 管理ドメインで、新規ディスク・イメージの名前を選択し、ユーザー・ドメインで既に名前が使用されていないか確認します。

# ls -l /EXAVMIMAGES/GuestImages/DomainName/new_disk_image_name

ls: /EXAVMIMAGES/GuestImages/DomainName/new_disk_image_name: No such file or \
directory

上記のコマンドで、DomainNameはドメインの名前で、new_disk_image_nameは、新規ディスク・イメージの名前です。

3. 管理ドメインで、新規ディスク・イメージを作成します。

# qemu-img create /EXAVMIMAGES/GuestImages/DomainName/new_disk_image_name size

次のコマンドで、新規ディスク・イメージ名はpv2_vgexadb.img、イメージ・サイズは0 GBです。

# qemu-img create /EXAVMIMAGES/GuestImages/DomainName/pv2_vgexadb.img 10G

4. ユーザー・ドメインで、使用できるディスク名を判別します。次の例では、ディスク名xvdaからxvddを使用し、 ディスク名xvdeは使用しません。

# lsblk -id
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda 202:0    0  13G  0 disk
xvdb 202:16   0  20G  0 disk /u01/app/12.1.0.2/grid
xvdc 202:32   0  20G  0 disk /u01/app/oracle/product/12.1.0.2/dbhome_1
xvdd 202:48   0  41G  0 disk

5. 管理ドメインで、新規ディスク・イメージをユーザー・ドメインに読取り/書込みモードで割り当てます。次の例では、ユーザー・ドメイン内の新規ディスク・イメージは、デバイス/dev/xvdeとして表示されます。

# xm block-attach DomainName     \
file:/EXAVMIMAGES/GuestImages/DomainName/new_disk_image_name /dev/xvde w

6. ユーザー・ドメインで、使用できるディスク・デバイスを確認します。次の例では、ディスク名xvdeがユーザー・ドメインで使用できます。

# lsblk -id
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda 202:0    0  13G  0 disk
xvdb 202:16   0  20G  0 disk /u01/app/12.1.0.2/grid
xvdc 202:32   0  20G  0 disk /u01/app/oracle/product/12.1.0.2/dbhome_1
xvdd 202:48   0  41G  0 disk
xvde 202:64   0  10G  0 disk

7. ユーザー・ドメインで、新規ディスク・デバイスにパーティションを作成します。次の例では、ディスク・デバイス/dev/xvdeにパーティションを作成します。

# parted /dev/xvde mklabel gpt
# parted -s /dev/xvde mkpart primary 0 100%
# parted -s /dev/xvde set 1 lvm on

parted mkpartコマンドが、次のメッセージを戻す場合があります。このメッセージは無視してかまいません。

Warning: The resulting partition is not properly aligned for best performance.

8. ユーザー・ドメインで、新規ディスク・パーティション上にLVM物理ボリュームを作成します。次の例では、LVM物理ボリュームをディスク・パーティション/dev/xvde1上に作成します。

# pvcreate /dev/xvde1

9. ユーザー・ドメインで、ボリューム・グループを拡張して、ボリューム・グループ内の追加領域を確認します。次の例では、ディスク名xvdeがユーザー・ドメインで使用できます。

# vgextend VGExaDb /dev/xvde1
# vgdisplay -s

10. 管理ドメインで、ユーザー・ドメイン構成ファイルvm.cfgのバックアップを作成します。

# cp /EXAVMIMAGES/GuestImages/DomainName/vm.cfg   \
/EXAVMIMAGES/GuestImages/DomainName/vm.cfg.backup

11. 管理ドメインで、次のコマンドを使用して、ユーザー・ドメインのUUIDを取得します。

# grep ^uuid /EXAVMIMAGES/GuestImages/DomainName/vm.cfg

次の例では、ユーザー・ドメインUUIDは49ffddce4efe43f5910d0c61c87bba58です。

# grep ^uuid /EXAVMIMAGES/GuestImages/dm01db01vm01/vm.cfg
uuid = '49ffddce4efe43f5910d0c61c87bba58'

12. 管理ドメインで、次のコマンドを使用して、新規ディスク・イメージのUUIDを生成します。

# uuidgen | tr -d '-'

次の例では、新規ディスクUUIDは、0d56da6a5013428c97e73266f81c3404です。

# uuidgen | tr -d '-'
0d56da6a5013428c97e73266f81c3404

13. 管理ドメインで、次のコマンドを使用して、/OVS/Repositoriesから新規ディスク・イメージへのシンボリック・リンクを作成します。

# ln -s /EXAVMIMAGES/GuestImages/DomainName/newDiskImage.img    \
/OVS/Repositories/user_domain_uuid/VirtualDisks/new_disk_uuid.img

次の例では、新規ディスク・イメージ・ファイルpv2_vgexadb.imgへのシンボリック・リンクが、ユーザー・ドメインdm01db01vm01に作成されます。ユーザー・ドメインdm01db01vm01のUUIDは、i49ffddce4efe43f5910d0c61c87bba58です。新規ディスク・イメージのUUIDは、0d56da6a5013428c97e73266f81c3404です。

# ln -s /EXAVMIMAGES/GuestImages/dm01db01vm01/pv2_vgexadb.img \
/OVS/Repositories/49ffddce4efe43f5910d0c61c87bba58/VirtualDisks/   \
0d56da6a5013428c97e73266f81c3404.img

14. 管理ドメインで、新規ディスク用のエントリを、ユーザー・ドメイン構成ファイルvm.cfgのディスク・パラメータに付加します。これにより、次の起動時、新規ディスク・イメージが自動的にユーザー・ドメインへ割り当てられます。この新規エントリのフォーマットは次の通りです。

'file:/OVS/Repositories/user_domain_uuid/VirtualDisks/new_disk_uuid.img,disk_device,w'

次に、vm.cfgファイル内の元のディスク・パラメータ・エントリの例を示します。

disk=['file:/OVS/Repositories/49ffddce4efe43f5910d0c61c87bba58/VirtualDisks/  \
76197586bc914d3d9fa9d4f092c95be2.img,xvda,w',                                 \
'file:/OVS/Repositories/49ffddce4efe43f591 0d0c61c87bba58/VirtualDisks/       \
78470933af6b4253b9ce27814ceddbbd.img,xvdb,w',                                 \
'file:/OVS/Repositories/49ffddce4efe43f5910d0c61c87bba58/VirtualDisks/        \
20d5528f5f9e4fd8a96f151a13d2006b.img,xvdc,w',                                 \
'file:/OVS/Repositories/49ffddce4efe43f5910d0c61c87bba58/VirtualDisks/        \
058af368db2c4f27971bbe1f19286681.img,xvdd,w']

次の例では、ディスク・デバイス/dev/xvdeとしてユーザー・ドメイン内でアクセス可能な新規ディスク・イメージに対して、付加されたディスク・パラメータを示します。

disk=['file:/OVS/Repositories/49ffddce4efe43f5910d0c61c87bba58/VirtualDisks/  \
76197586bc914d3d9fa9d4f092c95be2.img,xvda,w',                                 \
'file:/OVS/Repositories/49ffddce4efe43f591 0d0c61c87bba58/VirtualDisks/       \
78470933af6b4253b9ce27814ceddbbd.img,xvdb,w',                                 \
'file:/OVS/Repositories/49ffddce4efe43f5910d0c61c87bba58/VirtualDisks/        \
20d5528f5f9e4fd8a96f151a13d2006b.img,xvdc,w',                                 \
'file:/OVS/Repositories/49ffddce4efe43f5910d0c61c87bba58/VirtualDisks/        \
058af368db2c4f27971bbe1f19286681.img,xvdd,w',                                 \
'file:/OVS/Repositories/49ffddce4efe43f5910d0c61c87bba58/VirtualDisks/        \
0d56da6a5013428c97e73266f81c3404.img,xvde,w']

2.8.10.2 rootファイル・システムのサイズの増加

この手順では、システム・パーティションおよび/ (ルート)ファイル・システムのサイズを増やす方法について説明します。

これはファイル・システムがオンラインの場合に実行できます。

注意:

2種類のシステム・パーティション、LVDbSys1およびLVDbSys2が使用できます。片方のパーティションがアクティブでマウントされます。もう一方のパーティションは非アクティブで、アップグレード中、バックアップする場所として使用します。この2つのシステム・パーティションは、サイズが等しい必要があります。

VGExaDbボリューム・グループ内に、少なくとも1GBの空き領域が必要です。空き領域は、ソフトウェア保守の際に、dbnodeupdate.shユーティリティで作成したLVMスナップショットで使用します。「Oracle Linuxデータベース・サーバーのスナップショット・ベースのバックアップの作成」の手順に従い、/ (root)および/u01ディレクトリのバックアップをスナップショット・ベースで作成する場合、VGExaDbボリューム・グループに少なくとも6GBの空き領域が必要です。

1. 現在の環境に関する情報を収集します。

a. dfコマンドを使用して、ルート・パーティション(/)の空き領域および使用済領域の容量を確認します

# df -h /

次に、コマンドの出力例を示します。

Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VGExaDb-LVDbSys1
12G  5.1G  6.2G  46% /

注意:

アクティブなrootパーティションは、それ以前の保守アクティビティによりLVDbSys1またはLVDbSys2のいずれかに決定されます。

b. lvsコマンドを使用して、現在の論理ボリューム構成を表示します。

# lvs -o lv_name,lv_path,vg_name,lv_size

次に、コマンドの出力例を示します。

LV        Path                   VG      LSize
LVDbOra1  /dev/VGExaDb/LVDbOra1  VGExaDb 10.00g
LVDbSwap1 /dev/VGExaDb/LVDbSwap1 VGExaDb  8.00g
LVDbSys1  /dev/VGExaDb/LVDbSys1  VGExaDb 12.00g
LVDbSys2  /dev/VGExaDb/LVDbSys2  VGExaDb 12.00g

2. ボリューム・グループVGExaDbの使用可能な領域を確認するには、vgdisplayコマンドを使用します。

# vgdisplay VGExaDb -s

次に、コマンドの出力例を示します。

"VGExaDb" 53.49 GiB [42.00 GiB used / 11.49 GiB free]

ボリューム・グループは、2つのシステム・パーティションのサイズを増やすことができる空き領域を持ち、アップグレードの際にdbnodeupdate.shユーティリティで作成されるLVMスナップショットで使用するために、少なくとも1GBの空き領域を維持する必要があります。ボリューム・グループに十分な空き領域がない場合、新しいディスクをLVMに追加する必要があります。

3. LVDbSys1およびLVDbSys2論理ボリュームのサイズを変更するには、lvextendコマンドを使用します。

# lvextend -L +size /dev/VGExaDb/LVDbSys1
# lvextend -L +size /dev/VGExaDb/LVDbSys2

前述のコマンドで、sizeは論理ボリュームに追加する領域の容量です。いずれのシステム・パーティションにも、等しい容量の領域を追加します。

次の例では、拡大する論理ボリュームは10GBです。

# lvextend -L +10G /dev/VGExaDb/LVDbSys1
# lvextend -L +10G /dev/VGExaDb/LVDbSys2

4. 論理ボリューム内のファイル・システムのサイズを変更するには、resize2fsコマンドを使用します。

# resize2fs /dev/VGExaDb/LVDbSys1
# resize2fs /dev/VGExaDb/LVDbSys2

5. dfコマンドを使用して、アクティブなシステム・パーティションで領域が拡大されたことを確認します。

# df -h /

関連トピック

- 新規LVMディスクのユーザー・ドメインへの追加

2.8.10.3 /u01ファイル・システムのサイズの増加

この手順では、/u01ファイル・システムのサイズを増やす方法について説明します。

これはファイル・システムがオンラインの場合に実行できます。

注意:

VGExaDbボリューム・グループ内に、少なくとも1GBの空き領域が必要です。空き領域は、ソフトウェア保守の際に、dbnodeupdate.shユーティリティで作成したLVMスナップショットで使用します。「Oracle Linuxデータベース・サーバーのスナップショット・ベースのバックアップの作成」の手順に従い、/ (root)および/u01ディレクトリのバックアップをスナップショット・ベースで作成する場合、VGExaDbボリューム・グループに少なくとも6GBの空き領域が必要です。

1. 現在の環境に関する情報を収集します。

a. dfコマンドを使用して、/u01パーティションの空き領域および使用済領域の容量を確認します。

# df -h /u01

次に、コマンドの出力例を示します。

Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VGExaDb-LVDbOra1
9.9G  1.7G  7.8G  18% /u01

b. lvsコマンドを使用して、/u01ファイル・システムで使用される現在の論理ボリューム構成を表示します。

# lvs -o lv_name,lv_path,vg_name,lv_size /dev/VGExaDb/LVDbOra1

次に、コマンドの出力例を示します。

LV        Path                  VG       LSize
LVDbOra1 /dev/VGExaDb/LVDbOra1  VGExaDb 10.00g

2. ボリューム・グループVGExaDbの使用可能な領域を確認するには、vgdisplayコマンドを使用します。

# vgdisplay VGExaDb -s

次に、コマンドの出力例を示します。

"VGExaDb" 53.49 GiB [42.00 GiB used / 11.49 GiB free]

コマンドの出力で空き領域が1GB未満と表示された場合は、論理ボリュームもファイル・システムも拡大できません。アップグレードの際にdbnodeupdate.shユーティリティで作成されるLVMスナップショットのために、VGExaDbボリューム・グループ内に、少なくとも1GBの空き領域が必要です。ボリューム・グループに十分な空き領域がない場合、新しいディスクをLVMに追加する必要があります。

3. 論理ボリュームのサイズを変更するには、lvextendコマンドを使用します。

# lvextend -L +sizeG /dev/VGExaDb/LVDbOra1

前述のコマンドで、sizeは論理ボリュームに追加する領域の容量です。

次の例では、拡大する論理ボリュームは10GBです。

# lvextend -L +10G /dev/VGExaDb/LVDbOra1

4. 論理ボリューム内のファイル・システムのサイズを変更するには、resize2fsコマンドを使用します。

# resize2fs /dev/VGExaDb/LVDbOra1

5. dfコマンドを使用して、領域が拡張されたことを確認します。

# df -h /u01

関連トピック

- 新規LVMディスクのユーザー・ドメインへの追加

2.8.10.4 Oracle Grid InfrastructureホームまたはDatabaseホーム・ファイル・システムのサイズの増加

Oracle Grid InfrastructureホームおよびOracle Databaseソフトウェア・ホームのために、それぞれのディスク・イメージ・ファイルが管理ドメインに作成されます。ディスク・イメージ・ファイルの場所は、/EXAVMIMAGES/GuestImages/DomainName/ディレクトリです。ディスク・イメージ・ファイルは、仮想マシンの起動中に自動的にユーザー・ドメインに関連付けられ、別個にLVMではないファイル・システムとしてユーザー・ドメインにマウントされます。

次の手順では、ユーザー・ドメインにおけるデータベース・ホーム・ファイル・システムのサイズを増やす方法について説明します。グリッド・ホームのサイズを増やすには、同様の手順を使用します。

1. ユーザー・ドメインに接続し、ファイル・システム・サイズを確認するには、dfコマンドを使用します。

# df -h /u01/app/oracle/product/12.1.0.2/dbhome_1

次に、コマンドの出力例を示します。

Filesystem  Size  Used Avail Use% Mounted on
/dev/xvdc    20G  6.5G   13G  35% /u01/app/oracle/product/12.1.0.2/dbhome_1

2. 管理ドメインに接続し、ユーザー・ドメインをシャットダウンするには、xmコマンドを使用し、ドメインの名前を指定します。

# xm shutdown DomainName

3. OCFS reflinkを作成して、サイズを変更するディスク・イメージのバックアップとして使用します。

# cd /EXAVMIMAGES/GuestImages/DomainName
# reflink db12.1.0.2.1-3.img before_resize.db12.1.0.2.1-3.img

4. qemu-imgコマンドを使用して、空のディスク・イメージを作成し、データベース・ホーム・ディスク・イメージに付加します。

空のディスク・イメージ・サイズは、拡張後のファイル・システムのサイズです。最後のコマンドにより、データベース・ホーム・ディスク・イメージに付加済の空のディスク・イメージが削除されます。

# qemu-img create emptyfile 10G
# cat emptyfile >> db12.1.0.2.1-3.img
# rm emptyfile

5. e2fsckコマンドを使用して、ファイル・システムを確認します。

# e42fsck -f db12.1.0.2.1-3.img

6. resize2fsコマンドを使用して、ファイル・システムのサイズを変更します。

# resize2fs db12.1.0.2.1-3.img

7. ユーザー・ドメインを開始します。

# xm create /EXAVMIMAGES/GuestImages/DomainName/vm.cfg

8. ユーザー・ドメインに接続し、ファイル・システム・サイズが増えていることを確認します。

# df -h /u01/app/oracle/product/12.1.0.2/dbhome_1

次に、コマンドの出力例を示します。

Filesystem      Size  Used Avail Use% Mounted on
/dev/xvdc        30G  6.5G   22G  23% /u01/app/oracle/product/12.1.0.2/dbhome_1

9. 管理ドメインに接続し、バックアップ・イメージを削除します。

# cd /EXAVMIMAGES/GuestImages/DomainName
# rm back_up_image.img

上記のコマンドで、back_up_image.imgはバックアップ・イメージ・ファイルの名前です。

2.8.10.5 スワップ領域のサイズの増加

この手順では、ユーザー・ドメインで構成されたスワップの容量を増やす方法について説明します。

1. ボリューム・グループVGExaDbの使用可能な領域を確認するには、vgdisplayコマンドを使用します。

# vgdisplay VGExaDb -s

次に、コマンドの出力例を示します。

"VGExaDb" 53.49 GiB [42.00 GiB used / 11.49 GiB free]

コマンドの出力で空き領域が1GB未満と表示された場合は、論理ボリュームもファイル・システムも拡大できません。アップグレードの際にdbnodeupdate.shユーティリティで作成されるLVMスナップショットのために、VGExaDbボリューム・グループ内に、少なくとも1GBの空き領域が必要です。ボリューム・グループに十分な空き領域がない場合、新しいディスクをLVMに追加する必要があります。

2. 論理ボリュームを作成してスワップ領域のサイズを大きくするには、次のように、lvcreateコマンドを使用します。

次の例では、LVDbSwap2という名前の8GBの論理ボリュームが新たに作成されます。

# lvcreate -L 8G -n LVDbSwap2 VGExaDb

3. SWAP2のような一意のラベルのスワップ・デバイスとして論理ボリュームを新たに設定するには、次のように、mkswapコマンドを使用します。一意のラベルは、/etc/fstabファイルで現在使用されていないデバイスのLABELエントリです。

# mkswap -L SWAP2 /dev/VGExaDb/LVDbSwap2

4. 新しいスワップ・デバイスを有効にするには、swaponコマンドを使用します。

# swapon -L SWAP2

5. 新しいスワップ・デバイスが有効であることを確認するには、swaponコマンドを使用します。

# swapon -s

次に、コマンドの出力例を示します。

Filename         Type            Size      Used     Priority
/dev/dm-3        partition       8388604   306108   -1
/dev/dm-4        partition       8388604   0         -2

6. /etc/fstabファイルを編集して、存在するスワップ・エントリをコピーして新しいスワップ・デバイスを追加し、新しいスワップ・デバイスの作成で使用したラベルへの新しいエントリのLABEL値を変更します。次の例では、新しいスワップ・デバイスが、/etc/fstabファイルにLABEL=SWAP2として追加されます。

# cat /etc/fstab
LABEL=DBSYS   /                       ext4    defaults        1 1
LABEL=BOOT    /boot                   ext4    defaults,nodev        1 1
tmpfs         /dev/shm                tmpfs   defaults,size=7998m 0
devpts        /dev/pts                devpts  gid=5,mode=620  0 0
sysfs         /sys                    sysfs   defaults        0 0
proc          /proc                   proc    defaults        0 0
LABEL=SWAP    swap                    swap    defaults        0 0
LABEL=SWAP2   swap                    swap    defaults        0 0
LABEL=DBORA   /u01                    ext4    defaults        1 1
/dev/xvdb     /u01/app/12.1.0.2/grid  ext4    defaults        1 1
/dev/xvdc       /u01/app/oracle/product/12.1.0.2/dbhome_1       ext4   defaults        1 1

関連トピック

- 新規LVMディスクのユーザー・ドメインへの追加

2.8.11 データベース・サーバーのディスク拡張後の管理ドメインの/EXAVMIMAGESの拡張

データベース・サーバーにディスク拡張キットを追加するときには、適切な手順に従って、新しい領域を/EXAVMIMAGESファイル・システムに追加することが重要です。

デプロイメント中、データベース・サーバー上の使用可能なディスク領域はすべてdom0に割り当てられ、その領域のほとんどがユーザー・ドメイン・ストレージ用の/EXAVMIMAGESに割り当てられます。

次の例では、dm01db01がdom0管理ドメインの名前で、dm01db01vm01がゲスト・ユーザー・ドメインです。

1. -checkオプションを使用して、reclaimdisks.shが実行されたことを確認します。

最後の行が"Layout: DOM0"になっています。reclaimdisks.shが実行されていない場合は、"Layout: DOM0 + Linux"のように表示されます。

[root@dm01db01 ~]# /opt/oracle.SupportTools/reclaimdisks.sh -check
Model is ORACLE SERVER X5-2
Number of LSI controllers: 1
Physical disks found: 4 (252:0 252:1 252:2 252:3)
Logical drives found: 1
Linux logical drive: 0
RAID Level for the Linux logical drive: 5
Physical disks in the Linux logical drive: 4 (252:0 252:1 252:2 252:3)
Dedicated Hot Spares for the Linux logical drive: 0
Global Hot Spares: 0
Valid. Disks configuration: RAID5 from 4 disks with no global and dedicated hot spare disks.
Valid. Booted: DOM0. Layout: DOM0.

2. ディスク拡張キットをデータベース・サーバーに追加します。
キットには4台のハード・ドライブが含まれており、これを空いている4つのスロットに挿入します。フィラー・パネルを取り外し、ドライブを挿入します。ドライブは順不同で挿入できます。

3. alerthistoryの警告およびクリア・メッセージを参照し、RAIDの再構築が完了したことを確認します。

完了までに数時間かかることもあります。次の例では約7時間かかっています。クリア・メッセージ(下のメッセージ1_2)がある場合は、再構築が完了しているため、次の手順を実行できます。

[root@dm01db01 ~]# dbmcli -e list alerthistory

1_1     2016-02-15T14:01:00-08:00       warning         "A disk
expansion kit was installed. The additional physical drives were automatically
added to the existing RAID5 configuration, and reconstruction of the
corresponding virtual drive was automatically started."

1_2     2016-02-15T21:01:01-08:00       clear           "Virtual drive
reconstruction due to disk expansion was completed."

4. 現在の環境に関する情報を収集します。

[root@dm01db01 ~]# cat /proc/partitions |grep sda
8        0 4094720000 sda
8        1     524288 sda1
8        2  119541760 sda2
8        3 1634813903 sda3

[root@dm01db01 ~]# df -h /EXAVMIMAGES
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda3             1.6T   44G  1.5T   3% /EXAVMIMAGES

[root@dm01db01 ~]# xm list
Name                                        ID   Mem VCPUs      State   Time(s)
Domain-0                                     0  8192     4     r-----  94039.1
dm01db01vm01.us.oracle.com                4 16384     2     -b----   3597.3

5. dom0からコマンドxm shutdown –a –wを実行し、すべてのユーザー・ドメイン・ゲストを停止します。

すべてのユーザー・ドメイン・ゲストが停止すると、リストにDomain-0 (dom0)のみが表示されます。

[root@dm01db01 ~]# xm shutdown –a -w
Domain dm01db01vm01.us.oracle.com terminated
All domains terminated

[root@dm01db01 ~]# xm list
Name                                        ID   Mem VCPUs      State   Time(s)
Domain-0                                     0  8192     4     r-----  94073.4

6. partedを実行し、パーティション・サイズを確認します。

不要なプロンプトを回避するには次の構文を使用します。

[root@dm01db01 ~]# parted -s /dev/sda print
Model: LSI MR9361-8i (scsi)
Disk /dev/sda: 4193GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system  Name     Flags
1      32.8kB  537MB   537MB   ext3         primary  boot
2      537MB   123GB   122GB                primary  lvm
3      123GB   1797GB  1674GB               primary

前述のパーティション表に1674GBのパーティション3が表示されています。これが変更されるパーティションです。前述のパーティション表の出力の"Disk"行からわかるように、このパーティションは123GBで開始し、ディスク・サイズは4193GBです。これらの値は手順8で使用します。

7. パーティション3を削除します。

[root@dm01db01 ~]# parted /dev/sda
(parted) rm 3
(parted) quit

このコマンドは出力を生成しません。

8. 同じ開始位置を指定して、パーティションを再作成し、結果として更新されたパーティション表を出力します。

[root@dm01db01 ~]# parted /dev/sda
(parted) mkpart primary 123gb 4193gb
(parted) print
Model: LSI MR9361-8i (scsi)
Disk /dev/sda: 4193GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system  Name     Flags
1      32.8kB  537MB   537MB   ext3         primary  boot
2      537MB   123GB   122GB                primary  lvm
3      123GB   4193GB  4070GB               primary

(parted)  quit

9. /EXAVMIMAGESパーティションを再度マウントします。

[root@dm01db01 ~]# mount /EXAVMIMAGES

[root@dm01db01 ~]# df -h /EXAVMIMAGES
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda3             1.6T   44G  1.5T   3% /EXAVMIMAGES

10. ファイル・システムのサイズは、手順4の時点と同じで1.6TBです。

11. カーネルで確認されるパーティション表に、パーティション3の更新後のサイズが表示されることを確認します。

sda3の出力が、手順4で確認した出力よりも大きくなっていることを確認します。

[root@dm01db01 ~]# cat /proc/partitions |grep sda
8        0 4094720000 sda
8        1     524288 sda1
8        2  119541760 sda2
8        3 3974653903 sda3

12. ファイル・システムを拡張します。

ファイル・システムがマウント済で処理の実行中でも、この操作は実行できます。更新後のファイル・システムのサイズを、手順4の値と比較して確認します。tunefs.ocfs2コマンドは実行速度が速く、通常は出力が生成されません。

[root@dm01db01 ~]# tunefs.ocfs2 -S /dev/sda3

[root@dm01db01 ~]# df -h /EXAVMIMAGES
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda3             3.8T   44G  3.7T   2% /EXAVMIMAGES

13. ユーザー・ドメインを再起動します。

関連トピック

- 管理ドメイン内部のユーザー・ドメインのシャットダウン

- ユーザー・ドメインの開始

2.8.12 Oracle VM Oracle RACクラスタの作成

この手順では、Oracle Exadata Deployment Assistant構成ツールおよびデプロイメント・ツールを使用して、Oracle VM Oracle RACクラスタを作成します。

Oracle VM Oracle RACクラスタを追加する要件は、次のとおりです。

- システムが、1つ以上のOracle VM Oracle RACクラスタにデプロイ済である。

- メモリー、CPU、ローカル・ディスク領域およびOracle Exadata Storage Serverディスク領域などのリソースが、システムで使用可能である。

- 最初のシステム構成で使用したOracle Exadata Deployment Assistantデプロイメント・ファイルが、使用可能である。

1. 新しいユーザー・ドメインを管理ドメインに追加するのに十分なリソースが存在していることを確認します。

Oracle VM Oracle RACクラスタを作成している場合は、新しいユーザー・ドメインを作成するすべての管理ドメインのリソースを確認します。

2. 次のコマンドを使用して、Oracle Exadata Storage Serverのディスク領域を確認します。

# dcli -l celladmin -g cell_group "cellcli -e 'list celldisk attributes name, \
diskType, freeSpace where freeSpace>0'"

3. デフォルトで、Oracle Exadata Database Machineのデータベース・サーバーにはOracle Databaseの実行に必要なパッケージのみが含まれ、データベース・サーバーではOracle Exadata Deployment Assistant構成ツールの実行はできません。

4. My Oracle Supportノート888828.1から、最新のOracle Exadata Deployment Assistantをダウンロードし、グラフィック・ベースのプログラムが実行可能なシステム上に置きます。

デフォルトで、Oracle Exadata Database Machineのデータベース・サーバーにはOracle Databaseの実行に必要なパッケージのみが含まれ、データベース・サーバーではOracle Exadata Deployment Assistant構成ツールの実行はできません。

5. Oracle Exadata Deployment Assistantテンプレート・ファイルを取得して、システムをデプロイする際に使用します。

6. 次のようにして、Oracle Exadata Deployment Assistantを実行します。

a. 「インポート」をクリックします。

b. XMLファイルを選択して開き、このファイルを使用して名前CustomerName-NamePrefix.xmlでシステムにデプロイします。

c. 「次へ」をクリックして「クラスタ定義」ページを開き、IPアドレスおよびホスト名情報をページを移動しながら確認します。初回のデプロイの後、ネットワークに変更がない場合、変更する必要はありません。

d. 「クラスタ定義」ページで、クラスタ数をインクリメントして並び替えます。

e. 新しいクラスタ・タブを選択し、クラスタ情報を編集します。それ以外のクラスタは変更しません。

f. クラスタに一意のクラスタ名を入力します。

g. 新しいクラスタについて「Oracle Virtual Server」(OVS)とCELLコンポーネントを選択し、「追加」をクリックします。

注意:

最良のパフォーマンスおよび管理の簡略化のために、すべてのセルを選択することをお勧めします。

h. 必要に応じて「次へ」をクリックし、新しいクラスタのページへ進みます。それ以外のクラスタは変更しません。

i. 新しいクラスタに情報を入力します。情報には、仮想ゲスト・サイズ、ディスク・グループ詳細およびデータベース名が含まれます。データベース名は、同一のOracle Exadata Storage Serverを使用するすべてのデータベースに対して一意の名前です。

j. 「次へ」をクリックして「確認と編集」ページを表示し、新しいクラスタの情報を確認します。

k. 必要に応じて「次へ」をクリックし、「生成」ページへ進みます。

l. 「次へ」をクリックして、新規構成ファイルを生成します。

m. 構成ファイルの保存先ディレクトリを選択します。

n. 「保存」をクリックします。

注意:

Oracle VMのデフォルトをこのクラスタで変更した場合、既存クラスタの構成の詳細が、新しいテンプレート設定に一致するように書き換えられます。たとえば、vm01のSMALLをmemory=8GBにデプロイしていた場合、新しいVMのSMALLのテンプレートをmemory=10GBに変更します。vm01を変更していないにもかかわらず、Oracle Exadata Deployment Assistant XMLファイルには、vm01がmemory=10GBと表示されます。

o. 「終了」ページの「インストール・テンプレート」をクリックして、新しいクラスタの詳細を確認します。

p. 「終了」をクリックして構成ツールを終了します。

7. 新しいクラスタがCustomerName-NamePrefix-ClusterName.xmlという名前で、保存場所フォルダに存在することをXMLファイルで確認します。

8. Oracle Grid Infrastructureおよび使用中のOracle Databaseリリースのデプロイメント・ファイルを取得し、それらをOracle Exadata Deployment Assistant WorkDirディレクトリに保存します。

9. Oracle Exadata Deployment Assistantデプロイメント・ツールを実行して、-cfオプションで新しいクラスタにXMLファイルを指定し、-lオプションで手順の一覧を表示するには、次のコマンドを実行します。

$ ./install.sh -cf    \
ExadataConfigurations/CustomerName-NamePrefix-ClusterName.xml -l

次のような出力が表示されます。

Initializing
|||||
1. Validate Configuration File
2. Update Nodes for Eighth Rack
3. Create Virtual Machine
4. Create Users
5. Setup Cell Connectivity
6. Calibrate Cells
7. Create Cell Disks
8. Create Grid Disks
9. Configure Alerting
10. Install Cluster Software
11. Initialize Cluster Software
12. Install Database Software
13. Relink Database with RDS
14. Create ASM Diskgroups
15. Create Databases
16. Apply Security Fixes
17. Install Exachk
18. Create Installation Summary
19. Resecure Machine

10. Exadata上の既存のOracle VM環境で新しいOracle VMクラスタを追加する場合は、次の手順をスキップします。

- (エイス・ラック・システムの場合のみ) 2. Update Nodes for Eighth Rack

- 6. Calibrate Cells

- 7. Create Cell Disks

注意:
手順番号は、選択したハードウェア構成に基づいて変化します。ご使用のシステムでの正しい手順を識別するには、手順名を使用します。

たとえば、手順1を実行するには、次のコマンドを実行します。

$ ./install.sh -cf \
ExadataConfigurations/CustomerName-NamePrefix-ClusterName.xml -s 1

OEDAで手順の一部のみを実行する場合は、たとえば次のように範囲を指定できます。

$ ./install.sh -cf \
ExadataConfigurations/CustomerName-NamePrefix-ClusterName.xml –r 3–5

11. 他のすべてのシステムでは、新しいクラスタについてXMLファイルを使用して、アラートの構成を除くすべての手順を実行します。

個別の手順を実行するには、次のようなコマンドを使用します(これは最初の手順を実行します)。

$ ./install.sh -cf \
ExadataConfigurations/CustomerName-NamePrefix-ClusterName.xml -s 1

2.8.13 ExadataでのOracle VM Oracle RACクラスタの拡張

Oracle Exadata Deployment Assistant (OEDA)を使用しゲスト・ドメインを追加して、Oracle VM上の既存のOracle RACクラスタを拡張できます。

注意:

この手順の実行中、既存のOracle RACクラスタ・ノードとそのデータベース・インスタンスでは、停止時間は発生しません。

この手順のユースケースは次のとおりです。

- Exadataラックのデータベース・サーバーのサブセットのみを使用する既存のOracle RACクラスタがあり、現在クラスタによって使用されていないノードが使用候補になった場合。

- 新しいOracle Virtual Serverノードまたは個別のExadataラックと最近相互ラック接続された既存のOracle RACクラスタがExadata上にある場合。

1. OEDAを使用して、新しいゲスト・ドメインをホストするdom0に追加する、新しいゲスト・ドメイン(仮想マシン)の情報を含む新しいXMLファイルを作成します。

生成されたXMLファイルをunzipped_OEDA_location/ExadataConfigurationsに保存します。

単一のゲスト・ドメインを追加している場合、XMLファイルは単一ノードOracle RACクラスタを表します。

クラスタ定義画面の下のすべての画面のデータは、既存のクラスタのXMLファイルと同じです。

a. クラスタの定義画面で適切なOracle Virtual Server (OVS)を選択します。次の図は、クラスタへの単一ノードの追加を示しています。

図2-1 OEDAのクラスタ定義ページ

b. IPアドレスやプール・サイズなどのクラスタの詳細をクラスタの詳細画面に入力します。次の図は、クラスタへの単一ノードの追加を示しています。

図2-2 OEDAの「クラスタ」ページ

2. 手順1で作成したXMLファイルを使用してOEDA (install.sh)を実行し、OEDAで次の手順を実行します。

- 仮想マシンの作成

- ユーザーの作成

- セル接続の設定

前述の手順の手順番号は、次のコマンドを使用してリストできます。

./install.sh -cf ./ExadataConfigurations/xml_file_generated_in_step_1 -l

注意:
手順番号は、選択したハードウェア構成に基づいて変化するため、前述のコマンドを使用して注意して調べてください。

OEDAで手順の一部のみを実行する場合は、–r 2–4のように、範囲を指定できます

cd unzipped_OEDA_location
./install.sh -cf ./ExadataConfigurations/xml_file_generated_in_step_1 -r range_of_step_numbers_for_the_above_steps

3. クラスタに追加するゲスト・ドメインをクリーン・アップし、後でaddnode.shによって使用されるように準備します。

a. 新しく作成されたゲスト・ドメインにrootとしてログインし、次を実行します。

# cd /
# chown -R oracle:oinstall /u01
# cd /u01/app/12.1.0.2/grid  (cd to the Grid_home)
# rm -rf *
# cd /u01/app/oracle/product/12.1.0.2/dbhome_1  (cd to the Oracle_home)
# rm -rf *

b. oraInventoryが/u01/app内に存在していないことを確認します。

c. /etc/oraInst.locが存在していないことを確認します。

4. 新しく追加されたゲスト・ドメインからセキュア・シェル(SSH)等価のクラスタを他のすべてのノードに設定します。

a. 新しく作成されたゲスト・ドメインを含むクラスタに属している各ゲスト・ドメインに、oracleとしてログインします。

b. 新しく追加されたゲスト・ドメインを含むクラスタに属しているすべてのゲスト・ドメイン名が含まれている/home/oracleに、db_groupという名前のファイルを作成します。

c. 新しく追加されたドメインを含むクラスタのすべてのゲスト・ドメインから、次のコマンドをoracleとして実行して、すべてのプロンプトに答えます。

dcli -g db_group -l oracle -k

d. クラスタのすべてのノードでSSH等価が正しく設定されていることを検証します。

5. クラスタのすべてのノードでファイルの同期を取ります。

クラスタのすべてのノードで同じになるように、既存のクラスタからファイルを使用して、新しく追加されたノードに次のファイルの内容をコピーまたはマージします。

- /etc/security/limits.conf

- /etc/hosts
すべてのクラスタ・ノードのIPアドレスとセルのIPアドレスが含まれるように、/etc/hostsファイルを1つのノードで最初に変更してから、そのファイルをすべてのクラスタ・ノードにコピーする必要があります。

- /etc/oracle/cell/network-config/cellip.ora

- /etc/sysctl.conf

6. 新しく追加されたすべてのノード(ゲスト・ドメイン)を再起動します。

7. 新しく追加されたゲスト・ドメインの/etc/oracle/cell/network-config/cellip.oraの所有権を変更します。

# chown oracle:oinstall /etc/oracle/cell/network-config/cellip.ora

8. クラスタの既存のノードから次のコマンドを実行して、クラスタおよび新しいノードの完全性を確認します。このノードは、残りの手順でinit-nodeと呼びます。

$ cluvfy stage -pre nodeadd -n comma_delimited_node_names [-fixup] [-verbose]

–fixupおよび–verboseオプションは必要に応じて指定します。

9. Oracle Grid Infrastructureホームを新しいノードに拡張するには、init-nodeのGrid_home/addnodeディレクトリに移動して、Oracle Clusterwareをインストールしたユーザーとしてaddnode.shスクリプトを実行します。

$ cd Grid_home/addnode

$ ./addnode.sh -silent "CLUSTER_NEW_NODES={comma_delimited_node_names}" "CLUSTER_NEW_VIRTUAL_HOSTNAMES={comma_delimited_node_vips)}"

10. プロンプトが表示されたら、新しく追加されたすべてのノードで、orainstRoot.shをrootとして順に実行します。

# /opt/oracle/oraInventory/orainstRoot.sh

11. 新しく追加されたすべてのノードで、Grid_home/root.shをrootとして順に実行します。

12. データベース・ホームを新しく追加されたノードに拡張します。

init-nodeの$ORACLE_HOME/addnodeディレクトリに移動して、Oracle RACをインストールしたユーザーとしてaddnode.shを実行します。

$ cd $ORACLE_HOME/addnode

$ ./addnode.sh -silent "CLUSTER_NEW_NODES={comma_delimited_node_names}"

13. プロンプトが表示されたら、新しく追加されたノードで$ORACLE_HOME/root.shをrootとして実行します。

14. Oracle Database Configuration Assistant (DBCA)を使用して、データベース・インスタンスを新しく追加されたノードに追加します。サイレント・モードまたはグラフィカル・ユーザー・インタフェースを使用します。

サイレント・モードを使用している場合は、次のコマンドを実行します。

$ $ORACLE_HOME/bin/dbca -addInstance -gdbName global database name
-nodeName node_name_for_new_instance
-instanceName instance_name_for_new_instance
-sysDBAUserName SYS -sysDBAPassword password -silent

15. 新しく追加されたASMインスタンスとデータベース・インスタンスにcluster_interconnectsパラメータを設定します。

新しく追加された各ノードから、そのノードの新しいOracle ASMインスタンスとデータベース・インスタンスに、次の手順を実行します。

a. SQL*Plusを起動して、Oracle ASMインスタンスに接続します。

b. 新しいOracle ASMインスタンスのcluster_interconnectsパラメータを設定します。

alter system set cluster_interconnects=IP_address_of_private_interconnects scope=spfile sid=newly_added_ASM_instance;

c. SQL*Plusを起動して、データベース・インスタンスに接続します。

d. 新しいデータベース・インスタンスのcluster_interconnectsパラメータを設定します。

alter system set cluster_interconnects=IP_address_of_private_interconnects scope=spfile sid=newly_added_DB_instance;

16. 新しく追加されたノードでOracle Grid Infrastructureスタックを再起動します。

2.8.14 Oracle Grid InfrastructureおよびOracle Databaseの存在しないユーザー・ドメインの作成

ユーザー・ドメインは、システムにOracle Grid InfrastructureおよびOracle Databaseをインストールせずに作成することができます。新しいユーザー・ドメインの要素は、次の通りです。

- オペレーティング・システム・イメージがOracle Linuxである。

- 管理ネットワーク、クライアント・ネットワークおよびInfiniBandネットワークへアクセスできる。

- Oracle Grid InfrastructureおよびOracle Databaseがインストールされていない。

Oracle Grid InfrastructureおよびOracle Databaseの存在しないユーザー・ドメインを作成する手順は、次の通りです。

1. 未使用の新規IPアドレスおよびホスト名を新しいユーザー・ドメインに割り当てます。IPアドレスおよびホスト名は、管理ネットワーク、クライアント(SCAN)ネットワークおよびプライベートInfiniBandネットワークで必要です。

注意:

アドレスごとにpingコマンドを使用して、該当のInfiniBandネットワークのIPアドレスが使用されていないことを確認します。ibhostsコマンドには、ユーザー・ドメインのエントリが含まれていないため、このコマンドを使用して、すべてのInfiniBandネットワークのIPアドレスが使用されていることを確認することはできません。

2. 必要に応じて、更新されたユーザー・ドメイン(domU)システム・イメージ・ファイルを取得します。
ユーザー・ドメインを作成するために、この手順の後で実行するexadata.img.domu_makerコマンドには、ユーザー・ドメイン(domU)システム・イメージ・ファイルSystem.first.boot.version.imgが/EXAVMIMAGESに必要です(versionは、管理ドメインのExadataソフトウェアのバージョンに一致し、管理ドメインで"imageinfo -ver"コマンドを実行することで確認できます)。

たとえば、exadata.img.domu_makerを実行して、新しいユーザー・ドメインを作成し、管理ドメインのExadataソフトウェアのバージョンが12.1.2.1.1.150316.2の場合、ユーザー・ドメイン(domU)システム・イメージ・ファイル/EXAVMIMAGES/System.first.boot.12.1.2.1.1.150316.2.imgが存在する必要があります。

# imageinfo -ver
12.1.2.1.1.150316.2

# ls -l /EXAVMIMAGES/System.first.boot.12.1.2.1.1.150316.2.img
-rw-r--r-- 1 root root 13958643712 Mar 23 12:25 /EXAVMIMAGES/System.first.boot.12.1.2.1.1.150316.2.img

ユーザー・ドメイン(domU)システム・イメージ・ファイルが存在しない場合は、My Oracle Supportから取得し、管理ドメインの/EXAVMIMAGESに配置する必要があります。詳細は、My Oracle Supportノート888828.1を参照してください。

3. 次のコマンドを使用して、管理ドメインで、既存のXML構成ファイルをデプロイ済ユーザー・ドメインからコピーして、新しい名前のファイルにコピーします。

# cp /EXAVMIMAGES/conf/existingDomainName-vm.xml /EXAVMIMAGES/conf/newDomainName-vm.xml

前述のコマンドで、existingDomainName-vm.xmlは、デプロイされたユーザー・ドメインのXML構成ファイルで、newDomainName-vm.xmlは新しいファイルの名前です。

次の例では、ユーザー・ドメイン"dm01db01vm01"の構成ファイルを、nondbdomain-vm.xmlにコピーします。

# cp /EXAVMIMAGES/conf/dm01db01vm01-vm.xml /EXAVMIMAGES/conf/nondbdomain-vm.xml

4. 管理ドメインで、次のようにして、新しいXMLファイルを編集します。

a. すべての<Hostname>タグを変更して、対応するネットワークの新しいホスト名に一致させます。

b. すべての<IP_address>タグを変更して、対応するネットワークの新しいIPアドレスに一致させます。

c. <virtualMachine>タグを変更して、新しいホスト名を含めます。

d. <hostName>タグを変更して、新しいホスト名を含めます。

e. すべてのサブ要素を含む、<disk id="disk_2">および<disk id="disk_3">要素全体を削除します。開始<disk>タグから対応する終了</disk>の間のエントリ全体を削除する必要があります。

5. 管理ドメインで、/opt/exadata_ovm/exadata.img.domu_makerコマンドを使用して、InfiniBandネットワークGUIDを新しいユーザー・ドメインに割り当てます。

# /opt/exadata_ovm/exadata.img.domu_maker allocate-guids \
/EXAVMIMAGES/conf/newDomainName-vm.xml              \
/EXAVMIMAGES/conf/final-newDomainName-vm.xml

6. 管理ドメインで、/opt/exadata_ovm/exadata.img.domu_makerコマンドを使用して、新しいユーザー・ドメインを作成します。

# /opt/exadata_ovm/exadata.img.domu_maker start-domain \
/EXAVMIMAGES/conf/final-newDomainName-vm.xml

2.8.15 ユーザー・ドメインの別のデータベース・サーバーへの移動

ユーザー・ドメインを、別のデータベース・サーバーへ移動することができます。ターゲット・データベース・サーバーが、次の要件を満たしている必要があります。

- ターゲット・データベース・サーバーに、同一リリースのOracle Exadata Storage Server SoftwareおよびOracle VMがインストールされている。

- ターゲット・データベース・サーバーに、同一のネットワークが表示されている。

- ターゲット・データベース・サーバーは、同一のExadata Storage Serversにアクセスできる。

- ターゲット・データベース・サーバーで、ユーザー・ドメインの操作に必要な十分な空きリソース(メモリー、CPUおよびローカル・ディスク領域)が使用可能である。

- 仮想CPUをオーバーコミットすると、すべてのドメインに割り当てられた仮想CPUを、システム上の物理CPU数より多く割り当てることができます。CPUのオーバーコミットは、過剰に収容されたリソースへの競合するワークロードが十分理解され、同時に発生する要求が物理能力を超えない場合にのみ、実行する必要があります。

- メモリーをオーバーコミットすることはできません。

- ディスク・イメージをターゲット・データベース・サーバーにコピーすると、ディスク・イメージ・ファイルの領域の割当てが増加する場合があります。これは、コピーされたファイルは、OCFS2 reflinkを利用してディスク領域を省略できないためです。

- ユーザー・ドメイン名は、ターゲット・データベース・サーバーで未使用の名前にする必要があります。

次の手順に従い、ユーザー・ドメインを同一のOracle Exadata Storage Server Software構成内の新しいデータベース・サーバーに移動します。すべての手順は、管理ドメインで実行してください。

1. 次のコマンドを使用して、ユーザー・ドメインをシャットダウンします。

# xm shutdown DomainName -w

2. 次のコマンドを使用して、ユーザー・ディスク・イメージおよび構成ファイルをターゲット・データベース・サーバーにコピーします。

# scp -r /EXAVMIMAGES/GuestImages/DomainName/ target:/EXAVMIMAGES/GuestImages

上記のコマンドで、DomainNameはドメインの名前です。

3. 次のコマンドを使用して、ユーザー・ドメインのUUIDを取得します。

# grep ^uuid /EXAVMIMAGES/GuestImages/DomainName/vm.cfg

次の例では、ユーザー・ドメインUUIDは49ffddce4efe43f5910d0c61c87bba58です。

# grep ^uuid /EXAVMIMAGES/GuestImages/DomainName/vm.cfg
uuid = '49ffddce4efe43f5910d0c61c87bba58'

4. 次のコマンドを実行して、ユーザー・ドメインのUUIDを使用し、ユーザー・ドメイン・シンボリック・リンクを/OVS/Repositoriesから、ターゲット・データベース・サーバーにコピーします。

# tar cpvf - /OVS/Repositories/UUID/ | ssh target "tar xpvf - -C /"

5. 次のコマンドを使用して、ユーザー・ドメインをターゲット・データベース・サーバーで起動します。

# xm create /EXAVMIMAGES/GuestImages/DomainName/xm.cfg

2.8.16 Oracle VMで実行するOracle RACクラスタの削除

クラスタ内で実行中のデータベースおよびこのデータベースで使用中のOracle Exadata Storage Serverで保存するすべてのデータを含む、Oracle VMクラスタのすべてのOracle RACノードを削除します。

Oracle VMクラスタの一部のユーザー・ドメインを削除する場合、次の項を参照してください。

Oracle VMクラスタを削除する手順は、主に2つあります。

- ユーザー・ドメイン・ファイルを管理ドメインから削除する。

- 使用していないOracle Exadataグリッド・ディスクを削除する。

注意:

Oracle Exadata Deployment Assistant xml構成ファイルを後で再び使用する場合、削除されたユーザー・ドメインの定義がOracle Exadata Deployment Assistantファイル内に残っているため、それらの構成ファイルは同期できません。

1. 次のようなスクリプトを実行して、すべてのユーザー・ドメイン上のグリッド・ソフトウェア・オーナーを削除します。

シェル・スクリプトの例では、2つのスクリプト、list_griddisk.shおよびdrop_griddisk.shが生成されます。これらは、後述する手順で実行します。指示があるまで、この生成されたスクリプトを実行しないでください。

#!/bin/bash

# Run this script as the Grid Infrastructure software owner.
#
# This script identifies griddisks used by this cluster and the cells to
# which they belong, then creates two shell scripts - the list script to
# show the current status, and the drop script to drop the griddisks.
#
# In order for the drop script to succeed, the griddisks must not be in use,
# meaning databases and CRS are down, and the list script returns no output.
#
# The generated scripts are designed to run via dcli -x

ORACLE_SID=$(awk -F: '/^+ASM/{print $1}' /etc/oratab)
ORAENV_ASK=NO . oraenv >/dev/null

listGriddiskScript=list_griddisk.sh
dropGriddiskScript=drop_griddisk.sh

rm -f $listGriddiskScript $dropGriddiskScript

gridDiskList=$(asmcmd lsdsk --suppressheader | awk -F'/' '{print $NF}')
if [[ ${PIPESTATUS[0]} != 0 ]]; then echo "asmcmd failed - exiting"; exit 1; fi

cellList=$(echo "$gridDiskList" | awk -F_ '{print $NF}' | sort -u)

for cell in $cellList; do
myGriddisks=$(echo "$gridDiskList" | grep ${cell}$ | tr '\n' ',')
echo "[[ \$(hostname -s) == ${cell} ]] && cellcli -e 'LIST GRIDDISK \
${myGriddisks%,} attributes name, asmDiskGroupName, asmModeStatus \
where asmModeStatus != UNKNOWN'" >> $listGriddiskScript
echo >> $listGriddiskScript
done

chmod +x $listGriddiskScript

echo
echo "Run the following command to list griddisks in use by this cluster:"
echo
echo "# dcli -l celladmin -c ${cellList//$'\n'/,} -x $listGriddiskScript"
echo

for cell in $cellList; do
myGriddisks=$(echo "$gridDiskList" | grep ${cell}$ | tr '\n' ',')
echo "[[ \$(hostname -s) == ${cell} ]] && cellcli -e 'DROP GRIDDISK \
${myGriddisks%,}'" >> $dropGriddiskScript
echo >> $dropGriddiskScript
done

chmod +x $dropGriddiskScript

echo
echo "Stop CRS on all nodes in this cluster, then run the following"
echo "command to drop all griddisks used by this cluster:"
echo
echo "# dcli -l celladmin -c ${cellList//$'\n'/,} -x $dropGriddiskScript"
echo

exit

2. 削除対象のすべてのユーザー・ドメイン内のデータベースおよびOracle Grid Infrastructureを停止します。

# Grid_home/bin/crsctl stop crs -f

3. 削除対象のいずれかのユーザー・ドメインから、前述の手順で生成されたlist_griddisk.shスクリプトを実行します。

注意:

- dcliコマンドを使用してスクリプトを実行し、celladminユーザーとして構成内のすべてのOracle Exadata Storage Serverに接続します。

- dcliコマンドを実行する前に、データベース・サーバーのグリッド・ソフトウェア所有者とセルのcelladminユーザーの間に、パスワードなしのSSH接続を設定します。そうしないでコマンドを実行すると、パスワードの入力が常に求められます。

このコマンドの例を次に示します。

$ dcli -l celladmin -c dm01celadm01,dm01celadm02,dm01celadm03  \
-x list_griddisk.sh

list_griddisk.shスクリプトは、グリッド・ディスクを出力しません。list_griddisk.shスクリプトがグリッド・ディスクを戻す場合、そのグリッド・ディスクは使用中であるとみなされます。

list_griddisk.shスクリプトが空の出力を戻し、使用中のグリッド・ディスクがないことを確認してから、次の手順に進みます。Oracle Grid Infrastructureおよびデータベースが、削除するすべてのユーザー・ドメインで停止していることを確認してください。

4. 削除対象のいずれかのユーザー・ドメインから、前述の手順で生成されたdrop_griddisk.shスクリプトを実行します。

dcliコマンドを使用してスクリプトを実行し、celladminユーザーとして構成内のすべてのOracle Exadata Storage Serverに接続します。

$ dcli -l celladmin -c dm01celadm01,dm01celadm02,dm01celadm03 \
-x drop_griddisk.sh

5. 削除対象の各ユーザー・ドメインの管理ドメインからexadata.img.domu_makerコマンドを実行します。

このコマンドでユーザー・ドメインが削除されます。DomainNameがユーザー・ドメインの名前です。

# /opt/exadata_ovm/exadata.img.domu_maker remove-domain DomainName

次の例では、コマンドを実行して、2ノードOracle VM RACクラスタの2つのユーザー・ドメインを削除します。1つは、管理ドメインdm01db01上のユーザー・ドメインdm01db01vm04で、もう1つは、管理ドメインdm01db02上のユーザー・ドメインdm01db02vm04です。

[root@dm01db01 ~] # /opt/exadata_ovm/exadata.img.domu_maker \
remove-domain dm01db01vm04
[INFO] Start with command line: /opt/exadata_ovm/exadata.img.domu_maker \
remove-domain dm01db01vm04
[INFO] Shutting down DomU dm01db01vm04
[INFO] Autostart link for dm01db01vm04 deleted from /etc/xen/auto
[INFO] Deleted OVM repository /OVS/Repositories/7bfd49d6bd5a4b2db2e46e8234788067 for DomU dm01db01vm04
[INFO] Deleted guest vm /EXAVMIMAGES/GuestImages/dm01db01vm04 for \
DomU dm01db01vm04

[root@dm01db02 ~]# /opt/exadata_ovm/exadata.img.domu_maker \
remove-domain dm01db02vm04
[INFO] Start with command line: /opt/exadata_ovm/exadata.img.domu_maker \
remove-domain dm01db02vm04
[INFO] Shutting down DomU dm01db02vm04
[INFO] Autostart link for dm01db02vm04 deleted from /etc/xen/auto
[INFO] Deleted OVM repository /OVS/Repositories/1d29719ff26a4a17aca99b2f89fd8032 for DomU dm01db02vm04
[INFO] Deleted guest vm /EXAVMIMAGES/GuestImages/dm01db02vm04  \
for DomU dm01db02vm04

2.8.17 Oracle VM Oracle RACクラスタからのユーザー・ドメインの削除

Oracle VMクラスタから1つのOracle RACノードを削除できます。

Oracle Exadataグリッド・ディスクは、クラスタ内に残っているノードで使用中のため、削除しないでください。

注意:

Oracle Exadata Deployment Assistant xml構成ファイルを後で再び使用する場合、削除されたユーザー・ドメインの定義がOracle Exadata Deployment Assistantファイル内に残っているため、それらの構成ファイルは同期できません。

1. クラスタ・ノードを削除します。

2. 次のコマンドを使用して、ユーザー・ドメインをシャットダウンし、削除します。DomainNameがドメインの名前です。

# /opt/exadata_ovm/exadata.img.domu_maker remove-domain DomainName

このコマンドは、ユーザー・ドメイン・ファイルを管理ドメインから削除します。

関連トピック

- Oracle Clusterware管理およびデプロイメント・ガイド

2.8.18 タグVLANインタフェースの実装

このトピックでは、Exadata上のOracle VM環境でのタグVLANインタフェースの実装について説明します。

Oracle Exadata Database Machine上のOracle VMゲストで稼働しているOracleデータベースは、Oracle Exadata Deployment Assistant (OEDA)構成ツールで定義されたクライアントEthernetネットワークを介してアクセスされます。管理ドメイン(dom0)およびユーザー・ドメイン(domU's)の両方で、クライアント・ネットワーク構成は、初回のデプロイメント中にOEDAインストール・ツールが最初のユーザー・ドメインを作成すると、自動的に実行されます。

次の図に、デフォルトの結合クライアント・ネットワーク構成を示します。

図2-3 Oracle Virtual EnvironmentのNICレイアウト

ネットワークは、次のように構成されます:

1. dom0では、OEDAで定義されて、domUクライアントへのアクセスが許可されているethスレーブ・インタフェース(たとえば、eth1とeth2またはeth4とeth5)が、検出、構成されて、起動しますが、IPは割り当てられません。

2. dom0では、bondeth0マスター・インタフェースが構成され、起動しますが、IPは割り当てられません。

3. dom0では、ブリッジ・インタフェースvmbondeth0が構成されますが、IPは割り当てられません。

4. dom0では、特定のdomU's bondeth0インタフェースにマッピングされる仮想バックエンド・インタフェース(vif)がdomUごとに1つずつ構成され、起動しますが、IPは割り当てられません。これらのvifsは、ブリッジ・インタフェースvmbondeth0の上に構成されます。dom0 vifインタフェースと、これに対応するユーザー・ドメイン・インタフェース、bondeth0の間のマッピングは、/EXAVMIMAGES/GuestImages/user domain nameにあるvm.cfgと呼ばれるユーザー・ドメイン構成ファイルで定義されます。

デフォルトのインストールでは、単一のbondeth0と対応するvmbondeth0ブリッジ・インタフェースは、前述で説明するようにdom0内で構成されます。このbondeth0インタフェースは、デフォルトのAccess Virtual Local Area Network (Access VLAN)に基づいています。Access VLANに対して、bondeth0を構築するスレーブ・インタフェースで使用されるスイッチ上のポートが構成されます。

VLANタグ付けの使用

Exadataの仮想デプロイメントで、ユーザー・ドメインをまたいでネットワーク分離を有効にするなど、クライアント・ネットワーク上の他のVLANにアクセスする必要がある場合、802.1QベースのVLANタグ付けにより解決できます。次の図に、VLANタグ付けをしたクライアント・ネットワーク構成を示します。

図2-4 VLANタグ付けをしたOracle Virtual EnvironmentのNICレイアウト

このようなクライアント・ネットワーク上の追加のタグ付けされたVLANインタフェースの構成方法および使用方法の手順は、My Oracle Supportノート2018550.1を参照してください。これらの手順の実行の前後に、Access VLANが継続して稼働および構成されている必要があります。Access VLANが無効にされることはありません。

関連トピック

- タグ付けされたVLANインタフェースのExadata上のOracle VM環境への実装(My Oracle SupportのドキュメントID 2018550.1)

2.8.19 Oracle ExadataでのOracle VM Oracle RACクラスタ間のInfiniBandパーティションの実装

セキュリティの見地から、結合システムの重要な要件の1つは、結合システム内の複数の環境間のネットワーク分離です。Oracle Exadata上でOracle VM Oracle RACクラスタを使用した結合では、これは、1つのOracle RACクラスタのネットワーク・トラフィックが別のOracle RACクラスタにアクセスできないようするなどの、異なるOracle RACクラスタ同士の分離を意味します。Ethernetネットワークでは、これは、My Oracle Support DocID 2018550.1で説明するように、VLANタグ付けを使用して完成します。InfiniBandネットワークでは、これは、カスタムInfiniBandパーティション、専用パーティション鍵およびパーティション化表を使用して完成します。

InfiniBandパーティションは、相互の通信を許可されるInfiniBandノードまたはメンバーのグループを定義します。InfiniBandパーティションでは、一意のパーティション鍵で識別されるパーティションが作成され、マスター・サブネット・マネージャで管理されます。メンバーは、これらのカスタム・パーティションに割り当てられます。パーティション内のメンバーは、メンバー自身同士でのみ通信できます(My Oracle Support DocID 2018550.1の付録1で説明するように、メンバーシップにより異なります)。1つのパーティションのメンバーは、別のパーティションのメンバーとは、メンバーシップにかかわらず、通信できません。これらのラインを継続して、特定の1つのクラスタのOracle VM Oracle RACノードが、クラスタウェア通信用の1つの専用パーティションに割り当てられ、ストレージ・セルとの通信用の1つのパーティションに割り当てられます。このようにして、1つのOracle RACクラスタのノードは、異なるパーティションに属する別のRACクラスタのノードと通信できます。それぞれのOracle RACクラスタのノードには、それらに割り当てられた異なるパーティション鍵があります。

デフォルトで、InfiniBandサブネット・マネージャは、パーティション鍵0x7FFF (制限されたメンバーシップ)または0xFFFF (完全なメンバーシップ)により識別される単一パーティションを提供します。カスタムのInfiniBandパーティションを使用していないOracle Exadata上のOracle VMデプロイメントでは、すべてのユーザー・ドメイン間で、パーティション鍵0xFFFFが使用されます。

図2-5 クラスタ間でInfiniBandネットワーク分離がないOracle Exadata上のOracle VM Oracle RACクラスタ

Oracle VM Oracle RACクラスタ間の分離の実装のかわりのデフォルトではないカスタム・パーティションを使用すると、構成は、図2-6に示すように変更されます。新しいインタフェースclib0、clib1 (クラスタpkey用)およびstib0、stib1 (ストレージpkey用)が、それぞれのユーザー・ドメイン(domU's)に存在します。

管理ドメイン(dom0)では、InfiniBandインタフェースの変更はありません。

図2-6 InfiniBandパーティションを使用してクラスタ間でInfiniBandネットワーク分離があるOracle Exadata上のOracle VM Oracle RACクラスタ

関連トピック

- 「ExadataでのOVM RACクラスタ間のInfiniBandパーティションの実装」(Doc ID 2075398.1)

- 「タグ付けされたVLANインタフェースのExadata上のOracle VM環境への実装」(Doc ID 2018550.1)

2.8.19.1 OVM RACクラスタ間のInfiniBandパーティションの実装: 要件

InfiniBandパーティションの構成前に、次のことを確認します。

- ExadataシステムでOVMを構成しました。

- すべてのユーザー・ドメインとストレージ・セルで、デフォルトのパーティション鍵0xFFFFを使用しています。

- rootユーザー用に、いずれかの管理ドメイン(dom0ノード)からすべてのOVM RACクラスタ・ノード、ストレージ・セルおよびInfiniBandスイッチへの、パスワードなしのセキュア・シェル(SSH)・アクセスを設定しました。

- InfiniBandスイッチがファームウェア・バージョン2.0.4以上で設置されています。

- InfiniBandパーティションについて理解しています。

2.8.19.2 OVM RACクラスタ間のInfiniBandパーティションの実装: 手順

InfiniBandパーティションを実装するには、次の大まかな手順を実行します。

1. InfiniBandスイッチで、クラスタウェアで使用されるそれぞれのOVM RACクラスタに対して、専用パーティション(クラスタpkey)を作成します。

2. InfiniBandスイッチで、RACクラスタ・ノードとストレージ・セルとの通信のために、すべてのOVM RACクラスタおよびストレージ・セルで使用される1つのパーティション(ストレージpkey)を作成します。

3. パーティションごとに、新しいIPoIBネットワーク・インタフェースが必要です。OVM RACノードとストレージ・セルで、新しいIPoIBインタフェースのすべての関連するネットワーク構成ファイルを生成します(前の図のclib0、clib1、stib0、stib1)。

4. 新しく作成したIPoIBインタフェースを使用するように、すべてのOVM RACクラスタのOVM RACクラスタ・ノードとグリッド・インフラストラクチャ構成を変更します。

5. 管理ドメイン(dom0)で、各ユーザー・ドメインのユーザー・ドメイン構成ファイルを、そのユーザー・ドメインに該当するパーティション鍵を使用するように変更します。

6. 新しく作成したIPoIBインタフェースを使用するようにストレージ・セルを変更します。

7. ストレージ・セルとRACクラスタを再起動して、グリッド・インフラストラクチャとデータベースが機能することを確認します。この一連の手順では、RACクラスタで多少のダウンタイムが発生します。この手順のときにダウンタイムが発生します。

この項では、各手順について詳しく説明します。

1. pkeyインタフェースによって使用されるIPアドレスを割り当てます。
クラスタにInfiniBandパーティションが実装されたときに、クラスタpkeyインタフェースおよびストレージpkeyインタフェースで使用される各OVM RACクラスタのIPアドレスとネットマスクのセットを計画して割り当てます。

OVM RACクラスタ内では、クラスタpkey IPアドレスおよびネットマスクは、ストレージpkey IPアドレスおよびネットマスクとは別のサブネット上に存在する必要があります。

参考として、次の表に、ある特定のRACクラスタのものを示します。

表2-2 既存の構成

インタフェース名

IPアドレス

ネットマスク

ib0

192.168.12.153

255.255.248.0

ib1

192.168.12.154

255.255.248.0

次の表に、この1つのRACクラスタに対してこのドキュメントの手順を実行したときにpkeyインタフェースによって要求される新しいIPアドレスとネットマスクを示します。

表2-3 pkeyインタフェースによって要求される新しいIPアドレスとネットマスク

インタフェース名

IPアドレス

ネットマスク

clib0

192.168.112.1

255.255.248.0

clib1

192.168.112.2

255.255.248.0

stib0

192.168.114.1

255.255.240.0

stib1

192.168.114.2

255.255.240.0

2. InfiniBandスイッチでパーティション鍵を作成して構成します。

a. rootユーザー用に、いずれかのdom0ノードからInfiniBandファブリックのすべてのスイッチへのパスワードなしのSSH等価を有効化します。これは、この手順のすべてのスクリプトを実行するために使用するノードです。この手順では、このノードをドライバdom0と呼びます。
これを行うには、スクリプトを実行するために使用されるdom0ノードから、次のdcliコマンドを実行します。

# dcli –g <ib_switch_list> -l root –k

<ib_switch_list>は、ファブリックのすべてのInfiniBandスイッチが1つずつ個々の行に記載されたリストが含まれるファイルを示します。

b. My Oracle Supportノート2075398.1から、create_pkeys.tarをドライバdom0ノードにダウンロードして解凍します。tarファイルを解凍すると、3つのファイルが表示されます。

- create_pkeys_on_switch.sh

- run_create_pkeys.sh

- create_pkey_files.sh

c. ドライバdom0からスクリプトcreate_pkeys_on_switch.shを実行して、InfiniBandスイッチでパーティション鍵を作成して構成します。

注意:

create_pkeys_on_switch.shを1回実行すると、1つのパーティションが作成されます。作成するパーティションごとにスクリプトを1回実行する必要があります。たとえば、2つのOVM RACクラスタを含む環境に、1つのストレージ・パーティションと2つのクラスタ・パーティション(RACクラスタごとに1つ)の合計3つのパーティションを作成するとします。この例では、create_pkeys_on_switch.shを3回実行する必要があります。

このスクリプトは、1つのみのノード(ドライバdom0)から実行する必要があります。これにより、スクリプトの実行中に入力として指定されたすべてのスイッチにパーティションが作成されます。

スクリプトの完了後に、すべてのスイッチでパーティションが作成されたことを確認します。

# /usr/local/sbin/smpartition list active no-page

この段階で、すべての必要なパーティションを作成したことを確認します。

3. パーティション鍵を使用するために、OVM RACクラスタ・ノードを構成します。

注意:

この手順では、OVM RACクラスタ・ノードに次の変更を加えます。

- 次のファイルを変更します。

- /etc/sysconfig/network-scripts/ifcfg-ib0

- /etc/sysconfig/network-scripts/ifcfg-ib1

- 次のファイルを削除します。

- /etc/sysconfig/network-scripts/rule-ib0

- /etc/sysconfig/network-scripts/rule-ib1

- /etc/sysconfig/network-scripts/route-ib0

- /etc/sysconfig/network-scripts/route-ib1

- 前述のファイルを変更または削除する前に、スクリプトでこれらを/etc/sysconfig/network-scripts/backup-for-pkeysディレクトリにバックアップします。この手順が失敗した場合は、この手順を再実行する前に、/etc/sysconfig/network-scripts/backup-for-pkeysから/etc/sysconfig/network-scriptsにすべてのファイルをリストアします。

- /etc/sysconfig/network-scriptsに次の新しいファイルを作成します。

- ifcfg-clib0

- ifcfg-clib1

- rule-clib0

- rule-clib1

- route-clib0

- route-clib1

- ifcfg-stib0

- ifcfg-stib1

- rule-stib0

- rule-stib1

- route-stib0

- route-stib1

この手順が失敗し、前述のファイルが作成された場合は、この手順を再実行する前にこれらのファイルを削除する必要があります。

a. 手順1で使用したドライバdom0ノードからの、パーティション鍵に対して構成する必要があるすべてのRACクラスタ・ノードおよびストレージ・セルへのパスワードなしのSSHが設定されていることを確認します。

b. run_create_pkeys.shおよびcreate_pkey_files.shが実行可能で、これらがドライバdom0ノードの同じディレクトリに存在することを確認します。

c. run_create_pkeys.shを実行します。このスクリプトの構文は次のとおりです。

run_create_pkeys.sh <node_name> <interface_name> <pkey_id> <node_type> <pkey_ipaddr> <pkey_netmask> <pkey_interfaceType>

<node_name>にノード名を指定します。

<interface_name>はib0またはib1のいずれかです。

<pkey_id>に、0xの接頭辞を除いたpkeyを指定します。

<node_type>はcomputeまたはcellのいずれかです。

<pkey_ipaddr>にIPアドレスを指定します。

<pkey_netmask>に、/21などのCIDR形式のネットマスクを指定します。

<pkey_interfaceType>は、computeノード・タイプの場合はclusterまたはstorage、cellノード・タイプの場合はstorageです。

注意:

クラスタpkeyインタフェースのpkey_ipaddrおよびpkey_netmaskは、ストレージpkeyインタフェースのpkey_ipaddrおよびpkey_netmaskとは異なるサブネット上に存在する必要があります。

クラスタ・ノードの場合は、computeのノード・タイプ値を使用して、それぞれのクラスタ・ノードに対して合計4回スクリプトを実行する必要があります。

<pkey_id>は、手順2で入力したクラスタのpkey_idの値から導出されたクラスタのパーティション鍵です。

次のコマンドを使用すると、手順2で入力したpkey_idの値から、前述のコマンドに入力するパーティション鍵の値を導出できます。

FinalHexValue=$(echo "obase=16;ibase=2;$(expr 1000000000000000 + $(echo "obase=2;ibase=16;$(echo $HexValue|tr [:lower:] [:upper:])"|bc))"|bc|tr [:upper:] [:lower:])

FinalHexValueはここでコマンドに入力される値で、HexValueは手順2で入力したpkey_idの値です。

次の表で、4回の実行について説明します。

表2-4 クラスタ・ノードに対する4回の実行

実行

インタフェース名

pkey_id

node_type

pkey_ipaddress

pkey_netmask

pkey_interfaceType

1

ib0

クラスタpkey ID

compute

ib0のクラスタpkey IPアドレス

ib0のクラスタpkeyネットマスク

cluster

2

ib1

クラスタpkey ID

compute

ib1のクラスタpkey IPアドレス

ib1のクラスタpkeyネットマスク

cluster

3

ib0

ストレージpkey ID

compute

ib0のストレージpkey IPアドレス

ib0のストレージpkeyネットマスク

storage

4

ib1

ストレージpkey ID

compute

ib1のストレージpkey IPアドレス

ib1のストレージpkeyネットマスク

storage

次に例を示します。

# ./run_create_pkeys.sh vm-guest-1 ib0 a000 compute 192.168.12.153 /21 cluster

# ./run_create_pkeys.sh vm-guest-1 ib1 a000 compute 192.168.12.154 /21 cluster

# ./run_create_pkeys.sh vm-guest-1 ib0 aa00 compute 192.168.114.15 /20 storage

# ./run_create_pkeys.sh vm-guest-1 ib1 aa00 compute 192.168.114.16 /20 storage

この段階で、OVM RACクラスタ・ノードの新しいpkey対応ネットワーク・インタフェースに対して、次に示す、すべての必要なネットワーク・ファイルが作成されています。

- /etc/sysconfig/network-scripts/ifcfg-clib0

- /etc/sysconfig/network-scripts/ifcfg-clib1

- /etc/sysconfig/network-scripts/ifcfg-stib0

- /etc/sysconfig/network-scripts/ifcfg-stib1

- /etc/sysconfig/network-scripts/rule-clib0

- /etc/sysconfig/network-scripts/rule-clib1

- /etc/sysconfig/network-scripts/rule-stib0

- /etc/sysconfig/network-scripts/rule-stib1

- /etc/sysconfig/network-scripts/route-clib0

- /etc/sysconfig/network-scripts/route-clib1

- /etc/sysconfig/network-scripts/route-stib0

- /etc/sysconfig/network-scripts/route-stib1

グリッド・インフラストラクチャも変更され、再起動時に新しいネットワーク・インタフェースを使用するようになりました。$GI_HOME/bin/oifcfg getifで、cluster_interconnectに使用されるインタフェースのリストにclib0とclib1が表示されます。

4. ASMとRDBMSのcluster_interconnectsパラメータを変更します。

a. SYSとしてsqlplusを使用してRACクラスタの各ASMインスタンスにログインし、次のコマンドを実行します。

alter system set cluster_interconnects='<cluster pkey IP address of ib0>:<cluster pkey IP address of ib1>'
scope=spfile  sid='<name of the current ASM instance>';

次に例を示します。

alter system set cluster_interconnects='192.168.12.153:192.168.12.154'
scope=spfile  sid='<name of the current ASM instance>';

b. sqlplusを使用してRACクラスタの各RDBMSインスタンスにログインし、次のコマンドを実行します。

alter system set cluster_interconnects='<cluster pkey IP address of ib0>:<cluster pkey IP address of ib1>'
scope=spfile  sid='<name of the current RDBMS instance>';

次に例を示します。

alter system set cluster_interconnects='192.168.12.153:192.168.12.154'
scope=spfile  sid='<name of the current RDBMS instance>';

c. すべてのRACクラスタ・ノードでCRS自動起動を停止して無効化します。

# $GI_HOME/bin/crsctl stop crs

# $GI_HOME/bin/crsctl disable crs

この段階で、グリッド・インフラストラクチャ、ASMインスタンスおよびRDBMSインスタンスが、新しく作成したネットワーク・インタフェースを使用するように変更されました。

5. すべてのクラスタ・ノード(ユーザー・ドメイン)のcellip.oraとcellinit.oraを変更します。

a. すべてのRACクラスタ・ノードの/etc/oracle/cell/network-config/cellip.oraを手動で編集して、既存のIPアドレスを、手順6で設定するすべてのストレージ・セルの2つのストレージpkey IPアドレスに置き換えます。;を使用して2つのIPアドレスを区切ります。
次に、/etc/oracle/cell/network-config/cellip.oraファイルの例を示します。

cell="192.168.114.1;192.168.114.2"

cell="192.168.114.3;192.168.114.4"

cell="192.168.114.5;192.168.114.6"

cell="192.168.114.7;192.168.114.8"

cell="192.168.114.9;192.168.114.10"

cell="192.168.114.11;192.168.114.12"

cell="192.168.114.13;192.168.114.14"

この手順の目的を達成するために、次の手順をお薦めします。クラスタのいずれかのデータベース・サーバー・ノード(OVM RACクラスタのユーザー・ドメイン)で、次の手順を実行します。

i. 次のコマンドを実行します。

# cd /etc/oracle/cell/network-config
# cp cellip.ora cellip.ora-bak

ii. cellip.ora-bakを変更します。

iii. rootユーザー用にすべてのクラスタ・ノードからこのクラスタ・ノードへのSSH等価が設定されていることを確認します。

iv. 次のコマンドを実行します。<cluster_nodes>は、OVM RACクラスタのすべてのRACクラスタ・ノードの名前が含まれるファイルで、個々の行で各ノードを示します。

# /usr/local/bin/dcli -g <cluster_nodes> –l root "/bin/cp /etc/oracle/cell/network-config/cellip.ora /etc/oracle/cell/network-config/cellip-orig.ora"

# /usr/local/bin/dcli -g <cluster_nodes> –l root –f cellip.ora-bak –d /etc/oracle/cell/network-config/cellip.ora

b. /etc/oracle/cell/network-config/cellinit.oraを/etc/oracle/cell/network-config/cellinit.ora-bakにバックアップします。

c. /etc/oracle/cell/network-config/cellinit.oraを手動で編集して、既存のIPアドレスおよびネットマスクを、手順3で使用したクラスタ・ノードの2つのストレージpkey IPアドレスおよびネットマスクに置き換えます。このIPアドレスとネットマスクは、手順3の3回目と4回目の実行で使用されています。

6. dom0のすべての関連するvm.cfgファイルを変更します。この手順はOVM環境にのみ適用できます。
すべてのdom0にログインして、手順2で作成したパーティション鍵を含めるように/EXAVMIMAGES/GuestImages/<user domain name>/vm.cfgを手動で編集します。次の例を参照してください。

次の行を変更します。

ib_pkeys = [{'pf':'40:00.0','port':'1','pkey':['0xffff',]},{'pf':'40:00.0','port':'2','pkey':['0xffff',]},]

変更後:

ib_pkeys = [{'pf':'40:00.0','port':'1','pkey':['0xa000','0xaa00',]},{'pf':'40:00.0','port':'2','pkey':['0xa000','0xaa00',]},]

前述の例では、0xa000が手順2で入力したクラスタpkey_id値から導出されたクラスタのパーティション鍵で、0xaa00がストレージpkey_id値から導出されたストレージのパーティション鍵です。

次のコマンドを使用すると、手順2で入力したpkey_idの値から、前述のvm.cfgに入力するパーティション鍵の値を導出できます。

FinalHexValue=$(echo "obase=16;ibase=2;$(expr 1000000000000000 + $(echo "obase=2;ibase=16;$(echo $HexValue|tr [:lower:] [:upper:])"|bc))"|bc|tr [:upper:] [:lower:])

FinalHexValueはvm.cfgに入力される値で、HexValueは手順2で入力したpkey_idの値です。

注意:

環境内に複数のOVM RACクラスタがある場合は、すべてのOVM RACクラスタに対して手順3から6が実行された後で、手順7と手順8を1回のみ実行する必要があります。

7. パーティション鍵を使用するために、ストレージ・セルを構成します。

a. 手順2でrun_create_pkeys.shおよびcreate_pkey_files.shを使用可能にしてあり、かつ、これらが手順2で使用した同じdom0ノードの同じディレクトリに存在することを確認します。

b. 手順2で使用したdom0ノードからの、パーティション鍵に対して構成する必要があるすべてのストレージ・セルへのパスワードなしのSSHが設定されていることを確認します。

c. そのdom0ノードからrun_create_pkeys.shを実行します。ストレージ・セルのこのスクリプトの構文は次のとおりです。

run_create_pkeys.sh <node_name> <interfaceName> <pkey_id> <node_type> <pkey_ipaddr> <pkey_netmask> <pkey_interfaceType>

<node_name>にノード名を指定します。

<interface_name>はib0またはib1のいずれかです。

<pkey_id>に、0xの接頭辞を除いたpkeyを指定します。

<node_type>はcomputeまたはcellのいずれかです。

<pkey_ipaddr>にIPアドレスを指定します。

<pkey_netmask>に、/21などのCIDR形式のネットマスクを指定します。

<pkey_interfaceType>は、computeノード・タイプの場合はclusterまたはstorage、cellノード・タイプの場合はstorageです。

注意:

前述のコマンドの<pkey_id>は、手順2で入力したストレージのpkey_idの値から導出されたストレージのパーティション鍵です。

次のコマンドを使用すると、手順2で入力したpkey_idの値から、前述のコマンドに入力するパーティション鍵の値を導出できます。

FinalHexValue=$(echo "obase=16;ibase=2;$(expr 1000000000000000 + $(echo "obase=2;ibase=16;$(echo $HexValue|tr [:lower:] [:upper:])"|bc))"|bc|tr [:upper:] [:lower:])

FinalHexValueはコマンドに入力される値で、HexValueは手順2で入力したpkey_idの値です。

ストレージ・セルの場合は、次の表に示すように、cellのnode_typeを使用して、それぞれのストレージ・セルに対して2回スクリプトを実行する必要があります。

表2-5 ストレージ・セルに対する2回の実行

実行

インタフェース名

pkey_id

node_type

pkey_ipaddress

pkey_netmask

pkey_interfaceType

1

ib0

ストレージpkey ID

cell

ib0のストレージpkey IPアドレス

ib0のストレージpkeyネットマスク

storage

2

ib1

ストレージpkey ID

cell

ib1のストレージpkey IPアドレス

ib1のストレージpkeyネットマスク

storage

次に例を示します。

# ./run_create_pkeys.sh cell-1 ib0 aa00 cell 192.168.114.1 /20 storage

# ./run_create_pkeys.sh cell-1 ib1 aa00 cell 192.168.114.2 /20 storage

注意:

スクリプトからの次のメッセージは無視できます。手順9のストレージ・セルの再起動でこれらの項目が考慮されます。

Network configuration altered. Please issue the following commands as root to restart the network and open IB stack:

service openibd restart

service network restart

A restart of all services is required to put new network configuration into effect. MS-CELLSRV communication may be hampered until restart.

この段階で、ストレージ・セルが、再起動時に新しいネットワーク・インタフェースを使用するように変更されました。

8. ストレージ・セルの/opt/oracle.cellos/cell.confを変更して、ストレージ・セルを再起動します。

a. /opt/oracle.cellos/cell.confをバックアップします。

# cp /opt/oracle.cellos/cell.conf /opt/oracle.cellos/cell.conf-prepkey

b. /opt/oracle.cellos/cell.confの次の行を変更します。
次の行を変更します。

<Pkeyconfigured>no</Pkeyconfigured>

変更後:

<Pkeyconfigured>yes</Pkeyconfigured>

2つのプライベート・インタフェース、ib0とib1について、次の行を変更します。

<IP_enabled>yes</IP_enabled>

変更後:

<IP_enabled>no</IP_enabled>

c. すべてのOVM RACノードでグリッド・インフラストラクチャが停止していることを確認します。

d. すべてのストレージ・セル・サーバーを再起動します。

e. ストレージ・セルが再度稼働したら、新しいpkey対応ネットワーク・インタフェースが使用中であることを確認します。

# cellcli -e list cell detail | egrep 'interconnect|ipaddress'

これにより、新しいpkey対応インタフェース(stib0およびstib1)が新しいIPアドレスのセットとともに表示されます。

9. クラスタ・ノードを再起動します。

a. 各ユーザー・ドメイン・ノードの対応するdom0にログインします。

b. 次のコマンドを実行します。

# xm shutdown <user domain name>

# xm create /EXAVMIMAGES/GuestImages/<user domain name>/vm.cfg

10. すべてのクラスタ・ノードで、Grid Infrastructureスタックを起動し、完全に稼働していることを確認します。

a. すべてのRACクラスタ・ノードで、Grid Infrastructureスタックを起動し、自動起動を有効化します。

# $GI_HOME/bin/crsctl start crs

# $GI_HOME/bin/crsctl enable crs

b. すべてのノードでグリッド・インフラストラクチャが完全に稼働したら、新しく構成したpkeyインタフェースを使用するようにcluster_interconnectsパラメータが設定されていることを確認します。

SQL> select inst_id, value from gv$parameter where name = 'cluster_interconnects'

c. OCRから、古いクラスタ相互接続インタフェースを削除します。

# $GI_HOME/bin/oifcfg delif –global ib0/<old subnet>

# $GI_HOME/bin/oifcfg delif –global ib1/<old subnet>

2.8.19.3 OVM RACクラスタ間のInfiniBandパーティションの実装: 制限されたメンバーシップの設定

2016年10月の12.1.0.2データベース・バンドル・パッチでセキュリティ拡張機能が導入され、2016年10月の12.1.0.2バンドル・パッチより前に使用されていた完全なメンバーシップのかわりに、制限されたメンバーシップを使用して、データベース・ノードのGUIDをストレージpkeyに割り当てることができます。これは、ストレージpkeyインタフェースを使用するとあるRACクラスタのあるRACノードが別のRACクラスタのRACノードと通信できるセキュリティ上の問題の対策になります。

完全なメンバーシップと制限されたメンバーシップ

InfiniBandパーティションは、相互の通信を許可されるInfiniBandノードのグループを定義します。InfiniBandパーティションで、マスター・サブネット・マネージャによって管理されるカスタムまたは一意のパーティション鍵を定義して、カスタムのパーティション鍵にメンバーを割り当てます。同じパーティション鍵を持つメンバーのみが相互に通信できます。1つのパーティション鍵のメンバーは、別のパーティション鍵を持つメンバーとは、メンバーシップのタイプにかかわらず、通信できません。1つのクラスタのOVM RACクラスタ・ノードには、クラスタウェア通信用の1つのパーティション鍵と、ストレージ・セルとの通信用の別のパーティション鍵が割り当てられます。このように、RACクラスタのノードは、異なるパーティション鍵が割り当てられた別のRACクラスタのノードとは通信できません。このことは、イーサネットの分野のタグ付けされたVLANと概念的に非常に似ています。

パーティション鍵(pkey)は15ビットの整数で、0x1から0x7FFFの値を持ちます。追加のビットであるメンバーシップ・ビットによって、パーティションのメンバーのメンバーシップが識別されます。メンバーシップは次のとおりです。

- 完全: メンバーシップ・ビットは1に設定されます。完全なメンバーシップを持つメンバーは、相互に通信できることに加えて、同じパーティション鍵内の制限されたメンバーシップを持つメンバーと通信できます。

- 制限: メンバーシップ・ビットは0に設定されます。パーティション内の制限されたメンバーシップを持つメンバーは、相互に通信できません。ただし、同じパーティション内の完全なメンバーシップを持つ他のメンバーと通信できます。

pkeyとメンバーシップ・ビットが組み合されて16ビットの整数を構成します。最も重要なビットはメンバーシップ・ビットです。

デフォルトで、InfiniBandサブネット・マネージャは、パーティション鍵0x7FFF (制限されたメンバーシップ)または0xFFFF (完全なメンバーシップ)により識別される単一パーティションを提供します。

HCAポートは、最大で128個のパーティションに参加できます。それぞれのパーティション鍵で新しいIPoIBネットワーク・インタフェースが提供されます。たとえば、パーティション鍵0xa001を持つInfiniBandポート1が新しいネットワーク・インタフェースになります。これらのインタフェースには、ifcfg-<interface>ファイル・パラメータによって意味のある名前が付けられます。

1つのInfiniBandノードを複数のパーティションのメンバーにできます。パケットがデータベース・ノードに到着すると、パケットのパーティション鍵(pkey)がサブネット・マネージャ構成と照合されます。この検証により、データベース・ノードが、それがメンバーになっているパーティションの外部の別のデータベース・ノードと通信できなくなります。

InfiniBandファブリック内のすべてのノードには、/sys/class/infiniband/mlx4_0/ports/[1-2]/pkeysで確認できるパーティション鍵の表があります。ノードのそれぞれのキュー・ペア(QP)には、その表の1つのエントリにマッピングされる索引(pkey)が関連付けられています。QPの送信キューからパケットが送信される場合は、索引付きのpkeyが添付されます。QPの受信キューでパケットを受信した場合は、索引付きのpkeyが受信パケットのものと比較されます。一致しない場合、パケットは警告なしで破棄されます。受信チャネル・アダプタはその到着を認識せず、同様に送信チャネル・アダプタも受信確認を取得しません。送信済パケットは単に失われたパケットとして示されます。受信パケットのpkeyがQPの受信キューの索引付きのpkeyと一致した場合にのみ、ハンドシェイクが行われてパケットが受け入れられ、送信チャネル・アダプタに確認が送信されます。このようにして、同じパーティションのメンバーのみが相互に通信でき、そのパーティションのメンバーではないホスト(つまり、パーティション表にそのpkeyを持たないホスト)とは通信できないようになっています。

次の手順で、2016年10月の12.1.0.2データベース・バンドル・パッチが適用されたpkey対応環境でこの拡張機能を設定する方法について説明します。次で説明するように、考えられるシナリオは2つあります。

ケース1.ローリング形式によるpkey対応環境での機能の実装

このケースでは、すでに2016年10月の12.1.0.2データベース・バンドル・パッチを適用しています。

次の手順を、1回に1つのノードに実行します。

1. ノードでグリッド・インフラストラクチャを停止します。

# $GI_HOME/bin/crsctl stop crs

2. このユーザー・ドメインのOVM RACクラスタ・ノードを管理するdom0 (制御ドメイン)の2つのポートのGUIDを特定します。

# /usr/sbin/ibstat | grep Port

3. SMマスターがrootとして実行されているInfiniBandスイッチにログインします。

4. InfiniBandスイッチで次のコマンドを実行します。

# /usr/local/sbin/smpartition start

# /usr/local/sbin/smpartition modify -n <storage pkey name> -port <Port GUID1 of the dom0 from step 2> -m limited

# /usr/local/sbin/smpartition modify -n <storage pkey name> -port <Port GUID2 of the dom0 from step 2> -m limited

# /usr/local/sbin/smpartition commit

5. dom0のこのOVM RACユーザー・ドメイン・ノードのvm.cfgファイルを変更します。

a. rootとしてdom0にログインします。

b. /EXAVMIMAGES/GuestImages/<user domain name>/vm.cfgを編集して、次の例に示すようにパーティション鍵を変更します。
次の行を変更します。

ib_pkeys = [{'pf':'40:00.0','port':'1','pkey':[ '0xclpkey','0x<stpkey>',]},{'pf':'40:00.0','port':'2','pkey':[ '0xclpkey','0x<stpkey>',]},]

次のように変更します。

ib_pkeys = [{'pf':'40:00.0','port':'1','pkey':[ '0xclpkey','0x<mod_stpkey>',]},{'pf':'40:00.0','port':'2','pkey':[ '0xclpkey','0x<mod_stpkey>',]},]

<mod_stpkey>は、次の式を使用して<stpkey>から導出されます。

mod_stpkey=$(echo "obase=16;ibase=2;$(expr $(echo "obase=2;ibase=16;$(echo $stpkey|tr [:lower:] [:upper:])"|bc) - 1000000000000000)"|bc|tr [:upper:] [:lower:])

前述の式の<stpkey>と<mod_stpkey>は、0xの接頭辞なしで指定されています。

6. ユーザー・ドメインのRACノードの/etc/sysconfig/network-scripts/ifcfg-stib*ファイルを変更します。
次の式を使用して、これらのファイルのPKEY_IDを編集します。

mod_stpkey=$(echo "obase=16;ibase=2;$(expr $(echo "obase=2;ibase=16;$(echo $stpkey|tr [:lower:] [:upper:])"|bc) - 1000000000000000)"|bc|tr [:upper:] [:lower:])

mod_stpkeyが新しいPKEY_IDで、stpkeyが古いPKEY_IDです。

前述の式の<stpkey>と<mod_stpkey>は、0xの接頭辞なしで指定されています。

7. ユーザー・ドメインのRACノードの/opt/oracle.cellos/pkey.confを変更します。
ストレージ・ネットワークpkeyインタフェース(stib*)のPkeyを編集します。

変更前:

<Pkey>0xstpkey</Pkey>

変更後:

<Pkey>0xmod_stpkey</Pkey>

mod_stpkeyは、次の式を使用してstpkeyから導出されます。

mod_stpkey=$(echo "obase=16;ibase=2;$(expr $(echo "obase=2;ibase=16;$(echo $stpkey|tr [:lower:] [:upper:])"|bc) - 1000000000000000)"|bc|tr [:upper:] [:lower:])

前述の式で使用されているstpkeyとmod_stpkeyは、0xの接頭辞なしで指定されています。

8. OVM RACユーザー・ドメイン・ノードを再起動します。

a. rootとしてdom0にログインします。

b. 次のコマンドを実行します。

# xm shutdown <user domain name>

# xm create /EXAVMIMAGES/GuestImages/<user domain name>/vm.cfg

9. クラスタ・ノードでGrid Infrastructureスタックが完全に稼働していることを確認します。

10. 残りのクラスタ・ノードに対して、1回に1つのノードでこの手順を繰り返します。

ケース2.ローリング形式による2016年10月の12.1.0.2データベース・バンドル・パッチの適用中のpkey対応環境での機能の実装

次の手順を、1回に1つのノードに実行します。

1. クラスタ・ノードで2016年10月の12.1.0.2データベース・バンドル・パッチを適用します。

2. パッチが適用されたノードで前述のケース1の手順1から10を繰り返します。

3. 次のクラスタ・ノードに進み、前述の手順1および2を繰り返します。

注意:

dom0のGUIDが制限されたメンバーシップに変換された後、すべての新しいクラスタのデプロイメントには、2016年10月のデータベース・バンドル・パッチが前提条件として含められるようになります。

2.8.20 Oracle EXAchkの実行

Exadataでの仮想化は、Oracle EXAchkバージョン12.1.0.2.2以上でサポートされています。

Oracle Exadata Oracle VM環境でOracle EXAchk監査チェックの完全なセットを実行するには、Oracle EXAchkをインストールして、次のように複数の場所から実行する必要があります。

- 1つの管理ドメイン(dom0)から

- Oracle VM Oracle RACクラスタごとに1つのユーザー・ドメイン(domU)から

たとえば、4つのOracle VM Oracle RACクラスタを含む2つのデータベース・サーバー(両方のデータベース・サーバーで合計8つのdomU、クラスタごとに2つのノード)を使用したOracle Exadata Database Machineクオータ・ラックでは、次のようにOracle EXAchkを5回実行する必要があります。

1. クラスタ#1の最初のユーザー・ドメイン(domU)でOracle EXAchkを実行します。

2. クラスタ#2の最初のユーザー・ドメイン(domU)でOracle EXAchkを実行します。

3. クラスタ#3の最初のユーザー・ドメイン(domU)でOracle EXAchkを実行します。

4. クラスタ#4の最初のユーザー・ドメイン(domU)でOracle EXAchkを実行します。

5. 最初の管理ドメイン(dom0)でOracle EXAchkを実行します。

Oracle EXAchkによって実行される監査チェックは、次の表に指定されています。

表2-6 Oracle EXAchkによって実行される監査チェック

Oracle EXAchkのインストールおよび実行先

実行される監査チェック

管理ドメイン(dom0)

ハードウェアおよびオペレーティング・システム・レベルのチェック対象:

- データベース・サーバー(管理ドメイン)

- ストレージ・サーバー

- InfiniBandファブリック

- InfiniBandスイッチ

ユーザー・ドメイン(domU)

ユーザー・ドメインのオペレーティング・システム・レベル・チェックおよびOracle Grid InfrastructureおよびOracle Databaseのチェック

Oracle EXAchkコマンドラインのオプション

Oracle EXAchkには、専用のコマンドライン・オプションが不要です。Oracle Exadata Oracle VM環境で実行されていること、および管理ドメインまたはユーザー・ドメインで実行されているかどうかを自動的に検出し、適用可能な監査チェックを実行します。たとえば、最も簡単なケースとして、コマンドライン・オプションなしでOracle EXAchkを実行できます。

./exachk

Oracle EXAchkが管理ドメインで実行されると、すべてのデータベース・サーバー、ストレージ・サーバー、およびInfiniBandネットワーク経由でアクセス可能なInfiniBandスイッチで監査チェックを実行します。

サーバーまたはスイッチのサブセットでOracle EXAchkを実行するには、次のコマンドライン・オプションを使用します。

表2-7 Oracle EXAchkのコマンドライン・オプション

オプション

説明

-clusternodes

データベース・サーバーのカンマ区切りリストを指定します。

-cells

ストレージ・サーバーのカンマ区切りリストを指定します。

-ibswitches

InfiniBandスイッチのカンマ区切りリストを指定します。

たとえば、最初のクオータ・ラックのみが仮想化用に構成されているが、InfiniBandネットワーク経由ですべてのコンポーネントにアクセス可能なOracle Exadata Database Machineのフル・ラックの場合、データベース・サーバーdm01adm01から次のようなコマンドを実行できます。

./exachk -clusternodes dm01adm01,dm01adm02
-cells dm01celadm01,dm01celadm02,dm01celadm03
-ibswitches dm01swibs0,dm01sw-iba0,dm01sw-ibb0

関連トピック

- Oracle ORAchkおよびEXAchkユーザーズ・ガイド

2.9 LVMパーティションの拡張

この項では、データベース・サーバー内の論理ボリューム・マネージャ(LVM)パーティションについて説明します。LVMにはパーティションを再編成する柔軟性があります。

注意:

ソフトウェア保守の際にdbnodeupdate.shユーティリティで作成されるLVMスナップショットのために、VGExaDbボリューム・グループ内に、少なくとも1GBの空き領域が必要です。「Oracle Linuxデータベース・サーバーのスナップショット・ベースのバックアップの作成」の手順に従い、/ (root)および/u01ディレクトリのバックアップをスナップショット・ベースで作成する場合、VGExaDbボリューム・グループに少なくとも6GBの空き領域が必要です。

この項では、次の項目について説明します。

- ルートLVMパーティションの拡張

- ルート以外のLVMパーティションのサイズ変更

- スワップ・パーティションの拡張

2.9.1 ルートLVMパーティションの拡張

ルートLVMパーティションを拡張する手順は、Oracle Exadata Storage Server Softwareのリリースにより異なります。次の各項では、手順をリリースごとに説明します。

- Oracle Exadata Storage Server Softwareリリース11.2.3.2.1以上を実行するシステムでの、ルートLVMパーティションの拡張

- Oracle Exadata Storage Server Softwareリリース11.2.3.2.1より前のリリースを実行するシステムでの、ルートLVMパーティションの拡張

2.9.1.1 Oracle Exadata Storage Server Softwareリリース11.2.3.2.1以上を実行するシステムでの、ルートLVMパーティションの拡張

次の手順では、Oracle Exadata Storage Server Softwareリリース11.2.3.2.1以上を実行するシステム上で、ルート(/)パーティションのサイズを拡大する方法について説明します。

注意:

この手順では、サーバーを停止する必要はありません。

dom0システムの場合、アクティブのSys LVMと非アクティブのSys LVMは、LVDbSys1とLVDbSys2ではなく、LVDbSys2とLVDbSys3です。

LVDbSys1およびLVDbSys2のサイズが同じに設定されていることを確認します。

1. 次のように、現在の環境に関する情報を収集します。

a. 次のように、dfコマンドを使用して、rootパーティション(/)内の空き領域および使用済領域の容量を確認します。

# df -h /

次に、コマンドの出力例を示します。

Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VGExaDb-LVDbSys1
30G  22G  6.2G  79% /

注意:

アクティブなrootパーティションは、それ以前の保守アクティビティによりLVDbSys1またはLVDbSys2のいずれかに決定されます。

b. lvsコマンドを使用して、現在のボリューム構成を表示します。

# lvs -o lv_name,lv_path,vg_name,lv_size

次に、コマンドの出力例を示します。

LV                 Path                            VG       LSize
LVDbOra1           /dev/VGExaDb/LVDbOra1           VGExaDb  100.00g
LVDbSwap1          /dev/VGExaDb/LVDbSwap1          VGExaDb  24.00g
LVDbSys1           /dev/VGExaDb/LVDbSys1           VGExaDb  30.00g
LVDbSys2           /dev/VGExaDb/LVDbSys2           VGExaDb  30.00g
LVDoNotRemoveOrUse /dev/VGExaDb/LVDoNotRemoveOrUse VGExaDb  1.00g

2. tune2fsコマンドを使用して、オンラインのサイズ変更オプションを確認します。

tune2fs -l /dev/mapper/vg_name-lv_name | grep resize_inode

次に例を示します。

tune2fs -l /dev/mapper/VGExaDb-LVDbSys1 | grep resize_inode

resize_inodeオプションが、コマンド出力に表示されます。オプションが表示されない場合、パーティションのサイズ変更の操作をする以前に、ファイル・システムがアンマウントしています。「Oracle Exadata Storage Server Softwareリリース11.2.3.2.1より前のリリースを実行するシステムでの、ルートLVMパーティションの拡張」を参照して、パーティションのサイズを変更してください。

3. ボリューム・グループVGExaDbの使用可能な領域を確認するには、次のように、vgdisplayコマンドを使用します。

# vgdisplay -s

次に、コマンドの出力例を示します。

"VGExaDb" 834.89 GB [184.00 GB used / 650.89 GB free]

ボリューム・グループは、二つのシステム・パーティションのサイズを増やすことができる空き領域を持ち、アップグレードの際にdbnodeupdate.shユーティリティで作成されるLVMスナップショットで使用するために、少なくとも1GBの空き領域を維持する必要があります。

十分な空き領域がない場合、reclaimdisks.shユーティリティが実行中であるかどうか確認してください。ユーティリティが実行されていない場合、次のコマンドを実行して、ディスク領域をリクレイムします。

# /opt/oracle.SupportTools/reclaimdisks.sh -free -reclaim

ユーティリティが実行中で、十分な空き領域がない場合、LVMはサイズ変更できません。

注意:

reclaimdisks.shは、RAID再構築(ディスクの置換えまたは拡張)と同時に実行できません。RAID再構築が完了するまで待機してから、reclaimdisks.shを実行してください。

4. LVDbSys1およびLVDbSys2論理ボリュームのサイズを変更するには、次のように、lvextendコマンドを使用します。

# lvextend -L +XG --verbose /dev/VGExaDb/LVDbSys1
# lvextend -L +XG --verbose /dev/VGExaDb/LVDbSys2

前述のコマンドのXGは、拡大される論理ボリュームの量(GB)です。いずれのシステム・パーティションにも、等しい容量の領域を追加します。

次の例では、拡大する論理ボリュームは10GBです。

# lvextend -L +10G /dev/VGExaDb/LVDbSys1
# lvextend -L +10G /dev/VGExaDb/LVDbSys2

5. 論理ボリューム内のファイル・システムのサイズを変更するには、次のように、resize2fsコマンドを使用します。

# resize2fs /dev/VGExaDb/LVDbSys1
# resize2fs /dev/VGExaDb/LVDbSys2

6. dfコマンドを使用して、アクティブなシステム・パーティションで領域が拡大されたことを確認します。

# df -h /

2.9.1.2 Oracle Exadata Storage Server Softwareリリース11.2.3.2.1より前のリリースを実行するシステムでの、ルートLVMパーティションの拡張

次の手順では、Oracle Exadata Storage Server Softwareリリース11.2.3.2.1より前のリリースを実行するシステム上で、ルート(/)パーティションのサイズを拡大する方法について説明します。

注意:

この手順では、システムをオフラインにしてから再起動する必要があります。

ソフトウェア保守の際にdbnodeupdate.shユーティリティで作成されるLVMスナップショットのために、VGExaDbボリューム・グループ内に、少なくとも1GBの空き領域が必要です。「Oracle Linuxデータベース・サーバーのスナップショット・ベースのバックアップの作成」の手順に従い、/ (root)および/u01ディレクトリのバックアップをスナップショット・ベースで作成する場合、VGExaDbボリューム・グループに少なくとも6GBの空き領域が必要です。

dom0システムの場合、アクティブのSys LVMと非アクティブのSys LVMは、LVDbSys1とLVDbSys2ではなく、LVDbSys2とLVDbSys3です。

LVDbSys1およびLVDbSys2のサイズが同じに設定されていることを確認します。

1. 次のように、現在の環境に関する情報を収集します。

a. dfコマンドを使用して、ルート・パーティション(/)およびルート以外のパーティション(/u01)のマウント・ポイント、およびそれぞれのLVMを確認します。次に、コマンドの出力例を示します。

# df
Filesystem                    1K-blocks   Used    Available Use% Mounted on
/dev/mapper/VGExaDb-LVDbSys1 30963708   21867152   7523692  75%    /
/dev/sda1                      126427      16355    103648  14%    /boot
/dev/mapper/VGExaDb-LVDbOra1 103212320  67404336  30565104  69%    /u01
tmpfs                         84132864   3294608  80838256   4%    /dev/shm

dfコマンド出力のファイル・システム名は次のような形式になります。

/dev/mapper/VolumeGroup-LogicalVolune

前述の例のルート・ファイル・システムの完全論理ボリューム名は/dev/VGExaDb/LVDbSys1になります。

b. 次のように、lvscanコマンドを使用して、論理ボリュームを表示します。

#lvm lvscan

ACTIVE            '/dev/VGExaDb/LVDbSys1'  [30.00 GB]  inherit
ACTIVE            '/dev/VGExaDb/LVDbSwap1' [24.00 GB]  inherit
ACTIVE            '/dev/VGExaDb/LVDbOra1'  [100.00 GB] inherit

c. lvdisplayコマンドを使用して、現在の論理ボリュームおよびボリューム・グループ構成を表示します。

#lvm lvdisplay /dev/VGExaDb/LVDbSys1

--- Logical volume ---
LV Name               /dev/VGExaDb/LVDbSys1
VG Name               VGExaDb
LV UUID               GScpD7-lKa8-gLg9-oBo2-uWaM-ZZ4W-Keazih
LV Write Access       read/write
LV Status             available
# open                1
LV Size               30.00 GB
Current LE            7680
Segments              1
Allocation            inherit
Read ahead sectors    auto
- currently set to    256
Block device          253:0

d. 論理ボリュームを拡大できるように、ボリューム・グループVGExaDbに使用可能な領域があることを確認します。コマンドで空き領域がゼロと表示された場合は、論理ボリュームまたはファイル・システムは拡大できません。

# lvm vgdisplay VGExaDb -s
"VGExaDb" 556.80 GB [154.00 GB used / 402.80 GB free]

2. 次のように、システムを診断モードで再起動します。

a. ILOMインタフェースを使用して、/opt/oracle.SupportTools/diagnostics.isoファイルをマシンのディレクトリにコピーします。

b. ILOM Webインタフェースにログインします。

c. リモート制御タブを選択します。

d. リダイレクトタブを選択します。

e. リモート・コンソールの起動をクリックします。ILOMリモート・コンソールウィンドウが表示されます。

f. ILOMリモート・コンソールウィンドウで、「デバイス」メニューを選択します。

g. CD-ROMイメージをクリックします。

h. ファイルのオープンダイアログ・ボックスで、ローカル・マシンのdiagnostics.isoファイルの場所に移動します。

i. diagnostics.isoファイルを選択します。

j. 「開く」をクリックします。次のようなメッセージがコンソールに表示されます。

k. リモート制御タブからホスト制御を選択します。

l. 次の起動デバイスとしてCDROMを値リストから選択します。

m. 「保存」をクリックします。システムがブートすると、diagnostics.isoイメージが使用されます。システムは次の再起動後にデフォルトに戻ります。

n. ILOMリモート・コンソールウィンドウで、rootユーザーとしてログインします。

o. 次のコマンドを使用して、サーバーを再起動します。

# shutdown -r now

システムはdiagnostics.isoイメージを使用し始めます。

3. 次のように、eを入力して、診断シェルに入ります。

Choose from following by typing letter in '()':
(e)nter interactive diagnostics shell. Must use credentials from Oracle
support to login (reboot or power cycle to exit the shell),
(r)estore system from NFS backup archive,
Select:e

4. rootユーザーとしてシステムにログインします。パスワードを要求されます。

localhost login: root
Password: *********
-sh-3.1#

5. 次のコマンドを使用して、rootファイル・システムをアンマウントします。

# cd /
# umount /mnt/cell

6. 次のコマンドを使用して、論理ボリューム名を確認します。

# lvm lvscan
ACTIVE '/dev/VGExaDb/LVDbSys1' [30.00 GB] inherit
ACTIVE '/dev/VGExaDb/LVDbSwap1' [24.00 GB] inherit
ACTIVE '/dev/VGExaDb/LVDbOra1' [100.00 GB] inherit

7. 次のコマンドを使用して、現在のルート・ファイル・システムとバックアップ・ルート・ファイル・システムを保持するLVDbSys1とLVDbSys2のサイズを変更します。

# lvm lvextend -L+XG --verbose /dev/VGExaDb/LVDbSys1
# lvm lvextend -L+XG --verbose /dev/VGExaDb/LVDbSys2

前述のコマンドのXGは、拡大される論理ボリュームの量(GB)です。たとえば、論理ボリュームを5 GB拡大する場合、コマンドは次のようになります。

# lvm lvextend -L+5G --verbose /dev/VGExaDb/LVDbSys1
# lvm lvextend -L+5G --verbose /dev/VGExaDb/LVDbSys2

8. fsck.ext3またはfsck.ext4を使用して、ファイル・システムが有効であることを確認します。使用するコマンドはファイル・システムのタイプによって異なります。

# fsck.ext3 -f /dev/VGExaDb/LVDbSys1
# fsck.ext3 -f /dev/VGExaDb/LVDbSys2

または

# fsck.ext4 -f /dev/VGExaDb/LVDbSys1
# fsck.ext4 -f /dev/VGExaDb/LVDbSys2

9. 次のコマンドを使用して、ファイル・システムのサイズを変更します。

# resize2fs -p /dev/VGExaDb/LVDbSys1
# resize2fs -p /dev/VGExaDb/LVDbSys2

10. システムを通常のモードで再起動します。

# reboot

11. システムにログインします。

12. ルート・ファイル・システム・マウントが新しいサイズで問題なくマウントされていることを確認します。

2.9.2 ルート以外のLVMパーティションのサイズ変更

ルート以外のLVMパーティションのサイズを変更する手順は、Oracle Exadata Storage Server Softwareのリリースにより異なります。次の各項では、手順をリリースごとに説明します。

- Oracle Exadata Storage Server Softwareリリース11.2.3.2.1以上を実行するシステムでの、非ルートLVMパーティションの拡張

- Oracle Exadata Storage Server Softwareリリース11.2.3.2.1より前のリリースを実行するシステムでの、非ルートLVMパーティションの拡張

- Oracle Exadata Storage Server Softwareリリース11.2.3.2.1以上を実行するシステムでの、非ルートLVMパーティションの縮小

2.9.2.1 Oracle Exadata Storage Server Softwareリリース11.2.3.2.1以上を実行するシステムでの、非ルートLVMパーティションの拡張

この手順では、Oracle Exadata Storage Server Softwareリリース11.2.3.2.1以降を実行するシステム上で、非ルート(/u01)パーティションのサイズを拡大する方法について説明します。

この手順では、サーバーを停止する必要はありません。

1. 現在の環境に関する情報を収集します。

a. dfコマンドを使用して、/u01パーティションの空き領域および使用済領域の容量を確認します。

# df -h /u01

次に、コマンドの出力例を示します。

Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VGExaDb-LVDbOra1
99G   25G  70G   26% /u01

b. lvsコマンドを使用して、/u01ファイル・システムで使用される現在の論理ボリューム構成を表示します。

# lvs -o lv_name,lv_path,vg_name,lv_size

次に、コマンドの出力例を示します。

LV        Path                   VG      LSize
LVDbOra1  /dev/VGExaDb/LVDbOra1  VGExaDb 100.00G
LVDbSwap1 /dev/VGExaDb/LVDbSwap1 VGExaDb  24.00G
LVDbSys1  /dev/VGExaDb/LVDbSys1  VGExaDb  30.00G
LVDbSys2  /dev/VGExaDb/LVDbSys2  VGExaDb  30.00G

2. tune2fsコマンドを使用して、オンラインのサイズ変更オプションを確認します。

tune2fs -l /dev/mapper/vg_name | grep resize_inode

resize_inodeオプションが、コマンド出力に表示されます。オプションが表示されない場合、パーティションのサイズ変更の操作をする以前に、ファイル・システムがアンマウントしています。「Oracle Exadata Storage Server Softwareリリース11.2.3.2.1より前のリリースを実行するシステムでの、非ルートLVMパーティションの拡張」を参照して、パーティションのサイズを変更してください。

3. ボリューム・グループVGExaDbの使用可能な領域を確認するには、vgdisplayコマンドを使用します。

# vgdisplay -s

次に、コマンドの出力例を示します。

"VGExaDb" 834.89 GB [184.00 GB used / 650.89 GB free]

コマンドの出力で空き領域が1GB未満と表示された場合は、論理ボリュームもファイル・システムも拡大できません。アップグレードの際にdbnodeupdate.shユーティリティで作成されるLVMスナップショットのために、VGExaDbボリューム・グループ内に、少なくとも1GBの空き領域が必要です。

十分な空き領域がない場合、reclaimdisks.shユーティリティが実行中であるかどうか確認してください。ユーティリティが実行されていない場合、次のコマンドを実行して、ディスク領域をリクレイムします。

# /opt/oracle.SupportTools/reclaimdisks.sh -free -reclaim

ユーティリティが実行中で、十分な空き領域がない場合、LVMはサイズ変更できません。

注意:

- reclaimdisks.shは、RAID再構築(ディスクの置換えまたは拡張)と同時に実行できません。RAID再構築が完了するまで待機してから、reclaimdisks.shを実行してください。

4. 論理ボリュームのサイズを変更するには、lvextendコマンドを使用します。

# lvextend -L +sizeG /dev/VGExaDb/LVDbOra1

前述のコマンドで、sizeは論理ボリュームに追加する領域の容量です。

次の例では、拡大する論理ボリュームは10GBです。

# lvextend -L +10G /dev/VGExaDb/LVDbOra1

5. 論理ボリューム内のファイル・システムのサイズを変更するには、resize2fsコマンドを使用します。

# resize2fs /dev/VGExaDb/LVDbOra1

6. dfコマンドを使用して、領域が拡張されたことを確認します

# df -h /u01

2.9.2.2 Oracle Exadata Storage Server Softwareリリース11.2.3.2.1より前のリリースを実行するシステムでの、非ルートLVMパーティションの拡張

この手順では、Oracle Exadata Storage Server Softwareリリース11.2.3.2.1より前のリリースを実行するシステム上で、非ルート(/u01)パーティションのサイズを拡大する方法について説明します。

ここでは、/dev/VGExaDb/LVDbOra1が/u01でマウントされます。

注意:

ソフトウェア保守の際にdbnodeupdate.shユーティリティで作成されるLVMスナップショットのために、VGExaDbボリューム・グループ内に、少なくとも1GBの空き領域が必要です。「Oracle Linuxデータベース・サーバーのスナップショット・ベースのバックアップの作成」の手順に従い、/ (root)および/u01ディレクトリのバックアップをスナップショット・ベースで作成する場合、VGExaDbボリューム・グループに少なくとも6GBの空き領域が必要です。

1. 現在の環境に関する情報を収集します。

a. dfコマンドを使用して、ルート・パーティション(/)およびルート以外のパーティション(/u01)のマウント・ポイント、およびそれぞれのLVMを確認します。

# df
Filesystem                    1K-blocks   Used    Available Use% Mounted on
/dev/mapper/VGExaDb-LVDbSys1 30963708   21867152   7523692  75%    /
/dev/sda1                      126427      16355    103648  14%    /boot
/dev/mapper/VGExaDb-LVDbOra1 103212320  67404336  30565104  69%    /u01
tmpfs                         84132864   3294608  80838256   4%    /dev/shm

b. lvm lvscanコマンドを使用して、論理ボリュームを表示します。

ACTIVE            '/dev/VGExaDb/LVDbSys1'  [30.00 GB]  inherit
ACTIVE            '/dev/VGExaDb/LVDbSwap1' [24.00 GB]  inherit
ACTIVE            '/dev/VGExaDb/LVDbOra1'  [100.00 GB] inherit

c. lvdisplayコマンドを使用して、現在のボリューム・グループ構成を表示します。

# lvdisplay /dev/VGExaDb/LVDbOra1

--- Logical volume ---
LV Name               /dev/VGExaDb/LVDbOra1
VG Name               VGExaDb
LV UUID               vzoIE6-uZrX-10Du-UD78-314Y-WXmz-f7SXyY
LV Write Access       read/write
LV Status             available
# open                1
LV Size               100.00 GB
Current LE            25600
Segments              1
Allocation            inherit
Read ahead sectors    auto
- currently set to    256
Block device          253:2

d. 論理ドライブを拡大できるように、ボリューム・グループVGExaDbに使用可能な領域があることを確認します。

コマンドで空き領域がゼロと表示された場合は、論理ボリュームもファイル・システムも拡大できません。

# lvm vgdisplay VGExaDb -s

"VGExaDb" 556.80 GB [154.00 GB used / 402.80 GB free]

2. /u01を使用するソフトウェアを停止します。

次のソフトウェアは、通常/u01を使用します。

- Oracle ClusterwareおよびOracle Database

# Grid_home/bin/crsctl stop crs

- トレース・ファイル・アナライザ

# Grid_home/bin/tfactl stop

- OS Watcher (リリース11.2.3.3.0より前のリリース)

# /opt/oracle.oswatcher/osw/stopOSW.sh

- ExaWatcher (リリース11.2.3.3.0以上)

# /opt/oracle.ExaWatcher/ExaWatcher.sh --stop

- Oracle Enterprise Managerエージェント

(oracle)$ agent_home/bin/emctl stop agent

3. rootユーザーとしてパーティションをアンマウントします。

# umount /u01

注意:

umountコマンドでファイル・システムがビジーとレポートされた場合、umountコマンドが成功するには、fuser(1)コマンドを使用して、停止する必要があるが、ファイル・システムにまだアクセスしているプロセスを特定します。

# umount /u01
umount: /u01: device is busy
umount: /u01: device is busy

# fuser -mv /u01

USER      PID ACCESS COMMAND
/u01:   root     6788 ..c..  ssh
root     8422 ..c..  bash
root    11444 ..c..  su
oracle  11445 ..c..  bash
oracle  11816 ....m  mgr
root    16451 ..c..  bash

4. ファイル・システムを確認します。

# e2fsck -f /dev/VGExaDb/LVDbOra1

5. パーティションを拡張します。

この例では、論理ボリュームが物理ボリュームのサイズの80%まで拡大されています。同時に、ファイル・システムがコマンドによってサイズ変更されます。

# lvextend -L+XG --verbose /dev/VGExaDb/LVDbOra1

前述のコマンドのXGは、拡大される論理ボリュームの量(GB)です。次の例は、論理ボリュームを200GB追加して拡大する方法を示しています。

# lvextend -L+200G --verbose /dev/VGExaDb/LVDbOra1

注意:

サイズを縮小する場合は、十分に注意してください。新しいサイズは、パーティションの元の内容すべてを収容できる十分な大きさにする必要があります。サイズを縮小するには、次のようなコマンドを使用します。

lvreduce -L60G --resizefs --verbose /dev/VGExaDb/LVDbOra1

前述のコマンドでは、/u01のサイズが60GBに縮小されています。

6. e2fsckコマンドを使用して、/u01ファイル・システムを確認します。

# e2fsck -f /dev/VGExaDb/LVDbOra1

7. /u01ファイル・システムのサイズを変更します。

# resize2fs -p /dev/VGExaDb/LVDbOra1

8. パーティションをマウントします。

# mount -t ext3 /dev/VGExaDb/LVDbOra1 /u01

9. 領域が拡張されたことを確認します。

$ df -h /u01

10. 次のように、手順2で停止したソフトウェアを再起動します。

- Oracle ClusterwareおよびOracle Database

# Grid_home/bin/crsctl start crs

- トレース・ファイル・アナライザ

# Grid_home/bin/tfactl start

- OS Watcher (リリース11.2.3.3.0より前のリリース)

# /opt/oracle.cellos/vldrun -script oswatcher

- ExaWatcher (リリース11.2.3.3.0以上)

# /opt/oracle.ExaWatcher/ExaWatcher.sh

- Oracle Enterprise Managerエージェント

(oracle)$ agent_home/bin/emctl start agent

関連トピック

- Oracle Linuxデータベース・サーバーのスナップショット・ベースのバックアップの作成 - パーティションをカスタマイズしている場合

2.9.2.3 Oracle Exadata Storage Server Softwareリリース11.2.3.2.1以上を実行するシステムでの、非ルートLVMパーティションの縮小

次の手順では、Oracle Exadata Storage Server Softwareリリース11.2.3.2.1以上を実行するシステム上で、非ルート(/u01)パーティションのサイズを縮小する方法について説明します。

注意:

この手順では、サーバーを停止する必要はありません。手順を実行する前に、ファイル・システムをバックアップすることをお薦めします。

1. dfコマンドを使用して、/u01パーティションの空き領域および使用済領域の容量を確認します。

# df -h /u01

出力例:

Filesystem                    Size  Used Avail Use% Mounted on
/dev/mapper/VGExaDb-LVDbOra1  193G   25G  159G  14% /u01

2. lvmコマンドを使用して、/u01ファイル・システムで使用される現在の論理ボリューム構成を表示します。

# lvm vgdisplay VGExaDb -s
"VGExaDb" 271.82 GB [250.04 GB used / 21.79 GB free]

# lvm lvscan
ACTIVE            '/dev/VGExaDb/LVDbSys1' [30.00 GB] inherit
ACTIVE            '/dev/VGExaDb/LVDbSwap1' [24.00 GB] inherit
ACTIVE            '/dev/VGExaDb/LVDbOra1' [196.04 GB] inherit

この場合、LVDbSys2 (サイズは30.00 GB)をdbserver_backup.shスクリプトで作成できるように、LVDbOra1パーティションのサイズを縮小する必要があります。

3. /u01を使用するソフトウェアを停止します。次のソフトウェアは、通常/u01を使用します。

- Oracle ClusterwareおよびOracle Database

# GI_HOME/bin/crsctl stop crs

- トレース・ファイル・アナライザ

# GI_HOME/bin/tfactl stop

- OS Watcher (11.2.3.3.0より前のリリース)

# /opt/oracle.oswatcher/osw/stopOSW.sh

- ExaWatcher (リリース11.2.3.3.0以上)

# /opt/oracle.ExaWatcher/ExaWatcher.sh --stop

- Oracle Enterprise Managerエージェント

(oracle)$ agent_home/bin/emctl stop agent

4. rootユーザーとしてパーティションをアンマウントします。

# umount /u01

注意:

umountコマンドでファイル・システムがビジーとレポートされた場合、umountコマンドを正常に実行するには、fuser(1)コマンドを使用して、停止する必要があるファイル・システムにまだアクセスしているプロセスを特定します。

# umount /u01
umount: /u01: device is busy
umount: /u01: device is busy

# fuser -mv /u01

USER      PID ACCESS COMMAND
/u01:   root     6788 ..c..  ssh
root     8422 ..c..  bash
root    11444 ..c..  su
oracle  11445 ..c..  bash
oracle  11816 ....m  mgr
root    16451 ..c..  bash

5. ファイル・システムを確認します。

# e2fsck -f /dev/VGExaDb/LVDbOra1

fsck 1.39 (29-May-2006)
e2fsck 1.39 (29-May-2006)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
DBORA: 72831/25706496 files (2.1% non-contiguous), 7152946/51389440 blocks

6. 必要なサイズ(次の例では120G)までファイル・システムのサイズを縮小します。

# resize2fs /dev/VGExaDb/LVDbOra1 120G
resize2fs 1.39 (29-May-2006)
Resizing the filesystem on /dev/VGExaDb/LVDbOra1 to 26214400 (4k) blocks.
The filesystem on /dev/VGExaDb/LVDbOra1 is now 26214400 blocks long.

7. 目的のサイズまでLVMのサイズを縮小します。

# lvm lvreduce -L 120G --verbose /dev/VGExaDb/LVDbOra1
Finding volume group VGExaDb
WARNING: Reducing active logical volume to 120.00 GB
THIS MAY DESTROY YOUR DATA (filesystem etc.)
Do you really want to reduce LVDbOra1? [y/n]: y
Archiving volume group "VGExaDb" metadata (seqno 8).
Reducing logical volume LVDbOra1 to 120.00 GB
Found volume group "VGExaDb"
Found volume group "VGExaDb"
Loading VGExaDb-LVDbOra1 table (253:2)
Suspending VGExaDb-LVDbOra1 (253:2) with device flush
Found volume group "VGExaDb"
Resuming VGExaDb-LVDbOra1 (253:2)
Creating volume group backup "/etc/lvm/backup/VGExaDb" (seqno 9).
Logical volume LVDbOra1 successfully resized

8. 次のコマンドを使用して、パーティションをマウントします。

# mount -t ext3 /dev/VGExaDb/LVDbOra1 /u01

9. 次のコマンドを使用して、領域が縮小されていることを確認します。

# df -h /u01
Filesystem                    Size  Used Avail Use% Mounted on
/dev/mapper/VGExaDb-LVDbOra1  119G   25G   88G  22% /u01

# lvm vgdisplay -s
"VGExaDb" 271.82 GB [174.00 GB used / 97.82 GB free]

10. 次のように、手順3で停止したソフトウェアを再起動します。

- Oracle ClusterwareおよびOracle Database

# GI_HOME/bin/crsctl start crs

- トレース・ファイル・アナライザ

# GI_HOME/bin/tfactl start

- OS Watcher (11.2.3.3.0より前のリリース)

# /opt/oracle.cellos/vldrun -script oswatcher

- ExaWatcher (リリース11.2.3.3.0以上)

# /opt/oracle.cellos/vldrun -script oswatcher

- Oracle Enterprise Managerエージェント

(oracle)$ agent_home/bin/emctl start agent

2.9.3 スワップ・パーティションの拡張

この手順では、スワップ(/swap)パーティションのサイズを拡大する方法について説明します。

注意:

この手順では、システムをオフラインにしてから再起動する必要があります。

ソフトウェア保守の際にdbnodeupdate.shユーティリティで作成されるLogical Volume Manager (LVM)スナップショットのために、VGExaDbボリューム・グループ内に、少なくとも1GBの空き領域が必要です。「Oracle Linuxデータベース・サーバーのスナップショット・ベースのバックアップの作成」の手順に従い、/ (root)および/u01ディレクトリのバックアップをスナップショット・ベースで作成する場合、VGExaDbボリューム・グループに少なくとも6GBの空き領域が必要です。

1. 現在の環境に関する情報を収集します。

a. swaponコマンドを使用して、スワップ・パーティションを確認します。

# swapon -s
Filename    Type        Size       Used   Priority
/dev/dm-2   partition   25165816   0      -1

b. lvm lvscanコマンドを使用して、論理ボリュームを表示します。

# lvm lvscan
ACTIVE '/dev/VGExaDb/LVDbSys1' [30.00 GiB] inherit
ACTIVE '/dev/VGExaDb/LVDbSys2' [30.00 GiB] inherit
ACTIVE '/dev/VGExaDb/LVDbSwap1' [24.00 GiB] inherit
ACTIVE '/dev/VGExaDb/LVDbOra1' [103.00 GiB] inherit
ACTIVE '/dev/VGExaDb/LVDoNotRemoveOrUse' [1.00 GiB] inherit

c. vgdisplayコマンドを使用して、現在のボリューム・グループ構成を表示します。

# vgdisplay
--- Volume group ---
VG Name               VGExaDb
System ID
Format                lvm2
Metadata Areas        1
Metadata Sequence No  4
VG Access             read/write
VG Status             resizable
MAX LV                0
Cur LV                3
Open LV               3
Max PV                0
Cur PV                1
Act PV                1
VG Size               556.80 GB
PE Size               4.00 MB
Total PE              142541
Alloc PE / Size       39424 / 154.00 GB
Free  PE / Size       103117 / 402.80 GB
VG UUID               po3xVH-9prk-ftEI-vijh-giTy-5chm-Av0fBu

d. pvdisplayコマンドを使用して、LVMで作成され、オペレーティング・システムで使用される物理デバイスの名前を表示します。

# pvdisplay
--- Physical volume ---
PV Name               /dev/sda2
VG Name               VGExaDb
PV Size               556.80 GB / not usable 2.30 MB
Allocatable           yes
PE Size (KByte)       4096
Total PE              142541
Free PE               103117
Allocated PE          39424
PV UUID               Eq0e7e-p1fS-FyGN-zrvj-0Oqd-oUSb-55x2TX

2. x86マシンの場合: 正常なデータベース・サーバーにある/opt/oracle.SupportTools/diagnostics.isoファイルをリストア対象のデータベース・サーバーのILOMに仮想メディアとして接続します。

次に、ILOMインタフェースを使用した仮想CD-ROMの設定方法の例を示します。

a. ILOMインタフェースを使用して、/opt/oracle.SupportTools/diagnostics.isoファイルをマシンのディレクトリにコピーします。

b. ILOM Webインタフェースにログインします。

c. リモート制御タブからリモート・コンソールを選択します。これにより、コンソールが起動します。

d. 「デバイス」メニューを選択します。

e. CD-ROMイメージオプションを選択します。

f. diagnostics.isoファイルの場所に移動します。

g. diagnostics.isoファイルを開きます。

h. リモート制御タブからホスト制御を選択します。

i. 次の起動デバイスとしてCDROMを値リストから選択します。

j. 「保存」をクリックします。

3. サーバーを診断モードで再起動します。

4. ファイル・システムが有効であることを確認します。

以下のコマンドを使用します。

#fsck -f /dev/VGExaDb/LVDbSwap1

5. パーティションを拡張します。

この例では、論理ボリュームが物理ボリュームのサイズの80%まで拡大されています。同時に、ファイル・システムがこのコマンドによってサイズ変更されます。次のコマンドで、LogicalVolumePathの値はlvm lvscanコマンドによって取得され、PhysicalVolumePathの値はpvdisplayコマンドによって取得されます。

#lvextend -l+80%PVS --resizefs --verbose LogicalVolumePath PhysicalVolumePath

6. システムを通常のモードで再起動します。

2.10 Oracle Linuxデータベース・サーバーのスナップショット・ベースのバックアップの作成

データベース・サーバーのソフトウェアの重要な変更の前後にバックアップを行う必要があります。たとえば、次の手順の前後にバックアップを作成する必要があります。

- オペレーティング・システム・パッチの適用

- Oracleパッチの適用

- 重要な操作パラメータの再構成

- 重要なOracle以外のソフトウェアのインストールまたは再構成

この項では、次の項目について説明します。

- Oracle Linuxデータベース・サーバーのスナップショット・ベースのバックアップの作成 - パーティションをカスタマイズしていない場合

- Oracle Linuxデータベース・サーバーのスナップショット・ベースのバックアップの作成 - パーティションをカスタマイズしている場合

2.10.1 Oracle Linuxデータベース・サーバーのスナップショット・ベースのバックアップの作成 - パーティションをカスタマイズしていない場合

この手順は、スナップショット・ベースのバックアップを取得する方法を示しています。手順で示す値は、例です。

元の出荷時の構成からデータベース・サーバー・パーティションをカスタマイズしていない場合、この項の手順を使用してバックアップを作成し、そのバックアップを使用してデータベース・サーバーをリストアします。

注意:

- リカバリ手順により、出荷時の名前およびサイズを含む正確なパーティションがリストアされます。パーティションを少しでも変更した場合、この手順は使用できません。変更には、サイズや名前の変更、パーティションの追加または削除が含まれます。

- rootユーザーとして、すべての手順を実行する必要があります。

1. バックアップの保存先を準備します。

書込み可能な大きいNFSの場所を指定できます。NFSの場所は、バックアップtarファイルを保存できるように十分大きい必要があります。カスタマイズされていないパーティションの場合は、145GBで十分です。

a. NFS共有のマウント・ポイントを作成します。

mkdir -p /root/tar

b. NFSの場所をマウントします。

次のコマンドで、ip_addressはNFSサーバーのIPアドレス、nfs_locationはNFSの場所です。

mount -t nfs -o rw,intr,soft,proto=tcp,nolock
ip_address:/nfs_location/ /root/tar

2. /(ルート)、/u01および/bootディレクトリのスナップショット・ベース・バックアップを取得します。

a. ルート・ディレクトリにroot_snapという名前のスナップショットを作成します。

次の例ではLVDbSys1が使用されていますが、imageinfoの出力に基づく値を使用する必要があります。アクティブ・イメージがLVDbSys2にある場合、コマンドはlvcreate -L1G -s -c 32K -n root_snap /dev/VGExaDb/LVDbSys2になります。

lvcreate -L1G -s -c 32K -n root_snap /dev/VGExaDb/LVDbSys1

b. スナップショットにラベルを付けます。

e2label /dev/VGExaDb/root_snap DBSYS_SNAP

c. / (ルート)および/u01ディレクトリのファイル・システム・タイプを確認します。

12.1.2.1.0以上を実行しているデータベース・サーバーの場合は、"ext4"ファイル・システム・タイプを使用し、古いシステムの場合は"ext3"を使用します。X5より前のシステムで、セルが12.1.2.1.0以上に更新されている場合も、"ext3"を使用します。

# mount -l

d. スナップショットをマウントします。

前の手順で確認したように、次のmountコマンドでは、filesystem_type_of_/u01_directoryは、ファイル・システム・タイプのプレースホルダになります。

mkdir /root/mnt
mount /dev/VGExaDb/root_snap /root/mnt -t filesystem_type_of_/u01_directory

e. /u01ディレクトリにu01_snapという名前のスナップショットを作成します。

lvcreate -L5G -s -c 32K -n u01_snap /dev/VGExaDb/LVDbOra1

f. スナップショットにラベルを付けます。

e2label /dev/VGExaDb/u01_snap DBORA_SNAP

g. スナップショットをマウントします。

前述の手順2.cで確認したように、次のmountコマンドでは、filesystem_type_of_/u01_directoryは、ファイル・システム・タイプのプレースホルダになります。

mkdir -p /root/mnt/u01
mount /dev/VGExaDb/u01_snap /root/mnt/u01 -t filesystem_type_of_/u01_directory

h. バックアップのディレクトリに変更します。

cd /root/mnt

i. 次のいずれかのコマンドを使用して、バックアップ・ファイルを作成します。

- システムにNFSマウント・ポイントがない場合:

# tar -pjcvf /root/tar/mybackup.tar.bz2 * /boot --exclude \
tar/mybackup.tar.bz2 > /tmp/backup_tar.stdout 2> /tmp/backup_tar.stderr

- システムにNFSマウント・ポイントがある場合:
次のコマンドのnfs_mount_pointsは、NFSマウント・ポイントです。マウント・ポイントを除外すると、大きいファイルと長いバックアップ時間が生成できなくなります。

# tar -pjcvf /root/tar/mybackup.tar.bz2 * /boot --exclude \
tar/mybackup.tar.bz2 --exclude nfs_mount_points >         \
/tmp/backup_tar.stdout 2> /tmp/backup_tar.stderr

j. /tmp/backup_tar.stderrファイルをチェックして、重大なエラーがないかを確認します。
tarオープン・ソケットの障害に関するエラーおよび他の同様のエラーは無視できます。

3. スナップショットをアンマウントし、/ (ルート)および/01ディレクトリのスナップショットを削除します。

cd /
umount /root/mnt/u01
umount /root/mnt
/bin/rm -rf /root/mnt
lvremove /dev/VGExaDb/u01_snap
lvremove /dev/VGExaDb/root_snap

4. NFS共有をアンマウントします。

umount /root/tar

関連トピック

- Oracle Linuxデータベース・サーバーのスナップショット・ベースのバックアップの作成 - パーティションをカスタマイズしている場合

2.10.2 Oracle Linuxデータベース・サーバーのスナップショット・ベースのバックアップの作成 - パーティションをカスタマイズしている場合

データベース・サーバー・パーティションをカスタマイズしている場合、バックアップ手順はパーティションをカスタマイズしていない場合の手順と同じですが、次の例外があります。

- /u01のような追加パーティションをバックアップに追加する必要があります。

- パーティションの名前を変更した場合は、環境に定義した名前を使用してください。たとえば、/u01の名前が/myown_u01に変更された場合、コマンドに/myown_u01を使用します。

関連トピック

- Oracle Linuxデータベース・サーバーのスナップショット・ベースのバックアップの作成 - パーティションをカスタマイズしていない場合

2.11 Oracle Virtual Serverデプロイメントの管理ドメイン(dom0)とユーザー・ドメイン(domU)のバックアップ

Oracle Virtual Serverデプロイメントで、管理ドメイン(dom0)とユーザー・ドメイン(domU)をバックアップする必要があります。

- スナップショット・ベースのバックアップを使用した管理ドメインdom0のバックアップ

- ユーザー・ドメインのバックアップ

2.11.1 スナップショット・ベースのバックアップを使用した管理ドメインdom0のバックアップ

次の手順は、管理ドメインdom0のスナップショット・ベースのバックアップを取得する方法を示しています。次の手順で示す値は、例です。

rootユーザーとして、すべての手順を実行する必要があります。

1. バックアップの保存先を準備します。
バックアップ先は、書込み可能なNFSの場所など、ローカル・マシンの外部に存在するようにし、バックアップtarファイルを保持できる十分な大きさにする必要があります。カスタマイズされていないパーティションの場合、バックアップを保持するのに必要な領域は約60 GBです。

次のコマンドを使用してバックアップ先を準備できます。

# mkdir -p /remote_FS

# mount -t nfs -o rw,intr,soft,proto=tcp,nolock ip_address:/nfs_location/ /remote_FS

ip_addressは、NFSサーバーのIPアドレスで、nfs_locationは、バックアップを保持するNFSの場所です。

2. / (ルート)ディレクトリをホストするファイル・システムのスナップショット・ベースのバックアップを取得します。

a. / (ルート)ディレクトリをホストするファイル・システムに、LVDbSys3_snapという名前のスナップショットを作成します。このコマンドでは、LVDbSys3がアクティブ・パーティションであることを前提とします。

# lvcreate -L1G -s -n LVDbSys3_snap /dev/VGExaDb/LVDbSys3

b. スナップショットにラベルを付けます。

# e4label /dev/VGExaDb/LVDbSys3_snap DBSYSOVS_SNAP

c. スナップショットをマウントします。

# mkdir /root/mnt

# mount /dev/VGExaDb/LVDbSys3_snap /root/mnt -t ext4

d. バックアップのディレクトリに変更します。

# cd /root/mnt

e. バックアップ・ファイルを作成します。

# tar -pjcvf /remote_FS/mybackup.tar.bz2 * /boot > /tmp/backup_tar.stdout 2> /tmp/backup_tar.stderr

f. /tmp/backup_tar.stderrファイルをチェックして、重大なエラーがないかを確認します。tarオープン・ソケットの障害に関するエラーおよび他の同様のエラーは無視できます。

3. スナップショットをアンマウントして、ルート・ディレクトリのスナップショットを削除します。

# cd /
# umount /root/mnt
# /bin/rmdir /root/mnt
# lvremove /dev/VGExaDb/LVDbSys3_snap

4. 次のコマンドを使用して、NFS共有をアンマウントします。

# umount /remote_FS

2.11.2 ユーザー・ドメインのバックアップ

ユーザー・ドメインのバックアップ方法は2つあります。

- 方法1: Oracle Cluster File System (OCFS) reflinkを使用して記憶域リポジトリをバックアップし、一貫性のあるバックアップを取得する
この方法では、/EXAVMIMAGES ocfs2ファイル・システムである記憶域リポジトリをバックアップします。

dom0によって管理されるすべてのユーザー・ドメインをバックアップする、/EXAVMIMAGES全体をバックアップしたり、バックアップするユーザー・ドメインを選択したりできます。ユーザー・ドメインは、/EXAVMIMAGES/GuestImages/userディレクトリにあります。

この方法では、方法2よりもより堅牢で包括的なバックアップが可能です。方法2は、特にロール別に分離された環境で、迅速で簡単なバックアップ方法が提供されます。

方法1は、dom0管理者がユーザー・ドメインのバックアップを担当している場合に最適です。

- 方法2: スナップショット・ベースのバックアップを使用してユーザー・ドメインをバックアップする
この方法では、ユーザー・ドメイン内部からスナップショット・ベースのバックアップを作成することで、単一のユーザー・ドメインをバックアップします。

方法2は、ユーザー・ドメイン管理者がユーザー・ドメインのバックアップを担当している場合に最適です。

2.11.2.1 方法1: すべてのユーザー・ドメインをバックアップする

/EXAVMIMAGES OCFS2ファイル・システムである記憶域リポジトリをバックアップすることができます

次に示す手順ではすべてのユーザー・ドメインがバックアップされます。

1. バックアップの保存先を準備します。

バックアップ先は、書込み可能なNFSの場所など、ローカル・マシンの外部に存在するようにし、バックアップを保持できる十分な大きさにする必要があります。バックアップの保持に必要な領域は、システムにデプロイされるOracle VMの数に比例し、最大約1.6TBです。

このガイドでは、管理ドメイン当たりのユーザー・ドメインが15未満であることを前提とします。

次のコマンドを使用してバックアップ先を準備できます。

# mkdir -p /remote_FS

# mount -t nfs -o rw,intr,soft,proto=tcp,nolock ip_address:/nfs_location/ /remote_FS

ip_addressは、NFSサーバーのIPアドレスで、nfs_locationは、バックアップを保持するNFSの場所です。

注意:

次の手順2から4は、CSS misscount時間(デフォルトでは60秒に設定)内に完了する必要があります。ワークロードが高く、ユーザー・ドメインの一時停止とreflinkの作成に約45秒を超える時間がかかるような場合は、Oracle RACノードの削除を回避するために、reflinkを使用してスナップショットを取得する前に、VMをシャットダウンすることをお薦めします。これは、1つのOVS/dom0内のすべてのユーザー・ドメインを停止してバックアップし、その間Oracle RACクラスタ内のその他のユーザー・ドメインを起動しておくローリング方式で実行できます。

CSS misscountの詳細は、My Oracle Supportノート294430.1を参照してください。

2. ユーザー・ドメインを一時停止します。

# xm pause domain_id

3. /EXAVMIMAGESのすべてのファイルにreflinkを作成します。

4. ユーザー・ドメインの一時停止を解除します。

# xm unpause domain_id

5. 手順3で作成したreflinkファイルのスナップショットを.tarファイルとしてバックアップします。

6. 手順3で作成したreflinkを削除します。

次のサンプル・コマンドは、前述の手順2から6にリストされている操作の参照として使用できます。

##  Create the Backup Directory
find /EXAVMIMAGES -type d|grep -v 'lost+found'|awk '{print "mkdir -p /EXAVMIMAGES/Backup"$1}'|sh

## Pause user domains
xm list|egrep -v '^Domain-0|^Name'|awk '{print "xm pause",$2}'|sh

##  Create Reflinks for all the files to be backed up
find /EXAVMIMAGES/ -type f|awk '{print "reflink",$0,"/EXAVMIMAGES/Backup"$0}'|sh

## Unpause user domains
xm list|egrep -v '^Domain-0|^Name'|awk '{print "xm unpause",$2}'|sh;

##  Backup from the reflinks
pushd /EXAVMIMAGES/Backup/EXAVMIMAGES
tar -Spcvf /remote_FS/exavmimages-sparse.tar * 1> /tmp/Backup.log 2> /tmp/Backup.err
popd
rm -rf /EXAVMIMAGES/Backup/*

関連トピック

- 「Oracle ClusterwareでのCSSタイムアウトの計算」(Doc ID 294430.1)

2.11.2.2 方法2: ユーザー・ドメイン内からユーザー・ドメインをバックアップする

次の手順は、ユーザー・ドメイン内からユーザー・ドメインのスナップショット・ベースのバックアップを取得する方法を示しています。

注意:

LVMスナップショットを使用してユーザー・ドメイン内からユーザー・ドメインをバックアップする方法では、リカバリ時の使用に関して制限があります。このようなバックアップは、ユーザー・ドメインがまだブート可能で、rootユーザーとしてログインできる場合のリカバリ用にのみ使用できます。これは、一部のファイルに損失または損傷が発生したが、ユーザー・ドメインがブートされ、/ (ルート)パーティションがマウントされた後に、tarバックアップからリストアできるような損傷です。そのような状況ではなくユーザー・ドメインをブートできない損傷の場合は、上述の方法1で作成したバックアップを使用してユーザー・ドメインをリカバリする必要があります。この場合は次の手順を実行して、ユーザー・ドメイン・レベルでリカバリ手順を実行する必要があります。

すべての手順はユーザー・ドメイン内から実行します。

この手順では、次がバックアップされます。

- LVDbSys1 lvm

- LVDbOra1 lvm

- /bootパーティション

- Grid Infrastructureホーム

- RDBMSホーム

rootユーザーとして、すべての手順を実行する必要があります。

1. バックアップの保存先を準備します。

# mkdir -p /remote_FS

# mount -t nfs -o rw,intr,soft,proto=tcp,nolock ip_address:/nfs_location/ /remote_FS

ip_addressは、NFSサーバーのIPアドレスで、nfs_locationは、バックアップを保持するNFSの場所です。

2. 次のように、/ (ルート)および/u01ディレクトリを含むファイル・システムのスナップショット・ベースのバックアップを取得します。

a. ルート・ディレクトリを含むファイル・システムに、LVDbSys1_snapと言う名前のスナップショットを作成します。ボリューム・グループには、コマンドを正常に実行するのに少なくとも1 GBの空き領域が必要です。

# lvcreate -L1G -s -n LVDbSys1_snap /dev/VGExaDb/LVDbSys1

b. スナップショットにラベルを付けます。

# e2label /dev/VGExaDb/LVDbSys1_snap DBSYS_SNAP

c. スナップショットをマウントします。

# mkdir /root/mnt

# mount /dev/VGExaDb/LVDbSys1_snap /root/mnt -t ext4

d. /u01ディレクトリにu01_snapという名前のスナップショットを作成します。

# lvcreate -L256M -s -n u01_snap /dev/VGExaDb/LVDbOra1

e. スナップショットにラベルを付けます。

# e2label /dev/VGExaDb/u01_snap DBORA_SNAP

f. スナップショットをマウントします。

# mkdir -p /root/mnt/u01

# mount /dev/VGExaDb/u01_snap /root/mnt/u01 -t ext4

g. バックアップのディレクトリに変更します。

# cd /root/mnt

h. バックアップ・ファイルを作成して、前述で取得した2つのスナップショット、/bootパーティション、RDBMSホームおよびグリッド・インフラストラクチャのホームをバックアップします。

# tar -pjcvf /remote_FS/mybackup.tar.bz2 * /boot /u01/app/12.1.0.2/grid /u01/app/oracle/product/12.1.0.2/dbhome_1 > /tmp/backup_tar.stdout 2> /tmp/backup_tar.stderr

i. /tmp/backup_tar.stderrファイルをチェックして、重大なエラーがないかを確認します。tarオープン・ソケットの障害に関するエラーおよび他の同様のエラーは無視できます。

3. ルート・ディレクトリを含むファイル・システムのスナップショットをアンマウントおよび削除します。

# cd /
# umount /root/mnt/u01
# umount /root/mnt
# /bin/rmdir /root/mnt
# lvremove /dev/VGExaDb/u01_snap
# lvremove /dev/VGExaDb/LVDbSys1_snap

4. NFS共有をアンマウントします。

# umount /remote_FS

2.12 スナップショット・ベースのバックアップを使用したOracle Linuxデータベース・サーバーのリカバリ

この項では、データベース・サーバーで重大な障害が発生した後またはサーバー・ハードウェアを新しいハードウェアに交換する必要がある場合に、スナップショット・ベースのバックアップを使用して、Oracle Linuxを実行するデータベース・サーバー・ファイル・システムをリカバリする方法について説明します。たとえば、すべてのハード・ディスクを交換すると、システムの元のソフトウェアはトレースできません。これは、ソフトウェアの完全なシステムの交換と似ています。さらに、障害状態になる前にデータベース・サーバーが正常であったときに取得したLVMスナップショット・ベースのバックアップを使用するデータベース・サーバーの障害リカバリ方法を提供します。

リカバリ手順では、diagnostics.isoイメージを仮想CD-ROMとして使用し、ILOMを使用してレスキュー・モードでデータベース・サーバーを再起動します。一般的なワークフローには次の作業があります。

1. 次のものを再作成します。

- ブート・パーティション

- 物理ボリューム

- ボリューム・グループ

- 論理ボリューム

- ファイル・システム

- スワップ・パーティション

2. スワップ・パーティションをアクティブ化します。

3. /bootパーティションがアクティブなブート・パーティションであることを確認します。

4. データをリストアします。

5. GRUBを再構成します。

6. サーバーを再起動します。

この項で説明するリカバリ手順には、Exadata Storage Serverまたはデータベース・データのバックアップまたはリカバリは含まれません。バックアップとリカバリ手順は定期的にテストすることをお薦めします。この項では、次の項目について説明します。

- Oracle Linuxデータベース・サーバーのリカバリ - パーティションをカスタマイズしていない場合

- Oracle Linuxデータベース・サーバーのリカバリ - パーティションをカスタマイズしている場合

- Oracle Exadata Database Machineエイス・ラックのOracle Linuxデータベース・サーバーのリカバリ後の構成

注意:

テープからリストアする場合は、追加のドライブをロードする必要がありますが、この章では扱いません。ファイルはNFSの場所にバックアップし、既存のテープ・オプションを使用して、NFSホストとの間でバックアップとリカバリを行うことをお薦めします。

2.12.1 Oracle Linuxデータベース・サーバーのリカバリ - パーティションをカスタマイズしていない場合

パーティションをカスタマイズしていない場合にスナップショット・ベースのバックアップを使用してOracle Linuxデータベース・サーバーをリカバリできます。

この手順は、パーティション、論理ボリューム、ファイル・システム、およびそれらのサイズの配置がデータベース・サーバーの最初のデプロイ時の配置と等しい場合に適用されます。

注意:

ディスクの既存のすべてのデータは、この手順の実行中に失われます。

1. NFSサーバーを準備して、バックアップ・アーカイブmybackup.tar.bz2をホストします。

IPアドレスを使用して、NFSサーバーにアクセスできる必要があります。たとえば、IPアドレスnfs_ipを使用するNFSサーバーで/exportディレクトリがNFSマウントからエクスポートされる場合は、/exportディレクトリにmybackup.tar.bz2ファイルを置きます。

2. x86マシンの場合: 正常なデータベース・サーバーにある/opt/oracle.SupportTools/diagnostics.isoファイルをリストア対象のデータベース・サーバーのILOMに仮想メディアとして接続します。

次に、ILOMインタフェースを使用した仮想CD-ROMの設定方法の例を示します。

a. ILOMインタフェースを使用して、/opt/oracle.SupportTools/diagnostics.isoファイルをマシンのディレクトリにコピーします。

b. ILOM Webインタフェースにログインします。

c. リモート制御タブからリモート・コンソールを選択します。これにより、コンソールが起動します。

d. 「デバイス」メニューを選択します。

e. CD-ROMイメージオプションを選択します。

f. diagnostics.isoファイルの場所に移動します。

g. diagnostics.isoファイルを開きます。

h. リモート制御タブからホスト制御を選択します。

i. 次の起動デバイスとしてCDROMを値リストから選択します。

j. 「保存」をクリックします。

3. SPARCマシンの場合: 正常なデータベース・サーバーにある/opt/oracle.SupportTools/diagnostics.isoファイルをリストア対象のデータベース・サーバーのILOMに仮想メディアとして接続します。

a. バックアップ・アーカイブmybackup.tar.bz2をホストしているNFSの場所に/opt/oracle.SupportTools/diagnostics.isoファイルをコピーします。

b. ILOMコンソールにログインします。

c. 次のコマンドを実行します。

set /SP/services/kvms/host_storage_device/ mode=remote

d. diagnostic isoのサーバーURIを指定します。

set /SP/services/kvms/host_storage_device/remote/ server_URI=nfs://ip-number:/path/to/diagnostics.iso

4. ISOファイルからシステムを再起動します。

起動中に、CD-ROMを起動デバイスとして選択します。次のコマンドを使用して、ブート中に手動で起動デバイスを選択するかわりに、リストア対象のデータベース・サーバーのILOMにアクセスできる他のマシンからipmitoolコマンドを使用して、起動デバイスを事前に設定することもできます。

ipmitool -H ILOM_ip_address_or_hostname \
-U root_user chassis bootdev cdrom

ipmitool -H ILOM_ip_address_or_hostname \
-U root_user chassis power cycle

5. システムで要求された場合は、次のように入力します。レスポンスは太字で示されています。

リリース12.1.2.2.0以上のExadataソフトウェアでは、DHCPが使用されるため、ネットワークを手動で設定する必要はありません。

- リリース12.1.2.2.0以上のExadataソフトウェアを使用している場合、プロンプトは次のようになります。

Use diagnostics shell password to login as root user
(reboot or power cycle to exit the shell),
(r)estore system from NFS backup archive.
Select: r
Continue (y/n) [n]: y
Rescue password:
[INFO: ] Enter path to the backup file on the NFS server in format:
Enter path to the backup file on the NFS server in format:
<ip_address_of_the_NFS_share>:/<path>/<archive_file>
For example, 10.124.1.15:/export/nfs/share/backup.2010.04.08.tar.bz2
NFS line: 10.196.101.250:/srv/file/test/OARDC/fuji0506/mybackup06.tar.bz2
[INFO: ] The backup file could be created either from LVM or non-LVM based COMPUTE node
[INFO: ] Versions below 11.2.1.3.0 do not support LVM based partitioning
Use LVM based scheme. (y/n) [y]:
[INFO: ] Starting DHCP client
ixgbe 0000:88:00.0: eth2: NIC Link is Up 1 Gbps, Flow Control: None
ixgbe 0000:20:00.1: eth1: NIC Link is Up 1 Gbps, Flow Control: None
ixgbe 0000:20:00.0: eth0: NIC Link is Up 1 Gbps, Flow Control: RX/TX
[INFO: ] DHCP settings are in use
[INFO: ] Interface: eth0
[INFO: ] IP address: 10.196.103.123
[INFO: ] Netmask: 255.255.252.0
[INFO: ] Gateway: 10.196.100.4
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
FS-Cache: Loaded
FS-Cache: Netfs 'nfs' registered for caching
NET: Registered protocol family 10
ADDRCONF(NETDEV_UP): eth4: link is not ready
ADDRCONF(NETDEV_UP): eth5: link is not ready
ADDRCONF(NETDEV_UP): eth3: link is not ready

リカバリが完了すると、ログイン画面が表示されます。

- 12.1.2.2.0より前のリリースのExadataソフトウェアを使用している場合、プロンプトは次のようになります。

Choose from following by typing letter in '()':
(e)nter interactive diagnostics shell. Must use credentials from Oracle
support to login (reboot or power cycle to exit the shell),
(r)estore system from NFS backup archive,
Select:r
Are you sure (y/n) [n]:y

The backup file could be created either from LVM or non-LVM based compute node
versions below 11.2.1.3.1 and 11.2.2.1.0 or higher do not support LVM based partitioning
use LVM based scheme(y/n):y

Enter path to the backup file on the NFS server in format:
ip_address_of_the_NFS_share:/path/archive_file
For example, 10.10.10.10:/export/operating_system.tar.bz2
NFS line:nfs_ip:/export/mybackup.tar.bz2
IP Address of this host:IP address of the DB host
Netmask of this host:netmask for the above IP address
Default gateway:Gateway for the above IP address. If there is no default gateway in your network, enter 0.0.0.0.

リカバリが完了すると、ログイン画面が表示されます。

6. rootユーザーとしてログインします。
rootユーザーのパスワードがない場合は、Oracleサポート・サービスにお問い合せください。

7. rebootコマンドを使用して、システムを再起動します。
リストア・プロセスが完了です。

8. データベース・サーバーにログインして、すべてのOracleソフトウェアが起動して動作していることを確認します。
/usr/local/bin/imagehistoryコマンドは、データベース・サーバーが再構築されたことを示します。

次に、出力の例を示します。

imagehistory

Version                  : 11.2.2.1.0
Image activation date    : 2010-10-13 13:42:58 -0700
Imaging mode             : fresh
Imaging status           : success

Version                  : 11.2.2.1.0
Image activation date    : 2010-10-30 19:41:18 -0700
Imaging mode             : restore from nfs backup
Imaging status           : success

9. リカバリをOracle Exadata Database Machineエイス・ラックで実行した場合は、「Oracle Exadata Database Machineエイス・ラックのOracle Linuxデータベース・サーバーのリカバリ後の構成」の手順を実行します。

2.12.2 Oracle Linuxデータベース・サーバーのリカバリ - パーティションをカスタマイズしている場合

次の手順では、パーティションをカスタマイズしている場合にスナップショット・ベースのバックアップを使用してOracle Linuxデータベース・サーバーをリカバリする方法について説明します。diagnostics.isoを使用してデータベース・サーバーを起動した後にenter interactive diagnostics shellおよびrestore system from NFS backup archiveオプションの選択を要求されるまで、カスタマイズされていないパーティションのリストア手順と同じです。

1. 診断シェルの入力を選択して、rootユーザーとしてログインします。rootユーザーのパスワードがない場合は、Oracleサポート・サービスにお問い合せください。

2. 必要に応じて、/opt/MegaRAID/MegaCli/MegaCli64を使用して、ディスク・コントローラを構成してディスクを設定します。

3. /bootにマウントする少なくとも128MBのプライマリ・ブート・パーティションが作成されていることを確認します。ブート領域にLVMパーティションは指定できません。

4. 次のコマンドを使用して、ブート・パーティションを作成します。

umount /mnt/cell
parted /dev/sda

インタラクティブ・シェルが表示されます。次の手順では、システム・プロンプトに応答する方法について説明します。

a. 次のようにディスク・ラベルを割り当てます。
バージョン11.2.3.3.0以上を実行している場合は、mklabel gptを実行します。

11.2.3.3.0より前のバージョンを実行している場合は、mklabel msdosを実行します。

b. ユニット・サイズをセクターとして設定するには、「unit s」と入力します。

c. 「print」と入力して既存のパーティションを表示して、パーティション表を確認します。

d. 「rm <part#>」と入力して、再作成されるパーティションを削除します。

e. 新しい最初のパーティションを作成するには、「mkpart primary 63 1048639」と入力します。

f. ブート・パーティションのブート可能フラグを設定するには、「set 1 boot on」と入力します。

5. 次のように、2番目のプライマリ(lvm)・パーティションを作成します。

a. 新しい2番目のパーティションを作成するには、「mkpart primary 1048640 -1」と入力します。

b. LVMを選択するには、「set 2 lvm on」と入力します。

c. ディスクに情報を書き込んだ後に終了するには、「quit」と入力します。

6. 次のように、/sbin/lvmコマンドを使用して、カスタマイズされたLVMパーティションを再作成し、mkfsを使用してファイル・システムを作成します。

a. 次のコマンドを使用して、物理ボリューム、ボリューム・グループおよび論理ボリュームを作成します。

lvm pvcreate /dev/sda2
lvm vgcreate VGExaDb /dev/sda2

b. 次のコマンドを使用して、/(ルート)ディレクトリの論理ボリュームおよびファイル・システムを作成し、ラベルを付けます。

- 論理ボリュームを作成します。

lvm lvcreate -n LVDbSys1 -L40G VGExaDb

- 予約パーティション用の論理ボリュームを作成します。この手順は、リリース12.1.2.2.0以上のExadataソフトウェアを実行している場合にのみ必要となります。

# lvm lvcreate -n LVDoNotRemoveOrUse –L1G VGExaDb

この論理ボリュームにファイル・システムは作成しません。

- ファイル・システムを作成します。
ext4ファイル・システムがすでにある場合は、次のようにmkfs.ext4コマンドを使用します。

mkfs.ext4 /dev/VGExaDb/LVDbSys1

ext3ファイル・システムがすでにある場合は、次のようにmkfs.ext3コマンドを使用します。

mkfs.ext3 /dev/VGExaDb/LVDbSys1

- ラベルを付けます。

e2label /dev/VGExaDb/LVDbSys1 DBSYS

c. 次のコマンドを使用して、swapディレクトリの論理ボリュームを作成し、ラベルを付けます。

lvm lvcreate -n LVDbSwap1 -L24G VGExaDb
mkswap -L SWAP /dev/VGExaDb/LVDbSwap1

d. 次のコマンドを使用して、root/u01ディレクトリの論理ボリュームを作成し、ラベルを付けます。

- 論理ボリュームを作成します。

lvm lvcreate -n LVDbOra1 -L100G VGExaDb

- ファイル・システムを作成します。
ext4ファイル・システムがすでにある場合は、次のようにmkfs.ext4コマンドを使用します。

mkfs.ext4 /dev/VGExaDb/LVDbOra1

ext3ファイル・システムがすでにある場合は、次のようにmkfs.ext3コマンドを使用します。

mkfs.ext3 /dev/VGExaDb/LVDbOra1

- ラベルを付けます。

e2label /dev/VGExaDb/LVDbOra1 DBORA

e. 次のコマンドを使用して、/bootパーティションにファイル・システムを作成し、ラベルを付けます。

- ファイル・システムを作成します。
ext4ファイル・システムがすでにある場合は、次のようにmkfs.ext4コマンドを使用します。

mkfs.ext4 /dev/sda1

ext3ファイル・システムがすでにある場合は、次のようにmkfs.ext3コマンドを使用します。

mkfs.ext3 /dev/sda1

- ラベルを付けます。

e2label /dev/sda1 BOOT

注意:

カスタマイズされたファイル・システム配置の場合は、ここで追加の論理ボリュームを作成できます。カスタマイズされた配置では、異なるサイズが使用される場合があります。

7. すべてのパーティションのマウント・ポイントを作成して元のシステムをミラー化し、各パーティションをマウントします。たとえば、/mntがこの最上位ディレクトリとして使用されると、マウントされるパーティションのリストは次のようになります。

/dev/VGExaDb/LVDbSys1 on /mnt
/dev/VGExaDb/LVDbOra1 on /mnt/u01
/dev/sda1 on /mnt/boot

次に、ルート・ファイル・システムのマウント方法および2つのマウント・ポイントの作成方法の例を示します。次のコマンドのfilesystem_type_of_/_directoryは、/ (ルート)ディレクトリのファイル・システム(ext3またはext4のいずれか)を指定します。

mount /dev/VGExaDb/LVDbSys1 /mnt -t filesystem_type_of_/_directory
mkdir /mnt/u01 /mnt/boot

mount /dev/VGExaDb/LVDbOra1 /mnt/u01 -t filesystem_type_of_/u01_directory
mount /dev/sda1 /mnt/boot -t filesystem_type_of_/boot_directory

注意:

カスタマイズされたファイル・システム配置で追加の論理ボリュームがある場合は、この手順で追加のマウント・ポイントを作成する必要があります。

8. 次のように、ネットワークを起動し、バックアップが存在するNFSサーバーをマウントします。

a. 次のコマンドを実行して、ネットワークを起動します。

- オペレーティング・システムがOracle Linux 6以上の場合:

ip address add ip_address_for_eth0/netmask_for_eth0 dev eth0

ip link set up eth0

ip route add default via gateway_address dev eth0

- オペレーティング・システムがOracle Linux 5の場合:

ifconfig eth0 ip_address_for_eth0 netmask netmask_for_eth0 up

b. NFSサーバーをIPアドレスnfs_ipでマウントし、次のコマンドを使用して/exportとしてバックアップする場所にエクスポートします。

mkdir -p /root/mnt
mount -t nfs -o ro,intr,soft,proto=tcp,nolock nfs_ip:/export /root/mnt

9. 次のコマンドを使用して、バックアップからリストアします。

tar -pjxvf /root/mnt/mybackup.tar.bz2 -C /mnt

10. 次のコマンドを使用して、リストアしたファイル・システムをアンマウントし、/bootパーティションを再マウントします。

umount /mnt/u01
umount /mnt/boot
umount /mnt
mkdir /boot
mount /dev/sda1 /mnt/boot -t filesystem_type_of_/boot_directory

11. ブート・ローダーを設定します。次の場合、/dev/sda1が/boot領域です。

grub
find /I_am_hd_boot     (1)
root (hdX,0)
setup (hdX)
quit

前述のコマンドの(1)により、(hd0,0)などのI_am_hd_bootファイルを含むハード・ディスクhdXが検索されます。

12. diagnostics.isoファイルを切り離します。

13. 次のコマンドを使用して、/bootパーティションをアンマウントします。

umount /boot

14. システムを再起動します。これで、サーバーのリストア手順が完了です。

reboot

15. リカバリをOracle Exadata Database Machineエイス・ラックで実行した場合は、「Oracle Exadata Database Machineエイス・ラックのOracle Linuxデータベース・サーバーのリカバリ後の構成」の手順を実行します。

2.12.3 Oracle Exadata Database Machineエイス・ラックのOracle Linuxデータベース・サーバーのリカバリ後の構成

Oracle Exadata Database Machineエイス・ラックのOracle Linuxデータベース・サーバーを再イメージ化、リストアまたはレスキューした場合は、次の手順を実行する必要があります。

Oracle Exadata Storage Serverリリース12.1.2.2.3以前を実行するX3-2マシン

1. 別のデータベース・サーバーにある/opt/oracle.SupportTools/resourcecontrolユーティリティを、リカバリしたサーバーの/opt/oracle.SupportTools/resourcecontrolディレクトリにコピーします。

2. 次のコマンドを使用して、ユーティリティに対して適切な権限が設定されていることを確認します。

# chmod 740 /opt/oracle.SupportTools/resourcecontrol

3. 次のコマンドを使用して、現在の構成を検証します。コマンドの出力が表示されます。

# /opt/oracle.SupportTools/resourcecontrol -show

Validated hardware and OS. Proceed.
Number of cores active: 8

エイス・ラック構成の場合、8個のコアが有効になっている必要があります。その値が表示された場合、構成の変更は不要です。その値が表示されなかった場合は、手順4に進みます。

注意:

ユーティリティの実行後に次のようなエラーが発生した場合は、通常、サーバーを1回以上再起動すると、エラーが解消されます。

Validated hardware and OS. Proceed.
Cannot get ubisconfig export. Cannot Proceed. Exit.

4. 次のコマンドを使用して、構成を変更します。

# /opt/oracle.SupportTools/resourcecontrol -cores 8

5. 次のコマンドを使用して、サーバーを再起動します。

# reboot

6. 次のコマンドを使用して、構成の変更を検証します。

# /opt/oracle.SupportTools/resourcecontrol -show

コマンドを実行すると、データベース・サーバーについて次のような出力が表示されると予想されます。

This is a Linux database server.
Validated hardware and OS. Proceed.
Number of cores active per socket: 4

X6-8、X5-8、X4-8、X6-2、X5-2、X4-2およびX3-2マシン

X3–2システムでは、Oracle Exadata Storage Serverリリース12.1.2.3.0以上を実行している場合のみこの方法を使用します。

1. リカバリしたサーバーで、resourcecontrolユーティリティが/opt/oracle.SupportToolsディレクトリに存在することを確認します。そうでない場合は、リカバリしたサーバーに別のデータベース・サーバーからコピーします。

2. 次のコマンドを使用して、ユーティリティに対して適切な権限が設定されていることを確認します。

# chmod 740 /opt/oracle.SupportTools/resourcecontrol

3. 次のコマンドを使用して、現在の構成を検証します。

# dbmcli -e list dbserver attributes coreCount

それぞれのマシンの構成で許可されるコアの数は、表2-1を参照してください。正しい値が表示されている場合、構成の変更は不要です。その値が表示されなかった場合は、手順4に進みます。

4. 次のコマンドを使用して、構成を変更します。

# dbmcli -e alter dbserver pendingCoreCount=new_core_count force

エイス・ラックのnew_core_countは、X6-2の場合は22、X5-2の場合は18、X4-8の場合は60、X4-2の場合は12です。

5. 次のコマンドを使用して、サーバーを再起動します。

# reboot

6. 次のコマンドを使用して、構成の変更を検証します。

# dbmcli -e list dbserver attributes coreCount

2.13 Oracle Virtual Serverデプロイメントでのリカバリ

次の手順では、重大な障害が発生してOVSが損傷を受けた場合、またはサーバー・ハードウェアを新しいハードウェアに交換する必要がある場合に、スナップショット・ベースのバックアップからOracle Virtual Server (OVS)をリカバリする方法について説明します。たとえば、すべてのハード・ディスクを交換すると、システムの元のソフトウェアはトレースできません。これは、ソフトウェアの完全なシステムの交換と似ています。さらに、障害状態になる前にデータベース・サーバーが正常であったときに取得したLVMスナップショット・ベースのバックアップを使用するデータベース・サーバーの障害リカバリ方法を提供します。

リカバリ手順では、diagnostics.isoイメージを仮想CD-ROMとして使用し、ILOMを使用してレスキュー・モードでOracle Virtual Serverを再起動します。この手順の概要は、次のようになります。

1. 次のものを再作成します。

- ブート・パーティション

- 物理ボリューム

- ボリューム・グループ

- 論理ボリューム

- ファイル・システム

- スワップ・パーティション

2. スワップ・パーティションをアクティブ化します。

3. /bootパーティションがアクティブなブート・パーティションであることを確認します。

4. データをリストアします。

5. GRUBを再構成します。

6. サーバーを再起動します。

この項で説明するリカバリ手順には、Exadata Storage Serverまたはデータベース・データのバックアップまたはリカバリは含まれません。バックアップとリカバリ手順は定期的にテストすることをお薦めします。

2.13.1 シナリオ1: Oracle Virtual Serverとすべてのユーザー・ドメインのバックアップからのリカバリ

注意:

ディスクの既存のすべてのデータは、この手順の実行中に失われます。

1. NFSサーバーを準備して、バックアップ・アーカイブmybackup.tar.bz2をホストします。
IPアドレスを使用して、NFSサーバーにアクセスできる必要があります。たとえば、IPアドレスnfs_ipを使用するNFSサーバーで/exportディレクトリがNSFマウントからエクスポートされる場合は、/exportディレクトリにmybackup.tar.bz2ファイルを置きます。

2. 正常なデータベース・サーバーにある/opt/oracle.SupportTools/diagnostics.isoファイルをリストア対象のOracle Virtual ServerのILOMに仮想メディアとして接続します。

次に、ILOMインタフェースを使用した仮想CD-ROMの設定方法の例を示します。

a. ILOMインタフェースを使用するマシンのディレクトリに、diagnostics.isoファイルをコピーします。

b. ILOM Webインタフェースにログインします。

c. Oracle ILOM Webインタフェースで、リモート制御→リダイレクトをクリックします。

d. ビデオのリダイレクトを使用するを選択します。

e. コンソールが起動したら、KVMSメニューのストレージをクリックします。

f. DVDイメージなどのストレージ・イメージを追加するには、ストレージ・デバイス・ダイアログ・ボックスで、「追加」をクリックします。

g. diagnostics.isoファイルを開きます。

図2-7 diagnostics.isoファイルを選択するための「ストレージ・デバイスの追加」ダイアログを表示するILOM Webインタフェース

h. ストレージ・デバイス・ダイアログ・ボックスからストレージ・メディアをリダイレクトするには、ストレージ・メディアを選択して、「接続」をクリックします。
デバイスとの接続が確立されると、ストレージ・デバイス・ダイアログ・ボックスの「接続」ボタンのラベルが「切断」に変わります。

i. 「ホスト管理」タブからホスト制御を選択します。

j. 次の起動デバイスとしてCDROMを値リストから選択します。

k. 「保存」をクリックします。システムがブートすると、diagnostics.isoイメージが使用されます。

3. isoファイルからシステムを再起動します。
これは、次のいずれかの方法を使用して実行できます。

- 起動中に、CD-ROMを起動デバイスとして選択するか、または

- リストア対象のOVSのILOMにアクセスできる他のマシンから、ipmitoolコマンドを実行して、起動デバイスを事前に設定します。

# ipmitool -H ILOM_ip_address_or_hostname -U root chassis bootdev cdrom

# ipmitool -H ILOM_ip_address_or_hostname -U root chassis power cycle

4. システムに次が表示された場合:

Choose from following by typing letter in '()':
(e)nter interactive diagnostics shell. Must use credentials from Oracle support to login (reboot or power cycle to exit the shell),
(r)estore system from NFS backup archive,

"e"と入力して、診断シェルに入り、rootユーザーとしてログインします。rootユーザーのパスワードがない場合は、Oracleサポート・サービスに連絡してください。

5. 必要に応じて、/opt/MegaRAID/MegaCli/MegaCli64を使用して、ディスク・コントローラを構成してディスクを設定します。

6. 障害の発生後に論理ボリューム、ボリューム・グループおよび物理ボリュームが存在する場合は、それらを削除します。

# lvm vgremove VGExaDb

# lvm pvremove /dev/sda2

7. 既存のパーティションを削除し、ドライブをクリーン・アップします。

# parted
GNU Parted 2.1
Using /dev/sda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) rm 1
sda: sda2 sda3
(parted) rm 2
sda: sda3
(parted) rm 3
sda:
(parted) q

# dd if=/dev/zero of=/dev/sda bs=64M count=2

8. 3つのパーティションを/dev/sdaに作成します。

a. ディスク/dev/sdaの終了セクタを取得し、変数に保存します。

# end_sector=$(parted -s /dev/sda unit s print|perl -ne '/^Disk\s+\S+:\s+(\d+)s/ and print $1')

次のコマンドの開始および終了セクタの値は、残りのdom0から取得されています。これらの値は時間とともに変更される場合があるため、次のコマンドを使用して、これらの値を残りのdom0から確認することをお薦めします。

# parted -s /dev/sda unit S print

b. /bootパーティション/dev/sda1を作成します。

# parted -s /dev/sda mklabel gpt mkpart primary 64s 1048639s set 1 boot on

c. LVMを保持するパーティション/dev/sda2を作成します。

# parted -s /dev/sda mkpart primary 1048640s 240132159s set 2 lvm on

d. ocfs2記憶域リポジトリ・パーティション/dev/sda3を作成します。

# parted -s /dev/sda mkpart primary 240132160s ${end_sector}s set 3

9. /sbin/lvmコマンドを使用して論理ボリュームを再作成し、mkfsを使用してファイル・システムを作成します。

a. 物理ボリュームおよびボリューム・グループを作成します。

# lvm pvcreate /dev/sda2

# lvm vgcreate VGExaDb /dev/sda2

b. / (ルート)ディレクトリを含むファイル・システムの論理ボリュームを作成して、ラベルを付けます。

# lvm lvcreate -n LVDbSys3 -L30G VGExaDb

# mkfs.ext4 /dev/VGExaDb/LVDbSys3

# e2label /dev/VGExaDb/LVDbSys3 DBSYSOVS

c. スワップ・ディレクトリの論理ボリュームを作成して、ラベルを付けます。

# lvm lvcreate -n LVDbSwap1 -L24G VGExaDb

# mkswap -L SWAP /dev/VGExaDb/LVDbSwap1

d. バックアップ・パーティションの論理ボリュームを作成して、その上部にファイル・システムを構築します。

# lvm lvcreate -n LVDbSys2 -L30G VGExaDb

# mkfs.ext4 /dev/VGExaDb/LVDbSys2

e. 予約パーティション用の論理ボリュームを作成します。

# lvm lvcreate -n LVDoNotRemoveOrUse –L1G VGExaDb

この論理ボリュームにファイル・システムは作成しません。

f. /dev/sda1パーティションにファイル・システムを作成し、ラベルを付けます。
次のmkfs.ext3コマンドで、inodeサイズを128に設定するには"-I 128"オプションが必要です。

# mkfs.ext3 -I 128 /dev/sda1

# tune2fs -c 0 -i 0 /dev/sda1

# e2label /dev/sda1 BOOT

10. すべてのパーティションのマウント・ポイントを作成して、各パーティションをマウントします。
たとえば、/mntが最上位ディレクトリとして使用されると、マウントされるパーティションのリストは次のようになります。

- /dev/VGExaDb/LVDbSys3 on /mnt

- /dev/sda1 on /mnt/boot

次の例では、ルート・ファイル・システムをマウントし、2つのマウント・ポイントを作成します。

# mount /dev/VGExaDb/LVDbSys3 /mnt -t ext4

# mkdir /mnt/boot

# mount /dev/sda1 /mnt/boot -t ext3

11. eth0でネットワークを起動し、ホストのIPアドレス/ネットマスクを割り当てます。

# ifconfig eth0 ip_address_for_eth0 netmask netmask_for_eth0 up

# route add -net 0.0.0.0 netmask 0.0.0.0 gw gateway_ip_address

12. バックアップを保持するNFSサーバーをマウントします。

# mkdir -p /root/mnt

# mount -t nfs -o ro,intr,soft,proto=tcp,nolock nfs_ip:/location_of_backup /root/mnt

13. 「スナップショット・ベースのバックアップを使用した管理ドメインdom0のバックアップ」で作成したバックアップ、/およびブート・ファイル・システムからリストアします。

# tar -pjxvf /root/mnt/backup-of-root-and-boot.tar -C /mnt

14. リストアした/dev/sda1パーティションをアンマウントし、/bootに再マウントします。

# umount /mnt/boot

# mkdir /boot

# mount /dev/sda1 /boot -t ext3

15. GRUBブート・ローダーを設定します。次の場合、/dev/sda1が/boot領域です。

# grub
root (hd0,0)
setup (hd0)
quit

16. /bootパーティションをアンマウントします。

# umount /boot

17. diagnostics.isoファイルを切り離します。
これを行うには、手順2で「接続」をクリックしてDVD .isoイメージを割り当てたときに表示された、ILOM Webインタフェース・コンソールの「切断」をクリックします。

18. リストアした/etc/fstabファイルを確認し、/EXAVMIMAGESおよび/dev/sda3への参照を削除します。

# cd /mnt/etc

/EXAVMIMAGESまたは/dev/sda3を参照する行をすべてコメント・アウトします。

19. システムを再起動します。これで、OVS/dom0のリストア手順が完了です。

# reboot

20. 必要であれば、エイス・ラックに変換します。
リカバリをOracle Exadata Database Machineエイス・ラックで実行する場合は、「Oracle Exadata Database Machineエイス・ラックのOracle Linuxデータベース・サーバーのリカバリ後の構成」の手順を実行します。

21. サーバーが再起動されたら、ocfs2ファイル・システムを/dev/sda3パーティションに構築します。

# mkfs -t ocfs2 -L ocfs2 -T vmstore --fs-features=local /dev/sda3 --force

22. ocfs2パーティション/dev/sda3を/EXAVMIMAGESにマウントします。

# mount -t ocfs2 /dev/sda3 /EXAVMIMAGES

23. /etc/fstabで、手順18でコメント・アウトした/EXAVMIMAGESおよび/dev/sda3への参照を非コメント化します。

24. 記憶域リポジトリ(/EXAVMIMAGES)バックアップを保持するバックアップNFSサーバーをマウントし、すべてのユーザー・ドメイン・イメージを保持する/EXAVMIMAGESファイル・システムをリストアします。

# mkdir -p /root/mnt

# mount -t nfs -o ro,intr,soft,proto=tcp,nolock nfs_ip:/location_of_backup /root/mnt

25. /EXAVMIMAGESファイル・システムをリストアします。

# tar -Spxvf /root/mnt/backup-of-exavmimages.tar -C /EXAVMIMAGES

26. 各ユーザー・ドメインを起動します。

# xm create /EXAVMIMAGES/GuestImages/user_domain_hostname/vm.cfg

この時点で、すべてのユーザー・ドメインと、それらの中のGIおよびデータベース・インスタンスが起動し、残りの他のOVSノードによって形成されたOracle RACクラスタに参加します。

2.13.2 シナリオ2: dom0の再イメージ化およびバックアップからのユーザー・ドメインのリストア

次の手順は、修復できないほどの損傷がOVS/dom0で発生し、バックアップがdom0に存在しないが、すべてのユーザー・ドメインを格納する記憶域リポジトリ(/EXAVMIMAGESファイル・システム)の中に利用可能なバックアップが存在する場合に使用できます。この手順では、dom0を再イメージ化し、すべてのユーザー・ドメインを再構築します。

1. 「Oracle Linuxデータベース・サーバーの再イメージ化」の手順を使用して、ラック内のその他のOVS/dom0で使用されるイメージでOVSを再イメージ化します。

2. 次のコマンドを実行します。

# /opt/oracle.SupportTools/switch_to_ovm.sh

# /opt/oracle.SupportTools/reclaimdisks.sh –free –reclaim

3. リカバリをOracle Exadata Database Machineエイス・ラックで実行する場合は、「Oracle Exadata Database Machineエイス・ラックのOracle Linuxデータベース・サーバーのリカバリ後の構成」の手順を実行します。

4. ocfs2ファイル・システムを/dev/sda3パーティションに再構築します。

# umount /EXAVMIMAGES

# mkfs -t ocfs2 -L ocfs2 -T vmstore --fs-features=local /dev/sda3 --force

5. ocfs2パーティション/dev/sda3を/EXAVMIMAGESにマウントします。

# mount -t ocfs2 /dev/sda3 /EXAVMIMAGES

6. バックアップNFSサーバーをマウントし、ユーザー・ドメイン・イメージを保持する/EXAVMIMAGESファイル・システムをリストアします。

# mkdir -p /remote_FS

# mount -t nfs -o ro,intr,soft,proto=tcp,nolock nfs_ip:/location_of_backup /remote_FS

7. /EXAVMIMAGESファイル・システムをリストアします。

# tar -Spxvf /remote_FS/backup-of-exavmimages.tar -C /EXAVMIMAGES

注意:

記憶域リポジトリのリストア処理では、ユーザー・ドメイン固有のファイル(/EXAVMINAGES/GuestImages/<user_domain>/下のファイル)が通常のファイルとしてリストアされ、ユーザー・ドメインの作成時にこれらのファイルが記憶域リポジトリに最初に作成されたocfs2 reflinkとしてはリストアされません。したがって、/EXAVMINAGES内の領域の使用量は、バックアップ時の元の領域の使用量に比べて、リストア処理後に増加することがあります。

8. ネットワーク・ブリッジを手動で設定します。

a. ovmutils rpmのバージョンを確認します。

# rpm -qa|grep ovmutils

b. ovmutils rpmのバージョンが12.1.2.2.0より前の場合は、次の手順を実行します。

- /opt/exadata_ovm/exadata.img.domu_makerをバックアップします。このバックアップ・コピーは後ほど必要になります。

# cp /opt/exadata_ovm/exadata.img.domu_maker /opt/exadata_ovm/exadata.img.domu_maker-orig

- viなどのテキスト・エディタで/opt/exadata_ovm/exadata.img.domu_makerファイルを開き、"g_do_not_set_bridge=yes"を検索します。これは、CASE文オプション"network-discovery"の数行下にあります。
これを"g_do_not_set_bridge=no"に変更します。

/opt/exadata_ovm/exadata.img.domu_makerを保存して終了します。

- /EXAVMIMAGES/confディレクトリのすべてのxmlファイルで/opt/exadata_ovm/exadata.img.domu_makerを手動で実行します。

# cd /EXAVMIMAGES/conf
# ls -1|while read file; do /opt/exadata_ovm/exadata.img.domu_maker network-discovery $file /tmp/netdisc-$file; done

- バックアップ・コピーから/opt/exadata_ovm/exadata.img.domu_makerをリストアします。

# cp /opt/exadata_ovm/exadata.img.domu_maker-orig /opt/exadata_ovm/exadata.img.domu_maker

c. ovmutils rpmのバージョンが12.1.2.2.0以降の場合、次のコマンドを実行します。

# /opt/exadata_ovm/exadata.img.domu_maker add-bonded-bridge-dom0 vmbondeth0 eth4 eth5

9. /EXAVMIMAGES/GuestImagesディレクトリ内のユーザー・ドメイン・ディレクトリごとに、次の手順を実行します。

a. ユーザー・ドメインのUUIDを取得します。

# grep ^uuid /EXAVMIMAGES/GuestImages/<user domain hostname>/vm.cfg|awk -F"=" '{print $2}'|sed s/"'"//g|sed s/" "//g

コマンドを実行すると、uuid値が返され、これは次のコマンドで使用されます。

b. # mkdir -p /OVS/Repositories/uuid

c. # ln -s /EXAVMIMAGES/GuestImages/user_domain_hostname/vm.cfg /OVS/Repositories/uuid/vm.cfg

d. # ln -s /OVS/Repositories/uuid/vm.cfg /etc/xen/auto/user_domain_hostname.cfg

e. # mkdir VirtualDisks

f. # cd VirtualDisks

g. vm.cfgファイ内にある4つのディスク・イメージ名を使用して、このディレクトリに4つのシンボリック・リンクを作成します(/EXAVMIMAGES/GuestImages/user_domain_hostnameディレクトリ内にある4つの".img"ファイルを指します)。
たとえば、/OVS/Repositories/uuidディレクトリのサンプルvm.cfgファイルのサンプル・ディスク・エントリを次に示します。

disk =  ['file:/OVS/Repositories/6e7c7109c1bc4ebba279f84e595e0b27/VirtualDisks/dfd641a1c6a84bd69643da704ff98594.img,xvda,w','file:/OVS/Repositories/6e7c7109c1bc4ebba279f84e595e0b27/VirtualDisks/d349fd420a1e49459118e6a6fcdbc2a4.img,xvdb,w','file:/OVS/Repositories/6e7c7109c1bc4ebba279f84e595e0b27/VirtualDisks/8ac470eeb8704aab9a8b3adedf1c3b04.img,xvdc,w','file:/OVS/Repositories/6e7c7109c1bc4ebba279f84e595e0b27/VirtualDisks/333e7ed2850a441ca4d2461044dd0f7c.img,xvdd,w']

/EXAVMIMAGES/GuestImages/user_domain_hostnameディレクトリ内にある4つの".img"ファイルをリストできます。

ls /EXAVMIMAGES/GuestImages/user_domain_name/*.img

/EXAVMIMAGES/GuestImages/user_domain_name/System.img
/EXAVMIMAGES/GuestImages/user_domain_name/grid12.1.0.2.2.img
/EXAVMIMAGES/GuestImages/user_domain_name/db12.1.0.2.2-3.img
/EXAVMIMAGES/GuestImages/user_domain_name/pv1_vgexadb.img

この場合、次のコマンドを使用して、4つのシンボリック・リンク(dbm01db08vm01はユーザー・ドメインのホスト名)を作成できます。

# ln -s /EXAVMIMAGES/GuestImages/dbm01db08vm01/System.img $(grep ^disk /EXAVMIMAGES/GuestImages/dbm01db08vm01/vm.cfg|awk -F":" '{print $2}'|awk -F"," '{print $1}'|awk -F"/" '{print $6}')

# ln -s /EXAVMIMAGES/GuestImages/dbm01db08vm01/grid12.1.0.2.2.img $(grep ^disk /EXAVMIMAGES/GuestImages/dbm01db08vm01/vm.cfg|awk -F":" '{print $3}'|awk -F"," '{print $1}'|awk -F"/" '{print $6}')

# ln -s /EXAVMIMAGES/GuestImages/dbm01db08vm01/db12.1.0.2.2-3.img $(grep ^disk /EXAVMIMAGES/GuestImages/dbm01db08vm01/vm.cfg|awk -F":" '{print $4}'|awk -F"," '{print $1}'|awk -F"/" '{print $6}')

# ln -s /EXAVMIMAGES/GuestImages/dbm01db08vm01/pv1_vgexadb.img $(grep ^disk /EXAVMIMAGES/GuestImages/dbm01db08vm01/vm.cfg|awk -F":" '{print $5}'|awk -F"," '{print $1}'|awk -F"/" '{print $6}')

10. 各ユーザー・ドメインを起動します。

# xm create /EXAVMIMAGES/GuestImages/user_domain_hostname/vm.cfg

この時点で、すべてのユーザー・ドメインと、それらの中のグリッド・インフラストラクチャおよびデータベース・インスタンスが起動し、残りの他のOVSノードによって形成されたOracle RACクラスタに参加します。

2.13.3 シナリオ3: スナップショット・バックアップからのユーザー・ドメインのリストアおよびリカバリ

失ったまたは損傷したユーザー・ドメイン内のファイルを、ユーザー・ドメイン内で作成したスナップショット・ベースのユーザー・ドメイン・バックアップを使用してリストアするには、次の手順を使用します。ユーザー・ドメイン・バックアップは「方法2: ユーザー・ドメイン内からユーザー・ドメインをバックアップする」の手順を使用して作成したものです。

1. rootユーザーとしてユーザー・ドメインにログインします。

2. バックアップNFSサーバーをマウントし、損傷または紛失が発生したファイルをリストアします。

# mkdir -p /root/mnt

# mount -t nfs -o ro,intr,soft,proto=tcp,nolock nfs_ip:/location_of_backup /root/mnt

3. 損傷または紛失が発生したファイルをバックアップからステージング領域に抽出します。

抽出されたファイルが保持されるように、ステージング領域を準備します。これには、バックアップLVM LVDbSys2を使用できます。

# mkdir /backup-LVM

# mount /dev/mapper/VGExaDb-LVDbSys2 /backup-LVM

# mkdir /backup-LVM/tmp_restore

# tar -pjxvf /root/mnt/tar_file_name -C /backup-LVM/tmp_restore absolute_path_of_file_to_be_restored

4. 必要に応じて、損傷または紛失が発生したファイルを一時ステージング領域からリストアします。

5. ユーザー・ドメインを再起動します。

2.14 Oracle Linuxデータベース・サーバーの更新

Oracle Exadata Storage Server Softwareリリース11.2.3.1.0以上では、データベース・サーバーの更新手順で、データベース・オペレーティング・システムおよびファームウェアの更新配信にUnbreakable Linuxネットワーク(ULN)を使用します。Exadata Storage Server Softwareリリース12.1.2.2.0以上では、patchmgrを実行して更新をオーケストレートできます。

更新は、複数のrpmsで配信されます。dbnodeupdate.shユーティリティを使用して、更新を適用します。ユーティリティは、次のタスクを実行します。

- データベース・サーバーがLogical Volume Manager (LVM)構成の場合、ビルトインdbserver_backup.shスクリプトを使用して、サーバーの更新前にオペレーティング・システムをホストするファイル・システムのバックアップを実行します。

- データベース、Grid Infrastructureスタック、Oracle Enterprise Manager Cloud Controlエージェントおよび潜在的なマウントされていないリモート・マウントの停止を含む、準備、更新および承認手順のすべてを自動化します。

- 既知の問題に対する最新のベスト・プラクティスおよび回避策を組み込みます。

- 更新の成功を確認してOracleバイナリを再リンクし、Oracleスタックを起動します。

ULNを使用できない環境のために、Oracle Exadata Storage Server Softwareのリリースごとに、ISOリポジトリが用意されています。

dbnodeupdate.shユーティリティはMy Oracle Supportノート1553103.1から入手できます。ユーティリティは、すべての世代のハードウェア、Oracle Virtual Server (dom0)およびExadata Virtual Machines (domU)を実行するOracle Exadataデータベースをサポートしています。dbnodeupdate.shユーティリティは、Oracle Linux 5からOracle Linux 6への更新もサポートしています。Oracle Exadata Storage Server SoftwareパッチのREADMEファイルには、そのパッチが適用される世代のハードウェアが指定されています。常にサポート・ノートを確認して、最新リリースのユーティリティを更新に使用するようにしてください。

注意:

ISOイメージ・メソッドは、ローカルULNミラーを完全に代替するものではありません。ISOイメージには、Oracle Exadataチャンネル・コンテンツのみが含まれます。他のULNチャンネルの別のコンテンツは、ISOイメージに含まれません。使用する環境が他のLinuxパッケージを使用し、更新にOracle Exadataチャンネルが含まれない場合、必要に応じてそのパッケージを、ULNチャンネルを使用して更新する必要があります。

この項では、次の項目について説明します。

- データベース・サーバーの更新のパス

- Oracle Linuxデータベース・サーバーの更新の概要

- Oracle Exadataチャンネル・コンテンツでのyumリポジトリの準備と設定

- データベース更新時の停止時間の短縮

- リリース11.2.3.n.nまたは12.1.n.n.nにパッチ適用またはイメージ化を以前にしているデータベース・サーバーの更新

- リリース11.2.2.4.2を実行中のデータベース・サーバーの更新

- データベース・サーバー上のローリング・バック更新

- patchmgrによるデータベース・ノードの更新

- sudoによるdbnodeupdate.shおよびpatchmgr (およびdbnodeupdateオーケストレーション)の実行

関連トピック

- patchmgrによるデータベース・ノードの更新

- dbnodeupdate.shおよびdbserver.patch.zip: DBNodeUpdateユーティリティおよびpatchmgrを使用したExadata Database Server Softwareの更新(My Oracle SupportのドキュメントID 1553103.1)

2.14.1 データベース・サーバーの更新のパス

Oracle Linux 5.5以上およびOracle Exadata Storage Server Softwareリリース11.2.2.4.2以上を実行しているデータベース・サーバーは、dbnodeupdate.shユーティリティを使用してデータベース・サーバーを更新します。

Oracle Exadata Storage Server Softwareリリース11.2.2.4.2より前のリリースを実行しているOracle Linuxデータベース・サーバーは、dbnodeupdate.shユーティリティを使用して、最初にOracle Linux 5.5およびOracle Exadata Storage Server Software 11.2.2.4.2以上に更新する必要があります。

次の表に、Oracle Exadata Storage Server SoftwareおよびOracle Linuxのリリース別の、データベース・サーバーの更新用のパスを示します。

注意:

データベース・サーバーのuname -rコマンドの出力に、リリース2.6.18-128.1.16.0.1以前のカーネル・リリースが表示される場合、データベース・サーバーはOracle Linux 5.3で実行しています。

表2-8 データベース・サーバーの更新パス

現在インストールされているOracle Exadata Storage Server Softwareリリース

現在インストールされているOracle Linuxリリース

推奨アクション

リリース11.2.2.4.2以上

リリース5.5以上

「Oracle Linuxデータベース・サーバーの更新の概要」の説明に従い、ターゲット・リリースを更新します。

リリース11.2.2.4.2より前。

リリース5.5以上

1. パッチREADMEの8項の手順に従い、パッチ13513611を使用して、データベース・サーバーをリリース11.2.2.4.2に更新してください。

2. 「Oracle Linuxデータベース・サーバーの更新の概要」の説明に従い、それ以降のリリースに更新します。

リリース11.2.2.4.2より前

リリース5.5より前

1. My Oracle Supportノート1284070.1を使用して、リリース11.2.3.2.0に更新してください。

2. 「Oracle Linuxデータベース・サーバーの更新の概要」の説明に従い、それ以降のリリースに更新します。

注意:

- 非UEKカーネルをリリース11.2.3.2.0以上で実行しているOracle Exadataデータベース・サーバーの場合、dbnodeupdate.shユーティリティを使用してリリース11.2.3.3.0より前に更新すると、データベース・サーバーは非UEKカーネルのままです。

- UEKカーネルをリリース11.2.3.3.0より前のリリースで使用する必要があり、現在非UEKカーネルを使用している場合、dbnodeupdate.shユーティリティを使用して更新を実行し、更新の終了後、手動でUEKに変換します。詳細は、My Oracle Supportノート1524411.1を参照してください。

- Oracle Exadatarリリース11.2.3.3.0から、UEKカーネルのみがサポートされています。このため、dbnodeupdate.shユーティリティは、11.2.3.3.0以上に更新する場合、非UEKシステムを直接UEK2カーネルに更新します。

- My Oracle Supportノート888828.1に説明されているように、Oracle Exadata Database Serverの通常の更新が適用できるのは、ターゲット・リリースの日付スタンプが現在実行中のリリースの日付スタンプより新しい場合のみです。ターゲット・リリースよりも新しい日付スタンプのリリースを実行しているイメージからの更新はブロックされます。
例: Exadataリリース12.1.2.1.0は、リリース番号に基づいた12.1.1.1.2よりも新しく思えますが、12.1.1.1.2.1 (日付スタンプが150411)の日付スタンプは、12.1.2.1.0 (141206)よりも新しいため、12.1.1.1.2.150411から12.1.2.1.0.141206.1の更新はブロックされます。このような状況では、同じメジャー・リリースで日付スタンプが新しいメンテナンス・リリースに更新する必要があります。

個々のExadata以外のオペレーティング・システム・パッケージの更新

個々のExadata以外のオペレーティング・システム・パッケージを更新する場合は、システム用のOracle Linuxの「最新の」チャネルのローカルyumミラーを設定し、yum update <packagename>を実行することができます。

他のパッケージも同様に引き込まれる可能性があることに常に注意してください。

まずexadata-sun-computenode-exact rpmを削除する必要がある場合があります。

rpm -e exadata-sun-computenode-exact

ローカルyumミラーがない場合は、ULNまたは公開yumから個々のパッケージをダウンロードし、次のコマンドを使用して特定のパッケージを更新します。

rpm -uvh package-names

注意:

パッケージ名を指定せずにyum updateコマンドを実行すると、多くのパッケージおよび依存関係が引き込まれ、意図しない更新が行われて、Exadataシステムが使用できなくなり、次のExadataリリースへの更新が困難または不可能になる可能性があるので、実行しないでください。

関連トピック

- Exadata 11.1.3.3、11.2.1.2.x、11.2.2.2.x、11.2.2.3.[0-5]、11.2.2.4.[0-1]用のExadata 11.2.2.4.2リリースおよびパッチ(13513611)。(My Oracle SupportのドキュメントID 1388400.1)

- セル上と一致させるためのデータベース・ホストの主なソフトウェア・コンポーネントの更新(My Oracle SupportのドキュメントID 1284070.1)

- 前もって非UEKカーネルを使用するためのExadataデータベース・サーバーを選択した後でUEKカーネルを使用するためのExadataデータベース・サーバーを再構成する(My Oracle SupportのドキュメントID 1524411.1)

- Exadata Database MachineおよびExadata Storage Serverのサポートされているバージョン(My Oracle SupportのドキュメントID 888828.1)

- データベース・サーバー・パッケージのカスタマイズとMinimumおよびExact依存性の理解

- 一般的なExadataセキュリティ・スキャン結果への応答(My Oracle SupportのドキュメントID 1405320.1)

2.14.2 Oracle Linuxデータベース・サーバーの更新の概要

このトピックでは、Oracle Linuxデータベース・サーバーを新しいリリースに更新する手順の概要について説明します。

この項の情報は、次の要件を満たしているデータベース・サーバーに適用されます。

- Oracle Exadata Storage Server Software 11gリリース2 (11.2) 11.2.2.4.2以上がインストールされている。

- Oracle Linux 5.5以上がインストールされている。Oracle Exadata Storage Server Software 11g2 (11.2) 11.2.3.1.0以上がインストールされている場合、この要件は満たされます。

データベース・サーバーがこれらの要件を満たしていない場合、表2-8を参照し、必須の手順を実行して要件を満たします。

次の手順では、Oracle Linuxデータベース・サーバーを新しいリリースに更新する方法について説明します。

1. ターゲット・リリースのOracle Exadataチャンネル・コンテンツでyumリポジトリを準備および設定します。リリースで使用するULNチャンネル名は、パッチのそれぞれのREADMEファイルにリストされています。ULNチャンネルを使用しない場合、ISOイメージを使用できます。

2. Oracle Exadata Storage Server Softwareのリリース別に、前提条件チェック、更新およびパッチ適用後の手順を実行します。

- Oracle Exadata Storage Server Softwareリリース11.2.3.1.0以上で実行するOracle Databaseの場合、「リリース11.2.3.n.nまたは12.1.n.n.nにパッチ適用またはイメージ化を以前にしているデータベース・サーバーの更新」を参照して、手順を実行してください。

- Oracle Exadata Storage Server Softwareリリース11.2.2.4.2を実行するOracle Databaseの場合、「リリース11.2.2.4.2を実行中のデータベース・サーバーの更新」を参照して、手順を実行してください。

関連トピック

- Oracle Exadataチャンネル・コンテンツでのyumリポジトリの準備と設定

- データベース・サーバー上のローリング・バック更新

2.14.3 Oracle Exadataチャンネル・コンテンツでのyumリポジトリの準備と設定

次のメソッドを使用して、Oracle Exadataチャンネル・コンテンツを含むyumリポジトリを作成し、使用します。dbnodeupdate.shユーティリティで、yumリポジトリを使用してOracle Exadata Database Machine内のデータベース・サーバーを更新します。次の各項で、それぞれの方法について詳しく説明します。

- ULN Oracle Exadataチャンネルのローカル・ミラーの別個のサーバー上への設定

- ULN Oracle ExadataチャンネルのISOイメージのダウンロードおよび圧縮されたイメージの場所のdbnodeupdate.shユーティリティへの手渡し

- ISOイメージをダウンロードしてWebサーバーで使用できるようにする

2.14.3.1 ULN Oracle Exadataチャンネルのローカル・ミラーの別個のサーバー上への設定

このメソッドは、次の条件が満たされた場合に推奨されます。

- 更新するデータベース・サーバーの数が多い。

- すべてのデータベース・サーバーから、単一のリポジトリ・サーバーにアクセス可能である。

- 別のLinuxサーバーにULNミラーを構築するインフラストラクチャが存在する。

- データベース・サーバーで、ほかのULNチャンネルからの更新が必要なカスタマイズされたソフトウェアを使用している。

ミラーは、別個のLinuxサーバーで、更新対象のULNからダウンロードしたチャンネル・データおよびOracle Exadataリリースを保持します。データベース・サーバーは、ローカル・ミラー(リポジトリ)に接続して更新を取得します。

注意:

データベース・サーバーを、ローカルULNミラーとして使用することはできません。そのように使用すると、ULNがリポジトリ構築のために必要とするパッケージと、データベース・サーバーのインストールまたは更新のパッケージとの間に、依存性の競合が生じ、システム障害が発生する場合があります。別々のサーバーが使用できない場合、ISOイメージ・メソッドを使用してください。

ローカル・リポジトリの初回の設定の際に必要な追加のLinuxサブスクリプションは、リポジトリのホスト・サーバーで使用しているEnterprise LinuxまたはOracle Linuxのリリースによって異なります。サーバーは、次のような追加ULNチャンネルにサブスクライブして、リポジトリを構築する必要があります。

- 64-bit Enterprise Linux 4システムの場合:
el4_x86_64_latestおよびel4_x86_64_addons。

- 64-bit Enterprise Linux 5システムの場合:
el5_x86_64_latestおよびel5_x86_64_addons。

- 64-bit Oracle Linux 5システムの場合:
ol5_x86_64_latestおよびel5_x86_64_addons。

- 64-bit Oracle Linux 6システムの場合:
ol6_x86_64_latestおよびol6_x86_64_addons。

2.14.3.1.1 ローカルULNミラーの作成および維持

この手順では、ローカルULNミラーをyumリポジトリとして作成および維持する方法について説明します。

1. 「ローカルUnbreakable Linux Networkミラーの作成方法」の説明に従って、前提条件およびサーバー設定手順を確認してください。

2. Unbreakable Linux NetworkにあるULNにログインします。

3. 「システム」タブをクリックします。

4. 登録済のyumリポジトリ・サーバーに進みます。

5. 「サブスクリプションの管理」をクリックします。

6. Oracle ExadataパッチのREADMEで名前を付けたチャンネルを追加します。たとえば、exadata_dbserver_12.1.1.1.0_x86_64_baseです。

注意:

サブスクライブするOracle Exadataチャンネルは、更新するOracle Exadata Storage Server Softwareのリリースにより異なります。リリース別の詳細については、パッチのREADMEファイルを参照してください。

7. 「保存」をクリックします。

関連トピック

- ローカルUnbreakable Linux Networkミラーの作成方法

2.14.3.1.2 ローカルULNミラーの確認

前の項で説明したyumミラーを作成する手順では、ローカル・ミラーをyum mirror creation procedure described in the previous section provides a script that is used to populate the local mirror.スクリプトを実行すると、ULNからローカル・リポジトリへのrpmsダウンロードが開始します。

WebサーバーのDocument Rootディレクトリがディスク上のこの場所を指すように構成すると、HTTP Webサーバーを使用するOracle Exadata Linux Database Serversに対して、Oracle Exadataチャンネル・コンテンツが使用可能になります。

dbnodeupdate.shユーティリティに対するリポジトリの場所として指定されたURLは、次のグラフィックに示すように、repodataディレクトリと常に同じレベルです。

次のコマンドを使用して、rootユーザーとしてのリポジトリを確認します。

[root@dm01 ]# ./dbnodeupdate.sh -u -l http://yum-repo/yum/EngineeredSystems/exadata/dbserver/12.1.1.1.0/base/x86_64/ -v

注意:

IPv6アドレスのみをリスニングしているyumリポジトリにアクセスするには、データベース・ノードでExadataリリース12.1.2.2.0以降が実行されている必要があります。

2.14.3.2 ULN Oracle ExadataチャンネルのISOイメージのダウンロードおよび圧縮されたイメージの場所のdbnodeupdate.shユーティリティへの手渡し

リリース11.2.3.1.0以上では、Oracle ExadataチャンネルのISOイメージを、My Oracle Supportからダウンロードするパッチとして入手できます。圧縮されたファイルの場所は、dbnodeupdate.shユーティリティへ、直接手渡されます。このメソッドは、次の条件が満たされた場合に推奨されます。

- リポジトリ・サーバーとして使用可能な別のサーバーが存在しない。

- 追加ULNチャンネルからの更新を必要とするカスタマイズされたソフトウェアが、データベース・サーバーに存在しない。

- 簡略化されたメソッドが推奨される。

注意:

ISOイメージ・メソッドは、ローカルULNミラーを完全に代替するものではありません。ISOイメージには、Oracle Exadataチャンネル・コンテンツのみが含まれます。他のULNチャンネルの別のコンテンツは、ISOイメージに含まれません。使用する環境が他のLinuxパッケージを使用し、更新にOracle Exadataチャンネルが含まれない場合、必要に応じてそのパッケージを、ULNチャンネルを使用して更新する必要があります。

次の手順では、ISOイメージをダウンロードおよび確認する方法について説明します。

1. 更新対象のOracle ExadataリリースのISOイメージを、My Oracle Supportからダウンロードします。

2. 圧縮されたファイル形式のISOイメージを、更新するすべてのデータベース・サーバーにコピーします。圧縮ファイルのパスは、dbnodeupdate.shユーティリティへの引数として使用します。ファイルを解凍しないでください。

3. 次のコマンドを使用して、rootユーザーとしてのリポジトリを確認します。

[root@dm01 ]# ./dbnodeupdate.sh -u -l                     \
/u01/dbnodeupdate/p17997668_121110_Linux-x86-64.zip -v

2.14.3.3 ISOイメージをダウンロードしてWebサーバーで使用できるようにする

リリース11.2.3.1.0以上では、Oracle ExadataチャンネルのISOイメージを、My Oracle Supportからダウンロードするパッチとして入手できます。これは、すべてのOracle Exadata Database Machineデータベース・サーバーにHTTP接続可能なWebサーバーにダウンロード、解凍および設定できます。リリース別のパッチ情報へのリンクは、My Oracle Supportノート888828.1を参照してください。このメソッドは、次の条件が満たされた場合に推奨されます。

- 更新するデータベース・サーバーの数が多い。

- すべてのデータベース・サーバーから、単一のリポジトリ・サーバーにアクセス可能である。

- 追加ULNチャンネルからの更新を必要とするカスタマイズされたソフトウェアが、データベース・サーバーに存在しない。

次の手順では、Oracle Exadataチャンネル・コンテンツのISOイメージを、Apache HTTPサーバーを実行するLinuxベースのサーバーで使用する方法について説明します。それ以外のオペレーティング・システムも使用できますが、このドキュメントでは手順を説明しません。この手順では、ISOイメージは/u01/app/oracle/stageディレクトリにコピーされ、Webサーバー・ドキュメント内のDocument Rootエントリは/var/www/htmlです。

注意:

別のサーバーをWebサーバーとして使用することをお勧めします。Oracle Exadata Database Machine内のデータベース・サーバーを使用できますが、httpdパッケージはOracle Exadataパッケージの標準ではありません。データベース・サーバーを使用する場合、次の手順を実行する前に、Apache HTTPサーバーがサーバーにインストールされている必要があります。

1. 更新対象のOracle Exadataリリースの圧縮ISOイメージを、My Oracle Supportからダウンロードします。この手順では、リリース12.1.1.1.0への更新を説明しますが、リリース11.2.3.1.0以上にも適用されます。

2. ISOイメージをWebサーバーへコピーします。

3. 次のコマンドを使用して、ISOイメージ・マウント・ポイントをrootユーザーとして作成します。

[root@dm01 ]# mkdir -p /var/www/html/yum/unknown/EXADATA/dbserver/12.1.1.1.0/base

4. 次のコマンドを使用して、ISOイメージをrootユーザーとして、解凍およびマウントします。

[root@dm01 ]# cd /u01/dbnodeupdate
[root@dm01 ]# unzip p17997668_121110_Linux-x86-64.zip
[root@dm01 ]# mount -o loop /u01/dbnodeupdate/121110_base_repo.iso /var/www/html/yum/unknown/EXADATA/dbserver/12.1.1.1.0/base

5. 次の手順に従い、httpdサービスをrootユーザーとして起動します。

a. 次のコマンドを使用して、httpdサーバーを追加し有効にします。

[root@dm01 ]# chkconfig --add httpd
[root@dm01 ]# chkconfig httpd on

注意:

httpdサービスの自動起動を有効にしておく必要はありません。

b. 次のコマンドを使用してhttpdサービスを起動します。

[root@dm01 ]# service httpd start

c. 次のコマンドを使用して、httpdサービスが有効であることを確認します。

[root@dm01 ]# chkconfig --list httpd

6. Webブラウザを使用して、接続したリポジトリURLを識別しテストします。リポジトリURLの例を、次に示します。

http://yum-repo/yum/unknown/EXADATA/dbserver/12.1.1.1.0/base/x86_64/

7. 次のコマンドを使用して、rootユーザーとしてのリポジトリを確認します。

[root@dm01 ]# ./dbnodeupdate.sh -u -l  \
http://yum-repo/yum/EngineeredSystems/exadata/dbserver/12.1.1.1.0/base/x86_64/ -v

2.14.4 データベース更新時の停止時間の短縮

更新を開始する前に、バックアップを作成し前提条件チェックを実行して、停止時間を短くします。

実際の更新の際に、バックアップはスキップできます。バックアップは、リモートのネットワーク、NFSなどのマウントがアクティブではない場合に可能です。実際の更新の停止時間を開始する前日に、必ず前提条件チェックを実行する必要があります。

注意:

Logical Volume Manager (LVM)が有効なシステムを、Oracle Linux 5からOracle Linux 6に更新する場合、バックアップは実際の更新の一部として実行されます。バックアップをスキップすることはできません。

すべての警告および障害を、ダウンタイムの前に解決する必要があります。データベース・サーバーの更新の際、次の点に注意してください。

- リリース11.2.3.n.nまたは12.1.n.n.nにパッチを適用する、またはイメージ化を以前にしているデータベース・サーバーを更新する場合:
Minimum依存性の障害のみが発生し、現在のイメージをOracle Linux 6への更新の前にバックアップしないと、更新が進行しません。Minimum依存性のチェックが失敗した場合、/var/log/cellosディレクトリのdbnodeupdate.logファイルを参照して、依存性の障害が発生した原因を確認してください。依存性チェックは、Oracle Linux 6へ更新する場合は実行しません。警告および障害を解決してから、前提条件チェックを再開します。

- リリース11.2.2.4.2を実行中のデータベース・サーバーの更新
リリース11.2.2.4.2から更新する場合、依存性のチェックは実行されず、obsolete.lstおよびexclusion.lstリスト機能は有効ではありません。警告および障害を解決してから、前提条件チェックを再開します。

関連トピック

- データベース・サーバー・パッケージのカスタマイズとMinimumおよびExact依存性の理解

2.14.4.1 データベース・サーバーの更新前のバックアップおよび前提条件チェックの実行

サーバーを更新する数日前に、データベース・サーバーをバックアップし、前提条件をチェックすることができます。次の手順では、アクティブ・システム・パーティションをバックアップして、前提条件を実行する方法について説明します。

1. 次のコマンドを実行して、バックアップを作成します。

[root@dm01 ]# ./dbnodeupdate.sh -u -l repo -b

このコマンドで、repoはULNミラーのHTTPの場所または圧縮されたISOイメージの場所です。

注意:

バックアップを事前に作成すると、実際の更新の際、dbnodeupdate.shユーティリティ内のバックアップ手順をスキップすることができます。次のコマンドを使用して、バックアップ作成をスキップします。

[root@dm01 ]# ./dbnodeupdate.sh -u -l repo -n

このコマンドで、repoはULNミラーのHTTPの場所または圧縮されたISOイメージの場所です。

LVMが有効なシステムを、Oracle Linux 5からOracle Linux 6に更新する場合、バックアップは実際の更新の一部として実行されます。-nフラグは無視されます。

2. 次のコマンドを使用して、前提条件チェックを実行します。

[root@dm01 ]# ./dbnodeupdate.sh -u -l  repo -v

このコマンドで、repoはULNミラーのHTTPの場所または圧縮されたISOイメージの場所です。

2.14.5 リリース11.2.3.n.nまたは12.1.n.n.nにパッチ適用またはイメージ化を以前にしているデータベース・サーバーの更新

dbnodeupdate.shユーティリティを使用して、リリース11.2.3.n.nおよびリリース12.1.n.n.nを実行するデータベース・サーバーを更新します。この項の手順では、データベース・サーバーがリリース11.2.2.4.2以上を実行し、更新がローカルULNミラーまたはローカルISOイメージとして使用可能であることを前提にしています。

注意:

dbnodeupdate.shユーティリティを使用する場合、次の2つのコンポーネントが必要です。

- パッチのULNミラーまたは圧縮ISOファイル

- dbnodeupdate.shユーティリティ

この項では、次の項目について説明します。

- データベース・サーバー・パッケージのカスタマイズとMinimumおよびExact依存性の理解

- dbnodeupdate.shユーティリティの実行の準備

- 廃止パッケージ・リスト、除外パッケージ・リストおよび自動パッケージ削除の確認

- 更新モードでのdbnodeupdate.shユーティリティの実行

関連トピック

- Oracle Exadataチャンネル・コンテンツでのyumリポジトリの準備と設定

- dbnodeupdate.shユーティリティの実行の準備

- データベース更新時の停止時間の短縮

2.14.5.1 データベース・サーバー・パッケージのカスタマイズとMinimumおよびExact依存性の理解

システム管理者は、既存のOracle Exadataで供給されたパッケージに追加のパッケージをインストールして、より新しいリリースに更新することで、オペレーティング・システムをカスタマイズできます。この場合、カスタマイズにより、Oracle Exadata Storage Server Software機能を損なわないようにしてください。

注意:

Oracle Support Servicesからの指示がないかぎり、カーネルおよびInfiniBandパッケージを更新または削除しないでください。

Oracle Exadata Storage Server Softwareリリース11.2.3.3.0以前に更新する場合、dbnodeupdate.shユーティリティを使用してyum更新を実行すると、MinimumおよびExact依存性が発生します。このような依存性は前提条件のチェックおよび更新で働くため、システムをカスタマイズする際に、管理者がExadataリリースを元の状態に忠実またはより近い状態を保つことを助けます。

依存性は、次のように、exadata-sun-computenode-exact rpmおよびexadata-sun-computenode-minimum rpmにより成立します。

- exadata-sun-computenode-exact rpmは、Oracleが提供するパッケージの特定のリリースが更新の際に使用できるようにします。

- exadata-sun-computenode-exact rpmは、Oracleが提供するパッケージの特定のリリースまたはそれより後のリリースが更新の際に使用できるようにします。

Exact依存性がexadata-sun-computenode-exact rpmで成立すると、Oracle Exadataパッケージが完全に同一のリリースであるため、あたかもシステムが新しいリリースに対してイメージが新たに作られたようになります。

exadata-sun-computenode-minimum rpmにより、Minimum依存性が成立し、すべてのパッケージがインストール済であると同時に、それより後のバージョンのパッケージも許容されます。

デフォルトで、dbnodeupdate.shユーティリティは、次のリリースに更新する際に、Exact依存性が成立するように更新します。Exact依存性が競合して成立できない場合、ユーティリティはexadata-sun-computenode-minimum rpmを適用し、Minimum依存性を成立させて更新します。Exact依存性の欠如または未更新は許容され、問題にはなりません。システムをExact依存性で更新する場合、すべての障害を解決する必要があります。dbnodeupdate.logファイルをチェックして、競合するパッケージを確認し、それらを丁寧に取り除いてからdbnodeupdate.shユーティリティを再び実行します。

次のコマンドを使用して、リリースで成立したExact依存性を確認します。

[root@dm01 ]# rpm -qR exadata-sun-computenode-exact   | grep '=' | grep -v '('

コマンドの出力に、Exact依存性が表示されます。

たとえば、Oracle Exadata Storage Server Softwareリリース12.1.1.1.1の出力では、sendmailパッケージは8.13.8-8.1.el5_7と一致する必要があります。

次のコマンドを使用して、リリースで成立したMinimum依存性を確認します。

[root@dm01 ]# rpm -qR exadata-sun-computenode-minimum  | grep '>=' | grep -v '('

コマンドの出力に、Minimum依存性が表示されます。

たとえば、Oracle Exadata Storage Server Softwareリリース12.1.1.1.1の出力では、minimumのsendmailパッケージはsendmail >= 8.13.8-8.1.el5_7です。つまり、Exact依存性が成立しない場合、後のリリースのsendmailを使用できます。

dbnodeupdate.shユーティリティの確認画面には、更新で成立する依存性が常に表示されます。Exact依存性およびMinimum依存性のいずれも適用できない場合、更新を続行することはできません。そのような場合、dbnodeupdate.logファイルを参照して、依存性の障害の原因を特定します。失敗した依存性を取り除いた後、dbnodeupdate.shユーティリティを再び実行して依存性を検証し、少なくともMinimum依存性が成立することを確認します。

予定されたメンテナンスの数日前に、-vフラグを使用してdbnodeupdate.shユーティリティを実行し、前提条件を確認することをお薦めします。dbnodeupdate.shユーティリティ・ログ・ファイルに、更新を実行して停止時間が発生する前に解決するべき依存性の問題が報告されます。前提条件チェック中または更新の開始前に、依存性エラーが発生した場合、次のようにして問題を解決します。

- 要件またはyumエラーを解析します。リリース11.2.3.1.0以上から更新する場合、画面に表示されるファイルを確認します。これには、/var/log/cellos/dbnodeupdate.logファイルが含まれます。リリース11.2.2.4.2から更新する場合、/var/log/exadata.computenode.post.logファイル、/var/log/exadata.computenode.post.logファイルおよび/var/log/cellos/bootstrap.uln.logファイルを確認してください。

- 内容によっては、依存問題または障害の原因となるrpmパッケージを、アンインストール、インストールまたは更新する必要があります。dbnodeupdate.logファイルを参照して、失敗した依存性を確認してください。

- dbnodeupdate.shユーティリティを使用して、更新を実行してください。すでにバックアップが作成されている場合、-nフラグのみを使用して、バックアップをスキップします。デフォルトで、同一のイメージに対する既存のバックアップは上書きされます。
LVMが有効なシステムを、Oracle Linux 5からOracle Linux 6に更新する場合、バックアップは実際の更新の一部として実行されます。-nフラグは無視されます。

- 更新後にアンインストールしたカスタムrpmパッケージを、再びインストールします。

注意:

セキュリティ要件により、使用するシステム上の個々のパッケージを手動で更新する場合があります。この時、exadata-sun-computenode-exactで成立した依存性が競合することがあります。これを解決するために、exadata-sun-computenode-exactパッケージをアンインストールして、新しいパッケージをインストールすることができます。これを行うには、次のコマンドを実行します。

[root@dm01 ]# rpm -e exadata-sun-computenode-exact

後のOracle Exadata更新により新しいパッケージが含まれる場合、Exact依存性がdbnodeupdate.shユーティリティにより自動的に再インストールされます。

exadata-sun-computenode-minimumパッケージを削除することは、サポートされていません。Oracle Support Servicesからの指示がないかぎり、パッケージに対して強制的にrpm -Uvh --nodepsコマンドを使用しないでください。

2.14.5.2 dbnodeupdate.shユーティリティの実行の準備

dbnodeupdate.shユーティリティは、My Oracle Supportの「dbnodeupdate.sh and dbserver.patch.zip: Updating Exadata Database Server Software using the DBNodeUpdate Utility and patchmgr」(ドキュメントID 1553103.1)から入手できます。次の手順では、サーバー上でユーティリティをダウンロードおよび準備する方法について説明します。

1. dbnodeupdateパッケージ・ファイルをMy Oracle Supportからダウンロードします。

2. zipファイルを、更新するデータベース・サーバーの/u01/dbnodeupdateディレクトリに置きます。

注意:

この手順により、ULNリポジトリが使用できます。これは、「Oracle Exadataチャンネル・コンテンツでのyumリポジトリの準備と設定」で説明するオプションの1つです。

3. dbnodeupdateパッケージ、p16486998_12xxxx_Linux-x86-64.zipを、rootとして次のコマンドを使用して解凍します。

[root@dm01 ]# unzip p16486998_12xxxx_Linux-x86-64.zip

dbupdate-helpers.zipファイルを解凍しないでください。

注意:

SUDO権限のあるユーザーは、SUDOを使用してdbnodeupdate.shユーティリティを実行できます。

2.14.5.3 廃止パッケージ・リスト、除外パッケージ・リストおよび自動パッケージ削除の確認

リリース11.2.3.3.0以上に更新すると、データベース・サーバー上のパッケージの一部が廃止されて使用できません。データベース・サーバーの更新中、dbnodeupdate.shユーティリティにより、確認画面上に除外されたrpmリストおよび廃止されたrpmリストが表示されます。確認画面の例を、次に示します。この例では、除外リストはまだユーザーにより作成されていません。

Active Image version   : 11.2.3.2.1.130302
Active Kernel version  : 2.6.32-400.21.1.el5uek
Active LVM Name        : /dev/mapper/VGExaDb-LVDbSys2
Inactive Image version : 11.2.3.2.1.130109
Inactive LVM Name      : /dev/mapper/VGExaDb-LVDbSys1
Current user id        : root
Action                 : upgrade
Upgrading to           : 11.2.3.3.0.131014.1
Baseurl                : http://mynode.us.example.com/yum/exadata_dbserver_11.2.3.3.0_x86_64_base/x86_64/ (http)
Create a backup        : Yes
Shutdown stack         : No (Currently stack is up)
RPM exclusion list     : Not in use (add rpms to /etc/exadata/yum/exclusion.lst and restart dbnodeupdate.sh)
RPM obsolete list      : /etc/exadata/yum/obsolete.lst (lists rpms to be removed by the update)
: RPM obsolete list is extracted from exadata-sun-computenode-11.2.3.3.0.131014.1-1.x86_64.rpm
Logfile                : /var/log/cellos/dbnodeupdate.log (runid: 021213024645)
Diagfile               : /var/log/cellos/dbnodeupdate.021213024645.diag
Server model           : SUN FIRE X4170 M2 SERVER
Remote mounts exist    : Yes (dbnodeupdate.sh will try unmounting)
dbnodeupdate.sh rel.   : 2.20 (always check MOS 1553103.1 for the latest release)
Automatic checks incl. : Issue - Yum rolling update requires fix for 11768055 when Grid Infrastructure is below 11.2.0.2 BP12
Manual checks todo     : Issue - Database Server upgrades to 11.2.2.3.0 or higher may hit network routing issues after the upgrade
Note                   : After upgrading and rebooting run './dbnodeupdate.sh -c' to finish post steps

Continue ? [Y/n]

廃止されるパッケージを確認するには、obsolete.lstファイルの内容を確認し、スクリプトに要求されたらNを入力します。obsolete.lstファイルの場所は確認画面に表示されます。obsolete.lstファイルには、更新中に何もアクションを実行しない限り、削除対象のパッケージのみが表示されます。このリストに手動で追加されたパッケージは無視されます。次はobsolete.lstファイルの例です。

[root@dm01 ]# cat /etc/exadata/yum/obsolete.lst
# Generated by dbnodeupdate.sh runid: 021213024645
at.x86_64
java-*-openjdk
rhino.noarch
jline.noarch
jpackage-utils.noarch
giflib.x86_64
alsa-lib.x86_64
xorg-x11-fonts-Type1.noarch
prelink.x86_64
biosconfig
biosconfig_expat
qlvnictools
ibvexdmtools
opensm.x86_64
ofed-scripts
ibibverbs-devel-static
infiniband-diags-debuginfo
libibverbs-debuginfo
librdmacm-debuginfo
libibumad-debuginfo
libibmad-debuginfo
ibutils-debuginfo
libmlx4-debuginfo
libsdp-debuginfo
mstflint-debuginfo
perftest-debuginfo
qperf-debuginfo
libibcm-debuginfo
compat-dapl-utils.x86_64
compat-dapl.x86_64
dapl-utils.x86_64
dapl.x86_64
libgfortran.x86_64
mdadm.x86_64
mpi-selector.noarch
pygobject2.x86_64
specspo.noarch
time.x86_64
tree.x86_64
unix2dos.x86_64
usbutils.x86_64
words.noarch

obsolete.lstファイルのリストに表示されたパッケージを削除しないようにするには、/etc/exadata/yum/exclusion.lstファイルを作成し、rpm名またはワイルドカードを入力して除外リストにrpmを含めます。

次の例は、除外リストに追加されたパッケージを示します。

[root@dm01 ]# cat /etc/exadata/yum/exclusion.lst
java-*-openjdk

exclusion.lstファイルにエントリを追加し、dbnodeupdate.shユーティリティを再び実行すると、除外リストがユーティリティに検知されます。除外リスト上のrpmパッケージは、obsolete.lstファイルに表示されていますが、exclusion.lstファイル内にリストされたパッケージは更新の際に削除されません。次の確認画面の例では、エントリが追加された後、exclusion.lstファイルが使用中になります。

Active Image version   : 11.2.3.2.1.130302
Active Kernel version  : 2.6.32-400.21.1.el5uek
Active LVM Name        : /dev/mapper/VGExaDb-LVDbSys2
Inactive Image version : 11.2.3.2.1.130109
Inactive LVM Name      : /dev/mapper/VGExaDb-LVDbSys1
Current user id        : root
Action                 : upgrade
Upgrading to           : 11.2.3.3.0.131014.1
Baseurl                : http://mynode.us.example.com/yum/exadata_dbserver_11.2.3.3.0_x86_64_base/x86_64/ (http)
Create a backup        : Yes
Shutdown stack         : No (Currently stack is up)
RPM exclusion list     : In use (rpms listed in /etc/exadata/yum/exclusion.lst)
RPM obsolete list      : /etc/exadata/yum/obsolete.lst (lists rpms to be removed by the update)
: RPM obsolete list is extracted from exadata-sun-computenode-11.2.3.3.0.131014.1-1.x86_64.rpm
Logfile                : /var/log/cellos/dbnodeupdate.log (runid: 021213024900)
Diagfile               : /var/log/cellos/dbnodeupdate.021213024900.diag
Server model           : SUN FIRE X4170 M2 SERVER
Remote mounts exist    : Yes (dbnodeupdate.sh will try unmounting)
dbnodeupdate.sh rel.   : 2.20 (always check MOS 1553103.1 for the latest release)
Automatic checks incl. : Issue - Yum rolling update requires fix for 11768055 when Grid Infrastructure is below 11.2.0.2 BP12
Manual checks todo     : Issue - Database Server upgrades to 11.2.2.3.0 or higher may hit network routing issues after the upgrade
Note                   : After upgrading and rebooting run './dbnodeupdate.sh -c' to finish post steps

Continue ? [Y/n]

注意:

dbnodeupdate.shユーティリティまたはOracle Exadata Storage Server Software更新手順のいずれでも、obsolete.lstファイルにリストされていないrpmパッケージは削除されません。obsolete.lstファイル内にリストされたファイルのみが、exclusion.lstファイルに追加されます。カスタム・パッケージは削除されません。obsolete.lstおよびexclusion.lst機能は、リリース11.2.2.4.2から更新する場合、またはOracle Linux 6に更新する場合、使用できません。

2.14.5.4 更新モードでのdbnodeupdate.shユーティリティの実行

次の手順では、更新モードでdbnodeupdate.shユーティリティを実行する方法を説明します。

1. リポジトリの場所に応じて、次のコマンドのいずれかを使用し、dbnodeupdate.shユーティリティを実行します。

- ローカルULNミラーを使用する場合:

[root@dm01 ]# ./dbnodeupdate.sh -u -l http://my.repository.url/x86_64

- 圧縮されたISOイメージをデータベース・サーバー上で使用する場合:

[root@dm01 ]# ./dbnodeupdate.sh -u -l /u01/my_iso_file_zipped.zip

上記のコマンドで、my_iso_file_zippedは圧縮されたISOファイルの名前です。

注意:

データベースおよびGrid Infrastructureスタックが有効な場合、データベース・サーバーを更新する前に停止する必要があります。-sフラグを更新コマンドに追加すると、dbnodeupdate.shユーティリティにより、更新の最中にスタックが停止します。次にコマンドを示します。

[root@dm01 ]# ./dbnodeupdate.sh -u -l repo -s

2. 次のコマンドを使用してサーバーの再起動が終了したら、完了後の手順を実行して更新を完了します。

[root@dm01 ]# ./dbnodeupdate.sh -c

ユーティリティは、次の完了後の手順に進みます。

注意:

dbnodeupdate.sh -cコマンドの入力時に、更新の実行が継続中の場合があります。この時、ユーティリティはイメージ・ステータスを判別するまで待機します。保留中の更新が有効になるまでの待機中に、システムが再起動することがあります。このような場合、システムがオンラインに戻ってからdbnodeupdate.sh -cコマンドを再び入力します。

2.14.5.4.1 dbnodeupdate.shユーティリティの実行の例

このトピックでは、dbnodeupdate.shユーティリティの使用例を示します。

この例では、次のようになります。

- 現在Oracle Exadata Storage Server Softwareリリース11.2.3.3.1が実行されています(Active Image versionエントリに表示されます)。

- カーネル2.6.39-400.128.17.el5uekが使用されています(Active Kernel version)。

- 現在のアクティブなシステム・パーティションはLVDbSys2です(Active Logical Volume Manager (LVM) name)。

- 更新はリリース12.1.1.1.1.140712に更新されます(Upgrading to)。

- 更新では、圧縮ファイルで提供されたISOイメージを使用します(Iso file)。

dbnodeupdate.shユーティリティの出力に示されるように、次のアクションが実行されます。

- バックアップが作成され(Create a backup)、LVDbSys1に置かれます(Inactive LVM Name)。

- 現在のシステムでは、データベース・スタックが実行されていますが(Shutdown Stack)、-sフラグが指定されています。バックアップおよび更新を継続する前に、スタックを停止します。

- obsolete.lstファイル(RPM obsolete list)では、Oracleの更新の一部として削除されるRPMを指定します。

- exclusion.lstファイル(RPM exclusion list)は提供されません。

- Exact依存性チェックは失敗するため、リリース12.1.1.1.1への更新は、exadata-computenode-minimum RPM依存性のみ可能です。Minimum依存性制限へ更新する場合、競合はありません(Minimum dependencies)。

- dbnodeupdate.shユーティリティ・プロセスのログは、dbnodeupdate.logファイル(Logfile)に添付されます。diagfileファイル(Diagfile)には、更新を開始する前の重要なシステム情報が記載されています。ユーティリティを使用するごとに、diagfileファイルが生成されます。このファイルは、必要に応じてトラブルシューティングに使用されます。

- NFSのようなアクティブ・リモート・ネットワーク・マウントが検知され(Remote mounts exist)、dbnodeupdate.shユーティリティが、マウントを解除しようとします。それが不可能な場合、ユーティリティは進行をブロックしているセッションを表示して、停止します。

- dbnodeupdate.sh rel.エントリは、現在のdbnodeupdate.shリリースを指定します。

- ユーティリティがシステムをチェックし、dbnodeupdate.shユーティリティがOracle Exadataソースおよびターゲット・リリースで識別した既知の問題点が、スクリーン上のリストに表示されます。最初に、ユーティリティで自動的に解決される問題が表示され、次に、システム上で実行する必要がある手動チェックが表示されます。

例2-1 dbnodeupdate.shユーティリティの実行

[root@dm01 ]# ./dbnodeupdate.sh -u -l p18889969_121111_Linux-x86-64.zip -s

Active Image version   : 11.2.3.3.1.140529.1
Active Kernel version  : 2.6.39-400.128.17.el5uek
Active LVM Name        : /dev/mapper/VGExaDb-LVDbSys2
Inactive Image version : 11.2.3.2.0.120713
Inactive LVM Name      : /dev/mapper/VGExaDb-LVDbSys1
Current user id        : root
Action                 : upgrade
Upgrading to           : 12.1.1.1.1.140712 (to exadata-sun-computenode-minimum)
Baseurl                : file:///var/www/html/yum/unknown/EXADATA/dbserver/121114021722/x86_64/ (iso)
Iso file               : /u01/dbnodeupdate/iso.stage.121114021722/121111_base_repo_140712.iso
Create a backup        : Yes
Shutdown stack         : Yes (Currently stack is up)
RPM exclusion list     : Not in use (add rpms to /etc/exadata/yum/exclusion.lst and restart dbnodeupdate.sh)
RPM obsolete list      : /etc/exadata/yum/obsolete.lst (lists rpms to be removed by the update)
: RPM obsolete list is extracted from exadata-sun-computenode-12.1.1.1.1.140712-1.x86_64.rpm
Exact dependencies     : Will fail on a next update. Update to 'exact' will be not possible. Falling back to 'minimum'
: See /var/log/exadatatmp/121114021722/exact_conflict_report.txt for more details
: Update target switched to 'minimum'
Minimum dependencies   : No conflicts
Logfile                : /var/log/cellos/dbnodeupdate.log (runid: 121114021722)
Diagfile               : /var/log/cellos/dbnodeupdate.121114021722.diag
Server model           : SUN FIRE X4170 SERVER
Remote mounts exist    : Yes (dbnodeupdate.sh will try unmounting)
dbnodeupdate.sh rel.   : 3.79b (always check MOS 1553103.1 for the latest release of dbnodeupdate.sh)
Note                   : After upgrading and rebooting run './dbnodeupdate.sh -c' to finish post steps.

The following known issues will be checked for and automatically corrected by dbnodeupdate.sh:
(*) - Issue - Adjust kernel.rcu_delay in /etc/sysctl.conf. See MOS 1916147.1
(*) - Issue - Fix for CVE-2014-6271 and CVE-2014-7169 (Shell-Shock)

The following known issues will be checked for but require manual follow-up:
(*) - Issue - Yum rolling update requires fix for 11768055 when Grid Infrastructure is below 11.2.0.2 BP12

Continue ? [y/n]
y

(*) 2014-11-12 02:21:19: Verifying GI and DB's are shutdown
(*) 2014-11-12 02:21:19: Shutting down GI and db
(*) 2014-11-12 02:23:17: Successfully unmounted network mount /mnt/rene
(*) 2014-11-12 02:23:17: Unmount of /boot successful
(*) 2014-11-12 02:23:17: Check for /dev/sda1 successful
(*) 2014-11-12 02:23:17: Mount of /boot successful
(*) 2014-11-12 02:23:17: Disabling stack from starting
(*) 2014-11-12 02:23:17: Performing filesystem backup to /dev/mapper/VGExaDb-LVDbSys1. Avg. 30
minutes (maximum 120) depends per environment........
(*) 2014-11-12 02:30:29: Backup successful
(*) 2014-11-12 02:30:36: ExaWatcher stopped successful
(*) 2014-11-12 02:30:36: Capturing service status and file attributes. This may take a while...
(*) 2014-11-12 02:30:42: Service status and file attribute report in: /etc/exadata/reports
(*) 2014-11-12 02:30:43: Validating the specified source location.
(*) 2014-11-12 02:30:44: Cleaning up the yum cache.
(*) 2014-11-12 02:30:47: Performing yum update. Node is expected to reboot when finished.
(*) 2014-11-12 02:31:03: Waiting for post rpm script to finish. Sleeping another 60 seconds (60 / 900)

Remote broadcast message (Wed Nov 12 02:31:08 2014):

Exadata post install steps started.
It may take up to 15 minutes.

Remote broadcast message (Wed Nov 12 02:31:53 2014):

Exadata post install steps completed.
(*) 2014-11-12 02:32:03: Waiting for post rpm script to finish. Sleeping another 60 seconds (120 / 900)
(*) 2014-11-12 02:33:03: All post steps are finished.
(*) 2014-11-12 02:33:03: System will reboot automatically for changes to take effect
(*) 2014-11-12 02:33:03: After reboot run "./dbnodeupdate.sh -c" to complete the upgrade
(*) 2014-11-12 02:33:05: Cleaning up iso and temp mount points

(*) 2014-11-12 02:33:05: Rebooting now...

Broadcast message from root (pts/0) (Wed Nov 12 02:33:05 2014):

The system is going down for reboot NOW!

関連トピック

- データベース・サーバー・パッケージのカスタマイズとMinimumおよびExact依存性の理解

- dbnodeupdate.shおよびdbserver.patch.zip: DBNodeUpdateユーティリティおよびpatchmgrを使用したExadata Database Server Softwareの更新(My Oracle SupportのドキュメントID 1553103.1)

2.14.6 リリース11.2.2.4.2を実行中のデータベース・サーバーの更新

Oracle Exadata Storage Server Softwareリリース11.2.2.4.2を実行しているデータベース・サーバーの更新には、サーバーでyumを使用する準備のための更新が含まれます。

サーバーは、dbnodeupdate.shユーティリティを使用して準備します。このため、Oracle Exadataリリース11.2.2.4.2からの更新では、2つのdbnodeupdate.shユーティリティを別々の引数で実行する必要があります。どのコマンドをいつ実行するか、ユーティリティから指示があります。

データベース・サーバーの更新は、次の前提条件に基づいています。

- Oracle Exadata Storage Server Softwareリリースが11.2.2.4.2である。

- データベース・サーバーで、Oracle Linux 5.5以上を実行している。

- データベース・サーバー更新が、ローカルULNミラーまたはローカルISOイメージとして使用可能である。

この項では、次の項目について説明します。

- リリース11.2.2.4.2のデータベース・サーバー上でのdbnodeupdate.shユーティリティの使用の準備

- dbnodeupdate.shユーティリティの実行

関連トピック

- データベース更新時の停止時間の短縮

2.14.6.1 リリース11.2.2.4.2のデータベース・サーバー上でのdbnodeupdate.shユーティリティの使用の準備

この手順では、サーバー上でユーティリティをダウンロードおよび準備する方法について説明します。

dbnodeupdate.shユーティリティは、My Oracle SupportのドキュメントID 1553103.1から入手できます。dbnodeupdate.shユーティリティは、11.2.2.4.2を実行しているリリースを、直接Oracle Linux 6に更新できます。

1. dbnodeupdate.shユーティリティをMy Oracle Supportからダウンロードします。

2. データベース・サーバーにrootユーザーとしてログインします。

3. 圧縮ファイルを、データベース・サーバーの/u01/dbnodeupdateディレクトリに置きます。このディレクトリがまだ存在しない場合は、ディレクトリを作成します。

4. /u01/dbnodeupdateディレクトリ内のp16486998_12xxxx_Linux-x86-64.zipパッケージ・ファイルを、次のコマンドを使用して解凍します。

[root@dm01 ]# unzip p16486998_12xxxx_Linux-x86-64.zip

注意:

- 圧縮ISOを使用する場合、データベース・サーバーにアップロードして、使用可能な空き領域の/u01/dbnodeupdateディレクトリに置きます。このディレクトリがまだ存在しない場合は、ディレクトリを作成します。

- ローカルULNミラーを使用する場合、HTTPの場所が使用可能であるか確認します。

- ISOコンテンツがWeb上で使用可能な場合、コンテンツをWebサーバーにアップロードして、マウントし、URLを確認します。

- SUDO権限のあるユーザーは、SUDOを使用してdbnodeupdate.shユーティリティを実行できます。

関連トピック

- dbnodeupdate.shおよびdbserver.patch.zip: DBNodeUpdateユーティリティおよびpatchmgrを使用したExadata Database Server Softwareの更新(My Oracle SupportのドキュメントID 1553103.1)

- ULN Oracle Exadataチャンネルのローカル・ミラーの別個のサーバー上への設定

- ISOイメージをダウンロードしてWebサーバーで使用できるようにする

- Oracle Exadataチャンネル・コンテンツでのyumリポジトリの準備と設定

2.14.6.2 dbnodeupdate.shユーティリティの実行

次の手順では、dbnodeupdate.shユーティリティを、リリース11.2.2.4.2を実行するデータベース・サーバー上で使用する方法について説明します。

1. データベース・サーバーにrootユーザーとしてログインします。

2. 次のコマンドを使用して、dbnodeupdate.shユーティリティを実行します。データベース・サーバーは自動的に再起動します。

[root@dm01 ]# ./dbnodeupdate.sh -u -l repo

このコマンドで、repoはULNミラーのHTTPの場所または圧縮されたISOイメージの場所です。

注意:

データベース・サーバーは自動的に再起動します。再起動の直前に、次の手順の指示が画面に表示されます。

3. 手順2で説明したように、再起動の後、次のコマンドを実行します。圧縮ISOイメージが使用された場合、ユーティリティはISOイメージを自動的に再マウントします。

[root@dm01 ]# ./dbnodeupdate.sh -u -p 2

4. 次のコマンドを使用して、更新を終了します。

[root@dm01 ]# ./dbnodeupdate.sh -c

完了の手順では、ユーティリティが、更新後のチェック、ベスト・プラクティスの適用、Oracleホームの再リンクを実行した後、スタックを再起動します。

注意:

dbnodeupdate.sh -cコマンドの入力時に、更新の実行が継続中の場合があります。この時、ユーティリティはイメージ・ステータスを判別するまで待機します。保留中の更新が有効になるまでの待機中に、システムが再起動することがあります。このような場合、システムがオンラインに戻ってからdbnodeupdate.sh -cコマンドを再び入力します。

2.14.7 データベース・サーバー上のローリング・バック更新

データベース・サーバー更新は、Oracle Exadata Storage Server Software、Oracle Linuxシステム・ソフトウェアおよびファームウェアを変更します。更新は、Grid Infrastructureホーム、データベース・ホーム(dbnodeupdate.sh -c手順の再リンク以外)または顧客がインストールしたソフトウェアの変更は行いません。データベース・サーバー更新は、アクティブなシステム・ディスク・パーティションで実行されます。

アクティブなシステム・ディスク情報を表示するには、imageinfoコマンドを実行します。Logical Volume Manager (LVM)を使用するデータベース・サーバーには、少なくとも1つのシステム・パーティションがあります。imageinfoコマンドの出力例を次に示します。

Kernel version: 2.6.39-400.238.0.el6uek.x86_64 #1 SMP Fri Aug 15 14:27:21 PDT 2014 x86_64
Image version: 12.1.2.1.0.141022
Image activated: 2014-10-22 22:11:12 -0700
Image status: success
System partition on device: /dev/mapper/VGExaDb-LVDbSys1

dbnodeupdate.shユーティリティが、ロールバックを実行すると、非アクティブなシステム・ディスク・パーティションがアクティブになり、アクティブなシステム・ディスク・パーティションが非アクティブになります。非アクティブなシステム・パーティションをアクティブ化することで以前のリリースにロールバックしても、ファームウェアはロールバックされません。Oracle Exadata Storage Server Softwareリリースでは、それ以降のファームウェア・リリースをサポートしています。

データベース・サーバー更新をロールバックするには、データベース・サーバーの更新の前にバックアップを作成する必要があります。dbnodeupdate.shユーティリティは、次の要件が満たされる場合、非アクティブなシステム・ディスク・パーティション上にバックアップを作成します。

- システムでLVMを使用する。

- 非アクティブなパーティションとアクティブなパーティションのサイズが同じである。LVDbSys1パーティションのみが存在する場合、非アクティブなパーティションを作成するのに十分な空き領域がボリューム・グループにあります。

- 2つのシステム・ディスク・パーティション、LVDbSys1およびLVDbSys2が存在する場合、バックアップ中に一時的に作成されるスナップショットを格納するために、ボリューム・グループに少なくとも1GBの空き領域が必要。

前述の前提条件が満たされない場合、dbnodeupdate.shユーティリティにより通知され、処理の自動更新が無効になります。更新を継続する場合、更新をロールバックすることができません。

注意:

Oracle Linux 6に更新したシステムでは、更新を継続する前にバックアップを実行する必要があります。LVMが有効なシステムをOracle Linux 5からOracle Linux 6へ更新する場合、バックアップが自動で実行されます。

Oracle Virtual Server (dom0)として実行するデータベース・サーバーは、ロールバックの際にアクティブなシステム・パーティションとして、LVDbSys2とLVDbSys3との間をスイッチします。

Oracle Virtual Machine (domU)として実行するデータベース・サーバーでは、物理ハードウェア・デプロイメントよりも、LVDbSys1およびLVDbSys2のサイズは小型です。

バックアップがユーティリティで作成されることを確認するには、前提条件チェックまたは更新処理で表示されるdbnodeupdate.sh確認ダイアログをチェックします。作成される場合は、Create a backupエントリに、Yesと表示されます。

次のコマンドを使用すると、更新をロールバックします。

[root@dm01 ]# ./dbnodeupdate.sh -r -s

Oracle Linux 5からOracle Linux 6への更新の処理中、最初の再起動後にエラーが発生すると、LVMが有効なシステムに対して、自動的にロールバックが開始されます。

ロールバックの後、次のコマンドを使用して、パッチ処理後の手順を実行し、スタックを再リンクおよび起動する必要があります。

[root@dm01 ]# ./dbnodeupdate.sh -c

2.14.8 patchmgrによるデータベース・ノードの更新

Exadataリリース12.1.2.2.0以上では、patchmgrを使用してOracle Exadataデータベース・ノード(11.2.2.4.2以上のリリースを実行)、Oracle Exadata仮想サーバー・ノード(dom0)およびOracle Exadata仮想マシン(domU)の更新、ロールバックおよびバックアップを行うことができます。

スタンドアロン・モードでdbnodeupdate.shを実行することも可能ですが、patchmgrを実行して更新を行うと、単一のコマンドの実行によって同時に複数のノードを更新できます。各ノードで個別にdbnodeupdate.shを実行する必要はありません。patchmgrは、ローリングまたは非ローリング方式でノードを更新できます。

patchmgrでこのオーケストレーションを行うには、更新対象外のデータベース・ノードからpatchmgrを実行します。そのノードは、すでに更新されているノードからpatchmgrを実行するか、そのノード自体にスタンドアロンでdbnodeupdate.shを実行することにより、後で更新する必要があります。

セルの更新と同様に、更新するデータベース・ノード(domUおよびdom0を含む)のリストを指定するファイルを作成します。patchmgrは、ローリングまたは非ローリング方式で指定されたノードを更新します。デフォルトは、セルの更新と同様に非ローリングです。ロールバックは、ローリング方式で行われます。

dbnodeupdate.shをスタンドアロンで実行する場合は、patchmgrコンポーネントを使用せずにdbnodeupdate.shを実行するための標準手順に従います。My Oracle Supportノート1553103.1で、dbnodeupdate.shの最新リリースを常に確認してください。

関連トピック

- Oracle Linuxデータベース・サーバーの更新

- dbnodeupdate.shおよびdbserver.patch.zip: DBNodeUpdateユーティリティおよびpatchmgrを使用したExadata Database Server Softwareの更新(My Oracle SupportのドキュメントID 1553103.1)

2.14.8.1 dbserver.patch.zipの入手とインストール

Oracle Exadata Storage Server Softwareリリース12.1.2.2.0以上では、patchmgrからdbnodeupdateを実行するための、新しいdbserver.patch.zipファイルが用意されています。

zipファイルにはpatchmgrおよびdbnodeupdate.zipが含まれています。dbserver.patch.zipファイルを解凍し、そこからpatchmgrを実行します。dbnodeupdate.zipは解凍しないでください。My Oracle Supportノート1553103.1で、dbserver.patch.zipの最新リリースを常に確認してください。

圧縮ISO形式でローカルyumリポジトリを使用するユーザー向けに、通常のハードウェア,domUおよびdom0用に個別の圧縮ISOファイルが用意されています。更新のためにISOファイルを使用する場合は、ISOファイルをdbnodeupdate.zipと同じディレクトリに置くことをお薦めします。

関連トピック

- dbnodeupdate.shおよびdbserver.patch.zip: DBNodeUpdateユーティリティおよびpatchmgrを使用したExadata Database Server Softwareの更新(My Oracle SupportのドキュメントID 1553103.1)

2.14.8.2 非ローリングのアップグレードの動作

非ローリングのアップグレードの動作は次のとおりです。

- ノードが事前チェックの段階で失敗した場合、プロセス全体が失敗します。

- ノードがパッチまたはリブートの段階で失敗した場合、patchmgrは、それ以降のそのノードへのステップをスキップします。他のノードのアップグレード処理は続行されます。

- 事前チェックの段階は、シリアルで実行されます。

- パッチ/再起動および完了の段階は、パラレルで実行されます。

通知アラートの順序は次のとおりです。

1. 起動(すべてのノード、パラレル)

2. パッチ適用(すべてのノード、パラレル)

3. リブート(すべてのノード、パラレル)

4. 完了ステップ(各ノード、シリアル)

5. 成功(各ノード、シリアル)

2.14.8.3 更新手順

実行する手順は、実行する更新のタイプによって異なります。

Oracle Linux 5からOracle Linux 6への移行を伴うデータベース・ノードの更新を実行する場合:

1. patchmgrを使用して、前提条件チェックを実行します。

2. バックアップを実行します。

3. 必須のバックアップと更新を実行します。

Oracle Linux 5からOracle Linux 6への更新以外の更新を実行する場合:

1. 前提条件チェックを実行します。

2. (オプション)バックアップを実行します。

3. オプションのバックアップと更新を実行します。

2.14.8.4 patchmgrのオプション

patchmgrコマンドとともに様々なオプションを使用できます。

patchmgrを使用してデータベース・ノードを更新する場合、次のオプションがサポートされています。

表2-9 patchmgrのオプション: 必須オプション

オプション

説明

-dbnodeslist_file

データベース・ノードのリスト・ファイルの名前を指定します。ファイルには1行に1つのホスト名またはIPアドレスが記載されています。

表2-10 patchmgrのオプション: アクション・オプション

オプション

説明

-precheck

リスト・ファイルに指定されたデータベース・ノードに対して更新前の検証チェックを実行します(実際の更新は行いません)。

-upgrade

リフト・ファイルに指定されているデータベース・ノードをアップグレードします。

-backup

リフト・ファイルに指定されているデータベース・ノードをバックアップします。

-rollback

リフト・ファイルに指定されているデータベース・ノードをロールバックします。

-cleanup

非ローリング方式で、ホスト・リストに指定されたデータベース・ノードのすべての一時コンテンツを削除します。通常、このオプションはアップグレードまたはロールバックの操作の後に使用します。

-get property

指定されたプロパティに関する情報を戻します。プロパティは次のとおりです。

- log_dir
ログ・ディレクトリを返します。

表2-11 patchmgrのオプション: サポート・オプション

オプション

説明

-iso_repo repo_location

圧縮ISOファイルのパスを指定します。dbnodeupdate.zipファイルと同じディレクトリにそのファイルを配置することをお薦めします。

-backup、-precheckおよび-upgradeアクションには、このオプションまたは-yum_repoオプションを指定する必要があります。

-yum_repoオプションとともにこのオプションを使用することはできません。

-yum_repo repo_location

yumのHTTPリポジトリへのURLを指定します。

-backup、-precheckおよび-upgradeアクションには、このオプションまたは-iso_repoオプションを指定する必要があります。

-iso_repoオプションとともにこのオプションを使用することはできません。

-log_dir log_directory_or_auto

ログ・ディレクトリへの絶対パスを指定するか、またはautoを指定して、起動ディレクトリおよびノード・リスト・ファイルのコンテンツに基づくログ・ディレクトリを使用できます。

-log_dirオプションを指定すると、複数のパッチ・マネージャ呼出しを実行することも、root以外のユーザーとしてパッチ・マネージャを実行することもできます。

-nobackup

アップグレード・アクションでデータベース・ノードのバックアップを実行しないことを指定します。

-target_version version

更新先の完全なリリース・バージョンを指定します。この情報は、パッチのREADMEファイルにあります。

-unkey

終了する前に、データベース・ノードへのパスワードなしのSSHアクセスを削除します。

-rolling

ローリング方式で更新を実行することを指定します。指定しない場合、更新は非ローリング方式で実行されます。

注意: ロールバックは、このオプションを指定しない場合でも、常にローリング方式で実行されます。

注意: -rollingオプションが指定されている場合でも、常に非ローリング方式で事前チェックとクリーン・アップが実行されます。

-allow_active_network_mounts

アクティブなNFSまたはSMBマウントを使用してdbnodeupdateを実行することを許可します。

これはdbnodeupdate.sh -Aコマンドと同等です。

-force_remove_custom_rpms

Oracle Linux 5からOracle Linux 6へのデータベース・ノードの更新時にカスタムRPMを削除します。

これはdbnodeupdate.sh -Rコマンドと同等です。

-nomodify_at_prereq

前提条件の確認時にRPMを変更しません。

これはdbnodeupdate.sh -Nコマンドと同等です。

表2-12 patchmgrのオプション: メール・オプション

オプション

説明

-smtp_from "from_email"

patchmgr通知の送信元(from)の電子メール・アドレスを指定します。

-smtp_to "to_email1 to_email2 to_email3 ..."

patchmgr通知の送信先(to)の電子メール・アドレスを指定します。

-smtp_set_envelope_sender

「Return-Path:」メール・ヘッダーと同じ送信元(from)アドレスが使用されることを指定します。

関連トピック

- 前提条件の確認

- (データベース)ノードの更新

- データベース・サーバー上のローリング・バック更新

2.14.8.5 前提条件の確認

-precheckオプションは更新をシミュレートし、実際の更新は行いません。

-precheckオプションを使用して、実際の更新前にエラーを捕捉して解決します。

使用方法:

# ./patchmgr -dbnodes dbnode_list -precheck -iso_repo iso_file -target_version version

# ./patchmgr -dbnodes dbnode_list -precheck -yum_repo yum_http -target_version version

例2-2 yum HTTPリポジトリとのpatchmgrの使用

yum HTTPリポジトリを使用した例。date_stampはバージョンのリリース日を指定します(例: 150731)。

# ./patchmgr -dbnodes dbnode_list -precheck -yum_repo http://yum-repo/yum/ol6/EXADATA/
dbserver/12.1.2.2.0/base/x86_64/ -target_version 12.1.2.2.0.date_stamp

例2-3 yumの圧縮ISOリポジトリとのpatchmgrの使用

yumの圧縮ISOリポジトリを使用した例。date_stampはバージョンのリリース日を指定します(例: 150731)。

# ./patchmgr -dbnodes dbnode_list -precheck -iso_repo ./repo.zip
-target_version 12.1.2.2.0.date_stamp

2.14.8.6 (データベース)ノードの更新

-upgradeオプションは、データベース・ノードの実際のアップグレードを実行します。

システム内のすべてのデータベース・ノードを更新する必要がある場合は、駆動ノードからコマンドを実行する必要があります(駆動ノードは更新対象のデータベース・ノードに含めることはできません)。

使用方法:

# ./patchmgr -dbnodes dbnode_list -upgrade -iso_repo iso_file -target_version version

# ./patchmgr -dbnodes dbnode_list -upgrade -yum_repo yum_http -target_version version

例2-4 yum HTTPリポジトリを使用したローリング更新

yum HTTPリポジトリを使用したローリング更新の例。date_stampはバージョンのリリース日を指定します(例: 150731)。

# ./patchmgr -dbnodes dbnode_list -upgrade -yum_repo http://yum-repo/yum/ol6/EXADATA/
dbserver/12.1.2.1.0/base/x86_64/ -target_version 12.1.2.2.0.date_stamp -rolling

例2-5 yumの圧縮ISOリポジトリを使用した非ローリング更新

yumの圧縮ISOリポジトリを使用したローリング更新の例。date_stampはバージョンのリリース日を指定します(例: 150731)。

# ./patchmgr -dbnodes dbnode_list -upgrade -iso_repo ./repo.zip
-target_version 12.1.2.2.0.date_stamp

2.14.8.7 更新のロール・バック

-rollbackオプションを使用して、更新をロールバックします。

-rollbackオプションは、Logical Volume Manager (LVM)のアクティブ/非アクティブの切替え、/bootコンテンツのリストア、Grubの再インストールおよびデータベース・ノードの再起動を行って、アップグレードの影響を元に戻します。これを使用できるのは、LVMが有効なシステムに対してのみです。

注意:

ロールバックは、-rollingを指定しない場合にも、ローリング方式でのみ実行されます。

使用方法:

# ./patchmgr -dbnodes dbnode_list -rollback

関連トピック

- データベース・サーバー上のローリング・バック更新

2.14.8.8 patchmgrによるデータベース・ノードの更新時における失敗のトラブルシューティング

patchmgrの実行中に問題が発生した場合、次の注意点を確認してください。

patchmgrを使用してデータベース・ノードを更新するための正しい構文は、patchmgrオンライン・ヘルプを参照してください。

patchmgrツールを使用したデータベース・ノードの更新は簡潔で、最小限の情報のみが画面に出力されます。追加情報が必要な場合は、patchmgrログと、patchmgrが失敗したノードからコピーしたdbnodeupdate.shログ(使用できる場合)を確認できます。

ストレージ・セルの更新のように、patchmgrではSSH等価を実行する必要があります。

いつものように、My Oracle Supportノート1553103.1から最新のdbserver.patch.zipをダウンロードしてください。

まれに、patchmgrで更新のステータス(更新の成否)を判断できないことがあります。このような場合は、更新が失敗したことを示すメッセージが表示されます。ただし、更新が正常に完了している可能性もあります。更新の実際のステータスを確認する手順:

- (データベース)ノードのイメージ・ステータスをチェックします。これを行うには、imageinfoコマンドを実行します。「Image status」行にステータスが表示されます。

- Exadataソフトウェアのバージョンをチェックします。これはimageinfoコマンドから確認することもできます。

イメージ・ステータスが成功(success)で、Exadataバージョンが予想される新しいバージョンの場合、更新は成功しているため、update failed (更新の失敗)メッセージは無視して構いません。その後、次の操作を実行します。

- 特定のノード上でdbnodeupdate.sh -cを手動で実行し、更新の完了手順を実行します。

- 完了したノードを(データベース)ノード・ファイルから削除します。

- patchmgrを再実行し、残りのノードに対して更新を実行します。

patchmgrを使用したデータベース・ノードの更新は任意です。引き続きdbnodeupdate.shを手動で実行することもできます。クリティカル・システムの更新時にpatchmgrからブロック・エラーが返された場合、dbnodeupdate.shを手動で実行して更新することをお薦めします。

patchmgrオーケストレーションに失敗した理由を分析するには、Oracleサポートにサービス・リクエストを提出してください。

関連トピック

- patchmgrのオプション

- dbnodeupdate.shおよびdbserver.patch.zip: DBNodeUpdateユーティリティおよびpatchmgrを使用したExadata Database Server Softwareの更新(My Oracle SupportのドキュメントID 1553103.1)

- dbserver.patch.zipの入手とインストール

2.14.9 sudoによるdbnodeupdate.shおよびpatchmgr (およびdbnodeupdateオーケストレーション)の実行

2.14.9.1 sudoによるdbnodeupdate.shの実行

sudoを使用してdbnodeupdate.shを実行するために/etc/sudoersファイルを設定するには、次の手順を実行します。

1. rootとしてログインし、visudoを使用して/etc/sudoersを編集します。

# visudo

2. oracleユーザーなどのroot以外のユーザーが、dbnodeupdateをrootとして実行できるように、sudoersファイルの最後に、次のエントリを(すべてを1行で)追加します。

注意:

行の最初のフィールドは、dbnodeupdate.shコマンドのsudoアクセス権が付与される非rootユーザーを指定します。次の行では、oracleユーザーを例として使用しています。必要に応じて、異なるユーザーを指定できます。

oracle  ALL=(ALL)    NOPASSWD:SETENV: /u01/stage/patch/dbnodeupdate/dbnodeupdate.sh

3. rootとして、/u01/stage/patch/dbnodeupdateディレクトリを作成し、dbnodeupdate.zipを解凍します。

# mkdir -p /u01/stage/patch/dbnodeupdate
# cp dbnodeupdate.zip /u01/stage/patch/dbnodeupdate
# cd /u01/stage/patch/dbnodeupdate
# unzip dbnodeupdate.zip

正しく設定されたかどうかを確認するために、oracleユーザーとして前提条件チェック・モードでdbnodeupdateを実行します。

[oracle]$ cd /u01/stage/patch/dbnodeupdate

[oracle]$ sudo ./dbnodeupdate.sh -u -l http://my-yum-repo/yum/EngineeredSystems/exadata/dbserver/12.1.2.1.3/base/x86_64/ -v

dbnodeupdateは、root権限なしで実行された場合に終了します。

注意:

- 前述の設定では、/u01/stage/patch/dbnodeupdateのすべてがrootによって所有されている必要があります。

- dbnodeupdateの新しいバージョンを、sudoersでの指定と同じ場所に配置する必要があります。

2.14.9.2 sudoによるpatchmgr (およびdbnodeupdateオーケストレーション)の実行

sudoを使用してpatchmgr (dbserver.patch.zipにパッケージされている)を実行することにより、セルのパッチ適用、InfiniBandスイッチのパッチ適用、dbnodeupdateの実行のオーケストレーションなど、patchmgrの任意の機能を実行できます。

sudoを使用してpatchmgrを実行するために/etc/sudoersファイルを設定するには、次の手順を実行します。

1. rootとしてログインし、visudoを使用して/etc/sudoersを編集します。

# visudo

2. oracleユーザーなどのroot以外のユーザーが、patchmgrをrootとして実行できるように、sudoersファイルの最後に、次のエントリを追加します。

注意:

行の最初のフィールドは、patchmgrコマンドのsudoアクセス権が付与される非rootユーザーを指定します。次の行では、oracleユーザーを例として使用しています。必要に応じて、異なるユーザーを指定できます。

oracle  ALL=(ALL)    NOPASSWD:SETENV: /u01/stage/patch/dbserverpatch/patchmgr

3. rootとして、/u01/stage/patch/dbserverpatchディレクトリを作成し、dbserver.patch.zipを解凍します。

# mkdir -p /u01/stage/patch/dbserverpatch/
# cp dbserver.patch.zip /u01/stage/patch/dbserverpatch/
# cd /u01/stage/patch/dbserverpatch/
# unzip dbserver.patch.zip

4. /u01/stage/patch/dbserverpatch/dbserver_patch_x.yymmddディレクトリ下のすべてを、/u01/stage/patch/dbserverpatch/に移動します。

# mv /u01/stage/patch/dbserverpatch/dbserver_patch_x.yymmdd/* /u01/stage/patch/dbserverpatch/

注意:

- patchmgrは、sudoを使用して実行する場合でも、更新されるすべてのデータベース・ノードのroot SSH等価を期待します。

- 前述の設定では、/u01/stage/patch/dbserverpatchのすべての内容がrootによって所有されている必要があります。

- dbserver.patch.zipの新しいバージョンを、sudoersでの指定と同じ場所に配置する必要があります。

正しく設定されたかどうかを確認するために、oracleユーザーとして前提条件チェック・モードでpatchmgrを実行します。

[oracle]$ cd /u01/stage/patch/dbserverpatch/

[oracle]$ sudo ./patchmgr -dbnodes dbgroup -precheck     \
-yum_repo http://my-yum-repo/yum/EngineeredSystems/exadata/dbserver/12.1.2.1.3/base/x86_64/  \
-target_version 12.1.2.1.3.151021

2.15 Oracle Linuxデータベース・サーバーの再イメージ化

再イメージ化の手順が必要なのは、Oracle Linuxデータベース・サーバーで修復できないほどの損傷が発生した場合です。

損傷したOracle Linuxデータベース・サーバーを新しいデータベース・サーバーと交換します。複数のディスク障害でローカル・ディスクのストレージに障害が発生し、データベース・サーバーがバックアップされなかった場合は、この手順も実行します。再イメージ化手順の実行中に、Oracle Exadata Database Machineの他のデータベース・サーバーを使用できます。クラスタに新しいサーバーを追加すると、ソフトウェアが既存のデータベース・サーバーから新しいサーバーにコピーされます。スクリプト、CRONジョブ、保守処置、Oracle以外のソフトウェアのリストアはユーザーが行います。

注意:

この項の手順は、データベースがOracle Database 12cリリース1 (12.1)またはOracle Database 11gリリース2 (11.2)であることを前提としています。データベースがOracle Database 11gリリース1 (11.1)の場合、クラスタのサーバーの追加および削除の詳細は、該当するリリースのドキュメントを参照してください。

Oracle Linuxデータベース・サーバーを再イメージ化する方法は、次のとおりです。

- 作業1: Oracleサポート・サービスへの連絡

- 作業2: クラスタ検証ユーティリティの最新リリースのダウンロード

- 作業3: クラスタの障害が発生したデータベース・サーバーの削除

- 作業4: イメージ化に使用するUSBフラッシュ・ドライブの準備

- 作業5: 交換データベース・サーバーのイメージ化

- 作業6: 交換データベース・サーバーの構成

- 作業7: クラスタの交換データベース・サーバーの準備

- 作業8: 交換データベース・サーバーへのOracle Exadata Storage Server Softwareパッチ・バンドルの適用

- 作業9: 交換データベース・サーバーへのOracle Grid Infrastructureのクローニング

- 作業10: 交換データベース・サーバーへのOracle Databaseホームのクローニング

2.15.1 作業1: Oracleサポート・サービスへの連絡

Oracleサポート・サービスでOracleサポート・リクエストを開きます。サポート・エンジニアが障害が発生したサーバーを確認し、交換サーバーを送ります。サポート・エンジニアは、残存データベース・サーバーから実行したimagehistoryコマンドの出力結果を要求します。出力結果により、元のデータベース・サーバーのイメージ化に使用したcomputeImageMakerファイルへのリンクと、システムを同じレベルにリストアする手段が提供されます。

2.15.2 作業2: クラスタ検証ユーティリティの最新リリースのダウンロード

クラスタ検証ユーティリティ(cluvfy)の最新リリースは、My Oracle Supportで入手できます。

ダウンロードの方法およびその他の情報は、My Oracle Supportノート316817.1を参照してください。

関連トピック

- クラスタ検証ユーティリティ(CLUVFY)のFAQ (My Oracle SupportのドキュメントID 316817.1)

2.15.3 作業3: クラスタの障害が発生したデータベース・サーバーの削除

サーバーを再イメージ化する前に、障害が発生したデータベース・サーバーをクラスタから削除する必要があります。

この作業の手順は、クラスタで動作しているデータベース・サーバーを使用して実行されます。次のコマンドのworking_serverは動作しているデータベース・サーバー、replacement_serverは交換データベース・サーバーです。

1. クラスタのデータベース・サーバーにoracleユーザーとしてログインします。

2. 障害が発生したサーバーで実行されているリスナーを無効化します。

$ srvctl disable listener -n failed_server
$ srvctl stop listener -n failed_server

3. OracleインベントリからOracleホームを削除します。

次のコマンドのlist_of_working_serversは、dm01db02やdm01db03などのクラスタで動作しているサーバーのリストです。

$ cd $ORACLE_HOME/oui/bin
$ ./runInstaller -updateNodeList ORACLE_HOME= \
/u01/app/oracle/product/12.1.0.2/dbhome_1 "CLUSTER_NODES=list_of_working_servers"

4. 障害が発生したサーバーの固定が解除されたことを確認します。

$ olsnodes -s -t

次に、コマンドの出力例を示します。

dm01db01        Inactive        Unpinned
dm01db02        Active          Unpinned

5. 障害が発生したデータベース・サーバーのVIPリソースを停止して削除します。

# srvctl stop vip -i failed_server-vip
PRCC-1016 : failed_server-vip.example.com was already stopped

# srvctl remove vip -i failed_server-vip
Please confirm that you intend to remove the VIPs failed_server-vip (y/[n]) y

6. クラスタからサーバーを削除します。

# crsctl delete node -n failed_server
CRS-4661: Node dm01db01 successfully deleted.

次のようなエラー・メッセージを受領したら、投票ディスクを移動します。

CRS-4662: Error while trying to delete node dm01db01.
CRS-4000: Command Delete failed, or completed with errors.

投票ディスクを移動するには、次の手順を実行します。

a. 投票ディスクの現在の場所を特定します。

# crsctl query css votedisk

次に、コマンドの出力例を示します。現在の場所はDBFS_DGです。

##  STATE    File Universal Id          File Name                Disk group
--  -----    -----------------          ---------                ----------
1. ONLINE   123456789abab (o/192.168.73.102/DATA_CD_00_dm01cel07) [DBFS_DG]
2. ONLINE   123456789cdcd (o/192.168.73.103/DATA_CD_00_dm01cel08) [DBFS_DG]
3. ONLINE   123456789efef (o/192.168.73.100/DATA_CD_00_dm01cel05) [DBFS_DG]
Located 3 voting disk(s).

b. 投票ディスクを別のディスク・グループに移動します。

# ./crsctl replace votedisk +DATA

Successful addition of voting disk 2345667aabbdd.
...
CRS-4266: Voting file(s) successfully replaced

c. 次のコマンドを使用して、投票ディスクを元の場所に移動します。

# ./crsctl replace votedisk +DBFS_DG

d. クラスタからサーバーを削除します。

7. Oracleインベントリを更新します。

$ cd $ORACLE_HOME/oui/bin
$ ./runInstaller -updateNodeList ORACLE_HOME=/u01/app/12.1.0.2/grid \
"CLUSTER_NODES=list_of_working_servers" CRS=TRUE

8. サーバーが正常に削除されたことを確認します。

$ cluvfy stage -post nodedel -n failed_server -verbose

次に、コマンドの出力例を示します。

Performing post-checks for node removal
Checking CRS integrity...
The Oracle clusterware is healthy on node "dm01db02"
CRS integrity check passed
Result:
Node removal check passed
Post-check for node removal was successful.

関連トピック

- Oracle Real Application Clusters管理およびデプロイメント・ガイド

2.15.4 作業4: イメージ化に使用するUSBフラッシュ・ドライブの準備

USBフラッシュ・ドライブを使用して、イメージを新しいデータベース・サーバーにリストアします。

次の手順は、USBフラッシュ・ドライブを使用する準備を整える方法を示しています。

注意:

リリース12.1.2.1.0以降の場合、イメージの作成に使用されるシステムはOracle Linux 6を実行している必要があります。

リリース12.1.2.2.0以上の場合

1. 空のUSBフラッシュ・ドライブをクラスタの動作しているデータベース・サーバーに挿入します。

2. rootユーザーとしてログインします。

3. USBドライブを準備します。
次のようなコマンドを使用します。ここで、/dev/sddは挿入したUSBドライブの名前です。USBドライブを挿入した後に/var/log/messagesを確認すると、正確な名前がわかります。

# dd if=/dev/zero of=/dev/sdd bs=1M count=100 oflag=direct

4. USBドライブにcomputeImageMakerの.imgファイルを書き込みます。これには15分以上かかる場合があり、操作中には出力は表示されません。
次のようなコマンドを使用します。ここで、/dev/sddは挿入したUSBドライブの名前です。

# dd if=filename.img of=/dev/sdd bs=1M oflag=direct

5. Linuxのパーティション表を再スキャンして、新しいパーティションが認識されるようにします。

# partprobe

6. システムがext4ファイル・システムをサポートするかぎりUSBがマウント可能であることを確認します。前のddコマンドがOracle Linux 5システムで実行された場合でも、この手順ではこれをOracle Linux 6システムにする必要があります。
次のようなコマンドを使用します。ここで、/dev/sddは挿入したUSBドライブの名前です。

mount /dev/sdd1 /mnt

7. preconf.csvファイルを準備して、USBドライブに配置します。
USBでは、ファイル名はpreconf.csvである必要があります。preconf.csvファイルには、イメージ化中に使用される各ノードのMACアドレスが含まれる必要があります。イメージ化中にpreconf.csvファイルが使用されない場合は、ノードが初めて起動するときに、そのネットワーク構成が要求されます。

# cp /path_to_preconf_file/preconf.csv /mnt/preconf.csv

# umount /mnt   ### this also ensures that the filesystem is synchronized

12.1.2.2.0より前のリリースの場合:

1. 空のUSBフラッシュ・ドライブをクラスタの動作しているデータベース・サーバーに挿入します。

2. rootユーザーとしてログインします。

3. computeImageファイルを解凍します。

次のようなコマンドを使用します。ここで、exadata_releaseは11.2.1.2.0などのOracle Exadata Storage Server Softwareのリリース番号、release_dateは091102などのリリースの日付、platformはx86_64などのリリースのプラットフォームです。

# unzip computeImageMaker_exadata_release_LINUX.X64_ \
release_date.platform.tar.zip

# tar -xvf computeImageMaker_exadata_release_LINUX.X64_ \
release_date.platform.tar

4. 次のコマンドを使用して、USBフラッシュ・ドライブにイメージをロードします。

# cd dl360
# ./makeImageMedia.sh -factory -stit -reboot-on-success -nodisktests [-preconf path_to_preconf_file]

makeImageMedia.shスクリプトにより、情報を要求されます。

5. データベース・サーバーからUSBフラッシュ・ドライブを取り外します。

6. 動作しているデータベース・サーバーから解凍したcomputeディレクトリおよびcomputeImageMakerファイルを削除します。このディレクトリおよびファイルには、約2GBの領域が必要です。

2.15.5 作業5: 交換データベース・サーバーのイメージ化

データベース・サーバーが交換された後、USBフラッシュ・ドライブを使用して、新しいデータベース・サーバーにイメージを配置します。次の手順は、新しいデータベース・サーバーにイメージをロードする方法を示しています。

1. 交換データベース・サーバーのUSBポートにUSBフラッシュ・ドライブを挿入します。

2. サービス・プロセッサまたはKVMスイッチを使用してコンソールにログインし、進捗状況を監視します。

3. サービス・プロセッサ・インタフェースまたは電源ボタンを使用して、データベース・サーバーの電源を投入します。

4. BIOS中にF2キーを押してからBIOS設定を選択して起動順序を構成するか、またはF8キーを押してからワンタイム起動選択メニューを選択してUSBフラッシュ・ドライブを選択します。

5. マザーボードが交換されたら、BIOS起動順序を構成します。起動順序はUSBフラッシュ・ドライブ、次にRAIDコントローラの順です。

6. システムを起動できるようにします。システムが起動すると、CELLUSBINSTALLメディアが検出されます。イメージ化プロセスには、2つのフェーズがあります。次の手順に進む前に、各フェーズを完了します。

イメージ化プロセスの1つ目のフェーズでは、古いBIOSまたはファームウェアを識別し、イメージに対応するレベルにコンポーネントをアップグレードします。コンポーネントをアップグレードまたはダウングレードする必要がある場合は、システムが自動的に再起動します。

イメージ化プロセスの2つ目のフェーズでは、交換データベース・サーバーの工場出荷時のイメージをインストールします。

7. システムで要求された場合、USBフラッシュ・ドライブを取り外します。

8. USBフラッシュ・ドライブを取り外した後、[Enter]を押してサーバーの電源を切断します。

2.15.6 作業6: 交換データベース・サーバーの構成

交換データベース・サーバーには、ホスト名、IPアドレス、DNSまたはNTP設定がありません。この作業の手順は、交換データベース・サーバーの構成方法を示しています。交換データベース・サーバーを構成する前に、次の情報が必要です。

- ネーム・サーバー

- 南北アメリカ/シカゴなどのタイムゾーン

- NTPサーバー

- 管理ネットワークのIPアドレス情報

- クライアント・アクセス・ネットワークのIPアドレス情報

- InfiniBandネットワークのIPアドレス情報

- 標準的なホスト名

- デフォルトのゲートウェイ

Oracle Exadata Database Machineのすべてのデータベース・サーバーで情報を同じにする必要があります。IPアドレスは、DNSから取得できます。また、Oracle Exadata Database Machineがインストールされたときに、この情報を含むドキュメントが提供されています。

次の手順は、交換データベース・サーバーの構成方法を示しています。

1. 交換データベース・サーバーの電源を投入します。システムがブートすると、自動的にOracle Exadataの構成ルーチンが実行され、情報の入力が要求されます。

2. 要求された場合は情報を入力して、設定を確認します。起動プロセスが続行されます。

注意:

- データベース・サーバーがすべてのネットワーク・インタフェースを使用していない場合は、構成プロセスが停止し、いずれかのネットワーク・インタフェースが切断されているという警告が出されます。検出プロセスを再試行するかどうかの確認を求められます。環境に応じて、yesまたはnoと入力します。

- クライアント・アクセス・ネットワークにボンディングが使用される場合、この時点でデフォルトのアクティブ/パッシブ・モードに設定されます。

2.15.7 作業7: クラスタの交換データベース・サーバーの準備

Oracle Exadata Database Machineの初期インストールの実行中、インストール・プロセスで特定のファイルが変更されました。次の手順は、初期インストールの実行中の変更が交換データベース・サーバーに行われることを確認する方法を示しています。

1. 動作しているデータベース・サーバーのファイルを参照して、次のファイルの内容をコピーまたはマージします。

a. /etc/security/limits.confファイルの内容をコピーします。

b. /etc/hostsファイルの内容をマージします。

c. /etc/oracle/cell/network-config/cellinit.oraファイルをコピーします。

d. /etc/oracle/cell/network-config/cellinit.oraファイルを、交換サーバーのifcfg-bondib0インタフェース(アクティブ-パッシブ・ボンディングの場合)またはib0とib1のインタフェース(アクティブ-アクティブ・ボンディングの場合)のIP_ADDRESSで更新します。

e. /etc/oracle/cell/network-config/cellip.oraファイルをコピーします。すべてのデータベース・サーバーでcellip.oraファイルの内容を同じにする必要があります。

f. 10GbEなど、追加ネットワーク要件を構成します。

g. /etc/modprobe.confファイルをコピーします。すべてのデータベース・サーバーでファイルの内容を同じにする必要があります。

h. /etc/sysctl.confファイルをコピーします。すべてのデータベース・サーバーでファイルの内容を同じにする必要があります。

i. データベース・サーバーを再起動し、ネットワーク変更を有効にします。

2. Oracleソフトウェア所有者にグループを追加して、交換データベース・サーバーにoracleユーザーを設定します。通常、所有者はoracleです。グループ情報は、動作しているデータベース・サーバーで使用できます。

a. 次のコマンドを使用して、動作しているデータベース・サーバーから現在のグループ情報を取得します。

# id oracle
uid=1000(oracle) gid=1001(oinstall) groups=1001(oinstall),1002(dba),1003(oper),1004(asmdba)

b. 次のようにgroupaddコマンドを使用して、グループ情報を交換データベース・サーバーに追加します。

# groupadd -g 1001 oinstall
# groupadd -g 1002 dba
# groupadd -g 1003 oper
# groupadd -g 1004 asmdba

c. 次のコマンドを使用して、動作しているデータベース・サーバーから現在のユーザー情報を取得します。

# id oracle uid=1000(oracle) gid=1001(oinstall) \
groups=1001(oinstall),1002(dba),1003(oper),1004(asmdba)

d. 次のコマンドを使用して、ユーザー情報を交換データベース・サーバーに追加します。

# useradd -u 1000 -g 1001 -G 1001,1002,1003,1004 -m -d /home/oracle -s \
/bin/bash oracle

e. 次のコマンドを使用して、/u01/app/oracleや/u01/app/12.1.0.2/gridなどのORACLE_BASEおよびグリッド・インフラストラクチャ・ディレクトリを作成します。

# mkdir -p /u01/app/oracle
# mkdir -p /u01/app/12.1.0.2/grid
# chown -R oracle:oinstall /u01/app

f. 次のコマンドを使用して、cellip.oraおよびcellinit.oraファイルの所有権を変更します。通常、所有権はoracle:dbaです。

# chown -R oracle:dba /etc/oracle/cell/network-config

g. 次のコマンドを使用して、リストアしたデータベース・サーバーをセキュリティで保護します。

$ chmod u+x /opt/oracle.SupportTools/harden_passwords_reset_root_ssh
$ /opt/oracle.SupportTools/harden_passwords_reset_root_ssh

注意:

データベース・サーバーが再起動されます。プロンプトが表示されたら、rootユーザーとしてログインします。新しいパスワードが要求されます。他のデータベース・サーバーのパスワードrootと一致するパスワードを設定します。

h. 次のコマンドを使用して、Oracleソフトウェア所有者のパスワードを設定します。通常、所有者はoracleです。

# passwd oracle

3. 次に示すように、oracleアカウントにSSHを設定します。

a. 次のコマンドを使用して、交換データベース・サーバーのoracleアカウントにログインします。

# su - oracle

b. Oracleクラスタのサーバーをリストする交換データベース・サーバーのdcliグループ・ファイルを作成します。

c. 交換データベース・サーバーで次のコマンドを実行します。

$ dcli -g dbs_group -l oracle -k

d. 次のコマンドを使用して、交換データベース・サーバーにoracleユーザーとしてログインします。

# su - oracle

e. 次のコマンドを使用して、SSH等価を確認します。

$ dcli -g dbs_group -l oracle date

4. 次のコマンドを使用して、動作しているデータベース・サーバーから交換データベース・サーバーにカスタム・ログイン・スクリプトを設定またはコピーします。

$ scp .bash* oracle@replacement_server:.

前述のコマンドのreplacement_serverは、dm01db01などの新しいサーバーの名前です。

2.15.8 作業8: 交換データベース・サーバーへのOracle Exadata Storage Server Softwareパッチ・バンドルの適用

Oracle Exadata Database MachineのOracle Exadata Storage Server Softwareパッチ・バンドルが定期的にリリースされています。

computeImageMakerファイルのリリースよりも新しいパッチ・バンドルが動作しているデータベース・サーバーに適用された場合、パッチ・バンドルを交換データベース・サーバーに適用する必要があります。次に示すように、パッチ・バンドルが適用されているか確認します。

- Oracle Exadata Storage Server Softwareリリース11.2.1.2.3以前のデータベース・サーバーは、バージョン履歴情報を保持していません。リリース番号を確認するには、Exadata Storage Serverにログインし、次のコマンドを実行します。

imageinfo -ver

computeImageMakerファイルで使用されるリリースと異なるリリースが表示された場合、Oracle Exadata Storage Server SoftwareパッチがOracle Exadata Database Machineに適用されているので、交換データベース・サーバーに適用する必要があります。

- Oracle Exadata Storage Server Softwareリリース11.2.1.2.3以降、imagehistoryコマンドがデータベース・サーバーにあります。交換データベース・サーバーの情報を動作しているデータベース・サーバーの情報と比較します。動作しているデータベースのリリースが新しい場合、Exadata Storage Serverパッチ・バンドルを交換データベース・サーバーに適用します。

関連トピック

- Exadata Database MachineおよびExadata Storage Serverのサポートされているバージョン(My Oracle SupportのドキュメントID 888828.1)

2.15.9 作業9: 交換データベース・サーバーへのOracle Grid Infrastructureのクローニング

この手順では、交換データベース・サーバーにGrid Infrastructureをクローニングする方法について説明します。

次のコマンドのworking_serverは動作しているデータベース・サーバー、replacement_serverは交換データベース・サーバーです。手順中のコマンドは、動作しているデータベース・サーバーからグリッド・ホーム所有者として実行します。コマンドの実行にrootユーザーが必要な場合はコールアウトされます。

1. 次のようにクラスタ検証ユーティリティ(cluvfy)を使用して、ハードウェアおよびオペレーティング・システムのインストールを検証します。

$ cluvfy stage -post hwos -n replacement_server,working_server -verbose

レポートの最後にPost-check for hardware and operating system setup was successfulのフレーズが表示されます。

2. 次のコマンドを使用して、ピア互換性を確認します。

$ cluvfy comp peer -refnode working_server -n replacement_server  \
-orainv oinstall -osdba dba | grep -B 3 -A 2 mismatched

次に、出力の例を示します。

Compatibility check: Available memory [reference node: dm01db02]
Node Name Status Ref. node status Comment
------------ ----------------------- ----------------------- ----------
dm01db01 31.02GB (3.2527572E7KB) 29.26GB (3.0681252E7KB) mismatched
Available memory check failed
Compatibility check: Free disk space for "/tmp" [reference node: dm01db02]
Node Name Status Ref. node status Comment
------------ ----------------------- ---------------------- ----------
dm01db01 55.52GB (5.8217472E7KB) 51.82GB (5.4340608E7KB) mismatched
Free disk space check failed

障害が発生したコンポーネントだけが物理メモリー、スワップ領域およびディスク領域に関連している場合は、手順を継続できます。

3. 次のように、サーバーを追加するために必要な確認を行います。

a. GRID_HOME/network/admin/samplesディレクトリの権限が750に設定されていることを確認します。

b. データベース・サーバーの追加を検証します。oracleユーザーとして次のコマンドを実行します。ただし、このコマンドではrootユーザーのパスワードが要求されます。

$ cluvfy stage -pre nodeadd -n adczardb03 -fixup -method root -verbose
Enter "ROOT" password:

障害が発生したコンポーネントだけがスワップ領域に関連している場合は、手順を継続できます。

コマンドでエラーが返される場合は、次の環境変数を設定してコマンドを再実行します。

$ export IGNORE_PREADDNODE_CHECKS=Y

4. 次のコマンドを使用して、交換データベース・サーバーをクラスタに追加します。

$ cd /u01/app/12.1.0.2/grid/addnode

$ ./addnode.sh -silent "CLUSTER_NEW_NODES={replacement_server}" \
"CLUSTER_NEW_VIRTUAL_HOSTNAMES={replacement_server-vip}"

2つ目のコマンドを使用すると、Oracle Universal InstallerによってOracle Clusterwareソフトウェアが交換データベース・サーバーにコピーされます。次のようなメッセージが表示されます。

WARNING: A new inventory has been created on one or more nodes in this session.
However, it has not yet been registered as the central inventory of this
system. To register the new inventory please run the script at
'/u01/app/oraInventory/orainstRoot.sh' with root privileges on nodes
'dm01db01'. If you do not register the inventory, you may not be able to update
or patch the products you installed.

The following configuration scripts need to be executed as the "root" user in
each cluster node:

/u01/app/oraInventory/orainstRoot.sh #On nodes dm01db01

/u01/app/12.1.0.2/grid/root.sh #On nodes dm01db01

5. 次に示すように、端末のウィンドウの構成スクリプトを実行します。

a. 端末のウィンドウを開きます。

b. rootユーザーとしてログインします。

c. 各クラスタ・ノードのスクリプトを実行します。

スクリプトの実行後、次のメッセージが表示されます。

The Cluster Node Addition of /u01/app/12.1.0.2/grid was successful.
Please check '/tmp/silentInstall.log' for more details.

6. 次のコマンドを使用して、交換データベース・サーバーのorainstRoot.shおよびroot.shスクリプトを実行します。サンプルの出力が表示されます。

# /u01/app/oraInventory/orainstRoot.sh
Creating the Oracle inventory pointer file (/etc/oraInst.loc)
Changing permissions of /u01/app/oraInventory.
Adding read,write permissions for group.
Removing read,write,execute permissions for world.
Changing groupname of /u01/app/oraInventory to oinstall.
The execution of the script is complete.

# /u01/app/12.1.0.2/grid/root.sh

注意:

/u01/app/12.1.0.2/grid/install/ログ・ファイルで、root.shスクリプトの出力結果を確認します。

7. クラスタを確認します。

$ /u01/app/12.1.0.2/grid/bin/crsctl check cluster -all

**************************************************************
node1:
CRS-4537: Cluster Ready Services is online
CRS-4529: Cluster Synchronization Services is online
CRS-4533: Event Manager is online
**************************************************************
node2:
CRS-4537: Cluster Ready Services is online
CRS-4529: Cluster Synchronization Services is online
CRS-4533: Event Manager is online
**************************************************************
node3:
CRS-4537: Cluster Ready Services is online
CRS-4529: Cluster Synchronization Services is online
CRS-4533: Event Manager is online

関連トピック

- Oracle Real Application Clusters管理およびデプロイメント・ガイド

2.15.10 作業10: 交換データベース・サーバーへのOracle Databaseホームのクローニング

次の手順は、交換サーバーへのOracle Databaseホームのクローニング方法を示しています。

動作しているデータベース・サーバーから、oracleユーザーとしてコマンドを実行します。コマンドの実行にrootユーザーが必要な場合はコールアウトされます。

1. 次のコマンドを使用して、Oracle Database ORACLE_HOMEを交換データベース・サーバーに追加します。

$ cd /u01/app/oracle/product/12.1.0.2/dbhome_1/addnode

$ ./addnode.sh -silent "CLUSTER_NEW_NODES={replacement_server}"

2つ目のコマンドを使用すると、Oracle Universal InstallerによってOracle Databaseソフトウェアが交換データベース・サーバーにコピーされます。

WARNING: The following configuration scripts need to be executed as the "root"
user in each cluster node.
/u01/app/oracle/product/12.1.0.2/dbhome_1/root.sh #On nodes dm01db01
To execute the configuration scripts:
Open a terminal window.
Log in as root.
Run the scripts on each cluster node.

スクリプトの完了後、次のメッセージが表示されます。

The Cluster Node Addition of /u01/app/oracle/product/12.1.0.2/dbhome_1 was successful.
Please check '/tmp/silentInstall.log' for more details.

2. 交換データベース・サーバーで次のスクリプトを実行します。

# /u01/app/oracle/product/12.1.0.2/dbhome_1/root.sh

スクリプトの出力で/u01/app/orcale/product/12.1.0.2/dbhome_1/install/root_replacement_server.com_date.logファイルを確認します。

3. 対話型モードでDBCAを実行して、ターゲット・ノードにデータベース・インスタンスを追加します。

a. DBCAを起動します。

$ cd /u01/app/oracle/product/12.1.0.2/dbhome_1/bin

$ ./dbca

b. 「データベース操作」画面で、「インスタンス管理」を選択します。「次へ」をクリックします。

c. 「インスタンス操作」画面で、「インスタンスの追加」を選択します。「次へ」をクリックします。

d. 「データベース・リスト」画面で、インスタンスを追加するクラスタ・データベースを選択します。

e. 「リスト・インスタンス」画面に現在のインスタンスが表示されます。「次へ」をクリックして新しいインスタンスを追加します。

f. 「インスタンスの追加」画面に、デフォルト名と、クラスタに新しく追加されたノードが表示されます。デフォルト値をそのまま使用して「次へ」をクリックします。

g. 「サマリー」画面で、計画を確認し、「終了」をクリックします。

h. 「進行状況」画面で、完了率が100%になるまで待機します。

i. 「終了」画面で、新しいインスタンスが正常に追加されたという確認を承認します。

インスタンスが追加されたことを確認します。

$ srvctl config database -db dbm01

ターゲット・ノードの管理権限を確認します。

$ cd /u01/app/oracle/product/12.1.0.2/dbhome_1/bin

$ ./cluvfy comp admprv -o db_config -d /u01/app/oracle/product/12.1.0.2/dbhome_1 -n new_node

4. インスタンス・パラメータが交換したデータベース・インスタンスに設定されていることを確認します。次に、CLUSTER_INTERCONNECTSパラメータの例を示します。

SQL> SHOW PARAMETER cluster_interconnects

NAME                                 TYPE        VALUE
------------------------------       --------    -------------------------
cluster_interconnects                string

SQL> ALTER SYSTEM SET cluster_interconnects='192.168.73.90' SCOPE=spfile SID='dbm1';

5. 構成ファイルを次のように検証します。

- ORACLE_HOME/dbs/initSID.oraファイルは、Oracle ASM共有記憶域のSPFILEを指します。

- ORACLE_HOME/dbディレクトリにコピーされるパスワードは、orapwSIDに変更されています。

6. 以前にこのインスタンスを取り込んだサービスがないかを確認して、サービスを更新してこの交換インスタンスを含めます。

7. この手順をOracle Exadata Database Machineエイス・ラックで実行した場合は、「Oracle Exadata Database Machineエイス・ラックのOracle Linuxデータベース・サーバーのリカバリ後の構成」の手順を実行します。

関連トピック

- Oracle Real Application Clusters管理およびデプロイメント・ガイド

2.16 データベース・サーバーの既存のエラスティック構成の変更

この項では、既存のエラスティック構成に次の変更を行う方法について説明します。

- クラスタへの新しいデータベース・サーバーの追加

- 別のクラスタへの既存データベース・サーバーの移動

- Oracle RACからのデータベース・サーバーの削除

ストレージ・セルを伴う変更については、「ストレージ・セルの既存のエラスティック構成の変更」を参照してください。

2.16.1 クラスタへの新しいデータベース・サーバーの追加

このシナリオでは、Exadata上の既存のOracle RACに新しいデータベース・サーバーを追加します。

1. 新しいデータベース・サーバーを再イメージ化する必要があるかどうかを確認します。

新しいデータベース・サーバーを追加するクラスタ内のデータベース・サーバーのイメージ・ラベルをチェックします。クラスタ内の既存のデータベース・サーバーのイメージ・ラベルとの一致のためにデータベース・サーバーの再イメージ化が必要な場合は、「Oracle Linuxデータベース・サーバーの再イメージ化」の作業1、2、4、5および6に従ってデータベース・サーバーを再イメージ化します。

アップグレードが必要な場合は、dbnodeupdate.shを使用してアップグレードを実行できます。詳細は、「Oracle Linuxデータベース・サーバーの更新」を参照してください。

2. クラスタにデータベース・サーバーを追加します。

これを実行するには、「Oracle Linuxデータベース・サーバーの再イメージ化」の作業7以降の作業を実行してください。

3. 最新のexachkをダウンロードして実行し、結果の構成にOracle Exadataの最新のベスト・プラクティスが実装されたことを確認します。

2.16.2 別のクラスタへの既存データベース・サーバーの移動

このシナリオでは、既存のデータベース・サーバーを再利用し、同じExadataラック内の別のクラスタに移動します。

1. 既存のクラスタからデータベース・サーバーを削除します。

a. データベース・サーバー上のグリッド・インフラストラクチャを停止します。

$GI_HOME/bin/crstl stop crs

b. 「Oracle Linuxデータベース・サーバーの再イメージ化」の作業3を実行して、クラスタからデータベース・サーバーを削除します。

2. 再利用するデータベース・サーバーの再イメージ化が必要かどうかを確認します。
再利用するデータベース・サーバーを追加するクラスタ内のデータベース・サーバーのイメージ・ラベルをチェックします。クラスタ内の既存のデータベース・サーバーのイメージ・ラベルとの一致のために再利用するデータベース・サーバーの再イメージ化が必要な場合は、「Oracle Linuxデータベース・サーバーの再イメージ化」の作業1、2、4、5および6に従ってデータベース・サーバーをイメージ化します。

アップグレードが必要な場合は、dbnodeupdate.shを使用してアップグレードを実行できます。詳細は、My Oracle Supportノート1553103.1を参照してください。

3. クラスタにデータベース・サーバーを追加します。
これを実行するには、「Oracle Linuxデータベース・サーバーの再イメージ化」の作業7以降の作業を実行してください。

4. 最新のexachkをダウンロードして実行し、結果の構成にOracle Exadataの最新のベスト・プラクティスが実装されたことを確認します。

2.16.3 Oracle RACからのデータベース・サーバーの削除

このシナリオでは、Oracle RACから、それに含まれているデータベース・サーバーを削除します。

1. 削除するデータベース・サーバー上のグリッド・インフラストラクチャを停止します。

$GI_HOME/bin/crstl stop crs

2. 「Oracle Linuxデータベース・サーバーの再イメージ化」の「作業3: クラスタの障害が発生したデータベース・サーバーの削除」を実行して、クラスタからデータベース・サーバーを削除します。

3. 最新のExaCHKをダウンロードして実行し、結果の構成にOracle Exadataの最新のベスト・プラクティスが実装されたことを確認します。

2.17 高冗長性ディスク・グループのためのQuorumディスクの管理

この項には次のサブセクションが含まれます:

- Quorumディスク管理の概要

- Quorumディスク管理のソフトウェア要件

- Quorumディスクのデータベース・ノードへの追加

- quorumディスクの再作成

- ユースケース

- quorumdiskmgrリファレンス

2.17.1 Quorumディスク管理の概要

Oracle Exadataリリース12.1.2.3.0で導入されたQuorumディスク管理ユーティリティは、quorumディスクの管理に役立ちます。

このユーティリティを使用してiSCSI quorumディスクを2つのデータベース・ノード上に作成し、それら2つのquorumディスクに投票ファイルを格納できます。追加された2つの投票ファイルは、投票ファイル5つという高冗長性ディスク・グループの最小要件を満たすために使用されます。この機能は、次の要件を満たすOracle Exadataラックにのみ適用されます。

- Oracle Exadataラック内のストレージ・サーバーの数が5台未満。

- Oracle Exadataラック内に少なくとも2つのデータベース・ノードがある。

- Oracle Exadataラックに少なくとも1つの高冗長性ディスク・グループがある。

さらに2つの障害グループが存在することから、この機能では投票ファイルがOracle Exadataラック(ストレージ・サーバーが5台未満)上の高冗長性ディスク・グループに格納されます。

この機能を使用しない場合、投票ファイルはExadataラック(ストレージ・サーバーが5台未満)上の標準冗長性ディスク・グループに格納されます。これによりOracle Grid Infrastructureは二重パートナ・ストレージ・サーバー障害に対して脆弱になり、投票ファイルquorumが喪失し、その結果クラスタおよびデータベースの完全停止を招くこともあります。このシナリオにおけるクラスタウェアおよびデータベースの再起動については、My Oracle Supportノート1339373.1を参照してください。

RDSの使用でib0とib1のIPアドレスの可用性が高くなるため、iSCSI quorumディスクの実装は高い可用性を実現します。将来的に内部ネットワークの構成の柔軟化または分離が行われても、このマルチパス機能によりiSCSI quorumディスク実装はシームレスに動作し続けます。

次の図内の各iSCSIデバイスは、iSCSIターゲットに向かう特定のパスに対応しています。各パスはデータベース・ノードのInfiniBandポートに対応しています。アクティブ–アクティブ・システム内のマルチパスquorumディスク・デバイスごとに、2つのiSCSIデバイス(ib0用とib1用)があります。

図2-8 アクティブ-アクティブ・システムにおいて、両方のiSCSIデバイスに接続するマルチパス・デバイス

この機能はベア・メタルOracle RACクラスタとOracle VM Oracle RACクラスタで使用できます。Oracle VM Oracle RACクラスタの場合、次の図に示すように、quorumディスク・デバイスが存在するOracle RACクラスタはOracle VMユーザー・ドメインです。

図2-9 Oracle VM Oracle RACクラスタ上のquorumディスク・デバイス

pkeyが有効の環境では、ターゲットの発見に使用するインタフェースをOracle Clusterware通信で使用するpkeyインタフェースにする必要があります。これらのインタフェースは次のコマンドを使用すると表示されます。

Grid_home/bin/oifcfg getif | grep cluster_interconnect | awk '{print $1}'

Quorumディスク管理ユーティリティ(quorumdiskmgr)は、iSCSI構成、iSCSIターゲット、iSCSI LUN、iSCSIデバイスなど、この機能の実装に必要なすべてのコンポーネントを作成および管理するために使用します。

関連トピック

- quorumdiskmgrリファレンス

- 「Exadata環境でディスク・グループが失われた後のリカバリの操作手順」(Doc ID 1339373.1)

2.17.2 Quorumディスク管理のソフトウェア要件

この機能を使用するには、次のリリースが必要です。

- Oracle Exadata softwareリリース12.1.2.3.0以上

- すべてのデータベース・ホームにパッチ23200778を適用

- Oracle Grid Infrastructure 12.1.0.2.160119(パッチ22722476および22682752を適用)またはOracle Grid Infrastructure 12.1.0.2.160419以上
新規のデプロイメントでは、OEDAによってパッチが自動的にインストールされます。

2.17.3 Quorumディスクのデータベース・ノードへの追加

高冗長性ディスク・グループおよび5台未満のストレージ・ディスクを含むOracle Exadataラック上のデータベース・ノードに、quorumディスクを追加することができます。

この項の例では、2つのデータベース・ノード(db01およびdb02)のあるクオータ・ラックにquorumディスクを作成します。

これは、アクティブ-アクティブ・システムです。db01およびdb02の両方には、2つのInfiniBandポート、ib0およびib1があります。

iSCSIデバイスとの通信に使用するネットワーク・インタフェースは次のコマンドを使用して確認できます。

$ oifcfg getif | grep cluster_interconnect | awk '{print $1}'

各インタフェースのIPアドレスは次のコマンドを使用して確認できます。

ip addr show interface_name

この例のInfiniBand IPアドレスは次のとおりです。

db01:

- ネットワーク・インタフェース: ib0、IPアドレス: 192.168.10.45

- ネットワーク・インタフェース: ib1、IPアドレス: 192.168.10.46

db02:

- ネットワーク・インタフェース: ib0、IPアドレス: 192.168.10.47

- ネットワーク・インタフェース: ib1、IPアドレス: 192.168.10.48

quorumディスクが追加されるOracle ASMディスク・グループは、DATAC1です。Oracle ASM所有者はgridで、ユーザー・グループはdbaです。

投票ファイルは当初、標準冗長性ディスク・グループRECOC1に配置されています。

$ Grid_home/bin/crsctl query css votedisk
##  STATE    File Universal Id                File Name Disk group
--  -----    -----------------                --------- ---------
1. ONLINE   21f5507a28934f77bf3b7ecf88b26c47 (o/192.168.76.187;192.168.76.188/RECOC1_CD_00_celadm12) [RECOC1]
2. ONLINE   387f71ee81f14f38bfbdf0693451e328 (o/192.168.76.189;192.168.76.190/RECOC1_CD_00_celadm13) [RECOC1]
3. ONLINE   6f7fab62e6054fb8bf167108cdbd2f64 (o/192.168.76.191;192.168.76.192/RECOC1_CD_00_celadm14) [RECOC1]
Located 3 voting disk(s).

1. db01およびdb02に、ルートとしてログインします。

2. quorumdiskmgrコマンドを--create --configオプションを使用して実行し、quorumディスク構成をdb01およびdb02の両方に作成します。

# /opt/oracle.SupportTools/quorumdiskmgr --create --config --owner=grid --group=dba --network-iface-list="ib0, ib1"

3. quorumdiskmgrコマンドを--list --configオプションを使用して実行し、構成がdb01およびdb02の両方に正しく作成されたことを確認します。

# /opt/oracle.SupportTools/quorumdiskmgr --list --config

出力は次のようになります:

Owner: grid
Group: dba
ifaces: exadata_ib1 exadata_ib0

4. quorumdiskmgrコマンドを--create --targetオプションを使用して実行し、Oracle ASMディスク・グループDATAC1のターゲットをdb01およびdb02の両方に作成し、db01およびdb02の両方で表示されるようにします。

# /opt/oracle.SupportTools/quorumdiskmgr --create --target --asm-disk-group=datac1 --visible-to="192.168.10.45, 192.168.10.46, 192.168.10.47, 192.168.10.48"

5. quorumdiskmgrコマンドを--list --targetオプションを使用して実行し、ターゲットがdb01およびdb02の両方に正しく作成されたことを確認します。

# /opt/oracle.SupportTools/quorumdiskmgr --list --target

db01では、出力は次のようになります。

Name: iqn.2015-05.com.oracle:QD_DATAC1_DB01
Size: 128 MB
Host name: DB01
ASM disk group name: DATAC1
Visible to: 192.168.10.45, 192.168.10.46, 192.168.10.47, 192.168.10.48
Discovered by:

db02では、出力は次のようになります。

Name: iqn.2015-05.com.oracle:QD_DATAC1_DB02
Size: 128 MB
Host name: DB02
ASM disk group name: DATAC1
Visible to: 192.168.10.45, 192.168.10.46, 192.168.10.47, 192.168.10.48
Discovered by:

6. quorumdiskmgrコマンドを--create --deviceオプションを使用して実行し、db01およびdb02の両方のターゲットから、db01およびdb02の両方にデバイスを作成します。

# /opt/oracle.SupportTools/quorumdiskmgr --create --device --target-ip-list="192.168.10.45, 192.168.10.46, 192.168.10.47, 192.168.10.48"

7. quorumdiskmgrコマンドを--list --deviceオプションを使用して実行し、デバイスがdb01およびdb02の両方に正しく作成されたことを確認します。

# /opt/oracle.SupportTools/quorumdiskmgr --list --device

db01およびdb02の両方で、出力は次のようになります。

Device path: /dev/exadata_quorum/QD_DATAC1_DB01
Size: 128 MB
Host name: DB01
ASM disk group name: DATAC1

Device path: /dev/exadata_quorum/QD_DATAC1_DB02
Size: 128 MB
Host name: DB02
ASM disk group name: DATAC1

8. db01またはdb02のいずれかで、gridユーザーに切り替えます。

9. Oracle ASM環境を設定します。

10. asm_diskstring初期化パラメータを変更し、既存の文字列に/dev/exadata_quorum/*を追加します

SQL> alter system set asm_diskstring='o/*/DATAC1_*','o/*/RECOC1_*','/dev/exadata_quorum/*' scope=both sid='*';

11. 2つのquorumディスク・デバイスが、Oracle ASMにより自動的に検知されたことを確認します。

SQL> set linesize 200
SQL> col path format a50
SQL> select inst_id, label, path, mode_status, header_status
from gv$asm_disk where path like '/dev/exadata_quorum/%';

出力は次のようになります:

INST_ID LABEL          PATH                                MODE_STATUS HEADER_STATUS
------- -------------- ----------------------------------  ----------- ---------
1 QD_DATAC1_DB01 /dev/exadata_quorum/QD_DATAC1_DB01  ONLINE      CANDIDATE
1 QD_DATAC1_DB02 /dev/exadata_quorum/QD_DATAC1_DB02  ONLINE      CANDIDATE
2 QD_DATAC1_DB01 /dev/exadata_quorum/QD_DATAC1_DB01  ONLINE      CANDIDATE
2 QD_DATAC1_DB02 /dev/exadata_quorum/QD_DATAC1_DB02  ONLINE      CANDIDATE

12. 2つのquorumディスク・デバイスを高冗長性Oracle ASMディスク・グループに追加します。

高冗長性ディスク・グループがない場合は、高冗長性ディスク・グループを作成して、この2つの新しいquorumディスクを含めます。次に例を示します。

SQL> create diskgroup DATAC1 high redundancy quorum failgroup db01 disk '/dev/exadata_quorum/QD_ DATAC1_DB01' quorum failgroup db02 disk '/dev/exadata_quorum/QD_ DATAC1_DB02' ...

高冗長性ディスク・グループがすでに存在する場合は、2つの新しいquorumディスクを追加します。次に例を示します。

SQL> alter diskgroup datac1 add quorum failgroup db01 disk '/dev/exadata_quorum/QD_DATAC1_DB01' quorum failgroup db02 disk '/dev/exadata_quorum/QD_DATAC1_DB02';

13. 標準冗長性ディスク・グループの既存の投票ファイルを高冗長性ディスク・グループに移します。

$ Grid_home/bin/crsctl replace votedisk +DATAC1

14. 投票ディスクが高冗長性ディスク・グループに移動し、5つの投票ファイルが存在することを確認します。

crsctl query css votedisk

出力には、ストレージ・サーバーからの投票ディスク3つと、データベース・ノードからの投票ディスク2つが表示されます。

## STATE File Universal Id File Name Disk group
-- ----- ----------------- --------- ---------
1. ONLINE ca2f1b57873f4ff4bf1dfb78824f2912 (o/192.168.10.42/DATAC1_CD_09_celadm12) [DATAC1]
2. ONLINE a8c3609a3dd44f53bf17c89429c6ebe6 (o/192.168.10.43/DATAC1_CD_09_celadm13) [DATAC1]
3. ONLINE cafb7e95a5be4f00bf10bc094469cad9 (o/192.168.10.44/DATAC1_CD_09_celadm14) [DATAC1]
4. ONLINE 4dca8fb7bd594f6ebf8321ac23e53434 (/dev/exadata_quorum/QD_ DATAC1_DB01) [DATAC1]
5. ONLINE 4948b73db0514f47bf94ee53b98fdb51 (/dev/exadata_quorum/QD_ DATAC1_DB02) [DATAC1]
Located 5 voting disk(s).

15. Oracle ASMパスワード・ファイルとOracle ASM SPFILEを高冗長性ディスク・グループに移動します。

a. Oracle ASMパスワード・ファイルを移動します。

i) ソースのOracle ASMパスワード・ファイルの場所を取得します。

$ asmcmd pwget --asm

ii) Oracle ASMパスワード・ファイルを高冗長性ディスク・グループに移動します。

$ asmcmd pwmove --asm full_path_of_source_file full_path_of_destination_file

次に例を示します。

asmcmd pwmove --asm +recoc1/ASM/PASSWORD/pwdasm.256.898960531 +datac1/asmpwdfile

b. Oracle ASM SPFILEを移動します。

i) 現在使用しているOracle ASM SPFILEを取得します。

$ asmcmd spget

ii) Oracle ASM SPFILEを高冗長性ディスク・グループにコピーします。

$ asmcmd spcopy full_path_of_source_file full_path_of_destination_file

iii) 次の再起動時に移動したSPFILEが使用されるように、Oracle Grid Infrastructure構成を変更します。

$ asmcmd spset full_path_of_destination_file

このコマンドはOracle RACのいずれかのOracle VMクラスタ・ノードから実行する必要があります。

ダウンタイムが発生しても構わなければ、次のコマンドを使用してこの時点でOracle Grid Infrastructureを再起動します。

# Grid_home/bin/crsctl stop crs
# Grid_home/bin/crsctl start crs

ダウンタイムを許容できない場合は、Oracle Grid Infrastructureを再起動するまでの間は、Oracle ASM SPFILEの初期化パラメータの変更が必要になるたびに手順15.bを繰り返します。

16. MGMTDBを高冗長性ディスク・グループに移動します。

「別の共有記憶域(ディスク・グループ、CFS、NFSなど)にGI管理リポジトリを移動または再作成する方法」(Doc ID 1589394.1)を参照して、MGMTDB (実行している場合)を高冗長性ディスク・グループに移動します。

次の手順を使用し、hugepagesを使用しないようにMGMTDBを構成します。

export ORACLE_SID=-MGMTDB
export ORACLE_HOME=$GRID_HOME
sqlplus ”sys as sysdba”
SQL> alter system set use_large_pages=false scope=spfile  sid='*';

17. この手順はオプションです。

a. Oracle Grid Infrastructureを再起動します。

# Grid_home/bin/crsctl stop crs
# Grid_home/bin/crsctl start crs

b. 標準冗長性ディスク・グループを高冗長性ディスク・グループに変換します。

ディスク・グループの冗長性を変更する方法の詳細は、「データベースを別のディスク・グループに移動する方法(ディスク・グループの冗長性の変更)」(Doc ID 438580.1)を参照してください。

2.17.4 quorumディスクの再作成

状況によっては、quorumディスクの再作成が必要になる場合があります。

quorumディスクを再作成する必要があるのは次のような場合です。

- ゲストdomUを再作成するとき

- quorumディスクを削除したが事前にOracle ASMディスク・グループからquorumディスクを削除(drop)していないとき

1. なくなったquorumディスクの削除(drop)を強制的に実行します。

ALTER DISKGROUP dg_name DROP QUORUM DISK disk_name FORCE;

2. 「Quorumディスクのデータベース・ノードへの追加」の指示に従い、新しいquorumディスクを追加します。

関連トピック

- Quorumディスクのデータベース・ノードへの追加

2.17.5 ユースケース

- Oracle Exadata 12.1.2.3.0以降での新規デプロイメント

- Oracle Exadataリリース12.1.2.3.0以降へのアップグレード

- 12.1.2.3.0より前のOracle Exadataリリースへのダウングレード

- エラスティック構成の変更

2.17.5.1 Oracle Exadata 12.1.2.3.0以降での新規デプロイメント

Oracle Exadataリリース12.1.2.3.0以上での新規デプロイメントでは、次の要件がすべて満たされる場合、OEDAによってデフォルトでこの機能が実装されます。

- システムに少なくとも2つのデータベース・ノードと5台未満のストレージ・サーバーが含まれている。

- OEDAリリース2016年2月以降を実行している。

- 「Quorumディスク管理のソフトウェア要件」に記載されているソフトウェア要件を満たしている。

- Oracle Databaseが11.2.0.4以上である。

- システム上に少なくとも1つの高冗長性ディスク・グループがある。

システム上に3台のストレージ・サーバーがある場合、OEDAによって選択されたクラスタ内の最初の2つのデータベース・ノードに、2つのquorumディスクが作成されます。

システム上に4台のストレージ・サーバーがある場合、OEDAによって選択された最初のデータベース・ノードに、1つのquorumディスクが作成されます。

2.17.5.2 Oracle Exadataリリース12.1.2.3.0以降へのアップグレード

ターゲットのExadataシステム内に5台未満のストレージ・サーバー、少なくとも1つの高冗長性ディスク・グループおよび2つ以上のデータベース・ノードがある場合、quorumdiskmgrを使用して手動でこの機能を実装できます。

関連トピック

- Quorumディスクのデータベース・ノードへの追加

2.17.5.3 12.1.2.3.0より前のOracle Exadataリリースへのダウングレード

quorumディスクをサポートする12.1.2.3.0以上のリリースからquorumディスクをサポートしない12.1.2.3.0より前のOracle Exadataリリースにロールバックするには、環境にquorumディスク実装が存在する場合はquorumディスク構成を削除する必要があります。Exadataソフトウェアのロールバックを実行する前に、quorumディスク構成を削除する必要があります。

quorumディスク構成を削除するには、次の手順を実行します。

1. 1つ以上の標準冗長性ディスク・グループが存在することを確認します。ない場合は作成します。

2. 標準冗長性ディスク・グループに投票ファイルを再配置します。

$GI_HOME/bin/crsctl replace votedisk +normal_redundancy_diskgroup

3. ASMからquorumディスクを削除します。各quorumディスクに対して次のコマンドを実行します。

SQL> alter diskgroup diskgroup_name drop quorum disk quorum_disk_name force;

リバランス操作が完了するまで待機します。v$asm_operationによってディスク・グループの行が返されなくなったら、完了です。

4. quorumデバイスを削除します。quorumディスクが存在する各データベース・ノードから次のコマンドを実行します。

/opt/oracle.SupportTools/quorumdiskmgr --delete --device [--asm-disk-group asm_disk_group] [--host-name host_name]

5. ターゲットを削除します。quorumディスクが存在する各データベース・ノードから次のコマンドを実行します。

/opt/oracle.SupportTools/quorumdiskmgr --delete --target [--asm-disk-group asm_disk_group]

6. 構成を削除します。quorumディスクが存在する各データベース・ノードから次のコマンドを実行します。

/opt/oracle.SupportTools/quorumdiskmgr --delete –config

2.17.5.4 エラスティック構成の変更

- データベース・ノードの追加

- データベース・ノードの削除

- Oracle Exadata Storage Serverの追加および既存の高冗長性ディスク・グループの拡張

- Oracle Exadata Storage Serverの削除

2.17.5.4.1 データベース・ノードの追加

既存のRACクラスタに2つ未満のデータベース・ノードと5台未満のストレージ・サーバーが含まれていて、投票ファイルが高冗長性ディスク・グループに配置されていない場合は、quorumディスクをデータベース・ノードに追加し、投票ファイルを高冗長性ディスク・グループに移動することをお薦めします。

注意:

「Quorumディスク管理のソフトウェア要件」に示されている要件を満たしている必要があります。

関連トピック

- Quorumディスクのデータベース・ノードへの追加

2.17.5.4.2 データベース・ノードの削除

削除するデータベース・ノードがquorumディスクをホストしていない場合は、必要な処置はありません。

削除するデータベース・ノードが投票ファイルを含むquorumディスクをホストしていて、RACクラスタ内のストレージ・サーバーが5台未満の場合、データベース・ノードを削除する前に別のデータベース・ノードにquorumディスクを作成する必要があります。次の手順を実行します。

1. 現在quorumディスクをホストしていないデータベース・ノードにquorumディスクを作成します。

a. db01およびdb02に、ルートとしてログインします。

b. quorumdiskmgrコマンドを--create --configオプションを使用して実行し、quorumディスク構成をdb01およびdb02の両方に作成します。

# /opt/oracle.SupportTools/quorumdiskmgr --create --config --owner=grid
--group=dba --network-iface-list="ib0, ib1"

c. quorumdiskmgrコマンドを--list --configオプションを使用して実行し、構成がdb01およびdb02の両方に正しく作成されたことを確認します。

# /opt/oracle.SupportTools/quorumdiskmgr --list --config

出力は次のようになります:

Owner: grid
Group: dba
ifaces: exadata_ib1 exadata_ib0

d. quorumdiskmgrコマンドを--create --targetオプションを使用して実行し、ASMディスク・グループDATAC1のターゲットをdb01およびdb02の両方に作成し、両方で表示されるようにします。

# /opt/oracle.SupportTools/quorumdiskmgr --create --target
--asm-disk-group=datac1
--visible-to="192.168.10.45, 192.168.10.46, 192.168.10.47, 192.168.10.48"

e. quorumdiskmgrコマンドを--list --targetオプションを使用して実行し、ターゲットがdb01およびdb02の両方に正しく作成されたことを確認します。

# /opt/oracle.SupportTools/quorumdiskmgr --list --target

db01では、出力は次のようになります。

Name: iqn.2015-05.com.oracle:QD_DATAC1_DB01
Size: 128 MB
Host name: DB01
ASM disk group name: DATAC1
Visible to: 192.168.10.45, 192.168.10.46, 192.168.10.47, 192.168.10.48
Discovered by:

db02では、出力は次のようになります。

Name: iqn.2015-05.com.oracle:QD_DATAC1_DB02
Size: 128 MB
Host name: DB02
ASM disk group name: DATAC1
Visible to: 192.168.10.45, 192.168.10.46, 192.168.10.47, 192.168.10.48
Discovered by:

f. quorumdiskmgrコマンドを--create --deviceオプションを使用して実行し、db01およびdb02の両方のターゲットから、db01およびdb02の両方にデバイスを作成します。

# /opt/oracle.SupportTools/quorumdiskmgr --create --device
--target-ip-list="192.168.10.45, 192.168.10.46, 192.168.10.47, 192.168.10.48"

g. quorumdiskmgrコマンドを--list --deviceオプションを使用して実行し、デバイスがdb01およびdb02の両方に正しく作成されたことを確認します。

# /opt/oracle.SupportTools/quorumdiskmgr --list --device

db01およびdb02の両方で、出力は次のようになります。

Device path: /dev/exadata_quorum/QD_DATAC1_DB01
Size: 128 MB
Host name: DB01
ASM disk group name: DATAC1
Device path: /dev/exadata_quorum/QD_DATAC1_DB02
Size: 128 MB
Host name: DB02
ASM disk group name: DATAC1

h. 2つのquorumディスク・デバイスを高冗長性ASMディスク・グループに追加します。
高冗長性ディスク・グループがない場合は、高冗長性ディスク・グループを作成して、この2つの新しいquorumディスクを含めます。次に例を示します。

SQL> create diskgroup DATAC1 high redundancy quorum failgroup db01 disk '/dev/exadata_quorum/QD_ DATAC1_DB01' quorum failgroup db02 disk '/dev/exadata_quorum/QD_ DATAC1_DB02' ...

高冗長性ディスク・グループがすでに存在する場合は、2つの新しいquorumディスクを追加します。次に例を示します。

SQL> alter diskgroup datac1 add quorum failgroup db01 disk '/dev/exadata_quorum/QD_DATAC1_DB02' quorum failgroup db02 disk '/dev/exadata_quorum/QD_DATAC1_DB01';

2. データベース・ノードを削除すると、投票ファイルが手順1で追加したquorumディスクに自動的に再配置されます。

2.17.5.4.3 Oracle Exadata Storage Serverの追加および既存の高冗長性ディスク・グループの拡張

quorumディスクを使用するストレージ・サーバーを追加する場合は、新しく追加するストレージ・サーバーにデータベース・ノード上の投票ファイルを再配置することをお薦めします。

1. Exadataストレージ・サーバーを追加します。詳細は、「セル・ノードの追加」を参照してください。
次の例では、追加される新しいストレージ・サーバーの名前は"celadm04"です。

2. ストレージ・サーバーの追加後、v$asm_disk内の新しい障害グループを確認します。

SQL> select distinct failgroup from v$asm_disk;
FAILGROUP
------------------------------
ADM01
ADM02
CELADM01
CELADM02
CELADM03
CELADM04

3. 少なくとも1つのデータベース・ノードに投票ファイルを含むquorumディスクが含まれていることを確認します。

$ crsctl query css votedisk
##  STATE    File Universal Id                File Name Disk group
--  -----    -----------------                --------- ---------
1. ONLINE   834ee5a8f5054f12bf47210c51ecb8f4 (o/192.168.12.125;192.168.12.126/DATAC5_CD_00_celadm01) [DATAC5]
2. ONLINE   f4af2213d9964f0bbfa30b2ba711b475 (o/192.168.12.127;192.168.12.128/DATAC5_CD_00_celadm02) [DATAC5]
3. ONLINE   ed61778df2964f37bf1d53ea03cd7173 (o/192.168.12.129;192.168.12.130/DATAC5_CD_00_celadm03) [DATAC5]
4. ONLINE   bfe1c3aa91334f16bf78ee7d33ad77e0 (/dev/exadata_quorum/QD_DATAC5_ADM01) [DATAC5]
5. ONLINE   a3a56e7145694f75bf21751520b226ef (/dev/exadata_quorum/QD_DATAC5_ADM02) [DATAC5]
Located 5 voting disk(s).

この例では、2つのデータベース・ノード上に投票ファイルを含む2つのquorumディスクがあります。

4. いずれか1つのquorumディスクを削除します。

SQL> alter diskgroup datac5 drop quorum disk QD_DATAC5_ADM01;

削除したquorumディスク上の投票ファイルは、投票ファイルのリフレッシュ時にグリッド・インフラストラクチャによって、新しく追加したストレージ・サーバー上に自動的に再配置されます。これは次の方法で確認できます。

$ crsctl query css votedisk
##  STATE    File Universal Id                File Name Disk group
--  -----    -----------------                --------- ---------
1. ONLINE   834ee5a8f5054f12bf47210c51ecb8f4 (o/192.168.12.125;192.168.12.126/DATAC5_CD_00_celadm01) [DATAC5]
2. ONLINE   f4af2213d9964f0bbfa30b2ba711b475 (o/192.168.12.127;192.168.12.128/DATAC5_CD_00_celadm02) [DATAC5]
3. ONLINE   ed61778df2964f37bf1d53ea03cd7173 (o/192.168.12.129;192.168.12.130/DATAC5_CD_00_celadm03) [DATAC5]
4. ONLINE   a3a56e7145694f75bf21751520b226ef (/dev/exadata_quorum/QD_DATAC5_ADM02) [DATAC5]
5. ONLINE   ab5aefd60cf84fe9bff6541b16e33787 (o/192.168.12.131;192.168.12.132/DATAC5_CD_00_celadm04) [DATAC5]

2.17.5.4.4 Oracle Exadata Storage Serverの削除

ストレージ・サーバーを削除した結果、Oracle RACクラスタで使用されるストレージ・サーバーが5台未満になる場合で投票ファイルが高冗長性ディスク・グループ内にある場合は、データベース・ノードにquorumディスクを追加する(まだ存在しない場合)ことをお薦めします。

ストレージ・サーバーを削除する前にquorumディスクを追加しておき、ストレージ・サーバーの削除後すぐに5つの投票ファイルのコピーを使用できるようにしておきます。

関連トピック

- Quorumディスクのデータベース・ノードへの追加

2.17.6 quorumdiskmgrリファレンス

quorumディスク管理ユーティリティ(quorumdiskmgr)を各データベース・サーバーで実行すると、iSCSI quorumディスクをデータベース・サーバー上に作成できます。quorumdiskmgrを使用して、iSCSI quorumディスクをデータベース・サーバーで作成、リスト、変更および削除できます。出荷時に、ユーティリティはデータベース・サーバーにインストールされます。

このリファレンスの項の内容は、次のとおりです。

- Quorumディスク管理ユーティリティの構文

- quorumdiskmgrオブジェクト

- Quorumディスク構成の作成(--create --config)

- ターゲットの作成(--create --target)

- デバイスの作成(--create --device)

- Quorumディスク構成のリスト(--list --config)

- ターゲットのリスト(--list --target)

- デバイスのリスト(--list --device)

- 構成の削除(--delete --config)

- ターゲットの削除(--delete --target)

- デバイスの削除(--delete --device)

- 所有者とグループ値の変更(--alter --config)

- InfiniBand IPアドレスの変更(--alter --target)

2.17.6.1 Quorumディスク管理ユーティリティの構文

quorumディスク管理ユーティリティは、コマンドライン・ツールです。構文は次のとおりです。

quorumdiskmgr --verb --object [--options]

verbは、オブジェクト上で実行されるアクションです。これは、alter、create、delete、listのいずれかです。

objectは、コマンドでアクションを実行するオブジェクトです。

optionsは、コマンドの追加パラメータを使用できるようにコマンドの組合せの使用範囲を拡大します。

quorumdiskmgrユーティリティを使用する場合は、次のルールが適用されます:

- 動詞、オブジェクトおよびオプションは、明示的に指定されている場合を除き、大/小文字が区別されます。

- 二重引用符文字を使用して、オプションの値をスペースおよび句読点を含めて囲みます。

2.17.6.2 quorumdiskmgrオブジェクト

オブジェクト

説明

config

quorumディスク構成には、iSCSI quorumディスクを追加するASMインスタンスの所有者およびグループ、およびローカルおよびリモートiSCSI quorumディスクの発見で使用するネットワーク・インタフェースのリストが含まれます。

target

ターゲットは、各データベース・サーバー上のエンドポイントで、iSCSIイニシエータがセッションを確立するまで待機し、必要なIOデータ転送を提供します。

device

デバイスは、iSCSIデバイスで、ローカルまたはリモート・ターゲットへのログインで作成されます。

2.17.6.3 Quorumディスク構成の作成(--create --config)

--create --configアクションは、quorumディスク構成を作成します。構成は、ターゲットまたはデバイスが作成される前に作成する必要があります。

構文

quorumdiskmgr --create --config [--owner owner --group group] --network-iface-list network-iface-list

パラメータ

次の表に、--create --configアクションのパラメータを示します。

パラメータ

説明

owner

iSCSI quorumディスクを追加するASMインタフェースの所有者を指定します。これはオプションのパラメータです。デフォルト値は、gridです。

group

iSCSI quorumディスクを追加するASMインタフェースのグループを指定します。これはオプションのパラメータです。デフォルト値はdbaです。

network-iface-list

ローカルおよびリモート・ターゲットの発見で使用されるネットワーク・インタフェース名のリストを指定します。

例

quorumdiskmgr --create --config --owner=oracle --group=dba --network-iface-list="ib0, ib1"

2.17.6.4 ターゲットの作成(--create --target)

--create --targetアクションは、指定されたInfiniBand IPアドレスのリスト内のInfiniBand IPアドレスを使用してデータベース・サーバーによりアクセスされるターゲットを作成し、指定されたASMディスク・グループに追加されるデバイスを作成します。

ターゲットが作成されると、そのasm-disk-group、host-nameおよびsize属性は変更できません。

構文

quorumdiskmgr --create --target --asm-disk-group asm_disk_group --visible-to infiniband_ip_list [--host-name host_name] [--size size]

パラメータ

パラメータ

説明

asm-disk-group

ターゲットから作成されるデバイスが追加されるASMディスク・グループを指定します。asm-disk-groupの値は大/小文字が区別されません。

visible-to

InfiniBand IPアドレスのリストを指定します。リスト内のInfiniBand IPアドレスを持つデータベース・サーバーは、ターゲットへのアクセスがあります。

host-name

quorumdiskmgrが稼働するデータベース・サーバーのホスト名を指定します。asm-disk-groupおよびhost-nameの合計の長さは、26文字を超えてはいけません。ホスト名が長すぎる場合、クオータ・ラックの各データベース・サーバーに別々のホスト名が指定されている場合にかぎり、短いホスト名を指定できます。

これはオプションのパラメータです。デフォルト値は、quorumdiskmgrが稼働するデータベース・サーバーのホスト名です。host-nameの値は大/小文字が区別されません。

size

ターゲットのサイズを指定します。これはオプションのパラメータです。デフォルト値は128MBです。

例

quorumdiskmgr --create --target --size=128MB --asm-disk-group=datac1 --visible-to="192.168.10.45, 192.168.10.46" --host-name=db01

2.17.6.5 デバイスの作成(--create --device)

--create --deviceアクションは、指定されたIPアドレスのリスト内のInfiniBand IPアドレスを使用してターゲットを発見およびログインし、デバイスを作成します。

作成されたデバイスは、構成の作成中に指定された所有者およびグループのあるASMインスタンスにより、自動的に発見されます。

構文

quorumdiskmgr --create --device --target-ip-list target_ip_list

パラメータ

パラメータ

説明

target-ip-list

InfiniBand IPアドレスのリストを指定します。quorumdiskmgrは、InfiniBand IPアドレスを持つデータベース・サーバー上のターゲットを発見し、ターゲットにログインしてデバイスを作成します。

例

quorumdiskmgr --create --device --target-ip-list="192.168.10.45, 192.168.10.46"

2.17.6.6 Quorumディスク構成のリスト(--list --config)

--list --configアクションは、quorumディスク構成をリストします。

構文

quorumdiskmgr --list --config

出力例

Owner: grid
Group: dba
ifaces: exadata_ib1 exadata_ib0

2.17.6.7 ターゲットのリスト(--list --target)

--list --targetアクションは、ターゲット名、サイズ、ホスト名、ASMディスク・グループ名、ターゲットに対してアクセスを持つデータベース・サーバーを示すIPアドレスのリスト(visible-to IPアドレス・リスト)およびターゲットにログインしたデータベース・サーバーを示すIPアドレスのリスト(discovered-by IPアドレス・リスト)を含むターゲットの属性をリストします。

ASMディスク・グループが指定された場合、アクションは、指定されたASMディスク・グループに作成されたすべてのローカル・ターゲットをリストします。それ以外の場合、アクションは、quorumディスクに作成されたすべてのローカル・ターゲットをリストします。

構文

quorumdiskmgr --list --target [--asm-disk-group asm_disk_group]

パラメータ

パラメータ

説明

asm-disk-group

ASMディスク・グループを指定します。quorumdiskmgrは、このASMディスク・グループのすべてのローカル・ターゲットを表示します。asm-disk-groupの値は大/小文字が区別されません。

出力例

Name: iqn.2015-05.com.oracle:QD_DATAC1_DB01
Size: 128 MB
Host name: DB01
ASM disk group name: DATAC1
Visible to: 192.168.10.48, 192.168.10.49, 192.168.10.46, 192.168.10.47
Discovered by: 192.168.10.47, 192.168.10.46

2.17.6.8 デバイスのリスト(--list --device)

--list --deviceアクションは、デバイス・パス、サイズ、ホスト名およびASMディスク・グループを含むデバイスの属性をリストします。

ASMディスク・グループ名のみが指定された場合、アクションは、ASMディスク・グループに追加されたすべてのデバイスをリストします。

ホスト名のみが指定された場合、アクションは、ホスト上のターゲットから作成されたすべてのデバイスをリストします。

ASMディスク・グループ名およびホスト名の両方が指定された場合、ホスト上のターゲットから作成され、ASMディスク・グループに追加された単一のデバイスをリストします。

ASMディスク・グループ名およびホスト名のいずれも指定されない場合、アクションは、すべてのquorumディスク・デバイスをリストします。

構文

quorumdiskmgr --list --device [--asm-disk-group asm_disk_group] [--host-name host_name]

パラメータ

パラメータ

説明

asm-disk-group

デバイスが追加されたASMディスク・グループを指定します。asm-disk-groupの値は大/小文字が区別されません。

host-name

ターゲット・デバイスが作成されたデータベース・サーバーのホスト名を指定します。host-nameの値は大/小文字が区別されません。

出力例

Device path: /dev/exadata_quorum/QD_DATAC1_DB01
Size: 128 MB
Host name: DB01
ASM disk group name: DATAC1

Device path: /dev/exadata_quorum/QD_DATAC1_DB02
Size: 128 MB
Host name: DB02
ASM disk group name: DATAC1

2.17.6.9 構成の削除(--delete --config)

--delete --configアクションは、quorumディスク構成を削除します。構成は、ターゲットまたはデバイスが存在しない場合にのみ削除できます。

構文

quorumdiskmgr --delete --config

2.17.6.10 ターゲットの削除(--delete --target)

--delete --targetアクションは、データベース・サーバー上のquorumディスクに作成されたターゲットを削除します。

ASMディスク・グループが指定された場合、アクションは、指定されたASMディスク・グループに作成されたすべてのローカル・ターゲットを削除します。それ以外の場合、アクションは、quorumディスクに作成されたすべてのローカル・ターゲットを削除します。

構文

quorumdiskmgr --delete --target [--asm-disk-group asm_disk_group]

パラメータ

パラメータ

説明

asm-disk-group

ASMディスク・グループを指定します。このディスク・グループに作成されたローカル・ターゲットが削除されます。asm-disk-groupの値は大/小文字が区別されません。

例

quorumdiskmgr --delete --target --asm-disk-group=datac1

2.17.6.11 デバイスの削除(--delete --device)

--delete --deviceアクションは、quorumディスク・デバイスを削除します。

ASMディスク・グループ名のみが指定された場合、アクションは、ASMディスク・グループに追加されたすべてのデバイスを削除します。

ホスト名のみが指定された場合、アクションは、ホスト上のターゲットから作成されたすべてのデバイスを削除します。

ASMディスク・グループ名およびホスト名の両方が指定された場合、ホスト上のターゲットから作成され、ASMディスク・グループに追加された単一のデバイスを削除します。

ASMディスク・グループ名およびホスト名のいずれも指定されない場合、アクションは、すべてのquorumディスク・デバイスを削除します。

構文

quorumdiskmgr --delete --device [--asm-disk-group asm_disk_group] [--host-name host_name]

パラメータ

パラメータ

説明

asm-disk-group

削除する対象のデバイスのASMディスク・グループを指定します。asm-disk-groupの値は大/小文字が区別されません。

host-name

データベース・サーバーのホスト名を指定します。このホスト上のターゲットから作成されたデバイスが削除されます。host-nameの値は大/小文字が区別されません。

例

quorumdiskmgr --delete --device --host-name=db01

2.17.6.12 所有者とグループ値の変更(--alter --config)

--alter --configアクションは、所有者およびグループ構成を変更します。

構文

quorumdiskmgr --alter --config --owner owner --group group

パラメータ

パラメータ

説明

owner

quorumディスク構成の新しい所有者を指定します。このパラメータは省略可能です。指定しない場合、所有者は変更されません。

group

quorumディスク構成の新しいグループを指定します。このパラメータは省略可能です。指定しない場合、グループは変更されません。

例

quorumdiskmgr --alter --config --owner=grid --group=dba

2.17.6.13 InfiniBand IPアドレスの変更(--alter --target)

--alter --targetアクションは、指定されたASMディスク・グループに作成されたローカル・ターゲットへのアクセスを持つデータベース・サーバーのInfiniBand IPアドレスを変更します。

構文

quorumdiskmgr --alter --target --asm-disk-group asm_disk_group --visible-to infiniband_ip_list

パラメータ

パラメータ

説明

asm-disk-group

ターゲットから作成されるデバイスが追加されるASMディスク・グループを指定します。asm-disk-groupの値は大/小文字が区別されません。

visible-to

InfiniBand IPアドレスのリストを指定します。リスト内のInfiniBand IPアドレスを持つデータベース・サーバーは、ターゲットへのアクセスがあります。

例

quorumdiskmgr --alter --target --asm-disk-group=datac1 --visible-to="192.168.10.45, 192.168.10.47"

2.18 vmetricsの使用

vmetricsパッケージを使用すると、vmetricsサービスで収集されたシステム統計を表示できます。dom0またはdomUから、システム統計にアクセスできます。vmetricsサービスはdom0上で稼働して、統計を収集し、それらをxenstoreへプッシュします。これにより、domU'sが統計にアクセスできます。

vmetricsサービスによって収集されたシステム統計を、サンプル値を使用して次に表示します:

com.sap.host.host.VirtualizationVendor=Oracle Corporation;

com.sap.host.host.VirtProductInfo=Oracle VM 3;

com.sap.host.host.PagedInMemory=0;

com.sap.host.host.PagedOutMemory=0;

com.sap.host.host.PageRates=0;

com.sap.vm.vm.uuid=2b80522b-060d-47ee-8209-2ab65778eb7e;

com.sap.host.host.HostName=scac10adm01.us.oracle.com;

com.sap.host.host.HostSystemInfo=scac10adm01;

com.sap.host.host.NumberOfPhysicalCPUs=24;

com.sap.host.host.NumCPUs=4;

com.sap.host.host.TotalPhyMem=98295;

com.sap.host.host.UsedVirtualMemory=2577;

com.sap.host.host.MemoryAllocatedToVirtualServers=2577;

com.sap.host.host.FreeVirtualMemory=29788;

com.sap.host.host.FreePhysicalMemory=5212;

com.sap.host.host.TotalCPUTime=242507.220000;

com.sap.host.host.Time=1453150151;

com.sap.vm.vm.PhysicalMemoryAllocatedToVirtualSystem=8192;

com.sap.vm.vm.ResourceMemoryLimit=8192;

com.sap.vm.vm.TotalCPUTime=10160.1831404;

com.sap.vm.vm.ResourceProcessorLimit=4;

2.18.1 vmetricsサービスのインストールと起動

vmetricsサービスをインストールするには、dom0上でrootユーザーとしてinstall.shスクリプトを実行します:

[root@scac10adm01]# cd /opt/oracle.SupportTools/vmetrics
[root@scac10adm01]# ./install.sh

install.shスクリプトは、それがdom0で実行中であり、現在実行中のvmetricsサービスを停止、パッケージ・ファイルを/opt/oracle.vmetricsにコピーおよびvmetrics.svcを/etc/init.dにコピーすることを、確認します。

vmetricsサービスをdom0で開始するには、dom0上でrootユーザーとして次のコマンドを実行します:

[root@scac10adm01 vmetrics]# service vmetrics.svc start

統計を収集するコマンドは、30秒ごとに実行されます。

2.18.2 vmetricsパッケージ内のファイル

vmetricsパッケージには次のファイルが含まれます:

ファイル

説明

install.sh

このファイルは、パッケージをインストールします。

vm-dump-metrics

このスクリプトは、統計をxenstoreから読み取り、それらをXML形式で表示します。

vmetrics

このPythonスクリプトは、システム・コマンドを実行し、それらをxenstoreにアップロードします。システム・コマンドは、vmetrics.confファイル内にリストされています。

vmetrics.conf

このXMLファイルは、dom0がxenstoreへプッシュするべきメトリックおよび各メトリックで実行するシステム・コマンドを指定します。

vmetrics.svc

vmetricsをLinuxサービスにするinit.dファイル。

2.18.3 統計の表示

統計がxenstoreにプッシュされた後、次のいずれかのコマンドを実行すると、dom0およびdomU上に統計を表示できます:

注意:

domU's上に、xenstoreproviderおよびovmdパッケージがインストールされていることを確認してください。

xenstoreproviderは、ovmapiカーネル・インフラストラクチャと通信するライブラリです。

ovmdは、構成および再構成イベントを処理し、VMとOracle VMマネージャの間でメッセージを送信/受信するメカニズムを提供するするデーモンです。

次のコマンドを使用して、Oracle VM APIをサポートするためにOracle Linux 5および6で必要なパッケージをインストールします。

# yum install ovmd xenstoreprovider

- /usr/sbin/ovmd -g vmhostコマンドは、1つのライン上の統計を表示します。sedコマンドは、ラインを複数のラインに分割し、ラインごとに統計します。このコマンドは、rootユーザーとして実行する必要があります。

root@scac10db01vm04 ~]# /usr/sbin/ovmd -g vmhost |sed 's/; */;\n/g;s/:"/:"\n/g'
com.sap.host.host.VirtualizationVendor=Oracle Corporation;
com.sap.host.host.VirtProductInfo=Oracle VM 3;
com.sap.host.host.PagedInMemory=0;
com.sap.host.host.PagedOutMemory=0;
com.sap.host.host.PageRates=0;
com.sap.vm.vm.uuid=2b80522b-060d-47ee-8209-2ab65778eb7e;
com.sap.host.host.HostName=scac10adm01.us.oracle.com;
com.sap.host.host.HostSystemInfo=scac10adm01;
com.sap.host.host.NumberOfPhysicalCPUs=24;
com.sap.host.host.NumCPUs=4;
...

- vm-dump-metricsコマンドは、XML形式でメトリックを表示します。

[root@scac10db01vm04 ~]# ./vm-dump-metrics
<metrics>
<metric type='real64' context='host'>
<name>TotalCPUTime</name>
<value>242773.600000</value>
</metric>
<metric type='uint64' context='host'>
<name>PagedOutMemory</name>
<value>0</value>
</metric>
...

vm-dump-metricsコマンドを、コマンドを実行するdomU'sにコピーすることに注意してください。

2.18.4 vmetricsへのメトリックの追加

独自のメトリックを追加して、vmetricsサービスで収集することができます。

1. /opt/oracle.SupportTools/vmetrics/vmetrics.confに、新しいメトリック、およびそのメトリックを取得および解析するためのシステム・コマンドを追加します。次に例を示します。

<metric type="uint32" context="host">
<name>NumCPUs</name>
<action>grep -c processor /proc/cpuinfo</action>
<action2>xm list | grep '^Domain-0' |awk '{print $4}'</action2>
</metric>

<name>要素に、新しいメトリックの名前を入力します。

<action>および<action2>要素に、新しいメトリックのシステム・コマンドを指定します。<action2>のみが必要ですが、<action2>がシステムで機能しない場合は、<action>をフォールバックとして使用できます。

vmの名前が必要なアクションはいずれもscas07client07vm01を使用する必要があることに留意してください。vmetricsが稼働すると、このダミー名を、dom0で稼働中の実際のdomU名とスワップします。

2. /opt/oracle.SupportTools/vmetrics/vmetricsで、リストgFieldsList内のメトリックを追加します。メトリックがホスト(dom0)に関する場合、メトリック名に接頭辞"host"を追加し、メトリックがvm (domU)に関する場合、"vm"を追加します。次に例を示します。

gFieldsListは、次のようになります:

gFieldsList = [ 'host.VirtualizationVendor',
'host.VirtProductInfo',
'host.PagedInMemory',
'vm.ResourceProcessorLimit' ]

"NumCPUs" (手順1の例で示すように)という名の新しいメトリックを追加して、このメトリックがdomUに対して、dom0がいくつの使用可能なCPUを持つか告げる場合、gFieldsListは、次のようになります:

gFieldsList = [ 'host.VirtualizationVendor',
'host.VirtProductInfo',
'host.PagedInMemory',
'vm.ResourceProcessorLimit',
'host.NumCPUs']

3. (オプション) /opt/oracle.SupportTools/vmetrics/vm-dump-metricsに、新しいメトリックをXML出力に含めたい場合、新しいメトリックを追加します。

この手順をスキップすると、ovmd -g vmhostコマンドを使用して新しいメトリックを表示できます。

3 Oracle ExadataラックのExadata Storage Serverの保守

この章のトピックは、次のとおりです:

- Exadata Storage Serverの保守

- Exadata Storage Serverの物理ディスクの保守

- フラッシュ・ディスクの保守

- グリッド・ディスクのサイズ変更

- Oracle Exadata Storage Server Softwareレスキュー手順の使用

- 「ストレージ・セルの既存のエラスティック構成の変更」

注意:

- 読みやすさを考慮して、Oracle Exadata Database MachineとOracle Exadata Storage拡張ラックの両方に言及する場合、「Oracle Exadataラック」という名前を使用します。

- この章のすべての手順は、Oracle Exadata Database MachineおよびOracle Exadata Storage拡張ラックに適用されます。

関連トピック

- 交換ユニット

- Oracle Exadata Database MachineおよびOracle Exadataラックのエラー・メッセージ

3.1 Exadata Storage Serverの保守

この項では、Exadata Storage Serverの保守を実行する方法について説明します。次の項目が含まれます。

- Exadata Storage Serverのシャットダウン

- Exadata Storage Serverの削除

- リバランス操作のステータスのチェック

- Exadataセルのパッチ適用の理解

- 診断ISOを使用したネットワーク接続の有効化

関連項目:

Oracle ASMディスク修復タイマーの詳細は、Oracle Exadata Storage Server Softwareユーザーズ・ガイドを参照してください。

3.1.1 Exadata Storage Serverのシャットダウン

Exadata Storage Serverの保守を実行する場合、セルの電源切断または再起動が必要になることがあります。1つ以上のデータベースの実行中にExadata Storage Serverを停止する場合、Exadata Storage ServerのオフラインによるOracle ASMディスク・グループおよびデータベース可用性への影響がないことを確認してください。データベース可用性に影響を与えないでExadata Storage Serverをオフラインにする機能は、影響するディスク・グループで使用されるOracle ASM冗長性のレベルおよびオフラインにするExadata Storage Serverのデータのミラー・コピーを含む他のExadata Storage Serverのディスクの現在のステータスによって異なります。

次の手順は、Exadata Storage Serverの電源の切断方法を示しています。

1. (オプション)次のコマンドを実行して、セルの再起動後にグリッド・ディスクがオフラインのままになるようにします。

CellCLI> ALTER GRIDDISK ALL INACTIVE

この手順は、再起動を複数回実行したり、セルを再びアクティブにするタイミングを制御する場合(計画されていた保守アクティビティが成功したことを確認してからセルを使用する場合など)に役立ちます。

注意:

この手順を実行する場合は、手順6を実行してグリッド・ディスクをアクティブにする必要があります。

2. 次のコマンドを使用して、セル・サービスを停止します。

CellCLI> ALTER CELL SHUTDOWN SERVICES ALL

前述のコマンドでは、オフラインのディスクがないか、predictive failureステータスのディスクがないか、またはミラーにコピーする必要があるディスクがないかをチェックします。Oracle ASM冗長性が損なわれていない場合は、コマンドによりOracle ASMでグリッド・ディスクがオフラインに変更され、セル・サービスが停止されます。次のエラーが表示された場合は、冗長性が原因でディスク・グループが強制的にディスマウントされ、セル・サービスを安全に停止できない可能性があります。

Stopping the RS, CELLSRV, and MS services...
The SHUTDOWN of ALL services was not successful.
CELL-01548: Unable to shut down CELLSRV because disk group DATA, RECO may be
forced to dismount due to reduced redundancy.
Getting the state of CELLSRV services... running
Getting the state of MS services... running
Getting the state of RS services... running

エラーが発生した場合は、Oracle ASMディスク・グループの冗長性をリストアし、すべてのディスクのディスク・ステータスが正常に戻ってからコマンドを再試行してください。

3. セルを停止します。

4. 保守の実行後、セルの電源を投入します。セル・サービスが自動的に開始されます。セルの起動の一環として、Oracle ASMですべてのグリッド・ディスクが自動的にONLINEになります。

5. 次のコマンドを使用して、すべてのグリッド・ディスクが正常にオンラインになったことを確認します。

CellCLI> LIST GRIDDISK ATTRIBUTES name, asmmodestatus

すべてのグリッド・ディスクのasmmodestatusがONLINEまたはUNUSEDになるまで待機します。

6. 次のコマンドを使用して、グリッド・ディスクをオンラインに設定します。この手順は、手順1を実行した場合にのみ必要です。手順1を実行していない場合は、グリッド・ディスクは自動的にアクティブになります。

CellCLI> ALTER GRIDDISK ALL ACTIVE

関連トピック

- Exadata Storage Serverの電源切断

3.1.2 Exadata Storage Serverの削除

次の手順は、Exadata Storage Serverの削除方法を示しています。

1. Oracle ASMから次のコマンドを使用して、物理ディスクのOracle ASMディスクを削除します。

SQL> ALTER DISKGROUP diskgroup_name DROP DISKS IN FAILGROUP failgroup_name;

Oracle ASMの正しい冗長性レベルを確認するには、先に進む前にリバランスの完了を待機します。

2. Exadata Storage Serverにアクセスする各データベース・サーバーのcellip.oraファイルからIPアドレス・エントリを削除します。

3. 次のコマンドを使用して、Exadata Storage Serverから物理ディスクのグリッド・ディスク、セル・ディスクおよびセルを削除します。

CellCLI> DROP CELLDISK

4. Exadata Storage Server上のすべてのサービスをシャットダウンします。

5. セルの電源を切断します。

関連項目:

Exadata Storage Serverのシャットダウン

3.1.3 リバランス操作のステータスのチェック

ディスクを削除または追加すると、Oracle ASMリバランスが発生します。リバランスのステータスを確認するには、次の手順を実行します。

- リバランス操作が正しく実行された可能性がある場合。Oracle ASMアラート・ログを確認してください。

- リバランス操作が現在実行されている可能性がある場合。GV$ASM_OPERATIONビューを確認して、リバランス操作が実行されているかどうか判別します。

- リバランス操作が失敗した可能性がある場合。V$ASM_OPERATION.ERRORビューを確認して、リバランス操作が失敗したかどうか判別します。

- 交換される物理ディスクに複数のディスク・グループのASMディスクが含まれる場合、複数のディスク・グループのリバランス操作を同じクラスタの異なるOracle ASMインスタンスで実行できます。Oracle ASMインスタンスは、一度に1つのリバランス操作を実行できます。すべてのOracle ASMインスタンスがビジー状態の場合、リバランス操作がキューに入れられます。

注意:

BP4のOracle Databaseリリース12.1.0.2と一緒にOracle Exadata Storage Server Softwareリリース12.1.2.0を実行しているストレージ・サーバーで、Oracle ASMはリバランス操作のステータスについて電子メールを送信します。以前のリリースでは、管理者が操作のステータスをチェックする必要がありました。

3.1.4 Exadataセルのパッチ適用の理解

ソフトウェアの更新は、patchmgrユーティリティを使用してExadata Storage Serverに適用されます。patchmgrユーティリティにより、Exadata Storage Serverに必要なすべてのソフトウェアとファームウェアがインストールおよび更新されます。patchmgrユーティリティは、My Oracle Supportからダウンロードするソフトウェア・リリースに付属しています。

注意:

Exadata Storage Serverのソフトウェアをインストール、変更、再構成または削除する場合は、このガイド、『Oracle Exadata Storage Server Softwareユーザーズ・ガイド』またはMy Oracle Supportに記載されているOracle Exadata固有の指示に必ず従ってください。Exadata Storage Serverに対する変更は、特定のOracle Exadataドキュメントに記載がないかぎりサポートされません。

注意:

My Oracle Supportノート888828.1に説明されているように、Oracle Exadata Cellの通常の更新が適用できるのは、ターゲット・リリースの日付スタンプが現在実行中のリリースの日付スタンプより新しい場合のみです。ターゲット・リリースよりも新しい日付スタンプのリリースを実行しているイメージからの更新はブロックされます。

例: Exadataリリース12.1.2.1.0は、リリース番号に基づいた12.1.1.1.2よりも新しく思えますが、12.1.1.1.2.1 (日付スタンプが150411)の日付スタンプは、12.1.2.1.0 (141206)よりも新しいため、12.1.1.1.2.150411から12.1.2.1.0.141206.1の更新はブロックされます。このような状況では、同じメジャー・リリースで日付スタンプが新しいメンテナンス・リリースに更新する必要があります。

patchmgrユーティリティによるソフトウェアの更新は、構成内のすべてのExadataセルが対象となります。ユーティリティでは、ソフトウェアの更新方法としてローリングと非ローリングの両方がサポートされています。ユーティリティでは、パッチ適用の完了通知やローリング/非ローリング・パッチ適用のステータス情報を電子メール・メッセージで送信できます。次に、電子メール・メッセージを送信するためのコマンドを示します。

# ./patchmgr -cells cell_group -patch [-rolling] [-ignore_alerts] [-unkey] \
[-smtp_from "addr" -smtp_to "addr1 addr2 addr3 ..."]

前述のコマンドのaddrは送信元アドレス、addr1、addr2およびaddr3は送信先アドレスです。

この項では、Exadataセルにパッチを適用する各方法およびそれらの違いについて説明します。この項では、次の項目について説明します。

- ローリング更新の理解

- 非ローリング更新の理解

関連トピック

- sudoによるpatchmgr (およびdbnodeupdateオーケストレーション)の実行

3.1.4.1 ローリング更新の理解

ローリング更新は、デプロイメント全体での停止時間を伴わない方法としても知られます。

- この方法の利点:
データベースの停止時間が不要です。

問題が発生した場合に影響を受けるのは1つのセルのみです。

- この方法に関する考慮事項:
非ローリング更新よりもはるかに時間がかかります。セルは一度に1つずつ順番に処理されます。パッチの適用に最低限かかる概算時間は、非ローリング更新で1つのセルにパッチを適用するのにかかる時間にセルの数をかけたものになります。非ローリング更新で1つのセルの更新にかかる時間は約1時間です。ローリング更新を実行した場合、所要時間が非常に長くなる可能性があり、デプロイメントの負荷も大きくなります。このような負荷条件が、パッチ適用後のセルでグリッド・ディスクをアクティブ化および再アクティブ化するのにかかる時間に加算されます。

注意:

patchmgrユーティリティを起動するときは、ソフトウェア更新通知をサブスクライブすることをお薦めします。管理者ユーザーは、ソフトウェア更新がいつ完了するかを確実に知らせる電子メール通知を自動的に受信します。これにより、管理者が手動でセルのリブートを早く行い、ソフトウェア更新プロセスを中断することがなくなります。

Oracle ASMによりセルのグリッド・ディスクが削除されるのを回避するため、パッチ適用時にOracle ASMの修理タイムアウトを増やす必要があります。これらのグリッド・ディスクを再度追加することは、時間のかかる手動での作業になります。ディスク・グループのdisk_repair_timeは最低でもデフォルト値の3.6時間に設定するようにしてください。

注意:

- patchmgrユーティリティで-rollingオプションを指定してローリング更新またはロールバックを実行する場合は、My Oracle Supportノート1485475.1に列挙されている修正を事前にOracle Database 11gデータベースに適用してください。修正が必要なデータベース・リリースは、ノートに明記されています。

次に、ローリング更新を使用してExadataセルにパッチを適用する手順を簡単に説明します。これらの手順は、patchmgrユーティリティにより自動的に実行されます。

1. 1つのセル上の非アクティブ化対象のグリッド・ディスクをすべて非アクティブ化します。対象となるグリッド・ディスクのasmdeactivationoutcome属性がYesに設定されます。

2. 非アクティブ化したディスクがOFFLINEであることを確認します。

3. セルにパッチを適用します。

4. セルを再起動し、正常に起動したら、非アクティブ化したグリッド・ディスクをアクティブ化します。

5. Oracle ASMの再同期処理が完了するまで待機し、手順4でアクティブ化したグリッド・ディスクがONLINEになっていることを確認します。

6. パッチの適用対象となる次のセルに移動し、同じ手順を繰り返します。

patchmgrユーティリティでは、前述の手順が一度に1つのセルに対して実行されます。

3.1.4.2 非ローリング更新の理解

非ローリング更新は、デプロイメント全体での停止時間を伴う方法としても知られます。デプロイメント全体で停止するよう選択した場合は、パッチはすべてのセルにパラレルに適用されます。patchmgrユーティリティによりExadataセルにこの機能が提供されます。

- この方法の利点:
すべてのセルがパラレルに処理されます。そのため、パッチの適用時間は、適用対象となるセルの数に関係なく、ほぼ一定です。

グリッド・ディスクの非アクティブ化と再アクティブ化に費やす時間がゼロです。

- この方法に関する考慮事項:
パッチ適用プロセスの実行中はセルを使用できません。パッチの適用中は、セル・サービスを使用するすべてのデータベースを停止したままにする必要があります。

パッチの適用中にセルの1つで問題が発生した場合は、そのセルの問題が解決するまでデプロイメント全体が使用できなくなります。通常、Oracle Clusterwareを排他モードで起動し、Oracle ASMのディスク・グループをFORCEオプションによってマウントし、その後で問題のあるセルのグリッド・ディスクを削除することによって、データベースを起動することは可能です。ただし、これらの手順を実行することによって、停止時間がさらに延びます。

3.1.5 診断ISOを使用したネットワーク接続の有効化

再起動されないセルにアクセスして手動で修理する場合、診断ISOが必要になることがあります。ISOは、すべてのExadataセルの/opt/oracle.SupportTools/diagnostics.isoにあります。USBの使用など、他のブート方法が機能しない場合は、診断ISOを使用してください。

次に、ファイルを転送してセルを修理できるように、診断ISOとのネットワーキングを有効にする手順を示します。

1. Webインタフェースまたはシリアル・コンソールを使用して、サービス・プロセッサで1回のCD-ROMブートを有効にします。次に、シリアル・コンソールを使用する場合のコマンドの例を示します。

set boot_device=cdrom

2. サービス・プロセッサ・インタフェースを使用して、diagnostics.isoのローカル・コピーをCD-ROMとしてマウントします。

3. rebootコマンドを使用して、セルを再起動します。

4. rootユーザーとして診断ISOのパスワードを使用してセルにログインします。

5. 次のコマンドを使用してpingを回避します。

alias ping="ping -c"

6. /etc/networkという名前のディレクトリを作成します。

7. /etc/network/if-pre-up.dという名前のディレクトリを作成します。

8. /etc/network/interfacesファイルに次の行を追加します。

iface eth0 inet static
address IP_address_of_cell
netmask netmask_of_cell
gateway gateway_IP_address_of_cell

9. 次のコマンドを使用して、eth0インタフェースを起動します。

ifup eth0

いくつかの警告メッセージが表示される場合もありますが、インタフェースは稼働しています。

10. FTPまたはwgetコマンドを使用して、セルを修理するためのファイルを取得します。

3.2 Exadata Storage Serverの物理ディスクの保守

Exadata Storage Serverの最初の2枚のディスクは、システム・ディスクです。Oracle Exadata Storage Server Softwareシステム・ソフトウェアは、各システム・ディスクに割り当てられます。システム・ディスクのこの割り当てられた部分は、システム領域と呼ばれます。システム・ディスクのシステム領域以外は、データ・パーティションと呼ばれ、通常のデータ・ストレージに使用されます。セルの他のすべてのディスクは、データ・ディスクと呼ばれます。

CellCLI LIST PHYSICALDISKコマンドで属性を確認して、物理ディスクを監視できます。たとえば、物理ディスクのステータスが"failed" (以前のリリースでは、障害が発生した物理ディスクのステータスは"critical"でした)または"warning - predictive failure"と同等の場合、問題が発生している可能性があり、交換が必要です。内部しきい値を超えると、ディスク・ファームウェアによってエラー・カウンタが保守され、ドライブはPredictive Failureとマーク付けされます。交換が必要かどうかは、セル・ソフトウェアではなくドライブによって決定されます。

ディスクI/Oエラーが発生すると、Oracle ASMはメディア・エラーによる読取りエラーの障害範囲の修理を実行します。ディスクはオンラインのままで、アラートは送信されません。Oracle ASMが物理的に対処されたメタデータ・ブロックに関する読取りエラーを取得すると、ブロックはミラーリングされず、ディスクはオフラインになります。Oracle ASMは強制的にディスクを削除します。

表3-1に、Exadata Storage Serverの物理ディスク・ステータスを示します。

表3-1 Exadata Storage Serverの物理ディスク・ステータス

Oracle Exadata Storage Server Softwareリリース

物理ディスク・ステータス

リリース11.2.3.3以上

正常

正常 - 交換のため切断

正常 - 制限されたオンライン

正常 - 制限されたオンライン - 交換のため切断

存在しない

失敗

障害 - 交換のため切断

障害 - 不適切なディスク・モデルのため拒否

障害 - 不適切なディスク・モデルのため拒否 - 交換のため切断

障害 - 間違ったスロットのため拒否

障害 - 間違ったスロットのため拒否 - 交換のため切断

警告 - 制限されたオンライン

警告 - 制限されたオンライン - 交換のため切断

警告 - ピア障害

警告 - 低いパフォーマンス

警告 - 低いパフォーマンス - 交換のため切断

警告 - 低いパフォーマンス、ライトスルー・キャッシュ

警告 - 予測障害、低いパフォーマンス

警告 - 予測障害、低いパフォーマンス - 交換のため切断

警告 - 予測障害、ライトスルー・キャッシュ

警告 - 予測障害

警告 - 予測障害 - 交換のため切断

警告 - 予測障害、低いパフォーマンス、ライトスルー・キャッシュ

警告 - ライトスルー・キャッシュ

リリース11.2.3.2

正常

正常 - 制限されたオンライン

存在しない

失敗

障害 - 不適切なディスク・モデルのため拒否

障害 - 間違ったスロットのため拒否

警告 - 制限されたオンライン

警告 - ピア障害

警告 - 低いパフォーマンス

警告 - 低いパフォーマンス、ライトスルー・キャッシュ

警告 - 予測障害、低いパフォーマンス

警告 - 予測障害、ライトスルー・キャッシュ

警告 - 予測障害

警告 - 予測障害、低いパフォーマンス、ライトスルー・キャッシュ

警告 - ライトスルー・キャッシュ

リリース11.2.3.1.1以下

正常

予測障害

低いパフォーマンス

critical

存在しない

リリース11.2.3.2.0以上のOracle Exadata Storage Server Softwareでは、ディスクが交換可能であることを示すアラートが送信され、ディスクの外部にすべてのデータがリバランスされた後にそのディスクが予測障害を持つ場合、青色のLEDが点灯します。11.2.3.2.0より前のリリースでは、ディスクが予測障害を持つ場合、青色のLEDではなく、黄色のLEDが点灯しました。このような場合、ディスクの交換を進める前に、すべてのデータがそのディスクの外部にリバランスされたかどうかを手動でチェックする必要があります。

ディスクで障害が発生すると、ドライブの青色のLEDと黄色のLEDが両方とも点灯し、この場合、ディスクの交換を進めてもかまいません。動作はすべてのリリースで同じです。ただし、ドライブのLEDはリリース11.2.3.2.0では点灯したままになるのに対し、以前のリリースでは点滅します。

注意:

Exadata Storage Serverの物理ディスクを交換中、Oracle Exadataラックはオンラインで使用可能です。

この項では、次の項目について説明します。

- ハード・ディスク・コントローラのライトスルー・キャッシュ・モードの監視

- ディスク障害による物理ディスクの交換

- ディスクの問題による物理ディスクの交換

- 低いパフォーマンスによる物理ディスクの交換

- 物理ディスクの事前交換

- Exadata Storage Serverから別のExadata Storage Serverへのすべてのドライブの移動

- 物理ディスクの再利用

- 「同じ物理ディスクの取外しおよび交換」

- 拒否された物理ディスクの再有効化

関連項目:

- 予測障害および低いパフォーマンスのLEDステータス・ライトの詳細は、「LEDステータスの説明」を参照してください。

- LIST PHYSICALDISKコマンドの詳細は、Oracle Exadata Storage Server Softwareユーザーズ・ガイドを参照してください。

- 修復タイマーの設定の詳細は、『Oracle Exadata Storage Server Softwareユーザーズ・ガイド』を参照してください。

- 保守のベスト・プラクティスの詳細は、http://www.oracle.com/goto/maaのOracle Maximum Availability Architecture(MAA)Webサイトを参照してください。

- My Oracle Supportノート1084360.1のExadata環境の計算ノードのベア・メタル・リストア手順に関する項

3.2.1 ハード・ディスク・コントローラのライトスルー・キャッシュ・モードの監視

各Exadata Storage Serverのハード・ディスク・コントローラは、定期的にコントローラのバッテリの放電と充電を実行します。操作中は、書込みキャッシュ・ポリシーにより、ライトバック・キャッシュからライトスルー・キャッシュに変更されます。ライトスルー・キャッシュ・モードはライトバック・キャッシュ・モードより時間を要します。ただし、Exadata Storage Serverの電源が落ちたり障害が発生したりすると、ライトバック・キャッシュ・モードの場合はデータ損失のリスクがあります。リリース11.2.1.3より前のExadata Storage Serverリリースの場合、この処理は毎月発生します。リリース11.2.1.3.0以上のOracle Exadata Storage Server Softwareの場合、この処理は3か月ごとに発生します(例: 1月、4月、7月、10月の17日の01:00時)。学習サイクルの開始時間を変更するには、次のようなコマンドを使用します。サイクルが終了すると、時間はデフォルト学習時間に戻ります。

CellCLI> ALTER CELL bbuLearnCycleTime="2013-01-22T02:00:00-08:00"

次の学習サイクル時間を確認するには、次のコマンドを使用します。

CellCLI> LIST CELL ATTRIBUTES bbuLearnCycleTime

Exadata Storage Serverによって、次のようなセル上の論理ドライブのキャッシュ・モードの状態に関するアラート情報が生成されます。

HDD disk controller battery on disk contoller at adapter 0 is going into a learn
cycle. This is a normal maintenance activity that occurs quarterly and runs for
approximately 1 to 12 hours. The disk controller cache might go into WriteThrough
caching mode during the learn cycle. Disk write throughput might be temporarily
lower during this time. The message is informational only, no action is required.

バッテリのステータスを確認するには、次のコマンドを使用します。

# /opt/MegaRAID/MegaCli/MegaCli64 -AdpBbuCmd -GetBbuStatus -a0

次に、コマンドの出力例を示します。

BBU status for Adapter: 0

BatteryType: iBBU08
Voltage: 3721 mV
Current: 541 mA
Temperature: 43 C

BBU Firmware Status:
Charging Status : Charging
Voltage : OK
Temperature : OK
Learn Cycle Requested : No
Learn Cycle Active : No
Learn Cycle Status : OK
Learn Cycle Timeout : No
I2c Errors Detected : No
Battery Pack Missing : No
Battery Replacement required : No
Remaining Capacity Low : Yes
Periodic Learn Required : No
Transparent Learn : No

Battery state:

GasGuageStatus:
Fully Discharged : No
Fully Charged : No
Discharging : No
Initialized : No
Remaining Time Alarm : Yes
Remaining Capacity Alarm: No
Discharge Terminated : No
Over Temperature : No
Charging Terminated : No
Over Charged : No

Relative State of Charge: 7 %
Charger System State: 1
Charger System Ctrl: 0
Charging current: 541 mA
Absolute state of charge: 0 %
Max Error: 0 %

Exit Code: 0x00

3.2.2 ディスク障害による物理ディスクの交換

物理ディスクの停止により、パフォーマンスの低下およびデータの冗長性が発生する場合があります。したがって、すぐにディスクを新しいディスクに交換する必要があります。ディスクに障害が発生すると、物理ディスクのグリッド・ディスクに関連するOracle ASMディスクがFORCEオプションで自動的に削除され、Oracle ASMリバランスでデータの冗長性がリストアされます。

ディスクに障害が発生すると、Exadataアラートが生成されます。アラートには、ディスクを交換する特定の手順が含まれます。システムのアラート通知を構成している場合、電子メールでアラートが指定したアドレスに送信されます。

物理ディスクを交換すると、そのスロットの前のディスクにあったグリッド・ディスクとセル・ディスクは新しい物理ディスクに再作成されます。これらのグリッド・ディスクがOracle ASMグループの一部である場合、ディスク・グループの冗長性およびASM_POWER_LIMITパラメータに基づいて、ディスクがディスク・グループに追加され、データがリバランスされます。

注意:

BP4のOracle Databaseリリース12.1.0.2と一緒にOracle Exadata Storage Server Softwareリリース12.1.2.0を実行しているストレージ・サーバーで、Oracle ASMはリバランス操作のステータスについて電子メールを送信します。以前のリリースでは、管理者が操作のステータスをチェックする必要がありました。

以前のリリースについては、「リバランス操作のステータスのチェック」の説明に従ってリバランス操作ステータスをチェックしてください。

次の手順は、ディスク障害によるディスクの交換方法を示しています。

1. 次のコマンドを使用して、障害が発生したディスクを特定します。

CellCLI> LIST PHYSICALDISK WHERE diskType=HardDisk AND status=failed DETAIL

次に、コマンドの出力例を示します。スロット番号はディスクの場所、ステータスはディスクに障害が発生したことを示します。

CellCLI> LIST PHYSICALDISK WHERE diskType=HardDisk AND status=failed DETAIL

name:                   28:5
deviceId:               21
diskType:               HardDisk
enclosureDeviceId:      28
errMediaCount:          0
errOtherCount:          0
foreignState:           false
luns:                   0_5
makeModel:              "SEAGATE ST360057SSUN600G"
physicalFirmware:       0705
physicalInterface:      sas
physicalSerial:         A01BC2
physicalSize:           558.9109999993816G
slotNumber:             5
status:                 failed

2. ディスクを取り外す前に、ディスクの青い取外しOKのLEDが点灯していることを確認してください。

3. Exadata Storage Server上の物理ディスクを交換し、3分待ちます。物理ディスクはホットプラグ対応で、電源の投入時に交換できます。

4. ディスクがオンラインであることを確認します。

物理ディスクを交換する場合、使用前にディスクをRAIDコントローラで承認する必要があります。この処理にあまり時間は要しません。次のようなLIST PHYSICALDISKコマンドを使用して、ステータスがNORMALであることを確認します。

CellCLI> LIST PHYSICALDISK WHERE name=28:5 ATTRIBUTES status

5. ALTER CELL VALIDATE CONFIGURATIONコマンドを使用して、ファームウェアが正しいことを確認します。

まれに、自動ファームウェア更新が機能せず、LUNが再構築されない場合があります。これは、ms-odl.trcファイルをチェックして確認できます。

関連項目:

- Exadata Storage Serverの部品

- V$ASM_OPERATIONビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

- リバランス操作の詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。

3.2.3 ディスクの問題による物理ディスクの交換

ディスクがwarning - predictive failureステータスのため、物理ディスクの交換が必要な場合があります。predictive failureステータスは、物理ディスクに障害が発生する可能性があり、できるだけすぐに交換する必要があることを示します。物理ドライブのグリッド・ディスクに関連するOracle ASMディスクが自動的に削除され、Oracle ASMリバランスで障害が発生する可能性のあるディスクから他のディスクにデータが移動されます。

物理ドライブが故障する前に削除を完了できなかった場合は、「ディスク障害による物理ディスクの交換」を参照してください。

ディスクを削除すると、アラートが送信されます。物理ディスクを交換すると、スロットの前のディスクにあったグリッド・ディスクとセル・ディスクは新しい物理ディスクに再作成されます。これらのグリッド・ディスクがOracle ASMディスク・グループの一部である場合、ディスク・グループの冗長性およびASM_POWER_LIMITパラメータに基づいて、ディスクがディスク・グループに追加され、データがリバランスされます。

注意:

BP4のOracle Databaseリリース12.1.0.2と一緒にOracle Exadata Storage Server Softwareリリース12.1.2.0を実行しているストレージ・サーバーで、Oracle ASMはリバランス操作のステータスについて電子メールを送信します。以前のリリースでは、管理者が操作のステータスをチェックする必要がありました。

以前のリリースについては、「リバランス操作のステータスのチェック」の説明に従ってリバランス操作ステータスをチェックしてください。

次の手順は、ディスクの問題によるディスクの交換方法を示しています。

1. 次のコマンドを使用して、障害が発生したディスクを特定します。

CellCLI> LIST PHYSICALDISK WHERE diskType=HardDisk AND status= \
"warning - predictive failure" DETAIL

次に、コマンドの出力例を示します。スロット番号はディスクの場所、ステータスはディスクに障害が発生する可能性があることを示します。

CellCLI> LIST PHYSICALDISK WHERE diskType=HardDisk AND status= \
"warning - predictive failure" DETAIL
name:                   28:3
deviceId:               19
diskType:               HardDisk
enclosureDeviceId:      28
errMediaCount:          0
errOtherCount:          0
foreignState:           false
luns:                   0_3
makeModel:              "SEAGATE ST360057SSUN600G"
physicalFirmware:       0705
physicalInterface:      sas
physicalSerial:         E07L8E
physicalSize:           558.9109999993816G
slotNumber:             3
status:                 warning - predictive failure

2. ディスクを取り外す前に、ディスクの青い取外しOKのLEDが点灯していることを確認してください。

3. 物理ディスクのグリッド・ディスクに関連するOracle ASMディスクが正しく削除されるまで待機します。グリッド・ディスクが削除されたかどうか判別するには、Oracle ASMインスタンスのV$ASM_DISK_STATビューの問合せを実行します。

注意:

最初の2つのスロットのディスクは、オペレーティング・システムおよびOracle Exadata Storage Server Softwareを格納するシステム・ディスクです。1つのシステム・ディスクを稼働して、サーバーを維持する必要があります。

他のシステム・ディスクを交換する前に、ALTER CELL VALIDATE CONFIGURATIONにmdadmエラーが表示されなくなり、システム・ディスクの再同期化が完了するまで待機します。

4. Exadata Storage Server上の物理ディスクを交換し、3分待ちます。物理ディスクはホットプラグ対応で、電源の投入時に交換できます。

5. ディスクがオンラインであることを確認します。

物理ディスクを交換する場合、使用前にディスクをRAIDコントローラで承認する必要があります。この処理にあまり時間は要しません。次のようなLIST PHYSICALDISKコマンドを使用して、ステータスがNORMALであることを確認します。

CellCLI> LIST PHYSICALDISK WHERE name=28:5 ATTRIBUTES status

6. ALTER CELL VALIDATE CONFIGURATIONコマンドを使用して、ファームウェアが正しいことを確認します。

関連項目:

- Exadata Storage Serverの部品

- V$ASM_OPERATIONビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

- リバランス操作のチューニングの詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。

- V$ASM_DISK_STATビューの問合せの詳細は、『Oracle Databaseリファレンス』を参照してください。

- 『Oracle Exadata Storage Server Softwareユーザーズ・ガイド』のALTER CELL VALIDATE CONFIGURATIONコマンドに関する項

3.2.4 低いパフォーマンスによる物理ディスクの交換

1つの不良物理ディスクが、他の正常なディスクのパフォーマンスを低下させることがあります。不良ディスクはそのままにしないでシステムから削除する必要があります。リリース11.2.3.2以上では、パフォーマンスの低いディスクが自動的に識別され、アクティブな構成から削除されます。その後、Oracle Exadata Database Machineにより一連のパフォーマンス・テストが実行されます。CELLSRVでパフォーマンスの低いディスクが検出されると、セル・ディスクのステータスがnormal - confinedOnlineに変更され、物理ディスクのステータスがwarning - confinedOnlineに変更されます。次の状況はディスク制限のトリガーとなります。

- ディスクの応答停止。ストレージ・アラート・ログ内の原因コードはCD_PERF_HANGです。

- セル・ディスクの速度低下。次に例を示します。

- サービス時間のしきい値が高い(原因コードCD_PERF_SLOW_ABS)

- 相対的サービス時間のしきい値が高い(原因コードCD_PERF_SLOW_RLTV)

- 読取りまたは書込みでの長期待機時間。次に例を示します。

- 書込みでの待機時間が長い(原因コードCD_PERF_SLOW_LAT_WT)

- 読取りでの待機時間が長い(原因コードCD_PERF_SLOW_LAT_RD)

- 読取りおよび書込みでの待機時間が長い(原因コードCD_PERF_SLOW_LAT_RW)

- 頻繁に発生する個々のI/Oでの絶対的待機時間が非常に長い(原因コードCD_PERF_SLOW_LAT_ERR)

- I/Oエラーなどのエラー(原因コードCD_PERF_IOERR)。

ディスクの問題が一時的なものであり、テストに合格した場合は、そのディスクは構成に戻されます。ディスクがテストに合格しない場合は、poor performanceとしてマークされ、ASRによりディスク交換のためのサービス・リクエストが送信されます。可能な場合は、Oracle ASMによりグリッド・ディスクがテスト用にオフラインに変更されます。Oracle ASMがディスクをオフラインに変更できない場合、セル・ディスクのステータスは、ディスクを安全にオフラインに変更できるようになるまで、normal - confinedOnlineのまま変わりません。

ディスクのステータスの変更は、セルのアラート履歴にある次のエントリに関連付けられています。

MESSAGE ID date_time info "Hard disk entered confinement status. The LUN
n_m changed status to warning - confinedOnline. CellDisk changed status to normal
- confinedOnline. Status: WARNING - CONFINEDONLINE  Manufacturer: name  Model
Number: model  Size: size  Serial Number: serial_number  Firmware: fw_release
Slot Number: m  Cell Disk: cell_disk_name  Grid Disk: grid disk 1, grid disk 2
... Reason for confinement: threshold for service time exceeded"

ストレージ・セルのアラート・ログには次の情報が記録されます。

CDHS: Mark cd health state change cell_disk_name  with newState HEALTH_BAD_
ONLINE pending HEALTH_BAD_ONLINE ongoing INVALID cur HEALTH_GOOD
Celldisk entering CONFINE ACTIVE state with cause CD_PERF_SLOW_ABS activeForced: 0
inactiveForced: 0 trigger HistoryFail: 0, forceTestOutcome: 0 testFail: 0
global conf related state: numHDsConf: 1 numFDsConf: 0 numHDsHung: 0 numFDsHung: 0
...

注意:

11.2.3.2より前のリリースでは、CALIBRATEコマンドを使用して不良物理ディスクを識別し、各物理ディスクについてスループットやIOPSが極端に低くないか調べてください。

次の手順は、不良ディスクが確認された場合の物理ディスクの取外し方法を示しています。

1. 物理ドライブ・サービスLEDを点灯し、次のコマンドを使用して交換するドライブを識別します。

cellcli -e 'alter physicaldisk disk_name serviceled on'

前述のコマンドでdisk_nameは、20:2などの交換する物理ディスクの名前です。

2. 不良ディスクのすべてのグリッド・ディスクを確認します。次のコマンドを使用して、Oracle ASMに不良ディスクの使用をただちに停止するよう指示します。

SQL> ALTER DISKGROUP diskgroup_name DROP DISK asm_disk_name;

3. ディスクを取り外す前に、ディスクの青い取外しOKのLEDが点灯していることを確認してください。

4. V$ASM_DISK_STATビューの問合せを実行して、不良ディスクのグリッド・ディスクに関連するOracle ASMディスクが正しく削除されたことを確認します。

5. 不良ディスクを取り外します。ディスクを削除すると、アラートが送信されます。

6. 新しいディスクを使用できる場合、システムに新しいディスクを設置します。セル・ディスクおよびグリッド・ディスクが新しい物理ディスクに自動的に作成されます。

注意:

物理ディスクを交換する場合、使用前にディスクをRAIDコントローラで承認する必要があります。承認処理に時間はかかりませんが、LIST PHYSICALDISKコマンドを使用してステータスがNORMALであることを確認してください。

関連項目:

- Oracle Exadata Storage Server Softwareユーザーズ・ガイド

- ディスク・グループからのディスクの削除の詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。

3.2.5 物理ディスクの事前交換

Exadata Storageソフトウェアには、物理ディスクで障害が発生したか、問題のあるディスクとしてフラグが付けられた場合に物理ディスクを保守するための、自動化された完全な一連の操作が備えられています。ただし、物理ディスクを事前に構成から取り外す必要がある場合があります。

CellCLIのALTER PHYSICALDISKコマンドでは、drop for replacementオプションによって、データ損失のリスクなく安全に、正常に機能している物理ディスクを削除できるかどうかが確認されます。ただし、コマンドを実行した後、ストレージ・セルで物理ディスクのグリッド・ディスクが非アクティブ化され、Oracle ASMディスク・グループでオフラインに設定されます。

物理ディスクが交換または再有効化され、後続のリバランスが完了するまで、ディスク・グループの冗長性が損なわれます。このことは、標準冗長性を使用するディスク・グループにおいて特に重要です。

ディスク・グループで十分な冗長性を確保できないリスクを抑えて、事前に物理ディスクを交換するには、次の手順を実行します。

1. 物理ディスクに関連付けられたlun、celldiskおよびgriddiskを特定します。

次のようなコマンドを使用します。ここで、X:Yは交換するドライブの物理ディスク名を示します。

# cellcli –e "list diskmap" | grep 'X:Y'

2. 通常のモードで、Oracle ASMディスク・グループからグリッド・ディスクを削除します。

SQL> ALTER DISKGROUP diskgroup_name DROP DISK asm_disk_name;

3. リバランスが完了するまで待ちます。

4. drop for replacementを実行します。

次のようなコマンドを使用します。ここで、X:Yは交換するドライブの物理ディスク名を示します。

CellCLI> alter physicaldisk X:Y drop for replacement

5. ディスクを取り外す前に、ディスクの青い取外しOKのLEDが点灯していることを確認します。

6. 新しい物理ディスクに交換します。

7. 物理ディスクに関連付けられたlun、celldiskおよびgriddiskが作成されていることを確認します。

CellCLI> list lun lun_name
CellCLI> list celldisk where lun=lun_name
CellCLI> list griddisk where celldisk=celldisk_name

8. グリッド・ディスクがOracle ASMディスク・グループに追加されたことを確認します。

次の問合せでは行が戻されません。

SQL> SELECT path,header_status FROM v$asm_disk WHERE group_number=0;

次の問合せでは、すべての障害グループのディスク数が同じかどうかが示されます。

SQL> SELECT group_number, failgroup, mode_status, count(*) FROM v$asm_disk
GROUP BY group_number, failgroup, mode_status;

3.2.6 Exadata Storage Serverから別のExadata Storage Serverへのすべてのドライブの移動

Exadata Storage Serverから別のExadata Storage Serverへのすべてのドライブの移動が必要になることがあります。この作業が必要になるのは、マザーボードやILOM障害などのシャーシ・レベルのコンポーネント障害がある場合またはハードウェアの問題のトラブルシューティングを行う場合です。

次の手順は、ドライブの移動方法を示しています。

1. 次のディレクトリのファイルをバックアップします。

- /etc/hosts

- /etc/modprobe.conf

- /etc/sysconfig/network

- /etc/sysconfig/network-scripts

2. 「Exadata Storage Serverのシャットダウン」を参照して、すべてのグリッド・ディスクを安全に無効化し、Exadata Storage Serverをシャットダウンします。別のExadata Storage Serverでグリッド・ディスクをアクティブ化する前にOracle ASMによってディスクが削除されないように、Oracle ASMのdisk_repair_time属性に十分に大きい値が設定されていることを確認してください。

3. 物理ディスク、フラッシュ・ディスク、ディスク・コントローラおよびUSBフラッシュ・ドライブを元のExadata Storage Serverから新しいExadata Storage Serverに移動します。

注意:

- システム・ディスクの最初の2つのディスクが同じ最初の2つのスロットにあることを確認してください。そうしないと、Exadata Storage Serverが正常に機能しません。

- フラッシュ・カードが元のExadata Storage Serverと同じPCIeスロットに設置されていることを確認してください。

4. サービス・プロセッサ・インタフェースまたは電源ボタンを使用して、新しいExadata Storage Serverの電源を投入します。

5. サービス・プロセッサまたはKVMスイッチを使用して、コンソールにログインします。

6. 次のディレクトリのファイルを確認します。破損している場合、バックアップからリストアします。

- /etc/hosts

- /etc/modprobe.conf

- /etc/sysconfig/network

- /etc/sysconfig/network-scripts

7. ifconfigコマンドを使用して、eth0、eth1、eth2およびeth3の新しいMACアドレスを取得します。次に、eth0 MACアドレスを取得する例を示します。

# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:14:4F:CA:D9:AE
inet addr:10.204.74.184  Bcast:10.204.75.255  Mask:255.255.252.0
inet6 addr: fe80::214:4fff:feca:d9ae/64 Scope:Link
UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
RX packets:141455 errors:0 dropped:0 overruns:0 frame:0
TX packets:6340 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:9578692 (9.1 MiB)  TX bytes:1042156 (1017.7 KiB)
Memory:f8c60000-f8c80000

8. 手順7の出力に基づいて、/etc/sysconfig/network-scriptsディレクトリのifcfg-eth0ファイル、ifcfg-eth1ファイル、ifcfg-eth2ファイルおよびifcfg-eth3ファイルを編集してHWADDR値を変更します。次に、ifcfg-eth0ファイルの例を示します。

#### DO NOT REMOVE THESE LINES ####
#### %GENERATED BY CELL% ####
DEVICE=eth0
BOOTPROTO=static
ONBOOT=yes
IPADDR=10.204.74.184
NETMASK=255.255.252.0
NETWORK=10.204.72.0
BROADCAST=10.204.75.255
GATEWAY=10.204.72.1
HOTPLUG=no
IPV6INIT=no
HWADDR=00:14:4F:CA:D9:AE

9. Exadata Storage Serverを再起動します。

10. 次のコマンドを使用して、グリッド・ディスクをアクティブ化します。

CellCLI> ALTER GRIDDISK ALL ACTIVE

セルのディスクのOracle ASMディスクが削除されなかった場合、それらのディスクは自動的にONLINEに変更され、使用が開始されます。

11. 次のコマンドを使用して、構成を検証します。

CellCLI> ALTER CELL VALIDATE CONFIGURATION

12. ASRのILOMをアクティブ化します。

関連項目:

- Oracle Exadata Database Machine Oracle Auto Service Requestクイック・インストレーション・ガイド

- Oracle Exadata Storage Server Softwareユーザーズ・ガイド CellCLIユーティリティの詳細

- ディスク修復時間の詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。

3.2.7 物理ディスクの再利用

ディスクのすべてのデータを削除し、別の目的でディスクを使用できます。これを実行する前に、ディスクのデータをコピーしてください。

次の手順は、ディスクの再利用方法を示しています。

1. CellCLIのLISTコマンドを使用して、Exadata Storage Serverオブジェクトを表示します。物理ドライブのグリッド・ディスクおよびセル・ディスクを確認する必要があります。次に例を示します。

CellCLI> LIST PHYSICALDISK
20:0   D174LX    normal
20:1   D149R0    normal
...

2. 次のようなコマンドを使用して、LUNのセル・ディスクおよびグリッド・ディスクを特定します。

CellCLI> LIST LUN ATTRIBUTES name, cellDisk WHERE physicalDrives='20:0'

3. Oracle ASMから次のコマンドを使用して、物理ディスクのOracle ASMディスクを削除します。

SQL> ALTER DISKGROUP diskgroup_name DROP DISK asm_disk_name;

4. Exadata Storage Serverから次のコマンドを使用して、物理ディスクのセル・ディスクおよびグリッド・ディスクを削除します。

CellCLI> DROP CELLDISK celldisk_on_this_lun FORCE

注意:

セル・ディスクのすべてのデータを上書きするには、DROP CELLDISKコマンドでERASEオプションを使用します。このコマンドの例を次に示します。

CellCLI> DROP CELLDISK CD_03_cell01 ERASE=1pass NOWAIT
CellDisk CD_03_cell01 erase is in progress

5. ホット削除するドライブを削除します。次に例を示します。

CellCli> ALTER PHYSICALDISK 20:0 DROP FOR REPLACEMENT

6. ディスクを取り外す前に、ディスクの青い取外しOKのLEDが点灯していることを確認してください。

注意:

ドライブを取り外す前に、ディスクの青色のLEDが点灯していることを確認します。青色のLEDが消灯している場合にドライブを取り外すと、システムがクラッシュする場合があるため、取り外さないでください。

7. 再利用するディスクを取り外し、新しいディスクを挿入します。

8. 新しい物理ディスクがLUNとして追加されるまで待機します。

CellCLI> LIST LUN

セル・ディスクとグリッド・ディスクが新しい物理ディスクに自動的に作成され、グリッド・ディスクがOracle ASMグループに追加されます。

関連トピック

- Oracle Exadata Storage Server Softwareユーザーズ・ガイド

3.2.8 同じ物理ディスクの取外しおよび交換

不注意で間違った物理ディスクを削除した場合、ディスクを元に戻します。Oracle ASMディスク・グループに自動的に追加され、そのデータは再同期化されます。

注意:

ディスク障害またはディスクの問題でディスクを交換すると、ディスク上でLEDが点灯し識別できます。

3.2.9 拒否された物理ディスクの再有効化

不適切なスロットに挿入されたことが原因で物理ディスクが拒否された場合は、次のコマンドを実行してください。

注意:

次のコマンドでは、物理ディスク上のデータをすべて削除します。

CellCLI> ALTER PHYSICALDISK hard_disk_name/hard_disk_id reenable force

次に、コマンドの出力例を示します。

Physical disk hard_disk_name/hard_disk_id  was reenabled.

3.3 フラッシュ・ディスクの保守

データはExadataセル間でミラー化され、書込み操作が少なくとも2つのストレージ・セルに送信されます。1つのExadata Storage Serverのフラッシュ・カードに問題が発生すると、別のExadata Storage Serverのミラー化されたデータによって読取りおよび書込み操作が実行されます。アプリケーションでサービスの中断は発生しません。

フラッシュ・カードに障害が発生すると、Oracle Exadata Storage Server Softwareは、残存ミラーからデータを読み取り、フラッシュ・キャッシュのデータを確認します。次に、フラッシュ・カードに障害が発生したセルにデータが書き込まれます。障害が発生したフラッシュ・キャッシュ内での損失データの場所が、Oracle Exadata Storage Server Softwareによってフラッシュの障害発生時に保存されます。損失データをミラー・コピーに置き換えることにより、復元が開始されます。復元中、グリッド・ディスクのステータスはACTIVE -- RESILVERING WORKINGになります。

この項では、フラッシュ・ディスクの保守を実行する方法について説明します。次の項目が含まれます。

- フラッシュ・ディスク障害によるフラッシュ・ディスクの交換

- フラッシュ・ディスクの問題によるフラッシュ・ディスクの交換

- 11.2.3.3.1より前のソフトウェア・バージョンでのライトバック・フラッシュ・キャッシュの有効化および無効化

- フラッシュ・キャッシュの圧縮の有効化

- フラッシュ・キャッシュの圧縮の無効化

3.3.1 フラッシュ・ディスク障害によるフラッシュ・ディスクの交換

Exadata Storage Serverには、それぞれフラッシュ・デバイスが付属しています。フラッシュ・デバイスはExtreme Flashセルではホットプラグ対応ですが、High Capacityセルでは対応していません。High Capacityセルでは、交換前にセルの電源を切る必要があります。

障害が発生したフラッシュ・ディスクを確認するには、次のコマンドを使用します。

CellCLI> LIST PHYSICALDISK WHERE DISKTYPE=flashdisk AND STATUS=failed DETAIL

Extreme Flashセルからの出力例を次に示します。

name:                          NVME_10
deviceName:                 /dev/nvme7n1
diskType:             FlashDisk
luns:                 0_10
makeModel:            "Oracle NVMe SSD"
physicalFirmware:        8DV1RA13
physicalInsertTime:     2016-09-28T11:29:13-07:00
physicalSerial:           CVMD426500E21P6LGN
physicalSize:              1.4554837569594383T
slotNumber:                 10
status:                       failed

次に、Sun Flash Accelerator F20 PCIeカードからの出力例を示します。

CellCLI> LIST PHYSICALDISK WHERE DISKTYPE=flashdisk AND STATUS=failed DETAIL

name:                   FLASH_5_3
diskType:               FlashDisk
luns:                   5_3
makeModel:              "Sun Flash Accelerator F20 PCIe Card"
physicalFirmware:       D20Y
physicalInsertTime:     2012-05-14T17:44:14-07:00
physicalSerial:         1030M03UYM
physicalSize:           22.8880615234375G
slotNumber:             "PCI Slot: 5; FDOM: 3"
status:                 failed

次に、Sun Flash Accelerator F40 PCIeカードからの出力例を示します。

name:                   FLASH_5_3
diskType:               FlashDisk
luns:                   5_3
makeModel:              "Sun Flash Accelerator F40 PCIe Card"
physicalFirmware:       TI35
physicalInsertTime:     2012-07-13T15:40:59-07:00
physicalSerial:         5L002X4P
physicalSize:           93.13225793838501G
slotNumber:             "PCI Slot: 5; FDOM: 3"
status:                 failed

F20およびF40 PCIeカードの場合、nameおよびslotNumber属性は、PCIスロットおよびFDOM番号を示します。

Extreme Flashセルの場合、slotNumber属性は、前面パネルのNVMeスロットを示します。

フラッシュ・ディスクの障害が検出されると、フラッシュ・ディスクとそのLUNで障害が発生したことを示すアラートが生成されます。アラート・メッセージには、PCIスロット番号とFDOM番号か、またはNVMeスロット番号が含まれています。これらの番号により、フィールド交換可能ユニット(FRU)が一意に識別されます。システムのアラート通知を構成している場合は、指定したアドレスにアラートが電子メール・メッセージで送信されます。

フラッシュ・ディスクの停止により、パフォーマンスの低下およびデータの冗長性が発生する場合があります。できるだけすぐに障害が発生したディスクを新しいフラッシュ・ディスクに交換する必要があります。フラッシュ・キャッシュにフラッシュ・ディスクを使用する場合、セルの有効なキャッシュ・サイズが縮小します。フラッシュ・ログにフラッシュ・ディスクを使用する場合、ディスクでフラッシュ・ログが無効になり、有効なフラッシュ・ログ・サイズが縮小します。グリッド・ディスクにフラッシュ・ディスクを使用する場合、FORCEオプションによってグリッド・ディスクに関連するOracle ASMディスクがOracle ASMディスク・グループから自動的に削除され、Oracle ASMリバランスでデータの冗長性のリストアが開始されます。

次の手順は、High Capacityセルでの、ディスク障害によるFDOMの交換方法を示しています。Extreme FlashセルでのNVMeドライブの交換は、物理ディスクの交換と同様に、前面パネルからNVMeドライブを取り外して新しいものを挿入するのみです。セルを停止する必要はありません。

1. セルを停止します。

関連項目:

Exadata Storage Serverのシャットダウン

2. PCI番号およびFDOM番号に基づいて、障害が発生したフラッシュ・ディスクを交換します。白色のセルLEDが点灯し、影響を受けているセルを特定できます。

3. セルの電源を投入します。セル・サービスが自動的に開始されます。セルの起動の一環として、Oracle ASMですべてのグリッド・ディスクが自動的にONLINEになります。

4. 次のコマンドを使用して、すべてのグリッド・ディスクが正常にオンラインになったことを確認します。

CellCLI> LIST GRIDDISK ATTRIBUTES name, asmmodestatus

すべてのグリッド・ディスクのasmmodestatusがONLINEまたはUNUSEDになるまで待機します。

新しいフラッシュ・ディスクがシステムによって自動的に使用されます。フラッシュ・キャッシュにフラッシュ・ディスクを使用する場合、有効なキャッシュ・サイズが拡張します。グリッド・ディスクにフラッシュ・ディスクを使用する場合、グリッド・ディスクが新しいフラッシュ・ディスクに再作成されます。これらのグリッド・ディスクがOracle ASMディスク・グループの一部である場合、ディスク・グループの冗長性およびASM_POWER_LIMITパラメータに基づいて、ディスクがディスク・グループに追加され、データがリバランスされます。

関連項目:

- Exadata Storage Serverのシャットダウン

- 部品情報およびサービス・ガイドのリンクは、「Exadata Storage Serverの部品」を参照してください。

- V$ASM_OPERATIONビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

- ASM_POWER_LIMITの詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。

- CellCLIユーティリティの詳細は、『Oracle Exadata Storage Server Softwareユーザーズ・ガイド』を参照してください

- 「関連ドキュメント」に記載されている、ご使用のシステムに適したPCIeカード・ユーザーズ・ガイド

3.3.2 フラッシュ・ディスクの問題によるフラッシュ・ディスクの交換

Exadata Storage Serverには、4枚のPCIeカードが付属しています。各カードに4個のフラッシュ・ディスク(FDOM)があり、合計16個のフラッシュ・ディスクが提供されます。4枚のPCIeカードは、PCIスロット番号1、2、4および5にあります。PCIeカードはホットプラグ対応ではありません。フラッシュ・ディスクまたはカードを交換する前にExadata Storage Serverの電源を切断する必要があります。

ディスクが次のステータスのいすれかになるため、フラッシュ・ディスクの交換が必要な場合があります。

- 警告 - 予測障害

- 警告 - 低いパフォーマンス

- 警告 - ライトスルー・キャッシュ

- 警告 - ピア障害

注意:

リリース11.2.3.2.2より前のリリースでは、ステータスはnot presentです。

フラッシュ・ディスクのpredictive failureステータスは、フラッシュ・ディスクに障害が発生する可能性があり、できるだけすぐに交換する必要があることを示します。フラッシュ・キャッシュにフラッシュ・ディスクを使用する場合、引き続きフラッシュ・キャッシュとして使用されます。グリッド・ディスクにフラッシュ・ディスクを使用する場合、グリッド・ディスクに関連するOracle ASMディスクが自動的に削除され、Oracle ASMリバランスで障害が発生する可能性のあるディスクから他のディスクにデータが移動されます。

フラッシュ・ディスクのpoor performanceステータスは、フラッシュ・ディスクのパフォーマンスが非常に低く、できるだけすぐに交換する必要があることを示します。リリース11.2.3.2以上では、パフォーマンスの低いディスクが自動的に識別され、アクティブな構成から削除されます。フラッシュ・キャッシュにフラッシュ・ディスクを使用する場合、このディスクからフラッシュ・キャッシュが削除され、Exadata Storage Serverの有効なフラッシュ・キャッシュ・サイズが縮小します。グリッド・ディスクにフラッシュ・ディスクを使用する場合、このフラッシュ・ディスクのグリッド・ディスクに関連するOracle ASMディスクがFORCEオプションによって可能な場合に自動的に削除されます。オフライン・パートナのためにDROP...FORCEが失敗した場合、通常グリッド・ディスクが自動的に削除され、Oracle ASMリバランスでパフォーマンスの低いディスクから他のディスクにデータが移動されます。

その後、Oracle Exadata Database Machineにより一連のパフォーマンス・テストが実行されます。CELLSRVでパフォーマンスの低いディスクが検出されると、セル・ディスクのステータスがnormal - confinedOnlineに変更され、物理ディスクのステータスがwarning - confinedOnlineに変更されます。次の状況はディスク制限のトリガーとなります。

- ディスクの応答停止。ストレージ・アラート・ログ内の原因コードはCD_PERF_HANGです。

- セル・ディスクの速度低下。次に例を示します。

- サービス時間のしきい値が高い(原因コードCD_PERF_SLOW_ABS)

- 相対的サービス時間のしきい値が高い(原因コードCD_PERF_SLOW_RLTV)

- 読取りまたは書込みでの長期待機時間。次に例を示します。

- 書込みでの待機時間が長い(原因コードCD_PERF_SLOW_LAT_WT)

- 読取りでの待機時間が長い(原因コードCD_PERF_SLOW_LAT_RD)

- 読取りおよび書込みでの待機時間が長い(原因コードCD_PERF_SLOW_LAT_RW)

- 頻繁に発生する個々のI/Oでの絶対的待機時間が非常に長い(原因コードCD_PERF_SLOW_LAT_ERR)

- I/Oエラーなどのエラー(原因コードCD_PERF_IOERR)。

ディスクの問題が一時的なものであり、テストに合格した場合は、そのディスクは構成に戻されます。ディスクがテストに合格しない場合は、poor performanceとしてマークされ、ASRによりディスク交換のためのサービス・リクエストが送信されます。可能な場合は、Oracle ASMによりグリッド・ディスクがテスト用にオフラインに変更されます。Oracle ASMがディスクをオフラインに変更できない場合、セル・ディスクのステータスは、ディスクを安全にオフラインに変更できるようになるまで、normal - confinedOnlineのまま変わりません。

ディスクのステータスの変更は、セルのアラート履歴にある次のエントリに関連付けられています。

MESSAGE ID date_time info "Hard disk entered confinement status. The LUN
n_m changed status to warning - confinedOnline. CellDisk changed status to normal
- confinedOnline. Status: WARNING - CONFINEDONLINE  Manufacturer: name  Model
Number: model  Size: size  Serial Number: serial_number  Firmware: fw_release
Slot Number: m  Cell Disk: cell_disk_name  Grid Disk: grid disk 1, grid disk 2
... Reason for confinement: threshold for service time exceeded"

ストレージ・セルのアラート・ログには次の情報が記録されます。

CDHS: Mark cd health state change cell_disk_name  with newState HEALTH_BAD_
ONLINE pending HEALTH_BAD_ONLINE ongoing INVALID cur HEALTH_GOOD
Celldisk entering CONFINE ACTIVE state with cause CD_PERF_SLOW_ABS activeForced: 0
inactiveForced: 0 trigger HistoryFail: 0, forceTestOutcome: 0 testFail: 0
global conf related state: numHDsConf: 1 numFDsConf: 0 numHDsHung: 0 numFDsHung: 0
...

注意:

11.2.3.2より前のリリースでは、CALIBRATEコマンドを使用して不良フラッシュ・ディスクを識別し、各フラッシュ・ディスクについてスループットやIOPSが極端に低くないか調べてください。

フラッシュ・ディスクのパフォーマンスが非常に低い場合、poor performanceとしてマークされます。該当するフラッシュ・ディスクのフラッシュ・キャッシュが自動的に無効になり、そのフラッシュ・ディスクのグリッド・ディスクがOracle ASMディスク・グループから自動的に削除されます。

フラッシュ・ディスクのwrite-through cachingステータスは、PCIeカードのデータ・キャッシュのサポートに使用するキャパシタに障害が発生したため、できるだけすぐにカードを交換する必要があることを示します。

フラッシュ・ディスクのpeer failureステータスは、同じSun Flash Accelerator PCIeカードのいずれかのフラッシュ・ディスクに障害または問題が発生したことを示します。たとえば、FLASH_5_3に障害が発生すると、FLASH_5_0、FLASH_5_1およびFLASH_5_2がpeer failureステータスになります。次に、例を示します。

CellCLI> LIST PHYSICALDISK
36:0            L45F3A          normal
36:1            L45WAE          normal
36:2            L45WQW          normal
...
FLASH_5_0       5L0034XM        warning - peer failure
FLASH_5_1       5L0034JE        warning - peer failure
FLASH_5_2       5L002WJH        warning - peer failure
FLASH_5_3       5L002X4P        failed

CellSRVにより、ライトバック・フラッシュ・キャッシュに使用されているフラッシュ・ディスクで予測障害またはピア障害が検出され、不良FDOMが1つのみの場合は、その不良FDOMのデータが復元され、残りの3つのFDOMのデータはフラッシュされます。その後、有効なグリッド・ディスクが存在する場合、CellSRVはディスクに対してOracle ASMリバランスが開始します。不良ディスクは、作業が完了するまで交換できません。ディスク交換が可能になると、MSによりアラートが送信されます。

X5以降のシステムでは、High Capacity上の各フラッシュ・カードおよびExtreme Flash上の各フラッシュ・ドライブはFRUです。これは、これらのシステムにはピア障害がないことを意味します。

X3およびX4システムでは、フラッシュ・カード自体がFRUであるため、いずれかのFDOMが失敗した場合、セル・ソフトウェアによってそのカード上の残りのFDOMが自動的にピア障害に設定され、フラッシュ・カードの交換の準備のためにデータを移動することができます。

V2およびX2システムでは、各FDOMはFRUです。これらのシステムのフラッシュにはピア障害がありません。

フラッシュ・ディスクが1つのため、フラッシュ・ディスクがpredictive failureになると、データがコピーされます。グリッド・ディスクにフラッシュ・ディスクを使用する場合、Oracle ASMと関連パートナが再びパートナになり、リバランスが実行されます。ライトバック・フラッシュ・キャッシュにフラッシュ・ディスクを使用する場合、フラッシュ・ディスクからグリッド・ディスクにデータがフラッシュされます。

predictive failureのフラッシュ・ディスクを確認するには、次のコマンドを使用します。

CellCLI> LIST PHYSICALDISK WHERE DISKTYPE=flashdisk AND STATUS=  \
'warning - predictive failure' DETAIL

name:               FLASH1_2
diskType:           FlashDisk
luns:               1_2
makeModel:          "Sun Flash Accelerator F20 PCIe Card"
physicalFirmware:   D20Y
physicalInsertTime: 2012-09-27T13:11:16-07:00
physicalSerial:     508002000092e70FMOD2
physicalSize:       22.8880615234375G
slotNumber:         "PCI Slot: 1; FDOM: 2"
status:             warning - predictive failure

poor performanceのフラッシュ・ディスクを確認するには、次のコマンドを使用します。

CellCLI> LIST PHYSICALDISK WHERE DISKTYPE=flashdisk AND STATUS= \
'warning - poor performance' DETAIL

name:                FLASH1_4
diskType:            FlashDisk
luns:                1_4
makeModel:           "Sun Flash Accelerator F20 PCIe Card"
physicalFirmware:    D20Y
physicalInsertTime:  2012-09-27T13:11:16-07:00
physicalSerial:      508002000092e70FMOD2
physicalSize:        22.8880615234375G
slotNumber:          "PCI Slot: 1; FDOM: 3"
status:              warning - poor performance

フラッシュ・ディスクがpredictive failure、poor performance、write-through cachingまたはpeer failureステータスの場合、アラートが生成されます。アラートには、フラッシュ・ディスクを交換する特定の手順が含まれます。システムのアラート通知を構成している場合、電子メール・メッセージでアラートが指定したアドレスに送信されます。

ディスク交換にいつ進むかの決定は、次に示されているように、リリースによって異なります。

- 11.2.3.2より前のリリースの場合:
フラッシュ・ディスクの交換に進む前にV$ASM_DISK_STATビューの問合せを実行してOracle ASMディスクが正常に削除されるまで待機します。フラッシュ・ディスクで障害が発生する前に通常の削除を完了できなかった場合、FORCEオプションによってOracle ASMディスク・グループからOracle ASMディスクが自動的に削除されます。フラッシュ・ディスクで障害が発生する前にDROPコマンドが完了しなかった場合は、「フラッシュ・ディスク障害によるフラッシュ・ディスクの交換」を参照してください。

- リリース11.2.3.2以上の場合:
Oracle ASMディスクが削除されている場合は、アラートが送信され、フラッシュ・ディスクを安全に交換できます。フラッシュ・ディスクをライトバック・フラッシュ・キャッシュに使用する場合、フラッシュ・ディスクによってキャッシュされるグリッド・ディスクがなくなるまで待機します。すべてのグリッド・ディスクのcachedBy属性をチェックするには、次のコマンドを使用します。フラッシュ・ディスクのセル・ディスクは、グリッド・ディスクのcachedBy属性には表示されません。

CellCLI> LIST GRIDDISK ATTRIBUTES name, cachedBy

フラッシュ・ディスクをグリッド・ディスクとフラッシュ・キャッシュの両方に使用する場合は、アラートを受信し、セル・ディスクがグリッド・ディスクのcachedBy属性に表示されなくなるまで待機します。

次の手順は、ディスクの問題によるHigh Capacityセルでのフラッシュ・ディスクの交換方法を示しています。Extreme Flashセルでは、前面パネルからドライブを取り外して新しいものを挿入するのみです。セルを停止する必要はありません。

1. 次のコマンドを使用して、セル・サービスを停止します。

CellCLI> ALTER CELL SHUTDOWN SERVICES ALL

前述のコマンドでは、オフラインのディスクがないか、predictive failureステータスのディスクがないか、またはミラーにコピーする必要があるディスクがないかをチェックします。Oracle ASM冗長性が損なわれていない場合は、コマンドによりOracle ASMでグリッド・ディスクがオフラインに変更され、セル・サービスが停止されます。次のエラーが表示された場合は、冗長性が原因でディスク・グループが強制的にディスマウントされ、セル・サービスを安全に停止できない可能性があります。

Stopping the RS, CELLSRV, and MS services...
The SHUTDOWN of ALL services was not successful.
CELL-01548: Unable to shut down CELLSRV because disk group DATA, RECO may be
forced to dismount due to reduced redundancy.
Getting the state of CELLSRV services... running
Getting the state of MS services... running
Getting the state of RS services... running

エラーが発生した場合は、Oracle ASMディスク・グループの冗長性をリストアし、すべてのディスクのディスク・ステータスが正常に戻ってからコマンドを再試行してください。

2. セルを停止します。

3. PCI番号およびFDOM番号に基づいて、障害が発生したフラッシュ・ディスクを交換します。白色のセルLEDが点灯し、影響を受けているセルを特定できます。

4. セルの電源を投入します。セル・サービスが自動的に開始されます。セルの起動の一環として、Oracle ASMですべてのグリッド・ディスクが自動的にONLINEになります。

5. 次のコマンドを使用して、すべてのグリッド・ディスクが正常にオンラインになったことを確認します。

CellCLI> LIST GRIDDISK ATTRIBUTES name, asmmodestatus

すべてのグリッド・ディスクのasmmodestatusがONLINEまたはUNUSEDになるまで待機します。

新しいフラッシュ・ディスクがシステムによって自動的に使用されます。フラッシュ・キャッシュにフラッシュ・ディスクを使用する場合、有効なキャッシュ・サイズが拡張します。グリッド・ディスクにフラッシュ・ディスクを使用する場合、グリッド・ディスクが新しいフラッシュ・ディスクに再作成されます。これらのグリッド・ディスクがOracle ASMディスク・グループの一部である場合、ディスク・グループの冗長性およびASM_POWER_LIMITパラメータに基づいて、ディスクがディスク・グループに追加され、データがリバランスされます。

関連項目:

- フラッシュ・ディスクの問題によるフラッシュ・ディスクの交換

- Exadata Storage Serverのシャットダウン

- 部品番号情報およびサービス・ガイドのリンクは、「Exadata Storage Serverの部品」を参照してください。

- V$ASM_OPERATIONビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

- ASM_POWER_LIMITの詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。

- CellCLIユーティリティの詳細は、『Oracle Exadata Storage Server Softwareユーザーズ・ガイド』を参照してください

- 「関連ドキュメント」に記載されている、ご使用のシステムに適したPCIeカード・ユーザーズ・ガイド

3.3.3 ソフトウェア・バージョン11.2.3.3.1以上のライトバック・フラッシュ・キャッシュの有効化および無効化

リリース11.2.3.2.1以上では、Exadataスマート・フラッシュ・キャッシュにより、頻繁にアクセスするデータを高速のソリッド状態の記憶装置に透過的にキャッシュして、問合せの応答時間とスループットを向上させることができます。ディスクではなくフラッシュによって処理される書込み操作は、「ライトバック・フラッシュ・キャッシュ」と呼ばれます。この機能は必要に応じて有効または無効にできます。フラッシュ・キャッシュ・モードを変更する場合は、次の点に注意してください。

- ストレージ・セル・ソフトウェアのリリース11.2.3.3.1以上では、セルのサービスを停止する必要も、グリッド・ディスクを非アクティブ化する必要もありません。

- ライトバック・フラッシュ・キャッシュを使用するには、GridホームとOracle DatabaseホームがOracle Database 11gリリース11.2.0.3 BP9以上であることが必要です。

注意:

フラッシュ・キャッシュを削除し、再作成すると、キャッシュがウォームアップするまで、データベースの再起動の際にパフォーマンスに影響を与える可能性があります。

この項では、次の項目について説明します。

- 11.2.3.3.1以上でのライトバック・フラッシュ・キャッシュの有効化

- 11.2.3.3.1以上でのライトバック・フラッシュ・キャッシュの無効化

3.3.3.1 11.2.3.3.1以上でのライトバック・フラッシュ・キャッシュの有効化

ストレージ・サーバーでのライトバック・フラッシュ・キャッシュを有効にして、問合せの応答時間とスループットを向上させます。

注意:

- リリース11.2.3.3.1以上では、cellsrvプロセスを停止する必要も、グリッド・ディスクを非アクティブ化する必要もありません。

- アプリケーションのパフォーマンスへの影響を抑えるには、ワークロードが低い期間にライトバック・フラッシュ・キャッシュを有効化します。

1. フラッシュ・キャッシュを変更する前に、すべての物理ディスクが正常な状態であることを検証します。

次のコマンドでは行が戻されません。

# dcli –l root –g cell_group cellcli –e “list physicaldisk attributes name,status”|grep –v NORMAL

2. フラッシュ・キャッシュを削除します。

# dcli –l root –g cell_group cellcli -e drop flashcache

3. flashCacheMode属性をwritebackに設定します。

# dcli –l root – g cell_group cellcli -e "alter cell flashCacheMode=writeback"

4. フラッシュ・キャッシュを再作成します。

# dcli –l root –g cell_group cellcli -e create flashcache all

5. flashCacheModeがwritebackに設定されていることを確認します。

# dcli –l root –g cell_group cellcli -e list cell detail | grep flashCacheMode

6. グリッド・ディスク属性のcachingPolicyとcachedbyを検証します。

# cellcli –e list griddisk attributes name,cachingpolicy,cachedby

3.3.3.2 11.2.3.3.1以上でのライトバック・フラッシュ・キャッシュの無効化

ストレージ・サーバーでのライトバック・フラッシュ・キャッシュを無効にする必要がある場合は、次の手順を使用します。

注意:

- リリース11.2.3.3.1以上では、cellsrvプロセスを停止する必要も、グリッド・ディスクを非アクティブ化する必要もありません。

- アプリケーションのパフォーマンスへの影響を抑えるには、ワークロードが低い期間にライトバック・フラッシュ・キャッシュを無効化します。

1. フラッシュ・キャッシュを変更する前に、すべての物理ディスクが正常な状態であることを検証します。

次のコマンドでは行が戻されません。

# dcli –l root –g cell_group cellcli –e “LIST PHYSICALDISK ATTRIBUTES name,status”|grep –v NORMAL

2. フラッシュ・キャッシュ内のダーティ・データの量を確認します。

# cellcli -e "LIST METRICCURRENT ATTRIBUTES name,metricvalue WHERE name LIKE \'FC_BY_DIRTY.*\' "

3. フラッシュ・キャッシュをフラッシュします。

# dcli –g cell_group –l root cellcli -e "ALTER FLASHCACHE ALL FLUSH"

4. フラッシュ・キャッシュのフラッシュの進捗状況をチェックします。

FC_BY_DIRTYが0MBになると、フラッシュ・プロセスは完了します。

# dcli -g cell_group -l root cellcli -e "LIST METRICCURRENT ATTRIBUTES name,metricvalue WHERE name LIKE \'FC_BY_DIRTY.*\' "

属性flushstatusがCompletedに設定されたかどうかを確認することもできます。

# dcli -g cell_group -l root cellcli -e "LIST CELLDISK ATTRIBUTES name, flushstatus, flusherror" | grep FD

5. フラッシュ・キャッシュのフラッシュが完了した後、フラッシュ・キャッシュを削除します。

# dcli -g cell_group -l root cellcli -e drop flashcache

6. flashCacheMode属性をwritethroughに設定します。

# dcli -g cell_group -l root cellcli -e "ALTER CELL flashCacheMode=writethrough"

7. フラッシュ・キャッシュを再作成します。

# dcli –l root –g cell_group cellcli -e create flashcache all

8. flashCacheModeがwritethroughに設定されていることを確認します。

# dcli –l root –g cell_group cellcli -e list cell detail | grep flashCacheMode

3.3.4 11.2.3.3.1より前のソフトウェア・バージョンでのライトバック・フラッシュ・キャッシュの有効化および無効化

リリース11.2.3.2.1以上では、Exadataスマート・フラッシュ・キャッシュにより、頻繁にアクセスするデータを高速のソリッド状態の記憶装置に透過的にキャッシュして、問合せの応答時間とスループットを向上させることができます。ディスクではなくフラッシュによって処理される書込み操作は、「ライトバック・フラッシュ・キャッシュ」と呼ばれます。この機能は必要に応じて有効または無効にできます。フラッシュ・キャッシュ・モードを変更する場合は、次の点に注意してください。

- flashCacheMode属性を変更する前に、セル・サービスをシャットダウンする必要があります。セル・サービスは、ローリング形式または全体シャットダウンとしてシャットダウンできます。

- 変更をローリング形式で行う場合は、セル・サービスの再同期が完了していることを確認してから、次のセルを変更してください。

- フラッシュ・キャッシュ・モードをローリング形式で変更する場合は、次のセルに移る前に、現在のセルのすべてのグリッド・ディスクでasmDeactivationOutcome属性がyesに、asmModeStatus属性がonlineになっている必要があります。グリッド・ディスクの属性をチェックするには、次のコマンドを使用します。

LIST GRIDDISK ATTRIBUTES asmDeactivationOutcome, asmModeStatus

- 変更を非ローリング形式で行う場合は、クラスタ全体を停止してから、変更を開始してください。

- フラッシュ・キャッシュ・モードを非ローリング形式で変更する場合は、Oracle Clusterware CRSとすべてのデータベースを含め、クラスタ全体を停止してください。

- ライトバック・フラッシュ・キャッシュを使用するには、GridホームとOracle DatabaseホームがOracle Database 11gリリース11.2.0.3 BP9以上であることが必要です。

注意:

フラッシュ・キャッシュを削除し、再作成すると、キャッシュがウォームアップするまで、データベースの再起動の際にパフォーマンスに影響を与える可能性があります。

この項では、次の項目について説明します。

- ローリング形式でのライトバック・フラッシュ・キャッシュの有効化

- 非ローリング形式でのライトバック・フラッシュ・キャッシュの有効化

- ローリング形式でのライトバック・フラッシュ・キャッシュの無効化

- 非ローリング形式でのライトバック・フラッシュ・キャッシュの無効化

3.3.4.1 ローリング形式でのライトバック・フラッシュ・キャッシュの有効化

属性をwritethroughからwritebackに変更する場合は、属性を変更する前にフラッシュ・キャッシュを削除する必要があります。次の手順では、ライトバック・フラッシュ・キャッシュをローリング形式で有効にする方法について説明します。

注意:

ライトバック・フラッシュ・キャッシュの有効化と無効化を自動化するためのシェル・スクリプトが用意されています。スクリプトおよび詳細は、My Oracle Supportノート1500257.1を参照してください。

関連項目:

My Oracle Supportノート888828.1には、Oracle Exadata Storage Server Software、Grid InfrastructureホームおよびOracle Databaseホームの最小リリース要件がまとめられています。

1. ライトバック・フラッシュ・キャッシュを有効にする最初のセルにrootユーザーとしてログインします。

2. 次のコマンドを使用して、フラッシュ・キャッシュが正常であり、フラッシュ・ディスクの機能低下やクリティカル状態が発生していないことを確認します。

# cellcli -e LIST FLASHCACHE detail

3. 次のコマンドを使用して、セルのフラッシュ・キャッシュを削除します。

# cellcli -e DROP FLASHCACHE

4. 次のコマンドを使用して、セルのグリッド・ディスクを非アクティブ化します。

# cellcli -e ALTER GRIDDISK ALL INACTIVE

5. 次のコマンドを使用して、CELLSRVサービスを停止します。

# cellcli -e ALTER CELL SHUTDOWN SERVICES CELLSRV

6. 次のコマンドを使用して、flashCacheMode属性をwritebackに設定します。

# cellcli -e "ALTER CELL FLASHCACHEMODE=writeback"

7. 次のコマンドを使用して、セル・サービスを再起動します。

# cellcli -e ALTER CELL STARTUP SERVICES CELLSRV

8. 次のコマンドを使用して、セルのグリッド・ディスクを再アクティブ化します。

# cellcli -e ALTER GRIDDISK ALL ACTIVE

9. 次のコマンドを使用して、フラッシュ・キャッシュを再作成します。

# cellcli -e CREATE FLASHCACHE ALL

10. 次のコマンドを使用して、セルのステータスをチェックします。

# cellcli -e LIST CELL DETAIL | grep flashCacheMode

flashCacheMode属性がwritebackに設定されている必要があります。

11. 次のセルに移る前に、次のコマンドを使用して、グリッド・ディスクのasmDeactivationOutcome属性とasmModeStatus属性をチェックします。

CellCLI> LIST GRIDDISK ATTRIBUTES name,asmdeactivationoutcome,asmmodestatus

asmDeactivationOutcome属性がyesに、asmModeStatus属性がonlineになっている必要があります。

12. 次のセルに対して前述の手順を繰り返します。

3.3.4.2 非ローリング形式でのライトバック・フラッシュ・キャッシュの有効化

属性をwritethroughからwritebackに変更する場合は、属性を変更する前にフラッシュ・キャッシュを削除する必要があります。次の手順では、ライトバック・フラッシュ・キャッシュを非ローリング形式で有効にする方法について説明します。

注意:

ライトバック・フラッシュ・キャッシュの有効化と無効化を自動化するためのシェル・スクリプトが用意されています。スクリプトおよび詳細は、My Oracle Supportノート1500257.1を参照してください。

関連項目:

My Oracle Supportノート888828.1には、Oracle Exadata Storage Server Software、Grid InfrastructureホームおよびOracle Databaseホームの最小リリース要件がまとめられています。

1. データベース・ノードにrootユーザーとしてログインします。

2. 次のコマンドを使用して、クラスタ全体を停止します。

# cd $GI_HOME/bin
# ./crsctl stop cluster -all

3. 次のコマンドを使用して、すべてのセルのフラッシュ・キャッシュを削除します。

# dcli -g cell_group -l root cellcli -e DROP FLASHCACHE

4. 次のコマンドを使用して、CELLSRVサービスを停止します。

# dcli -g cell_group -l root cellcli -e ALTER CELL SHUTDOWN SERVICES CELLSRV

5. フラッシュ・キャッシュがwritethroughモードに設定されていることを確認します。

# dcli -g cell_group -l root "cellcli -e list cell detail | grep -i flashcachemode"

6. 次のコマンドを使用して、flashCacheMode属性をwritebackに設定します。

# dcli -g cell_group -l root cellcli -e "ALTER CELL FLASHCACHEMODE=writeback"

7. 次のコマンドを使用して、セル・サービスを再起動します。

# dcli -g cell_group -l root cellcli -e ALTER CELL STARTUP SERVICES CELLSRV

8. 次のコマンドを使用して、フラッシュ・キャッシュを再作成します。

# dcli -g cell_group -l root cellcli -e CREATE FLASHCACHE ALL

9. クラスタを再起動します。

# cd $GI_HOME/bin
# ./crsctl start cluster -all

3.3.4.3 ローリング形式でのライトバック・フラッシュ・キャッシュの無効化

flashCacheMode属性をwritebackからwritethroughに変更したときに、既存のフラッシュ・キャッシュが存在していると、エラーが表示されます。属性をwritethroughに変更する前に、フラッシュ・キャッシュをフラッシュして削除する必要があります。フラッシュ操作が開始されると、フラッシュ・キャッシュへのすべてのキャッシュが停止されます。次の手順では、ライトバック・フラッシュ・キャッシュをローリング形式で無効にする方法について説明します。

注意:

ライトバック・フラッシュ・キャッシュの有効化と無効化を自動化するためのシェル・スクリプトが用意されています。スクリプトおよび詳細は、My Oracle Supportノート1500257.1を参照してください。

1. ライトバック・フラッシュ・キャッシュを無効にする最初のセルにrootユーザーとしてログインします。

2. 次のコマンドを使用して、セルのすべてのグリッド・ディスクのasmDeactivationOutcome属性がyesになっていることを確認します。

# dcli -g cell_group -l root cellcli -e "LIST GRIDDISK WHERE   \
asmdeactivationoutcome != 'Yes' attributes name, asmdeactivationoutcome, \
asmmodestatus"

グリッド・ディスクが返された場合は、手順を進める前にこの問題を解決する必要があります。

3. 次のコマンドを使用して、フラッシュ・キャッシュ内のダーティ・データの量をチェックします。

# dcli -g cell_group -l root cellcli -e "LIST METRICCURRENT ATTRIBUTES  \
name,metricvalue WHERE name LIKE \'FC_BY_DIRTY.*\'"

4. 次のコマンドを使用して、フラッシュ・キャッシュをフラッシュします。

# dcli -g cell_group -l root cellcli -e ALTER FLASHCACHE ALL FLUSH

5. 次のコマンドを使用して、フラッシュ・キャッシュのステータスをチェックします。

# dcli -g cell_group -l root cellcli -e LIST CELLDISK ATTRIBUTES name, \
flushstatus, flusherror | grep FD

フラッシュが完了すると、ステータスがcompletedになります。

6. 1セルずつ、すべてのセルに次の一連の手順を実行します。つまり、すべてのセルが完了するまで、1つのセルに手順(a)から(i)を実行した後、別のセルにそれらを実行します。

a. 次のコマンドを使用して、フラッシュ・キャッシュを削除します。

# cellcli -e DROP FLASHCACHE

b. 次のコマンドを使用して、セルのグリッド・ディスクをすべて非アクティブ化します。

# cellcli -e ALTER GRIDDISK ALL INACTIVE

c. 次のコマンドを使用して、CELLSRVサービスを停止します。

# cellcli -e ALTER CELL SHUTDOWN SERVICES CELLSRV

d. 次のコマンドを使用して、flashCacheMode属性をwritethroughに設定します。

# cellcli -e "ALTER CELL FLASHCACHEMODE=writethrough"

e. 次のコマンド使用して、セル・サービスを再起動します。

# cellcli -e ALTER CELL STARTUP SERVICES CELLSRV

f. 次のコマンドを使用して、セルのグリッド・ディスクを再アクティブ化します。

# cellcli -e ALTER GRIDDISK ALL ACTIVE

g. 次のコマンドを使用して、フラッシュ・キャッシュを再作成します。

# cellcli -e CREATE FLASHCACHE ALL

h. 次のコマンドを使用して、セルのステータスをチェックします。

# cellcli -e LIST CELL DETAIL | grep flashCacheMode

i. 次のコマンドを使用して、グリッド・ディスクのasmDeactivationOutcome属性とasmModeStatus属性をチェックします。

# cellcli -e LIST GRIDDISK ATTRIBUTES name,status,asmdeactivationoutcome,asmmodestatus

asmDeactivationOutcome属性がyesに、asmModeStatus属性がonlineになっている必要があります。

ディスク・ステータスがSYNCINGの場合は、続行せずにACTIVEになるまで待ちます。

3.3.4.4 非ローリング形式でのライトバック・フラッシュ・キャッシュの無効化

flashCacheMode属性をwritebackからwritethroughに変更したときに、既存のフラッシュ・キャッシュが存在していると、エラーが表示されます。属性をwritethroughに変更する前に、フラッシュ・キャッシュをフラッシュして削除する必要があります。フラッシュ操作が開始されると、フラッシュ・キャッシュへのすべてのキャッシュが停止されます。次の手順では、ライトバック・フラッシュ・キャッシュを非ローリング形式で無効にする方法について説明します。

注意:

- ライトバック・フラッシュ・キャッシュの有効化と無効化を自動化するためのシェル・スクリプトが用意されています。スクリプトおよび詳細は、My Oracle Supportノート1500257.1を参照してください。

- フラッシュ・キャッシュのフラッシュ操作は、クラスタ全体を停止する前に実行できます。

1. ライトバック・フラッシュ・キャッシュを無効にする最初のデータベース・ノードにrootユーザーとしてログインします。

2. 次のコマンドを使用して、フラッシュ・キャッシュ内のダーティ・データの量をチェックします。

# dcli -g cell_group -l root cellcli -e "LIST METRICCURRENT ATTRIBUTES  \
name,metricvalue WHERE name LIKE \'FC_BY_DIRTY.*\'"

3. 次のコマンドを使用して、フラッシュ・キャッシュをフラッシュします。

# dcli -g cell_group -l root cellcli -e ALTER FLASHCACHE ALL FLUSH

4. 次のコマンドを使用して、ブロックがディスクに移動されたときのステータスをチェックします。件数はゼロまで減ります。

# dcli -g cell_group -l root cellcli -e "LIST METRICCURRENT ATTRIBUTES name, \
metricvalue WHERE NAME LIKE \'FC_BY_DIRTY.*\'"

5. 次のコマンドを使用して、フラッシュ・ディスクのステータスをチェックします。

# dcli -g cell_group -l root cellcli -e LIST CELLDISK ATTRIBUTES name, flushstatus, flusherror | grep FD

フラッシュが完了すると、ステータスがcompletedになります。

6. 次のコマンドを使用して、データベースとクラスタ全体を停止します。

# cd $GI_HOME/bin
# ./crsctl stop cluster -all

7. 次のコマンドを使用して、すべてのセルのフラッシュ・キャッシュを削除します。

# dcli -g cell_group -l root cellcli -e DROP FLASHCACHE

8. 次のコマンドを使用して、CELLSRVサービスを停止します。

# dcli -g cell_group -l root cellcli -e ALTER CELL SHUTDOWN SERVICES CELLSRV

9. 次のコマンドを使用して、flashCacheMode属性をwritethroughに設定します。

# dcli -g cell_group -l root cellcli -e "ALTER CELL FLASHCACHEMODE=writethrough"

10. 次のコマンドを使用して、セル・サービスを再起動します。

# dcli -g cell_group -l root cellcli -e ALTER CELL STARTUP SERVICES CELLSRV

11. 次のコマンドを使用して、フラッシュ・キャッシュを再作成します。

# dcli -g cell_group -l root cellcli -e CREATE FLASHCACHE ALL

12. 次のコマンドを使用して、セルのフラッシュ・キャッシュ・モードをチェックします。

# dcli -g cell_group -l root cellcli -e LIST CELL DETAIL | grep flashCacheMode

13. 次のコマンドを使用して、クラスタとデータベースを再起動します。

# cd $GI_HOME/bin
# ./crsctl start cluster -all

3.3.5 フラッシュ・キャッシュの圧縮の有効化

Oracle Exadata Database Machine X4-2、Oracle Exadata Database Machine X3-2およびOracle Exadata Database Machine X3-8フル・ラックの各システムでは、フラッシュ・キャッシュの圧縮を有効にできます。Oracle Exadata Database Machine X5-2およびX5-8にフラッシュ・キャッシュの圧縮機能はありません。フラッシュ・キャッシュの圧縮では、ユーザー・データがフラッシュ・キャッシュにロードされる際にデータを透過的に圧縮することによって、フラッシュ・キャッシュの論理容量が大幅に増加します。

注意:

- フラッシュ・キャッシュ圧縮を有効にするには、Oracle拡張圧縮オプションが必要です。

- フラッシュ・キャッシュの圧縮を有効にした場合、ユーザー・データは保持されません。

次の手順では、フラッシュ・キャッシュの圧縮を有効にする方法について説明します。

1. この手順は、ライトバック・フラッシュ・キャッシュが有効化されている場合にのみ実行します。ライトバック・フラッシュ・キャッシュが無効の場合は、この手順をスキップします。ライトバック・フラッシュ・キャッシュが無効の場合にこの手順を実行すると、エラー・メッセージが表示される場合があります。次のコマンドを実行してフラッシュ・キャッシュ・モードを確認できます。

# cellcli -e LIST CELL DETAIL | grep flashCacheMode

ライトバック・フラッシュ・キャッシュが有効化されている場合に、次のコマンドを使用して、フラッシュ・セル・ディスクにユーザー・データを保存します。

# cellcli -e ALTER FLASHCACHE all flush

2. 次のコマンドを使用して、セルからフラッシュ・キャッシュを削除します。

# cellcli -e DROP FLASHCACHE all

3. 次のコマンドを使用して、セルからフラッシュ・ログを削除します。

# cellcli -e DROP FLASHLOG all

4. 次のコマンドを使用して、セル・フラッシュ・ディスクを削除します。

# cellcli -e DROP CELLDISK all flashdisk

5. システムに応じて、次のコマンドを使用してフラッシュ・キャッシュの圧縮を有効にします。

- Sun Fire X4170 Oracle Database Server、およびExadata Storage Server X4-2L Serverを使用したOracle Exadata Database Machine X3-2の場合:

# cellcli -e ALTER CELL flashcachecompress=true

- Oracle Exadata Database Machine X3-2、およびExadata Storage Server X3-2 Serverを使用したOracle Exadata Database Machine X3-8フル・ラックの場合:

# cellcli -e ALTER CELL flashCacheCompX3Support=true
# cellcli -e ALTER CELL flashCacheCompress=true

6. 次のコマンドを使用して、セル・フラッシュ・ディスクを作成します。

# cellcli -e CREATE CELLDISK all flashdisk
CellDisk FD_00_exampleceladm18 successfully created
...
CellDisk FD_15_exampleceladm18 successfully created

7. 次のコマンドを使用して、フラッシュ・ログを作成します。

# cellcli -e CREATE FLASHLOG all
Flash log RaNdOmceladm18_FLASHLOG successfully created

8. 次のコマンドを使用して、セルでフラッシュ・キャッシュを作成します。

# cellcli -e CREATE FLASHCACHE all
Flash cache exampleceladm18_FLASHCACHE successfully created

3.3.6 フラッシュ・キャッシュの圧縮の無効化

Oracle Exadata Database Machine X4-2、Oracle Exadata Database Machine X3-2およびOracle Exadata Database Machine X3-8フル・ラックの各システムでは、フラッシュ・キャッシュの圧縮を無効にできます。Oracle Exadata Database Machine X5-2およびX5-8にフラッシュ・キャッシュの圧縮機能はありません。

注意:

- フラッシュ・キャッシュの圧縮を無効にした場合、ユーザー・データは保持されません。

次の手順では、フラッシュ・キャッシュの圧縮を無効にする方法について説明します。

1. 次のコマンドを使用して、フラッシュ・セル・ディスクにユーザー・データを保存します。

# cellcli -e ALTER FLASHCACHE all flush

2. 次のコマンドを使用して、セルからフラッシュ・キャッシュを削除します。

# cellcli -e DROP FLASHCACHE all

3. 次のコマンドを使用して、セルからフラッシュ・ログを削除します。

# cellcli -e DROP FLASHLOG all

4. 次のコマンドを使用して、セル・フラッシュ・ディスクを削除します。

# cellcli -e DROP CELLDISK all flashdisk

5. システムに応じて、次のコマンドを使用してフラッシュ・キャッシュの圧縮を無効にします。

- Sun Fire X4170 Oracle Database Server、およびExadata Storage Server X4-2L Serverを使用したOracle Exadata Database Machine X3-2の場合:

# cellcli -e ALTER CELL flashcachecompress=false

- Oracle Exadata Database Machine X3-2、およびExadata Storage Server X3-2 Serverを使用したOracle Exadata Database Machine X3-8フル・ラックの場合:

# cellcli -e ALTER CELL flashCacheCompX3Support=true
# cellcli -e ALTER CELL flashCacheCompress=false

注意:

flashCacheCompressをfalseに設定しますが、flashCacheCompX3Supportはtrueに設定する必要があります。

6. 次のコマンドを使用して、セル・フラッシュ・ディスクを作成します。

# cellcli -e CREATE CELLDISK all flashdisk
CellDisk FD_00_exampleceladm18 successfully created
...
CellDisk FD_15_exampleceladm18 successfully created

7. 次のコマンドを使用して、フラッシュ・ログを作成します。

# cellcli -e CREATE FLASHLOG all
Flash log RaNdOmceladm18_FLASHLOG successfully created

8. 次のコマンドを使用して、セルでフラッシュ・キャッシュを作成します。

# cellcli -e CREATE FLASHCACHE all
Flash cache exampleceladm18_FLASHCACHE successfully created

9. フラッシュ・キャッシュの圧縮が無効になっていることを確認します。

# cellcli -e LIST CELL

flashCacheCompress属性の値がfalseに設定されている必要があります。

3.4 グリッド・ディスクのサイズ変更

グリッド・ディスクとOracle ASMディスク・グループのサイズを変更して、空き領域が多すぎるディスクはサイズを減らしたり、最大容量に近いディスクはサイズを増やしたりできます。

Oracle Exadata Database Machineのディスク・グループ・サイズの初期構成は、Oracleベスト・プラクティスおよびバックアップ・ファイルの場所に基づきます。内部バックアップの場合、割当てられる領域はDATAディスク・グループで40%、RECOディスク・グループで60%です。外部バックアップの場合、割当てられる領域はDATAディスク・グループで80%、RECOディスク・グループで20%です。ディスク・グループの割当ては、デプロイ後に変更できます。たとえば、DATAディスク・グループの割当てが60%では小さすぎるため、80%にサイズ変更する必要が生じる場合があります。

システムで、セル・ディスクに空き領域がないが、1つのディスク・グループ(たとえばRECO)には十分な空き領域がある場合、RECOディスク・グループのサイズを小さくして、空き領域をDATAディスク・グループに再割当てすることができます。RECOディスク・グループを縮小した後で得られる空き領域は、DATAディスク・グループの既存の領域割当てとは連続しないオフセットにあります。グリッド・ディスクは、セル・ディスク上のどこにある領域でも使用することができ、連続している必要はありません。

グリッド・ディスクを拡張しようとするとき、十分な領域がセル・ディスクにすでにあり、既存のグリッド・ディスクを拡張できる場合には、最初に既存のディスク・グループをサイズ変更する必要はありません。RECOディスク・グループとグリッド・ディスクの縮小について説明している手順2と3は省略することもできます(ただし、DATAグリッド・ディスクを拡張する前に十分な空き領域があることを確認する必要はあります)。管理者が確保する必要がある空き領域の量は、障害時の補償範囲のレベルによって異なります。

グリッド・ディスクのサイズを縮小する場合は、ミラー化のために領域を確保する方法を理解する必要があります。データは、標準または高冗長性を使用してOracle ASMによって保護され、ファイル・エクステントとして保存される1つまたは2つのデータのコピーが作成されます。これらのコピーは、個別の障害グループに保存されます。1つの障害グループで障害が発生しても、ミラー・コピーには影響がないため、データにはまだアクセスできます。障害が発生すると、アクセスできないエクステントがOracle ASMによって再ミラー化(リバランスとも呼ばれる)されるため、冗長性が再確立されます。プロセスの再ミラー化を成功するには、新しいファイル・エクステントのミラー・コピーの作成に十分な空き領域がディスク・グループに存在する必要があります。十分な空き領域がないと、一部のエクステントが再ミラー化されず、他のデータ・コピーで後で障害が発生した場合に、ディスク・グループをバックアップからリストアする必要があります。領域の不足により再ミラー化プロセスが失敗すると、Oracle ASMはエラーを送信します。

Oracle Exadata Storage Server Softwareリリース12.1.2.1.0以上を使用するか、Oracle Bug#19695225のパッチをソフトウェアに適用する必要があります。

グリッド・ディスクのサイズを変更するこの手順は、ベア・メタルおよび仮想マシン(VM)デプロイメントに適用されます。

1. 使用可能な領域の容量の判別

2. ドナー・ディスク・グループのOracle ASMディスクの縮小

3. ドナー・ディスク・グループのグリッド・ディスクの縮小

4. 使用可能な領域によるグリッド・ディスクのサイズの拡張

5. Oracle ASMディスクのサイズの拡張

ASM容量およびExadataの空き領域の予約の理解(My Oracle SupportのドキュメントID 1551288.1)

Bug 19695225 - 時間をかけて多数のCreate GriddiskまたはAlter Griddiskコマンドを実行すると、セル・ディスク・メタデータが破損し(ORA-600 [addNewSegmentsToGDisk_2])、セル・ディスク内容が失われる(My Oracle SupportのドキュメントID 1991445.1)

3.4.1 使用可能な領域の容量の判別

ディスク・グループ内のディスクのサイズを増やすには、未割当てのディスク領域があるか、別のディスク・グループが現在使用している領域を再割当てする必要があります。

1. ディスク・グループによって現在使用されている領域を表示します。

SELECT name, total_mb, free_mb, total_mb - free_mb used_mb, round(100*free_mb/total_mb,2) pct_free
FROM v$asm_diskgroup
ORDER BY 1;

NAME                             TOTAL_MB    FREE_MB    USED_MB   PCT_FREE
------------------------------ ---------- ---------- ---------- ----------
DATAC1                           68812800    9985076   58827724      14.51
RECOC1                           94980480   82594920   12385560      86.96

この例では、DATAC1ディスク・グループには空き領域が約15%しかありませんが、RECOC1ディスク・グループには約87%の空きディスク領域があります。ここに表示されているPCT_FREEは未加工の空き領域です。使用できる空き領域ではありません。リバランス操作のためには追加の領域が必要です。

2. サイズを変更しようとするディスク・グループについて、ディスク・グループによって使用される障害グループの数とステータスを表示します。

SELECT dg.name, d.failgroup, d.state, d.header_status, d.mount_mode,
d.mode_status, count(1) num_disks
FROM V$ASM_DISK d, V$ASM_DISKGROUP dg
WHERE d.group_number = dg.group_number
AND dg.name IN ('RECOC1', 'DATAC1')
GROUP BY dg.name, d.failgroup, d.state, d.header_status, d.mount_status,
d.mode_status
ORDER BY 1, 2, 3;

NAME       FAILGROUP      STATE      HEADER_STATU MOUNT_S  MODE_ST  NUM_DISKS
---------- -------------  ---------- ------------ -------- -------  ---------
DATAC1     EXA01CELADM01  NORMAL     MEMBER        CACHED  ONLINE   12
DATAC1     EXA01CELADM02  NORMAL     MEMBER        CACHED  ONLINE   12
DATAC1     EXA01CELADM03  NORMAL     MEMBER        CACHED  ONLINE   12
DATAC1     EXA01CELADM04  NORMAL     MEMBER        CACHED  ONLINE   12
DATAC1     EXA01CELADM05  NORMAL     MEMBER        CACHED  ONLINE   12
DATAC1     EXA01CELADM06  NORMAL     MEMBER        CACHED  ONLINE   12
DATAC1     EXA01CELADM07  NORMAL     MEMBER        CACHED  ONLINE   12
DATAC1     EXA01CELADM08  NORMAL     MEMBER        CACHED  ONLINE   12
DATAC1     EXA01CELADM09  NORMAL     MEMBER        CACHED  ONLINE   12
DATAC1     EXA01CELADM10  NORMAL     MEMBER        CACHED  ONLINE   12
DATAC1     EXA01CELADM11  NORMAL     MEMBER        CACHED  ONLINE   12
DATAC1     EXA01CELADM12  NORMAL     MEMBER        CACHED  ONLINE   12
DATAC1     EXA01CELADM13  NORMAL     MEMBER        CACHED  ONLINE   12
DATAC1     EXA01CELADM14  NORMAL     MEMBER        CACHED  ONLINE   12
RECOC1     EXA01CELADM01  NORMAL     MEMBER        CACHED  ONLINE   12
RECOC1     EXA01CELADM02  NORMAL     MEMBER        CACHED  ONLINE   12
RECOC1     EXA01CELADM03  NORMAL     MEMBER        CACHED  ONLINE   12
RECOC1     EXA01CELADM04  NORMAL     MEMBER        CACHED  ONLINE   12
RECOC1     EXA01CELADM05  NORMAL     MEMBER        CACHED  ONLINE   12
RECOC1     EXA01CELADM06  NORMAL     MEMBER        CACHED  ONLINE   12
RECOC1     EXA01CELADM07  NORMAL     MEMBER        CACHED  ONLINE   12
RECOC1     EXA01CELADM08  NORMAL     MEMBER        CACHED  ONLINE   12
RECOC1     EXA01CELADM09  NORMAL     MEMBER        CACHED  ONLINE   12
RECOC1     EXA01CELADM10  NORMAL     MEMBER        CACHED  ONLINE   12
RECOC1     EXA01CELADM11  NORMAL     MEMBER        CACHED  ONLINE   12
RECOC1     EXA01CELADM12  NORMAL     MEMBER        CACHED  ONLINE   12
RECOC1     EXA01CELADM13  NORMAL     MEMBER        CACHED  ONLINE   12
RECOC1     EXA01CELADM14  NORMAL     MEMBER        CACHED  ONLINE   12

この例は、フル・ラック(DATAC1とRECOC1に対して14個のセルと14個の障害グループがある)のものです。各障害グループにNORMAL状態のディスクが12個以上(num_disks)あることを確認します。MISSINGと表示されるディスクがある場合、または構成で予期しない数のディスクが表示される場合は、問題を解決してから続きを行います。

Extreme Flash (EF)システムでは、ディスク数としてnum_disksに12ではなく8が表示されます。

3. 各セルと各障害グループに関連付けられた対応するグリッド・ディスクを表示して、サイズ変更するグリッド・ディスクを確認します。

SELECT dg.name, d.failgroup, d.path
FROM V$ASM_DISK d, V$ASM_DISKGROUP dg
WHERE d.group_number = dg.group_number
AND dg.name IN ('RECOC1', 'DATAC1')
ORDER BY 1, 2, 3;

NAME        FAILGROUP      PATH
----------- -------------  ----------------------------------------------
DATAC1      EXA01CELADM01  o/192.168.74.43/DATAC1_CD_00_exa01celadm01
DATAC1      EXA01CELADM01  o/192.168.74.43/DATAC1_CD_01_exa01celadm01
DATAC1      EXA01CELADM01  o/192.168.74.43/DATAC1_CD_02_exa01celadm01
DATAC1      EXA01CELADM01  o/192.168.74.43/DATAC1_CD_03_exa01celadm01
DATAC1      EXA01CELADM01  o/192.168.74.43/DATAC1_CD_04_exa01celadm01
DATAC1      EXA01CELADM01  o/192.168.74.43/DATAC1_CD_05_exa01celadm01
DATAC1      EXA01CELADM01  o/192.168.74.43/DATAC1_CD_06_exa01celadm01
DATAC1      EXA01CELADM01  o/192.168.74.43/DATAC1_CD_07_exa01celadm01
DATAC1      EXA01CELADM01  o/192.168.74.43/DATAC1_CD_08_exa01celadm01
DATAC1      EXA01CELADM01  o/192.168.74.43/DATAC1_CD_09_exa01celadm01
DATAC1      EXA01CELADM01  o/192.168.74.43/DATAC1_CD_10_exa01celadm01
DATAC1      EXA01CELADM01  o/192.168.74.43/DATAC1_CD_11_exa01celadm01
DATAC1      EXA01CELADM02  o/192.168.74.44/DATAC1_CD_00_exa01celadm01
DATAC1      EXA01CELADM02  o/192.168.74.44/DATAC1_CD_01_exa01celadm01
DATAC1      EXA01CELADM02  o/192.168.74.44/DATAC1_CD_02_exa01celadm01
...
RECOC1      EXA01CELADM13  o/192.168.74.55/RECOC1_CD_00_exa01celadm13
RECOC1      EXA01CELADM13  o/192.168.74.55/RECOC1_CD_01_exa01celadm13
RECOC1      EXA01CELADM13  o/192.168.74.55/RECOC1_CD_02_exa01celadm13
...
RECOC1      EXA01CELADM14  o/192.168.74.56/RECOC1_CD_09_exa01celadm14
RECOC1      EXA01CELADM14  o/192.168.74.56/RECOC1_CD_10_exa01celadm14
RECOC1      EXA01CELADM14  o/192.168.74.56/RECOC1_CD_11_exa01celadm14

168 rows returned.

4. 使用可能な空き領域をセル・ディスクで調べます。
セル・ディスク上の空き領域は、DATAC1グリッド・ディスクのサイズを増やすために使用できます。DATAC1グリッド・ディスクを拡張するために十分な空き領域がない場合は、RECOC1グリッド・ディスクを縮小して、DATAC1グリッド・ディスクの望ましいサイズを実現するために空き領域を提供する必要があります。

[root@exa01adm01 tmp]# dcli -g ~/cell_group -l root "cellcli -e list celldisk \
attributes name,freespace"
exa01celadm01: CD_00_exa01celadm01 0
exa01celadm01: CD_01_exa01celadm01 0
exa01celadm01: CD_02_exa01celadm01 0
exa01celadm01: CD_03_exa01celadm01 0
exa01celadm01: CD_04_exa01celadm01 0
exa01celadm01: CD_05_exa01celadm01 0
exa01celadm01: CD_06_exa01celadm01 0
exa01celadm01: CD_07_exa01celadm01 0
exa01celadm01: CD_08_exa01celadm01 0
exa01celadm01: CD_09_exa01celadm01 0
exa01celadm01: CD_10_exa01celadm01 0
exa01celadm01: CD_11_exa01celadm01 0
...

この例では空き領域がないため、最初にRECOC1グリッド・ディスクを縮小してDATAC1グリッド・ディスクのための領域を提供する必要があります。構成に使用可能な空き領域が豊富にある場合は、RECOC1グリッド・ディスクを縮小するかわりにその空き領域を使用できます。

5. RECOC1ディスク・グループと各グリッド・ディスクを縮小する領域の容量を計算します。

手順1に表示されている出力例では、RECOC1には豊富な空き領域があり、DATAC1の空き領域は15%未満でした。そこで、RECOC1を縮小して、解放されたディスク領域をDATAC1に提供します。RECOC1を現在のサイズの半部に縮小する場合、新しいサイズは94980480 / 2 = 47490240MBになります。

手順2の問合せでは、RECOC1に168個のグリッド・ディスクがあることがわかりました。14個のセルがあり、セルごとに12個のディスクがあるためです(14 * 12 = 168)。RECOC1ディスク・グループの各グリッド・ディスクの新しいサイズの見積もりは、47490240 / 168すなわち282,680MBです。

新しいグリッド・ディスク・サイズに最も近い16MBごとの境界を調べます。このチェックを実行しないと、セルによって、最も近い16MBごとの境界にグリッド・ディスク・サイズが自動的に切り下げられるため、Oracle ASMディスクとグリッド・ディスクの間でサイズの不一致が発生することがあります。

SQL> SELECT 16*TRUNC(&new_disk_size/16) new_disk_size FROM dual;
Enter value for new_disk_size: 282680

NEW_DISK_SIZE
-------------
282672

前述の結果に基づいて、RECOC1ディスク・グループのグリッド・ディスクの新しいサイズとして282672MBを選択することをお薦めします。グリッド・ディスクのサイズを変更すると、RECOC1ディスク・グループのサイズは47488896MBになります。

6. DATAC1ディスク・グループの各グリッド・ディスクのサイズをどれだけ増やすかを計算します。

Oracle ASMディスクのサイズとグリッド・ディスクのサイズがディスク・グループ全体で一致するようにします。次の問合せによって、各ディスク・グループのディスク・サイズの組合せが表示されます。理想は、すべてのディスクについて1つのサイズが見つかり、Oracle ASMディスク(total_mb)とグリッド・ディスク(os_mb)のサイズが一致することです。

SELECT dg.name, d.total_mb, d.os_mb, count(1) num_disks
FROM v$asm_diskgroup dg, v$asm_disk d
WHERE dg.group_number = d.group_number
GROUP BY dg.name, d.total_mb, d.os_mb;

NAME                             TOTAL_MB      OS_MB  NUM_DISKS
------------------------------ ---------- ---------- ----------
DATAC1                             409600     409600        168
RECOC1                             565360     565360        168

RECOC1のグリッド・ディスクを縮小した後で、DATAC1の各ディスクに次の領域が提供されます。

DATAC1ディスクの追加領域 = RECOC1_current_size - RECOC1_new_size
= 565360 - 282672 = 282688MB

DATAC1ディスク・グループの新しいサイズを計算するには、次を使用します。

DATAC1のディスクの新しいサイズ  = DATAC1_ disks_current_size + new_free_space_from_RECOC1
= 409600 + 282688 = 692288MB

新しいグリッド・ディスク・サイズに最も近い16MBごとの境界を調べます。このチェックを実行しないと、セルによって、最も近い16MBごとの境界にグリッド・ディスク・サイズが自動的に切り下げられるため、Oracle ASMディスクとグリッド・ディスクの間でサイズの不一致が発生することがあります。

SQL> SELECT 16*TRUNC(&new_disk_size/16) new_disk_size FROM dual;
Enter value for new_disk_size: 692288

NEW_DISK_SIZE
-------------
692288

問合せの結果に基づいて、DATAC1ディスク・グループのディスクについて計算したサイズ692288MBを使用できます。このサイズは16MBごとの境界に合っています。問合せの結果が指定した値と異なる場合は、問合せから返された値を使用する必要があります。セルによってこの値のグリッド・ディスク・サイズに切り上げ(または切り捨て)られるためです。

新しいグリッド・ディスク・サイズの計算値から、DATAC1ディスク・グループの合計サイズは116304384MB (168ディスク * 692288MB)になります。

3.4.2 ドナー・ディスク・グループのOracle ASMディスクの縮小

セル・ディスク上に使用可能な空き領域がない場合は、あるディスク・グループが使用する領域を減らして、別のディスク・グループに追加のディスク領域を提供することができます。

このタスクは、RECOC1ディスク・グループの領域をDATAC1ディスク・グループに再割当てする例の続きです。

ディスク・グループのサイズを変更する前に、領域を減らすディスク・グループに十分な空き領域があることを確認します。

1. RECOディスク・グループのOracle ASMディスクを縮小して、すべてのディスクが新しい目標サイズになるようにします。

RECOディスク・グループのディスクの新しいサイズとして、「使用可能な領域の容量の判別」の手順5で計算したものを使用します。

SQL> alter diskgroup RECOC1 resize all size 282672M rebalance power 64;

注意:
ALTER DISKGROUPコマンドは完了するまでに数分間かかることがあります。この処理が完了するまで、SQLプロンプトは表示されません。

リバランスが終了するまで待機してから、ビューGV$ASM_OPERATIONをチェックします。

SQL> set lines 250 pages 1000
SQL> col error_code form a10
SQL> SELECT dg.name, o.*
2  FROM gv$asm_operation o, v$asm_diskgroup dg
3  WHERE o.group_number = dg.group_number;

GV$ASM_OPERATIONへの問合せで、変更中のディスク・グループの行が表示されない場合のみ、次の手順に進みます。

2. 次の問合せを使用してASMディスクの新しいサイズを確認します。

SQL> SELECT name, total_mb, free_mb, total_mb - free_mb used_mb,
2   round(100*free_mb/total_mb,2) pct_free
3  FROM v$asm_diskgroup
4  ORDER BY 1;

NAME                             TOTAL_MB    FREE_MB    USED_MB   PCT_FREE
------------------------------ ---------- ---------- ---------- ----------
DATAC1                           68812800    9985076   58827724      14.51
RECOC1                           47488896   35103336   12385560      73.92

SQL> SELECT dg.name, d.total_mb, d.os_mb, count(1) num_disks
2  FROM v$asm_diskgroup dg, v$asm_disk d
3  WHERE dg.group_number = d.group_number
4  GROUP BY dg.name, d.total_mb, d.os_mb;

NAME                             TOTAL_MB      OS_MB  NUM_DISKS
------------------------------ ---------- ---------- ----------
DATAC1                             409600     409600        168
RECOC1                             282672     565360        168

前述の問合せの例では、RECOC1ディスク・グループのディスクのサイズが各々変更されて282672MGになり、ディスク・グループの合計サイズが47488896MBになったことが表示されます。

3.4.3 ドナー・ディスク・グループのグリッド・ディスクの縮小

Oracle ASMディスク・グループのディスクを縮小したら、各セルのグリッド・ディスクのサイズを縮小できます。

このタスクは、RECOC1ディスク・グループの領域をDATAC1ディスク・グループに再割当てする例の続きです。

「ドナー・ディスク・グループのOracle ASMディスクの縮小」のタスクを完了しておく必要があります。

1. すべてのセルのRECOディスク・グループに関連付けられたグリッド・ディスクを新しいサイズに縮小します。

「使用可能領域の容量の判別」の手順3で確認したストレージ・セルごとに、グリッド・ディスクを縮小して、前のタスクで縮小したOracle ASMディスクのサイズと一致するようにします。次のようなコマンドを使用します。

dcli -c exa01celadm01 -l root "cellcli -e alter griddisk RECOC1_CD_00_exa01celadm01 \
,RECOC1_CD_01_exa01celadm01 \
,RECOC1_CD_02_exa01celadm01 \
,RECOC1_CD_03_exa01celadm01 \
,RECOC1_CD_04_exa01celadm01 \
,RECOC1_CD_05_exa01celadm01 \
,RECOC1_CD_06_exa01celadm01 \
,RECOC1_CD_07_exa01celadm01 \
,RECOC1_CD_08_exa01celadm01 \
,RECOC1_CD_09_exa01celadm01 \
,RECOC1_CD_10_exa01celadm01 \
,RECOC1_CD_11_exa01celadm01 \
size=282672M "

dcli -c exa01celadm02 -l root "cellcli -e alter griddisk RECOC1_CD_00_exa01celadm02 \
,RECOC1_CD_01_exa01celadm02 \
,RECOC1_CD_02_exa01celadm02 \
,RECOC1_CD_03_exa01celadm02 \
,RECOC1_CD_04_exa01celadm02 \
,RECOC1_CD_05_exa01celadm02 \
,RECOC1_CD_06_exa01celadm02 \
,RECOC1_CD_07_exa01celadm02 \
,RECOC1_CD_08_exa01celadm02 \
,RECOC1_CD_09_exa01celadm02 \
,RECOC1_CD_10_exa01celadm02 \
,RECOC1_CD_11_exa01celadm02 \
size=282672M "

...

dcli -c exa01celadm14 -l root "cellcli -e alter griddisk RECOC1_CD_00_exa01celadm14 \
,RECOC1_CD_01_exa01celadm14 \
,RECOC1_CD_02_exa01celadm14 \
,RECOC1_CD_03_exa01celadm14 \
,RECOC1_CD_04_exa01celadm14 \
,RECOC1_CD_05_exa01celadm14 \
,RECOC1_CD_06_exa01celadm14 \
,RECOC1_CD_07_exa01celadm14 \
,RECOC1_CD_08_exa01celadm14 \
,RECOC1_CD_09_exa01celadm14 \
,RECOC1_CD_10_exa01celadm14 \
,RECOC1_CD_11_exa01celadm14 \
size=282672M "

2. 次のコマンドを使用してグリッド・ディスクの新しいサイズを確認します。

[root@exa01adm01 tmp]# dcli -g cell_group -l root "cellcli -e list griddisk attributes name,size where name like \'RECOC1.*\' "

exa01celadm01: RECOC1_CD_00_exa01celadm01 276.046875G
exa01celadm01: RECOC1_CD_01_exa01celadm01 276.046875G
exa01celadm01: RECOC1_CD_02_exa01celadm01 276.046875G
exa01celadm01: RECOC1_CD_03_exa01celadm01 276.046875G
exa01celadm01: RECOC1_CD_04_exa01celadm01 276.046875G
exa01celadm01: RECOC1_CD_05_exa01celadm01 276.046875G
exa01celadm01: RECOC1_CD_06_exa01celadm01 276.046875G
exa01celadm01: RECOC1_CD_07_exa01celadm01 276.046875G
exa01celadm01: RECOC1_CD_08_exa01celadm01 276.046875G
exa01celadm01: RECOC1_CD_09_exa01celadm01 276.046875G
exa01celadm01: RECOC1_CD_10_exa01celadm01 276.046875G
exa01celadm01: RECOC1_CD_11_exa01celadm01 276.046875G
...

前述の例では、RECOC1ディスク・グループのディスクのサイズが各々変更されて282672MB (276.046875 * 1024)になったことが表示されます。

3.4.4 使用可能な領域によるグリッド・ディスクのサイズの拡張

未割当てのディスク領域(すでに使用可能な領域、または別のOracle ASMディスク・グループで使用されている領域を縮小することで使用可能になった領域)がある場合は、グリッド・ディスクで使用されるサイズを増やすことができます。

このタスクは、RECOC1ディスク・グループの領域をDATAC1ディスク・グループに再割当てする例の続きです。既存のディスク・グループを拡張するために十分な領域がすでにある場合は、別のディスク・グループの領域を再割当てする必要はありません。

1. 予期した空き領域の容量がセル・ディスクにあることを調べます。
Oracle ASMディスクとグリッド・ディスクを縮小するタスクを完了している場合、セル・ディスクの空き領域は次のように表示されます。

[root@exa01adm01 tmp]# dcli -g ~/cell_group -l root "cellcli -e list celldisk \
attributes name,freespace"

exa01celadm01: CD_00_exa01celadm01 276.0625G
exa01celadm01: CD_01_exa01celadm01 276.0625G
exa01celadm01: CD_02_exa01celadm01 276.0625G
exa01celadm01: CD_03_exa01celadm01 276.0625G
exa01celadm01: CD_04_exa01celadm01 276.0625G
exa01celadm01: CD_05_exa01celadm01 276.0625G
exa01celadm01: CD_06_exa01celadm01 276.0625G
exa01celadm01: CD_07_exa01celadm01 276.0625G
exa01celadm01: CD_08_exa01celadm01 276.0625G
exa01celadm01: CD_09_exa01celadm01 276.0625G
exa01celadm01: CD_10_exa01celadm01 276.0625G
exa01celadm01: CD_11_exa01celadm01 276.0625G
...

2. ストレージ・セルごとにDATAグリッド・ディスクのサイズを目標の新しいサイズに増やします。

「使用可能な領域の容量の判別」で計算したサイズを使用します。

dcli -c exa01celadm01 -l root "cellcli -e alter griddisk DATAC1_CD_00_exa01celadm01 \
,DATAC1_CD_01_exa01celadm01 \
,DATAC1_CD_02_exa01celadm01 \
,DATAC1_CD_03_exa01celadm01 \
,DATAC1_CD_04_exa01celadm01 \
,DATAC1_CD_05_exa01celadm01 \
,DATAC1_CD_06_exa01celadm01 \
,DATAC1_CD_07_exa01celadm01 \
,DATAC1_CD_08_exa01celadm01 \
,DATAC1_CD_09_exa01celadm01 \
,DATAC1_CD_10_exa01celadm01 \
,DATAC1_CD_11_exa01celadm01 \
size=692288M "
...
dcli -c exa01celadm14 -l root "cellcli -e alter griddisk DATAC1_CD_00_exa01celadm14 \
,DATAC1_CD_01_exa01celadm14 \
,DATAC1_CD_02_exa01celadm14 \
,DATAC1_CD_03_exa01celadm14 \
,DATAC1_CD_04_exa01celadm14 \
,DATAC1_CD_05_exa01celadm14 \
,DATAC1_CD_06_exa01celadm14 \
,DATAC1_CD_07_exa01celadm14 \
,DATAC1_CD_08_exa01celadm14 \
,DATAC1_CD_09_exa01celadm14 \
,DATAC1_CD_10_exa01celadm14 \
,DATAC1_CD_11_exa01celadm14 \
size=692288M "

3. 次のコマンドを使用して、DATAC1ディスク・グループに関連付けられているグリッド・ディスクの新しいサイズを確認します。

dcli -g cell_group -l root "cellcli -e list griddisk attributes name,size \
where name like \'DATAC1.*\' "

exa01celadm01: DATAC1_CD_00_exa01celadm01 676.0625G
exa01celadm01: DATAC1_CD_01_exa01celadm01 676.0625G
exa01celadm01: DATAC1_CD_02_exa01celadm01 676.0625G
exa01celadm01: DATAC1_CD_03_exa01celadm01 676.0625G
exa01celadm01: DATAC1_CD_04_exa01celadm01 676.0625G
exa01celadm01: DATAC1_CD_05_exa01celadm01 676.0625G
exa01celadm01: DATAC1_CD_06_exa01celadm01 676.0625G
exa01celadm01: DATAC1_CD_07_exa01celadm01 676.0625G
exa01celadm01: DATAC1_CD_08_exa01celadm01 676.0625G
exa01celadm01: DATAC1_CD_09_exa01celadm01 676.0625G
exa01celadm01: DATAC1_CD_10_exa01celadm01 676.0625G
exa01celadm01: DATAC1_CD_11_exa01celadm01 676.0625G

DATAディスク・グループのサイズを増やすかわりに、新たに解放された空き領域を使用して新しいディスク・グループを作成することや、将来使用するために空き領域のままにしておくこともできます。一般的には、必要な最小限の数のディスク・グループ(通常はDATA、RECOおよびDBFS_DG)を使用して、高い柔軟性と管理のしやすさを実現することをお薦めします。ただし、場合によっては、仮想マシンを使用するとき、または多数のデータベースを統合するときなど、追加のディスク・グループや将来のための使用可能な空き領域が必要になる可能性があります。

将来のためにグリッド・ディスクに空き領域を残しておく場合は、後から既存のディスク・グループに空き領域を割り当てる手順について「My Oracle Support Note 1684112.1」を参照してください。

関連トピック

- http://www.oracle.com/technetwork/database/features/availability/exadata-consolidation-522500.pdf

- 「ExadataでASMディスクのサイズを変更する方法」(Doc ID 1684112.1)

3.4.5 Oracle ASMディスクのサイズの拡張

関連するグリッド・ディスクに割り当てられた領域を増やした後で、Oracle ASMディスクによって使用されるサイズを増やすことができます。

このタスクは、RECOC1ディスク・グループの領域をDATAC1ディスク・グループに再割当てする例の続きです。

Oracle ASMディスク・グループのサイズを変更するには、対応するグリッド・ディスクのサイズ変更のタスクを前もって完了しておく必要があります。

1. DATAC1ディスク・グループのOracle ASMディスクを、ストレージ・セル上のグリッド・ディスクの新しいサイズに増やします。

SQL> alter diskgroup DATAC1 resize all ;

このコマンドによって、Oracle ASMディスクのサイズがグリッド・ディスクのサイズと一致するように変更されます。

注意:

指定したディスク・グループでディスク・グループ内にquorumディスクが構成されている場合、ALTER DISKGROUP ... RESIZE ALLコマンドはエラーORA-15277で失敗することがあります。quorumディスクが構成されるのは、『Oracle Exadata Database Machineメンテナンス・ガイド』に記載されている要件が満たされる場合です。

対処方法としては、ストレージ・サーバー障害グループ名(FAILURE_TYPEが"REGULAR"であり、"QUORUM"ではない)をSQLコマンドに明示的に指定してください。次に例を示します。

SQL> ALTER DISKGROUP datac1 RESIZE DISKS IN FAILGROUP exacell01, exacell02, exacell03;

2. リバランス操作が完了するまで待機します。

SQL> set lines 250 pages 1000
SQL> col error_code form a10
SQL> SELECT dg.name, o.* FROM gv$asm_operation o, v$asm_diskgroup dg
WHERE o.group_number = dg.group_number;

変更されたディスク・グループについて問合せから行が戻されなくなるまで、次の手順に進まないでください。

3. Oracle ASMディスクとディスク・グループの新しいサイズが目標のサイズになったことを確認します。

SQL> SELECT name, total_mb, free_mb, total_mb - free_mb used_mb,
round(100*free_mb/total_mb,2) pct_free
FROM v$asm_diskgroup
ORDER BY 1;

NAME                             TOTAL_MB    FREE_MB    USED_MB   PCT_FREE
------------------------------ ---------- ---------- ---------- ----------
DATAC1                          116304384   57439796   58864588      49.39
RECOC1                           47488896   34542516   12946380      72.74

SQL>  SELECT dg.name, d.total_mb, d.os_mb, count(1) num_disks
FROM  v$asm_diskgroup dg, v$asm_disk d
WHERE dg.group_number = d.group_number
GROUP BY dg.name, d.total_mb, d.os_mb;

NAME                             TOTAL_MB      OS_MB  NUM_DISKS
------------------------------ ---------- ---------- ----------
DATAC1                             692288     692288        168
RECOC1                             282672     282672        168

問合せの結果から、RECOC1およびDATAC1のディスク・グループとディスクのサイズが、「使用可能な領域の容量の判別」で計算された値に変更されたことがわかります。

3.5 Oracle Exadata Storage Server Softwareレスキュー手順の使用

システム・ディスクで障害が発生した場合、オペレーティング・システムに破損したファイル・システムがある場合またはブート領域が損傷している場合、レスキュー手順が必要です。1つのシステム・ディスクのみで障害が発生した場合、リカバリにCellCLIコマンドを使用します。両方のシステム・ディスクで同時に障害が発生するまれな事例の場合、Oracle Exadata Storage Server Software CELLBOOT USBフラッシュ・ドライブで提供されるExadata Storage Serverレスキュー機能を使用する必要があります。

通常の冗長性を使用している場合、レスキューされるセルのミラー・コピーは1つだけです。レスキュー手順の実行中にこのミラーでも障害が発生すると、リカバリできないデータの損失が発生する可能性があります。ミラー・コピーでデータの完全なバックアップを作成し、すぐにミラー・コピー・セルをオフラインにしてレスキュー前の新しいデータ変更を防止することをお薦めします。これにより、レスキュー・プロセス中は、障害が発生したセルのグリッド・ディスクのすべてのデータおよびそのミラー・コピーにアクセスできなくなります。

Oracle ASMディスク修復タイマーのデフォルトの修復時間は、3.6時間です。この時間内にレスキュー手順を実行できないことがわかった場合、レスキュー手順を実行できるまで、Oracle ASMリバランス手順を使用してディスクをリバランスする必要があります。

障害が発生したセルのすべてのグリッド・ディスクにOracle ASMの複数のミラー・コピーがある場合など、高い冗長性のディスク・グループを使用している場合、障害が発生したセルをオフラインにします。構成したOracle ASMのタイムアウト後に、Oracle ASMにより、障害が発生したセルのグリッド・ディスクが自動的に削除され、ミラー・コピーを使用したデータのリバランスが開始されます。デフォルトのタイムアウトは2時間です。セルのレスキューに2時間以上かかる場合、Oracle ASMのレスキュー・セルのグリッド・ディスクを再作成する必要があります。

注意:

十分に注意してレスキュー手順を使用してください。誤って手順を使用すると、データの損失が発生する可能性があります。

レスキュー手順を使用する場合、次の点に注意してください。

- レスキュー手順により、セルの一部またはすべてのディスクが書き換えられる可能性があります。この場合、リカバリできずにそれらのディスクのすべての内容を失う可能性があります。
この手順を使用する場合は十分に注意し、プロンプトを確認してください。一部またはすべてのディスクのデータを損失してもかまわない場合にOracleサポート・サービスの支援だけでレスキュー手順を使用することが理想的です。

- レスキュー手順の実行中に明示的に選択しないかぎり、レスキュー手順により、データ・ディスクの内容またはシステム・ディスクのデータ・パーティションの内容は破棄されません。

- Oracle Exadata Storage Server Software 11gリリース2(11.2)以降、レスキュー手順により、Exadata Storage Serverソフトウェアが同じリリースにリストアされます。これには、最後に正常にブートしたときのセルのパッチが含まれます。レスキュー手順を使用しても、次の項目はリストアされません。

- アラート構成、SMTP情報、管理者の電子メール・アドレスなど、セルの構成。ただし、最後に/usr/local/bin/ipconfユーティリティの実行が成功したときに存在したネットワーク構成はリストアされます。セル、root、celladminおよびcellmonitorユーザーのSSH IDはリストアされます。
Exadata Storage ServerのILOM構成。通常、ILOM構成は、Exadata Storage Serverソフトウェアに障害が発生しても損われません。

- レスキュー手順により、データ・ディスクまたはシステム・ディスクのデータ・パーティションの確認または再構築は行われません。グリッド・ディスクにデータの破損がある場合、レスキュー手順は使用しないでください。かわりに、Oracle DatabaseおよびOracle ASMのレスキュー手順を使用してください。

正常なレスキューの実行後、セルを再構成し、データを保存する場合はセル・ディスクをインポートする必要があります。データを保存しない場合は、新しいセル・ディスクおよびグリッド・ディスクを作成する必要があります。

この項では、次の項目について説明します。

- CELLBOOT USBフラッシュ・ドライブを使用したレスキューの実行

- 損傷したCELLBOOT USBフラッシュ・ドライブの再作成

関連項目:

- タイマーのリセットの詳細は、『Oracle Exadata Storage Server Softwareユーザーズ・ガイド』を参照してください

- ALTER CELLコマンドの詳細は、『Oracle Exadata Storage Server Softwareユーザーズ・ガイド』を参照してください

- CellCLIユーティリティを使用したセル、セル・ディスクおよびグリッド・ディスクの構成の詳細は、『Oracle Exadata Storage Server Softwareユーザーズ・ガイド』を参照してください

3.5.1 CELLBOOT USBフラッシュ・ドライブを使用したレスキューの実行

CELLBOOT USBフラッシュ・ドライブを使用して、次の手順を実行します。

1. コンソールを使用して、Exadata Storage Serverに接続します。

2. Exadata Storage Serverを起動します。次のように表示されます。

Press any key to enter the menu
Booting Exadata_DBM_0: CELL_USB_BOOT_trying_C0D0_as_HD1 in 4 seconds...
Booting Exadata_DBM_0: CELL_USB_BOOT_trying_C0D0_as_HD1 in 3 seconds...
Press any key to see the menu.

Exadataソフトウェアの古いバージョンの場合、"Oracle Exadata"スプラッシュ画面が表示されます。スプラッシュ画面が表示されたら、キーボードの任意のキーを押します。スプラッシュ画面の表示は、5秒間のみです。

3. ブート・オプションの表示リストで、最後のオプションのCELL_USB_BOOT_CELLBOOT_usb_in_rescue_modeまで下にスクロールし、[Enter]を押します。

4. レスキュー・オプションを選択して、レスキュー手順に進みます。

5. システムの再起動を要求されたら、次の手順を実行するか、またはレスキューの最初のフェーズの最後にシェルを入力します。

a. 選択して、シェルを入力します。システムの再起動は選択しないでください。

b. レスキューのrootパスワードを使用してシェルにログインします。

c. シェルからrebootコマンドを実行します。

d. シェルが再起動したら、Oracle Exadataスプラッシュ画面が表示される前に[F8]を押します。F8キーを押すと、起動デバイス選択メニューが開きます。

e. 起動デバイスとしてRAIDコントローラを選択します。これにより、セルがハード・ディスクからブートされるようになります。

注意:

機能が制限されたレスキュー・モードのLinuxログイン・シェルを入力できる追加オプションを使用できる場合があります。Oracleサポート・サービスから提供されたパスワードを使用してrootユーザーとしてシェルにログインして、セルの追加診断および修復を手動で実行できます。詳細は、オンラインで入手できるこのリリースのリリース・ノートまたは最新のドキュメントを参照するか、Oracleサポート・サービス担当者に問い合せてください。

レスキューが成功した後、セルを構成する必要があります。データ・パーティションを維持した場合は、レスキュー手順の実行時にセル・ディスクが自動的にインポートされています。

1. レスキュー手順の実行中に交換されたディスクのセル・ディスクおよびグリッド・ディスクを再作成します。

2. グリッド・ディスクのステータスをチェックします。非アクティブの場合、次のコマンドを実行してアクティブ化します。

CellCLI> ALTER GRIDDISK ALL ACTIVE

3. Oracle ASMインスタンスにログインし、次のコマンドを使用して各ディスク・グループのディスクをONLINEに設定します。

SQL> ALTER DISKGROUP disk_group_name ONLINE DISKS IN FAILGROUP \
cell_name WAIT;

注意:

ディスクがすでに強制削除されているため、コマンドが失敗する場合は、ディスクをASMディスク・グループに強制追加する必要があります。

注意:

グリッド・ディスクのasmmodestatus属性とasmdeactivationoutcome属性は、ALTER DISKGROUP文が完了するまで正しく報告されません。

4. ALTER CELLコマンドを使用して、セルを再構成します。次に、最も一般的なパラメータの例を示します。

CellCLI> ALTER CELL
smtpServer='my_mail.example.com', -
smtpFromAddr='john.doe@example.com', -
smtpPwd=email_address_password, -
smtpToAddr='jane.smith@example.com', -
notificationPolicy='critical,warning,clear', -
notificationMethod='mail,snmp'

5. I/Oリソース管理(IORM)プランを再作成します。

6. メトリックしきい値を再作成します。

関連項目:

- IORMプランの詳細は、『Oracle Exadata Storage Server Softwareユーザーズ・ガイド』を参照してください

- メトリックしきい値の設定の詳細は、『Oracle Exadata Storage Server Softwareユーザーズ・ガイド』を参照してください

3.5.1.1 Oracle Exadata Database Machineエイス・ラックのストレージ・サーバーのレスキュー後の構成

Oracle Exadata Storage Server Softwareリリース11.2.3.3以上では、セルのレスキュー後に追加の手順は不要です。構成を検証するには、次の手順を使用します。

1. 別のストレージ・サーバーにある/opt/oracle.SupportTools/resourcecontrolユーティリティを、リカバリしたサーバーの/opt/oracle.SupportTools/resourcecontrolディレクトリにコピーします。

2. 次のコマンドを使用して、ユーティリティに対して適切な権限が設定されていることを確認します。

# chmod 740 /opt/oracle.SupportTools/resourcecontrol

3. 次のコマンドを使用して、現在の構成を検証します。コマンドの出力が表示されます。

# /opt/oracle.SupprtTools/resourcecontrol -show

Validated hardware and OS. Proceed.
Number of cores active: 6
Number of harddisks active: 6
Number of flashdisks active: 8

エイス・ラック構成の場合、6個のコア、6個のハード・ディスクおよび8個のフラッシュ・ディスクが有効になっている必要があります。他の値が表示された場合は、次のコマンドを使用して、エイス・ラック構成を有効にしてください。

CellCLI> ALTER CELL eighthRack=true

3.5.2 損傷したCELLBOOT USBフラッシュ・ドライブの再作成

CELLBOOT USBフラッシュ・ドライブの紛失または損傷が発生した場合、次の手順を使用して新しいドライブを作成できます。

注意:

Oracle Exadata Storage Server Softwareリリース12.1.2.1.0以上を実行するマシン用のUSBフラッシュ・ドライブを作成するには、Oracle Linux 6を実行するマシンが必要です。

1. rootユーザーとしてセルにログインします。

2. 新しいUSBフラッシュ・ドライブを取り付けます。このフラッシュ・ドライブには、少なくとも1GBから最大8GBの容量が必要です。

3. システムから他のUSBフラッシュ・ドライブを取り外します。

4. 次のコマンドを実行します。

cd /opt/oracle.SupportTools
./make_cellboot_usb -verbose -force

3.6 「ストレージ・セルの既存のエラスティック構成の変更」

この項では、既存のエラスティック構成に次の変更を行う方法について説明します。

- セル・ノードの追加

- 既存のExadataストレージ・グリッドの拡張

- 既存のディスク・グループまたはストレージ・グリッドからのストレージ・セルの削除

関連トピック

- データベース・サーバーの既存のエラスティック構成の変更

3.6.1 セル・ノードの追加

このシナリオでは、ディスク・グループを含む既存のExadataストレージ・グリッドに新しいセルを追加します。

1. 新しいセルの場合は、次の手順を実行します。

a. 目的のストレージ・グリッドで新しいストレージ・セルを利用できるようにするために、必要なすべてのケーブル接続要件を完了します。『Oracle Exadata Database Machineインストレーションおよび構成ガイド』を参照してください。

b. 適切なOSSイメージでセルをイメージ化し、IPアドレスの入力を求められたときに適切な入力を提供します。

手順3にスキップします。

2. ラック内の既存のセルをInfiniBandネットワーク内の別のクラスタに割り当てる場合は、追加するセルのInfiniBandインタフェース(ib0およびib1)に割り当てられているIPアドレスをメモします。

3. すべてのOracle RACノードの/etc/oracle/cell/network-config/cellip.oraファイルに、前述の手順からのIPアドレスを追加します。これを行うには、クラスタ内の任意のデータベース・サーバー上で次の手順を実行します。

a. cd /etc/oracle/cell/network-config

b. cp cellip.ora cellip.ora.orig

c. cp cellip.ora cellip.ora-bak

d. /etc/oracle/cell/network-config/cellip.ora-bakに新しいエントリを追加します。

e. /usr/local/bin/dcli -g database_nodes -l root -f cellip.ora-bak -d /etc/oracle/cell/network-config/cellip.ora
database_nodesは、クラスタ内の各データベース・サーバーの名前が含まれているファイルを参照します。名前は、それぞれ別の行にあります。

4. 既存のストレージ・セルにASRアラートが設定されていた場合は、追加するセルのためにセルのASRアラートを構成します。

a. セルのASRアラートを構成するために必要なセルの属性をリストします。いずれかの既存のストレージ・グリッド・セルから、次のコマンドを実行します。

cellcli -e list cell attributes snmpsubscriber

b. celladminユーザーとして次のコマンドを実行して、新しいセルに同じSNMP値を適用します。

cellcli -e "alter cell snmpsubscriber=snmpsubscriber"

snmpsubscriberを前述のコマンドからの値に置き換えます。

5. 追加するセルのセル・アラートを構成します。

a. セル・アラートを構成するために必要なセルの属性をリストします。いずれかの既存のストレージ・グリッド・セルから、次のコマンドを実行します。

cellcli -e list cell attributes
notificationMethod,notificationPolicy,smtpToAddr,smtpFrom,
smtpFromAddr,smtpServer,smtpUseSSL,smtpPort

b. celladminユーザーとして次のコマンドを実行して、新しいセルに同じ値を適用します。

cellcli -e "alter cell
notificationMethod='notificationMethod',
notificationPolicy='notificationPolicy',
smtpToAddr='smtpToAddr',
smtpFrom='smtpFrom',
smtpFromAddr='smtpFromAddr',
smtpServer='smtpServer',
smtpUseSSL=smtpUseSSL,
smtpPort=smtpPort"

プレースホルダを既存のセルから検出された値に置き換えます。

6. 追加するセルのセル・ディスクを作成します。

a. celladminとしてセルにログインし、次のコマンドを実行します。

cellcli -e create celldisk all

b. デフォルトでフラッシュ・ログが作成されたことを確認します。

cellcli –e list flashlog

フラッシュ・ログの名前が表示されます。cellnodename_FLASHLOGのような名前で、ステータスが"normal"になっていることを確認してください。

フラッシュ・ログが存在しない場合は、次を使用して作成します。

cellcli -e create flashlog all

c. 現在のフラッシュ・キャッシュ・モードを、既存セルのフラッシュ・キャッシュ・モードと比較します。

cellcli -e list cell attributes flashcachemode

フラッシュ・キャッシュ・モードを変更して既存のセルのフラッシュ・キャッシュ・モードに一致させるには、次の手順を実行します。

i.フラッシュ・キャッシュが存在し、セルがWriteBackフラッシュ・キャッシュ・モードの場合、フラッシュ・キャッシュを最初にフラッシュする必要があります。

cellcli –e alter flashcache all flush

コマンドが戻るまで待機します。

ii.フラッシュ・キャッシュを削除します。

cellcli -e "drop flashcache all"

iii.フラッシュ・キャッシュ・モードを変更します。

cellcli -e "alter cell flashCacheMode=writeback_or_writethrough"

flashCacheMode属性の値は、writebackまたはwritethroughのいずれかです。クラスタ内の他のストレージ・セルと同じフラッシュ・キャッシュ・モードになるように、値を設定する必要があります。

iv.フラッシュ・キャッシュを作成します。

cellcli -e create flashcache all

7. 追加するセルのグリッド・ディスクを作成します。

a. 既存のセルからの既存のグリッド・ディスクのsizeとcachingpolicyを問い合せます。

CellCLI> list griddisk attributes name,asmDiskGroupName,cachingpolicy,size,offset

b. 前述のコマンドで検出された各ディスク・グループについて、クラスタに追加する新しいセルのグリッド・ディスクを作成します。前述のコマンドで報告されたその特定のディスク・グループの既存のグリッド・ディスクのsizeとcachingpolicyを一致させます。既存のセルと同様のレイアウトおよびパフォーマンス特性になるように、グリッド・ディスクはオフセットの昇順で作成する必要があります。たとえば、"list griddisk"コマンドで次のような出力が返されたとします。

DATAC1          default         2.15625T        32M
DBFS_DG         default         33.796875G      2.695465087890625T
RECOC1          none            552.109375G     2.1562957763671875T

グリッド・ディスクを作成するときには、DATAC1、RECOC1、DBFS_DGの順序で次のコマンドを使用して作成します。

cellcli -e create griddisk
PREFIX=matching_prefix_of_the_corresponding_existing_diskgroup,
size=size_followed_by_G_or_T,
cachingPolicy=\'value_from_command_above_for_this_disk_group\',
comment =\"Cluster cluster_name diskgroup diskgroup_name\"

警告: 次のように、EXACTサイズを単位(TまたはG)とともに指定してください。

8. 新しく作成されたグリッド・ディスクがOracle RACノードから参照できることを確認します。各Oracle RACノードにログインし、次のコマンドを実行します。

$GI_HOME/bin/kfod op=disks disks=all | grep cellName_being_added

前述の手順7で作成したすべてのグリッド・ディスクがリストされる必要があります。

9. 新しく作成されたグリッド・ディスクをそれぞれの既存のASMディスク・グループに追加します。

alter diskgroup disk_group_name add disk 'comma_separated_disk_names';

comma_separated_disk_namesは、disk_group_nameに対応する手順5のディスク名を指します。

このコマンドはデフォルトの電源レベルでASMリバランス操作を開始します。gv$asm_operationの問合せにより、リバランスの進捗状況を監視します。

SQL> select * from gv$asm_operation;

リバランスが完了すると、Oracle RACへのセルの追加は完了です。

10. 最新のexachkをダウンロードして実行し、結果の構成にOracle Exadataの最新のベスト・プラクティスが実装されたことを確認します。

3.6.2 既存のExadataストレージ・グリッドの拡張

このシナリオでは、Exadataラック内にExadataストレージ・セルが存在し、最も拡張の必要なExadataストレージ・グリッドにストレージ・セルを追加します。

1. 現在のクラスタからストレージ・セルを廃止します。これを実行するには、「既存のディスク・グループまたはストレージ・グリッドからのストレージ・セルの削除」の手順に従ってください。

2. 目的のExadataストレージ・グリッドにストレージ・セルを追加します。これを実行するには、「セル・ノードの追加」の手順に従ってください。

3. 最新のexachkをダウンロードして実行し、結果の構成にOracle Exadataの最新のベスト・プラクティスが実装されたことを確認します。

3.6.3 既存のディスク・グループまたはストレージ・グリッドからのストレージ・セルの削除

既存のOracle Exadataストレージ・グリッドからストレージ・セルを削除できます。

1. Oracle ASMから削除されるセルに属するディスクを削除します。

注意:

Oracle Exadata Oracle VMデプロイメントでは、すべてのVMクラスタから次のサブステップを実行する必要があります。

a. クラスタ内の任意のノードにログインします。

b. 対象となるExadataセルのクラスタで使用されているグリッド・ディスクのリストを問い合せます。

Grid_home/bin/asmcmd  lsdsk --suppressheader | grep cellName_being_removed | awk -F'/' '{print $NF}'

注意:

削除されるストレージ・セルからのディスクを含むすべてのディスク・グループ内の使用可能な空き領域が、そのディスク・グループに割り当てられた記憶域の少なくとも15%であることを確認してください。

c. 前述のコマンドで返されたOracle ASMディスクをそれぞれのディスク・グループから削除します。

SQL> ALTER DISKGROUP diskgroup_name DROP DISKS IN FAILGROUP cellName_being_removed;

d. このディスク削除操作により、デフォルトの電源レベルでリバランス操作が開始されます。次のコマンドを使用して、リバランスを監視します。

SQL> SELECT * FROM gv$asm_operation;

リバランスが完了するまで、つまり、gv$asm_operationから行が返されなくなるまで待ちます。

e. すべてのディスク・グループが、削除されるセルのディスクを参照していないことを確認します。

SQL> SELECT path, name, header_status, mode_status, mount_status, state,
failgroup FROM v$asm_disk ORDER BY path;

削除されるセルに属するすべてのディスクのheader_status列は、「FORMER」と表示される必要があります。

注意:

Exadata Oracle VMデプロイメントでは、すべてのOracle VMクラスタから前述のサブステップを実行する必要があります。

2. 削除するセルをクリーンアップします。

celladminとしてセルにログインし、次のコマンドを実行します。各グリッド・ディスクに対して次のコマンドを実行します。

a. グリッド・ディスクを削除します。

cellcli -e drop griddisk all prefix=prefix_of_the_grid_disk

b. フラッシュ・キャッシュが存在し、セルがWriteBackフラッシュ・キャッシュ・モードの場合、削除前にフラッシュ・キャッシュをフラッシュする必要があります。

cellcli -e alter flashcache all flush

コマンドが戻るまで待機します。

c. フラッシュ・キャッシュを削除します。

cellcli -e drop flashcache all

d. セル・ディスクを削除します。

cellcli -e drop celldisk all

データを安全に消去するには、DROP CELLDISKコマンドをeraseオプションを指定して実行するか、DROP CELLコマンドをeraseオプションを指定して実行します。

DROP CELLコマンドの下の表内に消去操作の所要時間が表示されます。

3. クラスタ内のすべてのデータベース・サーバー・ノードの/etc/oracle/cell/network-config/cellip.oraから、削除するセルのエントリを削除します。
クラスタ内の任意のデータベース・サーバー・ノードで次の手順を実行します。

a. cd /etc/oracle/cell/network-config

b. cp cellip.ora cellip.ora.orig

c. cp cellip.ora cellip.ora-bak

d. 削除するセルのエントリを/etc/oracle/cell/network-config/cellip.ora-bakから削除します。

e. /usr/local/bin/dcli -g database_nodes -l root -f cellip.ora-bak -d /etc/oracle/cell/network-config/cellip.ora
database_nodesは、クラスタ内の各データベース・サーバーの名前が含まれているファイルを参照します。名前は、それぞれ別の行にあります。

4. Oracle ExaCHKの最新バージョンをダウンロードして実行し、結果の構成にOracle Exadataの最新のベスト・プラクティスが実装されたことを確認します。

4 Oracle Exadataラックの他のコンポーネントの保守

この章のトピックは、次のとおりです:

- 「配電ユニットの交換」

- 「無反応になったILOMのリセット」

- サービス・プロセッサおよびILOMネットワーク設定の構成

- 1GbE接続から10GbE接続への変更

- InfiniBandネットワークの保守

- InfiniBandパーティションの構成

- InfiniBand IPアドレスおよびホスト名の変更

- データベース・サーバーでのネットワーク・ルーティングの構成

- 「DNSサーバーの変更」

- 「NTPサーバーの変更」

- 「タイムゾーン設定の変更」

- KVMスイッチの構成

注意:

- 読みやすさを考慮して、Oracle Exadata Database MachineとOracle Exadata Storage拡張ラックの両方に言及する場合、「Oracle Exadataラック」という名前を使用します。

- この章のすべての手順は、Oracle Exadata Database MachineおよびOracle Exadata Storage拡張ラックに適用されます。

関連トピック

- 交換ユニット

- Oracle Exadata Database MachineおよびOracle Exadataラックのエラー・メッセージ

4.1 配電ユニットの交換

配電ユニット(PDU)は、Oracle Exadataラックがオンライン中に交換できます。PDU-Aは、ラックを背面から見て左側、PDU-Bは右側にあります。

4.1.1 PDU交換のガイドラインの確認

手順を安全にし可用性を損なわないために、PDUを交換する前に、次のガイドラインを確認してください。

- PDU-Aの取外しまたは挿入中に、InfiniBandケーブルのラッチを解除すると、ノードがクラスタから削除されるため、サービスが失われます。これにより、ラックが使用できなくなる場合があります。通常、InfiniBandケーブルはラッチでしっかりと固定されているため、取扱いには注意してください。InfiniBandケーブルを無理な力で引っ張らないでください。

- 間違った電源フィードのフックを外すと、ラックが停止します。交換するPDUから伸びている電源ケーブルを電源までたどり、それらのフィードのみを抜いてください。

- PDU交換部品の開封と再梱包は慌てずに行ってください。故障したユニットを同じように再梱包できるように、電源コードが梱包品の中でどのように巻かれているかに注意してください。

- サイド・パネルを取り外しておくと、PDUの交換に必要な時間を短縮できます。ただし、PDUを交換する際にサイド・パネルを取り外す必要はありません。

- コードレス・ドリルまたは電動ドライバを使用すると、PDUの交換に必要な時間を短縮できます。交換ラックに付属のハンド・レンチ・ツールを使用する場合は、交換に少し時間がかかります。ドライバを使用する場合は、Torx T30およびT25ビットを用意してください。

- 電源ケーブルを移動するには、サーバーのケーブル・アームの取外しが必要になる場合があります。これが該当する場合、ケーブル・アームのクリップを外さなくても済むように、プラグ接続をねじり、ケーブル・アーム・コネクタを曲げます。ケーブル・アームのクリップを外す必要がある場合は、片方の手でケーブルを支えて電源コードを外し、ケーブル・アームをクリップで留めます。ケーブル・アームはつるしたままにしないでください。

- T30ねじをL金具から外す場合は、PDUをラックから取り外すまで、PDUと金具を取り付けているT25ねじまたはナットを外さないでください。

4.1.2 PDUの交換

この手順では、配電ユニット(PDU)の交換方法について説明します。

1. PDUの交換の理由にならない場合は、PDUモニターを使用して、次のようにネットワーク設定を識別します。

a. カウント(5から0)が開始されるまで、リセット・ボタンを押します。カウントダウン中にボタンを放し、再度押します。

注意:

カウントダウンを開始するには、リセット・ボタンを20秒押す必要があります。

b. モニターが再起動したら、LCDに表示される設定やファームウェア・バージョンなどを記録します。

注意:

PDUモニターが機能していない場合は、ネットワーク経由でPDUに接続してネットワーク設定を取得するか、ネットワーク管理者から取得します。

2. すべてのPDUブレーカをオフにします。

3. PDUの電源プラグをACコンセントから抜きます。

注意:

- 電源コードが頭上の配線を使用している場合は、人に落ちたり当たったりしない場所に電源プラグを置きます。

- 高くした床にラックがある場合は、床の切抜き部分から電源コードを出します。電源コードを出すには、ラックを切抜き部分の上に移動する必要が生じる場合があります。

4. サイド・パネルにアクセスできず、ラックにInfiniBandケーブル・ハーネスがない場合は、PDU-Bの交換で次の手順を実行します。

注意:

ケーブル・アームに取り付けられているケーブルのストラップを外さないでください。

a. 四角のケーブル・アームをラックに留めているT25ねじを外します。

b. InfiniBandケーブルを邪魔にならないように中央に動かします。

5. サーバーおよびスイッチからPDUに接続されているすべての電源ケーブルを外します。電源ケーブルをグループの束にしてまとめておきます。

6. L金具の上部と下部からT30ねじを外し、ねじの位置をメモしておきます。

7. ラック・フレーム内のPDUの設置位置をメモしておきます。ブレーカ・スイッチを使用できるようにするために、通常はラック・フレームから後ろに1インチの位置にします。

8. PDUを斜めにしてラックから取り出します。

9. PDUを持ったまま(十分な空間がある場合は下ろし)、AC電源コードをラックに通します。ACコード・フラッシュをPDUの下部に固定するケーブル・タイを切断する必要が生じる場合があります。

10. ラックの下部または上部(サーバー間の空間のある場所)にできるだけ近くなるようにコードを引き、コンセントのプラグを配線用の穴に通します。

11. 小さい方のTorx T25ねじを外し、上部および下部のナットを緩めてPDUをL金具から取り外します。ナットは外す必要はありません。

12. L金具を新しいPDUに取り付けます。

13. 新しいPDUをラックの横に置きます。

14. ACコードをラックに通してコンセントまで配線します。

注意:

この時点では、ACコードを新しいPDUにケーブル・タイしないでください。

15. L金具が上部および下部のレールの上に来るまで、確度と位置を調整して、新しいPDUをラック内に置きます。

16. 穴とスロットの位置を整列し、PDUがラック・フレームの後ろ約1インチの位置になるようにします。

17. コードのラベルに従って、電源コードを取り付けます。たとえば、G5-0は、PDUのPDUグループ5のコンセント0を示しています。

18. 手順4でInfiniBandケーブル・ホルダを取り外した場合は、取り付けます。ねじがすり減らないようにするには、ホルダのねじを手で締めることをお薦めします。

19. AC電源コードをコンセントに接続します。

20. ブレーカをオンにします。

21. PDUモニターのケーブルを配線し、必要に応じてネットワークをプログラムします。

関連項目:

- PDUモニターのプログラミングの詳細は、Sun Rack II電力配分装置ユーザーズ・ガイド(https://docs.oracle.com/cd/E19657-01/html/E23956/index.html)を参照してください

- Exadata Database MachineおよびExadata Storage Serverのサポートされているバージョン(My Oracle SupportのドキュメントID 888828.1)

4.2 無反応になったILOMのリセット

Integrated Lights Out Manager (ILOM)が無反応になる場合があります。その場合は、手動の操作によってILOMのサービス・プロセッサ(SP)をリセットする必要があります。次の手順では、ILOMをリセットする方法について説明します。

- SSHを使用したILOMのリセット

- ILOMリモート・コンソールを使用したILOMのリセット

- IPMItoolを使用したILOMのリセット

- Oracle Exadata Database Machine X2-2 ServerおよびExadata Storage ServerでのSPリセット・ピンを使用したILOMのリセット

- Sun Fire X4800 Oracle Database ServerおよびSun Server X2-8 Oracle Database ServerからのSPの取り外し

- ILOM電源からプラグを抜く

関連項目:

Oracle Integrated Lights Out Manager (ILOM)のドキュメント(http://www.oracle.com/goto/ilom/docs)

4.2.1 SSHを使用したILOMのリセット

次の手順では、SSHを使用してILOMに接続してリセットする方法について説明します。

1. SSHを使用して、別のマシンからILOMに接続します。

2. ILOMプロンプトで次のコマンドを入力します。

reset /SP

4.2.2 ILOMリモート・コンソールを使用したILOMのリセット

SSHを使用してILOMに接続できない場合は、ILOMリモート・コンソールにログインします。次の手順では、リモート・コンソールを使用してILOMをリセットする方法について説明します。

1. ILOMリモート・コンソールにログインします。

2. 「メンテナンス」タブからSPのリセットを選択します。

3. SPのリセットをクリックします。

4.2.3 IPMItoolを使用したILOMのリセット

SSHまたはリモート・コンソールを使用してILOMに接続できない場合は、ローカル・ホストまたはILOMネットワーク上の別のホストにログインして、IPMItoolを使用します。次の手順では、IPMItoolを使用してILOMをリセットする方法について説明します。

1. ローカル・ホストまたはILOMネットワーク上の別のホストにログインします。

2. 次のIPMItoolコマンドを実行します。

- ローカル・ホストを使用する場合:

$ ipmitool mc reset cold
Sent cold reset command to MC

- 別のホストを使用する場合:

$ ipmitool -H ILOM_host_name -U ILOM_user mc reset cold
Sent cold reset command to MC

前述のコマンドのILOM_host_nameは使用中のホスト名、ILOM_userはILOMのユーザー名です。

4.2.4 Oracle Exadata Database Machine X2-2 ServerおよびExadata Storage ServerでのSPリセット・ピンを使用したILOMのリセット

SSH、リモート・コンソール、またはOracle Exadata Database Machine X2-2サーバーまたはExadata Storage ServerのIPMItoolを使用してILOMに接続できない場合は、SPリセット・ピンを押します。次の手順では、SPリセット・ピンを使用してILOMをリセットする方法について説明します。

1. 非導電性の小さい棒を用意します。

2. ラックの背面に移動します。

3. SPリセット・ピンの開口部を特定します。SPリセット・ピンの開口部は、NET MGTポートの右側にある最初の開口部です。

4. 開口部に棒を挿入し、ピンを押します。

4.2.5 Sun Fire X4800 Oracle Database ServerおよびSun Server X2-8 Oracle Database ServerからのSPの取り外し

SSH、リモート・コンソールまたはIPMItoolを使用して、Sun Fire X4800 Oracle Database ServerまたはSun Server X2-8 Oracle Database ServerでILOMをリセットできない場合は、サーバーからサービス・プロセッサ(SP)を取り外して、再度取り付けます。

オペレーティング・システム・レベルでメッセージが表示されます。これらのメッセージは無視できます。ファンの制御がないため、ファンの速度が上がります。

- Sun Fire X4800 Serverサービス・マニュアルのサービス・プロセッサ・モジュールの取外しおよび取付け(CRU)に関する項(http://docs.oracle.com/cd/E19140-01/html/821-0282/gjfvy.html#scrolltoc)を参照してください

4.2.6 ILOM電源からプラグを抜く

前述のオプションを使用してILOMをリセットできない場合は、電源のプラグを抜いて、再度差し込みます。この操作により、サーバーおよびILOMの電源が入れ直されます。

4.3 サービス・プロセッサおよびILOMネットワーク設定の構成

次の手順では、サービス・プロセッサ(SP)およびILOMネットワーク設定を構成する方法について説明します。

1. SSHを使用してrootユーザーとしてSPにログインします。

2. versionコマンドを使用して、SP/ILOMファームウェア・リリースを確認します。次に、コマンドの出力例を示します。

-> version
SP firmware 3.2.4.10
SP firmware build number: 93199
SP firmware date: Sat Oct  4 18:42:56 EDT 2014
SP filesystem version: 0.2.10

注意:

ipmitoolを使用して、サーバーSPにログインします。この方法は、管理ネットワークからSP/ILOMにアクセスできない場合に便利です。次のコマンドを使用して、SPに接続します。

# ipmitool sunoem cli
Connected. Use ^D to exit.
-> version
SP firmware 3.2.4.10
SP firmware build number: 93199
SP firmware date: Sat Oct  4 18:42:56 EDT 2014
SP filesystem version: 0.2.10

3. 次のようにsetコマンドを使用して、DNSサーバーを構成します。

cd /SP/clients/dns/
/SP/clients/dns
show
/SP/clients/dns
Targets:
Properties:
auto_dns = enabled
nameserver = 0.0.0.0
retries = 1
searchpath =
timeout = 5
Commands:
cd
set
show
set nameserver=192.68.0.2
set searchpath=yourdomain.com

4. 次のようにsetコマンドを使用して、NTPサーバーを構成します。

cd /SP/clients/ntp/server/1/
/SP/clients/ntp/server/1
show
/SP/clients/ntp/server/1
Targets:
Properties:
address = 0.0.0.0
Commands:
cd
set
show
set address=192.68.0.1

注意:

2つのNTPサーバーを構成できます。最初のNTPサーバーをsetコマンドを使用して設定し、それから、もう1つのサーバーをパスSP/clients/ntp/server/2 to configureを使用して設定します。

5. 次のようにsetコマンドを使用して、ネットワーク設定を構成します。

cd /SP/network
/SP/network
show
/SP/network
Targets:
interconnect
ipv6
test
Properties:
commitpending = (Cannot show property)
dhcp_clientid = none
dhcp_server_ip = none
ipaddress = 0.0.0.0
ipdiscovery = dhcp
ipgateway = 0.0.0.0
ipnetmask = 0.0.0.0
managementport = MGMT
pendingipaddress = 0.0.0.0
pendingipdiscovery = dhcp
pendingipgateway = 0.0.0.0
pendingipnetmask = 0.0.0.0
pendingmanagementport = MGMT
pendingvlan_id = (none)
state = enabled
vlan_id = (none)
Commands:
cd
set
show

6. ipaddress、ipdiscovery、ipgateway、ipnetmaskおよびvlan_idのそれぞれのpendingip*設定を構成し、次のコマンドを使用して保留中の設定をコミットします。

set commitpending=true

7. ネットワーク構成が完了した後、コマンド・ライン・インタフェースの接続を解除します。

注意:

ipmitoolを使用している場合、^Dでセッションを終了します。

4.4 1GbE接続から10GbE接続への変更

Sun Server X4-2 Oracle Database Server、Sun Server X3-2 Oracle Database Server、Sun Fire X4170 M2 Oracle Database Server、Oracle Server X6-8 Database Server、Oracle Server X5-8 Database Server、Sun Server X4-8 Oracle Database Server、Sun Server X3-8 Oracle Database Server、Sun Fire X4800 Oracle Database Serverには、10ギガビット・イーサネット(GbE)ネットワーク・カードが搭載されています。

1GbE接続は10GbE接続に変更できます。接続を変更するときは、次の点に注意してください。

- Oracle Exadata Database Machine X2-8フル・ラックに接続された10GbEインタフェースの単一障害点を避けるために、NEM0 NET1およびNEM1 NET0などの2枚のカードのNetwork Express Module(NEM)で異なるポートを使用します。

- 10GbEインタフェースは、Sun Fire X4170 M2 Oracle Database Serverではeth4およびeth5として、Sun Fire X4800 Oracle Database Serverではeth8からeth15として識別されます。Oracle Exadata Database Machine X2-8フル・ラックでは、次を使用することをお薦めします。

- インタフェースeth9およびeth15を使用したBONDETH0

- 10GbE NEM0(左)/NET1

- 10GbE NEM1(右)/NET3

- この手順の実行中に、Oracle Clusterwareがシャットダウンし、データベース・サーバーが再起動されます。

この項の内容は次のとおりです。

- 作業1: ping機能の検証

- 作業2: 現在のインタフェース・ファイルのバックアップ

- 作業3: 10GbEインタフェース設定の編集

- 作業4: 10GbEインタフェースの検証

4.4.1 作業1: ping機能の検証

次のコマンドを使用して、変更する前にpingコマンドの機能を検証します。変更前にpingコマンドを検証すると、インタフェース変更後の結果がどのようになるかがわかります。同様のコマンドを使用して、Oracle Exadata Database Machineに接続する他のサーバーをチェックできます。

# grep "^nameserver" /etc/resolv.conf
nameserver ip_address_1
nameserver ip_address_2

# ping -c 2 ip_address_1
PING ip_address_1 (ip_address_1) 56(84) bytes of data.
64 bytes from ip_address_1: icmp_seq=1 ttl=57 time=1.12 ms
64 bytes from ip_address_1: icmp_seq=2 ttl=57 time=1.05 ms

--- ip_address_1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 1.054/1.087/1.120/0.033 ms

テストに失敗すると100%パケット損失と表示され、これと同じ検証を「作業4: 10GbEインタフェースの検証」で実行したときにも、同じ結果になることが想定されます。テストが成功すると0%パケット損失と表示され、10GbE接続を変更後、同様の結果が表示されます。

4.4.2 作業2: 現在のインタフェース・ファイルのバックアップ

次の手順は、現在のインタフェース・ファイルのバックアップ方法を示しています。

1. rootユーザーとしてログインします。

2. 次のように、/etc/sysconfig/network-scriptsディレクトリに現在のファイルと新しい10GbEファイル用の非表示ディレクトリを作成します。

# cd /etc/sysconfig/network-scripts
# mkdir .Pre_10GigE_Settings
# mkdir .Post_10GigE_Settings

注意:

Linuxのスタートアップ・スクリプトによりifcfgで始まるファイルが検索され、ifcfgで始まるファイルがネットワーク設定に使用されます。バックアップ・ファイルを非表示ディレクトリに置くと、ネットワーク・インタフェースの設定に使用されないようにできます。

3. 次のコマンドを使用して、接続された10GbEインタフェースを識別します。各10GbEインタフェースに対して、このコマンドを実行します。

# ethtool interface

前述のコマンドのinterfaceは、10GbEインタフェースです。Sun Fire X4170 M2 Oracle Database Serverのインタフェースはeth4およびeth5、Sun Fire X4800 Oracle Database Serverのインタフェースはeth8からeth15です。

次に、コマンドの出力例を示します。速度は10000Mb/s、リンク検出はありで、二重化はフルです。

# ethtool eth9
Settings for eth9:
Supported ports: [ FIBRE ]
Supported link modes:  1000baseT/Full
10000baseT/Full
Supports auto-negotiation: No
Advertised link modes:  1000baseT/Full
10000baseT/Full
Advertised auto-negotiation: No
Speed: 10000Mb/s
Duplex: Full
Port: FIBRE
PHYAD: 0
Transceiver: external
Auto-negotiation: on
Supports Wake-on: umbg
Wake-on: umbg
Current message level: 0x00000007 (7)
Link detected: yes

4. 次のコマンドを使用して現行の結合インタフェースを検証します。コマンドからの出力例も示しています。

# grep -i bondeth0 ifcfg-eth*

ifcfg-eth1:MASTER=bondeth0
ifcfg-eth2:MASTER=bondeth0

5. 次のようなコマンドを使用して、1GbEインタフェース・ファイルを.Pre_10GigE_Settingsディレクトリにコピーします。

# cp -p ifcfg-eth1 ifcfg-eth2 ./.Pre_10GigE_Settings/.

6. 次のようなコマンドを使用して、10GbEインタフェース・ファイルを.Pre_10GigE_Settingsディレクトリにコピーします。

# cp -p ifcfg-eth9 ifcfg-eth15 ./.Pre_10GigE_Settings/.

7. 次のようなコマンドを使用して、ファイルを.Pre_10GigE_Settingsディレクトリから.Post_10GigE_Settingsディレクトリにコピーします。

# cp -p ./.Pre_10GigE_Settings/* ./.Post_10GigE_Settings/.

4.4.3 作業3: 10GbEインタフェース設定の編集

次の手順は、ifcfg構成ファイルの編集方法を示しています。

1. 次の表に示すように、ifcfg構成ファイルを編集します。ファイルは./Post_10GigE_Settings/.ディレクトリで編集する必要があります。

ファイル名

変更前

変更後

ifcfg-eth1

#### DO NOT REMOVE THESE LINES ####
#### %GENERATED BY CELL% ####
DEVICE=eth1
USERCTL=no
ONBOOT=yes
BOOTPROTO=none
HOTPLUG=no
IPV6INIT=no
HWADDR=00:21:28:44:d2:5e
MASTER=bondeth0
SLAVE=yes

#### DO NOT REMOVE THESE LINES ####
#### %GENERATED BY CELL% ####
DEVICE=eth1
USERCTL=no
ONBOOT=no
BOOTPROTO=none
HOTPLUG=no
IPV6INIT=no
HWADDR=00:21:28:44:d2:5e

ifcfg-eth2

#### DO NOT REMOVE THESE LINES ####
#### %GENERATED BY CELL% ####
DEVICE=eth2
USERCTL=no
ONBOOT=yes
BOOTPROTO=none
HOTPLUG=no
IPV6INIT=no
HWADDR=00:21:28:44:d2:f2
MASTER=bondeth0
SLAVE=yes

#### DO NOT REMOVE THESE LINES ####
#### %GENERATED BY CELL% ####
DEVICE=eth2
USERCTL=no
ONBOOT=no
BOOTPROTO=none
HOTPLUG=no
IPV6INIT=no
HWADDR=00:21:28:44:d2:f2

Oracle Exadata Database Machine X2-2のifcfg-eth4

Oracle Exadata Database Machine X2-8フル・ラックのifcfg-eth9

#### DO NOT REMOVE THESE LINES ####
#### %GENERATED BY CELL% ####
DEVICE=eth_interface
ONBOOT=no
BOOTPROTO=none
HOTPLUG=no
IPV6INIT=no
HWADDR=00:1b:21:66:4b:c0

前述の構文では、eth_interfaceは、Oracle Exadata Database Machine X2-2の場合はeth4で、Oracle Exadata Database Machine X2-8フル・ラックの場合はeth9です。

#### DO NOT REMOVE THESE LINES ####
#### %GENERATED BY CELL% ####
DEVICE=eth_interface
USERCTL=no
ONBOOT=yes
BOOTPROTO=none
HOTPLUG=no
IPV6INIT=no
HWADDR=00:1b:21:66:4b:c0
MASTER=bondeth0
SLAVE=yes

前述の構文では、eth_interfaceは、Oracle Exadata Database Machine X2-2の場合はeth4で、Oracle Exadata Database Machine X2-8フル・ラックの場合はeth9です。

Oracle Exadata Database Machine X2-2のifcfg-eth5

Oracle Exadata Database Machine X2-8フル・ラックのifcfg-eth15

#### DO NOT REMOVE THESE LINES ####
#### %GENERATED BY CELL% ####
DEVICE=eth_interface2
ONBOOT=no
BOOTPROTO=none
HOTPLUG=no
IPV6INIT=no
HWADDR=00:1b:21:66:4b:c1

前述の構文では、eth_interfaceは、Oracle Exadata Database Machine X2-2の場合はeth5で、Oracle Exadata Database Machine X2-8フル・ラックの場合はeth15です。

#### DO NOT REMOVE THESE LINES ####
#### %GENERATED BY CELL% ####
DEVICE=eth_interface2
USERCTL=no
ONBOOT=yes
BOOTPROTO=none
HOTPLUG=no
IPV6INIT=no
MASTER=bondeth0
SLAVE=yes
HWADDR=00:1b:21:66:4b:c1

前述の構文では、eth_interfaceは、Oracle Exadata Database Machine X2-2の場合はeth5で、Oracle Exadata Database Machine X2-8フル・ラックの場合はeth15です。

2. 次のコマンドを使用して、編集済ファイルを/etc/sysconfig/network-scriptsディレクトリにコピーします。

# cp -fp /etc/sysconfig/network-scripts/.Post_10GigE_Settings/ifcfg-eth* \
/etc/sysconfig/network-scripts/.

3. コンソールを使用して、データベース・サーバーを再起動します。

4. 起動シーケンスを監視し、bondeth0初期化中にエラーが発生しなかったことを確認します。

4.4.4 作業4: 10GbEインタフェースの検証

次の手順は、10GbEインタフェースの検証方法を示しています。

1. rootユーザーとしてログインします。

2. catコマンドを使用して、/proc/net/bonding/bondeth0ファイルを確認します。次に、コマンドとコマンドの出力例を示します。

# cat /proc/net/bonding/bondeth0

Ethernet Channel Bonding Driver: v3.4.0 (October 7, 2008)

Bonding Mode: fault-tolerance (active-backup)
Primary Slave: None
Currently Active Slave: eth9
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 5000
Down Delay (ms): 5000

Slave Interface: eth9
MII Status: up
Link Failure Count: 0
Permanent HW addr: 00:1b:21:66:4b:c0

Slave Interface: eth15
MII Status: up
Link Failure Count: 0
Permanent HW addr: 00:1b:21:66:4b:c1

出力結果で、スレーブ・インタフェースが正しく、スレーブ・インタフェースのMIIステータスがアップであることを確認します。

3. netstat -nrコマンドを使用して、ルーティング表をチェックします。ルーティング表は変更できません。このコマンドと出力例を次に示します。

# netstat -nr

Kernel IP routing table
Destination   Gateway      Genmask         Flags   MSS Window  irtt Iface
scan_subnet 0.0.0.0        255.255.255.0   U         0 0          0 bondeth0
192.168.80.0  0.0.0.0      255.255.254.0   U         0 0          0 bondib0
192.168.80.0  0.0.0.0      255.255.254.0   U         0 0          0 bondib1
192.168.80.0  0.0.0.0      255.255.254.0   U         0 0          0 bondib2
192.168.80.0  0.0.0.0      255.255.254.0   U         0 0          0 bondib3
mgmt_subnet 0.0.0.0        255.255.254.0   U         0 0          0 eth0
0.0.0.0       scan_gw      0.0.0.0         UG        0 0          0 bondeth0

4. 次のコマンドを使用して、デフォルト・ゲートウェイをチェックします。ゲートウェイはSCANネットワーク・ゲートウェイで、10GbEインタフェースでbondeth0を使用します。

# grep GATEWAY /etc/sysconfig/network
GATEWAY=gw_address
GATEWAYDEV=bondeth0

# ping -c 2 gw_address
PING gw_address (gw_address) 56(84) bytes of data.
64 bytes from gw_address: icmp_seq=1 ttl=57 time=1.12 ms
64 bytes from gw_address: icmp_seq=2 ttl=57 time=1.05 ms

--- gw_address ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 1.054/1.087/1.120/0.033 ms

前述のコマンドと出力で、gw_addressはデフォルト・ゲートウェイのIPアドレスです。

5. 「作業1: ping機能の検証」でネーム・サーバーがpingコマンドに応答していた場合は、次のコマンドを使用してネーム・サーバーをチェックします。同様のコマンドを使用して、Oracle Exadata Database Machineに接続する他のサーバーをチェックできます。

# grep "^nameserver" /etc/resolv.conf
nameserver ip_address_1
nameserver ip_address_2

# ping -c 2 ip_address_1
PING ip_address_1 (ip_address_1) 56(84) bytes of data.
64 bytes from ip_address_1: icmp_seq=1 ttl=57 time=1.12 ms
64 bytes from ip_address_1: icmp_seq=2 ttl=57 time=1.05 ms

--- ip_address_1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 1.054/1.087/1.120/0.033 ms

4.5 InfiniBandネットワークの保守

InfiniBandネットワークは、データベース・サーバーおよびExadata Storage ServerをラックのInfiniBandスイッチにBONDIB0インタフェースを介して接続します。この項では、InfiniBandスイッチの保守を実行する方法について説明します。

この項では、次の項目について説明します。

- スイッチ設定のバックアップおよびリストア

- 2.2.2へのアップグレード・プロセスで発生する可能性があるアラート

- Oracle Exadata Database Machine X3-8フル・ラックおよびOracle Exadata Database Machine X2-8フル・ラックのデータベース・サーバーのInfiniBandカード障害の修正

- 障害が発生したSun Datacenter InfiniBand Switch 36スイッチの交換

- InfiniBandネットワーク構成の確認

- InfiniBandネットワーク動作の確認

- ネットワーク・サブネット・マネージャ・マスターの理解

- InfiniBandスイッチのファームウェアのアップグレード

4.5.1 スイッチ設定のバックアップおよびリストア

スイッチ設定をバックアップおよびリストアする手順は、スイッチのファームウェアによって異なります。1.1.3-2ファームウェアには、バックアップおよびリストア機能を提供するIntegrated Lights Out Manager (ILOM)があります。1.0.1ファームウェアにILOMは含まれません。1.1.3-2ファームウェアにアップグレードして「2.1.3-4ファームウェアを使用したスイッチの設定のバックアップ」の手順を使用するか、各ファイルのバックアップおよびリストアを手動で実行します。

この項では、次の項目について説明します。

- 2.1.3-4ファームウェアを使用したスイッチの設定のバックアップ

- 1.1.3-2ファームウェアを使用したスイッチの設定のバックアップ

- 1.0.1ファームウェアを使用したスイッチの設定のバックアップ

- 2.1.3-4ファームウェアを使用したスイッチの設定のリストア

- 1.1.3-2ファームウェアを使用したスイッチの設定のリストア

- 1.0.1ファームウェアを使用したスイッチの設定のリストア

関連項目:

Oracle Integrated Lights Out Manager (ILOM)のドキュメント(http://www.oracle.com/goto/ilom/docs)

4.5.1.1 2.1.3-4ファームウェアを使用したスイッチの設定のバックアップ

次の手順は、2.1.3-4ファームウェアを使用したスイッチのバックアップ方法を示しています。スイッチを適切な設定で最初に構成した後、一度だけバックアップを実行する必要があります。

1. ブラウザのスイッチILOM URLに移動します。たとえば、http://dbm002-i1.us.example.comなどです。

2. ilom-adminユーザーとしてログインします。

3. 「メンテナンス」タブを選択します。

4. 「バックアップ/リストア」タブを選択します。

5. バックアップ操作およびブラウザ方法を選択します。

6. パスフレーズを入力します。これは、ユーザー・パスワードなどのバックアップの機密情報を暗号化するために使用されます。

7. 「実行」をクリックして、結果のXMLファイルを安全な場所に保存します。

8. rootユーザーとしてSun Datacenter InfiniBand Switch 36スイッチにログインします。

9. scpコマンドを使用して、次のファイルをコピーします。

- root SSHキー: /root/.ssh/authorized_keys

- nm2user SSHキー(存在する場合): /home/nm2user/.ssh/authorized_keys

- ホスト・ファイル: /etc/hosts

10. versionコマンドの出力を保存します。

4.5.1.2 1.1.3-2ファームウェアを使用したスイッチの設定のバックアップ

次の手順は、1.1.3-2ファームウェアを使用したスイッチのバックアップ方法を示しています。スイッチを適切な設定で最初に構成した後、一度だけバックアップを実行する必要があります。

1. ブラウザのスイッチILOM URLに移動します。たとえば、http://dbm002-i1.us.example.comなどです。

2. ilom-adminユーザーとしてログインします。

3. 「メンテナンス」タブを選択します。

4. 「バックアップ/リストア」タブを選択します。

5. バックアップ操作およびブラウザ方法を選択します。

6. パスフレーズを入力します。これは、ユーザー・パスワードなどのバックアップの機密情報を暗号化するために使用されます。

7. 「実行」をクリックして、結果のXMLファイルを安全な場所に保存します。

8. rootユーザーとしてSun Datacenter InfiniBand Switch 36スイッチにログインします。

9. scpコマンドを使用して、次のファイルをコピーします。

- ネットワーク構成: /etc/sysconfig/network-scripts/ifcfg-eth0

- DNS情報: /etc/resolv.conf

- NTP情報: /etc/ntp.conf

- タイムゾーン情報: /etc/localtime

- openSM設定: /etc/opensm/opensm.conf

- ホスト名: /etc/sysconfig/network

- root SSHキー: /root/.ssh/authorized_keys

- nm2user SSHキー(存在する場合): /home/nm2user/.ssh/authorized_keys

10. hostnameコマンドを実行して、出力を保存します。これは、ホスト名が/etc/sysconfig/networkファイルに設定されない場合に備えて実行されます。

11. rootおよびnm2userアカウントのパスワードを保存します。

12. nm2versionコマンドを実行して、出力を保存します。

4.5.1.3 1.0.1ファームウェアを使用したスイッチの設定のバックアップ

次の手順は、1.0.1ファームウェアを使用したスイッチの設定のバックアップ方法を示しています。

1. rootユーザーとしてスイッチにログインします。rootユーザーのパスワードがない場合は、Oracleサポート・サービスに連絡してください。

2. 次のファイルのコピーを作成します。

- ネットワーク構成: /etc/sysconfig/network-scripts/ifcfg-eth0

- DNS情報: /etc/resolv.conf

- NTP情報: /etc/ntp.conf

- タイムゾーン情報: /etc/localtime

- openSM設定: /etc/opensm/opensm.conf

- ホスト名: /etc/sysconfig/network

- root SSHキー: /root/.ssh/authorized_keys

- nm2user SSHキー(存在する場合): /home/nm2user/.ssh/authorized_keys

3. ホスト名が/etc/sysconfig/networkファイルに設定されない場合に備えて、hostnameコマンドを実行して出力を保存します。

4. rootおよびnm2userアカウントのパスワードを保存します。

5. nm2versionコマンドを実行して、出力を保存します。

4.5.1.4 2.1.3-4ファームウェアを使用したスイッチの設定のリストア

次の手順は、2.1.3-4ファームウェアを使用したスイッチの設定のリストア方法を示しています。

1. versionコマンドを実行して、スイッチが適切なファームウェア・レベルであることを確認します。適切ではない場合、スイッチを正しいファームウェア・レベルにアップグレードします。

2. ブラウザのスイッチILOM URLに移動します。たとえば、http://dbm002-i1.us.example.comなどです。

3. ilom-adminユーザーとしてログインします。

4. 「メンテナンス」タブを選択します。

5. 「バックアップ/リストア」タブを選択します。

6. リストア操作およびブラウザ方法を選択します。

7. 「参照」をクリックして、スイッチ構成バックアップを含むXMLファイルを選択します。

8. バックアップ中に使用されたパスフレーズを入力します。

9. 「実行」をクリックして、構成をリストアします。

10. rootユーザーとしてSun Datacenter InfiniBand Switch 36スイッチにログインします。

11. バックアップから次のファイルをリストアします。

- root SSHキー: /root/.ssh/authorized_keys

- nm2user SSHキー(存在する場合): /home/nm2user/.ssh/authorized_keys

- ホスト・ファイル: /etc/hosts

12. 次のコマンドを使用して、スイッチCLIからopenSMを再起動します。

disablesm
enablesm

13. rootユーザーとしてログインします。

14. スイッチを再起動します。

4.5.1.5 1.1.3-2ファームウェアを使用したスイッチの設定のリストア

次の手順は、1.1.3-2ファームウェアを使用したスイッチの設定のリストア方法を示しています。

1. versionコマンドを実行して、スイッチが適切なファームウェア・レベルであることを確認します。適切ではない場合、スイッチを正しいファームウェア・レベルにアップグレードします。

2. ブラウザのスイッチILOM URLに移動します。たとえば、http://dbm002-i1.us.example.comなどです。

3. ilom-adminユーザーとしてログインします。

4. 「メンテナンス」タブを選択します。

5. 「バックアップ/リストア」タブを選択します。

6. リストア操作およびブラウザ方法を選択します。

7. 「参照」をクリックして、スイッチ構成バックアップを含むXMLファイルを選択します。

8. バックアップ中に使用されたパスフレーズを入力します。

9. 「実行」をクリックして、構成をリストアします。

10. rootユーザーとしてSun Datacenter InfiniBand Switch 36スイッチにログインします。

11. バックアップから次のファイルをリストアします。

- ネットワーク構成: /etc/sysconfig/network-scripts/ifcfg-eth0

- DNS情報: /etc/resolv.conf

- NTP情報: /etc/ntp.conf

- タイムゾーン情報: /etc/localtime

- openSM設定: /etc/opensm/opensm.conf

- ホスト名: /etc/sysconfig/network

- root SSHキー: /root/.ssh/authorized_keys

- nm2user SSHキー(存在する場合): /home/nm2user/.ssh/authorized_keys

12. ホスト名が存在しない場合、次の行を/etc/sysconfig/networkファイルに追加して、ホスト名をリストアします。

HOSTNAME=switch_host_name

13. passwdコマンドを使用して、rootおよびnm2userユーザーのパスワードをリストアします。

14. 示されている順番で次のコマンドを実行して、サービスおよびopenSMを再起動します。

service network restart
service ntpd restart
disablesm
enablesm

15. rootユーザーとしてログインします。

16. スイッチを再起動します。

4.5.1.6 1.0.1ファームウェアを使用したスイッチの設定のリストア

次の手順は、1.0.1ファームウェアを使用したスイッチの設定のリストア方法を示しています。

1. rootユーザーとしてスイッチにログインします。rootユーザーのパスワードがない場合は、Oracleサポート・サービスに連絡してください。

2. スイッチが適切なファームウェア・レベルであることを確認します。適切ではない場合、スイッチを正しいファームウェア・レベルにアップグレードします。

3. バックアップから次のファイルをリストアします。

- ネットワーク構成: /etc/sysconfig/network-scripts/ifcfg-eth0

- DNS情報: /etc/resolv.conf

- NTP情報: /etc/ntp.conf

- タイムゾーン情報: /etc/localtime

- openSM設定: /etc/opensm/opensm.conf

- ホスト名: /etc/sysconfig/network

- root SSHキー: /root/.ssh/authorized_keys

- nm2user SSHキー(存在する場合): /home/nm2user/.ssh/authorized_keys

4. ホスト名が存在しない場合、HOSTNAME=switch_host_name行を/etc/sysconfig/networkファイルに追加して、ホスト名をリストアします。

5. passwdコマンドを使用して、rootおよびnm2userユーザーのパスワードをリストアします。

6. 示されている順番で次のコマンドを実行して、サービスおよびopenSMを再起動します。

service network restart
service ntpd restart
disablesm
enablesm

7. rootユーザーとしてログインします。

8. スイッチを再起動します。

4.5.2 2.2.2へのアップグレード・プロセスで発生する可能性があるアラート

2.2.2へのInfiniBandスイッチ・ファームウェアのアップグレード中に、管理サーバーで、停止状態で無効化されているInfiniBandポートに関するクリティカル・アラートが発生する場合があります。アラートは予想される動作で、迅速に(通常6分以内に)クリアされます。ユーザーによるアクションは必要ありません。

アラートの順序の例を次に示します。

27_1 2016-06-16T07:43:48-07:00 critical "InfiniBand Port HCA-1:1 may require attention. State:Down, Physical State:Disabled."

27_2 2016-06-16T07:48:40-07:00 clear "InfiniBand Port HCA-1:1 status is OK."

4.5.3 Oracle Exadata Database Machine X3-8フル・ラックおよびOracle Exadata Database Machine X2-8フル・ラックのデータベース・サーバーのInfiniBandカード障害の修正

Oracle Exadata Database Machine X3-8フル・ラックおよびOracle Exadata Database Machine X2-8フル・ラックのデータベース・サーバーのInfiniBandボンディング(BONDIB0からBONDIB3)は、4枚の各InfiniBandカードで1つのカードの両ポートを使用します。ポートで障害が発生したり、ケーブルが取り外された場合など、1枚のカードの2つのポートが無効になると、Oracle Clusterwareスタックが停止します。次の手順は、InfiniBandカードの問題を修正した後にカードを切り離してOracle Clusterwareを再起動する方法を示しています。

1. 次に示すように、障害が発生したInfiniBandカードを切り離します。

a. 次のコマンドを使用して、rootユーザーとしてOracle Clusterwareを停止します。Oracle Clusterwareがすでに停止している場合、手順1.bに移動します。

# crsctl stop crs

b. cellinit.oraファイルを編集して、影響するIPアドレスを削除します。

c. 次のコマンドを使用して、rootユーザーとしてOracle Clusterwareを起動します。

# crsctl start crs

2. InfiniBandカードの問題を修正します。

3. 次に示すように、カードを使用可能な状態に戻します。

a. 次のコマンドを使用して、rootユーザーとしてOracle Clusterwareを停止します。

# crsctl stop crs

b. IPアドレスをcellinit.oraファイルに追加します。

c. 次のコマンドを使用して、rootユーザーとしてOracle Clusterwareを起動します。

# crsctl start crs

4.5.4 障害が発生したSun Datacenter InfiniBand Switch 36スイッチの交換

この手順では、障害が発生したSun Datacenter InfiniBand Switch 36スイッチの交換方法について説明します。

1. 電源プラグを取り外して、スイッチの2つの電源を切断します。

2. スイッチからケーブルを取り外します。すべてのInfiniBandケーブルの両端に、場所を示すラベルがあります。ラベルのないケーブルが存在する場合は、ケーブルを取り外す前にラベルを付けてください。

3. ラックからスイッチを取り外します。

4. ラックに新しいスイッチを設置します。

5. 電源プラグを差し込んで、スイッチの電源を接続します。

6. 「スイッチ設定のバックアップおよびリストア」に示されているように、バックアップを使用してスイッチ設定をリストアします。

7. disablesmコマンドを使用して、サブネット・マネージャを無効化します。

8. ケーブルを新しいスイッチに接続します。各ケーブルが正しいポートに接続されていることを確認します。

9. すべてのサーバーで次のコマンドを実行します。

# /opt/oracle.SupportTools/ibdiagtools/verify-topology

前述のコマンドにより、適切な数のデータベース・サーバーが適切な数のExadata Storage Serverに接続されていることを確認します。

10. ホストで次のコマンドを実行して、ファブリックのリンクにエラーがないことを確認します。

ibdiagnet -c 5000 -r

11. enablesmコマンドを使用して、サブネット・マネージャを有効化します。

注意:

交換されたスイッチがスパイン・スイッチの場合、スパイン・スイッチがマスターになるまで他のスイッチのサブネット・マネージャを無効化して手動でマスター・サブネット・マネージャをそのスイッチまでフェイルバックして、他のすべてのスイッチのサブネット・マネージャを再有効化します。

関連項目:

- ケーブリングの詳細は、『Oracle Exadata Database Machineシステム概要』を参照してください。

- Sun Datacenter InfiniBand Switch 36ファームウェア、バージョン2.1のドキュメント(http://docs.oracle.com/cd/E36265_01/index.html)

- Sun Datacenter InfiniBand Switch 36ユーザーズ・ガイド(http://docs.oracle.com/cd/E19197-01/835-0784-05/gentextid-226.html)を参照してください

- Sun Datacenter InfiniBand Switch 36スイッチの設置の詳細は、『Oracle Exadata Database Machine拡張およびマルチラック・ケーブリング・ガイド』を参照してください。

- サブネット・マネージャ・マスターの設定の詳細は、『Oracle Exadata Database Machineインストレーションおよび構成ガイド』を参照してください

4.5.5 InfiniBandネットワーク構成の確認

この手順では、InfiniBandネットワーク構成の確認方法について説明します。

1. 適切なOpenFabrics Enterprise Distribution(OFED)ソフトウェアおよびInfiniBand HCAファームウェアのバージョンがデータベース・サーバーで使用されていることを確認します。

OFEDソフトウェアおよびInfiniBand HCAファームウェアのバージョンは、Exadataセルで自動的に保守されます。

2. データベース・サーバーまたはExadata Storage Serverから次のコマンドを使用して、InfiniBandトポロジを確認します。

# /opt/oracle.SupportTools/ibdiagtools/verify-topology

エラーが発生した場合は、Oracleサポート・サービスに問い合せてください。

関連項目:

- トポロジ検証ユーティリティの詳細は、「トポロジ検証ユーティリティの使用」を参照してください。

- 現在のリリースおよびインストールされているリリースの確認方法の手順は、Exadata Database MachineおよびExadata Storage Serverのサポートされているバージョン(My Oracle SupportのドキュメントID 888828.1)を参照してください

4.5.5.1 トポロジ検証ユーティリティの使用

Oracle Exadata Database Machineは、トポロジ検証ユーティリティを備えています。このユーティリティを使用すると、次のネットワーク接続問題を特定できます。

- 欠落しているInfiniBandケーブル

- 欠落しているInfiniBand接続

- 誤った位置に取り付けられているケーブル

- 誤ったエンドポイントに接続されているケーブル

このユーティリティは、すべてのサーバーのibdiagtoolsディレクトリにあります。トポロジ検証ユーティリティのオプションを表示するには、次のコマンドを使用します。

./verify-topology -h

[ DB Machine Infiniband Cabling Topology Verification Tool ]
Usage: ./verify-topology
[-v|--verbose]
[-r|--reuse (cached maps)]
[-m|--mapfile]
[-ibn|--ibnetdiscover (specify location of ibnetdiscover output)]
[-ibh|--ibhosts (specify location of ibhosts output)]
[-ibs|--ibswitches (specify location of ibswitches output)]
[-t|--topology [torus | fattree | halfrack] default is fattree]

verify-topologyユーティリティを使用した場合の出力例を次に示します。このエラー例では、ケーブルの接続が正しくないことが示されています。サーバーからのケーブルは、どちらも同じInfiniBandスイッチに接続されています。スイッチに障害が発生すると、サーバーからInfiniBandネットワークへの接続が失われます。

[ DB Machine Infiniband Cabling Topology Verification Tool ]

Bad link:Switch 0x21283a8371a0a0 Port 11A - Sun Port 11B
Reason : 2.5 Gbps Speed found. Could be 10 Gbps
Possible cause : Cable isn't fully seated in

Bad link:Switch 0x21283a89eba0a0 Port 11B - Sun Port 11A
Reason : 2.5 Gbps Speed found. Could be 10 Gbps
Possible cause : Cable isn't fully seated in

Is every external switch connected to every internal switch..........[SUCCESS]
Are any external switches connected to each other....................[SUCCESS]
Are any hosts connected to spine switch..............................[SUCCESS]
Check if all hosts have 2 CAs to different switches..................[ERROR]
Node trnA-db01 has 1 endpoints. (Should be 2)
Port 2 of this node is not connected to any switch

--------fattree End Point Cabling verifation failed-----

Leaf switch check: cardinality and even distribution.................[ERROR]

Internal QDR Switch 0x21283a8371a0a0 has fewer than 4 compute nodes
It has only 3 links belonging to compute nodes
Check if each rack has an valid internal ring........................[SUCCESS]

4.5.6 InfiniBandネットワーク動作の確認

サーバーのInfiniBand HCA、InfiniBandスイッチまたはInfiniBandケーブルの交換を含むInfiniBandネットワークのコンポーネントのハードウェア保守を行う場合またはInfiniBandネットワークの動作が標準以下の可能性がある場合、InfiniBandネットワークが正しく動作していることを確認します。次の手順は、ネットワーク動作の確認方法を示しています。

注意:

InfiniBandネットワークが予測を下回るパフォーマンスの場合は、常に次の手順を使用できます。

1. 「InfiniBandネットワーク構成の確認」の手順を実行します。

2. 次のように、ibdiagnetコマンドを実行して、InfiniBandネットワーク品質を確認します。

# ibdiagnet -c 1000

このコマンドで報告されるすべてのエラーが調査されます。このコマンドにより生成されるネットワーク・トラフィックは少量であるため、通常のワークロードの実行中に実行してもかまいません。

3. 次のように、ibqueryerrors.plコマンドを実行して、スイッチ・ポート・エラー・カウンタおよびポート構成情報を報告します。

#  ibqueryerrors.pl -rR -s RcvSwRelayErrors,XmtDiscards,XmtWait,VL15Dropped

前述のコマンドを使用すると、LinkDowned、RcvSwRelayErrors、XmtDiscardsおよびXmtWaitなどのエラーが無視されます。

注意:

- InfiniBandカウンタは累積的であり、過去のいずれかの時点でエラーが発生している可能性があります。エラーが報告された場合は、ibclearcountersコマンドを使用してInfiniBandカウンタをクリアすることをお薦めします。コマンドの実行後、負荷の下で数分間システムを動作させてから、ibquerryerrorsコマンドを実行してください。

- サーバーを再起動すると、SymbolErrorsまたはRcvErrorsなどのカウンタにより数値が変更される場合があります。これらのカウンタの値がLinkDownedカウンタよりも少ない場合、一般的に問題はありません。LinkDownedカウンタは、通常、再起動などの有効な理由でポートが停止した回数を表し、これ自体がエラー・インジケータとなることはありません。

- 多量で永続的なエラーならどれでも、特にSymbolErrors、LinkRecovers、RcvErrorsまたはLinkIntegrityErrorsは、ケーブルまたはポートが壊れているまたは緩んでいることを示します。

- 多量で永続的なInfiniBandネットワーク・エラー・カウンタがある場合は、問題を調査して修正してください。

4. 実行中のデータベースがないなど、InfiniBandネットワークの一部で実行されるロードがない場合は、infinicheckコマンドを実行して、完全なInfiniBandネットワーク構成、接続およびパフォーマンス評価を行います。

注意:

このコマンドは、完全なネットワークの最大スループットを評価します。InfiniBandネットワークのシステムで実行されているワークロードがある場合は実行しないでください。

このコマンドは、完全に構成されたシステムに依存します。最初のコマンドを実行して、最後のコマンドの実行中に作成されたファイルをクリアします。

# /opt/oracle.SupportTools/ibdiagtools/infinicheck -z

# /opt/oracle.SupportTools/ibdiagtools/infinicheck

次に、コマンドの出力例を示します。

Verifying User Equivalance of user=root to all hosts.
(If it isn't setup correctly, an authentication prompt will appear to push keys
to all the nodes)

Verifying User Equivalance of user=root to all cells.
(If it isn't setup correctly, an authentication prompt will appear to push keys
to all the nodes)

####  CONNECTIVITY TESTS  ####
[COMPUTE NODES -> STORAGE CELLS]
(30 seconds approx.)
[SUCCESS]..............Connectivity verified

[SUCCESS]....... All hosts can talk to all storage cells

Verifying Subnet Masks on Hosts and Cells
[SUCCESS] ......... Subnet Masks is same across the network

Checking for bad links in the fabric
[SUCCESS].......... No bad fabric links found

[COMPUTE NODES -> COMPUTE NODES]
(30 seconds approx.)
[SUCCESS]..............Connectivity verified

[SUCCESS]....... All hosts can talk to all other nodes

####  PERFORMANCE TESTS  ####

[(1) Every COMPUTE NODE to its STORAGE CELL]
(15 seconds approx.)
[SUCCESS]........ Network Bandwidth looks OK.
.......... To view only performance results run ./infinicheck -d -p

[(2) Every COMPUTE NODE to another COMPUTE NODE]
(10 seconds approx.)
[SUCCESS]........ Network Bandwidth looks OK.
...... To view only performance results run ./infinicheck -d -p

[(3) Every COMPUTE NODE to ALL STORAGE CELLS]
(45 seconds approx.) (looking for SymbolErrors)

[SUCCESS]....... No port errors found

4.5.7 ネットワーク・サブネット・マネージャ・マスターの理解

サブネット・マネージャは、InfiniBandネットワークのすべての運用上の特性を管理します。

運用上の特性は次のとおりです。

- ネットワーク・トポロジの検出

- ネットワークに接続されるすべてのポートへのローカル識別子の割当て

- スイッチ転送表の計算およびプログラム

- ファブリックの変更の監視

InfiniBandネットワークに1つ以上のサブネット・マネージャを保有できますが、アクティブにできるのは一度に1つのサブネット・マネージャのみです。アクティブなサブネット・マネージャは、マスター・サブネット・マネージャです。他のサブネット・マネージャは、スタンバイ・サブネット・マネージャです。マスター・サブネット・マネージャが停止または失敗すると、スタンバイ・サブネット・マネージャが自動的にマスター・サブネット・マネージャになります。

各サブネット・マネージャには構成可能な優先度があります。InfiniBandネットワークに複数のサブネット・マネージャがある場合は、最高優先度のサブネット・マネージャがマスター・サブネット・マネージャになります。Oracle Exadata Database Machineでは、リーフ・スイッチのサブネット・マネージャは優先度5として、スパイン・スイッチのサブネット・マネージャは優先度8として構成する必要があります。

次のガイドラインにより、Oracle Exadata Database Machineで実行されるサブネット・マネージャの場所が決定されます。

- Oracle Exadata Database Machine、Oracle Exalogic Elastic Cloud、Oracle Big Data ApplianceおよびOracle SuperClusterで使用するために指定されたInfiniBandスイッチのサブネット・マネージャのみを実行します。その他のデバイスでのサブネット・マネージャの実行はサポートされていません。

- Exadataのみの構成で、1つ、2つまたは3つのラックを配線してInfiniBandネットワークを構成している場合、すべてのスイッチでサブネット・マネージャを実行する必要があります。スパイン・スイッチでマスター・サブネット・マネージャを実行する必要があります。Oracle Exadata Database Machineクオータ・ラックのように、ネットワークにリーフ・スイッチのみが存在する場合、サブネット・マネージャ・マスターがリーフ・スイッチで実行されます。4つ以上のラックを配線してInfiniBandネットワークを構成している場合、スパイン・スイッチでのみ、サブネット・マネージャを実行する必要があります。リーフ・スイッチのサブネット・マネージャは無効化してください。

- ExadataとExalogicなどのように、異なる種類のラックを使用したマルチラック構成では、My Oracle Supportノート1682501.1を参照してください。

関連項目:

- Sun Datacenter InfiniBand Switch 36ファームウェア、バージョン2.1のドキュメント(http://docs.oracle.com/cd/E36265_01/index.html)

- サブネット・マネージャの優先度の設定の詳細は、『Oracle Exadata Database Machineインストレーションおよび構成ガイド』を参照してください。

- Exalogic/Big Data ApplianceおよびExadata/SuperClusterを含むマルチラック・ケーブリング構成でのサブネット・マネージャの設定(My Oracle SupportのドキュメントID 1682501.1)

4.5.8 InfiniBandスイッチのファームウェアのアップグレード

InfiniBandスイッチのアップグレードとダウングレードには、patchmgrユーティリティを使用します。patchmgrユーティリティを使用できる最小スイッチ・ファームウェア・リリースは1.3.3-2です。スイッチのファームウェアはローリング形式でアップグレードします。ラックにスパイン・スイッチが存在する場合は、スパイン・スイッチを最初にアップグレードします。ラックにスパイン・スイッチが存在しない場合は、サブネット・マネージャが実行されているスイッチをアップグレードします。スイッチでサブネット・マネージャが実行されていない場合は、任意の順序でアップグレードを実行できます。

ファイルを作成し、更新対象のInfiniBandスイッチを1行に1スイッチずつリストします。このファイルの例を次に示します。

# cat ibswitches.lst
myibswitch-01
myibswitch-02

InfiniBandスイッチをアップグレードするには、スイッチのファームウェアがリリース1.3.3-2以上である必要があります。スイッチのファームウェアがそれより前のリリースである場合は、My Oracle Supportノート888828.1の説明に従って、ファームウェアをリリース1.3.3-2にアップグレードする必要があります。

1. スイッチへのrootユーザーによるSSHアクセスを持つOracle Exadata Database Machineのデータベース・サーバーに、rootユーザーとしてログインします。データベース・サーバーは、スイッチと同じInfiniBandネットワークに属している必要があります。

2. データベース・サーバーに適切なパッチ・ファイルをダウンロードします。パッチ情報は、My Oracle Supportノート888828.1を参照してください。

3. パッチ・ファイルを解凍します。ファイルはpatch_release.dateディレクトリに解凍されます。

4. ファイルを作成し、更新する必要があるInfiniBandスイッチを1行に1スイッチずつリストします。このファイルの例を次に示します。

# cat ibswitches.lst
myibswitch-01
myibswitch-02

5. patch_release.dateディレクトリに移動します。

6. 次のコマンドを使用して、前提条件チェックを実行します。

# ./patchmgr -ibswitches ibswitches.lst -upgrade -ibswitch_precheck [-force] [-unkey]

注意:

- -unkeyオプションは、終了する前に、InfiniBandスイッチへのパスワードなしのSSHアクセスを削除します。

- -forceオプションを指定すると、InfiniBandトポロジの障害とサーバーからスイッチへの接続がオーバーライドされます。スイッチのアップグレードには影響しません。

コマンドの出力で全体的なステータスがSUCCESSになった場合は、アップグレードに進みます。コマンドの出力で全体的なステータスがFAILになった場合は、出力でエラーのサマリーを確認し、どのチェックが失敗したかを特定して、エラーを修正します。エラーを修正したら、前提条件チェックを再実行し、成功するまでこれを繰り返します。

7. 次のコマンドを使用して、スイッチをアップグレードします。

# ./patchmgr -ibswitches ibswitches.lst -upgrade [-force] [-unkey]

8. コマンドの出力をチェックし、アップグレードを検証します。出力はSUCCESSになる必要があります。エラーが存在する場合は、それらのエラーを修正し、アップグレード・コマンドを再実行してください。

4.5.8.1 スイッチ・ソフトウェアのダウングレード

リリース2.1.6-2へのダウングレードのみが含まれます。ファームウェアをダウングレードするには、次のコマンドを使用します。

# ./patchmgr -ibswitches ibswitches.lst -downgrade -ibswitch_precheck [-force] [-unkey]
# ./patchmgr -ibswitches ibswitches.lst -downgrade [-force] [-unkey]

4.6 InfiniBandパーティションの構成

InfiniBandパーティションの構成は、「Oracle ExadataでのOracle VM Oracle RACクラスタ間のInfiniBandパーティションの実装」で説明されています。Oracle VMを使用する場合も、使用しない場合も、InfiniBandパーティションを使用できます。

4.7 InfiniBand IPアドレスおよびホスト名の変更

既存のOracle ExadataラックのInfiniBandネットワーク情報の変更が必要になることがあります。複数のInfiniBandカードを使用してメディア・サーバーをサポートするか、同じラックの本番、テストおよびQA環境などの個別のInfiniBandネットワークのInfiniBandトラフィックを維持するため、変更が必要になる場合があります。

すべてのInfiniBandアドレスに同じサブネット内のアドレスを使用し、最小のサブネット・マスク255.255.240.0(または/20)を使用する必要があります。サブネット・マスクは、将来Oracle ExadataラックおよびInfiniBandネットワークが拡張されたときにも対応できる程度のものを選択する必要があります。

関連項目:

Oracle Exalogicシステムに接続するようにSDPリスナーを構成する方法の詳細は、Oracle Fusion Middleware Exalogic Enterprise開発ガイドを参照してください。

4.7.1 InfiniBandネットワーク情報の変更

この手順は、InfiniBandネットワーク情報の変更方法を示しています。

この項に示される手順は、次の前提条件に基づいています。

- すべての変更は、ILOMインタフェースを使用してilom-adminユーザーとして実行する必要があります。

- NET1およびNET2インタフェースを結合してBONDETH0を作成するため、クライアント・アクセス・ネットワークにチャネル・ボンディングが使用されます。チャネル・ボンディングを使用しない場合、手順のBONDETH0をNET1に置き換えてください。

- X4-2以降のハードウェアでは、リリース11.2.3.3.0より、InfiniBandボンディングに使用される名前は、BONDIB0からIB0およびIB1に変更されました。これらのインタフェースは、ifcfg-bondib0インタフェースと同じ方法で変更されます。

- リリース11.2.2.1.0の時点で、ボンディングに使用される名前が変更されました。InfiniBandボンディングにBONDIB0、イーサネット・ボンディングにBONDETH0という名前を使用します。以前のリリースでは、それぞれBOND0およびBOND1という名前でした。

- 手順には、dcliユーティリティおよびrootユーザーを使用します。これにより、データベース・サーバーのコマンドをパラレルに実行して、手順を完了する全体の時間を大幅に短縮します。

- dcliユーティリティには、SSHユーザー等価が必要になります。SSHユーザー等価が構成されない場合、一部のコマンドを各データベース・サーバーで明示的に実行する必要があります。

- データベース・グループ・ファイルdbs_groupを/rootディレクトリに格納する必要があります。

- InfiniBandネットワーク情報を変更する前に、Oracle Cluster Registry (OCR)の最新のバックアップが存在することを確認してください。OCRバックアップは、$Grid_home/cdata/cluster-nameディレクトリにあります。Grid_homeは、Oracle Grid Infrastructureソフトウェアをインストールした場所です。

- Oracle Grid Infrastructure 11gリリース2 (11.2)以上では、プライベート・ネットワーク構成がグリッド・プラグ・アンド・プレイ(gpnp)プロファイルとOCRの両方に格納されます。gpnpの定義が正しくない場合は、Oracle Clusterware CRSが起動しません。InfiniBandネットワーク情報を変更する前に、次のコマンドを使用して、すべてのノードのgpnpプロファイルのバックアップを作成してください。

$ cd $Grid_home/gpnp/hostname/profiles/peer/
$ cp -p profile.xml profile.xml.bk

1. CLUSTER_INTERCONNECTパラメータがOracle DatabaseおよびOracle ASMインスタンスで使用されているか確認します。

SQL> SELECT inst_id, name,value FROM gv$parameter WHERE name = \
'cluster_interconnects';

CLUSTER_INTERCONNECTパラメータがOCRに設定されている場合、値は返されません。CLUSTER_INTERCONNECTパラメータがサーバー・パラメータ・ファイル(SPFILE)に定義されている場合は、各インスタンスのIPアドレスが返されるため、新しいIPアドレスに変更する必要があります。

次に、Oracle ASMインスタンスのIPアドレスを変更するコマンドの例を示します。この例では、IPアドレス192.168.10.1は+ASM1インスタンスを実行するサーバーのBONDIB0に割り当てられる新しいIPアドレスとなり、192.168.10.2は+ASM2インスタンスを実行するサーバーのBONDIB0のIPアドレスとなり、それ以降も同様です。

ALTER SYSTEM SET CLUSTER_INTERCONNECTS='192.168.10.1' SCOPE=SPFILE SID='+ASM1';
ALTER SYSTEM SET CLUSTER_INTERCONNECTS='192.168.10.2' SCOPE=SPFILE SID='+ASM2';
ALTER SYSTEM SET CLUSTER_INTERCONNECTS='192.168.10.3' SCOPE=SPFILE SID='+ASM3';
...

同様のコマンドを使用して、戻された各Oracle DatabaseインスタンスのIPアドレスを変更します。

2. すべてのサーバーの新しいInfiniBandネットワーク情報の割当てを確認します。
InfiniBand IPアドレス、ネットマスク、ブロードキャストおよびネットワークIP情報を確認する必要があります。

3. oracleユーザーとして各データベース・サーバーのすべてのクラスタ管理サービスを停止します。

$ srvctl stop home -o db_home -s state_filename -n node_name

前述のコマンドのdb_homeはOracle Databaseホーム・ディレクトリの完全なディレクトリ名、state_filenameは状態ファイルを書き込む場合のパス名、node_nameはデータベース名です。このコマンドの例を次に示します。

$ srvctl stop home -o /u01/app/oracle/product/11.2.0.3/dbhome_1 -s \
/tmp/dm02db01_dbhome -n dm02db01

前述の例の/u01/app/oracle/product/11.2.0.3/dbhome_1はOracle Databaseホーム・ディレクトリ、/tmp/dm02db01_dbhomeは状態ファイル名、dm02db01はデータベース・サーバー名です。

4. 最初のデータベース・サーバーのクラスタ相互接続インタフェースを変更して、BONDIB0インタフェースを使用します。

注意:

この時点で、Oracle Clusterware、Oracle Clusterware CRSおよびOracle ASMインスタンスのみ起動しています。

a. oracleユーザーとしてログインします。

b. $ORACLE_HOMEをOracle Grid Infrastructureホームに設定します。

c. ORACLE_SID環境変数のベースを設定します。
ORACLE_HOME環境変数はOracle Grid Infrastructureのホームに設定する必要があります。

$ ORACLE_SID=+ASM1

d. 使用できるクラスタ・インタフェースをリストします。

$ oifcfg iflist

次に、出力の例を示します。

bondeth0 10.128.174.160
bondeth1 10.128.176.0
eth0 10.128.174.128
ib0 192.168.160.0
ib0 169.254.0.0
ib1 192.168.160.0
ib1 169.254.128.0

e. 現在割り当てられているクラスタ・インタフェースをリストします。

$ oifcfg getif

次に、出力の例を示します。

bondeth0 10.204.76.0 global public
ib0 192.168.16.0 global cluster_interconnect,asm
ib1 192.168.16.0 global cluster_interconnect,asm

f. グローバル・クラスタ相互接続インタフェースとしてib0とib1のインタフェースに新しいIPアドレスを割り当てます。

oifcfg setif -global ib0/192.168.8.0:cluster_interconnect
oifcfg setif -global ib1/192.168.8.0:cluster_interconnect

g. 現在のインタフェースをリストします。

$ oifcfg getif

次に、出力の例を示します。

bondeth0 10.128.174.160 global public
ib0 192.168.8.0 global cluster_interconnect
ib1 192.168.8.0 global cluster_interconnect

古いプライベート・インタフェースは後で削除します。

5. 各データベース・サーバーのOracle ClusterwareおよびOracle Clusterware CRSを停止します。

a. rootユーザーとしてログインします。

b. 次のコマンドを使用して、各データベース・サーバーのOracle Clusterware CRSを停止します。

# Grid_home/grid/bin/crsctl stop crs -f

c. 各データベース・サーバーのOracle Clusterware CRSの自動的な再起動を無効化します。

# Grid_home/grid/bin/crsctl disable crs

6. 各Exadata Storage ServerのInfiniBand IPアドレスを変更します。

a. rootユーザーとしてログインします。

b. 次のコマンドを実行します。

# cellcli -e alter cell shutdown services all
Stopping the RS, CELLSRV, and MS services...  The SHUTDOWN of services was successful.

# service ocrvottargetd stop

# ipconf

serviceコマンドのプロンプトに応答して、BONDIB0情報を変更します。次に、ipconfコマンドのプロンプトおよび応答の例を示します。変更は、基本ILOM設定のプロンプトの後に適用されます。

Logging started to /var/log/cellos/ipconf.log
Interface ib0 is Linked.  hca: mlx4_0
Interface ib1 is Linked.  hca: mlx4_0
Interface eth0 is Linked.  driver/mac: ixgbe/00:00:00:00:cd:01
Interface eth1 is ... Unlinked.  driver/mac: ixgbe/00:00:00:00:cd:02
Interface eth2 is ... Unlinked.  driver/mac: ixgbe/00:00:00:00:cd:03
Interface eth3 is ... Unlinked.  driver/mac: ixgbe/00:00:00:00:cd:04

Network interfaces
Name     State      IP address      Netmask         Gateway         Net type     Hostname
ib0      Linked
ib1      Linked
eth0     Linked
eth1     Unlinked
eth2     Unlinked
eth3     Unlinked
Warning. Some network interface(s) are disconnected. Check cables and swicthes and retry
Do you want to retry (y/n) [y]: n

The current nameserver(s): 192.0.2.10 192.0.2.12 192.0.2.13
Do you want to change it (y/n) [n]:
The current timezone: America/Los_Angeles
Do you want to change it (y/n) [n]:
The current NTP server(s): 192.0.2.06 192.0.2.12 192.0.2.13
Do you want to change it (y/n) [n]:

Network interfaces
Name     State           IP address    Netmask        Gateway       Net type            Hostname
eth0     Linked       192.0.2.151  255.255.252.0 192.0.2.15    Management   myg.example.com
eth1     Unlinked
eth2     Unlinked
eth3     Unlinked
bondib0  ib0,ib1      192.168.13.101 255.255.252.0  Private             myg-priv.example.com
Select interface name to configure or press Enter to continue: bondib0
Selected interface. bondib0
IP address or none [192.168.13.101]: 192.168.10.3
Netmask [255.255.252.0]:255.255.248.0
Fully qualified hostname or none [myg-priv.example.com]:
Continue configuring or re-configuring interfaces? (y/n) [y]: n

Select canonical hostname from the list below
1: myg.example.com
2: myg-priv.example.com
Canonical fully qualified domain name [1]:

Select default gateway interface from the list below
1: eth0
Default gateway interface [1]:

Canonical hostname: myg.example.com
Nameservers: 192.0.2.10 192.0.2.12 192.0.2.13
Timezone: America/Los_Angeles
NTP servers: 192.0.2.06 192.0.2.12 192.0.2.13
Default gateway device: eth0
Network interfaces
Name     State      IP address      Netmask         Gateway         Net type     Hostname
eth0     Linked     192.0.2.151   255.255.252.0 192.0.2.15     Management   myg.example.com
eth1     Unlinked
eth2     Unlinked
eth3     Unlinked
bondib0  ib0,ib1    192.168.10.3    255.255.248.0                   Private      myg-priv.example.com
Is this correct (y/n) [y]:

Do you want to configure basic ILOM settings (y/n) [y]: n

Starting the RS services...
Getting the state of RS services...  running

Starting MS services...
The STARTUP of MS services was successful.
A restart of all services is required to put new network configuration into
effect. MS-CELLSRV communication may be hampered until restart.
Cell myg successfully altered

Stopping the RS, CELLSRV, and MS services...
The SHUTDOWN of services was successful.
ipaddress1=192.168.10.3/21

c. Exadata Storage Serverを再起動します。

# reboot

7. セル・サービスを再起動します。

# cellcli -e alter cell restart services all

8. Exadata Storage Serverに新しく割り当てられたInfiniBandアドレスを確認します。

# cellcli -e list cell detail | grep ipaddress1

次に、出力の例を示します。

ipaddress1: 192.168.10.3/21

9. 各データベース・サーバーのInfiniBand IPアドレスを変更します。

a. rootユーザーとしてログインします。

b. /etc/sysconfig/network-scriptsディレクトリに変更します。

c. ifcfg-bondib0ファイルをコピーします。

コピーしたファイル名の先頭にifcfgを使用しないでください。

# cp ifcfg-bondib0 orig_ifcfg-bondib0

d. ifcfg-bondib0ファイルを編集して、IPADDR、NETMASK、NETWORKおよびBROADCASTフィールドを更新します。

元のifcfg-bondib0ファイルの例:

#### DO NOT REMOVE THESE LINES ####
#### %GENERATED BY CELL% ####
DEVICE=bondib0
USERCTL=no
BOOTPROTO=none
ONBOOT=yes
IPADDR=192.168.20.8
NETMASK=255.255.248.0
NETWORK=192.168.16.0
BROADCAST=192.168.23.255
BONDING_OPTS="mode=active-backup miimon=100 downdelay=5000 updelay=5000"
IPV6INIT=no
MTU=65520

更新後のifcfg-bondib0ファイルの例:

#### DO NOT REMOVE THESE LINES ####
#### %GENERATED BY CELL% ####
DEVICE=bondib0
USERCTL=no
BOOTPROTO=none
ONBOOT=yes
IPADDR=192.168.10.8
NETMASK=255.255.248.0
NETWORK=192.168.8.0
BROADCAST=192.168.15.255
BONDING_OPTS="mode=active-backup miimon=100 downdelay=5000 updelay=5000"
IPV6INIT=no
MTU=65520

注意:

データベース・サーバーのInfiniBandインタフェースのMTUサイズは、次のように設定する必要があります。

- Oracle Exadata Storage Server Softwareリリース11.2.3.3以上では、MTUサイズを7000に設定します。

- Oracle Exadata Storage Server Softwareリリース11.2.3.3より前のリリースでは、MTUサイズを65520に設定し、メディア・サーバーまたはNFSサーバーなどのInfiniBand経由のTCP/IPを使用して外部デバイスへの高速転送を実現します。

e. データベース・サーバーを再起動します。

# reboot

f. InfiniBand IPアドレス情報を確認します。

# ifconfig -a

次に、BONDIB0情報の例を示します。更新されたInfiniBandネットワーク情報が表示されます。

inet addr:192.168.10.8 Bcast:192.168.15.255 Mask:255.255.248.0

10. 各データベース・サーバーのcellinit.oraおよびcellip.oraファイルを更新します。

注意:

データベースまたはOracle ASMインスタンスを実行中は、cellinit.oraまたはcellip.oraファイルは編集しないでください。ファイルを変更するには、次のような手順を実行します。

a. 次のようにファイルのコピーを作成します。

cp cellinit.ora cellinit.new

b. テキスト・エディタでcellinit.newファイルを編集します。

c. 次のように、更新したcellinit.newファイルで古いcellinit.oraファイルを置換します。

mv cellinit.new cellinit.ora

a. rootユーザーとしてログインします。

b. /etc/oracle/cell/network-configディレクトリに変更します。

c. cellip.oraファイルのバックアップ・コピーを作成します。

このコマンドの例を次に示します。

# cp cellip.ora orig_cellip.ora

注意:

SSHユーザー等価を使用する場合、dcliユーティリティを使用できます。次に、dcliコマンドの例を示します。

# dcli -l root -g /root/dbs_group "cp cellip.ora orig_cellip.ora"

d. cellinit.oraファイルのバックアップ・コピーを作成します。

このコマンドの例を次に示します。

# cp cellinit.ora orig_cellinit.ora

注意:

SSHユーザー等価を使用する場合、dcliユーティリティを使用できます。次に、dcliコマンドの例を示します。

# dcli -l root -g /root/dbs_group "cp cellinit.ora \
orig_cellinit.ora"

e. cellip.oraファイルのInfiniBand IPアドレスを変更します。

元のファイルの例

cell="192.168.20.1"
cell="192.168.20.2"
cell="192.168.20.3"
cell="192.168.20.4"
cell="192.168.20.5"
cell="192.168.20.6"
cell="192.168.20.7"

更新されたファイルの例

cell="192.168.10.1"
cell="192.168.10.2"
cell="192.168.10.3"
cell="192.168.10.4"
cell="192.168.10.5"
cell="192.168.10.6"
cell="192.168.10.7"

注意:

SSHユーザー等価を使用する場合、dcliユーティリティを使用して、更新されたファイルを最初のデータベース・サーバーから他のデータベース・サーバーにコピーできます。次に、dcliコマンドの使用例を示します。

# dcli -l root -g /root/dbs_group -f \
/etc/oracle/cell/network-config/cellip.ora

# dcli -l root -g /root/dbs_group "mv /root/cellip.ora \
/etc/oracle/cell/network-config/"

f. cellinit.oraファイルのInfiniBand IPアドレスを変更します。

ファイルは、サブネットIDとそのサブネット・マスクで更新されます。

次に、元のファイルおよび更新されたファイルの例を示します。

元のファイルの例

ipaddress="192.168.20.8/21"

更新されたファイルの例

ipaddress="192.168.10.8/21"

各データベース・サーバーのcellinit.oraファイルを更新します。ファイルの内容は、データベース・サーバーに固有です。この手順にdcliユーティリティは使用できません。

g. 各データベース・サーバー上でALTER DBSERVERコマンドを実行して/etc/oracle/cell/network-config/cellinit.oraファイルを更新します。

次に例を示します。

# dbmcli -e alter dbserver interconnect1 = "ib0"
# dbmcli -e alter dbserver interconnect2 = "ib1"
# dbmcli -e alter dbserver interconnect3 = "ib2"
# dbmcli -e alter dbserver interconnect4 = "ib3"

11. 各データベース・サーバーおよびExadata Storage Serverの/etc/hostsファイルを更新して、新しいInfiniBand IPアドレスを使用します。

a. rootユーザーとしてログインします。

b. /etc/hostsファイルのバックアップ・コピーを作成します。

このコマンドの例を次に示します。

# cp /etc/hosts /etc/orig_hosts

c. データベース・サーバーおよびExadata Storage ServerファイルのInfiniBand IPアドレスを変更します。

12. 次のコマンドを使用して、各サーバーのrootユーザーとしてOracle Clusterwareを起動します。

# Grid_home/grid/bin/crsctl start crs

13. Oracle ASMのalert.logを確認して、各データベース・サーバーのクラスタ相互接続にRDSプロトコルが使用されていることを確認します。
ログは/u01/app/oracle/diag/asm/+asm/+ASM1/traceディレクトリにあります。最新のOracle ASMの再起動に次のようなエントリが示されます。

CELL interconnect IPC version: Oracle RDS/IP (generic)

リリース11.2.0.2以降の場合は、次のコマンドを使用してクラスタ相互接続を確認できます。コマンドは各データベース・サーバーのoracleユーザーとして実行します。

$ORACLE_HOME/bin/skgxpinfo

コマンド出力はrdsとなります。

インスタンスがInfiniBandでRDSプロトコルを使用していない場合は、次の手順を使用してOracleバイナリを再リンクします。

注意:

Oracleバイナリの再リンクにrelink allコマンドを使用しないでください。

a. oracleユーザーとして、Oracleバイナリを使用してすべてのプロセスをシャットダウンします。

b. Oracle Grid Infrastructureホームを再リンクする場合は、rootユーザーとして次のいずれかのコマンドを実行します。Oracle Grid Infrastructureホームを再リンクしない場合は、この手順は実行しないでください。

- Oracleソフトウェア・バージョンが12.2.0.1以上の場合:

# Grid_home/crs/install/rootcrs.sh -unlock

- Oracleソフトウェア・バージョンが12.1.0.1または12.1.0.2の場合:

# Grid_home/crs/install/rootcrs.pl -unlock

c. oracleユーザーとして、$ORACLE_HOME/rdbms/libディレクトリに移動します。

d. oracleユーザーとして、次のコマンドを実行します。

$ make -f ins_rdbms.mk ipc_rds ioracle

e. Oracle Grid Infrastructureホームを再リンクする場合は、rootユーザーとして次のいずれかのコマンドを実行します。Oracle Grid Infrastructureホームを再リンクしない場合は、この手順は実行しないでください。

- Oracleソフトウェア・バージョンが12.2.0.1以上の場合:

# Grid_home/crs/install/rootcrs.sh -unlock
# Grid_home/bin/crsctl start crs

- Oracleソフトウェア・バージョンが12.1.0.1または12.1.0.2の場合:

# Grid_home/crs/install/rootcrs.pl -patch

14. 次に示すように、SRVCTLユーティリティを使用して、すべてのクラスタ管理サービスを起動します。

a. oracleユーザーとしてログインします。

b. 次のコマンドを使用してデータベースを起動します。Oracle_homeはOracleホーム・ディレクトリです。

$ srvctl start home -o Oracle_home \
-s /tmp/dm02db01_dbhome -n dm02db01

c. 次のコマンドを使用して、データベース・インスタンスが実行されていることを確認します。

$ srvctl status database -d dbm

15. 次のように、Oracle ASMおよびデータベース・インスタンスで新しいネットワーク設定が使用されていることを確認します。

a. SQL*Plusを使用してOracle ASMおよびデータベース・インスタンスにログインします。

b. 次のコマンドを実行します。

SQL> SELECT inst_id, name,value FROM gv$parameter WHERE name = \
'cluster_interconnects';

16. 次のコマンドを使用して、古いプライベート・ネットワークを削除します。

$ oifcfg delif -global bondib0/192.168.16.0

17. 次のコマンドを使用して、古いインタフェースが存在しないことを確認します。

$ oifcfg getif

次に、出力の例を示します。

bondeth0  10.204.76.0  global public
bondib0   192.168.8.0  global cluster_interconnect

18. 次に示すように、各データベース・サーバーのOracle Clusterware CRSの自動的な再起動を有効化します。

a. rootユーザーとしてログインします。

b. 次のコマンドを使用して、Oracle Clusterware CRSを有効化します。

# Grid_home/grid/bin/crsctl enable crs

注意:

dcliユーティリティを使用してOracle Clusterware CRSを有効化するには、次のコマンドを使用します。

# dcli -l root -g dbs_group "Grid_home/grid/bin/crsctl \
enable crs"

19. すべてのノードでOracle Clusterwareの完全再起動を実行します。

20. My Oracle Supportノート1070954.1の手順を使用して、Oracle Exadataラックのヘルス・チェックを実行します。

注意:

Oracle ExadataラックのHealthCheckユーティリティは、Oracle Exadataラックの主要なソフトウェア、ハードウェア、ファームウェア・リリースおよび構成ベスト・プラクティスのデータを収集します。

Oracle Exadataラックの主要なコンポーネントの現在のデータを定期的に確認して、サポートされているリリース・レベルおよび推奨されているベスト・プラクティスと比較することをお薦めします。

Oracle ExadataラックのHealthCheckは、データベース、ネットワークまたはSQLパフォーマンス分析ツールではありません。連続監視ユーティリティではなく、Integrated Lights Out Manager(ILOM)またはOracle Enterprise Manager Grid Controlなどのその他のモニタリング・ツールまたはアラート・ツールとは重複しません。

21. クラスタウェア検証ユーティリティcluvfyを使用してプライベート・ネットワーク構成を検証します。

関連項目:

- ipconfコマンドの詳細は、『Oracle Exadata Storage Server Softwareユーザーズ・ガイド』を参照してください

- Server Control Utility(SRVCTL)コマンドの詳細は、Oracle Real Application Clusters管理およびデプロイメント・ガイドを参照してください。

- Oracle Exadata Database MachineのexachkまたはHealthCheck (My Oracle SupportのドキュメントID 1070954.1)

- クラスタ検証ユーティリティ(CLUVFY)のFAQ (My Oracle SupportのドキュメントID 316817.1)

4.8 データベース・サーバーでのネットワーク・ルーティングの構成

データベース・サーバーには3つの論理ネットワーク・インタフェースが構成されています。これらのインタフェースは、管理ネットワーク(eth0)、クライアント・アクセス・ネットワーク(BOND1またはBONDETH0)およびプライベートInfiniBandネットワーク(BOND0、BONDIB0またはIB0およびIB1)です。

注意:

この項の作業は、リリース11.2.3.2.1以前に構成されたデータベース・サーバーを対象にしています。

リリース11.2.2.3.0以上では、管理ネットワークへの接続の応答は管理ネットワーク・インタフェース上で送信され、クライアント・アクセス・ネットワークへの接続の応答はクライアント・アクセス・ネットワーク・インタフェース上で送信されます。プライベートInfiniBandネットワーク・トラフィックは2つのエンドポイント間での直接通信であり、ルーターは通信に関与しません。

Oracle Exadata Storage Server Softwareリリース11.2.2.3.0より前のリリースでは、管理ネットワーク上またはプライベートInfiniBandネットワーク上のIPアドレス以外を宛先としたアウトバウンド・トラフィックはデフォルト・ルートとしてクライアント・アクセス・ネットワークを使用して送信されます。この項の作業ではルーティングを変更するため、管理ネットワークに着信するトラフィックの応答は、管理ネットワークで送信されます。同様に、クライアント・ネットワークに着信するトラフィックの応答は、クライアント・ネットワークで送信されます。

ネットワーク・ルーティングの作業は、ブート時ルーティングかリアルタイム・ルーティングかによって異なります。次の点はどちらのタイプのルーティングにも当てはまります。

- これらの作業は、Oracle Exadata Storage Server Softwareリリース11.2.2.3.0より前のリリースを実行しているデータベース・サーバーを対象としています。

- これらの作業では次のサンプルIPアドレス、ネットマスクおよびゲートウェイを使用します。

- 管理ネットワークのIPアドレスは10.149.49.12、ネットマスクは255.255.252.0 (ネットワーク10.149.48.0/22)、ゲートウェイは10.149.48.1です。

- クライアント・アクセス・ネットワークのIPアドレスは10.204.78.15、ネットマスクは255.255.255.0 (ネットワーク10.204.78.0/24)、ゲートウェイは10.1.78.1です。

注意:

データベース・サーバーに他のネットワークが構成されている場合は、それらのネットワークにファイルを設定してください。

4.8.1 作業1: ブート時ルーティングのための構成

ネットワーク・ルーティングとしてブート時ルーティングを行うように構成するには、各データベース・サーバーにルールおよびルーティング・ファイルを作成する必要があります。ルールおよびルーティング・ファイルは、各データベース・サーバーの/etc/sysconfig/network-scriptsディレクトリに配置する必要があります。構成済のIPアドレスを持つ管理ネットワーク上のイーサネット・インタフェースごとに、データベース・サーバーにroute-ethnおよびrule-ethnファイルが必要です。結合イーサネット・インタフェースごとに、データベース・サーバーにroute-bondethnおよびrule-bondethnファイルが必要です。次に、ファイルの内容の例を示します。

ファイル

内容

/etc/sysconfig/network-scripts/rule-eth0

from 10.149.49.12 table 220
to 10.149.49.12 table 220

/etc/sysconfig/network-scripts/route-eth0

10.149.48.0/22 dev eth0 table 220
default via 10.149.48.1 dev eth0 table 220

/etc/sysconfig/network-scripts/rule-bondeth0

from 10.204.78.0/24 table 210
to 10.204.78.0/24 table 210

/etc/sysconfig/network-scripts/route-bondeth0

10.204.78.0/24 dev bondeth0 table 210
default via 10.204.78.1 dev bondeth0 table 210

4.8.2 作業2: リアルタイム・ルーティングのための構成

実行中のシステムでルールを構成するには、/sbin/ipコマンドを使用して、起動時に実行されるものと同じ構成を作成します。次のコマンドを使用すると、ブート時ファイルと同じ構成が得られます。

/sbin/ip rule add from 10.149.49.12 table 220
/sbin/ip rule add to 10.149.49.12 table 220
/sbin/ip route add 10.149.48.0/22 dev eth0 table 220
/sbin/ip route add default via 10.149.48.1 dev eth0 table 220

/sbin/ip rule add from 10.204.78.0/24 table 210
/sbin/ip rule add to 10.204.78.0/24 table 210
/sbin/ip route add 10.204.78.0/24 dev bondeth0 table 210
/sbin/ip route add default via 10.204.78.1 dev bondeth0 table 210

コマンドの実行後にデータベース・サーバーを再起動して、ブート時構成が正しいことを検証することをお薦めします。

4.8.3 作業3: ネットワーク・ルーティング・ルールおよびルートの検証

次のコマンドを使用して、ネットワーク・ルーティング・ルールを検証します。コマンドの出力には、システム上のすべてのルールが表示されます。

# /sbin/ip rule list
0:      from all lookup 255
32762:  from all to 10.204.78.0/24 lookup 210
32763:  from 10.204.78.0/24 lookup 210
32764:  from all to 10.149.49.12 lookup 220
32765:  from 10.149.49.12 lookup 220
32766:  from all lookup main
32767:  from all lookup default

前述の作業を行うときに2つの新しいルーティング表が作成されるため、デフォルトのルーティング表は変更されません。新しいルーティング表が使用されるのは、ルールで指定した場合のみです。次のコマンドは、デフォルトのルーティング表と新しいルーティング表をチェックする方法を示しています。

- デフォルトのルーティング表をチェックする場合。次に、コマンドと出力の例を示します。

# /sbin/ip route list
10.204.78.0/24 dev bondeth0  proto kernel  scope link  src 10.204.78.15
192.168.10.0/24 dev bondib0  proto kernel  scope link  src 192.168.10.8
10.149.48.0/22 dev eth0  proto kernel  scope link  src 10.149.49.12
default via 10.149.52.1 dev bondeth0

- 追加された表にコマンドで指定する表名が含まれているかどうかをチェックする場合。次に、コマンドと出力の例を示します。

# /sbin/ip route list table 220
10.149.48.0/22 dev eth0  scope link
default via 10.149.48.1 dev eth0
root@dbhost# ip route list table 210
10.204.78.0/24 dev bondeth0  scope link
default via 10.204.78.1 dev bondeth0

4.8.4 トラブルシューティングのためのネットワーク・ルーティング構成の削除

ネットワーク・ルーティング構成は、Oracle Exadata Database Machineを構成またはトライブシューティングするときに削除できます。ルールおよびルートを削除するには、次のコマンドを使用します。

/sbin/ip route del default via 10.149.48.1 dev eth0 table 220
/sbin/ip route del 10.149.48.0/22 dev eth0 table 220
/sbin/ip rule del to 10.149.49.12 table 220
/sbin/ip rule del from 10.149.49.12 table 220

/sbin/ip route del default via 10.204.78.1 dev bondeth0 table 210
/sbin/ip route del 10.204.78.0/24 dev bondeth0 table 210
/sbin/ip rule del to 10.204.78.0/24 table 210
/sbin/ip rule del from 10.204.78.0/24 table 210

4.8.5 デフォルトのルーティングへの再設定

デフォルトのネットワーク・ルーティングに戻すには、追加ファイルを/etc/sysconfig/network-scriptsディレクトリから削除し、サーバーを再起動します。次に、ファイルを削除してサーバーを再起動するコマンドの例を示します。

/bin/rm -f /etc/sysconfig/network-scripts/rule-eth0
/bin/rm -f /etc/sysconfig/network-scripts/route-eth0
/bin/rm -f /etc/sysconfig/network-scripts/rule-bondeth0
/bin/rm -f /etc/sysconfig/network-scripts/route-bondeth0
reboot

4.9 DNSサーバーの変更

ドメイン・ネーム・システム(DNS)サーバーの構成設定は、初期設定後に変更できます。Oracle Exadata Database Machineのすべてのサーバーおよびスイッチは、同じDNSサーバーを参照する必要があります。Oracle Exadata Database Machineが参照するすべてのドメインは、個々のDNSサーバーを介して解決される必要があります。この項では、Oracle Exadata Database Machineサーバーおよびスイッチを同じDNSサーバーに設定する作業および手順について説明します。各サーバーは1つずつ変更することをお薦めします。

- 作業1: Sun Datacenter InfiniBand Switch 36スイッチでのDNSサーバー・アドレスの変更

- 作業2: Ciscoイーサネット・スイッチでのDNSサーバー・アドレスの変更

- 作業3: データベース・サーバーでのDNSサーバー・アドレスの変更

- 作業4: Exadata Storage ServerでのDNSサーバーの変更

- 作業5: KVMスイッチでのDNSサーバーの変更

4.9.1 作業1: Sun Datacenter InfiniBand Switch 36スイッチでのDNSサーバー・アドレスの変更

すべての構成手順は、ILOMインタフェースを使用してilom-adminユーザーとして実行する必要があります。ファームウェア・リリースに応じて、次のいずれかの手順を実行してDNSサーバーを変更します。

- 2.0.4より前のファームウェア:

1. rootユーザーとしてSun Datacenter InfiniBand Switch 36スイッチにログインします。

2. viなどのエディタを使用して/etc/resolv.confファイルを編集し、DNSサーバーおよびドメイン名を設定します。各DNSサーバーに行があります。

3. ファイルを保存します。

- 2.0.4以降のファームウェア:

1. ilom-adminユーザーとしてログインします。

2. 次のいずれかのオプションを使用して、DNSアドレスを設定します。

- ILOM Webインタフェースを使用する場合:
「構成」タブをクリックして、DNSサーバー・アドレスを設定します。

- コマンドライン・インタフェースを使用する場合は、次のコマンドを使用してDNSサーバーを設定します。

set /SP/clients/dns nameserver=dns_ip

前述のコマンドで、dns_ipはDNSサーバーのIPアドレスです。DNSサーバーが複数ある場合は、set /SP/clients/dns nameserver=dns_ip1,dns_ip2,dns_ip3などのカンマ区切りのリストを入力します。

4.9.2 作業2: Ciscoイーサネット・スイッチでのDNSサーバー・アドレスの変更

次の手順では、Ciscoイーサネット・スイッチでDNSサーバー・アドレスを変更する方法について説明します。

1. ファームウェア・リリースに基づいて、次のいずれかの方法を使用してスイッチにアクセスします。

- リリース12.2より前のファームウェア:
Telnetを使用してスイッチにアクセスし、管理パスワードを使用して管理者としてログインします。

- リリース12.2以降のファームウェア:
SSHを使用してスイッチにアクセスし、管理者のパスワードを使用してadminユーザーとしてログインします。

注意:

SSHが構成されていない場合は、Telnetを使用して、adminユーザーとしてスイッチにアクセスします。

2. 次のコマンドを使用して、enableモードに変更します。パスワードを要求されたら、監理者のパスワードを使用します。

Switch> enable

3. 次のコマンドを使用して、現在の構成を確認します。

Switch# show running-config

4. 次のコマンドを使用して、現在のDNSサーバーの情報を消去します。

Switch# configure terminal
Enter configuration commands,one per line.End with CNTL/Z.
Switch(config)# no ip name-server 10.7.7.2
Switch(config)# no ip name-server 129.148.5.4
Switch(config)# no ip name-server 10.8.160.2
Switch(config)# end
Switch# write memory
Building configuration...
Compressed configuration from 2603 bytes to 1158 bytes [OK ]

注意:

変更する現在の各DNS IPアドレスは消去する必要があります。無効なIPアドレスも消去する必要があります。

5. 最大3つのDNSサーバーを構成します。次に、例を示します。

Switch# configure terminal
Enter configuration commands,one per line.End with CNTL/Z.
Switch(config)# ip name-server 10.7.7.3
Switch(config)# ip name-server 129.148.5.5
Switch(config)# ip name-server 10.8.160.1
Switch(config)# write memory
Building configuration...
Compressed configuration from 2603 bytes to 1158 bytes [OK ]

6. 次のコマンドを実行して出力を確認し、変更を検証します。

Switch# show running-config

次に、コマンドの出力例を示します。

Building configuration...
...
ip domain-name example.com
ip name-server 192.168.10.2
ip name-server 192.168.10.3
ip name-server 192.168.10.4
...

7. 次のコマンドを使用して、構成を保存します。

Switch# copy running-config startup-config
Destination filename [startup-config]?
Building configuration...
Compressed configuration from 14343 bytes to 3986 bytes[OK]

8. 次のコマンドを使用して、セッションを終了します。

Switch# exit

4.9.3 作業3: データベース・サーバーでのDNSサーバー・アドレスの変更

次の手順では、データベース・サーバーでDNSサーバー・アドレスを変更する方法について説明します。

1. rootユーザーとしてログインします。

2. viなどのエディタを使用して/etc/resolv.confファイルを編集し、DNSサーバーおよびドメイン名を設定します。各DNSサーバーにネーム・サーバー行があります。次に、更新されたファイルの例を示します。

search        example.com
nameserver    10.7.7.3

3. データベース・サーバーで次のコマンドを使用して、サーバーILOMのDNSサーバーを設定します。

ipmitool sunoem cli 'set /SP/clients/dns nameserver=dns_ip'

前述のコマンドで、dns_ipはDNSサーバーのIPアドレスです。DNSサーバーが複数ある場合は、set /SP/clients/dns nameserver=dns_ip1,dns_ip2,dns_ip3などのカンマ区切りのリストを入力します。

4. データベース・サーバーごとに、この手順を繰り返します。

4.9.4 作業4: Exadata Storage ServerでのDNSサーバーの変更

この手順では、Exadata Storage ServerでDNSサーバーを変更する方法について説明します。

注意:

この手順では、NTPも設定できます。

1. rootユーザーとしてログインします。

2. ディスクを修復しオンラインに戻す時間の間隔を指定します。
デフォルトのDISK_REPAIR_TIME属性値、3.6時間は、ほとんどの環境で十分な長さです。

a. マウントされたすべてのディスク・グループの修復時間を確認します。

Oracle ASMインスタンスにログインし、次の問合せを実行します。

SQL> select dg.name,a.value from v$asm_diskgroup dg, v$asm_attribute \
a where dg.group_number=a.group_number anda.name='disk_repair_time';

b. 必要に応じてパラメータを調整します。

次のコマンドで、h.nは、たとえば4.6などの時間を表す値(時間単位)です。

SQL> ALTER DISKGROUP DATA SET ATTRIBUTE 'DISK_REPAIR_TIME'='h.nH';

3. グリッド・ディスクをオフラインにした場合、Oracle ASMに問題が発生しないか確認します。

cellcli -e list griddisk attributes name,asmmodestatus,asmdeactivationoutcome

グリッド・ディスクでYesが戻ります。Yes値が戻らないディスクが1つでもある場合、ディスク・グループのデータ冗長性をリストアして、すべてのディスク・グループでYes値が戻るまでコマンドを繰り返します。

4. セル上のすべてのグリッド・ディスクを無効化します。

# cellcli -e alter griddisk all inactive

このコマンドは、終了するまで10分以上かかります。グリッド・ディスクを非アクティブ化すると、Oracle ASMインスタンスで自動的にディスクがofflineに設定されます。

5. グリッド・ディスクがオフラインであることを確認します。

a. グリッド・ディスクのステータスをチェックします。

# cellcli -e list griddisk attributes name, asmmodestatus,    \
asmdeactivationoutcome

出力には、asmmodestatus=OFFLINEまたはasmmodestatus=UNUSEDが表示され、asmdeactivationoutcome=Yesがすべてのグリッド・ディスクに表示されます。

b. グリッド・ディスクの一覧を表示し、オフラインであることを確認します。

# cellcli -e list griddisk

6. セル・サービスおよびocrvottargetdサービスを停止します。

# cellcli -e alter cell shutdown services all
# service ocrvottargetd stop

注意:

一部のリリースには、ocrvottargetdサービスは含まれません。

7. ipconfユーティリティを使用して、DNS設定を変更します。

# /usr/local/bin/ipconf

8. セル・サービスおよびocrvottargetdサービスを再起動します。

# service ocrvottargetd start
# cellcli -e alter cell startup services all

サーバーを再起動する必要はありません。

9. セルがオンラインになったらグリッド・ディスクをアクティブ化します。

# cellcli -e alter griddisk all active

10. ディスクがアクティブであることを確認します。

# cellcli -e list griddisk

出力には、activeと表示されます。

11. グリッド・ディスク・ステータスを確認します。

a. すべてのグリッド・ディスクがオンラインであることを確認します。

# cellcli -e list griddisk attributes name, asmmodestatus

b. Oracle ASM同期化が、すべてのグリッド・ディスクで完了するまで待機します。

すべてのディスクは、最初にSYNCING状態になり、次にONLINE状態になります。

次に、出力の例を示します。

DATA_CD_00_dm01cel01 ONLINE
DATA_CD_01_dm01cel01 SYNCING
DATA_CD_02_dm01cel01 OFFLINE
DATA_CD_03_dm01cel01 OFFLINE
DATA_CD_04_dm01cel01 OFFLINE
DATA_CD_05_dm01cel01 OFFLINE
DATA_CD_06_dm01cel01 OFFLINE
DATA_CD_07_dm01cel01 OFFLINE
DATA_CD_08_dm01cel01 OFFLINE
DATA_CD_09_dm01cel01 OFFLINE
DATA_CD_10_dm01cel01 OFFLINE
DATA_CD_11_dm01cel01 OFFLINE

すべてのグリッド・ディスクがasmmodestatus=ONLINEを示す場合のみ、Oracle ASMの同期化が完了します。

12. Exadata Storage Serverごとに、この手順を繰り返します。

4.9.5 作業5: KVMスイッチでのDNSサーバーの変更

次の手順では、KVMスイッチを使用してDNSサーバー構成を変更する方法について説明します。

注意:

- KVMスイッチが用意されているのは、Oracle Exadata Database Machine X2-2ラック、およびSun Fire X4270 M2 Serverを使用したExadata Storage Serverを搭載したOracle Exadata Storage拡張ラックのみです。

- KVMスイッチはNTPをサポートしていません。

1. KVMスイッチにログインします。インターネットでホスト名またはIPアドレスを使用すると、KVMに直接ログインしたり。スイッチにアクセスできます。

2. ユニット・ビューから「アプライアンス」を選択します。

3. アプライアンス設定から「DNS」を選択します。

4. DNS構成を選択します。

5. DNS構成を入力します。次の構成オプションを利用できます。

- DNSモード(手動、DHCP、DHCPv6)

- DNSサーバー・アドレス(1次、2次、3次)

6. 「保存」をクリックします。

4.10 NTPサーバーの変更

ネットワーク・タイム・プロトコル(NTP)サーバーの構成設定は、初期設定後に変更できます。

サーバーが同じ時刻に同期されるように、Oracle Exadata Database Machineのすべてのサーバーおよびスイッチは、同じNTPサーバーを参照する必要があります。この項では、Oracle Exadata Database Machineサーバーおよびスイッチを同じNTPサーバーに設定する作業および手順について説明します。各サーバーは1つずつ変更することをお薦めします。

- 作業1: データベース・サーバーでのNTPサーバー・アドレスの設定

- 作業2: Sun Datacenter InfiniBand Switch 36スイッチでのNTPサーバー・アドレスの設定

- 作業3: Ciscoイーサネット・スイッチでのNTPサーバー・アドレスの設定

- 作業4: Exadata Storage ServerでのNTPサーバーの設定

注意:

- これらの手順では、2つのNTPサーバー間の時間差が大きくないと仮定しています。使用

- Oracle Exadata Database Machineで使用するために構成可能なNTPサーバーは最大2台です。

4.10.1 作業1: データベース・サーバーでのNTPサーバー・アドレスの設定

Oracle Exadata Database Machineのデータベース・サーバーでNetwork Time Protocol (NTP)サーバー・アドレスを設定または変更できます。

1. データベース・サーバーのNTPサービスを停止します。

# service ntpd stop

2. 新しいNTPサーバーのIPアドレスでntp.confファイルを更新します。

3. データベース・サーバー上でNTPサービスを開始します。

# service ntpd start

4. 各データベース・サーバーに対して、手順1から3を繰り返します。

4.10.2 作業2: Sun Datacenter InfiniBand Switch 36スイッチでのNTPサーバー・アドレスの設定

Sun Datacenter InfiniBand Switch 36スイッチでNetwork Time Protocol (NTP)サーバー・アドレスを設定または変更できます。

注意:

InfiniBandスイッチのファイルは手動で編集しないでください。

1. ilom-adminユーザーとしてログインします。

2. 次のいずれかの方法を使用して日付、タイムゾーンおよびNTPサーバーを設定します。

- ILOMグラフィカル・インタフェースの「構成」ページを使用:

- 手動で次のコマンドを使用:

set /SP/clock timezone=preferred_tz
set /SP/clients/ntp/server/1 address=ntp_ip1
set /SP/clients/ntp/server/2 address=ntp_ip2
set /SP/clock usentpserver=enabled

前述のコマンドで、preferred_tzは優先されるタイムゾーン、ntp_ip1およびntp_ip2はNTPサーバーのIPアドレスです。両方のNTPサーバーを構成する必要はありませんが、少なくとも1つを構成する必要があります。

4.10.3 作業3: Ciscoイーサネット・スイッチでのNTPサーバー・アドレスの設定

Ciscoイーサネット・スイッチでNetwork Time Protocol (NTP)サーバー・アドレスを設定または変更できます。

1. ファームウェア・バージョンに基づいて、次のいずれかの方法を使用してスイッチにアクセスします。

a. バージョン12.2より前のファームウェア・バージョン: Telnetを使用してスイッチにアクセスし、管理パスワードを使用して管理者としてログインします。

b. バージョン12.2以降のファームウェア: SSHを使用してスイッチにアクセスし、管理パスワードを使用してadminユーザーとしてログインします。

注意:

SSHが構成されていない場合は、Telnetを使用して、adminユーザーとしてスイッチにアクセスします。

2. enableモードに変更します。パスワードを要求されたら、監理者のパスワードを使用します。

Switch> enable

3. 現在の構成を確認します。

Switch# show running-config

4. 現在のNTPサーバー構成を消去します。

この例では、現在のIPアドレスは10.10.10.1および10.8.8.1です。

Switch# configure terminal
Enter configuration commands,one per line.End with CNTL/Z.
Switch(config)# no ntp server 10.10.10.1
Switch(config)# no ntp server 10.8.8.1
Switch(config)# end
Switch# write memory
Building configuration...
Compressed configuration from 2603 bytes to 1158 bytes [OK ]

注意:

変更対象の現在の各NTP IPアドレスは消去する必要があります。無効なIPアドレスも消去する必要があります。

5. 最大2台のNTPサーバーを構成します。

Switch# configure terminal
Enter configuration commands,one per line.End with CNTL/Z.
Switch(config)# ntp server 10.7.7.1 prefer
Switch(config)# ntp server 10.9.9.1
Switch(config)# end
Switch# write memory
Building configuration...
Compressed configuration from 2603 bytes to 1158 bytes [OK ]

6. 変更を確認します。

Switch# show running-config

次に、コマンドの出力例を示します。

Building configuration...
...
ntp server 192.168.10.10 prefer
...

7. 構成を保存します。

Switch# copy running-config startup-config
Destination filename [startup-config]?
Building configuration...
Compressed configuration from 14343 bytes to 3986 bytes[OK]

8. セッションを終了します。

Switch# exit

4.10.4 作業4: Exadata Storage ServerでのNTPサーバーの設定

Exadata Storage ServerでNetwork Time Protocol (NTP)サーバー・アドレスを設定または変更できます。

注意:

この手順では、DNSも設定できます。

警告:

グリッド・ディスクをオフラインにしてもOracle ASMの操作に影響しないようにする手順を完了していない場合は、データベースが停止することがあります。

1. rootユーザーとしてセルにログインします。

2. ディスクを修復してオンラインに戻すまでの時間を調べ、必要であれば新しい値を指定します。

デフォルトのDISK_REPAIR_TIME属性値、3.6時間は、ほとんどの環境で十分な長さです。

a. Oracle ASMインスタンスにログインして次の問合せを実行し、マウントされたすべてのディスク・グループの修復時間を確認します。

SQL> SELECT dg.name,a.value FROM v$asm_diskgroup dg, v$asm_attribute a \
WHERE dg.group_number=a.group_number AND a.name='disk_repair_time';

b. デフォルト以外の値が指定されているとき、現在の設定ではNTPサーバーの変更を実装するために十分な時間が得られない場合は、次のようなコマンドを発行してパラメータを調整します。

SQL> ALTER DISKGROUP DATA SET ATTRIBUTE 'DISK_REPAIR_TIME'='3.6H';

h.nHの形式で時間を指定します。h.nは時間単位での長さです(4.6のように指定します)。

3. グリッド・ディスクをオフラインにした場合、Oracle ASMに問題が発生しないか確認します。

cellcli -e list griddisk attributes name,asmmodestatus,asmdeactivationoutcome

asmdeactivationoutcome値はグリッド・ディスクではYesにする必要があります。Yes値が戻らないディスクが1つでもある場合、ディスク・グループのデータ冗長性をリストアして、すべてのグリッド・ディスクでYes値が戻るまでコマンドを繰り返します。

4. セル上のすべてのグリッド・ディスクを無効化します。

# cellcli -e alter griddisk all inactive

このコマンドは、終了するまで10分以上かかります。グリッド・ディスクを非アクティブ化すると、Oracle ASMインスタンスで自動的にディスクがofflineに設定されます。

5. グリッド・ディスクがオフラインであることを確認します。

a. グリッド・ディスクのステータスをチェックします。

# cellcli -e list griddisk attributes name, asmmodestatus,  \
asmdeactivationoutcome

出力には、asmmodestatus=OFFLINEまたはasmmodestatus=UNUSEDが表示され、asmdeactivationoutcome=Yesがすべてのグリッド・ディスクに表示されます。

b. グリッド・ディスクの一覧を表示し、オフラインであることを確認します。

# cellcli -e list griddisk

6. セル・サービスおよびocrvottargetdサービスを停止します。

# cellcli -e alter cell shutdown services all
# service ocrvottargetd stop

注意:

一部のリリースには、ocrvottargetdサービスは含まれません。

7. ipconfユーティリティを使用して、NTP設定を変更します。

# /usr/local/bin/ipconf

8. セル・サービスを再起動します。サーバーを再起動する必要はありません。

# service ocrvottargetd start
# cellcli -e alter cell startup services all

9. セル・サービスがオンラインになったらグリッド・ディスクをアクティブ化します。

# cellcli -e alter griddisk all active

10. ディスクがアクティブであることを確認します。

# cellcli -e list griddisk

出力には、activeと表示されます。

11. グリッド・ディスクがオンラインであることを確認します。

# cellcli -e list griddisk attributes name, asmmodestatus

次に、出力の例を示します。

DATA_CD_00_dm01cel01 ONLINE
DATA_CD_01_dm01cel01 SYNCING
DATA_CD_02_dm01cel01 OFFLINE
DATA_CD_03_dm01cel01 OFFLINE
DATA_CD_04_dm01cel01 OFFLINE
DATA_CD_05_dm01cel01 OFFLINE
DATA_CD_06_dm01cel01 OFFLINE
DATA_CD_07_dm01cel01 OFFLINE
DATA_CD_08_dm01cel01 OFFLINE
DATA_CD_09_dm01cel01 OFFLINE
DATA_CD_10_dm01cel01 OFFLINE
DATA_CD_11_dm01cel01 OFFLINE

すべてのディスクは、最初にSYNCING状態になり、次にONLINE状態になります。Oracle ASM同期化が、すべてのグリッド・ディスクで完了するまで待機します。

Oracle ASM同期化が完了すると、すべてのグリッド・ディスクで値ONLINEがasmmodestatusに表示されます。

12. Exadata Storage Serverセルごとに、この手順を繰り返します。

関連トピック

- 作業4: Exadata Storage ServerでのDNSサーバーの変更

4.11 タイムゾーン設定の変更

初期構成およびデプロイメントの終了後にOracle Exadata Database Machineでタイムゾーンを変更できます。

タイムゾーン設定を変更する場合は、次のコンポーネントを変更する必要があります。

- Exadata Storage Server

- データベース・サーバー

- InfiniBandスイッチ

- Ciscoイーサネット・スイッチ

注意:

タイムゾーン設定を変更する前に、セル・サービスとOracle Clusterwareサービスを停止する必要があります。

次の作業では、コンポーネントでタイムゾーン設定を変更する方法について説明します。

- 作業1: Exadata Storage Serverでのタイムゾーン設定の変更

- 作業2: データベース・サーバーでのタイムゾーン設定の変更

- 作業3: InfiniBandスイッチでのタイムゾーン設定の変更

- 作業4: Ciscoスイッチでのタイムゾーン設定の変更

4.11.1 作業1: Exadata Storage Serverでのタイムゾーン設定の変更

次の手順では、Exadata Storage Serverでタイムゾーン設定を変更する方法について説明します。すべてのストレージ・サーバーに対する設定変更を完了してから、データベース・サーバーの設定を変更してください。

1. 計算ノードでrootユーザーとしてログインします。

2. すべての計算ノード上のOracle Clusterwareスタックを停止します。

次のようなコマンドを使用します(Grid_homeはOracle Grid Infrastructureソフトウェアをインストールした場所)。

# Grid_home/bin/crsctl stop crs

3. ストレージ・サーバーにrootユーザーとしてログインします。

4. 次のコマンドを使用して、セルのプロセスを停止します。

# cellcli -e alter cell shutdown services all

5. 次のコマンドを使用して、ipconfスクリプトを実行します。

# /opt/oracle.cellos/ipconf

a. タイムゾーン・プロンプトが表示されるまで、スクリプト・プロンプトに従います。その他の設定は変更しないでください。

国は番号で指定します。国を指定すると、その国の中の複数のタイムゾーンに対応する別の番号のセットが表示されます。次に、タイムゾーンを南極大陸から米国に変更する場合のタイムゾーン・プロンプトの例を示します。米国の番号は230です。

The current timezone: Antarctica/McMurdo
Do you want to change it (y/n) [n]: y

Setting up local time...

1) Andorra
2) United Arab Emirates
3) Afghanistan
.
.
.
15) Aruba
16) Aaland Islands
Select country by number, [n]ext, [l]ast: 230

Selected country: United States (US). Now choose a zone

1) America/New_York
2) America/Detroit
3) America/Kentucky/Louisville
.
.
.
15) America/North_Dakota/New_Salem
16) America/Denver
Select zone by number, [n]ext: 1

Selected timezone: America/New_York
Is this correct (y/n) [y]:

b. 残りのスクリプト・プロンプトに従いますが、他の値は変更しないでください。ILOMの設定は変更しないでください。

スクリプトは、変更の要求すべてに対応した後で、新しいファイルを生成します。

Info. Run /opt/oracle.cellos/validations/init.d/saveconfig
/opt/oracle.cellos/validations/init.d/saveconfig started at 2017_05_12_10_28
Copy cell configs from /opt/oracle/cell/cellsrv/deploy/config to /opt/oracle.cellos/iso/lastGoodConfig/cell/cellsrv/deploy/config
[INFO] Copying ssh host settings from //etc/ssh to /opt/oracle.cellos/iso/lastGoodConfig/etc/ssh ...
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)

6. タイムゾーンの変更が次のファイルに反映されていることを確認します。これらのファイルの変更を例を示します。

- /opt/oracle.cellos/cell.conf:

$VAR1 = {
'Hostname' => 'xdserver.example.com',
'Ntp servers' => [
'10.141.138.1'
],
'Timezone' => 'America/New_York',

- /etc/sysconfig/clock:

ZONE="America/New_York"
UTC=false
ARC=false
#ZONE="Antarctica/McMurdo"
#ZONE="America/New_York"
#ZONE="America/Los_Angeles"

コメント化されていないZONE値(行の先頭に#が付いていない値)が現在の設定です。

- /etc/localtime:
strings /etc/localtimeコマンドを実行して変更を検証します。最後の行がタイムゾーンを示しています。

~^Ip
EST5EDT,M3.2.0,M11.1.0

7. ストレージ・サーバーを再起動します。

8. dateコマンドを使用して、現在のタイムゾーンを表示します。次に、コマンドの出力例を示します。

# date
Tue Jan 29 12:44:21 EDT 2017

9. $ADR_BASE/diag/asm/cell/host_name/alert.logファイルを確認します。プロセスが再起動された時刻が現在の正しい時刻と一致する必要があります。

10. 各セルで手順3から9を繰り返します。

4.11.2 作業2: データベース・サーバーでのタイムゾーン設定の変更

ストレージ・セルでタイムゾーンの設定を変更したら、データベース・サーバーでタイムゾーンの設定を変更できます。

この手順を開始する前に、「タスク1: Exadata Storage Serverでのタイムゾーン設定の変更」の説明に従って、Oracle Clusterwareスタックを停止して、ストレージ・セルでタイムゾーンを変更しておく必要があります。

1. rootユーザーとして、いずれかのストレージ・セルからファイル/etc/localtimeをデータベース・サーバーにコピーします。

# scp root@cell_name:/etc/localtime /etc/localtime

2. いずれかのストレージ・セルからファイル/etc/sysconfig/clockをデータベース・サーバーにコピーします。

# scp root@cell_name:/etc/sysconfig/clock /etc/sysconfig/clock

3. Oracle Clusterwareの設定を変更して、データベース・サーバーの再起動後にCRSスタックが自動的に起動しないようにします。

# Grid_home/bin/crsctl disable crs

4. データベース・サーバーを再起動します。

5. データベース・サーバー上で日付が変更されていることを確認します。

dateコマンドを使用して、タイムゾーンの変更を検証します。

# date
Tue Jan 29 13:08:46 EDT 2017

6. Oracle Clusterwareの設定を変更して、データベース・サーバーの再起動後にCRSスタックを自動的に再起動するようにします。

# Grid_home/bin/crsctl enable crs

7. データベース・サーバー上でCRSスタックを起動します。

# Grid_home/bin/crsctl start crs

4.11.3 作業3: InfiniBandスイッチでのタイムゾーン設定の変更

Sun Datacenter InfiniBand Switch 36スイッチでタイムゾーンの設定を変更できます。

1. ilom-adminユーザーとしてSSHを使用してInfiniBandスイッチに接続します。

ssh -l ilom-admin switch_hostname

2. versionコマンドを使用して、スイッチ・ソフトウェアのバージョンをチェックします。

次に、コマンドの出力例を示します。

$ version
SUN DCS 36p version: 2.2.2-7
Build time: Aug 26 2016 10:00:25
SP board info:
Manufacturing Date: 2012.06.23
Serial Number: "ABCDE1234"
Hardware Revision: 0x0007
Firmware Revision: 0x0000
BIOS version: SUN0R100
BIOS date: 06/22/2010

3. ソフトウェアのバージョンに応じて、次のようにスイッチを管理します。

- ソフトウェアのバージョンが1.1.3-2以上である場合は、次のようにILOMを使用してスイッチを管理します。

a. Webアドレスhttp://switch_aliasを使用して、ILOMにログインします。

b. 「構成」タブを選択します。左側のナビゲーションで、「ILOM管理」を選択してから、「日付と時間」を選択します。

c. クロック・タブを選択します。

d. NTPを使用して時間を同期の横の「有効」チェック・ボックスをクリックします。

e. 「サーバー1」テキスト・ボックスに、プライマリNTPサーバーの正しいIPアドレスを入力します。

f. 「サーバー2」テキスト・ボックスに、使用するセカンダリNTPサーバーのIPアドレスを入力します。

g. 「保存」をクリックします。

- ソフトウェアのバージョンが1.1.3-2より前である場合は、次のようにSSHを使用してスイッチにログインします。

a. 次のコマンドを使用して、スイッチにログインします。

#ssh -l root {switch_ip | switch_name}

b. 次のコマンドを使用して、ntpdデーモンを停止します。

# service ntpd stop

c. 次のコマンドを使用して、/etc/localtimeファイルのコピーを保存します。

# cp /etc/localtime /etc/localtime.backup

d. /usr/share/zoneinfoディレクトリでタイムゾーンのファイルを特定します。次に、米国の例を示します。

#cd /usr/share/zoneinfo/US
#ls
Alaska  Aleutian  Arizona  Central  Eastern  East-Indiana  Hawaii
Indiana-Starke  Michigan  Mountain  Pacific  Samoa

e. 該当するファイルを/etc/localtimeディレクトリにコピーします。このコマンドの例を次に示します。

# cp /usr/share/zoneinfo/US/Eastern /etc/localtime

f. 現在の日時として現在の時刻に近い値を手動で設定します。

g. dateコマンドでMMddHHmmCCyy形式(月、日、時間、分、世紀、年)を指定して、新しいタイムゾーン用に時刻をNTPサーバーと同期します。このコマンドの例を次に示します。

# date 013110452013
# ntpd -q -g

h. 次のコマンドを使用して、日付を検証します。

# date

i. 次のコマンドを使用して、nptdデーモンを再起動します。

# service ntpd start

4.11.4 作業4: Ciscoスイッチでのタイムゾーン設定の変更

Ciscoスイッチでタイムゾーン設定を変更できます。

1. Telnetを使用してCiscoスイッチに接続します。

2. enableコマンドを使用して、特権モードを開始します。

3. configure terminalコマンドを使用して、構成を開始します。

4. 次のコマンドを使用して、クロックを設定します。

a. タイムゾーンを変更する手順は、次のとおりです。

clock timezone zone hours_offset [minutes_offset]

前の構文では:

- zoneは、標準時が有効になっているときに表示されるタイムゾーンの名前です。デフォルトのタイムゾーンはUTCです。

- hours_offsetはUTCに対する時間のオフセットです

- minutes_offsetはUTCに対する分のオフセットです

b. 毎年決まった曜日にサマータイム(DST)が開始して終了する地域でサマータイムを設定するには、次のコマンドを使用します。

clock summer-time zone recurring [week day month  hh:mm week day month  hh:mm[offset]]

前の構文でweek day month hh:mmの値が2回指定されますが、1つは開始日時、もう1つは終了日時です。

- recurringでは、毎年、指定日付にサマータイムが開始して終了することが指定されます。サマータイムはデフォルトでは無効になっています。clock summer-time zone recurringを指定し他のパラメータを付けない場合、サマータイムの規則としてデフォルトで米国の規則が使用されます。

- weekには月の週(1から5)を指定します。最初のweekは開始日、2番目のweekは終了日です。

- dayには曜日(SundayやMondayなど)を指定します。最初のweekは開始日、2番目のweekは終了日です。

- monthには月(JanuaryやJuneなど)を指定します。最初のweekは開始日、2番目のweekは終了日です。

- hh:mmには、24時間形式の時刻の時間と分(15:42など)を指定します

- offsetは、サマータイムで追加される分数です。デフォルトは60です。

例4-1 Ciscoスイッチでのタイムゾーンの設定

次に、タイムゾーンをアメリカ東部に設定し、サマータイムを有効にする場合の例を示します。

$ telnet dmcisco-ip
Connected to switch name
Escape character is '^]'.

User Access Verification

Password:
dmcisco-ip>enable
Password:
dmcisco-ip#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
dmcisco-ip(config)#clock timezone EST -5
dmcisco-ip(config)#clock summer-time EDT recurring
dmcisco-ip(config)#end
dmcisco-ip#write memory
Building configuration...
Compressed configuration from 6421 bytes to 2041 bytes[OK]
dmcisco-ip#show clock
12:03:43.516 EDT Wed May 12 2012
dmcisco-ip#

4.12 KVMスイッチの構成

この手順では、KVM(キーボード、ビデオ、マウス)スイッチの構成方法について説明します。

接続されているすべてのコンポーネントの電源を切断して、スイッチを構成します。

注意:

KVMスイッチが用意されているのは、Oracle Exadata Database Machine X2-2ラック、およびSun Fire X4270 M2 Serverを使用したExadata Storage Serverを搭載したOracle Exadata Storage拡張ラックのみです。

1. ラックの前面からKVMトレイを引き出して、ハンドルを使用して開きます。

2. タッチ・パッドに触れます。

3. マウスのダブルクリックと同じように左側の[Ctrl]キーを2回押して、ホストとKVMインタフェースを切り替えます。

4. ユーザー・インタフェースのユニット・ビューから「ターゲット・デバイス」を選択します。Oracle Exadata Database Machineフル・ラックに22、Oracle Exadata Database Machineハーフ・ラックに11、Oracle Exadata Database Machineクオータ・ラックに5のセッション数が表示されます。セッション数は、Oracle Exadata Storage Expansionフル・ラックは18、Oracle Exadata Storage拡張ハーフ・ラックは9、Oracle Exadata Storage拡張クオータ・ラックは4にする必要があります。

注意:

すべてのセッションが表示されない場合、ポート・ヘッダーからIQアダプタを選択します。表ヘッダー、「ポート」の順にクリックして、ポート番号でセッションをソートします。欠落している項目をメモします。ラックの下部から上部にセッションの番号が順番に付けられます。

5. ターゲット・デバイス画面に戻ります。

6. ユーザー・アカウントから「ローカル」を選択します。

7. ユーザーの下の「管理」をクリックします。

8. 管理アカウントのパスワードを設定します。他のパラメータを変更しないでください。

9. 「保存」をクリックします。

10. アプライアンス設定から「ネットワーク」を選択します。「ネットワーク情報」画面が表示されます。

11. IPv4またはIPv6を選択します。

12. DNSサーバーのアドレス、サブネット、ゲートウェイおよびIPアドレスの値を入力します。

13. 「保存」をクリックします。

14. KVM LAN1イーサネット・ポートを管理ネットワークに接続します。

15. ネットワーク情報画面のMACアドレスを確認して、ポートが正しく構成されていることを確認します。アドレスは、KVMスイッチの背面のLAN1/LAN2ポートの横のラベルと一致する必要があります。

16. アプライアンスから「概要」を選択します。

17. KVMスイッチの名前を入力します。

18. 「保存」をクリックします。

19. 「概要」の下の「再起動」を選択して、KVMスイッチを再起動します。

20. アプライアンス設定の「バージョン」を選択して、ファームウェア・バージョンのスイッチを確認します。次のようにアプリケーションとブートに2つのバージョン番号が表示されます。

Required version is:
Application 1.2.10.15038
Boot  1.6.15020

注意:

推奨されているファームウェア・バージョンは、1.2.8以上です。

ファームウェアが1.2.3以下の場合、ネットワーク・ブラウザからアップグレードできます。バージョン1.2.3以上の場合、KVM USBポートに接続されたフラッシュ・ドライブを使用してローカルのキーボードからアップグレードできます。ファームウェアをアップグレードするには、次の手順を実行します。

a. アプライアンスから「概要」を選択します。

b. 「ツール」リストからファームウェアのアップグレードを選択します。

c. アップグレード方法を選択します。

d. 「アップグレード」をクリックします。

e. ファームウェア・バージョンを確認します。

関連項目:

KVMスイッチの管理情報ベース(MIB)の詳細は、AvocentのWebサイト(https://www.vertivco.com/en-us/support/software-download/it-management/avocent-mergepoint-unity-switches-software-downloads/)を参照してください

4.12.1 サーバーにアクセスするKVMスイッチの構成

次の手順は、サーバーにアクセスするKVMスイッチの構成方法を示しています。

注意:

KVMスイッチが用意されているのは、Oracle Exadata Database Machine X2-2ラック、およびSun Fire X4270 M2 Serverを使用したExadata Storage Serverを搭載したOracle Exadata Storage拡張ラックのみです。

1. ユニット・ビューから「ターゲット・デバイス」を選択します。

2. サーバーの電源を投入します。前面パネルに電源ボタンがあります。ボタンが固定されている場合は、小さな工具を使用して緩めます。

3. マウスの左ボタンを使用して、「名前」列のシステム名をクリックします。

4. 「概要」をクリックし、顧客の接頭辞、ノード・タイプおよび番号のOracle標準命名形式で名前を上書きします。たとえば、trnacel03は接頭辞がtrnaで、次にラック下部のストレージ・セル3を表す名前が続き、trnadb02は接頭辞がtrnaで、ラック下部のデータベース・サーバー2を表す名前が続きます。

5. 「保存」を押します。

6. ラックの各サーバーに手順2から5を繰り返します。各サーバーをBIOSで起動して、デフォルトの工場出荷時のIP構成でオペレーティング・システムを起動します。

4.12.2 KVMスイッチを使用したサーバーのアクセス

次の手順は、KVMスイッチを使用してサーバーへアクセスする方法を示しています。

注意:

KVMスイッチが用意されているのは、Oracle Exadata Database Machine X2-2ラック、およびSun Fire X4270 M2 Serverを使用したExadata Storage Serverを搭載したOracle Exadata Storage拡張ラックのみです。

1. ユニット・ビューから「ターゲット・デバイス」を選択します。

2. マウスの左ボタンを使用して、「名前」列のシステム名をクリックします。

3. KVMセッションをクリックします。

5 Exadataソフトウェアの更新

Exadataソフトウェア更新は、次の3つの主要コンポーネントに適用されます。

- Exadataストレージ・サーバー

- Exadataデータベース・サーバー

- Exadata InfiniBandスイッチ

Exadataストレージ・サーバーおよびExadataデータベース・サーバーの更新には、一般的に、次のものに対する更新が含まれています。

- Oracle Linuxオペレーティング・システム

- Exadataソフトウェア

- ファームウェア(たとえば、ディスク、フラッシュ、RAIDコントローラ、ILOM、HCA)

一般的に、コンポーネントは推奨される最小リリースと揃えることをお薦めしますが、コンポーネントごとに別々に更新することもできます。たとえば、Exadata InfiniBandスイッチをExadataストレージ・サーバーおよびExadataデータベース・サーバーよりも後に更新できます。ただし、My Oracle Supportノート888828.1を参照して、依存性がないかどうかを確認する必要があります。

リリースされるすべてのExadataソフトウェア更新を個別に適用することが必要になるわけではありません。たとえば、リリースを2つか3つスキップして、より新しいリリースに直接更新できます。データベース・サーバーは年に2回更新することをお薦めします。

この項では、3つの主要コンポーネントのそれぞれに関して、更新を準備、適用およびロールバックする方法について説明します。まず汎用的なアプローチについて説明し、その後、一般的な更新シナリオを示します。

イメージ・バージョンのコンポーネント

リリースのイメージ・バージョンは、次の3つのコンポーネントで構成されています。たとえば、imageinfo -verが12.1.2.1.1.150316.2を返した場合、次のようになります。

- 製品バージョンは12.1.2.1.1です。

- 日付コードは150316です。

- Oracleの内部ビルド番号は2です。このコンポーネントはオプションです。

ほとんどの状況においては、製品バージョン(たとえば12.1.2.1.1)のみでリリースを参照することで十分です。ただし、アップグレードするときには、インストール済リリースおよびターゲット・リリースの製品バージョンと日付コードの両方を考慮する必要があります。アップグレードは、次の場合に.許可されます。

1. ターゲット・リリースの製品バージョンがインストール済ソフトウェアよりも大きく、かつ

2. ターゲット・リリースの日付コードがインストール済ソフトウェアよりも大きい必要があります。

たとえば、製品バージョン12.1.1.1.2と日付コード150411で構成されるイメージ・バージョン12.1.1.1.2.150411を現在実行しているシステムがあるとします。

- 12.1.2.1.2.150617.1へのアップグレードは、両方のルールが満たされているため、許可されます。

- 12.1.2.1.1.150316.2へのアップグレードは、インストール済ソフトウェアの日付コード150411がターゲット・リリースの日付コード150316よりも大きいため、許可されません。

関連トピック

- Exadata Database MachineおよびExadata Storage Serverのサポートされているバージョン(My Oracle SupportのドキュメントID 888828.1)

5.1 ソフトウェア・メンテナンスの計画

ソフトウェア更新を開始する前に、ベスト・プラクティスを確認し、アップグレードするバージョンを決定し、適切なパッチ適用ソフトウェアを入手する必要があります。

- Exadata Database Machineソフトウェアおよび更新の理解

- ソフトウェア・メンテナンスの構成および操作のベスト・プラクティス

- Exadataソフトウェア・バージョンの理解

- Exadata Patchmgr更新ユーティリティ

5.1.1 Exadata Database Machineソフトウェアおよび更新の理解

Exadata Database Machineで実行するソフトウェアは、2つのカテゴリに分かれます。

- Exadataインフラストラクチャ・ソフトウェア

- Oracle Grid InfrastructureおよびOracle Databaseソフトウェア

次の表は、Exadata Database Machineで実行するソフトウェアの2つの主なカテゴリを説明しています。

ソフトウェア

インストールされているコンポーネント

ソフトウェアの内容

ソフトウェア・バージョンの例

Exadataインフラストラクチャ・ソフトウェア

- Exadataストレージ・サーバー

- Exadataデータベース・サーバー

- Exadata InfiniBandスイッチ

- Oracle Linuxオペレーティング・システム

- Oracle VM Server (Oracle VM構成のデータベース・サーバー上)

- Exadataソフトウェア

- ファームウェア(例: ディスク、フラッシュ、RAIDコントローラ、ILOM、HCA、InfiniBandスイッチ・ファームウェア)

Exadataストレージ・サーバーおよびデータベース・サーバー:

- 12.2.1.1.0

- 12.1.2.3.4

Exadata InfiniBandスイッチ

- 2.2.4-3

- 2.1.8-1

Oracle Grid InfrastructureおよびOracle Databaseソフトウェア

Exadataデータベース・サーバー

- Oracle Clusterware (Gridホーム)

- Oracle Database (Databaseホーム)

12.2.0.1.0

12.1.0.2.160117

11.2.0.4.161018

Exadata Database Machineがデプロイされると、表に説明されているすべてのソフトウェアがインストールおよび構成され、Oracle Databaseのパフォーマンスと可用性が向上します。大規模なエンドツーエンド・テストによって、Exadataに付属するすべてのソフトウェア・コンポーネントは、シームレスに連携します。

My Oracle Supportのドキュメント888828.1は、Exadataで実行するソフトウェアの情報のプライマリ・ソースです。 次の情報が含まれます。

- 現在と以前のすべてのリリースのリスト

- 機能使用状況の最小要件

- ExadataバージョンとDatabaseバージョン間の互換性要件

- 特定のハードウェア・リリースの互換性要件

- Exadataで使用する場合の関連製品のガイドライン

- Exadataソフトウェア・メンテナンスのその他の関連情報ソースへの参照

関連トピック

- Exadata Database MachineおよびExadata Storage Serverのサポートされているバージョン(My Oracle SupportのドキュメントID 888828.1)

5.1.1.1 ソフトウェア・リリース・タイプ

主なソフトウェア・カテゴリ(Exadataインフラストラクチャ・ソフトウェアと、Grid InfrastructureおよびDatabaseソフトウェア)は、リリース・タイプによってさらに分類されます。

ソフトウェア

リリース・タイプ

説明および内容

Exadataインフラストラクチャ・ソフトウェア

機能リリース

最初の4桁は、Exadataの機能リリースを表します(12.2.1.1.0など)。

機能リリースには、新機能、バグ修正およびセキュリティ修正が含まれています。以前の機能リリースまたは継続リリースの更新に使用される場合もあります。

11.2.3.3.1から12.1.2.3.4までの以前のリリースから、機能リリース12.2.1.1.0に直接更新できます。

Exadataインフラストラクチャ・ソフトウェア

継続リリース

5桁目は、機能リリースへの累積更新を表します(12.1.2.3.4など)。

継続リリースには、バグ修正およびセキュリティ修正が含まれています。特定の機能リリースには、約4つの継続リリースがあります。継続リリースは以前の機能リリースまたは継続リリースの更新に使用される場合もあります。

11.2.3.3.1から12.1.2.3.3までの以前のリリースから、継続リリース12.1.2.3.4に直接更新できます。

Exadataインフラストラクチャ・ソフトウェア

個別パッチ

個別パッチは、継続リリースまたは機能リリースより前に修正が必要なユーザーに提供される個別のバグ修正です。個別パッチのインストールは必要に応じて行われ、定期的にスケジュールされた計画メンテナンス・イベントではありません。

Oracle Grid InfrastructureおよびOracle Databaseソフトウェア

メジャー・リリースまたはメンテナンス・リリース

1桁目および2桁目は、メジャー・データベース・リリースおよびメンテナンス・データベース・リリースを表します(12.2や12.1など)。

メジャー・リリースまたはメンテナンス・リリースには、新機能、バグ修正およびセキュリティ修正が含まれています。

Oracle Grid InfrastructureおよびOracle Databaseソフトウェア

パッチ・セット・リリース

4桁目は、パッチ・セット・リリースを表します(12.2.0.1や12.1.0.2など)。

パッチ・セット・リリースには、主にバグ修正が含まれています。ただし、パッチ・セット・リリースに小規模な新機能や機能変更が含まれる場合もあります。

Oracle Grid InfrastructureおよびOracle Databaseソフトウェア

プロアクティブ・バンドル・パッチ

5桁目は、パッチ・セット・リリースへの累積更新を表します(12.1.0.2.170117や11.2.0.4.161018など)。

プロアクティブ・バンドル・パッチには、バグ修正およびセキュリティ修正が含まれています。標準のOracle Grid Infrastructure PSU (GIPSU)のスーパーセットです。Exadataシステムにインストールできるのはプロアクティブ・バンドル・パッチのみで、標準のPSUはインストールできません(Oracle Database 12.1.0.1は例外で、これには標準のGIPSUが使用されています)。

Oracle Database 11.2では、プロアクティブ・バンドル・パッチはExadataのデータベース・パッチと呼ばれます。

Oracle Grid InfrastructureおよびOracle Databaseソフトウェア

個別パッチ

個別パッチは、Exadataの後続のパッチ・セット・リリースまたはデータベース・パッチより前に修正が必要なユーザーに提供される個別のバグ修正です。個別パッチのインストールは必要に応じて行われ、定期的にスケジュールされた計画メンテナンス・イベントではありません。

5.1.1.2 ソフトウェア・リリース可用性

各ソフトウェア・リリース・タイプには様々な可用性の頻度があります。

Exadataの継続リリースと、四半期ごとのGrid InfrastructureおよびDatabaseのプロアクティブ・バンドル・パッチは、Oracleクリティカル・パッチ・アップデート(CPU)プログラムの一部として、四半期サイクルで定期的にリリースされます。 これらの四半期ごとのリリースは、事前の重要な修正やセキュリティ脆弱性に対処するために提供されます。

ソフトウェア

リリース・タイプ

リリース頻度

最新バージョンを維持する重要度

新しいリリースを導入する際の推奨事項

Exadataインフラストラクチャ・ソフトウェア

機能リリース

6から18か月

中

新機能を導入し、重要な修正およびセキュリティ更新を取得する場合に更新します。

Exadataインフラストラクチャ・ソフトウェア

継続リリース

3か月(四半期)

高

重要な修正およびセキュリティ更新を取得する場合に四半期に一度更新します。ラグが12か月を超えないようにしてください。

Oracle Grid InfrastructureおよびOracle Databaseソフトウェア

メジャー・リリースまたはメンテナンス・リリース

24か月以上

低

新機能を導入する場合に更新します。現在のリリースのライフタイム・サポートの終了日より前に更新します。

Oracle Grid InfrastructureおよびOracle Databaseソフトウェア

パッチ・セット・リリース

12から24か月

中

現在のパッチ・セットのエラー修正サポートの終了日より前(通常は次のパッチ・セット・リリースから1年以内)に更新します。  詳細は、My Oracle Supportのドキュメント742060.1を参照してください。

Oracle Grid InfrastructureおよびOracle Databaseソフトウェア

プロアクティブ・バンドル・パッチ

3か月(四半期)

高

重要な修正およびセキュリティ更新を取得する場合に四半期に一度更新します。ラグが12か月を超えないようにしてください。

関連トピック

- My Oracle Supportのドキュメント742060.1

5.1.1.3 ソフトウェア更新頻度

Exadataソフトウェアの定期的な更新を計画する必要があります。

次に、リリースの通常の間隔を使用した4年サイクルにわたる四半期に一度の高度なソフトウェア・メンテナンス計画の例を3つ示します。

注意:
リリース頻度は、ここに記載されている内容によって異なります(特に新機能を含むリリースの場合)。

- 例5-1

- 例5-2

- 例5-3

例5-1 本番システム・ソフトウェアのメンテナンス計画

目標 - 重要な修正やセキュリティ修正が使用可能になったら適用し、新機能リリースをできるだけ遅く導入することで、リスクを最小限にします。 可能な場合は、Exadataの新機能リリースとDatabaseの新機能リリースを同時に導入しないでください。

アクション

Y1 Q1

Y1 Q2

Y1 Q3

Y1 Q4

Y2 Q1

Y2 Q2

Y2 Q3

Y2 Q4

Y3 Q1

Y3 Q2

Y3 Q3

Y3 Q4

Y4 Q1

Y4 Q2

Y4 Q3

Y4 Q4

Y5 Q1

次のExadata継続リリースへの更新

X

X

X

X

X

X

X

X

X

X

X

X

X

次のExadata機能リリースへの更新

X

X

X

X

次のデータベース・プロアクティブ・バンドル・パッチへの更新

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

次のデータベース・パッチ・セット・リリースへの更新

X

次のデータベース・メジャー・リリースまたはメンテナンス・リリースへの更新

X

例5-2 本番システム・ソフトウェアの更新の少ないメンテナンス計画

目標 - 代替四半期更新を適用することで、メンテナンス時間を最小限にします。可能な場合は、Exadataの新機能リリースとDatabaseの新機能リリースを同時に導入しないでください。

アクション

Y1 Q1

Y1 Q2

Y1 Q3

Y1 Q4

Y2 Q1

Y2 Q2

Y2 Q3

Y2 Q4

Y3 Q1

Y3 Q2

Y3 Q3

Y3 Q4

Y4 Q1

Y4 Q2

Y4 Q3

Y4 Q4

Y5 Q1

次のExadata機能リリースへの更新

X

X

X

次のExadata継続リリースへの更新

X

X

X

X

X

次のデータベース・メジャー・リリースまたはメンテナンス・リリースへの更新

X

次のデータベース・パッチ・セット・リリースへの更新

X

次のデータベース・プロアクティブ・バンドル・パッチへの更新

X

X

X

X

X

例5-3 開発およびテスト・システム・ソフトウェアのメンテナンス計画

目標 - 最新の機能およびソフトウェア更新をできるだけ早く導入します。

アクション

Y1 Q1

Y1 Q2

Y1 Q3

Y1 Q4

Y2 Q1

Y2 Q2

Y2 Q3

Y2 Q4

Y3 Q1

Y3 Q2

Y3 Q3

Y3 Q4

Y4 Q1

Y4 Q2

Y4 Q3

Y4 Q4

Y5 Q1

次のExadata機能リリースへの更新

X

X

X

X

次のExadata継続リリースへの更新

X

X

X

X

X

X

X

X

X

X

X

X

X

次のデータベース・メジャー・リリースまたはメンテナンス・リリースへの更新

X

X

次のデータベース・パッチ・セット・リリースへの更新

X

X

次のデータベース・プロアクティブ・バンドル・パッチへの更新

X

X

X

X

X

X

X

X

X

X

X

X

X

5.1.1.4 ソフトウェア更新ユーティリティ

Oracle Exadata Database Machineソフトウェアを更新する場合、更新されるコンポーネントに応じて特定のユーティリティを使用します。

更新タイプ

ユーティリティ

コンポーネント

説明

更新前の準備状況チェック

Oracle ExaCHK

Exadata Database Machine

メンテナンス準備状況を確認し、重大な問題の発生を特定し、ソフトウェアを更新するバージョン推奨を提供するために使用されるExadataヘルスチェック・ツールです。

My Oracle Supportのドキュメント1070954.1からOracle ExaCHKを取得してください。

Exadataインフラストラクチャ・ソフトウェア

patchmgr

- Exadataストレージ・サーバー

- Exadataデータベース・サーバー

- Exadata InfiniBandスイッチ

Exadataデータベース・サーバー、ストレージ・サーバーまたはInfiniBandスイッチ上のすべてのソフトウェア(Oracle Linux、Exadataインフラストラクチャ・ソフトウェア、ファームウェア)を更新するExadataソフトウェア更新ツールです。たとえば、patchmgrは、Exadataストレージ・サーバーおよびデータベース・サーバーをExadataバージョン12.2.1.1.0に更新したり、Exadata InfiniBandスイッチをバージョン2.2.4-3に更新します。

Oracle Grid InfrastructureおよびOracle Databaseソフトウェアのプロアクティブ・バンドル・パッチ

OPatch / opatchauto

Exadataデータベース・サーバー

プロアクティブ・バンドル・パッチをOracle Grid InfrastructureホームまたはOracle Databaseホームに適用するソフトウェア更新ツールです。たとえば、OPatchは、プロアクティブ・バンドル・パッチ12.1.0.2.170117を12.1.0.2 Oracle Grid InfrastructureおよびOracle Databaseホームに適用します。

My Oracle Supportのドキュメント274526.1からOPatchを取得してください。

Oracle Grid InfrastructureおよびOracle Databaseソフトウェアのパッチ・セット、メジャー・リリースまたはメンテナンス・リリース。

Oracle Universal Installer(OUI)

Exadataデータベース・サーバー

Grid InfrastructureおよびDatabaseパッチ・セット、メジャー・リリースまたはメンテナンス・リリースをインストールし、Grid Infrastructureをアップグレードするソフトウェア・インストール・ツールです。たとえば、OUIは、 Database 12.2.0.1をインストールしたり、Grid Infrastructureをインストールして12.1.0.2から12.2.0.1にアップグレードします。

アップグレードするOracle Grid InfrastructureおよびOracle DatabaseリリースにバンドルされているOUIのバージョンを使用します。

Oracleデータベースのアップグレード

Database Upgrade Assistant(DBUA)

Exadataデータベース・サーバー

データベースを新しいパッチ・セット、メジャー・リリースまたはメンテナンス・リリースにアップグレードするデータベース・ツールです。たとえば、DBUAは、データベースを12.1.0.1から12.1.0.2にアップグレードしたり、12.1.0.2から12.2.0.1にアップグレードします。

アップグレードするOracle Grid InfrastructureおよびOracle DatabaseリリースにバンドルされているDBUAを使用します。

Oracle Grid InfrastructureおよびOracle Databaseソフトウェア

高速ホーム・プロビジョニング(RHP)

Exadataデータベース・サーバー

集中化されたサーバーから1つ以上のクラスタ上のOracle Grid InfrastructureおよびOracle Databaseソフトウェアのプロビジョニング、パッチ適用およびアップグレードを行うソフトウェア・メンテナンス・ツールです。

RHPをOracle Clusterwareの機能として使用します。

Exadataインフラストラクチャ・ソフトウェア

Oracle Grid InfrastructureおよびOracle Databaseソフトウェア

Enterprise Manager Cloud Control

- Exadataストレージ・サーバー

- Exadataデータベース・サーバー

- Exadata InfiniBandスイッチ

Enterprise Manager Cloud Controlには、ソフトウェア更新をExadataシステムに適用するライフサイクル管理機能があります。

関連トピック

- Oracle Exadata Database MachineのexachkまたはHealthCheck (My Oracle SupportのドキュメントID 1070954.1)

- 最新のOPatch (6880880)バージョンのダウンロードおよびインストール方法(My Oracle SupportのドキュメントID 274526.1)

- 『Oracle Clusterware管理およびデプロイメント・ガイド』の高速ホーム・プロビジョニング、スケーリング、パッチ適用およびアップグレードに関する項

- 『Oracle Enterprise Managerライフサイクル・マネージメント管理者ガイド』のエンジニアド・システム・ソフトウェア更新の実行に関する項

5.1.2 ソフトウェア・メンテナンスの構成および操作のベスト・プラクティス

ソフトウェア更新の計画の一環として、更新を実行する様々な方法、およびソフトウェアを更新するためのベスト・プラクティスを確認する必要があります。

5.1.2.1 ローリング更新および非ローリング更新の理解

データベースがオンラインで使用可能な間はローリング形式でソフトウェア更新を実行し、Oracle ClusterwareおよびOracle Databaseが停止している場合は非ローリング形式で実行できます。

更新を実行する形式は、更新の頻度には影響しませんが、更新にかかる時間には影響します。 一般に、次の2つの方式があります。

- ローリング・ソフトウェア更新 - ローリング・ソフトウェア更新は、一度に1つの特定のコンポーネントに対して実行される更新で、他のコンポーネントはリクエストの処理中オンラインのままです。 ローリング・ソフトウェア更新について次の重要な点に注意してください。

- ローリング更新では、アプリケーション停止時間が非ローリング更新より短くなります。

- 更新が完了するまでの時間全体は長くなります。これは、1つのコンポーネントがオフラインで一度に更新され、他のすべてのコンポーネントはオンラインのままで稼働しているためです。

- 既存のデータベース接続への影響は、更新されるコンポーネントに応じて異なります。

- Exadataストレージ・サーバーまたはExadata InfiniBandスイッチのローリング更新 - ローリング更新中、すべてのデータベースは完全にオンラインで使用可能なままです。 データベース接続への中断はありません。

- Exadataデータベース・サーバー、Oracle Grid InfrastructureまたはOracle Databaseのローリング更新 - 更新中、Oracle Real Application Clusters (RAC)を使用するマルチインスタンス・データベースは使用可能なままです。 ただし、ローカル・データベース・インスタンスが停止すると、更新されるサーバー上のデータベース接続は中断されます。 表Xに説明されているように、クライアントの高可用性のためのOracle RACの機能を使用して、アプリケーションの中断を最小限にします。

- 非ローリング・ソフトウェア更新 - 非ローリング・ソフトウェア更新は、すべての特定のコンポーネントに対して実行される更新で、これらのコンポーネントはオフラインになります。 非ローリング・ソフトウェア更新について次の重要な点に注意してください。

- 非ローリング更新は、メンテナンス時間全体ではローリング更新より高速です。これは、複数のコンポーネントがパラレルに更新されるためです。

- 更新中、すべての特定のコンポーネントがオフラインで、1つのデータベース(またはシステム上のすべてのデータベース)もオフラインになるため、結果としてアプリケーションへの完全な停止となります

- 非ローリング形式で更新されるExadata Database Machineによって処理された重要なアプリケーションは、Oracle Data Guardを使用する環境のスタンバイ・システムに頻繁に移動されます。

- ローリング・ソフトウェア更新と非ローリング・ソフトウェア更新の組合せ - 同じメンテナンス・ウィンドウで複数のコンポーネントを更新する場合、ローリング方式と非ローリング方式の組合せを使用して、アプリケーションの停止時間とメンテナンス時間の望ましいバランスを実現できます。アプリケーションが接続の中断を効率的に処理しない状況で使用される一般的な組合せとして、Exadataストレージ・サーバーとInfiniBandスイッチの更新をローリング形式で実行してから、Oracle Grid Infrastructure、Oracle DatabaseおよびExadataデータベース・サーバーの更新を非ローリング形式で実行します。

Exadata patchmgr更新ユーティリティは、Exadataインフラストラクチャ・コンポーネント(ストレージ・サーバー、データベース・サーバーおよびInfiniBandスイッチ)のローリング形式または非ローリング形式での更新オーケストレーションを管理します。

次の表は、各コンポート・タイプでサポートされる更新方式を説明しています。

方式

コンポーネントのサポート

更新中のデータベース可用性の影響

ローリング

Exadataストレージ・サーバー

影響なし。

Oracle RACおよび単一インスタンス・データベースは、クラスタ内のすべてのノードで完全に使用可能なままです。

ローリング

Exadata InfiniBandスイッチ

影響なし。

Oracle RACおよび単一インスタンス・データベースは、クラスタ内のすべてのノードで完全に使用可能なままです。

ローリング

Exadataデータベース・サーバー

ローカル接続が切断され、すべてのローカル・インスタンスが停止します。

Oracle RACデータベースは、クラスタ内の他のノード全体で使用可能なままです。

ローリング

Grid Infrastructure

ローカル接続が切断され、すべてのローカル・インスタンスが停止します。

Oracle RACデータベースは、クラスタ内の他のノード全体で使用可能なままです。

ローリング

Database - プロアクティブ・バンドル・パッチ

更新されるデータベース・ホームでは、ローカル接続が切断され、ローカル・インスタンスが停止します。

Oracle RACデータベースは、クラスタ内の他のノード全体で使用可能なままです。

他のOracle Databaseソフトウェア・ホームから実行するデータベースは影響を受けません。

非ローリング

- Exadataストレージ・サーバー

- Exadataデータベース・サーバー

- Grid Infrastructure

- Database - プロアクティブ・バンドル・パッチ

- Database - パッチ・セット

- Database - リリース

データベース使用不可

ワークロードをOracle Data GuardまたはOracle Golden Gateスタンバイ・システムに移動して、影響を最小限に抑えます。

5.1.2.2 Oracle LinuxカーネルおよびOracle Databaseの個別修正のオンライン更新

適格な修正のオンライン更新は、Oracle LinuxおよびOracle Databaseでサポートされています。

通常、計画ソフトウェア更新では、更新後にコンポーネントを再起動する必要があります。たとえば、Exadataデータベース・サーバーは、Exadataソフトウェア・リリースを適用した後に再起動して、システム・ファームウェアを更新し、新しいOracle Linuxカーネルをアクティブにする必要があります。同様に、Oracleデータベース・インスタンスを停止してから再起動して、ソフトウェア更新をデータベース・ホームに適用する必要があります。

ただし、オンラインで適用が可能で、修正を適用してアクティブにするためにコンポーネントを再起動する必要がない個別修正が提供される場合もあります。適格な修正のオンライン更新は、次のコンポーネントでサポートされています。

- Kspliceオフライン・クライアントを使用したExadataデータベース・サーバー上のOracle Linuxカーネル。

- OPatchオンライン・パッチ適用を使用したOracle Database。

通常、オンライン更新は、次にスケジュールされた計画ソフトウェア・メンテナンスの前に重要な修正をシステムに適用する必要がある場合に、一時的な措置として実行されます。

関連トピック

- 方法: Exadataデータベース・ノードのkspliceカーネル更新のインストール(My Oracle SupportのドキュメントID 2207063.1)

- RDBMSオンライン・パッチAkaホット・パッチ(My Oracle SupportのドキュメントID 761111.1)

5.1.2.3 最適なソフトウェア・メンテナンスの構成プラクティス

Exadata Database Machineを構成する場合は、ソフトウェア更新を実行する影響およびリスクを減らす機能を導入することが重要です。

構成のプラクティス

ソフトウェア・メンテナンスのために使用

用途

Oracle ASM高冗長性ディスク・グループ

ローリング更新 - Exadataストレージ・サーバー

データベースをオンラインのままにしてローリング形式でストレージ・サーバー更新を実行する場合、高冗長性のOracle ASMディスク・グループを構成することを強くお薦めします。高冗長性ディスク・グループは、ローリング更新中に別のストレージ・サーバーでのディスクの障害に耐えることができます。

ローリングまたはオンラインのストレージ・サーバーの更新中、更新されるストレージ・サーバーのディスクは、更新中にpatchmgrによって1つのストレージ・サーバー上でオフラインになります。更新が完了すると、ディスクはOracle ASMによって再同期化され、patchmgrは次のストレージ・サーバーの更新を開始します。

ディスクのオフライン中、ディスク・グループの冗長性は低くなります。ローリング更新中に標準冗長性ディスク・グループの冗長性が低いと、別のストレージ・サーバーでディスクに障害が発生した場合にディスマウントされ、データが失われる可能性があります。

Oracle ASMディスク・グループの冗長性は、通常、システムの初期構成時に設定されます。そのため、システム構成の前に、ストレージ・サーバー更新の実行を計画する方法(ローリングまたは非ローリング)を考慮します。

Oracle Data Guardフィジカル・スタンバイ・システムは、ローリング・ストレージ・サーバー更新中のディスク障害に対して保護することもできます。

クライアントの高可用性のためのOracle RACの機能

ローリング更新 - Exadataデータベース・サーバー、Oracle Grid InfrastructureまたはOracle Databaseソフトウェア

クラスタ内の他のサーバー上でデータベース・サービスの実行中に1つのベース・サーバー上でExadataデータベース・サーバー、Oracle Grid InfrastructureまたはOracle Databaseソフトウェアの更新をローリング形式で一度に実行する場合、更新されるExadataデータベース・サーバー上ではデータベース・サービスを停止する必要があります。

メンテナンス中に停止されるデータベース・インスタンスに接続されたクライアント・アプリケーションへの影響を最小限に抑えるには、データベース・サービス、高速アプリケーション通知(FAN)、高速接続フェイルオーバー(FCF)およびアプリケーション・コンティニュイティを使用するように、クライアント・アプリケーションを構成します。

Oracle Data Guardフィジカル・スタンバイ・データベース

ローリング更新または非ローリング更新(Oracle Databaseパッチ・セットおよびリリース更新を除く)

Oracle Data Guard Standby-First Patchの適用は、プライマリ・データベースへのリスクが最小限のローリング方式でOracleパッチを適用および検証する目的で、プライマリ・データベースとそのフィジカル・スタンバイ・データベース間で異なるExadataインフラストラクチャ、Oracle Grid InfrastructureおよびOracle Databaseソフトウェアをサポートします。

Oracle Data Guard一時ロジカル・スタンバイ・データベース

ローリング更新または非ローリング更新

Oracle Data Guardロジカル・スタンバイ・データベースを使用して、パッチ・セットおよびリリース更新でのデータベース・アップグレードによる停止時間を減らします。 データベースのアップグレードによる停止時間は、プライマリ・データベースがオンラインのままで現在のバージョンを実行して、ロジカル・スタンバイ・データベースを新しいバージョンにアップグレードし、同期を維持することを許可することにより短縮されます。

Oracle GoldenGate

ローリング更新または非ローリング更新

Oracle GoldenGateを使用して、パッチ・セットおよびリリース更新でのデータベース・アップグレードによる停止時間を減らします。データベースのアップグレード中の停止時間は、ソース・データベースがオンラインのままで現在のバージョンを実行して、ターゲット・データベースを新しいバージョンにアップグレードし、同期を維持することを許可することにより短縮されます。

関連トピック

- 『Oracle Database 2日でReal Application Clustersガイド』のサービス、FAN、FCFおよびアプリケーション・コンティニュイティを使用したクライアントの高可用性に関する項

- Oracle Patchの保証 - Data Guard Standby-First Patch適用(My Oracle SupportのドキュメントID 1265700.1)

- 『Oracle Data Guard概要および管理』のOracle Data Guard構成におけるデータベースのパッチ適用、アップグレードおよびダウングレードに関する項

- Oracle Fusion Middleware Oracle GoldenGateの管理for Windows and UNIXのライブ・スタンバイ・データベース保守のためのOracle GoldenGateの構成に関する項

5.1.2.4 最適なソフトウェア・メンテナンスの操作のプラクティス

次の操作のプラクティスによって、最適なソフトウェア・メンテナンスが可能になります。

- Oracle ExaCHKを定期的に実行する - Exadataシステムが現在のベスト・プラクティスと常に変化するベスト・プラクティスを満たし続けていることを確認するための一般的なヘルス・チェック・ツールとして、Oracle ExaCHKを毎月実行します。exachkレポートは次のように利用します。

- ベースライン比較 - レポート比較機能(-diffオプション)を使用して、現在のレポートを承認されたベースライン・レポートと比較します。

- 重大な問題の発生 - 重大な問題が発生しているかどうかレポートを確認します。迅速に対処して、Oracle ExaCHKによってレポートされた重大な問題を解決します。

- バージョン推奨 - バージョン推奨があるかどうかレポートを確認します。「MAAスコアカード」セクションでは、現在のソフトウェア・バージョンの一貫性、互換性、および最新であるかどうかを評価します。

- Oracle ExaCHKを使用してメンテナンス準備状況を確認する - ソフトウェア・メンテナンスを実行する前に、Oracle ExaCHKを実行して、システムが正常な状態であることを確認します。ソフトウェアを更新する前に、FAILまたはWARNINGチェックを修正します。ソフトウェア・メンテナンスの完了後にOracle ExaCHKを再実行して、システム状態を確認します。

- ソフトウェアを定期的に更新する - すべてのソフトウェアを定期的に更新します。最新または最近のリリースでソフトウェアをメンテナンスすると、ソフトウェア・セキュリティの向上、安定した継続リリース、新しい関連ソフトウェアとの継続した互換性、問題に対する最適なサポートと迅速な解決、新しく検出された問題を修正する機能などの利点があります。

- 更新ユーティリティの最新バージョンを使用する - ソフトウェア更新ユーティリティ(Oracle ExaCHK、patchmgrおよびOPatch)の最新バージョンを使用します。
Oracle ExaCHKは、新しい機能、修正、ベスト・プラクティスのヘルス・チェック、およびバージョン推奨が含まれるように、定期的に更新されます。データベース・サーバーのPatchmgrは、新しい機能、修正、およびデータベース・サーバー更新の既知の問題の回避策が含まれるように、定期的に更新されます。OPatchは、新しい機能および修正が含まれるように、定期的に更新されます。

- サポートされていないシステム変更を回避する - Exadata Database Machineは、統合システムで、Oracle Databaseを実行するための最適なプラットフォームになるように設計されています。Exadataストレージ・サーバーおよびInfiniBandスイッチには、Oracle Databaseの実行に必要なすべてのソフトウェアが含まれており、Oracle Databaseを最適に実行するように構成されます。Exadataストレージ・サーバーおよびInfiniBandスイッチへのソフトウェア更新は、patchmgrを使用して実行されます。Exadataドキュメントに目的の変更の実行手順が記載されていない場合、構成またはインストール済ソフトウェアは手動で(patchmgrを使用せずに)変更できない可能性があります。サポートされていない手動の変更が即時に反映されると、次のような悪い結果が多く発生する可能性があります。

- 今後のpatchmgrソフトウェア更新の失敗

- システムのレスキュー不可

- ソフトウェア不具合の効率的な診断不可

Exadataストレージ・サーバーまたはInfiniBandスイッチの目的の変更について記載されていない場合、詳細はOracleサポートに連絡してください。

- データベース・サーバーのカスタマイズを最小限にする - Exadata Database Machineは、統合システムで、Oracle Databaseを実行するための最適なプラットフォームになるように設計されています。Exadataデータベース・サーバーには、Oracle Databaseの実行に必要なすべてのソフトウェアが含まれており、Oracle Databaseを最適に実行するように構成されます。Exadataデータベース・サーバーへのソフトウェア更新は、patchmgrを使用して実行されます。ただし、サイト固有の追加のソフトウェア(モニタリング・エージェントやバックアップ・エージェントなど)の手動インストールが必要になる場合があります。
データベース・サーバーの手動カスタマイズはサポートされていますが、パッケージを追加または更新することによってオペレーティング・システムをカスタマイズすると、今後patchmgrを使用してExadataソフトウェア更新を適用するとき(たとえば、Exadataサーバーの更新前にカスタマイズを削除し、Exadata更新の完了後にカスタマイズを再適用する場合)に、追加のアクションが必要になることがあります。これは、追加したソフトウェアによって、今後のExadata更新では提供されない新しい依存性が追加される場合があるためです。データベース・サーバーのカスタマイズを最小限にすることをお薦めします。詳細は、「Exadataデータベース・サーバーの更新」の項を参照してください。

- サポートされている構成変更をテストする - データベース・サーバーのサイト固有のカスタマイズを完全にテストする必要があります(構成変更後にデータベース・サーバーが正常に再起動したことを確認するなど)。システムが正常に再起動できなくなるカスタム構成変更を行うと、今後のExadata更新が失敗します。

関連トピック

- Exadataデータベース・サーバーの更新

5.1.2.5 バージョン互換性および複合バージョンのサポート

最も安定したセキュアなシステムを維持するために、定期的に更新されるすべてのコンポーネントのソフトウェアは、推奨される最小リリースと揃えることをお薦めします。

ただし、ソフトウェア・メンテナンス・ウィンドウ中にコンポーネントのサブセットのみを更新することがサポートされており、残りのコンポーネントは以前のバージョンのままです。 たとえば、次のシナリオがサポートされます。

- Exadataストレージ・サーバーのサブセットを新しいバージョンのExadataソフトウェアに更新しますが、残りのExadataストレージ・サーバーは以前のExadataソフトウェアのバージョンのままです。

- Exadataストレージ・サーバーを新しいバージョンのExadataソフトウェアに更新しますが、Exadataデータベース・サーバーは以前のExadataソフトウェアのバージョンのままです。

- Exadataデータベース・サーバーを新しいバージョンのExadataソフトウェアに更新しますが、Exadataストレージ・サーバーは以前のExadataソフトウェアのバージョンのままです。

- Exadataストレージ・サーバーを新しいバージョンのExadataソフトウェアに更新しますが、InfiniBandスイッチは以前のExadataソフトウェアのバージョンのままです。

- InfiniBandスイッチを新しいバージョンのExadataソフトウェアに更新しますが、Exadataストレージ・サーバーは以前のExadataソフトウェアのバージョンのままです。

- Exadataストレージ・サーバーを新しいバージョンのExadataソフトウェアに更新しますが、Oracle Grid InfrastructureまたはOracle Databaseソフトウェアは以前のリリース、パッチ・セットおよび四半期パッチ・レベルのままです。

複合バージョン(同じコンポーネント内または異なるコンポーネント間)はサポートされていますが、これは、ローリング・アップグレードの目的で、ローリング・アップグレード中に存在する一時的な構成のみにすることを強くお薦めします。

複合バージョンの場合、次のルールおよび考慮事項に従う必要があります。

- 特定の世代のExadataハードウェアに必要な最低限のExadataソフトウェア・バージョンがあります。 たとえば、Exadata X6ハードウェアには、Exadataソフトウェア12.1.2.3.1以上が必要です。

- 特定のOracle Databaseリリースには、Exadataの機能を完全にサポートするための最低限のExadataソフトウェア・リリースが必要です。 たとえば、Oracle Database 12cリリース2 (12.2)では、すべてのExadataオフロード機能をサポートするには、Exadataストレージ・サーバー上にExadataソフトウェア・リリース12.2.1.1.0以上が必要です。

- Exadataの新しいリリースで提供されている機能には、最低でもOracle Grid InfrastructureまたはOracle Databaseソフトウェアのリリース、パッチ・セットまたはパッチが必要です。 たとえば、Exadataの機能である圧縮型索引スキャンのためのExadata Smart Scanオフロードには、ストレージ・サーバー上にOracle Database 12.2およびExadataソフトウェア12.2が必要です。

- Grid Infrastructureでは、ローリング更新のみの目的で、ローリング更新中に限定して、複合バージョンがサポートされています(たとえば、12.1.0.2から12.2.0.1への更新や、12.1.0.2.161018から12.1.0.2.170117への更新)。 Oracle Clusterwareの機能には、クラスタがローリング・アップグレード・モードの場合に制限されているものもあります。

- Databaseでは、ローリング更新のみの目的で、プロアクティブ・バンドル・パッチの複合バージョンがサポートされています(たとえば、12.1.0.2.161018から12.1.0.2.170117への更新)。

関連トピック

- Exadata Database MachineおよびExadata Storage Serverのサポートされているバージョン(My Oracle SupportのドキュメントID 888828.1)

- 『Oracle Exadata Database Machineシステム概要』のOracle Exadata Database Machine 12cリリース2 (12.2.1.1.0)の新機能に関する項

5.1.2.6 更新の順序

一般に、ソフトウェア更新を実行すると、更新は、ビジネス・ニーズおよびメンテナンス・ウィンドウの要件に基づいた順序でコンポーネントに適用されます。

ソフトウェア更新を適用する推奨順序は次のとおりです。

1. Oracle Grid InfrastructureおよびOracle Databaseソフトウェア

2. Exadataデータベース・サーバー・ソフトウェア

3. Exadataストレージ・サーバー・ソフトウェア

4. Exadata InfiniBandスイッチ・ソフトウェア

特定の更新順序が必要になる例外があります。これは、更新するバージョンのExadataソフトウェアの補足READMEに記載されています。 必須の更新順序の例をいくつか示します。

- Oracle ASM Cluster File System (Oracle ACFS)が構成されているシステムを更新する場合は、データベース・サーバー(非Oracle VMまたはOracle VM)をExadataソフトウェア・リリース12.2に更新する前に、Grid Infrastructureホームにバグ22810422に対する修正を含める必要があります。

- Oracle VM構成をExadataソフトウェア・リリース12.1からExadataソフトウェア・リリース12.2に更新する場合、dom0をExadataソフトウェア・リリース12.2に更新する前に、すべてのdomUをExadataソフトウェア・リリース12.2に更新する必要があります。

- Oracle VM構成を更新する場合、domUをExadataソフトウェア・リリース12.2に更新する前に、domUのGrid Infrastructureホームは、プロアクティブ・バンドル・パッチ・リリース12.1.0.2.161018 (2016年10月)以降を実行している必要があります。

一般に、ソフトウェア更新順序の要件が発生するのは、1つ以上のコンポーネントを新機能を含む新しいバージョンに更新する場合です(たとえば、Exadataソフトウェアをリリース12.1からリリース12.2に更新する場合など)。詳細は、更新するソフトウェア・バージョンのExadataソフトウェアの補足READMEを参照してください。

関連トピック

- Exadata Database MachineおよびExadata Storage Serverのサポートされているバージョン(My Oracle SupportのドキュメントID 888828.1)

5.1.3 Exadataソフトウェア・バージョンの理解

Exadataストレージ・サーバーまたはExadataデータベース・サーバーにインストールされるExadataバージョンは、imageinfoコマンドで決定されます。

Exadataリリースのイメージ・バージョンは、3つのコンポーネントで構成されています。たとえば、imageinfo -verが12.1.2.1.1.150316.2を返した場合、次のようになります。

- 製品バージョンは12.1.2.1.1です。

- 日付コードは150316です。

- Oracleの内部ビルド番号は2です。このコンポーネントは常に使用されるとはかぎりません。

5.1.3.1 新しいExadataバージョンへの更新のルール

アップグレードするときには、インストール済リリースおよびターゲット・リリースの製品バージョンと日付コードの両方を考慮する必要があります。

ほとんどの状況においては、製品バージョン(たとえば12.1.2.1.1)のみでリリースを参照することで十分です。

特定のターゲット・バージョンへのアップグレードでは、patchmgrによって施行される次のルールに従う必要があります。

1. ターゲット・リリースの製品バージョンがインストール済ソフトウェアよりも大きい
かつ

2. ターゲット・リリースの日付コードがインストール済ソフトウェアよりも大きい必要があります。

たとえば、製品バージョン12.1.1.1.2と日付コード150411で構成されるイメージ・バージョン12.1.1.1.2.150411を現在実行しているExadata Database Machineがあるとします。

- 12.1.2.1.2.150617.1へのアップグレードは、両方のルールが満たされているため、許可されます。

- 12.1.2.1.1.150316.2へのアップグレードは、インストール済ソフトウェアの日付コード150411がターゲット・リリースの日付コード150316よりも大きいため、許可されません。

5.1.4 Exadata Patchmgr更新ユーティリティ

Patchmgrは、Exadataインフラストラクチャ・コンポーネントのソフトウェアの更新に使用されるユーティリティです。

Patchmgrには次の機能があります。

- 単一の起動の場合、すべてのExadataストレージ・サーバー、Exadataデータベース・サーバーまたはInfiniBandスイッチを更新します。

- ローリング更新の実行時に、一度にコンポーネント1つずつ、ソフトウェア更新をオーケストレートします。

- 非ローリング更新の実行時に、同時にすべてのコンポーネントへのソフトウェア更新をパラレル化します。

- 必要に応じて、すべてのコンポーネント・ソフトウェア(ファームウェア、オペレーティング・システムおよびExadataソフトウェアなど)を更新します。

- データベース・サーバーには、Oracle Databaseの実行に必要なすべてのソフトウェアが含まれており、Oracle Databaseを最適に実行するように構成されます。 ただし、サイト固有の追加のソフトウェア(モニタリング・エージェントやバックアップ・エージェントなど)の手動インストールが必要になる場合があります。 データベース・サーバーの手動カスタマイズはサポートされていますが、パッケージを追加または更新することによってオペレーティング・システムをカスタマイズすると、今後patchmgrを使用してExadataソフトウェア更新を適用するときに、追加のアクションが必要になることがあります。

- Exadataドキュメントに目的の変更の実行手順が記載されていない場合、ストレージ・サーバーまたはInfiniBandスイッチの構成、またはインストール済ソフトウェアは手動で変更(patchmgrを使用せずに更新)できない可能性があります。

- Patchmgrは、rootユーザーまたはroot以外のユーザーとして、Oracle Linuxを実行するExadataシステムまたは非Exadataシステムから実行できます。

- patchmgrの複数の起動は、同じソフトウェア・ディレクトリから実行できます。

データベース・サーバーを更新する場合、patchmgrは必要に応じて次を管理します。

- データベースとクラスタウェアの停止および起動

- ユーザー・ドメインの停止および起動(domU)

- Oracle Enterprise Manager Cloud Controlエージェントの停止および起動

- リモート・ネットワーク・マウントのアンマウント

- ロールバックに使用できるルート・ファイル・システムのオペレーティング・システムのバックアップの実行

- データベース・ホームとOracle Grid Infrastructureホーム・バイナリの再リンク

- 既知の問題の更新されたベスト・プラクティス構成の変更および回避策の適用

5.1.4.1 Patchmgrの取得

ストレージ・サーバーおよびInfiniBandスイッチの更新では、更新対象のExadataソフトウェア・リリースにバンドルされているバージョンのpatchmgrを使用します。

データベース・サーバーの更新では、My Oracle Supportのパッチ21634633からpatchmgrを使用します。 Exadataデータベース・サーバーを更新する際には、常にMy Oracle Supportのパッチ21634633から最新のpatchmgrを使用することをお薦めします。

関連トピック

- dbnodeupdate.shおよびdbserver.patch.zip: DBNodeUpdateユーティリティおよびpatchmgrを使用したExadata Database Server Softwareの更新(My Oracle SupportのドキュメントID 1553103.1)

5.1.4.2 Patchmgrの構文

Patchmgrは、Exadataインフラストラクチャ・コンポーネントのソフトウェアの更新に使用されるユーティリティです。

前提条件

Patchmgrは、Exadataデータベース・サーバーまたはOracle Linuxを実行しているExadata以外のシステムである駆動システムで実行されます。 これにより、patchmgrを中央サーバーから実行して複数のExadataシステムを更新したり、単一のExadataシステムのすべてのデータベース・サーバーを1回のpatchmgrの起動で更新したりできます。 patchmgrがExadataデータベース・サーバーから実行される場合、そのデータベース・サーバーはpatchmgrに提供されるグループ・ファイルにすることはできません。

構文

Patchmgr構文は、更新するコンポーネントによって異なりますが、一般的なpatchmgr構文は次のとおりです。

./patchmgr -component component_list_file -action required_arguments [optional_arguments]

オプション

オプション

説明

component

更新するコンポーネントを表します。有効な値は、-cells、-dbnodes、または

-ibswitches

component_list_file

更新するコンポーネントのホスト名を含むテキスト・ファイル。 たとえば、Exadataストレージ・サーバー(-cells)を更新する場合、 component_list_fileにはExadataストレージ・サーバーのすべてのホスト名のリストが含まれます。

action

実行する操作。 ほとんどの場合、アクションは更新されるコンポーネントに固有です。

required_arguments

特定のアクションに必要な追加引数。

optional_arguments

特定のアクションに必要なオプション引数。

使用上の注意

- patchmgrの複数の起動は、-log_dirオプションを使用して同じソフトウェア・ディレクトリから同時に実行できます。 これにより、patchmgrは、複数のExadataシステムを同じソフトウェア・ディレクトリから同時に更新できます。

- Patchmgrは、rootユーザーとしてもroot以外のユーザーとしても実行できます。 patchmgrを実行しているユーザーは、patchmgrが更新するサーバーまたはスイッチにルートレベルのSSH等価が構成されている必要があります。 patchmgrをroot以外のユーザーとして実行するには、-log_dirオプションを使用する必要があります。

- 以前のリリースでは、dbnodeupdate.shユーティリティを使用してデータベース・サーバーを更新していました。dbnodeupdate.shはpatchmgrと統合されており、patchmgrに置き換えられています。

例

例5-4 ストレージ・サーバー更新の前提条件チェックの実行後のストレージ・サーバーの更新

./patchmgr -cells cell_group -patch_check_prereq
./patchmgr -cells cell_group -patch

例5-5 ローリング形式でのストレージ・サーバーの更新

次のコマンドは、ストレージ・サーバーをローリング形式で更新し、更新が進むと電子メール通知を受信し、更新が完了した後にセルへのパスワードなしのSSHアクセスを削除します。

./patchmgr -cells cell_group -patch -rolling -unkey -smtp_from "dbm01@example.com" -smtp_to "admin1@example.com,admin2@example.com"

例5-6 複数のストレージ・サーバーの一度での更新

次のコマンドは、3つのExadataシステム上のストレージ・サーバーを同じソフトウェア・ディレクトリから同時に更新します。1つはローリング更新を使用する更新、その他の更新は非ローリングです。

この例では、次のようになります。

- 各patchmgrコマンドは、別々の端末のウィンドウから実行する必要があります。

- patchmgrの各実行では、component_list_fileの内容に基づいて自動的に生成される一意のロギング・ディレクトリ名が使用されます。

(terminal1) ./patchmgr -cells cell_group_exa01 -patch -rolling -log_dir auto
(terminal2) ./patchmgr -cells cell_group_exa02 -patch -log_dir auto
(terminal3) ./patchmgr -cells cell_group_exa03 -patch -log_dir auto

後続のpatchmgrの実行で、異なる内容の変更された component_list_fileを使用するが、以前のpatchmgrの実行と同じロギング・ディレクトリを使用するには、-get log_dirオプションを使用してロギング・ディレクトリを取得します。次に例を示します。

1. 最初のpatchmgrの実行のロギング・ディレクトリは、自動的に生成されます。

./patchmgr -cells cell_group -patch -log_dir auto

2. 最後のセルが更新に失敗し、patchmgrが最初のpatchmgrの実行と同じロギング・ディレクトリを使用して、最後のセルに対してのみ再実行されると仮定します。 -get log_dirオプションを使用し、元のcomponent_list_fileを使用してロギング・ディレクトリを取得します。

./patchmgr -cells cell_group -patch -log_dir auto -get log_dir log_dir=/tmp/patch_12.2.1.1.1.170419/log/dm01cel01_dm01cel02_cacce4ee

3. 最後のセルのみを含むようにcell_groupファイルを更新するか、最後のセルのみを含む別のファイルを使用します。 最初のpatchmgrの実行からロギング・ディレクトリを指定すると、このセルのグループのすべてのログが同じロギング・ディレクトリに作成されます。

./patchmgr -cells cell_group -patch -log_dir /tmp/patch_12.2.1.1.1.170419/log/dm01cel01_dm01cel02_cacce4ee

例5-7 データベース・サーバーのバックアップ後の更新の実行

次のコマンドは、Exadataデータベース・サーバーをバックアップし、Exadataデータベース・サーバー更新の前提条件チェックを実行し、Exadataデータベース・サーバーを非ローリング形式で更新します。

./patchmgr -dbnodes dbnode_group -backup -iso_repo /tmp/p25640941_122111_Linux-x86-64.zip -target_version 12.2.1.1.1.170419
./patchmgr -dbnodes dbnode_group -precheck -iso_repo /tmp/p25640941_122111_Linux-x86-64.zip -target_version 12.2.1.1.1.170419
./patchmgr -dbnodes dbnode_group -upgrade -nobackup -iso_repo /tmp/p25640941_122111_Linux-x86-64.zip -target_version 12.2.1.1.1.170419

関連トピック

- SSH等価の設定

5.2 Exadataソフトウェア更新の実行の概要

この項では、Exadataコンポーネントへのソフトウェア更新を実行するために必要な、高度なアクションについて説明します。

- ソフトウェア・メンテナンス前に実行するアクション

- Exadataストレージ・サーバー更新の実行の概要

- Exadataデータベース・サーバー更新の実行の概要

- Exadata InfiniBandスイッチ更新の実行の概要

- Grid InfrastructureおよびDatabase更新の実行の概要

5.2.1 ソフトウェア・メンテナンス前に実行するアクション

Exadata Database Machine上のソフトウェアの更新を実行するには、次のアクションを実行する必要があります。

- ターゲット・リリースを特定する - ターゲット・リリースは、次のいずれかによって決定されます。

- My Oracle Supportのドキュメント888828.1の推奨事項。

- Oracle ExaCHKレポートの「MAAスコアカード」セクションのバージョン推奨。

- Oracle ExaCHKを実行する - Oracle ExaCHKの最新バージョンを実行して、システムのソフトウェア・メンテナンス準備状況を確実にします(My Oracle Supportのドキュメント 1070954.1を参照してください)。 レポートで、次の点を確認します。

1. ベースラインから逸脱したFAILまたはWARNINGチェックを修正します。

2. 「MAAスコアカード」セクションでバージョン推奨を確認します。 Oracle ExaCHKは、現在のソフトウェア・バージョンの一貫性、互換性、および最新であるかどうかを評価します。

3. 「MAAスコアカード」セクションで重大な問題が発生しているかどうか確認します。 ターゲット・バージョンの選択によって、重大な問題の発生が解決されます。

次のタイミングでOracle ExaCHKの最新バージョンを実行することをお薦めします。

- 毎月(Exadataのベスト・プラクティスに従っているシステムを維持するため)

- メンテナンス準備状況を確実にするためのソフトウェア更新の1週間前

- メンテナンス準備状況を確実にするためのソフトウェア更新の前日

- ソフトウェア更新が完了した直後

- 前提条件チェックを実行する -

1. My Oracle Supportから、ターゲット・ソフトウェア・リリースおよびソフトウェア更新ユーティリティ(patchmgr、OPatchなど)の最新バージョンをダウンロードします。

2. 前提条件チェックを実行し、問題を修正します。  初期の前提条件チェックの実行は、問題を修正するための時間を確保するために、メンテナンス・ウィンドウの数日または数週間前に実行する必要があります。更新の直前に、前提条件チェックを再度実行します。

注意:
データベース・サーバーの前提条件チェックおよび-nomodify_at_prereqフラグの実行には、特別な考慮が必要です。  詳細は、「Exadataデータベース・サーバーの更新」を参照してください。

- 最新ドキュメントを確認する -

1. Oracle ExaCHKによってまだ自動的にチェックされていない、最近公開された重大な問題については、My Oracle Supportのドキュメント1270094.1を確認してください。

2. ソフトウェアがリリースされた後に検出された既知の問題のターゲット・ソフトウェア・バージョンについては、My Oracle Supportの補足READMEを確認してください。

関連トピック

- Exadata Database MachineおよびExadata Storage Serverのサポートされているバージョン(My Oracle SupportのドキュメントID 888828.1)

- Oracle Exadata Database MachineのexachkまたはHealthCheck (My Oracle SupportのドキュメントID 1070954.1)

- Exadataの重大な問題(My Oracle SupportのドキュメントID 1270094.1)

5.2.2 Exadataストレージ・サーバー更新の実行の概要

Exadataストレージ・サーバーを更新するプロセスの概要を示します。

Patchmgrは、ストレージ・サーバーのローリング形式または非ローリング形式での更新オーケストレーションを管理します。  -rollingオプションを使用する場合は、Oracle ASM高冗長性ディスク・グループを使用して、更新中に別のストレージ・サーバーでのディスクの障害に耐えるようにすることをお薦めします。

1. My Oracle SupportからターゲットのExadataソフトウェアをダウンロードし、それを駆動システム上で実行します。 My Oracle Supportのドキュメント888828.1を参照してください。

2. 更新するストレージ・サーバーのリストを含むファイルを作成します。このファイルは、component_list_fileとして指定されます。

3. component_list_file内のすべてのストレージ・サーバー上でrootへのpatchmgrを実行するユーザーからSSH等価を構成します。

4. patchmgr前提条件チェックを実行し、問題を修正します。

5. ストレージ・サーバーが非ローリングで更新される場合は、Oracle Clusterwareおよびストレージ・サーバーにアクセスするすべてのデータベースを停止します。

6. patchmgrを実行して、非ローリング(デフォルト)またはローリング(-rollingオプション)方式でストレージ・サーバーを更新します。

7. ストレージ・サーバーが非ローリングで更新された場合は、Oracle Clusterwareおよびすべてのデータベースを再起動します。

関連トピック

- SSH等価の設定

5.2.3 Exadataデータベース・サーバー更新の実行の概要

Exadataデータベース・サーバーを更新する場合、仮想化環境には別の手順があります。

注意:
Patchmgrは、Exadataデータベース・サーバーのローリング形式または非ローリング形式での更新オーケストレーションを管理します。  -rollingオプションを使用する場合、クライアントの高可用性のためのOracle RACの機能を使用して、メンテナンス時に停止するデータベース・インスタンスに接続されたクライアント・アプリケーションへの影響を最小限に抑えることをお薦めします。

5.2.3.1 非仮想化構成を更新する手順

Oracle VMが構成されていないExadataデータベース・サーバーの更新に関連する手順の概要です。

1. My Oracle Supportのパッチ21634633から最新のpatchmgrをダウンロードし、それを駆動システム上で実行します。

2. My Oracle SupportからターゲットのExadataソフトウェアをダウンロードし、それを駆動システム上で実行します。  My Oracle Supportのドキュメント888828.1を参照してください。

3. 更新するデータベース・サーバーのリストを含むcomponent_list_fileを作成します。

4. component_list_file内のすべてのデータベース・サーバー上でrootへのpatchmgrを実行するユーザーからSSH等価を構成します。

5. patchmgrバックアップを実行して、データベース・サーバーのルート・ファイル・システムおよびオペレーティング・システムをバックアップします。

6. patchmgr前提条件チェックを実行し、問題を修正します。

7. patchmgrを実行して、非ローリング(デフォルト)またはローリング(-rollingオプション)方式でデータベース・サーバーを更新します。

関連トピック

- Exadata Database MachineおよびExadata Storage Serverのサポートされているバージョン(My Oracle SupportのドキュメントID 888828.1)

- SSH等価の設定

5.2.3.2 仮想化構成を更新する手順

個別にpatchmgrを実行して、管理ドメイン(dom0)とユーザー・ドメイン(domU)が個別に更新されます。

管理ドメイン(dom0)の更新

- My Oracle Supportのパッチ21634633から最新のpatchmgrをダウンロードし、それを駆動システム上で実行します。

- My Oracle Supportからターゲットのdom0 Exadataソフトウェアをダウンロードし、それを駆動システム上で実行します。  My Oracle Supportのパッチ・ドキュメント888828.1を参照してください。

- 更新するデータベース・サーバーdom0のリストを含むcomponent_list_fileを作成します。

- component_list_file内のすべてのデータベース・サーバーdom0上でrootへのpatchmgrを実行するユーザーからSSH等価を構成します。

- patchmgrバックアップを実行して、データベース・サーバーdom0のルート・ファイル・システムおよびオペレーティング・システムをバックアップします。

- patchmgr前提条件チェックを実行し、問題を修正します。

- patchmgrを実行して、非ローリング(デフォルト)またはローリング(-rollingオプション)方式でデータベース・サーバーdom0を更新します。

ユーザー・ドメイン(domU)の更新

1. My Oracle Supportのパッチ21634633から最新のpatchmgrをダウンロードし、それを駆動システム上で実行します。

2. My Oracle SupportからターゲットのdomU Exadataソフトウェアをダウンロードし、それを駆動システム上で実行します。  My Oracle Supportのドキュメント888828.1を参照してください。

3. 更新するデータベース・サーバーdomUのリストを含むcomponent_list_fileを作成します。

4. component_list_file内のすべてのデータベース・サーバーdomU上でrootへのpatchmgrを実行するユーザーからSSH等価を構成します。

5. patchmgrバックアップを実行して、データベース・サーバーdomUのルート・ファイル・システムおよびオペレーティング・システムをバックアップします。

6. patchmgr前提条件チェックを実行し、問題を修正します。

7. patchmgrを実行して、非ローリング(デフォルト)またはローリング(-rollingオプション)方式でデータベース・サーバーdomUを更新します。

関連トピック

- Exadata Database MachineおよびExadata Storage Serverのサポートされているバージョン(My Oracle SupportのドキュメントID 888828.1)

- SSH等価の設定

5.2.4 Exadata InfiniBandスイッチ更新の実行の概要

Patchmgrは、InfiniBandスイッチのローリング形式での更新オーケストレーションを管理します

1. My Oracle SupportからターゲットのExadataソフトウェアをダウンロードし、それを駆動システム上で実行します。  My Oracle Supportのドキュメント888828.1を参照してください。

2. 更新するInfiniBandスイッチのリストを含むcomponent_list_fileを作成します。

3. component_list_file内のすべてのInfiniBandスイッチ上でrootへのpatchmgrを実行するユーザーからSSH等価を構成します。

4. patchmgr前提条件チェックを実行し、問題を修正します。

5. InfiniBandスイッチを更新するpatchmgrを実行します。 InfiniBandスイッチは、常にローリング形式で更新します。

関連トピック

- Exadata Database MachineおよびExadata Storage Serverのサポートされているバージョン(My Oracle SupportのドキュメントID 888828.1)

- SSH等価の設定

5.2.5 Grid InfrastructureおよびDatabase更新の実行の概要

Oracle Grid InfrastructureまたはOracle Databaseソフトウェアを更新する手順は、実行しているソフトウェア更新のタイプによって異なります。

新しいプロアクティブ・バンドル・パッチへの更新

新しいプロアクティブ・バンドル・パッチへの更新は、インプレースまたはアウトオブプレースで実行できます。インプレースとアウトオブプレースの両方の方法で、ローリング更新と非ローリング更新がサポートされています。

- インプレース
Oracle Grid InfrastructureまたはOracle Databaseソフトウェアが更新中のノードで停止している間に、OPatchを使用して現在のソフトウェア・ホームに更新が適用されます。

これは、プロアクティブ・バンドル・パッチのREADMEに記載されているように、Oracle Grid InfrastructureまたはOracle Databaseソフトウェアにプロアクティブ・バンドル・パッチ更新を適用するデフォルトの方法です。プロアクティブ・バンドル・パッチを適用する手順は、各ノードで実行する必要があります。

- アウトオブプレース(推奨)
Grid Infrastructureおよび/またはDatabaseソフトウェアの実行中に、新しいソフトウェア・ホームが準備され、更新されます。新しいホームが準備されると、Grid Infrastructureおよび/またはDatabaseはすばやく停止し、新しいホームに切り替えられ、再起動されます。

アウトオブプレースは、インプレース更新より次のような大きな利点があります。

- Grid Infrastructureおよび/またはDatabaseソフトウェアがオンライン中に新しいホームを準備できるため、リスクは低くなります。

- 新しいソフトウェア・ホームへの切替えは、インプレースの更新を適用するよりも速いため、停止時間は短くなります。

- 元のソフトウェア・ホームに簡単に戻すことができるため、ロールバックが高速になります。

アウトオブプレース更新を導入するための推奨方法は、Oracle Rapid Home Provisioning (RHP)を使用することです。RHPには次の利点があります。

- クラスタ内のすべてのノードにソフトウェア更新を配布します。

- 1つのコマンドを使用して、ローリング形式または非ローリング形式でクラスタ全体の更新をオーケストレートします。

- アプリケーションの可用性を維持するために、データベース・サービスの再配置を制御します。

アウトオブプレースのソフトウェア更新は、Enterprise Manager Cloud Controlでもサポートされています。

RHPまたはEMなしでのアウトオブプレースのソフトウェア更新は、My Oracle Supportのドキュメント2087150.1に従って行うことができます。

OJVMパッチ・セット更新

OJVMパッチ・セット更新(PSU)は、OJVMのセキュリティ脆弱性に対処するデータベース・ホーム用の個別のソフトウェア更新です。 これは、標準プロアクティブ・バンドル・パッチとは別にインストールされます。 OJVM PSUパッチは、特定の状況でOracle RACローリング形式でインストールできます。

新しいパッチ・セット・リリース、メジャー・リリースまたはメンテナンス・リリースへの更新

Grid InfrastructureまたはDatabaseの上位パッチ・セット、メンテナンスまたはメジャー・リリースに更新するには、My Oracle Supportの手順を追った説明に従ってください。

- 12.2.0.1への更新 - Exadata Database Machine用の12.2.0.1 Grid InfrastructureおよびDatabaseへのアップグレード(My Oracle Supportのドキュメント2111010.1)

- 12.1.0.2への更新 - Exadata Database Machine用の12.1.0.2 Grid InfrastructureおよびDatabaseへのアップグレード(My Oracle Supportのドキュメント1681467.1)

- 11.2.0.4への更新 - Exadata Database Machine用の11.2.0.4 Grid InfrastructureおよびDatabaseへのアップグレード(My Oracle Supportのドキュメント1565291.1およびMy Oracle Supportのドキュメント1555036.1)

関連トピック

- OPlanを使用した12c ORACLE_HOMEディレクトリのクローニングによる最小停止時間のパッチ適用(My Oracle SupportのドキュメントID 2087150.1)

- Oracle JavaVMコンポーネント・データベースPSU (OJVM PSU)パッチのRACローリング・インストール・プロセス(My Oracle SupportのドキュメントID 2217053.1)

- Oracle Linux上で11.2.0.3以降を実行するExadata Database Machineの場合の12.2へのGrid InfrastructureおよびDatabaseのアップグレード手順(My Oracle SupportのドキュメントID 2111010.1)

- Oracle Linuxを実行するExadata Database Machine上での11.2.0.2、11.2.0.3、11.2.0.4または12.1.0.1から12.1.0.2へのGrid InfrastructureおよびDatabaseのアップグレード(My Oracle SupportのドキュメントID 1681467.1)

- 11.2.0.2 BP12以前の場合のExadata Database Machine 11.2.0.4へのGrid InfrastructureおよびDatabaseのアップグレード(My Oracle SupportのドキュメントID 1565291.1)

- 11.2.0.2 BP11以前の場合のExadata Database Machine 11.2.0.4へのGrid InfrastructureおよびDatabaseのアップグレード(My Oracle SupportのドキュメントID 1555036.1)

5.3 Exadataデータベース・サーバーの更新

Exadataデータベース・サーバー・リリースの更新には、データベース・サーバー内の次のコンポーネントに対する更新が含まれています。

- Oracle Linuxオペレーティング・システム

- ファームウェア(ディスク、RAIDコントローラ、ILOM、HCA)

- Exadataソフトウェア

特定のリリースで更新されるソフトウェアおよびファームウェアのコンポーネントは、データベース・サーバーが実行されている現在のExadataソフトウェア・リリースおよび更新先のリリースによって異なります。Linuxオペレーティング・システム・パッケージおよびExadataソフトウェアは常に更新されるのに対して、ファームウェアは選択した少数のコンポーネントに対して更新されることや、まったく更新されないことがあります。

Exadataデータベース・サーバーに対する更新は、My Oracle Supportノート888828.1で特に指定されている場合を除き、Exadataストレージ・サーバーまたはInfiniBandスイッチとは関係なく適用できます。

Exadataデータベース・サーバーの更新は、常にインプレースで実行されます。つまり、アクティブなオペレーティング・システムが更新されます。実際の更新はYUMを使用して実行されますが、これを行うためのコマンドは更新ユーティリティと呼ばれるExadataユーティリティにラップされています。

更新処理中の検証手順と準備手順の厳密な順序を維持するために、YUMコマンドは更新ユーティリティにラップされています。また、Oracle提供のユーティリティを使用することで、既知の問題に対する修正の適用およびベスト・プラクティスを強制できます。

ClusterwareプロセスおよびOracle RACデータベース・インスタンスが、更新対象のデータベース・サーバー上で実行されていない必要があります。アプリケーション・レベルの影響を減らすために、Oracle Database高可用性ベスト・プラクティスで説明されているクライアント・フェイルオーバーのベスト・プラクティスに従ってください。

クラスタ全体の停止時間が許容されない場合は、ローリング方式でデータベース・サーバーを更新できます。つまり、一度に1つのExadataデータベース・サーバーを更新します。クラスタ全体の停止時間が許容される場合は、すべてのExadataデータベース・サーバーをパラレルに更新できます。非ローリング更新では、データベースの完全停止と引き換えに所要時間全体が短縮されます。

関連トピック

- Exadataデータベース・サーバーの更新ユーティリティ

- Exadata Database MachineおよびExadata Storage Serverのサポートされているバージョン(My Oracle SupportのドキュメントID 888828.1)

- Oracleデータベースの高可用性ベスト・プラクティス

5.3.1 Exadataデータベース・サーバーの更新パス

Oracle Linux 5.5以上およびOracle Exadataソフトウェア・リリース11.2.2.4.2以上が実行されているExadataデータベース・サーバーを更新するには、更新ユーティリティを使用してExadataソフトウェア更新を適用する必要があります。

11.2.2.4.2よりも古いExadataソフトウェア・リリースを実行しているExadataデータベース・サーバーを更新するには、まず、そのサーバーをOracle Linux 5.5およびExadataソフトウェア・リリース11.2.2.4.2以上に更新し、その後、更新ユーティリティを使用する必要があります。詳細は次の表を参照してください。

表5-1 更新パス

現時点でインストールされているOracle Exadataソフトウェア・リリース

現在インストールされているOracle Linuxリリース

推奨アクション

リリース11.2.2.4.2以上

リリース5.5以上

更新ユーティリティを使用してターゲット・リリースに更新します。

リリース11.2.2.4.2より前

リリース5.5以上

1. パッチ13513611を使用して、データベース・サーバーをリリース11.2.2.4.2に更新します。パッチ13513611のREADMEに記載されたセクション8の手順を参照してください。

2. 更新ユーティリティを使用して、より後のリリースに更新します。

リリース11.2.2.4.2より前

リリース5.5より前

1. リリース11.2.3.2.0に更新します。詳細は、My Oracle Supportノート1284070.1を参照してください。

2. 更新ユーティリティを使用して、より後のリリースに更新します。

関連トピック

- セル上と一致させるためのデータベース・ホストの主なソフトウェア・コンポーネントの更新(My Oracle SupportのドキュメントID 1284070.1)

5.3.2 Exadata以外のソフトウェアのインストール、更新および管理

Exadataデータベース・サーバー上でExadata以外のブランドのrpmをインストールおよび更新することは、カーネルおよびInfiniBand固有のパッケージが変更されないかぎり、許可されます。

パッケージを追加または更新することによってオペレーティング・システムをカスタマイズすると、Exadataソフトウェア更新を適用するときに問題が発生することがあります。これは、追加したソフトウェアによって、Exadata更新では提供されない新しい依存性が追加される場合があるためです。このため、Exadataイメージはそのままに近い状態を維持して、カスタマイズをできるかぎり少なくすることをお薦めします。

注意:

Exadataには、32ビット・ソフトウェアは付属していません。つまり、システムに32ビットrpmを導入するカスタマイズがある場合は、Exadataソフトウェア更新を阻害するため、削除する必要があります。

Exadataイメージによって提供されたパッケージを追加または更新した場合には、次のように、必要に応じてexadata-sun-computenode-exact rpmを削除できます。

[root@dm01 ]# rpm -e exadata-sun-computenode-exact

カスタマイズしたパッケージをインストールした場合には、スクリプトで、自動的に、それらのパッケージを削除(Exadataソフトウェアの更新前に実行)およびインストール(Exadataの更新後に実行)することをお薦めします。Exadataの更新後、カスタマイズしたパッケージを再インストールする前に、互換性が維持され、かつ引き続き必要であることを確認してください。

注意:

Oracleサポート・サービスからの指示がないかぎり、パッケージに対して強制的にrpm -Uvh --nodepsコマンドを使用しないでください。

追加のソフトウェアをインストールする以外のカスタマイズにも、同じ原則が適用されます。オペレーティング・システムに対するカスタマイズは、できるかぎり少なくすることをお薦めします。データベース・サーバーに対する変更は前述の境界内で許容されますが、オラクル社でオペレーティング・システムのあらゆる構成項目に対するあらゆるカスタマイズを予期することはできません。

Exadataユーティリティが依存する、一般的ないくつかの標準があります。これらの標準は、ベスト・プラクティスに基づき、かつ、長期にわたって検証されています。Exadata標準から逸脱すると、システムの設定が最適でなくなる可能性があり、また、オラクル社が個別の構成を予期してソフトウェアを検証することは困難であることから、リスクが発生します。このため、カスタマイズによって予期しない結果が発生することがあります。ソフトウェアを追加したり、システム構成をカスタマイズすると、標準のExadata更新処理に対して手順の変更や追加が必要になることがあります。カスタマイズの有無に関係なく、Exadata更新を本番システムで実行する前に、テスト・システムで検証することをお薦めします。

関連項目:

exadata-sun-computenode-exactの詳細は、前提条件チェックの実行を参照してください。

5.3.3 カスタマイズのレベルと影響

次の表では、Exadataデータベース・サーバーのカスタマイズに伴うリスクに関するいくつかのガイドを示します。前提条件チェックではほとんどのカスタマイズについてチェックしますが、構成変更の中には、データベース・サーバーを更新できるようにするために、ロールバックする必要があるものがあります。引き続き必要となるものについては、更新処理後にリストアできます。

表5-2 カスタマイズとそのリスク

項目

カスタマイズ・レベル

リスク

デフォルト指定のエンジニアド・システム・ソフトウェア・スタック

なし

なし

システム・ユーザー(root/oracle)のインタラクティブ・シェル・プロファイルの設定

低

高

VGExaDbのすべての空き領域の使用

低

低

追加の(Exadata以外の) rpmパッケージのインストール

中

低

様々なマウント・ポイントがあるファイル・システムのカスタマイズ

中

低

現在のExadataイメージに付属のパッケージの更新

中

低

構成ファイルのカスタマイズ、基本的なオペレーティング・システム機能の変更

高

中

追加の(Exadata以外の) rpm以外のパッケージのインストール

高

中

LVMレイアウトの変更

高

高

5.3.4 Exadataデータベース・サーバーの更新ユーティリティ

patchmgrは、Oracle Exadataデータベース・サーバーを更新するための更新ユーティリティです。

リリース12.2.1.1.0 (Exadata x86_64の場合)および12.1.2.4.0 (Exadata SPARCの場合)以降、Exadataデータベース・サーバーのExadataソフトウェア更新はpatchmgrユーティリティによってのみ適用できます。

注意:

Exadataデータベース・サーバーを更新するためのpatchmgrユーティリティは、Exadataソフトウェア更新に付属のpatchmgrスクリプトとは異なります。

データベース・サーバー用のpatchmgrは、dbserver.patch.zipにパッケージされ、My Oracle Supportノート1553103.1から独立したダウンロードとして入手できます。このユーティリティは既知の問題およびベスト・プラクティスに対処し、新しいハードウェアをサポートするために頻繁に更新されるため、常に最新のリリースを使用してください。

ユーティリティは、すべての世代のハードウェア、11.2.3.1.0以降のExadataストレージ・サーバー・リリース、およびOracle Virtual Server (dom0)とExadata Virtual Machines (domU)を実行しているOracle Exadataデータベース・サーバーをサポートしています。Oracle Exadataソフトウェア更新のREADMEファイルには、更新自体が特定の世代のハードウェアに適用可能かどうかが記載されています。READMEは、dbserver.patch.zipに付属していませんが、Oracle Exadataソフトウェア更新のzipファイルには付属しています。

ユーティリティは、Oracle Linux 5からOracle Linux 6へのExadataソフトウェア更新もサポートしています。

ユーティリティでは、オーケストレーションに対処します。更新は、1つまたは複数のExadataデータベース・サーバーを対象にローリング方式または非ローリング方式で実行できます。

更新ユーティリティは、次のタスクを実行します。

- 次のような、準備、更新、検証のすべての手順を自動化します。

- データベース、Grid InfrastructureスタックまたはdomUの停止

- Oracle Enterprise Manager Cloud Controlエージェントの停止

- リモート・ネットワーク・マウントのアンマウント(必要な場合)

- Exadataデータベース・サーバーを更新する前に、組込みのdbserver_backup.shスクリプトを使用して、オペレーティング・システムをホストするファイル・システムのバックアップを実行します。

- Oracleベスト・プラクティスおよび最新の既知の問題に対する修正を適用します。

- 更新が成功したことを確認し、Oracleバイナリを再リンクして、OracleスタックおよびdomUを起動します。

関連トピック

- 計画メンテナンスの前のExadataデータベース・サーバーのバックアップ

- dbnodeupdate.shおよびdbserver.patch.zip: DBNodeUpdateユーティリティおよびpatchmgrを使用したExadata Database Server Softwareの更新(My Oracle SupportのドキュメントID 1553103.1)

5.3.5 ツール実行ホストの更新

すべてのExadataデータベース・サーバーを一度に更新することを計画している場合は、更新対象のExadataデータベース・サーバーのグループ外にあるLinuxノードから更新ユーティリティを実行することが要件になります。これは、更新ユーティリティではその実行元のExadataデータベース・サーバーを更新できないためです。他にOracle LinuxまたはOracle Solarisを実行しているシステムがない場合には、Exadataデータベース・サーバーのいずれかから更新ユーティリティを実行できます。このような場合は、指定したdbs_groupファイルに、更新ユーティリティを実行するExadataデータベース・サーバーがリストされていないことを確認してください。

更新対象のすべてのExadataデータベース・サーバーのrootユーザーに対して、駆動ノードからrootユーザーのSSH等価を設定する必要があります。

関連トピック

- SSH等価の設定

5.3.6 root以外のユーザーとしての更新ユーティリティの実行および複数の起動の同時実行

デフォルトでは、更新ユーティリティはrootとして実行することを前提としています。ただし、リモート・ホストからroot以外のユーザーとして更新ユーティリティを実行することもできます。また、複数の起動を同時に実行することもできます。これにより、Exadataデータベース・サーバーの複数の論理グループを同時に更新できます。これを行うには、-log_dirフラグを指定して更新ユーティリティを実行します。

現在のユーザーのSSH等価が更新対象のExadataデータベース・サーバーのrootユーザーに対して設定されていることを確認してください。

次の例では、root以外のユーザーとして実行し、複数の起動を実行するオプションを示します。

[oracle@nonExadataHost ]$ ./patchmgr -dbnodes ~/dbs_group -upgrade -iso_repo /u01/ /p23557378_121223_Linux-x86-64.zip
-target_version 12.1.2.4.0.160710 -log_dir auto

-log_dirには、ログ・ディレクトリへの絶対パスか、キーワードautoを指定します。後者の場合、起動ディレクトリおよびノードのリスト・ファイルの内容に基づいて、ユーティリティがログ・ディレクトリへのパスを生成して設定します。その後、Exadataデータベース・サーバーのリストを変更した場合に、起動するときに同じログ・ディレクトリが使用されるようにするには、-get log_dirフラグを使用して、以前のセッションで使用していた-log_dirの場所を取得します。たとえば、次のコマンドを入力したとします。

[oracle@nonExadata ]$ ./patchmgr -dbnodes ~/dbs_group_test  -log_dir auto -get log_dir

このコマンドによって、次のような出力が返されます。

log_dir=/u01/test/dbserver_patch_5.160715/log/dbm01_dbm02_e8f1f75

後続のコマンドでは、log_dir値を使用します。次に例を示します。

[oracle@nonExadata ]$ ./patchmgr -dbnodes ~/dbs_group_test -precheck
-log_dir /u01/test/dbserver_patch_5.160715/log/dbm01_dbm02_e8f1f75
-iso_repo /u01/test/dbserver_patch_5.160715/p23557378_121223_Linux-x86-64.zip
-target_version 12.1.2.2.3.160720 -allow_active_network_mounts

関連トピック

- Exadataデータベース・サーバーの更新ユーティリティ

5.3.7 Exadataデータベース・サーバーを更新する場合にお薦めするタイムライン

Exadataデータベース・サーバーの更新には、次のタイムラインをお薦めします。このアプローチに従うことによって、必要な是正処置を実行するための時間を確保できます。

注意:

前提条件チェックなどの変更を加える前に、バックアップを作成してください。

表5-3 更新を実行するためのタイムライン

いつ

タスク

更新までの数週間から数日前

- My Oracle Supportノート1553103.1から最新のdbserver.patch.zipをダウンロードします。

- My Oracle Supportノート1070954.1から最新のExachkをダウンロードします。

- リリース固有のMy Oracle Supportノートで既知の問題を調査します。

- My Oracle Supportノート1270094.1を調べてExadataの重大な問題を調査します。

- Exachkを実行します。

- まず前提条件チェックを実行します。
注意: YUM依存性チェックが機能するようにするために、更新ユーティリティがExadataデータベース・サーバーに最小限の変更を加える場合があります。何も変更されないようにする場合は、-nomodify_at_prereqフラグを指定して前提条件チェックを実行します。

詳細は、前提条件チェックの実行を参照してください。

- 要注意の結果を修正します。この時点では、rpmを削除できない場合、依存性問題は無視してもかまいません。-nomodify_at_prereqを指定したため、依存性が破損している可能性があります。

更新直前

- My Oracle Supportノート1553103.1から最新のdbserver.patch.zipをダウンロードします。

- My Oracle Supportノート1070954.1から最新のExachkをダウンロードします。

- リリース固有のMy Oracle Supportノートで既知の問題を調査します。

- My Oracle Supportノート1270094.1を調べてExadataの重大な問題を調査します。

- Exachkを実行し、必要に応じて是正処置を行います。

更新時

- -backupフラグを使用してバックアップのみの実行を行います。
詳細は、計画メンテナンスの前のExadataデータベース・サーバーのバックアップを参照してください。

- 2回目の前提条件チェックを実行します。今回は、-nomodify_at_prereqフラグを省略して、YUM依存性を機能させるために必要となる変更を更新ユーティリティが加えることができるようにします。詳細は、前提条件チェックの実行を参照してください。

- ブロックしているrpmがある場合は、それを削除し、前提条件チェックを再実行して、すべての変更が完了しているかどうかを検証します。

- 更新を実行します。すでにバックアップのみの実行を行ったため、-nobackupフラグを使用してバックアップをスキップします。
詳細は、更新の実行を参照してください。

更新後

- Exachkを実行します。

- Exadataを更新する前に、削除したExadata以外のrpmを再インストールします。

5.3.8 Oracle Exadataチャンネル・コンテンツでのyumリポジトリの準備と設定

Exadataデータベース・サーバーのExadataソフトウェア更新手順では、配信にUnbreakable Linux Network (ULN)を使用します。更新は、グループ化されたパッケージ・セット(rpm)としてチャンネルに配信されます。前提条件チェックまたは更新を実行する前に、これらのパッケージをローカルに使用できるようにする必要があります。

チャンネルは、ローカルのExadata以外のデータベース・サーバーによってサブスクライブできます。これでチャンネル・コンテンツがローカル・サーバーにダウンロードされ、リポジトリがExadataデータベース・サーバーの更新に使用されるYUMリポジトリとして使用可能になります。

データ・センターから使用できるインターネット接続がない場合や、ULNを同期できない場合には、使用準備済のYUMリポジトリをISOイメージとしてダウンロードできます。

注意:

各Exadataストレージ・サーバー更新には、それぞれ独自のチャンネル/ISOイメージが付属しています。このISOイメージおよびULNチャンネルは、汎用的なLinux ULNチャンネルと完全に置き換わることを意図したものではありません。Exadata ISOおよびULNチャンネルには、Oracle Exadataチャンネル・コンテンツのみが含まれています。使用する環境で、Oracle Exadata ULNチャンネルやISOイメージに更新が含まれていない他のLinuxパッケージを使用している場合には、必要に応じて、Linux ULNチャンネルを使用して、そのパッケージを更新します。

Exadataソフトウェア更新をホストするためのYUMリポジトリを構築するには、次の方法を使用します。更新ユーティリティは、ローカルのYUMリポジトリを使用して、Exadataデータベース・サーバーを更新します。

- My Oracle SupportからISOイメージをYUMリポジトリとしてダウンロードし、圧縮イメージの場所を更新ユーティリティに渡します。これは、推奨アプローチです。

- 独立したサーバー上のULN Oracle Exadataチャンネルからローカル・ミラーをYUM HTTPリポジトリとして設定します。

- My Oracle SupportからISOイメージをYUMリポジトリとしてダウンロードし、それをWebサーバー上でYUM HTTPリポジトリとして使用できるようにします。

5.3.8.1 My Oracle SupportからISOイメージをYUMリポジトリとしてダウンロードし、圧縮イメージの場所を更新ユーティリティに渡す

Oracle Exadataソフトウェア更新を保持しているOracle Exadataチャンネルは、My Oracle Supportからダウンロード可能なイメージ(圧縮ISOファイル)として入手でき、次の2つの方法で使用できます。

- -iso_repoフラグを使用して、更新ユーティリティの引数として圧縮ファイルの場所を使用します。

- HTTPを使用して公開し、-yum_repoフラグを使用してURLを更新ユーティリティで使用します。

圧縮ファイルの場所は更新ユーティリティに直接渡すことができ、これは次の場合にお薦めします。

- リポジトリYUM HTTPサーバーとして使用可能な別のサーバーが存在しない。

- 追加ULNチャンネルからの更新を必要とするカスタマイズされたソフトウェアが、Exadataデータベース・サーバーに存在しない。

- 簡略化されたメソッドが推奨される。

注意:

圧縮ISOイメージは、更新ユーティリティを実行しているノード上にのみ存在する必要があります。圧縮ISOイメージの配信は、更新ユーティリティによって処理されます。

前提条件チェックを実行(-precheck)して、リポジトリが使用可能であることを検証できます。

5.3.8.2 独立したサーバー上のULN Oracle Exadataチャンネルからローカル・ミラーをYUM HTTPリポジトリとして設定する

このメソッドは、次の条件が満たされた場合に推奨されます。

- 更新するExadataデータベース・サーバーの数が多い。

- すべてのExadataデータベース・サーバーから、単一のリポジトリ・サーバーにアクセス可能である。

- 別のLinuxサーバーにULNミラーを構築するインフラストラクチャが存在する。

- Exadataデータベース・サーバーで、他のULNチャンネルからの更新が必要なカスタマイズされたソフトウェアを使用している。

ミラー・サーバーは、ULNからダウンロードした場合と同じく、Exadataデータベース・サーバー用にダウンロードしたExadataソフトウェア更新を保持する独立したLinuxサーバーです。Exadataデータベース・サーバーは、このローカル・ミラー(YUM HTTPリポジトリ)に接続して更新を取得します。

注意:

Exadataデータベース・サーバーを、ローカルULNミラーとして使用することはできません。そのようにすると、リポジトリを構築するためにULNが必要とするパッケージと、Exadataソフトウェア更新によってExadataデータベース・サーバーにインストールまたは更新されたパッケージとの間に、依存性の競合が発生する場合があります。使用できる独立したサーバーがない場合は、かわりにISOイメージによる方法を使用してください。My Oracle SupportからISOイメージをYUMリポジトリとしてダウンロードし、圧縮イメージの場所を更新ユーティリティに渡すを参照してください。

ローカル・リポジトリを初めて設定するとき、YUMリポジトリをホストするサーバーで使用するLinuxリリースによっては、追加のLinuxサブスクリプションが必要になる場合があります。サーバーは、次のような追加ULNチャンネルにサブスクライブして、リポジトリを構築する必要があります。

- 64ビット・システム: Enterprise Linux 5システムの場合: el5_x86_64_addonsが必要です。

- 64ビット・システム: Oracle Linux 5システムの場合: el5_x86_64_addonsが必要です。

- 64ビット・システム: Oracle Linux 6システムの場合: ol6_x86_64_addonsが必要です。

注意:

登録後、ローカルULNミラーを実行しているオペレーティング・システムに応じて、システム・サーバーはel5_x86_64_latest、ol5_x86_64_latestまたはol6_x86_64_latestを自動的にサブスクライブします。

ローカルULNミラーをYUMリポジトリとして作成および保守するには、「ローカルUnbreakable Linux Networkミラーの作成方法」(http://www.oracle.com/technetwork/articles/servers-storage-admin/yum-repo-setup-1659167.html)の説明に従って、前提条件およびサーバー設定手順を確認してください。前述の手順5については、リストされたチャンネルに加えて、Exadataのために次の手順を実行します。

- Oracle ExadataパッチのREADMEにリストされているチャンネルを追加します。たとえば、exadata_dbserver_12.1.2.3.2_x86_64_baseです。
サブスクライブするOracle Exadataチャンネルは、更新するOracle Exadataソフトウェア・リリースによって異なります。詳細は、リリースに対応したパッチのREADMEを参照してください。

前のリンクに示されているYUMミラー作成手順では、ローカル・ミラーへの移入に使用できるスクリプト(uln-yum-mirror)が用意されています。rootとしてこのスクリプトを実行すると、ULNからリポジトリを保持するローカル・ディレクトリへのrpmのダウンロードが始まります。

Webサーバーをインストールし、そのdocument Rootディレクトリがディスク上のこのリポジトリの場所を指すように構成する必要があります。これにより、HTTP Webサーバーを使用するOracle Exadata Linuxデータベース・サーバーで、Oracle Exadataチャンネル・コンテンツを使用できるようになります。これについては、前述の手順の手順7で説明されています。

更新ユーティリティを実行するときには、リポジトリの場所へのURLを指定します。このURLは、常に、repodataディレクトリのレベルである必要があります。前提条件チェック(-precheck)を実行して、リポジトリが機能していることを検証できます。前提条件チェックの実行で、YUMリポジトリを使用した前提条件チェックの例を参照してください。

注意:

IPv6アドレスのみをリスニングしているYUMリポジトリにアクセスするには、Exadataデータベース・サーバーでExadataリリース12.1.2.2.0以上が実行されている必要があります。

5.3.8.3 My Oracle SupportからISOイメージをYUMリポジトリとしてダウンロードし、それをWebサーバー上でYUM HTTPリポジトリとして使用できるようにする

Oracle Exadataソフトウェア更新を保持するISOイメージ・チャンネルをダウンロードして解凍し、すべてのOracle Exadataデータベース・サーバーへのHTTP接続が可能なWebサーバーに配置できます。このメソッドは、次の条件が満たされた場合に推奨されます。

- 更新するデータベース・サーバーの数が多い。

- すべてのデータベース・サーバーから、単一のリポジトリ・サーバーにアクセス可能である。

注意:

Exadata以外のシステムでこのISOイメージに対して更新ユーティリティを実行する場合は、各データベース・サーバーでローカルに対処されます。このような場合、ローカル・ミラーを設定する必要はありません。

- 追加ULNチャンネルからの更新を必要とするカスタマイズされたソフトウェアが、データベース・サーバーに存在しない。

注意:

データベース・サーバーにカスタム・ソフトウェアがインストールされている場合には、ISOではなくHTTP YUMリポジトリを使用すると、より適切です。これは、rpmを元どおりに追加/インストールする際の柔軟性が向上するためです。

Oracle Exadataチャンネル・コンテンツのISOイメージを、HTTPサーバーを実行するLinuxベースのサーバーで使用するには、次の手順を使用します。この手順は、他のオペレーティング・システムに応じて調整できます。この手順では、ISOイメージは/u01/app/oracle/stageディレクトリにコピーされます。Webサーバー・ドキュメント内のDocument Rootエントリは/var/www/htmlです。手順では、例としてリリース12.1.1.1.0を使用しています。

注意:

Webサーバーとして、独立したサーバー(Exadata以外のデータベース・サーバー)を使用することをお薦めします。

1. 次のコマンドを使用して、ISOイメージ・マウント・ポイントをrootユーザーとして作成します。

[root@nonExadataHost ]# mkdir -p /var/www/html/yum/unknown/EXADATA/dbserver/12.1.1.1.0/base

[root@nonExadataHost ]# mkdir –p /u01/app/oracle/stage

2. 圧縮ISOイメージをWebサーバーの/u01/app/oracle/stageにコピーします。

3. 次のコマンドを使用して、ISOイメージをrootユーザーとして、解凍およびマウントします。

[root@nonExadataHost ]# unzip p17997668_121110_Linux-x86-64.zip

[root@nonExadataHost ]# mount -o loop /u01/app/oracle/stage /121110_base_repo.iso /var/www/html/yum/unknown/EXADATA/dbserver/12.1.1.1.0/base

4. rootユーザーとして、httpdサービスを開始します。これは、httpdがインストール済であることを前提としています。

[root@nonExadataHost ]# service httpd start

5. Webブラウザを使用して、接続したYUM HTTPリポジトリを識別してテストします。リポジトリURLの例を、次に示します。

http://yum-repo/yum/unknown/EXADATA/dbserver/12.1.1.1.0/base/x86_64/

6. rootユーザーとして前提条件チェックを実行して、リポジトリが正しく設定されていることを検証します。前提条件チェックの実行を参照してください。

5.3.9 Exadata廃止パッケージの管理

リリース11.2.3.3.0以上に更新すると、Exadataデータベース・サーバーの一部のパッケージが廃止されて使用できなくなります。Exadataデータベース・サーバーの更新中に、更新ユーティリティは除外rpmリストおよび廃止rpmリストをログ・ファイルに出力します。

次の例では、ログ・ファイルに出力された除外リストおよび廃止リストを示します。この例では、除外リストはまだユーザーにより作成されていません。

RPM exclusion list  : Not in use (add rpms to /etc/exadata/yum/exclusion.lst and restart dbnodeupdate.sh)
RPM obsolete list   : /etc/exadata/yum/obsolete.lst (lists rpms to be removed by the update)
: RPM obsolete list is extracted from exadata-sun-computenode-11.2.3.3.0.131014.1-1.x86_64.rpm

どのパッケージが廃止されるかを確認するには、obsolete.lstファイルの内容を確認します。このファイルには、Exadataによって廃止されるように定義されたパッケージが記載されています。これらのパッケージは、何もアクションを実行しない場合、更新中に削除されます。このリストに手動で追加されたパッケージは無視されます。次に、obsolete.lstファイルのごく一部をサンプルとして示します。

[root@dm01 ]# cat /etc/exadata/yum/obsolete.lst
# Generated by dbnodeupdate.sh runid: 021213024645
at.x86_64
java-*-openjdk
rhino.noarch
jline.noarch
jpackage-utils.noarch

obsolete.lstファイルにリストされたパッケージが削除されないようにするには、/etc/exadata/yum/exclusion.lstファイルを作成し、保持するパッケージのrpm名(ワイルドカード使用可)を記載します。/etc/exadata/yum/exclusion.lstファイルを、使用するすべてのExadataデータベース・サーバーに配置します。

次の例は、除外リストに追加されたパッケージを示します。

[root@dm01 ]# cat /etc/exadata/yum/exclusion.lst
java-*-openjdk

exclusion.lstファイルにエントリを追加し、更新ユーティリティを再実行すると、除外リストが検出されます。除外リスト上のrpmパッケージは、obsolete.lstファイルに表示されていますが、exclusion.lstファイル内にリストされたパッケージは更新中に削除されません。

5.3.10 個々のパッケージの更新

セキュリティの確保やカスタマイズのために、Exadataリリースによって提供される個々の(汎用的な) Linuxパッケージを更新することが必要になる場合もあります。これを行うには、まずexadata-sun-computenode-exact rpmを削除します。

このrpmを削除することは、機能には影響を及ぼしませんが、ロックが削除されます。このロックを削除することで、特定の個々のLinux rpmを更新できるようになります。

必要に応じて、次のようにexadata-sun-computenode-exact rpmを削除できます。

[root@dm01 ]# rpm -e exadata-sun-computenode-exact

新しいリリースに更新するときに、更新ユーティリティはロックをリストアしようとします(exadata-sun-computenode-exact)。このことは、たとえば、より新しいリリースにより新しいパッケージが同梱されている場合に発生することがあります。

exadata-sun-computenode-exact rpmをリストアできない場合、更新ユーティリティはexadata-sun-computenode-minimumにフォールバックします。

注意:

Oracleサポート・サービスからの指示がないかぎり、パッケージで強制的にrpm -Uvh --nodepsコマンドを使用しないでください。

5.3.11 前提条件チェックの実行

実際の更新を行う前に、常に、前提条件チェックを実行する必要があります。前提条件チェックでは停止時間は必要なく、次のような重要な検証を実行します。

- Exadataリリースの検証(Oracle Linux 5.5を実行している11.2.2.4.2以上)

- ユーザー入力の検証

- インストール・メディア(ISOかHTTPのいずれかのYUMリポジトリ)の検証

- ディスク領域およびスナップショットの検証

- 更新を正常に終了するために重要なYUM設定の検証

- 既知の問題/ベスト・プラクティス

更新ユーティリティによって実行される最も重要な検証は、YUM依存性チェックです。YUM依存性チェックは、実際のYUM更新は行わず、依存性の検証を行うYUM更新テスト実行コマンド(11.2.3.3.0で導入)です。これは、更新を続行できるかどうかを判断する最終テストです。正常に更新できない場合、その原因がカスタマイズであることがよくあります。たとえば、RPMを追加でインストールしたことによって、YUMリポジトリにない依存パッケージが必要になることがあります。この場合、競合を解決するための是正処置を実行する必要があります。

YUM依存性チェック(テスト実行)は、MinimumおよびExact依存性に対して検証されます。これらの依存性は非機能Exadata RPMによって成立し、管理者がシステムをカスタマイズするときに、元のExadataリリースとまったく同じ(かそれに近い)状態を維持するために役立ちます。更新ユーティリティでは、次のようにexadata-sun-computenode-exact rpmおよびexadata-sun-computenode-minimum rpmを使用します。

- exadata-sun-computenode-exact rpmでは、更新中にOracle Exadataブランド・パッケージの特定のリリースのみが許可されるようにします(リリース=x)。

- exadata-sun-computenode-minimum rpmでは、更新中にOracle Exadataブランド・パッケージの特定のリリース以上のリリースが許可されるようにします(リリース>=x)。

exadata-sun-computenode-exact rpmを使用すると、すべてのOracle Exadataパッケージが基本インストールとまったく同じになるため、システムはより新しいリリースに新しくイメージ化されたかのように見えます。一方、exadata-sun-computenode-minimum rpmを使用すると、Minimum依存性が設定され、すべてのパッケージのインストールが強制されるものの、パッケージをそれより後のバージョンにすることも許容されます。基本インストールは、常に、両方のRPMを使用して開始されます。カスタマイズや更新を許可するには、exadata-sun-computenode-exactを削除する必要があります。

デフォルトでは、後のExadataリリースに更新するときに、更新ユーティリティはExact依存性を一致させようとします。Exact依存性が競合して成立しない場合、ユーティリティはフォールバックし、Minimum依存性を成立させるために、exadata-sun-computenode-minimum rpmの適用を試みます。このような場合、exadata-sun-computenode-exact rpmはインストールされていません。

Exact依存性の欠如または未更新は許容され、問題にはなりません。システムをExact依存性に従って更新する必要がある場合、すべての競合を解決する必要があります。ログ・ファイルを調べて、競合するパッケージを確認し、それらを慎重に削除してから、前提条件チェック・モードで更新ユーティリティを再実行します。

依存性の問題のために前提条件チェックが失敗した場合には、画面上でエラーを参照できます。更新ユーティリティのログ・ファイルには、より詳細な情報が含まれ、どの依存性が失敗したかを確認できます。Exact依存性とMinimum依存性の両方が一致しないときには、更新は続行できません。

このような場合は、ログ・ファイルを調べて、依存性が失敗した原因を特定します。失敗した依存性を取り除いた後、更新ユーティリティを再実行して、少なくともMinimum依存性が成立することを確認します。

注意:

YUM前提条件チェックが確実に機能するように、更新ユーティリティによる前提条件チェック中に、特定のパッケージが削除されることがあります。これは、一部のExadataストレージ・サーバーには、解決する必要がある既知の依存性があるためです。前提条件チェック中にこのようなRPMが削除されることは少なく、削除されてもExadataの機能には影響を及ぼしませんが、システムによっては前提条件チェックによる変更が許可されないこともあります。このようなシステムには、-nomodify_at_prereqフラグを使用することをお薦めします。このフラグを使用すると、更新ユーティリティはシステムからパッケージを削除するのではなく、削除した(インストールしたか、あるいはインストールしなかった)パッケージのリストを生成します。このフラグを使用すると、依存性チェックが失敗する場合があります。このため、計画メンテナンス・ウィンドウでバックアップのみの実行を行った後で、-nomodify_at_prereqフラグを指定しないで依存性チェックを再実行することをお薦めします。

前提条件チェック中または更新の開始前に、依存性エラーが発生した場合、次のようにして問題を解決します。

- ログ・ファイルに記載されたYUMエラーを分析します。Errorを検索します。

- 内容によっては、依存性の問題や競合の原因となるrpmパッケージを、アンインストール、インストールまたは更新する必要があります。ログ・ファイルには、失敗した依存性が記載されています。

アンインストールしたカスタムrpmパッケージが引き続き必要となり、かつ、更新したシステムと互換性がある場合には、更新後にそのパッケージを再インストールする必要があります。

デフォルトでは、アクティブなNFSマウントなど前提条件チェックで警告が発生すると、チェックは失敗します。アクティブなNFSマウントを許可する場合、リリース12.1.2.1.1以降では-allow_active_network_mountsフラグを使用できます。

その他のオプションは、更新ユーティリティに組込みのヘルプを参照してください。

前提条件チェックの例

次のコマンドは、ISOを使用してRPMを削除しない前提条件チェックの例を示しています。このコマンドは、rootとして実行します。

[root@dm01 ]# ./patchmgr -dbnodes dbs_group -precheck -iso_repo /u01/exa/p22750145_121230_Linux-x86-64.zip
-target_version 12.1.2.3.0.160207.3 -nomodify_at_prereq

-dbnodesには、更新するデータベース・ノードのリストを指定します。

-precheckには、前提条件チェック・アクションを指定します。

-iso_repoには、更新ユーティリティを実行しているノード上にあるISO (YUM)リポジトリの場所を指定します。これは、-yum_repo<location>で置き換えることができます。

-target_versionには、データベース・サーバーの更新先のターゲット・リリースを指定します。

-nomodify_at_prereqは、前提条件チェック時にRPMが削除されないことを示します。

次のコマンドは、ISOを使用して必要なRPMの削除を許可する前提条件チェックの例を示しています。このコマンドは、root以外のユーザーとして実行します。

[oracle@nonExadataHost ]$ ./patchmgr -dbnodes dbs_group -precheck -iso_repo /u01/exa/p22750145_121230_Linux-x86-64.zip
-target_version 12.1.2.3.0.160207.3 -log_dir auto

関連トピック

- Exadataデータベース・サーバー更新のトラブルシューティング

- Exadataデータベース・サーバーの更新ユーティリティ

5.3.12 計画メンテナンスの前のExadataデータベース・サーバーのバックアップ

次のリリースに更新するときは、変更を加える前に、Exadataデータベース・サーバーのバックアップを作成することをお薦めします。

このことは、-nomodify_at_prereqフラグを指定しないで前提条件チェックを実行する前や、前提条件/依存性チェックにパスするためのその他の変更を(手動で)加える前に、バックアップのみモードで更新ユーティリティを実行することを意味します。バックアップのみアクションでは、アクティブなルートと/bootファイル・システムのみをバックアップします。更新(失敗した場合)をロール・バックするには、これで十分です。

注意:

ブートできない障害からシステムをリカバリするには、更新ユーティリティに組込みのバックアップ(dbserver_backup.sh)では不十分です。ダブル・ディスク障害などの障害からデータベース・サーバー全体をリカバリするために、追加の(検証済の)バックアップ/リストア手順を採用することをお薦めします。

標準の仮想化されたExadataデータベース・サーバー(domU)の場合、アクティブなシステム・イメージを/dev/mapper/VGExaDb-LVDbSys1上のファイル・システムから実行しているときには、バックアップは/dev/mapper/VGExaDb-LVDbSys2に作成されます(その逆も同じです)。/dev/mapper/VGExaDb-LVDbSys2をアクティブなイメージとするdom0をExadataデータベース・サーバーで実行している場合、バックアップは/dev/mapper/VGExaDb-LVDbSys3に移動します(その逆も同じです)。

つまり、更新のロールバック時に、標準のデータベース・サーバーおよびdomUのアクティブなシステム・イメージは/dev/mapper/VGExaDb-LVDbSys2になり、dom0のアクティブなシステム・イメージは/dev/mapper/VGExaDb-LVDbSys3になります。

アクティブなシステム・パーティションをバックアップするプロセスでは、Sys* LVMのデフォルトのLVMスキームがあること、および両方のLVMが同じサイズであることを必要とします。サイズが異なる場合、大きい方のLVMパーティションを小さい方のLVMパーティションにバックアップできないためです。LVM VGExaDb-LVDbSys1パーティションのサイズ変更は、VGExaDb-LVDbSys2が同じサイズに変更される場合にかぎり、許可されます。

バックアップの実行中、ファイル・システムのビューの一貫性はLVMスナップショットによって保たれます。このLVMスナップショットは、バックアップ・スクリプトによって保守され、常に、VGExaDbに1Gの空きVG領域を必要とします。

スナップショットの領域は、/dev/VGExaDb/LVDoNotRemoveOrUseというプレースホルダLVMを使用することで、オラクル社によって保証されます。バックアップ・スクリプトを実行すると、このプレースホルダは削除され、スナップショットに使用可能な1Gの空き領域が常に確保されます。バックアップが完了すると、スナップショットは削除され、/dev/VGExaDb/LVDoNotRemoveOrUse LVMが再作成されます。

バックアップは、すべてのシステム・サービスが稼働している間に実行できます。リリース12.1.2.1.1以降、ユーティリティは-allow_active_network_mountsフラグでアクティブなネットワーク・マウント(NFS)をサポートしています。

バックアップの実行にかかる時間は、システムのビジー状態およびバックアップ対象データのサイズとタイプによって異なります。たとえば、数百万個の小さいファイルをバックアップすると、より大きい数個のファイルをバックアップするよりも大幅に長い時間がかかることがあります。このため、ルート・ファイル・システムに、データベース.audファイルを保持するディレクトリがないことを確認することをお薦めします。次の点に注意してください。

- バックアップは1つのみ保持できます。新規にバックアップを実行すると、既存のバックアップが上書きされます。

- -backupフラグを指定して(またはデフォルト更新モードで)更新ユーティリティを再実行すると、既存のバックアップが上書きされます。

- /boot内およびアクティブなSys LVM上にあるすべてのファイルがバックアップされます。たとえば、/u01内のファイルはバックアップされません。

バックアップのみの例

次の例では、rootとしてバックアップのみを実行する例を示します。

[root@dm01 ]# ./patchmgr -dbnodes dbs_group -backup -iso_repo /u01/exa/p22750145_121230_Linux-x86-64.zip
-target_version 12.1.2.3.0.160207.3 -allow_active_network_mounts

- -dbnodesには、更新するデータベース・ノードのリストを指定します。

- - backupには、バックアップのみアクションを指定します。

- -iso_repoには、更新ユーティリティを実行しているノード上にあるISO (YUM)リポジトリの場所を指定します。あるいは、-yum_repoフラグを使用して、YUMリポジトリのHTTPの場所を指定することもできます。
-target_versionには、バックアップの実行対象となるターゲット・リリースを指定します。

- -allow_active_network_mountsを指定すると、バックアップの実行中、アクティブなネットワーク・マウントがアクティブなままになります。

次の例では、root以外のユーザーとして実行したバックアップのみアクションを示します。

[oracle@nonExadataHost ]$ ./patchmgr -dbnodes ~/dbs_group_scab -backup -iso_repo /u01/iso/p23557378_121223_Linux-x86-64.zip
-target_version 12.1.2.2.3.160720 -allow_active_network_mounts -smtp_from "sender@somedomain.com"
-smtp_to "recipient@example.com"

関連トピック

- Oracle Linuxデータベース・サーバーのリカバリ - パーティションをカスタマイズしていない場合

5.3.13 更新の実行

ローリング方式(-rollingフラグを使用)または非ローリング方式で、Exadataデータベース・サーバーの実際の更新を実行できます。デフォルトは非ローリング方式です。

また、root以外のユーザーとしての更新ユーティリティの実行および複数の起動の同時実行の説明に従って、更新はrootとしてもroot以外のユーザーとしても(-log_dirフラグを使用)実行できます。

更新は、Minimum依存性チェックが成功した場合にのみ続行します。更新を続行するために、カスタマイズを削除することが必要になる場合があります。

デフォルトでは、更新によって、非アクティブなシステム・イメージにバックアップが作成されます。-nomodify_at_prereqフラグを使用しないで前提条件チェックの実行前にすでにバックアップを作成している場合には、更新を実行するときに–nobackupフラグを使用してバックアップをスキップできます。

注意:

-nobackupフラグを使用するのは、前提条件チェックの実行前に、-nomodify_at_prereqフラグを指定しないですでにバックアップを作成していた場合のみとしてください。

更新アクションには、次のフラグが必要です。

- -upgrade。更新アクションを指定します。

- -iso_repo (ISOイメージの場合)または-yum_repo (HTTPの場所の場合)。YUMリポジトリを指します(例5-9を参照)

- -target_version。更新先のリリースを指定します。パッチのREADMEには、常に、この情報が含まれています。

バックアップ中および更新中のアクティブなリモート・ネットワーク・マウントを許可する追加のフラグ(-allow_active_network_mounts)を指定し、更新ステータス通知用の電子メールの受信者(-smtp_from"addr"および-smtp_to"addr1 addr2 addr3...")を指定できます

例5-8 YUMリポジトリのISOイメージを使用した更新の実行

次の例では、rootとして実行し、YUMリポジトリのISOイメージを使用した更新アクションを示します。アクティブなネットワーク・マウントを許可し、ステータス通知用に電子メール情報を指定しています。

[root@dm01 ]# ./patchmgr -dbnodes ~/dbs_group -upgrade -iso_repo /u01/iso/p23557378_121223_Linux-x86-64.zip
-target_version 12.1.2.2.3.160720 -allow_active_network_mounts -smtp_from "sender@somedomain.com"
-smtp_to "receiver@somedomain.com" -nobackup

次の例では、ISO YUMリポジトリを使用してリモート・ホストからroot以外のユーザーとして実行した更新アクションを示します。アクティブなネットワーク・マウントを許可し、ステータス通知用に電子メール情報を指定しています。

[oracle@nonExadataHost ]$ ./patchmgr -dbnodes ~/dbs_group -upgrade -iso_repo /u01/iso/p23557378_121223_Linux-x86-64.zip
-target_version 12.1.2.2.3.160720 -allow_active_network_mounts -log_dir auto -smtp_from "sender@somedomain.com"
-smtp_to "receiver@somedomain.com" -nobackup

例5-9 YUMリポジトリのHTTPの場所を使用した更新の実行

次の例では、YUMリポジトリのHTTPを使用してrootとして実行した更新アクションを示します。アクティブなネットワーク・マウントを許可し、ステータス通知用に電子メール情報を指定しています。

[root@dm01 ]$ ./patchmgr -dbnodes ~/dbs_group -upgrade -yum_repo http://yum-repo/yum/ol6/EXADATA/dbserver/12.1.2.2.3/base/x86_64/
-target_version 12.1.2.2.3.160720 -allow_active_network_mounts -smtp_from "sender@somedomain.com" -smtp_to "receiver@somedomain.com"
-nobackup

次の例では、YUMリポジトリのHTTPを使用してリモート・ホストからroot以外のユーザーとして実行した更新アクションを示します。アクティブなネットワーク・マウントを許可し、ステータス通知用に電子メール情報を指定しています。

[oracle@nonExadataHost ]$ ./patchmgr -dbnodes ~/dbs_group -upgrade -yum_repo http://yum-repo/yum/ol6/EXADATA/dbserver/12.1.2.2.3/base/x86_64/
-target_version 12.1.2.2.3.160720 -allow_active_network_mounts -log_dir auto -smtp_from "sender@somedomain.com"
-smtp_to "receiver@somedomain.com" –nobackup

関連トピック

- 前提条件チェックの実行

- Exadata以外のソフトウェアのインストール、更新および管理

- 計画メンテナンスの前のExadataデータベース・サーバーのバックアップ

5.3.14 更新のロールバック

バックアップを使用すると、更新の成否に関係なく、更新をロールバックできます。このバックアップは、計画メンテナンスの前のExadataデータベース・サーバーのバックアップで説明しているように、非アクティブなシステム・パーティションに格納されています。

更新をロールバックするとき、更新ユーティリティでは次のアクションを実行します。

- スタックおよびdomUを停止します。

- アクティブなパーティションを非アクティブ化し、非アクティブなパーティションをアクティブ化します。

- 非アクティブなパーティションから/bootをリストアします。

- GRUBブート・ローダーを更新します。

非アクティブなシステム・パーティションを1つのみ保持することで、ロールバック・オプションが前回のアクティブ・イメージのみに制限されます。

例5-10 ロールバックの実行

[root@dm01 ]# ./patchmgr -dbnodes dbs_group -rollback -target_version 12.1.2.3.0.160207

-dbnodesには、更新するデータベース・ノードのリストを指定します。

-rollbackには、ロールバック・アクションを指定します。

-target_versionには、ロールバック先のターゲット・リリースを指定します。

その他のオプションは、更新ユーティリティに組込みのヘルプを参照してください。

注意:

以前のイメージにロールバックするときには、ファームウェア更新はロールバックされません。ロールバックした後、必要に応じて、次のコマンドを実行し、より古いバージョンのファームウェアを適用します。

/etc/init.d/lsidiag stop

/etc/init.d/lsi_mrdsnmpd stop

/opt/oracle.cellos/CheckHWnFWProfile -action updatefw -mode exact

最後のコマンドは、リリース11.2.3.3.0以上にのみ適用されます。

5.3.15 Exadataデータベース・サーバー更新のトラブルシューティング

更新ユーティリティによって生成されるログ・ファイルを使用して、更新をトラブルシューティングできます。

更新ユーティリティは、Exadataデータベース・サーバーの更新をオーケストレートします。ログ・ファイル(dbnodeupdate.log)およびdiagファイル(dbnodeupdate.<runid>.diag)は、最終的に次の2つの場所に存在します。

- 更新した各データベース・サーバー上の/var/log/cellosディレクトリに配置されます。

- 更新ユーティリティを実行しているノード上に統合されます。

更新ユーティリティを実行しているノード上では、-log_dirフラグをautoに設定した場合、ログ・ファイルはlog/<リスト・ファイル内のノードのコンテンツに基づいたディレクトリ>ディレクトリ(更新ユーティリティが起動されたディレクトリからの相対位置)に格納されます。たとえば、更新ユーティリティが/u01/dbserver.patchにある場合、ログ・ディレクトリは/u01/dbserver.patch/dm01db01_dm01db02_e8f1f753のようになります。

ログ・ディレクトリにある重要なファイルは次のとおりです。

- patchmgr.logには、様々なデータベース・サーバーでリモート更新コマンドを実行したときの画面出力がまとめられています。

- <hostname>_dbnodeupdate.<runid>.diagは、データベース・サーバーでの特定の実行に関するdiagファイルです。

- <hostname>_dbnodeupdate.logには、dbnodeupdate.logの出力にリモート・データベース・サーバーの/var/log/cellosからの情報を追記したものが含まれています。

前提条件チェック、バックアップ更新またはロールバックが失敗すると、画面上のエラー・メッセージには、どのノードでどの手順が失敗したかに関する情報が示されます。詳細な情報が必要な場合には、前述のログ・ファイルを参照してください。ログ・ファイルで新しい実行の開始を検索してください(zzzを検索します)。

その時間が実行に一致するかどうかをチェックします。一致した場合は、さらに調べるためにrunidをメモします。次に、ERRORを検索します。

実際のYUM更新よりも前に更新アクションが失敗した場合は、エラーを解決した後で更新を再試行できます。更新が途中で中断した場合は、ロールバックし、エラーを解決してから再試行することをお薦めします。

関連トピック

- Exadataデータベース・サーバーの依存性問題が原因で失敗した前提条件チェックのトラブルシューティング

- Exadataデータベース・サーバーでのmultilib問題のトラブルシューティング

5.4 Exadataストレージ・サーバーの更新

Exadataストレージ・サーバー・リリース更新には、Exadataストレージ・サーバー内の次のコンポーネントに対する更新が含まれています。

- Oracle Linuxオペレーティング・システム

- ファームウェア(フラッシュ、ディスク、RAIDコントローラ、ILOM、HCA)

- Exadataソフトウェア

更新されるソフトウェアおよびファームウェアは、ストレージ・サーバーに適用された現在のExadataソフトウェア・リリースおよび更新先のリリースによって異なります。Linuxオペレーティング・システム・パッケージおよびExadataソフトウェアは常に更新されるのに対して、ファームウェア更新は選択した少数のコンポーネントに対してのみ適用されることや、まったく適用されないことがあります。

Exadataストレージ・サーバーに対する更新は、特に指定されている場合を除き、Exadataデータベース・サーバーまたはInfiniBandスイッチへの更新とは関係なく適用できます。リリースされるすべてのExadataソフトウェア更新を個別に適用することが必要になるわけではありません。たとえば、リリースを2つか3つスキップして、より新しいリリースに直接更新できます。

Exadataストレージ・サーバーの更新は、常にアウトオブプレースで実行されます。つまり、Exadataストレージ・サーバー・ソフトウェアを含む新規バージョンのオペレーティング・システムは、非アクティブなシステム・パーティションにインストールされます。Exadataソフトウェアを更新するためのユーティリティは、更新自体に付属しています。

クラスタ全体の停止時間が許容されない場合は、ローリング方式でストレージ・サーバーを更新できます。ローリングとは、一度に1つのExadataストレージ・サーバーを更新することです。クラスタ全体の停止時間が許容される場合は、すべてのExadataストレージ・サーバーをパラレルに更新できます。非ローリング更新では、所要時間全体が短縮されます。

関連トピック

- Oracle Exadata Storage Serverの更新ユーティリティ

5.4.1 Oracle Exadata Storage Serverの更新ユーティリティ

Oracle Exadata Storage Serverを更新するには、patchmgr更新ユーティリティを使用します。Exadataストレージ・サーバー更新の場合、ユーティリティは更新自体と同梱(および出荷)され、ストレージ・サーバー更新としてMy Oracle Supportからダウンロードできます。

注意:

Exadataストレージ・サーバーの更新に使用されるpatchmgrは、Exadataデータベース・サーバー・ソフトウェア更新の適用に使用されるpatchmgrとは異なります。

保有しているExadataハードウェアがユーティリティでサポートされているかどうかは、更新しようとしているExadataストレージ・サーバー・リリースによって異なります。ユーティリティは、指定したExadataストレージ・サーバー全体にわたって更新処理をオーケストレートします。ユーティリティでは、ローリング方式または非ローリング方式で更新を実行できます。更新ユーティリティは、Exadataデータベース・サーバー、またはOracle LinuxかOracle Solarisを実行している他のサーバーから実行できます。

更新ユーティリティは、次のタスクを実行します。

- 準備、更新、検証の各手順を自動化します。

- ロールバックを自動化します。

更新ユーティリティは、複数のセッションをサポートしています。そのため、Exadataストレージ・サーバーのリリース12.1.2.3.2以降およびExadataデータベース・サーバーのリリース11.2.3.1.0以降の同じサーバーから、複数の更新を同時に実行できます。つまり、同じサーバーから複数のラックを同時に更新できます。更新ユーティリティは、rootとしてもroot以外のユーザーとしても実行できます。デフォルトでは、更新ユーティリティはrootユーザーとして実行されることを前提としています。ただし、複数セッションのサポートを有効にしたり、root以外のユーザーとして実行する場合には、-log_dirフラグを使用する必要があります。-log_dirフラグは、ディスク上の場所とキーワードautoという2つのタイプの引数をサポートしています。autoを指定した場合、更新ユーティリティはcell_groupファイルにリストされているストレージ・サーバーに基づいて独自のログ・ディレクトリを作成します。この動作により、cell_groupファイルから1つ以上のクラスタが追加または削除されたものと同じクラスタ内に、更新の実行のたびに、更新ユーティリティによって新しいディレクトリが作成されます。このようなディレクトリを取得(および再利用)するために、更新ユーティリティでは-getフラグを使用して自分のセッション用のログ・ディレクトリを特定できます。-getフラグは、作業ディレクトリをスキャンしてログ・ディレクトリ内のディレクトリを調べ、cell_groupに対応するディレクトリを返します。次に、コマンドの例を示します。

[oracle@nonExadataHost ]#./patchmgr -dbnodes ~/cell_group  -log_dir auto -get log_dir

以前のコメントによって、次のような出力が返される場合があります。

log_dir=/u01/test/patch_12.1.2.4.0.160802/log/dbm02celadm01_dbm02celadm02_9cfbc690

後続の更新セッションで、ログ・ディレクトリの場所を再利用できます。

[oracle@nonExadataHost ]# ./patchmgr -cells ~/cell_group -patch_check_prereq -log_dir /u01/test/patch_12.1.2.4.0.160802/log
/dbm02celadm01_dbm02celadm02_9cfbc690

5.4.2 Exadataストレージ・サーバーを更新する場合にお薦めするタイムライン

注意:

Exadata更新を本番システムで実行する前に、テスト・システムで検証することをお薦めします。

次のアプローチに従うと、必要な是正処置を実行するための時間を確保できます。

表5-4 更新を実行するためのタイムライン

いつ

タスク

更新までの数週間から数日前

- My Oracle Supportノート888828.1から必要なExadataストレージ・サーバー更新をダウンロードします。

- My Oracle Supportノート1070954.1から最新のExachkをダウンロードします。

- リリース固有のMy Oracle Supportノートで既知の問題を確認します。

- Exachkを実行します。

- 前提条件チェックを実行します。詳細は、Exadataストレージ・サーバーを更新するための準備を参照してください。

- 要注意の結果を修正し、必要に応じて前述の手順を再実行します。

更新時

- My Oracle Supportノート888828.1からExadataストレージ・サーバー更新をダウンロードします。

- My Oracle Supportノート1070954.1から最新のExachkをダウンロードします。

- リリース固有のMy Oracle Supportノートで既知の問題を確認します。

- Exachkを実行し、必要に応じて是正処置を行います。

- 必要に応じて前提条件チェックおよび是正処置を実行します。

- 更新を実行します。詳細は、Exadataストレージ・サーバーの更新の実行を参照してください。

更新後

- Exachkを実行します。

5.4.3 Exadataストレージ・サーバーを更新するための準備

Exadataストレージ・サーバーを更新する前に、次の準備手順を実行します。

更新(およびロールバック)アクションは、ローリング方式または非ローリング方式で実行できます。また、前提条件チェックもローリング方式または非ローリング方式で実行できます。デフォルトは非ローリング方式です。

1. 更新ユーティリティを駆動するユーザーに対してSSH等価を設定します。

2. Oracle ExaCHKをダウンロードして実行します。未解決の問題がある場合は、確認して対処します。My Oracle Supportノート1070954.1を参照してください。

3. リリース固有のMy Oracle Supportノートで既知の問題および回避策を確認します。

4. 更新またはロールバックの方式に対して前提条件をチェックします。
ローリング更新を実行するための前提条件:

a. My Oracle Supportノート888828.1の記載に従って、Grid InfrastructureホームおよびDatabaseホームのソフトウェア・バージョンとパッチ・レベルがExadataストレージ・サーバー・ローリング・セル更新の最小要件を満たしていることを検証します。

b. それぞれのOracle ASMディスク・グループについて、failgroup_repair_timeまたはdisk_repair_timeを検証します。
ローリング方式で更新を適用する場合、更新ユーティリティは一度に1つのサーバーを更新します。まず、すべてのグリッド・ディスクおよびASMディスクをオフラインにし、次に、サーバーに更新を適用し、その後、すべてのASMディスクおよびグリッド・ディスクをオンラインに戻します。Oracle ASM修復タイムアウト属性disk_repair_timeおよびfailgroup_repair_timeは、1つのストレージ・サーバー更新を完了できる十分な大きさの値に設定する必要があります。それぞれのデフォルト値である3.6hおよび24hが推奨値です。ローリング中に、compatible.asmが12.1.0.2.0以上のストレージ・サーバー更新ディスク・グループはfailgroup_repair_timeの値を使用し、compatible.asmが12.1.0.2.0未満のディスク・グループはdisk_repair_timeの値を使用することに注意してください。

ASM修復タイムアウト属性がデフォルト以上の値に設定されていることを検証してください。Oracle ASMインスタンスのすべてのマウント済ディスク・グループについて修復時間属性をチェックするには、次のコマンドを使用します。

SQL> col attribute format a30
SQL> col value format a10
SQL> select dg.name as diskgroup, a.name as attribute, a.value
from v$asm_diskgroup dg, v$asm_attribute a
where dg.group_number=a.group_number
and (a.name like '%repair_time' or a.name = 'compatible.asm');

DISKGROUP                      ATTRIBUTE                      VALUE
------------------------------ ------------------------------ ----------
DATA                           disk_repair_time               3.6h
DATA                           failgroup_repair_time          24.0h
DATA                           compatible.asm                 12.1.0.2.0
RECO                           disk_repair_time               3.6h
RECO                           failgroup_repair_time          24.0h
RECO                           compatible.asm                 12.1.0.2.0

ディスク・グループのOracle ASM修復タイマーがデフォルト値よりも低い場合には、修復タイマーを更新期間のデフォルト値に設定してください。すべてのストレージ・サーバーの更新が正常に完了した後で、現在値に戻してもかまいません。

非ローリング更新を実行するための前提条件:

a. 次のコマンドを使用して、各Exadataデータベース・サーバー上のOracleコンポーネントをシャットダウンして停止します。Grid_homeはOracle Grid Infrastructureソフトウェアがインストールされているディレクトリです。

[root@dm01 ]# dcli -g dbs_group -l root "Grid_home/bin/crsctl stop crs"

前記のコマンドを使用してもOracle Clusterwareが停止しなかった場合は、次のコマンドを使用して強制的に停止します。

[root@dm01 ]# crsctl stop crs -f

次のコマンドを使用して、Oracle Clusterwareステータスを確認します。Grid_homeはOracle Grid Infrastructureソフトウェアがインストールされているディレクトリです。

[root@dm01 ]# dcli -g dbs_group -l root "Grid_home/bin/crsctl check crs"

すべてのOracle Clusterwareコンポーネントがオフラインである必要があります。Oracle VMを実行している構成で非ローリング更新を実行している場合には、すべてのVMクラスタでOracle Clusterwareの状態を確認する必要があります。

b. 更新するすべてのストレージ・サーバー上にあるすべてのセル・サービスを停止します。このことを行うには、rootユーザーが、各セルに対してcellcli -e 'alter cell shutdown services all'を実行するか、または、次のdcliコマンドを実行して、すべてのセルを同時に処理します。

[root@dm01 ]# dcli -g cell_group -l root "cellcli -e alter cell shutdown services all"

5. システムが次の条件を満たしているかどうかをチェックします。

- Oracle Exadata Database MachineハードウェアがSunのサーバーを使用している。

- インストール済のOracle Exadataソフトウェア・リリースがリリース11.2.2.2.0よりも前のものである。

- インストール済のLinux ofaパッケージが1.5.1-4.0.28よりも前のものである。

システムが前の条件をすべて満たしている場合に、Exadataストレージ・サーバーでOracle Linuxを実行していると、ファイル・システムが破損し、その結果、再起動後にルート・ファイル・システムが読取り専用としてマウントされることがあります。ストレージ・サーバーおよびデータベース・サーバーを更新する前に、My Oracle Supportノート1589868.1の指示に従ってください。

6. 更新を解凍します。patch_release.date_codeディレクトリに抽出されます。このパッチ・ディレクトリに移動します。

7. ターゲット・リリースのMy Oracle Supportノートに添付されているpatchmgrプラグインをダウンロードし、My Oracle Supportノートの記載に従ってインストールします。実際に更新の適用を開始する直前に、リリース・ノートに記載されているMy Oracle Supportノート、問題および回避策を確認することをお薦めします。

8. -cleanupフラグを使用して、以前の更新ユーティリティ実行をクリーン・アップします。

注意:

初めてストレージ・サーバーを更新するときには、クリーン・アップを実行する前に、-reset_forceフラグを使用する必要があります。

rootユーザーとして-reset_forceを使用する例:

[root@dm01 ]# ./patchmgr -cells ~/cell_group –reset_force

root以外のユーザーとして-reset_forceを使用する例:

[oracle@nonExadataHost ]# ./patchmgr -cells ~/cell_group -log_dir auto –reset_force

rootユーザーとして-cleanupを使用する例:

[root@dm01 ]# ./patchmgr -cells ~/cell_group -cleanup

root以外のユーザーとして-cleanupを使用する例:

[oracle@nonExadataHost ]$ ./patchmgr -cells ~/cell_group -log_dir auto –cleanup

9. 前提条件チェックを実行します。
Exadataデータベース・サーバーからrootユーザーとしてローリング更新の前提条件チェックを実行している例:

[root@dm01 ]# ./patchmgr -cells ~/cell_group -patch_check_prereq -rolling -smtp_from "sender@example.com"
-smtp_to receiver@example.com

Exadata以外のデータベース・サーバーからroot以外のユーザーとして非ローリング更新の前提条件チェックを実行している例:

[oracle@nonExadataHost ]$ ./patchmgr -cells ~/cell_group -log_dir auto -patch_check_prereq -smtp_from "sender@example.com"
-smtp_to "receiver@example.com"

関連トピック

- Exadataセルのパッチ適用の理解

- SSH等価の設定

- Oracle Exadata Database MachineのexachkまたはHealthCheck (My Oracle SupportのドキュメントID 1070954.1)

- Exadata Database MachineおよびExadata Storage Serverのサポートされているバージョン(My Oracle SupportのドキュメントID 888828.1)

- Oracle Automatic Storage Management管理者ガイド

- Exadataストレージ・サーバーおよびLinuxデータベース・サーバー上の破損したルート・ファイル・システムがあるかどうかチェックする手順(My Oracle SupportのドキュメントID 1589868.1)

5.4.4 Exadataストレージ・サーバーの更新の実行

Exadataストレージ・サーバーを更新するための準備で前提条件手順を実行した後、実際の更新手順を実行できます。

Exadataストレージ・サーバーに更新を適用するときには、次の点に注意してください。

- シリアル・コンソールまたはILOM Webベースのコンソールを使用して、更新ユーティリティを起動しないでください。
シリアル・コンソールには、stderrまたはstdoutへの書込みが試行されると、システムが停止するという既知の問題があります。シリアル・コンソールから更新を開始した場合には、更新が停止することがあります。

次のコマンドからの出力がserialである場合は、シリアル・コンソールを使用しています。

[root@dm01 ]# ./echo $consoletype

- 必要に応じて、ILOM Webベースのコンソールを使用して、更新中にストレージ・サーバーを監視します。ILOM Webベースのコンソールは、トラブルシューティングが必要になった場合に使用する必要があります。

- ストレージ・サーバーのILOMおよびシリアル・コンソールにアクセスするには、rootユーザーとしてILOMホスト名またはIPアドレスへのSSHを使用します。シリアル・コンソールを起動するには、次を実行します。

start /SP/console

停止するには、[Esc]キーと(を順に押します。

- 更新手順またはロールバック手順ごとに新規ログイン・セッションを開始します。更新が適用されたのと同じログイン・セッションからロールバック手順を実行しないでください。ロールバック手順を実行したログイン・セッションから更新を実行しないでください。

- 更新処理を中断しないでください。

- ストレージ・サーバーをpatchmgrユーティリティ起動システムとして使用する必要がある場合は、更新のステージング領域として/opt/oracleを使用しないでください。このようにすると、更新が失敗し、ストレージ・サーバーが破損します。ステージング領域として/tmpディレクトリを使用してください。つまり、更新のファイルを/tmpに解凍します。

- 更新処理中に、ストレージ・サーバーは必要に応じて自動的に再起動します。更新の適用中に、ストレージ・サーバーを再起動したり、電源を入れ直さないでください。

- 書込み可能モードでログ・ファイルを編集したり、開かないでください。ログは、view、less、more、tailのいずれを使用しても表示できます。更新中にログ・ファイルを編集した場合には、更新処理が中断することがあります。

- patchmgrセッションの終了時、patchmgr.stdoutログ・ファイルは個々のストレージ・サーバー・ログ・ファイルに分かれ、それぞれcell_name.logという形式で名前が付与されます。また、/var/log/cellosの内容が非アクティブなセル・パーティションから/var/log/cellos/inactive_partitionディレクトリにコピーされます。非アクティブなパーティションの場所を特定するには、次のコマンドを使用します。

[root@dm01 ]# ./imageinfo -inactive -sys

更新の実行例:

Exadataデータベース・サーバーからrootとしてローリング方式で更新を実行するには、次のようにします。

[root@dm01 ]# ./patchmgr -cells ~/cell_group -patch -rolling -smtp_from "sender@somedomain.com" -smtp_to receiver@somedomain.com

Exadata以外のデータベース・サーバーからroot以外のユーザーとして非ローリング方式で更新を実行するには、次のようにします。

[oracle@nonExadataHost ]$ ./patchmgr -cells ~/cell_group -log_dir auto -patch -smtp_from "sender@somedomain.com" -smtp_to "receiver@somedomain.com"

更新の完了後、-cleanupオプションを使用してストレージ・サーバーをクリーン・アップし、すべての一時的な更新ファイルまたはロールバック・ファイルをクリーン・アップします。このオプションでは、失効した更新状態とロールバック状態をクリーン・アップし、ストレージ・サーバー上で最大1.5GBのディスク領域をクリーン・アップします。このオプションは、更新ユーティリティの停止した実行または失敗した実行を再試行する前に使用してください。詳細は、手順8を参照してください。

5.4.5 Exadataストレージ・サーバーに対する更新のロールバック

更新したExadataストレージ・サーバーをロールバックできるのは、それが正常に更新されている場合のみです。つまり、imageinfoコマンドがアクティブ・イメージ・ステータスにsuccessを返す必要があります。更新が不完全か失敗したストレージ・サーバーはロールバックできません。ロールバックは、ローリング方式または非ローリング方式で行うことができます。

1. 次のコマンドで、ストレージ・サーバーがロールバックされるバージョンおよびflashCacheMode設定をチェックします。

[root@dm01 ]# dcli -l root -g cell_group imageinfo -ver -inactive

[root@dm01 ]# dcli -l root -g cell_group cellcli -e 'list cell attributes flashCacheMode

注意:

ライトバック・フラッシュ・キャッシュを有効にした状態でストレージ・サーバーをリリース11.2.3.2.0よりも前のリリースにロールバックする必要がある場合は、ロールバック・アクションを実行する前に、フラッシュ・キャッシュをwritethroughフラッシュ・キャッシュに変換する必要があります。My Oracle Supportノート1500257.1のスクリプトを使用して、ライトバック・フラッシュ・キャッシュ無効にしてください。リリース11.2.3.2.0以上にロールバックされるストレージ・サーバーは、現在設定されているフラッシュ・キャッシュ・モードを保持します。

2. 次のコマンドを使用して、ロールバックの前提条件をチェックします。

[root@dm01 ]# ./patchmgr -cells cell_group -rollback_check_prereq [-rolling]

3. ロールバックを実行します。
rootとして非ローリング方式でロールバックを実行する例:

[root@dm01 ]# ./patchmgr -cells ~/cell_group -rollback

root以外のユーザーとしてローリング方式でロールバックを実行する例:

[oracle@nonExadataHost ]#./patchmgr -cells ~/cell_group -rollback -log_dir auto

注意:

以前のイメージにロールバックするときには、ファームウェア更新はロールバックされません。ロールバックした後、必要に応じて、次のコマンドを実行し、より古いバージョンのファームウェアを適用します。

/etc/init.d/lsidiag stop

/etc/init.d/lsi_mrdsnmpd stop

/opt/oracle.cellos/CheckHWnFWProfile -action updatefw -mode exact

4. -cleanupオプションを使用してExadataストレージ・サーバーをクリーン・アップし、すべての一時的な更新ファイルまたはロールバック・ファイルをクリーン・アップします。このオプションでは、失効した更新状態とロールバック状態をクリーン・アップし、Exadataストレージ・サーバー上で最大1.5GBのディスク領域をクリーン・アップします。このオプションは、patchmgrユーティリティの停止した実行または失敗した実行を再試行する前に使用してください。

[root@dm01 ]# ./patchmgr -cells cell_group -cleanup

5.4.6 Exadataストレージ・サーバー更新の監視、検証およびトラブルシューティング

更新対象のExadataストレージ・サーバーを監視する方法として、電子メール・アラートを使用することをお薦めします。これらのアラートを設定するには、更新ユーティリティで-smtp_fromフラグおよび-smtp_toフラグに電子メール・アドレスを指定します。

トラブルシューティングのために必要となった場合には、別のターミナル・セッションまたはターミナル・ウィンドウからless -rf patchmgr.stdoutを使用して更新アクティビティを監視して、更新ユーティリティが出力した未加工のログの詳細を表示できます。

また、ストレージ・サーバーのアクティビティを監視することもでき、そのためには、更新ユーティリティが起動した5分後に、更新対象の個々のストレージ・サーバーのシリアル・コンソールまたはWebベースのILOMコンソールにログインします。5分待つと、更新ユーティリティがILOMをリセットする時間を確保できます。ILOMをリセットすると、WebベースのILOMコンソールおよびシリアル・コンソールから切断されます。ILOMがリセットされた後、再接続できます。5分待つことによって、再接続する必要がなくなります。ILOMの更新中には接続が失われ、再接続が必要になります。ILOMには、更新アクションが表示されません。必要に応じて、プロセスが正しく進行していることを確認できるように、通常のセル起動や再起動やその他のアクティビティを監視すると有用です。

patchmgrユーティリティが完了した後、次のように更新ステータスを検証します。

各セルでimageinfoコマンドおよびimagehistoryコマンドを使用して、イメージ・ステータスおよび履歴をチェックします。高容量ドライブまたは高パフォーマンス・ドライブを使用するシステムに対する更新が正常に完了すると、次のような出力が表示されます。

Kernel version: 2.6.39-400.281.1.el6uek.x86_64 #1 SMP Fri Jun 17 20:10:16 PDT 2016 x86_64
Cell version: OSS_12.1.2.3.2_LINUX.X64_160721
Cell rpm version: cell-12.1.2.3.2_LINUX.X64_160721-1.x86_64

Active image version: 12.1.2.3.2.160721
Active image kernel version: 2.6.39-400.281.1.el6uek
Active image activated: 2016-07-21 13:04:34 -0500
Active image status: success
Active system partition on device: /dev/md5
Active software partition on device: /dev/md7

Cell boot usb partition: /dev/sdac1
Cell boot usb version: 12.1.2.3.2.160721

Inactive image version: 12.1.2.3.1.160411
Inactive image activated: 2016-04-11 19:58:28 -0700
Inactive image status: success
Inactive system partition on device: /dev/md6
Inactive software partition on device: /dev/md8

Inactive marker for the rollback: /boot/I_am_hd_boot.inactive
Inactive grub config for the rollback: /boot/grub/grub.conf.inactive
Inactive kernel version for the rollback: 2.6.39-400.128.21.el5uek
Rollback to the inactive partitions: Possible

Extreme Flashドライブを使用するシステムに対する更新が正常に完了すると、同様の出力が表示されますが、USBのパスが異なります。

Kernel version: 2.6.39-400.281.1.el6uek.x86_64 #1 SMP Fri Jun 17 20:10:16 PDT 2016 x86_64
Cell version: OSS_12.1.2.3.2_LINUX.X64_160721
Cell rpm version: cell-12.1.2.3.2_LINUX.X64_160721-1.x86_64

Active image version: 12.1.2.3.2.160721
Active image kernel version: 2.6.39-400.281.1.el6uek
Active image activated: 2016-07-21 13:04:34 -0500
Active image status: success
Active system partition on device: /dev/md5
Active software partition on device: /dev/md7

Cell boot usb partition: /dev/sda1
Cell boot usb version: 12.1.2.3.2.160721

Inactive image version: 12.1.2.3.1.160411
Inactive image activated: 2016-04-11 19:58:28 -0700
Inactive image status: success
Inactive system partition on device: /dev/md6
Inactive software partition on device: /dev/md8

Inactive marker for the rollback: /boot/I_am_hd_boot.inactive
Inactive grub config for the rollback: /boot/grub/grub.conf.inactive
Inactive kernel version for the rollback: 2.6.39-400.128.21.el5uek
Rollback to the inactive partitions: Possible

関連トピック

- Exadataストレージ・サーバーの更新の実行

5.5 Exadata InfiniBandスイッチ・ファームウェアの更新

InfiniBandスイッチを更新およびダウングレードするには、ストレージ・サーバー更新に付属している同じ更新ユーティリティを使用します。更新ユーティリティを使用できる最小スイッチ・ファームウェア・リリースは1.3.3-2です。スイッチのファームウェアは、常にローリング形式で更新します。

注意:

InfiniBandスイッチ・ファームウェアの更新に使用されるpatchmgrは、Exadataデータベース・サーバー・ソフトウェア更新に使用されるものとは異なります。

5.5.1 InfiniBandスイッチ・ファームウェア更新の準備

ラックにスパイン・スイッチが存在する場合は、それを最初に更新する必要があります。ラックにスパイン・スイッチが存在しない場合は、まずサブネット・マネージャが実行されているスイッチを更新します。スイッチでサブネット・マネージャが実行されていない場合は、任意の順序で更新を実行できます。

InfiniBandスイッチを更新するには、スイッチのファームウェアがリリース1.3.3-2以上である必要があります。スイッチのファームウェアがそれより前のリリースである場合は、My Oracle Supportノート888828.1の説明に従って、ファームウェアをリリース1.3.3-2に更新します。InfiniBandスイッチが実行しているソフトウェアのバージョンを特定するには、versionコマンドを使用します。

1. rootユーザーによるスイッチへのSSHアクセスが可能なExadataデータベース・サーバーにrootユーザーとしてログインします。データベース・サーバーは、スイッチと同じInfiniBandネットワークに属している必要があります。

2. スイッチのバージョンを特定します。

[root@dbm01-ibs0 ~]# version

SUN DCS 36p version: 2.1.8-1
Build time: Sep 18 2015 10:26:47
SP board info:
Manufacturing Date: 2015.07.01
Serial Number: "NCDLD0049"
Hardware Revision: 0x0200
Firmware Revision: 0x0000
BIOS version: SUN0R100
BIOS date: 06/22/2010

3. データベース・サーバーに適切なパッチ・ファイルをダウンロードします。パッチ情報は、My Oracle Supportノート888828.1を参照してください。

4. 更新を解凍します。ファイルは、patch_release.date>ディレクトリに解凍されます。

5. ファイルを作成し、更新する必要があるすべてのInfiniBandスイッチを1行に1スイッチずつリストします。ラック内のスイッチを識別するには、ibswitchesコマンドを使用します。他のExadata以外のエンジニアド・システムからのスイッチが同じファブリックに表示される場合がありますが、現時点では更新する必要がない可能性もあることに注意してください。次に、ibswitchesを実行した後に作成されるファイルの例を示します。

[root@dm01 ]# cat ibswitches.lst
myibswitch-01
myibswitch-02

注意:

ファイル名を指定しない場合、コマンドの実行対象は、ibswitchesコマンドを実行することによってこのホストから検出されたすべてのInfiniBandスイッチとなります。

6. <patch_release.date>ディレクトリに移動します。

7. 前提条件チェックを実行します。

[root@dm01 ]# ./patchmgr -ibswitches ibswitches.lst -upgrade -ibswitch_precheck [-force] [-unkey]

注意:

- -unkeyオプションは、終了する前に、InfiniBandスイッチへのパスワードなしのSSHアクセスを削除します。

- -forceオプションを指定すると、InfiniBandトポロジの障害とサーバーからスイッチへの接続がオーバーライドされます。スイッチのアップグレードには影響しません。

コマンドの出力で全体的なステータスがSUCCESSになった場合は、アップグレードに進みます。コマンドの出力で全体的なステータスがFAILになった場合は、出力でエラーのサマリーを確認し、どのチェックが失敗したかを特定して、エラーを修正します。すべてのエラーを修正した後、前提条件チェックを再実行し、成功するまでこれを繰り返します。

関連トピック

- Exadata Database MachineおよびExadata Storage Serverのサポートされているバージョン(My Oracle SupportのドキュメントID 888828.1)

- SSH等価の設定

5.5.2 InfiniBandスイッチ・ファームウェア・ソフトウェアの更新

次のコマンドを使用して、スイッチを更新します。

[root@dm01 ]# ./patchmgr -ibswitches ibswitches.lst -upgrade [-force] [-unkey]

5.5.3 InfiniBandスイッチ・ファームウェア・ソフトウェアのダウングレード

ファームウェアをダウングレードすると、Exadataストレージ・サーバー更新に付属している、より古いファームウェア更新が再適用されます。つまり、ストレージ・サーバー更新にはどのリリースにダウングレードできるかが定義されています。これはリリースごとに異なることがあり、更新前に使用していたファームウェアではない場合があります。更新先のリリースに付属している、より古いファームウェアの詳細は、パッチのREADMEを参照してください。

InfiniBandスイッチ・ファームウェアをダウングレードするコマンドの例:

[root@dm01 ]# ./patchmgr -ibswitches ibswitches.lst -downgrade -ibswitch_precheck [-force] [-unkey]

[root@dm01 ]# ./patchmgr -ibswitches ibswitches.lst -downgrade [-force] [-unkey]

5.6 SSH等価の設定

Exadata Database Machine上でソフトウェアを更新する前に、SSH等価を構成する必要があります。

Oracle LinuxまたはOracle Solarisを実行している任意のサーバーからrootユーザーまたはroot以外のユーザーとしてExadataデータベース・サーバーおよびExadataストレージ・サーバーのExadata更新ユーティリティを実行できます。ターゲットのExadataサーバーのrootユーザーに対してSSH等価が設定されているかぎり、ユーティリティでは任意のExadataサーバーで前提条件チェック、更新、ロールバックの各アクションを実行できます。

1. cell_groupまたはdbs_groupという名前のファイルを作成し、更新するストレージ・サーバーまたはデータベース・サーバーのそれぞれについて、ストレージ・サーバーまたはデータベース・サーバーのホスト名またはIPアドレスを1行に1つずつ記載します。

2. 既存のSSH等価がないかどうかを確認します。
次のコマンドでは、パスワードを求められることはなく、ユーザーによる操作も必要ありません。cell_groupファイルに記載されたホスト名のリストを返します。

[oracle@nonExadataHost ]# ./dcli -g cell_group -l root 'hostname -i'

3. SSH等価をまだ設定していない場合には、起動サーバーから設定します。
root SSH等価がすでにある場合は、この手順を実行しないでください。

次のコマンドを使用して、SSHキーを生成します。

[oracle@nonExadataHost ]# ssh-keygen -t dsa

rootユーザーのSSHキーが作成されるように、デフォルト値をそのまま使用します。

4. SSHキーをプッシュしてSSH等価を設定します。
プロンプトが表示されたら、rootのパスワードを入力します。

[oracle@nonExadataHost ]# dcli -g cell_group -l root –k

注意:

安全な環境を構築しているお客様の場合、Exadataストレージ・サーバーへのSSHアクセスを無効にしていることがあります。通常の操作中に、Exadataストレージ・サーバーがSSHアクセスを必要とすることはありません。一方、更新ユーティリティなどの管理用ユーティリティでは、SSHアクセスを必要とします。ストレージ・サーバーのロック解除の詳細は、Oracle Exadata Storage Server Softwareユーザーズ・ガイドのストレージ・サーバーでのSSHの無効化 の項のサブセクション、セルの一時的なロック解除を参照してください。

5.7 Exadataデータベース・サーバーの依存性問題が原因で失敗した前提条件チェックのトラブルシューティング

カスタムrpmがインストールされているExadataデータベース・サーバーで前提条件チェックまたは更新を実行すると、競合によって前提条件チェックまたは更新が失敗する場合があります。

前提条件チェックまたは更新を行うときに、更新ユーティリティは2つの依存性チェックを実行します。Minimum依存性に対するチェックと、Exact依存性に対するチェックです。

依存性の失敗をトリアージするには、ログ・ファイルを調べます。これは、ターゲットのExadataデータベース・サーバー上のdbnodeupdate.logである場合と、更新ユーティリティ(patchmgr)の起動元のログ・ディレクトリにある<hostname>_dbnodeupdate.logである場合があります。

ログ・ファイルで各実行の先頭を特定するには、zzzで始まる行を検索します。次に例を示します。

zzz - /u01/patches/YUM/dbnodeupdate.sh called with arguments -u -l
/u01/patches/YUM/p23564643_121232_Linux-x86-64.zip -v -N at  2016-08-23 23:31:54

日付スタンプは、調査対象の実行の時間と一致する必要があります。各実行は一意のrunidで識別され、これは、次のように、同じログ・ファイルの各実行の先頭に出現することもあります。

[1472009516][2016-08-23 23:31:59 -0400][INFO][/u01/patches/YUM/dbnodeupdate.sh][InitLogfile][]  # dbnodeupdate.sh script rel.
: 5.160809 started at  (runid :230816233155)

カスタムrpmがある場合は、固有の実行のdiagファイルを調べると、それをチェックすることもできます。diagファイルはrunidで識別され、ターゲットのExadataデータベース・サーバー上の/var/log/cellosか、更新ユーティリティを駆動しているディレクトリにあります。この例では、ファイル名はdbnodeupdate.230816233155.diagになっています。そのファイルで、RunDetectCustomRpmsShおよびrpm -qa --qf "%{n}-%{v}-%{r}.%{arch}\nというヘッダーのセクションを探します。インストール済の(追加の)パッケージがある場合は、それに関する詳細を確認できます。

ログ・ファイルで、MinimumおよびExact依存性チェックの結果について、開始(zzz)から下方向にExact dependencies (大文字小文字が区別されます)を検索します。この場合、次のようになっています。

Exact dependencies     : Will fail on a next update
Minimum dependencies   : Will fail on a next update

Minimum依存性チェックにパスするかぎり、更新または前提条件チェックは失敗しません。MinimumとExactの両方の依存性が失敗した場合は、エラーの原因を特定する必要があります。

エラーの原因となっている依存性を見つけるには、[ExecUpgrade][] Performing yum package dependencyを検索します。ここが、YUM実行(通常はテスト実行が先)が行われる場所です。依存性問題があるときには、Error:で始まるYUMメッセージが表示されます。次に例を示します。

--> Finished Dependency Resolution
Error: Package: krb5-devel-1.10.3-33.el6.x86_64 (@ol6_latest)
Requires: krb5-libs = 1.10.3-33.el6
Removing: krb5-libs-1.10.3-33.el6.x86_64 (installed)
krb5-libs = 1.10.3-33.el6
Updated By: krb5-libs-1.10.3-42z1.el6_7.x86_64 (exadata_generated_160616114412)
krb5-libs = 1.10.3-42z1.el6_7
You could try using --skip-broken to work around the problem

この例のエラー・メッセージによると、krb5-devel-1.10.3-33.el6.x86_64 (krb5-devel)パッケージはExadata以外のチャンネル(ol6_latest)からインストールされています。このkrb5-develパッケージは、krb5-libsに依存しています。ただし、このExadata更新ではkrb5-libsパッケージを使用できません。krb5-develを更新しないでkrb5-libsを更新することはできないため、依存性チェックは失敗します。krb5-develの新規バージョンがExadata更新に含まれていないため、パッケージは事前更新するか削除する必要があります。事前更新とは、Exadata更新を実行する前に個々のパッケージを手動で更新することです。これを行うには、rpm -Uvh <package-name>コマンドを使用します。

カスタム・パッケージを削除することをお薦めします。次のrpmコマンドを使用してください。

[root@dm01 ]# rpm –e krb5-devel

エラーの原因となっているrpmを削除した後、更新または前提条件チェックを再起動します。

関連トピック

- 前提条件チェックの実行

5.8 Exadataデータベース・サーバーでのmultilib問題のトラブルシューティング

アーキテクチャの異なるカスタム・パッケージがデータベース・サーバーにインストールされている場合は、Exadataデータベース・サーバーの依存性問題が原因で失敗した前提条件チェックのトラブルシューティングで説明しているものと同様の問題が発生することがあります。このことは、通常、i686パッケージがExadataデータベース・サーバーにインストールされている場合に発生します。

注意:

64ビット(x86_64)以外のパッケージもサポートされていますが、32ビット・ソフトウェアは使用しないことをお薦めします。サード・パーティが提供する特定の機能が必要になったときには、64ビット・バージョンを要求することをお薦めします。

通常、Exadataブランドのx86_64ビットrpmはExadata更新で更新されます。ただし、アーキテクチャがx86_64ビットでない、同様のパッケージをインストールしていた場合、更新ユーティリティは64ビット・パッケージを更新できません。ログ・ファイルに次のエラーが示されます。

--> Finished Dependency Resolution
Error:  Multilib version problems found. This often means that the root
cause is something else and multilib version checking is just
pointing out that there is a problem. Eg.:

1. You have an upgrade for libuuid which is missing some
dependency that another package requires. Yum is trying to
solve this by installing an older version of libuuid of the
different architecture. If you exclude the bad architecture
yum will tell you what the root cause is (which package
requires what). You can try redoing the upgrade with
--exclude libuuid.otherarch ... this should give you an error
message showing the root cause of the problem.

2. You have multiple architectures of libuuid installed, but
yum can only see an upgrade for one of those arcitectures.
If you don't want/need both architectures anymore then you
can remove the one with the missing update and everything
will work.

3. You have duplicate versions of libuuid installed already.
You can use "yum check" to get yum show these errors.

...you can also use --setopt=protected_multilib=false to remove
this checking, however this is almost never the correct thing to
do as something else is very likely to go wrong (often causing
much more problems).

Protected multilib versions: libuuid-2.17.2-12.24.0.1.el6.x86_64 != libuuid-2.17.2-12.18.0.1.el6.i686

rpm –e <package_name.i686>を実行して、i686またはi386パッケージを削除することが、multilib問題の解決策となります。

6 DBMCLIユーティリティの使用

この章では、Oracle Exadata Database Machineコマンドライン・インタフェース(DBMCLI)ユーティリティをOracle Exadata Database Machineで使用する方法を説明します。DBMCLIには、スクリプト・ファイルの使用を含む、SQL*Plusで提供される機能の多くが用意されています。この章のトピックは、次のとおりです:

- DBMCLIユーティリティの概要

- DBMCLIの管理コマンドについて

- DBMCLIのオブジェクト・コマンドについて

- DBMCLIのオブジェクト・タイプについて

- DBMCLIのオブジェクト属性

- メトリックを使用したデータベース・サーバーの監視

- DBMCLIコマンド・リファレンス

6.1 DBMCLIユーティリティの概要

DBMCLIユーティリティは、データベース・サーバーの構成およびサーバー環境内のデータベース・サーバーの管理に使用するコマンドライン管理ツールです。DBMCLIをそれぞれのサーバーで実行すると、個別のデータベース・サーバーを構成できます。DBMCLIを使用して、サーバーの開始および停止、サーバー構成情報の管理、およびサーバーの有効化または無効化が可能です。このコマンドライン・ユーティリティは、Oracle Exadata Database Machineの出荷時にインストール済です。この項では、次の項目について説明します。

- DBMCLIの起動

- DBMCLIのコマンド構文およびオプションの理解

- 予約語

- DBMCLIのコマンドライン編集

- DBMCLIの入力および出力オプション

- DBMCLIスクリプトのコメント

- DBMCLIコマンドの行継続文字

6.1.1 DBMCLIの起動

DBMCLIは、管理するデータベース・サーバーでオペレーティング・システムのコマンドラインから起動できますが、ネットワーク接続されたクライアントからSecure Shell (SSH)を使用してリモートで起動することもできます。コマンドライン構文は次のとおりです。

dbmcli [port_number] [-n] [-m] [-xml] [-v | -vv | -vvv] [-x] [-e command]

このコマンドのport_numberでは、データベース・サーバーのHTTPポート番号を指定します。port_number引数を省略した場合は、データベース・サーバーのcellinit.oraファイルのHTTP_PORT変数に割り当てられた値がDBMCLIユーティリティで使用されます。ファイルは、/opt/oracle/dbserver/dbms/deploy/config/ディレクトリにあります。cellinit.oraファイルにHTTP_PORT変数が設定されていない場合、ポート番号はデフォルトで8888に設定されます。

次の表に、DBMCLIコマンドで使用できるオプションを示します。

オプション

説明

-n

DBMCLIユーティリティを非対話型モードで実行します。このオプションでは、コマンド・プロンプトが非表示になり、コマンドライン編集機能が無効になります。

-m

DBMCLIを監視モード(読取り専用)で実行します。

-xml

出力をOracle Enterprise Manager用のXML形式で表示します。

-v、-vvおよび-vvv

ログ・レベルを設定します。-vオプションは普通のレベル、-vvは詳細なレベル、-vvvは最も詳細なレベルになります。

-x

バナーを抑止します。

-e command

指定されたDBMCLIコマンドを実行します。DBMCLIはコマンドの実行後に終了します。次に例を示します。

$ dbmcli -e list dbserver detail
$ dbmcli -e "list dbserver attributes name where name   -
like '.*dbm01'"

DBMCLIでは、データベース・サーバーのオペレーティング・システム認証を使用します。DBMCLIには、ログイン・パラメータや接続コマンドはありません。DBMCLIが起動されるディレクトリは、DBMCLIのSPOOLおよびSTARTコマンドでのファイル・アクセスに制限がないデフォルト・ディレクトリです。

関連項目:

offloadEfficiency属性の詳細は、「DESCRIBE DBSERVER」を参照してください。

6.1.2 DBMCLIのコマンド構文およびオプションの理解

DBMCLIの構文は次のとおりです。

{admin-command | object-command object} [options] ;

この構文では、次の引数が使用されます。

- admin-commandは管理アクションです。

- object-commandは、オブジェクトで実行されるアクションです。

- objectは、コマンドでアクションを実行するオブジェクトまたはターゲットです。

- optionsは、コマンドの追加パラメータを使用できるようにコマンドの組合せの使用範囲を拡大します。

DBMCLIユーティリティを使用する場合は、次のルールが適用されます。

- コマンド、オブジェクトおよびオプションは、LIKE演算子のフィルタ文字列で使用される文字列パターンなど、明示的に指定されている場合を除き、大/小文字は区別されません。

- 空白または記号を含むオブジェクトの名前は、一重引用符または二重引用符で囲みます。引用符を使用する場合は、開始と終了の引用符を同じにします。たとえば、"this is incorrect'は、最初の引用符が二重引用符で2番目の引用符が一重引用符のため正しくありません。

- 現在のローカル・データベース・サーバーは、すべてのDBMCLIコマンドが適用されるデータベース・サーバーです。

- DBMCLIコマンドの最後のセミコロン(;)は省略可能です。

- 長いコマンドで次の行にまたがる場合は、行の最後でハイフン(-)を使用します。

関連項目:

- DBMCLIの管理コマンドについて

- DBMCLIのオブジェクト・コマンドについて

- DBMCLIのオブジェクト・タイプについて

6.1.3 予約語

DBMCLIの予約語は次のとおりです。

ALERTDEFINITION
ALERTHISTORY
ALL
ALTER
BMC
CONFIGUREBMC
CREATE
DESCRIBE
DETAIL
DROP
FORCE
LED
LIST
LUN
MAIL
MEMORY
METRICDEFINITION
METRICCURRENT
METRICHISTORY
MS
NULL
OFF
ON
PHYSICALDISK
RESTART
RS
SHUTDOWN
SNMP
STARTUP
THRESHOLD
VALIDATE

これらのキーワードをコマンドの値として使用する場合は、引用符で囲む必要があります。

6.1.4 DBMCLIのコマンドライン編集

DBMCLIユーティリティでは、コマンドラインの履歴および編集をサポートしています。この機能は、BSD editlineおよびGNU readline機能に似ています。DBMCLIのコマンド編集機能のほとんどは、bashやtcshなどの最新のシェルに似ています。

6.1.5 DBMCLIの入力および出力オプション

データベースのコマンドライン・ユーティリティでは、標準入力からコマンドを読み取り、標準出力に出力を書き込みます。ホスト・オペレーティング・システムのオプションを使用すると、入力および出力をリダイレクトしてコマンド・スクリプトを構成および処理できます。たとえば、次のリダイレクションを実行できます。

$ dbmcli < command-script-in  > results-out

この例では、command-script-inファイルのDBMCLIコマンドからの出力がresults-outファイルに書き込まれます。

6.1.6 DBMCLIスクリプトのコメント

複数の書式を使用して1行コメントをDBMCLIスクリプトに追加できます。コメント行を開始するには、先頭にREMARK,REMまたは--(ハイフン2つ)を付けます。

たとえば、次の行はコメントとして有効な構文です。

REMARK This is a comment
REM This is a comment
-- This is a comment

6.1.7 DBMCLIコマンドの行継続文字

コマンドが長く次の行にまたがる場合は、行の最後にハイフン(-)を挿入します。次に、[Enter]を押してコマンド入力を続行します。

次に例を示します。

DBMCLI> LIST dbserver WHERE name LIKE '*.dbm04' -
attributes name, status, comment

6.2 DBMCLIの管理コマンドについて

DBMCLI管理コマンドでは、オブジェクトに対して直接アクションが実行されることはありません。

DBMCLIでは、次の管理コマンドを使用します。

- HELP

- SET

- SPOOL

- START

注意:

データベース・サーバーですべてのサービスを実行するには、dbmadminユーザーを使用する必要があります。dbmmonitorユーザーは監視用です。dbmmonitorユーザーは、次のコマンドを実行できます。

- DESCRIBE

- EXIT

- HELP

- LIST

- REMARK

- SET

- START

6.3 DBMCLIのオブジェクト・コマンドについて

DBMCLIには、オブジェクト・コマンド、オブジェクト・タイプおよびオブジェクト属性があります。

Oracle Databaseのオブジェクトで動作するDBMCLIコマンドは次のとおりです。

- ALTER

- CREATE

- DESCRIBE

- DROP

- LIST

関連トピック

- DBMCLIコマンド・リファレンス

6.4 DBMCLIのオブジェクト・タイプについて

表6-1は、DBMCLIオブジェクト・コマンドで扱うことができるOracle Exadata Storage Server Softwareのオブジェクト・タイプを示しています。

表6-1 Oracle Exadata Storage Server Softwareのオブジェクト・タイプ

オブジェクト・タイプ

説明

ALERTDEFINITION

アラート定義では、データベース・サーバーで生成可能なすべてのアラートの定義が提供されます。アラートはメトリックおよびその他のアラートのソースで定義されます。

ALERTHISTORY

アラート履歴では、データベース・サーバーで発生したアラートのリストが提供されます。

DBSERVER

現行のデータベース・サーバーまたはローカル・データベース・サーバー。

IBPORT

データベース・サーバーのInfiniBandポート。

LUN

論理ユニット番号(LUN)は、物理ディスク・デバイスのRAIDセットに対するアドレスです。

LUNは、サーバーの起動時に自動的に検出されます。LUNは、ディスクを最初に作成した際、またはシステムの再起動後にディスクが検出された際に、対応するディスクに割り当てられます。ディスクに未割当てのLUNは、NULL値です。

METRICCURRENT

現在のメトリックは、各メトリックの現在値の観測データのセットです。

METRICDEFINITION

メトリック定義は、メトリックの構成です。

METRICHISTORY

メトリック履歴は、すべてのメトリック値の過去の各観測データを収集したものです。

PHYSICALDISK

ディスクは、サーバー上の物理ディスクと呼ばれます。

THRESHOLD

しきい値は、特定のメトリックに基づいてステートフル・アラートを生成するためのルールです。このルールでは、境界値(しきい値)が設定され、メトリック値がこれらの境界値を超えた場合にアラートが生成されるまでの時間が設定されます。

コマンド・オブジェクトには、組み合せることができないものがあります。コマンド・オブジェクトの有効な組合せについては、それぞれのオブジェクト・コマンドの構文を確認してください。

6.5 DBMCLIのオブジェクト属性

DBMCLIの各オブジェクトには、オブジェクトの作成時または変更時に割り当てられる属性のセットがあります。属性フィルタおよびリストは、LISTコマンドの出力に表示される属性およびオブジェクトの指定に使用されます。

属性はすべて表示できますが、ユーザー側で直接変更できるのは一部の属性のみです。属性のリストを表示して、変更可能な属性を確認するには、DESCRIBEコマンドを使用します。

関連トピック

- LIST

- DESCRIBE

6.5.1 共通の属性値の制限

DBMCLIの複数のオブジェクトに共通する属性の値には、次の制限が適用されます。

- name属性の値は256文字未満にし、次のASCII文字(英数字およびアンダースコア)のみで構成する必要があります。

- 小文字の英字(aからz)

- 大文字の英字(AからZ)

- 数字(0から9)

- アンダースコア(_)

- comment属性の値は256文字未満にする必要があります。

属性値の追加の制限については、DBMCLIの各コマンドの構文を参照してください。

6.5.2 LISTコマンドの属性リスト

LISTコマンドで表示する属性は、次のオプション句で指定できます。

ATTRIBUTES { ALL | attribute1 [, attribute2] ... }

ALLを指定すると、LISTオブジェクトで組合せ可能なすべてのオブジェクト属性が表示されます。

6.5.3 LISTコマンドの属性フィルタ

LISTコマンドで表示するオブジェクトは、次のオプション句を使用して指定できます。

WHERE attribute-filter1 [AND attribute-filter2] ...

各attribute-filterNには、次の構文が含まれます。

attribute [ NOT | !] operator comparison_value

この構文では、次の引数が使用されます。

- operator: サポートされる演算子を表6-2に示します。これらの演算子は、NOTまたは!と組合せ可能です。

表6-2 属性フィルタでサポートされる演算子

演算子

説明

=

文字列、ステータスまたは数値の属性間の等号をテストします。次に例を示します。

status NOT = normal

>

数値属性より大きい値かどうかをテストします。次に例を示します。

size > 139920M

<

数値属性より小さい値かどうかをテストします。次に例を示します。

freeSpace !< 100M

LIKE

大/小文字を区別する一致を使用して、正規表現が文字列属性に一致するかどうかをテストします。次に例を示します。

LIKE 'GD_IO_RQ.*'

- comparison_value: サポートされる演算子で使用される場合、comparison_valueは次の値タイプのいずれかです。

- 数値

- リテラル: activeやnormalなどの値

- 日時: ALERTHISTORYでのみサポートされる時間値

- 文字列: 一重引用符('')または二重引用符(" ")で区切られる値

- NULL: 未割当ての文字列または空のリスト

6.6 メトリックを使用したデータベース・サーバーの監視

メトリックを表示することにより、データベース・サーバーを監視できます。メトリックには次のタイプがあります。

- cumulative: メトリックが作成されてからの統計。

- instantaneous: メトリックが収集される時点の値。

- rate: 特定の時間の統計を平均して計算される値。

この項では、次の項目について説明します。

- メトリックについて

- メトリックの表示

- データベース・サーバーのメトリック

6.6.1 メトリックについて

メトリックは、CPUなど、データベース・サーバーとそのコンポーネントの重要なランタイム・プロパティまたは内部のインスツルメンテーション値を観測して記録したものです。メトリックは、一定間隔で計算されてメモリーに保存される一連の測定値で、永続的な履歴としてディスクに格納されます。

通常、メトリック値では、特定の観測期間における累計カウンタの絶対値または累計カウンタの増減率を記録します。一部のメトリックは、状態遷移の時間の記録にも使用されます。

メトリック値としきい値を比較することにより、メトリック値がしきい値を超えた場合にアラートを送信できます。メトリックの極端な値が、管理者に注意を促す問題またはその他のイベントを示す場合、メトリックを警告およびクリティカルのしきい値に関連付けることができます。

6.6.2 メトリックの表示

DBMCLIのLISTコマンドを使用すると、データベース・オブジェクトのメトリックを表示および監視できます。LISTコマンドを使用して、メトリック定義、現在のメトリック、およびメトリック履歴を表示できます。

例6-1は、LIST METRICHISTORYコマンドにname属性およびmetrictype属性を指定した場合とその出力を示しています。

例6-1 特定の属性でのMETRICHISTORYの表示

LIST METRICHISTORY ATTRIBUTES name, metrictype
DS_BBU_CHARGE           Instantaneous
DS_BBU_TEMP             Instantaneous
DS_CPUT                 Instantaneous
DS_CPUT_MS              Instantaneous
DS_FANS                 Instantaneous
DS_FSUT                 Instantaneous
DS_MEMUT                Instantaneous
DS_MEMUT_MS             Instantaneous
DS_RUNQ                 Instantaneous
DS_SWAP_IN_BY_SEC       Instantaneous
DS_SWAP_OUT_BY_SEC      Instantaneous
DS_SWAP_USAGE           Instantaneous
DS_TEMP                 Instantaneous
DS_VIRTMEM_MS           Instantaneous
N_HCA_MB_RCV_SEC        Rate
N_HCA_MB_TRANS_SEC      Rate
N_IB_MB_RCV_SEC         Rate
N_IB_MB_TRANS_SEC       Rate
N_IB_UTIL_RCV           Rate
N_IB_UTIL_TRANS         Rate
N_NIC_KB_RCV_SEC        Rate
N_NIC_KB_TRANS_SEC      Rate
N_NIC_NW                Instantaneous

6.6.2.1 メトリック定義の表示

データベース・サーバーのメトリック定義を表示するには、LIST METRICDEFINITIONコマンドを使用します。

メトリック定義のリストには、メトリックの構成が表示されます。例6-2は、METRICDEFINITIONオブジェクトの属性を表示する方法を示しています。

例6-2 メトリック定義の表示

DBMCLI> LIST METRICDEFINITION DS_CPUT DETAIL

DBMCLI> LIST METRICDEFINITION WHERE name LIKE 'DS_SWAP_*' -
ATTRIBUTES name, metricType, description

関連トピック

- DESCRIBE METRICDEFINITION

- LIST METRICDEFINITION

6.6.2.2 現在のメトリックの表示

データベース・サーバーの現行のメトリック値を表示するには、LIST METRICCURRENTコマンドを使用します。

現在のメトリックのリストには、各メトリックの現在値の観測データのセットが表示されます。例6-3は、METRICCURRENTオブジェクトの属性を表示する方法を示しています。

例6-3 現在のメトリック値の表示

DBMCLI> LIST METRICCURRENT DS_FANS DETAIL

DBMCLI> LIST METRICCURRENT WHERE objectType = 'DBSERVER' AND                 -
metricValue != 0 ATTRIBUTES name, metricObjectName,                  -
metricValue, collectionTime

関連トピック

- DESCRIBE METRICCURRENT

- LIST METRICCURRENT

6.6.2.3 メトリック履歴の表示

データベース・サーバーのメトリック履歴を表示するには、LIST METRICHISTORYコマンドを使用します。

メトリック履歴のリストは、すべてのメトリック値の過去の各観測データを収集したものです。例6-4は、METRICHISTORYオブジェクトの属性を表示する方法を示しています。

メトリック履歴ファイルの保存期間は、metricHistoryDays属性で指定されます。この設定は、DBMCLIのALTER DBSERVERコマンドで変更できます。

例6-4 メトリック履歴の値の表示

DBMCLI> LIST METRICHISTORY DS_TEMP WHERE alertState='critical' DETAIL

DBMCLI> LIST METRICHISTORY WHERE objectType = 'DBSERVER' AND metricValue != 0   -
AND collectionTime > '2014-08-12T09:10:51-07:00' -ATTRIBUTES name,      -
metricObjectName, metricValue, collectionTime

関連トピック

- LIST METRICHISTORY

- ALTER DBSERVER

6.6.3 データベース・サーバーのメトリック

データベース・サーバーのメトリックでは、CPU使用率、メモリー、ネットワーク・インターコネクトなど、サーバーに関する情報が提供されます。セル・ディスクのメトリックを表示するには、METRICCURRENTオブジェクト、METRICDEFINITIONオブジェクトおよびMETRICHISTORYオブジェクトでDBSERVERと同等のオブジェクト・タイプ属性を使用します。例6-5は、セルのメトリックを表示する方法を示しています。

表6-6に、データベース・サーバー・メトリックのメトリック名およびその説明を示します。メトリックを表示するデータベース・サーバーは、METRICCURRENTオブジェクトおよびMETRICHISTORYオブジェクトのmetricObjectName属性で指定されます。

表6-3 データベース・サーバーのメトリックおよび説明

メトリック

説明

DS_BBU_CHARGE

ディスク・コントローラのバッテリ充電。

DS_BBU_TEMP

ディスク・コントローラのバッテリの温度。

DS_CPUT

サーバーのCPU使用率(システムCPUがアイドル状態でなくなる直前の1分間のCPU使用率(/proc/statで取得))。

DS_CPUT_MS

MSが使用しているCPU時間の割合(%)。

DS_FANS

サーバーで動作中のファンの回転数。

DS_FSUT

現在使用中のファイル・システムで使用されている合計領域の割合。このメトリックは、サーバーの様々なファイル・システムの領域使用率を示します。

DS_MEMUT

サーバーにおける合計の物理メモリー使用率。

DS_MEMUT_MS

MSが使用している物理メモリーの割合(%)。

DS_RUNQ

running(実行中)またはuninterruptible(無停止)とマークされるLinuxの実行キューの(直前の1分間の)プロセスの平均数(/proc/loadavgで取得)。

DS_SWAP_IN_BY_SEC

1秒当たりの読み取られたスワップ・ぺージのKB数。

DS_SWAP_OUT_BY_SEC

1秒当たりの書き込まれたスワップ・ぺージのKB数。

DS_SWAP_USAGE

使用済のスワップ領域の割合(%)。

DS_TEMP

ベースボード管理コントローラ(BMC)で提供されるサーバーの瞬間温度(摂氏)。

DS_VIRTMEM_MS

MSが使用している仮想メモリー量(MB)。

N_HCA_MB_RCV_SEC

InfiniBandインタフェースが1秒当たりに受信したMB数。

N_HCA_MB_TRANS_SEC

InfiniBandインタフェースが1秒当たりに送信したMB数。

N_IB_MB_RCV_SEC

InfiniBandポートが1秒当たりに受信したメガバイト数。

N_IB_MB_TRANS_SEC

InfiniBandポートが1秒当たりに送信したメガバイト数。

N_IB_UTIL_RCV

データ受信で使用されるInfiniBandポート容量のパーセンテージ。

N_IB_UTIL_TRANS

データ送信で使用されるInfiniBandポート容量のパーセンテージ。

N_NIC_KB_RCV_SEC

イーサネット・インタフェースが1秒当たりに受信したKB数。

N_NIC_KB_TRANS_SEC

イーサネット・インタフェースが1秒当たりに送信したKB数。

例6-5 データベース・サーバーのメトリックの表示

CellCLI> LIST METRICCURRENT DS_CPUT DETAIL

name:                   DS_CPUT
alertState:             normal
collectionTime:         2014-12-17T15:54:25-08:00
metricObjectName:       abcd2x3
metricType:             Instantaneous
metricValue:            6.7 %
objectType:             DBSERVER

6.7 DBMCLIコマンド・リファレンス

DBMCLIには、管理コマンドとオブジェクト・コマンドの両方があります。

DBMCLIユーティリティには次のコマンドがあります。

- ALTER

- CREATE

- DESCRIBE

- DROP

- GRANT

- HELP

- LIST

- REVOKE

- SET

- SPOOL

- START

6.7.1 ALTER

用途

ALTERコマンドは、単一のオブジェクトまたは複数のオブジェクトでアクションを実行したり、それらのオブジェクトの属性を変更したりします。ALTERコマンドは、オブジェクトに対して属性を変更したり、アクションを実行するために使用できます。

構文

ALTER { object_type object_name[, object_name]... operation
| attribute_name = attribute_value
[, attribute_name = attribute_value]...
}

使用上の注意

このコマンドでは、次の引数を使用できます。

- object_typeは次のとおりです。

- ALERTHISTORY

- DBSERVER

- IBPORT

- THRESHOLD

- USER

- object_nameは、アラート履歴、データベース・サーバー、LUNまたはしきい値の名前であるか、識別子です。

- operationは、指定したobject_typeの有効なアクションです。

複数のオブジェクトがALTERコマンドのターゲットである場合は、正常に実行されない場合があります。エラーが発生するとコマンドが中断され、残りのオブジェクトは変更されません。

関連トピック

- DBMCLIのオブジェクト・タイプについて

6.7.1.1 ALTER ALERTHISTORY

用途

ALTER ALERTHISTORYコマンドは、すべてのアラート履歴または指定したアラート履歴の属性を変更します。

構文

ALTER ALERTHISTORY { ALL | alertid1  [,alertid2 ...]}
examinedBy=user_name

使用上の注意

このコマンドでは、次の引数を使用できます。

- alertidn: 変更するアラートの識別子です。

- user_name: アラートを確認したユーザーの名前です。

例

例6-6は、examinedBy属性を更新するためにALERTHISTORYオブジェクトで使用したALTERコマンドを示しています。examinedBy属性は、変更可能な唯一のALERTHISTORY属性です。

例6-6 ALERTHISTORY属性の変更

DBMCLI> ALTER ALERTHISTORY 1671443714 -
examinedBy="jdoe"

DBMCLI> ALTER ALERTHISTORY ALL examinedBy="jdoe"

6.7.1.2 ALTER DBSERVER

ALTER DBSERVERkコマンドは、データベース・サーバーの属性を変更します。

構文

ALTER DBSERVER  {
| SHUTDOWN SERVICES { RS | MS | ALL }
| RESTART SERVICES { RS | MS | ALL }
| RESTART BMC
| STARTUP SERVICES { RS | MS | ALL }
| LED { ON | OFF }
| VALIDATE { MAIL | SNMP | CONFIGURATION }
| VALIDATE SYSLOGCONF facility.priority
| CONFIGUREBMC
| attribute_name = attribute_value
[, attribute_name = attribute_value]...
}

使用上の注意

次の表は、ALTER DBSERVERコマンドの引数およびオプションを示しています。

引数

オプション

説明

SHUTDOWN SERVICES

MS (管理サーバー)

RS (再起動サーバー)

ALL

MSサービスが停止します。

RSサービスが停止します。

ALLオプションでは、MSおよびRSサービスが停止します。

RESTART SERVICES

MS

RS

ALL

MSサービスが停止し、それから開始します。

RSサービスが停止し、それから開始します。

ALLオプションでは、MSおよびRSサービスが停止してから開始します。

RESTART BMC

なし

ベースボード管理コントローラ(BMC)を再起動します。

STARTUP SERVICES

MS

RS

ALL

MSサービスが開始します。

RSサービスが開始します。

ALLオプションでは、MSおよびRSサービスが開始します。

LED

ON

OFF

LED ON操作ではシャーシのLEDを点灯し、LED OFF操作ではシャーシのLEDを消灯します。

データベース・サーバーでメンテナンスが必要になった場合にLEDを点灯するように手動で設定できます。コンポーネントに障害が発生した場合にLEDが自動的に点灯するように設定することもできます。

VALIDATE

MAIL

SNMP

CONFIGURATION

VALIDATE MAIL操作では、データベース・サーバーに設定した電子メール属性を使用して、テスト・メッセージを送信します。

VALIDATE SNMP操作では、データベース・サーバーに設定したSNMP属性を使用して、テスト・メッセージを送信します。VALIDATE SNMP TYPE=ASR操作では、Oracle Exadata Storage ServerでASRを検証します。

VALIDATE CONFIGURATION操作では、構成を検証します。

VALIDATE SYSLOGCONF

facility.priority

VALIDATE SYSLOGCONF facility.priorityでは、指定したfacility(機能)とpriority(重要度)のテスト・メッセージを送信します。

CONFIGUREBMC

なし

管理サーバーでアラートを検出できるように、ローカル・データベース・サーバーにハードウェア・アラートを設定するようBMCを構成します。

属性

ALTER DBSERVERコマンドで変更可能な属性は、例6-32でmodifiableとして示されます。

ALTER DBSERVERコマンドについて、その他の使用方法は次のとおりです。

- 次の場合は、データベース・サーバーを再起動、停止または起動する必要がありません。

- ソフトウェアのアップグレード

- サービス停止(データベース・サーバーがサービス・リクエストに応答していない状態を含む)

- アラート通知を送信するようにデータベース・サーバーを設定する場合、次のデータベース・サーバー属性を構成する必要があります。

- smtpServer

- smtpPort

- smtpUser

- smtpPwd

- smtpUseSSL

- smtpFrom

- smtpFromAddr

- smtpToAddr

- snmpSubscriber

- snmpUser

- snmpEngineID

- notificationMethod

- notificationPolicy

- emailSubscriber

smtpToAddr属性は、アラート通知の受信先のカンマ区切りの電子メール・アドレス・リストに設定できます。このリストは引用符で囲む必要があります。

snmpSubscriber属性は、SNMPアラート通知を送信するSNMPターゲットのリストに設定できます。これらのターゲットは次のように指定されます。

snmpSubscriber=(
(host=host[,port=port][,community=community][,type=user_type][,fromIP="ip"][,asrmPort="ASRManager_port"])
[,(host=host[,port=port][,community=community][,type=user_type][,fromIP="ip"][,asrmPort="ASRManager_port"])] ...)

注意:

- ALTER DBSERVER ... smnpSubscriberコマンドでは、smnpSubscriberに設定されている既存の値を置き換えます。SNMPターゲットのリストを追加するには、既存の値がコマンドに含まれるようにします。コマンドを実行すると、次のメッセージが表示されます。

snmpSubscriber {0} has been replaced with {1}.

- snmpSubscriber属性は自動サービス・リクエストの構成に使用します。

- SNMPアラートは、Oracle Exadata Storage Server Softwareの各インストールに含まれているMIB (管理情報ベース)に準拠しています。データベース・サーバーのMIBファイルは、/opt/oracle/dbserver/dbms/deploy/config/にあります。
タイプASRおよびv3ASRのアラートは、SUB-HW-TRAP-MIB.mibファイルにあるSUN-HW-TRAP-MIBに準拠しています。

その他のアラート・タイプは、cell_alert.mibファイルにあるcell_alert MIBに準拠しています。

SNMPアラートとMIBはSNMPバージョン 1(SNMPv1)に準拠しています。ただし、自動サービス・リクエストのアラートはSNMPバージョン2c(SNMPv2c)に準拠しています。

portのデフォルト値は162です。communityのデフォルト値はpublicです。

notificationMethod属性の値は、mail、snmp、none、またはmailとsnmpの組合せ(notificationMethod='mail,snmp'など)が可能です。デフォルト値はmailです。

snmpSubscriberタイプは、ASR、v3およびv3ASRです。v3およびv3ASRタイプの場合、snmpUserを定義する必要があり、communityのかわりにユーザー名を指定します。

v3ASRタイプの場合、authProtocol=SHAおよびprivProtocol=AESを使用してユーザーを定義する必要があります。ASR Managerによってサポートされるプロトコルはこれらのみです。snmpSubscriberをv3ASRタイプとして設定すると、ILOMによって送信されるトラップのILOMプロパティおよびルールも設定されます。

タイプが指定されない場合、デフォルトはバージョン1、cell_alert trapsです。このタイプを指定する文字列はありません。このタイプを使用するにはタイプ・フィールドを省略してください。

fromIPフィールドで、トラップが送信されるIPアドレスを指定できます。このフィールドが指定されていない場合、デフォルトで、eth0に関連付けられているIPアドレスが設定されます。ASR ManagerにデフォルトのIPアドレスが登録されていない場合は、このフィールドが使用されます。ASR Managerでは、認識しているIPアドレスから送信されたSNMPトラップのみを処理します。

fromIPフィールドは、タイプがASRまたはv3ASRのsnmpSubscribersに対してのみ使用できます。

次に例を示します。

DBMCLI> alter dbserver snmpSubscriber=((host=asrhost,port=162,community=public,fromIP="1.1.1.1",type=ASR))

次の例では、タイプがASRまたはv3ASRではないため、エラーが返されます。

DBMCLI> alter dbserver snmpSubscriber=((host=localhost,port=162,community=public,fromIP="1.1.1.1"))
DBM-00068: The fromIP field is only supported for ASR SNMP subscribers.

asrmPortフィールドにより、ASRマネージャとの通信のためにMSで使用されるASRマネージャ・マシンのポート番号を指定できます。このポートは、ASRマネージャのHTTP受信機能のHTTPポートと同じにする必要があります。これを確認するには、ASRマネージャ・マシンでasr show_http_receiverを実行します。

asrmPortフィールドは、タイプがASRまたはv3ASRのsnmpSubscriberに対してのみ使用できます。このポートのデフォルト値は16161です。

snmpUser属性では、SNMPアラートを受信するユーザーを定義します。属性の構文は次のとおりです。

((name=user1, authProtocol=auth_type, privProtocol=priv_type,),  \
(name=user2, authProtocol=auth_type, privProtocol=priv_type,), ...)

- nameはユーザー名です。

- authProtocolは、認証プロトコルです。オプションはMD5またはSHAです。

- privProtocolは暗号化プロトコルです。オプションは、none、AESまたはDESです。privProtocol属性を指定しない場合、デフォルトのnoneを使用します。

- snmpUser属性にはauthProtocolを指定する必要があります。

- 認証パスワードの入力が求められます。認証パスワードは、8から12文字の英数字にする必要があります。

- 暗号化プロトコルが指定されている場合、暗号化パスワードの入力が求められます。パスワードは正確に8文字の英数字であり、大文字小文字が区別されます。

- パスワードは格納または表示されません。セキュア・ハッシュ・キーが計算され、トラップの認証および暗号化用として使用されます。

smtpUseSSL属性では、属性をtrueに設定すると、電子メール通知でSecure Socket Layer(SSL)暗号化が有効になります。

notificationPolicy属性の値は、none、またはcritical、warning、clearの組合せ(notificationPolicy='warning,clear'など)が可能です。

- critical値は、ハードウェア生成のアラートか、自動診断リポジトリ(ADR)またはBMCで生成されるアラートを示します。また、critical値は、メトリック定義で指定したcriticalのしきい値を超えた場合のメトリック・アラートも示します。

- warning値は、メトリック定義で指定したwarningのしきい値を超えた場合のメトリック・アラートを示します。

- clear値は、値がwarningまたはcriticalのしきい値を超えた後に、そのしきい値の境界を下回った場合のメトリック・アラートを示します。

- maintenance値は、ハードウェア関連のすべてのエラーを示します。ハードウェア・エラーは、電子メール・メッセージの件名の行に"Maintenance"としてレポートされます。

- 各サブスクライバのホストは、ドメイン名またはIPアドレスとして指定する必要があります。英数字以外の文字が含まれる場合は、ホスト名またはIPアドレスは引用符で囲みます。ポート値およびコミュニティ値はオプションです。ポート値のデフォルトは162です。コミュニティのデフォルト値はpublicです。タイプ値はオプションです。タイプのデフォルト値はNULLです。サポートされているNULL以外の値は、ASR、V3およびv3ASRタイプのみです。

- Management Server(MS)を起動すると、ASRまたはv3ASRのsnmpSubscriberリストのエントリはデータベース・サーバーのILOMに追加されます。これにより、ILOMが置き換えられると、エントリは新規ILOMに設定されます。エントリをILOMから削除する場合、ALTER DBSERVER ... snmpUser=コマンドを使用して、それらのエントリを手動でILOMに追加する必要があります。

- type=asrまたはtype=v3ASRのsnmpSubscriberはASR Managerの指定のみに構成する必要があります。

- データベース・サーバー・アラートまたはイベントの電子メール・メッセージが正常に送信されるかどうかを検証するには、ALTERコマンドにVALIDATE MAILオプションを指定します。検証プロセスにより、設定した受信先にテスト用の電子メール・メッセージが送信されます。テスト用の電子メール・メッセージが受信されない場合は、電子メール構成の設定が有効になっていません。

- emailFormat属性はhtmlまたはtextです。デフォルトでは、電子メール通知はHTML形式で送信されます。プレーン・テキストの電子メール通知を受信するには、値をtextに変更します。

- ALTER DBSERVER snmpEngineIDコマンドをSNMPマネージャで使用すると、アラートがデータベース・サーバーからサブスクライブされます。snmpEngineIDパラメータは、最大20文字まで設定できます。これは、データ・センター内のターゲットごとに一意である必要があります。デフォルトは、サーバー名です。SNMPユーザーが定義される前にsnmpEngineID属性が設定されていない場合、このデフォルト値が使用されます。
SNMPユーザーが定義された後は、エンジン識別子を変更しないでください。エンジン識別子を変更すると、ユーザー・キーが再計算されるため、ユーザーのパスワードを再入力する必要があります。

- データベース・サーバー名を変更する場合、一意のデータベース・サーバー名を選択する必要があります。

- ipaddressN属性の1つを変更すると、ネットワーク構成ファイル/etc/oracle/cell/network-config/cellinit.oraが変更されます。

- ALTER DBSERVER snmpSubscriberコマンドは、ASRサブスクライバを構成し、トラップを送信します。

- ALTER DBSERVER emailSubscriberコマンドは、特定の型のアラートのアラート通知の受信先のカンマ区切りの電子メール・アドレス・リストを設定します。この構文の例を次に示します。

ALTER DBSERVER emailSubscriber = ((email="email_address1",                \
alertType="alert_type")                               \
[, (email="email_address2",alertType="alert_type"), ...])

電子メール・アドレスは有効な電子メール・アドレスである必要があります。emailパラメータは必須です。alertTypeパラメータは、アラートのタイプを指定します。このパラメータはオプションです。アラート・タイプは、HARDWARE、SOFTWARE、METRICまたはADRです。アラート・タイプを指定しない場合、すべてのアラート・タイプがサブスクリプションの対象になります。

入力文字列を空にすると、現在の一連のサブスクライバが削除されます。

アラート通知を受信するには、通知ポリシーを設定する必要があります。ポリシーは、すべての電子メール・サブスクライバに適用されます。これらのアラートの通知ポリシーは、snmpSubscriberアラートの場合と同じです。

- syslogconf属性によってデータベース・サーバーのsyslogルールが拡張されます。この属性を使用すると、指定した管理サーバーに対象のsyslogメッセージが転送されるように指定できます。管理サーバーでは、管理サーバーのsyslog構成に応じて、転送されたメッセージがファイル、コンソールまたは管理アプリケーションに渡されます。この属性の構文を次に示します。

syslogconf = ('selector @node' [, 'selector @node']... )

この構文のselectorはメッセージ・タイプで、nodeは指定したサーバーです。どちらの変数もsyslog.confの標準構文規則に準拠します。

- syslogconf属性のfacilityオプションは、auth、authpriv、cron、daemon、ftp、kern、lpr、mail、mark、news、security、syslog、user、uucp、local0、local1、local2、local3、local4、local5、local6、local7、noneおよび*のいずれかである必要があります。

- syslogconf属性のpriorityオプションは、alert、crit、debug、emerg、err、error、info、notice、panic、warn、warning、noneおよび* (アスタリスク)のいずれかである必要があります。

- ALTER DBSERVER VALIDATE syslogconf selectorコマンドでは、テスト・ログ・メッセージを送信します。テスト・メッセージの送信先は、/etc/syslog.confファイルのルールによって指定されます。syslogconfの割当てによりsyslogのルールが拡張される場合は、指定の管理サーバーにテスト・メッセージが転送されます。

- 電子メールへの診断パッケージの添付をオフにするには、次のコマンドを実行します。

ALTER DBSERVER diagPackEmailAttach=FALSE

例

例6-7は、snmpSubscriberのasrmPortフィールドを設定する方法を示しています。

例6-8は、自動診断パックのアップロード機能を有効および無効にする方法を示しています。

例6-9は、データベース・サーバーに電子メール通知を設定する方法を示しています。

例6-10は、データベース・サーバー上の電子メール設定を確認する方法を示しています。

例6-11は、電子メールのメッセージの形式の変更方法を示しています。

例6-12は、データベース・サーバー上のSNMP設定を確認する方法を示しています。

例6-13は、電子メール・アラートのタイプの指定方法を示しています。この例では、1つのサブスクライバがハードウェア・アラートとソフトウェア・アラートを取得し、他のサブスクライバがADRアラートを取得しています。

例6-14は、データベース・サーバー・サービスを起動および停止する方法を示しています。

例6-15は、データベース・サーバー上にLEDを設定する方法を示しています。

例6-16は、キャパシティ・オンデマンドの保留中のコア数を示しています。新しいコア数をアクティブにするために、サーバーを再起動する必要があります。

例6-17は、アクティブ・コア数を増やす方法を示しています。

例6-18は、syslogconf属性を使用してルールを追加する方法を示しています。

例6-19は、テスト・メッセージを使用してルールを追加および検証する方法を示しています。

例6-20は、syslog.confのルールを削除する方法を示しています。

例6-7 snmpSubscriberのasrmPortの設定

DBMCLI> ALTER DBSERVER snmpSubscriber=((host=host1,port=162,community=public,type=asr,asrmPort=16161))

例6-8 自動診断パックのアップロードの有効化と無効化

dbserverオブジェクトのdiagPackUploadEnabled属性を設定すると、この機能を有効化または無効化できます。

この機能を無効にする場合は属性をfalseに、有効にする場合はtrueに設定します。デフォルトはtrueです。

DBMCLI> ALTER DBSERVER diagPackUploadEnabled=FALSE

例6-9 データベース・サーバーへの電子メール通知の構成

DBMCLI> ALTER DBSERVER smtpServer='my_mail.example.com',            -
smtpFromAddr='john.doe@example.com',         -
smtpFrom='John Doe',                         -
smtpToAddr='jane.smith@example.com',         -
snmpSubscriber=((host=host1),(host=host2)),  -
notificationPolicy='clear',                  -
notificationMethod='mail,snmp'

例6-10 データベース・サーバー上の電子メール設定の確認

DBMCLI> ALTER DBSERVER VALIDATE MAIL

例6-11 電子メールのメッセージの形式の変更

DBMCLI> ALTER DBSERVER emailFormat='text'
DBMCLI> ALTER DBSERVER emailFormat='html'

例6-12 データベース・サーバー上のSNMP設定の確認

DBMCLI> ALTER DBSERVER VALIDATE SNMP

例6-13 電子メール・アラートのタイプの指定

ALTER DBSERVER emailSubscriber=                                             \
((email="email1@example.com",alertType="HARDWARE,SOFTWARE"), \
(email="email2@example.com",alertType="ADR"))

例6-14 データベース・サーバー・サービスの起動および停止

DBMCLI> ALTER DBSERVER SHUTDOWN SERVICES MS

DBMCLI> ALTER DBSERVER RESTART SERVICES MS

表6-15 データベース・サーバーLEDの設定

DBMCLI> ALTER DBSERVER LED OFF
DBMCLI> ALTER DBSERVER LED ON

例6-16 保留コア数の設定

DBMCLI> ALTER DBSERVER pendingCoreCount=20

例6-17 アクティブ・コア数の増加

DBMCLI> ALTER DBSERVER pendingeCoreCount=20

例6-18 syslogconf属性の使用

DBMCLI> ALTER DBSERVER syslogconf=('*.err;authpriv.none @loghost', -
'*.emerg @loghost')

例6-19 ルールの追加および検証

DBMCLI> ALTER DBSERVER syslogconf=('kern.crit @loghost')
DBMCLI> ALTER DBSERVER VALIDATE syslogconf   'kern.crit'

例6-20 すべてのsyslog.confルールの削除

DBMCLI> ALTER DBSERVER syslogconf=''

関連トピック

- CREATE DIAGPACK

- 共通の属性値の制限

6.7.1.3 ALTER IBPORT

用途

ALTER IBPORTコマンドでは、すべてのInfiniBandポートまたは指定したInfiniBandポート上でアクションを実行します。

構文

ALTER IBPORT {ALL | ibport_name [, ibport_name] ...} RESET COUNTERS

使用上の注意

RESET COUNTERSオプションを使用すると、InfiniBandポート上のすべてのカウンタがリセットされます。

例

例6-21は、IBPORTオブジェクトを指定したALTERコマンドを示しています。

例6-21 IBPORT属性の変更

DBMCLI> ALTER IBPORT ALL RESET COUNTERS

InfiniBand Port HCA-1:1 successfully altered.
InfiniBand Port HCA-1:2 successfully altered.

DBMCLI> ALTER IBPORT "HCA-1:1" RESET COUNTERS

InfiniBand Port HCA-1:1 successfully altered.

6.7.1.4 ALTER THRESHOLD

用途

ALTER THRESHOLDコマンドは、すべてのしきい値または指定したしきい値の属性値を更新します。

構文

ALTER THRESHOLD { ALL |threshold_name [, threshold_name ...] }
attribute_name = attribute_value
[, attribute_name = attribute_value]...

使用上の注意

ALTERコマンドで変更可能な属性は、例6-40でmodifiableとして示されます。

例

例6-22は、しきい値の属性を変更する方法を示しています。

例6-22 しきい値の属性の変更

DBMCLI> ALTER THRESHOLD temp  warning=30

DBMCLI> ALTER THRESHOLD ALL occurrences=3

関連項目:

しきい値の属性の設定の詳細は、「CREATE」を参照してください。

6.7.1.5 ALTER USER

用途

ALTER USERコマンドは、ユーザーの属性を変更します。

構文

ALTER USER username attribute_name = attribute_value      \
[, attribute_name = attribute_value, ...]

使用上の注意

- usernameをroot、dbmadminまたはdbmmonitorにすることはできません。これらは予約されています。

- ユーザー名は一意である必要があります。

- 新しいユーザーのパスワードの入力が求められます。パスワードには、少なくとも1つの数字、1つの小文字および1つの大文字を使用した、12から40文字の英数字または特殊文字!@#$%^&*()である必要があります。

- 新しいパスワードをユーザーの現在のパスワードと同じにすることはできません。

例

例6-23に、ユーザーのパスワードを変更する方法を示します。

例6-23 ALTER USERコマンドの使用

DBMCLI> ALTER USER scott password=TOPsecret2345

6.7.2 CREATE

用途

CREATEコマンドは、新規のオブジェクトを作成し、初期属性をオブジェクトに割り当てます。

構文

CREATE object_type [name] [attributename=attribute_value [, attributename=attribute_value]...]

使用上の注意

- object_typeは次のとおりです。

- DBSERVER

- DIAGPACK

- ROLE

- THRESHOLD

- USER

- nameは、新規オブジェクトの名前です。

- attribute_valueは、object_typeの変更可能な属性の名前です。

- attribute_valueは、属性の初期設定です。

- 複数のオブジェクトがCREATEコマンドのターゲットとして有効な場合は、正常に実行されない場合があります。エラーが発生するとコマンドが中断され、残りのオブジェクトは作成されません。

関連トピック

- DBMCLIのオブジェクト・タイプについて

6.7.2.1 CREATE DBSERVER

用途

CREATE DBSERVERコマンドは、DBSERVERオブジェクト・タイプを作成します。

構文

CREATE DBSERVER [name]
[interconnect1=intValue1 [, interconnect2=intValue2 ...]]
[ { , ipaddress1=ipValue1 [, ipaddress2=ipValue2 ...] }]
[, attributeName = attributeValue ...]

使用上の注意

設定可能な属性は、DESCRIBE DBSERVERでmodifiableとして示されます。

- このコマンドを使用すると、ASR値をsnmpSubscriber属性に割当てできます。

- 名前を指定しない場合、デフォルトにより、データベース・サーバー名は、ネットワーク名のハイフンをアンダースコアで置換したサーバーのネットワーク・ホスト名に設定されます。ネットワーク名は、uname -nコマンドで表示できます。データベース・サーバー名を変更する場合、一意のデータベース・サーバー名を選択する必要があります。
名前を指定する場合は、名前がガイドラインを満たしていることを確認します。

- 1から4つのインターコネクトを指定できます。interconnect2属性が指定されている場合は、interconnect1属性を指定する必要があります。interconnect3が指定されている場合は、interconnect1属性とinterconnect2属性を指定する必要があります。

- interconnectNおよびipaddressNを指定すると、ipaddressNエントリが自動的に/etc/oracle/cell/network-config/cellinit.oraファイルに書き込まれます。

- インターコネクトはInfiniBand(ibN)です。

例

例6-24は、interconnectN属性を指定したCREATE DBSERVERコマンドを示しています。

例6-24 interconnectN属性のDBSERVERオブジェクトへの設定

DBMCLI> CREATE DBSERVER interconnect1=ib0

関連トピック

- ALTER DBSERVER

- 共通の属性値の制限

- DESCRIBE DBSERVER

6.7.2.2 CREATE DIAGPACK

用途

CREATE DIAGPACKコマンドは、診断パッケージを作成し、これにはシステムの問題のトラブルシューティングに使用できるログおよびトレースが含まれます。必要に応じて、このパッケージをOracleサポートに送信することもできます。

構文

CREATE DIAGPACK packStartTime=time, [durationInHrs=duration]

または

CREATE DIAGPACK alertName=alertName

使用上の注意

アラートが発生した場合、診断パッケージは自動的に作成されます。このパッケージには、アラートに関連するログおよびトレースが含まれます。

CREATE DIAGPACKコマンドを使用して、手動で診断パッケージを生成できます。

- packStartTimeパラメータは、ログおよびトレースの収集を開始する時間を指定します。packStartTimeの書式は次のとおりです。

yyyy_MM_ddTHH_mm_ss

例: 2015_07_07T09_00_00

packStartTimeにキーワードnowを指定することもできます。packStartTimeには、将来の時間および7日より前の時間は指定できません。packStartTimeの値は、診断パッケージの名前の一部として使用されます。

- durationInHrsパラメータは、診断パッケージに含めるログおよびトレースの時間数を指定します。有効な値は、1(デフォルト)から6です。
すべての診断パッケージには、packStartTimeの1時間前および1時間後のログが含まれます。たとえば、時間として12_00_00を指定した場合、終了時間が将来でなければ、11_00_00から13_00_00のログが収集されます。

- alertNameパラメータで、診断パッケージを作成するアラート名を指定します。LIST ALERTHISTORYコマンドを実行して、アラート名を表示できます。

診断パッケージの名前

診断パッケージの名前は、次の形式になります。

hostname + packStartTime + unique package ID

例: scaqab04adm08_2016_05_17T11_58_54_5_1.tar.bz2

アラートの場合、診断パッケージの名前は次の形式になります。

hostname + timestamp of when the package was created + alert ID

例: scaqab04adm08_2016_05_17T11_58_54_5_1.tar.bz

診断パッケージの場所

診断パッケージの場所は/opt/oracle/dbserver/dbms/deploy/logです。

診断パッケージのステータス

LIST DIAGPACKコマンドを実行して、システム内の診断パッケージのリストおよびそのステータスを取得できます。

診断パッケージの作成、リストおよびダウンロードに必要な権限

診断パッケージをダウンロードするには、事前にユーザーにロールを付与する必要があります。DBMCLIを使用して、次の権限をロールに付与します。

- 診断パッケージを作成する権限:

grant privilege CREATE ON DIAGPACK to ROLE role

- 診断パッケージをリストし、そのステータスをチェックする権限:

grant privilege LIST ON DIAGPACK to ROLE role

- 診断パッケージをダウンロードする権限:

grant privilege DOWNLOAD ON DIAGPACK to ROLE role

その後、このロールをユーザーに付与できます。たとえば、ロールにdiagpack_role,という名前を付けた場合、次のコマンドでユーザーfredにロールを付与します。

DBMCLI> GRANT ROLE diagpack_role TO USER fred

デプロイ中、Oracle Exadata Deployment Assistant (OEDA)によってCELLDIAGという名前のExadataストレージ・ソフトウェア・ユーザーが作成されます。このユーザーを使用して、ExaCLIまたはREST API経由でリモートからセルに接続できます。このユーザーには診断パッケージの作成、表示およびダウンロードの権限があります。

診断パッケージのダウンロード次のいずれかの方法で診断パッケージをダウンロードできます。診断パッケージをダウンロードする前に、DOWNLOAD ON DIAGPACK権限が必要であることに注意してください。

- REST APIの使用

- 名前によって診断パッケージをダウンロードするには、次のURLを使用します。ここで、hostnameにはサーバーのホスト名を、diagpacknameには診断パッケージの名前を指定します。

https://hostname/diagpack/download?name=diagpackname

ユーザーがまだログインしていない場合、このURLでは、ユーザー名とパスワードの入力を求めるプロンプトが表示されます。

診断パッケージには、次のようにアクセスすることもできます

https://hostname/diagpack

次に例を示します。

https://dm01db01.example.com/diagpack

このページでは、次のようにログインするユーザー名を要求されます。

User: fred
Password: *******

ユーザーの権限に基づいて、このページの異なるセクションが非表示になります。ユーザーがCREATE ON DIAGPACK権限を持っていない場合は、新しいdiagpackを作成するためのフォームが表示されません。同様に、ユーザーがLIST ON DIAGPACK権限を持っていない場合は、アラートおよびその診断パッケージのリストが表示されません。

アラート名によって診断パッケージをダウンロードするには、次のURLを使用します。ここで、hostnameにはサーバーのホスト名を、alertNameには診断パッケージのアラート名を指定します。

https://hostname/diagpack/download?alert=alertName

これは、AlertHistoryで使用されるものと同じアラート名です。ステートレス・アラートでは1、2、3、ステートフル・アラートでは1_1、2_1、3_1、3_2のようになります。

- ExaCLIのdownloadコマンドを使用する
ExaCLIにより、計算ノードからリモートでストレージ・ノード上のCellCLIコマンドを実行できます。downloadコマンドを実行するには、計算ノードで次のコマンドを実行します。

1. ExaCLIを起動し、診断パックが含まれるセルに接続します。次のようなコマンドを使用します。ここで、hostnameにはセルのホスト名を指定します。

exacli -l celladministrator -c hostname
Password=********

2. downloadコマンドを実行します。次のようなコマンドを使用します。ここで、nameにはダウンロードする診断パッケージの名前を、destinationFolderには、ダウンロードされる診断パッケージを保存するディレクトリを指定します。

exacli> download diagpack name destinationFolder

- アラートの電子メールから診断パッケージを取得する
アラートの電子メールには、INFO、CLEARおよびWARNINGを除く、すべてのアラートの診断パッケージが含まれています。診断パッケージは、クリティカル・アラートのみに生成されます。

電子メールへの診断パッケージの添付をオフにする

電子メールへの診断パッケージの添付をオフにするには、コマンド alter dbserver diagPackEmailAttach=FALSEを使用します。診断パッケージは引き続き生成され、システムに格納されます。診断パッケージをダウンロードするには、「診断パッケージのダウンロード」の項を参照してください。

例

例6-25 packStartTimeでの「now」の使用

この例では、開始時間としてNOWを使用し、デフォルトの継続時間の1時間で診断パッケージを作成します。

出力は、ディレクトリ/opt/oracle/dbserver/dbms/deploy/logの単一の圧縮ファイルです。

DBMCLI> create diagpack packStartTime="now"
Processing: dm01db01_diag_2015_07_08T17_53_58_1
Use 'list diagPack' to check its status.

例6-26 継続時間の指定

この例では、/opt/oracle/dbserver/dbms/deploy/logに3つの診断パッケージが作成されます。

- 最初のパッケージの開始時間は2015_07_07T09_00_00です。

- 第2のパッケージの開始時間は2015_07_07T10_00_00です。

- 第3のパッケージの開始時間は2015_07_07T11_00_00です。

DBMCLI> create diagpack packStartTime="2015_07_07T09_00_00", durationInHrs=3
Processing: dm01db01_diag_2015_07_07T09_00_00_1
dm01db01_diag_2015_07_07T10_00_00_1 (In queue...)
dm01db01_diag_2015_07_07T11_00_00_1 (In queue...)
Use 'list diagPack' to check its status.

関連トピック

- Oracle Exadata Storage Server Softwareユーザーズ・ガイド

- LIST ALERTHISTORY

- LIST DIAGPACK

- Oracle Exadata Database Machineメンテナンス・ガイド

6.7.2.3 CREATE ROLE

用途

CREATE ROLEコマンドは、データベース・サーバーにアクセスするユーザーのロールを作成します。

構文

CREATE ROLE  role_name1 [, role_name2, ...]

使用上の注意

ロールは一意である必要があります。

例

例6-27は、ロールの作成方法を示しています。

例6-27 ロールの作成

DBMCLI> CREATE ROLE dbmonitor

6.7.2.4 CREATE THRESHOLD

用途

CREATE THRESHOLDコマンドは、メトリック・アラートの生成条件を指定するしきい値オブジェクトを作成します。

構文

CREATE THRESHOLD name attributename=value [, attributename=value]...

使用上の注意

指定可能な属性は、comparison、critical、occurrences、observationおよびwarningです。

- name引数は必須です。名前はメトリック名とオブジェクト名で構成され、書式はmetricName.objectName (db_io_rq_sm_sec.db123やct_io_wt_rq.interactiveなど)になります。LIST METRICCURRENT metricコマンドを使用して、メトリックの使用可能なオブジェクト名を表示します。オブジェクト名はオプションです。

- オブジェクト名が指定されない場合、指定のメトリックのすべてのメトリック・オブジェクトにしきい値が適用されます。

- comparison属性は必須で、条件値が付きます。値は、'<'、'<='、'='、'>='または'>'にする必要があります。

- occurrences属性では、状態変更をトリガーするしきい値を超える測定値の連続する数を指定します。
発生および観測件数を指定する場合は、サンプル平均数の連続する発生数を、アラートの原因となった観測件数より多く指定する必要があります。たとえば、次の5つの観測(observations=5)がデータベース・サーバー上で発生した場合、連続する発生件数(occurrences=2)の値が5および15のため、平均サンプル数は10になります。

Observation 1: 0
Observation 2: 30
Observation 3: 0
Observation 4: 5
Observation 5: 15

- observation属性は、測定値の平均を計算するために使用される測定値の数です。

- warningまたはcriticalに設定される値の状態変更により、ステートフル・アラートが生成されます。

例6-28 しきい値の作成

この例は、しきい値を作成する方法を示しています。

DBMCLI> CREATE THRESHOLD temp comparison='>', critical=30

関連項目:

- メトリックの詳細は、『Oracle Exadata Storage Server Softwareユーザーズ・ガイド』を参照してください

- メトリックおよびしきい値の詳細は、「LIST ALERTDEFINITION」を参照してください。

6.7.2.5 CREATE USER

用途

CREATE USERコマンドは、ユーザーを作成します。

構文

CREATE USER name PASSWORD = *

使用上の注意

- ユーザー名は一意である必要があります。

- usernameをroot、dbmadminまたはdbmmonitorにすることはできません。これらは予約されています。

- 新しいユーザーのパスワードの入力が求められます。パスワードには、少なくとも1つの数字、1つの小文字および1つの大文字を使用した、12から40文字の英数字または特殊文字!@#$%^&*()である必要があります。

- 新しいパスワードをユーザーの現在のパスワードと同じにすることはできません。

例

例6-29は、ユーザーの作成方法を示しています。

例6-29 ユーザーの作成

DBMCLI> CREATE USER jdoe PASSWORD = *
password:
Confirm password: password
User jdoe successfully created.

6.7.3 DESCRIBE

用途

DESCRIBEコマンドは、引数として指定されるオブジェクト・タイプの属性のリストを表示します。modifiableというタグは、ALTERコマンドを使用して属性を変更できるかどうかを示しています。

構文

DESCRIBE object_type

使用上の注意

- object_typeは、サポートされるオブジェクト・タイプの1つです。

- 属性のリストは、LISTコマンドで引数として使用できます。

- DESCRIBEでは、オブジェクトのすべての属性は表示されません。

関連トピック

- DBMCLIのオブジェクト・タイプについて

6.7.3.1 DESCRIBE ALERTDEFINITION

用途

DESCRIBE ALERTDEFINITIONコマンドは、ALERTDEFINITIONオブジェクト・タイプの属性のリストを表示します。

構文

DESCRIBE ALERTDEFINITION

使用上の注意

表6-4は、DESCRIBE ALERTDEFINITIONコマンドの属性を示しています。

表6-4 DESCRIBE ALERTDEFINITIONの属性

属性

説明

alertShortName

アラートの省略名。アラートの基準がメトリックの場合、省略名は対応するメトリックのname属性と同じになります。

alertSource

アラートのソース(BMCやADRなど)。

alertType

アラートのタイプ。値はステートフルまたはステートレスです。

- ステートフル・アラートは、normalに遷移すると自動的にクリアされます。

- ステートレス・アラートはクリアされません。アラートは、examinedBy属性を設定して変更できます。

description

アラートの説明。

metricName

アラートの基準がメトリックの場合のメトリック名。

name

アラートの識別子。

例

例6-30は、ALERTDEFINITIONオブジェクトを指定したDESCRIBEコマンドを示しています。

例6-30 ALERTDEFINITIONオブジェクトの説明

DBMCLI> DESCRIBE ALERTDEFINITION

name
alertShortName
alertSource
alertType
description
metricName

6.7.3.2 DESCRIBE ALERTHISTORY

用途

DESCRIBE ALERTHISTORYコマンドは、ALERTHISTORYオブジェクト・タイプの属性のリストを表示します。

構文

DESCRIBE ALERTHISTORY

使用上の注意

次の表は、DESCRIBE ALERTHISTORYコマンドの属性を示しています。

表6-5 DESCRIBE ALERTHISTORYの属性

属性

説明

alertAction

このアラートで実行する推奨操作。

alertMessage

アラートの簡単な説明。

alertSequenceID

アラートの一意の順序ID。warningからcritical、またはcriticalからclearなど、アラートにより状態が変更されると、同じ順序番号と遷移時点のタイム・スタンプで別のアラート発生が作成されます。

alertShortName

アラートの省略名。アラートの基準がメトリックの場合、省略名は対応するメトリックのname属性と同じになります。

alertType

アラートのタイプ。値はステートフルまたはステートレスです。

- ステートフル・アラートは、normalに遷移すると自動的にクリアされます。

- ステートレス・アラートはクリアされません。アラートは、examinedBy属性を設定して変更できます。

beginTime

アラートによる状態変更が開始された時点のタイム・スタンプ。

endTime

アラートによる状態変更が終了した時点のタイプ・スタンプ。

examinedBy

アラートを確認した管理者。

failedMail

通知が失敗した場合に送信する電子メールの受信者。

failedSNMP

通知が失敗した場合に送信するSNMPサブスクライバ。

metricObjectName

メトリックしきい値にアラートを発生させるデータベース・サーバー・ディスクなどのオブジェクト。

metricValue

アラートを生成するメトリックの値。

name

アラートの一意の識別子。

notificationState

サブスクライバにアラート・メッセージを通知する場合の状況を示す番号。

- 0: 試行されなかった

- 1: 送信に成功

- 2: 再試行中(最大5回)

- 3: 5回の再試行に失敗

sequenceBeginTime

アラートの順序IDが最初に作成された時点のタイム・スタンプ。

severity

重大度のレベル。値はclear、info、warningまたはcriticalです。

例

例6-31は、ALERTHISTORYオブジェクトを指定したDESCRIBEコマンドを示しています。

例6-31 ALERTHISTORYオブジェクトの説明

DBMCLI> DESCRIBE ALERTHISTORY

name
alertAction
alertMessage
alertSequenceID
alertShortName
alertType
beginTime
endTime
examinedBy              modifiable
failedMail
failedSNMP
metricObjectName
metricValue
notificationState
sequenceBeginTime
severity

関連トピック

- DESCRIBE METRICDEFINITION

6.7.3.3 DESCRIBE DBSERVER

用途

DESCRIBE DBSERVERコマンドは、DBSERVERオブジェクト・タイプの属性のリストを表示します。

構文

DESCRIBE DBSERVER

使用上の注意

表6-6は、DESCRIBE DBSERVERコマンドの属性を示しています。

表6-6 DESCRIBE DBSERVERの属性

属性

説明

bbuStatus

ハード・ディスク・コントローラのバッテリ・バックアップ・ユニット(BBU)のステータス。

comment

ユーザー指定のテキスト文字列。

cpuCount

データベース・サーバー上のCPUの数。

diagHistoryDays

ADRファイルの保存日数。デフォルト値は7日間です。

diagPackEmailAttach

診断パッケージをアラート電子メールの添付ファイルとして含めるかどうか。デフォルトはtrueです。

diagPackUploadEnabled

診断パッケージの自動アップロード機能を有効にするかどうか。デフォルトはtrueです。

emailFormat

電子メール・メッセージのファイル形式。値はHTMLまたはtextです。

fanCount

動作中のファンの数およびファンの合計数。working/totalとして表示されます。

fanStatus

ファンのステータス。値はnormal、warning、criticalです。

id

ハードウェア・ベンダーによって提供されるグローバル一意識別子(GUID)。

interconnect1-4

データベース・サーバーの1から4までのインターコネクト。たとえば、bondeth0です。

interconnectCount

ネットワーク・インターコネクトの数。

ipaddress1-4

データベース・サーバーの1から4までのIPアドレス。

kernelVersion

ホスト・カーネル・ソフトウェアのバージョン。

location

ユーザーが指定するセル・ハードウェアの物理ロケーション。

locatorLEDStatus

セルLOCATE LEDのステータス。値はonまたはoffです。

makeModel

ベンダーにより提供されるセル・ハードウェアの型およびモデル。

metricCollection

管理サーバーがメトリック収集を実行するかどうかを示すインジケータ。値はTRUEまたはFALSEです。FALSEに設定すると、すべてのメトリック収集およびアラート・マイニングが停止します。デフォルトの設定はTRUEです。

metricHistoryDays

メトリック履歴ファイルの保存日数。デフォルト値は7日間です。

msVersion

管理サーバーのバージョン。

name

データベース・サーバーの名前。

notificationMethod

アラートの通知メソッド。値はmail、snmp、none、またはmailとsnmpの両方です。

notificationPolicy

サブスクライバに送信する重大度アラートのインジケータ。notificationPolicyの値は、none、またはcritical、warningおよびclearの任意の組合せです。

powerCount

電源数。working/totalとして表示されます。

powerStatus

電源のステータス。値はnormal、warning、criticalです。

releaseImageStatus

イメージングが成功したかどうかを判断するためのインジケータ。

releaseTrackingBug

セル・ソフトウェアのパッチ番号(11223344など)。

releaseVersion

セル・ソフトウェアのリリース番号(11.2.2.3.0など)。

rescuePlan

しきい値や通知などの設定を最後の既知の値にリストアするサーバー・レスキューの後で実行できるコマンドのリスト。

smtpFrom

アラート通知に表示されるSMTP電子メールのユーザー名。

smtpFromAddr

アラート通知の送信元のSMTP電子メール・アドレス。

smtpPort

アラート通知の送信に使用されるSMTP電子メール・サーバー・ポート。

smtpPwd

アラート通知の送信元のSMTP電子メール・ユーザーのパスワード。

smtpServer

アラート通知の送信に使用されるSMTP電子メール・サーバー。

smtpSubscriber

SNMPアラート通知をサブスクライブするホストのリスト。

smtpToAddr

電子メールの送信先のアドレス。電子メール・アドレスは、複数のサブスクライバにアラートを通知できるように、引用符で囲んだカンマ区切りのリストにできます。

smtpUser

アラート通知に表示されるSMTP電子メールのユーザー名。

smtpUseSSL

Secure Socket Layer(SSL)認証を使用するための仕様。

状態

データベース・サーバーのステータス。

syslogConf

システム・ログイン・ユーティリティsyslogdのルール。

temperatureReading

BMCから取得されるセルの現在の温度(摂氏)。

temperatureStatus

温度のステータス。値はnormal、warning、criticalです。

traceLevel

トレース・メッセージの書込みレベル。このレベルは、有効なJavaロギング・レベル(SEVERE、WARNING、INFO、CONFIG、FINE、FINER、FINEST)または有効なOracle Diagnostic Logging(ODL)のロギング・レベル(INCIDENT_ERROR:1、ERROR:1、WARNING:1、NOTIFICATION:1、NOTIFICATION:16、TRACE:1、TRACE:16、TRACE:32)にできます。デフォルトはINFOです。

upTime

システムが再起動してからの時間(days,hours:minutes)。

例

例6-32 DBSERVERオブジェクトの説明

DBMCLI> describe dbserver

name                   modifiable
bbuStatus
comment                modifiable
coreCount
cpuCount
diagHistoryDays        modifiable
diagPackEmailAttach    modifiable
diagPackUploadEnabled  modifiable
emailFormat            modifiable
emailSubscriber        modifiable
fanCount
fanStatus
iaasIdleInUse          modifiable
iaasMode               modifiable
iaasReason             modifiable
id
interconnectCount
interconnect1          modifiable
interconnect2          modifiable
interconnect3          modifiable
interconnect4          modifiable
interconnect5          modifiable
interconnect6          modifiable
interconnect7          modifiable
interconnect8          modifiable
ipaddress1
ipaddress2
ipaddress3
ipaddress4
ipaddress5
ipaddress6
ipaddress7
ipaddress8
kernelVersion
locatorLEDStatus
location               modifiable
makeModel
metricCollection       modifiable
metricHistoryDays      modifiable
msVersion
notificationMethod     modifiable
notificationPolicy     modifiable
pendingCoreCount       modifiable
powerCount
powerStatus
releaseImageStatus
releaseVersion
releaseTrackingBug
securityCert           modifiable
securityPrivKey        modifiable
securityPrivKeyPW      modifiable
securityPubKey         modifiable
smtpFrom               modifiable
smtpFromAddr           modifiable
smtpPort               modifiable
smtpPwd                modifiable
smtpServer             modifiable
smtpToAddr             modifiable
smtpUser               modifiable
smtpUseSSL             modifiable
snmpSubscriber         modifiable
snmpUser               modifiable
status
syslogConf             modifiable
temperatureReading
temperatureStatus
traceLevel             modifiable
upTime
msStatus
rsStatus

6.7.3.4 DESCRIBE IBPORT

用途

DESCRIBE IBPORTコマンドは、IBPORTオブジェクト・タイプの属性のリストを表示します。

構文

DESCRIBE IBPORT

使用上の注意

表6-7 DESCRIBE IBPORTの属性

属性

説明

activeSlave

対象のポートが、ボンディングされたIPの現在アクティブなポートかどうかを示すインジケータ。

dataRate

InfiniBandポートのデータ・レート。

hcaFWVersion

ホスト・チャネル・アダプタのファームウェアのバージョン。

id

InfiniBandポートのグローバル一意識別子(GUID)。

lid

InfiniBandポートのローカルID。サブネット内で一意であり、スイッチによって16ビットの識別子がネットワーク内のルーティングに使用されます。

linkDowned

ポートのトレーニング・ステート・マシンがリンク・エラーのリカバリ処理に失敗し、リンクがダウンした回数。

linkIntegrityErrs

リンク完全性エラーの数。

linkRecovers

ポートのトレーニング・ステート・マシンがリンク・エラーのリカバリ処理を正常に完了した回数。

name

InfiniBandポート名。

physLinkState

物理リンクの状態。

portNumber

InfiniBandポートのポート番号。

rcvConstraintErrs

InfiniBandポートで発生した受信制約エラーの数。

rcvData

InfiniBandポートで受信した32ビット・データのワード数。

rcvErrs

InfiniBandポートで受信した、エラーを含むパケットの数。

rcvRemotePhysErrs

InfiniBandポートで発生した物理エラーの数。

状態

リンクの状態。

symbolErrs

InfiniBandポートで発生した軽度なリンク・エラーの数。

vl15Dropped

リソースの制約(バッファ不足など)が原因で、InfiniBandポートによって廃棄された着信のVL15パケットの数。

xmtConstraintErrs

InfiniBandポートで発生した送信制約エラーの数。

xmtData

InfiniBandポート上で送信した32ビット・データのワード数。

xmtDiscards

ポートのダウンまたは輻輳によってInfiniBandポートで破棄されたアウトバンド・パケットの数。

例6-33 IBPORTオブジェクトの説明

この例は、IBPORTオブジェクトを指定したDESCRIBEコマンドを示しています。

DBMCLI> DESCRIBE IBPORT

name
activeSlave
dataRate
hcaFWVersion
id
lid
linkDowned
linkIntegrityErrs
linkRecovers
physLinkState
portNumber
rcvConstraintErrs
rcvData
rcvErrs
rcvRemotePhysErrs
status
symbolErrs
vl15Dropped
xmtConstraintErrs
xmtData
xmtDiscards

6.7.3.5 DESCRIBE LUN

用途

DESCRIBE LUNコマンドは、LUNオブジェクト・タイプの属性のリストを表示します。

構文

DESCRIBE LUN

使用上の注意

表6-8 DESCRIBE LUNの属性

属性

説明

deviceName

LUNのオペレーティング・システム・デバイス名。例: /dev/c1d5。

diskType

ディスクのタイプ。

errorCount

このLUNでのエラー数。

id

システムによって割り当てられる識別子。

lunSize

データベース・サーバー・ディスクに変換される前の、LUNのRawサイズ。

lunUID

システムによって割り当てられる一意の識別子。

name

LUNに割り当てられる一意の名前。IDが一意でない場合は、異なる(拡張形式)LUN IDになる場合があります。

overProvisioning

フラッシュ・ストレージ内のブロックうち、特定のLUNで今後も使用できるようにオーバー・プロビジョニングされたブロックの割合を示すインジケータ。この属性は、フラッシュ・ディスク専用です。

raidLevel

LUNで使用されるRAIDレベルの値。たとえば、RAID 0です。

状態

LUNのステータス。値はnormal、warning、criticalです。

例6-34 LUNオブジェクトの説明

この例は、LUNオブジェクトを指定したDESCRIBEコマンドを示しています。

DBMCLI> DESCRIBE LUN

name
deviceName
diskType
errorCount
id
lunSize
lunUID
overProvisioning
raidLevel
status

6.7.3.6 DESCRIBE METRICCURRENT

用途

DESCRIBE METRICCURRENTコマンドは、METRICCURRENTオブジェクト・タイプの属性のリストを表示します。

構文

DESCRIBE METRICCURRENT

使用上の注意

表6-9 DESCRIBE METRICCURRENTの属性

属性

説明

alertState

アラート状態のインジケータ。値はnormal、warning、criticalです。

collectionTime

メトリック値が収集された時点のタイム・スタンプ。

metricObjectName

計測中のデータベース・サーバーなど、オブジェクトの名前。

metricType

統計がどのように作成または定義されたかを示す仕様。

metricValue

メトリックが収集された時点の値。

name

現在のメトリックの一意の名前。

objectType

オプションは、DBSERVER、DBSERVER_FILESYSTEMおよびIBPORTです。

例6-35 METRICCURRENTオブジェクトの説明

この例は、METRICCURRENTオブジェクトを指定したDESCRIBEコマンドを示しています。

DBMCLI> DESCRIBE METRICCURRENT

name
alertState
collectionTime
metricObjectName
metricType
metricValue
objectType

関連トピック

- DESCRIBE METRICDEFINITION

6.7.3.7 DESCRIBE METRICDEFINITION

用途

DESCRIBE METRICDEFINITIONコマンドは、METRICDEFINITIONオブジェクト・タイプの属性のリストを表示します。

構文

DESCRIBE METRICDEFINITION

使用上の注意

表6-10は、DESCRIBE METRICDEFINITIONコマンドの属性を示しています。

表6-10 DESCRIBE METRICDEFINITIONの属性

属性

説明

description

メトリックの説明。

metricType

統計がどのように作成または定義されたかを示すインジケータ。次の2通りの場合があります。

- cumulative: メトリックが作成されてからの累積統計。

- instantaneous: メトリックが収集される時点の値。

- rate: 特定の期間の観測データの統計を平均して計算される率。

- transition: 遷移メトリックは、その値が変更された時点で収集され、通常はハードウェアのステータスで重要な遷移があった場合に取得されます。

name

メトリック定義の一意の名前。name属性の値は、省略語を組み合せたものになります。属性値は、メトリックが定義されるオブジェクト・タイプの省略語で開始します。略語は次のとおりです。

- DS_ (データベース・サーバー)

- N_ (ネットワーク)

objectType

オプションは、DBSERVER、DBSERVER_FILESYSTEMおよびIBPORTです。

persistencePolicy

時間メトリック値が格納されます。

unit

メトリックの単位。収集される次のメトリックに明示的に関連付けられます。

- 数値

- % (パーセンテージ)

- F (華氏)

- C (摂氏)

例6-36 METRICDEFINITIONオブジェクトの説明

この例は、METRICDEFINITIONオブジェクトを指定したDESCRIBEコマンドを示しています。

DBMCLI> DESCRIBE METRICDEFINITION

name
description
metricType
objectType
persistencePolicy
unit

6.7.3.8 DESCRIBE METRICHISTORY

用途

DESCRIBE METRICHISTORYコマンドは、METRICHISTORYオブジェクト・タイプの属性のリストを表示します。

構文

DESCRIBE METRICHISTORY

使用上の注意

表6-11は、DESCRIBE METRICHISTORYコマンドの属性を示しています。

表6-11 DESCRIBE METRICHISTORYの属性

属性

説明

alertState

アラート状態のインジケータ。値はnormal、warning、criticalです。

collectionTime

メトリック値が収集された時点のタイム・スタンプ。

memory

管理サーバー・メモリーのメトリック。この属性は、収集時間が1時間未満の場合に、collectionTime属性のかわりに使用できます。

metricObjectName

計測中のデータベース・サーバー・ディスクなど、オブジェクトの名前。

metricType

統計がどのように作成または定義されたかを示す仕様。

metricValue

メトリックが収集された時点の値。

metricValueAvg

メトリックの平均値。

metricValueMax

メトリックの最大値。

metricValueMin

メトリックの最小値。

name

現在のメトリックの一意の名前。

objectType

オプションは、DBSERVER、DBSERVER_FILESYSTEMおよびIBPORTです。

over

集計用の時間の指定(分単位)。この属性は、max、minおよびavgキーワードと組み合せることで機能します。

例6-37 METRICHISTORYオブジェクトの説明

この例は、METRICHISTORYオブジェクトを指定したDESCRIBEコマンドを示しています。

DBMCLI> DESCRIBE METRICHISTORY

name
alertState
collectionTime
memory
metricObjectName
metricType
metricValue
metricValueAvg
metricValueMax
metricValueMin
objectType
over

6.7.3.9 DESCRIBE PHYSICALDISK

用途

DESCRIBE PHYSICALDISKコマンドは、PHYSICALDISKオブジェクト・タイプの属性のリストを表示します。

構文

DESCRIBE PHYSICALDISK

使用上の注意

表6-12は、DESCRIBE PHYSICALDISKコマンドの属性を示しています。

表6-12 DESCRIBE PHYSICALDISKの属性

属性

説明

ctrlHwVersion

コントローラのバージョン。この属性は、HP Oracle Database Machine上のOracle Exadata Storage Server Softwareにのみ適用されます。

diskType

ディスクのタイプ(HARDDISKまたはFLASHDISK)。

enclosureDeviceId

ハード・ディスク・エンクロージャの識別子。この属性は、Oracle Exadata Storage Server上のOracle Exadata Storage Server Softwareにのみ適用されます。

errCmdTimeoutCount

ディスクでのコマンド・タイムアウトSCSIエラーの数。この属性は、HP Oracle Database Machine上のOracle Exadata Storage Server Softwareにのみ適用されます。

errHardReadCount

ディスクでのハード読取りエラーの数。この属性は、HP Oracle Database Machine上のOracle Exadata Storage Server Softwareにのみ適用されます。

errHardWriteCount

ディスクでのハード書込みエラーの数。この属性は、HP Oracle Database Machine上のOracle Exadata Storage Server Softwareにのみ適用されます。

errMediaCount

ハード・ディスクでのメディア・エラーの数。この属性は、Oracle Exadata Storage Server上のOracle Exadata Storage Server Softwareにのみ適用されます。

errOtherCount

ハード・ディスクでの未分類エラーの数。この属性は、HP Oracle Database Machine上のOracle Exadata Storage Server Softwareにのみ適用されます。

errSeekCount

ディスクでのSCSIシーク・エラーの数。この属性は、HP Oracle Database Machine上のOracle Exadata Storage Server Softwareにのみ適用されます。

hotPlugCount

ディスクがラックに挿入された回数。この属性は、HP Oracle Database Machine上のOracle Exadata Storage Server Softwareにのみ適用されます。

lastFailureReason

ディスクでの最新のエラーのタイプ。この属性は、HP Oracle Database Machine上のOracle Exadata Storage Server Softwareにのみ適用されます。

luns

このディスクから変換されたLUNのリスト。

makeModel

システムによって提供されるモデルの説明。

name

物理ディスクの一意の名前。

physicalFirmware

ディスクのファームウェアのシステム割当て名。この属性は、HP Oracle Database Machine上のOracle Exadata Storage Server Softwareにのみ適用されます。

physicalInsertTime

ディスクが挿入された時刻。

physicalInterface

ハード・ディスクで使用されているインタフェース・タイプ。たとえば、SASです

physicalPort

このディスクのコントローラのポート。この属性は、HP Oracle Database Machine上のOracle Exadata Storage Server Softwareにのみ適用されます。

physicalRPM

ディスクの回転数(毎分)。この属性は、HP Oracle Database Machine上のOracle Exadata Storage Server Softwareにのみ適用されます。

physicalSerial

システムで割り当てられた一意のID。

physicalSize

ディスクのサイズ(バイト単位)。

physicalUseType

ディスクの用途。例: Data Drive。

sectorRemapCount

物理ディスクのすべてのセクター再マップ操作の回数。この属性は、HP Oracle Database Machine上のOracle Exadata Storage Server Softwareにのみ適用されます。

slotNumber

ディスクの物理的な場所。

状態

物理ディスクのステータス。値は次のとおりです。

- failed: ディスクで障害が発生しました。以前のリリースでは、このステータスはcriticalと呼ばれていました。

- normal: ディスクは正常に動作しています。

- not present: ディスクは取り外されました。

- peer failure: フラッシュ・ディスク障害のみです。

- poor performance: ディスクのパフォーマンスが低下しています。

- predictive failure: ディスク障害の発生が予想されます。

- write-through caching: フラッシュ・ディスク・キャッシングのみです。

例

例6-38は、Oracle Exadata Storage ServerにおいてPHYSICALDISKオブジェクトを指定したDESCRIBEコマンドを示しています。

例6-38 データベース・サーバーのハード・ドライブ上のPHYSICALDISKオブジェクトの説明

DBMCLI> DESCRIBE PHYSICALDISK

name
ctrlFirmware
diskType
enclosureDeviceId
errMediaCount
errOtherCount
luns
makeModel
physicalFirmware
physicalInsertTime
physicalInterface
physicalSerial
physicalSize
slotNumber
status

6.7.3.10 DESCRIBE ROLE

用途

DESCRIBE ROLEコマンドは、ROLEオブジェクト・タイプの属性のリストを表示します。

構文

DESCRIBE ROLE

使用上の注意

表6-13 DESCRIBE ROLEの属性

属性

説明

name

ロールを割り当てられたユーザーの一意の名前。

privileges

ロールに付与されている権限。

例

例6-39 ROLEオブジェクトの説明

この例は、ROLEオブジェクトを指定したDESCRIBEコマンドを示しています。

DBMCLI> DESCRIBE ROLE
name
privileges

6.7.3.11 DESCRIBE THRESHOLD

用途

DESCRIBE THRESHOLDコマンドは、THRESHOLDオブジェクト・タイプの属性のリストを表示します。

構文

DESCRIBE THRESHOLD

使用上の注意

表6-14は、DESCRIBE THRESHOLDコマンドの属性を示しています。

表6-14 DESCRIBE THRESHOLDの属性

属性

説明

comparison

メトリック値としきい値を比較して、値がしきい値に違反しているかどうかを確認する演算子(>、>=、=、<、<=)。

critical

メトリック値がクリティカルの状態であるとみなされる上限値。この値を超えるとアラートが生成されます。

name

しきい値の一意の名前。

observation

測定値の数。この数の測定値で率メトリックを平均し、しきい値と比較されます。

occurrences

メトリック値がしきい値を連続して超えた場合の上限数。この上限数を超えると指定したアラートが発行されます。

warning

メトリック値が警告の状態であるとみなされる上限値。この値を超えるとアラートが生成されます。

例6-40 THRESHOLDオブジェクトの説明

この例は、THRESHOLDオブジェクトを指定したDESCRIBEコマンドを示しています。

DBMCLI> DESCRIBE THRESHOLD

name
comparison              modifiable
critical                modifiable
observation             modifiable
occurrences             modifiable
warning                 modifiable

6.7.3.12 DESCRIBE USER

用途

DESCRIBE USERコマンドは、USERオブジェクト・タイプの属性のリストを表示します。

構文

DESCRIBE USER

使用上の注意

次の表は、DESCRIBE USERコマンドの属性を示しています。

表6-15 DESCRIBE USERの属性

属性

説明

name

ユーザーの一意の名前。

roles

ユーザーに割り当てられたロール。

例6-41 USERオブジェクトの説明

この例は、USERオブジェクトを指定したDESCRIBEコマンドを示しています。

DBMCLI> DESCRIBE USER

name
roles

6.7.4 DROP

用途

DROPコマンドは、名前を指定したオブジェクトをデータベース・サーバーから削除するか、データベース・サーバーをリセットします。

構文

DROP object_type [object_name [, object_name]...] [options]

使用上の注意

- object_typeは次のいずれかです。

- ALERTHISTORY

- DBSERVER

- ROLE

- THRESHOLD

- USER

- object_nameは、データベース・サーバー・ディスク、ロール、しきい値またはユーザーの名前です。

- 複数のオブジェクトがDROPコマンドのターゲットの場合は、正常に実行されない場合があります。エラーが発生するとコマンドが中断され、残りのオブジェクトは削除されません。

関連トピック

- DBMCLIのオブジェクト・タイプについて

6.7.4.1 DROP ALERTHISTORY

用途

DROP ALERTHISTORYコマンドは、データベース・サーバーのアラート履歴からアラートを削除します。

構文

DROP ALERTHISTORY {ALL | alert1 {, alert2}, ...}

使用上の注意

- このコマンドのalertNは、履歴から削除されるアラートの名前です。

- ステートフル・アラートを削除する場合は、同時にアラートの順序のメンバーをすべて削除する必要があります。すべてのメンバーを削除しないと、システムによりエラーが発行されます。

例6-42 データベース・サーバーのアラート履歴の削除

DBMCLI> DROP ALERTHISTORY 1, 2_1, 2_2

6.7.4.2 DROP DBSERVER

用途

DROP DBSERVERは、データベース・サーバー上のMSを元の状態にリセットします。

構文

DROP DBSERVER

使用上の注意

- データベース・サーバーに設定されたいずれのしきい値も、データベース・サーバーから削除されます。

- DBSERVER属性はデフォルト値に設定されます。

例6-43 データベース・サーバーの削除

DBMCLI> DROP DBSERVER

6.7.4.3 DROP ROLE

用途

DROP ROLEコマンドは、セルからユーザー・ロールを削除します。

構文

DROP ROLE  { ALL | role_name1 [, role_name2, ...]} [FORCE]

使用上の注意

FORCEオプションは、ユーザーにロールが付与されている場合でもロールを削除します。

例6-44 ロールの削除

DBMCLI> DROP ROLE r1,r2

6.7.4.4 DROP THRESHOLD

用途

DROP THRESHOLDコマンドは、データベース・サーバーからすべてのしきい値または指定したしきい値を削除します。

構文

DROP THRESHOLD { ALL |threshold_name [, threshold_name ...] }

例6-45 しきい値の削除

DBMCLI> DROP THRESHOLD temp

6.7.4.5 DROP USER

用途

DROP USERコマンドは、データベース・サーバーからユーザーを削除します。

構文

DROP USER { ALL | user1 [, user2]... }

使用上の注意

- user(n)は削除するユーザーの名前です。

例6-46 ユーザーの削除

DBMCLI>DROP USER jdoe

6.7.5 GRANT

用途

GRANTコマンドは、権限およびロールの属性を設定します。

構文

GRANT object_type [name] TO sub_object_type [sub_object_name]

使用上の注意

- object_typeは次のとおりです。

- PRIVILEGE

- ROLE

- PRIVILEGEオブジェクト・タイプには次を使用できます。

- nameの書式は、次のとおりです。

{ ALL ACTIONS | action } ON { ALL OBJECTS | object }               \
[{ ALL ATTRIBUTES | ATTRIBUTES attribute1 [, attribute2, ...] }]   \
[{ WITH ALL OPTIONS | WITH OPTIONS option1 [, option2, ...] }]

- sub_object_typeはROLEである必要があります。

- sub_object_nameはロールの名前です。

- ROLEオブジェクト・タイプには次を使用できます。

- nameはユーザー名です。

- sub_object_typeはUSERである必要があります。

- sub_object_nameはユーザーの名前です。

6.7.5.1 GRANT PRIVILEGE

用途

GRANT PRIVILEGEコマンドは、ロールにアクセス権限を設定します。

構文

GRANT PRIVILEGE { ALL ACTIONS | action } ON { ALL OBJECTS | object }   \
{ ALL ATTRIBUTES | ATTRIBUTES attribute1 [, attribute2, ...] }         \
{ WITH ALL OPTIONS | WITH OPTIONS option1 [, option2, ...] }           \
TO ROLE { ALL | role1 [, role2, ...] }

使用上の注意

- actionはコマンドです。例: alter、create、describe、drop、export、import、list。
注意:

- grantおよびrevokeコマンドは付与できません。

- create userおよびdrop userは付与できません。

- create roleおよびdrop roleは付与できません。

- objectはアクションのオブジェクト・タイプです。これは、任意のDBMCLIオブジェクトを指定可能です。例: dbserver、threshold、ibport、alerthistory、role。

- attributeはオブジェクトの属性です。オブジェクトの属性リストを取得するには、LIST object_typeコマンドを実行します。

- optionはオブジェクトのオプションです。例: DETAIL、LIMIT、ORDER BY、WHERE。

- roleは、権限を付与するロールの名前です。

- ALL ACTIONS引数は、すべてのアクションの権限を付与します。

- ALL OBJECTS引数は、すべてのオブジェクトの権限を付与します。

- ALL ATTRIBUTES引数は、すべての属性の権限を付与します。

- WITH ALL OPTIONS引数は、すべてのオプションの権限を付与します。

- 属性とWITH OPTIONSの指定はオプションです。これらが指定されない場合、すべての属性とオプションの権限を付与します。

例

例6-47は、ロールに権限を付与する方法を示しています。

例6-48は、指定されたアクションとオブジェクトのすべての属性およびオプションをロールに付与する方法を示します。

例6-49は、指定されたアクション、オブジェクトおよび属性のすべてのオプションをロールに付与する方法を示します。

例6-50は、指定されたアクション、オブジェクトおよびオプションのすべての属性をロールに付与する方法を示します。

例6-47 ロールへの権限の付与

DBMCLI> GRANT PRIVILEGE list on alerthistory ATTRIBUTES alertAction,alertMessage  \
WITH OPTIONS detail TO ROLE dbmonitor

例6-48 すべての属性とオプションのロールへの付与

DBMCLI> GRANT PRIVILEGE { ALL ACTIONS | action } ON { ALL OBJECTS | object } to ROLE role1

例6-49 指定のアクション、オブジェクトおよび属性のすべてのオプションの付与

DBMCLI> GRANT PRIVILEGE { ALL ACTIONS | action } ON { ALL OBJECTS | object }  \
ATTRIBUTES attribute1 [, attribute2, ...] to ROLE role1

例6-50 指定のアクション、オブジェクトおよびオプションのすべての属性の付与

DBMCLI> GRANT PRIVILEGE { ALL ACTIONS | action } ON { ALL OBJECTS | object }   \
WITH OPTIONS option1 [, option, ...] to ROLE role1

6.7.5.2 GRANT ROLE

用途

GRANT ROLEコマンドは、ユーザーにロールを設定します。

構文

GRANT ROLE { ALL | role1 [, role2, ...] } TO USER { ALL | user1 [, user2...] }

使用上の注意

- roleはロールの名前です。

- ALL引数は、ユーザーにすべてのロールを付与します。

- TO USER ALL引数は、すべてのユーザーにロールを付与します。

例6-51 ユーザーへのロールの付与

この例は、ユーザーにロールを付与する方法を示しています。

DBMCLI> GRANT ROLE dbmonitor TO USER agarcia

6.7.6 HELP

用途

HELPコマンドは、すべてのDBMCLIコマンドの構文および使用方法に関する説明を表示します。

構文

HELP [help_topic]

HELPでトピック引数を指定しない場合は、用意されているすべてのトピックの名前が表示されます。トピックを指定した場合は、そのトピックの詳細なヘルプ・テキストが表示されます。

例6-52は、HELPコマンドの例を示しています。

例6-52 HELPコマンドを使用したヘルプ・テキストの表示

DBMCLI> HELP
DBMCLI> HELP ALTER
DBMCLI> HELP DROP ALERTHISTORY

6.7.7 LIST

用途

LISTコマンドは、データベース・サーバー・オブジェクトの属性のリストを表示します。表示されるオブジェクトは、名前またはフィルタで識別されます。表示される各オブジェクトの属性は、指定した属性リストで決定されます。

構文

LIST object_type  [ name |  attribute_filters] [attribute_list]
[DETAIL] [ORDER BY order_by_attribute_list] [LIMIT integer]

使用上の注意

- object_typeは次のとおりです。

- ALERTDEFINITION

- ALERTHISTORY

- DBSERVER

- IBPORT

- LUN

- METRICCURRRENT

- METRICDEFINITION

- METRICHISTORY

- PHYSICALDISK

- ROLE

- THRESHOLD

- USER

- DETAILオプションまたは属性リストを指定せずにobject_typeのみを指定してLISTを使用すると、このタイプの既存のオブジェクトの名前または属性のデフォルト・リストが表示されます。

- status属性を持つオブジェクト・タイプの場合は、オブジェクト名およびステータスが表示されます。

- METRICHISTORYオブジェクト・タイプの場合は、収集時間、オブジェクト名および値が表示されます。

- PHYSICALDISKおよびLUNオブジェクト・タイプの場合は、ID属性が表示されます。

- ALERTHISTORYオブジェクト・タイプの場合は、時間およびアラート・メッセージが表示されます。

- KEYオブジェクト・タイプの場合は、キー値が表示されます。

- 表示される各オブジェクトの属性は、指定した属性リストで決定されます。空白またはタブを含む文字列である属性値は、引用符で囲む必要があります。

- 表示されるオブジェクトは、属性フィルタにより決定されます。メトリックの数は多いため、コマンドの出力を絞り込む場合はLIST METRICCURRENTまたはLIST METRICHISTORYコマンドの使用時にフィルタを使用してください。

- DETAILオプションのないデフォルトの書式では、各オブジェクトが個別の行に表示され、指定した属性リストの順にタブで区切られた属性値が続きます。

- DETAILを使用した書式の場合は、特定のオブジェクトの各属性が個別の行に表示され、属性名の後に値が表示されます。属性リストが指定されていない場合は、値を持つすべての属性が表示されます。表示される各オブジェクトは、空白行で区切られます。DETAILはATTRIBUTES ALLオプションに似ていますが、書式のみが異なります。

- 設定されていない属性は、DETAILオプションでは表示されません。これに対し、空の値に設定されている属性はDETAILオプションで表示されます。

- ORDER BYにより、属性の昇順または降順でオブジェクトに順序が付けられます。デフォルトは昇順です。

- LIMITにより、表示するオブジェクト数の制限が設定されます。

関連項目:

- オブジェクト・タイプの詳細は、「DBMCLIのオブジェクト・タイプについて」を参照してください。

- 属性リストの詳細は、「LISTコマンドの属性リスト」を参照してください。

- 属性フィルタの詳細は、「LISTコマンドの属性フィルタ」を参照してください。

6.7.7.1 LIST ALERTDEFINITION

用途

LIST ALERTDEFINITIONコマンドは、データベース・サーバー上で使用可能なすべてのアラートのソースを示します。

構文

LIST ALERTDEFINITION [ name |  attribute_filters ]  [attribute_list]  [DETAIL]

使用上の注意

表示可能な属性のリストは、例6-30に示されています。

例

例6-53は、ALERTDEFINITIONオブジェクトを指定したLISTコマンドを示しています。

例6-53 ALERTDEFINITIONの属性の表示

DBMCLI> LIST ALERTDEFINITION HardwareAlert DETAIL
name:                   HardwareAlert
alertShortName:         Hardware
alertSource:            Hardware
alertType:              Stateless
description:            "Hardware Alert"
metricName:

6.7.7.2 LIST ALERTHISTORY

用途

LIST ALERTHISTORYコマンドは、データベース・サーバーで発生したすべてのアラートを表示します。

構文

LIST ALERTHISTORY [ name |  attribute_filters ]  [attribute_list]  [DETAIL]

使用上の注意

表示可能な属性のリストは、例6-31に示されています。

WHERE句にageInMInutes属性を追加すると、経過時間が指定範囲内のアラートのみをリスト表示するように指定できます。たとえば、次のコマンドでは、直前の15分間に作成されたアラートが表示されます。

DBMCLI> LIST ALERTHISTORY WHERE ageInMinutes < 15

例

例6-54は、ALERTHISTORYオブジェクトを指定したLISTコマンドを示しています。

例6-54 ALERTHISTORYの属性の表示

DBMCLI> LIST ALERTHISTORY 1_1 DETAIL
name:                   1_1
alertDescription:       "Data hard disk of size 300GB in slot 3 entered
predictive failure status"
alertMessage:           "Data hard disk entered predictive failure status.
Status        : WARNING - PREDICTIVE FAILURE
Manufacturer  : HITACHI  Model
Number  : H103030SCSUN300G  Size          : 300GB
Serial Number : 1026GZKMDE
Firmware      : A2A8  Slot Number   : 3"
alertSequenceID:        1
alertShortName:         Hardware
alertType:              Stateful
beginTime:              2014-09-22T20:18:23-05:00
examinedBy:
metricObjectName:       252:3
notificationState:      0
sequenceBeginTime:      2014-09-22T20:18:23-05:00
severity:               critical
alertAction:            "Informational. The hard disk has entered
predictive failure status. A white DB server locator LED has been turned on to
help locate the affected cell, and an amber service action LED has been lit on the
drive to help locate the affected drive. Detailed information on this problem can
be found at
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1112995.1
Automatic Service Request has been notified with Unique Identifier:
c84839be-e8d8-4e5e-b315-e145ccd7cbc8."

6.7.7.3 LIST DBSERVER

用途

LIST DBSERVERコマンドは、データベース・サーバーで発生したすべてのアラートを表示します。

構文

LIST DBSERVER [ name |  attribute_filters ]  [attribute_list]  [DETAIL]

使用上の注意

表示可能な属性のリストは、例6-32に示されています。

例

例6-55は、LIST DBSERVER DETAILコマンドの出力を示しています。

例6-56は、rescuePlan属性の値を表示する方法を示しています。

例6-55 DBSERVERの属性の表示

DDBMCLI> LIST DBSERVER DETAIL
name:                   myexadb03
bbuStatus:              normal
cpuCount:               24
diagHistoryDays:        7
fanCount:               16/16
fanStatus:              normal
id:                     1029FMM085
interconnectCount:      2
ipaddress1:             192.168.10.25/22
kernelVersion:          2.6.39-400.220.0.el6uek.x86_64
locatorLEDStatus:       on
makeModel:              Oracle Corporation SUN FIRE X4170 M2 SERVER
metricHistoryDays:      7
msVersion:              OSS_MAIN_LINUX.X64_140921
powerCount:             2/2
powerStatus:            normal
releaseImageStatus:     success
releaseVersion:         12.1.2.1.0.140728
releaseTrackingBug:     17885582
snmpSubscriber:
host=10.133.131.130,port=162,community=public,type=asr
status:                 online
temperatureReading:     20.0
temperatureStatus:      normal
upTime:                 55 days, 5:12
msStatus:               running
rsStatus:               running

DBMCLI> LIST DBSERVER attributes status,uptime
online  161 days, 3:11

例6-56 rescuePlan属性の表示

DDBMCLI> LIST DBSERVER ATTRIBUTES rescuePlan

CREATE ROLE "listdbserverattrs"

GRANT PRIVILEGE list ON dbserver ATTRIBUTES bbuStatus, coreCount WITH all options TO ROLE "listdbserverattrs"

ALTER DBSERVER diagHistoryDays="7", metricHistoryDays="7", bbuLearnSchedule="MONTH 1 DATE 17 HOUR 2 MINUTE 0", alertSummaryStartTime="2016-09-26T08:00:00-07:00", alertSummaryInterval=weekly, pendingCoreCount="128" force

6.7.7.4 LIST DIAGPACK

用途

LIST DIAGPACKコマンドは、システムの診断パッケージをそのステータスとともにリストします。

構文

LIST DIAGPACK [DETAIL]

使用上の注意

診断パッケージの場所は/opt/oracle/dbserver/dbms/deploy/logです。

例

例6-57 「list diagpack」コマンドの出力

この例は、LIST DIAGPACKコマンドの出力を示します。

DBMCLI> LIST DIAGPACK
scaqaa04adm01_2016_06_07T12_28_23_17_1.tar.bz2
scaqaa04adm01_2016_04_11T12_51_05_16_1.tar.bz2

例6-58 DETAILオプション付きの「list diagpack」コマンドの出力

この例は、DETAILオプション付きのLIST DIAGPACKコマンドの出力を示します。

DBMCLI> LIST DIAGPACK DETAIL
name:                   scaqaa04adm01_2016_06_07T12_28_23_17_1.tar.bz2
alertDescription:       "Hard disk of size 600GB in slot 5 failed"
alertName:              17_1
diagPackHostName:       scaqaa04adm01
packStartTime:          2016-06-07T12:28:23-07:00

name:                   scaqaa04adm01_2016_04_11T12_51_05_16_1.tar.bz2
alertDescription:       "InfiniBand Port HCA-4:1 may require attention. State:Down, Physical State:Disabled."
alertName:              16_1
diagPackHostName:       scaqaa04adm01
packStartTime:          2016-04-11T12:51:05-07:00

関連トピック

- CREATE DIAGPACK

6.7.7.5 LIST IBPORT

用途

LIST IBPORTコマンドは、指定した属性およびフィルタで決定されるInfiniBandポートの属性を表示します。

構文

LIST IBPORT  [ name |  attribute_filters ]  [attribute_list] [DETAIL]

使用上の注意

表示可能な属性のリストは、例6-33に示されています。

サーバー上の両方のInfiniBandポートのactiveSlave属性が一覧表示されない場合は、アクティブ-アクティブ・ボンディングが使用されています。activeSlave属性がTRUEの場合は、アクティブ-パッシブ・ボンディングが使用されています。

例

例6-59は、IBPORTオブジェクトを指定したLISTコマンドおよび対応する出力を示しています。

例6-59 IBPORTの属性の表示

DBMCLI> LIST IBPORT
HCA-1:1         Active
HCA-1:2         Active

DBMCLI> LIST IBPORT DETAIL
name:                   HCA-1:1
activeSlave:            TRUE
dataRate:               "40 Gbps"
hcaFWVersion:           2.7.0
id:                     0x00212800013e8c67
lid:                    20
linkDowned:             0
linkIntegrityErrs:      0
linkRecovers:           0
physLinkState:          LinkUp
portNumber:             1
rcvConstraintErrs:      0
rcvData:                84653709
rcvErrs:                0
rcvRemotePhysErrs:      0
status:                 Active
symbolErrs:             0
vl15Dropped:            0
xmtConstraintErrs:      0
xmtData:                84572496
xmtDiscards:            0

name:                   HCA-1:2
activeSlave:            FALSE
dataRate:               "40 Gbps"
hcaFWVersion:           2.7.0
id:                     0x00212800013e8c68
lid:                    21
linkDowned:             0
linkIntegrityErrs:      0
linkRecovers:           0
physLinkState:          LinkUp
portNumber:             2
rcvConstraintErrs:      0
rcvData:                79355427
rcvErrs:                0
rcvRemotePhysErrs:      0
status:                 Active
symbolErrs:             0
vl15Dropped:            0
xmtConstraintErrs:      0
xmtData:                79274016
xmtDiscards:            0

6.7.7.6 LIST LUN

用途

LIST LUNコマンドは、指定した属性およびフィルタで決定されるLUNの属性を表示します。

構文

LIST LUN [ name |  attribute_filters ]  [attribute_list] [DETAIL]

使用上の注意

表示可能な属性のリストは、例6-34に示されています。

例

例6-60は、LUNオブジェクトを指定したLISTコマンドおよび対応する出力を示しています。

例6-60 LUNの属性の表示

DBMCLI> LIST LUN
0_0     0_0     normal

DBMCLI> LIST LUN 0_0 DETAIL
name:                   0_0
diskType:               HardDisk
id:                     0_0
lunSize:                556.9289999008179G
lunUID:                 0_0
raidLevel:              5
lunWriteCacheMode:      "WriteBack, ReadAheadNone, Direct,   \
No Write Cache if Bad BBU"
status:                 normal

6.7.7.7 LIST METRICCURRENT

用途

LIST METRICCURRENTコマンドは、すべてのメトリックを収集したリストを表示します。

構文

LIST METRICCURRENT [ name |  attribute_filters ]  [attribute_list]  [DETAIL]

使用上の注意

- 表示可能な属性のリストは、例6-35に示されています。

- LIST METRICCURRENTコマンドの実行時の出力サイズを減らすには、フィルタを使用します。

例

例6-61は、METRICCURRRENTオブジェクトの情報を表示するため、フィルタを指定したLISTコマンドおよび対応する出力を示しています。

例6-61 METRICCURRENTの属性の表示

DBMCLI> LIST METRICCURRENT attributes name, objecttype
DS_BBU_CHARGE           DBSERVER
DS_BBU_TEMP             DBSERVER
DS_CPUT                 DBSERVER
DS_CPUT_MS              DBSERVER
DS_FANS                 DBSERVER
DS_FSUT                 DBSERVER_FILESYSTEM
DS_FSUT                 DBSERVER_FILESYSTEM
DS_FSUT                 DBSERVER_FILESYSTEM
DS_MEMUT                DBSERVER
DS_MEMUT_MS             DBSERVER
DS_RUNQ                 DBSERVER
DS_SWAP_IN_BY_SEC       DBSERVER
DS_SWAP_OUT_BY_SEC      DBSERVER
DS_SWAP_USAGE           DBSERVER
DS_TEMP                 DBSERVER
DS_VIRTMEM_MS           DBSERVER
N_HCA_MB_RCV_SEC        DBSERVER
N_HCA_MB_TRANS_SEC      DBSERVER
N_IB_MB_RCV_SEC         IBPORT
N_IB_MB_RCV_SEC         IBPORT
N_IB_MB_TRANS_SEC       IBPORT
N_IB_MB_TRANS_SEC       IBPORT
N_IB_UTIL_RCV           IBPORT
N_IB_UTIL_RCV           IBPORT
N_IB_UTIL_TRANS         IBPORT
N_IB_UTIL_TRANS         IBPORT
N_NIC_KB_RCV_SEC        DBSERVER
N_NIC_KB_TRANS_SEC      DBSERVER
N_NIC_NW                DBSERVER

DBMCLI> LIST METRICCURRENT where objectType='IBPORT'
N_IB_MB_RCV_SEC         HCA-1:1         0.026 MB/sec
N_IB_MB_RCV_SEC         HCA-1:2         0.009 MB/sec
N_IB_MB_TRANS_SEC       HCA-1:1         0.021 MB/sec
N_IB_MB_TRANS_SEC       HCA-1:2         0.004 MB/sec
N_IB_UTIL_RCV           HCA-1:1         0.0 %
N_IB_UTIL_RCV           HCA-1:2         0.0 %
N_IB_UTIL_TRANS         HCA-1:1         0.0 %
N_IB_UTIL_TRANS         HCA-1:2         0.0 %

DBMCLI> LIST METRICCURRENT where name = DS_CPUT and metricobjectname= myexadb04 detail
name:                   DS_CPUT
alertState:             normal
collectionTime:         2014-03-13T16:15:25-05:00
metricObjectName:       myexadb04
metricType:             Instantaneous
metricValue:            0.9 %
objectType:             DBSERVER

DBMCLI> LIST METRICCURRENT DS_FSUT
DS_FSUT         /       50 %
DS_FSUT         /boot   18 %
DS_FSUT         /u01    82 %

関連トピック

- LISTコマンドの属性フィルタ

6.7.7.8 LIST METRICDEFINITION

用途

LIST METRICDEFINITIONコマンドは、データベース・サーバーのメトリック定義のリストを表示します。

構文

LIST METRICDEFINITION [ name |  attribute_filters ]  [attribute_list]  [DETAIL]

使用上の注意

表示可能な属性のリストは、例6-36に示されています。

例

例6-62は、METRICDEFINITIONオブジェクトを指定したLISTコマンドおよび対応する出力を示しています。

例6-62 METRICDEFINITIONの属性の表示

DBMCLI> LIST METRICDEFINITION
DS_BBU_CHARGE
DS_BBU_TEMP
DS_CPUT
DS_CPUT_MS
DS_FANS
DS_FSUT
DS_MEMUT
DS_MEMUT_MS
DS_RUNQ
DS_SWAP_IN_BY_SEC
DS_SWAP_OUT_BY_SEC
DS_SWAP_USAGE
DS_TEMP
DS_VIRTMEM_MS
N_HCA_MB_RCV_SEC
N_HCA_MB_TRANS_SEC
N_IB_MB_RCV_SEC
N_IB_MB_TRANS_SEC
N_IB_UTIL_RCV
N_IB_UTIL_TRANS
N_NIC_KB_RCV_SEC
N_NIC_KB_TRANS_SEC
N_NIC_NW

6.7.7.9 LIST METRICHISTORY

用途

LIST METRICHISTORYコマンドは、各メトリックのリストを表示します。

構文

LIST METRICHISTORY [ name |  attribute_filters ]  [attribute_list]
{over_specification] [MEMORY] [DETAIL]

使用上の注意

- 表示可能な属性のリストは、例6-37に示されています。

- メトリック履歴エントリ・ファイルの保存期間は、metricHistoryDaysデータベース・サーバー属性で指定されます。この設定は、DBMCLIのALTER DBSERVERコマンドで変更できます。

- over_specificationの構文は次のとおりです。

OVER number [aggregation_type [aggregation_type]...]

この構文で、numberは集計のための時間(分単位)です。aggregation_typeには、max、minまたはavgを指定できます。

- WHERE句にageInMinutes属性を追加すると、経過時間が指定範囲内のメトリックのみをリスト表示するように指定できます。たとえば、次のコマンドでは、直前の15分間に作成されたメトリックが表示されます。

DBMCLI> LIST METRICHISTORY WHERE ageInMinutes < 15

例

例6-63は、nameおよびcollectionTime属性を指定したLIST METRICHISTORYコマンドを示しています。

例6-64は、ds_cput属性を指定したLIST METRICHISTORYコマンドを示しています。

例6-63 NameおよびCollectionTime属性を使用したMETRICHISTORYの表示

DBMCLI> LIST METRICHISTORY WHERE name LIKE 'DS_.*' AND collectionTime > '2014-03-27T17:48:16-05:00'

DS_FANS                 myexadb03       16              2014-03-27T17:49:15-05:00
DS_TEMP                 myexadb03       20.0 C          2014-03-27T17:49:15-05:00
DS_BBU_CHARGE           myexadb03       52.0 %          2014-03-27T17:49:16-05:00
DS_BBU_TEMP             myexadb03       45.0 C          2014-03-27T17:49:16-05:00
DS_CPUT                 myexadb03       0.3 %           2014-03-27T17:49:16-05:00
DS_CPUT_MS              myexadb03       0.0 %           2014-03-27T17:49:16-05:00
DS_FSUT                 /               73 %            2014-03-27T17:49:16-05:00
DS_FSUT                 /boot           18 %            2014-03-27T17:49:16-05:00
DS_FSUT                 /u01            43 %            2014-03-27T17:49:16-05:00
DS_MEMUT                myexadb03       42 %            2014-03-27T17:49:16-05:00
DS_MEMUT_MS             myexadb03       0.3 %           2014-03-27T17:49:16-05:00
DS_MEMUT_MS             myexadb03       0.3 %           2014-03-27T17:49:16-05:00
DS_RUNQ                 myexadb03       0.2             2014-03-27T17:49:16-05:00
DS_SWAP_IN_BY_SEC       myexadb03       0.0 KB/sec      2014-03-27T17:49:16-05:00
DS_SWAP_OUT_BY_SEC      myexadb03       0.0 KB/sec      2014-03-27T17:49:16-05:00
DS_SWAP_USAGE           myexadb03       0 %             2014-03-27T17:49:16-05:00
DS_VIRTMEM_MS           myexadb03       981 MB          2014-03-27T17:49:16-05:00
DS_VIRTMEM_MS           myexadb03       981 MB          2014-03-27T17:49:16-05:00

例6-64 ds_cput属性のMETRICHISTORYの表示

DBMCLI> LIST METRICHISTORY ds_cput OVER 10 MIN MAX MEMORY
DS_CPUT  myexadb03  1.0 %   2014-03-27T16:59:16-05:00       0.3 %   1.0 %
DS_CPUT  myexadb03  0.7 %   2014-03-27T17:09:16-05:00       0.2 %   0.8 %
DS_CPUT  myexadb03  0.7 %   2014-03-27T17:19:16-05:00       0.3 %   1.1 %
DS_CPUT  myexadb03  0.7 %   2014-03-27T17:29:16-05:00       0.3 %   0.9 %
DS_CPUT  myexadb03  0.7 %   2014-03-27T17:39:16-05:00       0.2 %   0.8 %
DS_CPUT  myexadb03  0.8 %   2014-03-27T17:49:16-05:00       0.3 %   0.8 %

関連項目:

- メトリック履歴の変更の詳細は、「ALTER DBSERVER」を参照してください。

- metricHistoryDaysセル属性の詳細は、「DESCRIBE DBSERVER」を参照してください。

- 属性フィルタの詳細は、「LISTコマンドの属性フィルタ」を参照してください。

6.7.7.10 LIST PHYSICALDISK

用途

LIST PHYSICALDISKコマンドは、指定した属性およびフィルタで決定される1つ以上の物理ディスクの属性を表示します。

構文

LIST PHYSICALDISK [ name |  attribute_filters ]  [attribute_list]  [DETAIL]

使用上の注意

表示可能な属性のリストは、例6-38に示されています。

例

例6-65は、PHYSICALDISKオブジェクトを指定したLISTコマンドおよび対応する出力を示しています。

例6-65 物理ディスクの属性の表示

DBMCLI> LIST PHYSICALDISK
252:0   G08VKE  normal
252:1   GYVAXE  normal
252:2   G07Z5E  normal
252:3   G0889E  normal

6.7.7.11 LIST ROLE

用途

LIST ROLEコマンドは、ロールに指定した属性を表示します。

構文

LIST ROLE [name | filters] [attribute_list] [DETAIL]

使用上の注意

- nameはロールの名前です。

- filtersは、表示するロールを決定する式です。

- attribute_listは、表示する属性です。ALLオプションを使用して、すべての属性を表示できます。

- DETAILオプションは、各値の前に属性ディスクリプタを付けて、各行で出力を属性としてフォーマットします。

例

例6-66は、LIST ROLEコマンドを示しています。

例6-66 ロールの表示

DBMCLI> LIST ROLE DETAIL

DBMCLI> LIST ROLE where name like 'db_*'

6.7.7.12 LIST THRESHOLD

用途

LIST THRESHOLDコマンドは、指定した属性およびフィルタで決定される1つ以上のしきい値の属性を表示します。

構文

LIST THRESHOLD [ name |  attribute_filters ]  [attribute_list] [DETAIL]

使用上の注意

表示可能な属性のリストは、例6-40に示されています。

例

例6-67は、THRESHOLDオブジェクトを指定したLISTコマンドおよび対応する出力を示しています。

例6-67 しきい値の属性の表示

DBMCLI> LIST THRESHOLD
DS_CPUT.myexadb04
DS_TEMP.myexadb04

DBMCLI> LIST THRESHOLD DS_CPUT.myexadb04 detail
name:                   DS_CPUT.myexadb04
comparison:             >
warning:                90.0

DBMCLI> LIST THRESHOLD DS_TEMP.myexadb04 detail
name:                   DS_TEMP.myexadb04
comparison:             >
critical:               30.0

6.7.7.13 LIST USER

用途

LIST USER コマンドは、ユーザーに指定した属性を表示します。

構文

LIST USER [name | filters] [attribute_list] [DETAIL]

使用上の注意

- nameはユーザー名です。

- filtersは、表示するユーザーを決定する式です。

- attribute_listは、表示する属性です。ALLオプションを使用して、すべての属性を表示できます。

- DETAILオプションは、各値の前に属性ディスクリプタを付けて、各行で出力を属性としてフォーマットします。

例

例6-68は、LIST USERコマンドを示しています。

例6-68 LIST USERコマンドの使用

DBMCLI> LIST USER DETAIL

DBMCLI> LIST USER where name like 'jdoe' DETAIL
name:                   jdoe
roles:                  role=db_monitor
Privileges:             object=dbserver
verb=list
attributes=all attributes
options= all options

6.7.8 REVOKE

用途

REVOKEコマンドは、権限およびロールを削除します。

構文

REVOKE object_type [name] FROM sub_object_type [sub_object_name]

使用上の注意

- object_typeは次のとおりです。

- PRIVILEGE

- ROLE

- PRIVILEGEオブジェクト・タイプには次を使用できます。

- nameの書式は、次のとおりです。

{ ALL ACTIONS | action } ON { ALL OBJECTS | object }  { ALL ATTRIBUTES | \
ATTRIBUTES attribute1 [, attribute2, ...] }  { WITH ALL OPTIONS |        \
WITH OPTIONS option1 [, option2, ...] }

- sub_object_typeはROLEである必要があります。

- sub_object_nameは、ロール名、ロール名のカンマ区切りのリストまたはキーワードALLです。

- ROLEオブジェクト・タイプには次を使用できます。

- nameは、ロール名、ロール名のカンマ区切りのリストまたはキーワードALLです。

- sub_object_typeはUSERである必要があります。

- sub_object_nameは、ユーザー名、ユーザー名のカンマ区切りのリストまたはキーワードALLです。

6.7.8.1 REVOKE PRIVILEGE

用途

REVOKE PRIVILEGEコマンドは、ロールから権限を取り消します。

構文

REVOKE PRIVILEGE { ALL ACTIONS | action } ON { ALL OBJECTS | object } { ALL ATTRIBUTES | ATTRIBUTES attribute1 [, attribute2...] } { WITH ALL OPTIONS | WITH OPTIONS option1 [, option2, ...] } FROM ROLE { ALL | role1 [, role2, ...] }

使用上の注意

- actionはコマンドです。

- objectはアクションのオブジェクト・タイプです。

- attributeはオブジェクトの属性です。

- optionはオブジェクトのオプションです。

- roleは、権限を取り消すロールの名前です。

- ALL ACTIONS引数は、すべてのアクションの権限を取り消します。

- ALL OBJECTS引数は、すべてのオブジェクトの権限を取り消します。

- ALL ATTRIBUTES引数は、すべての属性の権限を取り消します。

- WITH ALL OPTIONS引数は、すべてのオプションの権限を取り消します。

例

例6-69は、REVOKE PRIVILEGEコマンドを示しています。

例6-69 権限の取消し

DBMCLI> REVOKE PRIVILEGE ALL ACTIONS ON ALL OBJECTS ALL ATTRIBUTES -
WITH ALL OPTIONS FROM ROLE ALL

DBMCLI> REVOKE PRIVILEGE list ON dbserver ATTRIBUTES name     -
WITH OPTIONS detail FROM ROLE db_monitor

6.7.8.2 REVOKE ROLE

用途

REVOKE ROLEコマンドは、ユーザーのロールを取り消します。

構文

REVOKE ROLE { ALL | role1 [, role2, ...] } FROM USER { ALL | user1 [, user2...] }

使用上の注意

- role1とrole2はロールの名前です。

- user1とuser2はユーザーの名前です。

- ALL引数は、ユーザーのすべてのロールを取り消します。

- FROM USER ALL引数は、すべてのユーザーのロールを取り消します。

例

例6-70は、ユーザーからロールを取り消す方法を示しています。

例6-70 ユーザーのロールの取消し

DBMCLI> REVOKE ROLE db_monitor FROM USER jdoe

6.7.9 SET

用途

SETコマンドは、現行のセッションに対するDBMCLI環境を変更する変数を設定します。

構文

SET DATEFORMAT {LOCAL | STANDARD}
SET ECHO [ON | OFF]

使用上の注意

SET DATEFORMATコマンドでは、表示される日付形式を制御します。日付を受け入れるコマンドでは、standardの日時形式をお薦めします。local形式も受け入れられます。スクリプトでstandard形式が推奨される理由は、この形式がスクリプトの実行時に発生する可能性があるタイムゾーン、地域およびロケールの変更に依存しないためです。

SET ECHOコマンドでは、@またはSTARTで実行されるスクリプトのコマンドにエコーを設定するかどうかを制御します。ONオプションを指定すると、コマンドが画面に表示されます。OFFオプションを指定すると非表示になります。対話的に入力したコマンドやオペレーティング・システムからリダイレクトされたコマンドの表示は、SET ECHOコマンドによって影響を受けません。

例6-71 SETコマンドを使用した日付形式の設定

SET DATEFORMAT STANDARD

6.7.10 SPOOL

用途

SPOOLコマンドは、コマンドの結果を指定したファイルに書き込み(スプール)ます。

構文

SPO[OL] [file_name [ CRE[ATE] | REP[LACE] | APP[END] ] | OFF]

使用上の注意

オプションを指定せずにSPOOL file_nameを発行すると、ファイルの有無に関係なく、指定したファイルに出力がスプールされます。デフォルトの動作はREPLACEオプションです。

表6-16 SPOOLのオプション

オプション

説明

APPEND

指定したファイルの最後に結果を追加します。

CREATE

指定した名前で新しいファイルを作成し、このファイルが存在する場合、エラーが発生します。

file_name

結果が書き込まれるファイルの名前です。この名前は、完全修飾のパス名で指定できますが、現行ディレクトリの相対パスになる部分修飾のパス名で指定することもできます。

オプションなし

現在のスプールのターゲット・ファイルがある場合は、その名前を表示します。

OFF

ファイルへの書込み(スプール)出力を停止します。

REPLACE

指定した既存のファイルの内容を置き換えます。ファイルが存在しない場合は、REPLACEによってファイルが作成されます。これはデフォルトの動作です。

6.7.11 START

用途

STARTコマンドは、指定したスクリプト・ファイルでDBMCLIコマンドを実行します。

構文

STA[RT] file_name

使用上の注意

STARTオプションはfile_nameです。このオプションは、DBMCLIコマンドを含むスクリプト・ファイルの名前になります。ファイル名に完全修飾パスが含まれていない場合は、現行ディレクトリの相対パスが含まれるファイルがDBMCLIユーティリティによって検索されます。

STARTコマンドは、長いDBMCLIコマンドを入力する場合や、DBMCLIコマンドを複数入力する場合に便利です。たとえば、alter_dbserverが現行ディレクトリにある場合は、alter_dbserverという名前のテキスト・ファイルに例6-9のすべてのコマンドを入力して、次のように実行します。

START alter_dbserver

7 ExaCLIユーティリティの使用

この章では、リモートでデータベースおよびセル・ノードを管理できるExaCLIユーティリティについて説明します。

この章のトピックは、次のとおりです:

- ExaCLIの概要

- ExaCLIの構文

- ExaCLIの例

- 認証

- ユーザー管理

- ExaCLIとDBMCLI/CellCLIでのコマンドの違い

- 証明書

- URLを使用したリモートからのコマンドの実行

7.1 ExaCLIの概要

ExaCLIは、データベースおよびセル・ノードで実行されるコマンドライン管理ツールで、リモートでノードを管理できます。

ExaCLIを使用して、リモート・ノードの環境でセルとデータベース・ノードの構成およびオブジェクトを管理できます。ExaCLIは、セルまたはデータベース・ノードのイメージ化の際にインストールされます。ExaCLIでは、DBMCLIおよびCellCLIと同じコマンド構文がサポートされます。主な違いは、ExaCLIではリモート・ホストからセルおよびデータベース・ノードを管理するのに対し、DBMCLIはデータベース・ノード上で直接実行され、CellCLIはセル・ノード上で直接実行されることです。

ExaCLIを使用する主な理由には、次の2つがあります。

- 多くの企業、特に政府機関では、コンプライアンス要件の一部としてセルおよびデータベース・ノード上のrootアクセスまたはSSHサービスを無効にする必要があります。

- Exadataマシンをホストするサービス・プロバイダは、セルおよびデータベース・ノード上で実行されている仮想マシンへのアクセスを提供します。お客様が、ノードを管理するために、CellCLIまたはDBMCLIを使用して、セルまたはデータベース・ノードに対するSSHを実行することは、許可されません。

そのような場合、セルまたはデータベース・ノードを管理する方法は、リモート・ノードで実行されるExaCLIを使用することのみとなります。

ExaCLIユーティリティには、Javaバージョン1.8以上が必要です。Javaのバージョンは、"java -version"コマンドを実行して確認できます。また、適切なJavaバージョンのインストール・ディレクトリを指すようにJAVA_HOME環境変数を設定する必要があります。

次の手順では、一般的なExaCLIの使用方法について説明します。

1. DBMCLI (データベース・ノードの場合)またはCellCLI (セル・ノードの場合)を使用して、リモート・ノードでユーザーとロールを作成します。これは、ExaCLIを使用してリモート・ノードに接続することを許可されるユーザーです。ロールを使用してユーザーに権限を割り当てます。
セル・ノードの例:

次の例では、administratorロールを作成して、そのロールにすべての権限を付与します。その後、celladministratorというユーザーを作成して、そのユーザーにadministratorロールを付与します。

cellcli> create role administrator
cellcli> grant privilege all actions on all objects all attributes with all options to role administrator
cellcli> create user celladministrator password=*
cellcli> grant role administrator to user celladministrator

次の例では、グリッド・ディスクの名前属性とサイズ属性をリストする権限を持つロールを作成して、そのロールをuser1というユーザーに付与します。

cellcli> create user user1
password:************

cellcli> create role role1
Role role1 successfully created.

cellcli> GRANT PRIVILEGE list ON griddisk ATTRIBUTES name,size WITH OPTIONS
detail TO ROLE role1
Privilege [object=griddisk, verb=list, attributes=name,size, options=detail]
has been granted to role role1.

cellcli> grant role role1 to user user1

データベース・ノードの例:

次の例では、administratorロールを作成して、そのロールにすべての権限を付与します。その後、dbnodeadministratorというユーザーを作成して、そのユーザーにadministratorロールを付与します。

dbmcli> create role administrator
dbmcli> grant privilege all actions on all objects all attributes with all options to role administrator
dbmcli> create user dbnodeadministrator password=*
dbmcli> grant role administrator to user dbnodeadministrator

次の例では、データベース・サーバーの名前属性をリストする権限を持つロールを作成して、そのロールをuser1というユーザーに付与します。

dbmcli> create user user1
password:************

dbmcli> create role role1
Role role1 successfully created.

dbmcli> GRANT PRIVILEGE list ON dbserver ATTRIBUTES name WITH OPTIONS
detail TO ROLE role1
Privilege [object=dbserver, verb=list, attributes=name, options=detail]
has been granted to role role1.

dbmcli> grant role role1 to user user1

2. ExaCLIを実行し、前の手順で作成したユーザーとしてリモート・ノードに接続し、リモート・ノード上でコマンドを実行します。
セル・ノードの例:

次の例では、ExaCLIでcellnode01ノードにcelladministratorユーザーとして接続してlist cell detailコマンドを実行します。

$ exacli -l celladministrator -c cellnode01 --cookie-jar -e list cell detail
Password=*******

ログインおよびパスワードは、認証のためセル・ノードに送信されます。認証に成功すると、セル・ノードにより、ExaCLIが実行されているマシン上のCookie jarに格納されるログイン資格証明付きのCookieが返されます。

後続のコマンド実行では、以前のコマンドからのCookie jarに格納されたCookieを使用するため、ExaCLIからパスワードの入力は要求されません。

$ exacli -l celladministrator -c cellnode01 -e list griddisk detail

データベース・ノードの例:

次の例では、ExaCLIでdbnode01ノードにdbnodeadministratorユーザーとして接続してlist dbserver detailコマンドを実行します。

$ exacli -l dbnodeadministrator -c dbnode01 --cookie-jar -e list dbserver detail
Password=*******

ログインおよびパスワードは、認証のためデータベース・ノードに送信されます。認証に成功すると、データベース・ノードにより、ExaCLIが実行されているマシン上のCookie jarに格納されるログイン資格証明付きのCookieが返されます。

後続のコマンド実行では、以前のコマンドからのCookie jarに格納されたCookieを使用するため、ExaCLIからパスワードの入力は要求されません。

$ exacli -l dbnodeadministrator -c dbnode01 -e list alerthistory detail

7.2 ExaCLIの構文

ExaCLIは、オペレーティング・システムのコマンドラインから実行します。コマンドラインの構文は、次のとおりです。

exacli -c [username@]remotehost [-l username] [--xml] [--cookie-jar [filename]] [-e command]

表7-1 ExaCLIのオプション

オプション

説明

-c [username@]remotehost

--connect [username@]remotehost

接続先のリモート・ノードを指定します。ユーザー名を省略した場合は、ExaCLIから入力を要求されます。

-l username

--login-name username

リモート・ノードにログインするユーザー名を指定します。

--xml

出力をXML形式で表示します。

--cookie-jar [filename]

使用するCookie jarのファイル名を指定します。

ユーザー名およびパスワードは、認証のためリモート・ノードに送信されます。認証に成功すると、リモート・ノードにより、データベース・ノードのfilenameに格納されるCookie (ログイン資格証明)が発行されます。

filenameが指定されない場合、Cookieは、HOME/.exacli/cookiejarにあるデフォルトのCookie jarに格納されます(HOMEは、exacliコマンドを実行しているOSユーザーのホーム・ディレクトリです)。

Cookie jarファイルの権限は、rw------- (600)に設定されます。

exacliコマンドを実行しているOSユーザーがCookie-jarファイルの所有者です。

Cookie jarには、パラレル・セッションで複数のノード上の複数のユーザーからの複数のCookieを格納できます。

Cookieは、24時間後に無効化されます。

有効なCookieが存在することで、exacliユーザーは、後続のExaCLIセッションでログインを要求されることなく、コマンドの実行が許可されます。

Cookieが見つからないかまたは有効期限切れの場合は、exacliによりパスワードの入力を求められます。新しいCookieがfilenameで識別されるCookie jar、またはfilenameが指定されていない場合はデフォルトのCookie jarに格納されます。

exacliでは、--cookie-jarオプションがない場合も、デフォルトのCookie jarからCookieがチェックされます。しかし、Cookieが存在しないかまたは有効期限切れの場合、--cookie-jarオプションが指定されていないと、新しいCookieがデフォルトのCookie jarに格納されません。

-e command[; command]

-e @batchFile

実行するExaCLIコマンドまたはバッチ・ファイルのいずれかを指定します。ExaCLIはコマンドの実行後に終了します。インタラクティブなExaCLIセッションを開始するには、このオプションを省略します。

実行する複数のコマンドを指定する場合、コマンドを一重引用符で囲んで、シェルがセミコロンを解釈しないようにします。

バッチ・ファイルは、実行する1つ以上のExaCLIコマンドが含まれているテキスト・ファイルです。

--cert-proxy proxy[:port]

証明書をダウンロードするときに使用するプロキシ・サーバーを指定します。ポートを省略した場合、デフォルトはポート80です。

-n

--no-prompt

ユーザー入力を求めるメッセージを抑制します。ExaCLIがユーザーから追加情報を必要とする場合、たとえばExaCLIがユーザーにパスワードの入力を求めたり(たとえば、Cookie-jarに有効なCookieがないため)、リモート・ノードのアイデンティティを確認するよう求める必要がある場合、ExaCLIはエラー・メッセージを出力して終了します。

7.3 ExaCLIの例

セル・ノードの例1: セル・ノードcellnode01にcelladministratorユーザーとして接続します。デフォルトのCookie jarに「celladministrator」ユーザーの有効なCookieが含まれない場合、ExaCLIによりパスワードの入力が求められます。--cookie-jarオプションが指定されていないため、CookieはCookie jarには格納されません。次のコマンドは同等です。

$ exacli -l celladministrator -c cellnode01

$ exacli -c celladministrator@cellnode01

セル・ノードの例2: 認証のため、ユーザーcelladministratorおよびパスワードがcellnode01に送信されます。認証に成功すると、セル・ノードにより、デフォルトのCookie jarに格納されるCookieが送り返されます。指定されたコマンドがセル・ノードで実行されます。複数のコマンドは一重引用符で囲む必要があります。

$ exacli -l celladministrator -c cellnode01 --cookie-jar -e 'list cell; list celldisk'
Password=************

セル・ノードの例3: デフォルトのCookie jarのCookieを使用するため、ExaCLIにより、celladministratorユーザーの後続のExaCLIセッションにパスワードの入力を要求されることはありません。

$ exacli -l celladministrator -c cellnode01 -e list griddisk detail

セル・ノードの例4: ExaCLIはcellnode01ノードにcelladministratorユーザーとして接続し、認証に成功すると、commandFileでコマンドを実行します。

$ exacli -l celladministrator -c cellnode01 -e @commandFile

データベース・ノードの例1: データベース・ノードdbnode01にdbnodeadministratorユーザーとして接続します。デフォルトのCookie jarにdbnodeadministratorユーザーの有効なCookieが含まれない場合、ExaCLIによりパスワードの入力が求められます。--cookie-jarオプションが指定されていないため、CookieはCookie jarには格納されません。次のコマンドは同等です。

$ exacli -l dbnodeadministrator -c dbnode01

$ exacli -c dbnodeadministrator@dbnode01

データベース・ノードの例2: 認証のため、ユーザーdbnodeadministratorおよびパスワードがdbnode01に送信されます。認証に成功すると、データベース・ノードにより、デフォルトのCookie jarに格納されるCookieが送り返されます。指定されたコマンドがデータベース・ノードで実行されます。複数のコマンドは一重引用符で囲む必要があります。

$ exacli -l dbnodeadministrator -c dbnode01 --cookie-jar -e 'list dbserver; list alerthistory'
Password=************

データベース・ノードの例3: デフォルトのCookie jarのCookieを使用するため、ExaCLIにより、dbnodeadministratorユーザーの後続のExaCLIセッションにパスワードの入力を要求されることはありません。

$ exacli -l dbnodeadministrator -c dbnode01 -e list alerthistory

データベース・ノードの例4: ExaCLIはdbnode01ノードにdbnodeadministratorユーザーとして接続し、認証に成功すると、commandFileでコマンドを実行します。

$ exacli -l dbnodeadministrator -c dbnode01 -e @commandFile

7.4 認証

ExaCLIではリモート・ノード上でDBMCLIおよびCellCLIコマンドを実行するため、ユーザーは、コマンドを実行する前に認証される必要があります。認証プロセスは、各ExaCLIセッションで実行されます。

有効なCookieが存在することで、ExaCLIユーザーは、各セッションでログインを要求されることなく、コマンドの実行が許可されます。Cookieは、リモート・ノードにより発行され、ExaCLIが実行されているホスト・マシンに格納される、ログイン資格証明を含むトークンです。リモート・ノードにより発行されたCookieは、24時間後に無効化されます。Cookieリポジトリは、Cookie jarと呼ばれます。

同じCookie jarを複数のリモート・ノードに接続する複数の同時ExaCLIセッションで使用でき、異なるログイン名を使用している場合でも可能です。たとえば、exadcliでは複数のExaCLIセッションを使用して複数のリモート・ノードに接続しますが、それらはすべて同じCookie jarを使用します。

Cookie jarは、OSユーザーの読取りおよび書込み権限付きで構成されています。その他の誰も、このファイルの読取り、書込みまたは実行ができません。

7.5 ユーザー管理

ExaCLIを使用するには、リモート・ノード上でユーザーを作成する必要があり、そのユーザーに対してそのユーザーにふさわしい権限を持つロールを割り当てる必要があります。

ユーザーおよびロールの作成は、DBMCLIまたはCellCLIを使用して直接リモート・ノード上でのみ実行できます。

セル・ノードの例: 次の例では、すべての権限を持つcelladministratorというユーザーを作成します。

cellcli> create role administrator
cellcli> grant privilege all actions on all objects all attributes with all options to role administrator
cellcli> create user celladministrator password=*
cellcli> grant role administrator to user celladministrator

セル・ノードの例: 次の例では、オブジェクトの詳細を表示する権限を持つcellmonというユーザーを作成します。

cellcli> create role monitor
cellcli> grant privilege list on all objects all attributes with all options to role monitor
cellcli> create user cellmon password=*
cellcli> grant role monitor to user cellmon

データベース・ノードの例: 次の例では、すべての権限を持つdbnodeadministratorというユーザーを作成します。

dbmcli> create role administrator
dbmcli> grant privilege all actions on all objects all attributes with all options to role administrator
dbmcli> create user dbnodeadministrator password=*
dbmcli> grant role administrator to user dbnodeadministrator

データベース・ノードの例: 次の例では、オブジェクトの詳細を表示する権限を持つdbnodemonというユーザーを作成します。

dbmcli> create role monitor
dbmcli> grant privilege list on all objects all attributes with all options to role monitor
dbmcli> create user dbnodemon password=*
dbmcli> grant role monitor to user dbnodemon

関連項目:

ユーザーおよびロールの管理の詳細は、『Oracle Exadata Storage Server Softwareユーザーズ・ガイド』を参照してください。

7.6 ExaCLIとDBMCLI/CellCLIでのコマンドの違い

ExaCLIでは、DBMCLIおよびCellCLIと完全に同じコマンド構文がサポートされます。

すべてCellCLIコマンドがExaCLIを介して実行できるわけではありません。ExaCLIでは、次のコマンドはサポートされていません。

- セル・サービスの再起動(ALTER CELLコマンドの「restart」オプション)

- セル・サービスの起動(ALTER CELLコマンドの「startup」オプション)

- セル・サービスの停止(ALTER CELLコマンドの「shutdown」オプション)

- ユーザー管理コマンド(CREATE USER、ALTER USER、DROP USER)

- ロール管理コマンド(CREATE ROLE、DROP ROLE、GRANT ROLE、REVOKE ROLE)

- 権限管理コマンド(GRANT PRIVILEGE、REVOKE PRIVILEGE)

- CALIBRATE

- DESCRIBE

- HELP

- 次のセル属性の取得: LIST CELLコマンドの使用によるrsStatus、cellsrvStatus、msStatus

- SET

- SPOOL

- START

7.7 証明書

ExaCLIとリモート・ノード上で動作している管理サーバー(MS)間のすべての通信は、httpsを介して行われます。セキュリティ証明書により、リモート・ノードはExaCLIに対して自身のアイデンティティを確認できます。管理サーバーは、httpsアクセス用のデフォルトの自己署名セキュリティ証明書とともにデプロイされます。オプションで、認証局(CA)により発行された別のセキュリティ証明書をアップロードできます。

信頼性のあるCA証明書は、ExaCLIが実行されているマシン上で次のコマンドを実行することでリストできます。最初の$は、シェルのプロンプトです。

$ $JAVA_HOME/bin/keytool -list -v -keystore $JAVA_HOME/jre/lib/security/cacerts -storepass changeit

7.7.1 デフォルトの自己署名証明書の使用

セキュリティ証明書がExaCLIによって警告なしで受け入れられるには、それが信頼できる認証局(CA)によって署名されている必要があります。

ExaCLIが信頼性のあるCAによって署名されたセキュリティ証明書を持っていないリモート・ノードに接続した場合、証明書を検証するようにユーザーに要求する警告メッセージが生成されます。検証されると、ExaCLIによりセキュリティ証明書が記憶され、後続のコマンドでユーザーが証明書の再検証を求められることはありません。すべてのセルは、インストール中または管理サーバー(MS)のデプロイメント中に、自己署名証明書を使用して自動的に構成されます。

自己署名セキュリティ証明書(非CA証明書)を受け入れる例:

$ exacli -l celladministrator --cookie-jar -c cellnode01
This connection is unsecure. You have asked ExaCLI to connect to cell cellnode01 securely.
The identity of cellnode01 cannot be verified.
Got certificate from server:
CN=cellnode01,OU=Oracle Exadata,O=Oracle Corporation,L=Redwood City,ST=California,C=US
Do you want to accept and store this certificate? (Press y/n)

データベース・ノードの自己署名セキュリティ証明書(非CA証明書)を受け入れる例:

$ exacli -l dbadministrator --cookie-jar -c dbnode01
This connection is unsecure. You have asked ExaCLI to connect to dbserver dbnode01 securely.
The identity of dbnode01 cannot be verified.
Got certificate from server:
CN=dbnode01,OU=Oracle Exadata,O=Oracle Corporation,L=Redwood City,ST=California,C=US
Do you want to accept and store this certificate? (Press y/n)

7.7.2 CA認証済セキュリティ証明書の使用

Oracle Exadata Database Machineの管理者は、環境で必要な場合にCA認証済セキュリティ証明書を提供する必要があります。

有効なCA認証のセキュリティ証明書は、ExaCLIによって、プロンプトなしで、証明書の受入れを要求することなく受け入れられます。

1. セルまたは計算ノードのセキュリティ属性を変更します。

CA認証済セキュリティ証明書をアップロードするには、セルまたは計算ノードのsecurityPubKey属性とsecurityPrivKey属性を変更します。securityPubKeyとsecurityPrivKeyが、セキュアな通信のための鍵ペアを形成します。

- securityPubKey属性には、公開鍵を含むURLを指定します。

- securityPrivKey属性には、秘密鍵を含むURLを指定します。

秘密鍵が暗号化されている場合は、securityPrivKeyPW属性を使用してパスワードを指定できます。

次のコマンドは、CA認証済セキュリティ証明書をアップロードする例を示しています。

セル・ノードの例:

CellCLI> alter cell securityPubKey="http://www.acme.com/security/newkey.crt",  -
securityPrivKey="http://www.acme.com/security/newkey.key", -
securityPrivKeyPW=*

password=****************

データベース・ノードの例:

DBMCLI> alter dbserver securityPubKey="http://www.acme.com/security/newkey.crt", -
securityPrivKey="http://www.acme.com/security/newkey.key", -
securityPrivKeyPW=*

password=****************

2. セルまたは計算ノードの管理サーバーを再起動します。

CA認証済セキュリティ証明書をクラスタ内の各ノードに個別にアップロードしたら、新しいセキュリティ証明書を表示するためにMSを再起動する必要があります。

セル上で管理サーバーを再起動します。

CELLCLI> alter cell restart services ms

計算ノード上で管理サーバーを再起動します。

DBMCLI> alter dbserver restart services ms

7.8 URLを使用したリモートからのコマンドの実行

リモート・ノードでコマンドを実行するには、ExaCLIを使用する以外に、URLを使用することもできます。この場合も、「ExaCLIの概要」の説明に従って、ユーザー、ロールおよび権限を設定する必要があります。

URLの形式は次のとおりです。

https://remotenode:port/MS/RESTService/?cmd=command_to_run

リモート・ノードがセル・ノードの場合、ポートは443です。

リモート・ノードがデータベース・ノードの場合、ポートは7879です。

ブラウザでURLを送信すると、ブラウザによって、証明書に関する警告が表示されます。新しい証明書に関する警告である場合は、通常、その警告を許容できます。変更された証明書に関する警告である場合は、証明書が許容可能であることを確認する必要があります。

その後、ブラウザによって、ユーザー名およびパスワードが要求されます。

コマンドの結果は、プレーン・テキストで返されます。

同じセッションでさらにリクエストを送信した場合、セッションCookieの期限が切れないかぎり、ブラウザに証明書に関する警告が表示されることや、ユーザー名およびパスワードが要求されることはありません。

次の例では、list dbserver detailコマンドを実行します。

https://dbnode:7879/MS/RESTService/?cmd=list+dbserver+detail

次の例では、list cell detailコマンドを実行します。

https://cellnode:443/MS/RESTService/?cmd=list+cell+detail

RESTful形式でURLを指定することもできます。次に例を示します。

https://cellnode:443/MS/RESTService/celldisk/list?where=size>1g

curlを使用してURLを実行することもできます。手順は次のとおりです。

1. サーバーの証明書をダウンロードして格納します。

( openssl s_client -showcerts -connect remote_node:port < /dev/null | openssl x509 -outform PEM > mycertfile.pem ) >& /dev/null

これは1回のみ行う必要があります。有効な証明書が指定されないかぎり、curlは続行されません。

2. ユーザー名とパスワードを指定します。

curl -u username:password -c cookiejar --cacert mycertfile.pem 'https://remote_node:port /MS/RESTService/login'

3. コマンドを実行します。
データベース・ノードの例:

curl -b cookiejar --cacert mycertfile.pem 'https://remote_node:port/MS/RESTService/?cmd=list+dbserver+detail'

セル・ノードの例:

curl -b cookiejar --cacert mycertfile.pem 'https://remote_node:port/MS/RESTService/?cmd=list+cell+detail'

8 exadcliユーティリティの使用

exadcliユーティリティは、リモート・ノードのセットでExaCLIコマンドを自動的に実行し、exadcliユーティリティが実行された集中管理ロケーションに出力結果を返すことにより、Oracle Exadataシステムの集中管理を容易にします。この章のトピックは、次のとおりです:

- exadcliの概要

- exadcliの構文

- exadcliの例

8.1 exadcliの概要

exadcliユーティリティでは、複数のリモート・ノードでコマンドをパラレル・スレッドで実行します。

このユーティリティでは、リモート・ノード上のリモート・アプリケーションとの対話型セッションをサポートしていません。exadcliユーティリティは、データベース・ノードのイメージ化の際にインストールされます。

複数のリモート・ノードで実行するExaCLIコマンドを発行できます。リモート・ノードはホスト名またはIPアドレスで参照されます。dcliとは異なり、exadcliではExaCLIコマンドのみを実行できます。その他のコマンド、たとえばシェル・コマンドは、exadcliを使用して実行できません。

exadcliユーティリティを使用するには、すべてのリモート・ノードにユーザーおよびロールを設定する必要があります。exadcliは、リモート・ノードに並列に接続し、ユーザーを認証します。

指定したリモート・ノードでコピーおよびコマンド実行が終了すると、コマンド出力(stdoutおよびstderr)が収集されて表示されます。

exadcliは、プロンプトなしのモードでExaCLIを実行します。つまり、ユーザー操作が必要な場合(たとえば、パスワードを入力する必要がある場合またはリモート・ノードからの証明書が有効であることを確認する必要がある場合)、exadcliはエラーにより終了します。exadcli --authenticateを使用すると、同じパスワードを使用してすべてのセルまたはデータベース・ノードにログインできます。認証トークンがCookie jarに格納されるため、将来のexadcliセッションでパスワードを入力する必要がなくなります。

ただし、セルまたはデータベース・ノードのアイデンティティ証明書を受け入れるために、引き続きExaCLIを使用する必要があります。このことは、セルごとに1回のみ行う必要があります(セルがアップロードされた場合や、新しい証明書がリモート・データベースまたはセル・ノードにアップロードされた場合を除く)。次に例を示します。

$ exacli -l dbnodeadministrator -c dbnode01 --cookie-jar
No cookies found for user1@dbnode01.
Password: ************
EXA-30016: This connection is not secure. You have asked ExaCLI to connect to cell dbnode01 securely. The identity of dbnode01 cannot be verified. Got certificate from server:
C=US,ST=California,L=Redwood City,O=ABC Co.,OU=IT Dept,CN=dbnode01
Do you want to accept and store this certificate? (Press y/n) y
exacli user1@dbnode01>exit

すべてのセルまたはデータベース・ノードで証明書を受け入れる必要があります。

管理サーバー(MS)を再起動した場合は、exadcli --authenticateコマンドを使用してexadcliを再認証する必要があります。

$ exadcli -c dbnode01,dbnode02,dbnode03 -l dbnodeadministrator --authenticate

この時点で、exadcliを使用して次のようなコマンドを実行できます。

$ exadcli -c dbnode01,dbnode02,dbnode03 -l dbnodeadministrator list dbserver

関連項目:

ユーザー、ロールおよび権限の詳細は、「ExaCLIの概要」を参照してください。

8.2 exadcliの構文

exadcliは、次のように実行します。

exadcli [options] [command]

exadcliでは、次のオプションがサポートされます。

表8-1 exadcliのオプション

オプション

説明

-c host [,host]

--connect=host [,host]

ExaCLIコマンドの送信先となるターゲット・リモート・ノードのカンマ区切りのリストを指定します。

-g filename

--group-file=filename

コマンドの送信先のターゲット・リモート・ノードのリストを含むファイルを指定します。リモート・ノードは、ホスト名またはIPアドレスで識別できます。

-l username

--login-user=username

リモート・ノードにログインするユーザーを指定します。これは、オペレーティング・システムのユーザーではなく、dbmcliまたはセルのユーザーです。

-t

--list

-cオプションで名前を指定したターゲット・リモート・ノードまたは-gオプションで指定したグループ・ファイル内のターゲット・リモート・ノードを表示します。

-x filename

--exec-file=filename

リモート・ノードで実行するコマンド・ファイルを指定します。このコマンド・ファイルには、ExaCLIコマンドのリストが含まれています。

注意:

exadcliには対話型モードはありません。このオプションを使用して実行するコマンドを指定することも、コマンドラインの末尾でコマンドを指定することもできます。

--authenticate

ユーザー・パスワードを要求します。すべてのリモート・ノードでユーザーはパスワードを使用して認可され、認可はデフォルトのCookie jarに格納されます。

--max-lines=maxlines

リモート・ノードからの最大出力行を制限します。デフォルトは100,000行です。

--xml

これにより、出力がXML形式で表示されます。このオプションはExaCLIに渡されます。

-h

--help

ヘルプ・メッセージを表示します。

command

リモート・ノードで実行するExaCLIコマンドを指定します。複数のコマンドを指定するには、コマンドをセミコロン文字;で区切ります。

注意:

exadcliには対話型モードはありません。-xオプションを使用して実行するコマンド・ファイルを指定することも、コマンドラインの末尾でコマンドを指定することもできます。

--cookie-jar [filename]

注意:

現在ではexadcliで常にCookie jarが使用されるため、このオプションは非推奨です。

Cookie jarファイルを指定します。このオプションはExaCLIに渡されます。

exadcliからの戻り値は次のとおりです。

0: すべてのリモート・ノードで、コマンドが正常に実行されました。

1: 1つ以上のリモート・ノードにアクセスできず、リモート実行により0以外のステータスが返されました。

2: ローカルのエラーによりコマンドを実行できませんでした。

いずれかのリモート・ノードが停止しているか、応答がない場合は、メッセージがstderrに書き込まれ、応答のないリモート・ノードが表示されます。その他のリモート・ノードは操作が続行され、完了後のリターン・コードは1になります。

関連トピック

- ExaCLIの構文

8.3 exadcliの例

例1: celladministratorユーザーとしてcell01、cell02およびcell03に接続し、資格証明を~/.exacli/cookiejarに格納して、同じセルに対するそれ以降のexadcliコマンドでパスワードを要求しないようにします。

$ exadcli -c cell01,cell02,cell03 -l celladministrator --authenticate
Password:

例2: mycellsファイルにリストされているセルにcelladministratorユーザーで接続し、list cell detailコマンドを実行します。

$ cat mycells
cell01
cell02
cell03

$ exadcli -g mycells -l celladministrator list cell detail

例3: mycellsファイルにリストされているセルにcelladministratorユーザーで接続し、usercommands.txt内のExaCLIコマンドを実行します。

$ cat usercommands.txt
list cell

$ exadcli -g mycells -l celladministrator -x usercommands.txt
cell01 : cell01   online
cell02 : cell02   online
cell03 : cell03   online

例4: mydbserversファイルにリストされているデータベース・サーバーにdbadministratorユーザーで接続し、usercommands.txt内のExaCLIコマンドを実行します。

$ cat mydbservers
db01
db02
db03

$ cat usercommands.txt
list dbserver

$ exadcli -g mydbservers -l dbadministrator -x usercommands.txt
db01 : db01 online
db02 : db02 online
db03 : db03 online

A 交換ユニット

この付録では、Oracle Exadata Database MachineおよびOracle Exadata Storage拡張ラックの交換ユニットを示します。FRU(Field Replaceable Unit)およびCRU(Customer Replaceable Unit)の2つのタイプの交換ユニットがあります。FRUは、教育を受けたオラクル社のフィールド技術者によって設置されます。CRUは、お客様によって設置されます。

この付録の内容は次のとおりです。

- 修理カテゴリの理解

- 法規制および認定規格に対するコンプライアンス

- ディスク・コントローラのバッテリ

- F20 PCIeエネルギー・ストレージ・モジュール

- LEDステータスの説明

- Oracle Database Serverの部品

- Exadata Storage Serverの部品

- 「InfiniBandスイッチの部品」

- 「Ciscoスイッチの部品」

- KVMスイッチおよびKMMトレイの部品

- 「配電ユニットの部品」

- Oracle Exadataラックのケーブルおよびケーブル・アクセサリ

注意:

- 読みやすさを考慮して、Oracle Exadata Database MachineとOracle Exadata Storage拡張ラックの両方に言及する場合、「Oracle Exadataラック」という名前を使用します。

- この付録のOracle Exadata Database Machine用のすべての交換部品は、データベース・サーバーを除き、Oracle Exadata Storage拡張ラックに適用できます。

関連項目:

インストール前およびインストール後の手順の詳細は、このマニュアルのコンポーネント固有の章を参照してください。

A.1 修理カテゴリの理解

修理カテゴリでは、修理の潜在的な影響について説明します。表A-1に、カテゴリおよび処置を示します。

表A-1 Oracle Exadataラックの修理カテゴリ

カテゴリ

説明

シナリオ例

Hot Swap (HS)

修理部品がホット・スワップ可能なので、ホスト・システムを停止しないで交換できます。データ保護のために交換の前後にコマンドが必要になる場合があります。

- ディスク

- ファン

- 電源

Infrastructure Repair (IR)

Oracle Exadataラック内の接続コンポーネントの修理。ラックの停止時間はありませんが、個別のコンポーネントに停止時間が必要になる場合があります。

- 外部ケーブル

- InfiniBandスイッチ

- イーサネット・スイッチ

- KVMスイッチ/KMMトレイ

Database Server Offline(DBO)

部品を修理するには、Oracle Exadata Database Machine内の1台のデータベース・サーバーを停止する必要があります。ラックの停止時間はありませんが、個別のサーバー・ノードが停止して、一時的にクラスタの外部で処理される場合があります。

現在システムを実行している場合、正常に停止する必要があります。詳細は、「Oracle Exadataラックの電源の投入および切断」を参照してください。

Oracle Enterprise Manager Grid Controlを使用してシステムを監視する場合、ターゲットをブラックアウト状態にして不要なアラートを回避します。詳細は、『Oracle Enterprise Manager Cloud Control管理者ガイド』を参照してください。

- システム・ボード

- PCIeカード

- メモリー

- プロセッサ

- 配電ユニット

Exadata Storage Server Offline(EBO)

部品を修理するには、Oracle Exadataラック内の1台のExadata Storage Serverを停止する必要があります。ラックの停止時間はありませんが、個別のサーバー・ノードが停止して、一時的にクラスタの外部で処理される場合があります。データの冗長性を維持するリバランスのため、一時的にパフォーマンスに影響を与える場合があります。

現在システムを実行している場合、正常に停止する必要があります。詳細は、「Oracle Exadataラックの電源の投入および切断」を参照してください。

Oracle Enterprise Manager Grid Controlを使用してシステムを監視する場合、ターゲットをブラックアウト状態にして不要なアラートを回避します。詳細は、『Oracle Enterprise Manager Cloud Control管理者ガイド』を参照してください。

- システム・ボード

- PCIeカード

- メモリー

- プロセッサ

A.2 法規制および認定規格に対するコンプライアンス

Oracle Exadata Database MachineおよびOracle Exadataラックで使用される部品は、次の法規制および認定規格に準拠します。

- 法規制

- 安全性: UL/CSA 60950-1、EN 60950-1:2006 CB Scheme(各国の基準に準拠)

- RFI/EMI: EN 55022、EN 61000-3-12

- イミュニティ: EN 55024

- 排出量とイミュニティ: EN 300 386

- 動作保証

- 北米(NRTL)、欧州連合(EU)、国際CBスキーム、BSMI (台湾)、C-Tick (オーストラリア)、CCC (中国)、MSIP (韓国)、CU EAC (関税同盟)、VCCI (日本)

- 欧州連合指令

- 2006/95/EC低電圧ディレクティブ、2004/108/EC EMCディレクティブ、2011/65/EU RoHSディレクティブ、2012/19/EU WEEEディレクティブ

注意:

法規制および認定規格に対する準拠は、規定に従い、コンポーネント・レベルで取得されている場合があります。

関連項目:

Oracle Exadata Database Machineセーフティおよびコンプライアンス・ガイド

A.2.1 電気・電子機器における特定有害物質の欧州の使用制限指令の準拠

RoHS:YまたはRoHS:YLが指定されている部品は、電気・電子機器における特定有害物質の欧州の使用制限指令に次のように準拠しています。

- RoHS:Yの準拠は、現在の情報および信用に基づいています。この機器/部品番号は、欧州連合のRoHS指令の2002/95/ECとその改訂およびガイド・ドキュメントに準拠し、法律で許可されている一部の例外を除いて均質物質の最大濃度値を超える制限物質を含みません(サーバー、ストレージおよびストレージ・アレイ・システム、切替え、信号、送信用のネットワーク・インフラストラクチャ機器および電気通信用のネットワーク管理のはんだの鉛の例外を除く)。

- RoHS:YLの準拠は、現在の情報および信用に基づいています。この機器/部品番号は、欧州連合のRoHS指令の2002/95/ECとその改訂およびガイド・ドキュメントに準拠し、法律で許可されている一部の例外を除いて均質物質の最大濃度値を超える制限物質を含みません(サーバー、ストレージおよびストレージ・アレイ・システム、切替え、信号、送信用のネットワーク・インフラストラクチャ機器および電気通信用のネットワーク管理のはんだの鉛の例外を含む)。

- 部品リストに含まれる部品の説明にRoHS:YまたはRoHS:YLの記述がない場合、その部品がRoHSに準拠していないか、準拠の確認に必要な情報が製品チームから提供されていないことを示します。

A.3 ディスク・コントローラのバッテリ

Exadata Storage Serverおよびデータベース・サーバーのディスク・コントローラには、書込みパフォーマンスを高速化するバッテリ・バックアップ式の書込みキャッシュがあります。

この項は、バッテリを使用するシステムにのみ適用されます。 Oracle Exadata Database Machine X6にバッテリはありません。より新しいマシンには、バッテリではなくスーパー・キャップであるCVPM02 (Cache Vault)が備えられています。

充電容量が低下して48時間以上電力の供給されないキャッシュ・データをバッテリで保護できない場合、書込みキャッシュが無効になり、ディスク・コントローラがライトスルー・モードに切り替わります。これにより、書込みパフォーマンスが低下しますが、データは失われません。充電容量が不十分であるか温度が高い場合およびバッテリを交換する必要がある場合、Exadata Storage Serverがアラートを生成します。

バッテリの充電容量は徐々に低下し、寿命は動作温度と反比例します。最低の条件下のOracle Exadataラックのバッテリ寿命は、次のとおりです。

インレット環境の温度

バッテリの寿命

< 摂氏25度(華氏77度)

3年

< 摂氏32度(華氏89.6度)

2年

A.3.1 データベース・サーバーのバッテリの監視

データベース・サーバーのバッテリ充電容量は、次のコマンドを使用して監視できます。

# /opt/MegaRAID/MegaCli/MegaCli64 -AdpBbuCmd -a0 | grep "Full Charge" -A5 | sort \
| grep Full -A1

次に、コマンドの出力例を示します。

Full Charge Capacity: 1357 mAh
Max Error: 2 %

バッテリの事前交換は、バッテリの容量が800mAhを下回り、最大エラー率が10%を下回る場合に行います。容量が674mAhを下回るか、最大エラー率が10%を超えた場合は、ただちにバッテリを交換してください。

バッテリの温度は、次のコマンドを使用して監視できます。

/opt/MegaRAID/MegaCli/MegaCli64 -AdpBbuCmd -a0 | grep BatteryType; \
/opt/MegaRAID/MegaCli/MegaCli64 -AdpBbuCmd -a0 | grep -i temper

次に、コマンドの出力例を示します。

BatteryType: iBBU08
Temperature: 38 C
Temperature                  : OK
Over Temperature        : No

バッテリの温度が摂氏55度以上である場合は、原因を特定し、問題を解決してください。

注意:

充電容量が不十分であるか温度が高い場合およびバッテリを交換する必要がある場合、Exadata Storage Serverがアラートを生成します。

A.3.2 ディスク・コントローラのバッテリの交換

ディスク・コントローラの充電容量が最小しきい値を下回った場合、システムがOracle Premier Support for Systemsの対象または保証期間中であれば、故障したバッテリが無償で交換されます。

Premier Support for Systemsのお客様を対象に、ベスト・エフォート原則に基づいて寿命が終わる前にOracle Exadataラックのバッテリを事前に交換します。

A.4 F20 PCIeエネルギー・ストレージ・モジュール

Sun Flash Accelerator F20 PCIeカードは、頻繁にアクセスされるOracleデータベース・データをキャッシュし、Exadata Storage Serverのディスクに対する物理I/Oを不要とすることで、Oracle Exadataラックのパフォーマンスを高速化します。フラッシュ・カードに対する書込み操作は、書込み操作を高速化するためにカード上の揮発性のローカルDRAMメモリーに一時的にステージングされます。DRAM内のデータは、エネルギー・ストレージ・モジュール(ESM)によって保護されています。このモジュールは、十分な電力を提供して、電源障害の際にDRAM内のデータをローカル・フラッシュに移動します。

Oracle Exadata X3システムで使用されているフラッシュ・モジュールの予想耐久期間は、書込み集中型のアプリケーションでも10年以上です。フラッシュの耐久期間は、主に、何年にもわたってフラッシュに書き込まれる合計データ量および書き込まれるデータのタイプによって決まります。何年もの間、常時最大フラッシュ書込みIOPSで実行されるアプリケーションはありません。また、アプリケーションでは多くの読取りが実行され、アクティビティが多い期間と少ない期間があります(日中と夜間、四半期末、取引日の終了間際など)。非常に高い書込み集中型のアプリケーションで数か月にわたって測定したところ、最大フラッシュ書込みIOPSの25%が平均となります。各Exadata X3ストレージ・サーバーの耐久期間中の合計フラッシュ書込みは、一般的なデータベース・データの場合で50PBを超えます。フル・ラックでは、アプリケーションの平均書込みが10年間で250,000 8KフラッシュIOPS (最大書込みの25%)である場合、各セルに合計41PBのデータが書き込まれます。これは、セルの耐久期間中の50PBを下回ります。

ESMの充電が十分ではない場合、F20 PCIeカードは、DRAMメモリーを回避してすべてのデータを直接フラッシュに書き込むフェイルセーフのライトスルー・モードで動作します。これにより、書込みパフォーマンスが低下しますが、データは失われません。ESM容量が不十分な場合およびESMを交換する必要がある場合、Exadata Storage Serverがアラートを生成します。

ESMの充電容量は徐々に低下し、寿命は動作温度と反比例します。最低の条件下のOracle ExadataラックのESMの寿命は、次のとおりです。

Exadata Storage Serverのタイプ

寿命

Sun Fire X4275 Serverを使用したExadata Storage Server

3年

Sun Fire X4270 M2 Serverを使用したExadata Storage Server

4年

関連トピック

- ハード・ディスク・コントローラのライトスルー・キャッシュ・モードの監視

A.4.1 フラッシュESMの交換

F20 PCIe ESMの充電容量が最小しきい値を下回った場合、システムがOracle Premier Support for Systemsの対象または保証期間中であれば、故障したESMモジュールが無償で交換されます。

Premier Support for Systemsのお客様を対象に、ベスト・エフォート原則に基づいて寿命が終わる前にOracle ExadataラックのF20 PCIe ESMを事前に交換します。

A.5 LEDステータスの説明

この項では、Oracle ExadataラックのLEDについて説明します。内容は次のとおりです。

- Oracle Server X6-2 Oracle Database ServerのLED

- Oracle Server X5-2 Oracle Database ServerのLED

- Sun Server X4-2 Oracle Database ServerのLED

- Sun Server X3-2 Oracle Database ServerのLED

- Sun Fire X4170 M2 Oracle Database ServerのLED

- Sun Fire X4170 Oracle Database ServerのLED

- Oracle Server X5-8およびX6-8 Oracle Database ServerのLED

- Sun Server X4-8 Oracle Database ServerのLED

- Sun Server X2-8 Oracle Database ServerのLED

- Sun Fire X4800 Oracle Database ServerのLED

- Exadata Storage Server X5-2 Server

- Exadata Storage Server X4-2L Server

- Exadata Storage Server X3-2 Server

- Sun Fire X4270 M2 Serverを使用したExadata Storage Server

- Sun Fire X4275 Serverを使用したExadata Storage ServerのLED

- Sun Flash Accelerator F20 PCIeカードのLED

- Sun Datacenter InfiniBand Switch 36スイッチのLED

A.5.1 Oracle Server X6-2 Oracle Database ServerのLED

表A-2に、Oracle Server X6-2 Oracle Database ServerのLEDの色コードを示します。

表A-2 Oracle Server X6-2 Oracle Database ServerのLEDステータスの説明

コンポーネント

LEDステータス

Oracle Server X6-2 Oracle Database Serverのファン・モジュール

- ファン・ステータスLEDが消灯: システムの電源が投入されていて、ファン・モジュールが適切に機能しています。

- ファン・ステータスLEDが黄色: ファン・モジュールに障害があります。システムがファン・モジュールの障害を検出した場合、前面および背面パネルのサービス・アクション必須LEDも点灯します。

Oracle Server X6-2 Oracle Database Serverの電源

- 取外しOK LEDが緑色: ホット・スワップ中に電源を安全に取外せます。

- サービス・アクション必須LEDが黄色: 電源に障害があります。システムが電源の障害を検出した場合、前面および背面パネルのサービス・アクション必須LEDも点灯します。

- AC存在LEDが緑色: ホット・スワップ中に電源を取外せます。

Oracle Server X6-2 Oracle Database Serverのサーバー

- 取外しOK LEDが青色: ホット・スワップ中に記憶域ドライブを安全に取外せます。

- サービス・アクション必須LEDが黄色: システムが実行中ですが、記憶域ドライブに障害があります。システムが記憶域ドライブの障害を検出した場合、前面および背面パネルのサービス・アクション必須LEDも点灯します。

- OK/アクティビティLEDが緑色: 記憶域ドライブに対してデータの読取りまたは書込み中です。

表A-3に、LEDに基づいたディスク・ステータスを示します。

表A-3 LEDに基づいたOracle Server X6-2 Oracle Database Serverのディスク・ステータス

LED

予測障害

低いパフォーマンス

クリティカル

サービス・アクション必須(濃い黄色)

オン

オン

オン

取外しOK(青色)

オフ

オン

オン

A.5.2 Oracle Server X5-2 Oracle Database ServerのLED

表A-4に、Oracle Server X5-2 Oracle Database ServerのLEDの色コードを示します。

表A-4 Oracle Server X5-2 Oracle Database ServerのLEDステータスの説明

コンポーネント

LEDステータス

Oracle Server X5-2 Oracle Database Serverのファン・モジュール

- ファン・ステータスLEDが消灯: システムの電源が投入されていて、ファン・モジュールが適切に機能しています。

- ファン・ステータスLEDが黄色: ファン・モジュールに障害があります。システムがファン・モジュールの障害を検出した場合、前面および背面パネルのサービス・アクション必須LEDも点灯します。

Oracle Server X5-2 Oracle Database Serverの電源

- 取外しOK LEDが緑色: ホット・スワップ中に電源を安全に取外せます。

- サービス・アクション必須LEDが黄色: 電源に障害があります。システムが電源の障害を検出した場合、前面および背面パネルのサービス・アクション必須LEDも点灯します。

- AC存在LEDが緑色: ホット・スワップ中に電源を取外せます。

Oracle Server X5-2 Oracle Database Serverのサーバー

- 取外しOK LEDが青色: ホット・スワップ中に記憶域ドライブを安全に取外せます。

- サービス・アクション必須LEDが黄色: システムが実行中ですが、記憶域ドライブに障害があります。システムが記憶域ドライブの障害を検出した場合、前面および背面パネルのサービス・アクション必須LEDも点灯します。

- OK/アクティビティLEDが緑色: 記憶域ドライブに対してデータの読取りまたは書込み中です。

表A-5に、LEDに基づいたディスク・ステータスを示します。

表A-5 LEDに基づいたOracle Server X5-2 Oracle Database Serverのディスク・ステータス

LED

予測障害

低いパフォーマンス

クリティカル

サービス・アクション必須(濃い黄色)

オン

オン

オン

取外しOK(青色)

オフ

オン

オン

A.5.3 Sun Server X4-2 Oracle Database ServerのLED

表A-6に、Sun Server X4-2 Oracle Database ServerのLEDの色コードを示します。

表A-6 Sun Fire X4170 M2 Oracle Database ServerのLEDステータスの説明

コンポーネント

LEDステータス

Sun Server X4-2 Oracle Database Serverのファン・モジュール

- ファン・ステータスLEDが緑色: システムの電源が投入されていて、ファン・モジュールが適切に機能しています。

- ファン・ステータスLEDが黄色: ファン・モジュールに障害があります。システムがファン・モジュールの障害を検出した場合、前面および背面パネルのサービス・アクション必須LEDも点灯します。

Sun Server X4-2 Oracle Database Serverの電源

- 取外しOK LEDが緑色: ホット・スワップ中に電源を安全に取外せます。

- サービス・アクション必須LEDが黄色: 電源に障害があります。システムが電源の障害を検出した場合、前面および背面パネルのサービス・アクション必須LEDも点灯します。

- AC存在LEDが緑色: ホット・スワップ中に電源を取外せます。

Sun Server X4-2 Oracle Database Serverのサーバー

- 取外しOK LEDが青色: ホット・スワップ中に記憶域ドライブを安全に取外せます。

- サービス・アクション必須LEDが黄色: システムが実行中ですが、記憶域ドライブに障害があります。システムが記憶域ドライブの障害を検出した場合、前面および背面パネルのサービス・アクション必須LEDも点灯します。

- OK/アクティビティLEDが緑色: 記憶域ドライブに対してデータの読取りまたは書込み中です。

表A-7に、LEDに基づいたディスク・ステータスを示します。

表A-7 LEDに基づいたSun Server X4-2 Oracle Database Serverのディスク・ステータス

LED

予測障害

低いパフォーマンス

クリティカル

サービス・アクション必須(濃い黄色)

オン

オン

オン

取外しOK(青色)

オフ

オン

オン

A.5.4 Sun Server X3-2 Oracle Database ServerのLED

表A-8に、Sun Server X3-2 Oracle Database ServerのLEDの色コードを示します。

表A-8 Sun Server X3-2 Oracle Database ServerのLEDステータスの説明

コンポーネント

LEDステータス

Sun Server X3-2 Oracle Database Serverのファン・モジュール

- ファン・ステータスLEDが緑色: システムの電源が投入されていて、ファン・モジュールが適切に機能しています。

- ファン・ステータスLEDが黄色: ファン・モジュールに障害があります。システムがファン・モジュールの障害を検出した場合、前面および背面パネルのサービス・アクション必須LEDも点灯します。

Sun Server X3-2 Oracle Database Serverの電源

- 取外しOK LEDが緑色: ホット・スワップ中に電源を安全に取外せます。

- サービス・アクション必須LEDが黄色: 電源に障害があります。システムが電源の障害を検出した場合、前面および背面パネルのサービス・アクション必須LEDも点灯します。

- AC存在LEDが緑色: ホット・スワップ中に電源を取外せます。

Sun Server X3-2 Oracle Database Serverのサーバー

- 取外しOK LEDが青色: ホット・スワップ中に記憶域ドライブを安全に取外せます。

- サービス・アクション必須LEDが黄色: システムが実行中ですが、記憶域ドライブに障害があります。システムが記憶域ドライブの障害を検出した場合、前面および背面パネルのサービス・アクション必須LEDも点灯します。

- OK/アクティビティLEDが緑色: 記憶域ドライブに対してデータの読取りまたは書込み中です。

表A-9に、LEDに基づいたディスク・ステータスを示します。

表A-9 LEDに基づいたSun Server X3-2 Oracle Database Serverのディスク・ステータス

LED

予測障害

低いパフォーマンス

クリティカル

サービス・アクション必須(濃い黄色)

オン

オン

オン

取外しOK(青色)

オフ

オン

オン

A.5.5 Sun Fire X4170 M2 Oracle Database ServerのLED

表A-10に、Sun Fire X4170 M2 Oracle Database ServerのLEDの色コードを示します。

表A-10 Sun Fire X4170 M2 Oracle Database ServerのLEDステータスの説明

コンポーネント

LEDステータス

Sun Fire X4170 M2 Oracle Database Serverのファン・モジュール

- ファン・ステータスLEDが緑色: システムの電源が投入されていて、ファン・モジュールが適切に機能しています。

- ファン・ステータスLEDが黄色: ファン・モジュールに障害があります。システムがファン・モジュールの障害を検出した場合、前面および背面パネルのサービス・アクション必須LEDも点灯します。

Sun Fire X4170 M2 Oracle Database Serverの電源

- 取外しOK LEDが緑色: ホット・スワップ中に電源を安全に取外せます。

- サービス・アクション必須LEDが黄色: 電源に障害があります。システムが電源の障害を検出した場合、前面および背面パネルのサービス・アクション必須LEDも点灯します。

- AC存在LEDが緑色: ホット・スワップ中に電源を取外せます。

Sun Fire X4170 M2 Oracle Database Serverのサーバー

- 取外しOK LEDが青色: ホット・スワップ中に記憶域ドライブを安全に取外せます。

- サービス・アクション必須LEDが黄色: システムが実行中ですが、記憶域ドライブに障害があります。システムが記憶域ドライブの障害を検出した場合、前面および背面パネルのサービス・アクション必須LEDも点灯します。

- OK/アクティビティLEDが緑色: 記憶域ドライブに対してデータの読取りまたは書込み中です。

表A-11に、LEDに基づいたディスク・ステータスを示します。

表A-11 LEDに基づいたSun Fire X4170 M2 Oracle Database Serverのディスク・ステータス

LED

予測障害

低いパフォーマンス

クリティカル

サービス・アクション必須(濃い黄色)

オン

オン

オン

取外しOK(青色)

オフ

オン

オン

A.5.6 Sun Fire X4170 Oracle Database ServerのLED

表A-12に、Sun Fire X4170 Oracle Database ServerのLEDの色コードを示します。

表A-12 Sun Fire X4170 Oracle Database ServerのLEDステータスの説明

コンポーネント

LEDステータス

Sun Fire X4170 Oracle Database Serverのファン・モジュール

- 電源/OK LEDが緑色: システムの電源が投入されていて、ファン・モジュールが適切に機能しています。

- サービス・アクション必須LEDが黄色: ファン・モジュールに障害があります。システムがファン・モジュールの障害を検出した場合、前面および背面パネルのサービス・アクション必須LEDも点灯します。

Sun Fire X4170 Oracle Database Serverの電源

- 取外しOK LEDが緑色: ホット・スワップ中に電源を安全に取外せます。

- サービス・アクション必須LEDが黄色: 電源に障害があります。システムが電源の障害を検出した場合、前面および背面パネルのサービス・アクション必須LEDも点灯します。

- AC存在LEDが緑色: ホット・スワップ中に電源を取外せます。

Sun Fire X4170 Oracle Database Serverのサーバー

- 取外しOK LEDが青色: ホット・スワップ中に記憶域ドライブを安全に取外せます。

- サービス・アクション必須LEDが黄色: システムが実行中で、記憶域ドライブに障害があります。システムが記憶域ドライブの障害を検出した場合、前面および背面パネルのサービス・アクション必須LEDも点灯します。

- OK/アクティビティLEDが緑色: 記憶域ドライブに対してデータの読取りまたは書込み中です。

表A-13に、LEDに基づいたディスク・ステータスを示します。

表A-13 LEDに基づいたSun Fire X4170 Oracle Database Serverのディスク・ステータス

LED

予測障害

低いパフォーマンス

クリティカル

サービス・アクション必須(濃い黄色)

点滅

点滅

オン

取外しOK(青色)

オフ

点滅

点滅

A.5.7 Oracle Server X5-8およびX6-8 Oracle Database ServerのLED

表A-14に、Oracle Server X5-8およびX6-8 Oracle Database ServerのLEDの色コードを示します。

表A-14 Oracle Server X5-8およびX6-8 Oracle Database ServerのLEDステータスの説明

コンポーネント

LEDステータス

Oracle Server X5-8またはX6-8 Oracle Database Serverのバック・パネルのPCIeカード・キャリア(DPCC)

- 注意ボタンLED: PCIeをオペレーティング・システムから取り外す場合、または追加する場合に押します。

- サービス・アクション必須(障害)LEDが黄色: 障害のある状態です。

- OK LEDが緑色: PCIeの準備が完了し、オペレーティング・システムによって使用中です。

Oracle Server X5-8またはX6-8 Oracle Database Serverのハード・ドライブ

- ホット・スワップLEDが青色: ハード・ドライブを安全に取外せます。

- 障害が黄色:ハード・ドライブに障害があります。

- アクティビティが緑色:点滅は、ドライブのアクティビティ、およびスタンバイを示します。

Oracle Server X5-8またはX6-8 Oracle Database Serverの電源

- PSU障害LEDが黄色: 電源に障害がある状態です。

- PSU OK LEDが緑色: 電源が投入されています。

- AC LEDが緑色: ACが電源に接続されています。

Oracle Server X5-8またはX6-8 Oracle Database Serverのサービス・プロセッサ(SP)モジュール

- 10/1000/1000Base-TイーサネットLED(左): 緑色は、リンクが1ギガビットで確立されたことを示します。黄色(オン)は、リンクが100メガビットで確立されたことを示します。黄色(オフ)は、リンクが10メガビットで確立されたことを示します。

- 10/1000/1000Base-TイーサネットLED(下)が緑色: リンク上にアクティビティが存在します。

- シャーシのサービス・アクション必須(障害)LEDが黄色: 障害のある状態です。

- シャーシの電源OK LED: 緑色は、フル・パワー・モードを示します。AC電源コードがサーバーに接続されていると、SPブート時にすばやく点滅します。スタンバイ・パワー・モードではゆっくり点滅します。

- シャーシ上限温度超過LEDが黄色: 内部サーバー温度がしきい値の上限を超えています。

- SPモジュールOK LED: SPが機能しているときは緑色でオンになります。SPモジュールに最初に電源が投入されると3回緑色で点滅します。SPが機能していないときは黄色です。

- シャーシ検出LEDが白色: ILOMまたは検出ボタンによってアクティブ化されています。

表A-15に、LEDに基づいたディスク・ステータスを示します。

表A-15 LEDに基づいたOracle Server X5-8およびX6-8 Oracle Database Serverのディスク・ステータス

LED

予測障害

低いパフォーマンス

クリティカル

サービス・アクション必須(濃い黄色)

点滅

点滅

点滅

取外しOK(青色)

オフ

オフ

オフ

A.5.8 Sun Server X4-8 Oracle Database ServerのLED

表A-16に、Sun Server X4-8 Oracle Database ServerのLEDの色コードを示します。

表A-16 Sun Server X4-8 Oracle Database ServerのLEDステータスの説明

コンポーネント

LEDステータス

Sun Server X4-8 Oracle Database Serverのバック・パネルのPCIeカード・キャリア(DPCC)

- 注意ボタンLED: PCIeをオペレーティング・システムから取り外す場合、または追加する場合に押します。

- サービス・アクション必須(障害)LEDが黄色: 障害のある状態です。

- OK LEDが緑色: PCIeの準備が完了し、オペレーティング・システムによって使用中です。

Sun Server X4-8 Oracle Database Serverのハード・ドライブ

- ホット・スワップLEDが青色: ハード・ドライブを安全に取外せます。

- 障害が黄色:ハード・ドライブに障害があります。

- アクティビティが緑色:点滅は、ドライブのアクティビティ、およびスタンバイを示します。

Sun Server X4-8 Oracle Database Serverの電源

- PSU障害LEDが黄色: 電源に障害がある状態です。

- PSU OK LEDが緑色: 電源が投入されています。

- AC LEDが緑色: ACが電源に接続されています。

Sun Server X4-8 Oracle Database Serverのサービス・プロセッサ(SP)モジュール

- 10/1000/1000Base-TイーサネットLED(左): 緑色は、リンクが1ギガビットで確立されたことを示します。黄色(オン)は、リンクが100メガビットで確立されたことを示します。黄色(オフ)は、リンクが10メガビットで確立されたことを示します。

- 10/1000/1000Base-TイーサネットLED(下)が緑色: リンク上にアクティビティが存在します。

- シャーシのサービス・アクション必須(障害)LEDが黄色: 障害のある状態です。

- シャーシの電源OK LED: 緑色は、フル・パワー・モードを示します。AC電源コードがサーバーに接続されていると、SPブート時にすばやく点滅します。スタンバイ・パワー・モードではゆっくり点滅します。

- シャーシ上限温度超過LEDが黄色: 内部サーバー温度がしきい値の上限を超えています。

- SPモジュールOK LED: SPが機能しているときは緑色でオンになります。SPモジュールに最初に電源が投入されると3回緑色で点滅します。SPが機能していないときは黄色です。

- シャーシ検出LEDが白色: ILOMまたは検出ボタンによってアクティブ化されています。

表A-17に、LEDに基づいたディスク・ステータスを示します。

表A-17 LEDに基づいたSun Server X4-8 Oracle Database Serverのディスク・ステータス

LED

予測障害

低いパフォーマンス

クリティカル

サービス・アクション必須(濃い黄色)

点滅

点滅

点滅

取外しOK(青色)

オフ

オフ

オフ

A.5.9 Sun Server X2-8 Oracle Database ServerのLED

表A-18に、Sun Server X2-8 Oracle Database ServerのLEDの色コードを示します。

表A-18 Sun Server X2-8 Oracle Database ServerのLEDステータスの説明

コンポーネント

LEDステータス

Sun Server X2-8 Oracle Database Serverの背面パネルのPCIe Express Module(EM)

- 注意ボタンLED: EMをオペレーティング・システムから取り外す場合、または追加する場合に押します。

- サービス・アクション必須(障害)LEDが黄色: 障害のある状態です。

- OK LEDが緑色: EMの準備が完了し、オペレーティング・システムによって使用中です。

Sun Server X2-8 Oracle Database Serverのハード・ドライブ

- ホット・スワップLEDが青色: ハード・ドライブを安全に取外せます。

- 障害が黄色:ハード・ドライブに障害があります。

- アクティビティが緑色:点滅は、ドライブのアクティビティ、およびスタンバイを示します。

Sun Server X2-8 Oracle Database ServerのNetwork Express Module(NEM)

- 10Gbイーサネット・ポート・アクティビティLED: 緑色は、リンクが100メガビットで確立されたことを示します。黄色は、リンクが10メガビットで確立され、最大の容量が使用されていないことを示します。

- 10Gbイーサネット・ポート・リンクLEDが緑色: リンク上にアクティビティが存在します。

- 10/1000/1000Base-TイーサネットLED(上): 緑色は、リンクが1ギガビットで確立されたことを示します。黄色(オン)は、リンクが100メガビットで確立されたことを示します。黄色(オフ)は、リンクが10メガビットで確立されたことを示します。

- 10/1000/1000Base-TイーサネットLED(下)が緑色: リンク上にアクティビティが存在します。

- NEM検出LEDが白色: ILOMまたは検出ボタンによってアクティブ化されています。

- 取外しOK LEDが青色: 使用されていません。

- サービス・アクション必須(障害)LEDが黄色: 障害のある状態です。

- 電源OK LEDが緑色: システムの電源が投入されています。

Sun Server X2-8 Oracle Database Serverの電源

- PSU障害LEDが黄色: 電源に障害がある状態です。

- PSU OK LEDが緑色: 電源が投入されています。

- AC LEDが緑色: ACが電源に接続されています。

Sun Server X2-8 Oracle Database Serverのサービス・プロセッサ(SP)モジュール

- 10/1000/1000Base-TイーサネットLED(左): 緑色は、リンクが1ギガビットで確立されたことを示します。黄色(オン)は、リンクが100メガビットで確立されたことを示します。黄色(オフ)は、リンクが10メガビットで確立されたことを示します。

- 10/1000/1000Base-TイーサネットLED(下)が緑色: リンク上にアクティビティが存在します。

- シャーシのサービス・アクション必須(障害)LEDが黄色: 障害のある状態です。

- シャーシの電源OK LED: 緑色は、フル・パワー・モードを示します。AC電源コードがサーバーに接続されていると、SPブート時にすばやく点滅します。スタンバイ・パワー・モードではゆっくり点滅します。

- シャーシ上限温度超過LEDが黄色: 内部サーバー温度がしきい値の上限を超えています。

- SPモジュールOK LED: SPが機能しているときは緑色でオンになります。SPモジュールに最初に電源が投入されると3回緑色で点滅します。SPが機能していないときは黄色です。

- シャーシ検出LEDが白色: ILOMまたは検出ボタンによってアクティブ化されています。

表A-19に、LEDに基づいたディスク・ステータスを示します。

表A-19 LEDに基づいたSun Server X2-8 Oracle Database Serverのディスク・ステータス

LED

予測障害

低いパフォーマンス

クリティカル

サービス・アクション必須(濃い黄色)

点滅

点滅

点滅

取外しOK(青色)

オフ

オフ

オフ

A.5.10 Sun Fire X4800 Oracle Database ServerのLED

表A-20に、Sun Fire X4800 Oracle Database ServerのLEDの色コードを示します。

表A-20 Sun Fire X4800 Oracle Database ServerのLEDステータスの説明

コンポーネント

LEDステータス

Sun Fire X4800 Oracle Database Serverの背面パネルのPCIe Express Module(EM)

- 注意ボタンLED: EMをオペレーティング・システムから取り外す場合、または追加する場合に押します。

- サービス・アクション必須(障害)LEDが黄色: 障害のある状態です。

- OK LEDが緑色: EMの準備が完了し、オペレーティング・システムによって使用中です。

Sun Fire X4800 Oracle Database Serverのハード・ドライブ

- ホット・スワップLEDが青色: ハード・ドライブを安全に取外せます。

- 障害が黄色:ハード・ドライブに障害があります。

- アクティビティが緑色:点滅は、ドライブのアクティビティ、およびスタンバイを示します。

Sun Fire X4800 Oracle Database ServerのNetwork Express Module(NEM)

- 10Gbイーサネット・ポート・アクティビティLED: 緑色は、リンクが100メガビットで確立されたことを示します。黄色は、リンクが10メガビットで確立され、最大の容量が使用されていないことを示します。

- 10Gbイーサネット・ポート・リンクLEDが緑色: リンク上にアクティビティが存在します。

- 10/1000/1000Base-TイーサネットLED(上): 緑色は、リンクが1ギガビットで確立されたことを示します。黄色(オン)は、リンクが100メガビットで確立されたことを示します。黄色(オフ)は、リンクが10メガビットで確立されたことを示します。

- 10/1000/1000Base-TイーサネットLED(下)が緑色: リンク上にアクティビティが存在します。

- NEM検出LEDが白色: ILOMまたは検出ボタンによってアクティブ化されています。

- 取外しOK LEDが青色: 使用されていません。

- サービス・アクション必須(障害)LEDが黄色: 障害のある状態です。

- 電源OK LEDが緑色: システムの電源が投入されています。

Sun Fire X4800 Oracle Database Serverの電源

- PSU障害LEDが黄色: 電源に障害がある状態です。

- PSU OK LEDが緑色: 電源が投入されています。

- AC LEDが緑色: ACが電源に接続されています。

Sun Fire X4800 Oracle Database Serverのサービス・プロセッサ(SP)モジュール

- 10/1000/1000Base-TイーサネットLED(左): 緑色は、リンクが1ギガビットで確立されたことを示します。黄色(オン)は、リンクが100メガビットで確立されたことを示します。黄色(オフ)は、リンクが10メガビットで確立されたことを示します。

- 10/1000/1000Base-TイーサネットLED(下)が緑色: リンク上にアクティビティが存在します。

- シャーシのサービス・アクション必須(障害)LEDが黄色: 障害のある状態です。

- シャーシの電源OK LED: 緑色は、フル・パワー・モードを示します。AC電源コードがサーバーに接続されていると、SPブート時にすばやく点滅します。スタンバイ・パワー・モードではゆっくり点滅します。

- シャーシ上限温度超過LEDが黄色: 内部サーバー温度がしきい値の上限を超えています。

- SPモジュールOK LED: SPが機能しているときは緑色でオンになります。SPモジュールに最初に電源が投入されると3回緑色で点滅します。SPが機能していないときは黄色です。

- シャーシ検出LEDが白色: ILOMまたは検出ボタンによってアクティブ化されています。

表A-21に、LEDに基づいたディスク・ステータスを示します。

表A-21 LEDに基づいたSun Fire X4800 Oracle Database Serverのディスク・ステータス

LED

予測障害

低いパフォーマンス

クリティカル

サービス・アクション必須(濃い黄色)

点滅

点滅

点滅

取外しOK(青色)

オフ

オフ

オフ

A.5.11 Exadata Storage Server X5-2 Server

表A-22に、Exadata Storage Server X5-2 ServerのLEDの色コードを示します。

表A-22 LEDステータスの説明

コンポーネント

LEDステータス

Exadata Storage Server X5-2 Serverのファン・モジュール

- ファン・ステータスLEDが消灯: システムの電源が投入されていて、ファン・モジュールが適切に機能しています。

- ファン・ステータスLEDが黄色: ファン・モジュールに障害があります。システムがファン・モジュールの障害を検出した場合、前面および背面パネルのサービス・アクション必須LEDも点灯します。

Exadata Storage Server X5-2 Serverの電源

- 取外しOK LEDが緑色: ホット・スワップ中に電源を安全に取外せます。

- サービス・アクション必須LEDが黄色: 電源に障害があります。システムが電源の障害を検出した場合、前面および背面パネルのサービス・アクション必須LEDも点灯します。

- AC存在LEDが緑色: ホット・スワップ中に電源を取外せます。

Exadata Storage Server X5-2 Serverのサーバー

- 取外しOK LEDが青色: ホット・スワップ中に記憶域ドライブを安全に取外せます。

- サービス・アクション必須LEDが黄色: 記憶域ドライブに障害があります。システムが記憶域ドライブの障害を検出した場合、前面および背面パネルのサービス・アクション必須LEDも点灯します。

- OK/アクティビティLEDが緑色: 記憶域ドライブに対してデータの読取りまたは書込み中です。

表A-23に、LEDに基づいたディスク・ステータスを示します。

表A-23 LEDに基づいたExadata Storage Server X5-2 Serverのディスク・ステータス

LED

予測障害

低いパフォーマンス

クリティカル

サービス・アクション必須(濃い黄色)

オン

オン

オン

取外しOK(青色)

オフ

オン

オン

A.5.12 Exadata Storage Server X4-2L Server

表A-24に、Exadata Storage Server X3-2 ServerのLEDの色コードを示します。

表A-24 LEDステータスの説明

コンポーネント

LEDステータス

Exadata Storage Server X4-2L Serverのファン・モジュール

- ファン・ステータスLEDが緑色: システムの電源が投入されていて、ファン・モジュールが適切に機能しています。

- ファン・ステータスLEDが黄色: ファン・モジュールに障害があります。システムがファン・モジュールの障害を検出した場合、前面および背面パネルのサービス・アクション必須LEDも点灯します。

Exadata Storage Server X4-2L Serverの電源

- 取外しOK LEDが緑色: ホット・スワップ中に電源を安全に取外せます。

- サービス・アクション必須LEDが黄色: 電源に障害があります。システムが電源の障害を検出した場合、前面および背面パネルのサービス・アクション必須LEDも点灯します。

- AC存在LEDが緑色: ホット・スワップ中に電源を取外せます。

Exadata Storage Server X4-2L Serverのサーバー

- 取外しOK LEDが青色: ホット・スワップ中に記憶域ドライブを安全に取外せます。

- サービス・アクション必須LEDが黄色: 記憶域ドライブに障害があります。システムが記憶域ドライブの障害を検出した場合、前面および背面パネルのサービス・アクション必須LEDも点灯します。

- OK/アクティビティLEDが緑色: 記憶域ドライブに対してデータの読取りまたは書込み中です。

表A-27に、LEDに基づいたディスク・ステータスを示します。

表A-25 LEDに基づいたExadata Storage Server X4-2L Serverのディスク・ステータス

LED

予測障害

低いパフォーマンス

クリティカル

サービス・アクション必須(濃い黄色)

オン

オン

オン

取外しOK(青色)

オフ

オン

オン

A.5.13 Exadata Storage Server X3-2 Server

表A-26に、Exadata Storage Server X3-2 ServerのLEDの色コードを示します。

表A-26 LEDステータスの説明

コンポーネント

LEDステータス

Exadata Storage Server X3-2 Serverのファン・モジュール

- ファン・ステータスLEDが緑色: システムの電源が投入されていて、ファン・モジュールが適切に機能しています。

- ファン・ステータスLEDが黄色: ファン・モジュールに障害があります。システムがファン・モジュールの障害を検出した場合、前面および背面パネルのサービス・アクション必須LEDも点灯します。

Exadata Storage Server X3-2 Serverの電源

- 取外しOK LEDが緑色: ホット・スワップ中に電源を安全に取外せます。

- サービス・アクション必須LEDが黄色: 電源に障害があります。システムが電源の障害を検出した場合、前面および背面パネルのサービス・アクション必須LEDも点灯します。

- AC存在LEDが緑色: ホット・スワップ中に電源を取外せます。

Exadata Storage Server X3-2 Serverサーバー

- 取外しOK LEDが青色: ホット・スワップ中に記憶域ドライブを安全に取外せます。

- サービス・アクション必須LEDが黄色: 記憶域ドライブに障害があります。システムが記憶域ドライブの障害を検出した場合、前面および背面パネルのサービス・アクション必須LEDも点灯します。

- OK/アクティビティLEDが緑色: 記憶域ドライブに対してデータの読取りまたは書込み中です。

表A-27に、LEDに基づいたディスク・ステータスを示します。

表A-27 LEDに基づいたExadata Storage Server X3-2 Serverのディスク・ステータス

LED

予測障害

低いパフォーマンス

クリティカル

サービス・アクション必須(濃い黄色)

オン

オン

オン

取外しOK(青色)

オフ

オン

オン

A.5.14 Sun Fire X4270 M2 Serverを使用したExadata Storage Server

表A-28に、Sun Fire X4270 M2 Serverを使用したExadata Storage ServerのLEDの色コードを示します。

表A-28 LEDステータスの説明

コンポーネント

LEDステータス

Sun Fire X4270 M2 Serverを使用したExadata Storage Serverのファン・モジュール

- ファン・ステータスLEDが緑色: システムの電源が投入されていて、ファン・モジュールが適切に機能しています。

- ファン・ステータスLEDが黄色: ファン・モジュールに障害があります。システムがファン・モジュールの障害を検出した場合、前面および背面パネルのサービス・アクション必須LEDも点灯します。

Sun Fire X4270 M2 Serverを使用したExadata Storage Serverの電源

- 取外しOK LEDが緑色: ホット・スワップ中に電源を安全に取外せます。

- サービス・アクション必須LEDが黄色: 電源に障害があります。システムが電源の障害を検出した場合、前面および背面パネルのサービス・アクション必須LEDも点灯します。

- AC存在LEDが緑色: ホット・スワップ中に電源を取外せます。

Sun Fire X4270 M2 Serverを使用したExadata Storage Serverのサーバー

- 取外しOK LEDが青色: ホット・スワップ中に記憶域ドライブを安全に取外せます。

- サービス・アクション必須LEDが黄色: 記憶域ドライブに障害があります。システムが記憶域ドライブの障害を検出した場合、前面および背面パネルのサービス・アクション必須LEDも点灯します。

- OK/アクティビティLEDが緑色: 記憶域ドライブに対してデータの読取りまたは書込み中です。

表A-29に、LEDに基づいたディスク・ステータスを示します。

表A-29 Sun Fire X4270 M2 Serverを使用したExadata Storage ServerのLEDに基づいたディスク・ステータス

LED

予測障害

低いパフォーマンス

クリティカル

サービス・アクション必須(濃い黄色)

オン

オン

オン

取外しOK(青色)

オフ

オン

オン

A.5.15 Sun Fire X4275 Serverを使用したExadata Storage ServerのLED

表A-30に、Sun Fire X4275 Serverを使用したExadata Storage ServerのLEDの色コードを示します。

表A-30 Sun Fire X4275 Serverを使用したExadata Storage ServerのLEDステータスの説明

コンポーネント

LEDステータス

Sun Fire X4275 Serverを使用したExadata Storage Server

- 取外しOK LEDが青色: ホット・スワップ中に記憶域ドライブを安全に取外せます。

- サービス・アクション必須LEDが黄色: 記憶域ドライブに障害があります。システムが記憶域ドライブの障害を検出した場合、前面および背面パネルのサービス・アクション必須LEDも点灯します。

- OK/アクティビティLEDが緑色: 記憶域ドライブに対してデータの読取りまたは書込み中です。

Sun Fire X4275 Serverを使用したExadata Storage Serverのファン・モジュール

- 電源/OK LEDが緑色: システムの電源が投入されていて、ファン・モジュールが適切に機能しています。

- サービス・アクション必須LEDが黄色: ファン・モジュールに障害があります。システムがファン・モジュールの障害を検出した場合、前面および背面パネルのサービス・アクション必須LEDも点灯します。

Sun Fire X4275 Serverを使用したExadata Storage Serverの電源

- AC存在LEDが緑色: ホット・スワップ中に電源を取外せます。

- サービス・アクション必須LEDが黄色: 電源に障害があります。システムが電源の障害を検出した場合、前面および背面パネルのサービス・アクション必須LEDも点灯します。

- 取外しOK LEDが青色: ホット・スワップ中に電源を安全に取外せます。

表A-31に、LEDに基づいたディスク・ステータスを示します。

表A-31 Sun Fire X4275 Serverを使用したExadata Storage ServerのLEDに基づいたディスク・ステータス

LED

予測障害

低いパフォーマンス

クリティカル

サービス・アクション必須(濃い黄色)

点滅

点滅

オン

取外しOK(青色)

オフ

点滅

点滅

A.5.16 Sun Flash Accelerator F20 PCIeカードのLED

表A-32に、Sun Flash Accelerator F20 PCIeカードのLEDの色コードを示します。

表A-32 Sun Flash Accelerator F20 PCIeカードのLEDステータスの説明

コンポーネント

LEDステータス

FMod 3、2、1、0

LEDが緑色:対応するFModに読取り/書込みアクティビティがあると点滅します。対応するFModが存在すると点滅します。

ESM OK LED

LEDが緑色:ESMが充電されていて、停電時にデータの整合性を保持する十分な緊急時電力を提供できる場合にオンになります。システムがダウンしていているとオフになり、ESMが充電中である場合は点滅します。

ESMサービス必須LED

LEDが黄色のとき、ESMがライトバック・モードのための十分な予備電力を保持していないことを示します。カードはライトスルー(キャッシュ)モードで機能しています。サービスが必要です。

電源LED

LEDがオン:カードの電源が投入されていることを示します。

A.5.17 Sun Datacenter InfiniBand Switch 36スイッチのLED

表A-33に、Sun Datacenter InfiniBand Switch 36スイッチのLEDの色コードを示します。

表A-33 Sun Datacenter InfiniBand Switch 36スイッチのLEDステータスの説明

コンポーネント

LEDステータス

Sun Datacenter InfiniBand Switch 36のシャーシ

- ロケータLEDが白色: ロケータ自体の識別時に点滅します。機能していないときオンになり、無効になっているときはオフになります。

- 注意LEDが黄色: 障害のある状態です。機能していないとき点滅します。

- OK LEDが緑色: スイッチが正常に機能しています。機能していないとき点滅します。

Sun Datacenter InfiniBand Switch 36のリンク・ステータス

リンクLEDが緑色: リンクが確立されるとオンになります。リンクがダウンするとオフになり、シンボル・エラーがあると点滅します。

Sun Datacenter InfiniBand Switch 36のネットワーク管理ポート

- リンク速度LED: 緑色は、1000BASE-Tを示します。黄色は、100BASE-Tを示します。オフはリンクがないことを示します。点滅は機能していないことを示します。

- アクティビティLED: 点滅は、パケット・アクティビティを示します。オンは機能していないことを示します。オフはアクティビティがないことを示します。

Sun Datacenter InfiniBand Switch 36の電源

- OK LEDが緑色: 12VDCが供給されていることを示します。点滅は機能していないことを示します。

- 注意LEDが黄色: 障害があり、12VDCが停止しています。点滅は機能していないことを示します。

- AC LEDが緑色: AC電源が供給されていて正常です。点滅は機能していないことを示します。

A.6 Oracle Database Serverの部品

次の項では、Oracle Database Serverのデータベース・サーバーおよび部品を示します。

- Oracle Server X6-2 Oracle Database Serverの部品

- Oracle Server X5-2 Oracle Database Serverの部品

- Sun Server X4-2 Oracle Database Serverの部品

- Sun Server X3-2 Oracle Database Serverの部品

- Sun Fire X4170 M2 Oracle Database Serverの部品

- Sun Fire X4170 Oracle Database Serverの部品

- Oracle Server X5-8およびX6-8 Oracle Database Serverの部品

- Sun Server X4-8 Oracle Database Serverの部品

- Sun Server X2-8 Oracle Database Serverの部品

- Sun Fire X4800 Oracle Database Serverの部品

A.6.1 Oracle Server X6-2 Oracle Database Serverの部品

図A-1に、Oracle Server X6-2 Oracle Database Serverの前面図を示します。

図A-1 Oracle Server X6-2 Oracle Database Serverの前面図

図A-2に、Oracle Server X6-2 Oracle Database Serverの背面図を示します。

上位ハード・ディスク・ドライブは、左から右にHDD1、およびHDD3です。下位ドライブは、左から右にHDD0、およびHDD2です。

図A-2 Oracle Server X6-2 Oracle Database Serverの背面図

表A-34に、Oracle Server X6-2 Oracle Database Serverの交換部品を示します。

注意:

Premier Support of Systemsで保証されている場合、次の表のすべての交換部品はFRUとみなされます。

表A-34 Oracle Server X6-2 Oracle Database Serverの交換部品

部品番号

説明

修理カテゴリ

基本保証の範囲

修理手順

350-1719

構成部品、スリム・レール、1U-2Uスナップイン

DBO

CRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。詳細は、「データベース・サーバーの電源切断」を参照してください。

2. Oracle Server X6-2サービス・マニュアルのサーバーのラックへの再取付けに関する項(http://docs.oracle.com/cd/E62159_01/html/E62171/z40004191003899.html#scrolltoc)を参照

370-5621

3ボルト・リチウム・バッテリ

DBO

FRU

Oracle Server X6-2サービス・マニュアルのバッテリのサービス(CRU)に関する項(http://docs.oracle.com/cd/E62159_01/html/E62171/z40003f01423753.html#scrolltoc)を参照

542-0287

ドライブ、600GB 10K、SAS2、SFF

DBO

FRU

Oracle Server X6-2サービス・マニュアルのストレージ・ドライブのサービス(CRU)に関する項(http://docs.oracle.com/cd/E62159_01/html/E62171/z40000091011460.html#scrolltoc)を参照

7014226

ケーブル、インターロック、125mm

DBO

FRU

Oracle Server X6-2サービス・マニュアルのケーブル(電源、FIM、ディスク・バックプレーン・データ、DVD)のサービスに関する項(http://docs.oracle.com/cd/E62159_01/html/E62171/gnyov.html#scrolltoc)を参照

7046442

構成部品、デュアル・ポート、QDR CX3、ホスト・チャネル・アダプタ

DBO

CRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。詳細は、「データベース・サーバーの電源切断」を参照してください。

2. Oracle Server X6-2サービス・マニュアルのPCIeカードのサービス(CRU)に関する項(http://docs.oracle.com/cd/E62159_01/html/E62171/z40000f91037409.html#scrolltoc)を参照

3. 「InfiniBandネットワーク構成の確認」を参照してください。

4. 次のコマンドを使用して、新しいハードウェアがハードウェアおよびファームウェアの仕様を満たしていることを確認します。

/opt/oracle.SupportTools/CheckHWnFWprofile

関連項目: 『Oracle Exadata Storage Server Softwareユーザーズ・ガイド』

7051223

構成部品、Dual 10GbE SFP+LP、X8 PCIe 2.0、RoHS:Y

DBO

CRU

Sun Dual 10GbE SFP+ PCIe 2.0 Low Profile Adapterユーザーズ・ガイド(http://docs.oracle.com/cd/E19407-01/820-7898-11/index.html)

Oracle Server X6-2サービス・マニュアルのPCIeカードのサービス(CRU)に関する項(http://docs.oracle.com/cd/E62159_01/html/E62171/z40000f91037409.html#scrolltoc)を参照

7067728

ヒート・シンク、CPU 1U

DBO

FRU

Oracle Server X6-2サービス・マニュアルのプロセッサのサービス(FRU)に関する項(http://docs.oracle.com/cd/E62159_01/html/E62171/z40001d31037480.html#scrolltoc)を参照

7077680

構成部品、ライザー、2S、1U

DBO

FRU

Oracle Server X6-2サービス・マニュアルのPCIeライザーのサービス(CRU)に関する項(http://docs.oracle.com/cd/E62159_01/html/E62171/z40000f91037394.html#scrolltoc)を参照

7078072

DIMM、32GB、RDIMM、DDR4、2400

DBO

CRU

Oracle Server X6-2サービス・マニュアルのDIMMのサービス(CRU)に関する項(http://docs.oracle.com/cd/E62159_01/html/E62171/z40003f01425075.html#scrolltoc)を参照

7079395

電源、AC、A256、F、12V、600W

HS

CRU

1. CMAの背面左側を取り外し、後方に動かして右方向に取り外します。
サーバーの真後ろにあるケーブルを支える伸縮式クロス・メンバーを格納すると、両方の電源にアクセスできます。

2. Oracle Server X6-2サービス・マニュアルの電源供給のサービス(CRU)に関する項(http://docs.oracle.com/cd/E62159_01/html/E62171/z40000091014153.html#scrolltoc)を参照

3. CMAを交換します。

7081071

構成部品、ライザー、単一スタック、1U

DBO

CRU

Oracle Server X6-2サービス・マニュアルのPCIeライザーのサービス(CRU)に関する項(http://docs.oracle.com/cd/E62159_01/html/E62171/z40000f91037394.html#scrolltoc)を参照

7085209

HBA、12GB SAS PCIe 8ポートRAID (フラッシュ・モジュールとともに内蔵)

DBO

FRU

Oracle Server X6-2サービス・マニュアルの内蔵HBAカードのサービス(FRU)に関する項(http://docs.oracle.com/cd/E62159_01/html/E62171/goeht.html#scrolltoc)を参照

7086345

構成部品、スーパー・キャップ、13.5ボルト、6.4F、SAS3 HBA

DBO

FRU

Oracle Server X6-2サービス・マニュアルの内蔵HBAカードのサービス(FRU)に関する項(http://docs.oracle.com/cd/E62159_01/html/E62171/goeht.html#scrolltoc)を参照

7086346

ケーブル、スーパー・キャップ、620M、6ピン、ストレート、SAS3 HBA

DBO

CRU

Oracle Server X6-2サービス・マニュアルの内蔵HBA SASケーブル・アセンブリのサービスに関する項(http://docs.oracle.com/cd/E62159_01/html/E62171/z40003eb1420346.html#scrolltoc)を参照

7089073

ファン・モジュール

HS

CRU

Oracle Server X6-2サービス・マニュアルのファン・モジュールのサービス(CRU)に関する項(http://docs.oracle.com/cd/E62159_01/html/E62171/z40000091014194.html#scrolltoc)を参照

7095106

CPU、E5-2699 v4、2.2GHz、145W、22コア、C-1 (SR1XD)

DBO

FRU

Oracle Server X6-2サービス・マニュアルのプロセッサのサービス(FRU)に関する項(http://docs.oracle.com/cd/E62159_01/html/E62171/z40001d31037480.html#scrolltoc)を参照

7097205

構成部品、8DBP、1U/2U

DBO

FRU

Oracle Server X6-2サービス・マニュアルのディスク・バックプレーンのサービス(FRU)に関する項(http://docs.oracle.com/cd/E62159_01/html/E62171/z40011771417642.html#scrolltoc)を参照

7098505

構成部品、マザーボード、1U

DBO

FRU

1. Oracle Server X6-2サービス・マニュアルのマザーボードのサービス(FRU)に関する項(http://docs.oracle.com/cd/E62159_01/html/E62171/z40011771418436.html#scrolltoc)を参照

2. サーバーの再起動後、[F2]を押します。

3. 起動順序を設定します。

A.6.2 Oracle Server X5-2 Oracle Database Serverの部品

図A-3に、Oracle Server X5-2 Oracle Database Serverの前面図を示します。

図A-3 Oracle Server X5-2 Oracle Database Serverの前面図

図A-4に、Oracle Server X5-2 Oracle Database Serverの背面図を示します。

上位ハード・ディスク・ドライブは、左から右にHDD1、およびHDD3です。下位ドライブは、左から右にHDD0、およびHDD2です。

図A-4 Oracle Server X5-2 Oracle Database Serverの背面図

表A-35に、Oracle Server X5-2 Oracle Database Serverの交換部品を示します。

注意:

Premier Support of Systemsで保証されている場合、次の表のすべての交換部品はFRUとみなされます。

表A-35 Oracle Server X5-2 Oracle Database Serverの交換部品

部品番号

説明

修理カテゴリ

基本保証の範囲

修理手順

350-1719

構成部品、スリム・レール、1U-2Uスナップイン

DBO

CRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。詳細は、「データベース・サーバーの電源切断」を参照してください。

2. Oracle Server X5-2サービス・マニュアルのサーバーのラックへの再取付けに関する項(http://docs.oracle.com/cd/E41059_01/html/E48320/z40004191003899.html)を参照

370-5621

3ボルト・リチウム・バッテリ

DBO

FRU

Oracle Server X5-2サービス・マニュアルのバッテリのサービス(CRU)に関する項(http://docs.oracle.com/cd/E41059_01/html/E48320/z40003f01423753.html)を参照

542-0287

ドライブ、600GB 10K、SAS2、SFF

DBO

FRU

Oracle Server X5-2サービス・マニュアルのストレージ・ドライブのサービス(CRU)に関する項(http://docs.oracle.com/cd/E41059_01/html/E48320/z40000091011460.html)を参照

7014226

ケーブル、インターロック、125mm

DBO

FRU

Oracle Server X5-2サービス・マニュアルのケーブル(電源、FIM、ディスク・バックプレーン・データ、DVD)のサービスに関する項(http://docs.oracle.com/cd/E41059_01/html/E48320/gnyov.html)を参照

7046442

構成部品、デュアル・ポート、QDR CX3、ホスト・チャネル・アダプタ

DBO

CRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。詳細は、「データベース・サーバーの電源切断」を参照してください。

2. Oracle Server X5-2サービス・マニュアルのPCIeカードのサービス(CRU)に関する項(http://docs.oracle.com/cd/E41059_01/html/E48320/z40000f91037409.html)を参照

3. 「InfiniBandネットワーク構成の確認」を参照してください。

4. 次のコマンドを使用して、新しいハードウェアがハードウェアおよびファームウェアの仕様を満たしていることを確認します。

/opt/oracle.SupportTools/CheckHWnFWprofile

関連項目: 『Oracle Exadata Storage Server Softwareユーザーズ・ガイド』

7051223

構成部品、Dual 10GbE SFP+LP、X8 PCIe 2.0、RoHS:Y

DBO

CRU

Sun Dual 10GbE SFP+ PCIe 2.0 Low Profile Adapterユーザーズ・ガイド(http://docs.oracle.com/cd/E19407-01/820-7898-11/index.html)

Oracle Server X5-2サービス・マニュアルのPCIeカードのサービス(CRU)に関する項(http://docs.oracle.com/cd/E41059_01/html/E48320/z40000f91037409.html)を参照

7067728

ヒート・シンク、CPU 1U

DBO

FRU

Oracle Server X5-2サービス・マニュアルのプロセッサのサービス(FRU)に関する項(http://docs.oracle.com/cd/E41059_01/html/E48320/z40001d31037480.html)を参照

7077680

構成部品、ライザー、2S、1U

DBO

FRU

Oracle Server X5-2サービス・マニュアルのPCIeライザーのサービス(CRU)に関する項(http://docs.oracle.com/cd/E41059_01/html/E48320/z40000f91037394.html)を参照

7078072

DIMM、32GB、LRDIMM、DDR4、2133

DBO

CRU

Oracle Server X5-2サービス・マニュアルのDIMMのサービス(CRU)に関する項(http://docs.oracle.com/cd/E41059_01/html/E48320/z40003f01425075.html)を参照

7079395

電源、AC、A256、F、12V、600W

HS

CRU

1. CMAの背面左側を取り外し、後方に動かして右方向に取り外します。
サーバーの真後ろにあるケーブルを支える伸縮式クロス・メンバーを格納すると、両方の電源にアクセスできます。

2. Oracle Server X5-2サービス・マニュアルの電源供給のサービス(CRU)に関する項(http://docs.oracle.com/cd/E41059_01/html/E48320/z40000091014153.html)を参照

3. CMAを交換します。

7081071

構成部品、ライザー、単一スタック、1U

DBO

CRU

Oracle Server X5-2サービス・マニュアルのPCIeライザーのサービス(CRU)に関する項(http://docs.oracle.com/cd/E41059_01/html/E48320/z40000f91037394.html)を参照

7085209

HBA、12GB SAS PCIe 8ポートRAID (フラッシュ・モジュールとともに内蔵)

DBO

FRU

Oracle Server X5-2サービス・マニュアルの内蔵HBAカードのサービス(FRU)に関する項(http://docs.oracle.com/cd/E41059_01/html/E48320/goeht.html)を参照

7086345

構成部品、スーパー・キャップ、13.5ボルト、6.4F、SAS3 HBA

DBO

FRU

Oracle Server X5-2サービス・マニュアルの内蔵HBAカードのサービス(FRU)に関する項(http://docs.oracle.com/cd/E41059_01/html/E48320/goeht.html)を参照

7086346

ケーブル、スーパー・キャップ、620M、6ピン、ストレート、SAS3 HBA

DBO

CRU

Oracle Server X5-2サービス・マニュアルの内蔵HBA SASケーブル・アセンブリのサービスに関する項(http://docs.oracle.com/cd/E41059_01/html/E48320/z40003eb1420346.html)を参照

7089073

ファン・モジュール

HS

CRU

Oracle Server X5-2サービス・マニュアルのファン・モジュールのサービス(CRU)に関する項(http://docs.oracle.com/cd/E41059_01/html/E48320/z40000091014194.html)を参照

7095106

CPU、E5-2699 v3、2.3GHz、145W、18コア、C-1 (SR1XD)

DBO

FRU

Oracle Server X5-2サービス・マニュアルのプロセッサのサービス(FRU)に関する項(http://docs.oracle.com/cd/E41059_01/html/E48320/z40001d31037480.html)を参照

7097205

構成部品、8DBP、1U/2U

DBO

FRU

Oracle Server X5-2サービス・マニュアルのディスク・バックプレーンのサービス(FRU)に関する項(http://docs.oracle.com/cd/E41059_01/html/E48320/z40011771417642.html)を参照

7098505

構成部品、マザーボード、1U

DBO

FRU

1. Oracle Server X5-2サービス・マニュアルのマザーボードのサービス(FRU)に関する項(http://docs.oracle.com/cd/E41059_01/html/E48320/z40011771418436.html)を参照

2. サーバーの再起動後、[F2]を押します。

3. 起動順序を設定します。

A.6.3 Sun Server X4-2 Oracle Database Serverの部品

Exadata X4-2 Database Machineには複数の交換部品があります。

次の図に、Sun Server X4-2 Oracle Database Serverの前面図を示します。

図A-5 Sun Server X4-2 Oracle Database Serverの前面図

次の図に、Sun Server X4-2 Oracle Database Serverの背面図を示します。

図A-6 Sun Server X4-2 Oracle Database Serverの背面図

次の表に、Sun Server X4-2 Oracle Database Serverの交換部品を示します。

注意:

Premier Support of Systemsで保証されている場合、次の表のすべての交換部品はFRUとみなされます。

関連項目:

Oracle Server X4-2ドキュメント・ライブラリ(http://docs.oracle.com/cd/E36975_01/html/E38045/toc.html)

表A-36 Sun Server X4-2 Oracle Database Serverの交換部品

部品番号

説明

修理カテゴリ

基本保証の範囲

修理手順

7013526

ファン・モジュール

HS

CRU

Sun Server X4-2サービス・マニュアルのファン・モジュールのサービス(CRU)に関する項(http://docs.oracle.com/cd/E36975_01/html/E38045/z40000091014194.html#scrolltoc)を参照してください

7018701

DIMM、16GB、DDR3、2RX4、1600、1.35V

DBO

CRU

Sun Server X4-2サービス・マニュアルのDIMMのサービス(CRU)に関する項(http://docs.oracle.com/cd/E36975_01/html/E38045/z40003f01425075.html#scrolltoc)を参照してください

7020774

ヒート・シンク、CPU 1U、60mm FIN

DBO

FRU

Sun Server X4-2サービス・マニュアルのストレージ・ドライブのサービス(CRU)に関する項(http://docs.oracle.com/cd/E36975_01/html/E38045/z40000091011460.html#scrolltoc)を参照してください

7027478

ディスク・バックプレーン、RoHS:Y

DBO

FRU

Sun Server X4-2サービス・マニュアルのディスク・バックプレーンのサービス(FRU)に関する項(http://docs.oracle.com/cd/E36975_01/html/E38045/z40011771417642.html#scrolltoc)を参照してください

7039841

前面のインジケータ・モジュール

DBO

FRU

Sun Server X4-2サービス・マニュアルのPCIeライザーのサービス(CRU)に関する項(http://docs.oracle.com/cd/E36975_01/html/E38045/z40000f91037394.html#scrolltoc)を参照してください

7046442

構成部品、デュアル・ポート、QDR CX3、ホスト・チャネル・アダプタ

DBO

CRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。詳細は、「データベース・サーバーの電源切断」を参照してください。

2. Sun Server X4-2サービス・マニュアルのPCIeカードのサービス(CRU)に関する項(http://docs.oracle.com/cd/E36975_01/html/E38045/z40000f91037409.html#scrolltoc)を参照してください

3. 「InfiniBandネットワーク構成の確認」を参照してください。

4. 次のコマンドを使用して、新しいハードウェアがハードウェアおよびファームウェアの仕様を満たしていることを確認します。

/opt/oracle.SupportTools/CheckHWnFWprofile

7047503

構成部品、6GB、SAS RAIDディスクPCIe HBA、RoHS:Y

DBO

CRU

Sun Server X4-2サービス・マニュアルのストレージ・ドライブのサービス(CRU)に関する項(http://docs.oracle.com/cd/E36975_01/html/E38045/z40000091011460.html#scrolltoc)を参照してください

7048707

構成部品、ライザー、ダブル・スタック

DBO

CRU

Sun Server X4-2サービス・マニュアルのPCIeライザーのサービス(CRU)に関する項(http://docs.oracle.com/cd/E36975_01/html/E38045/z40000f91037394.html#scrolltoc)を参照してください

7048710

1スロットのPCI Expressライザー構成部品

DBO

CRU

Sun Server X4-2サービス・マニュアルのPCIeライザーのサービス(CRU)に関する項(http://docs.oracle.com/cd/E36975_01/html/E38045/z40000f91037394.html#scrolltoc)を参照してください

7051223

構成部品、Dual 10GbE SFP+LP、X8 PCIe 2.0、RoHS:Y

DBO

CRU

Sun Dual 10GbE SFP+ PCIe 2.0 Low Profile Adapterユーザーズ・ガイド(http://docs.oracle.com/cd/E19407-01/820-7898-11/index.html)

7057184

構成部品、バッテリ・キャリア・リモート

HS

FRU

データベース・サーバーのディスク・コントローラBBUの交換

7058153

構成部品、マザーボード、X4-2

DBO

FRU

1. Sun Server X4-2サービス・マニュアルのマザーボードのサービス(FRU)に関する項(http://docs.oracle.com/cd/E36975_01/html/E38045/z40011771418436.html)を参照してください

2. サーバーの再起動後、[F2]を押します。

3. 起動順序を設定します。

7060020

ユニバーサル・アップグレード・リモート・バッテリ・キット

EBO

FRU

データベース・サーバーのディスク・コントローラBBUの交換

7060951

電源、AC、A256、F、12V、600W

HS

CRU

1. CMAの背面左側を取り外し、後方に動かして右方向に取り外します。
サーバーの真後ろにあるケーブルを支える伸縮式クロス・メンバーを格納すると、両方の電源にアクセスできます。

2. Sun Server X4-2サービス・マニュアルの電源供給のサービス(CRU)に関する項(http://docs.oracle.com/cd/E36975_01/html/E38045/z40000091014153.html#scrolltoc)を参照してください

3. CMAを交換します。

7069232

CPU、E5-2697 v2、12コア、2.7GHz

DBO

FRU

Sun Server X4-2サービス・マニュアルのプロセッサのサービス(FRU)に関する項(http://docs.oracle.com/cd/E36975_01/html/E38045/z40001d31037480.html#scrolltoc)を参照してください

関連トピック

- Oracle Exadata Storage Server Softwareユーザーズ・ガイド

A.6.4 Sun Server X3-2 Oracle Database Serverの部品

Sun Server X3-2 Database Machineには複数の交換部品があります。

次の図に、Sun Server X3-2 Oracle Database Serverの前面図を示します。

図A-7 Sun Server X3-2 Oracle Database Serverの前面図

次の図に、Sun Server X3-2 Oracle Database Serverの背面図を示します。

図A-8 Sun Server X3-2 Oracle Database Serverの背面図

次の表に、Sun Server X3-2 Oracle Database Serverの交換部品を示します。

注意:

Premier Support of Systemsで保証されている場合、次の表のすべての交換部品はFRUとみなされます。

表A-37 Sun Server X3-2 Oracle Database Serverの交換部品

部品番号

説明

修理カテゴリ

基本保証の範囲

修理手順

150-3993

バッテリ、3V、390MAH、リチウム、コイン型

DBO

CRU

Sun Server X3-2 (旧称Sun Fire X4170 M3)サービス・マニュアルのバッテリのサービス(CRU)に関する項(http://docs.oracle.com/cd/E22368_01/html/E27242/z40003f01423753.html#scrolltoc)を参照してください

350-1719

構成部品、スリム・レール、1U-2Uスナップイン

DBO

CRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。詳細は、「データベース・サーバーの電源切断」を参照してください。

2. Sun Server X3-2 (旧称Sun Fire X4170 M3)インストレーション・ガイドのツールレス・スライドレール・アセンブリの取付けに関する項(http://docs.oracle.com/cd/E22368_01/html/E27242/z40000671011466.html#scrolltoc)を参照してください

375-3696

InfiniBand(CX2)デュアルポートのCX2 4xQDR PCI-e

DBO

CRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。詳細は、「データベース・サーバーの電源切断」を参照してください。

2. Sun Server X3-2 (旧称Sun Fire X4170 M3)サービス・マニュアルのPCIeカードのサービス(CRU)に関する項(http://docs.oracle.com/cd/E22368_01/html/E27242/z40000f91037409.html#z40000f91407682)を参照してください

542-0388

300GB - 金具付きの10000RPM SAS SFFディスク構成部品

HS

CRU

Sun Server X3-2 (旧称Sun Fire X4170 M3)サービス・マニュアルのストレージ・ドライブのサービス(CRU)に関する項(http://docs.oracle.com/cd/E22368_01/html/E27242/z40000091011460.html#scrolltoc)を参照してください

注意: ドライブがZFSルート・プールの一部の場合は、次を参照してください。

http://docs.oracle.com/cd/E53394_01/html/E54801/gitgn.html

7013526

ファン・モジュール

HS

CRU

Sun Server X3-2 (旧称Sun Fire X4170 M3)サービス・マニュアルのファン・モジュールのサービス(CRU)に関する項(http://docs.oracle.com/cd/E22368_01/html/E27242/z40000091014194.html#scrolltoc)を参照してください

7018701

DIMM、16GB、DDR3、2RX4、1600、1.35V

DBO

CRU

Sun Server X3-2 (旧称Sun Fire X4170 M3)サービス・マニュアルのDIMMのサービス(CRU)に関する項(http://docs.oracle.com/cd/E22368_01/html/E27242/z40003f01425075.html#scrolltoc)を参照してください

7020774

ヒート・シンク、CPU 1U、60mm FIN

DBO

FRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。詳細は、「データベース・サーバーの電源切断」を参照してください。

2. Sun Server X3-2 (旧称Sun Fire X4170 M3)サービス・マニュアルのプロセッサのサービス(FRU)に関する項(http://docs.oracle.com/cd/E22368_01/html/E27242/z40001d31037480.html#scrolltoc)を参照してください

7026878

CPU、E5-2690、2.9GHzインテル・エイトコア135 W、RoHS:Y

DBO

FRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。詳細は、「データベース・サーバーの電源切断」を参照してください。

2. Sun Server X3-2 (旧称Sun Fire X4170 M3)サービス・マニュアルのプロセッサのサービス(FRU)に関する項(http://docs.oracle.com/cd/E22368_01/html/E27242/z40001d31037480.html#scrolltoc)を参照してください

7027478

ディスク・バックプレーン、RoHS:Y

DBO

FRU

Sun Server X3-2 (旧称Sun Fire X4170 M3)サービス・マニュアルのディスク・バックプレーンのサービス(FRU)に関する項(http://docs.oracle.com/cd/E22368_01/html/E27242/z40011771417642.html#scrolltoc)を参照してください

7039841

前面のインジケータ・モジュール

DBO

FRU

Sun Server X3-2 (旧称Sun Fire X4170 M3)サービス・マニュアルのPCIeライザーのサービス(CRU)に関する項(http://docs.oracle.com/cd/E22368_01/html/E27242/z40000f91037394.html#scrolltoc)を参照してください

7048712

マザーボード構成部品

DBO

FRU

Sun Server X3-2 (旧称Sun Fire X4170 M3)サービス・マニュアルのマザーボードのサービス(FRU)に関する項(http://docs.oracle.com/cd/E22368_01/html/E27242/z40011771418436.html#scrolltoc)を参照してください

7047410

電源、AC、A256、12V、600W

HS

CRU

1. CMAの背面左側を取り外し、後方に動かして右方向に取り外します。
サーバーの真後ろにあるケーブルを支える伸縮式クロス・メンバーを格納すると、両方の電源にアクセスできます。

2. Sun Server X3-2 (旧称Sun Fire X4170 M3)サービス・マニュアルの電源供給のサービス(CRU)に関する項(http://docs.oracle.com/cd/E22368_01/html/E27242/z40000091014153.html#scrolltoc)を参照してください

3. CMAを交換します。

7047503

構成部品、6GB SAS RAIDディスクPCIe HBA、RoHS:Y

DBO

CRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。詳細は、「データベース・サーバーの電源切断」を参照してください。

2. Sun Server X3-2 (旧称Sun Fire X4170 M3)サービス・マニュアルのPCIeカードのサービス(CRU)に関する項(http://docs.oracle.com/cd/E22368_01/html/E27242/z40000f91037409.html#z40000f91407682)を参照してください

3. 次のコマンドを使用して、新しいハードウェアがハードウェアおよびファームウェアの仕様を満たしていることを確認します。

/opt/oracle.SupportTools/CheckHWnFWprofile

注意: ディスクの交換時にサービス・マニュアルのコントローラ・コマンドを実行しないでください。

7048710

ライザー構成部品、ダブル・スタック

DBO

CRU

Sun Server X3-2 (旧称Sun Fire X4170 M3)サービス・マニュアルのPCIeライザーのサービス(CRU)に関する項(http://docs.oracle.com/cd/E22368_01/html/E27242/z40000f91037394.html#scrolltoc)を参照してください

7050794

6Gb SAS RAID PCIバッテリ・モジュール(LiON)、BBU-08、RoHS:Y

DBO

CRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。詳細は、「データベース・サーバーの電源切断」を参照してください。

2. Sun Storage 6 Gb SAS PCIe RAID HBA, Internal HBAモデルSGX-SAS6-R-INT-ZおよびSG-SAS6-R-INT-Zインストレーション・ガイド(http://docs.oracle.com/cd/E19221-01/html/E22410/index.html)を参照してください

7051223

構成部品、Dual 10GbE SFP+LP、X8 PCIe 2.0、RoHS:Y

DBO

CRU

Sun Dual 10GbE SFP+ PCIe 2.0 Low Profile Adapterユーザーズ・ガイド(http://docs.oracle.com/cd/E19407-01/820-7898-11/index.html)

7057184

構成部品、バッテリ・キャリア・リモート

HS

FRU

データベース・サーバーのディスク・コントローラBBUの交換

7060020

ユニバーサル・アップグレード・リモート・バッテリ・キット

EBO

FRU

データベース・サーバーのディスク・コントローラBBUの交換

関連トピック

- Oracle Exadata Storage Server Softwareユーザーズ・ガイド

A.6.5 Sun Fire X4170 M2 Oracle Database Serverの部品

次の図に、Sun Fire X4170 M2 Oracle Database Serverの前面図を示します。

図A-9 Sun Fire X4170 M2 Oracle Database Serverの前面図

1. ハード・ディスク・ドライブ。上位ドライブは、左から右にHDD1、およびHDD3です。下位ドライブは、左から右にHDD0、およびHDD2です。

次の図に、Sun Fire X4170 M2 Oracle Database Serverの背面図を示します。

図A-10 Sun Fire X4170 M2 Oracle Database Serverの背面図

1. InfiniBandホスト・チャネル・アダプタ

2. ギガビット・イーサネット・ポート

次の表に、Sun Fire X4170 M2 Oracle Database Serverの交換部品を示します。

注意:

Premier Support of Systemsで保証されている場合、次の表のすべての交換部品はFRUとみなされます。

表A-38 Sun Fire X4170 M2 Oracle Database Serverの交換部品

部品番号

説明

修理カテゴリ

基本保証の範囲

修理手順

150-3993

バッテリ、3V、390MAH、リチウム、コイン型

DBO

CRU

Sun Fire X4170 M2 Serverサービス・マニュアルのバッテリのサービスに関する項(http://docs.oracle.com/cd/E19477-01/820-5830-13/motherboard.html#50634787_71528)を参照してください

300-2233

タイプA247の760ワットの電力、RoHS:Y

HS

CRU

1. CMAの背面左側を取り外し、後方に動かして右方向に取り外します。
サーバーの真後ろにあるケーブルを支える伸縮式クロス・メンバーを格納すると、両方の電源にアクセスできます。

2. Sun Fire X4170 M2 Serverサービス・マニュアルの電源供給のサービスに関する項(http://docs.oracle.com/cd/E19762-01/E22369-02/hotswap.html#50581538_pgfId-1098206)を参照してください

3. CMAを交換します。

371-4889

2.93GHzのインテル・シックスコアXeon X5670、12MB、95W、RoHS:Y

DBO

FRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。詳細は、「データベース・サーバーの電源切断」を参照してください。

2. Sun Fire X4170 M2 Serverサービス・マニュアルのCPUのサービスに関する項(http://docs.oracle.com/cd/E19762-01/E22369-02/motherboard_x4170.html#50581523_23425)を参照してください

371-4966

DIMM、8GB、DDR3、2RX4、1333

DBO

CRU

Sun Fire X4170 M2 Serverサービス・マニュアルのDDR3 DIMMのサービスに関する項(http://docs.oracle.com/cd/E19762-01/E22369-02/motherboard_x4170.html#50581523_71526)を参照してください

371-4919

1U拡張レール・ラック取付けキット

DBO

FRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。詳細は、「データベース・サーバーの電源切断」を参照してください。

2. Sun Fire X4170、X4270およびX4275 Serverインストレーション・ガイドのスライドレールによるサーバーのラックへの取付けに関する項(http://docs.oracle.com/cd/E19477-01/820-5827-13/rack_install.html)を参照してください

371-4982

6GB SAS RAID PCIバッテリ・モジュール、RoHS:Y (LiON)、BBU-08

DBO

CRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。詳細は、「データベース・サーバーの電源切断」を参照してください。

2. Sun Storage 6 Gb SAS PCIe RAID HBA, Internal HBAモデルSGX-SAS6-R-INT-ZおよびSG-SAS6-R-INT-Zインストレーション・ガイド(http://docs.oracle.com/cd/E19221-01/html/E22410/index.html)を参照してください

371-4984

シックスコア・インテルXeon X5675プロセッサ(3.06GHz)、12MB、95W、RoHS:Y

DBO

FRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。詳細は、「データベース・サーバーの電源切断」を参照してください。

2. Sun Fire X4170 M2 Serverサービス・マニュアルのCPUのサービスに関する項(http://docs.oracle.com/cd/E19762-01/E22369-02/motherboard_x4170.html#50581523_23425)を参照してください

375-3696

InfiniBand(CX2)デュアルポートのCX2 4xQDR PCI-e

DBO

CRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。詳細は、「データベース・サーバーの電源切断」を参照してください。

2. Sun Fire X4170 M2 Serverサービス・マニュアルのPCIeカードのサービスに関する項(http://docs.oracle.com/cd/E19762-01/E22369-02/motherboard_x4170.html#50581523_pgfId-1286564)を参照してください

375-3701

6GB SAS RAIDディスクPCIe HBA、RoHS:Y

DBO

CRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。詳細は、「データベース・サーバーの電源切断」を参照してください。

2. Sun Fire X4170 M2 Serverサービス・マニュアルのPCIeカードのサービスに関する項(http://docs.oracle.com/cd/E19762-01/E22369-02/motherboard_x4170.html#50581523_pgfId-1286564)を参照してください

3. 次のコマンドを使用して、新しいハードウェアがハードウェアおよびファームウェアの仕様を満たしていることを確認します。

/opt/oracle.SupportTools/CheckHWnFWprofile

注意: ディスクの交換時にサービス・マニュアルのコントローラ・コマンドを実行しないでください。

375-3617

Dual 10GbE SFP+LP、RoHS:Y

DBO

CRU

Sun Dual 10GbE SFP+ PCIe 2.0 Low Profile Adapterユーザーズ・ガイド(http://docs.oracle.com/cd/E19407-01/820-7898-11/index.html)

511-1548

8スロットのディスク・バックプレーン、SATA DVD、RoHS:Y

DBO

FRU

Sun Fire X4170 M2 Serverサービス・マニュアルのストレージ・ドライブ・ケージのサービスに関する項(http://docs.oracle.com/cd/E19762-01/E22369-02/infrastructure_x4170.html#50581544_71557)を参照してください

511-1489

分電盤、RoHS:Y

DBO

FRU

Sun Fire X4170 M2 Serverサービス・マニュアルの分電盤のサービスに関する項(http://docs.oracle.com/cd/E19762-01/E22369-02/infrastructure_x4170.html#50581544_71558)を参照してください

530-3927

ケーブル、PDB、MB、1U+2U、リボン

DBO

CRU

Sun Fire X4170 M2 Serverサービス・マニュアルのケーブルのサービスに関する項(http://docs.oracle.com/cd/E19762-01/E22369-02/motherboard_x4170.html#50581523_82397)を参照してください

530-4228

ケーブル、mini-SAS、36 POS LONG、LY、RoHS:Y

DBO

CRU

Sun Fire X4170 M2 Serverサービス・マニュアルのケーブルのサービスに関する項(http://docs.oracle.com/cd/E19762-01/E22369-02/motherboard_x4170.html#50581523_82397)を参照してください

530-4417

ケーブル、ファン電源、1U

DBO

CRU

Sun Fire X4170 M2 Serverサービス・マニュアルのファン・モジュールのサービスに関する項(http://docs.oracle.com/cd/E19762-01/E22369-02/hotswap.html#50581538_28930)を参照してください

530-4431

ケーブル、ファン・データ、1U

DBO

CRU

Sun Fire X4170 M2 Serverサービス・マニュアルのケーブルのサービスに関する項(http://docs.oracle.com/cd/E19762-01/E22369-02/motherboard_x4170.html#50581523_82397)を参照してください

540-7869

300GB - 金具付きの10000RPM SAS SFFディスク構成部品

HS

CRU

Sun Fire X4170 M2 Serverサービス・マニュアルのストレージ・ドライブのサービスに関する項(http://docs.oracle.com/cd/E19762-01/E22369-02/hotswap.html#50581538_61628)を参照してください

注意: ドライブがZFSルート・プールの一部の場合は、次を参照してください。

http://docs.oracle.com/cd/E53394_01/html/E54801/gitgn.html

541-4081

システム・ボード構成部品、RoHS:Y

DBO

FRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。詳細は、「データベース・サーバーの電源切断」を参照してください。

2. Sun Fire X4170 M2 Serverサービス・マニュアルのマザーボードのサービスに関する項(http://docs.oracle.com/cd/E19762-01/E22369-02/motherboard_x4170.html#50581523_98526)を参照してください

3. 次のコマンドを使用して、新しいハードウェアがハードウェアおよびファームウェアの仕様を満たしていることを確認します。

/opt/oracle.SupportTools/CheckHWnFWprofile

541-2075

Bus_bar、電力、1U+2U、RoHS:Y

DBO

FRU

Sun Fire X4170 M2 Serverサービス・マニュアルの分電盤のサービスに関する項(http://docs.oracle.com/cd/E19762-01/E22369-02/infrastructure_x4170.html#50581544_71558)を参照してください

541-2545

グリース付きのXeon Heatsink、RoHS:Y、1U

DBO

FRU

Sun Fire X4170 M2 Serverサービス・マニュアルのCPUのサービスに関する項(http://docs.oracle.com/cd/E19762-01/E22369-02/motherboard_x4170.html#50581523_23425)を参照してください

541-4274

ファン・ボード構成部品、RoHS:Y

DBO

CRU

Sun Fire X4170 M2 Serverサービス・マニュアルのファン・ボードのサービスに関する項(http://docs.oracle.com/cd/E19762-01/E22369-02/infrastructure_x4170.html#50581544_pgfId-1286241)を参照してください

541-4276

ファン・モジュール、40 x 56mm、15300RPMファン、RoHS:Y

HS

CRU

Sun Fire X4170 M2 Serverサービス・マニュアルのファン・モジュールのサービスに関する項(http://docs.oracle.com/cd/E19762-01/E22369-02/hotswap.html#50581538_28930)を参照してください

541-4275

構成部品、CONN-BRD-BRKT、SATA、1U

DBO

FRU

Sun Fire X4170 M2 Serverサービス・マニュアルのパドル・ボードのサービスに関する項(http://docs.oracle.com/cd/E19762-01/E22369-02/infrastructure_x4170.html#50581544_71559)を参照してください

541-2636

構成部品、ライト・パイプ

DBO

FRU

Sun Fire X4170 M2 Serverサービス・マニュアルのフロント・コントロール・パネルのライト・パイプ構成部品のサービスに関する項(http://docs.oracle.com/cd/E19762-01/E22369-02/infrastructure_x4170.html#50581544_71563)を参照してください

541-2883

1スロットのx8 PCI Expressライザー構成部品、1U、RoHS:Y

DBO

CRU

Sun Fire X4170 M2 Serverサービス・マニュアルのPCIeライザーのサービスに関する項(http://docs.oracle.com/cd/E19762-01/E22369-02/motherboard_x4170.html#50581523_71527)を参照してください

541-2885

1スロットのx16 PCI Expressライザー構成部品、1U、RoHS:Y

DBO

CRU

Sun Fire X4170 M2 Serverサービス・マニュアルのPCIeライザーのサービスに関する項(http://docs.oracle.com/cd/E19762-01/E22369-02/motherboard_x4170.html#50581523_71527)を参照してください

541-2732

USB構成部品、DVDフィラー・パネル、RoHS:Y

DBO

CRU

交換手順は、上部カバーの外部サービス・ラベルを参照してください。

関連トピック

- Oracle Exadata Storage Server Softwareユーザーズ・ガイド

A.6.6 Sun Fire X4170 Oracle Database Serverの部品

次の図に、Sun Fire X4170 Oracle Database Serverの前面図を示します。

図A-11 Sun Fire X4170 Oracle Database Serverの前面図

1. ハード・ディスク・ドライブ。上位ドライブは、左から右にHDD1、およびHDD3です。下位ドライブは、左から右にHDD0、およびHDD2です。

次の図に、Sun Fire X4170 Oracle Database Serverの背面図を示します。

図A-12 Sun Fire X4170 Oracle Database Serverの背面図

1. InfiniBandホスト・チャネル・アダプタ

2. ギガビット・イーサネット・ポート

次の表に、Sun Fire X4170 Oracle Database Serverの交換部品を示します。

注意:

Premier Support of Systemsで保証されている場合、次の表のすべての交換部品はFRUとみなされます。

表A-39 Sun Fire X4170 Oracle Database Serverの交換部品

部品番号

説明

修理カテゴリ

基本保証の範囲

修理手順

150-3993

Panasonic BR2032バッテリ、RoHS:Yのシステム・ボード

DBO

CRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。詳細は、「Oracle Exadataラックの電源の投入および切断」を参照してください。

2. Sun Fire X4170、X4270およびX4275 Serverサービス・マニュアルのバッテリのサービスに関する項(http://docs.oracle.com/cd/E19477-01/820-5830-13/motherboard.html#50634787_71528)を参照してください

300-2143

760ワットの電力、RoHS:Y

HS

CRU

1. CMAの背面左側を取り外し、後方に動かして右方向に取り外します。
サーバーの真後ろにあるケーブルを支える伸縮式クロス・メンバーを格納すると、両方の電源にアクセスできます。

2. Sun Fire X4170、X4270およびX4275 Serverサービス・マニュアルの電源供給のサービスに関する項(http://docs.oracle.com/cd/E19477-01/820-5830-13/hotswap.html#50634786_11706)を参照してください

3. CMAを交換します。

371-4288

4GB Registered DDR3-1333 DIMM、RoHS:Y

DBO

CRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。詳細は、「データベース・サーバーの電源切断」を参照してください。

2. Sun Fire X4170、X4270およびX4275 Serverサービス・マニュアルのメモリー・モジュールのサービス(DIMM)に関する項(http://docs.oracle.com/cd/E19477-01/820-5830-13/motherboard.html#50634787_71526)を参照してください

371-4300

2.53GHzのクアッドコア・インテルXeon E5540、8MB、80W、RoHS:Y

DBO

FRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。詳細は、「データベース・サーバーの電源切断」を参照してください。

2. Sun Fire X4170、X4270およびX4275 Serverサービス・マニュアルのCPUのサービスに関する項(http://docs.oracle.com/cd/E19477-01/820-5830-13/motherboard.html#50634787_23425)を参照してください

371-4746

バッテリー・モジュール、RoHS:Yの6GB SAS RAIDディスクPCI、BBU-07

DBO

CRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。詳細は、「データベース・サーバーの電源切断」を参照してください。

2. Sun Storage 6 Gb SAS PCIe RAID HBA, Internal HBAモデルSGX-SAS6-R-INT-ZおよびSG-SAS6-R-INT-Zインストレーション・ガイド(http://docs.oracle.com/cd/E19221-01/html/E22410/index.html)を参照してください

371-4919

1U拡張レール・ラック取付けキット

DBO

FRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。詳細は、「データベース・サーバーの電源切断」を参照してください。

2. Sun Fire X4170、X4270およびX4275 Serverインストレーション・ガイドのスライドレールによるサーバーのラックへの取付けに関する項(http://docs.oracle.com/cd/E19477-01/820-5827-13/rack_install.html)を参照してください

375-3606

SunデュアルポートのQDR(40GB/s)InfiniBandホスト・チャネル・アダプタPCIe、RoHS:Y

DBO

CRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。詳細は、「データベース・サーバーの電源切断」を参照してください。

2. Sun Fire X4170、X4270およびX4275 Serverサービス・マニュアルのPCIeカードのサービスに関する項(http://docs.oracle.com/cd/E19477-01/820-5830-13/motherboard.html#50634787_86021)を参照してください

3. 「InfiniBandネットワーク構成の確認」を参照してください。

4. 次のコマンドを使用して、新しいハードウェアがハードウェアおよびファームウェアの仕様を満たしていることを確認します。

/opt/oracle.SupportTools/CheckHWnFWprofile

375-3644

6GB SAS RAIDディスクPCIe HBA、RoHS:Y

DBO

CRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。詳細は、「データベース・サーバーの電源切断」を参照してください。

2. Sun Fire X4170、X4270およびX4275 Serverサービス・マニュアルのPCIeカードのサービスに関する項(http://docs.oracle.com/cd/E19477-01/820-5830-13/motherboard.html#50634787_86021)を参照してください

3. 次のコマンドを使用して、新しいハードウェアがハードウェアおよびファームウェアの仕様を満たしていることを確認します。

/opt/oracle.SupportTools/CheckHWnFWprofile

注意: ディスクの交換時にサービス・マニュアルのコントローラ・コマンドを実行しないでください。

501-7696

分電盤、RoHS:Y

DBO

CRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。詳細は、「データベース・サーバーの電源切断」を参照してください。

2. Sun Fire X4170、X4270およびX4275 Serverサービス・マニュアルの分電盤のサービスに関する項(http://docs.oracle.com/cd/E19477-01/820-5830-13/infrastructure_x4170_x4270.html#50634783_71558)を参照してください

511-1283

8スロットのディスク・バックプレーン、SAS DVD、RoHS:Y

DBO

FRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。詳細は、「データベース・サーバーの電源切断」を参照してください。

2. Sun Fire X4170、X4270およびX4275 Serverサービス・マニュアルのストレージ・ドライブ・バックプレーンのサービスに関する項(http://docs.oracle.com/cd/E19477-01/820-5830-13/infrastructure_x4170_x4270.html#50634783_pgfId-1287120)を参照してください

530-3927

システム・ボード・ケーブルの分電盤、RoHS:Y

DBO

FRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。詳細は、「データベース・サーバーの電源切断」を参照してください。

2. Sun Fire X4170、X4270およびX4275 Serverサービス・マニュアルの分電盤のサービスに関する項(http://docs.oracle.com/cd/E19477-01/820-5830-13/infrastructure_x4170_x4270.html#50634783_71558)を参照してください

530-4228

4x Mini SAS/SATAケーブル、SFF-8087 - SFF-8087、690mm、RoHS:Y

DBO

FRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。詳細は、「データベース・サーバーの電源切断」を参照してください。

2. Sun Fire X4170、X4270およびX4275 Serverサービス・マニュアルのケーブルのサービスに関する項(http://docs.oracle.com/cd/E19477-01/820-5830-13/infrastructure_x4170_x4270.html#50634783_78576)を参照してください

540-7355

146GB 10K RPM SASディスク構成部品、RoHS:Y、次の部品を含む

- 金具

- ディスク

HS

CRU

Sun Fire X4170、X4270およびX4275 Serverサービス・マニュアルのストレージ・ドライブのサービスに関する項(http://docs.oracle.com/cd/E19477-01/820-5830-13/hotswap.html#50634786_61628)を参照してください

540-7868

146GB 10K RPM SASディスク構成部品、RoHS:Y、次の部品を含む

- 金具

- ディスク

HS

CRU

Sun Fire X4170、X4270およびX4275 Serverサービス・マニュアルのストレージ・ドライブのサービスに関する項(http://docs.oracle.com/cd/E19477-01/820-5830-13/hotswap.html#50634786_61628)を参照してください

541-2075

Bus_bar、電力、1U+2U、RoHS:Y

DBO

CRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。詳細は、「データベース・サーバーの電源切断」を参照してください。

2. Sun Fire X4170、X4270およびX4275 Serverサービス・マニュアルのCPUのサービスに関する項(http://docs.oracle.com/cd/E19477-01/820-5830-13/motherboard.html#50634787_23425)を参照してください

541-2112

ファン電源ボード、RoHS:Y、次の部品を含む

- 上部金具

- 下部金具

- ファン・ボード

DBO

CRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。詳細は、「データベース・サーバーの電源切断」を参照してください。

2. Sun Fire X4170、X4270およびX4275 Serverサービス・マニュアルのファン電源ボードのサービスに関する項(http://docs.oracle.com/cd/E19477-01/820-5830-13/infrastructure_x4170_x4270.html#50634783_pgfId-1286820)を参照してください

541-2542

トレイ付きのシステム・ボード構成部品、RoHS:Y

DBO

FRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。詳細は、「データベース・サーバーの電源切断」を参照してください。

2. Sun Fire X4170、X4270およびX4275 Serverサービス・マニュアルのマザーボード構成部品のサービスに関する項(http://docs.oracle.com/cd/E19477-01/820-5830-13/motherboard.html#50634787_98526)を参照してください

3. 次のコマンドを使用して、新しいハードウェアがハードウェアおよびファームウェアの仕様を満たしていることを確認します。

/opt/oracle.SupportTools/CheckHWnFWprofile

541-2545

グリース付きのXeon Heatsink、RoHS:Y

DBO

FRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。詳細は、「データベース・サーバーの電源切断」を参照してください。

2. Sun Fire X4170、X4270およびX4275 Serverサービス・マニュアルのCPUのサービスに関する項(http://docs.oracle.com/cd/E19477-01/820-5830-13/motherboard.html#50634787_23425)を参照してください

541-2636

ライト・パイプ構成部品、RoHS:Y

DBO

FRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。詳細は、「データベース・サーバーの電源切断」を参照してください。

2. Sun Fire X4170、X4270およびX4275 Serverサービス・マニュアルのフロント・コントロール・パネルのライト・パイプ構成部品のサービスに関する項(http://docs.oracle.com/cd/E19477-01/820-5830-13/infrastructure_x4170_x4270.html#50634783_71563)を参照してください

541-2732

USB構成部品、DVDフィラー・パネル、RoHS:Y

DBO

CRU

交換手順は、上部カバーの外部サービス・ラベルを参照してください。

541-2802

ファン・モジュール、40mmの4極ファン、Nidec、RoHS:Y

HS

CRU

Sun Fire X4170、X4270およびX4275 Serverサービス・マニュアルのファン・モジュールのサービスに関する項(http://docs.oracle.com/cd/E19477-01/820-5830-13/hotswap.html#50634786_28930)を参照してください

541-2883

次の部品を含む1スロットのx8 PCIeライザー構成部品

- 1スロットのx8 PCIeライザー、RoHS:Y

- ライザー取付け金具、RoHS:Y

DBO

CRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。詳細は、「データベース・サーバーの電源切断」を参照してください。

2. Sun Fire X4170、X4270およびX4275 Serverサービス・マニュアルのPCIeライザーのサービスに関する項(http://docs.oracle.com/cd/E19477-01/820-5830-13/motherboard.html#50634787_42797)を参照してください

541-2885

次の部品を含む1スロットのx16 PCIeライザー構成部品

- 1スロットのx16 PCIeライザー、RoHS:Y

- ライザー取付け金具、RoHS:Y

DBO

CRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。詳細は、「データベース・サーバーの電源切断」を参照してください。

2. Sun Fire X4170、X4270およびX4275 Serverサービス・マニュアルのPCIeライザーのサービスに関する項(http://docs.oracle.com/cd/E19477-01/820-5830-13/motherboard.html#50634787_42797)を参照してください

541-3512

コネクタ・ボード構成部品、SAS DVD、次の部品を含む

- 金具、RoHS:Y

- コネクタ・ボード、SATA DVD、RoHS:Y

- 磁気インターロック・スイッチ、RoHS:Y

DBO

FRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。詳細は、「データベース・サーバーの電源切断」を参照してください。

2. Sun Fire X4170、X4270およびX4275 Serverサービス・マニュアルのDVD/USBモジュールのサービスに関する項(http://docs.oracle.com/cd/E19477-01/820-5830-13/infrastructure_x4170_x4270.html#50634783_71556)を参照してください

関連トピック

- Oracle Exadata Storage Server Softwareユーザーズ・ガイド

A.6.7 Oracle Server X5-8およびX6-8 Oracle Database Serverの部品

次の図に、Oracle Server X5-8 Oracle Database Serverの前面図を示します。

図A-13 Oracle Server X5-8 Oracle Database Serverの前面図

次の図に、Oracle Server X5-8 Oracle Database Serverの背面図を示します。

図A-14 Oracle Server X5-8 Oracle Database Serverの背面図

次の表に、Oracle Server X5-8およびX6-8 Oracle Database Serverの交換部品を示します。

関連項目:

Oracle Server X5-8サービス・マニュアル(https://docs.oracle.com/cd/E56301_01/html/E56311/index.html)

表A-40 Oracle Exadata X5-8およびX6-8 Oracle Database Serverの交換部品

部品番号

説明

修理カテゴリ

基本保証の範囲

修理手順

350-1662

ユニバーサル・レール・キット

IR

CRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。詳細は、「データベース・サーバーの電源切断」を参照してください。

2. Oracle Server X5-8インストレーション・ガイドのラックの取付け手順に関する項(https://docs.oracle.com/cd/E56301_01/html/E56304/gnmnn.html)を参照してください

542-0287

SFF SAS、600GB、10K、SAS2、SFF

DBO

CRU

Oracle Server X5-8サービス・マニュアルのストレージ・ドライブのサービスに関する項(https://docs.oracle.com/cd/E56301_01/html/E56311/gnsej.html)を参照してください

7040622

構成部品、ファン・モジュール

DBO

FRU

Oracle Server X5-8サービス・マニュアルのファン・モジュールおよびファン・フレームのサービスに関する項(https://docs.oracle.com/cd/E56301_01/html/E56311/gnsaw.html)を参照してください

7046442

デュアル・ポート、QDR CX3、HCA

DBO

CRU

Oracle Server X5-8サービス・マニュアルのPCIeカードおよびデュアルPCIeカード・キャリアのサービス(DPCC)に関する項(https://docs.oracle.com/cd/E56301_01/html/E56311/gnsdm.html)を参照してください

7085209

HBA、12GB SAS PCIe 8ポートRAID (フラッシュ・モジュールとともに内蔵)

DBO

CRU

Oracle Server X5-8サービス・マニュアルのホスト・バス・アダプタ(HBA)カードのサービスに関する項(https://docs.oracle.com/cd/E56301_01/html/E56311/gnshd.html)を参照してください

7086345

構成部品、スーパー・キャップ、13.5ボルト、6.4F、SAS3 HBA

DBO

CRU

Oracle Server X5-8サービス・マニュアルのホスト・バス・アダプタ(HBA)カードのサービスに関する項(https://docs.oracle.com/cd/E56301_01/html/E56311/gnshd.html)を参照してください

7051223

デュアル10GBE、I2 SFP + PCIe 2.0、LP

DBO

CRU

Oracle Server X5-8サービス・マニュアルのPCIeカードおよびデュアルPCIeカード・キャリアのサービス(DPCC)に関する項(https://docs.oracle.com/cd/E56301_01/html/E56311/gnsdm.html)を参照してください

7054513

バス・バーおよびミッドプレーン・アセンブリ

DBO

FRU

Oracle Server X5-8サービス・マニュアルのミッドプレーン・アセンブリの交換に関する項(https://docs.oracle.com/cd/E56301_01/html/E56311/gnseg.html)を参照してください

7064767

ケーブル・アセンブリ、Mini SAS R/A - ストレート、280mm

DBO

CRU

Oracle Server X5-8サービス・マニュアルのSASケーブルのサービスに関する項(https://docs.oracle.com/cd/E56301_01/html/E56311/gnsgu.html)を参照してください

7067930

ファン・モジュール

HS

CRU

Oracle Server X5-8サービス・マニュアルのファン・モジュールおよびファン・フレームのサービスに関する項(https://docs.oracle.com/cd/E56301_01/html/E56311/gnsaw.html)を参照してください

7068817

電源

HS

CRU

Oracle Server X5-8サービス・マニュアルの電源ユニットのサービス(PSU)に関する項(https://docs.oracle.com/cd/E56301_01/html/E56311/gnsbd.html)を参照してください

7069359

構成部品、ラック・マウント

IR

CRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。詳細は、「データベース・サーバーの電源切断」を参照してください。

2. Oracle Server X5-8インストレーション・ガイドのラックの取付け手順に関する項(https://docs.oracle.com/cd/E56301_01/html/E56304/gnmnn.html)を参照してください

7073781

アセンブリ、LRDIMM、32GB、DDR3、1600、4Rx4、1.35v

DBO

CRU

Oracle Server X5-8サービス・マニュアルのCPUモジュール(CMOD)コンポーネントのサービスに関する項(https://docs.oracle.com/cd/E56301_01/html/E56311/gnsdq.html)を参照してください

7074696

前面のインジケータ・モジュール

DBO

FRU

Oracle Server X5-8サービス・マニュアルの前面のインジケータ・モジュールのサービス(FIM)に関する項(https://docs.oracle.com/cd/E56301_01/html/E56311/gnseu.html)を参照してください

7077138

デュアルPCIeカード・キャリア

DBO

CRU

Oracle Server X5-8サービス・マニュアルのPCIeカードおよびデュアルPCIeカード・キャリアのサービス(DPCC)に関する項(https://docs.oracle.com/cd/E56301_01/html/E56311/gnsdm.html)を参照してください

7077530

CPUモジュール

DBO

FRU

Oracle Server X5-8サービス・マニュアルのCPUモジュール(CMOD)コンポーネントのサービスに関する項(https://docs.oracle.com/cd/E56301_01/html/E56311/gnsdq.html)を参照してください

7078320

システム・モジュール

DBO

FRU

Oracle Server X5-8サービス・マニュアルのシステム・モジュール(SMOD)コンポーネントのサービスに関する項(https://docs.oracle.com/cd/E56301_01/html/E56311/gnsem.html)を参照してください

7080100

CPUヒートシンク

DBO

FRU

Oracle Server X5-8サービス・マニュアルのCPUモジュール(CMOD)コンポーネントのサービスに関する項(https://docs.oracle.com/cd/E56301_01/html/E56311/gnsdq.html)を参照してください

7111402

CPU、E7-8895、v3、2.6 G、175 W、18 C、E0

DBO

FRU

Oracle Server X5-8サービス・マニュアルのCPUモジュール(CMOD)コンポーネントのサービスに関する項(https://docs.oracle.com/cd/E56301_01/html/E56311/gnsdq.html)を参照してください

7100477

Sun Quad Port GbE PCIe 2.0 Low Profileアダプタ、UTP

DBO

CRU

Oracle Server X5-8サービス・マニュアルのPCIeカードおよびデュアルPCIeカード・キャリアのサービス(DPCC)に関する項(https://docs.oracle.com/cd/E56301_01/html/E56311/gnsdm.html)を参照してください

A.6.8 Sun Server X4-8 Oracle Database Serverの部品

次の図に、Sun Server X4-8 Oracle Database Serverの前面図を示します。

図A-15 Sun Server X4-8 Oracle Database Serverの前面図

次の図に、Sun Server X4-8 Oracle Database Serverの背面図を示します。

図A-16 Sun Server X4-8 Oracle Database Serverの背面図

次の表に、Sun Server X4-8 Oracle Database Serverの交換部品を示します。

関連項目:

Sun Server X4-8ドキュメント・ライブラリ(http://docs.oracle.com/cd/E40591_01/)

表A-41 Sun Server X4-8 Oracle Database Serverの交換部品

部品番号

説明

修理カテゴリ

基本保証の範囲

修理手順

350-1662

ユニバーサル・レール・キット

IR

CRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。詳細は、「データベース・サーバーの電源切断」を参照してください。

2. Sun Server X4-8インストレーション・ガイドのラックの取付け手順に関する項(http://docs.oracle.com/cd/E40591_01/html/E40305/gnmnn.html)を参照してください

542-0287

SFF SAS、600GB、10K、SAS2、SFF

DBO

CRU

Sun Server X4-8サービス・マニュアルのストレージ・ドライブのサービスに関する項(http://docs.oracle.com/cd/E40591_01/html/E40317/gnsej.html)を参照してください

7040622

構成部品、ファン・モジュール

DBO

FRU

Sun Server X4-8サービス・マニュアルのファン・モジュールおよびファン・フレームのサービスに関する項(http://docs.oracle.com/cd/E40591_01/html/E40317/gnsaw.html)を参照してください

7046442

デュアル・ポート、QDR CX3、HCA

DBO

CRU

Sun Server X4-8サービス・マニュアルのPCIeカードおよびデュアルPCIeカード・キャリアのサービス(DPCC)に関する項(http://docs.oracle.com/cd/E40591_01/html/E40317/gnsdm.html)を参照してください

7047503

構成部品、6GB、SAS RAIDディスクPCIe HBA、RoHS:Y

DBO

CRU

Sun Server X4-8サービス・マニュアルのホスト・バス・アダプタ(HBA)カードのサービスに関する項(http://docs.oracle.com/cd/E40591_01/html/E40317/gnshd.html)を参照してください

7051223

デュアル10GBE、I2 SFP + PCIe 2.0、LP

DBO

CRU

Sun Server X4-8サービス・マニュアルのPCIeカードおよびデュアルPCIeカード・キャリアのサービス(DPCC)に関する項(http://docs.oracle.com/cd/E40591_01/html/E40317/gnsdm.html)を参照してください

7054513

バス・バーおよびミッドプレーン・アセンブリ

DBO

FRU

Sun Server X4-8サービス・マニュアルのミッドプレーン・アセンブリの交換に関する項(http://docs.oracle.com/cd/E40591_01/html/E40317/gnseg.html)を参照してください

7064767

ケーブル・アセンブリ、Mini SAS R/A - ストレート、280mm

DBO

CRU

Sun Server X4-8サービス・マニュアルのSASケーブルのサービスに関する項(http://docs.oracle.com/cd/E40591_01/html/E40317/gnsgu.html)を参照してください

7067930

ファン・モジュール

HS

CRU

Sun Server X4-8サービス・マニュアルのファン・モジュールおよびファン・フレームのサービスに関する項(http://docs.oracle.com/cd/E40591_01/html/E40317/gnsaw.html)を参照してください

7068817

電源

HS

CRU

Sun Server X4-8サービス・マニュアルの電源ユニットのサービス(PSU)に関する項(http://docs.oracle.com/cd/E40591_01/html/E40317/gnsbd.html)を参照してください

7069359

構成部品、ラック・マウント

IR

CRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。詳細は、「データベース・サーバーの電源切断」を参照してください。

2. Sun Server X4-8インストレーション・ガイドのラックの取付け手順に関する項(http://docs.oracle.com/cd/E40591_01/html/E40305/gnmnn.html)を参照してください

7073781

アセンブリ、LRDIMM、32GB、DDR3、1600、4Rx4、1.35v

DBO

CRU

Sun Server X4-8サービス・マニュアルのCPUモジュール(CMOD)コンポーネントのサービスに関する項(http://docs.oracle.com/cd/E40591_01/html/E40317/gnsdq.html)を参照してください

7074696

前面のインジケータ・モジュール

DBO

FRU

Sun Server X4-8サービス・マニュアルの前面のインジケータ・モジュールのサービス(FIM)に関する項(http://docs.oracle.com/cd/E40591_01/html/E40317/gnseu.html)を参照してください

7077138

デュアルPCIeカード・キャリア

DBO

CRU

Sun Server X4-8サービス・マニュアルのPCIeカードおよびデュアルPCIeカード・キャリアのサービス(DPCC)に関する項(http://docs.oracle.com/cd/E40591_01/html/E40317/gnsdm.html)を参照してください

7077530

CPUモジュール

DBO

FRU

Sun Server X4-8サービス・マニュアルのCPUモジュール(CMOD)コンポーネントのサービスに関する項(http://docs.oracle.com/cd/E40591_01/html/E40317/gnsdq.html)を参照してください

7078320

システム・モジュール

DBO

FRU

Sun Server X4-8サービス・マニュアルのシステム・モジュール(SMOD)コンポーネントのサービスに関する項(http://docs.oracle.com/cd/E40591_01/html/E40317/gnsem.html)を参照してください

7080100

CPUヒートシンク

DBO

FRU

Sun Server X4-8サービス・マニュアルのCPUモジュール(CMOD)コンポーネントのサービスに関する項(http://docs.oracle.com/cd/E40591_01/html/E40317/gnsdq.html)を参照してください

7080247

CPU、E7-8895、v2、2.8G、155W、15C、D1

DBO

FRU

Sun Server X4-8サービス・マニュアルのCPUモジュール(CMOD)コンポーネントのサービスに関する項(http://docs.oracle.com/cd/E40591_01/html/E40317/gnsdq.html)を参照してください

7100477

Sun Quad Port GbE PCIe 2.0 Low Profileアダプタ、UTP

DBO

CRU

Sun Server X4-8サービス・マニュアルのPCIeカードおよびデュアルPCIeカード・キャリアのサービス(DPCC)に関する項(http://docs.oracle.com/cd/E40591_01/html/E40317/gnsdm.html)を参照してください

A.6.9 Sun Server X2-8 Oracle Database Serverの部品

次の図に、Sun Server X2-8 Oracle Database Serverの前面図を示します。

図A-17 Sun Server X2-8 Oracle Database Serverの前面図

1. 電源。

2. ハード・ディスク・ドライブ。上位ドライブは、左から右にXL4、XL5、XL6およびXL7です。下位ドライブは、左から右にXL0、XL1、XL2およびXL3です。

3. CPUモジュール。モジュールは、下から上にBL0、BL1、BL2およびBL3です。

次の図に、Sun Fire X4800 Oracle Database Serverの背面図を示します。

図A-18 Sun Server X2-8 Oracle Database Serverの背面図

1. ファン・モジュール。

2. Network Express Module。

3. InfiniBand EM(CX2)デュアルポートPCI Expressモジュール。

次の表に、Sun Server X2-8 Oracle Database Serverの交換部品を示します。

注意:

Premier Support of Systemsで保証されている場合、次の表のすべての交換部品はFRUとみなされます。

表A-42 Sun Server X2-8 Oracle Database Serverの交換部品

部品番号

説明

修理カテゴリ

基本保証の範囲

修理手順

150-3993

CMODバッテリ

DBO

CRU

1. Sun Server X2-8 (旧称Sun Fire X4800 M2)サービス・マニュアルのCMODバッテリの交換方法(CRU)に関する項(http://docs.oracle.com/cd/E20815_01/html/E20819/gjeub.html#scrolltoc)を参照してください

2. 次のコマンドを使用して、新しいハードウェアがハードウェアおよびファームウェアの仕様を満たしていることを確認します。

/opt/oracle.SupportTools/CheckHWnFWprofile

150-1204

3V、サービス・プロセッサ用のリチウム・バッテリ、RoHS:Y

HS

CRU

300-2159

電源ユニット、AC、A239、F、12V、165A、2Kw

HS

CRU

1. CMAの背面左側を取り外し、後方に動かして右方向に取り外します。
サーバーの真後ろにあるケーブルを支える伸縮式クロス・メンバーを格納すると、両方の電源にアクセスできます。

2. Sun Server X2-8 (旧称Sun Fire X4800 M2)サービス・マニュアルの電源の取外しおよび取付け(CRU)に関する項(http://docs.oracle.com/cd/E20815_01/html/E20819/gjfdt.html#scrolltoc)を参照してください

3. CMAを交換します。

310-0225

グリース付きのHeatsink、RoHS:Y、1U

DBO

FRU

1. Sun Server X2-8 (旧称Sun Fire X4800 M2)サービス・マニュアルのCPUおよびヒートシンク構成部品の交換(FRU)に関する項(http://docs.oracle.com/cd/E20815_01/html/E20819/gjgrp.html#scrolltoc)を参照してください

2. 次のコマンドを使用して、新しいハードウェアがハードウェアおよびファームウェアの仕様を満たしていることを確認します。

/opt/oracle.SupportTools/CheckHWnFWprofile

371-5057

CPU、インテルXeon E7-8870、10コア、2.4GHz、130W

DBO

FRU

1. Sun Server X2-8 (旧称Sun Fire X4800 M2)サービス・マニュアルのCPUおよびヒートシンク構成部品の交換(FRU)に関する項(http://docs.oracle.com/cd/E20815_01/html/E20819/gjgrp.html#scrolltoc)を参照してください

2. 次のコマンドを使用して、新しいハードウェアがハードウェアおよびファームウェアの仕様を満たしていることを確認します。

/opt/oracle.SupportTools/CheckHWnFWprofile

371-4742

ユニバーサル・ラック取付けキット

DBO

FRU

1. Sun Server X2-8 (旧称Sun Fire X4800 M2)インストレーション・ガイドのユニバーサル・ラック取付けキットを使用したラックへのサーバーの設置に関する項(http://docs.oracle.com/cd/E20815_01/html/E20816/gjlel.html#scrolltoc)を参照してください

2. 次のコマンドを使用して、新しいハードウェアがハードウェアおよびファームウェアの仕様を満たしていることを確認します。

/opt/oracle.SupportTools/CheckHWnFWprofile

371-4579

構成部品、ファン・モジュール

HS

CRU

Sun Server X2-8 (旧称Sun Fire X4800 M2)サービス・マニュアルのファン・モジュールの取外しおよび取付け(CRU)に関する項(http://docs.oracle.com/cd/E20815_01/html/E20819/gjfpo.html#scrolltoc)を参照してください

371-4982

6Gb SAS RAID PCIバッテリ・モジュール、RoHS:Y(LiON)、BBU-08

DBO

CRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。詳細は、「Exadata Storage Serverのシャットダウン」を参照してください。

2. Sun Storage 6 Gb SAS PCIe RAID HBA, Internal HBAモデルSGX-SAS6-R-INT-ZおよびSG-SAS6-R-INT-Zインストレーション・ガイド(http://docs.oracle.com/cd/E19221-01/html/E22410/z4002f731006662.html#scrolltoc)のHBAの削除に関する項を参照してください

3. 次のコマンドを使用して、新しいハードウェアがハードウェアおよびファームウェアの仕様を満たしていることを確認します。

/opt/oracle.SupportTools/CheckHWnFWprofile

371-5023

DIMM、32GB (2 x 16GB)、DDR3、1066MHZ

DBO

CRU

1. Sun Server X2-8 (旧称Sun Fire X4800 M2)サービス・マニュアルのDIMMの取外しおよび取付け(CRU)に関する項(http://docs.oracle.com/cd/E20815_01/html/E20819/gjfvw.html#scrolltoc)を参照してください

2. 次のコマンドを使用して、新しいハードウェアがハードウェアおよびファームウェアの仕様を満たしていることを確認します。

/opt/oracle.SupportTools/CheckHWnFWprofile

375-3648

10GbEファブリック拡張モジュール(FEM)

DBO

CRU

1. Sun Server X2-8 (旧称Sun Fire X4800 M2)サービス・マニュアルのファブリック拡張モジュールの取外しおよび取付け(CRU)に関する項(http://docs.oracle.com/cd/E20815_01/html/E20819/gjmui.html#scrolltoc)を参照してください

2. 次のコマンドを使用して、新しいハードウェアがハードウェアおよびファームウェアの仕様を満たしていることを確認します。

/opt/oracle.SupportTools/CheckHWnFWprofile

375-3605

InfiniBand EM(CX2)デュアルポートのCX2 4xQDR PCI-e EXP_MODULE

DBO

CRU

1. Sun Server X2-8 (旧称Sun Fire X4800 M2)サービス・マニュアルのPCIe EMの取外しおよび取付け(CRU)に関する項(http://docs.oracle.com/cd/E20815_01/html/E20819/gjfrl.html#scrolltoc)を参照してください

2. 次のコマンドを使用して、新しいハードウェアがハードウェアおよびファームウェアの仕様を満たしていることを確認します。

/opt/oracle.SupportTools/CheckHWnFWprofile

375-3647

6GB/s SAS 2 REM 8pin RAID HBA(REM)(取付け済)

DBO

CRU

1. Sun Server X2-8 (旧称Sun Fire X4800 M2)サービス・マニュアルのRAID拡張モジュールの取外しおよび取付け(CRU)に関する項(http://docs.oracle.com/cd/E20815_01/html/E20819/gjldn.html#scrolltoc)を参照してください

2. 次のコマンドを使用して、新しいハードウェアがハードウェアおよびファームウェアの仕様を満たしていることを確認します。

/opt/oracle.SupportTools/CheckHWnFWprofile

451-4586

システム・ボード構成部品、CMOD

DBO

取外しおよび取付け用のCRU

交換用のFRU

1. Sun Server X2-8 (旧称Sun Fire X4800 M2)サービス・マニュアルのCMODの追加、取外しおよび取付け(CRU)に関する項(http://docs.oracle.com/cd/E20815_01/html/E20819/gjfsd.html#scrolltoc)を参照してください

2. 次のコマンドを使用して、新しいハードウェアがハードウェアおよびファームウェアの仕様を満たしていることを確認します。

/opt/oracle.SupportTools/CheckHWnFWprofile

511-1062

構成部品、バックプレーンHDD BD

DBO

FRU

1. Sun Server X2-8 (旧称Sun Fire X4800 M2)サービス・マニュアルのハード・ドライブ・バックプレーンの交換(FRU)に関する項(http://docs.oracle.com/cd/E20815_01/html/E20819/gjgqc.html#scrolltoc)を参照してください

2. 次のコマンドを使用して、新しいハードウェアがハードウェアおよびファームウェアの仕様を満たしていることを確認します。

/opt/oracle.SupportTools/CheckHWnFWprofile

530-3936

マルチポート・ドングル・ケーブル・アダプタ、RoHS:Y

HS

CRU

Sun Server X2-8 (旧称Sun Fire X4800 M2)サービス・マニュアルのマルチポート・ケーブルの取外しおよび取付けに関する項(http://docs.oracle.com/cd/E20815_01/html/E20819/gjukk.html#scrolltoc)を参照してください

530-4214

ケーブル、SAS長

DBO

FRU

1. Sun Server X2-8 (旧称Sun Fire X4800 M2)サービス・マニュアルのハード・ドライブ・バックプレーン・ケーブルのルーティングおよび指定に関する項(http://docs.oracle.com/cd/E20815_01/html/E20819/gjkuz.html#scrolltoc)を参照してください

2. 次のコマンドを使用して、新しいハードウェアがハードウェアおよびファームウェアの仕様を満たしていることを確認します。

/opt/oracle.SupportTools/CheckHWnFWprofile

530-4215

ケーブル、SAS短

DBO

FRU

1. Sun Server X2-8 (旧称Sun Fire X4800 M2)サービス・マニュアルのハード・ドライブ・バックプレーン・ケーブルのルーティングおよび指定に関する項(http://docs.oracle.com/cd/E20815_01/html/E20819/gjkuz.html#scrolltoc)を参照してください

2. 次のコマンドを使用して、新しいハードウェアがハードウェアおよびファームウェアの仕様を満たしていることを確認します。

/opt/oracle.SupportTools/CheckHWnFWprofile

530-4216

ケーブル、ディスク・プレーン、電力

DBO

FRU

1. Sun Server X2-8 (旧称Sun Fire X4800 M2)サービス・マニュアルのハード・ドライブ・バックプレーン・ケーブルのルーティングおよび指定に関する項(http://docs.oracle.com/cd/E20815_01/html/E20819/gjkuz.html#scrolltoc)を参照してください

2. 次のコマンドを使用して、新しいハードウェアがハードウェアおよびファームウェアの仕様を満たしていることを確認します。

/opt/oracle.SupportTools/CheckHWnFWprofile

540-7640

部分構成部品モジュール: 構成部品、シャーシ、ミッドプレーン、X4800

DBO

FRU

1. Sun Server X2-8 (旧称Sun Fire X4800 M2)サービス・マニュアルの部分構成部品モジュールの取外しおよび取付け(FRU)に関する項(http://docs.oracle.com/cd/E20815_01/html/E20819/gjgnp.html#scrolltoc)を参照してください

2. 次のコマンドを使用して、新しいハードウェアがハードウェアおよびファームウェアの仕様を満たしていることを確認します。

/opt/oracle.SupportTools/CheckHWnFWprofile

540-7645

構成部品、サービス・プロセッサ、X4800

HS

CRU

Sun Server X2-8 (旧称Sun Fire X4800 M2)サービス・マニュアルのサービス・プロセッサ・モジュールの取外しおよび取付け(CRU)に関する項(http://docs.oracle.com/cd/E20815_01/html/E20819/gjfvy.html#scrolltoc)を参照してください

540-7637

Network Express Module(NEM)– 4x 10GbE + パススルーに4x GbE NEM

HS

CRU

Sun Server X2-8 (旧称Sun Fire X4800 M2)サービス・マニュアルのNEMまたはNEMフィラーの取外しおよび取付け(CRU)に関する項(http://docs.oracle.com/cd/E20815_01/html/E20819/gjfse.html#scrolltoc)を参照してください

540-7672

構成部品、モジュール、ファン相互接続

DBO

FRU

1. Sun Server X2-8 (旧称Sun Fire X4800 M2)サービス・マニュアルのファン・モジュール・コントローラ・ボードの交換(FRU)に関する項(http://docs.oracle.com/cd/E20815_01/html/E20819/gjmts.html#scrolltoc)を参照してください

2. 次のコマンドを使用して、新しいハードウェアがハードウェアおよびファームウェアの仕様を満たしていることを確認します。

/opt/oracle.SupportTools/CheckHWnFWprofile

542-0300

300GB 10K RPM 2.5インチSAS HDDおよび金具

HS

CRU

Sun Server X2-8 (旧称Sun Fire X4800 M2)サービス・マニュアルのハード・ドライブの取外しおよび取付け(CRU)に関する項(http://docs.oracle.com/cd/E20815_01/html/E20819/gjfex.html#scrolltoc)を参照してください

注意: ドライブがZFSルート・プールの一部の場合は、http://docs.oracle.com/cd/E53394_01/html/E54801/gitgn.htmlを参照してください

関連トピック

- Oracle Exadata Storage Server Softwareユーザーズ・ガイド

A.6.10 Sun Fire X4800 Oracle Database Serverの部品

次の図に、Sun Fire X4800 Oracle Database Serverの前面図を示します。

図A-19 Sun Fire X4800 Oracle Database Serverの前面図

1. 電源。

2. ハード・ディスク・ドライブ。上位ドライブは、左から右にXL4、XL5、XL6およびXL7です。下位ドライブは、左から右にXL0、XL1、XL2およびXL3です。

3. CPUモジュール。モジュールは、下から上にBL0、BL1、BL2およびBL3です。

次の図に、Sun Fire X4800 Oracle Database Serverの背面図を示します。

図A-20 Sun Fire X4800 Oracle Database Serverの背面図

1. ファン・モジュール。

2. Network Express Module。

3. InfiniBand EM(CX2)デュアルポートPCI Expressモジュール。

次の表に、Sun Fire X4800 Oracle Database Serverの交換部品を示します。

注意:

Premier Support of Systemsで保証されている場合、次の表のすべての交換部品はFRUとみなされます。

表A-43 Sun Fire X4800 Oracle Database Serverの交換部品

部品番号

説明

修理カテゴリ

基本保証の範囲

修理手順

150-3993

CMODバッテリ

DBO

CRU

1. Sun Fire X4800 Serverサービス・マニュアルのCMODバッテリの交換方法(CRU)に関する項(http://docs.oracle.com/cd/E19140-01/html/821-0282/gjeub.html#scrolltoc)を参照してください

2. 次のコマンドを使用して、新しいハードウェアがハードウェアおよびファームウェアの仕様を満たしていることを確認します。

/opt/oracle.SupportTools/CheckHWnFWprofile

150-1204

3V、サービス・プロセッサ用のリチウム・バッテリ、RoHS:Y

HS

CRU

300-2159

電源ユニット、AC、A239、F、12V、165A、2Kw

HS

CRU

1. CMAの背面左側を取り外し、後方に動かして右方向に取り外します。
サーバーの真後ろにあるケーブルを支える伸縮式クロス・メンバーを格納すると、両方の電源にアクセスできます。

2. Sun Fire X4800 Serverサービス・マニュアルの電源の取外しおよび取付け(CRU)に関する項(http://docs.oracle.com/cd/E19140-01/html/821-0282/gjfdt.html#scrolltoc)を参照してください

3. CMAを交換します。

310-0225

グリース付きのHeatsink、RoHS:Y、1U

DBO

FRU

1. Sun Fire X4800 Serverサービス・マニュアルのCPUおよびヒートシンク構成部品の交換(FRU)に関する項(http://docs.oracle.com/cd/E19140-01/html/821-0282/gjgrp.html#scrolltoc)を参照してください

2. 次のコマンドを使用して、新しいハードウェアがハードウェアおよびファームウェアの仕様を満たしていることを確認します。

/opt/oracle.SupportTools/CheckHWnFWprofile

371-4860

CPU、Intel X7560、2.26G、130W、8CR

DBO

FRU

1. Sun Fire X4800 Serverサービス・マニュアルのCPUおよびヒートシンク構成部品の交換(FRU)に関する項(http://docs.oracle.com/cd/E19140-01/html/821-0282/gjgrp.html#scrolltoc)を参照してください

2. 次のコマンドを使用して、新しいハードウェアがハードウェアおよびファームウェアの仕様を満たしていることを確認します。

/opt/oracle.SupportTools/CheckHWnFWprofile

371-4742

ユニバーサル・ラック取付けキット

DBO

FRU

1. Sun Server X2-8 (旧称Sun Fire X4800 M2)インストレーション・ガイドのユニバーサル・ラック取付けキットを使用したラックへのサーバーの設置に関する項(http://docs.oracle.com/cd/E20815_01/html/E20816/gjlel.html#scrolltoc)を参照してください

2. 次のコマンドを使用して、新しいハードウェアがハードウェアおよびファームウェアの仕様を満たしていることを確認します。

/opt/oracle.SupportTools/CheckHWnFWprofile

371-4579

構成部品、ファン・モジュール

HS

CRU

Sun Fire X4800 Serverサービス・マニュアルのファン・モジュールの取外しおよび取付け(CRU)に関する項(http://docs.oracle.com/cd/E19140-01/html/821-0282/gjfpo.html#scrolltoc)を参照してください

371-4982

6Gb SAS RAID PCIバッテリ・モジュール、RoHS:Y(LiON)、BBU-08

DBO

CRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。詳細は、「Exadata Storage Serverのシャットダウン」を参照してください。

2. Sun Storage 6 Gb SAS PCIe RAID HBA, Internal HBAモデルSGX-SAS6-R-INT-ZおよびSG-SAS6-R-INT-Zインストレーション・ガイド(http://docs.oracle.com/cd/E19221-01/html/E22410/z4002f731006662.html#scrolltoc)のHBAの削除に関する項を参照してください

3. 次のコマンドを使用して、新しいハードウェアがハードウェアおよびファームウェアの仕様を満たしていることを確認します。

/opt/oracle.SupportTools/CheckHWnFWprofile

375-3648

10GbEファブリック拡張モジュール(FEM)

DBO

CRU

1. Sun Fire X4800 Serverサービス・マニュアルのファブリック拡張モジュールの取外しおよび取付け(CRU)に関する項(http://docs.oracle.com/cd/E19140-01/html/821-0282/gjmui.html#scrolltoc)を参照してください

2. 次のコマンドを使用して、新しいハードウェアがハードウェアおよびファームウェアの仕様を満たしていることを確認します。

/opt/oracle.SupportTools/CheckHWnFWprofile

375-3605

InfiniBand EM(CX2)デュアルポートのCX2 4xQDR PCI-e EXP_MODULE

DBO

CRU

1. Sun Fire X4800 Serverサービス・マニュアルのPCIe EMの取外しおよび取付け(CRU)に関する項(http://docs.oracle.com/cd/E19140-01/html/821-0282/gjfrl.html#scrolltoc)を参照してください

2. 次のコマンドを使用して、新しいハードウェアがハードウェアおよびファームウェアの仕様を満たしていることを確認します。

/opt/oracle.SupportTools/CheckHWnFWprofile

375-3647

6GB/s SAS 2 REM 8pin RAID HBA(REM)(取付け済)

DBO

CRU

1. Sun Fire X4800 Serverサービス・マニュアルのRAID拡張モジュールの取外しおよび取付け(CRU)に関する項(http://docs.oracle.com/cd/E19140-01/html/821-0282/gjldn.html#scrolltoc)を参照してください

2. 次のコマンドを使用して、新しいハードウェアがハードウェアおよびファームウェアの仕様を満たしていることを確認します。

/opt/oracle.SupportTools/CheckHWnFWprofile

511-1062

構成部品、バックプレーンHDD BD

DBO

FRU

1. Sun Fire X4800 Serverサービス・マニュアルのハード・ドライブ・バックプレーンの交換(FRU)に関する項(http://docs.oracle.com/cd/E19140-01/html/821-0282/gjgqc.html#scrolltoc)を参照してください

2. 次のコマンドを使用して、新しいハードウェアがハードウェアおよびファームウェアの仕様を満たしていることを確認します。

/opt/oracle.SupportTools/CheckHWnFWprofile

530-3936

マルチポート・ドングル・ケーブル・アダプタ、RoHS:Y

HS

CRU

Sun Fire X4800 Serverサービス・マニュアルのマルチポート・ケーブルの取外しおよび取付けに関する項(http://docs.oracle.com/cd/E19140-01/html/821-0282/gjukk.html#scrolltoc)を参照してください

530-4214

ケーブル、SAS長

DBO

FRU

1. Sun Fire X4800 Serverサービス・マニュアルのハード・ドライブ・バックプレーン・ケーブルのルーティングおよび指定に関する項(http://docs.oracle.com/cd/E19140-01/html/821-0282/gjkuz.html#scrolltoc)を参照してください

2. 次のコマンドを使用して、新しいハードウェアがハードウェアおよびファームウェアの仕様を満たしていることを確認します。

/opt/oracle.SupportTools/CheckHWnFWprofile

530-4215

ケーブル、SAS短

DBO

FRU

1. Sun Fire X4800 Serverサービス・マニュアルのハード・ドライブ・バックプレーン・ケーブルのルーティングおよび指定に関する項(http://docs.oracle.com/cd/E19140-01/html/821-0282/gjkuz.html#scrolltoc)を参照してください

2. 次のコマンドを使用して、新しいハードウェアがハードウェアおよびファームウェアの仕様を満たしていることを確認します。

/opt/oracle.SupportTools/CheckHWnFWprofile

530-4216

ケーブル、ディスク・プレーン、電力

DBO

FRU

1. Sun Fire X4800 Serverサービス・マニュアルのハード・ドライブ・バックプレーン・ケーブルのルーティングおよび指定に関する項(http://docs.oracle.com/cd/E19140-01/html/821-0282/gjkuz.html#scrolltoc)を参照してください

2. 次のコマンドを使用して、新しいハードウェアがハードウェアおよびファームウェアの仕様を満たしていることを確認します。

/opt/oracle.SupportTools/CheckHWnFWprofile

540-7640

部分構成部品モジュール: 構成部品、シャーシ、ミッドプレーン、X4800

DBO

FRU

1. Sun Fire X4800 Serverサービス・マニュアルの部分構成部品モジュールの取外しおよび取付け(FRU)に関する項(http://docs.oracle.com/cd/E19140-01/html/821-0282/gjgnp.html#scrolltoc)を参照してください

2. 次のコマンドを使用して、新しいハードウェアがハードウェアおよびファームウェアの仕様を満たしていることを確認します。

/opt/oracle.SupportTools/CheckHWnFWprofile

540-7645

構成部品、サービス・プロセッサ、X4800

HS

CRU

Sun Fire X4800 Serverサービス・マニュアルのサービス・プロセッサ・モジュールの取外しおよび取付け(CRU)に関する項(http://docs.oracle.com/cd/E19140-01/html/821-0282/gjfvy.html#scrolltoc)を参照してください

540-7637

Network Express Module(NEM)– 4x 10GbE + パススルーに4x GbE NEM

HS

CRU

Sun Fire X4800 Serverサービス・マニュアルのNEMまたはNEMフィラーの取外しおよび取付け(CRU)に関する項(http://docs.oracle.com/cd/E19140-01/html/821-0282/gjfse.html#scrolltoc)を参照してください

540-7672

構成部品、モジュール、ファン相互接続

DBO

FRU

1. Sun Fire X4800 Serverサービス・マニュアルのファン・モジュールの取外しおよび取付け(CRU)に関する項(http://docs.oracle.com/cd/E19140-01/html/821-0282/gjmts.html#scrolltoc)を参照してください

2. 次のコマンドを使用して、新しいハードウェアがハードウェアおよびファームウェアの仕様を満たしていることを確認します。

/opt/oracle.SupportTools/CheckHWnFWprofile

541-3426

構成部品、ブレード、CPU SMPモジュール(CMOD)

DBO

取外しおよび取付け用のCRU

交換用のFRU

1. Sun Fire X4800 Serverサービス・マニュアルのCMODの追加、取外しおよび取付け(CRU)に関する項(http://docs.oracle.com/cd/E19140-01/html/821-0282/gjfsd.html#scrolltoc)を参照してください

2. 次のコマンドを使用して、新しいハードウェアがハードウェアおよびファームウェアの仕様を満たしていることを確認します。

/opt/oracle.SupportTools/CheckHWnFWprofile

542-0246

DIMM、16GB (2 x 8GB)、DDR3、1066MHZ

DBO

CRU

1. Sun Fire X4800 Serverサービス・マニュアルのDIMMの取外しおよび取付け(CRU)に関する項(http://docs.oracle.com/cd/E19140-01/html/821-0282/gjfvw.html#scrolltoc)を参照してください

2. 次のコマンドを使用して、新しいハードウェアがハードウェアおよびファームウェアの仕様を満たしていることを確認します。

/opt/oracle.SupportTools/CheckHWnFWprofile

542-0300

300GB 10K RPM 2.5インチSAS HDDおよび金具

HS

CRU

Sun Fire X4800 Serverサービス・マニュアルのハード・ドライブの取外しおよび取付け(CRU)に関する項(http://docs.oracle.com/cd/E19140-01/html/821-0282/gjfex.html#scrolltoc)を参照してください

注意: ドライブがZFSルート・プールの一部の場合は、http://docs.oracle.com/cd/E53394_01/html/E54801/gitgn.htmlを参照してください

関連トピック

- Oracle Exadata Storage Server Softwareユーザーズ・ガイド

A.7 Exadata Storage Serverの部品

次の表に、Exadata Storage Serverの部品を示します。

- High Capacity Exadata Storage Server X6-2 Serverの部品

- Extreme Flash Exadata Storage Server X6-2 Serverの部品

- High Capacity Exadata Storage Server X5-2 Serverの部品

- Extreme Flash Exadata Storage Server X5-2 Serverの部品

- Exadata Storage Server X4-2L Serverの部品

- Exadata Storage Server X3-2L Serverの部品

- Sun Fire X4270 M2 Serverを使用したExadata Storage Serverの部品

- Sun Fire X4275 Serverを使用したExadata Storage Serverの部品

A.7.1 High Capacity Exadata Storage Server X6-2 Serverの部品

次の表に、High Capacity Exadata Storage Server X6-2 Serverの交換部品を示します。

注意:

Premier Support of Systemsで保証されている場合、次の表のすべての交換部品はFRUとみなされます。

表A-44 High Capacity Exadata Storage Server X6-2 Serverの交換部品

部品番号

説明

修理カテゴリ

基本保証の範囲

修理手順

350-1719

構成部品、1U-2Uスナップイン、スリム・レール・ラック

EBO

CRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。詳細は、「データベース・サーバーの電源切断」を参照してください。

2. Oracle Exadata Storage Server X6-2 High Capacityサービス・マニュアルのサーバーのラックへの再取付けに関する項(http://docs.oracle.com/cd/E62172_01/html/E63692/z40004191003899.html#scrolltoc)を参照してください

370-5621

3ボルト・リチウム・バッテリ

EBO

FRU

Oracle Exadata Storage Server X6-2 High Capacityサービス・マニュアルのバッテリのサービスに関する項(http://docs.oracle.com/cd/E62172_01/html/E63692/z40000f91037456.html#scrolltoc)を参照してください

7014226

ケーブル、インターロック、125mm

EBO

FRU

Oracle Exadata Storage Server X6-2 High Capacityサービス・マニュアルのSASケーブルのサービスに関する項(http://docs.oracle.com/cd/E62172_01/html/E63692/goitq.html#scrolltoc)を参照してください

7017231

インジケータ構成部品、右

EBO

FRU

Oracle Exadata Storage Server X6-2 High Capacityサービス・マニュアルの前面LED/USBインジケータ・モジュールのサービスに関する項(http://docs.oracle.com/cd/E62172_01/html/E63692/goity.html#scrolltoc)を参照してください

7023515

ディスク・バックプレーン構成部品、2背面

EBO

FRU

Oracle Exadata Storage Server X6-2 High Capacityサービス・マニュアルのストレージ・ドライブ・バックプレーンのサービスに関する項(http://docs.oracle.com/cd/E62172_01/html/E63692/goitv.html#scrolltoc)を参照してください

7044130

電源、A258、1000W、AC入力

HS

FRU

1. CMAの背面左側を取り外し、後方に動かして右方向に取り外します。
サーバーの真後ろにあるケーブルを支える伸縮式クロス・メンバーを格納すると、両方の電源にアクセスできます。

2. Oracle Exadata Storage Server X6-2 High Capacityサービス・マニュアルの電源供給のサービスに関する項(http://docs.oracle.com/cd/E62172_01/html/E63692/z40000091014153.html#scrolltoc)を参照してください

3. CMAを交換します。

7045042

ファン構成部品、2U、80 x 80、Ferrite、center_rotate

HS

FRU

Oracle Exadata Storage Server X6-2 High Capacityサービス・マニュアルのファン・モジュールのサービスに関する項(http://docs.oracle.com/cd/E62172_01/html/E63692/z40000091014194.html#scrolltoc)を参照してください

7046442

構成部品、デュアル・ポート、QDR CX3、ホスト・チャネル・アダプタ

EBO

FRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。詳細は、「データベース・サーバーの電源切断」を参照してください。

2. Oracle Exadata Storage Server X6-2 High Capacityサービス・マニュアルのPCIeカードのサービスに関する項(http://docs.oracle.com/cd/E62172_01/html/E63692/z40000f91037409.html#scrolltoc)を参照してください

3. 「InfiniBandネットワーク構成の確認」を参照してください。

4. 次のコマンドを使用して、新しいハードウェアがハードウェアおよびファームウェアの仕様を満たしていることを確認します。

/opt/oracle.SupportTools/CheckHWnFWprofile

7064884

ヒート・シンク、CPU

EBO

FRU

Oracle Exadata Storage Server X6-2 High Capacityサービス・マニュアルのプロセッサのサービスに関する項(http://docs.oracle.com/cd/E62172_01/html/E63692/goiwq.html#scrolltoc)を参照してください

7066824

構成部品、ドライブ、8TB、3.5インチ、SAS/7200rpm

HS

FRU

Oracle Exadata Storage Server X6-2 High Capacityサービス・マニュアルのストレージ・ドライブおよびリア・ドライブのサービスに関する項(http://docs.oracle.com/cd/E62172_01/html/E63692/z40000091011460.html#scrolltoc)を参照してください

7069337

構成部品、バックプレーン、12X3.5、W/SAS拡張、2U

EBO

FRU

Oracle Exadata Storage Server X6-2 High Capacityサービス・マニュアルのストレージ・ドライブ・バックプレーンのサービスに関する項(http://docs.oracle.com/cd/E62172_01/html/E63692/goitv.html#scrolltoc)を参照してください

7078070

DIMM、16GB、RDIMM、DDR4、2400

EBO

FRU

Oracle Exadata Storage Server X6-2 High Capacityサービス・マニュアルのDIMMのサービスに関する項(http://docs.oracle.com/cd/E62172_01/html/E63692/ceicjagi.html#scrolltoc)を参照してください

7085209

HBA、12GB SAS PCIe 8ポートRAID (フラッシュ・モジュールとともに内蔵)

EBO

FRU

Oracle Exadata Storage Server X6-2 High Capacityサービス・マニュアルのOracle Storage 12 Gb/s SAS PCIe RAID HBAカードのサービスに関する項(http://docs.oracle.com/cd/E62172_01/html/E63692/goivo.html#scrolltoc)を参照してください

7086345

構成部品、スーパー・キャップ、13.5ボルト、6.4F、SAS3 HBA

EBO

FRU

Oracle Exadata Storage Server X6-2 High Capacityサービス・マニュアルのOracle Storage 12 Gb/s SAS PCIe RAID HBAカードのサービスに関する項(http://docs.oracle.com/cd/E62172_01/html/E63692/goivo.html#scrolltoc)を参照してください

7086346

ケーブル、スーパー・キャップ、620M、6ピン、ストレート、SAS3 HBA

EBO

FRU

Oracle Exadata Storage Server X6-2 High Capacityサービス・マニュアルのSASケーブルのサービスに関する項(http://docs.oracle.com/cd/E62172_01/html/E63692/goitq.html#scrolltoc)を参照してください

7090170

フラッシュ・ドライブ、MLC、OSA ID、USB、8GB

EBO

FRU

Oracle Exadata Storage Server X6-2 High Capacityサービス・マニュアルの内部USBフラッシュ・ドライブのサービスに関する項(http://docs.oracle.com/cd/E62172_01/html/E63692/ceiicfbd.html#scrolltoc)を参照してください

7090698

構成部品、3.2TB eMLCフラッシュF320 NVMeカード

EBO

FRU

Oracle Flash Accelerator F320 PCIe Cardユーザー・ガイド(http://docs.oracle.com/cd/E65386_01/html/E65387/index.html)を参照してください

7095102

CPU、E5-2630 V4、2.2G、85W、10コア、R-2 (SR206)

EBO

FRU

Oracle Exadata Storage Server X6-2 High Capacityサービス・マニュアルのプロセッサのサービスに関する項(http://docs.oracle.com/cd/E62172_01/html/E63692/goiwq.html#scrolltoc)を参照してください

7096185

構成部品、インジケータ、左

EBO

FRU

Oracle Exadata Storage Server X6-2 High Capacityサービス・マニュアルの前面LED/USBインジケータ・モジュールのサービスに関する項(http://docs.oracle.com/cd/E62172_01/html/E63692/goity.html#scrolltoc)を参照してください

7098504

ASM、MOBOトレイ

EBO

FRU

Oracle Exadata Storage Server X6-2 High Capacityサービス・マニュアルのマザーボード構成部品のサービスに関する項(http://docs.oracle.com/cd/E62172_01/html/E63692/goiup.html#scrolltoc)を参照してください

関連トピック

- Oracle Exadata Storage Server Softwareユーザーズ・ガイド

A.7.2 Extreme Flash Exadata Storage Server X6-2 Serverの部品

Exadata Extreme Flash X6-2 Serverには複数の交換部品があります。

次の表に、Extreme Flash Exadata Storage Server X6-2 Serverの交換部品を示します。

注意:

Premier Support of Systemsで保証されている場合、次の表のすべての交換部品はFRUとみなされます。

表A-45 Extreme Flash Exadata Storage Server X6-2 Serverの交換部品

部品番号

説明

修理カテゴリ

基本保証の範囲

修理手順

350-1719

構成部品、1U-2Uスナップイン、スリム・レール・ラック

EBO

CRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。詳細は、「データベース・サーバーの電源切断」を参照してください。

2. Oracle Exadata Storage Server X6-2 Extreme Flashサービス・マニュアルのストレージ・サーバーのラックへの再取付けに関する項(http://docs.oracle.com/cd/E62172_01/html/E63689/z40004191003899.html#scrolltoc)を参照してください

370-5621

3ボルト・リチウム・バッテリ

EBO

FRU

Oracle Exadata Storage Server X6-2 Extreme Flashサービス・マニュアルのバッテリのサービスに関する項(http://docs.oracle.com/cd/E62172_01/html/E63689/z40000f91037456.html#scrolltoc)を参照してください

7014226

ケーブル、インターロック、125mm

EBO

FRU

Oracle Exadata Storage Server X6-2 Extreme Flashサービス・マニュアルのNVMeケーブルのサービスに関する項(http://docs.oracle.com/cd/E62172_01/html/E63689/goioo.html#scrolltoc)を参照してください

7017231

インジケータ構成部品、右

EBO

FRU

Oracle Exadata Storage Server X6-2 Extreme Flashサービス・マニュアルの前面LED/USBインジケータ・モジュールのサービスに関する項(http://docs.oracle.com/cd/E62172_01/html/E63689/goipz.html#scrolltoc)を参照してください

7044130

電源、A258、1000ワットAC入力

HS

FRU

1. CMAの背面左側を取り外し、後方に動かして右方向に取り外します。
サーバーの真後ろにあるケーブルを支える伸縮式クロス・メンバーを格納すると、両方の電源にアクセスできます。

2. Oracle Exadata Storage Server X6-2 Extreme Flashサービス・マニュアルの電源供給のサービスに関する項(http://docs.oracle.com/cd/E62172_01/html/E63689/z40000091014153.html#scrolltoc)を参照してください

3. CMAを交換します。

7045042

ファン構成部品、2U、80 x 80、Ferrite、center_rotate

HS

FRU

Oracle Exadata Storage Server X6-2 Extreme Flashサービス・マニュアルのファン・モジュールのサービスに関する項(http://docs.oracle.com/cd/E62172_01/html/E63689/z40000091014194.html#scrolltoc)を参照してください

7046442

構成部品、デュアル・ポート、QDR CX3、ホスト・チャネル・アダプタ

EBO

FRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。詳細は、「データベース・サーバーの電源切断」を参照してください。

2. Oracle Exadata Storage Server X6-2 Extreme Flashサービス・マニュアルのPCIeカードのサービスに関する項(http://docs.oracle.com/cd/E62172_01/html/E63689/z40000f91037409.html#scrolltoc)を参照してください

3. 「InfiniBandネットワーク構成の確認」を参照してください。

4. 次のコマンドを使用して、新しいハードウェアがハードウェアおよびファームウェアの仕様を満たしていることを確認します。

/opt/oracle.SupportTools/CheckHWnFWprofile

7064634

構成部品、スイッチ、PCI-e、X8、IDT

EBO

FRU

Oracle Exadata Storage Server X6-2 Extreme Flashサービス・マニュアルのPCIeカードのサービスに関する項(http://docs.oracle.com/cd/E62172_01/html/E63689/z40000f91037409.html#scrolltoc)を参照してください

7064884

ヒート・シンク、CPU

EBO

FRU

Oracle Exadata Storage Server X6-2 Extreme Flashサービス・マニュアルのプロセッサのサービスに関する項(http://docs.oracle.com/cd/E62172_01/html/E63689/goink.html#scrolltoc)を参照してください

7078070

DIMM、16GB、RDIMM、DDR4、2400

EBO

FRU

Oracle Exadata Storage Server X6-2 Extreme Flashサービス・マニュアルのDIMMのサービスに関する項(http://docs.oracle.com/cd/E62172_01/html/E63689/ceicjagi.html#scrolltoc)を参照してください

7090170

フラッシュ・ドライブ、MLC、OSA ID、USB、8GB

EBO

FRU

Oracle Exadata Storage Server X6-2 Extreme Flashサービス・マニュアルの内部USBフラッシュ・ドライブのサービスに関する項(http://docs.oracle.com/cd/E62172_01/html/E63689/ceiicfbd.html#scrolltoc)を参照してください

7093483

ASM、BP、Ultra-NVME

EBO

FRU

Oracle Exadata Storage Server X6-2 Extreme Flashサービス・マニュアルのストレージ・ドライブ・バックプレーンのサービスに関する項(http://docs.oracle.com/cd/E62172_01/html/E63689/goimw.html#scrolltoc)を参照してください

7093931

構成部品、SSD、3.2TB、eMLC-NAND、SFF-2.5インチNVMe 1.0、X4

HS

FRU

Oracle 3.2 TB NVMe SSDユーザー・ガイドのNVMeストレージ・ドライブのサービスに関する項(http://docs.oracle.com/cd/E65386_01/html/E65389/z40002cc9112.html#scrolltoc)を参照してください

7095102

CPU、E5-2630 V4、2.2G、85W、10コア、R-2 (SR206)

EBO

FRU

Oracle Exadata Storage Server X6-2 Extreme Flashサービス・マニュアルのプロセッサのサービスに関する項(http://docs.oracle.com/cd/E62172_01/html/E63689/goink.html#scrolltoc)を参照してください

7095801

ケーブル、NVME、HD41、RA-HD4i、STR、6xバンドル

EBO

FRU

Oracle Exadata Storage Server X6-2 Extreme Flashサービス・マニュアルのNVMeケーブルのサービスに関する項(http://docs.oracle.com/cd/E62172_01/html/E63689/goioo.html#scrolltoc)を参照してください

7096185

構成部品、インジケータ、左

EBO

FRU

Oracle Exadata Storage Server X6-2 Extreme Flashサービス・マニュアルの前面LED/USBインジケータ・モジュールのサービスに関する項(http://docs.oracle.com/cd/E62172_01/html/E63689/goipz.html#scrolltoc)を参照してください

7098504

ASM、MOBOトレイ

EBO

FRU

Oracle Exadata Storage Server X6-2 Extreme Flashサービス・マニュアルのマザーボード構成部品のサービスに関する項(http://docs.oracle.com/cd/E62172_01/html/E63689/goiqp.html#scrolltoc)を参照してください

関連トピック

- Oracle Exadata Storage Server Softwareユーザーズ・ガイド

- Exadata Storage Serverの物理ディスクの保守

A.7.3 High Capacity Exadata Storage Server X5-2 Serverの部品

High Capacity Exadata Storage Server X5-2 Serverには複数の交換部品があります。

次の図に、High Capacity Exadata Storage Server X5-2 Serverの前面図を示します。

図A-21 High Capacity Exadata Storage Server X5-2 Serverの前面図

次の図に、High Capacity Exadata Storage Server X5-2 Serverの背面図を示します。

図A-22 High Capacity Exadata Storage Server X5-2 Serverの背面図

次の表に、High Capacity Exadata Storage Server X5-2 Serverの交換部品を示します。

注意:

Premier Support of Systemsで保証されている場合、次の表のすべての交換部品はFRUとみなされます。

表A-46 High Capacity Exadata Storage Server X5-2 Serverの交換部品

部品番号

説明

修理カテゴリ

基本保証の範囲

修理手順

350-1719

構成部品、1U-2Uスナップイン、スリム・レール・ラック

EBO

CRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。詳細は、「データベース・サーバーの電源切断」を参照してください。

2. Oracle Exadata Storage Server X5-2 High Capacityサービス・マニュアルのサーバーのラックへの再取付けに関する項(http://docs.oracle.com/cd/E41033_01/html/E55080/z40004191003899.html#scrolltoc)を参照してください

370-5621

3ボルト・リチウム・バッテリ

EBO

FRU

Oracle Exadata Storage Server X5-2 High Capacityサービス・マニュアルのバッテリのサービスに関する項(http://docs.oracle.com/cd/E41033_01/html/E55080/z40000f91037456.html#scrolltoc)を参照してください

7014226

ケーブル、インターロック、125mm

EBO

FRU

Oracle Exadata Storage Server X5-2 High Capacityサービス・マニュアルのSASケーブルのサービスに関する項(http://docs.oracle.com/cd/E41033_01/html/E55080/goitq.html#scrolltoc)を参照してください

7017231

インジケータ構成部品、右

EBO

FRU

Oracle Exadata Storage Server X5-2 High Capacityサービス・マニュアルの前面LED/USBインジケータ・モジュールのサービスに関する項(http://docs.oracle.com/cd/E41033_01/html/E55080/goity.html#scrolltoc)を参照してください

7023515

ディスク・バックプレーン構成部品、2背面

EBO

FRU

Oracle Exadata Storage Server X5-2 High Capacityサービス・マニュアルのストレージ・ドライブおよびリア・ドライブのサービスに関する項(http://docs.oracle.com/cd/E41033_01/html/E55080/z40000091011460.html#scrolltoc)を参照してください

7044130

電源、A258、1000W、AC入力

HS

FRU

1. CMAの背面左側を取り外し、後方に動かして右方向に取り外します。
サーバーの真後ろにあるケーブルを支える伸縮式クロス・メンバーを格納すると、両方の電源にアクセスできます。

2. Oracle Exadata Storage Server X5-2 High Capacityサービス・マニュアルの電源供給のサービスに関する項(http://docs.oracle.com/cd/E41033_01/html/E55080/z40000091014153.html#scrolltoc)を参照してください

3. CMAを交換します。

7045042

ファン構成部品、2U、80 x 80、Ferrite、center_rotate

HS

FRU

Oracle Exadata Storage Server X5-2 High Capacityサービス・マニュアルのファン・モジュールのサービスに関する項(http://docs.oracle.com/cd/E41033_01/html/E55080/z40000091014194.html#scrolltoc)を参照してください

7046442

構成部品、デュアル・ポート、QDR CX3、ホスト・チャネル・アダプタ

EBO

FRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。詳細は、「データベース・サーバーの電源切断」を参照してください。

2. Oracle Exadata Storage Server X5-2 High Capacityサービス・マニュアルのPCIeカードのサービスに関する項(http://docs.oracle.com/cd/E41033_01/html/E55080/z40000f91037409.html#scrolltoc)を参照してください

3. 「InfiniBandネットワーク構成の確認」を参照してください。

4. 次のコマンドを使用して、新しいハードウェアがハードウェアおよびファームウェアの仕様を満たしていることを確認します。

/opt/oracle.SupportTools/CheckHWnFWprofile

7064884

ヒート・シンク、CPU

EBO

FRU

Oracle Exadata Storage Server X5-2 High Capacityサービス・マニュアルのプロセッサのサービスに関する項(http://docs.oracle.com/cd/E41033_01/html/E55080/goiwq.html#scrolltoc)を参照してください

7066824

構成部品、ドライブ、4TB、3.5インチ、SAS/7200rpm

HS

FRU

Oracle Exadata Storage Server X5-2 High Capacityサービス・マニュアルのストレージ・ドライブおよびリア・ドライブのサービスに関する項(http://docs.oracle.com/cd/E41033_01/html/E55080/z40000091011460.html#scrolltoc)を参照してください

7069337

構成部品、バックプレーン、12X3.5、W/SAS拡張、2U

EBO

FRU

Oracle Exadata Storage Server X5-2 High Capacityサービス・マニュアルのストレージ・ドライブ・バックプレーンのサービスに関する項(http://docs.oracle.com/cd/E41033_01/html/E55080/goitv.html#scrolltoc)を参照してください

7078070

DIMM、8GB、RDIMM、DDR4、2133

EBO

FRU

Oracle Exadata Storage Server X5-2 High Capacityサービス・マニュアルのDIMMのサービスに関する項(http://docs.oracle.com/cd/E41033_01/html/E55080/ceicjagi.html#scrolltoc)を参照してください

7085209

HBA、12GB SAS PCIe 8ポートRAID (フラッシュ・モジュールとともに内蔵)

EBO

FRU

Oracle Exadata Storage Server X5-2 High Capacityサービス・マニュアルのOracle Storage 12 Gb/s SAS PCIe RAID HBAカードのサービスに関する項(http://docs.oracle.com/cd/E41033_01/html/E55080/goivo.html#scrolltoc)を参照してください

7086345

構成部品、スーパー・キャップ、13.5ボルト、6.4F、SAS3 HBA

EBO

FRU

Oracle Exadata Storage Server X5-2 High Capacityサービス・マニュアルのOracle Storage 12 Gb/s SAS PCIe RAID HBAカードのサービスに関する項(http://docs.oracle.com/cd/E41033_01/html/E55080/goivo.html#scrolltoc)を参照してください

7086346

ケーブル、スーパー・キャップ、620M、6ピン、ストレート、SAS3 HBA

EBO

FRU

Oracle Exadata Storage Server X5-2 High Capacityサービス・マニュアルのSASケーブルのサービスに関する項(http://docs.oracle.com/cd/E41033_01/html/E55080/goitq.html#scrolltoc)を参照してください

7090170

フラッシュ・ドライブ、MLC、OSA ID、USB、8GB

EBO

FRU

Oracle Exadata Storage Server X5-2 High Capacityサービス・マニュアルの内部USBフラッシュ・ドライブのサービスに関する項(http://docs.oracle.com/cd/E41033_01/html/E55080/ceiicfbd.html#scrolltoc)を参照してください

7090698

構成部品、1.6TB eMLCフラッシュF160 NVMeカード、Aura 3.0 (LP BRKT付き)

EBO

FRU

Oracle Flash Accelerator F160 PCIe Cardユーザー・ガイド(http://docs.oracle.com/cd/E54943_01/html/E54947/index.html)を参照してください

7095102

CPU、E5-2630 V3、2.4G、85W、8コア、R-2 (SR206)

EBO

Oracle Exadata Storage Server X5-2 High Capacityサービス・マニュアルのプロセッサのサービスに関する項(http://docs.oracle.com/cd/E41033_01/html/E55080/goiwq.html#scrolltoc)を参照してください

7096185

構成部品、インジケータ、左

EBO

FRU

Oracle Exadata Storage Server X5-2 High Capacityサービス・マニュアルの前面LED/USBインジケータ・モジュールのサービスに関する項(http://docs.oracle.com/cd/E41033_01/html/E55080/goity.html#scrolltoc)を参照してください

7098504

ASM、MOBOトレイ

EBO

FRU

Oracle Exadata Storage Server X5-2 High Capacityサービス・マニュアルのマザーボード構成部品のサービスに関する項(http://docs.oracle.com/cd/E41033_01/html/E55080/goiup.html#scrolltoc)を参照してください

関連トピック

- Oracle Exadata Storage Server Softwareユーザーズ・ガイド

A.7.4 Extreme Flash Exadata Storage Server X5-2 Serverの部品

次の図に、Extreme Flash Exadata Storage Server X5-2 Serverの前面図を示します。

図A-23 Extreme Flash Exadata Storage Server X5-2 Serverの前面図

次の図に、Extreme Flash Exadata Storage Server X5-2 Serverの背面図を示します。

図A-24 Extreme Flash Exadata Storage Server X5-2 Serverの背面図

次の表に、Extreme Flash Exadata Storage Server X5-2 Serverの交換部品を示します。

注意:

Premier Support of Systemsで保証されている場合、次の表のすべての交換部品はFRUとみなされます。

表A-47 Extreme Flash Exadata Storage Server X5-2 Serverの交換部品

部品番号

説明

修理カテゴリ

基本保証の範囲

修理手順

350-1719

構成部品、1U-2Uスナップイン、スリム・レール・ラック

EBO

CRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。詳細は、「データベース・サーバーの電源切断」を参照してください。

2. Oracle Exadata Storage Server X5-2 Extreme Flashサービス・マニュアルのストレージ・サーバーのラックへの再取付けに関する項(http://docs.oracle.com/cd/E41033_01/html/E55031/z40004191003899.html#scrolltoc)を参照してください

370-5621

3ボルト・リチウム・バッテリ

EBO

FRU

Oracle Exadata Storage Server X5-2 Extreme Flashサービス・マニュアルのバッテリのサービスに関する項(http://docs.oracle.com/cd/E41033_01/html/E55031/z40000f91037456.html#scrolltoc)を参照してください

7014226

ケーブル、インターロック、125mm

EBO

FRU

Oracle Exadata Storage Server X5-2 Extreme Flashサービス・マニュアルのNVMeケーブルのサービスに関する項(http://docs.oracle.com/cd/E41033_01/html/E55031/goioo.html#scrolltoc)を参照してください

7017231

インジケータ構成部品、右

EBO

FRU

Oracle Exadata Storage Server X5-2 Extreme Flashサービス・マニュアルの前面LED/USBインジケータ・モジュールのサービスに関する項(http://docs.oracle.com/cd/E41033_01/html/E55031/goipz.html#scrolltoc)を参照してください

7044130

電源、A258、1000ワットAC入力

HS

FRU

1. CMAの背面左側を取り外し、後方に動かして右方向に取り外します。
サーバーの真後ろにあるケーブルを支える伸縮式クロス・メンバーを格納すると、両方の電源にアクセスできます。

2. Oracle Exadata Storage Server X5-2 Extreme Flashサービス・マニュアルの電源供給のサービスに関する項(http://docs.oracle.com/cd/E41033_01/html/E55031/z40000091014153.html#scrolltoc)を参照してください

3. CMAを交換します。

7045042

ファン構成部品、2U、80 x 80、Ferrite、center_rotate

HS

FRU

Oracle Exadata Storage Server X5-2 Extreme Flashサービス・マニュアルのファン・モジュールのサービスに関する項(http://docs.oracle.com/cd/E41033_01/html/E55031/z40000091014194.html#scrolltoc)を参照してください

7046442

構成部品、デュアル・ポート、QDR CX3、ホスト・チャネル・アダプタ

EBO

FRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。詳細は、「データベース・サーバーの電源切断」を参照してください。

2. Oracle Exadata Storage Server X5-2 Extreme Flashサービス・マニュアルのPCIeカードのサービスに関する項(http://docs.oracle.com/cd/E41033_01/html/E55031/z40000f91037409.html#scrolltoc)を参照してください

3. 「InfiniBandネットワーク構成の確認」を参照してください。

4. 次のコマンドを使用して、新しいハードウェアがハードウェアおよびファームウェアの仕様を満たしていることを確認します。

/opt/oracle.SupportTools/CheckHWnFWprofile

7064634

構成部品、スイッチ、PCI-e、X8、IDT

EBO

FRU

Oracle Exadata Storage Server X5-2 Extreme Flashサービス・マニュアルのPCIeカードのサービスに関する項(http://docs.oracle.com/cd/E41033_01/html/E55031/z40000f91037409.html#scrolltoc)を参照してください

7064884

ヒート・シンク、CPU

EBO

FRU

Oracle Exadata Storage Server X5-2 Extreme Flashサービス・マニュアルのプロセッサのサービスに関する項(http://docs.oracle.com/cd/E41033_01/html/E55031/goink.html#scrolltoc)を参照してください

7078070

DIMM、8GB、RDIMM、DDR4、2133

EBO

FRU

Oracle Exadata Storage Server X5-2 Extreme Flashサービス・マニュアルのDIMMのサービスに関する項(http://docs.oracle.com/cd/E41033_01/html/E55031/ceicjagi.html#scrolltoc)を参照してください

7090170

フラッシュ・ドライブ、MLC、OSA ID、USB、8GB

EBO

FRU

Oracle Exadata Storage Server X5-2 Extreme Flashサービス・マニュアルの内部USBフラッシュ・ドライブのサービスに関する項(http://docs.oracle.com/cd/E41033_01/html/E55031/ceiicfbd.html#scrolltoc)を参照してください

7093483

ASM、BP、Ultra-NVME

EBO

FRU

Oracle Exadata Storage Server X5-2 Extreme Flashサービス・マニュアルのストレージ・ドライブ・バックプレーンのサービスに関する項(http://docs.oracle.com/cd/E41033_01/html/E55031/goimw.html#scrolltoc)を参照してください

7093931

構成部品、SSD、1.6TB、eMLC-NAND、SFF-2.5インチNVMe 1.0、X4

HS

FRU

Oracle 1.6 TB NVMe SSDユーザー・ガイドのNVMeストレージ・ドライブのサービスに関する項(http://docs.oracle.com/cd/E54943_01/html/E54944/z40002cc9112.html#scrolltoc)を参照してください

7095102

CPU、E5-2630 V3、2.4G、85W、8コア、R-2 (SR206)

EBO

FRU

Oracle Exadata Storage Server X5-2 Extreme Flashサービス・マニュアルのプロセッサのサービスに関する項(http://docs.oracle.com/cd/E41033_01/html/E55031/goink.html#scrolltoc)を参照してください

7095801

ケーブル、NVME、HD41、RA-HD4i、STR、6xバンドル

EBO

FRU

Oracle Exadata Storage Server X5-2 Extreme Flashサービス・マニュアルのNVMeケーブルのサービスに関する項(http://docs.oracle.com/cd/E41033_01/html/E55031/goioo.html#scrolltoc)を参照してください

7096185

構成部品、インジケータ、左

EBO

FRU

Oracle Exadata Storage Server X5-2 Extreme Flashサービス・マニュアルの前面LED/USBインジケータ・モジュールのサービスに関する項(http://docs.oracle.com/cd/E41033_01/html/E55031/goipz.html#scrolltoc)を参照してください

7098504

ASM、MOBOトレイ

EBO

FRU

Oracle Exadata Storage Server X5-2 Extreme Flashサービス・マニュアルのマザーボード構成部品のサービスに関する項(http://docs.oracle.com/cd/E41033_01/html/E55031/goiqp.html#scrolltoc)を参照してください

関連トピック

- Oracle Exadata Storage Server Softwareユーザーズ・ガイド

- Exadata Storage Serverの物理ディスクの保守

A.7.5 Exadata Storage Server X4-2L Serverの部品

次の図に、Exadata Storage Server X4-2L Serverの前面図を示します。ハード・ドライブには、左下から始まり左から右へと番号が付けられます。下段のドライブの番号は0、1、2および3です。中段のドライブの番号は4、5、6および7です。上段のドライブの番号は8、9、10および11です。

図A-25 Exadata Storage Server X4-2L Serverの前面図

次の図に、Exadata Storage Server X4-2L Serverの背面図を示します。

図A-26 Exadata Storage Server X4-2L Serverの背面図

次の表に、Exadata Storage Server X4-2L Serverの交換部品を示します。

注意:

Premier Support of Systemsで保証されている場合、次の表のすべての交換部品はFRUとみなされます。

表A-48 Exadata Storage Server X4-2L Serverの交換部品

部品番号

説明

修理カテゴリ

基本保証の範囲

修理手順

371-5002

USBドライブ、4GB

EBO

CRU

Sun Server X4-2Lサービス・マニュアルの内部USBフラッシュ・ドライブのサービス(CRU)に関する項(http://docs.oracle.com/cd/E36974_01/html/E38145/ceiicfbd.html#scrolltoc)を参照してください

7014226

ケーブル、インターロック、125mm

EBO

FRU

Sun Server X4-2Lサービス・マニュアルのケーブルのサービス(FRU)に関する項(http://docs.oracle.com/cd/E36974_01/html/E38145/baecfjbc.html#scrolltoc)を参照してください

7014391

エクスパンダ構成部品、2U

EBO

FRU

Sun Server X4-2Lサービス・マニュアルのSASエクスパンダ・モジュールのサービス(CRU)に関する項(http://docs.oracle.com/cd/E36974_01/html/E38145/ceieidja.html#scrolltoc)を参照してください

7106353

4 TB 7200 RPM SAS HDD(ブラケット付属)

DBO

CRU

Sun Server X4-2Lサービス・マニュアルのストレージ・ドライブおよびリア・ドライブのサービス(CRU)に関する項(http://docs.oracle.com/cd/E36974_01/html/E38145/z40000091011460.html#scrolltoc)を参照してください

7017231

インジケータ構成部品、右

EBO

FRU

Sun Server X4-2Lサービス・マニュアルの前面LED/USBインジケータ・モジュールのサービス(FRU)に関する項(http://docs.oracle.com/cd/E36974_01/html/E38145/z40001d31014236.html#scrolltoc)を参照してください

7018701

DIMM、16GB、DDR3、1600、2Rx4、1.35V

EBO

CRU

Sun Server X4-2Lサービス・マニュアルのDIMMのサービス(CRU)に関する項(http://docs.oracle.com/cd/E36974_01/html/E38145/ceicjagi.html#scrolltoc)を参照してください

7020486

DIMM、8GB、DDR3、1600、2Rx4、1.35V

EBO

CRU

Sun Server X4-2Lサービス・マニュアルのDIMMのサービス(CRU)に関する項(http://docs.oracle.com/cd/E36974_01/html/E38145/ceicjagi.html#scrolltoc)を参照してください

7020776

ヒートシンク、CPU、2U、60 MM FIN、RoHS:YU

EBO

FRU

Sun Server X4-2Lサービス・マニュアルのプロセッサのサービス(FRU)に関する項(http://docs.oracle.com/cd/E36974_01/html/E38145/z40001d31037480.html#scrolltoc)を参照してください

7023515

ディスク・バックプレーン構成部品、2背面

EBO

FRU

Sun Server X4-2Lサービス・マニュアルの前面および背面ストレージ・ドライブ・バックプレーンのサービス(FRU)に関する項(http://docs.oracle.com/cd/E36974_01/html/E38145/z40007ac1419009.html#scrolltoc)を参照してください

7027479

ディスク・バックプレーン構成部品、4スロット3.5インチRoHS:Y

EBO

FRU

Sun Server X4-2Lサービス・マニュアルの前面および背面ストレージ・ドライブ・バックプレーンのサービス(FRU)に関する項(http://docs.oracle.com/cd/E36974_01/html/E38145/z40007ac1419009.html#scrolltoc)を参照してください

7044130

電源、A258、1000ワットAC入力

HS

CRU

1. CMAの背面左側を取り外し、後方に動かして右方向に取り外します。
サーバーの真後ろにあるケーブルを支える伸縮式クロス・メンバーを格納すると、両方の電源にアクセスできます。

2. Sun Server X4-2Lサービス・マニュアルの電源供給のサービス(CRU)に関する項(http://docs.oracle.com/cd/E36974_01/html/E38145/z40000091014153.html#scrolltoc)を参照してください

3. CMAを交換します。

7045042

ファン構成部品、2U、80 x 80、Ferrite、center_rotate

HS

CRU

Sun Server X4-2Lサービス・マニュアルのファン・モジュールのサービス(CRU)に関する項(http://docs.oracle.com/cd/E36974_01/html/E38145/z40000091014194.html#scrolltoc)を参照してください

7046442

構成部品、デュアル・ポート、QDR CX3、ホスト・チャネル・アダプタ

EBO

CRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。詳細は、「データベース・サーバーの電源切断」を参照してください。

2. Sun Server X4-2Lサービス・マニュアルのPCIeカードのサービス(CRU)に関する項(http://docs.oracle.com/cd/E36974_01/html/E38145/z40000f91037409.html#scrolltoc)を参照してください

3. 「InfiniBandネットワーク構成の確認」を参照してください。

4. 次のコマンドを使用して、新しいハードウェアがハードウェアおよびファームウェアの仕様を満たしていることを確認します。

/opt/oracle.SupportTools/CheckHWnFWprofile

7047503

構成部品、6GB、SAS RAIDディスクPCIe HBA、RoHS:Y

DBO

CRU

Sun Server X4-2Lサービス・マニュアルのストレージ・ドライブおよびリア・ドライブのサービス(CRU)に関する項(http://docs.oracle.com/cd/E36974_01/html/E38145/z40000091011460.html#scrolltoc)を参照してください

7048864

インジケータ構成部品、左、2U

EBO

FRU

Sun Server X4-2Lサービス・マニュアルの前面LED/USBインジケータ・モジュールのサービス(FRU)に関する項(http://docs.oracle.com/cd/E36974_01/html/E38145/z40001d31014236.html#scrolltoc)を参照してください

7057184

構成部品、バッテリ・キャリア・リモート

HS

FRU

データベース・サーバーのディスク・コントローラBBUの交換

7058152

構成部品、マザーボード、X4-2L

EBO

FRU

Sun Server X4-2Lサービス・マニュアルのマザーボード構成部品のサービス(FRU)に関する項(http://docs.oracle.com/cd/E36974_01/html/E38145/z40001d31037512.html#scrolltoc)を参照してください

7060020

ユニバーサル・アップグレード・リモート・バッテリ・キット

EBO

FRU

データベース・サーバーのディスク・コントローラBBUの交換

7069200

構成部品、800GB eMLCフラッシュPCIeカード

EBO

CRU

Sun Server X4-2Lサービス・マニュアルのPCIeカードのサービス(CRU)に関する項(http://docs.oracle.com/cd/E36974_01/html/E38145/z40000f91037409.html#scrolltoc)を参照してください

7069242

CPU、E5-2630 v2、6コア、2.6Ghz

EBO

FRU

Sun Server X4-2Lサービス・マニュアルのプロセッサのサービス(FRU)に関する項(http://docs.oracle.com/cd/E36974_01/html/E38145/z40001d31037480.html#scrolltoc)を参照してください

7070656

ディスク構成部品、1.2TB、SAS2

HS

CRU

Sun Server X4-2Lサービス・マニュアルのストレージ・ドライブおよびリア・ドライブのサービス(CRU)に関する項(http://docs.oracle.com/cd/E36974_01/html/E38145/z40000091011460.html#scrolltoc)を参照してください

関連トピック

- Oracle Exadata Storage Server Softwareユーザーズ・ガイド

A.7.6 Exadata Storage Server X3-2L Serverの部品

次の図に、Exadata Storage Server X3-2L Serverの前面図を示します。ハード・ドライブには、左下から始まり左から右へと番号が付けられます。下段のドライブの番号は0、1、2および3です。中段のドライブの番号は4、5、6および7です。上段のドライブの番号は8、9、10および11です。

図A-27 Exadata Storage Server X3-2L Serverの前面図

次の図に、Exadata Storage Server X3-2L Serverの背面図を示します。

図A-28 Exadata Storage Server X3-2L Serverの背面図

次の表に、Exadata Storage Server X3-2L Serverの交換部品を示します。

注意:

Premier Support of Systemsで保証されている場合、次の表のすべての交換部品はFRUとみなされます。

表A-49 Exadata Storage Server X3-2L Serverの交換部品

部品番号

説明

修理カテゴリ

基本保証の範囲

修理手順

150-3993

バッテリ、3V、390MAH、リチウム、コイン型

DBO

CRU

Sun Server X3-2L (旧称Sun Fire X4270 M3)サービス・マニュアルのバッテリのサービス(CRU)に関する項(http://docs.oracle.com/cd/E23393_01/html/E27229/z40000f91037456.html#scrolltoc)を参照してください

350-1719

構成部品、1U-2Uスナップイン、スリム・レール・ラック

DBO

CRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。詳細は、「データベース・サーバーの電源切断」を参照してください。

2. Sun Server X3-2L (旧称Sun Fire X4270 M3)サービス・マニュアルのツールレス・スライドレール・アセンブリの取付けに関する項(http://docs.oracle.com/cd/E23393_01/html/E27229/z40000671011466.html)を参照してください

371-4982

6Gb SAS RAID PCIバッテリ・モジュール(LiON)、BBU-08、RoHS:Y

DBO

CRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。詳細は、「データベース・サーバーの電源切断」を参照してください。

2. Sun Storage 6 Gb SAS PCIe RAID HBA, Internal HBAモデルSGX-SAS6-R-INT-ZおよびSG-SAS6-R-INT-Zインストレーション・ガイド(http://docs.oracle.com/cd/E19221-01/html/E22410/index.html)を参照してください

375-3696

InfiniBand(CX2)デュアルポートのCX2 4xQDR PCI-e

DBO

CRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。詳細は、「データベース・サーバーの電源切断」を参照してください。

2. Sun Server X3-2L (旧称Sun Fire X4270 M3)サービス・マニュアルのPCIeカードのサービス(CRU)に関する項(http://docs.oracle.com/cd/E23393_01/html/E27229/z40000f91037409.html)を参照してください

375-3701

構成部品、6GB SAS RAIDディスクPCIe HBA、RoHS:Y

DBO

CRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。詳細は、「データベース・サーバーの電源切断」を参照してください。

2. Sun Server X3-2L (旧称Sun Fire X4270 M3)サービス・マニュアルのPCIeカードのサービス(CRU)に関する項(http://docs.oracle.com/cd/E23393_01/html/E27229/z40000f91037409.html)を参照してください

3. 次のコマンドを使用して、新しいハードウェアがハードウェアおよびファームウェアの仕様を満たしていることを確認します。

/opt/oracle.SupportTools/CheckHWnFWprofile

注意: ディスクの交換時にサービス・マニュアルのコントローラ・コマンドを実行しないでください。

542-0428

ディスク構成部品、600GB、15K、SAS

HS

CRU

Sun Server X3-2L (旧称Sun Fire X4270 M3)サービス・マニュアルのストレージ・ドライブおよびリア・ドライブのサービス(CRU)に関する項(http://docs.oracle.com/cd/E23393_01/html/E27229/z40000091011460.html)を参照してください

7010036

3TB - 金具およびディスク付きの7200RPM 3.5インチSASディスク構成部品

HS

CRU

Sun Server X3-2L (旧称Sun Fire X4270 M3)サービス・マニュアルのストレージ・ドライブおよびリア・ドライブのサービス(CRU)に関する項(http://docs.oracle.com/cd/E23393_01/html/E27229/z40000091011460.html)を参照してください

注意: ディスクの交換時にサービス・マニュアルのコントローラ・コマンドを実行しないでください。

7014226

ケーブル、インターロック、125mm

EBO

FRU

Sun Server X3-2L (旧称Sun Fire X4270 M3)サービス・マニュアルのケーブルのサービス(FRU)に関する項(http://docs.oracle.com/cd/E23393_01/html/E27229/baecfjbc.html)を参照してください

7014391

エクスパンダ構成部品、2U

EBO

FRU

Sun Server X3-2L (旧称Sun Fire X4270 M3)サービス・マニュアルのSASエクスパンダ・モジュールのサービス(CRU)に関する項(http://docs.oracle.com/cd/E23393_01/html/E27229/ceieidja.html)を参照してください

7017223

インジケータ構成部品、左

EBO

FRU

Sun Server X3-2L (旧称Sun Fire X4270 M3)サービス・マニュアルの前面LED/USBインジケータ・モジュールのサービス(FRU)に関する項(http://docs.oracle.com/cd/E23393_01/html/E27229/z40001d31014236.html)を参照してください

7017231

インジケータ構成部品、右

EBO

FRU

Sun Server X3-2L (旧称Sun Fire X4270 M3)サービス・マニュアルの前面LED/USBインジケータ・モジュールのサービス(FRU)に関する項(http://docs.oracle.com/cd/E23393_01/html/E27229/z40001d31014236.html)を参照してください

7020486

DIMM、8GB、DDR3、1600、2Rx4、1.35V

EBO

CRU

Sun Server X3-2L (旧称Sun Fire X4270 M3)サービス・マニュアルのDIMMのサービス(CRU)に関する項(http://docs.oracle.com/cd/E23393_01/html/E27229/ceicjagi.html)を参照してください

7020776

ヒートシンク、CPU、2U、60 MM FIN、RoHS:YU

EBO

FRU

Sun Server X3-2L (旧称Sun Fire X4270 M3)サービス・マニュアルのSun Serverのプロセッサのサービス(FRU)に関する項(http://docs.oracle.com/cd/E23393_01/html/E27229/z40001d31037480.html)を参照してください

7023515

ディスク・バックプレーン構成部品、2背面

EBO

FRU

Sun Server X3-2L (旧称Sun Fire X4270 M3)サービス・マニュアルの前面および背面ストレージ・ドライブ・バックプレーンのサービス(FRU)に関する項(http://docs.oracle.com/cd/E23393_01/html/E27229/z40007ac1419009.html)を参照してください

7026993

構成部品、400GB eMLCフラッシュPCIEカード(LP金具付き)

EBO

CRU

Sun Server X3-2L (旧称Sun Fire X4270 M3)サービス・マニュアルのPCIeカードのサービス(CRU)に関する項(http://docs.oracle.com/cd/E23393_01/html/E27229/z40000f91037409.html)を参照してください

7027479

ディスク・バックプレーン構成部品、4スロット3.5インチRoHS:Y

EBO

FRU

Sun Server X3-2L (旧称Sun Fire X4270 M3)サービス・マニュアルのディスク・バックプレーンのサービス(FRU)に関する項(http://docs.oracle.com/cd/E22368_01/html/E27242/z40011771417642.html)を参照してください

7043559

CPU、E5-2630L、2.0 G、60 W、6 C

EBO

FRU

Sun Server X3-2L (旧称Sun Fire X4270 M3)サービス・マニュアルのSun Serverのプロセッサのサービス(FRU)に関する項(http://docs.oracle.com/cd/E23393_01/html/E27229/z40001d31037480.html)を参照してください

7044130

電源、A258、1000ワットAC入力

HS

CRU

1. CMAの背面左側を取り外し、後方に動かして右方向に取り外します。
サーバーの真後ろにあるケーブルを支える伸縮式クロス・メンバーを格納すると、両方の電源にアクセスできます。

2. Sun Server X3-2L (旧称Sun Fire X4270 M3)サービス・マニュアルの電源供給のサービス(CRU)に関する項(http://docs.oracle.com/cd/E23393_01/html/E27229/z40000091014153.html#scrolltoc)を参照してください

3. CMAを交換します。

7045042

ファン構成部品、2U、80 x 80、Ferrite、center_rotate

HS

CRU

Sun Server X3-2L (旧称Sun Fire X4270 M3)サービス・マニュアルのファン・モジュールのサービス(CRU)に関する項(http://docs.oracle.com/cd/E23393_01/html/E27229/z40000091014194.html)を参照してください

7047257

電源、AC、A258 1000ワット

HS

CRU

1. CMAの背面左側を取り外し、後方に動かして右方向に取り外します。
サーバーの真後ろにあるケーブルを支える伸縮式クロス・メンバーを格納すると、両方の電源にアクセスできます。

2. Sun Server X3-2L (旧称Sun Fire X4270 M3)サービス・マニュアルの電源供給のサービス(CRU)に関する項(http://docs.oracle.com/cd/E23393_01/html/E27229/z40000091014153.html#scrolltoc)を参照してください

3. CMAを交換します。

7049382

構成部品、マザーボード・トレイ

EBO

FRU

1. Sun Server X3-2L (旧称Sun Fire X4270 M3)サービス・マニュアルのマザーボード構成部品のサービス(FRU)に関する項(http://docs.oracle.com/cd/E23393_01/html/E27229/z40001d31037512.html#scrolltoc)を参照してください

2. サーバーの再起動後、[F2]を押します。

3. 起動順序を設定します。

7057184

構成部品、バッテリ・キャリア・リモート

HS

FRU

データベース・サーバーのディスク・コントローラBBUの交換

7060020

ユニバーサル・アップグレード・リモート・バッテリ・キット

EBO

FRU

データベース・サーバーのディスク・コントローラBBUの交換

関連トピック

- Oracle Exadata Storage Server Softwareユーザーズ・ガイド

A.7.7 Sun Fire X4270 M2 Serverを使用したExadata Storage Serverの部品

次の図に、Sun Fire X4270 M2 Serverを使用したExadata Storage Serverの前面図を示します。

図A-29 Sun Fire X4270 M2 Serverを使用したExadata Storage Serverの前面図

1. ハード・ディスク・ドライブ。上位ドライブは、左から右にHDD2、HDD5、HDD8およびHDD11です。中位ドライブは、左から右にHDD1、HDD4、HDD7およびHDD10です。下位ドライブは、左から右にHDD0、HDD3、HDD6およびHDD9です。

次の図に、Sun Fire X4270 M2 Serverを使用したExadata Storage Serverの背面図を示します。

図A-30 Sun Fire X4270 M2 Serverを使用したExadata Storage Serverの背面図

1. 電源。

2. InfiniBandホスト・チャネル・アダプタPCI Expressモジュール。

3. Sun Flash Accelerator F20 PCIeカード。

次の表に、Sun Fire X4270 M2 Serverを使用したExadata Storage Serverの交換部品を示します。

注意:

Premier Support of Systemsで保証されている場合、次の表のすべての交換部品はFRUとみなされます。

表A-50 Sun Fire X4270 M2 Serverを使用したExadata Storage Serverの交換部品

部品番号

説明

修理カテゴリ

基本保証の範囲

修理手順

150-3993

バッテリ、3V、390MAH、リチウム、コイン型

EBO

CRU

Sun Fire X4270 M2 Serverサービス・マニュアルのサーバー・バッテリのサービスに関する項(http://docs.oracle.com/cd/E19477-01/820-5830-13/motherboard.html#50634787_71528)を参照してください

300-2235

電源、A249、1200W、12V、2U、RoHS:Y

HS

CRU

1. CMAの背面左側を取り外し、後方に動かして右方向に取り外します。
サーバーの真後ろにあるケーブルを支える伸縮式クロス・メンバーを格納すると、両方の電源にアクセスできます。

2. Sun Fire X4270 M2 Serverサービス・マニュアルの電源供給のサービスに関する項(http://docs.oracle.com/cd/E19245-01/821-0488-12/hotswap.html#50516002_11706)を参照してください

3. CMAを交換します。

350-1502

ユニバーサル・ラック取付けキット

EBO

CRU

1. 現在システムを実行している場合、正常に停止する必要があります。詳細は、「Exadata Storage Serverのシャットダウン」を参照してください。

2. Sun Fire X4170、X4270およびX4275 Serverインストレーション・ガイドのサーバーのスライドレール・アセンブリへの取付けに関する項(http://docs.oracle.com/cd/E19477-01/820-5827-13/rack_install.html#50614309_74292)を参照してください

371-4415

24GBソリッド・ステート・フラッシュ・メモリー・モジュール、RoHS:Y

EBO

CRU

1. 「フラッシュ・ディスクの保守」を参照してください。

2. 現在サーバーを実行している場合、正常に停止する必要があります。詳細は、「Exadata Storage Serverのシャットダウン」を参照してください。

3. Sun Flash Accelerator F20 PCIe Cardユーザーズ・ガイドのFModのサービスに関する項(http://docs.oracle.com/cd/E19682-01/E21358/z40002401421318.html)を参照してください

371-4650

Energy Storage Module(ESM)5.5v 11F容量バックアップ電力モジュール、RoHS:Y

EBO

CRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。詳細は、「Exadata Storage Serverのシャットダウン」を参照してください。

2. Sun Flash Accelerator F20 PCIe Cardユーザーズ・ガイドのESMのサービスに関する項(http://docs.oracle.com/cd/E19682-01/E21358/z40002401422152.html)を参照してください

3. 次のコマンドを使用して、稼働時間の値をリセットします。

set clear_fault_action=true

371-4743

4GB USB 2.0フラッシュ・ドライブ、RoHS:Y

EBO

CRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。詳細は、「Exadata Storage Serverのシャットダウン」を参照してください。

2. Sun Fire X4270 M2 Serverサービス・マニュアルのPCIeカードのサービスに関する項(http://docs.oracle.com/cd/E19245-01/821-0488-12/motherboard.html#50516003_86021)を参照してください

3. 次の手順を実行します。
a.ラックからシステムを取り外します。

b.上部カバーを取り外します。

c.PCIeライザーを含むスロット2および5のF20 PCIeカードを取り外します。

d.PCIeスロット2のF20カードの横のUSBフラッシュ・ドライブを交換します。

e.手順aからdを逆に行い、システムをリストアします。

371-4887

2.26GHzのインテル・シックスコアXeon L5640、12MB、60W、RoHS:Y

EBO

FRU

Sun Fire X4270 M2 Serverサービス・マニュアルのCPUのサービスに関する項(http://docs.oracle.com/cd/E19245-01/821-0488-12/motherboard.html#50516003_23425)を参照してください

371-4965

LV DIMM、4GB、DDR3、1RX4、1333

EBO

CRU

Sun Fire X4270 M2 Serverサービス・マニュアルのメモリー・モジュールのサービス(DIMM)に関する項(http://docs.oracle.com/cd/E19245-01/821-0488-12/motherboard.html#50516003_71526)を参照してください

371-4982

6Gb SAS RAID PCIバッテリ・モジュール、RoHS:Y(LION)、BBU-08

EBO

CRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。詳細は、「Exadata Storage Serverのシャットダウン」を参照してください。

2. Sun Storage 6 Gb SAS PCIe RAID HBA, Internal HBAモデルSGX-SAS6-R-INT-ZおよびSG-SAS6-R-INT-Zインストレーション・ガイド(http://docs.oracle.com/cd/E19221-01/html/E22410/index.html)を参照してください

375-3696

InfiniBand(CX2)デュアルポートのCX2 4xQDR PCI-e

EBO

CRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。詳細は、「Exadata Storage Serverのシャットダウン」を参照してください。

2. Sun Fire X4270 M2 Serverサービス・マニュアルのPCIeカードのサービスに関する項(http://docs.oracle.com/cd/E19245-01/821-0488-12/motherboard.html#50516003_86021)を参照してください

375-3701

6GB SAS RAIDディスクPCIe HBA、RoHS:Y

EBO

CRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。詳細は、「Exadata Storage Serverのシャットダウン」を参照してください。

2. Sun Fire X4270 M2 Serverサービス・マニュアルのPCIeカードのサービスに関する項(http://docs.oracle.com/cd/E19245-01/821-0488-12/motherboard.html#50516003_86021)を参照してください

注意: ディスクの交換時にサービス・マニュアルのコントローラ・コマンドを実行しないでください。

511-1500

F20 PCIeフラッシュ・アクセラレータF20 SAS HBA、(移植なし)RoHS:Y

EBO

CRU

1. 「フラッシュ・ディスクの保守」を参照してください。

2. 現在サーバーを実行している場合、正常に停止する必要があります。詳細は、「Exadata Storage Serverのシャットダウン」を参照してください。

3. Sun Fire X4270 M2 Serverサービス・マニュアルのPCIeカードのサービスに関する項(http://docs.oracle.com/cd/E19245-01/821-0488-12/motherboard.html#50516003_86021)を参照してください

4. Sun Flash Accelerator F20 PCIe Cardユーザーズ・ガイドのカードのサービスに関する項(http://docs.oracle.com/cd/E19682-01/E21358/z40002cc9112.html#scrolltoc)を参照してください

530-3927

ケーブル、PDB、MB、1U+2U、リボン

EBO

CRU

Sun Fire X4270 M2 Serverサービス・マニュアルのケーブルのサービスに関する項(http://docs.oracle.com/cd/E19245-01/821-0488-12/infrastructure_x4270_M2.html#50515991_78576)を参照してください

530-4228

ケーブル、mini-SAS、36 POS LONG、LY、RoHS:Y

EBO

CRU

Sun Fire X4270 M2 Serverサービス・マニュアルのケーブルのサービスに関する項(http://docs.oracle.com/cd/E19245-01/821-0488-12/infrastructure_x4270_M2.html#50515991_78576)を参照してください

541-2075

Bus_bar、電力、1U+2U、RoHS:Y

EBO

FRU

Sun Fire X4270 M2 Serverサービス・マニュアルの分電盤のサービスに関する項(http://docs.oracle.com/cd/E19245-01/821-0488-12/infrastructure_x4270_M2.html#50515991_71558)を参照してください

541-2884

構成部品、ライザー、X8、X8、2U、PCI-E、RoHS:Y

EBO

CRU

Sun Fire X4270 M2 Serverサービス・マニュアルのPCIeライザーのサービスに関する項(http://docs.oracle.com/cd/E19245-01/821-0488-12/motherboard.html#50516003_53252)を参照してください

541-3310

グリース付きのXeon Heatsink、RoHS:Y 2U

EBO

FRU

Sun Fire X4270 M2 Serverサービス・マニュアルのCPUのサービスに関する項(http://docs.oracle.com/cd/E19245-01/821-0488-12/motherboard.html#50516003_23425)を参照してください

541-3356

x8/x8スイッチPCIeライザー構成部品、RoHS:Y、次の部品を含む

- x8/x8スイッチPCIeライザー

- 金具

EBO

CRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。詳細は、「Exadata Storage Serverのシャットダウン」を参照してください。

2. Sun Fire X4270 M2 Serverサービス・マニュアルのPCIeライザーのサービスに関する項(http://docs.oracle.com/cd/E19245-01/821-0488-12/motherboard.html#50516003_53252)を参照してください

541-4081

システム・ボード構成部品、RoHS:Y

EBO

FRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。詳細は、「Exadata Storage Serverのシャットダウン」を参照してください。

2. Sun Fire X4270 M2 Serverサービス・マニュアルのマザーボードのサービスに関する項(http://docs.oracle.com/cd/E19245-01/821-0488-12/motherboard.html#50516003_98526)を参照してください

541-4124

ファン・デッキ、Hyde、RoHS:Y

EBO

FRU

Sun Fire X4270 M2 Serverサービス・マニュアルのファン・ボードのサービスに関する項(http://docs.oracle.com/cd/E19245-01/821-0488-12/infrastructure_x4270_M2.html#50515991_71556)を参照してください

541-4222

構成部品、ファン、CR、2U、RoHS:Y

HS

CRU

Sun Fire X4270 M2 Serverサービス・マニュアルのファン・モジュールのサービスに関する項(http://docs.oracle.com/cd/E19245-01/821-0488-12/hotswap.html#50516002_28930)を参照してください

541-4223

分電盤、2U、RoHS:Y

EBO

FRU

Sun Fire X4270 M2 Serverサービス・マニュアルの分電盤のサービスに関する項(http://docs.oracle.com/cd/E19245-01/821-0488-12/infrastructure_x4270_M2.html#50515991_71558)を参照してください

541-4304

インジケータ、右、Hyde 12/24、ROHS:Y

EBO

FRU

Sun Fire X4270 M2 Serverサービス・マニュアルの前面パネルLEDモジュールのサービスに関する項(http://docs.oracle.com/cd/E19245-01/821-0488-12/infrastructure_x4270_M2.html#50515991_71563)を参照してください

541-4305

構成部品、ディスク、SAS2、XP_DC、Hyde、RoHS:Y

EBO

FRU

Sun Fire X4270 M2 Serverサービス・マニュアルのSASエクスパンダ・ボードのサービスに関する項(http://docs.oracle.com/cd/E19245-01/821-0488-12/infrastructure_x4270_M2.html#50515991_28246)を参照してください

541-4306

構成部品、コネクタ・ボード金具、Hyde

EBO

FRU

Sun Fire X4270 M2 Serverサービス・マニュアルのコネクタ・ボードのサービスに関する項(http://docs.oracle.com/cd/E19245-01/821-0488-12/infrastructure_x4270_M2.html#50515991_11100)を参照してください

541-4363

12スロットのディスク・バックプレーン、RoHS:Y

EBO

FRU

Sun Fire X4270 M2 Serverサービス・マニュアルのディスク・バックプレーンのサービスに関する項(http://docs.oracle.com/cd/E19245-01/821-0488-12/infrastructure_x4270_M2.html#50515991_71557)を参照してください

541-4371

インジケータ、左、Hyde 12/24、RoHS:Y

EBO

FRU

Sun Fire X4270 M2 Serverサービス・マニュアルの前面パネルLEDモジュールのサービスに関する項(http://docs.oracle.com/cd/E19245-01/821-0488-12/infrastructure_x4270_M2.html#50515991_71563)を参照してください

542-0166

600GB - 金具およびディスク付きの15000RPM SASディスク構成部品

HS

CRU

Sun Fire X4270 M2 Serverサービス・マニュアルのストレージ・ドライブおよびブート・ドライブのサービスに関する項(http://docs.oracle.com/cd/E19245-01/821-0488-12/hotswap.html#50516002_61628)を参照してください

注意: ディスクの交換時にサービス・マニュアルのコントローラ・コマンドを実行しないでください。

542-0247

2TB - 金具およびディスク付きの7200RPM 3.5インチSASディスク構成部品

HS

CRU

Sun Fire X4270 M2 Serverサービス・マニュアルのストレージ・ドライブおよびブート・ドライブのサービスに関する項(http://docs.oracle.com/cd/E19245-01/821-0488-12/hotswap.html#50516002_61628)を参照してください

注意: ディスクの交換時にサービス・マニュアルのコントローラ・コマンドを実行しないでください。

560-2952

ケーブル・キット、Hyde、RoHS:Y、次の部品を含む

- ディスク・バックプレーン電力ケーブル

- 24スロットのDBP電力ケーブル

- 12/24スロットのディスク・バックプレーン信号ケーブル

- ファン信号ケーブル

- ファン電力ケーブル

EBO

FRU

キットの個別の品目の記載事項を参照してください。

7010036

3TB - 金具およびディスク付きの7200RPM 3.5インチSASディスク構成部品

HS

CRU

Sun Fire X4270 M2 Serverサービス・マニュアルのストレージ・ドライブおよびブート・ドライブのサービスに関する項(http://docs.oracle.com/cd/E19245-01/821-0488-12/hotswap.html#50516002_61628)を参照してください

注意: ディスクの交換時にサービス・マニュアルのコントローラ・コマンドを実行しないでください。

A.7.8 Sun Fire X4275 Serverを使用したExadata Storage Serverの部品

次の図に、Sun Fire X4275 Serverの前面図を示します。

図A-31 Sun Fire X4275 Serverの前面図

1. ハード・ディスク・ドライブ。上位ドライブは、左から右にHDD2、HDD5、HDD8およびHDD11です。中位ドライブは、左から右にHDD1、HDD4、HDD7およびHDD10です。下位ドライブは、左から右にHDD0、HDD3、HDD6およびHDD9です。

次の図に、Sun Fire X4275 Serverの背面図を示します。

図A-32 Sun Fire X4275 Serverの背面図

次の表に、Sun Fire X4275 Serverを使用したExadata Storage Serverの交換部品を示します。

注意:

Premier Support of Systemsで保証されている場合、次の表のすべての交換部品はFRUとみなされます。

表A-51 Sun Fire X4275 Serverを使用したExadata Storage Serverの交換部品

部品番号

説明

修理カテゴリ

基本保証の範囲

修理手順

150-3993

Panasonic BR2032バッテリ、RoHS:Yのシステム・ボード

EBO

CRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。

2. Sun Fire X4170、X4270およびX4275 Serverサービス・マニュアルのバッテリのサービスに関する項(http://docs.oracle.com//cd/E19477-01/820-5830-13/motherboard.html#50634787_pgfId-1287052)を参照してください

300-1897

1050ワットの電力、RoHS:Y

HS

CRU

1. CMAの背面左側を取り外し、後方に動かして右方向に取り外します。
サーバーの真後ろにあるケーブルを支える伸縮式クロス・メンバーを格納すると、両方の電源にアクセスできます。

2. Sun Fire X4170、X4270およびX4275 Serverサービス・マニュアルの電源供給のサービスに関する項(http://docs.oracle.com/cd/E19477-01/820-5830-13/hotswap.html#50634786_pgfId-1098206)を参照してください

3. CMAを交換します。

350-1502

Exadata Storage Serverのねじを使用したスライド・レール・ラック取付けキット、RoHS:Y

EBO

FRU

1. 現在システムを実行している場合、正常に停止する必要があります。

2. Sun Fire X4170、X4270およびX4275 Serverインストレーション・ガイドのスライドレール・アセンブリのラックへの取付けに関する項(http://docs.oracle.com//cd/E19477-01/820-5827-13/rack_install.html#50614309_28682)を参照してください

371-4288

4GB Registered DDR3-1333 DIMM、RoHS:Y

EBO

CRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。

2. Sun Fire X4170、X4270およびX4275 Serverサービス・マニュアルのメモリー・モジュールのサービス(DIMM)に関する項(http://docs.oracle.com//cd/E19477-01/820-5830-13/motherboard.html#50634787_pgfId-1286176)を参照してください

371-4300

2.53GHzのクアッドコア・インテルXeon E5540、8MB、80W、RoHS:Y

EBO

FRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。

2. Sun Fire X4170、X4270およびX4275 Serverサービス・マニュアルのCPUのサービスに関する項(http://docs.oracle.com//cd/E19477-01/820-5830-13/motherboard.html#50634787_pgfId-1287119)を参照してください

371-4415

24GBソリッド・ステート・フラッシュ・メモリー・モジュール、RoHS:Y

EBO

CRU

1. 「フラッシュ・ディスクの保守」を参照してください。

2. 現在サーバーを実行している場合、正常に停止する必要があります。

3. Sun Flash Accelerator F20 PCIe Cardユーザーズ・ガイドのFModのサービスに関する項(http://docs.oracle.com/cd/E19682-01/E21358/z40002401421318.html)を参照してください

371-4650

Energy Storage Module(ESM)5.5v 11F容量バックアップ電力モジュール、RoHS:Y

EBO

CRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。

2. Sun Flash Accelerator F20 PCIe Cardユーザーズ・ガイドのESMのサービスに関する項(http://docs.oracle.com/cd/E19682-01/E21358/z40002401422152.html)を参照してください

3. 次のコマンドを使用して、稼働時間の値をリセットします。

set clear_fault_action=true

371-4743

4GB USB 2.0フラッシュ・ドライブ、RoHS:Y

EBO

CRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。

2. Sun Fire X4170、X4270およびX4275 Serverサービス・マニュアルのPCIeカードのサービスに関する項(http://docs.oracle.com//cd/E19477-01/820-5830-13/motherboard.html#50634787_pgfId-1287272)を参照してください

3. 次の手順を実行します。

a. ラックからシステムを取り外します。

b. 上部カバーを取り外します。

c. PCIeライザーを含むスロット2および5のF20 PCIeカードを取り外します。

d. PCIeスロット2の横のF20カードの下のUSBフラッシュ・ドライブを交換します。

e. 手順aからdを逆に行い、システムをリストアします。

371-4746

バッテリー・モジュール、RoHS:Yの6GB SAS RAIDディスクPCI、BBU-07

EBO

CRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。

2. Sun Storage 6 Gb SAS PCIe RAID HBA, Internal HBAモデルSGX-SAS6-R-INT-ZおよびSG-SAS6-R-INT-Zインストレーション・ガイド(http://docs.oracle.com/cd/E19221-01/html/E22410/index.html)を参照してください

375-3606

SunデュアルポートのQDR(40GB/s)InfiniBandホスト・チャネル・アダプタPCIe、RoHS:Y

EBO

CRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。

2. Sun Fire X4170、X4270およびX4275 Serverサービス・マニュアルのPCIeカードのサービスに関する項(http://docs.oracle.com//cd/E19477-01/820-5830-13/motherboard.html#50634787_pgfId-1287272)を参照してください

375-3644

6GB SAS RAIDディスクPCIe HBA、RoHS:Y

EBO

CRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。

2. Sun Fire X4170、X4270およびX4275 Serverサービス・マニュアルのPCIeカードのサービスに関する項(http://docs.oracle.com//cd/E19477-01/820-5830-13/motherboard.html#50634787_pgfId-1287272)を参照してください

511-1500

F20 PCIeフラッシュ・アクセラレータF20 SAS HBA、(移植なし)RoHS:Y

EBO

CRU

1. 「フラッシュ・ディスクの保守」を参照してください。

2. 現在サーバーを実行している場合、正常に停止する必要があります。

3. Sun Fire X4170、X4270およびX4275 Serverサービス・マニュアルのPCIeカードのサービスに関する項(http://docs.oracle.com//cd/E19477-01/820-5830-13/motherboard.html#50634787_pgfId-1287272)を参照してください

4. Sun Flash Accelerator F20 PCIe Cardユーザーズ・ガイドのカードのサービスに関する項(http://docs.oracle.com/cd/E19682-01/E21358/z40002cc9112.html#scrolltoc)を参照してください

530-3892

4x Mini SAS/SATAケーブル、SFF-8087、670mm、RoHS:Y

EBO

FRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。

2. Sun Fire X4170、X4270およびX4275 Serverサービス・マニュアルのケーブルのサービスに関する項(http://docs.oracle.com//cd/E19477-01/820-5830-13/infrastructure_x4170_x4270.html#50634783_pgfId-1287782)を参照してください

530-3927

システム・ボード・ケーブルの分電盤、RoHS:Y

EBO

FRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。

2. Sun Fire X4170、X4270およびX4275 Serverサービス・マニュアルの分電盤のサービスに関する項(http://docs.oracle.com//cd/E19477-01/820-5830-13/infrastructure_x4275.html#50634784_pgfId-1287132)を参照してください

530-4228

4x Mini SAS/SATAケーブル、SFF-8087、690mm、RoHS:Y

EBO

FRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。

2. Sun Fire X4170、X4270およびX4275 Serverサービス・マニュアルのケーブルのサービスに関する項(http://docs.oracle.com//cd/E19477-01/820-5830-13/infrastructure_x4170_x4270.html#50634783_pgfId-1287782)を参照してください

541-2073

分電盤/バス・バー構成部品、RoHS:Y、次の部品を含む

- 左側バス・バー

- 右側バス・バー

- 水平分電バー

- PDB信号ケーブル

EBO

FRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。

2. Sun Fire X4170、X4270およびX4275 Serverサービス・マニュアルの分電盤のサービスに関する項(http://docs.oracle.com//cd/E19477-01/820-5830-13/infrastructure_x4275.html#50634784_pgfId-1287132)を参照してください

541-2075

Bus_bar、電力、1U+2U、RoHS:Y

EBO

CRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。

2. Sun Fire X4170、X4270およびX4275 Serverサービス・マニュアルのマザーボード構成部品のサービスに関する項(http://docs.oracle.com//cd/E19477-01/820-5830-13/infrastructure_x4275.html#50634784_pgfId-1287132)を参照してください

541-2542

トレイ付きのシステム・ボード構成部品、RoHS:Y

EBO

FRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。

2. Sun Fire X4170、X4270およびX4275 Serverサービス・マニュアルのマザーボード構成部品のサービスに関する項(http://docs.oracle.com//cd/E19477-01/820-5830-13/infrastructure_x4275.html#50634784_pgfId-1287132)を参照してください

541-2884

次の部品を含むx8/x8 PCIeライザー構成部品

- x8/x8 PCIeライザー、RoHS:Y

- 金具、RoHS:Y

EBO

CRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。

2. Sun Fire X4170、X4270およびX4275 Serverサービス・マニュアルのPCIeライザーのサービスに関する項(http://docs.oracle.com//cd/E19477-01/820-5830-13/motherboard.html#50634787_pgfId-1286530)を参照してください

541-3290

金属の指ガード付きのCPUデュアル・ファン構成部品、60x38mm、2U、RoHS:Y

HS

CRU

Sun Fire X4170、X4270およびX4275 Serverサービス・マニュアルのファン・モジュールのサービスに関する項(http://docs.oracle.com//cd/E19477-01/820-5830-13/hotswap.html#50634786_pgfId-1100474)を参照してください

541-3310

グリース付きのXeon Heatsink、RoHS:Y

EBO

FRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。

2. Sun Fire X4170、X4270およびX4275 Serverサービス・マニュアルのCPUのサービスに関する項(http://docs.oracle.com//cd/E19477-01/820-5830-13/motherboard.html#50634787_pgfId-1287119)を参照してください

541-3356

x8/x8スイッチPCIeライザー構成部品、RoHS:Y、次の部品を含む

- x8/x8スイッチPCIeライザー

- 金具

EBO

CRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。

2. Sun Fire X4170、X4270およびX4275 Serverサービス・マニュアルのPCIeライザーのサービスに関する項(http://docs.oracle.com//cd/E19477-01/820-5830-13/motherboard.html#50634787_pgfId-1286530)を参照してください

541-3385

コネクタ・ボード構成部品、次の部品を含む

- 取付け金具、RoHS:Y

- コネクタ・ボード、RoHS:Y

EBO

FRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。

2. Sun Fire X4170、X4270およびX4275 Serverサービス・マニュアルのコネクタ・ブレイクアウト・ボードのサービスに関する項(http://docs.oracle.com//cd/E19477-01/820-5830-13/infrastructure_x4275.html#50634784_pgfId-1287220)を参照してください

541-3386

12スロットのディスク・バックプレーン、RoHS:Y

EBO

FRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。

2. Sun Fire X4170、X4270およびX4275 Serverサービス・マニュアルのストレージ・ドライブ・バックプレーンのサービスに関する項(http://docs.oracle.com//cd/E19477-01/820-5830-13/infrastructure_x4275.html#50634784_pgfId-1286916)を参照してください

541-3387

SASエクスパンダ・カード構成部品、RoHS:Y、次の部品を含む

- 金具、RoHS:Y

- SASエクスパンダ・ボード、RoHS:Y

EBO

FRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。

2. Sun Fire X4170、X4270およびX4275 Serverサービス・マニュアルのストレージ・ディスク・エクスパンダ・カードのサービスに関する項(http://docs.oracle.com//cd/E19477-01/820-5830-13/infrastructure_x4275.html#50634784_pgfId-1286818)を参照してください

541-3388

左側インジケータ構成部品、RoHS:Y、次の部品を含む

- 左側金具、RoHS:Y

- 左側LEDボード、RoHS:Y

- インジケータ・ケーブル、RoHS:Y

EBO

FRU

1. 現在システムを実行している場合、正常に停止する必要があります。

2. Sun Fire X4170、X4270およびX4275 Serverサービス・マニュアルのフロント・コントロール・パネルのライト・パイプ構成部品のサービスに関する項(http://docs.oracle.com//cd/E19477-01/820-5830-13/infrastructure_x4170_x4270.html#50634783_pgfId-1287263)を参照してください

541-3389

右側インジケータ構成部品、RoHS:Y、次の部品を含む

- 右側金具、RoHS:Y

- 右側LEDボード、RoHS:Y

- インジケータ・ケーブル、RoHS:Y

EBO

FRU

1. 現在システムを実行している場合、正常に停止する必要があります。

2. Sun Fire X4170、X4270およびX4275 Serverサービス・マニュアルのフロント・コントロール・パネルのライト・パイプ構成部品のサービスに関する項(http://docs.oracle.com//cd/E19477-01/820-5830-13/infrastructure_x4170_x4270.html#50634783_pgfId-1287263)を参照してください

541-3394

ファン・ボード構成部品、次の部品を含む

- 上部金具、RoHS:Y

- 下部金具、RoHS:Y

- ファン・ボード、RoHS:Y

EBO

FRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。

2. Sun Fire X4170、X4270およびX4275 Serverサービス・マニュアルのファン電源ボードのサービスに関する項(http://docs.oracle.com//cd/E19477-01/820-5830-13/infrastructure_x4170_x4270.html#50634783_pgfId-1286820)を参照してください

542-0166

金具およびディスク付きの600GB 15K RPM SASディスク構成部品、RoHS:Y

HS

CRU

1. 「Exadata Storage Serverの物理ディスクの保守」を参照してください。

2. Sun Fire X4170、X4270およびX4275 Serverサービス・マニュアルのストレージ・ドライブのサービスに関する項(http://docs.oracle.com//cd/E19477-01/820-5830-13/hotswap.html#50634786_pgfId-1093656)を参照してください

注意: ディスクの交換時にサービス・マニュアルのコントローラ・コマンドを実行しないでください。

542-0167

金具およびディスク付きの2TB 7.2K RPM 3.5インチSATAディスク構成部品、RoHS:Y

HS

CRU

Sun Fire X4170、X4270およびX4275 Serverサービス・マニュアルのストレージ・ドライブのサービスに関する項(http://docs.oracle.com//cd/E19477-01/820-5830-13/hotswap.html#50634786_pgfId-1093656)を参照してください

注意: ディスクの交換時にサービス・マニュアルのコントローラ・コマンドを実行しないでください。

560-2937

次の部品を含むExadata Storage Serverケーブル・キット

- 10pinバックプレーン電力ケーブル、RoHS:Y

- 20pinバックプレーン12Cケーブル、RoHS:Y

- 6pinファン電力ケーブル、RoHS:Y

- 16pin FAN 12Cケーブル、RoHS:Y

EBO

FRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。

2. Sun Fire X4170、X4270およびX4275 Serverサービス・マニュアルのコネクタ・ブレイクアウト・ボードのサービスに関する項(http://docs.oracle.com//cd/E19477-01/820-5830-13/infrastructure_x4275.html#50634784_pgfId-1287220)を参照してください+6

関連トピック

- Exadata Storage Serverのシャットダウン

A.8 InfiniBandスイッチの部品

次の表に、Oracle Exadataラックで使用されるInfiniBandスイッチの交換部品を示します。InfiniBandケーブルの詳細は、「Oracle Exadataラックのケーブルおよびケーブル・アクセサリ」を参照してください。

注意:

Premier Support of Systemsで保証されている場合、次の表のすべての交換部品はFRUとみなされます。

表A-52 InfiniBandスイッチの交換部品

部品番号

説明

修理カテゴリ

基本保証の範囲

修復方法

300-2143

760ワットの電力、RoHS:Y

HS

CRU

Sun Datacenter InfiniBand Switch 36ユーザーズ・ガイドの電源供給のサービスに関する項(http://docs.oracle.com/cd/E19197-01/835-0784-05/z400000e1496507.html)を参照してください

300-2299

760W AC入力電源

HS

CRU

Sun Datacenter InfiniBand Switch 36ユーザーズ・ガイドの電源供給のサービスに関する項(http://docs.oracle.com/cd/E19197-01/835-0784-05/z400000e1496507.html)を参照してください

350-1312

Sun Datacenter InfiniBand Switch 36のファン・モジュール、RoHS:Y

HS

CRU

Sun Datacenter InfiniBand Switch 36ユーザーズ・ガイドのファンのサービスに関する項(http://docs.oracle.com/cd/E19197-01/835-0784-05/z400000e1499116.html)を参照してください

350-1566

ファン・モジュール、1RU、Sanace、逆

HS

CRU

Sun Datacenter InfiniBand Switch 36ユーザーズ・ガイドのファンのサービスに関する項(http://docs.oracle.com/cd/E19197-01/835-0784-05/z400000e1499116.html)を参照してください

371-2210

CR2032 3vバッテリ、RoHS:Y

IR

CRU

Sun Datacenter InfiniBand Switch 36ユーザーズ・ガイドのバッテリのサービスに関する項(http://docs.oracle.com/cd/E19197-01/835-0784-05/cggefcei.html)を参照してください

541-3495

Sun Datacenter InfiniBand Switch 36、RoHS:YL

IR

CRU

1. 「障害が発生したSun Datacenter InfiniBand Switch 36スイッチの交換」を参照してください。

2. Sun Datacenter InfiniBand Switch 36ユーザーズ・ガイドのスイッチのサービスに関する項(http://docs.oracle.com/cd/E19197-01/835-0784-05/z40000609112.html)を参照してください

7052970

Sun Datacenter InfiniBand Switch 36、RoHS:YL

IR

CRU

1. 「障害が発生したSun Datacenter InfiniBand Switch 36スイッチの交換」を参照してください。

2. Sun Datacenter InfiniBand Switch 36ユーザーズ・ガイドのスイッチのサービスに関する項(http://docs.oracle.com/cd/E19197-01/835-0784-05/z40000609112.html)を参照してください

7061031

ファン・モジュール、1RU、Sanace、逆

HS

CRU

Sun Datacenter InfiniBand Switch 36ユーザーズ・ガイドのファンのサービスに関する項(http://docs.oracle.com/cd/E19197-01/835-0784-05/z400000e1499116.html)を参照してください

7065505

電源、AC、A247B、12V、760W、FW2022

HS

FRU

Sun Datacenter InfiniBand Switch 36ユーザーズ・ガイドの電源供給のサービスに関する項(http://docs.oracle.com/cd/E19197-01/835-0784-05/z400000e1496507.html)を参照してください

A.9 Ciscoスイッチの部品

次の表に、Oracle Exadataラックで使用されるCiscoスイッチの交換部品を示します。

注意:

Premier Support of Systemsで保証されている場合、次の表のすべての交換部品はFRUとみなされます。

表A-53 Ciscoスイッチの交換部品

部品番号

説明

修理カテゴリ

基本保証の範囲

修復方法

7023685

Cisco Catalyst 4948スイッチ、RoHS:Y

IR

CRU

『Catalyst 4948E and Catalyst 4948E-F Switch Installation Guide』のスイッチの取付けに関する項(http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst4900/4948E/installation/guide/4948E_ins/03instal.html)を参照してください

7024423

Cisco Catalyst 4948スイッチの電源、RoHS:Y

HS

CRU

『Catalyst 4948E and Catalyst 4948E-F Switch Installation Guide』の取外しおよび交換手順に関する項(http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst4900/4948E/installation/guide/4948E_ins/04frus.html)を参照してください

7024424

Cisco Catalyst 4948スイッチの冷却ファン、RoHS:Y

HS

CRU

『Catalyst 4948E and Catalyst 4948E-F Switch Installation Guide』のファン・トレイの取外しおよび取付けに関する項(http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst4900/4948E/installation/guide/4948E_ins/04frus.html)を参照してください

A.10 KVMスイッチおよびKMMトレイの部品

次の表に、KVMスイッチおよびKMMトレイの交換部品を示します。

注意:

Premier Support of Systemsで保証されている場合、次の表のすべての交換部品はFRUとみなされます。

表A-54 KVM/KMMの交換部品

部品番号

説明

修理カテゴリ

基本保証の範囲

修復方法

371-4778

構成部品、KMM、日本語キーボードおよびマウス・モジュール

IR

CRU

『Avocent MergePoint Unity Switch Installer/User Guide』(http://pcs.mktg.avocent.com/@@content/manual/590883501c.pdf)のインストールに関する章を参照してください

371-4779

Avocent MPU4032DAC-001 32ポートKVMスイッチ、RoHS:Y

IR

CRU

『Avocent MergePoint Unity Switch Installer/User Guide』(http://pcs.mktg.avocent.com/@@content/manual/590883501c.pdf)のインストールに関する章を参照してください

371-4780

米国キーボード付属のAvocent KMM引出し、RoHS:Y

IR

CRU

『Avocent MergePoint Unity Switch Installer/User Guide』(http://pcs.mktg.avocent.com/@@content/manual/590883501c.pdf)のインストールに関する章を参照してください

371-4781

Avocent(DSRIQ-USB)DB 15M - RJ45/USB KVMアダプタ、RoHS:Y

IR

CRU

『Avocent MergePoint Unity Switch Installer/User Guide』(http://pcs.mktg.avocent.com/@@content/manual/590883501c.pdf)のインストールに関する章を参照してください

A.11 配電ユニットの部品

次の表に、配電ユニット(PDU)の交換部品を示します。ケーブルおよび接続が複数ある場合は、配電ユニットの部品を交換する際にOracle Exadataラックのラックを停止することをお薦めします。

注意:

Premier Support of Systemsで保証されている場合、次の表のすべての交換部品はFRUとみなされます。

表A-55 配電ユニットの交換部品

部品番号

説明

修理カテゴリ

基本保証の範囲

修復方法

180-2379

13A/250V直角IEC 320 Sheet E - IEC 320 C13コード、1メートル、RoHS:Y

HS

CRU

適用なし

180-2380

13A/250V直角IEC 320 Sheet E - IEC 320 C13コード、2メートル、RoHS:Y

HS

CRU

適用なし

371-4000

3相PDU: 15kV、5Pin、IEC309 32A、5PIN 230/400V、3相IP44、国際、RoHS:Y

IR

FRU

「配電ユニットの交換」を参照してください

371-4001

3相PDU、24kVA、Oracle Exadata Database Machine X2-8フル・ラックの高電圧

IR

FRU

「配電ユニットの交換」を参照してください

371-4199

単相PDU、15kVA、3つの30A/250V 2極/3線式のNEMA L6-30Pプラグ、北米、RoHS:Y

IR

FRU

「配電ユニットの交換」を参照してください

371-4201

単相PDU、15kVA、3つの青色の32A/240Vの防沫構造の2極/3線式のIEC 60309プラグ、国際、RoHS:Y

IR

FRU

「配電ユニットの交換」を参照してください

371-5039

単相PDU: 22k VA Hubbell CS8265Cプラグ番号Xオプション

IR

FRU

「配電ユニットの交換」を参照してください

371-5040

単相PDU: 22k VA青色32A IEC 60309プラグ番号Xオプション

IR

FRU

「配電ユニットの交換」を参照してください。

371-4510

3相PDU、24kVA、Oracle Exadata Database Machine X2-8フル・ラックの低電圧

IR

FRU

「配電ユニットの交換」を参照してください

7051908

3相PDU: 15kVA、IEC309 60A、4PIN、250VAC、3相IP67、北米、RoHS:Y

IR

FRU

「配電ユニットの交換」を参照してください

7078660

3相PDU: 37kVA、RMII、低電圧

IR

FRU

「配電ユニットの交換」を参照してください

7078664

3相PDU: 37kVA、RMII、高電圧

IR

FRU

「配電ユニットの交換」を参照してください

A.12 Oracle Exadataラックのケーブルおよびケーブル・アクセサリ

次の表に、Oracle Exadataラックの交換ケーブルおよびケーブル・アクセサリを示します。

注意:

Premier Support of Systemsで保証されている場合、次の表のすべての交換部品はFRUとみなされます。

表A-56 Oracle Exadataラックの交換ケーブル

部品番号

説明

修理カテゴリ

基本保証の範囲

修復方法

350-1287

スリム・レール、CMA、Exadata Storage Serverの1U-2U

EBO

FRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。

2. Sun Fire X4170、X4270およびX4275 Serverインストレーション・マニュアルのケーブル管理アームの取付けに関する項(http://docs.oracle.com/cd/E19477-01/820-5827-13/rack_install.html#50614309_99582)を参照してください

350-1519

シリアル・ケーブル・キット、RoHS:Y、次の部品を含む

- USB - DB 9pin Mシリアル・ケーブル

- DB 9pin F - DB 9pin Fヌル・モデム・ケーブル

HS

CRU

Sun Datacenter InfiniBand Switch 36ユーザーズ・ガイド(http://docs.oracle.com/cd/E19197-01/835-0784-05/gentextid-226.html)を参照してください

350-1546

ケーブル管理アーム(CMA)1U、RoHS:Y、データベース・サーバー用

DBO

CRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。

2. Sun Fire X4170、X4270およびX4275 Serverインストレーション・マニュアルのケーブル管理アームの取付けに関する項(http://docs.oracle.com/cd/E19477-01/820-5827-13/rack_install.html#50614309_99582)を参照してください

350-1637

ラベル構成部品、EV2、双方向、アップグレード、ラベル

HS

CRU

『Oracle Exadata Database Machineシステム概要』を参照してください

350-1638

ラベル構成部品、EV2、3方向、サービス・アップグレード、ラベル

HS

CRU

『Oracle Exadata Database Machineシステム概要』を参照してください

350-1639

ラベル構成部品EV2、4方向、サービス・アップグレード、ラベル

HS

CRU

『Oracle Exadata Database Machineシステム概要』を参照してください

350-1640

ラベル構成部品EV2、5方向、サービス・アップグレード、ラベル

HS

CRU

『Oracle Exadata Database Machineシステム概要』を参照してください

350-1641

ラベル構成部品EV2、6方向、サービス・アップグレード、ラベル

HS

CRU

『Oracle Exadata Database Machineシステム概要』を参照してください

350-1642

ラベル構成部品EV2、7方向、サービス・アップグレード、ラベル

HS

CRU

『Oracle Exadata Database Machineシステム概要』を参照してください

350-1643

ラベル構成部品EV2、8方向、サービス・アップグレード、ラベル

HS

CRU

『Oracle Exadata Database Machineシステム概要』を参照してください

530-4445

QSFP InfiniBandパッシブ銅ケーブル、10 GbE、3m、RoHS:Y

HS

CRU

1. Sun Datacenter InfiniBand Switch 36ユーザーズ・ガイド(http://docs.oracle.com/cd/E19197-01/835-0784-05/gentextid-226.html)を参照してください

2. InfiniBandネットワーク構成を確認します。

注意: ケーブルの交換時に冗長性が失われます。

530-4446

QSFP InfiniBandパッシブ銅ケーブル、10 GbE、5m、RoHS:Y

HS

CRU

1. Sun Datacenter InfiniBand Switch 36ユーザーズ・ガイド(http://docs.oracle.com/cd/E19197-01/835-0784-05/gentextid-226.html)を参照してください

2. InfiniBandネットワーク構成を確認します。

注意: ケーブルの交換時に冗長性が失われます。

530-4403

4x QSFP QDR InfiniBand銅ケーブル、2m、RoHS:Y

HS

CRU

1. Sun Datacenter InfiniBand Switch 36ユーザーズ・ガイド(http://docs.oracle.com/cd/E19197-01/835-0784-05/gentextid-226.html)を参照してください

2. InfiniBandネットワーク構成を確認します。

注意: ケーブルの交換時に冗長性が失われます。

530-4404

4x QSFP QDR InfiniBand銅ケーブル、3m、RoHS:Y

HS

CRU

1. Sun Datacenter InfiniBand Switch 36ユーザーズ・ガイド(http://docs.oracle.com/cd/E19197-01/835-0784-05/gentextid-226.html)を参照してください

2. InfiniBandネットワーク構成を確認します。

530-4415

4x QSFP QDR InfiniBand銅ケーブル、5m、RoHS:Y

HS

CRU

1. Sun Datacenter InfiniBand Switch 36ユーザーズ・ガイド(http://docs.oracle.com/cd/E19197-01/835-0784-05/gentextid-226.html)を参照してください

2. InfiniBandネットワーク構成を確認します。

530-4432

イーサネット・ケーブル、Cat 5/5E、RJ45 - RJ45、7フィート、青、RoHS:Y

HS

CRU

『Catalyst 4948E and Catalyst 4948E-F Switch Installation Guide』(http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst4900/4948E/installation/guide/4948E_ins.html)を参照してください

530-4433

イーサネット・ケーブル、Cat 5/5E、RJ45 - RJ45、10フィート、赤、RoHS:Y

HS

CRU

『Catalyst 4948E and Catalyst 4948E-F Switch Installation Guide』(http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst4900/4948E/installation/guide/4948E_ins.html)を参照してください

530-4434

イーサネット・ケーブル、Cat 5/5E、RJ45 - RJ45、7フィート、赤、RoHS:Y

HS

CRU

『Catalyst 4948E and Catalyst 4948E-F Switch Installation Guide』(http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst4900/4948E/installation/guide/4948E_ins.html)を参照してください

530-4435

イーサネット・ケーブル、Cat 5/5E、RJ45 - RJ45、10フィート、黒、RoHS:Y

HS

CRU

『Catalyst 4948E and Catalyst 4948E-F Switch Installation Guide』(http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst4900/4948E/installation/guide/4948E_ins.html)を参照してください

530-4436

イーサネット・ケーブル、Cat 5/5E、RJ45 - RJ45、7フィート、黒、RoHS:Y

HS

CRU

『Catalyst 4948E and Catalyst 4948E-F Switch Installation Guide』(http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst4900/4948E/installation/guide/4948E_ins.html)を参照してください

530-4437

イーサネット・ケーブル、Cat 5/5E、RJ45 - RJ45、7フィート、オレンジ、RoHS:Y

HS

CRU

『Catalyst 4948E and Catalyst 4948E-F Switch Installation Guide』(http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst4900/4948E/installation/guide/4948E_ins.html)を参照してください

530-4438

イーサネット・ケーブル、Cat 5/5E、RJ45 - RJ45、10フィート、黒、RoHS:Y

HS

CRU

『Catalyst 4948E and Catalyst 4948E-F Switch Installation Guide』(http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst4900/4948E/installation/guide/4948E_ins.html)を参照してください

530-4444

QSFP - QSFPパッシブ銅ケーブル、1m、RoHS:Y

HS

CRU

1. Sun Datacenter InfiniBand Switch 36ユーザーズ・ガイド(http://docs.oracle.com/cd/E19197-01/835-0784-05/gentextid-226.html)を参照してください

2. InfiniBandネットワーク構成を確認します。

530-4445

QSFPパッシブ銅ケーブル、10GE、3m

HS

CRU

1. Sun Datacenter InfiniBand Switch 36ユーザーズ・ガイド(http://docs.oracle.com/cd/E19197-01/835-0784-05/gentextid-226.html)を参照してください

2. InfiniBandネットワーク構成を確認します。

530-4502

イーサネット・ケーブル、Cat 5/5E、10フィート、青、RoHS:Y

HS

CRU

『Catalyst 4948E and Catalyst 4948E-F Switch Installation Guide』(http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst4900/4948E/installation/guide/4948E_ins.html)を参照してください

7015400

電源ケーブル、ジャンパ、SR2、2m C14RA、10A、C13

HS

CRU

「配電ユニットの交換」を参照してください。

7042273

スリム・レール、ケーブル管理アーム、Exadata Storage Serverの1U-2U

EBO

FRU

1. 現在サーバーを実行している場合、正常に停止する必要があります。

2. Sun Fire X4170、X4270およびX4275 Serverインストレーション・マニュアルのケーブル管理アームの取付けに関する項(http://docs.oracle.com/cd/E19477-01/820-5827-13/rack_install.html#50614309_99582)を参照してください

7102869

パッシブ・ファイバInfiniBandケーブル、10m、RoHS:Y

HS

CRU

1. Sun Datacenter InfiniBand Switch 36ユーザーズ・ガイド(http://docs.oracle.com/cd/E19197-01/835-0784-05/gentextid-226.html)を参照してください

2. InfiniBandネットワーク構成を確認します。

注意: パッシブ・ファイバ・ケーブルごとにQSFP SRトランシーバ(部品番号X2124A-N)を2つ購入してください。

7102870

パッシブ・ファイバInfiniBandケーブル、20m、RoHS:Y

HS

CRU

1. Sun Datacenter InfiniBand Switch 36ユーザーズ・ガイド(http://docs.oracle.com/cd/E19197-01/835-0784-05/gentextid-226.html)を参照してください

2. InfiniBandネットワーク構成を確認します。

注意: パッシブ・ファイバ・ケーブルごとにQSFP SRトランシーバ(部品番号X2124A-N)を2つ購入してください。

7102871

パッシブ・ファイバInfiniBandケーブル、50m、RoHS:Y

HS

CRU

1. Sun Datacenter InfiniBand Switch 36ユーザーズ・ガイド(http://docs.oracle.com/cd/E19197-01/835-0784-05/gentextid-226.html)を参照してください

2. InfiniBandネットワーク構成を確認します。

注意: パッシブ・ファイバ・ケーブルごとにQSFP SRトランシーバ(部品番号X2124A-N)を2つ購入してください。

関連トピック

- Oracle Exadataラックの電源の投入および切断

- InfiniBandネットワーク構成の確認

B ExaCLIエラー・メッセージ

EXA-xxxxxエラーは、ExaCLIツールでのみ生成されます。

EXA-30000: {0}でMSに接続できません。エラー: {1}。

原因: ExaCLIは要求されたセルに接続できませんでした。

処置: コマンド・ライン上のセル名が正しく、セルが現在のマシンからアクセス可能であり、管理サーバー(MS)サービスが実行中であることを確認してください。

関連項目:

ExaCLIの構文

EXA-30002: 格納した証明書ファイルの読取り中にエラーが発生しました: {0}。

原因: セルのIDを受け付けた場合に記録される、指定されたファイルを読み取ることができません。

処置: ホーム・ディレクトリ、$HOME/.exacliディレクトリおよびこのディレクトリのすべてのファイルの読取り/書込み権限があることを確認してください。これで問題が解決しない場合は、エラー・メッセージに指定されたファイルを削除してください。ExaCLIにより、セルのIDを再確認するように求められます。

EXA-30003: デフォルトのトラストマネージャまたはキーストアを作成できません: {0}。

原因: 内部エラーが発生しました。

処置: Oracleサポート・サービスに問い合せてください。

EXA-30004: キーストアから証明書を取得中に内部エラーが発生しました: {0}。

原因: 内部エラーが発生しました。

処置: Oracleサポート・サービスに問い合せてください。

EXA-30005: 証明書が見つかりません。

原因: 内部エラーが発生しました。

処置: Oracleサポート・サービスに問い合せてください。

EXA-30006: URL {0}からデータを取得中にエラーが発生しました。

原因: ExaCLIは、カスタム証明書をアップロードするとき、指定されたURLからデータを収集できなかった可能性があります。

処置: URLが正しく、到達可能であることを確認してください。

EXA-30007: 証明書の作成中に内部エラーが発生しました: {0}。

原因: 内部エラーが発生しました。

処置: Oracleサポート・サービスに問い合せてください。

EXA-30008: セル名が指定されていません。"-c <cellname>"オプションを使用して接続するセルを指定してください。

原因: コマンド・ライン上にExaCLIの接続先セル名が指定されていません。

処置: コマンドで-c <cellname>オプションを使用してください。

関連項目:

ExaCLIの構文

EXA-30009: キーボード{0}から入力を取得できません。

原因: 内部エラーが発生しました。

処置: Oracleサポート・サービスに問い合せてください。

EXA-30010: cookiejar {0}に予期しない内容があります。

原因: ユーザー認証情報を保存するためのcookiejarファイル($HOME/.exacli/cookiejar)が破損しました。

処置: $HOME/.exacli/cookiejarを削除してください。すべてのセルにログインするためにパスワードを再入力する必要があります。

EXA-30011: securityPrivKey、securityPubKey (および必要に応じてsecurityPrivKeyPW)属性を同時に指定する必要があります。

原因: カスタム・セキュリティ認証のアップロードのために必要なすべての情報が提供されていません。

処置: セルへのカスタム・セキュリティのアップロード時に、秘密鍵(securityPrivKey属性)と公開鍵(securityPubKey属性)に個別のURLを指定する必要があります。

関連項目:

CA認証済セキュリティ証明書の使用

EXA-30012: cookiejar {0}を保存できません。

原因: ExaCLIは、指定されたcookie-jarファイルにCookieを保存できませんでした。

処置: cookie-jarファイルおよびcookie-jarファイルの親ディレクトリへの書込み権限があるかどうかを確認してください。

EXA-30013: ログインできません。不適切なユーザー名またはパスワードです。

原因: ユーザー名とパスワードの組合せが管理サーバー(MS)によって認識されませんでした。

処置: ユーザー名がMSに認識されており、パスワードが正しいことを確認してください。このユーザーは、オペレーティング・システム・ユーザーとは異なります。

関連項目:

ユーザー管理

EXA-30014: URLの作成中に内部エラーが発生しました。

原因: 内部エラーが発生しました。

処置: Oracleサポート・サービスに問い合せてください。

EXA-30015: cookieファイルを読み取れませんでした: {0}。

原因: ExaCLIは、指定されたcookie-jarファイルのCookieを読み取れませんでした。

処置: 指定されたファイルの読取り権限があることを確認してください。

EXA-30016: この接続は安全ではありません。セル{0}に安全に接続するようExaCLIを要求しました。{0}のアイデンティティを検証できません。

原因: セルにはCA認証のアイデンティティがなく、以前にセルからの自己認証のアイデンティティを受け入れていません。

処置: デフォルトでは、セル・ソフトウェアは自己認証のアイデンティティを提供します。続行するには、このアイデンティティを受け入れる必要があります。または、CA認証のアイデンティティをセルにアップロードできます。

関連項目:

証明書

EXA-30018: 新しいサーバー証明書を格納できません: {0}

原因: ExaCLIは、同じアイデンティティ証明書を再度受け入れる必要がないように、セルが提供する証明書をファイルに格納できませんでした。

処置: ホーム・ディレクトリ、$HOME/.exacliディレクトリおよびそのすべてのファイルに対する読取り/書込み権限があることを確認してください。

EXA-30019: サーバーを認識できません。終了します。

原因: セルが提供する自己認証のアイデンティティを受け入れませんでした。

処置: デフォルトでは、セル・ソフトウェアは自己認証のアイデンティティを提供します。続行するには、このアイデンティティを受け入れる必要があります。または、CA認証のアイデンティティをセルにアップロードできます。

関連項目:

証明書

EXA-30020: ユーザー名が-lオプションに指定されていないか、user@cellnameの形式ではありません。

原因: -lオプションに値を指定していないか、"-c user@cellname"のかわりに"-c @cellname"を入力しました。

処置: コマンド・ライン上に"-l user"または"-c user@cellname"のいずれかを使用してユーザー名を指定してください。両方を省略した場合、ユーザー名を求めるメッセージが表示されます。

関連項目:

ExaCLIの構文

EXA-30021: -lとuser@cellを使用してログイン名が2回指定されました。

原因: "-l user"と"-c user@cellname"の両方を使用して、コマンド・ラインにユーザー名が2回指定されています。

処置: コマンド・ライン上に"-l user"または"-c user@cellname"のどちらか1つのみを使用してユーザー名を指定してください。両方を省略した場合、ユーザー名を求めるメッセージが表示されます。

関連項目:

ExaCLIの構文

EXA-30022: -cert_proxyオプションにプロキシが指定されていません(証明書を取得するためのHTTPプロキシ)。

原因: --cert-proxyオプションの値がありません。

処置: 必要に応じて、ユーザー提供のURLにアクセスするために、--cert-proxyオプションの値を指定してください(たとえば、HTTPを使用してカスタム証明書をアップロードする場合)。

例: --cert-proxy proxy.example.com:80

EXA-30023: 続行できません。自己署名されていない証明書を検証できませんでした: {0}。中間証明書をダウンロードする必要があり、HTTPプロキシが必要な場合は、-cert_proxy <proxy>[:<port>]オプションを指定してください。

原因: セルが提供したCA認証のアイデンティティを検証できませんでした。これは、アイデンティティ証明書が本質的に無効である場合に発生することがあります。一部のCA認証のアイデンティティは、検証のために中間証明書をダウンロードする必要があります。ExaCLIがインターネットにアクセスできない場合、このような証明書は、実際に有効な場合でも、このエラーを生じます。

処置: ExaCLIがインターネットにアクセスするためにHTTPプロキシによる構成が必要な場合は、コマンド・ラインで"--cert-proxy <proxy>[:<port>]"オプションを使用してください。中間証明書は、ExaCLIにより自動的にダウンロードおよび検証されます。ExaCLIが引き続き、セル・アイデンティティを有効であると認識しない場合は、CellCLIを使用してこのコマンドを実行します:

alter cell securityCert="default"

これにより、デフォルトの自己認証のアイデンティティに戻ります。ExaCLIを使用して、カスタム・アイデンティティを再度アップロードする必要があります。

EXA-30024: 無効なオプションです: {0}。

原因: コマンドラインに指定されたオプションは認識されませんでした。

処置: 「ExaCLIの構文」に記載されているExaCLIの使用方法を参照してください。

EXA-30025: 証明書が無効であるため、アップロードできませんでした。

原因: セルにカスタム・アイデンティティをアップロードするとき、ExaCLIはURLに指定されたデータを有効な証明書として解析できませんでした。

処置: URLが正しい証明書ファイルを指していることを確認してください。証明書がPEM形式である場合、"-----BEGIN CERTIFICATE-----"で始まり、"-----END CERTIFICATE-----"で終わる必要があります。

関連項目:

証明書

EXA-30026: 自己認証の証明書は許可されないため、アップロードできませんでした。

原因: 自己認証のアイデンティティをセルのアイデンティティとしてアップロードすることはできません。セルには、デフォルトで自己認証のアイデンティティがあります。

処置: セルにCA認証のアイデンティティをアップロードするか、次のコマンドを使用してセルのデフォルトの自己認証のアイデンティティに戻します。

alter cell securityCert="default"

関連項目:

証明書

EXA-30027: 認証局によって署名された証明書を検証できなかったため、アップロードできませんでした。

原因: ExaCLIは、CA認証のセキュリティ証明書を検証できませんでした。

処置: CA認証のセキュリティ証明書の有効期限が切れていないこと、および失効していないことを確認してください。一部のCA認証の証明書は、検証のために中間証明書をダウンロードする必要があります。ExaCLIがインターネットにアクセスできない場合、このような証明書は、実際に有効な場合でも、このエラーを生じます。ExaCLIがインターネットにアクセスするためにHTTPプロキシによる構成が必要な場合は、コマンド・ラインで"--cert-proxy <proxy>[:<port>]"オプションを使用してください。中間証明書は、ExaCLIにより自動的にダウンロードおよび検証されます。

関連項目:

証明書

EXA-30028: 格納されたCookieを使用してログインできません。

原因: 以前に--cookie-jarオプションを使用してログインし、認証トークン(Cookie)が保存されています。しかし、現在セルではこのCookieを受け入れていません。

処置: パスワードを再入力してください。

関連項目:

- ExaCLIの構文

- 認証

EXA-30029: ファイル{0}に対して、所有者のみに読取り/書込みアクセスを許可するように権限を変更することはできません。

原因: ExaCLIによって作成されたすべてのファイルは、セキュリティ上の理由から、ファイル所有者のみ読取り/書込み可能に設定されています。しかし、ExaCLIは指定されたファイルの権限を変更できませんでした。

処置: 指定されたファイルが、ファイル所有者のみ読取り/書込み可能であることを確認してください。

EXA-30030: 必要なバージョンのJavaが見つかりませんでした。ExaCLIはJava 1.7.0_80以上が必要です。

原因: ExaCLIではJava 1.7.0_80以上が必要ですが、PATH変数とJAVA_HOME変数のどちらにも見つかりませんでした。

処置: Java 1.7.0_80以上がインストールされていること、およびjavaバイナリの場所がPATH環境変数であることを確認し、このバージョンのJavaの場所にJAVA_HOMEを設定します。

EXA-30031: コマンドとバッチ・ファイルの両方を指定することはできません。

原因: -eオプションにコマンドと@batchfileの両方を指定しようとしました。

処置: "-e command"または"-e @batchfile"のいずれか一方を指定してください。

関連項目:

ExaCLIの構文

EXA-30032: バッチ・ファイルは、他のバッチ・ファイルを介して、自身を呼び出している可能性があります。

原因: バッチ・ファイルには、同じバッチ・ファイルの呼出しが含まれています。次に例を示します。

$ cat batch_file
@batch_file

処置: バッチ・ファイルからすべての自己参照と循環依存を削除してください。

関連項目:

ExaCLIの構文

CELL-40001: DESCRIBEコマンドには1つのオブジェクト・タイプ・パラメータが必要です。

原因: DESCRIBEコマンドが値なしで発行されました。

処置: DESCRIBEの後に有効なMSオブジェクトが必要です(例: DESCRIBE CELL、DESCRIBE CELLDISK)。

関連項目:

Oracle Exadata Storage Server Softwareユーザーズ・ガイド

CELL-40003: DESCRIBEコマンドで無効なオブジェクト・タイプが指定されました: {0}。

原因: DESCRIBEコマンドの引数が有効なMSオブジェクトではありません。

処置: DESCRIBEの後に有効なMSオブジェクトが必要です(例: DESCRIBE CELL、DESCRIBE CELLDISK)。

関連項目:

Oracle Exadata Storage Server Softwareユーザーズ・ガイド

C Oracle Exadata Database MachineおよびOracle Exadataラックのエラー・メッセージ

この付録には、Oracle Exadata Database MachineおよびOracle Exadataラックのハードウェア・メッセージが含まれています。この付録の内容は次のとおりです。

- 「汎用アラート・メッセージ: HALRT-00001 - HALRT-00500」

- 「温度アラート・メッセージ: HALRT-00513 - HALRT-00600」

- 「ファン・アラート・メッセージ: HALRT-00616 - HALRT-00700」

- 「電源/電力変換装置アラート・メッセージ: HALRT-00717 - HALRT-00800」

- 「ネットワーク・アラート・メッセージ: HALRT-00912 - HALRT-01000」

- 「ハード・ディスクおよびフラッシュ・ディスク・アラート・メッセージ: HALRT-01015 - HALRT-01200」

- 「アクセラレータ/コントローラ・アラート・メッセージ: HALRT-01209 - HALRT-01300」

- 「電圧アラート・メッセージ: HALRT-01301 - HALRT-01400」

- 「物理ディスク・アラート・メッセージ: HALRT-01401 - HALRT-01500」

- Exadata Storage Serverの自動サービス・リクエスト・アラート・メッセージ: HALRT-02001 - HALRT-02013

- 「HDDコントローラのバッテリ・アラート・メッセージ: HALRT-02101 - HALRT-02200」

- USB警告メッセージ: HALRT-02401からHALRT-02404

- 「アラート・メッセージの汎用処理: HALRT-10001 - HALRT-10500」

- 「アラート・メッセージの汎用処理: HALRT-10503 - HALRT-11000」

- 「アラート・メッセージの汎用処理: HALRT-11001 - HALRT-11100」

- Oracle Exadata Database Machineコマンドライン・インタフェース・エラー・メッセージ

- Oracleサポート・サービスへの連絡

注意:

読みやすさを考慮して、Oracle Exadata Database MachineとOracle Exadata Storage拡張ラックの両方に言及する場合、「Oracle Exadataラック」という名前を使用します。

関連項目:

Oracle Database SNMPエラー・メッセージの詳細は、『Oracle Databaseエラー・メッセージ』リファレンスを参照してください。

C.1 汎用アラート・メッセージ: HALRT-00001 - HALRT-00500

これらのアラート・メッセージの範囲は、HALRT-00001からHALRT-00500です。

HALRT-00002: シャーシ侵入 - 物理セキュリティ侵害

原因: シャーシの物理セキュリティ侵害が検出されました。

処置: 情報アラートなので、ユーザー処理はありません。

HALRT-00003: シャーシ侵入(物理セキュリティ侵害)イベントがクリアされました。

原因: シャーシの物理セキュリティ侵害のクリア・イベントが検出されました。

処置: 情報アラートなので、ユーザー処理はありません。

HALRT-00004: CPU内部エラー

原因: CPU内部エラーが検出されました。

処置: システムを停止して、CPUエラーを調べてください。

HALRT-00005: CPU内部エラーがクリアされました。

原因: CPU内部エラーのクリア・イベントが検出されました。

処置: 情報アラートなので、ユーザー処理はありません。

HALRT-00006: CPU構成エラー

原因: CPU構成エラーが検出されました。

処置: システムを停止して、CPUエラーを調べてください。

HALRT-00007: CPU構成エラーがクリアされました。

原因: CPU構成エラーのクリア・イベントが検出されました。

処置: 情報アラートなので、ユーザー処理はありません。

HALRT-00008: CPUが存在します(プロセッサの存在が検出されました)。

原因: 新しいCPUのプレゼンス・イベントが検出されました。

処置: システムを停止して、CPUエラーを調べてください。

HALRT-00009: CPUが存在しません(プロセッサが存在しません)。

原因: CPUが存在しないことが検出されました。

処置: 情報アラートなので、ユーザー処理はありません。

HALRT-00010: システム・イベント・ログ(SEL)が満杯です(ロギング無効)。

原因: システム・イベント・ログが満杯であることが検出されました。

処置: 情報アラートなので、ユーザー処理はありません。

HALRT-00011: ASR (自動システム・リカバリ)のタイマーが切れました

原因: 自動システム・リカバリのタイマーが切れました。

処置: 情報アラートなので、ユーザー処理はありません。

HALRT-00012: ASR (自動システム・リカバリ)がリセットされました

原因: 自動システム・リカバリがリセットされました。

処置: 情報アラートなので、ユーザー処理はありません。

HALRT-00013: ASR (自動システム・リカバリ) の電源が切断されました

原因: 自動システム・リカバリの電源が切断されました。

処置: 情報アラートなので、ユーザー処理はありません。

HALRT-00014: ASR (自動システム・リカバリ)の電源が切断後ただちに投入されました

原因: 自動システム・リカバリの電源が入れ直されました。

処置: 情報アラートなので、ユーザー処理はありません。

HALRT-00015: {0}センサーのしきい値の状態変更: センサーのコンポーネント名: {1} センサーの状態: {2} センサーのしきい値タイプ: {3} センサーのしきい値の重大度: {4} センサーの値: {5} センサーのしきい値: {6} センサーの追加情報: {7}

原因: センサーのしきい値の状態が変更されました。

処置: センサーの状態の変更またはエラーを確認します。予想外でクリアされない場合は、Oracleサポート・サービスに問い合せてください。

HALRT-00016: {0}コンポーネントが障害の原因である可能性があります。コンポーネント名: {1} 障害クラス: {2} 障害の確度: {3} 障害メッセージ: {4} トラップの追加情報: {5}

レベル
クリティカル

原因: コンポーネントで障害が発生した可能性があります。

処置: アラート・メッセージの追加情報を参照してください。

HALRT-00017: {0}コンポーネントの障害はクリアされました。コンポーネント名: {1} トラップの追加情報: {2}

レベル
クリア

原因: コンポーネントの障害がクリアされました。

処置: 情報アラートなので、ユーザー処理はありません。

HALRT-00018: {0}センサーによりエラーが検出されました。コンポーネント名: {1} トラップの追加情報: {2}

原因: センサーによってエラーが検出されました。

処置: センサーの状態の変更またはエラーを確認します。予想外でクリアされない場合は、Oracleサポート・サービスに問い合せてください。

HALRT-00019: {0}センサーは正常な状態に戻りました。コンポーネント名: {1} トラップの追加情報: {2}

原因: センサーが正常な状態に戻りました。

処置: 情報アラートなので、ユーザー処理はありません。

HALRT-00020: {0}のフィールド交換可能ユニットは、システムに挿入されました。

原因: ユニットがシステムに挿入されました。

処置: 情報アラートなので、ユーザー処理はありません。

HALRT-00021: {0}のフィールド交換可能ユニットは、システムから取り外されました。

原因: ユニットがシステムから取り外されました。

処置: 情報アラートなので、ユーザー処理はありません。

HALRT-00022: コンポーネントの稼働状態は変更されたか、無効に変更中です。コンポーネント名: {0} 無効化の理由: {1} トラップの追加情報: {2}

原因: コンポーネントの稼働状態が変更されました。

処置: 情報アラートなので、ユーザー処理はありません。

HALRT-00023: コンポーネントの稼働状態は変更されたか、有効に変更中です。コンポーネント名: {0} トラップの追加情報: {1}

原因: コンポーネントの稼働状態が変更されました。

処置: 情報アラートなので、ユーザー処理はありません。

HALRT-00024: オペレーティング・システムがシステムを制御する前にエラーが検出されました。

原因: エラーが検出されました。

処置: コンソールのエラー・メッセージを取得してください。システムを再起動して電源を入れ直し、元に戻します。エラー・メッセージは、Oracleサポート・サービスに問い合せてください。

HALRT-00025: {0}によって識別される高可用性コンポーネントの状態が変更されました。古いHA状態: {1} 新しいHA状態: {2} トラップの追加情報: {3}

原因: 高可用性コンポーネントの状態が変更されました。

処置: アラート・メッセージの追加情報を参照してください。

HALRT-00026: 侵入センサーは、システムが物理的に改ざんされた可能性があることを検出しました。

原因: センサーがシステムの変更を検出しました。

処置: 情報アラートなので、ユーザー処理はありません。

HALRT-00027: ハード・ドライブの状態が変更されました。コンポーネント名: {0} 新しい状態: {1}

原因: ハード・ドライブの状態が変更されました。

処置: 情報アラートなので、ユーザー処理はありません。

HALRT-00028: これはテスト・トラップです。

原因: ユーザーがテスト・トラップを生成し、アラートが作成されました。

処置: 情報アラートなので、ユーザー処理はありません。

HALRT-00030: {0}コンポーネントの障害はクリアされました。

原因: コンポーネントの障害がクリアされました。

処置: 情報メッセージなので、処置は必要ありません。

C.2 温度アラート・メッセージ: HALRT-00513 - HALRT-00600

これらのアラート・メッセージの範囲は、HALRT-00513からHALRT-00600です。

HALRT-00513: 下限温度超過の警告(下限非クリティカル、低下中)。

原因: 温度が指定された制限以下でした。

処置: 温度機能の低下を確認します。システムを停止し、このセルのデータを移動します。

HALRT-00514: 下限温度超過の警告がクリアされました。

原因: 低温の警告がクリアされました。

処置: 情報アラートなので、ユーザー処理はありません。

HALRT-00515: 下限温度超過の問題(下限クリティカル - 低下中)。

原因: 低温の問題が検出されました。

処置: システムを停止します。熱障害の原因を特定します。必要に応じて、このセルのデータを移動します。

HALRT-00516: 下限温度超過の問題がクリアされました。

原因: 低温の問題がクリアされました。

処置: 情報アラートなので、ユーザー処理はありません。

HALRT-00517: 上限温度超過の警告(上限非クリティカル、上昇中)。

原因: 温度が制限を超えました。

処置: 温度機能の低下を確認します。システムを停止し、このセルのデータを移動します。

HALRT-00518: 上限温度超過の警告がクリアされました。

原因: 高温の警告がクリアされました。

処置: 情報アラートなので、ユーザー処理はありません。

HALRT-00519: 上限温度超過の問題(上限クリティカル - 上昇中)。

原因: 高温が検出されました。

処置: システムを停止します。熱障害の原因を特定します。必要に応じて、このセルのデータを移動します。

HALRT-00520: 上限温度超過の問題がクリアされました。

原因: 高温の問題がクリアされました。

処置: 情報アラートなので、ユーザー処理はありません。

HALRT-00521: CPUサーマル・トリップ(上限温度の超過による停止)。

原因: CPUの高温による停止が発生しました。

処置: システムを停止します。熱障害の原因を特定します。必要に応じて、このセルのデータを移動します。

HALRT-00522: CPUサーマル・トリップ(上限温度の超過による停止)がクリアされました。

原因: CPUの高温による停止がクリアされました。

処置: 情報アラートなので、ユーザー処理はありません。

C.3 ファン・アラート・メッセージ: HALRT-00616 - HALRT-00700

これらのアラート・メッセージの範囲は、HALRT-00616からHALRT-00700です。

HALRT-00616: 一般のクリティカルなファン障害。

原因: ファンで障害が発生しました。

処置: システムを停止します。ファン障害の原因を特定します。ファンを交換します。必要に応じて、このセルのデータを移動します。

HALRT-00617: 一般のクリティカルなファン障害がクリアされました。

原因: ファンの障害がクリアされました。

処置: 情報アラートなので、ユーザー処理はありません。

HALRT-00618: ファンの冗長性が失われました。

原因: 冗長ファンの機能が停止しました。

処置: 情報アラートなので、ユーザー処理はありません。

HALRT-00619: ファンの冗長性が正常な状態に戻りました。

原因: 冗長ファンの機能が正常になりました。

処置: 情報アラートなので、ユーザー処理はありません。

C.4 電源/電力変換装置アラート・メッセージ: HALRT-00717 - HALRT-00800

これらのアラート・メッセージの範囲は、HALRT-00717からHALRT-00800です。

HALRT-00717: 電源の冗長性が失われました。

原因: 電源の冗長性の機能が停止しました。

処置: 情報アラートなので、ユーザー処理はありません。

HALRT-00718: 電源の冗長性が正常な状態に戻りました。

原因: 電源の冗長性の機能が正常になりました。

処置: 情報アラートなので、ユーザー処理はありません。

HALRT-00719: 電源が挿入されました。

原因: 電源がシステムに挿入されました。

処置: 情報アラートなので、ユーザー処理はありません。

HALRT-00720: 電源が取り外されました。

原因: 電源がシステムから取り外されました。

処置: 電源を確認します。必要に応じて、電源を交換します。

HALRT-00721: 電源障害。

原因: 電源で障害が発生しました。

処置: 電源を確認します。必要に応じて、電源を交換します。

HALRT-00722: 電源障害がクリアされました。

原因: 電源の障害がクリアされました。

処置: 情報アラートなので、ユーザー処理はありません。

HALRT-00723: 電源警告。

原因: 電源の問題により、警告が発生しました。

処置: 電源を確認します。必要に応じて、電源を交換します。

HALRT-00724: 電源警告がクリアされました。

原因: 電源の警告がクリアされました。

処置: 情報アラートなので、ユーザー処理はありません。

HALRT-00725: 電源のACが停止しました。

原因: AC電源が切断されました。

処置: 電源を確認します。必要に応じて、電源を交換します。

HALRT-00726: 電源のACが復旧しました。

原因: AC電源が復旧しました。

処置: 情報アラートなので、ユーザー処理はありません。

C.5 ネットワーク・アラート・メッセージ: HALRT-00912 - HALRT-01000

これらのアラート・メッセージの範囲は、HALRT-00912からHALRT-01000です。

HALRT-00912: インフィニバンド・ポート{0}の状態が無効です: {1}。

原因: InfiniBandデバイスの状態が無効でした。

処置: ibstatusを使用してInfiniBand構成を確認し、両方のポートの状態がACTIVEで、期待するレート(GB/秒)になっていることを検証します。ポートの状態がACTIVEになると、アラートが解除されます。低いリンク・レートにネゴシエーションを行うInfiniBandリンクの一般的な原因の1つとして、HCAまたはスイッチのInfiniBandケーブル・コネクタが緩いことが考えられます。通常、InfiniBandコネクタがHCAおよびスイッチにしっかりと取り付けられていることを確認すれば、この問題は解決します。

スイッチの再起動後に、ポートの状態がDOWNを示す場合があります。数分後に、ポートは自動的にACTIVEになります。

HALRT-00913: インフィニバンド・ポート{0}のレートが無効です: {1} Gps。

原因: InfiniBandデバイスのレートが無効でした。

処置: CellCLIコマンドLIST IBPORT DETAILを使用してポートをチェックします。両方のポートが予期する速度(GB/秒)であることを検証します。低いリンク・レートにネゴシエーションを行うInfinibandリンクの一般的な原因として、HCAまたはスイッチのInfiniBandケーブル・コネクタが緩いことが考えられます。通常、InfiniBandコネクタがHCAおよびスイッチにしっかりと取り付けられていることを確認すれば、この問題は解決します。

HALRT-00914: インフィニバンド・ポートのステータスは正常です。

原因: InfiniBandデバイスのステータスは正常です。

処置: 情報アラートなので、ユーザー処理はありません。

HALRT-00915: インフィニバンド・ポート{0}でゼロ以外のエラー数が示されています。

原因: 指定されたポートのRcvErrorsおよびSymbolErrorsのエラー数がゼロ以外でした。エラー数が0以外の場合、不良ケーブルまたは正しく設置されていないケーブルあるいはHCAまたはスイッチの不良ポートが原因である可能性があります。手動によるInfiniBandポートの有効化および無効化またはInfiniBandスイッチのリセットでも、これらのエラーが発生する可能性があります。

処置: CellCLIコマンドLIST IBPORT DETAILを使用してポートをチェックします。両方のポートが予期する速度(GB/秒)であることを検証します。低いリンク・レートにネゴシエーションを行うInfinibandリンクの一般的な原因として、HCAまたはスイッチのInfiniBandケーブル・コネクタが緩いことが考えられます。通常、InfiniBandコネクタがHCAおよびスイッチにしっかりと取り付けられていることを確認すれば、この問題は解決します。

C.6 ハード・ディスクおよびフラッシュ・ディスク・アラート・メッセージ: HALRT-01015 - HALRT-01200

HALRT-01015: 物理ドライブが、アダプタ: {0}、デバイスID: {1}、囲みID: {2}、スロットID: {3}で挿入されました。

原因: 物理ドライブが挿入されました。

処置: 情報アラートなので、ユーザー処理はありません。

HALRT-01016: 物理ドライブが、アダプタ{0}で取り外されました deviceId {1}、enclosureId {2}、slotId {3}。

原因: 物理ドライブが取り外されました。

処置: 物理ドライブが意図せずに削除された場合は、ただちにディスクを元に戻してください。

HALRT-01017: 物理ドライブの状態が{0}から{1}に変更されました。アダプタ: {2}デバイスID: {3}、エンクロージャID: {4}、スロットID: {5}。

原因: 物理ドライブのステータスが変更されました。

処置: 情報アラートなので、ユーザー処理はありません。

HALRT-01018: FRUが変更されました。アダプタ: {0}デバイスID: {1}、エンクロージャID: {2}、スロットID: {3}、エンクロージャID: {4}、FRU {5}。

原因: アダプタのフィールド交換可能ユニット(FRU)が変更されました。

処置: 情報アラートなので、ユーザー処理はありません。

HALRT-01020: 物理ドライブがサポートされていません。アダプタ: {0}デバイスID: {1}、エンクロージャID: {2}、スロットID: {3}。

原因: 物理ドライブがアダプタでサポートされていません。

処置: 物理ドライブが意図せずに削除された場合は、ただちにディスクを元に戻してください。

HALRT-01021: 物理ドライブが認証されていません。アダプタ: {0}デバイスID: {1}、エンクロージャID: {2}、スロットID: {3}。

原因: 物理ドライブが認証されませんでした。

処置: 物理ドライブが意図せずに削除された場合は、ただちにディスクを元に戻してください。

HALRT-01021: 物理ドライブが認証されていません。アダプタ: {0}デバイスID: {1}、エンクロージャID: {2}、スロットID: {3}。

原因: 物理ドライブが認証されませんでした。

処置: 物理ドライブが意図せずに削除された場合は、ただちにディスクを元に戻してください。

HALRT-01023: これはシステム・ディスクです。すぐにこのディスクを交換することが非常に重要です。このディスクを交換して同期化する前に、このセル上の他のシステム・ディスクに障害が発生すると、セルおよびディスク上のすべてのデータはオフラインになります。

レベル: 警告

原因: システム・ディスクの交換が必要です。

処置: できるだけすぐにシステム・ディスクを交換します。

HALRT-01024: 物理{0}ディスクのエラー数が増加しています。ディスク: {1}、シリアル番号: {2}、スロット番号: {3}

レベル: クリティカル

原因: 最後のディスク・チェックからディスク・エラー数が増加しました。

処置: 物理ディスク・エラーを監視し、必要に応じて交換します。

HALRT-01025: 物理{0}ディスクのエラー数は安定しています。ディスク: {1}、シリアル番号: {2}、スロット番号: {3}。

レベル: クリア

原因: 最後のディスク・チェックからディスク・エラー数が増加しませんでした。

処置: 情報メッセージなので、処置は必要ありません。

HALRT-01027: フラッシュ・セル・ディスク{0}の書込みパフォーマンスが低下しています。フラッシュ・カードのsupercapモジュールに障害が発生した可能性があります。フラッシュ・ディスク名: {1} ディスク・シリアル番号: {2} スロット番号: {3}

原因: フラッシュ・セル・ディスクの書込みパフォーマンスが低下しました。

処置: このフラッシュ・ディスク、フラッシュPCIカードまたはEnergy Storage Module(ESM)を交換する必要があります。PCIカードのすべてのディスクがパフォーマンスの低下を示している場合、セル・シャーシの背面から確認できるPCIカードのESM LEDを確認してください。このLEDが黄色の場合、ESMを交換する必要があります。交換するディスクに永続データがある場合は、それらのディスクからデータをリバランスします。次に、フラッシュ・ディスクを交換します。フラッシュ・ディスクに永続データが存在していた場合は、データをディスクの内部にリバランスします。このフラッシュ・ディスクにより提供されたフラッシュ・キャッシュは、自動的に無効化されます。

HALRT-01028: フラッシュ・セル・ディスク{0}の書込みパフォーマンスの問題が解決されました。

原因: フラッシュ・セル・ディスクのパフォーマンスの問題が解決しました。

処置: 情報メッセージなので、処置は必要ありません。

HALRT-01029: 物理ディスク{0}を自動的にONLINEに設定することができませんでした。物理ディスク{0}のファームウェアをアップグレードできませんでした。

レベル: クリティカル

原因: 物理ディスクのファームウェアをアップグレードできませんでした。

処置: 物理ディスク上のファームウェアをアップグレードし、MSを再起動してディスクをオンラインにします。

HALRT-01030: 論理ブロック・アドレスの形式が誤っているため、{0} {1}は拒否されます。

レベル: クリティカル

処置: 次のコマンドを使用して、手動でディスクをフォーマットします。

nvmecli --format --device={0} --type={1}
次に、ALTER PHYSICALDISK REENABLE FORCEコマンドを実行して、ディスクをオンラインに設定します。このアクションによって、ディスクのすべてのデータが消去されます。

HALRT-01032: 物理ディスク{0}のファームウェアが正常にアップグレードされました。

原因: 物理ディスクのファームウェアがアップグレードされました。

処置: 情報メッセージなので、処置は必要ありません。

HALRT-01035: 物理ディスク{0}のファームウェアをアップグレードできませんでした。MS_ACCEPT_DISKFW_DIFFERENTがtrueに設定されているため、挿入された物理ディスクが使用されます。

レベル: 情報

原因: ファームウェアのアップグレードに失敗しました。

処置: これは情報メッセージです。

HALRT-01036: Oracle Exadataは、デバイス・ユーティリティで次の問題を検出しました: {0}。

原因: 問題が検出されました。問題は次のうちのいずれかです。

- 出力の名前が重複しています。

- 出力のシリアル番号が重複しています。

- 出力のOSデバイス名が重複しています。

- ターゲットIDを持つディスクのデバイス名が見つかりません。

処置: デバイス・モニタリング・ユーティリティから予期しない出力がありました。問題が解決されると、解決済のアラートが送信されます。問題が解決しない場合は、Oracleサポート・サービスまでお問い合せください。

HALRT-01037: {0}出力の名前が重複しています: {1}。

原因: 出力の名前が重複しています。

処置: 問題が解決されると、解決済のアラートが送信されます。問題が解決しない場合は、Oracleサポート・サービスまでお問い合せください。

HALRT-01038: {0}出力のシリアル番号が重複しています: {1}。

原因: 出力のシリアル番号が重複しています。

処置: 問題が解決されると、解決済のアラートが送信されます。問題が解決しない場合は、Oracleサポート・サービスまでお問い合せください。

HALRT-01039: {0}出力のOSデバイス名が重複しています: {1}。

原因: 出力のオペレーティング・システム・デバイス名が重複しています。

処置: 問題が解決されると、解決済のアラートが送信されます。問題が解決しない場合は、Oracleサポート・サービスまでお問い合せください。

HALRT-01040: ターゲットIDを持つディスクのデバイス名が見つかりません: {0}。

原因: デバイスが見つかりませんでした。

処置: 問題が解決されると、解決済のアラートが送信されます。問題が解決しない場合は、Oracleサポート・サービスまでお問い合せください。

HALRT-01041: デバイス・ユーティリティの問題が解決されました。

原因: 問題が解決されました。

処置: 情報メッセージなので、処置は必要ありません。

HALRT-01042: {0}が置き換えられました。ステータス: {1} 製造業者: {2} モデル番号: {3} サイズ: {4} シリアル番号: {5} ファームウェア: {6} スロット番号: {7} セル・ディスク: {9} グリッド・ディスク: {10}。

レベル: 警告

原因: ディスクが交換されました。

処置: グリッド・ディスクおよびセル・ディスクが新しい物理ディスクで再作成されます。グリッド・ディスクがOracle ASMディスク・グループの一部である場合、ディスク・グループの冗長性およびASM_POWER_LIMITパラメータに基づいて、ディスクがディスク・グループに追加され、データがリバランスされます。

HALRT-01043: {0}が置き換えられました。ステータス: {1} 製造業者: {2} モデル番号: {3} サイズ: {4} シリアル番号: {5} ファームウェア: {6} スロット番号: {7} セル・ディスク: {9} グリッド・ディスク: {10} フラッシュ・キャッシュ: {11} フラッシュ・ログ: {12}。

レベル: 警告

原因: フラッシュ・ディスクが交換されました。

処置: 情報メッセージなので、処置は必要ありません。

- このスロットのフラッシュ・ディスクが以前にフラッシュ・キャッシュに使用されていた場合は、フラッシュ・キャッシュが自動的に再有効化されます。

- このスロットのフラッシュ・ディスクが以前にフラッシュ・ログに使用されていた場合は、フラッシュ・ログが自動的に再有効化されます。

- このスロットのフラッシュ・ディスクが以前にグリッド・ディスクに使用されていた場合は、グリッド・ディスクが自動的に再作成され、Oracle ASMによってデータが自動的にリバランスされます。

HALRT-01044: {0}に失敗しました。ステータス: {1} 製造業者: {2} モデル番号: {3} サイズ: {4} シリアル番号: {5} ファームウェア: {6} スロット番号: {7} セル・ディスク: {9} グリッド・ディスク: {10}。

レベル: クリティカル

原因: システム・ディスクに障害が発生しました。

処置: システム・ハード・ディスクに障害が発生しました。影響を受けているセルを特定するための白色のセル・ロケータLEDが点灯しており、影響を受けているドライブを特定するための黄色のサービス・アクションのLEDおよび青色の取外しOKのLEDがドライブで点灯しています。ディスクをできるだけすぐに交換してください。Oracle ASMリバランスによってデータの冗長性が自動的にリストアされます。

HALRT-01045: {0}は、障害を示すステータスになりました。{1}が置き換えられました。ステータス: {2} 製造業者: {3} モデル番号: {4} サイズ: {5} シリアル番号: {6} ファームウェア: {7} スロット番号: {8} セル・ディスク: {9} グリッド・ディスク: {10}。

レベル: クリティカル

原因: システム・ハード・ディスクがpredictive failureステータスになりました。

処置: これは情報メッセージです。システム・ハード・ディスクが予測障害ステータスになりました。影響を受けているセルを特定するための白色のセル・ロケータLEDが点灯しており、影響を受けているドライブを特定するための黄色のサービス・アクションLEDがドライブで点灯しています。ディスクのデータはOracle ASMによって他のディスクに自動的にリバランスされます。リバランスが完了すると、別のアラートが送信され、青色の取外しOKのLEDがドライブで点灯します。リバランスが完了してから、ディスクを交換してください。

HALRT-01046: スロット{2}のサイズ{1}の{0}は失敗しました。

レベル: クリティカル

原因: ハード・ディスクに障害が発生しました。

処置: データ・ハード・ディスクに障害が発生しました。影響を受けているセルを特定するための白色のセル・ロケータLEDが点灯しており、影響を受けているドライブを特定するための黄色のサービス・アクションのLEDおよび青色の取外しOKのLEDがドライブで点灯しています。ドライブを交換してください。Oracle ASMリバランスによってデータの冗長性が自動的にリストアされます。

HALRT-01047: {0}は、障害を示すステータスになりました。ステータス: {1} 製造業者: {2} モデル番号: {3} サイズ: {4} シリアル番号: {5} ファームウェア: {6} スロット番号: {7} セル・ディスク: {8} グリッド・ディスク: {9}。

レベル: クリティカル

原因: データ・ハード・ディスクがpredictive failureステータスになりました。

処置: 情報です。影響を受けているセルを特定するための白色のセル・ロケータLEDが点灯しており、影響を受けているドライブを特定するための黄色のサービス・アクションLEDがドライブで点灯しています。ディスクのデータはOracle ASMによって他のディスクに自動的にリバランスされます。リバランスが完了すると、別のアラートが送信され、青色の取外しOKのLEDがドライブで点灯します。リバランスが完了してから、ディスクを交換してください。

HALRT-01048: {0}に失敗しました。ステータス: {1} 製造業者: {2} モデル番号: {3} サイズ: {4} シリアル番号: {5} ファームウェア: {6} スロット番号: {7} セル・ディスク: {8} グリッド・ディスク: {9}。

レベル: クリティカル

原因: フラッシュ・ディスクに障害が発生しました。

処置: 白色のセル・ロケータLEDが点灯しており、影響を受けているセルを特定できます。フラッシュ・ディスクを交換してください。フラッシュ・キャッシュにフラッシュ・ディスクを使用する場合、このディスクでフラッシュ・キャッシュが無効になり、有効なフラッシュ・キャッシュ・サイズが縮小します。フラッシュ・ログにフラッシュ・ディスクを使用する場合、このディスクでフラッシュ・ログが無効になり、有効なフラッシュ・ログ・サイズが縮小します。グリッド・ディスクにフラッシュ・ディスクを使用する場合、Oracle ASMリバランスによってデータの冗長性が自動的にリストアされます。

HALRT-01049: {0}に失敗しました。ステータス: {1} 製造業者: {2} モデル番号: {3} サイズ: {4} シリアル番号: {5} ファームウェア: {6} スロット番号: {7} セル・ディスク: {8} グリッド・ディスク: {9}。

レベル: クリティカル

原因: システム・ハード・ディスクに障害が発生しました。

処置: 影響を受けているセルを特定するためのセル・ロケータLEDが点灯しており、影響を受けているドライブを特定するためのエラーLEDがドライブで点灯しています。ドライブを交換してください。Oracle ASMリバランスによってデータの冗長性が自動的にリストアされます。

HALRT-01050: {0}は、障害を示すステータスになりました。ステータス: {1} 製造業者: {2} モデル番号: {3} サイズ: {4} シリアル番号: {5} ファームウェア: {6} スロット番号: {7} セル・ディスク: {8} グリッド・ディスク: {9}。

レベル: クリティカル

原因: システム・ハード・ディスクがpredictive failureステータスになりました。

処置: 情報です。システム・ハード・ディスクが予測障害ステータスになりました。影響を受けているセルを特定するためのセル・ロケータLEDが点灯しており、影響を受けているディスクを特定するためのエラーLEDがディスクで点灯しています。ディスクのデータはOracle ASMによって他のディスクに自動的にリバランスされます。リバランスが完了したら、別のアラートが送信されます。リバランスが完了してから、ディスクを交換してください。

HALRT-01051: {0}に失敗しました｛0｝ failed。ステータス: {1} 製造業者: {2} モデル番号: {3} サイズ: {4} シリアル番号: {5} ファームウェア: {6} スロット番号: {7} セル・ディスク: {8} グリッド・ディスク: {9}。

レベル: クリティカル

原因: データ・ハード・ディスクに障害が発生しました。

処置: 影響を受けているセルを特定するためのセル・ロケータLEDが点灯しており、影響を受けているディスクを特定するためのエラーLEDがディスクで点灯しています。ドライブを交換してください。Oracle ASMリバランスによってデータの冗長性が自動的にリストアされます。

HALRT-01052: {0}は、障害を示すステータスになりました。ステータス: {1} 製造業者: {2} モデル番号: {3} サイズ: {4} シリアル番号: {5} ファームウェア: {6} スロット番号: {7} セル・ディスク: {8} グリッド・ディスク: {9}。

レベル: クリティカル

原因: データ・ハード・ディスクがpredictive failureステータスになりました。

処置: 情報です。影響を受けているセルを特定するためのセル・ロケータLEDが点灯しており、影響を受けているディスクを特定するためのエラーLEDがディスクで点灯しています。ディスクのデータはOracle ASMによって他のディスクに自動的にリバランスされます。リバランスが完了したら、別のアラートが送信されます。リバランスが完了してから、ディスクを交換してください。

HALRT-01053: 次のディスクでのOracle ASM削除操作がORA-{0}により失敗しました。ASMディスク名: {1} ASMディスク・グループ: {2} グリッド・ディスク: {3} セル・ディスク: {4} 物理ディスク: {5} 物理ディスク・ステータス: {6}。

レベル: 警告

原因: 提示された理由により、Oracle ASMディスク・グループからグリッド・ディスクが削除されませんでした。

処置: Oracle Exadata Storage Server Softwareにより引き続きコマンドが再試行され、削除コマンドが成功したらアラートが送信されます。

HALRT-01054: 次のディスクでのOracle ASM削除操作がORA-{0}により失敗しました。ASMディスク名: {1} ASMディスク・グループ: {2} グリッド・ディスク: {3} セル・ディスク: {4} 物理ディスク: {5} 物理ディスク・ステータス: {6}。

レベル: 警告

原因: 提示された理由により、Oracle ASM DROPコマンドが失敗しました。

処置: エラーが解決された後で、Oracle ASMディスクでDROPコマンドを手動で再試行します。

HALRT-01055: 次のディスクでのOracle ASMリバランス操作がORA-{0}により失敗しました。ASMディスク名: {1} ASMディスク・グループ: {2} グリッド・ディスク: {3} セル・ディスク: {4} 物理ディスク: {5} 物理ディスク・ステータス: {6}。

レベル: 警告

原因: 提示された理由により、Oracle ASMリバランス操作が失敗しました。

処置: 情報メッセージなので、処置は必要ありません。

HALRT-01056: 次のディスクでのOracle ASMリバランス操作が再開されました。ASMディスク名: {0} ASMディスク・グループ: {1} グリッド・ディスク: {2} セル・ディスク: {3} 物理ディスク: {4} 物理ディスク・ステータス: {5}。

レベル: 警告

原因: Oracle ASMリバランス操作が再開されました。

処置: 情報メッセージなので、処置は必要ありません。

HALRT-01057: 次のディスクでのOracle ASM追加操作がORA-{0}により失敗しました。ASMディスク名: {1} ASMディスク・グループ: {2} グリッド・ディスク: {3} セル・ディスク: {4} 物理ディスク: {5} 物理ディスク・ステータス: {6}。

レベル: 警告

原因: 提示された理由により、Oracle ASMのディスク追加操作が失敗しました。

処置: Oracle Exadata Storage Server Softwareにより引き続きコマンドが再試行され、成功したらアラートが送信されます。

HALRT-01058: 次のディスクでのOracle ASM追加操作がORA-{0}により失敗しました。ASMディスク名: {1} ASMディスク・グループ: {2} グリッド・ディスク: {3} セル・ディスク: {4} 物理ディスク名: {5} 物理ディスク・ステータス: {6}。

レベル: 警告

原因: 提示された理由により、Oracle ASMのディスク追加操作が失敗しました。

処置: エラーが解決された後で、Oracle ASMディスクでコマンドを手動で再試行します。

HALRT-01059: 次のASMディスクでの追加操作によってトリガーされたリバランス操作がOracle Exadataで完了しました。ASMディスク名: {0} ASMディスク・グループ: {1} グリッド・ディスク: {2} セル・ディスク: {3} 物理ディスク: {4} 物理ディスク・ステータス: {5}。

レベル: クリア

原因: リバランス操作が完了しました。

処置: 情報メッセージなので、処置は必要ありません。

HALRT-01060: 次のASMディスクでの削除操作によってトリガーされたリバランス操作がOracle Exadataで完了しました。ASMディスク名: {0} ASMディスク・グループ: {1} グリッド・ディスク: {2} セル・ディスク: {3} 物理ディスク: {4} 物理ディスク・ステータス: {5}。

レベル: 警告

原因: Oracle ASMディスク・グループへのリバランス操作が完了しました。

処置: 情報メッセージなので、処置は必要ありません。

HALRT-01061: {0}を使用する準備ができました。ステータス: {1} 製造業者: {2} モデル番号: {3} サイズ: {4} シリアル番号: {5} ファームウェア: {6} スロット番号: {7} セル・ディスク: {8} グリッド・ディスク: {9} フラッシュ・キャッシュ: {10} フラッシュ・ログ: {11}。

レベル: クリア

原因: ディスクは使用可能です。

処置: 情報メッセージなので、処置は必要ありません。

HALRT-01062: {0}を使用する準備ができました。ステータス: {1} 製造業者: {2} モデル番号: {3} サイズ: {4} シリアル番号: {5} ファームウェア: {6} スロット番号: {7} セル・ディスク: {8} グリッド・ディスク: {9}。

レベル: クリア

原因: ディスクは使用可能です。

処置: 情報メッセージなので、処置は必要ありません。

HALRT-01063: ASMリバランス指数制限が0であるため、次のディスクでのOracle ASMリバランス操作が失敗しました。ASMディスク名: {0} ASMディスク・グループ: {1} グリッド・ディスク: {2} セル・ディスク: {3} 物理ディスク: {4} 物理ディスク・ステータス: {5}。

レベル: 警告

原因: Oracle ASMリバランス操作が無効になっているため、リバランス操作が失敗しました。

処置: asm_power_limit初期化パラメータを確認して、0以外の値に変更します。

HALRT-01064: 次のASMディスクでの追加操作によってトリガーされたリバランス操作がOracle Exadataで完了しました。ASMディスク名: {0} ASMディスク・グループ: {1} グリッド・ディスク: {2} セル・ディスク: {3} 物理ディスク: {4} 物理ディスク・ステータス: {5}。

レベル: 警告

原因: Oracle ASMディスク・グループにグリッド・ディスクを追加するリバランス操作が完了しました。

処置: 情報メッセージなので、処置は必要ありません。

HALRT-01106: すべての論理ドライブがライトスルー・キャッシュ・モードです。HDDディスク・コントローラのバッテリを交換する必要があります。Oracleサポートに連絡してください。

原因: 論理ドライブが見つかりました。

処置: 情報アラートなので、ユーザー処理はありません。

HALRT-01107: ディスク・ドライブ{0}がライトスルー・キャッシュ・モードです。このドライブの書込みパフォーマンスに影響があります。Oracleサポートに連絡してください。

原因: ディスク・ドライブが失われました。

処置: できるだけすぐに物理ディスクを交換する必要があります。

HALRT-01108: 論理ドライブのステータスが変更されました。LUN: {0}。ステータス: {1}。物理{2}ディスク: {3}。スロット番号: {4}。シリアル番号: {5}。セル・ディスク: {6}。グリッド・ディスク: {7}。

原因: 論理ドライブのステータスが変更されました。

処置: 情報アラートなので、ユーザー処理はありません。

HALRT-01109: ディスク・コントローラのバッテリ温度がしきい値の摂氏{0}度を超えています。すべてのディスク・ドライブがライトスルー・キャッシュ・モードになっています。フラッシュ・ドライブには影響はありません。バッテリのシリアル番号: {1} バッテリ・タイプ: {2} バッテリ温度: {3} フル充電容量: {4} 充電比: {5} 周囲温度: {6}。

原因: 温度がしきい値を超えています。

処置: 周囲温度が32℃を下回っているかどうか、およびファンが動作しているかどうかを確認してください。

HALRT-01110: 論理ドライブが見つかりました。空でした。セル・ディスクおよびグリッド・ディスクの作成に失敗しました。LUN: {0}。ステータス: {1}。物理{2}ディスク: {3}。スロット番号: {4}。シリアル番号: {5}。

原因: 論理ドライブが見つかりました。

処置: 情報アラートなので、ユーザー処理はありません。

HALRT-01115: BGIは、アダプタ{0} VDターゲット{1}の修正不可エラーの処理を完了しました。

原因: BGIはエラーの処理を完了しました。

処置: 情報アラートなので、ユーザー処理はありません。

HALRT-01116: BGIは、アダプタ{0} VDターゲット{1}で失敗しました。

原因: アダプタのBGIが失敗しました。

処置: この仮想ドライブのLUNで障害が発生しました。LUNを削除して再作成してください。

HALRT-01117: アダプタ{0} VDターゲット{1}のVDの状態が{2}から{3}に変更されました。

原因: LUNの状態が変更されました。

処置: 情報アラートなので、ユーザー処理はありません。

HALRT-01118: VDの不正ブロックの表がアダプタ{0} VDターゲット{1}でクリアされました。

原因: LUNの不正ブロックの表がクリアされました。

処置: 情報アラートなので、ユーザー処理はありません。

HALRT-01123: ディスク・モデルが不適切であるため、{0}が拒否されました。ステータス: {1} 製造業者: {2} モデル番号: {3} サイズ: {4} シリアル番号: {5} ファームウェア: {6} スロット番号: {7} セル・ディスク: {8} グリッド・ディスク: {9}

レベル: クリティカル

原因: ハード・ディスクまたはLUNが拒否されました。

処置: ディスク・モデルがサポートされていないため、Oracle Exadata Storage Serverでこのハード・ディスクを使用できません。このハード・ディスクを取り外して、サポートされているディスクに交換してください。このセルでサポートされているディスク・モデルは次のとおりです: {0}。

関連項目:

Exadata Storage Serverの物理ディスクの保守。

HALRT-01124: {0}が置き換えられました。ステータス: {1} 製造業者: {2} モデル番号: {3} サイズ: {4} シリアル番号: {5} ファームウェア: {6} スロット番号: {7} セル・ディスク: {8} グリッド・ディスク: {9}。

レベル: 警告

原因: ハード・ディスクが交換されました。

処置: 情報メッセージなので、処置は必要ありません。

HALRT-01126: ディスク・コントローラ・バッテリのフル充電容量が最小しきい値の{0}mAhを下回っています。すべてのディスク・ドライブがライトスルー・キャッシュ・モードになっています。ディスクの書込みパフォーマンスが少し低下している可能性があります。フラッシュ・ドライブは影響されません。バッテリのシリアル番号: {1} バッテリ・タイプ: {2} バッテリ温度: {3} フル充電容量: {4} 充電比: {5} 周囲温度: {6}。

原因: バッテリのフル充電容量がしきい値を下回っています。

処置: ディスク・コントローラのバッテリを交換してください。

HALRT-01127: すべてのディスク・ドライブがライトスルー・キャッシュ・モードになっています。フラッシュ・ドライブには影響はありません。バッテリのシリアル番号: {1} バッテリ・タイプ: {2} バッテリ温度: {3} フル充電容量: {4} 充電比: {5} 周囲温度: {6}。

原因: 原因を特定できませんでした。

処置: Oracleサポート・サービスに問い合せてください。

HALRT-01128: セル・ディスクが欠落しており、{0}に再作成されています。ステータス: {1} 製造業者: {2} モデル番号: {3} サイズ: {4} シリアル番号: {5} ファームウェア: {6} スロット番号: {7} セル・ディスク: {8} グリッド・ディスク: {9}。

原因: セル・ディスクが欠落しており、ディスクに再作成されています。

処置: 情報アラートなので、ユーザー処理はありません。

HALRT-01130: {0}がpoor performanceステータスになりました。LUN {1}のステータスが{2}に変更されています。CellDiskのステータスが{3}に変更されています。ステータス: {4} 製造業者: {5} モデル番号: {6} サイズ: {7} シリアル番号: {8} ファームウェア: {9} スロット番号: {10} セル・ディスク: {11} グリッド・ディスク: {12}。

原因: ハード・ディスクまたはフラッシュ・ディスクのステータスがpoor performanceに変更されました。

処置: スロット{0}の物理ディスクが低いパフォーマンスを示し、交換する必要があります。可能な場合、この物理ディスクのグリッド・ディスクに関連するOracle ASMディスクがFORCEオプションで自動的に削除されます。オフライン・パートナのために削除のFORCEが失敗した場合、通常グリッド・ディスクが自動的に削除され、Oracle ASMリバランスでパフォーマンスの低いディスクから他のディスクにデータが移動されます。「ディスク障害による物理ディスクの交換」またはディスク障害に関連するアラート・メッセージを参照してください。

ディスクの問題が原因でディスクを交換するには、次の手順を実行します。

1. 物理ディスクのグリッド・ディスクに関連するOracle ASMディスクが正しく削除されるまで待機します。グリッド・ディスクが削除されたかどうか判別するには、Oracle ASMインスタンスのV$ASM_DISK_STATビューの問合せを実行します。

2. 物理ディスクを交換します。物理ディスクはホットプラグ対応で、電源の投入時に交換できます。
スロットの以前のディスクのグリッド・ディスクおよびセル・ディスクが新しい物理ディスクで再作成されます。これらのグリッド・ディスクがOracle ASMディスク・グループの一部である場合、ディスク・グループの冗長性およびasm_power_limitパラメータに基づいて、ディスクがディスク・グループに追加され、データがリバランスされます。

注意:
最初の2つのスロットのディスクは、オペレーティング・システムおよびOracle Exadata Storage Server Softwareを格納するシステム・ディスクです。セルを稼働させておくには、少なくとも1つのシステム・ディスクをオンラインにする必要があります。システム・ディスクを交換するときは、ALTER CELL VALIDATE CONFIGURATIONにmdadmエラーが表示されなくなり、システム・ディスクの再同期化が完了するまで待機してから、他のシステム・ディスクを交換します。

ディスクを削除または追加すると、Oracle ASMリバランスが発生します。リバランスのステータスを確認するには、次の手順を実行します。

- リバランス操作が正しく実行された可能性がある場合。Oracle ASMアラート・ログを確認してください。

- リバランス操作が現在実行されている可能性がある場合。GV$ASM_OPERATIONビューを確認して、リバランス操作が実行されているかどうか判別します。

- リバランス操作が失敗した可能性がある場合。V$ASM_OPERATIONビューのERROR_CODE列を確認して、リバランス操作が失敗したかどうか判別します。

- 複数のディスク・グループのリバランス操作を同じクラスタ内の様々なOracle ASMインスタンスで実行できます。Oracle ASMインスタンスは、一度に1つのリバランス操作を実行できます。すべてのOracle ASMインスタンスがビジー状態の場合、リバランス操作はキューに入れられます。

HALRT-01131: {0}のステータスが正常に変更されました。ステータス: {1} 製造業者: {2} モデル番号: {3} サイズ: {4} シリアル番号: {5} ファームウェア: {6} スロット番号: {7} セル・ディスク: {8} グリッド・ディスク: {9}

レベル: 警告

原因: ハード・ディスクまたはフラッシュ・ディスクのステータスがnormalに変更されました。

処置: 情報メッセージなので、処置は必要ありません。

HALRT-01132: {0}が削除されました。ステータス: {1} 製造業者: {2} モデル番号: {3} サイズ: {4} シリアル番号: {5} ファームウェア: {6} スロット番号: {7} セル・ディスク: {8} グリッド・ディスク: {9}。

レベル: 警告

原因: ハード・ディスクまたはフラッシュ・ディスクが取り外されました。

処置: 情報メッセージなので、処置は必要ありません。

HALRT-01133: {0}のステータスがオフラインに変更されました。ステータス: {1} 製造業者: {2} モデル番号: {3} サイズ: {4} シリアル番号: {5} ファームウェア: {6} スロット番号: {7} セル・ディスク: {8} グリッド・ディスク: {9}。

レベル: クリティカル

原因: ハード・ディスクまたはフラッシュ・ディスクのステータスがofflineに変更されました。

処置: 情報メッセージなので、処置は必要ありません。

HALRT-01141: フラッシュ・ディスクが交換されました。ステータス: {0} 製造業者: {1} モデル番号: {2} サイズ: {3} シリアル番号: {4} ファームウェア: {5} スロット番号: {6} セル・ディスク: {7} グリッド・ディスク: {8} フラッシュ・キャッシュ: {9} フラッシュ・ログ: {10}。

レベル: 警告

原因: フラッシュ・ディスクが交換されました。

処置: 情報メッセージなので、処置は必要ありません。

HALRT-01143: すべてのディスク・ドライブがライトスルー・キャッシュ・モードになっています。コントローラがディスク・ドライブのキャッシュを5分以上保存しています。フラッシュ・ドライブには影響はありません。バッテリのシリアル番号: {1} バッテリ・タイプ: {2} バッテリ温度: {3} フル充電容量: {4} 充電比: {5} 周囲温度: {6}。

原因: 保存されているキャッシュが5分以上オフになっていません。

処置: Oracleサポート・サービスに問い合せてください。

HALRT-01144: セル・ディスクが欠落しており、{0}に再作成されています。ステータス: {1} 製造業者: {2} モデル番号: {3} サイズ: {4} シリアル番号: {5} ファームウェア: {6} スロット番号: {7} セル・ディスク: {8} グリッド・ディスク: {9} フラッシュ・キャッシュ: {10} フラッシュ・ログ: {11}。

原因: セル・ディスクが欠落しており、ドライブに再作成されています。

処置: 情報アラートなので、ユーザー処理はありません。

HALRT-01145: フラッシュ・ディスクのステータスが予測障害に変更されました。ステータス: {0} 製造業者: {1} モデル番号: {2} サイズ: {3} シリアル番号: {4} ファームウェア: {5} スロット番号: {6} セル・ディスク: {7} グリッド・ディスク: {8} フラッシュ・キャッシュ: {9} フラッシュ・ログ: {10}。

レベル: クリティカル

原因: フラッシュ・ディスクのステータスがpredictive failureに変更されました。

処置: フラッシュ・ディスクがpredictive failureステータスになりました。白色のセル・ロケータLEDが点灯しており、影響を受けているセルを特定できます。

- フラッシュ・キャッシュにフラッシュ・ディスクを使用する場合、このディスクでフラッシュ・キャッシュが無効になり、有効なフラッシュ・キャッシュ・サイズが縮小します。

- フラッシュ・キャッシュがライトバック・モードになっている場合は、このフラッシュ・ディスクのダーティ・データが対応するグリッド・ディスクに自動的にフラッシュされます。

- フラッシュ・ログにフラッシュ・ディスクを使用する場合、このディスクでフラッシュ・ログが無効になり、有効なフラッシュ・ログ・サイズが縮小します。

- グリッド・ディスクにフラッシュ・ディスクを使用する場合、フラッシュ・ディスクのデータがOracle ASMによって他のフラッシュ・ディスクに自動的にリバランスされます。

このフラッシュ・ディスクのすべてのデータがリバランスされ、フラッシュされたら、別のアラートが送信されます。リバランスとフラッシュが完了してから、フラッシュ・ディスクを交換してください。

関連項目:

フラッシュ・ディスクの保守。

HALRT-01146: {0}がpoor performanceステータスになりました。LUN {1}のステータスが{2}に変更されています。セル・ディスクのステータスが{3}に変更されています。ステータス: {4} 製造業者: {5} モデル番号: {6} サイズ: {7} シリアル番号: {8} ファームウェア: {9} スロット番号: {10} セル・ディスク: {11} グリッド・ディスク: {12} フラッシュ・キャッシュ: {13} フラッシュ・ログ {14} 低いパフォーマンスの理由: {15}。

レベル: クリティカル

原因: フラッシュ・ディスクのステータスがpoor performanceに変更されました。

処置: 「フラッシュ・ディスクの保守」を参照してください。

HALRT-01147: {0}のステータスが正常に変更されました。ステータス: {1} 製造業者: {2} モデル番号: {3} サイズ: {4} シリアル番号: {5} ファームウェア: {6} スロット番号: {7} セル・ディスク: {8} グリッド・ディスク: {9} フラッシュ・キャッシュ: {10} フラッシュ・ログ: {11}。

レベル: 警告

原因: フラッシュ・ディスクのステータスがnormalに変更されました。

処置: 情報メッセージなので、処置は必要ありません。

HALRT-01148: フラッシュ・ディスクが取り外されました。ステータス: {0} 製造業者: {1} モデル番号: {2} サイズ: {3} シリアル番号: {4} ファームウェア: {5} スロット番号: {6} セル・ディスク: {7} グリッド・ディスク: {8} フラッシュ・キャッシュ: {9} フラッシュ・ログ: {10}。

レベル: 警告

原因: フラッシュ・ディスクが取り外されました。

処置: フラッシュ・ディスクが取り外されているか、Oracle Exadata Storage Serverに表示できなくなっています。

- フラッシュ・ディスクを交換したばかり場合、このアラートは情報提供のみを目的としており、フラッシュ・ディスクが交換済であることを示すクリア・アラートが送信されます。処理は不要です。

- フラッシュがキャッシュとして使用されている場合、影響はこのセルのフラッシュ・キャッシュ・サイズが減っているということだけです。フラッシュ・ディスクを取り外しても、停止、データ損失またはOracle ASMリバランスは発生しません。

各フラッシュ・カードには、それぞれ4つのフラッシュ・ディスクが含まれています。カード上の4つすべてのフラッシュ・ディスクにアラートがある場合は、カードが取り外されている可能性があります。フラッシュ・ディスクが同じカード上にあるかどうかを確認するには、アラート出力で同一のPCIスロット番号をチェックします。

HALRT-01149: {0}のステータスがオフラインに変更されました。ステータス: {1} 製造業者: {2} モデル番号: {3} サイズ: {4} シリアル番号: {5} ファームウェア: {6} スロット番号: {7} セル・ディスク: {8} グリッド・ディスク: {9} フラッシュ・キャッシュ: {10} フラッシュ・ログ: {11}。

レベル: クリティカル

原因: フラッシュ・ディスクのステータスがofflineに変更されました。

処置: 情報メッセージなので、処置は必要ありません。

HALRT-01150: セル・ディスクが欠落しており、{0}に再作成されています。

原因: セル・ディスクが欠落しており、ディスクに再作成されています。

処置: 情報アラートなので、ユーザー処理はありません。

HALRT-01153: ディスク・ドライブ{0}はライトバック・キャッシュ・モードに戻りました。

原因: ディスク・ドライブがライトバック・キャッシュ・モードになりました。

処置: 情報アラートなので、ユーザー処理はありません。

HALRT-01154: Oracle Exadata Storage Serverで、新規に挿入された物理ディスクにセル・ディスクおよびグリッド・ディスクを自動的に作成できませんでした。物理ディスク: {0} ステータス: {1} 製造業者: {2} モデル番号: {3} サイズ: {4} シリアル番号: {5} ファームウェア: {6} スロット番号: {7}。

レベル: 警告

原因: サーバーでセル・ディスクまたはグリッド・ディスクが自動的に作成されませんでした。

処置: Oracle Exadata Storage Serverソフトウェアにより自動作成が再試行され、成功したらアラートが送信されます。

HALRT-01155: ディスク・コントローラのバッテリが交換されたため、すべてのディスク・ドライブが一時的にライトスルー・キャッシュ・モードになっています。フラッシュ・ドライブには影響はありません。バッテリのシリアル番号: {0} バッテリ・タイプ: {1} バッテリ温度: {2} フル充電容量: {3} 充電比: {4} 周囲温度: {5}。

原因: ディスク・コントローラのバッテリが交換されました。

処置: 情報メッセージなので、処置は必要ありません。

HALRT-01156: 前に欠落していた{0}が見つかりました。ステータス: {1} 製造業者: {2} モデル番号: {3} サイズ: {4} シリアル番号: {5} ファームウェア: {6} スロット番号: {7} セル・ディスク: {8} グリッド・ディスク: {9} フラッシュ・キャッシュ: {10} フラッシュ・ログ: {11}。

レベル: クリア

原因: 欠落していたフラッシュ・ディスクが見つかりました。

処置: 情報メッセージなので、処置は必要ありません。

- このスロットのフラッシュ・ディスクが以前にフラッシュ・キャッシュに使用されていた場合は、フラッシュ・キャッシュが自動的に再有効化されます。

- このスロットのフラッシュ・ディスクが以前にフラッシュ・ログに使用されていた場合は、フラッシュ・ログが自動的に再有効化されます。

- このスロットのフラッシュ・ディスクが以前にグリッド・ディスクに使用されていた場合は、グリッド・ディスクが自動的に再作成され、Oracle ASMによってデータが自動的にリバランスされます。

HALRT-01157: 前に欠落していた{0}が見つかりました。ステータス: {1} 製造業者: {2} モデル番号: {3} サイズ: {4} シリアル番号: {5} ファームウェア: {6} スロット番号: {7} セル・ディスク: {8} グリッド・ディスク: {9}

レベル: クリア

原因: 欠落していたハード・ディスクが見つかりました。

処置: 情報メッセージなので、処置は必要ありません。

HALRT-01159: {0}のインポートに失敗しました。ステータス: {1} 製造業者: {2} モデル番号: {3} サイズ: {4} シリアル番号: {5} ファームウェア: {6} スロット番号: {7} 。

レベル: 警告

原因: ハード・ディスクのインポート手順に失敗しました。

処置: 欠落している他のハード・ディスク用にキャッシュが保持されているため、このハード・ディスクのインポートに失敗しました。{0}のハード・ディスクを設置しなおすか、交換してください。すべてのディスクが正常にインポートされたら、別のアラートが送信されます。

HALRT-01160: {0}にLUNを作成できませんでした。ステータス: {1} 製造業者: {2} モデル番号: {3} サイズ: {4} シリアル番号: {5} ファームウェア: {6} スロット番号: {7}

レベル: 警告

原因: ディスク・コントローラにより物理ディスクにLUNが作成されませんでした。

処置: Oracleサポート・サービスに問い合せてください。

HALRT-01161: すべてのディスク・ドライブがライトバック・キャッシュ・モードに戻っています。保存されているキャッシュがオフになっています。バッテリのシリアル番号: {0} バッテリ・タイプ: {1} バッテリ温度: {2} フル充電容量: {3} 充電比: {4} 周囲温度: {5}。

原因: ディスク・ドライブがライトバック・キャッシュ・モードに戻りました。

処置: 情報メッセージなので、処置は必要ありません。

HALRT-01162: すべてのディスク・ドライブがライトバック・キャッシュ・モードになっています。バッテリのシリアル番号: {0} バッテリ・タイプ: {1} バッテリ温度: {2} フル充電容量: {3} 充電比: {4} 周囲温度: {5}。

原因: ディスク・ドライブがライトバック・キャッシュ・モードになっています。

処置: 情報メッセージなので、処置は必要ありません。

HALRT-01163: すべてのディスク・ドライブがライトバック・キャッシュ・モードに戻っています。バッテリの充電が完了しました。バッテリのシリアル番号: {0} バッテリ・タイプ: {1} バッテリ温度: {2} フル充電容量: {3} 充電比: {4} 周囲温度: {5}。

原因: バッテリの充電が完了し、すべてのディスク・ドライブがライトバック・キャッシュ・モードに戻りました。

処置: 情報メッセージなので、処置は必要ありません。

HALRT-01164: すべてのディスク・ドライブがライトバック・キャッシュ・モードになっています。バッテリのシリアル番号: {0} バッテリ・タイプ: {1} バッテリ温度: {2} フル充電容量: {3} 充電比: {4} 周囲温度: {5}。

原因: ディスク・ドライブがライトバック・キャッシュ・モードになっています。

処置: 情報メッセージなので、処置は必要ありません。

HALRT-01165: {0}を交換できます。ステータス: {1} 製造業者: {2} モデル番号: {3} サイズ: {4} シリアル番号: {5} ファームウェア: {6} スロット番号: {7} セル・ディスク: {8} グリッド・ディスク: {9}。

レベル: 警告

原因: 物理ディスクの交換が必要です。

処置: このディスクのデータはOracle ASMによって他のディスクに正常にリバランスされました。ドライブに対して、青色の取外しOKのLEDが点灯しました。ドライブを交換してください。

HALRT-01166: {0}を交換できます。ステータス: {1} 製造業者: {2} モデル番号: {3} サイズ: {4} シリアル番号: {5} ファームウェア: {6} スロット番号: {7} セル・ディスク: {8} グリッド・ディスク: {9} フラッシュ・キャッシュ: {10} フラッシュ・ログ: {11}。

レベル: 警告

原因: フラッシュ・ディスクの交換が必要です。

処置: このフラッシュ・ディスクのデータは正常にリバランスまたはフラッシュされています。ドライブを交換してください。

HALRT-01167: {0}を交換できます。ステータス: {1} 製造業者: {2} モデル番号: {3} サイズ: {4} シリアル番号: {5} ファームウェア: {6} スロット番号: {7} セル・ディスク: {8} グリッド・ディスク: {9} フラッシュ・キャッシュ: {10} フラッシュ・ログ: {11} ボード・トレーサ番号{12}

レベル: 警告

原因: フラッシュ・ディスクの交換が必要です。

処置: このフラッシュ・ディスクのデータは正常にリバランスまたはフラッシュされています。ドライブを交換してください。

HALRT-01168: {0}が取り外されているか、挿入されています。ステータス: {1} 製造業者: {2} モデル番号: {3} サイズ: {4} シリアル番号: {5} ファームウェア: {6} スロット番号: {7}

レベル: 情報

原因: コンポーネントが挿入されています。

処置: 情報メッセージなので、処置は必要ありません。物理ディスクが取り外されたときにCELLSRVによりI/Oエラーが報告された可能性があります。その結果、この物理ディスクのグリッド・ディスクがOracle ASMでオフラインになった場合、Oracle ASMによりディスクが自動的にオンラインにされます。

HALRT-01169: {0}は、ライトスルー・キャッシュ・モードになりました。ステータス: {1} 製造業者: {2} モデル番号: {3} サイズ: {4} シリアル番号: {5} ファームウェア: {6} スロット番号: {7} セル・ディスク: {8} グリッド・ディスク: {9} フラッシュ・キャッシュ: {10} フラッシュ・ログ: {11}。

レベル: クリティカル

原因: フラッシュ・ディスクで障害が発生しました。

処置: 白色のセル・ロケータLEDが点灯しており、影響を受けているセルを特定できます。フラッシュ・ディスクを交換してください。

- フラッシュ・キャッシュにフラッシュ・ディスクを使用する場合、このディスクでフラッシュ・キャッシュが無効になり、有効なフラッシュ・キャッシュ・サイズが縮小します。

- フラッシュ・ログにフラッシュ・ディスクを使用する場合、このディスクでフラッシュ・ログが無効になり、有効なフラッシュ・ログ・サイズが縮小します。

- グリッド・ディスクにフラッシュ・ディスクを使用する場合、Oracle ASMリバランスによってデータの冗長性が自動的にリストアされます。

関連項目:

フラッシュ・ディスクの保守。

HALRT-01170: ライト・バック・フラッシュ・キャッシュのフラッシュに失敗しました。ステータス: {0} 製造業者: {1} モデル番号: {2} サイズ: {3} シリアル番号: {4} ファームウェア: {5} スロット番号: {6} セル・ディスク: {7} グリッド・ディスク: {8} フラッシュ・キャッシュ: {9} フラッシュ・ログ: {10}。

レベル: クリティカル

原因: フラッシュ・キャッシュをフラッシュできませんでした。

処置: アラート・ログで詳細を確認してください。根本的な問題が解決されたら、このセル・ディスクのライトバック・フラッシュ・キャッシュのフラッシュが自動的に再開されます。

HALRT-01171: {0}は、制限オフライン・ステータスになりました。LUN {1}のステータスが{2}に変更されています。セル・ディスクのステータスが{3}に変更されています。このディスクに対する後続のI/Oはすべて即時に失敗します。ディスクで制限テストが実行され、ディスクの削除が必要かどうか判別されます。ステータス: {4} 製造業者: {5} モデル番号: {6} サイズ: {7} シリアル番号: {8} ファームウェア: {9} スロット番号: {10} セル・ディスク: {11} グリッド・ディスク: {12} 制限の理由: {13}。

原因: ハード・ディスクのパフォーマンスが低下し、制限状態になりました。

処置: ハード・ディスクをグリッド・ディスクに使用している場合、このハード・ディスクのグリッド・ディスクに関連するOracle ASMディスクがオフラインにされます。このディスクに対して制限テストが実行され、ディスクが恒久的にpoor performanceになるか、ディスクがnormal状態に戻ります。

HALRT-01172: {0}は、制限オフライン・ステータスになりました。LUN {1}のステータスが{15}に変更されています。セル・ディスクのステータスが{2}に変更されています。このディスクに対する後続のI/Oはすべて即時に失敗します。ディスクで制限テストが実行され、ディスクの削除が必要かどうか判別されます。ステータス: {4} 製造業者: {5} モデル番号: {6} サイズ: {7} シリアル番号: {8} ファームウェア: {9} スロット番号: {10} セル・ディスク: {11} グリッド・ディスク: {12} フラッシュ・キャッシュ: {13} フラッシュ・ログ: {14} 制限の理由: {15}。

原因: フラッシュ・ディスクのパフォーマンスが低下し、制限状態になりました。

処置: 次のいずれかの処置が実行されます。

- フラッシュ・ディスクをwritethroughフラッシュ・キャッシュに使用している場合、このディスクでフラッシュ・キャッシュが無効になり、有効なフラッシュ・キャッシュ・サイズが縮小します。

- フラッシュ・ディスクをwritebackフラッシュ・キャッシュに使用している場合、このディスクのフラッシュ・キャッシュが無効になり、フラッシュ・キャッシュ内のダーティ・データに対する読取りI/Oが別のセルのミラー・ディスクを対象とするようになります。書込みI/Oはこのセルのグリッド・ディスクを直接対象とします。

- フラッシュ・ディスクをフラッシュ・ログに使用している場合、このディスクでフラッシュ・ログが無効になり、有効なフラッシュ・ログ・サイズが縮小します。

- フラッシュ・ディスクをグリッド・ディスクに使用している場合、このフラッシュ・ディスクのグリッド・ディスクに関連するOracle ASMディスクがオフラインにされます。

このディスクに対して制限テストが実行され、ディスクが恒久的にpoor performanceになるか、ディスクがnormal状態に戻ります。

HALRT-01173: {0}は、制限ステータスになりました。LUN {1}のステータスが{2}に変更されています。セル・ディスクのステータスが{3}に変更されています。ステータス: {4} 製造業者: {5} モデル番号: {6} サイズ: {7} シリアル番号: {8} ファームウェア: {9} スロット番号: {10} セル・ディスク: {11} グリッド・ディスク: {12} 制限の理由: {13}。

原因: システム・ディスクは制限状態になりました。

処置: Oracleサポート・サービスに問い合せてください。

HALRT-01174: {0}は、制限ステータスになりました。LUN {1}のステータスが{2}に変更されています。セル・ディスクのステータスが{3}に変更されています。ステータス: {4} 製造業者: {5} モデル番号: {6} サイズ: {7} シリアル番号: {8} ファームウェア: {9} スロット番号: {10} セル・ディスク: {11} グリッド・ディスク: {12} フラッシュ・キャッシュ: {13} フラッシュ・ログ: {14} 制限の理由: {15}。

原因: ディスクは制限状態になりました。

処置: ディスクを正しいスロットに挿入してください。

HALRT-01175: システム・スロット{0}にパーティション表がありません。

レベル: 警告

原因: パーティション表がドライブのシステム・スロットにありません。

処置: Oracleサポート・サービスに問い合せてください。

HALRT-01176: スロット{1}のデータ・ディスクが同じOracle Exadata Storage Serverのシステム・スロット{2}に挿入されています。ステータス: {1} 製造業者: {2} モデル番号: {3} サイズ: {4} シリアル番号: {5} ファームウェア: {6} スロット番号: {7}

レベル: 警告

原因: データ・ディスクが間違ったスロットに挿入されています。

処置: ディスクを正しいスロットに挿入してください。

HALRT-01177: スロット{0}のシステム・ディスクが同じOracle Exadata Storage Serverのデータ・スロット{1}に挿入されています。ステータス: {2} 製造業者: {3} モデル番号: {4} サイズ: {5} シリアル番号: {6} ファームウェア: {7} スロット番号: {8}。

レベル: 警告

原因: 同じExadata Storage Serverのシステム・ディスクがデータ・ディスク・スロットに挿入されています。

処置: 正しいディスクをスロットに挿入してください。

HALRT-01178: 異なるOracle Exadata Storage Serverのシステム・ディスクがスロット{0}に挿入されています。ステータス: {1} 製造業者: {2} モデル番号: {3} サイズ: {4} シリアル番号: {5} ファームウェア: {6} スロット番号: {7}。

レベル: 警告

原因: 異なるExadata Storage Serverのシステム・ディスクがスロットに挿入されています。

処置: 正しいディスクをスロットに挿入してください。

HALRT-01179: 異なるOracle Exadata Storage Serverのデータ・ディスクがシステム・スロット{0}に挿入されています。ステータス: {1} 製造業者: {2} モデル番号: {3} サイズ: {4} シリアル番号: {5} ファームウェア: {6} スロット番号: {7}。

レベル: 警告

原因: 異なる同じExadata Storage Serverのデータ・ディスクがシステム・ディスク・スロットに挿入されています。

処置: 正しいディスクをスロットに挿入してください。

HALRT-01181: {0}は、ピア障害を示すステータスになりました。ステータス: {1} 製造業者: {2} モデル番号: {3} サイズ: {4} シリアル番号: {5} ファームウェア: {6} スロット番号: {7} セル・ディスク: {8} グリッド・ディスク: {9} フラッシュ・キャッシュ: {10} フラッシュ・ログ: {11}。

レベル: クリティカル

原因: フラッシュ・ディスクがpeer failureステータスになりました。

処置: フラッシュ・ディスクがpredictive failureステータスになりました。白色のセル・ロケータLEDが点灯しており、影響を受けているセルを特定できます。

- フラッシュ・キャッシュにフラッシュ・ディスクを使用する場合、このディスクでフラッシュ・キャッシュが無効になり、有効なフラッシュ・キャッシュ・サイズが縮小します。

- フラッシュ・キャッシュがライトバック・モードになっている場合は、このフラッシュ・ディスクのダーティ・データが対応するグリッド・ディスクに自動的にフラッシュされます。

- フラッシュ・ログにフラッシュ・ディスクを使用する場合、このディスクでフラッシュ・ログが無効になり、有効なフラッシュ・ログ・サイズが縮小します。

- グリッド・ディスクにフラッシュ・ディスクを使用する場合、フラッシュ・ディスクのデータがOracle ASMによって他のフラッシュ・ディスクに自動的にリバランスされます。

このフラッシュ・ディスクのすべてのデータがリバランスされ、フラッシュされたら、別のアラートが送信されます。リバランスとフラッシュが完了してから、フラッシュ・ディスクを交換してください。

HALRT01182: {0}がALTER PHYSICALDISK DROP FOR REPLACEMENTコマンドの実行前に取り外されました。ステータス: {1} 製造業者: {2} モデル番号: {3} サイズ: {4} シリアル番号: {5} ファームウェア: {6} スロット番号: {7} セル・ディスク: {8} グリッド・ディスク: {9}。

レベル: クリティカル

原因: ディスクがALTER PHYSICALDISK DROP FOR REPLACEMENTコマンドの実行前に取り外されました。

処置: 情報メッセージなので、処置は必要ありません。

HALRT01183: {0}がALTER PHYSICALDISK DROP FOR REPLACEMENTコマンドの実行前に取り外され、挿入されました。{1} 製造業者: {2} モデル番号: {3} サイズ: {4} シリアル番号: {5} ファームウェア: {6} スロット番号: {7}。

レベル: 情報

原因: ディスクがALTER PHYSICALDISK DROP FOR REPLACEMENTコマンドの実行前に取り外されました。

処置: 情報メッセージなので、処置は必要ありません。ディスクがオフラインになったときに、Oracle ASMグリッド・ディスクが物理ディスクにあった場合、Oracle ASMによりディスクが自動的にオンラインにされます。

HALRT-01184: {0}は、自動的にスペア・ディスクにフェイルオーバーしました。ステータス: {1} 製造業者: {2} モデル番号: {3} サイズ: {4} シリアル番号: {5} ファームウェア: {6} スロット番号: {7} セル・ディスク: {8} グリッド・ディスク: {9}。

レベル: クリティカル

原因: セル・ディスクがスペア・ディスクにフェイルオーバーしました。

処置: 情報メッセージなので、処置は必要ありません。

HALRT-01185: {0}は、自動的にスペア・ディスクにフェイルオーバーしました。ステータス: {1} 製造業者: {2} モデル番号: {3} サイズ: {4} シリアル番号: {5} ファームウェア: {6} スロット番号: {7} セル・ディスク: {8} グリッド・ディスク: {9} フラッシュ・キャッシュ: {10} フラッシュ・ログ: {11}。

原因: フラッシュ・ディスクがスペア・ディスクにフェイルオーバーしました。

処置: 情報メッセージなので、処置は必要ありません。

HALRT-01186: {0}が削除されました。ステータス: {1} 製造業者: {2} モデル番号: {3} サイズ: {4} シリアル番号: {5} ファームウェア: {6} スロット番号: {7} セル・ディスク: {8} グリッド・ディスク: {9} フラッシュ・キャッシュ: {10} フラッシュ・ログ: {11}。

レベル: クリティカル

原因: フラッシュ・ディスクが取り外されました。

処置: フラッシュ・ディスクが取り外されているか、表示できなくなっています。

- フラッシュ・ディスクを交換した場合、このアラートは情報提供のみを目的としており、フラッシュ・ディスクが交換済であることを示すクリア・アラートが送信されます。処理は不要です。

- フラッシュがキャッシュとして使用されている場合、影響はセルのフラッシュ・キャッシュ・サイズが減っているということだけです。フラッシュ・ディスクを取り外しても、停止、データ損失またはOracle ASMリバランスは発生しません。

- 各フラッシュ・カードには、それぞれ4つのフラッシュ・ディスクが含まれています。カード上の4つすべてのフラッシュ・ディスクでアラートが送信された場合は、カードが取り外されている可能性があります。フラッシュ・ディスクが同じカード上にあるかどうかを確認するには、アラート出力で同一のPCIスロット番号をチェックします。

HALRT-01187: {0}が置き換えられました。ステータス: {1} 製造業者: {2} モデル番号: {3} サイズ: {4} シリアル番号: {5} ファームウェア: {6} スロット番号: {7} セル・ディスク: {8} グリッド・ディスク: {9} フラッシュ・キャッシュ: {10} フラッシュ・ログ: {11}。

レベル: 警告

原因: フラッシュ・ディスクが交換されました。

処置: 情報メッセージなので、処置は必要ありません。

HALRT--01188: {0}が置き換えられました。ステータス: {1} 製造業者: {2} モデル番号: {3} サイズ: {4} シリアル番号: {5} ファームウェア: {6} スロット番号: {7} セル・ディスク: {8} グリッド・ディスク: {9} フラッシュ・キャッシュ: {10} フラッシュ・ログ: {11} ボード・トレーサ番号: {12}。

レベル: 警告

原因: フラッシュ・ディスクが交換されました。

処置: 情報メッセージなので、処置は必要ありません。

- このスロットのフラッシュ・ディスクが以前にフラッシュ・キャッシュに使用されていた場合は、フラッシュ・キャッシュが自動的に再有効化されます。

- このスロットのフラッシュ・ディスクが以前にフラッシュ・ログに使用されていた場合は、フラッシュ・ログが自動的に再有効化されます。

- このスロットのフラッシュ・ディスクが以前にグリッド・ディスクに使用されていた場合は、グリッド・ディスクが自動的に再作成され、Oracle ASMによってデータが自動的にリバランスされます。

HALRT--01189: Oracle Exadata Storage Serverで、新規に挿入された物理ディスクにセル・ディスクおよびグリッド・ディスクを自動的に作成できませんでした。物理ディスク: {0} ステータス: {1} 製造業者: {2} モデル番号: {3} サイズ: {4} シリアル番号: {5} ファームウェア: {6} スロット番号: {7} ボード・トレーサ番号: {8}。

レベル: 警告

原因: コンポーネントが交換されました。

処置: Oracle Exadata Storage Server Softwareにより自動作成操作が再試行され、成功したらアラートが送信されます。

HALRT--01190: 以前不足していた{0}が見つかりました。ステータス: {1} 製造業者: {2} モデル番号: {3} サイズ: {4} シリアル番号: {5} ファームウェア: {6} スロット番号: {7} セル・ディスク: {8} グリッド・ディスク: {9} フラッシュ・キャッシュ: {10} フラッシュ・ログ: {11} ボード・トレーサ番号: {12}。

レベル: クリティカル

原因: フラッシュ・ディスクが特定されました。

処置: 情報メッセージなので、処置は必要ありません。

- このスロットのフラッシュ・ディスクが以前にフラッシュ・キャッシュに使用されていた場合は、フラッシュ・キャッシュが自動的に再有効化されます。

- このスロットのフラッシュ・ディスクが以前にフラッシュ・ログに使用されていた場合は、フラッシュ・ログが自動的に再有効化されます。

- このスロットのフラッシュ・ディスクが以前にグリッド・ディスクに使用されていた場合は、グリッド・ディスクが自動的に再作成され、Oracle ASMによってデータが自動的にリバランスされます。

HALRT--01191: {0}のステータスが正常に変更されました。ステータス: {1} 製造業者: {2} モデル番号: {3} サイズ: {4} シリアル番号: {5} ファームウェア: {6} スロット番号: {7} セル・ディスク: {8} グリッド・ディスク: {9} フラッシュ・キャッシュ: {10} フラッシュ・ログ: {11} ボード・トレーサ番号: {12}。

レベル: 警告

原因: フラッシュ・ディスクのステータスがnormalに変更されました。

処置: 情報メッセージなので、処置は必要ありません。

HALRT--01192: {0}が取り外され、挿入されています。ステータス: {1} 製造業者: {2} モデル番号: {3} サイズ: {4} シリアル番号: {5} ファームウェア: {6} スロット番号: {7} ボード・トレーサ番号: {9}。

レベル: 情報

原因: 物理ディスクが取り外され、挿入されています。

処置: 情報メッセージなので、処置は必要ありません。ディスクが取り外されたときにCELLSRVによりI/Oエラーが報告された可能性があります。物理ディスクのグリッド・ディスクがOracle ASMでオフラインになった場合、Oracle ASMによりディスクが自動的にオンラインにされます。

HALRT--01193: {0}に失敗しました。ステータス: {1} 製造業者: {2} モデル番号: {3} サイズ: {4} シリアル番号: {5} ファームウェア: {6} スロット番号: {7} セル・ディスク: {8} グリッド・ディスク: {9} ボード・トレーサ番号: {10}。

レベル: クリティカル

原因: フラッシュ・ディスクで障害が発生しました。

処置: フラッシュ・ディスクで障害が発生し、交換する必要があります。白色のセル・ロケータLEDが点灯しており、影響を受けているセルを特定できます。

- フラッシュ・キャッシュにフラッシュ・ディスクを使用する場合、このディスクでフラッシュ・キャッシュが無効になり、有効なフラッシュ・キャッシュ・サイズが縮小します。

- フラッシュ・キャッシュがライトバック・モードになっている場合は、このフラッシュ・ディスクのダーティ・データが対応するグリッド・ディスクに自動的にフラッシュされます。

- フラッシュ・ログにフラッシュ・ディスクを使用する場合、このディスクでフラッシュ・ログが無効になり、有効なフラッシュ・ログ・サイズが縮小します。

- グリッド・ディスクにフラッシュ・ディスクを使用する場合、フラッシュ・ディスクのデータがOracle ASMによって他のフラッシュ・ディスクに自動的にリバランスされます。

HALRT--01194: {0}は、障害を示すステータスになりました。ステータス: {1} 製造業者: {2} モデル番号: {3} サイズ: {4} シリアル番号: {5} ファームウェア: {6} スロット番号: {7} セル・ディスク: {8} グリッド・ディスク: {9} フラッシュ・キャッシュ: {10} フラッシュ・ログ: {11} ボード・トレーサ番号: {12}。

レベル: クリティカル

原因: フラッシュ・ディスクがpredictive failureステータスになりました。

処置: フラッシュ・ディスクがpredictive failureステータスになりました。白色のセル・ロケータLEDが点灯しており、影響を受けているセルを特定できます。

- フラッシュ・キャッシュにフラッシュ・ディスクを使用する場合、このディスクでフラッシュ・キャッシュが無効になり、有効なフラッシュ・キャッシュ・サイズが縮小します。

- フラッシュ・キャッシュがライトバック・モードになっている場合は、このフラッシュ・ディスクのダーティ・データが対応するグリッド・ディスクに自動的にフラッシュされます。

- フラッシュ・ログにフラッシュ・ディスクを使用する場合、このディスクでフラッシュ・ログが無効になり、有効なフラッシュ・ログ・サイズが縮小します。

- グリッド・ディスクにフラッシュ・ディスクを使用する場合、フラッシュ・ディスクのデータがOracle ASMによって他のフラッシュ・ディスクに自動的にリバランスされます。

このフラッシュ・ディスクのすべてのデータがリバランスされ、フラッシュされたら、別のアラートが送信されます。リバランスとフラッシュが完了してから、フラッシュ・ディスクを交換してください。

HALRT--01195: {0}は、ピア障害を示すステータスになりました。ステータス: {1} 製造業者: {2} モデル番号: {3} サイズ: {4} シリアル番号: {5} ファームウェア: {6} スロット番号: {7} セル・ディスク: {8} グリッド・ディスク: {9} フラッシュ・キャッシュ: {10} フラッシュ・ログ: {11} ボード・トレーサ番号: {12}。

レベル: クリティカル

原因: フラッシュ・ディスクがpeer failureステータスになりました。

処置: フラッシュ・ディスクがpredictive failureステータスになりました。白色のセル・ロケータLEDが点灯しており、影響を受けているセルを特定できます。

- フラッシュ・キャッシュにフラッシュ・ディスクを使用する場合、このディスクでフラッシュ・キャッシュが無効になり、有効なフラッシュ・キャッシュ・サイズが縮小します。

- フラッシュ・キャッシュがライトバック・モードになっている場合は、このフラッシュ・ディスクのダーティ・データが対応するグリッド・ディスクに自動的にフラッシュされます。

- フラッシュ・ログにフラッシュ・ディスクを使用する場合、このディスクでフラッシュ・ログが無効になり、有効なフラッシュ・ログ・サイズが縮小します。

- グリッド・ディスクにフラッシュ・ディスクを使用する場合、フラッシュ・ディスクのデータがOracle ASMによって他のフラッシュ・ディスクに自動的にリバランスされます。

このフラッシュ・ディスクのすべてのデータがリバランスされ、フラッシュされたら、別のアラートが送信されます。リバランスとフラッシュが完了してから、フラッシュ・ディスクを交換してください。

HALRT--01196: {0}は、ライトスルー・キャッシュ・モードになりました。ステータス: {1} 製造業者: {2} モデル番号: {3} サイズ: {4} シリアル番号: {5} ファームウェア: {6} スロット番号: {7} セル・ディスク: {8} グリッド・ディスク: {9} フラッシュ・キャッシュ: {10} フラッシュ・ログ: {11} ボード・トレーサ番号: {12}。

レベル: クリティカル

原因: フラッシュ・ディスクがライトスルー・キャッシュ・モードになりました。

処置: フラッシュ・ディスクがpredictive failureステータスになりました。白色のセル・ロケータLEDが点灯しており、影響を受けているセルを特定できます。

- フラッシュ・キャッシュにフラッシュ・ディスクを使用する場合、このディスクでフラッシュ・キャッシュが無効になり、有効なフラッシュ・キャッシュ・サイズが縮小します。

- フラッシュ・キャッシュがライトバック・モードになっている場合は、このフラッシュ・ディスクのダーティ・データが対応するグリッド・ディスクに自動的にフラッシュされます。

- フラッシュ・ログにフラッシュ・ディスクを使用する場合、このディスクでフラッシュ・ログが無効になり、有効なフラッシュ・ログ・サイズが縮小します。

- グリッド・ディスクにフラッシュ・ディスクを使用する場合、フラッシュ・ディスクのデータがOracle ASMによって他のフラッシュ・ディスクに自動的にリバランスされます。

このフラッシュ・ディスクのすべてのデータがリバランスされ、フラッシュされたら、別のアラートが送信されます。リバランスとフラッシュが完了してから、フラッシュ・ディスクを交換してください。

HALRT--01197: {0}のステータスがオフラインに変更されました。ステータス: {1} 製造業者: {2} モデル番号: {3} サイズ: {4} シリアル番号: {5} ファームウェア: {6} スロット番号: {7} セル・ディスク: {8} グリッド・ディスク: {9} フラッシュ・キャッシュ: {10} フラッシュ・ログ: {11} ボード・トレーサ番号: {12}。

レベル: クリティカル

原因: コンポーネントのステータスがofflineに変更されました。

処置: 情報メッセージなので、処置は必要ありません。

HALRT--01198: {0}は、自動的にスペア・ディスクにフェイルオーバーしました。ステータス: {1} 製造業者: {2} モデル番号: {3} サイズ: {4} シリアル番号: {5} ファームウェア: {6} スロット番号: {7} セル・ディスク: {8} グリッド・ディスク: {9} フラッシュ・キャッシュ: {10} フラッシュ・ログ: {11} ボード・トレーサ番号: {12}。

レベル: クリティカル

原因: コンポーネントがスペア・ディスクにフェイルオーバーしました。

処置: 情報メッセージなので、処置は必要ありません。

HALRT--01199: {0}は完全に取り外されました。セルは正常にダウングレードされました。ステータス: {1} 製造業者: {2} モデル番号: {3} サイズ: {4} シリアル番号: {5} ファームウェア: {6} スロット番号: {7} セル・ディスク: {8} グリッド・ディスク: {9} フラッシュ・キャッシュ: {10} フラッシュ・ログ: {11} ボード・トレーサ番号: {12}。

レベル: クリア

原因: ユーザーによってフラッシュ・ディスクがスロットから取り外されました。セルは正常にダウングレードされました。

処置: 情報メッセージなので、処置は必要ありません。

C.7 アクセラレータ/コントローラ・アラート・メッセージ: HALRT-01209 - HALRT-01300

これらのアラート・メッセージの範囲は、HALRT-01209からHALRT-01300です。

HALRT-01209: アダプタ{0}のアラームがユーザーによって有効化されました。

原因: アダプタのアラームが有効化されました。

処置: 情報アラートなので、ユーザー処理はありません。

HALRT-01210: アダプタ{1}のバックグラウンドの初期化レートが{0}に変更されました。

原因: アダプタのバックグラウンドの初期化レートが変更されました。

処置: 情報アラートなので、ユーザー処理はありません。

HALRT-01211: コントローラ{0}のキャッシュが、メモリー/バッテリの問題により破棄されました。

原因: メモリーまたはバッテリの問題により、コントローラのキャッシュが破棄されました。

処置: キャッシュを失うと、ディスク上のすべてのデータは失効します。Oracle ASMからこのコントローラに接続されているディスクのデータを強制的に削除してから戻します。

HALRT-01212: 構成が不一致のため、アダプタ{0}のキャッシュ・データをリカバリできません。

原因: 構成の不一致により、キャッシュ・データがリカバリされました。

処置: キャッシュを失うと、ディスク上のすべてのデータは失効します。Oracle ASMからこのコントローラに接続されているディスクのデータを強制的に削除してから戻します。

HALRT-01213: アダプタ{0}のキャッシュ・データがリカバリされました。

原因: アダプタのキャッシュ・データがリカバリされました。

処置: 情報アラートなので、ユーザー処理はありません。

HALRT-01214: ファームウェア・バージョンに互換性がないため、アダプタ{0}のコントローラ・キャッシュが破棄されました。

原因: ファームウェア・バージョンに互換性がないため、コントローラ・キャッシュが破棄されました。

処置: キャッシュを失うと、ディスク上のすべてのデータは失効します。Oracle ASMからこのコントローラに接続されているディスクのデータを強制的に削除してから戻します。

HALRT-01215: アダプタ{1}の一貫性のチェック・レートが{0}に変更されました。

原因: アダプタの一貫性のチェック・レートが変更されました。

処置: 情報アラートなので、ユーザー処理はありません。

HALRT-01216: アダプタ{0}のダウンロードされたフラッシュ・イメージは破損しています。

原因: フラッシュ・メモリー・カード・イメージが破損しました。

処置: ディスク・コントローラのファームウェアをリフレッシュします。

HALRT-01217: アダプタ{0}のフラッシュの消去でエラーが発生しました。

原因: アダプタのフラッシュの消去でエラーが発生しました。

処置: ディスク・コントローラのファームウェアをリフレッシュします。

HALRT-01218: アダプタ{0}のフラッシュが、消去中にタイムアウトになりました。

原因: 消去手順の実行中にフラッシュがタイムアウトしました。

処置: ディスク・コントローラのファームウェアをリフレッシュします。

HALRT-01219: アダプタ{0}のフラッシュ・エラー。

原因: アダプタのフラッシュ・エラーが発生しました。

処置: ディスク・コントローラのファームウェアをリフレッシュします。

HALRT-01220: アダプタ{1}のフラッシュ・イメージ: {0}

原因: コントローラ・フラッシュが新しいイメージでアップグレードされました。

処置: 情報アラートなので、ユーザー処理はありません。

HALRT-01221: アダプタ{0}の新規ファームウェア・イメージのフラッシュが完了しました。

原因: 新しいファームウェア・イメージがフラッシュにコピーされました。

処置: 情報アラートなので、ユーザー処理はありません。

HALRT-01222: アダプタ{0}のフラッシュ・プログラミング・エラー。

原因: アダプタのフラッシュ・プログラミング・エラーが発生しました。

処置: ディスク・コントローラのファームウェアをリフレッシュします。

HALRT-01223: アダプタ{0}のフラッシュが、プログラミング中にタイムアウトになりました。

原因: アダプタのプログラミング中にフラッシュがタイムアウトしました。

処置: ディスク・コントローラのファームウェアをリフレッシュします。

HALRT-01224: アダプタ{0}の致命的なエラーが返されました。

原因: 致命的なエラーが発生しました。

原因: ディスク・コントローラでエラーが発生しています。Oracleサポート・サービスに問い合せてください。

HALRT-01225: アダプタ{1}の再構築レートが{0}に変更されました。

原因: アダプタの再構築レートが変更されました。

処置: 情報アラートなので、ユーザー処理はありません。

HALRT-01226: アダプタ{0}のアラームがユーザーによって無効化されました。

原因: アダプタのアラームが無効化されました。

処置: 情報アラートなので、ユーザー処理はありません。

HALRT-01227: アダプタ{0}の構成がクリアされました。

原因: アダプタの構成がクリアされました。

処置: この変更が意図したものではない場合は、Oracleサポート・サービスに問い合せてください。

HALRT-01228: アダプタ{0}のファクトリ・デフォルトがリストアされました。

原因: アダプタのファクトリ・デフォルト設定がリストアされました。

処置: この変更が意図したものではない場合は、Oracleサポート・サービスに問い合せてください。

HALRT-01229: アダプタ{0}のHDDディスク・コントローラ・バッテリが存在しません。

原因: アダプタのバッテリが存在しませんでした。

処置: この変更が意図したものではない場合は、Oracleサポート・サービスに問い合せてください。

HALRT-01230: アダプタ{0}に新規HDDディスク・コントローラ・バッテリが検出されました。

原因: アダプタの新しいバッテリが検出されました。

処置: 情報アラートなので、ユーザー処理はありません。

HALRT-01231: アダプタ{0}のHDDディスク・コントローラ・バッテリが交換されました。

原因: アダプタのバッテリが交換されました。

処置: 情報アラートなので、ユーザー処理はありません。

HALRT-01232: アダプタ{0}のHDDディスク・コントローラ・バッテリの温度が高くなっています。

原因: アダプタのバッテリ温度が高くなっていました。

処置: 動作温度がマシンの指定レベルの範囲であることを確認します。

HALRT-01233: アダプタ{0}のHDDディスク・コントローラ・バッテリの電圧が低くなっています。

原因: アダプタのバッテリの電圧が低くなっていました。

処置: バッテリが完全に充電されていない場合、バッテリを充電します。それ以外の場合、バッテリに障害が発生する可能性があります。ディスク・コントローラのバッテリを交換してください。

HALRT-01234: アダプタ{0}のHDDディスク・コントローラ・バッテリの温度は正常です。

原因: アダプタのバッテリが通常の温度でした。

処置: 情報アラートなので、ユーザー処理はありません。

HALRT-01235: HDDディスク・コントローラのバッテリを交換する必要があります。アダプタ{0}のSOH障害です。

原因: バッテリの交換が必要です。

処置: バッテリが完全に充電されていない場合、バッテリを充電します。それ以外の場合、バッテリに障害が発生する可能性があります。ディスク・コントローラのバッテリを交換してください。

HALRT-01236: アダプタ{0}のHDDディスク・コントローラ・バッテリが取り外されました。

原因: アダプタのバッテリが取り外されました。

処置: この変更が意図したものではない場合は、Oracleサポート・サービスに問い合せてください。

HALRT-01237: アダプタ{0}のHDDディスク・コントローラ・バッテリの現在の容量が、しきい値より低くなっています。

原因: アダプタのバッテリ容量がしきい値以下でした。

処置: バッテリが完全に充電されていない場合、バッテリを充電します。それ以外の場合、バッテリに障害が発生する可能性があります。ディスク・コントローラのバッテリを交換してください。

HALRT-01238: アダプタ{0}のHDDディスク・コントローラ・バッテリの現在の容量が、しきい値より高くなっています。

原因: アダプタのバッテリ容量がしきい値以上でした。

処置: 情報アラートなので、ユーザー処理はありません。

HALRT-01239: アダプタ{0}のBbu FRUが変更されました。

原因: アダプタのバッテリ・バックアップ・ユニット(BBU)のフィールド交換可能ユニット(FRU)が変更されました。

処置: 情報アラートなので、ユーザー処理はありません。

HALRT-01240: ディスク・コントローラのバッテリが学習サイクルを実行中で、学習サイクルの一部として一時的にライトスルー・キャッシュ・モードになっている可能性があります。ディスクの書込みスループットはこの間、一時的に低下する場合があります。フラッシュ・ドライブには影響はありません。バッテリ学習サイクルは、年に4回行われる通常の保守アクティビティで、約1時間から12時間実行されます。学習サイクルの多くはライトスルー・キャッシュ・モードに入る必要があります。ディスク・コントローラ・キャッシュが通常のライトバック・キャッシュ・モードに戻ると、追加情報のアラートが送信されます。バッテリのシリアル番号: {1} バッテリ・タイプ: {2} バッテリ温度: {3} フル充電容量: {4} 充電比: {5} 周囲温度: {6}。

原因: ディスク・コントローラのバッテリが学習サイクルを開始しました。

処置: 情報メッセージなので、処置は必要ありません。これは年に4回行われる通常の保守アクティビティで、約1時間から12時間実行されます。ディスク・コントローラのキャッシュは、学習サイクル中にライトスルー・キャッシュ・モードになる場合があります。ディスクの書込みスループットはこの間、一時的に低下する場合があります。

関連項目:

ハード・ディスク・コントローラのライトスルー・キャッシュ・モードの監視

HALRT-01243: すべてのディスク・ドライブがライトスルー・キャッシュ・モードになっています。フラッシュ・ドライブには影響はありません。ディスク・コントローラのバッテリが予定外の学習サイクルを実行しています。バッテリのシリアル番号: {1} バッテリ・タイプ: {2} バッテリ温度: {3} フル充電容量: {4} 充電比: {5} 周囲温度: {6}。

原因: 予定外の学習サイクルが開始されています。

処置: 予定外の学習サイクルの理由を確認してださい。

HALRT-01244: HDDディスク・コントローラのSASレーンでエラーが発生しました。

原因: ハード・ディスク・ドライブ・ディスク・コントローラのSASレーンで問題が発生しました。

原因: ディスク・コントローラでエラーが発生しています。Oracleサポート・サービスに問い合せてください。

HALRT-01245: HDDディスク・コントローラのSASレーンが正常に戻りました。

原因: ハード・ディスク・ドライブ・ディスク・コントローラのSASレーンが正常です。

処置: これは情報メッセージです。

C.8 電圧アラート・メッセージ: HALRT-01301 - HALRT-01400

これらのメッセージの範囲は、HALRT-01301からHALRT-01400です。

HALRT-01301: 不足電圧の問題(下限クリティカル - 低下中)。

原因: 不足電圧の問題が発生しました。

処置: 情報アラートなので、ユーザー処理はありません。

HALRT-01302: 不足電圧の問題がクリアされました。

原因: 不足電圧の問題がクリアされました。

処置: 情報アラートなので、ユーザー処理はありません。

HALRT-01303: 一般のクリティカルな電圧の問題。

原因: 一般的な電圧の問題が発生しました。

処置: 情報アラートなので、ユーザー処理はありません。

HALRT-01304: 一般のクリティカルな電圧の問題がクリアされました。

原因: 一般的な電圧の問題がクリアされました。

処置: 情報アラートなので、ユーザー処理はありません。

C.9 物理ディスク・アラート・メッセージ: HALRT-01401 - HALRT-01500

これらのメッセージの範囲は、HALRT-01401からHALRT-01500です。

HALRT-01401: {0}が置き換えられました。ステータス: {1} 製造業者: {2} モデル番号: {3} サイズ: {4} シリアル番号: {5} ファームウェア: {6} スロット番号: {7} セル・ディスク: {8} グリッド・ディスク: {9}。

レベル: クリア

原因: ラック内のコンポーネントが交換されました。

処置: グリッド・ディスクが自動的に再作成され、Oracle ASMによってデータが自動的にリバランスされます。

HALRT-01402: {0}が置き換えられました。ステータス: {1} 製造業者: {2} モデル番号: {3} サイズ: {4} シリアル番号: {5} ファームウェア: {6} スロット番号: {7} セル・ディスク: {8} グリッド・ディスク: {9} フラッシュ・キャッシュ: {10} フラッシュ・ログ: {11}。

レベル: クリア

原因: ラック内のフラッシュ・ディスクが交換されました。

処置: 情報メッセージなので、処置は必要ありません。

- このスロットのフラッシュ・ディスクが以前にフラッシュ・キャッシュに使用されていた場合は、フラッシュ・キャッシュが自動的に再有効化されます。

- このスロットのフラッシュ・ディスクが以前にフラッシュ・ログに使用されていた場合は、フラッシュ・ログが自動的に再有効化されます。

- このスロットのフラッシュ・ディスクが以前にグリッド・ディスクに使用されていた場合は、グリッド・ディスクが自動的に再作成され、Oracle ASMによってデータが自動的にリバランスされます。

HALRT-01403: {0}が置き換えられました。ステータス: {1} 製造業者: {2} モデル番号: {3} サイズ: {4} シリアル番号: {5} ファームウェア: {6} スロット番号: {7} セル・ディスク: {8} グリッド・ディスク: {9}。

レベル: クリア

原因: ラック内のコンポーネントが交換されました。

処置: 情報メッセージなので、処置は必要ありません。

HALRT-01404: {0}が置き換えられました。ステータス: {1} 製造業者: {2} モデル番号: {3} サイズ: {4} シリアル番号: {5} ファームウェア: {6} スロット番号: {7} セル・ディスク: {8} グリッド・ディスク: {9} フラッシュ・キャッシュ: {10} フラッシュ・ログ: {11}。

レベル: クリア

原因: ラック内のコンポーネントが交換されました。

処置: 情報メッセージなので、処置は必要ありません。

HALRT-01405: Oracle Exadata Storage Serverで、新規に挿入された物理ディスクにセル・ディスクおよびグリッド・ディスクを自動的に作成できませんでした。物理ディスク: {0} ステータス: {1} 製造業者: {2} モデル番号: {3} サイズ: {4} シリアル番号: {5} ファームウェア: {6} スロット番号: {7}。

レベル: クリア

原因: ラック内のコンポーネントが交換されました。

処置: Oracle Exadata Storage Server Softwareによりセル・ディスクおよびグリッド・ディスクの作成が再試行されます。自動作成が成功したら、アラートが送信されます。

HALRT-01406: {0}が置き換えられました。ステータス: {1} 製造業者: {2} モデル番号: {3} サイズ: {4} シリアル番号: {5} ファームウェア: {6} スロット番号: {7} セル・ディスク: {8} グリッド・ディスク: {9} フラッシュ・キャッシュ: {10} フラッシュ・ログ: {11} ボード・トレーサ番号: {12}。

レベル: クリア

原因: ラック内のコンポーネントが交換されました。

処置: 情報メッセージなので、処置は必要ありません。

HALRT-01407: {0}が置き換えられました。ステータス: {1} 製造業者: {2} モデル番号: {3} サイズ: {4} シリアル番号: {5} ファームウェア: {6} スロット番号: {7} セル・ディスク: {8} グリッド・ディスク: {9} フラッシュ・キャッシュ: {10} フラッシュ・ログ: {11} ボード・トレーサ番号: {12}。

レベル: クリア

原因: ラック内のフラッシュ・ディスクが交換されました。

処置: 情報メッセージなので、処置は必要ありません。

- このスロットのフラッシュ・ディスクが以前にフラッシュ・キャッシュに使用されていた場合は、フラッシュ・キャッシュが自動的に再有効化されます。

- このスロットのフラッシュ・ディスクが以前にフラッシュ・ログに使用されていた場合は、フラッシュ・ログが自動的に再有効化されます。

- このスロットのフラッシュ・ディスクが以前にグリッド・ディスクに使用されていた場合は、グリッド・ディスクが自動的に再作成され、Oracle ASMによってデータが自動的にリバランスされます。

HALRT-01408: Oracle Exadata Storage Serverで、新規に挿入された物理ディスクにセル・ディスクおよびグリッド・ディスクを自動的に作成できませんでした。物理ディスク: {0} ステータス: {1} 製造業者: {2} モデル番号: {3} サイズ: {4} シリアル番号: {5} ファームウェア: {6} スロット番号: {7} ボード・トレーサ番号: {8}。

レベル: クリア

原因: ラック内のコンポーネントが交換されました。

処置: Oracle Exadata Storage Server Softwareによりセル・ディスクおよびグリッド・ディスクの作成が再試行されます。自動作成が成功したら、アラートが送信されます。

HALRT-01409: {0}のステータスが正常に変更されました。ステータス: {1} 製造業者: {2} モデル番号: {3} サイズ: {4} シリアル番号: {5} ファームウェア: {6} スロット番号: {7} セル・ディスク: {8} グリッド・ディスク: {9}。

レベル: クリア

原因: コンポーネントのステータスがnormalに変更されました。

処置: 情報メッセージなので、処置は必要ありません。

HALRT-01410: {0}のステータスが正常に変更されました。ステータス: {1} 製造業者: {2} モデル番号: {3} サイズ: {4} シリアル番号: {5} ファームウェア: {6} スロット番号: {7} セル・ディスク: {8} グリッド・ディスク: {9} フラッシュ・キャッシュ: {10} フラッシュ・ログ: {11}。

レベル: クリア

原因: コンポーネントのステータスがnormalに変更されました。

処置: 情報メッセージなので、処置は必要ありません。

HALRT-01411: {0}のステータスが正常に変更されました。ステータス: {1} 製造業者: {2} モデル番号: {3} サイズ: {4} シリアル番号: {5} ファームウェア: {6} スロット番号: {7} セル・ディスク: {8} グリッド・ディスク: {9} フラッシュ・キャッシュ: {10} フラッシュ・ログ: {11} ボード・トレーサ番号: {12} 。

レベル: クリア

原因: コンポーネントのステータスがnormalに変更されました。

処置: 情報メッセージなので、処置は必要ありません。

HALRT-01420: {0}がpoor performanceステータスになりました。LUN {1}のステータスが{2}に変更されています。セル・ディスクのステータスが{3}に変更されています。ステータス: {4} 製造業者: {5} モデル番号: {6} サイズ: {7} シリアル番号: {8} ファームウェア: {9} スロット番号: {10} セル・ディスク: {11} グリッド・ディスク: {12} フラッシュ・キャッシュ: {13} フラッシュ・ログ {14} 低いパフォーマンスの理由: {15} ボード・トレーサ番号: {16}

レベル: クリティカル

原因: ハード・ディスクまたはフラッシュ・ディスクのステータスがpoor performanceに変更されました

処置: フラッシュ・ディスクがpoor performanceステータスになりました。白色のセル・ロケータLEDが点灯しており、影響を受けているセルを特定できます。

フラッシュ・キャッシュにフラッシュ・ディスクを使用する場合、このディスクでフラッシュ・キャッシュが無効になり、有効なフラッシュ・キャッシュ・サイズが縮小します。フラッシュ・キャッシュがライトバック・モードになっている場合は、このフラッシュ・ディスクのダーティ・データが対応するグリッド・ディスクに自動的にフラッシュされます。フラッシュ・ログにフラッシュ・ディスクを使用する場合、このディスクでフラッシュ・ログが無効になり、有効なフラッシュ・ログ・サイズが縮小します。グリッド・ディスクにフラッシュ・ディスクを使用する場合、フラッシュ・ディスクのデータがOracle ASMによって他のフラッシュ・ディスクに自動的にリバランスされます。このフラッシュ・ディスクのすべてのデータがリバランスされ、フラッシュされたら、別のアラートが送信されます。リバランスとフラッシュが完了してから、フラッシュ・ディスクを交換してください。

HALRT-01421: {0}がpoor performanceステータスになりました。LUN {1}のステータスが{2}に変更されています。セル・ディスクのステータスが{3}に変更されています。ステータス: {4} 製造業者: {5} モデル番号: {6} サイズ: {7} シリアル番号: {8} ファームウェア: {9} スロット番号: {10} セル・ディスク: {11} グリッド・ディスク: {12} 低いパフォーマンスの理由: {13}

レベル: クリティカル

原因: ハード・ディスクまたはフラッシュ・ディスクのステータスがpoor performanceに変更されました

処置: スロット{0}の物理ディスクが低いパフォーマンスを示し、交換する必要があります。可能な場合、この物理ディスクのグリッド・ディスクに関連するOracle ASMディスクがFORCEオプションで自動的に削除されます。オフライン・パートナのために削除のFORCEが失敗した場合、通常グリッド・ディスクが自動的に削除され、Oracle ASMリバランスでパフォーマンスの低いディスクから他のディスクにデータが移動されます。

物理ディスクが故障する前に削除を完了できなかった場合は、「ディスク障害による物理ディスクの交換」またはディスク障害に関連するアラート・メッセージを参照してください。

ディスクの問題が原因でディスクを交換するには、次の手順を実行します。

1. 物理ディスクのグリッド・ディスクに関連するOracle ASMディスクが正しく削除されるまで待機します。グリッド・ディスクが削除されたかどうか判別するには、Oracle ASMインスタンスのV$ASM_DISK_STATビューの問合せを実行します。

2. 物理ディスクを交換します。物理ディスクはホットプラグ対応で、電源の投入時に交換できます。
スロットの以前のディスクのグリッド・ディスクおよびセル・ディスクが新しい物理ディスクで再作成されます。これらのグリッド・ディスクがOracle ASMディスク・グループの一部である場合、ディスク・グループの冗長性およびasm_power_limitパラメータに基づいて、ディスクがディスク・グループに追加され、データがリバランスされます。

ディスクを削除または追加すると、Oracle ASMリバランスが発生します。リバランスのステータスを確認するには、次の手順を実行します。

- リバランス操作が正しく実行された可能性がある場合。Oracle ASMアラート・ログを確認してください。

- リバランス操作が現在実行されている可能性がある場合。GV$ASM_OPERATIONビューを確認して、リバランス操作が実行されているかどうか判別します。

- リバランス操作が失敗した可能性がある場合。V$ASM_OPERATIONビューのERROR_CODE列を確認して、リバランス操作が失敗したかどうか判別します。

- 複数のディスク・グループのリバランス操作を同じクラスタ内の様々なOracle ASMインスタンスで実行できます。Oracle ASMインスタンスは、一度に1つのリバランス操作を実行できます。すべてのOracle ASMインスタンスがビジー状態の場合、リバランス操作はキューに入れられます。

C.10 Exadata Storage Serverの自動サービス・リクエスト・アラート・メッセージ: HALRT-02001 - HALRT-02013

これらの自動サービス・リクエスト・アラート・メッセージの範囲は、HALRT-02001からHALRT-02013です。

HALRT-02001

原因: システム・ディスクで障害が発生しました。

処置: アラートがOracleサポート・サービスに送信されました。

HALRT-02002

原因: システム・ディスクでpredictive failureが発生しました。

処置: アラートがOracleサポート・サービスに送信されました。

HALRT-02003

原因: データ・ディスクで障害が発生しました。

処置: アラートがOracleサポート・サービスに送信されました。

HALRT-02004

原因: データ・ディスクでpredictive failureが発生しました。

処置: アラートがOracleサポート・サービスに送信されました。

HALRT-02005

原因: フラッシュ・ディスクで障害が発生しました。

処置: アラートがOracleサポート・サービスに送信されました。

HALRT-02006

原因: フラッシュ・ディスクでpredictive failureが発生しました。

処置: アラートがOracleサポート・サービスに送信されました。

HALRT-02007

原因: データベース・サーバーのハード・ディスクで障害が発生しました。

処置: アラートがOracleサポート・サービスに送信されました。

HALRT-02008

原因: データベース・サーバーのハード・ディスクでpredictive failureが発生しました。

処置: アラートがOracleサポート・サービスに送信されました。

HALRT-02009

原因: システム・ハード・ディスクのパフォーマンスが低下しています。

処置: アラートがOracleサポート・サービスに送信されました。

HALRT-02010

原因: データ・ハード・ディスクのパフォーマンスが低下しています。

処置: アラートがOracleサポート・サービスに送信されました。

HALRT-02011

原因: フラッシュ・ディスクのパフォーマンスが低下しています。

処置: アラートがOracleサポート・サービスに送信されました。

HALRT-02012

原因: BBUで障害が発生しました。

処置: アラートがOracleサポート・サービスに送信されました。

HALRT-02013

原因: 不明な理由により、BBUの機能が低下しています。

処置: アラートがOracleサポート・サービスに送信されました。

C.11 HDDコントローラのバッテリ・アラート・メッセージ: HALRT-02101 - HALRT-02200

これらのHDDコントローラ・バッテリ・メッセージの範囲は、HALRT-02101からHALRT-02200です。

HALRT-02101: HDDディスク・コントローラのバッテリは、交換のために除去されました。すべてのディスク・ドライブがライトスルー・キャッシュ・モードになっています。ディスクの書込みパフォーマンスが低下している可能性があります。フラッシュ・ドライブには影響はありません。バッテリのシリアル番号: {0} バッテリ・タイプ: {1} バッテリ温度: {2} フル充電容量: {3} 充電比: {4} 周囲温度: {5}。

レベル
警告

原因: HDDディスク・コントローラが交換前に削除されました。

処置: HDDディスク・コントローラのバッテリが間違って削除された場合は、HDDディスク・コントローラのバッテリを交換するか、ALTER CELL BBU REENABLEコマンドを使用してHDDディスク・コントローラのバッテリを再有効化してください。

HALRT-02102: HDDディスク・コントローラのバッテリが{0}です。すべてのディスク・ドライブがライトスルー・キャッシュ・モードになっています。ディスクの書込みパフォーマンスが低下している可能性があります。フラッシュ・ドライブには影響はありません。バッテリのシリアル番号: {1} バッテリ・タイプ: {2} バッテリ温度: {3} フル充電容量: {4} 充電比: {5} 周囲温度: {6}。

レベル
クリティカル

原因: HDDディスク・コントローラのバッテリで障害が発生しました。

処置: HDDディスク・コントローラのバッテリを交換してください。

HALRT-02103: HDDディスク・コントローラのバッテリで学習サイクルが実行されているため、すべてのディスク・ドライブが一時的にライトスルー・キャッシュ・モードになっています。ディスクの書込みパフォーマンスが少し低下している可能性があります。フラッシュ・ドライブには影響はありません。バッテリのシリアル番号: {1} バッテリ・タイプ: {2} バッテリ温度: {3} フル充電容量: {4} 充電比: {5} 周囲温度: {6}。

レベル
情報

原因: HDDディスク・コントローラのバッテリで学習サイクルが実行されています。

処置: これは情報アラートです。ディスク・ドライブは、HDDディスク・コントローラのバッテリで学習サイクルが完了すると、writebackモードになります。

HALRT-02104: HDDディスク・コントローラのバッテリの充電中であるため、すべてのディスク・ドライブが一時的にライトスルー・キャッシュ・モードになっています。ディスクの書込みパフォーマンスが少し低下している可能性があります。フラッシュ・ドライブには影響はありません。バッテリのシリアル番号: {1} バッテリ・タイプ: {2} バッテリ温度: {3} フル充電容量: {4} 充電比: {5} 周囲温度: {6}。

レベル
情報

原因: HDDディスク・コントローラのバッテリの充電中です。

処置: これは情報アラートです。ディスク・ドライブは、HDDディスク・コントローラのバッテリの充電が完了すると、writebackモードになります。

HALRT-02105: HDDディスク・コントローラのバッテリは削除されました。すべてのディスク・ドライブがライトスルー・キャッシュ・モードになっています。ディスクの書込みパフォーマンスが低下している可能性があります。フラッシュ・ドライブには影響はありません。

レベル
情報

原因: HDDディスク・コントローラのバッテリが取り外されました。

処置: HDDディスク・コントローラのバッテリを交換する必要があります。

HALRT-02106: HDDディスク・コントローラのバッテリ容量がしきい値の{0}mAhを下回っています。すべてのディスク・ドライブがライトスルー・キャッシュ・モードになっています。ディスクの書込みパフォーマンスが低下している可能性があります。フラッシュ・ドライブには影響はありません。バッテリのシリアル番号: {1} バッテリ・タイプ: {2} バッテリ温度: {3} フル充電容量: {4} 充電比: {5} 周囲温度: {6}。

レベル
クリティカル

原因: HDDディスク・コントローラのバッテリ容量が低すぎです。

処置: HDDディスク・コントローラのバッテリを交換するか、学習サイクルをスケジュールしてください。

HALRT-02107: HDDディスク・コントローラのバッテリ温度がしきい値の摂氏{6}度を超えています。すべてのディスク・ドライブがライトスルー・キャッシュ・モードになっています。ディスクの書込みパフォーマンスが低下している可能性があります。フラッシュ・ドライブには影響はありません。バッテリのシリアル番号: {1} バッテリ・タイプ: {2} バッテリ温度: {3} フル充電容量: {4} 充電比: {5} 周囲温度: {6}。

レベル
クリティカル

原因: HDDディスク・コントローラのバッテリ温度が高すぎです。

処置: HDDディスク・コントローラのバッテリが過熱しています。周囲温度が摂氏{0}度を下回っているかどうか、およびファンが動作しているかどうかを確認してください。

HALRT-02108: HDDディスク・コントローラのバッテリが交換されたため、すべてのディスク・ドライブが一時的にライトスルー・キャッシュ・モードになっています。ディスクの書込みパフォーマンスが少し低下している可能性があります。フラッシュ・ドライブには影響はありません。バッテリのシリアル番号: {1} バッテリ・タイプ: {2} バッテリ温度: {3} フル充電容量: {4} 充電比: {5} 周囲温度: {6}。

レベル
情報

原因: HDDディスク・コントローラのバッテリが交換されました。

処置: これは情報アラートです。ディスク・ドライブは、HDDディスク・コントローラのバッテリの充電が完了するまで、writebackモードになります。

HALRT-02109: すべてのディスク・ドライブがライトスルー・キャッシュ・モードになっています。ディスクの書込みパフォーマンスが低下している可能性があります。フラッシュ・ドライブには影響はありません。バッテリのシリアル番号: {1} バッテリ・タイプ: {2} バッテリ温度: {3} フル充電容量: {4} 充電比: {5} 周囲温度: {6}。

レベル
クリティカル

原因: HDDディスク・コントローラのバッテリが機能低下ステータスまたは不明なステータスになりました。

処置: HDDディスク・コントローラのバッテリを交換するか、学習サイクルをスケジュールしてください。

HALRT-02110: HDDディスク・コントローラのバッテリがALTER CELL BBU DROP FOR REPLACEMENTコマンドの実行前に取り外されました。バッテリのシリアル番号: {0} バッテリ・タイプ: {1} バッテリ温度: {2} フル充電容量: {3} 充電比: {4} 周囲温度: {5}。

レベル
クリティカル

原因: HDDディスク・コントローラのバッテリが取り外されましたが、バッテリの取外し前にALTER CELL BBU DROP FOR REPLACEMENTコマンドが実行されませんでした。

処置: HDDディスク・コントローラのバッテリを交換してください。

HALRT-02111: HDDディスク・コントローラのバッテリは交換されました。すべてのディスク・ドライブがライトバック・キャッシュ・モードになっています。バッテリのシリアル番号: {0} バッテリ・タイプ: {1} バッテリ温度: {2} フル充電容量: {3} 充電比: {4} 周囲温度: {5}。

レベル
クリア

原因: HDDディスク・コントローラのバッテリが交換されました。

処置: 情報アラートなので、ユーザー処理はありません。

HALRT-02112: すべてのディスク・ドライブがライトバック・キャッシュ・モードになっています。バッテリのシリアル番号: {0} バッテリ・タイプ: {1} バッテリ温度: {2} フル充電容量: {3} 充電比: {4} 周囲温度: {5}。

レベル
クリア

原因: HDDディスク・コントローラのバッテリが正常に戻りました。

処置: 情報アラートなので、ユーザー処理はありません。

HALRT-02113: すべてのディスク・ドライブがライトスルー・キャッシュ・モードになっています。コントローラがディスク・ドライブのキャッシュを5分以上保存しています。フラッシュ・ドライブには影響はありません。バッテリのシリアル番号: {0} バッテリ・タイプ: {1} バッテリ温度: {2} フル充電容量: {3} 充電比: {4} 周囲温度: {5}。

レベル
クリティカル

原因: 保存済キャッシュが原因で、すべてのディスク・ドライブがwritethroughキャッシュ・モードになりました。

処置: Oracleサポート・サービスに問い合せてください。

HALRT-02114: HDDディスク・コントローラのバッテリで予定外の学習サイクルが実行されています。すべてのディスク・ドライブがライトスルー・キャッシュ・モードになっています。フラッシュ・ドライブには影響はありません。バッテリのシリアル番号: {0} バッテリ・タイプ: {1} バッテリ温度: {2} フル充電容量: {3} 充電比: {4} 周囲温度: {5}。

レベル
情報

原因: HDDディスク・コントローラのバッテリで予定外の学習サイクルが実行されました。

処置: 予定外の学習サイクルの原因を特定してください。

HALRT-02115: ディスク・ドライブ{0}はライトスルー・キャッシュ・モードです。このドライブの書込みパフォーマンスに影響があります。

レベル
クリティカル

原因: ディスク・ドライブ{0}がwritethroughキャッシュ・モードになりました。

処置: HDDディスク・コントローラのバッテリは正常ですが、ディスク・ドライブ{0}がwritethroughキャッシュ・モードです。Oracleサポート・サービスに問い合せてください。

HALRT-02116: ディスク・ドライブ{0}はライトバック・キャッシュ・モードに戻りました。

レベル
クリア

原因: ディスク・ドライブ{0}がwritebackキャッシュ・モードに戻りました。

処置: これは情報アラートです。

HALRT-02117: HDDディスク・コントローラのバッテリは、学習サイクルを実行しています。バッテリのシリアル番号: {0} バッテリ・タイプ: {1} バッテリ温度: {2} フル充電容量: {3} 充電比: {4} 周囲温度: {5}。

レベル
情報

原因: ハード・ディスク・コントローラのバッテリが学習サイクルを開始しました。

処置: 情報アラートなので、ユーザーによる処置は必要ありません。

学習サイクルの一環として、すべてのディスク・ドライブが一時的にwritethroughキャッシュ・モードになる可能性があります。この間、ディスクの書込みスループットが低下する可能性があります。フラッシュ・ドライブには影響はありません。

バッテリ学習サイクルは、年に4回行われる通常の保守アクティビティで、約1時間から12時間実行されます。ほとんどの学習サイクルでwritethroughキャッシュ・モードの開始は不要です。ディスク・コントローラ・キャッシュがwritebackキャッシュ・モードに戻ると、情報アラートが送信されます。

HALRT-02118: HDDディスク・コントローラのバッテリは交換されました。すべてのディスク・ドライブがライトバック・キャッシュ・モードになっています。バッテリのシリアル番号: {0} バッテリ・タイプ: {1} バッテリ温度: {2} フル充電容量: {3} 充電比: {4} 周囲温度: {5}。

レベル
情報

原因: ハード・ディスク・コントローラのバッテリが交換されました。

処置: 情報アラートなので、ユーザーによる処置は必要ありません。

HALRT-02119: HDDディスク・コントローラのバッテリは交換されました。バッテリのシリアル番号: {0} バッテリ・タイプ: {1} バッテリ温度: {2} フル充電容量: {3} 充電比: {4} 周囲温度: {5}。

レベル
情報

原因: ハード・ディスク・コントローラのバッテリが交換されました。

処置: 情報アラートなので、ユーザーによる処置は必要ありません。

HALRT-02120: HDDディスク・コントローラのバッテリが再び差し込まれました。バッテリのシリアル番号: {0} バッテリ・タイプ: {1} バッテリ温度: {2} フル充電容量: {3} 充電比: {4} 周囲温度: {5}。

レベル
情報

原因: HDDディスク・コントローラが再び差し込まれました。

処置: 情報アラートなので、ユーザーによる処置は必要ありません。

HALRT-02121: HDDディスク・コントローラのバッテリが再び差し込まれました。

レベル
情報

原因: HDDディスク・コントローラが再び差し込まれました。

処置: 情報アラートなので、ユーザーによる処置は必要ありません。

HALRT-02121: HDDディスク・コントローラのバッテリは交換されました。すべてのディスク・ドライブがライトバック・キャッシュ・モードになっています。

レベル
情報

原因: HDDディスク・コントローラが交換されました。

処置: 情報アラートなので、ユーザーによる処置は必要ありません。

HALRT-02122: すべてのディスク・ドライブがライトバック・キャッシュ・モードになっています。バッテリのシリアル番号: {0} バッテリ・タイプ: {1} バッテリ温度: {2} フル充電容量: {3} 充電比: {4} 周囲温度: {5}

レベル
情報

原因: HDDディスク・コントローラのバッテリが正常に戻りました。

処置: 情報アラートなので、ユーザーによる処置は必要ありません。

HALRT-02151: HDDディスク・コントローラのバッテリは、交換のために除去されました。すべてのディスク・ドライブがライトスルー・キャッシュ・モードになっています。ディスクの書込みパフォーマンスが低下している可能性があります。フラッシュ・ドライブには影響はありません。バッテリのシリアル番号: {0} バッテリ・タイプ: {1} バッテリ温度: {2} パック: {3} 周囲温度: {4}。

レベル
警告

原因: HDDディスク・コントローラが交換のために削除されました。

処置: HDDディスク・コントローラのバッテリが間違って削除された場合は、HDDディスク・コントローラのバッテリを交換するか、ALTER CELL BBU REENABLEコマンドを使用してHDDディスク・コントローラのバッテリを再有効化してください。

HALRT-02152: HDDディスク・コントローラのバッテリで障害が発生しました。すべてのディスク・ドライブがライトスルー・キャッシュ・モードになっています。ディスクの書込みパフォーマンスが低下している可能性があります。フラッシュ・ドライブには影響はありません。バッテリのシリアル番号: {0} バッテリ・タイプ: {1} バッテリ温度: {2} パック: {3} 周囲温度: {4}。

レベル
クリティカル

原因: HDDディスク・コントローラのバッテリで障害が発生しました。

処置: HDDディスク・コントローラのバッテリを交換してください。

HALRT-02153: HDDディスク・コントローラのバッテリで学習サイクルが実行されているため、すべてのディスク・ドライブが一時的にライトスルー・キャッシュ・モードになっています。ディスクの書込みパフォーマンスが低下している可能性があります。フラッシュ・ドライブには影響はありません。バッテリのシリアル番号: {0} バッテリ・タイプ: {1} バッテリ温度: {2} パック: {3} 周囲温度: {4}。

レベル
情報

原因: HDDディスク・コントローラのバッテリで学習サイクルが実行されています。

処置: 処置は必要ありません。ディスク・ドライブは、HDDディスク・コントローラのバッテリで学習サイクルが完了すると、writebackモードになります。

HALRT-02154: HDDディスク・コントローラのバッテリの充電中であるため、すべてのディスク・ドライブが一時的にライトスルー・キャッシュ・モードになっています。ディスクの書込みパフォーマンスが低下している可能性があります。フラッシュ・ドライブには影響はありません。バッテリのシリアル番号: {0} バッテリ・タイプ: {1} バッテリ温度: {2} パック: {3} 周囲温度: {4}。

レベル
情報

原因: HDDディスク・コントローラがバッテリの充電を開始しました。

処置: 処置は必要ありません。ディスク・ドライブは、HDDディスク・コントローラのバッテリの充電が完了するまで、writebackモードになります。

HALRT-02155: HDDディスク・コントローラのバッテリは削除されました。すべてのディスク・ドライブがライトスルー・キャッシュ・モードになっています。ディスクの書込みパフォーマンスが低下している可能性があります。フラッシュ・ドライブには影響はありません。バッテリのシリアル番号: {0} バッテリ・タイプ: {1} バッテリ温度: {2} パック: {3} 周囲温度: {4}。

レベル
情報

原因: HDDディスク・コントローラのバッテリが取り外されました。

処置: HDDディスク・コントローラのバッテリを交換してください。

HALRT-02156: HDDディスク・コントローラの現在のバッテリ容量はしきい値の{0}Jouleを下回っています。すべてのディスク・ドライブがライトスルー・キャッシュ・モードになっています。ディスクの書込みパフォーマンスが低下している可能性があります。フラッシュ・ドライブには影響はありません。バッテリのシリアル番号: {1} バッテリ・タイプ: {2} バッテリ温度: {3} パック: {4} 周囲温度: {5}。

レベル
クリティカル

Cause: HDDディスク・コントローラのバッテリの充電量がしきい値を下回っています。

処置: HDDディスク・コントローラのバッテリを交換するか、学習サイクルをスケジュールしてください。

HALRT-02157: HDDディスク・コントローラのバッテリ温度がしきい値の摂氏{0}度を超えています。すべてのディスク・ドライブがライトスルー・キャッシュ・モードになっています。ディスクの書込みパフォーマンスが低下している可能性があります。フラッシュ・ドライブには影響はありません。バッテリのシリアル番号: {1} バッテリ・タイプ: {2} バッテリ温度: {3} パック: {4} 周囲温度: {5}。

レベル
クリティカル

Cause: HDDディスク・コントローラのバッテリの温度がしきい値を上回っています。

処置: HDDディスク・コントローラのバッテリが過熱しています。周囲温度が摂氏{0}度を下回っているかどうか、およびファンが動作しているかどうかを確認してください。

HALRT-02158: ディスク・コントローラのバッテリが交換されたため、すべてのディスク・ドライブが一時的にライトスルー・キャッシュ・モードになりました。ディスクの書込みパフォーマンスが低下している可能性があります。フラッシュ・ドライブには影響はありません。バッテリのシリアル番号: {1} バッテリ・タイプ: {2} バッテリ温度: {3} パック: {4} 周囲温度: {5}。

レベル
情報

原因: HDDディスク・コントローラが交換されました。

処置: 処置は必要ありません。ディスク・ドライブは、HDDディスク・コントローラのバッテリの充電が完了するまで、writebackモードになります。

HALRT-02159: すべてのディスク・ドライブがライトスルー・キャッシュ・モードになっています。ディスクの書込みパフォーマンスが低下している可能性があります。フラッシュ・ドライブには影響はありません。バッテリのシリアル番号: {1} バッテリ・タイプ: {2} バッテリ温度: {3} パック: {4} 周囲温度: {5}。

レベル
クリティカル

原因: すべてのディスク・ドライブがwritethroughキャッシュ・モードになりました。

処置: HDDディスク・コントローラのバッテリを交換するか、学習サイクルをスケジュールしてください。

HALRT-02161: HDDディスク・コントローラのバッテリは交換されました。すべてのディスク・ドライブがライトバック・キャッシュ・モードになっています。バッテリのシリアル番号: {1} バッテリ・タイプ: {2} バッテリ温度: {3} パック: {4} 周囲温度: {5}。

レベル
情報

原因: HDDディスク・コントローラのバッテリが交換されました。

処置: 情報アラートなので、ユーザーによる処置は必要ありません。

HALRT-02162: すべてのディスク・ドライブがライトバック・キャッシュ・モードになっています。バッテリのシリアル番号: {1} バッテリ・タイプ: {2} バッテリ温度: {3} パック: {4} 周囲温度: {5}。

レベル
情報

原因: すべてのディスク・ドライブがwritebackキャッシュ・モードになっています。

処置: 情報アラートなので、ユーザーによる処置は必要ありません。

HALRT-02163: すべてのディスク・ドライブがライトスルー・キャッシュ・モードになっています。コントローラがディスク・ドライブのキャッシュを5分以上保存しています。フラッシュ・ドライブには影響はありません。バッテリのシリアル番号: {1} バッテリ・タイプ: {2} バッテリ温度: {3} パック: {4} 周囲温度: {5}。

レベル
クリティカル

原因: すべてのディスク・ドライブがwritethroughキャッシュ・モードになりました。

処置: Oracleサポート・サービスに問い合せてください。

HALRT-02164: HDDディスク・コントローラのバッテリで予定外の学習サイクルが実行されています。すべてのディスク・ドライブがライトスルー・キャッシュ・モードになっています。フラッシュ・ドライブには影響はありません。バッテリのシリアル番号: {1} バッテリ・タイプ: {2} バッテリ温度: {3} パック: {4} 周囲温度: {5}。

レベル
情報

原因: HDDディスク・コントローラのバッテリで予定外の学習サイクルが開始されました。

処置: 予定外の学習サイクルがどのように開始されたかを確認してください。

HALRT-02165: ディスク・ドライブ{0}はライトスルー・キャッシュ・モードです。このドライブの書込みパフォーマンスに影響があります。バッテリのシリアル番号: {1} バッテリ・タイプ: {2} バッテリ温度: {3} パック: {4} 周囲温度: {5}。

レベル
クリティカル

原因: ディスク・ドライブがwritethroughキャッシュ・モードでした。

処置: Oracleサポート・サービスに問い合せてください。HDDディスク・コントローラのバッテリは正常ですが、ディスク・ドライブ{0}がwritethroughキャッシュ・モードです。

HALRT-02166: ディスク・ドライブ{0}はライトバック・キャッシュ・モードに戻りました。

レベル
クリア

原因: ディスク・ドライブがwritebackキャッシュ・モードに戻りました。

処置: 情報アラートなので、ユーザーによる処置は必要ありません。

HALRT-02167: HDDディスク・コントローラのバッテリは、学習サイクルを実行しています。バッテリのシリアル番号: {1} バッテリ・タイプ: {2} バッテリ温度: {3} パック: {4} 周囲温度: {5}。

レベル
情報

原因: HDDディスク・コントローラで学習サイクルが開始されました。

処置: バッテリ学習サイクルは、年に4回行われる通常の保守アクティビティで、約1時間から12時間実行されます。ほとんどの学習サイクルでwritethroughキャッシュ・モードの開始は不要です。ディスク・コントローラ・キャッシュが通常のwritebackキャッシュ・モードに戻ると、情報のアラートが送信されます。

HALRT-02168: HDDディスク・コントローラのバッテリは交換されました。すべてのディスク・ドライブがライトバック・キャッシュ・モードになっています。バッテリのシリアル番号: {1} バッテリ・タイプ: {2} バッテリ温度: {3} パック: {4} 周囲温度: {5}。

レベル
情報

原因: HDDディスク・コントローラのバッテリが交換されました。

処置: 情報アラートなので、ユーザーによる処置は必要ありません。

HALRT-02169: HDDディスク・コントローラのバッテリは交換されました。バッテリのシリアル番号: {1} バッテリ・タイプ: {2} バッテリ温度: {3} パック: {4} 周囲温度: {5}。

レベル
情報

原因: HDDディスク・コントローラのバッテリが交換されました。

処置: 情報アラートなので、ユーザーによる処置は必要ありません。

HALRT-02170: HDDディスク・コントローラのバッテリが再び差し込まれました。バッテリのシリアル番号: {1} バッテリ・タイプ: {2} バッテリ温度: {3} パック: {4} 周囲温度: {5}。

レベル
情報

原因: HDDディスク・コントローラのバッテリが差し込まれました。

処置: 情報アラートなので、ユーザーによる処置は必要ありません。

HALRT-02171: HDDディスク・コントローラのバッテリは交換されました。すべてのディスク・ドライブがライトバック・キャッシュ・モードになっています。バッテリのシリアル番号: {1} バッテリ・タイプ: {2} バッテリ温度: {3} パック: {6} 周囲温度: {5}

レベル
情報

原因: HDDディスク・コントローラのバッテリが交換されました。

処置: 情報アラートなので、ユーザーによる処置は必要ありません。

HALRT-02172: すべてのディスク・ドライブがライトバック・キャッシュ・モードになっています。バッテリのシリアル番号: {1} バッテリ・タイプ: {2} バッテリ温度: {3} パック: {6} 周囲温度: {5}。

レベル
情報

原因: HDDディスク・コントローラのバッテリが正常に戻りました。

処置: 情報アラートなので、ユーザーによる処置は必要ありません。

C.12 USBアラート・メッセージ: HALRT-02401 - HALRT-02404

これらのアラート・メッセージの範囲は、HALRT-02401からHALRT-02404です。

HALRT-02401: 内部USBステータスが低下しました。Oracleサポートに連絡してください。

レベル
クリティカル

原因: USBの機能が低下しました。

処置: Oracleサポート・サービスに問い合せてください。

HALRT-02402: 内部USBステータスが存在しません。

レベル
クリティカル

原因: USBが検出されませんでした。

処置: Oracleサポート・サービスに問い合せてください。

HALRT-02403: 内部USBステータスにエラーが発生しました。

レベル
クリティカル

原因: USBで障害が発生しました。

処置: Oracleサポート・サービスに問い合せてください。

HALRT-02404: 内部USBステータスが正常に戻りました。

レベル
情報

原因: USBが修理されました。

処置: これは情報メッセージです。

C.13 アラート・メッセージの汎用処理: HALRT-10001 - HALRT-10500

これらのメッセージは、アラート・メッセージのユーザー処理です。この処理の範囲は、HALRT-10001からHALRT-10500です。

HALRT-10001

原因: 通常のステータスに戻る場合など、ハードウェア・ステータスのエラー以外の変更が発生しました。

処置: 情報アラートなので、ユーザー処理はありません。

HALRT-10003

原因: 予定外の学習サイクルが開始されています。

処置: 予定外の学習サイクルがどのように開始されたかを調べてください。

HALRT-10004

原因: 温度が許容範囲ではありませんでした。

処置: システムを停止します。熱障害の原因を特定します。必要に応じて、このセルのデータを移動します。

HALRT-10005

原因: ファンで問題が発生しました。

処置: システムを停止します。ファン障害の原因を特定します。ファンを交換します。必要に応じて、このセルのデータを移動します。

HALRT-10007

原因: 電源で問題が発生しました。

処置: 電源を確認します。必要に応じて、電源を交換します。

HALRT-10015

原因: 温度が許容範囲ではありませんでした。

処置: 温度機能の低下を確認します。システムを停止し、このセルのデータを移動します。

HALRT-10025

原因: CPUエラーが検出されました。

処置: システムを停止します。CPUエラーを確認します。

HALRT-10029: 汎用センサーがエラーを検出しました。

原因: センサーの変更またはエラーが発生しました。

処置: センサーの状態の変更またはエラーを確認します。予想外でクリアされない場合は、Oracleサポート・サービスに問い合せてください。

HALRT-10030

原因: アラートが発生しました。

処置: アラート・メッセージの追加情報を参照してください。

HALRT-10031

原因: FRUが取り外されました。

処置: FRUが意図して削除されていない場合は、Oracleサポート・サービスに問い合せてください。

HALRT-10032

原因: エラーが発生しました。

処置: コンソールのエラー・メッセージを取得してください。システムを再起動して電源を入れ直し、元に戻します。エラー・メッセージは、Oracleサポート・サービスに問い合せてください。

HALRT-10033

原因: キャッシュが失われました。

処置: キャッシュを失うと、ディスク上のすべてのデータは失効します。Oracle ASMからこのコントローラに接続されているディスクのデータを強制的に削除してから戻します。

HALRT-10034

原因: ディスク・コントローラのファームウェアにリフレッシュが必要です。

処置: ディスク・コントローラのファームウェアをリフレッシュします。

HALRT-10035

原因: ディスク・コントローラがエラーを認識しました。

原因: ディスク・コントローラでエラーが発生しています。Oracleサポート・サービスに問い合せてください。

HALRT-10036

原因: システムが変更されました。

処置: この変更が意図したものではない場合は、Oracleサポート・サービスに問い合せてください。

HALRT-10037

原因: 動作温度がマシンの指定範囲ではありませんでした。

処置: 動作温度がマシンの指定レベルの範囲であることを確認します。

HALRT-10038

原因: バッテリが完全に充電されていません。

処置: バッテリが完全に充電されていない場合、バッテリを充電します。それ以外の場合、バッテリに障害が発生する可能性があります。ディスク・コントローラのバッテリを交換してください。

HALRT-10039

原因: 仮想ドライブのLUNで障害が発生しました。

処置: この仮想ドライブのLUNで障害が発生しました。LUNを削除して再作成してください。

HALRT-10040

原因: 物理ディスクが取り外されました。

処置: 物理ドライブが意図せずに削除された場合は、ただちにディスクを元に戻してください。

HALRT-10041

原因: システムのディスクがサポートまたは認証されませんでした。

処置: このディスクをサポートおよび認証されているディスクに交換します。

HALRT-10045

原因: フラッシュ書込みパフォーマンスが低下しました。

処置: フラッシュ・ディスク、フラッシュPCIカードまたはESMを交換する必要があります。PCIカードのすべてのディスクのパフォーマンスが低下した場合は、カードを交換してください。PCIカードのESM LEDをチェックします。セル・シャーシの背面から確認できます。このLEDが黄色の場合、カードを交換する必要があります。

注意:

このメッセージには、グリッド・ディスクがある場合にHALRT_10046メッセージ、グリッド・ディスクがなくフラッシュ・キャッシュにセル・ディスクが使用される場合にHALRT_10047メッセージの本文が含まれることがあります。

HALRT-10046

原因: ディスクでエラーが発生しました。

処置: 交換するディスクに永続データがある場合は、それらのディスクからデータをリバランスし、フラッシュ・ディスクを交換します。フラッシュ・ディスクに永続データが存在していた場合は、データをディスクの内部にリバランスします。

HALRT-10047

原因: フラッシュ・ディスクでエラーが発生しました。

処置: このフラッシュ・ディスクにより提供されたフラッシュ・キャッシュは、自動的に無効化されます。

HALRT-10054

原因: 物理ディスクが非常に低いパフォーマンスを示しました。

処置: できるだけすぐに物理ディスクを交換する必要があります。

HALRT-10056

原因: 一意の識別子が指定され、自動サービス・リクエストが通知されました。

処置: 情報アラートなので、ユーザーによる処置は必要ありません。

HALRT-10057

原因: この問題に関する詳細情報は、My Oracle Supportで見つかる可能性があります。

処置: アラートに一覧表示されているMy Oracle Supportノートを参照してください。

HALRT-10066

原因: システム・ハード・ディスクが非常に低いパフォーマンスを示しました。

処置: できるだけすぐにシステム・ハード・ディスクを交換します。

HALRT-10067

原因: データ・ハード・ディスクが非常に低いパフォーマンスを示しました。

処置: できるだけすぐにデータ・ハード・ディスクを交換します。

HALRT-10068

原因: フラッシュ・ディスクが非常に低いパフォーマンスを示しました。

処置: できるだけすぐにフラッシュ・ディスクを交換します。

HALRT-10073

原因: デバイス・モニタリング・ユーティリティから予期しない出力がありました。

処置: 問題が解決されると、解決済のアラートが送信されます。問題が解決しない場合は、Oracleサポート・サービスまでお問い合せください。

HALRT-10074

原因: フラッシュ・ディスクが取り外されているか、Oracle Exadata Storage Server Softwareに表示できなくなっています。

処置: フラッシュ・ディスクを交換した場合、このアラートは情報のみです。フラッシュ・ディスクがキャッシュとして使用されている場合、このセルのフラッシュ・キャッシュ・サイズは減っています。フラッシュ・ディスクを取り外すと、停止、データ損失、Oracle ASMリバランスが発生しません。

HALRT-10075

原因: Oracle Exadata Database Machineの温度が動作範囲外です。

処置: Oracle Exadata Database Machineの動作範囲は摂氏5から32度(華氏41から89.6度)です。データ・センターの状態を調整し、指定した範囲でOracle Exadata Database Machineが動作するようにしてください。

HALRT-10076

原因: 物理ディスクのグリッド・ディスクに関連付けられているOracle ASMディスクが正常に削除され、ディスクの取外しが安全であることを示す青色の取外しOKのLEDがディスクで点灯しています。

処置: できるだけすぐにディスク・ドライブを交換してください。

HALRT-10078

原因: 物理ディスクの取外し時に、CELLSRVによってI/Oエラーがレポートされました。

処置: ユーザーによる処置は必要ありません。その結果、この物理ディスクのグリッド・ディスクがOracle ASMでオフラインになると、Oracle ASMはディスクを自動的にオンラインにします。

HALRT-10079

原因: Exadata Storage Serverの単一のシステム・ディスクに有効なパーティションがありません。

処置: Oracleサポート・サービスに問い合せてください。

HALRT-10080

原因: ディスクが間違ったスロットに挿入されています。

処置: ディスクを正しいスロットに挿入してください。

HALRT-10081

原因: ハード・ディスクのパフォーマンスが一時的に低下しています。ディスクは制限され、オフライン状態になっています。

処置: ハード・ディスクをグリッド・ディスクに使用している場合、このハード・ディスクのグリッド・ディスクに関連するOracle ASMディスクがオフラインにされます。このディスクに対して制限テストが実行され、ディスクが恒久的にpoor performanceになるか、ディスクがnormal状態に戻ります。

HALRT-10082

原因: フラッシュ・ディスクのパフォーマンスが一時的に低下しています。ディスクは制限され、オフライン状態になっています。

処置: 次のいずれかの処置が実行されます。

- フラッシュ・ディスクをwritethroughフラッシュ・キャッシュに使用している場合、このディスクでフラッシュ・キャッシュが無効になり、有効なフラッシュ・キャッシュ・サイズが縮小します。

- フラッシュ・ディスクをwritebackフラッシュ・キャッシュに使用している場合、このディスクのフラッシュ・キャッシュが無効になり、フラッシュ・キャッシュ内のダーティ・データに対する読取りI/Oが別のセルのミラー・ディスクを対象とするようになります。書込みI/Oはこのセルのグリッド・ディスクを直接対象とします。

- フラッシュ・ディスクをフラッシュ・ログに使用している場合、このディスクでフラッシュ・ログが無効になり、有効なフラッシュ・ログ・サイズが縮小します。

- フラッシュ・ディスクをグリッド・ディスクに使用している場合、このフラッシュ・ディスクのグリッド・ディスクに関連するOracle ASMディスクがオフラインにされます。

このディスクに対して制限テストが実行され、ディスクが恒久的にpoor performanceになるか、ディスクがnormal状態に戻ります。

HALRT-10086

原因: フラッシュ・ディスクがpeer failureステータスになりました。白色のセル・ロケータLEDが点灯しており、影響を受けているセルを特定できます。

処置: すべてのデータがリバランスされ、フラッシュ・ディスクからフラッシュされている場合は、別のアラートが送信されます。リバランスおよびフラッシュ操作が完了し、白色のLEDで示されるフラッシュ・ディスクを交換するまで待機してください。

HALRT-10087

原因: このディスクのデータが正常にリバランスおよびフラッシュされています。

処置: ドライブを交換してください。

C.14 アラート・メッセージの汎用処理: HALRT-10503 - HALRT-11000

これらのメッセージは、アラート・メッセージのユーザー処理です。この処理の範囲は、HALRT-10503からHALRT-11000です。

HALRT-10503

原因: HDDディスク・コントローラで問題が発生しました。

処置: HDDディスク・コントローラのバッテリを交換する必要があります。Oracleサポート・サービスに問い合せてください。

HALRT-10504

原因: バッテリがライトスルー・キャッシュ・モードでした。

処置: HDDディスク・コントローラのバッテリは良好ですが、論理ドライブがライトスルー・キャッシュ・モードです。Oracleサポートに連絡してください。

HALRT-10505

原因: ディスク・コントローラのバッテリが学習サイクルを完了しました。

処置: ディスク・コントローラのバッテリは正常な状態に戻っていますが、ディスク・ドライブがwritethroughキャッシュ・モードです。Oracleサポート・サービスに問い合せてください。

HALRT-10506

原因: ディスク・ドライブがwritebackキャッシュ・モードになりました。

処置: ディスク・ドライブがwritebackキャッシュ・モードです。処理は不要です。

HALRT-10507

原因: すべての論理ドライブがライトスルー・キャッシュ・モードでした。

処置: ディスク・コントローラのバッテリは良好ですが、すべての論理ドライブがライトスルー・キャッシュ・モードです。Oracleサポート・サービスに問い合せてください。

HALRT-10510

原因: ディスク・コントローラのキャッシュの内容が失われました。

処置: ディスク・コントローラのキャッシュの内容が失われ、最近の書込み操作の一部が失われる可能性があります。このセルのグリッド・ディスクへのアクセスが無効になっています。ユーザーが開始したオフラインのディスクとの競合を回避したり、リカバリ中の強制削除を回避するため、セルに対してOracle Exadata Storage Server Softwareのディスク自動管理が無効になっています。この問題に関連しないセルの自動管理には影響しません。Oracleサポート・サービスに問い合せてください。

HALRT-10511

原因: 新しいバッテリが充電中です。

処置: 新しいバッテリが自動的に充電されています。バッテリの充電が完了すると、ディスク・ドライブはwritebackキャッシュ・モードになります。情報メッセージなので、処置は必要ありません。

HALRT-10512

原因: ディスク・コントローラのバッテリが過熱しています。

処置: ディスク・コントローラのバッテリが過熱しています。周囲温度が32℃を下回っているかどうか、およびファンが動作しているかどうかを確認してください。

HALRT-10513

原因: ディスク・コントローラのバッテリが動作していません。

処置: ディスク・コントローラのバッテリの交換が必要です。

C.15 アラート・メッセージの汎用処理: HALRT-11001 - HALRT-11100

これらのメッセージは、アラート・メッセージのユーザー処理です。この処理の範囲は、HALRT-11001からHALRT-11100です。

HALRT-11001

原因: Infiniband構成で問題が発生しました。

処置: ibstatusを使用してInfiniBand構成を確認し、両方のポートの状態がACTIVEで、期待するレート(GB/秒)になっていることを検証します。ポートの状態がACTIVEになると、アラートが解除されます。低いリンク・レートにネゴシエーションを行うInfiniBandリンクの一般的な原因の1つとして、HCAまたはスイッチのInfiniBandケーブル・コネクタが緩いことが考えられます。通常、InfiniBandコネクタがHCAおよびスイッチにしっかりと取り付けられていることを確認すれば、この問題は解決します。

スイッチの再起動後に、ポートの状態がDOWNを示す場合があります。数分後に、ポートは自動的にACTIVEになります。

HALRT-11002

原因: InfiniBandポートで問題が発生しました。

処置: CellCLIコマンドLIST IBPORT DETAILを使用してポートをチェックします。両方のポートについてrcvErrsとsymbolErrsのエラー数が0であるかどうか確認します。エラー数が0以外の場合、不良ケーブルが原因か、または正しく装着されていないケーブルが原因である可能性があります。HCAまたはスイッチの不良ポートが原因である可能性もあります。手動によるInfiniBandポートの有効化および無効化またはInfiniBandスイッチのリセットでも、これらのエラーが発生する可能性があります。この問題を修正してから、CellCLIコマンドALTER IBPORT...RESETを使用してInfiniBandエラー数をリセットします。HCAポートおよびピア・スイッチ・ポートの両方で、エラー数をリセットする必要があります。

HALRT-11003

原因: InfiniBandポートで問題が発生しました。

処置: CellCLIコマンドLIST IBPORT DETAILを使用してポートをチェックします。両方のポートが予期する速度(GB/秒)であることを検証します。低いリンク・レートにネゴシエーションを行うInfinibandリンクの一般的な原因として、HCAまたはスイッチのInfiniBandケーブル・コネクタが緩いことが考えられます。通常、InfiniBandコネクタがHCAおよびスイッチにしっかりと取り付けられていることを確認すれば、この問題は解決します。

C.16 Oracle Exadata Database Machineコマンドライン・インタフェース・エラー・メッセージ

この項では、Oracle Exadata Database Machineのエラー・メッセージのカテゴリについて説明します。カテゴリは次のとおりです。

- エラー・メッセージ: DBM-00001からDBM-00500

- エラー・メッセージ: DBM-10001からDBM-10500

C.16.1 エラー・メッセージ: DBM-00001 - DBM-00500

これらのメッセージの範囲は、DBM-00001からDBM-00500です。

DBM-00050: SNMP V3 ASRサブスクリプションは、snmpUserディレクティブでauthProtocol SHAとprivProtocol AESを指定する必要があります。ASRは、これらのプロトコルのみをサポートしています。

原因: ASRサブスクリプションでディレクティブとプロトコルが指定されませんでした。

処置: snmpUserディレクティブを修正し、authProtocolおよびprivProtocolのプロトコル値を正しく指定してください。

DBM-00051: SNMP V3ユーザー定義{0}に、authProtocolとauthPasswordを含める必要があります。

原因: ユーザー定義にauthProtocolおよびauthPasswordが含まれていませんでした。

処置: SNMPユーザーを定義するコマンドを入力し、authProtocolおよびauthPasswordを指定してください。

DBM-00052: SNMP V3ユーザー定義 {0} 認証パスワードは、8文字から12文字の半角英数文字を含む必要があります。プライバシ保護パスワードは、8文字の半角英数文字です。

原因: パスワードに正しい文字数が含まれていませんでした。

処置: 正しい文字数が含まれるパスワードを入力してください。SNMP V3パスワードには、最小限8文字かつ最大限12文字の英数字が含まれる必要があります。暗号化パスワードには、正確に8文字の英数字が含まれる必要があります。

DBM-00053: SNMP V3ユーザー定義{0}が、複数回定義されました。

原因: ユーザー定義はすでに定義されていました。

処置: 新しいユーザーを定義してください。

DBM-00054: SNMP V3ユーザー定義{0}に、privProtocolは含まれていますが、privPasswordは含まれていません。

原因: ユーザー定義にパスワードが含まれていませんでした。

処置: 定義を入力し、パスワードを含めてください。

DBM-00055: SNMP V3ユーザー定義{0}を削除できまん。SNMP V3サブスクリプションで参照されています。

原因: 定義を削除できませんでした。

処置: サブスクリプションを削除した後、コマンドを再入力してください。

DBM-00056: SNMP V3 snmpUser定義は、タイプV3またはV3ASRのサブスクリプションのみで使用できます。

原因: ユーザー定義にタイプが指定されていませんでした。

処置: 定義を入力し、サブスクリプション・タイプV3またはv3ASRを指定してください。

DBM-00057: 無効なプロトコルが{0}に指定されました。このプロトコルの値は、{1}または{2}です。

原因: 無効なプロトコルが指定されました。

処置: 正しいプロトコル値を指定して、コマンドを再入力してください。

DBM-00058: 繰り返されている属性が指定するディレクティブに含まれています: {0}。各ディレクティブでは、属性は1回の発生が許可されています。

原因: ディレクティブ内で属性が繰り返されました。

処置: コマンドを入力し、各属性を1回のみ指定してください。

DBM-00059: snmpSubcriberディレクティブに無効なタイプが含まれます。タイプASR、V3およびV3ASRのみがサポートされています。デフォルトのタイプはV1です。

原因: snmpSubscriberディレクティブに無効タイプが含まれていました。

処置: コマンドを入力し、有効なタイプを指定してください。有効なタイプは、ASR、V3およびv3ASRです。

DBM-00060: SNMP V3ユーザー定義{0}に、privPasswordは含まれていますが、privProtocolは含まれていません。

原因: ユーザー定義にプロトコルが含まれていませんでした。

処置: コマンドを入力し、プロトコルを指定してください。

DBM-00061: SNMP V3サブスクリプションで、SNMPユーザーを定義する必要があります。このユーザーは、snmpSubscriber属性に割り当てられたsnmpUserディレクティブが使用する名前で参照されます。

原因: snmpSubscriberにはV3またはv3ASRタイプが指定されていましたが、snmpUser属性が含まれていませんでした。

処置: コマンドを再入力し、定義内にsnmpUserを含めるか、V3を指定しないようsnmpSubscriberのタイプを変更してください。

DBM-00062: SNMPサブスクリプションはSNMPユーザー{0}を参照していますが、ユーザーが定義されていません。snmpUser属性の割当てを使用して、ユーザーを定義する必要があります。

原因: サブスクリプションで参照されているSNMPユーザーが定義されていません。

処置: サブスクリプションのユーザーを定義してください。

DBM-00063: SNMPユーザー名が無効です。正しくは、1から32文字の半角英数文字です。

原因: 無効なユーザー名が入力されました。

処置: 1から32文字の英数字を使用してユーザー名を入力してください。

DBM-00064: ILOM上で起動アクティビティが競合しているため、現在、この操作は実行できません。このコマンドを数分後に再入力してください。

原因: アクティビティが競合していました。

処置: 数分後にコマンドを再入力してください。

DBM-00065: このSNMPエンジンのIDを変更すると、既存のSNMPユーザーの定義が無効になります。ALTERコマンドを使用してSNMPユーザーを削除し、SNMPエンジンを変更してください。SNMPユーザー定義をもう1度作成する必要があります。

原因: エンジンIDの変更が既存のユーザー定義に起因せずに実行されました。

処置: SNMPユーザーを削除し、SNMPエンジンIDを変更してから、ユーザー定義を再作成してください。

C.16.2 エラー・メッセージ: DBM-10001 - DBM-10500

これらのメッセージの範囲は、DBM-00001からDBM-00500です。

DBM-10001: 無効な数値がpendingCoreCount属性に指定されました。有効な数値をX4-2アクティブ・コアに指定してください。(12、14、16、18、20、22、24)

原因: ペンディング・コアに指定された数値が正しくありませんでした。

処置: 有効な数値を使用してコマンドを入力してください。

DBM-10002: 無効な数値がpendingCoreCount属性に指定されました。有効な数値をX4-8アクティブ・コアに指定してください。(64、72、80、88、96、104、112、120)

原因: ペンディング・コアに指定された数値が正しくありませんでした。

処置: 有効な数値を使用してコマンドを入力してください。

DBM-10003: 無効な数値がpendingCoreCount属性に指定されました。有効な数値をX5-2アクティブ・コアに指定してください。(12、14、16、18、20、22、24、26、28、30、32、34、36)

原因: ペンディング・コアに指定された数値が正しくありませんでした。

処置: 有効な数値を使用してコマンドを入力してください。

DBM-10004: アクティブ・コア数の減少はサポートされていません。

原因: アクティブ・コア数が、既存のアクティブ・コア数より小さい数値に指定されました。

処置: 大きい数値を使用してコマンドを入力してください。

DBM-10005: アクティブ・コア数の変更に失敗しました。

原因: アクティブ・コア数が変更されませんでした。

処置: コマンドを再試行してください。コマンドが正常に終了しない場合、Oracleサポート・サービスに連絡してください。

DBM-10006: pendingCoreCountは、X4-2、X4-8またはX5-2でのみ変更できます。

原因: このラックではactiveCoreCount属性を使用できませんでした。

処置: Oracle Exadata Database Machine X4-2以上のシステムが、キャパシティ・オンデマンドをサポートしています。

DBM-10007: pendingCoreCount属性を変更できません。iaasModeがオンになっています。

原因: iassModeがオンに設定されていたため、属性が変更されませんでした。

処置: iaasMode属性をoffに設定してから、pendingCoreCount属性を変更してください。

DBM-10008: iaasReason属性に無効な設定が指定されています。有効な設定を指定してください。(expansion、test、HA)

原因: 無効な設定が指定されました。

処置: 有効な設定を使用してコマンドを入力してください。有効な設定は、expansion、testおよびHAです。

DBM-10009: 属性{0}は、X4-2、X4-8またはX5-2でのみ変更できます。

原因: このラックではこの属性を使用できませんでした。

処置: Oracle Exadata Database Machine X3-2以上のシステムが、IaaS (Infrastructure as a Service)をサポートしています。

DBM-10010: IaaSの有効化に失敗しました。

原因: エラーのため、IaaSを有効にできませんでした。

処置: コマンドを再入力しください。

DBM-10011: IaaSの無効化に失敗しました。

原因: エラーのため、IaaSを無効にできませんでした。

処置: コマンドを再入力しください。

DBM-10012: IaaS設定を変更できません。すべてのコアがアクティブではありません。

原因: 物理コアがすべてアクティブではありません。

処置: iaasMode属性は、すべての物理コアがアクティブな場合に使用できます。コアをアクティブ化してから、属性を設定してください。

DBM-10013: iaasReason属性を変更できるのは、iaasIdleInUse属性がTRUEに設定されている場合のみです。

原因: iaasReason属性を変更できませんでした。

処置: iaasReason属性は、iaasIdleInUse属性がtrueに指定されている場合に設定されます。iaasReason属性を変更するには、iaasIdleInUse属性を無効にし、別のiaasReason属性を指定して再び有効にします。

DBM-10014: iaasReason属性が、iaasIdleInUseをTRUEに設定するように指定されています。

原因: iaasIdleInUse属性の設定の際に、iaasReason属性が指定されませんでした。

処置: iaasReason属性を指定して、コマンドを入力してください。有効な設定は、expansion、testおよびHAです。

DBM-10015: IaaS設定を変更できません。BIOSおよびILOMが同期されていません。システムを再起動してコマンドを再実行してください。

原因: BIOSとILOMの同期がとれていません。

処置: システムを再起動し、コマンドを実行してください。

DBM-10016: IaaSは有効ではありません。iaasReason属性の設定を指定する必要はありません。

原因: IaaSがシステムに対して有効ではないため、iaasReason属性を指定する必要はありません。

処置: このメッセージは情報提供用です。処理は不要です。

DBM-10017: iaasModeがオンでなないため、iaasIdleInUse属性を変更できません。

原因: iassModeがONに設定されていなかったため、属性が変更されませんでした。

処置: iaasMode属性をonに設定してから、iaasIdleInUse属性を設定してください。

DBM-10018: iaasMode属性に無効な設定が指定されています。有効な設定を指定してください。(on、off)

原因: 属性に無効な設定が指定されています。

処置: iaasReason属性を指定して、コマンドを入力してください。有効な設定は、ONおよびOFFです。

DBM-10019: iaasMode属性の変更に失敗しました。

原因: エラーのため、iaasIdleInUse属性を変更できませんでした。

処置: コマンドを再入力しください。

DBM-10020: iaasMode属性とpendingCoreCount属性は同時に変更できません。

原因: 属性が同時に指定されました。

処置: 別々のコマンドを使用してそれぞれの属性を指定してください。

C.17 Oracleサポート・サービスへの連絡

一部のメッセージについては、Oracleサポート・サービスに問題を報告することをお薦めします。自動サービス・リクエストによって発行されたサービス・リクエストがある場合は、Oracleサポート・サービスにも連絡する必要があります。Oracleサポート・サービスに連絡する場合は、次の情報を用意してください。

- ハードウェア、オペレーティング・システムおよびOracle Databaseを実行しているオペレーティング・システムのリリース番号。

- リリース11.2.0.1.0などのOracle Databaseの完全なリリース番号。

- SQL*Plusリリース11.2.0.1.0など、エラーが発生した場合に使用されるすべてのOracleプログラム(リリース番号を含む)。

- 複数のエラー・コードまたはメッセージが検出された場合の表示順の正確なコード番号およびメッセージ・テキスト。

- 次の規約に従った問題の重大度。

- 1: プログラムが使用できません。操作に重大な影響を与えます。

- 2: プログラムは使用できます。操作が大幅に制限されます。

- 3: 機能が制限されて使用できるプログラム。全体の操作に重大な影響はありません。

- 4: お客様によって回避された問題。発生しても操作への影響は最小限です。

次の項目も必要です。

- 名前

- 連絡者の組織の名前

- 連絡者のOracle Support ID番号

- 電話番号

- ラック・マスター・シリアル番号

索引

A  B  C  D  E  F  G  H  I  K  L  M  N  O  P  Q  R  S  T  U  V  W  X  Y

A

- アクティブ・コア 1

- 管理コマンド

- DBMCLI 1

- ALERTDEFINITIONオブジェクト・タイプ

- 属性 1

- ALERTHISTORYオブジェクト・タイプ

- 属性 1

- アラート・メッセージ

- バッテリ学習サイクル 1

- HALRT-00002 - HALRT-00500 1

- HALRT-00513 - HALRT-00600 1

- HALRT-00616 - HALRT-00700 1

- HALRT-00717 - HALRT-00800 1

- HALRT-00912 - HALRT-01000 1

- HALRT-01015 - HALRT-01200 1

- HALRT-01209 - HALRT-01300 1

- HALRT-01301 - HALRT-01400 1

- HALRT-02001 - HALRT-02008 1

- HALRT-02101 - HALRT-02200 1

- HALRT-02401 - HALRT-02404 1

- HALRT-10001 - HALRT-10500 1

- HALRT-10503 - HALRT-11000 1

- HALRT-11001 - HALRT-11100 1

- ハードウェア 1

- アラート通知 1

- アラート

- 通知の構成 1

- ALTER ALERTHISTORY DBMCLIコマンド 1

- ALTER DBMCLIコマンド 1

- ALTER DBSERVER DBMCLIコマンド 1

- ALTER IBPORT DBMCLIコマンド 1

- 変更

- データベース・サーバー属性 1

- ALTER THRESHOLD DBMCLIコマンド 1

- ALTER USER DBMCLIコマンド 1

- 周囲温度範囲 1

- ASR

- 概要 1

- 属性

- ALERTDEFINITIONオブジェクト・タイプ 1

- 変更 1

- データベース・サーバー・オブジェクト 1

- DBSERVERオブジェクト・タイプ 1

- LISTコマンドを使用したフィルタ処理 1

- IBPORTオブジェクト・タイプ 1

- LUNオブジェクト・タイプ 1

- METRICCURRENTオブジェクト・タイプ 1

- METRICDEFINITIONオブジェクト・タイプ 1

- METRICHISTORYオブジェクト・タイプ 1

- PHYSICALDISKオブジェクト・タイプ 1

- 値の制限 1

- syslogconf 1

- THRESHOLDオブジェクト・タイプ 1

- USERオブジェクト・タイプ 1

- 自動診断リポジトリ(ADR)

- アラート表示 1

- 定義 1

- 自動サービス・リクエスト

- 「ASR」を参照

B

- ベースボード管理コントローラ(BMC) 1 , 2

- バッテリ

- 学習サイクル 1

- 寿命 1

- 監視 1

- 交換 1

- ディスク・コントローラBBUの交換 1

- BMC

- 「ベースボード管理コントローラ」を参照

- BONDETH0 1

- BONDIB0 1

C

- CALIBRATEコマンド 1

- キャパシティ・オンデマンド 1

- CELLBOOT USBフラッシュ・ドライブ 1

- 認定規格に対するコンプライアンス 1

- 変更

- IPアドレス 1

- Exadata Storage Serverでのネットワーク設定 1

- リバランス・ステータスのチェック 1

- Ciscoイーサネット

- NTPサーバーの設定 1

- Ciscoスイッチ

- パスワードの設定 1

- Oracle Databaseホームのクローニング

- Linuxベースのサーバー 1

- Oracle Grid Infrastructureのクローニング

- Linuxベースのサーバー 1

- クラスタ検証ユーティリティ 1

- コマンドライン編集

- DBMCLI 1

- コマンド

- 管理 1

- オブジェクト 1

- コメント属性

- 制限 1 , 2

- スクリプトのコメント

- DBMCLI 1

- 法令順守 1

- RoHS((コロン))Y 1

- RoHS((コロン))YL 1

- 構成ファイル

- Linux用ntp.confファイル 1

- 構成

- レスキュー後のエイス・ラック 1

- データベース・サーバーのメール 1

- データベース・サーバーでのネットワーク・ルーティング 1

- CREATE DBMCLIコマンド 1

- CREATE DBSERVER DBMCLIコマンド 1

- CREATE DIAGPACK DBMCLIコマンド 1

- CREATE ROLE DBMCLIコマンド 1

- CREATE THRESHOLD DBMCLIコマンド 1

- CREATE USER DBMCLIコマンド 1

D

- Database Machineコマンドライン・インタフェース

- 管理コマンド 1

- コマンドライン編集 1

- スクリプトのコメント 1

- 入力および出力オプション 1

- 行継続文字 1

- オブジェクト属性 1

- オブジェクト・コマンド 1

- オブジェクト・タイプ 1

- 概要 1

- 予約語 1

- 起動 1

- 構文 1

- データベース・サーバーのメトリック 1

- データベース・サーバー

- メールの構成 1

- 属性の変更 1

- yumリポジトリの準備 1

- エイス・ラックのOracle Linuxデータベース・サーバーの再構成 1

- Linuxベースのサーバーのリカバリ 1

- サービスの再起動 1

- サービスの停止 1

- サービスの起動 1

- 更新 1

- メールの検証 1

- SNMPの検証 1

- DBMCLIコマンド

- ALTER 1

- ALTER ALTERHISTORY 1

- ALTER DBSERVER 1

- ALTER IBPORT 1

- ALTER THRESHOLD 1

- ALTER USER 1

- CREATE 1

- CREATE DBSERVER 1

- CREATE DIAGPACK 1

- CREATE ROLE 1

- CREATE THRESHOLD 1

- CREATE USER 1

- DESCRIBE ALERTDEFINITION 1

- DESCRIBE ALERTHISTORY 1

- DESCRIBE DBSERVER 1

- DESCRIBE IBPORT 1

- DESCRIBE LUN 1

- DESCRIBE METRICCURRENT 1

- DESCRIBE METRICDEFINITION 1

- DESCRIBE METRICHISTORY 1

- DESCRIBE PHYSICALDISK 1

- DESCRIBE ROLE 1

- DESCRIBE THRESHOLD 1

- DESCRIBE USER 1

- DROP ALERTHISTORY 1

- DROP DBSERVER 1

- DROP ROLE 1

- DROP THRESHOLD 1

- DROP USER 1

- GRANT 1

- GRANT PRIVILEGE 1

- GRANT ROLE 1

- HELP 1

- LIST ALERTDEFINITION 1

- LIST ALERTHISTORY 1

- LIST DBSERVER 1

- LIST DIAGPACK 1

- LIST IBPORT 1

- LIST LUN 1

- LIST METRICCURRENT 1

- LIST METRICDEFINITION 1

- LIST METRICHISTORY 1

- LIST PHYSICALDISK 1

- LIST ROLE 1

- LIST THRESHOLD 1

- LIST USER 1

- REVOKE 1

- REVOKE PRIVILEGE 1

- REVOKE ROLE 1

- SET 1

- START 1

- dbnodeupdate.shユーティリティ 1 , 2 , 3 , 4 , 5

- DBSERVERオブジェクト・タイプ

- 属性 1

- DESCRIBE ALERTDEFINITION DBMCLIコマンド 1

- DESCRIBE ALERTHISTORY DBMCLIコマンド 1

- DESCRIBE DBSERVER DBMCLIコマンド 1

- DESCRIBE IBPORT DBMCLIコマンド 1

- DESCRIBE LUN DBMCLIコマンド 1

- DESCRIBE METRICCURRENT DBMCLIコマンド 1

- DESCRIBE METRICDEFINITION DBMCLIコマンド 1

- DESCRIBE METRICHISTORY DBMCLIコマンド 1

- DESCRIBE PHYSICALDISK DBMCLIコマンド 1

- DESCRIBE ROLE DBMCLIコマンド 1

- DESCRIBE THRESHOLD DBMCLIコマンド 1

- DESCRIBE USER DBMCLIコマンド 1

- 無効

- ライトバック・フラッシュ・キャッシュ 1

- ディスク・コントローラのバッテリBBU 1

- ディスク・コントローラ 1

- ディスク障害

- 物理ディスクの交換 1

- 表示

- 現在のメトリック 1

- LUN 1

- メトリック定義 1 , 2

- メトリック履歴 1

- 物理ディスク 1

- DNS

- 設定の変更 1

- DROP ALERTHISTORY DBMCLIコマンド 1

- DROP DBSERVER DBMCLIコマンド 1

- DROP ROLE DBMCLIコマンド 1

- DROP THRESHOLD DBMCLIコマンド 1

- DROP USER DBMCLIコマンド 1

E

- e2fsckコマンド 1

- 有効

- ライトバック・フラッシュ・キャッシュ 1

- エネルギー・ストレージ・モジュール

- 寿命 1

- 交換 1

- 稼働時間のリセット 1 , 2

- エラー・メッセージ

- Oracleサポート・サービスへの連絡 1

- ESM

- 「エネルギー・ストレージ・モジュール」を参照

- exadata.img.domu_makerコマンド 1

- examinedBy属性

- ALERTHISTORY 1

- 拡張

- 論理ボリューム 1

F

- F20 PCIeカード 1

- FDOM 1

- ファイル削除のポリシー 1

- ファームウェアのレベル 1 , 2

- フラッシュ・デバイス 1

- フラッシュ・ディスク 1

- ライトスルー・キャッシュ 1

G

- GRANT DBMCLIコマンド 1

- GRANT PRIVILEGE DBMCLIコマンド 1

- GRANT ROLE DBMCLIコマンド 1

- グリッド・ディスク

- サイズの変更 1

H

- HALRT-00002 - HALRT-00500アラート・メッセージ 1

- HALRT-00513 - HALRT-00600アラート・メッセージ 1

- HALRT-00616 - HALRT-00700アラート・メッセージ 1

- HALRT-00717 - HALRT-00800アラート・メッセージ 1

- HALRT-00912 - HALRT-01000アラート・メッセージ 1

- HALRT-01015 - HALRT-01100アラート・メッセージ 1

- HALRT-01209 - HALRT-01300アラート・メッセージ 1

- HALRT-01301 - HALRT-01400アラート・メッセージ 1

- HALRT-02001 - HALRT-02008アラート・メッセージ 1

- HALRT-02101 - HALRT-02200アラート・メッセージ 1

- HALRT-10001 - HALRT-10500アラート・メッセージ 1

- HALRT-10503 - HALRT-11000アラート・メッセージ 1

- HALRT-11001 - HALRT-11100アラート・メッセージ 1

- ハードウェア・アラート・メッセージ 1

- ヘルス・チェック・ユーティリティ 1

- HELP DBMCLIコマンド 1

- ハイフン

- 行継続文字 1

I

- IB0 1

- IB1 1

- IBPORTオブジェクト・タイプ

- 属性 1

- 識別

- 低いパフォーマンス 1

- 不良物理ディスク 1

- 欠落しているケーブル 1

- 低いパフォーマンスのフラッシュ・ディスク 1

- 予測障害フラッシュ・ディスク 1

- ILOM

- ルール・リスト 1 , 2

- imageinfoコマンド 1

- イメージ化

- Linuxベースのデータベース・サーバー 1

- アクティブ・コアの増加 1

- InfiniBand

- ボンディング名 1

- インタフェース 1

- スイッチのタイムゾーン 1

- スイッチのアップグレード 1

- 入力および出力オプション

- DBMCLI 1

- IPアドレス

- 変更 1

- ipconfユーティリティ 1 , 2

- IPMItool

- サービス・プロセッサのリセット 1

- ISOイメージ 1

- ダウンロード 1

K

- KVM

- サーバーへアクセス 1

- 構成 1

L

- リーフ・スイッチ 1

- LEDステータス 1

- levatorコマンド 1

- 行継続文字

- DBMCLI 1

- LIST ALERTDEFINITION DBMCLIコマンド 1

- LIST ALERTHISTORY DBMCLIコマンド 1

- LIST DBSERVER DBMCLIコマンド 1

- LIST DIAGPACK DBMCLIコマンド 1

- LIST IBPORT DBMCLIコマンド 1

- PCIスロット番号の一覧 1

- LIST LUN DBMCLIコマンド 1

- LIST METRICCURRENT DBMCLIコマンド 1

- LIST METRICDEFINITION DBMCLIコマンド 1

- LIST METRICHISTORY DBMCLIコマンド 1

- LIST PHYSICALDISK DBMCLIコマンド 1

- LIST ROLE DBMCLIコマンド 1

- LIST THRESHOLD DBMCLIコマンド 1

- LIST USER DBMCLIコマンド 1

- ローカルULNミラー 1

- 作成 1

- 確認 1

- 検索

- NEM検出LED 1 , 2

- サービス・プロセッサのシャーシのLED 1 , 2 , 3 , 4

- 論理ボリューム・マネージャ 1

- LUNオブジェクト・タイプ

- 属性 1

- LUN

- 情報の表示 1

- lvextendコマンド 1 , 2

- lvsコマンド 1 , 2

M

- メール

- データベース・サーバーでの構成 1

- データベース・サーバーでの検証 1

- メモリー拡張キット 1

- METRICCURRENTオブジェクト・タイプ

- 属性 1

- METRICDEFINITIONオブジェクト・タイプ

- 属性 1

- メトリック定義

- 表示 1 , 2

- メトリック履歴

- 表示 1

- 保存期間 1 , 2

- METRICHISTORYオブジェクト・タイプ

- 属性 1

- メトリック名 1

- メトリック

- 概要 1

- データベース・サーバー 1

- 説明 1

- 現在の表示 1

- 定義の表示 1 , 2

- 履歴の表示 1

- 名前 1

- 省略語 1

- ミラー化 1

- mkswapコマンド 1

- 変更

- データベース・サーバー属性 1

- ドライブの移動 1

- MTUサイズ 1

N

- name属性

- METRICDEFINITION 1

- 制限 1 , 2

- ネットワーク・ルーティング表 1

- ネットワーク・タイム・プロトコル 1

- ntp.confファイル

- Linuxの場合 1

- NTPサーバー

- ストレージ・セル 1

- NTPサーバー 1

O

- オブジェクト属性

- DBMCLI 1

- オブジェクト・タイプ

- ALERTHISTORY 1

- ALTERDEFINITION 1

- DBMCLI 1

- DBSERVER 1

- IBPORT 1

- LUN 1

- METRICCURRENT 1

- METRICDEFINITION 1

- METRICHISTORY 1

- PHYSICALDISK 1

- THRESHOLD 1

- USER 1

- オンライン更新 1

- Oracle Exadata Database Machine HealthCheckユーティリティ 1

- Oracle Maximum Availability Architecture 1

- Oracleサポート・サービス

- 連絡 1

- Oracle VM

- 概要 1

- 新規LVMディスクの追加 1

- ユーザー・ドメイン・コンソールへ接続 1

- 作成

- クラスタ 1

- 新規ディスク・イメージ 1

- 仮想CPU設定の判別 1

- 自動起動の無効化 1

- ディスク・イメージ・ファイルの場所 1

- e2fsckコマンド 1

- exadata.img.domu_makerコマンド 1

- UUIDの生成 1

- 増加

- /u01ファイル・システム 1

- ディスク領域 1

- ルート・ファイル・システム 1

- スワップ領域 1

- lvcreateコマンド 1

- lvextendコマンド 1 , 2

- lvsコマンド 1 , 2

- mkswapコマンド 1

- 変更

- メモリー割当て 1

- 仮想CPU 1

- ユーザー・ドメインの監視 1

- ユーザー・ドメインの移動 1

- qemu-imgコマンド 1

- 単一クラスタの削除 1

- クラスタの削除 1

- resize2fsコマンド 1 , 2 , 3

- ユーザー・ドメインの表示 1

- ユーザー・ドメインの停止 1 , 2

- ユーザー・ドメインの起動 1

- swaponコマンド 1

- vgdisplayコマンド 1 , 2 , 3

- xm listコマンド 1

P

- パスワード

- 変更

- Ciscoイーサネットのパスワード 1

- データベース・サーバーのパスワード 1

- Exadata Storage Serverのパスワード 1

- ILOMパスワード 1

- InfiniBandスイッチのパスワード 1

- KVMパスワード 1

- PDUパスワード 1

- patchmgr

- 構文 1

- PCIeカード 1

- 充電容量 1

- LED 1

- フラッシュ・エネルギー・ストレージ・モジュールの交換 1

- PCIスロット番号 1

- PDU

- 交換 1

- PHYSICALDISKオブジェクト・タイプ

- 属性 1

- 物理ディスク

- 表示 1

- セルの削除 1

- エラーによる取外し 1

- 交換 1 , 2

- 再利用 1

- ステータス 1

- ポート

- physicalPort 1

- 電源切断

- Oracle Database Server 1

- Oracle Exadata Storage Server 1

- 電源切断

- 緊急時 1

- 順序 1

- スイッチ 1

- 電源投入

- サーバーの手順 1

- ILOMの使用 1

- 予測障害 1

Q

- qemu-imgコマンド 1

- quorumディスク

- 交換 1

R

- リバランス・ステータス 1

- リバランス 1

- エイス・ラックの再構成 1

- エイス・ラックのストレージ・サーバーの再構成 1

- リカバリ

- Linuxベースのデータベース・サーバー 1

- 再作成

- CELLBOOT USBフラッシュ・ドライブ 1

- 論理ボリュームのサイズの縮小 1

- 冗長性 1

- 拒否されたディスクの再有効化 1

- 法規制に対するコンプライアンス 1

- 投票ディスクの移動

- Linuxベースのサーバー 1

- エラーのあるディスクの取外し 1

- ストレージ・セルの削除 1

- 修理カテゴリ 1

- 置換

- ディスク・コントローラBBU 1

- エネルギー・ストレージ・モジュール 1

- PDU 1

- 物理ディスク 1 , 2

- スパイン・スイッチ 1

- quorumディスクの交換 1

- ディスクの再利用 1

- フラッシュ・ドライブのレスキュー 1

- 予約語

- DBMCLIの予約 1

- リセット

- ILOM 1

- resize2fsコマンド 1 , 2 , 3

- サイズの変更

- グリッド・ディスク 1

- LVMパーティションのサイズ変更 1

- dfコマンド 1 , 2

- lvextendコマンド 1 , 2 , 3

- lvreduceコマンド 1

- lvsコマンド 1 , 2

- resize2fsコマンド 1 , 2

- tune2fsコマンド 1 , 2

- vgdisplayコマンド 1

- resourceControl.shスクリプト

- アクティブ・コアの増加 1

- データベース・サーバーでのサービスの再起動 1

- REVOKE DBMCLIコマンド 1

- REVOKE PRIVILEGE DBMCLIコマンド 1

- REVOKE ROLE DBMCLIコマンド 1

- RoHS((コロン))Yの準拠 1

- RoHS((コロン))YLの準拠 1

- ルーティング表 1

- rpmパッケージ

- Exact依存性 1

- Minimum依存性 1

S

- スクリプト・ファイル

- コメント 1

- 行継続文字 1

- DBMCLIでの実行 1

- スクリプト

- drop_griddisk.sh 1

- list_griddisk.sh 1

- SET DBMCLIコマンド 1

- 設定

- バッテリ学習サイクル 1

- Ciscoイーサネット

- NTPサーバー 1

- InfiniBand

- スイッチの日付 1

- スイッチのタイムゾーン 1

- shutdownコマンド 1

- すべてのユーザー・ドメインの停止 1

- SNMP

- データベース・サーバーでの検証 1

- スパイン・スイッチ

- 交換 1

- SPOOL DBMCLIコマンド 1

- START DBMCLIコマンド 1

- 開始

- DBMCLI 1

- データベース・サーバーでのサービスの起動 1

- ステートフル・アラート 1 , 2

- ステートレス・アラート 1 , 2

- ステータス

- コンポーネントLED 1

- 物理ディスク 1

- 予測障害 1

- ストレージ・サーバー

- エイス・ラックのLinuxベースのサーバーの再構成 1

- swaponコマンド 1

- 構文

- DBMCLIコマンド 1

T

- THRESHOLDオブジェクト・タイプ

- 属性 1

U

- 更新

- Linuxカーネル 1

- InfiniBandスイッチのアップグレード 1

- USBフラッシュ・ドライブ 1

- ユーザー・ドメイン

- 増加

- LVMパーティション 1

- リスト 1

- メモリー割当ての変更 1

- 監視 1

- 停止 1

- 起動 1

- USERオブジェクト・タイプ

- 属性 1

- CALIBRATEの使用 1

- ユーティリティ

- クラスタ検証 1

- データベース・ノード更新 1

- ヘルス・チェック 1

- ipconf 1 , 2

- トポロジ検証 1

V

- 検証

- データベース・サーバーのメール 1

- データベース・サーバー上のSNMP 1

- 確認

- データベース・サーバーの構成 1

- ファームウェア 1 , 2 , 3 , 4 , 5 , 6 , 7 , 8 , 9 , 10 , 11

- ハードウェア 1 , 2 , 3 , 4 , 5 , 6 , 7 , 8 , 9

- InfiniBandトポロジ 1

- 物理ドライブ構成 1

- 仮想ドライブ構成 1

- トポロジ検証ユーティリティ 1

- vgdisplayコマンド 1 , 2 , 3

- 仮想CPU

- 数の変更 1

W

- ライトバック・フラッシュ・キャッシュ

- 無効化 1

- 有効化 1

- ライトスルー・キャッシュ 1

X

- xm consoleコマンド 1

- xm listコマンド 1

- xm shutdownコマンド 1

Y

- yumリポジトリ 1

Oracleの法律上の注意点

コピーライト

Copyright © 1994-2017, Oracle and/or its affiliates. All rights reserved.

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクルまでご連絡ください。

制限付権利について

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、Oracle Corporationおよびその関連会社は一切の責任を負いかねます。

商標と登録商標について

OracleおよびJavaはオラクルおよびその関連会社の登録商標です。その他の社名、商品名等は各社の商標または登録商標である場合があります。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

Pre-General Availability (一般提供前)版のドキュメントについて

このドキュメントがPre-General Availability (一般提供前)版の場合:

このドキュメントはPre-General Availability (一般提供前)版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。Oracle Corporationおよびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

非公開のPre-General Availability (一般提供前)版のドキュメントについて

このドキュメントが非公開のPre-General Availability (一般提供前)版の場合:

このドキュメントに含まれる情報は、情報の共有のみを目的としたものであって、顧客諮問委員会(Customer Advisory Board)のメンバーとしてのお客様の立場でのみ、またはお客様のPre-General Availability Trial Agreement (Pre-GAトライアル契約)のみに従って検討されるべきものとします。マテリアル、コード、または機能の提供をお約束するものではなく、購入決定を行う際の判断材料とすべきではありません。このドキュメントに記載されている特徴または機能の開発、リリースおよび時期については、オラクルの裁量により決定されます。

このドキュメントには、ソフトウェアまたは印刷物などの形式を問わず、オラクルが独占的な権利を有する財産的情報が含まれています。この機密資料へのアクセスと使用は、お客様とオラクルとの間で締結され、お客様が遵守に同意した、Oracle Master Agreement、Oracle License and Oracle Services Agreement (オラクル・ライセンスおよびサービスに関する契約書)、Oracle Partner Network Agreement、Oracle Distribution Agreementまたはその他のライセンス契約の条件に従うものとします。このドキュメントとその内容の開示、コピー、複製および配布には、オラクルによる事前の承諾を必要とします。このドキュメントはライセンス契約の一部となるものではなく、オラクルおよびその子会社や関連会社との契約を構成するものではありません。

ドキュメントのアクセシビリティ

オラクルのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)を参照してください。

Oracle Supportへのアクセス

サポートをご契約のお客様には、My Oracle Supportを通して電子支援サービスを提供しています。詳細情報は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info)か、聴覚に障害のあるお客様は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs)を参照してください。