インメモリー技術を利用した超高速トランザクションへの対応セミナー - IBM solidDB インメモリーDB 構成と運用のポイント 日本アイ・ビー・エム システムズ・エンジニアリング株式会社

インメモリー技術を利用した超高速トランザクションへの対応セミナー
- IBM solidDB インメモリーDB 構成と運用のポイント
日本アイ・ビー・エム システムズ・エンジニアリング株式会社
インフォメーション・マネジメント
1
© 2009 IBM Corporation
目次
• 1．IBM solidDB 製品概要
• 2．IBM solidDB 構成のポイント
• 3．IBM solidDB 運用のポイント
2
© 2009 IBM Corporation
１. IBM solidDB 製品概要
3
© 2009 IBM Corporation
Solid Information Technology社の歴史
• 2008年1月より、IBM Corporation 100% 資本の子会社を経て完全統合（2008年6月）
• IBM ソフトウェア事業、インフォメーションマネジメント事業部へ統合
• 日本法人であるソリッド株式会社も日本アイ・ビー・エム株式会社へ統合
• ビジネス カテゴリ
•
高速かつ高可用なインメモリデータベースを提供するソフトウエアベンダーとして14年間におよぶ継続的な開発、
€35Mの開発投資を行う
• Solid の実績
• 全世界に300社以上の顧客、主に通信大手12ネットワーク機器ベンダー9社に採用
• 本番環境にて、既に４００万～インスタンスが稼動（OEM ビジネスモデル）
• バックグラウンド
• 1992年フィンランドの首都ヘルシンキで設立
• 1999年本社機能を米カリフォルニア州に移す （カリフォルニア州クパチノ）
EMEA 本社/R&D
本社/R&D
Helsinki, Finland
応用研究センター
Oulu, Finland
第二R&D
センター
第二R&Dセンター
St Petersburg,
Petersburg, Russia
アジア太平洋地域
アジア太平洋地域
Tokyo
WW本社
WW本社//米西海岸
Cupertino,
Cupertino, CA
CA
USA
4
セントラルヨーロッパ
Munich, Germany
and France
Beijing and Shenzen
© 2009 IBM Corporation
IBM solidDBの製品群
IBM solidDB
App
App
IBM solidDB Universal Cache
App
App
App
App
solidDBは、高速なデータアクセスを実現するインメモ
リーのデータベースです
単体で利用するsolidDBと、他のデータベースのフロント
キャッシュとして機能するsolidDB Universal Cacheがあ
ります
5
© 2009 IBM Corporation
IBM solidDB インメモリー・データベースの特長
• 高速なデータアクセスの実現
App
App
App
• マイクロ秒オーダーの応答時間
• 毎秒数万トランザクションオーダーのスループット
• 極めて高い可用性
• 2つのsolidDBインスタンス間で1秒以内の障害時引き継ぎ
• 低コスト
• 簡単に導入、構成のできる、SQL標準準拠のデータベース
IBM solidDB
6
• 極めて低い管理コスト
• 既存のSQLのスキルを活用し、低コストの開発が可能
© 2009 IBM Corporation
IBM solidDB Universal Cache
IBM, Microsoft, Oracle, Sybaseの各データベースの高速化を実現
• 様々なDBのフロントキャッシュ
App
App
App
• IBM DB2ファミリー, Informix Dynamic Server, Microsoft
SQL Server, Oracle, Sybaseの各データベースアクセス
の高速化を実現
• 超高速なDBアクセスを実現
• マイクロ秒オーダーの応答時間
• 毎秒数万トランザクションオーダーのスループット
• 様々な業務要件、構成のニーズに適合
Universal Cache
• 強力なスキーマ・マッピングとデータ変換の機能
• スケールアップ/スケールアウト拡張に対応
• 堅牢なデータベース
• データの永続性を保障
• 障害時に1秒以内で待機系に切り替えることのできる高
可用性
7
© 2009 IBM Corporation
極めて高い性能： 導入済みデータベースの高速化が可能
App
App
応答時間
App
800
691
700
600
マイクロ秒
Universal Cache
500
501
400
300
200
132
100
26
0
Select
ƒ
ƒ
8
Update
solidDB Universal Cache + ディスク型DB
ディスク型DB
© 2009 IBM Corporation
極めて高い可用性： 高速フェイルオーバー/ロードバランス
アプリケーション
•
実接続
solidDB ODBC,
JDBC ドライバ
TF
ドライバ
• パフォーマンス・平均復旧時
間とデータ継続性の
トレードオフを適性にコント
ロール
solidDB HAC
監視プロセス
仮想接続
アクティブ・スタンバイ構成
•
高速フェイルオーバ
• solidDB 透過接続 機能
高速フェイルオーバ
solidDB
アクティブDB
(プライマリ)
9
全トランザクションは、
リアルタイムで同期
(設定により変更可)
•
ロードバランス機能
•
データベース機能の一部
スタンバイDB
（参照可能なセカンダリ)
© 2009 IBM Corporation
2. IBM solidDB 構成のポイント
10
© 2009 IBM Corporation
IBM solidDBのコンフィグレーション
• solid.ini ファイル
• solidDBホームディレクトリに配置
• solidDBエンジンの設定
• データベースディレクトリ、ログファイ
ル、ソートファイル
• 通信設定
• メモリー設定
• スケジュール設定
• 非常に少ない設定で動作可能
• 多くのケースではデフォルト値で稼動
可能
11
solid.ini
[IndexFile]
FileSpec_1=c:¥solid¥db¥solid.db 2000M
CacheSize = 32M
[Logging]
FileNameTemplate=d:¥sollogs¥sol#####.log
[General]
BackupDirectory=e:¥solbackup
[Com]
Listen=tcp 1313, shm solid
[Sorter]
TmpDir_1 = c:¥temp
[Srv]
At=20:30 makecp, 21:00 backup,
sun 23:00 shutdown
© 2009 IBM Corporation
IBM solidDBのデータの保全
• どのようにしてインメモリ上のデータを保持しているのか？
メモリ上のデータは障害時に復旧できるのか？
アプリケーション
②
メイ ン メ
①
モリ
チェックポイント処理
t
CKPT
1.
障害
発生
DBファイルから、最後に成功した
チェックポイントまで回復（ロールバック）させる。
トランザクション・
データベース
↓
ログ・ファイル
・ファイル
2. チェックポイントからトランザクションログファイル
を使用して最新（障害発生）の時点までロールフォー
※チェックポイント間隔は、トランザクション数・
ワード処理で復旧
時間(msec)を指定
12
© 2009 IBM Corporation
IBM solidDBのロギング
非同期ロギング
(write-ahead log, WAL)
Î Relaxed durability
同期ロギング
(write-ahead log, WAL)
Î Strict Durability
Commit
データベースサーバー
データベースサーバー
Transaction
Logger
Transaction
Logger
OK
OK
レスポンス
タイム
DB
Log
ACIDの完全保障が必須のケース
ACIDの完全保障が必須のケース
13
Commit
DB
Log
高速なレスポンスが重要なケース
高速なレスポンスが重要なケース
© 2009 IBM Corporation
非同期ロギングの更新処理パフォーマンスへの影響
スタンドアロン構成でのログモードによるスループット比較
2458
Transactions per second
2500
2250
Read/write ratio
2034
2000
1750
1500
R20/W80
1250
1005
1000
750
R80/W20
711
500
250
0
Strict
Relaxed
Durability level
非同期ロギングでは 20-40%スループットが向上
（トランザクションロスとスループット向上のトレードオフ）
© 2009 IBM Corporation
ロギング設定（継続性レベルの設定）
Commit
Strictロギング
遅延時間
• トランザクションがコミットされる度に、ロギング (同期ロギング)
OK
DB
Relaxedロギング
log
• サーバーはログに書き込むタイミングを保留可能 (非同期ロギング)
• HA構成なしでは、トランザクションは喪失する可能性あり
• HA構成によりパフォーマンスを向上
Commit
遅延時間
OK
Adaptive（StrictとRelaxedの組み合わせ）ロギング
DB
log
DB
log
• HA構成の2相コミットレプリケーションとのみ使用可能
• プライマリアクティブ状態の場合、Relaxed ロギングを使用
• 上記以外の状態（つまり方系運用時）の場合は、Strict ロギングを使用
15
© 2009 IBM Corporation
Adaptive ロギング
通常運用時 (2-Safe Received)
プライマリでは高速
同期、非同期ロギン
グで処理可能
Commit
OK
非同期ロギング
log
log
ノード障害発生！
継続性はセカンダリ
で担保
障害時（プライマリアローン状態）
Commit
OK
log
同期ロギング
同期ロギングにより
継続性をローカル側
で担保（自動切り替
え）
2-Safe Received方式では、2つのノードが同時に停止
しないかぎり必ずデータを担保できる。
16
© 2009 IBM Corporation
HA（ホットスタンバイ） 構成時の考慮点
¾ホットスタンバイ構成時における得失評価（トレードオフ）
～各コンポーネントは相反する関係～
•アプリケーションの処理スピード
•平均復旧時間 (MTTR - Mean Time To Repair)
•データ整合性
¾Solid の利点
•3種類のHA構成時のデータ同期オプション＋ロギングオプション（Strict/Relaxed)
1-Safe (一相コミット)、2-Safe (二相コミット)の3種類の同期方法をロギングオプションと
併せて各ノードにそれぞれ適応可能。
•アプリケーションの運用に影響を与えることなく、継続性レベルを動的に変更可能
グローバル、セッション（接続毎）、トランザクション毎に設定可能
MTTR
長
い
↑
↓
短
い
Relaxed
17
高速 ← → 遅い
アプリケーション
スピード
Medium
データ整合性
高
い
↑
↓
低
い
※DB2と同様に３
つの項目内でのト
レードオフを比較
的自由に設定で
きることが重要。
Stringent
© 2009 IBM Corporation
2-Safe Acknowledgement 同期手法
プライマリ
Commit
2-Safe Received
OK
セカンダリでメッセージ受信した
段階でACK を返信
• 短い遅延時間
• 1ノードのみの障害時の継続性を担保
セカンダリ
OK
log
非同期ロギング
DB
2-Safe Visible
セカンダリでトランザクションが
処理され、データへアクセス可能に
なった段階でACKを返信
• データの直列可能性を保持
2-Safe Durable
セカンダリでトランザクションが
永続性のあるログにストアされた
段階でACKを返信
• 両ノードでの障害時にも
データ継続性を保持
18
DB
log
DB
log
Commit
OK
DB
log
Commit
非同期ロギング
Commit
OK
log
DB
log
同期ロギング
DB
© 2009 IBM Corporation
各同期モードでのフェイルオーバー時間
Failover time (milliseconds)
R20W80
R50W50
R80W20
0
100
2-safe-durable
200
2-safe-received
300
400
1-safe
9 同期レベルが高い程フェイルオーバー時間は短くなる
19
© 2009 IBM Corporation
各同期モードでのスループット
T ran sactio n s p er seco n d
4000
3551
3500
3269
3000
2500
2309
2000
1808
1781
R80/W20
1465
1500
R20/W80
943
1000
552
500
0
2-Safe Durable
(sync logging)
2-Safe Visible
(async logging)
2-Safe Received
(async logging)
1-Safe (async
logging)
9 同期レベルが高い程スループットは低くなる
© 2009 IBM Corporation
IBM solidDB ロードバランシング
- 参照トランザクションのスループット向上
• 参照トランザクションはプライマリと
セカンダリDBに振り分けられる
• 更新トランザクションは全てプライ
マリで処理される
Application
solidDB
Transparent Connectivity Driver
• 接続情報属性の設定（ODBC）
• 接続プロパティー設定（JDBC）
Read & Write
transactions
Read
transactions
Primary
Secondary
Secondary
(active)
(hot
(hot
standby)
-standby)
-
Replication
設定例: "TF_LEVEL=SESSION PREFERRED_ACCESS=READ_MOSTLY
SERVERS=tcp host1 1315, tcp host2 1325"
21
© 2009 IBM Corporation
ロードバランシングによるスループット向上
All read load on primary
No read load on primary
Telecom One Benchmark: 80/20 read/write workload
22
© 2009 IBM Corporation
IBM solidDB High Availability Controller（HAC）
ノード A
ノード B
セカンダリ
プライマリ
solidDB HSB
レプリケーション
solidDB HA Controller
HA 管理ノード
solidDB HA Controller
JDBC
HA Manager （GUIツール）
23
© 2009 IBM Corporation
IBM solidDB Universal Cache 6.3ー アーキテクチャー概要
GUI
管理コンソール
GUI
solidDB CDC
Instance
構成ツール
CDC Instance
solidDBとバックエンドDB間の
レプリケーションを管理し、両
者の同期を行うCDCコンポー
ネント
Access Server
Backend DB CDC
Instance
※CDC : Change Data Capture
アクセス・サーバー
GUI
構成ツール
24
管理コンソールから各CDCイ
ンスタンスへアクセスし、各イ
ンスタンスの管理をするため
に起動するプロセス
© 2009 IBM Corporation
IBM solidDB Universal Cache 6.3ー ホットスタンバイ構成
ホットスタンバイなし
ホットスタンバイ構成
solidDBのCDCイン
スタンスは、solidDB
サーバーで起動
solidDBのCDCイン
スタンスは、バック
エンドDB側で起動
solidDB JDBC driver
GUI
GUI
プライマリ
CDC for solidDB
-
管理コンソール
GUI
CDC 管理コンソール
セカンダリ
CDC for DB2
JDBC driver
GUI
管理コンソール
solidDB JDBC driver
CDC for solidDB
CDC for DB2
JDBC driver
CDC 管理コンソール
25
© 2009 IBM Corporation
IBM solidDB Universal Cache
– スキーママッピングとデータ変換定義のツール
Universal Cache
26
© 2009 IBM Corporation
IBM solidDB 構成のポイント まとめ
¾ ログの同期的書き出しはレスポンス低下を引き起こすので、非同期的に書き出す
¾ 非同期ロギング時には、データ保全性を確保するために高可用性の構成を選択する
片側DB障害時にも対応が可能なAdaptiveモードを選択する
¾ 高可用性構成のデータ同期モードは、レスポンス、データ整合性、障害回復速度のト
レードオフになる
¾ セカンダリー側のDBは参照が可能、ドライバーの機能でロードバランシング
¾ 高可用性構成での自動障害検出・フェールオーバーのための機能は提供されている
ので、クラスターソフトウェアの導入は不要
¾ Universal Cache使用時にもsolidDB側の高可用性構成は可能
27
© 2009 IBM Corporation
3. solidDB 運用のポイント
28
© 2009 IBM Corporation
インメモリーDB メモリ使用量 – キャパシティー計算
インメモリテーブルのサイズ計算方法
注意：おおよその目安となりますので、実際の計測データとは異なる場合があります。
テーブルサイズ（table_size） + インデックスサイズ（(index_sizes)の合計）
table_size =
1.3 x 行（rows） x カラムサイズの合計（(sum_of(col_sizes)） + (3 x ワードサイズ（word_size）) + (2 *
カラム数（num_cols）) + 2)
ワードサイズ（word_size）は、マシーンのワードサイズを示しています(e.g. 4 bytes for 32-bit OS
and 8 bytes for 64-bit OS);
インデックサイズは、1.3 x 行数 x ( (dist_factor x sum_of(col_sizes + 1)) + (8 x word_size) + 4)
“dist_factor”は、１．０～２．０の値とります。
（この値は、キーバリュー値の分布により依存し、もしデータ値が異なっている場合は、２．０をとり、似てい
る値であれば、１．０になります。）
29
© 2009 IBM Corporation
インメモリーDB メモリ使用量 – メモリ使用量の観察
• 大きなトランザクションは、トランザクションを実行中により多く
のメモリを消費します（DELETEなどの処理を実行した場合、
ロールバック領域確保するため、最大３倍ほどのメモリ領域を
必要とする場合もあります）。
• MME.ImDbMemoryLimitパラメタは、DELETEに関してのメモ
リ消費量を制限することはできません。
• Solidサーバプロセスは、OSがスワップを実行しているかして
いないかを判断することができません。メモリ消費量が増大し
てきた場合、OSレベルでの監視も必要です。
Memo
DELETE処理は、
ロールバック領域に、
トランザクション実行中にコピー
を保持する必要があります。
30
© 2009 IBM Corporation
診断ツール
• ADMIN COMMAND（管理者コマンド）を使用して、データベー
ス統計情報とサーバをモニタします：
• imdbsize
（インメモリDBサイズ）
• perfmon （パフォーマンスモニタ）
• report
（レポート機能）
• EXPLAIN PLAN FOR文を使用して、SQLの実行計画
パスの確認をします
• SOLIDのトレースツール
• OSツールを使用して、CPU、メモリ使用率のモニタをします。
31
© 2009 IBM Corporation
診断ツール – Admin Command ’PERFMON’;
Database Status
0 Performance statistics:
0 Time (sec)
45
40
40
45
40
50
41
14
Total
0 File open
:
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0 File read
:
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
1.1
0 File write
:
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0 File append
:
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0 File flush
:
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0 File lock
:
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0 Cache find
:
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
2.4
0 Cache read
:
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
1.1
0 Cache write
:
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0 Cache prefetch
:
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
1.1
0 Cache preflush
:
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0 RPC messages
:
0.0
0.0
0.0
0.0
0.3
0.2
0.0
0.0
0.0
0 RPC read
:
0.0
0.0
0.0
0.0
0.3
0.2
0.0
0.0
0.0
0 RPC write
:
0.0
0.0
0.0
0.0
0.3
0.2
0.0
0.0
0.0
0 RPC uncompressed
:
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0 RPC compressed
:
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0 Com sel empty
:
0.1
0.0
0.1
0.0
0.1
0.1
0.0
0.1
0.0
0 Com sel found
:
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0 SQL prepare
:
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0 SQL execute
:
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0 SQL fetch
:
0.0
0.0
0.0
0.0
2.6
1.7
0.0
0.0
0.0
........................................................................................
0 Db size
: 148032 148032 148032 148032 148032 148032 148032 148032
148032
0 Db free size
: 29992
29992 29992 29992 29992 29992 29992 29992
29992
0 Mem size
: 116623 116623 116623 116623 116687 116719 116719 116719
116719
32
© 2009 IBM Corporation
診断ツール – Admin Command ’REPORT’
Database Status
• サーバ統計情報のレポート作成
コマンド
1110110
001011
33
• ADMIN COMMAND ’REPORT <ファイル名>’
• このレポートは、その時のサーバ統計情報、
状況のスナップショットを取得します。
© 2009 IBM Corporation
Statements Execution
診断ツール – EXPLAIN PLAN FORステートメント
• 実行パスを検証するためのツール
使用方法:
EXPLAIN PLAN FOR <SQL文>
• 各クエリの実行計画を確かめること
ができます。
EXPLAIN PLAN FOR
SELECT COUNTRY, CITY, COUNT(*)
FROM CUSTOMER, INVOICE
WHERE CUSTOMER.CUSTOMER_ID =
INVOICE.CUSTOMER_ID
GROUP BY COUNTRY, CITY
ORDER BY COUNTRY;
34
Merge Join
CUSTOMER, INVOICE
CUSTOMER
INVOICE
© 2009 IBM Corporation
診断ツール – EXPLAIN PLAN FOR出力結果
1
ID UNIT_ID PAR_ID JOIN_
PATH
1
2
3
4
5
6
7
8
9
10
11
12
13
1
2
3
4
4
5
6
6
6
7
8
8
8
0
1
2
3
3
4
5
5
5
4
7
7
7
0
0
0
5
7
0
0
0
0
0
0
0
0
UNIT_TYPE
INFO
ORDER
GROUP
ORDER
JOIN
NO PARTIAL SORT
2
EXTERNAL SORT
MERGE JOIN
3
ORDER
TABLE
NO ORDERING REQ..
CUSTOMER
PRIMARY KEY
CUSTOMER_ID > 60
NO ORDERING REQ
INVOICE
INDEX ONLY I_IDX_1
CUSTOMER_ID > 60
ORDER
TABLE
explain plan for
SELECT COUNTRY, CITY, COUNT(*) FROM CUSTOMER,
INVOICE WHERE CUSTOMER.CUSTOMER_ID =
INVOICE.CUSTOMER_ID AND CUSTOMER.CUSTOMER_ID
> 60 GROUP BY COUNTRY, CITY ORDER BY COUNTRY;
4
5
6
Order
Group
Order
Join
Order
Table
7
8
CUSTOMER
Order
Table
INVOICE
•
EXPLAIN PLAN文の出力結果→MERGE JOIN が使用されています。
•
テーブルをJOINする場合、
カスタマテーブルのプライマリキーが、オーダーテーブルのセカンダリキーが使用されてい
ます。
• テーブルを結合する際に、並び替えは発生していません。
•
最終結果の並び替え作業は、外部ソート領域（ディスク）で実行されています。
35
© 2009 IBM Corporation
SOLID トレース機能
ADMIN COMMAND ‘MON ON’
ADMIN COMMAND ‘TRACE ON SQL’
solid.iniファイルに指定する場合：
[Srv]TraceLogSize
[Com]Trace
[Com]TraceFile
11.10
11.10
11.10
11.10
11.10
11.10
11.10
11.10
11.10
11.10
11.10
11.10
11.10
11.10
36
13:19:43
13:19:48
13:19:48
13:19:48
13:19:48
13:19:57
13:19:57
13:19:57
13:20:13
13:20:13
13:20:25
13:20:25
13:20:25
13:20:25
7:1:fetch next, 1 rows, total 1
7:2:opencursor 'SELECT * FROM TABLES‘
7:2:execute
7:2:fetch next, 2 rows, total 2
7:2:fetch next, 81 rows, total 83
7:3:opencursor 'SELECT COUNT(*) FROM MMETEST‘
7:3:execute
7:3:fetch next, 1 rows, total 1
User 'DBA' connected, user id 14, machine id ibmt21.
14:transopt autocommit off (3)
14:0:opencursor 'SELECT * FROM MMETEST WHERE ROWNUM < 5‘
14:0:execute
14:0:fetch next, 2 rows, total 2
14:0:fetch next, 2 rows, total 4
© 2009 IBM Corporation
メモリロード時間（参考）
メモリ起動時間の目安は、データ量、サーバスペックによって異なるため参考データ
として提示します。今回使用した機材は：
SunFire V20z AMD Opetron x2 / RAM2GB / SCSI 15000rpm x2です。
使用する機材によって、結果は変わってきますので、あくまで目安としてください。
クリーン（DBプロセスのみ起動）な状態でのロード時間計測になりますので、
実運用環境では若干のずれが見込まれます。
•
Case 1: 100000subs (solid.db 94mb)Loading time = 9 sec
•
Case 2: 200000subs (solid.db 178mb)Loading time = 18 sec
•
Case 3: 500000subs (solid.db 450mb)Loading time = 46 sec
•
Case 4: 1000000subs(solid.db 865mb)Loading time = 93 sec
vmstat -n 1 90でメモリサイズを監視（物理メモリ量２GB）：
ロード前:1874580k ロード完了後: 52296k 差分が100万人加入者データサイズ
①DBファイルサイズは、メモリサイズとは異なります。つまり、「ロード時間」は
データ展開とインデックス再作成時間が含まれます。100万件だとDBファイルは
865mb 展開後は1.9GB位になります。
②計測方法は：1行目のDB起動時間（--Tue Dec 05 18:26:36 2006）から、
「Database started.」が表示されるまでです。（DBサーバが要求受付可能になる時点）
37
© 2009 IBM Corporation
IBM solidDB Universal Cache – キャッシュの同期監視ツール
レプリケーション処理のレイテンシーやスループット情報の監視
Universal Cache
38
© 2009 IBM Corporation
IBM solidDB 運用のポイント まとめ
¾ メモリー容量見積もり時には、計算ロジックを使用しておおよその容量を見積もる
¾ メモリー使用の観察は必要、ロングトランザクションがある場合は、大量のメモリー消
費の可能性もあるので注意
¾ データベースの統計情報の出力が可能、モニターや障害時の切り分けに使用する
¾ アクセスプランの確認も可能
¾ メモリーへのデータのロードにはある程度の時間が必要なので、大容量のインメモリー
DBを構成する場合は考慮が必要
¾ Universal Cache使用時にもデータレプリケーションのモニターツールが提供されている
39
© 2009 IBM Corporation