Agenda マイグレーション実績 カスタマー傾向 ダウンタイム圧縮 テーブルスプリッタでのダウンタイム圧縮 Unicode Conversion 実績 エクスポートサーバでのダウンタイム圧縮 さいごに

2008/06/20 Tokyo

2008/06/23 Osaka

Yoshinori Hamaguchi

Agenda



マイグレーション実績



カスタマー傾向



ダウンタイム圧縮



テーブルスプリッタでのダウンタイム圧縮



Unicode Conversion実績



エクスポートサーバでのダウンタイム圧縮



さいごに

マイグレーション実績

(OS/DB変更)

AS/400

AS/400

DB2

DB2

2

2

UNIX

UNIX

DB2

DB2

1

1

UNIX

UNIX

Informix

Informix

1

1

UNIX

UNIX

SAPDB

SAPDB

2

2

UNIX

UNIX

Oracle

Oracle

25

25

Windows

Windows

Oracle

Oracle

3

3

UNIX

UNIX

Oracle

Oracle

4

4

(other UNIX)

(other UNIX)

Windows

Windows

Oracle

Oracle

13

13

Windows

Windows

MSSSQL

MSSSQL17

17

Source System

Target System

マイグレーション実績

(年度別)

2003

2003

年度

件数

3

3

2008年は5月末まで

2004

2004

2005

2005

2006

2006

2007

2007

2008

2008

5

5

1

1

2

2

1

1

12

12

4

4

10

10

6

6

2

2

1

1

OS/DB Migration

OS/DB Migration

Export/Import

Export/Import

によるサーバ入替え

によるサーバ入替え

2004

2004

年に確立したダウンタイム圧縮で、

年に確立したダウンタイム圧縮で、

₂₀₀₆

₂₀₀₆

年に

年に

_Migration

_Migration

件数が増加

件数が増加

2006

カスタマーの稼働停止日数

計画停止日数 Migrationシステム数 弊社作業時間実績 * * 弊社作業時間実績は、エクスポートダンプ搬送やクライアント削除実施などの特殊ケースを除いた、

5日以上の停止をしているカスタマーは、4件がMigration→Upgrade

半分以上のケースでカスタマーサイドの夜間作業なし

３日以上停止したカスタマーの８割がたは、最終日が予備日

SAPプロダクト別

SAP R/3

SAP R/3

30

30

Migration (OS/DB変更)

SAP BW

SAP BW

4

4

Export/Import (OS/DB未変更)

SAP R/3

SAP R/3

13

13

Backup/Restoreによるシステムコピー

SAP R/3

SAP R/3

1

1

SAP APO

SAP APO

2

2

3.0D

3.0D

1

1

3.1I

3.1I

1

1

4.0B

4.0B

3

3

4.5B

4.5B

1

1

4.6C

4.6C

15

15

4.7

4.7

4

4

4.6B

4.6B

5

5

2.0B

2.0B

1

1

3.1C

3.1C

1

1

3.5

3.5

2

2

3.1H

3.1H

1

1

4.0B

4.0B

2

2

4.6B

4.6B

4

4

4.6C

4.6C

4

4

4.7

4.7

2

2

4.6C

4.6C

1

1

3.0A

3.0A

1

1

3.1

3.1

1

1

年々増加するデータベースサイズ

マイグレーション作業時間は、

1～2日以内を要求される

長期間の運用によるデータサイズの大型化

ダウンタイム圧縮により、大規模顧客からのアプローチが来る

2003年

2004年

2005年

2006年

2007年

2008年

90GB

240GB

450GB

300GB

650GB

1.6TB

Migration時間短縮

リアルテックは、様々な手法で時間を短縮

システム停止前に作業実施

不要な処理の削除

RDBMSのパラメータ変更

マイグレーションキットのパラメータ変更

エクスポートプロセス分割と多重度の増加

エクスポート順序の入れ替え

テーブルスプリッタ

(Rel. 640 or Higher)の使用

エクスポートサーバの構築

ダウンタイム圧縮のモデル

本番稼動中

ダウンタイム

