Q&A
ここの掲示板ではMarkdownの使い方を覚えてください。
SQLなどのコードは https://teratail.com/help/question-tips#questionTips3-7 の [コード] に修正してください。
Oracle11g（11.2.0.4）から19c（19.3.0.0）へexpdp->impdpしたシステムで、以下の現象が発生しています。
同様の現象を経験された方や現象をご存知の方はぜひ解決策を教えていただきませんか。
現象が発生しているテーブル
MAILTABLE ( M_SEQ NUMBER DEFAULT 0 NOT NULL, M_FROM VARCHAR2(64) DEFAULT '', M_TO VARCHAR2(64) DEFAULT '', M_CC VARCHAR2(64) DEFAULT '', M_BCC VARCHAR2(64) DEFAULT '', M_REPLYTO VARCHAR2(64) DEFAULT '', M_ERRORSTO VARCHAR2(64) DEFAULT '', M_SUBJECT VARCHAR2(80) DEFAULT '', **M_MESSAGE LONG** DEFAULT '', SEND_SCHEDULE_YMD DATE, SEND_END_DATE DATE)
現象
メールをスケジュールした日時以降に送るプログラムがあり、SEND_SCHEDULE_YMDがSYSDATE以前のデータを取得し、M_FROMをFROM、M_TOをTOに、M_SUBJECTをメール、M_MESSAGEを本文として送信します。送信後はSEND_END_DATEに送信日時を入れて更新します。
11g時代から使っているプログラムです。
SELECT文は以下の通り。
SQL
1select M_SEQ , 2 M_FROM , 3 M_TO , 4 M_CC , 5 M_BCC , 6 M_REPLYTO , 7 M_ERRORSTO , 8 M_SUBJECT , 9 M_MESSAGE , 10 SEND_SCHEDULE_YMD, 11 SEND_END_DATE 12from MAILTABLE 13where SEND_SCHEDULE_YMD <= SYSDATE 14and SEND_END_DATE is null 15order by M_SEQ; 16
今回19cにdatapumpでエクスポート→インポートしたこのテーブルで、「order by」を使うか使わないかで取得するデータの中身が入れ替わってしまうレコードが発生しました。
＜order by を使わない結果（正しい内容）＞
|M_SEQ|M_FROM|M_TO|M_SUBJECT|M_MESSAGE
|:--|:--:|--:|
1 |aaa@aaa.com |to1@bbb.com |同じタイトル |本文１
2 |aaa@aaa.com |to2@bbb.com |同じタイトル |本文２
3 |aaa@aaa.com |to3@bbb.com |同じタイトル |本文３
＜order by を使った結果（不正な内容）＞
|M_SEQ|M_FROM|M_TO|M_SUBJECT|M_MESSAGE
|:--|:--:|--:|
||||
1 |aaa@aaa.com |to1@bbb.com |同じタイトル |本文１
1 |aaa@aaa.com |to1@bbb.com |同じタイトル |本文２
3 |aaa@aaa.com |to3@bbb.com |同じタイトル |本文３
色々試した結果
１．order by はどの項目を指定しても対象のレコードが含まれる抽出の場合に不正な内容になりました。
M_SEQ=1が悪いのか、M_SEQ=2が悪いのかははっきりしていません。
データの中身が入れ替わってしまうレコードを除いた状態でSELECTすれ発生しない現象です。
２．LONG型のM_MESSAGEを取得する項目から外した場合は、対象のレコードが含まれている状態でorder by を付けても正しい結果になりました。
３．19c上で、テーブルMAILTABLEをexpし、truncate してからimpすると本現象は解消されています。
その後に登録さるデータについては経過観察中です。
４．11g上で存在していたレコードで19cにdatapumpでインポートされたものだけではなく、19cに移行してから作成されたレコードでも発生しているスキーマもあります。
５．同じDB上でテーブル構成は同じ、データ内容が異なるスキーマがいくつかあり、本現象が発生していたのは6つのDBサーバ上で合計24スキーマあるうち4スキーマで現在この現象があるレコードが発生していました。
６．別テーブルで同じくLONG型の項目をもつ「テーブルB」があり、こちらでも3/24スキーマでこの現象に近いことが発生しており、こちらも「３．」を実施すると解消されています。
Oracleサポートへの問い合わせも並行してすすめておりますが、何かお気づきの点がありましたら教えてください。
ご指摘ありがとうございます。
Markdownやってみました
LONG 型が原因だとしたら、もう使うなってことですかねー
MAX_STRING_SIZE = EXTENDED にして VARCHAR2 を 32767 バイトにするか、CLOB にするか・・・
最終的にはalter table mailtable modify M_MESSAGE clob;等を考えていますが、
まさかこんな動きになるケースがあるとは思っておらず・・・。
回答1件
0
Oracle 19C SQL言語リファレンス LONG列を使用した表を作成しないでください。かわりに、LOB列(CLOB、NCLOBまたはBLOB)を使用してください。LONG列は、下位互換性のためにサポートされています。
ですので、LOBに変更するのが吉です。
オラクル・サポートからの回答はサポート・センターの了解を得ない限り公開することは禁止されてるので、ご注意ください。
投稿2022/01/08 07:02
総合スコア16417
ご回答ありがとうございます。
LOBに変更するのも検討していますが、現時点ではLONGのままでの解決策がないか模索しております。
オラクル・サポートにLONG型のバグを修正できるパッチが提供されていないか確認するとして、時代遅れになったコードを修正するのに必要以上に消極的になってはいけません。
5年くらい前にOracle Database のパフォーマンス・チューニング案件で調査したら幼稚過ぎるSQLを修正したら処理時間がほぼ半分以下に改善できるのに、お客様の担当者はSQL入門レベルの勉強をする気はまったくなく、SQLを修正するのに異常に怯えていてほとんど修正させてもらえなかった(開発環境でさえも)ことがあります。
わたしもLONG型は10年以上使っていません。
ご回答ありがとうございます。
そうですね、Oracleサポートには対応するパッチがあるか確認したいと思っています。
幸い、LONG使ってる箇所はとても限定的なので対応もそれほど時間がかかるわけではないのですが、まずは原因がわかってからの改修にしたいと考えております。
あなたの回答
tips
プレビュー
