データベース環境の準備

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