マイグレーションキットのインストール 統計情報の更新 エクスポート実施 ダンプのコピー インポート用DB作成 インポート実施 お客様サイドへ引渡し キットのインストール 補足処理 エクスポート性能の改良 インポート用DB作成 補足処理 エクスポート実施 ダンプのコピー(随時) インポート実施(随時) お客様サイドへ引渡し

標準的な手法

リアルテックの手法

大幅なダウンタイム削減

ダウンタイム圧縮実績

標準の手法

作業時間実績

ログからの逆算時間

ダウンタイム

エラーリカバリ

Migration中のエラーによる被害を最小に抑える

エラー原因確認

対応方法

最初からやり直し

通常は不必要

リトライ

時間効率が悪い

並行してリカバリ

遅延を極力短縮

Migrationのエクスポートやインポート

リリース

4.6D以下でのエクスポート

Large Table (eg. BSIS, RFBLG etc)

その他のテーブル

エクスポート時間が短くなる組み合わせを考える

・ 並列度

テーブルスプリッタ

(Release 640 or Higher)

Kernel 4.6D

Kernel 4.6D

以前

以前

Kernel 640

Kernel 640

以降

以降

時間

Large Table (eg. BSIS, RFBLG etc)

一つのR3loadでエクスポートするため、時間のネックになることが多い

R3load

複数のR3loadでエクスポートするため、 劇的に時間を短縮出来ることが多い

サーバ一杯の負荷をかける

CPU／ディスク

エクスポート時間短縮

range A

range B

range C

range D

range E

R3load

R3load

R3load

R3load

R3load

テーブルスプリッタでの時間実績

移行元 移行先 DBサイズ

BSIS

その他のテーブル

スプリッタ無しのエクスポート時間

低負荷で非効率 標準的な手法での推定エクスポート時間

スプリッタ無しのエクスポート時間

BSIS

その他のテーブル

同じサーバリソースでも、高い効率でエクスポートすると、劇的に結果が変わる

Unicode Conversion

Non Unicode Database Unicode Database

DDNTT_CONV_UC DDNTF_CONV_UC DDXTT_CONV_UC DDXTF_CONV_UC DDNTT DDNTF DDXTT DDXTF 現行システムが使用する ディクショナリテーブル(Non Unicode) Unicode Conversion 前処理で生成する Export Dump for Unicode Export Dump for Unicode DDNTT DDNTF DDXTT DDXTF Export Convert to unicode and Import

Unicode Conversion前に必ず前処理が必要

本番稼動中に実行可能

Unicode用 ディクショナリ

R3load

R3load

本番稼動中

ダウンタイム

Unicode Conversion実績

エクスポート性能の改良 インポート用DB作成 Unicode Conversion前処理(Unicode用ディクショナリ生成) MIGMON準備

Migration & Unicode Conversion + Upgradeを29時間で引渡し

移行元 移行先 エクスポート インポート＋補足処理 アップグレード 補足処理 SAPのMSCS化 アプリケーションパートナー作業

エクスポートサーバ



マイグレーション時によくある課題

エクスポートダンプ領域の確保

DBサイズの12~18%

数10GBのまとまった領域は無いことが多い

ダンプを随時退避することで回避可能

ただし、作業は煩雑

もっと、エクスポート時間を早くしたい

サーバ能力の限界？

現行本番機の本番稼動中へのログオンは極力回避したい

トランザクション系テーブルへのアクセスはしないけれど．．．

セキュリティポリシー

DBサーバのCPUが振り切ってしまう

DBサーバのCPUが少ない

高速ストレージ

現行本番機への影響を少なくしたい

マイグレーションキット

現行本番機

DBサーバ

エクスポートのアーキテクチャ ‐ １

通常の方法

DB

RDBMS

R3load

Dump File Dump File データ要求 I/Oリクエスト データ読出し データ受渡し 圧縮と ダンプ書出し

新本番機

DBサーバ

Dump File Dump File FTPダウンロード （マニュアル）

DB

RDBMS

R3load

読み込み と展開 Insert or Create Index処理

Insert or Create Index要求

R3loadの圧縮に、CPUリソースが消費される

ディスクが足らないときは、随時削除

エクスポート用サーバ

