Mercury Business Availability Center データベース環境の準備 Version 6.1 i Mercury Business Availability Center, Version 6.1 データベース環境の準備 本マニュアル,付属するソフトウェアおよびその他の文書の著作権は,米国著作権法,および各国の著作 権法によって保護されており,付属する使用許諾契約書に基づきその範囲内でのみ使用されるものとしま す。Mercury Interactive Corporation のソフトウェア,その他の製品およびサービスの機能は次の 1 つまたは それ以上の特許に記述があります。米国特許番号 5,511,185; 5,657,438; 5,701,139; 5,870,559; 5,958,008; 5,974,572; 6,137,782; 6,138,157; 6,144,962; 6,205,122; 6,237,006; 6,341,310; 6,360,332, 6,449,739; 6,470,383; 6,477,483; 6,549,944; 6,560,564; 6,564,342; 6,587,969; 6,631,408; 6,631,411; 6,633,912; 6,694,288; 6,738,813; 6,738,933; 6,754,701; 6,792,460 および 6,810,494。オーストラリア特許番号 763468 および 762554。その他の 特許は米国およびその他の国で申請中です。すべての権利は弊社に帰属します。 Mercury,Mercury Interactive,Mercury のロゴ,Mercury Interactive のロゴ,LoadRunner,WinRunner, SiteScope および TestCenter は,米国およびその他の国の Mercury Interactive Corporation の商標または登録 商標です。上記の一覧に含まれていない商標についても,Mercury Interactive が当該商標の知的所有権を放 棄するものではありません。 その他の企業名,ブランド名,製品名の商標および登録商標は,各所有者に帰属します。 Mercury Interactive Corporation は,どの商標がどの企業または組織の所有に属するかを明記する責任を負い ません。 Mercury では,補足情報を検索するため,サードパーティの Web サイトへのリンクを提供しています。サ イトの内容および利用は予告なしに変更される場合があります。Mercury は,サイトの内容または利用に ついて,いかなる表明や保証を行うものではありません。 Mercury Interactive Corporation 379 North Whisman Road Mountain View, CA 94043 Tel: (650) 603-5200 Toll Free: (800) TEST-911 Customer Support: (877) TEST-HLP Fax: (650) 603-5300 © 2005-2006 Mercury Interactive Corporation, All rights reserved 本書に関するご意見やご要望は [email protected] まで電子メールにてお送りください。 AMLIB_DB6.1JP/01 目次 データベース環境の準備へようこそ ....................................................... vii 本書の構成............................................................................................... vii 対象読者 ..................................................................................................viii 詳細情報について....................................................................................viii 第 1 部 :デ ー タ ベ ー ス 環 境 に つ い て 第 1 章 データベース環境の準備を開始する前に...................................3 Mercury Business Availability Center で使用されるデータベース ............4 第 2 部 :M S S Q L S e r v e r デ ー タ ベ ー ス の 導 入 と 保 守 第 2 章 MS SQL Server の導入の概要...................................................9 MS SQL Server の導入について .............................................................10 システム要件 ...........................................................................................11 第 3 章 MS SQL Server データベースの作成と設定 ...........................13 データベースの作成 ................................................................................14 データベースの設定 ................................................................................22 第4章 MS SQL データベースへのアクセスにおける Windows 認証の使用...............................................................31 Mercury Business Availability Center の Windows 認証機能の有効化 ....32 Windows 認証を使用した MS SQL データベースへの接続 ....................35 第 5 章 MS SQL Server データベースの保守 ......................................39 データベースのバックアップ..................................................................40 データベースの整合性とフラグメンテーション .....................................44 データベースの監視 ................................................................................55 データベースの保守 : 参考資料...............................................................59 iii 目次 第 6 章 MS SQL Server サイズ設定ガイドライン...............................61 Mercury Business Availability Center サイズ設定 ...................................62 ハードウェアのサイズ設定......................................................................63 サーバ設定オプション.............................................................................63 データ・ファイルのプロパティの設定....................................................64 tempdb データベースの設定 ...................................................................64 第 7 章 MS SQL Server サマリ・チェックリスト...............................65 Mercury Business Availability Center におけるサポートと認定の チェックリスト ....................................................................................66 サーバおよびデータベースの設定の確認と変更 .....................................67 第 8 章 MS SQL Server のインストールと設定 ..................................71 MS SQL Server のインストール .............................................................72 MS SQL Server の設定............................................................................81 第 3 部 :O r a c l e サ ー バ ・ デ ー タ ベ ー ス の 導 入 と 保 守 第 9 章 Oracle サーバの導入の概要.....................................................87 Oracle サーバの導入について .................................................................88 システム要件 ...........................................................................................89 Oracle サーバのエディションの選択 ......................................................91 第 10 章 Mercury Business Availability Center データベース環境の セットアップ............................................................................93 Mercury Business Availability Center の Oracle 表領域 ..........................94 管理用ユーザ・スキーマ .........................................................................97 プロファイル・ユーザ・スキーマ...........................................................99 Mercury Business Availability Center の Oracle スキーマの権限 ..........102 第 11 章 Mercury Business Availability Center 向けの Oracle Client の設定 .............................................................103 Oracle Client のバージョンとオペレーティング・システム・ プラットフォーム...............................................................................104 Oracle Client のインストール................................................................104 Oracle Client の設定 ..............................................................................105 第 12 章 Oracle サーバ・データベースの保守 ....................................107 データベースの保守とチューニング .....................................................108 Oracle データベースのバックアップおよび回復 ..................................121 第 13 章 Oracle サーバのサイズ設定ガイドライン .............................125 Mercury Business Availability Center サイズ設定 .................................126 ハードウェアのサイズ設定....................................................................127 Oracle パラメータのサイズ設定............................................................128 Oracle ファイルのサイズ設定 ...............................................................132 iv 目次 第 14 章 Oracle サマリ・チェックリスト ...........................................137 Mercury Business Availability Center のサポートと 認定向けチェックリスト ....................................................................138 第 4 部 :付 録 付録 A データベースの集約と分散 ....................................................149 データベースの集約のメリット ............................................................150 データベース分散の理由 .......................................................................150 付録 B データ格納域の推奨事項........................................................153 MS SQL Server ファイル・グループの作成 .........................................154 Oracle サーバ表領域の作成...................................................................158 付録 C データのパーティショニングとパージ ..................................161 データのパーティショニングとパージ .................................................162 パージ・マネージャの仕組み................................................................162 パージ・マネージャのパラメータ値の計算 ..........................................163 パージ・マネージャ・パラメータの設定..............................................165 パージ・マネージャを使用する際の Oracle 表領域の作成...................168 付録 D データベース・スキーマの検証 .............................................169 検証処理について..................................................................................170 検証処理の実行 .....................................................................................171 検証処理のためのデータベース・ユーザの作成 ...................................176 付録 E ローダを使用したデータの管理 .............................................179 ローダを使用したデータ管理の概要 .....................................................180 ローダに関する問題のトラブルシューティング ...................................181 ローダ・フォルダの場所 .......................................................................181 標準設定のログ・レベルの変更 ............................................................183 障害を起こしたデータの保持期間の変更..............................................183 DLQ クリーンアップ・ツール...............................................................185 付録 F モニタ管理の設定データのバックアップと復元....................187 設定データのバックアップと復元の概要..............................................188 基本バックアップと復元 .......................................................................189 レプリケーション・サーバへのバックアップと復元の基本 .................190 LDIF バックアップと復元 .....................................................................190 レプリケーション..................................................................................192 OpenLDAP の起動と停止......................................................................196 バックアップと復元の例 .......................................................................197 索引 .......................................................................................................203 v v 目次 vi データベース環境の準備へようこそ 本書では,MS SQL Server および Oracle サーバのデータベースを Mercury Business Availability Center で使用するための導入と保守の方法について説明し ます。 注:本書は Mercury Managed Services の利用者には該当しません。 本書の構成 本書は,以下の部で構成されています。 第1部 データベース環境について Mercury Business Availability Center で使用されるデータベースの種類について説 明します。 第2部 MS SQL Server データベースの導入と保守 MS SQL Server のインストールと設定の方法,MS SQL Server でのデータベースの 作成と設定の方法,およびデータベースの保守の方法について説明しています。 第3部 Oracle サーバ・データベースの導入と保守 Oracle サーバのインストール方法,Oracle サーバでのデータベースの作成と設 定の方法,Oracle に対応するための Mercury Business Availability Center データ ベース環境のセットアップ方法,Oracle Client の設定方法,およびデータベー スの保守の方法について説明しています。 vii ようこそ 第4部 付録 すべての Mercury Business Availability Center データを単一のデータベースに整 理統合すべき状況と,データを複数の異なるデータベースに分散すべき状況に ついて説明します。また,MS SQL Server ファイル・グループと Oracle 表領域 を作成する際の推奨事項,パージ・マネージャでの作業,データベース・ス キーマの検証手順,Mercury Business Availability Center ローダ,およびモニタの 管理設定データ用の LDAP データベースのバックアップと復元の手順について も説明します。 対象読者 本書は,次の Mercury Business Availability Center ユーザを読者として想定とし ています。 ➤ Mercury Business Availability Center 管理者 ➤ データベース管理者 本書は,データベース管理に通じていて高度なスキルを持っていることを前提 としています。 詳細情報について Mercury Business Availability Center 文書ライブラリの使用と更新の詳細,その他 の文書リソースの参照情報,文書ライブラリで使用している表記規則,および Mercury Business Availability Center の配備,管理,使用に関するクイック・リ ファレンスの詳細については,『Mercury Business Availability Center スタート アップ・ガイド』を参照してください。 viii 第1部 データベース環境について 第1章 データベース環境の準備を開始する前に 本章では,Mercury Business Availability Center で使用されるデータベースのタイ プについて説明します。 本章の内容 ページ Mercury Business Availability Center で使用されるデータベース 4 3 第 1 部 • データベース環境について Mercury Business Availability Center で使用されるデータベース Mercury Business Availability Center で作業を行うためには,次のタイプのデータ ベースを設定する必要があります。 ➤ 管理データベース : システム全体を対象としたデータや管理に関連する Mercury Business Availability Center 環境のメタ・データを格納します。Mercury Business Availability Center には,1 つの管理データベースが必要です。このデータベー スは手作業で作成するか,また管理データベース・ウィザード・ユーティリ ティを使用して作成できます。 ➤ プロファイル・データベース : Mercury Business Availability Center データ・コレ クタから取得した未処理測定データや集計測定データを格納します。必要なプ ロファイル・データベースは 1 つだけですが,必要に応じて,複数のデータ ベースにプロファイル・データを格納できます。プロファイル・データベース は,手動で作成するか,または[プラットフォームの管理]の[セットアップ と保守]タブからアクセスできる[データベース管理]ページを使用して作成 できます。 ➤ Mercury ユニバーサル CMDB : Mercury Business Availability Center,または他の サード・パーティ製の各種アプリケーションやツールから収集される設定情報 を格納します。この情報は Mercury Business Availability Center ビューの構築時 に使用されます。また,CMDB には構成アイテムと主要管理指標(KPI)の定 義に使用されるオブジェクト・リポジトリも格納されます。CMDB は Mercury Application Management と共有できます(詳細については,『CMDB を使用した 作業』の「Mercury ユニバーサル CMDB 環境の共有」を参照してください)。 注:標準設定では,CMDB は管理データベースの一部として作成されますが, 手作業で作成することも,[プラットフォームの管理]の[セットアップと保 守]タブからアクセスできる CMDB の[データベース管理]ページを使って作 成することもできます。本書全体を通じて,特に説明がない限り CMDB は管理 データベースの一部として扱います。 管理データベース,プロファイル・データベース,および CMDB は,組織で使 用しているデータベース・サーバのタイプに応じて,Microsoft SQL Server また は Oracle サーバのどちらかに設定します。MS SQL Server での作業の詳細につ いては,第 2 部「MS SQL Server データベースの導入と保守」を参照してくだ さい。Oracle サーバでの作業の詳細については,第 3 部「Oracle サーバ・デー タベースの導入と保守」を参照してください。付録では,MS SQL Server およ 4 第 1 章 • データベース環境の準備を開始する前に び Oracle サーバの両方のデータベースに関連する補足情報について説明してい ます。 注: ➤ データベース・サーバは Mercury Business Availability Center サーバと同じタ イム・ゾーン,夏時間,および時間に設定する必要があります。 ➤ 英語以外の環境で Mercury Business Availability Center を使用する際は, 『I18N 環境での作業』を参照してください。 5 5 第 1 部 • データベース環境について 6 第2部 MS SQL Server データベースの導入と保守 第2章 MS SQL Server の導入の概要 MS SQL Server 上には,管理データベースおよびプロファイル・データベース をセットアップできます。本章では,Mercury Business Availability Center と連携 して使用する MS SQL Server の導入に関する次の項目について説明します。 本章の内容 ページ MS SQL Server の導入について 10 システム要件 11 9 第 2 部 • MS SQL Server データベースの導入と保守 MS SQL Server の導入について MS SQL Server を導入し,Mercury Business Availability Center と連携させるため には,次の手順を実行する必要があります。 ➤ MS SQL Server のインストールと設定 詳細については,71 ページ「MS SQL Server のインストールと設定」を参照し てください。 ➤ 管理データおよびプロファイル・データを格納するデータベースを,MS SQL Server に作成 詳細については,14 ページ「データベースの作成」を参照してください。 注:データベースは Mercury Business Availability Center によって自動的に作成 されるようにできます。あるいは,CREATE DATABASE ステートメントまたは MS SQL Server Enterprise Manager を使用して自分で作成することもできます。 データベースは自分で作成することをお勧めします。 本項では,MS SQL Server の推奨環境およびサポート対象環境を示します。 Mercury Business Availability Center の導入において推奨される環境とは,推奨の 環境またはオプションについて Mercury の品質保証担当者が十分なテストを実 施済みであることを示すものです。サポート対象環境およびサポート対象オプ ションとは,対象の環境やオプションについて,Mercury の品質保証担当者に よる基本的なテストが正常に実施されたことを意味します。 10 第 2 章 • MS SQL Server の導入の概要 システム要件 次の表は,MS SQL Server を Mercury Business Availability Center と組み合わせて 運用する場合におけるシステム要件を示します。 サポート コンポーネント サービス・ パック バージョン / エディション サービス・ パック オペレーティン Windows 2000 Server/Advanced グ・システム Server Service Pack 4 Windows 2003 Server : Standard/ Enterprise Service Pack 1 MS SQL Server Service Pack 4 MS SQL Server 2000 Enterprise Service Pack 4 MDAC (Microsoft Data Access Components) (Mercury Business Availability Center サーバ上) バージョン / エディション 推奨 MS SQL Server 2000 Enterprise 2.5,2.52,2.61,2.62,2.7 SP1 更新 2.7 SP1 更新 : Mercury Business Availability Center サーバのインス トール時に自動的にインストール されます。 注:インストールされている MDAC のバージョンを調べるには, http://www.microsoft.com/downloads/details.aspx?FamilyID=8f0a8df6-4a21-4b43bf53-14332ef092c9&displaylang=en からコンポーネント・チェッカ・ツールをダ ウンロードして実行してください。 11 11 第 2 部 • MS SQL Server データベースの導入と保守 12 第3章 MS SQL Server データベースの作成と設定 本章では,MS SQL Server における Mercury Business Availability Center データ ベースの作成と設定について説明します。 本章の内容 ページ データベースの作成 14 データベースの設定 22 13 第 2 部 • MS SQL Server データベースの導入と保守 データベースの作成 MS SQL Server のインストールと設定が完了したら,システム全体を対象とす るデータや管理に関連するデータを格納する管理データベースと,Mercury Business Availability Center によって収集されるデータを格納するプロファイル・ データベースを 1 つ以上作成します。 データベースは,CREATE DATABASE ステートメントまたは MS SQL Server Enterprise Manager(詳細については,MS SQL Server 2000 Books Online を参照し てください)と,以降の各項に示した手順を使用して,自分で作成できます。 ➤ データベース権限 : 17 ページを参照してください。 ➤ データベース・ファイルのレイアウト : 18 ページを参照してください。 ➤ システム・データベース : 21 ページを参照してください。 注:Mercury Business Availability Center データベースの作成にはこの方法をお勧 めします。 管理スキーマとプロファイル・スキーマを生成すると(次の項を参照) ,管理 データベース・ウィザード・ユーティリティを使用して Mercury Business Availability Center を既存の管理データベースに接続できます。また, [プラット フォームの管理]の[セットアップと保守]タブにある[データベース管理] から Mercury Business Availability Center を既存のプロファイルに接続できます。 別に CMDB スキーマを生成している場合,管理データベースに含まれる標準の CMDB の代わりに, [プラットフォームの管理]の「セットアップと保守]タブ にある[CMDB データベース管理]ページから新しい CMDB に接続できます。 または,管理データベース・ウィザード・ユーティリティを使用して,管理 データベースが自動的に作成されるよう設定したり,[プラットフォームの管 理]の[セットアップと保守]タブにある[データベース管理]ページを使用 して,プロファイル・データベースが自動的に作成されるよう設定したりでき ます。管理データベースに含まれる標準の CMDB の代わりに別の CMDB を使 用する場合,Mercury Business Availability Center の[プラットフォームの管理] の[セットアップと保守]タブにある[CMDB データベース管理]ページを使 用して CMDB を作成できます。 管理データベース・ウィザード・ユーティリティの詳細については,『サーバ の導入』の「Windows プラットフォームにおける管理データベース・パラメー 14 第 3 章 • MS SQL Server データベースの作成と設定 タの設定」を参照してください。Mercury Business Availability Center でのプロ ファイル・データベースの作成の詳細については,『プラットフォームの管理』 の「データベースの管理」を参照してください。Mercury Business Availability Center での CMDB の作成の詳細については,『プラットフォームの管理』の 「Mercury ユニバーサル CMDB の管理」を参照してください。 注:データベースが自動的に作成されるよう設定した場合は,作成後にデータ ベースの設定を行うことを強くお勧めします。詳細については,22 ページ 「データベースの設定」を参照してください。 管理スキーマおよびプロファイル・スキーマを作成するスクリプトの手作業で の実行 本項の推奨事項に従ってデータベースそのものを手作業で作成することをお勧 めします。さらに,管理スキーマまたはプロファイル・スキーマ(表構造), あるいはその両方を,Mercury Business Availability Center で自動的に作成せず に,それらを生成するスクリプトを手作業で実行することをお勧めします。 注:本項の推奨事項に従って CMDB を手作業で作成する場合,標準の表構造を 格納している既存の CMDB に接続できないため,CMDB を生成するスクリプ トを実行する必要があります。Mercury Business Availability Center に CMDB を 作成し,接続する手順の詳細については,『プラットフォームの管理』の 「Mercury ユニバーサル CMDB の管理」を参照してください。 注:Mercury Business Availability Center は,管理データベース・オブジェクト格 納用のファイル・グループと,プロファイル・データベース・オブジェクト格 納用のファイル・グループを,それぞれ 2 つずつ自動的に作成します。ファイ ル・グループを追加する手順の詳細については,付録 B「データ格納域の推奨 事項」を参照してください。 管理用スキーマ作成スクリプトとプロファイル・スキーマ作成スクリプトは, <コア・サーバのルート・ディレクトリ> \AppServer\webapps\site.war \DataBases\SQL_Svr_DB_Utils ディレクトリにあります。 15 15 第 2 部 • MS SQL Server データベースの導入と保守 管理用スキーマ(標準設定の CMDB を含む)を作成するには,次の手順を実 行します。 次のスクリプトを実行します。 ➤ common_sql_dbobjects_create.sql ➤ management_sql_dbobjects_create.sql ➤ create_cm_tables_cmdb_ms.sql CMDB スキーマを作成するには,次の手順を実行します。 次のスクリプトを実行します。 ➤ common_sql_dbobjects_create.sql ➤ create_cm_tables_cmdb_ms.sql プロファイル・スキーマを作成するには,次の手順を実行します。 次のスクリプトを実行します。 ➤ profile_sql_dbobjects_create.sql これらのスクリプトを修正する場合(たとえば,データ・オブジェクト,イン デックス・オブジェクト,およびラージ・オブジェクトに使用するユーザ定義 のファイル・グループを指定する場合など)は,必ずスクリプトのコピーを作 成してコピーの方を修正し,クエリ・アナライザまたは OSQL を使用して手作 業で実行します。 注:以上の手順は,操作に詳しい MS SQL Server データベース管理者のみが実 行してください。 管理スキーマまたはプロファイル・スキーマ,あるいはその両方を作成した後 は,データベース・スキーマ検証プログラムを実行して,データベースが正し く設定されていることを確認することを強くお勧めします。検証処理の詳細に ついては,付録 D「データベース・スキーマの検証」を参照してください。 16 第 3 章 • MS SQL Server データベースの作成と設定 データベース権限 データベースを作成するには,CREATE DATABASE 権限が必要です。既存の データベースに接続するには,接続に使用するログイン・アカウントをデータ ベースの dbo にマップしておく必要があります。 注:sysadmin サーバ・ロールのメンバは,自動的に CREATE DATABASE 権限 が付与され,すべてのデータベースの dbo にも自動的にマップされます。デー タベースの所有者は自動的にデータベースの dbo にマップされます。 CREATE DATABASE 権限をユーザに付与するには,まず最初に,ユーザのログイ ンを master データベースのデータベース・ユーザにマップする必要があります。 以下の 3 つの方法のいずれか 1 つを実行して,必要なデータベースの dbo に ユーザのログインをマップします。 ➤ ユーザを sysadmin サーバ・ロールのメンバにします(これによって,ユーザに はサーバで行える作業に関して最も強力な権限が与えられることに注意してく ださい)。 ➤ EXEC sp_changedbowner 'login' を使用してユーザをデータベースの所有者に します。 ➤ EXEC sp_addalias 'login', 'dbo' を使用してユーザ・ログインをデータベースの dbo の別名にします。 ユーザがデータベースの所有者かどうかを確認するには,次を実行します。 EXEC sp_helpdb <データベース名> ユーザに CREATE DATABASE 権限があるかどうかを確認するには,権限を確 認するユーザのログイン・アカウントを使用してクエリ・アナライザにログイ ンし,次を実行します。 USE master IF PERMISSIONS() & 1 = 1 PRINT 'User has CREATE DATABASE permissions' ELSE PRINT 'User does not have CREATE DATABASE permissions' 17 17 第 2 部 • MS SQL Server データベースの導入と保守 ユーザがデータベースの dbo にマップされているかどうかを確認するには, マッピングを確認するユーザのログイン・アカウントを使用してクエリ・アナ ライザにログインします。そして,データベース・コンテキストを当該データ ベースに変更し,次を実行します。 SELECT USER_NAME() データベース・ファイルのレイアウト データベースを作成するときは,少なくとも 1 つのデータ・ファイル(拡張子 .mdf)と 1 つのトランザクション・ログ・ファイル(拡張子 .ldf)で構成する必 要があります。必要に応じて,データ・ファイル(.ndf)やログ・ファイル (.ldf)を追加で作成することもできます。 パフォーマンスの向上を図るために,複数のデータ・ファイルを作成すること もできます。その場合,MS SQL Server によってデータ・ファイル間でデータ のストライピングが行われます。これにより,データのストライピングを行う RAID コントローラがない場合でも,データ・ファイルを通常の複数の物理 ディスクに分散してデータをストライピングできます。ただし,ログについて はシーケンシャルに読み取りが実行されるため,ログ・ファイルの数を増やし てもパフォーマンスは向上しません。追加のログ・ファイルは,既存のログ・ ディスク領域が足りなくなったときに,別のディスクに作成してください。 データとログの配置 データ・ファイルとログ・ファイルは別々のディスク・サブシステムに配置す ることをお勧めします。変更はログに書き込まれるまでデータベースにフラッ シュされることはありません。また,ログのアーキテクチャでは書き込みが連 続的に実行されます。そのため,可能な限りログに関する処理を妨げないよう にする必要があります。ログは書き込みが連続的に実行されるため,通常は RAID 1 システムに配置すれば十分です。ログから読み取りを行うプロセスがあ る場合(たとえば,ログ・レコードまたはトランザクション・レプリケーショ ンによって構成される挿入ビューと削除ビューにアクセスするトリガがある場 合など),または,別のデータベースに使用される複数のログ・ファイルがあ る場合は,ログ・ファイルを RAID 0+1 (ストライピングとミラーリング)シ ステムに配置することを検討してください。 データ・ファイルは,最適なパフォーマンスが得られるよう RAID 0+1 システ ムに配置します。 18 第 3 章 • MS SQL Server データベースの作成と設定 注:データ・ファイルおよびログ・ファイルは,ページ(スワップ)ファイル が格納されるディスクとは別のディスクに格納することをお勧めします。 ファイルおよびデータベースのプロパティ データベースを作成するときは,次の 5 つのプロパティを各ファイル(.mdf, .ndf,.ldf)について指定できます。 ➤ NAME : 後でプロパティのいずれかを変更するときに使用できる論理ファイル名。 ➤ FILENAME : 物理ファイルのパスと名前。作成先ディレクトリが圧縮されてい ないことを確認します(Windows エクスプローラでディレクトリを右クリック して[プロパティ]を選択します。[全般]タブで[詳細]ボタンをクリック し,[属性の詳細]ダイアログ・ボックスで圧縮に関するチェック・ボックス が選択されていないことを確かめます)。 ➤ SIZE : ファイルの初期サイズ。 ➤ MAXSIZE : ファイルの最大サイズ。ファイルがこのサイズになるまで拡張が可 能です。この引数を省略した場合,または UNLIMITED を指定した場合は, ディスクがいっぱいになるまでファイルの拡張が可能です。 ➤ FILEGROWTH : ファイルを自動拡張する際の増分量。この引数には,既存の ファイル・サイズに対するパーセンテージ,または固定のサイズのどちらかを 指定できます。詳細については,第 6 章「MS SQL Server サイズ設定ガイドラ イン」を参照してください。 19 19 第 2 部 • MS SQL Server データベースの導入と保守 注:クライアントから送信された変更通知によって自動拡張処理が開始され, クライアントがタイムアウトした場合,拡張処理は正常に終了しません。この ため,次回クライアントが変更通知を送信したときには,自動拡張処理が初め から開始され,再びタイムアウトする可能性があります。この問題を回避する には,データベースが容量の上限近くに達するたびに(たとえば,空き容量が 残り 20% を下回るなど)ファイルを手動で拡張するか,または拡張の増分量 を,クライアントのタイムアウト設定よりも短い時間で割り当てることが可能 な固定サイズで設定することをお勧めします。一般に,ほとんどのシステムで は 30 秒以内に 100 MB を割り当てることが可能です。これは,クライアントの 一般的なタイムアウト設定と同じです。この問題の詳細については,Microsoft Knowledge Base Article - 305635 (http://support.microsoft.com/default.aspx?scid=kb;en-us;Q305635)を参照してくだ さい。 ファイル・グループ ファイル・グループとはデータ・ファイルを論理的にグループ化したものを指 します。以下の各オブジェクトは,それぞれ個別のファイル・グループ単位に 含めることができます。 ➤ テーブルのデータ ➤ テーブルのラージ・オブジェクト(text 列,ntext 列,image 列) ➤ インデックス データは,オブジェクトの格納先であるファイル・グループに属しているすべ てのファイルに,各ファイルの空き容量に比例して挿入されます。.mdf ファイ ルは PRIMARY ファイル・グループに配置されます。このグループは,データ ベースの作成時には Default のファイル・グループとしてマークされています (ファイル・グループが指定されていないときの,オブジェクトの既定のファ イル・グループ)。ほかのデータ・ファイル(.ndf ファイル)を個別のファイ ル・グループに配置しない場合は,それらのファイルも PRIMARY ファイル・ グループに配置されます。Default のファイル・グループは後で変更できます。 ファイル・グループはパフォーマンス・チューニングや保守に利用できます。 詳細については,MS SQL Server 2000 Books Online を参照してください。また, 格納域やパフォーマンス・チューニングに関連するホワイト・ペーパー (http://support.microsoft.com/common/canned.aspx?R=d&H=SQL%20Server%20200 20 第 3 章 • MS SQL Server データベースの作成と設定 0%20White%20Papers&LL=kbSQLServ2000Search&Sz=kbwhitepaper&CDID=ENUS-KB&LCID=1033)も参照してください。 ファイル・グループを保守のために使用する方法の例を次に示します。 ➤ 部分的復元 : MS SQL Server 2000 では,単一のテーブルの復元がサポートされ ていません。単一のテーブルをファイル・グループに配置した場合でも,残り のデータよりも前の時点までファイル・グループを復元することはできませ ん。その代わりに,ファイル・グループと残りのデータとの同期をとるため に,すべてのログ・ファイルのバックアップを適用する必要があります。MS SQL Server 2000 は,別の名前が付いたデータベースへの部分的復元をサポート しています。部分的復元では,単一のファイル・グループを復元でき,指定し た時点までの復元がサポートされています。ただし,PRIMARY ファイル・グ ループに SYSTEM テーブルが格納されているため,必ず PRIMARY ファイル・ グループを復元する必要があります。 論理的なエラーが発生した場合に,単一のテーブルを指定した時点まで復元で きるようにするには,データベースのファイル・グループの構成を以下のよう に設定する必要があります。 ➤ PRIMARY ファイル・グループ内に .mdf ファイルだけを配置します。 ➤ 大きなテーブルをそれぞれ個別のファイル・グループに配置します。 ➤ 小さなテーブルをすべて,別の 1 つのファイル・グループに配置します。 システム・データベース MS SQL Server の良好なパフォーマンスを実現する上で,次のシステム・デー タベースは特に重要です。 ➤ tempdb : tempdb システム・データベースは,MS SQL Server のさまざまな処理 において明示的にまたは暗黙のうちに使用されます。これらの活動には,ロー カルおよびグローバルの一時テーブルの作成,クエリ実行の中間結果をスプー ルするために暗黙のうちに実行される作業テーブルの作成,ソート処理,など があります。システムが正しく設定されていないと,tempdb データベースがパ フォーマンスのボトルネックになることがあります。そのため,tempdb データ ベースの初期サイズを正しく決定することが非常に重要です。データベース・ サイズの設定の詳細については,第 6 章「MS SQL Server サイズ設定ガイドラ イン」を参照してください。tempdb のファイルを移動するには,ALTER DATABASE tempdb MODIFY FILE コマンドを使用し,MS SQL Server を再起動 します。 21 21 第 2 部 • MS SQL Server データベースの導入と保守 ➤ master,msdb,model : これらのデータベースは MS SQL Server を運用する上で きわめて重要ですが,メタ・データのみが格納されるため,tempdb よりもサイ ズの小さいデータベースです。これらデータベースの格納先には,フォールト・ トレラントなディスク(RAID 1 が理想的)を使用することをお勧めします。 注:Mercury Business Availability Center の認定を受けるには,システム・データ ベースをフォールト・トレラントなディスクに配置します。 データベースのプロパティを確認するには,次を実行します。 EXEC sp_helpdb <データベース名> データベースの設定 必要なデータベースの作成が完了したら,データベースに新しいファイルを追 加したり,既存のデータベース・ファイルのプロパティを変更したり,データ ベース設定オプションを適宜設定したりできます。 注:Mercury Business Availability Center によって管理データベースおよびプロ ファイル・データベースが自動的に作成されるようにした場合は,本項で説明 している設定手順に従ってこれらのデータベースを設定することを強くお勧め します。 データベース・ファイルの設定 データベース・ファイルの特定のプロパティの変更や,ファイルの追加および 削除は,Enterprise Manager の[プロパティ]ダイアログ・ボックスか,または ALTER DATABASE コマンドを使用して実行できます(詳細については,MS SQL Server 2000 Books Online を参照してください)。 ファイルの追加 データ・ファイルは,データベースの既存のファイル・グループまたは新規の ファイル・グループに追加できます。特別な制約や要件はありません。 22 第 3 章 • MS SQL Server データベースの作成と設定 ファイルの削除 ファイルを削除するには,まず DBCC SHRINKFILE コマンドの EMPTYFILE オ プションを使用してファイルを空にする必要があります。これにより,ファイ ルのデータがファイル・グループ内のほかのすべてのファイルに送信されま す。ファイルを空にしたら,ALTER DATABASE <データベース名> DROP FILE コマンドを使用してファイルを削除できます。 ファイルのプロパティの変更 すべてのデータベースについて,サイズに関連するプロパティを変更できるほ か,tempdb データベースについては,ファイル名プロパティを変更できます (この変更は MS SQL Server の再起動後に有効になります)。SIZE プロパティ, MAXSIZE プロパティ,および FILEGROWTH プロパティは,ALTER DATABASE tempdb MODIFY FILE コマンドを使用して変更できます。SIZE プロ パティは拡大だけが可能です。ファイルを縮小するには DBCC SHRINKFILE コ マンドを使用します。ファイルのプロパティの詳細および推奨事項について は,14 ページ「データベースの作成」を参照してください。 23 23 第 2 部 • MS SQL Server データベースの導入と保守 データベース設定オプション 各データベースには,データベース自身の振る舞いを決める 1 組の設定オプ ションが格納されています。データベース・オプションは次を使用して表示ま たは変更できます。 ➤ Enterprise Manager の[プロパティ]ダイアログ・ボックスの[オプション]タブ 注:このダイアログ・ボックスでは,一部のデータベース設定オプションは使 用できません。 ➤ sp_dboptions ストアド・プロシージャ ➤ ALTER DATABASE <データベース名> SET コマンド 24 第 3 章 • MS SQL Server データベースの作成と設定 次の表は,標準の設定オプションと,Mercury Business Availability Center の認定 に必要な設定を示します。 標準 MS SQL Server 2000 における Mercury Business Availability Center の認定 設定オプション 説明 アクセスを制限 する 未設定(MULTI_USER) 単一のユーザまたは db_owner,dbcreator, sysadmin の各グループ のメンバだけがデータ ベースにアクセスでき ます。 MULTI_USER 読み取り専用 データベースが読み取 未設定(READ_WRITE) り専用になります。 READ_WRITE 復旧 データベースの復旧モ 完全 デルのレベルによっ て,復旧の能力が決ま ります。復旧モデルの レベルに応じて,バル ク操作ログ(Select into,Bulk,Insert, Create index,LOB 操作 など)の量が制御され ます。復旧モデルのレ ベルが高いほど,復旧 能力が高くなります。 ただし,復旧能力が高 くなる分ログの量も増 えるため,パフォーマ ンスに影響を与える可 能性があります。 完全(より低い 復旧能力でシス テムが十分対応 できることが確 実にわかってい る場合を除く) チェックポイン ト時のログの切 り捨て ログの非アクティブ部 未設定 分を自動的にマーク し,チェックポイント で再利用できるように します。 N/A 25 25 第 2 部 • MS SQL Server データベースの導入と保守 26 標準 MS SQL Server 2000 における Mercury Business Availability Center の認定 設定オプション 説明 Select into/bulk copy 未設定 最小限のログを残す select into/bulk copy 操 作を使用できるように します。 N/A ANSI NULL 既 定値(表の下の 注を参照) データベース列の標準 未設定 の定義を NULL または NOT NULL として指 定します。 未設定 再帰トリガ 再帰トリガがサポート 未設定 されるかどうかを指定 します。 未設定 統計の自動更新 クエリの最適化に必要 設定済み となる失効データに関 する統計情報が,最適 化中に自動的に作成さ れるかどうかを指定し ます。 設定済み 統計の自動作成 クエリの最適化に必要 設定済み となる欠落データに関 する統計情報が,最適 化中に自動的に作成さ れるかどうかを指定し ます。 設定済み 破損ページ検出 不完全なページを検出 設定済み できるようにするかど うかを指定します。 設定済み 第 3 章 • MS SQL Server データベースの作成と設定 説明 自動終了 データベースのリソー 未設定 スが解放され,すべて のユーザがログアウト した後に,データベー スをシャットダウンす るかどうかを指定し ます。 未設定 未設定 25% の空き領域を確 保するため,データ ベースを 1 時間おきに 自動的に圧縮するかど うかを指定します。 未設定 自動圧縮 標準 MS SQL Server 2000 における Mercury Business Availability Center の認定 設定オプション 注 : 設定した場 合,データ ベースの終了 後,ユーザが 接続するたび にデータベー スによるリ ソースの割り 当てに時間が かかることが あります。 注 : 設定した場 合,定常的な拡 張や縮小によっ てファイル・シ ステムの断片化 が生じることが あります。 27 27 第 2 部 • MS SQL Server データベースの導入と保守 標準 MS SQL Server 2000 における Mercury Business Availability Center の認定 設定オプション 説明 引用符で囲まれ た識別子を使用 MS SQL Server におい 未設定 て,引用符に関する ANSI 規則を適用する かどうかを指定しま す。二重引用符を, 列やテーブル名など の識別子に対しての み使用することを指 定する場合に,この オプションを選択し ます。この場合,文 字列を単一引用符で 囲む必要があります。 未設定 互換性レベル データベースの(アプ 80 リケーションに対す る)見かけ上の MS SQL Server のバージョ ンです。 80 注:Enterprise Manager では,すべての ANSI オプションを設定できるわけでは ありません。ANSI データベース設定オプションには,ANSI_NULLS, QUOTED_IDENTIFIER,ANSI_NULL_DEFAULT,ANSI_PADDING, ANSI_WARNINGS,ARITHABORT,NUMERIC_ROUNDABORT, CONCAT_NULL_YIELDS_NULL などがあります。なお,設定したオプション は,より上位のオプション設定が優先されるため,有効にならない場合があり ます。たとえば,セッション・オプション QUOTED_IDENTIFIER をオンにし た場合,このオプションと同等のデータベース設定オプションは無視されま す。ツールやデータベース・インタフェースによっては,特定のセッション・ オプションをオンまたはオフに切り替えるものがあります。そのような場合は 関連するデータベース設定オプションは反映されません。 28 第 3 章 • MS SQL Server データベースの作成と設定 次の表は,各復旧モデルの特性を示します。 モデルまたは サポート ログのバッ クアップが 可能 指定時点また はログ・マー クまでの復元 が可能 データ・ク ラッシュ時の バックアッ プ・ログが可 能(クラッ シュ時点まで の変更を保存) バルク操作ロ グの量(バル ク操作のパ フォーマンス に影響を与え る可能性あ り) 簡易 × × × 最小 バルク・ログ ○ × × 最小 完全 ○ ○ ○ 完全 データベースのプロパティを確認するには,次を実行します。 EXEC sp_helpdb <データベース名> 29 29 第 2 部 • MS SQL Server データベースの導入と保守 30 第4章 MS SQL データベースへのアクセスにおける Windows 認証の使用 特に設定しない限り,Mercury Business Availability Center は MS SQL データベー スへのアクセスに MS SQL サーバ認証を使用します。本章では,Mercury Business Availability Center での MS SQL データベースへのアクセスにおいて, Windows 認証の使用を有効にする方法について説明します。 本章の内容 ページ Mercury Business Availability Center の Windows 認証機能の有効化 32 Windows 認証を使用した MS SQL データベースへの接続 35 31 第 2 部 • MS SQL Server データベースの導入と保守 Mercury Business Availability Center の Windows 認証機能の有 効化 Mercury Business Availability Center では,Mercury Business Availability Center データベース(管理データベース,プロファイル・データベース,および CMDB)へのアクセスに,MS SQL Server 認証の代わりに,Windows 認証を使 用できます。 MS SQL データベースへのアクセスにおいて Windows 認証を使用できるように するには,Mercury Business Availability Center のすべてのサーバ上で,指定デー タベースへの必要なアクセス権を持ったユーザが Mercury Business Availability Center サービスを起動する必要があります。Windows 認証を使用した MS SQL データベースへの接続の詳細については,35 ページ「Windows 認証を使用した MS SQL データベースへの接続」を参照してください。 注:標準設定では,Mercury Business Availability Center サービスはデータベース への必要なアクセス権を持たないシステム・サービスとして実行されます。 特定のユーザで Mercury Business Availability Center サービスを実行するには, 次の手順を実行します。 1 < Mercury Business Availability Center のホーム> \bin \SupervisorStop.bat ファイルを編集し,最後にある,次の行の先頭に rem を 追加してコメント・アウトします。 rem magentservice.exe –remove 2([スタート]>[プログラム]>[Mercury Business Availability Center] >[Administration]>[Disable Business Availability Center]を選択し て,Mercury Business Availability Center サービスを停止します。 32 第 4 章 • MS SQL データベースへのアクセスにおける Windows 認証の使用 3[スタート]>[プログラム]>[管理ツール]>[サービス]を選択します。 [サービス]ウィンドウが表示されます。 33 33 第 2 部 • MS SQL Server データベースの導入と保守 4[サービス]ウィンドウで,Mercury Business Availability Center サービスを右ク リックし, [プロパティ]を選択します。 [プロパティ]ウィンドウが開きます。 5[ログオン]タブを選択します。 6[アカウント]を選択し,データベースへのアクセス権を持ったユーザ名とパ スワードを入力します。 7[OK]をクリックします。 8([スタート]>[プログラム]>[Mercury Business Availability Center] >[Administration]>[Enable Business Availability Center]を選択して, Mercury Business Availability Center サービスを起動します。 9 すべての Mercury Business Availability Center サービスでこの手順を繰り返します。 34 第 4 章 • MS SQL データベースへのアクセスにおける Windows 認証の使用 注:Mercury Business Availability Center をアンインストールするときは,アンイ ンストールを実行する前に,手順 1 で< Mercury Business Availability Center > \bin\SupervisorStop.bat ファイルに追加したコメント記号(rem) を削除し,< Mercury Business Availability Center のホーム> \bin \SupervisorStop バッチ・ファイルを実行する必要があります。Mercury Business Availability Center のアンインストールの詳細については,『サーバの導 入』の「Mercury Business Availability Center サーバのアンインストール」を参照 してください。 注:Mercury Business Availability Center のパージ・マネージャの実行には, Mercury Business Availability Center サービスを実行するユーザに DLL に対する 権限が必要です。パージ・マネージャの詳細については,161 ページ「データ のパーティショニングとパージ」を参照してください。 Windows 認証を使用した MS SQL データベースへの接続 MS SQL データベースへのアクセスに,Mercury Business Availability Center で Windows 認証を使用できるようにする(詳細については,32 ページ「Mercury Business Availability Center の Windows 認証機能の有効化」を参照)と,すべて の Mercury Business Availability Center データベース(管理データベース,プロ ファイル・データベース,および CMDB)に,MS SQL サーバ認証の代わりに Windows 認証を使って接続できます。 注:異なるデータベースへの接続には,Windows 認証と MS SQL サーバ認証を 組み合わせることができます。 管理データベースへの接続 Windows 認証を使って既存の管理データベースに接続できます。また, Windows 認証を使って新しい管理データベースを作成し,接続できます。 35 35 第 2 部 • MS SQL Server データベースの導入と保守 Windows 認証を使って既存の管理データベースへ接続するには,次の手順を実 行します。 1 管理データベースへ接続する Mercury Business Availability Center サーバで, [スタート]>[ファイル名を指定して実行]を選択し,[名前]フィールドに CMD と入力して,コマンド・ウィンドウを開きます。 2 次のコマンドを使用して,Mercury Business Availability Center の scripts ディレ クトリへ移動します。 cd < Mercury Business Availability Center のホーム> \scripts 3 次のパラメータを使用して,setmngdb バッチ・ファイルを実行します。 setmngdb connect MS-SQL " < SQL Server 名> , <管理データベース名> ,,, < SQL インスタンス・ポート> " 各項目について説明します。 ➤ SQL Server 名は,管理データベースがある MS SQL Server のホスト名または IP アドレスです。 ➤ 管理データベース名は,接続している管理データベースの名前です。 ➤ 次の 2 つのパラメータはユーザ名とパスワードで,Windows 認証の場合は空白 のままにします。 ➤ SQL インスタンス・ポートは,データベースへの接続に使用される MS SQL Server 上のポート番号です。 注:Mercury Business Availability Center プログラム・メニューの[Connect to Database]オプションからは,ユーザ名とパスワード・データを空白のままに できないため,Windows 認証を使った MS SQL データベースへの接続はできま せん。 36 第 4 章 • MS SQL データベースへのアクセスにおける Windows 認証の使用 Windows 認証を使って既存の管理データベースへ接続するには,次の手順を実 行します。 Windows 認証を使って既存の管理データベースへ接続するには,前述の手順と 同じ手順を実行しますが,connect オプションの代わりに create オプション を使って setmngdb バッチ・ファイルを実行します。 setmngdb create MS-SQL " < SQL Server 名> , <管理データベース名> ,,, < SQL インスタンス・ポート> " 注:setmngdb バッチ・ファイルは,MS SQL ターゲット・サーバでデータベー ス権限を作成したユーザとして実行する必要があります。 CMDB への接続 既存の CMDB への接続,または新規 CMDB の作成および接続には,[プラット フォームの管理]の[セットアップと保守]タブからアクセスできる[CMDB データベース管理]ページの Windows 認証を使用します。CMDB データベース 管理の詳細については, 『プラットフォームの管理』の「Mercury ユニバーサル CMDB の管理」を参照してください。 プロファイル・データベースへの接続 既存のプロファイル・データベースへの接続,または新規プロファイル・デー タベースの作成および接続には,[プラットフォームの管理]の[セットアッ プと保守]タブからアクセスできる[データベース管理]ページの Windows 認 証を使用します。プロファイル・データベース管理の詳細については,『プ ラットフォームの管理』の「データベースの管理」を参照してください。 37 37 第 2 部 • MS SQL Server データベースの導入と保守 38 第5章 MS SQL Server データベースの保守 本章では,MS SQL Server 上に作成した Mercury Business Availability Center デー タベースに対して推奨される各種の保守作業について説明します。具体的に は,データベースのバックアップ,データベースの整合性の検査,フラグメン テーションへの対処,およびデータベースの監視について説明します。 本章の内容 ページ データベースのバックアップ 40 データベースの整合性とフラグメンテーション 44 データベースの監視 55 データベースの保守 : 参考資料 59 39 第 2 部 • MS SQL Server データベースの導入と保守 データベースのバックアップ MS SQL Server では,データベースの主要なバックアップ方法として,全体 バックアップ,差分バックアップ,ログ・バックアップの 3 タイプがサポート されています。また,ファイルのバックアップと,ファイル・グループのバッ クアップもサポートされています。これらについては以降の別の項で説明しま す。復旧に関するニーズに応えるバックアップ方針を決定するには,各バック アップのタイプと,前項で説明した復旧モデルのデータベース設定オプション について,十分に理解する必要があります。 バックアップ操作は MS SQL エージェント・ジョブを使用して自動化できま す。MS SQL エージェント(SQLServerAgent サービス)は MS SQL Server のイ ンストール時に自動的にインストールされます。オペレーティング・システム の[サービス]アプレットで,MS SQL エージェントがサーバの起動時に自動 起動するように設定されていることを確認します。 次の内容は,すべてのタイプのバックアップに該当します。 ➤ バックアップには,バックアップが完了するまでに発生したすべての変更が含 まれます。 ➤ バックアップはオンラインで実行できますが,バックアップ処理はシステムの パフォーマンスに悪影響を及ぼす可能性があるため,データベースのバック アップはそのほかの処理が少ない時間帯に行うことをお勧めします。 ➤ 以下の操作をバックアップ処理中に実行しないようにします。 ➤ ファイルの追加または削除 ➤ データベースの圧縮 ➤ バックアップ先には,ディスク・デバイス(ローカル,または MS SQL Server サービス・アカウントがアクセス許可を必要とする共有ネットワーク上のも の)か,またはテープ(ローカルのみ)を指定できます。 全体バックアップ データベース全体のバックアップを行うと,データ,メタ・データ,ファイル 情報など,バックアップ対象のデータベースに関するすべての情報がバック アップに格納されます。全体バックアップは差分バックアップおよびログ・ バックアップの土台となります。小さなデータベース(たとえば,主にメタ・ データを格納するシステム・データベースなど)では,全体バックアップを毎 日実行することをお勧めします。大きなデータベース(管理データベースやプ 40 第 5 章 • MS SQL Server データベースの保守 ロファイル・データベースなど)では,一般に,期間を空けて(1 週間に 1 回 など)全体バックアップを実行することをお勧めします。 全体バックアップの格納に必要な記憶容量は,ファイルに占めるデータ部の格 納に必要な記憶容量とほぼ同じです。たとえば,データ・ファイルの合計サイ ズが 20 GB で,そのうち 15 GB だけが使用されている場合(5 GB の空き領域 がある場合)は,データベース全体のバックアップにはおよそ 15 GB 必要とな ります。 差分バックアップ 差分バックアップは,最後の全体バックアップ以降に変更のあったエクステン ト(8 KB のページが 8 個連続するブロック)のバックアップに使用します。 データベースを復元するときは,全体バックアップの後に実行された最後の差 分バックアップを復元するだけで済みます。MS SQL Server 2000 の差分バック アップのパフォーマンスは MS SQL Server 7.0 のパフォーマンスよりも優れてい ます。MS SQL Server 7.0 では,データベース全体を走査して個々のエクステン トを読み取って,最後の全体バックアップ後に変更が生じたかどうかを確認し ていました。これに対して MS SQL Server 2000 では,変更のあったエクステン トをマッピングするビットマップがファイルごとに用意されており,差分バッ クアップ時には該当するエクステントだけが読み取られるようにディスクの読 み取り装置が操作されます。 インデックスの再構成やフラグメンテーションの解消など,データの大きな部 分に影響を与えるような操作を実行した後は,全体バックアップを実行するこ とをお勧めします。このような場合に全体バックアップを実行しないで差分 バックアップを行うと,バックアップのサイズが非常に大きくなることがあり ます。インデックスの再構成およびフラグメンテーション解消の詳細について は,44 ページ「データベースの整合性とフラグメンテーション」を参照してく ださい。 通常,差分バックアップは全体バックアップの合間に実行するようスケジュー ルを設定します。たとえば,全体バックアップを週に一度実行する場合は,差 分バックアップを毎日,または 1 日に数回,実行します。 差分バックアップの格納に必要な記憶容量は,最後の全体バックアップ以降に 変更のあったエクステント(64 KB のブロック)の合計サイズです。 41 41 第 2 部 • MS SQL Server データベースの導入と保守 ログ・バックアップ 全体バックアップおよび差分バックアップは,主にエクステントのイメージを バックアップすることを中心としています。一方ログ・バックアップはこのよ うな方法とは異なり,トランザクション・ログに基づいてトランザクションを バックアップし,復元時にそれらを再生します。ログ・バックアップを実行す るためには,データベースを完全復旧モデルまたはバルク・ログ復旧モデルに 設定する必要があります。指定した時点またはログ・マークまでの復元を実行 する場合,あるいはデータのクラッシュ時にログに記録された変更をバック アップする場合は,データベースを完全復旧モデルに設定する必要がありま す。完全復旧モデルに設定していない場合は,最後のバックアップ以降に行わ れた変更がすべて失われます。 ログ・バックアップは本質的には増分バックアップであり,前回のログ・バッ クアップ以降に実行されたトランザクションだけがバックアップされます。 データベースを復元するときは,復元した最後の差分(または全体)バック アップ以降のログ・バックアップをすべて復元する必要があります。 また,ログ・バックアップでは,バックアップされた部分のログが「再利用可 能」とマークされます。完全復旧モデルまたはバルク・ログ復旧モデルに設定 されたデータベースでは,バックアップされなかった部分のログは再利用でき ません。ログがいっぱいになり,MS SQL Server がログの先頭に戻るためのロ グ循環を実行できず,ログ領域を再利用できなくなったときは,ログを拡張す る必要があります。したがって,ログ・バックアップの頻度は,トランザク ション・ログに必要なサイズを決める要素になります。ログ・バックアップを 頻繁に行えば,トランザクション・ログのサイズを小さく抑えることができま す。ログは可能な限り頻繁に(たとえば 30 分ごとに)バックアップすること をお勧めします。 ファイルのバックアップとファイル・グループのバックアップ データベース全体をバックアップするのではなく,ファイル単位またはファイ ル・グループ単位でバックアップすることもできます。ただし,1 つのファイ ルまたはファイル・グループを復元するときは,ファイルまたはファイル・グ ループとデータベースの残りの部分との間で同期をとる(同じ時点の状態にす る)ために,障害発生時点までを含むすべてのログのバックアップを適用する 必要があります。このタイプのバックアップは,一般に全体バックアップを頻 繁に実行することのできない,非常に大規模なデータベースに適しています。 42 第 5 章 • MS SQL Server データベースの保守 保守計画 MS SQL Server Enterprise Manager の[管理]ツリー・ビューの下に, [データベー ス保守計画]というグラフィカル・ツールがあります。このツールを使用して, 一般的な保守作業(全体バックアップ,ログ・バックアップ,整合性検査,イン デックスの再構成,統計情報の収集)を定義して自動的に実行できます。 トランザクション・ログに関する問題 ログは,保守の観点から見た場合,取り扱いに十分注意する必要があります。 ログがいっぱいになると,まず,バックアップ済みで非アクティブのログ領域 の循環と再利用が試みられますが,そのような領域が存在しなければ,ファイ ルの拡張が試みられます。ファイルを拡張する余地がなければ,MS SQL Server によってデータ変更要求が拒否されます。ログの領域不足を防ぐには,十分大 きなログ領域を確保し,頻繁にバックアップを行います(スケジュールに従っ て定期的にバックアップするのが理想的です) 。また,ログのアクティブ部分と は,処理が完了していない最も古いトランザクションから始まり,ログ内の現 在のポインタの位置まで続きます。このアクティブ部分の再利用や切り捨ては できません。トランザクションの処理が完了しないまま長い時間が経つと,た とえログをバックアップしていたとしても,ログがいずれ領域不足に陥ります。 このような問題の有無を調べるには,DBCC OPENTRAN を実行して,最も長 い時間完了しないままになっているトランザクションを取得します。該当する トランザクションを実行しているプロセスを終了してそのトランザクションの 処理をロールバックするには,KILL <プロセス ID > コマンドを使用します。 注:MS SQL Server 2000 では,DBCCSHRINKFILE コマンドは常に正常に実行 されます。 43 43 第 2 部 • MS SQL Server データベースの導入と保守 データベースの整合性とフラグメンテーション データベース・オブジェクトの物理的な整合性について定期的に検査し,パ フォーマンス低下の主な原因となるインデックスのフラグメンテーションの問 題に対処することが重要です。 データベースの整合性 DBCC CHECKDB を定期的に実行し,データベース内のオブジェクトの割り当 てと構造上の整合性を検査することをお勧めします。DBCC CHECKDB コマン ドは MS SQL エージェント・ジョブを使用して実行を自動化したり,スケ ジュールを設定して実行したりできます。次の構文を使用します。 DBCC CHECKDB (' <データベース名> ') 注:WITH NO_INFOMSGS オプションを使用して,処理量と tempdb の使用率 を減らすことができます。PHYSICAL_ONLY オプションを使用して,物理面 (ページ構造とレコード・ヘッダ)のみの簡単なテストを実行することもでき ます。 MS SQL Server 2000 では,データベースにスキーマ・ロック(スキーマの変更 を防ぐもの)だけが保持され,データ変更ロックは保持されません。そのた め,DBCC CHECKDB コマンドをオンラインで実行できます。ただし,DBCC CHECKDB コマンドはそのほか処理が少ない時間帯に実行することをお勧めし ます。これは,システムのパフォーマンスに悪影響を及ぼす可能性があるため です(DBCC CHECKDB は CPU とディスクを集中的に使用するコマンドであ り,ソート処理のために tempdb を使用します)。 ファイル・システムのフラグメンテーションについて ファイル・システムのフラグメンテーションは,データベース・ファイルだけ でなく,すべてのディスク・ファイルが関係します。フラグメンテーション は,ファイルの新しい部分が追加されたり,既存の部分が削除されたりすると きに,同じファイルを構成する各部分がディスクのさまざまな領域に分散する ことによって生じます。ファイル・システムのフラグメンテーションが進む と,通常はそれほど深刻にはならないものの,ディスク・アクセスが遅くな り,ディスク操作の全般的なパフォーマンスが低下します。 44 第 5 章 • MS SQL Server データベースの保守 ファイル・システムのデフラグ(フラグメンテーションの解消)を行うには, ファイルの各部分をハード・ディスク上の連続するセクタに書き込み直しま す。これにより,データ・アクセスやデータ取得が速くなります。データベー ス・ファイルのフラグメンテーションを防ぐには,できるだけ大きな初期サイ ズを持つファイルを作成し,将来の変更に対処できるようにします。また, ファイルがいっぱいになって手作業で拡張するときには増分を大きくします。 データベース・ファイルの将来のサイズを予測できない場合は,小さな断片が 発生するのを防ぐために,ファイルの増分量として大きな値を使用します。た だし,あまり大きな値を使用すると,ファイルの自動拡張時にクライアント要 求がタイムアウトしてしまうため,注意が必要です(詳細については,14 ペー ジ「データベースの作成」を参照してください)。また,データベースの自動 圧縮オプションの使用は避けます。このオプションを使用すると,データベー ス・ファイルの圧縮と拡張が継続的に繰り返され,フラグメンテーションの生 じる可能性が高くなります。 注:デフラグ・ユーティリティは定期的に実行することをお勧めします。 内部フラグメンテーションについて 内部フラグメンテーションとは,ページに含まれるデータの割合のことです。 Mercury Business Availability Center システムのように,トランザクションによっ てデータが頻繁に挿入されるという特性を持つ環境では,インデックス内で新 しいデータが発生することを予測して,内部フラグメンテーションが生じ,そ れがパフォーマンス向上につながることがあります。インデックス・ページの うち一定の割合を空けておくと,一定時間ページの分断を避けることができま す。このことは,実際のデータ・ページを格納しているクラスタ化インデック スの場合に特に重要です。内部フラグメンテーションは,DROP_EXISTING オ プションと FILLFACTOR オプションを指定して CREATE INDEX コマンドを実 行するか,または DBCC DBREINDEX コマンドを実行して,インデックスを定 期的に再構成することによって,実現できます。FILLFACTOR オプションは, リーフ・レベルのインデックス・ページをどの程度の割合までいっぱいにする かを指定します。 外部フラグメンテーションについて インデックスでページの分断が発生すると,新しく割り当てられたページが データベース・ファイルから獲得されます。ページの分断が生じる場合,分断 しているページに隣接するページが割り当てられるのが理想です。しかし実際 45 45 第 2 部 • MS SQL Server データベースの導入と保守 には,分断されたページに隣接する領域はすでに使用されているのが普通で す。ページ分断の発生量が増えると,その分だけインデックスのリンク・リス トがディスク上のページの物理的なレイアウトを反映しなくなり,外部フラグ メンテーションの量が増えます。 外部フラグメンテーションは,順序付きインデックス・スキャンのパフォーマ ンスに悪影響を及ぼします。これは,ディスクからページを読み出すために ディスクの読み取り装置があちこち移動しなければならないためです。リン ク・リストには,ディスク上のページの物理的なレイアウトが反映されるのが 理想です。そうすれば,順序付きインデックス・スキャンの実行時には,ディ スクからページを読み出すときにディスクの読み取り装置が一方向に移動する ようになります。 外部フラグメンテーションに対する予防的措置として,内部フラグメンテー ションが起こるようにして,リーフ・レベルのインデックス・ページが一定の 割合空くようにします。こうすることで,しばらくの間ページの分断を避ける ことができます。すでに説明したように,内部フラグメンテーションは FILLFACTOR オプションを指定してインデックスを定期的に再構成することに よって実現できます。また,インデックスの外部フラグメンテーションの状態 を確認し,インデックスを再構成することで,外部フラグメンテーションに対 処することもできます。 DBCC SHOWCONTIG の使用方法 DBCC SHOWCONTIG を使用して,内部フラグメンテーションと外部フラグメ ンテーションの両方のフラグメンテーションの度合いを確認できます。DBCC SHOWCONTIG の構文は次のとおりです。 DBCC SHOWCONTIG [ ( { <テーブル名> | <テーブル ID > | <ビュー名> | <ビュー ID > } [ , <インデックス名> | <インデックス ID > ] ) ] [ WITH { ALL_INDEXES | FAST [ , ALL_INDEXES ] | TABLERESULTS [ , { ALL_INDEXES } ] [ , { FAST | ALL_LEVELS } ] } ] 46 第 5 章 • MS SQL Server データベースの保守 DBCC SHOWCONTIG の一部のオプションは MS SQL Server 2000 から追加され たものです。MS SQL Server 7.0 ではテーブルおよびインデックスの ID を指定 する必要がありますが,MS SQL Server 2000 ではテーブルおよびインデックス の名前をパラメータとして指定できます。 次は,Northwind サンプル・データベースの Order Details テーブルのクラスタ化 インデックスに対して実行した DBCC SHOWCONTING の出力です。 DBCC SHOWCONTIG scanning 'Order Details' table... Table:'Order Details' (325576198); index ID:1, database ID: 6 TABLE level scan performed. - Pages Scanned................................: 9 - Extents Scanned..............................: 6 - Extent Switches..............................: 5 - Avg.Pages per Extent........................: 1.5 - Scan Density [Best Count:Actual Count].......: 33.33% [2:6] - Logical Scan Fragmentation ..................: 0.00% - Extent Scan Fragmentation ...................: 16.67% - Avg.Bytes Free per Page.....................: 673.2 - Avg.Page Density (full).....................: 91.68% DBCC execution completed.If DBCC printed error messages, contact your system administrator. 内部フラグメンテーションのレベルを調べるには,平均ページ密度の値を確認 します。この値は,ページがどの程度まで埋まっているかを示すパーセンテー ジの平均値です。平均ページ密度が 100% に近いほど,内部フラグメンテー ションは少なくなります。 外部フラグメンテーションのレベルを調べるには,次の 3 つの値を確認します。 ➤ スキャン密度 : 外部フラグメンテーションを知るために確認する必要のある最 も重要な値。スキャン密度は,すべてのエクステントが連続的にリンクしてい 47 47 第 2 部 • MS SQL Server データベースの導入と保守 る場合の理想的なエクステント変更と,実際のエクステント変更との比率で す。たとえば,インデックスの消費ページ数が 8000 の場合,理想的なカウン トは 1000 になります。インデックスのフラグメンテーションの度合いが増し, 順序付きインデックス・スキャンによってエクステント間での行き来が増える と,実際のカウントが増えます。スキャン密度はパーセンテージで示されま す。100% は外部フラグメンテーションがまったく存在しないことを示し,100 % 未満の値がフラグメンテーションの度合いを示します。次の図は,スキャン 密度がどのように計算されるのかを示します。 ➤ 論理スキャン・フラグメンテーション : インデックスのリーフ・ページのス キャンから返された,順序外ページの割合。順序外ページとは,IAM(Index Allocation Map)で示された次のページが,リーフ・ページ内の次ページ・ポイ ンタによって指し示されたページと異なる場合のページのことです。論理ス キャン・フラグメンテーションの値はできるだけ低くなるようにします。0% が理想です。 ➤ エクステント・スキャン・フラグメンテーション : インデックスのリーフ・ ページのスキャン時に検出された順序外エクステントの割合。順序外エクステ ントとは,インデックスの現在のページを格納しているエクステントが,物理 的にインデックスの前のページを格納しているエクステントの直後に位置して いないエクステントのことです。エクステント・スキャン・フラグメンテー ションの値もできるだけ低くなるようにします。0% が理想です。 インデックスのフラグメンテーションを解消する時期 論理スキャン・フラグメンテーションの値が 10% 以上になったときは,次の 各項の方法を使用してインデックスのフラグメンテーションを解消することを お勧めします。論理スキャン・フラグメンテーションの値が 20% 以上になっ たときは,インデックスのフラグメンテーションを解消することを強くお勧め します。 48 第 5 章 • MS SQL Server データベースの保守 フラグメンテーションへの対応 MS SQL Server 2000 では,内部フラグメンテーションと外部フラグメンテーショ ンに対応するための方法がいくつか提供されています。特定のインデックスを CREATE INDEX ステートメントの DROP_EXISTING オプションを使用して再構 成したり,テーブルに属するすべてのインデックスを DBCC DBREINDEX ス テートメントを使用して再構成したりできます。インデックスを再構成すると, インデックスのすべてのページがリンク・リストの順にディスク上に配置され るため,外部フラグメンテーションはなくなります。なお,内部フラグメン テーションを行うための FILLFACTOR を指定することもできます。 フラグメンテーションに対応する上記の 2 つの方法は,インデックスを削除し て再作成する方法よりも優れています。これには 2 つの理由があります。1 つ には,PRIMARY KEY 制約または UNIQUE 制約によって作成されたインデック スは削除できないことがあります。これらのインデックスを削除するには,制 約を削除する必要があります。もう 1 つは,クラスタ化インデックスを削除す ると,行ロケータの変更に対応するためにすべての非クラスタ化インデックス が再作成されることです。クラスタ化インデックスを再作成するときも,同じ ことが起こります。クラスタ化インデックスが一意の場合(CREATE INDEX ス テートメントの DROP_EXISTING オプション,または DBCC DBREINDEX を使 用している場合),クラスタ化インデックスの再構築時には,非クラスタ化イ ンデックスはそのまま残ります。 フラグメンテーションに対する上記 2 つの対応方法の不利な点は,インデックス の再構成時にデータにアクセスするユーザが影響を受けるという点です。クラス タ化インデックスの再構成時には,テーブルに対する排他ロックが獲得されま す。そのため,テーブルを対象としたデータの変更と取得が,ともにできなくな ります。非クラスタ化インデックスの再構成時には,テーブルに対する共有ロッ クが獲得されるため,データの変更ができなくなります。データの取得は可能で すが,再構成中はクエリでインデックスを使用することができません。 外部フラグメンテーションに対応するのと同時に,データの取得と変更も可能 にするには,MS SQL Server 2000 から導入された DBCC INDEXDEFRAG ステー トメントを使用できます。DBCC INDEXDEFRAG ステートメントでは, CREATE INDEX ステートメントで指定された FILLFACTOR が使用されます。 新しい FILLFACTOR を指定することはできません。DBCC INDEXDEFRAG で は,インデックスのフラグメンテーション解消にバブル・アルゴリズムが使用 され,ページの並びがリンク・リストの順序を反映するまで,ページの入れ替 えが行われます。ただし,インデックス・ページがディスク上で連続的に配置 されるようにするためにインデックスが再構成されることはありません。その 49 49 第 2 部 • MS SQL Server データベースの導入と保守 ため,DROP_EXISTING オプションまたは DBCC DBREINDEX を使用してイン デックスを定期的に再構成することをお勧めします。 次の表は,フラグメンテーションを解消する 3 つの方法の相違点をまとめたも のです。 オプション DROP_EXISTING に よるインデックス 作成 ロックされるテー クラスタ化 : 排他 ブル (変更禁止,取得禁 止),非クラスタ化 : 共有(変更禁止) DBCC DBREINDEX クラスタ化 : 排他 (変更禁止,取得 禁止) ,非クラス タ化 : 共有(変更 禁止) DBCC INDEXDEFRAG オンライン : テー ブルはロックされ ません 粒度 インデックス テーブル(すべて のインデックス) またはインデック ス・レベル インデックス ページの並べ替え ○ ○ ○ 連続性の処理 ○ ○ × FILLFACTOR の 指定 ○ ○ × : 元の値の適用 を試みる インデックスのフラグメンテーション解消の詳細については,Microsoft SQL Server 2000 Index Defragmentation Best Practices サイト (http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/ss2kidbp.mspx)を 参照してください。 注:データは頻繁に更新されるため,管理データベース用と,管理データベー スと別の場合は CMDB 用の,インデックス再構築自動タスクをそれぞれ作成す ることを強くお勧めします。 50 第 5 章 • MS SQL Server データベースの保守 CMDB インデックス・フラグメンテーションへの対応 Microsoft SQL Server 2000 では,インデックスを保持したまま基盤のテーブルへ 更新を反映するため,インデックスが断片化されることがあります。作業負荷 の特性によっては,フラグメンテーションは作業負荷のパフォーマンスに悪影 響を及ぼすことがあります。 インデックスにある,キー値に基づいたページの論理順序がデータファイル内 の物理的順序と一致しない場合,フラグメンテーションが存在します。イン デックスのすべてのリーフ・ページには,インデックスの次のページと前の ページへのポインタが格納されています。これにより,すべてのインデック ス・ページとデータ・ページについて二重連結リストが形成されます。デー タ・ファイルにあるページの物理順序は論理順序に一致するのが理想です。全 体のディスク・スループットは,データの物理順序と論理順序が一致すると大 幅に向上します。これにより特定の種類のクエリのパフォーマンスが向上しま す。物理順序と論理順序が一致しないと,一方向にスキャンするだけでなく, ディスク・ヘッドがインデックス・ページの収集に進んだり戻ったりする必要 があるため,ディスク・スループットの効率が低下することがあります。フラ グメンテーションは I/O パフォーマンスに影響しますが,データ・ページが SQL Server のデータ・キャッシュに存在しているクエリのパフォーマンスには 影響しません。 インデックスを最初に構築した時点では,フラグメンテーションはほとんど, またはまったく存在しないはずです。データの挿入,更新,および削除など, 時間の経過とともに基盤のインデックスのフラグメンテーション・レベルは上 がり始めます。 インデックスが断片化されているかどうかの主な判断基準は以下のとおりです。 ➤ 論理スキャン・フラグメンテーション : 順序外ページの比率を示します。割合 は 0% から 10% の間で,割合が高いと外部フラグメンテーションを示します。 ➤ スキャン密度 : エクステントの Best Count(完全なページの場合はその数)と Actual Count の比率を示します。フラグメンテーションが原因でページが完全 でないと,Actual Count は多くなります。この比率はできるだけ 100% に近く なるようにします。 Mercury Business Availability Center には,CMDB の断片化されたインデックスの 検出と再構築に使用できる 2 つのユーティリティがあります。これらのユー ティリティでは,論理スキャン・フラグメンテーションとスキャン密度の基準 を用いて,断片化されたインデックスを検出し,指定に基づいて再構築を実行 します。断片化されたテーブルのリスト作成操作はシステムのパフォーマンス 51 51 第 2 部 • MS SQL Server データベースの導入と保守 に対してほとんど影響しないため,作業中に実行できます。インデックスの再 構築操作は,プロセス実行中にテーブルを部分的にロックしてしまうため,パ フォーマンスを妨げることがあり,CPU と入出力の使用率が高まります。イン デックスの再構築はメンテナンス・ウィンドウから行うことをお勧めします。 2 つのユーティリティは,システム管理者またはデータベース管理者が実行し てください。。 2 つのユーティリティは,Mercury Business Availability Center Modeling データ処理 サーバの < Mercury Business Availability Center のルート・ディレクトリ> \MercuryAM\CMDB\dbscripts\ms\utils ディレクトリにあります。 データベースのインデックスをすべて再構築するユーティリティ rebuild_indexes.bat ユーティリティはデータベース内のテーブルすべてに対 して実行され,それらを再構築します。 rebuild_indexes.bat ユーティリティを実行するには,次の手順を実行します。 次のパラメータを指定して rebuild_indexes.bat を実行します。 ➤ SQL Server 名 ➤ データベース名 ➤ SA パスワード 処理の出力結果は,同じディレクトリの rebuild_indexes.log というファイル に保存されます。 インデックスごとのフラグメンテーション・レベルに基づいたインデックス再 構築のユーティリティ rebuild_fragmented_indexes.bat ユーティリティには次の 2 つの動作モード があります。 ➤ List fragmented tables : このモードでは,後でテーブルを再構築するのに 必要なコマンドとともに,断片化されたテーブル(フラグメンテーションが 30% を超えるテーブル)の一覧が返されます。 ➤ Rebuild fragmented tables : このモードでは,断片化されたテーブル(フ ラグメンテーションが 30% を超えるテーブル)がすべて再構築されます。 52 第 5 章 • MS SQL Server データベースの保守 rebuild_fragmented_indexes.bat ユーティリティを実行するには,次の手順を実 行します。 次のパラメータを指定して rebuild_fragmented_indexes.bat を実行します。 ➤ SQL Server 名 ➤ データベース名 ➤ SA パスワード ➤ 動作モード : 0 は,後で使用する再構築スクリプトを提供。1 は,インデック スを自動的に再構築。 処理の出力結果(断片化されたテーブルの一覧と再構築コマンド)は,同じ ディレクトリの rebuild_indexes.log というファイルに保存されます。 注:CMDB が管理データベースの一部となっている場合(標準設定の場合), 管理データベース・スキーマ用のユーティリティを実行します。別に CMDB を 作成した場合,CMDB 用ユーティリティを実行します。 分散の統計 Microsoft SQL Server 2000 を使用して,カラム内の値の分散に関する統計情報を 作成できます。この統計情報をクエリ・プロセッサで使用して,クエリを評価 するための最適な方法を確認できます。インデックスの作成時に,SQL Server はインデックス対象のカラムの値の分散に関する統計情報を自動的に格納しま す。SQL Server のクエリ・オプティマイザは,これらの統計情報を使用して, クエリに対してインデックスを使用する影響を見積ります。カラム内のデータ が変更されるのにしたがって,インデックスおよびカラム統計情報は古くな り,クエリ・オプティマイザが決定するクエリの処理方法は最適ではなくなる 可能性があります。 そのため,インデックス統計情報を更新して,テーブル内のデータ値の分散に 関する最新の情報をクエリ・オプティマイザに提供することをお勧めします。 これにより,クエリ・オプティマイザはデータベースに格納されているデータ に関して多くの情報を保持できるため,データへのアクセスに関する最適な方 法をより適切に判断できます。 標準設定では,auto update statistics database オプションは有効になってい ます。ただし,このオプションが無効になっていて,CMDB が管理データベー 53 53 第 2 部 • MS SQL Server データベースの導入と保守 スと別になっている場合,データは頻繁に変更されるため,管理データベース と CMDB の統計を毎日更新する自動タスクを作成することを強くお勧めしま す。このタスクでは,指定したデータベースに対して sp_updatestats API を 実行する必要があります。 注:統計の更新は,プロファイル・データベースについては毎日実行する必要 はありません。これは,プロファイル・データベースでは,データは追加また は削除されるだけであり,SQL Server が統計情報をランダムに自動的に更新す るためです。 auto update statistics database オプションが無効に設定されている場合は, 管理データベースと CMDB データベースの統計情報の更新タスクを毎日実行す ることをお勧めします。さらに,CMDB スキーマ・オブジェクトに対して大き な変更が加えられた場合(通常は大量なトランザクションの挿入によって発 生),手作業で CMDB の統計情報を更新することをお勧めします。次のシナリ オでは,手作業で CMDB 統計情報を更新します。 ➤ Automated Discovery タスク : ディスカバリ・マネージャが 構成アイテム (CI)を自動的に検出し,CMDB に挿入するプロセスです。 ➤ Mercury Business Availability Center アダプタ同期 : 大量なデータを CMDB へロードする可能性がある場合。[管理]>[CMDB]からアクセスできる, [ソース マネージャ]タブからアダプタを同期します。 手作業で CMDB 統計情報を更新するには,次の手順を実行します。 1 Web ブラウザで,http:// <センタ・サーバ・マシン名> :8080/jmx-console を 開きます。 2 Topaz セクションで,CMDB Dal Services を選択します。 3[runStatistics]にカスタマ ID を入力します。個々の Mercury Business Availability Center システムの標準設定のカスタマ ID(つまり,Mercury Managed Services で管理されていないもの)は 1 です。 4[runStatistics]で[Invoke]をクリックします。CMDB 統計情報が再生成さ れます。 54 第 5 章 • MS SQL Server データベースの保守 データベースの監視 本項では,ベースラインの設定または日常の監視において推奨される,システ ム・モニタ・カウンタについて説明します。 ベースラインの設定では,システムの通常の活動中にさまざまなカウンタを追 跡して,システムが良好に稼動しているときのカウンタの値を確認します。問 題が発生した場合には,現在のカウンタ値を調べてベースラインの値と比較で きます。 『SQL Server 2000 操作ガイド』 (http://www.microsoft.com/japan/technet/prodtechnol/sql/2000/maintain/sqlops0.mspx)で は,以下のカウンタを追跡してベースラインを作成し,それらを監視すること を勧めています。 カウンタ 説明 Memory Pages/second ハード・ページ・フォールトを解決するためにディスク との間で読み書きされるページ数(ハード・ページ・ フォールトは,作業セット内または物理メモリにない コードまたはデータをプロセスが要求し,それらをディ スクから取り出す必要があるときに発生します)。このカ ウンタは,システム全体の遅延の原因となるフォールト の種類を示す主要なインジケータであり,Memory: Pages Input/sec と Memory: Pages Output/sec の和で す。このカウンタではページ数が測定されるため, Memory:Page Faults/sec などのほかのページ・カウン トと直接比較することができます。このカウンタには, ファイル・システムのキャッシュされないマップ済みメ モリ・ファイルのフォールトを解決するために取り出さ れるページも含まれます。このカウンタには,直近の 2 回のサンプリングで測定された値の差を,サンプリング の間隔で割った値が表示されます。 Network Interface: Total Bytes/second 1 秒間にネットワーク・インタフェースを通過したバイト 数。この値が減少し始めた場合は,ネットワークの問題が アプリケーションに影響を及ぼしていないか調査します。 PhysicalDisk: Disk Transfers/second ディスクに対する読み書き操作の速度。サーバの物理 ディスクごとにカウンタを定義する必要があります。 55 55 第 2 部 • MS SQL Server データベースの導入と保守 56 カウンタ 説明 Processor: - % Processor Time プロセッサが非アイドル・スレッドを実行している時間 の割合。このカウンタはプロセッサの活動を示す基本的 なインジケータです。この値は,プロセッサがアイドル・ プロセスのスレッドを実行するのに費やす時間をサンプ ル間隔ごとに測定し,その値を 100% から引くことに よって算出されます(各プロセッサには,ほかのスレッ ドの実行準備ができていないときにサイクルを消費する アイドル・スレッドが割り当てられています) 。この値 は,あるサンプリング時点から次のサンプリング時点ま での間に何らかの有用な処理を行うために費やされた時 間の割合です。このカウンタには,サンプリング間隔の 間に測定されたビジー状態の時間の平均が表示されます。 この時間は,サービスが非アクティブだった時間の割合 を測定し,100% からその値を引くことによって算出され ます。MS SQL Server 専用のすべてのプロセッサの使用率 が 100% に達すると,エンド・ユーザの要求が無視され る可能性が高くなります。 SQLServer:Access Methods - Full Scans/second 無制限のベース・テーブル・スキャンまたは完全イン デックス・スキャンの回数。 SQLServer:Buffer Manager - Buffer Cache Hit Ratio ページがバッファ・プール内で見つかり,ディスクから の読み取りを必要としなかったページの割合。この割合 が大きいと,サーバは,ディスク I/O に関しては,最適な 効率で稼動しています。 SQLServer:Databases - Log Growths (アプリケーション・ データベース・インス タンスに対して実行さ れます) 選択されたデータベースに対するログの増分の総量。 SQLServer:Databases Application Database Percent Log Used (アプリケーション・ データベース・インス タンスに対して実行さ れます) ログの領域における使用中の領域の割合。 第 5 章 • MS SQL Server データベースの保守 カウンタ SQLServer:Databases Application Database Transactions/second (アプリケーション・ データベース・インス タンスに対して実行さ れます) 説明 データベースに対して開始されたトランザクションの数。 SQLServer:General Statistics - User Connections システムに接続されたユーザの数。この値が大幅に変動 する場合は調査が必要です。 SQLServer:Latches Average Latch Wait Time 待機する必要のあったラッチ要求に対する平均のラッチ 待機時間(ミリ秒単位)。この値が高い場合は,サーバが リソース競合を起こしている可能性があります。 SQLServer:Locks Average Wait Time ロック要求の結果として待機させられた個々のロック要 求の平均待機時間(ミリ秒単位)。 SQLServer:Locks Lock Waits/second 要求がすぐに満されずに,ロックが許可されるまで呼び 出し側が待機しなければならなかったロック要求の数。 SQLServer:Locks Number of Deadlocks/second 結果としてデッドロックとなったロック要求の数。 SQLServer:Memory Manager - Memory Grants Pending 作業領域メモリの割り当てを待機しているプロセスの現 在の数。 57 57 第 2 部 • MS SQL Server データベースの導入と保守 次のカウンタは,ハードウェアの問題を特定するのに役立ちます。 カウンタ 説明 Network Interface()\Packets Outbound Errors エラーのために送信できなかったアウトバウンド・パ ケットの数。 Network Interface()\Packets Received Errors パケットにエラーがあったために上層プロトコルに配送 されなかったインバウンド・パケットの数。 Server\Errors System 内部サーバ・エラーが検出された回数。これらのエラー は,ログオン,セキュリティ,メモリの割り当て,ディ スク操作,トランスポート・ドライバ・インタフェース の操作,通信[未実装または認識されない SMB(サー バ・メッセージ・ブロック)の受信など],I/O 要求パ ケットのスタック・サイズについて,サーバに問題があ ることを示している可能性があります。また,これらの エラーの多くは,イベント・ビューアのシステム・ログ とセキュリティ・ログにも書き込まれます。サーバは, このカウンタに表示されるエラーの大半から復旧できま すが,これらのエラーは予期されないエラーであり, Microsoft 製品サポート・サービスに報告する必要があり ます。 ベースライン作成の詳細については,システム・モニタのマニュアルを参照す るか,または 『SQL Server 2000 操作ガイド』 (http://www.microsoft.com/japan/technet/prodtechnol/sql/2000/maintain/sqlops0.mspx) を参照してください。 58 第 5 章 • MS SQL Server データベースの保守 データベースの保守 : 参考資料 MS SQL Server のパフォーマンス・チューニングの詳細については,次の文書 を参照してください(SQL Server 2000 操作ガイド以外は英語版です)。 ➤ データベース最適化の方法 : http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/sql/res kit/sql2000/part10/c3361.asp ➤ MS SQL Server でのアプリケーションのパフォーマンスに関するトラブル シューティング : http://support.microsoft.com/default.aspx?scid=KB;EN-US;q224587 ➤ パフォーマンス・カウンタ : http://www.databasejournal.com/features/mssql/article.php/1477311#disk ➤ MS SQL Server のパフォーマンス監査を実行する方法 : http://www.sql-server-performance.com/sql_server_performance_audit.asp ➤ MS SQL Server のパフォーマンス・チューニングのヒント : http://www.sql-server-performance.com/best_sql_server_performance_tips.asp ➤ SQL Server 2000 操作ガイド : http://www.microsoft.com/japan/technet/prodtechnol/sql/2000/maintain/sqlops0.mspx ➤ MS SQL Server のパフォーマンス・チューニング全般に関するページとそのほ かのリンク : http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/rdbmspft.mspx ➤ MS SQL Server MSDN のパフォーマンス・チューニング・セクション : http://msdn.microsoft.com/SQL/sqlperf/ default.aspx 59 59 第 2 部 • MS SQL Server データベースの導入と保守 60 第6章 MS SQL Server サイズ設定ガイドライン 本章では,MS SQL Server と Mercury Business Availability Center で作業を行う場 合に必要となる,サーバとデータベースに関する設定のガイドラインを示しま す。一般に,導入する Mercury Business Availability Center のサイズによって推 奨設定は異なります。 本章の内容 ページ Mercury Business Availability Center サイズ設定 62 ハードウェアのサイズ設定 63 サーバ設定オプション 63 データ・ファイルのプロパティの設定 64 tempdb データベースの設定 64 61 第 2 部 • MS SQL Server データベースの導入と保守 Mercury Business Availability Center サイズ設定 Mercury Business Availability Center のデータベース設定の要件は,Mercury Business Availability Center によって生成されるデータ量によって異なります。 たとえば,3 個のビジネス・プロセス・モニタが 300 日にわたってデータを生 成し,各エージェントにおいて,10 件のトランザクションと WebTrace を 15 分 ごとに実行するビジネス・プロセス・プロファイルを 5 個実行して,トランザ クションのうち 5% がエラーを返す,という場合を考えます。このような規模 のデータに対しては小規模のデータベースを使用することになります。 一方,10 個のビジネス・プロセス・モニタが 250 日にわたってデータを生成 し,各エージェントにおいて,約 600 種の測定を実行する 50 個の SiteScope プ ロファイルと,10 件のトランザクションおよび WebTrace を 15 分ごとに実行す るビジネス・プロセス・プロファイルを 30 個実行し,トランザクションのう ち 5% がエラーを返す,という場合を考えます。このような規模のデータに対 しては大規模のデータベースを使用することになります。 次の表に,生成されるデータ量に基づいて各データベース要素に必要となる データベース・サイズを示します。 データベース要素 備考 小規模 大規模 挿入量 (毎時行数) 6 KB 以下 500 KB 以上 名前付きユーザ (プロファイル・ データベース) 20 未満 80 以上 メモリ設定に使用 名前付きユーザ (管理データ ベース) 30 未満 50 以上 プロセス設定に使用 約 30 GB 約 600 GB 以上 データベース・サ イズ 62 Mercury Business Availability Center の 導入 第 6 章 • MS SQL Server サイズ設定ガイドライン ハードウェアのサイズ設定 次の表に,MS SQL Server データベースに関して Mercury Business Availability Center の認定を受けるためのハードウェア(CPU とメモリ)の要件を示します。 Mercury Business Availability Center の導入 プロセッサ数 物理メモリ MS SQL の推奨 バージョン 小規模 1-2 1 ~ 2 GB Microsoft SQL Server 2000 Enterprise,Service Pack 4 大規模 8 8 GB 以上 Microsoft SQL Server 2000 Enterprise,Service Pack 4 注:HP/Compaq データベース・サーバのデータベース・サイズ設定に関するオ ンライン情報の詳細については,次の Web ページを参照してください。 http://activeanswers.compaq.com/ActiveAnswers/Render/1,1027,5276-6-100-2251,00.htm http://activeanswers.compaq.com/ActiveAnswers/Render/1,1027,536-6-100-2251,00.htm サーバ設定オプション 次の MS SQL Server オプションは再設定できます。 ➤ awe enabled : MS SQL Server で 4 GB を超える物理メモリにアクセスする必要が ある場合は,Microsoft Windows 2000 AWE(Address Windowing Extensions)API を使用することで最大 64 GB までサポートできます。詳細については,MS SQL Server Books Online,および 『SQL Server 2000 操作ガイド』 (http://www.microsoft.com/japan/technet/prodtechnol/sql/2000/maintain/sqlops0.mspx)を参 照してください。 63 63 第 2 部 • MS SQL Server データベースの導入と保守 データ・ファイルのプロパティの設定 MS SQL Server データ・ファイルについては,次のプロパティを設定できます。 ➤ SIZE : MS SQL Server は,データベースの作成時にこのパラメータで指定され たサイズを割り当て,その領域を「0」で埋めます(これには時間がかかる場合 があります) 。MS SQL Server はできるだけ多くの量の連続領域を確保しようと するので,将来のファイルの拡張によるファイル・システムのフラグメンテー ションを避けるために,できるだけ大きな値を指定することをお勧めします。 ➤ FILEGROWTH : ファイルの自動増分量は,既存のファイル・サイズに対する パーセンテージか,または固定サイズのどちらかを指定できます。増分量を小 さめにすると,ファイル・システムのフラグメンテーションが増すため,お勧 めできません。逆に,増分量が非常に大きいと,クライアントから変更要求が 送信されたときに,自動拡張の完了まで待機するために接続がタイムアウトし てしまうことがあります。この問題は,ファイルの増分量が標準の 10% に設 定されているときに,データベースを作成してからしばらくして,突然発生す る可能性があります。データベースが小さければ,自動拡張は短時間で完了し ますが,データベースが大きくなると(たとえば数 GB など)標準の 10% の増 分でもその割り当てと初期化に時間がかかる場合があります。 tempdb データベースの設定 tempdb システム・データベースが頻繁に拡張されると,データベースのパ フォーマンスに影響が及ぶ可能性があります。特に,大規模なインストールの MS SQL Server ではその可能性が高くなります。したがって,tempdb のサイズ は,早期に拡張しなくてもすむよう十分な大きさにします。tempdb の増分量 は,フラグメンテーションを回避するのに十分な大きさで,かつ,拡張が適切 な時間内に完了するサイズにします。最低限のサイズ(初期サイズは 500 MB, 増分量は 50 MB)で tempdb を作成します。tempdb データベースは複数のディ スクを使ってストライピングします。RAID 0+1 コントローラを使うのが理想 的です。tempdb データベースは,専用のディスク・セットに移動することをお 勧めします。 たとえばデータの集計や並べ替えのように,使用量が増大し tempdb が大きく なる時に十分なディスク領域を確実に確保するには,tempdb のあるドライブに 少なくとも 20 GB の空き領域を残しておくことをお勧めします。 64 第7章 MS SQL Server サマリ・チェックリスト 本章では,Mercury Business Availability Center で作業を行う場合にサポートおよ び推奨されているサーバおよびデータベースの設定オプションをまとめた チェックリストを示します。また,サーバおよびデータベースの設定を確認ま たは変更するための手順をまとめた表も示します。 本章の内容 ページ Mercury Business Availability Center におけるサポートと認定のチェック リスト 66 サーバおよびデータベースの設定の確認と変更 67 65 第 2 部 • MS SQL Server データベースの導入と保守 Mercury Business Availability Center におけるサポートと認定の チェックリスト 次のチェックリストに,Mercury Business Availability Center で作業を行う場合に サポートおよび認定されているサーバおよびデータベースの設定オプションを まとめて示します。 MS SQL Server 2000 対象 サポート インスタンス 標準,シングル 認証モード 混合 照合順序 Case-Insensitive,AccentWindows ロケール Sensitive,Kana-Insensitive,(Latin1_General,AccentWidth-Insensitive Sensitive の各オプションを 選択) ネットワーク・ライブラリ サーバ : TCP/IP および名前 サーバ : TCP/IP 付きパイプ クライアント : TCP/IP クライアント : TCP/IP およ び名前付きパイプ サーバ設定オプション データ・ファイルのプロパ ティ 標準設定(ほかに指示がある場合を除く) 手動によるファイル拡張, FILEGROWTH : 約 30 ~ 100 MB または FILEGROWTH が 100 MB 以下 照合順序データベース・プロ パティ サーバの標準設定 データベース・オプション 復旧モデル 66 推奨 標準設定(ほかに指示がある場合を除く) 任意 完全 第 7 章 • MS SQL Server サマリ・チェックリスト サーバおよびデータベースの設定の確認と変更 次の表に,サーバとデータベースの設定を確認または変更する手順を示します。 サーバ / データベースの 設定 設定の確認または変更の方法 既定のインスタンス オペレーティング・システムの[サービス]アプレット で,既定のインスタンスは MSSQLServer と表示され, 名前付きインスタンスは MSSQL$INSTNAME と表示さ れます。MS SQL Server が既定のインスタンスとしてイ ンストールされていることを確認します。 認証モード MS SQL Server Enterprise Manager で,サーバを右クリッ クし,[プロパティ]を選択して,[セキュリティ]タブ をクリックします。[混合モード]を選択します。 照合順番の設定 次のコマンドを実行します。sp_helpsort 必要な結果 : Latin1-General, case-insensitive, accent-sensitive, kanatype-insensitive, width-insensitive ネットワーク・ライブラリ サーバ : svrnetcn.exe を実行します。 クライアント : cliconfg.exe を実行します。 サポート : TCP/IP および名前付きパイプが,サーバとク ライアントの両方でサポートされていること。 推奨 : TCP/IP のみサーバとクライアントの両方でサポー トされていること。 67 67 第 2 部 • MS SQL Server データベースの導入と保守 サーバ / データベースの 設定 サーバ設定オプションの 表示または変更 設定の確認または変更の方法 ➤ すべてのオプションの表示を可能にするには,次を 実行します。 EXEC sp_configure 'show advanced options', 1 reconfigure with override ➤ 現在の値を表示するには,次を実行します。 EXEC sp_configure ➤ 設定を変更するには,次を実行します。 EXEC sp_configure ' <オプション> ', <値> オプションによっては,reconfigure with override を実 行した後に有効になるものや,MSSQLServer サービス の再起動を必要とするものがあります。詳細について は, MS SQL Server 2000 Books Online を参照してく ださい。 ユーザが CREATE DATABASE 権限を持って いるかどうかの確認 確認する対象のログインを使用してクエリ・アナライザ にログインし,次を実行します。 USE master IF PERMISSIONS() & 1 = 1 PRINT 'User has CREATE DATABASE permissions' ELSE PRINT 'User does not have CREATE DATABASE permissions' 68 ユーザがデータベースの dbo かどうかのチェック 確認する対象のログインを使用してクエリ・アナライザ にログインします。そして,データベースのコンテキス トを対象データベースに変更し,次を実行します。 SELECT USER_NAME() データベース所有者の確認 次を実行します。 EXEC sp_helpdb <データベース名> 第 7 章 • MS SQL Server サマリ・チェックリスト サーバ / データベースの 設定 設定の確認または変更の方法 データ・ファイルおよび ログ・ファイルの格納先 ディレクトリが圧縮され ていないかの確認(NTFS の場合のみ) ディレクトリを右クリックし,[プロパティ]を選択し てから[詳細]を選択します。[圧縮]チェック・ボッ クスの選択が解除されていることを確認します。 データベースおよびデー タベース・ファイルのプ ロパティ ➤ データベースおよびデータベース・ファイルのプロ (復旧モデルと照合順序プ ロパティを含む) パティを表示するには,次を実行します。 EXEC sp_helpdb <データベース名> ➤ データベースのプロパティを変更するには,次を実 行します。 ALTER DATABASE <データベース名> SET <オプ ション> <値> ➤ データベース・ファイルのプロパティを変更するに は,次を実行します。 ALTER DATABASE <データベース名> MODIFY FILE (name = <ファイル名> , <プロパティ> = <値> ) Enterprise Manager の[データベースのプロパティ]ダ イアログ・ボックスでこれらのプロパティを表示または 変更することもできます。 MS SQL Server のサービ ス・パックのバージョン とエディション MS SQL Server のサービス・パックのバージョンとエ ディションを確認するには,次の URL を参照してくだ さい。 http://support.microsoft.com/default.aspx?scid=kb;enus;q321185 69 69 第 2 部 • MS SQL Server データベースの導入と保守 70 第8章 MS SQL Server のインストールと設定 本章では,MS SQL Server のインストール手順と設定について説明します。 本章の内容 ページ MS SQL Server のインストール 72 MS SQL Server の設定 81 71 第 2 部 • MS SQL Server データベースの導入と保守 MS SQL Server のインストール MS SQL Server をインストールするには,CD-ROM をドライブに挿入し, < MS SQL Server のルート・ディレクトリ> \x86\setup ディレクトリから setupsql.exe を実行します。インストール手順は難しくはありませんが,適切 なオプションを選択できるように,インストールの詳細のすべてについて理解 しておくことが重要です。標準設定のオプションのままでは,MS SQL Server のパフォーマンスに悪影響を及ぼすことがあります。 次の各項では,インストール中に特に注意が必要なダイアログ・ボックスを示 します。 [インスタンス名]ダイアログ・ボックス 同一のマシンに MS SQL Server 2000 の複数のインスタンスをインストールでき ます。各インスタンスはそれぞれに独立の MS SQL Server と MS SQL エージェ ント・サービスを持ち,ほかのインスタンスとは完全に独立しています。 既定のインスタンスとしてインストールできるインスタンスは 1 つだけです。 ほかのすべてのインスタンスは名前付きインスタンスとしてインストールする 必要があり,それらの名前はインストール時に指定します。既定のインスタン スにアクセスするには,サーバの名前または IP アドレスを指定します。名前付 きインスタンスにアクセスするには,サーバの名前または IP アドレスの後に \ <インスタンス名>を付けて指定します(たとえば server1\inst1 などと指 定します)。 Mercury Business Availability Center で作業を行うときは,MS SQL Server 2000 を 既定のインスタンスとしてインストールする必要があります。既定のインスタ 72 第 8 章 • MS SQL Server のインストールと設定 ンスとしてインストールするには,[インスタンス名]ダイアログ・ボックス の[既定インストール]チェック・ボックスを選択します。 インストール後にこの設定を確認する方法の詳細については,67 ページ「サー バおよびデータベースの設定の確認と変更」を参照してください。 73 73 第 2 部 • MS SQL Server データベースの導入と保守 [セットアップの種類]ダイアログ・ボックス [セットアップの種類]ダイアログ・ボックスでは,必ず[カスタム]オプショ ンを選択する必要があります。このオプションを選択しないと,[コンポーネン トの選択] , [照合順序の設定],[ネットワーク ライブラリ]の各ダイアログ・ ボックスを表示できなくなります。これらのダイアログ・ボックスでは,MS SQL Server を Mercury Business Availability Center と組み合わせて運用する上で, 標準のままでは適切でない一部のオプションを変更する必要があります。 [セットアップ先フォルダ]では,MS SQL Server の実行可能ファイルを格納す る[プログラム ファイル]ディレクトリと,システム・データベースおよび ファイルの格納場所が指定されていないユーザ・データベースが格納される [データ ファイル]ディレクトリを設定します。これらの設定は後で変更でき ないので注意してください。tempdb ファイルとユーザ・データベース・ファイ ルは後で配置し直すことができます(tempdb ファイルの場合は ALTER DATABASE tempdb MODIFY FILE コマンドを使用します。ユーザ・データベー ス・ファイルの場合は,デタッチ,移動,アタッチを行います)。しかし, master,msdb,model の各ファイルは移動できません。これらのシステム・ データベースのサイズは小さいですが,MS SQL Server の運用には欠かせない ファイルです。 [データ ファイル]ディレクトリは,必ず RAID 1 などのフォー ルト・トレラントなディスク・システムに格納してください。 74 第 8 章 • MS SQL Server のインストールと設定 [コンポーネントの選択]ダイアログ・ボックス [コンポーネントの選択]ダイアログ・ボックスで,[フルテキスト検索] チェック・ボックスが選択されていないことを確認します。選択されている場 合はチェック・ボックスをクリアします。Mercury Business Availability Center で はこのインデックス作成サービスは必要ありません。 75 75 第 2 部 • MS SQL Server データベースの導入と保守 [サービス アカウント]ダイアログ・ボックス [サービス アカウント]ダイアログ・ボックスでは,MS SQL Server のサービス を選択し,適切なサービス設定を入力します。MS SQL Server サービス(MS SQLServer)でローカル・マシン外部の活動(たとえば共有ネットワーク・ ディレクトリへのファイルのバックアップなど)を実行する場合は,[ドメイ ン ユーザー アカウントを使用]を選択し,ローカル・マシンの管理者グルー プのメンバであり,ネットワーク・リソースに対する適切な権限を持っている ユーザのユーザ名,パスワード,およびドメインを指定します。MS SQL Server のすべての活動がローカル・マシンに限定される場合は,[ローカル システム アカウントを使用]を選択します。このアカウントは,MS SQL Server サービ スに対する管理権限をローカル・マシンに限定して許可します。 同様に,MS SQL Server エージェント・サービス(SQLServerAgent)でローカ ル・マシン外部の権限を必要とする活動(たとえば,ほかのサーバとのレプリ ケーション,ActiveX スクリプト・ジョブ・ステップ,CmdExec ジョブ・ス テップなど)を実行する場合は,[ドメイン ユーザー アカウントを使用]を選 択し,ローカル・マシンの管理者グループのメンバであるユーザのユーザ名, パスワード,およびドメインを指定します。MS SQL Server エージェントのす べての活動がローカル・マシンに限定される場合は,[ローカル システム アカ ウントを使用]を選択します。 76 第 8 章 • MS SQL Server のインストールと設定 [認証 モード]ダイアログ・ボックス [認証モード]ダイアログ・ボックスでは,MS SQL Server で使用する認証のタ イプを選択します。Mercury Business Availability Center では MS SQL Server の認 証を利用できますが,認証は標準では無効にされています。MS SQL Server の 認証を有効にするには,[混合モード]を選択して,SA ログイン用に複雑なパ スワードを指定します。 注:MS SQL Server のセキュリティを確保するためには,パスワードを入力す ることが重要です。 これは,SA ユーザはシステム管理者の権限を持っており,MS SQL Server 内で はどのような操作も実行できるからです。同様に,SA ユーザは xp_cmdshell 拡 張プロシージャを使用することにより,MSSQLServer サービス・アカウントの コンテキストにおけるオペレーティング・システムおよびネットワークのすべ ての操作を実行できます。 インストール後に認証モードを変更または確認する方法の詳細については, 67 ページ「サーバおよびデータベースの設定の確認と変更」を参照してくだ さい。 77 77 第 2 部 • MS SQL Server データベースの導入と保守 [照合順序の設定]ダイアログ・ボックス [照合順序の設定]ダイアログ・ボックスでは,言語,辞書またはバイナリの 順序,および,文字データ型の大文字小文字などの区別を設定します。 次の 2 つのオプションのどちらかを選択します。 ➤[Windows ロケール]: このオプションは,以前のバージョンの MS SQL Server と上位互換性を保つ必要がない場合(レプリケーションのためなど)にだけ選 択します。このオプションを選択する場合は,Mercury Business Availability Center の認定を受けるために次を設定します。 ➤[照合順序指定子]: 通常使用する文字データ型(char,varchar,text)の言 語。英語をサポートする場合は標準のオプションである[Latin1_General] を選択します。 ➤[並べ替え順]: 文字データ型のバイナリ順序と,大文字小文字などの区別 (case,accent,kana,width)。[アクセントを区別する]オプションのみ選択 し,他のオプションは必ず選択しないでください。 注:Mercury Business Availability Center では,MS SQL Server 2000 での大文字小 文字の区別はサポートしていません。 ➤[SQL 照合順序]: このオプションは,現在のバージョンの MS SQL Server で以 前のバージョンと互換性を持たせる必要がある場合(サーバ間でデータをレプ リケートする場合など)に選択します。 78 第 8 章 • MS SQL Server のインストールと設定 上記の設定はシステム・データベースにのみ影響し,ユーザ・データベースに 対しては標準の設定として機能します。データベースには,サーバの標準設定 とは異なる照合順序を設定できます。また,表の列にはデータベースの標準設 定とは異なる照合順序を設定できます。MS SQL Server 2000 では照合順序の管 理が柔軟に行えるため,照合順序の設定の異なるデータベースを復元またはア タッチできます。 注:上記の設定を 1 つでも変更するには,すべてのシステム・オブジェクトと ルーチン(ログイン,ユーザ定義のシステム・メッセージ,マスター・ストア ド・プロシージャなど)のスクリプト編集が必要なほか,MS SQL Server を新 しい設定で再インストールし(または RebuildM.exe を実行し),保存したスク リプトを使ってすべてのシステム・オブジェクトを再作成して,ユーザ・デー タベースをアタッチする,という作業が必要になります。したがって,インス トール時に適切なオプションを選択することをお勧めします。 MS SQL Server 2000 の照合順序の設定を確認する方法の詳細については, 67 ページ「サーバおよびデータベースの設定の確認と変更」を参照してくだ さい。 79 79 第 2 部 • MS SQL Server データベースの導入と保守 [ネットワーク ライブラリ]ダイアログ・ボックス [ネットワーク ライブラリ]ダイアログ・ボックスでは,MS SQL Server がクラ イアント接続をリッスンするために使用するセッション・レベルのプロトコル を設定します。 標準では,MS SQL Server は名前付きパイプと TCP/IP の両方を通じてクライア ント接続をリッスンします。Mercury Business Availability Center では両方のプロ トコルがサポートされています。ただし,Mercury Business Availability Center の 認定を受けるためには,[TCP/IP]ソケット・オプションだけを選択する必要 があります。 クライアント・マシンでは,名前付きパイプと TCP/IP の両方を使用して MS SQL Server に接続するように設定できます。ただし,Mercury Business Availability Center の認定を受けるためには,TCP/IP だけを使用して MS SQL Server に接続するようクライアント・マシンを設定する必要があります。 インストール後に上記の設定を変更または確認する方法の詳細については, 67 ページ「サーバおよびデータベースの設定の確認と変更」を参照してくだ さい。 80 第 8 章 • MS SQL Server のインストールと設定 注:ネットワーク・ライブラリはすべて Windows 認証と SSL データ暗号化をサ ポートしています。 MS SQL Server の設定 本項では,MS SQL Server のインストール完了後に設定できるサービスおよび サーバのオプションについて説明します。 サービス設定オプション フルテキスト検索機能をインストールした場合は,リソースが無駄に使用され ないように,必ず無効にします(フルテキスト検索機能は,Microsoft Search を 使用しているサービス アプレット内に含まれているサービスです)。 分散トランザクションを使用していないかぎり,Distributed Transactions Coordinator サービスも必ず無効にするか,手動モードに設定します。 同様に,不必要なすべてのサービスが自動起動モードに設定されていないこと を確認します。 サーバ設定オプション サーバ設定オプションのほとんどは MS SQL Server によって動的に設定されま す(通常は 0 に設定されます)。Mercury Business Availability Center の認定を受 ける場合は,Mercury カスタマー・サポートによる指示がある場合を除いて, 標準のオプションを変更しないでください。 状況によっては,標準の設定を変更してもよい場合もあります。これらの設定 は sp_configure ストアド・プロシージャの中で変更するか,または MS SQL Server Enterprise Manager の各種のダイアログ・ボックス(主に[サーバのプロ パティ]ダイアログ・ボックス)の中で変更できます。 81 81 第 2 部 • MS SQL Server データベースの導入と保守 次の表に,MS SQL Server 2000 で使用できる設定オプション,標準の設定,お よび Mercury Business Availability Center の認定を受けるために必要な設定を示 します。 82 設定オプション 標準 MS SQL Server 2000 における Mercury Business Availability Center の認定 affinity mask 0 標準 allow updates 0 標準 awe enabled(Enterprise Edition) 0 標準(サーバで 4 ~ 64 GB のメモ リにアクセスする必要がある場合 を除く) c2 audit mode 0 標準 cost threshold for parallelism 5 標準 cursor threshold -1 標準 default full-text language 1033 標準 default language 0 標準 fill factor 0 標準 index create memory 0 標準 lightweight pooling 0 標準 locks 0 標準 max async IO 32 N/A max degree of parallelism 0 標準 max server memory 2,147,483,647 標準 max text repl size 65,536 標準 max worker threads 255 標準 media retention 0 標準 min memory per query 1024 標準 min server memory 0 標準 第 8 章 • MS SQL Server のインストールと設定 設定オプション 標準 MS SQL Server 2000 における Mercury Business Availability Center の認定 Using Nested Triggers 1 標準 network packet size 4096 標準 open objects 0 標準 priority boost 0 標準 query governor cost limit 0 標準 query wait -1 標準 recovery interval 0 標準 remote access 1 標準 remote login timeout 20 標準 remote proc trans 0 標準 remote query timeout 600 標準 scan for startup procs 0 標準 set working set size 0 標準 show advanced options 0 標準 spin counter 0, 10,000 N/A time slice 100 N/A two digit year cutoff 2049 標準 user connections 0 標準 user options 0 標準 以上のオプションは次を実行することですべて表示できます。 EXEC sp_configure 'show advanced options', 1 reconfigure with override 各オプションの現在の値を表示するには,EXEC sp_configure を実行します。 83 83 第 2 部 • MS SQL Server データベースの導入と保守 大規模なインストールでは,awe enabled オプションの設定が必要になる場合 があります。詳細については,第 6 章「MS SQL Server サイズ設定ガイドライ ン」を参照してください。 注:Mercury Business Availability Center データベースのホストとして使用する サーバには,MS SQL Server を 1 つインストールする以外,重要なプロセスは インストールしないことを強くお勧めします。MS SQL Server がマシンで唯一 の重要なプロセスであるときは,標準のメモリ設定を変更しないでください。 MS SQL Server によるメモリの動的管理が可能になるようにしてください (awe enabled のサポートを設定した場合を除く)。 オプションを再度設定するには,EXEC sp_configure ' <オプション> ', <値> を実行します。オプションによっては,reconfigure with override を実行した後 に有効になるものや,MS SQL Server サービスの再起動を必要とするものがあ ります。 84 第3部 Oracle サーバ・データベースの導入と保守 第9章 Oracle サーバの導入の概要 管理データベースおよびプロファイル・データベースは Oracle サーバ上にセッ トアップすることが可能です。本章では,Mercury Business Availability Center と 連携して使用するための Oracle サーバの導入に関連する次の項目について説明 します。 本章の内容 ページ Oracle サーバの導入について 88 システム要件 89 Oracle サーバのエディションの選択 91 87 第 3 部 • Oracle サーバ・データベースの導入と保守 Oracle サーバの導入について Oracle サーバを導入し,Mercury Business Availability Center と連携して使用でき るようにするためには,次の手順を実行します。 ➤ Oracle サーバをインストールします。 詳細については,使用する Oracle プラットフォームのインストール・ガイドを 参照してください。 ➤ 管理データおよびプロファイル・データを格納するためのデータベースを, Oracle サーバに作成します。 詳細については,使用する Oracle プラットフォームのインストール・ガイドを 参照してください。 ➤ 管理データおよびプロファイル・データを格納するための Oracle 表領域を 1 つ 以上作成します。 詳細については,94 ページ「Mercury Business Availability Center の Oracle 表領 域」を参照してください。 ➤ Oracle Client を Mercury Business Availability Center 用に設定します。 詳細については,103 ページ「Mercury Business Availability Center 向けの Oracle Client の設定」を参照してください。 ➤ 管理データ用の Oracle ユーザ・スキーマを作成します。 管理用ユーザ・スキーマは,手作業で作成するか,または Set Management Database ユーティリティを使用して Mercury Business Availability Center に作成さ せることができます。管理データ用の Oracle ユーザ・スキーマの作成の詳細に ついては,97 ページ「管理用ユーザ・スキーマ」を参照してください。 ➤ プロファイル・データ用の Oracle ユーザ・スキーマを 1 つ以上作成します。 プロファイル用ユーザ・スキーマは,手作業で作成するか,または[プラット フォームの管理]の[セットアップと保守]タブにある[データベース管理] ページを使用して作成できます。Mercury Business Availability Center プロファイ ル・データ用の Oracle ユーザ・スキーマの作成の詳細については,99 ページ 「プロファイル・ユーザ・スキーマ」を参照してください。 88 第 9 章 • Oracle サーバの導入の概要 本項の内容は,推奨される Oracle 環境およびサポート対象 Oracle 環境を対象と しています。Mercury Business Availability Center の導入において推奨される環境 とは,推奨の環境またはオプションについて Mercury の品質保証担当者が十分 なテストを実施済みであることを示すものです。サポート対象環境およびサ ポート対象オプションとは,対象の環境やオプションについて,Mercury の品 質保証担当者による基本的なテストが正常に実施されたことを意味します。 システム要件 本項では,Oracle サーバを Mercury Business Availability Center と組み合わせて運 用するためのシステム要件について説明します。 ハードウェアの要件 Mercury Business Availability Center のハードウェアのサイズ設定ガイドラインの 詳細については,第 13 章「Oracle サーバのサイズ設定ガイドライン」を参照し てください。 Oracle のハードウェア要件の詳細については,使用する Oracle プラットフォー ムのインストール・ガイドを参照してください。そのほか,Oracle ソフトウェ アの配布メディアおよび Oracle のオンライン・マニュアルも参照してくださ い。Oracle のマニュアルについては, http://otn.oracle.com/documentation/index.html を参照してください。 89 89 第 3 部 • Oracle サーバ・データベースの導入と保守 ソフトウェアの要件 Mercury Business Availability Center では,UNIX と Windows の両方のデータベー ス・サーバがサポートされています。次の表は,Mercury Business Availability Center で作業を行う場合にサポートおよび認定されている Oracle サーバの構成 の一部を示します。 サポート コンポーネ ント 90 推奨 バージョン / エディション サービス・ パック バージョン / エディション サービス・ パック Windows オ ペレーティ ング・シス テム Windows 2000 Server/Advanced Server Service Pack 4 Windows 2003 Server Standard / Enterprise Service Pack 1 Sun Solaris オ ペレーティ ング・シス テム Solaris 9 Solaris 8,10 Oracle Oracle 9.2.0.6 Oracle 10.2.0.1 第 9 章 • Oracle サーバの導入の概要 注: ➤ Solaris 環境は 64 ビットのみです。 ➤ Oracle 9i の Oracle 環境はすべてのプラットフォームで 32 ビットです。 Oracle 10g については,Windows では 32 ビット,UNIX では 64 ビットです。 Oracle Client ソフトウェアの要件の詳細については,104 ページ「Oracle Client のバージョンとオペレーティング・システム・プラットフォーム」を参照して ください。 Oracle インスタンス 1 台のマシンに,同じ Oracle データベース・エンジンを使用する複数の Oracle インスタンスをインストールできます。 Mercury Business Availability Center の認定を受ける場合は,複数の Oracle インス タンスは使用しないでください。Mercury Business Availability Center データベー スに対して複数のインスタンスを使用する場合は,必ずすべてのインスタンス を本書で説明しているとおりに設定し,すべてに同じ設定(同じ文字セットな ど)を適用してください。 Oracle サーバのエディションの選択 次に示す Oracle9i または 10g エディションのうちの 1 つを使用できます。 ➤ Standard Edition : 管理ツール,分散,レプリケーション,および Web の機能が 全面的に統合されたセットです。小規模ビジネスのシングル・サーバ環境から, 支社があるような広範囲に分散された環境にいたるまで,Oracle にはビジネス に欠かせないアプリケーションの構築に必要な機能がすべて含まれています。 ➤ Enterprise Edition : 大容量のオンライン・トランザクション処理(OLTP)環境 や,クエリを多用するデータ・ウェアハウス,多様なニーズへの対応が必要な インターネット・アプリケーションといった,ハイエンド・アプリケーション に対して,効率的で信頼性のある安全なデータ管理機能を提供します。Oracle Enterprise Edition は,今日のミッション・クリティカルなアプリケーションに 要求される可用性を実現するためのツールや機能を備えています。 91 91 第 3 部 • Oracle サーバ・データベースの導入と保守 ➤ Personal Edition : Oracle Standard Edition および Oracle Enterprise Edition との完全 な互換性を必要とする,シングル・ユーザによる開発と導入をサポートします。 ➤ Oracle Lite : ノートブック・コンピュータやハンドヘルド・コンピュータ,情報 家電などのモバイル・デバイスに,エンタープライズ・アプリケーションを提 供する目的で新しく開発された,小規模データベースです。強力な管理ツール をサポートし,Oracle Standard Edition および Oracle Enterprise Edition と同様の機 能を備えており,モバイル・ソリューションを容易に,かつ効果的に配備でき ます。Oracle Lite の機能については,先に示した各エディションと直接比較する ことができないため,本書では説明していません。Oracle Lite と先に示したエ ディションとの比較については,Oracle Lite 関連の記事を参照してください。 また,エディションごとに必要な費用が異なるので注意してください。 注:Mercury Business Availability Center では,Standard Edition と Enterprise Edition の両方がサポートされています。ただし,Mercury Business Availability Center での使用が推奨されているのは Enterprise Edition だけです。 92 第 10 章 Mercury Business Availability Center データ ベース環境のセットアップ 本章では,Mercury Business Availability Center ユーザ・スキーマ用の Oracle 表領 域の作成方法と,管理用およびプロファイル用の各ユーザ・スキーマの作成方 法について説明します。また,Mercury Business Availability Center ユーザ・ス キーマに対する Oracle の権限についても説明します。 本章の内容 ページ Mercury Business Availability Center の Oracle 表領域 94 管理用ユーザ・スキーマ 97 プロファイル・ユーザ・スキーマ 99 Mercury Business Availability Center の Oracle スキーマの権限 102 注:管理スキーマまたはプロファイル・スキーマ,あるいはその両方を作成し た後は,データベース・スキーマ検証プログラムを実行して,データベース・ スキーマが正しく設定されていることを確認することを強くお勧めします。検 証処理の詳細については,付録 D「データベース・スキーマの検証」を参照し てください。 93 第 3 部 • Oracle サーバ・データベースの導入と保守 Mercury Business Availability Center の Oracle 表領域 Oracle 表領域は,Oracle オブジェクトの 1 種で,表やインデックスなどのデー タベース・オブジェクトを格納する論理的なコンテナです。Mercury Business Availability Center で作業を行う場合は,Mercury Business Availability Center ユー ザ・スキーマ専用の標準設定の表領域を 1 つ以上作成する必要があります。ま た,Mercury Business Availability Center 専用の一時表領域を作成することもでき ます。表領域を作成するには,表領域を物理的に表現する特定のオペレーティ ング・システム・ファイルのほか,エクステント・パラメータを指定する必要 があります。 注:パージ・マネージャを有効にしている場合における表領域の作成の詳細に ついては,168 ページ「パージ・マネージャを使用する際の Oracle 表領域の作 成」を参照してください。 オペレーティング・システム・ファイルをマッピングするときのオプションの 1 つに,ファイルを自動拡張可能にするオプションがあります。Mercury Business Availability Center ではこの機能はサポートされていますが,使用する と Mercury Business Availability Center の認定を受けられません。これは,この 機能では使用可能なディスク領域をシステムがすべて消費してしまう可能性が あるためです。 ローカル管理される表領域 表領域のローカル管理は Oracle8i で導入された機能です。Oracle8i より前の バージョンでは,すべての表領域がディクショナリ管理されていました。エク ステントがローカルで管理される表領域には,固定のエクステント・サイズを 割り当てるか,またはシステムによって自動的に決定される可変のエクステン ト・サイズを割り当てることができます。表領域を作成するときに,uniform または autoallocate(システム管理)のオプションによって割り当てのタイプ を指定します。 システム管理のエクステントの場合は,64 KB を最小とする最適なエクステン ト・サイズが Oracle によって決められます。永続表領域の場合は,この 64 KB が標準のエクステント・サイズになります。 94 第 10 章 • Mercury Business Availability Center データベース環境のセットアップ 固定エクステントの場合は,エクステント・サイズを指定するか,または標準 設定のサイズである 1 MB を使用できます。エクステントがローカルに管理さ れる一時表領域では,このタイプの割り当てしか使用できません。 NEXT,PCTINCREASE,MINEXTENTS,MAXEXTENTS,DEFAULT STORAGE の各ストレージ・パラメータは,ローカルに管理されるエクステン トでは無効です。 次の表は,Mercury Business Availability Center で作業を行う場合にサポートおよ び推奨されている,ローカル管理される表領域のオプションを示します。 オプション サポート 推奨 備考 ローカルに管理される一時 表領域 ○ ○ TEMPFILE を使用す る必要があります。 TEMPFILE は作成時 にディスク上で割り 当てられるとは限り ません。 ローカル管理されるデータ 表領域 ○ ○ TEMPFILE を使用した,ローカルに管理される一時表領域の詳細については, 第 13 章「Oracle サーバのサイズ設定ガイドライン」を参照してください。 Mercury Business Availability Center の Oracle 表領域の作成 Mercury Business Availability Center の Oracle 表領域は oracle_tablespace_create.bat(UNIX でのインストールの場合は oracle_tablespace_create.sh)スクリプトを使用して作成します。 注:このスクリプトは 1 つのデータ・ファイルで構成される表領域を作成するた めの基本スクリプトです。このファイルは,インストールされている Mercury Business Availability Center のサイズに応じて編集できます。詳細については,第 13 章「Oracle サーバのサイズ設定ガイドライン」を参照してください。 95 95 第 3 部 • Oracle サーバ・データベースの導入と保守 Mercury Business Availability Center の Oracle 表領域を作成するには,次の手 順を実行します。 oracle_tablespace_create.bat または oracle_tablespace_create.sh スクリプ トのあるディレクトリから,次のコマンドを実行します。 oracle_tablespace_create [admin_user] [admin_password] [tns_entry_name] [tablespace_name] [file_name] [file_size] ➤ [admin_user] : Oracle Server に対する管理権限を持つユーザの名前 ➤ [admin_password] : 上で指定したユーザのパスワード ➤ [tns_entry_name] : ローカルの Oracle Client にある tnsnames.ora ファイル で指定されている TNS 名 ➤ [tablespace_name] : 作成する表領域の名前 ➤ [file_name] : 作成するファイルの名前(ファイルへのフル・パスを含む) ➤ [file_size] : ファイル・サイズ(M で MB を表し,K で KB を表す) • 管理用ユーザ・スキーマの場合は,ファイル・サイズとして 500 MB を 指定します。 • スタンドアロン CMDB ユーザ・スキーマの場合は,ファイル・サイズと して 500 MB を指定します。 • プロファイル・ユーザ・スキーマの場合は,ファイル・サイズとして 500 MB を指定します。実際に必要なサイズは,Mercury Business Availability Center によって生成されるデータ量と,履歴データを保持し ておく期間によって異なります。 96 第 10 章 • Mercury Business Availability Center データベース環境のセットアップ 管理用ユーザ・スキーマ 管理用ユーザ・スキーマには Mercury Business Availability Center の設定データ が格納され,通常は小さなデータベースです。管理用ユーザ・スキーマは,手 作業で作成するか(推奨方法については次の項を参照),または Set Management Database ユーティリティを使用して自動的に作成できます。Set Management Database ユーティリティの詳細については,『サーバの導入』の 「Windows プラットフォームにおける管理データベース・パラメータの設定」 を参照してください。 注:本項の推奨事項に従って CMDB を手作業で作成する場合,標準の表構造を 格納している既存の CMDB に接続できないため,CMDB の生成スクリプトを 実行する必要があります。Mercury Business Availability Center に CMDB を作成 し,接続する詳細については,『プラットフォームの管理』の「Mercury ユニ バーサル CMDB の管理」を参照してください。 注:Set Management Database ユーティリティで作業を行うためには,まず Mercury Business Availability Center サーバすべてで,Oracle Client (tnsnames.ora ファイル)のインストールと設定を行う必要があります。詳細 については,103 ページ「Mercury Business Availability Center 向けの Oracle Client の設定」を参照してください。 Set Management Database ユーティリティでは,次のパラメータを指定するよう 求められます。 ➤ 管理者ユーザ名 : ユーザ・スキーマの作成に使用する Oracle Server に対して管理 権限を持つユーザの名前。標準設定では,Oracle の管理ユーザは system です。 ➤ 管理者パスワード : 上で指定したユーザのパスワード。標準設定では,Oracle の管理ユーザのパスワードは manager です。 ➤ 管理ユーザ名 : 作成する管理用ユーザ・スキーマの名前。Mercury Business Availability Center 用に作成するユーザ・スキーマごとに一意のユーザ名を指定 する必要があります。 97 97 第 3 部 • Oracle サーバ・データベースの導入と保守 ➤ 管理用パスワード : 管理用ユーザ・スキーマへのアクセスを許可するパスワー ド。このパスワードは,たとえば Set Management Database ユーティリティで管 理用ユーザ・スキーマの設定を指定するときなどに使用します。 ➤ tnsnames エントリ名 : 1 台以上の Oracle Client マシンにある tnsnames.ora ファ イルで指定されている TNS 名。 ➤ 標準設定の表領域 : 管理用ユーザ・スキーマ専用に作成する標準設定の表領域 の名前。詳細については,94 ページ「Mercury Business Availability Center の Oracle 表領域」を参照してください。 ➤ 一時表領域 : 管理用ユーザ・スキーマ専用に作成する標準設定の一時表領域の 名前。専用の一時表領域を作成しなかった場合は,代わりの一時表領域を指定 します(標準設定の Oracle 一時表領域は temp という名前です)。 ➤ ホスト名 : Oracle サーバがインストールされているホスト・マシンの名前。 ➤ SID : 上のホスト・マシンで特定の Oracle インスタンスを識別する Oracle パラ メータ。 注:データベース・サーバへの接続パラメータを変更した場合は,3 つの Mercury Business Availability Center サーバすべてにインストールされている Oracle Client で tnsnames.ora ファイルを更新する必要があります。その後, すべてのマシンで Mercury Business Availability Center サービスを再起動する必 要があります。 手作業での管理用ユーザ・スキーマの作成 認定を受けたデータベース管理者が(組織で決められたデータベース設定方法 に従って)管理用ユーザ・スキーマを手作業で作成することをお勧めします。 そして,Set Management Database ユーティリティを使用して,後で管理用ユー ザ・スキーマに接続します。Set Management Database ユーティリティの詳細に ついては,『サーバの導入』の「Windows プラットフォームにおける管理デー タベース・パラメータの設定」を参照してください。 注:管理用ユーザ・スキーマの手動設定は,データベース管理者の接続パラ メータをセキュリティで保護されていない接続経由では送信できない場合に, 実行しなければならないことがあります。 98 第 10 章 • Mercury Business Availability Center データベース環境のセットアップ 手作業での管理用ユーザ・スキーマの作成は,<コア・サーバのルート・ディ レクトリ> \AppServer\webapps\site.war\DataBases\ORA_DB_Utils ディ レクトリにある management_ora_dbobjects_create.bat(UNIX でのインス トールの場合は management_ora_dbobjects_create.sh)を使用して実行し ます。 管理用ユーザ・スキーマ(標準設定の CMDB を含む)を手作業で作成するに は,次の手順を実行します。 <コア・サーバのルート・ディレクトリ> \AppServer\webapps\site.war \DataBases\ORA_DB_Utils ディレクトリから次のコマンドを実行します (使用するパラメータの詳細については,97 ページを参照してください)。 management_ora_dbobjects_create [admin_user] [admin_password] [application_management_user] [application_management_password] [tns_entry_name] [default_tablespace] [temporary_tablespace] CMDB ユーザ・スキーマを手作業で作成するには,次の手順を実行します。 オブジェクトを作成する表領域から,<コア・サーバのルート・ディレクトリ> \AppServer\webapps\site.war\DataBases\ORA_DB_Utils ディレクトリにあ る次のスクリプトを実行します。 ➤ common_ora_dbobjects_create.sql ➤ create_cm_tables_cmdb.sql プロファイル・ユーザ・スキーマ プロファイル・ユーザ・スキーマには,Mercury Business Availability Center に よって収集されたパフォーマンス・データが格納され,通常は大きなデータ ベースとなります。プロファイル・データベースのサイズの詳細については, 第 13 章「Oracle サーバのサイズ設定ガイドライン」を参照してください。 プロファイル・ユーザ・スキーマは,手作業で作成するか(推奨方法について は次の項参照),または[プラットフォームの管理]の[セットアップと保守] タブにある[データベース管理]ページを使用して自動的に作成できます。プ ロファイル・データベースの自動作成の詳細については,『プラットフォーム の管理』の「データベースの管理」を参照してください。 99 99 第 3 部 • Oracle サーバ・データベースの導入と保守 プロファイル・ユーザ・スキーマを作成するときは,次のパラメータを指定す る必要があります。 ➤ 管理者ユーザ名 : ユーザ・スキーマの作成に使用する Oracle サーバに対して管理 権限を持つユーザの名前。標準設定では,Oracle の管理ユーザは system です。 ➤ 管理者パスワード : 上で指定したユーザのパスワード。標準設定では,Oracle の管理ユーザのパスワードは manager です。 ➤ プロファイル・ユーザ名 : 作成するプロファイル・ユーザ・スキーマの名前。 Mercury Business Availability Center 用に作成するユーザ・スキーマごとに一意の ユーザ名を指定する必要があります。 ➤ プロファイル・ユーザ・パスワード : プロファイル・ユーザ・スキーマへのア クセスを許可するパスワード。このパスワードは,[プラットフォームの管理] の[セットアップと保守]タブにある[データベース管理]ページから定義済 みのプロファイル・ユーザ・スキーマに接続するときに使用します。 ➤ tnsnames エントリ名 : 1 台以上の Oracle Client マシンにある tnsnames.ora ファ イルで指定されている TNS 名。 ➤ 標準設定の表領域 : プロファイル・ユーザ・スキーマ専用に作成する標準設定 の表領域の名前。詳細については,94 ページ「Mercury Business Availability Center の Oracle 表領域」を参照してください。 ➤ 一時表領域 : プロファイル・ユーザ・スキーマ専用に作成する標準設定の一時 表領域の名前。専用の一時表領域を作成しなかった場合は,代わりの一時表領 域を指定します(標準設定の Oracle 一時表領域は temp という名前です)。 注:データベース・サーバへの接続パラメータを変更した場合は,3 つの Mercury Business Availability Center サーバすべてにインストールされている Oracle Client で tnsnames.ora ファイルを更新する必要があります。その後, すべてのマシンで Mercury Business Availability Center サービスを再起動する必 要があります。 手作業でのプロファイル・ユーザ・スキーマの作成 認定を受けたデータベース管理者が(組織で決められたデータベース設定方法 に従って)プロファイル・ユーザ・スキーマを手作業で作成することをお勧め します。その後,[プラットフォームの管理]の[セットアップと保守]タブ にある[データベース管理]ページから,これらのプロファイル・ユーザ・ス 100 第 10 章 • Mercury Business Availability Center データベース環境のセットアップ キーマに接続します。[プラットフォームの管理]からプロファイル・ユーザ・ スキーマに接続する方法の詳細については,『プラットフォームの管理』の 「データベースの管理」を参照してください。 注:プロファイル・ユーザ・スキーマの手動設定は,データベース管理者の接 続パラメータをセキュリティで保護されていない接続を経由して送信できない 場合に,実行しなければならないことがあります。 手作業でのプロファイル・ユーザ・スキーマの作成は, <コア・サーバのルート・ディレクトリ> \AppServer\webapps\site.war\DataBases\ORA_DB_Utils ディレクトリに ある profile_ora_dbobjects_create.bat(UNIX でのインストールの場合は profile _ora_dbobjects_create.sh)を使用して実行します。 プロファイル・ユーザ・スキーマを手作業で作成するには,次の手順を実行し ます。 <コア・サーバのルート・ディレクトリ> \AppServer\webapps\site.war \DataBases\ORA_DB_Utils ディレクトリから次のコマンドを実行します (使用するパラメータの詳細については,100 ページを参照してください)。 profile_ora_dbobjects_create [admin_user] [admin_password] [application_management_user] [application_management_password] [tns_entry_name] [default_tablespace] [temporary_tablespace] 101 101 第 3 部 • Oracle サーバ・データベースの導入と保守 Mercury Business Availability Center の Oracle スキーマの権限 Oracle ユーザ・スキーマを使用するときは,ユーザに与えられた Oracle 権限に 基づいて許可される任意のデータベース操作を実行できます。次の一覧は <コア・サーバのルート・ディレクトリ> \AppServer\webapps\site.war \DataBases\ORA_DB_Utils ディレクトリに格納されている oracle_user_create.sql スクリプトから抜粋したもので,Mercury Business Availability Center ユーザに与える必要のある必須のデータベース権限を示しま す。これらの権限は,Mercury Business Availability Center のプラットフォーム・ コンポーネントが新しい Oracle ユーザを作成するときにも使用されます。 ➤ GRANT "CONNECT" TO < Mercury Business Availability Center の Oracle ユーザ・ スキーマ> ; ➤ GRANT CREATE ANY INDEX TO < Mercury Business Availability Center の Oracle ユーザ・スキーマ> ; ➤ GRANT CREATE ANY SEQUENCE TO < Mercury Business Availability Center の Oracle ユーザ・スキーマ> ; ➤ GRANT CREATE ANY TABLE TO < Mercury Business Availability Center の Oracle ユーザ・スキーマ> ; ➤ GRANT CREATE ANY TRIGGER TO < Mercury Business Availability Center の Oracle ユーザ・スキーマ> ; ➤ GRANT UNLIMITED TABLESPACE TO < Mercury Business Availability Center の Oracle ユーザ・スキーマ> ; ➤ GRANT CREATE ANY VIEW TO < Mercury Business Availability Center の Oracle ユーザ・スキーマ> ; ➤ GRANT CREATE ANY PROCEDURE TO < Mercury Business Availability Center の Oracle ユーザ・スキーマ> ; ➤ ALTER USER < Mercury Business Availability Center の Oracle ユーザ・スキーマ> DEFAULT ROLE ALL; 注:Mercury Business Availability Center では,これより上位の権限を持つすべての ユーザがサポートされています。Mercury Business Availability Center の認定を受け る場合は,上に示した Oracle 権限を持つ Oracle ユーザを使用してください。 102 第 11 章 Mercury Business Availability Center 向けの Oracle Client の設定 本章では,Oracle Client を Mercury Business Availability Center 向けに設定する方 法を説明します。Mercury Business Availability Center で作業を行うためには,3 つの Mercury Business Availability Center サーバすべてで,Oracle Client ソフト ウェアのインストールと設定を行う必要があります。 本章の内容 ページ Oracle Client のバージョンとオペレーティング・システム・プラット フォーム 104 Oracle Client のインストール 104 Oracle Client の設定 105 103 第 3 部 • Oracle サーバ・データベースの導入と保守 Oracle Client のバージョンとオペレーティング・システム・プ ラットフォーム 次の表に,Mercury Business Availability Center での作業において,サポートおよ び推奨されている Oracle Client のバージョンとオペレーティング・システム・ プラットフォームを示します。 サポート コンポーネ ント 推奨 バージョン / エ ディション サービス・ パック バージョン / エ ディション サービス・ パック Windows オ ペレーティ ング・シス テム Windows 2000 Server/Advanced Server Service Pack 4 Windows 2003 Server Standard / Enterprise Service Pack 1 Sun Solaris オペレー ティング・ システム Solaris 9 Solaris 8,10 Oracle Oracle 9.2.0.6 Oracle 10.2.0.1 Oracle Client のインストール Oracle Client のインストールの詳細については,Oracle のマニュアルを参照し てください。 インストール・プロセスの中でカスタム・インストール・オプションを選択し た場合は,次のコンポーネント([Oracle Client]の下にあります)を必ずイ ンストールしてください。 ➤ Oracle Net(TCP/IP アダプタを含む) ➤ Oracle Database ユーティリティ ➤ SQL*Plus ➤ OCI(Oracle Call Interface) 104 第 11 章 • Mercury Business Availability Center 向けの Oracle Client の設定 Oracle Client の設定 Mercury Business Availability Center で作業を行うためには, < ORACLE_HOME > \network\admin ディレクトリに格納されている tnsnames.ora ファイルを設定する必要があります。ここでは,Oracle サーバ のホスト・マシンの名前または IP アドレスと,Oracle サーバのリスナー・ポー ト(標準設定では通常 1521),および,SID(標準では ORCL)または service_name を指定します。tnsnames.ora ファイルの例を次に示します。 tnsnames.ora ファイルを設定するには Oracle に付属の Oracle Net Configuration Assistant ツールを使用することをお勧めします。詳細については,Oracle のマ ニュアルを参照してください。 SID やポート設定などの Oracle Client の設定が,Oracle サーバの設定と一致し ていることを確認します。Oracle Client マシンから Oracle サーバ・マシンへの 接続をテストするには,tnsping ユーティリティを使用します。 注:Mercury Business Availability Center の各サーバは,JDBC 軽量ドライバを使 用して Oracle サーバにアクセスします。JDBC 軽量ドライバでは,net*8/9 に準 拠したファイアウォール接続はサポートされていません。したがって,SQL データの送信だけが可能です。 Oracle Client 向けの MDAC Mercury Business Availability Center は Microsoft MDAC コンポーネントを使用し てデータベースに接続します。MDAC は Windows 2000 オペレーティング・シ ステムでは標準でインストールされています。 105 105 第 3 部 • Oracle サーバ・データベースの導入と保守 注:Mercury Business Availability Center では,MDAC バージョン 2.5,2.52, 2.61,2.62,および 2.7 SP1 更新がすべてサポートされています。Mercury Business Availability Center の認定を受けるには,必ず MDAC バージョン 2.7 SP1 更新を Oracle Client マシンにインストールしてください。このバージョンの MDAC は Mercury Business Availability Center サーバのインストール時に自動的 にインストールされます。 106 第 12 章 Oracle サーバ・データベースの保守 本章では,Oracle サーバ上に作成する Mercury Business Availability Center データ ベースについて推奨される各種保守手順およびチューニング手順について説明 します。また,データベースのバックアップおよびリカバリの方法についても 説明します。 本章の内容 ページ データベースの保守とチューニング 108 Oracle データベースのバックアップおよび回復 121 107 第 3 部 • Oracle サーバ・データベースの導入と保守 データベースの保守とチューニング データベースのパフォーマンスが低下する原因として,インスタンスやデータ ベースの設定に誤りがある,あるいは,Oracle のトランザクション,ユーザ, またはプロセスによって異常にリソースが消費されている場合,などがありま す。データベース管理者は,リソースの消費を予防の観点から監視し,問題が あればパフォーマンスに影響が及ぶ前に是正することが大切です。 注:Oracle によって最もよく使用される 3 つのシステム・リソースは,メモリ, CPU,および I/O です。 データベースの動作を監視し,システムのボトルネックの特定に役立つツール が,サードパーティから提供されています。次のガイドラインを参考にしてく ださい。 SGA(システム・グローバル領域) SGA は,常に物理メモリに合わせて設定し,スワップが生じないようにしま す。SGA をシステムの物理メモリの 70% を超えないように設定して,ほかの システムやクライアント・プロセスのために十分なメモリを残しておくことを お勧めします。 データベースの負荷の状況 ustlbstat/utlestat(または STATSPACK)を定期的に実行してデータベースの 動作を監視します。Oracle 10g では,AWR スナップショットが定期的(標準設 定では 1 時間ごと)に作成され,7 日間保持されます。AWR レポートは STATSPACK レポートと同じ方法で作成し,使用できます。このツールの実行 方法と表示される出力の詳細については,「Oracle Metalink Note 62161.1: BSTAT/ESTAT」 (http://metalink.oracle.com/metalink/plsql/showdoc?db=Not&id=62161.1) ,または 「Oracle Metalink Note 94224.1: STATSPACK FAQ」 (http://metalink.oracle.com/metalink/plsql/showdoc?db=Not&id=94224.1)を参照し てください。 また,I/O の競合を特定するためにシステムの I/O 負荷を監視することもお勧め します。どのディスクの負荷が最も高いかを特定したら,utlbstat/utlestat の出力 108 第 12 章 • Oracle サーバ・データベースの保守 を利用して競合の原因となっている Oracle データ・ファイルを特定して調べ, データ・ファイルを再配置すべきかどうかを検討します。 CPU と I/O CPU とファイル・システムは,データベース・サーバにおいて消費される主要 リソースであり,監視することをお勧めします。CPU の使用率は 70% を超え ないようにし,I/O 待機も 10% を上回らないようにします。 これらのリソースを監視するには,Windows では perfmon を,UNIX では top をそれぞれ使用できます。 Oracle アラート・ファイル Oracle では異常なイベントが alert.log ファイルに登録されます。このファイル の場所は BACKGROUND_DUMP_DEST パラメータで定義されます。 このファイルを定期的に確認して,修正を必要とする ORA-XXXXX エラーな どの問題がないか調べることをお勧めします。 アーカイブ・ログ - ファイル・システム アーカイブログ・モードを使用するときは,ARCHIVE_DUMP_DEST の場所で ディスクの使用率を監視します。これらのファイルのバックアップと削除を定 期的に実施し,新しいアーカイブ・ファイル用に十分なディスク領域を残して おきます。 通常,アーカイブ・ファイルのサイズは REDO ログ・ファイルのサイズと同じ です。REDO ログ・ファイルのサイズを調べるには,オペレーティング・シス テムのコマンドを使用するか,または次のクエリを実行します。 SQL> select GROUP#, BYTES from V$LOG; 109 109 第 3 部 • Oracle サーバ・データベースの導入と保守 一定期間内(たとえば 1 日)に生成されるアーカイブ・ファイルの数を調べる には,システムが安定してから次のクエリを実行します。 SQL> alter session set NLS_DATE_FORMAT = 'DD-MON-YYYY'; SQL> select TO_DATE(TO_CHAR(FIRST_TIME,'DD-MON-YYYY')) as "Day", COUNT(*) as "Number of files" from V$LOG_HISTORY group by TO_CHAR(FIRST_TIME,'DD-MON-YYYY') order by 1 asc; 表領域の格納域 データの増加に伴う領域エラーを避けるため,表領域の使用率を定期的に監視 します。 表領域の 1 つで領域が足りなくなった場合は,ALTER TABLESPACE <表領域 名> ADD DATAFILE... コマンドを使用して,1 つ以上のデータ・ファイルを表 領域に追加できます。 ディクショナリ管理される表領域の合体 Oracle 表領域の空き領域は,新しく作成されたエクステントか,またはいった ん使用されて解放されたエクステントで構成されます。表領域内の空き領域の 一部が,いったん使用されて解放されたエクステントで構成されている場合, 表領域が一時的に断片化することがあります。フラグメンテーションを修正す るため,隣り合う 2 つのエクステントを合体して 1 つの大きなエクステントを 作成できます。 110 第 12 章 • Oracle サーバ・データベースの保守 フラグメンテーションをチェックするには,SQL*Plus を使用して(システム管 理者アカウントを使用)次のクエリを実行します。 SELECT A.TABLESPACE_NAME, COUNT(*) BLOCK_CASES FROM DBA_FREE_SPACE A, DBA_FREE_SPACE B WHERE A.TABLESPACE_NAME = B.TABLESPACE_NAME AND A.FILE_ID = B.FILE_ID AND A.BLOCK_ID+A.BLOCKS = B.BLOCK_ID GROUP BY A.TABLESPACE_NAME / このクエリは,合体を必要とする表領域の一覧を返します。合体は Oracle SMON によって自働的に処理されますが,それほど頻繁に実行されない場合が あります。したがって,ALTER TABLESPACE <表領域名> COALESCE; コマ ンドを使用して表領域のエクステントを合体することをお勧めします。 データベースについての統計情報の収集 Mercury Business Availability Center プラットフォームは,Oracle のコスト・ベー スのオプティマイザと連携動作するように設計,構築されています。コスト・ ベース・オプティマイザが正常に動作するためには,スキーマのすべての表に ついて定期的に統計情報を収集する必要があります。 Mercury Business Availability Center の導入の初期段階において,次の手順を実行 して,すべての Mercury Business Availability Center オブジェクト(表とイン デックス)の統計情報を収集することをお勧めします。 1 SQL*Plus を使用して Mercury Business Availability Center プロファイル・スキー マにログインします。 2 次のコマンドを実行します。 Exec DBMS_STATS.GATHER_SCHEMA_STATS (ownname => ' < Oracle ス キーマの名前> ', estimate_percent => 20, cascade => TRUE); Mercury Business Availability Center システムが安定したら,1 日に 1 回統計情報 を収集します。 111 111 第 3 部 • Oracle サーバ・データベースの導入と保守 Oracle 10g には,10g のスケジューラ API を使用するとその一部に,すべての データベース・スキーマの統計情報を収集する自動化されたジョブがありま す。自動化されたジョブは GATHER_STATS_JOB で,SYS スーパー・ユーザ が所有しています。このジョブは,あらかじめ定義された時刻に古い(不正確 な)統計情報を収集します([メンテナンス]ウィンドウ)。空の統計情報か古 い統計情報のみが更新されるため,Oracle 9i の場合のように不要なデータの検 索は回避されます。 [メンテナンス]ウィンドウは,WEEKNIGHT_WINDOW(月曜から金曜の午後 10:00 にジョブを開始)と WEEKEND_WINDOW(土曜の正午 12:00 にジョブを 開始)で構成され,日曜にスケジューリングされるジョブはありません。より システムに適合したメンテナンス時間に統計情報の収集が必要な場合,データ ベース管理者は Oracle Enterprise Manager コンソールを使ってスケジュールを変 更できます。Oracle のスケジューラの概要については,Oracle 10g のマニュア ルにある『Oracle Database 管理者ガイド』の「スケジューラの概要」の章を参 照してください。 大規模な Mercury Business Availability Center 環境で作業を行う際は,1 日の中で データ変更の量が著しいオブジェクトのみについて,または作成された新規の オブジェクト(パージ・マネージャによって作成された新しい表やインデック スなど)のみについて,統計情報を収集することをお勧めします。 特定のスキーマの表とそのインデックスについて統計情報を収集するには,次 の手順を実行します。 1 SQL*Plus を使用してスキーマにログインします。 2 各表について,次のコマンドを実行して統計情報を収集します。 Exec DBMS_STATS.GATHER_TABLE_STATS (ownname => ' < Oracle スキー マの名前> ',tabname => ' <統計情報を収集する表の名前> ', estimate_percent => 5, cascade => TRUE); 注:Cascade => True によって,表内のすべてのインデックスを分析するよう Oracle データベースに指示します。 112 第 12 章 • Oracle サーバ・データベースの保守 または,次の手順を実行して表とインデックスごとに統計情報を収集すること もできます。 1 SQL*Plus を使用してプロファイル・スキーマにログインします。 2 個々の表について,ANALYZE TABLE <表名> ESTIMATE STATISTICS SAMPLE < x > ROWS; クエリを使用して統計情報を収集します。「x」の値は, 表内のレコード数のおよそ 5% にすることをお勧めします。 3 個々のインデックスについては,ANALYZE INDEX <インデックス名> COMPUTE STATISTICS; クエリを使用して統計情報を収集します。 注:統計情報の収集は,長時間かかる可能性があり,リソースを消費する操作 です。したがって,統計情報の収集は特別に設定した保守時間中に実施するこ とをお勧めします。 表のリストを取得するには,SELECT TABLE_NAME FROM USER_TABLES ク エリを使用します。 スキーマ・インデックスのリストを取得するには,SELECT INDEX_NAME FROM USER_INDEXES クエリを使用します。 CMDB に関する統計情報の収集 クエリがあらかじめ定義されており,予想されるデータベース・サイズに従っ て切り替えが可能な,ほかのデータベースと異なり,CMDB データベースはそ のデータ・モデルに定義されたパターン・ビューに従って,クエリを動的に構 成します。これには常に正確な統計情報が必要です。CMDB について統計情報 を更新する日次ジョブの実行に加えて,CMDB のスキーマ・オブジェクトへ大 きな変更があった場合(通常は大量なトランザクションの挿入によって起こり ます)は,手作業で統計情報を更新することをお勧めします。次のシナリオで は,手作業で CMDB 統計情報を更新します。 ➤ Automated Discovery タスク : ディスカバリ・マネージャが構成アイテム (CI)を自動的に検出し,CMDB に挿入するプロセスです。 ➤ Mercury Business Availability Center アダプタ同期 : 大量なデータを CMDB へロードする可能性がある場合。[管理]>[CMDB]からアクセスできる, [ソース マネージャ]タブからアダプタを同期します。 113 113 第 3 部 • Oracle サーバ・データベースの導入と保守 Oracle 9i の統計情報収集のガイドライン 次のガイドラインは Oracle 9i に適用されます。 日次ジョブの実行 CMDB に関する統計処理を実行する日次ジョブを作成するには, <データ処理サーバ・マシンのルート・ディレクトリ> \MercuryAM\CMDB\dbscripts\oracle ディレクトリにある create_statistics_job.bat スクリプトを使用します。スクリプトを実行するに は,データベース・クライアント・ツール(SQLPLUS)が必要です。 SQLPLUS がインストールされている別のマシンへスクリプトを移動する場合, スクリプトがあるディレクトリを必要なマシンへコピーします。スクリプトは 次のコマンド構文を使って実行します。 create_statistics_job.bat <スキーマ> <パスワード> < db エイリアス> <時間> 各項目について説明します。 ➤ スキーマ : 統計ジョブをインストールしているスキーマの,CMDB スキー マ・ユーザの名前。 ➤ パスワード : データベース・スキーマ・ユーザのパスワード。 ➤ db エイリアス : tnsnames.ora ファイルで指定された対象データベースへ接 続する db エイリアス。対象サーバ用 tnsnames.ora ファイルには必ずエント リが 1 つあることを確認します。 ➤ 時間 : 統計ジョブを実行する時刻。有効な値は 0 ~ 23 です。標準設定は 「0」(午前 0 時)です。 注:提供スクリプトを使用して自動日次ジョブを生成しない場合,必要に応じ て次のコマンドを手動で実行できます。 Begin DBMS_STATS.GATHER_SCHEMA_STATS (ownname => ' < Oracle ス キーマの名前> ', cascade => TRUE) ; end; この API は,統計情報が直前の呼び出しと同じでも,表全体の統計情報と関連 するインデックスを収集します。 114 第 12 章 • Oracle サーバ・データベースの保守 毎晩深夜 0 時など,システムに特に重い負荷がかかっていない保守時間にジョ ブのスケジュールを設定する必要があります。 手作業による統計情報の更新 CMDB のデータに大きな変更があった場合,次のいずれかの方法で統計情報を 更新します。 ➤ runStatistics JMX を使用します。 ➤ Web ブラウザで,http:// <センタ・サーバ・マシン名> :8080/jmx-console を開きます。 ➤ Topaz セクションで,CMDB Dal Services を選択します。 ➤[runStatistics]にカスタマ ID を入力します。個々の Mercury Business Availability Center システムの標準設定のカスタマ ID(つまり,Mercury Managed Services で管理されていないもの)は 1 です。 ➤[runStatistics]で[Invoke]をクリックします。CMDB 統計情報が再生成 されます。 ➤ Oracle Client を使って日次ジョブを手作業で実行します。 ➤ SQLPLUS 経由で CMDB スキーマに接続します。 ➤ クエリ Select job from user_jobs where upper(what) like '%GATHER_SCHEMA_STATS%'; を実行します。 クエリの出力はジョブ番号です。 ➤ Exec dbms_job.run ( <ジョブ番号> ); を呼び出し,ジョブを実行します。 ➤ CMDB スキーマへ接続し,PL/SQL のブロック begin DBMS_STATS.GATHER_SCHEMA_STATS (ownname => ' <オラクル・ス キーマ名> ' , cascade => TRUE) ; end; を実行します。 Oracle 10g の統計情報収集のガイドライン 次のガイドラインは Oracle 10g に適用されます。 日次ジョブの実行 Oracle 10g 以降では,統計情報を収集する自動化されたジョブが含まれている ため,CMDB スキーマ専用の日次ジョブを定義する必要はありません。詳細に ついては,111 ページ「データベースについての統計情報の収集」を参照して ください。 115 115 第 3 部 • Oracle サーバ・データベースの導入と保守 毎時ジョブの実行 Oracle 10g では,オブジェクトの変更を自動的に監視しているため, DBMS_STATS.GATHER_SCHEMA_STATS API の GATHER AUTO メソッドを 操作して,欠落した統計情報や,古い統計情報だけを収集できます。つまり, 統計情報が正確なオブジェクトを表していない場合や,通常はオブジェクトの データが 10 %以上変更された場合に統計情報が収集されます。 データの大きな変更があるたびに手作業で統計情報を更新しない場合は,スケ ジューラ・ジョブに登録して,1 時間ごとに CMDB スキーマの古い統計情報を 更新することをお勧めします。PL/SQL のブロック begin DBMS_STATS.GATHER_SCHEMA_STATS (ownname => ' < Oracle スキーマ名> ', options => 'GATHER AUTO') ; end; を実行すると,自動で毎 時更新を実行します。 注:Oracle 10g 以降では,ジョブの自動化に DBMS_JOB API を使用する代わり に Oracle スケジューラ・ジョブの API を使用することを強くお勧めします。 手作業による統計情報の更新 CMDB のデータに大きな変更があった場合,次のいずれかの方法で統計情報を 更新します。 ➤ runStatistics JMX を使用します。 ➤ Web ブラウザで,http:// <センタ・サーバ・マシン名> :8080/jmx-console を開きます。 ➤ Topaz セクションで,CMDB Dal Services を選択します。 ➤[runStatistics]にカスタマ ID を入力します。個々の Mercury Business Availability Center システムの標準設定のカスタマ ID(つまり,Mercury Managed Services で管理されていないもの)は 1 です。 ➤[runStatistics]で[Invoke]をクリックします。CMDB 統計情報が再生成 されます。 注:JMX ユーティリティはデータベースの解放を確認し,Oracle 10g データ ベースの場合は,GATHER AUTO メソッドで統計処理を実行します。 116 第 12 章 • Oracle サーバ・データベースの保守 ➤ CMDB スキーマへ接続し,PL/SQL のブロック begin DBMS_STATS.GATHER_SCHEMA_STATS (ownname => ' <オラク ル・スキーマ名> ' , options => GATHER AUTO) ; end; を実行します。 FREELISTS 格納パラメータ Mercury Business Availability Center の分散環境では,Mercury Business Availability Center データベースの表とそのインデックスの中で,FREELISTS 格納パラメー タの値を標準値の 1 から 20 に増やすことをお勧めします。FREELISTS 格納パ ラメータの値を大きくすることで,データ・ブロックの待ちが回避されます。 SQL*Plus を使用して,FREELISTS パラメータの値を 20 に変更します。 表内の FREELISTS パラメータを変更するには,次のコマンドを実行します。 alter table <表名> storage ( freelists 20 ); インデックス内の FREELISTS パラメータを変更するには,次のコマンドを実行 します。 alter table <インデックス名> storage ( freelists 20 ); 大きな表をプロファイル・スキーマ内に作成する場合は,Mercury Business Availability Center によって FREELISTS パラメータが自動的に 20 に設定されま す。パージ・マネージャなど,ほかのコンポーネントによって後で作成される データベース・オブジェクト(表とインデックス)は,Oracle の標準設定の FREELISTS 値 1 を使用して作成されます。これらのオブジェクトを追跡し,そ れらの FREELISTS パラメータ値を 20 に設定することをお勧めします。 注:FREELISTS パラメータは,セグメント領域が手動で管理されている表領域 内に作成されたオブジェクトにのみ適用されます。 CMDB インデックス・フラグメンテーション CMDB スキーマは,表カラム検索拡張機能の Oracle B-tree インデックスで構成 されます。 117 117 第 3 部 • Oracle サーバ・データベースの導入と保守 CMDB スキーマのインデックスの構造を定期的に(アクティブなシステムでは 少なくとも毎週)検証し,必要であれば断片化したインデックスを再構築する ことを強くお勧めします。 インデックスが断片化する主な理由は次のとおりです。 ➤ 行の削除 : 表中の行が削除される場合,Oracle インデックス・ノードは物理的 には削除されず,同様にエントリもインデックスから削除されません。その一 方で,Oracle ではインデックス・エントリが論理的に削除され,使用されない ノードがインデックス・ツリーに残ります。これらのノードは,隣のエントリ が要求されると再利用されることがあります。ただし,近くの行が大量に削除 されると,削除された末端行が Oracle によって再利用されることはほとんどあ りません。領域の浪費に加えて,削除された大量の末端ノードが存在すること で,インデックス・スキャンで必要以上に時間がかかることになります。 時間の経過に伴い,スキーマの表から行が削除されていった後では,行の削除が ユーザの意志によるものか CMDB エンジンによる自動的なものかを問わず,CMDB スキーマのインデックスの一部を再構築する必要の生じることがあります。 ➤ インデックスの高さ : インデックスの高さとは,インデックスに含まれる最大 レベル数のことを指します。インデックスのレベル数が増加すると,インデッ クスを検索する際,ブロックの読み取りが多くなります。大量の行が表に追加 されると,Oracle ではインデックスのレベルを追加して,新しい行に対応させ ることがあります。これによって,大量挿入が起こったのがインデックス・ツ リーの一部の領域だけであっても,インデックスがレベル 4 にまで達してしま うことがあります。Oracle インデックスはレベル 3 以内では何百万ものエント リをサポートできますが,レベル 4 以上の Oracle インデックスでは再構築する ことでサポートできます。 CMDB の表では,レベル 4 以上のインデックスはすべて再構築することをお勧 めします。 インデックスの保守ユーティリティ Mercury Business Availability Center のインデックスの保守ユーティリティ (maintain_indexes.bat)を使うと,レベル 3 以上のインデックスや,10 万以 上のエントリ値か 10% 以上削除されたエントリ値を持つインデックスを識別 し,再構築することができます。 ユーティリティを実行する場合,フラグを設定して断片化されたインデックス を識別し,自動的に再構築させることができます。ただし,インデックスは手 作業で再構築することをお勧めします。 118 第 12 章 • Oracle サーバ・データベースの保守 ユーティリティを実行すると,ログファイル(index_stats.log)が生成され, 次のエントリが格納されます ➤ 再構築する候補として識別されたインデックスの,アルファベット順のリス ト。リストに含まれるインデックスすべてについて,インデックスの高さと削 除行の比率など,統計情報が表示されます。 ➤ 手作業でインデックスを再構築するのに使用できる,一覧に含まれる各イン デックス用の再構築コマンド。 このユーティリティは,対象スキーマに TEMP_STATS という名前の表も作成 します。これには,再構築候補のインデックスだけでなく,すべてのインデッ クスとそれぞれに関連する統計情報が格納されます。後の段階で結果を検査で きるように,この表は,手動で削除されるまでスキーマ内に残されます。 注意 : インデックスの保守ユーティリティは,スキーマのインデックスをすべ て解析するため,リソースを多く使用します。データベース・オブジェクトを ロックしたり,ほかのセッションでロックされたインデックスをスキップした りすることもあります。インデックスの保守ユーティリティは,保守時間内に のみ実行することをお勧めします。 インデックスの保守ユーティリティを実行するには,次の手順を実行します。 1 Mercury Business Availability Center Modeling Data Processing サーバの \MercuryAM\CMDB\dbscripts\oracle\utils ディレクトリから,Oracle デー タベース・クライアントがインストールされている Windows マシンへ次のファ イルをコピーします。 ➤ maintain_indexes.bat ➤ maintain_indexes.sql 2 ファイルをコピーしたマシンで,DOS コマンド・ウィンドウを開き,ファイル をコピーした場所へ移動します。 3 次のコマンド構文を使ってインデックスの保守ユーティリティを実行します。 maintain_indexes.bat <スキーマ> <パスワード> < db エイリアス> (再 構築のフラグ) 各項目について説明します。 119 119 第 3 部 • Oracle サーバ・データベースの導入と保守 ➤ スキーマ : ユーティリティを実行するスキーマの,データベース・スキー マ・ユーザの名前。 ➤ パスワード : データベース・スキーマ・ユーザのパスワード。 ➤ db エイリアス : tnsnames.ora ファイルで指定された対象データベースへ接 続する db エイリアス。対象サーバ用 tnsnames.ora ファイルには必ずエント リが 1 つあることを確認します。 ➤ 再構築のフラグ : ユーティリティで自動的にインデックスを再構築させるフ ラグ。フラグには,ユーティリティで自動的にインデックスを再構築させな い場合は 0 を,再構築させる場合は 1 を設定します。標準設定は 0 です。 インデックスの保守ユーティリティの実行が終了したら,手順 1 でファイルを コピーしたディレクトリの index_stats.log ファイルを確認し,再構築候補の インデックスのリストと使用する再構築用コマンドを確認します。 注:CMDB が管理データベースの一部の場合(標準設定の場合),管理データ ベース・スキーマ用のインデックスの保守ユーティリティを実行します。別に CMDB を作成している場合,CMDB スキーマ用のインデックスの保守ユーティ リティを実行します。 注:インデックスの保守ユーティリティの実行時間はインデックス・サイズ と,実行開始時のシステムへの負荷に依存します。 120 第 12 章 • Oracle サーバ・データベースの保守 Oracle データベースのバックアップおよび回復 組織のバックアップ計画が試されるのは,障害が発生してデータが失われたと きです。アプリケーション・ロジックのエラーや,インスタンス障害による Oracle の起動阻害,ディスクのクラッシュによるメディア障害など,いくつか の原因によって,データが失われたり,または壊れたりする可能性がありま す。定期バックアップ以外に,データベースの構成を変更したとき(たとえば データ・ファイルをデータベースに追加したときなど),またはソフトウェア やハードウェアをアップグレードする前に,バックアップを実施することが重 要です。 バックアップ計画を決めるとき,システムの作業負荷や,使用率計画,データ の重要度,データベースのハードウェア環境などのいくつかの要素について検 討します。 Oracle のバックアップは,SQL コマンドを実行するスクリプトと,ファイルを コピーするオペレーティング・システム・コマンドを組み合わせて実行できま す。または,Oracle RMAN(Recovery Manager)コマンドを使用することもで きます。 データベースで実行したバックアップについて,その更新レコードを維持し, 必要なときにそれらのレコードを使用してリカバリできるようにすることをお 勧めします。RMAN を使用する場合は,カタログからカタログ情報を使用でき ます。 バックアップの方法 本項では,利用可能なさまざまなバックアップ方法について説明します。 コールド・バックアップ コールド・バックアップはオフライン・バックアップとも呼ばれ,データベー ス・レベルでバックアップを行います。通常,コールド・バックアップでは, バックアップを開始する前にデータベースをシャットダウンする必要がありま す。ダウンタイムの長さは,データベースのサイズ,バックアップ・メディア (ディスクまたはテープ),バックアップ・ソフトウェア,使用しているハード ウェアなどによって異なります。 インスタンスを停止したら,そのすべてのデータ・ファイル,ログ・ファイ ル,制御ファイル,および設定ファイルを,ディスク,またはそのほかのメ ディアにコピーします。コピーが完了したら,インスタンスを再開できます。 121 121 第 3 部 • Oracle サーバ・データベースの導入と保守 このバックアップ方法では,過去にスナップショットが作成された時点まで回 復することが可能です。 詳細については,『Oracle バックアップおよびリカバリ・ガイド』 (http://otn.oracle.com/pls/db92/db92.show_toc?partno=a96519&remark=drilldown& word=Backup)を参照してください。 ホット・バックアップ ホット・バックアップはオンライン・バックアップとも呼ばれ,インスタンスが 実行中でユーザがデータベースに接続している間にバックアップを実行できま す。このバックアップ方法は表領域レベルでのバックアップであり,データベー スをアーカイブログ・モードで運用する必要があります。このモードでは, Oracle によって REDO ログ・ファイルのコピー(アーカイブ・ファイルと呼ばれ ます)が生成され,それによって変更を継続的に追跡できます。生成されたアー カイブ・ファイルは,インスタンス・パラメータ・ファイル内の LOG_ARCHIVE_DEST(または LOG_ARCHIVE_DEST_NN)パラメータで指定さ れたアーカイブ先に書き込まれます。アーカイブに関連するそのほかのパラメー タとして,LOG_ARCHIVE_FORMAT と LOG_ARCHIVE_START があります。 バックアップを開始したら,すべてのデータ・ファイル,制御ファイル,アー カイブ・ファイル,および設定ファイルを,ディスク,またはそのほかのメ ディアにコピーします。このバックアップ方法では,任意の時点まで回復する ことが可能です。アーカイブログ・モードで運用するためには,増分アーカイ ブ・ファイルを格納するためのディスク領域が別途必要になります。そのた め,データベースのパフォーマンスに影響を与える可能性があります。また, バックアップ処理中はディスクに負荷がかかるために,Mercury Business Availability Center のパフォーマンスに多少低下する可能性があります。 詳細については,『Oracle バックアップおよびリカバリ・ガイド』 (http://otn.oracle.com/pls/db92/db92.show_toc?partno=a96519&remark=drilldown& word=Backup)を参照してください。 エクスポート コールド・バックアップまたはホット・バックアップという物理的なバック アップ方法以外に,エクスポートと呼ばれる論理的なバックアップ方法も利用 できます。 エクスポート・ユーティリティは,スキーマの構造と内容を Oracle の構造化 ファイルにダンプ出力します。この方法を使用して,同じデータベースの 2 つ のスキーマ間で,または 2 つの別々の Oracle データベース間で,データを転送 122 第 12 章 • Oracle サーバ・データベースの保守 できます。エクスポートしたデータをデータベースにロードするには,イン ポート・ユーティリティを使用します。 詳細については,『Oracle ユーティリティ・ガイド』の「Export/Import」の部 (http://otn.oracle.com/pls/db92/db92.show_toc?partno=a96652&remark=drilldown& word=Export)を参照してください。 Oracle 10g では,データのエクスポートに Oracle Data Pump ユーティリティを使 用できます。詳細については,Oracle Web サイトの『 Oracle ユーティリティ・ ガイド』の「Data Pump」のページ (http://download-east.oracle.com/docs/cd/ B19306_01/server.102/b14215/part_dp.htm#i436481) を参照してください。 注:Mercury Business Availability Center では特定のバックアップ方法の使用が求 められることはありませんが,Mercury Business Availability Center が使用してい る複数のデータベース・ユーザ・スキーマ(管理用およびプロファイル用)に 適したバックアップ方法を使用することをお勧めします。 Oracle Recovery Manager - RMAN RMAN(Recovery Manager)は,対象となるデータベースのバックアップと復 元を可能にする Oracle の汎用ツールです。RMAN で作業を行う際は,RMAN カタログ・スキーマで作業を行うかどうかを選択できます。このカタログは Oracle スキーマの内部で管理されており,登録されたデータベース構造に関す る情報と,RMAN を使用して実行されたバックアップが格納されます。カタロ グに対してクエリを実行することで,バックアップ・レポートを生成したり, コピーの有無を調べたりできます。1 つのカタログで,1 つ以上のデータベー スから取得したバックアップ情報を管理できます。 通常,RMAN カタログは運用中のデータベースとは別のデータベース・インス タンスに置かれ,専用のバックアップ計画を作成します。RMAN カタログが必 要となるのは,バックアップまたはリカバリのときだけです。 RMAN ツールをサードパーティ製のバックアップ・ソフトウェアと組み合わせ て使用することで,バックアップおよびリカバリのための完全なソリューショ ンを確立できます。 RMAN には次のような利点があります。 123 123 第 3 部 • Oracle サーバ・データベースの導入と保守 ➤ バックアップされたファイルを圧縮して空のデータ・ブロックを除外すること でバックアップ・データが最小限に抑えられ,時間と領域を節約できます。 ➤ 増分バックアップがサポートされています。 ➤ バックアップのステータスを報告する機能をユーザに提供します。 ➤ 可能な場合は,バックアップおよびリカバリのパラレル処理がサポートされま す。 ➤ サードパーティ製のバックアップ・メディア・ツールと組み合わせて使用でき ます。 RMAN の詳細については,Oracle 9i については 『Oracle Recovery Manager ユーザーズ・ガイド』 (http://otn.oracle.com/pls/db92/db92.show_toc?partno=a96566&remark=drilldo wn&word=RMAN) と『Oracle Recovery Manager リファレンス』 (http://otn.oracle.com/pls/db92/db92.show_toc?partno=a96565&remark=drilldo wn&word=RMAN) を,Oracle 10g については『バックアップおよびリカバリ・ アドバンスト・ユーザーズ・ガイド』(http://downloadeast.oracle.com/docs/cd/B19306_01/backup.102/b14191/toc.htm) と 『Backup and Recovery Reference』(http://downloadeast.oracle.com/docs/cd/B19306_01/backup.102/b14194/toc.htm) を参照してく ださい。 124 第 13 章 Oracle サーバのサイズ設定ガイドライン 本章では,Oracle サーバと Mercury Business Availability Center で作業を行う場合 に必要となる,Oracle データベースの設定のガイドラインを示します。導入す る Mercury Business Availability Center のサイズによって推奨設定は異なります。 本章の内容 ページ Mercury Business Availability Center サイズ設定 126 ハードウェアのサイズ設定 127 Oracle パラメータのサイズ設定 128 Oracle ファイルのサイズ設定 132 125 第 3 部 • Oracle サーバ・データベースの導入と保守 Mercury Business Availability Center サイズ設定 Mercury Business Availability Center のデータベース設定の要件は,Mercury Business Availability Center によって生成されるデータ量によって異なります。 たとえば,3 個のビジネス・プロセス・モニタが 300 日間にわたってデータを 生成し,各エージェントで 10 件のトランザクションと WebTrace を 15 分ごとに 実行するビジネス・プロセス・プロファイルを 5 個実行して,トランザクショ ンのうち 5% がエラーを返す,という場合を考えます。このような規模のデー タに対しては小規模のデータベースを使用することになります。 一方,10 個のビジネス・プロセス・モニタが 250 日間にわたってデータを生成 し,各エージェントで約 600 の測定を実行する 50 個の SiteScope プロファイル と,10 件のトランザクションおよび WebTrace を 15 分ごとに実行する 30 個の ビジネス・プロセス・プロファイルを実行し,トランザクションのうち 5% が エラーを返す,という場合を考えます。このような規模のデータに対しては大 規模のデータベースを使用することになります。 次の表に,生成されるデータ量に基づいて各データベース要素に必要となる データベース・サイズを示します。 データベース要素 挿入量 (毎時行数) 小規模 大規模 6 KB 以下 500 KB 以上 備考 20 未満 名前付きユーザ (プロファイル・ ユーザ・スキーマ) 80 以上 メモリ設定に使用 30 未満 50 以上 プロセス設定に使用 約 30 GB 約 600 GB 以上 名前付きユーザ (管理ユーザ・ス キーマ) データベース・サ イズ 126 Mercury Business Availability Center の 導入 第 13 章 • Oracle サーバのサイズ設定ガイドライン ハードウェアのサイズ設定 次の表に,Mercury Business Availability Center の Oracle データベース・サーバで 推奨されるハードウェア(CPU とメモリ)の要件を示します。 Mercury Business Availability Center の導入 プロセッサ 数 物理メモリ 推奨される最小の Oracle バージョン 小規模 1 1 GB 9.2.0.6 大規模 8 8 GB 以上 9.2.0.6 127 127 第 3 部 • Oracle サーバ・データベースの導入と保守 Oracle パラメータのサイズ設定 次の表に,Mercury Business Availability Center のデータベース・サーバで作業を 行う際に,いくつかのパラメータに対して推奨されるサイズを示します。 Mercury Business Availability Center の導入 パラメータ名 128 備考 小規模 大規模 DB_BLOCK_SIZE 8192 16,384 表の後の備考を参照。 DB_BLOCK_BUFFERS または DB_CACHE_SIZE 85,000 または 696,320,000 244,000 または 4 GB 表の後の備考を参照。 DB_CACHE_SIZE パ ラメータの使用をお 勧めします。Oracle 10g には SGA_TARGET パラ メータの使用をお勧 めします。 DB_CACHE_ADVICE ON ON チューニングが必要 な際に統計情報を収 集するために使用し ます。 SHARED_POOL_SIZE Oracle 9i : 80 MB Oracle 9i : 112 MB Oracle 10g : 200 MB Oracle 10g : 252 MB Oracle 10g には SGA_TARGET パラ メータの使用をお勧 めします。 SGA_TARGET 890 MB 4.25 GB Oracle 10g でのみ有効 LOG_BUFFER 512,000 バイト 2,000,000 バイト DB_FILE_MULTIBLOC K_READ_COUNT 16 32 PROCESSES 200 400 安全のためさらに 100 を加算してくだ さい。 SESSIONS 225 445 (1.1 * PROCESSES) + 5 第 13 章 • Oracle サーバのサイズ設定ガイドライン パラメータ名 SORT_AREA_SIZE Mercury Business Availability Center の導入 小規模 大規模 1 MB 2 MB 備考 代わりに PGA_AGGREGATE_T ARGET パラメータの 使用をお勧めします。 このパラメータは下 位互換性と共有サー バ・モード用に確保 されています。正常 な動作のためには, WORKAREA_SIZE_P OLICY パラメータを MANUAL に設定する 必要があります。 SORT_AREA_RETAINE D_SIZE SORT_AREA_SI ZE の値と同じ SORT_AREA_S IZE の値と同じ SORT_AREA_SIZE パラメータの備考を 参照。 HASH_AREA_SIZE 3 MB 6 MB SORT_AREA_SIZE 値の 3 倍。 SORT_AREA_SIZE パラメータの備考を 参照。 129 129 第 3 部 • Oracle サーバ・データベースの導入と保守 パラメータ名 Mercury Business Availability Center の導入 小規模 大規模 WORKAREA_SIZE_POL ICY AUTO AUTO PGA_AGGREGATE_TA RGET 400 MB 800 MB STATISTICS_LEVEL TYPICAL TYPICAL 備考 PGA メモリの自動 管理モードは,専用 の Oracle サーバに よって割り当てられ た作業領域にのみ適 用されます。共有の Oracle サーバによっ て割り当てられる作 業領域のサイズは, 引き続き以前の *_AREA_SIZE パラ メータによって制御 されます。これは, これらの作業領域が PGA 内ではなく主 に SGA 内で割り当 てられるためです。 必要な場合に チューニングを有効 にします。 次の点に注意してください。 ➤ DB_BLOCK_SIZE : 管理用データベースとプロファイル・データベースで別々 のデータベース・サーバを使用する予定で,管理用ユーザ・スキーマに適用す るデータベース・ブロック・サイズを小さくする場合は,データベース・ブ ロック・サイズが 4 KB を下回らないようにします。 また,DB_BLOCK_SIZE はオペレーティング・システムのブロック・サイズの 倍数にする必要があります。 130 第 13 章 • Oracle サーバのサイズ設定ガイドライン ➤ DB_BLOCK_BUFFERS または DB_CACHE_SIZE : 上記の推奨設定は非常に大 規模な実装を対象とするものです。Mercury Business Availability Center の認定に 関係なく,このパラメータを設定するためには次のハードウェア条件をさらに 満たす必要があります。 ➤ Solaris ハードウェア : 32 ビット・オペレーティング・システムでは,すべ てのインスタンスについて共有メモリの上限が 1.75 GB となっています。4 GB の共有メモリを使用する場合は,64 ビットのオペレーティング・システ ムと 64 ビット対応の Oracle RDBMS を使用する必要があります。 ➤ Windows 2000 : 2 GB を超える SGA をサポートし使用するためには, Windows および Oracle の特定の構成(VLM)を有効にする必要があります。 詳細については,Microsoft および Oracle のオンライン・マニュアルを参照 してください。 ➤ SGA_TARGET : このパラメータを設定すると,Oracle に自動的に,バッファ・ キャッシュ(db_cache_size),共有プール(shared_pool_size),ラージ・プール (large_pool_size) ,java プール(java_pool_size),および Streams プール (streams_pool_size)のサイズを取得するように設定します。 SGA_TARGET に設定した値によって,SGA コンポーネント全体のサイズが決 まります。 SGA_TARGET に 0 以外の値が設定され,前述のプールのいずれかもまた 0 以 外の値が設定されている場合,プールの値がそのプールの最小値として使われ ます。 131 131 第 3 部 • Oracle サーバ・データベースの導入と保守 Oracle ファイルのサイズ設定 本項では,表領域,一時表領域,データ表領域,REDO ログ,およびロール バックについて,サイズ設定のガイドラインを示します。 表領域の設定 次の表に,表領域の推奨サイズを示します。 表領域 Mercury Business Availability Center の導入 備考 小規模 大規模 管理用 500 MB 1 GB サイズは必要最小限 のサイズです。 プロファイル用 30 GB 600 GB サイズは必要最小限 のサイズです。 プロファイル・デー タベースを複数作成 する場合は,個々の プロファイル・デー タベースを別々の表 領域に作成すること をお勧めします。 注:このほか,一時表領域とロールバック表領域のサイズも設定できます。詳 細については,133 ページ「一時表領域の設定」および 135 ページ「UNDO セ グメントの設定」を参照してください。 132 第 13 章 • Oracle サーバのサイズ設定ガイドライン 一時表領域の設定 次の表に,一時表領域の推奨サイズを示します。 表領域 Mercury Business Availability Center の導入 備考 小規模 大規模 TEMP 1 GB 5 GB 大きな表領域では複数のファ イルを使用してください。 TEMP 格納域 の設定 固定の割り当 て : 2 MB 固定の割り当 て : 2 MB ➤ できるだけローカルに管理 されるようにします(固定 割り当て,セグメント領域 の自動管理)。 ➤ 表領域のタイプは一時にし ます(TEMPFILE を使用)。 注:WORKAREA_SIZE_POLICY パラメータを MANUAL に設定する場合,一 時表領域の初期エクステントと増分エクステントの格納領域は, SORT_AREA_SIZE パラメータの倍数(1 より大きい値)にしてください。 133 133 第 3 部 • Oracle サーバ・データベースの導入と保守 データ表領域の標準の格納域設定 次の表に,データ表領域の標準設定の格納域に対する推奨サイズを示します。 Mercury Business Availability Center の導入 表領域 小規模 管理用 備考 大規模 ➤ ローカルに管理される表領域 ➤ セグメント領域の自動管理 ➤ ローカル・エクステントの自動 管理 プロファイ ル用 ➤ ローカルに管理される表領域 ➤ セグメント領域の自動管理 ➤ ローカル・エクステントの自動 管理 注:プロファイル・データベースには 530 の表と 2400 のインデックスが格納さ れます。大規模な実装の Mercury Business Availability Center 用にプロファイル・ データベースの表領域を作成する場合は,ローカル・エクステントの管理を固 定ではなく自動にすることを強くお勧めします。 REDO ログの設定 次の表に,REDO ログ・ファイルの推奨サイズを示します。 Mercury Business Availability Center の導入 設定 134 小規模 大規模 REDO ログ・ファイルのサイズ 70 MB 200 MB 最小グループ数 4 4 グループ当たりの最小メンバ数 2 2 第 13 章 • Oracle サーバのサイズ設定ガイドライン UNDO セグメントの設定 次の表に,ロールバック・セグメントの推奨サイズを示します。 設定 Mercury Business Availability Center システム・プロファイル 小規模 大規模 UNDO 表領域のサ イズ 500 MB 2 GB UNDO_MANAGE MENT パラメータ AUTO UNDO_RETENTIO N パラメータ Oracle の標準設定値 備考 セグメント数,最小エクステ ント数,およびロールバック・ セグメントのサイズ(初期, 増分)は,すべて Oracle によっ て自動的に設定されます。 Oracle の標準設定値 135 135 第 3 部 • Oracle サーバ・データベースの導入と保守 136 第 14 章 Oracle サマリ・チェックリスト 本章では,Mercury Business Availability Center のサポートと認定に必要となる要 件についてまとめたチェックリストを示します。 本章の内容 ページ Mercury Business Availability Center のサポートと認定向けチェックリスト 138 Oracle サーバの要件 144 Oracle Client の要件 145 注:Oracle サーバと Mercury Business Availability Center を組み合わせて使用する 場合に必要となる Oracle データベースの設定の詳細については,125 ページ 「Oracle サーバのサイズ設定ガイドライン」を参照してください。 137 第 3 部 • Oracle サーバ・データベースの導入と保守 Mercury Business Availability Center のサポートと認定向け チェックリスト 次の表に,Mercury Business Availability Center で作業を行う場合にサポートおよ び認定されている Oracle データベースのオプションをまとめて示します。 オプション サポート 推奨 Oracle のエディ ション Server および Enterprise Enterprise 不要 専用の Mercury Business Availability Center サーバ 必要 複数の Oracle イン ○ スタンスの使用 × 非標準ポートの 使用 ○ ○ 自動, 自動 UNDO 管理 手動 手動 UNDO 管理 + パブリック・ ロールバック・ セグメント 138 ○ × 備考 詳細情報の参 照先 91 ページ 「Oracle サーバ のエディショ ンの選択」 すべてのイン 91 ページ スタンスの構 「Oracle インス 成を,認定環 タンス」 境と同じにす る必要があり ます。 認定環境では UNDO_MANA GEMENT パラ メータを AUTO に設定 します。 第 14 章 • Oracle サマリ・チェックリスト オプション Oracle マルチス レッド・サーバ (MTS) サポート 推奨 備考 ○ × Mercury Business Availability Center では接 続プール・ アーキテク チャを使用し ます。 Oracle レプリケー 完全にはサポー ション トされない 詳細情報の参 照先 × Mercury SYSTEM,RBS, Mercury Business UNDO,TEMP の Availability Center Business 各表領域の使用 スキーマでは不可 Availability Center スキーマ では不可 Windows および × UNIX のファイル 圧縮 必須のデータ ベース制御ファ イル 2 以上 × Oracle ではサ ポートされて いません。動 作異常の原因 となり,パ フォーマンス に影響します。 3 異なるディス クへの配置が 理想的です。 139 139 第 3 部 • Oracle サーバ・データベースの導入と保守 140 オプション サポート 推奨 備考 REDO ログ・グ ループ 3 以上 4 Oracle では REDO ログ・ ファイルのソ フトウェア・ ミラーリング が可能です。 ソフトウェア・ ミラーリング は,グループ ごとに REDO ログのメンバ を少なくとも 2 つ作成するこ とによって実 現します。同 じグループの メンバを別々 のディスクに 配置します。 文字セット WE8ISO8859P1, UTF8 UTF8 OPTIMIZER_IND 100 EX_COST_ADJ パ ラメータの値 100 パフォーマンス に影響します。 HASH_JOIN_ENA True,False BLED パラメータ の値 True Oracle 10g で は削除されま した。 TIMED_STATISTI True,False CS パラメータの 値 True DB_CACHE_ADV Off,On ICE パラメータの 値 On 詳細情報の参 照先 128 ページ 「Oracle パラ メータのサイ ズ設定」 第 14 章 • Oracle サマリ・チェックリスト オプション サポート 推奨 STATISTICS_LEV Typical EL パラメータの 値 Typical LOG_CHECKPOI 0 以上 NT_INTERVAL パ ラメータの値 0 LOG_CHECKPOI 0 以上 NT_TIMEOUT パ ラメータの値 0,または 1800 以下 OPTIMIZER_MO Oracle 9i : DE パラメータの Choose 値 Oracle 10g : ALL_ROWS Oracle 9i : Choose PARTITION_VIE True,False W_ ENABLED パ ラメータの値 True CURSOR_SPACE True,False _FOR_TIME パラ メータの値 False CURSOR_SHARI Exact NG パラメータの 値 Exact 備考 詳細情報の参 照先 128 ページ 「Oracle パラ メータのサイ ズ設定」 Oracle 10g : ALL_ROWS Mercury Business Availability Center パー ジ・マネー ジャ使用時の パフォーマン スが向上しま す。Oracle 10g では削除され ました。 LOG_BUFFER パ 512,000 バイト超 512,000 バイト超 ラメータの値 141 141 第 3 部 • Oracle サーバ・データベースの導入と保守 オプション 推奨 USE_STORED_O × UTLINES パラ メータの値 × OPEN_CURSORS 800 パラメータの値 800 COMPATIBLE パ 9.2.06 ラメータの値 10.2.0.1 SQL_TRACE パラ True,False メータの値 False True,False True LOG_ARCHIVE_ True,False START パラメー タの値 True BLANK_TRIMMI False NG パラメータの 値 False FIXED_DATE パ ラメータの値 未設定 未設定 SPIN_COUNT パ ラメータの値 ○ × アーカイブ・ロ グ・モードでの 作業 142 サポート 備考 アーカイブ・ ログ・モード を「True」に 設定して作業 するときのみ Mercury Business Availability Center では, アプリケー ション・プロ セスの一部と してシステム 時間を生成す る場合に, SYSDATE 機能 を使用します。 詳細情報の参 照先 第 14 章 • Oracle サマリ・チェックリスト オプション サポート 推奨 備考 詳細情報の参 照先 UNDO_MANAGE Manual,Auto MENT パラメー タの値 Auto UNDO_RETENTI Oracle の標準設 ON パラメータの 定値 値 Oracle の標準設 Oracle 10g では 135 ページ 定値 自動チューニ 「UNDO セグメ ングが実行さ ントの設定」 れます。 WORKAREA_SIZ Manual,Auto E_POLICY パラ メータの値 Auto 128 ページ 「Oracle パラメー タのサイズ設 定」を参照して ください。ま た,SORT_ AREA_SIZE パラ メータも参照し てください。 ○ × 97 ページ「管 理用ユーザ・ スキーマ」 ローカル管理され ○ るデータ表領域 ○ 94 ページ 「ローカル管理 される表領域」 表領域ファイル での自動拡張オ プション 表領域のエクス テントの管理 ディクショナリ, 管理スキーマお ローカル,ロー よびプロファイ カル固定 ル・スキーマで はローカル自 動,TEMP 表領 域ではローカル 固定 RECYCLEBIN Off 132 ページ 「Oracle ファイル のサイズ設定」 Off 143 143 第 3 部 • Oracle サーバ・データベースの導入と保守 オプション サポート 推奨 セグメント領域の ○ 自動管理表領域 MDAC のバー ジョン 備考 詳細情報の参 照先 ○ 2.5,2.52,2.61, 2.7 SP1 更新 2.62,2.7 SP1 更新 インストール 105 ページ 「Oracle Client されている Oracle Client に 向けの MDAC」 従って,3 つの レジストリを 設定します。 Oracle サーバの要件 次の表に,Mercury Business Availability Center で作業を行うためにサポートおよ び認定されている Oracle サーバのバージョンとオペレーティング・システム・ プラットフォームを示します。 サポート コンポーネ ント 144 推奨 バージョン / エディション サービス・ パック バージョン / エディション サービス・ パック Windows オ ペレーティ ング・シス テム Windows 2000 Server/Advanced Server Service Pack 4 Windows 2003 Server Standard / Enterprise Service Pack 1 Sun Solaris オペレー ティング・ システム Solaris 9 Solaris 8,10 Oracle Oracle 9.2.0.6 Oracle 10.2.0.1 第 14 章 • Oracle サマリ・チェックリスト 注: ➤ Solaris 環境は 64 ビットのみです。 ➤ Oracle 9i の Oracle 環境はすべてのプラットフォームで 32 ビットです。 Oracle 10g については,Windows で 32 ビット,UNIX で 64 ビットです。 Oracle Client の要件 次の表に,Mercury Business Availability Center で作業を行うためにサポートおよ び認定されている Oracle Client のバージョンとオペレーティング・システム・ プラットフォームを示します。 サポート コンポーネ ント 推奨 バージョン / エディション サービス・ パック バージョン / エディション サービス・ パック Windows オ ペレーティ ング・シス テム Windows 2000 Server/Advanced Server Service Pack 4 Windows 2003 Server Standard / Enterprise Service Pack 1 Sun Solaris オペレー ティング・ システム Solaris 9 Solaris 8,10 Oracle Oracle 9.2.0.6 Oracle 10.2.0.1 145 145 第 3 部 • Oracle サーバ・データベースの導入と保守 146 第4部 付録 付録 A データベースの集約と分散 本付録では,すべての Mercury Business Availability Center データを単一のデー タベースに集約すべき状況と,反対に,データを複数の異なるデータベースに 分散すべき状況について,それぞれ説明します。 本章の内容 ページ データベースの集約のメリット 150 データベース分散の理由 150 149 第 4 部 • 付録 データベースの集約のメリット 一般に,すべてのデータを単一のデータベースに集約することをお勧めしま す。データを集約すべき理由はいくつかあります。 ➤ 扱いやすさ : 集約されたデータベースでは,管理,保守,および監視を 1 か所 で行えるため,管理作業の負担が軽減します。複数のデータベースを使う場合 は,保守作業と監視手続きをすべて繰り返す必要があります。 ➤ 領域管理のしやすさ : 単一のデータベースを使用すれば,データが 1 台のディ スクまたは 1 つのディスク・アレイに格納されるため,データベースの拡大や ディスク領域の問題が追跡しやすくなります。複数のデータベースを複数の ディスクやディスク・アレイで使用すると,データベースごとに拡大を追跡す る必要が生じるので,領域管理が複雑になります。 ➤ レポートの制限 : パーセント表示および標準偏差のレポートは,単一のデータ ベースの場合にのみサポートされます。 データベース分散の理由 次のような場合には,データを複数のデータベースに分散することを検討して ください。 ➤ 表のサイズ : 一般に,小さな表に対する処理のパフォーマンス(特に挿入速度) のほうが,大きな表に対する処理のパフォーマンスよりもよくなります。表の サイズは 100 万行を超えないようにすることをお勧めします。表のサイズを比 較的小さく抑えるには,パーティショニング機能を利用し,複数のデータベー スにデータを分散しないようにします。パーティショニングのサイクルを詳細 に調整することで,最適な表のサイズを実現できます。しかし,データベース が非常に大きい場合(80 GB 超)は,表のサイズを 100 万行を超えないように 抑えようとすると,パーティショニングのサイクルが 1 日よりも短くなりま す。この場合,1 か月分のデータで 30 を超えるパーティションが必要になりま す。このような状況になることは避け,パーティションのサイクルが 1 日を下 回らず,かつ表のサイズが 100 万行を超えないように,データを複数のデータ ベースに分散することを検討してください。 ➤ 保守の粒度 : プロファイルごとに異なる保守要件がある場合(データのパージ やバックアップの頻度など)は,プロファイルのグループごとに異なるデータ ベースを使用することもできます。 150 付録 A • データベースの集約と分散 また,ダウンタイムを必要とする保守活動(インデックスの再構築など)のス ケジュールを設定する必要があり,1 つの保守作業に対して十分な時間枠が確 保できない場合は,割り当てられた時間枠の中で 1 つの保守作業が完了するよ うに,データを複数のデータベースに分散することができます。同様に,リカ バリの単位は単一のデータベースです。システム障害の際に速やかに回復する 必要のあるプロファイルが複数ある場合は,それらのファイルを独立のデータ ベースに置くという方法も考えられます。 ➤ 物理リソース : 個々のプロファイルに異なる物理リソースを提供したい場合 (たとえば,活動量の非常に多いプロファイルに高速で高価なディスクを割り 当て,活動量の少ないプロファイルに低速で安価なディスクを割り当てたい場 合など)は,プロファイルを個別のデータベースに分散することによってそれ を実現できます。 151 151 第 4 部 • 付録 152 付録 B データ格納域の推奨事項 本付録では,Mercury Business Availability Center のデータを格納する MS SQL Server ファイル・グループおよび Oracle 表領域を作成する際の推奨事項につい て説明します。本付録の情報は上級ユーザのみを対象としています。 本章の内容 ページ MS SQL Server ファイル・グループの作成 154 Oracle サーバ表領域の作成 158 153 第 4 部 • 付録 MS SQL Server ファイル・グループの作成 標準設定では,管理データベース・オブジェクトとプロファイル・データベー ス・オブジェクトはそれぞれ 2 つのファイル・グループに格納されます(標準 設定では,システム・テーブル用は PRIMARY ファイル・グループ,ユーザ・ テーブル用は userdata001 です) 。したがって,管理データベースとプロファイ ル・データベースを自動的に生成すると,管理データベース用に 2 つのファイ ル・グループ(PRIMARY と userdata001)が作成され,プロファイル・データ ベース用に 2 つのファイル・グループ(PRIMARY と userdata001)が作成され ます。Mercury Business Availability Center の導入が大規模になる場合は,管理 データベース・オブジェクトとプロファイル・データベース・オブジェクトを 格納する追加のファイル・グループを作成することをお勧めします。 複数のファイル・グループがもたらすメリット システム・カタログを専用のファイル・グループに入れ,データ格納のための ユーザ定義のファイル・グループを複数作成することには,次のメリットがあ ります。 ➤ 保守 : データベースのバックアップと復元をファイル・グループ・レベルで実 行できます。 ➤ 部分復元 : データベースの部分的な復元をファイル・グループ・レベルで実行 できます。ただし,部分復元を行う際はシステム・カタログが格納されている PRIMARY ファイル・グループも復元する必要があります。PRIMARY ファイ ル・グループに .mdf ファイルだけを維持し,もう 1 つのユーザ・ファイル・ グループを標準ファイル・グループとして設定することで,PRIMARY ファイ ル・グループが小さく維持され,部分復元の際に問題とならなくなります。こ こで推奨しているファイル・グループ構造では 1 つのユーザ・ファイル・グ ループを作成していますが,これは将来データベース管理者または Mercury Business Availability Center が複数のファイル・グループを作成することになっ た場合の最初のグループになります。 ➤ 読み取り専用 : ファイル・グループは読み取り専用にすることができます。 データが変更できなくなるため,MS SQL Server で共有ロックを獲得する必要 がなく,パフォーマンスが向上します。 ➤ 復旧 : データベースのデータの一部がクラッシュしたとき,.mdf ファイルが損 傷した場合でも,ログ・ファイルと master データベースが損傷していない限 り,クラッシュ前に加えられた変更を保存できます。 154 付録 B • データ格納域の推奨事項 ➤ パフォーマンス : 高速ディスクでのホット・テーブルや,別々のファイル・グ ループへのテーブル・データとインデックスの分離など,数多くのチューニン グ・オプションが使用できます。 ➤ 柔軟性と管理能力 : 複数のファイル・グループを使用することで,さらなる柔 軟性と管理能力がデータベース管理者に提供されます。また,大規模なデータ ベースでは,Mercury Business Availability Center コンポーネントのタイムアウト 設定に達する前に標準の自動拡張量である 10 パーセントの拡張が完了できず, データベースの活動がロールバックされ,挿入が無限ループに陥る,という状 況が起こることがありますが,データベースの拡張サイズを固定にすること で,そうした状況を防ぐことができます。 次の各スクリプトを実行すれば,追加のファイル・グループを(追加の MS SQL Server データベースと一緒に)作成できます。 標準設定のデータベースを作成するには,次を実行します。 CREATE DATABASE [testdb] .mdf(カタログ)ファイルの SIZE パラメータを変更するには,次を実行します。 ALTER DATABASE [testdb] MODIFY FILE ( NAME = N'testdb', SIZE = 5MB ) .mdf(カタログ)ファイルの FILEGROWTH パラメータを変更するには,次 を実行します。 ALTER DATABASE [testdb] MODIFY FILE ( NAME = N'testdb', FILEGROWTH = 5MB ) .ldf(ログ)ファイルの SIZE パラメータを変更するには,次を実行します。 ALTER DATABASE [testdb] MODIFY FILE 155 155 第 4 部 • 付録 ( NAME = N'testdb_log', SIZE = 10MB ) .ldf(ログ)ファイルの FILEGROWTH パラメータを変更するには,次を実行 します。 ALTER DATABASE [testdb] MODIFY FILE ( NAME = N'testdb_log', FILEGROWTH = 50MB ) データベースの標準データ・ディレクトリのパスを取得するには,次を実行し ます。 SELECT LEFT(filename, LEN(filename) - CHARINDEX(N'\', REVERSE(filename))) AS path FROM master.dbo.sysdatabases WHERE name = N'testdb' 上記のスクリプトで返された 'testdb' 名を,次のスクリプトで使用します。 ユーザ・ファイル・グループを作成し,そこにデータ・ファイルを追加して, そのグループを標準ファイル・グループとして設定するには,次を実行します。 ALTER DATABASE [testdb] ADD FILEGROUP USERDATA001 ALTER DATABASE [testdb] ADD FILE ( NAME = N'testdb_Data001', FILENAME = N' <データ・ディレクトリへのパス> ', SIZE = 10MB, FILEGROWTH = 50MB ) TO FILEGROUP USERDATA001 156 付録 B • データ格納域の推奨事項 userdata001 ファイル・グループを標準ファイル・グループとして設定するに は,次を実行します。 ALTER DATABASE [testdb] MODIFY FILEGROUP USERDATA001 DEFAULT ファイル・グループを作成するときは次の点に注意してください。 ➤ 2 つの別々のデータ・ファイルを,2 つの別々のファイル・グループに作成 します。PRIMARY ファイル・グループに .mdf ファイルを作成し, userdata001 ファイル・グループに .ndf ファイルを作成します。 ➤ userdata001 グループを標準ファイル・グループとして設定します。 ➤ .mdf ファイルを,システム・カタログのある PRIMARY ファイル・グルー プにおけるただ 1 つのファイルにします。.mdf ファイルは,SIZE パラメー タの初期値を 5 MB,FILEGROWTH パラメータの初期値を 5 MB として作成 します。それ以外のデータ・ファイル(.ndf)およびログ・ファイル(.ldf) は,SIZE パラメータの初期値を 10 MB,FILEGROWTH パラメータの初期 値を 50 MB として作成します。いずれの場合も,FILEGROWTH パラメータ の値は比率ではなく固定サイズにします。 上記の設定規則は,ファイルの適切なリカバリ,フォールト・トレランス,パ フォーマンス,およびアーカイブにとって重要です。 157 157 第 4 部 • 付録 Oracle サーバ表領域の作成 標準設定では,Oracle ユーザ・スキーマにはそれぞれ専用に定義された表領域 が 1 つずつ存在します。Mercury Business Availability Center で作成されるすべて の Oracle データベース・オブジェクト(表やインデックスなど)は,この表領 域の中に自動的に格納されます。ただし,すべてのデータベース・オブジェク トを 1 つの表領域に格納しないことをお勧めします。実際には,次の 5 つの表 領域を追加で作成することをお勧めします。 オブジェクトのタイプ 実装サイズ 表 インデックス LOB 小規模 (1) (2) (5) 大規模 (3) (4) (5) 各表領域について推奨される格納パラメータは次のとおりです。 158 表領域の数 表領域のタイプ サイズ freelist の 数 (1) ローカルに管理される表領域, エクステントの自動割り当て 100 ~ 500 MB 20 (2) ローカルに管理される表領域, エクステントの自動割り当て 100 ~ 500 MB 20 (3) ローカルに管理される表領域, エクステントの自動割り当て 15 ~ 300 GB 10 (4) ローカルに管理される表領域, エクステントの自動割り当て 15 ~ 300 GB 10 (5) ローカルに管理される表領域, エクステントの自動割り当て 5 ~ 100 GB 1 付録 B • データ格納域の推奨事項 次の表に,Mercury Business Availability Center の各表で使用すべき表領域のタイ プを示します。 表領域の数 表 (5) 管理用の表 : CUSTOM_REPORTS プロファイル用の表 : SLA_REPORT_INSTANCES (3)および(4) 管理用の表 : なし プロファイル用の表 : EVENT_METER (1)および(2) 上記のすべての表(および該当する場合はそのインデックス) Mercury Business Availability Center データの転送 前記の 5 つの表領域を作成すると,標準設定の表領域から,作成したほかの表 領域にデータを転送できます。 作成した新しい表領域にデータを転送するには,次の手順を実行します。 1 管理データベースとプロファイル・データベースをまだ作成していなければ, それらを表領域 (1)に作成します。 2 ALTER TABLE <表名> MOVE TABLESPACE <表領域名> DDL コマンドを使 用して,すべての表を表領域(1)から表領域(3)および(5)に移動します。 このコマンドがサポートされていない古いバージョンの Oracle を使用している 場合は,表領域(1)の表を表領域(3)および(5)に作成し直すことができ ます。 3 すべてのインデックスを表領域(1)から表領域(4)および(5)に移動しま す。ある表領域から別の表領域にインデックスを移動するには,インデックス をいったん削除し,storage 句を使用して目的の表領域で作成します。 159 159 第 4 部 • 付録 注: ➤[プラットフォームの管理]の[セットアップと保守]タブにある[データ ベース管理]ページからプロファイル・ユーザ・スキーマを作成すると, データベース・オブジェクトが Oracle ユーザの標準設定の表領域に作成さ れます。データベース管理者は,Mercury Business Availability Center がプロ ファイル・ユーザ・スキーマを作成する際に使用するスクリプトを確認し, アプリケーションのニーズに合うように編集することをお勧めします。そし て,それらのスクリプトを使用して新しいプロファイル・ユーザ・スキーマ を手動で作成してください。 ➤ ユーザ・スキーマをアップグレードすると,アップグレード後に作成された すべてのオブジェクトが Oracle ユーザの標準設定の表領域に作成されます。 データベース管理者は,後で必要に応じてこれらのオブジェクトを他の表領 域に移動することができます。 160 付録 C データのパーティショニングとパージ 本付録では,プロファイル・データベース表のパーティショニングとパージの ポリシーを更新する方法について説明します。 本章の内容 ページ データのパーティショニングとパージ 162 パージ・マネージャの仕組み 162 パージ・マネージャのパラメータ値の計算 163 パージ・マネージャ・パラメータの設定 165 パージ・マネージャを使用する際の Oracle 表領域の作成 168 161 第 4 部 • 付録 データのパーティショニングとパージ 大量のデータが絶えず流れ込むアプリケーションを管理するうえで重要な要素 の 1 つとなるのが,古くなったデータのパージ(削除)です。Mercury Business Availability Center では,パーティショニングと呼ぶ方法を使用して古くなった データを削除します。Mercury Business Availability Center のパージ・マネージャ は,短期間で拡大する表を,指定した時間間隔で複数のパーティションに分割 します。指定した時間が経過すると,パーティション内のデータは,Mercury Business Availability Center レポートで使用するためのアクセスができないよう になります。さらに別に指定した時間が経過すると,パーティションがプロ ファイル・データベースからパージされます。 特定のプロファイル・データベース,またはすべての Mercury Business Availability Center プロファイル・データベースについて,パーティショニング とパージのポリシーを設定できます。 特定のプロファイル・データベース内のテーブルに対するパーティショニング とパージのポリシーを設定した場合,全プロファイル・データベースに対して 加えたポリシー変更は,この特定のデータベースには適用されません。 注:パージ・マネージャを実行するには,パージ・マネージャを有効にする必 要があります。詳細については,『プラットフォームの管理』の「パージ・マ ネージャの有効化および無効化」を参照してください。 パージ・マネージャの仕組み パージ・マネージャは 3 つのパラメータのセットを使用して,テーブルごと に,新しいパーティションを作成する条件,パーティションを使用不可にする 条件,およびパーティションを削除する条件を指定します。 使用するパラメータ・セットは次のとおりです。 162 付録 C • データのパーティショニングとパージ ➤ SLICE と SLICE_UNITS : データが新しいパーティションに分割される回数を 定義するのに使用します。データはパーティションごとに処理されるため, パーティション作成の頻度により,データ削除の頻度が決まります。たとえ ば,スライスを 1 週間と定義した場合,新しいパーティションは週に 1 回作成 されます。たとえば,範囲を 4 か月,保存期間を 6 か月と定義した場合,週に 1 回,4 か月より古いデータが使用不可能になり,6 か月より古いデータがパー ジされます。 ➤ RANGE と RANGE_UNITS : データが使用可能で Mercury Business Availability Center レポートに利用できる期間を定義します。たとえば,範囲を 6 か月と定 義した場合は,データを 6 か月間 Mercury Business Availability Center レポート に使用できます。6 か月後,このデータを含むパーティションは,データベー ス内の履歴ビューに移動します。 ➤ LIFETIME と LIFETIME_UNITS : データベース内のデータが削除されるまで の保持期間を定義します。指定範囲は過ぎていても,指定保持期間を過ぎてい ないデータは,データベース内の履歴ビューに保持されますが,Mercury Business Availability Center レポートに使用することはできません。たとえば, 保存期間を 1 年,範囲を 6 か月と定めた場合,データは 1 年間データベース内 に保持されますが,データを Mercury Business Availability Center レポートに使 用できるのは 6 か月間だけです。1 年を過ぎると,データはデータベースから パージされます。 注:Mercury Business Availability Center レポートには表示されなくなったが, データベース内には残っているデータを表示するには,データベースを開いて <テーブル名> _HIST ビューにアクセスします。 パージ・マネージャのパラメータ値の計算 パージ・マネージャは,テーブルの RANGE パラメータと EPM_VALUE パラ メータの値,および Mercury Business Availability Center によって設定された標 準設定のパーティション・サイズを基にして,テーブルの SLICE パラメータお よび LIFETIME パラメータの値を計算します。 EPM_Value パラメータでは,テーブルに入力されることが予想される,1 分あ たりのイベント数を定義します。 163 163 第 4 部 • 付録 RANGE パラメータまたは EPM_VALUE パラメータのどちらかの値が変更され ると,それに応じて SLICE パラメータおよび LIFETIME パラメータの値が再計 算されます。パラメータ値の変更の詳細については,165 ページ「パージ・マ ネージャ・パラメータの設定」を参照してください。 SLICE および LIFETIME の値は,次のアルゴリズム方式を使用して計算されま す。 ➤ SLICE(時間単位)= 標準設定のパーティション・サイズ / (EPM_VALUE * 60) ➤ SLICE の有効な最小値は 2 時間です(つまり,SLICE = 2,SLICE_UNITS = Hours) 。 ➤ SLICE と RANGE パラメータの値が等しい場合,LIFETIME パラメータにも同 じ値が設定されます。等しくない場合,LIFETIME の値は RANGE の値に基づ いて,アルゴリズムに従って計算されます。 注:テーブルの EPM_VALUE パラメータに NULL 値が含まれている場合,パー ジ・マネージャは従来の計算方法を使用して(旧バージョンの Mercury Business Availability Center を使用) ,テーブルの SLICE,SLICE_UNITS, LIFETIME,および LIFETIME_UNITS パラメータの値を計算します。従来の計 算では,アルゴリズム内で EPM_VALUE パラメータを使用しません。 パージ・マネージャでは,<コア・サーバ> \conf ディレクトリにある pmmanager.properties ファイルに CALC フラグを設定して,特定の計算機能 を使用するよう指示できます。CALC フラグに設定できる有効なオプションは 次のとおりです。 ➤ 0 : 従来の計算機能のみを使用 ➤ 1 : 新しい計算機能のみを使用 ➤ 2 : 標準設定。テーブルの EPM_VALUE パラメータに NULL 値が含まれている 場合は従来の計算機能を使用し,含まれていなければ新しい計算機能を使用。 164 付録 C • データのパーティショニングとパージ パージ・マネージャ・パラメータの設定 パージ・マネージャに標準設定の初期値が設定されたら, pmconfig.properties ファイルを編集して値をロードするか,テーブルの RANGE パラメータまたは EPM_VALUE パラメータのいずれかの値を変更して, 初期値を更新できます。 パージ・マネージャの標準設定値の設定 Mercury Business Availability Center では,パージ・マネージャによって管理され るテーブル用に,SLICE,RANGE,および LIFETIME というパラメータ・セッ トのほかに,EPM_VALUE パラメータに対しても標準設定値を設定します。 標準設定値は,<コア・サーバ> \conf ディレクトリにある pmconfig.properties ファイルに格納されています。パージ・マネージャは, 最初に起動されたとき,このファイルから管理データベースの PM_CONFIG テーブルに標準設定値をロードします。 pmconfig.properties ファイルの使用 <コア・サーバ> \conf ディレクトリに格納されている pmconfig.properties ファイルを使用し,テーブルの SLICE,SLICE_UNITS,LIFETIME, LIFETIME_UNITS の各パラメータ値を変更します。これらは,[プラット フォームの管理]の[パージ マネージャ]ページでは変更できません。テーブ ルの RANGE,RANGE_UNITS,および EPM_VALUE パラメータの値を,この ファイルで変更することもできます。 注:pmconfig.properties ファイルに対してテーブルの追加や削除は行わない でください。 pmconfig.properties ファイルを変更するには,次の手順を実行します。 1 <コア・サーバ> \conf\pmconfig.properties ファイルを開きます。 2 必要に応じて,SLICE,SLICE_UNITS,RANGE,RANGE_UNITS, LIFETIME,LIFETIME_UNITS,および EPM_VALUE パラメータを変更しま す。SLICE_UNITS,RANGE_UNITS,および LIFETIME_UNITS でサポートさ れている値は,hour(時),day(日),week(週),month(月),および year(年)です。ただし,最小の時間値は 2 です。 165 165 第 4 部 • 付録 注: ➤ データベース内に作成するパーティションの数は 52 個までにすることをお 勧めします(52 個を超えると,レポート生成のパフォーマンスに影響があ ります)。たとえば,スライスを 1 週間と定義した場合は,範囲として定義 する値を最大で 1 年までにするべきです(1 年は 52 週間のため)。 ➤ スライス期間を変更した場合は,次回のパーティションの作成時に変更が有 効になります。したがって,大きいスライス期間(年など)を指定しないよ うにしてください。 3 pmconfig.properties ファイルを保存します。 4 <コア・サーバ> \bin\pmconfig.bat ファイルをダブルクリックし,更新した 設定を管理データベースに入力します。コマンド・プロンプト・ウィンドウが 開き,データベース更新プログラムが実行されます。すべてのプロファイル・ データベースが更新されます。 特定のプロファイル・データベースのみを更新したい場合は,次のコマンドを 使用して,<コア・サーバ> \bin\pmconfig.bat ファイルを実行します。 pmconfig.bat -id <データベース ID > [ <設定ファイル> ] ここで,<データベース ID >は SESSIONS テーブルに列挙されているデータ ベース ID です(<設定ファイル>は省略可能です)。 5 更新の結果をチェックします。エラーがなければ,ENTER キーを押します。エ ラーが発生した場合は,問題を解決します。エラーの内容は<コア・サーバ> \log\pmanager.log ファイルで確認できます。すべてのエラーを解決したら, pmconfig.bat ファイルを再度実行します。 RANGE パラメータ値の変更 [プラットフォームの管理]の[セットアップと保守]タブにある[パージ マ ネージャ]ページにあるテーブルを使用して,データが各プロファイル・デー タベース・テーブルに保存され,Mercury Business Availability Center レポートで 表示できる時間を指定します(RANGE および RANGE_UNITS パラメータ値)。 [プラットフォームの管理]の[パージ マネージャ]ページを使用するとき, SLICE,SLICE_UNITS,LIFETIME,LIFETIME_UNITS の各パラメータの値は, 入力された新しい RANGE および RANGE_UNITS パラメータ値と,指定された 166 付録 C • データのパーティショニングとパージ ファイルの既存の EPM_VALUE パラメータ値とを使用して,自動的に再計算さ れます。 [プラットフォームの管理]の[パージ マネージャ]ページに関する手順の詳 細については,『プラットフォームの管理』の「プロファイル・データベース からの履歴データの削除」を参照してください。 EPM_VALUE パラメータ値の変更 ファイルの EPM_VALUE パラメータ値を変更するには,管理データベースの PM_CONFIG テーブルでこの値を直接変更します。 注:この変更はデータベース管理者が行ってください。 PM_CONFIG テーブルで EPM_VALUE パラメータの値を変更したら,[プラッ トフォームの管理]の[パージ マネージャ]ページに移動して該当のテーブル を選択し,[適用]をクリックします。これにより,入力した新しい EPM_VALUE パラメータ値と,テーブルの既存の RANGE および RANGE_UNITS パラメータ値を使用して,SLICE,SLICE_UNITS,LIFETIME, および LIFETIME_UNITS の各パラメータの値が再計算されます。 167 167 第 4 部 • 付録 パージ・マネージャを使用する際の Oracle 表領域の作成 パージ・マネージャは標準設定の Oracle 表領域内にパーティションを作成しま す。これらのパーティションでは,この表領域の格納パラメータが自動的に適 用されます。パージ・マネージャで,高速拡大する表で構成されるパーティ ションを,適切な格納パラメータが設定された表領域内に作成するようにした い場合は,低速拡大する表と高速拡大する表のために 2 つの表領域を作成する ことをお勧めします。これら 2 つの表領域の格納パラメータを,それぞれの表 のタイプごとに必要に応じて設定し,高速拡大する表のために作成した表領域 を標準設定の表領域として設定します。これによって,パージ・マネージャは 十分な格納領域を持つ表領域にパーティションを作成できるようになります。 注:既にパージ・マネージャを有効にしていて,Oracle データベースを使用し ている場合は,Oracle 初期化ファイル内の PARTITION_VIEW_ENABLED パラ メータを True に設定することを強くお勧めします。 168 付録 D データベース・スキーマの検証 本付録では,データベース・スキーマが正しく設定されていることを確認する ために管理スキーマおよびプロファイル・スキーマを検証する方法について説 明します。 本章の内容 ページ 検証処理について 170 検証処理の実行 171 検証処理のためのデータベース・ユーザの作成 176 169 第 4 部 • 付録 検証処理について 管理スキーマおよびプロファイル・スキーマを検証するには,データベース・ スキーマ検証プログラムを使用します。検証の処理中はシステムのダウンタイ ムは生じません。 データベース検証プログラムは,管理データベース・スキーマおよびプロファ イル・データベース・スキーマを確認して,指定したスキーマのバージョンの 正しいデータベース・スキーマに一致するようにします(使用されている標準 設定のスキーマ・バージョンは検証プログラムによって検出されます)。 管理データベース・スキーマおよびプロファイル・データベース・スキーマの検 証に加え,検証処理では,アップグレードできる新しいスキーマ・バージョンが あるかどうかも確認します。新しいバージョンのデータベース・スキーマが検出 された場合,以後のアップグレード操作に時間がかかり,アップグレード処理が 遅くなる可能性があります。そのため検証処理ではその旨を通知します。 検証プログラムの進行中,ユーザ名とパスワードの入力が求められます。これ は,一部のテスト(読み取りのみ)を実行するために必要です。DBA アカウン トのユーザ名とパスワードを使用したくない場合は,検証プログラムの操作に 必要な最低限の権限を持つユーザ名を作成して使用することができます。この ようなユーザの作成方法については,176 ページ「検証処理のためのデータ ベース・ユーザの作成」を参照してください。 注意事項と制限事項 データベース・スキーマ検証プログラムを実行する場合,次の注意事項と制限 事項があります。 ➤ Oracle 10g のスキーマでデータベース検証プログラムを実行中,Oracle datapump ユーティリティを使用して対象スキーマをインポートまたはエクス ポートする場合,対象スキーマに対してアクティブな datapump ジョブがないよ うにします。 対象スキーマに datapump 表がある場合,データベース・スキーマ検証プログラ ムの実行前に停止する必要があります。 Mercury Business Availability Center スキーマをログインに使用せず,管理者ス キーマに datapump 操作の実行を割り当てることをお勧めします。管理者スキー マに datapump 操作の実行を割り当てることによって,追加の権限を Mercury Business Availability Center スキーマに付与する必要がなくなり,datapump 表が 管理者スキーマ内に作成されます。 170 付録 D • データベース・スキーマの検証 ➤ 同じデータベース・サーバが 2 つの異なるホスト名(たとえば,dbserver およ び dbserver.merc-int.com など)を使用して管理データベースに列挙されている 場合は,ホスト名ごとに別々に接続するよう求められます。必ず,接続ごとに 同じ接続パラメータを入力します。 検証処理の実行 データベース・スキーマ検証プログラムは Mercury Business Availability Center サーバ・マシンから実行します。 データベース・スキーマを検証するには,次の手順を実行します。 1 < Mercury Business Availability Center サーバのルート・ディレクトリ> \dbverify\bin ディレクトリに移動し,run_db_verify.bat ファイルを実行します。 データベース検証プログラムが起動します。 2[TopazInfra.ini の選択]ダイアログ・ボックスで,< Mercury Business Availability Center サーバのルート・ディレクトリ> \conf\TopazInfra.ini を 参照します。 171 171 第 4 部 • 付録 注:すでに dbverify 処理を実行し,データベース設定が変更されていない場合, 標準設定の< Mercury Business Availability Center サーバのルート・ディレ クトリ> \dbverify\conf\TopazInfra.ini が表示され,選択できます。 3 対象データベースへの接続に必要な詳細を指定します。 ➤[SQL マスタ接続]ダイアログ・ボックスで,マスタ・データベースへの接 続に必要な詳細情報を指定します。 172 付録 D • データベース・スキーマの検証 [ユーザ]ボックスおよび[パスワード]ボックスに,データベースに対す る権限を持つユーザのユーザ名とパスワードを入力します([ユーザ]ボッ クスには,MS SQL サーバの標準の管理者ユーザ名 sa が表示されます。標 準設定ではパスワードはありません)。[OK]をクリックします。 ➤[Oracle ディクショナリ接続]ダイアログ・ボックスで,Oracle データベー スへの接続に必要な詳細情報を指定します。 [ユーザ]ボックスおよび[パスワード]ボックスに,データベースに対す る権限を持つユーザのユーザ名とパスワードを入力し,[了解]をクリック します。 注:管理データベースおよびプロファイル・データベースが存在するそれぞれ のサーバについて,接続データを入力するよう求められます。 注:データベース管理者アカウントのユーザ名とパスワードを使用したくない 場合は,検証プログラムの操作に必要な最低限の権限を持つユーザ名を作成し て使用することができます。このようなユーザの作成方法については, 176 ページ「検証処理のためのデータベース・ユーザの作成」を参照してくだ さい。 173 173 第 4 部 • 付録 4 データベース検証プログラムが,データベースの検証を開始します。検証の進 行状況は,[Upgrade database schema]ウィンドウで確認できます。 5 スキーマのバージョンが[BAC ユーザ スキーマのバージョン]ダイアログ・ ボックスに表示されることを確認します。 [了解]をクリックします。 174 付録 D • データベース・スキーマの検証 6 データベースの検証中に問題が発生した場合は,問題の内容を表示するダイア ログ・ボックスが表示されます。 問題を解決して[再試行]をクリックするか,または[終了]をクリックし て,後でデータベース・スキーマ検証プログラムを実行し直します。問題を解 決できない場合は,Mercury カスタマー・サポートにお問い合わせください。 < Mercury Business Availability Center サーバのルート・ディレクトリ> \dbverify\log ディレクトリに格納されているログ・ファイルでエラーを確認 することができます。 7 検証処理で,アップグレードできる新しいバージョンのデータベース・スキー マが検出された場合,アップグレードの操作には時間がかかるため,アップグ レード処理が遅くなり,その結果ダウンタイムが長くなる可能性があります。 そのためその旨を通知するダイアログ・ボックスが表示されます。 175 175 第 4 部 • 付録 [Yes]をクリックして処理を続行するか, [Details]をクリックして,検出さ れた時間のかかる操作がアップグレードに費やすと思われる予想時間を表示し ます。 8 データベースの検証が成功した場合は,次の確認メッセージが表示されます。 9[了解]をクリックします。 注:検証にかかわる問題のトラブルシューティングの詳細については,Mercury カスタマー・サポートのナレッジ・ベース (http://support.mercury.com/cgibin/portal/CSO/kbBrowse.jsp(US サイト))を参照してください。 検証処理のためのデータベース・ユーザの作成 データベース・スキーマ検証 / アップグレード・ユーティリティを実行すると きは,マスタ・データベースにアクセスできるユーザ名とパスワードの入力を 求められます。次のスクリプトの 1 つを実行することで,最低限の権限を持つ ユーザを作成できます。 MS SQL Server の場合 set nocount on use master GO sp_addlogin @loginame ='dbv_read',@passwd = ' <パスワード> ' GO sp_adduser @loginame = 'dbv_read', @name_in_db = 'dbv_read' go grant select on syslogins to dbv_read go set nocount off 176 付録 D • データベース・スキーマの検証 注:これらのスクリプトは sa ユーザとして実行する必要があります。 Oracle サーバの場合 CREATE USER dbv_read IDENTIFIED BY admin; GRANT SELECT_CATALOG_ROLE TO dbv_read; GRANT CONNECT TO dbv_read; 注:このスクリプトは SYSTEM ユーザとして実行する必要があります。 177 177 第 4 部 • 付録 178 付録 E ローダを使用したデータの管理 本付録では,Mercury Business Availability Center が,Mercury Business Availability Center データ・コレクタからコア・サーバ,さらにデータベースに至るデータ の流れを管理するためにローダを使用する方法について説明します。このロー ダ・システムによって,Mercury Business Availability Center で収集されたデータ がデータベースに報告されていることを検証できるようになります。Mercury カスタマー・サポートでも,ローダの情報を参考にして,データに関する問題 のトラブルシューティングを行います。 本章の内容 ページ ローダを使用したデータ管理の概要 180 ローダに関する問題のトラブルシューティング 181 ローダ・フォルダの場所 181 標準設定のログ・レベルの変更 183 障害を起こしたデータの保持期間の変更 183 DLQ クリーンアップ・ツール 185 179 第 4 部 • 付録 ローダを使用したデータ管理の概要 Mercury Business Availability Center のローダにより,Mercury Business Availability Center データ・コレクタからコア・サーバ,さらにデータベースに至るデータ を,効率的かつ継続的に報告できます。 データは HTTP 要求を介して,データ・コレクタ(ビジネス・プロセス・モニ タ,クライアント・モニタ,SiteScope など)からコア・サーバ上のローダの フォルダに流れます。ローダは,60 秒ごとに,ローダ永続化フォルダからデー タベースにデータを自動的に転送します。データベースが使用できない場合, ローダはデータをローダ永続化リカバリ・フォルダに転送します。データの損 傷などの理由でデータが正常にデータベースに転送されなかった場合,ローダ はデータを DLQ(「dead letter queue」)フォルダに転送します。データはこの フォルダで保存されます。ローダ・フォルダの場所については,181 ページ 「ローダ・フォルダの場所」を参照してください。 DLQ クリーンアップ・ツールを使用して,DLQ フォルダに保存されている データをデータベースに転送できます。詳細については,185 ページ「DLQ ク リーンアップ・ツール」を参照してください。 データ転送の問題を示すものとして,ローダ・フォルダのファイル数が継続的 に増える現象があります。この問題を確認する方法の詳細については,次項を 参照してください。 ローダのログには,ローダの問題に関する情報が格納されます。この情報は, データ転送の問題をデバッグする際に便利です。デバッグ時には,標準設定の ログ・レベルを変更する必要があります。詳細については,183 ページ「標準 設定のログ・レベルの変更」を参照してください。次の 3 つのログ・ファイル が使用されます。 ➤ collector_log : ローダが操作したすべての動作の詳細を格納する,ローダの主 要ログ・ファイルです。 ➤ dbloader_statistics : ローダのパフォーマンスに関する統計情報を格納します。 ➤ dbloader_samples : ローダを通過したすべてのデータ・サンプルのコピーを 格納します。 180 付録 E • ローダを使用したデータの管理 ローダに関する問題のトラブルシューティング データベースへのデータの転送に関する問題のトラブルシューティングを行う には,ローダのログ・ファイルを調べ,各ローダ・ディレクトリ内のファイル 数を調べます。 ➤ ログ・ファイルにエラー・メッセージがないか調べます。ログのレベルが flow (または info)に設定されている場合は,fatal(致命的),error(エラー),お よび warning(警告)のすべてのメッセージがログ・ファイルに表示されま す。Mercury カスタマー・サポートからの要請を受けた場合は,標準設定のロ グ・レベルを変更できます。詳細については,183 ページ「標準設定のログ・ レベルの変更」を参照してください。Mercury Business Availability Center のロ グ・レベルの定義については,『参照情報』の「ログの重大度レベル」を参照 してください。 ➤ ディレクトリのファイル数が増えていないか調べます。ファイル数の増加は問 題が継続していることを示します。Mercury カスタマー・サポートまでご連絡く ださい。ローダ・ディレクトリの詳細については,次項を参照してください。 ローダ・フォルダの場所 プロファイル・データベースはそれぞれ,ローダ・データを格納している専用 のディレクトリを持っています。それらのディレクトリは次のとおりです。 ローダ永続化ディレクトリ : データベースに転送されるデータが格納されてい ます。 ローダ永続化リカバリ・ディレクトリ : データベースが使用できなかったため にデータベースに転送されなかったデータが格納されています。ローダの問題 のトラブルシューティングに使用します。 DLQ ディレクトリ : データ転送に失敗したためにデータベースに転送されな かったデータが格納されています。 ローダは,ローダ永続化ディレクトリからデータベースに,データを自動的に 転送します。データベースが使用できない場合,ローダはデータをローダ永続 化リカバリ・ディレクトリに転送します。データの損傷などの理由でデータが 正常にデータベースに転送されなかった場合,ローダはデータを DLQ ディレ クトリに転送します。 181 181 第 4 部 • 付録 フォルダの場所の例 この例では次の名前が使用されます。 ➤ コア・サーバが coreserv というマシン上で実行されている。 ➤ データベース名が BAC_6 である。 データ・ファイルへのパスは次のようになります。 ローダ永続化ディレクトリ : .persist_dir\lnch_persistent\coreserv_project_topaz \guarantee\+coreserv_project_topaz_coreserv_topaz_collector\.msgs ローダ永続化回復ディレクトリ : .persist_dir\lnch_persistent\coreserv_project_topaz \guarantee\+coreserv_project_topaz_coreserv_BAC_6\.msgs DLQ ディレクトリ : .persist_dir\lnch_persistent\coreserv_project_topaz \guarantee\+coreserv_project_topaz_coreserv_dl_queue_host_BAC_6\.msgs ローダのログ・ファイルは次の場所にあります。 <コア・サーバのルート・ディレクトリ> \MercuryAM\log\collector_log.txt <コア・サーバのルート・ディレクトリ> \MercuryAM\log\\log \dbloader_statistics.txt <コア・サーバのルート・ディレクトリ> \MercuryAM\log \dbloader_samples.txt ローダの設定ファイルは次の場所にあります。 <コア・サーバのルート・ディレクトリ> \MercuryAM\conf\collector.ini 182 付録 E • ローダを使用したデータの管理 標準設定のログ・レベルの変更 ローダは自動的に作動するため,通常はローダ・ファイルに変更を加える必要 はありません。ただし,Mercury カスタマー・サポートからの要請を受けた場合 は,ログのレベルをレポート・レベルからデバッグ・レベルに変更できます。 ログのレベルを変更するには,次の手順を実行します 1 ファイル<コア・サーバのルート・ディレクトリ> \MercuryAM\conf \collector.ini にアクセスします。 2 ログ・レベルを変更するログ・ファイルのセクションで,次のエントリを探し ます。 ;; Verbosity level:error|warning|flow|debug1-debug5 LogLevel="flow" 注:標準設定では,LogLevel のパラメータは,collector_log ログと dbloader_statistics ログには flow が,dbloader_samples ログには error が設定され ます。 3 LogLevel のパラメータ設定(error または flow)をいずれかのデバッグ・レベ ルに変更します。デバッグ・レベルを上げるごとに詳細情報が追加され, debug5 では最も多くの情報が記録されます。 4 ファイルを保存します。 コア・サーバ・マシンが複数ある場合は,すべてのマシンでこの手順を繰り返 します。 障害を起こしたデータの保持期間の変更 主キー違反や制約チェック違反などのためにローダからデータベースにデータ を送信できなかった場合,ローダはそのデータを DLQ ディレクトリに書き込 みます(181 ページ「ローダ・フォルダの場所」を参照)。 Mercury Business Availability Center は次のパラメータを使用して DLQ ディレク トリ内にデータを保持する期間を決定します。 183 183 第 4 部 • 付録 ➤ DLQConnectionsMessageLifeTime : メッセージを DLQ ディレクトリに書き 込んでから保持する期間を設定します。このパラメータの標準設定値は 1440 時間(60 日)です。 ➤ DaysRange : Mercury Business Availability Center でメッセージが作成されてから プロファイル・データベースに挿入できるまでの期間を設定します。この期間 以上経過したメッセージは,DLQConnectionMessageLifeTime パラメータの設定 に従って削除されるまで DLQ ディレクトリ内に残ります。DaysRange パラメー タの標準設定値は 60 日です。 パラメータの設定を変更することもできますが,データが保持される期間を短 くすることはお勧めできません。必要であれば,この期間を長くすることがで きます。たとえば,Mercury カスタマー・サポートが問題を解決するまでデー タを保持しておきたい場合などが考えられます。 障害を起こしたデータを Mercury Business Availability Center に保持しておく期 間を変更するには,次の手順を実行します。 1 ファイル<コア・サーバのルート・ディレクトリ> \MercuryAM\conf \collector.ini にアクセスします。 2 変更するパラメータの次のエントリを探します。 ;; Defines the expiration time of samples in the DLQ. ;; If the sample life time is greater than this value (in hours) the bus will not pass the sample from dlq and will throw it. DLQConnectionsMessageLifeTime=1440 あるいは ;; highest accepted delay in days DaysRange="60" 3 期間を変更します。DLQConnectionsMessageLifeTime パラメータは時間単位で 設定され,DaysRange パラメータは日単位で設定されます。 注:両方のパラメータの値は,「DaysRange パラメータの日数 * 24 = DLQConnectionsMessageLifeTime パラメータの時間数」になるようにしてくだ さい。 184 付録 E • ローダを使用したデータの管理 4 ファイルを保存します。 コア・サーバ・マシンが複数ある場合は,すべてのマシンでこの手順を繰り返 します。 DLQ クリーンアップ・ツール DLQ クリーンアップ・ツールは,DLQ ディレクトリに格納されたデータを取 得してデータベースに転送します。 データ転送の問題が解決しない場合や,一部のデータがデータベースに到達し ない場合,データは DLQ ディレクトリに返されます。すべてのデータがデー タベースに到達するまで,必要なだけこのツールを実行できます。60 日以上 DLQ ディレクトリに残っているデータは削除されます。 DLQ クリーンアップ・ツールの実行 DLQ クリーンアップ・ツールは,Windows プラットフォームでは管理者,また は Unix プラットフォームではインストール時に定義された Mercury Business Availability Center のユーザとして,コマンド・ラインを使用して実行します。 DLQ クリーンアップ・ツールを実行するには,次の手順を実行します。 1 コア・サーバのコマンド・ウィンドウで,使用しているプラットフォームに対 応した,DLQ クリーンアップ・バッチファイルを起動します。 ➤ Windows プラットフォームの場合,次のコマンドを入力して,Enter キーを 押します。 < Mercury Business Availability Center のルート・ディレクトリ> \tools\DLQ_cleanup\dlq_cleanup.bat <マシン名> ➤ Unix プラットフォームの場合,次のコマンドを入力して,Enter キーを押 します。 < Mercury Business Availability Center のルート・ディレクトリ> /tools/DLQ_cleanup/dlq_cleanup.sh <マシン名> <マシン名>は,ローダがインストールされているコア・サーバの URL に表 示されるマシン名です。たとえば,名前が CoreServer1 で mydomain.com という ドメインの一部であるコア・サーバの場合,<マシン名>は,「CoreServer1」 または「CoreServer1.mydomain.com」となります。 185 185 第 4 部 • 付録 2 DLQ クリーンアップ・ツールが正常終了すると,「done」という確認メッセー ジが表示されます。 注:複数のコア・サーバがある分散システムでは,DLQ クリーンアップ・ツー ルの実行はシステム内のコア・サーバごとに行う必要があります。 186 付録 F モニタ管理の設定データのバックアップと復元 本付録では,モニタの管理の設定データのバックアップと復元の手順について 説明します。バックアップと復元専用のプロセスの確立は,高可用性環境にお ける基礎的な作業の 1 つです。 本章の内容 ページ 設定データのバックアップと復元の概要 188 基本バックアップと復元 189 レプリケーション・サーバへのバックアップと復元の基本 190 LDIF バックアップと復元 190 レプリケーション 192 OpenLDAP の起動と停止 196 バックアップと復元の例 197 注:LDAP サーバに対する自動レプリケーションおよびフェイルオーバ・プロ シージャのセットアップ方法の詳細については,Mercury カスタマー・サポー トのナレッジ・ベース にある 42154 番の記事を参照してください。 187 第 4 部 • 付録 設定データのバックアップと復元の概要 モニタ管理の設定データは,LDAP データベース(Lightweight Directory Access Protocol)に格納されます。標準設定では,このデータベースは,< Mercury Business Availability Center サーバのルート・ディレクトリ> \openldap\bdb\id*.* にあります。バックアップと復元のプロセスはすべてこ のディレクトリで行う必要があります。 本項では,バックアップと復元の方法および LDAP データベースの位置につい て説明します。 バックアップと復元の方法 モニタ管理のデータ・ファイルをバックアップおよび復元する方法を次の中か ら選択します。 ➤ 基本バックアップと復元 ➤ レプリケーション・サーバへのバックアップと復元の基本 ➤ LDIF バックアップと復元 LDAP データベースの位置 モニタ管理データの格納に使用する LDAP データベースの位置を確認するに は,以下の手順で行います。 1[管理]>[プラットフォーム]>[セットアップと保守]>[インフラスト ラクチャ設定]の順にアクセスします。 2[ファウンデーション]コンテキストを選択します。 3 リストから[モニタ管理]を選択します。 4[モニタ管理データの格納場所]エントリを見つけます。 188 付録 F • モニタ管理の設定データのバックアップと復元 基本バックアップと復元 ここで説明するのはバックアップと復元の基本的な方法であり,推奨する方法 です。データのキャッシュやファイルのロックが起こらないよう,設定データ ベースの物理コピー中に LDAP サービスを実行してはいけません。 バックアップ 最低 1 日 1 回はデータをバックアップしてください。複数の履歴アーカイブを 保存できるよう,日付(タイム・スタンプ名)が付いたディレクトリにファイ ルが格納されている,高可用性のサーバにデータを格納します。もう 1 つの方 法は,たとえば,..\\backups\Sunday,..\\backups\Monday などのように, 曜日ごとに可用性の高い特定の場所にバックアップする方法です。 大規模な更新や削除を行う前後にもバックアップしてください。 LDAP データベースを手動でバックアップするには,次の手順を実行します。 1 Mercury Business Availability Center を停止して,LDAP サービスを停止します ([スタート]>[プログラム]>[Mercury Business Availability Center] >[Administration]>[Disable Business Availability Center])。 2 ディレクトリ< Mercury Business Availability Center サーバのルート・ディ レクトリ> \openldap\bdb の内容を,バックアップ・メディアにコピーしま す。これは,手動で行うことも,バッチ・ファイルを実行して行うこともでき ます。バックアップ・ファイルの例については,198 ページ「backup.bat」を参 照してください。 3 Mercury Business Availability Center を再起動して,LDAP サービスを起動します ([スタート]>[プログラム]>[Mercury Business Availability Center] >[Administration]>[Enable Business Availability Center])。 復元 LDAP データベースを手動で復元するには,次の手順を実行します。 1 Mercury Business Availability Center を停止して,LDAP サービスを停止します ([スタート]>[プログラム]>[Mercury Business Availability Center] >[Administration]>[Disable Business Availability Center])。 2 < Mercury Business Availability Center サーバのルート・ディレクトリ> \openldap\bdb ディレクトリにあるすべてのファイルを削除します(これら のファイルを削除する前に,一時的な保存場所にコピーしてください)。 189 189 第 4 部 • 付録 3 適切なソースから適切なターゲット・メディアにファイルをコピーします。こ れは,手動で行うことも,バッチ・ファイルを実行して行うこともできます。 復元ファイルの例については,199 ページ「restore.bat」を参照してください。 4 Mercury Business Availability Center を再起動して,LDAP サービスを起動します ([スタート]>[プログラム]>[Mercury Business Availability Center] >[Administration]>[Enable Business Availability Center])。 レプリケーション・サーバへのバックアップと復元の基本 この方法は,基本バックアップのプロセスがレプリケーション・サーバのファ イル・システム上で行われる点を除いては,基本バックアップと復元の手順と 同じです。高い可用性を実現する方法として,最もお勧めする方法です。 利点は,操作が継続している間にプライマリ・サービス(Mercury Business Availability Center を含む)をシャット・ダウンする必要がないことです。また, レプリケーション・サーバは,プライマリ・サーバに障害が発生したときの コールド・バックアップの役目を果たします。 LDIF バックアップと復元 この方法では,LDAP データベースの内容を外部のテキスト表現として抽出す るために,LDIF 表現形式(LDAP Data Interchange Format)が使用されます。 OpenLDAP 2.1.4 以上では,back-bdb バックエンド(標準設定)を使用して, slapd.exe の実行中に slapcat.exe および db_dump.exe を使用できます。これ は,back-bdb バックエンドがページ・レベルでのロックを行っているためです。 バックアップ データを LDIF 形式でバックアップするには,次の手順を実行します。 注:OpenLDAP 2.1.4 以上を実行している場合は,次の手順 1 と手順 2 をスキッ プできます。 190 付録 F • モニタ管理の設定データのバックアップと復元 1 Mercury Business Availability Center を停止して,LDAP サービスを停止します ([スタート]>[プログラム]>[Mercury Business Availability Center] >[Administration]>[Disable Business Availability Center]) 。 2 コマンド・ウィンドウから(ファイルの読み込みのための十分な権限がある場 合),作業ディレクトリを< Mercury Business Availability Center サーバの ルート・ディレクトリ> \openldap ディレクトリに変更します。 3 次のコマンドを実行します。 slapcat -f slapd.conf -b "E=SSEnterprise" -f filename 詳細は次のとおりです。 filename はターゲット LDIF ファイルです(例 : JUL0404.LDIF)。 バックアップ・ファイルの例については,200 ページ「backupLDIF.bat」を参照 してください。 4 Mercury Business Availability Center を再起動して,LDAP サービスを起動します ([スタート]>[プログラム]>[Mercury Business Availability Center] >[Administration]>[Enable Business Availability Center])。 復元 次の処理をステージング LDAP サーバまたはテスト用 LDAP サーバでテストし てください。 データを新規の LDAP データベースに復元するには,次の手順を実行します。 注:OpenLDAP 2.1.4 以降を実行している場合は,次の手順 1 と手順 2 をスキッ プできます。 1 Mercury Business Availability Center を停止して,LDAP サービスを停止します ([スタート]>[プログラム]>[Mercury Business Availability Center] >[Administration]>[Disable Business Availability Center])。 2 コマンド・ウィンドウから(ファイルの読み込みのための十分な権限がある場 合),作業ディレクトリを< Mercury Business Availability Center サーバの ルート・ディレクトリ> \openldap ディレクトリに変更します。 191 191 第 4 部 • 付録 3 bdb ディレクトリにあるすべてのファイルを削除します(これらのファイルを 削除する前に,一時保存場所にコピーしてください)。 4 次のコマンドを実行します。 slapadd -f slapd.conf -b "E=SSEnterprise" -f filename 詳細は次のとおりです。 filename はターゲット LDIF ファイルです(例 : JUL0404.LDIF)。 復元ファイルの例については,201 ページ「restoreLDIF.bat」を参照してください。 5 Mercury Business Availability Center を再起動して,LDAP サービスを起動します ([スタート]>[プログラム]>[Mercury Business Availability Center] >[Administration]>[Enable Business Availability Center])。 レプリケーション OpenLDAP によって,レプリケーション・サービスが提供されます (http://www.openldap.org/software/man.cgi?query=slurpd で,slurpd を参照してくだ さい) 。これらのサービスを使用して,セカンダリ・マシンに複製されたプラ イマリ・サーバ(ホスト・マシン)上にある,情報すべてのコールド・バック アップの保守を行うことができます。サービスを使用する前に,Mercury Business Availability Center システム管理者にお問い合わせください。 本項は,次の項目で構成されています。 192 付録 F • モニタ管理の設定データのバックアップと復元 ➤ レプリケーションの確立 ➤ レプリケーション環境の Nanny Supervisor プロセスの変更 レプリケーションの確立 次に示す手順では,LDAP サーバがインストールされているプライマリ・マシン 上で Mercury Business Availability Center が実行されていること,およびセカンダ リ・マシンがセカンダリ LDAP サーバを実行していることを想定しています。 OpenLDAP サービスのレプリケーションを確立するには,次の手順を実行しま す。 1 Mercury Business Availability Center を停止します。 2 openldap ディレクトリを圧縮します(< Mercury Business Availability Center サーバのルート・ディレクトリ> \openldap)。 3 openldap.zip ファイルをセカンダリ・マシンに転送して,それを解凍します。 4 必要に応じて,レジストリ・エントリを追加します。 レジストリ・エントリの追加(openldap をサービスとして非標準のポートで実 行している場合)に関する詳細については,次の項を参照してください。 5 slapd サービスをセカンダリ LDAP サーバにインストールします。 cd c:\openldap slapd install 6 プライマリ LDAP サーバで実行されている slapd.conf ファイル(< Mercury Business Availability Center サーバのルート・ディレクトリ> \openldap ディレクトリにあります)を編集して,次の行を追加するか,コメントを解除 します。 # Replication MASTER Replica uri=ldap://slaveHost:9389 binddn="E=SSEnterprise" bind-method=simple credentials=fl1pp3r replogfile ./replicate.log 193 193 第 4 部 • 付録 注:slaveHost は,セカンダリ・マシンで実行されている LDAP サーバ名です。 7 セカンダリ LDAP サーバで実行されている slapd.conf ファイル(openldap ディレクトリにあります)を編集して,次の行を追加するか,コメントを解除 します。 #Replication SLAVE updatedn "E=SSEnterprise" updateref ldap://mercuryAMhostname:9389 minServer installation Change 注:mercuryAMhostname は,Mercury Business Availability Center プライマ リ・マシンの名前です。 8 プライマリ・マシン上の< Mercury Business Availability Center サーバの ルート・ディレクトリ> \openldap ディレクトリにあるファイル replica.log を探します。ない場合には,このファイルを作成します。 9 slurpd をプライマリ・マシンにインストールします。 cd c:\mercuryAM\openldap slurpd install 10 Mercury Business Availability Center を起動します。 11 LDAP サーバの実行をセカンダリ・マシンで開始します。 12 レプリケーションが正常に行われたことを確認します。 ➤ テンプレート・コンテナをエンタープライズに追加します。 ➤ 次の資格で,LDAP ブラウザを使用して,ポート 9389 でセカンダリ・マシ ンに接続します。e=SSEnterprise password:fl1pp3r.. ➤ 追加したテンプレート・コンテナが,セカンダリ・マシン上の LDAP サー バにあることを確認します。作成したオブジェクトに対して,LDAP サーバ 上に LDAP ノードが必要です。 194 付録 F • モニタ管理の設定データのバックアップと復元 レプリケーション環境の Nanny Supervisor プロセスの変更 slapd および slurpd レプリケーション・サービスの両方を実行している Mercury Business Availability Center マシン上では,Nanny Supervisor プロセスを 制御するファイルを変更する必要があります。 Nanny Supervisor プロセスを制御しているファイルを変更するには,次の手順 を実行します。 1 ファイル < Mercury Business Availability Center サーバのルート・ディレク トリ> \openldap\openldap_service_recover.bat を変更します。次の行を追 加します。 net start openldap-slurpd 2 バッチ・ファイル openldap_stop を作成して,次の行を追加し,それを openldap ディレクトリに保存します。 net stop openldap-slapd net stop openldap-slurpd 3 ファイル< Mercury Business Availability Center サーバのルート・ディレク トリ> \launch_service\dat\nanny\a_openldap.nanny を変更します。 stop_nt の行を変更して,OpenLDAP サービスを停止する openldap_stop バッ チ・ファイルを実行します。次に例を示します。 stop_nt=":\MercuryAM/openldap/openldap_stop" 195 195 第 4 部 • 付録 OpenLDAP の起動と停止 標準設定では,OpenLDAP は,Mercury Business Availability Center を起動するご とに起動します。また OpenLDAP は,起動時に自動的にデータの整合テストを 行います。Mercury Business Availability Center が OpenLDAP を自動的に起動し ないようにするには,< Mercury Business Availability Center サーバのルー ト・ディレクトリ> \launch_services\dat\ ディレクトリにある a_openldap.nanny ファイルを削除するか,.nanny 拡張子を削除する必要があ ります。 Windows プラットフォーム上 の OpenLDAP を停止して起動するには,次の手 順を実行します。 Windows プラットフォームで実行している OpenLDAP OpenLDAP は,Windows サーバ・マシン上では,NT サービスとして実行され ます。Mercury Business Availability Center が停止した場合でも,OpenLDAP は, 稼働環境内の複数のセンタ・サーバ・マシンにサービスを提供している場合が あるため,サービスとして実行を継続します。センタ・サーバが再起動され, かつサービスが既に実行中の場合は,サービスの実行は継続されます。 サービス管理ツールを使用して,OpenLDAP サービスが,サービスのその他の プロパティを実行しているかどうかを判断することができます([スタート] >[コントロール パネル]>[管理ツール]>[サービス]) 。 Windows プラットフォーム上で実行している OpenLDAP を停止および起動す るには,次の手順を実行します。 次のコマンドを実行します。 net stop openldap-slapd net start openldap-slapd OpenLDAP をサービスとして手動で削除するには,次のようにディレクトリを 変更します。 cd \ < Mercury Business Availability Center ホーム・ディレクトリ> \openldap 196 付録 F • モニタ管理の設定データのバックアップと復元 次のコマンドを実行します。 slapd remove このサービスを手動で再インストールするには,次を入力します。 slapd install 非標準ポートではないポート(9389)上で OpenLDAP をサービスとして実行す るには,レジストリ・キーが必要になります(インストール時に自動的に作成 されます)。 [HKEY_LOCAL_MACHINE\SOFTWARE\OpenLDAP\Parameters] "Urls"="ldap://:9389" ポートが変更されている場合は,Mercury Business Availability Center 設定を更新 して,変更を反映する必要があります。 バックアップと復元の例 本項は,次の例で構成されています。 ➤ backup.bat ➤ restore.bat ➤ backupLDIF.bat ➤ restoreLDIF.bat 197 197 第 4 部 • 付録 backup.bat 次のバッチ・ファイルを Windows システムで実行して,モニタ管理 LDAP デー タベースをバックアップできます。 @echo on rem back.bat rem rem このバッチ・ファイルは,モニタ管理データベースのバックアップ を取ります。 rem if "%1"=="" goto usage if not exist %1 md %1 xcopy bdb\*.* %1 goto done :usage echo backup [DATAFILE] echo ただし echo [DATAFILE] はバックアップするファイルのパス。 echo 使用例 : backup \\backups\mar0404\ :done 198 付録 F • モニタ管理の設定データのバックアップと復元 restore.bat 次のバッチ・ファイルを Windows システムで実行して,モニタ管理 LDAP デー タベースを復元できます。 @echo on rem restore.bat rem rem このバッチ・ファイルは,以前の backup.bat データベース・コピー から rem モニタ管理データベースをコピーします。 rem if "%1"=="" goto usage cd bdb if not exist hold md hold cd hold echo Y | del *.* cd .. xcopy *.* hold echo Y | del *.* cd .. xcopy %1 bdb goto done :usage echo restore [DATAFILE] echo ただし echo [DATAFILE] は復元するファイルのパス。 echo 使用例 : restore \\backups\mar0404.ldif :done 199 199 第 4 部 • 付録 backupLDIF.bat 次のバッチ・ファイルを Windows システムで実行して,モニタ管理データベー スを LDIF 形式の(LDAP Interchange Format)テキスト・ファイルにバックアッ プできます。 @echo off rem back.bat rem rem このバッチ・ファイルは,モニタ管理データベースを rem LDIF 形式のテキスト・ファイルにバックアップします。 rem if "%1"=="" goto usage slapcat -f slapd.conf -b "E=SSEnterprise" -l %1 goto done :usage echo backup [DATAFILE] echo ただし echo [DATAFILE] はバックアップ先のファイルのパス。 echo 使用例 : backup \\backups\mar0404.ldif :done 200 付録 F • モニタ管理の設定データのバックアップと復元 restoreLDIF.bat 次のバッチ・ファイルを Windows システムで実行して,モニタ管理データベー スを,以前作成した LDIF ファイルから復元できます。 @echo on rem restore.bat rem em このバッチ・ファイルは,LDIF ファイルを生成した以前の backup.bat から rem モニタ管理データベースを復元します。 rem if "%1"=="" goto usage cd *ldbm if not exist hold md hold cd hold echo Y | del *.* cd .. xcopy *.* hold echo Y | del *.* cd .. slapadd -f slapd.conf -b "E=SSEnterprise" -l %1 goto done :usage echo restore [DATAFILE] echo ただし echo [DATAFILE] は復元するファイルのパス。 echo 使用例 : restore \\backups\mar0404.ldif :done 201 201 第 4 部 • 付録 202 索引 C CMDB インデックス・フラグメンテーション Oracle サーバ 117 CMDB データベースのフラグメンテーション, MS SQL Server 51 CPU,Oracle サーバ 109 D DBCC SHOWCONTIG 46 dbverify ツール 171 L LDAP backup.bat 198 backupldif.bat 200 openLDAP の起動と停止 196 restore.bat 199 restoreldif.bat 201 基本バックアップと復元 189 データベースの位置 188 バックアップと復元の方法 188 バックアップと復元の例 197 モニタ管理の設定データの バックアップと復元 187 レプリケーション 192 レプリケーション環境の Nanny Supervisor プロセスの変更 195 レプリケーション・サーバへのバック アップと復元の基本 190 LDIF,バックアップと復元 190 M MDAC MS SQL Server 11 Oracle Client 105 Oracle サーバ 105 Mercury Business Availability Center Windows 認証の有効化 32 Mercury Business Availability Center のサイズ 設定 MS SQL Server 62 Oracle サーバ 126 Mercury ユニバーサル CMDB 定義 4 MS SQL Windows 認証を使用したデータベース への接続 35 MS SQL Server CMDB データベースの フラグメンテーション 51 インストール 72 権限 17 サイズ設定ガイドライン 61 システム・データベース 21 システム要件 11 設定 81 設定の確認 67 設定の変更 67 チェックリスト,サポートと認定用 66 データ格納 153 データの配置 18 データ・ファイルの削除 23 データ・ファイルの追加 22 データ・ファイル・プロパティの変更 23 データベース権限 17 データベースの監視 55 データベースの作成 14 データベースの整合性 44 データベースの設定 22 データベースのフラグメンテーション 44 データベースのプロパティ 19 203 索引 データベースの保守 39 統計情報の収集 43 導入の概要 10 バックアップ,データベース 40 ファイル・グループ 20 ファイルのプロパティ 19 分散の統計 53 ログの配置 18 MS SQL Server のインストール インスタンス名 ダイアログ・ボックス 72 コンポーネントの選択 ダイアログ・ ボックス 75 サービス アカウント・ダイアログ・ ボックス 76 照合順序の設定 ダイアログ・ボックス 78 セットアップの種類 ダイアログ・ ボックス 74 認証モード・ダイアログ・ボックス 77 ネットワーク ライブラリ・ ダイアログ・ボックス 80 R O RMAN Oracle Recovery Manager 123 openLDAP Windows プラットフォームで実行 196 Oracle インスタンス 91 クエリ・パフォーマンスの最適化 113 データベース環境 93 ファイルのサイズ設定 132 クエリ・パフォーマンスの最適化 111 Oracle Client MDAC 105 Mercury Business Availability Center 向け の設定 105 インストール 104 システム要件 104 Oracle RMAN (Recovery Manager)123 Oracle アラート・ファイル 109 Oracle サーバ CMDB インデックス・ フラグメンテーション 117 CMDB に関する統計情報の収集 113 CPU 109 インスタンス 91 204 エディション 91 サイズ設定ガイドライン 125 システム要件 89 チェックリスト,サポートと認定向け 138 データ格納 153 データベースの保守 108 導入の概要 88 入出力 109 バックアップ,データベース 121 パラメータのサイズ設定 128 表領域 94 表領域の保守 110 プロファイル・データベースに関する 統計情報の収集 111 Oracle サーバにおけるクエリのパフォーマン ス,最適化 111, 113 Oracle スキーマ Mercury Business Availability Center 向け の権限 102 S Set Management Database ユーティリティ 14, 97 SGA(システム・グローバル領域),Oracle サーバ 108 SID 98, 105 T tempdb データベース,MS SQL Server 64 tempdb データベース,MS SQL Server 21 tnsnames.ora ファイル 105 W Windows 認証 Mercury Business Availability Center にお ける有効化 32 MS SQL データベースへの接続 35 あ アーカイブ・ファイル,Oracle サーバ 109 アラート・ファイル,Oracle サーバ 109 索引 い インスタンス,Oracle サーバ 91 インストール MS SQL Server 72 Oracle Client 104 インデックス・フラグメンテーション, CMDB Oracle サーバ 117 か 確認 MS SQL Server の設定 67 データベース・スキーマ 169 管理データベース MS SQL Server での作成 14 定義 4 管理ユーザ・スキーマ 97 け 権限,Mercury Business Availability Center の Oracle スキーマ 102 権限,MS SQL Server 17 さ サーバ設定オプション,MS SQL Server 63, 81 サービス設定オプション,MS SQL Server 81 サイズ設定ガイドライン MS SQL Server 61 Oracle サーバ 125 し システム・データベース,MS SQL Server 21 システム要件 MS SQL Server 11 Oracle Client 104 Oracle サーバ 89 データ管理 179 データのパージ 161 パージ・マネージャ 162 パラメータ値の計算 163 データのパージ,パラメータ値の設定 165 データのパーティショニング 161 データの配置,MS SQL Server 18 データベース Oracle サーバでの設定 93 からのデータのパージ 161 データベースからのデータの削除 161 データベース権限,MS SQL Server 17 データベース集約のメリット 150 データベース・スキーマ,検証 169 データベース設定,MS SQL Server 22 データベースの監視,MS SQL Server 55 データベースの作成 MS SQL Server 14 データベースの整合性,MS SQL Server 44 データベースの負荷の状況,Oracle サーバ 108 データベースのフラグメンテーション,MS SQL Server 44 データベースのプロパティ,MS SQL Server 19 データベースの保守 MS SQL Server 39 Oracle サーバ 108 データベースの要件 4 データベース分散 150 データベース・ユーザ,作成 176 データ・ローダ 179 DLQ クリーンアップ・ユーティリティ 185 障害を起こしたデータの保持期間の変 更 183 データの管理 179 トラブルシューティング 181 標準設定のログ・レベルの変更 183 フォルダの場所 181 ち チェックリスト,サポートと認定向け Oracle サーバ 138 チェックリスト,サポートと認定用 MS SQL Server 66 て データ格納 153 と 統計情報 MS SQL Server での収集 43 Oracle サーバの CMDB に関する収集 113 Oracle サーバのプロファイル・データ ベースについて収集 111 205 205 索引 導入 MS SQL Server 10 Oracle サーバ 88 トラブルシューティング,データ・ローダ 181 トランザクション・ログ 18, 42, 43 ゆ ユーザ・スキーマ 管理 97 プロファイル 99 ユーザ,データベース・スキーマ検証のため の作成 176 に 認証 Mercury Business Availability における Windows 認証の有効化 32 Windows 認証を使用した MS SQL データベースへの接続 35 は パージ・マネージャ 161 ハードウェアのサイズ設定 MS SQL Server 63 Oracle サーバ 127 バックアップ,データベース MS SQL Server 40 Oracle サーバ 121 パラメータのサイズ設定,Oracle サーバ 128 ひ 表領域,Oracle Server 作成 158 パージ・マネージャ使用時の作成方法 168 表領域,Oracle サーバ 94 保守 110 ふ ファイル・グループ,MS SQL Server 20, 154 ファイルのサイズ設定,Oracle サーバ 132 ファイルのプロパティ,MS SQL Server 19 フラグメンテーション,MS SQL Server CMDB データベース 51 フラグメンテーション,MS SQL Server データ ベース 44 プロファイル・データベース MS SQL Server での作成 14 定義 4 プロファイル・ユーザ・スキーマ 99 分散,データベースの 150 分散の統計,MS SQL Server 53 206 ろ ローカル管理される表領域,Oracle サーバ 94 ローダ,「データ・ローダ」を参照 ログの配置,MS SQL Server 18 ログ・レベル 標準設定のデータ・ローダの変更 183
© Copyright 2026 Paperzz