およびドキュメントの生成。
はじめに
Oracleデータベースの新バージョンへの移行は複雑なプロジェクトです。ここでは単にデータを移行するだけでなく、大量のPL/SQLコードを新バージョンに適応させ、時間の経過とともに蓄積された時代遅れの要素を一掃し、リグレッションの発生を防ぐ必要があります。
Visual Expertは、静的PL/SQLコード解析ツールとして、既存コードの多角的調査、理解、文書化に優れており、Oracleデータベースの移行を大幅に効率化できます。
この記事では、Oracleデータベース移行の典型的なステップを取り上げ、それぞれのステップで遭遇する課題と、Visual Expertがどのようにそれを克服するのに役立つかを説明します。
このドキュメントでは、主にPL/SQLコードを含むOracle 11gデータベースをOracle 19c（または21c）に移行するケースを例として取り上げます。
ステップ1：コード/オブジェクト量の評価
目的：移行プロジェクトの最初のステップは、コードの分析範囲を明確に設定し、すべてのPL/SQLコード（パッケージ、プロシジャー、ファンクション、トリガー）、およびすべてのデータベース オブジェクト（テーブル、ビュー、インデックス...）を見積る必要があります。このボリュームの見積もりは、作業負荷と必要なリソースの計画に使用されます。
Oracleデータベースには、何千ものオブジェクトと何百万行ものコードが含まれることがあり、手作業でOracleカタログやPL/SQLコードを調べる事は、面倒で間違いを起こし易い時間のかかる作業を強いる事になります。アーキテクトやプロジェクト マネージャーにとって必要なグローバルビューを得る事ができます。
Visual Expertソリューション
Visual Expertを使用する事で、アーキテクトやプロジェクト マネージャーにとって必要なグローバルビューを得る事ができます。
- PL/SQLコードの総行数（コメントと実際の命令数）、プロシジャーとファンクションの数、パッケージの数、トリガーの数など、詳細なコード メトリクスを提供します。
- データモデルの複雑さを把握できるエンティティ リレーションシップ ダイアグラム（ER図）を生成できます。アーキテクトは、モデルのどの部分が移行に最も重要かを判断できます（高密度領域は、多くの場合、関連するロジックが多いことを意味します）。
ステップ2：コードのクリーンアップ
目的：未使用項目を排除して技術的負債とリスクを削減します。
移行する前に、呼び出されなくなった古いプロシジャー、忘れ去られたテンポラリテーブルやテストテーブル、時代遅れのビューやシノニムなど、既に使用されなくなったコード/オブジェクトを整理/削除して技術的負債とリスクを削減します。
既に使用されなくなった要素を移行することは、無駄に時間を費やしリスクを増大させます。しかし、手作業で未使用のオブジェクトを検出することは、大規模データベースでは非常に困難な作業です。開発者は、隠れた機能が壊れることを恐れてコードの削除に消極的で、予防措置としてすべてを移行するケースが見受けられます。
Visual Expertソリューション
Visual Expert は、Oracle データベース内の*「デッドコード*」をリストアップでき、この作業を手助けできます。これらの情報により、チームは Oracle 19c に移行しないオブジェクトを決定し、不要な要素を排除できます。
- 依存関係の完全な静的解析により、潜在的に使用されていないPL/SQLオブジェクト（他のプロシジャー、トリガー、または既知の外部アプリケーションによって参照/呼び出されることのないオブジェクト）を特定できます。
- また、使用されたことのないテーブル（SELECT/INSERT/UPDATE/DELETEステートメントで参照されないテーブル）を発見できます。
- 最後に、空のプロシジャー、統合すべき重複コードなど、クリーンアップすべき他の要素も識別してリストします。
詳細を読む：
ステップ3：サポートされなくなったコンポーネントの特定
目的：データベース移行のターゲット バージョンで非推奨、またはサポートされなくなったコード/オブジェクトを特定します。
Oracleは時間の経過と共に、特定の機能を非推奨にして新しい機能を導入します。例えば、DBMS_JOBファンクションはDBMS_SCHEDULERに置き換えられ推奨されなくなりました。また、LONGなどの特定のデータ型は廃止され、CLOB/BLOBが使用されるようになりました。
そのため、移行後のシステムではこの様なレガシー技術やサポートされていない技術が残らないように、これらの要素を置き換える必要があります。
難しいのは、データベース スキーマとコード内で、これらの廃止された要素を使用している箇所をすべて体系的に検出することです。例えば、技術的な表にLONG型の列が隠れている場合などは容易に見落とされてしまう可能性があります。そのため、開発者とDBAは、必要な置き換えを計画するために、徹底的な検出を行う必要があります。手動で数千行ものコードをスキャンしたり、Oracleディクショナリーを参照したりすることは現実的な解決策ではありません。
Visual Expertソリューション
詳細な依存関係分析
Visual Expertは、詳細な依存関係分析およびコード検査機能により、この様な作業を劇的に効率化できます。
- Oracle ファンクション、パッケージ、サブプログラムなど、廃止されたオブジェクトを参照するすべてのプロシジャー、トリガー、ファンクション、パッケージ、サブプログラム、および型をリストアップできます。
- LONGやDBMS_XMLGENパッケージなど、非推奨のデータ型に基づいてテーブルやカラムをリストアップできます。
- Visual Expertにはコード検査機能が実装されており、廃止された要素の使用を警告するルールがあります。
Visual Expertは互換性スキャナとして機能し、ベストプラクティスに従って既存のコードを精査し、テスト時の不快な驚きを避けます。
また、データをモデリングすることで、Visual Expertは古いデザインを識別し、Oracleによって提供される改善を利用する手助けになります。例えば
- 一部のテーブルでは、一意のシーケンス/ID 識別子の代わりに複合識別子を使用します。
- 一部のリレーションは、従来は制約によって宣言されず、コードによって処理されていました。
- 非常に長くて関連のないテキスト フィールドは CLOB に変換できるかも?
このように、Visual Expert は、コードの変更に加え、構造的な変更について考える材料を提供します。ダイアグラムには、計画された変更（新しい関係、新しいタイプ）を注釈として加えることができます。これらの要素は、次の段階の影響分析で使用されます。
ステップ4：変更の影響分析
目的：リグレッションを避けるために、変更のすべての結果を予測します。
置き換えるファンクション、変更するカラムなど、変更すべき内容が決まったら、影響分析により**その変更がどこに影響するかを**評価する必要があります。
- 例えば、廃止されたファンクションを置き換えるということは、そのファンクションを呼び出すすべての手続きのコードを修正することを意味します。しかし、これらのプロシジャーは他の場所でも呼び出される可能性があります。これらすべての変更の結果をチェックする必要があります。
- 同様に、LONGカラムをCLOBに変更するには、このカラムを参照するプロシジャーを変更し、上流/下流のコンポーネント（ビュー、インターフェースなど）をチェックする必要があります。
Visual Expertソリューション
Visual Expert は、インタラクティブな影響分析によって、「X を変更するとどうなるか」といった質問に回答できます。
オブジェクト（ファンクションやカラムなど）を選択して影響度分析を実行すると、Visual Expert は**そのオブジェクトを参照するすべてのオブジェクトを**一覧表示します。
Visual Expert は、E/R ダイアグラムやマトリックスの形で依存関係を表現できます。
例えば、CRUDマトリックスは、データとそれを操作する関数を相互参照し、各手順で実行される操作の種類（作成/読み取り/更新/削除）を指定します。
Visual Expert は、手作業で何時間もかかる作業を数秒で実行します。これにより、チームは各変更の準備（必要な時間の見積もり、変更するオブジェクトのリスト作成）を迅速に行うことができ、また、隠れた依存関係が無視されることがないため、見落としのリスクも排除されます。
ステップ5：コード変更の実施
目的：このステップでは、コード変更を安全に適用します。
分析フェーズの後にはコード変更フェーズ (コードのリファクタリング、スキーマの変更) が続きます。Visual Expertは解析ツールであり、編集ツールではありません。そのため、コード変更は開発者が通常使用するコード エディターで行なう必要があります。とはいえ、Visual Expertは以下の点で実装時に役立ちます。
Visual Expertソリューション
変更追跡ダッシュボード
チームはコード変更の各フェーズで、コード変更履歴を追跡するためのダッシュボードとしてVisual Expertの比較機能を使用できます。コード変更後、新しいコードを分析して、コード変更が正しく行われたか？ 古い要素が残っていないか？ を確認できます。
コードとスキーマの比較
Visual Expert は、初期スキーマと移行後のスキーマを比較するコード/スキーマ比較機能を提供しています。コード変更後にそのプロジェクトのコード解析を実行すると、新しいコード解析バージョンが作成され、このバージョンをその前のバージョンと比較すると、変更（追加、変更、削除）された箇所が色別に識別されます。
ステップ6：移行したデータベースのドキュメント作成
目的：完全で最新の使用可能なドキュメントを自動生成します。
移行完了後は、最新のドキュメントを作成する必要があります。これは、メンテナンスのための備品目録としても、変更内容の記録としても役立ちます。
しかし、回路図や数千行に及ぶコードを手作業でドキュメント化するのは、時間がかかり、ミスが起こりやすく現実的ではありません。そのため、ドキュメント作成の自動化が不可欠です。
デフォルトでは、ドキュメントは以下の内容で構成される必要があります。
- データベース構造（図表、ダイアグラム）
- データディクショナリ（カラム、データ型）
- PL/SQLコード（モジュール、パラメータ、呼び出しのリストと説明）
- 移行前後の比較（可能な場合）
Visual Expertソリューション
Visual Expertは、アプリケーションの詳細な説明を含むHTMLページで構成したドキュメントを自動的に生成できます。
- 各パッケージ／プロシジャー／トリガーについて、フォーマットされたソースコード、パラメータリスト、説明、および参照情報（例：「このプロシジャーはこのようなテーブルを呼び出します。また、このプロシジャーはこのような他のオブジェクトによって呼び出されます...」など）を表示します。これらの参照情報はドキュメント内でクリック可能なハイパーリンクとして表示され、Webサイトのようにナビゲートできます。
- 特定のレポートも生成できます。たとえば、移行中に変更されたすべてのオブジェクトとその新しいステータスのリストや、コンポーネント間の相互作用を示す CRUD マトリックスまたはコール ダイアグラムなどです。
データモデルドキュメントとビジネスロジック
Visual Expertは、マイグレーション後のデータモデルドキュメント作成にも役立ちます。
- 移行後のシステム全体のER図を作成します。
- このER図は、例えば、機能領域（請求、顧客管理など）ごとに複数のテーマ別に分割して、より分かりやすく表示できます。
- ER図の完成後、PDF または高解像度画像としてエクスポートし、最終的なドキュメントに統合できます。
コードの説明とコメント作成にAI機能を活用
技術ドキュメントを超えて、Visual Expertは以下もできます：
- コードのビジネス目的を説明する。
- その内部ロジックを説明する。
- コメントを生成する。
Visual Expertは、データモデルの概要、詳細なコードドキュメント、そして機能説明を組み合わせることで、データベースのあらゆる側面を網羅できます。また、Visual Expertにより作業は最小限に抑えられ、チームに負担をかけることなく、プロジェクト全体の品質を向上できます。
ステップ7：データベース移行後の最適化
目的：移行したデータベースのパフォーマンスと保守性を向上させます。
上位バージョンに移行することで、思わぬ問題が見つかることもあります。移行はまた、以前のバージョンでは対処できなかったパフォーマンス上の問題（インデックスの欠落、クエリの遅さなど）に対処する機会でもあります。移行後のこれらの作業は、時間がないために見過ごされることがあります。
Visual Expertソリューション
パフォーマンス分析
Visual Expertには、OracleのDBモニタリング ツールによって生成された実行統計情報をソースコードと一緒に分析して、パフォーマンス改善を支援するコード パフォーマンス機能が実装されています。これらの移行後の問題を修正することで、データベースのパフォーマンスと保守性が向上します。
コード品質と最適化
- Visual Expert はコードの品質もチェックし、パフォーマンスに影響を与える特定の悪い習慣 (SQL 結合の代わりに PL/SQL でネストされたループを使用するなど) を検出します。
- SQLクエリの実行を不必要に遅くしている欠落インデックス（SQL クエリの Where/Group by/Order by/Having 句で使用されているインデックスのないデータベース カラム）を検出できます。
- 最後に、Visual Expert は、検出された遅いクエリを分析するために使用できます。DBA はクエリ実行プランを表示し、Oracle による処理方法（インデックストラバーサル、完全スキャン、ハッシュ結合、ソートなど）を確認できます。これにより、分析から SQL 最適化のためのアクションへと迅速に移行できます。
- オブジェクトまたはクエリによってアプリケーションの速度が低下する場合、Visual Expert はコードを最適化できます。また、Visual Expert はAIの活用により、パフォーマンスの改善を提案できます。
これらの機能を組み合わせることで、全体的な予防的アプローチの一環として、あるいは特定のボトルネックを具体的に排除するために、アプリケーションのパフォーマンスを向上させることができます。
Visual Expert を使用すると、移行前後のパフォーマンスを測定し、行った最適化の実際の影響を評価することもできます。
ステップ8：移行後の継続的モニタリング
目的：長期にわたって PL/SQL コードの品質とパフォーマンスを維持します。
移行が完了したら、技術的なメリットを維持することが不可欠です。Visual Expert は、Oracle スキーマと PL/SQL コードの長期的な進化の確保、文書化、および管理を支援します。
これらの移行後の最適化は、時間がないために見過ごされることがあります。そのため、最も緊急なものを特定する必要があります：何百ものクエリとプロシジャーのうち、最初に最適化すべきものはどれでしょうか？
Visual Expertソリューション
積極的メンテナンス
- 変更前の体系的な影響分析；
Oracle データベースと PL/SQL コードの重要な変更を行う前に、影響度分析を体系的に実施することを推奨します。この実施により、依存関係を包括的に考慮し、リグレッション リスクを最小限に抑えることができます。 - 定期的な性能チェック；
プロシジャーやSQLクエリの実行時間を監視することで、新たな問題を検出でき迅速に対処することができます。例えば、パフォーマンスの低下を避けるために新しいインデックスの作成が必要となるようなクエリの修正後に、このような問題が発生する可能性があります。Visual Expert は、このようなケースを検出して DBA に報告し、DBA は必要な対策を講じることができます。
品質管理と問題解決
- コードの品質とセキュリティの定期的な検証；
Visual Expertは、自動的かつ定期的にコードを検査し、品質やセキュリティの問題の兆候を検出することができます。例えば、チームが習慣的に非推奨のOracleデータ型やファンクションを使用している可能性があります。このように定期的に管理することで、長期にわたって高いレベルの品質とセキュリティを維持することができます。 - コード内に見つかった問題の修正 ；
コード内で発見された各問題に対して、Visual Expertは潜在的な解決策を提案できます。 - スキーマとコード変更の追跡を文書化；
Visual Expertは、スキーマとPL/SQLコードに加えられたすべての変更を追跡し、バージョン管理と変更のトレーサビリティを大幅に簡素化します。
自動コード検査概要
このような継続的な監視によりメンテナンス コストが削減され、将来の進化が保証されるため、チームは移行後の機能改善にさらに集中できるようになります。
結論
Oracle 11gデータベースから19c/21cへの移行は複雑なプロジェクトですが、適切なツールを使用すれば大幅に簡素化できます。Visual Expertを使用すると、開発チームと管理チームは、コード分析、スキーマ管理、モデリング、ドキュメント作成を網羅した包括的なツールボックスにアクセスできます。
移行プロセスのすべての段階（範囲の正確な特定、クリーンアップ、新機能への適応、変更の制御、技術ドキュメント、継続的な最適化）が容易になります。
Visual Expertは、最初の移行後も、定期的な影響分析、パフォーマンスチェック、定期的なコード品質管理など、充実したサポートを提供し続けます。これらの機能により、Oracleデータベースの長期的な安定性、品質、パフォーマンスが保証され、移行プロジェクトに対する持続可能な投資収益率が確保されます。
Visual Expert をコード編集ツールと組み合わせ、プロジェクト ステップを厳密に管理することで、技術チームはリスクを軽減し、開発を安全にし、Oracle データベースの将来の保守性を促進しながら、大規模な移行を成功させることができます。
ステージ別概要表
| プロジェクト ステージ | Visual Expertの機能 |
|---|---|
| 1.ボリュームの評価 | - メトリクス（コード行数、オブジェクト数）の計算 - オブジェクトタイプ別のインベントリ - アプリケーション資産の概要 - ER図（データモデル）の自動生成 - 複雑な領域や孤立した領域の視覚的な分析 |
| 2. コードのクリーニング | - 未使用オブジェクト（参照されていないオブジェクト）の特定 - コードからアクセスされていないテーブルの特定 - 重複したコード、空のコード、冗長なコードの検出 |
| 3. サポートされなくなったコンポーネントの特定 | - 廃止されたファンクション/型の使用をチェック - コード解析ルールによる警告 - 最新化すべきオブジェクトの自動識別 - ERモデルの分析による設計の古さの特定 - 進化を定義するためのモデル注釈 |
| 4. 影響分析 | - インタラクティブな影響分析（誰が要素を使用しているか？） - CRUDマトリックス（誰がどのテーブルに読み取り/書き込みを行っているか？） - 呼び出し図と相互参照図 |
| 5. 変更の実装 | - 変更後の検証（すべてのポイントを網羅） - 移行前後のスキーマ／コードの比較 |
| 6. 技術ドキュメント |
- コードドキュメントの自動生成 - CRUDマトリックスの生成 - コール ダイアグラムの生成 - 移行後のドキュメント用ER図の更新 - データ モデルのサブダイアグラムのエクスポートと作成 |
| 7.データベース移行後の最適化 | - コードパフォーマンス分析（平均時間、頻度） - 関数呼び出し文字列の分析- 欠落インデックスの検出 - SQLクエリの分析とチューニング（実行プラン） - 最適化を反映したモデルの更新 |
| 8 - 移行後の継続的モニタリング | - 変更前の体系的な影響分析 - 定期的なパフォーマンス チェック - 定期的な品質チェック - スキーマとコードの進化に関するドキュメンテーション |
Oracle非推奨およびサポート対象外機能
最近のバージョンで非推奨または削除されたOracle機能について情報を維持します。移行プロジェクト中に必要な変更を予測するためにこのリストを使用してください。