| Oracle® Exadata Database Machineメンテナンス・ガイド 12cリリース1 (12.1) E56357-08 |
|
 前 |
 次 |
この章の内容は次のとおりです。
|
注意:
|
ほとんどの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の場合、通常、主に連絡を担当するのはデータベース管理者です。データベース管理者が問題解決に別のチームのサポートを必要とする場合は、協力して問題を解決します。問題の担当者を明確にしておく必要があります。
Oracle Exadata Database Machineのサーバー上でのほとんどの管理タスクは、従来のデータベース・サーバーおよびストレージ・サーバーと似ています。次のリストは、Oracle Exadata Database Machineサーバーの相違点と例外を示しています。
データベース・サーバーにLinuxパッケージのアップデート、特にカーネルのアップデートを適用する場合は、OFEDドライバが正しくインストールされ、カーネルが一致していることを確認する必要があります。
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のアップグレードで行われます。
|
関連項目: ipconfユーティリティの詳細は、『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環境にも適用されます。
この項には次のトピックが含まれます:
この項では、Oracle Exadataラックのコンポーネントの電源を正しく投入および切断する手順を説明します。この項の内容は次のとおりです。
Exadata Storage Serverの電源を投入するには、サーバー前面にある電源ボタンを押すか、ILOMインタフェースにログインしてシステムに電源を投入します。データベース・サーバーの電源が投入され、オペレーティング・システムがブートすると、Oracle Clusterwareがインストールされている場合にOracle Clusterwareが自動的に起動します。Oracle Clusterwareは、自動的に起動する構成のすべてのリソースを起動します。
電源投入の手順は次のとおりです。
ラック(スイッチを含む)。
Exadata Storage Serverの起動前に、スイッチに数分間電力が投入されて電源投入の構成が完了していることを確認してください。
Exadata Storage Server。
データベース・サーバーの起動前に、すべてのExadata Storage Serverのブート・プロセスが完了していることを確認してください。すべてのサービスの起動に5から10分かかる場合があります。
データベース・サーバー。
ILOMインタフェースを使用して、サーバーの電源をリモートで投入できます。Webコンソール、コマンドライン・インタフェース(CLI)、IPMIまたはSNMPを使用して、ILOMにアクセスできます。たとえば、IPMIを使用してサーバーdm01cel01に電源を投入するには、電源を投入するサーバーのILOMのホスト名がdm01cel01-ilomの場合、IPMItoolがインストールされているサーバーから次のコマンドを実行します。
# ipmitool -H dm01cel01-ilom -U root chassis power on
前述のコマンドにより、システムのパスワードの入力が要求されます。
|
関連項目: ILOMを使用してサーバーの電源を投入する方法の詳細は、Oracle Integrated Lights Out Manager(ILOM)3.0ドキュメントを参照してください。ドキュメントは次のWebサイトから入手できます。 |
Oracle Exadataラックの電源切断順序は、次のとおりです。
データベース・サーバー(Oracle Exadata Database Machineのみ)
Exadata Storage Server。
ラック(スイッチを含む)。
データベース・サーバーの電源を切断する場合、データベース・サーバーを再起動または停止する前にOracle Clusterwareを停止する必要があります。次のコマンドを使用して、Oracle Clusterwareを停止します。
crsctl stop cluster
次の手順は、データベース・サーバーの推奨されている停止手順になります。
次のコマンドを使用して、Oracle Clusterwareを停止します。
# GRID_HOME/grid/bin/crsctl stop cluster
crsctl stop clusterコマンドの発行後にOracle Clusterwareで管理されるリソースが実行されている場合、コマンドが失敗します。-fオプションを使用してすべてのリソースを無条件で停止し、Oracle Clusterwareを停止します。
次のコマンドを使用して、オペレーティング・システムを停止します。
# shutdown -h now
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コマンドを使用して、データベース・サーバーの電源切断または再起動を実行できます。
|
関連項目:
|
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ラックの電源切断
次のコマンドを使用して、すべてのデータベース・サーバーのOracle Clusterwareを停止します。
# GRID_HOME/grid/bin/crsctl stop cluster -all
次のコマンドを使用して、すべてのリモート・データベース・サーバーを停止します。
# dcli -l root -g remote_dbs_group shutdown -h now
前述のコマンドのremote_dbs_groupは、すべてのリモート・データベース・サーバーのリストを含むファイルです。
次のコマンドを使用して、すべてのExadata Storage Serverを停止します。
# dcli -l root -g cell_group shutdown -h now
前述のコマンドのcell_groupは、すべてのExadata Storage Serverのリストを含むファイルです。
次のコマンドを使用して、ローカル・データベース・サーバーを停止します。
shutdown -h now
ラックから電源を切断します。
ネットワーク・スイッチには電源スイッチがありません。配電ユニット(PDU)やデータ・センターのブレーカを介して電力が投入されなくなると、これらの電源は切断されます。
緊急時には、Oracle Exadataラックの電源をすぐに停止してください。次のような緊急時に、Oracle Exadataラックの電源切断が必要となります。
地震、洪水、ハリケーン、竜巻、またはサイクロンなどの自然災害の場合
マシンから異常な騒音、臭い、または煙が発生した場合
人の安全を脅かす場合
Oracle Exadataラックには、次の注意事項と警告が適用されます。
この製品の高圧電力を使用する部分には触れないでください。触れた場合、重傷を負う可能性があります。
緊急時以外は、Oracle Exadataラックの電源を切断しないでください。緊急時は、「緊急時の電源切断の手順」に従ってください。
キャビネットの前扉と後扉を閉めた状態にしてください。扉を閉めないと、システム障害や、ハードウェア・コンポーネントの破損が生じることがあります。
空気が適切に循環し、コンポーネントが過熱しないように、キャビネットの上部、前部および後部に障害物がない状態にしてください。
付属のハードウェア以外は使用しないでください。
自動サービス・リクエスト(ASR)は、特定のOracle Exadataラックのハードウェアに障害が発生すると自動的にサービス・リクエストを開くように設計されています。この機能を有効にするには、ハードウェア障害の遠隔測定情報をASRマネージャ・ソフトウェアに送信するように、Oracle Exadataラック・コンポーネントを構成する必要があります。このサービスでは、ディスクやフラッシュ・カードなどのExadata Storage ServerおよびOracle Database Serverのコンポーネントが対象となります。
Oracle Exadataラックの接続、およびHTTPSまたはHTTPSプロキシを使用したアウトバウンド・インターネット接続が可能なサーバーに、ASRマネージャをインストールする必要があります。Oracle SolarisまたはLinuxを実行中のスタンドアロン・サーバーまたはOracle Exadata Database Machineのデータベース・サーバーに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)トラップの例を示します。
|
注意:
|
例1-2は、Exadata Storage Serverディスク障害のSNMPトラップを示しています。対応するハードウェア・アラート・コードは強調表示されています。
例1-2 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トラップを示しています。対応するハードウェア・アラート・コードは強調表示されています。
例1-3 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.
ASRは、Oracle SolarisまたはLinuxを実行しているスタンドアロン・サーバーにインストールすることをお薦めします。インストールが完了したら、Oracle Exadata Database Machineのサーバーに対して障害の遠隔測定情報の送信先を構成します。Oracle Exadata Database Machineのサーバーは、初期構成時に設定できます。Oracle Exadata Database Machine Deployment Assistantで構成情報を収集し、サーバーを構成します。
初期構成後にASRをインストールして構成する方法の詳細は、Oracle Exadata Database Machine Oracle Auto Service Requestクイック・インストレーション・ガイドに記載されているインストールおよび構成の情報を参照してください。
|
関連項目:
|
最初のデータベース・サーバーにOracle Enterprise Manager Grid Controlエージェントを配置したOracle Enterprise Manager Grid ControlおよびExadata Storage ServerのOracle System Monitoring Plug-Inを使用して、Oracle Exadata Database Machineを監視できます。各Exadata Storage Serverは、Oracle Enterprise Manager Grid Controlの単一のターゲットとして監視されます。Oracle Exadata Database Machineのシステム・ダッシュボードにサーバーがグループ化されるので、グループ単位で監視できます。
Exadata Storage Serverメトリックは、管理サーバー(MS)によって収集および管理されます。Oracle Enterprise Manager Grid Controlと一緒に使用すると、Oracle Enterprise Manager Grid Controlメトリックとしてメトリックが示されます。
SNMPにより、すべてのExadata Storage ServerアラートがOracle Enterprise Manager Grid Controlに配信されます。Exadata Storage ServerとOracle Enterprise Manager Grid Control間の通信は、Exadata Storage ServerのOracle System Monitoring Plug-Inで実行されます。Exadata Storage Serverのサーバー・アラートのタイプは、次のとおりです。
ハードウェア・コンポーネントは、ILOMによって監視されます。ハードウェア・コンポーネントが障害またはしきい値を超えたことを報告した場合、ILOMはSNMPトラップとして障害をMSに報告します。MSは、トラップを処理してアラートを作成し、アラートをOracle Enterprise Manager Grid Controlに配信します。
ハードウェアおよびソフトウェア・コンポーネントもMSによって直接監視されます。障害またはしきい値を超えると、MSは、トラップを処理してアラートを作成し、アラートをOracle Enterprise Manager Grid Controlに配信します。
エンドユーザーの観点から、2つのタイプのアラートに違いはありません。アラート・メッセージには、アラートを解決する訂正処理が含まれています。
|
関連項目:
|
Oracle Configuration Managerは、構成情報を収集してOracleリポジトリにアップロードします。構成情報が毎日アップロードされると、Oracleサポート・サービスでデータを分析して適切なサービスを提供できます。サービス・リクエストが記録されると、構成データがサービス・リクエストに関連付けられます。次に、Oracle Configuration Managerの利点の一部を示します。
問題解決の時間の短縮
事前の問題回避
ベスト・プラクティスおよびOracleナレッジ・ベースのアクセスの向上
お客様のビジネス・ニーズの詳細な理解
一貫したレスポンスおよびサービス
サーバーの各ORACLE_HOMEディレクトリに、Oracle Configuration Managerソフトウェアがインストールおよび構成されます。クラスタ化されたデータベースには、Oracle Configuration Managerに1つのインスタンスのみが構成されます。構成スクリプトは、サーバーのすべてのデータベースで実行されます。Oracle Configuration Managerコレクタが集中管理されているOracleリポジトリにデータを送信します。
|
関連項目:
|
コンポーネントのパスワードは、初期構成後に変更できます。この項には次のトピックが含まれます:
ユーザー・アカウントとGRUBのパスワードは、データベース・サーバーで変更できます。データベース・サーバーのデフォルトのユーザー・アカウントはrootおよびソフトウェア所有者のアカウントです。通常、ソフトウェア所有者のアカウントはoracleまたはgridです。
データベース・サーバーでユーザー・アカウントを変更するには、オペレーティング・システム・プロンプトで次のコマンドを使用します。
passwd user_name
前述のコマンドのuser_nameは、変更対象のアカウントの名前です。
次の手順では、データベース・サーバーでGRUBアカウントのパスワードを変更する方法について説明します。
GRUBのパスワードを変更するには、オペレーティング・システム・プロンプトで次のコマンドを使用します。
grub-md5-crypt
新しいパスワードの入力を求められます。新しいパスワードを2回入力して文字列が表示されるようにします。
その文字列をコピー・バッファにコピーします。
/boot/grub/grub.confファイルでパスワード行を探します。その行は次のようなものです。
password --md5 hashed_string
既存のハッシュ文字列をgrub-md5-cryptコマンドの出力からコピーした文字列に置き換えます。
ファイルを保存します。
Exadata Storage Serverのデフォルトのユーザー・アカウントはroot、celladminおよびcellmonitorです。いずれかのパスワードを変更するには、オペレーティング・システム・プロンプトで次のコマンドを使用してExadata Storage Serverのパスワードを変更します。
passwd user_name
前述のコマンドのuser_nameは、変更対象のアカウントの名前です。
配電ユニット(PDU)のデフォルトのユーザー・アカウントはadminです。次の手順では、PDUのパスワードを変更する方法について説明します。
Webブラウザのアドレス行にPDUメーター・ユニットのIPアドレスを入力して、ユニットにアクセスします。現在の測定ページが表示されます。
ページの左上の「ネットワーク構成」をクリックします。
PDUメーター・ユニットにadminユーザーとしてログインします。
管理/ユーザー・フィールドを探します。ユーザー名とパスワードには、アルファベットと数字のみを使用できます。
管理/ユーザー・フィールドにユーザーとパスワードを最大で5つまで入力します。
各ユーザーを管理者またはユーザーとして指定します。
「送信」をクリックして、ユーザーとパスワードを設定します。
Integrated Lights Out Manager (ILOM)のデフォルトのユーザー・アカウントはrootです。次の手順では、ILOMのパスワードを変更する方法について説明します。
SSHを使用してILOMにログインします。
パスワードを変更するには、次のコマンドを使用します。
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
InfiniBandスイッチのデフォルトのユーザー・アカウントはroot、ilom-admin、ilom-user、ilom-operatorおよびnm2userです。次の手順では、InfiniBandスイッチのパスワードを変更する方法について説明します。
SSHを使用した次のコマンドで、InfiniBandスイッチにログインします。
ssh user_name@switch_name
前述のコマンドのuser_nameはユーザーの名前、switch_nameはInfiniBandスイッチの名前です。
スイッチのファームウェアのバージョンをチェックします。
ILOMで次のコマンドを使用して、パスワードを変更します。
ssh -l ilom-admin switch_name set /SP/users/user_name password
|
関連項目: 次のWebサイトの『Sun Datacenter InfiniBand Switch 36 User's Guide』を参照してください。 |
Ciscoイーサネット・スイッチにはデフォルトのユーザー・アカウントはありません。パスワードは有効化パスワードであり、ユーザー・アカウントに固有ではありません。次の手順では、Ciscoイーサネット・スイッチのパスワードを変更する方法について説明します。
次のコマンドを使用して、有効モードに変更します。
Switch> enable
burxsw-ip # configure terminal Enter configuration commands,one per line.End with CNTL/Z. burxsw-ip(config)# enable password ******* burxsw-ip(config)# enable secret ******* The enable secret you have chosen is the same as your enable password. This is not recommended.Re-enter the enable secret. burxsw-ip(config)# end burxsw-ip#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 ]
次のコマンドを使用して、現在の構成を保存します。
burxsw-ip# copy running-config startup-config
次のコマンドを使用して、セッションを終了します。
burxsw-ip# exit
セル・サーバーまたはデータベース・サーバーのモデルを判別するには、次のコマンドを使用します。
dmidecode -s system-product-name
次の表に、各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
|
Exadata Storage Server X6-2L Server
|
|
Oracle Exadata Database Machine X6-8 |
Oracle Server X5-8 5U Database Server
|
Exadata Storage Server X6-2L Server
|
|
Oracle Exadata Database Machine X5-2 |
Oracle Server X5-2 Database Server
|
Exadata Storage Server X5-2L Server
|
|
Oracle Exadata Database Machine X5-8 |
Oracle Server X5-8 Database Server
|
Exadata Storage Server X5-2L Server
|
|
Oracle Exadata Database Machine X4-2 |
Sun Server X4-2 Oracle Database Server
|
Exadata Storage Server X4-2L Server
|
|
Oracle Exadata Database Machine X3-2 |
Sun Server X3-2 Oracle Database Server
|
Exadata Storage Server X3-2 Server
|
|
Oracle Exadata Database Machine X2-2 |
Sun Fire X4170 M2 Oracle Database Server
|
Sun Fire X4270 M2 Serverを使用したExadata Storage Server
|
|
Oracle Exadata Database Machine X4-8フル・ラック |
Sun Server X4-8 Oracle Database Server
|
Exadata Storage Server X4-2L Server
|
|
Oracle Exadata Database Machine X3-8フル・ラック |
Sun Server X2-8 Oracle Database Server
|
Exadata Storage Server X3-2 Server
|
|
Oracle Exadata Database Machine X2-8フル・ラック |
Sun Fire X4800 Oracle Database ServerまたはSun Server X2-8 Oracle Database Server
|
Sun Fire X4270 M2 Serverを使用したExadata Storage Server
|
|
Oracle Exadata Database Machine |
Sun Fire X4170 Oracle Database Server
|
Sun Fire X4275 Serverを使用したExadata Storage Server
|
環境温度条件を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
出力が周囲温度範囲外の場合は、問題を調査して是正します。次の項目をチェックする必要があります。
ラックに十分な通気がある
室温が指定範囲内にある
ラックの背面に障害物がない
ディスク・コントローラ・バッテリ・バックアップ・ユニット(ディスク・コントローラBBU)は、データベースおよびExadata Storage Serverのドライブ・トレイにあります。ディスク・コントローラBBUは、サーバーおよびサーバー上で実行されているアプリケーションの停止時間なしで交換できます。次の手順では、ディスク・コントローラBBUを交換する方法について説明します。
|
注意: この項の手順は、コントローラに内蔵のバッテリ・バックアップ・ユニットには適用されません。これらのユニットを交換する場合は、システムを開いてコントローラ・カードにアクセスするため、システムを停止する必要があります。 |
この項では、データベース・サーバーのディスク・コントローラBBUを交換する方法について説明します。高度な手順は次のとおりです。
|
注意: 保守手順の終了後は常にExachkツールを使用することをお薦めします。このツールはMy Oracle Supportノート1070954.1から入手できます。 |
特定の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がないシステムの場合」を参照してください。
rootユーザーとしてログインします。
サービスを必要とするラックのサーバーで実行されているイメージのバージョンを取得します。
# imageinfo -ver 11.2.3.2.1.130302
例の最初の5つの部分の"11.2.3.2.1"はバージョンです。最後の部分はイメージの日付です。
ディスク・コントローラBBUの取り外しの準備
バージョン11.2.3.3.0以上を実行している場合:
交換対象のディスク・コントローラBBUを削除します。
# /opt/oracle.cellos/compmon/exadata_mon_hw_asr.pl -drop_bbu_for_replacement
次のことを確認します。
# /opt/oracle.cellos/compmon/exadata_mon_hw_asr.pl -list_bbu_status BBU status: dropped for replacement.
バージョン11.2.3.2.xを実行している場合:
サービス対象のラックのサーバーを特定し、インジケータ・ライトをオンにします。
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
HBAでバッテリと現在のステータスを表示できることを確認します。
|
注意: Solarisで実行している場合は、次のコマンドの/opt/MegaRAID/MegaCli/MegaCli64の代わりに/opt/MegaRAID/MegaCliを使用します。 |
# /opt/MegaRAID/MegaCli/MegaCli64 -adpbbucmd -a0
デフォルトの出力には、バッテリがまだ表示されていることが表示されますが、障害に応じて低電圧またはその他の問題が表示される場合もあります。BBUに重大な障害が発生し、HBAにアクセスできなくなった場合、BBUの読取りエラーが返されることがあります。
すべての論理ボリュームで現在のキャッシュ・ポリシーを確認します。
# /opt/MegaRAID/MegaCli/MegaCli64 -ldpdinfo -a0 | grep BBU
デフォルトのキャッシュ・ポリシーは、すべてのボリュームで"ライトバック"です。バッテリが正常に機能している場合、現在のキャッシュ・ポリシーは"ライトバック"としてレポートされます。ただし、障害は発生した場合、現在のキャッシュ・ポリシーは"ライトスルー"としてレポートされることがあります。
すべての論理ボリュームのキャッシュ・ポリシーをライトスルー・キャッシュ・モード(バッテリを使用しない)に設定します。
# /opt/MegaRAID/MegaCli/MegaCli64 -ldsetprop wt -lall -a0
すべての論理ボリュームの現在のキャッシュ・ポリシーがライトスルーになっていることを確認します。
# /opt/MegaRAID/MegaCli/MegaCli64 -ldpdinfo -a0 | grep BBU
リモート・マウントBBUがないシステムの場合
次の手順は、リモート・マウントBBUがないシステム用です。システムにリモート・マウントBBUがある場合は、「リモート・マウントBBUがあるシステムの場合」を参照してください。
リモート・マウントされたバッテリがシステムに取り付けられていない場合は、バッテリの交換が必要なノードをシャットダウンする必要があります。
すべてのRAIDディスク・ボリュームをライトスルー・モードに戻し、RAIDキャッシュ・メモリーのすべてのデータがディスクにフラッシュされ、バッテリの交換時にデータの損失が発生しないことを確認します。
すべての論理ボリュームのキャッシュ・ポリシーをライトスルー・キャッシュ・モードに設定します。
|
注意: Solarisで実行している場合は、次のコマンドの/opt/MegaRAID/MegaCli/MegaCli64の代わりに/opt/MegaRAID/MegaCliを使用します。 |
# /opt/MegaRAID/MegaCli/MegaCli64 -ldsetprop wt -lall -a0
すべての論理ボリュームの現在のキャッシュ・ポリシーがライトスルー(バッテリーを使用しない)になっていることを確認します。
# /opt/MegaRAID/MegaCli/MegaCli64 -ldpdinfo -a0 | grep BBU
サーバー・オペレーティング・システムをシャットダウンします。
My Oracle Supportノート1093890.1「Exadata構成でExadataおよびRDBMSサービスおよびセル/計算ノードをシャットダウン/起動する手順」の手順を実行します。
データベース・ノードの電源を切断する前に、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に設定されますが、設定によって変わる場合があります。
CRSが停止していることを確認します。実行中のCRSプロセスはありません。
# ps -ef | grep css
サーバー・オペレーティング・システムをシャットダウンします。
Linux:
# shutdown -hP now
Solaris:
# shutdown -y -i 5 -g 0
この手順では、古いディスク・コントローラ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ノードに適用されます。
オレンジ色と白色のBBUラベルのマークが付いたバッテリを特定します。
X3-2およびX4-2計算ノード: BBUのラベルが付いたシャーシの前面の右上隅のスロットです(以前に指定した"HDD7")。
X4-8計算ノード: BBUのラベルが付いたシャーシの背面の左上隅のスロットです。
X3-2LおよびX4-2Lストレージ・セル: BBUのラベルが付いた、PS1の上のシャーシ背面の右側のスロットです(以前に指定した"REAR HDD 1")。
ラッチを解除し、古いBBUキャリアをスライドさせて慎重に引き出します。
新しい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ノードに関連します。
CMOD0をサーバーから取り外し、平らな静電気防止面の上に置きます。
CMODの上部カバーを取り外します。
BBUが取り付けられているHBA REMを取り外します。
REMイジェクタ・ハンドルを持ち上げ、開位置まで回転します。
REMのコネクタの端を持ち上げ、前面の支持金具の固定クリップからREMを引き抜きます。
古いBBUをREMから取り外します。
プラスのねじ回し(Phillipsの1番)を使用して、バッテリをREMカードに固定している3本の留めねじを外します。REMとバッテリ・パックの上側のねじは外さないでください。これらのねじは、底部にねじ穴のある支持具を固定しており、バッテリ・パックに付けたままにしておく必要があります。
回路基板を含むバッテリ・パックを、回路基板コネクタからゆっくり持ち上げ、REMから取り外します。
新しいBBUをREMに取り付けます。
バッテリ・パックの回路基板コネクタを取り付け、REMのコネクタに接続します。
プラスのねじ回し(Phillipsの1番)を使用して、バッテリをREMに固定します。BBUに新しいねじのパッケージが付属している場合は、それらのねじを使用し、古いBBUアタッチメントのねじは再利用しないでください。
BBUが取り付けられているHBA REMを元どおりに取り付けます。
REMイジェクタ・レバーが閉位置になっていることを確認します。レバーはREM支持金具と平らになっている必要があります。
バッテリが下を向いており、コネクタとマザーボードのコネクタの位置が合うように、REMの位置を合わせます。
REMの反対の端を前面の支持金具の固定クリップの下に滑らせ、REMの端のノッチが金具の位置合せポストの周囲に位置していることを確認します。
REMがマザーボードのコネクタに接する位置まで、REMのコネクタの端を慎重に押し下げ、コネクタの位置が合っていることを確認します。コネクタを固定するには、レベル位置までREMを慎重に押し込みます。
カバーをCMODに取り付けます。
CMODをCMOD0スロットのユニットに戻します。
「手順1: ディスク・コントローラBBUの取り外しの準備」と同様、この手順には2つのサブ項目があります。
リモート・マウントBBUがあるシステムの場合
リモート・マウントBBUがあるシステムの場合、「手順1: ディスク・コントローラBBUの取り外しの準備」の終了時にシステムはシャットダウンされていません。
イメージ・バージョン11.2.3.3.0以上を使用している場合:
ルート・ユーザーとしてログインします。
ディスク・コントローラ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
ディスク・コントローラBBUおよびディスク・キャッシュを再有効化します。
# /opt/oracle.cellos/compmon/exadata_mon_hw_asr.pl -reenable_bbu HDD disk controller battery has been reenabled.
ディスク・コントローラBBUのバッテリ状態がOperationalであることを確認します。
# /opt/oracle.cellos/compmon/exadata_mon_hw_asr.pl -list_bbu_status BBU status: present
現在の論理ディスク・ドライブのキャッシュ・ポリシーでライトバック・モードが使用されていることを確認します。
# /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>
現在のキャッシュ・ポリシーがライトスルー・モードで、ライトバックでない場合は、バッテリのステータスをチェックします。
# /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を使用している場合:
ルート・ユーザーとしてログインします。
サーバーの検出LEDをオフにします。
# ipmitool chassis identify off Chassis identify interval: off
HBAが認識され、新しいBBUと通信を開始するまで、約5分間待機します。
HBAバッテリ・ステータスがOperationalで、充電中であることを確認します。
# /opt/MegaRAID/MegaCli/MegaCli64 -adpbbucmd -a0
すべての論理ドライブのキャッシュ・ポリシーをライトバック・キャッシュ・モードに設定します。
# /opt/MegaRAID/MegaCli/MegaCli64 -ldsetprop wb -lall -a0
すべての論理ドライブの現在のキャッシュ・ポリシーがライトバック・キャッシュ・モードを使用していることを確認します。
# /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を有効にします。
電源ボタンを押して、サーバーの電源を入れます。
ILOMが起動したら、電源ボタンを押してサーバーの電源を入れ、サーバーのコンソールに接続します。
ILOM Webブラウザからコンソールに接続する手順(推奨): リモート制御→リダイレクト・タブにアクセスし、リモート・コンソールの起動ボタンをクリックします。ILOM 3.1.xシステムでは、コンソール・ボタンは最初の「サマリー情報」画面から起動できます。
ILOM CLIからコンソールに接続する手順:
> start /SP/console
サーバーのコンソールから、システム・ブートを監視します。特に、ロード中のLSIコントローラのBIOSを監視してください。保存されているキャッシュがあるドライブに関する警告メッセージが表示される場合、"D"を選択すると、キャッシュを破棄して続行されます。ASMによる起動後に、ディスクが再同期されるため、これは問題ではありません。バッテリ低下によりライトスルー・モードになっているドライブに関する警告メッセージが表示される場合は、選択して続行します。
その後、Exadataの起動が正常に続行されると、Exadataのブート・スプラッシュ画面が表示され、通常のOSブート・メッセージが引き続き表示されます。後続の起動手順中に、ILOMシリアル・コンソールの画面出力の間の停止時間が長くなる場合がありますが、これは、デフォルトのコンソールがグラフィックで、Exadataブート・スプラッシュ画面が表示されないためです。
起動がすべて完了したら、rootユーザーとしてログインし、新しいバッテリが表示されて充電中であることを確認します。
# /opt/MegaRAID/MegaCli/MegaCli64 -adpbbucmd -a0
すべての論理ドライブのキャッシュ・ポリシーを、バッテリを使用するライトバック・キャッシュ・モードに設定します。
# /opt/MegaRAID/MegaCli/MegaCli64 -ldsetprop wb -lall -a0
すべての論理ドライブの現在のキャッシュ・ポリシーがライトバック・キャッシュ・モードを使用していることを確認します。
# /opt/MegaRAID/MegaCli/MegaCli64 -ldpdinfo -a0 | grep BBU
データベース・サービスが自動的に開始されたことを確認します。
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になります。
インスタンスが実行中であることを検証します。
# ps -ef |grep pmon
ASMインスタンスのレコードと各データベースのレコードが返されます。
この項では、Exadata Storage Serverのディスク・コントローラBBUを交換する方法について説明します。手順の概要は次のとおりです。
|
注意: 保守手順の終了後は常にExachkツールを使用することをお薦めします。このツールはMy Oracle Supportノート1070954.1から入手できます。 |
特定のX3-2、X4-2およびX4-8データベース・ノード、X3-2、X4-2、およびX3-8、X4-8ストレージ・サーバーでは、BBUはリモートでマウントされ、アクセスするのにシステムのシャットダウンは不要です。ただし、ディスク・ボリュームへのデータ破損を回避するには、RAID HBAから取り外せるように準備する必要があります。X3-8データベース・ノードのリモート・マウントBBUオプションはありません。
リモート・マウントBBUがあるシステムの場合
システムにリモート・マウントBBUがある場合は、この項の手順を実行します。システムにリモート・マウントBBUがない場合は、「リモート・マウントBBUがないシステムの場合」の手順を実行します。
rootユーザーとしてログインします。
サービスを必要とするラックのサーバーで実行されているイメージのバージョンを取得します。
# cellcli -e list cell attributes releaseVersion 11.2.3.2.1
ディスク・コントローラBBUを削除します。
バージョン11.2.3.3.0以上を実行している場合:
交換対象のディスク・コントローラBBUを削除します。次のコマンドを"celladmin"または"root"ユーザーとして実行します。
# cellcli -e alter cell bbu drop for replacement HDD disk controller battery has been dropped for replacement
交換対象のBBUが削除されたことを確認します。
# cellcli -e list cell attributes bbustatus dropped for replacement.
バージョン11.2.3.2.xを実行している場合:
サービス対象のラックのサーバーを特定し、インジケータ・ライトをオンにします。
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
HBAでバッテリと現在のステータスを表示できることを確認します。
|
注意: Solarisで実行している場合は、次のコマンドの/opt/MegaRAID/MegaCli/MegaCli64の代わりに/opt/MegaRAID/MegaCliを使用します。 |
# /opt/MegaRAID/MegaCli/MegaCli64 -adpbbucmd -a0
デフォルトの出力には、バッテリがまだ表示されていることが表示されますが、障害に応じて低電圧またはその他の問題が表示される場合もあります。BBUに重大な障害が発生し、HBAにアクセスできなくなった場合、BBUの読取りエラーが返されることがあります。
すべての論理ボリュームで現在のキャッシュ・ポリシーを確認します。
# /opt/MegaRAID/MegaCli/MegaCli64 -ldpdinfo -a0 | grep BBU
デフォルトのキャッシュ・ポリシーは、すべてのボリュームで"ライトバック"です。バッテリが正常に機能している場合、現在のキャッシュ・ポリシーは"ライトバック"としてレポートされます。ただし、障害は発生した場合、現在のキャッシュ・ポリシーは"ライトスルー"としてレポートされることがあります。
すべての論理ボリュームのキャッシュ・ポリシーをライトスルー・キャッシュ・モード(バッテリを使用しない)に設定します。
# /opt/MegaRAID/MegaCli/MegaCli64 -ldsetprop wt -lall -a0
すべての論理ボリュームの現在のキャッシュ・ポリシーがライトスルーになっていることを確認します。
# /opt/MegaRAID/MegaCli/MegaCli64 -ldpdinfo -a0 | grep BBU
リモート・マウントBBUがないシステムの場合
システムにリモート・マウントBBUがない場合は、この項の手順を実行します。システムにリモート・マウントBBUがある場合は、「リモート・マウントBBUがあるシステムの場合」を参照してください。
リモート・マウントされたバッテリがシステムに取り付けられていない場合は、バッテリの交換が必要なノードをシャットダウンする必要があります。
すべてのRAIDディスク・ボリュームをライトスルー・モードに戻し、RAIDキャッシュ・メモリーのすべてのデータがディスクにフラッシュされ、バッテリの交換時にデータの損失が発生しないことを確認します。
すべての論理ボリュームのキャッシュ・ポリシーをライトスルー・キャッシュ・モードに設定します。
# /opt/MegaRAID/MegaCli/MegaCli64 -ldsetprop wt -lall -a0
すべての論理ボリュームの現在のキャッシュ・ポリシーがライトスルー(バッテリーを使用しない)になっていることを確認します。
# /opt/MegaRAID/MegaCli/MegaCli64 -ldpdinfo -a0 | grep BBU
サーバー・オペレーティング・システムをシャットダウンします。
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時間で、コンポーネントの交換には適切ですが、長い時間が必要な場合は、変更が必要になることがあります。
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';
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によってディスマウントされ、データベースが突然停止します。 |
保守用に電源を切断する必要があるセルのすべてのグリッド・ディスクを非アクティブ化します。これは、最大で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...
グリッド・ディスクがオフラインになったことを確認します。ディスクがオフラインになり、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...
すべてのディスクがオフラインになり、非アクティブになると、セルをシャットダウンできます。
# shutdown -hP now
Exadata Storage Serverの電源を切断すると、すべてのストレージ・サービスが自動的に停止します。
「手順2: ディスク・コントローラBBUの交換」を参照してください。
「手順1: ディスク・コントローラBBUの取り外しの準備」と同様、この項には2つのサブ項目があります。
リモート・マウントBBUがあるシステムの場合
システムにリモート・マウントBBUがある場合は、この項の手順を実行します。このシナリオでは、「手順1: ディスク・コントローラBBUの取り外しの準備」の終了時にシステムはシャットダウンされていません。
イメージ・バージョン11.2.3.3.0以上を実行している場合:
celladminまたはrootユーザーとしてログインします。
BBUを再有効化します。
# cellcli -e alter cell bbu reenable HDD disk controller battery has been reenabled
ディスク・コントローラBBUのバッテリ状態がOperationalであることを確認します。
# cellcli -e list cell attributes bbustatus normal
"BBUステータス"が"normal"以外の場合は、続行する前に問題を調査して修正してください。
イメージ・バージョン11.2.3.2.xを実行している場合:
ルート・ユーザーとしてログインします。
サーバーの検出LEDをオフにします。
# ipmitool chassis identify off Chassis identify interval: off
HBAが認識され、新しいBBUと通信を開始するまで、約5分間待機します。
HBAバッテリ・ステータスがOperationalで、充電中であることを確認します。
# /opt/MegaRAID/MegaCli/MegaCli64 -adpbbucmd -a0
すべての論理ドライブのキャッシュ・ポリシーをライトバック・キャッシュ・モードに設定します。
# /opt/MegaRAID/MegaCli/MegaCli64 -ldsetprop wb -lall -a0
すべての論理ドライブの現在のキャッシュ・ポリシーがライトバック・キャッシュ・モードを使用していることを確認します。
# /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がないシステムはシャットダウンされています。システムを再起動する必要があります。
電源ボタンを押して、サーバーの電源を入れます。
ILOMが起動したら、電源ボタンを押してサーバーの電源を入れ、サーバーのコンソールに接続します。
ILOM Webブラウザからコンソールに接続する手順(推奨): リモート制御→リダイレクト・タブにアクセスし、リモート・コンソールの起動ボタンをクリックします。ILOM 3.1.xシステムでは、コンソール・ボタンは最初の「サマリー情報」画面から起動できます。
ILOM CLIからコンソールに接続する手順:
> start /SP/console
サーバーのコンソールから、システム・ブートを監視します。特に、ロード中のLSIコントローラのBIOSを監視してください。保存されているキャッシュがあるドライブに関する警告メッセージが表示される場合、"D"を選択すると、キャッシュを破棄して続行されます。ASMによる起動後に、ディスクが再同期されるため、これは問題ではありません。バッテリ低下によりライトスルー・モードになっているドライブに関する警告メッセージが表示される場合は、選択して続行します。
その後、Exadataの起動が正常に続行されると、Exadataのブート・スプラッシュ画面が表示され、通常のOSブート・メッセージが引き続き表示されます。後続の起動手順中に、ILOMシリアル・コンソールの画面出力の間の停止時間が長くなる場合がありますが、これは、デフォルトのコンソールがグラフィックで、Exadataブート・スプラッシュ画面が表示されないためです。
起動がすべて完了したら、rootユーザーとしてログインし、新しいバッテリが表示されて充電中であることを確認します。
# /opt/MegaRAID/MegaCli/MegaCli64 -adpbbucmd -a0
すべての論理ドライブのキャッシュ・ポリシーを、バッテリを使用するライトバック・キャッシュ・モードに設定します。
# /opt/MegaRAID/MegaCli/MegaCli64 -ldsetprop wb -lall -a0
すべての論理ドライブの現在のキャッシュ・ポリシーがライトバック・キャッシュ・モードを使用していることを確認します。
# /opt/MegaRAID/MegaCli/MegaCli64 -ldpdinfo -a0 | grep BBU
セルをサービスに戻します。
グリッド・ディスクをアクティブ化します。
# 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...
すべてのディスクがアクティブになっていることを確認します。
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...
すべてのグリッド・ディスクが正常にオンラインになったことを確認します。すべてのグリッド・ディスクで"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の同期化が完了します。このプロセスは、個別のサーバーが修復のために停止している間マシンがビジー、またはビジーであった状態に応じて時間がかかる場合があります。
リリース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を時間内に送信できなくなり、データベース・ノードで破損が発生し、リカバリが遅延する場合があります。
Oracle Exadata Database Machine 12.1.2.1.0以降:
データベース・ノードで管理サーバー(MS)が実行されるようになりました。以前のMSは、ストレージ・ノードでのみ実行されていました。
データベース・マシン・サービス(dbmsrv)という名前の新しいサービスがデータベース・ノードで実行されるようになりました。この新しいサービスがベースとするMSは、ストレージ・サーバー上で実行され、データベース・ノードに拡張管理機能を提供します。
新しいdbmsrvサービスを管理するために、新しいユーザーとグループが追加されました。
デフォルト値と競合が発生している場合(たとえば、LDAPまたは別のディレクトリを使用している場合、または、デフォルト値と異なる値を必要とするセッション管理ツールを使用している場合)、DBMユーザーのユーザーIDとグループIDを変更できます。
これらの手順は、DBMサービスのユーザーとグループのみに固有です。これらを使用して、他のOracle製品のユーザーとグループを変更しないでください。
デフォルトのDBMユーザーおよびグループIDを変更する手順:
dbserverサービスを停止します。次のコマンドをrootまたはdbmadminユーザーとして実行します。
dbmcli -e alter dbserver shutdown services all
ユーザーのグループIDを変更します。次のコマンドをrootとして実行します。
groupmod -g <NEW_GID> <GROUPNAME>
次に例を示します。
groupmod -g 3001 dbmusers
古いグループIDを含むファイルを更新します。次のコマンドをrootとして実行します。
find / -gid <OLD_GID> -exec chgrp -h <NEW_GID> {} \;
例:
find / -gid 11140 -exec chgrp -h 3001 {} \;
ユーザーIDを変更します。これは、グループIDの変更後に実行する必要があり、そうしないと、GIDが存在しませんエラーが表示されます。次のコマンドをrootとして実行します。
usermod -u <NEW_UID> -g <NEW_GID> <USER>
例:
usermod -u 2998 -g 3001 dbmsvc
古いユーザーIDを含むファイルを更新します。次のコマンドをrootとして実行します。
find / -uid <OLD_UID> -exec chown -h <NEW_ID> {} \;
例:
find / -uid 12137 -exec chown -h 2998 {} \;
dbrsMain実行可能ファイル上のsetuid bitをリセットし、これが実行されるようにします。setuid bitは、chgrpおよびchownコマンドによって変更されています。次のコマンドをrootとして実行します。
chmod 6550 /opt/oracle/dbserver/dbms/bin/dbrsMain
dbserverサービスを再起動します。次のコマンドをdbmadminユーザーとして実行します。
dbmcli -e alter dbserver startup services all
表1-5は、構成変更中にセル・ノードとデータベース・ノードをオフラインとオンラインのどちらにしておく必要があるかを示しています。
表1-5 操作時のセルおよびデータベース・ノードの状態
| 操作 | セル・ノード | データベース・ノード |
|---|---|---|
|
DNSサーバーの更新 |
オンライン |
オンライン |
|
NTPサーバーの更新 |
オンライン |
オンライン |
|
タイム・ゾーンの更新 |
オフライン |
オンライン |
|
管理ネットワークのIPアドレス、ネットマスク、ゲートウェイ、ホスト名の変更 |
オフライン |
オンライン |
|
クライアント・ネットワークのIPアドレス、ネットマスク、ゲートウェイ、ホスト名の変更 |
オフライン |
オンライン |
|
ILOM IPアドレスの変更 |
オフライン |
|
|
その他のILOMパラメータの変更 |
|
|
|
InfiniBand IP、ネットマスク、ホスト名の変更 |
オフライン |
オンライン |
|
pkeyの変更 |
オフライン |
オンライン |