エクスポートのアーキテクチャ ‐ ２

現行本番機

DBサーバ

エクスポートサーバでの方法

DB

RDBMS

R3load

Dump File Dump File データ要求 I/Oリクエスト データ読出し データ受渡し 圧縮と ダンプ書出し

新本番機

DBサーバ

DB

RDBMS

R3load

読み込み と展開 Insert or Create Index処理

Insert or Create Index要求

CPU能力が高いとダンプの吐き出しが速くなる

エクスポートサーバと新本番機が WindowsならMIGMON net mode

既存APサーバ#2 既存APサーバ#1

エクスポートサーバを使った例

- 1

既存 DBサーバ CPU 100% を維持 R3load R3load R3load 新DBサーバ 新DBサーバへ転送 各APサーバに、マニュアルでバッチを作成して制御 APサーバ#1は、巨大テーブル専用(R3load x 3) R3load R3load R3load APサーバ#2は、DBサーバのCPUが100%になるよう R3loadを発動する(R3load x 4 ~ 8) R3load R/3 4.6B Windows NT Informix 7

680

GB

Windows 2003 Informix 9 DBサーバのみのエクスポート R3load x 6でCPUが 振り切ってしまう R3load Dump File Dump File Dump File Dump File

新本番機DBサーバ Win2Kサーバ 既存UNIX DBサーバ

エクスポートサーバを使った例

- 2

カスタマーサイドで使用していないWindowsサーバ(2CPU * 2.8GHz)を利用 x 15 SAPDB 7 Windows ネットワーク共有 R/3 4.6C UNIX/SAPDB Windows 2003 MSSQL UNIX側に15GBしか無かったダンプ領域の問題を解消(最終的なダンプサイズは41GB) JAVA + Migration Monitor(netモード)で自動エクスポート/インポート

450

GB

Migration Monitor R3load Migration Monitor R3load MSSQL UNIXでエクスポート Dump File Dump File

新本番機MSCS Node B

エクスポートサーバを使った例

- 3

既存UNIX機は2CPUしかない R/3 Enterprise UNIX/Oracle Windows 2003 SQL Server 2005

Unicode Conversion で圧倒的なCPUリソース不足

新本番機のクラスタNode BにOracleクライアント+R3load (4CPUでも振り切る)

新本番機MSCS Node A 既存UNIX DBサーバ Oracle

70

GB

Migration Monitor R3load Migration Monitor R3load MSSQL Dump File Dump File

作業時間

DBサイズ

Upgrade

Migration

Migration & Upgrade

Migrationのダウンタイムを圧縮した実績により．．．

最近の主流は、

Migration + Upgrade

R/3 4.6C

UNIX / Oracle8i

SQL2000

Win2000

Enterprise 4.7

Migration + Upgrade実績

Enterprise 4.7

UNIX / Oracle9i

SQL2005

Win2003

ECC 6.0

R/3 4.6C

UNIX / Oracle9i

Win2003

SQL2005

ECC 6.0

R/3 4.6C

UNIX / DB2

SQL2005

Win2003

ECC 6.0

リアルテックジャパンのサービスメニュー

リアルテックは

_{Migrationに付随する、様々なサービスメニューを展開}

Migration / Upgrade

DBパフォーマンスチューニング

運用

/監視支援

クラスタ／

Disaster構築

アプリケーションの修正

インターフェース改修

ABAPパフォーマンスチューニング

アーカイビング

バックアップ設計／障害復旧支援

データベース再構築

アップグレードアセスメント

さいごに

社内のシステムリソースを有効活用しましょう

マイグレーションは９５％のケースで３日以内をコミット出来ます

マイグレーション＋アップグレードは９８％、４日以内をコミット出来ます

Unicode Conversionの時は、本番稼動時間を協力的に使わせて下さい

データベースの性能は、ストレージ能力を重視してください

ディスクを追加しなくてもよい設計で、導入することをお勧めします

CPUは、追加出来る設計で導入することをお勧めします

リアルテックは高効率な方法で、ダウンタイム圧縮を目指します

リアルテックは様々なサポートで、スムーズなプロジェクト進行を目指します