この記事で分かること
- SPDD（ディクショナリオブジェクトのモディフィケーション調整）の基本パターン
- PARCONV_UPGフェーズでテーブル変換が発生する条件とメカニズム
- 本番機でのみ処理時間が増大する理由
- インデックス再作成を後ろ倒しにするという考え方
SAPアップグレードにおいて、ダウンタイムの大きな変動要素となるのが「PARCONV_UPG」フェーズでのテーブル変換です。テーブル変換は、本番機の膨大なデータ量に比例して処理時間が長引き、想定外のダウンタイム増大を引き起こします。本記事では、変換の前段にあたるSPDD調整の基本パターンを整理したうえで、テーブル変換が発生する条件、本番機特有の遅延理由、そしてインデックス再作成を後ろ倒しにするという考え方を解説します。対象テーブルのデータ量から影響範囲を見極めることが、アップグレード計画の精度を高める鍵です。
※本記事のダウンタイムは、ハードウェアリプレースを伴うアップグレード（現行機の停止 → 新環境へのシステムコピー → 新環境でのSUM実行 → ポストプロセス → 稼働開始）を想定し、業務が停止している期間全体を指します。
モディフィケーション調整「SPDD」の4つの基本パターン
SAPシステムのアップグレードやサポートパッケージ適用において、既存のカスタマイズ（モディフィケーション）と新しいSAP標準オブジェクトの競合を解消する作業が不可欠です。このうち、テーブルやデータエレメントといったABAPディクショナリオブジェクト（標準オブジェクトへの直接変更）の調整を担うのが、トランザクション「SPDD」です。
SPDDでの対応方針は、お客様の要件と新バージョンの標準仕様との関係性から、大きく4つの基本パターンに分類されます。ここで適切な方針を選択することが、後続のテーブル変換処理におけるダウンタイム増大やデータ消失リスクを回避するための前提条件となります。
パターン1：SAP標準へのリターン（オリジナルへのリセット）
これまで適用していた独自のモディフィケーションを破棄し、新しいバージョンのSAP標準仕様を採用するパターンです。
新バージョンで標準機能が拡充され、カスタマイズなしで業務要件を満たせるようになった場合や、過去の変更がすでに不要となっている場合に選択します。標準仕様へ戻すことでシステムの保守性が大幅に向上し、将来的なアップグレード時の検証工数を削減できます。
パターン2：モディフィケーションの保持（変更の適用）
自社固有の業務プロセスを維持するために、新バージョンにおいても引き続き独自の変更を残すパターンです。
このパターンを選択する場合、SAP標準の新しいテーブル構造とお客様の変更内容を統合する必要があります。特に、標準テーブルの中間に項目を挿入するような変更を行っている場合、後続のフェーズで大規模なテーブル変換が発生する要因となります。そのため、モディフィケーションの保持は必要最小限に留めることが推奨されます。
パターン3：自動調整
標準オブジェクトへのモディフィケーションのうち、新旧の定義差をシステムが解析し、旧変更を新しい標準定義へ自動的に引き継げると判定したものが、自動調整の対象となります。開発者による手動介入が不要となるため、SPDDフェーズの作業工数を抑えることができます。
パターン4：マニュアル調整
複雑な変更が加えられており、システムによる自動調整が不可能で、開発者が手動でディクショナリを修正しなければならないパターンです。
新旧の構造を詳細に比較し、データの不整合が発生しないよう慎重に定義を修正する必要があります。この作業には、ABAPディクショナリに関する深い知識と業務要件の正確な理解が求められます。マニュアル調整の対象が多いほど、プロジェクトのスケジュールや工数に甚大な影響を及ぼします。
SPDD調整パターンの比較と影響度
これら4つの基本パターンが、アップグレード時の作業工数やダウンタイムリスクにどのような影響を与えるかを整理すると、下表のとおりです。
| 調整パターン | 作業工数 | ダウンタイムへの影響リスク | 今後の保守性 |
|---|---|---|---|
| SAP標準へのリターン | 小 | 低 | 高 |
| モディフィケーションの保持 | 中 | 高（テーブル変換発生の可能性） | 低 |
| 自動調整 | 極小 | 低 | 高 |
| マニュアル調整 | 大 | 高（作業ミスによる不整合リスク） | 低 |
なお、SPDDの調整は、開発機で一度実施して移送依頼として記録しておき、以降の検証機・本番機ではその移送をSUMの処理に取り込むことで、各環境での対応時間を短縮するのが一般的な進め方です。これはアップグレードにおける定石であり、移送を環境間で持ち回ることで、本番環境でのSPDD作業そのものを最小化できます。
SPDDフェーズでは、システム上に提示された対象オブジェクトを1つずつ確認し、上記のどのパターンに該当するかを見極める必要があります。この判断を誤ると、後続のフェーズで予期せぬ長時間の処理が発生するため、事前の影響調査と方針決定が極めて重要です。
ダウンタイム直撃のフェーズ：PARCONV_UPGのメカニズム
SAPシステムのアップグレードやサポートパッケージ適用において、ダウンタイムの長さを左右する最大の要因の一つが「PARCONV_UPG」フェーズです。新旧リリース間で生じたディクショナリ定義の変更を、実際のデータベース上のテーブル構造へ反映させるための処理がここで行われます。反映の対象となるのは、SAPが標準で提供するテーブル定義の変更（標準テーブルへの項目追加や型変更など）が中心であり、SPDDで保持したモディフィケーションによる構造差は、そこに上乗せされる要素の一つです。
PARCONV_UPGとは何か
SUM（Software Update Manager）ツールを用いたアップグレードプロセスにおいて、PARCONV_UPGはデータベーステーブルの変換（コンバージョン）を並行処理で実行するフェーズを指します。標準テーブルの項目追加やデータ型の変更、あるいはSPDDでのモディフィケーション調整の結果、既存のテーブル構造と新しいテーブル構造に差異が生じた場合に、この変換処理がトリガーされます。
テーブル変換がトリガーされる主な条件
すべてのテーブル変更が物理的な変換を伴うわけではありません。データベースの機能で対応可能な項目の追加（テーブル末尾への新規項目追加など）であれば、変換処理は不要です。しかし、以下のような変更が発生した場合には、PARCONV_UPGフェーズでの物理的なテーブル変換が避けられません。
- 既存項目のデータ型（文字型から数値型など）の変更
- 既存項目の桁数や長さの縮小
- テーブルのキー項目の追加、削除、または順序の変更
テーブル変換の5つのステップ
テーブル変換は、単なる定義の変更ではなく、データベースレベルでの物理的なデータ再配置を伴います。具体的な処理のメカニズムは、下表のとおりです。
| ステップ | 処理内容 | システムへの影響 |
|---|---|---|
| ステップ1 | 元テーブルのリネーム（QCMテーブル化） | 既存の元テーブルが、旧データを保持したままQCM＊という名前にリネームされます。 |
| ステップ2 | 新構造テーブル（QCM8テーブル）の作成 | 新しい構造を持つテーブルがQCM8＊という名前で作成されます。 |
| ステップ3 | データのコピー | QCMテーブル（旧データ）からQCM8テーブル（新構造）へ、全レコードがコピーされます。 |
| ステップ4 | 新テーブルのリネームと旧テーブルの削除 | QCM8テーブルを元のテーブル名にリネームし、コピー成功後にQCMテーブルを削除します。 |
| ステップ5 | インデックスの再作成 | テーブルに紐づく二次インデックスなどが再構築されます。 |
データ量とダウンタイムの関係
このメカニズムからわかるように、ステップ3の「データのコピー」およびステップ5の「インデックスの再作成」は、対象テーブルに格納されているレコード数やデータサイズにほぼ比例して処理時間が増大します。数千万から数億レコードを抱えるトランザクションテーブルが変換対象となった場合、このフェーズだけで数時間から数十時間のダウンタイムが発生するリスクがあります。
とくに、大規模なエンハンスメントパッケージの適用時や、モディフィケーションが多数含まれる環境では、影響を受けるテーブル数が多くなる傾向にあります。PARCONV_UPGフェーズの処理時間を正確に見積もることが、アップグレードプロジェクト全体の成否を分けると言っても過言ではありません。
なぜ「本番機」でだけ処理時間が爆発するのか？
開発機や検証機でのアップグレードが予定通りに完了したにもかかわらず、本番機で予期せぬ長時間のダウンタイムが発生するケースは珍しくありません。その最大の原因は、各環境における圧倒的なデータ量の差にあります。
PARCONV_UPGフェーズで発生するデータベース処理
SAPのアップグレードツールであるSUM（Software Update Manager）のPARCONV_UPGフェーズでは、ターゲットリリースに合わせてアプリケーションテーブルの構造が調整されます。
SPDDで標準テーブルにモディフィケーション（項目の追加やデータ型の変更など）が加えられている場合、データベースレベルで大規模な再編成が発生します。具体的には、以下のような処理が実行されます。
- 既存データの退避（QCMテーブルへのリネーム）
- 新構造テーブル（QCM8）の作成
- 退避したデータの再挿入（QCM→QCM8へのコピー）
- インデックスの再作成
これらの処理にかかる時間は、テーブルに格納されているレコード数やデータサイズにほぼ比例します。
開発機・検証機と本番機の環境比較
各環境におけるデータ量と処理時間の影響を比較すると、下表のとおりです。
| 環境 | データ量の傾向 | PARCONV_UPGの処理時間 |
|---|---|---|
| 開発機（DEV） | カスタマイズデータのみで非常に少ない | ごく短時間で完了する傾向 |
| 検証機（QAS） | テスト用のサンプリングデータのみ | 本番機より短く完了する傾向 |
| 本番機（PRD） | 長期間蓄積された本番業務データ（1億件規模になることも） | データ量に応じて長時間に及ぶことがある |
巨大テーブルにおけるインデックス作成の負荷
特に本番機で問題となるのが、巨大なテーブルに対するインデックスの再作成です。たとえば、明細系のトランザクションテーブル（購買・在庫管理の明細テーブルや管理会計の実績明細テーブルなど）は、本番稼働期間が長くなるほどデータが肥大化します。数千万から数億レコードを抱える透過テーブルに対して新しいインデックスを作成しようとすると、このフェーズだけで処理時間が大きく増大します。
インデックス再作成を後ろ倒しにするという考え方
PARCONV_UPGフェーズの処理時間の多くは、テーブル変換に伴うインデックスの再構築が占めます。そこで、業務再開に必須ではない二次インデックスの作成を、システム稼働後のバックグラウンド処理に回すという考え方があります。インデックス再構築をダウンタイムのクリティカルパスから外すことで、システムを早期に業務へ開放できる可能性があります。
インデックス再作成がダウンタイムを圧迫する理由
テーブルの構造変更（DDICの変更）が発生すると、データベース上では既存のテーブルが変換され、それに付随する二次インデックスもすべて再作成されます。数億件のレコードを持つ巨大なトランザクションテーブルの場合、このインデックス作成だけで数時間を要することも珍しくありません。ダウンタイム中にすべてのインデックスを同期的に作成しようとすると、システム切り替えのタイムリミットに間に合わなくなるリスクが高まります。
この考え方を適用する際の注意点
このテクニックはダウンタイム削減に絶大な効果を発揮しますが、システム稼働後のパフォーマンスに影響を与える可能性があるため、以下の点に注意して適用を判断する必要があります。
- インデックスが未作成の状態で該当テーブルに対する大量の検索処理が走ると、フルスキャンが発生しシステム全体のパフォーマンスが低下する恐れがある
- 業務再開直後にバッチ処理などが集中する場合、バックグラウンドでのインデックス作成処理とリソースを競合する可能性がある
- 必須の一次インデックス（プライマリキー）は後ろ倒しにできず、必ずダウンタイム中に作成される
そのため、後ろ倒しの対象は「データ量は多いが、業務再開直後には頻繁に検索されないテーブルの二次インデックス」に限定するなど、対象の見極めには高度な専門的判断が求められます。具体的な実現方法はシステム構成やDBプラットフォームによって異なり、関連するSAP Noteの確認と十分な検討を要するため、適用を検討する場合はSAPの公式情報を確認のうえ、経験豊富な技術者のもとで進めることを推奨します。事前のリハーサル環境で、インデックスを後ろ倒しにした場合の業務影響を必ず検証しておくことが前提となります。
テーブル変換とダウンタイムに関するよくある質問
SPDDの調整はスキップできますか？
標準オブジェクトを変更している場合、SPDDの調整は必須です。なお、開発機で調整して移送依頼を取得しておけば、検証機・本番機ではその移送をSUM処理に取り込むことで、各環境での作業時間を短縮できます。
PARCONV_UPGの処理時間は事前に予測できますか？
変換対象となるテーブルと、その本番機でのデータ量を事前に洗い出し、検証機での実測と突き合わせることで、ある程度の見積もりが可能です。ただしデータ量・行長・インデックス構成によって変動します。
インデックスの再作成はいつ行うべきですか？
業務再開に必須でない二次インデックスは、稼働後のバックグラウンド処理に回すことでダウンタイムを短縮できる場合があります。ただし対象の見極めには専門的な判断が必要で、必ず事前検証を行ってください。
まとめ：テーブル変換の影響範囲は「データ量」から見極める
SAPアップグレードにおいてダウンタイムの増大を防ぐためには、PARCONV_UPGフェーズでテーブル変換が発生するかどうかを事前に把握し、変換対象テーブルのデータ量から影響範囲を見極めて計画を立てることが重要です。その前段として、SPDD調整では不要なモディフィケーションを標準へ戻し、変換の発生そのものを抑えることが効果的です。事前のデータ量把握と適切な方針決定が、プロジェクト成功の鍵を握ります。
当社はSAPのスペシャリストとして、豊富な知見と実績をもとに、最適なソリューションをご提案します。SAPに関するご相談やお見積りのご依頼は、ぜひお気軽にリアルテックジャパンにお問い合わせください。
関連記事はこちら
第1回：SAPアップグレードのダウンタイムを決定する5つの主要因｜エキスパートが教える「単純計算できない」実態
第2回：SAPアップグレードのダウンタイムを左右するハードウェア性能｜CPU並列数とR3transの最適解
