リリース7.2.2.0
Oracle Rdbリリース・ノート, リリース7.2.2.0 for OpenVMS
部品番号: E06180-01
原本名: Oracle Rdb Release Notes, Release 7.2.2.0 for OpenVMS
Copyright © 1984, 2007 Oracle Corporation. All rights reserved.
制限付権利の説明
このプログラム（ソフトウェアおよびドキュメントを含む）には、オラクル社およびその関連会社に所有権のある情報が含まれています。このプログラムの使用または開示は、オラクル社およびその関連会社との契約に記された制約条件に従うものとします。著作権、特許権およびその他の知的財産権と工業所有権に関する法律により保護されています。
独立して作成された他のソフトウェアとの互換性を得るために必要な場合、もしくは法律によって規定される場合を除き、このプログラムのリバース・エンジニアリング、逆アセンブル、逆コンパイル等は禁止されています。
このドキュメントの情報は、予告なしに変更される場合があります。オラクル社およびその関連会社は、このドキュメントに誤りが無いことの保証は致し兼ねます。これらのプログラムのライセンス契約で許諾されている場合を除き、プログラムを形式、手段（電子的または機械的）、目的に関係なく、複製または転用することはできません。
このプログラムが米国政府機関、もしくは米国政府機関に代わってこのプログラムをライセンスまたは使用する者に提供される場合は、次の注意が適用されます。
U.S. GOVERNMENT RIGHTS
Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the Programs, including documentation and technical data, shall be subject to the licensing restrictions set forth in the applicable Oracle license agreement, and, to the extent applicable, the additional rights set forth in FAR 52.227-19, Commercial Computer Software--Restricted Rights (June 1987). Oracle Corporation, 500 Oracle Parkway, Redwood City, CA 94065.
このプログラムは、核、航空、大量輸送、医療あるいはその他の本質的に危険を伴うアプリケーションで使用されることを意図しておりません。このプログラムをかかる目的で使用する際、上述のアプリケーションを安全に使用するために、適切な安全装置、バックアップ、冗長性（redundancy）、その他の対策を講じることは使用者の責任となります。万一かかるプログラムの使用に起因して損害が発生いたしましても、オラクル社およびその関連会社は一切責任を負いかねます。
Oracleは米国Oracle Corporationの登録商標です。Hot Standby、LogMiner for Rdb、Oracle CDD/Repository、Oracle CODASYL DBMS、Oracle Expert、Oracle Rdb、Oracle RMU、Oracle RMUwin、Oracle SQL/Services、Oracle Trace、Rdb7は米国Oracle Corporationの商標または登録商標です。その他の名称は、他社の商標の可能性があります。
このマニュアルは、Oracle Rdbリリース7.2.2.0のリリース・ノートです。このリリース・ノートでは、変更された機能と拡張機能、アップグレードと互換性に関する情報、新規および既存のソフトウェアの問題点と制限事項、ソフトウェアとドキュメントの修正事項について説明します。
このマニュアルは、すべてのOracle Rdbユーザーによって使用されることを目的としています。Oracle Rdbリリース7.2.2.0をインストール、アップグレードまたは使用する前にこのマニュアルに目を通してください。
このマニュアルの内容は次のとおりです。
| 第1章 | Oracle Rdbリリース7.2.2.0のインストール方法について説明します。 |
| 第2章 | Oracle Rdbリリース7.2.2.0で修正される問題について説明します。 |
| 第3章 | Oracle Rdbリリース7.2.1.4で修正される問題について説明します。 |
| 第4章 | Oracle Rdbリリース7.2.1.3で修正される問題について説明します。 |
| 第5章 | Oracle Rdbリリース7.2.1.2で修正される問題について説明します。 |
| 第6章 | Oracle Rdbリリース7.2.1.1で修正される問題について説明します。 |
| 第7章 | Oracle Rdbリリース7.2.1.0で修正される問題について説明します。 |
| 第8章 | Oracle Rdbリリース7.2.2.0で導入される拡張機能について説明します。 |
| 第9章 | Oracle Rdbリリース7.2.1.4で導入される拡張機能について説明します。 |
| 第10章 | Oracle Rdbドキュメント・セットで現在入手できない情報を示します。 |
| 第11章 | Oracle Rdbリリース7.2.2.0に存在する既知の問題、制限事項および回避策について説明します。 |
このソフトウェアの更新は、OpenVMSのVMSINSTALユーティリティを使用してインストールします。
注意
Oracle Rdbリリース7.2キットは完全なキットです。新しいRdbリリース7.2キットのインストール時に以前のリリースのOracle Rdbをインストールする必要はありません。
Oracle Rdb製品ファミリは、HP OpenVMS Industry Standard 64プラットフォームとOpenVMS AlphaServerプラットフォームで利用できます。通常、OpenVMS Alpha上のOracle Rdbの機能は、OpenVMS Industry Standard 64上のOracle Rdbで使用できます。ただし、プラットフォーム間の一部の違いによって、性能や機能にわずかな相違が生じる場合があります。
Oracle Rdbリリース7.2のデータベースの形式は、I64プラットフォームとAlphaプラットフォームで同じです。クラスタ環境では、どちらのアーキテクチャからも同時にデータベースにアクセスできます。（AlphaまたはVAXプラットフォーム上の）以前のRdbバージョンまたはネットワーク上の他のシステムからOracle Rdbリリース7.2データベースにアクセスするには、Oracle Rdbのリモート・データベース・サーバーを使用できます。
1.2 要件
このソフトウェアをインストールするには、次の条件を満たす必要があります。
HP Integrityサーバー上のこのリリースのOracle Rdbでは、サポートされている最新のプロセッサはIntelデュアルコアItanium 2プロセッサ9100シリーズ（コード・ネームMontvale）です。
1.4 OpenVMSの最大バージョンの確認
このリリースのOracle Rdbに対してサポートされる最大バージョンのOpenVMSはOpenVMSバージョン8.3-xです。
OpenVMSオペレーティング・システムのバージョンとサポートされるハードウェア・プラットフォームは、インストール時と実行時に確認されます。保証されていないバージョンのOpenVMSまたはハードウェア・プラットフォームがインストール時に検出されると、インストールは中断します。保証されていないバージョンのOpenVMSまたはハードウェア・プラットフォームが実行時に検出されると、Oracle Rdbは起動しません。
1.5 データベース形式の変更
Oracle Rdbのディスク上のデータベース形式が721になりました。Oracle Rdbリリース7.0または7.1で作成またはアクセスされたデータベースにRdbリリース7.2でアクセスするには、RMU/CONVERT操作が必要です。
Oracle Rdbリリース7.2にアップグレードする前、および既存のデータベースをOracle Rdbリリース7.2の形式に変換する前に、データベースの全体検証（RMU /VERIFY /ALLコマンドを使用）とデータベースの全体バックアップ（RMU /BACKUPコマンドを使用）を実行して、有効で保護されたデータベースのコピーを確保しておくことを強くお薦めします。
1.6 リリース7.0より前のデータベースの使用
Oracle Rdbリリース7.0の形式よりも前のデータベースは、Oracle Rdbリリース7.2の形式に直接変換またはリストアすることはできません。Oracle Rdbリリース7.2のRMU Convertコマンドは、Oracle Rdbリリース7.0およびリリース7.1の形式のデータベースからの変換のみをサポートします。Oracle Rdbリリース3.0からリリース6.1までの形式のデータベースまたはデータベース・バックアップを使用している場合、最低でもOracle Rdbリリース7.0の形式に変換してから、Oracle Rdbリリース7.2の形式に変換する必要があります。たとえば、Oracle Rdbリリース4.2の形式のデータベースを使用している場合、まず最低でもOracle Rdbリリース7.0の形式に変換してから、Oracle Rdbリリース7.2の形式に変換する必要があります。
Oracle Rdbリリース7.0の形式よりも前のデータベースをOracle Rdbリリース7.2の形式に直接変換またはリストアしようとすると、Oracle RMUでエラーが生成されます。
1.7 VMSINSTALプロシージャの起動
Oracle Rdbのインストール・プロシージャは、Oracle Rdbの以前のメジャー・リリースと比較すると簡素化されています。Oracle Rdbのすべてのコンポーネントが常にインストールされ、インストール時のプロンプトの数が少なくなりました。インストール・プロシージャは、Oracle Rdb for OpenVMS Alphaの場合もOracle Rdb for OpenVMS I64の場合も同じです。
インストール・プロシージャを開始するには、次の例のようにVMSINSTALコマンド・プロシージャを起動します。
@SYS$UPDATE:VMSINSTAL RDBV72200IM device-name
@SYS$UPDATE:VMSINSTAL RDBV72200AM device-name
@SYS$UPDATE:VMSINSTAL RDBV72201AM device-name
device-name
メディアがマウントされるデバイスの名前を使用します。デバイスがディスクタイプのドライブの場合、ディレクトリも指定する必要があります。たとえば、DKA400:[RDB.KIT]のようになります。
1.8 インストールの停止
インストール・プロシージャを停止するには、常に[Ctrl] + [Y]を押します。[Ctrl] + [Y]を押すと、インストール・プロシージャは、その時点までに作成したファイルをすべて削除して終了します。これで、インストールを再度開始できます。
VMSINSTALでインストール時になんらかの問題が検出された場合、ユーザーに通知され、続行するかどうかを尋ねるプロンプトが表示されます。インストールを続行して、他にも問題があるかどうかを確認できます。ただし、インストールされたOracle Rdbのコピーは使用できない可能性があります。
1.9 Oracle Rdbのインストール後
この更新では、Oracle Rdbの新しいOracle TRACE機能定義が提供されます。更新されたOracle Rdb機能定義の新機能リリース番号RDBVMSV7.2を反映するために、Oracle Rdbを参照するOracle TRACEの選択内容を再定義する必要があります。
システムにOracle TRACEをインストールして、Oracle Rdbのために収集する場合、この更新キットに付属の新しいOracle Rdb機能定義を挿入する必要があります。
インストール・プロシージャでは、EPC$FACILITY.TLBと呼ばれるライブラリ・ファイルにOracle Rdb機能定義を挿入します。Oracle TRACEを使用してOracle Rdbのイベント・データを収集できるようにするには、Oracle TRACEの管理データベースにこの機能定義を移動する必要があります。次の手順を実行します。
$ LIBRARY /TEXT /EXTRACT=RDBVMSV7.2 - _$ /OUT=RDBVMS.EPC$DEF SYS$SHARE:EPC$FACILITY.TLB
$ COLLECT INSERT DEFINITION RDBVMS.EPC$DEF /REPLACE
INSERT DEFINITIONコマンドを実行するプロセスでは、Oracle TRACEの管理データベースの作成に使用するバージョンと一致するバージョンのOracle Rdbを使用する必要があります。バージョンが一致していない場合、INSERT DEFINITIONコマンドは失敗します。
1.10 VMS$MEM_RESIDENT_USER権限の修飾子が必要
Oracle Rdbリリース7.1では、データベースまたは行キャッシュの属性RESIDENT、SHARED MEMORY IS SYSTEMおよびLARGE MEMORY IS ENABLEDに対する追加の権限の実行が導入されました。データベースでこのような機能を使用する場合、データベースを開くユーザー・アカウントには、VMS$MEM_RESIDENT_USER権限の修飾子が付与される必要があります。
これらの機能を使用する場合、RMU/OPENコマンドを使用することをお薦めします。
1.11 インストール、構成、移行、アップグレードの推奨事項
Oracle Rdbリリース7.2は、AlphaServerシステムおよびHP Integrityサーバーの混合アーキテクチャ・クラスタを完全にサポートしています。
特定の開発環境では、AlphaServerシステムとHP IntegrityサーバーのクラスタにVAXシステムを組み込むと便利な場合があります。HP社とオラクル社では、ほとんどの場合、この組込みが原因でコンピューティング環境に問題が生じることはないと考えていますが、十分なサポートを提供できるほどの広範囲なテストは行っていません。クラスタ内のVAXシステムが原因でクラスタのパフォーマンスや安定性に問題が生じる可能性はあります。万が一問題が発生した場合は、問題の原因となっているクラスタ内のVAXシステムを削除してください。
オラクル社では、Rdbリリース7.0を使用して直接データベースにアクセスする、VAXシステムとAlphaServerシステムによる混合アーキテクチャ・クラスタを引き続きサポートします。Oracle Rdbリリース7.1は、Alphaシステムとクラスタでネイティブに実行されます。Rdbのすべてのバージョンには、組込みのリモート・ネットワーク・データベース・サーバーが付属しています。これにより、アーキテクチャ間およびバージョン間におけるアプリケーションやデータベースのアクセスが可能になります。
既存のAlphaまたはVAX構成から、Integrityサーバー・システムを含む新しい環境にアプリケーションを移動する場合、可能なパスが数多くあります。これは各サイトの要件に応じて異なります。通常、ノードがHP Integrityサーバーであることを除けば、この移動は既存のAlphaServerシステムのクラスタまたはスタンドアロンのシステムに新しいノードを追加するのと同じくらい簡単です。表1-1「移行の提案」で、考えられる状況と推奨手順について考えます。
| ケース | 希望する動作 | 推奨手順 |
|---|---|---|
| 1 | Alphaサーバーの既存のクラスタにIntegrityサーバーを追加します。 |
|
| 2 | VAXノードとAlphaノードによる既存の混合クラスタにIntegrityサーバーを追加し、すべてのノードからRdbデータベースにアクセスします。データベースに使用するディスクは、すべてのノードからアクセスできます。 |
|
| 3 | 新しいディスクにデータベースを移動し、既存のクラスタにIntegrityサーバーを追加します。 |
|
| 4 | 以前のリリースを使用して、主にVAXノードまたはAlphaノードから引き続きRdbを使用します。アプリケーションのテストを行う目的で、Integrityサーバーを追加します。 |
|
| 5 | Alphaサーバーの既存のクラスタにIntegrityサーバーを追加するか、または1つ以上の新しいIntegrityサーバーを追加することで既存のスタンドアロンのAlphaサーバーから新しいクラスタを作成します。 |
|
| 6 | 新しいスタンドアロンのIntegrityサーバー・システムまたはIntegrityサーバーのクラスタを作成し、新しい環境にデータベースを移動します。 |
|
RMUとリモート・データベースの使用に関する追加情報と詳細は、Oracle Rdbのドキュメント・セットを参照してください。
クラスタの多くのシステムからデータベースにアクセスする場合、データベース・パラメータを変更する必要があることに注意してください。
この章では、Oracle Rdbリリース7.2.2.0で修正されるソフトウェアの誤りについて説明します。
2.1 すべてのインタフェースに適用されるソフトウェアの誤りの修正
2.1.1 VLMグローバル・バッファを使用する場合のシステム・クラッシュ
きわめて稀な状況ですが、グローバル・バッファVLM（大容量メモリー）機能を使用する場合、Oracle RdbでOpenVMSシステムがクラッシュし、バグチェックMACHINECHK, Machine check while in kernel modeが発生することがありました。MACHINECHKは、無効なPFN（ページ・フレーム番号）の値がPTE（ページ表エントリ）にロードされることでトリガーされます。
この問題を回避するには、ALTER DATABASE ... GLOBAL BUFFERS ...LARGE MEMORY IS DISABLEDを指定して、Oracle Rdbのグローバル・バッファVLM（大容量メモリー）機能の使用を中止します。
この問題はOracle Rdbリリース7.2.2で修正されました。Oracle RdbのVLM機能では、割り当てられたPFNマップの限度を超えてアクセスすることはできなくなりました。
2.1.2 リリース7.1.1からリリース7.1.5.1へのアップグレード後の問合せでバグチェックが発生する
Oracle Bug#6448202
リリース7.1.1からリリース7.1.5.1にアップグレードした後、問合せでバグチェックが発生します。この問合せは、3つの複雑なビューで複数の表を結合します。
次のSQLフラグを定義することで動的オプティマイザを無効にする場合、問合せは成功します。
set flags 'max_stability';
この問題は、Oracle Bug#4597186の修正によってOracle Rdbリリース7.1.4.2に導入されましたが、最新のユーザー・レポートでは何も報告されていません。多重にネストされたクロス・ストラテジでの検索ブロックの1つが、最上部の親問合せに到達することにより、動的オプティマイザLEAFノードを適用しました。
この問題は、Oracle Rdbリリース7.2.2で修正されました。
2.1.3 Rdbリリース7.0からリリース7.2のアップグレード後、問合せがループしてハングする
Oracle Bug#6459494
Rdbリリース7.0.6からRdb 7.2リリースへのアップグレード後、問合せがループしてハングします。次の問合せは簡略化されたものですが、同じ動作を示しています（パフォーマンスはきわめて遅い）。
set flags 'strategy';
SELECT count(*)
FROM PM P, KOSE K
WHERE
P.PROD = 'RSS' AND
EXISTS(SELECT *
FROM KSU_V KV
WHERE
P.PROD = KV.PROD AND
P.PROD = K.PROD );
Aggregate
Cross block of 2 entries
Cross block entry 1
Match
Outer loop (zig-zag)
Index only retrieval of relation KOSE
Index name IDX_KOSE [1:1]
Inner loop (zig-zag)
Index only retrieval of relation PM
Index name IDX_PM [1:1]
Cross block entry 2
Conjunct Aggregate-F1 Conjunct
Merge of 2 entries
Merge block entry 1
Conjunct Index only retrieval of relation KSU
Index name KSU_IDX [0:0]
Merge block entry 2
Cross block of 3 entries
Cross block entry 1
Conjunct
Merge of 1 entries
Merge block entry 1
Reduce Conjunct
Index only retrieval of relation KSU
Index name KSU_IDX [1:1]
Cross block entry 2
Conjunct
Merge of 1 entries
Merge block entry 1
Index only retrieval of relation KOSEIUNIT_PSIYO
Index name KSU_IDX_1 [4:4]
Cross block entry 3
Conjunct Aggregate-F1
Index only retrieval of relation KSU
Index name KSU_IDX [6:6]
ビューKSU_Vには、UNION All句が含まれています。
create view KSU_V
(PROD, ATTCD, UGRP, UBLK, USEQ, PSIYO) AS
select C2.PROD, C2.ATTCD, C2.UGRP, C2.UBLK, C2.USEQ, C2.PSIYO
from KSU C2
union all
select C3.F1, C3.F2, C3.F3, C3.F4, C3.F5, C6.PSIYO
from
(select C5.PROD, C5.ATTCD, C5.UGRP, C5.UBLK, C5.USEQ
from KSU C5
group by C5.PROD, C5.ATTCD, C5.UGRP, C5.UBLK, C5.USEQ)
as C3 (F1, F2, F3, F4, F5),
(select C7.PROD, C7.UGRP, C7.UBLK, C7.USEQ, C7.PSIYO
from KOSEIUNIT_PSIYO C7
where ((((C7.PROD = C3.F1)
and (C7.UGRP = C3.F3))
and (C7.UBLK = C3.F4))
and (C7.USEQ = C3.F5)))
as C6 (PROD, UGRP, UBLK, USEQ, PSIYO)
where (not exists (select * from KSU C8
where ((((((C8.PROD = C3.F1)
and (C8.ATTCD = C3.F2))
and (C8.UGRP = C3.F3))
and (C8.UBLK = C3.F4))
and (C8.USEQ = C3.F5))
and (C8.PSIYO = C6.PSIYO))));
この問題もRdbリリース7.1.5.1とRdbリリース7.2.1.3の両方に存在します。ただし、Rdbリリース7.0.9では、問合せは実際に素早く実行されます。
この問題の回避策はありません。これは、Rdbリリース7.1.5.1のOracle Bug#5567495および4747999の修正によって生じたリグレッションであるためです。
ビューにUNIONの最初の区間があるため、ストラテジでは、次の問題となっている索引の全索引スキャンが使用されます。
Cross block entry 2
Conjunct Aggregate-F1 Conjunct
Merge of 2 entries
Merge block entry 1
Conjunct Index only retrieval of relation KSU
Index name KSU_IDX [0:0] <==
Merge block entry 2
索引KSU_IDXは次のように定義されます。
create index KSU_IDX on KSYU
(PROD, ATTCD, UGRP, UBLK, USEQ, PSIYO);
この問題は、Oracle Rdbリリース7.2.2で修正されました。
2.1.4 RDMS$$INTERP_COMPILEでのバグチェック
Oracle Bug#6505717
I64システムでランタイム・ネイティブ・コンパイラを使用する稀なケースでは、MOV_x命令がRDMS$$INTERP_COMPILE内で次のような内容のバグチェックをトリガーすることがありました。
***** Exception at FFFFFFFF8603B040 :
RDMSHRP72\RDMS$$INTERP_COMPILE + 0004CC71
%COSI-F-BUGCHECK, internal consistency failure
Saved PC = FFFFFFFF85EFAE90 : RDMSHRP72\RDMS$$GEVX_RET_FINISH + 00000DD0
Saved PC = FFFFFFFF85E5A520 : RDMSHRP72\RDMS$$CREATE_EMOD + 00003CD0
Saved PC = FFFFFFFF85EDB9A0 : RDMSHRP72\RDMS$$SETUP_ACTION + 000000F0
Saved PC = FFFFFFFF85EBA850 : RDMSHRP72\RDMS$$PRE_EXECUTION + 00002020
Saved PC = FFFFFFFF85E874B0 : RDMSHRP72\RDMS$$COMPILE_FOR_IF + 00004340
Saved PC = FFFFFFFF85E79D00 : RDMSHRP72\RDMS$$COMPILE_STMT + 00001420
Saved PC = FFFFFFFF85E78D20 : RDMSHRP72\RDMS$$COMPILE_STMT + 00000440
Saved PC = FFFFFFFF85E7CC30 : RDMSHRP72\RDMS$$COMPILE_STMT + 00004350
Saved PC = FFFFFFFF85E78D20 : RDMSHRP72\RDMS$$COMPILE_STMT + 00000440
Saved PC = FFFFFFFF85E78D20 : RDMSHRP72\RDMS$$COMPILE_STMT + 00000440
Saved PC = FFFFFFFF85E767F0 : RDMSHRP72\RDMS$$DSDI_COMPILE + 00001F10
Saved PC = FFFFFFFF85FD3CC0 : RDMSHRP72\RDMS$TOP_COMPILE_REQUEST + 00002350
Saved PC = FFFFFFFF867261A0 : RDMSHRP72\AMAC$EMUL_CMPC5 + 00002040
Saved PC = FFFFFFFF86381C60 : RDMSHRP72\KODSTREAM$JACKET + 00000130
この問題はOracle Rdbリリース7.2.2で修正されました。コードは、考えられるソースと宛先のすべての組合せのアドレッシング・モードを正しく処理するようになりました。
2.1.5 マップ済の共有メモリーが常駐するデータベースを開こうとすると、Duplicate NOGDBL name、またはRDMS-F-CANTCREGBLおよびCOSI-F-BADPARAMが発生する
Oracle Bug#6495572
データベース属性SHARED MEMORY IS PROCESS RESIDENTを使用する場合、（かなり大きなグローバル・セクションを含む高負荷システムでのみ）Rdbモニター・プロセスでグローバル・セクションの予期しない再マッピングを検出することがありました。モニター・プロセスはデータベースのグローバル・セクションを一意の名前で作成しようとしますが、以前のグローバル・セクションが誤ってマップされたままになっていました。
ユーザー・プロセスでデータベースを再度開くか、またはデータベースにアクセスしようとすると、次のような致命的なエラーが発生していました。
%RDMS-F-CANTOPENDB, database could not be opened as requested -RDMS-F-CANTCREGBL, error creating and mapping database global section -COSI-F-BADPARAM, bad parameter value
モニターのログ・ファイルには、次のようなDuplicate NOGDBL nameメッセージが含まれます。
6-OCT-2007 23:01:03.24 - Received open database request from 203589E8:0
- process name _FTA170:, user RDB_ADMIN
- database name "DSA58:[RDB.DATA]RESDB.RDB;1" [_DSA58] (13,1,0)
- Duplicate NOGDBL name "RDM72NDSA58000D0001000000000000" detected ...
retrying
- opening as monitor ID 1
- cluster watcher is active
- sending normal open database reply to 203589E8:0
回避策として、RESIDENT共有メモリーを使用しないようにデータベースを設定します。
この問題はOracle Rdbリリース7.2.2で修正されました。Oracle Rdbのモニター・プロセスは、グローバル・セクションの予期しない再マッピングを検出すると、共有メモリーのマッピングを解除します。
2.1.6 クラスタでの論理領域のドロップおよび再作成後にPIOFETCH$WITHIN_DBでBADPAGNUMのバグチェックが発生する
Oracle Bug#6603641
複数ノードのクラスタ環境では、論理領域をドロップして再作成する場合、PIOFETCH$WITHIN_DBで次のようなバグチェックが発生することがあります。
RDMS-F-CANTREADDBS, error reading pages 148:10881-10881 RDMS-F-BADPAGNUM, page 10881 is out of valid range (1:2637) for physical area 148 Exception occurred at RDMSHRP72\PIOFETCH$WITHIN_DB + 000005B8 Called from RDMSHRP72\PIOFETCH$FETCH + 000002E4 Called from RDMSHRP72\PIO$FETCH + 00000914 Called from RDMSHRP72\DIOLAREA$FIND_GOOD_PAGE + 00000214 Called from RDMSHRP72\DIO$RECORD_LOCATION + 0000021C Called from RDMSHRP72\DIOSTORE$STORE_SEG + 000000E4 Called from RDMSHRP72\DIO$STORE + 000002A4
この問題は、論理領域を1つのノードでドロップしてから、別の論理領域を同じ論理領域番号（ただし別の物理領域）を使用して追加した場合に発生することがあります。クラスタ内の別のノードは、新しい物理領域に対して無効な古い次のページのポインタを論理領域に使用していました。
この問題はOracle Rdbリリース7.2.2で修正されました。Oracle Rdbは論理領域の次のページのポインタが物理記憶域内で有効と思われるページであるかどうかを正しく検証するようになりました。
2.1.7 Rdb 7.2へのアップグレード後の全索引スキャンによる問合せの速度の低下
Oracle Bug#6617515
Rdbリリース7.0からRdbリリース7.2へのアップグレード後、全索引スキャンによって問合せの速度が低下します。次の問合せは簡略化されたものですが、同じ動作を示しています。
set flags 'strategy';
select abc.GCD
from T0 t0,
(select GCD
from T1
where GCD = (select GCD
from T2
where HBAN = t0.HBAN
and YSEQ = (select min(YSEQ)
from T2
where HBAN = t0.HBAN))) abc
where YMD = '20070619';
Cross block of 2 entries
Cross block entry 1
Index only retrieval of relation T0
Index name IDX_T0 [1:1]
Cross block entry 2
Merge of 1 entries
Merge block entry 1
Cross block of 2 entries
Cross block entry 1
Aggregate
Cross block of 2 entries
Cross block entry 1
Aggregate Conjunct
Index only retrieval of relation T2
Index name IDX_T2 [0:0]
Cross block entry 2
Index only retrieval of relation T2
Index name IDX_T2 [2:2]
Cross block entry 2
Index only retrieval of relation T1
Index name IDX_T1 [1:1]
索引は次のように定義されます。
create index IDX_T0 on T0 (YMD, HBAN); create index IDX_T1 on T1 (GCD) create index IDX_T2 on T2 (HBAN, YSEQ, GCD);
次に、Rdbリリース7.0からのストラテジ出力を示します。
Cross block of 2 entries
Cross block entry 1
Index only retrieval of relation T0
Index name IDX_T0 [1:1]
Cross block entry 2
Merge of 1 entries
Merge block entry 1
Cross block of 2 entries
Cross block entry 1
Aggregate
Cross block of 2 entries
Cross block entry 1
Aggregate Index only retrieval of relation T2
Index name IDX_T2 [1:1] Min key lookup
Cross block entry 2
Index only retrieval of relation T2
Index name IDX_T2 [2:2]
Cross block entry 2
Index only retrieval of relation T1
Index name IDX_T1 [1:1]
違いは次の行のみです。
From 7.2 output:
Aggregate Conjunct
Index only retrieval of relation T2
Index name IDX_T2 [0:0]
From 7.0 output:
Aggregate Index only retrieval of relation T2
Index name IDX_T2 [1:1] Min key lookup
この問題はRdbリリース7.1とRdbリリース7.2に存在しますが、Rdbリリース7.0.9では、問合せは素早く実行されます。
この問題の回避策はありません。これは、Rdbリリース7.2.1.0のOracle Bug#5567495および4747999の修正によって生じたリグレッションであるためです。
この問題は、Oracle Rdbリリース7.2.2で修正されました。
2.1.8 CONCATの最適化による問合せの速度の低下
Oracle Bug#6618080および6617696
Oracle Rdbリリース7.2.1では、より多くの引数と連結パフォーマンスの向上をサポートするためにCONCAT演算子が再実装されました。同時にオプティマイザが拡張され、CONCAT演算子を一連のAND式として書き換えることにより、索引の使用状況が向上するようにしました。ただし、この変更によって一致結合ストラテジからクロス結合ストラテジへの切替えが発生し、問合せに関連する遅れが生じる可能性があります。
この問題はOracle Rdbリリース7.2.2で修正されました。CONCATの最適化は、オプティマイザがこの最適化を使用して一致結合ストラテジを実装できるように修正されました。
2.1.9 Alphaで常駐イメージがある場合、バグチェックのダンプ・ファイルでコール・スタックが記号化されない
Oracle Bug#6634194
Rdbイメージの/RESIDENTがインストールされているAlphaシステムでは、バグチェックのダンプ・ファイルのコール・スタックでルーチンが正しく記号化されないことがあります。次の例は、ルーチンが記号化されない一例を示しています。それ以外の場合もあります（システム領域の仮想アドレスが常駐イメージを示すことに注意してください）。
***** Exception at FFFFFFFF81653234 : Image RDMSHRP72 + 004DD234
%COSI-F-BUGCHECK, internal consistency failure
Saved PC = FFFFFFFF81640E88 : Image RDMSHRP72 + 004CAE88
Saved PC = FFFFFFFF816415D4 : Image RDMSHRP72 + 004CB5D4
Saved PC = FFFFFFFF81461464 : Image RDMSHRP72 + 002EB464
Saved PC = FFFFFFFF814401C4 : Image RDMSHRP72 + 002CA1C4
Saved PC = FFFFFFFF8143FB70 : Image RDMSHRP72 + 002C9B70
Saved PC = FFFFFFFF8143FB70 : Image RDMSHRP72 + 002C9B70
Saved PC = FFFFFFFF8144401C : Image RDMSHRP72 + 002CE01C
Saved PC = FFFFFFFF814440DC : Image RDMSHRP72 + 002CE0DC
Saved PC = FFFFFFFF8143FC78 : Image RDMSHRP72 + 002C9C78
Saved PC = FFFFFFFF8144401C : Image RDMSHRP72 + 002CE01C
Saved PC = FFFFFFFF814440DC : Image RDMSHRP72 + 002CE0DC
Saved PC = FFFFFFFF8143FC78 : Image RDMSHRP72 + 002C9C78
Saved PC = FFFFFFFF81443574 : Image RDMSHRP72 + 002CD574
Saved PC = FFFFFFFF81443750 : Image RDMSHRP72 + 002CD750
Saved PC = 00000000014B9DCC : symbol not found
Saved PC = FFFFFFFF8145A5F4 : Image RDMSHRP72 + 002E45F4
Saved PC = FFFFFFFF8122849C : Image RDMSHRP72 + 000B249C
Saved PC = FFFFFFFF81688294 : Image RDMSHRP72 + 00512294
回避するには、イメージ/RESIDENTをインストールしないでください。
この問題は、Oracle Rdbリリース7.2.2で修正されました。コール・スタックは正しく記号化されるようになりました。
2.1.10 RDMS__CS_TRANS_Dでのバグチェック
Oracle Bug#6633348
WIN_LATIN1キャラクタ・セットを使用するデータベースの例を次に示します。
SQL> show character set;
Default character set is DEC_MCS
National character set is DEC_MCS
Identifier character set is DEC_MCS
Literal character set is DEC_MCS
Display character set is UNSPECIFIED
Alias RDB$DBHANDLE:
Identifier character set is WIN_LATIN1
Default character set is WIN_LATIN1
National character set is UNICODE
SQL>
ここでは、次のようなバグチェックが発生する場合があります。
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address= 0000000000000188, PC=FFFFFFFF80002D40, PS=0000000B Saved PC = 00000000803981C0 : RDMSHRP721\RDMS__CS_TRANS_D + 00000210
これはItaniumシステムのみの問題です。
この問題は、Oracle Rdbリリース7.2.2で修正されました。
2.1.11 Oracle Bug#5192800の修正による問合せの速度の低下
Oracle Bug#6619860
Oracle Bug#5192800の修正はRdbリリース7.2.1.0で行われました。この修正が原因で、現在のユーザーの問合せの速度が大幅に低下します。
Oracle Bug#5192800の問合せには、等式条件を含むON句を使用した内部結合操作と左側外部結合操作、およびMAX aggregateのsubselect問合せがあります。
SELECT SM.ACCT_NUM, H.ACCT_NUM
FROM
SM SM INNER JOIN SC SC
ON (SC.ACCT_NUM = SM.ACCT_NUM AND
EXISTS (SELECT * FROM EX EX
WHERE EX.ACCT_NUM = SC.ACCT_NUM))
LEFT OUTER JOIN
H H
OH H.ACCT_NUM = SM.ACCT_NUM
AND H.TIM_STMP =
(SELECT MAC(H2.TIM_STMP)
FROM H H2
WHERE H2.ACCT_NUM = SM.ACCT_NUM );
現在のユーザーの問合せには、外部結合操作はありませんが、2つのEXISTのsubselect問合せが含まれています。
SELECT * FROM
( SELECT HB FROM T1 WHERE KBN = '1') TT1,
( SELECT T2.HB
FROM T2,
(SELECT KBN FROM T3 WHERE ZK_KBN ='1') TT3
WHERE T2.KBN = TT3.KBN
AND NOT EXISTS( SELECT * FROM T2
WHERE KBN = '101'
AND ORDER_NO <> ORD_NO )
AND NOT EXISTS( SELECT *
FROM ( SELECT * FROM T2
WHERE KBN = '101'
AND ORDER_NO <> ORD_NO ) N1,
( SELECT * FROM T2
WHERE KBN = '201' ) N2
WHERE N1.ORD_NO = N2.ORD_NO
AND N1.HB = N2.HB
AND N1.YMD = N2.YMD )
GROUP BY T2.HB
HAVING T2.HB = TT1.HB
) T4;
この問題は、Oracle Rdbリリース7.2.2で修正されました。
2.1.12 DIOCCH$FETCH_SNAP_SEGのバグチェック
Oracle Bug#5240329
行キャッシュ機能を使用する場合、内部データ構造へのアクセスが誤って同期化されることがありました。この問題が原因で、読取り専用トランザクションが失敗し、次の例のようなバグチェックが発生していました（ただし、その他の現象も考えられます）。
***** Exception at 010BA554 : DIOCCH$FETCH_SNAP_SEG + 000009E4 %COSI-F-BUGCHECK, internal consistency failure Saved PC = 010A8F14 : DIOFETCH$FETCH_ONE_LINE + 00000994 Saved PC = 010A95C8 : DIO$FETCH_DBKEY + 000002F8
この問題は、Oracle Rdbリリース7.2.2で修正されました。データ構造へのアクセスは、読取り専用トランザクションと読み書きトランザクションの間で正しく同期化されるようになりました。行キャッシュ機能を使用するすべてのユーザーに、アップグレードすることをお薦めします。
2.2 SQLエラーの修正
2.2.1 NOT NULL制約が列に指定されている場合の%SQL-W-LOOK_FOR_STT
Oracle Bug#6157999
NOT NULL制約が2番目または後続の制約として列に指定された場合、CREATE/ALTER TABLEは失敗し、%SQL-W-LOOK_FOR_STTが発生していました。
たとえば、次のSQL文で問題を示します。
SQL>create table tab1 (col1 char(10) unique not null);
create table tab1 (col1 char(10) unique not null);
^
%SQL-W-LOOK_FOR_STT, Syntax error, looking for:
%SQL-W-LOOK_FOR_CON, DEFERRABLE,
%SQL-F-LOOK_FOR_FIN, found NULL instead
この問題を防ぐには、NOT NULL制約を他のどの制約よりも先に指定します。たとえば、前述のSQL文は次のように記述すると成功します。
create table tab1 (col1 char(10) not null unique);
この問題は、Oracle Rdbリリース7.2.2で修正されました。
2.2.2 WAITフラグとNOWAITフラグがシーケンスで使用されない
Oracle Bug#6487720
以前のバージョンのOracle Rdbでは、シーケンスに定義されたWAITフラグおよびNOWAITフラグを無視していました。そのため、すべての待機操作は、現在のトランザクションの設定によって制御されていました。トランザクションでNOWAIT句を指定した場合、NEXTVALの参照は失敗し、LOCK_CONFLICTエラーが表示されます。
%RDB-E-LOCK_CONFLICT, request failed due to locked resource -RDMS-F-LCKCNFLCT, lock conflict on client '........SEQ_....' 000000015F5145530000000100000019000000
この問題はOracle Rdbリリース7.2.2で修正されました。ALTER SEQUENCEとCREATE SEQUENCEコマンドのWAIT句およびNOWAIT句は、『Oracle Rdb SQLリファレンス・マニュアル』で説明されているように機能するようになりました。
2.2.3 予期しないデッドロックがCREATE TABLEで返される
Oracle Bug#6629124および5060366
稀なケースですが、以前のバージョンのOracle Rdbでは、CREATE TABLE文に現在の表定義の列を参照するCOMPUTED BY句、AUTOMATIC AS句またはDEFAULT句が含まれている場合、CREATE TABLEがデッドロック・エラーをレポートすることがありました。
次の例は、この予期しないエラーを示しています。
SQL> create table sample cont> (c_key char(16) cont> ,ckey_a automatic as upper (c_key) cont> ); %RDB-E-DEADLOCK, request failed due to resource deadlock -RDB-E-NO_META_UPDATE, metadata update failed -RDMS-F-DEADLOCK, deadlock on client 'Table id 32 (SAMP)' 504D4153000000200000000400000055
この問題は、割り当てられたRDB$RELATION_IDが最大許容値（8192）を超える場合にのみ発生します。この場合、Rdbは以前に割り当てられた古い値を表に再利用しようとします。これはDROP TABLEによって後から解放されたものです。
この問題はOracle Rdbリリース7.2.2で修正されました。Rdbは未使用のリレーションIDの値を正しく見つけるようになりました。デッドロック・エラーはレポートされません。
2.2.4 DECODE関数に対して予期しないNOTGROFLDエラーがレポートされる
Oracle Rdbを使用すると、GROUP BY句で式を使用できます。これらの式は、SELECT句の式と正確に一致する必要があります。以前のバージョンでは、次の例に示すように、SQLはDECODEの組込みに対してNOTGROFLDエラーを予期せずレポートしていました。
SQL> select ace_ord_type, cont> decode(ace_ord_status, 'CO', 1, 0), cont> count(*) cont> from ace_orders cont> group by ace_ord_type, cont> decode(ace_ord_status, 'CO', 1, 0); %SQL-F-NOTGROFLD, Column ACE_ORD_STATUS cannot be referred to in the select list, ORDER BY, or HAVING clause because it is not in the GROUP BY clause
回避するには、DECODE組込み関数ではなく単純なCASE式を使用します。たとえば、前述のDECODEは次のように変換できます。
case ace_ord_status
when 'CO' then 1
else 0
end
この問題はOracle Rdbリリース7.2.2で修正されました。DECODEは、GROUP BY式のセマンティック・チェックを実行する際にSQLで正しく処理されるようになりました。
2.2.5 LIKE演算子に関するメモリー・リークの修正
Oracle Bug#6405763
以前のバージョンのOracle Rdbでは、LIKE演算子に関連するメモリー・リークがわずかにありました。LIKEを使用する問合せの対話が何度も行われると、そのプロセスのPGFLQUOTAを超えることがありました。
この問題は、Oracle Rdbリリース7.2.2で修正されました。
2.3 RMUエラーの修正
2.3.1 RMU/CONVERTが論理領域エントリのAIPページ番号フィールドを設定しない
Oracle Rdb RMUリリース7.2では、Rdbデータベースの領域インベントリ・ページの論理領域エントリに新しいフィールドが追加されました。このフィールドには、論理領域エントリを位置付けるAIPページ番号が含まれていました。リリース7.2より前のバージョンのRdbデータベースを、/COMMIT修飾子（デフォルト）または/NOCOMMIT修飾子を使用してリリース7.2に変換した場合、このAIPページ番号を含む新しいフィールドが初期化されませんでした。ただし、値0が含まれていました。これが原因でデータベースが破損することはありませんでした。ページ番号フィールドは、論理領域を参照する後続の操作（RMU/SET AIP/LENGTH=n/LAREA=nまたはRMU/SET AIP/REBUILD_SPAMS/LAREA=nなど）によって設定されていました。ただし、初期化されるまで、AIPエントリのAIPページ番号フィールドの値はゼロで、RMU/SHOW AIP/LAREA=nなどのコマンドで表示されていました。この問題は修正され、RMU/CONVERTはRMU/CONVERTに対するAIPページの論理領域エントリのAIPページ番号フィールドをリリース7.2に正しく設定するようになりました。
次の例は、修正された問題を示しています。データベースをリリース7.2に変換した後、論理領域に対するRMU/SHOW AIPコマンドはAIPページ番号ゼロを示します。混合形式の記憶域の場合、統一形式の記憶域とは異なり、領域ビット・マップ・ページ番号フィールドはゼロになるのが正常です。この問題はAIPページ番号フィールドにのみ発生します。RMU/CONVERTで正しく処理される、AIPエントリのABMページ番号フィールドでは発生しません。
$ @SYS$LIBRARY:RDB$SETVER 7.2 $ RMU/CONVERT/COMMIT MF_PERSONNEL %RMU-I-RMUTXT_000, Executing RMU for Oracle Rdb V7.2-00 %RMU-I-LOGCONVRT, database root converted to current structure level %RMU-S-CVTDBSUC, database DEVICE:[DIRECTORY]MF_PERSONNEL.RDB;1 successfully converted from version V7.1 to V7.2 $ RMU/SHOW AIP/LAREA=80 MF_PERSONNEL Logical area name EMPLOYEES Type: TABLE Logical area 80 in mixed physical area 5 Physical area name EMPIDS_OVER Record length 126 AIP page number: 0 ABM page number: 0 Snapshot Enabled TSN: 60
この問題を回避するには、データベースのAIPページの該当論理領域に対してAIPページ番号エントリを初期化する操作（RMU/SET AIPコマンドなど）を論理領域に対して実行します。
$ @SYS$LIBRARY:RDB$SETVER 7.2 $ RMU/CONVERT/COMMIT MF_PERSONNEL %RMU-I-RMUTXT_000, Executing RMU for Oracle Rdb V7.2-00 %RMU-I-LOGCONVRT, database root converted to current structure level %RMU-S-CVTDBSUC, database DEVICE:[DIRECTORY]MF_PERSONNEL.RDB;1 successfully converted from version V7.1 to V7.2 $ RMU/SHOW AIP/LAREA=80 MF_PERSONNEL Logical area name EMPLOYEES Type: TABLE Logical area 80 in mixed physical area 5 Physical area name EMPIDS_OVER Record length 126 AIP page number: 0 ABM page number: 0 Snapshot Enabled TSN: 60 $ RMU/SET AIP/LAREA=80/LENGTH=126 MF_PERSONNEL $ RMU/SHOW AIP/LAREA=80 MF_PERSONNEL Logical area name EMPLOYEES Type: TABLE Logical area 80 in mixed physical area 5 Physical area name EMPIDS_OVER Record length 126 AIP page number: 150 ABM page number: 0 Snapshot Enabled TSN: 60
この問題は、Oracle Rdbリリース7.2.2で修正されました。
2.3.2 RMU/RESTOREを圧縮型保存セットと一緒に使用する場合にACCVIOが発生する
圧縮型保存セットの2番目のファイルからリストアを開始する場合、RMU/RESTOREが失敗し、ACCVIOが発生します。保存セットに多くのランダム・データがあるため、暗号化で使用する際に発生する場合が多くあります。
$ RMU/RESTORE/NOCDD LDA100:[000000]RBF1,LDA200: -
/DISK=READER=1/NOLOG/ENCR=(VALUE=A2345678901234567890123456789012,
ALG=AESCBC256)
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=000002C3,
PC=0039EEF4, ...
%RMU-I-BUGCHKDMP, generating bugcheck dump file ...
この問題は、Oracle Rdbリリース7.2.2で修正されました。
2.3.3 読取り専用記憶域のRMU Verify Readyでエラーが返される
Oracle Bug#6598519
READ ONLYに定義されているOracle Rdbデータベース記憶域のRMU/VERIFY Readyで、/TRANSACTION_TYPE=READ_ONLYが指定されていない場合、RMU-E-READONLYエラーが返されていました。RMU/VERIFYでは、/TRANSACTION_TYPE=WRITEがデフォルトです。/TRANSACTION_TYPEがREAD ONLYではない場合、RMUはREAD ONLY記憶域に関連付けられたスナップショット領域を2回（最初はREAD ONLY記憶域が準備されるとき、2回目はスナップショット領域を検証する直前）準備しようとしたため、この問題が発生していました。RMU/VERIFYがREAD ONLY領域に関連付けられたスナップショット領域を2回目に準備しようとしたときに、RMU-E-READONLYエラーが返されていました。
この問題は修正されました。/TRANSACTION_TYPE=WRITE（デフォルト）の場合でも、RMU/VERIFYは記憶域がREAD ONLYに定義されているかどうかを確認して、その記憶域とそれに関連付けられているスナップショット領域を正しく準備します。このエラーが返ることでデータベースの検証が終了するわけではありません。続けて次の記憶域を検証します。また、このエラーが返される場合、READ ONLY記憶域は検証されますが、その記憶域に関連付けられているスナップショット領域は検証されません。
次の例は、Rdbデータベース記憶域がREAD ONLYに定義され、RMU/VERIFY/TRANSACTION_TYPE=READ_ONLYが指定されていない場合にRMU-E-READONLYエラーが返される状況を示しています。
$ SQL ALTER DATABASE FILENAME MF_PERSONNEL ADD STORAGE AREA U_EMPIDS_MID PAGE FORMAT IS UNIFORM ALTER DATABASE FILENAME MF_PERSONNEL ALTER STORAGE AREA U_EMPIDS_MID READ ONLY; EXIT; $ RMU/VERIFY/ALL/NOLOG MF_PERSONNEL %RMU-E-BADREADY, error readying storage area U_EMPIDS_MID $ RMU/VERIFY/ALL/NOLOG/TRANSACTION_TYPE=WRITE MF_PERSONNEL %RMU-E-BADREADY, error readying storage area U_EMPIDS_MID
この問題を防ぐには、検証に対して/TRANSACTION_TYPE=READ_ONLYを指定します。
$ RMU/VERIFY/ALL/NOLOG/TRANSACTION_TYPE=READ_ONLY MF_PERSONNEL $
この問題は、Oracle Rdbリリース7.2.2で修正されました。
2.3.4 RMU/MOVE/ROOTがジャーナル化されない変更の警告を保持しない
Oracle Bug#2967642
RMU/MOVE_AREA/ROOTコマンドはデータベース・ルートを記憶域とともに移動する必要があることを指定しますが、移動したルートのエントリ（ジャーナル化されない変更がOracle Rdbデータベース記憶域に加えられたことを示す）を誤って消去していました。/ROOTがRMU/MOVE_AREAコマンドで指定されない場合、この情報は移動していないデータベースのルート・ファイルで正しく保持されていました。この問題は修正されました。RMU/MOVE_AREA/ROOTは、ジャーナル化されない（アフター・イメージ・ジャーナル・ファイルに保存されない）変更がデータベースに加えられたことを示す情報を、移動したルート・ファイルで保持するようになりました。
次の例は、修正された問題を示しています。RMU/MOVE_AREAで/ROOT修飾子を指定しない場合、ジャーナル化されない変更情報は、移動していないRdbデータベースのルート・ファイルで保持されていましたが、RMU/MOVE_AREA/ROOTでは、移動したルート・ファイルでこの情報が保持されていませんでした。
$ RMU/DUMP/OUTPUT=BEFORE.TXT TEST.RDB
$ search before.txt "Non-journalled database modifications have been made"
- WARNING: Non-journalled database modifications have been made
$ RMU/MOVE_AREA/NOLOG/DIRECTORY=DISK:[DIRECTORY] TEST.RDB
%RMU-W-DOFULLBCK, full database backup should be done to ensure future recovery
$ RMU/DUMP/OUTPUT=AFTER.TXT TEST.RDB
$ search after.txt "Non-journalled database modifications have been made"
- WARNING: Non-journalled database modifications have been made
$
$ RMU/DUMP/OUTPUT=BEFORE.TXT TEST.RDB
$ search before.txt "Non-journalled database modifications have been made"
- WARNING: Non-journalled database modifications have been made
$ RMU/MOVE_AREA/NOLOG/DIRECTORY=DISK:[DIRECTORY]/ROOT=TEST_MOVED TEST.RDB
%RMU-I-AIJRSTAVL, 0 after-image journals available for use
%RMU-I-AIJISOFF, after-image journaling has been disabled
%RMU-W-DOFULLBCK, full database backup should be done to ensure future recovery
$ RMU/DUMP/OUTPUT=AFTER.TXT TEST_MOVED.RDB
$ search after.txt "Non-journalled database modifications have been made"
%SEARCH-I-NOMATCHES, no strings matched
この問題は、Oracle Rdbリリース7.2.2で修正されました。
2.3.5 RMU /POPULATE_CACHEによってPIOFETCH$WITHIN_DBでバグチェックが発生する
Oracle Bug#6655876
RMU /POPULATE_CACHEコマンドがスナップショットのレコードのコピーを読み取ろうとするときにバグチェックが発生することが稀にありました。バグチェックのダンプ・ファイルには、次の内容が表示されます。
Exception occurred at RMU72\PIOFETCH$WITHIN_DB + 000001E8
Called from RMU72\PIOFETCH$FETCH + 000002E4
Called from RMU72\PIO$FETCH + 00000914
Called from RMU72\DIOCCH$FETCH_SNAP_SEG + 000005E4
Called from RMU72\DIOFETCH$FETCH_ONE_LINE + 00000738
Called from RMU72\DIO$FETCH_DBKEY + 000002A4
Called from RMU72\PSIISCAN$WALK_BTREE_TOP_DOWN + 00000218
Called from RMU72\RMUPOP$FETCH_ONE_SORTED_INDEX + 000002EC
Called from RMU72\RMUPOP$FETCH_AREAS + 00000304
Called from RMU72\RMUCLI$POPULATE_CACHE + 00000414
この問題はOracle Rdbリリース7.2.2で修正されました。RMUは、有効な記憶域とスナップショット記憶域の両方を必要に応じて正しく準備するようになりました。
この章では、Oracle Rdbリリース7.2.1.4で修正されるソフトウェアの誤りについて説明します。
3.1 すべてのインタフェースに適用されるソフトウェアの誤りの修正
3.1.1 PIOUTL$SERVICE_PAGE_BLASTSでのCPUバウンド・ループ
Oracle Bug#6111009
ACMSサーバー・プロセスがCPUバウンド・ループに陥ります。プロセスまたは強制バグチェックのダンプから取得したPCサンプルは、ルーチンPIOUTL$SERVICE_PAGE_BLASTSの場所を示しています。
この問題は、ブロッキングASTの配信を防ぐ同期が失敗したものです。結果は、キュー（BLASTED_QUEUE）に要素（BCB）が2回挿入されたコードになり、キュー連鎖でループが生じます。
この問題は、Oracle Rdbリリース7.2.1.4で修正されました。この状況を防ぐために、インターロックされたテスト命令とともに新しいフラグ（BCB内）が追加されました。
3.1.2 ジグザグ一致の不正な結果
Oracle Bug#6126475
ジグザグ一致ストラテジを使用する問合せが不正な結果を返します（外部区間で索引T1_SC_PC_NDXを適用する概要bug_match_outlineを使用する場合）。
set flags 'strategy, detail, sort';
SELECT E.PCODE, P.PKEY
FROM T1 E,
T2 P
WHERE E.SCODE = 'AXA'
AND P.SNO = 4
AND E.SCODE = P.SCODE
AND E.PKEY = P.PKEY ;
~S: Outline "BUG_MATCH_OUTLINE" used
~S#0003
Tables:
0 = T1
1 = T2
Conjunct: (0.SCODE = 1.SCODE) AND (0.PKEY = 1.PKEY)
Match
Outer loop
Sort: 0.SCODE(a), 0.PKEY(a)
SortId# 4., # Keys 4
Item# 1, Dtype: 2, Order: 0, Off: 0, Len: 1
Item# 2, Dtype: 14, Order: 0, Off: 1, Len: 3
Item# 3, Dtype: 2, Order: 0, Off: 4, Len: 1
Item# 4, Dtype: 8, Order: 0, Off: 5, Len: 4
LRL: 32, NoDups:0, Blks:6, EqlKey:0, WkFls: 2
Leaf#01 BgrOnly 0:T1 Card=3
Bool: 0.SCODE = 'AXA'
BgrNdx1 T1_SC_PC_NDX [1:1] Fan=16
Keys: 0.SCODE = 'AXA'
Inner loop (zig-zag)
Index only retrieval of relation 1:T2
Index name T2_SC_SN_PK_NDX [2:2]
Keys: (1.SCODE = 'AXA') AND (1.SNO = 4)
0 rows selected
この問合せは、概要が索引T1_SC_PC_NDXではなくT1_SC_PK_PC_NDXを使用するように変更される場合は機能します。
create outline BUG_MATCH_OUTLINE
id '045E2C384D284FD1061D1BF58CF8872D'
mode 0
as (
query (
-- For loop
subquery (
T1 0 access path index
-- T1_SC_PC_NDX -- replace it with T1_SC_PK_PC_NDX
T1_SC_PK_PC_NDX
join by match to
T2 1 access path index
T2_SC_SN_PK_NDX
)
)
)
compliance optional ;
SELECT E.PCODE, P.PKEY
FROM T1 E,
T2 P
WHERE E.SCODE = 'AXA'
AND P.SNO = 4
AND E.SCODE = P.SCODE
AND E.PKEY = P.PKEY ;
~S: Outline "BUG_MATCH_OUTLINE" used
Tables:
0 = T1
1 = T2
Conjunct: (0.SCODE = 1.SCODE) AND (0.PKEY = 1.PKEY)
Match
Outer loop (zig-zag)
Index only retrieval of relation 0:T1
Index name T1_SC_PK_PC_NDX [1:1]
Keys: 0.SCODE = 'AXA'
Inner loop (zig-zag)
Index only retrieval of relation 1:T2
Index name T2_SC_SN_PK_NDX [2:2]
Keys: (1.SCODE = 'AXA') AND (1.SNO = 4)
E.PCODE P.PKEY
850 84900
850 84910
2 rows selected
この問合せでエラーの一因となったのは、主に次の部分です。
この問題は、Oracle Rdbリリース7.2.1.4で修正されました。
3.1.3 MISSING条件を使用した外部結合からの不正な結果
Oracle Bug#6404754
MISSING条件を使用する外部結合の問合せから不正な結果がレポートされていました。ユーザーの問合せは簡略化され、次のように再現されています。
create table TAB1 (COL1 CHAR(4));
create table TAB2 (COL1 CHAR(4));
insert into TAB1 values ('1030');
insert into TAB1 values ('1420');
insert into TAB2 values ('1030');
insert into TAB2 values ('1420');
commit;
! the following query should return 0 rows but returns 2 rows incorrectly:
!
SELECT *
FROM TAB1 AAA,
(SELECT TAB1.COL1 FROM TAB1, TAB2 WHERE TAB1.COL1 = TAB2.COL1(+) ) BBB
WHERE AAA.COL1 = BBB.COL1(+) AND BBB.COL1 IS NULL;
Tables:
0 = TAB1
1 = TAB1
2 = TAB2
Conjunct: MISSING (1.COL1)
Cross block of 2 entries (Left Outer Join)
Cross block entry 1
Get Retrieval sequentially of relation 0:TAB1
Cross block entry 2
Conjunct: MISSING (1.COL1) <== See NOTE below
Conjunct: 0.COL1 = 1.COL1
Merge of 1 entries
Merge block entry 1
Conjunct: MISSING (1.COL1) <== See NOTE below
Cross block of 2 entries (Left Outer Join)
Cross block entry 1
Get Retrieval sequentially of relation 1:TAB1
Cross block entry 2
Conjunct: 1.COL1 = 2.COL1
Get Retrieval sequentially of relation 2:TAB2
AAA.COL1 BBB.COL1
1030 NULL
1420 NULL
2 rows selected
注意: conjunctが左側外部結合の問合せの主な問合せから誤って引き下げられているため、不正な結果が生じます。
この問合せでエラーの一因となったのは、主に次の部分です。
この問題は、Oracle Rdbリリース7.2.1.4で修正されました。
3.2 SQLエラーの修正
3.2.1 ALTER TABLE ... ADD COLUMN文の後の予期しない列の並べ替え
Oracle Bug#6148536
以前のリリースのOracle Rdbでは、頻繁に変更される表に対するSHOW TABLEで、列が予期せず並べ替えられたことを示すことがありました。この異常な状況は、RDB$FIELD_IDの値が65535を超えると発生します。RDB$FIELD_IDの値がかなり大きい場合、これらの行のNULLビット・ベクターがかなり大きくなるため、このような表の本番での使用はお薦めしません。ALTER TABLE操作を何度も実行すると、RDB$FIELD_VERSIONS表の説明行も伝播され、Rdbサーバーによるメタデータのロードに影響を与えます。
RDB$FIELD_IDの値が大きい場合、行の後にすべてのフィールドを保持するのに十分なNULLビット・ベクターが続きます。圧縮が無効の場合、表の処理時に行が断片化され、必要以上のI/Oが生じます。そのため、この問題を正しく解決するには、表データをアンロードして、表を再作成します。SQL EXPORTとIMPORTも同じ結果になります。
予期しない並べ替えの原因は、RDB$FIELD_IDのサイズが16ビットのままになっているため、ALTER TABLEのAFTER COLUMN句とBEFORE COLUMN句をエンコードするために、RDB$FIELD_POSITIONの上位16ビットが使用されることが前提となっていました。オーバーフローは、列の並べ替えコマンドとして誤って解釈されていました。
この問題は、Oracle Rdbリリース7.2.1.4で修正されました。Oracle Rdbは、RDB$FIELD_ID列の値を使用せず、別の方法で並べ替えを管理するようになりました。
3.2.2 複合文を使用する場合、SET ALL CONSTRAINTSでSQLCODE -1005が発生する
Oracle Bug#462035および1403770
コンパイル済SQLまたはSQLモジュール言語プログラムが、アクティブなトランザクションを含まない文を実行すると同時に制約をすぐに評価しようとする場合、その文は失敗し、SQLCODE -1005とRdbの関連するエラー・メッセージ%RDB-E-BAD_TRANS_HANDLが発生します。通常、SQL文は複合文であるか、ストアド・プロシージャまたは外部プロシージャのコールです。このような文ではトランザクションがアクティブである必要がないためです。
たとえば、次のコンパイル済SQLプログラムは、そのトランザクションをコミットしてから、SQL複合文をすぐに実行します。この複合文は失敗し、SQLCODE -1005が発生します。
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
EXEC SQL DECLARE ALIAS FILENAME PERSONNEL;
EXEC SQL INCLUDE SQLCA;
main()
{
EXEC SQL set transaction;
printf("SET TRANS SQLCODE is %ld\n", SQLCA.SQLCODE);
EXEC SQL set all constraints on;
printf("SET ALL CONSTR ON SQLCODE is %ld\n", SQLCA.SQLCODE);
EXEC SQL commit;
printf("COMMIT SQLCODE is %ld\n", SQLCA.SQLCODE);
EXEC SQL begin set transaction; end;
printf("compound SQLCODE is %ld\n", SQLCA.SQLCODE);
}
この問題は、Oracle Rdbリリース7.2.1.4で修正されました。
3.2.3 分散トランザクションのGET DIAGNOSTICSによって、トランザクションが非分散トランザクションになる
Oracle Bug#972038
特定の状況では、GET DIAGNOSTICS文を含む複合文によって、TRANSACTION_DEFAULT=DISTRIBUTEDで組み込まれた、コンパイル済SQLまたはSQLモジュール言語プログラムが非分散トランザクションを起動していました。複合文でも、トランザクションのコンテキストが必要な文（INSERTなど）を必要としていました。このようにアクティブな分散トランザクションがない場合、SQL$PREまたはSQL$MODプログラムは、複合文を実行する前にトランザクションを開始しません。このため、サーバーはデータベースのアタッチに対して非分散トランザクションを暗黙的に開始していました。
たとえば、次のコンパイル済CコードがTRANSACTION_DEFAULT=DISTRIBUTEDというSQLOPTIONでコンパイルされたプログラムの場合、この状況が発生していました。
...
EXEC SQL DECLARE ALIAS FILENAME PERSONNEL;
...
main ()
{
long rc;
long status;
short iosb[4];
long flag = 2;
long tid[4];
...
status = sys$start_transw(
0, /* efn */
flag, /* flags */
iosb, /* iosb */
0, /* astadr */
0, /* astprm */
tid /* tid */
);
...
EXEC SQL BEGIN
update employees set last_name = 'Toliver'
where employee_id = '00164';
get diagnostics :rc = row_count;
END;
printf("row count = %d\n", rc);
...
status = sys$end_transw(
0, /* efn */
0, /* flag */
iosb, /* iosb */
0, /* astadr */
0, /* astprm */
tid /* tid */
);
...
}
前述の例では、複合文にGET DIAGNOSTICS文があると、クライアント・プログラムはSYS$START_TRANSW()のコールで開始された分散トランザクションと自動的に結合しません。PERSONNELデータベースに対して進行中のRdbトランザクションがないため、Rdbサーバーは、アプリケーションの分散トランザクションとは別の1フェーズ・トランザクションを暗黙的に開始します。SYS$END_TRANSW()のコールは、Rdbトランザクションをコミットしません。これが分散トランザクションに参加するブランチ内にないためです。
TRANSACTION_DEFAULT=DISTRIBUTEDを指定する場合にコードが生成されるようにSQL$PREおよびSQL$MODが変更されました。これにより、GET DIAGNOSTICS文を含む複合文を実行する前に、既存の分散トランザクションを暗黙的に結合します。
この問題を回避するには、このような複合文の実行時に分散トランザクションがアクティブであることを確認します。
この問題は、Oracle Rdbリリース7.2.1.4で修正されました。
3.2.4 IMPORT DATABASEコマンドでコマンドラインの一部のデータベース属性が失われる
Oracle Bug#6311200
以前のリリースのOracle Rdbでは、SQLのIMPORT DATABASEコマンドが、SHARED MEMORY IS PROCESS RESIDENT句、またはGLOBAL BUFFERS ARE ENABLED句のLARGE MEMORY IS ENABLED属性を正しく継承しませんでした。対応する属性は、常に交換ファイル（.RBR）から継承されていました。
これは、Oracle Rdbリリース7.2.1.4で修正されました。ただし、回避するには、IMPORT DATABASEコマンドの直後にALTER DATABASE文を使用してこれらの属性を設定します。RMU/EXTRACT/ITEM=DATABASEコマンドを使用して、これらの設定を検証できます。
3.2.5 設定フラグTRANSACTIONで、グローバル・トランザクションIDが表示される
Oracle Bug#3107989
フラグTRANSACTIONが分散（別名2フェーズ・コミット）トランザクションの開始時に定義される場合、Oracle Rdbはこのデータベース・トランザクションに関連付けられたグローバル・トランザクションIDを表示するようになりました。これにより、分散トランザクションに関連する統計が収集されます。
次の例に示すように、「~T Start_transaction」ログ・メッセージの直後に「~T Global transaction id:」で始まる行が表示されます。
$ DEFINE RDMS$SET_FLAGS TRANSACTION $ SQL$ SQL> ATTACH 'ALIAS A FILENAME DB$:MF_PERSONNEL'; SQL> ATTACH 'ALIAS B FILENAME DB$:PERSONNEL'; SQL> START TRANSACTION READ WRITE; ~T Compile transaction (1) on db: 1 ~T Transaction Parameter Block: (len=2) 0000 (00000) TPB$K_VERSION = 1 0001 (00001) TPB$K_WRITE (read write) ~T Start_transaction (1) on db: 1, db count=2 ~T Global transaction id: 34C08373-41E3-11DC-ABB9-0008021A53CE ~T Compile transaction (1) on db: 2 ~T Transaction Parameter Block: (len=2) 0000 (00000) TPB$K_VERSION = 1 0001 (00001) TPB$K_WRITE (read write) ~T Start_transaction (1) on db: 2, db count=2 ~T Global transaction id: 34C08373-41E3-11DC-ABB9-0008021A53CE SQL>
トランザクションが分散されない場合、この情報は表示されません。TEST_SYSTEMフラグを使用すると、この情報は無効になります。
この問題は、Oracle Rdbリリース7.2.1.4で修正されました。
3.2.6 IMPORT DATABASEコマンドからの予期しないバグチェック
Oracle Bug#6313120
Oracle Rdbリリース7.1.4以降では、CREATE STORAGE MAP文で定義されるマッピングを反映する新しいシステム・ルーチンが作成されます。これらの特殊なルーチンは、CREATE STORAGE MAPによって自動的に生成されるため、手動で作成する必要はありません。7.1.4以降のバージョンのSQLのEXPORT DATABASEコマンドでは、交換ファイル（.rbr）から特別にマーク付けされた記憶域マッピング関数が省略されます。
ただし、比較的古いバージョンのSQLが交換ファイルの作成に使用される場合（複数バージョンのリリース7.0が同じシステムにインストールされる場合など）、結果として作成される交換ファイルにはこれらのルーチンのコピーが含まれます。
以前のリリースでは、このような交換ファイルの処理時にSQLのIMPORT DATABASEでバグチェックが発生していました。これらのダンプには、次の例のような内容が含まれていました。
この問題は、Oracle Rdbリリース7.2.1.4で修正されました。SQLのIMPORT DATABASEでは、重複するルーチンをインポートしようとすると、次のようなメッセージが生成されるようになりました。
%SQL-F-NOMODRES, unable to import module RDB$STORAGE_MAPS %RDB-E-NO_META_UPDATE, metadata update failed -RDMS-E-RTNEXTS, there is another routine named EMPLOYEE_HISTORY in this database
Oracle Bug#486335
特定の状況では、RDBPRE/COBOLプログラムをコンパイルすると、生成されたレコード定義に重複した名前を含むコードが生成されていました。結果として作成されるCOBOLコードがCOBOLコンパイラに送信された場合、重複した名前のフィールドが使用された時点で次のエラー・メッセージが生成されていました。
%COBOL-F-AMBIGSYM, Ambiguous reference - check name qualification ...
重複した名前のレコード構造は、データベース間の更新の際に中間結果を保存するためにRDBPREで使用されました。この問題は、ソース・データベースの列に、他のデータベースの対応するターゲット列とは異なる型やサイズがある場合に明示されていました。たとえば、次のSQL文で定義される一組のRdbデータベースについて考えてみます。
create database filename essai1
create table a_table (
a_zone1 SMALLINT,
a_zone2 SMALLINT,
a_zone3 INTEGER (2));
disconnect all;
create database filename essai
create table b_table (
b_zone1 SMALLINT,
b_zone2 INTEGER (3),
b_zone3 SMALLINT (1));
disconnect all;
次のRDBPRE/COBOLプログラムから生成されたコードには、重複した名前のレコード定義が含まれています。
IDENTIFICATION DIVISION.
PROGRAM-ID. tst.
ENVIRONMENT DIVISION.
DATA DIVISION.
WORKING-STORAGE SECTION.
*
&RDB& INVOKE DATABASE b = FILENAME "essai"
&RDB& INVOKE DATABASE a = FILENAME "essai1"
*
PROCEDURE DIVISION.
DEB-PROG.
&RDB& START-TRANSACTION ON B USING (READ-WRITE
&RDB& RESERVING b.b_table FOR SHARED READ)
&RDB& AND ON A USING (READ-WRITE
&RDB& RESERVING a.a_table FOR SHARED WRITE)
&RDB& FOR EC IN b.b_table
&RDB& WITH EC.b_zone1 = 0
&RDB& STORE ECC IN a.a_table USING
&RDB& ECC.a_zone2 = EC.b_zone2;
&RDB& ECC.a_zone3 = EC.b_zone3;
&RDB& END_STORE
&RDB& END_FOR
&RDB& COMMIT
stop run.
この問題を回避するには、STORE文の列の順序を並べ替えます。
この問題は、Oracle Rdbリリース7.2.1.4で修正されました。
3.3.2 RDBPRE/COBOLと式のリテラルを使用する場合に%RDB-F-ARITH_EXCEPTが発生する
Oracle Bug#560785
STOREまたはMODIFYにリテラルを含む演算式がある場合、RDBPRE/COBOLで不正なコードが生成されていました。特に、生成されたコードでは、BLRメッセージと、そのメッセージに対して生成されたCOBOLレコードの対応する項目との間で型が一致していませんでした。このため、実行時に%RDB-F-ARITH_EXCEPTまたは-COSI-F-INTOVF（あるいはその両方）などのエラー・メッセージが頻繁に発生していました。
次のプログラムの例はこの問題を示しており、MAXIMUM_SALARYフィールドとMINIMUM_SALARYフィールドの型が符号付きの単語スケール0になるようにJOBSリレーションを変更したPERSONNELデータベースを使用しています。SQL$SAMPLESのJOBS.RCOプログラムは、次のように変更されます。
01 WS-SAL-MIN PIC S9(4) COMP. 01 WS-SAL-MAX PIC S9(4) COMP.
STORE-JOBS.
MOVE 1 TO WS-SAL-MIN.
MOVE 1 TO WS-SAL-MAX.
&RDB& STORE J IN JOBS
&RDB& USING
&RDB& J.JOB_CODE = J-CODE;
&RDB& J.WAGE_CLASS = W-CLASS;
&RDB& J.JOB_TITLE = J-TITLE;
&RDB& J.MINIMUM_SALARY = WS-SAL-MIN + 1;
&RDB& J.MAXIMUM_SALARY = WS-SAL-MAX + 2;
&RDB& END_STORE
変更されたJOBS.RCOプログラムをコンパイルしてリンクすると、結果として作成されるコードでは、生成されたCOBOLレコードの最小給与フィールドおよび最大給与フィールドとBLRのメッセージとの間に不一致が生じます。このため、ランタイム・エラーが発生していました。
この問題は、Oracle Rdbリリース7.2.1.4で修正されました。
3.4 RMUエラーの修正
3.4.1 RMU/RESTOREまたは/DUMP/BACKUPのバグチェック
Oracle Bug#6001187
RMUが保存セットの破損を検出すると、対話しているユーザーに対してQUITまたはCONTINUEのいずれかを求めるプロンプトが表示されます。場合によって、プロンプト・メッセージが書き出される前にコマンドがACCVIOで終了するか、またはユーザーがQUITまたはCONTINUE以外のレスポンスを入力すると、ACCVIOが表示されます。
例1:
$ RMU/DUMP/BACK MFP.RBF %RMU-I-DMPTXT_163, No dump option selected. Performing read check. %RMU-E-READERR, error reading USER:[USERDIR]MFP.RBF; -RMU-E-BLOCKCRC, software block CRC error %RMU-E-INVBLKSIZ, invalid block size in backup file %RMU-E-INVRECSIZ, invalid record size in backup file %RMU-E-READERRS, excessive error rate reading USER:[USERDIR]MFP.RBF; -RMU-E-BLOCKCRC, software block CRC error %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=...
例2:
$ RMU/DUMP/BACK MFP.RBF %RMU-I-DMPTXT_163, No dump option selected. Performing read check. %RMU-E-READERR, error reading USER:[USERDIR]MFP.RBF; -RMU-E-BLOCKCRC, software block CRC error %RMU-E-INVBLKSIZ, invalid block size in backup file %RMU-E-INVRECSIZ, invalid record size in backup file %RMU-E-READERRS, excessive error rate reading USER:[USERDIR]MFP.RBF; -RMU-E-BLOCKCRC, software block CRC error %RMU-I-SPECIFYC, specify option (QUIT or CONTINUE) RMU> exit %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=...
RMUがIA64システムで保存セットの破損を検出した場合、ユーザーがQUITで応答するとバグチェックが発生します。その後、エラー・メッセージの書出しがループします。
例3:
$ RMU/RESTORE MFP.RBF %RMU-E-READERRS, excessive error rate reading IVMS_USER1:[FROEHLIN.TEST4]MFP.RBF; -RMU-E-BLOCKCRC, software block CRC error %RMU-I-SPECIFYC, specify option (QUIT or CONTINUE) RMU> quit %COSI-F-BUGCHECK, internal consistency failure %RMU-F-FATALOSI, Fatal error from the Operating System Interface. %RMU-I-BUGCHKDMP, generating bugcheck dump file USER:[USERDIR]RMUBUGCHK.DMP; %RMU-F-FTL_RSTR, Fatal error for RESTORE operation at ... %COSI-F-BUGCHECK, internal consistency failure ...loops with the following lines %RMU-F-FATALOSI, Fatal error from the Operating System Interface. %COSI-F-BUGCHECK, internal consistency failure
この問題の理由の1つに、プロンプト文字列の無効な記述子がありました。IA64上のループは、不適切な条件ハンドラによって生じていました。
これらの問題は、Oracle Rdbリリース7.2.1.4で修正されました。
3.4.2 RMU/CONVERTがリリース7.0以下のシステム・メタデータを削除できない
Oracle Bug#6270091
リリース7.2のRMU/CONVERTには、リリース7.0以下の古いシステム・メタデータを削除できないという制限事項がありました。リリース6.1以下の場合、古いメタデータを削除するのではなく、変換が終了すると、データベースが破損し、次のエラーが出力されていました。
$ RMU/CONVERT/COMMIT MF_PERSONNEL %RMU-I-RMUTXT_000, Executing RMU for Oracle Rdb V7.2-00 %RMU-I-LOGCONVRT, database root converted to current structure version %RMU-E-CANTCVRT, cannot convert this database version %RMU-F-FTL_CNV, Fatal error for CONVERT operation at 7-AUG-2007 22:14:50.50
この問題は修正されました。リリース6.1以下の古いメタデータは削除され、変換が正常に終了するようになりました。このような問題は、変換前にデータベースをバックアップすることの重要性を示しています。
RMU/CONVERT/NOCOMMITまたはRMU/RESTORE/NOCOMMITを指定して、データベースを新しいメタデータ・バージョンに変換してその変換をテストできるようにする場合、古い代替のメタデータをOracle Rdbデータベースに残しておくことができます。ただし、RMU/CONVERT/COMMITまたはRMU/RESTORE/COMMITを指定して次のバージョンに移行する前に変換はコミットされません。COMMITがデフォルトであることに注意してください。/NOCOMMITを指定すると、データベースにメタデータの2つのコピー（新しい現在のバージョンと以前の代替バージョン）が保持されます。新しい現在のメタデータ・バージョンのテストが完了すると、ユーザーはRMU/CONVERT/COMMITまたはRMU/RESTORE/COMMITを指定して、古い代替メタデータを削除し、新しい現在のメタデータのみを保持できます。あるいはユーザーに問題がある場合、RMU/CONVERT/ROLLBACKを実行して新しい現在のメタデータ・バージョンを削除し、以前の代替メタデータ・バージョンを現在のメタデータ・バージョンとしてリストアできます。もちろん、/ROLLBACKを実行する場合、データベースにアクセスするには以前のバージョンのRdbを使用する必要があります。
データベースの変換が次のバージョンに移行する前にコミットされない場合、古い代替バージョンのメタデータがデータベースに保持されます。このデータベースでは、不要になった論理領域が使用されます。この問題は修正されましたが、リリース6.1以下の古い代替メタデータを削除する必要がある場合、変換も失敗していました。
新しいバージョンに移行する際にCONVERTコードが実行するのは（/NOCOMMITの場合であっても）、最初のパスを出して既存の代替メタデータを削除することです。これは、現在のデータベース設計で保存できるのは現在のメタデータ・バージョンと以前のメタデータ・バージョンのみであり、以前のバージョンのメタデータを新しい代替メタデータとして保存する必要があるためです。たとえば、現在のリリース6.0のメタデータ（6.0/0の現在のバージョンと代替バージョン）のみが含まれるリリース6.0のデータベースで考えてみます。RMU/CONVERT/NOCOMMITを7.0にする場合、データベースにはリリース7.0とリリース6.0のメタデータがあります。ただし、RMU/CONVERT/NOCOMMITを7.1にする場合、最初に6.0の古い代替メタデータを削除し、最後にリリース7.1とリリース7.0のメタデータをデータベースに残します。このバグで修正された問題の一例として、6.1/0の現在のバージョンと代替バージョンのメタデータを含むリリース6.1のデータベースがありました。RMU/CONVERT/NOCOMMITをバージョン7.1にすると、リリース7.1とリリース6.1のメタデータがデータベースに作成されます。RMU/CONVERT/NOCOMMITをリリース7.2にすると、リリース7.2とリリース7.1のメタデータが作成されますが、古いリリース6.1のメタデータを最初に削除する必要があります。RMU/CONVERT/NOCOMMITをリリース72にすると、リリース7.2/0のメタデータが作成されます。どちらの場合も、古いリリース6.1のメタデータを削除する必要があり、RMU/CONVERTはリリース6.1以下のメタデータを処理できないため、変換は失敗します。
リリース6.1とリリース6.0のメタデータ・バージョンについては、すべてのメタデータとそのメタデータの論理領域が削除されるようになりました。ただし、リリース5.1以下のメタデータ・バージョンの場合、古いメタデータのポインタは削除されますが、実際の古いメタデータとそのメタデータを含む論理領域は削除されません。ただし、データベースは有効であるため、変換は正常に行われます。ここで示す現在のメタデータと代替メタデータには、ユーザー作成の表や索引は含まれませんが、内部Rdbデータベース構造を定義する、Oracle Rdbで作成されたシステム表や索引を参照します。
次の例は、修正された問題を示しています。6.0/0の現在および代替メタデータのバージョンで開始するデータベースで、/NOCOMMITをRdbリリース7.1に変換した場合、現在および代替メタデータのバージョンは7.1と6.0になります。/COMMIT（デフォルト）をRdbリリース7.2に変換すると、RMU/CONVERTはリリース7.0以下の古いバージョンのメタデータを削除できないため、変換は失敗していました。
$ @SYS$LIBRARY:RDB$SETVER 6.0 $ RMU/RESTORE/NOLOG/NOCDD/DIRECTORY=DEVICE:[DIRECTORY] - DEVICE:[DIRECTORY.60]MF_PERSONNEL.RBF %RMU-I-AIJRSTAVL, 0 after-image journals available for use %RMU-I-AIJISOFF, after-image journaling has been disabled %RMU-W-USERECCOM, Use the RMU/RECOVER command. The journals are not available. $ @SYS$LIBRARY:RDB$SETVER 7.1 $ RMU/CONVERT/NOCOMMIT MF_PERSONNEL %RMU-I-RMUTXT_000, Executing RMU for Oracle Rdb V7.1-00 %RMU-I-LOGCONVRT, database root converted to current structure version %RMU-S-CVTDBSUC, database DEVICE:[DIRECTORY]MF_PERSONNEL.RDB;1 successfully converted from version V6.0 to V7.1 $ @SYS$LIBRARY:RDB$SETVER 7.2 $ RMU/CONVERT/COMMIT MF_PERSONNEL %RMU-I-RMUTXT_000, Executing RMU for Oracle Rdb V7.2-00 %RMU-I-LOGCONVRT, database root converted to current structure version %RMU-E-CANTCVRT, cannot convert this database version %RMU-F-FTL_CNV, Fatal error for CONVERT operation at 7-AUG-2007 22:14:49.68
この問題を回避するには、データベースを次のRdbバージョンに変換する前に、現在のRdbバージョンでデータベースのRMU/CONVERT/COMMITを実行します。
この問題は、Oracle Rdbリリース7.2.1.4で修正されました。
3.4.3 /BLOCKS_PER_PAGEを使用する場合、RMU /MOVE_AREAまたは/COPY_DATABASEが失敗する
/BLOCKS_PER_PAGE修飾子を使用する場合、RMU /MOVE_AREAまたはRMU /COPY_DATABASEコマンドが失敗することがあります。実際の失敗の現象として、予期しないバグチェックが発生します。問題の原因は、割り当てられたデータ構造の限度を超えて記述する不正なコードに関連していました。
回避するには、/BLOCKS_PER_PAGE修飾子を使用しないようにしてください。
この問題は、Oracle Rdbリリース7.2.1.4で修正されました。
3.4.4 索引が存在しない場合にRMU/COLLECT/INDEXESがエラーを返さない
Oracle Bug#6316729
RMU/COLLECT OPTIMIZER_STATISTICS /INDEX=(A,B,C)またはRMU/SHOW OPTIMIZER_STATISTICS /INDEX=(A,B,C)に対して、Oracle Rdbデータベースに存在しない索引名が与えられた場合、その索引を無視して続行し、エラーが返されませんでした。
この問題は修正されました。ユーザーがデータベースに存在しない名前の索引を指定すると、RMU/COLLECT OPTIMIZERまたはRMU/SHOW OPTIMIZERコマンドは中断し、エラーが返されるようになりました。
$ rmu/collect opt mf_personnel /notables /log /index=bad_name Start loading tables... at 28-AUG-2007 16:16:14.54 Done loading tables.... at 28-AUG-2007 16:16:14.54 Start loading indexes... at 28-AUG-2007 16:16:14.54 %RMU-F-INDNOTFND, index BAD_NAME does not exist in this database %RMU-F-FTL_COL_STAT, Fatal error for COLLECT OPTIMIZER_STATISTICS operation at 28-AUG-2007 16:16:14.54
次の例は、修正された問題を示しています。指定の索引bad_nameが存在しない場合でも、RMU/COLLECT OPTIMIZER_STATISTICSはエラーを返さず続行し、索引を無視します。
$ rmu/collect opt mf_personnel /notables /log /index=bad_name Start loading tables... at 28-AUG-2007 16:14:21.04 Done loading tables.... at 28-AUG-2007 16:14:21.05 Start loading indexes... at 28-AUG-2007 16:14:21.05 Done loading indexes.... at 28-AUG-2007 16:14:21.06 Start collecting btree index stats... at 28-AUG-2007 16:14:21.12 Done collecting btree index stats.... at 28-AUG-2007 16:14:21.12 Start collecting table & hash index stats... at 28-AUG-2007 16:14:21.12 Done collecting table & hash index stats.... at 28-AUG-2007 16:14:21.12 Start collecting workload stats... at 28-AUG-2007 16:14:21.17 Maximum memory required (bytes) = 0 Done collecting workload stats.... at 28-AUG-2007 16:14:21.18 Start calculating stats... at 28-AUG-2007 16:14:21.18 Done calculating stats.... at 28-AUG-2007 16:14:21.18 Start writing stats... at 28-AUG-2007 16:14:21.21 Done writing stats.... at 28-AUG-2007 16:14:21.21
この問題は、Oracle Rdbリリース7.2.1.4で修正されました。
3.4.5 RMU OPTIMIZER_STATISTICSコマンドが不正で致命的なエラー終了メッセージを返す
RMU/COLLECT OPTIMIZER_STATISTICS、RMU/DELETE OPTIMIZER_STATISTICSおよびRMU/INSERT OPTIMIZER_STATISTICSが、実行する操作を正しく指定しない、致命的なエラー終了メッセージを返していました。エラーは正しく処理されましたが、Oracle RdbのRMUが終了する前に出力された致命的なメッセージが正しくありませんでした。
この問題は修正されました。特定のコマンド操作に該当する致命的なエラー終了メッセージが出力されるようになりました。
$ rmu/collect optimizer_statistics baddb %RMU-W-BADDBNAME, can't find database root DEVICE:[DIRECTORY]BADDB.RDB; -RMS-E-FNF, file not found %RMU-F-CANTOPNROO, cannot open root file "BADDB" %RMU-F-FTL_COL_STAT, Fatal error for COLLECT OPTIMIZER_STATISTICS operation at 29-AUG-2007 15:44:07.54 $ rmu/delete optimizer_statistics baddb %RMU-W-BADDBNAME, can't find database root DEVICE:[DIRECTORY]BADDB.RDB; -RMS-E-FNF, file not found %RMU-F-CANTOPNROO, cannot open root file "BADDB" %RMU-F-FTL_DEL_STAT, Fatal error for DELETE OPTIMIZER_STATISTICS operation at 29-AUG-2007 15:44:30.18 $ rmu/insert optimizer_statistics baddb %RMU-W-BADDBNAME, can't find database root DEVICE:[DIRECTORY]BADDB.RDB; -RMS-E-FNF, file not found %RMU-F-CANTOPNROO, cannot open root file "BADDB" %RMU-F-FTL_INS_STAT, Fatal error for INSERT OPTIMIZER_STATISTICS operation at 29-AUG-2007 15:44:50.48
次の例は、修正された問題を示しています。致命的なエラー終了メッセージ%RMU-F-FTL_ANAがRMUから返されました。これは実行するコマンド操作を正しく表していませんでした。
$ rmu/collect optimizer_statistics baddb %RMU-W-BADDBNAME, can't find database root DEVICE:[DIRECTORY]BADDB.RDB; -RMS-E-FNF, file not found %RMU-F-CANTOPNROO, cannot open root file "BADDB" %RMU-F-FTL_ANA, Fatal error for ANALYZE operation at 29-AUG-2007 15:33:52.70 $ rmu/delete optimizer_statistics baddb %RMU-W-BADDBNAME, can't find database root DEVICE:[DIRECTORY]BADDB.RDB; -RMS-E-FNF, file not found %RMU-F-CANTOPNROO, cannot open root file "BADDB" %RMU-F-FTL_ANA, Fatal error for ANALYZE operation at 29-AUG-2007 15:34:05.65 $ rmu/insert optimizer_statistics baddb %RMU-W-BADDBNAME, can't find database root DEVICE:[DIRECTORY]BADDB.RDB; -RMS-E-FNF, file not found %RMU-F-CANTOPNROO, cannot open root file "BADDB" %RMU-F-FTL_ANA, Fatal error for ANALYZE operation at 29-AUG-2007 15:34:19.03
この問題は、Oracle Rdbリリース7.2.1.4で修正されました。
3.4.6 RMU/CONVERTで指定しない型のシステム論理領域が作成される
Oracle Bug#6390145
Oracle RdbのRMU/CONVERTでは、Rdbデータベースを現在のバージョンに変換する場合、システム表やシステム索引の論理領域を作成する際に論理領域の型を指定しませんでした。このため、データベースの変換時に、システム表と索引を含む論理領域にUNKNOWN型が与えられていました。これが原因でデータベースが破損することはありませんでしたが、RMU/SHOW AIPなどのコマンドで論理領域の型にUNKNOWNが表示されていました。RMU/CONVERTで作成されたシステム表と索引を含む論理領域の型は、TABLEおよびSORTED INDEXが正しい型です。
この問題は、次の例に示すように修正されました。RMU/CONVERTで作成される新しいシステム論理領域に正しい型が指定されました。
$ rmu/convert/noconfirm mf_personnel %RMU-I-RMUTXT_000, Executing RMU for Oracle Rdb V7.2-nn %RMU-I-LOGCONVRT, database root converted to current structure level %RMU-S-CVTDBSUC, database DEVICE:[DIRECTORY]MF_PERSONNEL.RDB;1 successfully converted from version V7.1 to V7.2 %RMU-I-CVTCOMSUC, CONVERT committed for DEVICE:[DIRECTORY]MF_PERSONNEL.RDB;1 to version V7.2 $ rmu/show aip/brief mf_personnel *----------------------------------------------------------------------------- * Logical Area Name LArea PArea Len Type *----------------------------------------------------------------------------- RDB$PROFILES 114 1 140 TABLE RDB$GRANTED_PROFILES 115 1 28 TABLE RDB$TYPES 116 1 148 TABLE RDB$TYPE_FIELDS 117 1 148 TABLE RDB$WORKLOAD 118 1 75 TABLE RDB$TRIGGER_ACTIONS 119 1 84 TABLE RDB$NDX_NDX_NAME_NDX 120 1 219 SORTED INDEX RDB$NDX_REL_NAME_NDX 121 1 219 SORTED INDEX RDB$NDX_SEG_NAM_FLD_POS_NDX 122 1 219 SORTED INDEX RDB$REL_REL_NAME_NDX 123 1 219 SORTED INDEX RDB$VER_REL_ID_VER_NDX 124 1 219 SORTED INDEX
次の例は、修正された問題を示しています。RMU/CONVERTで作成される新しいシステム論理領域に指定される型はありませんでした。
$ rmu/convert/noconfirm mf_personnel %RMU-I-RMUTXT_000, Executing RMU for Oracle Rdb V7.2-nn %RMU-I-LOGCONVRT, database root converted to current structure level %RMU-S-CVTDBSUC, database DEVICE:[DIRECTORY]MF_PERSONNEL.RDB;1 successfully converted from version V7.1 to V7.2 %RMU-I-CVTCOMSUC, CONVERT committed for DEVICE:[DIRECTORY]MF_PERSONNEL.RDB;1 to version V7.2 $ rmu/show aip/brief mf_personnel *----------------------------------------------------------------------------- * Logical Area Name LArea PArea Len Type *----------------------------------------------------------------------------- RDB$PROFILES 114 1 140 UNKNOWN RDB$GRANTED_PROFILES 115 1 28 UNKNOWN RDB$TYPES 116 1 148 UNKNOWN RDB$TYPE_FIELDS 117 1 148 UNKNOWN RDB$WORKLOAD 118 1 75 UNKNOWN RDB$TRIGGER_ACTIONS 119 1 84 UNKNOWN RDB$NDX_NDX_NAME_NDX 120 1 219 UNKNOWN RDB$NDX_REL_NAME_NDX 121 1 219 UNKNOWN RDB$NDX_SEG_NAM_FLD_POS_NDX 122 1 219 UNKNOWN RDB$REL_REL_NAME_NDX 123 1 219 UNKNOWN RDB$VER_REL_ID_VER_NDX 124 1 219 UNKNOWN
この問題は、Oracle Rdbリリース7.2.1.4で修正されました。
3.4.7 RMU/VERIFY/LOGのVMS終了ステータスが正しくない
Oracle Bug#6315971
RMU/VERIFY/LOGが指定された状態で、Oracle Rdbデータベースの検証時にエラーや警告が発生しない場合、VMS終了ステータスが、成功のステータスではなく重大度Informationalのログ・メッセージに誤って設定されていました。これは、/LOGが指定されない場合は発生しませんでした。この問題は修正されました。/LOGが指定されない場合と同様に/LOGが指定された場合も、成功のステータスが出力されるようになりました。
次の例は、修正された問題を示しています。/LOGが指定されない場合、RdbデータベースのRMU/VERIFYが成功すると、VMS成功の終了ステータスが表示されますが、/LOGが指定された場合、終了ステータスは、情報を示すログ・メッセージになっていました。どちらの場合も、現在はVMS成功の終了ステータスが設定されるようになりました。
$ rmu/verify/all mf_personnel $ show symbol $status $STATUS == "%X10000001" $ rmu/verify/all/log mf_personnel %RMU-I-BGNROOVER, beginning root verification %RMU-I-ENDROOVER, completed root verification %RMU-I-BGNVCONST, beginning verification of constraints for database DEVICE:[DIRECTORY]MF_PERSONNEL.RDB;1 %RMU-I-ENDVCONST, completed verification of constraints for database DEVICE:[DIRECTORY]MF_PERSONNEL.RDB;1 %RMU-S-ENDVERIFY, elapsed time for verification : 0 00:00:02.22 $ show symbol $status $STATUS == "%X12C8B51B"
この問題は、Oracle Rdbリリース7.2.1.4で修正されました。
3.5 LogMinerエラーの修正
3.5.1 RMU/UNLOAD/AFTER_JOURNALのソート作業ファイルのサイズの縮小
RMU/UNLOAD/AFTER_JOURNALは、ソート操作を実行して、抽出する各トランザクションの重複するレコードの変更を削除します。特定の状況では（特にデータベース内のレコード圧縮が使用された場合）、RMUはソートする最大レコード長を多めに見積るため、ディスク上のソート一時作業ファイルの割当てが必要以上になっていました。
この問題は、Oracle Rdbリリース7.2.1.4で修正されました。ソートする最大レコード・サイズが、より正確に計算されるようになりました。これは、ソート作業ファイルのサイズの縮小と、作業ファイルのIOの防止に役立ちます。
3.5.2 RMU/UNLOAD/AFTER_JOURNALの/QUICK_SORT_LIMIT修飾子
RMU/UNLOAD/AFTER_JOURNALは、ソート操作を実行して、抽出する各トランザクションの重複するレコードの変更を削除します。ソートのカーディナリティが少ない場合は、内部インメモリーのクイック・ソート・アルゴリズムが使用されます。それ以外の場合は、SORT32アルゴリズムが使用されます。以前は、クイック・ソート・ルーチンを使用する場合、修正された5000レコードという値の制限がありました。
しきい値に対して修正された値に関するこの制限は、Oracle Rdbリリース7.2.1.4で緩和されました。インメモリー・アルゴリズムでソートする最大レコード数を明示的に制御できるように、新しい修飾子/QUICK_SORT_LIMIT=nが提供されました。デフォルト値は5000です。最小値は10、最大値は100,000です。
/QUICK_SORT_LIMIT修飾子に指定した値が大きいほど、CPU時間とメモリー消費を増やしてソート作業ファイルのIOを軽減できます。値が小さすぎると、ディスク・ファイルのIOが増加します。通常は、デフォルト値が受け入れられます。
3.6 RMU Show Statisticsのエラーの修正
3.6.1 「File IO Statistics」画面でファイル名が上書きされる
Oracle Bug#6319121
Oracle Rdbリリース7.2.1以降では、ファイル名がRMU /SHOW STATISTICSユーティリティの「File IO Statistics」画面に表示されません。この問題は、統計の見出し行が極端に変わることで生じていました。
この問題は、Oracle Rdbリリース7.2.1.4で修正されました。ファイル名は上書きされなくなりました。
3.6.2 「Device Information」画面を上方向に移動する際のバグチェック
Oracle Bug#6319159
Oracle Rdbリリース7.2.1以降では、（[Page Up]キーを使用して）「Device Information」画面を上方向に移動すると、RMU /SHOW STATISTICSユーティリティでバグチェックが発生することがあります。この問題は、上方向に移動するときに内部データ構造が正しく構成されないことが原因で発生していました（画面の下方向に移動する場合は発生しません）。
この問題は、Oracle Rdbリリース7.2.1.4で修正されました。
3.6.3 RMU/SHOW STATISTICS /INPUT= Possibleのエラーまたはバグチェック
Oracle Bug#6339722
Oracle Rdbリリース7.2.1以降では、RMU /SHOW STATISTICSユーティリティを入力バイナリ・ファイルとともに使用すると、入力ファイルの読取り時にエラーが発生することがあります。また、画面見出しの2行目のElapsed:時間表示フィールドが空白になることが頻繁にありました。
考えられる回避策として、バイナリ・ファイルを読み書きするRMUコマンドで/NOLOGICAL_AREA修飾子を使用して問題を防止できます。
これらの問題は、Oracle Rdbリリース7.2.1.4で修正されました。バイナリ入力ファイルは正しく処理されます。
この章では、Oracle Rdbリリース7.2.1.3で修正されるソフトウェアの誤りについて説明します。
4.1 すべてのインタフェースに適用されるソフトウェアの誤りの修正
4.1.1 複数のデータベースがアタッチされる場合の共有メモリーの破損
Oracle Bug#5841667
Oracle Rdbリリース7.1.4とOracle Rdbリリース7.2以降では、共有メモリーが破損することがありました。1つのRdbルート・ファイルのデータが別のデータベースの共有メモリーに書き込まれると（あるいはこれが原因で）、頻繁に破損していました。破損が起こると、データベースとデータベース・ユーザーの信頼性や機能性が危険にさらされる可能性があります。
この破損を引き起こす状況は次のとおりです。
メモリー破損は、共有メモリーへのルート・ファイル情報の更新中に、I/Oバッファの不正な同期が原因で発生していました。
この問題は、Oracle Rdbリリース7.2.1.3で修正されました。
注意
一度に複数のデータベースにアタッチするアプリケーションやプロシージャを使用するユーザーは、メモリー破損の問題が起こらないようにOracle Rdbリリース7.2.1.3以上にアップグレードすることを強くお薦めします。
Oracle Bug#6152325
TCP/IPプロトコルを使用して、内部セキュリティ・チェックに構成されるデータベースにリモートでアタッチする場合、バグチェックまたはバグチェックのダンプが生成されていました。
***** Exception at 0000000000A7730C : RDMSHRP72\RDMS$$DML$READY + 0000005C %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=00000000000001D4, PC=0000000000A7730C, PS=00000009
この問題は、Oracle Rdbリリース7.2.1.3で修正されました。
4.1.3 RDB$DATABASEシステム表に関する複雑な問合せからの不正な結果
Oracle Bug#6195672
Oracle Rdbリリース7.2の以前のリリースでは、RDB$DATABASEシステム表に対する複雑な問合せが、不正な行を返すことがありました。これは、問合せがDBKEY検索を常に実行するように、この特定の表に対する問合せの最適化に関連した問題です。
次の例は、問題を示しています。この問合せは、2つの行の派生表のクロス結合から4行を返します。
SQL> SELECT F.FLAG, A.ACCOUNT cont> FROM cont> (SELECT 'Y' AS FLAG FROM RDB$DATABASE cont> UNION ALL cont> SELECT 'N' AS FLAG FROM RDB$DATABASE) F, cont> (SELECT 'A' AS ACCOUNT FROM RDB$DATABASE cont> UNION ALL ! note:: the query works if UNION cont> SELECT 'M' AS ACCOUNT FROM RDB$DATABASE) A ; F.FLAG A.ACCOUNT N A N M 2 rows selected SQL>
回避するには、問合せのRDB$DATABASEを、別の単一行の表に置き換えます。
この問題は、Oracle Rdbリリース7.2.1.3で修正されました。
4.1.4 ALTER DATABASE ... SHARED MEMORY IS PROCESSでRESIDENTが無効にならない
以前は、SQLを使用する場合、データベース共有メモリーのRESIDENT属性が一度有効になると、無効にすることができませんでした。
次の例では、RESIDENT属性が一度有効になると、ALTER文を使用する際にRESIDENT属性が消去されません。
$ SQL$ CREATE DATA FILE FOO SHARED MEMORY IS PROCESS RESIDENT;
$ RMU/DUMP/HEAD/OUT=X.X FOO
$ SEARCH X.X MAPPED
Database will be mapped in process space
Shared memory will be mapped resident (OpenVMS Alpha only)
$ SQL$ ALTER DATA FILE FOO SHARED MEMORY IS PROCESS;
$ RMU/DUMP/HEAD/OUT=X.X FOO
$ SEARCH X.X MAPPED
Database will be mapped in process space
Shared memory will be mapped resident (OpenVMS Alpha only)
回避策として、RMU/SET SHARED_MEMORY/TYPE=コマンドを使用して、SYSTEM、PROCESSおよびRESIDENTを切り替えることができます。
この問題は、Oracle Rdbリリース7.2.1.3で修正されました。ALTER DATABASE ... SHARED MEMORY IS PROCESSを使用する場合、RESIDENT属性の設定が正しく消去されるようになりました。
4.1.5 COSI-E-WORK_DEVの不完全なエラーの処理
Oracle Bug#4898352
Rdbのソート作業ファイルがローカルでランダムなアクセス・ファイルではない場合、Rdbは不完全なエラー・メッセージをレポートしていました。該当のデータベースがリモートの場合、リモートRDBSERVERはアクセス検証で失敗していました。たとえば、エラーがローカル・データベースの対話型SQLのセッションで発生した場合、不完全なエラー・メッセージは次のように表示されます。
%COSI-E-WORK_DEV, work file !AS must be on random access local device
前述の例では、!ASは問題のソート作業ファイルの名前（NL:[]SORTWORK.TMP;など）で置き換えられていました。
エラーがリモート・データベースで発生した場合、RDBSERVERは失敗し、ローカル・セッションでは次のエラー・メッセージが表示されます。
%RDB-F-IO_ERROR, input or output error -SYSTEM-F-LINKABORT, network partner aborted logical link
リモートの場合、リモート・システム上の該当セッションのNETSERVER.LOGは%SYSTEM-F-ACCVIOエラーを記録していました。
この問題は、Oracle Rdbリリース7.2.1.3で修正されました。
4.1.6 NOT NULLテストを使用する問合せからの不正な結果
Oracle Bug#6041167
次の例に示すように、NOT NULLテストを使用する問合せから、不正な結果がレポートされる場合があります。
SHOW INDEX T1_NDX;
Indexes on table T1:
T1_NDX with column COL_DATA
and column KEY_ID
Duplicates are allowed
Type is Sorted Ranked
Duplicates are Compressed Bitmaps
Key suffix compression is DISABLED
Node size 430
SEL COL_DATA,KEY_ID,NUMBER FROM T1;
Get Retrieval by index of relation T1
Index name T1_NDX [0:0]
COL_DATA KEY_ID NUMBER
55 NULL 96507257
66 NULL 96509951
68 NULL 96508028
3 rows selected
SELECT COUNT(*) FROM T1 WHERE KEY_ID IS NOT NULL;
Aggregate Conjunct Index only retrieval of relation T1
Index name T1_NDX [0:0] Index counts lookup
3
1 row selected
次の例に示すように、NOT NULL条件の列が先行セグメントとして定義される場合、問合せは機能します。
DROP INDEX T1_NDX;
CREATE INDEX T1_NDX ON T1 (KEY_ID,COL_DATA)
TYPE IS SORTED RANKED;
SELECT COUNT(*) FROM T1 WHERE KEY_ID IS NOT NULL;
Aggregate Index only retrieval of relation T1
Index name T1_NDX [0:0] Index counts lookup
0
1 row selected
この問合せでエラーの一因となったのは、主に次の部分です。
この問題を回避するには、影響を受ける問合せのIndex counts lookupを無効にします。これは設定フラグNOCOUNT_SCANを使用して行います。
この問題は、Oracle Rdbのリリース7.1.4.4、リリース7.1.4.5、リリース7.1.5、リリース7.2.0.1、リリース7.2.0.2、リリース7.2.1、リリース7.2.1.1およびリリース7.2.1.2に影響します。この問題はOracle Rdbリリース7.2.1.3で修正されました。
4.1.7 RDMS-F-NOREQIDTのCOSI$TIMER_GET_REQIDTでバグチェックが発生する
Oracle Bug#6069358
同じプログラム内のデータベースに定期的にデタッチおよびリアタッチするアプリケーションで高速コミット機能を使用する場合、そのアプリケーションでは、Rdbのタイマー・ブロックを最終的に使い果し、次のような内容のバグチェックが発生します。
***** Exception at 01235994 : COSI$TIMER_GET_REQIDT + 00000294 %RDMS-F-NOREQIDT, reached internal maximum number of simultaneous timer requests Saved PC = 01235C38 : COSI_TIMER_SET + 00000288 Saved PC = 01235DA8 : COSI_TIMER_SLEEP + 00000078 Saved PC = 012A7548 : KOD$COMMIT + 00000508 Saved PC = 01079148 : RDMS$$INT_COMMIT_TRANSACTION + 00000328 Saved PC = 01078D14 : RDMS$TOP_COMMIT_TRANSACTION + 000001E4
次の例のスクリプトのフラグメントは、高速コミットのチェックポイント期間1秒と、2秒あまり（チェックポイントのタイマーが2回発動するのに十分な時間を許可）のトランザクション間の遅れを使用して失敗を示しています。
.
.
.
$ DEFINE SQL$DATABASE DKA0:[DB]DB.RDB
$ DEFINE RDM$BIND_CKPT_TIME 1
.
.
.
$ SQL$
INSERT INTO C1 VALUES (1);
COMMIT;
$ WAIT 0:0:2.02
DISCONNECT ALL;
.
. Repeat the sequence 101 times
.
INSERT INTO C1 VALUES (1);
COMMIT;
$ WAIT 0:0:2.02
DISCONNECT ALL;
%RDMS-I-BUGCHKDMP, generating bugcheck dump file
DISK$USER:[USER]RDSBUGCHK.DMP;
この問題は、Oracle Rdbリリース7.2.1.3で修正されました。この問題は、内部タイマーのデータ構造が割り当てられているが、タイマーの期限が切れている場合に割当てが解除されていないことが原因で発生していました。タイマーの期限が切れていない場合、内部タイマーのデータ構造の割当てが正しく解除されていませんでした。そのため、タイマーのデータ構造がリークして、最終的に「RDMS-F-NOREQIDT, reached internal maximum number of simultaneous timer requests」というバグチェックの例外が発生していました。
4.1.8 ジャーナルが存在しない場合にジャーナルをドロップする際の不正なメッセージ
Oracle Bug#5059712
データベースにジャーナルが定義されていない場合、存在しないジャーナルをドロップすると、次の例に示すように、「RDMS-F-AIJDISABLED, after-image journaling must be enabled for this operation」という多少の誤解を招くメッセージが返されます。
$ SQL$
CREATE DATABASE FILE AIJTST RESERVE 3 JOURNALS
CREATE STORAGE AREA RDB$SYSTEM;
DISCONNECT ALL;
ALTER DATABASE FILENAME AIJTST DROP JOURNAL FOO;
%RDMS-F-AIJDISABLED, after-image journaling must be enabled for this operation
EXIT;
$ EXIT
この重要性の低い問題は、Oracle Rdbリリース7.2.1.3で修正されました。次の例に示すように、Rdbは、より正確で明示的なメッセージ「RDMS-F-NOSUCHAIJ, no such AIJ journal "journal-name"」を返すようになりました。
$ SQL$
CREATE DATABASE FILE AIJTST
RESERVE 3 JOURNALS
CREATE STORAGE AREA RDB$SYSTEM;
DISCONNECT ALL;
ALTER DATABASE FILENAME AIJTST DROP JOURNAL FOO;
%RDMS-F-NOSUCHAIJ, no such AIJ journal "FOO"
EXIT;
$ EXIT
Oracle Bug#6125013
次の例に示すように、定数ブールを使用するUNION問合せからバグチェックが発生したというレポートがありました。
SELECT A_CLEARER_ID
FROM (SELECT A_DATE,A_CLEARER_ID
FROM T_CLEARED_BY
UNION ALL
SELECT A_DATE,A_CLEARER_ID
FROM T_CLEARED_BY
) AS TMP
WHERE A_DATE = DATE'2007-06-15' AND 1=1;
%RDMS-I-BUGCHKDMP, generating bugcheck dump file DISK:[DIRECTORY]RDSBUGCHK.DMP;
問合せは、定数条件1=1を削除すると機能します。
SELECT A_CLEARER_ID
FROM (SELECT A_DATE,A_CLEARER_ID
FROM T_CLEARED_BY
UNION ALL
SELECT A_DATE,A_CLEARER_ID
FROM T_CLEARED_BY
) AS TMP
WHERE A_DATE = DATE'2007-06-15';
Merge of 1 entries
Merge block entry 1
Merge of 2 entries
Merge block entry 1
Conjunct Index only retrieval of relation T_CLEARED_BY
Index name U1_CLEARED_BY [1:1]
Merge block entry 2
Conjunct Index only retrieval of relation T_CLEARED_BY
Index name U1_CLEARED_BY [1:1]
0 rows selected
この問題は、主な問合せがWHERE句の1=1などのブール型条件を含むUNION問合せの派生表から選択する場合に発生します。
この問題は、Oracle Rdbのリリース7.1.4.4、リリース7.1.4.5、リリース7.1.5、リリース7.1.5.1、リリース7.2.0.1、リリース7.2.0.2、リリース7.2.1、リリース7.2.1.1およびリリース7.2.1.2に影響します。この問題はOracle Rdbリリース7.2.1.3で修正されました。
4.2 SQLエラーの修正
4.2.1 ALTER TABLE ... DISABLE CONSTRAINT後の予期しない制約のアクティブ化
以前のリリースのOracle Rdbでは、ALTER TABLEコマンドは現在のセッションですでにアクティブな制約を有効化または無効化しませんでした。制約を有効および無効にするには、ALTER TABLE ... ENABLE CONSTRAINT constraint-name、ALTER TABLE ... DISABLE CONSTRAINT constraint-name、ALTER TABLE ... ENABLE ALL CONSTRAINTSおよびALTER TABLE ... DISABLE ALL CONSTRAINTSを使用します。
次の例は、ALTER TABLEを使用して制約が無効化されている場合でも、セッション時に制約がチェックされる状態を示しています。
SQL> create table my_con3
cont> (c1 char
cont> ,c2 char
cont> ,constraint MYC1 check (c1 in ('a','b')) deferrable);
SQL> commit;
SQL>
SQL> insert into my_con3 (c1,c2) values ('d','e');
1 row inserted
SQL> commit;
%RDB-E-INTEG_FAIL, violation of constraint MYC1 caused operation to fail
-RDB-F-ON_DB, on database RDB$DEFAULT_CONNECTION
SQL> rollback;
SQL>
SQL> insert into my_con3 (c1,c2) values ('a','b');
1 row inserted
SQL> commit;
SQL> rollback;
SQL>
SQL> alter table my_con3 disable constraint myc1;
SQL> show table (constraint) my_con3;
Information for table MY_CON3
Table constraints for MY_CON3:
MYC1
Check constraint
Table constraint for MY_CON3
Evaluated on COMMIT
Source:
CHECK (c1 in ('a','b'))
Constraint is disabled
Constraints referencing table MY_CON3:
No Constraints found
SQL> commit;
SQL>
SQL> insert into my_con3 (c1,c2) values ('d','e');
1 row inserted
SQL> commit;
%RDB-E-INTEG_FAIL, violation of constraint MYC1 caused operation to fail
-RDB-F-ON_DB, on database RDB$DEFAULT_CONNECTION
この問題は、Oracle Rdbリリース7.2.1.3で修正されました。Oracle Rdbは、セッションのアクティブな制約に対して有効/無効を正しく適用するようになりました。
4.2.2 データベース間のINSERTでのSQL$BLRXPR - 15を含むバグチェック
Oracle Bug#4307036
特定の状況では、データベースにまたがるselectを使用するINSERT文が失敗し、次の行を含むSQLBUGCHK.DMPが生成されていました。
%SQL-F-BUGCHK, There has been a fatal error. Please contact your Oracle support representative. SQL$BLRXPR - 15
このようなINSERT文には、SELECTにDISTINCTキーワードまたはCASE式が含まれていました。たとえば、次のデータベース宣言と変数宣言について考えてみます。
$ SQL$
SQL> create database filename temp1;
SQL> create table ctab (
cont> destination char(4),
cont> state char(2)
cont> );
SQL> insert into ctab values ('ABCD','ME');
1 row inserted
SQL> insert into ctab values ('EFGH','ME');
1 row inserted
SQL> insert into ctab values ('IJKL','MI');
1 row inserted
SQL> insert into ctab values ('ABCD','ME');
1 row inserted
SQL> commit;
SQL> disconnect all;
SQL> create database filename temp2;
SQL> create table tb1 (
cont> ccode char(4),
cont> snum integer
cont> );
SQL> commit;
SQL> disconnect all;
SQL> att 'alias db2 file temp2';
SQL> att 'alias db1 file temp1';
SQL> declare : run_id integer = 5;
SQL> declare :xx char(2) = 'xx';
SQL> declare :suffix char(2) = 'ME';
SQL> declare :hv2 integer = 1;
前述のコンテキストでは、データベースにまたがる次のINSERT文が失敗します。
SQL> insert into db2.tb1 cont> (select distinct destination, :run_id from db1.ctab where state='ME'); %RDMS-I-BUGCHKDMP, generating bugcheck dump file MY$DISK:[MY_HOME]SQLBUGCHK.DMP; %SQL-F-BUGCHK, There has been a fatal error. Please contact your Oracle support representative. SQL$BLRXPR - 15 SQL> insert into db2.tb1 cont> (select destination, cont> case when :suffix indicator :hv2 is null cont> then 1 else 2 end case cont> from db1.ctab); %RDMS-I-BUGCHKDMP, generating bugcheck dump file MY$DISK:[MY_HOME]SQLBUGCHK.DMP; %SQL-F-BUGCHK, There has been a fatal error. Please contact your Oracle support representative. SQL$BLRXPR - 15
この問題は、Oracle Rdbリリース7.2.1.3で修正されました。
4.2.3 コメントがSQL$PRE/COBOLで必ずしも認識されない
Oracle Bug#4751103
SQLプリコンパイラがCOBOLのコメント文を適切に認識しませんでした。ほとんどの場合、違いはありませんが、レコード定義の途中などでは、名前が欠落することがあり、%SQL-F-HVNOTDECLなどのエラーが発生していました。
たとえば、埋込みSQLを使用する次のCOBOLプログラムについて考えます。
000000 IDENTIFICATION DIVISION. 000000 PROGRAM-ID. DUMMYIO. 000000 AUTHOR. RDB ENGINEERING. 000000 000000 ENVIRONMENT DIVISION. 000000 000000 CONFIGURATION SECTION. 000000 SOURCE-COMPUTER. ALPHA-RDB. 000000 OBJECT-COMPUTER. ALPHA-RDB. 000000 000000 DATA DIVISION. 000000 000000 WORKING-STORAGE SECTION. 000000 000000 EXEC SQL INCLUDE SQLCA END-EXEC 000000 000000 01 HOST-DATA. 000000 02 HOST-CODE PIC X(03). 000000* COMPUTATIONAL ITEMS 000000 02 OLD-TOTAL-COST PIC S9(09)V99 COMP. 000000 02 OLD-TOTAL-TAX PIC S9(09)V99 COMP. 000000* END OF COMPUTATIONAL ITEMS 000000 02 HOST-REASON PIC X(60). 000000 02 USER-CODE PIC X(05). 000000 000000 01 SELECTION-RANGES. 000000 02 NO-RANGE PIC X(1). 000000 000000 PROCEDURE DIVISION. 000000 000000 THE-PROGRAM. 000000 000000 PERFORM SELECT-HOST-RECORD. 000000 MOVE SPACE TO NO-RANGE. 000000 000000 RETURN-TO-CALLER. 000000 EXIT PROGRAM. 000000 000000 SELECT-HOST-RECORD. 000000 EXEC SQL SELECT COUNT(*) 000000 INTO :OLD-TOTAL-COST 000000 FROM RDB$DATABASE 000000 END-EXEC.
前述のプログラムでは、HOST-DATAレコードの定義内に2つのコメントがあります。SQLプリコンパイラは、これらのコメントを正常に解析しませんでした。その結果、次のエラー・メッセージが表示されていました。
000000 INTO :OLD-TOTAL-COST
1
%SQL-F-HVNOTDECL, (1) Host variable OLD-TOTAL-COST was not declared
バグ・レポートでは、埋込みコメントは、一組の位置合せのコンパイラ・ディレクティブで、次のように表示されるCOBOLの特殊なコメント行です。
000000 01 HOST-DATA. 000000 02 HOST-CODE PIC X(03). 000000*DC SET ALIGNMENT 000000 02 OLD-TOTAL-COST PIC S9(09)V99 COMP. 000000 02 OLD-TOTAL-TAX PIC S9(09)V99 COMP. 000000*DC END-SET ALIGNMENT 000000 02 HOST-REASON PIC X(60). 000000 02 USER-CODE PIC X(05).
問題を回避するには、レコード定義の途中からコメントを削除します。コメントが位置合せのコンパイラ・ディレクティブの場合（前述のALIGNMENTディレクティブやPADALIGNディレクティブなど）、これらを再配置してレコード全体をまとめることができ、同じCOBOLコードが生成されます。たとえば、前述のレコード定義は次のように再コード化できます。
000000*DC SET ALIGNMENT 000000 01 HOST-DATA. 000000 02 HOST-CODE PIC X(03). 000000 02 OLD-TOTAL-COST PIC S9(09)V99 COMP. 000000 02 OLD-TOTAL-TAX PIC S9(09)V99 COMP. 000000 02 HOST-REASON PIC X(60). 000000 02 USER-CODE PIC X(05). 000000*DC END-SET ALIGNMENT
この問題は、Oracle Rdbリリース7.2.1.3で修正されました。
4.2.4 CONCAT演算子から表示される不正なデータ
Oracle Bug#6002006および6034530
Oracle Rdbリリース7.2.1、リリース7.2.1.1およびリリース7.2.1.2では、CONCAT演算子（||）で不正な結果が生成されることがあります。次の例では、エラーが、予想される->ではなく..として表示されています。
SQL> set flags 'trace'; SQL> SQL> begin cont> for :a as each row of cont> select s_number, s_unit cont> from tom cont> where (s_line = 0 or s_line is NULL) cont> do cont> trace :a.s_number,'-'||'>', :a.s_unit; cont> end for; cont> end; ~Xt: 1 ..1 ~Xt: 2 ..2 ~Xt: 3 ..3 SQL>
この問題は、外部のFORループに対する範囲リストストラテジを処理する際のRdbオプティマイザとの対話が原因で発生していました。OR条件が問合せ例から削除されると、CONCATの結果が正しくなります。
この問題は、Oracle Rdbリリース7.2.1.3で修正されました。
4.2.5 CREATE INDEXが間違ったパーティションに索引キーを挿入する
Oracle Bug#2797443
以前のリリースのOracle Rdbでは、照合順序がある降順のCHAR列またはVARCHAR列のパーティション索引を作成する場合、行が間違ったパーティションにマップされることが稀にあります。このような定義は次のように表示されます。
create collating sequence GERMAN german;
create domain NAMES_DOM char(40) collating sequence GERMAN;
create domain IDS_DOM char collating sequence GERMAN;
create table NAMES_TABLE (id IDS_DOM, last_name NAMES_DOM);
create index NAMES_INDEX
on NAMES_TABLE (id, last_name)
store using (id, last_name)
in AREA1 with limit of ('1', 'k')
in AREA2 with limit of ('1', 'm')
otherwise AREA3;
この問題は、索引の作成後に行が挿入される場合、または照合順序が削除される場合は発生しません。
この問合せでエラーが生じる状況の一因となったのは、主に次の部分です。
この問題は、Oracle Rdbリリース7.2.1.3で修正されました。
4.2.6 ビューに挿入する際の予期しないバグチェック
Oracle Bug#4001764
Oracle Rdbリリース7.2の以前のリリースでは、AUTOMATIC AS列またはDEFAULT値を含む列を参照するビューを使用すると、バグチェックが発生していました。これは、参照される列が実表の他の列も参照した場合に発生していました。次の例は、問題を示しています。
SQL> create table sample_auto cont> (cola integer(3) cont> ,colb automatic insert as round(cola)); SQL> insert into sample_auto values (18.245); 1 row inserted SQL> SQL> create view sample_view as select * from sample_auto; SQL> SQL> insert into sample_view values (19.456); %RDMS-I-BUGCHKDMP, generating bugcheck dump file USER2:[TESTING]RDSBUGCHK.DMP; %RDMS-I-BUGCHKDMP, generating bugcheck dump file USER2:[TESTING]SQLBUGCHK.DMP; %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=0000000000000010, PC=0000000000288F7C, PS=0000001B SQL>
この問題は、Oracle Rdbリリース7.2.1.3で修正されました。Oracle Rdbは、AUTOMATIC AS列とDEFAULT値の句の参照をビュー内から正しく解決するようになりました。
4.2.7 動的SQLでSQLSTATE 22001が返されない
Oracle Bug#5208854
ダイアレクトSQL92、SQL99、ORACLE LEVEL1またはORACLE LEVEL2を使用する場合、SQL文に入力した値が切り捨てられる際に、SQLSTATEフィールドにはマイナスのSQLCODEコードとともに22001がレポートされる必要があります。
コンパイル済SQLプログラムで変数を使用してSQL文の入力値を指定し、この変数がターゲット・データベースのフィールドより長く、フィールドのサイズを超える空白以外のデータがこの変数に含まれている場合、必要なSQLSTATEとSQLCODEがレポートされていませんでした。
たとえば、次の列が定義されているCH1という名前のデータベース表について考えます。
Column Name Data Type ----------- --------- CH1A CHAR(10) CH1B CHAR(1) CH1C CHAR(10)
コンパイル済SQL/Cプログラムの次のフラグメントには、次の挿入コードが含まれます。
...
long SQLCODE;
char SQLSTATE[6] = {'\0','\0','\0','\0','\0','\0'};
char dstmt[100];
char x4[16];
...
strcpy(dstmt, "SET DIALECT 'SQL92'");
EXEC SQL EXECUTE IMMEDIATE :dstmt;
strcpy (dstmt, "INSERT INTO CH1 VALUES ('FOO', 'F', ?) ");
EXEC SQL PREPARE BLAT4 FROM :dstmt;
strcpy (x4, "LITTLETOOLONG");
EXEC SQL EXECUTE BLAT4 USING :x4;
printf("SQLCODE should be < 0, SQLSTATE should be 22001\n")
printf("SQLCODE is %ld\n", SQLCODE);
SQLSTATE[5] = '\0';
printf ("SQLSTATE is %s\n", SQLSTATE);
...
このプログラムの出力は次のように表示されていました。
SQLCODE should be < 0, SQLSTATE should be 22001 SQLCODE is 0 SQLSTATE is 00000
プログラムの出力は次のようになります。
SQLCODE should be < 0, SQLSTATE should be 22001 SQLCODE is -306 SQLSTATE is 22001
この問題は、Oracle Rdbリリース7.2.1.3で修正されました。
4.2.8 SORTED RANKED索引の許容された重複を作成する場合の予期しないバグチェック
Oracle Bug#3899550
Oracle Rdbの以前のバージョンでは、SORTED RANKED索引でその重複の数がきわめて多い（16777217よりも多い）場合、CREATE INDEXコマンドが失敗します。バグチェックのダンプは、次のようになります。
この問題は、Oracle Rdbリリース7.2.1.3で修正されました。Oracle Rdbは、より大容量の内部カウンタにリーフ・ノードのカーディナリティを蓄積するようになりました。
4.2.9 SQLSTATE 22011とSQLCODE -1044の追加
ダイアレクトSQL92、SQL99、ORACLE LEVEL1またはORACLE LEVEL2を使用する場合、組込み関数SUBSTRINGのパラメータ・エラーの結果として、マイナスのSQLCODEとSQLSTATE 22011（無効なサブストリングを意味する）がレポートされる必要があります。SQLは一般的なエラー結果、つまりSQLCODE -1とSQLSTATE RR000を返していました。
たとえば、PERSONNELデータベースに対する次の問合せは、マイナスの文字列長が原因で失敗します。
SQL> select substring(last_name from 1 for -1) from employees; %RDB-F-INVSUBSTRLEN, length specified for substring is invalid
このような失敗に対して、SQLCODE -1044（無効なサブストリングの長さを意味する）と、SQL規格の必須のSQLSTATE 22011を生成するようにOracle Rdbが拡張されました。たとえば、SQLCAは前述の問合せ後に次のように表示されます。
SQL> show sqlca
SQLCA:
SQLCAID: SQLCA SQLCABC: 128
SQLCODE: -1044
SQLERRD: [0]: 3
[1]: 0
[2]: 0
[3]: 0
[4]: 0
[5]: 0
SQLWARN0: 0 SQLWARN1: 0 SQLWARN2: 0
SQLWARN3: 0 SQLWARN4: 0 SQLWARN5: 0
SQLWARN6: 0 SQLWARN7: 0
SQLSTATE: 22011
この問題は、Oracle Rdbリリース7.2.1.3で修正されました。
4.2.10 プログラムで定義されたビューに対するSUBSTRINGの切捨て
Oracle Bug#6117796
コンパイル済SQLまたはSQLモジュール言語プログラムで、組込み関数SUBSTRINGを使用して定義された列を含むビューを定義する場合、同じプログラムの実行時に検索にそのビューを使用すると、結果が切り捨てられることがあります。
たとえば、次のSQL文を含むコンパイル済SQLプログラムがあるとします。
EXEC SQL CREATE TABLE MOREGRUB (C1 VARCHAR (10), ID INT);
EXEC SQL CREATE VIEW X4 (S1, ID) AS
SELECT (C1 FROM 2 FOR 4), ID
FROM MOREGRUB;
EXEC SQL INSERT INTO MOREGRUB VALUES ('Pretzels', 1);
EXEC SQL SELECT S1 INTO :ch1 FROM X4 WHERE ID = 1;
前述のコードの実行後、ホスト変数:ch1の値は、正しい値retzではなくreになっていました。
この問題を回避するには、プログラムの外部にビューを定義するか、ビューを使用せずに表に対して直接選択します。
この問題は、Oracle Rdbリリース7.2.1.3で修正されました。
4.2.11 記憶域マップ関数のコール時の予期しないPORT_LENエラー
Oracle Bug#6129632
以前のリリースのOracle Rdbでは、表の記憶域マップと同じ名前を使用して特殊な記憶域マップ関数を作成していました。この関数にはデータ値を渡すことができ、コール元に返されるパーティション番号があります。次の例に示すように、このようなコールはRDB-F-PORT_LENエラーで失敗することがあります。
SQL> SELECT sample_map (acct_num) FROM sample; %RDB-F-PORT_LEN, buffer length 25 does not match BLR description 29
このエラーは、ユーザー・データの全長が4の倍数の場合に発生します。この場合、ACCT_NUM列はINTEGER型です（長さは4オクテット）。この問題の回避策はありません。
このリリースのOracle Rdbをインストールすると、次のコマンドを使用して、機能する関数定義を再生成できます。
SQL> ALTER STORAGE MAP sample_map COMPILE; SQL> COMMIT;
このコマンドは、このエラーが表示される記憶域マップに適用する必要があります。
この問題は、Oracle Rdbリリース7.2.1.3で修正されました。Oracle Rdbは、記憶域マップ関数を正しく生成するようになりました。
4.2.12 PERSONAサポートを有効化するALTER DATABASEが予期せず失敗する
Oracle Bug#6132645
ALTER DATABASE ... SECURITY CHECKING IS EXTERNAL (PERSONA IS ENABLED)は、データベースでのPERSONAの有効化に失敗することがあります。これは、データベースでバッファの数がきわめて少ない場合に稀に発生します。レポートされたケースでは、データベースでNUMBER OF BUFFERSが10に定義されていました。
これを回避するには、データベースのバッファ数を100に増やすか、あるいはRDB$DATABASE行を含むバッファがメモリー内に残るようにします。
この問題は、Oracle Rdbリリース7.2.1.3で修正されました。このリリースのRdbでは、RDB$FLAGS列の更新時にRDB$DATABASE行が最新であることを確認します。
4.3 RMUエラーの修正
4.3.1 /ENCRYPTIONを使用するテープへのRMUバックアップでバグチェックが発生する
Oracle Bug#6196884
ゼロ以外のXORグループの数と暗号化を使用する、テープ操作へのRMUバックアップが失敗し、アクセス違反エラーが発生することがあります。次の例を見てみます。
$ RMU/BACKUP/ENCRYPTION=(VAL="mysecretkey") MF_PERSONNEL MKA0:TEST.RBF ... %RMU-I-BUGCHKDMP, generating bugcheck dump file ... %SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual address=... %RMU-F-FATALERR, fatal error on BACKUP
この問題は、XORコードで変更された不正なバッファ・サイズを使用する暗号化コードが原因で発生していました。
この問題は、Oracle Rdbリリース7.2.1.3で修正されました。
4.3.2 RMU /ANALYZE /INDEXがすべての論理領域と物理領域にアクセスする
Oracle Bug#3146660
以前のリリースのOracle Rdbでは、RMU /ANALYZE /INDEXコマンドがデータベースのすべての論理領域と物理領域にアクセスしようとしていました。このため、I/Oが過剰になり、ロック操作が発生し、他のデータベース・ユーザーとの論理領域または物理領域のロック競合が予期せず発生することがありました。
この問題は、Oracle Rdbリリース7.2.1.3で修正されました。RMU /ANALYZE /INDEXコマンドは、分析対象の索引の論理領域と物理領域のみにアクセスするようになりました。
4.3.3 %COSI-F-NEGTIMによってRMU/VERIFYまたはRMU/BACKUPが中断する
Oracle Bug#6005440
この問題では、次のメッセージが表示されます。
%COSI-F-NEGTIM, a negative time was computed
これによって、Oracle RdbデータベースのRMU/BACKUPまたはRMU/VERIFYが中断することがあります。この問題は、RMU/VERIFYコマンドとRMU/BACKUPコマンドで実行されるOracle Rdbデータベースのルート検証時に、Oracle Rdbデータベース・ルートの作成時間が許容範囲を超える場合に発生していました。コマンドの実行の続行が許可された場合、RMU/BACKUP操作またはRMU/VERIFY操作を中断するために%COSI-F-NEGTIMエラーが割り当てられていました。
この問題の1つの原因として考えられるのは、データベースのルート破損以外に、VMSシステム時間がデータベースの作成時間よりも短く設定されている場合です。
この問題は、データベースのルートの検証時に%COSI-F-NEGTIMエラーが発生する場合、RMU/VERIFYまたはRMU/BACKUPの続行が許可されるように修正されました。
次の例で示す問題は、Oracle Rdbデータベースのバックアップを開始する際のデータベースのルートの検証時に発生します。データベースのルートに無効な作成日時の値があるために、警告%RMU-W-ROOTADINVが出力されると、%COSI-F-NEGTIMエラーによってバックアップ操作が中断されます。
$rmu/backup mf_personnel mfp.rbf
%RMU-W-ROOTADINV, root "DEVICE:[DIRECTORY]MF_PERSONNEL.RDB;1",
contains incorrect time stamp
expected between 1-DEC-1981 00:00:00.00 and
1-JAN-2007 00:00:01.24,
%COSI-F-NEGTIM, a negative time was computed
%RMU-F-FATALOSI, Fatal error from the Operating System Interface.
%RMU-F-FTL_BCK, Fatal error for BACKUP operation at 1-JAN-2007 00:00:02.59
VMSシステム時間がデータベースの作成時間よりも短く設定されていることが原因でこの問題が生じる場合、問題を回避するには、データベースの作成時間よりも遅い時間にシステム時間を設定します。それ以外では、RMU/RESTORE/ONLY_ROOTを使用して、以前のデータベースのバックアップから有効なデータベースのルートをリストアできます。
この問題は、Oracle Rdbリリース7.2.1.3で修正されました。
4.3.4 データベースの作成日時の診断に関するRMU/VERIFYの問題
RMU/VERIFYコマンドとRMU/BACKUPコマンドで実行されるデータベースのルートの検証時に次の診断メッセージが発生した場合（Rdbデータベースのルートの作成時間がゼロまたは許容範囲外であることが原因）、不正な診断メッセージまたは診断メッセージに不正な日付の値が後から出力されることがありました。これは、いずれかのエラーが出力された場合にAIJおよびページのタイムスタンプを検証するために、ルートの作成時間が後で使用する目的で正しく保存されていなかったためです。
%RMU-W-ROOTADINV, root "DEVICE:[DIRECTORY]MF_PERSONNEL.RDB;1",
contains incorrect time stamp
expected between 1-DEC-1981 00:00:00.00 and
1-JAN-2007 00:00:02.54,
found: 19-APR-2007 03:35:27.81
%RMU-W-ROOTADZER, root "DEVICE:[DIRECTORY]MF_PERSONNEL.RDB;1",
contains zero time stamp
この問題は修正され、ルートの作成時間がゼロまたは許容範囲外の場合でも、後の診断で使用できるように正しく保存されるようになりました。
この問題の1つの原因として考えられるのは、データベースのルート破損以外に、VMSシステム時間がデータベースの作成時間よりも短く設定されている場合です。
次の例で示す問題は、Oracle Rdbデータベースのバックアップを開始する際のデータベースのルートの検証時に発生します。警告%RMU-W-ROOTADINVが出力されると、後から発生する%RMU-E-BADTADAIJエラーの診断には、初期化されていないVMSシステムの日付17-NOV-1858 00:00:00.00が含まれます。
$rmu/backup mf_personnel mfp.rbf
%RMU-W-ROOTADINV, root "DEVICE:[DIRECTORY]MF_PERSONNEL.RDB;1",
contains incorrect time stamp
expected between 1-DEC-1981 00:00:00.00 and
1-JAN-2007 00:00:01.24,
found: 1-JAN-2007 00:01:29.14
%RMU-E-BADTADAIJ, after-image journal creation version differs from the root
expected: 17-NOV-1858 00:00:00.00, found: 1-JAN-2007
00:01:29.14
%RMU-W-ROOERRORS, 1 error encountered in root verification
%RMU-I-COMPLETED, BACKUP operation completed at 1-JAN-2007 00:00:01.40
VMSシステム時間がデータベースの作成時間よりも短く設定されていることが原因でこの問題が生じる場合、問題を回避するには、データベースの作成時間よりも遅い時間にシステム時間を設定します。それ以外では、RMU/RESTORE/ONLY_ROOTを使用して、以前のデータベースのバックアップから有効なデータベースのルートをリストアできます。
この問題は、Oracle Rdbリリース7.2.1.3で修正されました。
4.3.5 間違ったバージョンを使用する場合にRMU/RESTOREがトレースバック・ログで終了する
Oracle Bug#6001235
互換性のないバージョンのデータベースをリストアするためにRMU/RESTOREを使用すると、RMU/RESTOREは単純に終了するのではなくレジスタ・ダンプで終了します。次の例でこの問題を示します。
$ RMU/RESTORE/NOCDD/DIR=SYS$DISK:[]/LOG REPRODUCER.RBF
%RMU-F-DB_CVT_FAIL, Cannot convert from version V7.2 to V7.1
%RMU-F-DB_CVT_FAIL, Cannot convert from version V7.2 to V7.1
Improperly handled condition, image exit forced by last chance handler.
Signal arguments: Number = 0000000000000008
Name = 0000000002C88B94
0000000000000004
0000000000000007
0000000000000002
0000000000000007
0000000000000001
00000000003AEB34
100000000000001B
...
この問題は、Oracle Rdbリリース7.2.1.3で修正されました。
4.3.6 RMU/VERIFYの%RMU-I-BADNXTNOD診断メッセージから%RMU-E-BADNXTNODへの変更
Oracle Bug#4197298
Oracle Rdbデータベースのソート索引の検証時に表示される%RMU-I-BADNXTNOD診断メッセージは、索引構造が破損していることと、索引を再構築する必要があることを示していました。そのため、BADNXTNOD診断メッセージの重大度レベルは、このメッセージが無視されないようにInformationalからErrorに変更されました。
次の例は、RMU/VERIFYがRdbデータベースのソート索引の構造が破損していることを検出したときに出力される%RMU-I-BADNXTNOD診断メッセージを示しています。これは、索引を再構築する必要があることを示していました。
$ RMU/VERIFY/INDEX=bad_index mf_personnel
%RMU-I-BADNXTNOD, Bad next b-tree node at level 2.
Expected b-tree node at logical dbkey 39:3:2.
Found next b-tree node at logical dbkey 65:3:2.
次の例は、索引の破損がユーザーに確実に通知されるように、重大度がInformationalではなくErrorで出力される%RMU-E-BADNXTNOD診断メッセージを示しています。
$ RMU/VERIFY/INDEX=bad_index mf_personnel
%RMU-E-BADNXTNOD, Bad next b-tree node at level 2.
Expected b-tree node at logical dbkey 39:3:2.
Found next b-tree node at logical dbkey 65:3:2.
この問題は、Oracle Rdbリリース7.2.1.3で修正されました。
4.3.7 RMU/VERIFYの%RMU-I-BTRDUPCAR診断メッセージから%RMU-E-BTRDUPCARへの変更
Oracle Rdbデータベースのランク付きソート索引の検証時に表示される%RMU-I-BTRDUPCAR診断メッセージは、索引構造が破損していることと、索引エントリに指定されているカーディナリティがエントリの重複リストから計算されたカーディナリティと一致していないために索引を再構築する必要があることを示しています。これにより、COUNT(*)などのSQL問合せの不正な結果が生じます。そのため、RMU-I-BTRDUPCAR診断メッセージの重大度レベルは、このメッセージが無視されないようにInformationalからErrorに変更されました。
次の例は、RMU/VERIFYがRdbデータベースのランク付きソート索引の構造が破損していることを検出したときに出力される%RMU-I-BTRDUPCAR診断メッセージを示しています。これは、索引を再構築する必要があることを示していました。
$ RMU/VERIFY/INDEX=bad_index mf_personnel
%RMU-I-BTRDUPCAR, Inconsistent duplicate cardinality (C1) of 16777318 specified
for entry 1 at dbkey 58:10:0.
Actual count of duplicates is 16777317.
%RMU-I-BTRROODBK, root dbkey of B-tree is 58:10:0
次の例は、索引の破損が確実にユーザーに通知されるように、重大度がInformationalではなくErrorで出力される%RMU-E-BTRDUPCAR診断メッセージを示しています。
$ RMU/VERIFY/INDEX=bad_index mf_personnel
%RMU-E-BTRDUPCAR, Inconsistent duplicate cardinality (C1) of 16777318 specified
for entry 1 at dbkey 58:10:0.
Actual count of duplicates is 16777317.
%RMU-I-BTRROODBK, root dbkey of B-tree is 58:10:0
この問題は、Oracle Rdbリリース7.2.1.3で修正されました。
4.3.8 RMU/RESTORE、RMU/DUMP/BACKUPに対する無効な%RMU-F-NOPRIVERRエラー
Oracle Bug#6119717
RMUのすべてのコマンドと/ROOT_ONLY RESTOREコマンドの実行に必要なVMS権限を初期化する際の問題が原因で、無効な%RMU-F-NOPRIVERRが発生していました。これは、初期化の問題によって、WORLDアクセスなどの特定のVMS権限がない場合に、RMUが誤ってその権限が必要であると判断したためです。これは、ユーザー・プロセスが特権的ではないため、BYPASSやSYSPRVなどのVMS優先権限が付与されていない場合にのみ発生していました。データベースのアクセス制御リストのアクセス権限をチェックすることに関する問題ではありません。これは正しく処理されていました。
次の例は、RBFファイルに保存されたデータベースのアクセス制御リストが、データベースへのユーザー・アクセスを許可して、RMU/RESTOREコマンドの実行を許可するために必要なVMS権限をユーザーが保持している場合でも、非特権ユーザー・プロセスがRMU/RESTOREコマンドを実行する権限に対して拒否されている状況を示しています。
$ SHOW PROCESS/PRIVILEGE
Authorized privileges:
GROUP GRPNAM GRPPRV NETMBX TMPMBX
$ RMU/SHOW PRIVILEGE MF_PERSONNEL.RDB
(IDENTIFIER=[GROUP,USER],ACCESS=READ+WRITE+CONTROL+RMU$ALL)
$ RMU/BACKUP/NOLOG MF_PERSONNEL.RDB MFP.RBF
$ SQL
drop database filename mf_personnel;
exit
$ RMU/RESTORE/NOLOG MFP.RBF
%RMU-F-NOPRIVERR, no privileges for attempted operation
この問題を回避するには、BYPASS権限またはSYSPRV権限で認可されているVMSアカウントを使用してRESTOREを実行します。
この問題は、Oracle Rdbリリース7.2.1.3で修正されました。
4.3.9 スナップショット・ファイルを移動するRMU/REPAIRが新しいファイルの間違った仕様で失敗する
Oracle Bug#4083632
スナップショット・ファイルのデフォルトのファイル仕様の隠れたデバイス名と、新しいスナップショットの場所の指定により、RMU/REPAIRが失敗することがあります。次の例を見てみます。
$ RMU/REPAIR/INITIALIZE=(SNAPSHOT=CONFIRM)/AREA=MYDB_DATA -
$1$DKA100:[USER.][SUB]MYDB
Area MYDB_DATA snapshot filename [$1$DKA100:[USER.][SUB]MYDB_DATA.SNP;1]:
>>> User response: $1$DKA100:[USER]MYDB_DATA.SNP
Area MYDB_DATA snapshot file allocation [100]:
%RMU-F-FILACCERR, error creating database file $1$DKA100:[USER.]
[USER]MYDB_DATA.SNP;1
-RMS-E-DNF, directory not found
この問題は、Oracle Rdbリリース7.2.1.3で修正されました。
4.3.10 RMU/BACKUP/AFTERでの「RMU-F-FILACCERR, Error Truncating File」
Oracle Bug#5629652
1つの拡張可能なアフター・イメージ・ジャーナル・ファイル（ジャーナル・ファイルのバックアップ前に拡張されてから無効化されたファイル）のRMU/BACKUP/AFTERが失敗し、次のエラーが発生していました。
%RMU-F-FILACCERR, error truncating file -SYSTEM-W-ACCONFLICT, file access conflict
次の例は、1つの拡張可能なアフター・イメージ・ジャーナル・ファイル（ジャーナル・ファイルのバックアップ前に拡張されてから無効化されたファイル）のRMU/BACKUP/AFTERで発生したRMU-F-FILACCERRを示しています。
$ SQL create data file foo; create table tbl1 (c1 char(50),c2 char(50)); commit; exit $ rmu/backup foo foo $ rmu/set after/enable/add=(name=aij1,file=aij1) foo $ SQL att 'f foo'; @load.sql exit $ rmu/set after/disable foo $ rmu/backup/after/log foo fooaij %RMU-F-FILACCERR, error truncating file -SYSTEM-W-ACCONFLICT, file access conflict
この問題を回避するには、ジャーナル・ファイルのバックアップ前にジャーナル・ファイルを無効化しないようにします。
この問題は、Oracle Rdbリリース7.2.1.3で修正されました。
4.4 RMU Show Statisticsエラーの修正
4.4.1 RMU/SHOW STATISTICSの不正な「Transaction Recovery Duration Estimates」
Oracle Bug#6006427
Oracle Rdb 7.2の以前のリリースでは、「Transaction Recovery Duration Estimates」画面の時間の値が大幅に間違っていることがありました。本来の値よりもかなり大きな値になっていました。
この問題は、Oracle Rdbリリース7.2.1.3で修正されました。推定値は、より現実的な範囲の値に縮小されています。
4.4.2 RMU/SHOW STATISTICSのストール統計の集計の期間の値が誤って見積られる
Oracle Bug#6006202
Oracle Rdb 7.2の以前のリリースでは、「aggregate stall statistics」画面のストール期間の値が正しく見積られていないため、異常に大きな値が表示されていました。
この問題は、Oracle Rdbリリース7.2.1.3で修正されました。
4.4.3 RMU /SHOW STATISTICS /ALARM=nがn秒を待機しない
Oracle Bug#6016126
Oracle Rdb 7.2の以前のリリースでは、ストールの通知アラームが誤って発動することがありました。概して、ストールの通知は予定よりもかなり早くなっていました。たとえば、60秒よりも長いストールが検出されると、OPCOMによって次のアラームが発動します。アラームは、本来よりもかなり早い時間に生成されていました。
$ RMU /SHOW STATISTICS PRODUCTION_DB -
/NOINTERACTIVE -
/BROADCAST -
/TIME=60 -
/ALARM=60 -
/NOTIFY=(OPER12) -
/UNTIL=TOMORROW
この問題は、Oracle Rdbリリース7.2.1.3で修正されました。ストールの通知アラームは、予定よりも早く生成されることがなくなりました。
4.4.4 「Hot Standby Statistics」画面で状態の値が切り捨てられる
Oracle Bug#6044632
以前は、ホット・スタンバイのTCP/IPポート番号が9999よりも大きい場合、そのポート番号はRMU /SHOW STATISTICSの「Hot Standby Statistics」画面で切り捨てられていました。
たとえば、TCP/IPポート番号12345を使用する場合、状態の画面にはState: TCP/IP:1234と表示されていました。
この問題は、Oracle Rdbリリース7.2.1.3で修正されました。状態の表示フィールドでは、5桁のTCP/IPポート番号を表示できるようになりました。
4.5 ホット・スタンバイ・エラーの修正
4.5.1 RMU/OPEN/ROW_CACHE=DISABLEを使用する際のホット・スタンバイ・ノードの障害のリカバリ
Oracle Bug#5957364
行キャッシュ機能とホット・スタンバイ機能を使用する構成では、データベースで最初にホット・スタンバイを開始する前に、RMU/SET ROW_CACHE/DISABLEコマンドを使用してスタンバイ・データベースで行キャッシュを明示的に無効にする必要があります。ただし、行キャッシュを無効にするには、スタンバイ・データベースでRMU/OPEN/ROW_CACHE=DISABLEコマンドを使用することもできます（推奨ではありません）。
RMU/OPEN/ROW_CACHE=DISABLEコマンドを使用する際にシステム障害が発生した場合、データベースを再開するとすぐにデータベース・リカバリは、かなり古い最後のチェックポイントの場所で開始しようとしていました。この場所は、元々スタンバイ・データベースを作成するためにマスター・データベースをバックアップしたときの行キャッシュのチェックポイントに基づいていました。必要なAIJファイルはすでにオンライン上にないため、リカバリが失敗していました。
この問題は、Oracle Rdbリリース7.2.1.3で修正されました。DBRプロセスは、RCSプロセスがアクティブのときにノード障害からリカバリしない場合、行キャッシュの最も古いチェックポイントの場所を無視するようになりました。
この章では、Oracle Rdbリリース7.2.1.2で修正されるソフトウェアの誤りについて説明します。
5.1 すべてのインタフェースに適用されるソフトウェアの誤りの修正
5.1.1 KOD$START + 0000080Cでのバグチェック
Oracle Bug#5059527
Oracle Rdbリリース7.1.4.3以降では、次の例外のバグチェックが発生することがありました。
***** Exception at 0193578C : KOD$START + 0000080C %COSI-F-BUGCHECK, internal consistency failure
リリース7.1.4.3では、TSNゼロが割り当てられていないかどうかを検証するために、ルーチンKOD$STARTが変更されました。TSNゼロが割り当てられた場合、このバグチェックが発生していました。
この問題は、データベースで最も古いトランザクション順序番号（TSN）を決定するコードのわずかな競合状態が原因で発生していました。複数のプロセスがグローバルな最も古いTSNの場所に同時にアクセスしていた場合、コードは最も古いTSNがゼロであると誤って判断していました。
この問題を完全に防ぐには、以前のバージョンのOracle Rdbを使用するしかありません。発生回数を減らすには、データベースのクラスタ・ノードの数を1よりも大きな値に設定します。これにより、ノードの数が1であることに依存するパフォーマンス機能（行キャッシュなど）が無効になることに注意してください。また、システムがクラスタの一部ではない場合、クラスタ・ノードの数を1よりも大きな値に設定しても影響はありません。
この問題は、Oracle Rdbリリース7.2.1.2で修正されました。TSNゼロが割り当てられる原因となった競合状態はなくなりました。
5.1.2 大きなAIJファイルをDBに追加すると、ACCVIOエラーまたはOPCDECエラーで失敗する
Oracle Bug#5852864
データベースのアフター・イメージ・ジャーナル・ファイルの作成が失敗し、ACCVIOエラーまたはOPCDECエラーが発生します。次の例を見てみます。
SQL> CREATE DATABASE
...
PRESTARTED TRANSACTIONS ARE on
(WAIT 1 MINUTES FOR TIMEOUT)
...
SQL> ALTER DATABASE FILENAME myDB ADD JOURNAL journal01 FILENAME 'JOURNAL01'
ALLOCATION IS 7000000 BLOCKS;
%SYSTEM-F-ACCVIO, access violation, reason mask=00,
virtual address=000000000000000C, PC=000000000000000C,...
これは、同期化フラグを早めに消去するコードのバグが原因で発生していました。このため、現在のリクエストが完了する前に、期限切れの事前起動トランザクション・タイマーで作成されたリクエストが実行されていました。また、スタックも破損していました。
問題を回避するには、事前起動トランザクション・タイマーの値を大きくするか、SQLのALTER DATABASE文を使用して事前起動トランザクション・タイマーを完全に無効にします。
この問題は、Oracle Rdbリリース7.2.1.2で修正されました。
5.1.3 単純な問合せがARITH_EXCEPTで失敗する
Oracle Bug#5941200
次の例に示すように、単純な問合せが算術例外で失敗します。
SELECT * FROM auth_control WHERE scheme_code = 'aaa' AND task_ind = 'x' AND in_use_ind = 'g'; %RDB-E-ARITH_EXCEPT, truncation of a numeric value at runtime -SYSTEM-F-HPARITH, high performance arithmetic trap, Imask=00000000, Fmask=00000400, summary=04, PC=00000000008BADFC, PS=0000001B -SYSTEM-F-FLTDIV, arithmetic trap, floating/decimal divide by zero at PC=00000000008BADFC, PS=0000001B
次の例に示すように、SQLフラグindex_column_groupが無効の場合、問合せは機能します。
set flags 'noindex_column_group'; set flags 'stra,detail'; SELECT * FROM auth_control WHERE scheme_code = 'aaa' AND task_ind = 'x' AND in_use_ind = 'g'; 0 rows selected
また、次の例に示すように、RMU/COLLECT OPTIMIZERが適用される場合、問合せは機能します。
$rmu/collect optimizer <database> $SQL$ ATT 'FILE <database>'; SELECT * FROM auth_control WHERE scheme_code = 'aaa' AND task_ind = 'x' AND in_use_ind = 'g'; 0 rows selected
この問合せでエラーの一因となったのは、主に次の部分です。
Segment group factors of 4 segments are estimated. COL1 GROUP_FACTOR 3.2407680E+00 PREFIX_CARD 1 COL2 GROUP_FACTOR 2.4153826E+00 PREFIX_CARD 1 COL3 GROUP_FACTOR 1.8002133E+00 PREFIX_CARD 0 COL4 GROUP_FACTOR 1.3417203E+00 PREFIX_CARD 0
この問題は、Oracle Rdbのリリース7.1.4.4、リリース7.1.4.5、リリース7.2.0.1、リリース7.2.0.2およびリリース7.2.1.0に影響します。この問題はOracle Rdbリリース7.2.1.2で修正されました。
5.2 SQLエラーの修正
5.2.1 ストアド・ファンクションをすべての定数パラメータでコールする際に予期しないRTN_FAIL/BAD_REQ_HANDLEがレポートされる
Oracle Bug#4764496
以前のリリースのOracle Rdbでは、問合せが失敗し、ルーチン名"(unknown)"のエラーRTN_FAILと派生メッセージBAD_REQ_HANDLEが発生していました。
次に、SQL_FUNCTIONSルーチンからREPLACE関数を使用する例を示します。
select
replace('hallo','a','e')
from TAB1
where COL2 = date'2006-06-29'
and ( COL1 = 'AA'
or
COL1 = 'BB' );
%RDB-E-RTN_FAIL, routine "(unknown)" failed to compile or execute successfully
-RDB-E-BAD_REQ_HANDLE, invalid request handle
この問題は、問合せのオプティマイザが問合せの構成時に定数式を使用しようとした場合に発生していました。ただし、参照されるルーチン（この例ではREPLACEという名前の関数）は、問合せで使用する目的でコンパイルされていないため、レポートされた名前は不明になっていました。関数がロードされると、この問合せは成功します。
この問題の回避策は次のとおりです。
この問題は、Oracle Rdbリリース7.2.1.2で修正されました。
5.2.2 大量のコマンドラインを使用する場合のSYSTEM-F-ROPRAND
Oracle Bug#4117738
大量のコマンドラインを使用する場合、対話型SQLでSYSTEM-F-ROPRANDメッセージが発生することがありました。さらに、SQLはすべての後続コマンドでSYSTEM-F-ROPRANDエラーが発生する状態になっていました。バグ・レポートの例では、1行が11,000バイトを超える構成のコマンド・ファイルによって、問題が明示されていました。
次のシーケンスは、BIGCMD.SQLという名前のコマンド・ファイルを使用する問題の状態を示しています。このファイルは大きすぎるため、ここでは再現できません。
SQL> @BIGCMD.SQL %SYSTEM-F-ROPRAND, reserved operand fault at PC=0000000000F4DDA8, PS=0000001B
このような大量のコマンドラインを使用する場合、アクセス違反などの様々な現象も発生する可能性があります。
SQLの問題が修正された後でも、前述の例のコマンドラインには、Rdbのエグゼクティブ・モード・スタックのデフォルト・サイズよりも大きな再帰レベルを必要とする問合せが含まれていました。この場合、問合せは失敗し、次のメッセージが表示されます。
%RDB-F-IMP_EXC, facility-specific limit exceeded -RDMS-F-XPR_STACK_OFLO, expression forces too many levels of recursion
エグゼクティブ・モード・スタックのサイズは、論理RDMS$BIND_EXEC_STACK_SIZEを使用して調整できます。デフォルト・サイズは20ページレットです。前述のコマンドファイルの問合せを完了するには、このサイズを330に設定する必要がありました。
この問題は、Oracle Rdbリリース7.2.1.2で修正されました。
5.2.3 ALTER VIEWからの予期しないバグチェック
Oracle Bug#5964501
以前のリリースのOracle Rdbでは、AS SELECT句を指定したALTER VIEWコマンドでバグチェックが発生することがありました。これは、CASE、COALESCE、NULLIF、NVL、NVL2、ABS、DECODEまたはsubselect文などに表示されるブール式が列の式に含まれる場合に発生していました。
次の例は、エラーを示しています。
SQL> alter view v_t1 as select nullif(col1,-999999) as nn from t1; %RDMS-I-BUGCHKDMP, generating bugcheck dump file RDBVMS_USER2:[SMITHI]RDSBUGCHK.DMP; %RDMS-I-BUGCHKDMP, generating bugcheck dump file RDBVMS_USER2:[SMITHI]SQLBUGCHK.DMP; %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address= 000000000000000C, PC=000000000028878C, PS=0000001B SQL>
この問題は、Oracle Rdbリリース7.2.1.2で修正されました。また、Oracle RdbはビューのDB$VIEW_RELATIONSシステム表の表依存情報を正しく保存するようになりました。
5.2.4 ALTER INDEX ... BUILD PARTITIONからの予期しないバグチェック
Oracle Bug#5951999
以前のリリースのOracle Rdbでは、SORTED RANKED索引に対するALTER INDEX ... BUILD PARTITION文またはALTER INDEX ... REBUILD PARTITION文でバグチェックが発生することがありました。この問題は、HASHED索引またはSORTED索引には影響しません。
SORTED RANKED索引機能内のサニティー・チェックで、パーティションのデータベース・キーが重複する索引キー内でソートされないことが検出された場合にバグチェックが発生します。
この問題を回避するには、REBUILD ALL PARTITIONS句を使用するか、索引をドロップして再作成します。
この問題は、Oracle Rdbリリース7.2.1.2で修正されました。Rdbは、重複する索引キーの値がDBKEYで昇順になるように正しくソートするようになりました。
5.3 RMUエラーの修正
5.3.1 RMU/DUMP/BACKUPがACCVIOエラーまたはオーバーラン・エラーで失敗する
Oracle Bug#5968242
/COMPRESSION=ZLIBで保存された保存セットに対するコマンドRMU/DUMP/BACKUPが失敗し、次のエラーが表示されます。
%SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual address=..., PC=..., PS=0000001B %RMU-F-FATALOSI, Fatal error from the Operating System Interface.
/COMPRESSION=HUFFで保存された保存セットに対するコマンドRMU/DUMP/BACKUPが失敗し、次のエラーが表示されます。
Illegal output buffer overrun %RMU-E-INVRECEXP, Error expanding compressed backup file record. %RMU-F-FATALERR, fatal error on DUMP_BACKUP
このエラーは、領域に適切な圧縮コンテキストに切り替わらない、/DUMPに固有のコード・セクションで発生していました。
これらの問題は、Oracle Rdbリリース7.2.1.2で修正されました。
5.3.2 クライアント順序が32を超える場合のRMU/RESTOREの変換の問題
Oracle Bug#5963088
Rdbデータベースのルートのクライアント順序カウントは、リリース7.2に変換するリリース7.1データベースで32より大きな場合でも、変換したリリース7.2データベースで適宜32に設定されていました。これが原因で、データベースが破損していました。これは、リリース7.1データベースのRBFバックアップ・ファイルのリリース7.2のRMU/RESTOREによって、リストアの最後にデータベースがリリース7.2に変換される場合のみ発生していました。RMU/CONVERTコマンドを使用してリリース7.1データベースをリリース7.2データベースに変換する場合は発生しませんでした。この問題は、クライアント順序のカウントが、リリース7.2に変換されるリリース7.1データベースで32を超えない場合は発生しません。ただし、データベースを破損させないようにするには、次に示す2つの回避策のいずれかを使用して変換を繰り返すしかありません。このような問題は、リリース7.1データベースをリリース7.2に変換する前にリリース7.1データベースをバックアップして、データベースの変換直後にRMU/VERIFY/ALLを実行することの重要性を示しています。
次の例は、変換がエラーなしで完了したことを示しています。ただし、RMU/VERIFYは、データベースのルートに入力するよりも多くのクライアント順序がRDB$SEQUENCESシステム表に含まれていることを示しており、SQLでクライアント順序を表示しようとすると、RDMSのバグチェックのダンプが発生します。
$ RMU/RESTORE/LOG/DIR=DEVICE:[DIRECTORY]/nocdd -
_$ MFP_SEQUENCES.RBF
%RMU-I-CVTCOMSUC, CONVERT committed for DEVICE:[DIRECTORY]
MF_PERSONNEL.RDB;1 to version V7.2
%RMU-W-USERECCOM, Use the RMU Recover command. The journals are not
available.
%RMU-I-COMPLETED, RESTORE operation completed at 30-MAR-2007 15:42:40.23
GIBSON>rmu/verify/all mf_personnel
%RMU-E-NOSEQENT, sequence id 35 has no valid entry in the root file
%RMU-E-NOSEQENT, sequence id 37 has no valid entry in the root file
%RMU-E-NOSEQENT, sequence id 38 has no valid entry in the root file
%RMU-E-NOSEQENT, sequence id 39 has no valid entry in the root file
%RMU-E-NOSEQENT, sequence id 40 has no valid entry in the root file
%RMU-E-NOSEQENT, sequence id 41 has no valid entry in the root file
%RMU-E-NOSEQENT, sequence id 42 has no valid entry in the root file
%RMU-E-NOSEQENT, sequence id 43 has no valid entry in the root file
%RMU-E-NOSEQENT, sequence id 44 has no valid entry in the root file
%RMU-E-NOSEQENT, sequence id 45 has no valid entry in the root file
%RMU-E-NOSEQENT, sequence id 46 has no valid entry in the root file
%RMU-E-NOSEQENT, sequence id 47 has no valid entry in the root file
%RMU-E-NOSEQENT, sequence id 48 has no valid entry in the root file
%RMU-E-NOSEQENT, sequence id 49 has no valid entry in the root file
%RMU-E-NOSEQENT, sequence id 51 has no valid entry in the root file
%RMU-E-NOSEQENT, sequence id 52 has no valid entry in the root file
%RMU-E-NOSEQENT, sequence id 53 has no valid entry in the root file
%RMU-E-NOSEQENT, sequence id 54 has no valid entry in the root file
%RMU-E-NOSEQENT, sequence id 55 has no valid entry in the root file
$ SQL
SQL> ATTACH 'FILENAME MF_PERSONNEL';
SQL> SHOW SEQUENCES;
Sequences in database with filename mf_personnel
EMPID
N1
N10
N11
N12
N13
N14
N15
N16
N17
N18
N19
N2
N20
N21
N22
N23
N24
N25
N26
N27
N28
N29
N3
N30
%RDMS-I-BUGCHKDMP, generating bugcheck dump file
DEVICE:[DIRECTORY]RDSBUGCHK.DMP;
この問題を回避するには、リリース7.1データベースのRMU/CONVERTをリリース7.2に実行します（次の例を参照）。また、リリース7.1データベースをバックアップする前にそのデータベースでクライアント順序をドロップし、リリース7.2にリストアして、リリース7.2データベースでクライアント順序を再定義する方法もあります。
$ RMU/CONVERT MF_PERSONNEL %RMU-I-RMUTXT_000, Executing RMU for Oracle Rdb V7.2-00 Are you satisfied with your backup of DEVICE:[DIRECTORY]MF_PERSONNEL.RDB;1 and your backup of any associated .aij files [N]? Y %RMU-I-LOGCONVRT, database root converted to current structure level %RMU-S-CVTDBSUC, database DEVICE:[DIRECTORY] MF_PERSONNEL.RDB;1 successfully converted from version V7.1 to V7.2 %RMU-I-CVTCOMSUC, CONVERT committed for DEVICE:[DIRECTORY]MF_PERSONNEL.RDB;1 to version V7.2
この問題は、Oracle Rdbリリース7.2.1.2で修正されました。
5.3.3 NULL値を解析する際のRMU LOADのテキスト区切りの問題
Oracle Bug#5768090
DELIMITED TEXTデリミタを使用して、RMU UNLOADおよびLOADでNULLとしてフラグ付けされた値を解析する場合に問題が発生していました。これは、NULLとしてフラグ付けされたフィールドを示すために使用する文字列が、列の値の最初と最後をマークするPREFIXデリミタとSUFFIXデリミタを示すために使用する組合せ文字列と同じ場合に発生していました。この問題は、RMU/LOADが、NULL値をPREFIXデリミタの後に続くSUFFIXデリミタとして解釈することが原因で発生していました。そのため、列がロードされるときにNULLとしてフラグ付けされませんでした。これにより、RMU/LOADでエラーが発生しました。一例として、ロードするフィールドが日付フィールドのときに無効な日付の値をロードしようとする場合などです。また、NULLとしてフラグ付けされることになっているフィールドに予想外の値がロードされてしまうこともあります。
この問題は修正されました。ただし、接頭辞、接尾辞、または接頭辞と接尾辞による単一文字または文字列値の解析でRMU UNLOADとLOADが混乱しないように、NULLに対して一意の文字列または1つの文字値を使用することを強くお薦めします。
同一のデリミタを混同するような紛らわしい状況では、パーサーは選択の優先順位を付ける必要があります。最も一般的で適切なケースを選択しようとしますが、ユーザーの本来の意図と必ずしも一致するとはかぎりません。一意のNULL値を使用するか、またはデフォルトのNULL値を取ることで、このようなケースを防ぐことができます。
次に、このようなケースで修正された一例を示します。この例では、NULL文字列が、接頭辞と接尾辞の文字列を組み合せた値（それぞれは単一文字列で構成される）と同じであるため、RMU/LOADで問題が発生しました。このケースは、接頭辞文字と接尾辞文字が指定されていないため、ユーザーにとって明確ではありませんが、ドキュメントに記載されているデフォルトの接頭辞と接尾辞の単一文字デリミタの値"が使用されていました。NULL文字列を""と指定していたため、RMU/LOADはNULL値""を、デフォルトの接頭辞の値"とそれに続くデフォルトの接尾辞の値"として解釈しました。このため、NULLビットが中間列に対して用意されていませんでした。ドキュメントには、次のように記載されています。
NULL=""""""
これは、2つの外部の二重引用符文字が削除されるため、NULL値""を示しています。それぞれの"文字は""として入力する必要があります。
$ SQL
create database filename test;
create table t1 (col1 char(5), col2 date vms, col3 char(5));
create table t2 (col1 char(5), col2 integer, col3 char(5));
create table t3 (col1 char(5), col2 char(5), col3 char(5));
commit;
insert into t1 (col1,col3) values ('first','last');
insert into t2 (col1,col3) values ('first','last');
insert into t3 (col1,col3) values ('first','last');
commit;
SQL> sel * from t1;
COL1 COL2 COL3
first NULL last
1 row selected
SQL> sel * from t2;
COL1 COL2 COL3
first NULL last
1 row selected
SQL> sel * from t3;
COL1 COL2 COL3
first NULL last
1 row selected
Exit
$ rmu/unload/record=(file=t1,format=delimited,null="""""") test t1 t1
$ rmu/unload/record=(file=t2,format=delimited,null="""""") test t2 t2
$ rmu/unload/record=(file=t3,format=delimited,null="""""") test t3 t3
$ type t1.unl
"first","","last "
$ type t2.unl
"first","","last "
$ type t3.unl
"first","","last "
RMUが、NULL値と、PREFIXおよびSUFFIXの値を混同したため、日付フィールドに対してRMU/LOADが失敗し、整数（または実数）の場合にゼロを挿入し、文字フィールドの場合は空の文字列を挿入します。
$ rmu/load/record=(file=t1,format=delimited,null="""""") test t1 t1 %RMU-I-LOADERR, Error loading row 1. %RDB-E-CONVERT_ERROR, invalid or unsupported data conversion -COSI-F-IVTIME, invalid date or time %RMU-I-DATRECREAD, 1 data records read from input file. %RMU-I-DATRECSTO, 0 data records stored. %RMU-F-FTL_LOAD, Fatal error for LOAD operation at 18-JAN-2007 04:23:54.48 $ rmu/load/record=(file=t2,format=delimited,null="""""") test t2 t2 %RMU-I-DATRECREAD, 1 data records read from input file. %RMU-I-DATRECSTO, 1 data records stored. $ rmu/load/record=(file=t3,format=delimited,null="""""") test t3 t3 %RMU-I-DATRECREAD, 1 data records read from input file. %RMU-I-DATRECSTO, 1 data records stored. $ SQL SQL> att 'f test'; SQL> sel * from t1; COL1 COL2 COL3 first NULL last 1 row selected SQL> sel * from t2; COL1 COL2 COL3 first NULL last first 0 last 2 rows selected SQL> sel * from t3; COL1 COL2 COL3 first NULL last first last 2 rows selected
この問題を回避するには、デフォルト、または他のDELIMITED TEXTデリミタに指定した値と混同されない一意の値をNULLに指定します。
この問題は、Oracle Rdbリリース7.2.1.2で修正されました。
5.4 RMU Show Statisticsエラーの修正
5.4.1 RMU/SHOW STATISTICSのAIJ ARB:I/Oの割合、ブロックごとのI/Oの割合に関する問題
アフター・イメージ・ジャーナルが有効なOracle RdbデータベースのRMU/SHOW STATISTICSコマンドで生成された「AIJ Analysis」画面表示で「Examine ARB:I/O ratio」オプションと「Examine blocks-per-I/O ratio」オプションに設定された警告のしきい値の検出に関する問題がありました。この問題により、「ARB:I/O ratio」の警告
#.# ARBs per I/O below #.# threshold
が、この割合に対して現在設定されているしきい値を超えたときに出力されない場合がありました。また、それにより、「blocks-per-I/O ratio」の警告
#.# blocks written per I/O below #.# threshold
が、この割合に現在設定されているしきい値を超えたときに、出力されない場合がありました。この問題は、これらのしきい値がカウント値ではなくパーセント値として処理されることが原因で発生していました。この問題は修正され、誤解を招くパーセント記号はこれらの警告メッセージから削除されました。
この問題は、Oracle Rdbリリース7.2.1.2で修正されました。
5.5 ホット・スタンバイ・エラーの修正
5.5.1 ホット・スタンバイ・ガバナーを完全に無効にできない
Oracle Bug#5166721
以前は、ホット・スタンバイ・ガバナーを明示的に無効にした場合、負荷が非常に高いときに、スタンバイ・システムのLRSバッファの使用率が75%を超えると、ガバナーが再有効化されることがありました。
この動作はデフォルトで無効になりました。ガバナーは、スタンバイ・システムのLRSバッファの使用率が75%を超える場合でも再有効化されないようになりました。
以前の動作に戻す場合は、システム全体の論理名RDM$BIND_LRS_ALLOW_AUTOMATIC_HOT_STANDBY_GOVERNORの値を1に定義して、以前のリリースと同様にガバナーを再有効化できます。
この問題は、Oracle Rdbリリース7.2.1.2で修正されました。
この章では、Oracle Rdbリリース7.2.1.1で修正されるソフトウェアの誤りについて説明します。
6.1 すべてのインタフェースに適用されるソフトウェアの誤りの修正
6.1.1 問合せが予期せず失敗し、DB-E-NO_RECORDエラーが表示される
Oracle Bug#5846989
以前のリリースのOracle Rdbでは、MIN関数またはMAX関数を使用した問合せが失敗し、次のエラーが発生することがありました。
%RDB-E-NO_RECORD, access by dbkey failed because dbkey is no longer associated with a record -RDMS-F-NODBK, -524:22806:1 does not point to a data record
表示されるDBKEYは、一致キーの重複連鎖を参照する、エンコードされたDBKEYです。
この問題は、次の状況で発生します。
回避策として動的オプティマイザを無効にするために、論理名RDMS$SET_FLAGS、またはキーワードMAX_STABILITYを指定したSET FLAGSコマンドを使用するか、あるいは論理名RDMS$MAX_STABILITYの値を1に定義します。
また、ISOLATION LEVEL REPEATABLE READ句を使用してトランザクションを開始する方法もあります。
この問題は、Oracle Rdbリリース7.2.1.1で修正されました。
6.1.2 AIJバックアップ操作がNONAME-F-NOMSGメッセージ番号00000004で中断する
Oracle Bug#5890612
アフター・イメージ・ジャーナルのバックアップ操作が、予期しない不正なステータス値で失敗することが稀にあります。実際の値は変わる場合がありますが、この問題に関する少なくとも1つのユーザー・レポートでは、値00000004が示されていました。この問題のバグチェックのダンプ・ファイルは次のとおりです。
***** Exception at 0054D94C : AIJBCK$GET_NEXT_JOURNAL + 00000CFC Saved PC = 005452E8 : AIJBCK$FULL_BACKUP + 00000FF8 Saved PC = 00543C0C : AIJBCK$BACKUP + 0000113C Saved PC = 0040E7A4 : RMUCLI$BACKUP_AIJ + 00000904 Saved PC = 003A2414 : RMU_DISPATCH + 00000484 Saved PC = 003A1AE8 : RMU_STARTUP + 000004E8 Saved PC = 001E002C : RMU$MAIN + 0000002C
この問題は、Oracle Rdbリリース7.2.1.1で修正されました。間違ったステータス値は、初期化されていない戻りステータスが返されるという結果になりました。正しいステータスが返されるようになりました。
6.1.3 一部のRDMS$SET_FLAGS設定がアタッチ後に表示されない
Oracle Bug#4103971、4116768および5245116
一部のデータベース環境設定が、論理名またはRDMS$SET_FLAGS論理名を使用する場合に変更されることがありました。以前のバージョンでは、RDMS$SET_FLAGS論理で設定された値がデフォルト値で上書きされていました。
次の例は、一部の値が無視される状況を示しています。
$ define/nolog rdms$set_flags "MAX_STABILITY,NOINDEX_COLUMN_GROUP, NOTRANSITIVITY,MAX_RECURSION(1000)" $ SQL$ attach 'filename sql$database'; show flags; Alias RDB$DBHANDLE: Flags currently set for Oracle Rdb: PREFIX,WARN_DDL,INDEX_COLUMN_GROUP,MAX_SOLUTION ,MAX_RECURSION(1000),REFINE_ESTIMATES(127),NOBITMAPPED_SCAN $
この問題は、Oracle Rdbリリース7.2.1.1で修正されました。アクションに対するデフォルト値は、RDMS$SET_FLAGS論理名を処理する前に割り当てられます。
6.1.4 SET TRANSACTIONの失敗後のRDB-E-EXCESS_TRANSエラー
Oracle Bug#5755008
ある状況では、複数のデータベース（少なくとも1つのリモート・データベースを含む）でSET TRANSACTION文が失敗すると、そのリモート・データベースは予測できない状態になっていました。この状態では、すべてのSQL文で%RDB-E-EXCESS_TRANSエラーが発生し、このエラーには、すでに進行中のトランザクションがあるものとしてリモート・データベースが指定されていました。問題を出現させるには、次の要因が必要でした。
前述の状況では、Rdbはいずれかのデータベースで失敗する前にトランザクションを正常に起動するために、各データベースのトランザクションをロールバックします。このような失敗の最も一般的な理由としてあげられるのは、別のプロセスとのロック競合です。
次の例は、失敗を示しています。
SQL> ATTACH 'ALIAS A1 FILENAME XENA::PERSONNEL'; SQL> ATTACH 'ALIAS A2 FILENAME PERSONNEL'; SQL> SET TRANSACTION ON A1 USING cont> (READ ONLY RESERVING A1.employees FOR SHARED READ) cont> AND ON A2 USING cont> (READ ONLY RESERVING A2.employees FOR SHARED READ, cont> A2.bogus FOR SHARED READ); %RDB-E-OBSOLETE_METADA, request references metadata objects that no longer exist -RDMS-F-RELNOEXI, relation BOGUS SQL> SQL> show table a2.employees %RDB-E-EXCESS_TRANS, exceeded limit of 1 transaction per database attachment -RDB-F-ON_DB, on database DISK:[DIR]MF_PERSONNEL.RDB;1
前述の例では、エイリアスA1はリモート・データベースで、エイリアスA2はローカル・データベースです。SET TRANSACTION文はどちらのデータベースに対してもREAD ONLYを指定しているため、Rdbは分散トランザクションを使用しません（これが最適化です）。SET TRANSACTION文は、エイリアスA2で存在しないbogusという名前の表を予約しようとするため失敗します。この失敗は通常どおりで予期されるものです。ただし、SET TRANSACTIONの失敗後に、RdbはエイリアスA1でトランザクションを適切にロールバックしませんでした。このため、後続のSHOW文とすべての後続の文が失敗し、RDB-E-EXCESS_TRANSエラーが発生していました。
この問題を回避するには、SET TRANSACTION文の最後でリモートのエイリアスを指定します。
この問題は、Oracle Rdbリリース7.2.1.1で修正されました。
6.1.5 Rdbオプティマイザのコスト見積りにおける浮動小数のオーバーフロー
Oracle Bug#5727379
次の問合せは、次の浮動小数オーバーフローのエラーを生成します。
select * from game t1, post t2
where (t1.post_ref_1 = t2.post_ref
OR t1.post_ref_2 = t2.post_ref
OR t1.post_ref_3 = t2.post_ref
OR t1.post_ref_4 = t2.post_ref
OR t1.post_ref_5 = t2.post_ref)
AND t2.post_flag = 1
limit to 1 row;
%RDB-E-ARITH_EXCEPT, truncation of a numeric value at runtime
-SYSTEM-F-HPARITH, high performance arithmetic trap, Imask=00000000,
Fmask=00000001, summary=02, PC=00000000007FB6F4, PS=0000001B
-SYSTEM-F-FLTINV, floating invalid operation, PC=00000000007FB6F4, PS=0000001B
問合せは、次の条件がCASTを使用して変更されると機能します。
select * from game t1, post t2
where (t1.post_ref_1 = t2.post_ref
OR t1.post_ref_2 = t2.post_ref
OR t1.post_ref_3 = t2.post_ref
OR t1.post_ref_4 = t2.post_ref
OR t1.post_ref_5 = t2.post_ref)
and CAST(t2.post_flag AS INTEGER) = 1 ! <==
limit to 1 row;
0 rows selected
この問題の既知の回避策はありません。
この問合せでエラーが生じる状況の一因となったのは、主に次の部分です。
この問題は、Oracle Rdbリリース7.2.1.1で修正されました。
6.1.6 ジグザグ一致と逆スキャンを使用する問合せからの不正な結果
Oracle Bug#5842319、5850013および4771936
逆スキャンを使用してジグザグ一致ストラテジを含む次の問合せが不正な結果を返します（本来は1行を返します）。
SQL> set flags 'strategy,detail';
SQL> select d.trx_id
cont> from t1 d
cont> where exists (select * from t2 where trx_id = d.trx_id);
Tables:
0 = T1
1 = T2
Conjunct: <agg0> <> 0
Match
Outer loop (zig-zag)
Index only retrieval of relation 0:T1
Index name T1_NDX [0:0]
Inner loop (zig-zag)
Aggregate-F1: 0:COUNT-ANY (<subselect>)
Index only retrieval of relation 1:T2
Index name T2_NDX [0:0] Reverse Scan
0 rows selected
表には次のデータが含まれます。
SQL> select * from t1; TRX_ID SEQUENCE_NO 0000044 1 0000046 2 0000047 1 SQL> select * from t2; TRX_ID LOCATION_ID COMPANY_NO 0000046 5 2 0000045 5 2
回避するには、SET FLAGSを使用するか、RDMS$SET_FLAGSの値をNOREVERSE_SCANに定義して逆スキャン機能を無効にします。次の例を見てみます。
SQL> set flags 'noreverse_scan'
SQL> !... execute the same above query here ...
Tables:
0 = T1
1 = T2
Cross block of 2 entries
Cross block entry 1
Index only retrieval of relation 0:T1
Index name T1_NDX [0:0]
Cross block entry 2
Conjunct: <agg0> <> 0
Aggregate-F1: 0:COUNT-ANY (<subselect>)
Index only retrieval of relation 1:T2
Index name T2_NDX [1:1]
Keys: 1.TRX_ID = 0.TRX_ID
TRX_ID SEQUENCE_NO
0000046 2
1 row selected
これはOracle Bug#4771936の不完全な修正に関連する問題です。この問合せでエラーが生じる一因は、主に次の部分です。
この問題は、NOT EXISTSと通常の結合問合せに類似した状況で発生することがあります。
この問題は、Oracle Rdbのリリース7.1.4.4、リリース7.1.4.5、リリース7.2.0.1、リリース7.2.0.2およびリリース7.2.1に影響します。この問題は、Oracle Rdbリリース7.2.1.1で修正されました。
6.1.7 カーソルからフェッチする際の%RDB-E-REQ_NO_TRANS
Oracle Bug#3000645
ある状況では、SQLストアド・プロシージャ、または現在アクティブなトランザクションがないプロセスを残した複数文のプロシージャを実行すると、SQLで%RDB-E-REQ_NO_TRANSエラーが生成されます。このエラーは、ホールド・カーソルとともに使用する場合、頻繁に発生していました。
次のSQLは、実行すると状態を設定するストアド・プロシージャ（TX_END）を作成します。この状況で問題が発生していました。ストアド・プロシージャは、アクティブなトランザクションを単純に終了し、戻ることに注意してください。
create module tx_end
language sql
declare transaction read only
procedure tx_end();
begin
declare :v_active tinyint default 0;
get diagnostics :v_active = TRANSACTION_ACTIVE;
if (:v_active <> 0) then
rollback;
end if;
end;
end module;
問題を回避するには、ストアド・プロシージャ内でトランザクションを実行するのではなく、明示的なSQL文でトランザクションを終了させます。
この問題は、Oracle Rdbリリース7.2.1.1で修正されました。
6.1.8 ビットマップ・スキャンが有効なDistinct問合せのバグチェック
Oracle Bug#5295755
ビットマップ・スキャンが有効なDistinct問合せの2回目の実行時に、バグチェックが発生することがありました。
set flags 'nobitmap,strategy,detail';
select distinct test_nbr from t1 where asn='10000';
Tables:
0 = T1
Reduce: 0.TEST_NBR
Leaf#01 Sorted 0:T1 Card=141
Bool: 0.ASN = '10000'
FgrNdx IND_TN [0:0] Fan=17
BgrNdx1 IND_ASN [1:1] Fan=14
Keys: 0.ASN = '10000'
TEST_NBR
1.000
2.000
2 rows selected
set flags 'bitmap,strategy,detail';
select distinct test_nbr from t1 where asn='10000';
%RDMS-I-BUGCHKDMP, generating bugcheck dump file RDSBUGCHK.DMP;
次の2つの例外が発生する可能性がありました。
***** Exception at 01001154 : RDMS$$EXE_CLOSE + 00000574 %COSI-F-BUGCHECK, internal consistency failure
または
***** Exception at 0124631C : KOD$ROLLBACK + 0000032C %COSI-F-BUGCHECK, internal consistency failure
次の例に示すように、2回目の実行でビットマップが有効ではない場合、問合せは機能します。
set flags 'nobitmap,strategy';
select distinct test_nbr from t1 where asn='10000';
Tables:
0 = T1
Reduce: 0.TEST_NBR
Leaf#01 Sorted 0:T1 Card=141
Bool: 0.ASN = '10000'
FgrNdx IND_TN [0:0] Fan=17
BgrNdx1 IND_ASN [1:1] Fan=14
Keys: 0.ASN = '10000'
TEST_NBR
1.000
2.000
2 rows selected
この問合せでエラーの一因となったのは、主に次の部分です。
この問題は、Oracle Rdbのリリース7.1.4.4、リリース7.1.4.5、リリース7.2.0.1、リリース7.2.0.2およびリリース7.2.1に影響します。この問題は、Oracle Rdbリリース7.2.1.1で修正されました。
6.1.9 ALTERには記憶域への読み書きアクセスが必要
Oracle Rdbリリース7.2.1では、ディスク上の行の長さを変更する可能性があるSQLのALTER TABLE文、ALTER STORAGE MAP文、TRUNCATE TABLE文またはALTER INDEX文では、読み書きアクセスを許可する記憶域にオブジェクトのすべてのパーティションが存在する必要があります。さらに、読み書きアクセスを許可するにはRDB$SYSTEM記憶域も必要です。
エラー「RDMS-F-READONLY, data in a read-only storage area may not be accessed for update」が返されます。このエラーは、次の例のように、参照する記憶域への読み書きアクセスが許可されないことを示します。
SQL>ALTER DATA FILE 'PLUGH' ALTER STORAGE AREA U2 READ ONLY;
.
.
.
SQL>ALTER TABLE PARTUNIF ADD COLUMN RDB_TEST1 INT;
%RDB-E-NO_META_UPDATE, metadata update failed
-RDMS-F-READONLY, data in a read-only storage area may
not be accessed for update
Oracle Rdbリリース7.2.1.1では、読み書きアクセスを許可する記憶域に、変更されたオブジェクトが存在するという制限はなくなりました。
6.2 SQLエラーの修正
6.2.1 SQL/Services実行プログラムで99%のCPU消費がループする
Oracle Bug#4401924および5353228
Rdb 7.1.4.3.1以降のバージョンのSQL/Services 7.1.5.9.1にアップグレードした後、一部のアプリケーションでは、SQL/Services実行プログラムでかなりの割合のCPUを消費する逼迫したループに陥ることが頻繁にありました。これはプログラムが終了するまで続きました。この問題は、通常、実行プログラムが新しいクライアントへのサービス提供を開始して、問題が発生するVMSノードの他のすべてのパフォーマンスが著しく低下した直後に発生します。この問題を取り除くには、ループしている実行プログラムのプロセスに対してSTOP/IDを実行します。
この問題は、キャッシュ済メタデータのSQLの管理に関連するメモリー破損が原因で生じていました。メモリー破損は、一部の接続にカーソルが定義されている複数のSQL接続に関連していました。通常、DISCONNECT文の後に発生しますが、それ以外でも発生する可能性はあります。同様に、前述のSQL/Services実行プログラムだけでなく、SQL接続やカーソルを使用するアプリケーションにも影響します。どのメモリーが破損しているかによって、Rdbの他のレイヤーやユーザー・アプリケーションでの障害など様々な現象が発生することがありました。
注意: リリース7.1.2では、ループ動作の発生に関して、この問題の影響を軽減する変更が行われました。この変更は修正ではありません。
この問題の回避策はありません。
この問題は、Oracle Rdbリリース7.2.1.1で修正されました。
6.2.2 一部のSQLのダイアレクトに必要な警告が配信されない
Oracle Bug#3651847および4532451
NULLの行の削除（%RDB-I-ELIM_NULL）や、文字列の切捨て（%RDB-I-TRUN_RTRV）に対する必要な警告（情報コード）が、シングルトンのSELECT文およびシングルトンのUPDATE文（つまり、INTO句を使用する単一行を返す文）に対して返されませんでした。これは、次の対話型SQLのコマンドを使用するPERSONNELデータベースで示されます。
SQL> set dialect 'sql92';
SQL> attach 'filename sql$database';
SQL>
SQL> ! Force a row to contain NULL for SALARY_AMOUNT
SQL> update salary_history
cont> set salary_amount = NULL
cont> where employee_id = '00471'
cont> and salary_end = date vms'20-Aug-1981';
1 row updated
SQL>
SQL> declare :avg_sal integer(2);
SQL>
SQL> ! No informational generated (but is expected)
SQL> select avg(salary_amount) into :avg_sal
cont> from salary_history where employee_id = '00471'
cont> and salary_end >= date vms'1-AUG-1970';
SQL> show sqlca
SQLCA:
SQLCAID: SQLCA SQLCABC: 128
SQLCODE: 0
SQLERRD: [0]: 0
[1]: 0
[2]: 1
[3]: 0
[4]: 0
[5]: 0
SQLWARN0: 0 SQLWARN1: 0 SQLWARN2: 0
SQLWARN3: 0 SQLWARN4: 0 SQLWARN5: 0
SQLWARN6: 0 SQLWARN7: 0
SQLSTATE: 00000
SQL> print :avg_sal;
AVG_SAL
60893.86
SQL> rollback;
必要なSQLCODEの値とSQLSTATEの値が返されるようになりました。これにより、前述の例では次の相違が生じます。
SQL> select avg(salary_amount) into :avg_sal
cont> from salary_history where employee_id = '00471'
cont> and salary_end >= date vms'1-AUG-1970';
%RDB-I-ELIM_NULL, null value eliminated in set function
SQL> show sqlca
SQLCA:
SQLCAID: SQLCA SQLCABC: 128
SQLCODE: 1003
SQLERRD: [0]: 0
[1]: 0
[2]: 1
[3]: 0
[4]: 0
[5]: 0
SQLWARN0: 0 SQLWARN1: 0 SQLWARN2: 0
SQLWARN3: 0 SQLWARN4: 0 SQLWARN5: 0
SQLWARN6: 0 SQLWARN7: 0
SQLSTATE: 01003
%RDB-I-ELIM_NULL, null value eliminated in set function
この問題は、Oracle Rdbリリース7.2.1.1で修正されました。
6.2.3 SET AUTOMATIC TRANSLATION ONで問合せから不正な結果が生じる
Oracle Bug#5849845
Oracle Rdbリリース7.2の以前のリリースでは、SET AUTOMATIC TRANSLATION ONコマンドにより、一部の問合せで不正な結果が返されることがありました。これは、テキスト文字列リテラル、パラメータまたは変数が数列と比較される場合に発生していました。AUTOMATIC TRANSLATIONは、テキスト以外の値を誤って処理していました。
次の例は、SET AUTOMATIC TRANSLATION ONコマンドがセッションで使用される場合の不正な結果を示しています。
SQL> set automatic translation 'off';
SQL> select * from TEST_NLS_D where num = '333.333';
%SQL-I-NUMCMPTXT, Numeric column will be compared with string literal as text
NUM TDATE
333.333 3-MAR-2099 00:00:00.00
1 row selected
SQL>
SQL> set automatic translation 'on';
SQL> select * from TEST_NLS_D where num = '333.333';
%SQL-I-NUMCMPTXT, Numeric column will be compared with string literal as text
0 rows selected
SQL> rollback;
この問題は、Oracle Rdbリリース7.2.1.1で修正されました。ほどんどのOracle Rdbユーザーの場合、デフォルトはOFFです。ただし、Rdbの最新バージョンのOCI Servicesではこのコマンドを使用するため、OCIアプリケーションを介した問合せは影響を受ける可能性があります。
6.2.4 宣言した変数がOracleダイアレクトの動的な文によって無視される
Oracle Bug#5847260
以前のバージョンのOracle Rdbでは、動的な文がDECLARE構文によって作成された変数を無視することがありました。これは、ダイアレクトがORACLE LEVEL1またはORACLE LEVEL2に設定されている場合に発生していました。
この問題は、Oracle Rdbリリース7.2.1.1で修正されました。Oracleダイアレクトは、これらの変数を宣言された変数として正しく認識し、パラメータ・マーカーとして認識しないようになりました。
6.2.5 パラメータがCONCAT操作にある場合、予期しないDATTYPUNKエラーがレポートされる
Oracle Bug#5847260
Oracle Rdbリリース7.2.1では、動的なSQL文を処理する際に、文にパラメータ・マーカーのある連結が含まれている場合、エラーがレポートされていました。次の例は、このエラーを示しています。
-> UPDATE EMPLOYEES SET ADDRESS_DATA_2='My Address ' || :B1 WHERE EMPLOYEE_ID = :B1; Error -1: %SQL-F-DATTYPUNK, Data type unknown. Expression cannot use only host variables
この問題は、Oracle Rdbリリース7.2.1.1で修正されました。連結はデフォルトのVARCHAR(2000)型をパラメータに割り当て、文字列の最終的な結果の長さを計算できるようになりました。以前のバージョンでは、パラメータは、短すぎる最初のパラメータの長さにデフォルトで設定されていました。
6.2.6 マップされていない表に対するALTER TABLEでAIPの長さが設定されない
Oracle Rdbリリース7.2.1.0では、AIPの長さを更新するサポートが追加されました。ただし、STORE句を使用するSTORAGE MAPが含まれない表に対するALTER TABLEでは、現在、AIPの長さが更新されません。
次の例は、問題を示しています（ログ出力にLOGMODVALメッセージはありません）。
SQL> set flags 'stomap_stats'; SQL> SQL> create table T (a integer); SQL> SQL> alter table T cont> add column b varchar(230); ~As: reads: async 0 synch 8, writes: async 10 synch 0 SQL> SQL> commit; SQL> SQL> create storage map T_MAP cont> for T cont> store in RDB$SYSTEM; ~As: create storage map "T_MAP" ~As: Table "T" (sys=0, rest=0, tmptbl=0) ~As: creating storage mapping routine T_MAP (columns=0) ~As: creating system module RDB$STORAGE_MAPS SQL> SQL> alter table T cont> add column c timestamp(2); ~As: reads: async 0 synch 15, writes: async 11 synch 0 SQL> SQL> commit; %RDMS-I-LOGMODVAL, modified record length to 252 %RDMS-W-REBUILDSPAMS, SPAM pages should be rebuilt for logical area T ~As unlocking table "T" (PU -> PR)
この問題を回避するには、前述の例に示すように表に記憶域マップを追加するか、あるいは次の例に示すように新しいRMU Set AIPコマンドを使用します。
SQL> set flags 'stomap_stats'; SQL> SQL> create table T (a integer); SQL> SQL> alter table T cont> add column b varchar(230); ~As: reads: async 0 synch 8, writes: async 10 synch 0 SQL> SQL> commit; $ define/user rdms$set_flags "stomap_stats" $ rmu/set aip abc t/length %RDMS-I-LOGMODVAL, modified record length to 244 %RDMS-W-REBUILDSPAMS, SPAM pages should be rebuilt for logical area T
この問題は、Oracle Rdbリリース7.2.1.1で修正されました。
6.3 RMUエラーの修正
6.3.1 RMUのオンライン検証のRMUVLAREA$VERIFY_LAREA_PAGESでACCVIOが発生する
オンラインのRMU /VERIFY操作で、検証の実行中に記憶域が拡張された場合、内部データ構造のサイズが縮小されることがありました。このため、次のようなRMUバグチェックのダンプ・ファイルなど、いくつかの障害が発生することがありました。
***** Exception at 000000000080B101 :
RMU72\RMUVLAREA$VERIFY_LAREA_PAGES + 00000581
%SYSTEM-F-ACCVIO, access violation, reason mask=00,
virtual address=00000000014E0005, PC=000000000080B101, PS=0000001B
Saved PC = 000000000080A6B0 : RMU72\RMUVLAREA$VERIFY_ALL_LAREAS + 00000390
Saved PC = 00000000007BA110 : RMU72\RMUVER$VERIFY + 00003100
Saved PC = 0000000000470820 : RMU72\RMU$VERIFY + 00002E70
Saved PC = 0000000000463A30 : RMU72\RMU_DISPATCH + 00002840
Saved PC = 0000000000460A50 : RMU72\RMU_STARTUP + 00000910
通常、検証操作を再実行すると正しく完了します。
この問題は、Oracle Rdbリリース7.2.1.1で修正されました。データ構造にアクセスする場合、割り当てられたメモリー以外にアクセスしないようになりました。
6.3.2 RMU/SHOW LOGICAL_NAMESにRDM$MONITORnnが含まれない
Oracle Bug#5847856
以前は、RMU/SHOW LOGICAL_NAMESコマンドで表示される論理名のリストには、論理名RDM$MONITORnnが含まれていませんでしたが、論理名RDM$MONITORが含まれていました。
この問題は、Oracle Rdbリリース7.2.1.1で修正されました。論理名RDM$MONITORnn（nnは実行するRMUの複数バージョンのRdbインストール・バージョンを参照する）が表示されるようになりました。
6.3.3 ビットマップ索引に対するRMU/VERIFY/INCREMENTALの不正な診断
Oracle Bug#4149656
RMU/VERIFYがBツリー・ビットマップ索引を参照していることを把握している場合でも、索引を検証するルーチンに渡される不正なフラグによって、ハッシュが索引タイプのメッセージに誤って挿入されることがありました。また、索引に問題がない場合でも、RMU-W-BADHDADBK、RMU-I-BTRDUPCARおよびRMU-I-BTRERPATHなどのビットマップBツリー索引の無効な診断がRMU/VERIFY/INCREMENTALによって出力されていました。これは、RMU/VERIFYがBツリー索引のビットマップの重複連鎖を検証しているときにコンテキストが失われることで発生していました。
この問題は、RMU/VERIFY/INCREMENTALがBツリー・ビットマップ索引の重複連鎖を検証しているときにのみ発生しました。/NODATAを指定する場合は発生しませんでした。複数の重複ビットマップ・レコードのフェッチを必要とする長いビットマップ連鎖で発生していました。
次の例は、RMU/VERIFY/INCREMENTALで出力される無効な索引診断を示しています。
$ RMU/VERIFY/INCREMENTAL/ALL TEST_DATABASE %RMU-W-BADHDADBK, Bad logical area DBID in hashed index data record dbkey 1716:674953227:-32678 Found 06B4 (hex). %RMU-W-BADHDADBK, Bad logical area DBID in hashed index data record dbkey 1716:674953227:-32677 Found 06B4 (hex). %RMU-W-BADHDADBK, Bad logical area DBID in hashed index data record dbkey 1716:674953227:-32676 Found 06B4 (hex).
この問題を回避するには、/NODATAを指定するか、または検証に/INCREMENTALを指定しないようにします。
$ RMU/VERIFY/INCREMENTAL/INDEX/NODATA TEST_DATABASE $ RMU/VERIFY/ALL TEST_DATABASE
この問題は、Oracle Rdbリリース7.2.1.1で修正されました。
6.3.4 PARALLELおよびCOMPRESS=ZLIBを指定したRMU/BACKUPが失敗する
Oracle Bug#5870330
PARALLEL修飾子とCOMPRESS=ZLIB修飾子を指定したRMU/BACKUPコマンドを実行すると、次の内容のバグチェックが発生していました。
Alpha OpenVMS 8.2 Oracle Rdb Server 7.2.1.0.1 Got a RMUBUGCHK.DMP SYSTEM-F-ACCVIO, access violation, virtual address=0000000000000000 Exception occurred at RMUSHR72\COSIZLIB$FINISH_COMPRESS + 00000048 Called from RMUSHR72\RMUBCK$BF_BACKUP_THREAD + 00001244 Called from RMUSHR72\RMUIO$TERMINATE_THREAD + 00000040 Called from RMUSHR72\RMUIO$FIREWALL + 00000040 Running image RMUEXEC72.EXE Dump created: 7-FEB-2007 08:45:58.93
バックアップ・コードの管理では、初期化されていない圧縮コンテキスト構造が使用されていました。PARALLELを使用せずにCOMPRESS=ZLIBを使用し、出力に複数のテープ・ドライブを使用する場合、同じエラーが発生することがありました。
この問題の既知の回避策はありません。
この問題は、Oracle Rdbリリース7.2.1.1で修正されました。
6.4 行キャッシュ・エラーの修正
6.4.1 行キャッシュのスナップショットが有効な場合のオンラインRMUバックアップ時のバグチェック
Oracle Bug#4260102
行キャッシュのスナップショット機能を使用する場合、データベースのキャッシュ済の行が大きくなるように変更できます。この変更を行うには、データベース・ページに領域を割り当てる必要があります。この場合、行のスナップショットはデータベースに書き込まれませんが、行キャッシュに単独で保持されます。オンラインのRMU操作（RMU /BACKUPなど）は、スナップショットの行のコピーを見つけられずに失敗し、ダンプ・ファイルにエラー「BADPAGNUM, PAGE 4294967295」が表示されます。
この問題は、Oracle Rdbリリース7.2.1.1で修正されました。実際のディスク上の行の変更が行われる前に、サイズを調整する行のスナップショット連鎖がスナップショットの記憶域に書き込まれます。
6.4.2 VMS$MEM_RESIDENT_USER要件の緩和
Oracle Bug#5859487
以前は、データベースに対して有効化されたキャッシュがない場合でも、常駐メモリーに構成された行キャッシュがあるデータベースを開くにはVMS$MEM_RESIDENT_USER修飾子が必要でした。
この制限は、Oracle Rdbリリース7.2.1.1で緩和されました。データベースが行キャッシュに対して有効化されていない場合、キャッシュが常駐メモリーに定義されている場合でもVMS$MEM_RESIDENT_USER修飾子は必要ありません。
6.5 RMU Show Statisticsエラーの修正
6.5.1 RMU /SHOW STATISTICSからのラッチによるハング
Oracle Bug#4397634および5842040
以前のリリースのOracle Rdbでは、非常にわずかな時間内で、データベース・アタッチ・シーケンス時にラッチを操作している間にRMU /SHOW STATISTICSコマンドを実行するプロセスがハングすることがありました。イベントの正確なタイミングとシーケンスに応じて、このプロセスはデータベースの他のユーザーをブロックすることがあります。
この問題は、Oracle Rdbリリース7.2.1.1で修正されました。
6.5.2 KUTDIS$LONG_TX_NOTIFYでのRMU/SHOW STATISTICSのバグチェック
Oracle Bug#5867253
Oracle Rdbリリース7.2.1では、構成オプションLONG_TX_SECONDSの使用時に、RMU /SHOW STATISTICSコマンドが失敗し、バグチェックのダンプが発生することがありました。バグチェックのダンプの内容は、次のようになります。
SYSTEM-F-ACCVIO, access violation Exception occurred at RMU72\KUTDIS$LONG_TX_NOTIFY + 00000424 Called from RMU72\KUTDIS$EVENT_NOTIFY + 00000054 Called from RMU72\KUTDIS$DISPLAY_ASTX + 00000584 Called from RMU72\KUT$DISPLAY + 0000199C Running image RMU72.EXE Command line was "RMUI/SHOW STATISTIC DSA0:[DB]FOO.RDB;/NOINTERACTIVE/CONFIGURATION=DSA0:[FOO]FOO.CFGCFG"
この問題は、Oracle Rdbリリース7.2.1.1で修正されました。
6.6 ホット・スタンバイ・エラーの修正
6.6.1 LRSの停止の失敗RDMS-F-PARTDTXNERR/SYSTEM-F-NOSUCHID
Oracle Bug#5754461
Oracle Rdbのホット・スタンバイ機能に関する問題が確認されています。OpenVMS $GETGTIシステム・サービスがステータス値SS$_NOSUCHIDを返す場合、LRSプロセスを正常に停止することができないことがあります。このため、スタンバイ・データベースに不整合が生じていました。
この問題は、Oracle Rdbリリース7.2.1.1で修正されました。LRSプロセスは、返されたSS$_NOSUCHIDステータスをSS$_NOSUCHTIDステータスと同じものとして処理するようになりました。ステータスは正常に処理され、LRSが失敗することはなくなりました。
この章では、Oracle Rdbリリース7.2.1.0で修正されるソフトウェアの誤りについて説明します。
7.1 すべてのインタフェースに適用されるソフトウェアの誤りの修正
7.1.1 I64でのバックアップの不正なチェックサムとCRC値
Rdbリリース7.2.0.2以降のI64システムで、.RBFバックアップ・ファイル内のチェックサムまたはCRC値が正しくない場合があります。この違いにより、/CRC=CHECKSUMを使用する場合、リストア操作時にチェックサムのエラーが発生することがあります。つまり、CRC=CHECKSUMが使用された場合、I64のRdb 7.2.0.2でのリストアは、その他のプラットフォームまたはバージョンで行われたバックアップを読み取ることができません。
回避策として、/CRC=CHECKSUMではなく、/CRC=AUTODIN_IIのデフォルトのCRCアルゴリズムを使用することをお薦めします。
この問題はOracle Rdbリリース7.2.1で修正されました。Oracle Rdbで計算されたチェックサムの値は、すべてのプラットフォームやバージョンと同じになりました。
7.1.2 バグチェックのループによって多くのバグチェックのダンプが作成される
Oracle Bug#5411895および5361954
特定の状況では、あるバグチェックのダンプが原因で別のバグチェックのダンプが発生します。その結果、実際に制限された数が生成される場合を除いて、バグチェックのダンプが無制限に生成されます。作成されるバグチェックのダンプ数が制限されるのは、使用可能なディスク領域を使い切ってしまうためです。
この問題を修正する試みがなされました。プロセスで3つのバグチェックのダンプが作成されると、それ以降のダンプはミニ・ダンプとなります。3つのバグチェックのミニ・ダンプが作成されると、ダンプは止まり、COSI$_FATINTERRステータスが返されます。
これ以降にバグチェックのダンプが作成されそうになると、COSI$_FATINTERRが単純に返されます（つまり、バグチェックのダンプは生成されなくなります）。
この問題の原因となる問合せの例を次に示します。
SELECT TIPO, OPFU
FROM T1
WHERE CODE ='100' AND
VALUE = '0057984193004785667' AND
COOP = 'OCA0604WOREST' AND
CRTC = 'MFV' AND
OPFU = '20011228' AND
( TIPO = 'TCI' OR
(IVSN = 'I' AND (TIPO = 'COM' OR TIPO = 'ATR') ) ) ;
%RDMS-I-BUGCHKDMP, generating bugcheck dump file RDSBUGCHK.DMP;
%RDMS-I-BUGCHKDMP, generating bugcheck dump file RDSBUGCHK.DMP;
%RDMS-I-BUGCHKDMP, generating bugcheck dump file RDSBUGCHK.DMP;
%RDMS-I-BUGCHKDMP, generating bugcheck dump file RDSBUGCHK.DMP;
%RDMS-I-BUGCHKDMP, generating bugcheck dump file RDSBUGCHK.DMP;
...etc...
この変更は、Oracle Rdbリリース7.2.1で行われました。
7.1.3 全索引スキャンを使用する場合、左側外部結合の問合せの速度が低下する
Oracle Bug#5567495
リリース7.1.4.1からリリース7.1.4.4にアップグレードした後、左側外部結合操作の外部区間で全索引スキャンを使用する場合、特定の問合せの実行速度が著しく低下するという状況がユーザーからレポートされました。データを使用せずに次の単純なスクリプトを使用して問題を再現できました。出力ストラテジの違いが問題を示しています。
create table t1 (
col_one integer,
col_two integer,
price integer);
create table t2 (
col_one integer,
col_two integer,
line_amt COMPUTED BY
(select c1.price from t1 c1
where ((c1.col_one = t2.col_one)
and (c1.col_two = t2.col_two)))) ;
create unique index t1_ndx on t1 (col_one, col_two);
create unique index t2_ndx on t2 (col_one, col_two);
create view v_t1_loj_t2
(col_one, col_two, total) as
(select c2.col_one, c2.col_two, SUM(c3.line_amt)
from t1 as c2
LEFT OUTER JOIN
t2 as c3
ON ((c3.col_one = c2.col_one) AND
(c3.col_two = c2.col_two))
GROUP BY c2.col_one, c2.col_two);
! The following is the query that slows down in performance since the
! strategy applies a full index scan at the outer leg of the left outer join
! operation, as compared to "Direct lookup" index retrieval strategy.
select t1.col_two,
(select v1.total from v_t1_loj_v2 v1
where v1.col_one = t1.col_one and
v1.col_two = t1.col_two) as v_total
from t1 where t1.col_one = 1 ;
Cross block of 2 entries
Cross block entry 1
Conjunct Index only retrieval of relation T1
Index name T1_NDX [1:1]
Cross block entry 2
Aggregate Conjunct Aggregate
Cross block of 2 entries
Cross block entry 1
Match (Left Outer Join)
Outer loop
Index only retrieval of relation T1
Index name T1_NDX [0:0] <== Full index scan
Inner loop (zig-zag)
Index only retrieval of relation T2
Index name T2_NDX [0:0]
Cross block entry 2
Aggregate Get Retrieval by index of relation T1
Index name T1_NDX [2:2] Direct lookup
0 rows selected
Rdbリリース7.1.4.1.1のストラテジは、左側外部結合操作の外部ループで索引検索がより正確に実行される点を除き、ほとんど同じです。
Cross block of 2 entries
Cross block entry 1
Conjunct Index only retrieval of relation T1
Index name T1_NDX [1:1]
Cross block entry 2
Aggregate Conjunct Aggregate
Cross block of 2 entries
Cross block entry 1
Match (Left Outer Join)
Outer loop
Index only retrieval of relation T1
Index name T1_NDX [2:2] Direct lookup <== Best one
Inner loop (zig-zag)
Index only retrieval of relation T2
Index name T2_NDX1 [0:0]
Cross block entry 2
Aggregate Get Retrieval by index of relation T1
Index name T1_NDX [2:2] Direct lookup
この問題の既知の回避策はありません。
この問合せでエラーが生じる状況の一因となったのは、主に次の部分です。
この問題は、Oracle Rdbリリース7.2.1で修正されました。
7.1.4 DIO$LACB_CREATE + 00000174でのDBRのバグチェック
Oracle Bug#5467328
新しい表または索引の作成をロールバックしている間にプロセスが終了した場合、データベース・リカバリ・プロセス（DBR）でバグチェックが発生することがありました。たとえば、次のスクリプトについて考えます。
SQL> CREATE DATABASE FILENAME TEST; SQL> CREATE TABLE T1 (C1 INT); SQL> INSERT INTO T1 VALUES (1); 1 row inserted SQL> ROLLBACK;
コマンドの前述のシーケンスでは、トランザクションのロールバック時に、プロセスが表T1の作成をロールバックし、表の領域インベントリ・ページ（AIP）を更新して、変更されたAIPエントリをディスクにフラッシュし、リカバリ・ユニット・ジャーナル（RUJ）を切り捨てる前に終了する場合、存在しない表T1にアクセスしようとするとDBRが失敗していました。最初のDBRのバグチェックには、次のような例外が含まれます。
***** Exception at 00000000001A6C0C : RDMDBR72\DIOLACB$LACB_AIP_ENT_GET + 000005CC %COSI-F-BUGCHECK, internal consistency failure
次にデータベースにアクセスしようとすると、DBRのバグチェックが発生し、次のような例外が表示されます。
***** Exception at 00000000001A6174 : RDMDBR72\DIO$LACB_CREATE + 00000174 %RDMS-F-CANTFINDLAREA, cannot locate logical area 58 in area inventory page list
この問題は、表の挿入をロールバックしようとしたときに、表が存在しないという可能性に対してDBRの準備ができていなかったために発生していました。
この問題が発生する場合、問題を解決する回避策はサポートされていません。データベースをリストアおよびリカバリするか、またはデータベースにアクセスする前にこの問題の修正が含まれるリリースにOracle Rdbを更新する必要があります。
この問題は、Oracle Rdbリリース7.2.1で修正されました。
7.1.5 モニター終了後にプロセスが必ずしも終了しない
Oracle Bug#5361981
Oracle Rdbモニター・プロセスが異常終了すると、そのノードのデータベースにアタッチされているすべてのユーザー・プロセスはすぐに終了します。ただし、このようにならない場合があり、モニターが失敗した後も、ユーザー・プロセスはOracle Rdbリソースに引き続きアクセスしていました。次の例を見てみます。
イベントの前述のシーケンスでは、ノード1のユーザー・プロセスは、モニター・プロセスが終了するとすぐに終了しますが、アクティブのままでした。
この問題を回避するには、RMU/OPENコマンドを使用するか、ユーザーがデータベースにアクセスするすべてのノード上のデータベースを手動で開きます。
この問題は、Oracle Rdbリリース7.2.1で修正されました。
7.1.6 OR Index Retrievalとビットマップ式スキャンを使用する場合の不正な結果
Oracle Bug#5363170
OR Index Retrievalを含むオプティマイザでストラテジが選択され、ビットマップ式スキャンが有効な場合、問合せから不正な結果が返されることがありました。
次の例では、通常は100行を返しますが、1行しか返されていません。ビットマップ・スキャンが有効で、2番目（内部）のcross blockでストラテジにOR Index Retrievalが含まれることに注意してください。
SQL> set flags 'bitmap,strategy,detail'
SQL> select t1.id from t1 join t2
cont> on t1.id=t2.id or t1.id=t2.id
cont> where t1.f2=1 and t1.f2=1;
Tables:
0 = T1
1 = T2
Cross block of 2 entries
Cross block entry 1
Conjunct: 0.F2 = 1
Conjunct: 0.F2 = 1
Get Retrieval sequentially of relation 0:T1
Cross block entry 2
Conjunct: ((0.ID = 1.ID) OR (0.ID = 1.ID)) AND (0.F2 = 1) AND (0.F2 = 1)
AND (0.ID = 1.ID)
OR index retrieval
Index only retrieval of relation 1:T2
Index name I2 [1:1]
Keys: 0.ID = 1.ID
T1.ID
00164
1 row selected
この問題を回避するには、ビットマップ・スキャンを使用しないようにします。
この問題は、Oracle Rdbリリース7.2.1で修正されました。
7.1.7 AND/OR条件を使用する問合せの単一表でのバグチェック
Oracle Bug#5361954
データベースをAlpha Rdb 7.0.6.5からItanium 7.2.0.0に移行した後、特定の問合せで次の問合せを含むバグチェックが常に発生することがユーザーから報告されました。
SELECT TIPO, OPFU
FROM T1
WHERE CODE ='100' AND
VALUE = '0057984193004785667' AND
COOP = 'OCA0604WOREST' AND
CRTC = 'MFV' AND
OPFU = '20011228' AND
( TIPO = 'TCI' OR (IVSN = 'I' AND (TIPO = 'COM' OR TIPO = 'ATR') ) ) ;
%RDMS-I-BUGCHKDMP, generating bugcheck dump file RDSBUGCHK.DMP;
%RDB-F-BUG_CHECK, internal consistency check failed
問題は、Rdb 7.2 Integrityプラットフォームに固有のものではありません。このバグチェックは、Rdbのすべてのバージョンで発生していました。
select * from rdb$databaseなどのメタデータの問合せ後に問合せを実行する場合、問合せが失敗しなくなることがありました。EXPORT/IMPORTを実行する場合も問題は発生しません。
次の例に示すように、SQLフラグMAX_STABILITYが定義される場合、問合せは機能します。
SET FLAGS 'MAX_STABILITY';
SELECT TIPO, OPFU
FROM T1
WHERE CODE ='100' AND
VALUE = '0057984193004785667' AND
COOP = 'OCA0604WOREST' AND
CRTC = 'MFV' AND
OPFU = '20011228' AND
( TIPO = 'TCI' OR (IVSN = 'I' AND (TIPO = 'COM' OR TIPO = 'ATR') ) ) ;
Firstn Sort Conjunct
Get Retrieval by index of relation T1
Index name T1_NDX3 [5:5,(7:7)2] Bool
TIPO OPFU
COM 20011228
1 row selected
問合せが失敗する表T1に対して次の索引を定義する必要があります。
T1_NDX1 with column CODE
and column NUMOP
T1_NDX2 with column TIPO
and column CODE
and column VALUE
and column COOP
and column CRTC
and column OPFU
and column IVSN
and column NUMOP
T1_NDX3 with column CODE descending
and column VALUE descending
and column COOP
and column CRTC
and column TIPO
and column IVSN
and column OPFU
この問題は、Oracle Rdbリリース7.2.1で修正されました。
7.1.8 ビットマップ・スキャンが有効な場合のバグチェック
Oracle Bug#5414635
次の問合せでは、ビットマップ・スキャン機能が有効な場合にバグチェックが発生します。
set flags 'bitmap'; select * from T1 where C2 = 'XYZ' or C4 >='03-jul-2006' ; %RDMS-I-BUGCHKDMP, generating bugcheck dump file RDSBUGCHK.DMP;
次の例に示すように、ビットマップ・スキャンが無効の場合、問合せは機能します。
set flags 'nobitmap'; SQL> select * from T1 where C2 = 'XYZ' or C4 >='03-jul-2006' ; Tables: 0 = T1 Conjunct: (0.C2 = 'XYZ') OR (0.C4 >= '3-JUL-2006') Get Retrieval by index of relation 0:T1 Index name X1_T1 [0:0] 0 rows selected
この問題は、Oracle Rdbリリース7.2.1で修正されました。
7.1.9 Aggregateを使用するスター型結合の問合せからの不正な結果
Oracle Bug#5192800
次の問合せは、表t0とその他の2つの表（t1およびt2）を結合するスター型結合のようになります。通常はゼロ行を返しますが、かわりに1つの行が誤って検索されています。
select t0.acct_num, t1.scard_id
from
subscr t0
inner join
scard t1
on
(t1.acct_num = t0.acct_num
and exists
(select *
from hwatt t3 where t3.acct_num = t1.acct_num))
left outer join
service t2
on
t2.acct_num = t0.acct_num and
t2.dt_tim_stmp =
(select max(t4.dt_tim_stmp)
from service t4
where t4.acct_num = t0.acct_num);
Tables:
0 = SUBSCR
1 = SCARD
2 = SERVICE
3 = HWATT
4 = SERVICE
Cross block of 2 entries
Cross block entry 1
Cross block of 2 entries (Left Outer Join)
Cross block entry 1
Cross block of 3 entries
Cross block entry 1
Get Retrieval sequentially of relation 0:SUBSCR
Cross block entry 2
Aggregate: 0:MAX (4.DT_TIM_STMP)
Conjunct: 4.ACCT_NUM = 0.ACCT_NUM
Get Retrieval sequentially of relation 4:SERVICE
Cross block entry 3
Conjunct: 1.ACCT_NUM = 0.ACCT_NUM
Get Retrieval sequentially of relation 1:SCARD
Cross block entry 2
Conjunct: (2.ACCT_NUM = 0.ACCT_NUM) AND (2.DT_TIM_STMP = <agg0>)
Get Retrieval sequentially of relation 2:SERVICE
Cross block entry 2
Aggregate-F1: 1:COUNT-ANY (<subselect>)
Conjunct: 3.ACCT_NUM = 1.ACCT_NUM
Get Retrieval sequentially of relation 3:HWATT
T0.ACCT_NUM T1.SCARD_ID
1 2
1 row selected
次の例に示すように、MAX aggregateのsubselect問合せを含む等式条件がWHERE句に変換される場合、問合せは機能します。
select t0.acct_num, t1.scard_id
from
subscr t0
inner join
scard t1
on
(t1.acct_num = t0.acct_num
and exists
(select *
from hwatt t3 where t3.acct_num = t1.acct_num))
left outer join
service t2
on
t2.acct_num = t0.acct_num
where ! <== converted into WHERE clause
h.dt_tim_stmp =
(select max(sv2.dt_tim_stmp)
from service sv2 where sv2.acct_num = ss.acct_num);
Tables:
0 = SUBSCR
1 = SCARD
2 = SERVICE
3 = HWATT
4 = SERVICE
Cross block of 2 entries
Cross block entry 1
Cross block of 2 entries (Left Outer Join)
Cross block entry 1
Cross block of 3 entries
Cross block entry 1
Get Retrieval sequentially of relation 0:SUBSCR
Cross block entry 2
Conjunct: 1.ACCT_NUM = 0.ACCT_NUM
Get Retrieval sequentially of relation 1:SCARD
Cross block entry 3
Conjunct: <agg0> <> 0 <== See Note
Aggregate-F1: 0:COUNT-ANY (<subselect>)
Conjunct: 3.ACCT_NUM = 1.ACCT_NUM
Get Retrieval sequentially of relation 3:HWATT
Cross block entry 2
Conjunct: 2.ACCT_NUM = 0.ACCT_NUM
Get Retrieval sequentially of relation 2:SERVICE
Cross block entry 2
Conjunct: 2.DT_TIM_STMP = agg1
Aggregate: 1:MAX (4.DT_TIM_STMP)
Conjunct: 4.ACCT_NUM = 0.ACCT_NUM
Get Retrieval sequentially of relation 4:SERVICE
0 rows selected
注意: conjunct <agg0> <> 0は、EXISTS文のAggregateの最上部の適切なストラテジ出力に表示されますが、このconjunctは問題の問合せのストラテジ出力では欠落しています。
この問合せでエラーが生じる状況の一因となったのは、主に次の部分です。
この問題は、Oracle Rdbリリース7.2.1で修正されました。
7.1.10 権限を与えられたイメージで外部ルーチンを実行する場合の制限の緩和
Oracle Bug#4595983および4606819
以前のバージョンのOracle Rdbでは、OpenVMSによって現在のプロセスに付与されたよりも多くの権限を持つイメージから外部ルーチンがコールされた場合、その外部ルーチンをアクティブ化することはできませんでした。このセキュリティの防御策により、安全ではない共有可能イメージが本番環境で置き換えられることはありませんでした。
次の例は、Oracle Rdbでレポートされるエラーを示しています。
%RDB-E-EXTFUN_FAIL, external routine failed to compile or execute successfully -RDMS-E-RTNUSENOTALL, routine "GET_ONE" can not be used, too many privileges available
この制限では、SQL/ServicesアプリケーションでBIND ON SERVERを含む外部ルーチンを定義して、権限を与えられた環境以外でルーチンをアクティブ化できるようにする必要がありました。このため、RMU Loadの問題（制約、トリガーおよびAUTOMATIC INSERT列が外部ルーチンをコールする場合）、RMU Unloadの問題（COMPUTED BY列とビューが外部ルーチンをコールする場合）、RMU Verifyの問題（制約を評価する）も発生していました。
Rdbリリース7.2以降では、INSTALL ADD/SHAREコマンドを使用して、外部ルーチンの共有可能なknownイメージを作成できます。この共有可能イメージは、/EXECUTIVEモード・オプションを指定するシステム全体の論理名によってアクティブ化する必要があります。このようなイメージは、権限を与えられたイメージ（RMUなど）が外部ルーチンを実行する場合に信頼できるものとみなされます。
次の例では、FUNCS.OBJという名前の単一モジュールから構築されるFUNCS.EXEと呼ばれる共有イメージに、GET_ONEという名前の関数があると仮定します。データベースには、次の外部関数の定義があります。
SQL> create function get_one() returns integer; cont> external cont> name RETURN_ONE cont> location 'MY_DIR:FUNCS.EXE' cont> language general cont> parameter style general cont> deterministic cont> comment is 'Always returns 1';
PRIV_APPという名前のSQL$PRE/CCアプリケーションがあるとします。このアプリケーションは、追加の権限とともにインストールする必要があり、この中には次のコードが含まれています。
EXEC SQL select get_one() into :result from rdb$database;
printf("%d is the loneliest number\n");
FUNCS.EXEがインストールされず、PRIV_APPがそのインストール時に与えられたよりも低い権限のアカウントから実行される場合、前述のGET_ONE()のコールは失敗し、RTNUSENOTALLエラーが発生します。PRIV_APP内からGET_ONE()を実行できるようにするには、SYS$SHAREで共有可能イメージを探し、次のようなDCLを使用してFUNCS.EXEをインストールします。
$ LINK/SHARE/NOTRACE/EXE=SYS$COMMON:[SYSLIB]FUNCS.EXE FUNCS,SYS$INPUT:/OPTIONS SYMBOL_VECTOR=(RETURN_ONE=PROCEDURE) $ SET FILE /PROTECTION=W:RE SYS$SHARE:FUNCS.EXE $ INSTALL ADD SYS$SHARE:FUNCS.EXE /SHARE $ DEFINE/SYSTEM/EXECUTIVE_MODE MY_DIR SYS$SHARE
インストールした共有可能イメージPRIV_APPを使用すると、SQL文が正常に実行され、関数GET_ONEのコールが成功します。
この問題は、Oracle Rdbリリース7.2で修正されました。
7.1.11 RDMS$_ SymbolsがI64のRDMMSGSHRから欠落している
Oracle Bug#5309253
I64のOracle Rdb 7.2より前のリリースでは、すべてのメッセージ記号がRDMMSGSHR.EXEから誤って省略されていました。
この問題は、Oracle Rdbリリース7.2.1で修正されました。
7.1.12 ページの競合が多い場合のハングまたはループ
ページの競合が多いアプリケーションでは、ページのロックがプロセスで解放されずにハングするか、CPUのループに陥ることがありました。これは、Oracle Rdbリリース7.2のみの問題です。
この問題は、ブロッキングASTのリクエストの管理に使用する内部キューが破損すると発生していました。この状況では、ブロッキングASTが失われるか、キューの処理によって無限ループに陥っていました。
この問題の回避策はありません。
この問題は、Oracle Rdbリリース7.2.1で修正されました。
7.1.13 論理RDMS$ENABLE_INDEX_COLUMN_GROUPが機能しない
Oracle Bug#5614198
Oracle Rdbリリース7.2では、VMSの論理RDMS$ENABLE_INDEX_COLUMN_GROUPを使用して、この機能を無効にできません。
$define RDMS$ENABLE_INDEX_COLUMN_GROUP 0 $SQL$ attach 'file personnel'; show flags; Alias RDB$DBHANDLE: Flags currently set for Oracle Rdb: STRATEGY,PREFIX,WARN_DDL,INDEX_COLUMN_GROUP,MAX_SOLUTION ,MAX_RECURSION(100),DETAIL_LEVEL(1),REFINE_ESTIMATES(127) ,NOBITMAPPED_SCAN
回避するには、コマンドのSQLフラグNOINDEX_COLUMN_GROUPを使用します。
この問題は、Oracle Rdbリリース7.2.1で修正されました。
7.2 SQLエラーの修正
7.2.1 CREATE OUTLINEが複数スキーマのデータベースに対して完全にサポートされない
整形式の問合せの概要は、複数スキーマのデータベース内で必ず正常に機能するとはかぎりません。これは、MODULEタグ、RELATIONタグおよびINDEXタグに対して、STORED NAMEではなくオブジェクト名が使用されるためです。これらの参照が機能するのは、STORED NAMEがスキーマ内の名前と同じ場合のみです。
次の例は、誤って渡された名前が原因でOracle Rdbからレポートされるエラーを示しています。
SQL> create outline S.QO_0 cont> id 'DAE28B9C6DA276E600C68C32AFF46F88' cont> mode 0 cont> as ( cont> query ( cont> -- Select cont> subquery ( cont> TT MODULE S.M2 0 access path sequential cont> ) cont> ) cont> ) cont> compliance optional ; %RDB-E-NO_META_UPDATE, metadata update failed -RDB-E-OBSOLETE_METADA, request references metadata objects that no longer exist -RDMS-E-MODNEXTS, module M2 does not exist in this database SQL> SQL> create outline S.QO cont> stored name is "qoQOqo" cont> id '74263C5C965F88554C9E67744616925C' cont> mode 0 cont> as ( cont> query ( cont> -- For loop cont> subquery ( cont> S.TTABLE 0 access path sequential cont> ) cont> ) cont> ) cont> compliance optional ; %RDB-E-NO_META_UPDATE, metadata update failed -RDB-E-OBSOLETE_METADA, request references metadata objects that no longer exist -RDMS-F-RELNOEXI, relation TTABLE does not exist in this database SQL> SQL> create outline S.QO_2 cont> id '21CA5C0637609367779EB2D7967FF11B' cont> mode 0 cont> as ( cont> query ( cont> -- For loop cont> subquery ( cont> S.T 0 access path index S.T_INDEX cont> ) cont> ) cont> ) cont> compliance optional ; %RDB-E-NO_META_UPDATE, metadata update failed -RDMS-F-INDNOTEXI, index T_INDEX does not exist in this database
また、SQLは、宣言されたローカルの一時（別名スクラッチ）表の名前を正しく処理しませんでした。CREATE OUTLINE構文は、表名のスキーマ（およびカタログ）を許可しますが、モジュール内の一時表の場合、表のサブオブジェクトはモジュール名によって完全に指定されます。SQLは、非限定の名前を制限するようになりました。
これらの問題は、Oracle Rdbリリース7.2.1で修正されました。
7.2.2 コンパイル済ソースのCREATE MODULEからの予期しないINV_TBL_DCLエラー
SQLモジュール言語またはSQLプリコンパイラのソース・ファイルに、DECLARE LOCAL TEMPORARY TABLEを使用するCREATE MODULE文が含まれる場合、複数のエラーがレポートされていました。対話型SQLまたは動的SQLでは、同じCREATE MODULE文が受け入れられていました。
次の例は、これらのエラーを示しています。
declare local temporary table module.T2T (f float)
1
%SQL-E-INV_TBL_DCL, (1) Invalid use of declared local temporary table T2T
select f into :x from module.T2T where module.T2T.f = 0e0;
1
%SQL-F-RELNOTDCL, (1) Table T2T has not been declared in module or environment
この制限は、このリリースのOracle Rdbで解除されました。この禁止事項はCREATE MODULE文に対して誤って適用されたもので、DECLARE LOCAL TEMPORARY TABLEに対する制限は、コンパイル済モジュールのDDL文に適用されません。
この問題は、Oracle Rdbリリース7.2.1で修正されました。
7.2.3 範囲外の数値でSQLSTATE 22003が返されない
Oracle Bug#5208860
表の列にNUMERICが定義されている場合、範囲外の数値を列に挿入すると、返されるSQLCODEは-1、SQLSTATEはRR000になっていました。正しいSQLCODEは-304、SQLSTATEは22003です。
たとえば、次のように定義される表について考えます。
CREATE TABLE NUM1 ( NUM1C1 NUMERIC (3, 2), NUM1C2 NUMERIC (2) );
次の例は、範囲外の値が表に挿入される場合に、古い不正なSQLCODEとSQLSTATEが返される状況を示しています。
SQL> INSERT INTO NUM1 VALUES (-10, 0);
%RDB-E-VALOUTRANGE, value outside the specified precision (3) for column
"NUM1C1"
SQL> show sqlca
SQLCA:
SQLCAID: SQLCA SQLCABC: 128
SQLCODE: -1
SQLERRD: [0]: 2
[1]: 0
[2]: 0
[3]: 0
[4]: 0
[5]: 0
SQLWARN0: 0 SQLWARN1: 0 SQLWARN2: 0
SQLWARN3: 0 SQLWARN4: 0 SQLWARN5: 0
SQLWARN6: 0 SQLWARN7: 0
SQLSTATE: RR000
このINSERTは、現在、次の結果を生成するようになりました。
SQL> INSERT INTO NUM1 VALUES (-10, 0);
%RDB-E-VALOUTRANGE, value outside the specified precision (3) for column
"NUM1C1"
SQL> show sqlca
SQLCA:
SQLCAID: SQLCA SQLCABC: 128
SQLCODE: -304
SQLERRD: [0]: 0
[1]: 0
[2]: 0
[3]: 0
[4]: 0
[5]: 0
SQLWARN0: 0 SQLWARN1: 0 SQLWARN2: 0
SQLWARN3: 0 SQLWARN4: 0 SQLWARN5: 0
SQLWARN6: 0 SQLWARN7: 0
SQLSTATE: 22003
正しいSQLCODE/SQLSTATEを取得する既知の回避策はありません。
この問題は、Oracle Rdbリリース7.2.1で修正されました。
7.2.4 TIME式に追加されたDATEのTIMESTAMPの結果が切り捨てられる
Oracle Rdbでは、TIMESTAMPの結果を生成するために、DATE ANSIとTIMEデータ型の値の追加を許可しています。SQLは、小数秒の精度を、TIMESTAMPの結果ゼロ（0）に誤って割り当てていました。そのため、結果は対話型SQLによって切り捨てられていました。SQLは、TIME値の式による小数秒の精度を、TIMESTAMPの結果に正しく割り当てるようになりました。
次の例は、小数秒が切り捨てられた状態を示しています。
SQL> select date ansi'2006-1-1' + time'12:12:12.12' from rdb$database; 2006-01-01 12:12:12 1 row selected
この問題はOracle Rdbリリース7.2.1で修正されました。SQLは、TIME値の式による小数秒の精度を、TIMESTAMPの結果に正しく割り当てるようになりました。
7.2.5 INSERT ... SELECT文からの予期しない制約の失敗
以前のリリースのOracle Rdbでは、NOT DEFERRABLE制約は、INSERT INTO ... SELECT ... FROM ...文によって挿入される行ごとに評価されていました。この行ごとの評価が原因で、成功すると思われていたINSERT文が失敗していました。SQLのためのANSIおよびISOのデータベース言語規格では、SELECTからのINSERT文はアトミックであり、制約の評価はすべての行の挿入後に行う必要があると定めています。
次の例は、本来は成功するはずの制約が失敗する状況を示しています。
SQL> set dialect 'SQL99'; SQL> SQL> create table TEST_A (a integer); SQL> insert into TEST_A values (1); 1 row inserted SQL> insert into TEST_A values (-1); 1 row inserted SQL> SQL> create table TEST_B cont> (b integer); SQL> SQL> insert into TEST_B select * from TEST_A; 2 rows inserted SQL> SQL> -- add constraint that ensures total is zero SQL> alter table TEST_B cont> add constraint BB cont> check ((select sum (b) from TEST_B) = 0) cont> not deferrable; SQL> SQL> insert into TEST_B select * from TEST_A; %RDB-E-INTEG_FAIL, violation of constraint BB caused operation to fail -RDB-F-ON_DB, on database DISK1:[DATABASES]MF_PERSONNEL.RDB;1 SQL>
この問題はOracle Rdbリリース7.2.1で修正されました。SQL言語のダイアレクトSQL92、SQL99、ORACLE LEVEL1またはORACLE LEVEL2が設定される場合、NOT DEFERRABLE制約の評価は、すべての行がINSERT ... SELECT文に対して挿入された後に実行されるようになりました。
7.2.6 SQL$MOD /LISが不正な/ALIGN値を表示する
Oracle Bug#5350528
SQLモジュール言語コンパイラで作成されたリストには、リストの最後のコマンドラインの概要セクションで使用される/(NO)ALIGN修飾子の不正な値が表示されていました。この修飾子の正しい値はコンパイルで使用されていました。つまり、問題は誤解を招くリストに限定されていました。
たとえば、リストのコマンドラインの概要セクションには次のように表示されます。
Command Line Summary:
/LIST/NOALIGN/MACH TEST$SOURCE:MOD_DATETIME_ADA_4.SQLMOD
/FLOAT=D_FLOAT
/WARNING=(WARNING, DEPRECATED)
/NOFLAG_NONSTANDARD
/CONSTRAINT_MODE=DEFERRED
/NOCONNECT
/INITIALIZE_HANDLES
/NORESTRICT_INVOKER
/ALIGN_RECORDS
...
前述の例では、コマンドラインで/NOALIGNを指定しましたが、レコードが実際に並べられていない場合でも、使用する値として/ALIGN_RECORDSが表示されています。
この問題の回避策はありません。
この問題は、Oracle Rdbリリース7.2.1で修正されました。
7.2.7 FOR UPDATE句がDECLARE CURSORに対して無視される
Oracle Bug#4990176
Oracle Rdbリリース7.1.2以降では、SELECT ... FOR UPDATE句はUPDATE ONLY CURSOR構文と同義のものとしてみなされていました。FOR UPDATE句は、行を最初に読み取るときにさらに強力なロックを示す、SQLの様々なダイアレクトで使用されます。たとえば、シングルトンのSELECT文はFOR UPDATEを使用して行をフェッチし、アプリケーションで続いて更新するためにDBKEY（またはROWID）を保存します。
動的SQLと対話型SQLの場合、FOR UPDATEは行を更新するカーソルを使用する際の重要な機能です。このような環境では、カーソルを更新する目的は、UPDATE ... WHERE CURRENT OF文が現れるまでわかりません。FOR UPDATE句は、問合せを最適化するための重要な情報を提供するだけでなく、更新予定の行をロックします。ただし、DECLARE CURSOR構文は、ORACLE LEVEL1とORACLE LEVEL2を除くすべてのダイアレクトでFOR UPDATE句を無視し、Oracle Rdbによる強力なロックが適用されていませんでした。
この問題はOracle Rdbリリース7.2.1で修正されました。SQLのすべてのダイアレクトで、強力な行ロックのためにFOR UPDATEを受け入れるようになりました。
7.2.8 UPDATE ... WHERE CURRENT OFがIF文内で不正な結果を割り当てる
Oracle Bug#2266270
以前のバージョンのOracle Rdbでは、IF THEN ELSE文またはCASE文などの条件文内で実行されたUPDATE ... WHERE CURRENT OFが、ターゲット列に対して不正な結果を割り当てることがありました。これは、次の状況でのみ発生します。
問題は、共通式の評価がIF文の1つのブランチでのみ行われ、他の条件ブランチに対して不可視であるため発生します。このような他のブランチによって、不正な結果が割り当てられます。
次の例は、このような問題のある問合せの構造を示しています。この例の共通式はA + Bです。
begin
for :x as each row of cursor y
for select id, a, b from t_table
do
if :x.id = 1 then
update t_table set res = a + b + 1 where current of y;
else
update t_table set res = a + b where current of y;
end if;
end for;
end;
この問題は、Oracle Rdbリリース7.2.1で修正されました。
7.2.9 SHOWコマンドで予期しないCOSI-F-BUGCHECKエラーがレポートされる
Oracle Bug#5256548
SHOW INDEX (PARTITION)コマンド、SHOW TABLEコマンドまたはSHOW STORAGE MAPコマンドが失敗し、COSI-F-BUGCHECKエラーが発生することがあります。これは、記憶域が統一形式の領域内にあり、名前の長さが厳密に31オクテットの場合に発生します。エラーはバッファのサイズ設定が小さすぎるために発生します。
次の例は、問題を示しています。
SQL> show table SAMPLE_TABLE; Information for table SAMPLE_TABLE: ... Partition information for index: Partition: (1) SYS_P00150 Storage Area: A_VERY_LONG_STORAGE_AREA_NAME_1 %COSI-F-BUGCHECK, internal consistency failure
この問題は、Oracle Rdbリリース7.2.1で修正されました。
7.2.10 ALTER DOMAINがDEFAULTの変更を表の列に誤って伝播する
Oracle Bug#5203032
以前のリリースのOracle Rdbでは、ALTER DOMAIN ... DROP DEFAULT句は、そのドメインに基づいてすべての列に変更を伝播していました。ほとんどの場合、この動作は適切ですが、列に各自のDEFAULTがあり、それがドメインの列を上書きする場合、このアクションの実行は不要です。
DROP DEFAULTによって列のデフォルト値が失われてしまうという影響があります。ただし、SHOW TABLE (COLUMN)などのコマンドでは古い値が表示されます。
次の例は、この動作を示しています。ここで、ドメインには、NULL値が挿入されないようにするCHECK制約が含まれています。DROP DEFAULTは、DEFAULT式をアクティブにせず、NULLが挿入されます。
SQL> create domain D_TEST
cont> integer
cont> default -99
cont> check (value is not null) not deferrable;
SQL>
SQL> create table T_TEST
cont> (ident_column D_TEST default 1
cont> ,subident_column D_TEST default 0
cont> );
SQL>
SQL> insert into T_TEST default values;
1 row inserted
SQL> select * from T_TEST;
IDENT_COLUMN SUBIDENT_COLUMN
1 0
1 row selected
SQL>
SQL> alter domain D_TEST
cont> drop default;
SQL>
SQL> insert into T_TEST default values;
%RDB-E-NOT_VALID, validation on field IDENT_COLUMN caused operation to fail
SQL>
これを修正するには、ALTER TABLE ... ALTER COLUMN ... DEFAULTを使用して列のデフォルトを再定義します。
この問題はOracle Rdbリリース7.2.1で修正されました。ALTER DOMAINは、列レベルで上書きするDEFAULT句を持つ列にDROP DEFAULTの変更を伝播しなくなりました。
7.2.11 モジュールのグローバル変数が64のDECLARE文に制限される
Oracle Bug#5346544
以前のバージョンのOracle Rdbでは、モジュールのグローバル変数に64を超えるDECLARE文を使用するCREATE MODULE文でバグチェックが発生することがありました。バグチェックの概要は、次のように表示されます。
この問題はメモリーの割当てエラーが原因で発生していましたが、Oracle Rdbリリース7.2.1で修正されました。Oracle Rdbは、実質的に無制限のモジュールのグローバル変数をサポートするようになりました。
7.2.12 無効なエスケープ・シーケンスがSQLSTATEに存在しない
Oracle Bug#5208821
SQLの規格では、無効なエスケープ・シーケンスはコード22025のSQLSTATEでレポートされる必要があります。また、Rdbでは、SQLCODE -1040でこの状況をレポートすることになっています。以前のバージョンのRdbでは、SQLSTATE RR000とSQLCODE -1がかわりにレポートされていました。
たとえば、SQL$PRE/CCプログラムに次の問合せが含まれているとします。
EXEC SQL SELECT COUNT(*) FROM CPBASE
WHERE JUNK1 LIKE 'P%X%%X' ESCAPE 'X';
前述の問合せのエスケープ・シーケンスは、エスケープ文字で終わるため無効です。以前のバージョンでは、動的SQLは、一般的なSQLCODE -1およびSQLSTATE RR000でエラーをレポートしていました。現在は、正しいSQLCODE -1040とSQLSTATE 22025がレポートされるようになりました。
この問題の既知の回避策はありません。
この問題は、Oracle Rdbリリース7.2.1で修正されました。
7.2.13 DROP STORAGE AREA ... CASCADEによって、パーティション索引が完全にドロップされない
Oracle Bug#5620530
以前のリリースのOracle Rdbでは、ALTER DATABASE ... DROP STORAGE AREA ... CASCADE文が、パーティション表から削除された行を参照するパーティション索引を正しく更新しない場合があります。
次の例は、一部の索引ノードが古い行を参照する状態を示しています。これはRMU Verifyで検出されます。
$ DEFINE/USER RDMS$SET_FLAGS -
"TEST_SYSTEM,STOMAP_STATS,INDEX_STAT,INTERNAL,ITEM_LIST"
$ SQL$
alter database
filename SAMPLE_DATABASE
drop storage area AREA_MAIN_07 cascade;
~As: Drop Storage Area "AREA_MAIN_07" Cascade
~As: ...area referenced by index: "INDEX1"
~As: ...area referenced by map: "MAP_TABLE_001"
~As: ...purge index "INDEX2"
~As: ...update the AIP for larea=65 (table)
~As: ...update the AIP for larea=77 (index)
~H Extension (VERIFY CONSTRAINTS) Item List:
0000 (00000) RDB$K_EXT_VFYC_EXCLUDE_UNIQUE
0003 (00003) RDB$K_EXT_VFYC_TABLE_NAME "TABLE_001"
000F (00015) RDB$K_INFO_END
$
$ RMU/VERIFY/INDEX SAMPLE_DATABASE
%RMU-W-CANTFINDLAREA, cannot locate logical area 65 in area inventory page list
%RMU-E-BDLAREADY, error readying logical area with dbid 65
%RMU-I-READYDATA, ready needed for data record at 65:5:0
%RMU-I-BTRNODDBK, Dbkey of B-tree node is 89:3:0
%RMU-W-BTRVFYPRU, B-tree verification pruned at this dbkey
%RMU-I-BTRPARROO, root dbkey of b-tree partition in AREA_INDEX_07 is 89:3:0
$
この問題はOracle Rdbリリース7.2.1で修正されました。この問題を回避するには、影響を受ける索引をドロップして再作成するしかありません。
7.2.14 TRANSLATE ... USING関数を使用する場合の予期しないLENMISMAT警告
Oracle Bug#5629307
以前のバージョンのOracle Rdbでは、TRANSLATE (... USING ...)関数の結果の長さが、SQLによって過度に見積られていました。このため、予期しない不正な警告が発行されることがありました。
次の例は、単純な列でのこの状況を示しています。このコマンドからの警告はありません。
SQL> set character length 'characters';
SQL> create table utest (u5 char(10) character set unicode) ;
SQL> show table (column) utest
Information for table UTEST
Columns for table UTEST:
Column Name Data Type Domain
----------- --------- ------
U5 CHAR(10)
UNICODE 10 Characters, 20 Octets
SQL> insert into utest values ( translate ('A' using rdb$unicode ) ) ;
1 row inserted
SQL> insert into utest values ( translate ('AB' using rdb$unicode ) ) ;
1 row inserted
SQL> insert into utest values ( translate ('ABC' using rdb$unicode ) ) ;
1 row inserted
SQL> insert into utest values ( translate ('ABCD' using rdb$unicode ) ) ;
1 row inserted
SQL> insert into utest values ( translate ('ABCDE' using rdb$unicode ) ) ;
1 row inserted
SQL> insert into utest values ( translate ('ABCDEF' using rdb$unicode ) );
%SQL-W-LENMISMAT, Truncating right hand side string for assignment to column U5
1 row inserted
SQL> insert into utest values ( translate ('ABCDEFG' using rdb$unicode ) );
%SQL-W-LENMISMAT, Truncating right hand side string for assignment to column U5
1 row inserted
SQL> commit;
この問題はOracle Rdbリリース7.2.1で修正されました。SQLは、キャラクタ・セットの最大サイズ文字のオクテット長を使用して見積りを行うようになりました。TRANSLATEが不要なLENMISMAT警告を発行する可能性はほとんどなくなりましたが、SQLはソースの文字列の最終的な翻訳を理解しないことがあります。一部の可変長のキャラクタ・セットの場合、代入が切り捨てられずに成功する場合でも警告が正当化されることがあります。
7.2.15 NULL例外を含むUNIONからの予期しないエラー
Oracle Bug#5645199
以前のバージョンのOracle Rdbでは、最初の区間のselectリストでNULLを指定したUNION演算子が、一般的なデータ型に対して無効なデータ型を取得することがあります。このため、（次の例に示すように）文字化けが発生するか、または実行時にエラーが生成されます。
%RDB-E-ARITH_EXCEPT, truncation of a numeric value at runtime -SQL-F-UNSDTPCVT, Unsupported data type conversion
次の例は、不正な結果を示しています。
SQL> select null from ntab cont> union cont> select d1 from dtab; D1 @L.oGe%.....(x/z(x/z... NULL 2 rows selected
この問題を回避するには、CAST式をNULLでラップして、UNIONの他の区間と互換性のあるデータ型を指定するか、またはNULL式が最後に処理されるようにselect式を逆にします。次の例は、予期される結果を示しています。
SQL> select d1 from dtab cont> union cont> select null from ntab; D1 6-NOV-2006 16:16:52.62 NULL 2 rows selected
この問題は、Oracle Rdbリリース7.2.1で修正されました。
7.2.16 IS NULL式へのデータ型の割当てが一貫していない
Oracle Bug#5484239
以前のリリースのOracle Rdbでは、動的SQLは、隣接する式に基づいてIS NULL句のパラメータ・マーカーにデータ型を割り当てていました。多くの場合、このデータ型は一貫して適用されていませんでした。
次の例は、ユーザーからのデータを求める動的SQLアプリケーションを示しています。? IS NULLでは、整数（4および8を入力）をリクエストする場合と、char(30)の入力をリクエストする場合があります。
Enter statement:
create table CUSTOMERS
(id INTEGER
,ORDERID INTEGER
,NAME CHAR(30)
);
Enter statement:
update CUSTOMERS
set ID=?, ORDERID=?, NAME=?
where (ID= ? OR (ID IS NULL AND ? IS NULL))
and (ORDERID= ? OR (ORDERID IS NULL AND ? IS NULL))
and (NAME= ? OR (NAME IS NULL AND ? IS NULL));
[9 fields]
0/ID/Integer: 12345
1/ORDERID/Integer: 345
2/NAME/Char(30/30): Jones
3/ID/Integer: 12355
4//Integer: 0
5/ORDERID/Integer: 344
6//Char(30/30):
7/NAME/Char(30/30): Lee
8//Integer: 0
Enter statement:
この問題はOracle Rdbリリース7.2.1で修正されました。このリリースでは、SQLは、式? IS NULLのデータ型としてデフォルトの型（VARCHAR(2000)）を割り当てるようになりました。
7.2.17 表のシノニムが問合せの概要で使用されない
以前のリリースのOracle Rdbでは、CREATE SYNONYMまたはRENAME TABLEを使用して表に作成されたシノニムが、実行時に問合せの概要で認識されませんでした。STRATEGYフラグがSET FLAGS文で指定された場合、次のようなメッセージがレポートされていました。
SQL> select a from t000 order by a; ~S: Outline "QO_A" used ~S: Outline/query mismatch; assuming T000 0 renamed to TABLE_000 0 Tables: 0 = TABLE_000 Index only retrieval of relation 0:TABLE_000 Index name T000_INDEX [0:0] 0 rows selected SQL>
この問題はOracle Rdbリリース7.2.1で修正されました。Oracle Rdbは、結果のターゲット表を、問合せの概要で参照される名前と比較するだけではなく、問合せの表の名前と比較するようになりました。
7.2.18 文字列の連結時の予期しないUNSDTPCVTエラー
Oracle Bug#5584169
長さゼロの文字列を別の文字列と連結する場合、SQLはUNSDTPCVTエラーを予期せずレポートします。これは、問合せにOracleセマンティクスを適用しようとするために発生します。このエラーは、ダイアレクトがORACLE LEVEL1またはORACLE LEVEL2に設定されている場合のみ発生します。
次の例は、この問題が原因で失敗する問合せを示しています。
SQL> set dialect 'oracle level1'; SQL> select 'test'||'' from rdb$database; %SQL-F-UNSDTPCVT, Unsupported data type conversion SQL>
この問題は、Oracle Rdbリリース7.2.1で修正されました。
7.2.19 LIKEパターンのパラメータのサイズが小さすぎる
Oracle Bug#4179408
動的SQLが、LIKEパターンにパラメータ・マーカーを使用する問合せを処理している場合、パラメータの長さがソースの文字列の長さと同じであると仮定されます。ただし、%123%などのパターンは、CHAR(4)列に対する一致で使用するには完全に有効ですが（先頭の123または最後の123が一致）、想定されるデータ型により、パターンがOracle Rdbで切り捨てられるため、すべての値が一致するとはかぎりません。
次の例は、古い動作を示しています。3つのすべての行が問合せで一致する必要があります。
$ run test$tools:tester
Enter statement:
attach 'filename sql$database';
Enter statement:
create table LL (val char(4));
Enter statement:
insert into LL (val) values ('1234');
Enter statement:
insert into LL (val) values ('1235');
Enter statement:
insert into LL (val) values ('0123');
Enter statement:
select * from LL where val like ?;
[1 fields]
0/VAL/Varchar(4/8): %123%
Enter statement:
次の例は、修正された動作と、パラメータ・マーカーのデータ型の長さが増加したことを示しています。
$ run test$tools:tester
Enter statement:
attach 'filename sql$database';
Enter statement:
create table LL (val char(4));
Enter statement:
insert into LL (val) values ('1234');
Enter statement:
insert into LL (val) values ('1235');
Enter statement:
insert into LL (val) values ('0123');
Enter statement:
select * from LL where val like ?;
[1 fields]
0/VAL/Varchar(8/12): %123%
0/VAL: 1234
0/VAL: 1235
0/VAL: 0123
Enter statement:
この問題はOracle Rdbリリース7.2.1で修正されました。SQLは、likeパターンのサイズがソースの文字列の2倍であると仮定するか、またはESCAPE句がある場合は、サイズを3倍に仮定します。これはほとんどのパターン文字列にとって余裕があります。このサイズ設定でも小さすぎる場合、CAST(? AS VARCHAR(n))を使用して、パラメータのサイズをより正確な長さに設定します。
7.3 RMUエラーの修正
7.3.1 /EDIT_FILENAMEが含まれる場合、RMU/BACKUP/AFTERがデフォルトのファイル名を無視する
Oracle Bug#5464971
RMU/BACKUP/AFTERコマンドが発行され、出力ファイル名が指定されず、/EDIT_FILENAME修飾子が含まれている場合、バックアップ・ファイルの作成時にデフォルトのジャーナル・ファイル名が使用されませんでした。次に例を示します。
$ RMU/BACKUP/AFTER/LOG -
/EDIT_STRING=("_", VNO, "_", YEAR,MONTH,DAY_OF_MONTH) -
MF_PERSONNEL .AIJ
.
.
.
%RMU-I-LOGCREBCK, created backup file DEV:[DIR]_0_20060829.AIJ;1
前述の例では、ジャーナル・ファイル名はJ1であり、バックアップのファイル名の接頭辞としてこの名前が使用されるはずでしたが、かわりに編集文字列のコンテンツのみがファイル名の構成に使用されました。
この問題を回避するには、バックアップ・コマンドでバックアップの出力ファイル名を明示的に指定します。
この問題は、Oracle Rdbリリース7.2.1で修正されました。
7.3.2 RMU COLLECT OPTIMIZERの作業負荷統計のメモリー破損
Oracle Bug#5436532
RMU/COLLECT OPTIMIZERコマンドを使用してRdbデータベースの作業負荷統計を収集する場合、システムのアクセス違反が発生することがありました。この問題は、メモリー破損の問題が原因で発生していました。このメモリー破損は、多くの行がある表の作業負荷統計を計算するために使用するビットマップ表以外にビットが設定されている場合に発生することがありました。この問題は修正され、ビットマップ表の範囲外でビットが設定されることはなくなりました。この問題は、Oracle Rdb RMUリリース7.2でのみ発生します。
次の例は、作業負荷統計が収集される場合に発生するシステムのアクセス違反を示しています。
$ RMU/COLLECT OPTIMIZER/STATISTICS=(WORKLOAD) test_datatbase %SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual address=000000000000000C, PC=0000000000501D2C, PS=0000001B %RMU-F-FATALOSI, Fatal error from the Operating System Interface. %RMU-I-BUGCHKDMP, generating bugcheck dump file device:[directory]RMUBUGCHK.DMP
この問題を部分的に回避するには、最初にRMU/COLLECT OPTIMIZERコマンドで/TABLE修飾子を使用して、どの表がこの問題を引き起こしているのかを確認し、次に/EXCLUDE_TABLES修飾子を使用して該当する表の作業負荷統計が収集されないようにします。
$ RMU/COLLECT OPTIMIZER/STATISTICS=(WORKLOAD)- /EXCLUDE_TABLE=problem_table test_database $
この問題は、Oracle Rdbリリース7.2.1で修正されました。
7.3.3 RMU VERIFYのメモリー破損
Oracle Bug#5349580および5276155
データベースが破損したために、データベースの検証を行う構造にメモリーを割り当てるためのカウンタが小さすぎる場合がありました。破損によってシステム表の問合せが整合性のないデータを返す場合、この問題が発生することがあります。この問題の原因の1つが、統一領域の領域ビット・マップ・ページの破損です。
表、索引、セグメント化された文字列などのエントリを検証構造に入力するために、その他の問合せがデータベースに対して実行された場合、データベースの各種オブジェクトの検証構造に入力されたエントリが、その構造に割り当てられたメモリーを超える可能性があります。このため、メモリーが破損し、システム・エラーとRMU/VERIFYのバグチェックが発生することがあります。
データベースの破損が原因でシステム表から整合性のないデータが返される場合、検証によって修正することはできません。ただし、検証構造に割り当てられたメモリー・サイズの超過を防ぐためのチェックが行われるようになり、システム表へのアクセス問題があるためすべてのデータベース・オブジェクトが検証されるわけではないが、検証が続行されることを示す警告メッセージが出力されるようになりました。データベースへの問合せが信頼できるものではなく、この非一貫性が発生した時点でその原因を検証の開始時に通知する方法がないため、問題を示すことができるように検証を続行する機会が与えられます。
次の例は、データベースのRMU/VERIFYで、検証構造をロードするときにメモリー超過の原因となった破損が生じた状況を示しています。これにより、メモリーが破損し、システムの予約オペランド・フォルトが繰り返されます。検証を続行しようとしますが、検証を続けるために必要な構造をロードできない場合、検証は中断され、予期しないシステム・エラーのためにバグチェックのダンプが出力されます。
$ RMU/VERIFY/ALL device:[directory]database.rdb %RMU-I-BGNROOVER, beginning root verification %RMU-I-ENDROOVER, completed root verification %SYSTEM-W-ROPRAND, reserved operand fault at PC=000000000032E178, PS=0000001B %RMU-E-ERRRDBIND, error accessing RDB$INDICES relation %RMU-I-PARTLVFY, continuing partial verification %RMU-F-ABORTVER, fatal error encountered; aborting verification %SYSTEM-F-ROPRAND, reserved operand fault at PC=000000000032E178, PS=0000001B %RMU-F-FATALOSI, Fatal error from the Operating System Interface. %RMU-I-BUGCHKDMP, generating bugcheck dump file device:[directory]RMUBUGCHK.DMP; %RMU-F-FTL_VER, Fatal error for VERIFY operation at 21-JUN-2006 08:03:57.63
次の例は、修正された動作を示しています。メモリー超過は回避され、データベース・オブジェクトの特定の型に関して、その型のすべてのオブジェクトを完全に検証するために情報をロードする際の問題があることを示す警告メッセージが出力されます。検証によって返される診断が問題の特定に役立つように検証は続行されます。領域ビット・マップ・ページが破損している場合、RMU/REPAIRを実行して破損を修正できます。
$ RMU/VERIFY/ALL device:[directory]database.rdb %RMU-W-NOTALLDAT, Not all data for database TABLES can be loaded from system tables - verify continuing. %RMU-W-ABMBITERR, inconsistency between spam page 9475371 and bit 918 in area bitmap in larea 1 page 6 %RMU-W-ABMBITERR, inconsistency between spam page 9490631 and bit 932 in area bitmap in larea 1 page 6 %RMU-W-ABMBITERR, inconsistency between spam page 9491721 and bit 933 in area bitmap in larea 1 page 6 %RMU-E-BADABMPAG, error verifying ABM pages $ RMU/REPAIR/ABM/AREA=UNIFORM_AREA device:[directory]DATABASE.RDB %RMU-I-FULBACREQ, A full backup of this database should be performed after RMU REPAIR $ RMU/VERIFY/ALL device:[directory]DATABASE.RDB
この問題は、Oracle Rdbリリース7.2.1で修正されました。
7.3.4 接尾辞の先行文字がデータに表示される場合の予期しないDLMNOTFND
Oracle Bug#4245634
以前のバージョンのOracle Rdbでは、SUFFIXの先行文字がデータに含まれる場合、RMU Loadがエラーをレポートしていました。これは、SUFFIXオプションが指定されたFORMAT=DELIMITEDで発生していました。たとえば、次のサンプル・データでは、名前SMITH, ANDREWの後に/が続きます。/はRMU Loadのコマンドラインで定義されるSUFFIXの先行文字でもあります。
/:/key3/:/,/:/SMITH, ANDREW//:/,/:/Z/:/&END&
これにより、次の例に示すようにRMU Loadが失敗します。
$ RMU/LOAD/RECORD_DEFINITION=(-
FILE=NAMES_TABLE.RRD,-
FORMAT=DELIMITED_TEXT, -
PREFIX="/:/",-
SUFFIX="/:/",-
TERMINATOR="&END&",-
NULL="")-
LOAD_TEST NAMES_TABLE NAMES.DAT
%RMU-F-DLMNOTFND, Separator (,) not found for column 2 of row 1 in the input.
%RMU-I-DATRECREAD, 3 data records read from input file.
%RMU-I-DATRECSTO, 0 data records stored.
%RMU-I-DATRECREJ, 0 data records written to exception file.
%RMU-F-FTL_LOAD, Fatal error for LOAD operation at 14-JUL-2006 12:49:18.79
この問題は、Oracle Rdbリリース7.2.1で修正されました。RMU Loadは、正しいSUFFIXに対して前もってスキャンを正しく実行するようになりました。
7.3.5 NULL文字列が列データで表示される場合の予期しないRMU Loadの失敗
Oracle Bug#4865227
以前のリリースのOracle Rdbでは、RMU Loadコマンドは、列データ内でNULL文字列を検出すると失敗していました。これはFORM=DELIMITEDで、NULLオプションをRECORD_DEFINITION修飾子に指定すると発生します。次の例は、単純なケースを示しています。
$ RMU/UNLOAD/RECORD=(FILE=T1.RRD,FORMAT=DELIMITED,-
SEPARATOR="|",PREFIX="",SUFFIX="",NULL="***") -
SAMPLE_DB T1 T1.DAT
%RMU-I-DATRECUNL, 1 data records unloaded.
$ TYPE T1.DAT
abcde|N***N |z
$ RMU/LOAD/RECORD=(FILE=T1.RRD,FORMAT=DELIMITED,-
SEPARATOR="|",PREFIX="",SUFFIX="",NULL="***") -
SAMPLE_DB T1 T1.DAT
DEFINE FIELD C1 DATATYPE IS TEXT SIZE IS 5.
DEFINE FIELD C2 DATATYPE IS TEXT SIZE IS 10.
DEFINE FIELD C3 DATATYPE IS TEXT SIZE IS 1.
DEFINE RECORD T1.
C1 .
C2 .
C3 .
END T1 RECORD.
%RMU-F-UNEXPDELIM, Unexpected delimiter encountered (***) in row 1 of input
%RMU-I-DATRECREAD, 1 data records read from input file.
%RMU-I-DATRECSTO, 0 data records stored.
%RMU-F-FTL_LOAD, Fatal error for LOAD operation at 14-JUL-2006 00:57:40.42
RMU Loadは、データが不明瞭でなければ、エラーをレポートすることはありません。
この問題は、Oracle Rdbリリース7.2.1で修正されました。
7.3.6 RMU Loadで予期しないINVALID_BLRエラーがレポートされる
Oracle Bug#4040175
以前のリリースのOracle Rdbでは、RMU Loadコマンドは、データ型PACKED DECIMAL、UNSIGNED NUMERICおよびLEFT SIGNED NUMERICを含むレコード定義ファイルを受け入れていました。このため、次の例のようなエラーが発生していました。
$ rmu/load abc temp_table /rec=(format=text,file=z.rrd) z.dat %RDB-E-INVALID_BLR, request BLR is incorrect at offset 8 %RMU-I-DATRECREAD, 0 data records read from input file. %RMU-I-DATRECSTO, 0 data records stored. %RMU-F-FTL_LOAD, Fatal error for LOAD operation at 13-JUL-2006 20:50:23.81
これらの型は、Oracle Rdbサーバーでサポートされておらず、RMU Loadで許可されません。このリリースでは、これらの型の使用が正しく診断されるようになりました。
%RMU-F-UNSSUPDAT, Unsupported data type: 16 %RMU-I-DATRECSTO, 0 data records stored. %RMU-F-FTL_LOAD, Fatal error for LOAD operation at 13-JUL-2006 20:50:40.17
この問題は、Oracle Rdbリリース7.2.1で修正されました。
7.3.7 RMU /COPY、/MOVEおよび/RESTOREでABMページが破損する
Oracle Bug#5276155
RMU COPY、MOVEおよびRESTOREで、論理領域に対して複数のABMビットマップ・ページの連鎖があり、連鎖の以前のABMページにビットが設定されておらず、連鎖の後続のABMページにビットが設定されている場合、統一記憶域の領域ビット・マップ・ページが誤って設定されることがあります。すべてのSPAM PAGESを1つのABMページのビットマップで表すことができるとはかぎらず、論理領域ごとにSPAMページを表すには複数のABMページ（それぞれにビットマップがある）が必要とされるために、統一記憶域に十分なSPAMページがある場合にこの問題が発生することがあります。論理領域のいずれかのABMページ（だたし最後ではない）にビットが設定されていない場合、RMU MOVE、COPYまたはRESTOREの前にビットが設定されていたページの後のABMページでは、RMU COPY、MOVEまたはRESTOREの後にすべてのビットが消去されていました。ビットが論理領域のABMページに設定されていない場合、Rdbは、そのSPAMページで制御されるデータベースのデータ・ページを取得しません。これは、説明したケースで、統一記憶域の場合にのみ発生する点に注意してください。この問題はRMU/VERIFYで検出され、RMU/REPAIR/ABM/AREASで修正できます。この問題は修正され、ABMビットマップのビットは正しく設定されるようになりました。
次の例は、データベースのRMU/COPYによってこの問題が生じる状況を示しています。問題はRMU/VERIFYで検出され、RMU/REPAIRで修正されます。
$ RMU/COPY/NOLOG/DIRECTORY=device:[directory] DATABASE.RDB $ RMU/VERIFY/AREAS/LAREAS device:[directory]DATABASE.RDB %RMU-W-ABMBITERR, inconsistency between spam page 8650241 and bit 161 in area bitmap in larea 113 page 8650819 %RMU-W-ABMBITERR, inconsistency between spam page 8651331 and bit 162 in area bitmap in larea 113 page 8650819 %RMU-W-ABMBITERR, inconsistency between spam page 8652421 and bit 163 in area bitmap in larea 113 page 8650819 %RMU-W-ABMBITERR, inconsistency between spam page 8653511 and bit 164 in area bitmap in larea 113 page 8650819 %RMU-W-ABMBITERR, inconsistency between spam page 8654601 and bit 165 in area bitmap in larea 113 page 8650819 %RMU-W-ABMBITERR, inconsistency between spam page 8655691 and bit 166 in area bitmap in larea 113 page 8650819 %RMU-W-ABMBITERR, inconsistency between spam page 8656781 and bit 167 in area bitmap in larea 113 page 8650819 %RMU-E-BADABMPAG, error verifying ABM pages $ RMU/REPAIR/ABM/AREA=UNIFORM_AREA device:[directory]DATABASE.RDB %RMU-I-FULBACREQ, A full backup of this database should be performed after RMU REPAIR $ RMU/VERIFY/AREAS/LAREAS device:[directory]DATABASE.RDB $
この問題は、Oracle Rdbリリース7.2.1で修正されました。
7.3.8 区切り形式またはテキスト形式が使用される場合、RMU Unloadで実際のデータが切り捨てられる
Oracle Bug#4297346
以前のリリースのOracle Rdbでは、実際の列のRMU Unloadでデータが切り捨てられることが稀にあります。
LEAST、GREATEST、CASE、NULLIF、COALESCE、NVL、NVL2またはDECODEの各式を使用して結果を計算する表のCOMPUTED BYまたはビュー列が計算の場合に発生します。この問題が発生するには、計算にREAL（浮動小数F）になる1つの式と、SMALLINTになる別の式が含まれている必要があります。ただし、Oracle Rdbは、値を文字列値に変換する前にDOUBLE PRECISION（浮動小数G）に結果を促していました。値がRMU Unloadに配信されると、ターゲット文字列（REAL文字列値に正しくサイズ設定されている）は、結果として生成されるDOUBLE PRECISION文字列に対して小さすぎるため、結果が切り捨てられていました。
この問題を回避するには、COMPUTED BYまたはビュー列の定義に明示的なCAST(... AS REAL)を含めます。
次の出力は、列の切捨てを示しています。
003537||| 9.7500000E+01|||975||| 9.750000000000
想定される結果には、指数が含まれます。
003537||| 9.7500000E+01|||975||| 9.750000000000000E+001
この問題は、Oracle Rdbリリース7.2.1で修正されました。
7.3.9 RMU Extractで複数スキーマのデータベースが完全にサポートされない
Oracle Bug#5558122、5568079および5568040
以前のリリースのOracle Rdbでは、複数スキーマのデータベースに対してRMU Extractのサポートが完全ではありませんでした。このリリースでは、RMU Extractに関して次の部分の修正が行われました。
これらの問題は、Oracle Rdbリリース7.2.1で修正されました。
7.3.10 RMU Extract Item=Protectionsで保護が一貫して抽出されない
Oracle Bug#5225643
以前のバージョンのOracle Rdbでは、表に対するRMU Extract Item=Protectionsの出力では、表に対して未使用のOPERATOR権限が含まれるか、またはモジュール、関数またはプロシージャに対するREFERENCES権限が省略されることがあります。これらのエラーに害はありませんが、2番目のエラーが発生すると、生成スクリプトで作成された、シノニムの対象となるルーチンが実行されない可能性があります。
この問題は、Oracle Rdbリリース7.2.1で修正されました。RMUは、すべてのオブジェクトの保護を一貫して出力するようになりました。
7.3.11 統計が無効の場合、RMU/CONVERTのPIO$LOCK_PAGEでバグチェックが発生する
RMU/CONVERTコマンドの実行中に統計が無効の場合、RMUユーティリティでバグチェックが発生し、次のようなスタックが表示されていました。
***** Exception at 0000000000719708 : RMU72\PIO$DEMOTE_PAGE + 000001A8 %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=0000000000000000, PC=0000000000719708, PS=0000001B Saved PC = 0000000000722E14 : RMU72\PIOUTL$EMPTY_ONE_BUFFER + 000002B4 Saved PC = 000000000071D654 : RMU72\PIOFETCH$WITHIN_DB_HNDLR + 00000134 Saved PC = FFFFFFFF81104EC8 : Image LIBOTS + 00008EC8 Saved PC = FFFFFFFF800A693C : symbol not found ***** Exception at 000000000071C020 : RMU72\PIO$LOCK_PAGE + 00000320 Saved PC = 000000000071E114 : RMU72\PIOFETCH$WITHIN_DB + 00000924 Saved PC = 000000000071B444 : RMU72\PIOFETCH$FETCH + 000002E4 Saved PC = 000000000071A4E4 : RMU72\PIO$FETCH + 000008F4
以前のバージョンのOracle Rdbで行われたバックアップをリストアすることにより暗黙的な変換が行われる場合も、同じ問題が発生することがありました。
この問題は、次のコマンドを使用して明示することができます。
$ @SYS$LIBRARY:RDB$SETVER 71 Current PROCESS Oracle Rdb environment is version V7.1-441 (MULTIVERSION) Current PROCESS SQL environment is version V7.1-441 (MULTIVERSION) Current PROCESS Rdb/Dispatch environment is version V7.1-441 (MULTIVERSION) $ MCR SQL$71 SQL> CREATE DATABASE FILENAME TEST; SQL> EXIT $ $ DEFINE RDM$BIND_STATS_ENABLED 0 $ $ @SYS$LIBRARY:RDB$SETVER 72 Current PROCESS Oracle Rdb environment is version V7.2-010 (MULTIVERSION) Current PROCESS SQL environment is version V7.2-010 (MULTIVERSION) Current PROCESS Rdb/Dispatch environment is version V7.2-010 (MULTIVERSION) $ RMU/CONVERT/NOCONFIRM TEST %RMU-I-RMUTXT_000, Executing RMU for Oracle Rdb V7.2-010 %RMU-I-LOGCONVRT, database root converted to current structure level %RMU-I-BUGCHKDMP, generating bugcheck dump file dev:[dir]RMUBUGCHK.DMP;
この問題を回避するには、RMU/CONVERTコマンドの実行前にRDM$BIND_STATS_ENABLED論理の割当てを解除します。
この問題は、Oracle Rdbリリース7.2.1で修正されました。
7.3.12 RMU/RESTORE/AREA/ONLINEが、読取り保護のRDB$SYSTEMを不要にロックする
Oracle Bug#5203722
RMU/RESTORE/AREA/ONLINEが、読取り保護モードのRDB$SYSTEM領域をロックしていました。これは、RDB$SYSTEMがリストアする記憶域ではない場合も同様です。領域インベントリ・ページが一貫していない場合、これを読み取って場合によっては変更するために、RMU/RESTORE/AREA/ONLINEはシステム領域にアクセスする必要があります。領域インベントリ・ページはシステム領域にあります。ただし、参照するAIPページがない混合形式の記憶域のみがリストアされる場合でも、RMUはシステム領域を不要にロックしていました。
領域ごとにオンラインでリストアする場合、システム領域のAIPページのロックとページへのアクセスは変更されました。リストアする領域すべてが混合形式の場合、システム領域がリストアする領域でなければ、そのシステム領域はロックされません。統一領域がオンラインでリストアされる場合、システム領域は、読取り保護モードではなく同時書込みモードになり、リストア中の同時実行性が向上します。統一領域では、領域ビット・マップ・ページと領域管理ページを再構築するためにAIPページにアクセスして、これらのページが一貫していないときは、場合によって変更する必要があります。
リストア・コマンドで指定する、実際にリストアする領域（システム領域など）は、排他更新のために引き続きロックされます。
次の例は、これらの変更で影響を受ける、領域ごとのオンライン・リストア・コマンドを示しています。リストアが混合領域のみを参照する場合、システム領域はロックされません。リストアが統一領域を参照する場合、以前はシステム領域の読取り保護がロックされていましたが、システム領域の同時書込みになりました。システム領域自体がリストアされる場合、システム領域は、排他更新のために引き続きロックされます。
$ RMU/RESTORE/ONLINE/AREA/NOLOG/DIR=DEVICE:[DIRECTORY] -
DEVICE:[DIRECTORY]DATABASE.RBF MIXED_1_AREA, MIXED_2_AREA
$ RMU/RESTORE/ONLINE/AREA/NOLOG/DIR=DEVICE:[DIRECTORY] -
DEVICE:[DIRECTORY]DATABASE.RBF MIXED_1_AREA, MIXED_2_AREA, -
UNIF_1_AREA, UNIF_2_AREA
$ RMU/RESTORE/ONLINE/AREA/NOLOG/DIR=DEVICE:[DIRECTORY] -
DEVICE:[DIRECTORY]DATABASE.RBF MIXED_1_AREA, MIXED_2_AREA,-
UNIF_1_AREA, UNIF_2_AREA, RDB$SYSTEM
この問題は、Oracle Rdbリリース7.2.1で修正されました。
7.3.13 データベースの記憶域の数が非常に多く、/BLOCK_SIZEに指定した値が小さい場合、RMU /BACKUPが失敗する
Oracle Bug#5376038
以前は、記憶域の数が非常に多く、/BLOCK_SIZEに指定された値が小さいデータベースでは、RMU /BACKUPが失敗することがありました。内部バッファが、出力ファイルのブロック・サイズをオーバーフローし、リカバリ時に読み取れないレコード、またはメモリーを破損させるレコードを書き込み、バックアップ時にACCVIOのバグチェックが発生します。一部のバージョンでは、バッファのオーバーフローが実行時に検出され、RMU /BACKUP操作が終了して、次のようなバグチェックのダンプが発生していました。
$ RMU/BACKUP FOO.RDB FOO.RBF /BLOCK_SIZE=2048 ***** Exception at 003E95F0 : RMUBCK$BACKUP_SUMMARY + 00000270 %COSI-F-BUGCHECK, internal consistency failure Saved PC = 003E8584 : RMUBCK$BF_BACKUP_THREAD + 00000494 Saved PC = 008302FC : RMUIO$TERMINATE_THREAD + 00000040 Saved PC = 008304B8 : RMUIO$FIREWALL + 00000040 Saved PC = 00830478 : RMUIO$FIREWALL + 00000000 Saved PC = 003A18E4 : RMU_DISPATCH + 00000434 Saved PC = 003A1008 : RMU_STARTUP + 000004E8 Saved PC = 001E002C : RMU$MAIN + 0000002C
この問題はOracle Rdbリリース7.2.1で修正されました。RMU /BACKUPは、データベースの記憶域の数とページ・サイズに適応するように、バックアップのブロック・サイズを必要に応じて適切に調整するようになりました。
7.3.14 RMU ExtractがBITSTRING関数でBAD_CODEエラーをレポートする
以前のリリースのOracle Rdbでは、RMU Extractが、CASE、ABS、COALESCE、DECODE、NULLIF、NVLまたはNVL2の関数内にネストされたBITSTRING関数を抽出しようとすると、BAD_CODEエラーを生成していました。次の例は、レポートされたエラーを示しています。
%RMU-F-BLRINV, internal error - BLR string 83 for . is invalid -RDMS-E-BAD_CODE, corruption in the query string %RMU-F-FTL_RMU, Fatal error for RMU operation at 10-JUL-2006 03:27:48.68
この問題は、Oracle Rdbリリース7.2.1で修正されました。
7.3.15 UNIONとGROUP BY句を含むビューで不正なSQL構文が生成される
Oracle Bug#5666305および5672460
以前のリリースでは、RMU Extractは、UNIONにGROUP BY句を含むブランチがある場合、select値のリストの後にアスタリスク*を付けてビューの定義を誤って抽出していました。
次の例は元のビューの定義を示しています。
SQL> create view SAMPLE_VIEW (a, b, c) cont> as cont> select last_name, first_name, middle_initial cont> from candidates cont> group by last_name, first_name, middle_initial cont> union cont> select last_name, first_name, middle_initial cont> from employees cont> group by last_name, first_name, middle_initial cont> ;
これは、RMU Extractからの出力で不正な構文を示しています。
.
.
.
create view SAMPLE_VIEW
(A,
B,
C) as
select C3.LAST_NAME, C3.FIRST_NAME, C3.MIDDLE_INITIAL
* from CANDIDATES C3
group by C3.LAST_NAME, C3.FIRST_NAME, C3.MIDDLE_INITIAL
union
select C5.LAST_NAME, C5.FIRST_NAME, C5.MIDDLE_INITIAL
* from EMPLOYEES C5
group by C5.LAST_NAME, C5.FIRST_NAME, C5.MIDDLE_INITIAL;
.
.
.
この問題は、Oracle Rdbリリース7.2.1で修正されました。
7.4 LogMinerエラーの修正
7.4.1 RMU/UNLOAD/AFTER_JOURNALの不正なNULLビットの設定
Oracle Bug#5256671
以前のリリースのOracle Rdbでは、データベースの表定義の変更や構造によって、LogMinerがNULL列の情報を不適切に処理することがありました。
次に、不正なNULLの処理の一因と考えられる例を示します。抽出されたレコードでは、不正な列がNULLで示されています。
$ DEFINE /NOLOG SQL$DATABASE FOO
$ SQL$
CREATE DATA FILE SQL$DATABASE
NUMBER OF BUFFERS 100 NUMBER OF CLUSTER NODES 1;
DISCONNECT ALL;
ALTER DATA FILE SQL$DATABASE
JOURNAL ENA (FAST COMMIT ENA) ADD JOURNAL J1 FILE J1;
CREATE TABLE T1 (
I1 INT,I2 INT,I3 INT,I4 INT,I5 INT,I6 INT,
I7 INT,I8 INT,I9 INT,I10 INT,I11 INT,I12 INT);
CREATE STORAGE MAP M1 FOR T1 DISABLE COMPRESSION;
COMMIT;
ALTER TABLE T1 DROP COLUMN I5;
COMMIT;
ALTER TABLE T1
ADD COLUMN I13 INT
ADD COLUMN I14 INT
ADD COLUMN I15 INT
ADD COLUMN I16 INT
ADD COLUMN I17 INT;
COMMIT;
ALTER TABLE T1 DROP COLUMN I17;
ALTER TABLE T1 ADD COLUMN I18 INT;
COMMIT;
ALTER TABLE T1 DROP COLUMN I18;
COMMIT;
DISCONNECT ALL;
EXIT;
$ RMU/SET LOGMINER/ENABLE/NOLOG SQL$DATABASE
$ RMU/BACKUP/AFTER/NOLOG SQL$DATABASE NLA0:BAR
$ RMU/BACKUP/NOLOG/NOCRC/NOCHECKSUM SQL$DATABASE NLA0:BAR
$ SQL$
INSERT INTO T1 VALUES (1,2,3,4,6,7,8,9,10,11,12,13,14,15,16);
INSERT INTO T1 VALUES (NULL,2,3,4,6,7,8,9,10,11,12,13,14,15,16);
INSERT INTO T1 VALUES (1,NULL,3,4,6,7,8,9,10,11,12,13,14,15,16);
INSERT INTO T1 VALUES (1,2,NULL,4,6,7,8,9,10,11,12,13,14,15,16);
INSERT INTO T1 VALUES (1,2,3,NULL,6,7,8,9,10,11,12,13,14,15,16);
INSERT INTO T1 VALUES (1,2,3,4,NULL,7,8,9,10,11,12,13,14,15,16);
INSERT INTO T1 VALUES (1,2,3,4,6,NULL,8,9,10,11,12,13,14,15,16);
INSERT INTO T1 VALUES (1,2,3,4,6,7,NULL,9,10,11,12,13,14,15,16);
INSERT INTO T1 VALUES (1,2,3,4,6,7,8,NULL,10,11,12,13,14,15,16);
INSERT INTO T1 VALUES (1,2,3,4,6,7,8,9,NULL,11,12,13,14,15,16);
INSERT INTO T1 VALUES (1,2,3,4,6,7,8,9,10,NULL,12,13,14,15,16);
INSERT INTO T1 VALUES (1,2,3,4,6,7,8,9,10,11,NULL,13,14,15,16);
INSERT INTO T1 VALUES (1,2,3,4,6,7,8,9,10,11,12,NULL,14,15,16);
INSERT INTO T1 VALUES (1,2,3,4,6,7,8,9,10,11,12,13,NULL,15,16);
INSERT INTO T1 VALUES (1,2,3,4,6,7,8,9,10,11,12,13,14,NULL,16);
INSERT INTO T1 VALUES (1,2,3,4,6,7,8,9,10,11,12,13,14,15,NULL);
COMMIT;
$ RMU/BACKUP/AFTER/NOLOG SQL$DATABASE B1
$ RMU/UNLOAD/AFTER/NOLOG/FORMAT=DUMP SQL$DATABASE B1 -
/TABLE=(NAME=T1,OUTPUT=T1.DAT)
$ SEARCH T1.DAT NULL
I13 : NULL
I9 : NULL
I13 : NULL
I10 : NULL
I13 : NULL
I11 : NULL
I13 : NULL
I12 : NULL
I13 : NULL
I13 : NULL
I14 : NULL
I13 : NULL
I15 : NULL
I13 : NULL
I16 : NULL
I13 : NULL
I13 : NULL
I13 : NULL
I13 : NULL
I13 : NULL
I13 : NULL
I13 : NULL
I13 : NULL
$ EXIT
この問題はOracle Rdbリリース7.2.1で修正されました。LogMinerは、表定義に基づいて内部のNULL情報の構造の長さを正確に追跡するようになりました。
7.4.2 テキスト形式のRMU /UNLOAD /AFTER_JOURNALのAERCP_LENフィールドが正しくない
Oracle Bug#5617814
以前は、TEXTまたはDELIMITED_TEXTの出力形式を使用する場合、コミット・レコード・コンテンツのAERCP_LENフィールドが正しくありませんでした。
たとえば、区切りテキスト形式を使用する場合、次の情報がコミット・レコードに返されます。
"C",
"",
.
.
.
"16",
"7169",
"00000000-0000-0000-0000-000000000000",
"000000000000038F000000000000038F000000160000000000001C01"
ここでは、フィールドの値16がRM_TID_LENで、値7169が正しくないAERCP_LENフィールドです。
この問題は、Oracle Rdbリリース7.2.1で修正されました。AERCP_LENフィールドの正しい値が返されるようになりました。AERCP_LENの値は28です。これはAERCP構造のフォーマットされていないバイナリの長さを表します。テキスト形式フィールドの長さではありません。
7.5 行キャッシュ・エラーの修正
7.5.1 ジャーナル化された行キャッシュの変更のRMU/RECOVERでデータベースが破損する
Oracle Bug#5469750
データベースの行キャッシュ・パラメータが変更され、データベースがリストアおよびリカバリされると、結果としてそのデータベースは破損していました。場合によっては、RMU/RECOVERプロセスも失敗し、Oracle Rdbモニター・プロセスが失敗することもあります。
次のスクリプトで問題を示します。
$
$ ! Create a database with a few basic caches.
$
$ SQL$
CREATE DATABASE FILENAME TEST
NUMBER OF CLUSTER NODES 1
RESERVE 4 STORAGE AREAS
RESERVE 3 JOURNALS
RESERVE 3 CACHE SLOTS
ROW CACHE IS ENABLED
CREATE STORAGE AREA RDB$SYSTEM FILENAME TEST
CREATE STORAGE AREA TEST_A1 FILENAME TEST_A1
CREATE STORAGE AREA TEST_A2 FILENAME TEST_A2
CREATE STORAGE AREA TEST_A3 FILENAME TEST_A3
CREATE CACHE TEST_A1 CACHE SIZE 100 ROWS ROW LENGTH 100 BYTES
CREATE CACHE TEST_A2 CACHE SIZE 200 ROWS ROW LENGTH 200 BYTES
CREATE CACHE TEST_A3 CACHE SIZE 300 ROWS ROW LENGTH 300 BYTES;
DISCONNECT ALL;
ALTER DATABASE FILENAME TEST
ADD JOURNAL TEST_J1 FILENAME SYS$DISK:[]TEST_J1.AIJ
ADD JOURNAL TEST_J2 FILENAME SYS$DISK:[]TEST_J2.AIJ
ADD JOURNAL TEST_J3 FILENAME SYS$DISK:[]TEST_J3.AIJ
JOURNAL IS ENABLED (FAST COMMIT ENABLED);
%RDMS-W-DOFULLBCK, full database backup should be done to ensure future recovery
EXIT;
$
$ ! Save away the original cache configuration.
$
$ RMU/BACKUP/NOLOG TEST TEST
$ RMU/DUMP/HEADER=BRIEF/OUTPUT=BEFORE.TXT TEST
$
$ ! Alter a cache parameter.
$
$ SQL$
ALTER DATABASE FILENAME TEST ALTER CACHE TEST_A2 ROW LENGTH 400 BYTES;
DISCONNECT ALL;
-- Delete the database
DROP DATABASE FILENAME TEST;
EXIT;
$
$ ! Restore the database. RMU will automatically recover the journals.
$
$ RMU/RESTORE/NOCDD/NOLOG TEST
%RMU-I-AIJRSTAVL, 3 after-image journals available for use
%RMU-I-AIJRSTMOD, 1 after-image journal marked as "modified"
%RMU-I-AIJISON, after-image journaling has been enabled
%RMU-W-DOFULLBCK, full database backup should be done to ensure future recovery
%RMU-I-LOGRECDB, recovering database file DEV:[DIR]TEST.RDB;1
%RMU-I-AIJAUTOREC, starting automatic after-image journal recovery
%RMU-I-AIJONEDONE, AIJ file sequence 0 roll-forward operations completed
%RMU-I-AIJONEDONE, AIJ file sequence 1 roll-forward operations completed
%RMU-W-NOTRANAPP, no transactions in this journal were applied
%RMU-I-AIJALLDONE, after-image journal roll-forward operations completed
%RMU-I-AIJSUCCES, database recovery completed successfully
%RMU-I-AIJFNLSEQ, to start another AIJ file recovery, the sequence number
needed will be 2
$ RMU/DUMP/HEADER=BRIEF/OUTPUT=AFTER.TXT TEST
$
$ ! Compare the original database with the recovered database.
$ ! In this example, instead of the cache row length being changed
$ ! to 400 the number of database buffers is changed to 400.
$
$ DIFFERENCE BEFORE.TXT AFTER.TXT
.
.
.
************
File DEV:[DIR]BEFORE.TXT;1
35 - Default user buffer count is 20
36 - Default recovery buffer count is 20
37 - Global buffers are disabled
******
File DEV:[DIR]AFTER.TXT;1
35 - Default user buffer count is 400
36 - Default recovery buffer count is 400 (stored as 20)
37 - Global buffers are disabled
************
どの行キャッシュ・パラメータを変更するかによって、RMU/RECOVER操作またはデータベースのモニターで発生する障害は異なる可能性があります。レポートされた問題では、RMU/RECOVERが失敗し、次の例外が発生しました。
***** Exception at 007E35BC : PIO$FETCH + 000003EC %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=0000000000000000, PC=00000000007E35BC, PS=0000001B
また、データベースのモニターも失敗し、次の例外が発生しました。
**** Exception at hhhhhhhh : MON$DELETE_UNREFERENCED_GBL + 00000DAC %SYSTEM-F-ACCVIO, access violation, virtual address=0000000000414000
この問題を回避するには、行キャッシュ・パラメータの変更後、データベースの全体バックアップとジャーナルのバックアップを行います。この問題が発生すると、リストアされたデータベースを、行キャッシュの変更が含まれるジャーナルの時点までリカバリできます。つまり、/UNTIL修飾子を使用する場合、行キャッシュの変更が行われた時点までジャーナルをリカバリします。
この問題は、Oracle Rdbリリース7.2.1で修正されました。
7.5.2 行のスナップショットが有効な場合、リカバリされたデータベースが破損する
キャッシュ機能のスナップショットが有効な場合、アフター・イメージ・ジャーナル（AIJ）のエントリが不正なトランザクション順序番号（TSN）で記録されることがありました。このため、リストアされたデータベースをリカバリするためにジャーナルが使用されると、データベースが破損することがありました。この問題は、更新文でエラーが発生して、トランザクションが後からコミットされる場合に発生していました。たとえば、制約の失敗またはロックのタイムアウトの後にCOMMITを実行すると、不正なジャーナルのエントリが作成されていました。
この問題は、Oracle Rdbリリース7.1.4.4および7.2.0.2で導入されました。
この問題を回避するには、すべてのキャッシュをROW SNAPSHOT IS DISABLEDに設定します。
この問題は、Oracle Rdbリリース7.2.1で修正されました。
7.6 RMU Show Statisticsエラーの修正
7.6.1 RMU/SHOW STATISTICSの「Hot Standby Statistics」の「State」表示フィールド
Oracle Bug#5396571
以前は、ホット・スタンバイ機能でTCP/IPネットワーク・トランスポートを使用する場合、RMU /SHOW STATISTICSの「Hot Standby Statistics」画面の「State」フィールドが、次の例に示すように、見出し「UserSync:」を上書きすることがありました。
Node: HSVMS (1/1/16) Oracle Rdb V7.1-441 Perf. Monitor 18-JUL-2006 06:17:59.97 Rate: 3.00 Seconds Hot Standby Statistics Elapsed: 00:07:28.63 Page: 1 of 1 $1$DGA113:[MWILLEMS.HS.HS1.MASTER]MF_PERSONNEL.RDB;1 Mode: Online ------------------------------------------------------------------------- State: TCP/IP:72 rSync: Cold Current.Msg: 1 Cl Mstr.AIJ: 1:2 LagTime: 00:00:00 AutoSync: Cold Stalled.Msg: none 1 Stby.AIJ: 1:2 Stby.DB: HSVMS1::$1$DGA20:[MWILLEMS.HS.HS1.STANDBY]STANDBY_MF_PERSONNEL
「State」で開始される行が、「UserSync:」を部分的に上書きしています。
この問題は、Oracle Rdbリリース7.2.1で修正されました。
7.6.2 RMU /SHOW STATISTICSの「Defined Logicals」のリストが完全ではない
Oracle Bug#5600122
以前は、RMU /SHOW STATISTICSの「Defined Logicals」画面がFullモードに設定されている場合、その画面にすべての論理が適切にリストされないことがありました。この問題は、考えられる論理名の数が誤って計算されることで生じていました。
この問題は、Oracle Rdbリリース7.2.1で修正されました。論理名の完全なリストが正しく表示されるようになりました。
7.6.3 Rdbエグゼクティブのソートと一時作業ファイルの統計
Oracle Bug#5617519
以前は、全データベース・レベルでRdbエグゼクティブ内のソート操作の数と一時作業ファイル操作の数を決定する、信頼性の高い方法がありませんでした。
Rdbエグゼクティブ内のソート操作と一時作業ファイル操作の数およびタイプの把握に役立つ新しい統計が利用できます。これらの統計は、RMU /SHOW STATISTICSユーティリティの「Rdb Executive Statistics」画面で使用できます。
ソートと一時作業ファイルの統計を示す「Rdb Executive Statistics」画面の例を示します。
Node: LUCAS (1/1/1) Oracle Rdb X7.2-00 Perf. Monitor 26-OCT-2006 22:41:29.41
Rate: 3.00 Seconds Rdb Executive Statistics Elapsed: 00:02:50.14
Page: 1 of 1 $1$DGA203:[HSEC]MF_PERSONNEL.RDB;1 Mode: Online
--------------------------------------------------------------------------------
statistic......... rate.per.second............. total....... average......
name.............. max..... cur..... avg....... count....... per.trans....
queries compiled 16 0 0.7 82 16.4
index scans 84 0 3.8 430 86.0
index only 0 0 0.0 0 0.0
index full 21 0 1.0 112 22.4
dynamic optimizer 10 0 0.3 34 6.8
one abandoned 0 0 0.0 1 0.2
all abandoned 0 0 0.0 0 0.0
records sorted 37 0 3.0 339 67.8
quick-sorts 0 0 0.0 3 0.6
sort32 sorts 0 0 0.0 4 0.8
workfile write IO 0 0 0.0 0 0.0
workfile read IO 0 0 0.0 0 0.0
temp file create 63 0 2.7 301 60.2
delete 63 0 2.7 301 60.2
truncate 0 0 0.0 0 0.0
record put 246 0 11.3 1268 253.6
record get 267 0 11.3 1268 253.6
record position 63 0 2.7 301 60.2
このリリースのOracle Rdbでは、いくつかのパフォーマンスの拡張機能が実装されました。これらの変更は、ほとんどの場合、I64システムで実行するアプリケーションに固有のものか、あるいはI64システムに重大な影響を与えます。拡張機能は次のとおりです。
Oracle Bug#6389282
最適化レベルのTOTAL TIMEおよびFAST FIRSTは、次の方法で指定できます。
ただし、一部の動的SQL環境では、これらの方法によって影響を受けない問合せが生成されます。そのため、Oracle Rdbはこのような問合せをカバーできる新しいフラグをSET FLAGS（およびRDMS$SET_FLAGS論理名）に追加しました。
フラグOPTIMIZATION_LEVELを使用して、問合せのデフォルトの最適化レベルを変更できます。問合せがOPTIMIZE FOR句を明示的に使用するか、または前述の方法を使用してデフォルトを上書きする環境内で問合せがコンパイルされる場合、問合せの最適化に対する変更は行われません。問合せがデフォルトの最適化レベルを使用する場合、最適化はこのフラグで変更されます。
次の例は、動的オプティマイザを使用する問合せの動作の変更を示しています。
SQL> -- show with default behavior (FFirst tactic used)
SQL> select *
cont> from xtest
cont> where col2 between 999980 and 1000000
cont> and col1 > 0
cont> ;
Tables:
0 = XTEST
Leaf#01 FFirst 0:XTEST Card=10
Bool: (0.COL2 >= 999980) AND (0.COL2 <= 1000000) AND (0.COL1 > 0)
BgrNdx1 XTEST_IDX [1:0] Fan=17
Keys: 0.COL1 > 0
0 rows selected
SQL>
SQL> -- use SET FLAGS
SQL> set flags 'optimization_level(total_time)';
SQL>
SQL> -- show that BgrOnly is used for TOTAL TIME
SQL> select *
cont> from xtest
cont> where col2 between 999980 and 1000000
cont> and col1 > 0
cont> ;
Tables:
0 = XTEST
Leaf#01 BgrOnly 0:XTEST Card=10
Bool: (0.COL2 >= 999980) AND (0.COL2 <= 1000000) AND (0.COL1 > 0)
BgrNdx1 XTEST_IDX [1:0] Fan=17
Keys: 0.COL1 > 0
0 rows selected
SQL>
この機能は、Oracle Rdbリリース7.2.2で追加されました。
8.1.3 新しい修飾子/ABMS_ONLYは、RdbデータベースのABMページのみをダンプする
現在、RMU/DUMPコマンドを使用する場合、Oracle Rdbデータベースの領域ビット・マップ・ページは、統一記憶域または統一記憶域内の論理領域のその他のページと一緒にダンプできます。RMU/DUMPコマンドに新しい修飾子/ABMS_ONLYが追加されました。/ABMS_ONLYは、統一記憶域または統一記憶域内に含まれる論理領域のABMページのみをダンプします。既存の/START=n修飾子または/END=n修飾子（あるいはその両方）で指定した限定ページ範囲内のABMページをダンプできます。nはページ番号です。あるいは、限定ページ範囲を指定しない場合、統一記憶域内または統一記憶域に含まれる論理領域内のABMページをすべてダンプできます。
/ABMS_ONLY修飾子を無効にすることはできません。この修飾子は、デフォルトにはなりません。/ABMS_ONLYを指定しない場合、デフォルトでは、ABMページとともに記憶域と論理領域の他のデータベース・ページを引き続きダンプします。既存の/AREAS、/LAREAS、/ALL_LIVE、/ALL_LAREAの各修飾子を、RMU/DUMPのコマンドラインで/ABMS_ONLY修飾子とともに使用しない場合、/ALL_LIVEのデフォルトでは、すべての有効な統一記憶域内に含まれるABMページのみがダンプされます。ABMページのダンプの形式は変更されていません。ヘッダーは現在と同様に出力され、ダンプする有効な統一記憶域、または有効な統一記憶域内の論理領域の後に続く各論理領域内に含まれるABMページ（あるいはその両方）を特定します。データベース・ヘッダーのダンプが、現在と同様にダンプの開始時に含まれます。
指定したページ範囲内にABMページがない場合、記憶域が混合形式領域の場合、または論理領域が混合記憶域内に含まれる場合、ABMページが存在しないため、ダンプするABMページはありません。RMU/DUMP/HEADERコマンドを実行する場合、Rdbデータベースに定義された記憶域のエントリは、どの領域が統一形式であるか、どの領域が混合形式であるかを指定します。/ABMS_ONLY修飾子は、領域管理ページのみをダンプする既存の/SPAMS_ONLY修飾子と同じダンプ・コマンドで指定できません。/ABMS_ONLY修飾子は、SNAPSHOT領域をダンプする既存の/SNAPSHOTS修飾子と同じダンプ・コマンドで指定できません。
ABMページのみをダンプする構文は次のとおりです。
/ABMS_ONLY
次の例では、指定したRdbデータベースのすべての統一記憶域に含まれるABMページがすべてダンプされます。
$ rmu/dump/abms_only/out=dmp.out mf_personnel
次の例では、指定したRdbデータベースの指定の統一記憶域に含まれるABMページのみがダンプされます。
$ rmu/dump/abms_only/area=rdb$system mf_personnel
次の例では、指定したRdbデータベースの統一記憶域の指定の論理領域に含まれるABMページのみがダンプされます。
$ rmu/dump/abms_only/larea=rdb$relations mf_personnel
次の例では、指定したRdbデータベースの指定の統一記憶域の指定のページ範囲内に含まれるABMページのみがダンプされます。
rmu/dump/abms_only/area=rdb$system/start=1/end=5 mf_personnel
記憶域が異なるデバイスにある場合、RMU/BACKUPは、最初の入力デバイスのすべての記憶域の読取りを開始してから、次の入力デバイスに進んでいました。このため、各種デバイスのI/O負荷が均一ではなくなっていました。1つの入力デバイスの読取りI/Oがかなりアクティブに実行されている間は、その他の入力デバイスがアイドリング状態になっていました。
このリリースの拡張機能では、RMU/BACKUPは、記憶域のディスク・デバイスに基づいてラウンドロビン方式を使用することで、保存する記憶域をリーダー・スレッドに割り当てます。このディスク・デバイスに対して、比較的大きな記憶域が最初に選択されます。以前と同様に、各出力デバイス、保存セットまたはメディア・マネージャのストリームに移行するデータ量のバランスが均一になります。
$ RMU/BACKUP/LOG=FULL LDA100:[DB]MYTESTDB -
$1$DGA20:[BACKUP]RBF1,$1$DGA40:[BACKUP]RBF2/DISK=WRITERS=2
%RMU-I-BCKTXT_01, Writer thread 1 writes $1$DGA20:[BACKUP]RBF1.RBF; containing:
File LDA100:[DB]MYTESTDB.RDA;1 1404 blocks
File LDA100:[DB]A0007.RDA;1 5388 blocks
File LDA300:[DB]A0006.RDA;1 7758 blocks
File LDA100:[DB]A0004.RDA;1 4490 blocks
File LDA200:[DB]A0005.RDA;1 9310 blocks
File LDA300:[DB]A0009.RDA;1 4490 blocks
File LDA200:[DB]A0011.RDA;1 3742 blocks
File LDA100:[DB]A0001.RDA;1 2599 blocks
File LDA300:[DB]A0012.RDA;1 3742 blocks
%RMU-I-BCKTXT_01, Writer thread 2 writes $1$DGA40:[BACKUP]RBF2.RBF; containing:
File LDA200:[DB]A0002.RDA;1 27802 blocks
File LDA100:[DB]A0010.RDA;1 3742 blocks
File LDA300:[DB]A0003.RDA;1 4490 blocks
File LDA200:[DB]A0008.RDA;1 2166 blocks
%RMU-I-BCKTXT_00, Backed up root file LDA100:[DB]MYTESTDB.RDB;1
%RMU-I-RESUME, resuming operation on volume 2 using _$1$DGA40
%RMU-I-BCKTXT_02, Starting full backup of storage area (RDB$SYSTEM)
LDA100:[DB]MYTESTDB.RDA;1
%RMU-I-BCKTXT_12, Completed full backup of storage area (RDB$SYSTEM)
LDA100:[DB]MYTESTDB.RDA;1
%RMU-I-BCKTXT_02, Starting full backup of storage area (A0009)
LDA300:[DB]A0009.RDA;1
%RMU-I-BCKTXT_02, Starting full backup of storage area (A0002)
LDA200:[DB]A0002.RDA;1
%RMU-I-BCKTXT_02, Starting full backup of storage area (A0007)
LDA100:[DB]A0007.RDA;1
%RMU-I-BCKTXT_02, Starting full backup of storage area (A0010)
LDA100:[DB]A0010.RDA;1
%RMU-I-BCKTXT_02, Starting full backup of storage area (A0006)
LDA300:[DB]A0006.RDA;1
%RMU-I-BCKTXT_02, Starting full backup of storage area (A0003)
LDA300:[DB]A0003.RDA;1
%RMU-I-BCKTXT_02, Starting full backup of storage area (A0004)
LDA100:[DB]A0004.RDA;1
%RMU-I-BCKTXT_02, Starting full backup of storage area (A0008)
LDA200:[DB]A0008.RDA;1
%RMU-I-BCKTXT_02, Starting full backup of storage area (A0005)
LDA200:[DB]A0005.RDA;1
%RMU-I-BCKTXT_12, Completed full backup of storage area (A0008)
LDA200:[DB]A0008.RDA;1
%RMU-I-BCKTXT_12, Completed full backup of storage area (A0010)
LDA100:[DB]A0010.RDA;1
%RMU-I-BCKTXT_12, Completed full backup of storage area (A0003)
LDA300:[DB]A0003.RDA;1
%RMU-I-BCKTXT_12, Completed full backup of storage area (A0004)
LDA100:[DB]A0004.RDA;1
%RMU-I-BCKTXT_02, Starting full backup of storage area (A0011)
LDA200:[DB]A0011.RDA;1
%RMU-I-BCKTXT_12, Completed full backup of storage area (A0009)
LDA300:[DB]A0009.RDA;1
%RMU-I-BCKTXT_02, Starting full backup of storage area (A0001)
LDA100:[DB]A0001.RDA;1
%RMU-I-BCKTXT_12, Completed full backup of storage area (A0007)
LDA100:[DB]A0007.RDA;1
%RMU-I-BCKTXT_02, Starting full backup of storage area (A0012)
LDA300:[DB]A0012.RDA;1
%RMU-I-BCKTXT_12, Completed full backup of storage area (A0001)
LDA100:[DB]A0001.RDA;1
%RMU-I-BCKTXT_12, Completed full backup of storage area (A0002)
LDA200:[DB]A0002.RDA;1
%RMU-I-BCKTXT_12, Completed full backup of storage area (A0006)
LDA300:[DB]A0006.RDA;1
%RMU-I-BCKTXT_12, Completed full backup of storage area (A0011)
LDA200:[DB]A0011.RDA;1
%RMU-I-BCKTXT_12, Completed full backup of storage area (A0005)
LDA200:[DB]A0005.RDA;1
%RMU-I-BCKTXT_12, Completed full backup of storage area (A0012)
LDA300:[DB]A0012.RDA;1
%RMU-I-COMPLETED, BACKUP operation completed
RMU /SET SERVER /OUTPUT=filespec servertypeコマンドを使用して、いくつかのデータベース・サーバー・プロセスに対してデフォルトの出力ファイルの仕様を指定できます。出力ファイルの仕様が空の場合、出力ファイルのエントリは無効です。現在、出力ファイルのエントリを無効にするには、空の出力ファイルの仕様を/OUTPUT修飾子で指定する以外に、RMU /SET SERVER /NOOUTPUT servertypeを指定する方法もあります。/NOOUTPUTはデフォルトであり、/OUTPUTが指定されない場合、出力ファイルのサーバー・ロギングのエントリは無効になることに注意してください。
そのため、/OUTPUT修飾子の構文は次のようになります。
[NO]OUTPUT[=filespec]
次の例は、出力ファイルのエントリをRMU/SET SERVERコマンドで無効にする方法を示しています。無効にするには、/NOOUTPUTを指定するか、空の出力ファイルの仕様で/OUTPUTを指定するか、または/NOOUTPUTがデフォルトなので/OUTPUTを指定しないようにします。
$ RMU /SET SERVER LRS /NOOUTPUT DUA0:[ZDB]ZDB.RDB $ RMU /SET SERVER LRS /OUTPUT="" DUA0:[ZDB]ZDB.RDB $ RMU /SET SERVER LRS DUA0:[ZDB]ZDB.RDB
Oracle Bug#6494061
以前のバージョンのOracle Rdbでは、現在のバージョンを使用してエラーが発生した場合、リモート接続のクライアント側は、デフォルトで古いバージョンのリモートRdbプロトコルを使用してリモート・サーバーとの通信を試みます。この再試行は、データベースのアタッチ、作成または削除が失敗する場合に発生していました。古いプロトコル・バージョンは、Rdb 5.1以下で使用されたものです。この再試行は、クライアントがかなり古いバージョンのリモート・サーバーと自動的に通信できるようにすることを目的としていました。
データベースのアタッチ、作成または削除の失敗がレポートされる場合、この再試行によって、ほとんどのユーザーは2倍の長さと2倍の量のリソースを消費するという影響を受けました。クライアントとサーバーのプロトコルの交換がかなり混乱するため、クライアントがLEF状態でハングすることもありました。たとえば、リモート・サーバーが実行していたノードでRdbモニターが稼働していなかった場合などに発生していました。
前述の問題を解決するために、古いプロトコルを使用する再試行が行われないようにデフォルトの動作が変更されました。ユーザーがRdb 5.1以下のバージョンのリモート・サーバーを使用してリモート・データベースに接続する必要がある場合、Rdbで古いプロトコルを使用して再試行するための新しい構成ファイル・パラメータが追加されました。この構成ファイル・パラメータの名前はSQL_PROTOCOL_RETRYで、RDB$CLIENT_DEFAULTS.DATファイルにあります。構成ファイルの情報の詳細は、Oracle Rdbのインストレーションおよび構成ガイドの第4章を参照してください。
たとえば、リモート・データベースを使用するクライアント・アプリケーションは、RDB$CLIENT_DEFAULTS.DATに次のエントリが含まれる場合、古いリモート・プロトコルを使用して再試行します。
SQL_PROTOCOL_RETRY TRUE
Oracle Bug#705542
以前は、RMU/RESTOREコマンドは、混合形式の記憶域の場合のみ、ページ・サイズの増加を許可していました。
この制限は緩和されました。RMUリモート操作時に混合記憶域と統一記憶域のどちらの形式でも、ページ・サイズを増加できるようになりました。
Oracle Enhancement Bug#6331702
以前のリリースのOracle Rdbでは、RMU/SHOW STATISTICSの/STALL_LOG機能を使用すると、すべてのアクティブなストール・メッセージがサンプルの期間ごとにストール・ログ・ファイルに書き込まれていました。ほとんどのアクティブなストールが短期間にあるため、情報量が多すぎてしまいます。
この問題は、Oracle Rdbリリース7.2.1.4で修正されました。RMU/SHOW STATISTICSコマンドは、/OPTION修飾子に対して新しいLOG_STALL_ALARMキーワードを受け入れるようになりました。/STALL_LOGと/ALARMを使用する際にLOG_STALL_ALARMが存在する場合、/ALARMで指定した期間を超えるストールのみがストール・ログ出力ファイルに書き込まれます。
9.1.2 RMU/SHOW STATISTICSのストール・アラーム起動プロシージャのパラメータの追加
Oracle Enhancement Bug#6331702
ストール・アラーム起動コマンドに渡されるパラメータにパラメータP6が追加されました。P6パラメータには、書式設定されたストール・メッセージ文字列が含まれます。
起動コマンドに渡されるパラメータは次のとおりです。
| パラメータ | 説明 |
|---|---|
| P1 | ルート・ファイルの仕様 |
| P2 | 現在のデータ/時間 |
| P3 | プロセスID |
| P4 | ストリームID |
| P5 | アラームのしきい値の秒数 |
| P6 | 書式設定されたストール・メッセージ |
Oracle Enhancement Bug#3390639
RMU /SHOW AIPコマンドは、次の例に示すように、AIP情報を要約した表形式で表示する修飾子/BRIEFをサポートするようになりました。
$ RMU/SHOW AIP DKA0:[DB]DB /PAREA=(4,5)/BRIEF *---------------------------------------------------------------------------- * Logical Area Name LArea PArea Len Type *---------------------------------------------------------------------------- RDB$SYSTEM_RECORD 60 4 215 SYSTEM RECORD RDB$SYSTEM_RECORD 61 5 215 SYSTEM RECORD EMPLOYEES_HASH 79 4 215 HASH INDEX EMPLOYEES 82 4 121 TABLE JOB_HISTORY_HASH 85 4 215 HASH INDEX JOB_HISTORY 88 4 42 TABLE DEPARTMENTS_INDEX 89 5 430 SORTED INDEX DEPARTMENTS 90 5 55 TABLE
表示される列は次のとおりです。
RMU /SHOW AIPコマンドは、指定した物理領域に保存される論理領域のAIP情報を表示する修飾子/PAREAをサポートするようになりました。
$ RMU/SHOW AIP DKA0:[DB]DB /BRIEF /PAREA=(4,5) *---------------------------------------------------------------------------- * Logical Area Name LArea PArea Len Type *---------------------------------------------------------------------------- RDB$SYSTEM_RECORD 60 4 215 SYSTEM RECORD RDB$SYSTEM_RECORD 61 5 215 SYSTEM RECORD EMPLOYEES_HASH 79 4 215 HASH INDEX EMPLOYEES 82 4 121 TABLE JOB_HISTORY_HASH 85 4 215 HASH INDEX JOB_HISTORY 88 4 42 TABLE DEPARTMENTS_INDEX 89 5 430 SORTED INDEX DEPARTMENTS 90 5 55 TABLE
このリリースのOracle Rdbでは、RMU Dump ExportのOPTIONS修飾子に新しいキーワードが追加されています。OPTIONS修飾子を使用すると、このダンプ・コマンドからの出力を変更できます。
$ RMU/DUMP/EXPORT/OPTION=HEADER JOBS.UNL
BEGIN HEADER SECTION - (0)
NONCORE_TEXT HDR_BRP_ID - (20) : Load/Unload utility
CORE_NUMERIC HDR_BRPFILE_VERSION - (1) : 4
NONCORE_TEXT HDR_DBS_ID - (18) : Oracle Rdb V7.2-10
NONCORE_TEXT HDR_DB_NAME - (16) : DB$:MF_PERSONNEL
NONCORE_DATE HDR_DB_LOG_BACKUP_DATE - (8) : 3-JUL-2006 16:52:32.83
CORE_NUMERIC HDR_DATA_COMPRESSION - (1) : 1
END HEADER SECTION - (0)
$
使用上の注意
$ RMU/DUMP/EXPORT/OP=IMPORT_DATABASE EMPLOYEES.UNL/OUT=EMP.SQL $ SQL$ @EMP.SQL SQL> IMPORT DATABASE cont> from 'DISK1:[TESTING]EMPLOYEES.UNL;1' cont> -- ident ' Load/Unload utility' cont> -- backup file version 4 cont> -- database ident 'Oracle Rdb V7.2-131' cont> filename 'DB$:MF_PERSONNEL' cont> ; %SQL-F-EXTRADATA, unexpected data at the end of the .RBR file $
この章では、ドキュメントの誤りと省略に関する修正について説明します。
10.1 ドキュメントの修正
10.1.1 SET OPTIMIZATION LEVEL文の例の修正
Oracle Bug#6350960
例1: 最適化レベルの設定
動的オプティマイザは、FAST FIRSTまたはTOTAL TIMEの方法を使用してアプリケーションに行を返すことができます。デフォルトの設定FAST FIRSTでは、アプリケーション（特に対話型SQLを使用するアプリケーション）が可能なかぎり早く行を確認して、場合によっては完了前に問合せを中断することを前提とします。そのため、FAST FIRSTの方法が可能な場合、オプティマイザはすべての検索時間を使って、最初に行を素早く返します。この選択は、OPTIMIZATION LEVELの設定によって影響を受けます。
次の例は、FAST FIRSTとTOTAL TIMEが有効な場合に選択される問合せのストラテジを対比したものです。データベースと問合せは、その要件によって変わります。問合せを調整して、どの設定がアプリケーション環境のニーズに最適かを確認する必要があります。MF_PERSONNELデータベースの場合、これらの方法に違いはほとんど（まったく）ありませんが、比較的大きな表の場合、違いが顕著になる可能性があります。
SQL> set flags 'STRATEGY,DETAIL';
SQL> --
SQL> -- No optimization level has been selected. The optimizer
SQL> -- selects the FAST FIRST (FFirst) retrieval tactic to
SQL> -- retrieve the rows from the EMPLOYEES table in the
SQL> -- following query:
SQL> --
SQL> select EMPLOYEE_ID, LAST_NAME
cont> from EMPLOYEES
cont> where EMPLOYEE_ID IN ('00167', '00168');
Tables:
0 = EMPLOYEES
Leaf#01 FFirst 0:EMPLOYEES Card=100
Bool: (0.EMPLOYEE_ID = '00167') OR (0.EMPLOYEE_ID = '00168')
BgrNdx1 EMPLOYEES_HASH [(1:1)2] Fan=1
Keys: r0: 0.EMPLOYEE_ID = '00168'
r1: 0.EMPLOYEE_ID = '00167'
EMPLOYEE_ID LAST_NAME
00167 Kilpatrick
00168 Nash
2 rows selected
SQL> --
SQL> -- Use the SET OPTIMIZATION LEVEL statement to specify that
SQL> -- you want the TOTAL TIME (BgrOnly) retrieval strategy to
SQL> -- be used.
SQL> --
SQL> SET OPTIMIZATION LEVEL 'TOTAL TIME';
SQL> select EMPLOYEE_ID, LAST_NAME
cont> from EMPLOYEES
cont> where EMPLOYEE_ID IN ('00167', '00168');
Tables:
0 = EMPLOYEES
Leaf#01 BgrOnly 0:EMPLOYEES Card=100
Bool: (0.EMPLOYEE_ID = '00167') OR (0.EMPLOYEE_ID = '00168')
BgrNdx1 EMPLOYEES_HASH [(1:1)2] Fan=1
Keys: r0: 0.EMPLOYEE_ID = '00168'
r1: 0.EMPLOYEE_ID = '00167'
EMPLOYEE_ID LAST_NAME
00167 Kilpatrick
00168 Nash
2 rows selected
SQL> --
SQL> -- When the SET OPTIMIZATION LEVEL 'DEFAULT' statement
SQL> -- is specified the session will revert to the default FAST FIRST
SQL> -- optimizer tactic.
SQL> --
SQL> SET OPTIMIZATION LEVEL 'DEFAULT';
SQL> select EMPLOYEE_ID, LAST_NAME
cont> from EMPLOYEES
cont> where EMPLOYEE_ID IN ('00167', '00168');
Tables:
0 = EMPLOYEES
Leaf#01 FFirst 0:EMPLOYEES Card=100
Bool: (0.EMPLOYEE_ID = '00167') OR (0.EMPLOYEE_ID = '00168')
BgrNdx1 EMPLOYEES_HASH [(1:1)2] Fan=1
Keys: r0: 0.EMPLOYEE_ID = '00168'
r1: 0.EMPLOYEE_ID = '00167'
EMPLOYEE_ID LAST_NAME
00167 Kilpatrick
00168 Nash
2 rows selected
SQL>
RMU/VERIFYコマンドを使用する場合、プロセスには最低でも次の割当てが必要です。
Oracle RMU BACKUPコマンドの次の間違った制限事項は、『Oracle Rdb for OpenVMS Oracle RMUリファレンス・マニュアル』から削除されます。
以前のリリースの『Oracle Rdb for OpenVMS Oracle RMUリファレンス・マニュアル』では、RMU Backupオンライン・オプションの下に、「メモリーによる転送（ページ転送の最適化とも呼ばれる）が有効な場合は、オンラインのバックアップ・オプションを実行できない」と記載されています。（ページ転送の最適化の詳細は、『Oracle Rdb SQLリファレンス・マニュアル』のSQL ALTER DATABASE文の説明を参照してください。）この制限事項は現在当てはまらないため、『Oracle Rdb for OpenVMS Oracle RMUリファレンス・マニュアル』から削除される予定です。
Online Copy DatabaseコマンドとOnline Move Areaコマンドにも同じ制限事項がリストされています。この制限事項は現在これらのコマンドに当てはまらないため、『Oracle Rdb for OpenVMS Oracle RMUリファレンス・マニュアル』から削除される予定です。
10.1.4 CREATE STORAGE MAPの例の欠落
Oracle Bug#5655348
『Oracle Rdb SQLリファレンス・マニュアル』には、LIST記憶域マップの記憶域属性を示す例が記載されていませんでした。次の例は、Oracle Rdbリリース7.2の将来のバージョンの『Oracle Rdb SQLリファレンス・マニュアル』のCREATE STORAGE MAPに関する項に記載される予定です。
例
次の例は、LIST記憶域マップの記憶域属性の使用状況を示しています。記憶域属性は、記憶域名（表の記憶域マップと同様）の直後にします。
SQL> create database
cont> filename 'DB$:MULTIMEDIA'
cont>
cont> create storage area PHOTO_AREA1
cont> filename 'DB$:PHOTO_AREA1'
cont> page format UNIFORM
cont>
cont> create storage area PHOTO_AREA2
cont> filename 'DB$:PHOTO_AREA2'
cont> page format UNIFORM
cont>
cont> create storage area TEXT_AREA
cont> filename 'DB$:TEXT_AREA'
cont> page format UNIFORM
cont>
cont> create storage area AUDIO_AREA
cont> filename 'DB$:AUDIO_AREA'
cont> page format UNIFORM
cont>
cont> create storage area DATA_AREA
cont> filename 'DB$:DATA_AREA'
cont> page format UNIFORM
cont> ;
SQL>
SQL> create table EMPLOYEES
cont> (name char(30),
cont> dob date,
cont> ident integer,
cont> photograph list of byte varying (4096) as binary,
cont> resume list of byte varying (132) as text,
cont> review list of byte varying (80) as text,
cont> voiceprint list of byte varying (4096) as binary
cont> );
SQL>
SQL> create storage map EMPLOYEES_MAP
cont> for EMPLOYEES
cont> enable compression
cont> store in DATA_AREA;f
SQL>
SQL> create storage map LISTS_MAP
cont> store lists
cont> in AUDIO_AREA
cont> (thresholds are (89, 99, 100)
cont> ,comment is 'The voice clips'
cont> ,partition AUDIO_STUFF)
cont> for (employees.voiceprint)
cont> in TEXT_AREA
cont> (thresholds is (99)
cont> ,partition TEXT_DOCUMENTS)
cont> for (employees.resume, employees.review)
cont> in (PHOTO_AREA1
cont> (comment is 'Happy Smiling Faces?'
cont> ,threshold is (99)
cont> ,partition PHOTOGRAPHIC_IMAGES_1)
cont> ,PHOTO_AREA2
cont> (comment is 'Happy Smiling Faces?'
cont> ,threshold is (99)
cont> ,partition PHOTOGRAPHIC_IMAGES_2)
cont> )
cont> for (employees.photograph)
cont> fill randomly
cont> in RDB$SYSTEM
cont> (partition SYSTEM_LARGE_OBJECTS);
SQL>
SQL> show storage map LISTS_MAP;
LISTS_MAP
For Lists
Store clause: STORE lists
in AUDIO_AREA
(thresholds are (89, 99, 100)
,comment is 'The voice clips'
,partition AUDIO_STUFF)
for (employees.voiceprint)
in TEXT_AREA
(thresholds is (99)
,partition TEXT_DOCUMENTS)
for (employees.resume, employees.review)
in (PHOTO_AREA1
(comment is 'Happy Smiling Faces?'
,threshold is (99)
,partition PHOTOGRAPHIC_IMAGES_1)
,PHOTO_AREA2
(comment is 'Happy Smiling Faces?'
,threshold is (99)
,partition PHOTOGRAPHIC_IMAGES_2)
)
for (employees.photograph)
fill randomly
in RDB$SYSTEM
(partition SYSTEM_LARGE_OBJECTS)
Partition information for lists map:
Vertical Partition: VRP_P000
Partition: (1) AUDIO_STUFF
Fill Randomly
Storage Area: AUDIO_AREA
Thresholds are (89, 99, 100)
Comment: The voice clips
Partition: (2) TEXT_DOCUMENTS
Fill Randomly
Storage Area: TEXT_AREA
Thresholds are (99, 100, 100)
Partition: (3) PHOTOGRAPHIC_IMAGES_1
Fill Randomly
Storage Area: PHOTO_AREA1
Thresholds are (99, 100, 100)
Comment: Happy Smiling Faces?
Partition: (3) PHOTOGRAPHIC_IMAGES_2
Storage Area: PHOTO_AREA2
Thresholds are (99, 100, 100)
Comment: Happy Smiling Faces?
Partition: (4) SYSTEM_LARGE_OBJECTS
Fill Randomly
Storage Area: RDB$SYSTEM
SQL>
SQL> commit;
Oracle Bug#1495227および3916606
『Oracle Rdb7データベース・パフォーマンスおよびチューニングのためのガイド』のA-17ページでは、RDM$BIND_MAX_DBR_COUNT論理の使用について誤って説明されています。
更新版の説明を次に示します。既存のドキュメントとソフトウェア間での実際の動作の違いは、論理名が各データベースのノード障害のリカバリ時（つまり、システムまたはモニターのクラッシュ、あるいはその他の異常終了の後）に同時に作成されたデータベース・リカバリ・プロセスの数のみを制御する点です。
データベース全体が異常終了する場合は（たとえばシステム障害などが原因）、ノード障害リカバリ・モードでデータベースをリカバリする必要があります。このリカバリは、データベースを別のノードで開く場合に別のノードで実行されるか、または次にデータベースを開くときに実行されます。
RDM$BIND_MAX_DBR_COUNT論理名とRDB_BIND_MAX_DBR_COUNT構成パラメータは、ノード障害のリカバリ時に各データベースのデータベース・モニターで同時に起動されるデータベース・リカバリ（DBR）プロセスの最大数を定義します。
この論理名と構成パラメータは、グローバルなバッファが有効ではないデータベースのみに適用されます。グローバルなバッファを使用するデータベースでは、ノード障害のリカバリ時に一度に1つのリカバリ・プロセスのみを開始します。
行キャッシュ機能が有効なノード障害のリカバリ（グローバル・バッファの状態には関係ない）では、データベース・モニターは1つのデータベース・リカバリ（DBR）プロセスを開始して、データベースの最も古いアクティブなチェックポイントからRow Cache Server（RCS）プロセスとすべてのユーザー・プロセスをリカバリします。
データベースごとの値
RDM$BIND_MAX_DBR_COUNT論理名は、各データベースに対して同時に実行するデータベース・リカバリ・プロセスの最大数を指定します。たとえば、リカバリするデータベースが10あり、RDM$BIND_MAX_DBR_COUNT論理名の値が8の場合、最大で80のデータベース・リカバリ・プロセスがノード障害後にモニターで開始されます。
RDM$BIND_MAX_DBR_COUNT論理名は、モニター・プロセスがデータベースを開くと変換されます。論理の新しい値を有効にするには、データベースを閉じて再度開く必要があります。
10.1.6 データベース・サーバー・プロセスの優先順位の明確化
デフォルトでは、Rdbモニターで作成されたデータベース・サーバー（ABS、ALS、DBR、LCS、LRS、RCS）は、VMSプロセスのスケジュールに基づく優先順位をRdbモニター・プロセスから継承します。Rdbモニター・プロセスのデフォルトの優先順位は15です。
各サーバーの優先順位は、表10-1に示すようにシステム全体の論理名によって明示的に制御できます。
| 論理名 | 使用する優先順位 |
|---|---|
| RDM$BIND_ABS_PRIORITY | ABSサーバー・プロセスの基本優先順位 |
| RDM$BIND_ALS_PRIORITY | ALSサーバー・プロセスの基本優先順位 |
| RDM$BIND_DBR_PRIORITY | DBRサーバー・プロセスの基本優先順位 |
| RDM$BIND_LCS_PRIORITY | LCSサーバー・プロセスの基本優先順位 |
| RDM$BIND_LRS_PRIORITY | LRSサーバー・プロセスの基本優先順位 |
| RDM$BIND_RCS_PRIORITY | RCSサーバー・プロセスの基本優先順位 |
ホット・スタンバイ機能をインストールする場合、アカウントの優先順位を15に指定するとRDMAIJSERVERアカウントが作成されます。システム上のAIJサーバー・プロセスの優先順位は、システム全体の論理名RDM$BIND_AIJSRV_PRIORITYで制限できます。この論理名を15よりも少ない値に定義する場合、AIJサーバー・プロセスの開始時に指定された値にその基本優先順位を調整します。RDM$BIND_AIJSRV_PRIORITYには値0〜31を使用できますが、プロセスの優先順位はRDMAIJSERVERアカウントの値よりも上にすることはできません。
ほとんどのアプリケーションとシステムの場合、サーバー・プロセスの優先順位を変更することはお薦めしません。
10.1.7 複数バージョンのSQL環境におけるSQL$INTの説明とSQL$INTの再定義方法
Oracle Bug#2500594
複数のバージョンのOracle Rdb（たとえばRdbリリース7.0とRdbリリース7.1など）を実行する環境では、SQL$70.EXEやSQL$71.EXEなどの改良されたSQLイメージがあります。ただし、SQL$INT.EXEは改良されていませんが、正しいSQLランタイム環境をアクティブ化する論理名RDMS$VERSION_VARIANTの変換を使用するディスパッチャとして機能します。このイメージは、比較的高いバージョンのOracle Rdbをインストールする場合に置き換えられます。そのため、前述の例を使用すると、Rdbリリース7.1をインストールする場合、SQL$INT.EXEはリリース7.1のSQL$INT.EXEに置き換えられます。
アプリケーションが、この環境（リリース7.1のSQL$INTを使用）と、Oracle Rdbリリース7.0の複数バージョンのみを実行するシステムにデプロイされた対応する実行可能ファイルでリンクされる場合、このアプリケーションを実行すると、次のエラーが発生することがあります。
%IMGACT-F-SYMVECMIS, shareable image's symbol vector table mismatch
このような問題を回避するには、次の代替方法が提供されます。
Oracle Rdbリリース7.0とOracle Rdbリリース7.1の両方を実行する複数バージョンの環境では、コマンド・プロシージャRDB$SETVER.COM 70とRDB$SETVER RESETを実行することでOracle Rdbリリース7.0の複数バージョンを実行します。これは、Oracle Rdbリリース7.0の環境の構築に必要な論理名と記号を設定します。
次に例を示します。
$ @SYS$LIBRARY:RDB$SETVER 70 Current PROCESS Oracle Rdb environment is version V7.0-63 (MULTIVERSION) Current PROCESS SQL environment is version V7.0-63 (MULTIVERSION) Current PROCESS Rdb/Dispatch environment is version V7.0-63 (MULTIVERSION) $ @SYS$LIBRARY:RDB$SERVER RESET
SQLを実行して、バージョンが正しいことを確認します。
$ sql$ SQL> show version Current version of SQL is: Oracle Rdb SQL V7.0-63
改良されたSQL$SHR.EXEを指し示すようにSQL$INTを定義します。次に、この新しく定義されたSQL$INTとリンクするリンカーを指示するオプション・ファイルを作成します。次に例を示します。
$ DEFINE SQL$INT SYS$SHARE:SQL$SHR'RDMS$VERSION_VARIANT'.EXE $ LINK TEST_APPL,SQL$USER/LIB,SYS$INPUT/option SQL$INT/SHARE ^Z
これでOracle Rdbリリース7.0の複数バージョンの環境に実行可能ファイルをデプロイする準備ができました。この実行可能ファイルは正常に実行されます。
Oracle Rdbの各リリースでは、SQL$INT共有可能イメージに新しいエントリ・ポイントが追加されていることに注意してください。この新しいエントリ・ポイントにより、新機能の実装が可能です。そのため、Oracle Rdbリリース7.1のSQL$INTとリンクするアプリケーションは、Oracle Rdbリリース7.0のみをインストールするシステムで実行できません。これは、共有可能イメージに十分なエントリ・ポイントが含まれていないためです。
ここで示す回避策を使用すると、アプリケーションはそのイメージのOracle Rdbリリース7.0と明示的にリンクできます。このようなアプリケーションには上位互換性があり、Oracle Rdbリリース7.0とOracle Rdbリリース7.1で実行されます。アプリケーションは最も低いバージョンでコンパイルしてリンクされます。
Oracle Rdbリリース7.1がインストールされている環境では、SQL$INTイメージが該当するSQL$SHRxxイメージを予定どおりに動的にアクティブ化するため、この回避策は必要ありません。
10.1.8 PREPARE文の動作の明確化
Oracle Bug#2581863
『Oracle Rdb SQLリファレンス・マニュアル』には、PREPAREのstatement-idパラメータを使用する際、「そのパラメータが整数の場合、PREPARE文を実行する前に、その整数を明示的にゼロに初期化する必要がある」と記載されています。
この説明は正しくありません。次の情報に書き換える必要があります。
statement-id-parameterではなくstatement-nameを使用する場合、SQLはアプリケーションで使用するためにidを暗黙的に宣言します。そのため、statement-nameを使用する場合、記述されたセマンティクスが同様に適用されます。詳細はRELEASE文を参照してください。
10.1.9 RDM$BIND_LOCK_TIMEOUT_INTERVALがデータベース・パラメータを上書きする
Oracle Bug#2203700
トランザクションを開始する場合、そのトランザクションのロック・タイムアウト時間の決定に使用する3つの異なる値があります。値は次のとおりです。
トランザクションのタイムアウト時間は、SET TRANSACTION文で指定する値やCREATE DATABASEで指定する値よりも小さくなります。ただし、論理名RDM$BIND_LOCK_TIMEOUT_INTERVALを定義する場合、この論理名の値はCREATE DATABASEに指定した値を上書きします。
これら3つの値の相互関係については、Rdbドキュメント・セットのいくつかの異なる箇所で説明されていますが、この説明には誤りがあるため、前述の説明で書き換えられる予定です。
データベースのロック・タイムアウト値は、RMU/SHOW STATISTICSのロック・ダッシュボードから動的に変更できます。プロセスごとのロック・ダッシュボードを使用して、1つ以上のプロセスに対して論理名RDM$BIND_LOCK_TIMEOUT_INTERVALを動的に上書きできます。
10.2 オンライン・ドキュメントの形式とオーダー情報
ドキュメントは、Acrobat Readerを使用するAdobe Acrobat形式で表示できます。Acrobat Readerを使用すると、Adobe Portable Document Format（PDF）のドキュメントを表示、ナビゲート、印刷できます。Acrobat Readerの無料コピーの入手やサポートされるプラットフォームの詳細は、http://www.adobe.comを参照してください。
Adobe Acrobat形式のOracle Rdbドキュメントは次のMetaLinkで入手できます。
Top Tech Docs\Oracle Rdb\Documentation\<bookname>
印刷されたドキュメントを購入するには、Oracleの担当者に連絡してください。
この章では、Oracle Rdbに関連する問題と制限事項について説明し、該当する回避策を示します。
11.1 すべてのインタフェースにおける既知の問題と制限事項
この項では、すべてのインタフェースに影響する既知の問題と制限事項について説明します。これは完全なリストではありません。Oracleバグのデータベースをチェックして、オープンしているすべてのRdbバグとその現在のステータスのリストを確認してください。
11.1.1 RCSの予期しない終了
Rdbリリース7.2.2の内部テストでは、Record Cache Server（RCS）が制御できずに終了する場合、特定の状況でデータベースまたはアフター・イメージ・ジャーナル・ファイル（あるいはその両方）が破損する問題が見つかりました。
RCSが終了すると、データベースは停止し、次のようなメッセージがモニター・ログに書き込まれます。
6-DEC-2007 15:04:17.02 - Received Record Cache Server image termination from
22ED5144:1
- database name "device:[directory]database.RDB;1" [device] (1200,487,0)
- abnormal Record Cache Server termination detected
- starting delete-process shutdown of database:
- %RDMS-F-RCSABORTED, record cache server process terminated abnormally
- sending process deletion to process 22ED10F9
- sending process deletion to process 22ECED59
- sending process deletion to process 22EC0158
- sending process deletion to process 22EB9543 (AIJ Log server)
- database shutdown waiting for active users to terminate
この問題が発生した場合、データベース・バックアップのリストアの後にAIJをロールフォワードしようとする試みは失敗し、バグチェックのダンプが発生します。
現在わかっている、この問題が発生する唯一の状況は、論理名RDM$BIND_RCS_VALIDATE_SECSがある値に定義され、同時に論理名RDM$BIND_RCS_LOG_FILEが未定義であるか、または誤って定義されている場合です。
この問題を防ぐには、ユーザーが行キャッシュ機能を使用する場合、論理名RDM$BIND_RCS_VALIDATE_SECSを定義しないようにするか、またはなんらかの理由でこの論理名を定義する必要がある場合はRDM$BIND_RCS_LOG_FILEが正しく定義されているかどうか（/SYSTEM修飾子と/EXECUTIVE修飾子で定義され、十分な空き領域のある、クラスタからアクセス可能なデバイスの既存のディレクトリにある有効なファイル名を指し示しているかどうか）を確認することをお薦めします。
この推奨事項はすべてのバージョンのOracle Rdbに適用されます。
11.1.2 I64で降順のパーティション索引を使用する場合の不正な結果
Rdbリリース7.2を使用してI64システムで実行する場合、降順のパーティション索引を使用する際に、一部の問合せが不正な結果を返すことがあります。Alphaシステムは、この問題による影響を受けません。
次の例は、降順のパーティション索引を使用する場合のAlphaとI64の動作の違いを示しています。
SQL> CREATE DATABASE FILE FOO
cont> CREATE STORAGE AREA FOOA
cont> CREATE STORAGE AREA FOOB;
SQL>
SQL> CREATE TABLE MESA (ID INTEGER, M4 CHAR (1), M5 INTEGER);
SQL> CREATE TABLE RASA (ID INTEGER, R4 CHAR (1), R5 INTEGER);
SQL>
SQL> INSERT INTO MESA (ID, M4, M5) VALUES (1, 'M', 1 );
1 row inserted
SQL> INSERT INTO RASA (ID, R4, R5) VALUES (1, 'M', 1 );
1 row inserted
SQL>
SQL> CREATE INDEX X4 ON MESA (ID ASC , M4 DESC)
cont> STORE USING (ID, M4)
cont> IN FOOA WITH LIMIT OF (1, 'G')
cont> OTHERWISE IN FOOB ;
SQL>
SQL> CREATE INDEX Y4 ON RASA (ID ASC , R4 DESC)
cont> STORE USING (ID, R4)
cont> IN FOOA WITH LIMIT OF (1, 'G' )
cont> OTHERWISE IN FOOB ;
SQL>
SQL> COMMIT;
! This query correctly returns 1 row
! on Alpha but returns 0 rows on I64:
SQL> SELECT M.ID, M.M4, R.R4 FROM
cont> MESA M INNER JOIN RASA R ON (M.ID = R.ID);
0 rows selected
SQL>
この問題は、Oracle RdbがI64で実行される場合の降順キーの値の構成と比較に関連します。この問題は、Rdb72の将来のリリースで修正される予定です。
11.1.3 RMU再起動プロンプトに対するレスポンスQUITでループが発生する
Oracle Bug#6001187
Itaniumでは、再起動プロンプトに対してQUITで応答すると、RMUコマンドがバグチェックの作成をループします。
この問題はAlphaでは発生しません。Itaniumに関する将来のリリースで修正される予定です。
11.1.4 実在する論理名の処理の変更
このリリースのOracle Rdbでは、Rdb環境の調整に使用する、実在する論理名の処理が変更されます。過去のバージョンでは、これらの実在する論理名をどの値に定義しても有効でした。Rdbドキュメントでは、ほとんどの場合、その値に値1またはYESを使用するように説明されており、今回の変更はこのドキュメントとの上位互換性があります。
Rdbは、これらの論理名（次のリストを参照）をブール型論理として扱い、TRUEを意味するY、y、T、tまたは1で開始する文字列を受け入れます。その他の値はすべてFALSEとみなされます。この変更により、以前は不可能だった、プロセス・レベルの定義で高度な論理名の表の定義を上書きできます。
次の論理名を定義するすべてのプロシージャを確認して、その値がこれらのルールに確実に適合するようにします。これは、予想外の動作の変更を防止するために、Oracle Rdbリリース7.2.1.1以上にアップグレードする前に行います。
OpenVMSバージョン8.3システムでのOracle Rdbリリース7.2.1の機能テスト中に、拡張ロック値ブロックおよびOpenVMS専用CPUロック・マネージャ機能の使用に関する問題が検出されました。
この問題を防ぐために、ユーザーがOracle RdbとOpenVMS専用CPUロック・マネージャ機能をOpenVMSバージョン8.3で使用する場合、OpenVMSバージョン8.3システムでOracle Rdbリリース7.2.1を使用する前に、次のアーキテクチャに固有のいずれかのパッチ・キット（かわっている場合は後続のキット）をインストールすることを強くお薦めします。
Oracle Bug#2351258
Rdb 6.1以前で構築されたSQLモジュールまたはコンパイル済SQLプログラムは、そのプログラムが問合せのパラメータに対するある種の文字列操作を含む問合せを発行する場合にRdb 7.2で実行すると失敗することがあります。たとえば、SQL文のWHERE句のLIKE演算子では、SQLが文字または文字列に一致するワイルドカード文字を検索する必要があります。また、IGNORE CASEを使用すると、使用するキャラクタ・セットの大文字と小文字がSQLで同じになってしまうという例もあります。
次の例は、PERSONNELデータベースに問合せを行うSQLモジュール言語プログラムの一部を示しています。
DECLARE MANL_NAME_LIST CURSOR FOR SELECT DISTINCT E.LAST_NAME,E.FIRST_NAME,J.JOB_CODE,J.DEPARTMENT_CODE,E.CITY FROM DB1_HANDLE.EMPLOYEES E,DB1_HANDLE.JOB_HISTORY J WHERE J.EMPLOYEE_ID = E.EMPLOYEE_ID AND E.STATUS_CODE = STATUS_CODE AND E.CITY LIKE CITYKEY IGNORE CASE ORDER BY E.EMPLOYEE_ID DESC, E.LAST_NAME DESC PROCEDURE SQL_OPN_NAME_LIST SQLCODE CITYKEY CHAR(20) STATUS_CODE CHAR(1); OPEN MANL_NAME_LIST;
前述のコードを含むSQLモジュールがコンパイルされて、7.0より前のバージョンのRdbを使用する実行プログラムにリンクされる場合、このモジュールは該当バージョンに対して適切に実行されます。ただし、同じプログラムがRdb 7.2の環境で実行される場合、SQL_OPN_NAME_LISTプロシージャのコールは、SQLCODE -1を返します。RDB$MESSAGE_VECTORには、次のメッセージに関連するコードが含まれます。
%SQL-F-IGNCASE_BAD, IGNORE CASE not supported for character set
この問題を回避するには、リリース7.2のSQL$INT.EXEまたはSQL$USER.OLB（あるいはその両方）を使用するプログラムを再リンクします。
11.1.7 PTHREAD$RTLにリンクされる外部ルーチンのイメージ
『OpenVMS Guide to the POSIX Threads Library』には、コア・ランタイム・ライブラリの共有可能イメージPTHREAD$RTLを動的にアクティブ化することはサポートされていないと記載されています。Oracleのテストでは、PTHREAD$RTLにリンクされる外部ルーチンとして使用するために提供される共有可能イメージによって、OpenVMS I64システムの動的なイメージをアクティブ化する間にハングする可能性があることがわかりました。この問題はOpenVMS Alphaシステムでは検出されていません。
Rdb外部ルーチンに使用される共有可能イメージがPTHREAD$RTLとリンクされる状況でこの問題を回避するには、主なプログラムのイメージを同様にPTHREAD$RTLとリンクする必要があります。この要件は、ユーザーが構築したアプリケーションの主なプログラムと主な対話型SQLイメージにも適用されます。
OCI Services for Oracle Rdb（SQL/Servicesの一部）で提供された共有可能イメージRDB$NATCONN_FUNC72.EXEは、PTHREAD$RTLとリンクする共有可能イメージの1つです。RDB$NATCONN_FUNC72.EXEイメージから外部ルーチンを使用するユーザー構築プログラムでは、主なイメージがPTHREAD$RTLとリンクしているかどうかを確認する必要があります。ユーザーがコールして、RDB$NATCONN_FUNC72.EXEから関数を使用する外部ルーチンは次のとおりです。
OpenVMSのコマンドANALYZE/IMAGEを使用して、イメージがPTHREAD$RTLに依存するかどうかを判断します。詳細は、OpenVMSのドキュメントを参照してください。
11.1.8 SQLプロシージャの外部の場所は大文字にする
Oracle Bug#4722422
外部ルーチンを使用する場合、同じ共有可能イメージの宣言はすべて、そのイメージ・ファイルの仕様と完全に同じ文字列を使用することが重要です。同じ文字列のコンテンツを使用しないと、イメージの複数のコピーがアクティブ化されるか、または外部ルーチンが正しくコールされません。
ALTER FUNCTION ... LOCATIONコマンドを使用して、関数のドロップや再作成は行わずに、既存の関数の場所の文字列を変更できます。
次の例は、EXTERNAL LOCATION仕様の同じ文字列を示しています。
create procedure sys$asctim(
out :timlen smallint by reference,
out :timbuf char(23) by descriptor,
in :timadr date vms by reference,
in :cvtflag integer by value);
external location 'SYS$SHARE:SYS$PUBLIC_VECTORS.EXE'
language general general parameter style;
create procedure sys$gettim(
in :timadr date vms by reference);
external location 'SYS$SHARE:SYS$PUBLIC_VECTORS.EXE'
language general general parameter style;
Oracle Rdbリリース7.0の形式よりも前のデータベースは、Oracle Rdbリリース7.2の形式に直接変換またはリストアすることはできません。Oracle Rdbリリース7.2のRMU Convertコマンドは、Oracle Rdbリリース7.0およびリリース7.1形式のデータベースからの変換のみをサポートします。Oracle Rdbリリース3.0からリリース6.1の形式のデータベースを使用している場合、最低でもOracle Rdbリリース7.0の形式に変換してから、Oracle Rdbリリース7.2の形式に変換する必要があります。たとえば、Oracle Rdbリリース4.2の形式のデータベースを使用している場合、まず最低でもOracle Rdbリリース7.0の形式に変換してから、Oracle Rdbリリース7.2の形式に変換する必要があります。
Oracle Rdbリリース7.0の形式よりも前のデータベースをOracle Rdbリリース7.2の形式に直接変換またはリストアしようとすると、Oracle RMUでエラーが生成されます。
11.1.10 降順列で照合順序が指定されたパーティション索引
Oracle Bug#2797443
問合せが不正な結果を返すという既知の問題があります（返される行数が正しくありません）。この問題は、複数の列があり、いずれかの列が降順でソートされてその列に照合順序が関連付けられているパーティション索引がある表で発生することがあります。
次の例を使用して、問題を示すことができます。
$ sql$
create database file mf_collating.rdb alloc 10
collating sequence french french
create storage area area1 alloc 10
create storage area area2 alloc 10
create storage area area3 alloc 10;
create table tab1 (id tinyint, r3 char (3));
insert into tab1 (id, r3) values (1, 'a');
insert into tab1 (id, r3) values (1, 'b');
insert into tab1 (id, r3) values (1, 'f');
create index y3 on tab1 (id asc, r3 desc)
store using (id, r3)
in area1 with limit of (1, 'k')
in area2 with limit of (1, 'e')
otherwise in area3 ;
commit;
set flags 'strategy';
! Here is a query that returns the correct rows using sequential rather
! than indexed access.
select id, r3 from tab1 where id = 1 and r3 <= 'e'
optimize for sequential access;
Conjunct Get Retrieval sequentially of relation TAB1
ID R3
1 a
1 b
2 rows selected
! Here is the same query without the sequential access restriction.
! Note in the query strategy that index Y3 is used for data retrieval.
! This query ought to (but does not) return the same set of rows as
! for the sequential access query.
select id, r3 from tab1 where id = 1 and r3 <= 'e';
Leaf#01 FFirst TAB1 Card=3
BgrNdx1 Y3 [2:1] Fan=16
0 rows selected
Oracle Bug#3735144
Oracle Rdbリモート接続にTCP/IPを使用する場合、同じサブネットではないノードのデータベースを含む分散トランザクションが機能しないことがあります。
リモートのRdbは、DECnetではなくTCP/IPを介してリモート接続を可能にします。（この設定方法については、Oracle Rdb OpenVMSのインストレーションおよび構成ガイドを参照してください。）ただし、TCP/IPを介して接続されたリモート・データベースを含む分散トランザクションには問題がありました。これは、Rdbが分散トランザクション・サポートのOpenVMS DECdtmに依存し、DECdtmではオフノード通信にDECnetが必要であるためです。（これはRdbの制限事項ではなくOpenVMSの制限事項です。詳細は、Hewlett-Packard社のOpenVMSサポートに連絡してください。）
TCP/IPネットワークが通信の重要な要素として使用される環境で、DECnet（DECdtmなど）を必要とするOpenVMSサービスが機能するように、OpenVMSにはTCP/IPを介してDECnetを実行する機能があります。この機能を使用すると、DECdtm（およびRdb）はTCP/IPで分散トランザクションを管理できます。（この機能の構成と使用の方法については、HP社のOpenVMS DECnet-Plusのドキュメント・セットを参照してください。）
ただし、リモート・データベースに関連するトランザクションの場合、RdbはDECdtmにのみリモート・ノードのSCSNODE名を提供します。たとえば、次のSQLがTCP/IPを使用して2つのリモート・データベースにアタッチする状況について考えます。
SQL> attach 'alias db1 filename node1.a.b.c::db_root:db1 user ''me'' using ''pw'''; SQL> attach 'alias db2 filename node1.a.b.c::db_root:db2 user ''me'' using ''pw''';
前述の例では、RdbはTCP/IPアドレスnode1.a.b.c.を使用して両方のリモート・データベースに正常に接続できますが、複数のデータベースをアタッチする場合、RdbはDECdtmを介して分散トランザクションを暗黙的に使用します。Rdbは接続の相手側のRDBSERVERnnから取得したSCSNODE名のみをDECdtmに渡すため、通常、DECdtmにはリモート参照を解決するために必要な情報はありません。SCSNODE名とTCP/IPノード名が同じでローカル・ノードが同じサブネット（例では.a.b.c）上にある場合、このようにするしかありません。それ以外の場合は、2番目のアタッチの後に、トランザクションを開始するとすぐに次のエラー・メッセージが発生します。
SQL> set trans read write; %RDB-F-SYS_REQUEST_CAL, error from system services request - called from 100001 -RDB-E-DECDTMERR, DECdtm system service call error -IPC-E-BCKTRNSFAIL, failure on the back translate address request
3つの考えられる回避策があります。
$ TCP SET HOST NODE1.A.B.C/address=nnn.nnn.nnn.nnn/alias=NODE1_SCS
複数のモジュールを使用するアプリケーションをリンクする場合、次のエラー・メッセージが返されることがあります。
%ILINK-E-INVOVRINI, incompatible multiple initializations for overlaid section
section: VMSRDB
module: M1
file: DKA0:[BLD]M1.OBJ;1
module: M2
file: DKA0:[BLD]SYS.OLB;1
I64システムでは、後で初期化されるプログラム・セクションで、初期化のゼロ以外の部分が一致しないことは許可されません。リンカーがこのような初期化を許可するOpenVMS AlphaシステムやVAXシステムとは異なります。
指定したモジュールがSQLモジュール言語または生成されたプリコンパイラの場合、アプリケーションで構築されたプロシージャは通常変更する必要があります。一般的には、データベースを初期化するソリューションは、いずれかのモジュールのみで処理します。SQLMODコマンドライン修飾子/NOINITIALIZE_HANDLESおよび/INITIALIZE_HANDLESは、エイリアス定義がエイリアス参照に強要されるかどうかを指定するために使用されます。
11.1.13 以前のバージョンとの互換性がない、RMU/LOADで保存される新しい属性
Oracle Bug#2676851
Oracle Rdbリリース7.1.2では、ビューをアンロードする動作を改善するために、ビュー列のアンロード方法が変更されました。これにより、ビューの計算列COMPUTED BY列およびAUTOMATIC列の属性が保存されるようになりました。これらの新しい属性は、以前のリリースのOracle Rdbでは受け入れられません。
次の例は、リリース7.1.0.4でリリース7.1.2のファイルをロードしようするとレポートされるエラーを示しています。
%RMU-F-NOTUNLFIL, Input file was not created by RMU UNLOAD %RMU-I-DATRECSTO, 0 data records stored. %RMU-F-FTL_LOAD, Fatal error for LOAD operation at 21-OCT-2003 16:34:54.20
この問題を回避するには、/RECORD_DEFINITION修飾子を使用してFORMAT=DELIMITEDオプションを指定します。ただし、この方法はLIST OF BYTE VARYING列のアンロードはサポートしていません。
11.1.14 Galaxy環境でSHARED MEMORY IS SYSTEMまたはLARGE MEMORY IS ENABLEDを使用する場合の致命的エラーSYSTEM-F-INSFMEM
OpenVMS Galaxy環境でGALAXY SUPPORT IS ENABLED機能を使用する場合、レコード・キャッシュをマップするか、またはデータベースを開くときに「%SYSTEM-F-INSFMEM, insufficient dynamic memory error」が返されることがあります。Galaxy構成に固有のこの問題では、Galaxy共有メモリー・リージョンを使い果していることが原因の1つです。Galaxyシステムの場合、GLX_SHM_REGは、Galaxy Management Database（GMDB）に構成された共有メモリー・リージョンの構造の数を表します。
64リージョンというデフォルト値（少なくともリリース7.3-1までのOpenVMSの場合）は、一部のインストールでは十分ですが、SHARED MEMORY IS SYSTEM機能またはLARGE MEMORY IS ENABLED機能が有効な場合に多くのデータベースや行キャッシュを使用するサイトでは、このデフォルトでは不十分であることがわかっています。
レコード・キャシュをマップしたり、データベースを開くときに「%SYSTEM-F-INSFMEM, insufficient dynamic memory error」が返される場合、GLX_SHM_REGパラメータを、行キャッシュの数と、一度にGalaxyでアクセスできるデータベースの数の合計の2倍に増やすことをお薦めします。Galaxy共有メモリー・リージョンの構造がそれほど大きくない場合、このパラメータを必要な値より高く設定しても、物理メモリーが大幅に消費されることはありません。また、Galaxy環境を後から再起動することも避けられます。このパラメータはGalaxyのすべてのノードで設定する必要があります。
Galaxyの再起動が必要
GLX_SHM_REGシステム・パラメータを変更する場合、OpenVMS Galaxy環境を最初から起動する必要があります。つまり、Galaxyのすべてのノードを停止してから、各インスタンスを開始してGalaxyを再構築する必要があります。
OpenVMSリリース7.2では、2つの主なコンポーネントで構成される拡張ファイル仕様の機能が導入されました。
Advanced Server for OpenVMS 7.2（以前のPATHWORKS for OpenVMS）、DCOMおよびJAVAアプリケーションのユーザーに対して、機能を共有する拡張ファイルを提供することを主な目的としてODS-5が導入されました。
Oracle Rdbは各自のファイルとディレクトリ名の解析を実行し、ODS-2（OpenVMSの従来のボリューム構造）ファイルとディレクトリ名の表記規則に明示的に従う必要があります。このため、Oracleでは、ODS-2以外のファイル命名規則の機能を使用するOracle Rdbデータベースのファイル・コンポーネント（ルート・ファイル、記憶域ファイル、アフター・イメージ・ジャーナル・ファイル、レコード・キャッシュのバックエンドのデータストア・ファイル、データベース・バックアップ・ファイル、アフター・イメージ・ジャーナルのバックアップ・ファイルなど）をサポートしていません。このような理由で、Oracle RdbデータベースのコンポーネントをODS-5ボリュームに配置しないことをお薦めします。
Oracle Rdbで使用するこのようなファイルとディレクトリがすべてODS-2のファイルとディレクトリ名の表記規則に厳密に従っている場合は、ODS-5ボリューム上のOracle Rdbデータベースのファイル・コンポーネントがサポートされます。特に、すべてのファイル名は全体を大文字で指定してください。ファイル名やディレクトリ名で特殊文字を使用することは禁止されています。
11.1.16 チェック制約の最適化
Oracle Bug#1448422
CHECK構文を使用して制約を表す場合、同じまたは類似した制約が参照整合性（PRIMARYとFOREIGN KEY）制約を使用して表現される場合よりも質の悪いストラテジがオプティマイザによって選択されることがあります。
たとえば、T1およびT2という2つの表があり、どちらの表にも1つの列があります。表T1のすべての値がT2に存在することを確認するとします。どちらの表にも参照フィールドに索引があります。T2ではPRIMARY KEY制約を使用し、T1ではFOREIGN KEY制約を使用します。
SQL> alter table t2 alter column f2 primary key not deferrable; SQL> alter table t1 alter column f1 references t2 not deferrable;
PRIMARY KEY表から削除する場合、RdbはFOREIGN KEYに削除された値があるFOREIGN KEY表の行のみをチェックします。これは、検索ストラテジでT1の索引の検索として示されます。
SQL> delete from t2 where f2=1; Get Temporary relation Retrieval by index of relation T2 Index name I2 [1:1] Index only retrieval of relation T1 Index name I1 [1:1] %RDB-E-INTEG_FAIL, violation of constraint T1_FOREIGN1 caused operation to fail
制約の失敗は重要ではありません。重要なのは、T2で削除された行と同じ値を持つT1の行のみが影響を受けることをRdbが効率的に検出することです。
CHECK制約を使用してこのようなリレーションシップを定義することが必要な場合があります。これは、表T2にNULL値があるためにその表の主キーの定義が排除されるため必要になります。これは次の形式のCHECK制約で実行されます。
SQL> alter table t1 alter column f1
cont> check (f1 in (select * from t2)) not deferrable;
SQL> delete from t2 where f2=1;
Get Temporary relation Retrieval by index of relation T2
Index name I2 [1:1]
Cross block of 2 entries
Cross block entry 1
Index only retrieval of relation T1
Index name I1 [0:0]
Cross block entry 2
Conjunct Aggregate-F1 Conjunct
Index only retrieval of relation T2
Index name I2 [0:0]
%RDB-E-INTEG_FAIL, violation of constraint T1_CHECK1 caused operation to fail
cross blockは、制約の評価に使用されます。この検索ストラテジは、制約を評価するために、表T1の索引全体をスキャンして、キーごとに表T2の索引全体をスキャンすることを示しています。この動作は、制約のselect句の等式結合条件を使用してある程度改善できます。
SQL> alter table t1 alter column f1 cont> check (f1 in (select * from t2 where f2=f1)) not deferrable; or: SQL> alter table t1 alter column f1 cont> check (f1=(select * from t2 where f2=f1)) not deferrable;
どちらの場合も、検索ストラテジは次のようになります。
SQL> delete from t2 where f2=1;
Get Temporary relation Retrieval by index of relation T2
Index name I2 [1:1]
Cross block of 2 entries
Cross block entry 1
Index only retrieval of relation T1
Index name I1 [0:0]
Cross block entry 2
Conjunct Aggregate-F1 Conjunct
Index only retrieval of relation T2
Index name I2 [1:1]
%RDB-E-INTEG_FAIL, violation of constraint T1_CHECK1 caused operation to fail
T1の索引全体のスキャン中に、少なくともT1の値がT2の索引検索の実行に使用されます。
これらの制限事項は、NULL処理に関するIN操作とEXISTS操作の動作のセマンティックの違いと、等式以外の結合条件を扱う複雑さに起因します。
比較的大きな表でこのようなタイプの整合性チェックの実行を改善するには、制約チェックを実行する一連のトリガーを使用できます。次のトリガーは、前述の制約に対して類似するチェックを実行します。
SQL> create trigger t1_insert after insert on t1 cont> when (not exists (select * from t2 where f2=f1)) cont> (error) for each row; SQL> create trigger t1_update after update on t1 cont> when (not exists (select * from t2 where f2=f1)) cont> (error) for each row; SQL> ! A delete trigger is not needed on T1. SQL> create trigger t2_delete before delete on t2 cont> when (exists (select * from t1 where f1=f2)) cont> (error) for each row; SQL> create trigger t2_modify after update on t2 cont> referencing old as t2o new as t2n cont> when (exists (select * from t1 where f1=t2o.f2)) cont> (error) for each row; SQL> ! An insert trigger is not needed on T2.
T2での削除ストラテジは次のようになりました。
SQL> delete from t2 where f2=1; Aggregate-F1 Index only retrieval of relation T1 Index name I1 [1:1] Temporary relation Get Retrieval by index of relation T2 Index name I2 [1:1] %RDB-E-TRIG_INV_UPD, invalid update; encountered error condition defined for trigger -RDMS-E-TRIG_ERROR, trigger T2_DELETE forced an error
トリガーのストラテジは、最初に索引のみの検索を表示しています。T1の索引が、削除で影響を受ける行のみを確認するために使用されることに注意してください。
この回避策を使用する場合、トリガーの操作、INとEXISTSの使用、参照整合性制約の使用でセマンティックの違いがあることに注意する必要があります。
この回避策は、制約の形式がより複雑で、参照整合性制約を使用して表すことができない場合に役立ちます。たとえば、アプリケーションが表T1の値を、値がないことを示す空白またはNULLのように使っている場合、このようなセマンティックを許容するために前述のトリガーを簡単に変更できます。
11.1.17 キャリーオーバー・ロックとNOWAITトランザクションの明確化
NOWAITトランザクションで、BLAST（ブロッキングAST）メカニズムは使用できません。ブロッキング・ユーザーがBLASTシグナルを受け取るには、リクエストするユーザーは、ロックするリソースをWAITでリクエストする必要があります（NOWAITトランザクションは行いません）。Oracle Rdbは、NOWAITというリソースを定義します。NOWAITは、NOWAITトランザクションが開始されたことを示すために使用されます。NOWAITトランザクションが開始すると、ユーザーはNOWAITリソースをリクエストします。他のすべてのデータベース・ユーザーは、NOWAITトランザクションの開始時に、他のすべてのユーザーにNOWAITのBLASTが通知されるようにNOWAITリソースをロック状態にします。BLASTにより、ブロッキング・ユーザーはキャリーオーバー・ロックを解放します。キャリーオーバー・ロックのトランザクションがNOWAITトランザクションの存在を検出して、そのキャリーオーバー・ロックを解放するまでに遅延が発生することがあります。この状態を検出するには、ストール・メッセージを確認します。ストール・メッセージ「Waiting for NOWAIT signal (CW)」が頻繁に表示される場合、アプリケーションのパフォーマンスが低下している可能性があるため、キャリーオーバー・ロックの動作を無効にすることを検討してください。
11.1.18 ホット・スタンバイ・データベースでの読取りトランザクションで予期しない結果が発生する
ホット・スタンバイを使用する場合、スタンバイ・データベースは、レポートの作成、簡単な問合せ、およびその他の読取り専用トランザクションの目的で使用することが一般的です。スタンバイ・データベースでこのような読取り専用トランザクションを実行している場合、分離レベルREAD COMMITを許容できることを確認します。これは、読取り専用トランザクションが終了する前にホット・スタンバイ・データベースが別のトランザクションで更新され、取得されたデータが想定したものとは異なる可能性があるためです。
ホット・スタンバイがスナップショット・ファイルに書き込まれず、読取り専用トランザクションについてスタンバイ・データベースで達成する分離レベルがREAD COMMITEDトランザクションであるためです。つまり、読取り専用トランザクションでノンリピータブル・リードとファントム・リードが許容されます。
そのため、スタンバイ・データベースからのデータの読取りが変化しないことを保証することはできません。スタンバイ・データベースからデータを読み取って使用するプロシージャを実装する前に、読取り専用トランザクションが分離レベルREAD COMMITを許容できることを確認します。
11.1.19 SYS$HIBERを使用するアプリケーションとOracle Rdb
Oracle Rdbと$HIBERシステム・サービスを使用するアプリケーション・プロセス（場合によっては、LIB$WAITなどのRTLルーチン、またはPTHREAD$RTLを使用するマルチスレッド・プロセス（JAVAベースなど）を使用する）では、待機中のイベントが実際に発生したかどうかをアプリケーションで確認する必要があります。Oracle Rdbは、プロセス間通信に$HIBER/$WAKEシーケンスを使用します。
Oracle Rdbで$WAKEシステム・サービスを使用すると、$HIBERの他のユーザー（RTLルーチンLIB$WAITなど）が妨げられることがあります。$HIBERの他のユーザーはイベントの完了をチェックしないため、$HIBERがまったく待機せず予想外に再開する場合があります。それ以外の場合、SYS$HIBERサービスの1つのコール元が、他のSYS$WAKEに対して意図された警鐘または保留中の警鐘を消費することがあります。Rdbを使用する場合、そのRdbでSYS$HIBER/SYS$WAKEを使用すると、内部アクセス・モードで発生する可能性が高くなります。
このような状況を防ぐには、操作（遅延やタイマーの発動など）の完了をチェックしないで続行しないようにするコード・シーケンスを使用するアプリケーションの変更を検討します。アプリケーション内でhiber/wakeを使用するには、常に疑似警鐘を扱うように正しくコード化する必要があります。
次の疑似コードは、timed-waitが正常に完了したことを示すためのフラグの使用状況を示しています。この待機は、タイマーが実際に発動してTIMER_FLAGをTRUEに設定するまで完了しません。このコードは、ASTが有効であるかどうかに依存します。
OWN WAKEFLG : VOLATILE; ! Volatile to force memory fetch
ROUTINE TIMER_WAIT:
BEGIN
WAKEFLG = FALSE ! Clear timer flag
! Schedule an AST for sometime in the future
STAT = SYS$SETIMR (TIMADR = DELTATIME, ASTRTN = TIMER_AST)
IF STAT <> SS$_NORMAL THEN LIB$SIGNAL (STAT)
! Hibernate. When the $HIBER completes, check to make sure
! WAKEFLG is set indicating that the wait has finished.
WHILE WAKEFLG = FALSE DO SYS$HIBER()
END
ROUTINE TIMER_AST:
BEGIN
WAKEFLG = TRUE ! Set flag indicating timer expired
STAT = SYS$WAKE () ! Wake the main-line code
IF STAT <> SS$_NORMAL THEN LIB$SIGNAL (STAT)
END
OpenVMS LIB$WAITルーチンを使用して、代替の待機方法（$SYNCHシステム・サービスを使用）を可能にする場合、LIB$K_NOWAKEフラグを指定できます。この代替の待機方法では、$HIBERシステム・サービスを使用する複数のコード・シーケンスに関連する問題を防止できます。
アプリケーションのハングを防止するには、SYS$HIBERの内部モード・ユーザーが追加の手順を実行して、保留中の警鐘が誤って消費されないようにする必要があります。これを実行するには、SYS$HIBERのコールが行われた場合、イベントの完了後、プロセスにSYS$WAKEを発行するのが一般的な方法です。Rdbがこの手順を実行するため、警鐘が予期せず表示される場合に備えて、アプリケーション・プログラムを準備しておく必要があります。
11.1.20 ホット・スタンバイのレプリケーションがアクティブの場合、行キャッシュが許可されない
レプリケーションがアクティブの場合、行キャッシュ機能をホット・スタンバイ・データベースで有効にできません。行キャッシュが有効な場合、ホット・スタンバイ機能は開始されません。
この制限があるのは、論理dbkeysから行キャッシュの行にアクセスされるためです。ただし、アフター・イメージ・ジャーナルからスタンバイ・データベースに変換される情報には物理dbkeysのみが含まれます。ホット・スタンバイ処理によってキャシュに行を維持する方法がないため、スタンバイ・データベースが開いていてレプリケーションがアクティブな場合、行キャッシュを無効にする必要があります。
新しいコマンド修飾子ROW_CACHE=DISABLEDがRMU Openコマンドに追加されました。レプリケーションを開始する前にホット・スタンバイ・データベースを開くには、RMU OpenコマンドでROW_CACHE=DISABLED修飾子を使用します。
11.1.21 Oracle Rdbのソート時の多すぎるプロセス・ページ・フォルトとパフォーマンスのその他の考慮事項
ハード・ページ・フォルトまたはソフト・ページ・フォルトが多すぎると、プロセス・パフォーマンスを制限する要因となります。Oracle Rdbのプロセス・ページ・フォルトの一因はソート操作です。ソートのよくある原因として、問合せに指定したSQLのGROUP BY句、ORDER BY句、UNION句、DISTINCT句、索引作成操作などがあります。論理名RDMS$DEBUG_FLAGSをRSに定義すると、Oracle Rdbのソート操作の発生のタイミングと、ソート・キーおよび統計の表示の決定に役立ちます。
Oracle Rdbには、Oracle Rdbイメージ内にOpenVMS SORT32コードの独自のコピーが含まれ、通常、OpenVMSランタイム・ライブラリのルーチンをコールしません。SORT32コードのコピーを使用すると、Oracle RdbとOpenVMSのバージョン間の安定性が得られます。Oracle Rdbは、SORT32の共有可能イメージを使用して実行することが困難なエグゼクティブ・プロセッサ・モードからソート・ルーチンをコールするためです。SQL IMPORT操作およびRMU Load操作は実行しますが、OpenVMS SORTランタイム・ライブラリをコールします。
ソート操作の開始時に、SORTコードは作業領域にメモリーを割り当てます。SORTコードは、バッファ、データのメモリー内コピー、ツリーのソートにこの領域を使用します。
SORTは、メモリーを割り当てるときにプロセスの割当て量やパラメータを直接検討しません。WSQUOTAおよびWSEXTENTによる影響は間接的なものです。各ソート操作の開始時に、SORTコードは、$ADJWSLシステム・サービスを使用して、リクエストされた作業セットの制限を%X7FFFFFFFページ（最大可能数）に指定し、プロセス作業セットを最大可能サイズに調整しようとします。SORTは、仮想メモリーのスクラッチ領域に対して、返された作業セットの値75%を使用します。スクラッチ領域は初期化され、ソートが開始します。
スクラッチ領域の初期化により、通常、作業セットにページが新たに追加され、ページフォルトが発生します。新しいページがフォルトインすると、すでに作業セットにあったページはフォルトアウトします。ソート操作が完了してSORTがOracle Rdbに戻ると、作業セットからフォルトアウトしたページは、作業セットにフォルトバックします。
プロセス作業セットが作業セットの割当て（WSQUOTA）パラメータで制限され、作業セットの範囲（WSEXTENT）パラメータがより大きな値である場合、ソート・ルーチンを最初にコールすると、作業セットが大きくなるにつれて多くのページ・フォルトが発生します。WSEXTENTの値をWSQUOTAに近い値にすると、この影響が軽減されます。
一部のOpenVMSバージョンの場合、AUTOGENは、SYSGENパラメータPQL_MWSEXTENTをWSMAXパラメータと同じに設定します。つまり、システム上のすべてのプロセスが、WSMAXと同じWSEXTENTで終了します。この値はかなり高いため、ソートによって過度のページ・フォルトが発生します。この状況が使用するシステムで発生する場合、PQL_MWSEXTENTの値を明示的に低く設定します。
ソート作業ファイルは、Oracle Rdbのソート操作の調整時に検討するもう1つの要素です。使用可能なメモリーで操作を実行できない場合、SORTは一時ディスク・ファイルを使用して、ソートするデータを保持します。ソート作業ファイルの詳細は、『Oracle Rdb7データベース・パフォーマンスおよびチューニングのためのガイド』を参照してください。
論理名RDMS$BIND_SORT_WORKFILESは、作業ファイルが必要な場合に使用する作業ファイルのソートの数を指定します。デフォルトは2で、最大数は36です。作業ファイルは、SORTWORKn論理名でそれぞれ制御できます（nの範囲は0〜Z）。ソート操作の効率を上げるには、一時ソート作業ファイルの場所を異なるディスクに割り当てます。これらの割当ては、最大で36の論理名（SORTWORK0〜SORTWORKZ）を使用して行われます。
通常、SORTはSYS$SCRATCHディレクトリに作業ファイルを配置します。デフォルトでは、SYS$SCRATCHはSYS$LOGINの場所と同じデバイスとディレクトリです。複数のディスクまたはコントローラ（あるいはその両方）にI/O負荷を分散すると、より多くのシステム・リソースを利用することで効率とパフォーマンスが向上し、ディスクI/Oのボトルネックの防止に役立ちます。作業ファイルが別々のディスクに配置されるように指定すると、SORTの読取り/書込みのサイクルの重複が許可されます。SYS$SCRATCHディスク・デバイスに十分な領域が存在しない場合もあります（たとえば、Oracle Rdbがきわめて大きな表の索引を構築しているときなど）。論理名SORTWORK0からSORTWORKZを使用すると、この問題の防止に役立ちます。
SORTでは様々なソートの実行に作業ファイルを使用し、そのソートの実行をより大きなグループにマージすることに注意してください。ソース・データがほとんどソートされる場合、すべてのソート作業ファイルにアクセスする必要はありません。これは、36のソート作業ファイルを使用する場合でも、最初のSORTファイルのデバイスの容量を超えて、残りの35のソート作業ファイルにアクセスせずにソート操作が失敗することがあり、混乱の原因となる可能性があります。
この時点では、CREATE INDEX、ALTER INDEX、およびUNION DISTINCT句、ORDER BY句、GROUP BY句、SELECT DISTINCT句で使用されるものとして、10を超えるソート作業ファイルのみがOracle Rdbのソート・インタフェースで使用されます。RMUインタフェースおよびSQL IMPORTインタフェースは、OpenVMS SORTインタフェースを使用しますが、このインタフェースは、現在10を超えるソート作業ファイルをサポートしていません。
論理名RDMS$BIND_WORK_VMおよびRDMS$BIND_WORK_FILEはソート操作に影響を与えることはありません。あるいは、ソート操作を制御することはありません。これらの論理名を使用して、Oracle Rdb内のその他の一時領域の割当てを制御します。
11.1.22 ソート作業のメモリー割当ての制御
Oracle Rdbは、組込みのSORT32パッケージを使用して多くのソート操作を実行します。ソートに使用する作業メモリーを初期化する際に、これらのソートによって重大なパフォーマンスの問題が示されることがあります。この動作は、たとえば、ソートのカーディナリティがかなり高く見積られる場合（ただし、実際のソートのカーディナリティは低い）に発生することがあります。
ソート・パッケージによる作業メモリーの使用を人為的に制限することが望ましい場合があります。この制御を行うために、2つの論理が作成されました。通常、これらの論理名のいずれかを使用する必要はありません。これらの論理名を誤って使用すると、ソートのパフォーマンスに重大な影響を及ぼす可能性があります。これらの論理を注意深く慎重に使用することをお薦めします。
| 論理 | 定義 |
|---|---|
| RDMS$BIND_SORT_MEMORY_WS_FACTOR | 組込みのSORT32パッケージにソート・メモリーを割り当てる際に、使用するプロセスの作業セットの制限の割合を指定します。定義しない場合、デフォルト値は75（75%を表す）、最大値は75（75%を表す）、最小値は2（2%を表す）になります。かなり大きな作業セットの制限があるプロセスでは、ソート・メモリーを初期化している間にかなりの数のページ・フォルトが発生し、CPUを著しく消費することがあります。この論理名は、ソートの作業メモリーをプロセスの最大作業セットの割合に制限できます。 |
| RDMS$BIND_SORT_MEMORY_MAX_BYTES | 組込みのSORT32パッケージにソート・メモリーを割り当てる際に、使用する絶対的な制限を指定します。定義しない場合、デフォルト値は無制限（最大で1GB）、最大値は2147483647、最小値は32768になります。 |
カーソルが表から選択された行を処理している場合、別の問合せがそのカーソルで使用する索引列のキー値を変更して、カーソルの検索を妨害することがあります。
たとえば、カーソルがLAST_NAME >= 'M'のすべてのEMPLOYEESを選択する場合、問合せはLAST_NAMEでソート索引を使用してカーソルの行を検索します。MasonからRickardまでの従業員のLAST_NAMEを変更するカーソルの処理時に更新が行われる場合、従業員の行は2回処理される可能性があります。最初に名前Masonでフェッチし、次に新しい名前Rickardでアクセスされます。
ハロウィーン問題は、リレーショナル・データベースでよく知られている問題です。I/Oの要件を最適化するアクセス・ストラテジ（索引検索など）では、この問題に陥る傾向があります。他のセッションによる問合せの妨害はロックで防ぎ、SQLのISOLATION LEVELオプションまたはRDO/RDMLのCONCURRENCY/CONSISTENCYで制御します。
Oracle Rdbがカーソルのサブジェクト表の更新を認識する場合、この問題は防止されます。たとえば、SQLの構文UPDATE ... WHERE CURRENT OFを使用してターゲット行の更新を実行するか、またはRDO/RDML MODIFY文がストリームにコンテキスト変数を使用するとします。この場合、ハロウィーン問題の原因となる更新が行われると、オプティマイザはかわりのアクセス・ストラテジを選択します。これは、カーソルの問合せの結果を保持するために一時リレーションが作成される例2-2のアクセス・ストラテジで確認できます。
対話型SQLまたは動的SQLを使用する場合、UPDATE ... WHERE CURRENT OF文またはDELETE ... WHERE CURRENT OF文は、カーソルが宣言されて開かれるまで表示されません。これらの環境では、FOR UPDATE句を使用して、カーソルで選択された列がカーソルの処理時に更新されるように指定する必要があります。この場合、これがハロウィーン問題に対して保護するためのRdbオプティマイザへの指示となります。例2-1および例2-2でこれを示します。
次の例は、EMP_LAST_NAME索引が検索に使用される状況を示しています。実行される更新は、場合によってはハロウィーン問題に陥ります。
SQL> set flags 'strategy'; SQL> declare emp cursor for cont> select * from employees where last_name >= 'M' order by last_name; SQL> open emp; Conjunct Get Retrieval by index of relation EMPLOYEES Index name EMP_LAST_NAME [1:0] SQL> close emp;
次の例は、列LAST_NAMEが後の問合せで更新されるように問合せが指定する状況を示しています。問合せの結果セットを保持するために一時リレーションを使用することで、オプティマイザが検索に使用するEMP_LAST_NAME索引を保護します。LAST_NAMEに対して実行される更新は、ハロウィーン問題を防止するようになりました。
SQL> set flags 'strategy'; SQL> declare emp2 cursor for cont> select * from employees where last_name >= 'M' cont> order by last_name for update of last_name; SQL> open emp2; Temporary relation Conjunct Get Retrieval by index of relation EMPLOYEES Index name EMP_LAST_NAME [1:0] SQL> close emp2;
SQLプリコンパイラまたはSQLモジュール言語コンパイラを使用する場合、カーソルに関連するすべての文がモジュール内に存在するため、カーソルのコンテキストはそのカーソルの処理時に更新される可能性があることが判断できます。DECLARE_STREAM文とSTART_STREAM文、および同じストリーム・コンテキストを使用してすべてのMODIFY文とERASE文を実行する場合、これはRDML/RDBPREプリコンパイラにも当てはまります。
ここで、後続のUPDATEまたはDELETEのときではなく、SQLカーソル（またはRDOストリーム）を開くときに保護が有効になることに注意してください。
カーソルからフェッチされる行を変更する個々のUPDATE問合せを実行する場合、フェッチされる実際の行は、Rdbオプティマイザで選択されるアクセス・ストラテジによって異なります。問合せをカーソルの問合せと区別する場合（つまり、カーソルのコンテキストを参照しない）、オプティマイザは、カーソルが選択した行が更新されることを認識しないため、ハロウィーン問題に対する通常の保護を行うことができません。
11.2 SQLの既知の問題と制限事項
この項では、SQLインタフェースの既知の問題と制限事項について説明します。
11.2.1 設定フラグCRONO_FLAGの削除
SET FLAGS文とRDMS$SET_FLAGS論理名は、古いキーワードCRONO_FLAGを受け入れなくなりました。このキーワードは削除されました。キーワードCHRONO_FLAGを使用するにはすべてのスクリプトとアプリケーションを更新してください。
11.2.2 Oracle Rdbリリース7.2で作成された交換ファイル（RBR）は以前のリリースと互換性がない
データベースの新しい属性とオブジェクトを数多くサポートするために、SQL EXPORTとSQL IMPORTで使用するプロトコルが拡張され、より多くのプロトコル・タイプをサポートするようになりました。そのため、Oracle Rdbリリース7.2の交換ファイルの形式は、古いバージョンのOracle Rdbで読み取ることができなくなりました。
Oracle Rdbは、古いバージョンで生成された交換ファイルの上位互換性を引き続き提供します。
Oracle Rdbは下位互換性をサポートしませんが、古いバージョンのIMPORTを含む交換ファイルを使用することがありました。ただし、このプロトコルの変更によって、この交換ファイルの使用が許可されなくなりました。
11.2.3 単一文LOCK TABLEがSQLモジュール言語およびSQLプリコンパイラに対してサポートされない
新しいLOCK TABLE文は、モジュール言語内または埋込みSQL言語コンパイラ内の単一文として現在サポートされていません。
かわりに、複合文でこの文を囲む必要があります。つまり、次の例に示すように、この文の前後でBEGIN... ENDを使用します。この形式では、LOCK TABLEのすべての構文と柔軟性が提供されます。
この制限事項は、対話型SQLや動的SQLには適用されません。
モジュール言語リスト・ファイルから抽出された次の内容は、LOCK TABLEを単一文のプロシージャとして使用する場合にレポートされるエラーを示しています。同じモジュールの他のプロシージャは、LOCK TABLE文を含む複合文を使用するため受け入れられます。
1 MODULE sample_test 2 LANGUAGE C 3 PARAMETER COLONS 4 5 DECLARE ALIAS FILENAME 'mf_personnel' 6 7 PROCEDURE a (SQLCODE); 8 LOCK TABLE employees FOR EXCLUSIVE WRITE MODE; %SQL-F-WISH_LIST, (1) Feature not yet implemented - LOCK TABLE requires compound statement 9 10 PROCEDURE b (SQLCODE); 11 BEGIN 12 LOCK TABLE employees FOR EXCLUSIVE WRITE MODE; 13 END;
SQLモジュール言語または埋込みSQLアプリケーションにLOCK TABLEを使用する場合に発生するこの問題を回避するには、EXEC SQL文で複合文を使用します。
11.2.4 複数文またはストアド・プロシージャが原因でハングする
長期間実行している複数文またはストアド・プロシージャでは、そのプロシージャがデータベースの他のユーザーに必要なリソースを取得する場合、その他のユーザーがハングすることがあります。複数文またはストアド・プロシージャの実行で取得されるリソースは、その複数文またはストアド・プロシージャが終了するまで解放されません。そのため、長期間実行している複数文またはストアド・プロシージャが原因で他のプロセスがハングすることがあります。この問題は、文にSQL COMMIT文またはROLLBACK文が含まれている場合でも発生する可能性があります。
次の例は、問題を示しています。最初のセッションが無限ループに陥り、2番目のセッションがデータベースをバックアップしようとしますが、永久にハングします。
Session 1:
SQL> attach 'filename MF_PERSONNEL';
SQL> create function LIB$WAIT (in real by reference)
cont> returns integer;
cont> external name LIB$WAIT location 'SYS$SHARE:LIBRTL.EXE'
cont> language general general parameter style variant;
SQL> commit;
.
.
.
$ SQL
SQL> attach 'filename MF_PERSONNEL';
SQL> begin
cont> declare :LAST_NAME LAST_NAME_DOM;
cont> declare :WAIT_STATUS integer;
cont> loop
cont> select LAST_NAME into :LAST_NAME
cont> from EMPLOYEES where EMPLOYEE_ID = '00164';
cont> rollback;
cont> set :WAIT_STATUS = LIBWAIT (5.0);
cont> set transaction read only;
cont> end loop;
cont> end;
Session 2:
$ RMU/BACKUP/LOG/ONLINE MF_PERSONNEL MF_PERSONNEL
From a third session, you can see that the backup process is waiting for a lock
held in the first session:
$ RMU/SHOW LOCKS /MODE=BLOCKING MF_PERSONNEL
.
.
.
Resource: nowait signal
ProcessID Process Name Lock ID System ID Requested Granted
--------- --------------- --------- -------- --------- -------
20204383 RMU BACKUP..... 5600A476 00010001 CW NL
2020437B SQL............ 3B00A35C 00010001 PR PR
この制限事項の回避策はありません。複数文またはストアド・プロシージャの実行が終了すると、他のプロセスで必要なリソースが解放されます。
11.2.5 共有可能イメージからのOracle Rdbの使用
共有可能イメージのイメージ初期化ルーチンのコードが、SQLやその他の手段でOracle Rdbにコールする場合、Oracle Rdbのイメージに各自の初期化を行う機会がないと、アクセス違反または予期しないその他の動作が発生することがあります。
この問題を回避するには、アプリケーションで次のいずれかの手順を実行する必要があります。
これはバグではありません。OpenVMSイメージのアクティブ化から派生する制限事項です。
11.3 Oracle RMUの既知の問題と制限事項
この項では、RMUインタフェースの既知の問題と制限事項について説明します。
11.3.1 リレーションIDの最大値を超えるとRMU Convertが失敗する
リリース7.2のデータベースに対するRMU Convertの際に、リレーションIDが新しいシステム表に割り当てられる場合、Oracle RdbでのリレーションIDの最大許容値8192を超えると、致命的エラー%RMU-F-RELMAXIDBADが表示され、データベースが以前のデータベース・バージョンにロールバックされます。このエラーが発生した場合は、Oracleサポート・サービスに連絡してください。データベースがロールバックされる場合、ロールバックは成功したが、そのロールバックは致命的エラーの検出によって生じたものであり、ユーザーからリクエストされたものではないことを示す致命的エラー%RMU-F-CVTROLSUCが表示されます。
この状況は、データベースで定義される表の数が著しく多い場合、または多くの表が定義されて、その後に削除された場合にのみ発生します。
次の例は、データベースでのリレーションIDの最大許容値8192を超えた場合の%RMU-F-RELMAXIDBADエラー・メッセージと、データベースがリリース7.2に変換できないためにリリース7.0にロールバックされた場合の%RMU-F-CVTROLSUCエラー・メッセージを示しています。
$rmu/convert mf_personnel %RMU-I-RMUTXT_000, Executing RMU for Oracle Rdb V7.2 Are you satisfied with your backup of DEVICE:[DIRECTORY]MF_PERSONNEL.RDB;1 and your backup of any associated .aij files [N]? Y %RMU-I-LOGCONVRT, database root converted to current structure level %RMU-F-RELMAXIDBAD, ROLLING BACK CONVERSION - Relation ID exceeds maximum 8192 for system table RDB$RELATIONS %RMU-F-CVTROLSUC, CONVERT rolled-back for DEVICE:[DIRECTORY]MF_PERSONNEL.RDB;1 to version V7.0
次の例は、リレーションIDの最大許容値を超えない場合を示しています。
$rmu/convert mf_personnel %RMU-I-RMUTXT_000, Executing RMU for Oracle Rdb V7.2 Are you satisfied with your backup of DEVICE:[DIRECTORY]MF_PERSONNEL.RDB;1 and your backup of any associated .aij files [N]? Y %RMU-I-LOGCONVRT, database root converted to current structure level %RMU-S-CVTDBSUC, database DEVICE:[DIRECTORY]MF_PERSONNEL.RDB;1 successfully converted from version V7.0 to V7.2 %RMU-I-CVTCOMSUC, CONVERT committed for DEVICE:[DIRECTORY]MF_PERSONNEL.RDB;1 to version V7.2
RMUのUnload /After_Journalコマンドは、混合形式の記憶域に保存されるレコードの論理dbkeysを再構築する場合、ディスク上の領域インベントリ・ページ（AIP）を使用して、各論理領域に適切なタイプを決定します。ただし、AIPの論理領域タイプ情報は、通常、Oracle Rdbリリース7.0.1以前に作成された論理領域の場合は不明です。RMU Unload /After_Journalコマンドが1つ以上のAIPエントリの論理領域タイプを決定できない場合、領域ごとに警告メッセージが表示され、混合形式の記憶域に保存されるレコードに対して領域番号ゼロで最終的に論理dbkeysを返します。
AIPのディスク上の論理領域タイプを更新するには、RMU Repairユーティリティを使用する必要があります。INITIALIZE=LAREA_PARAMETERS=optionfile修飾子のオプション・ファイルは、TYPE修飾子とともに使用できます。たとえば、MF_PERSONNELデータベースのEMPLOYEES表を修正するには、次の行を含むオプション・ファイルを作成します。
EMPLOYEES /TYPE=TABLE
パーティション化された論理領域の場合、AREA=name修飾子を使用して、更新する特定の記憶域を識別できます。たとえば、MF_PERSONNELデータベースのEMPLOYEES表でEMPID_OVER記憶域のみを修正するには、次の行を含むオプション・ファイルを作成します。
EMPLOYEES /AREA=EMPID_OVER /TYPE=TABLE
TYPE修飾子は、論理領域のタイプを指定します。次のキーワードが許可されます。
注意
このタイプは、RDB$SYSTEM論理領域に対して使用しないでください。このタイプは、システム・リレーションを識別しません。
論理領域に指定したタイプのエラーの明示的なチェックはありません。ただし、不正なタイプが原因で、RMU Unload /After_Journalコマンドが有効かつ論理的なdbkeysを正しく返すことができないことがあります。
11.3.3 HYPERSORTをRMU Optimize After_Journalコマンドと一緒に使用しないこと
OpenVMS Alphaバージョン7.1オペレーティング・システムでは、高パフォーマンスのSort/Mergeユーティリティ（HYPERSORTとも呼ばれる）が導入されました。このユーティリティでOpenVMS Alphaアーキテクチャを使用すると、ほとんどのソート操作とマージ操作のパフォーマンスが向上します。
高パフォーマンスのSort/Mergeユーティリティは、SORルーチンのサブセットをサポートします。ただし、高パフォーマンスのSort/Mergeユーティリティでは、RMU Optimize After_Journalコマンドで使用する一部のインタフェースをサポートしていません。また、RMU Optimize After_Journalコマンドで使用するサポートされていないオプションでこのユーティリティがコールされる場合、高パフォーマンスのSort/Mergeユーティリティからエラーや警告はレポートされません。
このため、高パフォーマンスのSort/Mergeユーティリティの使用は、RMU Optimize After_Journalコマンドでサポートされていません。HYPERSORT.EXEを参照するために論理名SORTSHRを定義しないでください。
11.3.4 RMU Backupに関するEXCLUDE修飾子とINCLUDE修飾子の変更
RMU Backupコマンドは、同じコマンド内でInclude修飾子とExclude修飾子の両方を受け入れなくなりました。この変更により、IncludeとExcludeを同じ行で指定した場合のバックアップ内容に関する混乱はなくなりますが、RMU Backupコマンドの機能が低下することはありません。
バックアップから一部の記憶域を明示的に除外するには、Exclude修飾子を使用して除外する記憶域を指定します。これにより、Exclude修飾子で指定された領域を除くすべての記憶域がバックアップされます。
同様に、Include修飾子により、この修飾子で指定された記憶域のみがバックアップされます。Include修飾子で指定されない記憶域はバックアップされません。Noread_only修飾子とNoworm修飾子を指定すると、読取り専用記憶域とWORM記憶域はバックアップから引き続き省略されます。これはこれらの領域がInclude修飾子で明示的にリストされている場合も同様です。
もう1つの関連する変更はEXCLUDE=*の動作にあります。以前のバージョンでは、EXCLUDE=*によってすべての記憶域がバックアップされていました。リリース7.1以降では、EXCLUDE=*によってルートのバックアップのみが行われます。EXCLUDE=*を使用して作成されるバックアップは、RMU Restore Only_Rootコマンドでのみ使用できます。
11.3.5 RMU Backup操作では1つのタイプのテープ・ドライブのみを使用する
RMU Backupコマンドに複数のテープ・ドライブを使用する場合、すべてのテープ・ドライブのタイプを同じにする必要があります（たとえば、テープ・ドライブをすべてTA90s、TZ87sまたはTK50sにします）。データベースの1回のバックアップ操作に対して異なるテープ・ドライブのタイプ（1つのTK50と1つのTA90など）を使用すると、データベースのリストアが困難または不可能になることがあります。
Oracle RMUは、バックアップ操作時に異なるテープ・ドライブの密度の使用を防ぐようにしますが、すべての無効なケースを検出することはできず、バックアップに対するすべてのテープ・ドライブのタイプが同じであると考えます。
バックアップ操作時に使用するすべてのテープを、リストア操作時に同じタイプのテープ・ドライブで読み取ることができる場合、バックアップが有効になる可能性が高くなります。たとえば、TA90とTA90Eを使用する場合などです。
基本的には、テスト・システムを使用して、バックアップ、リカバリ・プロシージャおよび環境をテストすることをお薦めします。本番システムの障害リカバリをシミュレートするには、データベースをリストアしてから、AIJを使用してリカバリする必要があります。
Oracle Rdbのバックアップ操作とリストア操作の詳細は、『Oracle Rdb7 Guide to Database Maintenance』、『Oracle Rdb7 Guide to Database Design and Definition』および『Oracle Rdb for OpenVMS Oracle RMUリファレンス・マニュアル』を参照してください。
11.3.6 RMU/VERIFYがPGSPAMENTエラーまたはPGSPMCLSTエラーをレポートする
RMU/VERIFYは、記憶域の検証時にPGSPAMENTエラーまたはPGSPMCLSTエラーをレポートすることがあります。これらのエラーは、特定のデータ・ページの領域管理ページ（SPAM）の全体しきい値が、データ・ページの実際の領域の使用量と一致していないことを示しています。SPAMページの詳細は、『Oracle Rdb7 Guide to Database Maintenance』を参照してください。
通常、これらのエラーは、データベースの操作に悪影響を及ぼすことはありません。データ・ページの領域が全体的に使用されていない可能性があるか、または新しい行を保存する領域を検索するときに少量の余分なI/Oが消費されてしまう可能性があります。ただし、これらのエラーが大量に発生しなければ、影響はほとんどありません。
このような非一貫性がOracle Rdbのエラーで生じる場合があります。このような状況が発生した場合は、非一貫性が生じないようにOracle Rdbを修正します。Oracle Rdbの通常操作でこれらのエラーが生じることもあります。次のシナリオでは、SPAMページが一貫していません。
SPAMページが対応するデータ・ページと非同期にならないようにするメカニズムを作成できますが、パフォーマンスへの影響はささいなものではありません。これらのエラーは比較的珍しく、影響が重大ではないため、これらのエラーの発生は、Oracle Rdbの通常操作の一部とみなされます。エラーが前述のシナリオによるものではないことがわかった場合は、Oracleサポート・サービスに連絡してください。
PGSPAMENTエラーおよびPGSPMCLSTエラーを修正するには、次のいずれかの操作を実行します。
リリース7.0以前から存在する、次の問題と制限事項について説明します。
11.4.1 単一ファイルのデータベースの変換
リリース7.0のデータベース・ルート・ファイルの情報は大幅に増加しているため、単一ファイルのデータベースとリリース7.0以上でRMU Convertコマンドを使用する前に、ディスク領域が十分にあることを確認する必要があります。
あるデータベースのデータベース・ルート・ファイルのサイズは、最大で約600ディスク・ブロック増加しています。実際の増加は、ほとんどの場合、データベースに指定した最大ユーザー数によって異なります。
11.4.2 行キャッシュと排他アクセス
表に行レベルのキャッシュが定義されている場合、Row Cache Server（RCS）が表に対する共有ロックを取得して、他のユーザーがその表に対する保護ロックまたは排他ロックを取得できないようにします。
11.4.3 排他アクセスのトランザクションがRCSプロセスでデッドロックになる
長期実行トランザクション（EXCLUSIVE WRITEの表を予約するREAD/WRITEアクセスをリクエストする）から表に頻繁にアクセスする場合、および表に複数の索引がある場合、ユーザー・プロセスとRow Cache Server（RCS）プロセスの間でデッドロックが発生することがあります。
この問題を回避するには、少なくとも3つの回避策が提案されます。
演算子<または>や記憶域マップの境界値と同じ値を含むWHERE句を使用する場合、Oracle Rdbは余分なパーティションをスキャンします。境界値は、WITH LIMIT OF句で指定した値です。次の例は、論理名RDMS$DEBUG_FLAGSをSに定義して実行したもので、その動作を示しています。
ATTACH 'FILENAME MF_PERSONNEL'; CREATE TABLE T1 (ID INTEGER, LAST_NAME CHAR(12), FIRST_NAME CHAR(12)); CREATE STORAGE MAP M FOR T1 PARTITIONING NOT UPDATABLE STORE USING (ID) IN EMPIDS_LOW WITH LIMIT OF (200) IN EMPIDS_MID WITH LIMIT OF (400) OTHERWISE IN EMPIDS_OVER; INSERT INTO T1 VALUES (150,'Boney','MaryJean'); INSERT INTO T1 VALUES (350,'Morley','Steven'); INSERT INTO T1 VALUES (300,'Martinez','Nancy'); INSERT INTO T1 VALUES (450,'Gentile','Russ'); SELECT * FROM T1 WHERE ID > 400; Conjunct Get Retrieval sequentially of relation T1 Strict Partitioning: part 2 3 ID LAST_NAME FIRST_NAME 450 Gentile Russ 1 row selected
前述の例では、パーティション2をスキャンする必要はありません。このことが、結果の精度に影響を与えるわけではありません。ユーザーが余分なスキャンをしないようにするには、境界値以外の値を使用します。
11.4.5 ユーザーがデータベースにアタッチされる記憶域を追加する場合の制限事項
ページ・サイズが既存の最小ページ・サイズよりも小さな新しい記憶域を対話形式で追加しようとして、データベースを手動で開くかまたはユーザーがアクティブな場合、追加操作は失敗し、次のエラーが発生します。
%RDMS-F-NOEUACCESS, unable to acquire exclusive access to database
または
%RDB-F-SYS_REQUEST, error from system services request -RDMS-F-FILACCERR, error opening database root DKA0:[RDB]TEST.RDB;1 -SYSTEM-W-ACCONFLICT, file access conflict
この変更は、ユーザーがデータベースにアタッチされていない場合、およびデータベースがOPEN IS MANUALに設定されて、データベースを終了する場合のみ行えます。Oracle Rdbの一部の内部データ構造は、ページの最小サイズに基づいており、ユーザーがデータベースにアタッチされる場合、これらの構造のサイズ変更はできません。
さらに、この特定の変更はAIJで記録されないため、リカバリのシナリオが失敗します。.aijファイルを使用する場合、この変更によって現在のAIJのリカバリが無効になるため、データベースをバックアップしてアフター・イメージ・ジャーナルを再起動する必要があります。
11.4.6 複数ブロックのページの書込みにはリストア操作が必要
複数ブロックのページがディスクに書き込まれているときにノードに障害が発生した場合、ディスクのページに一貫性がなくなり、フェイルオーバー時にすぐに検出されます。（フェイルオーバーは、アプリケーションを別のコンピュータ上で再起動するアプリケーションのリカバリです。）この問題はあまり発生しません。単一ブロックのI/O操作の自動的な書込みがOpenVMSで保証されるために発生します。この問題は、ユーザーからレポートされたことはありませんが、Oracleでのストレス・テスト中に検出されました。
領域レベルのリストア操作でページを修正します。データベースの整合性が危険にさらされることはありませんが、リストア操作が完了するまで影響のある領域は使用できません。
Oracle Rdbの将来のリリースでは、複数ブロックのアトミックな書込み操作を保証するソリューションが提供される予定です。クラスタのフェイルオーバーによって、複数ブロックのページが自動的にリカバリされるため、手動による操作は不要になります。
11.4.7 レプリケーション・オプションによるコピー・プロセスがアプリケーションより先にデータベース・ページを処理しない
レプリケーション・オプション（以前のデータ・ディストリビュータ）で開始されるコピー・プロセスのグループが、アプリケーションでデータベースの変更を開始した後に実行する場合、そのコピー・プロセスがアプリケーションを捕捉し、RDB$CHANGESシステム・リレーションで論理的にアプリケーションよりも先にあるデータベース・ページを処理できません。すべてのコピー・プロセスは、同じデータベース・ページの待機を調整し、アプリケーションが解放するまで移動しません。アプリケーションによってペースが調整されるため、各コピー・プロセスのパフォーマンスは低下します。
コピー・プロセスが各自のリモート・データベースへの更新を完了すると、RDB$TRANSFERSシステム・リレーションを更新してから、転送で不要なRDB$CHANGES行を削除しようとします。このプロセスでは、RDB$CHANGES表をアプリケーション・プロセスによって更新することはできません。削除プロセスが完了するまでデータベースの更新を待機します。アプリケーションは、RDB$CHANGES表を待機している間、停滞します。その結果、RDB$CHANGESのSPAMページとデータ・ページの競合が発生し、この競合がパフォーマンスのスループットに重大な影響を及ぼすため、通常の処理にユーザーが介入する必要があります。
これは、リリース4.0以上で既知の制限事項です。Oracle Rdbは、ページ・ロックをラッチとして使用します。これらのラッチは、ページでアクションの期間中のみ保持されます。トランザクションの終了まで保持されません。ページ・ロックには、ブロッキング非同期システム・トラップ（AST）も関連付けられています。そのため、プロセスがページ・ロックをリクエストするときは必ず、そのページ・ロックを保持するプロセスが、OpenVMSによってブロッキングAST（BLAST）に送信されます。このようなブロッキングASTを受け取るプロセスは、ページ・ロックをできるだけ早く解放する必要があることをキューします。ただし、ページ・ロックをすぐに解放することはできません。
ページ・ロックを解放する作業リクエストは、verbのコミット時に処理されます。Oracle Rdbのverbは、トランザクション内でアトミックに実行するOracle Rdbの問合せです。そのため、たとえば大きな表のスキャンを必要とするverbはかなり長くなることがあります。更新中のアプリケーションは、そのverbが完了するまでページ・ロックを解放しません。
verbが終了するまでページ・ロックを保持するのは、データベース管理システムの基本的な仕組みのためです。
11.5 Oracle Rdbリリース7.0以前の既知の問題と制限事項
Oracle Rdbリリース7.0以前から存在する、次の問題と制限事項について説明します。
11.5.1 LIKE IGNORE CASEを使用する場合のARITH_EXCEPTまたは不正な結果
LIKE...IGNORE CASE（Oracle Rdbリリース4.2とリリース5.1でリンクされるプログラム）を使用して、Oracle Rdbの上位のバージョンで実行する場合、不正な結果または%RDB-E-ARITH_EXCEPT例外が発生することがあります。
問題を回避するには、IGNORE CASEをLIKEと一緒に使用しないようにするか、または上位バージョン（リリース6.0以上）で再コンパイルして再度リンクします。
11.5.2 問合せから返される行を制限するための様々な方法
問合せから返される行の問合せガバナーを構築するには、SQLのSET QUERY LIMIT文または論理名のいずれかを使用します。次の注意事項は、2つのメカニズムの違いを示しています。
RDMS$BIND_QG_REC_LIMIT論理名を小さな値に定義すると、論理に割り当てる値に関係なく、問合せが行を返さずに失敗することが多くあります。次の例は、制限を10行に設定して、結果として発生する失敗を示しています。
$ DEFINE RDMS$BIND_QG_REC_LIMIT 10 $ SQL$ SQL> ATTACH 'FILENAME MF_PERSONNEL'; SQL> SELECT EMPLOYEE_ID FROM EMPLOYEES; %RDB-F-EXQUOTA, Oracle Rdb runtime quota exceeded -RDMS-E-MAXRECLIM, query governor maximum limit of rows has been reached
対話型SQLは、SELECT文を処理する前に、表のメタデータ・キャッシュをロードする必要があります。この例では、対話型SQLはメタデータ・キャッシュをロードして、列EMPLOYEE_IDが実際に表に対して存在するかどうかを確認できるようにします。Oracle Rdbシステム・リレーションRDB$RELATIONSおよびRDB$RELATION_FIELDSに対する問合せは、行の制限を超えています。
Oracle RdbはSELECT文を作成しません。もちろん実行もしません。制限を100よりも少ない数（EMPLOYEESのカーディナリティ）で、EMPLOYEESの列数よりも多い数（つまりRDB$RELATION_FIELDSシステム・リレーションから読み取る行数）に増やすと、各列の定義を読み取るには十分になります。
システム・リレーションに対して実行する問合せの指示を確認するには、RDMS$DEBUG_FLAGS論理名をSまたはBに定義します。
SQLのSET QUERY文を使用して行制限を設定し、同じ問合せを実行する場合、失敗する前にSQLのSET QUERY文で指定した行数が返されます。
SQL> ATTACH 'FILENAME MF_PERSONNEL';
SQL> SET QUERY LIMIT ROWS 10;
SQL> SELECT EMPLOYEE_ID FROM EMPLOYEES;
EMPLOYEE_ID
00164
00165
.
.
.
00173
%RDB-E-EXQUOTA, Oracle Rdb runtime quota exceeded
-RDMS-E-MAXRECLIM, query governor maximum limit of rows has been reached
SET QUERY LIMITは、ユーザーの問合せのみを10行に制限することを指定します。そのため、メタデータ・キャッシュのロードに使用する問合せは制限されません。
SET QUERY LIMIT文と同様に、SQLプリコンパイラとモジュール・プロセッサのコマンドライン修飾子（QUERY_MAX_ROWSおよびSQLOPTIONS=QUERY_MAX_ROWS）は、ユーザーの問合せのみを制限します。
論理名RDMS$BIND_QG_REC_LIMITを使用して返される行を制限する場合の違いに注意してください。これらの論理名は、明らかに多くの問合せを制限できます。これは、4GLツール（SQLプリコンパイラ、SQLモジュール・プロセッサ、Oracle Rdbシステム・リレーションを問合せ処理の一部として読み取るその他のインタフェース）を使用する場合に重要です。
11.5.3 パラレル索引作成にSHARED DATA DEFINITION句を最適に使用する場合の提案
CREATE INDEXプロセスでは、次の手順が必要です。
手順6は、システム・リレーションと索引が他の更新済の表と同様にロックされているため、他の索引定義者との競合ポイントになります。
複数のユーザーが同じ表で索引を作成するには、SET TRANSACTION文のRESERVING table_name FOR SHARED DATA DEFINITION句を使用します。この機能を最適に使用するために、Oracle Rdbは次のガイドラインを提供します。
次の表は、SHARED DATA DEFINITION句を使用してパラレルで複数の索引を作成する場合の経過時間のメリットを示しています。この表は、10個のパラレル・プロセス索引の作成（Index1、Index2、...Index10）の経過時間と、10個連続の索引の作成（All10）を含む1つのプロセスを示しています。この例では、グローバル・バッファが有効であり、バッファの数は500です。パラレル索引作成での最長時間はIndex7で、経過時間は00:02:34.64です。これと比較して、10個連続の索引作成の経過時間は00:03:26.66です。1つのパラレル作成の索引の最長経過時間は、10個連続の索引作成の経過時間よりも短くなります。
| 索引作成のジョブ | 経過時間 |
|---|---|
| Index1 | 00:02:22.50 |
| Index2 | 00:01:57.94 |
| Index3 | 00:02:06.27 |
| Index4 | 00:01:34.53 |
| Index5 | 00:01:51.96 |
| Index6 | 00:01:27.57 |
| Index7 | 00:02:34.64 |
| Index8 | 00:01:40.56 |
| Index9 | 00:01:34.43 |
| Index10 | 00:01:47.44 |
| All10 | 00:03:26.66 |
ストアド・ルーチンをコールする場合、同じルーチンを使用して、ストアド・ファンクションで引数の値を計算しないでください。たとえば、コールするルーチンが引数の値の計算時にストアド・ファンクションからもコールされる場合、ルーチンに渡される引数は正しくないことがあります。
次の例は、ストアド・プロシージャPをコールする際に、引数の計算で同じストアド・プロシージャPを別に起動する状況を示しています。
SQL> create module M cont> language SQL cont> cont> procedure P (in :a integer, in :b integer, out :c integer); cont> begin cont> set :c = :a + :b; cont> end; cont> cont> function F () returns integer cont> comment is 'expect F to always return 2'; cont> begin cont> declare :b integer; cont> call P (1, 1, :b); cont> trace 'returning ', :b; cont> return :b; cont> end; cont> end module; SQL> SQL> set flags 'TRACE'; SQL> begin cont> declare :cc integer; cont> call P (2, F(), :cc); cont> trace 'Expected 4, got ', :cc; cont> end; ~Xt: returning 2 ~Xt: Expected 4, got 3
前述に示した結果は正しくありません。ルーチンの引数の値は、複雑な式の値が計算される前に、コールされたルーチンのパラメータ領域に書き込まれます。これらの計算は、（例に示すように）以前にコピーされたデータを上書きします。
これを回避するには、引数の式（この例ではストアド・ファンクションFのコール）を一時変数に割り当て、この変数をルーチンの入力として渡します。次の例は、回避策を示しています。
SQL> begin cont> declare :bb, :cc integer; cont> set :bb = F(); cont> call P (2, :bb, :cc); cont> trace 'Expected 4, got ', :cc; cont> end; ~Xt: returning 2 ~Xt: Expected 4, got 4
この問題は、Oracle Rdbの将来のバージョンで修正される予定です。
11.5.5 保留可能カーソルを使用する場合の考慮事項
アプリケーションで保留可能カーソルを使用する場合、COMMIT文またはROLLBACK文の実行後、カーソルで選択された結果セットが安定した状態に保たれないことに注意してください。つまり、コミットやロールバックが行われた後に保留可能カーソルで選択された行に対してロックがかけられていないため、他のユーザーによって行の挿入、更新および削除が行われることがあります。さらに、アクセス・ストラテジに応じて、Oracle Rdbが実際に行をフェッチする前に、まだフェッチされていない行が変更される場合があります。
その結果、同時実行ユーザー環境で保留可能カーソルを使用する場合、次の異常が発生することがあります。
保留可能カーソルは、読取り専用またはほとんどの部分が読取り専用の環境にとっては非常に強力な機能です。ただし、同時更新環境では、カーソルが不安定な状態は受け入れられません。更新環境での保留可能カーソルの安定性は、Oracle Rdbの将来のバージョンで解決される予定です。
論理名RDMS$BIND_HOLD_CURSOR_SNAPを値1に定義して、すべての保留カーソルが結果セットをキャッシュされたデータ領域にフェッチするようにできます。（キャッシュされたデータ領域は、SET FLAGS 'STRATEGY'文またはRDMS$DEBUG_FLAGSのSフラグで表示されるオプティマイザ・ストラテジの一時リレーションとして表示されます。）この論理名は、カーソルのある程度の安定に役立ちます。
11.5.6 AIJSERVER権限
セキュリティの理由から、AIJSERVERアカウント（RDMAIJSERVER）は、NETMBX権限およびTMPMBX権限でのみ作成されます。これらの権限は、ほとんどの場合、ホット・スタンバイを起動するのに十分です。
ただし、本番のホット・スタンバイ・システムの場合、これらの権限は、すべての環境と作業負荷の状況で連続したレプリケーションを確保するには十分ではありません。そのため、DBAがAIJSERVERアカウントに次の追加の権限を提供することをお薦めします。
| 目次