独立したモジュールで並行して実行可能な再編成コードを生成します。これにより、マルチプロセッサーのサーバーにおける再編成のパフォーマンスを劇的に向上できます。
再編成をパーティション分割するため、GeneXus は個別に実行できるコードブロックを識別しており、再編成ではこのコードブロックを個別のスレッドで実行します。これを行うために再編成プロセスを再設計した結果、コードが非常に読みやすくなりました。特に、テーブルを再編成するために必要な手順が見やすくなっています。
Informix の注意: この機能は Informix 以外の GeneXus の DBMS すべてに対応しています。Informix では ANSI データベースで制限があり、Autocommit に対応していません。Autocommit はマルチスレッドでの実行において、各 URL が使用する接続を管理してデッドロックを回避するのに必要です。
並行スレッド数の変更: 既定では、再編成は 5 つの並行スレッドで実行されます。プロセッサの数によって、この設定を変更する必要があります。reorg.cfg (Java) の SUBMIT_POOL_SIZE または client.exe.config (.NET) の REORG_MAX_THREADS を変更します。
SQL 文および構文は、最大限の効率性を確保する目的において、ターゲットの DBMS および DBMS バージョンに依存します。
データ変換のために一時テーブルを使用するケースは少なく、サーバーおよびクライアント間のデータのやりとりも最小限となっており、可能であれば ALTER TABLE コマンドを使用しています。
1) SQL サーバー内のテーブルに NOT NULL の列を追加すると、2 つの文を実行します。例では、CustomerEmail の null 不可の列を [ Customer ] テーブルに追加する方法を示しています。
ALTER TABLE [ CUSTOMER ] ADD [ CustomerEmail ] varchar(40) NOT NULL CONSTRAINT CustomerEmail_DEFAULT DEFAULT ' '
ALTER TABLE [ CUSTOMER ] DROP CONSTRAINT CustomerEmail_DEFAULT
2) NOT NULL 項目属性が格納されているテーブルを変更するには、3 つの文が必要です。例では、CustomerEmail 項目属性を [ Invoice ] テーブルから [ Customer ] テーブルに移動させる方法を示しています。
ALTER TABLE [ CUSTOMER ] ADD [ CustomerEmail ] varchar(40) NOT NULL CONSTRAINT CustomerEmail_DEFAULT DEFAULT ''
UPDATE [ CUSTOMER ] SET [ CustomerEmail ] = T. [ CustomerEmail ] FROM
(SELECT [ CustomerEmail ] , [ CustomerId ] FROM [ INVOICE ] ) T WHERE [ CUSTOMER ] .CustomerId = T.CustomerId
ALTER TABLE [ CUSTOMER ] DROP CONSTRAINT CustomerEmail_DEFAULT
3) 初期値に IIF() を使用して新しい列を追加すると、3 つの文を実行します。例では、初期値 = iif(ProductPrice > 1000, "Category 1", "Category 2") の ProductCategory 項目属性を [ PRODUCT ] テーブルに追加して再編成を解決します。
ALTER TABLE [ Product ] ADD [ ProductCategory ] char(20) NOT NULL CONSTRAINT ProductCategoryProduct_DEFAULT DEFAULT ''
UPDATE [ Product ] SET [ ProductCategory ] =T. [ ProductCategory ] FROM
(SELECT [ ProductId ] , CASE WHEN [ ProductPrice ] > 1000 THEN 'Category 1' ELSE 'Category 2' END AS ProductCategory
FROM [ Product ] ) T
WHERE [ Product ] .ProductId= T.ProductId
ALTER TABLE [ Product ] DROP CONSTRAINT ProductCategoryProduct_DEFAULT
パフォーマンスを向上させ、一時テーブルを回避するため、手動で行った変更をテーブルの定義で維持します。たとえば、テーブルに権限を追加すると、一時テーブルを使用する場合にテーブルが削除および再作成され、セキュリティ設定がすべて失われます。一時テーブルを使用しないためにテーブルの削除を行わない場合は、設定は失われません。
影響分析レポートとともに、データベースで実行する SQL 文を見ることができます。これにより、各テーブルを再編成するために GeneXus が実行する内容を理解できます。実行順にすべての再編成の文が含まれるスクリプト (ReorganizationScript.txt) をモデルディレクトリーに作成します。GeneXus はこのスクリプトを実行しません。これはドキュメンテーションのためだけに作成します。
既定の再編成プロセスにおける最初の手順の 1 つは、再編成する各テーブルのレコード数を数えて表示することです。また、レコードを数えるためだけに再編成プログラムを実行することもできます。-recordcount パラメーターを設定して再編成プログラムを実行すると、テーブルすべてのレコードを数え、結果を表示して停止します。再編成の所要時間を推測するのに使用できます。
-recordcount パラメーターおよび、このドキュメントで説明するほかの多くの再編成オプションは、GeneXus の [ ビルドプロセス ] - [ 詳細 ] - [ 再編成 ] オプションのモデル設定で設定できます。既定ではこのオプションは -nogui の値が設定されています。
再編成の前後で SQL 文を実行する必要がある場合があります。たとえば、バックアッププロセスを実行し、再編成前にサイズの大きいテーブルを切り捨て、再編成後にデータを復元する場合があります。
再編成プロセスが、再編成プログラムと同じ (現在の) ディレクトリーで beforeReorganizationScript.txt という名前のファイルを見つけた場合、再編成前にファイルの SQL 文を実行します。afterReorganizationScript.txt というファイルがある場合も同じであり、再編成プロセス後にこれを実行します。
どちらのファイルも SQL 文のみを記載します。SQL 文は次のスクリプト例のように、セミコロン (;) で区切ります:
TRUNCATE TABLE [ FirstBigTable ] ;
TRUNCATE TABLE [ SecondBigTable ] ;
再編成プロセスが失敗する理由はいくつかあります。電源の停止、ディスク領域や権限の不足などが一般的な原因の例です。多くの場合はデータベースを復旧する必要はなく、問題が解決すれば (電源の復旧を待つ、ディスク領域を空ける、権限を与えるなど) 障害発生箇所から再開します。この場合、時間や作業の負荷を最低限に抑えられます。
再編成プロセスには、障害後の再開機能がビルトインされています。つまり、障害後に実行を開始すると、既に完了している手順をスキップして前回の実行時に失敗した手順の実行を開始します。その結果、再編成の障害からの復帰が容易になります。問題を解決して再編成を再開すればよいだけです。障害後の再開機能には、事前/事後再編成スクリプトの文を含む点に注意してください。たとえば、再編成が beforeReorganization.txt の 3 つ目の SQL 文で失敗した場合、再開時には最初の 2 つの文は実行しません。
障害復旧において、再編成を最初からやりなおしたい場合もあります。-ignoreresume パラメーターを設定して再編成プロセスを実行すると、再編成プロセスは再開情報を無視して実行します。
再編成ではデータベーススキーマを変更します。これには、テーブルの作成と削除、構造の変更、インデックスや制限の追加、テーブル間でのデータの移動などが含まれます。データベーススキーマが正しくないと、特定の再編成プロセスで使用するどの文やプロシージャーも失敗する可能性があります。たとえば、再編成が新しいテーブルを作成する必要がある場合にテーブルが既に存在していると、この再編成は失敗します。
再編成プロセスは現在のデータベーススキーマを検索し、予想されたデータと実際にあるデータの間で一致しない点を探します。このプロセスを「データベーススキーマの検証」と呼びます。
このドキュメント作成時点において、次の検証が行われています:
- 新しいテーブルを作成する必要がある場合、同じ名前のテーブルやビューがないことを検証します。
- テーブルをドロップすると、そのテーブルが存在することを検証します。
- テーブルの名前を変更すると、新しいテーブル (または同じ名前のビュー) が既に存在しないこと、元のテーブルが存在することを検証します。
- 項目属性を作成する必要がある場合、この項目属性が既に存在しないことを検証します。
- 項目属性をドロップすると、その項目属性が存在することを検証します (詳しくは、こちらを参照してください。)。
注: 検証はすべて、実際の DBMS カタログに対して行います。
何らかの理由でデータベーススキーマを検証したくない場合は、再編成実行時に -noverifydatabaseschema パラメーターを使用します。
この値を設定できるモデルのオプションは 2 つあります: [ Create Database Options ] と、GeneXus から直接再編成を実行する [ Reorganization Options ] です。それぞれで既定値が異なります:
- Reorganization Options の既定値 = -nogui
- Create Database Options の既定値 = -nogui -noverifydatabaseschema
DBMS バージョンの検証では、GeneXus で設定されている DBMS バージョンと同等またはそれ以上の DBMS バージョンで再編成が実行されていることを検証します。この検証は、データベースの作成を含むすべての種類の再編成で実行します。
たとえば、接続先の SQL サーバーバージョンが 2000 であり、GeneXus の [ SQL server Version ] プロパティで [ 2005 or higher ] の値が設定されている場合、次のメッセージが表示されます:
データベーススキーマの検証プロセスでエラーが発生しました。現在のバージョンの DBMS より新しいバージョンで実行する再編成コードが生成されています。
DBMS はバージョン 2005 以上である必要があります。それよりも下位バージョンである場合、対応する DBMS バージョンのプロパティを変更した後に、再編成コードを再生成して再編成を再度実行する場合があります。
再編成プロセスは正常に完了しませんでした。
再編成に失敗しました。
注: この検証は回避できません。
再編成を 2 回実行する方法
既に正常に完了した再編成を誤って実行してしまうのを避けるため、2 回目に再編成を実行しようとすると「再編成は不要です」というメッセージが表示されます。ただし、既に正常に完了した再編成をもう一度実行する必要がある場合は、-force フラグを設定すれば実行可能です。
大まかにまとめると、再編成プロセスは次の手順で進められます。
- beforeReorganizationScript.txt ファイルが存在するかどうかを確認する。
- 再編成オプションに従って、データベーススキーマを検証する。
- 再編成を最後のエントリーポイントから再開する必要があるかどうかを確認する。
- 再編成を実行する。
- テーブルの作成やデータ変換も含め、IAR 解析に基づいてデータベースを再編成するコードを実行する。
- インデックスと参照整合性を作成する。
- afterReorganizationScript.txt ファイルが存在するかどうかを確認する。
- ナレッジベースを更新する。
データベースの再編成時に一時テーブルが作成される場合
データビューに関連する再編成
|